Earlier quoted context omitted.
Static types are the new religion, like OOP was in the 90s. Types solve 2% of programming errors. They lead to coupling for the sake of the compiler, and make code harder to change, harder to write, and often needlessly constrain the utility of the code where they're applied. But they do make the IDE code-completion go, so there's that.
Can you reference "Types solve 2% of programming errors"? I've read numerous research papers and blogs on this topic and have never seen anything as low as 2%. Edit: Googled and nope, can't find anything.
Clojure: A Lisp that wants to spread
251–260 of 306 posts
Re: Clojure: A Lisp that wants to spread
#252Earlier quoted context omitted.
You're aware that it's possible to write bad code in any language, even Clojure, right?
Look, I'm not trying to bash on static typing. I like type systems. I love Haskell's, for example. I missed static type checker in every single dynamically typed language, and Clojure is not an exception. That being said, there's no conclusive evidence that dynamically typed systems can't be robust and scalable. Sometimes, dynamically typed systems make absolute sense, especially in the context of homoiconic language…
> That being said, there's no conclusive evidence that dynamically typed systems can't be robust and scalable.
That was never the claim, though. It's possible to write anything in any language, witness the millions of lines of code that are written in PHP or FORTRAN today.
The question is trying to determine if there are characteristics of programming languages (such as their type system) that make achieving these goals easier, and which also possess other nice attributes (such as making the code easier to refactor and maintain, easier to navigate or learn by new hires, etc...).
In my experience, dynamically typed systems are harder to refactor, harder to understand, require more cognitive load to understand them, and are typically slower than statically typed languages. And because of the absence of type annotations and the 100% reliance on the (hoped) existence of tests, many developers simply decide not to refactor dynamic code for fear of breaking it, which leads to much more pronounced code rot with dynamically typed languages.
> Maybe the simplicity that Clojure offers allows me to stay dumb and focused on the task at hand, and enjoy the ride.
I'd argue the opposite: dynamically typed languages require you to hold a lot more stuff in your head (the types and what each object is and what they can do) whereas type annotations allow you to focus on more important things.
Re: Clojure: A Lisp that wants to spread
#253Earlier quoted context omitted.
Instead of just measuring how many developers adopt Clojure and how difficult/easy that is, I'd also love a measure of how many developers Clojure "puts out of business". IME Clojure is quite aggressive on that front. In 2017 a customer wanted a set of services written in Clojure. Based on their Java experience they wanted to hire 10 devs. When I arrived they had 4, over the 1.5-year period I was there, they hired an…
Were they fired because they weren’t good enough at Clojure? Perhaps all Clojure did was filter out less capable performers. The small team of skilled developers might have been just as fast in Java if they weren’t encumbered by the mediocre ones.
I was mainly concerned with teaching Clojure in this project as everyone had little or no experience prior, so nobody was blocked by learners. Those who were fired all had one thing in common: They refused to adopt Clojure beyond its syntax in favor of patterns they learned to rely on in another language. This varied from porting Scala polymorphism to just banging out imperative while loops with atoms. I don't think they were incapable. They simply didn't want to learn it. Code reviews turned into arguments quickly, took endless time and lead nowhere.
Their code was never touched by those who stayed and were able to work together. Later it was rewritten, because in spite of tons of unit tests (which passed), it was full of bugs. The code was considered "write-only". The rewrites averaged at 5-10% LOC.
Re: Clojure: A Lisp that wants to spread
#254I tried Clojure but ended up hating it for reasons all stemming from its hosted implementation. Whenever I didn't know how to do something, I (and most other Clojure users) would go use some JDK class (or worse, an external Java library) instead of figuring out how to write the Lisp. For some reason this doesn't often happen with regular Lisp even though CFFI is available. There's a tendency to just reimplement it di…
I have to say that I don't really recognise that thing about using JDK classes. I've worked with Clojure for 2 years on a big government project (maybe 50 Clojure devs) and it was full-stack Clojure all the way down. We never used any Java libraries either, but of course basic Java/JS interop is a pretty normal occurrence in Clojure when doing a certain type of code (like reading and writing certain binary files to d…
I have to concur with you mate, I've used Clojure now for 6 years in 2 startups and I can almost count on 2 hands the number of times I've had to interop directly with Java classes to get something to work.
Re: Clojure: A Lisp that wants to spread
#255Earlier quoted context omitted.
This list doesn't strike me as the important things that Clojure is missing. They're all relatively minor matters. There are several other things that I would consider much more important. I've gone on at some length about those things before (for example, see my long comment in this thread: https://news.ycombinator.com/item?id=22318748 , ), so I won't repeat it here. I'll just say that Clojure is pretty nice as far…
> I daydream about a Clojure with the missing pieces filled in Be the change you want to see in the world and start filling in the missing pieces! ;-)
That's a fair response. I've thought about working on a Clojure implementation on a Common Lisp runtime, precisely because I'd like to see a Clojure that is a real, proper Lisp.
Cloture is an interesting effort:
https://github.com/ruricolist/cloture
I hope ruricolist succeeds.
But so far I haven't actually done any work in that direction. When I work on interpreters and compilers, I generally work on trying to improve upon Common Lisp, rather than trying to help Clojure catch up to it.
Years ago, in the early 1990s, I worked on an experimental OS at Apple. It was written mostly in a Lisp called Ralph (which later evolved into Dylan). Ralph was basically Scheme's kernel operations on top of data types built on CLOS with some functional-programming idioms.
Ralph had all of the nice things I was pining for in that post that I previously linked, but it was also a smaller, simpler, and more consistent language than Common Lisp, and it was easier to learn and easier to extend.
I've been working for years now on a language that started as a Ralph embedded in Common Lisp, but which has mutated quite a bit over the years as I learned new things and experimented with adding them to my implementations. It's been complete enough for me to ship a few products with it, but it's not done, and lately I've been inclined to steer it more back toward Ralph.
Mostly. There are still a few newer features I might like to keep.
So, while I acknowledge that it's totally fair of you to exhort me to work on Clojure, and it's not necessarily a bad idea, there is another Lisp for me to work on that is dearer to me.
Re: Clojure: A Lisp that wants to spread
#256Earlier quoted context omitted.
How is it declining? Every single year we're adding 3-5 new conferences, last year alone - Ukraine, Russia, Brazil, India, Canada. New books being published. There are number of active podcasts (more than for any other FP lang). Latest JVM survey shown - Clojure has become more popular than Scala (largely due to Kotlin), but still surprisingly so. There's a Clojure related post on HN top, almost every week, sometimes…
Maybe it just means that there is a small and vocal community around Clojure - being on HN means that something is interesting for HN community, but it does not translate to wider adoption necessarily. When Clojure was started it didn't have much competition in JVM languages space. There was Scala only. Right now we have also Kotlin, which seems to be hitting the sweet spot between being a better Java and being diffi…
> Maybe it just means that there is a small and vocal community around Clojure
There's relatively small but vocal Emacs community. There are no books being published; almost no podcasts; it took forever to organize a conference, but they still couldn't find a venue, so it was a video-conference. Every few years there's a new "Emacs killer" but the ecosystem (after over 40 years) is very much alive and thriving.
Same thing can be said about Clojure. It's a very vibrant ecosystem and there's a lot happening in Clojuresphere, but of course, with almost every post about Clojure, there would be at least one person to claim - "Clojure is dying." Well, if that's true, then buckle-up folks. It's going to be a very long, steady ride.
Re: Clojure: A Lisp that wants to spread
#257Earlier quoted context omitted.
Look, I'm not trying to bash on static typing. I like type systems. I love Haskell's, for example. I missed static type checker in every single dynamically typed language, and Clojure is not an exception. That being said, there's no conclusive evidence that dynamically typed systems can't be robust and scalable. Sometimes, dynamically typed systems make absolute sense, especially in the context of homoiconic language…
> That being said, there's no conclusive evidence that dynamically typed systems can't be robust and scalable. That was never the claim, though. It's possible to write anything in any language, witness the millions of lines of code that are written in PHP or FORTRAN today. The question is trying to determine if there are characteristics of programming languages (such as their type system) that make achieving these go…
You don't have to explain benefits of statically typed languages to me, I'm not fresh from a bootcamp.
The flaw in any argumentation about programming languages is almost always universally stems from the fact that we eagerly paint everything either white or black.
And I've been coding for long enough to learn that there are no universal answers - clean OOP, or pure FP, dynamically or statically typed, garbage collected or manual memory management, etc. The answer is almost always: "it depends".
Looking at any specific language through a prism of your own beliefs guaranteed to form opinions that would be flawed.
You can't put all dynamically typed languages into the same bag - programming in Python is vastly different from programming in Clojure. Same way as you cannot do it for other properties of the language, like it being a Lisp or being hosted on JVM.
Re: Clojure: A Lisp that wants to spread
#258The dealbreakers with Clojure for me are: 1. Weirdly irregular syntax. 2. Java import statements and Java error backtraces anywhere you want to do real work. 3. Inexcusable renaming and name collisions on basic Lisp functions. It's much, much less of a Lisp than Scheme and neither "but it's properly functional" nor "we fixed the tooling now" make that any less true or the language any more interesting for the use cas…
I do agree that initial impressions are important for a language and "perceived" learning curve does make a difference. Things that scare people away initially do hurt adoption; things like Clojure's syntax and that it is a dynamic language on the JVM (i.e. how does that affect interop/performance/etc) all raise questions. Even if there are answers to these questions and justified reasons just like most sales pitches you've already lost a lot of people who have doubts and are already productive as they are.
As an example I remember a presentation done some time ago where the presenter was showing code in F# and many non-technical people understood the code thinking it was a pseudo code at first (i.e. business stakeholders/BA types/etc). That was a win for them. If I showed F# and Clojure code side by side to an ex-coder manager as an example syntax I'm sure would matter and they often have a say in this decision. Buy-in is an important criteria in language selection for sure, as well as current skilled developers. If the pool of devs is small how easy it is to train people and get people wanting to be trained in it thinking it may be dead end skill with no jobs? I don't have that opinion personally but some dev's definitely do. Especially because jobs in these languages are scarce; if learning curve is small then it could be used even then.
My cynicism shows marketing and perception of a tech stack are equally if not more important than other factors in tech selection in many companies. No one got fired for picking IBM or in this day and age Java?
Re: Clojure: A Lisp that wants to spread
#259Earlier quoted context omitted.
> Prefer functions which take their input as separate parameters. In practice, it's better to avoid positional arguments and extensively use maps and destructuring. Of course, there's a risk of not properly passing a key in the map, but in practice that doesn't happen too often. Besides - Spec, Orchestra, tests and linters help to mitigate that risk.
> In practice, it's better to avoid positional arguments and extensively use maps and destructuring We can agree to disagree I guess. In my experience, especially in the context of refactoring, extensive use of maps as arguments causes quite a lot of problems. Linters also do nothing for that. Positional arguments have the benefit of being compile errors if called with wrong arity. I actually consider extensive use o…
For example if you have something like:
(study [student age] ,,,)
It also makes it difficult to carry the data through functions in between. The only benefit that positional arguments offer is the wrong arity errors (like you noted). And yes, passing maps can cause problems, but both Joker and Kondo can catch those early, and Eastwood does that as well, although it is painfully slow. With Orchestra and properly Spec'ed functions - the missing or wrong key would fail even before you save the file. I don't even remember the last time we had a production bug due to a missing key in a map args.
But of course it all depends on what you're trying to do. I personally use positional arguments, but I try not to add more that two.
Re: Clojure: A Lisp that wants to spread
#260Earlier quoted context omitted.
And poor tooling support on MS Windows. Leiningen does not even have a proper installer on Windows, last time I checked. Having leiningen not bundled into the clojure distribution, is in strong contrast to the "batteries included" approach of python. There were also complexities in including local jars into projects, as it required setting up a local maven repository, which is tedious job. Also when exeptions occur c…
This is being addressed currently. There is now a bundled into the Clojure distribution package manager called "tools.deps". It currently have alpha support for Windows. They are still ironing out the quirks: https://github.com/clojure/tools.deps.alpha/wiki/clj-on-Wind... You no longer need local Maven repo, because tools.deps supports local dependencies, you can basically just depend on local folders. It also can de…
Yes, but that again begs the question why these are being addressed such late in the evolution of the language/ecosystem.