jstimpfle

Point is that C isn't tied to POSIX. It's just not. Of course there are apps created on e.g. Linux, those sometimes get ported by relying on standardized "POSIX" platform. But that's not how you have to program, and it isn't a great way to program. And it isn't a sufficient platform to do anything useful.

If id Software is any indication, apparently they wrote their games in C since their inception in 1990 with Commander Keen.

I don't know about you but I need zero POSIX to write C on Windows. Not even much of the (mostly bad) C standard library. I use snprintf for convenience (but I don't have to), and memcpy, that's about it.

And many projects properly abstract their OS layer so they aren't tied to POSIX.

Maybe Unix is tied to C, but C isn't tied to Unix.

I don't even have to search. Given the frequency of you repeating the same old tired stories, one is bound to stumble over your comments every other day.

There is plenty history of you repeating the same strawmans literally thousands of times. I've just never seen _anyone_ on HN (or elsewhere for that matter) make such claims?

You repeating this weird strawman take a million times doesn't make it true. Why don't you finally just put out some genuinely interesting projects demonstrating how everybody was doing it wrong, so people can make up their own mind and finally be convinced. There must be some true magic in those languages and platforms you mention, that should offset the pain of writing in upper case and with super long KEYWORDs everywhere, and to offset the cost of switching to a culture that has way less mindshare and way less of a software ecosystem around it.

FWIW I've actually worked for 6 months on a large old Delphi project. It was some performance work that, as almost always, mainly required getting the language crap out of the way. In the end I got the job done (100x-1000x speedup) but I wouldn't want to switch back to this ecosystem: Licensing costs, weird language warts there too. A slow moving ecosystem. Ultimately, I just need something that does what I tell it to do, reliably and fast, and that doesn't get in the way.

For the most part, software does not exist in a vacuum. If there is a serious bug, or much improved feature, in a library you depend on, what do you do? Most likely you'll try to upgrade the library. Same deal for the compiler, it's a huge dependency.

If your project is truly done, by all means ship it on a N64 cartridge. I can't say I don't have sympathy for that attitude. But don't expect this is how the world works today. And don't forget, N64 cartridges weren't built using massive amounts of dependency, so it was easier to confidently declare something "done".

I believe there are many top level chess masters that consider chess an art. Same for programmers, to many of the best, it is an art form or at least a craft that they take very seriously. And many would disagree that programming is solved. "Boring and standard" can be a sign of quality, but it also applies to those code bases that don't solve any interesting problems and just drown in boilerplate, kept alive by dozens or hundreds of programmer drones just working to collect their paychecks.

Good to point out the difference between taxes and other tariffs, but I have a hard time understanding why you have to call what I said "wrong"? What you went to explain in detail is exactly what I alluded to, that also matches the previous posters "electricity [...] taxed into oblivion".

Another point: 3.3% of federal tax income, or 1.7% of all taxes paid by citizens, goes directly into "Klima- und Transformationsfonds" i.e. gets pumped into energy transformation. And the state even pumps more money into that, by means of "Sondervermögen" (taking additional debts). Measured as a percentage of federal state tax income, seems like Germany is pumping more than 7% total into energy transformation. Quite a lot I think, and even if this is not directly a tariff on electricity, it's easy to imagine how this can result in general price inflation.

The prices of so many things have gone down with times due to increased efficiencies. Why not electricity? If solar PV is cheaper than fossils, I would, naive as I am, expect prices to go down.

(I acknowledge fossils have been going up for various reasons, and have become more scarce, and energy demands are rising)

FTR and for the inevitable downvoters, I am not a fan of fossil energy. I am merely a fan of well presented arguments, and downvotes aren't that.

What I am saying is that those spot prices may not represent all of the reneweables' marginal costs. Question is, will the end consumer prices ever go down, and by how much?

I was under the impression that the taxes are going into infrastructure and grants for renewable energies, meaning those energy prices are maybe way higher than advertised. Funny thing is we are constantly being told how cheap reneweables are to produce but apparently there are other costs involved.

Why I said not only... but also.

This is interesting, but now explain why Germany has both the highest electricity prices in Europe as well as a relatively high CO2 footprint from electricity? Germany is buying not only nuclear but also coal energy from neighbouring countries.

Will this be fixed at some point or is the German model not actually as good as you imply?

Not following Omarchy, not even sure what it is trying to be compared to existing distros (other than an incredibly hyped up product). Not hating on DHH. But hasn't he become famous for developing a web framework (20 years ago), rather than for his technical prowess as a systems-level engineer? Seeing these kinds of bugs is not exactly unexpected.

