Hacker News Reader

Comment by Elrac | Hacker News Reader

Let's be fair to Haskell and LyaH:

I've taught some Java classes. I can get people writing and running trivially useful code before explaining the concepts of "class" and "static". I explain that parts of the code will remain a mystery for a little while until I explain them, I promise to do so, and of course I fulfill that promise as soon as I can.

I feel neither Java nor Haskell are intrinsically bad just because there's no practical way to teach them completely on progressively layered concepts. Even (e.g.) Lisp has a risk of using special forms before understanding them.

View on HN

Sure, but Learn You a Haskell seem to try to avoid saying "I will explain this mumbo jumbo later" by explaining everything up to type classes before getting to "hello world".

I guess I should write a Haskell tutorial which starts with "hello world" without trying to teach monads beforehand!

Skipping over syntax, I think it's something like:

To write any program in Haskell, you define `main`, the IO action that does the work of your program. `putStrLn` is a function that takes a String and returns an IO action that prints the string.

So we can write "hello world" simply:

    main = putStrLn "Hello, World"

I'm curious whether you actually think that's more useful than building understanding at the REPL.

> I'm curious whether you actually think that's more useful than building understanding at the REPL.

Again, I think this depends on you way of learning. For some people it might be possible to "build understanding" gradually over weeks until you are finally ready to write "hello world" having learnt all the fundamentals of the language. That just doesn't work for me. I need to learn through writing programs which actually does something.

But in the tutorial you are building programs that actually do something - plenty more than simply printing a fixed string. You're just doing it at the REPL instead of in a file.

You keep describing the alternative as if it's a bunch of theory before any practice. It's actually just a slightly different form of practice than maybe you are used to.

I am sympathetic to the notion that it might not work for you, but you haven't spoken at all to the actual distinction. If it really does make a big difference for you, I'm very interested in any unpacking you can do.

I do understand what a REPL is and have even used one from time to time. But from my perspective, a program which cannot interact with the outside world is literally useless.

It is not an accident that almost any tutorial for any language or framework or platform starts with "hello world". Because you want to start with the minimal but real, working program - and build from there.

I seriously don't see how a stand-alone "hello world" program is meaningfully "interact[ing] with the outside world" in a way that printing a string at the REPL is not. Stop ranting and posturing, and instead please try to unpack that.

In either case you are simply printing a string to the terminal. The standalone program is easier to compose in your shell, which in some contexts matters a lot, but I don't see that it does here. Where is the difference?

Further, if we define "interact with the outside world" in a way that excludes the programmer reading things off the screen, then it's plainly wrong that all such programs are "literally useless". Calculators, for instance, have delivered a tremendous amount of value. I've personally run something at a REPL (in various languages) plenty of times because I had actual use for the value to be printed and didn't need to persist the program.

The point of "Hello world" is that it is the simplest possible real, working program. It can be compiled and executed and you could deploy it to users or to a production environment if you wanted.

"A complex system that works is invariably found to have evolved from a simple system that worked."

I understand that from a certain theoretical perspective it is just the same thing to echo a string literal in a REPL, but from a software development perspective it is completely different.

> The standalone program is easier to compose in your shell, which in some contexts matters a lot, but I don't see that it does here.

I kind of see where you are coming from. You are assuming the program is only ever used by yourself. I understand this is just a different culture and hadn't even thought about that perspective.

To clarify, I am not critical of the language Haskell itself. I think it is great. It is mostly a criticism of the tutorials and general culture around the language.

For example Rust is another language which have a reputation for being hard to learn, due to novel and complex concepts like the borrow checker. But in my experience you see none of this "talking down" to the audience. They just explain how the stuff works with practical examples.

Reply on news.ycombinator.com