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

[Joe Armstrong]

On Tue, Feb 4, 2014 at 9:04 AM, Vlad Dumitrescu <vladdu55@REDACTED> 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.
>
> 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. That Eclipse starts with a "welcome" page that can be confusing, that
> has nothing to do with GUIs either.
>
> Of course, if we are comparing (say) Emacs in console mode and Eclipse,
> then we can pick on this kind of detail. 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: I, for example, have easier
> to work with images/icons/color coding/visual structure. Others, like you,
> prefer plain text. Excellent! I'm not bashing textual interfaces just
> because I happen to have other ways that work better for me in certain
> cases.
>
> 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.
>
> If more research was done on things that are actually helping people
> rather than on things that look good on resumes, then I think we would have
> much better tools. Likewise, if more thought went to creating a GUI that is
> actually helping people rather than cramming more cool features into that
> program, then we'd have much better GUIs. These shortcomings are not
> intrinsic to a kind of tool or program or interface, so I think we should
> try to keep them apart.
>

Agree 100%

I have a idea of what I'd like - I've been thinking about this for many
years

I'd like to see two windows.

In window one I type my program. There is a single button under the window.
The button has an icon of Sherlock Holmes on it.

I press the Sherlock button.

Sherlock analyses my text fragment comparing it to all the programs in the
entire universe
that have ever been written - in the second window it says
"this program is very similar to ..." or "this is a new idea ..."
"did you know that XXX is working on this at this very moment ..."

I've experiment with this is several forms - I want to find "the most
similar thing to
the given thing" - this is an extremely difficult problem.

I write code because it is quicker to write the code from scratch than
finding out
if somebody else has written it.

Almost invariably if I can find that somebody else has written some code, it
does not do precisely what I want - but a near miss would be good enough.
If I could understand it I could modify it to suit my needs.

We need mechanisms merge code, but the problem is we don't know where the
code
is that needs to be merged.

If I publish a program, people will cut-and-paste from this code forming
new code.
Changes made in the cut-and-paste code will not back propagate into the
original code.

One algorithm I've played with is least-compression-difference.

A and B are similar if the size(compress(A)) is almost the same as
size(compress(A ++ B))
I guess the similarity detection  algorithms and sliding checksums used in
rsync
would be useful, or Bayesian inference or Latent Dirchlet allocation.

I also dislike files and directories. They are totally useless for
organizing information.

When I've typed my small program into a text box, I have to store it in
a file - but what should the file name be, and in which directory? How
will I find it again later?

As for editors the best I have found is org-mode in emacs - outline editors
are great - since they support two levels of abstraction. Editing content,
and editing structure.

Emacs is great at paragraph editing, but not good at structure editing.
I can't easily flip the order of this and the last paragraph. I guess I
could
write a macro for this, but it would be nice if it did this out of the box.
org-mode solves a lot of these problems.

One day IDEs might help me think - I think some kind of synergy between
a text editor, a search engine and a IRC thingy would be good.

IRC is great - if I knew who to talk to and where they hang out.

Computers should serve our needs - not like it is today where we serve
their needs.

/Joe














