Look at the rest of that quote:

> The human, computer pair, will also interactively suggest, confirm and fine tune specifications of mathematical properties and invariants at points in the the program.

That hasn't happened and as far as I am aware, is not even close.

> This will help the computer assistant to not only better understand the program but also to to generate real time, verification test runs using SAT technology,

Ditto.

> Interactive testing will eliminate whole classes of logic bugs, making most non ui code correct by construction.

Ditto..

So, 1 out of 4 predictions correct, which makes it worse than random chance?

Short summary of linked video: when your type system is powerful enough you can restrict the set of possible implementations to the point that the compiler can make a decent guess as to what the program should be to satisfy the type signature.

/s

I was just pointing out something fun.

Isn't that just the Rust borrow checker?

I'd like to see evidence / experience reports backing up this part. Certainly Copilot exists, but what I've read about it is pretty mixed.

I am not confident that there are programs I can write in Python, JS, or OCaml in one hour that nobody can write in Ada in ten hours, and programs in those languages in ten hours that nobody can write in Ada in 100 hours. I'm even less confident that they beat Smalltalk by as much. The exception is for very small programs: you can write things in Python in 5 minutes that nobody can write in Ada in an hour.

http://canonical.org/~kragen/sw/dev3/rpneact.py is maybe one example, which I wrote over the course of about 12 hours on January 2. It's a simple interactive calculator app that includes a general-purpose numerical equation solver; from the Python standard library it gets floating-point and complex arithmetic, regular expressions, and command-line editing. I don't think it would take me even as long as 120 hours to write it in C, which is roughly the same level as Ada but more painful to debug.

Similarly, http://canonical.org/~kragen/sw/dev3/lmu.py is a very limited MUD, where multiple users can connect, interact, and collaboratively build a textual world by creating rooms and other objects and setting their descriptions: sort of like a Wiki for interactive fiction, though without much richness of interaction. I wrote this between July 18 and July 24 last year, probably taking more than 20 hours in total. Writing it in C would have been slower but surely would not have taken 200 hours.

The main thing that's happened since 01987 is that computers have gotten a lot faster and bigger, so we can get by without as much attention to efficiency, and software libraries are also enormously more powerful. It's not that much easier now to write a SQL database than it was in 01987, but it's a hell of a lot easier to link in SQLite. It's not that much easier to write a regular expression matcher, but every modern language has one in the standard library already. Rendering Telugu text properly still involves a lot of hairy cases, but whether you're in a terminal or a browser, generally all you need to do is emit some UTF-8 bytes and you're golden.

In my opinion it does hold up, since indeed we can hardly even be 2x more productive in a barebone project with different programming languages, let alone an order of magnitude.

And what you are getting at is as far as I remember was the escape hatch mentioned by Brooks himself, that is the only significant improvement in productivity will come from the ecosystem. And I think we are behind even at that, in that we unfortunately have many NIH projects doing the exact same thing across language ecosystems, with not much interoperability. Eg. the JVM, Python, JS ecosystem has barely any shareable elements. Hopefully something like Graal’s polyglot might change it in the future.

The library ecosystem is a great bright spot: the cost of modularity has fallen to such a point that leftPad is its own NPM module. The fact that Python has a separate leftPad as the .rjust method on strings seems less significant than the reduction of duplication within each ecosystem. Historically if you wanted your library to be usable from anywhere, like D-BUS, you wrote it in C, and that's still a viable option; but Rust is shaping up to be a better alternative there.

I do think we can be more than 2× more productive in a barebones project with better programming languages, because I've been programming in assembly language this week, and it is pretty slow going. But I reluctantly came to the conclusion that Brooks was right: the big leap in raw productivity was from assembly to Algol 60, not Algol 60 to JS. (And, separately, from batch mode to interactive programming.)

EDIT. regarding these situations when it doesn't predict what I wanted, I feel that my brain is getting better at not focusing at that and moving on. At first it was distracting, now I subconsciously know that the provided solution might be wrong and I'm deciding faster if it's something I should choose or skip. Your tool is adapting to you and you're adapting to your tool to find the right balance :)

Of course, getting a new language to wide spread adoption is far from trivial, but that's a separate problem.

If we can do it, we should do it. All technology is progress. All technology improves the human existence.

https://NN-512.com

I profit from your obsolescence. I'm making you obsolete. I know what I'm doing. I'm making you worthless. The fact that you can fail to do even a basic check into me speaks volumes.

As someone who has suffered though inheriting a code base of excessive copy/paste with things done "pretty much the same way but changing only one thing" it's a nightmare to take it to diff and try and refactor out the common code. In my case I had to fix a bug in their copy/paste mess and found six separate copies of a whole functions worth of code duplicated.

I suspect part of the reason is for the initial developer it's a great feeling to churn out tons of code and it all kind of works without having to think how you make a block of code generic (avoiding temptation to just pass in a global state struct and dealing with function pointers in the worst cases etc) but having suffered the after effects, I implore you, PLEASE don't repeat yourself (DRY)

> manually code it into reusable function and use it repeatedly

Refactoring every place where you do x into a reusable function that does x is a boring repetitive chore.

You also get good at 'using copilot' just like you can be 'good at googling'. So if you not already doing it. Start now.

IMO. There's literally no point coding without it. You are completely wasting your time. However it has limits. It only helps you write code. Architecture is still down to you. If it could read your whole codebase rather than just the page you are on. And if you could supply it prompts via urls. i.e. preloads it with hints from other code bases. Then it will really become something else.

Except maybe that it is still not generally available.

Copilot is decent at speeding up some commonly occurring boilerplate in a common language, and pretty bad at anything else.

FWIW, there was also this https://challenge.openai.com/codex/leaderboard, and Copilot's 'time' was laughably bad compared to any decent human.

Does this mean that it couldn't potentially be a useful tool? No. I think it could be, and for some projects I would probably use it myself to speed up some laborious tasks. But currently, claiming it can help with anything remotely more complex is just untrue.

If you have evidence to the contrary, I'd like to see it.

edit.

- ok so you conceded in your sentence that it's faster and you would use it for that reason.

so your only disagreement is it can't help you solve harder problems?.

- the average dev is hitting stackoverflow 10x a day for that very reason. And that data is embedded in copilot. I've literally typed the name of functions I was going to have to spend 20 minutes googling to figure out how to achieve. typed the pseudo code comments and boom. copilot has done it before I even had to think. If not I just have to change how i prompt it by feeding it a few variable names or changing my comments. As I said. You can get good at using it. If copilot is crap it's because of the person using it. I.e. if you are looking for a bike and you google 'chicken sandwich' well. You aint gonna get a bike.

To me 'smarter and faster' means being able to solve harder problems + accurately reason about things, etc. (And not introduce security issues, which is a whole other thing...)

If it is just a replacement for stackoverflow, it's probably useful and it could save time, but I'm not sure it's 'smarter and faster' any more than any other feature in an IDE (you could also create a hotkey or something to search SO which would probably be just as fast too).

It's nice to reason about your actual problem and not the features of code.

JetBrains has their own experimental thing that is not enabled per default.

And there's also Codota and Tabnine.

Copilot is actually fairly late to the party here.

[1]: https://marketplace.visualstudio.com/items?itemName=VisualSt...

[2]: https://github.com/MicrosoftDocs/intellicode/blob/master/doc...