esailija

> When it comes to deciding where to place which code, I found a particular mantra very helpful: minimize code and maximize use cases. The idea is to have as many reusable software components as possible and to minimize the overall code within an organization.

You'll want to do exactly the opposite. This just leads to maximizing dependencies and grinding everything to halt as everything you could fix in 2 mins will take 6 months of waiting instead. Also literally anything can be "reused" with enough configuration and parameters, with them becoming the source of complexity and programming itself and at the end of the day it was a huge waste to effectively create a new programming language.

We don't know what humans are because they are a black box, we use some imperfect models that have limited usability in specific contexts.

LLM is white box that we know for sure is just a statistical next token predictor and nothing more. It's not a just a model of some black box we are trying to understand but the whole actual thing. That people think it's something more or could be something more is on them. If you understand that then you understand the flaws, limitations and vulnerabilities which is very useful.

There is no such thing that you can always keep adding more of and have it automatically be effective.

I tend to automate too much because it's fun, but if I'm being objective in many cases it has been more work than doing the stuff manually. Because of laziness I tend to way overestimate how much time and effort it would took to do something manually if I just rolled my sleeved and simply did it.

Whether automating something actually produces more with less labor depends on nuance of each specific case, it's definitely not a given. People tend to be very biased when judging the actual productivity. E.g. is someone who quickly closes tickets but causes disproportionate amount of production issues, money losing bugs or review work on others really that productive in the end?

There is more than molecules, neurons and synapses. They are made from lower level stuff that we have no idea about (well, we do in this instance but you get the point). They are just higher level things that are useful to explain and understand some things but don't describe or capture the whole thing. For that you would need to go to lower and lower level and so far it seems they go on infinitely. Currently we are stuck at the quantum level, that doesn't mean it's the final level.

OTOH, an LLM is just a token prediction engine. It fully and completely covers it. There is no lower level secrets hidden in the design nobody understands, because it could not have been created if there was. The fact that the output can be surprising is not evidence of anything, we have always had surprising outputs like funny bugs or unexpected features. Using the word "emergence" for this is just deceitful.

This algorithm has fundamental limitations and they have not been getting better, if you look closely. For instance you could vibe code a C compiler now, but it's 80% there, cute trick but not usable in real world. Just like anything, it cannot be economically vibe coded to 100%. They are not going back and vibe coding the previous simpler projects to 100% with "improved" models. Instead they are just vibe coding something bigger to 80%. This is not an improvement in limitations, it is actually communicating between the lines that the limitations cannot be overcome.

Also, enshittification has not even started yet.

I don't think so. Imagine it was vice versa, someone saying they knew JS and were weak at C/C++/Java.

Tests knowing about implementation details and testing the implementation details (which is the case 99.999% of the time if you use mocks) is more common than not. Even when the main value of automated testing is being able to change those very implementation details, that you now cannot do.

A whole bunch of work spent for no benefit or negative benefit is pretty common.

There is a difference between extrapolating from just a few examples vs interpolating between trillion examples

The problem is of course that there is no useful default behavior you can define when the trait is so isolated and generic.

Yeah there can be a ton of derivative and convenience methods that would either have to be duplicated in all implementations or even worse duplicated at call sites.

Call them interfaces with default implementations or super classes, they are the same thing and very useful.

Typescript does support it. You can do everything ts can in js with just jsdoc style comments. I actually prefer it.

Because it doesn't understand or have intelligence. It just knows correlations, which is unfortunately very good for fooling people. If there is anything else in there it's because it was explicitly programmed in like 1960's AI.

Actually the belief that you're good or "doing altruism" is exactly the kind of thing that would cause a person to do such evil things.

If we take bible metaphorically it's pretty smart because believing you are a inherently unworthy sinner will actually encourage you to do good things instead of the opposite which just causes people to do evil things and virtue signal.

Basically "But we're the good guys" <- that's how you know who is truly evil.

In reality even having a several "deal breakers" means you would need infinite options to find a match that doesn't have any of the so called deal breakers. Most guys don't get to pick from infinite, or even 10s of options. So you need to settle or stay single.

