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:

other criteria that many people demand that he omits:

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

"
login or register to post comments

" 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

"
login or register to post comments

"

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

"
login or register to post comments

"

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?, Jason Reed, and Elly Jones.

You appear to be advocating a new: [ ] functional [ ] imperative [ ] object-oriented [ ] procedural [ ] stack-based [ ] "multi-paradigm" [ ] lazy [ ] eager [ ] statically-typed [ ] dynamically-typed [ ] pure [ ] impure [ ] non-hygienic [ ] visual [ ] beginner-friendly [ ] non-programmer-friendly [ ] completely incomprehensible programming language. Your language will not work. Here is why it will not work.

You appear to believe that: [ ] Syntax is what makes programming difficult [ ] Garbage collection is free [ ] Computers have infinite memory [ ] Nobody really needs: [ ] concurrency [ ] a REPL [ ] debugger support [ ] IDE support [ ] I/O [ ] to interact with code not written in your language [ ] The entire world speaks 7-bit ASCII [ ] Scaling up to large software projects will be easy [ ] Convincing programmers to adopt a new language will be easy [ ] Convincing programmers to adopt a language-specific IDE will be easy [ ] Programmers love writing lots of boilerplate [ ] Specifying behaviors as "undefined" means that programmers won't rely on them [ ] "Spooky action at a distance" makes programming more fun

Unfortunately, your language (has/lacks): [ ] comprehensible syntax [ ] semicolons [ ] significant whitespace [ ] macros [ ] implicit type conversion [ ] explicit casting [ ] type inference [ ] goto [ ] exceptions [ ] closures [ ] tail recursion [ ] coroutines [ ] reflection [ ] subtyping [ ] multiple inheritance [ ] operator overloading [ ] algebraic datatypes [ ] recursive types [ ] polymorphic types [ ] covariant array typing [ ] monads [ ] dependent types [ ] infix operators [ ] nested comments [ ] multi-line strings [ ] regexes [ ] call-by-value [ ] call-by-name [ ] call-by-reference [ ] call-cc

The following philosophical objections apply: [ ] Programmers should not need to understand category theory to write "Hello, World!" [ ] Programmers should not develop RSI from writing "Hello, World!" [ ] The most significant program written in your language is its own compiler [ ] The most significant program written in your language isn't even its own compiler [ ] No language spec [ ] "The implementation is the spec" [ ] The implementation is closed-source [ ] covered by patents [ ] not owned by you [ ] Your type system is unsound [ ] Your language cannot be unambiguously parsed [ ] a proof of same is attached [ ] invoking this proof crashes the compiler [ ] The name of your language makes it impossible to find on Google [ ] Interpreted languages will never be as fast as C [ ] Compiled languages will never be "extensible" [ ] Writing a compiler that understands English is AI-complete [ ] Your language relies on an optimization which has never been shown possible [ ] There are less than 100 programmers on Earth smart enough to use your language [ ] ____________________________ takes exponential time [ ] ____________________________ is known to be undecidable

Your implementation has the following flaws: [ ] CPUs do not work that way [ ] RAM does not work that way [ ] VMs do not work that way [ ] Compilers do not work that way [ ] Compilers cannot work that way [ ] Shift-reduce conflicts in parsing seem to be resolved using rand() [ ] You require the compiler to be present at runtime [ ] You require the language runtime to be present at compile-time [ ] Your compiler errors are completely inscrutable [ ] Dangerous behavior is only a warning [ ] The compiler crashes if you look at it funny [ ] The VM crashes if you look at it funny [ ] You don't seem to understand basic optimization techniques [ ] You don't seem to understand basic systems programming [ ] You don't seem to understand pointers [ ] You don't seem to understand functions

Additionally, your marketing has the following problems: [ ] Unsupported claims of increased productivity [ ] Unsupported claims of greater "ease of use" [ ] Obviously rigged benchmarks [ ] Graphics, simulation, or crypto benchmarks where your code just calls handwritten assembly through your FFI [ ] String-processing benchmarks where you just call PCRE [ ] Matrix-math benchmarks where you just call BLAS [ ] Noone really believes that your language is faster than: [ ] assembly [ ] C [ ] FORTRAN [ ] Java [ ] Ruby [ ] Prolog [ ] Rejection of orthodox programming-language theory without justification [ ] Rejection of orthodox systems programming without justification [ ] Rejection of orthodox algorithmic theory without justification [ ] Rejection of basic computer science without justification

Taking the wider ecosystem into account, I would like to note that: [ ] Your complex sample code would be one line in: _______________________ [ ] We already have an unsafe imperative language [ ] We already have a safe imperative OO language [ ] We already have a safe statically-typed eager functional language [ ] You have reinvented Lisp but worse [ ] You have reinvented Javascript but worse [ ] You have reinvented Java but worse [ ] You have reinvented C++ but worse [ ] You have reinvented PHP but worse [ ] You have reinvented PHP better, but that's still no justification [ ] You have reinvented Brainfuck but non-ironically

