6 ms·

I had Haskell as the subject in my intro course at university (my first experience with functional programming). I've tinkered a bit with it since then as well,

I had Haskell as the subject in my intro course at university (my first experience with functional programming). I've tinkered a bit with it since then as well, and I'm at the "somewhat intuitive grasp of monad transformers" state. I tried Clojure some week ago through the Clojure koans that were posted here. Compared to Haskell I found the syntax very obtuse and it was not obvious why Lisp would be more powerful than Haskell. The bare-bones syntax felt more like a "proof of concept" than an actual strength. (of course, the koans took less than a day to do so I'm not dismissing Clojure because they didn't impress me, but I got the idea that the koans were an attempt to showcase Clojure's strengths)

artursapek 14y ago
Do you go to Yale?? Haskell school of music?
gajomi 14y ago
I would advise checking out the problems at http://www.4clojure.com/ http://www.4clojure.com/ over the koans. You will definitely find some challenging problems. The nice thing about these is that you can look at how other users all solving the problems, which helps to convey a sense of style. I haven't done a problem in awhile, but I oftentimes gotten something out of looking at solutions from 'amalloy' and 'chouser' in particular. Of course, you can also check out my own ('gajomi') solutions :).
- nemetroid 14y ago
  Thank you. I will check it out when I get some spare time.
chimeracoder 14y ago
> I found the syntax very obtuse and it was not obvious why Lisp would be more powerful than Haskell. The easiest answer to that is, there's no syntax, which makes reimplementing your own Lisp parser trivial (one single function call, in fact). This in turn makes reimplementing your own Lisp, inline in Lisp, similarly trivial. That sounds like something out of an SICP exercise - and it is - but the same properties make it easier to reason about your code in a way that's far more abstract than other languages let you. Once you start treating your code as data that other parts of your code can manipulate, you can start refactoring in ways that simply aren't possible in other languages. This explanation by a well-known Perl programmer explains it very well: http://lists.warhead.org.uk/pipermail/iwe/2005-July/000130.html http://lists.warhead.org.uk/pipermail/iwe/2005-July/000130.h... Another way I've heard it (this may have been pg, but I can't remember), is that, when writing idiomatic Lisp, you first think, "What language would make solving this problem really easy?" and then proceed to implement that language.
- egonk 14y ago
  Have you got a good example where Lisp macros would work but standard Haskell would "fail"? I've done some compiler work in Haskell like writing programs (semantic actions) as algebraic data structures and then transforming or interpreting the tree. Would I gain something by using Lisp macros in this instance?
  - tome 14y ago
    Many of Lisp's uses of macros can be replicated in Haskell by taking advantange of lazy evaluation. This is enough for most needs I've ever had, but some things still need the macro system that Template Haskell provides. Deriving lenses from type declarations is one of the up-to-the minute uses.
  - kd0amg 14y ago
    Have you got a good example where Lisp macros would work but standard Haskell would "fail"? http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg01539.html http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...
- draegtun 14y ago
  If pg then perhaps it was (or stems from) this: Programming Bottom-Up - http://www.paulgraham.com/progbot.html http://www.paulgraham.com/progbot.html
  - chimeracoder 14y ago
    > In Lisp, you don't just write your program down toward the language, you also build the language up toward your program. As you're writing a program you may think "I wish Lisp had such-and-such an operator." So you go and write it. Afterward you realize that using the new operator would simplify the design of another part of the program, and so on. That's close, but not quite the wording I remember, so I must have seen it somewhere else as well. That's a pretty good description of what I was referring to, though.
    - 14y ago
chongli 14y ago
>it was not obvious why Lisp would be more powerful than Haskell. The bare-bones syntax felt more like a "proof of concept" than an actual strength. The answer is that Lisp code is written with Lisp data (the property known as homoiconicity). Why is this an advantage? Because it greatly simplifies metaprogramming; Lisp macros are simply functions that operate on Lisp data structures.
jeffdavis 14y ago
"Compared to Haskell I found the syntax very obtuse and it was not obvious why Lisp would be more powerful than Haskell." Language "power" is ill-defined, and basically means "good". If you think that homoiconicity is good, then you probably like lisp. If you think that referential transparency is good, then you probably like haskell. Those are mutually exclusive, so one language can't really have both. But either one could be considered "powerful" and either one could be said to help prevent bugs.
- eggsby 14y ago
  How is it that referential transparency (the ability to swap a reference with it's value: no hidden inputs) and homoiconicity (both the source and the resulting syntax tree sharing the same structure) are mutually exclusive? What homoiconicity offers is the macro system, the ability to operate on the syntax tree as a regular language data structure. The difference is a language like Haskell enforces referential transparency where in a lisp it is up to the developer whether or not a function will be referentially transparent.
  - jeffdavis 14y ago
    "How is it that referential transparency..." That was incorrect, I meant: "the kinds of metaprogramming associated with homoiconicity are mutually exclusive with referential transparency". A macro could not, for instance, take a variable name as an argument and return a result that's based on the value of that variable and maintain referential transparency. So that would be a pretty weak macro system. I suppose there may be other uses for homoiconicity, but I don't know enough about lisp to comment on that.
    - cgag 14y ago
      Maybe I don't understand referential transparency, but why not? `or` is a macro in Clojure: (def a 10) (def b 20) (or a b) => 20 Is `or` not referentially transparent?
      - 14y ago
jhuni 14y ago
> Compared to Haskell I found the syntax very obtuse and it was not obvious why Lisp would be more powerful than Haskell. What do you mean by "obtuse"? If by that you mean difficult to understand, Haskell's syntax is far harder to understand because it has operator precedence tables. Even if you manage to memorize the language's built in operator precedence levels developers can define their own operators with custom associativity and precedence. I will take the uniformity of Lisp syntax rather then the complicated, incomprehensible, and hard to parse syntax of Haskell any day. Lisp syntax is so much simpler then syntactic languages like Haskell that you can even build a simple reversible parser that converts textual code to and from list structures with whitespace metadata: http://lisp-ai.blogspot.com/2012/09/reversible-lisp-reader.html http://lisp-ai.blogspot.com/2012/09/reversible-lisp-reader.h....

artursapek 14y ago

Do you go to Yale?? Haskell school of music?

gajomi 14y ago

I would advise checking out the problems at http://www.4clojure.com/ http://www.4clojure.com/ over the koans. You will definitely find some challenging problems. The nice thing about these is that you can look at how other users all solving the problems, which helps to convey a sense of style. I haven't done a problem in awhile, but I oftentimes gotten something out of looking at solutions from 'amalloy' and 'chouser' in particular. Of course, you can also check out my own ('gajomi') solutions :).

nemetroid 14y ago
Thank you. I will check it out when I get some spare time.

chimeracoder 14y ago

> I found the syntax very obtuse and it was not obvious why Lisp would be more powerful than Haskell. The easiest answer to that is, there's no syntax, which makes reimplementing your own Lisp parser trivial (one single function call, in fact). This in turn makes reimplementing your own Lisp, inline in Lisp, similarly trivial. That sounds like something out of an SICP exercise - and it is - but the same properties make it easier to reason about your code in a way that's far more abstract than other languages let you. Once you start treating your code as data that other parts of your code can manipulate, you can start refactoring in ways that simply aren't possible in other languages. This explanation by a well-known Perl programmer explains it very well: http://lists.warhead.org.uk/pipermail/iwe/2005-July/000130.html http://lists.warhead.org.uk/pipermail/iwe/2005-July/000130.h... Another way I've heard it (this may have been pg, but I can't remember), is that, when writing idiomatic Lisp, you first think, "What language would make solving this problem really easy?" and then proceed to implement that language.

egonk 14y ago
Have you got a good example where Lisp macros would work but standard Haskell would "fail"? I've done some compiler work in Haskell like writing programs (semantic actions) as algebraic data structures and then transforming or interpreting the tree. Would I gain something by using Lisp macros in this instance?
- tome 14y ago
  Many of Lisp's uses of macros can be replicated in Haskell by taking advantange of lazy evaluation. This is enough for most needs I've ever had, but some things still need the macro system that Template Haskell provides. Deriving lenses from type declarations is one of the up-to-the minute uses.
- kd0amg 14y ago
  Have you got a good example where Lisp macros would work but standard Haskell would "fail"? http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg01539.html http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...
draegtun 14y ago
If pg then perhaps it was (or stems from) this: Programming Bottom-Up - http://www.paulgraham.com/progbot.html http://www.paulgraham.com/progbot.html
- chimeracoder 14y ago
  > In Lisp, you don't just write your program down toward the language, you also build the language up toward your program. As you're writing a program you may think "I wish Lisp had such-and-such an operator." So you go and write it. Afterward you realize that using the new operator would simplify the design of another part of the program, and so on. That's close, but not quite the wording I remember, so I must have seen it somewhere else as well. That's a pretty good description of what I was referring to, though.
  - 14y ago

chongli 14y ago

>it was not obvious why Lisp would be more powerful than Haskell. The bare-bones syntax felt more like a "proof of concept" than an actual strength. The answer is that Lisp code is written with Lisp data (the property known as homoiconicity). Why is this an advantage? Because it greatly simplifies metaprogramming; Lisp macros are simply functions that operate on Lisp data structures.

jeffdavis 14y ago

"Compared to Haskell I found the syntax very obtuse and it was not obvious why Lisp would be more powerful than Haskell." Language "power" is ill-defined, and basically means "good". If you think that homoiconicity is good, then you probably like lisp. If you think that referential transparency is good, then you probably like haskell. Those are mutually exclusive, so one language can't really have both. But either one could be considered "powerful" and either one could be said to help prevent bugs.

eggsby 14y ago
How is it that referential transparency (the ability to swap a reference with it's value: no hidden inputs) and homoiconicity (both the source and the resulting syntax tree sharing the same structure) are mutually exclusive? What homoiconicity offers is the macro system, the ability to operate on the syntax tree as a regular language data structure. The difference is a language like Haskell enforces referential transparency where in a lisp it is up to the developer whether or not a function will be referentially transparent.
- jeffdavis 14y ago
  "How is it that referential transparency..." That was incorrect, I meant: "the kinds of metaprogramming associated with homoiconicity are mutually exclusive with referential transparency". A macro could not, for instance, take a variable name as an argument and return a result that's based on the value of that variable and maintain referential transparency. So that would be a pretty weak macro system. I suppose there may be other uses for homoiconicity, but I don't know enough about lisp to comment on that.
  - cgag 14y ago
    Maybe I don't understand referential transparency, but why not? `or` is a macro in Clojure: (def a 10) (def b 20) (or a b) => 20 Is `or` not referentially transparent?
    - 14y ago

jhuni 14y ago

> Compared to Haskell I found the syntax very obtuse and it was not obvious why Lisp would be more powerful than Haskell. What do you mean by "obtuse"? If by that you mean difficult to understand, Haskell's syntax is far harder to understand because it has operator precedence tables. Even if you manage to memorize the language's built in operator precedence levels developers can define their own operators with custom associativity and precedence. I will take the uniformity of Lisp syntax rather then the complicated, incomprehensible, and hard to parse syntax of Haskell any day. Lisp syntax is so much simpler then syntactic languages like Haskell that you can even build a simple reversible parser that converts textual code to and from list structures with whitespace metadata: http://lisp-ai.blogspot.com/2012/09/reversible-lisp-reader.html http://lisp-ai.blogspot.com/2012/09/reversible-lisp-reader.h....