5 ms·

Froskell: Haskell with unlockable features for teaching programming

42 points by bontoJR 11y ago

rwl 11y ago
I don't know if the authors of this proposal are here, but I wonder if they have heard of Elm: http://elm-lang.org/ http://elm-lang.org/ If they are not completely married to Haskell, they might consider using Elm instead. Why? Like Haskell, it's a functional language in the ML family. It already has a browser-based IDE, and has a lot of built-in features that make it well-suited to writing the kinds of programs beginners might be interested in, like games. Starting with Elm, the authors would be a lot closer to their goals; they could focus on just implementing the concept of "unlockable" features in the existing Elm IDE.
- psibi 11y ago
  Yes, they know about Elm. They have mentioned it in the article.
- vezzy-fnord 11y ago
  Like Haskell, it's a functional language in the ML family. Haskell isn't in the ML family. It's a successor to the concepts used in David Turner's languages (but more specifically Miranda), themselves born out of a language named Hope that came out nearly the same time as ML.
Someone 11y ago
I am not sure the "unlockable" features idea is a good one. Firstly, that seems to imply that students will first learn what "simple error message" means, and later, when they make the same mistake, get shown "gobbledygook gook gook". Why would they spend time learning that new message, if, for all they know, a few lessons on, the same mistake may produce yet another error message? Secondly, the good student may generalize from the subject of a lesson (for example because they may have experience with another language), guess at advanced syntax and try it out, and hurt their nose because their language doesn't _yet_ support the feature. I would think that the only good way forward is to spend time improving the error messages in the full language. Possibly, that requires redesigning the language (for example, having if...fi, do...od, and while...wend may be superior to using braces everywhere) Yes, that is hard work. In many languages, writing a parser that accepts valid programs is way easier than writing a parser that gives meaningful error messages and recovers from errors in the to be parsed code well. If you have that, maybe, labeling parts of error messages as 'irrelevant for this lesson' by graying them out might help, but I think you should present all possible causes of parse errors up front. [aside: from the title alone, I guessed this was a game where achievements allowed you to buy language features: "your next task is to draw a Pythagorean tree. You have 367 coins. You can buy recursive function calls for 100 coins, Unicode emoji output for 150, floating point arithmetic for 250, or goniometric functions for 200?"]
- TheLoneWolfling 11y ago
  Agreed on all parts, give or take. An addition: I don't see how one could suppress error messages relating to features that haven't been unlocked without causing program validity itself to be dependent on what features you have unlocked. Either that or have programs that don't have any observable error messages but still don't work. And that's a nasty side effect. Note that a recursive-descent parser is actually probably the best approach for this. They have the combination of being simple and relatively easy to generate relevant error messages and recover from errors that you often don't get with other parsers. The classic shortfall of a recursive-descent parser (exponential-time worst case complexity) doesn't generally apply to this sort of thing, as generally the programs are relatively short.
