Ask HN: What is the single top-priority software engineering problem?

1) computers handle bits and bytes, not information. If computers can be made to create, search, update and delete pieces of information, instead of bits and bytes, 90% of code would go away and life would be much easier for all of us.

2) programming is done wrongly and poorly: we write a program to do a specific job, without any proofs, with serial control flow, we compile it, we setup an environment for it, etc. Instead, we should write hierarchies of programs, each level of hierarchy should have its own proofs (i.e. the specifications should be part of our programs), control flow should be event based, programs should be running as soon as we write them in a live test environment etc.

In other words, forget files, processes, handles, databases, source files, bits, bytes, the command line, UIs etc. All these provide some level of abstraction that doesn't really scale to what we actually need. We need another level of abstraction: the piece of information.

Which should eventually include a piece of code that communicates with the outside world via events, and that code would be composed of other pieces of information, would be fully creatable, searchable, updatable and deletable just like any other sort of piece of information.

And UIs should be creatable, searchable, updatable and deletable pieces of information as well.

And a global communication language would replace all command line interfaces, UIs, and programming languages: we shall talk to our UIs with this language, and the UIs shall talk to us by using that language as well, using graphical representation when needed.

Let's take the simple concept of "array" or "list". Mathematically speaking, it's a very simple concept: integer numbers are mapped to objects.

But there are so many ways to implement this mathematical abstraction. Do you assume the integer numbers will be used in a sequence, like 1, 2, 3, 4, 5; or completely arbitrarily with possibly large gaps, like 1, 1000, 1001, 5000? Will it be accessed from different threads? Will it have a "create phase" when it is constructed in a single thread, followed by a "use phase" when it is accessed from multiple threads but read only? Will it be modified frequently, or rarely, compared to mere reading? Will you need to make copies of it for further independent modification? Etc.

Now, one possible way is to choose one specific answer, and make the standard "list" in your language mean exactly that. For some purposes it will be okay, for other purposes it will suck, and someone will create a library providing an alternative implementation; and users will complain why they need an extra library for something that should have been part of the language.

Or perhaps you will provide multiple implementation, and users will have to choose. And they will complain about this being too complicated.

You might also spend years trying to find one perfect implementation of "list", that will fare relatively well under all circumstances (never the best one, but also never the worst one).

It would be nice to have a language where the programmer wouldn't have to worry about performance of the underlying data types. Just use them as mathematical abstractions, and everything will work fine. Like, you would still have to worry about algorithmic complexity of your code, but you would not have to worry about accidentally using the existing stuff in a wrong way which is not obviously wrong (and would not be wrong for a different implementation).

This is different from merely allowing people to use both high-level and low-level concepts in the same language. This is about how to implement the language in a way that allows you to do high-level as much as possible, without suffering terrible performance consequences. And I don't mean consequences like "this will be 100 times slower", but rather "this implementation of list, when used in this specific way, will actually have exponential complexity where some other implementation would have been polynomial". Because ultimately each implementation has a weakness, and one must be chosen. And if you treat other pieces of code as black boxes, it means you never know whether you made a good choice.

I didn't say that.

> Usually because I learned new information, past choices turned out to have regrettable unforeseen consequences, etc.

Indeed, that "awful" code may have been written by the same developer from one or two years ago and now they're not comfortable with it anymore either.

Of course I'm being a bit hyperbolic, but what I'm saying is basically true and applies to pretty much everyone.

It's not all bad either, without some push towards renewal, we would be stuck with old ideas forever. The key point is that permanent renewal has a cost that the business must carry. Sometimes no renewal at all is the right business decision.