In conclusion, this is what I think of you: [ ] You have some interesting ideas, but this won't fly. [ ] This is a bad language, and you should feel bad for inventing it. [ ] Programming in this language is an adequate punishment for inventing it.

-- http://colinm.org/language_checklist.html

---

http://users.rcn.com/david-moon/PLOT/page-2.html

General Principles " Everything about the language is to be defined in the language itself. The language is to be fully extensible by users, with no magic. Of course to be implementable this requires bootstrapping.

Anything that must be intrinsically known to the compiler is explicitly marked.

Define as much as possible by the binding of names to values.

Use naming conventions in place of Common Lisp's multiple name-binding spaces for functions, variables, types, and packages.

Discourage assignment, and make it syntactically obvious where it is allowed or occurs. But do not forbid it.

Discourage unnecessary type declarations, but allow them where needed.

Use hygienic macros pervasively.

Language-enforced access control is incompatible with macros and with debugging within the language, so do not attempt to provide that type of feature. Use naming conventions and social enforcement instead.

Arithmetic operations must always produce mathematically correct results. No insanity like (x + y) / 2 is sometimes a negative number when both x and y are positive.

Strive for programs to be readable yet concise. Hence use infix syntax, case-insensitive names, and nesting structure indicated by indentation rather than punctuation.

Minimize the use of punctuation and maximize the use of whitespace, for readability.

Avoid abbreviation, but when you must abbreviate, do it consistently.

Strive for simple concepts that combine in powerful ways. Keep removing unnecessary complex features until no more can be removed.

Take full advantage of classes and methods.

Do not conflate the concepts of class, module, scope, and encapsulation. Use simple concepts that combine in powerful ways instead of one overly powerful concept that tries to do everything. "

ELL kernel: http://github.com/manuel/ell/blob/master/KERNEL.org

--

--- " Not sure if this

Not sure if this is the type of criticism you are looking for (these are mostly engineering type problems) but the reasons I still program in non-functional languages are:

Lack of functional polymorphism leads to namespace crowding, i.e. no operator overloading. Type classes help address this somewhat, but it is still a pain point.

Lack of sugar. Despite having clearly inferior support for map/filter/reduce, most scripting languages provide cleaner string processing functionality because of OO-enabled operator overloading and plenty of sugar.

State. Again is an obvious one, but the lack of state is also a plus for pure functional languages. It is a trade-off, and is one of the main features that makes pure functional languages unique. For me this is clearly a feature and not a bug. I do think though, that many of the common problems caused by the lack of state could be addressed with a good helping of sugar on the part of the compiler. " -- http://lambda-the-ultimate.org/node/3924#comment-58889

http://www.haskell.org/haskellwiki/DDC

toread: http://lambda-the-ultimate.org/node/2700 http://conal.net/papers/icfp97/ http://lambda-the-ultimate.org/node/3924#comment-59037 http://lambda-the-ultimate.org/node/3924

--- "

My whole attitude changed when Michael Piatek (one of the star engineers in the group) sent me an initial cut at the core system rewrite in Go, the result of less than a week's work. Unlike the original C++ based system, I could actually read the code, even though I didn't know Go (yet). The #1 benefit we get from Go is the lightweight concurrency provided by goroutines. Instead of a messy chain of dozens of asynchronous callbacks spread over tens of source files, the core logic of the system fits in a couple hundred lines of code, all in the same file. You just read it from top to bottom, and it makes sense.

Michael also made the observation that Go is a language designed for writing Web-based services. Its standard libraries provide all of the machinery you need for serving HTTP, processing URLs, dealing with sockets, doing crypto, processing dates and timestamps, doing compression. Unlike, say, Python, Go is a compiled language and therefore very fast. Go's modular design makes for beautiful decomposition of code across modules, with clear explicit dependencies between them. Its incremental compilation approach makes builds lightning fast. Automatic memory management means you never have to worry about freeing memory (although the usual caveats with a GC-based language apply). " ---

https://github.com/boo-lang/boo/blob/master/docs/BooManifesto.pdf

(see also https://en.wikipedia.org/wiki/Boo_(programming_language) )

--

we value low latency over high throughput (e.g. we want a fast startup for our interpreter, over Java's slow startup but high throughput)

--

BayleShanks RecentChanges Bayle Shanks's website
Comments on notes-computer-programming-programmingLanguageDesign-criteria This page is read-only View other revisions Administration
Last edited 2020-09-09 08:25 UTC by BayleShanks (diff)