14 ms·

I'm a bit older than the author. Every time I feel like I'm "out of touch" with the hip new thing, I take a weekend to look into it. I tend to discover that the

by delinka 10y ago

I'm a bit older than the author. Every time I feel like I'm "out of touch" with the hip new thing, I take a weekend to look into it. I tend to discover that the core principles are the same, this time someone has added another C to MVC; or the put their spin on an API for doing X; or you can tell they didn't learn from the previous solution and this new one misses the mark, but it'll be three years before anyone notices (because those with experience probably aren't touching it yet, and those without experience will discover the shortcomings in time.) When learning something new, I find that this group implemented with $NEW_THING in a completely different way than that group did an implementation with the exact same $NEW_THING. I have a harder time understanding how the project is organized than I do grokking $NEW_THING. And when I ask "why not $THAT_THING instead?" I get blank stares, and amazement that someone solved the problem a decade ago. Sure, I've seen a few paradigm shifts, but I don't think I've seen anything Truly New in Quite Some Time. Lots of NIH; lots of not knowing the existing landscape. All that said, I hope we find tools that work for people. Remix however you need to for your own edification. Share your work. Let others contribute. Maybe one day we'll stumble on some Holy Grail that helps us understand sooner, be more productive, and generally make the world a better place. But nothing's gonna leave me behind until I'm dead.

tluyben2 10y ago
> Every time I feel like I'm "out of touch" with the hip new thing, I take a weekend to look into it. I tend to discover that the core principles are the same, this time someone has added another C to MVC; or the put their spin on an API for doing X; But that is only for the 'abstractions' they implement; the details are another thing. I feel the only thing that really changed is that now big companies with PR / marketing departments are on the case while before it was more a geek thing. There is nothing fundamentally different in new frameworks (heck, most are them are just rehashes of others that are many years old with very small improvements), but suddenly the echo chamber makes it out to be vital to your career. Like React. It's nice but come on... Every frontend programmer I know is fretting that they are not into it enough because you will die or something if you are not. That seems good marketing by Facebook to get such a solid drive behind it so quickly. But it's not needed for anything; you can still just use what you used before and often faster/better (because you are good at what you did for many years right?) and you don't have to bother with learning the latest thing all the time, while, with React, because you are drinking the cool aid, you have to update/refactor/redo stuff often because of changing libraries and new insights. It would make you stressed if think you feel you have to keep up with all of that. Also, some tools seem to have just been made to look smart. Really, something like Webpack doesn't have to be that obfuscated. It really looks like it has been made like that just to say; 'ah, you just do not get it'. I see people (20somethings included) really sweating in their keyboard when trying to figure out more than the basics of that thing; so why are people using it? Why is it actually popular?
- sotojuan 10y ago
  The Webpack story is interesting because its author isn't (well, wasn't) even a JS developer in his day job or was part of the JS community. I don't hate Webpack but I really have no idea where it came from. Browserify was made by one of Node's ecosystem top contributors, so at least that makes sense.
  - btown 10y ago
    And webpack's documentation is the spawn of Satan. Going outside the typical use cases is downright impossible. While it has the widest feature set out there, it's incredibly difficult to believe in its reliability. That said, since you can always QA your bundle, reliability isn't as much of an issue I guess...
    - s_kilk 10y ago
      > And webpack's documentation is the spawn of Satan. An insult to our Master, Satan would never create something so awful :P
    - biscarch 10y ago
      FWIW webpack's docs are getting much better for v2
- raarts 10y ago
  > React Similarly on Flux: I implemented an immutable store where only incoming messages change state and changes are distributed to widgets in 2005. Around the same time we started using feature flags in our application. We also did CI around 2000. Didn't call it that of course. Never did it myself but heard of TDD long before it became a thing. Again under a different name. Erlang. Superior technology that forms the heart of new kid on the block Elixir. Built long before the Bay Area CS grads re-invented ageism and claimed young people to 'be just smarter'. Sure some things are new, but there's just no respect for experience any more.
- Taek 10y ago
  What about Go? I like go a lot because I feel like they did hit the mark and they did learn from their predecessors. Strong standard library. Clean syntax. Easily compiles to every major platform and architecture (all you need to do is set an environment variable). Everything statically compiled (as a software distributor, this is super nice!). Phenomenal testing framework. It's not all that innovative, it's just very easy to use, and very well put together.
