145
$\begingroup$

I'm pretty fluent in C/C++, and can make my way around the various scripting languages (awk/sed/perl). I've started using python a lot more because it combines some of the nifty aspects of C++ with the scripting capabilities of awk/sed/perl.

But why are there so many different programming languages ? I'm guessing all these languages can do the same things, so why not just stick to one language and use that for programming computers ? In particular, is there any reason I should know a functional language as a computer programmer ?

Some related reading:

$\endgroup$
11
  • 2
    $\begingroup$ there is also a difference between OO and non-OO. Plus, some languages come with nice packages: R, Maple, Matlab, Mathematica that are often lacking from other languages. $\endgroup$ Mar 17, 2012 at 6:30
  • 89
    $\begingroup$ i.stack.imgur.com/35yc5.png $\endgroup$
    – Dai
    Mar 17, 2012 at 6:32
  • 6
    $\begingroup$ Already ask on Programmers programmers.stackexchange.com/q/7551/45322 $\endgroup$ Mar 19, 2012 at 21:39
  • 2
    $\begingroup$ For implementing parallel algorithms, functional programming is better, in general when you have mutable objects, it's better to use OO paradigm, else (if you want deal with immutable objects) it's better change it to functional model. This scenario widely exists in parallel processing. Also some of excellent OO patterns, like fluent interface and method chaining are working like functional paradigm. $\endgroup$
    – user742
    Aug 20, 2012 at 0:16
  • 6
    $\begingroup$ Why are there so many cars? Why are there so many airplanes? And what about BOATS! I mean, really! You go down to the ocean and there's, like, all KINDS of the dang things! What's the point of all those differents kinds of things?!?!? It's inefficient! It's wasteful!! And what is the freakin' point of all those different choices?!?!? Geez - wise up people! Nobody could possibly need anything except a Yugo, an F-150, and an ocean liner! Oh, yeah, planes - MD-80's'll work fine for just about everything. There. Now that that's all settled... :-) $\endgroup$ Feb 16, 2016 at 3:05

12 Answers 12

127
$\begingroup$

Programming languages evolve and are improved with time (innovation).

People take ideas from different languages and combine them into new languages. Some features are improved (inheritance mechanisms, type systems), some are added (garbage collection, exception handling), some are removed (goto statements, low-level pointer manipulations).

Programmers start using a language in a particular way that is not supported by any language constructs. Language designers identify such usage patterns and introduce new abstractions/language constructs to support such usage patterns. There were no procedures in assembly language. No classes in C. No exception handling in (early) C++. No safe way of loading new modules in early languages (easy in Java). No built-in threads (easy-peasy in Java).

Researchers think about alternative ways of expressing computations. This led to Lisp and the functional language branch of the language tree, Prolog and the logic programming branch, Erlang and other actor-based programming models, among others.

Over time, language designers/researchers come to better understand all of these constructs, and how they interact, and design languages to include many of the popular constructs, all designed to work seamlessly together. This results in wonderful languages such as Scala, which has objects and classes (expressed using traits instead of single or multiple inheritance), functional programming features, algebraic data types integrated nicely with the class system and pattern matching, and actor-based concurrency.

Researchers who believe in static type systems strive to improve their expressiveness, allowing things such as typed generic classes in Java (and all of the wonderful things in Haskell), so that a programmer gets more guarantees before running a program that things are not going to go wrong. Static type systems often impose a large burden on the programmer (typing in the types), so research has gone into alleviating that burden. Languages such as Haskell and ML allow the programmer to omit all of the type annotations (unless they are doing something tricky). Scala allows the programmer to omit the types within the body of methods, to simplify the programmer's job. The compiler infers all the missing types and informs the programmer of possible errors.

Finally, some languages are designed to support particular domains. Examples include SQL, R, Makefiles, the Graphviz input language, Mathmatica, LaTeX. Integrating what these languages' functionalities into general purpose languages (directly) would be quite cumbersome. These languages are based on abstractions specific to their particular domain.

Without evolution in programming language design, we'd all still be using assembly language or C++.

As for knowing a functional programming language: functional languages allow you to express computations differently, often more concisely than using other programming languages. Consider about the difference between C++ and Python and multiply it by 4. More seriously, as already mentioned in another answer, functional programming gives you a different way of thinking about problems. This applies to all other paradigms; some a better suited to some problems, and some are not. This is why multi-paradigm languages are becoming more popular: you can use constructs from a different paradigm if you need to, without changing language, and, more challengingly, you can mix paradigms within one piece of software.

