4 ms·

Begging your pardon, you're doing so out of ignorance. An entire programming ecosystem -- a brilliant one, one of the very most impressive -- has been built on

by gruseom 16y ago

Begging your pardon, you're doing so out of ignorance. An entire programming ecosystem -- a brilliant one, one of the very most impressive -- has been built on top of what you are denigrating. Scour through searchyc looking for past threads on APL/K/J and you'll find the arguments all repeated on multiple occasions, including many instances of the same but-this-isn't-what-I'm-used-to rush to judgment that always, unfortunately, comes up in droves.

akkartik 16y ago
I've seen some threads on APL, but I've never seen other languages used with APL-level compression. Are there really other threads about this? I'm not sure what to search for on searchyc.
- silentbicycle 16y ago
  Try any of these: apl iverson k kona whitney j hui incunabulum (That one-page J interpreter is sometimes called the "J Incunabulum".) See e.g. http://news.ycombinator.com/item?id=1458016 http://news.ycombinator.com/item?id=1458016 http://news.ycombinator.com/item?id=266982 http://news.ycombinator.com/item?id=266982 http://news.ycombinator.com/item?id=697501 http://news.ycombinator.com/item?id=697501 http://news.ycombinator.com/item?id=2176980 http://news.ycombinator.com/item?id=2176980
