2 ms·

Agreed, and thanks, that looks like an interesting paper. In Gothenburg, Sweden, where I studied, Haskell is the first introductory language for students of CS

by mbrock 11y ago

Agreed, and thanks, that looks like an interesting paper. In Gothenburg, Sweden, where I studied, Haskell is the first introductory language for students of CS and (I believe) CE. I know people who had barely even used a computer when they started there who are quite proficient with Haskell. A side benefit of that is that the dorks like me who had been coding Perl and C and whatever for years before were thrown back to "oh shit, I have to actually study" mode and thus equalized with the people who were starting from scratch. In terms of gender, when I started studying women were way less likely to have been coding since the age of 6. In the exam for a later course on Advanced Functional Programming that included monad transformers, functional embedded languages, the basics of dependently typed programming, and a semi-large Haskell programming project, I was happy to see a female classmate who hadn't programmed at all before university get the best score of anyone. But I digress... (Shoutout to Elin if you're reading!) I'm somewhat anxious that my way of talking about this stuff might make people think that Haskell is way more difficult to learn than other languages, which I don't think is the case. I think people probably forget how much trouble they had grokking concepts like "objects" and "superclasses" and "generators" and so on. Haskell might be difficult in some other ways. Maybe in some ways it forces you to really understand things more than other languages. But it's still very possible to learn to program in Haskell without being exceptionally good at math. Also, some of what people find tricky about Haskell is also present in other ML-style languages. I learned about O'Caml and some SML, and also Scheme, before I got into Haskell. So I knew about functional recursive styles of programming, and algebraic data types, and probably the biggest new things were lazy evaluation and the complete lack of side effects leading to the need for monadic sequencing. Those are not insurmountable. Edit: By the way, I also appreciate how Haskell is becoming a sort of grass roots study group for coders to learn more about math, algebra, category theory, and what have you. It is not at all constrained to the universities anymore. This article is at the top of HN right now! Interesting times.

jacquesm 11y ago
I think you're on to something here. It may be that programming languages that require you to 'reboot' are better suited to people totally new to programming than to people that already know how to program using some other methodology. This is because compared to your old, well used and worn tools that new tool starts off as a set-back rather than an advantage and we more or less expect an instant productivity boost from new technology. That set-back then becomes a huge hurdle to overcome. The question a programmer faced with a problem to solve is always one of investment: should I invest my time and effort into this new technology that will make me x times more productive or simply a better programmer (or someone capable of tackling more complex problems) a year or more down the line, or should I break out my trusty tools and turn a buck today (or turn a buck for my employer). In most cases that equation works out in favor of the old tools so the energy required would need to be offset by concrete short term gains if a person is to switch from one tech to another. That lack of concrete short-term gains is the big stumbling block for old hands, and if you manage to hack that then I think a lot of these better technologies would find traction. People new to programming don't have that particular hang-up and I'd expect them to do much better with such new tool or different tools. (But they'd have the same problem if they needed to switch to other tools, it's just that in this particular instance they have a blank slate advantage, that evaporates the moment they become proficient in that technology.)
- jwdunne 11y ago
  This comment and the parent comment was really interesting. It's made me think about my current path and somethings I have done/learned that has incrementally pushed me towards functional programming over a long window of time. I have played with Scheme, along with a half-completed SICP read through. I have also played with Haskell, along with partial read throughs of LYAH and real-world Haskell. Those experiences, although incomplete, have been important to me as a programmer. I don't think those actually 'sold' me on FP though. I took a detour for some time and decided to become a better programmer using OO methodologies. I used TDD, I memorised SOLID and all that. Read up on design patterns and then used them practically. All well and good. From my toying with Scheme, Haskell and associated literature, I wasn't entirely satisfied. The code I produced was always a bit, I'm not sure, but not entirely satisfiying. It looked and worked better than what I get given to review when considering freelancers for an extra pair of hands - part of that is because of PHP I think. I carried on this way for a while in any case. In my own self-learning, I'd started looking at language design and compilers. I read some books and decided I didn't have enough mathematical skills to consume the texts. I turned to learning discrete mathematics. That was a big eye opener. As I was reading about formal logic, set theory, proofs, etc, my mind kept turning to the problem of applying this in my work. Haskell and FP came to mind too. I believe doing this helped it finally click that a functional approach can be taken successfully in most of the work I do. Whilst I was doing this, I had a fairly simple project that, if designed correctly, could make my life easier in future projects. I took an OO approach, designed the UML, started writing tests, etc. I decided that it was over-engineered or at least it was a lot of work for what I was trying to do. I decided to take an FP approach. I had the project completed with far less code that I was happier with. In the same language. That was almost like an 'epiphany moment'. I started getting seriously interested about functional programming then. I am now starting to see the flaws and bloat in the approaches I was taking before. I recently read Out of the Tar Pit again. I had read it before but I didn't really get it. This time it excites me and made my brain whir with ideas. Especially on how I can make these approaches compatible with the constraints of my day job. I actually now digest as much as I can about FP. Haskell, as an important player, frequently comes up. After laying the ground work, monads make a lot more sense. Haskell as a language excites me. In my opinion, and I am self-taught when it comes to computers so it may not be 100% applicable, here is what I did to start my transition from imperative to declarative: a) experiment with functional programming. Not actually get it and be ok with that. Carry on down the path. b) Read HN and note articles posted about FP c) Continue learning about imperative programming and consume the advice from OO thought leaders. Apply it to your work. d) Learn a bit about maths and what it actually is, especially realising it's not just rote computation and application of algorithms from school. e) Take a functional approach instead of an OO approach within the language you are working with. I did this in PHP. Not only will it show you how FP compares, it will also show you why Haskell/OCaml/etc by way of the deficiencies for FP in your chosen languages. In PHP, the type system (arrays as your Everyman...) and inconsistent type hints, explicit closing over of variables in outer scopes and piss-poor support for modules is one. Biggest is the only way to pass a function in the function namespace is to use a a fully-qualifies string (so function name along with namespace - you get undefined constant otherwise). With Java, it might be that you cannot have stand alone functions, which would suck. This helped a lot for me but I'm sure spending a long time learning about software down to the hardware in my spare time contributed a lot to this too.

