http://www.indeed.com/jobtrends?q=scala%2C+clojure

Also, Clojure may not be for everybody but should be experimented by those who want to “beat the averages” (http://www.paulgraham.com/avg.html).

That’s what I’ve meant!

I doubt that line. To me this is more wishful self image than reality of many Lisp supporters.

Starting with the very dynamic nature of Clojure: Clojure does have type hints, yes, but they are meant to provide hints for optimization, and the whole ethos of Clojure is to wind up with a set of small, composable functions which do a single well-defined operation on a data structure. Note that this isn’t an object with methods, it’s a functional library. Clojure feels very procedural to someone coming at it from a more OO background. In contrast, Scala encourages OO design from the beginning, though it’s certainly not as pedantic about it as Java is.

Also, regarding macros: I imagine a small handful people who are interested in Scala and language design might read the one page of official documentation about how the plugin system works and then roll up their sleeves, dive into the source code, and write a plugin to implement some new bit of syntax or add in a feature to the language. In contrast, macros are a well-defined, often uysed language feature of many Lisps, and any Clojure tutorial is sure to mention defmacro. It’s part of the Clojure culture – a quick glance at the Clojure Google groups will confirm this.

Also, I surely can’t speak for Rich Hickey, but I do think it’s fair to say that he was interested in comping up with “another Lisp,” just one that was emphatically not Common Lisp.

http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey

One thing which is important (IMO):
I think its quite important to emphasise that both scala and clojure encourage the functional programming theme on the jvm.
Which is IMO a very good thing.

To what extend that maybe topic of following ( endless) discussions.

But “just” that fact is important enough to me to take a closer look at both (say over Groovy)

regards andreas

http://codemonkeyism.com/scala-vs-clojure-flawed-loc-comparison/

I’m sorry to hear you feel that way. If you think apple/apple comparisons are more valuable than comparing solutions idomatic to both languages it would be great if you could write them up (the code) and I’d be happy to link them or depending on the amount, compile them all in a new blog post.

I can assure you that no member of the Clojure community have any interest whatsoever in producing comparisons which do not represent reality.

Thanks,
Lau

Any takers here?

But I won’t read your post, nor answer, or recommend it, because in the past you faked comparisons so much and so deliberately (Scala, Python, Clojure LOC) and didn’t change them, even after admitting they were at least shaky, that I can’t believe any longer you write not only FUD. Sorry. Stephan

Thanks for getting the ball rolling with this, I think its great to look at the similarities and differences, simply from a feature-aspect.

I’ve tried to walk through your bullets here:
http://www.bestinclass.dk/index.php/2010/04/clojure-scala-similarities-twins-separated-at-birth/

And unfortunately (as your commentators suggest), most of them don’t hold up under pressure. One key piece that I was missing in my post, was the scenarios where Scalas Type System would be the deciding factor in using Scala instead of Clojure for a given task, but I failed to think of any. Can you fill in the blank?

Best regards,
Lau B. Jensen

http://translate.google.com/translate?hl=en&sl=pt&tl=en&u=http%3A%2F%2Fwww.diale.org%2Fdiff.html

Obviously the same thing can be written in Clojure.

James

I’ve been programming Scala (and Java) for a couple of years in my current job, but previous to that I spent several years programming Lisp for AI research.

The static typing / dynamic typing seems to be a key difference, and one that might influence people one way or the other.

They do blur in a way, but fundamentally the static/dynamic difference is still there. My understanding of the type hinting in Clojure is that it’s to avoid reflection (by casting to the hinted type) but doesn’t provide any compile-time type checking. And thinking about type inference in Scala it seems to be more about conciseness. Statically typed languages are often perceived as verbose, while dynamic languages as concise. Haskell is the usual conter-example to this.

I find Daniel’s comment on “functional first” and “object-oriented first” interesting. Maybe larger project examples are needed to see how much of a difference this makes? I wonder if Scalaz shows that Scala can also be used in a way that puts functional over object-oriented?

Macros and Lisp’s code-as-data are very cool. Does anyone have some practical examples of using macros that would be too difficult to implement with Scala’s features?

Without macros, you can write code that writes code in other languages, but it generally runs as a separate pas, reading in what to it pure data, manipulating it as data, and then spitting out data that happens to be code when it’s done. I have done that before – using Cheetah to create Makefiles, or data structures to create XPath expressions. But this tends to mix two languages – the target language and the language that controls the generation of the final code. I also find that it’s a conceptual leap to go from writing code to writing code in a slightly different language that writes code.

With LISP macros, there’s only one language – it’s all LISP. It’s always there. Which means that going from writing code to realizing I need a macro to write that code is no longer conceptual leap – it’s just reaching for the next tool in the toolbox.

I’ve done a few videos on “code is data” if you’re interested…

http://vimeo.com/9114362

“I’ve thought about this for a bit, and I think the advantage of Lisp macros is centrally tied to the “code is data” philosophy. ”

After a little bit of thinking, you might be right.

Up until your comment I thought only machine code and Prolog were on completly different branches of the programming tree.

Is not just a syntax thing: is dynamic vs static typing :)

