7 ms·

http://lambda-the-ultimate.org/node/4655#comment-73772 http://lambda-the-ultimate.org/node/4655#comment-73772 > ... the beginnings of intelligent ... assistant

by junon 5y ago

http://lambda-the-ultimate.org/node/4655#comment-73772 http://lambda-the-ultimate.org/node/4655#comment-73772 > ... the beginnings of intelligent ... assistants in our IDEs ... specialize (sic) in ... C/C++, Java, Mobile. They will have intimate knowledge of common APIs ... trained on tens of thousands of code projects pulled from the open repositories across the web (google code, github, bitbucket,...). In addition to having 'read' more orders of magnitude more code then any human could in a lifetime, they will also have rudimentary ability to extract programmer intent, and organizational patterns from code. ... The computer automatically bringing up example code snippets, suggesting references to existing functionality that could be reused. This person (Marc DeRosa) predicted Github Copilot within a margin of one year. Incredible.

chubot 5y ago
> Leveraging the strengths of the computer and human will lead to an order of magnitude improvement in programmer productivity. Interactive testing will eliminate whole classes of logic bugs, making most non ui code correct by construction. 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.
- kaba0 5y ago
  More like Brooks was the one being right (for like 3 decades now) with his ‘No silver bullets article’, in that we will not have another order of magnitude productivity change in programming after high level languages became a thing.
  - kragen 5y ago
    Brooks wrote "No Silver Bullet" in 01987. The examples of high-level languages he mentions in his paper are Ada, Modula (not sure whether the 01975 version or Modula-2), Simula-67, APL, Pascal, Smalltalk, Fortran, COBOL, PL/I, and Algol, and of these he thinks Ada is the most promising. Does his thesis hold up in the face of modern programming language advances? 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 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 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.
    - kaba0 5y ago
      I may not really get your point: are you trying to prove or disprove the original article? 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.
      - kragen 5y ago
        Well, I was hoping to disprove it, and then I looked at things I'd written recently in high-level languages, for which I had logs of how long it took me, and came to the opposite conclusion: Python might be more productive than Ada, but not by an order of magnitude. Of course someone else might be a much better programmer than I am in Python, but in all likelihood their improvement over me in lower-level languages would be even bigger. 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.)
    - laurentlbm 5y ago
      Why do you write years with a preceding zero?
  - chakkepolja 5y ago
    Availability of internet & resources like Stack Overflow can be considered a silver bullet, if you consider less proficient / junior programmers.
deleted 5y ago
[deleted]
Areading314 5y ago
Does anyone actually use Copilot day to day? How much time does it actually save?
- solidr53 5y ago
  Writing scrapers with it is also amazing. All from the puppeteer code, response interface and casting to a local class model. Very time saving indeed.
  - 37ef_ced3 5y ago
    How close are you to being fully obsolete?
    - deleted 5y ago
      [deleted]
    - bspammer 5y ago
      The correct response to becoming obsolete is to learn something new, not to fight the thing making you obsolete. Doing the latter is about as productive as yelling at the tide to not come in.
      - 37ef_ced3 5y ago
        Yes, I guess it's like complaining about nuclear weapons. Best to embrace them. If we can do it, we should do it. All technology is progress. All technology improves the human existence.
        bspammer 5y ago
        It's irrelevant whether the technology is good or bad. There's nothing you can do to stop it happening, so do you want to complain, or do you want to embrace the change and stay ahead of the curve?
        5y ago
ldjkfkdsjnv 5y ago
Its honestly not that hard to predict, with a bit of statistics and some insights into early deep learning, its obvious that alot of data with discernable patterns will produce good results.
- sandwichbop 5y ago
  What will programming look like in 2028?
  - Koshkin 5y ago
    2028 will be the year of Linux on the desktop, so…
  - craftinator 5y ago
    We'll all be using Deno, Crystal, Nim, and Zig, and lament with great nostalgia the days of Node, Ruby, Rust, and C/++.
    - nsonha 5y ago
      I understand that the value proposition of Rust is better C++, Deno is better Node. Crystal's "Better Ruby" doesn't sound like much given Ruby is niche anyway. What is it for Nim and Zig?
      - dosshell 5y ago
        Zig is a better C in many ways. Memory handling, error handling, security, but most importantly it can be used together with C. No need to port your code base just swap to zig and continue. Of course now you have a code base in zig and C... :/
    - Alekhine 5y ago
      What makes you think Rust will be out the door? None of those languages are as fast, while also being memory safe
lasc4r 5y ago
FYI, specialize is the American spelling.
- junon 5y ago
  Yep, I'm an American. It was missing the 'D' on the end ("specialized") hence the (sic).
lelanthran 5y ago
Cherry picking only the accurate prediction makes it seem like the predictor is really good! 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?
- CardenB 5y ago
  Can you explain how this is worse than random chance?
  - GuuD 5y ago
    It is, for people who think that the chance of meeting dinosaur on the street is 50% (you either do or don’t) /s
    - jhgb 5y ago
      Does that account for multiverses?
  - maest 5y ago
    They're just using a flat prior, which is maybe inappropriate.
    - Sharlin 5y ago
      A flat prior over a probability space with only four possible events, but in reality there are of course many more possible events from which those four were originally picked.