by mbrock 11y ago

jacquesm 11y ago

I think you're on to something here. It may be that programming languages that require you to 'reboot' are better suited to people totally new to programming than to people that already know how to program using some other methodology. This is because compared to your old, well used and worn tools that new tool starts off as a set-back rather than an advantage and we more or less expect an instant productivity boost from new technology. That set-back then becomes a huge hurdle to overcome. The question a programmer faced with a problem to solve is always one of investment: should I invest my time and effort into this new technology that will make me x times more productive or simply a better programmer (or someone capable of tackling more complex problems) a year or more down the line, or should I break out my trusty tools and turn a buck today (or turn a buck for my employer). In most cases that equation works out in favor of the old tools so the energy required would need to be offset by concrete short term gains if a person is to switch from one tech to another. That lack of concrete short-term gains is the big stumbling block for old hands, and if you manage to hack that then I think a lot of these better technologies would find traction. People new to programming don't have that particular hang-up and I'd expect them to do much better with such new tool or different tools. (But they'd have the same problem if they needed to switch to other tools, it's just that in this particular instance they have a blank slate advantage, that evaporates the moment they become proficient in that technology.)

jwdunne 11y ago
This comment and the parent comment was really interesting. It's made me think about my current path and somethings I have done/learned that has incrementally pushed me towards functional programming over a long window of time. I have played with Scheme, along with a half-completed SICP read through. I have also played with Haskell, along with partial read throughs of LYAH and real-world Haskell. Those experiences, although incomplete, have been important to me as a programmer. I don't think those actually 'sold' me on FP though. I took a detour for some time and decided to become a better programmer using OO methodologies. I used TDD, I memorised SOLID and all that. Read up on design patterns and then used them practically. All well and good. From my toying with Scheme, Haskell and associated literature, I wasn't entirely satisfied. The code I produced was always a bit, I'm not sure, but not entirely satisfiying. It looked and worked better than what I get given to review when considering freelancers for an extra pair of hands - part of that is because of PHP I think. I carried on this way for a while in any case. In my own self-learning, I'd started looking at language design and compilers. I read some books and decided I didn't have enough mathematical skills to consume the texts. I turned to learning discrete mathematics. That was a big eye opener. As I was reading about formal logic, set theory, proofs, etc, my mind kept turning to the problem of applying this in my work. Haskell and FP came to mind too. I believe doing this helped it finally click that a functional approach can be taken successfully in most of the work I do. Whilst I was doing this, I had a fairly simple project that, if designed correctly, could make my life easier in future projects. I took an OO approach, designed the UML, started writing tests, etc. I decided that it was over-engineered or at least it was a lot of work for what I was trying to do. I decided to take an FP approach. I had the project completed with far less code that I was happier with. In the same language. That was almost like an 'epiphany moment'. I started getting seriously interested about functional programming then. I am now starting to see the flaws and bloat in the approaches I was taking before. I recently read Out of the Tar Pit again. I had read it before but I didn't really get it. This time it excites me and made my brain whir with ideas. Especially on how I can make these approaches compatible with the constraints of my day job. I actually now digest as much as I can about FP. Haskell, as an important player, frequently comes up. After laying the ground work, monads make a lot more sense. Haskell as a language excites me. In my opinion, and I am self-taught when it comes to computers so it may not be 100% applicable, here is what I did to start my transition from imperative to declarative: a) experiment with functional programming. Not actually get it and be ok with that. Carry on down the path. b) Read HN and note articles posted about FP c) Continue learning about imperative programming and consume the advice from OO thought leaders. Apply it to your work. d) Learn a bit about maths and what it actually is, especially realising it's not just rote computation and application of algorithms from school. e) Take a functional approach instead of an OO approach within the language you are working with. I did this in PHP. Not only will it show you how FP compares, it will also show you why Haskell/OCaml/etc by way of the deficiencies for FP in your chosen languages. In PHP, the type system (arrays as your Everyman...) and inconsistent type hints, explicit closing over of variables in outer scopes and piss-poor support for modules is one. Biggest is the only way to pass a function in the function namespace is to use a a fully-qualifies string (so function name along with namespace - you get undefined constant otherwise). With Java, it might be that you cannot have stand alone functions, which would suck. This helped a lot for me but I'm sure spending a long time learning about software down to the hardware in my spare time contributed a lot to this too.