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

[Richard A. O'Keefe]

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!

>