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

[Thomas Lindgren]

The basics of reloading your app or modules:

- the simple way while developing is to write l(modulename). in the erlang shell to reload modulename for that VM.

- if you want to be more sophisticated about it, dig into how OTP applications work

There are also a number of hacks that let you reload all changed modules. Here's one:
https://github.com/thomasl/erlang-repl-utils


Best,
Thomas




On Friday, January 31, 2014 7:25 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.
>
>
>
>
>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
>>
>>
>>
>>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/0c80a8cc/attachment.htm>