21 ms·

Ruins of forgotten empires: APL languages

135 points by erehweb 13y ago

cabacon 13y ago
I have had a huge amount of fun lately going through the J labs. Start at jsoftware.com to download the interpreter, then the labs are all built into the interpreter. You can also run it on iOS. The terse code actually means you can type in real programs even on an iPod keyboard. When I taught people to play frisbee, I used to throw with my off-hand when teaching, because it made me pay attention to the fundamentals I was trying to teach. Learning J had some of that same feel. I felt like a newbie, but when I saw the kinds of audacious programs you could write, I was hooked. Highly recommended for a bit of fun in your spare time.
- deleted 13y ago
  [deleted]
- kaoD 13y ago
  Same here, but I found it extremely hard to find real world use cases for the language. It's fun as hell, but for me it's a puzzle, not a programming language. Anyways, making cellular automata is fun as hell! :P
- saryant 13y ago
  I went to a small university with only 8 CS professors. One of them was the author of J's array parallelization and he taught our Intro to Functional Languages course. That class was fourth in the undergrad sequence, coming after C, C++ and Java so it was quite a shock to, well, everyone. He took us from finding the average of a list all the way through to implementing a CMS in J (our department web server still runs on J because he's since retired and no one else knows how to maintain it). This was easily the hardest class in the entire department. Students who sailed through everything else would struggle to pass. It's a fascinating language but not an easy one to grasp.
hat_matrix 13y ago
How is lush an old language? Looks like a language that was released last decade, but just never caught on.
- scottlocklin 13y ago
  Lush as a language was developed in 1987, just like it says on the website. Older versions of it are reading the numbers off of your checks when you deposit it in the ATM machine. The ideas it embodies are significantly older than common lisp: it is a very pure hackers lisp: sorta has the eau de zetalisp about it (not that I really know anything about zetalisp, I ain't that old, but I've read about it). Studying it will make your brain grow. http://lush.sourceforge.net/credits.html http://lush.sourceforge.net/credits.html
  - hat_matrix 13y ago
    Actually it says that Lush's predecessors were developed in 1987. Version 1 of Lush was released last decade. But even if it was 1987, that's not older than Perl or Python.
    - cbr 13y ago
      Perl was started in 1987, Python in 1989 [1]. [1] http://python-history.blogspot.com/2009/01/brief-timeline-of-python.html http://python-history.blogspot.com/2009/01/brief-timeline-of...
    - scottlocklin 13y ago
      Well, if you download, say, TL3 from Leon's page (a subset of SN), you'll immediately see that the "predecessors" are essentially the same language. Same Ogre, same UI. You can even call pieces of it in modern Lush. The name change is irrelevant. http://leon.bottou.org/projects/tl3 http://leon.bottou.org/projects/tl3
  - lsh 13y ago
    "eau de zetalisp" => "water of zetalisp"
jdn 13y ago
The authors response in the comments to an overzealous attempt at political correctness was wonderful.
- _delirium 13y ago
  I looked for it after seeing this comment, and the response came across as kind of juvenile to me.
  - jdn 13y ago
    It was a juvenile response to a juvenile comment
    - jamesaguilar 13y ago
      If it was a juvenility contest, the response won by lengths. The response also won in mean-spiritedness and unnecessary escalation.
- lclarkmichalek 13y ago
  > You may now go fuck yourself with a carrot scraper in whatever gender-free orifice you have available. How the fuck is that "wonderful"? The comment was something along the lines of "I wish people wouldn't use that kind of language", and the response was in the form "If I insult you enough, I don't have to acknowledge your argument". Looking at the other comments, the one nitpicking about the choice of Lady Gaga is equally as useless, but strangely that one didn't get an angry reply.
  - jdn 13y ago
    That line was a bit juvenile, granted. The other comment wasn't really nitpicking. The commenter believed that Gaga has genuine musical ability, and the author wanted to make it clear that it was that classical training that made her the target of his blog. I don't want to misinterprete your meaning here, but are you trying to suggest the author would only react angrily to a female/feminist commentator?
prezjordan 13y ago
If anyone here is proficient at J, please (pretty please) contribute a guide to Learn X in Y [0]!! I don't run the site, I just really want a J guide in this format. [0]: http://learnxinyminutes.com/ http://learnxinyminutes.com/
- scottlocklin 13y ago
  Try this: http://www.jsoftware.com/help/primer/contents.htm http://www.jsoftware.com/help/primer/contents.htm Or, download it and run one of the intro labs; that's even better.
- silentbicycle 13y ago
  As Scott Locklin said in a parallel comment, J already comes with excellent documentation and tutorials. This would be a better starting place: http://www.jsoftware.com/jwiki/FrontPage http://www.jsoftware.com/jwiki/FrontPage As a language, J isn't ever going to fit comfortably into a "Learn X in Y" format -- there are too many unfamiliar ideas, it isn't just syntax.
lmm 13y ago
This happens with proprietary languages. How many people can afford $100k/CPU, however good it is? How many can play around with a language like that at home? Who's going to write infrastructure around such a thing? Hadoop is pretty crap - I know, I used to use it professionally. You know what else is crap? Unix. People are going on about cgroups as an exciting new feature, when better implementations were around what, thirty years ago in Real OSes. It doesn't matter. Commodity wins, and sooner or later if there are good ideas to be had we'll find them again.
- hat_matrix 13y ago
  So what isn't crap?
  - lmm 13y ago
    Stuff made in industries more mature than software. Bridges were probably all crap for the first fifty years of building them too.
- jingo 13y ago
  s/Unix/Linux/ When you say "Unix" did you mean to say "Linux"? "Real OSes" Can you name an example or two? I'm aware of some old non-UNIX OSes that are still around but which over time have become largely ignored. I'm curious the "Real OSes" you were thinking of. "How many can play around with a language like that at home?" As many as have the desire and time to do so. Learners are limited to 32bit and no long running jobs in excess of 1 hour, but this does not stop anyone from learning the language. There's also an open source alternative of the intepreter based on an earlier version of the language.
- stass 13y ago
  How APL is proprietary? Anybody can implement it, and there are opensource implementations available. The 100k/CPU price the author referred to was about the high performance database integrated with a vector processing language engine. It is not about commodity. cgroups-like functionality was available in many opensource OSes for years (e.g. FreeBSD jails), but was easily dismissed by majority as worthless. This is exactly what the author was talking about referring to Lady Gaga -- the modern programming community is driven by fashion regardless of how good or bad the current fashionable technology is. I do not find it surprising however, as it is a direct result of the order of magnitude growth of the programmer's population, which is behaviorally much more close to the general population currently that it used to be.
