Discussion on:

10 development technologies that refuse to die

It seems from some of the comments that many persons believe that software developers should constantly be changing the languages that they use to develop applications and, therefore, computer languages should have relatively short lifetimes.

I believe that this attitude is mistaken. There are many good reasons for some computer languages to last many decades, perhaps even centuries.

Please remember, computer languages are tools. Used properly, in a good-fitting situation, they can be highly productive and effective tools for solving complex problems.

Ideally, computer languages should be evaluated using bona-fide business and technical criteria. After all, decision makers should be much more concerned about productivity and effectiveness rather than what is the latest fashion or fad.

Consider the longevity of human languages. Some of them are thousands of years old. Modern variants that are understandable today are often centuries old. Consider:
* Greek has a continuous history of thousands of years.
* Latin, often considered by many to be dead, is still the official language of record of the Vatican.
* English is over a thousand years old, although Anglo-Saxon (Old English) and Middle English (e.g., Chaucer) are understandable only by trained scholars. However, most modern people can read early modern English (e.g., Shakespeare) without much difficulty.

QUOTE: "It seems from some of the comments that many persons believe that software developers should constantly be changing the languages that they use to develop applications and, therefore, computer languages should have relatively short lifetimes."

I don't see a lot of comments like that. Scheme, Smalltalk, C, ML, and Prolog are all old languages that are still around and still relevant, and they're all languages that have a lot to offer for years to come, and will require something revolutionary to make them obsolete.

This stands in stark contrast to languages like Java, C++, and COBOL. They can all be replaced, in terms of their technical designs and capabilities, with relative ease. It is social factors, financial barriers to migration, and a lack of serious efforts to replace these languages and their attendant technologies that ensures their continued prominence in various niches. References to the fact they are far from perfect and could stand to be replaced is not identical to a meaningless desire for change.

Let me see if I've got this straight. Scheme, Smalltalk, and Prolog are relevant and stand is stark contrast to Java and Cobol?!?
I have nothing in particular against them, but I don't know how you can call them especially relevant. They are niche players at best.

Next time you read up on new features being bandied about as possible additions to Java, check on where they appeared as early implementations in other languages. They'll have come from languages like Scheme, Smalltalk, or Prolog -- if not directly, then by having been the inspiration for a chain of descent that ultimately leads to Java.

How is the effort to incorporate lexical closures (first appearing in Scheme in 1975) into the Java language coming along, by the way?

The languages you dismiss as "niche" are still contributing "advanced" capabilities to other languages as the mainstream clods of language design eventually grasp the way these features work, figure out how to implement them, and begin to grasp their importance -- "advanced" capabilities that, in many cases, these "niche" languages have had for decades.

Relevance is influence, excellence, and applicability. It is not just popularity. In any case, you seem to think I said Java and COBOL aren't relevant. I said nothing of the sort. I said that they (and C++, even more relevant in the long term than Java and COBOL due to its profound impact on the world of computing and language design) are more easily replaced than Scheme, Smalltalk, and Prolog (as well as C and ML) in terms of technical designs and capabilities.

Of course, I should have specified *useful* capabilities, primarily to account for C++, which is bursting at the seams with capabilities that are overwrought and top-heavy, but that's not really relevant to the discussion of how Java and COBOL contrast with Scheme, Smalltalk, and Prolog. I find it odd, by the way, that you jumped all over those three languages as mere "niche" languages and ignored ML. Do you just not know what ML is?

Finally . . . I'd say that PHP, JavaScript, and COBOL are more properly niche languages than Scheme, Smalltalk, and Prolog. Well, Scheme and Smalltalk, anyway. Each of PHP, JavaScript, and COBOL is designed (badly) for a particular narrow purpose -- a "niche" -- and tends to fall on its face the moment it begins to stray from that niche. Of the three, JavaScript is the most flexible, a fact most attributable to the existence of the ECMAScript standard that ensures a certain amount of generalizability in the language itself even if not in its implementation.

The remarkable thing I've found about Smalltalk is it pioneered system features, like the modern graphical interface (overlapping windows, icons, menus), MVC (Model View Controller), the concept of the IDE (Integrated Development Environment), refactoring features in an IDE, cut/copy/paste/undo, not to mention blending the concept of closures with objects (in Smalltalk-80). Yes, quite relevant in terms of language and system design. It's kind of like Cobol in the sense it's no longer the hot language of the day, but is still used in important industries. Most people in IT don't encounter it, though.

fmajor7 brought back fond memories. I grew up on COBOL, FORTRAN, and Assembler, but later fell in love with PL/1. It could move entire data structures like COBOL, do scientific computations like FORTRAN, bit twiddle like Assembler, recursive calls like ALGOL, and matrix algebra like none. Like fmajor7 said, I developed many systems in my 35 year career. I suspect a few of these are still in service.

