Bayle Shanks's website: notes-computer-programming-programmingLanguageDesign-criteria

various people's lists of programming language criteria

---

" Here's a short list of programming-language features that have become ad-hoc standards that everyone expects:

    Object-literal syntax for arrays and hashes
    Array slicing and other intelligent collection operators
    Perl 5 compatible regular expression literals
    Destructuring bind (e.g. x, y = returnTwoValues())
    Function literals and first-class, non-broken closures
    Standard OOP with classes, instances, interfaces, polymorphism, etc.
    Visibility quantifiers (public/private/protected)
    Iterators and generators
    List comprehensions
    Namespaces and packages
    Cross-platform GUI
    Operator overloading
    Keyword and rest parameters
    First-class parser and AST support
    Static typing and duck typing
    Type expressions and statically checkable semantics
    Solid string and collection libraries
    Strings and streams act like collections

Additionally, NBL will have first-class continuations and call/cc. I hear it may even (eventually) have a hygienic macro system, although not in any near-term release.

Not sure about threads. I tend to think you need them, although of course they can be simulated with call/cc. I've also noticed that languages with poor threading support tend to use multiprocessing, which makes them more scalable across machines, since by the time you've set up IPC, distributing across machines isn't much of an architectural change. But I think threads (or equivalent) are still useful. Hopefully NBL has a story here. " -- http://steve-yegge.blogspot.com/2007/02/next-big-language.html " Rule 6: Multi-Platform

NBL will run, at a minimum, both standalone and on the JVM. I'm not sure about plans for .NET, but it seems like that will have to happen as well.

And there are two other platforms that NBL will run on which, more than anything else, are responsible for its upcoming dominance, but I'd be giving away too much if I told you what they were. " -- http://steve-yegge.blogspot.com/2007/02/next-big-language.html

---

" The features I've outlined don't make NBL a great language. I think a truly great language would support Erlang-style concurrency, would have a simpler syntax and a powerful macro system, and would probably have much better support for high-level declarative constructs, e.g. path expressions, structural dispatch (e.g. OCaml's match ... with statement) and query minilanguages. Among other things. "

--- https://docs.google.com/file/d/0B7ZmlZgOfG3KUkpWQVpud0N2dWs/edit CleanCode?-E0-TheLastProgrammingLanguage?-540p.mp4 :

his criteria for a language:

