I have been looking at functional languages for frontend. But, I guess I am one of those people who just can't unsee the parentheses in lisp languages .
How does clojurescript compare to elm/purescript ?
In the last week, I've done this 2 or 3 times: I've opened some Clojure/CLJS file of mine in a text editor, did a search-and-replace of all open- and close-parens to a single space.
Then I ask if they've seen Python before, to which most say 'yes', and I say, 'there you go, it's Python now'. And I can immediately see the look of surprise when they see that _similarity_, because the similarity is then hard to unsee!
I recommend that trick to any others trying to open minds and challenge preconceived notions in their surroundings. :-)
Side note: I've made the point that nested SQL expressions have many nested parens, too, which we've all done. And that the sum of parens+brackets+braces is similar to other languages, just the distribution is different. Neither of those 2 arguments work as well -- I guess because it's not visual and striking?
Hmm, I feel like such a revelation would break down fairly quickly. What happens when you check equality somewhere, or add two numbers? It's not only parens everywhere (although that is quite the eyesore), other things like prefix notation also makes lispy code unpleasant to read.
This approach reminds me of when people say, hey JS has classes and constructors just like Java does! And then proceed to write Java in JS.
I think it's interesting how much people's aesthetic preferences differ on lisp syntax. Personally, I think the parentheses are visually appealing, but it's probably an acquired taste. Even more than that, I actually now find it much more difficult to parse infix notation for math, equality and so on (and not just operators in syntax-heavy languages like Haskell). Prefix notation, while requiring a different reading style, is incredibly clear and unambiguous as long as no one's gone macro-crazy on you.
I use Clojurescript and love it, and also really like Elm. I think the difference is that the Clojurescript community is really on the leading edge of web application development techniques. Elm does it all right, in a similar way, but more basic. In Elm you're also encouraged to develop UI's with no private state and a single Immutable app data structure, but that strategy only gets you so far. Om has the concept of cursors to deal with this, and Om Next will have the evolution of that in a GraphQL type solution which I think is the future.
So basically I'd do any serious development with Clojurescript. Elm is a really cool thing with a small community that's fun to mess around with.
I disagree strongly. I think we'll see more and more developers moving towards Elm's model for exactly the reason you've mentioned. It's simple.
Not only that but having a single source of truth for your app's state, using only pure functions and non-stateful components to render your view allows you to do things like:
- build a time traveling debugger
- serialize your app's state and store it in your session so that users see exactly the same view when they log back in
- trivially do server side rendering
I have yet to be convinced that stateful react/virtual-dom components and/or GraphQL add any tangible benefits in the majority of cases.
Sorry if it wasn't apparent but I agree / advocate strongly for what you mention, and we use that model at my company. If you look at how Om evolved though, it started out with that simple model of passing the state object down to child components. Then cursors were implemented to make it easier to pass around parts of your global state without having components needing to know everything.
GraphQL doesn't mean moving to stateful components, it's just a nicer way to have a singleton data store because instead of chunking and passing a map around, components can declare which data they need. In that system components are still read only, and dispatch to external pure functions.
This is really true. I've recently moved to CLJS from Ruby/vanilla JS, and it took a couple weeks to be able to make sense of it. Now I don't notice it at all. It's just an exposure / getting-used-to-it thing.
Having paredit makes me miss LISP when I'm not writing it. It just makes moving around and restructuring code so much easier than it is an a C-based language.
> How does clojurescript compare to elm/purescript ?
Clojurescript is a Lisp with dynamic typing, Elm/Purescript are ML dialects where (static) typing is much more important, in Purescript more so than Elm.
I think Elm is interesting because it takes a rather uncompromising FRP approach to web development. Clojurescript does not strive for the same degree of functional fundamentalism.
CLJS is a dynamically typed mostly-functional strict uncurried lisp, Purescript is a very Haskell-inspired languages, Elm is syntactically similar but less welded to Haskell, it's strict, it doesn't implement many features (where clauses, pattern guards) and concepts (e.g. typeclasses, HKT) and strongly focuses on FRP and frontend interactive programming instead.
PureScript is a very principled pure functional language with a design based on Haskell but adapted to be compatible with JS (it adds extensible records, which are a great fit for JS objects). The type system should really pay itself off in the long run in terms of significantly lowering the cost of refactoring pretty much anything [1]
Additionally, I find that algebraic data types are by far the most natural and complete way to model your data and pattern matching is a powerful way to write succinct and readable code that manipulates that data. The fact that Lisps don't normally come with ADTs (incl. clojure) is a real shame.
PureScript got its own Hoogle [2] recently. It lets you search for functions by stating their argument and result types. This has worked far better for me than any IntelliSense, and its miles ahead compared to rummaging through the docs of a dynamic language hoping to hit a jackpot.
Although the community is small, the speed at which the language and its libraries are moving is quite amazing. For the cases where a package doesn't yet exist, its very easy to write FFI bindings to an existing JS library
On the minus side, there is no "template purescript" yet, and generic deriving is WIP, so some things (like JSON serialization) are still a bit more tedious than absolutely necessary.
The efficiency of the generated code may also be a concern. For example, currying is implemented in such a way that a function call with 3 arguments always generates both the result and 2 temporary JS closures. This can be very costly in certain situations. I find that library documentation is also sometimes lacking, however types and typeclasses do help with that somewhat (the latter only once you learn what each typeclass means).
Finally, something to keep in mind if coming from JavaScript: unless you know Haskell the learning curve for PureScript is far steeper than ClojureScript. Its about as steep as Haskell's. There is a great book available to help with that [3], and almost all of the the knowledge gained there will easily transfer to Haskell. Since PureScript compiles to readable JS, looking at the compiled code made it much easier for me to understand the mechanics of certain features (Eff <-> thunks in particular was quite a revelation) which in turn helped me understand those features
I haven't used ClojureScript much, but it does seem to have more mature, battle-tested persistent data structures (vs purescript-maps) and UI library (om vs purescript-halogen, although halogen seems very promising). There is also a type system (core.typed) which while not as principled as PureScript's, its still amazingly expressive - and since its gradual, you can start fully dynamic and then add types whenever you feel like doing that to parts of the codebase.
Shen is executable sequent calculus. It's data types are sequents, the conditions specified as arbitrary lisp (shen). Wikipedia seems to classify Shen as having algebraic data types, although it's type system isn't derived from ML or Cateogry Theory.
How does clojurescript compare to elm/purescript ?