sotojuan 10y ago
What's the last truly new thing you can think of? I'm interested because I am young (22) but have studied programming language paradigms and history and I also agree a lot of "new" stuff is old.
- TheCowboy 10y ago
  Not exactly "new" but: Being able to spend ~$30 on a system powerful enough do everything faster than you could years ago for thousands of yesterday dollars. The feeling of not being limited by computing power for every thing is incredible. Vice versa, feeling like you aren't imaginative enough to utilize modern day power available, it's a great time to push your mind harder to take advantage of it.
- danpat 10y ago
  I work on navigation software (http://project-osrm.org/ http://project-osrm.org/). Many of the algorithms we're implementing (or at least considering) only exist in recently published papers, or sit behind unpublished APIs. There have been huge improvements in graph route-finding algorithms in the last decade, so much of it is new, interesting and it's far from run-of-the-mill implementation. I'm 38 - I spent the first many years of my career doing CRUD development, first in Perl (late 90's), then Java/PHP (2000's). I skipped the JS craze, and now I'm enjoying my work more than ever improving my C++ skills (last time I touched C++ was 98, modern C++14 is a huge improvement) and working on backend, specialized algorithm implementation. It's great! Experience is the best teacher. Kids don't listen to their parents, new developers don't listen to the greybeards until it's too late. This is the way things are :-)
  - YeGoblynQueenne 10y ago
    >> backend, specialized algorithm implementation Sounds great - how does one go about finding that sort of work in the industry?
    - danpat 10y ago
      I went looking. After years of cruft work, I took some time off to pursue other interests. When I was ready to come back to software development, I took a good hard look at the things I actually enjoyed doing, then went looking for organizations that did that stuff. I was fortunate to have the breathing room to be deliberate in my search.
partycoder 10y ago
MVC is from the 70s.
usgroup 10y ago
It's not long before you start thinking "f*ck the current new thing, what's the next new thing going to be? I'll try and spot that then jump onto the band wagon earlier" The new Devs are basically doing this by default. They are early adopters on the hype cycle and so leverage it for renum since it disrupts supply every time. Play the game old bean, it hasn't changed :)
pjc50 10y ago
There's an eternal war between "avoid reinventing the wheel" and ahistorical "not invented here", isn't there? Because the profession is so heavily skewed towards the young and self-taught, people don't seem to know about the solutions of a decade ago and their merits and demerits. This is partly why software componentisation as "parts catalog" has never really taken off. It's easier to reimplement or independently reinvent something than it is to find the right existing solution and learn it. It's as if it were easier to turn every bolt you needed on a lathe than to go to the shop for them. (The closest might be npm, but then we see what an engineer would call an excessively large bill-of-materials, as trivial projects pull in thousands of dependencies)
- douche 10y ago
  That's the constant battle. "Oh, this library kind of does what I want, but this behavior kind of sucks, and this bug hasn't been fixed... Do I shoehorn it in and write all the glue and adapter code? Fuck it, I'll just start over, and build yet another grid component, or datepicker, or rich-text editor."
- SticksAndBreaks 10y ago
  >There's an eternal war between "avoid reinventing the wheel" and ahistorical "not invented here", isn't there? There is a iternal itteration between reading disgusting Documentation (nonexistant one) and finding the hidden shortconmings of existing solutions - and just doing the only "open source" that is accepted in every company- rewrite it yourself.
