Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Future of Clojure

thoughtworks.com

Post reply on HN
Print view View original

291–300 of 309 posts

Re: The Future of Clojure

#291

Post by mto »

throwaway92938 wrote: post #89
bambataa wrote: post #55

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 suppose the argument would be that only developers with a modicum of interest in their craft will gravitate towards niche languages such as Clojure. There is an opportunity cost and there are plenty of motivated developers that instead of learning yet another niche language decide to work on algorithms, applications and generally more difficult problems. Few languages offer enough advantages to overcome the fact…

Good point. I have been playing with lots of niche languages but in the end I also find that focusing my learning elsewhere is usually a better idea. Even more, I don't know many of the features of the languages I use although I have been working on rather tricky topics - from 3D viz to medical computer vision, low power device soft-realtime streaming deep learning inference ;) etc. and in decades of C++ I still only know the basics of metaprogramming (means standard template functions and classes). I am pretty dogmatic about RAII and similar but try to keep things simple. Even dropped most of the abstractions over time - sometimes 3 else ifs that then never change again are probably better than polymorphism, command pattern, lambda etc. stuff - at least you know what will be called there just by looking at the code.

Similarly I feel my Python code is getting simpler and simpler over time.

I'd probably even gravitate towards Go at some point nur there I do muss a few things.

I usually find the pay off is just better when I rather learn more about deep learning, statistics, domain knowledge, security, visualization or stuff like AWS, Kubernetes, Unity etc.

The language ends up to be a very small piece and usually more important to have the ecosystem and community available. Like Julia also does not solve the 2 language problem for me but leads to a 3 language problem.

Re: The Future of Clojure

#292

Post by dnautics »

kazinator wrote: post #286
dnautics wrote: post #175

Earlier quoted context omitted.

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…

Once you teach people a valuable technique, they don't want to back to being ignorant of that technique or avoid using it when they are able and it's the best tool for the job. 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 ope…

It's also a footgun waiting to happen, because I 150% promise you a junior dev or even senior dev will somewhere forget to pass by value instead of pass by reference. There is a reason why Julia and ruby encourages sigilling functions capable of mutating with a !. That character is not chosen randomly.

Yes, it is also absolutely necessary for expressive A* pathfinding.

This is unnecessary for someone connecting two web APIs. Correctness in most domains is totally worth not having to worry about pass-by-reference defaults.

Re: The Future of Clojure

#294

Post by mto »

simongray wrote: post #250
omginternets wrote: post #219

Earlier quoted context omitted.

Can you elaborate on “Clojure can’t be parsed by IDE”? Surely some amount of static analysis is possible.

The same amount of static analysis as Python, Ruby, or any other language that doesn't have static type checking. Some people need something to happen when they press dot, though: https://www.youtube.com/watch?v=aSEQfqNYNAc

As I've been mostly using Python for the last 10 years I forgot how nice this dot thing can be ;). True that vscode and pycharm can give you something but I found that it's very often crap.

I am writing a little bit of C# atm and astonished how you can just dot tab through your work (without ever having read a tutorial or book on C#) and all those other contextual information you get with "full" visual studio. Somehow feels like just letting you guide through the work :).

On the other hand, the students I teach really struggle when they don't have all their IDE tricks. They learn almost exclusively C# at their institution in the first year(s) while my experience is mostly playing with Unity ;).

Re: The Future of Clojure

#295

Post by mto »

paultopia wrote: post #38
keithasaurus wrote: post #32

Having worked at a company with a large Clojure codebase, I just don't see Clojure growing. It's not well-suited to large projects. The dynamic-ness of it and awkward parts of the language (macros, protocols, ambiguity of laziness, etc) end up inevitably getting used in ways they aren't intended. The idea that you need "wise programmers" is a really big problem. People leave, institutional knowledge is lost, and then…

Maybe a broader version of this point: clojure tries to be something suited both for industry use at scale and for hobbyists wanting to do freaky-deaky stuff at the same time, but those are fundamentally incompatible. I say this as someone squarely in the latter category who has exactly the opposite problem from you: I love clojure the language and its features, but all the major libraries seem to be written by refug…

