A+, the Programming Language of Morgan Stanley

http://www.aplusdev.org/index.html

by ausbah • 7 years ago

28 20 7 years ago

beagle3• 7 years ago

Last new feature added 16 years ago; Last fix (for 64-bit) done 11 years ago -- but likely, real development stopped a decade before that, when Arthur Whitney left MS.

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.

ajflores1604• 7 years ago

I literally just heard about K for the first time while listening to fast.ai founder Jeremy Howard talk about it in a podcast, less than 5 minutes ago.

(https://youtu.be/J6XcP4JOHmk?t=696)

Do you recommend any resources for exploring these array languages? They sound really interesting.

arthurcolle• 7 years ago

You can evaluate the 32-bit version of q by downloading the binary from here: https://code.kx.com/v2/

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.

hhas018• 7 years ago

Just something I stumbled on while rummaging around:

https://tryapl.org/

zwkrt• 7 years ago

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

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?

Fins• 7 years ago

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.

hhas018• 7 years ago

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

hhas018• 7 years ago

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

simg• 7 years ago

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.

lloydatkinson• 7 years ago

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

hhas018• 7 years ago

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]

colanderman• 7 years ago

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

hhas018• 7 years ago

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

kod• 7 years ago

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.

hestefisk• 7 years ago

Ghosu is another example, a JVM based language for the Guidewire suite of policy and claims systems.

hhas018• 7 years ago

I think the key to understanding APL is realizing that it’s not built for Programmers; it’s built for Mathematicians.

Here’s a fine half-hour introduction to APL in action:

https://youtu.be/_DTpQ4Kk2wA

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:

https://youtu.be/a9xAKttWgP4

For all its mechanical advances over the last 40 years, it’s shocking how far our technology has regressed philosophically.

throwerhover• 7 years ago

Anytime I think of a great DSL I think of Erlang.

A+, the Programming Language of Morgan Stanley

Related Stories