mistercow

CoffeeScript was great except for a few fatal mistakes. The biggest was implicit variable declarations, which meant that to write maintainable code, you had to reintroduce explicit declarations via iifes. Otherwise, you’d risk a future code change introducing shadowing which would have consequences that were super painful to debug.

The other big one, which unfortunately Civet seems to be doing too, is implicit return combined with “everything is an expression”. You can have one of those, but not both. With both, it’s far too easy to write loops intended to be statements, and which accidentally turn into gigantic multi-dimensional array returns which can’t easily be optimized out by the compiler. Fortunately, this would be only mildly inconvenient to work around with a lint rule that forces explicit return in all functions.

It’s interesting because this is the point of make, but it seems really common for make alternatives to miss this.

And that’s frustrating, because the place where a make alternative could really shine is not in making the syntax for specifying scripts nicer, but in figuring out how to design the dependency APIs so that you aren’t almost guaranteed to get them wrong in subtle ways.

But that’s not how FM receivers generally work. They don’t just take a chunk of the spectrum and measure relative amplitudes within that window. Some very quick and dirty FM demodulators do something like that, but they have poor noise rejection, so the analogy fails.

Proper receivers use a phase-locked loop to “lock on” to a carrier, rejecting any weaker interference on nearby frequencies.

In the analogy, suppose you’re decoding a signal from a flashlight over the entire color spectrum, but sunlight shines through the leaves of the tree, adding a slight green noise component to what you see, while the flashlight is actually red. You’ll erroneously interpret the signal as slightly yellow.

We don’t have anything like the PLL in our eyes, so the analogy breaks down here. In the equivalent scenario with an actual FM signal, that slight “green” component would not affect the received signal (or it would affect it to a much lesser extent).

It is not literally the same. The colors you perceive on the screen in front of you demonstrate why. That banner above is not orange; it’s red and green. You don’t actually have the ability to distinguish a varying frequency between red-orange and yellow-orange, and two amplitude modulated “carriers” at red and green.

That’s the hallmark of an analogy. It gives the general idea, but breaks down if we interrogate it in too much detail.

Except that color isn’t the same thing as wavelength when it comes to humans perceiving light, because our eyes only deal with the total energy within each of three overlapping bands. An FM receiver knows the difference between a single carrier varying in frequency, and two carriers of different frequencies varying in proportion. Our eyes don’t, hence the banner above appearing orange, even though it’s actually made of different proportions of red and green.

I wonder how the performance would be if you ran it in Pyodide.

Copilot’s main thing is to be autocomplete on steroids, so I’m not sure what exactly you’re looking for. Cursor’s Copilot++ is able to make more complex edits, which is good in boilerplate heavy situations, but it’s not as good at inline completions. I use a combination, flipping copilot++ on only when I’m doing rote migrations and refactors.

If you’re looking for “type in some English text and get fifty lines of code written”, Cursor’s chat is the best I’ve tried. But I’m not a fan of that workflow, so take my opinion with a grain of salt on that.

I can only get behind this if there’s a fixed exchange rate between two coinable metals that doesn’t change with their relative scarcity.

My own mental picture of that makes it just feel very clever, rather than magical. If you imagine that addition is easy, but division is hard, it’s pretty easy to see how you can build fast integer multiplication out of addition, and create hard to reverse operations like key exchange.

Now replace “addition” with modular multiplication, and “division” with the logarithm, and you have the trick behind DH. Swap out addition for this weird operation that involves jumping around elliptic curves, and you have the trick behind ECDH (admittedly, the fact that that jumping around thing works as a group operation is still pretty magical).

What I like about this way of thinking about it is that you can fully implement the key exchange in terms of integer addition, and the fact that it lets you pass around secrets in a world without “division oracles” seems pretty mundane.

Sometimes a remnant of the magic remains in the math, though, even after you understand why the math must work. The Burrows-Wheeler transform used in bzip2 is an example of this for me. I get why it works, but it just feels too damned convenient, almost as if this is one of the universe’s APIs, and you don’t get to look into the source code of this one to find out why such a simple maneuver is so effective on exactly the sort of data we like to compress.

> If a competitor puts out a better model than yours, people can switch to theirs by updating a few lines of code.

This may become increasingly the case as models get smarter, but it’s often not the case right now. It’s more likely to be a few lines of code, a bunch of testing, and then a bunch of prompt tweaking iterations. Even within a vendor and model name, it’s a good idea to lock to a specific version so that you don’t wake up to a bunch of surprise breakages when the next version has different quirks.

> In Calling Bullshit, the authors give the example of the Virginia Mason Quality Equation Q = [Ax(O+S)÷W]