VM
light syntax (like lisp, smalltalk, or fourth)
polymorphism
OOP (no jumping to function pointers) + structured programming (no goto) + functional (no assignments)
should be able to interoperate with other languages and libraries in other languages well, esp. JVM and .NET (e.g. ruby, python, clojure)
garbage collected
fast
high level (e.g. you shouldn't know how many bits are in an integer; C is too close to the metal, smalltalk, clojure and ruby are not)
textual, not graphical
homeoiconic (lisps have this)
dynamically change the language while its running (lisp, ruby and java)
problems with C: not garbage collected, polymorphism is possible but too hard, no VM, cannot modify it while it's running, not homeoiconic
problems with C++: same problems as C, and way too much syntax
problems with Java: not functional, a little syntax heavy
problems with C#: same as Java

other criteria that many people demand that he omits:

static typing
- various criteria about the expressivness of static typing, e.g.:
- generics
true multithreading (e.g. no GIL)

http://lambda-the-ultimate.org/node/3166

"What Are The Resolved Debates in General Purpose Language Design?

In the history of PL design there has been quite a bit of vitriol spilled over design choices. These days bringing up "static vs dynamic typing" is a good way to generate some heat on a cold winter web forum.

But a few debates seem to have been pretty firmly resolved, at least for general purpose languages. GP languages have considered goto harmful for decades now, dynamic scoping is seen as a real oddity, and manual memory management is a choice only made by systems language designers.

Questions for LtU?: What other debates have been "resolved" in the sense that general purpose languages are hardly ever designed with an alternative to the consensus? What debates will be resolved in the near future? And what apparently resolved debates deserve to be reopened?

One rule: "static vs dynamic typing" will be considered off topic because clearly and emphatically that debate hasn't been resolved and has no prospect of being resolved any time soon. Also, it's boring. "

" First-class functions. Memory safety. " (some argument on FCF in the thread below)

" 1. Structured programming (Goto considered harmful) 2. Lexical Scoping "

but: "Besides CL and Perl, Clojure includes a (thread local) dynamically scoped binding construct as part of the language and Scala has one in its library. So the resolved issue is, as you say, what's the default rather than whether it should exist or not."

Here's a few:

Might not think about these because we don't argue about them.

    Numbers (at least small integrals and finite-precision reals)
    Arithmetic (sum, product, division, modulo)
    Structured Aggregate Data (at least one mechanism to glob small bits of data into larger structures)... but note that immutability of these structures is NOT resolved.
    Structured Programs (at least one mechanism, such as procedures, to break down big programs into smaller chunks)
    Conditional Execution (ability to specify that a subprogram execute only in certain conditions)
    Recursive Definitions (ability for a procedure, function, or method to ultimately call back into itself, including co-recursion)
    Dynamic Memory Allocation & Management (excepting in certain embedded domains... ability to fetch more memory on demand and later release it; doing so may be explicit or implicit)
    Pattern Matching - from simple to advanced forms of switch/case statements.
    Modularity - breaking down large projects into bite-sized chunks accessed through an interface (usually a set of shared names)
    Named Variables - ability to assign something to a name at runtime then use that name to access that something; issue of single-assignment vs. mutable variables remains.

Here's a few stubborn old entries that I believe aren't yet resolved to everyone's satisfaction:

    Exception Handling (and especially Java-style 'checked' exceptions, which some claim even more 'evil' than the regular exceptions)
    Reflection
    Concurrency (many languages still don't acknowledge it, nobody agrees on how to do it)
    Representing IO
    Macros/Extensible Language/Operator Overloading (much holy war fodder between language designers here, concerns regarding maintainability of code by newcomers to projects)
    Syntax, especially Syntax of comments :-)

There are tons more issues that simply don't come up that often (security in languages is a major focus of E and my own language, language integrated queries are on the new side but are regarded as pretty cool, resumable exceptions are wicked nice but nobody but to my knowledge only Lisp really has them, multi-methods, open functions, open data types, aspect-oriented programming, dataflow constructs, versioning/transactions/undo-capabilities, etc. simply don't come up in enough languages to be subject to widespread debate. By dmbarbour at Tue, 2009-01-13 16:59

" unicode strings "

" XPath/XQuery " (most ppl disagree but some like it, tho dont consider it 'resolved')

"Constants "

" Block scope "

" Resolved to be deserved to be resolved.

1. High level module system. Functor, Functor-Functors. 2. Module / Component dependency and composition wiring. 3. Symmetrical, turtles all the way down, full control of Opaque or Transparent Types. 4. Macros. 5. Immutability. With concise syntax for copy constructing new instances with mutated field values (Records/Objects/Tuples) 6. Opting for Nullessness. 7. Contracts with blame. 8. Pattern Matching 9. Tail Recursion 10. Continuations (even better serializable continuations) 11. Seamless and simple, dynamic compilation and loading. 12. Named and Default Parameters. 13. Currying 14. Lazyness / Call-By-Name capable but not enforced. 15. Well behaved multiple inheritance / mixins. 16. Introspection and Reflection. 17. Runtime typing annotations. 18. Closures. 19. First Class Functions, Classes, Modules. 20. Component Versioning. 21. Optional Effects System. "

(settled as bad, i assume): " `typeless' variables as in B. self-modifying code. Wierd lexical schemes like APL. `natural' English like FLOW-MATIC and COBOL. "

" Whitespace as a token separator "

Resolved negatively

Structural code editors (i.e. that would not let you make code that doesn't parse) failed. Turns out that today's style of IDEs, which let you write whatever you want and simply highlight errors and have good error recovery, have won.

Similarly, graphical programming (stitching together boxes and arrows) has been shown to be far inferior than good-ole textual programming, relegated to UML and design tools that generate boilerplate code. By Ben L. Titzer at Wed, 2009-01-14 20:55

Static syntax

I agree with David Barbour's comment that syntax isn't a settled matter. Beyond that, I think this is a place that there should be space for different approaches.

But one very valuable property of syntax does seem to be accepted wisdom: you should be able to lex/parse the syntax without running the program. This was not always the case: there are some legacy languages out there where the dynamics of the reader could be manipulated during program execution. TeX?, a cornucopia of both good rendering algorithms and bad PL design decisions, is probably the most important such language.

Postscript: Following the mention of languages such as Katahdin & Converge in the Macro Systems thread, I see that the above isn't and shouldn't be accepted wisdom, since there is interest in embedding DSLs with user defined grammars & the whole enterprise isn't incoherent. I'll refine my claim to say there should be a well-behaved separation between syntax and evaluation of code, such as is violated on a grand scale by TeX?, and also, in a less grand sense, by some macro expander languages such as m4. By Charles Stewart at Fri, 2009-01-16 12:35

A modern language. Go has everything you’d expect a modern language to have: Unicode, garbage collection, multi-core (GOMAXPROCS), built-in map, string and array types, closures, unit-testing , an official style guide (‘gofmt’), reflection, etc "

" So what does C++11 bring to the table? To mention some:

Safety - Standardized smart pointers, nullptr, better type-safety

Performance - Rvalue references, move semantics, constant expressions with constexpr

Concurrency - Standard facilities for threading, async, futures

Language features - lambda expressions, support for UTF8/16/32, uniform initialization

Libraries - std::chrono for various time handling facilities, standard random number engines and generators, hash tables, regular expressions, tuples

There's also plans to introduce more libraries to C++ next year, and evolve the language through libraries rather than the core language specification. "

Programming Language Checklist by Colin McMillen?