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

[Joe Armstrong]

On Fri, Jan 31, 2014 at 11:40 AM, Vlad Dumitrescu <vladdu55@REDACTED>wrote:

> Hi Joe,
>
> On Fri, Jan 31, 2014 at 8:49 AM, Joe Armstrong <erlang@REDACTED> wrote:
>
>> On Fri, Jan 31, 2014 at 7:50 AM, Michael Turner <
>> michael.eugene.turner@REDACTED> wrote:
>>
>>> One thing I've gotten out of this excellent thread: given what some
>>> people (but not Joe, I guess) want out of a programming environment,
>>>
>>
>> What I want in a programming environment would take a book to describe.
>>
>> For starters, I would like it to be precisely documented.
>>
>> 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.
>>
>> I currently think Knuth was right.
>>
>
> With all due respect to you and Donald Knuth, there is something in your
> text (above and below) that makes me feel confused. Maybe it's just me and
> then it's ok (for the rest of the world, at least), but maybe not. I don't
> know if I will be able to express what this confusion is about, but I will
> try. Maybe you meant something else than I understood and I'd love to get
> it right.
>
> It got a bit long, sorry about that. Look for "****" for the TL;DR
>
> ---
> Why does automating something have anything to do with that thing being
> textual or graphical? vim runs in a console, but also as gVim (graphical).
> The same can be said about emacs and XEmacs. Eclipse can be run in headless
> mode (but I admit that there are rather few tools that work in that mode).
> To me, a tool can be automatable at two levels: it can be run from the
> command line and it might return meaningful data that some other tool can
> process further. I don't see what this has anything to do with the tool
> being textual or graphical. These parts are just the presentation layer...
>

I guess I'd like to be able to run eclipse headless (whatever that means)

I just want to enter things in a file using my favorite editor and then say
(in the command line)

> do_the_stuff_in_the_file <file>

and get a file back with stuff I can read. The stuff in the file will tell
me what went wrong.

It's an added bonus if both the inputs and outputs are easy to parse.

This way I can automate everything with programs that manipulate files.

I don't know how to write a program that "clicks on buttons inside eclipse"




>
> Whether we want it or not, to the human brain images are lower level than
> text or speech. We can't read text files directly, we interpret the
> graphical representation of that text, be it on a console or a window. Some
> people can handle abstractions in their heads more easily than others. The
> latter category will need help, possibly in the form of tools to visualize
> the code (or whatever). If you are from the former category, more power to
> you, but that doesn't mean that it works for all people. It feels a bit
> like Usain Bolt saying "Bicycles? They are utterly useless, I can run
> faster than that and it's better to one's health".
>
> 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. It also
> provides a toolbox of utilities that can be used to process the code. I
> find it largely irrelevant if the environment is a GUI or not, I only need
> it to give me the information I need in the format that is best suited for
> me.
>
> It's the same kind of help one gets from a debugger: one could run the
> code in one's head and look for where the problem is, but it's much more
> effective with a tool that shows the system's exact state, not to mention
> that one can ask for a colleague or two to look at it.
>

I don't use debuggers. I write all the information I think I need into a
file and study this (in emacs :-)
and I cam mail this to a colleague if I want to.


>
> Taking a TeX example, wouldn't you find it helpful to have a window
> alongside your editor that show in real time how the document is rendered,
> without the need to run "tex mydoc.tex | pdfview&" (or whatever) yourself
> once in a while? Once you start to use more and more complicated macros,
> wouldn't be useful to be able to see the documentation for these, maybe to
> be able choose between a couple of similarly named ones?
>

Not really - I did try something like this. I make lots of small changes
while editing
and I know that the program is not ready to be run.

I do use TeX but (of course) I use a program to generate the TeX from an
emacs org file

The only time I look at the TeX is when there's a bug in the translation
program.


>
> Or in Erlang (and doing some wishful thinking), wouldn't it be useful if
> one could actually _see_ in real time the network of processes in a node,
> how they are linked/monitoring each other, how they communicate, which ones
> are growing large or seem deadlocked, zoom out for a bird-eye view or in
> for details? Or more realistically, running some tests and get diagrams of
> the process communication, where selecting a message could show details and
> the code where it is sent and received? In my humble opinion, it sure would
> beat scrolling through wades of logs and code...
>

