281–290 of 309 posts
Earlier quoted context omitted.
Any statically typed language allows for a compiler to detect breaking changes like you describe. That’s the point!
In practice that's very not true. Plenty of room for undefined behavior in statically typed languages like Java, C# etc.
Earlier quoted context omitted.
In practice that's very not true. Plenty of room for undefined behavior in statically typed languages like Java, C# etc.
Of course there is. That's not my point.
You literally posted that using a statically typed language prevented breaking changes?
Earlier quoted context omitted.
I suppose the argument would be that only developers with a modicum of interest in their craft will gravitate towards niche languages such as Clojure. But you are correct that doing so doesn't necessarily mean they are good. However, I don't think it follows that great developers work on hard problems. Why can't you be a great developer working on CRUD apps and occasionally finding ways to do them better?
I argue that Clojure née the functional programming community writ large capture a peculiar local maximum. I used to subscribe to the “functional = better” camp until going to MIT. I challenge anyone to find a cutting edge CS paper* that is written in their favorite functional language. If it were so effective — wouldn’t one academic have exploited this efficiency to catapult themselves ahead of their imperatively bo…
If anything, as someone who has a Ph.D. and a career spanning both academia and industry, I can assure you that functional programming languages like Clojure is much more productive than the mainstream languages, even for implementing cutting edge CS research.
My experience of implementing algorithms from papers is that, in Clojure, the implementation is much more straightforward, always almost a direct translation from pseudo code in the paper to actual working code, even the pseudo code is inevitably written in an imperative style. However, the original author's code implemented in c/c++/java is always much more convoluted and bears no resemblance to their pseudo code in the paper. That should tell you one thing: that is functional languages often capture the bare essence of computer science, whereas mainstream language often have too much incidental complexity imposed by the languages themselves.
Earlier quoted context omitted.
Honest question: Why is clojure so much better than the rest?
Compared to other languages, I've found Clojure makes it much easier to iteratively turn an idea into code. Say you're writing a pure function... You start with just data and a sense of how the output might look. Let's say I have APIs providing me with a user record and a list of transactions, and I want to get that person's balance... Maybe you start with some canned data (let [person {:name "Matt" :id 12345 :curren…
A common point is being made in the threads here: "The downside of Clojure is that you need good, wise developers..." The converse of this is that good, wise developers are going to (ultimately) _demand_ Clojure. What I mean by this: I was a Java programmer for years and increasingly started writing code in a more functional, immutable, dynamic style with the occasional need for meta-programming -- for the sheer need…
> The converse of this is that good, wise developers are going to (ultimately) _demand_ Clojure. HN seems to blindly accept the idea that developers using niche languages are good but I certainly haven't seen any proof of that and I haven't seen anything to even remotely suggest that good developers gravitate towards Clojure. Great developers have to be working on hard problems and almost all of the hard problems in…
From my personal experience, before I become a Clojure user, I wouldn't dare to write "hard" software such as compiler, database, and such, all by myself. Now I have done all that, I would credit part of that to the productivity of the language. That's why with such a small community, Clojure ecosystem has produced so many first of its kind innovative systems, e.g. Storm, Datomic, etc.
Earlier quoted context omitted.
When I'm coding in Lisp, I want objects with methods and mutable state. I made myself a Lisp dialect with a nice little object system. More precisely, I made it without that object system, but I eventually couldn't stand the situation. I use objects even in small, throwaway programs used once. Sometimes it turns out that they aren't just used once, and the use of objects makes them easier to read later.
FYI - you are an outlier. In my experience once you teach someone about immutable systems, they never want to go back. There are sometimes corner cases where you want mutability. Usually for performance reasons; and in those cases it's helpful to have an escape hatch, but also, I would argue that most programmers don't need performance, even when they think they do, something else is the bottleneck. Because this in H…
They also don't want to throw away all their other valuable techniques.
Programming with mutation is not just efficient, it is also highly expressive and easy to verify, for the right kinds of problems.
Just because it's useful for writing operating systems, video games and database engines, don't be mistaken in assuming that it's only useful for operating systems, video games and database engines.
Earlier quoted context omitted.
> how it differs from other (primarily object oriented languages That includes every major Lisp dialect.
The interactive development is definitely Lisp heritage, but not "simplicity, functional programming, and immutability".
What's not Lisp heritage is to have a vector or hash table to which you can add an item to get a new container, such that the original remains the same.
It's a generalization of consing an item onto a list, though.
Earlier quoted context omitted.
Many Clojure companies find it easy to hire smart non-Clojure developers and teach them Clojure. You can learn the basics in a week or two and be a pretty effective Clojure developer (especially if supported in a team) pretty easily.
No, you can't (in that timeframe).
In my startup, our onboarding time is two weeks. I would say nine out of ten fresh graduates we hired picked up Clojure and were able to do something useful after two weeks. But we did have one or two persons who were not able to and they ended up in one of FAAG (yes, we did do leetcode style interviews, but only asked medium level questions).
Earlier quoted context omitted.
No, you can't (in that timeframe).
+1 on that. I've learned Clojure in the past and keep wanting to go back to it but Clojure has been the hardest language for me to become fairly comfortable with. I think it may have to do with its dynamic-ness. There's basically no problem Clojure experts can't find a solution for. Its basic constructs are very powerful but all those solutions are not codified in the language itself. So Clojure has this extra layer…
So I agree that it is harder for experienced people than for young kids fresh from school.
Earlier quoted context omitted.
Same for Kotlin, really. Can only do so much to stabilize things when you're building your home in a marecage.
There are certainly limits, but null safety doesn't need to be one of them. Typescript does a great job of handling null safety on top of JavaScript. I don't see any technical reason why Kotlin couldn't have done the same.
Kotlin does do the same. I totally disagree with GP's assertion that Kotlin has no null safety. I use both Kotlin and Clojure and I find Kotlin much better than either Clojure or Java with respect to NPEs.