>
> best regards,
> Vlad
>
> On Tue, Feb 4, 2014 at 6:48 AM, Richard A. O'Keefe <ok@REDACTED>wrote:
>
>>
>> On 3/02/2014, at 10:01 PM, Vlad Dumitrescu wrote:
>>
>> > Hello Richard,
>> > TL;DR: There's a lot of fine semantics regarding the things at stake
>> here and I'm not arguing that "graphical beats textual", but that
>> "'graphical' appeals to different parts of the brain than 'textual' and
>> which one works better for an individual is a personal matter".
>>
>> But note that the "personal matter" depends on training and experience
>> also.
>>
>> > I don't believe there is something intrinsic to 'graphical' that makes
>> it bad.
>>
>> There are issues such as
>>  - density of relevant information
>>  - accessibility of information
>>
>> I have begun using some annotations in my Smalltalk system.
>>
>>         <compatibility: DIALECT>
>>             Says that this method exists for compatibility
>>             with another Smalltalk system.  Don't blame ME
>>             for the interface.
>>
>>         <supportFor: METHOD>
>>             Says that this method exists in order to support
>>             the construction of some other METHOD and should
>>             not be considered as part of a stable interface.
>>             (If METHOD is changed, this might change or go.)
>>
>>         <compositionOf: FIRST and: SECOND>
>>             Says that this method is semantically a composition
>>             of two other methods but done a different way that
>>             saves space or time or both or done when the
>>             composition is legal but the parts would not be.
>>
>> How does something like UML handle relationships like these?
>> By *textual* annotations on lines.
>> Or it would if UML were good at handling relationships between
>> methods...
>>
>> I've only just begun exploring this space.  Already it is
>> clear that some refinement is possible.
>>
>> <compatibility: _>
>>    When I look at other systems, I see
>>         A standard things
>>         B nonstandard things that seem like a good idea
>>         C nonstandard things that I don't really feel
>>           any need for, but what the heck
>>         D nonstandard things that stink.
>>         E useful ideas which badly need redesign.
>>
>> For B and C I need to give credit where it's due.
>> There should be a distinction between B and C.
>> For D, it's hard to annotate something that's not
>> _there_, but I've been feeling the need to have
>> *something* that tools can trivially find to say
>> why a particular class or method is not there.
>> For an example of E, the way that Squeak and Pharo
>> handle joining a bunch of strings inspired me, but
>> it inspired me to do it quite differently.  So I want
>> to express a relationship between some methods I do NOT
>> have and some methods I DO have.
>>
>> So now we have relationships like
>>         METHOD1 in this system solves the same
>>         problem that METHOD2 in SYSTEM2 does
>>         but better because REASON.
>> Text?  No worries.
>> Pictures?  Not so good.
>>
>> <compositionOf: _ and: _>
>>
>> What is the reason for the composition?
>> Is it #space (to avoid garbage creation),
>>    or #time  (to save time),
>>    or #legality (e.g. to avoid mutating a collection
>>                  while iterating over it)
>>    or #concurrency
>>    or what?
>>
>> Like I said, I've only just begun exploring what I think
>> of as the "discourse structure" of code; I'm sure there
>> is a lot more to be found, and
>>
>>         the freedom to think in terms of n-ary
>>         relationships rather than binary relations
>>         annotated with a <<sterotype>> is important.
>>
>>
>> > Also, "graphical" is not the same as "having a GUI"; I got them mixed
>> up too in my message. A program can have a good (or bad) user interface
>> regardless of this interface being textual or graphical.
>>
>> If I understood him, Joe's point was not so much about how
>> information is displayed to a user but about how accessible
>> it is to lightweight *tools*.  If there is an easy to drive
>> programmable interface to the data model, I imagine Joe
>> has no objection if there is a graphical human interface as well
>> for those that want it.
>>
>> Take as an example Microsoft Excel.
>>
>> On Windows, you can control it programmatically using Visual
>> Basic for Applications, or could.  You can probably do it
>> through PowerShell, which is pretty capable.  In MacOS X,
>> you do it through AppleScript.  (You can probably do it
>> through FScript as well.)  But I can't get at it the *same*
>> way on both systems.
>>
>> > Here is the first semantic point: you are absolutely right. Then why
>> call Eclipse "graphical"? It still edits text!
>>
>> So,
>>         % open -a Eclipse
>> After a l o n g time, I am staring at a window containing
>>
>>         a circle containing picture of a desk globe
>>         a circle containing a 4-pointed star
>>         a circle containing a blue cube, a green pyramid,
>>           and an orange ball
>>         a circle containing a notebook with a green tick
>>         a circle with a piece of ribbon in it.
>>         a purple disc with the word "eclipse" over it and
>>           a white fuzzy penumbra.
>>
>> Did someone actually think this was *clever*?
>>
>> It turns out these things mean
>>
>>         Overview
>>         What's new
>>         Samples
>>         Tutorial
>>         Workbench
>>         nothing whatever
>>
>> respectively.  A picture is sometimes worth 0.001 words.
>>
>> > If the thing with Eclipse is that it has a lot of graphical ornaments
>> around the text,
>>
>> There's Joe's issue and my issue.
>> I think Joe's issue was availability or not of a simple text-based
>> *alternative* that can be used by mortals.
>> From my perspective, Eclipse is about two decimal orders of
>> magnitude harder to use than Emacs.
>>
>> > then my point was that Emacs has toolbars and status bars and such too.
>>
>> No it doesn't, not unless you want it to.
>> Just verified: it uses one line at the bottom for the minibuffer
>> and one line above that for the status line.  In an 80 column by
>> 60 line window I can easily spare 2 lines.
>>
>> > The (first edition of) the book that explains how to *use*
>> > Eclipse is bigger than the listing of my emacs-like editor
>> > PLUS the listing of the C compiler I originally used to
>> > write it PLUS the listing of the UNIX kernel it originally
>> > ran on PLUS the manuals.
>> >
>> > I'm not sure why that would be relevant.
>>
>> The relevance is that
>>  - Eclipse *looks* dauntingly complex when you sit down in
>>    front of it,
>>  - when you turn to the reference book for help, it turns
>>    out that it really *is* dauntingly complex.
>>    Eclipse all by itself is more complex to understand than
>>    the *whole* of the software stack I used when doing my
>>    PhD, and
>>  - it is hard to approach that complexity incrementally
>>    because there are *lots* of things you apparently have
>>    to do to do anything.
>>
>> I *was* able to learn everything I needed to know about XCode
>> from a book and from the Apple documentation.  I'm able to
>> use -- even to extend -- Smalltalk IDEs and I still have
>> fond memories of using and extending Interlisp-D.  I was at
>> one time familiar with the sources of three Emacs clones.
>> But Eclipse has utterly defeated me.  I am never going to be
>> able to learn it by myself.
>>
>> > Just because Eclipse might be difficult to understand/explain doesn't
>> make all possible similar tools bad.
>>
>> Agreed.  I can at least do basic things in NetBeans, but even then,
>> I'd much rather not.
>>
>> > Also, I don't know how large a book about using emacs is/would be (at
>> the same detail level as in the Eclipse book).
>>
>> It's not hard to find out.  The Emacs manuals are free.  The Emacs
>> user manual is considerably smaller than the Eclipse user book.
>>
>> > There's a lot of functionality in both, it has to take some place to
>> describe and explain it.
>>
>> For me the daunting complexity is not "a lot of functionality",
>> it's the complexity of the interface for *getting started*.
>> >
>> >> In my opinion, what a programming environment brings to the table is
>> multiple ways to look at the code, to quickly see what is going on.
>> > I think Joe agrees with you, except that Joe places a heavy
>> > emphasis on
>> >  - something that has precise definition
>> >  - explicit and straightforward semantics
>> >  - that he can understand.
>> >
>> > I think so too. Only the last point has the potential to signify that
>> pure text beats a GUI, and it's a personal thing.
>>
>> Potential?  The question is not the *potential* but the
>> *present actuality*, which is that textual systems _do_
>> (by and large) have more explicit definitions.  Too many
>> GUI designers seem to take the view "It's a GUI.  How can
>> it be hard?"
>>
>> >
>> > The one that's actually _useful_ is the text file, because
>> > there doesn't seem to be any good way to display nearly
>> > 800 classes in one diagram.  Heck, the collection hierarchy
>> > alone has 176 classes; try getting just _that_ in one display.
>> >
>> > And there is a good way to display this hierarchy in textual form on a
>> single page? That would be the equivalent...
>>
>> No, it's *not* the equivalent.  The equivalent of a picture
>> that needs to be scrolled around a large wall is a text file
>> that needs scrolling in one direction only.  For a human
>> being.  For a program, the important thing is that
>>
>>  - it is trivial to generate the picture from the text
>>  - but not the other way around.
>> >
>> > There are tools that can show large diagrams in a way that works much
>> better (for example, by using a hyperbolic mapping where the current item
>> is large and in the middle and the less related other items are to it, the
>> smaller and more to the periphery they are.
>>
>> Sorry, that just does not work in this case.  The things I need
>> to see together are not close in that sense.
>>
>> > Panning in the diagram brings other items in focus). There's a lot of
>> research on this, see for example http://www.visualcomplexity.com/vc/.
>> Just because the simplest diagrams aren't good enough doesn't mean that any
>> diagram is bad.
>>
>> It doesn't mean that a more complex diagram is any good either.
>> In this case, for my purposes, it isn't.
>>
>> Remember, the goal is not "DISPLAY SOMETHING", it is
>> "EXTRACT INFORMATION FROM SOMETHING".
>>
>> Data visualisation is actually one of my interests.
>> I have seen *way* too many really cute "infographics"
>> that turned out to be incomprehensible or inaccurate.
>> (I have a copy of Gephi and had serious difficulties
>> with its user interface.)
>>
>> There are some superb data visualisations, but it isn't
>> _easy_ to design them.
>>
>> > Now, visualising the process structure would be nice, except
>> > that someone *did* this using UbiGraph and the result was
>> > as dismaying as it was cool.  Erlang lets you have *lots* of
>> > processes, and that's just what doesn't suit a diagram.
>> >
>> > See above. The breakthrough would be to be able to detect which
>> processes are important to show and when.
>>
>> Yes, that would be nice.  Do you have some idea of how to do that?
>>
>> > See for example https://code.google.com/p/gource/ on how a project's
>> VCS history can be visualized
>>
>> I have seen that before.
>> To me, it's a textbook example of "cute, but what actual
>> GOOD does it do me?"
>> If I want to learn something from version control logs,
>> I'm *not* going to look at a Gource movie,
>> I'm going to analyse the logs in textual form.
>>
>> Not idle chatter.  I have a project of my own for which I
>> *have* analysed the logs to spot patterns.  Plain old
>> black and white 2D graphs displayed what I had found
>> perfectly well.  The trick was to GET ACCESS TO THE DATA
>> in such a way that A SIMPLE PROGRAM CAN PROCESS IT.
>>
>> > -- imagine a similar thing where the focus is on processes that are
>> active, they are kept in the middle and larger, the links light up when
>> messages are sent, all dynamically as one goes back and forth in time..
>>
>> If it's just like the one I saw a while back using Ubigraph,
>> or if it's like Gource, the answer is that it will be as cute
>> as a basket of kittens in party hats, but won't actually be
>> any use for analysis.
>>
>> I am reminded of a prominent secular theologian (that's one of
>> those strange people who says there is no god THEREFORE let us
>> do religion).  My father went to one of his lectures, and
>> afterwards me one of his own students who had also gone.
>>         Student.  Wasn't X a *wonderful* speaker?
>>         Dad.      Yes.  But what did he *say*?
>>         Student.  (Silence.)
>>
>> >
>> >> As a user, one shouldn't need to understand how the environment works
>> (you think Eclipse is complex, I think Emacs is; it's a matter of what we
>> are accustomed to).
>> > We can measure the complexity of an environment in itself
>> > without reference to what we are accustomed to.
>> > The text editor I normally use takes less than 15 000 raw
>> > lines of C (less than 8 000 SLOC); executables and help
>> > files come to 173 kB on disc.
>> > That _has_ to be less complex than Emacs.app, which is
>> > 161 MB on disc.
>> > And that _has_ to be less complex than Eclipse for C/C++
>> > where the smallest download seems to be 141 MB compressed.
>> > And the really annoying thing is that the actual text
>> > editing support in Eclipse is far more limited than that
>> > in the 173 kB program!
>> >
>> > Why is the size or complexity of the code relevant?
>>
>> (a) Because a small program *can't* have as a dauntingly
>>     complex an interface as a large one.
>> (b) Because a small program *can't* have as many
>>     internal interactions as a large one (the user's
>>     mental model of what the program is up to will be
>>     less inaccurate).
>> (c) Because a large program will, as a rule, have more
>>     bugs than a small one, and the relationship is
>>     non-linear.
>>
>> > I can have short and simple code that implements a program with very
>> weird commands and interaction patterns. I can have a huge complex program
>> with a nice and understandable or discoverable way to use it.
>>
>> You *can*, but as a rule you *don't*.
>> >>
>> > I understand what you mean. If I use Emacs and I customize it with
>> fancy commands that help my workflow and become dependent on them -- isn't
>> that the same problem as with depending on Eclipse?
>>
>> No, the question is not "what do *I* depend on" but
>> "what am I requiring *OTHER* people to depend on".
>>
>> > Emacs _is_ an IDE.
>>
>> This really does miss the point, which is that software
>> developed *using* Emacs is textual.  If Joe develops something
>> using Emacs, I can read *ALL* of it using TextEdit or pico or
>> whatever.
>>
>> Now I've never succeeded in building anything with Eclipse,
>> but I *can* say that if I build something with XCode, there's
>> information hidden in all sorts of strange places, and I've
>> had serious difficulty importing old projects into a newer
>> XCode.  Heck, I've had serious difficulty importing other
>> people's projects into the *same* version of XCode, thanks
>> to important information about the project that was only
>> accessible using the GUI.
>> >
>> >
>> >  What I mean is that implementing a bug-free core is much easier than
>> implementing all the functionality on top of it just as bug-free.
>>
>> Agreed, and getting the other functionality on top bug-free pretty
>> much *depends* on there being a small comprehensible core.
>>
>> > No I'm not. I just don't think that the reason that TeX is practically
>> bug-free has anything to do with it being a backend tool.
>>
>> Let's be clear about causality here.
>> I think you are saying
>>         NOT BECAUSE(backend(TeX), reliable(TeX))
>> and I am saying
>>         BECAUSE(reliable(TeX), backend(TeX))
>>
>> Let me put it this way.  There was a time when I was seriously
>> considering a move from (La)TeX to another document formatter
>> with simpler cleaner markup.  I read the manual cover to cover
>> several times, started playing with it, and found it produced
>> good-looking output.  But when I ran lint over it, a lot of the
>> lint warnings turned out to be genuine, and within a day I had
>> found a number of ways to crash it.  So I dropped the idea of
>> writing front end scripts to generate input for that processor.
>> For me,
>>         BECAUSE(NOT reliable(XXXX), NOT backend(XXXX))
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140204/d28ed388/attachment.htm>