- still_grokking 5y ago
byteface 5y ago
Well people were making API calls to stackoverflow at the time to pull the most popular answer based code comments. There were several Sublime plugins. So this wasn't so hard to imagine.
moogly 5y ago
People only seem to have heard about GitHub Copilot. But Microsoft has a similar solution (that is not as... invasive) that was first released in preview in 2018. It's called IntelliCode, available for multiple languages both for Visual Studio Code[1] and regular Visual Studio[2] (but not enabled by default last time I checked -- which was a while ago, granted). 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=VisualStudioExptTeam.vscodeintellicode https://marketplace.visualstudio.com/items?itemName=VisualSt... [2]: https://github.com/MicrosoftDocs/intellicode/blob/master/docs/intellicode-visual-studio.md https://github.com/MicrosoftDocs/intellicode/blob/master/doc...

by junon 5y ago

chubot 5y ago

> Leveraging the strengths of the computer and human will lead to an order of magnitude improvement in programmer productivity. Interactive testing will eliminate whole classes of logic bugs, making most non ui code correct by construction. 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.

kaba0 5y ago
More like Brooks was the one being right (for like 3 decades now) with his ‘No silver bullets article’, in that we will not have another order of magnitude productivity change in programming after high level languages became a thing.
- kragen 5y ago
  Brooks wrote "No Silver Bullet" in 01987. The examples of high-level languages he mentions in his paper are Ada, Modula (not sure whether the 01975 version or Modula-2), Simula-67, APL, Pascal, Smalltalk, Fortran, COBOL, PL/I, and Algol, and of these he thinks Ada is the most promising. Does his thesis hold up in the face of modern programming language advances? 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 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 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.
  - kaba0 5y ago
    I may not really get your point: are you trying to prove or disprove the original article? 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.
    - kragen 5y ago
      Well, I was hoping to disprove it, and then I looked at things I'd written recently in high-level languages, for which I had logs of how long it took me, and came to the opposite conclusion: Python might be more productive than Ada, but not by an order of magnitude. Of course someone else might be a much better programmer than I am in Python, but in all likelihood their improvement over me in lower-level languages would be even bigger. 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.)
  - laurentlbm 5y ago
    Why do you write years with a preceding zero?
- chakkepolja 5y ago
  Availability of internet & resources like Stack Overflow can be considered a silver bullet, if you consider less proficient / junior programmers.

deleted 5y ago

[deleted]

Areading314 5y ago

Does anyone actually use Copilot day to day? How much time does it actually save?

solidr53 5y ago
Writing scrapers with it is also amazing. All from the puppeteer code, response interface and casting to a local class model. Very time saving indeed.
- 37ef_ced3 5y ago
  How close are you to being fully obsolete?
  - deleted 5y ago
    [deleted]
  - bspammer 5y ago
    The correct response to becoming obsolete is to learn something new, not to fight the thing making you obsolete. Doing the latter is about as productive as yelling at the tide to not come in.
    - 37ef_ced3 5y ago
      Yes, I guess it's like complaining about nuclear weapons. Best to embrace them. If we can do it, we should do it. All technology is progress. All technology improves the human existence.
      - bspammer 5y ago
        It's irrelevant whether the technology is good or bad. There's nothing you can do to stop it happening, so do you want to complain, or do you want to embrace the change and stay ahead of the curve?
        5y ago

ldjkfkdsjnv 5y ago

Its honestly not that hard to predict, with a bit of statistics and some insights into early deep learning, its obvious that alot of data with discernable patterns will produce good results.

sandwichbop 5y ago
What will programming look like in 2028?
- Koshkin 5y ago
  2028 will be the year of Linux on the desktop, so…
- craftinator 5y ago
  We'll all be using Deno, Crystal, Nim, and Zig, and lament with great nostalgia the days of Node, Ruby, Rust, and C/++.
  - nsonha 5y ago
    I understand that the value proposition of Rust is better C++, Deno is better Node. Crystal's "Better Ruby" doesn't sound like much given Ruby is niche anyway. What is it for Nim and Zig?
    - dosshell 5y ago
      Zig is a better C in many ways. Memory handling, error handling, security, but most importantly it can be used together with C. No need to port your code base just swap to zig and continue. Of course now you have a code base in zig and C... :/
  - Alekhine 5y ago
    What makes you think Rust will be out the door? None of those languages are as fast, while also being memory safe

lasc4r 5y ago

FYI, specialize is the American spelling.

junon 5y ago
Yep, I'm an American. It was missing the 'D' on the end ("specialized") hence the (sic).

lelanthran 5y ago

Cherry picking only the accurate prediction makes it seem like the predictor is really good! 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?

CardenB 5y ago
Can you explain how this is worse than random chance?
- GuuD 5y ago
  It is, for people who think that the chance of meeting dinosaur on the street is 50% (you either do or don’t) /s
  - jhgb 5y ago
    Does that account for multiverses?
- maest 5y ago
  They're just using a flat prior, which is maybe inappropriate.
  - Sharlin 5y ago
    A flat prior over a probability space with only four possible events, but in reality there are of course many more possible events from which those four were originally picked.
still_grokking 5y ago

byteface 5y ago

Well people were making API calls to stackoverflow at the time to pull the most popular answer based code comments. There were several Sublime plugins. So this wasn't so hard to imagine.

moogly 5y ago

People only seem to have heard about GitHub Copilot. But Microsoft has a similar solution (that is not as... invasive) that was first released in preview in 2018. It's called IntelliCode, available for multiple languages both for Visual Studio Code[1] and regular Visual Studio[2] (but not enabled by default last time I checked -- which was a while ago, granted). 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=VisualStudioExptTeam.vscodeintellicode https://marketplace.visualstudio.com/items?itemName=VisualSt... [2]: https://github.com/MicrosoftDocs/intellicode/blob/master/docs/intellicode-visual-studio.md https://github.com/MicrosoftDocs/intellicode/blob/master/doc...