Going slow is often a good idea, but part of the wisdom that comes from 20 years writing software is knowing when you should choose between slowing down, coding like hell, slapping something half-working together, etc.
That's not even close to true. I've worked in more than one shop where the 19-23yo kid fresh out of high school/college is 10x better than most of the 40-50s. Or, in a few cases, infinitely better than the guys in their 50s who are -100x (it required weeks/months to undo the damage when they finally left).
There's something to be said for experience, but keep in mind the old adage about "10 years of experience versus 1 year of experience repeated 10 times".
I found ocaml to be a more flexible alternative -- I can sprinkle printf for quick debugging without having to alter types. (I think this is what you mean by "having to use the IO monad". I didn't work with haskell much, so it's possible there's an easy way around this there.) And stack traces in ocaml are reasonable, though not quite as verbose as python's.
But your point about needing to install extra packages stands for either language.
OCaml is currently my language of choice. I love functional programming, been doing it for a while now, but it's nice to know that if I read an algorithm in a textbook, I can just implement it as-is instead of doing a translation to be purely functional (and sometimes having to fight to get back the asymptotic complexity). The module system is also absolutely great, and should be copied shamelessly by more languages.
I spent a little time with Haskell and gave up because progress was slow. Later I picked up Ocaml and found many of the concepts to be similar but had a much easier time making progress. Having used Ocaml to familiarize myself with strongly typed FP, I think it wouldn't be so hard now to go back to Haskell and have more success.
If you decide to give it a try, I highly recommend Real World Ocaml  as a starting point, especially the installation instructions that help you get up and running with a sane toolchain right away .
This sounds great. I've starting looking at the CIS 194 lectures, though, and so far not a single example works in ghci. Googling around indicates that you need to use 'let' or define things in a module and load them . . .
Are universities using single-language curricula now? I hear people talking about "python schools" or "java schools". That seems like a mistake. I don't have any hard data to back it up, but it seems like students would end up better off learning a small number of languages across multiple paradigms while they are in school.
e.g. Intro CS 1/2 in python, followed by a computer architecture course that introduces an assembly/machine language (you could write an assembler/disassembler in python), possibly followed by C (since pointers will make sense now), and finally something different like lisp or ML family.
> If we wanted to engage in the same level of software engineering for all software, we could. But we don't want to.
Of course. Like building structures, there are different kinds of software. I can build a garden shed by myself as long as I have the skills to get the thing to stand up. If it blows down in a storm I'm the only person with a loss. But just because I can get a garden shed (or even a larger structure like a barn or a house) to survive windstorms without incident doesn't make me a structural engineer.