[flagged]
Try Clojure
81–90 of 404 posts
Re: Try Clojure
#82Earlier quoted context omitted.
On the contrary - I think it's much easier! The real advantage of this notation is that it's much, much easier to stack calculations. Example: (/ (+ 34 68 12 9 20) 140) You can imagine how the first part of that could come about: (+ 34 68 12 9 20) And then the second part (pseudocode): (/ sum 140) In Clojure it's easy to mash them together, or for example to paste the first calculation in the second. (/ (+ 34 68 12 9…
I'd take the verbosity over having to count the operators from the start of the line to figure out which one are used at the end of the line "1.5 2"
The parenthesis highlight in any decent editor. So it always very obvious which operators apply to the operands.
Re: Try Clojure
#83If 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
Re: Try Clojure
#84[flagged]
Type your Clojure symbolic expressions here
=>(+ 1 2)
3
=>(* 1 2)
2
=>(* 2 2)
4
=>(/ 100 10)
10
=>Re: Try Clojure
#85[flagged]
=>(def ÷ /) =>(def × *)?
Re: Try Clojure
#86There is XSS in the (my-name) part :)
(my-name "")
Re: Try Clojure
#87That's a great introduction, but... how to do an if statement would've been cool to add in the tutorial.
[deleted]
Re: Try Clojure
#88[flagged]
What a bizarre critique of LISP, which allows you to arbitrary define symbols to mean literally anything.
Re: Try Clojure
#89I'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…
I write less boilerplate in Go than in Rust, about as much in Go (but of course different ;) as in Haskell).
Re: Try Clojure
#90I'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…
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 reasoning.
There's a population of people that don't like this kind of abstraction, because to understand the code you first need to understand the problem, the data flow and how it's expressed. They prefer to look at the issue "bottom up" than "top down", and for them Go is perfect, because instead of reasoning about what the module does, how the data flows, what the algorithm does, they can focus on the small: this is a loop that iterates through a slice, this is an if condition that depends on this variable.
There's no better or worse here, just two types of people. Some like to look at the whole bridge, some like to examine the individual nuts and bolts and joints.