Automating programming: AI is transforming the coding of computer programs

Before Stackoverflow, people were answering questions on USENET newsgroups without any award of points.

And before USENET and the internet, hobbyists would gather to trade advice on building home computers. E.g.: https://en.wikipedia.org/wiki/Homebrew_Computer_Club

The common theme isn't the points... it's that people like to be helpful and share knowledge.

>Open source is another one: here’s my code that I’ve worked so hard on, spent countless hours on - please have it for free, my labor is worthless.

There are multiple motivations for open source. In my case, I did it because I could get more value from the community's enhancements than the "free code" the community got from me.

>It’s like they’re actively seeking to bring their own value down.

Neither of your 2 examples look like erosion of labor value. On the contrary, it shows that not every activity associated with programming has to be driven by the exchange of money.

Or, at least, it's only "labor" in the same sense that literature or painting is labor.

Does it seem strange to you that writers or painters would want the world to see their work, even for free? It doesn't seem strange to me.

Programming is the same.

It's true that software developers need to eat too but we need to figure out a way to do so without making the world more cumbersome, transactional, and shitty.

If you can't understand why someone would decide to offer their help for free then at least try to be thankful.

Basically what motivates good engineers is a good problem. If we can meet our basic needs we give the rest away for free. Companies/entities have been using/exploiting this for years. The gamification points are lame (I agree) but I believe there is a general desire to contribute to the common good and give back to the community.

https://thecreativeindependent.com/people/philip-glass-on-co...

That's weird logic. Presumably you wouldn't create something you consider worthless - you'd create it because you needed it.

When I participated on Stack Overflow, for me it was a combination of learning a lot by answering other people's questions and getting a kick out of demonstrating my expertise.

Just take my day today: interpreting the client's specs and internally communicating and planning a minor change in the context of a few parallel release paths, discussing a few tweaks to a piece of code with a colleague carefully weighing effort, impact on partially rolled out tests, and future flexibility (making best guesses as to where things are going), and analysing / fixing an issue in a piece of code which design delicately balances simplicity, robustness and performance.

Call me naive but I don't see an AI taking over before reaching (or nearing) general AI. Nor do I see how someone that's not a competitor already become one just by having access to Stack Overflow, or even a tenfold of it.

Open source is a great way to market yourself. If I have some really valuable code, then I'll keep it for myself. If I think it would be more useful and gain traction as an open source project then I might publish it and in that way position myself as the top expert on that software.

A lof of businesses are actively using, publishing and contributing to open source. Not because they don't want to make money, but because it's the way to make money.

The opposite is true. Analogy: Volvo invented the three point seatbelt. To maximize the value of the invention, they gave it away free to use.

Mass delusions are easy to propagate as they require little emotional nuance; a salute, tattoo, incantation… those used to be enough to bind large groups.

Groups are out though. We’re leaning into enabling humans as atomic agents and automating away the utilitarian social obligations, and work of biological survival to get there.

How much "interesting, creative work" is there? Surely most of the work that most of us do, and that most of us are capable of and interested in, is not simultaneously interesting and creative.

I count myself as lucky and I have certainly had a more interesting working life than average but the proportion of that forty years of work that counted as both interesting and creative is probably, looking back on it, measured in single digit percentage points.

If a machine does all the easy stuff how would I ever get enough practice to stretch myself to the difficult creative parts?

Law can be pretty verbose. Given half a paragraph, how often can an intelligence (artificial or natural) deduce what's next?

Of course the coding AI has the advantage that coders write (and publish) comments.

I dare posing that by the time AI takes over my job, it's gotten so advanced that I've got much more to worry about than just my job.

I'll leave it to the GP to give a lit review, but will say that CS has (always had) a hype-and-bullshit problem, and that knowing your history is good way to stay sober in this field.

> We've also seen GPT-3 and other generative text engines create genuinely interesting and innovative content.

Making things humans find entertaining is easy. Markov chains could generate genuinely interesting and innovative poetry in the 90s. There's a Reply All episode on generating captions for memes or something where the two hosts gawk in amazement at what's basically early 90s tech.

