3 ms·

Yes, I've been surprised too by the sentiment in the article of "it's too hard to keep up with new developments in programming languages" because that is what w

by kleiba 5y ago

Yes, I've been surprised too by the sentiment in the article of "it's too hard to keep up with new developments in programming languages" because that is what we all face, be it young or old. It is true, though, that it feels like change has been accelerated greatly over recent years. I mean, how many different programming language were actually used outside of niche applications in the 80s, maybe even 90s? More than a couple, for sure, but if you look at popular languages right now, there's a really long (and not overly thin) tail. And a lot of the languages you'll find on that list are fairly young, while older languages have mostly disappeared (besides C maybe). I do wonder though what the author finds so hard to learn. I'm not exactly new, either, but with more experience I don't necessarily find new things harder to learn than when I was young. It's different - perhaps my brain doesn't work as quickly any more but with more experience, it's either to recognize where "new" concepts are very similar to stuff you already know. With programming, I think there are people who get it easily and those who struggle. And don't mean "at first" but in general, and those who struggle would probably struggle with any language be it new or old, while those to which it comes more naturally should be able to adjust to new languages fairly easily, no? But then again, it's not just the languages that are new, but development styles have also changed quite dramatically since the time the author first entered the industry. Just think how much powerful IDEs have changed the style of development - hot swap, time traveling debuggers, inline documentation, on-the-fly compilation with in-editor error messages, refactoring support,... This is all stuff that the author is implicitly referring to as well.

smackeyacky 5y ago
Exactly. Although to me the style of programming has kind of come full circle. We all used to make fun of Emacs as an operating system in search of a good editor, but VSCode is basically a very Emacs like environment. The resurgence of the command line has surprised me, in a good way. Sitting at a debian box with VSCode and a few terminal windows humming isn't a big leap from what having a sparcstation on my desk used to feel like. Visual Studio and Android Studio suddenly feel very old fashioned and confining. Edit: to be fair, if your background was mainframe programming, most of those paradigms would be pretty alien.
- kleiba 5y ago
  Interesting. Would you mind elaborating about this "full circle" analogy? How come the preferred way of coding is now a combination of a powerful editor + the command line (again)?
  - smackeyacky 5y ago
    If you had a Sun3 or a Sparcstation, you would have a windowing environment that most of us basically used like having a corral of terminals in front of us (or at least that's what I would do). Actually I think the first Sun I sat at (at the Australian National University in Canberra) was running SunView: https://en.wikipedia.org/wiki/SunView https://en.wikipedia.org/wiki/SunView At the time, the Sun workstation (and competitors) made the graphics on a PC look pathetic. A PC simply couldn't drive enough dots on the screen to compete with Sun or SGI. I'm talking about programming a big system in C here but other languages would be similar. A pile of terminals would be your editors. If you were lucky, you could drag out your window and the editor would still format OK (vi was good at this, emacs sometimes not so good depending on your local sysadmin and what they had installed). Other editors... didn't really do that and you were stuck with whatever the termcap entries on the machine looked like. There were native "windowed" editors available but they mostly sucked for a programmer as they were more like "point and click" and didn't have all the buffer commands, quick jump to the line you wanted etc. shortcuts that a good programmers editor has. Line numbers are important! Most non-trivial programs have lots of source files, so you would have half a dozen vi sessions in half a dozen windows running. One window I would use just for running the compiler. The workflow was: compile the program, compiler spits out line number and file where problem is. Likely you already have it open so jump over to that window, fix the problem, :w!, recompile. Once it compiled, fire up dbx or whatever was installed and run your stuff. dbx was (is?) capable of setting break points, inspecting things etc. You'd find the issue, kill the debugger, fix it, recompile. Happy programmers felt a new freedom compared to being hunched over a vt220 terminal. It was bliss. Then, Visual Basic turned up. It took all the ideas of something like Turbo Pascal (everything on one screen) and kinda smooshed it together with the workstation windows idea, but instead of little windows all over the place, you have one big window with a pile of little windows inside it. For small screens (say 640x480) it felt a bit like having a Sun. Well, it felt like a Fisher Price toy but for putting together CRUD GUI apps it was pretty much unbeatable. At that point I had moved onto Smalltalk (VisualWorks) but it was not like Unix. Everything is inside the environment - windows spread out everywhere but no command line stuff whatsoever. For the time it was fantastic (sorry digression). Eventually, as the capabilities of PC's increased the industry kind of settled on things like Visual Studio where you have one screen, and tabs, and everything you need to do is on a menu somewhere. But having somebody have to program up all those menu items just about kills the release cycle of new features. Every time you add a new feature to the compiler you have to change the properties screen, test it, merge it, roll it into the next release. I understand why Microsoft in particular abandoned that idea for .NET where the importance of a PowerShell window really started to come into play. Outside of MS you start to get things like Node.js where you need to run a command line tool to set things up. So it became normalised to want a rich CLI and all the nice things like "more" and "grep" suddenly become more useful again. Which is unfortunate if you are running Windows because suddenly you have to install a pile of 3rd party stuff. And along with it the most uselessly named system in the history of uselessly named things: chocalety. Hey whoever named chocalety, go f*ck yourself. So VSCode is almost back to where I started. It has a bunch of tabs instead of different editor windows, but a lot of the time I'm in a terminal running "code ." and starting another instance of it. The compiler is running in a terminal session within VSCode but you don't have to do things that way and sometimes I don't, I have another terminal open where I do "dotnet start" or "docker run" and just attach to the process rather than using the vscode built-in launch stuff, because I want to drag that output window out nice and long instead of being cramped to 8 lines at the bottom of VSCode. Onion on belt etc. edit: If you really want to know where all the Ctrl-Z, bg, fg etc. stuff came from in the Unix shells, it was programmers who had 10 vi sessions running on a single terminal and were switching around between tasks.
taylodl 5y ago
> I mean, how many different programming language were actually used outside of niche applications in the 80s, maybe even 90s? I started my career in 1985. I've never been a mainframe programmer, but I know back in the day they were using Cobol (still do!), RPG, PL/1, and JCL. On the minicomputer side they were using Fortran, Lisp and C. Microcomputers also adopted C but also added Pascal, Modula-2/3, and of course, Basic. In the late 70's and even early 80's they were still working on the paradigm shift to structured programming. That's table stakes today but yes, there was a time when structured programming was a paradigm shift. Structured programming was all the buzz. And then came those weirdos from Xerox PARC with Smalltalk and talking about "object-oriented programming." Great. Another paradigm shift. Bjarne Stroustrup then had to go and post incrementally improve C to add object-oriented programming to give us C++. So far we've only made it to 1986 and we haven't talked about platforms! The various mainframes, minicomputers and microcomputers and all the different operating systems running on all of them. Since you said "maybe even 90s" then I would remind you that's when Python, Perl, Java, Ruby, and C# all came into being. From my perspective things have slowed down dramatically over the past 10-15 years. We only have 4 major OSs, 2 microprocessor architectures and there haven't been that many new languages: Go, Rust, Julia, Scala, Kotlin, and Clojure (hmm, maybe there have been a few new languages!) You could argue there's another paradigm shift afoot, functional programming, but it's been around since the 80's (!) and hasn't had widespread adoption. Finally, it's far easier to learn today than it was back then pre-widespread internet. You used to have to read periodicals and buy books. There weren't videos, tutorials, and the plethora of training options there are today. Add to it that all the tools you need to get started are free and you're all set! Bottom line - I'd say it's easier than ever to keep up with new developments. The field is moving slower and there's more resources available to keep up with the changes.
- jareklupinski 5y ago
  I'm just happy we've all settled on a single endian-ness :)
