Five Obituaries for the Languages That Shaped the Web

Perl · Objective-C · Visual Basic · CoffeeScript · Ruby

OBITUARY NO. 1

Perl Is Dead — The Internet Just Hasn’t Noticed Yet

The duct tape of the internet has lost its stick. Once the glue holding the web together, Perl is now the cobweb in the corner of the server room nobody wants to touch.

Picture this: it’s 1999. You’re a sysadmin with a ponytail, a root beer, and an iron grip on the coolest language on the block. You’re writing Perl — the Swiss Army chainsaw of programming languages — and you feel unstoppable. You can parse text, spin up a CGI web form, wrangle a regex so monstrous it would make lesser mortals weep, all before lunch. You are a god.

Now picture 2025. Nobody calls. The job boards don’t list your skillset. Your colleagues look at your code like archaeologists brushing dust off a Roman mosaic — impressed, vaguely, by its age, but absolutely not planning to live in it.

“There’s more than one way to do it.” — Perl’s motto. Also: its death sentence.

The Rise: When Perl Was King

Perl didn’t just arrive on the scene in 1987 — it crashed it. Created by Larry Wall, who holds a genuine linguistics PhD (which explains everything), Perl was designed to be expressive, flexible, and brutally practical. It ate text for breakfast and asked for more. Unix sysadmins adopted it immediately. The early web was practically written in it. CGI scripts, log parsing, report generation — Perl could do all of it with gleeful, chaotic energy.

At its peak, Perl was the third most popular language on the planet. The Comprehensive Perl Archive Network (CPAN) was the largest software library of its kind. Developers spoke of it in reverent tones. Conferences filled auditoriums. Books flew off shelves. Larry Wall received actual fan mail.

The Fall: Python Showed Up and Ruined Everything

Here’s the uncomfortable truth: Perl didn’t get bad. It just got shown up. Python arrived looking clean, readable, and beginner-friendly — the exact opposite of Perl, which had a reputation for write-only code so dense that even its own authors couldn’t decipher it the next morning.

The phrase ‘write-only language’ became Perl’s unofficial nickname, and not affectionately. A Perl regex for parsing email addresses could stretch 50 characters long, dense with sigils, punctuation, and hidden meaning. Python did the same thing in two lines your grandmother could probably guess at.

Perl:    my %count; $count{$_}++ for split /\W+/, lc $text;
Python:  from collections import Counter
         count = Counter(text.lower().split())

Both work. Only one makes you feel like you need a decoder ring to understand it later. By late 2024, Perl had plummeted to #25 on the TIOBE Index — its lowest ranking ever. Python, meanwhile, sat at the top with a market share above 25%.

The Legacy: Dead, But Not Gone

Here’s the tragicomic twist: Perl isn’t technically dead. There are millions of lines of it still running in production, powering systems at banks, telecoms, and biotech firms. Bioinformatics, in particular, still has a quiet Perl heartbeat — the language’s text-processing chops made it a natural fit for genome analysis in the 2000s, and legacy code doesn’t rewrite itself.

Perl 7 was announced in 2020 with great fanfare, promising a modern rebrand. By 2025, the community is still… discussing it. If you squint, there’s something almost poetic about a language that moves slowly in a world that moves fast.

FINAL VERDICT Perl is the programming language equivalent of a legendary rock band still doing reunion tours to half-empty arenas. The hardcore fans are devoted. Everyone else has moved on. Learn it if you’re inheriting a legacy codebase or want to understand history — avoid it if you’re building anything new. The duct tape is brittle now.

OBITUARY NO. 2

Objective-C: Apple Killed Its Own Firstborn

Apple built the cage, trained the bird, then quietly opened the door and released a falcon named Swift. The bird didn’t make it.

There is a specific kind of corporate betrayal that is uniquely Silicon Valley — the moment a company quietly deprecates the very technology it spent decades evangelising. Microsoft did it to Internet Explorer. Adobe did it to Flash. Apple did it to Objective-C. Slowly, lovingly, with a smile on its face and a WWDC keynote in its hand.

The difference is, Objective-C actually deserved it. And deep down, it knew it.

“[objectWithMessage:sendingIt:likeThis:]” — Objective-C method syntax. Yes, it’s as painful as it looks. Yes, this is genuinely how you write it.

The Language That Time Forgot to Modernise

