Upload
king
View
44
Download
1
Embed Size (px)
DESCRIPTION
Why is Java so popular?. Floundered until adapted for internet. 90% of personal computers have Java Run on client – so load to server is drastically reduced Portable – cross platform Objected oriented – leads to extensibility Built in security Removes undesirable features of C++ Hype. - PowerPoint PPT Presentation
Citation preview
1
Why is Java so popular?Floundered until adapted for internet.
90% of personal computers have JavaRun on client – so load to server is
drastically reducedPortable – cross platformObjected oriented – leads to
extensibilityBuilt in securityRemoves undesirable features of C++Hype
Chapter 3 Louden
2
Microsoft's C# is Java without the reliability, productivity or security - They had this problem in their design rules that they had to support C and C++, which means you have to have a memory model where you can access everything at all times. It's the existence of those loopholes that is the source of security, reliability and productivity problems for developers.
(Gosling, the inventor of Java, is also a creator of Netbeans)
Chapter 3 Louden
3
Why is C++ popular Criticisms (too high or too low):
– writing efficient code in C is easier than C++ because the level of information hiding hides inefficiencies
– its powerful features and complexities are often the source of many errors.
– C++ suffers under the burden of backwards compatibility Success
– dominant language for game dev– C++ adds layers of abstraction to C– multi-paradigm (generic, imperative, OO)– large audience of C programmers. Early C++ compilers
just emitted C code.– efficiency– willingness and readiness of compiler vendors to add
another language to their packagesChapter 3 Louden
4Chapter 3 Louden
Chapter 3 - Language Design Principles
Programming Languages:Principles and Practice, 2nd Ed.Kenneth C. Louden
5
Thought questionWhat characteristics should be
present in your “perfect language”?
Chapter 3 Louden
6Chapter 3 Louden
The language design problemLanguage design is difficult, and
success is hard to predict:– Pascal a success, Modula-2 (successor
to Pascal – fixed syntactic ambiguity and added modules) a failure
– Algol60 a success, Algol68 a failure– FORTRAN a success, PL/I a failure
Conflicting advice
7Chapter 3 Louden
Efficiency The “first” goal (FORTRAN): execution efficiency. Still an important goal in some settings (C++, C). Many other criteria can be interpreted from the point of
view of efficiency:– programming efficiency: writability or expressiveness
(ability to express complex processes and structures)– reliability (software doesn’t crash, is secure).– maintenance efficiency: readability.(saw this as a goal for first time in Cobol)
8
Reliability and Programming Language?Hurts
bad syntax source of bugs (if a=b when mean if a==b) complex syntax distracts the
programmer (errors are more likely)
Name hiding - confusion machine dependencies (length
of Integer could cause different results when ported)
Helps rigorous type checking eliminate undefined
variables (always init) runtime checks (array
bounds, types) simple syntax less implicit computation
(force explicit casts) compiler helps (check for
declared but not used) correct return value types
Chapter 3 Louden
9Chapter 3 Louden
Other kinds of efficiencyefficiency of execution (optimizable)efficiency of translation. Are there
features which are extremely difficult to check at compile time (or even run time)? e.g. Algol68 – solved dangling else problem (case/esac if/fi, do/od closing)
Implementability (cost of writing translator)
10Chapter 3 Louden
Features that aid efficiency of execution
Static data types allow efficient allocation and access.
Manual memory management avoids overhead of “garbage collection”.
Simple semantics allow for simple structure of running programs (class variables, run time inheritance type checking - expensive).
11Chapter 3 Louden
Visit with you neighbor: can you see any conflicts with efficiency?
Writability, expressiveness: Software reliability, efficiency: Expressiveness, writability, readability:
12Chapter 3 Louden
Some goals conflict with efficiency Writability, expressiveness:
– idea: no static data types (variables can hold anything, no need for type declarations). [harder to maintain]
Reliability, efficiency: – idea: automatic memory management (no need
for pointers). [runs slower] Expressiveness, writability, readability:
– idea: more complex semantics, allowing greater abstraction. [harder to translate]
13Chapter 3 Louden
Internal consistency of a language design: Regularity Regularity is a measure of how well a language
integrates its features, so that there are no unusual restrictions, interactions, or behavior. Easy to remember.
Regularity issues can often be placed in subcategories:– Generality: combining closely related constructs into
a single more general one. Ex. Ruby collections/ranges/ arrays/files all have each
– Orthogonality (independence): are there strange interactions?
– Uniformity: Do similar things look the same, and do different things look different?
14Chapter 3 Louden
Generality deficienciesIn pascal, procedures can be passed
as parameters, but no procedure variable to store them (not a true object).
Pascal has no variable length arrays –length is defined as part of definition (even when parameter). This is a much bigger deal than you would think.
15Chapter 3 Louden
Orthogonality: independence Not context sensitive Seems similar to “generality” but more of
an “odd” decision rather than a limitation. For example, if I buy a top:
– sweater, sweatshirt, shirt– short sleeve, long sleeve, or sleeveless– small, medium, or large– red, green, or blue
16
Orthogonal – independent decisions
Chapter 3 Louden
Sweater Sweatshirt Shirt
Size S,M,L,XL S,M,L,XL S,M,L,XL
Sleeve Length Short/Long Short/Long Short/Long
Color RGB RGB RGB
17
Non-Orthogonal – dependent decisions (if sweater, no choice on sleeve length)
Chapter 3 Louden
Sweater Sweatshirt Shirt
Size S,M,L,XL M,L,XL (no S) S,M,L,XL,XXL
Sleeve Length Long (no Short) Long (no Short)Sleeveless/Short/Long
Color RGB Yellow, Purple RGB RGB
18Chapter 3 Louden
Orthogonalitya relatively small set of primitive constructs can be combined
in a relatively small number of ways. Every possible combination is legal.
Is orthogonal if it can be used without consideration as to how its use will affect something else (no side effects)
Language features are orthogonal when they can be understood in isolation and freely combined with no surprises. Orthogonality thus allows a simple definition to cover lots of possibilities.
Orthogonality makes it easier to understand what happens when things combine.
Is closely related to simplicity - the more orthogonal, the fewer rules to remember.
Can make implementation more complicated as implement things that might not really need.
19
Orthogonal: Alternative definition Cleanly integrated features: All features must be cleanly and elegantly
integrated into the language.
Composability of features: It must be possible to use features in combination to achieve solutions that would otherwise have required extra separate features. Ex. Arrays of records
Avoid special purpose features: There should be as few spurious and "special purpose" features as possible.
Performance independence: A feature should be such that its implementation does not impose significant overheads on programs that do not require it. Ex. array element deletion
Understatement independence: A user need only know about the subset of the language explicitly used to write the program. Ex. reserve word
Understatement is a form of speech which contains an expression of less strength than what would be expected.
Chapter 3 Louden
20
OperatorsBad: For example - in IBM assembly language there are
different instructions for adding memory to register or register to register (non-orthogonal).
Good: In Vax, a single add instruction can have arbitrary operands.
Orthogonality seems to be in opposition with security, since it allows potential errors to go unnoticed
Chapter 3 Louden
21
Most Languages
Chapter 3 Louden
contains array records files
arrays yes yes no
records yes yes no
files yes res no
22
Pascal
Chapter 3 Louden
Functions Integers Float Arrays Strings
input parameters Yes yes yes yes
return values Yes yes no yes
23
If not allow user to overload operators
Chapter 3 Louden
Operator Use integer float complexstrings
User defined types
+ yes yes yes yes no
24
Most Languages
Chapter 3 Louden
Switch integer Boolean Float string
Case Labels yes yes no no
25
Java – non orthogonalities
Chapter 3 Louden
Declarations Type = intType = SomeClass
Type ii is variable of type integer
i is a pointer to SomeClass type object
26
Thought questionWhere does non-orthogonality come
from? If it is “bad design”, why not eliminate it?
How would you rate Ruby in terms of regularity?
Chapter 3 Louden
27Chapter 3 Louden
For examples of non-orthogonality consider C++:
– We can convert from integer to float by simply assigning a float to an integer, but not vice versa. (not a question of ability to do – generality, but of the way it is done)
– Arrays are pass by “what appears to be” reference while integers are pass by value.
– A switch statement works with integers, characters, or enumerated types, but not doubles or Strings.
28Chapter 3 Louden
Regularity examples from C++ Declarations are not uniform: data
declarations must be followed by a semicolon, function declarations must not.
Lots of ways to increment – lack of uniformity (++i, i++, i = i+1)
i=j and i==j look the same, but are different. Lack of uniformity
29Chapter 3 Louden
Other design principlesSimplicity: make things as simple as
possible, but not simpler (Einstein). (Pascal, C)
We can make things so simple that it doesn’t work well – no string handling, no reasonable I/0 (some languages left out of documentation)
Can be cumbersome to use or inefficient.
30Chapter 3 Louden
Other design principlesExpressiveness: make it possible to express
conceptual abstractions directly and simply. (Scheme)
Helps you to think about the problem. Ruby, for example, allows you to return
multiple arguments: a,b= swap(a,b)
31Chapter 3 Louden
Other design principles Extensibility: allow the programmer to
extend the language in various ways. Types, operators, create libraries, extend
built in classes
Security: programs cannot do unexpected damage. (Java)– discourages errors– allows errors to be discovered– type checking
32Chapter 3 Louden
Other design principles (cont.) Preciseness: having a language definition
that can answer programmers and implementers questions.
If it isn’t clear, there will be differences.Example: Declaration in local scope (for loop)
unknown/known after exitExample: implementation of switch statementExample: constants – expressions or not?Example: how much accuracy of float?Example: order of operations
33Chapter 3 Louden
Other design principles (cont.) Machine-independence: should run the same on any
machine. (Java- big effort) Consistent with accepted notations – easy to learn and
understand for experienced programmers (Most languages today, but not Smalltalk & Ruby)– 42 factorial (sends 42 to function factorial – Smalltalk)– Symbols, yield, leave off parens in method calls, use
of $1
Restrictability: a programmer can program effectively in a subset of the full language. (C++: avoids runtime penalties)
34Chapter 3 Louden
Wikipedia moment: Syntactic sugar is a term coined by Peter J.
Landin for additions to the syntax of a computer language that do not affect its expressiveness but make it "sweeter" for humans to use.
Syntactic sugar gives the programmer (designer, in the case of specification computer languages) an alternative way of coding (specifying) that is more practical, either by being more succinct or more like some familiar notation.
35Chapter 3 Louden
C++ case studyThanks to Bjarne Stroustrup, C++ is
not only a great success story, but also the best-documented language development effort in history:– 1997: The C++ Programming Language,
3rd Edition (Addison-Wesley).– 1994: The Design and Evolution of C++
(Addison-Wesley).– 1993: A History of C++ 1979-1991,
SIGPLAN Notices 28(3).
36Chapter 3 Louden
Major C++ design goalsOO features: class, inheritanceStrong type checking for better
compile-time debuggingEfficient executionPortableEasy to implementGood interfaces with other tools
37Chapter 3 Louden
Supplemental C++ design goals C compatibility (but not an absolute goal:
no gratuitous incompatibilities) Incremental development based on
experience. No runtime penalty for unused features. Multiparadigm Stronger type checking than C Learnable in stages Compatibility with other languages and
systems
38Chapter 3 Louden
C++ design errorsToo big?
– C++ programs can be hard to understand and debug
– Not easy to implement– Defended by Stroustrup: multiparadigm
features are worthwhileNo standard library until late (and
even then lacking major features)– Stroustrup agrees this has been a major
problem
39
Review: Language Design Features Efficiency -execution -translation -implementation Reliability Readability Writability Expressiveness
Regularity -generality, -orthogonality -uniformity Simplicity Extensibility Security Preciseness
Chapter 3 Louden