Why Clojure will win

I’m going to make a bold proclamation. I’m not going to claim that Clojure will ever become the most popular language, but it will win in the next 15 years in a major way, because it is already one of the most interesting, and all signs show that it will continue to build momentum,. This is independent of what happens with the Java ecosystem; Clojure will be ready to go off of the JVM if it needs to do so. It is not in a hurry to make that change, but it that becomes necessary it will happen. Why am I so confident about Clojure? Partly, it’s the community. I started using Clojure in late 2008, and the language has improved by leaps and bounds, whereas many languages seem to have gone sideways over the past few years. That, however, isn’t the full story. There are a lot of good languages out there, and most remain in relative oblivion. What makes Clojure different? It’s not just one thing about it, because what I’ve realized about Clojure of late is that it’s not just a language. It’s a vision. Programming should be interactive, as beautiful as possible, modular, and it should generate assets that are easy to use and learn. The Clojure community gets that in a way that many language communities, within the enterprise, don’t.

On a fundamental level, this is different from the enterprise Java vision that has grown up over the past 18 years. The language itself (Java) isn’t so awful– it’s the C analogue of a very powerful garbage-collected virtual machine– but the culture that has grown up around it is conducive to gigantic programs, low interactivity, and manager-friendly conservatism. That doesn’t make it impossible to build good software– far from it– but it creates an environment that’s dissatisfying to the few people capable of writing good software. Clojure has gone the other way. Its build tools and frameworks (although not as fully featured as some in other languages) are simple, idiomatic to the language, and coherent with the vision. While the most “dangerous” feature of Clojure (macros) certainly does allow “cowboy coders” to run wild with ill-conceived DSLs, the truth is that one spends far less time contending with these parochial DSLs in a Clojure program than one does on a typical enterprise Java project; the latter tends to be full of ad-hoc DSLs built to overcome shortfalls in the language. Clojure, on the other hand, has little to be overcome in the language; one can extend it rather than making deeper alterations. Features are added to the language orthogonally, through libraries.

The reason why I say Clojure is a vision more than a language is that it strives to go into messy places that ivory-tower language inventors would avoid, while refusing to compromise on its core vision. It’s visually evident, when looking at a Clojure program, what aspects of the language are idiomatic and which are (usually temporary) tolerated compromises (e.g. the difference between using count or .length on a String). The language strives to remain attractive, but its purpose is to be a fully-fledged commercial language, and it will favor practicality when it’s prudent to do, and rejoin the prevailing aesthetic over time. Clojure is, in particular, designed to go beyond its most typical platform (Java). The reference implementation runs on the (typically server-side) JVM, but ClojureScript runs in the browser, and both dialects get core support. Also in accord with this expanding vision, Pedestal is one of many web frameworks that have been built for the language, and Incanter is bringing it into statistical computing. Then there’s Datomic, which applies Rich Hickey’s refined aesthetic and engineering senses to the database world. In Clojure, there’s a movement to restore a certain aesthetic integrity, modularity, and empowerment of the individual programmer that has, for a couple of dark decades, been lost in the enterprise.

Does Clojure have weaknesses? Of course. In 2008, the warts were evident, because the language was so new (for one thing, JVM interop was very painful). They’re less so now; one has to do a bit of work to find the issues. Yet it has very few fundamental weaknesses. The core language itself is very sound, and it’s only getting better as the vision is refined.

One argument made against it is its lack of a static type system. How damning is this? To be honest, I like static typing a lot, and used to be a die-hard defender of it. My view has softened a bit. My experiences with Scala– well-designed to its purpose, but solving a very difficult (and possibly impossible) problem, which is to unify the Haskell and Java worldviews– have convinced me that compile-time typing, strictly speaking, isn’t needed for most purposes. Interface integrity (type guarantees, contracts) is important, and Haskell and Clojure come loaded with different tool sets to guarantee such things. In the hard-line statically typed world, there’s a type system you get, implicitly, out of the box. It comes with the language, and can be extended in some powerful ways, but it has limits. There are some desired type-system features that require hacking the compiler or making fundamental “wizards only” alterations to the type system that, if done wrongly, can be dangerous. Type systems limit the kinds of programs one can write (and that’s a feature, because reasoning about arbitrary code is literally impossible). They provide automated reasoning about code that is better than the hand-rolled test suites found in 99% of web applications, for sure, but they also (perhaps surprisingly) limit some of the things one can do to reason about code. (If you make a type system too powerful, type-checking becomes undecidable and you’re back into the wild.) Clojure, on the other hand, certainly makes it possible to write sloppy code; however, it also makes it possible to prevent sloppy code in ways that are very difficult in its static counterparts. An enterprise Scala project, for example, is typically going to present the frustrations that come with components that live outside the language. Learning Scala isn’t that bad, but Maven and Spring and Hibernate? Ouch. In Clojure, most of the typically “external” needs are provided with idiomatic libraries that can be reasoned about within the language.

