Not having to memorize an operator precedence table makes me more than willing to give up syntactic sugar. This is one of the things that I dislike most about haskell. I wish liskell or one of the other projects trying to bring S-expressions to haskell had taken off.
In that case you can either use $ or parenthesis in Haskell. I personally find the code neat without any parenthesis noise.
While this is a reasonable approach, it quickly breaks down when you look at code written by others who do not follow this approach.
I am a Ruby guy torn between diving into Haskell or Clojure. Help! Every time I get excited about one feature of one (ClojureScript) I learn the other has something equivalent or potentially better (Haste). One thing that has put me off on Clojure is 1) the ugly as hell JVM stacktraces, 2) hitting the wall of the number system results in nasty JVM errors if you are used to Ruby's trivial (to the developer at least) h…
That's the neat thing about Lisp-style macros. You have to sacrifice a little bit of the syntactical sugar that you are used to in most languages, but in return you have the ability to add almost any possible construct to the language natively. It makes it much easier to extend the language as you don't need to hack an interpreter written in C or Java. Half of the core language is already written in macros.
Not having to memorize an operator precedence table makes me more than willing to give up syntactic sugar. This is one of the things that I dislike most about haskell. I wish liskell or one of the other projects trying to bring S-expressions to haskell had taken off.
If I have the slightest concern about operator precedence while writing code, I put in extra parens. Because it will definitely hinder me reading the code later. Plus, Haskell doesn't use them much anyways. I'm sure the 9 and 0 keys get lonely.
This is called homoiconicity[0] and it's one of Clojure's coolest features in my opinion. [0] http://en.wikipedia.org/wiki/Homoiconicity
The concept of homoiconicity has yet to really sink in for me. Conceptually, I understand what it means and I can explain it to others but I have yet to really understand it in a practical sense.
Imagine if, instead of Javascript, you had a language based on JSON, with a few additional types, notably a 'symbol' type and a 'list' type. A few of the symbols are primitives that determine the semantics of the list type, allowing other symbols to be defined as functions.
That's homoiconicity, and Clojure strongly resembles an actual implementation of this conceit.
Oddly enough I never used this, but maybe named fns might help? ( http://clojure.org/special_forms#Special%20Forms--%28fn%20na... ) (fn my-name [] (throw (Exception. "boom"))) (Sorry, I don't know Clojure internals well enough to have great answers to your explicit questions.) [Edited: thanks to jerf for pointing out the inconsistency in a term I used.]
Named... anonymous... functions? Wuzzah fuzzah?
Yeah, that's a terminology issue. They mean lexically scoped named functions. Versus the default in Clojure of global or namespace scope.
I'd like to learn Clojure. Any suggestions on how to get started? It's my first time using a Lisp dialect. I figured I'd tackle the Clojure Koans, and mix in a few Project Euler problems.
I'd also like to do some code reading. I know the Clojure source code is on GitHub, but maybe something smaller to start?
If anyone else is interested in getting started, here are a few links I visited over the weekend:
The last link is an hour-long interview with Rich Hickey - a fantastic introduction to the language and his design goals. It's probably the best technical video I've ever watched on YouTube.
The benefits of lisp 'syntax' are legion, to the point that I've come to feel that your position is unprofessional. Why wouldn't you try to get passed something as superficial as syntax, in order to better _make_ stuff? 1) Easier to learn and remember syntax for polyglots. No more Googling, shit like "what was the syntax for try-with-resources or the new multi-catch feature in java"? 2) The language tooling is so muc…
Julia [1] has 3 and 5, and almost 1 (it has very few built-in syntax sugars and a uniform way of invoking macros). It's targeted at scientists, so 4 is not an option, as infix syntax is a hard requirement for mathematics. [1] http://julialang.org/ Edit: Elixir [2] is homoiconic as well, with even more uniform syntax (though it doesn't have special matrix syntax). [2] http://elixir-lang.org/
+1 for Elixir, really excited about it. Especially knowing it is built (like Clojure) on a very solid battle tested VM.
In that case you can either use $ or parenthesis in Haskell. I personally find the code neat without any parenthesis noise.
While this is a reasonable approach, it quickly breaks down when you look at code written by others who do not follow this approach.
When approach X isn't followed, approach X breaks down? True for all approaches, no?
Any language can be written poorly. I don't think any language will ever be able to force good coding style on programmers. Though Haskell comes closer to that impossible goal than many other languages, due to its type system, functional purity, and mandatory indentation.
One thing I've noticed is that the JVM startup time is actually pretty small. What's slow is waiting for Clojure to bootstrap itself.
That's true, but it's generally like this with any Java application. The JVM starts in 0.3 seconds, but loading all your classes usually takes seconds. I don't know the arcitecture well enough, but I think it's because it looks for classes in a lot of places and unpacks JAR files etc.
That of course depends on the number of deps that you have, but you have to have a _lot_ to reach into the second range.
That's the neat thing about Lisp-style macros. You have to sacrifice a little bit of the syntactical sugar that you are used to in most languages, but in return you have the ability to add almost any possible construct to the language natively. It makes it much easier to extend the language as you don't need to hack an interpreter written in C or Java. Half of the core language is already written in macros.
Not having to memorize an operator precedence table makes me more than willing to give up syntactic sugar. This is one of the things that I dislike most about haskell. I wish liskell or one of the other projects trying to bring S-expressions to haskell had taken off.
With haskell's type system most precedence errors are caught quickly. Precedence generally follows intuition: PEMDAS of course, and then the idea that control-flow operators like >>=, , etc should be lower precedence, while operators that tend to group expressions together like (.) should be high-precedence. Of course a lot of the time it's somewhat arbitrary, but this is because a lot of the time it just doesn't matter. In cases where things aren't clear, you can always choose to use parentheses.