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

Six years of professional Clojure development

falkoriemenschneider.de

Post reply on HN
Print view View original

181–190 of 209 posts

Re: Six years of professional Clojure development

#181

Post by _6pvr »

iLemming wrote: post #177
void_mint wrote: post #159

Earlier quoted context omitted.

Yeah, it seems like programming language decision is, at least in part, a proxy for "At what point do you want to be held accountable for your program's correctness at runtime?" Haskell/Rust - Immediately Java/C#/Go - Relatively quickly Dynamic Languages - Whenever you decide it becomes important

It's a bit of an oversimplification, I think. Even though Clojure is not a statically typed language, it does have a type system. Here's an example what Clojure.Spec lets you do. When I was working for a fintech company, we built a suite of specs for a ledger. Based on those specs we could generate data. And it wasn't just some set of key/value pairs with completely randomized numbers. It would generate "a proper" le…

I'm not familiar with Clojure Specs, but it definitely sounds exactly like the "Dynamic language implements type checking tooling to assert correctness", as referenced in the above post. The spec website just looks like type assertions as "validation" - what am I missing?

> Even Nodejs doesn't always let you re-use code between backend and the front.

This is not true. Check out Lodash. It's a dependency of pretty much every FE and BE NPM package that exists. Ignoring rendering libraries like React, client side JS and backend JS are "just" JS.

> I've never experienced the joy of creating such robust, predictable, and reliable software with any other (statically typed or otherwise) language before.

I think you should definitely keep doing the things that bring you joy!

Re: Six years of professional Clojure development

#182

Post by 59nadir »

fulafel wrote: post #176
void_mint wrote: post #159

Earlier quoted context omitted.

Yeah, it seems like programming language decision is, at least in part, a proxy for "At what point do you want to be held accountable for your program's correctness at runtime?" Haskell/Rust - Immediately Java/C#/Go - Relatively quickly Dynamic Languages - Whenever you decide it becomes important

Whether you get strong assurance of correctness from static typing depends on your domain, are you're working with a closed-world app like a compiler, or a talking to the rest of the world a lot? Though it's telling how little static checking by type systems is leveraged eg in LLVM, so even in closed systems the assurance payoff for static checking doesn't necessarily get good bang for the buck. Eg working with web b…

> Eg working with web based services, your code tends to communicate a lot with other services, and a very large % of bugs that make it further out than your dev laptop come from those interfaces. Making these part of the closed world of the static type system is done in some places but most static language users elect not to do it, preferring programmable checks in form of schemas or tests.

Are you actually suggesting that "most static language users elect" to not decode at the boundaries of their system because it somehow is favorable to not do so? This does not match my perception of things, neither the "most are not decoding" part nor the "it's fine to not decode into a known good structure" part.

> It's an attractive idea to hedge your risks by usign a static language even if it only catches the trivial bugs and slows you down, because statically found bugs are a falsifiable observation, wheras making programming easier, faster and more fun[1] in general doesn't leave hard evidence unless you run duplicate trial projects just for science.

What an incredible straw man you've built up, but then you just let it sit there and don't even burn it up.

Since I'm not here to convince anyone, I can say your straw man is the opposite of my experience. I've never been able to prototype and change a system in any phase of its lifetime faster than I've been in Haskell. Haskell has downsides, but speed of development and maintenance is one of its strong points.

> I tend to think of static vs dynamic as a mindset question, where our bias of loss aversion rears its head.

Re: Six years of professional Clojure development

#183

Post by void_mint »

59nadir wrote: post #178
fulafel wrote: post #154

Earlier quoted context omitted.

> Do you really want a dynamic language, or do you just want the ability to be careless intermittently? [...] I just think, as a codebase in a dynamic language grows, codebases seem to build lots of tooling to make that dynamic language less dynamic. I think this is getting closer to the interesting questions. It's often a good thing that when the product matures and moves more into maintenance mode, you can then inc…

