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

Six Years of Professional Clojure

engineering.nanit.com

Post reply on HN
Print view View original

31–40 of 254 posts

Re: Six Years of Professional Clojure

#31

Post by Zababa »

taeric wrote: post #15
EdwardDiego wrote: post #11

> An incoming HTTP request? it is a plain Clojure dictionary. I learned to code in Python. Loved it. Dynamically typed dicts up the wazoo! Then I learned why I prefer actual types. Because then when I read code, I don't have to read the code that populates the dicts to understand what fields exist.

To be fair, an incoming request is, almost by definition, dynamic. It makes sense to have that as a map, since the main sensible thing to do on receipt is validation/inspection. Granted, you may have a framework do a fair bit of that. Depends how much you want between receipt of the request and code you directly control.

Usually the approach in a statically-typed language is to transform your dynamic request into something that you know through parsing instead of validation. Here's a great article about this: https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va....

Re: Six Years of Professional Clojure

#32

Post by lostcolony »

aliswe wrote: post #19

> ... and the question regarding choosing Clojure as our main programming language rose over and over again If I find myself having to repeat myself justifying a certain decision time and time again, it's an indicator that the decision needs to be revised to be something which is a more intuitive fit for the organization.

Not really; it's like stoplights. You're going to be interrupted and therefore notice the red lights, and just sail easily through and thus not notice the green lights. Likewise, you're going to notice the pain points, but need to take a minute to reflect to notice the benefits.

Really, if repeating the same justifications convinces people, then the problem isn't the justifications.

Re: Six Years of Professional Clojure

#33

Post by k__ »

dgb23 wrote: post #3

I found one of the perceived weaknesses of Clojure (in this article), it being dynamically typed, is a tradeoff rather than a pure negative. But it applies that tradeoff differently than dynamic languages I know otherwise and that difference is qualitative: It enables a truly interactive way of development that keeps your mind in the code, while it is running. This is why people get addicted to Lisp, Smalltalk and si…

I think, the big issue with dynamic typing in popular languages like PHP and JavaScript are the automatic conversions.

Re: Six Years of Professional Clojure

#34

Post by girishso »

dmitriid wrote: post #6

