5 ms·

This has been done with Scheme and works really well. But Haskell really is too complex.

by judk 12y ago

seanmcdirmid 12y ago
Scheme is quite simple compared to Haskell or even ML. Yet even MIT moved from Scheme to Python.
- MichaelGG 12y ago
  Did they have pure intentions in that move? I thought it was more out of popularity than any good metric.
  - seanmcdirmid 12y ago
    Who knows, everyone has their own opinion about it. Perhaps it was just too many parentheses for students to deal with.
    - judk 12y ago
      MIT switched to Python because they believe modern basic CS is about controlling complex systems (web APIs, robot APIs) not walking through the history of CS from scratch and bare metal.
      - fractallyte 12y ago
        Here are a couple of quotes from 'Realm of Racket', just to expand on your statement: 'All members of this [ALGOL] family are made from more or less the same material and for the same kind of programmers - those who love the machine more than the problem.' Contrast with Lisp: 'a language that would help programmers solve problems without forcing them to think about the elements of a machine.' So it really depends on one's interpretation of 'Computer Science', and the choice of what to prioritize from the subject: engineering or ideas.
        andreasvc 12y ago
        That is an incredibly condescending way of arguing. On the other side of the coin you could claim that imperative programming is more practical, concerned with the actual steps needed to solve a problem, instead of an ideal, indirect formulation. Imagine having to explain someone how to bake an apple pie without being able to state any specific steps how to do it but instead describing the pie as some set of interrelationships of the ingredients. (That is probably not a fair characterization of FP, but it's at the same level as "[imperative programmars] love the machine").
        fractallyte 12y ago
        Actually, I would point out that Lisp is not limited to any single paradigm... But something else you wrote brought to mind this rather interesting statement from - of all places! - the introduction to Michael Barnsley's famous book, 'Fractals Everywhere': 'In deterministic geometry, structures are defined, communicated, and analysed, with the aid of elementary transformations such as affine transformations, scalings, rotations, and congruences. A fractal set generally contains infinitely many points whose organization is so complicated that it is not possible to describe the set by specifying directly where each point in it lies. Instead, the set may be defined by "the relations between the pieces." It is rather like describing the solar system by quoting the law of gravitation and stating the initial conditions. Everything follows from that. It appears always to be better to describe in terms of relationships.'
        andreasvc 12y ago
        I have no idea how your reply relates to my comment. I wouldn't claim that Lisp is limited to a single paradigm, nor do I see how fractals are related to the discussion at hand.
        fractallyte 12y ago
        The point is that Lisp can be imperative too. But, because the language was not constructed according to the underlying physical architecture, it's not bound by the limitations of ALGOL-like languages. So, rather than condescending, I find this interesting: these are two dissimilar approaches to solving problems. Your comment about baking an apple pie 'without being able to state any specific steps how to do it but instead describing the pie as some set of interrelationships of the ingredients' was also an excellent statement of the differences between these points of view. Barnsley's perspective was that relationships may indeed be a better way to describe structures. His concern was fractals, but perhaps the analogy extends to the logical structures that comprise a program.
  - thinkpad20 12y ago
    The first time I learned programming it was Scheme, and I didn't care for it - the syntax was confusing and it felt more like magical incantations than giving the machine instructions. I didn't touch programming again for several years, but when I did it was python. I found it was much more interesting, in part because of my state of mind but also because I could see the computer responding to what I told it to do and I liked being "in control" of the machine rather than the other way around (which FP can sometimes feel like). I love functional programming now and I write a lot of Haskell, but I think there's real value to starting out with an imperative language to get that "interacting with the machine" feel. It also makes it easier IMO to learn about computational complexity, systems, etc. That, and python has a ton of great libraries, an intuitive syntax, and a lot of flexibility, so I'm not surprised they've adopted it.
- JacksonGariety 12y ago
  SICP is still the bible, even through Python has become the "practical" language that's also quite simplistic.
codygman 12y ago
What about Haskell is too complex? If you go through A Gentle Introduction to Haskell[0] I think you'll see it's a pretty simple language. There aren't that many parts of core Haskell to learn about. Perhaps the abstractions such as Monad and Functor are more complex, but they don't seem anymore complex than some of the design patterns used to accomplish what they're used for. 0: http://www.haskell.org/tutorial/ http://www.haskell.org/tutorial/
- gizmo686 12y ago
  Monad and Functor are abstract, not complex. One of the things that is easy to forget once you know something is that the complex and concrete thing is often easier to understand than the simple and abstract thing. Of course, eventually you begin to consider the abstract thing to be concrete.
  - cousin_it 12y ago
    If you just stick to the idea of type classes, then yeah, it is simple and abstract, even for constructor classes like Functor and Monad. But the reality of type classes in Haskell is not as simple, I think. Defaulting rules, "deriving", Paterson conditions, instance coherence, functional dependencies, etc.
- cdsmith 12y ago
  It's worth mentioning that the tool this blog post is about defines a simplified version of Haskell's standard library. In particular, there are no type classes exported from Prelude, much less monads or functors. In the end, it's not really any more complex than Scheme, except for syntax. Now, true, the syntax is much more complicated than Scheme. You can operators and precedence and all that. But while definitely complex, it is mostly consistent with math notation. I tried to teach with Scheme first (following www.bootstrapworld.org) before I created this, and I found the change in syntax from what they are used to can be a real obstacle for children. This is also consistent with the comment about MIT moving to Python, which similarly has much more complex but familiar syntax.

This has been done with Scheme and works really well. But Haskell really is too complex.

by judk 12y ago

This has been done with Scheme and works really well. But Haskell really is too complex.

seanmcdirmid 12y ago

Scheme is quite simple compared to Haskell or even ML. Yet even MIT moved from Scheme to Python.

MichaelGG 12y ago
Did they have pure intentions in that move? I thought it was more out of popularity than any good metric.
- seanmcdirmid 12y ago
  Who knows, everyone has their own opinion about it. Perhaps it was just too many parentheses for students to deal with.
  - judk 12y ago
    MIT switched to Python because they believe modern basic CS is about controlling complex systems (web APIs, robot APIs) not walking through the history of CS from scratch and bare metal.
    - fractallyte 12y ago
      Here are a couple of quotes from 'Realm of Racket', just to expand on your statement: 'All members of this [ALGOL] family are made from more or less the same material and for the same kind of programmers - those who love the machine more than the problem.' Contrast with Lisp: 'a language that would help programmers solve problems without forcing them to think about the elements of a machine.' So it really depends on one's interpretation of 'Computer Science', and the choice of what to prioritize from the subject: engineering or ideas.
      - andreasvc 12y ago
        That is an incredibly condescending way of arguing. On the other side of the coin you could claim that imperative programming is more practical, concerned with the actual steps needed to solve a problem, instead of an ideal, indirect formulation. Imagine having to explain someone how to bake an apple pie without being able to state any specific steps how to do it but instead describing the pie as some set of interrelationships of the ingredients. (That is probably not a fair characterization of FP, but it's at the same level as "[imperative programmars] love the machine").
        fractallyte 12y ago
        Actually, I would point out that Lisp is not limited to any single paradigm... But something else you wrote brought to mind this rather interesting statement from - of all places! - the introduction to Michael Barnsley's famous book, 'Fractals Everywhere': 'In deterministic geometry, structures are defined, communicated, and analysed, with the aid of elementary transformations such as affine transformations, scalings, rotations, and congruences. A fractal set generally contains infinitely many points whose organization is so complicated that it is not possible to describe the set by specifying directly where each point in it lies. Instead, the set may be defined by "the relations between the pieces." It is rather like describing the solar system by quoting the law of gravitation and stating the initial conditions. Everything follows from that. It appears always to be better to describe in terms of relationships.'
        andreasvc 12y ago
        I have no idea how your reply relates to my comment. I wouldn't claim that Lisp is limited to a single paradigm, nor do I see how fractals are related to the discussion at hand.
        fractallyte 12y ago
        The point is that Lisp can be imperative too. But, because the language was not constructed according to the underlying physical architecture, it's not bound by the limitations of ALGOL-like languages. So, rather than condescending, I find this interesting: these are two dissimilar approaches to solving problems. Your comment about baking an apple pie 'without being able to state any specific steps how to do it but instead describing the pie as some set of interrelationships of the ingredients' was also an excellent statement of the differences between these points of view. Barnsley's perspective was that relationships may indeed be a better way to describe structures. His concern was fractals, but perhaps the analogy extends to the logical structures that comprise a program.
- thinkpad20 12y ago
  The first time I learned programming it was Scheme, and I didn't care for it - the syntax was confusing and it felt more like magical incantations than giving the machine instructions. I didn't touch programming again for several years, but when I did it was python. I found it was much more interesting, in part because of my state of mind but also because I could see the computer responding to what I told it to do and I liked being "in control" of the machine rather than the other way around (which FP can sometimes feel like). I love functional programming now and I write a lot of Haskell, but I think there's real value to starting out with an imperative language to get that "interacting with the machine" feel. It also makes it easier IMO to learn about computational complexity, systems, etc. That, and python has a ton of great libraries, an intuitive syntax, and a lot of flexibility, so I'm not surprised they've adopted it.
JacksonGariety 12y ago
SICP is still the bible, even through Python has become the "practical" language that's also quite simplistic.

codygman 12y ago

What about Haskell is too complex? If you go through A Gentle Introduction to Haskell[0] I think you'll see it's a pretty simple language. There aren't that many parts of core Haskell to learn about. Perhaps the abstractions such as Monad and Functor are more complex, but they don't seem anymore complex than some of the design patterns used to accomplish what they're used for. 0: http://www.haskell.org/tutorial/ http://www.haskell.org/tutorial/

gizmo686 12y ago
Monad and Functor are abstract, not complex. One of the things that is easy to forget once you know something is that the complex and concrete thing is often easier to understand than the simple and abstract thing. Of course, eventually you begin to consider the abstract thing to be concrete.
- cousin_it 12y ago
  If you just stick to the idea of type classes, then yeah, it is simple and abstract, even for constructor classes like Functor and Monad. But the reality of type classes in Haskell is not as simple, I think. Defaulting rules, "deriving", Paterson conditions, instance coherence, functional dependencies, etc.
cdsmith 12y ago
It's worth mentioning that the tool this blog post is about defines a simplified version of Haskell's standard library. In particular, there are no type classes exported from Prelude, much less monads or functors. In the end, it's not really any more complex than Scheme, except for syntax. Now, true, the syntax is much more complicated than Scheme. You can operators and precedence and all that. But while definitely complex, it is mostly consistent with math notation. I tried to teach with Scheme first (following www.bootstrapworld.org) before I created this, and I found the change in syntax from what they are used to can be a real obstacle for children. This is also consistent with the comment about MIT moving to Python, which similarly has much more complex but familiar syntax.