Objective-C was born in 1984 — the same year Apple launched the original Macintosh with that iconic Super Bowl ad. It was a hybrid: C at the core, wrapped in a layer of Smalltalk-inspired object-orientation that felt genuinely innovative for the era. When Apple adopted it as the primary language for macOS and later iOS, Objective-C became the language of the most valuable platform on earth.

For 30 years, every iPhone app, every Mac utility, every piece of software bearing that gleaming apple logo was almost certainly written in Objective-C. Millions of developers learned it. Entire careers were built on it. It was unavoidable if you wanted to play in Apple’s garden.

The problem? It also looked and felt like it was designed in 1984. Because it was.

Objective-C:  NSString *greeting = [NSString stringWithFormat:@"Hello, %@!", name];
              NSLog(@"%@", greeting);

Swift:        let greeting = "Hello, \(name)!"
              print(greeting)

Swift Arrives: A Beautiful Assassin

At WWDC 2014, Chris Lattner walked on stage and announced Swift. He called it ‘Objective-C without the C.’ The room went wild. Developers who had spent years squinting at bracket-heavy syntax and manual memory management felt something stir inside them — hope, relief, and a slight pang of guilt for feeling those things about a language that had served them so faithfully.

Swift was clean. Swift was fast. Swift had type inference, optionals, and closures that didn’t make you want to quit the industry. Within a year, it topped the ‘most loved language’ lists on Stack Overflow. Apple made its intentions unmistakably clear: new APIs were Swift-first. New documentation was Swift-first. New everything was Swift-first.

By 2025, over 90% of new iOS apps are built in Swift. Objective-C persists in legacy codebases the way Latin persists in legal documents — technically present, mostly ignored, occasionally feared.

The Long Goodbye

Objective-C hasn’t been formally killed — Apple is too polite for that, and too pragmatic. There are billions of lines of Objective-C code running in production across millions of apps, and the Swift runtime is still interoperable with it. You can mix and match. Legacy codebases aren’t going anywhere soon.

But the writing is carved into the wall in 72-point Helvetica Neue: new developers aren’t learning Objective-C. Companies aren’t hiring for it. Job postings list it the way vintage shops list ‘vintage’ — as a curiosity, not a requirement. The ecosystem is in hospice, not quite dead, but no longer fighting.

FINAL VERDICT Objective-C is the programming language equivalent of a loyal deputy who served for decades only to watch the new sheriff ride in and take the badge. There’s no drama, no firing — just a slow, dignified exit. Unless you’re maintaining legacy code, don’t learn it. Swift does everything it does, better, with fewer brackets and zero nostalgia required.

OBITUARY NO. 3

Visual Basic: Microsoft’s Forgotten Middle Child

VB made programming accessible to millions. Then Microsoft said ‘thanks, we’ve got C#’ and quietly changed the locks.

If programming languages were children, Visual Basic would be the middle kid. Not ignored exactly — not rejected — just consistently, systematically overlooked in favour of the shinier siblings. C++ got the respect. C# got the investment. And VB got a passive-aggressive memo from Microsoft in 2020 that essentially read: ‘We love you. We’re just not going to update you anymore. Please sit quietly in the corner.’

The memo — a real blog post titled ‘Visual Basic’s Future’ — confirmed what the developer community had suspected for years. Microsoft would stop adding new language features to VB.NET. It would be maintained, barely, but left to fossilise in peace while C# sprinted forward into records, pattern matching, and nullable reference types.

VB was the language that taught a generation that coding didn’t have to be terrifying. That was both its greatest gift and its ultimate curse.

The Democratisation of Code

Visual Basic 1.0 landed in 1991 with a genuinely radical proposition: you could build a Windows application with actual buttons, windows, and menus by dragging and dropping components and writing minimal code. No memory management. No arcane compiler flags. No pointer arithmetic. Just drag a button onto a form, double-click it, and type what you wanted to happen.

For millions of people — accountants, small business owners, science teachers, hobby tinkerers — VB was the first time programming felt possible. VB6, released in 1998, was arguably the pinnacle: a development environment so approachable that an entire cottage industry of VB tutorials, books, and forums sprang up. By some estimates, there were more VB developers in the late 1990s than any other language.

VB.NET and the Identity Crisis

When .NET launched in 2002, Microsoft ported VB to the new platform. VB.NET was technically superior to VB6 — proper object-orientation, better memory management, a genuine future in the .NET ecosystem. But something got lost in translation. The simplicity that made VB6 magical became muddied. The syntax changed enough to break compatibility with millions of lines of existing code, which infuriated the community.

