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

Thu Jan 30 19:49:21 CET 2014

I’m an emacs guy, and most of what you want is in there - however, completely understand the pain in switching editors, so some vim-specific comments below...  

--  
Steve Strong
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

On Thursday, 30 January 2014 at 19:10, kraythe . wrote:

> I would pose a couple of questions tool wise then. Keep in mind that there are likely answers to these questions I don't know so please don't detect attitude but rather inquisitiveness. With my tools I want the following as a must:  
>  
> 1) Code completion. Sorry but I can't be bothered to type the same flipping method name in its entirety 40 times.  
>  
looks like vim can do this: http://blogs.gnome.org/lharris/2008/07/20/code-completion-with-vim-7/.  I’m sure there are other options as well...

>  
> 2) Redeploy in running app or quick restart. I worked a tutorial on a rebar based application and then when I changed it I had to do:   
>  
> --> (ctrl-G) q
> $ myapp stop
> $ myapp start
> $ myapp attach
>  
>  
>  

Try something like https://github.com/rustyio/sync (reloads beam files whenever they change) combined with something like https://github.com/mynyml/watchr (watches a directory, and runs a command (such as “make”) whenever anything changes).  That way, you save the file and then test the results.  No need to stop / start the VM in the majority of cases.  Even better would be to have a test suite rather than an interactive prompt and just have the tests automatically execute.
>  
> That is a development cycle that would drive me NUTS.
>  
> 3) Automatic dependency fetching. I understand rebar can do some of this but how do I fix versions of modules and so on? Do I have to compile every third party lib?  
rebar.config (and erlang.mk is you wanted a pure make approach) can both fetch deps, and both support fixing the version of the deps that are pulled, by tab, by branch, by commit hash etc.  And yes, you do need to compile them - but the occasional “rebar compile” doesn’t seem much overhead.

>  
> 3) Syntax coloring. (VIM color codes a file so that is there, emacs I don't know AT ALL.)
I don’t know of any editor that doesn’t do this - even github displays syntax colouring on erlang files.  
>  
> 4) Editor easiness, files window, project overview, configuration, etc.  
not a user of VIM (emacs does this stuff just fine), but a single google search reveals http://vimdoc.sourceforge.net/htmldoc/windows.html - which suggests it can do pretty much everything  
>  
> 5) Refactoring. This is one of the tools I am reluctant to give up. If I change the signature of a method I do not want to have to go change 40 files manually. NO thanks.  
This is something that’s harder - there’s a plugin for Emacs called Wrangler that can do some refactoring, don’t know of anything for VIM.  That said, although I’m an emacs guy, I don’t bother with Wrangler.  If changing a method signature means I have to edit 40 other files, then I think I’ve got *much* bigger problems.  The insanely good refactoring support in Visual Studio (particularly with Resharper) enables the hiding of a multitude of sins, allowing code to become far too closely coupled without noticing until way too late in development.  Not having that kind of support makes me write better code in the first place.  The only time I’d be needing to edit a lot of files is if I’m changing so very low level utility - typically, these tend to be so trivial that they rarely if ever change, so it’s not often a problem.  
>  
> It could be I have to learn Emacs. Being a vi guy for 20 years, that will take some adaptation I can tell you.   
>  
I certainly wouldn’t suggest switching editors - although the religious zealots will insist that one is far better than the other, the reality (imo) is that both are highly capable and can do the bulk of what people need with a few hours work on google and with the configuration.

Hope that helps!

Cheers,

Steve

> LinkedIn: http://www.linkedin.com/pub/robert-simmons/40/852/a39
>  
>  
>  
>  
> On Thu, Jan 30, 2014 at 11:12 AM, Steve Strong <steve@REDACTED (mailto:steve@REDACTED)> wrote:
> > I'll chip in on the part about the tooling - I was a C# / Visual Studio dev for 10+ years when I switched to erlang. For the first perhaps 4 weeks, I missed hitting 'dot' and having the computer tell me what to do; then I started noticing that I was actually remembering what stuff did, rather than relying on the IDE.  
> > I also found the build tool chain awkward, but it turned out that 'make' was rather good - and the total lack of black magic made it obvious how to fix build / release issues when they did occur (ignoring here the rather arcane syntax for retool!)
> > Within a couple of months I've no doubt that I was more productive than I'd been in Visual Studio, and now, 3+ years on, you'd have to pay me significant sums of money to go back to those 'advanced' tools.
> > Cheers,
> > Steve
> > On 30 Jan 2014 17:58, "Ulf Wiger" <ulf@REDACTED (mailto:ulf@REDACTED)> wrote:
> > >  
> > > On 30 Jan 2014, at 17:19, kraythe . <kraythe@REDACTED (mailto:kraythe@REDACTED)> wrote:
> > > > The tools are, well frankly, garbage. Sorry, in 2014 to be pushed back to coding with VIM and makefiles is primitive.  
> > > So use Emacs. ;-)
> > >  
> > > Seriously, there are a few reasons why the tools are garbage compared to e.g. the Java community’s, but here’s the main reason:
> > >  
> > > For one thing, they are not needed as much. I once participated in a code kata track, where (as it happened) the same problem was solved in several different languages. The idea was to let the audience lead, but the only ones who did that were I and the Ruby guy - and we and the Clojure guy were the only ones who completed the task on time. This, even though we stuck to Emacs and had no other fancy tools. The Java team and the C# guy ran out of time.  
> > >  
> > > The Java guys - two experts, pair programming rather than involving the audience - ripped through with IntelliJ, but still didn’t finish the task on time. Still, it was amazing to see what the tool could do. Talking to some Java experts afterwards, the consensus seemed to be that “yeah, the tools are fantastic, but the problem is that you’re dead in the water without them”. Also, some complaints were raised that the tool support distances you as a developer from the raw implementation, especially when the tool automatically generates a lot of your code for you.  
> > > To some extent, this also applies to the libs question. You might well get done faster even if you end up having to do work that you wouldn’t have to in Java, since writing your own lib in Erlang can often be less work than using an existing lib in Java. ;-)  
> > >  
> > > Since most Erlang programmers are quite comfortable using Emacs or Vim, it’s hard to get traction for a tool development project. There have been attempts, but overall, most (?) Erlang devs don’t feel that they need such tools to be productive.  
> > >  
> > > But mostly, the things to look for are the major snags - the ones that could kill your project. How much support can you get from the respective communities for the kind of application you have in mind? How mature are the components you will have to rely on? Etc.  
> > >  
> > > Depending on your application domain, the anwers to those questions are likely to vary.
> > >  
> > > BR,
> > > Ulf W
> > >  
> > > Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
> > > http://feuerlabs.com
> > >  
> > >  
> > >  
> > >  
> > >  
> > > _______________________________________________
> > > erlang-questions mailing list
> > > erlang-questions@REDACTED (mailto: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/20140130/bf0164ea/attachment.htm>