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 m

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.