cmccabe 13y ago
This paints a really misleading picture of what is available in Hadoop right now. Columnar data formats? Yep, we've got them-- see Parquet [http://parquet.io/ http://parquet.io/]. Yes, Hive spends a lot of its time reading and writing data. This is because it decomposes SQL queries into sets of MapReduce jobs, all of which must take input from the filesystem and write it to the filesystem. That's one of the reasons Cloudera Impala was developed [http://blog.cloudera.com/blog/2012/10/cloudera-impala-real-time-queries-in-apache-hadoop-for-real/ http://blog.cloudera.com/blog/2012/10/cloudera-impala-real-t...]. If you don't like for loops, yep, we've got that too-- use Scala or another functional programming language to write your MapReduce jobs. Or use SQL, which is a lot more powerful than APL, and a lot more accessible to businessey types than functional programming. SQL is a declarative programming language, by the way-- I don't see any for loops there. The efficiency argument makes no sense either. Does the author understand that a just-in-time dynamically recompiling virtual machine is faster than an interpreter? If so, he doesn't mention it anywhere. You know, sometimes old technologies are just... old. You could at least compare Java and the JVM to something like Lisp machines. People overestimate the gains that are to be had from mmap. I am currently in the process of adding mmap support to HDFS and I know what I am talking about. mmap gives gains, but only when the data is coming from memory, and only when you can reuse the mmap. Otherwise, you're better off reading even a 512 MB file via read() and write(). The reason is that syscall overhead is not that high on modern UNIXes (like Linux), and page faults involve a transition into kernel space anyway.
- gngeal 13y ago
  Or use SQL, which is a lot more powerful than APL How could that possibly be true? What does "powerful" mean? Certainly not that it can compute things that APL family languages can't, and the design of APL/J/K etc. as languages is so much better that it isn't even fun. SQL is the COBOL for the 21th century. Does the author understand that a just-in-time dynamically recompiling virtual machine is faster than an interpreter? As memory latencies relative to instruction execution times go up, this factor becomes less and less relevant. An even worse problem is that your "just-in-time dynamically recompiling virtual machine" can't even vectorize properly, whereas APL has high-level array manipulating operators that make it comparatively easy to generate vectorized code. Your "just-in-time dynamically recompiling virtual machine" would have to "intelligently" recover high-level patterns from seemingly nondescript for() and while() loops to do that. Guess what: it doesn't! When you consider the fact that memory latencies matter these days, the fact that an AVX vector instruction can do a whole lot of work in a single cycle (or a few of them at most), and the fact that the integer units that would otherwise be idle can handle dispatching the next primitive operation in the meantime, there's a potential for even an interpreter to kick your "just-in-time dynamically recompiling virtual machine"'s ass.
mattdw 13y ago
He'd rather write in Beethoven languages than Lady Gaga languages. Which is fine, but there's something to be said for "takes 3 minutes to perform with one voice and one computer" as against "takes an hour to perform with a team of 30 highly specialised professionals." To stretch his metaphor.
ginko 13y ago
> APL is a mistake, carried through to perfection. It is the language of the future for the programming techniques of the past: it creates a new generation of coding bums. - Edsger W. Dijkstra
- jacques_chester 13y ago
  You can find an acidic Dijkstra quote for every language of his time. Dijkstra, I think, viewed mere languages as an unhappy by-product of computer science and hankered to do it all with mathematics, actual utility be damned.
  - gngeal 13y ago
    Alan Kay seems to think along similar (though not identical) lines these days. The sheer inertia of ordinary programming language implementations means that by the time you get to use it, you may realize that something "slightly different" would have been better, but you seldom have any other option than to "suck it up".
    - jacques_chester 13y ago
      Economists have a term for it -- Path Dependence. Some decisions have a high enough reversal cost that they are in practice irreversible. This means that one's future decisions are dependent on historical decisions over which one might have had no control. In our case: once a technology is deeply rooted, it's hard to displace. More closely, the Rogers model of diffusion[2] has 5 factors of diffusion (relative advantage, compatibility, complexity/simplicity, trialability and observability). Generally even the most advantageous language transitions score well only in relative advantage. The other diffusion predictors are missing or weak. [1] http://en.wikipedia.org/wiki/Path_dependence http://en.wikipedia.org/wiki/Path_dependence [2] http://en.wikipedia.org/wiki/Diffusion_of_innovations http://en.wikipedia.org/wiki/Diffusion_of_innovations
- coldtea 13y ago
  Dijkstra never had anything relevant or wise to say about any programming language (including the few he did like). In general, he was good at the math part of computer science, terrible at the computer part.
jacques_chester 13y ago
The most common "perform operation on bulk data simultaneously" language in wide use today is SQL. Joe Celko coined a phrase for this: think in sets. Not in loops, not in linear instructions -- but in sets, being transformed into other sets. It's a very powerful way of thinking. Most of the time, you don't need ordered evaluation and so loops are imposing unnecessary guarantees on you. On the more general problem of our collective historical ignorance ... yes. That is us. Well not entirely. That decades of the relevant literature is locked up in Fort ACM and IEEE Castle has a lot to do with it.
- jamii 13y ago
  The BOOM guys have also shown that thinking in terms of unordered collections translates much better to distributed systems, where guaranteeing order is expensive: http://boom.cs.berkeley.edu/ http://boom.cs.berkeley.edu/
  - gtani 13y ago
    The other day i thought i had found a textbook chapter on stream algo's/online learning, but Chapter 17 has yet to be written http://ciml.info/ http://ciml.info/
  - stass 13y ago
    BOOM project came up with a very impressive ideas. Their half page long paxos implementation in Overlog blew my mind. I don't think they new Bloom language is as expressive, however.
  - beagle3 13y ago
    I'm going to read about BOOM later, but can you give an executive summary about why that is? People who subscribe to the Relational Database dogma often claim that sets are superior to vectors, and yet despite asking a lot of them I never received an example -- whereas I have numerous real life examples in which vectors are superior.
    - jacques_chester 13y ago
stiff 13y ago
There is no shortage of excellent work being done today, too. With the large systems that are being created today I would take Python over APL or J any day, can you imagine building a company like Google or Facebook on top of APL, even assuming you would manage to find a team of good APL programmers? It is not a language fit for cooperation nor for large systems, it is a problem-solving language, back from the day where people used computers for relatively small tasks. Plenty of the good things in APL are now available in other forms anyway. NumPy with it's powerful set of linear algebra primitives and the huge set of implemented algorithms is just as great at data crunching. Want mmapped files? No problem: http://docs.scipy.org/doc/numpy/reference/generated/numpy.memmap.html http://docs.scipy.org/doc/numpy/reference/generated/numpy.me... That's not to say APL is not worth studying, it is built on powerful ideas. But to study the masters is to criticize the masters, not only blindly admire them. And history is not all romantic.
- hat_matrix 13y ago
  And R also has mmap, which is the the relevant package to reference rather than bigmemory in the original blog post?
  - scottlocklin 13y ago
    bigmemory is a better package.
- yummyfajitas 13y ago
  There are big companies built on top of APL like languages. One example is Morgan Stanley (K). You are correct that not everything is built on K - typically there are gigantic concurrent enterprisey systems build in java/c++/scala which shell out to a computational core built in K. You are also right that Python/Numpy is getting to be a good alternative to K, giving you less performance but better cooperation. That's why BankAm is building their SecDB clone on top of it.
  - oddthink 13y ago
    I definitely miss having the Morgan Stanley site license for K at my disposal. I can't quite justify the money to get a license, just for me, so I've been slowly assembling a poor-man's substitute built on numpy, pandas, and hdf5. K itself isn't as consistent as I'd like (odd corners like the auto-casting arrays, especially dict arrays to tables, and skipping NaNs in sums), but it's a great place to start. J really needs a table or dictionary data type, or at least the tools to make one yourself.
lcedp 13y ago
I had some fun with J. But it's (you know what I'll say) too cryptic.. Let's take an example from RosettaCode. For instance, merge sort: merge =: ,`(({.@] , ($: }.))~` ({.@] , ($: }.)) @.(>&{.))@.(*@*&#) split =: </.~ 0 1$~# mergeSort =: merge & $: &>/ @ split ` ] @. (1>:#) I could probably write it, but read what it does in a few weeks?
- michaelfeathers 13y ago
  Maybe it takes more than a few weeks. People half-way across the world read text like this everyday: 中國哲學書電子化計 C looks like that to most non-programmers. We forgot how much we have acclimated to already.
  - lcedp 13y ago
    Actually it's a very good example. Is 中 a word? Or 中國 a word? Or 中國哲 is a word? One can't say until they read a full sentence, making sense of it and distinguishing words from context. Similarly, can you clearly distinguish operators here ",`(({.@] , ($: }.))~` ({.@] , ($: }.)) @.(>&{.))@.(@&#)"? Sure, we can acclimate to a lot. Assembler is also a language. But nobody gonna write Hacker News in it.
    - gd1 13y ago
      Don't mistake looking complex for being complex. These languages have very simple and clean grammars (or they'd fall apart quickly), which is quite a contrast to the dog's breakfast that is modern C++. A simple grammar = simple to read once you've learnt the syntax. There's no issue in having a lot of symbolic operators if they all work in a clean and consistent way.
      - kd0amg 13y ago
        Unfortunately, J's grammar isn't the cleanest. It uses juxtaposition to mean about a dozen different things depending on whether the tokens are data, first-order functions, or second-order functions and how many are juxtaposed. A variable could stand for any of these. If there are variables in the expression, you have to know which variables stand for which kinds of objects in order to parse the expression.
