“In this example, you don’t know the languages you are criticizing.” - Creme

I think that goes for many of the examples given.

http://www.databasesandlife.com/programming-languages-is-newer-always-better-part-2/

@Helge: Response coming in a future post.

I don’t know enough about programming languages, so I’ll shut up on your main point. As to your example with network vs. standalone computer: This is a very effective and productive cycle, it’s not the same things coming back but technologies being built on top of each other.

The terminals of the early mainframes were entirely stupid. The workstations that came then were an added bonus to those mainframes, an *addition*. The notion of “the web is the computer” enables us to do the same things as locally but collaboratively - a real *addition* in value again. (Note that these “terminals” of today are not stupid any more, they interpret (html/css) and run (javascript) web applications locally.) But one wants to be able to use these great because collaborative services also when, say, on a plane. So offline versions are being added. Are real *addition* in value again.

Every step in your cycle is a real addition to the previous one, and is built on top of it. Standing on the shoulders of giants, as Newton said I believe.

Bottom line: If your main argument follows your central-local-central metaphor then re-inventing programming languages from time to time is a very good, productive and innovative thing.

[…]I constantly hear the belief that modern programming languages and environment are better than older programming languages. More productive, easier to user, and so on. It would stand to reason: nobody would make a new programming language with wor…

Variable Bounds
You really have two components here. One are primitives like integers, floats and byte arrays. Second is objects which reflect higher level abstractions like strings, byte arrays (again), hashes, etc. I don’t think variable checks are all that useful as a feature of the language. This should be part of the library of higher level functions. In any OOP language (including Simula) this can easily be supported and sometimes is.

Strict typing
This is really a static vs dynamic typing argument. You want the compiler to check that a method can only receive an object of type SomeObject while I want any method to be able to receive any object as long as it responds to (or has the same interface) as SomeObject. Lisp (old), Smalltalk (old), Perl (new), Ruby (new), Python (new), etc all have this dynamic feature and benefit greatly for it. C, Fortran, C++, Java and Pascal require static definitions and suffer greatly for it. C++ (again) and Java (again) have templates/generics to fake this kind of feature and suffer horribly for it. OCaml allows either and therefore has a leg up on both camps by giving the developer the greatest flexibility.

Knowing what’s going on
This is a terrible example. You are really arguing that PHP programmers don’t know how their language works while C programmers do. This is a horribly wrong-headed assertion. How about I counter your straw man with one of my own. I know plenty of new (as of the last 5 years) C programmers who have no idea that 0 is equivalent to NULL.

Enumerated types
This is a great feature modern day languages have though maybe it isn’t called “enumerated type.” Ruby has symbols so you can say your types are :hot, :warm, :lukewarm, :cold. These symbols mean the same thing everywhere. To use your PHP example in Ruby, how about error_log(”user not found”, :user_not_found). In this example, you don’t know the languages you are criticizing.

No compiler
Please point me to a modern language that is slower with longer variable and method names. Ruby, Perl, Python, OCaml and Erlang all “compile” the code to an intermediate form (bytecodes) and then execute those. Long variable names or method names have no performance impact except during this “compile” stage when it parses the languages. *Every* language bears this cost because they *all* to have to parse the code at some point to either turn it into bytes or machine code.

No linker
Your argument here is about memory footprint. This is a total non-starter on any modern operating system that does demand paging. If huge sections of your ruby/perl/python/whatever library are not used, the OS will never page them into RAM. If I am misreading this and you are really arguing over disk space, then let’s just agree to disagree.

Multiple compile errors
This is a criticism of coding style. Apparently you think programmers who used these older languages sat down and spewed forth entire programs in a single sitting and then debugged them in one shot after getting a list of syntax errors. I prefer to write a test, watch it fail, write the code to make it pass. My programs generally never have more than a single error. But that’s just my style; use whatever you like but don’t blame the language if your style doesn’t fit it.

Formatted strings
This isn’t a language feature. It’s a feature of a language’s library. Any language, no matter how old or new, can easily support “sprintf” semantics including C++. You don’t have to use “<<” if it doesn’t have the feature you need.

Auto-creation of variables
This is another style criticism like your “Multiple compile errors” criticism. Let’s agree to disagree. I’m never more than one test away from discovering a misspelling which is equivalent to the compiler spitting out the error.

1 - There are so many new technologies that we spend less and less energy studying the past.

2 - Several features are dropped from new languages because the designers consider it “very dangerous, no _real_ programmer would ever use that”. As that’s a matter of opinion, we lose several powerful features just because they are… hmm… powerful. For example: GOTOs and Multiple Inheritance.