The other thing I think is worth considering in a move to Clojure is how different functional thinking is. I mean, if you're used to moving between C and Perl and Python and PHP and Java and Javascript and so on, you're used to language transitions within more or less the same paradigm. It feels like a categorically different problem to try to transition a team from one of those to a functional language.
They lay out a couple of algorithms in an imperative style, and then gradually morph them into a functional style. It's pretty wild: you go from a story, "do this, then do this, then do this" to a math problem: "your answer is a list composed of f() of g() of h() of another list". (Unfortunately you only get snippets from that link -- it's worth the money to get the whole thing if you're interested.)
Anyway, having followed through their examples and done some of my own Clojure programming, I ended up not so convinced that people who are good at solving story-style imperative problems will necessarily be good at solving math-style functional problems. It felt like a different part of my brain.
This is not at all a reason not to dabble with functional languages, just a potential pitfall to be aware of if you're thinking of bringing a whole team over. And maybe I'm overstating it? I haven't dabbled too much myself.
Anyway, having followed through their examples and done some of my own Clojure programming, I ended up not so convinced that people who are good at solving story-style imperative problems will necessarily be good at solving math-style functional problems. It felt like a different part of my brain.
When you're coming to a new paradigm which is completely different from what you're currently using, then of course it will initially feel hard/different and that you're using a different part of your brain. That doesn't necessarily mean that it's harder for you to program in a functional style, it just means that you're more experienced in imperative programming.
"C and Perl and Python and PHP and Java and Javascript and so on, ... It feels like a categorically different problem to try to transition a team from one of those to a functional language."
I just have to throw a flag here and point out that Javascript is also a functional language. With Javascript you can declare functions as variables, pass functions as arguments to other functions, return functions as the result of other functions, and use them as part of a data structure. Javascript is much closer to Scheme than it is to a C paradigm.
Well, you can pass around function pointers, return function pointers, and store function pointers in data structures in C, too. You can also use closures - a closure is just a (function pointer, struct with its closure values) struct. Sure, OCaml, Scheme, and company box the pair for you, garbage collect it, and don't make you flatten your code into a single file-level scope, but the difference between Javascript and C isn't as big as you think.
Javascript is kinda sorta maybe functional if you look at it right, but it's still mostly the same imperative/object-oriented mishmash as Java, Python, or Ruby.
Indeed. I'd certainly rather be able to nest functions, but C became a lot more powerful to me after I learned how to compile a bunch of high-level features to it. (Your 'ichbins' helped, by the way. That, LiSP, and some SML papers.) I'd still rather automate much of the heavy lifting, of course.
I'm weirded out by the idea of writing CPS-transformed code by hand for node.js, but apparently people like it? Perhaps it's something similar.
The thing I don't get about node.js is that it used to have a promise abstraction and they dropped it to go callback-only. I guess the abstraction leaked, in a language not built around it?
I like to imagine Node's success comes from bringing some of E's insights to a community just ready to use them, and if the cost is manual CPS, apparently it's not too high.
(Relevant E theory at http://erights.org/elib/concurrency/overview.html )
There is a distinct difference between languages designed around the functional paradigm (Haskell, lisps etc), and languages that support the functional paradigm (python, javascript etc). Most javascript code is imperative, not functional, and it would be disingenuous to say that there is not a difference in the way of thinking when writing in lisp, and when writing in javascript.
> With Javascript you can declare functions as variables, pass functions as arguments to other functions, return functions as the result of other functions, and use them as part of a data structure.
I'm pretty sure you can do all of those things with function pointers in C. void (*func)(void), for example.
"With Javascript you can declare functions as variables, pass functions as arguments to other functions, return functions as the result of other functions, and use them as part of a data structure. "
I'm not sure if focusing on syntax and succinctness is such a great approach though. When I've discussed Clojure with colleagues familiar with Java, they've been more interested in the concurrency support via immutable data structures and reference types, which really sets Clojure apart from other Lisps. I think it's a much more compelling sell that way, since Java programmers seem to be attached to Java's syntax and static typing, but are aware of how difficult it is to write correct concurrent code. YMMV of course.
I agree. A good way to sell Clojure to an experienced Java programmer is to ask him has he ever serialized data to a string for passing it around in a program, and why. Then when he explains how the semantics for all the composite Java types except for string suck, tell him that every type in Clojure just works right, like string does in Java.
Why would anyone do that? We use immutable collections, immutable value objects, unmodifiable views and deep/shallow copies, but never serializing data to a string just for passing it around. I think most experienced Java developers would go for the type-safe alternatives.
> I'm not sure if focusing on syntax and succinctness is such a great approach though.
Depends on the audience I'd guess, considering bug-proneness is an almost direct function of LOC (at equivalent skill levels) it can be a pretty interesting note.
Though I'd agree that concurrency prowess should be higher on the list, especially in SOA companies.
Sure, i's an interesting note, I just don't think one should lead with it. For instance even as someone who's a fan of Clojure, my immediate reaction to the example with Map<String, String> was to think "that's not really equivalent since the Java example is more typesafe". I just think it might invite unnecessary digression, especially since Java programmers have been hearing about more concise dynamic languages for years.
It's definitely hard to sell a new tool based on an intermediate advantage (less LoC) alone. You have to sell the whole package (of experience).
When Rails came out, it offers more than just RAD for building web but it also offers integration with the 2 most commonly tasks in building web-application: DB migration and Automated Testing. That strikes to the heart of any type of applications be it enterprise or one-man-show.
Ruby community can't sell Ruby because of its syntax alone by saying that it looks like English (keep in mind that Ruby was invented somewhere in the mid 90's era and didn't exactly known until Rails).
We're seeing the same trend here: promise of concurrency. I also would point out "leiningen" as a build/packaging tools as part of the selling point: there are some portion of Java developers that would swear by Maven (including me, despite its quirkiness/complexity) as the killer app/framework/tool for Java. Leiningen fills that gap for these individuals.
I made a similar presentation a year ago to a bunch of fellow quants at the bank. I chose Scala, and my presentation was mostly code. Quant Finance tends to be one of those areas where Scala really excels. For example, a time series is just a running fold. So instead of having an imperative for block with various indices & guards, you can write a 1-line prefix scan to price a 5 year CDS. My examples also included bond pricing, vanilla calls and puts, binomial trees, monte carlo generators, portfolio optimization, risk calculations ( VaR & CVaR ) and a few graphics. My manager was very open-minded when it came to technology choice, and my fellow quants were somewhat tough on the 2 hour presentation, but the end result was what I believe is called a win-win. We've since pushed a bunch of apps coded in Scala into production, and the group has embraced the language quite enthusiastically.
An awful lot of finance (that used to run in Excel) is just side-effect free, compute-centric transformations over data. Time series, for example, have a relatively nice algebra that makes it easy to manipulate in terms of maps, scans and folds. And anything that makes it easier to avoid off-by-one errors is a big win, especially if your traders and quants aren't trained software engineers.
>An awful lot of finance (that used to run in Excel) is just side-effect free, compute-centric transformations over data
true dat.
For example, in Excel, checkout PV ( Click on Formulas->Financial->PV )
Given a $1K@par 10Y bond paying $50 annual coupon at 2% interest, Excel says the Present Value (PV) of the bond must be $1269.48
Getting rid of the fold produces the list of discounted coupons and the discounted principal...just a trivial teaser example, but most quants look at that & go, wow if you could do all that in 1 line, imagine the possibilities if you are pricing a mortgage with tranches...you could get rid of 4 page spreadsheets & replace with a paragraph of straight math & it would just work...and they'd be right, too.
For offline analysis, I'd eagerly agree.
But have you had any success with FP for online analysis? E.g. you have 100 time series updating every second, and must yield some other series and events.
An eager functional language would probably die here, but it seems like a fine fit for a lazy one: compose a list of the other series/events as you scan.
What about datasets that don't fit in memory? How can a functional language deal with those (let's say we don't want to use a database)? Lazy sequences?
I mean, I loved clojure when I tried it out, I just do not know if I can use it to process data as with other languages with really good libraries (python, for example).
Clojure is very lazy about computation and the loading of values. You can work with sequences of infinite size. Lazy sequences are actually the default.
As to processing data like you would with other really good libraries... if you want to do it like that you can. Clojure gives you easy access to Java.
I moved from C++ to scala for my Quaint work and I have been nothing but happy. The other fun thing to use is Akka for easy migration to multi-threaded code. Nothing like generating a bunch of Futures and then collecting the results. I was able to process two quarters of tick data as part of a test routine simply because I had the cores and an easy way to excersize them.
If I was manager wanting to decide on a substantial technology change like Clojure with a presentation like that I'd have to answer "no". It doesn't answer some of the most important questions:
1) What level of support is there for the Clojure toolchain? Is this likely to be around in 5 years from now?
2) We are going to need to hire programmers in the future. Are there people with Clojure skills (or those that we can cross-train) around? In our geographic region? At the price point we can afford? In 5 years from now is it likely that this is going to be a marginalized technology that we have trouble finding skills for?
These are the more important questions, not how succinct the language is. I've had first-hand experience of how technology choices affect companies and it can be very painful down the road.
(Note: this isn't intended as a dig at Clojure, you could replace it with Scala, or any other up-and-coming language choice.)
While I wholly sympathize with your rather pragmatic pov, technology is not a staple industry like agriculture or the diary business or the furniture industry. It is more like the fashion industry. You have to be a bit of a visionary to succeed in this trade.
>Is this likely to be around in 5 years from now?
In 1997 when I graduated, career services told me to erase Java from my resume and replace it with "Borland C++ OWL 2.0" so that I could land a job. (http://en.wikipedia.org/wiki/Object_Windows_Library) At that time, Java = dancing duke on netscape navigator. Right now, I'd give a million dollars to find another OWL 2.0 developer ( ok not a million, maybe $10 )
>5 years from now is it likely that this is going to be a marginalized technology
5 years == light years in tech. Nobody can predict that far out.
>it can be very painful down the road.
If you future-proof yourself by only using the most stable, well supported toolchain, it can be much more painful down the road when you are stuck with some legacy platform nobody is willing to code in because everybody has moved on to the next big thing.
>you could replace it with Scala, or any other up-and-coming language
There should be a statute of limitations on when you can stop using "up-and-coming" w.r.t a language :) Seriously,Scala has been around in some shape/form since 2003. We've had stable releases since 2008. At this point it is no longer "up-and-coming".
I surely can predict that in 5 "light" years C++, even C, will not become obsolete. I know of a very innovative company which still uses almost exclusively Visual C++ 2008 (they do some heavy image processing and OCR).
> I've had first-hand experience of how technology choices affect companies and it can be very painful down the road.
I've had the same experience. A couple of years ago we decided to implement a rather large part of a project in JRuby (the other part was written in Java), because it seemed to be the right tool for the job: a scripting language that can interoperate with java libraries out of the box.
In retrospect it was a bad decision, because the interpreter error messages were (are?) cryptic (at least compared to what you get with Java) and IDE integration was really, really bad. Cross-language re-factoring was broken and we ended up unit testing almost every line of JRuby code to make sure we didn't introduce regressions when making changes to running systems.
There's a part in Peopleware (http://www.amazon.com/Peopleware-Productive-Projects-Teams-2...) where the authors describe that the choice of programming language has almost no impact on the success of a project. So why add additional risk when there's no proven benefit?
Edit: Also, people always argue that they can get things done much faster in "esoteric" languages, but forget about the time spent on maintenance, bug fixing, explaining code to new colleagues, ...
> We are going to need to hire programmers in the future. Are there people with Clojure skills (or those that we can cross-train) around? In our geographic region? At the price point we can afford?
I think this common perspective is a little misguided. Programmers retrain fairly easily, inexpensive recent graduates doubly so. With JVM languages, it's particularly true, because the overall environment is so large compared to the language, and all that comes over for free.
I don't really understand the business world's preoccupation with 5 years of experience. My experience has been that some programmers "get it" right out of school, others never get it, some continue to improve into their 60s and beyond. Experience levels correlate strongly with desired starting salary, but not with skill or ability to learn.
> In 5 years from now is it likely that this is going to be a marginalized technology that we have trouble finding skills for?
Lisp was a highly marginalized technology for a few decades there. No doubt you could scour résumés at Monster.com all day and not find anyone who had bothered to put it down. But nobody who actually tried to hire Common Lisp programmers had much difficulty finding them or paying them, because of the prestige. Very few languages seem to enter an actively-hated state (Cobol and Mumps being obvious exceptions); the rest enter disuse and we programmers get all misty-eyed for them.
In short, this is one of those "obvious" business fears that turns out to be completely irrational.
On the flip side, where I work, we use Java 6, JSF 2 and Hibernate: industry standard stuff. Nevertheless, we've been able to fill only one of three open positions in the last three years, after multiple month searches. The size of the labor pool is usually not the limiting factor: in our case, we are in the middle of nowhere and offer below industry standard compensation (though it's very high for the region). Where you are, what you pay, what the benefits are like, what you work on; these kinds of things are going to have a much more dramatic effect on your ability to find developers than simply choosing an off-beat language. Plenty of recent graduates would rather work for less money on interesting problems with desirable tools.
Just a quick note: from personal experience, I've been a lot more productive in Clojure than in Java, and I have written a lot of Java code. Things like the REPL, STM or FP speed you up a lot, I would say by a factor of at least 2 - 3, maybe more. I have no data to back it up but this is my perception.
So hiring one programmer instead of 3 and paying him 2x more is already good for you.
When I switched from C to Java, I experienced a considerable bump in development speed. Just the collections framework was a godsend, not to mention things like GC etc.
Quite literally I would write things in days instead of weeks. Same thing goes for Java -> Clojure. And just to be clear, it is not my favorite language.
Funny story. I programmed briefly in C and went to Java. I had almost five years of experience there. Due to circumstances, my sister now needs some help coding some stuff in C (note these aren't same types of problems I had). And I noticed that I am now so much more productive in C compared to what I was before. Hell I make less mistakes than in Java (granted problems are a bit easier).
My point is - are you sure you just aren't better programmer overall and attributing that (somewhat underservedly because GC and a huge choice of collections) to Java/Clojure/<insert language>?
Partly, sure. If I had to write some C again I would surely try to do it as functionally as possible, and with the added experience I have gained in the last years I would now probably be a better overall C programmer. But had I sticked with C and not moved on to other languages I probably wouldn't be much better now than I was before.
I'd hazard a guess that this had less to do with java and more to do with your lack of c experience. collections in c is a solved problem, there are numerous libraries (glib, for example) out there that are all similar to Java's collections.
C++ has stl with many of the same collections, and if you want to use auto_ptr, you don't even need to remember to call delete.
I am not saying there are not productivity gains to be had from using java, but as in this case, it typically comes from not having the relevant experience elsewhere.
Automatic memory management, instantaneous compilation, no portability issues, (easier) polymorphism. Maybe weeks -> days was an overexaggeration when it comes to C -> Java but I definitely experienced a big productivity gain, and it wasn't because of a lack of C experience.
From a quick glance at the docs glib looks good but it is still too low-level for normal app development (for example, the size of a hashing table created by hcreate() is fixed; so you have to create & copy & destroy a hash table if you want to add more elements than it can hold at a time) and it should be, that's the whole point.
However, it's also widely held that individual programmer ability and the cultures of certain groups can have even larger affects on productivity.
Switching languages is hard. Managing groups is hard. Dealing with the rest of a large organization is hard. If a group can do fine without switching languages, why would any manager be in a hurry to do it?
But you're depending on 1 programmers instead of spreading your risk into 3 different developers.
Lots of angles to consider not just in terms of monetary. Human's behaviour/attitude/mindset is a very large unknown despite however hard we tried to make a "human" as static as a "resource".
Sure, but a 3x faster programmer will still be more efficient than 3 other programmers, because there is no communication overhead and opportunities for misunderstandings.
I would rather hire somebody really good for $6k / month than 3 people for $2k each.
Maybe you don't want to replace three java programmers with one clojure programmer, but it might not be so bad to replace fifteen java programmers with five clojure programmers.
I would definitely agree with all the advantages of having less (less people to manage, less communication, less lines of code) provided that you can find the ideal situation.
But alas, finding the ideal situation is like winning the NBA Championship trophy: you need all the stars to line up including "Lucky" star.
Clojure and Java aren't really direct competitors. The appropriate comparison is to Python, Ruby, or Perl. I strongly doubt there would be a 2-3x difference in that case.
Personally speaking, even though I really wanted to love Clojure, I was forced to conclude that Python is more productive.
Well, it depends. For example, look at core.logic and show me something comparable in Perl or Python. The ability to just code up a DSL in no time, with the same syntax as the rest of the language is a really powerful tool, and I've yet to see a language that comes even close to Lisp's metaprogramming support.
Python has logic programming (Pyke). But, in principle, yes: you can't add new syntax to non-homoiconic languages. You can use macros (even C has macros), but they are more limited in a nonhomoiconic language.
In my experience, though, metaprogramming is of limited use as anything other than syntactic sugar. And it often leads to very confusing code.
Other language features are far more fundamental and important: libraries, good integration with the shell, coherent error messages (!), readability, tooling, deployment, etc. As a language Clojure is beautiful, but as an ecosystem it has very far to go.
I'm not aware of many non-Lisp non-Prolog logic programming libraries like core.logic. core.logic can trivially operate on the terms of language which it is defined in. Meaning core.logic itself can be used for metaprogramming.
In my experience, metaprogramming is a wonderfully powerful utility for controlling complexity and confusion.
As far as the ecosystem - I used Python for a couple years, it's good. But the Clojure ecosystem is doing pretty darn well itself these days.
Theses are really common questions to ask and we already know the responses.
But are you asking the right questions?
Your hypothesis is that anybody suffiently trained is enough and it is easy to scale by having more people.
This work well for contracting companies that effectivelly sell people and not really care about the software. Their model is totally scalable: they revenue is mostly dependant of the number of people billed. And too much productivy is more a nuisance. They just need not to be worse than other contracting companies. So do the same as everybody else, be sure to have low operationnal costs and you are fine.
But from the software side, this is the opposite. Software don't scale. The bigger the code base, the more it cost to maintain. Too many people working on it and too much turnover and your team start to spend more time in meetings, politics or helping newcomers than getting things done.
As a manager, while this is far more satisfactory to manage bigger teams, your role is to empower your team so it can do more with less. And any tool that can give you an edge is a huge asset. If a better programming language mean more productivity, use it. If a better SCM can help, use it! If faster computer ensure that your devs stay in the zone, buy them.
That the point here. You can do more with a good team of 10 people than with an average team of 50 people (where 10 peoples will be consumed just to manage others).
To the OP: If you have to take a cheap shot at Perl in order to demonstrate the benefits of Clojure, then you have failed.
For the record, I am not implying that Perl is above criticism. But, showing a single arbitrary perl code segment, and touting that Clojure doesn't look like it is not fair comparison.
He was anticipating the argument that succinctness leads to unreadable code. Perl is a language where you can choose to be so terse as to be nearly unreadable.
I don't think he was trying to claim that was idiomatic perl. Rather he was saying that clojure is succinct and still very readable.
If he chose his example without consideration of idiomatic Perl, then his attempt appears even worse. Further he chose to remove all spaces from the example, presumably to demonstrate that Perl code is "not clear".
I have not written a single line of clojure, and don't know how idiomatic clojure looks like. I tried to translate his example to clojure using my very limited knowledge and looking at the examples on ClojureDocs site:
I am sure this is not idiomatic clojure, and probably a very bad way to write. If I cited this as an example of typical clojure code, then I'd be making a totally unfair judgment.
The funny thing is, when I just add spaces to the Perl code segment, it looks quite readable to me. But then, I probably know more Perl than him.
I did not paste the Clojure example from anywhere. I wrote it. It was not intentional on my part to write broken code, but if it was, it actually nicely illustrates my point.
"He was anticipating the argument that succinctness leads to unreadable code"
And it's a valid argument. There's sometimes a tradeoff between terseness and readability. Of course, readability suffers if the code gets too verbose as well.. go figure.
"Perl is a language where you can choose to be so terse as to be nearly unreadable"
You can actually choose a "level" of succinctness that fits the task at hand and your personal style. This is a very cool feature of Perl that it should be praised for. I agree with GP that the OP intentionally misrepresents it.
The Joy of Clojure goes into to Clojure philosophy and explains the "Why?" of Clojure. Clojure Programming is divided into five parts, and parts III and IV provide a good overview of how to set up your environment and structure projects.
But the best book for learning the language is Programming Clojure (http://www.amazon.com/Programming-Clojure-Stuart-Halloway/dp...) by Stu Halloway. Stu works alongside Rich and understands Clojure at a deep level, but he's still in tune to the beginner's mind and is able to clearly explain concepts and provide the context you need for the ideas to resonate.
I haven't read through 2nd edition of Programming Clojure yet, but comparing it and Joy is silly IMO, as Joy is built around the idea of being the book you read after you understand the basics of Clojure as taught by one of the other two books mentioned (or other resources).
Joy is the one book I consider a necessity to getting a deep understanding of the language without spending as much time as you might attempting the same understanding on your own.
I disagree, I found joy to be a much better text for learning than halloway's book. Halloway's book didn't have as good a flow from one section into the next and felt more disjointed
I haven't read Halloway's, but I found the O'reilly book much more helpful for learning Clojure than The Joy of Clojure. They're both great, but I'd definitely read the O'Reilly book before Joy.
Thank you for pointing these amazing resources. I've had the fortune of being able to borrow The Joy of Clojure from my alma-mater library and I was surprised by the size of the book! Maybe there's life after Java after all!! :D
I really like some of these languages. Clojure is something I've worked with but haven't built a complete product from, but I'd like to make something standalone.
I just wish there was a single website devoted to re-creating the terribly boring "Employee Directory Website" app in each language of choice.
It would be even better if the creators of said language would go through the time to make the example site so I could see how they imagine a CRUD layer working, or sessions, or REST/XML data, or the sql connection.
For every "new" language it seems I can find a hundred examples of fibonacci sequencing (or more recently everyone seems to enjoy creating 'twitter in 5 lines of code!') but almost no real "boring web stack" examples.
There are quite some interesting web apps implemented in clojure.
Build web app with clojure is where clojure shines.
I've built a few, some are for the company which pay me. One for myself, the source code https://github.com/shenfeng/rssminer. You can have a look, It did the things you mentioned
Many of these presentations come across as proselytizing. It's an immediate turn-off to some developers and most all managers. The proselytizer claims to know or be able to understand things that others on the team cannot. It's condescending. You wouldn't say to a co-worker... "I understand why we should use X, you do not, so I'm going to enlighten you and explain this to you in a way that you can understand and see the benefits of."
The best way to gain traction and to get others to use your favorite tools is to write code and implement projects on time and under budget that are reliable and easy to maintain. If you do that, then the tools that you use will be in demand. Others will want to use them and they will speak for themselves.
Pretty nice intro / advocacy piece for Clojure. I have high hopes that once we're flooded with more example code people will start to see the simplicity of Clojure. Right now the reference is somewhat terse, but you can dig around GitHub quite a bit which is nice. Also, it seems that the combination of people working with contemporary problems and small and succinct generics that you wind up making in Lisps, there could be a lot of great reusable code for this language out there soon. I'm also curious about http://www.collaj.net/ ... the Redfoot project for RDF / Python seems to remind me of this... that we're not paying enough attention to the "Google / Paste / Execute" loop.
This may seem superficial, but Clojure's usability is a problem. The source-code itself is hurt by the same thing that makes it strong: homogeneity. Even at a superficial level, skimming with the eye, closure code looks strange. It is exactly the same problem that markup that is all divs has when compared to markup that uses common top-level markup. It's hard for the eye to pick out what's important, and what's going on. In addition, indentation rules are not agreed upon and it's a bit stutter stop. (I actually think this is a worse problem then the "inside out" problem).
Aha! I just had a really good idea! Let's call it "Clojure folding". It's like code-folding only instead of hiding lines, you pull up all the code into one line. Some of the internals may be elided - and revealed with a tooltip.
I also like the idea of coloring the entire content of the parens, so that you can embed a large item and then clearly see that you are now back in the containing list. Indentation doesn't do a good enough job, nor do rainbow parens. Further, you'd get a good intuitive sense of place in the code if you have a consistent series of colors. Emotionally, you'd know that if you're typing read you're like 6 layers deep - and that's really deep, in the danger zone, and you probably want to pull some stuff out into definitions.
Chris Granger, feel free to include these ideas in Light Table.
We have been using Clojure for a product for about 9 months now, and in my experience, I have no trouble identifying what different blocks of code do. It may depend on proper syntax highlighting, but I think one of the keys is that there is so little boilerplate in Clojure that all of the code is important. You're not skimming over getters and setters, assignment of constructor parameters to the object, or some of the other things your eyes tend to automatically skip when reading, say, Java or Python. It tends to be pure logic or pure data, with very little else in the way.
These seem like standard criticisms of lisps that have been raised for decades. I dont know the responses or solutions, but surely they exist in abundance on the interwebs.
Clojure keeps looking more and more interesting. Noir, in particular, has caught my eye. Anyone have a link to a high-quality Noir tutorial? (high-quality in the sense of straightforward yet useful)
Nice article, BTW. Good intro for those not familiar with Clojure yet.
I gather you've already seen these? http://webnoir.org/tutorials They got me started, and then I went to the Hiccup docs (https://github.com/weavejester/hiccup/) for more detailed information. I have yet to find a more comprehensive walk-through but I'll post again if I find one.
Interesting article, but its only skin deep... The larger issues are down the road, it's where the engineers and the sophomore programmers are separated.
I really like Clojure as a language, but the JVM implementation takes over a second to start. This lack of responsiveness makes it a poor choice for many small scripts that should run quickly. If not for this issue, I would probably use Clojure on a regular basis.
Although you could argue the .NET CLR is also optimized for long-running applications, because it's directly competing with Java. Why is the CLR so much quicker?
For interests sake, I typed "java -version" on my new MacBook Pro now and it took 0.9 seconds. Second time it took 0.11 seconds. It's still unacceptably slow, in my opinion.
I can't agree with you more. I love clojure. We have done some projects with clojure. But clojure start slow, which make scriting with it a very bad idea. As an example one of our team member write this: https://github.com/killme2008/clojure-control. we use it to manage many machines remotely, wich is a pain. We used to use fabfile to manage them, with is much better.
One solution (a little awkward) is to keep a warmed-up JVM in the background, and have your scripts send the arguments to it. Some trouble to setup, and of course the send-code can't be in Java... but it is lightening fast. I'm not sure why this isn't a more common practice: if there was a standard server and (non-java) client, it wouldn't be awkward.
Almost certainly. You could go on: would it be faster written in C? In ASM? The question shouldn't be "can it be faster," but rather "is it fast enough?"
If you're worried about clojure not being fast enough where java is, you've always got the option of prototyping in clojure then dropping to java via clojure's interop where you have to.
A clojure program written in "canonical" style will usually be slower than the equivalent "canonical" java program (as long as canonical != enterprisey canonical), if only because canonical Clojure uses immutable datastructures and therefore spends quite a bit of time churning memory but Clojure lets you type-hint programs (to generate more type-tight bytecode, closer to what statically typed Java would provide), use Java mutable types and alongside compile-time metaprogramming that can be used to generate code which will likely be as efficient as tight Java code: http://www.learningclojure.com/2010/09/clojure-faster-than-m...
A bigger drawback to Clojure, in my experience, is that error messages are complete shit (most errors will yield stack traces to compiled bytecode, so you get java traces with a layer of obfuscation in that they're tracing the bytecode generated by clojure). The same issue exists when trying to improve performances, you get performance counters for java bytecode and have to match them to clojure code "by hand".
You may know this, but Clojure's immutable data structures don't spend near as much time churning memory as they would if they were implemented naively. Change one element of a sequence, and in your new sequence all the unchanged elements will reference the same memory locations they did before.
Sure, but you'll still need to reallocate all the tree path leading to the changed value, there's only so much immutable datastructures can share. And this does result in signifiant churn compared to an object/imperative system where most of the manipulations mutate existing objects (with very little allocations or deallocations comparatively).
I'm going wax poetically and say that there are a lot of things like GStreamer or the Javax stuff that's just going to be another library, and depending on what you're doing in Clojure it will run just the same. If you're designing something where your processing is happening with Clojure, it depends on how the JIT observes it and optimizes it, so mostly that stuff might be slower, but it also might be the same. Now, if you're really trying to push things, you could be doing all of it on the GPU, in which case it doesn't matter what language you use, your code on the CPU is just going to be uploading or otherwise managing the GPU work, so using C++ to do such things might not even matter given that the GLSL or whatever you're doing the GPU is compiled and running over there anyway. But as far as Clojure speed goes, the general feel I get is that it's generally slower than Java (for say a single thread, and especially interactively with the REPL) but still faster than C Python, but it also may surprise you with its transparent threading.
For most tasks, it's slower, but within the same order of magnitude. Performant processing of numeric data, however, requires quite a few ugly hacks (just like almost all functional languages).
Purely numeric operations in recent Clojure releases are unboxed, meaning primitive arithmetic executes the same way as it does in the JVM. There are several tricks for removing the overhead of dynamic function lookups, so function call overhead can be roughly the same as Java's. You also have access to Java arrays, including primitive arrays.
So, in theory you can write Java-in-Clojure and see similar performance between the two, as the just-in-time compiler will not be doing any more work for Clojure than for Java code. In practice, the code will not be as attractive as plain Clojure.
I was thinking of the same thing a few minutes ago, and for some tasks I think one is better off with Java (IMHO, I don't even do much Java - its just the C/Java style wins in some cases - I'm thinking of code with many array acesses).
But as a high-level language for high-level tasks, for gluing pieces of code and calling libraries all around and for dynamic chancing stuff like web programming, Clojure really shines.
I do consulting for small businesses around where I live (Mexico). And since like 3 months ago I switched to clojure and I couldn't be happier. I used ruby then python before. Now there is one minisupermarket doing billing and inventories and backups and charging customers with clojure in Mexico and that number is looking to grow!
Learn Java first before learning other JVM languages: one of their strengths is interoperability with Java libraries.
If you want to learn functional programming _for its own sake_, learn Scheme (Little Schemer, SICP, Seasoned Schemer) , ML (either OCaml or SML would do), and optionally Haskell.
Common Lisp is worth learning, but majority of Common Lisp code is not very functional: idiomatic Common Lisp code readily takes advantage of cons cell mutability and uses do/loop macros; macros and CLOS are the salient feature of Common Lisp that are worth knowing about.
I'm looking to expand my knowledge range and open a few more doors to different areas. I currently am fairly proficient with python, php, mysql, dhtml. Java seemed like a natural progression especially since I'm interested in mobile phone development, but I'm also interested in the strengths of the JVM and Java's libraries.
If you're getting into mobile phone development (likely Android), then you should start with Java. I think some people have managed to compile/run clojure to run on Android, but there are still some performance hurdles that will need to be overcome (true for dynamic languages running on Dalvik) before it becomes a viable language for mobile.
If you want to learn for the sake of expanding your knowledge range, Java is a pretty bad choice; there's very little that's novel about Java. The two advantages it has over Clojure right now are are 0) it's much easier to find employment in and 1) Clojure isn't yet suitable for Android development.
I used Clojure and now I'm using a little bit of Java (and reading Effective Java) and I'm pretty glad I'm doing so: interfaces, generics, concurrency, data structures, mutable vs immutable objects, etc etc: most I just ignored when programming Clojure... and they are interesting to know IMO.
(I intend to return to Clojure/Python on the next project because Java really makes CRUD style web programming a PITA).
I'm thinking in particular of this section from O'Reilly's Clojure book: http://books.google.com/books?id=I8KdEKceCHAC&ots=wNiLN6...
They lay out a couple of algorithms in an imperative style, and then gradually morph them into a functional style. It's pretty wild: you go from a story, "do this, then do this, then do this" to a math problem: "your answer is a list composed of f() of g() of h() of another list". (Unfortunately you only get snippets from that link -- it's worth the money to get the whole thing if you're interested.)
Anyway, having followed through their examples and done some of my own Clojure programming, I ended up not so convinced that people who are good at solving story-style imperative problems will necessarily be good at solving math-style functional problems. It felt like a different part of my brain.
This is not at all a reason not to dabble with functional languages, just a potential pitfall to be aware of if you're thinking of bringing a whole team over. And maybe I'm overstating it? I haven't dabbled too much myself.