Last check on 2001/9/13
Anyway, you should always keep in mind that for any of your applications,
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:
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.
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:
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.
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:
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:
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.
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.
About scalability: abc
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:
Conclusion: Pliant currently provides a rather complete built in Internet suite, but is not yet a desktop suite replacement.
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 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.
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: