Programming Languages
- Glories and Blunders
Brian Wichmann
Notes
• Some subjective judgement!
• Only a limited number of languages
considered
• Reliability, integrity, readability
Issues
• Surprises
• Underlying semantics
• Programming convenience
• Accuracy
• Performance?
Critical diagram
Executes
Compiles
Algol 60 - Glories
• BNF, semantics based upon syntax
• Basic language
• Call-by-name
Algol 60 - Blunders
• Labels and switches
• No I/O
• Closed language
Meta-blunder
• Any language which is less precise than
Algol 60
Pascal - Glories
• Enumerated types and ranges
• Richness of statically-sized data
structures
Pascal - blunders
• No dynamically-sized arrays (language
Turing showed how to do this)
• Initial definition failed the Algol 60 test
• (No garbage collection)
Meta-blunder
• Since 1970, any language that did not
have enumerated types and ranges
The blunder of Booleans
• Data type, but not a single bit
• PL516 and conditions
• Conditional procedures
C - Glories
• Universal machine-level language
• Good for OS kernel and small
embedded applications
C - Blunders
• Used for non-trivial applications
• Complex semantics
• Too much compiles
Ada - Glories
• OK for large systems
• Compiled language for which programs
rarely crash
• High and low-level programming
Ada - Blunders?
• Parnas - language is too big
• Remove fixed point types??
C++ - Glories
• Based on C
• OO and an ordinary language
• Can be used for large systems
C++ - blunders
• Based on C
• Insecure
• Evolved from C
Java - Glories
• Compile once, run anywhere
• High capable libraries available
Java - blunders
• No enumerated types/ranges, initially
• Numerics can’t be portable and efficient
• Libraries can be overwhelming
Python - Glories
• Complex data structures easy to set up
• Easy to write small programs
• Good string handling
Python - blunders
• Reference is implicit
• Boolean an afterthought
PostScript/PDF - Glories
• Paint operations
PostScript/PDF blunders
• Character encoding
• Font types
• Compatibility
• (low level) MetaPost
Static analysis?
• Why are languages not designed with
static analysis in mind?
• What about literate programming?
• Documentation aids
Conclusion - 1
It is astonishing to me that 47 years after strong typing was
invented and recognised, and after the Turing Award has been
presented to such proponents as Dijkstra, Hoare, Wirth, Dahl,
Nygaard and Naur, professionals not using this technology
caused 85% of significant errors in a specific field of computer
science. I think it is disgraceful.
Peter B. Ladkin, Professor of Computer Networks and Distributed
Systems, Faculty of Technology, University of Bielefeld. Germany
Conclusion - 2
• Programming language success has
little to do with technical merit
• Those who forget history are doomed to
repeat it. (George Santayana, 18631952)
Reasons for using C
The answers were almost always C and the reasons given included the
following:
1.
"We use UNIX and that means you have to write in C"
2.
"Our programmers only know C"
3.
"Its good for graphics"
4.
"We can get a free compiler"
5.
"C programmers are easy to recruit"
6.
"Its efficient"
7. My favourite: "Our programmers really like it because the
software they write in it is so bad that they will be more or less
permanently employed in maintaining it."
8. Its easy to get things going without having to think too much
about them.
9.
We can't get a compiler for any other language
10. The customer insisted on it.
From Kevin Dyer
Language success
I have a somewhat different viewpoint of why C and C++ are so widespread. The
reason they are widespread is that they were the best alternatives available at
critical times when the market was ready to switch programming languages.
In the late 70s and early 80s I was working for a small computer company, and
then for myself as a consultant. I witnessed many small software companies
struggling to find a suitable programming language in which to write
applications for microcomputers. Most of them started out using assembler or
Basic, which initially were the only languages well supported on microcomputers.
Then Pascal appeared on the scene, and may of them switched to Pascal. The
trouble was, core Pascal was not powerful enough to write commercial
applications, for example its support for string operations was very poor. So
you had to use Pascal extensions; but there was no agreement on the extensions.
When C became widely available on microcomputers, people recognised that at last
there was a language that was expressive enough for their purpose, even if it
was a bit low-level in places. So the Pascal crowd switched to C. Ada 83 was
never a contender as it arrived too late.
In the mid 90s, much the same happened again. It was recognised that
object-oriented technology offered increased re-use and productivity in the
development of commercial applications. Ada 95 was a poor attempt at
retrofitting OO constructs into a non-OO language, and in any case came too late
(again). So the battle was between C++ and Objective C.
Much of the commercial software development market now wants to move away from
C/C++ and is looking at or using other languages. Ada 2005 has come too late to
mend the OO failings of Ada 95, besides the market wants a true OO language now.
The battle is between C# and Java. Of these, C# is better from a programmer's
perspective (Microsoft had the benefit of seeing the weaknesses in Java), but
Java is more portable. So I expect both to be in widespread use for some time.
This doesn't really help the critical systems market, which by and large has
good reason to avoid languages which require garbage collection.
Crocker
David