Yet another AI language you miss in your CV? 4 reasons why it will matter less and less.

It never hurts, but it varies how helpful a (fairly) new programming or script language is. From more or less a prerequisite in R&D and platform-vendor firms, to a nice-to-have CV footnote in mainstream businesses that rather emphasize extended SQL, analytics , data architecture, and automated ML platform/s.

Here are 4 reasonswhy you can live with it (ascending order by weight)

1. The fate of LISP, Prolog, Smalltalk, KQLM etc. (use comment form below to fill in what’s missing : ))

To drive the history of applied “AI 1.0” to the extremes, an enterprise in the 1980-ies was expected to achieve superpowers as soon as the CIO (and preferably, CEO : )) learned at least one exotic-enough AI language. The subsequent AI winter after 1990 happened supposedly because most CIO’s refused to so; best case: they got lost somewhere inside their fifth pair of nested parentheses in LISP (like most of us devs did too, including myself)…

2. The rise of expert-system development shells in business (near 1990)

Programming languages are versatile. You can get anything you need, given a generous timeframe. Development tools encapsulate a lot of technical detail. You can get more or less what you need, even under tight time constraints. No wonder it’s more appealing to CIOs than nested parentheses.

3. Success of those who used then-mainstream industry languages  

Books on configurators, or on LISP, drill down into Digital (HP) XCON/R1, but in books on management and modular manufacturing, you read about Scania Trucks & Buses (reporting profits for 80 consecutive years). Scania’s smart proprietary configurator (an age fellow of XCON) became a backbone of the enterprise, and grew to several times the size of XCON. Unlike XCON, Scania did cope in maintenance and upgrades. For decades. Offering complex customized vehicles assembled from a cluster of common component types. Language: unglamorous then-mainstream Cobol and DL/1.

4. A trend toward frameworks, component libraries, automated analytics & ML platforms

It’s a two-way street. On one hand, “AI 2.0” and ML challenge current architectures, not least data architectures: big-data ingestion, parallelism, fast access aid for non-sequential access because learning (in both human and artificial neural networks) is essentially non-sequential (parallel).

On the other hand, ML offers a toolbox to tackle these challenges, and also, enables quite some automation of the entire data pipeline and of an architect’s (or dev’s) repetitive tasks. I won’t be surprised if automated-ML platforms for big data, using extended SQL instead of script languages, spark success stories of Scania’s magnitude. It’s about the augmentation (or automation) itself, and about architecture fit for business, rather than about the detail.

So from now on, Informator’s new one-day course is called AI, Architecture, and Machine Learning. Neither just AI for Architecture, nor just Architecture for AI. It’s a two-way street.

Rapid progress in the middle

Figure from course AI, Architecture, and Machine Learning (T1913)

by Milan Kratochvil

Trainer at Informator, senior modeling and architecture consultant at Kiseldalen.com, main author : UML Extra Light (Cambridge University Press) and Growing Modular (Springer), Advanced UML2 Professional (OCUP cert level 3/3).

Milan and Informator collaborate since 1996 on architecture, modelling, UML, requirements, rules, and design. You can meet him this Spring at public Architecture courses in English or Swedish (T1913, T1101, T1430) or Modeling courses ( T2715, T2716)