TheLoneWolfling 11y ago
I would find this sort of thing infuriating. Every time you learn a syntax, it gets replaced by another? Your error messages depend on how far along you are? Worse: program correctness depends on how far along you are? Good luck going to a TA with that one... Also, it's shooting yourself in the foot w.r.t. those people who come into the program already knowing something. Driving away the advanced people isn't the best thing in the world. As an aside, that first example pretty much sums up why I don't like Haskell. Not the error message, but that it doesn't work in the first place. It's too bad, because I know I'm kind of shooting myself in the foot. But first impressions leave a mark.
brudgers 11y ago
The idea of a progression of "Student Languages" with reduced features, better error messages, and a supporting IDE is exactly what the PLT Group provides in the form of Racket. The only "features" it lacks are a monetization strategy in general and one that sounds like in-app-purchases in particular and the IDE running online (Racket's DrRacket is a stand-alone desktop application, but runs natively on Windows, OSX, and *nix including with native UI as applicable). It has good documentation to boot. And in my opinion that's one of the truly critical factors for a pedagogical language. YMMV.

42 points by bontoJR 11y ago

rwl 11y ago

I don't know if the authors of this proposal are here, but I wonder if they have heard of Elm: http://elm-lang.org/ http://elm-lang.org/ If they are not completely married to Haskell, they might consider using Elm instead. Why? Like Haskell, it's a functional language in the ML family. It already has a browser-based IDE, and has a lot of built-in features that make it well-suited to writing the kinds of programs beginners might be interested in, like games. Starting with Elm, the authors would be a lot closer to their goals; they could focus on just implementing the concept of "unlockable" features in the existing Elm IDE.

psibi 11y ago
Yes, they know about Elm. They have mentioned it in the article.
vezzy-fnord 11y ago
Like Haskell, it's a functional language in the ML family. Haskell isn't in the ML family. It's a successor to the concepts used in David Turner's languages (but more specifically Miranda), themselves born out of a language named Hope that came out nearly the same time as ML.

Someone 11y ago

I am not sure the "unlockable" features idea is a good one. Firstly, that seems to imply that students will first learn what "simple error message" means, and later, when they make the same mistake, get shown "gobbledygook gook gook". Why would they spend time learning that new message, if, for all they know, a few lessons on, the same mistake may produce yet another error message? Secondly, the good student may generalize from the subject of a lesson (for example because they may have experience with another language), guess at advanced syntax and try it out, and hurt their nose because their language doesn't _yet_ support the feature. I would think that the only good way forward is to spend time improving the error messages in the full language. Possibly, that requires redesigning the language (for example, having if...fi, do...od, and while...wend may be superior to using braces everywhere) Yes, that is hard work. In many languages, writing a parser that accepts valid programs is way easier than writing a parser that gives meaningful error messages and recovers from errors in the to be parsed code well. If you have that, maybe, labeling parts of error messages as 'irrelevant for this lesson' by graying them out might help, but I think you should present all possible causes of parse errors up front. [aside: from the title alone, I guessed this was a game where achievements allowed you to buy language features: "your next task is to draw a Pythagorean tree. You have 367 coins. You can buy recursive function calls for 100 coins, Unicode emoji output for 150, floating point arithmetic for 250, or goniometric functions for 200?"]

TheLoneWolfling 11y ago
Agreed on all parts, give or take. An addition: I don't see how one could suppress error messages relating to features that haven't been unlocked without causing program validity itself to be dependent on what features you have unlocked. Either that or have programs that don't have any observable error messages but still don't work. And that's a nasty side effect. Note that a recursive-descent parser is actually probably the best approach for this. They have the combination of being simple and relatively easy to generate relevant error messages and recover from errors that you often don't get with other parsers. The classic shortfall of a recursive-descent parser (exponential-time worst case complexity) doesn't generally apply to this sort of thing, as generally the programs are relatively short.

TheLoneWolfling 11y ago

I would find this sort of thing infuriating. Every time you learn a syntax, it gets replaced by another? Your error messages depend on how far along you are? Worse: program correctness depends on how far along you are? Good luck going to a TA with that one... Also, it's shooting yourself in the foot w.r.t. those people who come into the program already knowing something. Driving away the advanced people isn't the best thing in the world. As an aside, that first example pretty much sums up why I don't like Haskell. Not the error message, but that it doesn't work in the first place. It's too bad, because I know I'm kind of shooting myself in the foot. But first impressions leave a mark.

brudgers 11y ago

The idea of a progression of "Student Languages" with reduced features, better error messages, and a supporting IDE is exactly what the PLT Group provides in the form of Racket. The only "features" it lacks are a monetization strategy in general and one that sounds like in-app-purchases in particular and the IDE running online (Racket's DrRacket is a stand-alone desktop application, but runs natively on Windows, OSX, and *nix including with native UI as applicable). It has good documentation to boot. And in my opinion that's one of the truly critical factors for a pedagogical language. YMMV.