Clojure

File: 1428297651197.gif (12KB, 500x500px) Image search: [Google]

12KB, 500x500px

>>56341823
(Nothing?)

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

>>56341823
Another meme diversion from common lisp embraced by web hipsters.

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

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

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

>>56344467
I think a lot of people that use Clojure are Lispers, yo

File: 1453844847041.jpg (44KB, 750x366px) Image search: [Google]

44KB, 750x366px

>Clojure using the JVM

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

>>56344073

You could try ClojureScript or ClojureCLR... basically the same language with a different runtime environment.

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

>>56345852
ClojureScript is sexy. I like how you can set it up to update almost anything on a browser from a separate REPL.

https://youtu.be/MTawgp3SKy8?t=11m22s

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

>>56341823

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

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

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

>>56346954

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.

>>56341823
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:
>>56346861
>>56346896
>>56346954

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

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

>>56344572
>Common Lisp isn't really functional though,
And nobody significant cares about that.

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

>>56347093
>I just cannot stand java stacktraces - and often the most common errors spit them out.

There are libraries for that

>>56347097
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...
>>56347127
such as?

>>56347127
Can you recommend any good ones?

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

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

File: Oshasmile.png (31KB, 224x224px) Image search: [Google]

31KB, 224x224px

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.

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

>>56347093
Compiled CL is faster than Java iirc, mostly due to having some very mature implementations like SBCL.

>>56347653
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: https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=clojure&lang2=sbcl

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

>>56347905
Nah, Java is still faster... Though Clojure is a compiler, so it's not super-slow in comparison: https://benchmarksgame.alioth.debian.org/u64q/clojure.html

As for good books, I liked Joy of Clojure (http://www.joyofclojure.com/foreword/) and, while I haven't read it, I hear "Clojure for the Brave and True" is pretty good too (http://www.braveclojure.com/)... Of course, there are also problem sites like https://www.4clojure.com/

As for ClojureScript, I think the video in >>56346639 shows it off pretty well, though it is slightly dated.

File: Clojure.png (73KB, 800x664px) Image search: [Google]

73KB, 800x664px

Thoughts on this?
https://labs.ig.com/static-typing-promise

>>56347905
>Are there any good Clojure books out there yet?
If you already know some functional concepts, you could go through the language essentials here: http://clojure-doc.org/articles/content.html#essentials
...and solve 4clojure problems while doing it.

>>56348158
Oh, and this is a good language reference that explains the APIs pretty well too: https://clojuredocs.org/core-library

>>56341823
It's another nu-male language. Don't bother.

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

>>56344754
>CL is imperative, Clojure is functional like Scheme

CL is a horrible point of comparison.

>>56348686
Even so, it was the comparison in the quote.

>>56348195
Eh? I've seen Clojure called a lot of things, but that's a first.

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

>>56350642
I appears pretty well-suited for more than just that

>>56347644

i like emacs but i also have a cursive licence for intellij.

>>56347905

i liked clojure programming, but emerick, carper and grand that was published through o'reilly. didn't like the books on pragprog.

>>56341823

i don't mind the language. 1.10 introduces specs, i.e. validation of input and output, which i thought was a nice touch.

>>56344572

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.

>>56341823
lein is annoying as shit.

File: LFE.png (98KB, 600x600px) Image search: [Google]

98KB, 600x600px

>>56341823

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.


>>56344514

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

>>56351904

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