useful 13y ago
1/2 our codebase is in APL. It is a good calculator.
perlgeek 13y ago
I am a bit disappointed by the low ratio of technical content to rambling. And much of the technical content seems to set apart APL from C, but not from many modern languages. For examples languages like Fortress contain primitives for parellelized loops, and most modern languages also contain enough functional programming that you rarely have to write for-loops. Function composition and interactivity aren't a unique feature of APL languages either. There are some other things that are important for programming today: Maintainability, richness of available libraries/modules, packaging, versioning and so on. Where would I even look for existing APL libraries? My searches for a HTTP library for APL (for example) have turned up nothing, while searching for a HTTP library for several other languages that came to my mind brought up useful results.
- klibertp 13y ago
  There is HTTP library in J (APL "spiritual successor") standard library. There is one for APL for sure - it's just less popular and so the google results are less helpful. Unique features of J (I'm writing about J because I know it, while I don't know APL) are that all the basic verbs (functions) can operate on arrays as easily as on atoms. There is no special syntax or feature for adding two matrices, for example, standard `+` verb does it naturally. The second unique feature is a tacit - point-free - style by default. This means that function composition is the default, not function application. You can define new words by just slapping old ones together, without worrying about threading params through them. The third unique feature (and probably unique to J, previous are found in APL too) are complex rules of composition (hooks and forks) as well as words that modify functions. You can express very complex things in very little space thanks to this. J is very interesting, unique language which are very well suited to one thing - very fast and efficient array transformations - and completely useless for other things. I hear it's used in a financial and banking sectors, for rapidly prototyping and sometimes deploying statistical and mathematical algorithms. If you have a good enough use case, then learning J will pay off. For anything less than full time commitment, I think that R od Python+Pandas is better. Still, I'm very happy I tried to learn J, as it's completely unlike anything else and it helped me greatly to understand numpy/pandas for my main job.
