9 ms·

A+, the Programming Language of Morgan Stanley

28 points by ausbah 7y ago

beagle3 7y 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 7y 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 https://youtu.be/J6XcP4JOHmk?t=696) Do you recommend any resources for exploring these array languages? They sound really interesting.
  - arthurcolle 7y ago
    You can evaluate the 32-bit version of q by downloading the binary from here: https://code.kx.com/v2/ 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.
  - hhas01 7y ago
    Just something I stumbled on while rummaging around: https://tryapl.org/ https://tryapl.org/
zwkrt 7y 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 7y 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.
- hhas01 7y 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).
- hhas01 7y 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.
hestefisk 7y ago
Ghosu is another example, a JVM based language for the Guidewire suite of policy and claims systems.
hhas01 7y 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 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 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 7y ago
Anytime I think of a great DSL I think of Erlang.

28 points by ausbah 7y 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 7y 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 https://youtu.be/J6XcP4JOHmk?t=696) Do you recommend any resources for exploring these array languages? They sound really interesting.
- arthurcolle 7y ago
  You can evaluate the 32-bit version of q by downloading the binary from here: https://code.kx.com/v2/ 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.
- hhas01 7y ago
  Just something I stumbled on while rummaging around: https://tryapl.org/ https://tryapl.org/

zwkrt 7y 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 7y 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.
hhas01 7y 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).
hhas01 7y 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.

hestefisk 7y ago

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

hhas01 7y 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 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 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 7y ago

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