Last check on 2001/9/13

Pliant is basically three things:

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

As you can see, the rule here is flexibility.

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.

There are mainly two very different ways to evaluate a language quality:

  • The positive quality measure: the quality of a language is measured by its ability to solve the problems that it is especially designed for.
  • The negative quality measure: the quality of a language is measured by its ability for solving the problems in the worst possible field of problems.

In other words, if for each application field you give a quality measure to a language, then the positive quality measure means that the overall quality you credit the language is the maximum of the various measures, and the negative quality measure means that you select the minimum measure.

Now what's very interesting is that none of these measures is wrong or even worse than the other. They lead to very different results and it might explain why various people have strongly different point of view about the quality of any given language. Basically, it's the kind of programs you write that will determine which language you end up with, subconsciously. If the programs you write most of the time belong to any specific field, then you will probably end with using the positive quality measure. On the other hand, if you are facing problems in completely different fields over time, then you will probably end with using the negative quality measure.

What you are doing most ... so end thinking ... and your best language is probably
Quite similar programs positive quality a logical programming language (the one you will select depends on your specific application field), or C if you do low level programming
Very different programs negative quality best is Pliant, second is C++, third is C

The history of computer languages shows that, up to now, success is rather related to negative quality measure, whereas feeling is rather related to positive quality measure. Also, it's hard to say if the success of languages with high negative quality is due to the fact that most people are writing very different softwares, or to the fact that there are much fewer of them (so development power is more concentrated). A language with a good negative quality measure is very general, whereas a language with good positive quality measure tend to be specific (so there will always be a lot of these).

Note: the Java and Visual basic special cases .

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:

... but its overall design is really weak: Pliant is simply a much better designed answer to C shortages.
What it brings in its design: Now, the practical consequences are:

So, Pliant:

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.

Also note that the ideal of small application source code dovetails nicely with the fundamental ideas behind the design of the language - namely to construct a elegant core around which advanced features can be added as modules.

There are two major problems with such a development model:

If a free software application becomes a monster then new users loose the ability to dig into the code and make changes without spending large amounts of time reading the code.Roughly speaking, the free software becomes closed.

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:

Now if the source code of a free software becomes huge, then one looses the ability to dig in the code and make changes with a reasonable amount of work. Roughly speaking, the free software becomes closed.

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

Here is the Pliant built in server applications list:
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 a very safe database engine for the dynamic pages.
DNS server names service.
SMTP/POP3 server mail service.
FTP server old fashioned files sharing.
Secured proxy secured upload, download and remote administration.
Backup system advanced multi CD backup system.
Here is the Pliant built in end user applications list:
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 web site (a forum is also a kind of smart mailing list).
There are mainly two kind of Pliant built in applications:
For server applications, the main issues are: In the mainstream we currently have two main lines:

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.

Pliant built in server applications provide a clean and compliant implementation of various standards (such as HTTP, SMTP or DNS).
This single sentence truly means: So, this excludes from the implementation all sub features that are not necessary to provide the service though

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.
Here is the Pliant built in server applications list:
Applications What's that for
HTTP server creating web sites or intranets (contains a .page dynamic pages format which is much more powerfull than PHP)
Database engine make the web site dynamic.
FTP server old fashioned files sharing.
DNS server names service.
SMTP/POP3 server mail service.
Secured proxy secured upload, download and remote administration.
Backup system advanced CD backup system.

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:

and some serious problems:

Here is the Pliant built in end user applications list:
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
Spreadsheet not available yet
Word processor not available yet
Configuration manager Monitor, configure and update computers.

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

The key idea to understand Pliant built in applications design is the feature/code size ratio. Pliant language enabled to make it an order of magnitude higher. The problem with 'classical' applications is that they all badly hurt one of these walls:

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.