eliasmacpherson 13y ago
My only knowledge of APL is second hand via Scott Meyer's "More Effective C++" where he gives it as an example of the benefits offered by lazy-evaluation, saying that rather than compute the results of each statement in series it makes a compound statement where it computes only the result needed. In my own situation APL is a language looking for a problem - I don't currently have a use case for it. http://books.google.ie/books?id=azvE8V0c-mYC&pg=PT121&lpg=PT121&dq=more+effective+c%2B%2B+APL&source=bl&ots=46hf09Ni3j&sig=rqutwxurvUWv5uQcL9KpQ1IbKI0&hl=en&sa=X&ei=BBz1UYOOGvGP7Ab8oYHICA&redir_esc=y http://books.google.ie/books?id=azvE8V0c-mYC&pg=PT121&lpg=PT...
michaelochurch 13y ago
q is a neat language, and I spent some time studying it when I was in finance, because it's useful to know q/kdb if you're a quant. Here's an offensive but accurate taxonomy. There are 6-month languages/technologies and 20-year languages. The 6-month set are optimized toward being quick to learn fast. Java, for example, inherited C++ syntax while cleaning up the OOP, so the C++ programmers of the time could pick it up in quickly. Now, q and kdb are 20-year languages. It doesn't take 20 years to be productive with them, of course; it's that they're designed to optimize a person's productivity over 20 years, and not in the first 6 months. Unlike the various distributed tools out there (Hadoop, Hive) it will take you a long time to learn them, because they aren't like anything else. Superficially, q is Lisp-like, but the performance implications are very different and it doesn't look like a Lisp at all. (It parses right-to-left, for one example; also, it's written as a stream rather than in nested s-expressions.) Many of these modern tools being bashed have grown up in a world where 20-year tools can't really be built; they'll never catch on commercially in a world where people change jobs every 2 or 3 years, when MVPs are more important than solid decades-proof engineering, and where employers are pretty averse to their people taking time to just learn new technologies. There's too much volatility in the world for it to make sense for most people to learn q and kdb right away. You can get half-decent in a couple months, but it'll take much longer to learn why those tools are (for some use cases) so damn powerful. This 6-month vs. 20-year tool concern is part of why I've gravitated toward Clojure recently. I haven't seen anyone else do quite as good a job of balancing those two need sets as Rich Hickey and the Clojure community have. Clojure is (becoming) a 20-year language, but it's no harder to become basically productive in than Python or Ruby.
dschiptsov 13y ago
The beauty of a programming language comes from being small and consistent. Such as Smalltalk, which has only 6 reserved words and implements message-passing as if it is a function call. This is the brilliant idea of Smalltalk - message-passing + blocks + booleans and out of this everything else is implemented. Classes are of second importance, but delegating (via message passing) to parent or another object was invented here. Scheme, on the other hand, was also minimalist and consistent - s-expressions and about dozen special forms, and out of this everything else could be implemented, including closures, continuations, and classes and message passing, if needed (CS 61A 2008 does this for you). Haskell is.. well, everyone know what Haskell is. As for APL, in my opinion, the power of a language comes not from using esoteric math notation, but, like in CL or Scheme, from possibility to easy add new control structures (call/cc) and special forms (with macros) or even create a new languages, such as Arc.
- rossjudson 13y ago
  Minimalism is oversold. K specifically eschews minimalism, providing an essential list of operators and combiners (verbs and adverbs). It's no "6-word" language. Every character is a word in other languages. We don't have six characters in the English language.
  - dschiptsov 13y ago
    minimalism in itself is not the key, but being small, consistent and good-enough is.
  - kansface 13y ago
    Right, and the English was designed to perform the function that it does. Perhaps a sane implementation of the language would use far fewer characters.
    - lttlrck 13y ago
      "designed" is the last word I would use to describe English :)
deleted 13y ago
[deleted]
robomartin 13y ago
I used APL extensively for about ten years. I was introduced to the language by a physics professor in college who was quite vocal about having his students learn the language. I ended-up using it professionally for a wide range of applications, from inventory management and core business operating systems to robotics and DNA sequencing. While the language is wonderful I would not use it for production systems today. It is my opinion that the language came to be too early and, as a result, has not seen innovation for decades. It also does not help that the leading APL implementations cost thousands of dollars to license. APL is still being used extensively in financial institutions in Wall Street. J has been mentioned here a few times. Even though J is the work of APL's creator, Ken Iverson, whom I had the pleasure of meeting at various APL conferences, I consider it an abomination and a huge step backwards. I have a feeling Ken might have sought more commercial appeal by using ASCII characters rather than specialized notation. Ironic because of [1]. However, in making this switch, he created a horrible mutation that anyone can rightly recoil at. The language looks like a random vomiting of ASCII characters on the screen. Sad. Many have commented on APL on this thread. In most cases it is obvious that these comments come from lack of or limited experience with the language. The power of APL comes from two things: Abstraction and Notation. Abstraction is very much like objects in OO languages or specialized symbols in mathematics. Notation --through specialized symbols-- is huge. Ken Iverson's own "Notation as a tool for thought" [1] covers this in far more depth than I could attempt here. I'll just mention one example: music notation. A page in an orchestral score looks like gibberish to someone unskilled in the art. However, to a skilled professional it reads, well, like music. While I am not at that level, I can read guitar or piano sheet music and imagine, for lack of a better word, the music with reasonable accuracy. That's what happens with APL if you really know it: You read it like music. Much of the criticism and misguided opinion comes from people who simply don't have this level of proficiency with the language. All other languages allow you to be a pretty decent "hobby" programmer in the sense that you don't have to be able to read it like music and you can still produce and maintain software. APL, for non-trivial work, requires true expertise, not superficial exposure. It rewards you with unparalleled productivity and expressive power. It really is a cool language, but you have to invest the time to learn it and read it like music. Another way to put it: It's like vim. It's a shit code editor until you invest the time and effort to use it instinctively, to play it like a reasonably skilled musician would play a piano: without having to think about which finger to use to press a certain key to produce the desired tone. That's APL. It's very different than using C or Java. It requires expertise, time and dedication. And perhaps that's the source of its demise. Today most programmers don't care about diving to those depths. Most want to learn the basics and poke around API and code libraries to get shit done and consider super-simple stuff like pointers confusing and complicated. BTW, to me Python has a number of APL-like features that make it fun and productive. I really enjoy it. [1] http://www.jdl.ac.cn/turing/pdf/p444-iverson.pdf http://www.jdl.ac.cn/turing/pdf/p444-iverson.pdf
dangoldin 13y ago
I've been doing the Project Euler problems and always love seeing the APL-like solutions. Amazingly expressive stuff that would be fun to get into some day.
jingo 13y ago
"Big data problems are almost all inherently columnar..." Can you name some that are not?
dmpk2k 13y ago
As a random aside, why do APL programmers try to import their idioms into C? Take a look at the VM code in J or Kona and prepare for a shock. It's too bad. I find VMs interesting, but I wouldn't touch that C with a ten-foot pole. It's IOCCC quality.
- gruseom 13y ago
  It's a distinct style of C that evolved over decades for implementing APLs. It's more akin to an embedded DSL than it is to normal systems code, and the reason people use it is not that it's obscure but that it fits the problem space well. The "shock" of looking at it is exactly the same as the shock of looking at APL or K programs to begin with. They don't look anything like code that most people are used to, but since they tend to be highly regular, the impression of noise is misleading.
  - dmpk2k 13y ago
    I'm not sure a general lack of useful commenting and a subsistence on single-variable names is defensible. It sure seems like a case of "You can write Fortran in any language".
znowi 13y ago
There's a great link in the original comments to a video from 1974, where Iverson, Falkoff, and others discuss the origins of APL. It was a pleasure to watch. A peculiar contrast in language and attitude to today's rockstars and ninjas :) https://www.youtube.com/watch?v=8kUQWuK1L4w https://www.youtube.com/watch?v=8kUQWuK1L4w
deleted 13y ago
[deleted]
mathattack 13y ago
Great article. It seems like once you get beyond the hype of Big Data, you get to some old technologies whose primary use cases are finally coming to light. The more things change...

