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

Sylvain Benner <>
Tue Feb 4 14:39:59 CET 2014


If you are familiar with Vim I recommend installing the evil-mode right 
away, it is the one of the most complete Vim key bindings emulation. You 
will feel like home with it and you will be one of the happy Emacs/Vim 
strange kind of user (monster?!) which can enjoy the best* text editor on 
this planet: Emacs+Vim.

Annnnnnd you will be able to enjoy the best* programming environment for 
Erlang: EDTS [1] which is of course written partly in Erlang :-)
For example, EDTS evaluates eunit tests as you modify them and show the 
result visually in the buffer by underlining the test name in green en red, 
put the cursor on the test name and you have your failed assertion. And 
this is just a small example of what EDTS does.

cheers,
syl20bnr

[1] https://github.com/tjarvstrand/edts
* very personal opinion there :-)


Le vendredi 31 janvier 2014 01:25:17 UTC-5, kraythe a écrit :
>
> 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 . <<javascript:>
> > 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 
>> <http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
>>  
>>
>> On Thu, Jan 30, 2014 at 10:29 PM, Richard A. O'Keefe <<javascript:>
>> > 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!
>>>
>>> >
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140204/bd13312b/attachment.html>


More information about the erlang-questions mailing list