$\endgroup$
3
  • 1
    $\begingroup$ Fully agree. I am interested in where multi-paradigm languages (e.g. Scala) will be in a couple of years. If they allow easy DSL integration, we might actually see a gradual decline in language numbers. $\endgroup$
    – Raphael
    Mar 17, 2012 at 11:11
  • 2
    $\begingroup$ Very detailed answer! We could acknowledge that most programming languages might be Turing Equivalent, but that doesn't mean that the abstraction they support is suitable for every problem domain. $\endgroup$
    – CyberFonic
    Mar 21, 2012 at 1:42
  • 3
    $\begingroup$ Putting assembly and C++ in a same box hurts my heart. C++ has evolved a lot!! Specially since C++11 and forward. $\endgroup$
    – ABu
    Aug 3, 2019 at 18:03
75
$\begingroup$

tldr: There is no silver bullet language.

I hope they won't sue me, but here is a pic from one of the Stanford presentations.

enter image description here

When you decide to pick a language, you can pick only 2 of these 3 features.

And that is why people are sad and want to invent a superlanguage that will cover all 3 of them.

Actually, there is a huge list of requirements (some of them you can see in other answers) but they just add details to the core features. Additionally, there are historical and political reasons to prefer one language over another.

Combinations of such factors yield a new language.

