Hacker News: bluetomcat

LLM coding is the wrong layer of abstraction

bluetomcat — Fri, 03 Apr 2026 20:12:00 +0000

Article URL: https://bbuyukliev.blogspot.com/2026/04/llm-coding-is-wrong-layer-of-abstraction.html

Comments URL: https://news.ycombinator.com/item?id=47631617

Points: 3

# Comments: 1

New comment by bluetomcat in "LLM Doesn't Write Correct Code. It Writes Plausible Code"

bluetomcat — Sat, 07 Mar 2026 16:06:16 +0000

No. Plausible code is syntactically-correct BS disguised as a solution, hiding a countless amount of weird semantic behaviours, invariants and edge cases. It doesn't reflect a natural and common-sense thought process that a human may follow. It's a jumble of badly-joined patterns with no integral sense of how they fit together in the larger conceptual picture.

New comment by bluetomcat in "We automated everything except knowing what's going on"

bluetomcat — Tue, 03 Mar 2026 13:53:23 +0000

We went from expressing computation via formal, mostly non-ambiguous languages with strict grammar and semantics, to a fuzzy and flaky probabilistic system that tries to mimic code that was already written. What could go wrong?

Show HN: Shell script and text database for vintage Lego Pirates collections

bluetomcat — Tue, 10 Feb 2026 20:15:10 +0000

Article URL: https://github.com/bbu/classic-pirates.sh

Comments URL: https://news.ycombinator.com/item?id=46966164

Points: 3

# Comments: 0

New comment by bluetomcat in "The choice between Rust and C-derived languages is not only about memory safety"

bluetomcat — Sat, 13 Dec 2025 10:29:03 +0000

You are correct. The final output was polished by ChatGPT, but I originally presented the basic ideas in a few paragraphs. The LLM added a sense of flow and persuasiveness which are somehow lacking in my rather dry and non-native English writing style.

The choice between Rust and C-derived languages is not only about memory safety

bluetomcat — Fri, 12 Dec 2025 21:07:15 +0000

Article URL: https://bbuyukliev.blogspot.com/2025/12/the-choice-between-rust-and-c-derived.html

Comments URL: https://news.ycombinator.com/item?id=46248960

Points: 45

# Comments: 19

New comment by bluetomcat in "Show HN: Cdecl-dump - represent C declarations visually"

bluetomcat — Mon, 08 Dec 2025 02:32:04 +0000

It starts from the identifier. At every stage, it outputs a sub-expression which is the “mirrored use” and corresponds to the boxed representation below it. When it reaches the top of the expression, it prints the final type of the expression which is the lone specifier-qualifier list.

As per the screenshot, “arr” is an array of 4 elements. Consequently, “arr[0]” is an array of 8 elements. Then, “arr[0][0]” is a pointer. And so on, until we arrive at the specifier-qualifier list.

Show HN: Cdecl-dump - represent C declarations visually

bluetomcat — Mon, 08 Dec 2025 00:26:04 +0000

A small tool that parses C declarations and outputs a simple visual representation at each stage, as it encounters arrays, pointers or functions.

The program uses a table-driven lexer and a hand-written, shift-reduce parser. No external dependencies apart from the standard library.

Comments URL: https://news.ycombinator.com/item?id=46186917

Points: 35

# Comments: 13

New comment by bluetomcat in "Some software bloat is OK"

bluetomcat — Tue, 04 Nov 2025 10:52:00 +0000

And consequently, "you need 32GB of RAM just to be future-proof for the next 3 years".

From epoll to io_uring's Multishot Receives

bluetomcat — Tue, 28 Oct 2025 17:39:21 +0000

Article URL: https://codemia.io/blog/path/From-epoll-to-iourings-Multishot-Receives--Why-2025-Is-the-Year-We-Finally-Kill-the-Event-Loop

Comments URL: https://news.ycombinator.com/item?id=45736075

Points: 16

# Comments: 1

New comment by bluetomcat in "Love C, hate C: Web framework memory problems"

bluetomcat — Fri, 10 Oct 2025 08:59:06 +0000

Because in C, every allocation incurs a responsibility to track its lifetime and to know who will eventually free it. Copying and moving buffers is also prone to overflows, off-by-one errors, etc. The generic memory allocator is a smart but unpredictable complex beast that lives in your address space and can mess your CPU cache, can introduce undesired memory fragmentation, etc.

In Java, you don't care because the GC cleans after you and you don't usually care about millisecond-grade performance.

New comment by bluetomcat in "Love C, hate C: Web framework memory problems"

