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

321–330 of 404 posts

Re: Try Clojure

#321

Post by nathants »

phforms wrote: post #317
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 Reac…

you think reagent is more complex?

i don’t even know what the difference between hooks and classes are, reagent has never given me a reason to care.

if that’s not simplicity, i don’t know what is.

if i were to build a 3d high performance game in react, maybe i’d experiment with dropping reagent. instead i’d just use cpp.

not sure why people want yelp complexity websites to be 3d games.

i love react! i absolutely do not care about the details. never have…

Re: Try Clojure

#322

Post by zakkor1 »

camelspotter wrote: post #318

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"

That's a bug in the JS interpreter they're running, not anything related to Clojure. Also, that's not a syntax error

Re: Try Clojure

#323

Post by kaba0 »

ReleaseCandidat wrote: post #93
kubb wrote: 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.

Well, you are comparing the tooling of haskell and go. Of course in this comparison the difference will be stark, but there are plenty of languages that are sanely expressive, unlike go, and has decent tooling around it, like java, c#, perhaps scala if you want even more expressivity.

Re: Try Clojure

#324

Post by kaba0 »

nXqd wrote: post #298
vaylian wrote: post #256

Earlier quoted context omitted.

> 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 reasoning. How does this affect readability when one tries to dive into an existing Go project? Is Go code harder to navigate than code in more expressive languages?

We shouldn't overestimtae the complexity of expressive language like Clojrue vs Go. Go is perfectly simple and easy to follow, even compared with Clojure. If you come from background of Computer Science or programming first, Go is easier to follow.

I always feel this comparison is a fallacy. Assembly is also perfectly simple and easy to follow, like each instruction is trivial. Yet you will fail to grasp the whole, as “you are zoomed in too close”. I feel go has a good scale for many kind of tasks, but at the same time, it lacks the expressivity to change the zoom level, which I feel is needlessly limiting and makes the language a bad language for problems that require a slightly higher level of abstraction.

Re: Try Clojure

#325

Post by silcoon »

camelspotter wrote: post #318

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"

Not a syntax error. TryClojure is running on SCI which is a interpreter that uses a Babashka version for Clojurescript compiler, not Clojure JVM.

Babashka cli returns this, telling you clearly what the error is:

   user=> (+ 2 2 + 3)
   java.lang.ClassCastException: clojure.core$_PLUS_ cannot be cast to java.lang.Number [at :1:1]

Re: Try Clojure

#326

Post by kaba0 »

cess11 wrote: post #97
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…

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…

The funny thing is, go is significantly more verbose than even decade-old java.

Re: Try Clojure

#327

Post by kaba0 »

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.

You mean not having the error that go just fixed by changing the language is a problem?

Re: Try Clojure

#328

Post by kaba0 »

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.

Well, there aren’t too many more stable platforms out there, so your experience elsewhere couldn’t be all that cloudless either.

Re: Try Clojure

#329

Post by ReleaseCandidat »

kaba0 wrote: post #323
ReleaseCandidat wrote: post #93

Earlier quoted context omitted.

> 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.

Well, you are comparing the tooling of haskell and go. Of course in this comparison the difference will be stark, but there are plenty of languages that are sanely expressive, unlike go, and has decent tooling around it, like java, c#, perhaps scala if you want even more expressivity.

> and has decent tooling around it, like java, c#, perhaps scala

All of these are perfectly mediocre and usable languages (in which I would write in if somebody pays me), but surprisingly even for myself I ended up really liking Go.

Re: Try Clojure

#330

Post by kubb »

vaylian wrote: post #256
kubb wrote: 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…

> 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 reasoning. How does this affect readability when one tries to dive into an existing Go project? Is Go code harder to navigate than code in more expressive languages?

This would depend on the size of the project, and the difficulty of the solved problem.

With a simple problem, and a small codebase, Go is easier, because you need to know less language constructs.

With a complex problem, and a large codebase, a more expressive language is easier if used properly, because it can highlight what's important in the solution. The ratio of signal to noise when reading code is higher.

Post reply on HN