Hacker News Reader

Comment by marktangotango | Hacker News Reader

He "cheats" by putting multiple statements on one line:

noun(c){A z;if(c<'0'||c>'9')R 0;z=ga(0,0,0);z->p=c-'0';R z;}

would be

  noun(c){
   A z;
   if(c<'0'||c>'9')
     R 0;
   z=ga(0,0,0);
   *z->p=c-'0';
   R z;
  }

In this forms, it's still cryptic, but not quiet as inscrutable.

View on HN

Except this isn't him "cheating", this is his preferred coding style, for readability!

To avoid scrolling, which he says he hates.

What you refer to as "cheating" is simply writing C like k/APL/J (i.e. functional versus imperative). Language implementations have this tendency. I've seen the same effect with Lisp implementations.
N.B. - k/APL/J functions are often written on one line because that are often very short.

> What you refer to as "cheating" is simply writing C like k/APL/J (i.e. functional versus imperative).
Mashing things up without line breaks isn't a functional vs. imperative thing [1]. Its a density vs. negative space thing. There's a quite a bit of research in many contexts indicating that effective use if negative space generally improves readability of most things for most readers, so while I know Whitney and his disciples like to say that J is "more readable" because of its density, I don't think that's generally the case for most readers.
[1] idiomatic Haskell is definitely functional, but does not eschew line breaks; mashing C programs into cryptic single-line monstrosities doesn't make it any less imperative, it just makes it unreadable.

It's often considered much more understandable to define the distance between two points as a short mathematical expression - with sigma, x_n - y_n, second powers, square root - that actually explain what it is in non-mathematical terms.
Similarly, J programmers prefer to write
a =: a + b
instead of
(for i=0; i<a.size(); ++i) a[i] += b[i];
which obscures the idea quite a bit. Or saying
(# %: */) a
to calculate geometric mean of vector a and use that in next expression.

> Similarly, J programmers prefer to write
> a =: a + b
> instead of
> (for i=0; i<a.size(); ++i) a[i] += b[i];
Well, sure, most people prefer not to write code with syntax errors.
But, nitpicks aside, your post is mostly frequently-made commentary in favor of functional programming (both FP languages and functional style -- which, again, has nothing to do with avoiding line breaks or whitespace -- in other languages), but really has nothing to do with the characterization uphtread of the mass of minimally-whitespace, non-line-broken C code presented upthread as being a matter of "functional vs. imperative", which remains completely wrong. So its a complete nonsequitur to the post it "responds" to.
Not using whitespace, including line breaks, has nothing to do with functional style, and using it has nothing to do with imperative style. (If it did, your C++ example, minus the syntax error, would be just as "functional" as the J example.)

The more relevant part is comparison with math notation. No whitespaces and line breaks there.

Actually, the usual presentation of math notation in textbooks, papers, etc., while dense, does use whitespace -- and often large whitespace or line breaks for factoring out definitions used in the main equation for readability and ready comprehension. [1] Let-bindings and similar constructs in other functional languages are, in fact, largely driven by this kind of factoring-out in mathematical notation (not just in their use of whitespace, but in general.)
[1] For an example of the large whitespace for factoring-out, see the factoring out of J-sub-k on the top of p. 460 of http://titan.fsb.hr/~venovako/dist/tensor.pdf

Heck, short awk programs are often written as one-liners that are invoked from the command line. I sometimes do this, but use a program file ("-f hithere.awk") for anything beyond semi-trivial.
And I always use "--lint" with "-f".

"noun" in C: noun(c){A z;if(c<'0'||c>'9')R 0;z=ga(0,0,0);z->p=c-'0';R z;}
"noun" in k: noun:{[c]$[(c<"0")|c>"9";0;c-"0"]} / $[boolean; true; false]
The C version is effectively the k version expanded with declarations, memory allocation and initialization. I would not be surprised if the interpreter was written in APL and transliterated to C.

Given his obvious facility with both languages I think you are right but that both those steps occurred simultaneously in real time.
Arthur had learned how to think a problem in APL and was a wizard at transliteration.

I'm not saying the C isn't in functional style.
I'm saying that it being in functional style has nothing to do with the absence of whitespace/newlines. Both the use of the functional style and the absence of whitespace no doubt reflect Whitney's language-independent programming preferences, but they are distinctly different things.

Reply on news.ycombinator.com