[erlang-questions] Large-scale Erlang in practice

[Bengt Kleberg]

Greetings,

To what extent would something like LACE
(http://archive.eiffel.com/doc/manuals/technology/lace/subcluster/page.html), but for Erlang, handle your problems?


bengt

On Wed, 2012-02-08 at 02:06 +0100, Tim Watson wrote:
> On 7 February 2012 22:00, Attila Rajmund Nohl
> <attila.r.nohl@REDACTED> wrote:
>         2012/2/7, Tim Watson <watson.timothy@REDACTED>:
>         [...]
>         > 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.
>         
>         
>         In the AXD301 the module names were prefixed with the
>         subsystem name,
>         so for example many subsystems could have a library module
>         with name
>         like xyzLib. I guess this was enforced on project level.
> 
> 
> Yes I'm not surprised because everybody (including me) is still doing
> this today. You can see modules called riak_something and
> rabbitmq_something and mochiweb_something, etc etc. I have no problem
> with this, but if people *don't* follow this convention then you run
> into trouble.
>  
>         
>         Honestly, C doesn't have packages either, still applications
>         can use
>         dozens of libraries. Even though the situation is not exactly
>         the same
>         (in C the internal names can "clash"), the API functions are
>         (in many
>         cases) religiously prefixed with the library name. An this
>         worked for
>         the last 40 years.
> 
> Yes it can be made to work with, as you put it, religious adherence to
> coding standards, but C is hardly the poster child for making this
> stuff easy. In fact C is notoriously annoying when it comes to name
> clashes, forcing you to write statically linked wrappers to re-export
> symbols with alternative names and/or mess around with symbol renaming
> tools. I'm sure there are many clever things that people do in order
> to make writing assembler code manageable, but that doesn't mean we
> should consider those good approaches for high level languages like
> Erlang does it? 
> 
> 
> I suppose a simple approach to the "long names" complaint might be to
> write a common parse_transform that appends a configurable
> "<organisation>_<project>_" prefix to modules during the build and
> generates a bit of metadata in the application config file. That way I
> can write my own code in a pithy fashion, have the generated modules
> *fully qualifies* and have other code that uses it consume the full
> name. If someone else wants to take advantage of the concise names,
> they can include the parse_transform in their build and take advantage
> of whatever `-special_import(...)` directive(s) it makes available for
> mapping short names to fully qualified module names during the AST
> transform.
> 
> 
> But I still think that having a coarser grained scoping/grouping
> construct than modules would be useful. This is obviously what
> applications are for, but they're not *first class* citizens in the
> way modules are. For example, another IMO great benefit that
> application level scoping of modules would bring is the ability to
> provide an export directive that makes functions callable from within
> your application (i.e., between the modules in app123) but *not* by
> outside callers. From an API design perspective, that would be very
> nice to have, as I often need to export shared code for use in my
> application but don't really want external callers to depend on it.
> 
>