HN user

gdwatson

580 karma
Posts8
Comments195
View on HN

I am not so paranoid, and I haven’t been working with AI, so my AI-dar is bad. But I keep reading technical writeups like this, then getting frustrated at the writing style or incomplete explanation – this one was more complete than most, though it was repetitive. Then I come read the HN comments, and I see that it was LLM-generated.

(To be fair, this one says so up top. Even so my eyes skipped over it.)

So I find the reaction helpful. I want to read posts in the best human style, but if the angry mob can’t motivate those, at least I can notice the pitchforks and torches, slap my forehead, and say, “Oh, that explains it.”

I think a lot of people just want to be able to discuss different areas of the automatic memory management design space separately, and maintaining the distinction between reference counting and garbage collection (meaning tracing GCs) lets them do that.

As for me personally, I consider refcounting and GC overlapping categories. I am perfectly willing to call CPython’s reference counting plus cycle collector a form of garbage collection, because it is transparent to the programmer. Every memory management technique has tradeoffs and pathological edge cases, but since you don’t have to consider them in the ordinary course of programming I’d say it counts. If you had to break cycles manually, or to annotate which references should be counted, I’d call that refcounting but not GC – as in the C++ stdlib.

This reminds me a bit of the way academics in programming language theory internalized the type-theoretic definition of the word “type” over and against the traditional programming definition. You sometimes see people who try to correct the term “dynamically typed language,” which makes perfect sense when types are data types, to “untyped” or “unityped,” which makes sense when types are mathematical constructs equivalent to proofs.

The colloquial term is clear in context, and it draws its boundaries in useful places. If academia prefers other boundaries to simplify its formal definitions, that’s understandable. But the rest of us shouldn’t restrict our language in that way.

It was a clever hack for porting existing code. But it doesn’t scale at all – you’ve just described adding four registers to a register-starved architecture in order to solve the issue for one CPU generation or so.

Leaving Mozilla 1 month ago

"He resigned and declined Mozilla's offer to remain in another C level position."

At this point I think it's clear his resignation was not voluntary. Maybe the other offer was sincere, or maybe it wasn't; I'm not sure how we could tell.

I actually think I like the baseline-aligned one best. It's spaced reasonably well while reflecting the character of each font better, IMHO. Or maybe it's just because a consistent baseline rhythm feels so typographically right.

I think the idea is that SmallTalk replaced conditional syntax with methods on booleans. You could call `ifTrue:` on a boolean, passing it a code block; a true boolean would execute the block, and a false boolean would not. (There was also an `ifFalse:` method.)

This feels more like a party trick than anything. But it does represent a deep commitment to founding the whole language on object orientation, even when it seems silly to folks like me.

I guess I am a sucker for stories about redesigning data structures, and I'd have liked more detail on that front. Also, they talked about Rust's greater memory safety; it would have been nice to know whether there were specific language features that played into the cache difference or whether it just made the authors comfortable using a systems language in this application and that made the difference.

I will confess to skimming by the end. But I don’t think they explained how they solved the cache issue except to say they rewrote the software in Rust, which is pretty vague.

Was all the code they rewrote originally in Lua? So was it just a matter of moving from a dynamic language with pointer-heavy data structures to a static language with value types and more control over memory layout? Or was there something else going on?

Scribus is an open source project but I’m not sure how the quality is in that.

I am not a typographer, and I’ve never used it in a professional capacity, but v1.6 (early 2024) improved Scribus a lot. I’ve used it and liked it for some personal projects for years, but the improved typography in 1.6 is big.

Years ago I wrote a toy Lisp implementation in Objective-C, ignoring Apple’s standard library and implementing my own class hierarchy. At that point it was basically standard C plus Smalltalk object dispatch, and it was a very cool language for that type of project.

I haven’t used it in Apple’s ecosystem, so maybe I am way off base here. But it seems to me that it was Apple’s effort to evolve the language away from its systems roots into a more suitable applications language that caused all the ugliness.

I think that diff algorithms have more in common with traditional, “lower” textual criticism than with the sort of source criticism canjobear is pondering.

It’s interesting that they’re organized by date. On an intuitive level, that makes sense. But so many of the dates are hotly debated, and reorganizing the list would produce such a different impression, that it’s a surprising choice.

I am not a scholar of such things, but a quick glance at the documents I am familiar with suggests that the date ranges represent uncertainty within the compiler’s point of view. That’s reasonable, but when it’s linked out of context it’s not immediately obvious that it doesn’t reflect the range of debate in the broader secular scholarship, let alone secular and conservative religious scholarship taken together. So caveat lector.

That said, the breadth of documents linked here is really impressive.

Units based on base 12 or base 2, as U.S. standard measures tend to be, are easier to divide in many ways.

Now if we used base 12 numbers instead of base 10, and we had a system of units based on that, I bet we’d have the best of both worlds. No idea if Napoleon could have imposed base 12 arithmetic on most of Europe the way he did metric, though.

I realize you are tongue in cheek, but I hope people respect the logical limits of this sort of thing.

Years ago, there were some development tools coming out of the Ruby world – SASS for sure, and Vagrant if I remember correctly – whose standard method of installation was via a Ruby gem. Ruby on Rails was popular, and I am sure that for the initial users this had almost zero friction. But the tools began to be adopted by non-Ruby-devs, and it was frustrating. Many Ruby libraries had hardcoded file paths that didn’t jive with your distro’s conventions, and they assumed newer versions of Ruby than existed in your package repos. Since then I have seen the same issue crop up with PHP and server-side JavaScript software.

It’s less of a pain today because you can spin up a container or VM and install a whole language ecosystem there, letting it clobber whatever it wants to clobber. But it’s still nicer when everything respects the OS’s local conventions.

Could you explain your reasoning? I don’t see any moral difference between deliberately limiting compatibility from the peripheral side and doing so from the “computer” side (i.e., iPhone, iPad, Macintosh). One type of device may produce more inadvertent incompatibilities than the other, but that’s different.

Besides, I think this will create surprise and confusion for less technical users. In my experience, many will blame the incompatibility on whichever device is new, without understanding who is gating out whom. And even for technical users, consider CarPlay and Android Auto: From the phone’s perspective, the car is a peripheral, and that makes sense; but lots of people will still consider the car the “core device.”

The first few times you use it, XSLT is insane. But once something clicks, you figure out the kinds of things it’s good for.

I am not really a functional programming guy. But XSLT is a really cool application of functional programming for data munging, and I wouldn’t have believed it if I hadn’t used it enough for it to click.

The point isn't that the developer should disable text selection whenever he thinks it's unnecessary, which would indeed be silly. It's that sometimes the user interface rules for navigating selectable text conflict or interfere with the user interface rules for navigating, say, a set of tab panes. In that situation, making the tab titles selectable will cause grief.

I agree with your address example. That is user data, and it should be selectable.

I agree. The closer to a traditional desktop U.I. you get, the jankier selecting clickable text becomes. For a simple web form, leaving labels selectable is no big deal and probably a win. But for something trying to behave like a tabbed dialog box, it breaks navigation left and right.

Which motherboards enable PBO out of the box? That’s crazy! I know that motherboard manufacturers set some sketchy default turbo durations for Intel CPUs back when Intel was cagey about the spec and let them get away with it, but I thought that AMD was stricter about such things.

It sounds like their lawyers have done the appropriate counter-challenge with YouTube, so the video will go back up unless Bloomberg sues them in the next so many days. And this is Gamers Nexus, so I presume they will fight to keep it as is on principle.

Personally, I found the length of the quotes from politicians kind of tedious, but I sure wouldn’t want them to capitulate to Bloomberg after this.