3 ms·

> the real challenge in software engineering research is not what to do about ChatGPT or whatever else Silicon Valley is gushing about at the moment. I know th

> the real challenge in software engineering research is not what to do about ChatGPT or whatever else Silicon Valley is gushing about at the moment. I know this is really just a turn of phrase, but at the rate language models are becoming programming models, it is hard to think of any problem with the lack of hard engineering, science, math, ..., in what we call "Computer Engineering", "Computer Science", "Computer Math", ..., that won't be heavily impacted by model/co-model driven development. For instance, a major programming language of the near future might develop adaptively as multiple coder models communicate between each other. Reviewing, testing and improving upon each other's designs and co-optimizing the way they communicate code as they do so. Resulting in representations and solutions to existing development problems completely opaque to the humans currently working on those problems. The rising effect of massive data + compute outdoing slow careful research in yet another area. Today's models are already being trained across the board on practical/actual and theoretical/research artifacts. No persistent pernicious borders there. Not to take away from anything being said.

xanderlewis 3y ago
> any problem with the lack of hard engineering, science, math, … To be fair, that does exclude quite a lot of problems.
- JadeNB 3y ago
  > > any problem with the lack of hard engineering, science, math, … > To be fair, that does exclude quite a lot of problems. I had some trouble parsing the comment, but I eventually settled on the reading that it means what it literally says, a problem caused by the lack of engineering in computer engineering, of science in computer science, and of math in "computer math" (a phrase I have never heard), rather than a problem other than hard engineering, science, and math, which I agree with you excludes an awful lot of problems.
  - Nevermark 3y ago
    Yes, I meant the phrase respectively! Apologies for lack of clarity. My first computing programming class was called Computer Math. With not even a soft math emphasis.
wizzwizz4 3y ago
> Resulting in representations and solutions to existing development problems completely opaque to the humans currently working on those problems. But why would anyone want that? I agree that this would result, but my takeaway is "and therefore we shouldn't do that".
- Nevermark 3y ago
  > But why would anyone want that? I agree that this would result, but my takeaway is "and therefore we shouldn't do that". My guess is that a lot of CEO's already consider the implementation details of their companies' software systems as opaque. So that is essentially a pre-existing market for performative but opaque systems. CEO's. CFO's. Shareholders, etc. Even in engineering organizations. Look at how Boeing and NASA both demoted critical engineering concerns when external concerns became overwhelmingly more important to their leaders. Now factor in the models actually doing a good job, checking each other, and generally getting better year to year.

xanderlewis 3y ago

> any problem with the lack of hard engineering, science, math, … To be fair, that does exclude quite a lot of problems.

JadeNB 3y ago
> > any problem with the lack of hard engineering, science, math, … > To be fair, that does exclude quite a lot of problems. I had some trouble parsing the comment, but I eventually settled on the reading that it means what it literally says, a problem caused by the lack of engineering in computer engineering, of science in computer science, and of math in "computer math" (a phrase I have never heard), rather than a problem other than hard engineering, science, and math, which I agree with you excludes an awful lot of problems.
- Nevermark 3y ago
  Yes, I meant the phrase respectively! Apologies for lack of clarity. My first computing programming class was called Computer Math. With not even a soft math emphasis.

wizzwizz4 3y ago

> Resulting in representations and solutions to existing development problems completely opaque to the humans currently working on those problems. But why would anyone want that? I agree that this would result, but my takeaway is "and therefore we shouldn't do that".

Nevermark 3y ago
> But why would anyone want that? I agree that this would result, but my takeaway is "and therefore we shouldn't do that". My guess is that a lot of CEO's already consider the implementation details of their companies' software systems as opaque. So that is essentially a pre-existing market for performative but opaque systems. CEO's. CFO's. Shareholders, etc. Even in engineering organizations. Look at how Boeing and NASA both demoted critical engineering concerns when external concerns became overwhelmingly more important to their leaders. Now factor in the models actually doing a good job, checking each other, and generally getting better year to year.