bluetomcat — Fri, 10 Oct 2025 07:31:49 +0000

Yes, you can do it with minimal allocations - provided that the source buffer is read-only or is mutable but is unused later directly by the caller. If the buffer is mutable, any un-escaping can be done in-place because the un-escaped string will always be shorter. All the substrings you want are already in the source buffer. You just need a growable array of pointer/length pairs to know where tokens start.

New comment by bluetomcat in "Love C, hate C: Web framework memory problems"

bluetomcat — Fri, 10 Oct 2025 06:36:09 +0000

Good C code will try to avoid allocations as much as possible in the first place. You absolutely don’t need to copy strings around when handling a request. You can read data from the socket in a fixed-size buffer, do all the processing in-place, and then process the next chunk in-place too. You get predictable performance and the thing will work like precise clockwork. Reading the entire thing just to copy the body of the request in another location makes no sense. Most of the “nice” javaesque XXXParser, XXXBuilder, XXXManager abstractions seen in “easier” languages make little sense in C. They obfuscate what really needs to happen in memory to solve a problem efficiently.

New comment by bluetomcat in "You didn't see it coming"

bluetomcat — Wed, 24 Sep 2025 11:20:12 +0000

> These lies don’t just affect them but also the people reading it as they might never see what actually happens

This is what sustains this whole economic bubble built on debt and future promises. At all levels of society, you have these inflated unrealistic expectations and BS circulating in the media. Technically-incompetent but eloquent and charismatic CEOs predict that in 6 months, some major technological shift will happen. Managers preach about adjusting their organisations to these new realities. Workers have no choice but to play the game with all its dirty tricks, if they want to stay employed. Anyone who dares to say that the emperor has no clothes is isolated in a dark corner because they may suddenly deflate the value of the whole economy. This is corporate feudalism disguised as a competitive economy.

New comment by bluetomcat in "GNU Midnight Commander"

bluetomcat — Wed, 17 Sep 2025 06:30:38 +0000

They were popular because there was no Unix culture in Eastern Europe at the time. Pretty much any computer geek was a DOS user. To me personally, it always seemed kind of lame because many of these people would not bother to properly learn the shell language.

New comment by bluetomcat in "Kernel-hack-drill and exploiting CVE-2024-50264 in the Linux kernel"

bluetomcat — Wed, 03 Sep 2025 11:53:05 +0000

Their English is sufficiently good. It's a cultural aspect regarding writing style. When Russians and most Eastern Europeans write about technical subjects, they tend to be concise, dense and straightforward. Americans, on the other hand, are over-expressive and tend to saturate their writing with pointless metaphors and rhetorical devices.

New comment by bluetomcat in "Undefined Behavior in C and C++ (2024)"

bluetomcat — Tue, 12 Aug 2025 12:11:23 +0000

> Pattern matching should make the language less verbose, not more.

In the most basic cases, yes. It can be used as a more polished switch statement.

It's the whole paradigm of "define an ad-hoc Enum here and there", encoding rigid semantic assumptions about a function's behaviour with ADTs, and pattern matching for control-flow. This feels like a very academic approach and modifying such code to alter its opinionated assumptions isn't funny.

New comment by bluetomcat in "Undefined Behavior in C and C++ (2024)"

bluetomcat — Tue, 12 Aug 2025 08:28:32 +0000

Rust encourages a rather different "high-level" programming style that doesn't suit the domains where C excels. Pattern matching, traits, annotations, generics and functional idioms make the language verbose and semantically-complex. When you follow their best practices, the code ends up more complex than it really needs to be.

C is a different kind of animal that encourages terseness and economy of expression. When you know what you are doing with C pointers, the compiler just doesn't get in the way.

New comment by bluetomcat in "Car has more than 1.2M km on it – and it's still going strong"

bluetomcat — Sat, 09 Aug 2025 14:37:25 +0000

The W210s did indeed rust badly and the interiors weren't on par with previous generations, but in purely mechanical terms, they were still solid cars. The diesels (particularly E250 TD and E290 TD) could cover 700k+ kilometres without any interventions to the engine or the transmission. The W211 is an improvement to the W210 in almost every aspect, and they are still plentiful on the roads in Eastern Europe.

New comment by bluetomcat in "C++: "model of the hardware" vs. "model of the compiler" (2018)"

bluetomcat — Mon, 04 Aug 2025 08:07:53 +0000

What a mess of an article. A pretentious mishmash of scattered references with some vague abstract claims that could be summarised in one paragraph.