notes-computer-programming-programmingLanguagesBook-programmingLanguagesChCriteria

Table of Contents for Programming Languages: a survey

Chapter ?: Design Criteria for programming languages

High-level criteria

readability, simplicity, expressiveness, power (expressiveness/simplicity), succinctness, metaprogrammability, communal gravity,

principal of least astonishment

performance fast throuput fast startup low latency real-time profilable

fast prototyping

longevity

code reuse

assisting the work of teams

homoiconicity

ease of use

productivity

expressiveness

maintainability

correctness and safety

REPL

compiled

http://en.wikipedia.org/wiki/Separation_of_concerns

todo add everything from http://en.wikipedia.org/wiki/Unix_philosophy

what else

"there's more than one way to do it"

"Easy things should be easy and hard things should be possible"

Extensibility vs. gravity and readability

http://www.winestockwebdesign.com/Essays/Lisp_Curse.html

"You will be interested to learn that the very first version of Smalltalk (-72) had a completely extensible syntax (in fact the writing of a class also automatically supplied the grammar). This worked very well, except ... that too much freedom here leads to a Tower of Babel as far as other users are concerned. This has also been the experience with the few other really good extensible languages (like Ned Iron's IMP). Extreme extensibility was removed in the next major design of Smalltalk (-76) in favor of a syntax that could read by anyone, regardless of how many classes had been defined ... I.e., getting stronger meanings turned out to be more important in the end than making language structures fit the task." -- Alan Kay

regularity

e.g. of irregularity in C: in one context (inside a function), the 'static' keyword is used to make a variable persist across calls to that function. But in another context (outside of any function), the same 'static' keyword is used as an access modifier to define visibility to other compilation units!

from http://www.catb.org/esr/writings/taoup/html/ : Rule of Modularity: Write simple parts connected by clean interfaces. Rule of Clarity: Clarity is better than cleverness. Rule of Composition: Design programs to be connected with other programs. Rule of Separation: Separate policy from mechanism; separate interfaces from engines. Rule of Simplicity: Design for simplicity; add complexity only where you must. Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do. Rule of Transparency: Design for visibility to make inspection and debugging easier. Rule of Robustness: Robustness is the child of transparency and simplicity. Rule of Representation: Fold knowledge into data, so program logic can be stupid and robust. Rule of Least Surprise: In interface design, always do the least surprising thing. Rule of Silence: When a program has nothing surprising to say, it should say nothing. Rule of Repair: Repair what you can — but when you must fail, fail noisily and as soon as possible. Rule of Economy: Programmer time is expensive; conserve it in preference to machine time. Rule of Generation: Avoid hand-hacking; write programs to write programs when you can. Rule of Optimization: Prototype before polishing. Get it working before you optimize it. Rule of Diversity: Distrust all claims for one true way. Rule of Extensibility: Design for the future, because it will be here sooner than you think. KISS

from http://www.catb.org/esr/writings/taoup/html/ :

Don't Repeat Yourself (DRY)

http://www.catb.org/esr/writings/taoup/html/ch04s02.html#spot_rule following Brian Kernighan calls DRY Single Point Of Truth or SPOT rule, and also says "There is an analog of the SPOT rule for data structures: “No junk, no confusion”. “No junk” says that the data structure (the model) should be minimal, e.g., not made so general that it can represent situations which cannot exist. “No confusion” says that states which must be kept distinct in the real-world problem must be kept distinct in the model. In short, the SPOT rule advocates seeking a data structure whose states have a one-to-one correspondence with the states of the real-world system to be modeled."

textuality

(end http://www.catb.org/esr/writings/taoup/html/ section )

Mid-level criteria and specific criteria

zen of python

C++: "you only pay for what you use"

"All manipulable entities should be first-class objects" (Kernel)

Metaprogrammability: "Programmer-defined facilities should be able to duplicate all the capabilities and properties of built-in facilities" (Kernel)

Protecting you from yourself: "Dangerous computation behaviors (e.g., hygiene violations), while permitted on general principle, should be difficult to program by accident" (Kernel)

todo find others from [1]

Uniform access principle: "All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation" (Eiffel)

ability for the typical programmer to simulate the precise operation of any visible part of the language (e.g. the type system is visible; the garbage collector is invisible. see https://news.ycombinator.com/item?id=6442550 )

no expressiveness penalty for indirection: you should be able to take a big block of code and separate it into different functions which call each other, or different modules which call each other, without losing expressiveness or flexibility.

no flexibility penalty for factoring: if there are two functions or modules A and B, and if they both have a subroutine C that does the same thing with the same code, then you should be able to factor out C into its own function or module, depended upon by both A and B, without losing any flexibility or modularity beyond the loss of the ability to make a separate version of C for A and for B"

Determinisism except where desired / "Deterministic by Default"

readability :: not too much punctuation ('line noise'): when there are too many punctuation characters in frequently-encountered source code, this gives an impression of unreadability (the term 'line noise' goes back to the days of acoustic modems, in which a terminal sessions were often not error-corrected, and sometimes spurious strange characters would appear due to noise in the underlying communications medium). An example of a language which tends towards 'line noise' is Perl.

readability :: not too little punctuation: judicious use of punctuation can greatly aid visual scanning and brevity. An example is array assignment; in languages that use something like "arr[i1, i2] = x", it's easy to scan through the program and look for the pattern 'arr[..] = ..', and there is not many characters wasted. An example of a language that doesn't make much use of punctuation is Common Lisp; the above would be '(setf (aref arr i1 i2) x)', which is both more verbose and harder to scan for. In Clojure we'd have something like (aset arr i1 i2 x).

"the new words defined by a library should look just like primitives of the language" -- "Growing a Language" by Guy L. Steele Jr

semantic constraints on the programmer

goto considered harmful

continuations as the functional goto

referential transparency

Tradeoffs

The expressiveness/simplicity tradeoff

Often there is a choice whether to permit (or even require) the use of very expressive semantics in some area, or to permit only an (over)simplified variant. The benefit of the former choice could be in conciseness through abstraction, performance, safety, or in some other area. The benefit of the latter choice is simplicity, with all that implies (decreased cognitive load, easier to read, learnability).

Examples of places where this comes up are the type system (e.g. do we have type signatures for first-class functions that describe the types of the arguments?), argument passing semantics (e.g. do we allow the explicit choice of either of call-by-value and call-by-reference?), concurrency semantics (e.g. do we allow a choice of various memory consistency models for atomic operations?), evaluation strategy (e.g. do we allow an explict choice between lazy and strict evaluation? if lazy, do we allow a choice between e.g. foldl and foldr?), memory allocation (e.g. do we allow explict selection of allocation on the stack or the heap? do we allow explicit destructors?)

Pros and cons of static/dynamic typing

The "Bánffy-Bray criteria for selecting between static and dynamic type systems:

    Static typing’s attractiveness is a direct function (and dynamic typing’s an inverse function) of API surface size.
    Dynamic typing’s attractiveness is a direct function (and static typing’s an inverse function) of unit testing workability." -- https://www.tbray.org/ongoing/When/201x/2011/12/27/Type-Systems

Links

.