Last check on 2001/9/13

Anyway, you should always keep in mind that for any of your applications,

• at development time you can choose to rely only on the Pliant language, or also use (and customize) Pliant provided applications,
• then at deploy time, you can choose to run your application on your favourite operating system, or on FullPliant operating system.

On the concrete side, one could first think about the Pliant language and its low level libraries as a replacement for GCC (a compiler), glibc (low level libraries) and guile (a high level language for scripting within applications).

On the concepts side, you could first see Pliant as a C extension.

Let's start from C, which is best described as a portable assembly. It's main quality is that it is very close to hardware design, yet fairly portable, so very efficient in all applications. It is also fairly simple. This is what made it the first language with a high negative quality measure. On the other hand it's low level, so C code tends to be large and buggy. This limits its quality. When developing a project in C, you will not face a crisis because one small part of the project is outside the languages' reasonable usage scope. But the overall cost (esp in the beta testing stage) will be high because the language is low level.

Then came C++ which tried to address the shortfalls of C in a very conservative way. By conservative, I mean that C++ took every options to gain fast acceptance:

• the syntax is an extension of C
• the language contains only two built in new high level features (classes and templates) which enable it to use all the existing tools (linker, debugger, profiler) with only a few modifications

• the syntax is really ugly
• the 'template' feature is not consistent with the classical static compiler model and taxes classical static linker design
• the code generator capabilities introduced by templates are rather trivial (looks more like a preprocessor) and not that powerful
• using high level features impacts the execution speed (returned data is always be copied and new classes cannot advise the optimizer about non trivial optimizations)

• brand new clean syntax (or rather an extension of Lisp syntax with operators and indentation that eliminates the need for most parenthesis)
• the compiler is dynamic (it can compile extra code at execution time or, if more meaningful for you, it contains an 'eval' function)
• reflexivity in all areas that enables you to extend the parser, extend the high level compiler (expressivity), add various code optimizations (e.g. automatic transparent rewriting of the program by advanced libraries) and even change the even low level code generator (low level code efficiency).
• clean module notion (impacts both syntax, semantic and code generation)

• it introduces a reflexive high level compiling stage, that you could think of as typed Lisp, and that brings much more expression power: instead of the C++'s two high level features, Pliant lets you add the one you want though standard libraries that extend the high level compiler.
  You can view the high level compiling stage as a very powerful code generator (what Lisp truly is), modelled on typed Lisp.
• it provides optional automatic memory management by reference counting (and probably garbage collection in a future release), without any drawback on the low level execution capabilities. Pliant provides the highest possible (as far as I could design it) execution level that adds no constrains on the low level parts of the application.
• the cost of using high level features is reduced as libraries can add new optimizers to the compiler that will transparently rewrite code to get better efficiency.
• Pliant can also be lower level than C, what C++ cannot be (the inline assembly is standard, and you can even define new assembly instructions).
• you can get rid of 'make' and 'configure' like tools since the program can directly check its environment then compile accordingly.

So, Pliant:

• can be much higher level than C++, or even lower level than C
• is a nice scripting language (the syntax is clean so you can write useful applications in very few lines; there is no need for a make file or command line parser).
• it can be a powerful macro language within your application. There is an 'eval' mechanism and there is no need for a glue API since the dynamic compiler could use C headers and application data can be accessed directly).

About the syntax: A superficial analysis could lead you to think that C++ using a C syntax extension is a great advantage when upgrading an existing application. In facts it's not.
In order to get significant benefits from C++'s extra capabilities the application has to be completely rewritten because C is based on the 'function' notion whereas C++ is based on the 'class' notion. If you deeply change the application then switching the syntax for a much cleaner one is little extra work.
On the other hand, if you plan to keep the old code as it is then Pliant's different syntax is not much of a problem: you will turn the old application to a DLL, and then Pliant can use it directly. The second advantage of C++ keeping C syntax is that it can read C headers (functions prototypes and structure definitions). But Pliant's POSIX port proved that the Pliant dynamic compiler is powerful enough to read this information by driving the C compiler itself.

	Summary: Pliant tries to bring as much expression power as possible without impacting low level code performance. In order to do so, it is built as a minimal language framework where most the advanced features can be introduced in modules. The minimum is a dynamic highly reflexive compiler that handles the program a bit like a typed Lisp. So Pliant ends up being something in the middle (nearly both in fact) of a procedural low level language and a logical high level one.

