jeremycw

It omits that the prisoners are deceased and uses the term "vanish" which implies it's not known where the organs have gone.

"Alabama prisoners' organs vanish, and there's a whole lot of passing the buck" could easily be "Deceased prisoners' organs taken by University of Alabama against families wishes" but that's not going to get the clicks.

The overhead of cgo seems like it would not be an issue if you could pass in an array of vectors and moved the outer loop into the procedure instead of calling the procedure for each vector. This may only be viable if there is a low overhead way to pass arrays back and forth between go and C. I'm no expert but a quick google makes me think this is possible.

I get that hand rolling assembly is fun but as a theoretical future maintainer I would much prefer C to ASM.

https://github.com/ir33k/gmi100/blob/master/gmi100.c#L27 definitely threw me for a loop until I realized it was a line saving trick. It would be more readable to save lines elsewhere by exploiting the comma operator instead of essentially cramming irrelevant statements into a conditional.

For example:

  addr.sin_family = AF_INET;
  addr.sin_port = htons(1965);

Could become:

  addr.sin_family = AF_INET, addr.sin_port = htons(1965);

I am not a lawyer and please correct me if I'm wrong but as I understand it rules and mechanics are not copyrightable. What is copyrightable is the flavor text and specific compilation of the rule set into the "Rule Book". The rule book becomes a copyrightable work. This means that your are within your legal right to make a game called "Dragons & Daggers" where all the combat mechanics, rules, etc are identical to Dungeons & Dragons as long as the "glue" text and flavour text is original content. It seems to me like a community fork licensed under CC that plays exactly the same is not impossible.

I think you need to be a bit more humble on a topic that's clearly going over your head.

Imagine a scenario where you are testing out a brand new RISC-V development board. The vendor has only provided a C compiler for this board as is often the case. You want to be able to use the zig language to write programs for your new development board but no zig compiler exists for this board yet. That means you need to compile the zig compiler from source. The latest version of the zig compiler is written in zig. Again you don't have a zig compiler so how will you compile the zig compiler from source? You need a way to go from C compiler to Zig compiler. That's what this is describing. It does not make sense to maintain two completely separate versions of the compiler. The "real" one written in Zig and the "bootstrap" one for compiling from C. So the zig source is compiled into WASM and stored in the repo. On a system with only a C compiler this WASM can be ran instead of a native zig binary. The WASM version can then be used to compile an actual native zig binary.

I wonder if it's possible this was an optical illusion. Seeing optical illusions where oil tankers are hovering in mid-air has changed my perception of what people could see and how it could be misinterpreted. [1] I'm not a physicist but it almost looks like the photo could be a mountain and it's reflection somehow projected up into the sky similar to how the oil tanker is projected in the sky.

[1] https://www.bbc.com/news/uk-england-cornwall-56286719

I've seen a few large Rails codebases that included a state machine library like mentioned in the article. Every single one was worse because of it. It pushes the code down a path where hidden hooks run when magic methods are called. At this point in my career I'm just done with that type of "clever" code.

The article starts with examples that just define the state machine by hand. This is a much better approach and scales to larger code much better. You can grep "def start!" and just read what the method does. A state machine DSL is really not providing much value and eventually just gets in the way.

The problem with these types of gems is that they're good for refactoring functional style code that takes an input and produces a result and has "few side effects" as they mention, but this is generally not the type of code you find in an old legacy rails application that you want to refactor. The whole thing that makes these refactors tricky is that they can just write to the db anywhere in a non obvious way.

If you naively go about refactoring something like:

POST /users

Thinking all you need to do is match the output of the current request and match the record it makes in the users table you're potentially missing a ton of side effects you didn't even know about.The problem has always been the side effects and until one of these gems can track and compare side effects in an intelligent way I don't see how they are that useful.

Sometimes I find it a little depressing that (at least through my laymen eyes) we are nearing a technological plateau and that more research into physics is unlikely to get us to a world describe in traditional science fiction with FTL drives and large metal spaceships that can take you from planet to planet.

