Tangentially: I recently decided to give Pharo a try. I'm still pretty early on in it, but, so far, I've really been having fun. If you look at it the right way, Smalltalk can almost be seen as more Clojure than Clojure. It's even more dynamic, and the live programming environment gives even tighter, more integrated feedback loops than REPL-driven development. Smalltalkers aren't exaggerating when they say you can li…
What are you writing with it? I've been wanting to give it a try too, but I'm unsure what kind of project is best suited.
The Future of Clojure
121–130 of 309 posts
Re: The Future of Clojure
#122Earlier quoted context omitted.
At the company I work for we've found it hard to find Clojure devs. Not sure if this applies everywhere else, but it's definitely seen as a disadvantage of the language here.
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.
People who already knew Clojure had a tendency to overcomplicate things with solutions that used every bit of their Clojure knowledge.
Re: The Future of Clojure
#123Earlier quoted context omitted.
This absolutely matches my experience as a full time Clojure dev at multiple companies. Leadership is desperate to replace the code with something more maintainable. It's gotten bad enough that I will switch languages for my next job, the headaches are not worth it.
Clojure is quite maintainable, a well-written Clojure program is small and clear, easy to modify. Pervasive immutability is a huge win; Clojure programs are big on referential integrity. There's some doublespeak going on here. When "leadership" says "maintainable" what they mean is that the project is recoverable after they frog march the project lead out the door, or lay off the team, or the team quits because the j…
Even there, the projects suffered so much to hit release dates and stay understandable as the system grew that velocity suffered relative to peers doing experiments in traditional OO languages. In fact, the maintenance burden (for code composed by smart senior people!) is so high that it's actually convinced me on the virtue of regular OO/procedural languages over lisp.
Re: The Future of Clojure
#124> The downside of Clojure is that you need good, wise developers... Is there a language that, for a sufficiently large application, you don't need wise developers? What is it? How?
Re: The Future of Clojure
#125are there people who used both clojure and scala. And decided to use Scala ? if so why ? I'm new to Scala that's why
There are people that used both including me. But I fell squarely on the Clojure side and haven't written Scala for 7-8 years now.
Re: The Future of Clojure
#126This will probably earn me lots of negative points, but I used Java for eight years and after much initial enthusiasm came to despise it. It was the least productive language I have ever used. I have twice tried to learn Clojure and each time I have to install the JVM, I simply quit, despite being intrigued by Clojure itself. Sigh.
Which one was the least productive language, Java or Clojure ?
Re: The Future of Clojure
#127Earlier quoted context omitted.
Clojure is quite maintainable, a well-written Clojure program is small and clear, easy to modify. Pervasive immutability is a huge win; Clojure programs are big on referential integrity. There's some doublespeak going on here. When "leadership" says "maintainable" what they mean is that the project is recoverable after they frog march the project lead out the door, or lay off the team, or the team quits because the j…
This is not what I meant by maintainable. The companies I've programmed clojure in were sizable and bet on it for their entire stack, and hired very sharp senior people to work on them. Even there, the projects suffered so much to hit release dates and stay understandable as the system grew that velocity suffered relative to peers doing experiments in traditional OO languages. In fact, the maintenance burden (for cod…
This is an example of the problem of Clojure being promoted as Lisp. There are now people whose idea of what is "Lisp" is represented by Clojure.
You might like coding in a normal, procedural Lisp with OOP, but due to a bias induced by Clojure, you don't suspect that's even a thing.
Re: The Future of Clojure
#128A 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…
I think that the bigger problem is that developers just don't get taught any way to think about coding other than the object-oriented, use-Java-for-everything approach. I sometimes think I could have massively accelerated my ability to produce decent code in any language if I had been forced to work through "The Little Schemer" and "How to Design Programs" before I saw anything else. But that is probably just hindsig…
Re: The Future of Clojure
#129Earlier quoted context omitted.
> Sun spent like a billion dollars marketing Java I guess now the question is if Nubank could/will also promote Clojure and to what extent (or if they will support Cognitect enough to do that). I would wonder if they went through that thought process and what RoIs for that are from their perspective. It might even take much lesser investment than equivalent of $1bil from 90s... The Java/JVM market is huge so it might…
> And all that just by selling some cheap cut syntax sugar on the corner. I suppose you could dismiss a lot of what Kotlin adds as mere syntactic sugar. But it also makes some much more fundamental improvements. It provides a much cleaner, unified, object-oriented type system. It provides about as sane an approach to null safety as is possible on the JVM. (Clojure's is arguably better, but I'll concede that nil punni…
Re: The Future of Clojure
#130I do think that Clojure shops (like all software shops) need to dial back the torture interviews / homework / tests, but that's really a bigger thing that just Clojure. I think more could be done to market Clojure to the non-believers, but I don't have specific ideas on how that could be done.
You can take my parentheses from my cold, unemployed hands.