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

[kraythe .]

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