pcfwik

Since this is about C declarations: for anyone who (like me) had the misfortune of learning the so-called "spiral rule" in college rather than being taught how declarations in C work, below are some links that explain the "declaration follows use" idea that (AFAIK) is the true philosophy behind C declaration syntax (and significantly easier to remember/read/write).

TL;DR: you declare a variable in C _in exactly the same way you would use it:_ if you know how to use a variable, then you know how to read and write a declaration for it.

https://eigenstate.org/notes/c-decl https://news.ycombinator.com/item?id=12775966

Oh awesome, thanks for the pointer!

I once considered Wren for a situation where I (to a first approximation) wanted to allow users to write 'plugins' that link against my internal C application symbols but using a language focusing more on ease of use (rather than C).

Unfortunately, neither Wren nor any of the other major 'embeddable scripting languages' (e.g., Lua) were really a good fit for this, because they commit fully to the 'all-numbers-are-floats' thing and generally don't seem to even try to provide a general equivalent to the C++ `extern "C" { ... }` thing.

Of course, I know this isn't really the target use case of Wren/Lua/etc., but if anyone knows of a good embeddable scripting language for this I'd love to hear about it. Eventually I went with CPython (which provides ctypes to solve my problem) but it's a huge pain to embed properly.

FWIW --- programmer dvorak lets you type () without "shift" but both ~ and ^ require shift. https://www.kaufmann.no/roland/dvorak/

Re: visualizations of lambda terms, also see "To Dissect a Mockingbird" https://dkeenan.com/Lambda/

makes sense, thanks --- cool project!

Also find it interesting that you're allowing out-of-bounds pointer arithmetic as long as no dereference happens, which is a class of UB compilers have been known to exploit ( https://stackoverflow.com/questions/23683029/is-gccs-option-... ). Do you disable such optimizations inside LLVM, or does Fil-C avoid this entirely by breaking pointers into pointer base + integer offset (in which case I wonder if you're missing out on any optimizations that work specifically on pointers)?

Given the goal is to work with existing C programs (which already have free(...) calls "carefully" placed), and you're already keeping separate bounds info for every pointer, I wonder why you chose to go with a full GC rather than lock-and-key style temporal checking[1]? The latter would make memory usage more predictable and avoid the performance overhead and scheduling headaches of a GC.

Perhaps storing the key would take too much space, or checking it would take too much time, or storing it would cause race condition issues in a multithreaded setting?

[1] https://acg.cis.upenn.edu/papers/ismm10_cets.pdf

To add another suggestion for understanding the Fourier transform, personally the first explanation that ever clicked with me was the Aho/Hopcroft/Ullman algorithms textbook.

Rather than talking about sine and cosine waves, they motivate the Fourier transform entirely in terms of polynomials. Imagine you want to multiply two polynomials (p(x) and q(x)). The key is to recognize that there are two ways to represent each polynomial:

1. "Coefficient form," as a set of coefficients [p_0, p_1, p_2, ..., p_d] where p(x) = p_0 + p_1x + p_2x^2 + ... + p_dx^d, OR

2. "Sample form," as a set of sampled points from each polynomial, like [(0, p(0)), (1, p(1)), (2, p(2)), ..., (d, p(d))]

Now, naive multiplication of p(x) and q(x) in coefficient form takes O(d^2) scalar multiplications to get the coefficients of p(x)q(x). But if you have p(x) and q(x) in sample form, it's clear that the sample form of p(x)q(x) is just [(0, p(0)q(0)), (1, p(1)q(1)), ...], which requires only O(d) multiplications!

As long as you have enough sample points relative to the degree, these two representations are equivalent (two points uniquely defines a line, three a quadratic, four a cubic, etc.). The (inverse) Fourier transform is just a function that witnesses this equivalence, i.e., maps from representation (1) to representation (2) (and vice-versa). If the sample points are chosen cleverly (not just 1/2/3/...) it actually becomes possible to compute the Fourier transform in O(d log d) time with a DP-style algorithm (the FFT).