- jerf 10y ago
  "This is partly why software componentisation as 'parts catalog' has never really taken off." Well, that and the fact that OO turned out to not be a very good mechanism for building the parts catalog on. In the end I'd judge it as only slightly more successful than procedural programming on that front. For instance, Haskell's "part's catalog" is somewhat smaller than other languages. But the parts do what they say they will, and generally go together pretty well once the community is done chewing on them and fixing them up. (Here I mean fundamental tools like parsers or text template systems, not merely "libraries to access this API" or "bindings to this particular library.) All those restrictions that go into Haskell are there for a reason.
andyjohnson0 10y ago
Late forties developer here. > Every time I feel like I'm "out of touch" with the hip new thing, I take a weekend to look into it. There's my problem right away. I can't just "take a weekend" to learn some new shiny thing. I have a partner and children who I want to be with at the weekend. And I'd rather go climbing or hiking or even just go out on my bike, than learn another damn api. Twenty years ago I had evenings and weekends to burn. Now I don't.
- toxik 10y ago
  I'm 26, and modulo the kids, this is how I feel as well. I've been programming professionally for almost ten years, and I feel less and less pressure to keep up with the latest packages on NPM or whatever the flavor of the month is. It's much more interesting to know what has been tried before, and why that didn't stick. Like this newLISP thing, why should we suddenly start writing Lisp? The language is older than C, for god's sake.
  - fao_ 10y ago
    NewLisp is over 25 years old.
  - progman 10y ago
    > why should we suddenly start writing Lisp? The language is older than C, for god's sake. If so many "modern" languages still copy features from Lisp (hello C++) then why not use the real thing? All those nice "new" features which Python and C++ are praised for (lambdas, closures, list comprehensions) have been available for almost 50 years. Lisp was way ahead of its time. It just lacked the hardware power which we have today. It is still ahead of our time. Consider Lisp macros, Genera and MCCLIM. MCCLIM is an interactive GUI for shells which has been neglected for decades. It is being revived right now to make it available for modern Lisp distributions. Modern Lisp just lacks one thing to be the real deal: a native Lisp Machine. https://common-lisp.net/project/mcclim/ https://common-lisp.net/project/mcclim/
    - jerf 10y ago
anexprogrammer 10y ago
A little past 50 here. I can relate. Yet some things have barely changed. Beyond 25 years ago it was Solaris or HPUX, using C, talking TCP/IP and mucking about with SQL. Some of us were sad at SVR4 as we still preferred the BSD view of things. Running Unix and 10 terminals on some 680x0, learning to get efficient in vi. Some preferred emacs. I was excited for the future, especially of hardware and the OS, as I'd seen it on the Amiga. I'd seen some of the crazy ideas being thought about, like we might have this mad thing called VR. That looks interesting. It's insanely expensive and made me feel a bit seasick, but maybe it'll be the cool fad of of 1990. We'll see. Fast forward to today. Oh. Well there's a lot more switches, and security has changed some things, desktops have pushed ideas because they think they're phones, but I'd never have conceived how similar so much would be. BSD isn't forgotten, mysql grew up and then some. Emacs and vi are still be being discussed. Why aren't old programmers more popular? I'm still interested in hip new things. I'm losing some enthusiasm though. There's an increasing number I haven't got to, as there's just too many of them. Too much is just fashion. So often I'm struck by how $NEW_THING gives something, but takes something or adds needless complexity, yet manages to be a variation on an aging theme. In frameworks the best $NEW_THING fashion changes hourly. Leaves me rather disappointed, but I'm still looking. And hoping.
- weaksauce 10y ago
  > Why aren't old programmers more popular? Cost and reduced willingness to work the death march hours that many places want the new hires to work/are willing to work to "prove" their worth.
- CyberDildonics 10y ago
  What about applying concurrency to more problems? So many of the basic ideas were discovered and tried a long time ago, but widespread application of concurrency still hasn't caught on.
  - blahfuk 10y ago
    Concurrency is still as hard today as it was 40 years ago. Prudent developers avoid it whenever possible.
agumonkey 10y ago
The more I learn about fundamentals (recently non determinism + predicate logic) the more I realize the trends are shallow (or not so shallow) obfusction of the same basic blocks. And pardon the following hint, I found FP a pretty good vehicle to express these blocks in an abstract manner. Binary operations, composition, accumulation, iteration, induction, state transitions.
larve 10y ago
While I'm not old, I have been a professional developer for 17 years and feel that first downwards curve in the author's graph (and I get frustrated at the younger programmer's reinventing the wheel from time to time). However, I never find myself confronted with things that are not genuinely new and interesting to learn and work on. A lot of these things are not new at all, but they are new to me: statistics, linear algebra, machine learning, compiler construction, PL research, model verification, graph algorithms, calculus, engineering modeling, vectorized programming, GPU programming, geometrical computation, and it just goes on and on. In each of those, you will have the fads of the day, the current hot framework, the second current hot framework, the old framework that works better. At the end of the day, I get the textbook, look up university courses on youtube, pick whatever framework shows up first in google, and spend time on the fundamentals. As a crude example, I may have to look up how to do a dot product in numpy / matlab / mathematica / c++ / R every second day, and when i learn something most of my programming is SO-driven, but I also can perfectly write a dot-product in clojure/factor/elixir/arm assembly if you asked me to, and then do a vectorized dot-product in CUDA/Neon SIMD/VHDL because I spent time on the fundamentals. The best thing that happens is when you start to see how one technique appears in so many different fields (for example SVD). Nothing is new, but most of it is new to me. After that I do spend a significant amount of time researching my tools (IDE, supporting apps, build systems, frameworks, compilers, programming languages), but that's the craftmanship part of it, and is kind of like doing the dishes and going to the farmer's market to have a nice kitchen to cook in and great ingredients to cook with.

by delinka 10y ago

tluyben2 10y ago

> Every time I feel like I'm "out of touch" with the hip new thing, I take a weekend to look into it. I tend to discover that the core principles are the same, this time someone has added another C to MVC; or the put their spin on an API for doing X; But that is only for the 'abstractions' they implement; the details are another thing. I feel the only thing that really changed is that now big companies with PR / marketing departments are on the case while before it was more a geek thing. There is nothing fundamentally different in new frameworks (heck, most are them are just rehashes of others that are many years old with very small improvements), but suddenly the echo chamber makes it out to be vital to your career. Like React. It's nice but come on... Every frontend programmer I know is fretting that they are not into it enough because you will die or something if you are not. That seems good marketing by Facebook to get such a solid drive behind it so quickly. But it's not needed for anything; you can still just use what you used before and often faster/better (because you are good at what you did for many years right?) and you don't have to bother with learning the latest thing all the time, while, with React, because you are drinking the cool aid, you have to update/refactor/redo stuff often because of changing libraries and new insights. It would make you stressed if think you feel you have to keep up with all of that. Also, some tools seem to have just been made to look smart. Really, something like Webpack doesn't have to be that obfuscated. It really looks like it has been made like that just to say; 'ah, you just do not get it'. I see people (20somethings included) really sweating in their keyboard when trying to figure out more than the basics of that thing; so why are people using it? Why is it actually popular?

sotojuan 10y ago
The Webpack story is interesting because its author isn't (well, wasn't) even a JS developer in his day job or was part of the JS community. I don't hate Webpack but I really have no idea where it came from. Browserify was made by one of Node's ecosystem top contributors, so at least that makes sense.
- btown 10y ago
  And webpack's documentation is the spawn of Satan. Going outside the typical use cases is downright impossible. While it has the widest feature set out there, it's incredibly difficult to believe in its reliability. That said, since you can always QA your bundle, reliability isn't as much of an issue I guess...
  - s_kilk 10y ago
    > And webpack's documentation is the spawn of Satan. An insult to our Master, Satan would never create something so awful :P
  - biscarch 10y ago
    FWIW webpack's docs are getting much better for v2
raarts 10y ago
> React Similarly on Flux: I implemented an immutable store where only incoming messages change state and changes are distributed to widgets in 2005. Around the same time we started using feature flags in our application. We also did CI around 2000. Didn't call it that of course. Never did it myself but heard of TDD long before it became a thing. Again under a different name. Erlang. Superior technology that forms the heart of new kid on the block Elixir. Built long before the Bay Area CS grads re-invented ageism and claimed young people to 'be just smarter'. Sure some things are new, but there's just no respect for experience any more.
Taek 10y ago
What about Go? I like go a lot because I feel like they did hit the mark and they did learn from their predecessors. Strong standard library. Clean syntax. Easily compiles to every major platform and architecture (all you need to do is set an environment variable). Everything statically compiled (as a software distributor, this is super nice!). Phenomenal testing framework. It's not all that innovative, it's just very easy to use, and very well put together.

sotojuan 10y ago

What's the last truly new thing you can think of? I'm interested because I am young (22) but have studied programming language paradigms and history and I also agree a lot of "new" stuff is old.

TheCowboy 10y ago
Not exactly "new" but: Being able to spend ~$30 on a system powerful enough do everything faster than you could years ago for thousands of yesterday dollars. The feeling of not being limited by computing power for every thing is incredible. Vice versa, feeling like you aren't imaginative enough to utilize modern day power available, it's a great time to push your mind harder to take advantage of it.
danpat 10y ago
I work on navigation software (http://project-osrm.org/ http://project-osrm.org/). Many of the algorithms we're implementing (or at least considering) only exist in recently published papers, or sit behind unpublished APIs. There have been huge improvements in graph route-finding algorithms in the last decade, so much of it is new, interesting and it's far from run-of-the-mill implementation. I'm 38 - I spent the first many years of my career doing CRUD development, first in Perl (late 90's), then Java/PHP (2000's). I skipped the JS craze, and now I'm enjoying my work more than ever improving my C++ skills (last time I touched C++ was 98, modern C++14 is a huge improvement) and working on backend, specialized algorithm implementation. It's great! Experience is the best teacher. Kids don't listen to their parents, new developers don't listen to the greybeards until it's too late. This is the way things are :-)
- YeGoblynQueenne 10y ago
  >> backend, specialized algorithm implementation Sounds great - how does one go about finding that sort of work in the industry?
  - danpat 10y ago
    I went looking. After years of cruft work, I took some time off to pursue other interests. When I was ready to come back to software development, I took a good hard look at the things I actually enjoyed doing, then went looking for organizations that did that stuff. I was fortunate to have the breathing room to be deliberate in my search.

partycoder 10y ago

MVC is from the 70s.

usgroup 10y ago

It's not long before you start thinking "f*ck the current new thing, what's the next new thing going to be? I'll try and spot that then jump onto the band wagon earlier" The new Devs are basically doing this by default. They are early adopters on the hype cycle and so leverage it for renum since it disrupts supply every time. Play the game old bean, it hasn't changed :)

pjc50 10y ago

There's an eternal war between "avoid reinventing the wheel" and ahistorical "not invented here", isn't there? Because the profession is so heavily skewed towards the young and self-taught, people don't seem to know about the solutions of a decade ago and their merits and demerits. This is partly why software componentisation as "parts catalog" has never really taken off. It's easier to reimplement or independently reinvent something than it is to find the right existing solution and learn it. It's as if it were easier to turn every bolt you needed on a lathe than to go to the shop for them. (The closest might be npm, but then we see what an engineer would call an excessively large bill-of-materials, as trivial projects pull in thousands of dependencies)

douche 10y ago
That's the constant battle. "Oh, this library kind of does what I want, but this behavior kind of sucks, and this bug hasn't been fixed... Do I shoehorn it in and write all the glue and adapter code? Fuck it, I'll just start over, and build yet another grid component, or datepicker, or rich-text editor."
SticksAndBreaks 10y ago
>There's an eternal war between "avoid reinventing the wheel" and ahistorical "not invented here", isn't there? There is a iternal itteration between reading disgusting Documentation (nonexistant one) and finding the hidden shortconmings of existing solutions - and just doing the only "open source" that is accepted in every company- rewrite it yourself.
jerf 10y ago
"This is partly why software componentisation as 'parts catalog' has never really taken off." Well, that and the fact that OO turned out to not be a very good mechanism for building the parts catalog on. In the end I'd judge it as only slightly more successful than procedural programming on that front. For instance, Haskell's "part's catalog" is somewhat smaller than other languages. But the parts do what they say they will, and generally go together pretty well once the community is done chewing on them and fixing them up. (Here I mean fundamental tools like parsers or text template systems, not merely "libraries to access this API" or "bindings to this particular library.) All those restrictions that go into Haskell are there for a reason.

andyjohnson0 10y ago

Late forties developer here. > Every time I feel like I'm "out of touch" with the hip new thing, I take a weekend to look into it. There's my problem right away. I can't just "take a weekend" to learn some new shiny thing. I have a partner and children who I want to be with at the weekend. And I'd rather go climbing or hiking or even just go out on my bike, than learn another damn api. Twenty years ago I had evenings and weekends to burn. Now I don't.

toxik 10y ago
I'm 26, and modulo the kids, this is how I feel as well. I've been programming professionally for almost ten years, and I feel less and less pressure to keep up with the latest packages on NPM or whatever the flavor of the month is. It's much more interesting to know what has been tried before, and why that didn't stick. Like this newLISP thing, why should we suddenly start writing Lisp? The language is older than C, for god's sake.
- fao_ 10y ago
  NewLisp is over 25 years old.
- progman 10y ago
  > why should we suddenly start writing Lisp? The language is older than C, for god's sake. If so many "modern" languages still copy features from Lisp (hello C++) then why not use the real thing? All those nice "new" features which Python and C++ are praised for (lambdas, closures, list comprehensions) have been available for almost 50 years. Lisp was way ahead of its time. It just lacked the hardware power which we have today. It is still ahead of our time. Consider Lisp macros, Genera and MCCLIM. MCCLIM is an interactive GUI for shells which has been neglected for decades. It is being revived right now to make it available for modern Lisp distributions. Modern Lisp just lacks one thing to be the real deal: a native Lisp Machine. https://common-lisp.net/project/mcclim/ https://common-lisp.net/project/mcclim/
  - jerf 10y ago

anexprogrammer 10y ago

A little past 50 here. I can relate. Yet some things have barely changed. Beyond 25 years ago it was Solaris or HPUX, using C, talking TCP/IP and mucking about with SQL. Some of us were sad at SVR4 as we still preferred the BSD view of things. Running Unix and 10 terminals on some 680x0, learning to get efficient in vi. Some preferred emacs. I was excited for the future, especially of hardware and the OS, as I'd seen it on the Amiga. I'd seen some of the crazy ideas being thought about, like we might have this mad thing called VR. That looks interesting. It's insanely expensive and made me feel a bit seasick, but maybe it'll be the cool fad of of 1990. We'll see. Fast forward to today. Oh. Well there's a lot more switches, and security has changed some things, desktops have pushed ideas because they think they're phones, but I'd never have conceived how similar so much would be. BSD isn't forgotten, mysql grew up and then some. Emacs and vi are still be being discussed. Why aren't old programmers more popular? I'm still interested in hip new things. I'm losing some enthusiasm though. There's an increasing number I haven't got to, as there's just too many of them. Too much is just fashion. So often I'm struck by how $NEW_THING gives something, but takes something or adds needless complexity, yet manages to be a variation on an aging theme. In frameworks the best $NEW_THING fashion changes hourly. Leaves me rather disappointed, but I'm still looking. And hoping.

weaksauce 10y ago
> Why aren't old programmers more popular? Cost and reduced willingness to work the death march hours that many places want the new hires to work/are willing to work to "prove" their worth.
CyberDildonics 10y ago
What about applying concurrency to more problems? So many of the basic ideas were discovered and tried a long time ago, but widespread application of concurrency still hasn't caught on.
- blahfuk 10y ago
  Concurrency is still as hard today as it was 40 years ago. Prudent developers avoid it whenever possible.

agumonkey 10y ago

The more I learn about fundamentals (recently non determinism + predicate logic) the more I realize the trends are shallow (or not so shallow) obfusction of the same basic blocks. And pardon the following hint, I found FP a pretty good vehicle to express these blocks in an abstract manner. Binary operations, composition, accumulation, iteration, induction, state transitions.

larve 10y ago

While I'm not old, I have been a professional developer for 17 years and feel that first downwards curve in the author's graph (and I get frustrated at the younger programmer's reinventing the wheel from time to time). However, I never find myself confronted with things that are not genuinely new and interesting to learn and work on. A lot of these things are not new at all, but they are new to me: statistics, linear algebra, machine learning, compiler construction, PL research, model verification, graph algorithms, calculus, engineering modeling, vectorized programming, GPU programming, geometrical computation, and it just goes on and on. In each of those, you will have the fads of the day, the current hot framework, the second current hot framework, the old framework that works better. At the end of the day, I get the textbook, look up university courses on youtube, pick whatever framework shows up first in google, and spend time on the fundamentals. As a crude example, I may have to look up how to do a dot product in numpy / matlab / mathematica / c++ / R every second day, and when i learn something most of my programming is SO-driven, but I also can perfectly write a dot-product in clojure/factor/elixir/arm assembly if you asked me to, and then do a vectorized dot-product in CUDA/Neon SIMD/VHDL because I spent time on the fundamentals. The best thing that happens is when you start to see how one technique appears in so many different fields (for example SVD). Nothing is new, but most of it is new to me. After that I do spend a significant amount of time researching my tools (IDE, supporting apps, build systems, frameworks, compilers, programming languages), but that's the craftmanship part of it, and is kind of like doing the dishes and going to the farmer's market to have a nice kitchen to cook in and great ingredients to cook with.