Using FizzBuzz as your proxy for "unreviewed code" is extremely misleading. It has practically no complexity, it's completely self-contained and easy to verify. In any codebase of even modest complexity, the challenge shifts from "does this produce the correct outputs" to "is this going to let me grow the way I need it to in the future" and thornier questions like "does this have the performance characteristics that I need".
> is this going to let me grow the way I need it to in the future
This doesn’t matter in the age of AI - when you get a new requirement just tell the AI to fulfill it and the old requirements (perhaps backed by a decent test suite?) and let it figure out the details, up to and including totally trashing the old implementation and creating an entirely new one from scratch that matches all the requirements.
For performance, give the AI a benchmark and let it figure it out as well. You can create teams of agents each coming up with an implementation and killing the ones that don’t make the cut.
Or so goes the gospel in the age of AI. I’m being totally sarcastic, I don’t believe in AI coding
> including totally trashing the old implementation and creating an entirely new one from scratch that matches all the requirements
Let me guess, you've never worked in a real production environment?
When your software supports 8, 9, 10 or more zeroes of revenue, "trash the old and create new" are just about the scariest words you can say. There's people relying on this code that you've never even heard of.
> Let me guess, you've never worked in a real production environment?
The comment to which you're responding includes a note at the end that the commenter is being sarcastic. Perhaps that wasn't in the comment when you responded to it.
It wasn’t thanks for highlighting. Can be hard to tell online because there’s a lot of people genuinely suggesting everyone should build their own software on the fly
If the amount of code corporations produce goes even 2x there's gonna be a lot of jobs for us to fix every company's JIRA implementation because the c-suite is full of morons.
I work on a product that meets your criteria. We can't fix a class of defects because once we ship, customers will depend upon that behavior and changing is very expensive and takes years to deprecate and age out. So we are stuck with what we ship and need to be very careful about what we release.
But if you start from the beginning with a code base that is always only generated from a spec, presumably as the tools improve you'd be able to grow to a big industrial-grade app that is 100% based on a spec.
The question is how many giant apps out there have yet to be even started vs. how many brownfield apps out there that will outlive all of us.
If the spec covers 100% of the code paths, then yes, you're right. But now spec and code are entirely redundant. Changing the spec or changing the code takes the same effort.
If the spec doesn't specify all the details, then there are gaps for the code to fill. For example, code for a UI is highly specific, down to the last pixel. A spec might say "a dialog with two buttons, labelled OK and cancel". That dialog would look different every time the spec is reimplemented.
Unless of course, there was also a spec for the dialog, that we could refer to in the other spec? That's really just code and reuse.
> When your software supports 8, 9, 10 or more zeroes of revenue, "trash the old and create new" are just about the scariest words you can say. There's people relying on this code that you've never even heard of.
Well, now it'll take them 5 minutes to rewrite their code to work around your change.
> Well, now it'll take them 5 minutes to rewrite their code to work around your change
You misunderstand. It will take them 2 years to retrain 5000 people on the new process across hundreds of locations. In some fields, whole new college-level certifications courses will have to be created.
In my specific experience it’s just a few dozen (maybe 100) people doing the manual process on top of our software and it takes weeks for everyone to get used to any significant change.
We still have people using pages that we deprecated a year ago. Nobody can figure out who they are or what they’re missing on the new pages we built
> You misunderstand. It will take them 2 years to retrain 5000 people on the new process across hundreds of locations. In some fields, whole new college-level certifications courses will have to be created.
I don't agree with your first point. We are surely writing less code, and it will keep getting less and less. At some point it will reduce to a single run function that will make the universe and everything work and it will be called via a button, and that will be the modern definition of writing code: Click the button. Not a lot of keys with weird alphabet thingies on them.
You are however right on your second point because I'm damn good at clicking buttons.
it isn't gospel, it's perspective. if you care about the code, it's obviously bonkers. if you care about the product... code doesn't matter - it's just a means to an end. there's an intersection of both views in places where code actually is the product - the foundational building blocks of today's computing software infrastructure like kernels, low level libraries, cryptography, etc. - but your typical 'uber for cat pictures' saas business cares about none of this.
Yes? If you’re an auto factory, you might care, but an auto maker cares about minimizing cost and maximizing revenue within the regulatory constraints. Nowhere is there a requirement to care about how the car is built, there are requirements on what the car can and cannot do.
Caring about the requirements on what the car can and cannot do sounds suspiciously like caring about how it's built when you consider how it's built directly impacts what it can and cannot do.
> Each board director could ask for a particular thing they require, or a briefing themself, eliminating human intermediary
You are missing the point of board briefings. The CEO serves as a critical filter of information, deciding what to tell the board and how to frame it. If you take the CEO out of it, you're giving the board full access to the company's state. There's enough going on day-to-day that each member can tell themselves the story they want to believe. The CEO is there to advocate for the company and present a unified front, you can't take them out of the equation.
Because it opens them up to liability. The most experienced board members will leave the board deck behind so they don’t have a copy. They sure won’t go searching for things that aren’t presented in the board meeting. It’s better for them to blame and fire the CEO.
I've lived in 3 states and none of them have required proof of citizenship to register to vote. You basically check a box that acknowledges that you are a US Citizen with the right to vote and that illegal registration carries penalties.
How many documents can be used to prove your citizenship? How many times do people have to go back to the DMV because they forgot something or another? Now imagine that everyone has one shot to get that right on voting day.
In the United States at least, voter registration will include your place of residence which will place you in a specific precinct. In other words: "I am so and so, and I live here. Votes that affect this area include me, and I get a say."
When voters are voting for things, for example a tax levy to fund a new school, or for who will be their state or federal congressional representatives, it's important that the voters in that school district or in that congressional district are the ones voting for their representatives or for the bills or initiatives that affect them. This isn't quite as important for national elections, gubernatorial races, or for the senate at the federal level, but it's obviously incredibly important the more local you get.
Without voter registration, that model breaks down. Even mundane things like how much staff and equipment should be at a polling location is not easy to figure out when you don't know how many voters you'll have. If you haven't worked as a poll worker it's really enlightening to learn about how the process works and a great way to meet your neighbors.
One of the issues is that the US, unlike most of Europe, for example, doesn't require registering your address with your locality or police when you move.
Bash syntax is anything but simple or logical. Just look at the insane if-statement syntax. Or how the choice of quotes fundamentally changes behavior. Argument parsing, looping, the list goes on.
> Also the choice of quotes changing behavior is a thing in:
In those languages they change what's contained in the string. Not how many strings you get. Or what the strings from that string look like. ($@ being an extreme example)
> @ Expands to the positional parameters, starting from one. When the expansion occurs within double quotes, each parameter expands to a separate word. That is, "$@" is equivalent to "$1" "$2" ... If the double-quoted expansion occurs within a word, the expansion of the first parameter is joined with the beginning part of the original word, and the expansion of the last parameter is joined with the last part of the original word. When there are no positional parameters, "$@" and $@ expand to nothing (i.e., they are removed).
That’s…a lot. I think Bash is interesting in the “I’m glad it works but I detest having to work with it” kind of way. Like, fine if I’m just launching some processes or tail’ing some logs, but I’ve rarely had a time when I had to write an even vaguely complex bash script where I didn’t end up spending most of my time relearning how to do things that should be basic.
Shellcheck was a big game changer at least in terms of learning some of the nuance from a “best practice” standpoint. I also think that the way bash does things is just a little too foreign from the rest of my computing life to be retained.
Complex and bash script should not be in the same sentence.
If a script you have is becoming complex, that’s an hint to use an anemable programming language with proper data types and structures.
Uh, reading a bash script shouldn't be as hard as doing your taxes. Bash syntax has to be simple because bash code is going to be read and reasoned by humans. Reading just a simple if statement in bash syntax requires a TON of knowledge to avoid shooting yourself in the foot. That's a massive failure of usability just to save a couple of keystrokes.
This is like saying "what's wrong with brainfuck??? makes sense to me!" Every syntax can be understood, that does not automatically make them all good ideas.
Bash syntax is the pinnacle of Chesterton's Fence. If you can't articulate why it was done that way, you have no right to remove it. Python would be an absolutely unusable shell language.
I didn't say that there wasn't a reason. I said it was absolute trash to use. It's so bad that the moment I need even the slightest bit of complexity, I will switch away from bash. Can't really say that for any other language.
This is a Very Bad Idea. Two people working with the same language will be unable to reason about each other's code, because it requires understanding their bespoke syntax and its nuances.
No it won't? That's exactly the point -- each of those people will be viewing the code in their own preferred syntax. If there is semantic nuance in the writer's syntax, the reader will see it presented in the best way their preferred syntax's representation can provide.
Imagine all the hours saved that are currently spent on tired tabs vs spaces debates, or manicuring .prettierrc, etc etc. The color of the bike shed might matter (sometimes a lot) to some people, I know, but it's storing bikes away from the elements and thieves that is the goal, not obsessing over optimizing something that is demonstrably a subjective matter of taste.
Those are both formatting examples though? You're suggesting totally different syntaxes, which means you can't even point to the same line in a codebase when talking about a PR. This throws up massive hurdles around communication when you could just agree on one standard and move on.
class Bean {
private boolean sprouted;
public void sprout() {
this.sprouted = true;
// ...
}
}
or
data Bean = Dormant | Sprouted
sprout :: Bean -> Bean
sprout Dormant = Sprouted
sprout Sprouted = -- aw, beans, we could have modeled
-- this state as impossible to construct,
-- but you chose runtime checks, so
-- here we are.
As for pointing to the source line, I think JavaScript people solved that one for us with source maps. Just because we download and execute a single 4Mb line of minified code, doesn't mean we can't tell which line of the original source caused the error. :)
Oh lord, yeah this convinces me even more that this is a bad idea. I can't even tell at a glance if those do the same thing. Just pick one and move on, you're requiring everyone to pass around sourcemaps literally everywhere they go, one for every single pair of syntaxes. You can't even talk about the code with the same language with each other. Is Bean a "class" or a "datatype"? If I'm using one syntax, how do I tell you to fix a bug in your syntax?
> If I'm using one syntax, how do I tell you to fix a bug in your syntax?
How about "Hey, your Bean ain't sprouting"? :)
I'm sorry, I feel like I'm not communicating this properly. Um, have you ever discussed with someone a book or a TV show that was translated into your language? Did you have problems referring to the exact parts you liked or disliked? :)
I got the battery extension and it lasted more than 10 months (I have it on a 30 minute refresh). Highly recommend TRMNL if you want something to hack on without fussing with hardware.
Complex numbers are just a field over 2D vectors, no? When you find "complex solutions to an equation", you're not working with a real equation anymore, you're working in C. I hate when people talk about complex zeroes like they're a "secret solution", because you're literally not talking about the same equation anymore.
There's this lack of rigor where people casually move "between" R and C as if a complex number without an imaginary component suddenly becomes a real number, and it's all because of this terrible "a + bi" notation. It's more like (a, b). You can't ever discard that second component, it's always there.
We identify the real number 2 with the rational number 2 with the integer 2 with the natural number 2. It does not seem so strange to also identify the complex number 2 with those.
If you say "this function f operates on the integers", you can't turn around and then go "ooh but it has solutions in the rationals!" No it doesn't, it doesn't exist in that space.
You can't do this for general functions, but it's fine to do in cases where the definition of f naturally embeds into the rationals. For example, a polynomial over Z is also a polynomial over Q or C.
Sure, you can say that complex numbers are 2-tuples with a special rule for multiplication (a, b) * (c, d) = (ac - bd, ad + bc). Same way you can define rationals as 2-tuples with a special rule for addition (a, b) + (c, d) = ((ad + cb) / gcd(b, d), bd / gcd(b, d)).
But I think this way you'd lose insight as to where these rules really come from. The rule for complex multiplication is the way it is, precisely because it gives you an algebra that works as if you were manipulating a quantity that squared to -1.
The movement from R to C can be done rigorously. It gets hand-waved away in more application-oriented math courses, but it's done properly in higher level theoretically-focused courses. Lifting from a smaller field (or other algebraic structure) to a larger one is a very powerful idea because it often reveals more structure that is not visible in the smaller field. Some good examples are using complex eigenvalues to understand real matrices, or using complex analysis to evaluate integrals over R.
I hate when people casually move "between" Q and Z as if a rational number with unit denominator suddenly becomes an integer, and it's all because of this terrible "a/b" notation. It's more like (a, b). You can't ever discard that second component, it's always there. ;)
Yes, you're right. You can't say your function operates in Z "but has solutions in Q". That's what people are doing when they take a real function and go "ooh look, secret complex solutions!"
Great writeup! Looks like this is going to be relevant very soon.
> Tools do not make a culture; the people engaging on it do
Absolutely, but it's also important to keep in mind that the tool has a big impact on culture by virtue of what behaviors it encourages and what limitations it has. "The medium is the message" is very true here, so think carefully about which tool you hop onto.
reply