jstimpfle

std::string is not UTF-8 and can't be made UTF-8. It's encoding agnostic, its API is in terms of bytes not codepoints.

What type of filter do you mean? Unless I'm misunderstanding/missing something, the approach described doesn't go into the details of how coverage is computed. If the input image is only simple lines whose coverage can be correctly computed (don't know how to do this for curves?) then what's missing?

I'd be interested how feasible complete 2D UIs using dynamically GPU rendered vector graphics are. I've played with vector rendering in the past, using a pixel shader that more or less implemented the method described in the OP. Could render the ghost script tiger at good speeds (like 1-digit milliseconds at 4K IIRC), but there is always an overhead to generating vector paths, sampling them into line segments, dispatching them etc... Building a 2D UI based on optimized primitives instead, like axis-aligned rects and rounded rects, mostly will always be faster, obviously.

Text rendering typically adds pixel snapping, possibly using byte code interpreter, and often adds sub-pixel rendering.

I'm not worried about expensive copies. I'm worried about being able to understand my systems code. The solution isn't adding more abstractions (like move semantics on top). I don't want to move anything. I want to be clear about taking a reference or making an actual copy, these are deeply, semantically, different. This difference is important for single threaded code but also for concurrency -- not only with mutable data types but also with immutable ones.

Performance is mostly a consequence of clear and direct code. You mostly don't achieve performance by saving individual copies, but by being in control of the code and architecture.

In C++, in particular when restricting to a C like subset, I prefer looking at an expression like

    foo->bar.baz

instead of (in Rust and other modern languages that decided to get rid of the distinction)

    foo.bar.baz

For example, the former lets me easily see that I can copy foo->bar and I now have a copy of baz (and indeed bar). In a newer language, it's harder to see whether we are copying a value or a reference.

I deny this rhetoric; you can use it to justify all kinds of wrongs. I can't tell you what I'd done if I was living in the early days of Hitler, because I don't have that context, while I do have the hindsight. Comparing Hitler with the current US administration seems a bit of a stretch to me, even though I have strong disagreements with some of the things that Trump/MAGA are doing (or _seem_ to be doing. At this point it's hard to trust anything anymore). On the other hand, there's a serious question to be asked, had we not been on a descent to madness for more than a decade before the current administration?

I've been very clear that I'm a layman, such as certainly most of the commenters here. I qualified using "AFAIK" and I've heard this on different occasions by people who have actual experience in the field. You can find similar claims on this page, partly backed by links. For example, I too have heard about studies evidencing that gender differences are more stark in developed countries with well functioning social systems, where people are freeer to choose their profession based on personal interest rather than for example economic aspects.

Point taken. I do think that it can be challenging to be a rare female amongst males (it would probably be similar the other way around). But the biggest contributing factor for such behaviours is certainly the anonymity of online gaming.

I for one have said that sentence you're discussing a lot, and you'll just have to take my word that I'm far from being a fascist. I even draw conclusions from that sentence, but I'm trying hard to not draw any conclusions about specific members of any given sex.

I of course get where you're coming from, but don't you think it is intellectually dishonest to try and police certain "obviously true statements"? Isn't it similar to banning kitchen knifes because they can be used to kill? Doesn't it put under suspicion a lot of people who are simply following their intellectual curiosity?

I would argue that the ideas you seem to be advertising can lead to similar societal catastrophes as the ones you're trying to prevent from reoccurring.

For sure, the misguided idea that men and women are absolutely, 100% the same, and that any other outcome than some equal distribution between males and females means there must be mysoginy and patriarchy at work (which I don't say you're proclaiming directly), has lead to a lot of real problems in the past decades. And that includes aggressive propaganda against males in general, and against some actually valuable male virtues as well as female virtues, in some circles.

AFAIK there are differences established on many psychological axes that are more basic than "occupational choice", such as competitiveness, neuroticism, interest in things vs human relations, and others. I don't understand these deeply but you can research for yourself, so there is certainly no shortage of possible explanations based on those.

For all I know, being a male programmer myself, with a significant proportion of females in all my programmer circles so far, I can attest the exact opposite. Every one of those circles has been welcoming and inclusive.

