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

[Håkan Huss]

Just thought I'd interrupt the IDE war^H^H^Hdiscussion and pick up the
"reload" question.

Hot code loading is one of the fundamental parts of Erlang, so reloading by
restarting the entire node is normally not necessary. During development
and testing (and in emergencies on running customer sites :-) when only one
or a few modules have changed it would normally be sufficient to do 'make'
(or 'rebar compile' or what have you), copying the .beam files to the
affected node(s), opening a shell connected to the node and loading the new
versions of the modules with the shell command l (or nl in the distributed
case) and that's it. The new code is running without any need for restarts.

Of course, if the new code changes data representation or APIs, or there
are processes that are running long-lived calls to the affected modules
there may be additional steps. Then I might use the application/release
upgrade support that OTP offers even in development. And when upgrading a
production system this is of course always a good way. It takes some work
to understand the appup/relup support, but it is well invested effort.

Regards,
/Håkan


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/20140131/86b90ff9/attachment.htm>