I actually explained well enough why this requires to a large degree a competent developer to judge.

Good, you achieved a 10% speedup for a particular workload that some users said they care about. But how do you find out that was really the feature that should have been built next? How do you prevent adding badly factored code? How to make sure you don't pile on top of existing tech debt in the codebase, that you are solving the most fundamental issues first?

How do you measure them if you don't understand what you're doing? A shitty benchmark or small test suite is not how solid software gets made.

What are you talking about?

How do you judge "better" if you don't understand the LLM output?

Yes -- I can see good use for runtimes. For example, compiler can autogenerate good runtime error messages. Thinking about it, debuggers make use of reflection. Debuginfo formats have some kind of reflection built in.

Reflection is a joke. De/serializing arbitrary C++ structs is ill-defined. When you need serialization, even lots of it (e.g. silly JSON), I think you're better off writing your own framework where you can be clear about data formats and transformation rules.

I challenge you to find one random person making that claim and to present it with a straight face. What kind of ghosts are you fighting?

Who uses Ada95 or whatever? You are fighting strawmans, nobody has made the claims you imply. My personal opinion is just that low-level access is essential to make interesting and performant programs. Object-type fluff doesn't help with that, it's getting in the way.

Casting integers to pointers is implementation-defined as far as I know. Even if weren't, I'm not convinced that you have to interpret C's address space as flat just because it is finite or because pointers are representable as integers. In any case, machine's address spaces are flat (the physical memory mapped into them not so much), and working with real machines is what I'm interested in.

Mind you, the "you can use this other way as you see fit" idea often isn't practical (like combining GC'ed and non-GC'ed parts). You generally want a whole codebase to be structured according to shared idioms. Otherwise the interfacing cost becomes too high.

I have doubts that you can program easily in a C-style way in C# without adding lots of annotations everywhere in many places. But don't know, maybe I'm wrong, I did a search for a simple C-style arena allocator in C#, and it looked acceptable, it was quite close. The most annoying thing was maybe keyword boilerplate.

It isn't actually that flat in the spec, though modern machines' address spaces are. So in a sense it is merely an accident of a specific implementation that you can smash stacks.

But I assume that both on compiler and on machine, the evaluation is still conforming to the semantics of the C abstract machine?

So do you want to "rewrite" some C code in C++ to think you made a point? I think you should do C# or Java.

What about you do xxHash? Should be quite basic, not a lot of complicated structures. https://github.com/Cyan4973/xxHash/blob/dev/xxhash.h

Or what about you do an audio or video codec? Or an operating system?

Not going to paste any of my own code, because any non-trivial stuff is hundreds to thousands of lines. But one more example (that I recently did myself): Create a block allocator (power of two blocks) with bookkeeping in shadow memory (administered in individually committed zones representing virtual memory regions of 64 MB (2^26)). Any used memory has bookkeeping support for being sub-allocated at any and all levels up from 64 KB (2^16) to 64 MB (2^26), and even higher (by joining committed regions). Individual blocks are collected (using intrinsic linking, because no memory allocation) in a hierarchy of pools of same-sized chunks that have the same parent, and can be recursively sub-allocated on any smaller chosen power-of-2 level, and finally be consumed in linear fashion (arenas). Blocks are pooled with a moderate retain policy (watermark system) to allow subsystems to almost completely avoid any system calls and avoid inter-thread synchronisation. The memory overhead must be below 1% even though it's totally flexible (as said has metadata for all levels from 64 KB up).

The bookkeeping should function on 32-bit systems (small virtual space, occupancy range from megabytes to 3 GB) as well 64-bit systems (2^48-2^57 bytes of virtual address space, occupancy range from megabytes to hundreds of gigabytes) with reasonable overhead compared to actual usage.

This requires intrusively linked lists, occupancy bitmasks, bit-counting and bit-prefix counting, OS syscall access (virtual memory), pointer arithmetic (alignment needed to address shadow bookkeeping memory) and thread synchronisation. The reference code is >> 95% pure ISO C++11 (could be C99 with few changes), with a little platform code glued in. It works on Windows but it could be ported to Linux in a few hours. It supports a mostly-immediate-mode GUI with hundreds of thousands (maybe millions?) of small variable-sized allocations per second. Allocation has almost completely disappeared from the CPU profile, well below 1% of CPU usage.