(Context: I've been programming since I was 12, 30 years ago).
Edit: Thank you for all the replies! I can not comment individually at the moment because of HN posting limits.
Instead I'm now mucking around with a Unity game, using C# which I already know, and have suddenly found the motivation to start the udacity android course.
Just do what you want to do, not what you think you should do, once you've got your enthusiasm for programming back you'll find an excuse to learn something new.
One of the most insidious ideas people fall into is that they have to spend all of their free time learning new things all the time or else they will fall behind. You should spend some time on professional development, but when you've hit the wall banging your head against it doesn't help.
Go build some hardware or a rocking chair, or a yoga studio or whatever. The lessons learned doing that can apply to your profession as well.
Then the annoying time it takes to setup frameworks and do the simplest things! IDEs? meh! Especially if you are super comfortable with your vi or Emacs.
So what do you do? Pick up a book with lots of examples, don't think too much about it. Just type in the damn examples like a zombie, breeze through the chapters, by the time you are half way you will start getting into the book, don't forget to modify the examples to your own taste as you learn.
Looking into data science, now is actually the first time I keep seeing PhD listed as a requirement for jobs that would interest me.
Maybe one day - atm I don't really have any connections into academia and wouldn't quite know how to find a worthy subject and a willing mentor.
Also, I am 42.
I've worked with two commercial C++ systems designed around the reactor pattern, so perhaps not an expert, but this is not a drive-by comment either.
The C++ projects I worked on ended up requiring extra little "threads on the side" to deal with stuff like sync DB drivers or closed source libs. Little inefficiencies added up to the point where we may as well have done the darn things in JS anyway.
You're trying to make an (extremely weak) reductio ad absurdum argument, an intellectually bankrupt solipsist.
There's no point engaging you with anything more than exasperation, especially since the guy's asking for help, not useless snark.
Actually, to be completely honest, because you've made me angry now, only an asshole would say something like that to someone asking for help.
Not that obvious for me. I cannot see any significant changes. Mind giving some examples?
> especially since the guy's asking for help
He's asking for motivation, not for help. And it should be good to know that he do not need to learn much, everything is pretty much the same as it used to be, just presented slightly differently. New terminology can be learned in a couple of days.
And this is the false perception that things have changed and there is a lot to learn that made the OP feel powerless. You're not helping him by reiterating the bullshit that have scared him in the first place.
I used to be a Java developer, but haven't monitored the developments of the language and best practices for the last 3 years. Also I don't really like Java anymore.
I ponder getting into Android, but it's Java again, and then I find I have to learn a whole new style language that is almost but not quite like CSS, but seemingly less powerful.
I don't really care about agile development or scrum, another deal breaker for many jobs.
I like data science, but it seems mostly PhDs fresh from university or other young people are being hired for that. I actually enjoy doing Coursera or Udacity courses in data science, but it's not enough.
ECMA-262: around 250 pages, most of which is just water. One day reading. No new concepts are introduced over anything that existed 30 years ago, so it does not require any learning, just knowing where to look for a reference.
> client side frameworks
Who need to learn the libraries? They must have some documentation, I suppose. And again, I really doubt any of those managed to introduce a fundamentally new concept which was not known 30 years ago.
> but haven't monitored the developments of the language and best practices for the last 3 years
The safest assumption is that nothing really changed.
> I like data science
I.e., statistics, a > 100 years old science.
I am not saying it would be difficult. But I lack the energy. I have read a lot of documentation in my 30 years of programming.
Do you have any domain knowledge outside of programming? A data scientist who understands the domain they're dealing with is a rarity and at least in my opinion worth more than someone who knows all the math, but has no grounding in what he's actually trying to analyse.
You have just saved a considerable amount of time and nerves. Not only will they fundamentally change it in version 2.0, they are going to use a different language - TypeScript flavour.
In fact, I had to resort to a calculator to check my arithmetic, something I haven't had to do in a long time. I checked my calendar to make sure it really is 2015, and then:
$ eq 2015-1989
> 26
I, too, find myself falling behind. I don't know what a "container" might be, and I certainly don't know what "docker" is. I don't know how to write an app, and I've never seen code that uses react.js
In fact, with a few exceptions I don't know what any of these are:
> http://en.wikipedia.org/wiki/List_of_JavaScript_libraries
I have programmed in Python, Ruby, and Haskell, but if you think nothing has fundamentally changed in the last 30 years, good for you.
> I don't know what a "container" might be
It's some poor man crap that mimics the IBM mainframes from 1970s.
> I have programmed in Python, Ruby, and Haskell, but if you think nothing has fundamentally changed in the last 30 years, good for you.
Smalltalk, Simula, Lisp, ML, Miranda, all are over 30 years old. Python, Ruby and Haskell did not bring anything fundamentally new.
And I've programmed in Smalltalk, Simula, Lisp (of various flavors), ML, Miranda, C, BCPL, MCPL, Occam, zed (probably not the one you're thinking of), BASIC (probably not the one you're thinking of), ForTran (probably not the one you're thinking of, or that one either) and more, and to me, there's a great deal to learn to get to Haskell, OCaml, etc., and even more to learn to get into the current ecosystems.
What exactly? If all that "new" stuff is just a poor, crappy execution of the concepts that had been around for over 30 years. There is nothing new to learn, same old stuff presented slightly differently.
> it's all the crap you need to learn
Do you really need to learn something as simple as a new syntax for the same old stuff? I hope you're not memorising APIs and command line arguments - it's always better to look this stuff up as you go.
> there's a great deal to learn to get to Haskell, OCaml
Mind naming any fundamentally new concepts introduced by Haskell or OCaml? Type classes? Not that new, and still worse than the good old SML modules. STG? Implementation minutiae. Or you're referring to "learning" the ghc command line options and things like hackage? Things you can look up in seconds are not worth any "learning".
Applicative functors seems an example of something "new" as the paper introducing it is form 2008.
Which concepts exactly?
> Applicative functors seems an example of something "new"
Too small a thing to be fundamental, to require any degree of re-learning.
Of course there is a lot of new fancy syntax sugar and all that, but the nature of the lazy languages did not change a bit since Miranda. If you knew Miranda, you'll learn Haskell in no time, and 30 years in between them would not make it any harder.
But yeah, since Turing and Church the fundamentals of computation hasn't changed. Nil novum sub sole
So, back to the point: anyone who knew how to program 30 years ago would easily pick it up now, without any significant learning.
For OCaml:
- row polymorphism (in particular polymorphic variants)
- higher-order and applicative functors (not the Haskell thing).
- first-class modules
For both:
- Higher-rank polymorphism
For Haskell (and now in both):
- GADTs
By introduced here, I'm ignoring them being implemented in toy languages first (since that is simply the first step of introducing them to programming). Similarly, it is not reasonable to say that F-omega or a dependently typed calculus already had such features, because that ignores issues of type inference and efficient implementation.
[1]: My father always attributed it to Zhukov.