This is roughly how I learned; I used Hakyll[0] to make my personal site, and working with the Compiler monad it uses taught me to understand monads and use do notation.
It's way easier to learn when you have a reason to be learning, and abstractions always make more sense when you have a case to motivate them.
Nice example to look at @wetmore, very jeckyl and something I recognise well. I got sick of trying to get Rails working on my light server so I wrote my own in Python version using the same file structure(.md + yaml). So looking at a Haskell example is great. The only bummer I see using Haskell is the install for GHCi. [0]
[0] All my development is on RaspberryPi. You can get it going hacking thru the source but it's a pain. So the running working code generating things is a sort of anti-dote sort of negates this problem.
Thanks, I almost lost hope that I will get a sensible answer. I don't buy the argument that real world code cannot be pretty; what would be the reason to use Haskell, then?
Bangs are well written and idiomatic Haskell code. Haskell is a default-lazy language. Good code uses lazy algorithms (to avoid wasted work) and strict data structures (to avoid space leaks), so efficient data structures need the bangs.
Real-world code (which is what most projects consist of) is rarely fully idiomatic and well-written, because it contains fixes to weird edge cases only some users experience, performance optimisations and such.
You mean production code doesn't look as pretty and toy code.
Production code that performs well is well written and idiomatic if it follows the common practices of production code.
I suffer from the problem of languages changing over time as I became disabled in 2003, been in hospitals a lot, recovering at home a lot. Trying to get back into programming after 13+ years of recovery and medical debt that forced me into bankruptcy.
Any book I own is way out of date, I bought books in 2008 that are out of date already. I might as well code in COBOL and FORTRAN on an old Mainframe that didn't change since the 1970s as I still have books from college on those. I tried to work in retroprogramming in writing code for old languages like Visual BASIC 6.0 and ASP 3.0 and VBScript, but found no takers.
I read the LYAH book and found I couldn't get the code to work, Functional Programming is still new to me, so I struggle with it. I was contacted by someone on Github over the debate they had about a code of conduct and she writes in F Sharp and wanted to pair program with me. So I had to learn F Sharp, which is another functional language. I took an EDX course that Microsoft offered on it. I have Visual Studio 2013 Community edition, and I found that even if they say I can use 2013, the course is graded in 2015 which made changes to F Sharp. Some code won't compile and has to be rewritten, code that I write that passes tests may not work in 2015 so my homework assignments got points taken off. Had they run it in 2013 it would have gotten 100% on a score. I was two weeks behind due to being sick and I caught up on everything but the last homework program and I scored 66% needing 50% to pass the course. Even Microsoft changes the way their languages work. What few F Sharp books that exist, are out of date just like the Haskell books.
Oddly enough I have Turbo C code I wrote in 1987 that still compiles on most modern C compilers. I got C4Droid on my Android phone and it compiles the C code without any errors and runs them just right as well. I saved my code on a floppy disk and the moved them to a USB drive and transferred them to my Android phone to see if it would still work.
I sort of wonder why most modern languages aren't backward compatible like C is, and why they break compatibility. I guess it is so they can charge more for the training in the new standard and write new books and teach more courses? Either that or the changes they made had optimize the language so it used less memory and ran faster but broke compatibility wit legacy code.
I find myself still using Python 2.7 instead of 3.X, because I have books that have code that still works with it, and 3.X breaks a lot of things. I found that a lot of GNU/Linux still uses Python 2.X and when you install Python 3.X it is called Python3 on the command line.
This video helps me understand Haskell a bit more, and looking in Github for FOSS Haskell projects to view the source code would help as well.
But I find as soon as I learn something, it has been changed and there is a new version available.
I might be way off with this advice but perhaps consider using Google more. If something doesn't work as expected, say, in Python 3, just search for the error message in a 'normalized' form (i.e. without specific variable names etc.) and add a "python 3". Chances are someone has written up a solution for the problem on stackoverflow.com or other forums. Don't hesitate to blatantly adapt code from somewhere else. Everybody does it and it speeds up your work. Don't listen to those complaining that this would prevent a deeper understanding of the code, usually it doesn't.
Unfortunately, as you're keenly aware, the software development industry has a tendency to attempt to reinvent itself every few years. It might stop eventually.
For the specific problem of python, consider using 2to3.py to catch most problems (it'll fix up minor API changes and the like). It might help :)
Although being pessimistic about technology is my pass time, I'd imagine that breaking backwards compatibility is not done for business purposes. Two points of data on that line of reasoning:
1. C has a number of active, popular compilers (gcc, clang and msvcc, but I haven't kept up) which keeps maintainers from individually removing _too_ much functionality -- it's typically a poor business decision to remove compatibility bullet points from your product. Python (excluding pypy since it makes the typically poor business decision to remove compatibility bullet points) and F# are single-major implementation languages, giving them a fair bit more freedom to experiment.
2. Off the top of my head, Java and C# have compatibility going back many, many years. Considering that they've huge corporate backers that would have a lot of incentive to deprecate functionality continuously, that seems a good counterexample. A point could be made regarding feature addition rather than subtraction, but similarly that applies to C++ ...
Nope. There have been many changes since Haskell 98: for example Applicative is now a superclass of Monad. So not only could you not force a current GHC to compile Haskell 98; in addition, you cannot get Haskell 98 to compile on a current GHC at all.
The only way to be sure you can compile old Haskell is to keep an old GHC and old libraries around. Stackage should make this easier going forward.
It's way easier to learn when you have a reason to be learning, and abstractions always make more sense when you have a case to motivate them.
[0]: http://jaspervdj.be/hakyll/