(And I've heard that every good programmer should make their own new language ;))

$\endgroup$
11
  • 16
    $\begingroup$ Over time the triangle is shrinking, in the sense that the corners are getting closer together..... I hope/dream. $\endgroup$ Mar 21, 2012 at 12:25
  • 1
    $\begingroup$ Performance and Generality, can more o less be compared but I will add that experience in a language gives you more productivity than a certain language itself, it's not fair to compare "productivity of languages" alone, because you need the supposition of knowing and expertise them all, a very unlikely hypothesis. $\endgroup$ May 23, 2012 at 12:20
  • 1
    $\begingroup$ @evnu, here's a quasiformal argument of one part: assuming generality means that valid programs of any length n in language L cover a larger problem space, each subspace of problems is only covered by some fractions of the length n programs. If the programs of length n outside your particular subspace were instead inside your subspace, you'd have greater odds of finding a shorter program which solved your problem (so you'd presumably be more productive), but the language would be less general---it'd solve problems in other subspaces less well (i.e. with longer programs). $\endgroup$ Feb 2, 2013 at 15:35
  • 2
    $\begingroup$ This is a good argument that you need at least two programming languages, as well as a large number of domain-specific languages, thus covering all three sides of the triangle. We have many, many, many more than that. (And I'd put c at the top vertex of the triangle, but that's a fairly small niggle.) $\endgroup$
    – Peter Shor
    Oct 5, 2013 at 23:31
  • 1
    $\begingroup$ @RosieF Both C and C++ fit in the same category on the chart. It is appropriate to group them together. $\endgroup$
    – user253751
    Dec 16, 2020 at 14:56
29
$\begingroup$

The world is filled with things that have many different variations: word processors, cars, home designs, beverages, candy, pens, shovels, etc. The reasons why we have so many can be boiled down to a few principles:

  • Someone thinks they can improve on existing products
  • A different design is necessitated by local considerations (think: homes on stilts vs. homes on concrete slabs)
  • A new category of product fills a need where none existed before

Walk into any office supply store and look at the "writing instrument" section -- there are hundreds of varieties of pens. They all do roughly the same thing: deliver ink to a writing surface. But each pen you see displayed for sale is there because one of the three reasons above.

  • Cartridge fountain pens are an improvement on dipped fountain pens, which are themselves an improvement on feather quills.
  • NASA needed a pen that could write in the absence of gravity, so the pressurized rollerball pen was invented.
  • The very first pen itself may well have been a pointed stick dipped in tar or blood; prior to that people were scraping rocks together or smearing pigments on walls with fur. (Just a guess.)

The evolution of pens will continue since no one product fits the needs of every user. Some pens are cheap and disposable, some are expensive and built of high-quality materials; some use gels, some use ink, some use pigments; some have twist-off caps, some don't have caps at all; wide barrels, narrow barrels, round barrels, square barrels; short, long; red, white, black, blue. Etc, etc.

But enough about pens.

Our current myriad of programming languages can be traced back to the very first ones: the numeric machine codes for early computers back in the 1940s. Primitive, hard to use, and laborious to enter into the computer, but they did the job. It wasn't long after that programmers assigned mnemonic words (such as ADD, CALL, LOAD) to the machine codes, giving birth to the class of languages called "assembly languages."

Different processor architectures called for different mnemonic codes, depending on the specific features of the underlying machines. Taking these differences into account meant inventing different assembly languages.

(Perhaps by now you can see where this is going...)

Programmers looked at their assembly languages programs and saw patterns: the same sequences of instructions would be used to form loops, conditionals, variable assignment, function calls, and so forth. Thus, the procedural programming languages were born. These languages encapsulated groups of instructions under umbrella terms such as "if", "while", "let", etc.

Out of a mathematical analysis of computer programming came the functional languages -- a whole new way of looking at computation. Not better, not worse, just different.

And then there's object-oriented, statically typed, dynamically typed, late binding, early binding, low memory usage, high memory usage, parallelizable, languages for specific uses, and on and on.

Ultimately, we have different programming languages because we want different programming languages. Every language designer has their own ideas about how their "dream" language will look and operate. Diversity is a good thing.

$\endgroup$
3
  • 1
    $\begingroup$ I don't see any compelling reason given here for why we should have multiple languages besides that people want to for whatever reasons. $\endgroup$
    – Raphael
    Mar 21, 2012 at 12:25
  • $\begingroup$ That's it exactly. Programmers are by nature problem-solvers. To solve problems, they need tools which often take the form of programming languages. If the tools can't help them solve their problem they way they want, they invent new tools. Think of it this way: since the tools are software and new software is written to solve new problems, the tools themselves can be problems to be solved. Those problems are solved by making new tools. $\endgroup$ Mar 21, 2012 at 23:21
  • $\begingroup$ Just one nit: The functional branch of languages is an ofshot of mathematician's ideas of how to express what we today call "computing", that started to be considered some 50 years before the first computers. It isn't for nothing that LISP (in some form) is the second oldest language still around, the first being FORTRAN. $\endgroup$
    – vonbrand
    Mar 10, 2016 at 11:43
20
$\begingroup$

Functional programming languages are usually based on the different (but equivalent in power) model of computation: lambda-calculus. There are some untyped (has Python-like typing) languages such as LISP, Scheme (used in widely recognizable Structure and Interpretation of Computer Programs book/course) and statically-typed languages like Haskell, ML, F#.

SICP is what got me into functional programming, but other people recommend this paper by John Hughes and this interview with him.

Functional programming is now being push by Microsoft, for example, who have included F# (their functional language for .NET) in VS2010 and 11; they also employ some Haskell developers in MSR, IIRC.

Note, that there are also some non-lambda-calculus functional programming languages, such as Refal, which is based on pattern matching and rewriting.

Because the level of abstraction in functional languages is different, your attitude to solving problems changes, when you use functional programming techniques. Some say that it can make you a better programmer in general.

$\endgroup$
8
  • 1
    $\begingroup$ Another interesting class of languages is logic programming languages, such as Prolog. I only had a very limited experience with DataLog so maybe somebody else could write an answer about those? $\endgroup$
    – Daniil
    Mar 17, 2012 at 6:30
  • 2
    $\begingroup$ I agree that we need a programming language for each programming paradigm: imperative, OO, declarative, functional, etc. But this doesn't explain why we have so many, say, OO languages. $\endgroup$
    – Dai
    Mar 17, 2012 at 6:36
  • $\begingroup$ @Dai, well, do we really? The theoretical foundation is not the only characteristic of a language. For example, one may say that a key feature of Java or C# is (comparing to C++) the virtual machine, which makes Java significantly different. $\endgroup$
    – Daniil
    Mar 17, 2012 at 6:54
  • $\begingroup$ But then if C# and Java both use the virtual machine concept, why don't we use identical syntax for both languages? I think every designer has his/her strong ideas how his/her language should look like, and has the tendency to create his/her own standard. $\endgroup$
    – Dai
    Mar 17, 2012 at 6:57
  • $\begingroup$ @Dai, there are a lot of minor differences between C# and Java, after all. Plus, I think there was some legal dispute over the Java VM for Windows or something of that sort. $\endgroup$
    – Daniil
    Mar 17, 2012 at 6:59
19
$\begingroup$

In particular, is there any reason I should know a functional language as a computer programmer ?

Yes. Because haskell changed the way I think. It might change the way you think too.

Story: I used to think that I can learn any programming language in a day. One day I started Haskell. I finished everything that came before monads in half a day. Now its been a year since that day and I am still hopelessly stuck at Monads.

Read:

  1. Languages and thought wiki

  2. Notation as a tool for thought by Kenneth E. Iversion, Turing Award lecture

But why are there so many different programming languages ?

Notation is tool for thought. We need different tailor made notations to deal with different thoughts comfortably. So we create new languages.

Also, read. ;-)

$\endgroup$
7
  • 5
    $\begingroup$ To recurse is divine! $\endgroup$ Mar 21, 2012 at 2:18
  • 4
    $\begingroup$ to iterate is human ? $\endgroup$
    – Suresh
    Mar 21, 2012 at 2:47
  • 2
    $\begingroup$ Not sure if that was a good advert for Haskell. ;) $\endgroup$ Mar 21, 2012 at 23:22
  • $\begingroup$ @Pratik Deoghare. Learning Haskell in a day was probably not a good idea. I would say, read a good text book on functional programming, such as Bird and Wadler, and take your time doing it. Then monads might not be so difficult. $\endgroup$
    – Uday Reddy
    Mar 22, 2012 at 21:32
  • 1
    $\begingroup$ I found this video from Brian Beckman quite a clear explanation and it at least got me to understand Monoids within an hour. $\endgroup$
    – icc97
    Apr 1, 2016 at 15:18
