Hi Booker,

<bbense+comp.lang.ruby.Oct.04.02 / telemark.stanford.edu> wrote in message news:<ankf4s$585$1 / news.Stanford.EDU>...

----------------------------------------------------------------------------
> - - IMHO, if you aren't willing to change the way you think about
>   problems then you're just going to be frustrated by Ruby. 
>   To me that's the entire point of Ruby. Sometimes the square peg
>   is just not going to go in the round hole. 

Probably not really.  Ruby itself is just a "tool" as an "advanced
interface".  The main problem is not how to code well, but how to
design an optimum communications network.  The simpler the interface
(minimalism), the better; and if there is some possibility to do some
programming with the interface, some users are welcome to adventure. 
Ideally, this "advanced interface" is a general-purpose yet
simulator-specific language.  As currently I don't have the resources
to do that, Ruby so far is the best candidate (with Python and Lua
being the runner ups) to be used as a base.

-----------------------------------------------------------------------------
> - - What I don't understand is why you use Ruby at all? Java seems
>   to be more or less what you want. 

Definitely I have considered Java before.  Some problems are:

*) Variable declarations and OO style are mandatory, so it is rather
hard to do "rapid development" and creating "easy interface". 
However, because of the Fortran/C heritage, IMHO in the
simulator-specific language the declarations should be optional.  (At
least, to me, it should be good from the "marketing" point of view if
not from the programming point of view.)

*) It is more difficult to do tight integration between Java and C. 
Because of the performance requirement, definitely the network
simulator core should be written in C.  Because Ruby itself is written
in C, it is relatively easier to do core-interface integration.

*) Java source code is not available or not easy to modify.  Ruby
really has the potential to be used as a base for the general purpose
yet simulator-specific language because its source code is available.

*) Java is garbage-collected, so it is also relatively slow for a
network simulator.  Ideally, a network simulator should be written in
C/C++; or when gc is considered, reference counting is probably the
best.  Ruby is also gc-ed; but again because the source code is
available, it is not impossible to modify Ruby gc.
-----------------------------------------------------------------------------

> - - Well, I know how hard it is to train engineers to use sane
>   coding practices, but giving them Ruby and then encouraging
>   a procedural style seems especially cruel. 

I may be wrong, but for me so far Ruby has served very well being used
in a procedural style.  The OO feature comes in really handy, because
in network simulations we definitely have to model objects.  (Probably
I would have passed on Ruby the first time I encountered it, if Ruby
had insisted on me to code in the OO way since the beginning, like
Java.)  I think the main objective will not be to teach the engineers
on how to use "the Ruby way", but to give them a freedom of choice: if
some engineers want to stick with their old style they can do that,
but if some others want to learn how to code well, (hopefully) nothing
will prevent them from achieving that.  (Again, to me, this should be
good from the "marketing" point of view if not from the programming
point of view.)

-----------------------------------------------------------------------------

> - - Well, Factory methods are perhaps an exception, but I still
>   think the 3 arg rule applies. Where do all these args come
>   from anyway? I would guess either a GUI or input file.
>   If it were my code, you'd be passing around structs of
>   LinkParameters. Even in C and java, the 3 arg rule is 
>   a life saver. I write a lot more C then ruby and I try
>   pretty hard to stick to this rule. 
> 
>   function(context,input,output,error)
> 
>   I've found this to be a much more powerful technique for
>   keeping code in sync with design than any amount of type
>   checking.

Thanks for the tip, Booker.  I will consider it when I make the next
major revision to the code.

Regards,

Bill