This underscores what I think is the biggest advantage to the dynamically typed world. Static typing is great when one is solving a known problem and requirements don’t change, but when quality and correctness are extremely important. While dynamic typing can theoretically be used to achieve the same level of correctness, I don’t think it’s always economical; it requires more error-handling code and there will performance costs that are only paid once on an executable (in compilation) in the static world. However, I think dynamic typing wins when the requirements are unknown or changing, rapid prototyping is essential, and (most relevantly) integration of new technologies, not always known from the outset, is mandatory. Interactivity and exploration become a core part of the development process at that point, and while every static language worth its salt has an interactive mode (“REPL”) it doesn’t have the same first-class-citizen feel. For example, Clojure’s REPL (which performs compilation of each statement) provides identical performance to what will be achieved in production, making it possible to time functions interactively.

On the static front, there’s nothing that stops the Clojure community and vision from confronting the typical commercial need set that is fulfilled by static typing, and it will. For research value, it will probably be steps behind Haskell on that front forever– Haskell’s a leader in that, and Clojure’s a leader in other things– and such features will always be optional, but I think it will meet most of the needs of typical programming. The shortcomings associated with dynamic languages are, in any case, more often cultural than intrinsic to the language, and Clojure’s culture is of extremely high quality, so I think there were always be enough awareness of those risks, and that the Clojure world will continue to produce technical assets of very high quality.

What makes Clojure– and I’m talking about the vision and community even more than the language– unique, in my mind, is that it takes a hard-line approach to both aesthetics and practicality, perhaps in recognition of the fact that those two need sets were never in opposition at all. The era in which one could “learn programming” in 6 months at age 22 and have lifelong job security are over. People constantly need to learn new things, just to survive, and that’s only feasible when newly-generated technical assets are coherent, attractive, and interactive. That, I think, is the biggest advantage of the Clojure approach to technology growth. Unlike the typical enterprise Java stack, it’s optimized for lifelong learners. That, above all, is why it will win.

About these ads