Yeah Python culture is generally pretty "direct". I did mostly python the last decade and got so used to "no problem to read the source of pytorch or whatever" that I meanwhile really feel challenged when I look at Java, C# whatever framework/library code to figure out where the abstractions end and the actual work is happening. My own code also became less and less abstract over time.

Re: The Future of Clojure

#296

Post by fulafel »

puredanger wrote: post #54
Xenoamorphous wrote: post #46

Earlier 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.

Yep, this works.

Re: The Future of Clojure

#297

Post by fulafel »

ertucetin wrote: post #57
puredanger wrote: post #54

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).

The GP didn't say 2 weeks to effective, it was for learning the basics. Or do you disagree with that as well?

Re: The Future of Clojure

#298

Post by prepor »

aeoleonn wrote: post #222
pinchhit wrote: post #181

As a person who has and currently does work professionally in clojure (at multiple all-clojure shops): The smart engineer effect is extremely overblown. You will hire smarter-than-average engineers, but with a caveat that no one talks about: they are all self-selected for being people who enjoy tinkering on computer science problems to a fault, and not necessarily your business. So the breakdown is that you get 10 su…

At a contract job, I had to use ReAgent, ClojureScript's "this compiles into ReactJS" framework. Wow, what a pain-- all I could think is "Why don't we just use Reactjs?". Clojure itself is decent. But as you mention-- "n practice everyone expects you to use poorly-maintained clojure-ish libraries to paper over the java/javascript bits, which get out of date quickly.' That is indeed the problem I saw.

> Why don't we just use Reactjs?

"Dealing with immutable data in JavaScript is more difficult than in languages designed for it, like Clojure. "

From React's docs.

Re: The Future of Clojure

#299

Post by silver-arrow »

puredanger wrote: post #86
atdixon wrote: post #27

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…

I use Clojure because I am not a particularly wise programmer (I have been fortunate to work with many actually wise programmers). I like to write dumb, obvious code. Most Clojure code is about taking your data, representing it a sequence of maps, and transforming them into different sequences of maps. The maps are open (easy to change over time), immutable (impossible to encounter data races, weird equality semantic…

This is an excellent comment and it matches my experience with the language very closely. After a career with many languages and paradigms (C, C++, Java, javascript, Swift...), then pushed to do Clojure the past 3 years, all the points you make above became so obvious that is in now EXTREMELY painful to work in any of the other languages.

I think a couple pain points need to be remedied in the community so that Clojure is more inviting to the general programmer, who like you mentioned would ultimately have an easier time with Clojure once bootstrapped into the language.

The primary one for me was being met with Emacs out of the gate as the preferred and touted editor for Clojure. I dove into that for a good year, became proficient with it but sorely regretted it. It was a decision point and cognitive hurdle I wish wasn't even presented to me in the beginning. IntelliJ/Cursive or something like it is a better way for most newcomers.

Earlier books on Clojure were way to "intellectual" in my opinion and pretty offputting to the general programmer. Luckily that area has improved in recent years with books such as "Getting Clojure" and "Programming Clojure"

Also the newcomer could be confused about what a repl is and how it functions with the IDE or editor. It would be better if editors and plugins focused on raw Socket or prepl repls over middleware repls like nrepl.

I would hope actually that some resources in the community would make an awesome LSP Server for Clojure so that any editor that supports LSP would have a great Cursive like experience. "clojure-lsp" is a great start but needs more resources.

The points made above by puredanger are so very true in my experience and I am so lucky and joyful to be working on Clojure systems.

Re: The Future of Clojure

#300

Post by kingdomcome50 »

bird_monster wrote: post #282
kingdomcome50 wrote: post #281

Earlier quoted context omitted.

Of course there is. That's not my point.

??? You literally posted that using a statically typed language prevented breaking changes?

Did I literally post that? You might want to reread my comment.

I can say from experience for every language above, save C++ (with which I have never worked), that they will fail to compile if you change a function signature in a backwards-incompatible way and fail to update all call sites.

The purpose of static typing as a method of program verification is to enforce type constraints at compile-time for all possible executions of that program. A function signature is, you guessed it, a type constraint.

Post reply on HN