Coffee Space

Why?

Because PHP is a hacked piece of rubbish, it doesn’t take a genius to work that out. If you would like a better explanation please visit another site - this is not where this site wants to concentrate it’s efforts.

Lessons Learned

The following is what has been learnt from the PHP language:

• Don’t be afraid to fix broken code. It’s much more dangerous to the overall design to leave it there and ultimately the system future.
• If the design is wrong - change it. Backwards compatibility can be handled in the compile/version stage. If somebody is really bothered, they can stay in a really old mode. The point is - it’s their choice.
• Compatibility of web technologies should be considered. Too many web pages don’t load correctly because a case was missed. It’s about time programmers no longer had to worry about this in their Server/Client side scripting. If this cannot be fixed, it’s truly our failure to web users.

Concept

So the basic concept so far is that the server is the main controller and doesn’t have to be all the fast. This could be written in Java and have several compiler in it, read to be unpacked per the operating system it’s on. It then compiles each one of the pages, which consists of taking the BoPLE code files and compiling them such that the normal web code stays as is and is just printed at the correct times. The BoPLE code (in <?BoPLE> tags)is then compiled using implemented C++ methods.

Important parts of code:

• Version = _._._._; - Tells compiler which methods this code was designed for. Anything other than bug fixes will result in a newer version of methods. If no version is defined, the newest is assumed. This will allow to go forward and act as motivation to keep sites up to date. Where possible backwards compatibility will be kept where it doesn’t affect operation or security - which may result in warnings otherwise. The version is defined by Major, Minor, Patch and Build. A coder may not want to accept changes that come in and may only ever want to support a very specific version. This is perfectly valid and understandable.
• S.* - Defines when a method is intended to be run server side. These will be pre-processed where the input is pre-defined. These follow a JS layout but may not be used as JS. This is directly converted to C++ hence the fundamental design is different. Speed shall not be compromised to bring the style towards JS.
• C.* - Defines when a method is intended to be run client side. If there is any possibility these methods may not work, an “exception” is reported to be thrown where the programmer must make a choice about to handle it. It’s perfectly valid to ignore such an error - but not advised. At the very least the programmer can not claim to have not been warned.
• Ignore.add(_); - Allows different warnings to be ignored, such as JS support. A programmer may say something like “I don’t want to support IE or Safari” - which is understandable. By default all support will be on as standard.

After the code is compiled, the user simply makes a request to the server and the mini-program is run. The output is then read by the server that ran that sub-program and spits this back out to the expecting user - who will be pleasantly surprised at how fast their page arrived.

Continuation

I guess some time in the future there will be an implementation of this. I have a feeling that businesses keep you really busy working on things that earn them money so that you don’t come up with better ideas… Or perhaps cause and effect is the wrong way around!