> If you had a rigid system and slow turnaround from the start, you might not have gotten off the ground to get that far. I always see people say this and on the surface it seems to make sense, but I also always wonder what "rigid system" they're talking about. It's much, much faster to make big changes in every phase of a project in Haskell for me than it is in Elixir, so this is the perspective I'm seeing this from…

It's funny - I see that sentiment all the time ("Static typing is slower to get going with") and I kinda chuckle. In both static and dynamic languages, in the beginning, you're not doing anything silly. In both scenarios, you likely aren't writing your methods that accept strings and then immediately trying to pass them ints. For two developers of the same proficiency, competing to generate value in a static vs. dynamic language, I suspect the first 10 hours or so of building a project would progress pretty similarly. Compilers don't really fight with you until there's lots of hidden complexity.*

*Haskell and Rust get a lot of flack because of their compilers being difficult for beginners to work with. I don't necessarily think this is actually an issue - for a sufficiently skilled Rust or Haskell dev, I doubt most compiler errors feel like a "fight".

Re: Six years of professional Clojure development

#184

Post by iLemming »

_6pvr wrote: post #181
iLemming wrote: post #177

Earlier quoted context omitted.

It's a bit of an oversimplification, I think. Even though Clojure is not a statically typed language, it does have a type system. Here's an example what Clojure.Spec lets you do. When I was working for a fintech company, we built a suite of specs for a ledger. Based on those specs we could generate data. And it wasn't just some set of key/value pairs with completely randomized numbers. It would generate "a proper" le…

I'm not familiar with Clojure Specs, but it definitely sounds exactly like the "Dynamic language implements type checking tooling to assert correctness", as referenced in the above post. The spec website just looks like type assertions as "validation" - what am I missing? > Even Nodejs doesn't always let you re-use code between backend and the front. This is not true. Check out Lodash. It's a dependency of pretty muc…

> This is not true. Check out Lodash.

Respectfully, as someone who spent over a decade building front-end apps, I'd say: the code re-use between js in the browser and js in node still feels limited in comparison with Clojure/Clojurescript approach.

I'm not talking about utility libraries.

Re: Six years of professional Clojure development

#185

Post by void_mint »

iLemming wrote: post #184
_6pvr wrote: post #181

Earlier quoted context omitted.

I'm not familiar with Clojure Specs, but it definitely sounds exactly like the "Dynamic language implements type checking tooling to assert correctness", as referenced in the above post. The spec website just looks like type assertions as "validation" - what am I missing? > Even Nodejs doesn't always let you re-use code between backend and the front. This is not true. Check out Lodash. It's a dependency of pretty muc…

> This is not true. Check out Lodash. Respectfully, as someone who spent over a decade building front-end apps, I'd say: the code re-use between js in the browser and js in node still feels limited in comparison with Clojure/Clojurescript approach. I'm not talking about utility libraries.

Because you chose to bake environment information into your code, that does not mean nodejs doesn’t support client/server reuse. Respectfully.

Re: Six years of professional Clojure development

#186

Post by iLemming »

void_mint wrote: post #185
iLemming wrote: post #184

Earlier quoted context omitted.

> This is not true. Check out Lodash. Respectfully, as someone who spent over a decade building front-end apps, I'd say: the code re-use between js in the browser and js in node still feels limited in comparison with Clojure/Clojurescript approach. I'm not talking about utility libraries.

Because you chose to bake environment information into your code, that does not mean nodejs doesn’t support client/server reuse. Respectfully.

I never said "it doesn't support", it's just not the same.

Code re-use is just one of the aspects. When choosing a tool, especially a tool like a programming language, one needs to take "a holistic approach". Clojure is not a silver bullet. Neither is Haskell, Rust, or any other PL.

I like Clojure today, because today it makes sense for me to use it. For the projects I build. I'm sure, someday, it stops making sense for me to use it, and I will move onto something else.