Developers who had sworn by VB started drifting toward C#. And C# was ruthlessly good. Designed by Anders Hejlsberg with the ambition of combining Java’s safety with C++’s power, it matured quickly into one of the finest general-purpose languages in existence. New features arrived in C# first — often years before arriving in VB.NET, if at all. In 2025, VB.NET receives no new language features whatsoever.

VB.NET:  Dim message As String = "I am not dead yet"
         Console.WriteLine(message)

C#:      var message = "I am very much alive";
         Console.WriteLine(message);

The Ghost in the Enterprise Machine

The darkly funny part? VB isn’t actually gone. Somewhere right now, a municipal government or a mid-size insurance company is running critical business logic in VB6 or VB.NET. Not because it’s good, but because the cost and risk of rewriting it is enormous, the developers who built it retired in 2011, and the system works fine — technically — if you don’t look at it too hard or ask it to interact with anything built after Obama’s first term.

These codebases are the Miss Havishams of software: frozen in time, still wearing the wedding dress, clocks stopped at the moment Microsoft turned away. They will outlive us all, and we should probably be afraid of that.

FINAL VERDICT Visual Basic deserves more credit than it gets for opening the door to programming for a generation. But that legacy is historical, not practical. VB.NET is a dead end with a polite maintenance contract. If you’re in the .NET world, C# is the only sensible choice. If you’re maintaining old VB code — godspeed. You’re doing important, invisible work that keeps the world running.

OBITUARY NO. 4

CoffeeScript: The Hype Cycle Had a Name, and It Was Delicious

It arrived like a rockstar. It left like a rockstar’s side project — enthusiastically received, quickly shelved, quietly forgotten somewhere between two TypeScript releases.

There is a very particular kind of technology death — the death of the language that was right about the problem but wrong about the solution. CoffeeScript saw JavaScript’s ugliness clearly. It diagnosed the patient correctly. Then TypeScript walked in with an actual prescription while CoffeeScript was still arguing about the symptoms.

CoffeeScript’s entire pitch was this: JavaScript is verbose, syntactically noisy, and frankly embarrassing. What if we transpiled a cleaner language into JavaScript under the hood, so you could write beautiful code without suffering the original? It was a compelling argument in 2009. A less compelling one in 2015. By 2024, npm downloads had collapsed by 78% in a single year. The coffee had gone cold.

CoffeeScript didn’t just ride the hype cycle — it was the hype cycle. Meteoric rise, ecstatic peak, brutal plateau, and a descent so quiet you barely noticed it was gone.

The Golden Years: When Coffee Was Cool

Jeremy Ashkenas released CoffeeScript in 2009, and for a moment — a genuinely exciting moment — it felt like the future. The syntax was borrowed liberally from Ruby and Python: no curly braces, no semicolons, significant whitespace, and an expressiveness that made JavaScript look like a bureaucratic form by comparison.

GitHub’s internal tools used it. Rails adopted it as the default JavaScript preprocessor. Prominent developers championed it loudly and publicly. In 2012, CoffeeScript was the second most popular language on GitHub. That sentence needs to sit with you for a moment. Second. On GitHub. In 2012.

It was also the first mainstream example of ‘transpiling’ — writing in one language, outputting another — an idea so ahead of its time that it became the dominant paradigm of modern frontend development. The entire ecosystem of Babel, JSX, and TypeScript exists partly because CoffeeScript showed the world it could work.

How TypeScript Ate Its Lunch, Dinner, and Breakfast

CoffeeScript’s undoing came from two directions simultaneously. First, JavaScript itself caught up. ES2015 brought classes, arrow functions, destructuring, and template literals — nearly every CoffeeScript feature that had made it attractive was absorbed directly into vanilla JavaScript. Why use a transpiler when the original language now did the same thing?

Second, and more decisively, TypeScript arrived from Microsoft and addressed something CoffeeScript never could: type safety. CoffeeScript made JavaScript prettier. TypeScript made it safer. For large teams building complex applications, safety beats aesthetics every time. TypeScript is now used by 69% of professional developers. CoffeeScript is a footnote.

CoffeeScript:  class Developer
                 constructor: (@name) ->
                 greet: -> "Hello, I'm #{@name}"

TypeScript:    class Developer {
                 constructor(private name: string) {}
                 greet(): string { return `Hello, I'm ${this.name}`; }
               }

The Honest Eulogy

Here’s what CoffeeScript genuinely deserves credit for: it proved the concept. It showed the industry that you could write in one language, output another, and make the developer experience dramatically better in the process. The tools that killed it — Babel, TypeScript, the entire modern build pipeline — are children of the idea CoffeeScript pioneered.

