6 ms·

At first I was wondering how he managed to write a compiler in 750 loc. Then I noticed it's for APL, which I would call terse: Y0←{⊃,/((⍳≢⊃n⍵)((⊣sts¨(⊃l),¨∘⊃

At first I was wondering how he managed to write a compiler in 750 loc. Then I noticed it's for APL, which I would call terse: Y0←{⊃,/((⍳≢⊃n⍵)((⊣sts¨(⊃l),¨∘⊃s),'}',nl,⊣ste¨(⊃n)var¨∘⊃r)⍵),'}',nl} See also https://en.wikipedia.org/wiki/APL_(programming_language)#Examples https://en.wikipedia.org/wiki/APL_(programming_language)#Exa...

zzzcpan 10y ago
He also replaces long names with short ones, so it's more like an obsession. First commit I clicked on was replacing "penv" with "p" just to make it shorter.
- coldtea 10y ago
  That wouldn't affect line count.
  - devmunchies 10y ago
    It would if you have a max length rule for lines and some need to broken up.
  - hobarrera 10y ago
    It does affect deleted/added lines. You can quickly have several dozed deletions and additions renaming a single variable.
- arcfide 10y ago
  There's a specific reason I made that switch, which for a long time had appeared to be a silly change. Eventually I realized that "penv" as a name was so different from the rest of the naming conventions that it was causing cognitive dissonance in my programming that was taking me out of the flow and making it more difficult to work with the code. Move to the name "p" did shorten the code, but more importantly, brought more consistency, predictability, and regularity into the code base. It is a case of synergizing simplicity and brevity and how they work together.
  - zzzcpan 10y ago
    That's ok, but documenting naming conventions is equally as important. How else are you going to remember them when some time passes or how someone else is going to understand them.
    - arcfide 10y ago
      I would tend to agree. It's certainly a generally good rule of thumb. However, I've honestly struggled to find a way to document the naming conventions that is useful. Every time I've wondered about a particular name, it's faster for me to go to the definition sight of that name than to seek documentation, and the documentation for the naming conventions might exceed the size of most of the compiler, simply because it's hard to write out all of the aesthetic and stylistic choices that are almost self enforcing through an overwhelming pressure of context when you're actually programming in the code. Basically, while I am a huge fan of documentation, with this style and the approach I'm taking, I've found it exceptionally difficult to create up to date, meaningful, and reliable documentation of any sort that isn't totally useless. Now, I do have public API documentation, but internal developer docs have not proven to be helpful at all for any reason in this compiler. I've tried on multiple occasions to make it happen, and it just doesn't work here. If you have a way to do so, or even maybe if you want to talk with me and make it happen, all the better, but when the code base changes so fast all the time, it's just very hard to keep documenting this fluid thing that keeps changing. In some ways that includes the naming conventions. I'm quite open to people providing ideas on how to properly document this project outside of "big idea" documentation that I'm currently doing with the paper publications. I've yet to be able to find anything that works. The standard best practices don't seem to flow well at all, but maybe I've missed something.
Silhouette 10y ago
Does anyone here program APL? I've tried to look into it occasionally because the idea of powerful, concise syntax appeals to me, but the unfamiliar syntax was always too much to get my head around within a reasonable amount of time. I'm curious to know whether it really does become second nature after a while, in the same way that some of us might read a printf format string or regular expression quite fluently after many years of working with them.
- RodgerTheGreat 10y ago
  I program in K, a close relative, and I have done some tinkering with APL. The symbols actually don't take long to memorize- perhaps a few days of practice. It's a bit like learning to read prose. At first you have to sound out words letter by letter, but eventually you're able to "see" words and phrases built out of common patterns of symbols. I see ,/f' and think flatmap, ~~': and think heads of uniform runs, {x@<x} and think sort up, etc. A dense expression can still take a while to puzzle out sometimes, but certainly no longer than the equivalent logic spelled out in a more verbose language across many lines.
  - willhslade 10y ago
    What's it like looking for a K job?
    - RodgerTheGreat 10y ago
      In my experience, if you do enough open source stuff with K, jobs find you.
  - 35bge57dtjku 10y ago
    I've looked at some of the ascii APL relatives, and my impression was that they are probably great for working with numbers, but seem like they'd be bad for working with text and other things. Am I missing something here?
    - 10y ago
