Programming breakthroughs we need

Glue code is used to piece together libraries. I think it's a sign you used the right libraries and aren't reinventing. It's boring, but glue code essentially describes why your project is not the same as every other apo using those libraries.

Boilerplate is a thing that happens when libraries don't have sane defaults. It's one of the more unpleasant things about Docker et al. I wish we had a dev climate where something like Linux Standard Base could take off.

I find frameworks to be perfectly fine, as long as you break out of the "Perfectly fit the code to the vision in my head" model and go for "How do I make this product using only these high level blocks I have, without modifying them".

Frameworks are great as long as you don't fight them. Using a distro like Mint? Don't try to swap out core system services. Using a declarative web framework? Don't try to do some synchronous imperative stuff it was never meant to handle.

I get the feeling a lot of programmers really value creative freedom and don't want to feel like they are playing a rail shooter, just coding the one obvious thing the opinionated tools tell them to do, and then they have a bad time when they use tools that were specifically designed to remove any need for interesting code.

> The question is - if most of the work we want to do is about changing existing code, then why is the system not optimized for change by default? The code we write is optimized for reading the source text and its storage.

But it is optimized for change! That's exactly the reason line-by-line textual coding has been so hard to disrupt! Many, many non-text or augmented-text options for code have been tried, and they all fail exactly because they're not optimized for change! It's a pain in the ass to go and change some visual, graph-based program that someone else wrote, and an even bigger pain to keep it in source control. Text is the easiest thing in the world to change.

And I'll repeat the same refrain whenever the idea of non-text-based programming comes up: you're underestimating how long code spends in a non-functional state (cannot be unambiguously parsed into an AST), and how important that intermediate state is. Text handles that state beautifully, and every other option fails at it hard.

> Or even better, I want to specify a goal like "I want this function to not take this parameter" and let the system figure out how to transform the program to achieve this goal.

Or, even better, I want to specify a goal like "Make me a website that does cool shit" and let the system figure out how to achieve this goal. The author's stated goal is extremely ambiguous, and it's exactly our jobs to resolve that type of ambiguity. What exactly should the system to do? If you want someone else to figure that out for you, then you just don't really want to be a programmer.

>I can imagine a system that can combine small transforms into larger ones and use some AI magic to figure out how to compose them to achieve the specified goal.

So this whole article really is just "I'm sick of programming and I want an AI to do it for me". It's OK to be sick of your profession, but that doesn't mean other people are doing it wrong.

> If we instead focused on building the right model, we could better optimize that model for editing and the text could be just a view of that model. If the text is just a view, it doesn't matter how it's written. Let everybody customize it the way they want. I don't care if you put opening brace on a new line, I don't even want to care.

But we do just focus on building the right model. The text is not the hard part -- not by a long shot! That's why discussion and deep thought are where the real programming happens; translating it into working code is a very small fraction of the whole process. "The text is just a view" just kicks the can down the road -- a view into what? Whatever that underlying thing is (some awful clunky graph-based model?), that's now your language. Of course you have a language somewhere.

Again I get the impression the author is just sick of being a programmer.

> Software testing doesn't work

Got it right there!

> We have some promising ideas. Some examples include strong type system, fuzzing, snapshot tests and sanitizers.

Okay, look. There's a lot of different times when a software error can be detected and fixed -- a whole spectrum. Let's be real generous about the categories of things "software error" can include here, including inefficiencies or building something the user doesn't actually want. The lower on this list we find errors, the more costly it is to fix them. Our goal is to push up where we detect errors as high as possible in the spectrum. It looks something like this (details and order may vary):

  - Initial ideation  ["Facebook for dogs? That idea sucks."]
  - Requirements analysis  ["That's not actually how we calculate that metric."]
  - Conceptual system design  ["Wait, these parts don't fit together like that."]
  - Low-level design ["Crap, a loop won't work here, I need a different flow."]
  - Brain-to-fingers typing  ["Whoops I almost typed 'elesif'"]
  - Immediately post-typing  [Red squiggly line under 'elesif']
  - Re-reading  ["Wait that should be i-1, not i"]
  - Compile time  ["SYNTAX ERROR: Unknown identifier 'elesif'"]
  - Unit test time  ["Assertion failed: expected 7, got 8"]
  - Code review time  ["You didn't handle the case where N is negative"]
  - Merge / integration test time  ["Oh crap, David's commit broke my commit! How the hell do I merge this?"]
  - Internal manual testing time  ["You need to tighten up the graphics on level 3"]
  - Production  ["The users say the application keeps crashing when they run this report! Fix it!"]
  - Years later/never  ["Turns out the last 10 years of analysis that we used to make business decisions were wrong."]

Testing is actually quite low on the list, and there are lots of ways to move more errors higher up that list, such as strong typing, good abstractions, and really clean code. It's also tightly coupled to the implementation itself, so a conceptual error in the code can also exist in the test's assertions. I'd much rather write test that is obviously correct (errors caught at re-read or compile time) than write tests; only when you can't do you fall back to that lower-level option.

Dennis Ritchie wrote C for himself.

Thanks for the response. I think we probably ultimately agree. I was taking aim at that second group you outline with my rant.

I had always assumed punch-tape was encoding some other representation of code than text until I did the research for my blog post. I think text is here to stay and I don't have any real problems with that. Where my tools offer designers or visual editors for code/UIs I still prefer to use text.

As an on-ramp to programming nothing quite beat opening up an HTML file in Notepad (or text editor of choice), making some changes and seeing that your header now flashed and was red.

I do think however that much like digging on a beach with a plastic bucket and spade is fun when you are young and carefree; when you're being paid to dig holes you want the biggest shiniest JCB you can get.

I am mainly reacting to the second group who curl their lips with disdain at the idea of doing anything other than coding in Nano or whatever pure text environment. They seem to see programming as a priestly sect dedicated to text like Lindisfarne's monks and people who don't know their Cherry Reds from Browns as fake/noob/impostor programmers.