Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

And a strong sell for Scala and no mention of Clojure. It confuses the hell out of me; clojure is fast, mature, and has a OO syntax and model to rival CLOS. It's got built in laziness and te best concurrency primitives I've seen to date (and I was a professional Erlang programmer).

What does it take to break into the general public's consciousness? Clearly it's not the parens.



This article is from December 2008, when both languages were fairly young but Scala had been around significantly longer than Clojure.


Good point. I hadn't noticed that.


<contributor-bias>

I seriously think Clojure is too much to take in at the first introduction. It's really hard to get your brain around everything done right, when compared to traditional programming. You need to use it for a while to really get why it's approach to state (not concurrency) is awesome.

</contributor-bias>


I think that this may be a side-effect of the literature, which is very lispy and computer sciency. For someone like me, that's exactly the right tack. For someone who may not take for granted all the claims Rich and his book-writing compatriots are making (let alone take for granted the lisp code-as-data is an foundational revelation of computer science), it may be a problem.

Because really, Clojure is in many ways simpler than both Scala and Java. You can ignore the hard parts (agents, deftype, macros, de-chunking seqs, etc) and just cruise through the easy parts with a fair degree of ease. Everyone understands functions, after all. And Javascript has really pushed the "use functions for everything" approach into the public eye quite nicely.


That, and we're still getting our act together in the Clojure world. Stay tuned :)


I keep asking for, and I will do so again here, a non-toy web application written in clojure as a study object for newbies to dissect. That would help a lot.


What would qualify as non-toy? With Ring and a routing library like Moustache what more do you really need for building a non-trivial web application in Clojure?


Well, you outline the problem really nicely there. Never heard of Moustache, and the problem is in figuring out how all the bits go together and what is the 'best' way of doing this in clojure. The learning curve for the language alone is steep enough that having a non-trivial example would do wonders in terms of understanding how a clojure based website works under the hood.


If you've ever worked with light weight http framework in Python or Ruby, it works exactly the same way.

http://mmcgrana.github.com/2010/03/clojure-web-development-r... http://github.com/cgrand/moustache

There isn't a mature web framework for Clojure yet (for obvious reasons), so there isn't a popular "way". At the moment you have a lot of good libraries and you can put your app together in whatever way seems most sound to you.


I agree. I have been working on some statistical NLP code in Clojure today for a client and I continue to be amazed at how concise code can be. One of the reasons I starting using Ruby about 5 years ago was that it is such a concise language, but Clojure seems even better. Smaller code is easier to read and maintain.


Scala has Twitter to champion it in business and tech circles as well as creator Odersky's technical university affiliations to appeal to the academic crowd.

Clojure has a lot going for it in terms of theory but I don't know that it can claim any of the social proof of Scala.

The closest thing I can think of for Clojure is all of Siebel's Lispy interview questions from Coders at Work that lead an underinformed coder to think highly of STM and of Lisps.

Edit: Scala apparently predates Clojure by a good four years. The larger mindshare is no surprise in that light. Also it appears to have simple pattern matching and several other things that Alex Payne liked: http://www.slideshare.net/al3x/why-scala-presentation


AFAIK the "theory" in clojure also stems from the scala world in that clojure data structures are based on work done for scala or by scala affiliates.


No. All that work predates both, in some cases by several years.

In fact, a good friend of mine is working to put scala bindings over all the clojure data structures so they can be used transparently in scala. They're that good.


Your friend might be wasting a lot of effort (apart from his personal learning experience), as Phil Bagwell is working on Scala's collection library.


For context to "outsiders": Bagwell wrote the papers that the Clojure datastructures are based on.


“A lot of effort?”

Wrapping the PersistentMaps took like less than 200 lines of code: http://github.com/codahale/yoink


Yes, 'a lot' is quite relative. :-)

From my point of view 200 LoC giving me something I already have is a lot. From the point of view of your friend 200 LoC might be a very small price to pay for a good learning experience.


I invite you to benchmark the two.

I'm also slightly confused as to why you think reusing stable, proven, and reviewed data structure implementations is a "good learning experience" as opposed to being SOP.


scala.collection.immutable is/will not be stable, proven and reviewed?


The hash array mapped trie was committed to trunk 3 months ago and was first released in 2.8.0.RC1 (which no one uses due to various bugs) and is now available in 2.8.0.RC2 (which very few people are using due to binary incompatibility).

In contrast, Clojure's PersistentHashMap dates back to 2007 and was in both the 1.0 and 1.1.0 releases.


Is it unreasonable to expect that Scala's persistent collections will work comparably to Closure's when 2.8 final is released?


That doesn't sound unreasonable, no -- at some point in the future, Scala's hash array mapped trie will be robust and highly optimized. If your plan is to wait until then, you might be able to speed things up by helping them out yourself.

In the meantime, I benchmarked Yoink's PeristentHashMap against 2.8.0.RC2's immutable.HashMap by a) creating a map of 100,000 sequential keys and then removing them all, and b) creating a map of 100,000 random keys and then removing 100,000 random keys. In the first case, Yoink was 20.7041% (±1.83693%) faster. In the second case, Yoink was 24.7834% (±4.17055%) faster. (Student's t distribution, 95% confidence interval, source is in src/test on the GitHub project and I used ministat for the statistical analysis [a cross-platform port of which is also available on my GitHub page].)

So to summarize, I have a provably faster hash array mapped trie at almost zero cost right now because I spent a few hours with a "good learning experience."


I'm not disputing that Clojure's data structures right now are more performant than Scala's or that your project was worthless. I even apologized in case my original post was badly worded.

What I wanted to confer was that, you _might_ have been wasting a lot of effort because I assumed that you might not have been informed about work of the Scala team that has a high likelihood of obsoleting your project in the near future. Obviously you were informed and my notice was inappropriate. Be assured it won't happen again.

If increasing the performance by about 1/4 for your use cases - compared to the current beta - is valuable for you, great! For me it wouldn't have been worth a few hours. 'A good learning experience' would have. But obviously your values are different.


The back of your hand is going to get sore with all those compliments.


I did not have the intention of backhanding you or your friend. If my post had the appearance of doing so, I apologize.

I just wanted to point out the (for me at least) non obvious fact that the mind behind the theory of Clojure's persistent datastructures is working on Scala's collection library and that Scala's hash maps are already backed by hash tries - http://www.scala-lang.org/archives/downloads/distrib/files/n...


Good for Scala. When it's ready, people can use that. Until then, there are interim solutions.

And it's pretty neat to see a scala proponent call a scala project a "waste of time." Way to represent for your community, bro.


I liked the look of Clojure the language, but I got put off a bit by all the Java infrastructure that gets pulled in. For example, not knowing much about Java build tools, I have very little idea what leinigen is actually doing behind the scenes. There's not much documentation, and I didn't have much luck googling for error messages. I'm playing around a bit with Google App Engine, and things got a lot easier when I just gave up and switched over to Python. Having to use any kind of build system feels like a huge waste of time if execution speed is not a top priority. Python might not be quite as nice a language as Clojure, but I just write the code and it works -- no extra fiddling about required.


I think that you are correct about two things: Clojure stack traces and error messages are pretty bad. And, Python is probably the best language for AppEngine because of the small loading request times; with Java I struggle to minimize loading request times (I use objectify-appengine instead of JDO, etc.)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: