I wish the Clojure guys would come up with some clear and direct messaging around its license. When I started exploring Clojure one weekend a few months back, I found that it's the only language I've ever seen that uses the Eclipse Public License. In turn, the EPL is the only license I've ever seen where the FAQ is even more ambiguous and confusing than the license text itself!
I did some sniffing around to see what the practical effects (if any) are for applications written in Clojure, and on their own mailing list the topic is a bit of a mess:
Everyone seems to agree that forking or modifying Clojure itself would trigger all sorts of license requirements (e.g. GPL-incompatibility, you might need to use the EPL, etc).
However, nobody on their mailing list seems to agree on what the licensing means for normal applications that happen to be written in Clojure and use its library at runtime. Is that a "derivative work", or not? Does the fact that you write applications in Clojure have any bearing on the licenses that you may choose?
I know that it's somewhat possible to mix the EPL with almost anything... because I've worked with some Aptana IDE's that are based on Eclipse, yet use GPL v3 with several paragraphs of caveats and exceptions. (http://www.aptana.com/legal , http://www.aptana.com/legal/aplgplex) Not sure about GPL v2.
I just don't want to have to think about this stuff AT ALL as an application developer who isn't making changes to the programming language or core runtime library. The murkiness on their own mailing list has definitely been a deterrent from my exploring Clojure more seriously.
Hmmm, when looked into this a few days ago with an eye towards a Clojure port (in part a fork) what I remember finding is that the EPL allows separate "modules" to have a different license, although of course that couldn't be an incompatible one like the GPL based on the latter's linking requirements. The Aptana legal link looks pretty clear at first glance, "the EPL is not particularly compatible with the GPL".
I think we would have heard by now if there were any viral problems with normal applications built on top of it, Clojure has been a very big thing in the Lisp world for years.
IANAL but I don't think you need to worry about this too much as an application or open source developer USING Clojure the language and Clojure's standard libs. This question and its answers on Stack Overflow points to an interpretation that makes sense intuitively to me, but again, not a lawyer, pretty ignorant of this stuff, etc...
It would be nice if someone from the Clojure team would add a FAQ page or something about the license to clojure.org as it pertains to users of the language... Since this seems to come up a lot.
For what it's worth, I am actively improving Nightcode, an IDE written in Clojure that bundles Leiningen. Last night I released 0.0.6. We have a long way to go before it's stable, but more feedback from users is the best way to get there.
It will automatically set up the REPL, and you can run expressions just like in EMACS/Light Table, it has code completion, source browsing, etc... Super easy to set up and run, much easier than any of the alternatives.
This Clojure environment is by far the easiest programming environment I have ever set up. Far easier than even Python or Ruby on Linux, definitely easier than anything EMACS-related. Leiningen is super easy to use from the terminal, and Clooj is super easy to set up and use.
Even having to build clooj from source (because the mediafire link didn't work) was super easy. I can't get the REPL to load the symbols in my project, but that's probably my fault.
Yeah, the REPL isn't perfect (sometimes it needs to be restarted if you mess with it too much), but it's a heck of a lot easier to set up than EMACS with nRepl, or even Light Table (which itself is a great editor).
Another good one is Catnip, which is an add-on to Lein which launches an editor/REPL in your browser...
It never ceases to amaze me the kinds of things that people have already done with Clojure - games on Google Play store for Android, awesome IDEs, Pedestal is looking like a great web framework, Datomic, Clojurescript and now Clojure that compiles to C. Not to mention all the private enterprisey things being done, I know of at least a few banks/hedge funds which use Clojure internally, a robotics company, and likely many others...
Since the article is targeted at those wanting to get started with clojure, I recommend that newcomers avoid trying to learn a new editor and a new language at the same time.
There are clojure plugins for many popular editors these days. If you already have an editor/IDE you like, I'd recommend starting there and moving to something else in the future once you get used to it.
I'd say that this is usually the case for many languages, but Lisp IDEs have been refined, unrefined, GMOd, and subjected to all kinds of prodding that you generally want to pick one of the approved environments (Emacs, LispWorks Emacsish, Allegro I-wanna-be-Genera-Emacs).
The main reason for this is that so many of the tutorials will assume emacs for your repl management beyond the basic "(car '(foo bar baz))" and any emacs will have a well-defined "manage the indentation and parens"-mode.
Getting help from other people will often involve Emacs-specific instructions as well. "C-c C-e at the end of the sexpr and eval the result..." which may or may not be the binding in Eclipse or whatever IDE the person is using.
What are the issues you've found with IntelliJ? Have you reported them? We'd love to know how we can improve it. Please feel free to ping me (hadi at jetbrains)
The gradle/groovy integration is of only slightly better harmony. It's very obviously a plugin and the lack of analysis makes for an awkward dynamic programming experience.
For example, I dislike the yellow warning lines that abound when it can't infer a type that has previously been assigned on all call paths.
There are issues from TWO years ago with no comments, no explanation, and no fix.
Why would I use your product if I can't trust you to fix anything? With Emacs and nRepl or Slime/Swank I can fix things myself if I need to. Although in practice I don't need to.
Nobody cares about which part you're responsible for, they care about how nice the tools are. Saying it's OSS and not your problem is weak and looks bad. Especially given it's on your GitHub organization!
If you want people to use IntelliJ, you have to step up to the plate and contribute to stuff outside of the core IDE.
If things like LaClojure are garbage, it makes you look bad and people will start using other tools.
Java programmers that learn Clojure are, (in my experience), leaving their Java IDEs of choice because the support is poor for their new favorite language.
They're coming home to Emacs or experimenting with LightTable.
That makes it your problem. Nobody cares about excuses.
Let me be clear, I don't care if you fail, I'm an Emacs user and believe in programmers maintaining their tools for themselves out of deep mistrust for commercial entities owning how programmers do their work. But if you want to be competitive you have to stop being myopic.
Have you been paying attention? Companies like http://zeroturnaround.com/ make their product free for Scala users because those people are the vanguard for their respective communities and will often be the ones making product decisions.
There is a comparable thing going on with YourKit's wonderful support of the Clojure community.
How exactly are you staying on top of the latest developments in JVM languages if you're concerned exclusively with "IntelliJ-the-IDE-itself"?
Who says we're paying attention only to the IDE itself? Apart from the fact that we support a wide variety of languages on the platform, both JVM targeted languages as those that are not, and that the fact that we're also developing our own OSS language, kind of is contrary to us only focusing exclusively on the IDE or the tools.
My point about it being on our GitHub account and OSS is that the source is available, much like it is for plug-ins for Emacs or Sublime or any other environment. It's not about blaming anyone or pushing the effort on to someone else.
We have quite a few developers dedicated to writing plug-ins in-house, specially considering pretty much all the functionality in IDEA is based around plug-ins and in fact we have around 3 people that are working alone on Scala plugin.
> ... and in fact we have around 3 people that are
> working alone on Scala plugin.
As a paying customer who bought IntelliJ solely for its Scala plugin, I'm currently seriously questioning whether it is still worth paying for the next version.
It is not only that I can't see much progress with IntelliJ's Scala plugin and that the free Scala IDE is getting increasingly better as well as having some amazing add-on functionality.
I'm really wondering how much money of their Scala customers JetBrains is really spending on improving the Scala plugin and how much of it is silently funnelled into FUD and vaporware factories like Kotlin.
That's a huge conflict of interest and the reason why a significant part of my next paycheck probably won't end up in JetBrains bank account.
Also, IntelliJ Community Edition is OSS and free. Available on GitHub as well as downloadable from our site. So not sure what you would need in terms of making the product free. We also have quite a few community programs where we provide licenses, and OSS projects can qualify for free licenses to ANY of our products.
Does LaClojure have a blog or some kind of "news" page where we can find out what the latest developments have been? All I've found is the github page.
I'm still deciding whether emacs is worth all the time and learning. I've seen people use it and it looks wickedly intricate. I was going get into tmux when I saw the HN post. I'm only using sublime, but I know that's for script kiddies ;).
When ruby hit the mainstream we would see these kind of 'getting started' atricles once in a while but very very rarely. Would it be safe to assume that since functional thinking is such a departure from traditional OO that it warrants more 'getting started' ?
What are you using beyond Chrome? The Open Sans web fonts render much better on my Mac with Chrome Version 30.0.1588.0 dev.
Not that I'm a big fan of the font (too close to Arial, especially the 'R' for my antiquated tastes), but I would say it's a well-rendered font of a typeface I do not like. :-)
I probably would, if it were mine. However, I'm not the author.
It's also not blurry at all on my setup, so if you do try to find the actual author and suggest a change, you might want to include details of your setup so he would have a chance to test any changes.
It may be the page has changed since then but the screenshot below isn't even close to the way it shows on firefox (black text, blue accents, white background).
It is advisable to begin with Scheme (SICP) or Racket (HtDP2) to internalize the underlying ideas behind Lisps, because in Clojure everything is messed up due to kitchen sink syndrome.
After proper Scheme training (CS61A) Clojure looks awkward and messy but very useful, as it supposed to be due to its "productivity beats clarity/conciseness" philosophy of scripting languages, such as Ruby.
I don't think you miss a single clojure thread with your rhetoric about "what a true lisp is." It really is rather tiring. I'd kindly ask that if you want to promote scheme or common lisp you do it by submitting relevant articles and promoting them in a positive way, rather than the very negative way you do in every single clojure thread.
Yes, it could be called a promotion, if you wish, but not of Scheme, but the philosophy of being good-enough mix of very few well-selected and balanced features.
The old CS61A course, of which I am huge fan, taught you the very important idea that all you need is lambda as Brian Harvey put it himself.)
The meaning is quite profound. First of all, the notion that everything could be written using just procedure calls (we will not talk about Lambda Calculus here) few special forms and list notation, which goes back to John McCarthy is the great one, and Scheme, therefore, is a result of polishing this idea.
Second very important idea related to the first - all the fundamental ideas and techniques in programming one should learn and internalize, could be easily and elegantly expressed in Scheme. This is why it was a language of choice for teaching CS. Even if it lacks some features, such as advanced module system or OO capabilities, but they teach you how easily it could be implemented, and that it is of second importance.
So, if I am promoting something here it is these realizations from Brian Harvey, and for me Clojure is something very opposite, a mess and hype and unjustified rhetoric, claiming that it is superior to something much more great and profound.
And it is not an empty pose. Even playing with its repl will teach you that it is full of special cases you must learn and know, that if something is printed as a list it might be not, that behavior of a function depends on what data-structure is given as its argument and so on. I'm also not sure that collections is such a great idea.
No one denies the importance of Lambda calculus, but you are confusing the notions of minimality, expressivity, and pragmatism. Worse, you can't seem to accept that others do not agree with your notion of an "ideal balance" of these things.
It's perfectly fine to not like a language, but it's inappropriate to be so over the top with it as to post in, quite literally, every story about that language.
For someone who doesn't have enough hours in the day to receive "proper Scheme training" and already (sort of) knows Clojure could you go into detail about what you mean when you talk about it being "messed up due to kitchen sink syndrome."?
Gladly. Some languages does not emerge all of sudden as a product of one sharp mind (there is no doubts about that) but are time-selected mix of (ideally very few) basic concepts and syntactic constructs which form a well-balanced set of features.
The examples of well-chosen set of basics is Scheme R4RS, or pg's Arc. The examples of so-called natural selection are CL (an attempt to put together the best ideas and syntactic sugar from various implementations) and, surprise! Haskell, which is a product of a merge of efforts of ML/Lazy languages world.
On the other hand, there are languages created by one individual, according their own preferences, such as Perl, Ruby and Clojure.
Ruby, for example, it is a mix of features from Perl and Smalltalk, its author liked, but, of course, the resulting language is neither a dialect of Perl or Smalltalk. It is a language of its own.
Similarly, Clojure is a mix of features from various languages, notable Common Lisp, Smalltalk, ML, plus various Python-like comprehensions for vectors or hashmaps.
There are many other clever tricks, like simplified pattern matching, at the cost of sacrificing uniformity and announcing vectors as parameter lists for binding constructs, apparently from ML, and multi-method function declarations, also from ML.
The result is a language of its own, and cannot be called a Lisp, the same way Ruby cannot be called Smalltalk. The design decisions, while mostly clever, broke the uniformity and clarity of classic Lisps.
So, in my opinion, Clojure is closer to Ruby in its ideology, than to Lisp.
Clojure is most definitely a Lisp. The biggest difference from more traditional lisps is that it has literals for a wider variety of data structure types. Apart from that, it has every single characteristic that defines a lisp.
> After proper Scheme training (CS61A) Clojure looks awkward and messy but very useful, as it supposed to be due to its "productivity beats clarity/conciseness" philosophy of scripting languages, such as Ruby.
As someone with "proper Scheme training" (CS61A), I've found that Clojure is actually much more clear than Scheme in most cases. The code is less beautiful from a purely visual perspective because there is more syntax, but a lot of complexity gets removed when you add literals for sets, vectors, and maps.
Well, I don't think it can be called a LISP, as in LISt Processing, which I pedantically use to describe the Lisps that came before it, because in addition to making those additional data structures first class syntactic citizens and their widespread use by programmers, it as dschiptsov notes modified some standard LISP syntax to use vectors where you have a list that'll never be modified, extended, etc.
E.g. (defn name [arg1 arg2] body). Lists are not the alpha and omega like they are in LISPs.
But I agree it has "every single characteristic that defines a lisp", even if it looks funny to experienced Lispers like myself.
Aesthetically I much prefer standard LISP syntax + indentation , but 100% support the use of literals for the non-list data structures. Many disagree on the syntax, and if no longer having a sea of pure parens brings more adaptation I'm willing to live with it. I got the impression the syntax changes were due to that reason vs. inspiration from ML, but I'm not at all sure about that. Still, Rich Hickey is an experienced Lisper with exquisite taste below the level of syntax, so I'm pretty sure he was aware of the implications of his syntax changes.
My understanding is that the square-bracket notation is just a reader macro to provide syntax sugar. Now, I know Clojure doesn't expose reader macros to the end user, but you could achieve the same syntax in CL without too much hassle (http://dorophone.blogspot.co.uk/2008/03/common-lisp-reader-m... for something similar). I don't think it's necessarily reasonable to criticise it for baking in a choice you could quite happily make in CL.
EDIT: "Criticise" is clearly the wrong word, since your description isn't perjorative. "Distinguish" would be better.
Indeed, and I'm not really criticizing it, it's a matter of taste, and arguing over that is generally fruitless.
However, while I could make such a choice in CL, or modify Clojure, the standard including indentation for such a fundamental part of a language is controlling, and if I want to be part of the community I have to follow it.
I don't understand your position on lists. In Clojure, lists, vectors, and other collections are unified under the Seq abstraction. To me, they are all the same, until I need some specific behavior or performance characteristic.
It's aesthetic, how the code looks (e.g. in an editor), and can't be separated from a quarter century of LISP experience (Lisps where only lists/pairs are syntactically first class). Note data in code is an exception, it's perfectly fine to e.g. include literals of other collections.
Don't take me wrong, making the other collections syntactically first class and unifying them under the Seq abstraction is a really good thing, in fact when I appreciated that it was the first thing that got me really excited about Clojure, especially Clojure as "the next Lisp". But personally, if just for myself, I would have kept the vectors out of the syntax and depended on indentation in smart editors.
I've said it before, I'll say it again. Your definition of "Lisp" excludes Common Lisp. Precisely the same criticism of "kitchen-sink syndrome" was levelled at CL back in the day.
I don't see how a definition of "Lisp" that excludes Common Lisp is useful. How do you find this definition useful? You bring it up with remarkable regularity when Clojure is mentioned, presumably you find some value in it?
Lisp was the discovery of a set of a few simple concepts so elegant they give us a transcendental way of thinking about programs. But then people built religions around their own embodiments of the concepts. Eventually the infighting started and it is still driving most folks away.
Occasionally, a pragmatist like Hickey comes along and says "hey look how useful this can be". Another generation of programmers takes a look at Lisp. Where will it go this time?Can Lisp be saved from the Lispers?
I did some sniffing around to see what the practical effects (if any) are for applications written in Clojure, and on their own mailing list the topic is a bit of a mess:
https://groups.google.com/forum/#!topic/clojure/bpnKr88rvt8 https://groups.google.com/forum/#!topic/clojure/mGf_SuHsSGc
Everyone seems to agree that forking or modifying Clojure itself would trigger all sorts of license requirements (e.g. GPL-incompatibility, you might need to use the EPL, etc).
However, nobody on their mailing list seems to agree on what the licensing means for normal applications that happen to be written in Clojure and use its library at runtime. Is that a "derivative work", or not? Does the fact that you write applications in Clojure have any bearing on the licenses that you may choose?
I know that it's somewhat possible to mix the EPL with almost anything... because I've worked with some Aptana IDE's that are based on Eclipse, yet use GPL v3 with several paragraphs of caveats and exceptions. (http://www.aptana.com/legal , http://www.aptana.com/legal/aplgplex) Not sure about GPL v2.
I just don't want to have to think about this stuff AT ALL as an application developer who isn't making changes to the programming language or core runtime library. The murkiness on their own mailing list has definitely been a deterrent from my exploring Clojure more seriously.