4 ms·

This gem comes up semi-regularly on HN; previous thread (with 43 comments): https://news.ycombinator.com/item?id=25902615 https://news.ycombinator.com/item?id=2

This gem comes up semi-regularly on HN; previous thread (with 43 comments): https://news.ycombinator.com/item?id=25902615 https://news.ycombinator.com/item?id=25902615 I know Whitney's style is a strict no-no, but it's beautiful how he regards C as a pliable material, rather than as a hard tool with standard modes of use, and uses it to define his own rudimentary DSL to build J on top of it.

carapace 4y ago
My attitude is, on the one hand, reverence for such a fantastic intellectual feat, but on the other hand, annoyance that it's so opaque and difficult. It's sort of like performance art (very well-paid performance art) rather than something mere mortals could learn and use.
- JadeNB 4y ago
  > It's sort of like performance art (very well-paid performance art) rather than something mere mortals could learn and use. If I were to be flippant, I would just say "not with that attitude!" But, mere flippancy being (rightly) not welcome here, I would also point out that all code is opaque and difficult to people who haven't learned how to read it. I think this kind of code should be taken, not as absolutely unintelligible (elsethread at https://news.ycombinator.com/item?id=34052034 https://news.ycombinator.com/item?id=34052034, zwerge posted a link to their dissection of it)—after all, part of the beauty of coding is that we all have access to a source of absolute truth (the code does what the compiler says it does)—but as either a fun diversion (my personal perspective) or as a goal. If making the code-reading part of your brain fluent in this sort of code is something to which you aspire—and there's no reason you should, but also no reason you shouldn't—then you can do it, with lots of patience!
  - mncharity 4y ago
    > making the code-reading part of your brain fluent in this sort of code [...] lots of patience I've not seen attempts to aid learning of basic skills for reading diverse coding styles. The space is large, from "eyeball abstraction" over "code is 90% repetition and boilerplate", to APLish "DO Repeat Yourself! At every callsite! With variations! ... each is like 4 characters", to terse lambda "code is documentation for humans, and only secondarily executable", to ... . There are skills involved with reading each style. And non-obvious tradeoffs to use. But even within individual styles, aid seems more "write and read a lot of code, and you'll eventually get the hang of it", and less "here, let me break down for you what I'm doing, what skills I'm using, when I read this". Perhaps there's some "live coding^H^H^He reading" on yt? Or how about an interviewer pair-reads code with a language expert? While linters trending increasingly strict, towards canonical representation, raises hope for the old dream of AST-based coding, it does crush an axis of expressive power, for better and worse. Hmm, I wonder if one could generate an ML training corpus to answer "explain what this bit of code here is doing and why"? Or perhaps, "create a minimum-ink compressed summary of these files"? Or even aspire to "rewrite this Java code in the style of APL"? :P (Ha - further down this page, ChatGPT https://news.ycombinator.com/item?id=34053932 https://news.ycombinator.com/item?id=34053932 )
  - carapace 4y ago
    At risk of being overly pedantic, I have to point out that you quoted my conclusion (which is based on my attitude), my attitude is, as I said, an unsettling mixture of reverence and annoyance. I'm actually pretty eager to learn and use what you might call the Array Paradigm. Here's a comment thread from this summer: https://news.ycombinator.com/item?id=31380292 https://news.ycombinator.com/item?id=31380292 Some good info surfaced, and you can see for yourself how excited I got. :) Anyway... > all code is opaque and difficult to people who haven't learned how to read it. Sure, but there's a difference between, say, Logo and J in terms of available educational materials, eh? My complaint isn't that the array languages are particularly hard (they're not), it's that they are obscure. ( "elsethread" I love it! I'm going to use that I think. Cheers! )

carapace 4y ago

My attitude is, on the one hand, reverence for such a fantastic intellectual feat, but on the other hand, annoyance that it's so opaque and difficult. It's sort of like performance art (very well-paid performance art) rather than something mere mortals could learn and use.

JadeNB 4y ago
> It's sort of like performance art (very well-paid performance art) rather than something mere mortals could learn and use. If I were to be flippant, I would just say "not with that attitude!" But, mere flippancy being (rightly) not welcome here, I would also point out that all code is opaque and difficult to people who haven't learned how to read it. I think this kind of code should be taken, not as absolutely unintelligible (elsethread at https://news.ycombinator.com/item?id=34052034 https://news.ycombinator.com/item?id=34052034, zwerge posted a link to their dissection of it)—after all, part of the beauty of coding is that we all have access to a source of absolute truth (the code does what the compiler says it does)—but as either a fun diversion (my personal perspective) or as a goal. If making the code-reading part of your brain fluent in this sort of code is something to which you aspire—and there's no reason you should, but also no reason you shouldn't—then you can do it, with lots of patience!
- mncharity 4y ago
  > making the code-reading part of your brain fluent in this sort of code [...] lots of patience I've not seen attempts to aid learning of basic skills for reading diverse coding styles. The space is large, from "eyeball abstraction" over "code is 90% repetition and boilerplate", to APLish "DO Repeat Yourself! At every callsite! With variations! ... each is like 4 characters", to terse lambda "code is documentation for humans, and only secondarily executable", to ... . There are skills involved with reading each style. And non-obvious tradeoffs to use. But even within individual styles, aid seems more "write and read a lot of code, and you'll eventually get the hang of it", and less "here, let me break down for you what I'm doing, what skills I'm using, when I read this". Perhaps there's some "live coding^H^H^He reading" on yt? Or how about an interviewer pair-reads code with a language expert? While linters trending increasingly strict, towards canonical representation, raises hope for the old dream of AST-based coding, it does crush an axis of expressive power, for better and worse. Hmm, I wonder if one could generate an ML training corpus to answer "explain what this bit of code here is doing and why"? Or perhaps, "create a minimum-ink compressed summary of these files"? Or even aspire to "rewrite this Java code in the style of APL"? :P (Ha - further down this page, ChatGPT https://news.ycombinator.com/item?id=34053932 https://news.ycombinator.com/item?id=34053932 )
- carapace 4y ago
  At risk of being overly pedantic, I have to point out that you quoted my conclusion (which is based on my attitude), my attitude is, as I said, an unsettling mixture of reverence and annoyance. I'm actually pretty eager to learn and use what you might call the Array Paradigm. Here's a comment thread from this summer: https://news.ycombinator.com/item?id=31380292 https://news.ycombinator.com/item?id=31380292 Some good info surfaced, and you can see for yourself how excited I got. :) Anyway... > all code is opaque and difficult to people who haven't learned how to read it. Sure, but there's a difference between, say, Logo and J in terms of available educational materials, eh? My complaint isn't that the array languages are particularly hard (they're not), it's that they are obscure. ( "elsethread" I love it! I'm going to use that I think. Cheers! )