Live data from Hacker News

Six years of professional Clojure development

falkoriemenschneider.de

31–40 of 209 posts

Re: Six years of professional Clojure development

#31

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)

That's true if you write everything on one line. But how could you fail to notice that most Lisp code is written on multiple lines and indented? The structure is visually laid out, so as not to be maintained in anyone's head.

Re: Six years of professional Clojure development

#32

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)

If you've seen 300+ line react components marching off the right of the screen, you'll know that maintaining the parse tree in your head isn't a barrier to popularity.

Re: Six years of professional Clojure development

#33
post #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…

I really like Clojure and I'm glad it is around, but I'll prefer something with strong types any day.

From the article I see a lot f reasons why:

> "Don't break things!" is part of the culture.

If you cannot have compile time guarantees on correctness, the discipline to not break things becomes a key feature. On the other hand, if you have strong correctness guarantees, you may more easily incur some breakage (and thus actually fix things).

> Some discipline required [...] with great freedom comes great responsibility.

There's always some discipline required, but without a type system discipline become more important.

> you often need to find specific places where a function or a piece of data is referenced [which is hard in Clojure] because there are no links established via a type system.

Yups. IDEs also like types to build their features on.

> Documentation becomes more important

I dont like documentation as a fix. Docs should tell me why some code is there, not what it does or how to use it (that is preferably obvious).

Again: I like the language a lot. I also like Ruby a lot. But when a new project with serious complexity requires me to pick language I go with something that has: no implicit nulls, strong type safety, sum types, exhaustivity checks.

Re: Six years of professional Clojure development

#34

Earlier quoted context omitted.

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

So you're saying there's absolutely no loss of readability in something like Lisp opposed to Python?

Re: Six years of professional Clojure development

#35
post #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…

What is mutable by default in Clojure? Nothing. You need to explicitly declare mutable variables with a special notation. Are you talking about the underlying VM? Yes, the Java API are mutable, not surprise here, it's not Haskell.

Imperative? What is imperative by default in Clojure? Nothing. It's one of the least imperative Lisp, favoring functional constructs all over the place unlike Common Lisp or even Scheme.

Blocking IO. Ok. So you want JavaScript? You have async i/o lib for Clojure and the primitive of the language to create threads are relatively good (relative because the limitations come from the Java VM).

Zero guarantees at compile time. Almost true. It' s a dynamic language and does not pretend to be something else. It has pros and cons. Like modelling a domain is very simple since you almost always reuse the same datastructure and having ubiquious immutable datastructures build a solid foundation for an ecosystem of libraries.

Re: Six years of professional Clojure development

#36

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)

I love that you use 4 indirections before getting to you main, parenthetical, point.

Re: Six years of professional Clojure development

#37
post #33
post #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…

I really like Clojure and I'm glad it is around, but I'll prefer something with strong types any day. From the article I see a lot f reasons why: > "Don't break things!" is part of the culture. If you cannot have compile time guarantees on correctness, the discipline to not break things becomes a key feature. On the other hand, if you have strong correctness guarantees, you may more easily incur some breakage (and th…

If you constantly work on the same code base day-in, day-out, breakage through the language or libraries is much less of an issue. You can keep up with current developments in the language and/or libraries, and update as necessary. Incremental changes are not a big deal, since you’re always around when they happen.

If you tend to write code once, and come back to it months or years later, breakage is a huge issue - why is the code that was working perfectly well in 2019 broken today? Why do I have to now fix 4 dependencies in order to do what I actually wanted to do (make some small change). This is the reason that I tend to write all my own code in TypeScript projects, but for my Clojure/ClojureScript projects I am much more happy to pull in the occasional library.

I would say that the “don’t break things” culture is less about static vs dynamic types, and more about the style of software being written and the maintenance expectations.

Re: Six years of professional Clojure development

#38
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…

There’s always https://shen-language.github.io/

Re: Six years of professional Clojure development

#39

Clojure is the most enjoyable language I've ever used and I love the interactive development. I haven't written code in any other language that even comes close. Unfortunately I am too lazy and careless to use Clojure in any serious capacity though. I really need a Haskell or Rust compiler to remind me of all my silly mistakes. I can't be trusted to get to the same level of confidence through unit tests or linting or…

I wrote Clojure for 4 years. I understand your pain points. Dynamic types are an impediment beyond a certain code size.

Re: Six years of professional Clojure development

#40

Clojure is the most enjoyable language I've ever used and I love the interactive development. I haven't written code in any other language that even comes close. Unfortunately I am too lazy and careless to use Clojure in any serious capacity though. I really need a Haskell or Rust compiler to remind me of all my silly mistakes. I can't be trusted to get to the same level of confidence through unit tests or linting or…

I wrote Clojure for 4 years. I understand your pain points. Dynamic types are an impediment beyond a certain code size.

My experience with dynamic types comes from developing in Python. The projects I've seen were pretty healthy until a large enough part of the original team went away. Once enough people had to figure out their way by experimenting, the projects got messy.

I'm not saying this doesn't happen in Java or Go but the static typing enables easier code exploration. That makes code bases more readable to newcomers.

Post reply on HN