Hacker News Reader

>2/ The boilerplate is what bothers me the most (as someone who believes in the declarative approach to software engineering). The future for programming and programming languages should be an attempt to step up to a higher level of abstraction, that has been historically the way we step up to higher levels of productivity. As applications get larger and code-bases grow significantly we need abstraction, not more boilerplate.

Just the other day someone on copilot threads was arguing that this kind of boilerplate optimizes for readability... It's like Java Stockholm syndrome and the old myth of easy to approach = easy to read (how long it took them to introduce var).

I've always viewed code generators as a symptom of language limitations (which is why they were so popular in Java land) that lead to unmaintainable code, this seems like a fancier version of that - with all the same drawbacks.

Code generators = out of practice, out of mind

Tools like xsd or T4 (in the .NET ecosystem) are great time-savers, but you would never consider directly modifying the code they generate. You would leave the generated code untouched (in case it ever needed to be generated again) and subclass it to make whatever changes you intend.

I think Copilot is so unfortunate because it's not building abstractions and expecting you to override parts of them. It's acting as an army of monkeys banging out Shakespeare on a typewriter. And the code it generates is going to require an army to maintain.

Linq2Db is a great example of T4 code generation that works. It creates partial classes from database schema. Together with C# I have strongly typed database access.

https://github.com/linq2db/linq2db

Even there I feel like code generators are just a band aid around the fact that metaprogramming facilities suck. If you would never modify the generated code why generate in the first place. You could argue that stack traces are easier to follow but TBH generated code is rarely pretty in that regard as well.

For example I think F# idea of type providers > code generators.

I'm all for abstracting. I like Rails, for example. That said, it gets truly difficult to add or change stuff at the more abstract layers. For example, adding recursive querying to an existing ORM is tough. And on the rare occasion that there is a bug in the abstract layer, debugging that from the normal application code is also tough.

I understand why some corporations prefer dumb boilerplate everywhere for some applications. If there is an outage it's usually easy to fix quickly. Sometimes it's not, if it's a issue in the boilerplate (say, Feb 29 rolls around and all of the boilerplate assumed a 28 day month) that means a huge update all across the system, but that rarely happens in practice.

I would say ORM is tough with code gen or with metaprogramming because it maps two mismatched paradigms (OOP and relational) and tries to paper over the differences.

I do agree on the debugging aspect - especially in dynamic languages - metaprogramming stack traces can be really hard to follow.

Awesome summary and thanks for trying it for the rest of us!

Copilot sounded terrible in the press release. The idea that a computer is going to pick the right code for you (from comments, no less) is really just completely nuts. The belief that it could be better than human-picked code is really way off.

You bring up a really important point. When you use a tool like Copilot (or copypasta of any kind), you are introducing the additional burden of understanding that other person's code -- which is worse than trying to understand your own code or write something correct from scratch.

I think you've hit the nail on the head. Stuff like Copilot makes programming worse and more difficult, not better and easier.

Stuff like Copilot makes programming worse and more difficult, not better and easier.

Copilot makes programming worse and more difficult if you're aiming for a specific set of coding values and style that Copilot doesn't generate (yet?). If Copilot generates the sort of code that you would write, and it does for a lot of people, then it's definitely no worse (or better) than copying something from SO.

The author of a declarative, functional C# framework likely has very different ideas to what code should be than some PHP developer just trying to do their day-to-day job. We shouldn't abandon tools like Copilot just because they don't work out at the more rigorous ends of the development spectrum.

The arguments that the GP makes are not based on a specific style or value of coding. Instead, they're based on the simple truth that it is harder to understand code that somebody else wrote.

In some cases the benefits of doing so outweigh the costs (such as using a stack overflow answer that's stood the test of time for something you don't know how to do), but with Copilot you don't even get the benefit of upvotes, human intent, or crowdsourced peer review.

>If Copilot generates the sort of code that you would write, and it does for a lot of people, then it's definitely no worse (or better) than copying something from SO.

Disagree.

Most SO copy-paste must be integrated into your project -- maybe it expects different inputs, maybe it expects or works with different variables -- whatever, it must be partially modified to work with the existing code-base that you're working with.

Copilot does the integration tasks for you. When one might have had to read through the code from SO to understand it enough to integrate it, the person using Copilot need not even invest that much understanding.

