Live data from Hacker News

Try Clojure

tryclojure.org

101–110 of 404 posts

Re: Try Clojure

#101

I know many people will have problems with this post, but I am posting as information for clorjure-ophiles. Not reasons, but personal reasons why I don't do Clojure and will not try it. 1. When I read about Clojure (repeatedly) I like it. I am especially interested in transducers. I even built a half baked transducer engine in JavaScript using generators. There is clearly something here of value here. Any system that…

> It was okay until someone wrote a thing in php (!!) in a day that would be have taken at least a month in Java. Maybe two. I understand the "good" of Java, but for me personally, the cost of that good is just incredible tedium. This is personal and I understand that. You understand that this has everything to do with Java and nothing to do with the JVM, right?

It's everything to do with the libraries people pick and not Java the language. Java the language can be extremely concise and expressive. Stop picking Spring and Java becomes fun again.

Re: Try Clojure

#102
post #90

Earlier quoted context omitted.

Development in Go will always be more painful for some people than in Clojure or TS, because the language is intentionally hostile to abstraction, so you're thinking in higher level concepts, but you implement them in more steps than necessary. The program can never reflect the shape of the problem, because it will be riddled with "glue code" that implements the obvious dull steps that you abstract away when reasonin…

> There's no better or worse here, just two types of people. No, two types of solving a problem. I like writing both (Haskell and Go) - for _myself_ - but the tooling and standard library and ... of Go is orders of magnitudes better.

I would refrain from comparing Haskell - a research language intended for academia and created in universities, to Go - a pragmatic industry language intended for production and created in a megacorp. Why would Haskell's tooling be better? It's not reasonable to expect that.

Re: Try Clojure

#103

I know many people will have problems with this post, but I am posting as information for clorjure-ophiles. Not reasons, but personal reasons why I don't do Clojure and will not try it. 1. When I read about Clojure (repeatedly) I like it. I am especially interested in transducers. I even built a half baked transducer engine in JavaScript using generators. There is clearly something here of value here. Any system that…

> It was okay until someone wrote a thing in php (!!) in a day that would be have taken at least a month in Java. Maybe two. I understand the "good" of Java, but for me personally, the cost of that good is just incredible tedium. This is personal and I understand that. You understand that this has everything to do with Java and nothing to do with the JVM, right?

PHP avoids many of the hassles of deployment that pretty much any other language does.

Re: Try Clojure

#104
post #90
post #79

Earlier quoted context omitted.

As a side note, I'm always amazed by people who can use a highly expressive language (Clojure, Rust, even TS) but switch to Go when they feel like it (especially pre-1.18). To me, switching to a less expressive language is painful and infuriating. I remember having to switch from Python to Java 5, and how everything started to take 3 to 5 times longer code to express. Maybe the key thing is to only write small things…

Development in Go will always be more painful for some people than in Clojure or TS, because the language is intentionally hostile to abstraction, so you're thinking in higher level concepts, but you implement them in more steps than necessary. The program can never reflect the shape of the problem, because it will be riddled with "glue code" that implements the obvious dull steps that you abstract away when reasonin…

While I share your perspective on go, I do prefer developing in a bottom-up way myself: I just do so with the intent of iterating my way to a higher level abstraction. Sometimes I see the abstraction right away and start with it, but I don’t want a language that gets in my way in either direction.

Re: Try Clojure

#105
post #83
post #57

If you are new to Clojure and would like to experiment with it in a way that is immediately useful, I highly recommend the Babashka runtime for scripting [0]. It's very fun, approachable, and one of the more polished parts of the Clojure ecosystem. It's a particularly good entry point because unlike full-JVM Clojure it has a very fast startup time. Newcomers can use any file-watching /reloading tools (e.g. nodemon) t…

And when you're ready to take the fun to the web, look no further than Biff: https://biffweb.com