You can use all sorts of arguments for people to try something else today, assuming they are just misinformed - either about Clojure or the other PLs (you're preaching about).

I can assure you though, most Clojuristas I know - didn't end up using Clojure by accident. It's a deliberate choice. After trying many other options.

Re: Six years of professional Clojure development

#187

Post by fnord123 »

Graziano_M wrote: post #163
Scarbutt wrote: post #141

Earlier quoted context omitted.

Your hello world actually took one second to start, add libraries for a web application and you will be hitting 2-3 minutes of startup time.

That's actually not correct at all. Hello World is slow because you have to start up the JVM. Once it's started it's rather fast. Your web application has the same JVM startup cost but not a lot more than that.

The jvm takes 50 ms to start. That's 620ms unaccounted for in Hello World.

Re: Six years of professional Clojure development

#188

Post by fulafel »

59nadir wrote: post #178
fulafel wrote: post #154

Earlier quoted context omitted.

> Do you really want a dynamic language, or do you just want the ability to be careless intermittently? [...] I just think, as a codebase in a dynamic language grows, codebases seem to build lots of tooling to make that dynamic language less dynamic. I think this is getting closer to the interesting questions. It's often a good thing that when the product matures and moves more into maintenance mode, you can then inc…

> If you had a rigid system and slow turnaround from the start, you might not have gotten off the ground to get that far. I always see people say this and on the surface it seems to make sense, but I also always wonder what "rigid system" they're talking about. It's much, much faster to make big changes in every phase of a project in Haskell for me than it is in Elixir, so this is the perspective I'm seeing this from…

I don't have Elixir experience, but the natural way to get started in modeling data and state in Clojure quite obviously involves less ceremony and scaffolding than what you do in Haskell, and is less work to change around.

Also, it's not just the amount of work, it's the complexity of the language. Clojure is really simple, so you don't h ave to spend much of your cognitive capacity juggling things related to the language or operating a mental simulation of the type system.

Re: Six years of professional Clojure development

#189

Post by tome »

void_mint wrote: post #183
59nadir wrote: post #178

Earlier quoted context omitted.

> If you had a rigid system and slow turnaround from the start, you might not have gotten off the ground to get that far. I always see people say this and on the surface it seems to make sense, but I also always wonder what "rigid system" they're talking about. It's much, much faster to make big changes in every phase of a project in Haskell for me than it is in Elixir, so this is the perspective I'm seeing this from…

It's funny - I see that sentiment all the time ("Static typing is slower to get going with") and I kinda chuckle. In both static and dynamic languages, in the beginning, you're not doing anything silly. In both scenarios, you likely aren't writing your methods that accept strings and then immediately trying to pass them ints. For two developers of the same proficiency, competing to generate value in a static vs. dyna…

> for a sufficiently skilled Rust or Haskell dev, I doubt most compiler errors feel like a "fight".

That's certainly true of my experience. I prefer to have the compiler there guiding me (My reference points are poorly-typed languages like C, Java and C++, and the dynamically-typed language Python. I've never used Clojure.).

Re: Six years of professional Clojure development

#190

Post by fulafel »

void_mint wrote: post #179
fulafel wrote: post #176

Earlier quoted context omitted.

Whether you get strong assurance of correctness from static typing depends on your domain, are you're working with a closed-world app like a compiler, or a talking to the rest of the world a lot? Though it's telling how little static checking by type systems is leveraged eg in LLVM, so even in closed systems the assurance payoff for static checking doesn't necessarily get good bang for the buck. Eg working with web b…

I don't particularly want to argue with you. Using the phrase "falsifiable observation", and then referencing "fun" as an argument just doesn't really work for me. I appreciate that you like dynamic languages, but I will not take your "rest of the world" bait. To suggest that dynamic typesystems are as verifiably correct as static typesystems is verifiably incorrect.

Not sure if this needs clarifying or not from your message but:

By falsifiable I meant that it's an observation that could be shown to be false, if it was false. So a concept from philosophy of science, not an assertion.

Post reply on HN