According to an MSDN page I read as well as several other blogs, Microsoft states that your use of MVC or Web Forms is task dependent. I believe I read somewhere something like "if your web app serves up a lot of data then you should use web forms."

To me that doesn't sound like they are trying to obsolete web forms.

If the title of the list is "10 Development Technologies that Refuse to Die," Java and Cobol should not both be on the same list. The list is a confusing mix of current and legacy development platforms.

4GL is still around and deeply embedded in many an ERP system.

Perl may not be on the list but is close behind. With its nature to evolve as a language, Perl code is going to around for a long time.

Gaz

VBA is still a great "code behind" language for manipulating the objects exposed by the MS Office apps. I'm a heavy user of VBA collections, and use this function to test if a key is present in a collection:

Public Function InCollection(c As Variant, ByVal k As String) As Boolean ' collection is Variant so it can be used with built-in collections
On Error Resume Next
InCollection = (TypeName(c(k)) <> "") ' if not in collection, or if c is not a collection, then error will occur
End Function

SQL generated by abstract tools not always have the best performance.
It's better and fast write down the fast SQL

Kenneth Iverson creature in still alive and kicking. With several vendors (IBM APL2, Dyalog APL, APL2000,...), forks/dialects (J, Q, A+,...), journal (Vector - https://sites.google.com/site/baavector) and market niches.

Widely used in financial applications. Recent development in the form of GT.M or InterSystems Cach??. The European Space Agency announced on May 13, 2010 that it will use MUMPS to support the Gaia mission. This mission aims to map the Milky Way with unprecedented precision

You forgot "PHP"

It might be more accurate to say we would like to forget PHP, but can't.

http://www.marco.org/2012/06/29/php-addiction

Just as COBOL is entrenched in the largest of corporate entities, so is RPG entrenched into the day-to-day workings of corporations that are using IBMi hardware. This language has decades of existence and continues to get used even today.

While these may be the toys that the 'popular' kids played with, there are also some more obscure things, such as M which persist. M is the most popular language used in healthcare and financial (including banks) institutions and has persisted long after the 'fancy' new stuff (much like COBOL / FORTRAN / RPG, etc...) M was developed in 1966 and is still everywhere. The implication that SQL is somehow beyond its prime, is just plain stupid and reflects more a person who is out of the loop. But then again, the world revolves around the Microsoft developer ... oh, wait SQL Server...

This is another language running on IBM AS-400 mainframes that is still chugging along. Used mainly for order entry screens and report writing, companies that have invested in this technology are slow to move away from it.

You say "until Microsoft come up with a suitable alternative". On past form, they'll come up with an unsuitable alternative, and withdraw VBA to *make* us use it.
Microsoft please note: millions of us know VBA - it works. If there's a problem such as checking collections please just add functionality. DON'T make tens of millions of us have to learn a whole new way of doing several hundred things each (for example, the doggone ribbon).

"why in the world does anyone actually write SQL into their applications? It should be the (very rare) exception, not the norm..."

probably the same reason people don't let Visual Studio write their HTML....

Every developer has his/her tool set. If they get the job done and the job is excepted by the end user, who does not care how it is developed just that it works for them, then these tools will live as long as the developer wants to use them or they are forced to use another tool.

First off, you should call the article "Languages", not "Development Technologies" that refuse to die. Development technologies that won't go away include things like using NotePad (or the equivalents, like teco, vi, or emacs!) to write your code in. I keep on running into having to use these truly archaic editors because the developers of new systems have just forgotten to create a new system for their new language.

The languages like FORTRAN and COBOL will, as you say, never go away. Assembly Code programming will also probably endure for things like device drivers, but only in very small niches.

As for SQL, it appears that the market for programming in SQL is alive, well, and very healthy. Why? Because the abilities and quirks of the target systems (databases) keep changing, so there is a large number of dialects of SQL (T-SQL, PL/SQL, ...), none of which yet meet Dr Codd's original requirements for complete adherance to the mathematical Relational Model, and none are likely to, as they grow ever further into non-relational areas.

What the heck does vi have in common with Notepad other than the fact they can both be used to edit text files? That's a bit like comparing an Olympic swimming pool with a rusted out old Pinto body flipped upside down and filled with water, an Amazon cluster running a million-user web application with a MySpace or Geocities page, or a local microbrewery restaurant's buffalo stirrup steaks with day-old Big Mac leftovers.

"Old" doesn't mean "bad" or "deficient". That's why modern LISP dialects are still among the most semantically powerful programming languages available, why Unix is still technically superior to MS Windows, and vi kicks the crap out of Notepad.

As for Emacs, that thing is a sprawling tentacular mass of features rivaling MS Office for the extent of its integrated capabilities -- both a blessing and a curse, as evident in jokes to the effect that it's a great operating system that only lacks a decent editor.

There's nothing meaningfully "equivalent" about emacs, vi, and Notepad.

... are all very powerful editors, when used by someone who knows how to use them. Notepad is not.

I figured that was probably the case, regarding TECO, but I have never used it myself and didn't want to make a mistake. Thanks for adding to the argument.

... that when well-meaning people say, "stay away from that, it's dangerous" -- that's where to look for the real power. TECO was all but banned from a shop I worked at long ago.

Right, why can't we be following Microsoft's lead and keep pushing new "technologies" every couple of years? Lets do retraining and rewriting... Plzzzzz...

Most items on your list here was created by non-MS. They were done right from the start and just enhanced. Not thrown away and redone like MS likes to do. I dumped all of MS products and Windows. I now use a Mac/Linux and program with LAMP. At least I know I won't find myself retraining for the 10th time because MS says so.

By the way PHP is old. But it wasn't dumped. It is being enhanced with few rewrites.

Is there a way to re-purpose information stored in a word document. For example a document may contain information for a facilitator and for a participant.
The information for the two would be mixed throughout the document. For example a page might start with the information for the powerpoint slides, below that info for the facilitator and below that info for the participant.

From this master document I would like to output/print just the powerpoint info/facilitator or the powerppoint info/participant.

You'd have to be barking mad or incompetent to do it though.

It's a document. It's purpose is up to you. You can print it out and then make several paper aeroplanes out it if you want. Or something useful like a paper hat

Many would wonder reading the list .. All these are techs that refuse to die!!??.. then which are those TEN LIVING ones.. that flourish as the leaders and thriving ..???

Relational databases are designed for the storage of sets and relationships among sets. SQL is a convenient language for expressing product and quotient spaces over those sets and relationships. Which is what you want to do with sets and relationships. Why anyone would say, "OK, I don't want to think about sets. I want to think about objects, but I still want to use an RDBMS to store my data", I don't know. The question isn't "Why do people still write SQL?" The question is, "Why do people use ORMs?"

RDBMSes are such a mature technology that, right now, better performance, stability, and functionality can be had by an ORM on top of an RDBMS than a purely object-oriented database.

In my experience with SQL, the main objection is if you're programming in any language besides PL/SQL on an Oracle RDBMS, you either have to use a macro language, or an API, to use it, rather than have the data access integrated into the language you're using.

I remember there was some technology in .Net that finally integrated data access into the language, but it seems to be frowned upon since its release, because of its use of dynamic SQL. So I think the point of any complaint about SQL is the fact that you have to effectively translate data between two runtimes. It would be nice if there were consistent rules for data between the language and the RDBMS, and data access constructs in the language that can interface with RDBMSes, as opposed to putting SQL into strings, and having no syntax & semantic checks until run time.

MS has made some attempts in that direction. I don't know about Java, only because I haven't used it recently. Sun/Oracle may have worked that out as well.

Re. apotheon's point re. ORM vs. an object database

Interesting point about the performance differences. Hopefully that'll be improved, 'cuz ultimately it would be nice to be able to persist objects. Have you checked out Gemstone's Smalltalk-oriented object database or Maglev for Ruby? I heard about both a few years ago, but I haven't kept track of them since. Both seemed to be designed for heavy data access, and large data storage.

As long as there are relational databases out there, there will be SQL and the prime reason is the fact it is based in something called relational algebra, which deals with relationships and operators in a formal (mathematical) way. The author mentions the fact that systems generate SQL anyway, but we have to keep in mind that there are different type of languages, while systems very well manage DDL, when it comes to DML, they have their limitations. When people have access to those systems, they may use them to generate version 0 of the program, but it require many iterations before they perform properly.

In it's day (the days of Ken Olsen and Digital Equipment Corp, I mean Compaq, I mean HP), TECO rocked. I wrote a TECO macro for a DEC System10 and later a VAX/VMS system, back before DEC had any account reporting capabilities, that would parse usage data out of system the log files and generate usage trend plots. Pretty pictures always got my upgrade proposals approved.

TECO sounds like it was pretty nice (as mentioned, I have not actually used it). Too bad it was effectively supplanted by emacs, rather than continuously developed as an updated editor in its own right.

... is that its syntax was cryptic, and if you made a mistake you could completely trash the file you were working on. With great power comes great responsibility.

That sounds somewhat similar to a vi user like me.

TECO was often scripted, including writing out the modified file. I guess you can be just as deadly with sed, though.