Making a Living in Languages (Redux) part 2: Every Application Architecture Has Plenty of Languages

Last time: “What Do Buyers Want?,” in which I said that employers want specialists in technologies, which doesn’t really help the employers solve problems.
Now: Where does that leave us? Where’s the language vendor in this picture? Where does the language guru go?

[This is an excerpt from a Lisp conference talk I gave in 2002.]

So, if you are looking for a job, you know what you have to do. For a given application architecture, figure out what tools will be demanded four or five years from now, and acquire that much paid experience using them. That can be tricky, because less than 4-5 years ago, the list for our bank application example would have been radically different.

But, if you’re a true language geek, you should be ecstatic about all the different languages you’ll get to use in the course of a typical n-tier project:

General purpose languages (sort of) include: C++, Java, C#, JavaScript, Perl

W3C happy-land includes: HTML, XML, XSLT, Xpath, CSS, SVG

The data level requires: SQL, Oracle stored procedures, LDAP, RDF

Application servers use their own languages: JSP, ASP, PHP, ColdFusion, DHTML, CGI

Special domains require one additional language such as: Flash, VB for MS-xxx, Powerbuilder, Siebel, SAS

Design tools have their own modeling languages: UML, ClearCase

Component architectures have their own language for describing the metadata that glues everything together: EJB, COM, CORBA/IDL, WSDL

The tools and services each have their own configuration language: for Apache, SiteMinder, UDDI, etc.

Well clearly there’s room for languages work, but where are the language products hiding?

next: Hidden Special Purpose Languages.
Start of nine part series.