Makes me wonder if the hardware engineers look at software engineers and shrug, “they don’t really know how their software really works.”
Makes me wonder if C programmers look at JS programmers and shrug, “they don’t understand what their programs are actually doing.”
I’m not trying to be disingenuous, but I also don’t see a fundamental difference here. AI lets programmers express intent at a higher level of abstraction than ever before. So high, apparently, that it becomes debatable whether it is programming at all, out whether it takes any skill, out requires education or engineering knowledge any longer.
Yeah, the online Gemini app is not good for long lived conversations that build up a body of decisions. The context window gets too large and things drop.
What I’ve learned is that once you reach that point you’ve got to break that problem down into smaller pieces that the AI can work productively with.
If you’re about to start with Gemini-cli I recommend you look up https://github.com/github/spec-kit. It’s a project out of Microsoft/Github that encodes a rigorous spec-then-implement multi pass workflow. It gets the AI to produce specs, double check the specs for holes and ambiguity, plan out implementation, translate that into small tasks, then check them off as it goes. I don’t use spec-kit all the time, but it taught me that what explicit multi pass prompting can do when the context is held in files on disk, often markdown that I can go in and change as needed. I think it ask basically comes down to enforcing enough structure in the form of codified processes, self checks and/or tests for your code.
Pro tip, tell spec-kit to do TDD in your constitution and the tests will keep it on the rails as you progress. I suspect “vibe coding” can get a bad rap due to lack of testing. With AI coding I think test coverage gets more important.
See https://abseil.io/tips/ for some idea of the kinds of guidance these kinds of teams work to provide, at least at Google. I worked on the “C++ library team” at Google for a number of years.
These roles don’t really have standard titles in the industry, as far as I’m aware. At Google we were part of the larger language/library/toolchain infrastructure org.
Much of what we did was quasi-political … basically coaxing and convincing people to adopt best practices, after first deciding what those practices are. Half of the tips above were probably written by interested people from the engineering org at large and we provided the platform and helped them get it published.
Speaking to the original question, no, there were no teams just manually reading code and looking for mistakes. If buggy code could be detected in an automated way, then we’d do that and attempt to fix it everywhere. Otherwise we’d attempt to educate and get everyone to level up their code review skills.
Some popular streamers have dabbled in OCaml this year, sometimes calling it "the Go of functional programming", which probably set off a small wave of people tinkering with the language. OCaml has also gotten gradually better in recent years in terms of tooling, documentation, standard library, etc.
In my experience learning a bit of OCaml after Rust, and then looking at Haskell, the three aren't all that different in terms of the basics of how ADTs are declared and used, especially for the simpler cases.
> Bad example. Google docs doesn’t use CRDTs but uses OT instead. CRDTs may handle your scenario just fine depending on how they decide to handle this scenario.
The CRDT may pick one or the other replacement word, but who is to say that either choice is correct? Perhaps including both words is correct.
> Then there’s not even a merge conflict...
Agree, this is what CRDTs are all about.
> ...to really worry about.
I think it is important to make clear that CRDTs do not "solve" the merging problem, they merely make it possible to solve in a deterministic way across replicas.
Often, CRDTs do not capture higher level schema invariants, and so a "conflict free" CRDT merge can produce an invalid state for a particular application.
There is also the example above, where at the application level, one particular merge outcome may be preferred over another.
So, it isn't as simple as having nothing to worry about. When using CRDTs, often, there are some pretty subtle things that must be worried about. :-)
I don't agree that a missing "framework" is the whole of the problem. It just isn't that simple.
Sure, people need to use resiliency skills to cope with the stresses of life. Often times, this is an important part of what therapy for depressed people is trying to achieve.
But this isn't to say that there isn't a constellation of causes in recent decades and years that cause the world to be particularly stressful, especially for young people. It also isn't to say that we should dismiss what is occurring in the world today as "the same old stuff" without acknowledging that it may actually have unique properties worth understanding. Off the top of my head: world population is at an all-time high, global warming is becoming increasingly understood, it is increasingly acknowledged that we can no longer simply extract unlimited resources from the earth to solve all problems, the Internet has changed the way the world works that seems to speed everything up: communication, changes within social groups, larger societal shifts, economic change, etc.
> It's much more a matter of whether you want to do something small scale and fun, or whether you want to suck all the joy out of it by applying the same soul crushing constraints we already get paid to do in our day jobs. Bleh.
Amen. And further, what better prepares a programmer to assess the relative costs of implementing a thing vs using a library providing that thing than having attempted an implementation?
Learning by doing is a valid approach, and this can even be called fun.
Definitely interested in how you achieved another 2-10x over the btree approach. I want surprised that btree was as effective as it was, but I’d be curious to know how you squeezed a bit more out of it.
Those are good things to consider in review, but I maintain that the answer might be "no" to one or more of those questions and still be acceptable.
I'm old enough to have worked in the pre-code-review era. Things were fine. People still learned from each other, software could still be great or terrible, etc. It wasn't appreciably worse or better than things are today.
> An implicit question in several of the above is "will this set a good example for future contributions?"
Which in my experience can be an almost circular requirement. What do you consider a good example? As perfect as perfect can be? Rapid development? Extreme pragmatism?
The more experienced I get, the less I complain about in code review, especially when reviewing for a more junior dev, and especially for frequent comitters. People can only get so much out of any single code review, and any single commit can only do so much damage.
Put another way, code review is also about a level of trust. Will the committer be around next week? Are they on the same team as me? If yes, give them some leeway to commit incremental work and make improvements later. Not all incremental work need occur pre-commit. Mention areas for improvement, sure, but don't go overboard as a gatekeeper.
Things are obviously going to be different when reviewing code from what amounts to a stranger on a mission critical piece of code, etc.
Given equivalent data stored in both JSON and BSON format I would expect them both to compress down to blobs of roughly equivalent sizes. This is because both encode roughly the same amount of information, so the compression algorithm will tend to compress down to the same final result. I haven't run this as an experiment though..that would be fun.
> I am more excited by Emacs 30, mostly I like the ahead of time compilation of Lisp code.
Emacs has had an ahead of time compilation feature, "Native Compilation," since Emacs 28. Is this what you mean? Or is the Emacs 30 feature something different?
There is always an authority structure in these kinds of companies. I'm personally familiar with Google, but this description of Facebook makes it sound similar...
The upside is that people, in theory, don't need to wait to be promoted to (attempt to) have an outsized influence on what actually happens on their team, in their org, etc. The downside is that the "real" power/influence structure can be a more nebulous/social game, rather than something concrete that is diagrammed out in a visible org structure. It was often said at Google that you get promoted to level X after already doing work at that level, which implies that the people with influence are running around influencing/leading before they've been anointed with an official title that "gives" them authority.
Reading Carmack's letter, it sounds like he consciously chose to prioritize his personal programming/engineering work over his social/influence/leadership at Facebook. In all my observations, past a certain level, you kinda have to choose one or the other. Both are valid choices.
> Which is why unless is such a hard concept for people to grasp, not just in code, but also in regular English.
This is the first I've heard about this confusion over the word "unless" in English.
In spoken English I do notice that most often the "unless" comes after a statement. Example: "I'll be there on time, unless the bus is late." That is more clear (to me) than "I'll be there on time, if the bus is not late." Maybe not by coincidence, I tend to like "unless" when it follows the action in in Ruby code, too.
> nix unlike all other distros can install multiple version of the same package
The above is sometimes true and sometimes not. For the most part, Nix can install multiple versions of a program but only one can be in use at any given time.
Nix is for the most part shell based workflow (as in bash, zsh, etc.). The `nix-shell` command lets you switch out the packages (and versions of packages) that are used in any given shell, but it works off of a configuration file written in the Nix language that you write. The programs that are available are controlled by environment variables such as PATH and MANPATH.
Nix is a big shift from the usual way of dealing with packages, programs, etc. It isn't really useful until you really make the effort to understand what is going on, learn the Nix language, etc. If you are not interested in "programming" your system, then it probably isn't for you.
> Exact opposite. I ask them to please not bring me a mashed vegetables patty and call it a burger. It is not.
I can agree that "mashed vegetables" does not describe a good veggie patty. I don't agree that a good veggie patty fails in "burger" format.
I can easily imagine that some people have simply never tasted a good veggie patty in "burger" format, because they are rare.
This is the root of most "meat alternatives" in average restaurants -- much of the restaurant world hasn't figured out that providing vegetarian options isn't about finding equivalent "meat replacements" but instead about cooking up options that stand on their own and taste great.
> While Impossible and Beyond displaced the meat alternatives
In my experience the "meat alternative" patties have not displaced the good veggie patties in the restaurants that had good veggie patties to begin with.
> ...that doesn't mean you have to go meat in a vat at home, you can do products such as Morningstar Farms Grillers Original, or maybe Boca All-American Flame-Grilled Burger. Those taste stack more reasonably with what goes on a burger than the mashed vegetables patties, without the weirdness (fake blood look, why?) of Impossible or Beyond. Your local diner will probably be happy to stock them as they're simple frozen goods.
A beef burger patty has the wonderful property that it is simply made of meat -- a good beef patty has no ingredient lists because it isn't a packaged food.
A good veggie patty is also made on site of simple whole foods, in the same way a good burger is and in the same way any other good meal is.
Any frozen puck taken from a bag and slapped on a grill fails the test, be it comprised mostly of beef, soy, beans, "beyond beef", wheat, or whatever. Those things are about convenience, not taste.
Most people driving cars with an active recall are unaffected by the problem the recall is supposed to address. They can drive on blissfully unaware that something could go wrong. They might even enthusiastically recommend that others purchase the car they drive.
For a few people, they'll experience a failure, possibly a dangerous one.
And this is the root of the problem. The fundamental concept of using a language prone to UB exposes all programs to a small risk. In isolation, the risk is small. In aggregate, the problem is real.
Makes me wonder if C programmers look at JS programmers and shrug, “they don’t understand what their programs are actually doing.”
I’m not trying to be disingenuous, but I also don’t see a fundamental difference here. AI lets programmers express intent at a higher level of abstraction than ever before. So high, apparently, that it becomes debatable whether it is programming at all, out whether it takes any skill, out requires education or engineering knowledge any longer.