Hacker News Reader

Comment by hyperpape | Hacker News Reader

Every so often, I think about the meme of the 100 year language. The idea is that we need to start working towards the languages we'll use in 100 years. Instead, I wonder how many we already have.

Fortan: 59

C: 43

C++: 33

Python: 25

Php: 21

Javascript: 20

Java: 20

It's still a long time until any of those languages reach 100. But longevity seems to be the rule, not the exception. How many languages that were widespread actually died?[0] I don't pretend to know all the languages that have ever been popular, but not many that subsequently died come to mind. Cobol, maybe some lisp dialects, if you don't count Common Lisp as their successor? Is PL/1 dead? Was APL big enough to make the list?

Probably some of the languages I listed above will die before they're 100. Others might be niche, like Fortran already is. But I wouldn't guarantee it.

[0] Where dead doesn't rule out someone being paid to maintain ancient code. By that standard, it's unclear whether anything will ever die (https://www.snellman.net/blog/archive/2015-09-01-the-most-ob...)

View on HN

COBOL is 57 years old, has billions of lines running, and new code is constantly developed. Should be on list.

LISP is widespread in education as Scheme, has lasting commercial deployments/companies with LispWorks and Franz Allegro, and new community with Clojure. However, one might treat them as separate languages given LISP 1.0 is very different from Common LISP which isn't Scheme or Clojure. So, it's up for debate but Scheme at 47 years old is probably justifiable due to academics. Racket is practical version with strong community. Chicken Scheme had one last I checked, too.

PL/1 (53 years old) is dead outside of legacy systems including mainframes and eComStation (OS/2). Yet, might be worth adding given that it has new code added to extend old systems like COBOL does. New compilers updates happen as well like below. Hard to say it's dead if it's still running companies, getting extended, and getting tooling updates. Just not popular.

http://www.iron-spring.com/readme_linux.html

Also, Burrough's MCP is still around under Unisys banner. It was first OS written in high-level, safer language: Burrough's ALGOL (56 years old). Became ESPOL (48yrs old) and NEWP (???). Unisys has a 2015 dated doc on NEWP. I think that means they converted most or all of the OS to it.

BASIC (52 yr old) was a language designed for beginners. Since it looked like pseudo-code, it was ridiculously easy to read and write. I got started on VB incidentally. Many spinoffs with wide deployments of commercial BASIC's for business, gaming, and education show it's far from dead. Not to mention 4GL's that were often BASIC-like. Could actually be one of the most widely, built-on languages ever made.

https://en.wikipedia.org/wiki/List_of_BASIC_dialects

So, there's more for your list.

EDIT to add BASIC in there.

FORTRAN isn't the same language either. Much like LISP, it evolved over time. Things like line numbers and GOTO statements that made people hate the language are not really mandatory -- it is basically as structured as C these days.

It's been evolving a lot. They're at least honest about that as they put the year after the Fortran type.

Obligatory and relevant Hoare quote:

“I don't know what the language of the year 2000 will look like, but I know it will be called Fortran.” —Tony Hoare, winner of the 1980 Turing Award, in 1982.

Given how things turned out, he might have better said:

"I don't know what the language of the future will be called, but I know it will look like C."

In some ways Fortran is more advanced than C and even C++, e.g. had modules since Fortran 90, pure functions and so on ...

It is a very different language from the original Fortran.

Regarding LISP, perhaps the perspective that does count LISP and its descendants as one ongoing evolution of a similar language family is the same perspective that will allow that lineage to last 100 years?

I feel that the systems that change over time have the best chance of weathering it.

It could. That might normally be considered cheating but LISP is actually designed with philosophy of customizing language itself to problem domain. Thing is, the implementations and even language features of modern LISP's are nothing like McCarthy's simplistic language and interpreter. They couldn't succeed being that due to performance and usability issues.

So, I think it's more fair to talk about LISP languages as an ongoing family but still a cheat to treat a modern one as original LISP. Probably should date it from creation of dialect or similar one.

Certainly, but the borders aren't so obvious to me. Is any language going to last 100 years without changing so much it feels 'nothing like' it's origin point?

Even if it hasn't changed in name, it may have changed in spirit. Some languages that promote themselves under very different names are substantially more similar than other cases where new language versions are dramatically different.

What 'essence' makes it the 'same language'? An interesting problem.

COBOL or Pascal if you don't use modern features lol. Idk. It's an interesting question about how we count the changes against the language's lineage. I don't have an answer to that one. We need a debate about it on StackOverflow that moderators close as "not constructive." Those are the threads that usually have great insights into issues like this haha.

1960s Lisp code can still run on Common Lisp with only minimal changes -- e.g. http://elizagen.org/. A reboot like Racket or Clojure has more chance of making it alive to 2060, but I wouldn't quite rule out early Lisp yet.

Thanks for mentioning algol and cobol! Its easy to forget these languages since they are mostly used on mainframes.

Algol used to be language you submitted things to the ACM in I think and is the systems programming language of the MCP, which my dad still programs in to this day!

It is interesting how many languages had an algol style syntax until C stole the show. I am not sure the world is better for it.

"is the systems programming language of the MCP, which my dad still programs in to this day!"

That's pretty neat. Everyone thinks Burroughs died but they just changed names. Make crazy money. System is quite dated, though, in features and interface. No denying that. ;)

"It is interesting how many languages had an algol style syntax until C stole the show. I am not sure the world is better for it."

I'm not sure on syntax. Decisions by top languages in terms of safety or reliability show ALGOL and Pascal families were right about those. You might like to look at Modula-3 and Component Pascal to see where things might have gone in a parallel universe.

https://en.wikipedia.org/wiki/Modula-3

http://blackboxframework.org/index.php?cID=why-program-in-co...

Note how power, yet simple, Component Pascal is by looking at the full language grammar in two pages of Wikipedia:

https://en.wikipedia.org/wiki/Component_Pascal

"However, one might treat them as separate languages given LISP 1.0 is very different from Common LISP which isn't Scheme or Clojure."

Well, on the one hand that's true. But on the other hand, a lot of the living languages have that too. BASIC is 52 years old, sure, but no 52-year-old BASIC program would even compile in a modern BASIC, and I mean, it's not even close, not like a couple keywords or some chars here or there, but the entire structure of the language is fundamentally different now.

By that standard: C is still recognizably the same. I'd suggest C++ is a different language before and after templates, which cuts it down to 27 years, and if you wait for the STL to be usable before you say they "took", less than that, but I imagine a lot of the early C++ would still compile or nearly so. Python has smoothly evolved and I can't point to any one feature that was a hard transition, but it is a fairly different language today than it was in the 1-1.5.2 era, but a lot of the 1.5.2 would still run OK. Javascript has actually been relatively stable as a language, coming out of the gate with rather a lot of stuff already built in. Java has also been pretty stable as a language. I don't know enough about Fortran or COBOL.

Lisp is an amusing case where a lot of old Lisp is probably reasonably close to parseable but probably doesn't run at all beyond the basics.

I fully acknowledge there's some subjectivity to the judgments here, but I think part of the 100-year-language idea is that code in the 100 years language should still be usable 100 years later, directly. By that age measure we're shorter on viable languages, though we still have some.

I agree with all of this except maybe C. I don't have time to evaluate that in detail so no opinion. I especially like your definition of what constitutes 100 year old code or language. I think we can compromise between two definitions by differentiating between how old a language family/style is vs a specific variant or implementation of it. The LISP family and style is decades old but supported implementations are much younger.

early C++ compiling wouldn't be the problem you wouldn't uncover...

I worked on a large early C++ project and we had problems on the scale of a couple of years. Even if C++ wasn't changing, the compilers were.

Java is interesting because it's always prioritized backwards compatibility, but the changes that have shown up recently or are in progress are pretty big: lambdas, value objects and type inference can all be argued to go against some important aspect of how the language was originally conceived.

You might argue it's changed the least, but only because all languages change a great deal.

"C is still recognizably the same."

I wouldn't state that so categorically:

    foo(x)
    {
        return x+x;
    }

    bar(x)
    float x;
    {
        return x+x;
    }

If you didn't live when that was C, I'm not sure you would recognize it as such. Certainly, I could claim it was B, C's precursor and get away with it with quite a few people. It doesn't look that different from the example at https://en.m.wikipedia.org/wiki/B_(programming_language)#Exa...:

    printn(n, b) {
        extrn putchar;
        auto a;

        if (a = n / b)
            printn(a, b); /* recursive */
        putchar(n % b + '0');
    }

"...Python has smoothly evolved..." Well, not exactly.

You can say that of any language. Today's javascript has little to do with the pop-up opening nuisances of the 90s (even if it still also does that!).

And even today's Visual Basic has gone a long way from the VB6 that most people remember VB by.

"a lot of old Lisp is probably reasonably close to parseable"

I think you would be hard-pressed to find any old Lisp code that a modern READ cannot turn into a list which could trivially be transformed into a valid s-expr in that dialect.

The reverse is much less true, since modern Lisp-like languages allow many more characters, are often case-independent, and often have standard "decorations" (e.g. &REST or #:optional).

Common Lisp is so kitchen-sinky that you'd be hard pressed to find old Lisp code that was then reasonably portable that will be outright hard to port to a modern CL implementation. Most of it will probably run as-is, or with a thin macro package doing mechanical translations.

Unportable code is unportable code. If it was so tied to e.g. Allegro that it wouldn't run in any other CL environment, that's hardly the language's fault.

However, really early Lisp stressed the "S" part, and rarely did anything strongly system-specific.

There are some variants of Lisp which are not trivial to port to Common Lisp. Something like Standard Lisp is slightly difficult due to various reasons. Somehing like Interlisp is also difficult, because much of its functions and libraries work quite different from Maclisp/Common Lisp.

Ha, good list. Never worked on it, but I've read that the Pick environment (OS + language + DB ...) is still used. It's quite old, ~50 years, according to:

https://en.wikipedia.org/wiki/Pick_operating_system

The more I think about it, the less I'm sure certain languages like Java will ever die. Java is a really good language for systems of mind-boggling size, and just as it's easy to write, it's also easy to manage and measure people writing it. Java strikes a good balance between extensibility (easy to implement design patterns; cross-platform JVM) and safety (auto garbage collector; no memory access).

Even if technology did rapidly change (nanomachines!) there would still be a business case for a Java-style language. Given how used to C syntaxes we are, it might end up looking like Java. Or Java might just be here to stay, for a long, long time.

Side note: a lot of "dead" languages nowadays are ones that were written before memory and processing power were abundant so they had a lot of (what we in the glorious future might call) arbitrary character limits.

sp(a,b); might have been sufficient back in the slow-old days, but we don't really consider character limits anymore, and so we can actually learn what a given line of code does by reading it.

SubmitPostOnHackerNews(commentID,messageText);

> just as it's easy to write, it's also easy to manage and measure people writing it

I think you nailed why I don't care for writing Java perfectly.

You'd be the first person to write Java perfectly! #grammaticalambiguityforthewin

The problem with Java systems of mind-boggling size is that their mind-boggling size is usually caused by them being written in Java (and not the other way around).

As for design patterns, the patterns that are really extensively used have more to do with overcoming the limitations of Java (or C++, C#, or whatever similar language) than with expressing anything profound.

Except people tend to forget those mind-boggling systems used to be written in C, C++ and Smalltalk before Java was a thing.

Anyone that hates JEE, should spend some time having fun with CORBA or DCOM and see which one s/he likes best.

CORBA. Oogh. You would bring that up.

Oh it's worse. Not sure why but the high-assurance security field relied on high-security ORB's for connecting components in separation kernel systems. I was like, "Can't we use ZeroMQ or something? What are the odds that could be more fu... insecure than CORBA implementations?" Unreal.

On the other hand, the litigious environment around Java thanks to Oracle makes it a more risky ecosystem, for reasons that have nothing to do with language design. There is definitely room in this world for languages with more benign stewards.

Pascal is a good example of a dead language that used to be fairly popular.

Good call.

Maybe a good call, maybe not. Embarcadero or whatever spelling haha keeps Delphi alive for businesses with old and new code written. Community mostly forked into Free Pascal with lots of libraries, example code, and active compiler development. Component Pascal was a C++ competitor with many companies and people in Europe and Russia using it. Mainly thanks to Blackbox Component Builder which was a Component Pascal app and BSD'd.

So, it doesn't seem quite dead.

Still pretty alive

http://www.mikroe.com/mikropascal/

Did you miss the FP/Lazarus resurgence recently? The forums are active, they made a nice introductory video, it's cross-platform...since I think we're talking "really dead" here, I doubt it qualifies.

A month ago I would have agreed with you. But then I surprised myself by choosing the Free Pascal Compiler and the Lazarus IDE for some personal projects that need to be native Windows applications.

These projects have been in my queue for years because I kept chasing the "best" way to create Windows applications. I learned (and forgot) a lot of crap, but never actually made anything. Now I'm making stuff.

Join us: http://www.lazarus-ide.org/

Pascal isn't dead! Native binaries produced (much less garbage overhead), fast compilation, kick-ass open source IDE and standard library, cross platform, free (as in freedom, as well as beer).

JOIN US.

Wow, I stand corrected. Lazarus is a great name though since it calls out the fact that Pascal was dead ;)

That was a great burn. I'm going to reuse it if they get cocky in the future. :)

Yes, it was dead. Now though... please try it. You'll be impressed.

Pascal is not dead. Lots of Windows applications have been written in Delphi (Object Pascal), and these will require maintenance. Or a rewrite in C#.

Calling Fortran 59 years old is odd, as not many people write in the original form of fortran. C11 is much closer to K&R C than Fortran 08 is to the original Fortran.

I'll throw two domain specific language (families) into the mix, that are psuedo-dead although not really dead.

Although amstex and latex are healthy (and latex is about 40 years old) I would argue that very few indeed are writing in raw bare macro-free package-free tex, just bare totally raw tex. I'm sure it happens... rarely.

Another psuedo-dead is postscript. In the 80s there was a famous EE pushing the idea of sending your code and data to your postscript laserprinter as a batch frontend sorta and let the laserprinter interpret the postscript and do the calculations for your smith chart, not merely print your bitmap containing a smith chart or whatever. That idea of postscript as a general purpose application language, although infinitely cool, never went much of anywhere.

And of course, there is PSTricks, which combines them both, letting you solve ODEs in your document: https://www.ctan.org/tex-archive/graphics/pstricks/contrib/p...

BASIC - everyone's abandoned it.

PROLOG - such a great idea, never really caught on. Yeah yeah I know minikanren and clojure core.logic but realize its gone from "The Japanese are using it to leap ahead of American AI research so we gotta catch up" in the late 80s to "whats that?" today.

To eliminate some battles over the definition of the word dead, how about "without too much effort you can get a paying job writing it". That works pretty well for spoken languages too.

That helps with Assembly. As a fraction of the pie its never been lower. As a device driver, embedded, firmware, compiler optimization (does that count?), and boot loader type of technology there's probably never in human history been more lines written per year. So its both dead and thriving by some definitions, but by my definition above its hardly dead.

> PROLOG - such a great idea

I don't really get the appeal of basing a whole language on a backtracking algorithm. It always seemed to me that constraint solvers are better suited to a library implementation.

There are a lot of people still writing BASIC code. PureBasic, QB64, FreeBASIC, etc. Check out how active those communities are. Has everyone _really_ abandoned it? The bar for dead is just that: Dead.

> maybe some lisp dialects, if you don't count Common Lisp as their successor?

In that case Dennis Ritchie's K&R C is dead, if you don't count C11 as its successor.

If/when Python 2.7 dies out, Python's age can then be measured back to Python 3.

Etc.

COBOL is anything but dead (unfortunately).

Are there really that many new projects in COBOL, or is it almost all maintenance/extension of existing code? That's where I'd put the cutoff.

Gartner puts it at 5 million lines a year:

http://blog.insight.com/2010/10/cobol-still-in-action/

They write as much as they can outside COBOL. Those 5 million lines are for extending old programs or integrating new things into them. Some new programs are presumably written as well since... well, it's COBOL programmers writing them. ;)

5 million lines really isn't that much in the grand scheme of things.

It's not a lot. Yet, it's extra code extending critical apps with billions of lines of code and running more transactions than Google does searches. That's a large impact in the grand scheme of things.

Also, how much C was being written in UNIX 1.0 days outside of ports of same, exact software? :P

I believe the company I work for is writing just under 500K lines of COBOL code per year... now... how much of that is "new" vs extending vs maintaining is a good question. It is very difficult to measure those things in our environment. If you were to ask the 60 - 75 mainframe programmers we employ, I'm sure they would answer that COBOL is very much alive, and no matter how hard you try to kill it, 40 years of system code is just not going away any time soon (depending on your definition of "dead"). Especially as we hire a good amount of "new to us" people to maintain the system.

I think individual companies should define a language as "dead" based on the number of new people needed to maintain the systems. As the number approaches less than 5%(?) of your replacement hires, have you effectively "killed" the language? At the very least it is on life support, and a decision needs to be made about its future. (A grim analogy, I know).

Well, are we talking dead or just obsolete? It can't be dead if it's actively being developed with significant amounts of money and tooling improvements (eg MicroFocus). It can be obsolete, though, if it's taking up a tiny percentage of new code or hires as you said that keeps going down.

I agree one should try to phase out something on life support. Gradually at the least.

I am about to start a new project with a company where COBOL is still very much a force. COBOL is far from dead and there are very serious applications using COBOL in mainstream use.

You left out Erlang, which has just turned 30.

I also left out Perl, which may be losing mindshare, but is definitely not dead, Ruby, C#, and so on.

I chose these languages because they occurred to me as being relatively old and relatively common, but I won't argue that there aren't any other languages that could be on the list.

>but not many that subsequently died come to mind. Cobol,

I've read (not heard) it said that there may be more lines of COBOL in existence (probably meaning still running) than lines of any other language. Biz, insurance, gov't, IBM, etc. ...

FORTRAN and C are probably close seconds (relatively speaking).

A friend of mine mentioned that they hired a COBOl guy last month. They needed someone to work on the COBOL side of things because they are doing a big rewrite. (The legacy COBOL code outlived the stuff that was supposed to eventually replace it)

> The idea is that we need to start working towards the languages we'll use in 100 years.

IF we'll still be programming in 100 years, let alone using languages, instead of just telling an A.I. what to make. :)

We already don't use a lot of tech that we used to, because automated tools do it for us now. Assembly language is a relevant example right there.

Or an A.I. telling us what to make.

Reply on news.ycombinator.com