I have an announcement...
Javascript is dead!
Okay, now, be honest. How many of you just had a momentary flash of "ooh, crud, so what should I do my project in instead?"
Rest assured: Javascript is not dead. You can keep doing your JS project with no fear. But that one stray statement had an effect. Imagine if the rest of this article had built on that premise. How would people respond?
I've heard some absolutely stunning death proclamations over the past year. Perl is dead! C++ is dead! Java is dead! LAMP is dead! Python is dead!
We have a massive problem in the programming world, and it ain't the platform death rate.
Define "Dead"...
We throw this term around a lot, but I don't think many of us actually understand what "dead" implies. Maybe Mr. Webster can help us.
Deprived of life; -- opposed to alive and living; reduced to that state of a being in which the organs of motion and life have irrevocably ceased to perform their functions; as, a dead tree; a dead man.
I think it's pretty clear what Noah is getting at. Dead is...dead. Not growing, not living, not viable. Nothing's happening. When you're dead, you're worm food.
Maybe it would help to provide a technical example of dead for you...
Visual FoxPro was discontinued in 2007. As of 2015, it has reached end of support. It wouldn't be possible to build and ship a Visual FoxPro project today, no matter how much you wanted to. Visual FoxPro is dead.
[EDIT: I have to retract that obituary too! As Herb Wolfe pointed out in the comments, it is not only possible to develop with FoxPro today, but it has an active community. I even found an open source clone. Surprise, surprise!]
Now, by contrast, let's look at the claim that finally prompted me to write this article. "Ruby on Rails is dead." According to him, except for a few rare fringe users, no one builds anything meaningful with Ruby on Rails anymore. Let's think about this...
- DEV is literally built on Ruby on Rails!
- Rails just released version 5.2.2 on December 4, 2018
- There are 718 open pull requests right now on their official GitHub.
- A literal conference for Rails is slated for Spring 2019 in Minneapolis.
- THE WEBSITE YOU'RE CURRENTLY VIEWING IS BUILT ON RAILS! (It bears repeating.)
Ruby on Rails fails to meet even one criteria of "dead". I could make similar arguments for Perl, C++, Java, Python, LAMP, and so forth.
Even older languages like C, FORTRAN, and COBOL couldn't actually be considered dead. They're still supported on virtually all modern operating systems, and have strong, enduring roles in their respective domains. If you doubt me, walk into a room of Linux developers and shout "C is dead, amirite?" (Pro tip: wear a helmet when you do. It'll protect you from the rocks...although not the derisive laughter.)
Dead...To Me, Anyway
Clearly, the programming community is not using the term "dead" in any sort of sane and reasonable fashion.
When we say "X is dead," we're usually meaning "X isn't popular," meaning in turn that "X isn't the shiniest new thing out there." To me, that makes us sound like a bunch of nattering middle school girls.
"Like, did you see what Cindy is wearing? That dress is, like, so last week. I'm totally not inviting her to my party this weekend."
The problem, of course, is that sort of assessment is based purely on the subjective opinion of the masses. When we parrot that "Ruby on Rails is dead," we're likely citing nothing more than the opinion of some random group of programmers with the attention span of a juvenile golden retriever.
Sometimes, of course, we're not actually basing our "X is dead" assertions on any mass opinion...we're basing it on own own. I've heard so many people individually claim that "C++ is dead," merely because they didn't like the language: manual memory management, pointers, compiling...it gave them hives. And that's fine - they don't have to like the language.
However, as with Ruby on Rails, C++ is very much alive and well - C++17 just rolled out recently. It's also one of my favorite languages. I employ it for use cases that I find it is very well adapted for.
So really, what these people are saying is "C++ is dead...to me. I hate it. I wish it would go away."
Personally, I hate Javascript, and I wish it would go away. But even 20 years from now, if Javascript has fallen out of favor with the masses, I'm probably not going to be writing any articles on how "Javascript is dead," because it won't be!
But honestly, what does it matter if the technology is popular? If it meets the needs of the project, if it enables the developer to solve their problem and ship viable software to their target audience, and if it provides them with a development experience they personally find productive and rewarding, who cares what anyone else's opinion is about it?
What's The Point?
So why does this matter, anyway? If we're all clear on what we mean by "dead," what am I going on about?
It's simple: Words matter! Not everyone is aware of our middle-schooler definition of "dead," nor should we force them to embrace that connotation. "Dead" has a precise, meaningful definition that rightly discourages us from making use of a quantitatively non-viable technology.
Remember at the beginning of the article when I declared that Javascript was dead? You probably (though not definitely) had a brief emotional reaction, even if you knew it was a viable technology. The connection between communication and human psychology is a weird one, but it's very important! Just as you would not choose to hire a graphics designer if you were informed he or she was dead, and just as you would not buy a parrot if you knew it was dead, it just feels inherently wrong to use a technology you've been told is dead. It becomes a mental speed-bump.
In other words, when we call a viable technology "dead" on the basis of popularity or personal opinion, we're actually manipulating others to make a technical decision that conforms to our whims, whether we mean to or not! Even if the other person knows about our popular misinformed connotation of "dead," they'll still have that mental hiccup.
To put that another way, to declare a viable technology as "dead" is to actually put a psychological roadblock in the way of a person picking the best technology for their project. And even if your intentions are good, by doing that, you are literally presuming that you're in a better position to make technical decisions for someone else's project than they are!
The Benefits of Being Unpopular
I've written about fads in programming before, so you may recall when I said...
An innovation only becomes a technology fad when we start mass-adopting it on any basis other than its own merit!
When a technology falls out of mass favor, it settles into a much more stable role in the use cases it is best suited for. It will go from being adopted for reasons of popularity, to being adopted for reasons of suitability. Ongoing development, as well as the technology's community, will become better focused on the technology's strengths, often by merit of ignoring those use cases the technology is not well suited for.
By way of historic example, look at C, FORTRAN, and COBOL. All three were extremely popular in their day, and people attempted to use them for just about anything they could. Later, as their shine wore off, and the masses moved on to glittering new horizons, those languages settled into the uses they were best suited for.
Even today, C is the underpinning of most systems development, providing what is still some of the most reliable "bare-metal" access. FORTRAN is a pillar of scientific computing, trusted by NASA, CERN, and many other organizations for their most critical code. And COBOL is involved in the majority of financial transactions, even today, owing to its speed, portability, and superb mathematical accuracy.
These languages aren't just being coded in by a few has-been fringe developers and acne-ridden enthusiasts. They're real, professionally viable technologies.
Some day in the future, C may give way to Rust, FORTRAN to R, and COBOL to, honestly, nobody knows what right now. The cycle always goes on, and nothing lasts forever.
But in all seriousness, languages don't die very often. Even the much derided Ada lives on, with its most recent stable release coming out in February 2016. The increasing dominance of open source only serves as further insurance that most languages, once established, seldom die.
In thirty years, I'm sure the cool kids will all be mocking the Python, Javascript, Rust, Haskell, Go, and Java developers for sticking to their "dead" languages.
But, honestly, what does it matter whether our tools are popular or not? So long as Phillips screws are sold at my local hardware store, I'll keep using my Phillips screwdriver. In fact, I guarantee that I'll be fixing a brand new, high-end computer thirty years from now, and take out about two dozen Phillips screws.
Yet, no one is writing articles praising Phillips screws anymore (at least, not that I know of,) but that doesn't make any difference. They work.
"Will this fit the needs of my project" is the only question that should matter in choosing technologies!
It's Alive!
Reports of Ruby on Rail's death were greatly exaggerated...along with nearly all similar "X is dead" proclamations.
We have a responsibility to each other, especially to the beginners coming in behind us, to not make each other's jobs harder! You don't have to love every technology out there, but don't confuse your opinion of a language with its viability, and then go confuse another developer as to whether that language is even worth her honest, objective consideration.
That language isn't dead. That language is very much alive, with a community of intelligent developers using it to produce valuable, viable software.
So quit trying to tell us it's an ex-parrot. We're not interested in trading it in for a slug, no matter how shiny it is.
Read more...
Top comments (14)
I very much agree with most of what you have said. The developer community is big and growing everyday, and, what's more important, it's difficult for people to just leave what they were using to embrace a new technology just because it does stuff better. I've seen people running MSDOS applications, which they keep tweaking, just because they decided to create them 30 years ago. People keep designing new games for the Amstrad and, probably, even the MSX machines. In part, anything that's difficult enough is a challenge, and gives you street cred. On the other hand, I found jarring something you said in your article. 700 pull requests is a lot of pull requests. Even if people worry about that particular code, it's kind of clear there's no one on the other side vetting and reviewing those PRs. Those PRs address some particular concerns, mean something is not working (or not working correctly) for someone. Most of those people one stale PR away from abandoning that technology, and moving on to Elixir or Go. At the end of the day, technologies don't die, but they get a bit sick and are finally used in small, and slowly decreasing, niches. If they are not taught in workshops, if there's no vibrant user group, if there are no new tutorials, if the new basic technologies are not embedded in them, well, they will eventually stop being widely used, and they will become the next COBOL.
I've been starting to find that the term 'niches' is a major weasel-word in its own right: it's usually used to claim that the technology is used by "that little group over there," as a way of dismissing its relevance. However, it overlooks the fact that virtually all technologies, once past their fad stage, are best suited for a specific use-case. In other words, all technologies are used in "niches". There are no true one-size-fits-all tools in programming.
Also, COBOL has an active community and user group.
P.S. Just glancing, it looks like some of the older PRs on Rails went stale waiting on the author to do something - fix linter errors, merge a branch, whatever. I've noticed that happens a LOT in open source, and it isn't the fault of the project maintainers. However, the entire first page is all stuff from the past week, so that strikes me as active, but not necessarily unhealthy.
I didn't mean niche to be dismissive. I use it in the biological sense, which is kinda close to use case. All technologies are used in niches, and Nature abhors vacuum, so there's a technology for every use case. However, you can use niche or use case or whatever, and it's true that most technologies slowly abandon the mainstream (or the top 20 in rankings, or reach their plateau in number of users with new users balancing those leaving them) and get stuck to a few use cases. You can probably create reactive web sites and even web services with Cobol, but you're better off doing it with, well, Ruby or Elixir. It's very likely that you can leverage multi-core architectures with C, but you'll most likely use Go or Rust, instead of looking for some library or whatever.
And you are true about the PRs. Most of them are addressed, some of them are waiting for OP action. Still, there are a lot that are simply stale, like this one, three months old github.com/rails/rails/pull/33911. And if you see 700 PRs to be merged, you'll think twice (or more) before submitting your own; many people will simply let it go.
There seem to be ~40 devs active in any one month github.com/rails/rails/pulse/monthly, and the balance of opens/closes and PRs proposed/merged is quite healthy, this month. But still, the balance of open - closed is -40 this month. A t this rate, it might take 17 years to clear the PR backlog. That's not unhealthy per se, but it would be interesting to look at past history, and get the number of PRs and monthly contributors... declining numbers do not mean immediate death, it just means that, for many use cases it was used before (say creation of dynamic websites) lots of programmers have moved on and are using something else (say Vue.js, Elixir, or Sinatra). Contribution sustainability is always a problem for fully-volunteer open source projects, and a bunch of use cases are sometimes not enough to maintain a project, not to mention develop it further.
This is the gist! Well put. It's because we wished all other devs chose our favorite technology
The only real issues about technologies that have moved from popularity to suitability only is finding developers willing to program in such technologies (or even the experts in it).
That's the difference. This point is valid if we were talking about a piece of tech frozen in time but tech isn't. COBOL is slowly becoming a liability in financial companies and banks not because there are no modern versions but because there are not enough people to work on it.
Yes, COBOL is alive and well with a community. But is it big enough to stave off the very real issues that companies have?
I'm going to quote from It’s COBOL all the way down:
and
It's a very nice read :-)
Glad you liked the article.
You make some good counterpoints about COBOL. My thought is, how much of COBOL's lack of continued popularity is due to the language's deficits (there are quite a few, I'll readily admit), and how many are because the majority of programmers are infected with shiny-language syndrome?
In other words, could the lack of COBOL developers be in part due to the regular statement that "COBOL is dead?"
Part of the difficulty in eliminating COBOL from the financial sector is its stability. Given how unstable code is, and how many projects fail dramatically, the financial sector is probably flighty about the idea of porting. They'd be trading speed, stability, and proven mathematical accuracy for what exactly? Maintainability is important, but in mission-critical code, it isn't usually worth the trade-off. Thus, it becomes more practical to find/train COBOL developers to patch the existing systems, rather than build new ones.
Besides that, according to some expert articles I read, so far no languages have really proven themselves equal to COBOL in the financial role. So, we have a language with no apparent successor, and a lot of already-stable code that we don't want to break.
So, I'll ask again: is the problem COBOL, or that we've been discouraging developers from learning it?
P.S. Yes, I'm well aware the language has a painful syntax. That's one of the drawbacks.
I'm too young to know what happened to COBOL but I guess it's both :-) The article I linked talks about the shortcomings of the language itself. I have no idea how recent Cobol dialects are but the GO TO must be hell if used in programs with millions of lines of code
Yep, but they can't keep up with the amount of devs they need in rapport to the amount of code there is.
I think it's both. Devs like shiny things, COBOL isn't anymore :-) It's probably also because the landscape of development isn't the same as in the 60s. Web development didn't exist back then, now web development is a huge chunk of the software development industry.
I'll give you another example. I learned object oriented programming with Object Pascal/Delphi. I loved it, it was a good language BUT they were so concentrated on creating GUI when the world was clearly more interested in developing software for the web. Delphi mostly lacked support over there, people jumped ship. Is Delphi dead? Not at all. But it's not just the fault of people saying "don't bother", of that I'm sure.
Python might be dead in 30 years but its "general purposiness" from day 0 is one the reasons why is still one of the languages that people learn every day, even if it will be 30 years old shortly ;-)
A good, balanced rebuttal (well, half-rebuttal). Thanks for the added insight!
Javascript is great in its original use case, which is creating a small layer of browser side scripting to add some procedural code on top of your already delivered html and css. Huge javascript frameworks like Angular and React are an overcomplicated mess, and javascript is a horrible server side solution. Why in the world would someone want to use javascript over java on a server? You don't want a compiler and strongly typed language to "move your development left"? Node is a complete CF of a solution. Horrible horrible idea taken to its painful extreme. People are using typescript now because they want a more structured javascript?? That is a logical smell to tell you that the decision was bad to begin with.
Actually it is still possible to deploy Visual Foxpro applications today. I use it in my current role, and it still has an active community of users.
Blinks
I...am quite honestly stunned.
HOW do you do that?
EDIT: Jiminy crickets, you weren't kidding. There's even an open source clone. Obituary retracted. (See edit in article.)
With WebAssembly gaining traction, none of these are dead. 😏
No, I've heard it from all sorts of programmers, from many different sectors.
For additional reading, @vnbrs wrote an excellent article on how Ruby is not dead:
The State of Ruby 2019: Is It Dying?
Vinicius Brasil