Live data from Hacker News

Six years of professional Clojure development

falkoriemenschneider.de

201–209 of 209 posts

Re: Six years of professional Clojure development

#201

Earlier quoted context omitted.

Do you really think referencing brainfuck, a deliberately difficult language, is the right way to get your point across?

> > > Good programming practice isn't a language feature its a programmer feature. > > I'll enjoy reading your production-grade brainfuck code. > Do you really think referencing brainfuck, a deliberately difficult language, is the right way to get your point across? I'm gonna assume you're not deliberately missing the point here and the confusion is genuine. You were initially indirectly saying that "it doesn't matte…

Brainfuck is not an example, its a strawman. If it was meant to be a joke, it sucks.

I really don't understand the automatic genuflection that lisp/forth/smalltalk get on HN. You can't make a bad programmer better by switching out the language.

I am guessing HN skews younger and never had to build boring production systems in these failures (note: my professional experience was years of fighting smalltalk).

For the vast majority of programming tasks, boring old java or c# or python have enough language features of the holy trinity now that smugly announcing to the world you are a clojure exclusive geek is a huge red flag.

Re: Six years of professional Clojure development

#202

Earlier quoted context omitted.

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.

Your comment was reddit-level bait. This comment is also reddit-level bait.

Enjoy your day.

Re: Six years of professional Clojure development

#203

Earlier quoted context omitted.

> > > Good programming practice isn't a language feature its a programmer feature. > > I'll enjoy reading your production-grade brainfuck code. > Do you really think referencing brainfuck, a deliberately difficult language, is the right way to get your point across? I'm gonna assume you're not deliberately missing the point here and the confusion is genuine. You were initially indirectly saying that "it doesn't matte…

Brainfuck is not an example, its a strawman. If it was meant to be a joke, it sucks. I really don't understand the automatic genuflection that lisp/forth/smalltalk get on HN. You can't make a bad programmer better by switching out the language. I am guessing HN skews younger and never had to build boring production systems in these failures (note: my professional experience was years of fighting smalltalk). For the v…

> You can't make a bad programmer better by switching out the language

Right; good programmer, though, another story.

> boring old java or c# or python

Many programmers using these were switched to them from something else, and in many cases are doing better work because of that.

Re: Six years of professional Clojure development

#204

Earlier quoted context omitted.

Brainfuck is not an example, its a strawman. If it was meant to be a joke, it sucks. I really don't understand the automatic genuflection that lisp/forth/smalltalk get on HN. You can't make a bad programmer better by switching out the language. I am guessing HN skews younger and never had to build boring production systems in these failures (note: my professional experience was years of fighting smalltalk). For the v…

> You can't make a bad programmer better by switching out the language Right; good programmer, though, another story. > boring old java or c# or python Many programmers using these were switched to them from something else, and in many cases are doing better work because of that.

If they moved on from lisp I'm 100% sure they are now able to do better work, largely because they no longer have to spend their days telling everybody they are a lisp programmer.

Re: Six years of professional Clojure development

#205
post #95

I've used Clojure for going on 10 years now and it has been one of the most enjoyable programming languages I've ever used. But I've gone back to Scheme for a few ridiculous reasons. 1. TCO. Using `recur` in Clojure just breaks my thought process. 2. Difficulty in getting down to the metal when needed. Using JNI is painful. In Scheme, when needed, the FFI usually handles plain old C. Much easier in my opinion. 3. Com…

I don't understand arguments of the kind: "Lisp A vs. Lisp B". A Lisp is a Lisp. I am honestly so grateful for my younger self for the decision I made years ago to learn Lisp. These days, pretty much any platform, any hardware, or a VM supports at least one dialect of Lisp. And that's awesome! I switch between Lisps with relative ease: Scheme, Fennel, Clojure, Elisp, Common Lisp - they feel pretty much the same langu…

> I don't understand arguments of the kind: "Lisp A vs. Lisp B". A Lisp is a Lisp. I am honestly so grateful for my younger self for the decision I made years ago to learn Lisp. These days, pretty much any platform, any hardware, or a VM supports at least one dialect of Lisp. And that's awesome!

“Lisp” is no more a language family than “curly braces" is. Individual Lisps are often further apart from each other than either from various other languages.

Re: Six years of professional Clojure development

#206

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…

> 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 suggesti…

> 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

I'm was thinking protocol meta systems like protobufs where you use tooling to enforce closed world style communication patterns in a networked world.

Re: Six years of professional Clojure development

#207
post #95

I've used Clojure for going on 10 years now and it has been one of the most enjoyable programming languages I've ever used. But I've gone back to Scheme for a few ridiculous reasons. 1. TCO. Using `recur` in Clojure just breaks my thought process. 2. Difficulty in getting down to the metal when needed. Using JNI is painful. In Scheme, when needed, the FFI usually handles plain old C. Much easier in my opinion. 3. Com…

I don't understand arguments of the kind: "Lisp A vs. Lisp B". A Lisp is a Lisp. I am honestly so grateful for my younger self for the decision I made years ago to learn Lisp. These days, pretty much any platform, any hardware, or a VM supports at least one dialect of Lisp. And that's awesome! I switch between Lisps with relative ease: Scheme, Fennel, Clojure, Elisp, Common Lisp - they feel pretty much the same langu…

> I switch between Lisps with relative ease

The only relevant measure is: how much actual code do you switch?

Because otherwise that's just like saying "I switch between brain surgery, jazz saxophone, chess and rock climbing with relative ease".

Re: Six years of professional Clojure development

#208
post #26

Earlier quoted context omitted.

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.

Somewhat off topic: My problem with Haskell is that every time I've tried to read the documentation, I've felt like I needed a PhD in type theory to understand all of the terminology. As a practitioner (not a researcher), I just want to know how to do things, but the documentation has always been a roadblock to me. So, after a number of attempts at learning to use Haskell, I've decided its not for me. Not because of…

This. I think I understand the basic concepts, but you get a first big slap with doing your first curl to some other service. Ergonomics of the libs is often times horrible. You are in this constant loop, oh I can't do this I need algebraic derationalizer to align those types. Several hours later your curl request works. You start looking at wall to decompress. Curl is a pretty good example its a complexity that has been made super easy in a lot of languages.

I am very much waiting for some "extremely" constraint subset/flavour of Haskell that gets some adoption(I do not think I am alone in this lobby). No crazy stuff, no "just read the types", no "its just a small extension". But I also know that it is not really feasible without breaking the IO enforcements.

Re: Six years of professional Clojure development

#209
post #33

Earlier quoted context omitted.

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…

> 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. Which language is that?

Haskell, OCaml, Elm
Post reply on HN