...and now the site is down. Hope the cursors were worth it!
2,205 karma · joined March 22, 2012
> Code reviewing coworkers are rapidly losing their minds as they come to the crushing realization that they are now the first layer of quality control instead of one of the last. Asked to review; forced to pick apart. Calling out freshly added functions that are never called, hallucinated library additions, and obvious runtime or compilation errors. All while the author—who clearly only skimmed their “own” code—is taking no responsibility, going “whoopsie, Claude wrote that. Silly AI, ha-ha.”
LLMs have made Brandolini's law ("The amount of energy needed to refute bullshit is an order of magnitude larger than to produce it") perhaps understated. When an inexperienced or just inexpert developer can generate thousands of lines of code in minutes, the responsibility for keeping a system correct & sane gets offloaded to the reviewers who still know how to reason with human intelligence.
As a litmus test, look at a PR's added/removed LoC delta. LLM-written ones are almost entirely additive, whereas good senior engineers often remove as much code as they add.
So if the reason you're choosing Android over iOS is freedom and flexibility, once that's gone, why not choose slickness, speed, battery-life, photo quality, and an integrated experience?
Such countries already have not only smoke alarms but also building codes and layers of safety systems.
The analogy matches a person who goes to a place with high fire risk and no safety systems in place and through tireless effort introduces common sense measures to protect people.
They are probabilistic. Running them on even different hardware yields different results. And the deltas compound the longer your context and the more tokens you're using (like when writing code).
But more importantly, always selecting the most likely token traps the LLM in loops, reduces overall quality, and is infeasible at scale.
There are reasons that literally no LLM that you use runs deterministically.
However, the specific discussion here is about delegating the work of writing to an LLM, vs abstracting the work of writing via deterministic systems like libraries, frameworks, modules, etc. It is specifically not about abstracting the work of compiling, constructing, or smelting.
But here I'll bite: I've had MBPs for work for like 15 years now and I bought a personal high spec Thinkpad. I now regret that purchase because my work machine is better than my personal machine in literally every way. My over $2k Thinkpad just sits there gathering dust because I don't want to use it. And unlike MacBooks, the secondary market for it is nothing so I can't just sell it and recover most of the loss.
I quite like Go and use it when I can. However, I wish there were something like Go, without these issues. It's worth talking about that. For instance, I think most of these critiques are fair but I would quibble with a few:
1. Error scope: yes, this causes code review to be more complex than it needs to be. It's a place for subtle, unnecessary bugs.
2. Two types of nil: yes, this is super confusing.
3. It's not portable: Go isn't as portable as C89, but it's pretty damn portable. It's plenty portable to write a general-purpose pre-built CLI tool in, for instance, which is about my bar for "pragmatic portability."
4. Append ownership & other slice weirdness: yes.
5. Unenforced `defer`: yes, similar to `err`, this introduces subtle bugs that can only be overcome via documentation, careful review, and boilerplate handling.
6. Exceptions on top of err returns: yes.
7. utf-8: Hasn't bitten me, but I don't know how valid this critique is or isn't.
8. Memory use: imo GC is a selling-point of the language, not a detriment.
Defold ships as a ~2MB executable, is designed for lightweight performance on non-cutting-edge mobile devices, and focuses on portability with a commitment to never require any build tooling. Professional game developers and hobbyists alike very much consider it a lightweight platform, but you're welcome to disagree with them.
> I'd 100% pick a "fantasy console" like Pico-8
Ok?
> Phaser[3] actually IS regular javascript ... I don't know how much more standard JS you can get than that.
Your linked example starts with `class Example extends Phaser.Scene` as the base for everything, then fills it with gems like `this.physics.add.image(400, 100, 'logo')` ... For your colleagues' sake, I truly hope that's not the sort of "regular javascript" you use at work.
If you wanted to learn JavaScript by building games, then you should definitely not use Kaplay or Phaser, etc, since they're so far removed from JavaScript you wouldn't learn anything (other than how to build things in their particular environments). Web standard JS is more than capable of building simple games with no abstractions separating you from what you're trying to learn.
I'd like to add two points to this:
First, I like that you said "live coding" rather than leet code. The floor for live coding should be super low, with a high ceiling and lots of flexibility. That allows you to say, nope, they didn't pass the floor level, easy binary decision, no hire. Pick a fun toy to build in 90 minutes and the high ceiling + flexibility will yield tons of signal from applicants.
Second, I see live coding sessions like this as a positive sign from potential employers. It lets me know that my future colleagues will have some baseline level of competence. If you've worked on a team that didn't do live coding, and you've had to carry water for someone who can't actually do the day-to-day technical "hard skill" work of software engineering, you probably feel the same way. Never again.
I bought it because I wanted frankly, something different than the Mbps I've had from work for 15 years, and to go Linux-first. OSX annoys me about as much as Linux does, so the software is on par, but the hardware just can't touch Apple hardware. I wish this weren't the case, but it is.
It's hard for me to take in good faith an interpretation of that article that determines Noel "didn't write his own engine," but in case a couple direct quotes would help:
"I don't have much to say about assets, because when you're rolling your own engine you just load up what files you want, when you need them, and move on." ... "my City of None engine"
Noel literally describes his workflow as "rolling your own engine" and has a name for the engine he wrote.
> He's also making a 2D game, which traditionally is closer to game making of old
Please read the context of the thread you're replying to, which is arguing against writing your own engine even for games with "simpler 'indie' graphics," specifically called out.
> Finally, he's not arguing against engines like Godot or Unreal
He's not arguing against anything. He's advocating for writing your own engine.
Noel made the indie hit Celeste: https://en.wikipedia.org/wiki/Celeste_(video_game)
It allows anyone to provide a complaint without any evidence, about any content hosted anywhere, and puts the legal onus on the person hosting that content to prove the negative (that it isn't a "fake"), with the legal requirement to remove the content as soon as is technically feasible (ie, instantly).
So, similarly abusable to the DMCA, but with even broader requirements and even more-impossible-to-prove legitimacy, since it creates a whole new ill-defined class of legal ownership over content.
TLDR: it's a great reason to move hosting outside of the US
1) a bare (ala Pixel) foldable with S-pen and without large external displays to get cracked and complicate things
2) a rooted linux-computer-in-your-pocket that can be plugged into a usb-c hub and happens to have a SIM card/cell modem to work as a phone.
...but until then I just get by for years and years on whatever mid-tier phone happened to be the smallest form-factor and best-camera-for-$ at the time my last one became unusable.
This is why - because people like you are killing other people due to technologically-inspired negligence.
Worse, it continues to trend downward.
Most sane tech CEOs would prefer to keep their upward trend and $5+ billion revenue rather than saving $1 billion to lose $2.5 billion and invert their slope.