I read somewhere (maybe in Thinking, Fast and Slow?), that formulas like this can actually be surprisingly effective, even though the units don’t make sense, because they encode an intuition but prevent you from putting your finger on the scale when applying it, by mixing in other biases. IIRC, the studies on this found that trying to tune these formulas by adding in weights tended to make them worse, which is especially surprising.

I’ll have to see if I can dig up the reference on this.

The problem I have with this is that when you give therapy to people with certain personality disorders, they just become better manipulators. Knowledge and understanding of ethics and empathy can make you a better person if you already have those instincts, but if you don’t, those are just systems to be exploited.

My biggest worry is that we end up with a dangerous superintelligence that everybody loves, because it knows exactly how to make every despotic and divisive choice it makes sympathetic.

I think o1 is a pretty big step in this direction, but the really tricky part is going to be to get models to figure out what they’re bad at and what they’re good at. They already know how to break problems into smaller steps, but they need to know what problems need to be broken up, and what kind of steps to break into.

One of the things that makes that problem interesting is that during training, “what the model is good at” is a moving target.

I'm kind of confused what's going on here. Typically, with this kind of thing, you convert the input image to black and white and then, for each pixel, choose the character whose average value most closely matches that pixel. Then you print out that character in a fixed color. The point is generally to convert the image into a format that would be able to display on a simple text-only output device, like a typewriter.

But this seems to be varying the intensity of each character as well, which means you'd only be able to display the result on a full color display in the first place.

Yeah it’s slightly more token heavy, although not as much as it seems like at first glance. Most opening tags are 2-3 tokens, and most closing tags are 3-4. Since tags are generally a pretty small fraction of the text, it typically doesn’t make a huge difference IME, but it obviously depends on the particular content.

Have you compared markdown to just stripping the HTML down (strip tag attributes, unwrap links, remove obvious non-displaying elements)? My experience has been that performance is pretty similar to markdown, and it’s an easier transformation with fewer edge cases.

I mean sure. All software is built on assumptions. Make sure the assumptions you’re making are appropriate in context.

Also if you want a program to call itself, which is sometimes useful, this way lets you actually call the same program, rather than assuming the name and path.

Also the analogy just really breaks at the seam we’re examining because a reasonable and obvious answer would be “I like the pies you get from this one”, which isn’t a great answer if you’re talking about software. And recipes are a lot simpler than software, so your friend could just look at the two recipes and quickly see how they’re different.

I think probably not, if the assets are coming from the same place, since the connection will be reused in most modern situations. Maybe if you’re loading the JS from a CDN though, and there are no other large resources, or those resources come from a different server.

I think you have to look at this in the context of an entire bundle or project, and then you have to weigh it against the download speeds you’re generally expecting for the users of your site or app.

I agree that as a blanket statement “gzip is enough” is not technically correct, but I think it’s largely correct in spirit, in that people tend to reach for minification by default, without really thinking about what they’re gaining.

If minifying saves you 200 KB overall, for example, and you expect your average user to have a 200 Mbps connection, you’re saving a grand total of 8 ms on page load, which is an imperceptible difference on its own. In exchange, you’re getting worse debugging, and worse error reporting.

I don’t think they’re saying that minifying provides no additional space savings, but rather that those additional savings are small and not worth the tradeoffs.

> Obviously base64 is a simpler transformation than rot13

Is it? It’s probably more obscuring from an LLM’s perspective, assuming the LLM has seen enough rot13 text during training. Spaces and punctuation are untouched by rot13, unlike base64, which means that word and sentence boundaries will still be denoted by tokens that denote those boundaries in plaintext.

Beautifiers will restore whitespace, but they won’t rename variables by inferring their semantic meaning.

It seems to be consistent. The correct answer was the first for all but the last question for me.

That's not generally how the legal system works. If you've disabled the duplication filter, and then generated substantial amounts of duplicated GPL code and then violated the GPL license, a judge is not going to say "Well, fair enough, you used the loophole of copying code through an LLM, after all." They're going to treat it as a willful copyright violation, the same as if you'd just copied and pasted it.

And again, I have to ask: why? Why would you think that putting tons of time and effort into tricking the model into repeating memorized code is going to be a better investment than just using it normally to implement the functionality you want?

That’s an interesting rhetorical trick, because answering the question “what is an LLM” requires a lecture series, not a hacker news comment.

It’s trained on publicly available code, so what would be the point of that? If you’re looking to specifically infringe the copyright of code available on the open web, using an LLM code completion engine is just about the most roundabout and unreliable way to achieve that.

There is a vast distance between “accurate self-assessment” and “no idea what the interviewer is looking for”.

I’ve already explained why I think obscuring poor performance to preserve candidate confidence is crucial. If you think that’s a “terrible interview”, maybe you could elaborate on why, rather than just asserting it.