jstimpfle · HackerLangs

If you use a JSON parser, URL parser, configuration file parser, async framework, and so on, maybe you have other problems. Not that I don't know these project or don't have to work on them, but I don't think it matters what JSON library or URL parser library or async framework you're using.

The actual problem is the complexity coming from the choice to use these things at all (and thinking they should play any important role in the system at all, instead of being entirely replaceable), which means to do anything useful you have to go through a lot of abstraction, which makes everything tedious and buggy and hard to fix.

jstimpfle

14 日前議論

> You do the endianness conversion

Exactly my point.

jstimpfle

15 日前議論

You may have never done socket programming, or do you use wrapper libs in Zig? Because you have to send the kernel big endian port numbers for example.

What do you do if you program a kernel in Zig, or just generally do low level networking?

My point is to refute the statement that everyone has agreed to little endian, and so there aren't use cases to want to do conversion. Programs do not exist in a vacuum, most programs do not.

jstimpfle

15 日前議論

Does that mean there are no file formats thatbuse big endian? And network byte order isn't a thing?

jstimpfle

17 日前議論

It's not as black and white as you claim. 99% is obviously much better than 0%, and 99.999% would be an exceptional, unheard-of improvement. In most software projects, this would find ALL bugs.

And most "memory safe" languages are not all that memory safe. Or they need escape hooks.

EDIT: To be clear it's not AT ALL black and white. You have drunken too much of the type safety kool-aid.

jstimpfle

17 日前議論

It might just mean the opposite. Unergonomic and/or slow memory safe languages might not be needed anymore at some point, because LLM can check for reasonable programming patterns and can do some amount of vulnerability checking upfront. But seriously the first point -- as long as you keep to a known set of reasonable patterns (much larger set than the sets accepted by restrictive and cumbersome type systems), memory unsafe languages are actually pretty safe, and the code remains easy to understand, easy to maintain, and performant.

Already today, in my experience, widespread models like Claude 4.6 or 4.8 can quite reliably find some concurrency bugs that are easily missed by humans.

jstimpfle

19 日前議論

This is one of the articles where I'm immediately grateful to the author to have written it down. Very good and easy to pick up point, actionable advice. I would just slightly modify it, don't create a time bomb. "I would like to... until date XY" should achieve the same effect -- not inviting bikeshedding or delaying action, sending "I got this" -- without pressurising anyone else for taking a decision or too much responsibility.

jstimpfle

20 日前議論

Code duplication is the wrong abstraction too -- unless it's not really code duplication but code that only happens to be similar for some really "unstable" reason.

jstimpfle

22 日前議論

But why are there so many of them?

jstimpfle

22 日前議論

> There’s nothing wrong with having non-normalized representations

There is a lot wrong with that: complexity, bloat, and slowness.

> But now client code can distinguish 2/3 from 4/6 using ==

That's a great way to obfuscate code. Not a good idea. The right way to do the comparison is, just make a function called CompareRational().

jstimpfle

22 日前議論

OOP isn't just about values vs objects. Yes, the idea that everything needs identity is a big part of the problem. But another big problem is the idea that the implementation and representation of types should be hidden by default. The mindset that there isn't a known and useful data representation for a given type. That everything is done by methods parameterized by a type. It's a misguided idea. There is a place for objects and implementation hiding. But the idea that this should be done on a type granularity is a complete and utter failure.

To see why, consider that to do any useful work, data from different objects (also from different types) has to be combined. To be able to do that in the OOP framework, the encapsulation has to be unwrapped. That's why Java code is littered with getters and setters that don't do any useful work at all, they just make it too painful to get any real work done.

Again, there is a place for objects and implementation hiding, but it's at the highest levels of an architecture where different components get integrated.

jstimpfle

23 日前議論

> your "platform" is also typically a framework, like QT or AppKit or whatever you end up using

That's not what I consider "low level programming". I don't use any of these.

Yes you can do try and do plain Javascript. Honestly Javascript is a much less pleasurable environment than a compiled statically typed procedural language. The main advantage of the browser is you get a viewport, you get font rendering etc. with almost no setup required at all.

jstimpfle

23 日前議論

It's not so much about the browser (I'm not aware of major incompatibilities introduced by new browsers or new W3C standards). But the software ecosytems (like frameworks, or node.js) that web people are relying on in order to create their web apps.

jstimpfle

23 日前議論