He wrote this whole game in it. Apart from that, a couple dozen or hundreds of beta-testers. Not sure whether the language ever gets released, maybe he's too worried about having to maintain it and not being able to change it anymore.

I'm not at all about decomposition and encapsulation. But I do think that the idea of _hierarchical_ decomposition can easily be overdone. The hierarchy idea might be what leads to building "on top" of leaky abstractions.

Is the opposite explained? I haven't read literature on the topic, and I'm by the way also somewhat of a sceptic of science on such topics, as a layman. But it seems super obvious that girls/women on average are not wanting to spend their teenage years in the basement programming geek stuff, like many boys/men do. In my experience, here in Germany, and you can probably extrapolate to the West in general, it's not like girls aren't encouraged to pursue programming or science. Men are, on average, just more willing to put in the hours of social neglect in order to become good at such things as programming, or also gaming, or whatever other fringe unsocial hobby. A big part of that is probably competitiveness, but also I believe there are more loners among men. Again, this is not scientific, just personal observations, also ideas I've picked up that I can agree with. I'm not even saying that it must be mostly for biological reasons (though I assume it is), just that there is a deeper reason for fewer girls to exist in tech than just "there is patriarchy and power structures and misogynist gatekeeping and shit".

Never forget that the social neglect is not exactly healthy, and programming isn't actually that prestigious and externally rewarding, except for maybe the compensation that you can currently earn in some places.

Adding that for example in math or other sciences, we are much closer to gender parity.

It might be the _logically_ correct interpretation that these are separate things. Now let's talk about rhetorics. Why are two unrelated, heavy accusations combined in a single sentence? Then consider that the added accusation (misogynist) doesn't hold water even on a logical level (let alone the bad faith involved here), it is a crass misreading of the evidence that was brought up for it.

Not scrutinizing Blow's words. One must be extremely careful when calling anyone fascist or similar labels. The burden of proof is on the accuser, not on the accused. It's obviously right to demand precision from the accuser, and to interpret whatever the accused said in good faith.

My apologies, not trying to fight here, and I acknowledge you've been more balanced and nuanced in other comments.

Don't be silly, it's brought up as a support clause that is also lacking any factual evidence.

It's _obviously_ reductionist and biased, not losing any more words on that.

I quote:

> Blow is a full-bore fascist sympathizer who also doesn't seem to think that women have any role to play in his profession.

The latter part being argued with a post where he merely opines that the sexes have different interests.

That's an extremely biased presentation of things on both sides.

The therm "fascist" is definitely being thrown around like it was nothing, for the most unnewsworthy opinions or statements. There are definitely people who call anyone fascist who would dare to claim that there might be differences between the sexes on average for example. Doing so probably has a fascist element itself (not accepting different opinions). It's also unreasonable, and let me say _ridiculous_, to even doubt that there are certain differences. To be clear, it's of course not right to make any prescriptions what any specific member of a sex should or could do -- but that's a completely different thing.

I would be very surprised if this connotation was intentional of him. His name was "Naysayer88" for a long time, and I had wondered as well where that 88 came from -- maybe it was a rhyme on "Naysayer", which (ignoring the number) is an apt description of his ways and approaches. At some point he changed the name. I assumed the reason was he had gotten aware of the connotation.

I think your general idea is right, it sounds reasonable that the insane cancelation mania can bring some conservatives to dig into deeper holes. It is probably what enabled the recent right shift in politics. As to Blow specifically, I've watched his streams quite a bit. I've always had sympathy for him and have been able to relate to his opinions a lot (about software in particular). But I can see how some other people could take offense from the way he's presented his stances.

I say that as someone who once made him angry myself when I live-commented in one of his streams because I had a rare disagreement. I was maybe not in shock but at least startled by his reaction. I had presented my disagreement relatively casually.

Now, my impression is that he's tuned down his considerably and developed a more well meaning stance on things over the years. Recently I've found him more on the side of "here's how most people are doing this, I don't like this, maybe I don't think it's sustainable or how you get good results, but anyway here's what I like to do instead, make of it what you want".