> They can generate new, genuinely interesting content and connections.

Have you ever dropped acid? You can make all sorts of fascinating content and connections while hallucinating. Seriously -- much more than when you're sober. Probably shouldn't push to prod while stoned, though.

Art and rhetoric are easy because there's really no such thing as "Wrong". That's why we've been able to "fake creative intelligence" since the 80s or 90s.

Almost all software that people are paid to write today is either 1) incredibly complicated and domain-specific (think scientists/mathematicians/R&D engineers), or else 2) interfaces with the real world via either physical machines or, more commonly, integration into some sort of social processes.

For Type 1, "automatic programming" has a loooong way to go, but you could imagine it working out eventually. Previous iterations on "automatic programming" have had huge impacts. E.g., back in the day, the FORTRAN compiler was called an "automatic programmer". Really.

For Type 2, well, wake me up there's a massive transformer-based model that only generates text like "A tech will be at your house in 3 hours" when a tech is actually on the way. And that's a pretty darn trivial example.

There is a third type of software: boilerplate and repetitive crap. Frankly, for that third type, I think the wix.com model will always beat out the CoPilot model. And it's frankly the very low end of the market anyways.

The following is a comprehensive introduction and survey of recent work in the field:

https://www.microsoft.com/en-us/research/wp-content/uploads/...

Regarding novelty, neural networks are excellent at interpolation but awful at extrapolation. What I mean by interploation is that the models learned by a neural network represent a dense region of cartesian space circumscribed by the neural net's training instances. The trained model can recognise and generate instances included in this dense region, including instances not included in its training set, by interpolation, but it is almost completely incapable of representing instances outside this dense region by extrapolation [1].

So basically what I'm saying above is that deep learning language model code generators can't extrapolate to programs that are not similar to the programs they've been trained on. Hence, no real novelty. But you can go a long way without such novelty hence my expectation that e.g. Copilot can be a nice boilerplate generator.

______________

[1] My standard reference for this is the following article by François Chollet, maintainer of Keras:

https://blog.keras.io/the-limitations-of-deep-learning.html

See also the second part of the series of articles where possible ways are proposed to address this limitation:

https://blog.keras.io/the-future-of-deep-learning.html

The latter is relevant to the conversation because the author basically proposes augmanting current deep learning approaches with a form of program synthesis.

Look up the work of Cordell Green. He invented the idea and built a company around it.

https://www.kestrel.edu/people/green/

I think what you describe is the task of putting together parts of a program according to a configuration. That's a related task and you could certainly see it as a kind of program synthesis, but because it's a common task that we know how to do well, it's not really what program synthesis research is focused on.

Some programming languages are definitely better suited to program synthesis than others. That's particularly the case with languages that have little of what I'd call "ceremony", syntax that's not really necessary to express the behaviour of a program, but are there to help the programmer organise the code, such as classes, maybe, or interfaces, say.

I don't know that metaprogramming was a dead end in AI. I hear that a lot for many subjects of AI research that are still active. I mean, if you asked machine learning researchers ten years ago about neural networks they'd tell you "it's a dead end", or "we tried that and it didn't work" etc. So, unless you're very knowledgeable about a subject of AI research my suggestion is to be cautious when extracting conclusions from a perfunctory perusal of wikipedia or blog posts etc. That's not where most of the knowledge is stored for such deep subjects as AI research.

When I post in conversations like this I do it in the hope that my comments will invite robust debate from knowledgeable contributors, that will challenge my assumptions and my knowledge and help me refine my understanding of the subjects I am interested in. This comment is really so much not that, that it hurts.

I'm pretty sure that as you say deep learning will be used for program synthesis, in fact it already has - the article above mentions a few applications and startups etc. I'm really curious to see how all this will pan out a few years from now. But the applications that are developed commercially are really trying to implement programming aids, rather than solutions to the full program synthesis problem, which, in a nutshell, is to be able to generate arbitrary programs from a specification of some sort.

