Live data from Hacker News

Dijkstra On the foolishness of "natural language programming"

cs.utexas.edu

61–70 of 281 posts

Re: Dijkstra On the foolishness of "natural language programming"

#61
Finally someone put it this way! Natural language has embedded limitations that stem from our own mental limitations -the human mind thinks sometimes too abstract or too specific things, and misses important details or generalizations.

As a programmer, I know first hand that the problems or even absurdities of some assignments only become apparent after one has begun implement the code as code, i.e. as strict symbolisms.

Not to mention that it often takes more time to explain something accurately in natural language than it takes to just write the algorithm as code.

Re: Dijkstra On the foolishness of "natural language programming"

#62
post #20

Reminds me of another recurring idea of replacing code with flowcharts. First I've seen that idea coming from some unknown Soviet professor from 80s, and then again and again from different people from different countries in different contexts. Every time it is sold as a total breakthrough in simplicity and also every time it proves to be a bloat of complexity and a productivity killer instead. Or weak typing. How ma…

> Maybe software engineering should have some sort of "Hall of Ideas That Definitely Don't Work", so that young people entering the field could save their time on implementing one more incarnation of an already known not good idea. I'm deeply curious to know how you could easily and definitively work out what is and is not an idea that "Definitely Don't Work" Mathematics and Computer Science seem to be littered with…

Well, "Hall of Ideas That Are So Difficult To Make Work Well That They May Not In Fact Be Much Use" doesn't roll off the tongue as smoothly.

What this Hall could contain, for each idea, is a list of reasons why the idea has failed in the past. That would at least give future Quixotes something to measure their efforts by.

Re: Dijkstra On the foolishness of "natural language programming"

#63

Earlier quoted context omitted.

The difference between the clarity of Dijkstra writing and the text at this link is astounding.

Vibes aren’t really about clarity, are they? The point is that a clear, programmatic approach is not the only effective computational mechanism for realizing intentions anymore. Keep in mind that Dijkstra had some giant shoulders to stand on. This article is the very first one I’ve ever seen that directly dealt with vibes.

The thing is, for at least some readers, the attraction of _The Glass Bead Game_ and similar abstractions is that they should be able to communicate more clearly, and without the ambiguity of natural language, but with a naturalness which allows unbridled expression.

I really would like to see such a programming system realized, see efforts at:

https://github.com/IndieSmiths/myappmaker-sdd

but the more I work at programming, the more the solution seems to be documentation, and the best system for documenting code and the information about it seems to be:

http://literateprogramming.com/

I just need to find the perfect GUI toolkit which allows Bézier Curve representations in a way which clicks and makes sense to me, and suits my next project.

Re: Dijkstra On the foolishness of "natural language programming"

#65

He didn’t understand the concept of the vibe. Here’s the best theory article I’ve read https://www.glass-bead.org/article/a-theory-of-vibe/

What is with the mix of high academia and lowbrow language? Does the author think it’s cute? Covering for something?

> the computations involved in autoencoding… are mathematically intractable

OK, so he doesn’t understand what he’s talking about.

> Peli Grietzer recently finished his PhD in mathematically informed literary theory at Harvard Comparative Literature

How is this a thing.

Re: Dijkstra On the foolishness of "natural language programming"

#66
post #43

Reminds me of another recurring idea of replacing code with flowcharts. First I've seen that idea coming from some unknown Soviet professor from 80s, and then again and again from different people from different countries in different contexts. Every time it is sold as a total breakthrough in simplicity and also every time it proves to be a bloat of complexity and a productivity killer instead. Or weak typing. How ma…

> Maybe software engineering should have some sort of "Hall of Ideas That Definitely Don't Work", so that young people entering the field could save their time on implementing one more incarnation of an already known not good idea. FWIW, neural networks would be in that pool until relatively recently.

If we change "definitely don't work" to "have the following so far insurmountable challenges", it addresses cases like this. Hardware scaling limitations on neural networks have been known to be a limitation for a long time - Minsky and Papert touched in this in Perceptrons in 1969.

The Hall would then end up containing a spectrum ranging from useless ideas to hard problems. Distinguishing between the two based on documented challenges would likely be possible in many cases.

Re: Dijkstra On the foolishness of "natural language programming"

#67
This reminded me of this old quote from Hal Abelson:

"Underlying our approach to this subject is our conviction that "computer science" is not a science and that its significance has little to do with computers. The computer revolution is a revolution in the way we think and in the way we express what we think. The essence of this change is the emergence of what might best be called procedural epistemology—the study of the structure of knowledge from an imperative point of view, as opposed to the more declarative point of view taken by classical mathematical subjects. Mathematics provides a framework for dealing precisely with notions of "what is". Computation provides a framework for dealing precisely with notions of "how to"."

Re: Dijkstra On the foolishness of "natural language programming"

#68
post #52

Earlier quoted context omitted.

What you're describing is decontextualization. A sufficiently powerful transformer would theoretically be able recontextualize a sufficiently descriptive natural language specification. Likewise, the same or an equivalently powerful transformer should be able to fully capture the logic of a complicated program. We just don't have sufficient transformers yet. I don't see why a complete description of the program's des…

“Fill in the gaps by using context” is the hard part. You can’t pre-bake the context into an LLM because it doesn’t exist yet. It gets created through the endless back-and-forth between programmers, designers, users etc.

But the end result should be a fully-specced design document. That might theoretically be recoverable from a complete program given a sufficiently powerful transformer.

Re: Dijkstra On the foolishness of "natural language programming"

#69
post #62
post #20

Earlier quoted context omitted.

> Maybe software engineering should have some sort of "Hall of Ideas That Definitely Don't Work", so that young people entering the field could save their time on implementing one more incarnation of an already known not good idea. I'm deeply curious to know how you could easily and definitively work out what is and is not an idea that "Definitely Don't Work" Mathematics and Computer Science seem to be littered with…

Well, "Hall of Ideas That Are So Difficult To Make Work Well That They May Not In Fact Be Much Use" doesn't roll off the tongue as smoothly. What this Hall could contain, for each idea, is a list of reasons why the idea has failed in the past. That would at least give future Quixotes something to measure their efforts by.

Ok, so better documentation about what was tried, why, how it failed so as to make obvious if it's viable to try again or not.

I can get behind that :)...

Re: Dijkstra On the foolishness of "natural language programming"

#70
> It was a significant improvement that now many a silly mistake did result in an error message instead of in an erroneous answer. (And even this improvement wasn't universally appreciated: some people found error messages they couldn't ignore more annoying than wrong results, and, when judging the relative merits of programming languages, some still seem to equate "the ease of programming" with the ease of making undetected mistakes.)

If I didn't know who wrote this it would seem like a jab directly at people who dislike Rust.

Post reply on HN