There’s a version of this story where CoffeeScript is the tragic hero. Right idea, wrong decade. It planted the seed and never got to eat the fruit. The open-source community ran away with its best insight and built something larger and safer than CoffeeScript ever could have become. It won by losing.

FINAL VERDICT If you’re writing CoffeeScript in 2025, migrate to TypeScript — it does everything CoffeeScript promised and adds type safety, IDE support, and a thriving ecosystem. The coffee’s gone cold. Time to switch drinks.

OBITUARY NO. 5

Ruby: The Beautiful Language Nobody’s Hiring For

Ruby optimised for developer happiness. The market, it turns out, optimises for something else entirely — and it will pay you handsomely for Go.

Yukihiro ‘Matz’ Matsumoto designed Ruby around a single, radical principle: the language should make programmers happy. Not fast. Not safe. Not scalable. Happy. In 1995, this was a revolutionary idea. In 2025, it is a delightful artefact of a more innocent era, like artisan pickles or a business card printed on wood.

Ruby is still beautiful. Ruby is still expressive. Ruby is still — if you spend time with it — a genuine joy to write. And Ruby jobs fell 36% between 2021 and 2024, because the market does not pay salaries for happiness. It pays salaries for throughput.

“Ruby is designed to make programmers happy.” — Matz, 1995. “We’re migrating to Go.” — Twitter, GitHub, and Airbnb, 2013–2018.

The Rails Era: When Ruby Ruled the Web

Ruby’s defining moment wasn’t the language itself — it was Ruby on Rails, the web framework David Heinemeier Hansson unleashed in 2004. Rails made building web applications genuinely fast: convention over configuration, sensible defaults, and a degree of ‘magic’ that let small teams ship products at speeds previously requiring armies of Java developers and a consultant from Accenture.

The early 2000s startup ecosystem was essentially built on Rails. Twitter, GitHub, Shopify, Airbnb, Basecamp, Hulu — the list of companies that launched on Rails reads like a roll call of the defining internet businesses of the 2010s. Rails evangelism was a personality type. DHH was a folk hero. Being a Rails developer was, briefly, the single coolest thing you could be in software.

The Scale Problem That Would Not Go Away

Here’s where the happiness metaphor breaks down: happiness doesn’t scale. Ruby is interpreted, dynamically typed, and the Global Interpreter Lock in the standard MRI implementation means it cannot truly run parallel threads. At low traffic volumes, this doesn’t matter. At Twitter-level traffic volumes, it absolutely does.

Twitter’s infamous ‘fail whale’ — the error page that appeared when the service buckled under load — became a cultural meme, and Ruby took much of the blame (fairly or not). Twitter rewrote its critical infrastructure in Scala and later Rust. GitHub rewrote performance-critical components in Go. The pattern repeated across the industry: start with Rails, scale the product, hit a wall, reach for something compiled.

Ruby:  users.select(&:active?).map(&:email).each do |email|
         send_newsletter(email)
       end

Go:    for _, user := range users {
         if user.Active { sendNewsletter(user.Email) }
       }

Ruby reads like prose. Go reads like a specification. At 10 million requests per hour, the market votes for the specification.

The Tragicomedy of Shopify

The most interesting Ruby story in 2025 is Shopify, which has done the opposite of everyone else: doubled down. While the industry fled, Shopify invested heavily in Ruby performance improvements, hired core Ruby contributors, and became the unofficial patron saint of the language. Their engineers have done remarkable work — Ruby 3.x is dramatically faster than the Ruby that powered early Twitter.

It is, against all odds, a love story. Shopify loves Ruby, Ruby loves Shopify, and together they are proof that a language doesn’t have to win the market to remain vital. But it does have to win someone’s market, and beyond Shopify’s benevolent stewardship, that market is narrowing year by year.

The community is not without hope. Frameworks like Hanami offer modern architectural patterns. The language itself is genuinely evolving. But the job market is a cold mirror: postings are down, salaries are plateauing relative to Go and TypeScript, and the flow of new developers into the ecosystem has slowed to a trickle.

FINAL VERDICT Ruby is not dead, and it is not without a future — Shopify alone ensures that. But for most developers making career choices today, the trajectory is clear. Ruby is the language for small teams who value elegance over scale, or for those lucky enough to join one of the companies still committed to it. Beautiful, diminishing, and worth respecting for what it gave the industry: the idea that code could be a joy to write, not just a job to do.