14
$\begingroup$

There hardly could be a programmer who hasn't at some point in time become frustrated by the constraints of the language they were using and decided to scratch his itch. Thus a new language - or dialect of an existing one - is born.

Abadi and Cardelli in "A Theory of Objects" develop a whole family of programming languages from object-oriented foundations. They prove that functional programming is a special case of OO but not the converse.

Inventing something new is fun, that is why people are more likely to create yet another language than contribute to making an existing one better. Of course, there are custodians of languages who don't welcome changes to their vision. Best example being the chasm between Common Lisp and Scheme supporters.

$\endgroup$
1
  • 3
    $\begingroup$ A Theory of Objects does not present a whole family of usable programming languages. It presents a foundation for object-oriented programming languages, and a strange one at that, being not based on classes. I don't see the connection between "A Theory of Objects" and functional programming. The object calculi have no notion of laziness, for example. There is also research encoding OO concepts in terms of functions and records, for example, the work by Pierce in the late 90s. $\endgroup$ Mar 21, 2012 at 20:14
14
$\begingroup$

Why are there so many countries in the world? Wouldn't it be easier if we just had 5 or 6 superpowers, or even one universal kingdom of the Earth? It is easy to argue why it would not be better --- for a start, competition different countries may lead to progress, and from the point of view of democracy, human rights, etc., many countries may be better than one --- but this does not explain, why we have many countries. It only explains why many countries would be better.

Similarly, you can ask, why so many different human languages? Polish, Arabic, Mandarin... Wouldn't it be easier if there were just one language? You could argue either way, but those would be reasons as to why it would be better if life were one way or the other. It wouldn't explain the causes behind there being so many different human languages.

The thing is, there are many people on the planet, and we are all doing our thing, we all have our opinions, we all want to be in charge and have our own country or programming language, and we often think that we know better than others, or at least don't bother to understand what others have to offer.

Read this very enlightening blog post, Why so many Python web frameworks? Apparently, there are about 50 web frameworks in Python. This is just ridiculous; there is absolutely no sensible rational reason for that. But the author of the post answers: there are so many Python web frameworks because it is so easy to create one. You don't need a rational reason for there being more python web frameworks or more programming languages. People will go on creating new ones because they don't know what is already available, or because they hope they can make money, or just because creating new things is fun!