Now that we have studied the Pliant language by comparing it with other languages, let's talk about it from a more conceptual point of view: The key idea about Pliant's design is that it is an attempt to gain as much extra expression power (high level programming) as possible without impacting low level efficiency. Now, after several years thinking, I have concluded that the best design was not to try to add this or that high level wonderful feature, but rather to concentrate on defining the minimum set of rules that several languages should agree on to be able to work nicely altogether in a single application. This well defined minimal set of rules became the Pliant core compiler. Then maximum expressive power can be introduced through maximal reflexivity, so that we gain the ability to define any high level feature as a module (provided that it doesn't break the minimal set of rules). And the good news is that we have known a very good model for high level reflexivity for a long time: typed Lisp (what is missing from Lisp is the reflection at the code generation level and the ability to get to low level when required). So, back to language quality measures. The set of minimal rules grants Pliant a high negative quality measure (nothing can reduce the ability of low level code to be efficient), and, together with the maximal reflexivity, it can also bring a high positive quality measure in most areas as it's very likely that the few extra advanced and specific capabilities can be added as a module. This makes me call Pliant a language framework.
Java special case (again)

Conclusion: If you are looking for a language with a high negative quality measure then Pliant is for you because its design is so much better than C++.
On the other hand, if you are looking for a language with a high positive quality measure then Pliant is probably not the best one for you. The best one depends on the kind of applications you are programming, but it is likely be close.

For extra details, see Pliant language design more technical chapter.

Under Construction

The single most important feature in Pliant applications is the the code is reasonably short. Let me explain why this is so important.

With closed source, no advanced end user is able to improve the application so the software provider will try to provide as many features as possible in order to satisfy the maximum number of users and so get the largest possible market for the product. As a result, a monster application is the natural evolution for closed software.
On the other hand, since the end user is able to modify (or fix) the code of free software and allowed to publish the changes, they can share their special features (and split the cost of implementing then) with the very few other people around the world having the same special needs. Anyway, this wonderful feature stands only as long as the source code is not too long or complex so that the cost for digging in the source remains reasonable.

Free softwares are facing a dilemma: popularity or flexibility
Firstly, most end users currently have no computing culture and one explanation is that the computing field is still young, so most end users are not able to customize any application, even if the code is free, short and clean. As a result, if the application is targeting popularity, then it has to behave like closed software and provide as many as possible built in features. By doing so, it prevents customization and so looses true flexibility (but will get more users).
Secondly, nowadays most free software is linked with commercial companies which fund them, so the pressure is high for them to target popularity rather than anything else.
As a result, applications today end up as monsters (both free and closed) and so fail to cover anything other than mainstream needs.

There are two major problems with such a development model:

• Huge code means buggy code
• They still succeed only to cover mainstream users needs

	Pliant's built in application are reasonably short so that you will truly be able to customize them.

The key difference with free software is that the source code is available, and that you are allowed to modify (or fix) it (so that it better solves your needs), then publish the changes so that other people interested with a new feature can share the effort with you.
On the other hand, since an advanced end user will not be able to improve a closed application (no source code available), then these tend to provide as many built in features as possible in order to cover the largest possible number of users needs. There are two sever problems with such a development model:

• Huge code means large sets of bugs
• They still succeed only to cover mainstream users needs

In the desktop area, we currently see

One assertion with Pliant is that we don't care about interfacing with mainstream products: we care about interfacing with standards. It may look disappointing at first, but it works much better on the long run.

Now the main problem I currently see with free softwares is that they try more to be apple to apple free clones of mainstream closed applications rather than benefit from the intrinsic possibilities of a free software. So they also end with huge code so that the end user looses the ability to customize.

This is even more true nowadays that many free softwares have financial dependencies with commercial organization that will always make pressure so that the software be

The conclusion is straight forward: weather free of closed, huge code means the application will fail to cover anything but the mainstream needs.
Please also notice that the reasonable sized code at application level is very consistent with the language design which is rather than provide a new language with one or two built in wonderful features, just try to provide a clean tiny language where most advanced features can be added as modules.

Nowadays, most users are currently mainstream entry level users because computing is a fairly new field, and most people lack 'computing culture'. So one has to choose: either you expect large number of users, so will have to target the mainstream entry level user, or you will get very few users. What we currently see is that many free softwares are now linked from the financial point of view to distributions or other commercial companies. The main problem I currently see with free software is that they try too much to clone closed softwares.

On the other hand, one may try to provide a monster application that covers all users needs so that there is no need for the end user to dig in the code. Pliant applications target medium scalability: if you want to get top numbers, you will need to use Unix ones where the. On the other

• server applications: One could see these as the top level of the operating system. They provide high level services, but the end user will generally not interact directly with these.
  Examples are the HTTP server or the STMP/POP3 mail servers.

• end user applications: These are what the end user sees and know that he is using.
  Examples are a word processor, or the mail agent.

• Standards compliance
• Stability
• Flexibility
• Scalability

• The Unix line: very conforming, and containing all possible extensions.
  The problem is that the code of the mainstream Unix implementation is always growing to an unreadable, and sometime even close to an unmanageable status.
  Sometime, it even leads to the standard to follow the implementation (DNS following bind) and more frequently the standard to provide details that are implementation issues.

• The Microsoft line: non conforming, changing to incompatible all the time.
  This company tends, at any time, to make it's non standard implementation of the protocol, according to it's immediate needs and without enough thinking. The great problem is that it does not work well with other implementations (what they seem to like in facts), and even with Microsoft implementations built at different time (what currently prevents them to hijack the server fields thanks to the monopoly they have on the desktop field), so it could be summarised as an always prototype implementation.

  NB: Microsoft is not the only big player, and also not the biggest one, but among big players, it is the one with the most extreme attitude.

Pliant tries to go a third way:
For each standard, I try to understand what's truly useful in the standard (what service it truly brings) then provide a short and compliant implementation of this central part.
Then I spend most time redesigning rather then extending the code. Restarting from scratch is also something I do often.

• The code is short so you can truly read it (whereas you will hardly read the source code of Unix (too long) or Windows (same, but also not available) mainstream applications.
• Pliant does not try to provide a complete implementation of the standard. Most standards have evolved over time and the mainstream Unix implementation is generally very complex because supporting all possible features have plugged in over time, without restarting from scratch, what is always required at some point to get back to clean design.
• Pliant rather tries to provide a clean way to use the standard service in a conforming way.

About scalability: abc

	Pliant is an Internet suite: it contains everything you need to start your Internet site, including database, forums and mail support, and much easier to use dynamic pages support.

	Within Pliant built in applications, the graphical toolkit is the HTTP server.

End user applications are tightly linked to the user interface. It is so much true that they are immediately associated to the graphical toolkit they rely on (there used to be the command line, then Macintosh Windows OS/2 and Motif, and now we see the new KDE and Gnome applications. Let's say it right from the beginning: the graphical toolkit for Pliant built in applications is the Pliant HTTP server.

It's quite surprisingAnyway, HTTP/HTML has two key advantages:

• The HTTP dialog model is quite flexible (a set of ASCII lines followed by a blank line).
• There is no significant difference between a program and a document, so you can very easily have explanations in the middle of a dialog, or an active button in the middle of a document.
• It works very well on a wan.

• The HTTP protocol had been designed to upload or download documents (GET and PUT instruction). The URL options, and then forms (introduced with the POST instruction) are poorly designed. Basically, we should have XML everywhere, and the options in the URL and forms should be replaced by an XML document bound to the query. (the ideal protocol)
• The languages in the browser (Java and Javascript) for making client side computations and both young and poorly designed.
• HTTP lacks a clear way for the client to provide just a few informations to the server (the result of a user action), and for the server to send the client an order to move backward, modify part of the current HTML page or part of the images.

Conclusion: Pliant currently provides a rather complete built in Internet suite, but is not yet a desktop suite replacement.

• If the application is written using a general purpose low level language (with high negative quality measure, typically C or C++) the the code soon becomes a monster because of the lack of expression power of the language (typical GNU application).
• If the application is written using a language with high positive quality measure, then it grows poorly because extensions bring new constrains that deeply stress the initial chosen language design (often found in one man projects that start fast an look promising at early stage, but then fail to get final).
• If the application is very modular (involving several libraries potentially written in different languages), then mixing soon becomes the hard part (the Pliant very carefully designed minimal rules set is my solution), and wrappers the longest part of the code.

If you look at Pliant current code, some is very low level (strings functions, or even more floating point functions), and some is very high level (dynamic pages for configuring Pliant), so that you could think that they belong to different language, but nowhere you will find glue code in the middle: each Pliant function can directly and straight forwardly pick the information it requires from the rest of the Pliant word. This is what the reflexive dynamic compiler with minimal set of or rules brings at application level.

Now there is a second important rule about Pliant built in applications: I designed these to be truly productive for true applications, but not to be mainstream. I mean that for non of these I plan to add more and more features until it can satisfy all potential users. I'm rather targeting an advanced student: the code is not over simple (the design is strong and scales well), but kept short (at the expense of various easy to implement extra features) so that it can be studied in a reasonable amount of time.The general idea is that I prefer various people to customize the code than a single central code repository (customizing is very easy with Pliant since compiling from source is transparent, so applying small changes is trivial).

Here is the Pliant built in applications list:

	Pliant built in applications key design points: The code is short Strong design Reasonable scalability Limited set of features Format is HTML+ User interface is HTTP/HTML

Server applications	What's that for
HTTP server	creating web sites or intranets (contains a .page dynamic pages format which is much more powerful than PHP)
database engine	make your site dynamic
FTP server	old fashioned files sharing
DNS server	names service
SMTP/POP3 server	mail server
secured proxy	remote administrate your site safely

End user applications	What's that for
web mail	access your mails from anywhere through a simple web browser
forums	easily add forums to your site

The client point of view: All you need to access Pliant applications is a web browser. This is a clear design choice. Also the web browser is far from a perfect user interface, it proves to be much more open. So I have decided that all built in Pliant applications will use HTML/HTTP as their native interface.
Also some contributors can provide KDE, Gnome or Win32 wrappers, or much better a single toolkit accessing all three transparently, and applications using one of these. On my side, at some point, if I get too bad results from interfacing Mozilla using DOM, I might develop a Pliant browser, and this one should work under Linux frame buffer, X11 or Windows API. Also I'll try to avoid it, and preferably develop a Pliant proxy which you could install one per site and would optimize the traffic between your lan and the Pliant Internet servers.

under construction

All Unix embedded server applications configuration files are generated automatically according to the content of the Pliant computer configuration single file. More over, the settings in this single files can be updated using the Pliant web administration system so you wont notice many differences with Pliant built in server applications, except that files sharing rights mechanism is much less flexible than Pliant one.

Extra services provided through FullPliant Unix embedded system:

Embedded server applications	What's that for
Files sharing	Share files with other Unix, Windows or Mac systems
Printing	The classical Unix printing queue.