Most(ly dead) Influential Programming Languages
hillelwayne.com
hillelwayne.com
I don't know if Self was ever commercialized; I do know that once Java was released Sun focused much of its attention on promoting Java at the exclusion of other object-oriented environments that Sun invested in (such as the OpenStep Objective-C API, which was actually jointly developed by NeXT and Sun). But Self is probably one of the most influential programming languages; it's just a shame that this language was never brought up in any of the computer science courses I've taken.
Before Sun cannibalised the Self team into Java, it was actually slow as a snail.
Another fun fact, a reduced version of Self was used the programming language for most of the Apple Newton, because Dylan was taking too long to get off the Ground.
A word processor could include for instance PNG images even though PNG was not even invented when the word processor was created!
https://www2.eecs.berkeley.edu/Pubs/TechRpts/1986/CSD-86-287...
However, I don't think SPARC would be saddled with tagged integers were it not for SOAR.
Java only became fast after the HotSpot server compiler, which was written by Cliff Click (and Micahael Paleczny / Christopher Vick) and takes a different approach than Smalltalk / Self compilers.
Here's mine: ES6 classes are wildly smart. They provide the benefits of prototypical inheritance--you can just reach into the thing and do what you want to do!--while making it way easier for many developers to read and parse in short order, while reducing the difficulty spike in moving to JavaScript (or, today, TypeScript).
"Pandering". Right.
I can write old-style object prototypes. It makes my eyes bleed and makes me make more mistakes. So I'm just not gonna do that anymore.
Anyways, let's not act like ES6 classes aren't without their slew of issues, obscure syntax, and most importantly, problems when it comes to transpiling and backwards compatibility:
https://medium.com/@WebReflection/a-case-for-js-classes-with...
It's 2020. Things move on.
function f(x) {
a[x] = "whatever"
for (e in a)
if (a[e] == x)
return e
}
Edit: To clarify, Clojure is mostly a dead language that didn't have any innovations by itself, but it did influenced many programmers(the creator is good at marketing). It helped push forward the FP mindset into the users of other mainstream languages(js, python, java).
A stepping stone to more mainstream languages perhaps? I hardly saw a Clojure program so please elaborate.
Like most(ly dead) languages, it still has its followers, in the case of clojure, mostly a cultish group (my impression from r/clojure and other forums).
Going back to 2010 we see less than 500 respondents and only 27% using it for work. A charitable assumption is that it grew substantially between 2010 and 2015 and held steady between 2015 and 2020.
However this isn't ultimately the most useful metric. Would you for example select a restaurant based on the reviews and the cuisine or to total annual revenue of its parent company. If your metric suggests you forego surf and turf at a local diner in order to eat a Whopper you may be asking the wrong questions.
For your consideration here is a better one. A language is alive when its ecosystem is likely to receive enough interest and talent to continue to develop enough to allow its users to continue to accomplish useful goals. Being embedded in 2 of the top platforms and being able to reuse those libraries is a factor. Relying on these host platforms means that it can remain alive indefinitely while being useful to only thousands instead of millions as long as it drives enough interest to pay the salaries of the dozens who develop the core and the hundreds that write useful tools.
For instance, you can define a dynamic inheritance : your inheritance can be defined by a function which return an object - so, a prototype - among several.
The author of this language explain me that Self was one of the most important day in his life ;-)
- Influenced C's type system. I'm just going to quote Dennis Ritchie on this: "The scheme of type composition adopted by C owes considerable debt to Algol 68, although it did not, perhaps, emerge in a form that Algol's adherents would approve of. The central notion I captured from Algol was a type structure based on atomic types (including structures), composed into arrays, pointers (references), and functions (procedures). Algol 68's concept of unions and casts also had an influence that appeared later."
- Influenced bash's syntax (fi, esac)
- I'm not sure if this counts as an influence or not, but objections to Algol 68's design lead Niklaus Wirth to revive his earlier proposal for a new version of Algol, called Algol W, and ultimately evolve it into Pascal.
ALGOL-68 was loved by people who would have never used ALGOL to begin with (and they didn't start doing so with ALGOL-68).
It was difficult to write compilers for, slow & far too complex.
And like go, it's loved by people who don't know ALGOLs and hated otherwise.
Go is basically Oberon with C-ish syntax, and Oberon is probably the Wirthiest of Wirth languages, basically everything Wirth thought was good distilled into a single language. And given that Wirth's whole family tree of languages exists because he objected to Algol 68 so hard he walked out on Algol...
Although Oberon not only had Oberon-2 as successor, it had Active Oberon, Oberon.NET, Zonnon, Component Pascal and Oberon-07, the later with multiple revisions.
But if Perl can be credited with kick starting the dynamic language boom (Python, Ruby) then it have been massively influential.
Edit: Maybe also Perl's Configure (crazy wide cross-platform portability) and CPAN. They were pretty ahead of their time.
Smarty could possibly take credit for inspiring some of the template engines out there also.
A lot of subsequent languages have focused on readability, partly as a reaction to some of the....unique things came up with in Perl.
If I dig into the gripes about the syntax, it's usually use of the implied $_ variable, wide use of sigils ($, @, %), derefs of complex data structures (hash of lists of hashes, etc) or regex syntax that people are talking about.
Am I the only one who finds perl data structures simple and consistent? Once I understood the difference between () and [] (or {} for hashes), it was easy (too easy, some might say!) to construct complex data structures.
$foo->{bar};
$$foo{bar};
And quoting or not the key, etc. Slices and individual elements, etc. Probably looks like line noise to outsiders when you have a long one using parens to grab a specific array element, combined with $$ and so forth.
Having those constructs so effortlessly available with a minimal amount of syntax spoiled me. To this day, I would likely still prefer to do any kind of complicated ETL involving deeply nested structures with Perl.
Perl, on the other hand, looks just like a programming language would if it was the only way we could talk to computers, day in, day out:
- Implicit "it" variable,
- Very brief syntax for common operations,
- More than one way to say things,
- Context determines the meaning of things, and so on.
It's not at all what one instinctively thinks of as "a programming language drawing from natural languages", but on closer inspection (and daily use) that's exactly what such a thing would look like!
react {
whenever signal(SIGINT) {
say "Aborted";
done;
}
whenever Promise.in(3) {
say "Timed Out"
done;
}
}
say "Goodbye";
Another significant experiment in Perl was embracing the idea that everybody write in their own personal dialect or subset of the language. Again, the conclusion seem to be that this is a really bad idea since someone else will have to maintain the code eventually. But nevertheless it is valuable that the experiment have been tried. Python took some important lessons from that.
> - More than one way to say things
I respect that others may disagree, but I actually find this to be a major disadvantage in a programming language. From a readability perspective[1], having more than one way to express the same task is in my opinion a bad thing. As a trivial example, Perl supports both pre- and post-conditionals:
if something then x = 1
x = 1 if something
I think this is one major reason languages like Perl or C++ are often considered hard to read. Having so many ways to express the same thing means a major mental load until you've figured out what is trying to be expressed.
[1] By now we've all come to agree that easy reading of code is far more important than easy writing of code, right?
See what I did there? Same meaning, different order of clauses. Emphasis ended up on different parts of the sentence! This is a very powerful out-of-band signaling path to control how the reader interprets the literal words, and being used to Perl where we also have it, it is weird to not have it in other languages.
Sometimes the actual predicate is the important/interesting bit, in which case putting it first makes sense: `if (user_is_underaged) return;`. Sometimes the predicate is not as interesting as the expression it's conditioning: `say "message" if debug_mode;`.
if $you-are-hungry { make-a-sandwich() }
make-a-sandwich() if $you-are-hungry;
if you are hungry make a sandwich
make a sandwich if you are hungry
If you pay attention to how people use those different forms in english, you will also notice that the infix form of “if” tends to be used for simple short sentences. Which is exactly how I use it in Perl and Raku.
sub factorial ( UInt $n ){
return 1 if $n == 0;
return 1 if $n == 1;
return $n * factorial($n - 1)
}
sub factorial ( UInt $_ ){
return 1 when 0;
return 1 when 1;
return $_ * factorial($_ - 1)
}
sub factorial ( UInt $_ ){
return 1 when 0|1;
return $_ * factorial($_ - 1)
}
The thing is, that also reads fairly well in english.
return one when [it is] zero or one
> Alice: What result should we give the user?
>
> Bob: Return one when zero or one.
> Otherwise multiply it by …
The problem with that is that you aren't communicating with a computer. You are communicating with everyone that is going to read your code. Reading a technical manual can be very tiring for even the most stoic of readers.
I prefer to read a well written novel. Good Perl and Raku code often reads more like a novel than a technical manual. Even when it is kept very precise about its semantics.
Which means that when I am done doing something in Perl or Raku, I want to continue doing more of that. I don't want to stop.
Sometimes I will find myself re-reading the same line repeatedly at 3am.
---
Further, note how I used the infix form of “if”.
return 1 if $n == 0;
return 1 if $n == 1;
It is very common to use it in this manner. Where they sit at the very beginning of a function as a kind of guard clause. The real important bit is the right part of the lines. Which actually stands out more than the left half, because it is closer to the center of the screen.
After those two lines, we know two things about `$_`. It is neither a `0` or a `1`, because we already dealt with both cases. So we don't have to worry about them in the rest of the function.
For the most part, when I see a line like that I know that I can safely skip over it. That is because it is almost only ever used for that type of thing. As a way to deal with simple cases early in the lifetime of a function. It also means that I can very quickly glean the information I need for that very same reason.
---
People tend to have a lot of bad things to say about Perl and Raku.
Almost everyone who has used them enough to get comfortable with either of the two languages would say just about the opposite to most of those things.
Basically, it's bad in theory, but it's good in practice.
Reminds me of a video “Clay Shirky on Love, Internet Style” https://www.youtube.com/watch?v=Xe1TZaElTAs (9m14s long)
Particularly this line:
> And it was at that moment that I understood what was going on. Because they didn't care.
> They didn't care that they had seen it work in practice, because they already knew it couldn't work in theory.
---
I very much agree that it is far more important to be easy to read. Which is why I find Perl and Raku to be awesome.
I can write things in the most readable way for a person as possible, rather than the only way the compiler can understand.
Raku (formerly known as "Perl 6"), PHP, Ruby and PowerShell were directly influenced by Perl.
Also you may be correct about it kicking off the scripting languages' popularity, and as someone else mentioned it is also responsible for cgibin.
It might sound strange to modern eyes but there was an time when Perl was considered elegant and robust, but then again very few young people have ever experienced the horrors of trying to write portable shell code for commercial Unix, perl was on the other hand almost completely identical regardless of what variant of Unix you happened to be running, and vastly faster then sh/awk at a time when even expensive systems could be slow by modern standards.
For modern day script writers Ruby and Python have all but replaced perl even though that's not stopping the enterprise from keeping their perl codebases alive and kicking for the foreseeable future, but even there it's being challenged from bellow by the fact that bash and gawk have become fairly universal on Linux systems and hardware fast enough that regex performance rarely matter.
That said, once Python 1.5.2 (or so) hit, Perl was done for. It was simply better, and there was no reasonable way for Perl to recover the lead, or even really coexist. Perl had a lot of momentum and took many years to decline, but that was the tipping point, in my mind.
It remains to be seen whether Python3 will displace Python2. :-)
Sure the percentage has gone down, but the count has gone up.
And unfortunately, the brilliant minds that worked on Perl 6 spent so much time rewriting the compiler tool chain and basically treating just that part as a research project, that it was incredibly difficult to actually contribute and push the project forward. Couple that with a spec that never seemed finished and a community that tore itself apart because of assholes, and it was a perfect storm to remove Perl from prominence.
Anyway...
Somewhat deserved, surely?
Perl is like the Continuum transfunctioner, "Its power is exceeded only by its mystery." ;-)
Much of our "duct tape" is unmaintainable code with undocumented aracne regexes everywhere, single-letter variables, and 1990s-era flow control. Nothing you'd find in Modern Perl is in our duct tape. Ultimately, the fastest turnaround on "we need feature X added to Perl script Y" is going to be "rewrite Y in Python, add feature X" because actually extending the Perl code has proven to be a nightmare.
(and as a side note, most of these Perl scripts ran out of cron on various boxen scattered across our network, and as I've been rewriting them I've also been removing them from cron and putting them in our centralized setup that uses Jenkins to run scripts, pulled out of git, inside Docker images on a schedule)
It showed how to make a minimal programming language that runs in a very small amount of space with just a stack. And did a lot to popularize RPN notation.
Even if you do not write in Forth, you can still benefit from knowing the ideas. For example I could not have written my answer at https://stackoverflow.com/a/60817908/585411 if I did not know the ideas of Forth.
When I took programming in high school, we started with TI-BASIC on TI-83 calculators for about a month, as my programming teacher felt like this best replicated his experience learning programming on a TRS-80. I tend to agree, and this is a great use of BASIC. It's the default programming interface on a widely used computer to this day.
We then moved to VB6 for our "serious" programming, although we also did JavaScript and Java.
My first programming professionally was done in an office setting at a temp job using VBA to help with some Excel work. And then my first job as a software engineer, even though I wasn't writing it, did have some Visual Basic.NET floating around (most of my work was in C#).
It was just enough of a push. Small programs and games were fine and I actually got really used to the keyboard (I can still type on it pretty quickly these days). For longer programs I def. remember wanting to program with more monitor real estate and not having to rely on GOTOs. That's how I started to learn Python, which I still use daily.
It turns out, you can actually write programs in TI-BASIC on a computer, and sync the file to the calculator with the usb connector.
I used to charge kids in my class for copies of my games (Snake, and a Zork-esque text adventure). a lot of early business lessons there, in retrospect.
> Smalltalk wasn’t the only casualty of the “Javapocalypse”: Java also marginalized Eiffel, Ada95, and pretty much everything else in the OOP world. The interesting question isn’t “Why did Smalltalk die”, it’s “Why did C++ survive”. I think it’s because C++ had better C interop so was easier to extend into legacy systems.
Maybe it's linked to performance? Even today some application are rewritten from Java to C++ (or clones are made) to gain performance (like with Cassandra and Scylla).
With the high prices of Smalltalk and Objective-C environments, Java attracted a lot of companies and developers who wanted an object-oriented programming language that provided some of Smalltalk's benefits (e.g., garbage collection, memory safety, a rich standard library) without having to shell out the cash for a Smalltalk implementation.
This in 1990 - 1992.
Emphasis on "NO". Affordable doesn't cut it.
If you can't download it from somewhere for free, something else will be used by students that will later determine what they'll use at their startups or companies.
Even better if it's legal to download for free.
I say that it was an additional barrier to entry which got more significant the later we are in the 90s. That it was free was a significant boost for the popularity of Java (probably also the free JVM from Microsoft was a significant contributor).
In the early 80s you always had a programming language for free with your computer and often, those manuals were not bad either as that was seen as an additional selling point for the hardware and that's why the hardware producers did it.
Knowing no-better, $0 seems better to most.
The Smalltalk vendors provided student licenses / educator licenses.
Back in 1998, "…the largest object-oriented course in the world: the Open University’s new introduction to computing, for which over 5,000 students have enrolled for its first year. The course introduces computing from a systems-building stance specifically, through object technology, Smalltalk and our own adaptation and extension of Goldberg’s LearningWorks programming environment."
[pdf] https://www.academia.edu/33568403/An_Object-oriented_Approac...
Here it is running under Windows 10 (thanks to otvdm/winevdm that allows running 16bit programs in 64bit windows): https://i.imgur.com/r5aQNyJ.png
I had access to C/C++ in high school on a PC only because my father ran an engineering group and brought home a VC++ license for us. I didn't get to use it that much before heading off to college.
I mostly used BASIC early on cause we had it free with the first 2-3 PCs we had. By High School I had gotten my hands on Turbo Pascal for free, maybe again through my father. High School classes were in Pascal. Turbo Pascal blazed and worked even on our 286 IIRC, which had minimal graphics capabilities. Even once we got a 486 TP was so lightweight compared to booting up windows that probably helped it's popularity for people who were stuck on PCs at home.
As soon as I went to college I always had access to C/C++ and that's what classes were taught in, and by Winter 95/96 we were all getting linux up and running and started having access to all the GNU stuff for doing our work.
There were a couple commercial implementations, with ISE being the dominant player. I bought a copy, but it wasn't cheap.
The open source SmallEiffel (later SmartEiffel) compiler by Dominique Colnet (and others) from loria.fr [1] didn't implement implement some parts of the language until the late 1990's.
It never had a big community.
Yes, when a well funded corporation gives away programming language runtimes and development tools — that puts language and development tool vendors out-of-business.
However, it takes a large amount of money in order to develop something like a modern-day Symbolics Genera. Where is the money going to come from? There seems to be little room in today's marketplace for modern-day equivalents of ParcPlace or Symbolics, or even Borland for that matter, since free tools are good enough for many developers. Inexpensive Unix workstations from Sun and DEC helped kill the Lisp machine, and Linux on ever-faster and ever-cheaper x86 PCs helped kill the Unix workstation market; good-enough-and-affordable seems to do better in the marketplace than polished-and-expensive. It seems to me that development tools and operating systems seem to be either the product of research organizations or are "subsidized" by companies where developer tools and operating systems are not their main businesses unless the operating system is a monopoly.
I don't see an easy way around this, though. Maybe if someone like Alan Kay or Richard Gabriel visited a FAANG campus and convinced its engineers to build their infrastructure on top of a new object-based operating system, we'd finally get a modern, full-featured Smalltalk or Lisp operating system that's at par with the commercial Smalltalks and Lisps from the 1980s and 1990s....
While not the same, it is the most mainstream stacks that are somehow close to those ones.
Of course, it may have felt productive — lots of mousy interaction and tight focus engagement — without being so very productive.
> … development tools … product of research organizations or are "subsidized"…
One factor is determinism. GC introduces unpredictable (non-deterministic) time latency, making GC languages generally unsuitable for real time programming.
Another is size efficiency, Java programs have a well-deserved rep for using lots of memory. That isn't a good mix for smaller/embedded systems. Java also carries along a large runtime, although Graal and other efforts are addressing this.
The final factor is that C++ is perceived (rightly or wrongly) to be an "improved C". As the heir apparent to C, C++ has a ton of mindshare and momentum. Rust is now providing a major challenge, one I hope it wins! (Honorable mention to D, which is a nice language as well.)
See also https://aplwiki.com/wiki/Array_model.
For those that don't recognize his username, I think he works for Dyalog in APL implementation. Is that right?
https://www.sacrideo.us/paper-is-dead-long-live-paper-progra...
As far as the underlying concepts, speaking as someone who has experimented recently with Joy (one of the concatenative languages you mention. although it wasn't directly influenced by Forth, I think, it's a case of convergent design), I think it's a shame it hasn't been more influential.
The time may come: check out Conal Elliot's Compiling to Categories.
Maybe you already knew this, but there are lots of great articles about Joy in nsl.com, and there is also Thun: http://joypy.osdn.io/ (which someone suggested me around here).
Ok, you can argue about the definition of "mostly dead", but whatever you decide these two just aren't in the same category as the others on this list.
It's easy enough to understand — just look at when they were very much alive.
"UbiquitousApplications:Embedded Systems to Mainframe"
Video Games. From around 1999 to recently, C++ was the language of game development. It only recently came under serious threat, from C#.
Video games community is very luddite in what concerns adoption of technologies, they usually only move forward when the platform owners force them to do so.
Many moons ago, C, Pascal, Modula-2, Basic were seen as Unity is seen nowadays, naturally real game devs had to use Assembly, specially to take care of the special purpose graphic and sprite engines.
Playstation 1 was probably the first console that force them to start using C instead, while on 16 bit.
So slowly everyone accepted that doing games in C, Pascal and what have wasn't that bad.
C++ only became kind of accepted years later, and even then it was more "C compiled with C++" than anything else.
The major boost for C++ were the OS vendors for home and office computers, Apple, IBM and Microsoft, alongside Zortech, Borland and Watcom, with their full stack C++ frameworks, something that ironically C++ has lost (OS C++ SDKs where it has the front role).
I worked as a C++ programmer from something like 2001 - 2010, and all video games companies used it. I wouldn't have learned how to program properly in it without the games experience I gained.
Until 2001, you had Mac OS, Windows, OS/2, BeOS, EPOC, Telligent, ill fated Coplad, SOM, COM, CORBA, Newton all using C++ as the main programming language for enterprise applications.
Had Apple, Microsoft, Google decided otherwise and game community opinions wouldn't matter.
That's ludicrous. Because of game industry demand for programmable graphics pipelines we now have the modern AI industry. You're welcome.
Because of game industry demand for high-performance, low-latency programming languages C++ stuck around. You've scoffed that it's basically used as C-in-a-C++-compiler, but that's because the steering committee seems to be completely out of touch with what people want C++ to do.
Worth watching: https://www.youtube.com/watch?v=qYN6eduU06s
Sure, game devs ignore modern C++ and the STL, but they do so because modern C++ and the STL, as defined, are not zero-cost abstractions. If we wanted a language with a predictable 30% overhead we'd use C#, and we do, but when it matters we want something where the core language is without serious burden in its use.
Why use C++ if zero-cost abstractions aren't important to you? Honestly, what's the value? You've already given up frames, you may as well accept some to handle memory management, continuous garbage collection, ownership safety and so on.
Yes the games industry demand for better hardware has driven mainstream computing to adopt them.
And naturally we got shader Assembly, followed up by C dialects like Cg and 3DLabs initial GLSL implementation.
C++ on the GPUs happened thanks to CUDA and C++AMP.
Even Vulkan would keep being a bare bones C API if it wasn't for NVidia's initial use of C++ on their samples SDK.
Hardly any programming language innovation being done by gaming companies, with exception of snowflakes like Naughty Dog.
I think this is an unfair assessment. "Real devs" had to use assembly language because when targeting consoles and low-end home computers, this was the only really performant option for a long time. For a lot of types of games this doesn't matter so much, but there's a long ongoing trend in big titles really trying to cram as much visual fidelity as possible into the target machine.
Same deal with C++ today. You can use Unity of course, no one is any less of a "real game dev" because of it, but it's simply not an option if you want to work on cutting edge tech for AAA titles. There are tons of other things you may want to work on, other boundaries to push, which I think is why Unity is such a popular option. But I think it's unfair to simply chalk it up to luddism. Present the available alternatives that compare favorably in terms of development speed and performance for non-critical software instead.
While the demands of gaming industry have always driven the hardware evolution on mainstream computing, most studios only move to newer programing languages when the platform owners force them to do so.
The gaming industry is not known for being early adopters of new software stacks, and many studios would to this day actually use pure C instead of C++ if the console vendors would give them C based SDKs.
I'm not in agreement with your assessment that the industry is conservative; it is largely responsible for pushing graphics into programmable pipelines, for instance, and the vendor-preffered language lock-in for consoles hasn't really been a factor since the Indie revolution took the industry by storm.
I get the impression you're an outsider looking in, relying on decades out of date personal experience to understand what they see.
Naturally Kotlin and Swift are in mobile games, they are part of the user space official SDK languages
Also, thumbing your nose at Indie games is odd, considering the sales they've enjoyed and the extent to which the industry has adjusted to adapt to their surge in popularity.
I can't imagine Nintendo in the 90s treating indie devs the way it treats them today.
C++ doesn't have full access to OS APIs and some integration is always required.
Adoption is driven by platform owners.
My point is that it isn't a question of new vs old. It's a question of fast vs slow. There was a reluctance to adopt e.g. Pascal because the popular implementations favored convenience of implementation (UCSD Pascal, which generated code for a virtual machine) or speed of compilation (Turbo Pascal, a single pass compiler) over the quality of the generated code. For long, it was the case that C compilers generated code that couldn't nearly measure up with hand-written assembly.
I've seen plenty of old games and demos written in C and Pascal. Almost always using these languages as organization frameworks for executing snippets of in-line assembly where speed actually mattered.
So what are the alternatives to C++ today? A lot of game developers use Unity and write code in C#. Unity itself is of course written almost entirely in C++. Rust? Well, if you can figure out exactly when memory is freed, which Rust can make a bit of a puzzle. Zig seems like it could be a nice contender, at some point in the future. Swift? If you can accept the cost of reference counting.
All these are great options IMO, just perhaps not for the low-level work that goes on at the big high tech game studios. The closest thing to a contender is maybe Rust. The game industry's reluctance to adopt Rust is hardly unique to them.
A few years after the Playstation gained prominence would be around 1999; and shortly thereafter Unreal Engine took the industry by storm.
EASTL is how old, now?
I still remember Carmack's comments of his initial forays into using C++ for idtech.
I don't think it's fair to shrug us off.
It's hard to believe how fast things changed and desktop apps were replaced by web apps...
There are domains, like laboratory automation devices in life sciences where browsers are persona non grata in air gaped environments, plus they lack the necessary hardware integration.
So between daemon + browser and a proper desktop application, most customers still rather have a nice desktop application.
Mostly business type front ends and it actually mostly makes sense for that purpose. But there are huge areas where browsers play no role.
(Writing a JVM in just Java is doable, and some research JVMs have done it, but that approach hasn’t yet been fully productionised.)
Well, I learned something new and I spend a lot of time reading about PL (and even teach undergrad PL!). Had never heard of CLU before.
We ignore the past. I've worked with people who hadn't heard of Alan Kay. I worked with a guy tasked to revamp an expert system who had never heard of Prolog.
One specific dot this article helped me connect (thanks article) was that Barbara Liskov of CLU is the same namesake of Liskov's Substitution Principle, which definitely has made broader waves in mainstream OOP consciousness among programmers. It originated in a paper two decades after a lot of the CLU work so it isn't directly a part of CLU's own influence on the world, but it is quite probable that CLU's influence is deep inside the formation/elucidation of the Principle in that Barbara Liskov was clearly thinking about the problem area for decades, and in some cases decades ahead of colleagues and practical applications.
http://www.pmg.lcs.mit.edu/CLU.html
I would already be more than happy if Go 2.0 generics would be CLU like, no need for something more fancy.
It compiles very fast to native code, has properties with implicit setters/getters, null-safe strings with mutability xor aliasing, function and operator overloading.
It is really amazing
...but yeah, it was definitely doing pretty good throughout the 1990s.
You can absolutely go to town arguing whether or not their definition of influence makes sense, though.
(CF is a language on my list of hopes to never see again.)
More languages should also steal Verilog's use of _ as an optional digit separator. It's just arrived in C# 7.
Erlang has the full stop '.' as expresssion/statement terminator [2].
[0] https://en.cppreference.com/w/cpp/language/integer_literal [1] https://docs.swift.org/swift-book/ReferenceManual/LexicalStr... [2] https://erlang.org/doc/getting_started/seq_prog.html
I like those features too! I'm glad they are coming to contemporary languages.
It reads really well, because it also uses colons as combinators, with higher precedence than the semicolon. But it does not map well into other paradigms.
That’s something people complain about when looking at Erlang code. Thanks to its Prolog heritage, it uses commas, semi-colons, and full stops to terminate statements.
It’s actually very easy to remember which is which, despite the general angst, because they are directly analogous to those punctuation marks’ usage in English.
Commas indicate a continuation of statements, semi-colons separate clauses within a function, and full stops complete a function definition.
I think E was more influential than its distribution would suggest.
ReasonML therefore is much closer to the revised OCaml syntax (a failed previous alternate syntax) than it is to its own language.
(ducks for cover)
I know someone writing Smalltalk on a daily basis for this system: https://kyma.symbolicsound.com/
If we're only talking about influential languages, I'd agree with you and put lisp on the top.
Am I missing something, how is this different from a map?
3 3 3 ⍴ ⍳10
1 2 3
4 5 6
7 8 9
10 1 2
3 4 5
6 7 8
9 10 1
2 3 4
5 6 7
M ← 3 3 3 ⍴ ⍳10
M*M
1.00000E0 4.00000E0 2.70000E1
2.56000E2 3.12500E3 4.66560E4
8.23543E5 1.67772E7 3.87420E8
1.00000E10 1.00000E0 4.00000E0
2.70000E1 2.56000E2 3.12500E3
4.66560E4 8.23543E5 1.67772E7
3.87420E8 1.00000E10 1.00000E0
4.00000E0 2.70000E1 2.56000E2
3.12500E3 4.66560E4 8.23543E5
How many maps did you want?
It's notable not only for being the Lingua Franca of scientific computing through at least the '80s, but also for breaking ground in programming language technology, starting right at the beginning -- the Fortran I compiler, for the IBM 704 in 1957, was the first to have an optimizer (and the technical papers on that compiler introduced terminology which has since become standard to the field -- e.g. "basic block").
Same with COBOL.
Something I always wonder about COBOL, since it has so little influence on other languages, is if there are good ideas that we missed out on.
Done my 10k lines batch COBOL. It is a waste of life. Verbose. C is better but unfortunately it is not very io. Still ...
batch COBOL with mainframe parallel io sub-processor helps a lot.
May be the cics where 1000+ users can use a pc (3-5 mips even emulated) with 16MB is something unusual.
At one point, like 10-15 years ago, I knew experienced well paid COBOL programmers being laid off and being replaced by kids fresh out of school. And then CS programs, if not outright stopped, at least greatly reduced teaching COBOL courses. And no one coming out of school learning Java and Python and Node wants to write COBOL.
And then old timer COBOL programmers started retiring, but companies (especially banks) were not replacing their existing mainframe infrastructure. So now you have a gap between supply (COBOL programmers) and demand ( mostly banks), to the point that retired programmers are doing part time work for $200 an hour. Here's an article from 4 years ago;
https://www.reuters.com/article/us-usa-banks-cobol/banks-scr...
Startups and small companies can ignore anything that isn't new and shiny; companies processing billions of dollars/transaction know better.
Am I misremembering and it was just an urban legend/marketing from C compilers? Thinking back it doesn't seem logical that C would offer any significant performance benefits - both Pascal and C were compiled down to machine code and had approximately the same levels of abstraction.
In MS-DOS days, if you actually cared about performance, a macro Assembler was the only way to achieve it.
To share a similar anecdote I was so proud of myself having created my own mouse support unit, that I then used to plug into a couple of BGI based applications.
What was probably the case is that there were more C compilers so some of them produced better code than Borland's.
Is there a kind of web archive of programming languages? Can we make sure their compilers, interpreters, etc. are not lost? Sure, there are issues of them being proprietary, or needing some virtualization to run; I'm just wondering.
Is that true? What was the complexity about? I've never done COBOL, but I was always under impression that it was quite straightforward in its infamous clunkiness, lacking lots of constructs that've been obvious for decades now
Why isn't Prolog on the list then?? :O
I guess constraint solvers like Z3 are in the same category kind of(?), but I don't know if/how their syntaxes are related.
BASIC 1970 high school computer hacking
LISP 1972 MIT A.I. course
APL 1973 MIT circuits course
PL/I 1973 MIT systems programming course
OS360 Assembly MIT systems programming course
FORTRAN 1974 MIT physics research
C 1976 Stanford research
PASCAL, ObjectPASCAL 1984 Macintosh developer
ObjectiveC 1987 NeXT Developer
C++ 1986 scientific programming
Java 1994 scientific programming
I think I it didn't help that free Pascal compliers were harder to come by. IIIRC
Looked at Eiffel for a hot sec in college but it never stuck, because no toolchain for beos, which I used in college.
These days I program in elixir, and am learning Zig.
I don’t miss them too much, but they were important stepping stones.