Live data from Hacker News

Six years of professional Clojure development

falkoriemenschneider.de

21–30 of 209 posts

Re: Six years of professional Clojure development

#21

Earlier quoted context omitted.

I don't think it's about it's dynamicism but more about it being functional. Plenty of super popular dynamic languages out there. I think that's also what keeps elixir from becoming something more mainstream, most people come from OOP and are used to thinking about programming that way.

Both of you miss the most obvious difference between Clojure and all mainstream languages: it's a lisp. I've had so many programmers look at code I write and proclaim: "wow that looks impossible because of the parenthesis" and that would never touch anything like it because it seems so different. Some people do take the time to learn how it works, but many just have a knee-jerk reaction to it and then forget about th…

I don’t think it’s the parents, but the s-expression themselves.

LISPs forces you to maintain the stack for the parse tree in your head, something humans aren’t that great at — s-expressions are the programming language equivalent of center embedding, which is quite alien for human languages (the depth is three at most: compare that to your favorite lisp program)

Re: Six years of professional Clojure development

#22
I loved clojure until working with it for a few years, with some of the famous best teams in Europe and America, including Cognitect people, who ill leave unnamed here.

I fell out of love when I realised what the language is - a mutable, imperative, blocking IO by default language with lambdas and zero guarantees at compile time. Effects happen at any time, as it is an imperative language. Just like JS with a better syntax but with blocking IO and Java threads.

Backends, when more than a handful coders program, turn to runtime checking all the time with spec or schema, and because it’s always up to you to make things async, things often end up depending on a handful of blocking calls. It’s not impossible to write good big programs in clojure, but when working with a group it does not tend to end up that way. Changing a program from sync to async with zero help from the compiler is a task that ends up requiring a lot of time, and negotiation, when it could’ve been the default.

In imperative languages, where you have no control over what effects run, programmers often turn to frameworks to square their program. In teams of >20ppl using clojure, it instead tends to become siloed, where a few people “own” a part of the code, and others must request changes there. It’s not a law of nature, but a pattern I’ve seen emerging in my experience working with clojure teams, including the very famous ones. Time spent negotiating and in these meetings is time wasted.

I should make sure to thank Clojure for getting me into lisp and emacs though, as well as Hickeys enlightening talks.

Re: Six years of professional Clojure development

#23

Earlier quoted context omitted.

Both of you miss the most obvious difference between Clojure and all mainstream languages: it's a lisp. I've had so many programmers look at code I write and proclaim: "wow that looks impossible because of the parenthesis" and that would never touch anything like it because it seems so different. Some people do take the time to learn how it works, but many just have a knee-jerk reaction to it and then forget about th…

Can you blame them though? Look at Python/Ruby where even non developers can sometimes understand the code and then look at some crazy Haskell/Lisp expression.

Yes, I do blame them for this because if you spend 10 minutes, any programmer can learn "some crazy lisp expressions" because they are not that crazy.

This knee-jerk reaction you're having is exactly the ones I'm talking about :)

Re: Six years of professional Clojure development

#26
post #6

Nice article. Sadly a lot of people won't even try clojure since it is dynamic typed. I see their point but nevertheless clojure does something really well here. As the author obserserves designing around some core data structures results in high code reuse. A library like spec is also way better in encoding business requirements than all the mainstream language typesystems e.g. a number in business context has mostl…

I don't think it's about it's dynamicism but more about it being functional. Plenty of super popular dynamic languages out there. I think that's also what keeps elixir from becoming something more mainstream, most people come from OOP and are used to thinking about programming that way.

I really like Clojure, it's the language that finally made FP "click" for me. It was my go to for hobby/side projects for quite a while.

Dynamic typing is why I eventually switched. Haskell scratches the same itches that Clojure did, but the compiler and type system are immensely helpful, and keep saving me from tripping over my own feet.

Re: Six years of professional Clojure development

#27
post #6

Nice article. Sadly a lot of people won't even try clojure since it is dynamic typed. I see their point but nevertheless clojure does something really well here. As the author obserserves designing around some core data structures results in high code reuse. A library like spec is also way better in encoding business requirements than all the mainstream language typesystems e.g. a number in business context has mostl…

Can we have a REPL-driven language that's statically typed? My hope is yes, in that it's just that the work hasn't been put in yet to create to create the equivalent of Typescript for Clojure or Lua that compiles down to the actual, extensible language. I always wish that it would become unnecessary to have to choose between stability and extensibility when selecting a programming language. Having a Clojure with stat…

You certainly can, OCaml and Haskell do. They were sadly not designed with S-expressions though.

Re: Six years of professional Clojure development

#28

Earlier quoted context omitted.

Both of you miss the most obvious difference between Clojure and all mainstream languages: it's a lisp. I've had so many programmers look at code I write and proclaim: "wow that looks impossible because of the parenthesis" and that would never touch anything like it because it seems so different. Some people do take the time to learn how it works, but many just have a knee-jerk reaction to it and then forget about th…

I don’t think it’s the parents, but the s-expression themselves. LISPs forces you to maintain the stack for the parse tree in your head, something humans aren’t that great at — s-expressions are the programming language equivalent of center embedding, which is quite alien for human languages (the depth is three at most: compare that to your favorite lisp program)

You might be right in the first part, and the "fear" of s-expressions are only expressed as a fear of parenthesis.

But on the second part I think that's the same as for most languages. You end up with nested scopes at the same degree as any c-like language really. But most lisp programmers tend to break out into new functions a bit earlier than let's say JS programmers. I'd argue that normally you'd have to keep track of less depth in a normal Clojure program than you would in a JS program, simply because of how a programmer usually works in those languages.

Re: Six years of professional Clojure development

#29

Earlier quoted context omitted.

I don't think it's about it's dynamicism but more about it being functional. Plenty of super popular dynamic languages out there. I think that's also what keeps elixir from becoming something more mainstream, most people come from OOP and are used to thinking about programming that way.

Both of you miss the most obvious difference between Clojure and all mainstream languages: it's a lisp. I've had so many programmers look at code I write and proclaim: "wow that looks impossible because of the parenthesis" and that would never touch anything like it because it seems so different. Some people do take the time to learn how it works, but many just have a knee-jerk reaction to it and then forget about th…

It’s just like C or JS but the first paren goes to the left of the function name.
Post reply on HN