A+, the Programming Language of Morgan Stanley
aplusdev.org
aplusdev.org
The first is MUMPS, primarily used in the healthcare industry. The second was the Mason templating language used at Amazon, which allowed inline integration with Perl, similar to PHP, ASP, JSP, ERB, etc. Both were wildly frustrating to work with because the real knowledge was all tribal, they didn’t integrate easily with anything, and they seemed like a waste to learn since I knew the knowledge was not transferable.
The commonality to any language used primarily in a single industry is that it is dead on arrival. As soon as the original maintainer is gone the language freezes. Things the maintainer may have considered bugs become specs, things to-be-done never are, and no one can be truly at the helm when the language needs to respond to change over time.
A company/industry is not in a good position to maintain a language, they simply use languages as-is to solve their problems. Think of it as the industry considering expenditures on improving the language as capex, and a company doesn’t spend capex unless it has clear bottom-line justification. “The devs are unhappy” is not such a justification, certainly one not understood by accounting.
I know this isn’t always the case though, are there such languages that seem to be thriving?
Seen them? Hell, I write them.
“The commonality to any language used primarily in a single industry is that it is dead on arrival. As soon as the original maintainer is gone the language freezes.”
There’s absolutely nothing magical about a domain-specific language; it’s just one more business tool for solving a specific set of business problems. If a proven DSL fails to outlive its original creators, that’s a failure in business continuity and product lifecycle management; a common business failing across all types of business apps, not just DSLs. I’m sure we’re all familiar with the kinds of implacably progress-hostile C-grade managers and self-serving code monkeys whose only skill is in dragging everything down to their own level of incompetence and killing it with apathy.
One place I worked, I built them a DSL-based system that was 10 years ahead of anything their competitors had, and yet I could not for the life of me get them to hire another dev to ensure project continuity. Unsurprisingly, when I finally quit due to burnout, they failed to replace me, effectively writing off a $200K investment and squandering who knows how many $Millions in sales opportunities without a though. (Back-of-an-envelope: this tech could cut their manual production costs by 20-80%.)
But like I say, this is not a DSL-specific failing. That place also had a major enterprise CRUD webapp as their prestige product; a massive ball of mud that they were unable to maintain due to bad lifecycle management and rapid developer turnover. And that product had a team of 20 on it compared to my “team” of one, so you can imagine the amount of investment already sunk into that. Last I heard they had finally given up trying to develop it any further and were attempting to build a completely new <del>ball of mud</del> webapp to replace it; no prizes for guessing how that was working out.
There’s a common theme here, which has less to do with the kind of company-specific application than to the company’s own attitudes towards it. Which is why we have TheDailyWTF.com, although the same sorts of fuckups can apply to all types of product in all types of business (and regularly do).
Though considering payroll’s one of the oldest and most solved problems in software development (Hi, LEO!) I do wonder what benefits a custom language could over current over off-the-shelf tools. Could be a legacy thing, in league with those old COBOL mainframe systems you hear about, lurking in shadows, waiting to teach all you kids nowadays a thing or two about walking fifteen miles in snow, uphill both ways… [cont p.94]
All knowledge is disposable. What’s transferable is the ability to learn, along with the deeper insights and understanding of the problem space which its practice brings.
Pathological packrats who pride themselves on the great volume of knowledge they possess are a good chunk of what’s wrong with today’s programming profession [sic]. Me, I trained as an artist, and the first lesson of value it taught me: If you can’t/won’t/don’t learn how to throw away and start over as easily as breathing, you may be mediocre but you will never get good.
I have never seen a job advert that says "we don't care what skills you already have so long as you're good at learning".
Without the right keywords on your CV there's a good chance no-one will even see your CV because it gets automatically filtered.
Beyond indicating a degree of experience in the hiring company’s primary development language and perhaps a couple major libraries, it really is a worthless measure of anything, except perhaps of middle management that doesn’t understand shit about what it is it’s meant to be managing. Like I said, programmer attitudes are a part of the problem.
But I’m preaching to the choir here. If it’s any consolation, if was hiring I would rate Ability to Learn way more highly. As I observed on another thread recently:
“The key to being a competent software developer is really, really simple: Learn the Business. Because if you can’t/won’t/don’t understand the problem domain, how can you expect to solve problems in it?”
If what the company does require an “exotic” or bespoke language to beat its competitors, that’s just one more work tool to be learnt and used (and maybe learn from) for the duration, and price yourself accordingly.
I suspect the best you can do at is read between the lines on the resume and ask searching questions at interview, searching for indicators that the candidate is an active and competent learner, not merely an effective chair warmer. Someone who shows an eagerness to step outside her comfort zone; who makes a point of talking with, and learning from, her users. Beyond that, well, that’s why new hires have probationary/trial periods, so that our initial guestimates of her abilities can be tested in battle.
Of course, all this presupposes you have a management and HR culture that expects managers and HR to know enough about computer programming and software development to be able to ask the right questions and make qualitative judgements on the responses. And, needless to say, just as there are way too many coders who don’t give a shit about anything except coding, there are way too many managers with zero clue how to do anything other than manage.
But if you don’t know jack about what it is you’re meant to be managing, how do you possibly expect to manage it effectively?
See also:
I suppose it depends on what you mean by “tribal”. A good DSL is naturally tribal: it serves a very specific user base in a very specific field. If you aren’t one of that audience already educated in that field, of course it won’t make much sense to you. A language tailor-made for the medical industry might well seem alien to a non-medic. Unfriendliness to outsiders does not mean it’s a bad language, it just means outsiders have a far larger learning curve to climb to get anywhere productive.
I suspect in MUMPS’ case, its <cough>issues spring more from being a Product Of Its Time; passed through software, hardware, and wetware of the same. It’s of the same generation as COBOL, when language design itself was an unexplored territory. It wasn’t until the likes of Algol 60—and Algol 68(!)—that programming languages really fell into the “standard ways” of doing common things. And even that’s proved a double-edged sword, as the established ways of doing many things have long since proven unreliable unscalable crap; Peter Principle in code.
As for Mason, show us an HTML templating language that isn’t the size of Trump Tower, and I’ve no doubt behind it you’ll find at least two of its predecessors that were. Programmers just LOVE generating Complexity—it’s exciting! Plus, until you’ve really worked a problem and solved it a couple times over already, it’s tough enough just getting to something that works; never mind works well and is as simple as it possibly can be too.
[Aside] Funny enough, it was HTML templating where I cut my own design teeth. Truly, every programmer and their mother seems to write one. Took me three attempts to get from grotesque unmanageable monstrosity, or SOP, down to something that was just three methods long. Which, it turns out, is all that job actually takes: insert, iterate, and delete; everything beyond that is just ego-inflating bullshit. But I never knew that going in, and neither, clearly, does anyone else as programmers are still inventing vast baroque HTML templating languages that take Greenspun’s Tenth Rule and delightedly poop all over it.
Thus, I’d say MUMPS and Mason are fine examples of at least one, probably two, custom languages that should long since have been superseded by newer and better solutions but haven’t been, at least in part because no-one in this industry can be bothered to learn from what has gone before. Or, as Keith Braithwaite put it:
“It's a curious thing about our industry: not only do we not learn from our mistakes, we also don't learn from our successes.”
And if ever there was an acid test for this, I’d say languages are it.
--
TL;DR: While niche domain languages are at least as subject to Sturgeon’s Law as mainstream industry ones are, what actually differentiates the two is that all of the former’s frank fuckups are entirely random and unique, instead of ISO standardized and taught in school.
See also: http://james-iry.blogspot.com/2009/05/brief-incomplete-and-m...
Here’s a fine half-hour introduction to APL in action:
1:00-2:00 is the motivation for APL—or any DSL—in a nutshell. (“conversational computing”, “users who are [not] professional programmers”)
Or, if you’re happy to sit back and see math magic happen:
For all its mechanical advances over the last 40 years, it’s shocking how far our technology has regressed philosophically.
What he did later was create K (and kdb+ and now shakti), which are significantly farther away from APL (of which A+ is mostly just a very opinionated dialect), but which I personally find overall cleaner and more consistent.
(https://youtu.be/J6XcP4JOHmk?t=696)
Do you recommend any resources for exploring these array languages? They sound really interesting.
The setup is a little annoying and you have to make sure q and the license file are in same directory or something, I vaguely remember that the error message was pretty cryptic but it is definitely worth taking it for a spin. It is an interesting piece of engineering and there are many interesting example scripts that you can find on the Web, although actually becoming productive in q is another matter entirely.