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

Try Clojure

tryclojure.org

Post reply on HN
Print view View original

311–320 of 404 posts

Re: Try Clojure

#311

Post by yiyu_earth »

cageface wrote: post #296
DeathArrow wrote: post #292

I wonder why no functional language has the degree of success imperative or OOP languages have. Is functional programming too weird for majority of computer programmers? Is functional programming not optimal for solving industry problems? Maybe there is no functional programming that that is up to some set of standards? Is functional programming too complicated? I do enjoy functional programming myself, and while I d…

Functional programming languages haven't gone mainstream but functional techniques are very common now. Higher order functions, immutable data structures, declarative UI frameworks, etc are things you're quite likely to encounter in a contemporary codebase these days.

[dead]

Re: Try Clojure

#312

Post by gpderetta »

nine_k wrote: post #79
jakebasile wrote: post #67

I'm glad this is back. A version of this existed in the ancient past and helped encourage me to try Clojure which ended up being by far the most impactful decision in my professional life. It went away for a while for reasons I'm unclear on. I use Clojure nearly daily at my job and at home. Sometimes it's standard Clojure, sometimes it's the excellent Babashka flavor which I use as a make-like task runner and Zsh-lik…

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…

As a C++ programmer, I definitely like my languages with extra legs nailed on.

But sometimes limitations can spur creativity.

Re: Try Clojure

#313

Post by gpderetta »

fire_lake wrote: post #271
nine_k wrote: 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…

Python is the new Java 5 here. The lack of multiline lambdas is incredibly awkward, leading to code that bounces you around the file.

Lack of multiline lambdas is infuriating, but nested named functions partially make up for it.

Re: Try Clojure

#314

Post by cess11 »

ErikCorry wrote: post #290
cess11 wrote: post #97

Earlier quoted context omitted.

Java has had lambdas, map/filter/reduce and other stuff for like ten years or so I think. It's a bit chatty for sure, but that's what you want sometimes, the verbosity can make it easier for newcomers to make changes and additions. To me it isn't more infuriating than learning a new language or practicing one I'm not very good at. There's a bit of friction, but that's common when I'm developing in the languages I'm m…

These Java features are ruined by not allowing mutable variables to be captured. Having to do the 1-element array trick when the compiler could just do it for me is insane. If you are making JavaScript look good you are failing as a language.

Typically I can use a forEach in such cases, and when I can't it's probably an incrementer and the IDE just switches out my int as an automatic solution to its complaint.

I think its OK to be reminded that the context is mainly immutable when chaining on a stream.

Method polymorphism to achieve default parameter values is a much worse nuisance, but not particularly hard to get used to when one decides to focus on the problem rather than the inevitable warts of a broadly useful programming language.

Edit: Also a pretty weird complaint in a thread about a programming language where pretty much all the basic data structures are immutable. Maybe take it to the top and make the quip about worse than JavaScript with regards to Clojure?

Re: Try Clojure

#315

Post by stefcoetzee »

memothon wrote: post #212

My favorite part of working in clojure is how easy it is to do common data structure operations. map, filter and reduce are extraordinarily powerful, especially when combined with the other core library functions.

With Specter [0] to lend a hand for more uncommon operations. ;)

[0] https://github.com/redplanetlabs/specter

Re: Try Clojure

#316

Post by pjmlp »

didibus wrote: post #291
pjmlp wrote: post #277

Earlier quoted context omitted.

The various JVM implementations have mechanisms to fix that, like JIT caches and AOT compilation, which Clojure doesn't take advantage of. So it is indeeed a Clojure issue, not a JVM one.

Can you talk more about these?

AOT compilation with PGO, available for free on GraalVM and OpenJ9.

Also available since around 2000 from comercial vendors, of which, Aicas and PTC are the main survivors.

https://www.aicas.com/wp/products-services/jamaicavm/

https://www.ptc.com/en/products/developer-tools/perc

OpenJ9 also does JIT caching across executions, https://eclipse.dev/openj9/docs/aot/

OpenJDK also does caching but at higher level,

https://docs.oracle.com/en/java/javase/22/vm/class-data-shar...

https://wiki.openjdk.org/display/HotSpot/Application+Class+D...

Project Leyden plans to add a similar JIT cache like on OpenJ9, https://openjdk.org/projects/leyden/notes/02-shift-and-const...

Azul and OpenJ9 have cloud JIT servers, that share execution heuristics and dedicate servers for highly optimizing compilers,

https://www.azul.com/products/prime/cloud-native-compiler-fa...

https://eclipse.dev/openj9/docs/jitserver/

Finally, although technically not really Java nor JVM, the Android Runtime (ART), does a mix of high performance interpreter written in Assembly, JIT, AOT compilation, and PGO sharing across devices via Play Store (cloud profiles).

