Review of existing Languages

Preliminary Note

This page has been moved to the project Wiki. This page remains for material which for various reasons has not been migrated elsewhere yet. Expect it to be gone shortly.

Relevant Features

  • When Tunes is ready, this page will be made a query-driven database (with standard query forms) where languages/implementations couples will be classified upon the characteristics below.

    Scheme Critique

    See generic critique for LISP languages above


    1. Scheme is an IEEE standard.
    2. Scheme has got lots and lots of implementations
    3. Scheme has got a clean, short, and expressive formal semantics.
    4. Scheme has got the best macro systems ever found in a language.
    5. Scheme is minimalistic, no unneeded constructs or bizarre rules.
    6. Scheme makes lots of things completely orthogonal.
    7. Just any program can be made a first-class object in Scheme: it has maximal positive expressiveness.
    8. Scheme is the basis for some of the best books to learn computer science (see SICP)
    9. Scheme can express just any programming style in existence, including functional, procedural, logic, constraint, OO, and whatever programming style you want, for which you'll easily find lots of example source packages.


    1. The standard focuses only on the core language, and completely ignores lots of issues that are required for real world use.
    2. All the implementations of Scheme are completely incompatible with each other for anything but batch computation, because only the core language is standardized.
    3. Notably, no standard binding for non-trivial I/O primitives, threads, persistence, etc, exist in standard Scheme.
    4. It has no standard module system or any easy mechanism for deferred binding.
    5. Scheme hasn't got a large standard library, which makes every Scheme implementation incompatible with the others as far as the system interface is concerned. SRFIs are meant to improve things here.
    6. Actually, its very lack of a standard module system makes development of such library difficult. This is the ONE BIG PROBLEM that prevents Scheme from being used in large projects.
    7. The effect of lack of a module system make things very bad as far as namespace management is concerned: the theory is as bad as C (only a one global namespace), and the practice is even worse (making a (define) definition local is not a local transformation on a module, whereas in C, putting the static keyword suffices)
    8. Despite its simple and clean semantics, Scheme is too low-level wrt mutability.
    9. There is no standard way to declare read-only objects. More modern functional languages can do this, and this really would allow much cleaner semantics, hence easier optimization, etc.
    10. The read-write cons cell concept is a very low-level one that dirties the otherwise high abstraction level of the language.
    11. More generally, Scheme does introduce both the concepts of values and of locations, but does it in complex non-orthogonal ways, which plain sucks.
    12. Even more generally, there are a lot of things doable in Scheme, that the Scheme standard offers no way to do, but with clumsy inefficient abstraction inversion, which makes the language both powerful and frustrating.
    13. Every single feature you want may be found as first-class in some Scheme implementation, only it will not be standard, and you'll never find a Scheme implementation with all the features you need.
    14. Perhaps because of not having a module system that would allow to separate "core" constructs from "library" constructs, Scheme fails even at providing a really minimal "core" language, and has lots of unorthogonal features.
    15. Unlike other LISP dialects, Scheme offers no standard way to do run-time reflection; even support for compile-time reflection is minimal and not very adequate, through explicitly manipulating source as data, and using the macro system.
    16. The semantics of Scheme macros is not well-defined; only puny "syntactic macros" are standardized, and nothing is specified about concepts of compile-time, run-time, etc, concerning the non-standard but ubiquitous LISP-like defmacro constructs.

    A new HLL


    1. We can design the syntax to fit our needs and ideas, so that it's much easier to use. Moreover, even C isn't our natural language, and whatever language we use, there will have been adaptating time to use it.
    2. We can correct the lacks of any existing language we would have used.
    3. Portability: both the system and the language may be as easy to port. All you need do is porting a LLL compiler back-end or interpreter, and hardware specific lolos (low-level objects).
    4. The language is perfectly well adapted to the system. No need of bizarre and slow language -> system call translation.
    being efficient as an interpreted language, it may serve as a shell language as well as a programming language; being powerful, and easy to specialize via standard libraries, it also replaces small utility languages (sed, awk, perl, etc); finally, being high-level and knowing of relations between objects, it is easily adaptated to an AI language. So there is no more need to learn a different language for every application; the same language is used for (almost) everything; no more need to learn new syntaxes each time.


    1. we have to relearn a new language syntax. But as we may choose whatever syntax pleases us (and support multiple automatically translatable syntax), this is no great deal, really.
    2. No existing compiler can be used directly. This is no great deal either: Front end are easy to write, and no existing back end can fit an interestingly new OS' object format, calling conventions, and security requirements. Moreover, our system having a brand new conception, even with a traditional language, we'll have to learn restrictions about our way of programming.
    3. we have to debug the language specifications as we use it. But this can prove useful to refine the language and the system specs. Here is an interesting point.