Let me describe a personal example. About 10 years ago I was writing some C++ code for a Finnish company. You know, in Finland they have those huge trucks that, well, travel long-distance and deliver a lot of stuff from one place to the other. I am sure, there are such trucks in America as well. So a typical problem is to make sure that all the 24 or so tires are fine. Of course, there is time-tested technology: pressure and temperature can be monitored, and drastic changes would indicate that something went wrong. Of course, all of this technology is proprietary, patented, with all the implications. (Remember: patents are supposed to promote innovation!) So this Finnish company wanted to detect the state of the tires by... sound. The idea was to install microphones to listen to the sound coming from all the tires and to do some kind of signal processing magic on those sounds in order to see if one of the tires had a problem of some kind, and I was doing a prototype of this madness. (They even had a dedicated lab for recording sample sounds; once they sent me an impressive video record of a particular occasion when they managed to explode a sample tire after subjecting it to 5 or 10 tons of pressure and heating it up to some ridiculous temperature.) Clearly, again, there was not a particular rational reason for this development, except that it was fun and some people wanted to make money. So also understand that there are so many reasons as to why somebody would start developing a new programming language. There is no need or even possibility to learn all of them.

Of course, all of this only applies if you believe in evolution. If you believe in some form of intelligent design, that God has also created all of the programming languages, then you would have to find a purpose behind this multitude. Perhaps God wanted to promote competition between different programming languages so that the art of software development would reach its highest possible state.

In conclusion, there are many people, many countries, many programming languages. This is just the nature of life! Let's be grateful for that: this just means that the field of programming/computer science is very much alive and flourishing.

$\endgroup$
1
  • $\begingroup$ very perfect answer,I don't know why it wasn't accepted! $\endgroup$ Jun 29, 2014 at 18:46
13
$\begingroup$

Since others have already given good answers for this question, I will just quote Alan Perlis.

Beware of the turing tar pit, in which everything is possible but nothing of interest is easy.

Also, http://weblog.raganwald.com/2004/10/beware-of-turing-tar-pit.html, is a good read.

$\endgroup$
10
$\begingroup$

Why are there so many different programming languages?

Because there are choices to be made:

  • Mode of specification: Imperative vs. functional
  • Typing: Statically typed vs. dynamically typed
  • Order of evaluation: call-by-value vs. call-by-name
  • Modularity: class-based vs. abstract data type-based
  • Execution model: sequential vs. concurrent

Fortunately, the last two are inessential dichotomies, i.e., one could put both the choices into a single programming language. But, the first three dichotomies give rise to 8 combinations. So, even in an ideal world, there would be at least 8 programming languages. When you drill down, there would be further nuanced design choices within particular paradigms. For instance, if one decides to do a class-based statically typed language, there are different ways of designing the type system. There is not yet a canonical way of doing it. If one decides to do a concurrent programming language, there are various ways of representing concurrency: semaphores, conditional critical regions, monitors, message-passing (synchronous vs. asynchronous). Within synchronous message-passing, there are two major paradigms determined by how nondeterministic choice is captured (as represented by CCS and CSP).

Part of the research we do in programming language theory is devoted to resolving these dichotomies. For instance, I worked on resolving the dichotomy between imperative and functional programming in a paper called "Assignments for applicative languages" and our method has now been adopted by Haskell, making it both a functional and imperative language. That doesn't mean that the dichotomy is fully resolved. A Haskell programmer is still faced with the choice of whether to solve his problem functionally or imperatively. Luca Cardelli worked on resolving static vs. dynamic typing dichotomy. Paul Levy worked on resolving the call-by-value vs. call-by-name dichotomy. Not all of these results have yet been implemented in real-life programming languages.


If all these languages can do the same things, why not just stick to one language and use that for programming computers?

Because for a programmer in the real world, it is not enough to just do something. It also matters how it is done. When it is done properly, the problem domain is represented faithfully in the program, modularity of the problem is retained, and the programs become easy to understand, modify and maintain. All these things affect the cost of program development and maintenance. They also affect the reliability and security of the software.

For instance, many people use a program called "Quicken" for financial accounts. The original program was developed in some in-house version of Visual Basic, and it was quite good. However, it has been hard to extend it and maintain it. Over the years, as the company attempted to extend it for newer features, the program became increasingly buggy with millions of dissatisfied customers everywhere. They will probably benefit from re-engineering the software in a strongly typed object-oriented programming language.


In particular, is there any reason I should know a functional language as a computer programmer ?