That's the same thing as happened to James Damore, who is, in my view, a harmless guy (even nice) and whoever cancelled him or is unable to acknowledge he had a point is much closer to fascism. I don't like throwing that term but just to return it.

It _boggles_ my mind that someone might find it controversial that there are on average differences between the sexes in terms of behaviour and interests. And to throw extremely strong accusations like "fascist" for a totally reasonable assumption or observation like that, I don't have words for that, I think those people have been smoking too much pot.

I haven't played any of these games, but "explains otherwise" seems to be a misrepresentation given that the commenter you linked is saying himself that Blow's game combines ideas and rulesets from several other previous games.

Elsewhere in the arstechnica comments you linked

> But, uh... this isn't a "Linus Torvalds is a jerk" sort of situation. "Controversial" undersells just how outlandish and inappropriate Blow's views are. Blow is a full-bore fascist sympathizer who also doesn't seem to think that women have any role to play in his profession.

What's going on on these platforms? Is there any serious evidence to the strong claims?

> I'm really liking your writing style by the way, do you have a blog or something?

Thank you! I don't get to hear that often. I have to say I was almost going to delete that above comment because it's too long, the structure and build up is less than clear, there are a lot of "just" words in it and I couldn't edit anymore. I do invest a lot of time trying to write comments that make sense, but have never seen myself as a clear thinker or a good writer. To answer your question, earlier attempts to start a blog didn't go anywhere really... Your comment is encouraging though, so thanks again!

I think I agree with your "buy-in idea", but adding that the Unix filesystem abstraction is almost as minimal as it gets, at least I'm not aware of a simpler approach in existence. Maybe subtract a couple small details that might have turned out as not optimal or useful. You can also in fact write a string to an offset on an SSD (open e.g. /dev/sda), you only need the necessary privileges (like for a file in a filesystem hierarchy too btw).

A database would not work as mostly unstructured storage for uncoordinated processes. Databases are quite opinionated and require global maintenance and control, while filesystems are less obtrusive, they implement the idea of resource multiplexing using a hierarchy of names/paths. The hierarchy lets unrelated processes mostly coexist peacefully, while also allowing cooperation very easily. It's not perfect, it has some semantically awkward corner cases, but if all you need is multiplexing a set of byte-ranges onto a physical disk, then filesystems are a quite minimal and successful abstraction.

Regarding STL containers, I think they're useful and useable after a little bit of practice. They allow you to get something up and running quickly. But they're not without drawbacks and at some point it can definitely be worthwhile to implement custom versions that are more straightforward, more performant (avoiding allocation for example), have better debug performance, have less line noise in their error messages, and so on. The most important containers in the STL are quite easy to implement custom versions with fewer bells and whistles for. Maybe with the exception of map/red-black tree which is not that easy to implement and sometimes the right thing to use.

> Could you please expand upon your idea that [..] a hierarchical structure of "blackboxes" [...] is bad?

You'll notice yourself when you try to actually apply this idea in practice. But a possible analogy is: How many tall buildings are around your place, what was their cost, how groundbreaking are they? Chances are, most buildings around you are quite low. Low buildings have a higher overhead in space cost, so especially in denser cities, there is a force to make buildings with more levels.

But after some levels, there are diminishing returns from going even higher, compared to just creating an additional building of the same size. And overhead is increasing. Higher up levels are more costly to construct, and they require a better foundation. We can see that most higher buildings are quite boring: how to construct them is well-understood, there isn't much novelty. There just aren't that many types of buildings that have all these properties: 1) tall/many levels 2) low overall cost of creation and maintenance 3) practical 4) novel.

With software components it's similar. There are a couple of ideas that work well enough such that you can stack them on top of each other (say, CPU code on top of CPUs on top of silicon, userspace I/O on top of filesystems on top of hard drives, TCP sockets on top of network adapters...) which allows you to make things that are well enough understand and robust enough and it's really economical to scale out on top of them.

But also, there isn't much novelty in these abstractions. Don't underestimate the cost in creating a new CPU or a new OS, or new software components, and maintaining them!

