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

[Michael Turner]

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