From: billtj@... (Bill Tj) Date: 2002-10-09T00:10:12+09:00 Subject: Ruby as an Advanced Interface Hi Booker, wrote in message news:... ---------------------------------------------------------------------------- > - - 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