gdwatson

Names for C successor languages are pretty well exhausted by this point, so I sympathize, but I strongly associate the name C* with a decade-old rant about C compilers’ aggressive exploitation of undefined behavior: https://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_20... . (In calling it a rant I don’t mean that it’s altogether unpersuasive. Its style is just a bit spicier than I am used to seeing typeset in Computer Modern.)

I am bad at recognizing LLM writing off the bat, though I am getting better. It's pretty common that the writing is good enough to get me reading on a topic I am interested in; then, once I am invested in the piece, it turns out to be shallow, wildly incomplete, or simply wrong.

It's common enough that it's training me to recognize and recoil from AI tics through sheer classical conditioning.

Deliberately so, and for an Internet standard correctly so. I know there is a long tail of environments, so I am curious. What's your environment like that you need traffic inspection but don't have full control of the clients?

There are two angles on this. There is the rejection of the humanities in favor of science and wealth, which are good things in themselves but are not everything. But, on the other hand, what many modern humanities faculties offer is a very time-bound activism that rejects books from 500 years ago and is not interested in the permanent things.

That post salvaged the subreddit; before, it had lost its focus. When I came back to give it another try, that post had become a meme and a rallying cry, and the sub had a lot of legitimately interesting thoughts and discussion.

Fair. If only they'd retired those APIs, too.

I remember when Windows gained experimental support for a UTF-8 locale usable with its 8-bit APIs. I used to run it at work; it had some issues at first, but most got shaken out pretty quickly. I don't know its current state, but that's probably the best route to UTF-8 on Windows if MS would lean into it.

Windows bought into Unicode hard before Unicode expanded beyond 16 bits. The consequence is that its native strings are theoretically UTF-16, but often behave like UCS-2, allowing random halves of surrogate pairs. Windows APIs reflect that, Windows filenames reflect that, and translation into UTF-8 has to reflect that -- somehow. It's not great.

Personally I'd like a world where Unicode gave up all the compromises that come with supporting UTF-16. But presumably burning all your early adopters is not a winning strategy.

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 stumbled over that too, but it makes sense when you finish the article. The ancient Romans didn’t build a lot of keyboards.

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.

"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.

> Now maybe its my male engineer brain, but I haven't heard of that color in 36 years, but it does make sense and it is rather distinct.

You need to get into either fishing (chartreuse lures are common) or cocktails: https://en.wikipedia.org/wiki/Chartreuse_(liqueur) .

I feel like I am missing too much background here. If there is only one licensor, why add terms to defeat the license it chose rather than choose a license which does not need defeating?

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 hope that God is indeed willing, but the man is 88 years old and he’s not done with the third tome of volume four. It would require a minor miracle for him to finish volume 7 within this lifetime.

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 really miss the days of the fairness-doctrine.

There are so many ways to game the system, whom do you trust to enforce it? I don’t trust my own “side” to do so, and I sure as heck don’t trust the other side.

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.”

Beside being a neat font in its own right, Iosevka allows for custom builds with different settings, selection from a bunch glyph variants, and custom ligature choices. It's pretty incredible.

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.