Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Teenage Haskell

twdkz.wordpress.com

Post reply on HN
Print view View original

51–60 of 93 posts

Re: Teenage Haskell

#51

Post by cdsmith »

codygman wrote: post #25
judk wrote: post #5

Earlier quoted context omitted.

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

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/

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.

Re: Teenage Haskell

#52

Post by seanmcdirmid »

59nadir wrote: post #40
mpweiher wrote: post #36

Earlier quoted context omitted.

At the TU-Berlin, our intro courses were held in FP languages, and we were indoctrinated as to the incomparable superiority of the approach...and could see for ourselves how the reality diverged from the hype. That was a good 20 years ago, but I just ran into a current student who told me that's still the case, and they still hate it as much as we did.

Seems like your university is doing it wrong. While I do believe that the principles used in FP languages are vastly superior I don't think this is really a matter of debate. The advantages are obvious and if you didn't realize it you probably weren't taught well enough. On topic: I sometimes wonder if the wins from FP languages are lost on the people not already scarred by the pitfalls of imperative programming. I w…

> While I do believe that the principles used in FP languages are vastly superior I don't think this is really a matter of debate. The advantages are obvious and if you didn't realize it you probably weren't taught well enough.

No, there are plenty of people who will debate this, programming languages academics even. There is a vocal FP crowd that fawns over elegance, but there are plenty of other people who are more pragmatic about it.

> I sometimes wonder if the wins from FP languages are lost on the people not already scarred by the pitfalls of imperative programming.

Pity the poor programmers who get things done, write huge beautiful systems, all without worshiping lambdas? And by taking shortcuts ala side effects as a way to making things easier.

> Maybe someone uninitiated in programming won't have as many problems formulating functional solutions to problems in Haskell too.

It depends on how much math they have behind them. You take a mathemegician, sure, but a high schooler who is still having trouble with pre-calc?

Re: Teenage Haskell

#53

Post by seanmcdirmid »

arianvanp wrote: post #39

How about http://elm-lang.org/ ? It is very similar to haskell but a bit less daunting and all its libraries are focussed on building inbrowser games. Sounds like something kids would love. Now that i am brainstorming anyway. Something like http://scratch.mit.edu would be so much nicer if it were a functional language! Instead of confusing blocks that maintain state every block is just a standalone welldefined functi…

Elm is this weird language that is really good at visual demos but is not anything interesting as far as language goes (if you want Haskell, just use Haskell, if you want FRP, there are plenty of libs for that, if you need pseudo FRP on web, then elm makes sense).

Scratch would be impossible to use as a functional language, especially for the logo-style turtle procedural behavior they are aiming at.

Re: Teenage Haskell

#54

Post by seanmcdirmid »

username223 wrote: post #26
thinkpad20 wrote: post #20

Earlier quoted context omitted.

There are infinite loops in Haskell too. (And space leaks in python)

Are any of the space leaks available without explicit syntax, e.g. genexps? GHC is smart, but only smart enough to mostly hide your misunderstandings about what it can do with your code.

A space leak is simply pinning memory unintentionally, which definitely happens in most garbage collected languages.

Perhaps Python programmers would be baffled by time leaks instead :)

Re: Teenage Haskell

#55

Post by codygman »

klrr wrote: post #48
seanmcdirmid wrote: post #4

Earlier quoted context omitted.

> Their lack of preconceptions regarding programming might make Haskell much easier for them to pick up, than it would for a student with experience in another language. Or traumatize them forever away from the field of programming. > Would they think Python was stupid or would they be grateful that all of a sudden they could use a for loop? I would love to know the answer to this, regardless of my own biases. But Ha…

I'm a teen I guess. Haskell as a first language worked great for me, and I happened to write a game and a few scripts in Python two months ago so I think I can answer your question. So, what made learning Haskell a good experience I think was mainly the strong type system. You could basically even early on use functions you barely knew what its name meant solely based on its type signature. It also made the progress…

Thanks for sharing your experiences! I've always been curious about this.

Re: Teenage Haskell

#56

Post by mpweiher »

seanmcdirmid wrote: post #52
59nadir wrote: post #40

Earlier quoted context omitted.

Seems like your university is doing it wrong. While I do believe that the principles used in FP languages are vastly superior I don't think this is really a matter of debate. The advantages are obvious and if you didn't realize it you probably weren't taught well enough. On topic: I sometimes wonder if the wins from FP languages are lost on the people not already scarred by the pitfalls of imperative programming. I w…

> While I do believe that the principles used in FP languages are vastly superior I don't think this is really a matter of debate. The advantages are obvious and if you didn't realize it you probably weren't taught well enough. No, there are plenty of people who will debate this, programming languages academics even. There is a vocal FP crowd that fawns over elegance, but there are plenty of other people who are more…

