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

[Vlad Dumitrescu]

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...

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.

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?

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...

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.

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.
****

---
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).

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/2aad94f1/attachment.htm>