Maybe so, but my father in law, who is a salesman and knows nothing about computers and programming still knows SQL.
SQL is a horrible language in the same way Excel is -- programmers hate it but the what makes it a horrible programming language to developers is what makes it accessible to non programmers.
As a programming language? Sure. As a way to work with relational data? It may be my favorite "language" across all domains because of the terse beauty. I am a self-taught, no CS coder but SQL is the one place where I feel like I get all the math I should know.
An opinionated, possibly hot take would be to call SQL "A more elegant weapon of a civilized age".
Maybe you’re implying that message passing makes compile-time validation of messages difficult? The types themselves are a solved problem, as long as you allow actors to fail when they receive a message they can’t handle.
What kind of codebase do you work on (number of lines?). How many tokens does your local context support?
Maybe your statement is true for smaller codebases and shorter conversations, but I’d be surprised if you actually achieve good results on millions of lines of code with a million token context.
Granted if your setup works well for your workload then that’s all you need.
I said "open weight" rather than "local". I mean, local if you have $240k to drop on GPUs but you can run Kimi k2.6 on a B300 cluster for ~$50/hour too.
This is a ridiculous analogy. Test the app. Read its source code. Developers could always write toxic instruction in your tools. AI may write inefficient or messy code, but it’s far from nefarious. “Asbestos” code is written intentionally by humans, not unintentionally AI.
That's a good way to guarantee nobody will use it. Who is going to test the app in a sandbox with godknowswhat kind of tooling needed to find malicious behavior and read the code? For a tool that's convenient once per decade?
At no point ever in history could you guarantee that third party code downloaded from the internet was not malicious without some sort of security review.
Software security assessments exist for this very purpose. You may personally lack the rigor to do this at home but those who have rigorous security processes absolutely do implement security reviews.
There is a whole industry of professionals who do this work.
The people outside of us didn’t care about your beautiful code before. Now we can quickly build their boring applications and spend more time building beautiful things for our community’s sake. Yes, there are economic concerns, but as far as “craft” goes, nothing is stopping us from continuing to enjoy it.
I'd add part of the craft is enjoying those minutiae, sharing lessons, and stories with others. The number of people you can do that with is going to dwindle (and has been for a long time from the tech sphere's coopting of all of it). That's part that I mourn.
Yes, it is true that companies are always hungry for more. But once again, those same companies never cared about beautiful code. They wanted us to build something that works as quickly as possible. In my experience, the beauty of programming was often enjoyed outside of work for this very reason, and we can still enjoy it outside of work for it's own sake.
Don’t Erlang/Elixir model all concurrency as actors, to some level of success. I was under the impression that it allows for quite a bit of deployment flexibility. Actors are addressed in the same way whether they’re on the same machine or not.
yes, to huge levels of success. It's not clear what kibwen is going on about, but local + remote actor concurrency transparency, while not without its complications, comes with massive development and deployment wins.
This reminds of me calorie tracking: you cannot perfectly capture the number of calories or macronutrients, but measuring does seem to help people loose weight. There are probably many loop holes where eating large amounts of certain food, with a certain margin of error, can leads to wildly incorrect estimates.
I wonder how much this analogy applies to carbon tracking? Does using a wide variety of foods help make the tracking more accurate because no single bad estimate becomes overrepresented? Can a similar approach be taken via a wide variety of cloud technologies being used?
Yea, I actually saw something similar in the early days of Infracost, when we didn't track that many price points. The % change and the directionality was really helpful for engineers. Then we iterated on the prices, added more coverage etc, and the accuracy increased to a point where people trust the output of Infracost more than the AWS pricing calculator. That was a cool learning moment for me.
>This reminds of me calorie tracking: you cannot perfectly capture the number of calories or macronutrients, but measuring does seem to help people loose weight.
This probably would explain the success of many fad diets if it were the increased awareness of the eating having an effect beyond the decision making about what to eat.
Totally - something I've been thinking a lot about...
I got pulled into these diets at one point in my life - I remember doing atkins, then went full vegan for a while, then went only meat lol
The diets were meh. But the cool thing was that I learnt so much about food in general! I honestly didn't know much about food growing up. I feel like I still don't know that much, but I know the basics, and i'm not afraid of digging into some of the details.