Because of these workflow differences, it seems to me as if Copilot enables an even more low-quality workflow than offered by copy-pasting from SO and patching together multiple code-styles and paradigms while hoping for the best; Copilot does that without even the wisdom that an SO user might have that 'this is a bad idea.'

I'm not firmly for or against the concept of Copilot, but it's fascinating to me that it will introduce an entirely new class of bugs. Rather than specific mistakes in certain blocks of code and edge case errors in handling certain inputs, now we're going to have lazy/overworked/junior developers getting complacent and committing code they haven't reviewed that isn't even close to their intent. Like you could have a backend method that was supposed to run a database query, but instead it sends the content of an arbitrary variable in a POST request to a third-party API or invokes a shell to run `rm -rf /`.

To me, the most interesting aspect is the new class of supply chain security vulnerabilities it will create. How people will act to exploit or protect¹ against those will be very interesting.

1 - I don't expect "not using a tool that generates bad code" to be the top option.

I don't think they work out past trivial applications. Any non trivial app requires an understanding of a much larger part of the codebase than a tool like Copilot is looking at at any one time.

Copilot does not understand the code in toto and is therefore really useless for debugging (70% of all coding) and probably useless for anything other than very simple parts of an app.

Any non trivial app requires an understanding of a much larger part of the codebase than a tool like Copilot is looking at at any one time.

I don't think that's important. Copilot, at least as it's been demo'd so far judging by the examples, is to help you write small, standalone functions. It shouldn't need to know about the rest of the application. Just as the functions that you write yourself shouldn't need to know about the rest of the application either.

If your functions need a broad understanding of the codebase as a whole how the heck do you write tests that don't fail the instant anything changes?

The reality of code is that stuff breaks when connected to other stuff, as it eventually must be for real work to happen. There's no getting around that.

Since that's where the work of programming is, debugging connected applications (not writing fresh, unencumbered code, a rare luxury), a tool that offers no help for that is, well, not much help.

While I accept most of the concerns, it's better than your comment suggests. I see some promise for it as a tool for reminding you of a technique or inspiring you to a different approach than you've seen before.

For example, I wrote a comment along the lines of "Find the middle point of two 2D positions stored in x, y vectors" and it came up with two totally different approaches in Ruby - one of which I wouldn't have considered. I did some similar things with SQL, and some people might find huge value in it suggesting regexes, too, because so many devs forget the syntax and a reminder may be all it takes to get out of a jam.

I'm getting old enough now to see where these sorts of prompts will be a game changer, especially when dabbling in languages I'm not very proficient in. For example, I barely know any Python, so I just created a simple list of numbers, wrote a "Sort the numbers into reverse order" comment, and it immediately gave me the right syntax that I'd otherwise have had to Google, taking much longer.

Maybe to alleviate the concerns it could be sandboxed into a search engine or a separate app of its own rather than sitting constantly in my main editor - I would find that a fair compromise which would still provide value but require users to engage in more reflection as to what they're using (at least to a level that they would with using SO answers, say).

Yeah, but... I mean, I guess we all agree that copying code from, let's say StackOverflow without checking if it really does what you want it to do is a bad thing? Now here we have a tool that basically automates that (except it's copying from GitHub, not StackOverflow), and that's supposed to be a good thing? Even if its AI is smarter, you would still have to check the code it suggests, and that can actually be harder than writing it yourself...

The big boost, that I think parent is alluding to, is for rusty (not Rust!) languages in the toolbox, where you may not have the standard library and syntax loaded into your working memory.

As a nudge, it's a great idea. As a substitute for vigilance, it's a terrible idea.

I suspect that's why they named it Copilot instead of Autopilot, but it's unfortunately more likely to be used as the latter, humans being humans.

Right, so it might occasionally be useful as a search tool for divergent ideas of different approaches to a problem, and your suggestion to sandbox it in a separate area works for that.

But that does not seem to be it's advertised or configured purpose, sitting in your main editor.

This is good stuff. As a search engine, it could very well be useful. As another poster pointed out, if some context or explanation were provided along with the source suggestions, its utility as a reference would really grow.

I totally agree with you that prompted help is a big deal and just going to get bigger. We have developed a language for fact checking called MSL that works exactly this way in practice -- suggesting multiple options rather than just inserting things.

One of the things that interests me about this thread is the whole topic of UI vs. AI and how much help really comes from giving the user options (and a good UI to discover them) vs how much is "AI" or really intelligence. I think the intelligence has to belong to the user, but a computer can certainly sift through a bunch of code to find a search engine result and, those results could be better than you get now from Google &Co.