Historically, "functional programming" was invented by Godel, Kleene and Church following the standard mathematical practice, and "imperative programming" was invented by Turing to pin down the notion of mechanical computation. Before Turing, there is no evidence of mathematics ever having analysed imperative programming ideas. (While all traditional mathematical algorithms were expressed in an "imperative style," their essential content was still functional.) So, imperative programming is very very new to human civilization, and its mathematics is still not very well understood. The No. 1 reason why everybody should know some functional programming is to understand how programming can be mathematical. (I am not admitting that imperative programming is non-mathematical, which is what functional programmers would have you believe. But I would agree that, with the present state of art, we don't yet know how to do imperative programming mathematically. Many of us are working on precisely that problem.)

$\endgroup$
2
  • 1
    $\begingroup$ Charles Babbage's/Ada Lovelace's computer programs where published in the 1840s, long before Turing. They could be called an early imperative style $\endgroup$
    – Sebastian
    Apr 5, 2020 at 13:51
  • $\begingroup$ Agree with the comment that attributing imperative programming to Lovelace would be more appropriate than to Turing. At any rate, Turing's primary accomplishment was formally defining computation, not inventing imperative programming. I don't really view Turing machines as imperative; they are a machine encoding that can be used e.g. for functional or logic-based paradigms as well. $\endgroup$ Jun 21, 2020 at 10:59
1
$\begingroup$

You might look at it as evolution.

In the beginning, computers were programmed purely with binary codes. After that mnemonics were introduced and assembly languages were introduced, mostly depending heavily on the CPU used.

After that higher level (3th level) languages was introduced (Pascal, C, ADA, Cobol), some very generic (like C), some more suitable for data handling (Cobol), some for calculations (Fortran).

After that 4th level languages arose, like logic languages (like Prolog). The most generic languages are successors of third level languages; some of them are Java, C#.

We also see languages specific for internet/web, like ASP.NET, PHP.

And languages for a specific domain (DSL), which mostly work together with a generic language.

Then there are languages for kids to learn programming, like LOGO.

Also languages for fastly writing code, like Python, Ruby etc, languages for handling XML (XSLT).

And I probably have forgotten a lot of languages and even categories of languages.

$\endgroup$
2
  • 1
    $\begingroup$ Your chronology is confused. Prolog is from 1972, which is younger then Ada (1983). I don't know what you mean by "successors of third level languages"; few languages aren't descendants of Fortran, including C and Pascal (which begat Ada). $\endgroup$
    – prosfilaes
    Jul 21, 2015 at 6:50
  • 1
    $\begingroup$ @prosfilaes, way confused. FORTRAN was the first language still in use, then came LISP, then COBOL. Algol was defined for publishing algorithms, not machine use (but compilers of a sort came to be anyway), with ofshots Pascal and later C. PL/1 was a strange mix of FORTRAN and COBOL with Algol-ish control structures. $\endgroup$
    – vonbrand
    Mar 10, 2016 at 12:02
1
$\begingroup$

other answers are good, will add a few new angles. as DC writes languages evolve just like real human languages! and they borrow concepts and syntax from each other again like real human languages. in other words theres also a fairly real study of etymology of computer languages.

this also means theres been a long history and timeline which mainly started around the 1930s with lambda calculus.

there is a strong interplay/synergy/symbiosis between theory and application with programming languages. new applications are invented which leads to new theories and vice versa. a programming language is in many ways a bridge between theory and application.

an interesting case study from history is Fortran. it is not well known but earlier versions of Fortran (mostly before Fortran77) had an ambiguous grammar. this means that the same command could be legitimately "interpreted"/compiled different ways by the compiler because there were multiple valid "interpretations" (this is not the same technical sense of "interpreted" languages).

so the theory about formal grammars was being developed around the time that Fortran was invented, and it was a small crisis when the issue of language ambiguity was discovered. Fortan syntax was reformulated to avoid this ambiguity and later languages had more sensitivity to grammar ambiguity in their design. OOP is also a very important/foremost example of a theoretical concept/advance in programming languages that "impacts" or "ripples" into many existing languages, transforming them.

other case studies are the invention of new technologies. for example the invention of the relational database has had huge impact on computer languages eg with SQL and computer language interfaces to it (eg for example in java, "JDBC"). likewise the world wide web with even more massive impact. there seemed to be an explosion of languages timed right around the dotcom boom which largely coincided with the early growth of the WWW and might be compared with evolutionary explosions.

there also does seem to be a long trend of rise in new programming languages in conjunction with the massive exponentially increasing processing power of Moores law which some think may be slowing.

current longrange trends in programming languages seems to be toward Big Data and Parallelization eg with MapReduce. there is also a current interest in closures.

another key aspect of languages is that they represent increasing levels of abstraction. they build on lower-level abstractions to create higher level abstractions (similar to a pyramid). in this way the progress of computer language evolution is probably endless and we can be relatively sure important new ones will continue to be invented long into the future. this is probably analogous to a similar concept in psychology called chunking—roughly stated, building higher level mental concepts out of lower-level building blocks.

anyone who has studied many computer languages must admit that a herd mentality can be observed whereby some aspects of them turn out to be overhyped fads, ie not so critical as advocated, or even die out (in use) over time! some of the core ideas/changes remain but the (over-)hype fades. in this sense programming languages also fall in and out of fashion. two cases in my opinion from the last half-decade that are indeed useful but were overhyped:

increasingly a self-similarity can be observed across many major languages such that they all tend to be converging toward implementing many similar features in their own way, ie as with product comparison charts that "check off" many features in a grid.

$\endgroup$
5
  • $\begingroup$ see also design patterns which often cross languages and are implemented in languages. another key aspect of language study/functionality are features implemented in libraries $\endgroup$
    – vzn
    May 14, 2013 at 20:05
  • $\begingroup$ FORTRAN never had a formal description, much less the complexity of expression that could lead to grammar ambiguities (yes, I did start programming in an abomination called PDQ FORTRAN, and later FORTRAN IV) the language in which the (very embarrassing) ambiguity in the grammar came to light has Algol, the first language defined with a grammar. $\endgroup$
    – vonbrand
    Mar 10, 2016 at 11:57
  • $\begingroup$ point taken wrt original/ early FORTRAN but later versions were more formalized with more rigorous grammar definitions. its a case study showing evolution of a language along with language theory. $\endgroup$
    – vzn
    Mar 10, 2016 at 16:07
  • $\begingroup$ FORTRAN got force-fed a grammar, but never was designed around one. Algol started that trend, which got continued by Pascal, the Modula family, Oberon, C and it's ofstpring, PL/1, Ada and such. Given the context free grammar technology and an understanding of parsing, today defining a grammar and translating that into an error-free parser is almost trivial, no newer language does without. $\endgroup$
    – vonbrand
    Mar 10, 2016 at 18:54
  • $\begingroup$ addendum, case study in newer/ emerging languages: Google go, node.js, Apple swift $\endgroup$
    – vzn
    Mar 10, 2016 at 19:45
-4
$\begingroup$

They weren't, it's just a marketing gimmick-- if you make the language kinda sorta look like "C", then that lowers the apparent barrier to entry.

Some that have no C influence at all: SQL, Pascal, Delphi, FORTRAN, COBOL, Ada, PowerBuilder, HyperTalk, Lisp, Simula, FOCAL, BASIC, PL/I, Algol, Algol-68, SNOBOL, Modula, Visual BASIC, Tutor, logo, Forth, DIBOL, Helix, AppleScript, Python, Erlang, Ruby, Pick, English, RPG, PL/SQL, ASP, Prolog, SmallTalk, Perl, bash, Wand BASIC, REXX, DOS batch language.

Those that kinda LOOK like C, but have very little in common with it: JavaScript, Java, C#, (arguably) Objective-C.

It's all marketing, Java, C++, and JavaScript kinda looks like C, but could hardly be more different under the covers.

$\endgroup$
2
  • 5
    $\begingroup$ "They weren't" -- what weren't what? In any case, I don't see how this answers the question. It's simply a list of languages, along with a completely unsubstantiated claim that marketing is somehow involved. $\endgroup$ Mar 10, 2016 at 7:10
  • 3
    $\begingroup$ "Some that have no C influence at all: ... Algol, Algol-68, ..." -- Funny you should say that, given that C arose from Algol. "if you make the language kinda sorta look like "C", then that lowers the apparent barrier to entry" -- iirc, this has been proven wrong. Students without prior exposure to programming learn faster with other languages (I think they used Haskell in that study). $\endgroup$
    – Raphael
    Mar 10, 2016 at 9:12

Not the answer you're looking for? Browse other questions tagged or ask your own question.