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.

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.

Summary:

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

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

... but its overall design is really weak:

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)

Pliant is simply a much better designed answer to C shortages.
What it brings in its design:

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

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.

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:

Huge code means buggy code

They still succeed only to cover mainstream users needs

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:

Huge code means large sets of bugs

They still succeed only to cover mainstream users needs

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:

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.

For server applications, the main issues are:

Standards compliance

Stability

Flexibility

Scalability

In the mainstream we currently have two main lines:

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.

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:

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.

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:

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.

and some serious problems:

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.

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