Thanks for being gracious enough to entertain this discussion :)

In all fairness, I don’t have any experience w/ Scala. The following is based on experience w/ other languages like Ruby & Java…

I’ve thought about this for a bit, and I think the advantage of Lisp macros is centrally tied to the “code is data” philosophy. Everything is a data structure, so lisp macros manipulate data structures. The resulting data structure is then evaluated directly, with no intermediate steps.

The other big advantage is that Lisp macros are always available (and the system is always compiling). This means I can get information from a variety of sources.

This lets you do a lot of things. In the sysadmin world, *nix is so popular because it allows you to configure your systems with information stored in a file, retrieved over a network, or generated programmaticly. It allows for lots of tasks to be automated & centralized, and eliminates repetition.

This approach that works awesome in the sysadmin world seems to be promptly forgotten in the development world. As a result we repeat ourselves all the time, and create this unnecessary work. Lisp macros let me avoid this.

“(I don’t think compiler plugins are a fair answer.)”

So aren’t macros I think, their relevance in real projects doesn’t correspond to their relevance in language arguments. Macros are the equivalent of Godwin’s Law.

As did obviously the fact that they are basically the same, but I mixed the language with the culture? And all the protocol and agent nonsense in Clojure should be removed. Then Clojure is not much more than JLisp?

I would appreciate examples, best from each culture, how problems that lend themselves to functional programming are solved in “completly” and “lightyears apart” different ways.

THEN I would be convinced. Otherwise I will only point to the Hacknot essays.

A while ago when I was thinking which one should I learn (mandatory because of all the parallelism and concurrency that we need to learn these days) I peek up Cloure because it’s pure functional and I don’t know nothing about FP.

So I decide to firstly learn FP with Clojure and after learn Scala and merge my OO and FP skills.

After all this I’ll be able to choose one of them for a real world project.

In terms of feel, I think the biggest difference is really the typing. Scala seems to be “more” than Java (although inferencing makes that ok in many cases) and Clojure is “less” than Java (dynamic but type hints pull you back towards Java). Depending on how you feel about types, you may be drawn towards one side or the other.

I think there is a case that macros are a difference but there is plenty of other stuff in Scala that I think allows you to solve those kinds of abstraction and language problems (at least those that occur in practice). (I don’t think compiler plugins are a fair answer.)

I actually proposed a Scala | Clojure talk with Jonas Boner for JavaOne this year called “Cool Hand Duke” about breaking out of Java. Of course, the chances that it will get accepted are about the same as Larry Ellison rewriting Oracle in Clojure.

Clojure and Scala are lightyears apart. Really, their only similarities are the fact that they both support functional idioms and they both run on the JVM.

How do you think the power of macros compares to compiler plugins? The same power level, one up?

Thx. Stephan