<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">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.</span><br>
<div class="gmail_extra"><div><div dir="ltr"></div></div>
<br><br><div class="gmail_quote">On Fri, Jan 31, 2014 at 12:24 AM, kraythe . <span dir="ltr"><<a href="mailto:kraythe@gmail.com" target="_blank">kraythe@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">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.</div>
<div class="gmail_extra"><br clear="all"><div><div dir="ltr"><div class="im"><div style="font-family:arial;font-size:small"><b>Robert Simmons Jr. MSc. - Lead Java Architect @ EA</b></div></div><div class="im"><div style="font-family:arial;font-size:small">
<i>Author of: Hardcore Java (2003) and Maintainable Java (2012)</i></div>
</div><div><i style="font-family:arial;font-size:small">LinkedIn: </i><font face="arial"><i><a href="http://www.linkedin.com/pub/robert-simmons/40/852/a39" target="_blank">http://www.linkedin.com/pub/robert-simmons/40/852/a39</a></i></font></div>
</div></div><div><div class="h5">
<br><br><div class="gmail_quote">On Thu, Jan 30, 2014 at 10:29 PM, Richard A. O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
On 31/01/2014, at 7:49 AM, Steve Strong wrote:<br>
> On Thursday, 30 January 2014 at 19:10, kraythe . wrote:<br>
</div><div>>> 1) Code completion. Sorry but I can't be bothered to type the same flipping method name in its entirety 40 times.<br>
<br>
<br>
</div>There are three causes for "completion" in languages like<br>
Prolog and Erlang:<br>
<br>
(a) Definitions with multiple clauses.<br>
Your editor should be able to turn "add a clause" into a<br>
single command.<br>
<br>
(b) Recursion.<br>
Your editor should be able to turn "add a recursive call"<br>
into a single command (basically the same as (a), just<br>
different stuff wrapped around it).<br>
<br>
A programming style using higher order procedures can<br>
eliminate a lot of this.<br>
<br>
(c) Repetitive patterns of code.<br>
<br>
A programming style using higher order procedures can<br>
eliminate a lot of this.<br>
<br>
There's a thing I find myself saying more and more often:<br>
<br>
Why can't I see the structure?<br>
<br>
I was reviewing a page or two of Prolog code for someone the<br>
other day. By the end of three hours, I'd made some progress,<br>
but I was troubled. The code was clean, but it wasn't OBVIOUS.<br>
What finally dawned on me would have been instantly obvious to<br>
a real functional programmer: the code was an interweaving of<br>
a "compute argmax of a partial function over a finite domain"<br>
and "here is this partial function". Actually introducing the<br>
higher order function in question let me explore several ways<br>
of implementing that *without* any effect on the rest of the<br>
code. Breaking the specific partial function out and naming<br>
it let me see that memoising *that* function -- which hadn't<br>
previously existed -- stood an excellent chance of reducing<br>
the overall cost of the algorithm down *hugely*.<br>
<br>
So I say, if you find yourself _wanting_ a method name to<br>
appear 40 times in a day's work, you are doing something<br>
badly wrong.<br>
<br>
For another data point, as part of building up my Smalltalk<br>
skills, I used to pick up Java code and rewrite it in Smalltalk.<br>
There were two invariable results: first, the code would<br>
shrink by about a factor of six, and second, it would become<br>
painfully obvious that the original code was really really<br>
bad design, and that in a *good* OO design, most of the<br>
classes wouldn't just shrink, they'd disappear. A good part<br>
of this is down to Smalltalk's support for and extensive use<br>
of higher order functions from day 1.<br>
<div><br>
><br>
> 3) Syntax coloring. (VIM color codes a file so that is there, emacs I don't know AT ALL.)<br>
</div>To which Steve Strong replied<br>
<div>> I don’t know of any editor that doesn’t do this -<br>
> even github displays syntax colouring on erlang files.<br>
<br>
</div>My own text editor doesn't do syntax colouring.<br>
Frankly, I hate syntax colouring. I could give you<br>
a long rant about why. One big issue is that the<br>
name is a lie. It's *lexical* colouring; the colour<br>
depends on what kind of token something is. But I<br>
can *see* that. If you offered me an editor where<br>
calls to functions whose definitions had been edited<br>
recently were brightly coloured, or where the functions<br>
imported from a particular module were brightly coloured,<br>
or where slicing was used to colour the places where a<br>
particular variable could be *changed* and *used*, I'd<br>
find that really really helpful. Why waste colour<br>
telling me something that is already obvious at a glance?<br>
I once came across a compiler (written in Finland) where<br>
several passes had had to be woven together because of<br>
the language it was written in, so they had coloured<br>
each declaration and statement according to which pass<br>
it was logically part of. Now _that's_ good use of colour!<br>
<br>
><br>
</blockquote></div><br></div></div></div>
</blockquote></div><br></div></div>