[erlang-questions] Large-scale Erlang in practice

[Prashant Sharma]

+1 for Tim's idea here. Above that I feel with the advent of
autocompletion etc... and IDE's the code is less readable otherwise
and becomes imperative to use them, thus they are not just an option.
I love the way things are with vi/emacs. :) There is definitely a
world of difference between JAVA( or others on similar lines.) and
thus love to write code for them in IDEs.

Wonder if something we could do, like clojure's clear cut idea of
managing namespaces. :)

On Wed, Feb 8, 2012 at 2:19 AM, Tim Watson <watson.timothy@REDACTED> wrote:
> On 7 February 2012 19:39, Max Bourinov <bourinov@REDACTED> wrote:
>>
>> I believe that Erlang is perfect the way it is.
>
>
> I love Erlang's simplicity and it's been pretty much my favorite development
> platform for the past few years now. I would like to be able to refer to a
> module *via* some additional context though, whether that is the application
> it resides in or a package/namespace.
>
>>
>>
>> I see problem in absence of good IDE/editors for Erlang (yes, emacs is way
>> not perfect).
>>
>
> Personally I get along fine with vim, but erlide is cool for those who want
> to use it.
>
>>
>> If there will be a tool like IntelliJ IDEA for Erlang, there will be no
>> problems with typing very_long_names any more. Auto completion rules.
>>
>
> Yes but my point about very_long_module_names is not just that it is ugly
> and painful to type. I can get autocompletion in vim/emacs today so that's
> not the issue. The point is that as the number of libraries/applications I
> am able to choose from increases (and let's face it, they're growing fast)
> I'm increasingly being forced to deal with module name clashes *or* to put
> up with very long names which are distracting to look at - they take focus
> away from the *function* that is being called, which is what *I* want to
> focus on.
>
> Maybe it's just me, and I'm in no way suggesting I know how to fix this. I
> would like to be able to run rabbitmq and riak in the same vm without a
> module name clash though, and it is there that currently one of several
> things has to happen:
>
> 1. both rabbit and riak-<whatever> rename their copy of gen_server2 to
> riak_gen_server2/rabbit_gen_server2
> 2. I let the first one on the code path get loaded and hope to the gods that
> it *behaves* properly for both applications
> 3. I give up and run them in a separate vm
>
> None of these are satisfactory, especially as (1) isn't likely to happen.
> What might make this go away could be something like:
>
> - module code scoped to "application domains" i.e., to the application the
> beam file resides in - so as not to clash
> - modules within the same "application domain" referring to one another
> default to the same domain - so if app1 contains [mod1, mod2] and mod1 calls
> a function via `mod2:do_it(...)` then the function is resolved to the module
> `mod2` in the same application domain
> - we get the ability to `import` modules from external application domains,
> so that I can call stuff in other apps when I want to.
>
> % import everything in kernel and stdlib - this should probably be a default
> attribute!
> -import_app([kernel, stdlib]).
>
> % import a specific module from a specific app-domain
> -import_mod(rabbitmq, [gen_server2]).
>
> start() ->
>     %% this resolves to the gen_server2 beam which resides in the rabbitmq
> application
>     gen_server2:start(...).
>
>> (there is plugin for idea to write Erlang code, but I didn't find it
>> useful)
>
>
> I *have* to use intelliJ to write java code, because it's so complicated to
> write anything in java that without a good IDE it takes forever. I agree
> wholeheartedly that Erlang is a better language precisely because I *don't*
> need an IDE to be productive with it.
>
>>
>>
>> Sent from my iPhone
>>
>> On 07.02.2012, at 21:25, Tim Watson <watson.timothy@REDACTED> wrote:
>>
>> On 7 February 2012 11:27, Mihai Balea <mihai@REDACTED> wrote:
>>>
>>>
>>> On Feb 6, 2012, at 2:38 PM, Tim Watson wrote:
>>>
>>> On 6 February 2012 19:24, Jon Watte <jwatte@REDACTED> wrote:
>>>>
>>>> That is interesting -- it might make it worth it to upgrade to R14.
>>>>
>>>> Also, we found a module called "gen_server2" that works around this
>>>> problem by draining the message queue before calling any callback, and
>>>> then dispatching messages based on this list of drained messages. Does
>>>> anyone have experience with this module?
>>>>
>>>
>>> It is part of rabbitmq, which I'm guessing it's reasonable to call
>>> *fairly stable and production worthy* lol. I keep a copy as a standalone OTP
>>> library application on github, which I update/synchronise periodically with
>>> updates from the rabbit hg/git repository. I haven't refreshed it in a
>>> while, as we're largely >= R14 now, but I find this approach (of bundling it
>>> as a standalone library app) works nicely for making it available across
>>> projects, though I'm less reliant on it now as I'm not using the extra
>>> features it provides in addition to message queue draining.
>>>
>>>
>>> I wish there was an "official" standalone version of gen_server2.
>>> Rabbitmq includes it, the Erlang rabbitmq client includes it as well,
>>> riak_core too plus a variety of individuals like Tim have created standalone
>>> versions based on one of the above. If one attempts to combine, say,
>>> riak_core with the rabbitmq erlang client, frustration ensues.
>>>
>>
>> Actually this issue (of duplicate uses of the same module name) has to do
>> with lack of namespace/package support and isn't so simple to solve - at
>> least based on the myriad discussions on this list regarding the issue, none
>> of which have yielded a satisfactory answer. Personally I think that whilst
>> the java/.net approach of providing a namespace such as
>> org.foobar.appname.package...etc might be flawed/imperfect, but it's a lot
>> better than having clashes. The reason it works well in practise is that you
>> can import modules via their namespace which reduces finger ache and you can
>> always fully qualify a *thing* you want to use if there is a potential
>> clash. Personally, I don't mind renaming gen_server2 to
>> nebularis_gen_server2 but I just don't want to have to type that all the
>> time. On the other hand, if packages were fully supported I could do this:
>>
>> -import(org.nebularis.gen_server2).
>> doodah() -> gen_server2:start(....).
>>
>>
>> But of course in todays system there are numerous tools (reltool, cover,
>> etc) that do not work properly with packages *and* you have to import "top
>> level" modules as well, which is just a pain in the arse:
>>
>> -import(lists). %% but why!!!
>>
>> I *know* there are potentially better ways and I fully recognise that
>> there is little difference semantically between a_b and a.b, but it's not a
>> about the separator, it's about the tedium of typing in long names, not to
>> mention the fact the
>> a_very_long_series_of_different_segments_separated_by_underscores is
>> appalling to read.
>>
>> Personally I'd like to see behaviours and import come together so I can
>> define take the gen_server(2) behaviour and import an implementation at the
>> top level:
>>
>> -api(gen_server2, nebularis_genserver2).
>>
>>>
>>> Mihai
>>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>



-- 
Prashant Sharma
Mtech CSE
IIIT Hyderabad.

"Hare Krishna"