4 ms·

Not a personal experience, but more of an easy to remember existence proof: https://www.ptc.com/en/products/cad/elements-direct/modeling https://www.ptc.com/en/

by Jach 8y ago

Not a personal experience, but more of an easy to remember existence proof: https://www.ptc.com/en/products/cad/elements-direct/modeling https://www.ptc.com/en/products/cad/elements-direct/modeling is made of several million lines of Common Lisp and has been developed over decades. I find the counter-arguments to your discomfort in this thread very strange. Some big problems just require big solutions. A language might indeed be best suited for smaller problems, but that doesn't mean that bigger problems are a "cultural disease". For Clojure in particular, I recall Hickey saying something to the extent that for the problems where Java is successful, Clojure should be successful too. Maybe this rhetoric has changed, but I think it's also related to people's experience that what takes 750k lines of Java takes under 1000 in Clojure, for some problems, so you get this bias that 750k lines of Clojure is "wrong". No, it's just that the equivalent Java would be a factor of 10-100 bigger. If a language can support modularity, it should be able to scale. More at addressing your discomfort, I'd be curious to know what you mean by "language without any type safety". Dynamic typing isn't the same thing as untyped, and some dynamic languages (like Lisp) support a notion of compile time that lets you have type warnings, optimization, etc. that you might be used to from static compilers... as far as testing goes, the big testing pushes in industry have come from people dealing with giant C++ and Java projects more than the dynamic language crowds, because more energy for testing is needed in general. Whether dynamic languages need more or less of it could be interesting, but because of the variations in what we call "static languages" and what we call "dynamic languages" it might not be useful to compare things so broadly. Instead we could compare language against language, and take into account usual dev practices. Having a REPL to leverage while developing, testing, and debugging changes things in a big way, for instance.

tigershark 8y ago
I don’t really, really think that clojure is 750 times more dense than java. Probably F# can approach between 5 and 10 times more density than C# in the right conditions. The 750 times less is simply false in my opinion. Any strong proof of your extremely strong declaration?
- Jach 8y ago
  You're right that Clojure isn't 750 times more dense than Java in even the 99% case, I'm not trying to claim that. I probably should have used something more conservative to make my point (that dynamic languages will usually result in significantly less code for the same problems and that might itself cause suspicion of large projects entirely by dynamic language fans rather than take on the question directly of can their language scale to projects millions of lines big). The particular project I was thinking of in this case is Hibernate ORM, which somehow managed to weigh around 750k lines last I remember. It's a bit of a facetious comparison, I'll admit, to point to a few Clojure projects I know of that seem to solve the same core problem better in around 1.5k lines. Even if you agreed that they did, I think we'd both agree it was because of language features apart from dynamic typing (your own experience of two static languages differing by as much as 10x implies as much). When the problem domain is related to symbolic computing and metaprogramming, languages that support symbols and macros are going to have a huge advantage, especially when you start generating code you would have written by hand otherwise.

by Jach 8y ago

tigershark 8y ago

I don’t really, really think that clojure is 750 times more dense than java. Probably F# can approach between 5 and 10 times more density than C# in the right conditions. The 750 times less is simply false in my opinion. Any strong proof of your extremely strong declaration?

Jach 8y ago
You're right that Clojure isn't 750 times more dense than Java in even the 99% case, I'm not trying to claim that. I probably should have used something more conservative to make my point (that dynamic languages will usually result in significantly less code for the same problems and that might itself cause suspicion of large projects entirely by dynamic language fans rather than take on the question directly of can their language scale to projects millions of lines big). The particular project I was thinking of in this case is Hibernate ORM, which somehow managed to weigh around 750k lines last I remember. It's a bit of a facetious comparison, I'll admit, to point to a few Clojure projects I know of that seem to solve the same core problem better in around 1.5k lines. Even if you agreed that they did, I think we'd both agree it was because of language features apart from dynamic typing (your own experience of two static languages differing by as much as 10x implies as much). When the problem domain is related to symbolic computing and metaprogramming, languages that support symbols and macros are going to have a huge advantage, especially when you start generating code you would have written by hand otherwise.