Conference turris::languages

>   1.6  Programmer Productivity
>
>        Programmer productivity in C is fairly high  -  certainly  higher
>   than in BLISS.  

Can this be proven?  I'd be interested in seeing some figures to backup this 
claim. 

>                   Programmers are productive since there is a direct way
>   in the language to code the desired algorithm.  

Uhm, yes - there are also indirect ways in C to code algorithms ...

Jack

Pardon my weak understanding of the subject, but what is a "BOSE Standard
Language"? When you answer that, I'll have some more replies ...

BOSE -  Business and OFFICE systems engineering? (group which includes 
WPS(all versions and DECpage etc) is
is proposing KOALA as the standard language to write all their 
products in. The BOSE products run on VAxes, IBM pcs, etc.

This looks like a counter-proposal to using KOALA as the standard language.

IBM pc's??? You sure? I didn't know Digital ever was, nor planned to be in
the business of developing software that ran on other vendors hardware!

If we truly believe the "One company, one xxx, one yyy" I would venture to
state that Ada will be one of the first (if not the first) language to be
ported to any new hardware/software machines/operating systems DEC
developes. And, I feel Ada is a superior language to write applications
(especially large ones) in. I'm a little biased, but in retropect 5
years from now, I would rather look back and think "Gee, I'm glad we
wrote all these new applications in a modern, structured, typed, industry 
standard language (Ada) rather than in 'C' ..." 

And if you say that Ada doesnt generate code for PDP-11's, I'll say thats
not in line with the "One xxx" message anyway (at least for new product
developement).

I'm sure in this notes file, and in the Ada notes file there are many places
pointing out the virtues of Ada, and how more and more groups within DEC
are or plan to write their new products in Ada. And I'm sure more will jump
on the bandwagon as time goes on ...

If I had to choose between Ada and C for writing systems programs, I
suspect I would choose C.  As was remarked, among the advantages of C
are that it is available for many different systems, it is pretty much a
de-facto standard, and most implementations provide production quality
code.

We are already in the business of writing software to run on other
vendors' hardware, particularly the IBM PC.  Consider, for example,
DECnet-DOS.  There is likely to be much more of this occurring in the
future, rather than less.  This is to our advantage.  There is plenty of
money to be made from software (look at, e.g. Digital Research, or at
Lotus Development, or even at Borland, if you don't believe there is
money in the software business).  In the future, it will be beneficial
to us to be able to provide the same business solutions on VMS and on
Unix (our own Ultrix or someone else's box), and using truly portable
languages is a prerequisite to attaining that goal.

BLISS is probably not in the running, for the simple reason that there
are not BLISS compilers for most computer systems.

At the present time, the same argument also applies to Ada.  There are
VERY FEW production quality Ada implementations, although this will
probably change over time.  See note 108.* in the Ada notesfile on this 
cluster for further comments on Ada, however.

The transportability problems of BLISS and Ada apply even more strongly 
to Koala, unless, of course, the Koala implementors believe they can 
port it easily to other systems.

Tom

Re .5:

Most C compilers have nothing but a peephole optimizer, and rely on
the programmer to write code goes through the compiler like a watermelon
seed.  (Make as much of that analogy as you like).

Exceptions I know of are Vax-11 C and whatever Tartan Labs is working on.
And whatever Stanford is up to.

(I assume Mike Powell hasn't been sneaking around writing a C compiler
that "does all good things and no bad things, taking no time and no space"
during some weekend, like he did with Modula-2).

Anyone who wants to disabuse me of this notion should feel free to post the
name of their favorite optimizing C compiler (hopefully accompanied with a
representative list of optimizations).  I'd rather know sooner than later.
Still, there are probably 10 optimizing Fortran compilers for every optimizing
C compiler.

Also, BOSE isn't the only organization picking an implementation langauge,
and I have heard rumors that a lot of people are going to be coding in
something that is neither Ada, C, Bliss, Modula-2 nor Koala.  Comments?
				/AHM/THX

I think that languages must be selected on their applicability to a given
system.  I will not advocate the use of a single language for all applications
(although some languages are more 'universal' than others).  I will certainly
not advocate the use of C as a standard language.  Aside from heavy systems
development, I do not see many reasons to use C for other applications.

The language lacks many modern concepts (do not forget, it was started in late
60s).  It began as a super-assembler and still is one.  The procedure nesting
is primitive, and variable scoping is obsolete.  Only APL provides more ways
to bend a program in a pretzel than C.  Parameter passing allows perverse
degrees of freedom.  Strong typing is unheard of.  Portability is vastly
exaggerated.  C does not have a standard - the language is defined 'by example'
in the well known manual.  C is not so fast -- Bell Labs often use Fortran for
number crunching applications, and even boots VMS (yes!) to replace sluggish
C-based UNIX on up to 30% of their VAXen.  C compilers provide very little
protection -- most Pascal/Ada-style compile-time detectable errors have
to wait until run-time 'core dump' to be found. . . . 

C anyone?  Not me, I've had enough!

-Alex, ex Member of Technical Staff, AT&T Bell Laboratories

re: .7

While I agree that C is not a 'universal' language, many of your criticisms
are not completely true.  C is language with certain attributes and certain
deficiencies, just like any other language.  There is a standardization
effort, ANSI X3J11, which is getting close to having a proposed standard.
There is definitely a dichotomy on the committee of people who want C to
remain a symbolic assembly language and people who want C to be a useful
medium-to-high level language.  In my opinion, the majority is the latter
group.  As for speed, VAX C is a highly optimizing compiler which generates
code which is typically as good as VAX Pascal or VAX FORTRAN.  It obviously
depends upon the application, but on the VAX speed is not a reason to choose
one language over another.  This is not true universally - VAX C certainly
runs rings around most other vendor's C compilers.  As for strong typing
and static checks in the compiler, true, C does not have much.  Again, VAX
C has much more than most.  However, that does open a market for productivity
tools to support an 'environment' consisting of more than just a compiler
and linker -- re: LSE for a start.  C has it's place.  It is reasonable and
valid language for many languages.  True, it is not an Ada, but would you
want it to be?


		- a totally unbiased language afficionado
		  and former VAX C project member
		                                 
		- Dave

re: .8

Yes, C has its place and your reply makes a lot of common sense. But having
spent much time battling the "C is panacea" fashion, I prefer to over-critisize.
I do agree that VAX/C is a very good and fast implementation of C. 
C also has a potential for being a very portable language, however most
systems destroy that advantage through non-disciplined usage of OS-dependent
features (shell/DCL/system calls).  And I do not have to tell you that C
rivals APL (in the negative sense) when found in the hands of amateurs.

To sum it up: only a competent project manager/leader should be able
to select C as the implementation language on a project by project
basis, but we are too far from this ideal.  C is fine for what it was
intended, but unfortunately C is often selected for wrong reasons.

Alex

Background:

I learned C once, but don't program in C.  I also consider myself a pretty
good assemby-language hacker (high-performance, etc), and used to be impressed
with the code generated by Bliss, but have become less so (mebbe it's me,
but mebbe it's Bliss).  Anyway, ....

Remark:

I compiled a program doing some interesting character manipulation in VAX C
(an equivalent of which I'd also coded in Macro), and was AWED by the code
generated by VAX C.

Conclusion:

Someone else might conclude that VAX C is a good language, but I don't
like C.  The moral is that -

	 It pays to invest in a good re-usable code generator.

But for the sake of "ONE COMPANY", etc., we should have one standard
implementation language.  I don't much care which one it is (we will
improve it as necessary), but it's silly for each group in the
company to have its own standard language.

". . .  the determined Real Programmer can write FORTRAN programs in any
language" - from Real Programmers Don't Use Pascal.
				/AHM

It doesn't appear as though Bill Keating's drive to establish a new 
corporate preferred development language is going anywhere (see #54.7).
What happened?

Jack

Following along with the "ONE COMPANY", why not use "ONE PHILOSOPHY",
i.e. that of VMS and the Common Language Environment.  We keep preaching
the CLE to our customers and telling them to pick the language that's most
suited for their application, even to write different modules of the same
application in the "right" language.  Why can't we do this within the company.

Isn't VMS itself a combination of BLISS, MACRO, a little of FORTRAN, Pascal,
and DCL?

RE: .13:

Did you possibly mean note number 42.7?  I looked and note number 54 only
has 6 responses.  Thinking that you might have turned the numbers around,
I looked for a note number 45.7, but there is no note number 45.

RE: .14

If you're interested, VMS has substantial quantities of Bliss, Macro, SDL, MDL,
message source, DCL and CLD files.  In addition, there are a few .FDL files.

There are relatively small amounts of C (CRTL), Pascal (EDF, Encrypt, UV1ROM),
FORTRAN (ERF and MSGFIL) and PL/I (CLIUTL, Monitor, PLIRTL and REG.)
There weren't any CMS elements for Ada (yet), Cobol or Basic.

Kent

RE: .15

Ooops, yes, I meant 42.7. Thanks for pointing that out.

Jack