This is how I mean it: In case of low level programming, the "platform" is the hardware/OS/compiler. In case of web programming, the "platform" is the web framework.

If you update the OS, hardware, or compiler, you will see only few changes. If you update the web framework, you may see breakages, API deprecations or whatever. You may want to move to a different web framework entirely. TBH I don't really know, I don't know web programming beyond basic HTML/Javascript. That's what they say, though.

jstimpfle

23 日前議論

Depends on what you mean by low level I guess. Compared to web application framework churn rate, simple procedural programming without many dependencies is remarkably stable. You tend to program in a way that works for most platforms (all targetted platforms). How to best do that you learn over the years. To me personally it's very refreshing if the environment around you does not constantly change. That affords learning a bag of tricks and a list of gotchas to avoid.

jstimpfle

24 日前議論

I thought so, too, at some point, and I put it to practice, actually did that for a long time. (I'm not _that_ much of a talker, I can back up what I'm saying with real experience having erred on the opposite side for a long time).

I thought so too, for many other things, and did so too in practice. Then I was doing thousands of little tasks in order to improve "security" and "correctness" and "proving everything", and never got to actually do anything useful, and my code became bloated to the point it didn't get to do much useful work.

Now I'm more considerate, trying to weigh everything in the larger context, is it REALLY required to get my job done?

jstimpfle

24 日前議論

So if I understand correctly now, you _do_ proclaim to put asserts, not write code that somehow copes with the "possiblity" of NULL.

"Because no one is expecting it to work if a null is passed", so you can do whatever. If you write an assert for every pointer passed to every function, that will be a lot of asserts, for pretty much the same outcome in practice. Asserts are just marginally more ergonomic when they trigger, but are a nuisance in the code often. So my position is to use them judiciously, but not overdo it, be instead focused on the actual task.

When the lack of non-null assertions is an actual problem during development, you have much larger structural issues.

jstimpfle

24 日前議論

Please, go ahead and type the example. I think you are trolling.

> Define a command algebra in which the "ok" syscalls are a subtype

Dude, it's clear you're not doing any actual work. You are living in an ivory tower, and you underestimate the complexity and detail and volatility of real world applications by at least 3 orders of magnitude. You don't understand how to modularize and contain complexity.

You _cannot_ complete a project with this attitude.

You are ignorant of the fact that a type system is necessarily a blunt simplification of the real complexity. Therefore, use of types must be pragmatic, and actual logic must be coded in normal code (which should be obvious but it isn't to type theory weirdos). Otherwise, you require dependent typing or whatever, and you will have to write your code twice, once in a usable programming language and once in a very unusable programming language. Much more than only twice actually, given that all the implicit detail should apprently go explicitly formalized at the type level.

Just to make sure I'm not entirely talking out of my arse because I'm so incredibly annoyed by your otherworldly proposition, I asked an AI about the sel4 microkernel. It consists of 10,000 lines of C code (that says a lot about its practical utility, which is very limited), and of 1,3 million lines of manually written proof code (which says a lot about the practicality of proving).

jstimpfle

24 日前議論

If you follow that line of reasoning, you will end up testing almost every pointer before accessing it. The reason is that you are extending your valid state space massively since you aren't able to specify "this subset of 7 trillion distinct states is invalid, if it was the case we would have failed before".

You are requiring yourself to find a valid outcome for an input that doesn't make _any_ sense in the context of what your application is meant to achieve. How is that not a Sysiphean task?

jstimpfle

24 日前議論

Typical invariant for me would look like:

Given a, b, c input parameters to my func, it must hold that that a->m->t == b->t. c->mutex must be held, and c->cond is the condition variable that goes with c->mutex and will release any waiters on the buffer contained in a.

Or: Integer x is representable using 12 bits only, Integer y should be a multiple of N and I have a integer s is used as a bit-shift that should be less than 8.

Or: I need to guarantee that no locks have to be taken and no allocations have to be made on this complicated looking codepath. While holding a lock, we must not do any syscalls (syscall a, b, c are ok though), and surely not make any logging calls.

I know only one system that can express this, it's called STRAIGHTFORWARD CODE, and it requires doing engineering and casual logic out-of-band, and yes it does include making mistakes and repairing them incrementally.

I don't know a type system that would let me explain these things to me and tell me where I was wrong. But maybe you can show me, with 5 minutes of actually trying?

コメント