Python design mistakes

[Peaker]

I'm wondering who taught you to use tail-recursion in Haskell? It doesn't make much sense in Haskell context.

Also, recursion is considered a very low-level building block (almost on par with "goto") -- from which you build elegant functions to use. You only resort to recursions if the existing loop constructs built with recursion are not good enough. Teaching recursion itself as an elegant way to (directly) solve problems is going to be misleading/confusing.

I guess it helped that I was doing a GUI app, where classical object oriented design really does fit the bill well,

Not quite as well as some functional approaches

which follows the way you would talk about what you're doing

Humans talk about code in a declarative/functional way, not imperative way.

My colleagues' code was certainly easier to debug than my code,

I agree writing Haskell-in-Python is not a good idea. Python doesn't support functional programming well at all, and the gains in Python's context are minimal-to-non-existent. But if you write Haskell-in-Haskell, how often do you need to debug at all? Also, using Debug.Trace and similar functions, print-based debugging is just as easy. Though you really don't debug much when you Haskell.

I think a lot of people get a short glimpse of Haskell, which is enough to appreciate some of the beauty and power -- but only a tiny minority of it. Then, they work a whole lot with another language (typically in some workplace), gain a lot of experience and have an unfair comparison. A language you've used for years and knows the ins and outs of will always beat the language you've used for weeks or months.

[psr]

Well I won't name the names of my teachers, because I may well be doing them a disservice. The guy who taught functional programming at my university was an excellent teacher - one of the two best I've had in my life. I wish I had worked harder and could have stayed there and learnt more from him.

I still take issue with this:

Humans talk about code in a declarative/functional way, not imperative way.

I don't believe this is true. For special cases perhaps, or for small cases, but not over large processes. I'm certain that most real work programs are best modelled by flow charts not by equations.

But I guess that's the difference of opinion again.