That does Sup Forums think of Clojure?
Clojure
Other urls found in this thread:
youtu.be
benchmarksgame.alioth.debian.org
benchmarksgame.alioth.debian.org
joyofclojure.com
braveclojure.com
4clojure.com
labs.ig.com
clojure-doc.org
clojuredocs.org
twitter.com
(Nothing?)
It's got a solid ecosystem and it's a Lisp. I'd give it a serious shot if it weren't tied to the JVM. Racket is my go-to alternative.
I haven't written anything exclusively in Clojure yet, but I really want to because it's actually really fun.
I usually just embed it in Java applications because it's super-handy to be able to just fire up a Clojure server if something goes wrong, and play around with the runtime. I actually even have a playground file I use for exactly this.
It also lets me script little one-off things if someone wants something and I don't feel like making it in Java and either making a new release or redeploying.
Another meme diversion from common lisp embraced by web hipsters.
>I'd give it a serious shot if it weren't tied to the JVM
this, just the thought of writing something that has to call java classes in an ugly way disgusts me
I'd rather use something like Lisp Flavoured Erlang if I needed the cool VM features
Common Lisp isn't really functional though, it has some aspects of functional languages, but in practice side effects are everywhere.
Also, Clojure is a lot different to CL than most people think. That isn't a problem, mind you, but comparing the two is a pretty bad comparison I think.
I actually write in both, though I started with CL.
>Also, Clojure is a lot different to CL than most people think.
To expand on this:
>Clojure has almost everything as immutable whereas Common Lisp has almost everything as mutable.
>By default, everything in Clojure is lazy, and in CL it is not. (Though it is reasonably easy to add)
>Common Lisp has OMFGMacros and functions that are amazing when you know them (Like loop or format), wheras there is nothing nearly as complex in Clojure.
>Clojure encourages recursion, CL encourages iteration. (CL doesn't have TCO in its spec, though it is common nowadays)
>Clojure makes everything safely threadable, Common Lisp threads are considerably harder.
Basically, they both use parens, and both have a REPL, but the way you write code in each it waaay different.
I like how you can basically say "fuck it" and turn all of your function calls into threads without giving yourself a colossal headache.
I think a lot of people that use Clojure are Lispers, yo
>Clojure using the JVM
Fyeah, that's the best part of clojure. Easy parallelization ftw. Also, I like how it implemented so much approaches to concurrency while making them reasonably fast in order to compete even with Golang.
Jesus, loop and format are the biggest warts I saw in CL. Even the "Lisp weenies" call theme "un-lispy" - format's syntax is plain shitty, and loops keywords are a lot, and, let's face it: it's the worst way of controlling the flux of a program ever. I'm trying to learn racket now, and having seen that you basically use it to make a DSL that solves your current problem and use it - I probably will end up rewriting half of clojure to accomplish a lot of my tasks.
Also, the laziness, immutability and functional features borrowed from haskell are just awesome - they make me want to learn haskell as well; I think it won't be as useful though.
You could try ClojureScript or ClojureCLR... basically the same language with a different runtime environment.
I consider myself a Lisp weenie, and loop isn't universally considered bad. It's just, kind of an area that is heavily debated. I personally like it because it can often simplify complex iteration very tersely.
But yeah, I'll admit that Clojure's loop and recur are better for more complex problems because you can control exactly what you want to continue with, no matter how many things you do simultaneously.
ClojureScript is sexy. I like how you can set it up to update almost anything on a browser from a separate REPL.
Yeah, I know lispers that are fighting about it. I like its power and terseness, but honestly dislike the keyword thing.
I kinda like the clojure's loop/recur too, but knowing its internal implementation I suffer a little in using it.
Here's what's wrong: it's a dirty hack made by Rich Hickey to emulate TCO - which is notoriously absent from the Oracle JVM. AFAIK He firmly believes that it's up to them implementing it (and I think he's right), differently from the Odersky and the scala guys, who said "fuck it" and implemented TCO in scalac, which is the compiler.
So, since 'loop' is the only way to have true TCO in clojure (aside from trampoline) one has to rely heavily on it, whether he wants it or not.
look up Om and Reagent, when you've got some time (Reagent is better, newer and less 'hairy').
They are react-style frameworks based on the virtual DOM concept.
There's also Elm, which I believe to be even better, but it's based on haskell, and I haven't looked upon it, yet. People I know who used it speak about it pretty well though.
I must admin I dislike it's map syntax.
Also, it's version 1.9 now and the string handling of it's standard library is sub-par.
All in all, the language is pretty cool, but it's standard library is appalling --- and good luck getting your patches accepted by the Hickey.
I only use it because it's the best Lisp nowadays. Eagerly awaiting 2.0
what's wrong with
(map #(yourfunction) [1 2 3 4])
?
and what do the string manipulation lack? AFAIK you can handle strings just as they were arrays of characters, with the possibility to use standard java regexes on them...
right, I meant hashes, sorry
{:hello 1
:world 2}
Just the normal things like split/join/replace/trim/substring -- although things are improving, half of these in the clojure.lang namespace and half of these are in clojure.string. the third half (oh the irony) exists in java.lang.String or Javascript's string class.
> you can handle strings just as they were arrays of characters
Umm, Clojure runtimes will use native strings, so in JVM-land string are immutable, so this is a very leaky abstraction
So don't get me wrong, I like Clojure; it's that it's stdlib leaves a lot to be desired coming from Python, for example.
Exactly because of superior JVM interop capabilities, it relies on the Java stdlib too much.
I program stateful transactional systems, not scientific models etc. that lend more easily to functional languages, so I'm not on the Lisp/Clojure train whatsoever.
My general feeling is that languages with first-class execution state (closures and continuations) offer false temptations with mathematical purity in face of a reality where standard call-return flow control is the only paradigm that performs well on actual hardware.
Acting like you can replace a pure linear stack with a state tree and not suffer locality or fragmenting issues is nuts.
On the other hand, I can't imagine many people actually take much advantage of the more "powerful" aspects of these languages and roll their own coroutine or exception handling systems, etc., so this is probably not really an issue anyway.
I will admit that having that having some higher-order functions baked in is a thing not seen often enough in more standard systems programming languages that would be nice though:
Well, then what's wrong with hashes?
About strings: yeah, there's something that needs to be done about it. From one side, it's pretty understandable: whatever you can do with a string as an array may be found in clojure.lang, everything else clojure-string specific is found in clojure.string.
From the other, well... you're not so wrong about the java.lang.String thing. Probably Rich and his squad should step up their game and build a custom string class just for clojure - although it hardly would happen, since this is not among the "wrongest" things about clojure.
For example, the most urgent thing to do, IMHO, would be the error handling. I just cannot stand java stacktraces - and often the most common errors spit them out.
well, performance is not among the priorities of clojure - although now it's as fast as java (which is, contrarily to the popular beliefs, pretty dang fast). It's awesome to have the power of the limitless abstraction, though. AFAIK it's the best performing lisp actually widespread.
>My general feeling is that languages with first-class execution state (closures and continuations) offer false temptations with mathematical purity in face of a reality where standard call-return flow control is the only paradigm that performs well on actual hardware.
Really? I thought it was all an abstraction that makes it no more expensive than a normal function call after it gets compiled.
Clojure actually compiles all of its forms and the JVM bytecode is what eventually gets run, so as long as the compiler is smart, I don't think that it should have too bad an implication performance-wise.
>Common Lisp isn't really functional though,
And nobody significant cares about that.
It matters a lot in how you write code in practice though. Clojure and CL are like night and day because of its emphasis on this.
>I just cannot stand java stacktraces - and often the most common errors spit them out.
There are libraries for that
a couple of years ago clojure performed really, really bad. Like, an order of magnitude worse than the fucking scala.
But then Rich stepped up his game...
such as?
Can you recommend any good ones?
"normal" function calls aren't an issue, since they boil down to the same stack pointer management and simple saved instruction pointer returns.
it's all the wacky shit with closures that's really insidious, since it basically requires garbage collection and ruins all the O(1) guarantees a normal stack offers.
Interesting.
In practice I don't notice much, but I also don't know enough about it to find out the effects it really has. (But now I'm very curious actually)
So, what do you all use to write Clojure..?
I mostly use CIDER in Emacs, and sometimes combine that with Org Mode if I am trying to figure something out in Literate style.
It's pretty gnarly actually, especially since Org works great with CIDER these days.
I'm somewhat interested in Clojure now after this thread, but things like the lack of TCO and being tied to Java are very unfortunate. It seems more like Scheme than CL.
The idea that imperitive programs are the only one that will truly be fast because they're somehow closer to the operation of hardware has been disproven decades ago. Even discounting the fact that computers have been build in which the basic Lisp model and garbage collection are implemented in hardware. Things like TCO have made performance possible on a standard architecture without turning the stack into a mess.
Compiled CL is faster than Java iirc, mostly due to having some very mature implementations like SBCL.
You actually do get TCO, it's just not automatic. Things like functions and loop calls can be recursed with a "recur" call with the arguments you want to recur with. It's actually super-common.
Also, if Java isn't your thing, ClojureScript targets JavaScript. It's actually really nice even..! I had my doubts initially because I thought it would be hard to debug, but in actuality, it is often easier than vanilla JS, even with the ability to hotswap JS in things like Chrome's devtools.
>Compiled CL is faster than Java iirc, mostly due to having some very mature implementations like SBCL.
Well: benchmarksgame.alioth.debian.org
Neat, I expected clojure to be slow, turns out it's faster than regular Java. I'll have to check it out. Are there any good Clojure books out there yet? Something like Practical Common Lisp that dives straight into the guts of the language?
ClojureScript sounds cool, I'm no fan of JS either, but I imagine that it would be fun for lisp on the web shenanigans.
Nah, Java is still faster... Though Clojure is a compiler, so it's not super-slow in comparison: benchmarksgame.alioth.debian.org
As for good books, I liked Joy of Clojure (joyofclojure.com
As for ClojureScript, I think the video in shows it off pretty well, though it is slightly dated.
Thoughts on this?
labs.ig.com
>Are there any good Clojure books out there yet?
If you already know some functional concepts, you could go through the language essentials here: clojure-doc.org
...and solve 4clojure problems while doing it.
Oh, and this is a good language reference that explains the APIs pretty well too: clojuredocs.org
It's another nu-male language. Don't bother.
TCO doesn't begin to address the issues highlighted, since it just prevents unneeded growth of a linear stack.
Spaghetti stacks are a natural and unavoidable consequence of call-cc semantics, which is one of the primary things that functionalfags slobber over themselves about when boasting about the power of their paradigm, not being able to express iteration as recursion or whatever.
Also, the Lisp machines were hot garbage except for their keyboards, which were GOAT-tier.
>CL is imperative, Clojure is functional like Scheme
CL is a horrible point of comparison.
Even so, it was the comparison in the quote.
Eh? I've seen Clojure called a lot of things, but that's a first.
>Reagent
Hah, that's kinda cool! Though I don't think I'd use it for anything besides single-page webapps.
I should play around with it more though.
I appears pretty well-suited for more than just that
i like emacs but i also have a cursive licence for intellij.
i liked clojure programming, but emerick, carper and grand that was published through o'reilly. didn't like the books on pragprog.
i don't mind the language. 1.10 introduces specs, i.e. validation of input and output, which i thought was a nice touch.
Clojure isn't functional either. And idiomatic Clojure code involves heavy use of OOP abstractions, much unlike Common Lisp where CLOS seems to be rather optional.
I like it and I appreciate it's push for immutability. However I'd rather use a language that allows for mutability when I really want it and one that isn't restricted by the JVM. The lack of TCO forcing you to use recur and trampolines kinda sucks. They don't cover all possible tail call cases. Racket is also my go to language for general scripting and more serious OO and functional stuff and while it lacks the ability to call whatever bit of Java to do stuff, it has a fairly large library of functions and its ecosystem is growing quickly as they improve its package manager.
lein is annoying as shit.
Many "purists" frown upon the JVM, but I think it's great that Clojure exists. I haven't looked into it yet, since I'm not really a Java guy, but I like that the chances to find a job/company that actually uses a Lisp have grown a lot.
>I'd rather use something like Lisp Flavoured Erlang if I needed the cool VM features
Yay, nice. I didn't know about that one. Is it production ready?
Now I can have have pattern matching, guards, tail recursion, list comprehensions and a simple light weight concurrency modell. I will give it a shot.
>tail recursion
Uhm, yeah, I mean the Erlang way of tail recursion..
>But there's only one way..
Yeah, OK. Just forget it, will you?