If they're using something like GPT-3 on the backend, which they probably are, it probably can't provide any explanations or context (unless the output is memorized training data, like this); the output can be somewhat novel code not from any particular source, and while it might be possible to find relevant information on similar code, this would be a hard problem too.

EDIT: they appear to be interested in making it look for similar code, see here: https://docs.github.com/en/github/copilot/research-recitatio...

Hm odd takes here.

It's really weird for software engineers to judge something by its current state and not by its potential state.

To me, it's clearly solvable by Copilot filtering the input code by that repository's license. It should only be certain open source licenses, maybe even user-choosable, or code-creators can optionally sublicense their code to Copilot in a very permissable way.

Secondly, a way for the crowd to code review suggestions would be a start.

Practically every open source license requires attribution, if copilot has a licensing issue, training a model on only repositories with the same license won't fix it except for the extremely rare licenses which do not require attribution.

why not? it can just generate an attribution file or reminder

Because it's an opaque neural network on the backend, it doesn't know if or from whom it copied code.

Could they handle this by generating a collective attribution file that covers every (permissively licensed) repository that Copilot learned from?

Of course this would be massive, so from a practical consideration the attribution file that Copilot generates in the local repository would have to just link to the full file, but I don't think that would be an issue in and of itself.

Maybe? Might depend on the license, I doubt the courts would be amused.

Almost certainly a link would not suffice, basically every license requires that the attribution be directly included with the modified material. Links can rot, can be inaccessible if you don't have internet access, can change out from underneath you, etc.

(I am not a lawyer, btw)

Makes sense. Maybe something like git-lfs/git-annex would be sufficient to address the linking issue, but it seems like the bigger concern is whether a court would accept this as valid attribution. In a sense it reminds me of the LavaBit stunt with the printed key.

I think a judge could be persuaded that a list of every known human does not constitute a valid attribution of the actual author, even though their name is on the list. The purpose of an attribution is to acknowledge the creator of the work, and such a list fails at that.

Makes sense. That's probably the best interpretation here. Any other decision would make attribution lists optional in general for all practical purposes.

I've been in the business a long time and I just don't believe in generalized AI at all. Writing code requires general (not artificial) intelligence. All of these "code helping" tools break down quickly because they may be searching for and finding relevant code blocks (the "imperative hell" referred to by another commenter), but they don't understand the context or the overall behavior and goals of the program.

Writing to overall goals and debugging actual behavior are the real work of programmers. Coming up with syntax or algorithms are 3rd and 4th on the priority list because, lets face it, it's not that hard to find a reference for correct syntax or the overall recipe implied by an algorithm. Once you understand those, you can write the correct code for your project.

I do think Copilot has potential as a search engine and reference tool -- if it can be presented that way. But the idea of a computer actually coming up with the right code in the full context of the program seems like fantasy.

If we're coming up with potential uses, I think they got the direction wrong.

Don't tell me what to do, tell me what not to do. "this line doesn't look like something that belongs in a code base", "this looks like a line of code that will be changed before the PR is merged". Etc.

That would be fantastic! Imagine if it could catch common errors before you make them. So many things in loops and tests that we mess up all the time. My favorite is to confuse iterating through an array vs an object in JS. I'd love to have Gazoo step in and say, "Don't you mean, this, David?"

> It's really weird for software engineers to judge something by its current state and not by its potential state.

No, we're not afraid of Copilot replacing us. The thought is ridiculous, anyway. If it actually worked, we would be enabled to work in higher abstractions. We'd end up in even higher demand because the output of a single engineer would be so great that even small businesses would be able to afford us.

Yes, we are afraid of Copilot making the entire industry worse, the same way that "low-code" and "no-code" solutions have enabled generations of novices to produce volumes of garbage that we eventually have to clean up.

Sounds like projecting because thats not what I was referring to

I’m saying copilot can be better with very simple tweaks

Isn't the entire point of this to suggest code you may use, not to just blindly accept is correct without thinking?

5/ Boilerplate is easy to write but expensive to maintain in large quantities. Proper abstraction/templating requires careful thinking. Copilot encourages the first and discourages the second.

6/ Copilot learns from the past. It can only favor popularity and familiarity in code patterns over correctness and innovation.

