Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dijkstra On the foolishness of "natural language programming"

cs.utexas.edu

Post reply on HN
Print view View original

11–20 of 281 posts

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

#11

Post by d1sxeyes »

hamstergene wrote: post #5

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…

Not sure if you’re talking about DRAKON here, but I love it for documentation of process flows.

It doesn’t really get complicated, but you can very quickly end up with drawings with very high square footage.

As a tool for planning, it’s not ideal, because “big-picture” is hard to see. As a user following a DRAKON chart though, it’s very, very simple and usable.

Link for the uninitiated: https://en.m.wikipedia.org/wiki/DRAKON

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

#12

Post by yapyap »

(2010) by the way, which makes this article all the more impressive.

I was under the assumption this was a current body of work seeing as Dijkstra spoke so well about the possibilities but this just goes to show some people were ahead of their tike with their worries.

Also adding your home address to something you write / publish / host on the internet is pretty hardcore.

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

#13

Post by octacat »

hamstergene wrote: post #5

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…

Most popular dependency management systems literally linking to a git sha commit (tag), see locks file that npm/rebar/other tool gives you. Just in a recursive way.

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

#14

Post by timvdalen »

yapyap wrote: post #12

(2010) by the way, which makes this article all the more impressive. I was under the assumption this was a current body of work seeing as Dijkstra spoke so well about the possibilities but this just goes to show some people were ahead of their tike with their worries. Also adding your home address to something you write / publish / host on the internet is pretty hardcore.

Dijkstra died in 2002, so I assume 2010 is just the date of transcription

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

#15

Post by gitanovic »

chilldsgn wrote: post #3

This is the most beautiful thing I've read in a long time.

Me too, I printed it and underlined it, I will try to memorize some of the concepts and the exposition, because this is a cristallization of what I vaguely feel about the abuse of LLM I am currently witnessing

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

#16

Post by hmhhashem »

hamstergene wrote: post #5

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…

For young engineers, it is a good thing to spend time implementing what you call "bad ideas". In the worst-case, they learn from their mistake and gain valuable insight into the pitfalls of such ideas. In the best case, you can have a technological breakthrough as someone finds a way to make such an idea work.

Of course, it's best that such learning happens before one has mandate to derail the whole project.

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

#17

Post by hamstergene »

octacat wrote: post #13
hamstergene wrote: post #5

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…

Most popular dependency management systems literally linking to a git sha commit (tag), see locks file that npm/rebar/other tool gives you. Just in a recursive way.

They do way more than that. For example they won't allow you to have Foo-1 that depends on Qux-1 and Bar-1 that depends on Qux-2 where Qux-1 and Qux-2 are incompatible and can't be mixed within the same static library or assembly. But may allow it if mixing static-private Qux inside dynamic Foo and Bar and the dependency manager is aware of that.

A native submodule approach would fail at link time or runtime due to attempt to mix incompatible files in the same build run. Or, in some build systems, simply due to duplicate symbols.

That "just in a recursive way" addition hides a lot of important design decisions that separate having dependency manager vs. not having any.

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

#20

Post by Folcon »

hamstergene wrote: post #5

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 unworkable ideas that have made a comeback when someone figured out how to make them work.

Post reply on HN