So, long story short, if you want to multiply p(x) and q(x), it's best to first convert them to "sample" form (O(d log d) time using the FFT), then multiply the sample forms pointwise to get the sample form of p(x)q(x) (O(d) time), and then finally convert them back to the "coefficient" form (O(d log d) using the inverse FFT).

This is the leverage paradox. New technologies give us greater leverage to do more tasks better. But because this leverage is usually introduced into competitive environments, the result is that we end up having to work just as hard as before (if not harder) to remain competitive and keep up with the joneses.

Off-topic, but in biology circles I've heard this type of situation (where "it takes all the running you can do, to keep in the same place" because your competitors are constantly improving as well) called a "Red Queen's race" and really like the picture that analogy paints.

https://en.wikipedia.org/wiki/Red_Queen%27s_race

I assume the poster is referencing Citizens United v. FEC, specifically about the government's use of the 2002 Bipartisan Campaign Reform Act to restrict showing of political documentaries (apparently, called "Hillary: The Movie" and "Celsius 41.11").

While (as far as I know) the law was never actually used to ban books (only documentaries), the case became infamous because the government argued that it had the right to ban books if it wanted to. See, e.g., the NYTimes article below: "The [government's] lawyer, Malcolm L. Stewart, said Congress has the power to ban political books, signs and Internet videos, if they are paid for by corporations and distributed not long before an election.".

https://www.nytimes.com/2009/03/25/washington/25scotus.html https://en.wikipedia.org/wiki/Citizens_United_v._FEC https://www.law.cornell.edu/supct/cert/08-205

Absolutely not a perfect solution, and maybe you're already using it within your Makefiles, but for anyone who doesn't yet know about it there's Latexmk[1] which is supposed to automate all of this hassle. I think at least on Debian it's included with texlive-full. In addition it has some nice flags like `-outdir` which lets you send all the crazy LaTeX intermediate build/aux files to a separate directory that's easy to gitignore.

https://mgeier.github.io/latexmk.html#running-latexmk

That is not a TCP/IP stack in 200 LoC.

I agree --- I mostly think it's interesting as one of the most concrete examples of what they claim to have actually done that I've been able to find.

In general, it's frustrating that, as far as I can tell, they don't seem to have made any of the code from the project open source. Widespread skepticism about their claims due to this is (IMO) justified.