tharne 5y ago
> Yes, I've been surprised too by the sentiment in the article of "it's too hard to keep up with new developments in programming languages" because that is what we all face, be it young or old. What you're ignoring here is that in your 20's and early 30's you have nothing but time. You can spend your evenings and weekends reading O'Reilly books and churning out cool side projects. As you get older, non-work responsibilities increase massively for most people, as you spend time taking care of children, elderly parents, doing small home repairs, etc. Suddenly you can't just drop everything and spend the entire weekend reading documentation and tutorials when $BIG_CORP suddenly decides that all work must henceforth be done in $SEXY_NEW_FRAMEWORK_X.
- smackeyacky 5y ago
  I agree with the time issue, but we didn't have resources like StackOverflow or reams of personal blogs back then. I find it easier to learn something new now, at least easier to get over that initial learning curve. Proficiency still takes time but it always did.
- ChrisLomont 5y ago
  >that in your 20's and early 30's you have nothing but time 20's and 30's are where lots of people have time pulled away by kids, not later (median in 2020 was around 28 for kids). And in your 50's and 60's people generally have lots more time as kids move out (28+20=48 = kids gone or at least not such a time sink). If anything, 50's and 60's should be a golden age of learning.
- mbrodersen 5y ago
  I have worked with plenty of young people who had zero interest in learning anything new. It isn’t an age problem. It is a personality problem.