I'm not sure we should throw the baby out with the bath water here due to the large blurbs it stubs in when when it doesn't have a lot to go on in mostly empty files. It is a preview release. They are working on proper attribution of suggested code and explainability [1]. Having a stochastic parrot that types faster than I do would be useful in a lot of cases.

Yes, better layers of abstraction could make us more productive in the future, but we're not there yet. By all means, don't accept the larger blurbs it proposes, but there is productivity to be gained in the smaller suggestions. If it correctly intuits the exact rest of the line that you were thinking of, it will save time and not make you lose understanding of the program.

In some areas complete understanding and complete code ownership is required but in a lot of places, it's not. If it produces the work of a moderately skilled developer it would be sufficient. I don't remember all code I write as time passes. If it produces work that I would have produced, then I don't see how that's any different that work that was produced by my past self.

It may feel offensive but a lot of the comments against it sound like rage against the machine/industrialization opponents and the arguments sound pretty similar to those made in the past by those that had their jobs automated away. I'm not sure we're all as unique snowflakes as we like to think we are. Sure, there will be some code that requires an absolute master that is outside the capabilities of this tool. But I'd guess there is a massive amount of code that doesn't need that mastery.

[1] https://docs.github.com/en/github/copilot/research-recitatio...

I think it depends on how you look at it.

For small snippets that have likely been already written by someone else, this probably works great. For those though, the time savings is probably at most 5-10 min down to 1 or less. The challenge is that that’s not where my time goes unless I’m working in an unfamiliar language.

As someone who writes a lot of code quickly, I’m usually bottlenecked by reviews. For more complex changes I’m bottlenecked by understanding the problem and experimenting with solutions (and then reviews, domain-specific tests usually, fixing bugs etc). Writing code isn’t like waiting for code to compile since I’m not actually ending up task switching that frequently.

This does sound like a fantastic tool when I’m not familiar with the language although I wonder if it actually generates useful stuff that integrates well as the code gets larger (eg can I say “write an async function that allocates a record handle in the file with ownership that doesn’t outlive the open file’s lifetime”). I’m sure though that this is what a lot of people are overindexing on. For things like that I expect normal evolution of the product will work well. For things like “cool, understand your snippets but also weight my own codebase higher and understand the specifics of my codebase”, I think there’s a lot of groundbreaking research that would be required. That is what I see as a true productivity boost - I’d make this 100% required for anyone joining the codebase. The more mentorship can be offloaded, the lower the cost is to growing teams. OSS projects can more easily scale similarly.

This is a little off topic, but your framework looks really interesting! How come you opted for building a functional framework in C#, vs using F#? I couldn’t see anything in the README about what was specifically frustrating about F#? I ask because we’re looking at introducing it at my company.

I cofounded a company in 2005, the primary product is a never-ending C# web-application project. As the code-base grew to many millions of lines of code I started to see the very real problems of software engineering in the OO paradigm, and had the functional programming enlightenment moment.

We started building some services in F#, but still had a massive amount of C# - and so I wanted the inertia of my team to be in the direction of writing declarative code. There wasn't really anything (outside of LINQ) that did that, so I set about creating something.

We don't write F# any more and find functional C# (along with the brilliant C# tooling) to be very effective for us (although we also now use PureScript and Haskell).

I do have a stock wiki post on the repo for this though [1]. You might not be surprised to hear it isn't the first time I've been asked this :)

[1] https://github.com/louthy/language-ext/wiki/%22Why-don't-you...

Ha, it's good to see I'm full of original thoughts.

That post in the wiki sums it up perfectly, much appreciated!

Generating code has never been a problem for developers :)

I'd be more interested in a tool that notices patterns and boilerplate. It could offer a chance for generalization, abstraction or use of a common pattern from the codebase. This is of course much harder.

Great points. Really makes me question why so many developers were excited / worried about programming jobs being automated away by this technology. I really doubt that many jobs are going to be displaced by what is at best an improvement to autocomplete/intellisense and at worst an unreliable, copyright infringing boilerplate generator. Also agree with point #3 - I could see Copilot steering devs away from new code patterns toward whatever was most commonly seen in the existing codebases it was trained on. Doesn't seem good for innovation in that sense.

I'm inclined to agree with you, and actually I'm rather mistrustful of even basic autocomplete ever since a colleague caught me using it without even looking at the screen!

But I wonder...

Is this a difference of programmer culture?

I think there are people who write successful computer programs for successful businesses without delving into the details. Without considering all the things that might go wrong. Without mapping the code they're writing to concepts.

