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.
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.
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.
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.
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.
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?
> You upgrade the libraries your website depends on, or add a dependency, and this new code happens to depend on that native prototype. Only you replaced it with your custom method, and that method likely doesn't have the exact same behavior. You broke that new code and fixing this might not be trivial because uses of your custom method are sprinkled everywhere in your code.
He was suggesting adding a prototype method, not replacing one. Unless the library your using is also adding prototypes, I can't think of an issue with this. Sure, if a new version of JS ends up using these names then things could break, but I'd bet this won't cause him a problem in actuality.
I couldn’t help but think this as well. I understand wanting software that feels snappy, but this is hardly a problem. Instead of trying to convince the reader that we should care about this, it would be nice if the writer admitted this is an inconsequential personal preference.
Author here . If you'd like an intro to FoundationDB, you can take a look at this blog post I wrote. This CI framework was created during the writing of this post.
It depends on what you mean by "sucks". I don't think anyone here is denying that it's often the best tool for the job. You SHOULD learn CSS if you want to be an effective UI programmer simply because you'll encounter it everywhere. But the quality of the language should still be critique IMO.
This seems like a lack of experience. The more I work with LLMs, the better I get at predicting what they’ll get wrong. I then shape my prompts to avoid the mistakes.
At risk of sounding like a jerk, this post is just raw data. The “implication” you brought up and the rejection of said implication was all done by you.