AnimalMuppet 5y ago
> I mean, how many different programming language were actually used outside of niche applications in the 80s, maybe even 90s? More than a couple, for sure, but if you look at popular languages right now, there's a really long (and not overly thin) tail. First, I think there were a lot of languages then, too. It's just that you haven't heard of them. SNOBOL? JOVIAL? There were 1700 known languages in 1965 (quote at the top of https://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf https://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf). In 1990, say, there was Lisp, FORTRAN, COBOL, BASIC, PL/I, APL, probably still some ALGOL. Then there was the Unix-flavored stuff: C, PERL, awk, sed. There was Pascal, Simula, and Smalltalk. Today I think the picture is similar, except for one thing: web frameworks. If you exclude web frameworks, there aren't that many languages in general use today. C, C++, C#, Java, go, python, Swift. Maybe Clojure, Kotlin, or Scala, depending on how you define "general use". I think that a huge amount of the churn is in web languages and web frameworks. Outside of that, languages aren't moving that fast at all.
deleted 5y ago
[deleted]

by kleiba 5y ago

smackeyacky 5y ago

Exactly. Although to me the style of programming has kind of come full circle. We all used to make fun of Emacs as an operating system in search of a good editor, but VSCode is basically a very Emacs like environment. The resurgence of the command line has surprised me, in a good way. Sitting at a debian box with VSCode and a few terminal windows humming isn't a big leap from what having a sparcstation on my desk used to feel like. Visual Studio and Android Studio suddenly feel very old fashioned and confining. Edit: to be fair, if your background was mainframe programming, most of those paradigms would be pretty alien.

kleiba 5y ago
Interesting. Would you mind elaborating about this "full circle" analogy? How come the preferred way of coding is now a combination of a powerful editor + the command line (again)?
- smackeyacky 5y ago
  If you had a Sun3 or a Sparcstation, you would have a windowing environment that most of us basically used like having a corral of terminals in front of us (or at least that's what I would do). Actually I think the first Sun I sat at (at the Australian National University in Canberra) was running SunView: https://en.wikipedia.org/wiki/SunView https://en.wikipedia.org/wiki/SunView At the time, the Sun workstation (and competitors) made the graphics on a PC look pathetic. A PC simply couldn't drive enough dots on the screen to compete with Sun or SGI. I'm talking about programming a big system in C here but other languages would be similar. A pile of terminals would be your editors. If you were lucky, you could drag out your window and the editor would still format OK (vi was good at this, emacs sometimes not so good depending on your local sysadmin and what they had installed). Other editors... didn't really do that and you were stuck with whatever the termcap entries on the machine looked like. There were native "windowed" editors available but they mostly sucked for a programmer as they were more like "point and click" and didn't have all the buffer commands, quick jump to the line you wanted etc. shortcuts that a good programmers editor has. Line numbers are important! Most non-trivial programs have lots of source files, so you would have half a dozen vi sessions in half a dozen windows running. One window I would use just for running the compiler. The workflow was: compile the program, compiler spits out line number and file where problem is. Likely you already have it open so jump over to that window, fix the problem, :w!, recompile. Once it compiled, fire up dbx or whatever was installed and run your stuff. dbx was (is?) capable of setting break points, inspecting things etc. You'd find the issue, kill the debugger, fix it, recompile. Happy programmers felt a new freedom compared to being hunched over a vt220 terminal. It was bliss. Then, Visual Basic turned up. It took all the ideas of something like Turbo Pascal (everything on one screen) and kinda smooshed it together with the workstation windows idea, but instead of little windows all over the place, you have one big window with a pile of little windows inside it. For small screens (say 640x480) it felt a bit like having a Sun. Well, it felt like a Fisher Price toy but for putting together CRUD GUI apps it was pretty much unbeatable. At that point I had moved onto Smalltalk (VisualWorks) but it was not like Unix. Everything is inside the environment - windows spread out everywhere but no command line stuff whatsoever. For the time it was fantastic (sorry digression). Eventually, as the capabilities of PC's increased the industry kind of settled on things like Visual Studio where you have one screen, and tabs, and everything you need to do is on a menu somewhere. But having somebody have to program up all those menu items just about kills the release cycle of new features. Every time you add a new feature to the compiler you have to change the properties screen, test it, merge it, roll it into the next release. I understand why Microsoft in particular abandoned that idea for .NET where the importance of a PowerShell window really started to come into play. Outside of MS you start to get things like Node.js where you need to run a command line tool to set things up. So it became normalised to want a rich CLI and all the nice things like "more" and "grep" suddenly become more useful again. Which is unfortunate if you are running Windows because suddenly you have to install a pile of 3rd party stuff. And along with it the most uselessly named system in the history of uselessly named things: chocalety. Hey whoever named chocalety, go f*ck yourself. So VSCode is almost back to where I started. It has a bunch of tabs instead of different editor windows, but a lot of the time I'm in a terminal running "code ." and starting another instance of it. The compiler is running in a terminal session within VSCode but you don't have to do things that way and sometimes I don't, I have another terminal open where I do "dotnet start" or "docker run" and just attach to the process rather than using the vscode built-in launch stuff, because I want to drag that output window out nice and long instead of being cramped to 8 lines at the bottom of VSCode. Onion on belt etc. edit: If you really want to know where all the Ctrl-Z, bg, fg etc. stuff came from in the Unix shells, it was programmers who had 10 vi sessions running on a single terminal and were switching around between tasks.

taylodl 5y ago

> I mean, how many different programming language were actually used outside of niche applications in the 80s, maybe even 90s? I started my career in 1985. I've never been a mainframe programmer, but I know back in the day they were using Cobol (still do!), RPG, PL/1, and JCL. On the minicomputer side they were using Fortran, Lisp and C. Microcomputers also adopted C but also added Pascal, Modula-2/3, and of course, Basic. In the late 70's and even early 80's they were still working on the paradigm shift to structured programming. That's table stakes today but yes, there was a time when structured programming was a paradigm shift. Structured programming was all the buzz. And then came those weirdos from Xerox PARC with Smalltalk and talking about "object-oriented programming." Great. Another paradigm shift. Bjarne Stroustrup then had to go and post incrementally improve C to add object-oriented programming to give us C++. So far we've only made it to 1986 and we haven't talked about platforms! The various mainframes, minicomputers and microcomputers and all the different operating systems running on all of them. Since you said "maybe even 90s" then I would remind you that's when Python, Perl, Java, Ruby, and C# all came into being. From my perspective things have slowed down dramatically over the past 10-15 years. We only have 4 major OSs, 2 microprocessor architectures and there haven't been that many new languages: Go, Rust, Julia, Scala, Kotlin, and Clojure (hmm, maybe there have been a few new languages!) You could argue there's another paradigm shift afoot, functional programming, but it's been around since the 80's (!) and hasn't had widespread adoption. Finally, it's far easier to learn today than it was back then pre-widespread internet. You used to have to read periodicals and buy books. There weren't videos, tutorials, and the plethora of training options there are today. Add to it that all the tools you need to get started are free and you're all set! Bottom line - I'd say it's easier than ever to keep up with new developments. The field is moving slower and there's more resources available to keep up with the changes.

jareklupinski 5y ago
I'm just happy we've all settled on a single endian-ness :)