Lots of people.

What would they do with this?

> What would they do with this?

Not get a job working for me ;)

More seriously, when I think back to when I was first learning programming - in the heady days of 1985 - I would often copy listings out of computing magazines, make a mistake whilst doing it, and then have no idea what was wrong. The only way was to check character by character. I didn't have the deeper understanding yet, and so I couldn't contribute to solving the problem in any real way.

If they're at that level as a programmer, to the point where their code is being written for them and they don't really understand it, then they're going to make some serious mistakes eventually.

If you want to step up as a dev, understanding is key. Programming is hard and gets harder as you step up and bite off bigger and more complex problems. If you're relying on the tools to write your code, then your job is one step away from being automated. That should be enough to light a fire under your ambition!

I also typed stuff in from magazines in the 80’s, and my fast but imperfect typing really helped me learn programming: I often had to stop, go back to the first page, and actually read the damned thing in order to make it work.

My question is would Copilot be useful if you could choose the codebase it would be drawing from? Almost as an internal company tool?

If you find yourself copying code someone else in your organization wrote rather than abstracting it to a function in a shared library or building a more declarative framework to manage the problem, something horrible has happened.

Sometimes boilerplate is unavoidable. As an example, how do you send a GET request with libcurl in C with an authorization header? I can't tell you offhand, but I can tell you the file in my codebase that does have it, because I've duplicated the logic for two separate systems.

So you are saying you would rather every project in the world have at least one--if not, thanks to making it easier via Copilot, many--copies of this code rather than one shared library that provides a high-level abstraction for libcurl?... At least for your own code, how did you end up with two copies of duplicated logic rather than a shared library of functionality?

> So you are saying you would rather every project in the world have at least one--if not, thanks to making it easier via Copilot, many--copies of this code.

Absolutely not, not at all. I'm suggesting that copying and pasting happens, particularly in the context of a single project.

> At least for your own code, how did you end up with two copies of duplicated logic rather than a shared library of functionality?

At what point is it worth introducing an abstraction rather than copying? Using my libcurl example, you can create an abstraction over the~ 10 lines of initialization, but if you need to change it to a POST, then you're just implemnenting an abstraction over libcurl, which is just silly.

If you have 10 lines of repeated code with one line changed to make it GET vs POST, introducing an abstraction isn't "silly": it is simultaneously both ergonomic and advantageous, as not only is libcurl's API extremely verbose (as it is a low-level primitive), if you ever need to add another line of code to that initialization--which totally happens over the years, due to various security extensions you might need to either enable or disable with respect to acceptable TLS settings, or to tune performance parameters related to connection caching, or to add a header to every request (for any number of reasons from debugging to authentication)--you can do it in one place instead of umpteen number of places. The libcurl API is itself a leaky abstraction of the underlying TLS libraries in places, so if you ever realize you need to switch SSL libraries (a space in which there has been absolute upheaval in recent years) you are going to reach for shared abstractions; and like... to take this to its ultimate conclusion: I use libcurl as a fallback for Linux, but if you want to correctly support the user's settings for proxy servers--which are sometimes needed for your requests to work at all--my code is abstracted so I can plug in entirely different HTTP backends instead of libcurl, such as Apple's CFNetwork (which you absolutely should be using if at all possible on iOS). You act like abstraction is somehow a bad thing or some inherent cost you want to avoid, when it should absolutely take you less time to wrap duplicated code into a function than to duplicate it in the first place, and if IDE features (including Copilot) are somehow making you think it is easier to throw a ton of duplicated code everywhere, that is part of the argument for why those features are dangerous... they are apparently undermining all the work people did onto refactoring code browsers that are designed to help users locally manage abstraction instead of mitigating poor architecture :/.

It would certainly alleviate the license concerns. If it was possible to train it to a level (that produces effective output), then sure.

As a thought experiment, I thought "what would happen if we trained it on our 15 million lines of product code + my language-ext project". It would almost certainly produce something that looks like 'us'.

But:

* It would also trip over a million or so lines of generated code

* And the legacy OO code

* It will 'see' some of the extreme optimisations I've had to built into language-ext to make it performant. Something like the internals of the CHAMP hash-map data-structure [1]. That code is hideously ugly, but it's done for a good reason. I wouldn't want to see optimised code parroted out upfront. Maybe it wouldn't pick up on it, because it hasn't got a consistent shape like the majority of the code? Who knows.

