jkercher

Obligatory "package managers are evil:"

https://www.gingerbill.org/article/2025/09/08/package-manage...

Okay smarty-pants. What if I want a generic map then ;)

Yes and no. If you want to make something like a generic dynamic array, you can do it with type erasure (`void*`), but then your code is no longer typesafe. I would find that more fragile. The preprocessor allows you to add constructs that make it behave like any other modern language.

As an aside, clangd can dereference a macro in place to make debugging easy.

Please tell me this is sarcasm...

I think you nailed it. And that would make sense and should be expected. 99.9% of the world's software (the training data) is several orders of magnitude away from max performance.

Another possible confusing thing for an LLM is that getting close to max doesn't necessarily require any "tricks." A big part of getting in the ballpark is just not doing anything you don't have to. If program A is faster than program B, most of the time is not some magic algorithm. It's that program A just did less stuff.

I don't know man. It's just zero. Dereferencing it just crashes your program (assuming an operating system). This kind of just reads like a fear of pointers. Corrupted/out-of-range pointers are, at least, a real problem.

Meh, I think NULL is fine in C. It's an extra, valid state to represent pointers at no cost. Unlike the more hand holdy languages, it's quite rare for a pointer in C to have the ability to be NULL since, more often than not, it's pointing at something known. It's actually quite rare to see NULL checks unless it's API code or something like that. I can see this being more of a problem in a managed language where anything can be NULL at any time.

Ha. I'm probably in the more anti AI camp, but if it could free us from the plague that is Python thinking, I might change my tune. 2 seconds might feel negligible in the real world, but it is damn near an eternity in the supercomputers we're all running.

Sam?

You make that sound worse than it is. On the overall topic, you have 0 supply chain risk, and the whole thing is local. Also, your code from 2009 is still valid. That would be a foreign concept in some languages like Python.

I too have used a similar strategy of packing variables together. I even came up with a name for it. I called it a "building."

Tangentially related. Don't ever put "." in your PATH. I used to do this to avoid typing the "./" to execute something in my current directory. BAD IDEA. It can turn a typo into a fork bomb. I took down a production server trying to save typing two characters.

One of the advantages to the pointer + length approach is free substrings. This inline approach doesn't allow that.

Couldn't agree more. I have a project at work from 2016 that builds multiple different HMIs (C++) along with 2 embedded systems (C). They all have to play nicely with each other as they share some structures and can all be updated in the field with a single file on a USB stick. So there is a bash script that builds everything from a fresh clone, makes update files, and some other niceties. Then, there is a single python script that generates a handful of tables from a json file.

Guess which part of the build I spent fixing the other day... It wasn't the ~200000 lines of c/c++ or the 1000+ line bash script. No. It was 100 lines of python that was last touched 2 years years ago. Python really doesn't work as a scripting language.

I certainly would not use it prescriptively as I said originally. I wouldn't use any poker book prescriptively. You make your own style and pull pieces from others just like any other trade. I like the way Joe does X.. I like the way Jane does Y.. I have my own way to do Z. That becomes my style.

There are nuggets of wisdom in every poker book I've read even if I disagree with some parts or some are just flat out wrong. Super System, in particular, provided insights into the mind of one of the greatest player of all time. I particularly liked the psychological view on things. If nothing else, it provides context for the ones that came before you. Its been 15+ years since I read it, but beyond the fundamentals, I recall picking up (hopefully not misattributing anything here)...

- a quick, in-your-head method of calculating odds based on outs

- psychology of playing runs and others perceptions of you at the table

- the pitfalls of playing AA

- a realistic look at "tells"

- the general psychology of aggression

- how/where tight players make money and how/where aggressive players make money

Super System is the seminal book of poker. It is the book that your opponents are most likely to have read. As I alluded in my original comment, you wouldn't want to be the only person at the table who doesn't recognize someone playing the super system to the letter. IIRC, the goal was to make the player just appear lucky. It was meant to be confusing. It's like reading K&R as a C programmer. Sure, some of the information might not hold up today, but it provides a lot of context.

I don't think so. I don't play nearly as often as I used to, but I still do alright. Though, I usually play tournaments where "game theory optimal" can only get you so far. There is a lot more nuance in a tournament where your style should change as it progresses.

Super System is old, but I wouldn't call it outdated. Definitely still worth a read. The more books you've read, the bigger your tool set. The key here is that it works in both directions because each style you learn, is a style you may recognize other players using. The pitfall of Super System, is by now, everyone's read it, and it's quite easily recognized:

- limp-shoving under the gun

- always trying to go on runs

- over playing suited connectors (JTs specifically)

But, you still get the advantage of being able to recognize it. There's lots of good wisdom in there that isn't as prescriptive either. Read as many books as you can. Poker is information warfare.

Rust and Zig are both perfectly fine languages. Odin wins on simplicity and familiarity for me. I'm most productive in C which is what I use at work. So, for me, it's a better C with some quality of life improvements. It's not trying to be too radical, so not much to learn. The result is that I move can fast in Odin, and it is legitimately fun.

When I first heard about Odin, I thought, why another C replacement?! What's wrong with rust or zig? Then, after looking into it, I had a very similar experience to the author. Someone made a language just for me! It's for people who prefer C over C++ (or write C with a C++ compiler). It has the things that a C programmer has to implement themselves like tagged unions, slices, dynamic arrays, maps, and custom allocators. While providing quality of life features like distinct typing, multiple return values, and generics. It just hits that sweet spot. Now, I'm spoiled.

What's naive?

I'm not looking for an argument, but my knee jerk reaction to seeing 4 or 5 different answers to the question of getting python to C... Why not just learn C?

clickhouse-local is pretty slick as well. You can operate directly on text files as if they were tables. I made my own toy text file database thing and thought I was cool because I could outrun similar programs like q, textql, sqlite, etc. But clickhouse-local had me by a factor of 10 easy in every kind of query with every type of data. Those guys know stuff.

I think he's saying the text should be more muted like the copyright at the bottom.

Cool. Let us software guys know when we get computers that are 1000x faster so we can write the next language/framework that is 1000x slower.

I think he is getting at this part "non-mass scale platform." He's implying it only protects the big players that can afford the change.