I think Pascal's sun set because Borland killed it with Delphi.
In my opinion, Borland was the 300lbs gorilla in the Pascal compiler arena, so when Borland decided to move push Delphi over Pascal, there was no interest in filling the Pascal hole.
btw I wrote commercial products on Pascal that I thought was neat. A chat program that used IPX/SPX, a a fax server using DesqView, and MS Mail queues both inbound and outbound, reverse delta databases that stored all changes at field level, overcame the 640K memory barrier by using a TSR that swapped the data in/out on demand, and a proto-PXE server using my insanely fast copy program over IPX. That was the good old times.
> Pascal was the introductory computer language at my college in 1988. I don't remember much of it.
I took Pascal as a college freshman in 1982. And even though I haven't programmed in it seriously since then, it stuck with me. It didn't hurt that it was a minimal language designed for teaching computer science. For example, when I learned Pascal, there was no string type; you had to create an array of characters.
I was checking out the Free Pascal website recently; although the language has been greatly expanded, Free Pascal source code still made sense to me.
Learning Standard ML made me a better programmer (back in the day)... It was all about specifying how input and results are related instead of giving instructions to the CPU on what to do.
When I was first exposed to C (perhaps in Byte Magazine), I was dead certain that Pascal would win out. I wonder if the minor optimizations achieved by programming closer to bare iron on early computers led to a minor performance advantage that outweighed the need for readable / maintainable code.
C did compile to more efficient code than Pascal, but The Delphi compiler processed code 10x faster than the C compiler, and hit an amazing sweet spot for the 300Mhz workstations of the day, where you could iterate through edit/compile/run in Delphi just as fast as Visual Basic, and when you were done the program ran an order of magnitude faster than VB (and maybe 90% as fast as C). Also, because the language was easier to parse, the tooling was able to interact with your code way better than Borland's same product for C++ or any of Microsoft's products, so you were getting more accurate code completion and context-sensitive help and all that.
I believe that Delphi was a vastly superior product to any of its contemporaries, and was killed purely by corporate forces.
C and Pascal were both fast, but C allowed programmers to dynamically allocate and free memory without having to deal with 255 character limits and other limitations imposed by Pascal. It also allowed us to create some magnificent bugs, too.
My sense was Delphi was replaced more by Visual Basic, though it's entirely possible that's based on my personal experience and didn't represent a larger trend.
Turbo Pascal was popular because it was cheap at a time when buying a compiler could cost hundreds of dollars. But it really never got picked up widely beyond Borland products. BASIC options got a bit better. And, yes, C and Java were popular for "serious" programming.
Pascal graduated to Delphi (Object-pascal with built-in GUI designer), and had a very healthy run for a decade and was my favorite language until Borland corporate stuff happened and a cross-licensing deal with Microsoft that turned Delphi into a sort of bastard sibling of .NET, and new owner Embercadero raised prices out of the reach of most of the small-time users that made up a bulk of the userbase. I was in a tiny factory-automation engineering group that used it to build user interfaces and data reporting for all the factory stations. Well, on that note, 3M corporate shut down the factory and moved it to China, so maybe other forces were in play to kill the userbase.
In my youth, I learned basic then Pascal before taking compsci in high school. Despite the fact that I was confident in both, your course supported both languages, but by far the "not a programmer" types chose VB and that was their speed and it's was fine. For those of us that really enjoyed programming, we learned and loved Pascal/Delphi more, but I'd argue most of us transitioned to C/java afterwards. Delphi took a middle ground approach that wasn't entirely successful to either of these groups.
I still think the biggest mistake MS made with their tooling was burying VB6+ and replaced it with VB.net. They may have made VB a "real" function extensive language, but I think a bunch of soft-programming people just left and never went back. C# ate any of those that would've used VB.net in this way anyways IMHO.
The BASIC cause of death is written that it was seen as a lesser, kids language.
That sentiment may be true to some extent, but fails to mention all of the problems of the BASIC language that made people look into alternatives, none of which were snobbiness.
If that were a real reason, Python would have suffered a similar fate.
BASIC was very practical for 8 bit machines. You didn't even need an editor, because you could just retype a line. It was also very straightforward for a complete novice (as most people were with those machines).
In any another environment, it really doesn't make sense.
True. One feature that was missed about BASIC on those early computers: you’d turn on the Apple ][ and you were greeted by the BASIC prompt and you could just start typing your program.
This was before floppy disks… you could load a program from cassette tape.
In Atari BASIC and Commodore BASIC, you didn't even need to retype a line. You could cursor up and edit it right on the screen. This saved a ton of typing.
BASIC illustrates the "one-screen problem," where a program becomes unreadable when it exceeds one screen, or perhaps one printed page. The one-screen problem is how I explain to beginners the value of things like subroutines with named arguments, local variables, and the like. Languages that survive, have to work for the size of programs that people want or need to write.
> BASIC illustrates the "one-screen problem," where a program becomes unreadable when it exceeds one screen, or perhaps one printed page.
Python has the same problem though, as do "scripting" languages in general. The limit may be some low amount of "screens" as opposed to a literal screenful of text, but either way it's quite impossible to program "in the large" with it. Even Go is hampered in this domain by its limited abstractions.
That a language might overcome the "any hunk of code bigger than a screenfull is too complex to manage", other than by chopping the code into functions and classes or whatever, is news to me.
What are other methods for slaying this complexity? And what are the languages that use it?
I think it's all of the languages people complain are "too complex": to be able to deal with more of program's complexity, you take on more language complexity.
e.g.:
• Encapsulation. Keeping implementation details private is pointless when you deal with a small program (the implementation is right there on your screen), but it becomes valuable when otherwise it'd be too hard to check which details you can change and which you can't.
• Strong type systems. All the types are obvious when the program fits in your head, and seem like unnecessary boilerplate. However, when the program is large, it off-loads a bunch of sanity checks from your head to the compiler.
Same goes for design patterns. Writing an `AbstractWidget` and `WidgetFactory` when you have two widgets to deal with is overcomplicating. But when you have 50 widgets, you need something to avoid drowning in copypaste and spaghetti if/elses.
Ideally, the features needed for writing bigger codes should be optional. For instance, a beginner can write a Python script within a single screen that does something like graph some data. Encapsulation can be treated as an add-on, as can be the type system.
That's assuming you want scalability. If a language is absolutely never going to be used for scripting by beginners, it doesn't need to be used that way.
> Ideally, the features needed for writing bigger codes should be optional.
Newer languages like Rust, Swift and arguably Carbon don't make programming-in-the-large features "optional"; they make them as lean as possible, so that users can more easily apply them at the outset compared to older languages like Java/C#. That way even a screenful-length trivial script can potentially grow into a larger system without becoming unmaintainable in the process.
Oh, you shouldn’t really be comparing unreadability of BASIC to even Unix shell scripts. Python is the pinnacle of readability and structure in comparison.
Let’s see…
Numbered lines as labels, GOTO everywhere. You got GOSUB if you were lucky.
All state propagated mostly via global variables. Subroutine parameters were present in dialects few and far between.
Now, variables. Maximum length of an identifier was what, 1? Or 2?
Inconsistent delimiters and syntax in general. Take GW-BASIC and its hot mess of graphical commands. Here you can’t have parentheses, but there you must. Semicolons here, commas there.
All the stuff that makes programs readable — consistent syntax, named procedures, reasonably long variable names, named labels if you must — all appeared very late, in QBASIC I think. But the rest of the BASIC world still had to cater to the lowest common denominator if your program was to be even mildly portable.
For starters, you didn't "get GOSUB if you were lucky". It dates back to the very first version of Dartmouth BASIC.
That aside, most of the limitations that you describe are applicable to BASIC as it was in 1970s (and some, like numeric-only labels and single-letter identifiers, are straight from the 60s). For example, GW-BASIC that you mention already had 40 significant characters in identifiers, WHILE loops, and single-expression user-defined functions.
I also don't recall anyone writing any serious amount of BASIC code while catering to the lowest common denominator for the sake of portability, simply because the dialects were different enough that it wasn't really feasible. Even on a single platform like DOS, going from e.g. Turbo BASIC to QBASIC required substantial changes.
QBasic (actually QuickBASIC; QBasic being the IDE) fixed some of the more glaring deficiencies of the original BASIC and I think was pretty popular for quite some time. I tried it and didn't like it--as I recall, I found things like error handling awkward. But it was from Microsoft and stayed around for quite some time.
Although Turbo Pascal was also popular for a time, I'm not sure anything truly replaced these beginner-friendly languages until Python came along.
Visual Basic was very successful, until Microsoft turned it into a mere alternative syntax for C# [0]. There is a parallel universe in which classic Visual Basic would have continued to thrive as a win32 glue language. (It still does to a minor extent in the form of VBA.)
I agree. VB6 was actively executed by Microsoft. VB6 didn't have to die.
I'm still surprised to this day that nobody stepped into that vacuum and created a VB6 clone. There should have been a ton of money for doing so--I wonder what prevented it.
I still have clients who are struggling to upgrade millions of lines of VB6 code base into something more modern (generally Python). GUI construction sucks in every single language since VB6.
The nice part is that they are unanimous in not choosing a Microsoft language ever again.
I've done some porting of VB6 into C# with WinForms. It's actually a pretty direct mapping. I wrote a converter, and then spend a few minutes cleaning up the converted code per form. Took me a couple weeks to convert a 500KB program, which mostly involved going through and converting VB6-isms that failed to auto-convert into C#. I can't imagine trying to translate something like that into such a different language and UI environment as Python. Unfortunate that they'd reject such a thing just because C# came from Microsoft.
> The BASIC cause of death is written that it was seen as a lesser, kids language.
Nah, its more that:
(1) The standardized, broadly compatible subset was a mostly unstructured, imperative language with very limited features, only global variable scope, named custom functions limited to a single expression (and a syntax that sharply limits what can be in a single expression), variables limited to numbers and strings, that was very tightly adapted to systems without modern capability (“line numbers” seem baroque now, but it really was a great way to have a simple, line-oriented text environment that worked as both REPL and simple dev environment.)
(2) While there were plenty of nonstandard versions with more modern features, they were mostly proprietary, often tied to very specific other pieces of software, and not particularly interoperable between them.
(3) Plenty of more modern, just as easy to use for simple cases, languages became available that had broad cross-platform compatibility (sometimes, not always, with formal standardization) without the limitations of BASIC’s broadly-compatible subset.
(4) Almost no computers came with “power on BASIC” anymore, so the unique role the ubiquitous use of BASIC in this way in the 8-bit home PC era gave it and which provided a support for its overall popularity went away.
All talks by Bret Victor are great, they are listed on his websites but they are more concerned with the future of programming than old languages: http://worrydream.com/
On the topic of language design, there is also this talk by Brian Kernighan which gives good practical advice if you're building a language and talks about his journey with awk: https://www.youtube.com/watch?v=Sg4U4r_AgJU
By what possible metric could you consider C++ "mostly dead"? I'm fairly sure that most, if not all AAA games nowadays are coded in C++, for example. Never mind such little known projects like GCC, Qt, and LLVM. It's not a language I care to use, but it's clearly still very healthy: widely used and regularly updated.
Most programs you use and internet infrastructure are written in C and C++. Furthermore, it's actively used to develop new software everyday by most large companies.
I'd say your first comment is very true and your second is very untrue. There will be sectors that will generally gravitate to c/c++, and a huge boatload that won't touch them with a ten foot pole. Corp languages are jvm based, .net based, js/ts, and maybe Go in some contexts now. None of the companies I've worked at in like 15 years has decided to create new c++ projects (clearly subjective view).
There’s significantly less interest in implementing the next version of C++; Apple and Google don’t care about it. So someone’s going to have to update g++ and clang.
Cobol is far from dead.
It is not sexy and I dont know of any systems starting out today using it.
But there are massive legacy systems till out there.
At least a couple years ago Cobol programmers were in high demand.
According to Microfocus [1 (2018)] over 2 million people worldwide are active full-time Cobol programmers, and it is running quite a few mission critical
systems.
>Companies involved in keeping COBOL-based systems working say that 95 percent of >ATM transactions pass through COBOL programs, 80 percent of in-person >transactions rely on them, and over 40 percent of banks still use COBOL as the >foundation of their systems.
Since we're talking about languages, a better question would be "is a language in which no new works are written but which has a large catalog of past works that are still studied by thousands of people 'mostly dead'?"
The many COBOL programmers are not being paid to study a dead language, they are being paid to adapt, evolve, and maintain living systems written in that language.
Less dead than perl by far. I've seen a lot of new COBOL going into production just this year. New versions of the compiler (the IBM one, the only one that really matters for COBOL) are still being released. A while back they went to the trouble of implementing full JSON serialization/deserialization. You would be surprised how many web services are pretty much just COBOL the minute the server needs to do anything with files or databases or whatnot.
As somebody that grew up on C and mostly doesn't work on the applications programming side of things, it was always tough to get my head around why so many people still wanted to write COBOL. Over the years though I've concluded that its simply a better language for certain kinds of tasks than anything created since. And there has been no shortage of support in keeping it relevant and easy to integrate with modern systems.
It would be interesting to see the COBOL record IO and destructuring of files and whatnot be implemented in a more modern language. I don't think anybody particularly cares for COBOL syntax, but the programming paradigm it supports doesn't have any other major players. Nobody has ever really even tried, probably because the types of people that usually create programming languages have no connections to the somewhat closed world of COBOL enthusiasts at large corporations. Certainly an interesting idea for a hobby project though, there are a lot of interesting places you could take a mixed COBOL/functional language type thing.
For instance, a function would take one file and output another, file structures and record structures could be interpreted as data types, archiving files would be treated as a side effect of the system essentially (or potentially if you get real crazy, make that some sort of functional abstraction as well). Just spitballing here because it's a fantastic idea that I would love to see. There is no reason that working with files has to necessarily be treated as entirely external to the program/a side effect, so long as you take care to have some sort of way to deal with acquiring locks/contention issues and whatnot. Not a problem on mainframes, but there would need to be some systems features implementing to make that sort of paradigm effective in a Unix style environment. I'm not sure it could be done entirely in a runtime, a lot of that state would really need to be global.
Microfocus COBOL also matters - there's non-trivial amount of code that is still being worked on, in COBOL, that runs these days mainly on RHEL machines and is compiled with Microfocus.
As for handling destructuring files, how useful it is really shows when you consider how easier many tasks become when you have access to such facility - even if nowadays you might expect it to be handled by extra compilation step that uses protocol buffers or something similar.
Modern programming languages are more than capable of providing an abstraction layer that can offer seamless file->struct and struct->file conversions.
It's basically the equivalent of ORM for relational database.
But nobody does it not because it's hard or because the language doesn't support it. They don't do it because we no longer think of file system the main "database" that stores your application state.
Instead we think of the filesystem as a lower level building block for higher level abstractions (such as relational or whatnot databases)
Pascal similarly lives on with Deplhi/Lazarus. I know plenty of currently supported commercial programs running on Delphi and considering a transition to Lazarus.
I've seen an uptick in APL and APL-derived array languages. "Niche" would have been a better term. I would put Smalltalk in the same category.
What about some commercial languages instead which are de-facto dead, such as ColdFusion, ActionScript, Lingo, and so on...
> and I dont know of any systems starting out today using it
I do... In a project I was working on for a major Dutch government organization, they were building stuff in COBOL. This was a project where we were using NLP for automated data extraction. I still find it hilarious that part of it was being built in COBOL.
Most of these languages are neither dead nor dying. They are just niche.
I just started learning APL this year. It is still actively developed and no you don't need a special keyboard. Plus we have unicode now which makes the special symbols a non-issue these days.
Same with most of the other languages. There is Pharo and Squeak for Smalltalk, the pascal community has free pascal. Sure those communities might not be huge but they are not in acute danger of vanishing any time soon.
And COBOL is still carrying the economy.
Now some languages like ALGOL might actually be dying, sure.
Natural languages are considered dead when they lose their last native speaker. Similarly when the last person being able to use a programming languages dies, we can consider that language dead.
Which means that we have lots of languages that died at childbirth but once a programing language has managed to go over a certain popularity threshold, it is very hard to kill.
Languages don't need to win any popularity contests to be alive. Language maximalism in the sense that you need to be one of the most popular languages or you are considered a failure and dead is just silly.
What were your use cases for APL ? I love it to bits on principles but never used it seriously, despite all the efforts of dyalog and Aaron Hsu.
niche languages have a flavour that mainstream spoils with feverish fads.. I always like to read perl or TCL forums and am surprised by the ideas and productions.
> Natural languages are considered dead when they lose their last native speaker. Similarly when the last person being able to use a programming languages dies, we can consider that language dead.
Someone "able to use a programming language" more directly parallels someone able to speak a language at all, by which measure Latin would not yet be dead. If you're going to draw the line there, that would be what linguists term an "extinct language".
It's hard to draw parallels to natural language because there are no native speakers of programming languages. The closest parallel I can think of is that a language can be considered dead when no new projects are started in it. Once you've reached that point, the remaining work in the language is maintenance, which is comparable to people studying and translating old Sanskrit texts.
Alternatively, a language can be considered dead when it has stopped changing and frozen in its final form.
By either of these measures a lot of these still aren't dead, but my bet would be that COBOL counts.
Also, as was obscured by the title mangler, the "dead" in the title is just a side remark; the title without the parenthesis is "10 most influential programming languages", and "(ly dead)" after "most" is just a parenthesis.
Maybe we'll just revert to the linkbaity title in this case. I had it briefly as "Mostly-dead, influential programming languages (2020)" but that probably did more harm than good.
Just curious: How do you determine whether the title change worked? Do you try it out and then check back later to see whether commenters are still getting hung up on the topic?
Well, it's not a claim that these are the ten most influential programming languages. Lisp was clearly more influential than most of these, but it didn't make the list because it's still alive.
I think the title was mostly just a pun/riff on the title of the other post linked in the first paragraph, which did claim to be a list of the most influential languages, and doesn't really make sense if read as a specific concrete claim.
> Natural languages are considered dead when they lose their last native speaker. Similarly when the last person being able to use a programming languages dies, we can consider that language dead.
I don't think this is the right comparison. A native speaker would be more like someone who learned the language as their first or maybe second language, rather than someone who can use it at all. And by that metric, these languages are pretty much dead/dying, since they mostly have no new learners who aren't into PL history.
> since they mostly have no new learners who aren't into PL history.
They do have have new learners, that was my whole point. Whether they learn out of historical interest, to become better programmer in general, for a job, for research, or because they need it for a specific project does not matter. (And yes all those reasons apply.)
Or look how many people use it to solve Advent of Code.
As for learning them as a first language, if we applied that criteria then most programming languages would be born absolutely dead and stay there. I don't think anyone ever learned Elm or Purescript as their first language, are they dead?
I really don't get why people make such weird claims, declaring healthy and obviously alive communities to be dead. Again, things don't need to popular to be alive.
There's a difference between learning a language as part of history, and actually being proficient at it. I know ALGOL 60 well enough (having tried to implement it), but I wouldn't consider myself a "native speaker" of it.
I mean, I'm pretty sure most of those companies would view APL as a liability, just like companies that still use COBOL. The question really is about whether new, significant projects are being started in these language.
People choose weird, novel, old, and esoteric languages for Advent of Code because it's fun and a way to stand out from the pack, or practice languages that might not ever get used otherwise. It's not evidence of a healthy community.
And yeah, I mean Elm and Purescript might not be "dead", but the fact that they are niche, largely non-general-purpose languages doesn't really mean that they are "healthy" either. I'd be willing to take a bet that both of these languages are effectively dead in 10 years.
your first programming language isn't really analogous to your native language. there isn't actually a fair comparison between programming languages and natural languages. active users of a programming languages seems a fair enough measure of liveness.
Sure, but I think the question is what we mean by "active." I think "has anyone written code in this language recently" isn't a great metric, because by that measure pretty much any language that ever has had adoption is "alive" by virtue of being used in Advent of Code, as the OP points out. This just seems contrary to my intuition about what it means for a PL to be alive and have a healthy community. What I meant by "first language" was more about community growth, and there being people willing to mentor newbies, new projects being started for new users to hack on, etc.
Lazarus ( Free Pascal ) seems to be thriving actually. APL is probably as big as it ever was. COBOL will shrink over time but it may still outlast me. I have no insight into SmallTalk but my University curriculum included it and it would not surprise me at all to see it used academically today. I was also taught Scheme and Fortran and those are still going strong. If I wanted to use any of these, I know I can find both free and commercial dev environments easily that run on platforms I still use.
Is ALGOL still in use anywhere though? Is there a compiler available that runs on anything modern? I genuinely curious.
My exposure to SmallTalk has basically been from professors who always referenced it as great and a pillar of OOP back in the day at university. Of course I was a crontrarian student who was drinking the functional cool aid at the time so my response was usually "lol OOP" or something similarly clever. I investigated it a bit and my main takeaway was "ellegant but slow". Being the mature student I was I then proceeded to read up on OOP in detail for the following semester and changed from "lol OOP" to "yeah, yeah but it's so much better in Eiffel". I'm very thankful that I've since turned from a flamewar-triggerhappy person into a very pragmatic person that uses whatever language gets the job done while trying to find the value and neatness in each of them :)
Looks like an Algol special character was added to Unicode in 2009 so... maybe?
Seems like Fortran and COBOL pop here as dead languages still in use but I haven't seen anyone mention Algol (or B, BCPL or anything similar either).
That's why he said MOSTLY dead. Mostly dead is slightly alive. With all dead, there's only one thing you can do: go through their pockets and look for loose change.
Not by choice but rather out of desperation and necessity to continue to run the mission critical code, mostly in banking, finance, and it is also occasionally encountered in government services albeit its presence has greatly diminished in the last decade or so. Young developers have no interest in learning COBOL, and the old developers have alredy died several times, have been dug out of their graves several times and brought back to the frontlines, and there are no more of those to be had. So the mission critical code continues to run on the constantly upgraded mainframe hardware, sometimes having not been changed in a few decades.
Oddly enough, despite a few large scale attempts to come up with automated COBOL -> whatever language migration / translation tools, they seem to have been largely fruitless. I think it was IBM that hired a bunch of hardcore academics in mid-2000's (?) to design and implement a COBOL to Java translator in Standard ML, and they even managed to produce something working. Unfortunately, then history becomes murky and trails off, and the eventual fate of that creation is an enigma of sorts. And, then, earlier versions of Java (before Java 8 anyway) were a horror to behold and would probably require a Java < 8 into Java >= 8 translator, so…
I'd actually love to work with COBOL professionally, my problem is that COBOL jobs still pay a substantially low amount of money compared to jobs using modern stacks.
For something so "critical" you'd think the base salaries would start at $250k/year; but I guess we aren't at that level of desperation yet.
Out of curiosity what about COBOL appeals to you? My first job out of college was working with RPG on an AS/400 (so I'd consider it at least a cousin) and the experience was awful.
Basically wanting to work with a true legacy system, colloquially I feel like
legacy" typically means "abandoned php/java8/c#" project. COBOL projects are older than me!
I think it would really help me grow as an engineer to understand how these systems are maintained, how they are tested, and how they are updated; what better way than something several decades old?
I feel like this is hard to find in the modern era, especially post 2010 onward.
Ah, interesting. I will admit I learned a great deal in the 2 years, though not all of that was the things you said. For me it was we had a lot of different codebases because each client had their own needs (beyond everyone who used our payroll system including printing checks, but that system rarely needed maintenance) so I had to learn to quickly read and understand a codebase to be able to make changes w/o spending days/weeks getting up to speed.
Interesting reading your comment as well! I honestly don't know what I would expect to learn just writing would I think would happen. :D
Thinking about it more, I don't think I've met single person that ever touched a COBOL code base throughout my career (talking from ICs up to VPs here). It seems the "oldest" was always some early Java project from early 2000s.
Because at $250k/yr they'd have no trouble attracting engineers willing to learn COBOL. There isn't a current "emergency" a la Y2K to spike the demand of experienced COBOL programmers; they have time to hire anyone with a CS background and let them learn the language on-the-job so they can do low-priority legacy maintenance.
> […] and let them learn the language on-the-job so they can do low-priority legacy maintenance.
And that is a problem frequently faced with fresh graduates and young developers (no disrespect to them) whose common reaction to legacy programming languages and platforms is best characterised as «ew, this is gross». Even a heftier salary package does not do the job – they just don't want to learn legacy technologies.
As a personal anecdote, it is the situation I encountered with a few young devs (3-4 years of the industry experience) in my team whom the management had entrusted to learn and support a 4GL platform that they borderline flatly refused to learn and left their employer shortly afterwards to code in React and other NodeJs frameworks. Which is regretful as the 4GL language in question was a pretty modern and good design and could have been learned to get a glimpse into good design and coding practices, the intricacies of the complex transaction processing etc. All of which could have been reused pretty much anywhere outside 4GL. In my view, it was a sorely missed opportunity.
The '08 recession forced me into a job maintaining an old Ada system when I was a young developer. Toward the end of that experience I was put on a project that involved modernizing and updating said system by porting it from SPARC/Solaris to x86/RedHat. I also had to learn to read MATLAB because most of the new modules involved translating the work of scientists into Ada code.
A good learning experience, at least. I've long since moved on to more "modern" technologies.
Windows Win32 API still uses Pascal calling convention instead of standard C. Shadow from the dead.
And also there was the 4th generation language movement at that time, 4GL. Defined by coding like writing English sentences, and not much algo. More akin to our no-code, low-code trend. SQL was also a child from 4GL. C/C++ was then seen as 3GL. And then we can now watch 3GL ultimately took over 4GL, at least until now, for half a century.
COBOL came well before the 4th generation of programming languages - it was one of the earliest 3rd-gen languages. One could argue that like 4th-gen languages it was domain specific, but most programming languages back then were tailored to rather narrow domains.
Pascal is almost dead but still there is Delphi, FreePascal/Lazarus and Oxygen.
They are all being actively developed.
I just wish Embarcadero would stop charging an insane amount for Delphi.
Basic is even more nearly dead.
There are still a few interesting things left
like:
Up until a few years ago at least, and I still think it is the case
Epic (https://www.epic.com/) had a huge amount of their codebase in Visual Basic classic.
I would not say so. The BASIC used in the Office pack is the last child of the MS-BASIC/GWBASIC/QBASIC/QuickBasic/VisualBasic lineage, is still (unfortunately?) very much alive, and probably powering a much bigger part of the modern world than we should be comfortable with.
VBA isn't that bad a language. Compiles to native and runs with impressive speed. Lots of built in libraries for numeric programming among other things and fairly easy to call into any dll. The issue is it's accessibility. Like JS and Python people blame the language for what happens when you hand people with no software training and an interest only in solving their immediate problem, a computer language they are productive in.
And how can we call basic dead when VB.net is still in the tiobe top 10?
The problem with claims of Pascal being dead or almost dead, is there are competing interests and evangelists of rival languages who wish it to be dead, and Pascal/Object Pascal simply won't do them the favor. As partially shown by Object Pascal being consistently ranked around #15 (for many years) on the TIOBE index (sometimes a bit higher and sometimes a bit lower).
To say Pascal/Object Pascal is almost dead, is to ignore how much more used and taught the language is over known and hyped languages in the media such as Go, Rust, Swift, Julia, etc... Nobody says that those languages are "almost dead", yet Pascal/Object Pascal is as or more used than any of them.
One aspect of the confusion over if Pascal is dead or not, has to do with naming and marketing. Delphi is an IDE/compiler of the Object Pascal language. People can of heard the name Delphi, and know its still very alive, but have no idea or don't realize the language is Object Pascal. In the same context, this goes for Oxygene, and to a lesser degree, for Free Pascal/Lazarus, PascalABC, etc... People aren't aware of how they connect as dialects of Pascal/Object Pascal, and get confused by the names and marketing.
Well, the real problem is that people are not writing native Windows applications anymore, that's what Delphi was good at. And Embarcadero also priced themselves out of the market, they should have had a long hard look at Jetbrains and how those guys thrived in an overcrowded market.
They certainly are, because not everything can be a Web app, and thakfully Electron is still a niche thing.
Borland priced themselves out of the market when they trasitioned into Emprise, now that is what is left as customers, the people that pay for tooling, and sadly it is hard to go back in time for hobby prices.
See Qt as well.
I have the feeling JetBrains might fall into the same trap, as I see them trying to make a Delphi out of Kotlin.
The "Why Pascal is not my favourite language" essay mentioned used to get cited frequently,
but a lot of its criticisms are either irrelevant or just plain incorrect with respect to Delphi and co. e.g. "There is no 'break' statement" - In Delphi, there is. "There is no 'return' statement" - yes, there is.
It became a recurring circular argument at that point, with rounds of
"This essay is just wrong now."
"that just shows that Delphi is not Pascal, the essay is correct for _Pascal_ as standardised";
"then why does this essay keep being raised as if it's still relevant to Delphi, when it is not?"
"That's a misinterpretation",
"yes, one that newcomers make constantly. It's harmful."
The article is probably accurate that this essay was influential. "Was it correctly so?" is a different issue.
That chart with Java is amazing. And in my personal case, also true. Actually paid for something called SmalltalkAgents (which was pretty cool btw) just a bit before Java happened. Then Java happened.
PL/1 was an IBM mainframe language; but Intel made a compiler for a stripped-down version targeting 8086, called PL/M (Programming Language for Microprocessors). PL/M was (I believe) the main language used in writing the CTOS/BTOS operating system (Convergent Technologies/Burroughs).
PL/M was a nice language. It was suited for system programming (structs, pointers). I first came across it in some introductory programming book I bought from a second-hand crate. A lot of my early programming lessons came from that book, even though I had no access to a PL/M compiler. I have no idea who wrote it, or what its title was.
My encounter with PL/I was with some 3270-style Wang terminals for their minicomputers. They were programmable by writing PL/I which got compiled and stored in the terminal's NVRAM. There wasn't much you couldn't do with it, I made macros that could copy blocks of text between two different terminal sessions as well as a bunch of cursor positioning and general clipboard operations. PL/I is quite a nice language.
PL/M was a nice language indeed; I used it on embedded 8085 based systems; but I don't think it had many overlaps with PL/I; but there were similarities.
Having programmed in both, the most similarity is in the name. PL/I is a vastly complicated language that needs a specialized grammar to describe and PL/M works on microprocessors. Oh, and another flaw with the article is that PL/M was not invented by Gary Kildall, not Intel.
Well, I said that Intel produced a compiler. I see from Wikipedia that Kildall did indeed develop PL/M; the same article says that Intel "promoted" it. The compiler that we used was branded Intel. It sounds like Kildall developed it for Intel.
[Edit] My notion that PL/M was a cut-down version of PL/I was clearly wrong; I never used PL/I, the closest I got was reviewing a few documentation pages.
It will go away one large bank bankruptcy at a time (perhaps several at a time in case of country bankrupcy). Who is going to use COBOL for a new project at a new bank ?
Surprised this doesn’t mention Smalltalk’s huge influence on two major living languages: Objective-C and Ruby, both of which use the Smalltalk object model, dynamic message passing paradigm and all, which is very different from how most other OOP implementations work.
In the long run: Objective-C will be gone in 20 years, but Ruby won’t. Outside of ObjC interop facilities, Swift will retain some of Objective-C’s Smalltalk heritage, as one of many influences.
The writing of history (historiography) is not meant to be a minutely detailed account of everything that happened. History is a narrative, a story about how we came to be here, and sees the past with a particular lens. I think this particular history was meant to bring appreciation of influential yet obscure and niche languages for the current generation of developers and software engineers. I doubt it was meant to be definitive or exhaustive.
In fact, at the very bottom of the article, there is a link to the Encyclopedia of Programming Languages with over 8000 entries. The influence of Smalltalk’s “everything is an object” on Objective-C and Ruby is probably in there somewhere.
Disclosure: I wrote Ruby professionally for over ten years, and learned the basics of OOP with ObjC back in the 90s. I get the significance of Smalltalk’s object model.
> The writing of history (historiography) is not meant to be a minutely detailed account of everything that happened. History is a narrative, a story about how we came to be here, and sees the past with a particular lens.
Of course I get all of that; however, the author also chronicled the influence of these languages and certainly Objective-C use of Smalltalk's object model, a language that provided macOS and iOS such a competitive advantage for many years, it's probably worth a mention.
This was a great trip down memory lane for an old retired sometime programmer and software engineer. I learned programming in K & K BASIC on a GE time share machine and FORTRAN II on an IBM 7090. I wrote production code in many of these languages (BASIC, COBOL, PL/I (not much), Pascal, SmallTalk (my favorite)). Among the odder "language" projects I ever worked on was a cross-compiler written in Pascal for a report generator. The compiler generated COBOL as it's object code, which we chose because of it's facility with reading database records, and formatting output for fixed spacing line printers.
I'm familiar with all but a couple of the languages in his list, and wrote code in most of them, although in some cases not code that ever went into a product or production environment. ML and CLU, though, I've never touched.
I’ll shout out for ADA as well. Really enjoyed working with it.
Compiler was a nit picking monster but the rigour ensured that you really considered your program. Thanks for making me remember.
My only real exposire to Ada was a report for a class project in college. One tidbit that stuck with me is that there were a few DOD projects using Ada after it was first created which actually got done ahead of schedule and under budget. That always impressed me given the normal DOD software track record.
Also, I believe people place way too much emphasis on "popularity" of a language. If a language has enough traction to stay alive it can be valuable unless you're doing the most generic web dev stuff around. Heck there's cases where Perl still outshines modern competitors.
Like some of the sibling posters, I'll use this opportunity to share my feelings on Ada. I checked it out a few years ago, and I was amazed at how much it has to offer. Despite being designed by committee in the late 70s, Ada has many features that remain novel by today's standards. I'd say Ada is a 'must see' for anyone interested in implementing new programming languages, there are many great lessons language designers can take away from Ada.
One benefit I had from learning Ada was that it treats encapsulation, implementation hiding, inheritance, subclassing, message passing, etc. as separate mechanisms that you can opt into individually.
This is a huge difference compared to something like Java or Python where "everything is a class and a class is everything", and if you desire implementation hiding you sort of automatically also opt into get encapsulation and subclassing and the rest of it.
When you learn the mechanisms individually, object-oriented programming starts to make a lot more sense! Ada is worth looking at just for that experience alone! Then the other things are a bonus.
You can get going with the Alire package manager which installs the Free Software Foundations GNAT compiler (part of GCC) in a few minutes: https://ada-lang.io
This connects to another of Ada's advantages: language-integrated support for
subsetting the language. In the C world, you can define a subset of the
language, but if you want a tool to ensure compliance, you're on your own.
With Ada, you can define a 'profile' and have the compiler check compliance.
This has been done with the Ravenscar profile (for real-time work) and, most
famously, the SPARK profile (for formal verification).
(There isn't integrated support for user-defined style guide conformance
though. From the perspective I've used here, MISRA C is both a subset and a
style guide.)
You know what's a lot like Ada in a good way is Mesa, which evolved into Ceder, from Xerox PARC. I know people who really loved programming in it. They'd call it "Industrial Strength Pascal". It was a successful experiment in code reuse. A strongly typed language with strong separation between interfaces and implementations, which encouraged creating robust, hardened code.
>Mesa and Cedar had a major influence on the design of other important languages, such as Modula-2 and Java, and was an important vehicle for the development and dissemination of the fundamentals of GUIs, networked environments, and the other advances Xerox contributed to the field of computer science.
Demonstration of the Xerox PARC Cedar integrated environment (2019) [video] (youtube.com)
Mark Weiser and others at Xerox PARC's ported the Cedar environment to Unix, which resulted in the development of the still-widely-used Boehm–Demers–Weiser conservative garbage collection.
I believe that stuff is the port of Cedar to the Sun. Xerox PARC developed "Portable Common Runtime", which was basically the Cedar operating system runtime, on top of SunOS (1987 era SunOS, not Solaris, so no shared libraries or threads, which PCR had to provide). He demonstrates compiling a "Hello World" Cedar shell command, and (magically behind the scenes) dynamically linking it into the running shell and invoking it.
Experiences Creating a Portable Cedar.
Russ Atkinson, Alan Demers, Carl Hauser, Christian Jacobi, Peter Kessler, and Mark Weiser.
>Abstract: Cedar is the name for both a language and an environment in use in the Computer Science Laboratory at Xerox PARC since 1980. The Cedar language is a superset of Mesa, the major additions being garbage collection and runtime types. Neither the language nor the environment was originally intended to be portable, and for many years ran only on D-machines at PARC and a few other locations in Xerox. We recently re-implemented the language to make it portable across many different architectures. Our strategy was, first, to use machine dependent C code as an intermediate language, second, to create a language-independent layer known as the Portable Common Runtime, and third, to write a relatively large amount of Cedar-specific runtime code in a subset of Cedar itself. By treating C as an intermediate code we are able to achieve reasonably fast compilation, very good eventual machine code, and all with relatively small programmer effort. Because Cedar is a much richer language than C, there were numerous issues to resolve in performing an efficient translation and in providing reasonable debugging. These strategies will be of use to many other porters of high-level languages who may wish to use C as an assembler language without giving up either ease of debugging or high performance. We present a brief description of the Cedar language, our portability strategy for the compiler and runtime, our manner of making connections to other languages and the Unix operating system, and some measures of the ...
It was also heavily negatively influenced by C++. If you like reading lots of hilarious ideological, syntactic, and semantic ranting and raving about how terrible C++ is, pick up one of Bertrand Meyer's original Eiffel books (from before Java, which is another negative reaction to C++ in a different direction), you'll love it!
Where I think it broke down is with multithreading, because you can't reason about preconditions and postconditions of a method if there are other threads banging away at it. But maybe that's been solved since when I read the Eiffel book.
Sather is an open source language that was originally based on Eiffel, but developed in its own direction. Named after the Sather Tower at Berkeley instead of the Eiffel Tower in Paris.
Despite being designed by committee in the late 70s
You say that like it stayed there. Ada has been updated and refined continually since the first standard in 1983. Ada 2012 is the latest approved, and Ada 202x is in review.
Just like Fortran (see Fortran 90, 95, 2003, 2008 & 2018).
My apologies. I was only referencing the typical criticisms people have of the language. Most of which having absolutely nothing to do with the language itself. I'm very familiar with modern Ada. I've done lots of hobby programming in Ada 2012, and now Ada 202x.
I wish more language designers paid attention to how Ada did things. The language has some features that are very relevant to performance that even C++ or Rust lacks.
For example, Ada allows to return stack-allocate arrays with variable number of elements. One can emulate that in C++ with various arena classes, but the resulting code is not that efficient and the usage is much more complex.
I offered a job in a company that implements NATO procedures.
Its a company in Greece that implements radar software for airspace among other defensive projects.
I stayed there only for a month, i hated the objective of the job, I hated the UI custom library, I hated the way I had to test my code, I hated how much of disengagement I had to do from my morals to work on 'defense' projects.
I just posted a link about NewtonScript [1] in this thread, which had prototypical inheritance in the early 90s, which JavaScript later used.
Short answer: it's more memory efficient than a full-blown OOP system.
I was pretty active in the Newton MessagePad community back then and I knew lots of Newton developers; they loved NewtonScript and raved about prototypical inheritance.
I would expand this list with: perl(mostly-dead influential), and ceylon and coffescript(these last ones mostly-dead and not so influential, let's be honest).
I also would say that ruby is a future mostly-dead language, but I don't want to sound too controversial.
CoffeeScript might just be one of the most influential languages. Tons of ES6 features were directly inspired by CoffeeScript and ES6+ JavaScript is the most popular language in the world right now.
I'm not sure I agree with you. I'm not denying that coffescript might have inspired ES6+ features, but from this to say that it's a very influential, let alone one of the most influential languages, is a big leap. In my opinion, of course.
I developed a lot of projects with ruby and yet I can't think of a single reason to opt for ruby over python or typescript. Ruby doesn't do anything better both in terms of language or platform than its already very well established competitors.
It's my understanding that ruby rose to prominence mostly because of ruby on rails, now that RoR is in a downward trend I think ruby will follow the same trend until it's reduced to a small community of enthusiasts in the same way that happened to perl.
I can think of one, Ruby has a very healthy ecosystem for web development, with a very dominant an popular framework. A lof ot big companies seem to be invested on it to some degree. I don't think it has the brightest future and it might have a long but steady decline ahead, but I don't think risk of immediate dead.
(This is not to talk about the merits of the language, which it's really orthogonal to popularity).
> While SIMULA wasn’t the first “true” OOP language, it was the first language with proper objects and laid much of the groundwork that others would build on.
This is wrong. Simula 67 was the first object-oriented programming language; though the term is said to be coined by Alan Kay who specified Smalltalk-72; but he understood and still understands object-orientation differently than we understand it today; our understanding of it today is more like what Simula 67 introduced; remarkably, Smalltalk-76 represented a significant departure from Smalltalk-72 toward the concepts already known in Simula 67; the primary difference of Smalltalk 76 from Simula was dynamic typing and the conception of even simple types as classes. Simula 67 was still actively used in the nineties (e.g. as a teaching language at Stockholm University until 1997). The performance was comparable to that of C++ or Pascal, definitely faster than Smalltalk on comparable machines.
243 comments
[ 3.2 ms ] story [ 162 ms ] threadIn my opinion, Borland was the 300lbs gorilla in the Pascal compiler arena, so when Borland decided to move push Delphi over Pascal, there was no interest in filling the Pascal hole.
btw I wrote commercial products on Pascal that I thought was neat. A chat program that used IPX/SPX, a a fax server using DesqView, and MS Mail queues both inbound and outbound, reverse delta databases that stored all changes at field level, overcame the 640K memory barrier by using a TSR that swapped the data in/out on demand, and a proto-PXE server using my insanely fast copy program over IPX. That was the good old times.
I took Pascal as a college freshman in 1982. And even though I haven't programmed in it seriously since then, it stuck with me. It didn't hurt that it was a minimal language designed for teaching computer science. For example, when I learned Pascal, there was no string type; you had to create an array of characters.
I was checking out the Free Pascal website recently; although the language has been greatly expanded, Free Pascal source code still made sense to me.
https://news.ycombinator.com/item?id=22690229 (289 comments; March 26, 2020)
https://news.ycombinator.com/item?id=24602741 (13 comments; Sept 26, 2020)
Some other submissions but with 0 or 1 comment.
I believe that Delphi was a vastly superior product to any of its contemporaries, and was killed purely by corporate forces.
I still think the biggest mistake MS made with their tooling was burying VB6+ and replaced it with VB.net. They may have made VB a "real" function extensive language, but I think a bunch of soft-programming people just left and never went back. C# ate any of those that would've used VB.net in this way anyways IMHO.
That sentiment may be true to some extent, but fails to mention all of the problems of the BASIC language that made people look into alternatives, none of which were snobbiness.
If that were a real reason, Python would have suffered a similar fate.
In any another environment, it really doesn't make sense.
This was before floppy disks… you could load a program from cassette tape.
Python has the same problem though, as do "scripting" languages in general. The limit may be some low amount of "screens" as opposed to a literal screenful of text, but either way it's quite impossible to program "in the large" with it. Even Go is hampered in this domain by its limited abstractions.
What are other methods for slaying this complexity? And what are the languages that use it?
e.g.:
• Encapsulation. Keeping implementation details private is pointless when you deal with a small program (the implementation is right there on your screen), but it becomes valuable when otherwise it'd be too hard to check which details you can change and which you can't.
• Strong type systems. All the types are obvious when the program fits in your head, and seem like unnecessary boilerplate. However, when the program is large, it off-loads a bunch of sanity checks from your head to the compiler.
Same goes for design patterns. Writing an `AbstractWidget` and `WidgetFactory` when you have two widgets to deal with is overcomplicating. But when you have 50 widgets, you need something to avoid drowning in copypaste and spaghetti if/elses.
That's assuming you want scalability. If a language is absolutely never going to be used for scripting by beginners, it doesn't need to be used that way.
Newer languages like Rust, Swift and arguably Carbon don't make programming-in-the-large features "optional"; they make them as lean as possible, so that users can more easily apply them at the outset compared to older languages like Java/C#. That way even a screenful-length trivial script can potentially grow into a larger system without becoming unmaintainable in the process.
Let’s see…
Numbered lines as labels, GOTO everywhere. You got GOSUB if you were lucky.
All state propagated mostly via global variables. Subroutine parameters were present in dialects few and far between.
Now, variables. Maximum length of an identifier was what, 1? Or 2?
Inconsistent delimiters and syntax in general. Take GW-BASIC and its hot mess of graphical commands. Here you can’t have parentheses, but there you must. Semicolons here, commas there.
All the stuff that makes programs readable — consistent syntax, named procedures, reasonably long variable names, named labels if you must — all appeared very late, in QBASIC I think. But the rest of the BASIC world still had to cater to the lowest common denominator if your program was to be even mildly portable.
That aside, most of the limitations that you describe are applicable to BASIC as it was in 1970s (and some, like numeric-only labels and single-letter identifiers, are straight from the 60s). For example, GW-BASIC that you mention already had 40 significant characters in identifiers, WHILE loops, and single-expression user-defined functions.
I also don't recall anyone writing any serious amount of BASIC code while catering to the lowest common denominator for the sake of portability, simply because the dialects were different enough that it wasn't really feasible. Even on a single platform like DOS, going from e.g. Turbo BASIC to QBASIC required substantial changes.
Although Turbo Pascal was also popular for a time, I'm not sure anything truly replaced these beginner-friendly languages until Python came along.
QuickBasic and QBasic both included IDEs; QBasic was the later revision (1991, vs. QuickBasic in 1985).
(Weirdly, perhaps, Microsoft released Visual Basic the same year as QuickBasic.)
[0] http://catb.org/jargon/html/V/Visual-Fred.html
I'm still surprised to this day that nobody stepped into that vacuum and created a VB6 clone. There should have been a ton of money for doing so--I wonder what prevented it.
I still have clients who are struggling to upgrade millions of lines of VB6 code base into something more modern (generally Python). GUI construction sucks in every single language since VB6.
The nice part is that they are unanimous in not choosing a Microsoft language ever again.
Nah, its more that:
(1) The standardized, broadly compatible subset was a mostly unstructured, imperative language with very limited features, only global variable scope, named custom functions limited to a single expression (and a syntax that sharply limits what can be in a single expression), variables limited to numbers and strings, that was very tightly adapted to systems without modern capability (“line numbers” seem baroque now, but it really was a great way to have a simple, line-oriented text environment that worked as both REPL and simple dev environment.)
(2) While there were plenty of nonstandard versions with more modern features, they were mostly proprietary, often tied to very specific other pieces of software, and not particularly interoperable between them.
(3) Plenty of more modern, just as easy to use for simple cases, languages became available that had broad cross-platform compatibility (sometimes, not always, with formal standardization) without the limitations of BASIC’s broadly-compatible subset.
(4) Almost no computers came with “power on BASIC” anymore, so the unique role the ubiquitous use of BASIC in this way in the 8-bit home PC era gave it and which provided a support for its overall popularity went away.
Not true. When I learned Applesoft BASIC in 1978–79 on an Apple ][+, it had arrays.
It gives an interesting tour of dead languages and the things we lost.
https://www.youtube.com/watch?v=8pTEmbeENF4
This talk explain me why I feel better with languages with more dynamic features.
On the topic of language design, there is also this talk by Brian Kernighan which gives good practical advice if you're building a language and talks about his journey with awk: https://www.youtube.com/watch?v=Sg4U4r_AgJU
[0] https://www.youtube.com/watch?v=SxdOUGdseq4
I kicked and kicked and it would not get up again.
What’s merlyn doing these days?
His response to the early warnings that “Perl is dying “ was “more people use Perl now more than ever”
The downfall of Perl should be a “case study”. Other communities should learn from the Perl community’s mistakes.
Java also had many problems for quite some time but its frequent update cycle seems to have helped.
It looks like he's still doing Perl:
http://www.stonehenge.com/merlyn/
https://www.oreilly.com/library/view/learning-perl-8th/97814...
At least a couple years ago Cobol programmers were in high demand.
According to Microfocus [1 (2018)] over 2 million people worldwide are active full-time Cobol programmers, and it is running quite a few mission critical systems.
>Companies involved in keeping COBOL-based systems working say that 95 percent of >ATM transactions pass through COBOL programs, 80 percent of in-person >transactions rely on them, and over 40 percent of banks still use COBOL as the >foundation of their systems.
Can we say it's mostly dead?
For example, is it more or less dead than perl?
Most would say yes.
There's a lot of new code written in most of these languages. It might be existing systems, but the code being written is new.
>> For example, is it more or less dead than perl?
== The current state of Perl 5 for Python fans ==
Perl 5: I'm not dead!
TIOBE: 'Ere! 'E says 'e's not dead!
Internet: Yes he is.
Perl 5: I'm not!
TIOBE: 'E isn't?
Internet: Well... he will be soon--he's very ill...
Perl 5: I'm getting better!
Internet: No you're not, you'll be stone dead in a moment.
TIOBE: I can't take 'im off like that! It's against regulations!
Perl 5: I don't want to go off the chart....
Internet: Oh, don't be such a baby.
TIOBE: I can't take 'im off....
Perl 5: I feel fine!
Internet: Well, do us a favor...
TIOBE: I can't!
Internet: Can you hang around a couple of minutes? He won't be long...
TIOBE: No, gotta get to Reddit, they lost nine today.
Internet: Well, when's your next round?
TIOBE: Next year.
Perl 5: I think I'll go for a walk....
Internet: You're not fooling anyone, you know-- (to TIOBE) Look, isn't there something you can do...?
Perl 5: I feel happy! I feel happy!
Monthy Python is just pure genius :D
As somebody that grew up on C and mostly doesn't work on the applications programming side of things, it was always tough to get my head around why so many people still wanted to write COBOL. Over the years though I've concluded that its simply a better language for certain kinds of tasks than anything created since. And there has been no shortage of support in keeping it relevant and easy to integrate with modern systems.
It would be interesting to see the COBOL record IO and destructuring of files and whatnot be implemented in a more modern language. I don't think anybody particularly cares for COBOL syntax, but the programming paradigm it supports doesn't have any other major players. Nobody has ever really even tried, probably because the types of people that usually create programming languages have no connections to the somewhat closed world of COBOL enthusiasts at large corporations. Certainly an interesting idea for a hobby project though, there are a lot of interesting places you could take a mixed COBOL/functional language type thing.
For instance, a function would take one file and output another, file structures and record structures could be interpreted as data types, archiving files would be treated as a side effect of the system essentially (or potentially if you get real crazy, make that some sort of functional abstraction as well). Just spitballing here because it's a fantastic idea that I would love to see. There is no reason that working with files has to necessarily be treated as entirely external to the program/a side effect, so long as you take care to have some sort of way to deal with acquiring locks/contention issues and whatnot. Not a problem on mainframes, but there would need to be some systems features implementing to make that sort of paradigm effective in a Unix style environment. I'm not sure it could be done entirely in a runtime, a lot of that state would really need to be global.
As for handling destructuring files, how useful it is really shows when you consider how easier many tasks become when you have access to such facility - even if nowadays you might expect it to be handled by extra compilation step that uses protocol buffers or something similar.
It's basically the equivalent of ORM for relational database.
But nobody does it not because it's hard or because the language doesn't support it. They don't do it because we no longer think of file system the main "database" that stores your application state.
Instead we think of the filesystem as a lower level building block for higher level abstractions (such as relational or whatnot databases)
I've seen an uptick in APL and APL-derived array languages. "Niche" would have been a better term. I would put Smalltalk in the same category.
What about some commercial languages instead which are de-facto dead, such as ColdFusion, ActionScript, Lingo, and so on...
I do... In a project I was working on for a major Dutch government organization, they were building stuff in COBOL. This was a project where we were using NLP for automated data extraction. I still find it hilarious that part of it was being built in COBOL.
I just started learning APL this year. It is still actively developed and no you don't need a special keyboard. Plus we have unicode now which makes the special symbols a non-issue these days.
Same with most of the other languages. There is Pharo and Squeak for Smalltalk, the pascal community has free pascal. Sure those communities might not be huge but they are not in acute danger of vanishing any time soon.
And COBOL is still carrying the economy.
Now some languages like ALGOL might actually be dying, sure.
Natural languages are considered dead when they lose their last native speaker. Similarly when the last person being able to use a programming languages dies, we can consider that language dead.
Which means that we have lots of languages that died at childbirth but once a programing language has managed to go over a certain popularity threshold, it is very hard to kill.
Languages don't need to win any popularity contests to be alive. Language maximalism in the sense that you need to be one of the most popular languages or you are considered a failure and dead is just silly.
niche languages have a flavour that mainstream spoils with feverish fads.. I always like to read perl or TCL forums and am surprised by the ideas and productions.
https://en.wikipedia.org/wiki/J_(programming_language)
Edit: also K something something: https://en.wikipedia.org/wiki/Kx_Systems
Someone "able to use a programming language" more directly parallels someone able to speak a language at all, by which measure Latin would not yet be dead. If you're going to draw the line there, that would be what linguists term an "extinct language".
It's hard to draw parallels to natural language because there are no native speakers of programming languages. The closest parallel I can think of is that a language can be considered dead when no new projects are started in it. Once you've reached that point, the remaining work in the language is maintenance, which is comparable to people studying and translating old Sanskrit texts.
Alternatively, a language can be considered dead when it has stopped changing and frozen in its final form.
By either of these measures a lot of these still aren't dead, but my bet would be that COBOL counts.
Didn't COBOL recently (in COBOL terms) get object oriented features?
See https://www.ibm.com/docs/en/cobol-zos/6.2?topic=programs-wri...
https://news.ycombinator.com/newsguidelines.html
Edit: that didn't work. I'm just going to take the whole 'dead' thing out.
I think the title was mostly just a pun/riff on the title of the other post linked in the first paragraph, which did claim to be a list of the most influential languages, and doesn't really make sense if read as a specific concrete claim.
I don't think this is the right comparison. A native speaker would be more like someone who learned the language as their first or maybe second language, rather than someone who can use it at all. And by that metric, these languages are pretty much dead/dying, since they mostly have no new learners who aren't into PL history.
They do have have new learners, that was my whole point. Whether they learn out of historical interest, to become better programmer in general, for a job, for research, or because they need it for a specific project does not matter. (And yes all those reasons apply.)
Take a look at companies using APL: https://github.com/interregna/arraylanguage-companies
Or look how many people use it to solve Advent of Code.
As for learning them as a first language, if we applied that criteria then most programming languages would be born absolutely dead and stay there. I don't think anyone ever learned Elm or Purescript as their first language, are they dead?
I really don't get why people make such weird claims, declaring healthy and obviously alive communities to be dead. Again, things don't need to popular to be alive.
People choose weird, novel, old, and esoteric languages for Advent of Code because it's fun and a way to stand out from the pack, or practice languages that might not ever get used otherwise. It's not evidence of a healthy community.
And yeah, I mean Elm and Purescript might not be "dead", but the fact that they are niche, largely non-general-purpose languages doesn't really mean that they are "healthy" either. I'd be willing to take a bet that both of these languages are effectively dead in 10 years.
They were sent by Jack Sparrow to settle his debt. Technical debt of course.
Is ALGOL still in use anywhere though? Is there a compiler available that runs on anything modern? I genuinely curious.
Not by choice but rather out of desperation and necessity to continue to run the mission critical code, mostly in banking, finance, and it is also occasionally encountered in government services albeit its presence has greatly diminished in the last decade or so. Young developers have no interest in learning COBOL, and the old developers have alredy died several times, have been dug out of their graves several times and brought back to the frontlines, and there are no more of those to be had. So the mission critical code continues to run on the constantly upgraded mainframe hardware, sometimes having not been changed in a few decades.
Oddly enough, despite a few large scale attempts to come up with automated COBOL -> whatever language migration / translation tools, they seem to have been largely fruitless. I think it was IBM that hired a bunch of hardcore academics in mid-2000's (?) to design and implement a COBOL to Java translator in Standard ML, and they even managed to produce something working. Unfortunately, then history becomes murky and trails off, and the eventual fate of that creation is an enigma of sorts. And, then, earlier versions of Java (before Java 8 anyway) were a horror to behold and would probably require a Java < 8 into Java >= 8 translator, so…
For something so "critical" you'd think the base salaries would start at $250k/year; but I guess we aren't at that level of desperation yet.
I think it would really help me grow as an engineer to understand how these systems are maintained, how they are tested, and how they are updated; what better way than something several decades old?
I feel like this is hard to find in the modern era, especially post 2010 onward.
Thinking about it more, I don't think I've met single person that ever touched a COBOL code base throughout my career (talking from ICs up to VPs here). It seems the "oldest" was always some early Java project from early 2000s.
And that is a problem frequently faced with fresh graduates and young developers (no disrespect to them) whose common reaction to legacy programming languages and platforms is best characterised as «ew, this is gross». Even a heftier salary package does not do the job – they just don't want to learn legacy technologies.
As a personal anecdote, it is the situation I encountered with a few young devs (3-4 years of the industry experience) in my team whom the management had entrusted to learn and support a 4GL platform that they borderline flatly refused to learn and left their employer shortly afterwards to code in React and other NodeJs frameworks. Which is regretful as the 4GL language in question was a pretty modern and good design and could have been learned to get a glimpse into good design and coding practices, the intricacies of the complex transaction processing etc. All of which could have been reused pretty much anywhere outside 4GL. In my view, it was a sorely missed opportunity.
A good learning experience, at least. I've long since moved on to more "modern" technologies.
And lazarus.
And also there was the 4th generation language movement at that time, 4GL. Defined by coding like writing English sentences, and not much algo. More akin to our no-code, low-code trend. SQL was also a child from 4GL. C/C++ was then seen as 3GL. And then we can now watch 3GL ultimately took over 4GL, at least until now, for half a century.
Tidbits.
Corrected: COBOL was 3GL.
Pascal is almost dead but still there is Delphi, FreePascal/Lazarus and Oxygen. They are all being actively developed. I just wish Embarcadero would stop charging an insane amount for Delphi.
Basic is even more nearly dead. There are still a few interesting things left like:
https://www.purebasic.com/
Up until a few years ago at least, and I still think it is the case Epic (https://www.epic.com/) had a huge amount of their codebase in Visual Basic classic.
I would not say so. The BASIC used in the Office pack is the last child of the MS-BASIC/GWBASIC/QBASIC/QuickBasic/VisualBasic lineage, is still (unfortunately?) very much alive, and probably powering a much bigger part of the modern world than we should be comfortable with.
And how can we call basic dead when VB.net is still in the tiobe top 10?
To say Pascal/Object Pascal is almost dead, is to ignore how much more used and taught the language is over known and hyped languages in the media such as Go, Rust, Swift, Julia, etc... Nobody says that those languages are "almost dead", yet Pascal/Object Pascal is as or more used than any of them.
One aspect of the confusion over if Pascal is dead or not, has to do with naming and marketing. Delphi is an IDE/compiler of the Object Pascal language. People can of heard the name Delphi, and know its still very alive, but have no idea or don't realize the language is Object Pascal. In the same context, this goes for Oxygene, and to a lesser degree, for Free Pascal/Lazarus, PascalABC, etc... People aren't aware of how they connect as dialects of Pascal/Object Pascal, and get confused by the names and marketing.
Borland priced themselves out of the market when they trasitioned into Emprise, now that is what is left as customers, the people that pay for tooling, and sadly it is hard to go back in time for hobby prices.
See Qt as well.
I have the feeling JetBrains might fall into the same trap, as I see them trying to make a Delphi out of Kotlin.
It became a recurring circular argument at that point, with rounds of
"This essay is just wrong now."
"that just shows that Delphi is not Pascal, the essay is correct for _Pascal_ as standardised";
"then why does this essay keep being raised as if it's still relevant to Delphi, when it is not?"
"That's a misinterpretation",
"yes, one that newcomers make constantly. It's harmful."
The article is probably accurate that this essay was influential. "Was it correctly so?" is a different issue.
On QKS' SmalltalkAgents: http://computer-programming-forum.com/3-smalltalk/fe67cb349c...
(amazed that there is not a single image of this software on the net.)
PL/M was a nice language. It was suited for system programming (structs, pointers). I first came across it in some introductory programming book I bought from a second-hand crate. A lot of my early programming lessons came from that book, even though I had no access to a PL/M compiler. I have no idea who wrote it, or what its title was.
[Edit] My notion that PL/M was a cut-down version of PL/I was clearly wrong; I never used PL/I, the closest I got was reviewing a few documentation pages.
In the long run: Objective-C will be gone in 20 years, but Ruby won’t. Outside of ObjC interop facilities, Swift will retain some of Objective-C’s Smalltalk heritage, as one of many influences.
In fact, at the very bottom of the article, there is a link to the Encyclopedia of Programming Languages with over 8000 entries. The influence of Smalltalk’s “everything is an object” on Objective-C and Ruby is probably in there somewhere.
Disclosure: I wrote Ruby professionally for over ten years, and learned the basics of OOP with ObjC back in the 90s. I get the significance of Smalltalk’s object model.
Of course I get all of that; however, the author also chronicled the influence of these languages and certainly Objective-C use of Smalltalk's object model, a language that provided macOS and iOS such a competitive advantage for many years, it's probably worth a mention.
Same here. There's a lot of amazing things which we have yet to learn from the 'also ran' systems of history.
I'm familiar with all but a couple of the languages in his list, and wrote code in most of them, although in some cases not code that ever went into a product or production environment. ML and CLU, though, I've never touched.
Its not dead but you will never see it trending. Its just a niche language as most of the languages at the post are.
Also, I believe people place way too much emphasis on "popularity" of a language. If a language has enough traction to stay alive it can be valuable unless you're doing the most generic web dev stuff around. Heck there's cases where Perl still outshines modern competitors.
This is a huge difference compared to something like Java or Python where "everything is a class and a class is everything", and if you desire implementation hiding you sort of automatically also opt into get encapsulation and subclassing and the rest of it.
When you learn the mechanisms individually, object-oriented programming starts to make a lot more sense! Ada is worth looking at just for that experience alone! Then the other things are a bonus.
This has been done with the Ravenscar profile (for real-time work) and, most famously, the SPARK profile (for formal verification).
(There isn't integrated support for user-defined style guide conformance though. From the perspective I've used here, MISRA C is both a subset and a style guide.)
Some ancient documentation on RavenScar: https://gcc.gnu.org/onlinedocs/gcc-4.5.4/gnat_rm/Pragma-Prof...
https://en.wikipedia.org/wiki/Mesa_(programming_language)
>Mesa and Cedar had a major influence on the design of other important languages, such as Modula-2 and Java, and was an important vehicle for the development and dissemination of the fundamentals of GUIs, networked environments, and the other advances Xerox contributed to the field of computer science.
Demonstration of the Xerox PARC Cedar integrated environment (2019) [video] (youtube.com)
https://news.ycombinator.com/item?id=22375449
Computer History Museum: Eric Bier Demonstrates Cedar
https://www.youtube.com/watch?v=z_dt7NG38V4
Mark Weiser and others at Xerox PARC's ported the Cedar environment to Unix, which resulted in the development of the still-widely-used Boehm–Demers–Weiser conservative garbage collection.
https://news.ycombinator.com/item?id=22378457
I believe that stuff is the port of Cedar to the Sun. Xerox PARC developed "Portable Common Runtime", which was basically the Cedar operating system runtime, on top of SunOS (1987 era SunOS, not Solaris, so no shared libraries or threads, which PCR had to provide). He demonstrates compiling a "Hello World" Cedar shell command, and (magically behind the scenes) dynamically linking it into the running shell and invoking it.
Experiences Creating a Portable Cedar.
Russ Atkinson, Alan Demers, Carl Hauser, Christian Jacobi, Peter Kessler, and Mark Weiser.
CSL-89-8 June 1989 [P89-00DD6]
http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-89-8...
>Abstract: Cedar is the name for both a language and an environment in use in the Computer Science Laboratory at Xerox PARC since 1980. The Cedar language is a superset of Mesa, the major additions being garbage collection and runtime types. Neither the language nor the environment was originally intended to be portable, and for many years ran only on D-machines at PARC and a few other locations in Xerox. We recently re-implemented the language to make it portable across many different architectures. Our strategy was, first, to use machine dependent C code as an intermediate language, second, to create a language-independent layer known as the Portable Common Runtime, and third, to write a relatively large amount of Cedar-specific runtime code in a subset of Cedar itself. By treating C as an intermediate code we are able to achieve reasonably fast compilation, very good eventual machine code, and all with relatively small programmer effort. Because Cedar is a much richer language than C, there were numerous issues to resolve in performing an efficient translation and in providing reasonable debugging. These strategies will be of use to many other porters of high-level languages who may wish to use C as an assembler language without giving up either ease of debugging or high performance. We present a brief description of the Cedar language, our portability strategy for the compiler and runtime, our manner of making connections to other languages and the Unix operating system, and some measures of the ...
https://en.wikipedia.org/wiki/Eiffel_(programming_language)
It was also heavily negatively influenced by C++. If you like reading lots of hilarious ideological, syntactic, and semantic ranting and raving about how terrible C++ is, pick up one of Bertrand Meyer's original Eiffel books (from before Java, which is another negative reaction to C++ in a different direction), you'll love it!
Where I think it broke down is with multithreading, because you can't reason about preconditions and postconditions of a method if there are other threads banging away at it. But maybe that's been solved since when I read the Eiffel book.
Sather is an open source language that was originally based on Eiffel, but developed in its own direction. Named after the Sather Tower at Berkeley instead of the Eiffel Tower in Paris.
https://en.wikipedia.org/wiki/Sather
The Differences Between Sather and Eiffel
https://omohundro.files.wordpress.com/2009/03/omohundro91_sa...
You say that like it stayed there. Ada has been updated and refined continually since the first standard in 1983. Ada 2012 is the latest approved, and Ada 202x is in review.
Just like Fortran (see Fortran 90, 95, 2003, 2008 & 2018).
For example, Ada allows to return stack-allocate arrays with variable number of elements. One can emulate that in C++ with various arena classes, but the resulting code is not that efficient and the usage is much more complex.
https://en.wikipedia.org/wiki/Beltway_bandit
https://www.youtube.com/watch?v=OhxIhwKhMeE
I stayed there only for a month, i hated the objective of the job, I hated the UI custom library, I hated the way I had to test my code, I hated how much of disengagement I had to do from my morals to work on 'defense' projects.
Does anyone else still remember how JavaScript prototypical inheritance was touted as a “good” idea?
Short answer: it's more memory efficient than a full-blown OOP system.
I was pretty active in the Newton MessagePad community back then and I knew lots of Newton developers; they loved NewtonScript and raved about prototypical inheritance.
[1]: https://news.ycombinator.com/item?id=34047775
It was one of several big language influences for Brendan Eich when he knocked out Javascript in a hurry a few years later.
I also would say that ruby is a future mostly-dead language, but I don't want to sound too controversial.
Aren't you just saying it anyway? Why do you think this?
It's my understanding that ruby rose to prominence mostly because of ruby on rails, now that RoR is in a downward trend I think ruby will follow the same trend until it's reduced to a small community of enthusiasts in the same way that happened to perl.
(This is not to talk about the merits of the language, which it's really orthogonal to popularity).
This is wrong. Simula 67 was the first object-oriented programming language; though the term is said to be coined by Alan Kay who specified Smalltalk-72; but he understood and still understands object-orientation differently than we understand it today; our understanding of it today is more like what Simula 67 introduced; remarkably, Smalltalk-76 represented a significant departure from Smalltalk-72 toward the concepts already known in Simula 67; the primary difference of Smalltalk 76 from Simula was dynamic typing and the conception of even simple types as classes. Simula 67 was still actively used in the nineties (e.g. as a teaching language at Stockholm University until 1997). The performance was comparable to that of C++ or Pascal, definitely faster than Smalltalk on comparable machines.