I am a self-taught programmer, with little in the way of formal background. I worked my way through college (yes, I am old enough that it was possible for me to work full-time and pay for classes out of my own pocket at a state school, though I had a huge support network to fall back on for which I am very grateful) but as an electrical engineering major, not as computer science major. I left before completing that degree, to take a job in the network security. When I went back to finish, I completed in a made up degree: Liberal Science degree in Interdisciplinary Studies with concentrations in Political Science and Computer Science (no, that's really the name. It's on the degree -- across several lines -- and everything). Even my Masters is not pure computer science -- it's a CIS degree.
The point of that little biography is that I do not have a deep academic background in computer science. I have a deep interest that I have fed in my spare time and wherever and whenever work has allowed me, but there are gaps in my academic understanding. One of those gaps is functional programming. I know what it is, I know some of the underpinnings, but I don;t understand how it works in real life, as I haven't written anything in a functional language or style more complicated than hello world. But the more I read about real world experiences with it, the more it intrigues me. It reminds me of what I feel is a lost attitude toward programming: the Unix mindset.
When I was first teaching myself programming for work, I was learning C based languages, like Perl and, umm C, in Unix environments. Unix programs tended to be small, self-contained and interested in one thing and one thing only. I love that mindset. To me, it makes it easier to build large systems. If each piece of your system is small enough to be well understood and with a narrow-enough focus to minimize the unintended side effects of interactions (or, at least, make tracing the culprit easier) then you can build much more stable, expandable and complex systems out of those parts. That mindset seems to have been lost somewhat to what I think of as the Java languages.
Languages like Java and the .NET family are predicated on big builds, large programs with lots of embedded dependencies generally deployed as huge packages against an equally huge application server. It is much harder to understand such systems, harder to change them, and harder to scale them. Even in the JavaScript domain, a lot of frameworks seems to be "java like" and do not make modularity and simplicity core concerns. Complexity is the devil; if you are going to build complexity, make sure you build it based on simplicity. The Unix mindset does that; the Java one does not.
Which brings me to Haskell. I keep seeing quotes like this:
“It’s safe in Haskell to run two functions at the same time. You know there will be no side effects. ..."
and it reminds me of the Unix mindset. Languages and programming systems that have, at their heart and in their design, the mindset of simple, isolated building blocks feel like the Right Way to Program. Languages that have the opinion built into them are an advancement, it seems to me. So I am going to try it out. I am going to build
something real world-ish in Haskell. Why Haskell? Because it seems to be the most purely functional language with a decent sized user base. What am I going to build? Dunno, feel free to suggest something. If nothing else, you can be amused by the process, for as long as I manage to keep it up in the face of almost inevitable failure.
This may not be the most practical task ever, but never turn down the chance to learn, I occasionally say before I get frustrated by whatever damn-fool thing I am chasing after. I have said this before, but programming is not a discipline, it is an art. Playing with new ways of doing things is collectively how we advance that art, even if its only your own personal artistic talent.