4 ms·

Scheme. As still the best "small" language to teach fundamental principles (everything is a first-class value, symbols are references to values - naming, proc

Scheme. As still the best "small" language to teach fundamental principles (everything is a first-class value, symbols are references to values - naming, procedure composition and nesting as the basic building block, ADTs, immutability of the data, evaluation strategies - eager and lazy, and what is meant by "mostly functional language", etc.) and shapes of data structures (list, three, table). It will pay back with any "stack" or a "framework". Haskell. To learn that static typing done right (type inference) is a very clever feature, but it catches only simple errors (it cannot catch flawed logic or wrong abstractions), so it is not a silver bullet, and, perhaps, to realize why "extremes", like "pure-functionality" or "lazy language" are rather unnecessary complications than big gains. And that monads are mere accidental, awkward ADT to ensure an order of evaluation in a "lazy language", where it is undefined by definition. After that one would find everything in industry is rather easy and boring and develop a healthy aversion to Java and other "packers" stuff.

innguest 12y ago
I agree with everything you said here; I particularly agree with the part where you say that after knowing Scheme and Haskell everything else becomes easy and boring. Does it ever. Makes me question why I got into programming now that I see the bigger picture of what I have been diligently trying to master for over 15 years. To the beginner I'd say: study Scheme and Haskell. Understand them. Once you do, look at other languages. Everything should be familiar. Now you have to decide if you want to spend your professional life always learning different ways to do the same few things there are to do that you learned from Scheme. YMMV but yes it gets boring and yes it will burn you out.
- mod 12y ago
  Maybe it's like cheating in video games. Maybe we should all play the normal game instead of turning on god-mode Scheme? I'm not going to lie: I don't want to be bored or burnt out.
  - innguest 12y ago
    I like the metaphor and think it's on point. It's as if you found a way to make cash appear from nowhere. It would be hard to find a reason to work for money. Same deal with Scheme. It lets you do anything, easily, but it makes it hard to find a reason to want to do anything. To be fair I wouldn't blame it on Scheme, more on my own brain, but still, beginners should look at Scheme right away so they can get to the "I can do anything, now what do I want to do, if anything, with this tool" part faster.
mkehrt 12y ago
Disagree about monads. What you mean is that IO actions are an awkward way to ensure evaluation order in a lazy language. In Haskell, IO actions form a monad, but this is only reasonable because so many other things form a monad that the language has special support for them. Monads are great in that disparate things like lists, sets, IO, control flow, state, optional values, and even functions are all instances of a single ADT which is useful enough that one can write reasonable code abstracted over it, and Haskell provides the mechanisms to do so.
- dschiptsov 12y ago
  > one can write reasonable code abstracted over it Don't you think that at least in a strict language, this would be rather over-abstraction or abstracting for the sake of abstraction?
  - mkehrt 12y ago
    Not really. I think you're confusing Haskell's purity, which makes it necessary to write monadic code, with its monad syntax, which makes it easy.
    - dschiptsov 12y ago
      I think I am not. Monads has nothing to do with "purity" - Erlang is a pure-functional language but there are no monads. Monad make sense only within a language with Normal (instead of Applicative) order of evaluation, to ensure that one computation (or action) "finishes" (being reduced to a value) before another (>>= and >>). return is for the type-checker.
      - mkehrt 12y ago
        That's a very specific way of thinking about monads. Sure, they enforce ordering in a language where you may want to do that. But they're also any ADT equipped with a generalized map (that we happen to call >>= or bind) that commutes nicely. I don't think about my list operations using bind as about ordering computation; I think about them as transforming data in a way that is a little harder to do with more traditional list operations. Same with set, maybe, etc. The ordering feature of monads is more about IO actions than it is about monads in themselves. All I'm saying is that monads are a useful abstraction regardless of whether or not they are used to encapsulate effects. I use Traversables, which have a bind operation, all the time in Scala, and it is an effectful language.

innguest 12y ago

I agree with everything you said here; I particularly agree with the part where you say that after knowing Scheme and Haskell everything else becomes easy and boring. Does it ever. Makes me question why I got into programming now that I see the bigger picture of what I have been diligently trying to master for over 15 years. To the beginner I'd say: study Scheme and Haskell. Understand them. Once you do, look at other languages. Everything should be familiar. Now you have to decide if you want to spend your professional life always learning different ways to do the same few things there are to do that you learned from Scheme. YMMV but yes it gets boring and yes it will burn you out.

mod 12y ago
Maybe it's like cheating in video games. Maybe we should all play the normal game instead of turning on god-mode Scheme? I'm not going to lie: I don't want to be bored or burnt out.
- innguest 12y ago
  I like the metaphor and think it's on point. It's as if you found a way to make cash appear from nowhere. It would be hard to find a reason to work for money. Same deal with Scheme. It lets you do anything, easily, but it makes it hard to find a reason to want to do anything. To be fair I wouldn't blame it on Scheme, more on my own brain, but still, beginners should look at Scheme right away so they can get to the "I can do anything, now what do I want to do, if anything, with this tool" part faster.

mkehrt 12y ago

Disagree about monads. What you mean is that IO actions are an awkward way to ensure evaluation order in a lazy language. In Haskell, IO actions form a monad, but this is only reasonable because so many other things form a monad that the language has special support for them. Monads are great in that disparate things like lists, sets, IO, control flow, state, optional values, and even functions are all instances of a single ADT which is useful enough that one can write reasonable code abstracted over it, and Haskell provides the mechanisms to do so.

dschiptsov 12y ago
> one can write reasonable code abstracted over it Don't you think that at least in a strict language, this would be rather over-abstraction or abstracting for the sake of abstraction?
- mkehrt 12y ago
  Not really. I think you're confusing Haskell's purity, which makes it necessary to write monadic code, with its monad syntax, which makes it easy.
  - dschiptsov 12y ago
    I think I am not. Monads has nothing to do with "purity" - Erlang is a pure-functional language but there are no monads. Monad make sense only within a language with Normal (instead of Applicative) order of evaluation, to ensure that one computation (or action) "finishes" (being reduced to a value) before another (>>= and >>). return is for the type-checker.
    - mkehrt 12y ago
      That's a very specific way of thinking about monads. Sure, they enforce ordering in a language where you may want to do that. But they're also any ADT equipped with a generalized map (that we happen to call >>= or bind) that commutes nicely. I don't think about my list operations using bind as about ordering computation; I think about them as transforming data in a way that is a little harder to do with more traditional list operations. Same with set, maybe, etc. The ordering feature of monads is more about IO actions than it is about monads in themselves. All I'm saying is that monads are a useful abstraction regardless of whether or not they are used to encapsulate effects. I use Traversables, which have a bind operation, all the time in Scala, and it is an effectful language.