When you create your own software abstractions, those just aren't going to be that useful, they are not going to be rock-solid and well tested. They aren't even going to be that stable -- soon a stakeholder might change requirements and you will have to change that component.

So, in software development, it's not like you come up with rock-solid abstractions and combine 5 of those to create something new that solves all your business needs and is understandable and maintainable. The opposite is the case. The general, pre-made things don't quite fit your specific problem. Their intention was not focused to a specific goal. The more of them you combine, the less the solution fits and the less understandable it is and the more junk it contains. Also, combining is not free. You have to add a _lot_ of glue to even make it barely work. The glue itself is a liability.

But OOP, as I take it, is exactly that idea. That you're creating lots of perfect objects with a clear and defined purpose, and a perfect implementation. And you combine them to implement the functional requirements, even though each individual component knows only a small part of them, and is ideally reusable in your next project!

And this idea doesn't work out in practice. When trying to do it that way, we only pretend to abstract, we just pretend to reuse, and in the process we add a lot of unnecessary junk (each object/class has a tendency to be individually perfected and to be extended, often for imaginary requirements). And we add lots of glue and adapters, so the objects can even work together. All this junk makes everything harder and more costly to create.

> structure things as a loosely coupled set of smaller components

Don't build on top of shoddy abstractions. Understand what you _have_ to depend on, and understand the limitations of that. Build as "flat" as possible i.e. don't depend on things you don't understand.

Yup, it's quite rare that ADTs (or Rust enums) are so clear cut and obvious.

The idea that the data model looks like

   enum XYZ {
      case A(B, C, D, E);
      case F(G, H, I, J, K);
      case L();
      case M(N, O);
   }

is just not true in practice.

I think messaging is one case where it can happen, but even there it's often good to combine fields and share them (and common code) over multiple types of messages. If Messages A and B both have a field "creationTime" or whatever (with identical semantics), it's probably a bad idea to model them as separate fields, because that leads to code duplication, which is unmaintainable.

Maybe I can be more precise by proclaiming that ADTs can be good to be clear what's "there", so they can be used to "send" information. But to write any useful usage code, typically a different representation that folds common things into common places is needed. And it might just happen that field F is valid in cases A and B but not C. That's life! Reality is not a tree but a graph.

That's why it's a bad idea to try and model the exact set of possible states and rule out everything else completely in the type system. Even the most complicated type systems can only deal with the simple cases, and will fail and make a horrible mess at the more complicated ones.

So I'm saying, there is value to preventing some misuse and preventing invalid states, but it comes at a cost that one has to understand. As so often, it's all about moderation. One should avoid fancy type system things in general because those create dependency chains throughout the codebase. Data, and consequently data types (including function signatures) is visible at the intersection of modules, so that's why it's so easy to create unmaintainable messes by relying on type systems too much. When it's possible to make a usable API with simple types (almost always), that's what you should do.

It always depends on the definition of OOP. Typical enterprise OOP is grounded of the idea of creating black boxes that you can't misuse. That creates silos that are hard to understand externally (and often internally as well, because their implementation tends to be composed of smaller black box objects). That practice may prevent some misuse but it creates a lot of problems globally because nobody understands what's happening anymore on the global scale. This leads to inefficiencies, both performance wise as well as development wise. Even with some understanding, there is typically so much boilerplate that changing things around becomes extremely tedious.

Actually, I have some similar concerns about powerful type systems in general -- not just OOP. Obsessing about expression and enforcement of invariants on the small scale can make it hard to make changes, and to make improvements on the large scale.

Instead of creating towers of abstraction, what can work better often is to try and structure things as a loosely coupled set of smaller components -- bungalows when possible. Interaction points should be limited. There is little point in building up abstraction to prevent every possible misuse, when dependencies are kept in check, so module 15 is only used by 11 and 24. The callers can easily be checked when making changes to 15.

But yeah -- I tend to agree with GP that immutability is a big one. Writing things once, and making copies to avoid ownership problems (deleting an object is mutation too), that prevents a lot of bugs. And there are so many more ways to realize things with immutable objects than people knew some time ago. The typical OOP codebase from the 90s and 00s is chock-full with unnecessary mutation.