Time to update programming rules?

[wildchild]

http://www.erlang.se/doc/programming_rules.shtml

7.7 Module names

Erlang has a flat module structure (i.e. there are not modules within
modules). Often, however, we might like to simulate the effect of a
hierarchical module structure. This can be done with sets of related
modules having the same module prefix.

If, for example, an ISDN handler is implemented using five different
and related modules. These module should be given names such as:
isdn_init
isdn_partb
isdn_...

We have packages! http://www.erlang.se/publications/packages.html
_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

[Jon Gretar Borgthorsson-3]

Nice.

This is the first time I have heard about them.

So I guess it really is time to update the documentation.

On Thu, Sep 4, 2008 at 9:01 PM, WildChild <alexander.uvarov@...> wrote:

http://www.erlang.se/doc/programming_rules.shtml

7.7 Module names

Erlang has a flat module structure (i.e. there are not modules within
modules). Often, however, we might like to simulate the effect of a
hierarchical module structure. This can be done with sets of related
modules having the same module prefix.

If, for example, an ISDN handler is implemented using five different
and related modules. These module should be given names such as:
isdn_init
isdn_partb
isdn_...

We have packages! http://www.erlang.se/publications/packages.html
_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

[Richard O'Keefe]

On 5 Sep 2008, at 9:01 am, WildChild wrote:

> http://www.erlang.se/doc/programming_rules.shtml
>
> 7.7 Module names
>
> Erlang has a flat module structure (i.e. there are not modules within
> modules). We have packages! http://www.erlang.se/publications/packages.html

Yes, but
(a) we should not use them because they are inside out, and
(b) packages are NOT "modules within modules".
Poplog, Ada, and SML have modules within modules.
Modules within modules are much more like Java nested classes
than they are like Java packages.







_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

[Edwin Fine]

Richard,

Please will you clarify what you mean by

(a) we should not use them because they are inside out

?

Do you mean, we should not use these facilities at all, ever, because the design is badly flawed, or we should not use them in the way the documentation proposes, because it's "inside out", and there's a better way? Or both, or neither? What do you mean by "inside out"?

On Thu, Sep 4, 2008 at 10:37 PM, Richard A. O'Keefe <ok@...> wrote:

On 5 Sep 2008, at 9:01 am, WildChild wrote:

> http://www.erlang.se/doc/programming_rules.shtml
>
> 7.7 Module names
>
> Erlang has a flat module structure (i.e. there are not modules within

> modules). We have packages! http://www.erlang.se/publications/packages.html

Yes, but
(a) we should not use them because they are inside out, and
(b) packages are NOT "modules within modules".
Poplog, Ada, and SML have modules within modules.
Modules within modules are much more like Java nested classes
than they are like Java packages.

_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

[Richard O'Keefe]

On 5 Sep 2008, at 2:55 pm, Edwin Fine wrote:

> Richard,
>
> Please will you clarify what you mean by
>
> (a) we should not use them because they are inside out

I have discussed this at length in this mailing list.

> Do you mean, we should not use these facilities at all, ever,  
> because the design is badly flawed,

Yes.
>

One fundamental issue is that dotted names are just that:
a *FLAT* module name space that just happens to allow dots
in identifiers.  Since Erlang already allows @ signs in
identifiers, if we had wanted to use names like
     mnesia@CORBA@connector@impl
we could have and can still.  (Think of the "@" signs as
"fat dots".)  Allowing dots in identifiers doesn't, in
principle, accomplish anything that allowing at-signs in
identifiers doesn't.

Well, there's some sort of abbreviation rule, but all that
does is to mess things up horribly.  It is now possible for
two *different* names to refer to the *same* module.  It is
also possible for a module (with no mentions of its name
anywhere other than ?MODULE) to break if you change its name.
In fact, changing the name of a module that doesn't mention
its name ANYWHERE other than the -module directive can break it.

Why I say it's inside-out is that "compound names" for modules
need to be relative to the starting module, not "absolute",
so that you can move an entire cluster of related modules
in a single renaming, WITHOUT having to hack on every single
file.

The design also perpetuates a great nastiness from Java, that
of mixing up the dotting structure of module names with the
arrangement of files in a file system.  I have just spent a
painful half hour trying to read the documentation and sources
for a Haskell package I'd like to use.  They've followed Java's
lead with module names.  One result is that what seems to this
potential user like *ONE* thing is actually broken up into
about 30 pieces; instead of one coherent manual there are
disconnected bits all over the place.  Instead of one directory
with all the source files, there is a great tree with files,
even files that are conceptually at the same level, not only
in different directories but in directories at different levels.

The right thing to do is to have a "configuration" language like
C/Mesa or LACE.

_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

[Benjamin Tolputt-2]

Edwin Fine wrote:
> Richard,
>
> Please will you clarify what you mean by
>
> (a) we should not use them because they are inside out

I too would like some clarification on this. Is this because you
disapprove of the design (i.e. personal opinion), because the Erlang
developers have recommended it not be used (i.e. it is an experimental
or soon to be removed feature), or something else?

The idea of using the package support appeals to me as it will help keep
name-space conflicts to a minimum. As I understand the "packages.html"
page, this is pretty much ALL that the packages functionality offers.

--Ben
_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

[Richard O'Keefe]

On 5 Sep 2008, at 3:17 pm, Benjamin Tolputt wrote:
> The idea of using the package support appeals to me as it will help  
> keep
> name-space conflicts to a minimum. As I understand the "packages.html"
> page, this is pretty much ALL that the packages functionality offers.

It doesn't offer any MORE of that than Erlang has without it.
What it DOES give you is extra breakability.



_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

[Benjamin Tolputt-2]

Richard A. O'Keefe wrote:
> On 5 Sep 2008, at 3:17 pm, Benjamin Tolputt wrote:
>> The idea of using the package support appeals to me as it will help keep
>> name-space conflicts to a minimum. As I understand the "packages.html"
>> page, this is pretty much ALL that the packages functionality offers.
>
> It doesn't offer any MORE of that than Erlang has without it.
> What it DOES give you is extra breakability.

I understand the possibility of errors. Possibility of error is a decent
point, but one that can (and has) been made about other parts of the
Erlang system. As I understand it then, this is an "opinion" exclusion
of use rather than one endorsed by the developers of Erlang (given they
implemented it and have yet to remove it from the system). Not throwing
mud at you or anything, just ensuring I understand that this is a
feature you don't like versus one that could be ripped out of Erlang on
a release's notice.

The "extra" functionality it offers is that the beams are split out
nicely such that "xyz.abc.mymod" is compiled to a "mymod.beam" file that
will not conflict with a "abc.def.mymod" module. This (in my mind) is a
Good Thing. Like Java, the multi-folder thing is likely to be a moot
issue given a decent IDE. One that I have admittedly not yet found for
Erlang - beyond a good text editor (ScITE) and the Erlang shell.

--Ben

_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

[Edwin Fine]

Thanks for repeating yourself. I didn't know you had posted about it before, and sometimes I don't even think of searching the lists, mea culpa.

I empathize with your pain at having to hack modules with namespace/directory changes. I have done this too many times (actually, once is too many times) with Java to develop a serious allergy to its namespace mechanism. Then again, if you are amenable to IDEs, Eclipse allows you to refactor Java quite painlessly, including moving between namespaces. Of course, that won't stop namespace changes from breaking someone else's existing code that uses the old namespace. I will look into C/Mesa and Lace - they sound interesting.

The worse problem is the ability to have two modules with different names to refer to the same module. That's a showstopper.

I am reminded of another namespace abomination, namely the addition of namespaces to XML. XML names were originally allowed to contain the colon character. This became a way to retrofit namespaces to XML without breaking backward compatibility (much).

It seems that much evil is done in many spheres to retain backward compatibility, especially in the face of temporal or market pressures - remember the segmented x86 architecture? I wonder how many people on this list were forced to work with the various x86 compiler memory models (IIRC, tiny, small, compact, medium, large, and huge). I was praying that the 68000 would win. Oh, the horror, the horror...

On Thu, Sep 4, 2008 at 11:14 PM, Richard A. O'Keefe <ok@...> wrote:

On 5 Sep 2008, at 2:55 pm, Edwin Fine wrote:

Richard,

Please will you clarify what you mean by

(a) we should not use them because they are inside out

I have discussed this at length in this mailing list.

Do you mean, we should not use these facilities at all, ever, because the design is badly flawed,

Yes.

One fundamental issue is that dotted names are just that:
a *FLAT* module name space that just happens to allow dots
in identifiers.  Since Erlang already allows @ signs in
identifiers, if we had wanted to use names like
   mnesia@CORBA@connector@impl
we could have and can still.  (Think of the "@" signs as
"fat dots".)  Allowing dots in identifiers doesn't, in
principle, accomplish anything that allowing at-signs in
identifiers doesn't.

Well, there's some sort of abbreviation rule, but all that
does is to mess things up horribly.  It is now possible for
two *different* names to refer to the *same* module.  It is
also possible for a module (with no mentions of its name
anywhere other than ?MODULE) to break if you change its name.
In fact, changing the name of a module that doesn't mention
its name ANYWHERE other than the -module directive can break it.

Why I say it's inside-out is that "compound names" for modules
need to be relative to the starting module, not "absolute",
so that you can move an entire cluster of related modules
in a single renaming, WITHOUT having to hack on every single
file.

The design also perpetuates a great nastiness from Java, that
of mixing up the dotting structure of module names with the
arrangement of files in a file system.  I have just spent a
painful half hour trying to read the documentation and sources
for a Haskell package I'd like to use.  They've followed Java's
lead with module names.  One result is that what seems to this
potential user like *ONE* thing is actually broken up into
about 30 pieces; instead of one coherent manual there are
disconnected bits all over the place.  Instead of one directory
with all the source files, there is a great tree with files,
even files that are conceptually at the same level, not only
in different directories but in directories at different levels.

The right thing to do is to have a "configuration" language like
C/Mesa or LACE.

_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

[Richard O'Keefe]

On 5 Sep 2008, at 4:10 pm, Benjamin Tolputt wrote:
> I understand the possibility of errors. Possibility of error is a  
> decent
> point, but one that can (and has) been made about other parts of the
> Erlang system.

That's pretty much of a straw man position.
It's not a question of a mere *possibility* of errors,
but of a "feature" that makes errors *especially* likely,
and which offers no compensating advantages.

> As I understand it then, this is an "opinion" exclusion
> of use rather than one endorsed by the developers of Erlang (given  
> they
> implemented it and have yet to remove it from the system).

The developers of Erlang have so far refrained from announcing
dotted module names as a permanent feature of the language.

There was a lot of discussion back in 2003 and it does not appear
that the dotted names "feature" has been significantly revised since
to address any of the issues that were seen five years ago.
>

> The "extra" functionality it offers is that the beams are split out
> nicely such that "xyz.abc.mymod" is compiled to a "mymod.beam" file  
> that
> will not conflict with a "abc.def.mymod" module.

Actually, no.  There never ever was anything whatsoever in Erlang
to stop you writing module names like 'a.b.c' and thereby having
the beam file placed as 'a.b.c.beam', which quite naturally never
did conflict with an 'e.f.c.beam' file or 'e.f.c' module.

Allowing you to write dotted names without quotation marks is no
big deal either: we ALWAYS had the ability to write module names
with @ signs in them.

> This (in my mind) is a Good Thing.

I am not saying one word against the idea of compound names.
(Although I note that the compound name features originally
present in SETL and ZetaLisp were dropped in SETL2 and
Common Lisp.  It would be very interesting to know why.)
I am, as it happens, a big fan of 'child modules' in Ada,
but unlike Java, Ada does child modules *well*.

> Like Java, the multi-folder thing is likely to be a moot
> issue given a decent IDE. One that I have admittedly not yet found for
> Erlang - beyond a good text editor (ScITE) and the Erlang shell.

You should not need a Gargantuan cycle-hogging "IDE" to paper over
mistakes in a design.  Have you studied Meyer's LACE at all?

The mapping of module names to file names, whether simple or
compounds, is inherently problematic in Haskell (which does it)
and Erlang (which does it) and Prolog (which does it), in that
names (including module names) are case sensitive in those languages,
but in certain popular operating systems file names are not.
Off hand I can think of four "POSIX-compatible" file systems that
do not distinguish alphabetic case, so
        myModule
and mymodule
might, or might not, be distinguishable in BEAM file names.
Then too, there are characters that can be present in an Erlang
module name (like 'date/time mgmt') that are not allowed in a
file name (Unix or Windows).

Quoting
http://www.erlang.org/pipermail/erlang-questions/2003-September/009794.html
"if you insist on mapping Erlang module names directly to file names,
NOBODY CAN EVER KNOW WHAT THE SET OF PORTABLE ERLANG MODULE NAMES IS!
Nobody can even know how long an Erlang module name may be:
is the limit 8 or 10 or 27 or 251 or what?"

Aside from the mapping to file names, the only genuinely new
thing that the "packages" "feature" for Erlang gives you is
the ability to have more than one name for the same module,
and to use the wrong one in a context where it matters.

We can, and should, do MUCH MUCH better.

For example, if a module is going to be referred to elsewhere as
a.b.c, and if we compile a module M by invoking "erlc M.erl",
then erlc a.b.c.erl should work.  (It doesn't.)  Certainly if a
module announces itself as "-module(a.b.c)" then compiling it
should not produce a simple c.beam.  (It does.)

>
>
> --Ben
>
>
>
>
> ====================================================================
>                     Auto Generated Mail Footer
>      If this email is requesting your password then it is a HOAX.
>                     DO NOT reply to the email.
>                    Validate this footer at the
> Otago University web site keyword search: information security phish
> ====================================================================
>
>
>

--
If stupidity were a crime, who'd 'scape hanging?







_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

[Edwin Fine]

 

You should not need a Gargantuan cycle-hogging "IDE" to paper over
mistakes in a design.  Have you studied Meyer's LACE at all?

Now hold on a second :)

Firstly, unless you are running X on a PDP-11/44 or NT on a 286, an IDE like Eclipse is not that much of a big deal. These days there are plenty of spare cycles and memory addresses to hog on a modern development workstation.

Secondly, although I agree that ideally one should not need an IDE to compensate for design errors in a programming language, IDEs are peerless when it comes to supporting computer-aided processes like refactoring. Machines are far better at cross-checking fiddly things like inter- and intra-module references than are humans. And besides, I know of no significant (i.e. those I have heard of ;) programming languages that lack design errors. Although I must admit, I probably only know of a fraction of the scores or hundreds that you know about.

As an aside, I think it would be rather indelicate to study Meyer's LACE, even if Meyer wasn't wearing it.

Regards,
Edwin Fine

_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

[Benjamin Tolputt-2]

Richard A. O'Keefe wrote:
> That's pretty much of a straw man position.
> It's not a question of a mere *possibility* of errors,
> but of a "feature" that makes errors *especially* likely,
> and which offers no compensating advantages.

Without trying to be a pain, I'll separate the fact (use of the feature
increases the possibility of errors) from the opinion (no compensating
advantages).

I agree that using the feature will increase the likelihood of a
particular type of bug creeping into the code. In fact, this likelihood
is currently enough to keep me from using the feature. On the other hand
stating that there is "no" compensating advantages is simply your
opinion (well respected as it is).

> The developers of Erlang have so far refrained from announcing
> dotted module names as a permanent feature of the language.

True, and neither of us can state categorically what their plans are on
the feature until they make an official comment on it.

> There was a lot of discussion back in 2003 and it does not appear
> that the dotted names "feature" has been significantly revised since
> to address any of the issues that were seen five years ago.

It is still a feature of Erlang five years from then. My interpretation
is that this implies the feature is likely to stay. Your opinion
differs, but neither of us can make statements of *fact* on it until the
Erlang developers pipe up with something official.

> Actually, no.  There never ever was anything whatsoever in Erlang
> to stop you writing module names like 'a.b.c' and thereby having
> the beam file placed as 'a.b.c.beam', which quite naturally never
> did conflict with an 'e.f.c.beam' file or 'e.f.c' module.
>
> Allowing you to write dotted names without quotation marks is no
> big deal either: we ALWAYS had the ability to write module names
> with @ signs in them.

The readability alone of "x@y@z" compared to "x.y.z" should make junk of
that argument. Using quotes for atoms appears (from all Erlang text &
code I have been able to get a hold off) to be for "special cases only".
A "compound name system" for modules is not something I would like to
think of as special case.

> You should not need a Gargantuan cycle-hogging "IDE" to paper over
> mistakes in a design.  Have you studied Meyer's LACE at all?

*laugh* And what language does not have design flaws?

Seriously though, not all IDE's are cycle-hogging beasts to the level
that they impede development. Unless you are "developing" code on an
embedded device or a machine approaching it's 12th birthday, I'm sure an
Erlang IDE based on Eclipse or similar would operate just fine without
killing the OS you'd be developing on..


In summary, though - I'd be just as happy (if not happier) if the
package system created "a.b.c.beam" files for the "a.b.c" module, so
long as it provided a similar
syntax. Quoting all my module names (or worse, using the '@' character
for compound names) seems counter to all the other code I have seen
written for Erlang. Admittedly, there doesn't seem to be any using the
packages functionality either, but I find it alot more readable than
(for example) "inet@http@reponse:some_func(...)"


--Ben

P.S. Honestly find it difficult to argue this case as my respect for you
in regards to Erlang development. Your name in the sender line is
generally enough for me to read a subject I might otherwise skip on this
list. Please do not take this thread to be my overall assessment of your
skills & experience; just a difference of opinion.
_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

[Richard O'Keefe]

On 8 Sep 2008, at 2:48 pm, Edwin Fine wrote:
> Firstly, unless you are running X on a PDP-11/44 or NT on a 286, an  
> IDE like Eclipse is not that much of a big deal. These days there  
> are plenty of spare cycles and memory addresses to hog on a modern  
> development workstation.

My main machine is a 500MHz UltraSPARC II.
The IDE from Sun is NetBeans.
So I tried downloading Sun's IDE (written in Sun's language)
from Sun's website and installing it on Sun hardware running
Sun's operating system with Sun's compilers.
And it didn't work.

Last night I was using Microsoft Visual Studio 2008 on a new
laptop (not mine).  It did nothing to improve my opinion of
IDEs, let's put it that way.

The worst thing that these things hog is screen area.

I'm a fan of Smalltalk, which gets the screen area bit
right.  It's pretty much the only IDE that I do like.  But
they said "oh, machines are faster bigger, so we can make
pretty-print-as-you-type and colourising defaults" and
pretty soon the 1GHz PowerMac I was using was crawling.
Hogs!

> Secondly, although I agree that ideally one should not need an IDE  
> to compensate for design errors in a programming language, IDEs are  
> peerless when it comes to supporting computer-aided processes like  
> refactoring.

The Smalltalk refactoring browser is a fine example of that.

> Machines are far better at cross-checking fiddly things like inter-  
> and intra-module references than are humans. And besides, I know of  
> no significant (i.e. those I have heard of ;) programming languages  
> that lack design errors.

Meyer's LACE referred to the "Language for Assembling Classes
in Eiffel."

As for design errors, there are differences of degree.  The
inconsistencies in the dotted module names "feature" put it
roughly on a level with C's switch() statement.

_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

[Richard O'Keefe]

On 8 Sep 2008, at 3:16 pm, Benjamin Tolputt wrote:

[about a number of side issues and avoiding the core of it]

I agree that we should get an official opinion about what
is likely to happen to the dotted names stuff in Erlang from
the Erlang/OTP developers.

There are two fundamental problems with dotted module names.
One is perhaps a matter of opinion.

First: the fact that dotted module names are like "absolute"
file names rather than "relative" file names.  There is a
rival design, or more precisely, a sketch of one, available
for discussion, which does not have this problem.  Some day
I should convert it to EEP form.

It is idle to say that an IDE can fix up module names when
you move a cluster of modules; that only works if the IDE
can *find* module names reliably.  And that leads us to ...

Second: the dotted names proposal is a *compile-time*
retrofit to a language with a *run-time* approach to
naming.  The compiler or preprocessor or whatever simply
cannot find all references to a module.  The rewrite
rules for handling "names" are inconsistent (some occurrences
of an "abbreviated" module name will be expanded, others will
not) and in any case do not apply to module names determined
at run time.  If this were an essential property of every
possible way to add macro-level structuring to Erlang, we'd
just have to live with it, but as it happens, there is also
a sketch of an approach that doesn't have this problem
posted to this mailing list years ago and available for
discussion.

It is entirely possible to have a macro-level structured
module system for Erlang in which ALL module references in
source code are simple identifiers, so that there are
_necessarily_ no inconsistencies about rewriting module
names (because they don't get rewritten).
_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

[Ulf Wiger (TN/EAB)]

Edwin Fine skrev:
>  
>
>     You should not need a Gargantuan cycle-hogging "IDE" to
 >     paper over mistakes in a design.  Have you studied Meyer's
 >     LACE at all?
>
>
> Now hold on a second :)
>
> Firstly, unless you are running X on a PDP-11/44 or NT on a
 > 286, an IDE like Eclipse is not that much of a big deal.
 > These days there are plenty of spare cycles and memory
 > addresses to hog on a modern development workstation.

I've frequently argued for the use (or at least the preparation
for use) of Eclipse in our projects, but every single time so
far that I've tried to use it myself, I've run into obstacles
like:

- The workstation I tried it on didn't have a compatible version
   of JDK installed (and I lacked the privileges to fix it.)

- The workstation certainly did NOT have enough cycles to spare
   in order to make running Eclipse anything but excruciatingly
   painful.

- (Most recently) Running Eclipse on my dual-core Vista laptop
   seems to trigger some locking violation in Eclipse, crashing
   the editor every time at startup.

I will admit that I've never been willing to commit more than
a few hours each time to try to get Eclipse working. This
amount of work or less has been perfectly sufficient for trying
out any number of plain editors, none of which were good enough
to lure me away from Emacs, but at least I could quickly get them
to work. I will feel much better about my tacit endorsement of
Eclipse the day I can actually get some work done with it
myself. (:


> Secondly, although I agree that ideally one should not need
 > an IDE to compensate for design errors in a programming language,
 > IDEs are peerless when it comes to supporting computer-aided
 > processes like refactoring.

I'm all for the use of IDEs and other power tools, but in my
experience, early adopters easily forget that a large number
of people will actually be using quite modest hardware - the
kind that the early adopter has piled up in the closet because
he considers it practically useless. I very much like the fact
that you can be very productive in Erlang /without/ an IDE.

I side completely with Richard on this particular issue.

BR,
Ulf W
_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

[Edwin Fine]

Look, Make no mistake, I am no IDE apologist. I use Vim, and only Vim, to do all my work, unless I have Java work to do, in which case I use Eclipse because of its very good support for Java and all the other things I mentioned. I didn't realize that any people actually still used 500MHz SunSparc II pizza boxes other than for bookends. I truly commiserate. No, really, I was forced to use one at my previous job for some things, and after being treated for post-traumatic stress disorder from that experience, I am mostly ok now. I hear that since they were so obsolete they couldn't even run some of the newer versions of Solaris, they loaded them all into the back of a truck, along with some ancient and horribly underpowered HP workstations, and melted them down for something more valuable, the plastic or metals or something. So if one is truly forced to use such state of the ark equipment, I totally understand the anti-IDE allergy.

But if you work for a company that forces you to suffer such curel and unusual punishment, you should let them know it is false economy to force developers to use such underpowered tools. They would get far more productivity from spending even US$1,000 on a decent dual-core or quad-core x86_64 CPU, 4 GB of RAM, 500GB of disk and running some flavor of Linux. I understand that for architecture-specific development, such as for SPARC or PA-RISC, one may have to make do with some old clunker. I've done plenty of multiple-platform development and understand that you can't always have the best and latest, especially since companies like Sun and HP tend to charge fortunes for modern workstations. However, you could do much of the development on a decent Linux box and then switch to the bronze-age box to do the final compile and testing. It's truly shameful that people of your calibre should be forced into such indignities.

As for Windows Vista, I feel for you, but anyone who actually uses that abomination (talk about cycle-hogging!) and expects it to work needs to have their head read. Format the hard disk and put on a copy of XP or maybe even Linux.

Some of the downsides of IDEs, excluding the memory/cycle hogging, include things like project and build files that are IDE-dependent AND version dependent. Microsoft seem historically to be particularly offensive in this regard. I recently tried to help someone fix a C# .NET application. Let me reproduce what I wrote a couple of weeks ago about trying to get an older version of the Microsoft Visual Studio .NET to work with the project files that were created on a newer version.

---------------------------
Be warned: rant ahead, but please take it in the spirit of "ha ha, he's only serious".

I set PATH and LIB to the bin directory containing both the .exe and the .dll. I threatened the computer with viruses. I promised my firstborn to Microsoft. I sacrificed goats to Yahweh, Ahura Mazda, Zeus, Apollo, Pallas Athena, Thor, Odin, Loki, Moloch, Baal, Isis, Osiris, Seth, Prostetnic Vogon Jeltz, Beelzebub, Pazuzu, Satan, and George W. Bush. Then I ran out of goats, so I used a neighbor and tried to raise Cthulhu, Yog-Sothoth, and Shub-Niggurath. I ingested magic mushrooms and other hallucinogens because I thought the "Windows development environment", and I use the term loosely, might make more sense if I were in an alternate reality.

Nothing worked.

The way the f-ing stuff hangs together is impenetrable to me, and evidently to many deities and evil spirits.

I installed MS VisualStudio .NET 2003 so I could at least build the code, but the project files that are there are from a newer version of VS .NET, so I can't open them.

Sorry to say this, but this is one reason why I detest IDEs in general, and Microsoft's specifically - for that matter, I despise Microsoft in general, may the bugs of a thousand Vistas infest their armpits. The old, primitive make system or newer ones like Ant work just about everywhere, but IDE-based things don't.

Why MS had to reinvent the f-ing wheel and create .NET and yet another level of non-interoperability I don't know, but I hope there is a special, very low infernal level of Hades reserved just for them. And may there only be Windows Me 4.77MHz 8088 PCs available there. And 300 baud modems.
---------------------------------

I rest my case. I'll stick to human-readable configuration files that I can fix by hand if I have to. And Vim (yes, laugh at me, O Emacs lovers, but it's what I learned first, so there).

Regards,
Edwin Fine

On Mon, Sep 8, 2008 at 4:42 AM, Ulf Wiger (TN/EAB) <ulf.wiger@...> wrote:

Edwin Fine skrev:

 
   You should not need a Gargantuan cycle-hogging "IDE" to

>     paper over mistakes in a design.  Have you studied Meyer's
>     LACE at all?

Now hold on a second :)

Firstly, unless you are running X on a PDP-11/44 or NT on a

> 286, an IDE like Eclipse is not that much of a big deal.
> These days there are plenty of spare cycles and memory
> addresses to hog on a modern development workstation.

I've frequently argued for the use (or at least the preparation
for use) of Eclipse in our projects, but every single time so
far that I've tried to use it myself, I've run into obstacles
like:

- The workstation I tried it on didn't have a compatible version
 of JDK installed (and I lacked the privileges to fix it.)

- The workstation certainly did NOT have enough cycles to spare
 in order to make running Eclipse anything but excruciatingly
 painful.

- (Most recently) Running Eclipse on my dual-core Vista laptop
 seems to trigger some locking violation in Eclipse, crashing
 the editor every time at startup.

I will admit that I've never been willing to commit more than
a few hours each time to try to get Eclipse working. This
amount of work or less has been perfectly sufficient for trying
out any number of plain editors, none of which were good enough
to lure me away from Emacs, but at least I could quickly get them
to work. I will feel much better about my tacit endorsement of
Eclipse the day I can actually get some work done with it
myself. (:

Secondly, although I agree that ideally one should not need

> an IDE to compensate for design errors in a programming language,
> IDEs are peerless when it comes to supporting computer-aided
> processes like refactoring.

I'm all for the use of IDEs and other power tools, but in my
experience, early adopters easily forget that a large number
of people will actually be using quite modest hardware - the
kind that the early adopter has piled up in the closet because
he considers it practically useless. I very much like the fact
that you can be very productive in Erlang /without/ an IDE.

I side completely with Richard on this particular issue.

BR,
Ulf W

_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

[Robert Raschke-5]

<rant>

2008/9/8 Edwin Fine <erlang-questions_efine@...>:
> But if you work for a company that forces you to suffer such curel and
> unusual punishment, you should let them know it is false economy to force
> developers to use such underpowered tools. They would get far more
> productivity from spending even US$1,000 on a decent dual-core or quad-core
> x86_64 CPU, 4 GB of RAM, 500GB of disk and running some flavor of Linux

This is one of the big contributers to bloated software, you know. In
order to get performant software out of your development department,
give them slow machines with limited memory. And give your testing
department fast machines, so they can feedback information quickly.

I always marvel at IT departments that feel compelled to give
developers mega machines, while the sales force are fobbed off with
laptops that barely cope with demoing the stuff written for a
multi-core 4GHz 8GB machine.

Robby
_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions