Whole-known-network
<p><span class="h-card" translate="no"><a href="https://mathstodon.xyz/@bremner" class="u-url mention">@<span>bremner</span></a></span> <span class="h-card" translate="no"><a href="https://mastodon.social/@shriramk" class="u-url mention">@<span>shriramk</span></a></span> Such a good book. I frequently get nasty remarks when I point it out to those who still insist something like the OLPC initiative was a good idea, despite all evidence to the contrary.</p>
<p><span class="h-card" translate="no"><a href="https://bsd.network/@cynicalsecurity" class="u-url mention">@<span>cynicalsecurity</span></a></span> as for whether it makes sense: i don't think the latest fancy opcodes will make even the top #3. my number one concern would be whether the compiler does inlining, which is arguably the single most important optimization (cross-module inlining even more so). my number two would be code density, which the choice of opcodes to emit affects but the choice of opcodes to optimize out affects more</p>
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@shriramk" class="u-url mention">@<span>shriramk</span></a></span> I can miss a chance to recommend the book "The Charisma Machine" which has a lot to say about the acolytes of Papert.</p>
<p><span class="h-card" translate="no"><a href="https://bsd.network/@cynicalsecurity" class="u-url mention">@<span>cynicalsecurity</span></a></span> tons of these, take any beginner level compiler and it will do just that</p><p>tcc i think would fit?</p>
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@regehr" class="u-url mention">@<span>regehr</span></a></span> <span class="h-card" translate="no"><a href="https://types.pl/@lenary" class="u-url mention">@<span>lenary</span></a></span> i do, but i don't want it to have its own quirky toolchain that nobody makes good devtools for, and i especially don't want it to generate code in an opaque build system</p><p>right now i'm working on a heavily pattern matching oriented compiler in rust and the most i've accepted is using macro-by-example (if you're unfamiliar, a slightly-above-regex flexibility and power language over token streams / partial ASTs)</p><p>not building a procedural macro that generates code is a direct goal</p>
<p>Pinker said this of Chomsky, and it perfectly sums up CS Ed (w/ Papert):</p><p>Linguistics is an eccentric field…because it was so polarized by a charismatic figure and his opponents that it didn’t proceed in the ordinary direction of making the theory more precise, more testable.</p>
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> <span class="h-card" translate="no"><a href="https://types.pl/@lenary" class="u-url mention">@<span>lenary</span></a></span> you don't want some sort of declarative language?</p>
<p><span class="h-card" translate="no"><a href="https://types.pl/@lenary" class="u-url mention">@<span>lenary</span></a></span> <span class="h-card" translate="no"><a href="https://mastodon.social/@regehr" class="u-url mention">@<span>regehr</span></a></span> i have personally found cranelift to be vastly more pleasant to work with than tablegen (unsurprisingly, given how many lessons cranelift learned) but in my own compilers i still go very far to avoid making a tablegen</p>
<p>the LLVM people have made meta-TableGen. horrifying <a href="https://mlir.llvm.org/docs/Dialects/IRDL/" target="_blank" rel="nofollow noopener" translate="no"><span class="invisible">https://</span><span class="ellipsis">mlir.llvm.org/docs/Dialects/IR</span><span class="invisible">DL/</span></a></p>