Then something like this reminds me that if we as a species were able to unlock the secrets of bio-chemistry (not sure if that's the right term) it would be a game changer unlike any seen so far. And the fact that there is a huge corpus of evidence out there in the world called "life" proving some of the possibilities already gives me hope that while we may never have FTL, the future could still be pretty wild.

While stylistically I don't necessarily agree with him all the time, Casey Muratori's Handmade Hero (https://handmadehero.org/) is probably the most complete resource in terms of videos and access to source code as far as an 'example' goes.

You're right, when I mentioned "taxonomy, abstraction and world-modeling" I meant as it pertains to code organization in the tradition OOP/OOD sense where it's generally about naming classes, creating inheritance hierarchies, etc. Data-oriented design is _absolutely_ concerned with the data schema. I would, however, disagree that the focus should be on "building the world" with your schema. To me this means creating the schema based off of some gut/fuzzy feeling you get when the names of things all end up being real world nouns. To me creating a good schema is less about world building than it is about having the exact data that you need, well normalized and in a format that works well with the algorithm you want to apply to it.

> Doesn't the former enable the latter?

Not necessarily. ECS is a local maxima when developing a general purpose game engine. Since it's general purpose it can do nothing more than provide a lowest common denominator interface that can be used to make any game. If you are building a game from scratch why would you limit yourself to a lowest common denominator interface when there's no need? Just write the exact concrete code that needs to be there to solve the problem.

> Our job as engineers is to make software that functions according to some set of desires, and those desires may directly conflict with approaching an optimal transform.

All runtime desires of the software must be encoded in the transform. So no software functionality should get in the way of approaching the optimal transform. What does get in the way of approaching the optimal transform is code organization, architecture and abstraction that is non-essential to performing the transform.

I think the focus on ECS when talking about data-oriented design largely misses the point of what data-oriented design is all about. Focusing on a _code_ design pattern is the antithesis of _data_-oriented design. Data-oriented is about breaking away from the obsession with taxonomy, abstraction and world-modeling and moving towards the understanding that all software problems are data transformation problems.

It's that all games essentially (and most software in general) boil down to: transform(input, current_state) -> output, new_state

Then, for some finite set of platforms and hardware there will be an optimal transform to accomplish this and it is our job as engineers to make "the code" approach this optimal transform.

I use it when I need to be really productive on projects and tasks where there are a lot of little things to accomplish and lots of little details to keep track of. My procrastination kicks in when I finish a task and "deserve a break" then I have trouble getting into the mindset of starting the next task. So for me a project that requires doing lots of small tasks that take 20 to 40 minutes to finish is the worst case scenario. I find the pomodoro technique is super valuable when trying to get through something like that.

It's less useful for me when there's a big feature to code and all I need to do is start pumping out code.

I ran `brew install graphiz` a week ago and got a new major postgres version.

> The major argument is somewhat philosophical. I don’t like what people expect out of CD games. Does anyone think that the cheeseball dialog in crash and burn is a GOOD addition? It turns my stomach. People expect CD games to have tons of digitized speech and video, and the 3DO is going to be strongly associated with it. The joke here is that if we ever do a CD version of DOOM, you are going to get the game and “The Making of DOOM” a one hour feature film. Companies spend hundreds of thousands of dollars putting all this media into their games, and it often actually detracts from it. We don’t want to be part of this crowd.

> I would rather cut down to the essentials and fit on a cartridge than uselessly bulk up on a CD. I have a minimalist sense of aesthetics in game design.

It's kind of surprising to see John Carmack have what amounts to a "640k ought to be enough for everyone" moment here. As a guy that I see as somewhat of a futurist, developing on the edge of technology, it seems strange to see him be so dismissive to the potential of the massive storage space of CDs at the time.

I remember JWT coming on my radar around 10 years ago during the height of RESTful bikeshedding. It was a "must have" because sessions, being stateful, are not pure REST. Now that we've come off the height of the pure REST fanaticism and have learned about a bunch of issues that JWT causes, is it really better than just having a session id and a session stored on the server? Does it actually provide any technical benefit? Honest question.

This is good advice. However, I've seen this advice before and the example is usually something where it's easy to imagine what an incremental step is. The advice is when you want to do n just do < n. This is great for some things but I find it doesn't work for everything. So I'd like to just expand on this for tasks where doing < n doesn't really make sense.

For example, if you're trying to solve a difficult bug it can be overwhelming and you feel like you're not making progress and you procrastinate because you don't have the time to dive in for five hours and you feel like spending thirty minutes isn't enough to accomplish anything.

My advice, if you're struggling with tasks like these is to make excessive notes. Save the link to the Stack Overflow question you looked at. Write down file names and line numbers with your thoughts. Copy bits of relevant documentation right into your notes. The basic idea is that if you can ramp up from your notes in less time than it took you to make them then you have made progress.

There's something about event driven architectures that captures our engineering minds and makes our imaginations run wild. At face value it seems like the Grand Unifying Theory of software engineering, a Grand Unifying Architecture. Everything is perfectly decoupled and only reads and writes to an event bus. Perfect uniformity, everything just reads and writes events. Perfect open-closed semantics, I can completely add new functionality without touching any existing components just by having it read from the event bus.

However, like the grand unifying theories of physics so far, it just doesn't match reality. I have yet to witness a system that fully embraces event driven architecture that isn't a complete nightmare to read, understand, debug and modify. Yet we seem unable to shake the idea that it is a panacea. It captures the minds of each new generation of engineers and gets implemented in the technology of the era. For me it was applying the observable pattern to everything in Java. Now it's setting up a bunch of microservices that only communicate through Kafka. Maybe I'm just not a true Scotsman but this pattern has anecdotally never worked well in anything I've had to work with. I would think very hard before applying it as a pattern in my code let alone as the driving force of my architecture. That's just my experience and 2 cents.

This is the type of code/suggestion that I would have eaten up 10 years ago as a junior. Now this type of code just makes me angry and I spend most of my time turning stuff like this back into what it was before applying this query object abstraction.

There's nothing wrong with the code before he applies this abstraction. It's twenty lines, it's exactly in the first place I would go looking if I need to debug, it directly uses active record so I know there's no hidden BS.

The goal is definitely not to replace NGINX or Apache or the like. I don't see handling TLS ever being a goal of this project, same with HTTP2 support. Although allowing the user to plug something in to handle HTTPS may not be out of the question.

Yes, there are some pieces missing that are on my radar like chunked support, uri/query parsing and sendfile.

I don't really understand what your criticisms are. There is literally no functional code difference between a single header library and a two file library. Your aversion is as arbitrary as saying you don't consider libraries if the API uses camel case.

This only causes a problem if you define HTTP_BODY in the same file that you define HTTPSERVER_IMPL when including httpserver.h

No, but by virtue of being a single header library it will run through whatever static analysis you have set up on your project. If an http server like NGINX solves your problem then, please, use that, because this is not an http server. It's a library for creating http servers.

I would also love if someone wanted to contribute fuzz testing or other static analysis to the project. PRs are welcome.

I wrote tetris in verilog that can output to VGA 10 years ago for a university project. The code is here: https://github.com/jeremycw/tetris-verilog for anyone interested. Comments are sparse but it might be interesting for anyone looking for some example code that's relatable.

I don't get this. There's a reason why they make AstroTurf green. If you're Amazon and you're trying to generate realistic good buzz about your work conditions don't name the accounts "AmazonDrone643278" or similar.

I don't really understand it either. I thought the whole purpose of having an application layer on top of your database was to provide a specialized interface for your application. If you're just going to provide a general query language to the frontend what is the point of the application layer? It seems like you'll just end up writing a database on top of your database. If you are writing a general purpose interface now, why are you writing custom code? Couldn't it all be abstracted out into an RDBMS? Would an RDBMS with user login and permissions system meant to be accessed by the end user/frontend be better than everyone writing their own weird database wrapper? It all seems very strange to me.

I've now been a professional software developer for about 10 years and have come to the exact opposite conclusion of this article. I've come to find that these types of principals lead to the opposite of readable code for me. Principals like solid lead to overly abstract code that becomes very hard to follow. I prefer code to be as linear, obvious and unsurprising as it can be and the amount of useless abstractions that get bolted on to make code SOLID do the opposite of that. Some principals I have found useful:

YAGNI KISS DRY

In that order. First, try not to do the thing. Second, if you have to, make it as simple and straight forward as possible. Third, don't repeat yourself but observe one and two first.