It would be nice to "see" processes in some sense - stop time and wander
around as it were.

I actually use pencil and paper for a lot of this. It's very time consuming
to enter
diagrams into a computers.

Some kind of pad computer that could turn sketched circles and arrows into
programs
would be fantastic


>
> 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). Of course, this changes when I need to do something that
> the environment doesn't support. But even so, there is always the fallback
> of doing it as if no IDE was available, so I don't think that having an IDE
> can make things worse.
>

Both emacs and Eclipse are very complex - If I were a IDE fan I guess I'd
go for smalltalk
since I have a feeling that one day I might get my head around how it
worked. If I could just
click on anything in eclipse and bring up the code that created the GUI
control I'd be happier.

I actually rather like Javascript and how it can manipulate the DOM, it's
easy to
just do view-source in the browser and see how things work. Just because
you can see
it doesn't mean you can understand it, but javascript can be nicely written
:-)

I think an eclipse like thing in HTML5 would be great - especially since it
would
make collaborate editing etc. easier.




>
> That said, existing IDEs have widely different pros and cons, weaknesses
> and strengths. None is perfect and one of the main reasons that none can be
> perfect for everybody is that each developer has different needs and
> expectations. Make it too narrow and only few will use it. Make it too
> broad and the plethora of setting to tweak will make most people ignore
> them (thus the development effort is wasted).
>
> ****
> My vision for an IDE is that there should be a core of (narrow) tools
> cooperating to provide a broad functionality for processing source code and
> delivering useful data from the code base, tools that are agnostic of any
> way of interacting with it or of presenting the results. Think of it as
> syntax_tools on super-steroids. These tools can then be used by emacs, or
> Eclipse, or vim, or from scripts, or whatever. I am aiming for that with
> erlide, but it's a long way to go.
> ****
>
>
That would be nice.


> ---
> Knuth could do this amazing thing with TeX (practically no bugs) for all
> the reasons you stated, but also because he set very strict boundaries for
> what TeX is and can do. Basically, he not only froze the specifications, he
> set them in stone. If that would have been enough, would there have been a
> need for XeTeX, pdfTeX, laTeX and other tools that extend and improve the
> basic TeX? Would it have been possible to keep the bug levels as low if
> these extensions and improvements had been part of the core TeX?
>
> Your example of "hello \end" being easy to understand is misleading. So is
> "echo 'hello'" or "printf 'hello'" or "System.out.println("hello");" (the
> latter with some boilerplate removed). What is interesting is whether a
> real-life example is easy to understand. You say "it's just a matter of
> understanding what the primitives do", but isn't this exactly the difficult
> part with everything? "Just understanding" might mean a lot of work and
> time and effort... Given a complex document typeset in plain TeX (i.e
> without any macro libraries and containing Unicode text), the code is going
> quickly to get more that one can hold in one's head and I doubt that it's
> going to be just as easy to understand, even if one would understand
> perfectly what each primitive does. I venture to state that it would
> probably be just as easy or difficult as it would be for any well-designed
> programming language. As a matter of fact, because TeX macros can define
> their own syntax too, it might make the result more difficult to read
> (given that not all macros are written by Donald Knuth himself).
>
>
Mastering TeX I guess would take a few years of study.

It wouldn't be any fun if it were easy.

We (programmers) are like trappist monks studying the holy scrolls

Cheers

/Joe


