The only difference one should care about is static typing versus dynamic typing and that's it. Of course it's not a binary black and white classification when looking at languages, for example Scala is less static than Haskell and Clojure is less dynamic than Ruby. But overall that's the biggest difference and that changes the style, the mentality you have, how the code looks like.
As an example you are much more likely to see in Scala the Maybe/Option monad, whereas in Clojure people prefer to work with null (nil). Rich Hickey said it himself that Option[T] only makes sense in a static language. In general in Scala you're more likely to see things like monads and functors being modeled explicitly. It's more natural to do that in Scala because it's all a matter of describing functions with certain signatures. And you know, when working with combinations of flatMap and map, it's much easier if you have the compiler telling you where you've fucked up. Which is why many people do use things like Scalaz or Cats or Shapeless. On the other hand in Clojure it's much easier to build things like transducers, because there's no type-system to stay in your way.
Clojure people work with lots of DSLs built over macros. You can see that in how Clojure exposes those channels in core.async and compare that to how asynchronous processing of events is done in Scala (e.g. Future, Iteratees, scalaz-stream, Rx, Akka actors, Reactive Streams, shameless plug: https://github.com/monifu/monifu). Of course, Scala has its own macros system, but like in other static languages, the macros in Scala are only being used by those that really know what they are doing. But because of that, in both languages you get features exposed as libraries instead of being special language features. For example here's Scala's equivalent for C#'s await/async exposed as a library: https://github.com/scala/async
Which one is better is actually dependent on the problems you're trying to solve. The problems I'm working on have a very complex business logic and are a better mix for static typing. This is why people will never agree on which one is better, because it actually depends on context.
Probably explains why most Lisps consist of one-man-hobbyist projects, though.
I do not agree. There is no single type system that would fit all the possible use cases.
> Probably explains why most Lisps consist of one-man-hobbyist projects, though.
No, it does not.
The good thing is that 99.999999999999% of all programs never need to be written, and there are plenty of type systems which deal well with the last 0.00000000001.
> No, it does not.
Ok, that leaves the failure of Lisp outside of hobbyist mom's basements a mystery.
This is where I lost a track of your arguments.
> Ok, that leaves the failure of Lisp outside of hobbyist mom's basements a mystery.
Lisp did not fail. It's in pretty much all the mainstream languages now.
Then maybe you should maybe spend some time studying these topics instead of acting up on HN.
> Lisp did not fail. It's in pretty much all the mainstream languages now.
This is where I lost the last doubts about the reality and your lack of closeness with it.
Chances are, I implemented more varieties of type systems than you can name.
> This is where I lost the last doubts about the reality and your lack of closeness with it.
Scala fanboys are much more detached from the reality. The reality rejected bondage&discipline languages long ago.
Please also don't post unsubstantive comments. That means avoiding programming language flamewars, since they're only nominally about programming and really about insults and disses.
We ban accounts that do this repeatedly. On HN, please post civilly and substantively, or not at all.
Scala has macros since 2.10
The worst part which makes macros much less useful is that you cannot have a macro definition and use it in the same compilation unit.
In fact, adding proper macros support to any language is trivial. Pity that very few are bold enough to do it.