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



Language-related WWW pages

Indices


Some "paradigms" of programming


Implementational topics


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...



Existing Languages


ADA

Description

There is a lot of things to say about ADA. Anyone care to write a review?

Pointers

I didn't do a comprehensive web search yet, but have been given this URL.
ADA was originally chosen as US DoD's language, and was meant to fulfill the Steelman specifications.


Agora

Description

Agora is a prototype-based OO language ŕ la SELF, that is used to explore reflective features (notably mixins).
Could anyone have a deep look and send insightful feedback?

Pointers

Here's an FTP site, and now a WWW site.


BETA

Description

BETA is an OO language from those who invented SIMULA. It is the latest advance in OO programming.

Implementations

  • The reference implementation, is the commercial Mjolner BETA system; educational institutions may have discounts.
  • There is now a free interpreter, GBETA

  • C/C++

    This entry should definitely be updated and split into C, C++, Objective C, etc.

    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 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).
    C++ critique v3
    LC-Lint is the best existing typechecker for C.
    Ctools, by Tom Lord, might also prove useful (where is it?)


    Critique

  • 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. It is remarkable that most security alerts in operating systems are related to buffer overruns in C code, because the language doesn't help in any way to automatically ensure safety -- unsafety is the default, and manually ensuring it is a long, tedious, difficult task. A higher-level language could fully automatize safety, making it the default, whereas it would be unsafe operations that would have to be explicitly coded.
    8. 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++.
    9. 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.
    10. Because the whole object system in C++ is based on lame inheritance, enhancements in a program may mean complete rewrite of the type hierarchy.
    11. The C/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

    LISP

    Common LISP is a dialect of the LISP family of languages. See the according information below.

    Description

    Common LISP is the result of a standardization effort by Lisp vendors started with the commercialization of LISP in the early 80s. Because it strived toward backward compatibility with existing Lisp systems, the result is a huge monolithic ANSI standard 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). Greenspun's Tenth Rule of Programming states that "any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp".

    Online Books about Common LISP

    • For many years, the de facto Common Lisp standard has been `Common Lisp: the Language' (CLtL), edited by Guy Steele. The (current) second edition (CLtL2) is available in electronic form, among others (in the States) from Carnegie Mellon University, as well as (in France) from Supelec
    • The Common Lisp HyperSpec is the definitive ANSI standard made available as hypertext from Harlequin (download or browse)
    • An Introduction to Common Lisp excellent page of pointers to Lisp related resources all over the Web
    • CLIM 2.0 User's Manual available as hypertext from Harlequin (download or browse) (also the CLIM spec)
    • Other books online from Harlequin (various, including Dylan refs)

    Free Implementations of CommonLISP

    • CMU CL 17f is a deadly fast free compiler for CommonLISP.
    • Bruno Haible's CLISP is a portable and compact implementation of CommonLISP written in C and using bytecode. Does not implement the full CLOS MOP.
    • Franz Inc. sells its commercial system Allegro CommonLISP on most platforms, but will send you for free CD containing the Linux version of ACL 4.3.
    • Harlequin sells its commercial system LispWorks and Liquid Common LISP (bought from the dead Lucid), but you can download for free its FreeLisp version of LispWorks for Windows95.

    Free software packages written in Common LISP

    • CL-HTTP The Common Lisp Hypermedia Server
    • Free CLIM is an effort for a free implementation of CLIM.
    • Thread Interfaces for Common Lisp are discussed here

    Critique

    • See Generic critique for LISP languages

    • Pros

      1. It is an ANSI standard.
      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 has a most advanced object system with generic functions and multiple dispatch (CLOS), a unique feature about widely implemented languages.
      4. The object system (CLOS) has got most advanced reflective features through a Meta-Object Protocol (MOP)
      5. Functional programming allows good factorization of programs, so that added features take very little space as compared to non-functional programs.
      6. It has a powerful standardized macro system
      7. It has got a package system.
      8. It has got a powerful library of builtin features.
      9. You can declare types to achieve very efficient compiled code.

    • Cons

      1. the standard has got too many legacy features nobody uses.
      2. many essential features for a modern language are not standardized (notably threads), and how it is implemented (or not) on each implementation varies.
      3. The object system's semantics does too many things dynamically at run-time.
      4. The Object and Meta-Object system is too much based on side-effects
      5. Though today's machines have more than enough memory to run CL (which was not the case in the early days of CL), CL still takes too much space to be used in embedded environments.
      6. The macro system does not have as clean semantics as it should.
      7. its module system offers no security at all.
      8. The too many builtin features are not orthogonal enough.
      9. There is no standard way by which the system would statically check declared types and infer new ones as a tool for enforcing static invariants and tracking bugs.


    COBOL

    COBOL is the COmmon Business-Oriented Language.
    It's a very old and lame language. The kind of thing a sensible man wouldn't touch unless forced to. Because its syntax is so verbose, it makes the neophyte and non-programmer believe they actually understand programming better. But of course, what makes a good language is its semantics, not its syntax, and for actual programming, COBOL syntax gets in the way, while its semantics plain suck.
    If you're interested, check the COBOL FAQ.


    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, that aims at being compiled as efficiently as static languages, while providing an unequaled development environment. 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).
    Dylan was developped conjointly by Apple, Carnegie Mellon University, and Harlequin inc. But Apple abandonned the project half-way, and we hear no news from the Gwydion project at CMU; however, Harlequin seems to be still committed to Dylan, and announced DylanWorks for late 1997.

    Pointers


    Eiffel

    Eiffel is a rather clean OO language originally designed by Bertrand Meyer, that stresses the concept of programming by contract, to achieve reliable industrial-strength programs.
    Unhappily, the language as it is is not expressive enough to express 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.
    See Sather for a language that tries to fix some of the flaws of Eiffel.

    Implementations

    More crucially, Eiffel has no complete usable free implementation; however, there is one, SmallEiffel, being developed under the GPL.
    There are lots of commercial implementations, though I have only these pointer handy:

    Pointers


    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 pure 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.


    EuLisp

    LISP

    EuLISP is a dialect of the LISP family of languages. See the according information below.

    Description

    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 perfectly 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.

    Pointers

    You may find the current EuLisp specification and sample implementations here.


    FORTH

    Description

    FORTH is a low-level functional language for a stack-based virtual machine model.
    It is a very interesting language to study, both for its achievements and its shortcomings.

    Standard

    The current Forth standard is ANSI's 1992 ANS FORTH. It replaces the FORTH'83 and FORTH'78 standards.
    FORTH is also being used as the standard language for Open Firmware, used to boot all modern computers in a portable way (see Firmworks).

    Pointers

    • 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.
    • On Skip's site lies the homepage of the FIG (Forth Interest Group).
    • Another important page here.
    • Of course, the place to ask questions about FORTH is the usenet newsgroup comp.lang.forth, on which is regularly published a FAQ (you might also look at the old faq)
    • FORTH, inc is the company created by the original authors of FORTH.
    • Also, FORTH stuff on cera2.com or eg3.com

    Online Books

    Some implementations

    • GNU Forth is a portable 32-bit FORTH interpreter written in C, with efficient assembly routines on common platforms.
    • PFE is a free, portable, and super-standard implementation of FORTH that runs on unices and PCs.
    • Wil Baden's Macro4th is a mostly standard FORTH with very interesting (unstandard) features. Runs on unices, pcs, macs.
    • F-PC is a very popular FORTH system for the old 16-bit PC. The page also contains lots of useful FORTH pointers.
    • Forth/2 is a free implementation for OS/2 that comes with source.
    • MOPS is an FORTH with builtin OO extensions well integrated into the MacIntosh environment.

    Random pointers to sort out about FORTH


    Gema

    Gema is a general purpose macroprocessor.


    Haskell

    Haskell is the reference among pure lazy functional programming language. It serves as a bench for much of the research and teaching in pure functional languages. In particular, it has a very elaborate 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.
    pointers to sort out:


    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.
    There's an OO extension to Icon, Idol.


    Java

    Java some kind of revamped C++ dialect meant to be used as a universal WWW language.
    Design
    Java starts from the C++ syntax and object model, frees it from C compatibility and ugly hacks; frees it from manual memory management, pointer arithbuggics, and unsafe typecasting; then it tries to add just every possible in-fad feature, without having any clean design principle (how could they starting from the C++ object model?). That is, they clean up C++, remove much of its fat, but essentially follow the same general bloat-oriented design.
    They nonetheless provide interesting features (Interfaces), and overall, the language is much cleaner (hence better) than C++ for OOP programming (see the C++ critique v3). Note that much better than C++ does not remotely mean "good". And whatever "OOP" means, being good at it might not mean being much useful, either...
    Implementation
    Java is indeed two standard: firstly, their language (see above), but secondly, and perhaps more importantly, their low-level bytecode-based JVM virtual machine.
    Java people pretend that their JVM allows for secure, efficient, portable bytecode. Of course, this is pure nonsense:
    • Security is a high-level concept; just no low-level representation can bring it; they can do no better, only worse, than what any typed scoped language brings; and their actual security claims look like they are based on their isolating programs in a black box with restricted access to the environment, which is no better than what "protected" operating systems already do, and doesn't solve the fact that a program can be useful only in as much as it affects actual resources.
    • Efficiency and portability cannot be simultaneously expressed with such a low level of abstraction. The JVM is just a lousy intermediate code representation, that isn't well adapted to high-level optimizations.
    Hype
    Java is a hype-oriented language. Expect you usual computer hypists to talk a lot about Java. The main principle about their constantly adding features to Java, seems to be "poll the opinion to determine what feature will have it sell better", which of course leads to inconsistent design that doesn't work right.
    Because Java is the new fad, you'll see lots of Java implementations, development systems, and application software getting written; lots of Java->X and X->Java compilers (or more likely JVM->X, X->JVM), where X is about any language.
    Conclusion
    Let's put aside the hype, and forget about those pretentions of Java being the mother-of-all programming languages. Then, Java is still a usable language, though with currently buggy implementations. However, whatever you'd want to do with it, you can do it much better with a cleaner language! The only interest of it may lie in its alledged WWW-portability provided by the JVM, but many other languages now have compilers targetting the JVM (plus the JVM sucks), so this is not a particularly good argument for Java.
    Related Pages
    Here I'll add a few Java-related pages...


    Linda

    Linda is a language for parallel programming, by publishing tuples in a global space.
    The idea seems nice, but it's basically a very very particular case of what pi-calculus allows.


    LISP

    Description

    Originally invented in 1956 by John McCarthy, LISP (which originally stood for LISt Processing) is a family of languages that have always been at the cutting edge, because they stressed better semantics rather than fancy syntax.

    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.

    Syntax

    Lisp source code is most often written in Cambridge Polish notation: from a set of atomic symbols, you build Symbolic EXPressions (S-exp or SEXP -- once was SEX), a SEXP being either atomic, or a list of smaller SEXP, read and written as the parenthesized space-separated sequence of the representations of its components.

    The basic data structure, the SEXP, is hence a recursive list, and provides a trivial syntax for writing programs: atomic symbols each denote a value, and a list being interpreted as a function call; the head element of the list is computed as a function, the tail of the list is computed as parameters given to it, and the result is what applying the function to the parameters return. (Of course, SEXP need not be interpreted this way, and indeed, good implementations will compile them insteadfor better performance).

    Knowledgeable computists will see that SEXPs are a actually only a trivial syntax for abstract syntax trees. While programmers and language implementers of other languages spend so much time and effort mastering or developing wierd fancy syntaxes, that they spend years debugging, parsing, etc, Lisp programmers and implementers instead trivialize those tasks, and can focus on semantics. At the same time, S-exp give an canonical embedding of source code as data, which is foremost for development of meta-programs and reflective features.

    SEXP syntax is unobvious at first; not only is it unfamiliar for someone having received a standard education; it also lacks these kinds of redundancy that make it so easy to read simple things in many other languages at first when read in a linear way, while imposing a systematic repetitive constraint that is tedious to follow, all the less without good editing tools (such as EMACS), and a treelike indentation of code (which is some different useful redundancy), of which most programmers are unaware. For these reasons, SEXP has gained a bad reputation among illiterate programmers, who don't see beyond the syntax, and LISP has been surnamed such things as "Lots of Insipid and Stubborn Parentheses".

    On the other hand, SEXP also avoids the ambiguities and limitations that make it so easy to write gross mistakes in many other languages, and to tedious (when even possible) the elaboration of complex programs. After a short training, SEXP appear as the representation for abstract syntax trees that they are, and they become as familiar to LISP programmers as the infix syntaxes considered as "normal" by other people (which after all is a matter of conventions and education); only SEXP have lots of additional advantages, as already described. There actually used to be another more conventional syntax for LISP, the M-exp, but it fell out of use as the S-exp were so much more practical to Lispers whereas the M-exp led to endless arguing about with way to write things was fanciest, and how to translate between code and data representations.

    The advantages brought by the trivial SEXP syntax are precisely the strongest asset of the LISP family of languages, and all stem from the fact that the programmer's brain was literally liberated from the yoke of syntax. SEXP mean "drop the syntactic brainfuck, and get to the actual semantic problem". Paradoxically, the uncommon character of LISP's syntax has also been the biggest brake to its spreading widely, so that LISP's strongest asset is also one of its major marketing weaknesses.

    A way by which LISP can benefit from both the reflective features of its abstract syntax, and from the ease of access of more "conventional" syntaxes, is to have first-class syntaxes, as in the GUILE system, where new fancy syntaxes can be seamlessly used, that are all canonicalized to SEXP, while SEXP can be pretty-printed to them.

    Another system, Dylan, started with SEXP syntax and concepts developed by Lispers freed of syntactic concerns, and then stopped using the SEXP syntax, to provide a cutting-edge state-of-the-art language, though a language that might not benefit anymore from the same freedom of thought as LISP provided (another more modest such Scheme dialect is Pico)

    Dialects

    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 and Scheme. Other notable LISP dialects are EuLisp, and elisp (the EMACS Lisp from the famous GNU Emacs editor). An interesting derivative is Dylan.
    Each of these languages has a section of its own in this Review page. Here is a quick summary:
    • Common LISP is an ANSI standard defined for industrial strength and it is just huge.
    • Scheme is a minimalist effort that tries to narrow the essentials of programming languages; it suffers from lack of standardization of features needed for programming in the large.
    • EuLisp is an intermediate between CL and Scheme, but it never took off.
    • elisp is a dialect that's not popular for a clean design or a good implementation, but because it is the extension language of the Mother-of-all text editors, EMACS.

    Lisp Machines

    [Is anyone willing to write a short critique of Lisp machines here?] See this Technical Summary on Lisp Machines

    Lisp Resources

    Critique

    • See Henry Baker's 1992 article: "Critique of DIN Kernel LISP"

    • Pros
      1. It's got a trivial syntax so you can focus on the essentials.
      2. There are standardized languages in the LISP family.
      3. LISP is widely taught in universities, and many advanced programmers know it.
      4. LISP allows for higher-order functional programming style.
      5. LISP also allows for imperative and OO programming style.
      6. Both interpreters and compilers of good quality are available, and new ones are easy to design, making development easy, and portability quite good.
      7. LISP is strongly-typed (type-safe)
      8. LISP has fully reflective dialects.

    • Cons
      1. The syntax isn't mainstream
      2. There are just too many LISP standards, none being perfect.
      3. LISP is not always so-well taught in universities, and many programmers were unduly disgusted.
      4. The pattern language for LISP lambda-expressions limited because of legacy non-orthogonality, contrarily to modern functional programming languages like ML.
      5. The way LISP inherits all its many impure imperative constructs from the dark ages makes them not orthogonal enough.
      6. There are so many good things about LISP languages, but it seems that you can never find an implementation that has all of those you want at once.
      7. The static type system is trivial.
      8. LISP gives no way to enforce invariants, which doesn't give good control on reflection.

    • Notes

      1. Because LISP is so powerful and versatile a language, several flavors of LISP have been used in a wide range of applications, from real-time industrial control, to space-born engines, to financial applications to extension language for text editors (Emacs), CAD engines (AutoCAD), arcade games (Abuse).

    • 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).


    LUA


    M4

    Short description

    m4 is a powerful (Turing-equivalent, 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).

    Implementations

    The only good implementation is GNU m4 1.4. Stay away from those completely broken commercial versions of m4 that UNIX vendors sell your for hard bucks.

    Semantics

    The semantics of m4 are just horrible: it uses back-door evaluation as the standard way to evaluate text; it has no safe way to quote arbitrary text; it has dynamic scoping. As a result, 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):
      • evaluation is based on unconstrained backdoor evaluation
      • you don't have closures or contexts,
      • you only have pass-by-value and dynamic scoping
      • quoting is syntax-based, not semantic based
      • you can't escape characters in a quoted text.
    • 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 so long...


    Mathematica


    Mercury


    MISA

    MISA is an interesting project to design the language of next century.
    also a Java demo around here.


    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 OCAML.
    • Other theorem provers like HOL, Isabelle...

  • 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-2).
    See The Oberon Reference Site (and 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 how to compile 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. It is THE language of choice for hacking programs oriented toward interfacing UNIX/Internet protocols.
    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.org; perl.com; perlWWW; Perl
    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.
    The principal advantage of Perl is that you can quickly hack up a working program to do text/binary manipulations that would be quite cumbersome using previous tools, that were either too generic, with a cumbersome interface to Internet-standard human-readable files, or too specific, unable to express more complex file manipulations. Perl allows you to do things in tons of different ways, so everyone can find one that fits his taste and thinking pattern.
    The principal disadvantage of Perl is that, allowing too many things as valid programs, it makes it difficult to specify and verify bugs out; the terse syntax that makes hacking quicker makes debugging slower. This is typical of traditional non-meta-programming development, where a compromise between writeability and readability is needed: only a meta-programming environment could help transform a valid program into a clean valid program of equivalent meaning.
    Another current disadvantage of Perl is that the current interpreter may be too slow to start and run to cope with the usage pattern of an intensive server. The Perl compiler being developped might alleviate this problem.


    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


    REBOL

    Carl Sassenrath's REBOL
    I've removed my original negative comment on REBOL, since it appears that the available papers are only tutorials for the programming-unaware, and from e-mail exchange, Carl S seems to have lots of good insight that doesn't appear on the page.
    More to come, hopefully...


    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.
    From their homepage: Sather is an object oriented language designed to be simple, efficient, safe, flexible and non-proprietary. One way of placing it in the "space of languages" is to say that it aims to be as efficient as C, C++, or Fortran, as elegant as and safer than Eiffel, and support higher-order functions and iteration abstraction as well as Common Lisp, CLU or Scheme.


    Scheme

    LISP

    Scheme is a dialect of the LISP family of languages. See the according information above.

    Description

    Scheme is a minimalistic dialect (some say a skimmed version) of the LISP language, in which everything is built upon the simplest constructs. It is the language that proved to the world the benefits of lexical scoping over dynamic scoping.

    Semantics

    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 Resources

    • Home Pages

    • Books and Articles
      • Both authors of this review agree that the best book about programming they read is Structure and Interpretation of Computer Programs (SICP), by Abelsson and Sussman, that uses Scheme as a language. (beware that the first edition used a slightly old-style subdialect of Scheme).

    • Courses

    • User Groups
      • The canonical place to find people interested in Scheme is the Usenet newsgroup comp.lang.scheme
      • The Scheme Underground project strives to build a complete computing system on top of Scheme.
      • The LispOS project.

    Free Implementations

    Here are notable free implementations of the Scheme dialect (and its variations). For more, or for commercial implementations, see the FAQ and above resources.

    • GNU has its own Scheme dialect, GUILE, "GNU's Ubiquitous Intelligent Language for Extension"
    • MIT-Scheme (aka C Scheme) and its efficient LIAR compiler lie here.
      It features: a very efficient native-code compiler (LIAR), an Emacs clone integrated to the Scheme environment (Edwin), a package system, first-class environments, etc.
    • Olin Shivers' SCheme SHell, scsh (pronounce skish).
      Based on Scheme48 a portable implementation of Scheme, scsh is designed to provide a complete Scheme-based system development tool for use on existing operating systems.
      Scsh may someday become a serious alternative to Perl, however, it still has to add these in their next release: fast startup, multithreading support, scalability of executable output code, 64-bit support.
      More on the newsgroup comp.lang.scheme.scsh.
    • Kali Scheme is another Scheme system based on Scheme48, that offers primitive for distributed computing.
    • The RScheme project led by Prof Paul Wilson at Texas University and and Donovan Kolby at TKG.
      It features: a byte-code compiler as well as a compiler through C, a CLOS-like (but single dispatch) object system, a real-time GC, a persistent store.
    • STk allows access to the popular Tk toolkit for X programming via Scheme. It's main interest is TinyCLOS, a port of CLOS to Scheme.
    • Rice University has built lots of tools for Scheme teaching and development: MzScheme, an interpreter; MrEd, the same interpreter bundled with a graphics toolbox and a built-in editor; and DrScheme, a Scheme development environment built atop MrEd.
    • Jeffrey Mark Siskind is actively developing Stalin an optimizing compiler for Scheme that goes through C, and produces impressingly good code (available by ftp).
    • Manuel Serrano's bigloo also compiles through C; it's got its own object system, a module system that allows separate compilation, many libraries to access the system, and so on.
    • Marc Feeley's Gambit compiler for Scheme.
    • Will Clinger's Twobit compiler
    • Oliver Lauman's elk (Extension Language Kit) is a very straightforward Scheme interpreter written in portable C. It's not fast, but it's very robust, easy to understand, comes with lots of cleanly designed straightforward extensions and system access libraries. It's easy to extend and to link into your application. It's sure not cutting-edge, but it's very stable.
    • Kawa is a Scheme for the JVM.
    • OScheme Objective Scheme from INRIA is an interpreter that easily interfaces C, and has its own object system; it is used in GWM, the Generic Window Manager for X.
    • Also: T, Hobbit, SCM, VSCM, Scheme->C, siod, rabbit, wxWindows, oaklisp, euscheme, pcscheme, meroon, fools, scoops, umb, xscheme, s88, softscheme, similix, pixiescheme, minischeme, libscheme, and every year more...
    • Pico is a Scheme dialect with more traditional syntax.
    • There are DAMN TOO MANY IMPLEMENTATIONS (well, half are not very active). And that's only the free ones! Every single feature you'd expect from a Scheme implementation is implemented in one of them. Just not all of them at a time! To many divergent efforts, not enough coordination in even the most trivial language extensions, etc. OUCH!

    Free software based on Scheme

    • DSSSL is a powerful document formatting system based on SGML and Scheme.
    • Functional Postscript takes all the Postscript drawing primitives, and wraps them with a real language, Scheme, instead of that Postscript hack.
    • An interesting example of how Scheme was embedded into a CAD framework
    • Aubrey Jaffer's SLIB standard library for Scheme.
    • Portable Object-Oriented packages for Scheme include:
      • Moostrap (a Self-like language with behavioral reflection)
      • Ken Dickey's YASOS (Yet Another Scheme Object System)
      • Of course, many implementations have their own object system, including RScheme, STk, OScheme, etc.

    Critique

    • See generic critique for LISP languages above

    • Pros
      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.

    • Cons

      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.
      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. Again, this plain sucks: 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.


    SELF

    Description

    SELF is a pure prototype-based 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.

    SELF Resources

    Free software using SELF

    • The Merlin OS project uses SELF.


    SIMULA

    SIMULA was one of the first "OO" languages (or is it the first?), down in the sixties. C++ is to C what SIMULA is to Algol.
    There are still people using it at DIRO in Montreal.
    The authors of SIMULA have since made a much greater language, BETA


    SISAL

    Sisal is a pure functional language that beats FORTRAN for number crunching, especially as its allows lots of automatic optimizations for parallel architectures.
    Unhappily, while focusing on number crunching performance, Sisal forgot many of those things that make functional programming so cool, so there's room for a better language than SISAL...

    Pointers


    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. Tcl has lots of success since it is a strongly-hyped language.
    Many real languages, including OCaml, Perl, Python, Scheme, and more, 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


    To Do on this page


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


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