3,069 karma · joined July 22, 2022
"Nuance gets lost" well with centralized politics, the whole damn point gets lost.
That said, it's true that all the default decisions it initially took were not good. I had to keep insisting that the solution should scale linearly with number of workers. With every additional feature or adjustment, it kept adding shared processing bottlenecks, even though it required less than 20% extra code to keep it embarrassingly parallel. And that's with my entire codebase designed to be embarrassingly parallel from the ground up.
I think there's definitely a weakness there. That said, I think this industry tends to shun embarrassingly parallel solutions; equating it to overengineering. Personally, I find embarrassingly parallel solutions more elegant and robust especially in terms of state management. Doesn't require that much additional work. Everyone seems to be on board with Functional Programming which also helps to manage state more reliably (and often helps make code embarrassingly parallel) but my impression is that just aiming for parallelism gives you the same key benefits as FP. Allowing modules to hold state isn't the problem. The problem is that state has to be handled carefully. FP is kind of throwing out the baby with the bathwater, IMO.
I don't understand why anyone would want to buy something outside of its legal socio-economic context, when that thing's entire value is derived from that context and is otherwise worth very little intrinsically based purely on aesthetic value.
Any market value it sells for is then based on some shared mental deficiency which prevents people from understanding that.
- People believe they will be able to maintain code just as easily as they can generate it and it's hard to explain the asymmetry to people who haven't experienced it themselves.
- People don't feel like coding is a craft anymore so they don't care about how the code looks. They just want it to appear like it's working and don't care about anything else. As a team leader, you can't get people to overcome this deep sense of apathy they feel towards the code.
And yes, drones are a kind of tangible narrative device. If people didn't believe the narrative, they would just have 'surrendered' on day one of the war and the drones would never have been sent. They're just not smart enough and too proud.
French people are the smartest in that respect. Look at how many times they surrendered and look at how big France is still. France has territories all over the world and a dominant culture. They lost essentially every major war but haven't lost a thing in practice.
I wonder if Germans even learned the lesson yet... They have plenty of evidence to look at in their case. They're smart but also a bit gullible and their pride gets in the way. Heck, even a backward country like Iraq or Afghanistan can lose a war to the world's #1 superpower and still manage to keep everything.
How can anyone see this and believe that fighting a war makes sense? Most people are retarded and gullible.
With variable-rate mortgages, banks can insulate themselves from inflation risks, which they themselves create.
In reality, the group has little power over you as an individual. It derives most of its power from your own compliance. The compliance of others is a lesser factor in your oppression.
You don't need to believe in alternative fictions unless you created it. You just need to wait it out and pretend hard! Create your own fiction, exploit every loophole! Let the idiots realize their idiocy on their own and rebel on their own later once they realize they were fooled. You have to be a radical realist, wait it out and bare all the costs in the meantime. It's better to bare the pain of system dysfunction for decades than to go along with it and find yourself at the front of the firing line later, fighting against what you helped to create.
If the fiction doesn't benefit you; there really is no incentive for you to believe it, and you shouldn't... You can be sure it's benefiting someone else. Do you want to die for the people who created this nightmare reality?
Her cancer was the exact same kind, down to every detail as the one which was tested in one of the most successful cancer trials in history; 100% success rate of full recovery with no surgery. Also, her specific genetic profile was an exact match for about half of participants in that trial. Essentially she was a textbook perfect candidate for immunotherapy so it's mind-boggling that it wasn't the first recommended option.
Every contrarian idea has to dismantle layer upon layer of existing beliefs to even be considered plausible. Many people will discard it outright because of how much it goes against their worldview.
The worst part is that people have also been conditioned to believe that long, detailed explanations are the result of delusions built up in social media 'echo chambers' or 'conspiracy theories' based upon fake news. LLMs will typically act as though they are concerned for your mental health if you provide a valid rebuttal to all of their points in such a discussion; they will say "Note what you did, you've made your argument unfalsifiable..." And I have to point out that its own mainstream version is also merely a narrative and also unfalsifiable and backed by even less evidence. The discussion has to be evaluated from first principles, taking into account empirical evidence, trends and incentives.
Incentives are much more important than simplicity of arguments to estimate accuracy. People will go to great lengths to obtain rewards and avoid punishment. Often, reality is complicated, not simple. Occam's razor generally isn't correct these days. Perhaps it was at one point in the past; those were simpler times.
From my own life experience and behavior, there are no simple explanations for anything I did or what happened to me; so I don't see why simple explanations are valid for anyone else. Occam's razor is essentially part of Hollywood's conditioning; conditioning people to people map their lived experiences into simple movie-like narratives.
To summarize 15 years of experience for you: You keep learning non-stop the entire time and after 15 years, you've got a really good high level view and you've built up an intuition for how to separate code in a way to minimize complexity whilst maximizing maintainability, reliability and performance... But you still miss stuff, miss some security vulnerabilities; because complex projects give you so many things to think about, it's a struggle to attend to everything. The one real advantage is that what you miss is generally easy to fix (thanks to your design intuition).
Even after 15 years, though, my feeling is that I'm still not skeptical enough. Solving problems with software is really hard. The more experience I have, the harder it appears to be. I'm a much better coder now than I ever was by an order of magnitude but I trust my own code less than I ever did. AI is can help a junior a lot; you just have to be humble about your output and be very critical of it.
Also, my goal since I graduated university, was to become a software architect but the position had become rare and mostly existed in bureaucratic organisations.
Now with AI, every developer is essentially a software architect.
My university major was 'software design'. When I came out of uni, I was shocked to learn that nobody cared about software design. Now software design is all any engineer has left to care about.
Once, I lost the master password of my password manager and the email to reset that master password was sent to my email inbox which required a password which was stored in my password manager which I was trying to regain access to... Catch 22... In the end, I got lucky that I didn't trust the entire security model and I had written down the password for my email on a sticky note on my desk!
The reason I lost the master password is because my company made me change the password every few months and didn't let me reuse old passwords and forced me to use a specific sequence of special characters. Eventually I couldn't remember which of the last 10 passwords I used was the latest one and which special characters were not allowed for which environment.
Is it a good thing to have so many processes that the user doesn't understand and often isn't even aware of?
If it's a security concern now, think of how bad of a problem it will be after AI is writing most programs that people use.
Almost nobody cares about intellectual activity. Not now, not before AI. People only care about status. That's all. The people who care about intellectual stuff are islands nowadays. They are all alone.
That said, in the past couple of month, AI has gained a lot of ground on the 'project management' front in terms of planning capability for a lot of simple to medium-complexity projects. It still needs a lot of help for more complex projects. Just today, it almost fooled me into making a major structural mistake but thankfully I asked the right question and saved myself a lot of future problems; it was essentially dancing around a critical point and giving me the illusion that the critical point had been addressed but only when I phrased my question in a particular way, I understood the core issue was not addressed.
But when I saw the photo of the krill, which is whales' main food source, I was like "AHA!"
But no, cattle it is... Though I guess this is probably a more recent development. Without humans, there would surely be a lot fewer cows.
Sometimes even something which sounds really simple, isn't simple at all once you consider all the possible formats, modes of interaction and all the things which could go wrong.
All the LLM issues I face are related to incorrect priorities, choosing the wrong tradeoffs, UX and UI flaws or incorrect assumption about requirements.
Why would I want to fill up my context window with useless type annotations and waste tokens generating them? Just like I don't want to be distracted thinking about types when I code, I don't want my LLM to be distracted by them either. Also, I don't want to waste time waiting for the transpiler to build. I don't use bundling nowadays - Not necessary if I use plain JS; instead I preload all my frontend libraries and distribute them individually; better for caching and they still download in parallel. I don't have to invalidate the entire bundle cache just because I updated one script.
Also, I don't want my LLM to generate over-engineered enterprise code. My priority is to get stuff done, not achieve job security.
Although I was keen to get involved in Deno in the beginning and I'm a fan of Ryan Dahl, I just couldn't shake my preference for vanilla JavaScript; it was already the case before LLMs took over, but now even more so after LLMs. But I like that Deno is an option which users of my open source projects can use.
That said, Deno deserves the credit for making TypeScript as painless as possible. Juggling different Node.js and tsc versions and tsconfig versions was a major pain in the neck. I like how Deno forces a specific TypeScript version. None of that nonsense.
When I worked with blockchain before, that was another level because each node had to talk with thousands of other nodes; each running different versions of the code and they had to propagate messages throughout the network in a secure and scalable way without missing any nodes or reaching the same node twice (spam vulnerability) so your code is basically talking to different versions of itself which feels a bit like recursion, but harder and with a network between which adds latency and errors; and you can encounter tricky issues like message storms among others where the nodes keep bouncing and replicating a message between themselves. Or if any kind of propagated processing doesn't deduct tokens, then that's a massive spam vulnerability. Also, if the peer-discovery algorithm is structured, then the network is vulnerable to eclipse attacks. Also, most parts of the code had to be fully deterministic and idempotent or else some nodes could fork off the network. Stamping out non-deterministic, non-idempotent logic is hard work, especially when you have to do it across multiple distinct nodes running on different machines operated by different people! Paradoxically, some parts of the code actually benefited from being non-deterministic like the P2P networking and peer discovery logic since that made it harder to game/carry out eclipse attacks. So you need deep, nuanced knowledge to get it right.
For the kinds of systems I work on, loose coupling + high cohesion is mandatory, but building reliable systems is still difficult and time consuming regardless.
That blockchain project I mentioned wasn't architected well in the beginning and it was a nightmare to work with; it had to be rewritten because it was literally impossible to add new features on top (in a reliable way); nobody could do it, even the people who were there since the beginning couldn't explain how it was working. Making it modular allowed us to make it reliable and extensible but each module was still difficult to work on in the sense that every feature required careful discussion and debate with team members because so many tradeoffs had to be considered.
I think probably the people whose ancestors lived there for hundreds of years (as mine did) probably became immune to all these nasty mosquito-borne diseases through natural selection. Dengue sounds really serious when I read about it now.
In fact, for many complex projects, it's essentially impossible, even with AI.
Eventually, you get to a point when you have every feature you could possibly want but the list of tradeoffs is long and yet not worth trimming.