> best regards,
> Vlad
>
>
>
>
>
>
>> The version numbering of TeX (using successive digits of Pi) is brilliant
>> TeX it at version  3.14159265 - Knuth also pays a reward (in cash) for
>> every new bug. The reward
>> doubles for each new error.
>>
>> This scheme means that the project will be abandoned if there are more
>> then 15 or so bugs - because the
>> version number would be too long, and the cost too great - and it
>> probably should be abandoned
>> if it had this number of errors.
>>
>> Knuths way of working - Literate programming - with patch files -
>> enforces an incredibly disciplined way
>> of working. TeX (as a literate program) is just about the only example I
>> know of a large complex program
>> that is understandable and has no known errors.
>>
>> TeX was produced without fancy editors and revision control systems and
>> IDEs and all that stuff.
>>
>> The only downside of Knuths way is that it takes a long time to write the
>> program.
>>
>> At a guess 80% of software costs are in maintenance of legacy code - so
>> in the long term
>> Knuthian development pays off. Being early to market with buggy software
>> is however the
>> way to make money. What earns you most money in the short term costs you
>> most in the long term.
>>
>> TeX is interesting in a sense that (say) eclipse is not. I feel it is
>> possible to learn how TeX works
>>
>> (aside I have started on this journey
>>       "Hello \end"
>> is a minimal TeX program that I can understand. All I need to do is
>> understand what
>> the primitives do, and then how the macro expansion works, ...
>> )
>>
>> There is no way I can understand something like eclipse - there is no
>> documentation of what it does and how
>> it works - only documentation of how to use it.
>>
>> I only like doing things I can understand.
>>
>> emacs is in the TeX category - I can "in principle" read the code and see
>> what it does
>>
>> (another aside - reading code to see what it does is highly overrated -
>> reading my own code
>> that I wrote years ago is difficult - reading other peoples code is
>> doubly difficult - reading undocumented
>> code in a language I don't really understand to fix a bug that I didn't
>> want to fix into order to solve a problem
>> that I do want to solve is an incredible waste of time - and that's why I
>> like Kuthian rigour in software)
>>
>> Nowhere have I said that this is easy - but I believe that IDEs etc make
>> matters worse by hiding
>> what should not be hidden. If it's such a mess that it needs tool support
>> to write then the solution is
>> to clean up the mess not provide tools to hide the mess.
>>
>> As I said - I could write a book on this :-)
>>
>> Cheers
>>
>> /Joe
>>
>>
>>> and what some people like in programming languages (Joe, for example),
>>> somebody should do an Erlide for Elixir.
>>>
>>> Regards,
>>> Michael Turner
>>> Executive Director
>>> Project Persephone
>>> K-1 bldg 3F
>>> 7-2-6 Nishishinjuku
>>> Shinjuku-ku Tokyo 160-0023
>>> Tel: +81 (3) 6890-1140
>>> Fax: +81 (3) 6890-1158
>>> Mobile: +81 (90) 5203-8682
>>> turner@REDACTED
>>> http://www.projectpersephone.org/
>>>
>>> "Love does not consist in gazing at each other, but in looking outward
>>> together in the same direction." -- Antoine de Saint-Exupéry
>>>
>>>
>>> On Fri, Jan 31, 2014 at 3:25 PM, kraythe . <kraythe@REDACTED> wrote:
>>> > Well I think after seeing the arguments and the response of the
>>> community I
>>> > am trending seriously towards Erlang. I will probably make the mental
>>> > investment to learn and become good with emacs. And then move on from
>>> there.
>>> > I may still have a ton of questions. I would still, for example, love
>>> to
>>> > know who to 'reload' my application once it is started.
>>> >
>>> >
>>> > On Fri, Jan 31, 2014 at 12:24 AM, kraythe . <kraythe@REDACTED> wrote:
>>> >>
>>> >> Well I think after seeing the arguments and the response of the
>>> community
>>> >> I am trending seriously towards Erlang. I will probably make the
>>> mental
>>> >> investment to learn and become good with emacs. And then move on from
>>> there.
>>> >> I may still have a ton of questions. I would still, for example, love
>>> to
>>> >> know who to 'reload' my application once it is started.
>>> >>
>>> >> Robert Simmons Jr. MSc. - Lead Java Architect @ EA
>>> >> Author of: Hardcore Java (2003) and Maintainable Java (2012)
>>> >> LinkedIn: http://www.linkedin.com/pub/robert-simmons/40/852/a39
>>> >>
>>> >>
>>> >> On Thu, Jan 30, 2014 at 10:29 PM, Richard A. O'Keefe <
>>> ok@REDACTED>
>>> >> wrote:
>>> >>>
>>> >>>
>>> >>> On 31/01/2014, at 7:49 AM, Steve Strong wrote:
>>> >>> > On Thursday, 30 January 2014 at 19:10, kraythe . wrote:
>>> >>> >> 1) Code completion. Sorry but I can't be bothered to type the same
>>> >>> >> flipping method name in its entirety 40 times.
>>> >>>
>>> >>>
>>> >>> There are three causes for "completion" in languages like
>>> >>> Prolog and Erlang:
>>> >>>
>>> >>> (a) Definitions with multiple clauses.
>>> >>>     Your editor should be able to turn "add a clause" into a
>>> >>>     single command.
>>> >>>
>>> >>> (b) Recursion.
>>> >>>     Your editor should be able to turn "add a recursive call"
>>> >>>     into a single command (basically the same as (a), just
>>> >>>     different stuff wrapped around it).
>>> >>>
>>> >>>     A programming style using higher order procedures can
>>> >>>     eliminate a lot of this.
>>> >>>
>>> >>> (c) Repetitive patterns of code.
>>> >>>
>>> >>>     A programming style using higher order procedures can
>>> >>>     eliminate a lot of this.
>>> >>>
>>> >>> There's a thing I find myself saying more and more often:
>>> >>>
>>> >>>         Why can't I see the structure?
>>> >>>
>>> >>> I was reviewing a page or two of Prolog code for someone the
>>> >>> other day.  By the end of three hours, I'd made some progress,
>>> >>> but I was troubled.  The code was clean, but it wasn't OBVIOUS.
>>> >>> What finally dawned on me would have been instantly obvious to
>>> >>> a real functional programmer:  the code was an interweaving of
>>> >>> a "compute argmax of a partial function over a finite domain"
>>> >>> and "here is this partial function".  Actually introducing the
>>> >>> higher order function in question let me explore several ways
>>> >>> of implementing that *without* any effect on the rest of the
>>> >>> code.  Breaking the specific partial function out and naming
>>> >>> it let me see that memoising *that* function -- which hadn't
>>> >>> previously existed -- stood an excellent chance of reducing
>>> >>> the overall cost of the algorithm down *hugely*.
>>> >>>
>>> >>> So I say, if you find yourself _wanting_ a method name to
>>> >>> appear 40 times in a day's work, you are doing something
>>> >>> badly wrong.
>>> >>>
>>> >>> For another data point, as part of building up my Smalltalk
>>> >>> skills, I used to pick up Java code and rewrite it in Smalltalk.
>>> >>> There were two invariable results:  first, the code would
>>> >>> shrink by about a factor of six, and second, it would become
>>> >>> painfully obvious that the original code was really really
>>> >>> bad design, and that in a *good* OO design, most of the
>>> >>> classes wouldn't just shrink, they'd disappear.  A good part
>>> >>> of this is down to Smalltalk's support for and extensive use
>>> >>> of higher order functions from day 1.
>>> >>>
>>> >>> >
>>> >>> > 3) Syntax coloring. (VIM color codes a file so that is there,
>>> emacs I
>>> >>> > don't know AT ALL.)
>>> >>> To which Steve Strong replied
>>> >>> > I don't know of any editor that doesn't do this -
>>> >>> > even github displays syntax colouring on erlang files.
>>> >>>
>>> >>> My own text editor doesn't do syntax colouring.
>>> >>> Frankly, I hate syntax colouring.  I could give you
>>> >>> a long rant about why.  One big issue is that the
>>> >>> name is a lie.  It's *lexical* colouring; the colour
>>> >>> depends on what kind of token something is.  But I
>>> >>> can *see* that.  If you offered me an editor where
>>> >>> calls to functions whose definitions had been edited
>>> >>> recently were brightly coloured, or where the functions
>>> >>> imported from a particular module were brightly coloured,
>>> >>> or where slicing was used to colour the places where a
>>> >>> particular variable could be *changed* and *used*, I'd
>>> >>> find that really really helpful.  Why waste colour
>>> >>> telling me something that is already obvious at a glance?
>>> >>> I once came across a compiler (written in Finland) where
>>> >>> several passes had had to be woven together because of
>>> >>> the language it was written in, so they had coloured
>>> >>> each declaration and statement according to which pass
>>> >>> it was logically part of.  Now _that's_ good use of colour!
>>> >>>
>>> >>> >
>>> >>
>>> >>
>>> >
>>> >
>>> > _______________________________________________
>>> > erlang-questions mailing list
>>> > erlang-questions@REDACTED
>>> > http://erlang.org/mailman/listinfo/erlang-questions
>>> >
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140131/9dff49f7/attachment.htm>