Structs (was RE: Record selectors)

Joe Armstrong joe@REDACTED
Thu Jan 16 10:48:53 CET 2003


On Wed, 15 Jan 2003, Chris Pressey wrote:

> On Wed, 15 Jan 2003 10:39:07 +0100 (CET)
> Joe Armstrong <joe@REDACTED> wrote:
> 
> > [...]
> >   My view is that data validation *only* occurs at a human -> computer
> > interface and  at a boundary  where two components communicate  via. a
> > protocol and where the components are not trusted.
> 
> Ah!  I feel very similarly, except my view is that I shouldn't fully trust
> *anything* outside the current module - not even my own code, since I'm
> human and I make mistakes.  In other words, every module is a boundary
> where components communicate with a protocol, even if that protocol is
> just a set of exported Erlang functions.
> 

  You are right  - but please don't tell  anybody outside this mailing
list...

  I will tell  you a little story about what  happened when people did
things this way ...

  In  one  project that  I  know  about,  project management,  in  its
"wisdom"  forced  the  programmers  to  specify all  interfaces  in  a
"language neutral  manner [1]" (the  thinking behind this was,  "so we
can ditch Erlang and re-write it later in God's own language[2]").

  This approach  was ruthlessly enforced,  resulting in code  that ran
like soggy treacle and to the obvious conclusion that Erlang was crap.

  Moral: By all means enforce  internal boundaries but do so in manner
which is appropriate to the problem.

  /Joe


  [1] When a "suit" say  "language neutral IDL" they mean the language
*must* be C++ and the IDL *must* be Corba.

  [2] GOL varies with time - it  was C++ then became Java and I note a
creeping tendency towards C#, but I might wrong about the C#.

  Thus it is  is that projects are done in C++  (because it is "future
proof") - the future being that period in time during which the entire
application is re-written in Java.

  Erlang, however, cannot be used because it is not "future proof".














More information about the erlang-questions mailing list