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

Fri Jan 31 08:49:40 CET 2014

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.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140131/008730a6/attachment.htm>