scott_s 16y ago
You're conflating the implementation of an environment with the value of the environment itself. Did you read the C code? It is terribly difficult to follow, does not follow C formatting idioms, and makes frequent use of macros that further obfuscate what is going on. Example: #define DECLG V*sv=VAV(self);A gs=sv->g; \ AF g1=gs?VAV(gs)->f1:0,g2=gs?VAV(gs)->f2:0 Judging the quality of this code says nothing about the language and environment that this code provides.
- silentbicycle 16y ago
  From the coding conventions for Kona (http://github.com/kevinlawler/kona/wiki/Coding-Guidelines http://github.com/kevinlawler/kona/wiki/Coding-Guidelines), an open-source implementation of K 3.2 that I've been contributing to lately: This is a very unusual style of C "The unusual appearance is a side effect of writing C as concisely as possible. There are great benefits to writing code as concisely as possible. Someone familiar with the style can read and comprehend the code much faster than they would be able to with traditional code. It also creates a discipline that reduces bugs. Some of the benefits will not be apparent until you try it. Some of the downsides of the style are inaccessibility and a steep learning curve." You get used to code like that, and often, doing it that way makes sense. I first encountered it learning to read this short prototype interpreter (http://nsl.com/papers/origins.htm http://nsl.com/papers/origins.htm) by Arthur Whitney, which very strongly influenced the programming style in the J codebase. As gruesom notes, this discussion has already happened numerous times in the HN archives. Your reaction is the APL equivalent of going, "OMG! Parens!!!!1!" when introduced to Lisp code.
  - scott_s 16y ago
    Fair enough, although I've read many threads on APL-derived languages over the years on HN, but I somehow missed the discussion of the C runtime implementation.
    - silentbicycle 16y ago
      AFAICT, the implementations have usually been closed-source (with the exception of A+ (http://www.aplusdev.org/ http://www.aplusdev.org/), which is GPL'd; Arthur wrote it before K), and most research on APL implementation is locked behind the ACM paywall. I suspect part of the style comes from APLers typically being mathematicians as well as programmers, and drawing more from mathematics than typical "software engineering best practices" style.
      - scott_s 16y ago
        Then, forgive me for harping on this, how could this discussion have already happened numerous times on HN? And by "this discussion" I mean the C style used to implement APL-derived languages, not the style one uses to write programs in APL-derived languages.
- gruseom 16y ago
  Hi Scott. I don't exactly agree, because the terseness and lexical density of the C code are the same qualities as cause people to recoil from APL/J/K programs as well (http://www.nsl.com/k/s/s.k http://www.nsl.com/k/s/s.k). The implementation and language are cut from the same cloth. This of course is not always true (i.e. your point holds much better in the general case) - but it is true in this world, where program brevity and regularity are so highly prized. Let's note that the payoff for departing from the mainstream in this way is not small: these languages achieve abstractive (compositional) power and elegance without sacrificing efficiency. Those two things are incompatible in nearly every other programming context -- so much so that it's a truism that higher-level code is shorter but slower, lower-level code is faster but more verbose. Yet here they happily co-exist.
  - scott_s 16y ago
    silentbicycle's examples and points have actually made me come around somewhat. But there is a key difference between the terseness and density of APL-derived languages and the C implementation of the runtime: in the actual languages, the semantics of the language are well defined and enforced by the compiler. C is a free-for-all. So while there is discipline behind the C code - and I can see that it mimics the language it implements - it must be self discipline. That makes it more dangerous, and objecting to that is not the same as objecting to the APL family of languages themselves.
jfager 16y ago
Forgive me, I think we've had a misunderstanding. To my mind, the IOCCC is a contest where very smart people work very hard to bend C as far as it will go to come up with very clever programs. The fact that something as impressive as J is implemented like this blows me away, and while I would never want to (nor ever could) work in the codebase myself, I think it's wonderful.
- gruseom 16y ago
  Forgive me back. I was writing more hastily than I usually try to do and being kind of a grouch about it.

by gruseom 16y ago

akkartik 16y ago

I've seen some threads on APL, but I've never seen other languages used with APL-level compression. Are there really other threads about this? I'm not sure what to search for on searchyc.

silentbicycle 16y ago
Try any of these: apl iverson k kona whitney j hui incunabulum (That one-page J interpreter is sometimes called the "J Incunabulum".) See e.g. http://news.ycombinator.com/item?id=1458016 http://news.ycombinator.com/item?id=1458016 http://news.ycombinator.com/item?id=266982 http://news.ycombinator.com/item?id=266982 http://news.ycombinator.com/item?id=697501 http://news.ycombinator.com/item?id=697501 http://news.ycombinator.com/item?id=2176980 http://news.ycombinator.com/item?id=2176980

scott_s 16y ago

You're conflating the implementation of an environment with the value of the environment itself. Did you read the C code? It is terribly difficult to follow, does not follow C formatting idioms, and makes frequent use of macros that further obfuscate what is going on. Example: #define DECLG V*sv=VAV(self);A gs=sv->g; \ AF g1=gs?VAV(gs)->f1:0,g2=gs?VAV(gs)->f2:0 Judging the quality of this code says nothing about the language and environment that this code provides.

silentbicycle 16y ago
From the coding conventions for Kona (http://github.com/kevinlawler/kona/wiki/Coding-Guidelines http://github.com/kevinlawler/kona/wiki/Coding-Guidelines), an open-source implementation of K 3.2 that I've been contributing to lately: This is a very unusual style of C "The unusual appearance is a side effect of writing C as concisely as possible. There are great benefits to writing code as concisely as possible. Someone familiar with the style can read and comprehend the code much faster than they would be able to with traditional code. It also creates a discipline that reduces bugs. Some of the benefits will not be apparent until you try it. Some of the downsides of the style are inaccessibility and a steep learning curve." You get used to code like that, and often, doing it that way makes sense. I first encountered it learning to read this short prototype interpreter (http://nsl.com/papers/origins.htm http://nsl.com/papers/origins.htm) by Arthur Whitney, which very strongly influenced the programming style in the J codebase. As gruesom notes, this discussion has already happened numerous times in the HN archives. Your reaction is the APL equivalent of going, "OMG! Parens!!!!1!" when introduced to Lisp code.
- scott_s 16y ago
  Fair enough, although I've read many threads on APL-derived languages over the years on HN, but I somehow missed the discussion of the C runtime implementation.
  - silentbicycle 16y ago
    AFAICT, the implementations have usually been closed-source (with the exception of A+ (http://www.aplusdev.org/ http://www.aplusdev.org/), which is GPL'd; Arthur wrote it before K), and most research on APL implementation is locked behind the ACM paywall. I suspect part of the style comes from APLers typically being mathematicians as well as programmers, and drawing more from mathematics than typical "software engineering best practices" style.
    - scott_s 16y ago
      Then, forgive me for harping on this, how could this discussion have already happened numerous times on HN? And by "this discussion" I mean the C style used to implement APL-derived languages, not the style one uses to write programs in APL-derived languages.
gruseom 16y ago
Hi Scott. I don't exactly agree, because the terseness and lexical density of the C code are the same qualities as cause people to recoil from APL/J/K programs as well (http://www.nsl.com/k/s/s.k http://www.nsl.com/k/s/s.k). The implementation and language are cut from the same cloth. This of course is not always true (i.e. your point holds much better in the general case) - but it is true in this world, where program brevity and regularity are so highly prized. Let's note that the payoff for departing from the mainstream in this way is not small: these languages achieve abstractive (compositional) power and elegance without sacrificing efficiency. Those two things are incompatible in nearly every other programming context -- so much so that it's a truism that higher-level code is shorter but slower, lower-level code is faster but more verbose. Yet here they happily co-exist.
- scott_s 16y ago
  silentbicycle's examples and points have actually made me come around somewhat. But there is a key difference between the terseness and density of APL-derived languages and the C implementation of the runtime: in the actual languages, the semantics of the language are well defined and enforced by the compiler. C is a free-for-all. So while there is discipline behind the C code - and I can see that it mimics the language it implements - it must be self discipline. That makes it more dangerous, and objecting to that is not the same as objecting to the APL family of languages themselves.

jfager 16y ago

Forgive me, I think we've had a misunderstanding. To my mind, the IOCCC is a contest where very smart people work very hard to bend C as far as it will go to come up with very clever programs. The fact that something as impressive as J is implemented like this blows me away, and while I would never want to (nor ever could) work in the codebase myself, I think it's wonderful.

gruseom 16y ago
Forgive me back. I was writing more hastily than I usually try to do and being kind of a grouch about it.