4 ms·

There's a reason that APL never gained a foothold and J has not been adopted by software engineers. You can program at the speed of thought in TECO as well, but

by cplease 12y ago

There's a reason that APL never gained a foothold and J has not been adopted by software engineers. You can program at the speed of thought in TECO as well, but the reasons for its limitations and peculiar history vanished long ago. There are far better tools available these days for rapid prototyping; interpreted languages with REPLs and libraries for just about everything--without resorting to a write-only line-noise language and actually ending up with a usable product. For that matter, I suppose it's possible to write understandable, maintainable TECO, APL and J with some effort if you don't value obscurity and cleverness over simplicity, correctness, maintainability and understandability. If your business logic or product is written in line noise written by some lone J genius, your company is fucked when your guy inevitably gets hit by a bus, goes nuts, or leaves for greener pastures.

avmich 12y ago
Perhaps "Notation as a Tool of Thought" - http://www.jsoftware.com/papers/tot.htm http://www.jsoftware.com/papers/tot.htm - could help you, if you want to understand why people keep writing APL and its successors? Like Mathematica, for example?.. Do you think mathematical articles are understandable and maintainable? What if there is not a lone J genius, but a whole - small - department of people, who spend time actually thinking and talking about computations, not the ways to express it?
scottlocklin 12y ago
I've been screwing around with it in my spare time. J is quite logical and understandable. Anyone can understand it, but they have to make an effort to do so, just like they would if they were learning some other "weird" language like Lisp or Forth.
beagle3 12y ago
> There's a reason that APL never gained a foothold APL was widespread in operations research in the 80s, and since the early 90s is usually found in and around finance, even though it isn't really common anymore. Part of it is a mindset thing; People used to consider longer employment periods, both from the company's perspective and from the employee's perspective. Although APL is extremely useful when you use it properly, it is definitely not a "programmer-is-a-replaceable-cog" language that Java strives to be and the most firms now assume.
icsa 12y ago
The same could be said for writing a document in Chinese, Arabic or Hebrew. They all look like "line noise" until you make an effort to learn them. "For that matter, I suppose it's possible to write understandable, maintainable TECO, APL and J with some effort if you don't value obscurity and cleverness over simplicity, correctness, maintainability and understandability." Yes. I do separate long functions in k onto separate lines. However, long functions in k are rare (and usually) an indication that I haven't arrived at a simple solution. Writing in J/k/APL allows to think in chunks where the chunk is an algorithm - not all of the tiny steps in an algorithm. It is a higher level of abstraction - not unlike programming in C versus assembly language or machine code. E.g. The sum of a list (of any type) in k (APLis similar): sum:+/x / read "plus over x" or "reduce x with plus" versus (C code fragment) which computes the sum of integers only: int sum=0: for(int i=0; i<n; ++i) { sum = sum + x[i]; } Btw, John Von Neumann once chastised a grad student for writing an assembler. Perhaps real software engineers only write in machine code. "If your business logic or product is written in line noise written by some lone J genius, your company is fucked when your guy inevitably gets hit by a bus, goes nuts, or leaves for greener pastures." I think the larger issue is documentation. Undocumented code (of any kind) is a liability. When I write in k, Every line of k is documented (as text past column 80). In addition, there is header documentation that described the purpose and approach of the code in the file/module. The number of lines of code in a file is typically no more than 10 lines.

by cplease 12y ago

avmich 12y ago

Perhaps "Notation as a Tool of Thought" - http://www.jsoftware.com/papers/tot.htm http://www.jsoftware.com/papers/tot.htm - could help you, if you want to understand why people keep writing APL and its successors? Like Mathematica, for example?.. Do you think mathematical articles are understandable and maintainable? What if there is not a lone J genius, but a whole - small - department of people, who spend time actually thinking and talking about computations, not the ways to express it?

scottlocklin 12y ago

I've been screwing around with it in my spare time. J is quite logical and understandable. Anyone can understand it, but they have to make an effort to do so, just like they would if they were learning some other "weird" language like Lisp or Forth.

beagle3 12y ago

> There's a reason that APL never gained a foothold APL was widespread in operations research in the 80s, and since the early 90s is usually found in and around finance, even though it isn't really common anymore. Part of it is a mindset thing; People used to consider longer employment periods, both from the company's perspective and from the employee's perspective. Although APL is extremely useful when you use it properly, it is definitely not a "programmer-is-a-replaceable-cog" language that Java strives to be and the most firms now assume.

icsa 12y ago

The same could be said for writing a document in Chinese, Arabic or Hebrew. They all look like "line noise" until you make an effort to learn them. "For that matter, I suppose it's possible to write understandable, maintainable TECO, APL and J with some effort if you don't value obscurity and cleverness over simplicity, correctness, maintainability and understandability." Yes. I do separate long functions in k onto separate lines. However, long functions in k are rare (and usually) an indication that I haven't arrived at a simple solution. Writing in J/k/APL allows to think in chunks where the chunk is an algorithm - not all of the tiny steps in an algorithm. It is a higher level of abstraction - not unlike programming in C versus assembly language or machine code. E.g. The sum of a list (of any type) in k (APLis similar): sum:+/x / read "plus over x" or "reduce x with plus" versus (C code fragment) which computes the sum of integers only: int sum=0: for(int i=0; i<n; ++i) { sum = sum + x[i]; } Btw, John Von Neumann once chastised a grad student for writing an assembler. Perhaps real software engineers only write in machine code. "If your business logic or product is written in line noise written by some lone J genius, your company is fucked when your guy inevitably gets hit by a bus, goes nuts, or leaves for greener pastures." I think the larger issue is documentation. Undocumented code (of any kind) is a liability. When I write in k, Every line of k is documented (as text past column 80). In addition, there is header documentation that described the purpose and approach of the code in the file/module. The number of lines of code in a file is typically no more than 10 lines.