arcfide 10y ago
Actually, most of those 750 LoC is C++ code for the runtime, written in a style to match the semantic density of the rest of the code, as well as code for calling off to the various C compilers on various operating systems. The core compiler (between the parser and final code generator pass) is around 90 lines and is written is a particular style of APL code.
userbinator 10y ago
For something in a more... conventional language, here's a compiler/interpreter for a C subset in ~500 lines: https://news.ycombinator.com/item?id=8558822 https://news.ycombinator.com/item?id=8558822

zzzcpan 10y ago

He also replaces long names with short ones, so it's more like an obsession. First commit I clicked on was replacing "penv" with "p" just to make it shorter.

coldtea 10y ago
That wouldn't affect line count.
- devmunchies 10y ago
  It would if you have a max length rule for lines and some need to broken up.
- hobarrera 10y ago
  It does affect deleted/added lines. You can quickly have several dozed deletions and additions renaming a single variable.
arcfide 10y ago
There's a specific reason I made that switch, which for a long time had appeared to be a silly change. Eventually I realized that "penv" as a name was so different from the rest of the naming conventions that it was causing cognitive dissonance in my programming that was taking me out of the flow and making it more difficult to work with the code. Move to the name "p" did shorten the code, but more importantly, brought more consistency, predictability, and regularity into the code base. It is a case of synergizing simplicity and brevity and how they work together.
- zzzcpan 10y ago
  That's ok, but documenting naming conventions is equally as important. How else are you going to remember them when some time passes or how someone else is going to understand them.
  - arcfide 10y ago
    I would tend to agree. It's certainly a generally good rule of thumb. However, I've honestly struggled to find a way to document the naming conventions that is useful. Every time I've wondered about a particular name, it's faster for me to go to the definition sight of that name than to seek documentation, and the documentation for the naming conventions might exceed the size of most of the compiler, simply because it's hard to write out all of the aesthetic and stylistic choices that are almost self enforcing through an overwhelming pressure of context when you're actually programming in the code. Basically, while I am a huge fan of documentation, with this style and the approach I'm taking, I've found it exceptionally difficult to create up to date, meaningful, and reliable documentation of any sort that isn't totally useless. Now, I do have public API documentation, but internal developer docs have not proven to be helpful at all for any reason in this compiler. I've tried on multiple occasions to make it happen, and it just doesn't work here. If you have a way to do so, or even maybe if you want to talk with me and make it happen, all the better, but when the code base changes so fast all the time, it's just very hard to keep documenting this fluid thing that keeps changing. In some ways that includes the naming conventions. I'm quite open to people providing ideas on how to properly document this project outside of "big idea" documentation that I'm currently doing with the paper publications. I've yet to be able to find anything that works. The standard best practices don't seem to flow well at all, but maybe I've missed something.

Silhouette 10y ago

Does anyone here program APL? I've tried to look into it occasionally because the idea of powerful, concise syntax appeals to me, but the unfamiliar syntax was always too much to get my head around within a reasonable amount of time. I'm curious to know whether it really does become second nature after a while, in the same way that some of us might read a printf format string or regular expression quite fluently after many years of working with them.

RodgerTheGreat 10y ago
I program in K, a close relative, and I have done some tinkering with APL. The symbols actually don't take long to memorize- perhaps a few days of practice. It's a bit like learning to read prose. At first you have to sound out words letter by letter, but eventually you're able to "see" words and phrases built out of common patterns of symbols. I see ,/f' and think flatmap, ~~': and think heads of uniform runs, {x@<x} and think sort up, etc. A dense expression can still take a while to puzzle out sometimes, but certainly no longer than the equivalent logic spelled out in a more verbose language across many lines.
- willhslade 10y ago
  What's it like looking for a K job?
  - RodgerTheGreat 10y ago
    In my experience, if you do enough open source stuff with K, jobs find you.
- 35bge57dtjku 10y ago
  I've looked at some of the ascii APL relatives, and my impression was that they are probably great for working with numbers, but seem like they'd be bad for working with text and other things. Am I missing something here?
  - 10y ago

arcfide 10y ago

Actually, most of those 750 LoC is C++ code for the runtime, written in a style to match the semantic density of the rest of the code, as well as code for calling off to the various C compilers on various operating systems. The core compiler (between the parser and final code generator pass) is around 90 lines and is written is a particular style of APL code.

userbinator 10y ago

For something in a more... conventional language, here's a compiler/interpreter for a C subset in ~500 lines: https://news.ycombinator.com/item?id=8558822 https://news.ycombinator.com/item?id=8558822