The future of VMS
Bill Gunshannon
decided to try and take positive action. However, I will need
a bit of information first.
Background:
We have a required course for all of our seniors called
"Senior projects". :-) I am considering proposing the
porting of one (or maybe two) of the currently popular
X toolkits to VMS as potential projects.
Questions:
Which toolkit(s) would the VMS community here most like
to see ported?? GTK?? QT??
I currently have available for student use a couple of
VAX 4000's and VMS 7.1. If the porting effort is taken
using this base will it be merely a matter of re-compiling
to make it work on Alpha or newer VMS versions?
Would people here object to students involved in this
project bringing questions here when they get stuck??
It is unlikely that any student accepting one of these
projects will have any VMS experience at all.
For those who may have already ported something from
the Unix environment to VMS, is it likely that this
project could be accomplished by one or two students
in a single semester??
Any information will be greatly appreciated. The students
are int he process of selecting projects for the Fall now.
If I am to get this going I need to get a project written up
and posted quickly.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bi...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
John E. Malmberg
bi...@triangle.cs.uofs.education (Bill Gunshannon) writes:
> In an attempt to aid in the continuing existence of VMS, I have
> decided to try and take positive action. However, I will need
> a bit of information first.
>
> Background:
> We have a required course for all of our seniors called
> "Senior projects". :-) I am considering proposing the
> porting of one (or maybe two) of the currently popular
> X toolkits to VMS as potential projects.
>
> Questions:
>
> Which toolkit(s) would the VMS community here most like
> to see ported?? GTK?? QT??
GTK has been listed as ported and downloadable as part of the Mozilla
effort.
Does QT still have licence issues that would prevent it's distribution?
> I currently have available for student use a couple of
> VAX 4000's and VMS 7.1. If the porting effort is taken
> using this base will it be merely a matter of re-compiling
> to make it work on Alpha or newer VMS versions?
Generally yes, small issues may crop up.
The biggest difference I have found is the construction of shared images.
> Would people here object to students involved in this
> project bringing questions here when they get stuck??
> It is unlikely that any student accepting one of these
> projects will have any VMS experience at all.
It really depends on the level of the question. Most of the objections
to student questions that I have seen, is where the student asks for
a complete solution to a trivial problem.
They should be prepared to get all range of answers, good, bad, ugly.
vmsnet.desktop.misc might be a good newsgroup for those working on that sort of
port.
> For those who may have already ported something from
> the Unix environment to VMS, is it likely that this
> project could be accomplished by one or two students
> in a single semester??
It may be hard to tell. Some of the packages compile and go, other
ports have numerous features disabled.
Building a portable test/verification environment for a toolkit can
be time consuming.
It might be useful for them to take an existing open-source port of a
project and see if they can enhance it's performance, or reduce it's
resource requirements.
This could get them some good experience with code profiling and testing,
where they could evaluate the merits of which enhancement to persue.
> Any information will be greatly appreciated. The students
> are int he process of selecting projects for the Fall now.
> If I am to get this going I need to get a project written up
> and posted quickly.
Look at the STAR OFFICE base requirements. In addtion to the code supplied,
there are other libraries that it seems to need.
Other candiates would be: WINELIB, GCC, SAMBA, MOZILLA, POSTGRESQL, CVS.
Personal Opinion Only
wb8...@qsl.network
John Vottero
It's likely that a VAX port would be a simple recompile for Alpha but,
there's no guarantee.
"Bill Gunshannon" <bi...@triangle.cs.uofs.edu> wrote in message
news:9f0a9p$162l$1...@info.cs.uofs.edu...
Robert Deininger
> In an attempt to aid in the continuing existence of VMS, I have
> decided to try and take positive action. However, I will need
> a bit of information first.
>
> Background:
> We have a required course for all of our seniors called
> "Senior projects". :-) I am considering proposing the
> porting of one (or maybe two) of the currently popular
> X toolkits to VMS as potential projects.
Hurray! And thanks.
> Questions:
>
> Which toolkit(s) would the VMS community here most like
> to see ported?? GTK?? QT??
I can't give an opionion here, since I've not used them.
> I currently have available for student use a couple of
> VAX 4000's and VMS 7.1. If the porting effort is taken
> using this base will it be merely a matter of re-compiling
> to make it work on Alpha or newer VMS versions?
Porting to alpha is probably straigtforward. What compiler(s) will they
use? If C, use DEC C, avoid VAX C.
> Would people here object to students involved in this
> project bringing questions here when they get stuck??
> It is unlikely that any student accepting one of these
> projects will have any VMS experience at all.
No problem. Make sure they have access to VMS documentation. Please
point them to the FAQ before the newsgroup.
> For those who may have already ported something from
> the Unix environment to VMS, is it likely that this
> project could be accomplished by one or two students
> in a single semester??
If they are fairly good students, if they can/will read documentation, if
they aren't too hung up on some other architechture to think in new ways,
and above all, if they have some guidance from someone with more VMS
experience.
It might be a good idea to have a truncated version of the projects, in
case you mis-estimate the level of effort needed. I think it's a safe bet
that the students are in no position to estimate the scope of the project.
This isn't an area I've worked in myself, but I've always heard that X
programming is fairly hellish. Maybe not the best introductory project on
a new OS?
> Any information will be greatly appreciated. The students
> are int he process of selecting projects for the Fall now.
> If I am to get this going I need to get a project written up
> and posted quickly.
Feel free to post the project here for comments as well.
--
Robert Deininger
rdein...@mindspring.com
Tim Llewellyn
Robert Deininger wrote:
> In article <9f0a9p$162l$1...@info.cs.uofs.edu>, bi...@cs.scranton.edu wrote:
>
> > In an attempt to aid in the continuing existence of VMS, I have
> > decided to try and take positive action. However, I will need
> > a bit of information first.
> >
> > Background:
> > We have a required course for all of our seniors called
> > "Senior projects". :-) I am considering proposing the
> > porting of one (or maybe two) of the currently popular
> > X toolkits to VMS as potential projects.
>
> Hurray! And thanks.
>
> > Questions:
> >
> > Which toolkit(s) would the VMS community here most like
> > to see ported?? GTK?? QT??
>
how about a network aware port of TCL/TK that works with UCX
/TCPIP Services?
--
Tim Llewellyn, OpenVMS Infrastructure, Remarcs Project
MedAS at the BBC, Whiteladies Road, Bristol, UK.
Email tim.ll...@bbc.co.uk. Home tim.ll...@cableinet.co.uk
I speak for myself only and my views in no way represent those of
MedAS or the BBC.
LBohan@dbc.spam_less..com
Gunshannon) wrote:
if X toolkits look to be too hairy/too long a project,
or hard to test:
the most common initial stumbling block in a vms port
of some unix tool, is often the autoconf/configure
steps, ie getting a usable build script.
Maybe look at a VMS port of autoconf ?
perhaps not doable without a working unix shell;
GNU bash might work for this,
but, iirc, it assumes/uses v7.3 rtl libraries.
other thoughts:
mySQL (Dan O'Rielly, process.com had started on this?)
or, perhaps one of the DBM api's
(My recollection is that autoconf was a stumbling block
here also)
SleepyCat (berkeley) had done a VMS port of at least
one of the DBM api's. at least according to their web site.
Simon Clubley
<q7v7htoh1gjsrutf1...@4ax.com>, LBo...@dbc.spam_less..com wrote:
>
>On 29 May 2001 14:04:41 GMT, bi...@triangle.cs.uofs.edu (Bill
>Gunshannon) wrote:
>
>>Background:
>> We have a required course for all of our seniors called
>> "Senior projects". :-) I am considering proposing the
>> porting of one (or maybe two) of the currently popular
>> X toolkits to VMS as potential projects.
>>
>
>or hard to test:
>
>the most common initial stumbling block in a vms port
>of some unix tool, is often the autoconf/configure
>steps, ie getting a usable build script.
>
>Maybe look at a VMS port of autoconf ?
>
>perhaps not doable without a working unix shell;
>GNU bash might work for this,
>but, iirc, it assumes/uses v7.3 rtl libraries.
>
>other thoughts:
>
> mySQL (Dan O'Rielly, process.com had started on this?)
>
>or, perhaps one of the DBM api's
>(My recollection is that autoconf was a stumbling block
> here also)
>
>SleepyCat (berkeley) had done a VMS port of at least
>one of the DBM api's. at least according to their web site.
>
A related idea: has anybody evaluated what would be involved in doing
a Cygwin style environment for VMS and would this be suitable for the
above project ?
Some background for those not aware of Cygwin:
Cygwin is the project to put the Unix tools on Windows. It works by
having a base set of code that emulates the Unix environment and
works well enough that a wide selection of the Unix tools have been ported
to Windows.
Given previous discussions in the newsgroup about filesystem differences
as a cause of porting problems, you may be interested in the Cygwin approach,
as it could be used for VMS as well. If you look at a Cygwin installation
from a MSDOS prompt, you see \CYGWIN\USR\* as been the top level of /usr, but
from within BASH running under CYGWIN, /usr appears as a top level directory
just as it does under Unix. Your normal Windows drives appear as, for example,
/cygdrive/c/ for C:.
Simon.
--
Simon Clubley, simon_clubley@remove_me.excite.com-Earth.UFP
Worrying idea #101: What if Microsoft goes into the Ada compiler business ?
David Mathog
>In an attempt to aid in the continuing existence of VMS, I have
>decided to try and take positive action. However, I will need
>a bit of information first.
>
>Background:
> We have a required course for all of our seniors called
> "Senior projects". :-) I am considering proposing the
> porting of one (or maybe two) of the currently popular
> X toolkits to VMS as potential projects.
>
That could easily exceed the time the students have available to work on
such a project, unless they work in teams, and maybe not even then. X11
programs can be particularly difficult to port, see for instance:
http://saf.bio.caltech.edu/www/X11_VMS_NOTES.TXT
As a somewhat more tractable alternative I'd like to suggest (and this is
just the embryo of the idea) a class in code portability where the
semester's project consists of developing a cross platform C specific
"make" environment that must run on Unix, VMS, and WNT (W2K) and has the
following requirements:
1. must implement full dependency based build
2. it may not use external programs of any sort (ie, it can't awk, sed, SORT,
SEARCH, find, copy, cp, mv, ln -s etc) with the exception that it may
emit "compile, library, and link" related instructions.
3. it must be written entirely in ANSI C. Grade inversely proportional
to the number of #ifdefs required to run on a different platform.
4. it must be able to discover platform specific properties, but only
through creating, compiling, and running small C programs.
extra credit for:
5. automatic dependency discovery.
A semester is a relatively short time, and this would be a good thing,
since it would force the students to keep the projects simple - hopefully
keeping them from evolving into monstrosities like "autoconf".
Students could be divided into groups of 4, each such group being assigned
the same "gnu" program to test their cross platform method on. The group
of 4 could collaborate on any porting within the program itself needed to
get it to run on the different platforms. However, each student would be
responsible for his/her own "build" software.
The whole class could agree upon a set of standard symbols for classes
of #ifdef usage. (for instance, HAS_STRNCAT). They could also agree upon
a common format for dependency files.
Part of the grade would include testing each student's build program on all
4 platforms versus several of the gnu packages, using the agreed upon
dependency and #ifdef symbols.
Anyway, something along those lines. And something useful would come out
of it - full build environments for many of the gnu progrms on multiple
platforms.
Regards,
David Mathog
mat...@caltech.edu
Manager, sequence analysis facility, biology division, Caltech
Fred Kleinsorge
An alternative that might be interesting and do-able is to write an
application that reads command line definition files, and builds a GUI
interface for it.
People are always complaining that they want GUI interfaces to command line
apps ;-)
fabio_...@ep-bc.petrobras.com.br
future we can
have a new graphical terminal.
Regards
FC
"Fred Kleinsorge" <klein...@star.zko.dec.com> em 31/05/2001 16:00:36
Favor responder a "Fred Kleinsorge" <klein...@star.zko.dec.com>
Assunto: Re: The future of VMS
Paul Repacholi
> If I had time on my hands, I would port Gnome.
> An alternative that might be interesting and do-able is to write an
> application that reads command line definition files, and builds a GUI
> interface for it.
Or as a first step, read a CLD and spit out the code to set up the
varibles etc for a lunix system. You may want to do a unix version
of LIB$FIND_FILE first. with wildcard handeling.
--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
Raw, Cooked or Well-done, it's all half baked.
Spam-To: u...@ftc.gov,enfor...@sec.gov,sn...@fcc.gov,hfur...@fcc.gov,
mpo...@fcc.gov,gtri...@fcc.gov
John Vottero
read a CLD file and produce code and/or tables that could be used in
conjunction with open source CLI$ routines. Let's bring real command line
utilities to UNIX and Windows!
"Fred Kleinsorge" <klein...@star.zko.dec.com> wrote in message
news:sxwR6.896$fi2....@news.cpqcorp.net...
Larry Kilgallen
> That would be nice. As a start, I would like to see something that would
> read a CLD file and produce code and/or tables that could be used in
> conjunction with open source CLI$ routines. Let's bring real command line
> utilities to UNIX and Windows!
Imagine David Dachtera's signature file here.
Please discuss Unix and Windows futures in some other conference.
==============================================================================
Great Inventors of our time: Al Gore -> Internet; Sun Microsystems -> Clusters
==============================================================================
Christof Brass
Sorry, but please forget these technically completely irrelevant
so called OSes.
To strengthen VMS we should have decent VMS apps.
Unfortunately the initiative to setup a list with most wanted
VMS apps didn't find much help.
I would refrain from trying to support C/C++ as common language.
Both languages lack the very basics from the point of SW
engineering and therefore provide a worst case scenario for
porting apps.
I suggest to concentrate on one porting aspect like the file
system. This might be a semester project: how to map the
different file specs of other OSs to VMS and as an extension for
the eager students how to cope with case sensitive environments.
John Vottero
news:RwNnDd...@eisner.encompasserve.org...
> In article <thdq43t...@news.supernews.com>, "John Vottero"
<Jo...@mvpsi.com> writes:
> > That would be nice. As a start, I would like to see something that
would
> > read a CLD file and produce code and/or tables that could be used in
> > conjunction with open source CLI$ routines. Let's bring real command
line
> > utilities to UNIX and Windows!
>
> Imagine David Dachtera's signature file here.
>
If I did, I never would have scrolled down far enough to see the next line!
> Please discuss Unix and Windows futures in some other conference.
>
If we show the UNIX/Windows crowd how thing should be done, maybe these UNIX
utilities would actually be useful if they were running on VMS!
Christopher Smith
> From: Christof Brass [mailto:br...@infopuls.com]
> I would refrain from trying to support C/C++ as common language.
> Both languages lack the very basics from the point of SW
> engineering and therefore provide a worst case scenario for
> porting apps.
It's interesting to note that I can't think of much commercial software
that's not written in C/C++ these days. Perhaps rather than porting a
modern application, one should consider looking for an older one with a
solid foundation and doing a port/enhancement at the same time.
It's unfortunate that web browsers are probably too new to do this with. A
web browser in ADA would be interesting. As a matter of preference, I don't
like ADA too well, but it seems well supported, and is relatively solid.
Most of the problems I see with web browsers are in memory allocation, I
assume, from sloppy C. :)
Regards,
Chris
Christopher Smith, Perl Developer
Amdocs - Champaign, IL
/usr/bin/perl -e '
print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");
'
Larry Kilgallen
>> -----Original Message-----
>> From: Christof Brass [mailto:br...@infopuls.com]
>
>> I would refrain from trying to support C/C++ as common language.
>> Both languages lack the very basics from the point of SW
>> engineering and therefore provide a worst case scenario for
>> porting apps.
>
> It's interesting to note that I can't think of much commercial software
> that's not written in C/C++ these days. Perhaps rather than porting a
> modern application, one should consider looking for an older one with a
> solid foundation and doing a port/enhancement at the same time.
>
> It's unfortunate that web browsers are probably too new to do this with. A
> web browser in ADA would be interesting. As a matter of preference, I don't
> like ADA too well, but it seems well supported, and is relatively solid.
> Most of the problems I see with web browsers are in memory allocation, I
> assume, from sloppy C. :)
Competing in the web browser market is a daunting task.
The most prominent public web-related Ada project is AWS, the Ada Web Server.
It is not a generalized server like Apache, but rather a subsystem you link
into your own application so it can serve up web pages related to its purpose,
such as control of your lawn sprinker or space station or anything in between.
Dan O'Reilly
> > -----Original Message-----
> > From: Christof Brass [mailto:br...@infopuls.com]
>
> > I would refrain from trying to support C/C++ as common language.
> > Both languages lack the very basics from the point of SW
> > engineering and therefore provide a worst case scenario for
> > porting apps.
>
>It's interesting to note that I can't think of much commercial software
>that's not written in C/C++ these days. Perhaps rather than porting a
>modern application, one should consider looking for an older one with a
>solid foundation and doing a port/enhancement at the same time.
>
>It's unfortunate that web browsers are probably too new to do this with. A
>web browser in ADA would be interesting. As a matter of preference, I don't
>like ADA too well, but it seems well supported, and is relatively solid.
>Most of the problems I see with web browsers are in memory allocation, I
>assume, from sloppy C. :)
Caveat emptor: not trying to slam anybody here!
You know, it's interesting the way software engineering vis-a-vis languages
has transmogrified over the years. It used to be the responsibility of the
engineer to write good code. Now it seems to be the responsibility of the
language constructs to FORCE the engineer to write good code. Hence, state-
ments like languages lacking "the very basics from the point of SW engineer-
ing".
Maybe that's good for the kids just coming out of college, but (showing my
age - I wrote my first BASIC program 27 years ago!) as for me, I mourn the
passing of the "real art" of software engineering...
Christopher Smith
> From: Dan O'Reilly [mailto:da...@process.com]
> You know, it's interesting the way software engineering
> vis-a-vis languages
> has transmogrified over the years. It used to be the
> responsibility of the
> engineer to write good code. Now it seems to be the
> responsibility of the
> language constructs to FORCE the engineer to write good code.
> Hence, state-
> ments like languages lacking "the very basics from the point
> of SW engineer-
> ing".
>
> Maybe that's good for the kids just coming out of college,
> but (showing my
> age - I wrote my first BASIC program 27 years ago!) as for
> me, I mourn the
> passing of the "real art" of software engineering...
I agree completely. It's a shame that people don't know how to program any
more :/
It's also a shame that, since they don't know how to program, they don't
produce good code ;)
Since most programmers now either can't program, or refuse to test, what
will you do?
Personally, I believe that you should choose a language which is more or
less restrictive depending on the scale and scope of a project, but any
language for the "unwashed masses" will have to be idiot-proof today, or
you'll get no software. As much as you or I would like to, we can't say to
all of the clueless programmers in the world "Go home and play solitaire."
Eventually, somebody will get us into a situation where we have to use some
of the slime that those people produce, and I'd rather the languages forced
them to make it less "slimy." :) The current popular languages don't do
this.
I'm not saying it's good that it's come to this, but it's justified because
that's the state of the profession :/
Jan Vorbrueggen
> Maybe that's good for the kids just coming out of college, but (showing my
> age - I wrote my first BASIC program 27 years ago!) as for me, I mourn the
> passing of the "real art" of software engineering...
While I share the sentiment, to some degree, I do think "art" and
"engineering" don't go well together. The top item of merit, in my
opinion, for any engineering-related activity is reliability - or
do you find it appropriate that you wonderfully designed house
suddenly collapses because you happened to kick it in the wrong place?
Also, I think the computer should take care of the trivial accounting
things it is so good at, and I am so bad at, mostly because I will
become bored and/or lazy: making sure assignments actually could mean
something, pointers point to allocated memory and not elsewhere, array
indices are in-range, and such things. The problem with languages such
as C and C++ is that they offer too many possibilities to violate simple,
stupid rules without telling you about it.
It seems there is a cultural difference between the US and Europe in this
regard. I have been told that it is quite acceptable to tell people - even
customers - in the US, "don't do that, or something horrible will happen
(e.g., delete all your work, start WW III)". In Europe, such missing
interlocks usually result in incredulity and a strong desire to check
whether "they" really had the chutzpah to release a piece of software with
such characteristics. Thus, WW III will start in Europe at some presently
undetermined future time 8-)...
Jan
Marty Kuhrt
> Since most programmers now either can't program, or refuse to test, what
> will you do?
Buy their software by the millions, if Micro$quish is any indicator.
Christof Brass
>
> > -----Original Message-----
> > From: Christof Brass [mailto:br...@infopuls.com]
>
> > I would refrain from trying to support C/C++ as common language.
> > Both languages lack the very basics from the point of SW
> > engineering and therefore provide a worst case scenario for
> > porting apps.
>
> It's interesting to note that I can't think of much commercial software
> that's not written in C/C++ these days. Perhaps rather than porting a
> modern application, one should consider looking for an older one with a
> solid foundation and doing a port/enhancement at the same time.
Is there a classification in what PL apps are implemented?
Why not take a decent TurboPascal/Delphi app and port it to VMS?
> It's unfortunate that web browsers are probably too new to do this with. A
> web browser in ADA would be interesting. As a matter of preference, I don't
> like ADA too well, but it seems well supported, and is relatively solid.
> Most of the problems I see with web browsers are in memory allocation, I
> assume, from sloppy C. :)
Ada or DEC Pascal would be a very nice programming platform.
Christof Brass
To clearify one point: you can write good apps in almost every
language but it needs more effort to do it in e.g. C or C++
because especially these language lack too much from the point
of SW engineering. A simple example might be sufficient: how the
compiler handles header files is not safe against some kind of
modification (of these header files) which can lead to
completely corrupt binaries.
IIUYC the art of SW engineering is way beyond the problems with
which the average C/C++ is coping. And, agreed, time constraints
lower the quality of engineering work in almost every company.
Christof Brass
This is an interesting question if this is really a cultural
difference.
I completely share you opinion about PLs especially with the
analysis that the computer should be used for the things it can
do best and releave the human beeing from that stupid tasks. But
I think that in the USA the competition is a little bit harder
and therefore the presure on the programmer is higher. The idea
of good enough SW is a result of that presure. I'm wondering if
Europe will feel this presure soon and react similarly.
Challanger and Ariane V will not be the only "victims".
Christof Brass
Very good idea, similar to a meritocraty: if you are well
educated and skillful you can do what you want, you can use the
PL you like and you have more political and social power. A
newby has to program in a very safe environment, e.g. to write
applets in Java.
Paul Repacholi
> At 10:29 AM 6/1/2001, Christopher Smith wrote:
> > > From: Christof Brass [mailto:br...@infopuls.com]
> > > I would refrain from trying to support C/C++ as common language.
> > > Both languages lack the very basics from the point of SW
> > > engineering and therefore provide a worst case scenario for
> > > porting apps.
> >It's interesting to note that I can't think of much commercial
> >software that's not written in C/C++ these days. Perhaps rather
> >than porting a modern application, one should consider looking for
> >an older one with a solid foundation and doing a port/enhancement
> >at the same time.
> >It's unfortunate that web browsers are probably too new to do this
> >with. A web browser in ADA would be interesting. As a matter of
> >preference, I don't like ADA too well, but it seems well supported,
> >and is relatively solid. Most of the problems I see with web
> >browsers are in memory allocation, I assume, from sloppy C. :)
> Caveat emptor: not trying to slam anybody here!
> You know, it's interesting the way software engineering vis-a-vis
> languages has transmogrified over the years. It used to be the
> responsibility of the engineer to write good code. Now it seems to
> be the responsibility of the language constructs to FORCE the
> engineer to write good code. Hence, state- ments like languages
> lacking "the very basics from the point of SW engineering".
> Maybe that's good for the kids just coming out of college, but
> (showing my age - I wrote my first BASIC program 27 years ago!) as
> for me, I mourn the passing of the "real art" of software
> engineering...
C has a pile of really nasty traps, and has not bothered to learn the
lessions of experience. Ma Bell found out the hard way that in-band
signalling is a really bad idea, much to the joy of phone phreakers. C
has not yet learned that lession, and still clings to the 'inbuilt
magic' method for basic data structures.
Tim Llewellyn
Fred Kleinsorge wrote:
yup, and the way to do that as you suggest is to build the GUI around the
command
line interface.
Hey, I was thinking about something very similar just last night.
regards
Christopher Smith
> From: Christof Brass [mailto:br...@infopuls.com]
> Christopher Smith wrote:
> > It's interesting to note that I can't think of much
> commercial software
> > that's not written in C/C++ these days. Perhaps rather
> than porting a
> > modern application, one should consider looking for an
> older one with a
> > solid foundation and doing a port/enhancement at the same time.
> Is there a classification in what PL apps are implemented?
> Why not take a decent TurboPascal/Delphi app and port it to VMS?
Well, no reason at all. Unfortunately I'm not sure that there are many apps
done in turbo pascal (Delphi) these days. Probably fewer still that solve
the problems for which VMS needs applications. :)
On the other hand, if you can find one, it may be simple (relatively) to
make a "turbo pascal compatibility layer" on top of DEC Pascal, or something
like that, which could give functions that were like Delphi functions, but
which used X11 for graphics, and native VMS interfaces for other things.
That would solve the "immediate need" problem. A later version could, of
course, be more properly ported.
> > It's unfortunate that web browsers are probably too new to
> do this with. A
> > web browser in ADA would be interesting. As a matter of
> preference, I don't
> Ada or DEC Pascal would be a very nice programming platform.
That's more or less what I was thinking.
Christopher Smith
> From: Christof Brass [mailto:br...@infopuls.com]
> Very good idea, similar to a meritocraty: if you are well
> educated and skillful you can do what you want, you can use the
> PL you like and you have more political and social power. A
> newby has to program in a very safe environment, e.g. to write
> applets in Java.
That's putting it bluntly. :) I'd like to make it clear, though, that I
don't advocate requiring people to use "safe" languages. People can use
what they like, but I'd never recommend that a person new to programming
start out with fortran. ;)
What I'm really saying is that I think the world should "standardize" on a
safer language (for application programming), since a lot of people who
don't know much about programming will just go with the standard. The trick
is to make it safe, while not making it too restrictive for an experienced
programmer (who will inevitably get stuck using it some time or another).
Applets in Java are an interesting proposition, and should be incredibly
safe, however, until the state of Java VMs improves some (or native
compilers...), I'm not sure whether that's even as safe as it could be.
Christof Brass
Okay, here we have an alternative semester programme: create a
Delphi/Kylix compatibility layer on top of DEC Pascal.
Christof Brass
>
> > -----Original Message-----
> > From: Christof Brass [mailto:br...@infopuls.com]
>
> > Very good idea, similar to a meritocraty: if you are well
> > educated and skillful you can do what you want, you can use the
> > PL you like and you have more political and social power. A
> > applets in Java.
>
> That's putting it bluntly. :) I'd like to make it clear, though, that I
> don't advocate requiring people to use "safe" languages. People can use
> what they like, but I'd never recommend that a person new to programming
> start out with fortran. ;)
>
> What I'm really saying is that I think the world should "standardize" on a
> safer language (for application programming), since a lot of people who
> don't know much about programming will just go with the standard. The trick
> is to make it safe, while not making it too restrictive for an experienced
> programmer (who will inevitably get stuck using it some time or another).
>
> Applets in Java are an interesting proposition, and should be incredibly
> safe, however, until the state of Java VMs improves some (or native
> compilers...), I'm not sure whether that's even as safe as it could be.
>
> Regards,
>
> Chris
>
> Christopher Smith, Perl Developer
> Amdocs - Champaign, IL
>
> /usr/bin/perl -e '
> print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");
> '
Great, let's choose our entry level standard language. From my
point of view it *is* possible to design a language in a way
that it supports safety against stupid (human) mistakes and
power for the skillful programmer. A modern Pascal version like
the modular DEC Pascal will do the trick.
I recently read a proposal to replace "unsafe" by "only for
restricted use" in the area of PLs.
Robert Deininger
<br...@infopuls.com> wrote:
> Great, let's choose our entry level standard language. From my
> point of view it *is* possible to design a language in a way
> that it supports safety against stupid (human) mistakes and
> power for the skillful programmer. A modern Pascal version like
> the modular DEC Pascal will do the trick.
Ada is a very modern Pascal derivative, and is very portable. A
"beginner's subset" is pretty much as easy to learn as Pascal. Maybe
easier, due to the absense of some of the nastier syntax problems in
Pascal.
Ada has plenty of power for the skillful programmer.
(Note, Ada doesn't have any official subsets, but common sense shows the
way to a reasonable beginner's subset.)
Ada on VMS isn't currently very well supported. VMS is NOT one of GNAT's
favorite platorms, but it is available for free.
--
Robert Deininger
rdein...@mindspring.com
Carl Perkins
}> From: Christof Brass [mailto:br...@infopuls.com]
}> Christopher Smith wrote:
}> > It's interesting to note that I can't think of much
}> commercial software
}> > that's not written in C/C++ these days. Perhaps rather
}> than porting a
}> > modern application, one should consider looking for an
}> older one with a
}> > solid foundation and doing a port/enhancement at the same time.
}
}> Is there a classification in what PL apps are implemented?
}> Why not take a decent TurboPascal/Delphi app and port it to VMS?
}
}Well, no reason at all. Unfortunately I'm not sure that there are many apps
}done in turbo pascal (Delphi) these days. Probably fewer still that solve
}the problems for which VMS needs applications. :)
}
}On the other hand, if you can find one, it may be simple (relatively) to
}make a "turbo pascal compatibility layer" on top of DEC Pascal, or something
}like that, which could give functions that were like Delphi functions, but
}which used X11 for graphics, and native VMS interfaces for other things.
}That would solve the "immediate need" problem. A later version could, of
}course, be more properly ported.
Or you could just get Kylix (the new Linux version of Delphi)
ported to VMS.
--- Carl
Christof Brass
Fine with me.
Alan Greig
<klein...@star.zko.dec.com> wrote:
>If I had time on my hands, I would port Gnome.
>
>An alternative that might be interesting and do-able is to write an
>application that reads command line definition files, and builds a GUI
>interface for it.
It;s occurred to me previously that it should be possible to build a
very nice DCL GUI by doing this without too much work. Could even
cross-reference to the HELP libraries.
>People are always complaining that they want GUI interfaces to command line
>apps ;-)
>
>
>
--
Alan
Bob Koehler
>
> don't advocate requiring people to use "safe" languages. People can use
> what they like, but I'd never recommend that a person new to programming
> start out with fortran. ;)
Why not, isn't that what all real programmers learned first?
Or has WATERLOO FORTRAN WITH WATFOR AND WATFIV been out of print too
long?
----------------------------------------------------------------------
Bob Koehler | Computer Sciences Corporation
NASA GSFC Flight Software | Federal Sector, Civil Group
| please remove ".aspm" when replying
Bob Koehler
> Great, let's choose our entry level standard language. From my
> point of view it *is* possible to design a language in a way
> that it supports safety against stupid (human) mistakes and
> power for the skillful programmer. A modern Pascal version like
> the modular DEC Pascal will do the trick.
Considering that the original Pascal was invented as a teaching language
for exactly those kind of reasons, one cannot be too surprised.
Jan Vorbrueggen
> Challanger and Ariane V will not be the only "victims".
Both Challenger and the first Ariane V were a failure of systems
engineering. Somewhat different rules apply than on software 'engineering".
Jan
Christopher Smith
> From: Christof Brass [mailto:br...@infopuls.com]
> Christopher Smith wrote:
> > What I'm really saying is that I think the world should
> "standardize" on a
> > safer language (for application programming), since a lot
> of people who
> > don't know much about programming will just go with the
> standard. The trick
> > is to make it safe, while not making it too restrictive for
> an experienced
> > programmer (who will inevitably get stuck using it some
> time or another).
> Great, let's choose our entry level standard language. From my
> point of view it *is* possible to design a language in a way
> that it supports safety against stupid (human) mistakes and
> power for the skillful programmer. A modern Pascal version like
> the modular DEC Pascal will do the trick.
Well, Robert Deininger has suggested Ada, which is not my preference,
although it would work. I tend to prefer Mr. Wirth's more modern languages
to a DOD project based on his previous work. Something like a dialect of
Modula or Oberon might work. Alternatively, native Java would certainly
make the C people happy.
The mention of Oberon actually makes me wonder how much of the trouble with
software could be solved in the implementation language. On the other hand,
I think most of the remaining problems would be environmental, and VMS
should be a solid foundation for our mythical new language.
Perhaps we could come up with a list of constructs which most often
contribute to code malfunction?
Common ones would be:
Strings with no length.
Unstructured "manual" (de)allocation of memory.
Absence of a clearly defined (possibly it should even be platform agnostic)
type for one of: Array, int, float, long, double
Goto ;) (Not that I think it's used excessively any more, but you don't
want to encourage it if it's not required)
Pointer arithmetic ( A beginner shouldn't probably go pointing to random
spots in memory without knowing what they're getting in to )
Absence of a clear indicator whether an item is to be passed by reference or
value ( I think taking the pass by reference out by default may be going too
far )
Built-in functions which conflict with user-defined ones (This can be solved
with namespaces to an extent)
Type conversion without an explicit indication (This one is arguable either
way, though, and integer to float, for instance, would probably be fine.
Maybe there should be a mechanism for defining to which (and how) types some
item may be converted? Again, that would call for a bit of
object-oriented-ness.)
Absence of an adequate set of standard procedures/functions. (I've seen
more bad code written to replace things that should be part of a standard
library than I care to remember. :)
Undefined behavior. :) (Seriously, "undefined" is not good enough. An
error should be emitted in all cases where behavior can't be "defined.")
Inconsistent use of delimiting characters () [] {}, '"` etc, etc. :) (more a
problem in script languages)
I'm sure I missed some things. This is what comes to mind at the moment.
So the implementation the above "features" in the language would need to be
tightly controlled (or absent all together for some). For those features
above which are useful, I would consider a separate module, where you can
specifically include them, perhaps even on a per-item, and per-function
basis. (eg. "I want to do manual memory allocation in this function")
> I recently read a proposal to replace "unsafe" by "only for
> restricted use" in the area of PLs.
If you mean in practice, moving all of the "unsafe" features into a module
that could be ignored by most people, then I think it's a very good idea.
As I said above, it may be even better if we can selectively include them
one at a time in single functions.
regards,
Shane....@healthnet.com
Heh, true. An IF statement doesn't usually corrode, or fail due to metal
fatigue...
Shane
Jan Vorbrueggen <j...@mailhost.neuroinformatik.ruhr-uni-bochum.de> on
06/05/2001 09:00:17 AM
Please respond to Jan Vorbrueggen
<j...@mailhost.neuroinformatik.ruhr-uni-bochum.de>
To: Info...@Mvb.Saic.Com
cc:
Subject: Re: The future of VMS
Christof Brass
Both were a result of sloppyness. The reason I mentioned it was
to show that you should take into account that people not only
make mistakes but also don't adhere to best practices or rules
given by their employer.
Christof Brass
:-)
Christof Brass
A no-issue in a proper designed language.
> Type conversion without an explicit indication (This one is arguable either
> way, though, and integer to float, for instance, would probably be fine.
> Maybe there should be a mechanism for defining to which (and how) types some
> item may be converted? Again, that would call for a bit of
> object-oriented-ness.)
>
> Absence of an adequate set of standard procedures/functions. (I've seen
> more bad code written to replace things that should be part of a standard
> library than I care to remember. :)
I suggest to use the term "standard" procedures/functions for
the pervasive built-in procedures/functions. Libraries are
basically language independent. But agreed, a set of powerful
and proper designed libraries (as opposed to the Java class
library) would substantially improve the value of the
language/system.
> Undefined behavior. :) (Seriously, "undefined" is not good enough. An
> error should be emitted in all cases where behavior can't be "defined.")
??? Could you please give an example?
> Inconsistent use of delimiting characters () [] {}, '"` etc, etc. :) (more a
> problem in script languages)
>
> I'm sure I missed some things. This is what comes to mind at the moment.
I would add a bunch of features wrt basic software engineering
like separate compilation and type safe linking - both is
missing in C/C++. The make system for C/C++ is completely
rotten. The development enviroment must ensure without
intervention of the programmer that the generated executables
are technically correct.
The language/RTS must offer dynamic loading like Java. And, of
course, the language must be oo, although a hybrid solution like
Java or Modula-3 is very good.
> So the implementation the above "features" in the language would need to be
> tightly controlled (or absent all together for some). For those features
> above which are useful, I would consider a separate module, where you can
> specifically include them, perhaps even on a per-item, and per-function
> basis. (eg. "I want to do manual memory allocation in this function")
>
> > I recently read a proposal to replace "unsafe" by "only for
> > restricted use" in the area of PLs.
>
> If you mean in practice, moving all of the "unsafe" features into a module
> that could be ignored by most people, then I think it's a very good idea.
> As I said above, it may be even better if we can selectively include them
> one at a time in single functions.
>
> regards,
>
> Chris
>
> Christopher Smith, Perl Developer
> Amdocs - Champaign, IL
>
> /usr/bin/perl -e '
> print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");
>'
Your proposal is close to what is done in modern Wirth languages
like Oberon or Modula-3, the development of the latter has been
completely funded by DEC: functions of restricted use are only
available with a special declaration at the beginning of a
module.
May I suggest not to define a new PL - there are more than
enough to choose from - but instead to decide which one to
support. The language should be adequate to the quality of VMS'
design, architecture and implementation. This would be then the
language of choice to write apps for VMS.
Robert Deininger
<3B55D7F383B0D31197D9...@cmiexch1.cmi.itds.com>,
Christopher Smith <csm...@amdocs.com> wrote:
> Well, Robert Deininger has suggested Ada, which is not my preference,
> although it would work. I tend to prefer Mr. Wirth's more modern languages
> to a DOD project based on his previous work.
There's really not much DOD left in Ada these days. The Ada95
standardization work was very open.
What don't you like about Ada, just to be curious?
> Perhaps we could come up with a list of constructs which most often
> contribute to code malfunction?
See the C reference manual? Partly kidding. I'll let Christof supply the
heavy ammunition here. :-)
> I'm sure I missed some things. This is what comes to mind at the moment.
>
> So the implementation the above "features" in the language would need to be
> tightly controlled (or absent all together for some). For those features
> above which are useful, I would consider a separate module, where you can
> specifically include them, perhaps even on a per-item, and per-function
> basis. (eg. "I want to do manual memory allocation in this function")
Have you read the Ada Rationale? Interesting to follow some of the
reasoning that went into the language.
> > I recently read a proposal to replace "unsafe" by "only for
> > restricted use" in the area of PLs.
>
> If you mean in practice, moving all of the "unsafe" features into a module
> that could be ignored by most people, then I think it's a very good idea.
> As I said above, it may be even better if we can selectively include them
> one at a time in single functions.
Ada does this, for example unchecked_deallocation and uncheck_conversion.
When a module uses these, you have a red flag to be careful around it.
--
Robert Deininger
rdein...@mindspring.com
Linda Luik
basic high school student project. It's also funny how system
administrators used to be engineers (or at least people with a four year
college degrees) now there's high school graduates (little or no
college) performing these tasks. Not that that's a bad thing. That just
means that computers have become easier to use and high school educators
are catching up with the real world. The bad part is is that disciplined
use of structured programming techiniques and documentation have put in
the back seat -- or hidden away in the trunk!
Linda
Bob Koehler wrote:
>
> In article <3B55D7F383B0D31197D9...@cmiexch1.cmi.itds.com>, Christopher Smith <csm...@amdocs.com> writes:
> >
> > That's putting it bluntly. :) I'd like to make it clear, though, that I
> > don't advocate requiring people to use "safe" languages. People can use
> > what they like, but I'd never recommend that a person new to programming
> > start out with fortran. ;)
>
> Why not, isn't that what all real programmers learned first?
>
> Or has WATERLOO FORTRAN WITH WATFOR AND WATFIV been out of print too
> long?
>
> ----------------------------------------------------------------------
> Bob Koehler | Computer Sciences Corporation
> NASA GSFC Flight Software | Federal Sector, Civil Group
> | please remove ".aspm" when replying
--
Linda Luik
Motorola GIS
2200 W. Broadway Rd.
AZ09-M555
Mesa, Arizona 85202
Phone: 480-655-4432
FAX: 480-655-3659
Pager 1-888-772-5230
linda...@motorola.com
Alan Greig
>
>Heh, true. An IF statement doesn't usually corrode, or fail due to metal
>fatigue...
Except possibly silicon fatigue due to cosmic rays on Sun hardware :-)
--
Alan
steven...@quintiles.com
I think it's not quite that simple.....
Computers, like education, have been dumbed down in certain areas. It's
true that a person leaving high school now thinks that they can administer
systems (and are often employed for that role). The problem comes when
something goes wrong or when the department/company which they are
supporting reaches a certain critical mass. At this stage, the high school
person just can't cope unless they've had significant experience. They
probably don't have the analysis techniques in their heads to be able to
consider what the symptoms are and what the underlying problem which is
causing them might be. As a colleague and I discussed and he suggested to
me a while back - there are too many people out there who can look at the
system or the router but can't see the whole picture and think about how
all of these items fit together.
One thing that came up in another thread this week was the problem of
whether network cards can do autonegotiation on speeds and feeds. Most of
us in this group can understand what the problems might be (or at least
hazard a guess) and how this affects other systems on the network. A
windows weenie straight from school would probably not have the background
or the experience to be able to do that. Heck, there's people with
significant experience in my previous and present employment who wouldn't
have the experience and would probably go all around the houses to supply a
two second fix.
For programming, I don't think there are many places where programming is
taught other than in clicky-draggy mode using VB or similar.
Steve.
Main, Kerry
Just to expand on what you are saying about todays additional support
requirements -
Even though the cars today are more sophisticated, faster, better quality
etc., you can still easily teach a 16 year old how to drive. That is not
much different than 10 years ago.
Similarily, the kids today can use faster systems to do certain things at a
certain level.
However, the mechanic fixing integration problems with onboard
microprocessors in many common vehicles today is very much a different
person than the mechanic working on cars 10 years ago.
GPS devices being able to locate cars and shutdown engines in case of theft
. that is a totally different vehicle support requirement than tuning a
carburetor.
Similarily, keeping an IT infrastructure up and running on a 24x7 basis and
fixing things before they impact the business and complex middleware
programming designed to be highly scalable, reliable, take advantage of the
local platforms clustering features etc requires a whole different level of
support than a simple college programmer (VB?) or admin person who has no
real experience.
:-)
Kerry Main
Senior Consultant
Compaq Canada Inc.
Professional Services
Voice: 613-592-4660
Fax : 819-772-7036
Email: Kerry...@Compaq.com
-----Original Message-----
From: steven...@quintiles.com [mailto:steven...@quintiles.com]
Sent: June 6, 2001 5:37 AM
To: Info...@Mvb.Saic.Com
Subject: Re: The future of VMS
Christopher Smith
> From: Christof Brass [mailto:br...@infopuls.com]
> Christopher Smith wrote:
> > Undefined behavior. :) (Seriously, "undefined" is not good
> enough. An
> > error should be emitted in all cases where behavior can't
> be "defined.")
> ??? Could you please give an example?
Here's something I dug up just now. It's C, of course. :)
..actually it's an extension to C, I believe. The whole document is at
http://www.lysator.liu.se/c/restrict.html
1 Figure 7 Restricted pointer function parameters
2 float x[100];
3 float *c;
4
5 void f3(int n, float * restrict a, float * const b) {
6 int i;
7 for ( i=0; i<n; i++ )
8 a[i] = b[i] + c[i];
9 }
10 void g3(void) {
11 float d[100], e[100];
12 c = x; f3(100, d, e); /* Behavior defined. */
13 f3( 50, d, d+50); /* Behavior defined. */
14 f3( 99, d+1, d); /* Behavior undefined. */
15 c = d; f3( 99, d+1, e); /* Behavior undefined. */
16 f3( 99, e, d+1); /* Behavior defined. */
17 }
18
19 Two of the calls shown in g3 result in aliasing that is
20 inconsistent with the restrict qualifier, and their behavior
21 is undefined. Note that it is permitted for c to point into
22 the array associated with b. Note also that, for these
23 purposes, the ``array'' associated with a particular pointer
24 means only that portion of an array object which is actually
25 referenced through that pointer.
Note that this document says that lines 14 and 15 will not behave properly,
however, it doesn't specify in this case that the compiler should return an
error and refuse to accept them. There are a few things of this nature
floating around, especially in C.
> > I'm sure I missed some things. This is what comes to mind
> at the moment.
> I would add a bunch of features wrt basic software engineering
> like separate compilation and type safe linking - both is
> missing in C/C++. The make system for C/C++ is completely
> rotten. The development enviroment must ensure without
> intervention of the programmer that the generated executables
> are technically correct.
I was actually going to suggest that the linker be made "smarter" than most
are. That slipped my mind before I wrote it down, but there are several
problems that I've seen which could have been avoided if the linking process
was a bit more intelligent.
> The language/RTS must offer dynamic loading like Java. And, of
> course, the language must be oo, although a hybrid solution like
> Java or Modula-3 is very good.
Can't argue with that.
> Your proposal is close to what is done in modern Wirth languages
> like Oberon or Modula-3, the development of the latter has been
> completely funded by DEC: functions of restricted use are only
> available with a special declaration at the beginning of a
> module.
I noticed, myself, that it was turning out to be very similar. You never
know, though, until you think it through.
> May I suggest not to define a new PL - there are more than
> enough to choose from - but instead to decide which one to
> support. The language should be adequate to the quality of VMS'
> design, architecture and implementation. This would be then the
> language of choice to write apps for VMS.
Modula-3 is probably a very good choice. The question is, how does one get
people to use it? Another issue comes up with porting to other systems. If
there's a decent cross-platform Modula-3 compiler, I'd like to know about
it. If you could get the same app to run on VMS, Beos, MacOS, etc, etc,
that would likely be useful. Also, do you know whether the VMS Modula-3
compiler can use X11 for graphics -- what about the "cross-platform"
equivalent? (People like to have graphical interfaces.)
Regards,
Christopher Smith
> In article
> <3B55D7F383B0D31197D9...@cmiexch1.cmi.itds.com>,
> Christopher Smith <csm...@amdocs.com> wrote:
> > although it would work. I tend to prefer Mr. Wirth's more
> modern languages
> > to a DOD project based on his previous work.
> There's really not much DOD left in Ada these days. The Ada95
> standardization work was very open.
Maybe I should look over it again, then. I do still have a couple of
reference books, which I should dig out.
> What don't you like about Ada, just to be curious?
It's been a while, but here are my opinions from when I used it:
I like the Pascal-style syntax, and I like that it's been applied to a
language with a modern design, OO type features, etc.
I dislike that the designers chose to make you type in the entire
hierarchical path to a given procedure when it's not in the current module.
(Ok, there is the 'use' command, which I had some trouble with since I could
only get it to 'use' one module at a time. :)) I don't particularly
appreciate many of the "self-documenting" features. I do write my own
documentation, and I do it fairly well. A self-documenting language will
just slow me down, because I'll end up writing all the documentation twice
-- once for the compiler. :) I don't need two and three character names,
but fifteen is excessive. That's not a big problem, and I could live with
it anyway.
Looking around, it seems that several of the problems I'd had with the
language are non-existent at this point.
> > Perhaps we could come up with a list of constructs which most often
> > contribute to code malfunction?
> See the C reference manual? Partly kidding. I'll let
> Christof supply the
> heavy ammunition here. :-)
Oh, they're all in there. :) See my previous list.
> Have you read the Ada Rationale? Interesting to follow some of the
> reasoning that went into the language.
Nope, do you have a link?
> Ada does this, for example unchecked_deallocation and
> uncheck_conversion.
> When a module uses these, you have a red flag to be careful around it.
It seems that in theory Ada is very similar to Modula-3, which Christoff and
I have both mentioned. It would be interesting to see a comparison.
Chris Casey
Christopher Smith wrote in message
<3B55D7F383B0D31197D9...@cmiexch1.cmi.itds.com>...
>> -----Original Message-----
>> From: rdein...@mindspring.com [mailto:rdein...@mindspring.com]
>
>> In article
>> <3B55D7F383B0D31197D9...@cmiexch1.cmi.itds.com>,
>> Christopher Smith <csm...@amdocs.com> wrote:
>
>> > although it would work. I tend to prefer Mr. Wirth's more
>> modern languages
>> > to a DOD project based on his previous work.
PMFJI but if you want a higly scaleable and portable language you should
take a look at Mumps and its newer hybrid Cache.
This even works on billy boxes as well as providing high performance
database systems on real boxes and operating systems.
It includes many modes including object based, SQL based or just good old
scripting.
It's database elements have proven time and again to be the fastest
operating in the VMS environment and, if it wasn't for good ol DEC trying to
flog RDB (now Oracle) it would have been their flagship.
Not trying to sell you anything, just my opinion.
Robert Deininger
<3B55D7F383B0D31197D9...@cmiexch1.cmi.itds.com>,
Christopher Smith <csm...@amdocs.com> wrote:
> > There's really not much DOD left in Ada these days. The Ada95
> > standardization work was very open.
>
> Maybe I should look over it again, then. I do still have a couple of
> reference books, which I should dig out.
>
> > What don't you like about Ada, just to be curious?
>
> It's been a while, but here are my opinions from when I used it:
>
> I like the Pascal-style syntax, and I like that it's been applied to a
> language with a modern design, OO type features, etc.
>
> I dislike that the designers chose to make you type in the entire
> hierarchical path to a given procedure when it's not in the current module.
> (Ok, there is the 'use' command, which I had some trouble with since I could
> only get it to 'use' one module at a time. :))
If long multi-part procedure names become a pain, you can shorten them
with some renaming declarations.
If your packages are well organized, a USE clause for the package should
give you a good collection of procedures with short names.
Ada style takes some getting used to. Trying to do things the (C,
Fortran) was leads to unnecessary discomfort.
> I don't particularly
> appreciate many of the "self-documenting" features.
I'm not sure I'm following you. Self documenting? You mean the
redundancy, for example the near-total duplication of procedure
declarations and definitions? I look at that as double-entry
bookkeeping. It lets the compiler cross-check, even with separate
compilation.
Ada is more verbose than many others, at least superficially. In a large
program, a lot of Ada is written at a very high level. You may end up
with fewer, smaller modules than in older languages. But each module will
seem verbose. C++, properly used, is probably as expressive. But it has
other problems.
I'm probably missing your point here...
> I do write my own
> documentation, and I do it fairly well. A self-documenting language will
> just slow me down, because I'll end up writing all the documentation twice
> -- once for the compiler. :)
AFAIK, the compiler really _uses_ all that information. Except for the
comments of course. Have you found an Ada compiler that forces you to
write comments?
I'd love to inflict it on some of my co-workers.
Someone mentioned earlier that C and C++ would be help by a smarter
linker. With Ada, you get that smarter linker, if by another name. Once
Ada signs off on an executable, you should not have any linker-type errors
left. (Unless you are mixing in non-Ada modules.)
> I don't need two and three character names,
> but fifteen is excessive. That's not a big problem, and I could live with
> it anyway.
Ada doesn't force long names on you. The longest reserved word is what,
"procedure"? (I don't have all 60-odd at my fingertips, so that's
probably NOT the longest one.)
> Looking around, it seems that several of the problems I'd had with the
> language are non-existent at this point.
>
> > > Perhaps we could come up with a list of constructs which most often
> > > contribute to code malfunction?
>
> > See the C reference manual? Partly kidding. I'll let
> > Christof supply the
> > heavy ammunition here. :-)
>
> Oh, they're all in there. :) See my previous list.
>
> > Have you read the Ada Rationale? Interesting to follow some of the
> > reasoning that went into the language.
>
> Nope, do you have a link?
http://www.adapower.com/
http://www.adapower.com/rationale/index.html
> > Ada does this, for example unchecked_deallocation and
> > uncheck_conversion.
> > When a module uses these, you have a red flag to be careful around it.
>
> It seems that in theory Ada is very similar to Modula-3, which Christoff and
> I have both mentioned. It would be interesting to see a comparison.
I haven't had time to study Modula-3, but my impression is that there was
some borrowing of ideas.
--
Robert Deininger
rdein...@mindspring.com
Larry Kilgallen
>> From: rdein...@mindspring.com [mailto:rdein...@mindspring.com]
>> Have you read the Ada Rationale? Interesting to follow some of the
>> reasoning that went into the language.
>
> Nope, do you have a link?
http://www.adapower.com/rationale/index.html
==============================================================================
Great Inventors of our time: Al Gore -> Internet; Sun Microsystems -> Clusters
==============================================================================
Christopher Smith
> In article
> <3B55D7F383B0D31197D9...@cmiexch1.cmi.itds.com>,
> Christopher Smith <csm...@amdocs.com> wrote:
> Ada style takes some getting used to. Trying to do things the (C,
> Fortran) was leads to unnecessary discomfort.
I have noticed that. It's easier to think of Ada as a Pascal-alike language
and program it as if you were writing Pascal. That works better -- not
quite perfectly, though.
> > I don't particularly
> > appreciate many of the "self-documenting" features.
> I'm not sure I'm following you. Self documenting? You mean the
Any language which is incredibly verbose in its statements is said by some
to be "self-documenting." That's crap, of course. No language is, but I
get the impression that all of the functions/procedures were named in such a
way that it may be simple for a non-programmer to understand what's going
on. That's not a bad thing, of course, but the extra verbosity required
also necessitates extra typing on my part.
> Ada is more verbose than many others, at least superficially.
> In a large
> program, a lot of Ada is written at a very high level. You may end up
> with fewer, smaller modules than in older languages. But
> each module will
> seem verbose. C++, properly used, is probably as expressive.
> But it has
> other problems.
That's exactly what I mean. I find that it takes about 1.5 times the
characters to express something in Ada properly. No big thing in general,
but it can get annoying sometimes.
> I'm probably missing your point here...
The point is that if a programmer writes comments into the code, the
declaration:
function blarg (A, B: boolean) return boolean is
can be condensed to something like:
--Blarg is a function which does... it accepts... and returns...
bool func blarg (A, B: bool):
If you're going to write the comment anyway, the previous is just extra
work.
> AFAIK, the compiler really _uses_ all that information.
> Except for the
> comments of course. Have you found an Ada compiler that forces you to
> write comments?
> I'd love to inflict it on some of my co-workers.
No, but I've seen people who could use it. Maybe look into intercal. It at
least requires them to ask nicely sometimes.
> Ada doesn't force long names on you. The longest reserved
> word is what,
> "procedure"? (I don't have all 60-odd at my fingertips, so that's
> probably NOT the longest one.)
What about in the standard procedures and functions? (What does Ada call
them? :)
Tim Llewellyn
steven...@quintiles.com wrote:
> I think it's not quite that simple.....
>
> Computers, like education, have been dumbed down in certain areas. It's
> true that a person leaving high school now thinks that they can administer
> systems (and are often employed for that role). The problem comes when
> something goes wrong or when the department/company which they are
> supporting reaches a certain critical mass. At this stage, the high school
> person just can't cope unless they've had significant experience. They
> probably don't have the analysis techniques in their heads to be able to
> consider what the symptoms are and what the underlying problem which is
> causing them might be. As a colleague and I discussed and he suggested to
> me a while back - there are too many people out there who can look at the
> system or the router but can't see the whole picture and think about how
> all of these items fit together.
ah, the good old "staffing for the troughs in demand" trick. Or, the apps
programmer
who won't touch anything but the particular 4GL they've been using for years.
:-)
Of course, non-technical management may wonder why they need those expensive
oldies
who really have seen the shit hit the fan enough to know when to duck and how
to fix it.
Sadly, it is an scenario all to familiar in and outside of IT, in this country.
My colleague has been trying for some days now to get his tax code from the IR
(Inland Revenue), every time he calls "the computer is down". My DSL provider
should surely be able to provide the quoted 250kbit/sec to any point on their
own network. I can barely tracrt to the first hop on their network mostly.
It is frightening that govt is standardizing on M$. Shows they have no real
appreciation
of IT issues.
ah well, car problems again today :-)
--
Tim Llewellyn, OpenVMS Infrastructure, Remarcs Project
MedAS at the BBC, Whiteladies Road, Bristol, UK.
Email tim.ll...@bbc.co.uk. Home tim.ll...@cableinet.co.uk
I speak for myself only and my views in no way represent those of
MedAS or the BBC.
Larry Kilgallen
>> -----Original Message-----
>> From: rdein...@mindspring.com [mailto:rdein...@mindspring.com]
>
>> In article
>> <3B55D7F383B0D31197D9...@cmiexch1.cmi.itds.com>,
>> Christopher Smith <csm...@amdocs.com> wrote:
>
>> Ada style takes some getting used to. Trying to do things the (C,
>> Fortran) was leads to unnecessary discomfort.
>
> I have noticed that. It's easier to think of Ada as a Pascal-alike language
> and program it as if you were writing Pascal. That works better -- not
> quite perfectly, though.
This is true of just about any language. Long before there was Ada,
somebody said "It is possible to write FORTRAN in any language".
The unspoken lesson is that because something is possible does
not mean it is a good idea. Any language should be programmed
in a style appropriate to that language.
> Any language which is incredibly verbose in its statements is said by some
> to be "self-documenting." That's crap, of course. No language is, but I
> get the impression that all of the functions/procedures were named in such a
> way that it may be simple for a non-programmer to understand what's going
> on. That's not a bad thing, of course, but the extra verbosity required
> also necessitates extra typing on my part.
Consider somebody new to the language, or to your project, trying
to understand your code while you are on vacation (or "holiday" :-).
They are going to read that line _many_ more times than you typed it.
Anyone writing Ada code should spend a _lot_ more time thinking about
it than typing it, and so far as I can see that applies to other
languages as well.
> The point is that if a programmer writes comments into the code, the
> declaration:
>
> function blarg (A, B: boolean) return boolean is
>
> can be condensed to something like:
>
> --Blarg is a function which does... it accepts... and returns...
> bool func blarg (A, B: bool):
>
> If you're going to write the comment anyway, the previous is just extra
> work.
Certainly that is an example of a poor comment. Comments should _not_
parrot what can be determined from the source. I would expect the
comment for the Blarg function to explain why it is not using the
standard Bla function for the project. I would also expect a
better name for the function, but perhaps it is a well-known
term in the problem domain.
>> Ada doesn't force long names on you. The longest reserved
>> word is what,
>> "procedure"? (I don't have all 60-odd at my fingertips, so that's
>> probably NOT the longest one.)
>
> What about in the standard procedures and functions? (What does Ada call
> them? :)
There are standard "packages" (similar to modules if you don't look
too closely), containing "subprograms":
http://www.ada-auth.org/~acats/arm-html/RM-A.html
For your project there may be heavily used "packages" that would not be
"standard" due to only being of interest to those working in your problem
domain.
While Generic_Complex_Elementary_Functions is certainly a keyboardful,
anyone really using it will take advantage of renaming or "use" clauses
to access the package. Within that package the longest function name
I can find is "Arctanh", and I doubt that even specialists in the field
would want it shorter.
By the way, Ada does let you have an Arctanh for floating point and
a different Arctanh for long floating point (if your machine has such)
and Ada decides which one you mean based on the type of arguments you
feed it. And no, there is no Arctanh that accepts two Booleans, although
you could define one if you thought you knew what it should do :-)
Christopher Smith
> -----Original Message-----
> From: Kilg...@eisner.decus.org.nospam
> In article
> <3B55D7F383B0D31197D9...@cmiexch1.cmi.itds.co
> m>, Christopher Smith <csm...@amdocs.com> writes:
> > The point is that if a programmer writes comments into the code, the
> > declaration:
> >
> > function blarg (A, B: boolean) return boolean is
> >
> > can be condensed to something like:
> >
> > --Blarg is a function which does... it accepts... and returns...
> > bool func blarg (A, B: bool):
> >
> > If you're going to write the comment anyway, the previous
> is just extra
> > work.
> Certainly that is an example of a poor comment. Comments should _not_
> parrot what can be determined from the source. I would expect the
> comment for the Blarg function to explain why it is not using the
> standard Bla function for the project. I would also expect a
> better name for the function, but perhaps it is a well-known
> term in the problem domain.
Or maybe it's a poor example of a comment. :) What I mean is that the
comment should say what your function does to its arguments and (or at
least) why, what to expect out of it, and what (not) to do with it, if
appropriate.
I do think it's appropriate to give more information than necessary in your
comments, because most people reading your code will speak your native
language more fluently than whatever programming language it's in. If you
can help them to avoid some 3:00 am errors, so much the better.
> While Generic_Complex_Elementary_Functions is certainly a keyboardful,
Wow, I'd forgotten about that one. :)
> anyone really using it will take advantage of renaming or
> "use" clauses
> to access the package. Within that package the longest function name
> I can find is "Arctanh", and I doubt that even specialists in
> the field
> would want it shorter.
No, Arctanh is fine. Generic_Complex_Elementary_Functions is a bit too
much, I think :) On the other hand, there's something profound about the
command "use Generic_Complex_Elementary_Functions;"
Larry Kilgallen
My first priority would be to have some of that information
incorporated into the name of the function, so I know it even
when I am looking at the module that calls it:
Blarg
vs.
Blarg_Thread_Safe
Of course what I _really_ want is for the person who wrote the
original to have called it:
Blarg_Thread_Unsafe
but I realize that is too much to hope for.
The comment can then explain anything further than needs explaining,
and in some languages that might include the data types for the
arguments.
> I do think it's appropriate to give more information than necessary in your
> comments, because most people reading your code will speak your native
> language more fluently than whatever programming language it's in. If you
> can help them to avoid some 3:00 am errors, so much the better.
Given that as the goal, I would suggest that the information described
is not "more information than necessary". Certainly, there will be
_some_ readers for which some of the information is superfluous,
such as those who have read it before. They can take their
consolation in feeling superior.
Christopher Smith
> From: Kilg...@eisner.decus.org.nospam
> In article
> <3B55D7F383B0D31197D9...@cmiexch1.cmi.itds.co
> m>, Christopher Smith <csm...@amdocs.com> writes:
> My first priority would be to have some of that information
> incorporated into the name of the function, so I know it even
> when I am looking at the module that calls it:
> Blarg
> vs.
> Blarg_Thread_Safe
> Of course what I _really_ want is for the person who wrote the
> original to have called it:
> Blarg_Thread_Unsafe
> but I realize that is too much to hope for.
Fair enough, as long as you don't start tacking senseless prefixes on to
accomplish the goal... For instance, Blarg_Thread_Safe is fine, but
m_pfulBlarg is probably worthless. :)
> > I do think it's appropriate to give more information than
> necessary in your
> > comments, because most people reading your code will speak
> your native
> > language more fluently than whatever programming language
> it's in. If you
> > can help them to avoid some 3:00 am errors, so much the better.
> Given that as the goal, I would suggest that the information described
> is not "more information than necessary". Certainly, there will be
> _some_ readers for which some of the information is superfluous,
> such as those who have read it before. They can take their
> consolation in feeling superior.
True enough. It's not as if people are forced to read the comments.
JF Mezei
> Similarily, keeping an IT infrastructure up and running on a 24x7 basis and
> fixing things before they impact the business and complex middleware
> programming designed to be highly scalable, reliable, take advantage of the
> local platforms clustering features etc requires a whole different level of
> support than a simple college programmer (VB?) or admin person who has no
> real experience.
Unfortunatly, Bill Gates convinced the industry that it is easier to be
tolerant of faults than to be fault tolerant. Case in point, a large GSM
wireless company in Canada who though that having its web site and
email-to-from-phones services down for a whole week was quite acceptable, and
6 months later, their web site still says that if you have a mac, they
apoligize but it won't work.
(And these people upgraded from NT to a serious system : SUN). I guess their
windows teenage weenies had to learn how to operate stuff on Unix *after* they
went into production.)
Christof Brass
>
> In article
> <3B55D7F383B0D31197D9...@cmiexch1.cmi.itds.com>,
> Christopher Smith <csm...@amdocs.com> wrote:
>
> > Well, Robert Deininger has suggested Ada, which is not my preference,
> > although it would work. I tend to prefer Mr. Wirth's more modern languages
> > to a DOD project based on his previous work.
>
> There's really not much DOD left in Ada these days. The Ada95
> standardization work was very open.
>
> What don't you like about Ada, just to be curious?
I don't have much practice with Ada but I even don't regard the
history as problem. At least we could conclude that the DoD had
utmost quality in several aspects in mind: interoperability of
different platforms i.e. a very well defined standard which
excludes platform dependency to a degree that could be
questionable (e.g. the inherent task model), good self
documentation, safety and a good programming style. We should
keep in mind that Ada was very well supported by DEC in the
80ies.
The only problem I associate with Ada is "a camel is a horse
designed by a committee" and the PL/1 syndrom. But I recently
looked at the oo extension introduced in Ada95 and I found them
quite useful. Ada or Modula-3 are my favourite candidates from a
perspective a broad acceptance. Also I have some other languages
"in petto".
> > Perhaps we could come up with a list of constructs which most often
> > contribute to code malfunction?
>
> See the C reference manual? Partly kidding. I'll let Christof supply the
> heavy ammunition here. :-)
Thanks :-)
> > I'm sure I missed some things. This is what comes to mind at the moment.
> >
> > So the implementation the above "features" in the language would need to be
> > tightly controlled (or absent all together for some). For those features
> > above which are useful, I would consider a separate module, where you can
> > specifically include them, perhaps even on a per-item, and per-function
> > basis. (eg. "I want to do manual memory allocation in this function")
>
> Have you read the Ada Rationale? Interesting to follow some of the
> reasoning that went into the language.
>
> > > I recently read a proposal to replace "unsafe" by "only for
> > > restricted use" in the area of PLs.
> >
> > If you mean in practice, moving all of the "unsafe" features into a module
> > that could be ignored by most people, then I think it's a very good idea.
> > As I said above, it may be even better if we can selectively include them
> > one at a time in single functions.
>
> Ada does this, for example unchecked_deallocation and uncheck_conversion.
> When a module uses these, you have a red flag to be careful around it.
>
> --
> Robert Deininger
> rdein...@mindspring.com
Basic question to the Ada expert: Is it possible to dynamically
load code like in Java or some very few other languages/systems?
This is especially interesting in an oo framework environment.
Christof Brass
Thanks, I got the picture.
> Note that this document says that lines 14 and 15 will not behave properly,
> however, it doesn't specify in this case that the compiler should return an
> error and refuse to accept them. There are a few things of this nature
> floating around, especially in C.
This is in deed very evil and that shouldn't of course not in
any programming language. Sometimes there is weaker form of
this: you can write it but it will behave differently on
different platforms but at least equal (i.e. defined,
deterministic) on one platform.
> > > I'm sure I missed some things. This is what comes to mind
> > at the moment.
>
> > I would add a bunch of features wrt basic software engineering
> > like separate compilation and type safe linking - both is
> > missing in C/C++. The make system for C/C++ is completely
> > rotten. The development enviroment must ensure without
> > intervention of the programmer that the generated executables
> > are technically correct.
>
> I was actually going to suggest that the linker be made "smarter" than most
> are. That slipped my mind before I wrote it down, but there are several
> problems that I've seen which could have been avoided if the linking process
> was a bit more intelligent.
Fine with me.
> > The language/RTS must offer dynamic loading like Java. And, of
> > course, the language must be oo, although a hybrid solution like
> > Java or Modula-3 is very good.
>
> Can't argue with that.
:-)
> > Your proposal is close to what is done in modern Wirth languages
> > like Oberon or Modula-3, the development of the latter has been
> > completely funded by DEC: functions of restricted use are only
> > available with a special declaration at the beginning of a
> > module.
>
> I noticed, myself, that it was turning out to be very similar. You never
> know, though, until you think it through.
We should then conclude that your proposal has to be rated as
high quality work :-)
> > May I suggest not to define a new PL - there are more than
> > enough to choose from - but instead to decide which one to
> > support. The language should be adequate to the quality of VMS'
> > design, architecture and implementation. This would be then the
> > language of choice to write apps for VMS.
>
> Modula-3 is probably a very good choice. The question is, how does one get
> people to use it? Another issue comes up with porting to other systems. If
> there's a decent cross-platform Modula-3 compiler, I'd like to know about
> it. If you could get the same app to run on VMS, Beos, MacOS, etc, etc,
> that would likely be useful. Also, do you know whether the VMS Modula-3
> compiler can use X11 for graphics -- what about the "cross-platform"
> equivalent? (People like to have graphical interfaces.)
>
> Regards,
>
> Chris
>
> Christopher Smith, Perl Developer
> Amdocs - Champaign, IL
>
> /usr/bin/perl -e '
> print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");
> '
These are a good but hard questions:
- should we aim for portability from VMS to other platforms?
- how do we get people to use the language(s) of choice?
I personally think that VMS is unique and therefore any attempt
to make portability inherent will lower the quality of the VMS
version - at least wrt VMS integration. I'm not talking about
(trivial) best practices like layering and modularisation. I
think about using the unique VMS API (QIO, AST, RMS). I think
the best what can happend to VMS is that high quality apps are
developed or ported to VMS that take full advantage of the VMS
unique features. The idea is to attract *users* or *customers*
to use VMS instead to offer good programs also on other
platforms.
I'm personally sure that there is and will be only small
percentage of programmers who are willing to concentrate on the
real interesting programming tasks instead of mastering
unecessary problems of PLs that aren't designed or don't meet up
to date quality criteria. The question is therefore to find
exactly this minority and to create a community or something
like that which includes these people and the customer/user
base. What interests me most in that respect: how many people
are there of this type (including those that don't know yet)?
And is this number high enough to achieve what we need (all
necessary apps and enough payment)?
Christof Brass
[SNIP]
Sorry, have forgotten one thing: the point about the X11
interface is a no-issue because this is basically language
independent. If this exists - fine; if not, we write an
interface. End of story.
Christof Brass
Sorry to say this again: I looked into MUMPS programs and found
them awful - combining the worst aspects of BASIC, C and
assembly language.
Christof Brass
>
> In article
> <3B55D7F383B0D31197D9...@cmiexch1.cmi.itds.com>,
> Christopher Smith <csm...@amdocs.com> wrote:
>
> > > There's really not much DOD left in Ada these days. The Ada95
> > > standardization work was very open.
> >
> > Maybe I should look over it again, then. I do still have a couple of
> > reference books, which I should dig out.
> >
> > > What don't you like about Ada, just to be curious?
> >
> > It's been a while, but here are my opinions from when I used it:
> >
> > I like the Pascal-style syntax, and I like that it's been applied to a
> > language with a modern design, OO type features, etc.
> >
> > I dislike that the designers chose to make you type in the entire
> > hierarchical path to a given procedure when it's not in the current module.
> > (Ok, there is the 'use' command, which I had some trouble with since I could
> > only get it to 'use' one module at a time. :))
>
> If long multi-part procedure names become a pain, you can shorten them
> with some renaming declarations.
The trend in high quality programming is towards full
declaration, long names etc., and strongly against renaming or
aliasing because this makes the same objects available under
different names which is overall not desirable.
Some verbosity of all well designed languages (look at Java
which is very verbose for a C style language) is a result of the
bad experiences with operator based languages like C/C++, Lisp,
APL or PERL. The basic contest: how high is the percentage of
random texts that the compiler/interpreter regards as valid
programs? The idea of verbosity is to some extend to avoid
stupid mistakes and make the programs easy readable. Do you like
to read RegExps?
Additional questions to the Ada expert:
- Has Ada a GC?
- Has Ada95 a proper type test for dynamically typed objects?
Christof Brass
>
> > -----Original Message-----
> > From: rdein...@mindspring.com [mailto:rdein...@mindspring.com]
>
> > In article
> > <3B55D7F383B0D31197D9...@cmiexch1.cmi.itds.com>,
> > Christopher Smith <csm...@amdocs.com> wrote:
>
> > Ada style takes some getting used to. Trying to do things the (C,
> > Fortran) was leads to unnecessary discomfort.
>
> I have noticed that. It's easier to think of Ada as a Pascal-alike language
> and program it as if you were writing Pascal. That works better -- not
> quite perfectly, though.
Ada has been stronly influenced by other languages - especially
Pascal.
As a sidenote to Robert Deiningers "I haven't had time to study
Modula-3, but my impression is that there was some borrowing of
ideas." PLs development is a circus of borrowing of ideas. But
some people are smarter and some are more interested in
design/quality than in market share, similarity to existing ones
etc.. Sometimes the latter and the former are the same and you
get really good results, i.e. really good languages. Alas, you
need some time to adapt. It's like in the OS arena: a person
only acquainted with Windoze or UNIX (which should never be used
anyway because it's a collection of designless pieces of code
fragments) has real problems to understand VMS. I just had a
discussion with a programmer and former sys admin who admitted
that VMS was terra incognita since they phased it our anly six
months after joining the university at that time. This person
has really no clue about VMS. How could we expect someone to
like something what is completely unknown?
> > > I don't particularly
> > > appreciate many of the "self-documenting" features.
>
> > I'm not sure I'm following you. Self documenting? You mean the
>
> Any language which is incredibly verbose in its statements is said by some
> to be "self-documenting." That's crap, of course. No language is, but I
> get the impression that all of the functions/procedures were named in such a
> way that it may be simple for a non-programmer to understand what's going
> on. That's not a bad thing, of course, but the extra verbosity required
> also necessitates extra typing on my part.
If you could use an ultra modern development environment there
might be a chance to copy something instead of re-typing it ;-)
About 50% of the quality of a PL is the style introduced by its
designers and continued/maintained by its community. To write
easy understandable SW is to a very high degree a question of
style. Ada supports and even sometimes enforces this style.
> > Ada is more verbose than many others, at least superficially.
> > In a large
> > program, a lot of Ada is written at a very high level. You may end up
> > with fewer, smaller modules than in older languages. But
> > each module will
> > seem verbose. C++, properly used, is probably as expressive.
> > But it has
> > other problems.
>
> That's exactly what I mean. I find that it takes about 1.5 times the
> characters to express something in Ada properly. No big thing in general,
> but it can get annoying sometimes.
>
> > I'm probably missing your point here...
>
> The point is that if a programmer writes comments into the code, the
> declaration:
>
> function blarg (A, B: boolean) return boolean is
>
> can be condensed to something like:
>
> --Blarg is a function which does... it accepts... and returns...
> bool func blarg (A, B: bool):
>
> If you're going to write the comment anyway, the previous is just extra
> work.
But there is one important rule (like in good opera
productions): never duplicate the program in the comment (never
show on stage what is already clear with the music), i.e. never
comment what is obvious from what is written - always comment
about overall structure or what is going to happen or what is
the idea behind. The comment should contain hints which aren't
obvious from what is written.
Christof Brass
But then you would need a very good comment ...
Chris Casey
Christof Brass wrote in message <3B1EB1D4...@infopuls.com>...
>Sorry to say this again: I looked into MUMPS programs and found
>them awful - combining the worst aspects of BASIC, C and
>assembly language.
I didn't think that you had actually said that before in a literate form.
I would be interested in your reasoning behind these statements.
Larry Kilgallen
> - Has Ada a GC?
The Ada standard treats garbage collection as an implementation detail
and neither requires it nor prohibits it. The marketplace current
state is that compiler implementers are not providing garbage collection
and say their customers are not demanding it. The obvious exception is
Ada compilers that target a Java bytecode machine.
> - Has Ada95 a proper type test for dynamically typed objects?
Yes.
Main, Kerry
>>> Unfortunatly, Bill Gates convinced the industry that it is easier to be
tolerant of faults than to be fault tolerant. >>>
While this has been true in the past when there was relatively little
competition, I would suggest that the days of not providing high levels of
service are rapidly coming to a close.
Bottom line is that there is just to much competition.
There are some very hungry competitors who are ready to quickly take your
business out of the hands of those lower service level vendors.
The dot.bomb or flop com market is a good example where only those with
serious offerings are going to survive.
Should be interesting.
:-)
Regards
Kerry Main
Senior Consultant
Compaq Canada Inc.
Professional Services
Voice: 613-592-4660
Fax : 819-772-7036
Email: Kerry...@Compaq.com
-----Original Message-----
From: JF Mezei [mailto:jfmezei...@videotron.ca]
Sent: June 6, 2001 3:07 PM
To: Info...@Mvb.Saic.Com
Subject: Re: The future of VMS
Shane....@healthnet.com
Someone recently put out the quote about "you can write FORTRAN code in any
language". (And it's true, I know this from experience...) Well, you can
write crap code in any language too. The most important component in any
piece of quality code is programmer discipline. Sure, you can use single
character variable names in C and leave out the comments, but you can do
equivalently stupid things in any language. A disciplined and determined
programmer can produce sources (ie commented code) you can understand in
any language I know of. If anyone has written a language you /can't/ put
comments in, they should be caught and beaten liberally with a wet haddock,
then locked away somewhere they can't do any more harm.
This shouldn't be turned into a "my language is better than yours" thing
here, I'm not addressing that at all. We all know some languages are
inherently easier to follow than others, we just can't all agree on which
ones... ;-)
Shane
Christof Brass <br...@infopuls.com> on 06/06/2001 03:50:55 PM
Please respond to Christof Brass <br...@infopuls.com>
To: Info...@Mvb.Saic.Com
cc:
Subject: Re: The future of VMS
Robert Deininger wrote:
>
> In article
> <3B55D7F383B0D31197D9...@cmiexch1.cmi.itds.com>,
> Ada style takes some getting used to. Trying to do things the (C,
> Fortran) was leads to unnecessary discomfort.
>
> > I don't particularly
> > appreciate many of the "self-documenting" features.
>
> I'm not sure I'm following you. Self documenting? You mean the
> redundancy, for example the near-total duplication of procedure
> declarations and definitions? I look at that as double-entry
> bookkeeping. It lets the compiler cross-check, even with separate
> compilation.
>
> Ada is more verbose than many others, at least superficially. In a large
> program, a lot of Ada is written at a very high level. You may end up
> with fewer, smaller modules than in older languages. But each module
will
> seem verbose. C++, properly used, is probably as expressive. But it has
> other problems.
>
> I'm probably missing your point here...
>
> > I do write my own
> > documentation, and I do it fairly well. A self-documenting language
will
> > just slow me down, because I'll end up writing all the documentation
twice
> > -- once for the compiler. :)
>
> AFAIK, the compiler really _uses_ all that information. Except for the
> comments of course. Have you found an Ada compiler that forces you to
> write comments?
> I'd love to inflict it on some of my co-workers.
>
> Someone mentioned earlier that C and C++ would be help by a smarter
> linker. With Ada, you get that smarter linker, if by another name. Once
> Ada signs off on an executable, you should not have any linker-type
errors
> left. (Unless you are mixing in non-Ada modules.)
>
> > I don't need two and three character names,
> > but fifteen is excessive. That's not a big problem, and I could live
with
> > it anyway.
>
> Ada doesn't force long names on you. The longest reserved word is what,
> "procedure"? (I don't have all 60-odd at my fingertips, so that's
> probably NOT the longest one.)
>
> > Looking around, it seems that several of the problems I'd had with the
> > language are non-existent at this point.
> >
> > > > Perhaps we could come up with a list of constructs which most often
> > > > contribute to code malfunction?
> >
> > > See the C reference manual? Partly kidding. I'll let
> > > Christof supply the
> > > heavy ammunition here. :-)
> >
> > Oh, they're all in there. :) See my previous list.
> >
> > > Have you read the Ada Rationale? Interesting to follow some of the
> > > reasoning that went into the language.
> >
> > Nope, do you have a link?
>
> http://www.adapower.com/
> http://www.adapower.com/rationale/index.html
>
> > > Ada does this, for example unchecked_deallocation and
> > > uncheck_conversion.
> > > When a module uses these, you have a red flag to be careful around
it.
> >
> > It seems that in theory Ada is very similar to Modula-3, which
Christoff and
> > I have both mentioned. It would be interesting to see a comparison.
>
> I haven't had time to study Modula-3, but my impression is that there was
> some borrowing of ideas.
>
> --
> Robert Deininger
> rdein...@mindspring.com
Additional questions to the Ada expert:
- Has Ada a GC?
David J. Dachtera
If you've ever seen MUMPS, how can you ask that?
I'd say it combines the worst of C, assembler and APL.
--
David J. Dachtera
dba DJE Systems
http://www.djesys.com/
Unofficial Affordable OpenVMS Home Page and Message Board:
http://www.djesys.com/vms/soho/
This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings
is to be expected.
Feel free to exercise your rights of free speech and expression.
However, attacks against individual posters, or groups of posters, are
strongly discouraged.
Robert Deininger
> Robert Deininger wrote:
> > If long multi-part procedure names become a pain, you can shorten them
> > with some renaming declarations.
>
> The trend in high quality programming is towards full
> declaration, long names etc., and strongly against renaming or
> aliasing because this makes the same objects available under
> different names which is overall not desirable.
Renaming a subprogram in Ada isn't what I would call "aliasing", as
aliasing is usually meant in C or Fortran. Renaming gives what appears to
be a new subprogram in the particular context. You can change the name,
paramater defaults, etc. The fact that the new subprogram is actually
implemented using an existing one is not really relevant. Ada won't let
you mix them up.
If the subprogram has side effects, then there are many opportunities for
obfuscation if a module uses both the old and new names. But this is
really more like the evil of mis-used global data: two routines sharing
something. The routine just happen to have the same underlying
implementation, but that's not the source of the evil.
And as Chris pointed out, full names in a large Ada system can get VERY
long. Renaming certainly helps to clarify in some contexts.
When you're well-rested, you should jump into the USE vs. no-USE wars in
Ada some time. Another facet of "aliasing"? That debate will never end.
> Some verbosity of all well designed languages (look at Java
> which is very verbose for a C style language) is a result of the
> bad experiences with operator based languages like C/C++, Lisp,
> APL or PERL. The basic contest: how high is the percentage of
> random texts that the compiler/interpreter regards as valid
> programs?
I haven't measured, but it seems clear that random texts are very unlikely
to be valid Ada. And it isn't done with verbosity. The verbosity is to
help human readers, and is a matter of style that is widely used in Ada.
The compiler has its own ways to catch mistakes, which work just as well
in very terse programs.
> The idea of verbosity is to some extend to avoid
> stupid mistakes and make the programs easy readable.
--
Robert Deininger
rdein...@mindspring.com
Jan Vorbrueggen
> > > Challanger and Ariane V will not be the only "victims".
> > Both Challenger and the first Ariane V were a failure of systems
> > engineering. Somewhat different rules apply than on software 'engineering".
> Both were a result of sloppyness. The reason I mentioned it was
> to show that you should take into account that people not only
> make mistakes but also don't adhere to best practices or rules
> given by their employer.
Have you actually read the reports of the investigations on those two
incidents? Both blame, and recommend changes to, the processes used in
running and/or developing systems. Both are quite careful in not pointing
fingers at individuals "[not] adhere[ing] to best practices or rules given
by their employer", because that either didn't happen, or was not a major
contributor to the incident's cause.
It's a difference between a piece of work that is faulty, and pieces of work
that, individually, are not faulty but that taken together will not work as
designed, or at all. The latter is systems engineering.
Jan
Alan Greig
<j...@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote:
>Christof Brass <br...@infopuls.com> writes:
>
>> > > Challanger and Ariane V will not be the only "victims".
>> > Both Challenger and the first Ariane V were a failure of systems
>> > engineering. Somewhat different rules apply than on software 'engineering".
>> Both were a result of sloppyness. The reason I mentioned it was
>> to show that you should take into account that people not only
>> make mistakes but also don't adhere to best practices or rules
>> given by their employer.
>
>Have you actually read the reports of the investigations on those two
>incidents? Both blame, and recommend changes to, the processes used in
>running and/or developing systems. Both are quite careful in not pointing
>fingers at individuals "[not] adhere[ing] to best practices or rules given
>by their employer", because that either didn't happen, or was not a major
Eh, my recollection of the Challenger inquiry and the BBC
re-construction is that according to the rules Challenger should not
have launched. Indeed the booster manufacturers initially gave a
launch condition violation warning to NASA on the very grounds that
the O-rings would not hold. NASA management put extreme pressure on
the manufacturers to withdraw this and, after argument, a company
director over-ruled their engineering director and changed the status
to "no violations". The SRB booster designers clearly said "If you
launch it will blow up". NASA disagreed and managers over-ruled.
The tapes of the telephone conversations in which the decision was
reversed were used in the reconstruction.
>contributor to the incident's cause.
>
>It's a difference between a piece of work that is faulty, and pieces of work
>that, individually, are not faulty but that taken together will not work as
>designed, or at all. The latter is systems engineering.
>
> Jan
--
Alan
steven...@quintiles.com
Given the comments from Kerry and me yesterday, it was interesting to come
across and article in Computer Weekly dated 31-MAY-2001 in which Steve
Lane, Abbey National's director of group technology says that finding
Windows programmers with a mainframe-style approach to systems is the key
to success in his bid to building a full Windows mainframe.
To quote from the article :
>>>
Speaking at the Tif conference, Lane said that people with desktop Windows
experience tend to worry less about the knock on effects of what they do on
the system, and that he needs people with rigourous mainframe discipline.
<<<
The article ends (and thereby spoils it all) with :
>>>
Security is not an issue because the system is not web-facing and there are
few personal users - the main users are other applications, he said.
<<<
The full article is entitled "Mainframe Windows programmers sought" and is
on page 10 of Computer Weekly, dated 31-MAY-2001.
Steve.
Kerry Main commented :
>>>
Similarily, keeping an IT infrastructure up and running on a 24x7 basis and
fixing things before they impact the business and complex middleware
programming designed to be highly scalable, reliable, take advantage of the
local platforms clustering features etc requires a whole different level of
support than a simple college programmer (VB?) or admin person who has no
real experience.
<<<
"Main, Kerry" <Kerry...@compaq.com> on 06-06-2001 01:16:06 PM
Please respond to "Main, Kerry" <Kerry...@compaq.com>
To: Info...@Mvb.Saic.Com
cc:
Subject: RE: The future of VMS
Steve,
Just to expand on what you are saying about todays additional support
requirements -
Even though the cars today are more sophisticated, faster, better quality
etc., you can still easily teach a 16 year old how to drive. That is not
much different than 10 years ago.
Similarily, the kids today can use faster systems to do certain things at a
certain level.
However, the mechanic fixing integration problems with onboard
microprocessors in many common vehicles today is very much a different
person than the mechanic working on cars 10 years ago.
GPS devices being able to locate cars and shutdown engines in case of theft
. that is a totally different vehicle support requirement than tuning a
carburetor.
Similarily, keeping an IT infrastructure up and running on a 24x7 basis and
fixing things before they impact the business and complex middleware
programming designed to be highly scalable, reliable, take advantage of the
local platforms clustering features etc requires a whole different level of
support than a simple college programmer (VB?) or admin person who has no
real experience.
:-)
Kerry Main
Senior Consultant
Compaq Canada Inc.
Professional Services
Voice: 613-592-4660
Fax : 819-772-7036
Email: Kerry...@Compaq.com
-----Original Message-----
From: steven...@quintiles.com [mailto:steven...@quintiles.com]
Sent: June 6, 2001 5:37 AM
To: Info...@Mvb.Saic.Com
Subject: Re: The future of VMS
I think it's not quite that simple.....
Computers, like education, have been dumbed down in certain areas. It's
true that a person leaving high school now thinks that they can administer
systems (and are often employed for that role). The problem comes when
something goes wrong or when the department/company which they are
supporting reaches a certain critical mass. At this stage, the high school
person just can't cope unless they've had significant experience. They
probably don't have the analysis techniques in their heads to be able to
consider what the symptoms are and what the underlying problem which is
causing them might be. As a colleague and I discussed and he suggested to
me a while back - there are too many people out there who can look at the
system or the router but can't see the whole picture and think about how
all of these items fit together.
One thing that came up in another thread this week was the problem of
whether network cards can do autonegotiation on speeds and feeds. Most of
us in this group can understand what the problems might be (or at least
hazard a guess) and how this affects other systems on the network. A
windows weenie straight from school would probably not have the background
or the experience to be able to do that. Heck, there's people with
significant experience in my previous and present employment who wouldn't
have the experience and would probably go all around the houses to supply a
two second fix.
For programming, I don't think there are many places where programming is
taught other than in clicky-draggy mode using VB or similar.
Steve.
Linda Luik wrote:
>>>
It's funny how programming has degraded from an engineering task to a
basic high school student project. It's also funny how system
administrators used to be engineers (or at least people with a four year
college degrees) now there's high school graduates (little or no
college) performing these tasks. Not that that's a bad thing. That just
means that computers have become easier to use and high school educators
are catching up with the real world. The bad part is is that disciplined
use of structured programming techiniques and documentation have put in
the back seat -- or hidden away in the trunk!
<<<
JF Mezei
> Lane, Abbey National's director of group technology says that finding
> Windows programmers with a mainframe-style approach to systems is the key
> to success in his bid to building a full Windows mainframe.
What goes around comes around.
Many companies opted to dump proprietary (serious) systems because they felt
that they could not find enough qualified people, opting instead to go
mainstream with Windows crap where they could hire any teenager brought up
playing Nintendo and hence having automatic ability to use Windows.
This left experienced people like me without much work while companies were
complaining that they couldn't find enough Windows weenies and that there was
a shortage. (Little did those companies know that they would have to hire
twice as many windows weenies as serious experienced programmers).
Christopher Smith
> From: Christof Brass [mailto:br...@infopuls.com]
> Christopher Smith wrote:
[snip]
> ideas." PLs development is a circus of borrowing of ideas. But
> some people are smarter and some are more interested in
> design/quality than in market share, similarity to existing ones
> etc.. Sometimes the latter and the former are the same and you
> get really good results, i.e. really good languages. Alas, you
> need some time to adapt. It's like in the OS arena: a person
> only acquainted with Windoze or UNIX (which should never be used
> anyway because it's a collection of designless pieces of code
> fragments) has real problems to understand VMS. I just had a
> discussion with a programmer and former sys admin who admitted
> that VMS was terra incognita since they phased it our anly six
> months after joining the university at that time. This person
> has really no clue about VMS. How could we expect someone to
> like something what is completely unknown?
A perfectly valid point. On the other hand, what is it that makes people
like a language? This could be key in finding a good language that people
will use. After all -- if nobody likes it, it won't get enough use for
anyone to get used to it... and nobody will like it. :)
> > on. That's not a bad thing, of course, but the extra
> verbosity required
> > also necessitates extra typing on my part.
> If you could use an ultra modern development environment there
> might be a chance to copy something instead of re-typing it ;-)
True enough. Generally, though, you shouldn't have to repeat yourself too
often, since there are loop constructs, and sometimes inheritance to do that
for you. (...and if you want them -- loops -- unrolled, there are generally
compiler options to do it)
> About 50% of the quality of a PL is the style introduced by its
> designers and continued/maintained by its community. To write
> easy understandable SW is to a very high degree a question of
> style. Ada supports and even sometimes enforces this style.
It does do that... :) I'm not sure how I feel about "enforcement" of the
style, myself. I tend to think I have a perfetly good programming style
which may not exactly match what it wants to enforce. On the other hand,
I'm sure people with absolutely terrible styles think the same, so in the
big picture it makes some sense.
> > If you're going to write the comment anyway, the previous
> is just extra
> > work.
> But there is one important rule (like in good opera
> productions): never duplicate the program in the comment (never
> show on stage what is already clear with the music), i.e. never
> comment what is obvious from what is written - always comment
> about overall structure or what is going to happen or what is
> the idea behind. The comment should contain hints which aren't
> obvious from what is written.
Good point again. I try very hard to follow this rule, myself, though I
haven't heard it said that way. I'll have to remember it.
The real trick is figuring out what is "obvious" from the code. After a
certain point, the line between "obvious" and "that's what it's written to
do" blurs some. I find that since there are invariably some people who are
less knowledgeable than me interested in the code, it's best to comment on
something if you're not sure.
Christopher Smith
> Someone recently put out the quote about "you can write
> FORTRAN code in any
> language". (And it's true, I know this from experience...)
> Well, you can
> write crap code in any language too. The most important
> component in any
> piece of quality code is programmer discipline. Sure, you can
> use single
> character variable names in C and leave out the comments, but
> you can do
> equivalently stupid things in any language. A disciplined and
> determined
> programmer can produce sources (ie commented code) you can
> understand in
> any language I know of. If anyone has written a language you
> /can't/ put
> comments in, they should be caught and beaten liberally with
> a wet haddock,
> then locked away somewhere they can't do any more harm.
This brings to mind a guy I used to work with. His name was Sajeev. His
code was -- shall we say, strange, in several regards:
He would copy liberally from textbooks, preserving variable names, etc,
which probably should have been given completely different names which had
at least something to do with the current function. :)
He would cut and paste blocks of code from function to function (in C++!)
which would have been more properly in separate functions themselves. At
one point, I counted two pages of code repeated in five functions, verbatim!
Lastly, on the rare occasion that he was forced to make up his own variable
name, he'd name them after himself. (Very descriptive. :)
I once was writing a test application; it was a throw away to test a
library, in which I decided (as joke) to try incorporating the third point
in my test program. It was wonderful. Three typewritten pages of C++, with
every function, variable, object, etc, named Sajeev (or some strangely
capitalized variation). Had I been forced to go back and read it, even I
would have been confused. :)
To give an example, there might have been (probably wasn't) a:
SAjeeV += Sajeev.SAJeev(SAjeev);
Anyway, the moral of the story is: always name your variables
descriptively.
Christopher Smith
> From: JF Mezei [mailto:jfmezei...@videotron.ca]
> Many companies opted to dump proprietary (serious) systems
> because they felt
> that they could not find enough qualified people, opting instead to go
> mainstream with Windows crap where they could hire any
> teenager brought up
> playing Nintendo and hence having automatic ability to use Windows.
You can't dump proprietary system if you still have some windows crap. :)
(You probably know this, however, it bears repeating)
Christopher Smith
> From: Christof Brass [mailto:br...@infopuls.com]
> Christopher Smith wrote:
> > Note that this document says that lines 14 and 15 will not
> behave properly,
> > however, it doesn't specify in this case that the compiler
> should return an
> > error and refuse to accept them. There are a few things of
> this nature
> > floating around, especially in C.
> This is in deed very evil and that shouldn't of course not in
> any programming language. Sometimes there is weaker form of
> this: you can write it but it will behave differently on
> different platforms but at least equal (i.e. defined,
> deterministic) on one platform.
Right. I don't know what to say about the latter case. On one hand it
causes problems, but on the other hand different platforms are, well,
different. You can't necessarily take advantage of platform specific
features without doing things in a platform specific manner. I do think
that all attempts should be made to make things as uniform as possible,
though. A standard set of functions helps a lot, I think.
> These are a good but hard questions:
> - should we aim for portability from VMS to other platforms?
> - how do we get people to use the language(s) of choice?
> I personally think that VMS is unique and therefore any attempt
> to make portability inherent will lower the quality of the VMS
> version - at least wrt VMS integration. I'm not talking about
> (trivial) best practices like layering and modularisation. I
> think about using the unique VMS API (QIO, AST, RMS). I think
> the best what can happend to VMS is that high quality apps are
> developed or ported to VMS that take full advantage of the VMS
> unique features. The idea is to attract *users* or *customers*
> to use VMS instead to offer good programs also on other
> platforms.
See above. Yes, VMS is unique, and no, I don't believe it's possible to
take full advantage of it without doing some VMS specific things. I guess
whether we can make it portable, though, depends on the extent that we'd
choose to rely on a set of external libraries (which could then have their
functions re-done in a platform specific manner...)
It's desirable to do this, to increase acceptance of the language (and the
libraries...), but personally I wouldn't want to sacrifice the VMS specific
features.
> I'm personally sure that there is and will be only small
> percentage of programmers who are willing to concentrate on the
> real interesting programming tasks instead of mastering
> unecessary problems of PLs that aren't designed or don't meet up
> to date quality criteria. The question is therefore to find
> exactly this minority and to create a community or something
> like that which includes these people and the customer/user
> base. What interests me most in that respect: how many people
> are there of this type (including those that don't know yet)?
> And is this number high enough to achieve what we need (all
> necessary apps and enough payment)?
You could also express this as:
How many programmers would rather concentrate on large projects vs. small
single-purpose applications?
Which programmers are interested in doing something new vs.
re-implementation?
Which programmers are more likely to want to use an available library than
to re-write parts on their own?
It would make an interesting pole.
Shane....@healthnet.com
Might I add my vote for appropriate indentation?
I was once asked to add a feature to a program that had been tinkered with
by several previous generations of programmers. The original author hadn't
grasped the concept of indentation or splitting lines for readability.
Subsequent programmers had actually duplicated his style too, so it was
really hard to follow. In more than one case, someone had actually put a
multilevel indented IF in under one of his, and when I applied the
indentation to the original group it came out identical to the later one.
Halfway down the code there is a comment that looks something like this:
! **SFS 07/05/96** Third day. Still no sign of an indented IF.
! Food and water is running out and the bearers are getting
! restless. I think Carruthers is going mad...
Shane
Christopher Smith <csm...@amdocs.com> on 06/07/2001 07:28:08 AM
Please respond to Christopher Smith <csm...@amdocs.com>
To: Info...@Mvb.Saic.Com
cc:
Subject: RE: The future of VMS
SAjeeV += Sajeev.SAJeev(SAjeev);
Regards,
Mike Kier
really nice module test capabilities by default).
Of course, the only VMS version is a few releases behind :-(
It might make a good project in and of itself to bring the VMS version up to
2.1 and update the sys module with the newer features of VMS in 7.2/7.3.
There's a Python newsgroup at comp.os.python that's pretty active.
--
Mike Kier
Compaq Professional Services
Cincinnati, OH, USA
michae...@compaq.com
<Shane....@Healthnet.com> wrote in message
news:OFE8BECFB4.85EA8EE2...@foundation.com...
Christopher Smith
> From: Shane....@Healthnet.com [mailto:Shane....@Healthnet.com]
> Christopher Smith <csm...@amdocs.com> on 06/07/2001 07:28:08 AM
> To give an example, there might have been (probably wasn't) a:
>
> SAjeeV += Sajeev.SAJeev(SAjeev);
>
> Anyway, the moral of the story is: always name your variables
> descriptively.
> Might I add my vote for appropriate indentation?
[snip]
> Halfway down the code there is a comment that looks something
> like this:
>
> ! **SFS 07/05/96** Third day. Still no sign of an indented IF.
> ! Food and water is running out and the bearers are getting
> ! restless. I think Carruthers is going mad...
Ha! Yes, you can. This particular person had a problem with indentation,
too. He would indent his code, but seemed not to grasp the reasoning behind
the indentation. He ended up with inconsistent indents, which, arguably,
are worse than none at all.
I have very bad memories of wading through his code trying to find a bug
that caused a fatal error one day. To make matters worse, the error was
from a bit of code that the compiler would comment in and out at
compile-time. (It was Microshaft's visual c++, of course -- for those of
you who don't know, some components of visual c++ will add chunks of comment
to your code, and make the compiler magically uncomment them at compile
time. This particular chunk of comment should have been removed when he
removed some feature with the gui designer, and wasn't. In other words,
never use a microshaft compiler.)
Bill Gunshannon
If it's possible to avoid language wars and the usual C and Unix
bashing I am going to try an gather real info at this point in time.
It looks not only like my plans for sponsoring projects to have
students port one or possibly more opensource/freeware programs
to VMS are going to move ahead, it appears at this point that
they will be doing the porting to an Alpha running OpenVMS 7.3.
So, I now seriously ask what programs people here would like to
see ported first??
My personal preference is for program under the BSD style license
rather than the GPL but anything will be considered. The only
other serious consideration is that there must be a reasonable
expectation that the program is capable of being ported within
a single semester. (I think that pretty much eliminates something
like GNOME.)
My list starts out with:
A Bourne Shell clone
A C-shell clone (most likely tcsh)
make
What particular utilities would other people like to see put
on the list for consideration??
One of the requirements for any of these projects will be good
documentation of the porting process with an eye towards developing
a "Unix to VMS Porting Document" or at least a set of porting
guidelines.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bi...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Hoff Hoffman
I'd be happy to discuss this topic off-line, as I'm familiar with
(parts of) the DII COE work that is going into OpenVMS, and I'm
familiar with (parts of) the OpenVMS Freeware...
:My list starts out with:
: A Bourne Shell clone
: A C-shell clone (most likely tcsh)
: make
Various of these are readily available, and extensive work is going
into these areas here in OpenVMS. I know about bash and make, and
I'd expect to find a port of csh around somewhere.
Shells, by the way, can be a lot of work to port, as folks expect
the tools that are behind the shells will be available, too...
:One of the requirements for any of these projects will be good
:documentation of the porting process with an eye towards developing
:a "Unix to VMS Porting Document" or at least a set of porting
:guidelines.
There is a UNIX OpenVMS Compatibility book available. AFAIK, it is
either marketing collateral -- perversely, I acquired my copy at a
customer event -- or is part of the Tru64 UNIX documentation set.
One tool I haven't seen: an ODS-5 capable tar.
Another tool that could use an updated port: imake.
A tool I haven't seen ported: RPM.
Others: any of various tools that were not carried forward from Freeware
V4.0 to Freeware V5.0 -- these tools did not see updates, and I did not
have room to carry these through given the (large) volume of new Freeware
submissions and updates to existing submissions that I had received.
--------------------- #include <rtfaq.h> -----------------------------
For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com
--------------------------- pure personal opinion ---------------------------
Hoff (Stephen) Hoffman OpenVMS Engineering hoffman#xdelta.zko.dec.com
Larry Kilgallen
> In article <9fok9f$ufr$1...@info.cs.uofs.edu>, bi...@triangle.cs.uofs.edu (Bill Gunshannon) writes:
> :One of the requirements for any of these projects will be good
> :documentation of the porting process with an eye towards developing
> :a "Unix to VMS Porting Document" or at least a set of porting
> :guidelines.
>
> There is a UNIX OpenVMS Compatibility book available. AFAIK, it is
> either marketing collateral -- perversely, I acquired my copy at a
> customer event -- or is part of the Tru64 UNIX documentation set.
>
> One tool I haven't seen: an ODS-5 capable tar.
I needed one of those last month, so I took the VMSTAR source from the
Freeware discs and modified it in a couple of hours. I doubt that you
can keep students engaged for a full semester on something that only
takes me a couple of hours, since VMSTAR is written in C (a language
I avoid as much as possible).
Christopher Smith
> So, I now seriously ask what programs people here would like to
> see ported first??
[snip]
> What particular utilities would other people like to see put
> on the list for consideration??
> One of the requirements for any of these projects will be good
> documentation of the porting process with an eye towards developing
> a "Unix to VMS Porting Document" or at least a set of porting
> guidelines.
What about busybox?
From the web-site: http://busybox.lineo.com/
BusyBox combines tiny versions of many common UNIX utilities into a single
small executable. It provides minimalist replacements for most of the
utilities you usually find in fileutils, shellutils, etc. BusyBox provides a
fairly complete POSIX environment for any small or embedded system.
It's licensed under the General Public License -- sorry! :)
Anyway, this looks like it might be an interesting way to provide POSIX
functionality on a VMS machine. It will emulate several unix commands
either with symbolic links (probably better not to do it this way on VMS...)
or by saying busybox <command> <args> One might be able to work it as a
foreign command "UNIX" or something. (which I think would fit the VMS way of
doing things as well as possible) One could then say, for instance, UNIX
ZCAT ...
Of course, some of the commands would be more difficult to do than others,
and some may be better left out.
Here is the list of commands, also from the web-site:
Currently defined functions include:
ar, basename, busybox, cat, chgrp, chmod, chown, chroot, chvt, clear, cmp,
cp, cut, date, dc, dd, deallocvt, df, dirname, dmesg, dos2unix, dpkg,
dpkg-deb, du, dumpkmap, dutmp, echo, expr, false, fbset, fdflush, find,
free, freeramdisk, fsck.minix, getopt, grep, gunzip, gzip, halt, head,
hostid, hostname, id, ifconfig, init, insmod, kill, killall, klogd, length,
ln, loadacm, loadfont, loadkmap, logger, logname, ls, lsmod, makedevs,
md5sum, mkdir, mkfifo, mkfs.minix, mknod, mkswap, mktemp, more, mount, mt,
mv, nc, nslookup, ping, pivot_root, poweroff, printf, ps, pwd, rdate,
readlink, reboot, renice, reset, rm, rmdir, rmmod, route, rpmunpack, sed,
setkeycodes, sh, sleep, sort, stty, swapoff, swapon, sync, syslogd, tail,
tar, tee, telnet, test, tftp, touch, tr, true, tty, umount, uname, uniq,
unix2dos, update, uptime, usleep, uudecode, uuencode, watchdog, wc, wget,
which, whoami, xargs, yes, zcat, [
For the curious the finished program is about 332k on a mips r4000 (only
system I have it working on)
Hoff Hoffman
:I needed one of those last month, so I took the VMSTAR source from the
:Freeware discs and modified it in a couple of hours. I doubt that you
:can keep students engaged for a full semester on something that only
:takes me a couple of hours, since VMSTAR is written in C (a language
:I avoid as much as possible).
vmstar is apparently either an old port of tar or is a rather limited
port -- it is missing a number of tar options. The baseline port to
ODS-5 definitely isn't that difficult (assuming willingness to work
with the existing C code :-), but a port of a more current (full)
version of tar is likely rather more involved. (This was the topic
of a recent lunch-time discussion among various local engineers...)
Another potential target for a port: XRN -- the existing Motif version
of XRN (MXRN) is based on a rather old version of XRN.
---------------------------- #include <rtfaq.h> -----------------------------
John E. Malmberg
>
> If it's possible to avoid language wars and the usual C and Unix
> bashing I am going to try an gather real info at this point in time.
>
> It looks not only like my plans for sponsoring projects to have
> students port one or possibly more opensource/freeware programs
> to VMS are going to move ahead, it appears at this point that
> they will be doing the porting to an Alpha running OpenVMS 7.3.
>
> So, I now seriously ask what programs people here would like to
> see ported first??
No Priority:
GNU INFO
XMAN (not inside of POSIX)
Consider writing a version of the GNU getopts() routine that can use
the CLI$ routines to get it's data.
Another vote for RPM (V4.x).
I earlier posted a wishlist for GZIP
- Support for ODS-5 filenames.
- Support for .TGZ, TAR_GZ, and ^.tar.gz extensions.
- OpenVMS wildcard support like in the versions at
ftp://ftp.qsl.net/pub/wb8tyw/gzip
- Encode/decode the OpenVMS file attributes in the saved file
name. This would allow GZIP to handle backup save sets.
- Fix to preallocate the estimated uncompressed file size on
create.
The BZIP program could probaly use the same things.
And to repeat my earlier suggestion, set up benchmarking for an
existing port of something and see where it can be optimized for both
the OpenVMS and even the UNIX version.
This would allow the students to get real experience on using the
profiling and source code analysis tools.
-John
Personal Opinion Only.
wb8...@qsl.network
Robert Deininger
<3B55D7F383B0D31197D9...@cmiexch1.cmi.itds.com>,
Christopher Smith <csm...@amdocs.com> wrote:
>
> Ha! Yes, you can. This particular person had a problem with indentation,
> too. He would indent his code, but seemed not to grasp the reasoning behind
> the indentation. He ended up with inconsistent indents, which, arguably,
> are worse than none at all.
I know a Fortran programmer who tends to indent all the assignment
statements in a given routine so that all the "=" signs line up. Sort of
like this:
long_name = a +2b
x = long_name * 46+ x
if (x .gt. 99) then
z =x/100
endif
It's too painful to try to type a long example. Image the above with
non-assignment statements interspersed, going on for a few pages. All the
"=" line up, and other parts of the statements are apparently randomly
positioned.
I can't really describe what this does to my brain.
--
Robert Deininger
rdein...@mindspring.com
Christopher Smith
> From: hof...@xdelta.zko.dec.nospam
> A tool I haven't seen ported: RPM.
>
> Others: any of various tools that were not carried forward
> from Freeware
> V4.0 to Freeware V5.0 -- these tools did not see updates,
> and I did not
> have room to carry these through given the (large) volume
> of new Freeware
> submissions and updates to existing submissions that I had received.
If you just want an RPM extractor, see my previous suggestion (BusyBox),
which includes, among other things, RPM and Debian package extractors.
Christof Brass
While my information of Challanger is from the press I have
second hand personal information about the other incident. A
former working colleague worked at Logica the company which
developed the Arian 4 SW and handed them over to the company
which introduced the problem.
Anyway we are far OT wrt VMS and the only connection of the two
topics is the basic line that a society shouldn't depend on the
correct behaviour of one individual or a company or a system.
The society should avoid risks with single point of failures.
Maybe it should use something like VMS clusters ;-)
Christof Brass
>
> Christof Brass wrote in message <3B1EB1D4...@infopuls.com>...
>
> >Sorry to say this again: I looked into MUMPS programs and found
> >them awful - combining the worst aspects of BASIC, C and
> >assembly language.
>
> I didn't think that you had actually said that before in a literate form.
> I would be interested in your reasoning behind these statements.
You're right I only wrote I regard MUMPS more a sickness than a
PL.
In 1995 I had to advice a hospital in buying new administration
SW which had to run on their VMS cluster. There was a new
developed system entirely written in MUMPS and we attended a
presentation which gave us the impression of only midrange
quality - especially the UI seems to be very restriced.
The hospital already used a MUMPS package which collected the
medical results from some laboratories. This also ran on VMS but
the SysAdmin showed me that it was a single huge process instead
of the other VMS apps which had several processes which made
resource management easier. The MUMPS SW was like an elephant
and unfortunately not as stable as the other programs.
To get an impression I looked at the sources of this laborartory
SW and was really frightened. The syntax is awful and it seemed
that there was a substantial lack of modularisation features and
abstraction. I then asked the other company to send us a few
examples of their sources because I hated the hospital buying
similar disorganised SW and at that time I wasen't sure if this
was a basic MUMPS problem or an individual SW development
problem. Alas the other company didn't dare to send us one piece
of properly developed SW.
Would you like to give a short example why you think that MUMPS
is a superior system?
Christof Brass
>
> In article <3B1EB3CF...@infopuls.com>, Christof Brass <br...@infopuls.com> writes:
>
> > - Has Ada a GC?
>
> and neither requires it nor prohibits it. The marketplace current
> state is that compiler implementers are not providing garbage collection
> and say their customers are not demanding it. The obvious exception is
> Ada compilers that target a Java bytecode machine.
>
> > - Has Ada95 a proper type test for dynamically typed objects?
>
Thanks!
I personally regard GC as a major advantage in oo environments.
Christof Brass
>
> In article <3B1EB3CF...@infopuls.com>, Christof Brass
> <br...@infopuls.com> wrote:
>
> > Robert Deininger wrote:
>
> > > If long multi-part procedure names become a pain, you can shorten them
> > > with some renaming declarations.
> >
> > The trend in high quality programming is towards full
> > declaration, long names etc., and strongly against renaming or
> > aliasing because this makes the same objects available under
> > different names which is overall not desirable.
>
> Renaming a subprogram in Ada isn't what I would call "aliasing", as
> aliasing is usually meant in C or Fortran. Renaming gives what appears to
> be a new subprogram in the particular context. You can change the name,
> paramater defaults, etc. The fact that the new subprogram is actually
> implemented using an existing one is not really relevant. Ada won't let
> you mix them up.
>
> If the subprogram has side effects, then there are many opportunities for
> obfuscation if a module uses both the old and new names. But this is
> really more like the evil of mis-used global data: two routines sharing
> something. The routine just happen to have the same underlying
> implementation, but that's not the source of the evil.
I personally like to exactly know what I'm using.
> And as Chris pointed out, full names in a large Ada system can get VERY
> long. Renaming certainly helps to clarify in some contexts.
If this is done in a local scope it might be okay. I personally
don't mind long names.
> When you're well-rested, you should jump into the USE vs. no-USE wars in
> Ada some time. Another facet of "aliasing"? That debate will never end.
:-)
> > Some verbosity of all well designed languages (look at Java
> > which is very verbose for a C style language) is a result of the
> > bad experiences with operator based languages like C/C++, Lisp,
> > APL or PERL. The basic contest: how high is the percentage of
> > random texts that the compiler/interpreter regards as valid
> > programs?
>
> I haven't measured, but it seems clear that random texts are very unlikely
> to be valid Ada. And it isn't done with verbosity. The verbosity is to
> help human readers, and is a matter of style that is widely used in Ada.
> The compiler has its own ways to catch mistakes, which work just as well
> in very terse programs.
Yes, of course, proper syntax and strong typing is the major
foundation for that matter.
Christof Brass
[SNIP]
I'm not sure if we understand each other in the last paragraph.
I agree completely that the alternative questions are also very
interesting but I don't see a clear relationship to the "type of
programmer" and "type of customer/manager" topic that I stated.
A small example: memory management in C/C++ is done by the
programmer and very often leads to memory problems like
accessing invalid memory regions or memory leaks (Slowaris is
well known for having substantial memory leaks in its C
libraries). But most programmers like to write these little
memory management statements like alloc, new, free etc.. There
are a few programmers who think that what could be done
automatically and in high quality shouldn't be a burden of the
programmer.
There a few managers of companies that prefer to wait until a SW
product is really usable instead of getting it as early as
possible and then having trouble with the bugs. These companies
are the target for VMS marketing.
Christof Brass
>
> Might I add my vote for appropriate indentation?
>
> I was once asked to add a feature to a program that had been tinkered with
> by several previous generations of programmers. The original author hadn't
> grasped the concept of indentation or splitting lines for readability.
> Subsequent programmers had actually duplicated his style too, so it was
> really hard to follow. In more than one case, someone had actually put a
> multilevel indented IF in under one of his, and when I applied the
> indentation to the original group it came out identical to the later one.
>
> Halfway down the code there is a comment that looks something like this:
>
> ! **SFS 07/05/96** Third day. Still no sign of an indented IF.
> ! Food and water is running out and the bearers are getting
> ! restless. I think Carruthers is going mad...
>
> Shane
>
May I vote for a source formatter which allows to look at the
source in your own style. Logitech once offered this for
Modula-2. You could configure it manually or you could give it
an example of your formatting style and it would learn from
that.
Christof Brass
Yellow card ;-))
Bill Gunshannon asked us to stop bashing UNIX and C.
BTW, did I mention that UNIX should be avoided because it's a
collection of code without any design, structure or system?
Christof Brass
>
> OK, as the person who started this particular thread, I'm back.
>
> If it's possible to avoid language wars and the usual C and Unix
> bashing I am going to try an gather real info at this point in time.
Hardly ...
What I would like to see is a tool which automatically converts
the command line interface of foreign programs to a CLD/VMS
style interface.