jstimpfle

13 ms·

91.
by jstimpfle 4mo ago
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.
92.
by jstimpfle 4mo ago
But why are there so many of them?
93.
by jstimpfle 4mo ago
> 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 obfus
94.
by jstimpfle 4mo ago
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
95.
by jstimpfle 4mo ago
> 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 J
96.
by jstimpfle 4mo ago
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 cre
97.
by jstimpfle 4mo ago
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,
98.
by jstimpfle 4mo ago
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 t
99.
by jstimpfle 4mo ago
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)
100.
by jstimpfle 4mo ago
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. I
101.
by jstimpfle 4mo ago
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,
102.
by jstimpfle 4mo ago
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 trill
103.
by jstimpfle 4mo ago
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 rel
104.
by jstimpfle 4mo ago
Yes, I am talking about a buffer for an outbound queue that should buffer on the order of MB/sec. That's decidedly not a niche thing. It's very basic systems engineering (and also how socket buffers are represented in a ker
105.
by jstimpfle 4mo ago
So reject as in assert? But how does that go together with what you said, "because now it's fine if it does"?
106.
by jstimpfle 4mo ago
The cast is at least 50% of why this is useful! You'll now get compile errors in case you did anything wrong.
107.
by jstimpfle 4mo ago
Are you talking about extending the API contract to allow for NULL? That is often the path to madness, especially if it requires complicating the signature (return value etc). Better to just assert/crash.
108.
by jstimpfle 4mo ago
You can try and do this if it's a relatively narrow public facing API, but otherwise this is a theoretic ideal. In practice, if you add an assertion for every pointer argument to every little function, you'll go insane, and it is
109.
by jstimpfle 4mo ago
May. If. If. If. In case. We are talking about an extremely simple straightforward API with an obvious contract. It's good enough for this function to reliably surface almost all wrong uses with a segfault immediately. Wrong use wil
110.
by jstimpfle 4mo ago
Thanks for letting me know, nitpick appreciated. Typing on my phone.
111.
by jstimpfle 4mo ago
A bug is a bug even when it doesn't clearly manifest itself 100% of the time, and furthermore it is pretty much guaranteed that NULL dereference crashes with segfault in practice, only not for the people playing theoretic games whose e
112.
by jstimpfle 4mo ago
> Nothing is sane in a language that lets you say 4["Foo!"] I just had a look at your HN profile page and was struck by the irony of seeing your Forth vs Lisp vs Postscript code examples there. Now consider that I've never
113.
by jstimpfle 4mo ago
I told him the same thing multiple times, just open a random code location in GCC, or a recently committed change, and see that it's basically C. But he keeps repeating that ridiculous argument like a broken record.
114.
by jstimpfle 4mo ago
I don't know the size up front because it goes up and down depending on load. I want to be able to buffer jitters/spikes but not hog memory when there is no data in the queue. I was assuming it's natural to want a simple link
115.
by jstimpfle 4mo ago
> The O(1) complexity looks good superficially Without knowing more about the details of the spec and of real world implementations [0], I'll boldly claim that the O(1) is the precise problem why this is a weird data structure (I ne
116.
by jstimpfle 4mo ago
looks like I was wrong, but here is the de-facto standard I was relying on over the years ;-). Not that I've memcpied many structs to file directly btw. http://www.catb.org/esr/structure-packing/
117.
by jstimpfle 4mo ago
sure, if you change the struct, it will now be different.
118.
by jstimpfle 4mo ago
It's totally true, using sizeof like a function is one of my pet peeves. Even the kernel people do it but it's WRONG and you are right. But ACSHUALLY, how you write allocation is like this #define sane_alloc(type, count) ((t
119.
by jstimpfle 4mo ago
struct layout is well specified, it should be possible to avoid any padding issues by just aligning and by padding (with dummy members) correctly. The problem in practice is mostly integer representation (big-endian vs little-endian).
120.
by jstimpfle 4mo ago
> was already what you were paying by using the amortized O(1) growable array type As I said, I don't think growable array data structure is a good idea. > Basically std::deque. Surely no more need be said ? Ok now you're re

More ›