I recently went through most of the Biff tutorial but found it seemed to be missing some parts later on that had me scratching my head. It was otherwise a very enjoyable experience and Biff seems like a great way to get a "batteries included" starting point for web (similar to something like Rails or Django, though maybe not as comprehensive as either of those).

Re: Try Clojure

#106
post #98

Earlier quoted context omitted.

Another neat thing is that these functions are n-ary, and that includes 0 args. So (+) => 0 (additive identity) and (*) => 1 (multiplicative identity). Little things like this are missing from languages like Python and make functional programming worse than it should be.

Oh wow, this is truly great! Would you have a link to the code behind `(+)` and `(*)` ? (In my functional programming languages, `reduce` also requires passing an initial value, like `foldl (+) 0 [1, 2, 3]`. But surely it should get a monoid instead of two separate arguments for the operation and the starting value!)

Of course `+` and `*` are special, but defining such functions yourself is possible: https://clojure.org/guides/learn/functions#_multi_arity_func... https://clojure.org/guides/learn/functions#_variadic_functio...

Re: Try Clojure

#107

I'm happy with TypeScript, Go, and Rust. Don't feel like learning anything else.

I'm with you. I'll even go a step further, since I haven't heard anybody else say this:

My hot take -- There are already too many programming languages in use and every engineers life would be easier and productivity would be higher if we standardized.

There is almost no situation where making an entirely new language is the optimal solution. And the worst reason of all to make a language is anything aesthetic (e.g. spacing, parentheses, notations) -- all of those cases should be handled via native transpiling in the IDE.

Re: Try Clojure

#108
post #90

Earlier quoted context omitted.

Development in Go will always be more painful for some people than in Clojure or TS, because the language is intentionally hostile to abstraction, so you're thinking in higher level concepts, but you implement them in more steps than necessary. The program can never reflect the shape of the problem, because it will be riddled with "glue code" that implements the obvious dull steps that you abstract away when reasonin…

While I share your perspective on go, I do prefer developing in a bottom-up way myself: I just do so with the intent of iterating my way to a higher level abstraction. Sometimes I see the abstraction right away and start with it, but I don’t want a language that gets in my way in either direction.

The thing is, in Go you can develop bottom-up, but you can't always end up with a an appropriate abstraction, because of the lack of tools to achieve that.

Re: Try Clojure

#109
post #22

Earlier quoted context omitted.

In my experience, the subsets of the community around clojure were one of the biggest problem with it. It's gotten better over the years, but circa 2016 - 2018 it had a spike in popularity despite being very hostile to newcomers. There was an almost apologist attitude towards rough edges or failure modes folks new to the community would fall into. I managed to work with it for a time despite that, but it left me with…

> ...had a spike in popularity despite being very hostile to newcomers. To be fair the community itself, as humans, was very welcoming to newcomers. Really super nice and helpful folks. If anything was "hostile" it was the dominance of emacs and very limited options for other tooling. That, and the horrifically unhelpful leaky abstractions in the stack trace when something went wrong. It's a big step, if you don't al…

the tooling is the reason i gave up when i was interested in learning clojure. everywhere pretty much said that emacs was the "correct" editor to use for clojure, i tried it out for a bit but ultimately learning a new language and a new editor at the same time was just too big of an ask.

i tried calva with vscode afterwards but it was basically the same thing, calva has paredit which overrides the keyboard navigation and there was no way to disable it. somebody had asked for the option to disable it on the github but the creator said something along the lines of calva without paredit wasn't the way he wanted it to be used, so i just picked another language to learn.

Re: Try Clojure

#110
post #4

I love clojure, but it's really lost a lot of the momentum it had as many imperative languages have adopted parts of functional programming (and much for the better) over the last many years. On the other side I've felt a lot of the ecosystem work that was done has a more "timeless" quality. Coupled with java interop I haven't ever felt wanting when I do reach for it for some hobby projects I keep up with. One thing…

Should have maintained a python interoperable runtime. Less and less people use JVM languages for things like web apps, data eng, data science, ML, etc.
Post reply on HN