Still, I'd be more willing to allow my team to use it if I could train it myself.

[1] https://github.com/louthy/language-ext/blob/main/LanguageExt...

> legacy OO code

Aside from OO vs FP. A concern with that I'd have is that it would encourage and enforce idiosyncracies in large corporate codebases.

If you've ever worked for a large corporation on their legacy code, you know you don't want any of that to be suggested to colleagues.

This would enforce bad behaviors and make it even harder for fresh developers to argue against it.

> This would enforce bad behaviors and make it even harder for fresh developers to argue against it.

I think this is a significant point. It maintains the status quo. We change our guidance to devs every other year or so. New language features become available, old ones die, etc. But we're not rewriting the entire code-base every time, we know if we hit old code, we refactor with the new guidance; but we don't do it for the sake of it, so there's plenty of code that I wouldn't want in a training set (even if I wrote it myself!)

That would actually be potentially useful, it could do a kind of combination of autocompletion of internal libraries, automatic templates for common patterns and internal style/linting type tasks all in one. Certainly augmenting those other things.

It would be interesting how much code you would need before it was useful (and how good does it have to be to be useful? Does even a small error rate cost so much that it erases other gains, because so many of the potential errors in usage of this type of tool are very subtle?)

That sounds interesting, though it still feels like it would need work. Like a way to annotate suggestions with comments, or flag them. Definitive licensing shown for each snippet. A way to mark deprecated code as deprecated to the training algorithm, etc.

Neural net: ”It’s all in the training data, stupid.”

> programming languages should be an attempt to step up to a higher level of abstraction

Adding abstraction buries complexity. If all you do is keep adding more abstractions, you end up with an overcomplicated, inefficient mess. Which is part of why application sizes are so bloated today. People just keep adding layers, as long as they have room for more of them. Everything gets less efficient and definitely not better.

The right way to design better is to iterate on a core design until it cannot be any simpler. All of the essential complexity of software systems today comes from 40 year old conventions. We need a redesign, not more layers.

One example is version management. Most applications today can implement versioned functions and keep multiple versions in an application, and track dependencies between external applications. Make a simple DAG of the versions and let apps call the versions they were designed against, or express what versions are compatible with what, internally. This would make applications infinitely backwards-compatible.

The functionality exists right now in GNU Libc. You can literally do it today. But rather than do that, we stumble around replacing entire environments of specific versions of applications and dependencies, because we can't seem to move the entire industry forward to new ideas. Redesign is hard, adding layers is easy.

> Adding abstraction buries complexity. If all you do is keep adding more abstractions, you end up with an overcomplicated, inefficient mess. Which is part of why application sizes are so bloated today. People just keep adding layers, as long as they have room for more of them. Everything gets less efficient and definitely not better.

Presumably you're writing code in binary then? This is a non-argument, because there's evidence that it's worked. Computers were first programmed with switches and punch cards, then tape, then assembly, then low level languages like C, then memory managed languages etc.

Abstraction works when side-effects are controlled. Composition is what we're after, but we must compose the bigger bits from smaller bits that don't have surprises in. This works well in functional programming, a good example would be monadic composition: monads remove the boilerplate of dealing with asynchrony, value availability, list iteration, state management, environment management, etc. Languages that have first-class support for these tend to have significantly less boilerplate.

The efficiency argument is also off too. Most software engineering teams would trade some efficiency for more reliable and bug free code. At some point (and I would argue we're way past it) programs become too complex for the human brain to comprehend, and that's where bugs come from. That's why we're overdue an abstraction lift.

Tools like Copilot almost tacitly agree, because they're trying to provide a way of turning the abstract into the real, but then all you see is the real, not the abstract. Continuing the assault on our weak and feeble grey matter.

I spent the early part of my career obsessing over performance on crippled architectures (Playstation 3D engine programmer). If I continued to write applications now like I did then, nothing would go out the door and my company wouldn't exist.

Of course there are times when performance matters. But the vast majority of code needs to be correct first, not the most optimal it can be for the architecture.

That's an extreme form of simplification. Simplification is not performance optimization at all; it's removing non-essential complexity. You can still have abstraction and layers, monads and features. The thing is not to keep adding them when a refactor makes them redundant.

Like I say, our designs are ancient and lack features; we need to add more stuff to the code. But that will enable us to remove abstractions that were added only because our previous designs were crap.