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

301–310 of 404 posts

Re: Try Clojure

#301

Post by DeathArrow »

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.

That's what I said. I do use functional programming techniques, I just wonder why functional programming languages don't see a larger following.

Re: Try Clojure

#302

Post by ReleaseCandidat »

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?

Go really is the most "readable" code for anybody who has ever read something C (or Algol ;) like - so just about anybody. The only "strange" stuff is its `iota`, the method syntax and of course channels and goroutines. But that's nowhere comparable to some C++ or Haskell, "type heavy" Typescript or some Lisp macro DSL.

Re: Try Clojure

#303

Post by dgb23 »

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…

There are degrees and different shades of "success" and "functional programming".

Clojure is successful, stable and well maintained. However it is a niche language compared the big mainstream languages. It takes a functional approach by default, but doesn't shy away from other paradigms/patterns/idioms when appropriate.

Functional programming itself has had a huge influence on mainstream languages since about a decade and a half. More and more pragmatic features have been introduced in mainstream languages. Newer languages have adopted functional idioms from the get go. On the macro level as well, ops and architecture have been adopting statelessness, reproducibility and so on.

The consensus has shifted towards containing state. The more moving parts you have, the harder it gets to reason about a whole thing. Treating data as data.

OOP has also changed and got refined over this time. I think people realized that it has good ideas (generic interfaces, polymorphism etc.) and bad ideas (inheritance, local state etc.). Same thing with FP, there's stuff that's esoteric and too far from the reality of actual programming and stuff that is pragmatic and simplifying in there.

Re: Try Clojure

#305

Post by KingMob »

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.

Interesting. Usually the reluctance comes from people confusing Java the language with JVM the platform.

Re: Try Clojure

#306

Post by tmtvl »

didibus wrote: post #248
tmtvl wrote: post #174

So here's something which I, as a Lisper, don't understand: Clojure has syntax for hash tables (the curly braces), why doesn't it use those for let-bindings, instead choosing to use vector syntax? (Of course I prefer standard Lisp syntax which can easily be extended for multiple-value and destructuring bindings: (let ((a 1) ((b c) (list 2 3)) (d e (values 4 5))) `#(,a ,b ,c ,d ,e)) ;; => #(1 2 3 4 5)

What's so different to Clojure's ? (let [a 1 [b c] (list 2 3) [d e] [4 5]] `(~a ~b ~c ~d ~e)) ;; => (1 2 3 4 5)

But what would be the equivalent of:

  (let ((quotient remainder (floor x y)))
    (+ (* quotient z)
       (* remainder (floor z y))))
Where floor is a function which returns multiple values rather than a list or vector of results?

Also, but this is entirely on me being an absolute dullard, I like having the brackets around each binding as a kind of guardrails for my mind to not lose track of where I am and what belongs where.

Re: Try Clojure

#307

Post by globular-toast »

tasuki wrote: post #98
globular-toast wrote: post #32

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!)

Yeah, it always annoys me to have to pass an initial argument. The idea of identities is built into Lisps and seems conspicuously missing from other languages and I don't know why. In Python and JS people have to write stuff like `lambda x: x` over and over again. The identity function is surely special enough to get its own name.

Re: Try Clojure

#308

Post by tmtvl »

puredanger wrote: post #179
tmtvl wrote: post #174

So here's something which I, as a Lisper, don't understand: Clojure has syntax for hash tables (the curly braces), why doesn't it use those for let-bindings, instead choosing to use vector syntax? (Of course I prefer standard Lisp syntax which can easily be extended for multiple-value and destructuring bindings: (let ((a 1) ((b c) (list 2 3)) (d e (values 4 5))) `#(,a ,b ,c ,d ,e)) ;; => #(1 2 3 4 5)

Maps are unordered, but let bindings are sequential so order matters.

I see, so Clojure's let works like Lisp's let*. I didn't know that, thanks for the explanation!

Re: Try Clojure

#309

Post by pron »

fiddlerwoaroof wrote: post #241
pron wrote: post #190

Earlier quoted context omitted.

The JVM cold-starts, loads a Hello, World program from a compressed JAR, runs it and shuts down in 40ms. But Clojure compiles quite a bit of Clojure code generating hundreds if not thousands of classes and then loads them before starting up the Clojure program. Still, there's ongoing work on the JVM (Project Leyden [1]) to speed up both startup and warmup even of such programs by caching more state. [1]: E.g. see htt…

Back when I wrote Clojure professionally, using GraalVM to generate a native executable of things like clj-kondo basically eliminated the startup latency.

Right, but Native Image comes with its own tradeoffs. Lyeden's "premain" work aims to be somewhere between the situation today and Native Image.

Re: Try Clojure

#310

Post by voidUpdate »

harrison_clarke wrote: post #181
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…

i find i flip between different languages when i'm thinking about the problem in a different way an expressive language (clojure, python, C#, etc.) is good when you're iterating "what problem am i even trying to solve?" a less expressive language is typically better when you more or less know a high level solution to your business problem, and you're iterating on "how do i make the machine actually do it". like "how…

If you're counting C# as an expressive language then a lot of gamedevs will reach for one, judging by the market share of unity, me included :P
Post reply on HN