
References for “The Future of Programming” - edwintorok
http://worrydream.com/dbx/
======
jwatte
Goal oriented programming is alive and well in SQL.

Visual programming comes around every ten years, and fails each time, because
it can't deal with large complexity like text can. There is a reason people
write books, not comics, especially for advanced topics!

Negotiating without a common ontology is needlessly hard, and doesn't come up
in real use cases. It turns out, when you need to talk to another computer,
you need to do that for very specific reasons. (Also, security and
authorization!)

Constraint systems are alive and well in SolidWorks, Inventor, and other such
systems.

It turns out, just because ideas are interesting, doesn't make them actually
better at solving real problems in general! It's not the "FORTRAN versus
assembly" problem. It's the "can I actually get there" problem.

I'm all for a topic review, including of classic history. But I also think
"different for different's sake" is a good way of eating money and alienating
users.

~~~
pseud0r
Visual programming is really superset of textual programming. Is basically
GUIs vs command lines. These day most people use a GUI such as Windows, Mac OS
X or X Windows rather than using DOS or a pure Linux command line. The issue
is that current visual languages in general try to force everything into a
node based language. It need to be able to describe different data structures
in different ways, some maybe as text, some as tables, others as networks.

There is a reason people write books with illustrations, not pure text books,
especially for advanced topics.

~~~
collyw
The only thing that visual programming solves is the syntax element. At the
end of the day that is actually one of the easiest parts of programming.
Understanding your data structures and relationships can't be solved any more
easily through GUI interfaces.

Guis work well for interactive stuff, but not for scripting things.

~~~
pseud0r
There's a reason why people draw in photoshop instead of typing the values of
pixels in an array.

I think the biggest problem with textual programming isn't the text per se,
but that text is used as the underlying format. I'd rather have projections of
an abstract syntax tree that I could manipulate as text with different types
of syntax or as various visual objects when that would be more useful.

~~~
icebraining
Frankly, I never understood this objection; what's the problem with using text
as the stored format? You can still parse it to an AST, render it in a visual
way and then serialize the AST back to text.

I think the main issue is that code syntax is too flexible, so code generation
tools create large diffs when updating manually written code. A simple
solution to that is having a formatting tool like "go fmt" to adjust the
latter before committing.

~~~
collyw
At the end of the day, text is just an intermediate format that we understand.
Its all stored in a binary representation.

Yes, I agree. Text is too flexible (allowing you to do clever things you
couldn't do in a drop down menu). A drop down menu won't allow you to make the
same mistakes that a text option will, but is way less flexible.

~~~
seanmcdirmid
Flow and rhythm are a thing in progrsmming, which is why structured editing
continues to feel "stilted" to many people. Heck, many people don't even like
static typing for similar reasons...without heavy doses of inference, it
forces you to write your code in a certain order or suffer from a bunch of
distracting spurious tyoe errors.

------
Nzen
previous discussion
[https://news.ycombinator.com/item?id=6129148](https://news.ycombinator.com/item?id=6129148)

I am personally most interested in how to arrange a software to software
pigdin for negotiating communication. Beside the obvious, like the dialtone
handshake.

------
ktRolster
Is there a summary of the talk? I can't find a transcript anywhere.

~~~
wcarss
Spoilers:

The talk is presented as though the year is 1973 and Bret Victor is reviewing
some of the great stuff that's happened the last decade and four major trends
that he can imagine will define computing in 40-someodd years.

They revolve around constraint/goal solving instead of writing procedures,
direct manipulation of data instead of coding it, using spatial representation
and reasoning rather than huge piles of text, and real concurrency rather than
mock concurrency built atop sequential Von Neumann machines, all with great
examples (these are what the references largely fill out).

The talk concludes with Bret Victor slightly dropping the gag and making the
point that these particular things are not the real point: the real point is
that believing we know what we're doing, individually or as a profession, is
deadly to our creativity, and that the great ideas discussed all happened
_then_ because computers were able to be useful at that time, but no one
thought that they'd figured it all out yet.

He urges us to realise and become comfortable with the fact that we don't know
what we're doing, so that we can be free to do anything.

/tape recorded, distorted applause

