[erlang-questions] The quest for the perfect programming language for massive concurrency.

[Richard A. O'Keefe]

On 4/02/2014, at 9:04 PM, Vlad Dumitrescu wrote:

> Hi Richard,
> 
> There's a lot of interesting stuff in your post, as always, and most of it I agree 100% but I have this nagging feeling that there's a misunderstanding between us and we're not talking about the same things.

Let's go right back to what Joe wrote:

	What I want in a programming environment
	would take a book to describe.

	For starters, I would like it to be precisely
	documented.

Let me say that this is one of my pet peeves.
If there _had_ been precise documentation for XCode 4,
Apple might have been inclined to make XCode 5 more
compatible with it.  As it is, I have a helpful book
for XCode 4 that is, um, less helpful for XCode 5.

Maybe this deserves a slogan: "If we don't document
an interface we can smile while breaking it."

	It should be textual not GUI based -
	THE REASON FOR THIS IS AUTOMATION -
	I cannot easily automate things if they
	are GUI based.  I can automate things if
	they are text based.

	Also It's very difficult to describe
	what to do in a GUI - the descriptions need
	pictures to tell you what to do.

Slogan: "A picture may be *worth* a thousand words
but it *costs* ten thousand."

> In short, the things you enumerate as advantages of a textual program and the drawbacks of the graphical ones aren't all related to the textual/graphical attribute of the program. That Excel can't be scripted in the same language in all environments has nothing to do with it having a GUI.

In a sense you are right.
After all, Microsoft *did* supply Visual Basic for Applications
on Macintoshes,
		right up to the point where Apple switched to
X86 and it became *easier* for Microsoft to do this.

The problem is that when the update without VBA was forced on
me, I *never* received *any* documentation for how to drive it
from AppleScript.  Nor did I receive any links to it.
Apparently there *was* an AppleScript/Excel reference manual,
but it's no longer at its old address and other people seem to
be looking for it too.
(I loved this quote: "The Microsoft Office scripting
dictionaries are just horribly designed.  They violate
pretty much every convention for scripting dictionaries
that Apple specifies.")
R to the rescue!  (But wait: that's a textual interface!)

Here are the criteria again:

	* automation
	* [my addition] tolerably portable automation
	  across all supported platforms
	* clear and adequate definition of the interface
	* ease of explaining to others what to do

Now Excel only supports automation to the extent that it
supports an *alternative* to the GUI.  The documentation
-- and I eventually discovered an obsolete copy of the
reference manual, who knows what will break? -- presents
a *textual* interface for automation.

As a matter of fact, now that I have that, I can see that
it is definitely easier to explain to other programmers
what sort of AppleScript to write than to send them a video
of me doing it with the GUI.

> That Eclipse starts with a "welcome" page that can be confusing, that has nothing to do with GUIs either. 

Yes it does.  Joe was talking about programming environments.
Eclipse is one.  I am saying that "is graphical" does not mean
"is good for communication", and that's a superb example of a
*graphical* *user* *interface* that fails horribly at
communication *because* it is graphic.  Only the (textual!)
tooltips make it possible to do *anything* with that page.

>  What I tried to compare was what could be done with one or other kind of interface. Most things can be done just as well with either; some things work better with one of them, depending of the way the user's brain is wired:

Remember the criteria?  It wasn't originally about *users*,
it was about *automation*.

GUIs are hard to automate, not least because Microsoft seem to
redesign their UI for each release.

> I, for example, have easier to work with images/icons/color coding/visual structure. Others, like you, prefer plain text.

I don't know nearly enough about usability.
This much I do know, there are three very different things:
 - how FAST someone can perform a task
 - how ACCURATELY they can perform the task
 - how much they ENJOY performing the task.
These are not just conceptually distinct; they are in
practice sufficiently independent that when someone says
"I have easier to work with X than Y"
I haven't the least idea what they actually mean.

>  Excellent! I'm not bashing textual interfaces just because I happen to have other ways that work better for me in certain cases.

Then why _are_ you writing?

I guess I am just a bad writer.  I did say that I was trying
to support what I took Joe's position to be.

> Everyone I know draws pen-and-paper diagrams and sketches and charts and finds them useful. If they are useful when drawn by hand, they are useful when drawn by a program. If existing programs are drawing incomprehensible diagrams, it doesn't mean that the right diagram would be just as useless.

I would soften Joe's position a bit.

I don't mind if a programming environment *does* have an
optional GUI.  What I mind is if all the design work has
gone into making the GUI look flashy and buzzwordy while
the scripting interface is unstable, bloated, or defunct.



Oh, let me close with a GUI feature I which I *do* enjoy.
If you use XCode, and you select Build|Analyze, you get
these really cool relevance chains tying together the
lines that combine to produce a probable bug.  I *really*
enjoy that.  (But I don't believe it helps me program
faster or more accurately.)