One thing I don't like about all articles on clojure is that basically all of them say: ah, it's just like lisp with lists `(an (example of) (a list))` with vectors `[1 2 3]` thrown in. So easy! But then you get to Clojure proper, and you run into additional syntax that either convention or functions/macros that look like additional syntax. Ok, granted, -> and ->> are easy to reason about (though they look like addit…

Agreed. These days I'm really fascinated by clojure and trying to learn clojure. Other than the project setup and repl and the editor (which I had considered), these weird characters are throwing me off.

What clojure really needs is some kind of opinionated framework or starter template, something like create-react-app. That has all these things figured out so a beginner like me can start playing with actual clojure, which documents all the steps to setup the repl and editor and what not. The last time I asked for this I was told about lein templates, they help but there's no documentation to go with those.

There needs to be some push from the top level. create-react-app was produced by facebook. Elm reactor (which lets you just create a .elm file and play with elm) was created by Evan the language creator himself.

tldr: There's a huge barrier to start playing with clojure that needs to come down and the push needs happen from the top level.

Re: Six Years of Professional Clojure

#35

Post by lostcolony »

sramsay wrote: post #30
taeric wrote: post #16

Earlier quoted context omitted.

That is possible with all languages. I've seen java, scala, clojure, perl, python, etc. Usually this is made worse by bespoke build tools and optimizations that make the system punishing to pick up.

You've seen a case where someone wrote something in Python that later devs could not understand and then rewrote it in . . . what? And you've seen that with Java? There's a big difference between a developer going off and writing something in one of the top five most used languages in the world and doing so in Scala.

Both are strange and alien to Javascript developers, who can be full stack.

Python may seem simple once you know it, but going in blind there's plenty of traps to bite you. Significant whitespace for one.

Re: Six Years of Professional Clojure

#36

Post by mollusk »

ronnier wrote: post #10
dmitriid wrote: post #6

One thing I don't like about all articles on clojure is that basically all of them say: ah, it's just like lisp with lists `(an (example of) (a list))` with vectors `[1 2 3]` thrown in. So easy! But then you get to Clojure proper, and you run into additional syntax that either convention or functions/macros that look like additional syntax. Ok, granted, -> and ->> are easy to reason about (though they look like addit…

Single engineers will pick clojure at companies , build a project in it, later that engineer will move on, now nobody can maintain this code so it’s rewritten in some normal language. I’ve seen that happen a few times. That code is hard to read and understand. This is why clojure will remain niche.

You need a team that wants to use Clojure. I wrote Clojure professionally for 2 years, and everyone at the company was excited about it and sold on the language. Even after 3-5 years of programming in it. Now, at a different place, we write in a different language, and even though I still love Clojure, I'm not gonna write some project in it, even if Clojure might suit it so well, because I know these people are sold on different language, and I'm not going to preach and I'm not going to make their lives more difficult by having to maintain some obscure codebase.

Re: Six Years of Professional Clojure

#37

Post by elwell »

k__ wrote: post #33
dgb23 wrote: post #3

I found one of the perceived weaknesses of Clojure (in this article), it being dynamically typed, is a tradeoff rather than a pure negative. But it applies that tradeoff differently than dynamic languages I know otherwise and that difference is qualitative: It enables a truly interactive way of development that keeps your mind in the code, while it is running. This is why people get addicted to Lisp, Smalltalk and si…

I think, the big issue with dynamic typing in popular languages like PHP and JavaScript are the automatic conversions.

Which is less of a concern considering Clojure's focus on immutability.

Re: Six Years of Professional Clojure

#38

Post by uDontKnowMe »

girishso wrote: post #34
dmitriid wrote: post #6

One thing I don't like about all articles on clojure is that basically all of them say: ah, it's just like lisp with lists `(an (example of) (a list))` with vectors `[1 2 3]` thrown in. So easy! But then you get to Clojure proper, and you run into additional syntax that either convention or functions/macros that look like additional syntax. Ok, granted, -> and ->> are easy to reason about (though they look like addit…

Agreed. These days I'm really fascinated by clojure and trying to learn clojure. Other than the project setup and repl and the editor (which I had considered), these weird characters are throwing me off. What clojure really needs is some kind of opinionated framework or starter template, something like create-react-app. That has all these things figured out so a beginner like me can start playing with actual clojure,…

There is the widely used Luminus framework https://luminusweb.com/

Re: Six Years of Professional Clojure

#39

Post by ivanech »

I started working professionally with Clojure earlier this year and this article rings true. I think the article leaves out a fourth downside to running on the JVM: cryptic stack traces. Clojure will often throw Java errors when you do something wrong in Clojure. It's a bit of a pain to reason about what part of your Clojure code this Java error relates to, especially when just starting out.

Re: Six Years of Professional Clojure

#40

Post by achikin »

ronnier wrote: post #10
dmitriid wrote: post #6

One thing I don't like about all articles on clojure is that basically all of them say: ah, it's just like lisp with lists `(an (example of) (a list))` with vectors `[1 2 3]` thrown in. So easy! But then you get to Clojure proper, and you run into additional syntax that either convention or functions/macros that look like additional syntax. Ok, granted, -> and ->> are easy to reason about (though they look like addit…

Single engineers will pick clojure at companies , build a project in it, later that engineer will move on, now nobody can maintain this code so it’s rewritten in some normal language. I’ve seen that happen a few times. That code is hard to read and understand. This is why clojure will remain niche.

It could have been Go and Java programmer trying to understand it. Or it could have been some clumsy tool written in node which Go programmer finds hard to read and understand. Clojure's main advantage is that you can you can learn it very very quickly up to the point when you understand most of the code, the language is very very small compared to "five main languages".
Post reply on HN