Thanks for the input Thomas.
Thomas Beale wrote:
>Jim Self wrote:
>
>> Rob Cecil wrote:
>> I clipped the example code for brevity. If you are interested, here is a
URL
>> http://vmacs.vmth.ucdavis.edu/demo/rtn/DIDTC.html that will give you a
more
>
>Wow. I don't want to sound rude, but is anyone really advocating that
people use
>even this nicer colourised code?
No, but the syntax coloring helps quite a bit to transform other people's
coding styles into something more comfortable for me. I don't think anyone
holds this up as an example of *good* coding style for MUMPS. As Greg Kreis
said, this is a routine which has changed very little in over 20 years. As
far as I know it is probably compatible with MUMPS implementations from that
time and yet is also Y2K compliant and quite flexible.
To expand on what I said in a possibly later post, I view much of the source
code in Fileman as close to the bottom of the scale of MUMPs readability. On
the other hand, it has been separated from its documentation, virtually all
(close to 50) date handling functions in Fileman and, I think, VistA are
contained in this and its sister routine DIDT. Personally, I don't think it
is all that hard to read for a programmer who has spent enough time to
become familiar with MUMPS syntax.
>> >Eiffel.
>> >
>> >I personally think Eiffel is a fantastic, super language - from an
academic
>> >point of view. I have Meyer's 2nd Ed. OO book on my self next to me,
and
>> >reference it from time to time. There was a time, once, when Eiffel
could
>> >have been "it". But C++ "won" (at that time), as the large-scale OO
>> >implementation language.
>>
>> If what Thomas has been saying about the relative productivity of Eiffel
vs
>> C++ is true then I suspect the battle is not over.
>
>I can't predict where industry will go obviously, but I think C++ is headed
for
>legacy language status. Java has a better simplicity/power ratio, and will
>probably replace this segment of the market.
>
>If componentisation is used for what it should be used for - developing
>components (in whatever language best suits the job), then Eiffel should
have as
>long a life as anything else. In any case, one doesn't normally see the
writing
>of a complete new GNU compiler for a language unless interest in it is
>growing....
While interest in MUMPS per se may not be growing, the importance of a Free
MUMPS is becoming increasingly clear to those of us who have highly
functional and actively growing information systems based on MUMPS.
>> If my desire to see an Open Source MUMPS in the near future is to be
>> realized, it will probably be implemented in C or C++ or Eiffel. If
>> SmallEiffel is used then it will be compiled to C or, perhaps, Java. I
would
>> appreciate some more clues as to which route would be best.
>
>Please, C, Eiffel, Java, anything but C++!
It sounds like you are saying that C++ will be relegated to legacy status
prior to C. If so, why is that?
>
>> >Hence, the most mature development environment for
>> >OO from GNU/FSF is gcc/g++ ( have you checked the myriad corporate
>> >contributions noted on Cygnus' EGCS web site?). I think what people
most
>> >appreciate about Eiffel is the Contract mechanism to strengthen class
>> >semantics. GNU Nana? (http://www.fsf.org/software/nana/nana.html) can
be
>> >used to add Eiffel-like contract semantics to C++ code.
>>
>> I will take a look at this. Does it affect Thomas' claim that Eiffel is
>> several times more productive as well as conducive to higher quality?
>
>Alright, I'll be a bit more serious. In my experience, you _can_ write
>high-quality C++ code, and with additions such as the above, you might get
>pretty close to Eiffel. C++ is powerful, no doubt about it. The issues are:
>
>- cost of training: it's complexity practically mandates a B. Sc. in comp
sci,
>then significant inhouse training to establish enterprise idioms and norms.
>- cost of development: requires experienced engineers; expensive. Hackers
will
>create an obscene mess
>- cost of maintenance: it's just heard to read, and often not clear what
the
>design intention was from the code. If standards have not been applied to
all
>coding in the product, the myriad of differnt styles can make it cheaper to
>rewrite than to maintain. I have seen this myself in big sites.
You appear to be saying that use of Eiffel has a significant effect on all
these factors. Unless someone can give me some convincing counter arguments,
I suppose I will simply have to give it some sort of trial period. Would I
somehow be missing the boat by starting with SmallEiffel?
>- thomas beale
>
>--
>---------------------------------------------
>Deep Thought Informatics Pty Ltd
>Information and Knowledge Systems Engineering
>
>mailto:[EMAIL PROTECTED]
>http://www.gehr.org
>phone: +61 7 5439 9405
>
>http://www.elj.com/eiffel/ebs
>---------------------------------------------
>
>
---------------------------------------
Jim Self
Manager and Chief Developer
VMTH Computer Services, UC Davis
(http://www.vmth.ucdavis.edu/us/jaself)
