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

[Sylvain Benner]

Oops seems that I missed 2 full pages of discussion... EDTS has already 
been mentioned.

Le mardi 4 février 2014 08:39:59 UTC-5, Sylvain Benner a écrit :
>
> 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 . <kra...@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 
>>> <http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
>>>  
>>>
>>> On Thu, Jan 30, 2014 at 10:29 PM, Richard A. O'Keefe <
>>> o...@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!
>>>>
>>>> >
>>>>
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140204/de2c88ea/attachment.htm>