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

[João Neves]

I'd like to add that since you're taking the dive into Emacs-land, I
*highly* recommend that you setup EDTS (https://github.com/tjarvstrand/edts)
to get some nice stuff like autocompletion, automatic running of EUnit
tests, per-project settings (like which version of Erlang you want to work
with) and a bunch of other niceties.

Makes for a smoother transition if you come from the Java world with all
the tools the IDEs give you.

--
João Neves


2014-01-31 kraythe . <kraythe@REDACTED>:

> 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!
>>>
>>> >
>>>
>>
>>
>
> _______________________________________________
> 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/20140201/be5199fe/attachment.htm>