> It depends on how much math they have behind them.

Very much so, and also depends very much on the problem at hand. Yes, compilers and yet another RB-Tree implementation can be great in FP. Most real-world problems aren't that. In fact, most real world problems I have encountered (and see) tend to be massively about manipulating state. Often they do little else than shuffle data around.

I sometimes think "computers" are misnamed, because they do so little actual "computation". "Data around-shufflers" might be more appropriate.

Re: Teenage Haskell

#57

Post by coldtea »

59nadir wrote: post #45
mpweiher wrote: post #41

Earlier quoted context omitted.

That's exactly the kind of hair-raising and mindless (in the truest sense of the word) nonsense we were presented with: "the superiority of FP is not a matter for debate". The reality was that the tools were slower and buggier than others, the programs different (and slower) but no simpler and the bugs different but stilly just as buggy. When presented so mindlessly and categorically, any claims of superiority instan…

The principles used in FP are actual principles you could employ in imperative languages... and people do, because they are obviously good. It's a matter of there actually being principles instead of the alternative; nothing . This aside, you seem to be talking about the languages themselves, so let's go ahead: > the tools were slower Which tools are these? I don't see this as a systematic failure of FP languages. Wh…

>It's a matter of there actually being principles instead of the alternative; nothing.

BS principles are not better than no principles.

Or principles that tie your hand around your back for that matter. And functional principles do that for a lot of cases, with respect to performance, memory impact etc.

Functional languages are not some kind of 2x or 10x multiplier of a programmers abilities. In fact most of the things that made LISP interesting have been ported since ages in modern non-functional languages, from GC to closures, and even macros.

>Most FP languages are not suitable for performance sensitive tasks and most people will admit this. For most other tasks, though, they're just going to allow you to work faster and get to where you're going with less hassle.

Not the case in the real world.

For one, this BS idea forgets all about ecosystems and libraries. Python will let you work faster and get where you're going with less hassle. Functional languages that have 1/10 the libraries available, and in various stages of abandonment because of lack of programmers will not.

>The alternative isn't as much a principle as it is a lack of principle.

Really? For one, what all "FP languages" do when they run, is "flip individual switches and modify memory". The way they model the program is just an abstraction (and a leaky one) from what happens in the machine.

Second, I thought the Church-Turing thesis shows that lambda calculus is equivalent to the Turing machine way, for one.

Third, where did you get the idea that non-FP languages don't have principles? Smalltalk, for one, sure has tons of unifying principles behind it. Prolog. Erlang.

And if Algol was good enough for Dijkstra, modern, 10-times better algol derivatives are good enough for me. Especially if they also have adopted tons of functional paradigms, which you can get to opt to use when it makes sense for your design, and not have them forced upon you.

Re: Teenage Haskell

#58

Post by Dewie »

seanmcdirmid wrote: post #4
MarcScott wrote: post #3

My brother (a Haskell programmer) and I (a teacher of high school CS) have talked about this often. He's postulated that teaching Haskell to kids with no programming experience would be an interesting experiment. Their lack of preconceptions regarding programming might make Haskell much easier for them to pick up, than it would for a student with experience in another language. What would be more interesting however,…

> Their lack of preconceptions regarding programming might make Haskell much easier for them to pick up, than it would for a student with experience in another language. Or traumatize them forever away from the field of programming. > Would they think Python was stupid or would they be grateful that all of a sudden they could use a for loop? I would love to know the answer to this, regardless of my own biases. But Ha…

> Or traumatize them forever away from the field of programming.

The same can be said about using Python et al as the first programming language. How many people quit an introductory course to programming because they didn't like (say) the style of programming in Python, but could get an interest in it if the language being taught was some FP one (or maybe a logic programming language, etc.)? It's kind of hard to tell, because students who get turned away from an introductory course on programming probably aren't going to look up (or even know about) "programming paradigms" and see whether there are alternatives.

Granted, how long would these people survive in the job market if they were able to be "traumatized" by some imperative language? There are certainly more imperative language jobs (or, they tend more to imperative style than FP style) in the job market, it seems. But even if they wouldn't like working as a programmer, they can still use it as a hobby if they like.

Re: Teenage Haskell

#59

Post by fractallyte »

andreasvc wrote: post #49
fractallyte wrote: post #42

Earlier quoted context omitted.

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…

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 interrel…

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.'

Re: Teenage Haskell

#60

Post by cousin_it »

gizmo686 wrote: post #27
codygman wrote: post #25

Earlier quoted context omitted.

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/

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.

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.
Post reply on HN