135 points by erehweb 13y ago

I have had a huge amount of fun lately going through the J labs. Start at jsoftware.com to download the interpreter, then the labs are all built into the interpreter. You can also run it on iOS. The terse code actually means you can type in real programs even on an iPod keyboard. When I taught people to play frisbee, I used to throw with my off-hand when teaching, because it made me pay attention to the fundamentals I was trying to teach. Learning J had some of that same feel. I felt like a newbie, but when I saw the kinds of audacious programs you could write, I was hooked. Highly recommended for a bit of fun in your spare time.

deleted 13y ago
[deleted]
kaoD 13y ago
Same here, but I found it extremely hard to find real world use cases for the language. It's fun as hell, but for me it's a puzzle, not a programming language. Anyways, making cellular automata is fun as hell! :P
saryant 13y ago
I went to a small university with only 8 CS professors. One of them was the author of J's array parallelization and he taught our Intro to Functional Languages course. That class was fourth in the undergrad sequence, coming after C, C++ and Java so it was quite a shock to, well, everyone. He took us from finding the average of a list all the way through to implementing a CMS in J (our department web server still runs on J because he's since retired and no one else knows how to maintain it). This was easily the hardest class in the entire department. Students who sailed through everything else would struggle to pass. It's a fascinating language but not an easy one to grasp.

hat_matrix 13y ago

How is lush an old language? Looks like a language that was released last decade, but just never caught on.

scottlocklin 13y ago
Lush as a language was developed in 1987, just like it says on the website. Older versions of it are reading the numbers off of your checks when you deposit it in the ATM machine. The ideas it embodies are significantly older than common lisp: it is a very pure hackers lisp: sorta has the eau de zetalisp about it (not that I really know anything about zetalisp, I ain't that old, but I've read about it). Studying it will make your brain grow. http://lush.sourceforge.net/credits.html http://lush.sourceforge.net/credits.html
- hat_matrix 13y ago
  Actually it says that Lush's predecessors were developed in 1987. Version 1 of Lush was released last decade. But even if it was 1987, that's not older than Perl or Python.
  - cbr 13y ago
    Perl was started in 1987, Python in 1989 [1]. [1] http://python-history.blogspot.com/2009/01/brief-timeline-of-python.html http://python-history.blogspot.com/2009/01/brief-timeline-of...
  - scottlocklin 13y ago
    Well, if you download, say, TL3 from Leon's page (a subset of SN), you'll immediately see that the "predecessors" are essentially the same language. Same Ogre, same UI. You can even call pieces of it in modern Lush. The name change is irrelevant. http://leon.bottou.org/projects/tl3 http://leon.bottou.org/projects/tl3
- lsh 13y ago
  "eau de zetalisp" => "water of zetalisp"

jdn 13y ago

The authors response in the comments to an overzealous attempt at political correctness was wonderful.

_delirium 13y ago
I looked for it after seeing this comment, and the response came across as kind of juvenile to me.
- jdn 13y ago
  It was a juvenile response to a juvenile comment
  - jamesaguilar 13y ago
    If it was a juvenility contest, the response won by lengths. The response also won in mean-spiritedness and unnecessary escalation.
lclarkmichalek 13y ago
> You may now go fuck yourself with a carrot scraper in whatever gender-free orifice you have available. How the fuck is that "wonderful"? The comment was something along the lines of "I wish people wouldn't use that kind of language", and the response was in the form "If I insult you enough, I don't have to acknowledge your argument". Looking at the other comments, the one nitpicking about the choice of Lady Gaga is equally as useless, but strangely that one didn't get an angry reply.
- jdn 13y ago
  That line was a bit juvenile, granted. The other comment wasn't really nitpicking. The commenter believed that Gaga has genuine musical ability, and the author wanted to make it clear that it was that classical training that made her the target of his blog. I don't want to misinterprete your meaning here, but are you trying to suggest the author would only react angrily to a female/feminist commentator?

prezjordan 13y ago

If anyone here is proficient at J, please (pretty please) contribute a guide to Learn X in Y [0]!! I don't run the site, I just really want a J guide in this format. [0]: http://learnxinyminutes.com/ http://learnxinyminutes.com/

scottlocklin 13y ago
Try this: http://www.jsoftware.com/help/primer/contents.htm http://www.jsoftware.com/help/primer/contents.htm Or, download it and run one of the intro labs; that's even better.
silentbicycle 13y ago
As Scott Locklin said in a parallel comment, J already comes with excellent documentation and tutorials. This would be a better starting place: http://www.jsoftware.com/jwiki/FrontPage http://www.jsoftware.com/jwiki/FrontPage As a language, J isn't ever going to fit comfortably into a "Learn X in Y" format -- there are too many unfamiliar ideas, it isn't just syntax.

lmm 13y ago

This happens with proprietary languages. How many people can afford $100k/CPU, however good it is? How many can play around with a language like that at home? Who's going to write infrastructure around such a thing? Hadoop is pretty crap - I know, I used to use it professionally. You know what else is crap? Unix. People are going on about cgroups as an exciting new feature, when better implementations were around what, thirty years ago in Real OSes. It doesn't matter. Commodity wins, and sooner or later if there are good ideas to be had we'll find them again.

hat_matrix 13y ago
So what isn't crap?
- lmm 13y ago
  Stuff made in industries more mature than software. Bridges were probably all crap for the first fifty years of building them too.
jingo 13y ago
s/Unix/Linux/ When you say "Unix" did you mean to say "Linux"? "Real OSes" Can you name an example or two? I'm aware of some old non-UNIX OSes that are still around but which over time have become largely ignored. I'm curious the "Real OSes" you were thinking of. "How many can play around with a language like that at home?" As many as have the desire and time to do so. Learners are limited to 32bit and no long running jobs in excess of 1 hour, but this does not stop anyone from learning the language. There's also an open source alternative of the intepreter based on an earlier version of the language.
stass 13y ago
How APL is proprietary? Anybody can implement it, and there are opensource implementations available. The 100k/CPU price the author referred to was about the high performance database integrated with a vector processing language engine. It is not about commodity. cgroups-like functionality was available in many opensource OSes for years (e.g. FreeBSD jails), but was easily dismissed by majority as worthless. This is exactly what the author was talking about referring to Lady Gaga -- the modern programming community is driven by fashion regardless of how good or bad the current fashionable technology is. I do not find it surprising however, as it is a direct result of the order of magnitude growth of the programmer's population, which is behaviorally much more close to the general population currently that it used to be.

