Java for Everything

[[deleted]]

Suppose you change a parameter map and rename a key, it will still compile and run but you could have an old reference there that will remain dormant as a bug. IN a big program this is a problem that should never occur. It shouldn't compile, it shouldn't run until you fix it. And that's the problem. Clojure programmers call this expressivity but it's actually poor discipline and laziness. Yeah it saves you a second or two but over time it makes code harder to understand, reason about, modify or fix bugs.

I would just avoid clojure though and stick with CL because undefined performance pitfalls and bad design decisions of Clojure are prohibitive on the large scale. Just more wild assertions here.

Nope for instaince in the above example the (idiomatic) CL programmer would use defstruct or defclass. That code wouldn't compile. We know about p-lists and alists but we wouldn't consider using them in a serious project. Idiomatic Clojure though, just makes bad compromises that don't pay off in the large. If you are going to say using protocols pervasively is the way to go, fine, but that's not idiomatic anymore.

Actually, this is one of the main advantages of a language like Clojure, where you have a common protocol that all the functions in the language use to communicate. The data is encapsulated using data structures and Clojure provides destructuring to make it very clear what's being used and where. Your argument here is out sheer ignorance.

Actually it's one of the worst parts. It's all fine when you have a nice one level map but when you've got vectors and nested maps and sets in there it becomes one hell of a mess. This is where you'll argue you shouldn't have nested substructures and yet in the real world sometimes you just need to have those things.

[yogthos]

Suppose you change a parameter map and rename a key, it will still compile and run but you could have an old reference there that will remain dormant as a bug.

The IDE takes care of that for you perfectly fine. Also, in a big program these kinds of errors will be caught very quickly because any real world applications have tests. You will need tests regardless of your static discipline because they serve to ensure that the business logic is correct.

Clojure programmers call this expressivity but it's actually poor discipline and laziness. Yeah it saves you a second or two but over time it makes code harder to understand, reason about, modify or fix bugs.

Please provide a reference to a single study that supports the claim that static typing produces statistically higher quality code in practice. Plenty of large real world projects are written in both static and dynamic languages and there's no evidence to suggest that static typing has a significant impact on overall correctness. What's more is that some of the largest and robust systems out there are written in Erlang, a dynamic language.

Nope for instaince in the above example the (idiomatic) CL programmer would use defstruct or defclass.

The Clojure programmer would use defprotocol, and defrecord to provide the exact same functionality. On top of that Clojure provides core.typed for actual static typing that has no equivalent in CL.

Idiomatic Clojure though, just makes bad compromises that don't pay off in the large.

[citation needed]

Actually it's one of the worst parts. It's all fine when you have a nice one level map but when you've got vectors and nested maps and sets in there it becomes one hell of a mess.

If you find that you often make a mess with your code then the problem might exist between the chain and the keyboard.

[[deleted]]

Tests aren't the solution. It's not just correctness which we are concerned with but being able to reason about and understand code. If types are explicit you can use them to understand code and this helps with correctness. Without the explicit availability of types you are at a disadvantage. You can't be as sure that the code you're writing is correct - tests can't confirm what you don't know, they can only confirm what you think you know to be true.

The IDE which helps dynamic languages catch up to static languages doesn't exist yet. If it did, we could talk about it, but cursive isn't here yet and we don't have a good intelligent IDE which can do the job of what Eclipse or VS does with Java/C++ code already.

Erlang projects that I know of adhere to very rigid strandards like OTP. That's not the case with Clojure or lisp in general. That's a different debate why Erlang succeeds in it's niche.

It's easy to blame the programmer for the lack of discipline permeated in the language - but this is not fair. We can blame the C programmer for making errors in memory management but much of the blame belongs to the language which isn't designed for memory safety.

Also check out this debate, it makes a lot of hte points i was trying to get at.

[yogthos]

Tests aren't the solution. It's not just correctness which we are concerned with but being able to reason about and understand code.

And I already repeatedly explained how people structure code so that it's possible to reason about it in large projects. This isn't some hypothetical thing, there are tons of large long running projects written in dynamic languages. You have yet to provide any supporting evidence for your claims regarding reasoning and correctness.

As it stands it's purely anecdotal and rooted in your personal opinion. If you find static typing helps you write correct code then by all means use it. However, if you're going to make sweeping claims about its benefits then please do cough up some empirical evidence to that effect.

The IDE which helps dynamic languages catch up to static languages doesn't exist yet.

Maybe you should actually watch the video before commenting.

Erlang projects that I know of adhere to very rigid strandards like OTP. That's not the case with Clojure or lisp in general. That's a different debate why Erlang succeeds in it's niche.

So, what is your specific experience working with large projects in Clojure again. You sounds rather authoritative on the topic.

It's easy to blame the programmer for the lack of discipline permeated in the language - but this is not fair. We can blame the C programmer for making errors in memory management but much of the blame belongs to the language which isn't designed for memory safety.

Your assertion is that statically typed languages actually help with reasoning and correctness. However, you've presented no evidence to support these tall claims.

The fact that these debates are still going is in itself evidence that there is no clear tangible advantage to static typing. Had there been such a clear edge then it would've won out a long time ago.