73 thoughts on “Why Clojure will win

  1. I feel very similar about Ruby, though Ruby has a *very* different aesthetic, and set of definitions of both “beautiful” (Ruby likes topic-specific DSLs) and practical (startup, not enterprise).

    I think there will be a number of different languages with precisely these attributes, but with exactly such varying definitions. That is, I think the best languages will be defined by their community, and their definitions of these words.

    • Ruby is a fantastic language, but the culture leaves something to be desired. ‘Thought’ leaders regularly dismiss the need to do design, claiming that this week’s framework has you covered, and that you just don’t trust it enough. This has weird ripple effects, such as everyone clinging to ActiveRecord, despite it’s collection of anti-features. I hate to say it, but it always feels like the ‘web dev’ sector revels in slinging code over quality, and Ruby feels like it inherited some of it.

      • Agreed. Right away you know the culture is completely different when clojurians seem to take performance semantics as a first class concern. It’s an architects language I feel – not just functional constructs that have to be cached heavily in order to achieve performance.

      • The Ruby community is essentially Rails for all intents and purposes. The Rails community reminds me of high school kids trying to be popular with a framework they don’t understand while wreaking havoc everywhere. The immaturity of the community is obvious when you look at a product like rails and as you mention the clinging to ActiveRecord. Rails is something you could pick up in 30 days (or a lot less) and have no idea what you’re doing. That’s why companies are paying people with NO Ruby _or_ Rails experience to come and clean up the messes that are likely unsalvageable. Then there’s the one or two people that actually know Ruby not just Rails, but that’s of little use despite Sinatra being a very promising framework.

  2. The era in which one could “learn programming” in 6 months at age 22 and have lifelong job security are over.

    It never existed. I was there. “You learn something new every day” is laughable: anyone who only learned one thing a day would be seriously brain-damaged.

    • What John Cowan said. To the best of my knowledge, there has never been such a thing as an entry level programming job. 100% of jobs require 3+ years of experience with a technology within two years of its introduction.

  3. Lovely post. I have same thoughts about Clojure that community and it’s energy is big thing for the language. I came to Clojure from Ruby and was amazed how open-minded and diverse community is.
    You can find people from logic programming, big data, machine learning, web development, java enterprise and other programming worlds.
    They are so well mixed together.
    I started looking at Clojure as web development language
    and after few month I know how to use core.logic, I’m amazed by things like core.typed or core.async, I learned machine learning and various big data techniques only because of Clojure. I never saw something similar before, I never wanted to be a part of something like Clojure community more than now.

    Magnificent, astonishing, exciting. Clojure :)

  4. “Clojure will be ready to go off of the JVM if it needs to do so. It is not in a hurry to make that change, but it that becomes necessary it will happen.”

    That change was necessary before Clojure was even conceived and IMO is the huge reason for its lack of adoption: it requires one to be a Java JVM expert as any JVM language does if one is to push the system to its fullest.

    “ClojureScript runs in the browser”

    ClojureScript is translated into Javascript in the browser or before. It doesn’t run in the browser. The ludicrousness of such technologies is not even worth discussing, but I’ll give it a brief rundown. Like CoffeeScript and other such bullshit compile to JS languages, the overhead alone and the debugging of javascript when one has written the original code in a totally different language make this yet another sophomoric exercise by people who like to write interpreters and can’t or don’t want to actually learn Javascript for creating useful, valuable software. Considering the performance of Javascript in modern applications is quite disappointing even on the desktop (V8 etc.) adding another layer that needlessly adds complexity (breaking the #1 rule of proper software development) is one of the most idiotic architectural decisions I’ve seen made over and over in my life. Hell, I made the mistake myself when I was a pre-pubescent teen, but one would expect professional adult “engineers” to to have more common sense, not less.

    • I believe it is the other way around. If it wasn’t running on the JVM few people would adopt it at all. I’m not saying it wouldn’t be “better” to not run on the JVM but Clojure is also about being practical. The ability to run on lots of existing enterprise systems without having to change their architecture is huge. Developers can slowly integrate it into existing systems and you can still fall back to or use java libraries if needed. No need to rewrite everything or reinvent the wheel. And the fact that it runs on the JVM makes it much easier to sell to management although it’s still hard. Otherwise it would most likely stay a language that would be used for side projects or startups.

      Personally I think Clojure is seeing some great adoption and I see more and more people using it. Most people who start using it love it. The biggest problem to me is not the JVM, it’s the fact that most programmers have a problem with functional programming and that a lisp “looks weird”. They are just too used to the OO way. It took me quite a while to “get” FP and I’m still learning a lot each day. I wish had gotten into Clojure/Lisp much earlier. The Clojure language itself is the easiest language I’ve ever used and there have been quite a few. It’s the FP part that made it hard.

      Now ClojureScript. I’d love to see it run in the browser natively but javascript is unfortunately the only supported language by all browsers. You call it ludicrous and for small javascript programs it’s complete overkill, I agree. But for large programs javascript has some serious issues. CoffeeScript and ClojureScript both compile to javascript but the languages themselves to me serve a completely different purpose. CoffeeScript seems to want to make javascript a little easier to write. Personally I’d rather not deal with javascript at all. ClojureScript brings a lot of things to the table. Just check out the new core.async library. Yes, you add some complexity to your development (compiling/debugging) but it also takes away a lot of complexity when you compare the language to javascript. I know Rich Hickey and the others want to make things really simple (not the same as easy) but that’s not always possible because of practical reasons. If you listen to his talks and to other committers you’d find those professional adult “engineers” have lots of common sense.

      In the end everyone has their own preference. I thoroughly enjoy Clojure and am using it with Datomic right now (which is a breath of fresh air as well). The community is terrific and I love the fact they have a clear vision. It makes work a lot of fun again.

      • Yes, I can see the JVM being a point for adoption at the enterprise level where Java is already used, but what about the myriad of companies that don’t use Java or the JVM at all. That’s what I was thinking of when I say that’s a huge disadvantage. Personally, I would not add the JVM to my stack unless absolutely necessary and certainly not for a language that is not guaranteed to solve problems I can’t currently solve.

        As far as ClosureScript/CoffeeScript, I’ve seen nothing that addresses any of my concerns above. They’re just unnecessary languages in a world already flooded with languages. I don’t know about you, but I know and have met very few people who can be experts in more than two languages at once and even that is a feat. Sure, everyone can program in a dozen or more languages, but to be an expert and really master a language takes years of significant, daily work.

        • I get your point, I just don’t agree on the huge disadvantage part. Even if Clojure wouldn’t be hosted on the JVM you’d still have to add another stack to your current one. I’d rather add the JVM and have the option of several languages if needed, without needing yet another completely new stack for which there’s no expertise at all to be found. In the end no language is a perfect fit for all situations. They all make trade-offs and you’ll have to decide if those are worth it or not. It’s all about the requirements you have.

          Can you solve the same problems with java/ruby/javascript or any other language? Yes, you probably can in most cases. But most of the time you need a lot less (yet still readable) and simpler code in Clojure/lisp to solve that same problem. The applications also tend to be much easier to change. The fact Clojure is a lisp dialect and that it’s all about immutable data structures, not objects, makes it really stand out for me. It makes a lot of things so much easier. And I find that I end up with much simpler applications because of all the possible abstractions. Clojure libraries also tend to be small and focused and very composable. I’m all about picking the right tool for the job. In many cases that’s Clojure for me but there are also areas where it wouldn’t even be on my list.

          As far as experts go, how many companies need a true expert in a specific language in the way that they know every little detail? Most companies benefit far more from an expert programmer who has experience with all kinds of languages and knows their strengths/weaknesses and has the ability to look at things from different angles because of it. Programmers to me are first of all problem solvers, that means knowing what’s possible in general. I’d rather have someone who knows all kinds of concepts inside and out (FP/OO etc) than someone stuck in a language. How will they know otherwise if the language itself is the problem. Writing great software doesn’t have anything to do with knowing the language itself inside and out (although it helps of course).

        • Personally I’ve found the JVM and Clojure technology stack to be easy to learn and reasonably easy to use (debugging can be a bit of a pain), and it would appear to be one of the best available (e.g. pointer safe with solid VM implementations). What do you consider to be superior technology stacks and why?

          That said, it is one of my ambitions to write a native SMP Lisp, which will almost certainly be a “Bare Metal” Clojure.

        • Coffeescript is not unnecessary. It solves a lot of JS quirks and allows writing clean code instead of bloated pure js which leads to more maintainable code. if you think I am wrong, try to achieve consistent behavior of “this” keyword in pure JS in complex backbone app and then compare this with simplicity of => operator in coffeescript.

    • [Disclaimer I work on ClojureScript]

      I’ve been writing client side JavaScript applications professionally for 8 years. Despite the disadvantages – ClojureScript offers a considerable amount of value for experienced client side engineers.

      • When those engineers leave and those client-side spots need to be filled you’ve now not only reduced your pool to the small number of front end engineers that can actually do the job, you’ve reduced it to the fraction that can and is willing to work with ClojureScript. What’s the advantage? I keep hearing this, yet I have yet to see one concrete example of an advantage. I’ve given at least half a dozen examples of why it’s a terrible idea (don’t worry CoffeeScript is the same way), but have yet to see an example of a real world client side problem that’s solved by ClojureScript that can’t be solved by JS.

        • You seem to be really focused on the ability to solve the problem. ClojureScript compiles to JS so of course anything can be done directly in JS as well. The thing is, would you want to. I prefer less, cleaner, easier to test and easier to reason about code. Yes, you might need to find someone who is willing to learn ClojureScript (or any other language) but I wouldn’t hire anyone who is stuck in his/her ways anyway. Especially with technologies moving this fast. I actually feel you have a far bigger problem if you truly need an expert programmer to maintain your code. If you can solve the same problems in a much simpler way isn’t that more important? Like you said, expert programmers in a specific language are really hard to find. What if that expert leaves? I’ve seen too many times that people pick a technology/language first instead of focusing on the problem they are trying to solve. ClojureScript isn’t the answer to everything but “it can be done in JS so we do it in JS” isn’t either.

          I prefer someone who is an expert in solving problems in the simplest way, regardless of technology, over someone who is an expert in one language and can do anything with it.

          • Yes, that’s the whole point, solving problems. There is plenty of information on JavaScript and writing it correctly. I personally do not see putting an extra layer and extra language in my stack, limiting my pool of potential candidates, rather than hiring smart JavaScript engineers. I have yet to see one advantage of such a setup with endless disadvantages.

            • If you have JS stockholm syndrome (I kid…maybe), then ClojureScript is going to seem unnecessary. Given a random JS dev and a random ClojureScript dev, I know which one I’d pick every time.

            • I’m curious, have you even invested some time in learning Clojure/ClojureScript, read about lisps and what they can bring to the table? You talk about the complexity of the stack. But you stop there and don’t seem to look any further. What about the complexity that’s being taken away? Because JS for instance is far more complex than Clojure/ClojureScript as a language. Yes, there is a lot of information on JS. That doesn’t make the language any better. You should read Beating the Averages by Paul Graham. It sums things up really nicely. For smaller applications, yes, you probably won’t benefit that much, but it adds up quickly.

              Do you use any JS frameworks? Because with your reasoning that seems out of the question as well.

              I agree with the fact that you shouldn’t add a new layer just for the sake of it. But the fact that you don’t see any benefit or advantage doesn’t mean it’s not there. If Clojure/ClojureScript only added complexity do you really believe anyone would use it? People are willing to learn FP, learn a foreign syntax (for most programmers) and have an initial seemingly more complex setup. Yet still they feel that the “trouble” of learning it really pays off in a huge way. Does anything new have to solve problems that you couldn’t solve before? Why is solving existing problems in a far simpler way not enough?

              • I’m aware of what functional programming can bring to the table, although I see it much less useful for front end work.

                I’ve used at least half a dozen JS libraries in my time. By my reasoning that seems to be the obvious good solution to most problems. In fact, code reuse is a huge part of making architectural decisions, something that it seems you have no familiarity with as you have still failed to provide an example of where ClojureScript would be an advantage rather than a disadvantage. Luc Prefontaine provided one very edge case. We are talking about code here that will run as JS in the browser still, code that can be modified by the user after all.

                I don’t know why you’d get the idea I’m opposed to libraries. That’s silly. ClojureScript is NOT a library. Perhaps you might want to find out the difference between a translator (or compiler if you wish) and a library.

                “People are willing to learn FP, learn a foreign syntax (for most programmers) and have an initial seemingly more complex setup.”

                Well considering FP consists of about 3% of all programming, a few people willing to put up with such insanity is inconsequential. In fact, regardless, this statement is still anecdotal and inconsequential.

                “Does anything new have to solve problems that you couldn’t solve before? Why is solving existing problems in a far simpler way not enough?”

                That’s correct. Resolving the problems in a simpler way is called refactoring. That’s hardly ever done despite all the talk about TDD or FP’s REPL (as if it was something new). It isn’t enough because you’re rewriting the wheel, so to speak. There are very few cases where the wheel needs to be rewritten. In fact, working code should _never_ be rewritten without a compelling reason and making it simpler, as much as that is the goal of all true programmers, is NOT a compelling reason, as any programmer with experience will tell you.

                But hey, go ahead and reinvent the wheel over and over. That’s what these communities are doing. Have fun. I know it’s fun. I’d do it myself if I could make money off of it. But remember, you’re just wasting your own time, skills, and holding back the whole programming community as a whole.

                Anyway, such idiotic topics, really don’t even deserve so much thoughtful discussion.

                • FP isn’t the same as being a lisp.

                  As far as I can tell Luc was talking about Clojure, not ClojureScript although the same reasoning applies. And I was talking about frameworks, not libraries. Frameworks also add another layer that you need to learn.

                  3%? Even if that’s the case what does that say? Since when does popularity have any relationship to being better.

                  Refactoring only goes so far. If the language is part of the complexity then you can’t refactor any further. And who is talking about rewriting? Existing problems isn’t the same as existing code. I’m talking about writing far simpler code in the first place. If I end up with less code which is easier to read, easier to maintain, easier to reason about, easier to reuse and contains less bugs then I’m all for it.

                  In the end lets just agree that we’re never going to agree. If you believe it’s a waste of time, great…don’t use it. I like opinionated people, but you don’t seem to be very open minded and very stuck in your ways (from my point of view anyway). You criticize parts of it without knowing the whole story and you’re not willing to invest the time to find out why the language can make a huge difference. I see where you’re coming from, respect your opinion, I just don’t agree with it.

                  Still, having such a discussion is fun anyway, especially if it stays civil. Too many of the discussions turn into a shouting match.

    • The value comes from the described values and concepts of the language. JavaScript is built on such a mess of principles, and further warped to no end by the years of its ‘upgrades’, that although it /can/ output good code, it requires more knowledge of ridiculous conventions and purely side effect realities to do so than actual knowledge of how it /should/ be working based on the logic of the language. (Like things that became correct because someone saw that if you do this weird trick with your hands you can run this line of code 10% faster, oh and the variables actually ended up doing what they were supposed to do too. Plus to top that off this ‘knowledge’ is passed down like some word of mouth folktale of a hero long lost!)

      ClojureScript compiles down to this painful mess from a much more coherent, logical, well put together core. You get the benefit of writing code that makes sense, that is beautiful as mentioned in the article above, and that is capable of being managed painlessly. It is writing code in a language that has an actual vision.

      • If you’re not a JS master, you have no business messing with ClojureScript or CoffeeScript or any of that shite. If you can’t deal with the whole front-end stack (which require you mastering JS), then find another job because when that fails, you’ll have to anyway (assuming you’re working on mission critical apps, which I doubt anyone here is, and you’ve made such an idiotic architectural decision). If you’re working on typical web programming you just added another layer of needless complexity as I wrote before. Finding a good front end person is difficult enough, but this seems to be a huge extension of let’s add needless components to the stack. Just like the extra “MV” layer in MVVM patterns. Well, I’d like to see how this will be maintainable when you’re just adding components for their “coolness” factor as is the trend in this sick, idiotic, and ignorant culture.

        • I totally agree with your comments. Fix the root cause, do not add a patch to conceal it. The root cause is the fact that there is an ever growing need to write applications that delivers better user experiences in a responsive manner (Single Page Web Applications) both on desktop and mobile devices. In order to do that, most of the code that existed in application server layer now needs to move into the browser such as business logic (partially), validation etc. I just finished reading Single Page Web Applications JavaScript end-to-end (http://www.manning.com/mikowski/). Although I agree with the fact that SPAs are necessary to implement responsive web applications with significantly better user experiences, JavaScript (and its runtime) is not the right tool to do that. New terms such as Fractal MVC pattern, anchor interface pattern mentioned in that book are desperate attempts to implement a command pattern in a JavaScript runtime that you otherwise would use in an object oriented fashion to implement a desktop application with a proper OO language. Now relying on JavaScript runtime to implement SPAs feels like going back to stone age to me…

          Having been in this industry for 16 years, it really bothers me to see that we are still debating engineering patterns to lay out foundations for web applications, we should have been over with this long time ago.

        • I don’t know why you put Coffescript in the same context of Clojuscript, Coffescript is pretty much just syntaxtic sugar with some built in features that compile to js , any coffeescript code that compile to JS would be perfectly readable to anyone working with, so i don’t see the point from arguing with it. You spend 10 minutes reading the coffescript wiki, and pretty much learn the whole language and do something productive with it, Clojurescript on the other hand is very different, is pretty much a REAL and full new language (Clojure with interpolate JS) that compile to js.

        • Even the best JS developer would have a very hard time coding, straight into Javascript, the JS output of a ClojureScript program using something like core.async. More so when it comes to extending the program- which could very well mean re-architecting your JS code!

          The abstraction over Javascript that ClojureScript provides can be as great as that of high-level languages over straight assembly.

    • I don’t like this talk of “wining” especially with a relatively new language. It seems disrespectful to what came before. I think Clojure enticed a lot of people in with its fancy logo and Scheme like attributes more than it’s viability as a winner. I’m not even sure functional programming will win. Math research continues on… Remember why FP was slow to take off, and still is? It’s conceptually unfamiliar to the way most people learn math in school (unfortunately) and it’s still not the all pervasive “universal” answer for scalability and concurrency that people claim. Odersky mentioned in a presentation at scala conf. that the big problem with lazy eval. is loop unrolling which makes perfect sense. So really, to go fully down the lazy route (ivory tower platform untouched obsessive compulsive) you sap up memory and reduce performance significantly. Nothing’s free, there’s a cost in there somewhere, even if it ends up being optimisation time itself and extra abstract complexity. It doesn’t really scale as people say it does when you factor in performance. It’s a convenient means of abstraction through monads, but you still need some kind of AI, to build a strategy to unroll your loops. I believe that in the future, our x86, x64 machines etc. will be respected greatly in a similar vain to how we respect our Turing machines today. It’s classical logic and the classical register based Von Neuman architecture that empowered us to even think of putting functional programming to use. Scala to my mind seems like the wisest choice – take an imperative language, make it a bit simpler and allow functional programming. It’s the harmony between abstraction and hardware. I think it’s a great research platform and the way to go.
      But again, you can’t just say that Scala should be the “winner”. Haskell on C and OpenCL is an implementation of top down meets bottom up in its own right. F# on dot net is another. And btw the latter is by far and a way, winning handsomely. It’s used a lot more than either of the formers even though it’s relatively new. I like Scala but the syntax of Clojure (lisp-1 dialect) and Scheme (lisp-1 dialect) is some how more elegant and to my mind scalable to the eye. Clojure, Scheme or lisp wrapped inside .NET or the JVM seems to me to be the sustainable route, and that’s the vision I have in my mind. Scala just seems like the perfect bridge between either of those 2 implementations. That’s why its beautiful. It doesn’t try to be too holy!
      My vision (for classical computers) of the full hierarchy on the mega scale:

      1) Assembler -> C + OpenCL -> JVM + Java -> Scala + Scalaz and/or a Lisp dialect. (->Prolog/core.logic?)
      2) Assembler -> C + CUDA -> .NET + C# -> F# and/or a Lisp dialect. (->Prolog/core.logic?)

      That’s very vaguely how I primitively see the future at least (accept skynet or Samantha might be doing all the programming in the end!), and competition is still healthy is it not. I’d personally prefer something that looked more like (1). But there will surely be a replacement for the CUDA/Open CL madness we have now. I just think the Scala crowd are geniuses at seeing the big picture. F# is genius too and is certainly winning over all other functional languages afaik (at least in high performance and big business) but Scala can match it and is a viable alternative.

      Rant almost over. I think people like the idea of timelessness generally and Math is where it’s at but computers aren’t built purely out of Mathematics. They’re machines. To me Scala is cool but it’s all good.

      My 2 cents from a CS major, not a pure Math grad.

      • It’s very hard to pick between Clojure and Scala, but I feel like it will be Clojure. Lisp should have won a long time ago. We can bypass the imperative layer entirely at the high level. Low level assembler/VM bytecodes is what we need from that. After that, functional can take over.

  5. This compile-to-JVM thing, does this mean apps for Android can be written in Clojure? That would make Android almost palatable. I have an Android phone and there’s an app I wish existed, and I’ve been trying to learn Java (at Udacity, of all places) as a means to that end. :(

      • Not exactly Gonzih. Afaik, there’s a guy that hacks the jvm so that clojure .class files are modified and then fed into the Dalvik VM. And there is a performance hit. The Dalvik VM is a register based VM whereas the JVM is stack-based. It’s a bad idea to write non java code for the Dalvik VM. Clojure fared best in benchmarks, Rhino and Scala were worse still. Clojure would need to be specifically targeted to the Dalvik VM or ART instead of theJVM to get decent performance.

  6. From my perspective, it’s exactly what is happening in my
    business domain. We are are to solving a problem for which
    “established” languages and frameworks are insufficient because
    they lack a vision and make implementation costs rise up so high that
    the whole business case crumbles under its own weight.

    I kind of agree that it may not become widely used mainly
    because not many people are willing to rewire their brain and will stick
    with tools (even crippled ones) that they feel comfortable to use.

    The added value of Clojure and it’s offsprings may very well be in
    in the nature of the problems people and businesses will tackle with it.
    Complex stuff where traditional tools are failing are now within
    reach.

    If this happens it will eventually change the way software gets created
    and may lead to a new generation of software shops much more
    performant than what you can see these days.

    It may not be as visible as seeing systematic adoption by
    the industry, it may well be through business competition and
    business players renewal and attritions. Ripple effects.

    Even if other similar alternatives to Clojure are created, it would still
    be a landmark in the software industry.

    Luc P.

      • Making medical workflow implementations across local or remote
        systems/clinics/hospitals/user groups a commodity item.

        No more huge project for each point to point integration, no specific
        code per site, … you deploy toasters each with a few knobs.

        Driven by dynamic code/data configurations
        using custom DSLs, provides semantic resolution of data,
        real time data acquisition, instant aggregation of data to remote sites,
        fully redundant and distributed, provides reusale hooks to attach
        to health system of different suppliers, …

        This is a domain were traditional development fails. Attempts
        that I have seen yields bloated code, fragmentation of
        implementations (not the same code everywhere), lack of generality
        and prohibitive implementation and maintenance costs
        Change management becomes a nightmare.

        This can be applied to an entire country health system.
        Not only a few hospitals here and there…

        The effects of a few health policies today are monitored every 5 to 10
        years because collecting the data is a nightmare, it’s on paper most
        of the time, requires months to gather, verifications have to be done on the vailidy of the collected data and eventually you may
        get some analysis done.

        Doing this using real time data is invaluable, specifically in
        emerging countries where every public penny counts.

        This is what I had in mind in my previous post :)

        • Thank you for your example. I agree that is quite important. Most applications are not like this. Yes on such cases the added complexity might be worth it. Great that’s one example but it doesn’t justify script or coffee script for the other 99% of web apps that don’t need functional programming especially on the client side. You will also still need to audit the whole conjurescript code every release, at least for security and have JavaScript experts who can work on the translator at the minimum on staff for when the security holes pop up or get a service agreement with a provider to cover such instances. Healthcare data is quite sensitive.

  7. Anyone that fails to see the value of CoffeeScript or CojureScript due to already knowing how to write JavaScript fails to realize the value of having far less code. The JavaScript I write looks almost identical to what is generated to the coffee compiler with the occasional extra guard or IIFE that I wouldn’t need to write. I can express the same amount of logic in typically 50% less CoffeeScript while improving readability because it has more sane semantics. When I need to step into a program I’d rather have 50 lines than 100 lines to reason about what the application is doing, let alone something over 1K SLOC.

    ClojureScript takes it even a step farther than CoffeeScript because you get access to a number of Clojure libraries in addition to wrapping existing JS libraries. There’s also the fact that you can reuse some of your domain from the server in the client. On most heavy client side applications you’lI end up with a redundant set of functionality/domain models on the client written in backbone or something less formal.

    These benefits alone make languages like CoffeeScript and ClojureScript worth the effort. You can always dive down to JS if needed, just like you can with C extensions in Ruby or Java, or assembler extensions in C. But when you want to reason about what a program is doing there’s no valid argument against having less code to read through, especially while improving expressiveness. Otherwise, why did we ever evolve beyond assembler?

    • Actually you have twice the code, the closure script and that you’ll have to read through and debug. You don’t even address performance or the fact that good JavaScript does exist.

      • No. You see, I do not have to debug the generated code. It is clear in the Coffee/Clojure script where the bug is and I can fix it directly. I can be as oblivious to the generated code. Even if I had to debug generated code I did not have to write and manipulate it by hand. I’m still at a higher level of expression. You seem to assume my bugs are caused by the compiler but that is not the case 99% of the time.

        I did address performance, saying you can drop down a level at anytime, but you’re assuming these compilers will generate bloated JS.

        Good JavaScript does exist. These compilers generate quite lovely JavaScript for me.

        Just my experiences from working in these langs as opposed to your assumptions from not.

      • >Actually you have twice the code, the closure script and that you’ll have to read through and debug. You don’t even address performance or the fact that good JavaScript does exist.

        I stopped taking you seriously right there. Do you count C++ as costly overhead on top of assembler code by the same logic?

  8. I think the decoupling provided by immutable data structures makes type-systems less relevant. It’s easier to sanction off chunks of your programs and understand them fully. IME, loading code into my head is not O(n) in time, so being able to mentally isolate relevant parts of code is my process bottleneck. You can do a similar trick in java by thinking in terms of interface contracts, but these borders are not as robust, reflective, or manipulable as clojure’s data approach.

  9. I agree with everything in this article, and I love Clojure, I use it as my go-to language for everything I do myself.

    The problem is there are more people like Lucian in the world that not, that see writing anything other than Java on the JVM as pointless complexity, that look at a piece of amazing Clojure and go ‘Urgh! what is that shit!’ without even wanting to learn anything about it, or try it.

    I feel that if I could get some of my colleagues to sit and what a Rich Hickey video they might be interested, by most of them would never ‘waste’ the 2 hours to get a high level overview of it, they are happy writing Java because they don’ care that something better exists.

    I write Java, Objective-C (iOS apps), Javascript and a bit of C# I am probably only close to expert in Java, but I can still write perfectly fine iOS apps and hack together some windows UI in C#, but some people won’t use any language in production they are not ‘expert’ in, so the small number of colleagues that might enjoy Clojure would never actually get around to using it in the real world.

    All of this makes me sad and is the reason (from my point of view) that Clojure will never take off, forget about convincing management, I can’t convince any developers!

    • This is a real problem, but has little or nothing to do with Clojure per se. There’s a large class of programmers who learn a certain skill set, and then stick to that until they’re forced to do otherwise. Given the age discrimination in this field, which they are a legitimate cause of, that’s often a forced exit from the field, although it could take a long time, it’s been observed Java is the current COBOL.

      So I take them to not be not interested in Clojure, but not interested in any alternatives to what they’ve learned.

      Depending on the field this can also be self-correcting; Paul Graham pointed out this WRT startups in Beating the Averages:

      […] Software is a very competitive business, prone to natural monopolies. A company that gets software written faster and better will, all other things being equal, put its competitors out of business. And when you’re starting a startup, you feel this very keenly. Startups tend to be an all or nothing proposition. You either get rich, or you get nothing. In a startup, if you bet on the wrong technology, your competitors will crush you.

      Robert and I both knew Lisp well, and we couldn’t see any reason not to trust our instincts and go with Lisp. We knew that everyone else was writing their software in C++ or Perl. But we also knew that that didn’t mean anything. If you chose technology that way, you’d be running Windows. When you choose technology, you have to ignore what other people are doing, and consider only what will work the best.

      This is especially true in a startup. In a big company, you can do what all the other big companies are doing. But a startup can’t do what all the other startups do. I don’t think a lot of people realize this, even in startups.

      The average big company grows at about ten percent a year. So if you’re running a big company and you do everything the way the average big company does it, you can expect to do as well as the average big company– that is, to grow about ten percent a year.

      The same thing will happen if you’re running a startup, of course. If you do everything the way the average startup does it, you should expect average performance. The problem here is, average performance means that you’ll go out of business. The survival rate for startups is way less than fifty percent. So if you’re running a startup, you had better be doing something odd. If not, you’re in trouble.

    • “All of this makes me sad and is the reason (from my point of view) that Clojure will never take off, forget about convincing management, I can’t convince any developers!”

      I hear you. It’s tempting to blame the anti-intellectualism of the software world on businessmen (“MBAs”) and them alone, but there are a lot of engineers who are just as useless. We end up in this negative position (business subordinates instead of makers) because a lot of us aren’t good for anything more, and businessmen (unable to evaluate us) see those CommodityJavaDrone types as “good enough”.

  10. I think the discussion around static typing was interesting and good, but it is not at all clear to me that Clojure will win over, say Haskell in the long run.

    Haskell is built on a stonger foundation than Clojure. I love Clojure as a step up from Common Lisp which I also love.

    However, as stated in the article, Haskell hands down gives stronger guarantees and thus less bugs.

    You write: “On the static front, there’s nothing that stops the Clojure community and vision from confronting the typical commercial need set that is fulfilled by static typing, and it will.”

    I think this is too low a bar to aim for. In order to be productive, we need to be able to express ourselves using great abstractions that do not introduce bugs. FP is a set of such abstractions, but Haskell-level type systems is complementary.

    As you probably know, GHC, *the* haskell compiler has a REPL and declaring types are optional in Haskell (they are inferred).

    My feeling is that languages such as Haskell which has the foundations right but lots of warts in other areas (the build system, IDEs, sluggish compiler, needs more super high quality libraries) has a better long-term shot at making it.

    I think 3-10 really stellar libraries are being built for Haskell each year, libraries that enable high performance abstractions that are amazing. This is what clojure competes against. While it can mostly compete on the library side and on elegance (because it is a lisp), it cannot compete on the type system side. I don’t think that’s good enough in the long run.

    Basically I don’t think you give much in way of examples where exploratory programming is hard in Haskell, nor that there are compelling examples of programs that cannot be written because of the type system.

    Regarding the latter point, programs that cannot be written because of the type system, I will say that those problems are usually at the library level. For example when a fluent way to convert a typed structure to JSON, or when typed SQL is needed, a library that includes the required level of type trickery will be provided by an expert.

    I don’t see many examples where the type system stops normal higher level programs from being expressed by normal programmers.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s