** 2. How to design a PL?  Or, what makes a PL good? **

---------------------------------------------------------------

2.1.

User-oriented goals:

language is easy to learn
   * simple, small, regular

programs are easy to understand & readable
   * natural notation
   * simple to predict behavior; regular
   * modular
   * models application domain
   * programs are not overly long or verbose

programs are easy to write, correctly
   * expressive features & abstraction mechanisms =>
      often at odds with readability!
   * concise notation => ditto
   * domain-specific features & support => at odds with simplicity/smallness
   * no error-prone features
   * internal correctness checks (e.g. typechecking) to avoid errors

programs are easy to modify & extend as requirements change
   * minimal redundancy
   * hooks for extensibility included automatically;
     no features that make it hard to change code later

programs are efficient
   * features for programmers to control efficiency
   * analyzable by compilers and other tools

programs are understandable & writable by programs, too
   * regular syntax & semantics


Others?

---------------------------------------------------------------

2.2.

Design principles:

expressive:
   * powerful
   * easy for programmer to express intent

orthogonal: a collection of a *few* *independent* *powerful* features,
            combinable *without restriction*
   * independent = orthogonal
       two features are the same or very different (the Kay principle)

simple: but what does this mean?
   * simple to learn (given what background?)
   * mathematically simple/regular; small set of rules to describe
   * not very powerful; small

natural:
   * notation resembles what's expected in domain of applicability


Design features:

* Expression-orientedness

* Abstraction mechanisms: anything can be named & parameterized, and
anything can be anonymous
    *) naming is an orthogonal feature to value construction

---------------------------------------------------------------

2.3.

Consider C, Perl, Scheme?

---------------------------------------------------------------

2.4.

Dijkstra: goto harmful
*) people handle static relations better than dynamic ones
*) no "coordinates" to describe state of process

Hoare: hints on PL design
*) programmer tasks: program design, documentation, & debugging
=> simplicity (learnability & masterability)
=> security (not prone to errors; sailor w/ & w/o lifejacket analogy
=> fast compilation
=> efficient compiled code [from simple compiler, and easily optimizable too]
=> readability
-- comment conventions, syntax, arithmetic expressions, ...
*) designer: concentrate on one feature at a time, or assemble w/o innovating

Gabriel: Lisp: good news, bad news, how to win big; "worse is better"
+ good standardization, performance, environments, integration, OOP
"The Right Thing", "MIT approach", Lisp & Scheme
  * simplicity (of interface over implementation)
  * correctness (absolutely)
  * consistency (at cost to simplicity & completeness)
  * completeness (at cost to simplicity)
"Worse is Better", "NJ approach", Unix & C
  * simplicity (of implementation over interface, dominates others)
  * correctness (slightly sacrifice for simplicity)
  * consistency (sacrifice for simplicity)
  * completeness (as much as practical, given other desires)

===============================================================

2.5.

What makes good PL research?

++) How to evaluate new language designs?  Very subjective, and very
application-dependent.  Psych experiments?  Large controlled
double-blind tests?  How to do real scientific experiment?

*) Designing a "better" language from scratch doesn't cut it => too
subjective, too many variables changing

*) Better: pick some area of interest, identify a clear problem w/
existing languages, design a refinement in the context of some good
existing language that is clearly better on some clearly articulated
principles, implement it & gain experience with it, and make it freely
available to others

*) Or, do the same thing, but at the level of a type system

*) Much good PL research can be viewed as software engineering: what
language features or programming idioms lead to good software?

*) Or, look at more objectively-assessed related tools, e.g. compilers