cmccabe 13y ago

This paints a really misleading picture of what is available in Hadoop right now. Columnar data formats? Yep, we've got them-- see Parquet [http://parquet.io/ http://parquet.io/]. Yes, Hive spends a lot of its time reading and writing data. This is because it decomposes SQL queries into sets of MapReduce jobs, all of which must take input from the filesystem and write it to the filesystem. That's one of the reasons Cloudera Impala was developed [http://blog.cloudera.com/blog/2012/10/cloudera-impala-real-time-queries-in-apache-hadoop-for-real/ http://blog.cloudera.com/blog/2012/10/cloudera-impala-real-t...]. If you don't like for loops, yep, we've got that too-- use Scala or another functional programming language to write your MapReduce jobs. Or use SQL, which is a lot more powerful than APL, and a lot more accessible to businessey types than functional programming. SQL is a declarative programming language, by the way-- I don't see any for loops there. The efficiency argument makes no sense either. Does the author understand that a just-in-time dynamically recompiling virtual machine is faster than an interpreter? If so, he doesn't mention it anywhere. You know, sometimes old technologies are just... old. You could at least compare Java and the JVM to something like Lisp machines. People overestimate the gains that are to be had from mmap. I am currently in the process of adding mmap support to HDFS and I know what I am talking about. mmap gives gains, but only when the data is coming from memory, and only when you can reuse the mmap. Otherwise, you're better off reading even a 512 MB file via read() and write(). The reason is that syscall overhead is not that high on modern UNIXes (like Linux), and page faults involve a transition into kernel space anyway.

gngeal 13y ago
Or use SQL, which is a lot more powerful than APL How could that possibly be true? What does "powerful" mean? Certainly not that it can compute things that APL family languages can't, and the design of APL/J/K etc. as languages is so much better that it isn't even fun. SQL is the COBOL for the 21th century. Does the author understand that a just-in-time dynamically recompiling virtual machine is faster than an interpreter? As memory latencies relative to instruction execution times go up, this factor becomes less and less relevant. An even worse problem is that your "just-in-time dynamically recompiling virtual machine" can't even vectorize properly, whereas APL has high-level array manipulating operators that make it comparatively easy to generate vectorized code. Your "just-in-time dynamically recompiling virtual machine" would have to "intelligently" recover high-level patterns from seemingly nondescript for() and while() loops to do that. Guess what: it doesn't! When you consider the fact that memory latencies matter these days, the fact that an AVX vector instruction can do a whole lot of work in a single cycle (or a few of them at most), and the fact that the integer units that would otherwise be idle can handle dispatching the next primitive operation in the meantime, there's a potential for even an interpreter to kick your "just-in-time dynamically recompiling virtual machine"'s ass.

mattdw 13y ago

He'd rather write in Beethoven languages than Lady Gaga languages. Which is fine, but there's something to be said for "takes 3 minutes to perform with one voice and one computer" as against "takes an hour to perform with a team of 30 highly specialised professionals." To stretch his metaphor.

ginko 13y ago

> APL is a mistake, carried through to perfection. It is the language of the future for the programming techniques of the past: it creates a new generation of coding bums. - Edsger W. Dijkstra

jacques_chester 13y ago
You can find an acidic Dijkstra quote for every language of his time. Dijkstra, I think, viewed mere languages as an unhappy by-product of computer science and hankered to do it all with mathematics, actual utility be damned.
- gngeal 13y ago
  Alan Kay seems to think along similar (though not identical) lines these days. The sheer inertia of ordinary programming language implementations means that by the time you get to use it, you may realize that something "slightly different" would have been better, but you seldom have any other option than to "suck it up".
  - jacques_chester 13y ago
    Economists have a term for it -- Path Dependence. Some decisions have a high enough reversal cost that they are in practice irreversible. This means that one's future decisions are dependent on historical decisions over which one might have had no control. In our case: once a technology is deeply rooted, it's hard to displace. More closely, the Rogers model of diffusion[2] has 5 factors of diffusion (relative advantage, compatibility, complexity/simplicity, trialability and observability). Generally even the most advantageous language transitions score well only in relative advantage. The other diffusion predictors are missing or weak. [1] http://en.wikipedia.org/wiki/Path_dependence http://en.wikipedia.org/wiki/Path_dependence [2] http://en.wikipedia.org/wiki/Diffusion_of_innovations http://en.wikipedia.org/wiki/Diffusion_of_innovations
coldtea 13y ago
Dijkstra never had anything relevant or wise to say about any programming language (including the few he did like). In general, he was good at the math part of computer science, terrible at the computer part.

jacques_chester 13y ago

The most common "perform operation on bulk data simultaneously" language in wide use today is SQL. Joe Celko coined a phrase for this: think in sets. Not in loops, not in linear instructions -- but in sets, being transformed into other sets. It's a very powerful way of thinking. Most of the time, you don't need ordered evaluation and so loops are imposing unnecessary guarantees on you. On the more general problem of our collective historical ignorance ... yes. That is us. Well not entirely. That decades of the relevant literature is locked up in Fort ACM and IEEE Castle has a lot to do with it.

jamii 13y ago
The BOOM guys have also shown that thinking in terms of unordered collections translates much better to distributed systems, where guaranteeing order is expensive: http://boom.cs.berkeley.edu/ http://boom.cs.berkeley.edu/
- gtani 13y ago
  The other day i thought i had found a textbook chapter on stream algo's/online learning, but Chapter 17 has yet to be written http://ciml.info/ http://ciml.info/
- stass 13y ago
  BOOM project came up with a very impressive ideas. Their half page long paxos implementation in Overlog blew my mind. I don't think they new Bloom language is as expressive, however.
- beagle3 13y ago
  I'm going to read about BOOM later, but can you give an executive summary about why that is? People who subscribe to the Relational Database dogma often claim that sets are superior to vectors, and yet despite asking a lot of them I never received an example -- whereas I have numerous real life examples in which vectors are superior.
  - jacques_chester 13y ago

stiff 13y ago

There is no shortage of excellent work being done today, too. With the large systems that are being created today I would take Python over APL or J any day, can you imagine building a company like Google or Facebook on top of APL, even assuming you would manage to find a team of good APL programmers? It is not a language fit for cooperation nor for large systems, it is a problem-solving language, back from the day where people used computers for relatively small tasks. Plenty of the good things in APL are now available in other forms anyway. NumPy with it's powerful set of linear algebra primitives and the huge set of implemented algorithms is just as great at data crunching. Want mmapped files? No problem: http://docs.scipy.org/doc/numpy/reference/generated/numpy.memmap.html http://docs.scipy.org/doc/numpy/reference/generated/numpy.me... That's not to say APL is not worth studying, it is built on powerful ideas. But to study the masters is to criticize the masters, not only blindly admire them. And history is not all romantic.

hat_matrix 13y ago
And R also has mmap, which is the the relevant package to reference rather than bigmemory in the original blog post?
- scottlocklin 13y ago
  bigmemory is a better package.
yummyfajitas 13y ago
There are big companies built on top of APL like languages. One example is Morgan Stanley (K). You are correct that not everything is built on K - typically there are gigantic concurrent enterprisey systems build in java/c++/scala which shell out to a computational core built in K. You are also right that Python/Numpy is getting to be a good alternative to K, giving you less performance but better cooperation. That's why BankAm is building their SecDB clone on top of it.
- oddthink 13y ago
  I definitely miss having the Morgan Stanley site license for K at my disposal. I can't quite justify the money to get a license, just for me, so I've been slowly assembling a poor-man's substitute built on numpy, pandas, and hdf5. K itself isn't as consistent as I'd like (odd corners like the auto-casting arrays, especially dict arrays to tables, and skipping NaNs in sums), but it's a great place to start. J really needs a table or dictionary data type, or at least the tools to make one yourself.

lcedp 13y ago

I had some fun with J. But it's (you know what I'll say) too cryptic.. Let's take an example from RosettaCode. For instance, merge sort: merge =: ,`(({.@] , ($: }.))~` ({.@] , ($: }.)) @.(>&{.))@.(*@*&#) split =: </.~ 0 1$~# mergeSort =: merge & $: &>/ @ split ` ] @. (1>:#) I could probably write it, but read what it does in a few weeks?

