Mine is that the useState hook is an actual plague on the entire React ecosystem. Regardless of your opinions of React, if you wanna use something then use it right.
If you don’t prematurely optimize your code you’ll never optimize your code.
I know people are advised against premature optimization because it risks you wasting time on something that ends up unused.
But let’s be honest, once you get something into a working state will you ever be afforded the time to go back to it? Even if you are, are you really gonna choose to uproot code and do a refactor on it and potentially everything relying on it?
Rather than waiting until your hacks and workarounds run out and you absolutely have to do a refactor, I would prefer spending more time upfront to make sure it is efficient and flexible before moving on.
My masochistic tendencies brought me back to say:
One reason python is a great language is that most LLMs are particularly good with it
They also seem fine with rust. I haven’t tried with perl yet as that is a fun language
Thanks. I haven’t tried that yet and am interested, so maybe this’ll be a good experiment.
The
unlesskeyword is an abominationx = "I disagree." y = false puts x unless yI miss it when writing python.
Specifically I hate it as a prefix. It’s even worse when else clauses become involved!
x = "this is great" y = "this is awful" z = false unless(z) puts(y) else puts(x) endIn that case it’s just a synonym for
if (not z)yes, and? Having to translate
unlesstoif notis basically exactly why I hate it. Just writeif not
The entire modern web tech stack should be thrown in a dumpster, ignited with gasoline, and blown up with a nuke for good measure.
Is this not the most popular, widely accepted opinion?
I would love to see TCP/IP replaced by something more secure and uncentralizable like Reticulum.
People in FOSS community (including users) nitpick way too much about eachother’s ethics and are mostly dictators so they expect everybody’s views to align with themselves and each sub-community/individual see themselves as the source of moral balance.
“oh no one of project XYZ maintainers doesn’t like trans people we should boycott the project and fork it into LibreLGBTQXYZ”
be professional ffs. See the project as the software and it’s technicality, art, science and engineering. we can’t be too picky about individual people’s beliefs and ethics especially in current situations.
Transphobia is now what antisemitism was during the Holocaust.
This framing of trans rights being pulverized as an edge-case moral purity signaling is low-key genocide enabler discourse.
It is only a matter to be careful to set boundaries to the centrism so that it doesn’t bleed over to the nazi side.
That being said, weaponized purity in online politics, and online software politics specifically might be a problem, sometimes. Minimal gain and huge inconvenience to the resistance, but I won’t go into it right now.
Is it really a genocide? Like I’m trans and being pushed towards losing my life, and that’s bad, but it feels weird calling that a genocide when you compare it to the actual Holocaust or Palestine or the Sudanese civil war. For it to qualify I think I’d have to be arrested and executed for being trans, not just driven to suicide because I don’t have any friends and no employers will hire me.
In the worst case in the worst countries. Fascists like to turn people against a subgroup. In the 1930s it was the Jews, but only in Germany.
Right now the American government is making fascist noises and telling everyone how terrible trans people are
“I will happily promote the project of a person who openly says people like me should be shot. What’s the problem?”
I probably disagree with 90% of Linus torvald’s beliefs and ideologies. Do I promote him as a person? No. Do I promote Linux as a great project and operating system? Hell yes. Same goes with Stallman or probably 90% of other people. Because that’show we are. Most of us share nothing in common and oppose eachother’s beliefs but we can still work together as professionals.
Linus doesn’t want you and your kind fave down in a gutter. Stop pretending this is about a mere disagreement in harmless beliefs.
You can stop attacking the dev or team or company in charge of a project, mate, the software is what matters. Death of the author and all that
If some dev team wants to curb stomp you, you should probably keep away from them
Lol, so if using their project gets them fame and money to fuck up my country or harm people that look like me, according to you I should just keep going?
Genius advice. Truly enlightened.
Transphobia is unprofessional.
So is any other kind of bigotry.
An individual’s personal beliefs has nothing with their profession. Unless they leak it into their profession. Now the profession has that ideology and we can address that. The person, and especially as long as it’s just words and tweets etc, is separate from the work.
Anyway, this is my unpopular opinion.
be professional ffs
You lost me here. It’s not “unprofessional” to want people to not be transphobic.
You can ask the person, not the software project. The project is just a project. We can tear eachotger to pieces as individuals and then sit at a table trying to solve problems as professionals.
If someone wanted to take your rights away, maybe even didn’t believe you should be allowed to be alive, would you be unprofessional for not wanting to use software they make? Would you be unprofessional for making your own version of that if the project refused to remove them as the lead? No. You wouldn’t. A way to solve that problem as a professional is to fork the project. What’s not professional is calling people doing that unprofessional.
So don’t donate to them and tell others how they’re bad and that they don’t deserve money
Why stop using the software they made and gave away?
This conversation has been about people who fork software to continue working on it without bigoted leaders in charge, in what way is that not using the software?
Cloud computing is the biggest breach of privacy out there that we’ve adopted whole hearted.
There is no cloud. Just other people’s computers.
Also, I would say that AI has probably one-upped cloud computing in that area.
Firefox is a good browser
I do have to put up with an unsupported browser banner on government websites (which work perfectly)
If a browser does not support unlock origin it is worthless. So Firefox wins by all opponents willfully exiting the race
It’s the only non chrome browser
Safari? I’m not suggesting you use it, but it does exist.
We don’t acknowledge the existence of proprietary blobs here
Firefox is good, Mozilla is bad
You know what, I’ve been a Firefox user since the days of beta Phoenix. I’ve expressed your view for years now - Firefox was great, but held back by a commercial org that wanted fancy SF offices, fancy SF compensation etc.
But I tried out Helium a little while ago and in truth, I’m not sure Firefox is all that good these days. Helium is basically ungoogled-chromium + extension support + super lean UI.
The upside is that you no longer have to contend with sites that have given up on Firefox testing. The downside is manifest v3. But all in all, I find it a better browser. Firefox is so busy telling its story, and finding revenue, that it just seems to have left behind product market fit.
Using the blink engine, even in a ungoogled browser, still gives google power and is immoral.
Getters and setters are ridiculous
I don’t like working with them any more than you do, but they’re necessary to enforce read/write-level security. Without them, there’d be no differentiation between reading a variable and writing variable from an external class, which kinda defeats the point.
From a development standpoint, they’re an extra hurdle to clear. From a security standpoint, they’re a necessary evil.
Moreso correctness, not security. In the end, your user is shooting themselves in their foot, if they mutate a variable that they shouldn’t, and by making the variable private and only offering a getter, we document that.
Having said that, there’s also big differences between languages and paradigms, though.
In object-oriented / garbage-collected languages, you often pass around references to an object into so many places that you need to code defensively versus your own codebase. That’s why getters/setters were taught religiously during the height of OOP.In other paradigms, you often just have one place that uses an object and then you can …simply not shoot yourself in the foot there. When you control both the definition and the access, you don’t need to protect yourself from yourself. In particular, you would probably think twice before mutating an object anyways.
Perl is a fuckin’ awesome programming language, and it’s too bad other languages didn’t learn from it.
I will forever miss you $_
Other languages took perl’s regex engine
Good. Perl did regex correctly
Care to elaborate on this? Not saying you’re wrong necessarily, that’s just a pretty bold claim and I’m curious why.
React works by maintaining a virtual representation of the DOM. When you dispatch state changes into the virtual DOM react can determine which components depend on the change and which side
useEffects run.My gripe is that YouTube tutorials teach that the useState is the equivalent of a variable. This encourages average developers to problem solve solutions that end up using React’s Virtual DOM for business logic. The YouTube tutorials have react devs planting 100s of useStates - some of which don’t directly induce a visible-on-screen rerender - and then ⅒ as many useEffects to bind these states together. This means that for the Virtual DOM to come to the conclusion as to what html elements need to be changed and how it has already mutated 20-50-100s of times and the CTO tells me the react app is slow and they’re mad.
If 2 states have the opportunity to mutate each other back and forth then the truth is that you have 2 perspectives of the same state. And React gives you solutions for that - proper solutions - the
useReducerhook is for defining these complex state mutations and the Context API for communicating that state to any component.And this has me quintuple pissed off because these same tutorial grade react devs install REDUX as compulsively as a pack-a-day smoker (that’s #3). They use Redux to file variables in JavaScript memory (that’s #4) like it’s a global variable and rarely if ever use it for the complex state mutations they need instead I’ve seen react devs write components pull state out of redux into a component just so it can mount useEffect and process the state and dispatch the result back into redux. Let’s not even bring up how the react-redux binding library literally uses the React Context API (that’s #5).
As a tutorial grade react developer (please return me to the backend where I am mediocre instead of bad), having more senior developers take the time to explain why my code was bad was really helpful.
Also I think I just kind of hate JavaScript. It always feels like everything is more complicated and booby trapped than it should be.
Modern Money Theory.
What specific side of the MMT hill are you dying on?
Personally, any financial economic model which uses fiat currencies, but dismisses MMT, is a pseudoscience and should be afforded a consummate level of deference.
Money, like everything, needs to be studied. Like we don’t know what government spending is inflationary and what isn’t, and that’d be a great thing for central banks to know so they can advise government what their policy will cost
Right now everyone pretends it’s the same to spend the money fixing a dangerous road or by reducing taxes to help some giant company
Though Keynesians are more likely to distribute stimulus money to the people, which is nice.
You should not be using AI at all. https://survey.stackoverflow.co/2026/ai
This is a LinkedIn screenshot, sry if I cropped it too tight
No that’s my opinion lol. I’m in the 1%. I wasn’t saying you used AI.
I’m more-or-less agreed with what I think you probably mean, but you’re going to have to be more specific than that. What does “should” mean, is it morally wrong or just likely to lead to bad results? What does AI mean, does it include anything with a neutral net? Or even the formal logic systems which were popular in the middle of the last century?
You’re totally right, I was trying to word it in a way that was in line with the survey results since the meme wasn’t so clear. But also I totally should have explained more since I complain about others not explaining enough all the time.
What I meant by AI was LLMs specifically.
And image generation!
While image generation is bad, it’s actually much less energy intensive and massive data centers are not being built for it. The problem currently is solely LLMs.
-
C++ is an awful language overall.
-
Linus is just some guy with good programming skills and not an authority over anything tech.
-
There aren’t any good text editors in the wild. VSCode is awful apart from extension support. Kate is close to being perfect but lack of extensions are pulling it back. Vim, Helix, Emacs, NeoVim are all flex toys.nvm just tried zed with AI disabled -
AI bad
Upvoting because I disagree with every word of what you wrote.
Linus is just some guy with good programming skills
I somewhat agree. Most celebrated personalities in tech aren’t programming geniuses - they were in the right area at the right time and had some luck. Zuckerberg is a good example.
I think kernel maintainers and rendering engines (browsers and others) have a higher base skill level. Like some web developers are clever and some are stupid, but I don’t think there are stupid kernel maintainers.
The thing with Linus is that he’s been involved, and at the pointy end, for decades. You or I may not agree with him on every issue, but you can acknowledge that he has experience and he has connections.
What makes you think C++ is awful?
Don’t most people who use it try to avoid like 90% of the core language features
Agree with half of that. C++ is last century stuff and should be replaced. Any new code in C and C++ is immediately a vulnerability.
Atleast C is easy to understand which makes it easier to find and fix vulnerabilities. C++ feels like it’s duct tape holding it together.
-
Linux should be forked at a pre-ai date.
I’ve got good news for you!
Ha! Well, by a solid group of committed lead devs I guess is my point.
Who’s coming with me!?
I think all the devs like the ai tools
I don’t think there’s enough skills in the Luddite camp
Unit tests are overrated to the point of being harmful. They have their place, but that place is certainly not “the base of the testing pyramid”. They are useful for a very specific type of “units” - and using them anywhere else just messes things up.
Curious how bad they’d have to be to land you at that position.
If they’re hard to write, it’s kinda a red flag about the overall code itself. Forcing people to write them tends to force people to use better patterns just so the associated tests aren’t a bitch.
And they pin behavior more than strict correctness, in my experience, but that’s a valuable signal. Canaries in the mine.
You can be much more bold when you’ve got strong coverage.
So I do admit some of the benefits might feel intangible… But boy howdy you’ll miss them if you move to a shop that never bothered. You’ll see the dumbest fucking patterns and be kinda handcuffed to do anything good.
And they pin behavior more than strict correctness, in my experience, but that’s a valuable signal. Canaries in the mine.
The problem is that the behavior they pin is not the official API-exposed behavior. The behavior they pin is mostly implementation details. If
diffuse(bomb)is supposed to diffuse the bomb, I need to test that given a legal instance of aBombit’d end up diffused. A unit test cannot test that - ifdiffuseis the unit being tested, thenbombis not allowed to be an actual bomb - it has to be a mock. And thusdiffuse(bomb)does not test thatdiffusediffuses a bomb - it tests thatdiffusecuts very specific set of wires in a very specific order.- If the bomb change, the unit test is till green because the mock is still replaying the old behavior.
- If I fix
diffuseto handle the new bomb, the unit test becomes red.
Once the bomb change, the unit test shows the opposite of what a test is supposed to show - and now you have to fix the test itself. Because that’s what unit tests test - they test themselves. They don’t test the system.
An integration test that would bring in an actual bomb, diffuse it, and check if it’s diffused in a controlled environment where it can’t do damage by blowing up - is going to be more expensive to run, yes, but at least you will be getting a meaningful signal out of it. It’d be testing something of value. The unit test is cheap to run (although writing it was probably more expensive), but it gives you nothing. It’s completely pointless.
Awesome and well articulated response. Love it.
There are a few threads to pull here:
Is an integration test the best way to test the full e2e behavior of an api call? Yep.
Now, depending on the size (and architecture) of your system, the full test suite of into tests could take like, 10 hours.
And even then, you’re STILL probably mocking something (direct seeding bombs into the db). Full setup of all life cycles of all your entities using their associated entities (bombs, wires, wire clippers, bomb diffusers, their rank, their bosses, their diffusion history, etc…)
So they’re expensive, and if you really look you’re probably still cheating some steps anyways.
Another thread to pull on is what are you mocking in your tests to begin with, and if they’re not resulting in valuable test results then that goes back to one of my original points being that you might have suboptimal patterns in your production code.
Like, what logic governs bomb diffusion and where does it live? Are you mocking the right thing? If you have to mock the wrong thing… WHY? The ritual of writing those tests give you the first whiff of a potential smell.
I tell my guys not to test implementation: test behaviour. Test contract adherence. If that’s hard, no problem, message me let’s review it. Maybe a behavior they’re trying to test legitimately should be an int test. More often than not, their design is demanding to mock something that should be decomposed further, and then composed with dependency injections that are where the units that should ACTUALLY be mocked are the things that get mocked and injected, so the unit tests are actually testing the BEHAVIORS we want to pin rather than implementations. Composition and single responsibility principal are what enable unit tests to pull their weight.
Edit: I’m so passionate on the subject that if you scribbled up a scratch example and pinged me a github link I’d genuinely review it.
Now, depending on the size (and architecture) of your system, the full test suite of into tests could take like, 10 hours.
You’ll eventually have to run these 10 hours no matter what. If you only run the unit tests you won’t be able to tell if your code actually works, and if your full e2e suite passes then you won’t learn anything of value from running the unit tests - if one of them fails you can be fairly certain that it is that unit test itself that is broken, not the product.
During development, you don’t need to run the full test suite. It’s usually quite trivial to identify a single integration test that checks the parts you are touching, and then you only have to run it to see the effects of your changes.
And even then, you’re STILL probably mocking something (direct seeding bombs into the db). Full setup of all life cycles of all your entities using their associated entities (bombs, wires, wire clippers, bomb diffusers, their rank, their bosses, their diffusion history, etc…)
Integration tests rarely (if ever) need mocks. If they need Test Doubles at all, they’d typically be _Fake_s rather than _Mock_s. But even that is not always needed - an integration test can often just use non-production versions of the real dependencies.
So - if your real software typically runs against a database that sits on a powerful server and has tables with billions of rows, the e2e tests can use the same database engine but run it locally and only put a few dozens of rows in these tables. This setup is quick and cheap to set up and tear down while still being faithful to the production setup - maybe not 100%, but orders or magnitude more faithful than a unit test’s mock that just compares the SQL commands given to it with the ones preprogrammed into it.
Another thread to pull on is what are you mocking in your tests to begin with, and if they’re not resulting in valuable test results then that goes back to one of my original points being that you might have suboptimal patterns in your production code.
Like, what logic governs bomb diffusion and where does it live? Are you mocking the right thing? If you have to mock the wrong thing… WHY? The ritual of writing those tests give you the first whiff of a potential smell.
My argument is that this is more about the “problem domain” than about the “solution domain”. Some field of software work very neatly with unit tests - general libraries are a good example. Other fields are a very poor fit, and trying to shoehorn them into using unit tests - even worse, shoehorning them into using mostly unit tests - will inevitable result in a nightmare of mock maintenance.
I tell my guys not to test implementation: test behaviour. Test contract adherence. If that’s hard, no problem, message me let’s review it. Maybe a behavior they’re trying to test legitimately should be an int test. More often than not, their design is demanding to mock something that should be decomposed further, and then composed with dependency injections that are where the units that should ACTUALLY be mocked are the things that get mocked and injected, so the unit tests are actually testing the BEHAVIORS we want to pin rather than implementations. Composition and single responsibility principal are what enable unit tests to pull their weight.
The problem is that unit tests “promote” aspects of implementation into behavior. Classic example - the exact syntax of the SQL query a function uses to obtain the data it needs is by all rights an implementation detail, but a unit test is forbidden from using a real database so it passes a mock that expects a very specific query - now it became a behavior.
That’s a lot, so I’ll be forthright that I’ll probably be giving a relatively terse and gappy response, but that’s more because of my own limitations as a mobile user.
Fundamentally every test unit, integration, ui, manual is still the same thing:
Given X do Y expect Z.
Mocks, fakes, whatever you want to call them, they’re fundamentally the same concept too: “given some idealized version of P”
All you’ve done is pushed where that line sits. If I update my company writer to prospend all my company names with “corp.”, and my company read API test seeds without it and something at your read service layer strips “.”, if I forget to update the “given” in my read test seed data, that bug stays invisible.
It’s the same class of issue. We just kicked the can down the road.
You could do writes and reads in the same test, but even then you’re still kicking the can down the road that your front end is calling the API correctly at all. Maybe that the buttons even render to an end user given their authority.
One might then conclude, then, that everything should be an automated UI test.
But would it catch a bug where the bottom collapsed to 1PX? Is that part of the test too? Maybe manual testing is the real way to go.
A further step back why do we even test anything at all? To provide some ultimate guarantee that everything works perfectly at all times? Is that the gate for a PR? A deployment to prod?
There are various gates, at different levels of certainty, and there is an economic scaling for the different levels of assurances. AND they scale with the overall complexity of the system.
And that isn’t a bug, that’s a feature.
It’s ALL behavioral contracts, up and down the pyramid.
There is a bang, there is a buck. Get the most bang for your buck. The distribution will vary by complexity and structure of your project.
That being said, I’ve said it before and I’ll say it again: int and UI tests make it very very easy to write fucking garbage code, the VALUABLE architectural pushbacks on poorly patterned code that unit tests avail is AT LEAST as much value to the overall tech debt accumulation of a project as the results themselves.
Please don’t read this as me shitting on int tests. It’s me trying to impress that unit tests are worth writing, and justifications for forgoing them usually are fundamentally driven by an underlying code smell. Sometimes the smell is “our architecture is already so fucked that writing a meaningful unit test would involve re architecting large swathes of our system”.
And in that case I’d say “it is what it is”, recalibrate the testing posture towards int tests, and accept that is the reality.
But I would NOT conclude on the blanket statement that unit tests SHOULDN’T be at the bottom of the testing period generally. Just that I’d inherited or failed to maintain a strong system design, and take the opportunity to reflect on how things came to that state for the purposes of becoming wiser.
Addendum:
Even int tests can reveal insane system architecture, just at a different layer and scale. I worked on a system at a fortune 500 company where the architecture was too far gone to even have meaningful integration tests. They were too far gone to even have automated front end tests. All material testing had to be done by hand. They had engineered their system with that staggering level of incompetetence. At the risk of making a slippery slope argument… It’s a slippery slope.
