Review of existing Languages


Preliminary Note

There are a lot of these, aren't there ?
I'd love feedback from you, particularly if you know any interesting language not (or poorly) considered here...
Also feel free (=bound :-) to add your comments and to correct broken english and typing mistakes.


Contents

  • Existing languages
  • Other language-related WWW pages
  • Why a New HLL



    Existing languages

    This classification is stupid, approximative, and should be re-done completely, with perhaps an array of "features", to serve as a guide... Of course, the only way to know for sure about the language is to see how it really is... Also, many things here are out of date. Updates welcome...
  • Languages are no more classified in bogus "families"
  • 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. Meanwhile, please forgive the lameness of this page, and think about enhancing it by your contributions.


    Other language-related WWW pages



    Existing Languages


    Agora

    I've been told about this most interesting Agora language. Could anyone send feedback ? Here's an FTP site, and now a WWW site.


    BETA

    BETA is an OO language from those who invented SIMULA. It is the latest advance in OO programming.
    Its only current implementation is the Mjolner BETA system, which is commercial, but with discounts for educational institutions.


    C/C++

    Description

    "C" is a low-level, weakly typed, static, non-modular, non-generic, non-reflective language.
    "C" was designed in the late '70s as a portable assembler for the PDP-11 series (remember? nominally compatible machines but with various word lengths), and it is still the state of the art in that area, although, as a systems programming language, it is more adapted to the PDP-11 than to modern architectures.
    In the late '80s, the small and elegant `K&R' C has become the prey of an ANSI standards commitee; it has now become ANSI Standard C.
    In the '80s, C has (in our opinion wrongly) become the language of choice for general purpose programming. In an attempt to add the features of general-purpose Object-Oriented languages to C, Bjorne Stroustrup created C++, a huge, bloated, hack-ridden monster.

    Writing the formal semantics of C++ is left as an exercise to the reader.

    The only positive point about it is that it is the one standard as a programming language.

    There are also other less popular "object-oriented" versions of C, such as Objective C (Kind of smalltalk with low-level unsecurity and lack of dynamism). or Dynace.

    References

    About C, get the C Bible by Kernighan&Ritchie (the original authors of C). There's also an online tutorial by Dave Marshall, Programming in C.
    About C++, just shoot(yourself.foot++); or if you must, learn to program C++ with the Globewide Network Academy (GNA)'s Introduction to Object Oriented Programming Using C++.
    Look on prep.ai.mit.edu or any mirror site to find GCC, the GNU C Compiler, a free C/C++ compiler, and a lot of utilities written in C.
    Here are papers about why not use C or C++ in general. This one is particularly meaningful as to what a language should be (that C/C++ is not).


    Pros

    1. Anybody knows this language, and we wouldn't have to readapt to another language syntax, as it is the one (now ANSI) standard in system programming (yuck).
    2. We may compile test programs immediately, without having to wait for the kernel and compiler to be done.

    Cons

    Actually, C and C++ are not high-level languages, and just worth throwing to nearest garbage can (poor garbage can), unless you're stuck to it, which you are on existing systems (themselves worth as much, but again, you're stuck to them until Tunes comes out).
    1. C/C++ do not include functions as a first-class object, thus creating a boundary between using and programming: it's a static language; you can't both program and use at the same time. That's the opposite of user programmer/user friendliness.
    2. C/C++ is not a structured language: procedures are all global; that's why C/C++ will NEVER allow having independent light threads, and why it's impossible to have a lightweight multitasking system under C/C++. You may notice that this point is related to the preceding remark: if procedure were objects, you could include them individually inside thread objects, then each thread would have its own independent code.
    3. C/C++ knows only early binding (i.e., it only compiles directly executable code), hardly knows about dynamic library linking (in the case of C, it's not a language feature, only a linker feature); C/C++ considers a program to be complete, finished, and run in the absolute without interaction with other programs, but through the system; that's why all ROI in C must be explicitly done through system calls !!!
    4. The "we won't have to rewrite a compiler" argument doesn't stand: if the system is to be OOed, we'll have to adapt the compiler so that it produces OO code compliant to our system's requirements. Unless our system brings nothing that can't be done easily by replacing the standard library, it's impossible; so only front ends can be reused, which are trivial to write (although more difficult in the case of C than with other languages). All in all, "C" would only get in the way if used.
    5. As it's a low-level language, either we'll have to have low-level specs for the OS (as with Unix), so that we can't adapt to an architecture different from that for the which the OS was designed; or we'll have to rewrite a great amount of the C/C++ code on each system adaptation. So we lose either system functionality, or language portability. Interoperability of code is also impossible, unless we define a common target architecture that other computers will have to emulate.
    6. For the same reason (C/C++ being low-level), we can never achieve object-level security, but by having a C/C++ program for each object, which either disallows everything -however little- is an object in the system, or requires many a low-level system (as opposed to language) declaration in a C source, and/or requires having tiny C/C++ programs, which contradicts the heavy compilation cost and the class philosophy of the language.
    7. Horrible in C and dreadful in C++ is the lack of really first-class structured values. This makes C nothing more than a badly specified portable assembler (with very limited macro facility, and restrictions in calling conventions), and gives a completely obfuscated notion of object identity to C++.
    8. The C++ philosophy contradicts the idea of late user-object binding. C++ knows only of early compile-time object binding, or at best/worst, binding with compile-time defined virtual class realization through so called virtual tables. So to make the slightiest add/change, you must recompile the whole application.
    9. Because the whole object system in C++ is based on lame inheritance, enhancements in a program may mean complete rewrite of the type hierarchy.
    10. The C++ preprocessor allows simple macro-definitions, but neither macro instructions, nor recursive macro definitions. If #define DEF #define was possible, for example, it would be possible to Ziv-Lempel compress a source program from C to C. But cpp just plain sucks.
    Note that "C" offers absolutely no particular interest when cut from all its standard compilers and libraries, for you can no more port existing software. As Tunes won't support any standard "C" library (at least as support for native code), and requires a different compiler anyway, because its semantics is so much different, "C" offers no interest on top of Tunes. Thus, "C" just has nothing to do with Tunes, except perhaps as a layer between Tunes and a POSIX compliant system, if Tunes is to be implemented as an application under such system (see OTOP subproject).


    Concurrent Agregates & ICC++

    The Illinois Concert project is developping two languages for distributed OO computing: Concurrent Agregates (a LISP dialect), and ICC++ (a C++ dialect).


    CECIL

    Cecil is an OO language at University of Washington, participating Craig Chambers who wrote the SELF compiler.


    Clean

    Concurrent Clean is a general purpose, higher order, pure and lazy functional programming language for the development of sequential, parallel and distributed real world applications.

    Clean is a language in the spirit of other modern lazy functional languages like Haskell and Miranda. People familiar with these languages will have no difficulty to program in Clean. The Clean compiler has the nice property that it runs on small platforms (Mac, PC, Sun), while it compiles very quickly and produces code of state-of-the-art quality.


    Common LISP

    Description

    LISP is a self-extending higher-order dynamically typed strict (but with lazy data structures often implemented) non-pure functional language. It is the second oldest programming language, but also one with the nicest semantics. It's a good experimental platform for just any kind of computing; it has got very good support, including free portable development environments, integrated structured editors, and efficient "optimizing" compilers. Unfortunately, LISP syntax takes some getting used to (it uses a very clean but unusual notation called `Cambridge Polish') which makes it quite unpopular with many programmers.

    Studying all the dialects of LISP is enough work for a lifetime. However, there seem to be two main standards as for LISP:
    Common LISP is a huge monolithic language, with hundreds of built-in constructs for a megabyte worth of run-time system (not talking about add-on modules). However, the advantages of programming in Common Lisp cannot be overestimated: everything a programmer usually needs is in the library, the object system is (quite) well integrated with the type system and the condition system (which is unique on its own).
    Common Lisp is now an ANSI Standard (we do not know how legal it is to redistribute the text of the standard in machine-readable form, as we'd like to). For many years, the de facto Common Lisp standard has been `Common Lisp: the Language', by Guy Steele. The (current) second edition is available in electronic form, among others (in the States) from Carnegie Mellon University. as well as (in France) from Supelec
    Scheme is a minimalistic, "skimmed", dialect of LISP, in which everything is built upon the simplest constructs.
    Scheme has a section of its own in this review.
    EuLisp (European Lisp), is a modern object-oriented dialect of Lisp whose design was less minimalist than that of Scheme but less constrained by compatibility reasons than that of Common Lisp. In particular, it has a single namespace for variables and functions (like Scheme, and unlike Common Lisp) and its type system is prefectly integrated with the object system. Furthermore, the language makes use of the module system, so that every program may import only those parts of the language that it needs. You may find the current EuLisp specification here.

    Lisp source code is written in Cambridge Polish which consists of balanced parenthesized expressions of atomic symbols, which are then parsed as S-exps (Symbolic EXPressions). These S-exp are quite (tree-)structured data, which is interpreted very easily. The basic data structure is the (syntactically parenthesized) list of S-exp's, and a list is evaluated by first evaluating each element, then applying the function denoted by its first element to the rest of the list as arguments.
    LISP is really a nice language, but Cambridge Polish is unpleasant for the profane (and even for the expert if you don't use a LISP editor like EMACS, that will help you balance and indent your expressions). Actually, Cambridge Polish is LISP's mostly, but (in the opinion of half the authors of this page) deep flaw: had Lisp a more free syntax, it would fulfill all the requirements for (a basis to) Tunes' HLL. LISP would truly be the one language to do that!

    References

    There are many books about LISP and Scheme.
    About LISP, if you are bald, you may get the specifications for the Common LISP ANSI standard, or read CLtL (Common LISP, the Language) by Guy Steele.
    Both authors of this review agree that the best book about programming they read is Structure and Interpretation of Computer Programs, by Abelsson and Sussman. It happens to use (a slightly old-style subdialect of) Scheme.
    GNU Emacs is a widely spread LISP-based advanced editor. Look on prep.ai.mit.edu or any mirror site to find EMACS.
    There are also newsgroups about LISP and Scheme, comp.lang.lisp, comp.lang.scheme, not to talk about the many groups about emacs or ai.
    LISP and Scheme repository here


    Pros

    1. It's a widely known and standard language, with implementation on just any computer architecture, including very portable ones.
    2. Both interpreters and compilers of good quality are available, and new ones are easy to design, making development easy, and portability quite good.
    3. It is fully reflective
    4. It is strongly-typed, that is, type-safe for a non-trivial type system.

    Cons

    1. the type-system is not safely extensible in a high-level way
    2. it doesn't allow any static typing
    3. it allows too many side-effects
    4. no standard reflectivity allows the syntax to go beyond S-exp's
    5. although it is fully reflective, it has no
    6. it lacks some ML-like pattern matching
    7. it lacks a clean macro system
    8. its standard (common lisp) has got too many features nobody uses.
    9. its module system offers no security at all.

    Notes

      Because LISP is so powerful and versatile a language, several flavors of LISP have been used in a wide range of applications, from industrial control to arcade games, including real-time applications.

    Conclusion

    All in all, it could be said about Lisp's semantics that while it offers a great expressivity as to constructing new objects, it is unexpressive as to express constraints on these.
    About its syntax, we find that it is very all-purpose, and adapts immediately to any use; however, it doesn't allow to scale to specific uses where local constraints make it too redundant.
    It could be said that Lisp is a language based on syntax trees; then, Clean, that is based on graphs, and could be a successor (see also Prolog and Lambda-Prolog for the same in logic programming).


    COBOL

    COBOL means COmmon Business-Oriented Language. It's a very old and lame language which has got a FAQ here.


    Coq

    Coq is a higher-order proof system based on the Curry-Howard isomorphism between propositions and types, proofs and terms in a pure functional language: a functional term is a proof of its type's realizability. By restraining to intuitionistic logic (i.e. no built-in choice axiom), it allows to extract actual programs from proofs.
    The newer version of Coq does have programmable tactics (using CAML-light), extensible grammars, etc.
    The problem with Coq is that it is not reflective: there is a one global meta-context, and no way to meta-translate expressions: a proof done in "Prop" will have to be done again in "Set" and in "Type"; there are no "proof sketches" as first-class objects.
    Coq has got a WWW page, which is no more empty.
    The Coq distribution includes full docs.


    Dylan

    Dylan is a new object oriented dynamic language developped conjointly by Apple, Carnegie Mellon University and Harlequin inc. The main design goal of Dylan was to make a dynamic language that could be compiled as efficiently as static languages. The design group hopes that it might bring dynamic languages to C++ programmers (but don't worry: even some Real Language programmers find Dylan nice).
    See Apple's page, and CMU's Gwydion project for a free implementation of Dylan.


    Eiffel

    Eiffel is an OO language meant for reliable programming, where safety could be somehow proven. Unhappily, it seems to me the language is not expressive enough for all the constraints one may like to verify. Moreover, the language suffers from the choice of typing covariance in functions which makes quite an adhoc type system.
    More crucially, Eiffel has no usable free implementation (well, some are being worked on).
    See Sather for a language that tries to fix all those flaws.
    All this information might be outdated...


    Ellie

    Description

    Ellie is a language designed for computer-scheduled parallelism, which stresses the existence of future values, that the system may lazily or concurrently evaluate.

    References

    You may find papers about it here

    Pros

    1. It has unified semantics for objects (code&data)
    2. the same for parallelism
    3. it has already been studied

    Cons

    1. it's got a cryptic syntax
    2. it's not standard and we don't own it; a compiler may be difficult to have.
    3. It's got almost no "no". No negation, exclusion and such, but in the function/operation assertion, so the compiler cannot understand things as simple as "this object can take these values, and NO other.
    4. no exceptions to cope with the previous: these would be useful for handling errors or special cases, but would be very difficult to design consistently with parallelism.


    Erlang

    A functional languages used in real-life telecommunication applications here. [Looks quite interesting...]


    Escher

    Escher is a declarative, general-purpose programming language which integrates the best features of both functional and logic programming languages. It has types and modules, higher-order and meta-programming facilities, and declarative input/output.
    Escher also has a collection of system modules, providing numerous operations on standard data types such as integers, lists, characters, strings, sets, and programs. The main design aim is to combine in a practical and comprehensive way the best ideas of existing functional and logic languages, such as Gödel, Haskell, and \lambda-Prolog. Indeed, Escher goes well beyond Gödel in its ability to allow function definitions, its higher-order facilities, its improved handling of sets, and its declarative input/output. Escher also goes well beyond Haskell in its ability to run partly-instantiated predicate calls, a familiar feature of logic programming languages which provides a form of non-determinism, and its more flexible handling of equality. The language also has a clean semantics, its underlying logic being (an extension of) Church's simple theory of types.
    You can obtain a report. about it.


    FORTH

    The main on-line source of information about FORTH are the homepage of the FIG (Forth Interest Group), and this page.
    Of course, the place to ask questions about FORTH is the usenet newsgroup comp.lang.forth, which has an old faq and a new faq
    The ANS document for FORTH is available in many formats from here. Here is an online book, "Real-Time Forth",
    FORTH, inc is the company created by the original authors of FORTH.
    The main FORTH site is Skip Carter's taygeta.com (also known as forth.org): HTTP and FTP; it has a german FTP mirror here.
    I've been told of Tim Hendtlass's book that could be found around there
    Also, FORTH stuff on cera2.com or eg3.com
    Some implementations:


    Gema

    Gema is a general purpose macroprocessor.


    Haskell

    Haskell is a lazy (non-strict) functional programming language. serving as a bench for much of the research in functional languages. In particular, it has a very complex type system which unifies ad hoc polymorphism (operator overloading) with normal polymorphism. It might be called a functional object oriented language.
    Gofer is a lightweight version of Haskell. Gofer implementations exist that can be run on desktop computers.
    There's a Haskell group at Glasgow head up by Simon Peyton Jones with its own implementation GHC
    Professor Paul Hudak is heading up the Yale Haskell group, and doing Haskell and music in Haskell.

    See this FTP repository.


    Icon

    Icon is a high-level, general-purpose programming language with a large repertoire of features for processing data structures and character strings. Icon is an imperative, procedural language with a syntax reminiscent of C and Pascal, but with semantics at a much higher level.
    The Icon project (in Arizona) has a WWW page here.


    Java

    Java some kind of revamped C++ dialect meant to be used as a universal WWW language.

    Implementation: Java is indeed two standard: firstly, their garbage language in which they throw every single language feature their twisted mind can think about (not the useful ones, only the ones that sell). Secondly, the horrible low-level bytecode-based JVM virtual machine, that java people are stupid enough to pretend can be secure, efficient, portable bytecode, which is pure nonsense: security is a high-level concept, while efficiency and portability cannot be simultaneously expressed with such a low-level abstraction.

    Java is the new fad, and you'll see everything and the opposite done about Java: Java->X and X->Java compilers (or most likely X->JVM), where X is about any language.

    Here I'll add a few Java-related pages...


    Linda

    Linda is a language for parallel programming.


    M4

    m4 is a powerful (unlike CPP) macro-expansion program designed as a preprocessor to more stubborn languages. It's ugly, but it's fairly standard (available on most platforms, including a fine GNU version).
    The semantics for reflection are horrible, so users who want to do complicated things often find themselves compiling manually to continuation passing style.

    Quick critique of m4 as a programming language

    The language semantics or brain-dead, and remindful of TCL (though simpler and cleaner):
    As a result,
  • you don't have nested definitions of abstractions but with horrible unsafe contorsions that give results inconsistent with deeper abstraction
  • Building new control structures is therefore difficult and unsafe, whereas the language proposes few basic ones.
  • Syntax is modifiable, but previously defined reflective object won't be is consistently modified.
  • Unless stubborn double-character quotes are used, quote characters must be banned from output.
    Also, the language support is poor as
    • There are few input/output primitives, and only output has easy-to-use syntax
    • available implementations make everything but string handling completely unefficient, and proposes no efficient data structure but a string LIFO.
    • there is no standard library
    • there is no standard way to extend the language
    To conclude, m4 offers reflection without abstraction. It really should be used only as a quick and dirty preprocessor, when little programming is needed. I wonder why I sticked to it...


    MISA

    MISA is an interesting project to design the language of next century.


    ML

    ML (originally the Meta Language for a theorem prover) is a class of (strongly) typed functional language.
    ML comes in two main flavors:
  • SML, with its docs and implementations SML/NJ, (same as here, where you could look for "Implementation work using ML"), Edimburgh ML, Moscow ML, and
  • CAML CAML, with its implementations CAML-Light and now Objective CAML, that both have on-line docs around, too.
    SML/NJ is an efficient but hyper-heavy implementation: don't use it with less than 32MB of memory. I don't know about Edimburgh ML. Moscow ML is some SML implementation using the CAML-light run-time. CAML-light is very light-weight bytecode-based implementation that fits almost any 32 or 64 bit computer; as a measure of its usability, it has been used successfully for a game under X11. The new Objective CAML compiles to either portable bytecode or native code, and is meant to compete successfully with SML's efficiency, at much lighter cost and resource requirements, and with a much better and cleaner module system, and with unequaled objects.
    SML has got a powerful but kludgy module system, only fully implemented in SML/NJ. OCAML has got an equivalently powerful and much cleaner module system, that allows separate compilation; plus it has objects which SML hasn't; and it must now have builtin multithread support.
    Here are some interesting software projects I've found using ML:
  • The Fox project from CMU to write an OS using (a hacked version of) SML/NJ running directly over Mach.
  • The Coq project of a constructive proof/program environment written in CAML-light.


    Modula-3

    Modula-3 comes between Modula-2 and Oberon in Niclaus Wirth's quest for his ideal language...
    Click here for more information.


    Napier88

    Napier88 is a persistent programming system from University of St Andrews


    Oberon

    Oberon (now version 2) is the latest modular OO language by Niclaus Wirth (the author of Pascal and Modula) (also here).
    There are FTP sites for Oberon and the Oberon User-group.


    Orca

    Orca is a language for distributed computing, codevelopped with the Amoeba distributed OS.


    Pascal

    Pascal was a toy written by Prof. Nicklaus Wirth to teach computer languages. Unhappily it has been taken seriously by many people.
    See Modula-2, Modula-3, and Oberon for more serious languages developped by Professor Wirth.
    Brian Kernighan (author of C as well as many Pascal software), once wrote an article "Why Pascal is Not My Favorite Language", which is quite obsolete now that modern Pascal's (e.g. Turbo-Pascal) are quite equivalent to C (which also shows C sucks as much as this toy Pascal language).


    Perl

    Perl is a language for easily manipulating text, files, and processes. It provides easy ways to do many jobs that were formerly accomplished (with difficulty) by programming in C or one of the shells.
    Perl4 lacked a lot of expressiveness required for an all purpose language, but already was a great tool for what was clumsily done before with horrible shell/awk/sed scripts and lame C hacks.
    Perl5 has all the good features of Perl4 (a few misfeatures were dropped and replaced), but it's a full-fledged all-purpose language with a most powerful OO module system.
    It is interfaced to lots of libraries (libc, Tk, ncurses, DB/gdbm/ndbm, etc), has got lots of modules to manage various internet protocols, and if by chance it isn't interfaced to your favorite software yet, this can be done through a well-documented extension system.
    And here's a Perl 5 page for people on the bleeding edge. It's a real language, with powerful OO extensions.
    WWW Pages: perl.com perlWWW
    As the name "Practical Extraction and Report Language" coins out, Perl aims at being effective in practice, not at developping a nice and simple semantics (though whenever nice things are effective, Perl does them too). Thus after a short learning time, it becomes a great tool for jobs of interfacing software, converting file formats, making small network daemons, etc. Perl is perfectly adapted to the Unix philosophy and practice. However, it is a bad choice when long-term/wide-area consistency is required.


    Prolog

    Prolog is a language for programming based on Horn-Clause logic (not even full first-order logic).


    Python

    Python is an OO programming language
    WWW and FTP sites.


    RPL

    RPL ("Reverse Polish LISP") is the language from HP 28/48 calculators. Despite their lack of horsepower, these calculators are much more usable and friendly than my unix workstation. Let us try to determine why...

    Pros and Cons

    Pros

    1. The language is reflective: code IS an object as anything on the HP, and it is easily manipulable.
    2. Interaction is done through a visible stack in exactly the same way as the thing is programmed. The interface is thus very well integrated with the programming language, and the interface concepts are simple, with trivial automatization. Much better than windows !
    3. The system is orthogonally persistent.

    Cons

    1. The language was not extensible (well HP48's can be extended using the assembler, but that seems kludgy).
    2. The language was designed with a unique execution context in mind: single user, single-threaded, global variables.
    3. No support for modules and migration.


    Sather

    Sather is a free Object-Oriented programming language rival of Eiffel.


    Scheme

    Scheme is a small dialect (some say a skimmed version) of the LISP language.
    Scheme is among the few languages that have a perfectly defined formal semantics, and not a too kludgy one at that. and Scheme programmers often find it unpleasant to program any other language. However, Scheme suffers from minimalism, and Common Lisp programmers often wish they had a unified library in Scheme.
    Scheme has got a WWW page at the MIT, and you can find more info about Scheme in the Scheme FAQ, from the comp.lang.scheme newsgroup.
    A selection of Scheme code can be found in the Scheme Repository at Indiana University
    The Scheme Underground project to build a complete computing system on top of Scheme48, a portable implementation of Scheme
    The RScheme project led by Prof Paul Wilson at Texas University and TKG. (its ftp site)
    I don't know if it's the same people, but on top of Scheme48 is also scsh (pronounce skish), a Scheme Shell, designed to fully interface Scheme with existing operating systems (mostly Unixish ones, I presume). They may become a serious alternative to Perl, as they will do more than it, with a clean and consistent language [I'm not sure about scsh's support for encapsulation]. However, they still have to add these in their next release: multithreading support, scalability of executable output code, 64-bit support.
    Object-Oriented systems have been implemented in Scheme:
  • OScheme Objective Scheme from INRIA
  • Moostrap (a Self-like language with behavioral reflection)
  • Ken Dickey's YASOS (Yet Another Scheme Object System)
    STk allows access to the popular Tk toolkit for X programming via Scheme.
    Kali Scheme is a Scheme system that offers primitive for distributed computing, and runs on top of Scheme48.
    GNU has its own Scheme dialect, GUILE. They also offer extensive support for a non-prefix alternate syntax to Scheme. Get it on ftp.cygnus.com or SUNSite Europe

    Pros and Cons

    Pros

    1. Scheme is minimalistic, no unneeded constructs or bizarre rules.
    2. It has trivial syntax, so you can concentrate on semantics
    3. Its semantics are very simple, regular and expressive.
    4. It has the best macro system ever found in a language
    5. Just any program can be made a first-class object in Scheme: it has maximal positive expressivity
    6. Scheme is the basis for some of the best book to learn computer science (see SICP)

    Cons

    1. Scheme hasn't got a large standard library.
    2. It has trivial syntax, so there aren't the usual redundancy anchors that help human readers understand programs.
    3. It has no standard module system or any easy mechanism for deferred binding.
    4. There is no standard way to declare read-only objects.
    5. The read-write cons cell concept is a low-level one that dirties the high abstraction level of the language.
    6. There is no standard way to restrict the extent of definition by some requirements ofe context soundness (typing). So while maximally positively expressive, Scheme is as trivially negatively expressive as such a language can be.


    SELF

    SELF is a Object-Oriented programming language based on very simple concepts which allow efficient implementations.
    SELF uses trivial strong typing (much like LISP): there is no "typecasting" backdoor to object representation, but there is no elaborate type hierarchy, just a one unique static type.
    Brown University has an interesting course on SELF.
    The Merlin project uses SELF.


    TCL

    TCL is a logically challenged interpreted language, which is popular because of Tk, a powerful toolkit to program the X-Window environment. Those who really managed to understand its semantics try to explain it with words such as `binding-time', `runtime', `coffee-time' and pretend it's not that bad after all.
    Many better languages, including Perl, Scheme, and Caml-light have access to Tk. And other languages have other interfaces to GUIs.
    Deeper insight can be found at the language critique page or in those Comparisons of Tcl with other systems



    A new HLL

    Pros and Cons

    Pros

    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.

    Cons

    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.


    Draft

  • My TOP 3 languages are RScheme, OCAML, and Clean.


    To Do on this page

  • Create a subdirectory for the Review alone.
  • Have a subfile for each language family.
  • Find all existing HLLs.
  • Write a summary about each of these, with particularities, pros, cons, pointers, (examples/history ?), etc.
  • Add references to the Glossary.
  • Wait for feedback and criticism.
  • Instead of this bogus classification, use actual criteria:
    • strongly typed or not
    • type-dependent types
    • value-dependent types
    • dynamic/static language
    • garbage collection
    • single-dispatch/multidispatch polymorphism
    • first/second/higher order
    • prefix/infix/postfix syntax
    • reflectivity
  • What should we do with proprietary languages?
  • A few pointers to register:


    Back to the Tunes Review Subproject,
    or to the HLL Subproject.


    Page Maintainers:
    Faré -- rideau@ens.fr