Hacker News new | comments | show | ask | jobs | submit login

I had the good? fortune of programming in A+ (a derivative of APL) at Morgan Stanley in the mid 90s. Not sure if it is used there anymore. For someone coming from a background in object-oriented languages like C++ and Java (only just introduced in 1995,) A+ was utterly alien and incredibly powerful. A single line could accomplish stuff that would take 50-100 lines of C++. But that single line looked like Egyptian hieroglyphics! To even read or write code in A+ required a special font addition to XEmacs to work as the glyphs would not render in any other font. I never fully understood the art of programming in A+ in the year or so I had to work on the product that was written it it, but I was amazed at the things the experts in my team could achieve with it.



It is indeed still in use at Morgan Stanley in the Interest Rate Derivatives Technology group. Apparently there were plans to decommission the A+ code as far back as the early 2000s, but much of it is still in use and, from what I can tell, the users still have a fondness for it even in the face of replacement pieces done in Java/Scala/C#. Several A+ devs retired within the past few years, but they have been able to bring on new blood, which was surprising to me. I didn't do much A+ coding in that group, but it always seemed like a breath of fresh air working in A+/XEmacs where you could easily directly inspect the running program to either produce new results or investigate existing ones. It was certainly much nicer than working on the modern Scala project that would often take an hour+ just to rebuild if you happened to add some logging.


I’m envious. You essentially worked in the presence of a dying race of wizards.


I do wonder if the rise of spreadsheets played a factor in the demise of such language usage.


The glyphs are unicode now and I bet A+ is just legacy and new things are kdb+ which is the successor to A+. Can anyone confirm?


About 10 years ago, A+ was just used as the communications protocol for fixed income. Nothing (that I knew of) used it, but C++ ceremoniously created A+ objects, sent them over the wire to another C++ process that decoded them.

Around that time, we moved much of the mortgage models over to kdb and q, which was fun. Lots of weird dark little corners in that language. (List of dicts? Nope! It's a table now! 'sum x' drop NAs, while 0+/x was NA if any value was NA, but maybe only for ints, not floats, etc. Ugh.)


It is still there and open source [0] and I guess you can say k (not kdb or q!) are it's successors in some ways. Definitely in the way they are all very much APLs, with or without the glyphs. If you read the APL book by Iverson and then go to implementations of APL, A+, J, K, you'll notice differences, but there are all identical enough to pick them up fast once you are proficient at one of them. kdb+/q are different beasts and that is were the issues start (and the big bucks are to be found); debugging (performance) issues related to critical software written on top of k.

[0] http://www.aplusdev.org/index.html


Do you have any experience with kdb+/q? I was considering taking a job offer where I'd have the opportunity to learn kdb+/q but I don't have any experience with it and I can't find a huge amount of information about it online.


Despite my griping, I liked kdb+ and q. As a database query language, q is awesome, if you are doing a lot of time-series analysis (running sums, etc., nothing fancy). As a language, the table type in q is very nice, a bit like what pandas or data.table wish they could be.

For a while there was a freely downloadable version to try out, and you can look at "q for mortals", http://code.kx.com/q4m3/, to get some flavor.


They just made the 64 bit version free for experimenting with. It is annoying because it only will start up and run if you are connected to the internet, but it fully works. The 32 bit version can be downloaded as well and that fully works, with or without internet connection.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: