[jaredly]

I was going to have a section on Elm, and then the post got too long :) Clojure(script) feels much more mature, and general-purpose. Elm is client-only, not nearly as many libraries, etc.

Would clojure's readability be helped by having a non-lisp pretty-printer? I've been thinking about this a bit - s-exps are great for writing, but fails to take advantage of our advanced visual pattern matching when reading it.

[rlander]

Cool, do write about your Elm experiences, I'd be interested to read!

Unfortunately, yes, Elm is restricted to the browser. But this might change in the future. And although it is somewhat tedious to write ports, IME Elm communicates better with JS than ClojureScript. You can just drop any old JS library and write a port for it (it will be async, though).

Sexps alone don't bother me at all. What bothers me (and I only came to this conclusion recently, after reading this[0]) is the interplay between functional code and the absence of type annotations. Sometimes it feels like Lisp just wants you to write clever code, all the time. Clever Python code looks bad. Clever Lisp code looks pretty nice.

[0] http://elbenshira.com/blog/the-end-of-dynamic-languages/

[gered]

It's interesting to hear from someone else who also finds that Clojure/Lisp code can be difficult to read. I worked with Clojure professionally for 2 years and had started to think that I was the odd one out since everyone else I worked with was just gushing over the readability of the code. At times it could be easy to read, but very often I found it hard to follow and would have to spend more time then others deconstructing what was happening.

Which is not to say that I didn't like working with Clojure. I very much did. But it always seemed to be such a chore to read others code or code I hadn't seen in a few months or more. I remember on occasion showing some snippets of code to a co-worker and commenting that I thought there was too much "clever" code in there, that it was too dense and hard to follow. The co-worker didn't agree with me though, and I guess I just resigned myself to the idea that I was the odd one out here or something.

Ultimately, I think I ended up coming to the same conclusion as you. My way of thinking (and reading code apparently) just clicks so very much better with typed languages.

(I hope no one reads my post and treats this as some kind of attack on Clojure/Lisp and s-exps. It's not. I'm just noting that the style just doesn't jive with certain types of people. And I gave it plenty of time (2 years as noted above) before coming to that realization.)

[rlander]

And I thought I was the oddball ;)

Yup, sometimes it's easier for me to understand somebody else's OCaml/F#/Elm code than Clojure code written by myself. I still love working with Clojure, though. Go figure...

[hendekagon]

what aspects of the text made the code hard to read for you ? Was it the parens ? If LISP was displayed in the editor without parens (but still had them behind-the-scenes), so that the code was formatted much like Python, then would it be acceptable ?

[jaredly]

I just listened to this podcast[0], and there's a really great discussion in there about when it's nice to have types, and when it's more trouble than it's really worth.

That's why javascript's flow[1] appeals to me so much, and I'm really interested in core.typed.

[0] http://giantrobots.fm/172 [1] http://flowtype.org

[rlander]

Love that podcast. I'll check it out later today, thanks.

About core.typed, just be aware that it comes with its own set of issues[0]. I've been down that road and it wasn't great.

[0] http://blog.circleci.com/why-were-no-longer-using-core-typed...

[ihm]

> You can just drop any old JS library and write a port for it (it will be async, though).

Actually, it's pretty simple to wrap Javascript functions so that you can call them directly from Elm. See e.g. [0] which is called from Elm here [1].

[0] https://github.com/elm-lang/core/blob/master/src/Native/Colo...

[1] https://github.com/elm-lang/core/blob/master/src/Color.elm

[platz]

Elm's reactive model is best suited to UI's in my opinion. There's no good way to limit the data coming at you in a push-only model, so if you can't keep up with the incoming data flow bad things happen. On the UI this case usually isnt encountered, but on the server one needs mechanisms to deal with this

[Matthias247]

It can also happen on UIs:

Imagine you subscribe to lots of realtime data sources (e.g. via websocket), that deliver lots of updates to your UI. Then you have a race condition whether you can draw the updates faster than you receive them.

In an eventloop environment like Javascript it could be self-regulating (http/ws stack wouldn't receive new frames until you return from drawing. But it might also be not (because a C++ background thread in your browser receives the messages and queues them until they can be pushed to JS) - then you might get out of memory. But I totally agree that it's an exception for UIs to deal with such scenarios, but it should be normal an a server.

[d13]

I went through the same debate with myself earlier this year, and finally decided to go with Elm. But, 100% of my work is client-side web, and has been for 15 years, so having a tool specialized in that field makes sense for me.

[grayrest]

> non-lisp pretty-printer?

Brandon Bloom's fipp[1] works fine but the Chrome Canary dev tools have support for object formatters. I get reasonable results on .170 just doing a (js/console.log a-map).

[1] https://github.com/brandonbloom/fipp