So rewriting gets cheaper and cheaper. New features fall more or less into the same category. Refinement doesn't.
The question is: Will we live in the world of breathless re-implementation, new features every week, rebranding every quarter or will we eventually discover the value of stability, software that does its thing more or less optimally for decades?
Recent examples of things like curl or Firefox are interesting in that regard. Will we end up with a nearly perfect HTTP user agent and stick with it for decades?
It certainly helps to be neighbor with an economically strong but demographically weak and overly beaurocratic country that hungers for eager, competent workers.
Who said that? It certainly helps. Poland has close trade and manufacturing ties to Germany and has rightfully developed from a "cheap" image to "quality that's still affordable" image.
> The point of types is to prove the absence of errors
Maybe for you. Originally static typing was to make the job of the compiler easier. Dynamic typing was seen as a feature that allows for faster prototyping.
And no, dynamic typing does not mean untyped. It just means type errors are checked at runtime instead of compile time.
You can have strongly typed dynamic languages. Common Lisp is a very good example.
Weak typing is a design mistake. Dynamic typing has its place as it allows you to have types that are impossible to express in most static type systems while avoiding the bureaucratic overhead of having to prematurely declare your types.
The best languages allow for gradual typing. Prototype first then add types once the general shape of your program becomes clear.
You seem to have no idea what you're talking about. Type theory is a thing, much older than any compiler. And soundness has a meaning.
> It just means type errors are checked at runtime instead of compile time.
This is a fundamental misconception. A type checker proves the absence of errors. It doesn't check for error conditions. That is: A program that isn't (cannot be proven to be) well-typed can very well be correct. But a program that is well-typed is guaranteed to be free from certain errors.
What you call "dynamically typed", in contrast, is comsequent just value inspection and stopping the evaluation/execution early. A program that has been executed successfully often is not necessarily correct.
Interestingly enough, I have never needed them there. Granted, I have written a few orders of magnitude less Haskell than I have C++. Still, the difference is worth interrogating (when I'm less sleep deprived).
Clearly, there is a thing missing here: Regulations. If you have strong regulations on how you can make money, you cannot sustainably have biz antagonize user. So in that case biz just becomes a filter for users that actually are willing (and able) to fund your software. That's a good thing.
Obviously, our regulations aren't perfect or even good enough yet. See DRM. See spyware TVs. See "who actually gets to control your device?". But still...
No, that's malicious compliance. If the owners of those websites would just stop ignoring visitors' right to privacy they wouldn't be showing those banners (yes, I know the website of the EU also has such a banner, lazy devs are lazy).
Most people have no idea how hard it is to run static analysis on C/C++ code bases of any size. There are a lot of ways to do it wrong that eat a ton of memory/CPU time or start pruning things that are needed.
If you know what you're doing you can split the code up in smaller chunks where you can look with more depth in a timely fashion.
Is it? If "others with AI" deliver what you consume, it should also make it easier to deliver more than you consume because what you consume becomes cheaper.
Maybe a part of the anxiety is the realization that much if what was delivered by well-paid people before AI is actually not something the very same people want to consume?
That’s fine. New opportunities to provide value will emerge. If software becomes oversupplied, fewer people will enter that field and move to other areas where value is needed. If you only want to add value in the software space, then yes, it may be a problem.
If now only everyone who is talented at crafting software (or any other job that might be replaced), but who is out of a job could magically be as talented at something else, and enjoy doing that other work, then we would have no problem. But one issue is, that often significant time goes into becoming good at what one does. Switching has a very high personal cost in terms of time and having no income for a prolonged time.
Even worse, people are not the same as when they were younger. They may have less ability to learn. Almost certainly they have lower internal motivation and enthusiasm, since their career of choice was just taken from them. Job retraining programs are probably a big hint here. They have a poor track record.
I produce software too but I starting producing food recently. I feel like it really takes edge off my AI-related anxiety. (I also realize I'm more rural than most of HN).
If I am not mistaken, the verification is problematic here. It's run too late.
A piece of code that satisfies a single test will most likely not be probable to adhere to the spec.
Worse, the whole spec can only be correctly implemented in total. You cannot work iteratively by satisfying one constraint after the other. The same holds for the test cases. That means that satisfying the last test or fulfilling the last constraint will take much more work than the first. The number of tests passed is not a good metric for completion of the implementation.
That would be great, but Rust relies on compile-time monomorphization for efficiency (very much like C++, if you consider templates polymorphic functions/classes).
This means that any Rust ABI would have to cater for link-time specialization. I think this should be doable, but it would require a solution that's better than just to move the code generation into the linker. Instead, one would need to carefully consider the usage of the "shape" of all parameters of a function.
I wonder if we look at it from a too narrow perspective. We use the C ABI because it's the only game in town. We should be aiming for a safe cross language ABI. I'd love to make Rust, C, PHP, Swift, Java and Python easily talk to each other inside 1 process.
It should extend the C ABI with things like strings, arrays, objects with a way to destruct them, and provide some safety guarantees.
As an example, the windows world has COM, which is at the core pretty reasonable for its design constraints, even if gnarly sometimes.
> It should extend the C ABI with things like strings, arrays, objects with a way to destruct them, and provide some safety guarantees.
> As an example, the windows world has COM, which is at the core pretty reasonable for its design constraints, even if gnarly sometimes.
Yeah, and we had CORBA. Gnome was originally not a DE - the acronym stood for Gnu Network Object Model Environment or similar.
I programmed in CORBA in the 90s. Other than being slower than a snail on weed, I liked it just fine. Maybe it's time for a resurgence of something similar, but without requiring that calls work across networks.
You'll find that all of these languages ultimately build FFI on top of C ABI conventions, though Swift's own internally stable ABI uses a lot of alloca() to place dynamically sized objects on the stack, in a way that's somewhat unidiomatic (the Rust folks are trying to back out of their alloca() equivalent). You can even interface to COM from pure C.
The question is: Will we live in the world of breathless re-implementation, new features every week, rebranding every quarter or will we eventually discover the value of stability, software that does its thing more or less optimally for decades?
Recent examples of things like curl or Firefox are interesting in that regard. Will we end up with a nearly perfect HTTP user agent and stick with it for decades?