I'm skeptical that deep learning can really solve this more general (and much harder) problem. The reason I'm skeptical is that neural networks are great approximators but they're not known for their great precision, I guess. With program synthesis the point is usually to really get a program that does what the specification says, no ifs and buts and no 80%-there's. I don't know how neural netwokrs can do in this, but I don't think the answer is "very well".

>> Anyway, I agree it's unfortunate that program synthesis has been overlooked in the latest AI code generation craze -- I've mentioned it to a few journalists when talking about things like Copilot but it doesn't tend to end up in the final article.

Well, thanks for fighting the good fight :)

You've piqued my curiosity, of course. Can you share one of the articles you mention?

And thus the ball is moved back to the human programmers court, as it has since Cobols sentences and paragraphs were supposed to allow managers and business analyst to write code.

>> Also, some forms of programming are super non-trivial to describe and are much more easily specified with input output pairs.

I agree of course, but then I would, wouldn't I? That's the kind of thing I'm studying...

The Gulwani et al. work behind FlashFill made a huge impression in program synthesis circles when it first came out.

To use a fast food example, I somewhat regularly go to a McDonalds when we road trip (I have kids, don't shame me) and they have ordering screens. It takes easily 5x as long to answer all of it's questions about permutations on the meal I want than to just say "gimme a #2 with Dr Pepper, no pickles" to a cashier.

Maybe if they put in a proper voice assistant it would be better. But the touchscreen is not in any way a superior experience.

The prices werent any lower they just had fewer staff. Presumably the owner thought they could collect higher profits.

It seems to have become quite normalized to put tip jars out for all sorts of businesses that aren't really service-based. Setting the expectation. Or putting on a tip line on the credit card receipt -- sure, you don't have to tip, but we want you to think you're abnormal if you don't.

I don't think switching to tablets would do anything to reduce the expectation of tips.

And it hasn't been 15% for years.

They don’t have to tip to start with. And the ones with the most problem with it won't, or will tip less.

And people go to places that aren't fast food because, at least in part, of service, which iPad’s don't provide the way servers do.

I'm not even convinced that the effect will be positive. A habit of blindly accepting copilot suggestions could lead to more bugs.

Yes, but the ideas that are being expressed in formal languages are much more complex and detailed than the ideas that are being expressed in natural language.

Writing some plausibly on-topic blog posts is way easier than writing even a very simple program, especially if you don't really know what you're talking about.

I don't deny that good suggestions are useful in coding. I am just not sure you can get these by mimicking other people's code without really understanding it.

I think the reason why code is different than natural language is that in code, the meaning of identifiers (words) is very dependent on the context of the specific codebase, and not nearly as universal as in natural language. Sure, there are words like personal names in natural language that change meaning depending on wider context, but they are not as common in the natural text.

So focusing on the names only, rather than for example understanding types of runtime objects/values, and how they change, can be actually actively harmful in trying to understand the code and making good suggestions. So I would believe that suggestions based on e.g. type inference would be more useful.

There is another aspect to this, text has inherently low entropy, it's somewhat easy to predict the next symbol. But if code has low entropy (i.e. there are universal patterns that can be applied to any codebase in a particular programming language), I would argue that this is inefficient from the programmer's point of view, because this entropy could probably be abstracted away to a more condensed representation (which could be then intelligently suggested based on semantics rather than syntax).

In other words, I think the approach assumes that the probability of the next word, based on syntax, is similar to probability of the next word, based on semantics, but I don't believe that's the case in programming languages.

That's a red herring. The "Eliza effect" has nothing to do with how toy-like ELIZA actual was, it is a lesson about how humans were very bad at evaluating its actual capability and insight. This continues to be true today, and is an effect with at least some impact on essentially any AI/ML system that people interact with.

This particular program included if/then conditionals, counting down in a loop, concatenation of a numeric value with text, and displaying output.

The system also attempts to optimize the number of programming instructions executed, in which case complexity can actually be considered based upon the resulting behavior, rather than LOC.