[erlang-questions] packages (was: newbie: why c.erl is special?)

[David Mercer]

Maybe we should name all our modules with a GUID.  That would reduce the
likelihood of module name clashes down close to zero.

 

J

 

Cheers,

 

DBM

 

  _____  

From: erlang-questions-bounces@REDACTED
[mailto:erlang-questions-bounces@REDACTED] On Behalf Of Robert Virding
Sent: Thursday, March 06, 2008 17:57
To: Steve Vinoski
Cc: erlang-questions
Subject: Re: [erlang-questions] packages (was: newbie: why c.erl is
special?)

 

On 06/03/2008, Steve Vinoski <vinoski@REDACTED> wrote:

On 3/6/08, Sean Hinde <sean.hinde@REDACTED> wrote:
>  One of the worst aspects of this would be the endless traversing up
>  and down interminable directory hierarchies. Soon we would need a full
>  IDE just to help us find the definition of a module in the filesystem.


YES! I was about to point out the same thing, and I'm very glad to
know I'm not alone in my thinking. Java's abuse of the filesystem in
this manner is very annoying, for example, and pushing Erlang to that
model would be a huge mistake IMO.


One of our original goals, which is seldom mentioned today, was that we
wanted to keep the language *simple*! Then many programmers in Ericsson, who
were out potential users, were not very experienced and not well trained in
the art/science of programming. This is one reason why features considered
standard were added later. This may not have been a good design decision but
it did result in a small simple base language. I have read on the net
discussions about designing languages for the masses, or not.

And, whatever its warts, a flat module system is easy to comprehend. If you
call module foo there is only one module foo to which it can refer,
irrespective of from where it is called. And you can always use naming
conventions to handle the case of many modules in an application or
sub-system.

 

Robert

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080307/0b1e0e34/attachment.htm>