Slashdot Mirror
The History of Programming Languages
Dozix007 writes "For 50 years, computer programmers have been writing code. New
technologies continue to emerge, develop, and mature at a rapid pace.
Now there are more than 2,500
documented programming languages and O'Reilly
has produced
a poster called History
of Programming Languages, which plots over 50 programming languages
on a multi-layered, color-coded timeline."
Now I need to go buy a 40" monitor to view the whole thing at once...
They forgot Steve++, the crappy C++ rip-off I wrote for an independant study project back in high school.
Somehow I think they missed the boat on that one. Delphi is Borland's Object Pascal in a GUI driven environment.
What we really need is a meta programming language of which all the other programming languages are special cases.
----
Your Boss Might Be A Muppet
You may want to "right-click, Save As" that puppy . . .
I'm not tense. I'm just terribly, terribly, alert.
The same program, written in 621 of the 2,500+ is here.
He was referring to Assembler.
===== Murphy's Law is recursive. =====
The Tao gave birth to machine language. Machine language gave birth to the assembler.
The assembler gave birth to the compiler. Now their are ten thousand languages.
Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao.
But do not program in COBOL if you can avoid it.
Technoli
The Forth, Logo and Smalltalk lines all start in the late Sixties.
That being said, the lighter connecting arrows between languages (Lisp to Logo, Algol to almost everything else) makes the chart easy to follow and interesting to look at.
...and you run and you run and you can't stop what's been done...
So which couple dozen will we continue to use?
Enjoy!
/ob
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
ActionScript 2.0 is the newest language according to this chart. And if my manager gets ahold of this, I'll end up having to program in it by the month's end!
After all, to managers, "newer, and therefore better." *sigh*
There is another programming language family tree on that page aswell. This was mentioned in a previous story.
People do not typically "flame" about VB's functionality, but rather the breed of programmers and the vendor,IDE and API lock-in which accompany it.
I want to delete my account but Slashdot doesn't allow it.
One thing that has always bothered me is the lack of standards for basic syntax. Why not just have a standard for basic operators? For example does anyone really lose flexibility if we say statements are delimited by ';'? Or a standard syntax for if-then-else? e.g. perl's syntax is a pointless departure that adds no value.
Whoa.
It seems that Lisp holds the record for
"Longest Lived Language That Is Still Relevant Yet Underappreciated"
It just amazes me that something concieved that long ago is still going strong. I guess it makes sense, as it was concieved initially as a language for describing algorithms, then later implemented. With abstraction on the rise as it seems to be, this quality of being much closer to theory than practice is quite a useful one.
cool programming challenge: figure out the optimal vertical order for the languages so as to minimize the length of relationship indicators
For 49.5 years, computer programmers have been saying "but it worked on *my* computer"!
Height: 38U, Weight: 0 Newtons, Eyes: #0000FF, OS: Gray Matter 1.0 (Alpha)
Aaah, the nostalgia!
Anyway, I didn't see any programming language versions for functional languages (the ones I recognize are Haskell, ML and Miranda) after some time in -99.
Does that mean that they are dying out?
I've heard rumors of F# from Microsoft but I don't know if that is true.
It would be a pity if functional languages would die at this point in time since proponents of functional languages always used the argument that "they may be slow now but they scale really well on massively parallell computer systems" (because of no side effects) and we are at the brink of seeing multi-processor systems starting to go mainstream.
On a separate note, XSLT, which isn't a programming language in the traditional sense, is functional in its design. I think the designers of XSLT really put some thought into it. In any event, XSLT doesn't have any side effects, making it a functional language in a sense, and this means that it also should scale really well on massively parallell systems.
So, I guess the theory behind functional languages live on in one of the hottest technologies around today.
Also, the last version of Prolog was in -97. Pity, you can really do some magic in that language.
The Internet is full. Go Away!!!
Fortran 2060!
RTA:
FORTRAN I begot ALGOL 58 begot ALGOL 60 begot CPL begot BCPL begot B begot C begot C++
And it was good.
Beating the averages
Both are amazingly good.
It's quite impressive how it has evolved, and is still one of the most entertaining software environments around.
How could you not like a language whose syntax is > < + - . , [ ]
Its also the smallest compiler ever written.
Ardente veritate incendite tenebras mundi
The font is too bold and too small for the size of the graphic.
If only they would make it poster sized and ready for print!
I was disappointed to see Lisp not get much cred on that chart. First language with dynamic typing is worth noting. I've been reading up on Lisp (not coded a line yet) and have suddenly become disappointed in the entire programming world - right here there's a language with a featureset that it has taken other languages decades to catch up to.
Where is a language with the power of Lisp and the ease of Python? Python has some wonderful features in terms of speed and readability, but it is too tied to its primitives. After reading on Lisp, then going back to coding Python, I was really frustrated that the language wasn't better generalized - that all statements (if, import, etc) are hard coded - what if I want to make a custom block statement (like if or while) or something similar? Can't do that in Python, because you don't really have access to parsed code objects the way you do in Lisp.
I've looked at the modern Lisp languages (Common Lisp and Scheme) and I can't figure out which ones are worthy of my attention. Scheme seems like it has lost the intelligent simplicity of Python in favour of clumsy "special character" based syntax, while Common Lisp has many detractors that don't complain much of details. Is your complaint about Common Lisp based on all Lisp variants? Or is CL especially bad?
I know Lisp is not the ideal language - its ugly, illegible, and slower than compiled languages - but the fact is it existed at a time so far before many languages that pathetically failed to implement its features, so I'm a little confused at the way the computing world has ignored it, instead of trying to work its principles into modern languages (Python does a little, but ends up feeling cobbled together and inconsistent).
Looks like they colorized the one found here: http://www.levenez.com/lang/
"It is better to die on one's feet than to live on one's knees." - Albert Camus
or after a point does this just look like the history of when O'Reilly put out books?
Is your complaint about Common Lisp based on all Lisp variants? Or is CL especially bad?
No, I just don't think that a proper Lisp has been implemented yet - I'm thinking of a language with all of the semantics of Lisp *plus* easily readable syntactic sugar. I'd like to see a standardized lisp that I can write and read as quickly and Python.
In Python we have a very succesful programming model, in Lisp we have potential for every conceivable programming model. Specializing the Lisp a little bit to optimize for pythonic programming would do a world of good.
I want do do
o = SomeClass()
instead of
(setq o (make-instance SomeClass) )
The latter might be semantically more elegant, but boy, it doesn't flow like the python variant.
As far as non-language-feature issue goes, Lisp does need a better (quantitavely and qualitatively - no "Functional Programming" people but people who can recognize the realities of programming today) community and one standard open source implementation. Availability of commercial implementations just doesn't cut it. And the one open source implementation should run on Windows too (no, Debian doesn't cut it).
Save your wrists today - switch to Dvorak
They didn't define what they consider a programming language (Turing complete? General purpose?). Powerbuilder and m4 are general purpose languages but I didn't see them on the diagram.
If domain-specific languages are allowed, I think these were overlooked:
BTW, you can download a more printer-friendly version here: Eric Levenez's Computer Languages History
Also, a German version is available here: German PDF
Okay, good to see someone has come to the same conclusions I have. Python is a wonderful language, but the problem is that it has grown osmotically - the language itself is good (not great, but good), but the real popularity of it comes from its incredible amount of "batteries included".
IMHO, a real, true, ultimate pure _language_ (not standard library) needs to be polished up for an opensource successor. Something with the power of Lisp and the legibility of Python. I'm thinking of something very similar to python except that code-based blocks should be handled as custom objects like everything else in Python.
In Python, the statement
class foo(bar):
def __init__(self):
self.baz = "foo bar baz"
is using the interpreter to auto-insance a bunch of standard Python objects (a class and a method, which is than in turn wrapped with an instancemethod) based around code objects. I can subclass the interpreter "method" object or create new substitute ones in its place, but if I want to use them in the interpreter, then I have to instance them the normal way, using
mycustommethodinstance = mycustommethodclass(constructorarguments)
whereas the main method object gets the nice
def funcname(args):
statement. This is the biggest failure of Pythons generalism - its inorexicably tied to its core objects, so that if you are using it like Lisp as a fully custom-made lexicon, you still have to either a) tear the contents out of the engine objects and relocate them into your own objects or b) use stupid constructors like
myfunc = myfuncclass("myname", "my massivestring of text that is actually the whole code block that this contructor will compile into code but I have to enter it as a string like this its kinda stupid eh?")
Not very nice. I want to make custom if and class statements, replace the implicit behaviour that typing i=1 creates an int object instead of some other custom object I want it to make. Likewise, I want to use other datatypes otehr than a true python Dictionary object as the local namespace or the global namespace (well, the globals can be any kind of mapping, actually).
A generalized Python would be my dream language - Python, but where all the core objects and statements (like "if" or "class") were part of the standard library.
Ugly and illegible are matters of opinion - most Lisp people will gladly trade a certain amount of syntactic suger for extensibily. `Slower than compiled languages' is just silly: modern (say, in the last 30 years) Lisp implementations are (a) compiled, and (b) not generally slow.
The only date they list for Ocaml is 97 which is presumably when it was created. The latest major version of Ocaml is from 2000, and the latest minor update is from 2003.
I bet that's not the only example. They list Java 1.4.1_2002, but don't list minor releases of more obscure languages.
A generalized Python would be my dream language - Python, but where all the core objects and statements (like "if" or "class") were part of the standard library.
If you went that route, you would eventually realize that python-like syntax is unecessarily complicated, so you would simplify it down.. and you would have Lisp.
I hate to sound like a Lisp weenie, but if you take all these programming ideas and take them "to the logical conclusion", you *have* have a language with a light, uniform syntax, like Lisp has. You'd have to have the same basic constructs that Lisp has. Anything else would have to have some limitations, or would have opportunities for optimization.
Of course, do you really *need* that kind of a language? It's cool that in Lisp you can start with 2-3 constructs and build the entire language out of them, but in general that doesn't really help you write better programs.
editorial: I think Ruby is the "best" language out there, you can't implement all of Ruby in Ruby, but you can do a heck of a lot more than most other languages. But Ruby is still easy to use in the common case, where Lisp unfortunately isn't. And Ruby comes pre-installed with Mac OS X. :-)
As for the peculiar syntax, you get used to it rather quickly. Just like with other languages, there are editor tools to help you be productive "in spite of the parenthesis."
I know Lisp is not the ideal language - its ugly, illegible, and slower than compiled languages
Wait a minute. I have serious complaints about Lisp, but those are not among them. Let me take those in reverse order:
SLOWER THAN COMPILED LANGUAGES: No, there are compilers for both Lisp and Scheme that generate VERY fast code. There are interpreters that are as fast as Python that are nice to use during development, then you run it thru a compiler and the speed is on a par with C++, when performing similar operations. Of course a small amount of C++ code will often run much faster than a small amount of Lisp code, but that's because a small amount of Lisp code can say so much more than a small amount of C++ source can say. That shouldn't be counted against Lisp.
ILLEGIBLE: Not really, in my experience. I know what you mean, though. After a lot of use, it's still not quite as easy to read (for me) as something like Ruby or Python, which were already pretty clear even before I had written a single line of either. But it's nowhere near as hard to read as Perl still sometimes is for me, and I've been coding in Perl (occasionally) for a decade. Even C++, which I've done a lot of over the last decade, still gets pretty darned hard to read sometimes, such as when using templates to call old-style C APIs.
Lisp is a lot better than that. I've certainly grown to appreciate the way you can build abstractions out of abstractions and the top level is still called the same way as the bottom level. Self similarity at every level of abstraction, so you just have to think about the algorithms and not the syntax.
Trust me that, with practice, Lisp gets much easier to read, though it never seems to get quite as easy as something like Ruby or Python.
UGLY -- of course this is related to legibility. Again, I know what you mean, and I agree in some ways. A simple mathematical expression or loop is quite ugly, I think, compared to the same thing in Ruby or Python.
However, as soon as you leave the simple, built-in stuff and start building your own more complex functionality, you discover that Ruby and Python get uglier and uglier but Lisp still looks the same. As soon as you start trying to express really interesting algorithms (fancy searches, AI stuff, etc.), you'll see the beauty in the simple consistency of the syntax. (Much more true of Scheme than Common Lisp, BTW.)
So, no, I don't have any serious complaints in that regard. There's no speed problem at all and where it is harder to read, it's a small price to pay for the significant power boost that style of syntax gives you when working with really interesting problems.
So, what don't I like? The online community of users, for one. The misanthropes that took over comp.lang.lisp are pathetic. I've never seen a techical discussion group that hostile and defensive. Don't even think of asking them questions that might clear up some of your skepticism about Lisp. The fact that you have any doubts makes you unworthy of being treated with anything other than utter hostility.
They love Common Lisp like a religion, and hate everything, and everyONE else, even natural allies like Scheme. Common Lisp fossilized sometime back in the Reagan Administration and has since lost almost all ability to improve. As a result, the vast majority of former users have abandoned it and those who remain almost have to take a position that there is no further NEED for improvement except in trivial ways (more libraries, more "complete" implementations, etc.) that, if you think about it, are merely restatements of the "nothing needs to be improved" notion.
And that brings me to what I like least: it seems that the fundamental ideas underlying all forms of Lisp (incl. Scheme) are fascinating, and if redone in a way such as Paul Graham's Arc (www.paulgraham.com) could turn out to be a terrific language. Unfortunately, I don't see it happening. Arc is announcementware. It has shown no signs of life since its first few weeks. Com
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
Don't tell me no one here has ever seen this. I can get my own copy there and print it. O'Reilly merely remade it, and gave a small credit to Eric Levenez.
--<Mike>--
Perl's history starts with nawk and sh at version 1.0 and there are no further influences listed. At least that's what's in the picture.
A more accurate history would be:
Perl 1.0: awk, sh, C, BASIC
Perl 5.0: C++, LISP
Listed as a seperate line:
Perl6 A1-12: Perl 5.0, LISP, C#, C++, Ruby, Java, Python, SNOBOL
To be more specific, Perl 1.0 had heavy influences from C. The most obvious influecnes were in the operator precedence, ternary operator and behavior of parens.
In 5.0, the influence of C++ was felt strongly on the establishment of Perl 5's non-object-model object model (AKA the object model construction kit) and from LISP can the idea of closures.
Come Perl6, of course, it's a different language which borrows most of all from Perl 5, but also heavily from the other languages listed. Adding LISP currying, Ruby mix-ins, a Java and/or C#-like VM, python-like exceptions and a number of features from C++ including templated proto-classes and iterators as well as dozens of unique features. But, ultimately I think the most world-view altering change will be the SNOBOL-like inline grammar construction.
Well, there are lots of Delphi / VB comparisons and observations here so I thought I would throw in my two cents as Delphi is the environment I program in the most.
While there are similarities between VB and Delphi there were (and I say were because VB.net is a whole new animal) some important differences. For instance:
1. Delphi can link statically - I can hand a person a floppy disc with a program I wrote in Delphi and I know that they will be able to run it without distributing VB Runtime Libraries
2. Object Pascal in Delphi is a strongly typed language and a true object oriented language.
3. While Delphi applications may not be quite as fast as C++ apps the performance is certainly better than VB.
4. One can write Assembly blocks in a Delphi unit.
There are more but I am at work so I'll stop.
It's fashionable to slag VB, but, really, it's done a lot. A lot of people that would never have gotten into programming were able to make apps to suit some small purpose because of VB.
It's just too bad that most of those people did not know about Delphi and latch on to that because it really is the best RAD environment for Windows. Delphi really should have been the VB killer.
I did not state that QuickBasic or VB "required" line numbers. I stated that MS added the ability to use line numbers as part of the transition from Pascal to QuickBasic.
BZZZZZZZZZZZZT. Wrong. Now take 3 seconds out of your life... wouldn't you think... LOGICALLY... that line numbers would be supported as backward compatibility to GWBasic? I think so. As a matter of fact, I have seen several schools teach Qbasic classes, using GWBasic text books... see where this goes, and your bullshit doesnt?
When I first encountered QuickBasic, I already knew BASIC, Pascal, and C. I could replace the keywords in my Pascal programs and then do minor debugging to have functional QuickBasic programs. The API for VB has grown since then, but it still looks like Pascal with different keywords.
You mean like StrLen? C had to have RIPPED THAT OFF TOO! Oh, let me illustrate how much they are the same:
If You = Retarded Then
Print "Retard"
Else
Print "Still Retarded"
End If
vs.
If You = Retarded Then
Begin
writeln('Retard');
End Else Begin
writeln('Still Retarded');
End
Yep.... identical all right *ugh*.
It was a smart move for MS. Most college grads were learning Pascal, and the transition to developing in the MS-proprietary language was easy since few of the rules were different
Do you even live in the same universe as the rest of us?
Today I work with Java and LotusScript with Domino because it is allows much faster business application development than any other platform. LotusScript was based on VB, and still looks similar: same keywords, different API, and it has the List variable type. I also use Java for applets, servlets, and server applications; and one of my Java projects will require a GUI-based client, although I have not written it yet. (I prefer Java over C/C++ because the native memory management saves development and QA time.) I have never developed with Delphi, although several friends are good with it, and their code looks like super-charged Pascal.
Ok, thanks for clearing up why you are completely unqualified to even exist.
Also, it looks like Super Charged pascal, because its simple Object Pascal.
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
Just in case you don't know, Lisp is a compiled language and not slow, especially when compiled with appropriate type declarations. Only the very most early dialects (forty or so years ago) were interpreted-only. Some interpreted implementations exist now, but that's a choice of the implementor, not a requirement of the language.
I disagree with your remarks about ugly and illegible, too, but that's personal taste, I guess. My views on all this are copiously documented in my Slashdot interview, Part I and Part II.
However, what really disappointed me in this chart was its unscientific and subjective decision about what to include and how to present things.
Some of the arrows stop mysteriously so far leftward (as if to hint "this language is no longer used). That's apparently a subjective assessment on their part offered with no foundation, and irresponsibly inappropriate in a document intended to fairly describe history. Common Lisp's arrow stops short for reasons I don't understand since it continues in commmercial use today.
I didn't check the table thoroughtly, but the absence of mention of the fact that Scheme influences Common Lisp seems odd since it's a well-advertised truth.
The omissions of ISLISP, an ISO standard (ISO/IEC 13816:1997) is also surprising and shows poor researching. The absence of Interlisp, Portable Standard Lisp (PSL), Eulisp, Gnu Emacs-Lisp (in spite of huge distribution world-wide as customization substrate for Emacs), and Xlisp (hugely distributed as part of Autocad) as important dialects is similarly sad.
O'Reilly sells books and has for a long time requested outright that no Lisp authors approach them. I and others have long noted that it has an apparent chip on its shoulder about Lisp, and little surprise they couldn't help exposing that bias in their chart. They want you to think the books they sell define the market. But that's just not so, especially when they voluntarily close their eyes to what's going on around them.
People should look skeptically at a company that wants a reputation as a "documentation" company yet so easily falls victim to its own commercial decision to close its eyes to this language family's achievements (such as an international standard).
A quick glance at other parts of the table leave out many other important languages and dialects, with no explanation of their rationale. Just for example: Teco, which strongly influenced Emacs-Lisp. I don't see HyperTalk there, either, even though I thought it influential. And there were many dialects of BASIC and LISP that are too small to mention, yet variations on the Unix shell language like bash are apparently worth mention. I guess that more reflects O'Reilly's sales than an attempt to explain history.
As a consequence, I have to regard this chart of theirs as commercial eye candy and not a properly scholarly work. I think it's a shame that Slashdot has chosen to give it all this free press. I'm sure that's just what they were hoping. And I'm sure they just don't care about their errors, omissions, and biases. I imagine they just want to sell books, and that all this free press will do just that.
Me, I buy my books from other sources. And I recommend you do, too.
Kent M Pitman
Philosopher, Technologist, Writer