(Edit: for folks interested, it seems like some of the code has found itself scattered around the Web ... https://news.ycombinator.com/item?id=19844088 )

I don't think they DID build a modern computing environment at all.

I agree that, now, after they've tried and failed, we can say they didn't build a modern computing environment in 20kloc.

My point is just that, when they were pitching the project for funding, there was no real way to know that this "trillion dollar technology" goal would fail whereas nukes/moon mission/etc. would succeed. Hindsight is 20/20, but at the beginning, I don't think any of these projects defined themselves as "doing something that lots of people are trying to do all the time;" instead they would probably say "nobody else has tried for a 20kloc modern computing system, we're going to be the first."

Given they all promised to try something revolutionary, I'm not sure it's fair to claim after-the-fact how obvious it is that one would fail to achieve that vs. another.

But I do take your point that it's important in general not to fall into the trap of "do X but tweak it to be a bit better" and expect grand results from that recipe.

Sorry, added an edit to my above post before I saw this, just to summarize:

I think that's a more reasonable complaint, but I fear it's too vague to be applicable.

The STEPS folks would probably say that a modern computing environment in ~20kloc is something that was previously unaccomplished and thought to be unaccomplishable, but you're writing that off/not counting it as such, presumably because it failed.

On the other end of the spectrum, things like Git (to my knowledge) did come out of the "find a better way to source control" incremental improvement mindset. (Of course, you can say the distributed model was "previously unaccomplished," but the line here is blurry.)

Let me guess, they published a bunch of papers, did a bunch of experiments like "lets do X but gui" "what if you didn't have to learn syntax" and then nobody ever did anything with any of the work because it was a total dead end.

This response is very confusing to me, and it seems you have a very different understanding of what STEPS did than I do.

In my understanding, the key idea of STEPS was that you can make systems software orders of magnitude simpler by thinking in terms of domain-specific languages, i.e., rather than write a layout engine in C, first write a DSL for writing layout engines and then write the engine in that DSL. See also, the "200LoC TCP/IP stack" https://news.ycombinator.com/item?id=846028

You seem to think they're advocating a Scratch-like block programming environment, but I'm not sure that's accurate. Can you point to where in their work you're finding this focus?

I too believe STEPS was basically a doomed project, but I don't think it's for the reason you've said (moreso just the extreme amount of backwards compatibility users expect from modern systems).

(--- edit: ---)

You don't make leaps from paying grad students to play around with "how can we make programming better", you get it from all of a sudden an AI can just generate code.

I think this is a more compelling point, but it doesn't seem to explain things like the rise of Git as "a way to make programming (source control) better," and it's not clear how to determine when something counts as an "all of a sudden" sort of technology. They would probably say their OMeta DSL-creation language was this sort of "all of a sudden" technological advance that lets you do things in orders of magnitude less code than before.

I think it would get a lot less hate if Google just made it possible to opt-out of them without having to download some third-party browser extension (which is actually what Google's AI summary itself suggests I do when I ask it how to turn itself off!). A small "opt out" link on the top of the AI suggestion would make most of this hate go away, and would make me stop paying for Kagi, if Google cared.

I also find it extra frustrating when AI summaries appear when I search for correctness-critical information, e.g., "what temperature to cook chicken?" or "can I eat old eggs?" --- why force me to scroll past an entire page of AI generated, 1%-chance-of-being-a-literally-lethal-hallucination "summaries" in order to find the CDC's actual recommendation? I don't want to play Russian roulette with my health hoping I don't get a hallucination, instead I just want the authoritative answer. Which Google did an amazing job at until a year ago, and Kagi is doing a pretty great job at now.

This book has some nice cuttable flexagon templates on thicker paper, with designs: https://www.amazon.com/Fantastic-Flexagons-Hexaflexagons-Oth...

The designs are fun, although I find that the thicker paper actually makes them a bit harder to fold and flex than typical printer paper.

If you find flexagons interesting, you might like trying to find a copy of Martin Gardner's "Scientific American Book of Mathematical Puzzles and Diversions" at your local used book sale. The first chapter is about flexagons and it gets better from there! Wonderful car ride, plane, etc. distractions.

https://www.amazon.com/Scientific-American-Mathematical-Puzz...

At least in my personal case: GLR sounds great in theory, but I like to implement things 'from scratch' when possible. Both PEGs and the basic Earley algorithm are incredibly simple to write up and hack on in a few hundred lines of insert-favorite-language-here.

GLR would probably have (much) better performance but I'm usually not parsing huge files (or would hand-roll one if I were). I've not yet found an explanation of GLR (or even LR for that matter) that's quite as simple as PEGs or Earley (suggestions welcome tho!).

There was an interesting discussion two years ago regarding nonobvious issues with PEGs:

https://news.ycombinator.com/item?id=30414683

https://news.ycombinator.com/item?id=30414879

I spent a year or two working with PEGs, and ran into similar issues multiple times. Adding a new production could totally screw up seemingly unrelated parses that worked fine before.

As the author points out, Earley parsing with some disambiguation rules (production precedence, etc.) has been much less finicky/annoying to work with. It's also reasonably fast for small parses even with a dumb implementation. Would suggest for prototyping/settings when runtime ambiguity is not a showstopper, despite the remaining issues described in the article re: having a separate lexer.

Also possible to do directly in the "safe" type system, without messing around with /proc/mem: https://zyedidia.github.io/blog/posts/5-safe-transmute/