At the beginning, Pliant is a computing language.

Over the years, it evolved to a full development and computing system. It can run either as an application under your favorit Linux distribution, or as an application under Windows operating system, or as a standalone operating system named FullPliant.

It provides:

• a complete development environment including the dynamic compiler, debugging an profiling features
• database engine
• a web friendly user interface graphical toolkit
• client and server side implementations of several standard services such as DNS, SMTP (mail), LPR, HTTP, VNC
• some basic desktop oriented applications such as file browser, text editor
• it will contain basic desktop applications such as word processor, spreadsheet, drawing tool, photo editing tool

The answer is a little bit longer than one sentence, so let's go step by step.

The Pliant goal is to be an high quality tool for companies wanting to build an internal value added application. On one side, the two major issues faced when doing internal use targeted development are:

• limited ressources (you can't share the cost among a very large number of users)
• inconsistencies mostly freeze the application after a shorter than expected amount of time, so make productivity gains nearly stall earlier than expected and the three most common (nearly universal) mistakes are:
• poor analyse of the needs and formulation of the specifications to meet these
• too much bonus assigned to tools that are close to what people already know at the expense of serious evaluation of their effective suit to the needs and real capabilities on the long run aspects
• deap over estimation of the ability to adapt existing applications and tools to new needs

On the other side, let's describe various aspects of computing tools:

• learning time
• features, that is immedialely available possible services
• code availability and size, that is cost to make small adaptations
• concepts and design, that is possible extra services before hiting the need to restart from scratch wall

So the game is: how to optimize at selection time the weighes of various aspects of the computing tools to best cope with internal value added development constrains, and avoid common mistakes as far as possible. What we can note immediately is that weighing mostly the two first aspects, that is basic features learning time and features set, just means reasoning as a end user instead of as an application achitect, so is a reliable way to end well in the middle of the most common mistakes field.

Let's end this set of initial remarks with expressing two very common aspects of well known mature applications:

• they tend to be a lot of features added on a many years old weak design and set of concepts
• they target the end user rather than integration in a value added application, I mean the scripting tools tend to be both exotic and weak

Now all the foundations are led down that enable us to express the reasoning leading to Pliant rewritting all standard tools and services from scatch as opposed to interfacing aready existing more mature ones. The guide line is that we face right from the beginning the hardest part of the internal development, which is to enable to keep productivity gains running high for long, so that our initial goal is to prevent the application to mostly freeze too soon.

Freezing can come from two different aspects:

• the application level of inconsistencies reached the point that makes any change painfull
• the application reaches some limits of the tools it relies on

About the internal inconsistences of the application, the answer is purely human: you need a good achitect for you application, and no tool will replace it. Please notice that this is also the only serious answer to avoid the first of the three common mistakes, which is poor analyse of the needs and formulation of the specifications to meet these.

As far as underlying tools are concerned, we can define three different usage levels:

• no modifications
• small modifications within the initial design
• complete rewrite in order to go behond initial design limits Each usage level brings an order of magniture more capabilities that the previous one, so will enable productivity gains run high for much longer.

The weighes you assign to various criterians at tools selection time is very different if your target level is no modifications or small modifications within the initial design. If your target is no modifications, then you will give high weighes to easy to learn basic usage of and features rich, so that well known large existing tools will be selected. On the other hand, if you target small modifications within the initial design, then highest weighes will be assigned to the other criterians because having a set of small and consistent tools (a single language, short open source code) will make the learning curve to truely benefiting of the ability to make small changes in the underlying tools shorter, and a strong design grants that the wall you will hit at some point anyway that would require a complete rewrite of the underlying tools stands as far away as possible.

In very fiew words, Pliant tools are designed to be easily adapted rather than used as is. If you look at them as an underpowered replacement of large mainstream features rich applications, then it's probably because your creterians weighes are still matching the end user ones, which is also the no modifications of the underlying tools development usage level. The main problem in such a situtation is that you are very likely to fall on the most common mistakes listed at the beginning, so see the productivity improvements brought by your internal application stall earlier than expected.

Most unaware managers will say: let's start with using the underlying tools unmodified, in order to get something usable soon, and we'll try to go futher later. Now, on top of this, the technicians will add: since the boss expects to see something running soon, let's start with the tools that are closer to what we already know. This is the starting point you must not select because the failure of the application to bring high productivity improvements on the long run would be mostly granted right from the beginning. Of course, when the application starts that way, we can assume the lack of competent and empowered architect.

Computing is a hard field: most of the time, changing the tools your application relies on implies restarting the all application from scratch. Many people will want to tell you that it's false and that the new release of the tool will solve it nicely and smoothly, but this is just marketing. Once again, the most common and close to universal mistake about software evaluation is deap over estimation of smooth evolution capabilities as opposed to restarting from scratch.

What you need is:

• a good achitect
• a team that is competent enough to make small modifications on the underlying tools (this implies using a set of consistent, not too huge open source tools)
• selecting underlying tools with strong design rather than features rich