Re:Arthur Whitney's One-page Interpreter (1992)
by icsa on Thursday October 30, 2014 @11:14PM
(#8537125)
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.
"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.