https://source.android.com/docs/core/runtime/configure

Re: Try Clojure

#317

Post by phforms »

nathants wrote: post #259

the best reason to learn clojure is reagent[1], by far the best way to use react. shadow-cljs[2] makes using npm libraries easy. i’ve settled on go backends and reagent frontends as my default setup[3]. 1. https://reagent-project.github.io/ 2. https://github.com/thheller/shadow-cljs 3. https://github.com/nathants/aws-gocljs

Reagent is nice and has been around for about a decade now, but I moved away from it towards very thin wrappers around React[1], because I felt like it was adding too much additional complexity on top of React, which is already quite complex on its own. I wanted a clearer view at what is going on and a simpler way to interop with native React components.

Although it seems to catch up with experimental support of React 18 now, Reagent has fallen behind the latest developments in React and may not benefit from all of its performance optimizations. It is still using class components instead of hooks and there have been concerns that the runtime conversion of Hiccup may drag down performance. I guess in most cases it is not really an issue or in any way noticable, so if you’re not doing any fancy stuff it should be fine. I may even come back to Reagent at some point, since I have to admit that I miss the UI-as-data model with Hiccup.

What I highly recommend, however, is using re-frame[2] for state management. It has also been around for a long time (2014, around the same time Reagent came along) and pioneered some popular ideas in that area. It may seem a bit overwhelming at first, but the docs provide a great introduction and I find the model very clear once you wrap your head around it. At the moment it depends on Reagent, but there are ways around that. [3]

[1]: see Helix (https://github.com/lilactown/helix) or UIx (https://github.com/pitch-io/uix)

[2]: https://day8.github.io/re-frame/

[3]: refx (https://github.com/ferdinand-beyer/refx) is an almost drop-in replacement without the Reagent dependency, but hasn’t been updated in a while. Alternatively, re-frame can be integrated with UIx/Helix by adding some interop code https://github.com/pitch-io/uix/blob/master/docs/interop-wit...

Re: Try Clojure

#318

Post by camelspotter »

this example shows how "elegant" closure treats syntax errors, almost looks like a bad joke.

=> (+ 2 2 + 3)

"4function Cg(a){switch(arguments.length){case 0:return Cg.s();case 1:return Cg.g(arguments[0]);case 2:return Cg.h(arguments[0],arguments[1]);default:for(var c=[],d=arguments.length,e=0;;)if(e<d)c.push(arguments[e]),e+=1;else break;return Cg.j(arguments[0],arguments[1],new gc(c.slice(2),0,null))}}3"

Re: Try Clojure

#319

Post by BaculumMeumEst »

hpeter wrote: post #293
BaculumMeumEst wrote: post #223

Clojure is a really interesting and well designed language with bad error messages and bad official tooling. It feels very sloppy. Compared to Go, it has a weak stdlib, is more memory intensive, and generally slower. You get beautifully concise code but it can be very hard to follow (or return to after time away). Go can look completely idiotic or unbelievably focused and practical, depending on the light. It is pain…

"weak stdlib": You can use the Java ecosystem, most of the things you need are there "it can be very hard to follow": I agree, if you are not a lisp developer it's really hard, but if you develop clojure everyday, it's as easy as anything else. The answer is usually clean code when it comes to clojure. Keep your functions small. "more memory intensive, and generally slower": yep, the JVM is more memory intensive than…

Having projects that make significant usage of interop feels kind of gross, but I guess that is an option yeah. Pig-latin java is probably less fun to write than Go.

Regarding difficulty reading code, I'm not talking about syntax, I'm talking about the fact that many libraries define their own DSLs and you _cannot understand what they are doing_ by reading the code, you have to dig into the library internals to make sense of how they actually work, particularly when documentation is lacking or outdated.

Many problems can be solved by either language, and I wish it was easier to justify reaching for Clojure.

Re: Try Clojure

#320

Post by ertucetin »

dheera wrote: post #260
jakebasile wrote: post #67

I'm glad this is back. A version of this existed in the ancient past and helped encourage me to try Clojure which ended up being by far the most impactful decision in my professional life. It went away for a while for reasons I'm unclear on. I use Clojure nearly daily at my job and at home. Sometimes it's standard Clojure, sometimes it's the excellent Babashka flavor which I use as a make-like task runner and Zsh-lik…

The "j" is always what put me off from learning Clojure. I've had too many bad experiences with JDKs and JVMs that I stay a thousand kilometers away from any thing that has "J" in it unless it's referring to JavaScript.

You can also try ClojureScript, which runs on JavaScript. If you're developing frontends.
Post reply on HN