JITting alone will just make code slower. Even with many optimizations V8 eventually changed the "unoptimizing JIT" to an interpreter and now only JITs hot functions.

More extreme climate events have happened before a single co2 was emitted by human machines.

You could move goal posts again and claim that we shouldn't expect completely unprecedented extreme events from climate change, just that somewhat extreme events are supposedly becoming more common than before. Even if that was true it doesn't matter because it's not convincing and undeniable.

They said for active lifestyle.

> Why can't a "purely statistical" process have an understanding?

Once you understand long division, you can do it on infinite numbers without ever having seen the specific numbers. You can get this full understanding just from a handful of examples, no need for terabytes of them.

No matter how many examples of long division examples you fed to statistical model like GPT, there will always be infinite amount of numbers you can tell it where it will give the wrong answer*, unless you cheated and actually hard coded the understanding into the model.

If it cannot understand long division just from few examples it cannot ever understand it. The very reason it needs ridiculous amounts of data is precisely because it cannot understand. If you think it understands you simply aren't trying very hard to confirm otherwise.

* in a way that reveals there is no understanding of long division, obviously a human would also give wrong answer after being awake 100 hours writing numbers on paper

There are a lot of tools that have made developers far more productive than that and it has never resulted in reduction of demand.

It depends what you mean by confirm.

You can raise the bar for confirmation so high that you cannot confirm that you even yourself are not an automation. And you can lower the bar so that other humans are considered sentient.

But in the end, it is only about arbitrary decision where to place the bar for confirmation.

This is missing the point so badly I suspect this comment was generated by AI :D

Yeah I quit a few years ago and before quitting I very rarely had dreams. Now I have at least one dream every night. Also convinced a few people to quit and they reported the same thing.

There is a lot of truth to DRY but it has been distorted by becoming completely obsessed with it as if it was some end to reach, rather than any other property with its own tradeoffs.

And its not just developers, but even some companies are also obsessed with removing "waste" by sacrificing everything just to minimize any kind of seemingly duplicated effort without ever considering if it's actually cheaper to do so..

When DRY is shown as high ideal somewhere, how often do they also mention the tradeoffs like tight coupling and premature abstraction?

Yeah I admit I have wasted too much time solving edge cases that either never happen or happen but the effect is not so big of a deal that it was worth to handle it.

Data-based architecture means that you have all data about an entity in a single place. Even though if you analyze the domain and all use cases you find that there are slices of that data that never interact together.

Example is storing customers address and purchase history in same place, only because they "belong to customer" in a data sense. This is very bad because it leads to entangled architecture where everything depends on everything and you cannot extract truly independent modules. The project implemented like this simply cannot scale beyond a certain size.

So no, data is not important but how it is used.

Maybe the whole thing is sarcasm

No, it's because of CAP forces to make a compromise. If there was a way to be available and consistent there would not be overbooking. But they chose availability because losing sales is worse than dealing with overbooking.

Exactly same with Amazon, they will not bother checking that the product is actually available because then you will miss the sale when the warehouse service is down or slow, which it would be all the time because it has to be a single place of failure. Its better to refund orders for non existent items than to miss sales.

Consistency requires single source of truth which implies single place of failure. There is tremendous cost to it, it's not done for no reason like you say.

In any sane country it is the people who lay on highways or jump into train tracks who are criminals not the drivers or train operators.

Yeah no-one drives on a highway to conditions where there might be a human laying on the road waiting to be killed. Even self driving cars killed people in better conditions (person was walking on highway not laying there).

There are no crosswalks on highways. It's basically like someone sitting on a traintrack and blaming the train operator for killing them.

You lose security/privacy benefits. People in this thread pretend that there is one id type that is obviously better.

- UUID (all types) scale, sequential ids don't scale

- UUID (fully random) is completely secure and private. You cannot infer anything from it. As soon as you add anything to it ( like timestamp or counter), outsiders can infer things like how fast you are generating new objects

- UUID (fully random) cannot be abused by developers, which might skip creating timestamp columns and read it from the id instead

- UUIDs are slower, but as you see y's not for no benefits