tharne 5y ago

> Yes, I've been surprised too by the sentiment in the article of "it's too hard to keep up with new developments in programming languages" because that is what we all face, be it young or old. What you're ignoring here is that in your 20's and early 30's you have nothing but time. You can spend your evenings and weekends reading O'Reilly books and churning out cool side projects. As you get older, non-work responsibilities increase massively for most people, as you spend time taking care of children, elderly parents, doing small home repairs, etc. Suddenly you can't just drop everything and spend the entire weekend reading documentation and tutorials when $BIG_CORP suddenly decides that all work must henceforth be done in $SEXY_NEW_FRAMEWORK_X.

smackeyacky 5y ago
I agree with the time issue, but we didn't have resources like StackOverflow or reams of personal blogs back then. I find it easier to learn something new now, at least easier to get over that initial learning curve. Proficiency still takes time but it always did.
ChrisLomont 5y ago
>that in your 20's and early 30's you have nothing but time 20's and 30's are where lots of people have time pulled away by kids, not later (median in 2020 was around 28 for kids). And in your 50's and 60's people generally have lots more time as kids move out (28+20=48 = kids gone or at least not such a time sink). If anything, 50's and 60's should be a golden age of learning.
mbrodersen 5y ago
I have worked with plenty of young people who had zero interest in learning anything new. It isn’t an age problem. It is a personality problem.

AnimalMuppet 5y ago

> I mean, how many different programming language were actually used outside of niche applications in the 80s, maybe even 90s? More than a couple, for sure, but if you look at popular languages right now, there's a really long (and not overly thin) tail. First, I think there were a lot of languages then, too. It's just that you haven't heard of them. SNOBOL? JOVIAL? There were 1700 known languages in 1965 (quote at the top of https://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf https://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf). In 1990, say, there was Lisp, FORTRAN, COBOL, BASIC, PL/I, APL, probably still some ALGOL. Then there was the Unix-flavored stuff: C, PERL, awk, sed. There was Pascal, Simula, and Smalltalk. Today I think the picture is similar, except for one thing: web frameworks. If you exclude web frameworks, there aren't that many languages in general use today. C, C++, C#, Java, go, python, Swift. Maybe Clojure, Kotlin, or Scala, depending on how you define "general use". I think that a huge amount of the churn is in web languages and web frameworks. Outside of that, languages aren't moving that fast at all.

deleted 5y ago

[deleted]