michaelfeathers 13y ago
Maybe it takes more than a few weeks. People half-way across the world read text like this everyday: 中國哲學書電子化計 C looks like that to most non-programmers. We forgot how much we have acclimated to already.
- lcedp 13y ago
  Actually it's a very good example. Is 中 a word? Or 中國 a word? Or 中國哲 is a word? One can't say until they read a full sentence, making sense of it and distinguishing words from context. Similarly, can you clearly distinguish operators here ",`(({.@] , ($: }.))~` ({.@] , ($: }.)) @.(>&{.))@.(@&#)"? Sure, we can acclimate to a lot. Assembler is also a language. But nobody gonna write Hacker News in it.
  - gd1 13y ago
    Don't mistake looking complex for being complex. These languages have very simple and clean grammars (or they'd fall apart quickly), which is quite a contrast to the dog's breakfast that is modern C++. A simple grammar = simple to read once you've learnt the syntax. There's no issue in having a lot of symbolic operators if they all work in a clean and consistent way.
    - kd0amg 13y ago
      Unfortunately, J's grammar isn't the cleanest. It uses juxtaposition to mean about a dozen different things depending on whether the tokens are data, first-order functions, or second-order functions and how many are juxtaposed. A variable could stand for any of these. If there are variables in the expression, you have to know which variables stand for which kinds of objects in order to parse the expression.

useful 13y ago

1/2 our codebase is in APL. It is a good calculator.

perlgeek 13y ago

I am a bit disappointed by the low ratio of technical content to rambling. And much of the technical content seems to set apart APL from C, but not from many modern languages. For examples languages like Fortress contain primitives for parellelized loops, and most modern languages also contain enough functional programming that you rarely have to write for-loops. Function composition and interactivity aren't a unique feature of APL languages either. There are some other things that are important for programming today: Maintainability, richness of available libraries/modules, packaging, versioning and so on. Where would I even look for existing APL libraries? My searches for a HTTP library for APL (for example) have turned up nothing, while searching for a HTTP library for several other languages that came to my mind brought up useful results.

klibertp 13y ago
There is HTTP library in J (APL "spiritual successor") standard library. There is one for APL for sure - it's just less popular and so the google results are less helpful. Unique features of J (I'm writing about J because I know it, while I don't know APL) are that all the basic verbs (functions) can operate on arrays as easily as on atoms. There is no special syntax or feature for adding two matrices, for example, standard `+` verb does it naturally. The second unique feature is a tacit - point-free - style by default. This means that function composition is the default, not function application. You can define new words by just slapping old ones together, without worrying about threading params through them. The third unique feature (and probably unique to J, previous are found in APL too) are complex rules of composition (hooks and forks) as well as words that modify functions. You can express very complex things in very little space thanks to this. J is very interesting, unique language which are very well suited to one thing - very fast and efficient array transformations - and completely useless for other things. I hear it's used in a financial and banking sectors, for rapidly prototyping and sometimes deploying statistical and mathematical algorithms. If you have a good enough use case, then learning J will pay off. For anything less than full time commitment, I think that R od Python+Pandas is better. Still, I'm very happy I tried to learn J, as it's completely unlike anything else and it helped me greatly to understand numpy/pandas for my main job.

eliasmacpherson 13y ago

My only knowledge of APL is second hand via Scott Meyer's "More Effective C++" where he gives it as an example of the benefits offered by lazy-evaluation, saying that rather than compute the results of each statement in series it makes a compound statement where it computes only the result needed. In my own situation APL is a language looking for a problem - I don't currently have a use case for it. http://books.google.ie/books?id=azvE8V0c-mYC&pg=PT121&lpg=PT121&dq=more+effective+c%2B%2B+APL&source=bl&ots=46hf09Ni3j&sig=rqutwxurvUWv5uQcL9KpQ1IbKI0&hl=en&sa=X&ei=BBz1UYOOGvGP7Ab8oYHICA&redir_esc=y http://books.google.ie/books?id=azvE8V0c-mYC&pg=PT121&lpg=PT...

michaelochurch 13y ago

