|
|
|
|
|
by jelliclesfarm
2026 days ago
|
|
>A more serious analysis of brevity might define it as “the entropy of a parse tree recursively inlined/macroexpanded down to language primitives.” This suggests our focus ought to be on two questions: how compressible are our primitives, and how can we enable users to achieve something close to optimal compression? Since the first question has a relative measure (what’s the compression ratio for our expanded parse tree?), we could productively iterate on both better primitives and better tools for abstracting over them. But Graham’s analysis of brevity, and indeed of all language design, was fundamentally unserious. He wasn’t interested in a rigorous definition of brevity, because the ultimate measure of a language’s quality was still his hacker’s radar. All of his essays, and Arc itself, were just spokes around that central hub. If his essays sometimes disagreed, or if Arc didn’t reflect his essays, it’s hardly surprising; their only connection was they all, in the moment, seemed right and true to Paul Graham[..] I dont understand what the author means by 'brevity'. Is that the same as what one might call 'elegant code'? I prefer to use the term elegant. From the article, it seems to me that PG's prefers elegant code that is modular and neat. It is reflected in his essays and how he approaches subjects. Code can be elegant and modular. People are complex. You can hack them, but you cant debug people. |
|
> It would not be far from the truth to say that a hacker about to write a program decides what language to use, at least subconsciously, based on the total number of characters he’ll have to type.