Hacker News Reader

“I have seen two similar “company-specific” languages in my relatively short career”

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).

Erlang (from Ericsson) turned out OK: https://en.wikipedia.org/wiki/Erlang_(programming_language)#...

I'm not sure Mason is the best example here. It had an O'Reilly book http://shop.oreilly.com/product/9780596002251.do and was used by the RT bugtracker, as well as non-Amazon businesses, including the largest Usenet provider in the world.

Custom languages like that are one of the many reasons I said no to a job offer from Capita. Amongst other things I'd be working on the payroll system (something to do with it, I forgot since) with their custom language. Absolutely not transferable in any way and as you say probably tribal knowledge. Can't imagine how frustrating that sort of thing is...

Of all the reasons to say “no” to a job at Crapita (see Eyes passim), having to pick up a custom language sounds like the least of them.

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]

“I knew the knowledge was not transferable.”

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 agree with you, but on the other hand all tech jobs appear to have a hard requirement for <x> years experience in particular languages or technologies.

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.

True dat, but what does “must have 20 years’ experience with $technology” even mean? Using it day-in, day-out, for the last 20 years? Originally learning it 20 years ago, and periodically brushing up on the current release every few years when a project for which it’s actually appropriate lands on your desk? Or one year of experience, repeated 20 times?

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.

But how would you test a candidate for their "Ability to Learn"?

Good question, and I think it reveals an embarrassing truth about common hiring practices: they’re designed to test for qualities that can be trivially tested for, rather than qualities that are actually productive down on the shop floor.

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:

https://i.redd.it/vhoy65xmfegz.jpg

https://pbs.twimg.com/media/CpsutgxUIAE2h3i.jpg

In case of MUMPS (or M, these days) it seems to live on as Cache and GT.M, among other things, and is used not only in healthcare but in finance as well.

“Both were wildly frustrating to work with because the real knowledge was all tribal”

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.