q is a neat language, and I spent some time studying it when I was in finance, because it's useful to know q/kdb if you're a quant. Here's an offensive but accurate taxonomy. There are 6-month languages/technologies and 20-year languages. The 6-month set are optimized toward being quick to learn fast. Java, for example, inherited C++ syntax while cleaning up the OOP, so the C++ programmers of the time could pick it up in quickly. Now, q and kdb are 20-year languages. It doesn't take 20 years to be productive with them, of course; it's that they're designed to optimize a person's productivity over 20 years, and not in the first 6 months. Unlike the various distributed tools out there (Hadoop, Hive) it will take you a long time to learn them, because they aren't like anything else. Superficially, q is Lisp-like, but the performance implications are very different and it doesn't look like a Lisp at all. (It parses right-to-left, for one example; also, it's written as a stream rather than in nested s-expressions.) Many of these modern tools being bashed have grown up in a world where 20-year tools can't really be built; they'll never catch on commercially in a world where people change jobs every 2 or 3 years, when MVPs are more important than solid decades-proof engineering, and where employers are pretty averse to their people taking time to just learn new technologies. There's too much volatility in the world for it to make sense for most people to learn q and kdb right away. You can get half-decent in a couple months, but it'll take much longer to learn why those tools are (for some use cases) so damn powerful. This 6-month vs. 20-year tool concern is part of why I've gravitated toward Clojure recently. I haven't seen anyone else do quite as good a job of balancing those two need sets as Rich Hickey and the Clojure community have. Clojure is (becoming) a 20-year language, but it's no harder to become basically productive in than Python or Ruby.

dschiptsov 13y ago

The beauty of a programming language comes from being small and consistent. Such as Smalltalk, which has only 6 reserved words and implements message-passing as if it is a function call. This is the brilliant idea of Smalltalk - message-passing + blocks + booleans and out of this everything else is implemented. Classes are of second importance, but delegating (via message passing) to parent or another object was invented here. Scheme, on the other hand, was also minimalist and consistent - s-expressions and about dozen special forms, and out of this everything else could be implemented, including closures, continuations, and classes and message passing, if needed (CS 61A 2008 does this for you). Haskell is.. well, everyone know what Haskell is. As for APL, in my opinion, the power of a language comes not from using esoteric math notation, but, like in CL or Scheme, from possibility to easy add new control structures (call/cc) and special forms (with macros) or even create a new languages, such as Arc.

rossjudson 13y ago
Minimalism is oversold. K specifically eschews minimalism, providing an essential list of operators and combiners (verbs and adverbs). It's no "6-word" language. Every character is a word in other languages. We don't have six characters in the English language.
- dschiptsov 13y ago
  minimalism in itself is not the key, but being small, consistent and good-enough is.
- kansface 13y ago
  Right, and the English was designed to perform the function that it does. Perhaps a sane implementation of the language would use far fewer characters.
  - lttlrck 13y ago
    "designed" is the last word I would use to describe English :)

deleted 13y ago

[deleted]

robomartin 13y ago

I used APL extensively for about ten years. I was introduced to the language by a physics professor in college who was quite vocal about having his students learn the language. I ended-up using it professionally for a wide range of applications, from inventory management and core business operating systems to robotics and DNA sequencing. While the language is wonderful I would not use it for production systems today. It is my opinion that the language came to be too early and, as a result, has not seen innovation for decades. It also does not help that the leading APL implementations cost thousands of dollars to license. APL is still being used extensively in financial institutions in Wall Street. J has been mentioned here a few times. Even though J is the work of APL's creator, Ken Iverson, whom I had the pleasure of meeting at various APL conferences, I consider it an abomination and a huge step backwards. I have a feeling Ken might have sought more commercial appeal by using ASCII characters rather than specialized notation. Ironic because of [1]. However, in making this switch, he created a horrible mutation that anyone can rightly recoil at. The language looks like a random vomiting of ASCII characters on the screen. Sad. Many have commented on APL on this thread. In most cases it is obvious that these comments come from lack of or limited experience with the language. The power of APL comes from two things: Abstraction and Notation. Abstraction is very much like objects in OO languages or specialized symbols in mathematics. Notation --through specialized symbols-- is huge. Ken Iverson's own "Notation as a tool for thought" [1] covers this in far more depth than I could attempt here. I'll just mention one example: music notation. A page in an orchestral score looks like gibberish to someone unskilled in the art. However, to a skilled professional it reads, well, like music. While I am not at that level, I can read guitar or piano sheet music and imagine, for lack of a better word, the music with reasonable accuracy. That's what happens with APL if you really know it: You read it like music. Much of the criticism and misguided opinion comes from people who simply don't have this level of proficiency with the language. All other languages allow you to be a pretty decent "hobby" programmer in the sense that you don't have to be able to read it like music and you can still produce and maintain software. APL, for non-trivial work, requires true expertise, not superficial exposure. It rewards you with unparalleled productivity and expressive power. It really is a cool language, but you have to invest the time to learn it and read it like music. Another way to put it: It's like vim. It's a shit code editor until you invest the time and effort to use it instinctively, to play it like a reasonably skilled musician would play a piano: without having to think about which finger to use to press a certain key to produce the desired tone. That's APL. It's very different than using C or Java. It requires expertise, time and dedication. And perhaps that's the source of its demise. Today most programmers don't care about diving to those depths. Most want to learn the basics and poke around API and code libraries to get shit done and consider super-simple stuff like pointers confusing and complicated. BTW, to me Python has a number of APL-like features that make it fun and productive. I really enjoy it. [1] http://www.jdl.ac.cn/turing/pdf/p444-iverson.pdf http://www.jdl.ac.cn/turing/pdf/p444-iverson.pdf

dangoldin 13y ago

I've been doing the Project Euler problems and always love seeing the APL-like solutions. Amazingly expressive stuff that would be fun to get into some day.

jingo 13y ago

"Big data problems are almost all inherently columnar..." Can you name some that are not?

dmpk2k 13y ago

As a random aside, why do APL programmers try to import their idioms into C? Take a look at the VM code in J or Kona and prepare for a shock. It's too bad. I find VMs interesting, but I wouldn't touch that C with a ten-foot pole. It's IOCCC quality.

gruseom 13y ago
It's a distinct style of C that evolved over decades for implementing APLs. It's more akin to an embedded DSL than it is to normal systems code, and the reason people use it is not that it's obscure but that it fits the problem space well. The "shock" of looking at it is exactly the same as the shock of looking at APL or K programs to begin with. They don't look anything like code that most people are used to, but since they tend to be highly regular, the impression of noise is misleading.
- dmpk2k 13y ago
  I'm not sure a general lack of useful commenting and a subsistence on single-variable names is defensible. It sure seems like a case of "You can write Fortran in any language".

znowi 13y ago

There's a great link in the original comments to a video from 1974, where Iverson, Falkoff, and others discuss the origins of APL. It was a pleasure to watch. A peculiar contrast in language and attitude to today's rockstars and ninjas :) https://www.youtube.com/watch?v=8kUQWuK1L4w https://www.youtube.com/watch?v=8kUQWuK1L4w

deleted 13y ago

[deleted]

mathattack 13y ago

Great article. It seems like once you get beyond the hype of Big Data, you get to some old technologies whose primary use cases are finally coming to light. The more things change...