The Philosophy Behind CULE

Q.  Why is CULE considered a Component Unification Language?     A:  Over the last two decades, no software development paradigm has proven itself more productive over the long term than Object-Oriented Programming (OOP).  This is because in contrast to traditional procedural approaches OOP offers true software reuse via the powerful concept of inheritance.  However, the problem with OOP was that in general the objects were only reusable within the languages that defined them.  There was no way to use objects written in one language from another.  Reuse was at the source code level only. The component movement on the Windows platform initiated by Microsoft in the early 90’s with its COM technology was designed to bring the productivity (through reuse) of OOP to a binary standard usable across languages.  However the promised catalogs of reusable software components that could be quickly snapped together like LEGO bricks to produce solutions to business problems never materialized. These early binary components simply lacked the all important "extensibility through inheritance" feature required to construct the truly reusable software needed to achieve economies of scale across projects. . The CULE language design attempts to change this by providing state-of-the-art component-oriented language/compiler features that allow binary components of diverse origins to seamlessly interoperate within a single CULE program.  CULE achieves this by representing all software components in a consistent manner within a program regardless of what type they are or where they come from.  In the case of external (i.e.; non-native CULE) components this necessitates a transformation from the component's native representation to one that is consistent within the CULE language semantic.  This transformation is accomplished through a combination of the language's powerful yet deceptively simple IMPORT statement, and compiler component unification plug-ins that allow the CULE implementation compilers to be extended by 3rd party plug-in modules that precisely define how the compiler should transform an external component type into an internal CULE entity.  Just as the object-oriented movement produced computer languages with formal object-oriented features to promote more productive development under that paradigm, the component-oriented movement also requires formal language support to simplify the Component-Based Development (CBD) approach to constructing software.  CULE represents the world's first component-oriented language specifically designed to support CBD.  Learn More... Q.  Is CULE really available Everywhere?     A:  No not yet. The only implementation of CULE currently available is CULE.Net targeting the .Net platform. However, CULE was very carefully designed to be portable across platforms.   As with any semantically rich language, CULE has its own runtime library to help implement that runtime functionality that is too complex to in-line when generating code for the target platform.  Each implementation of CULE will have a runtime library called CULExxxPILib.DLL where xxx is the implementation platform, and “PI” stands for “Platform Implementation“.  In the case of CULE.Net this library is called CULENETPILIB.DLL.  This library encapsulates CULE from the platform where required.  Thus the language can be defined in a platform independent way allowing it to be implemented anywhere a CULE compiler is implemented for it.  Q.  How can CULE claim to support both platform independence and rich platform integration?     A:  The traditional way of obtaining truly portable software by developing for the lowest common denominator, servers nobody's needs very well.  You end up with a watered-down product that fails to bring out the best of any of the environments that it runs in.  Today, what is required is a way to write portable code that still provides for the uniquenesses of each platform it runs in. The CULE language implementation embraces the philosophy that to write great software you have to exploit the richness of the environment you are running in when needed.  However, that need should not preclude the ability to write portable code for the vast majority of your application.  Therefore the customization of the CULE language for the various environment through natural extensions has been architected in such away as to never sacrifice the platform agnostic design goals of CULE.  Specifically, if you use a platform-specific aspect of a CULE implementation, the compiler for that platform will generate warnings indicating that your code will be “platform dependent”.  This allows you to clearly identify what parts of your application you are tieing to the platform and that will need to be looked at more closely if you port the application to another platform in the future.  Of course, if you are developing your application only for one platform, you do not want to see these warnings and can turn them off via a compiler switch.  When you use this compiler switch you are effectively declaring to the compiler that your application is intended to target that platform only, and that portability is not one of its design goals. The flexibility to write platform agnostic code in the general case, yet dip down and exploit the richness of the targeted environment as needed in a controlled way, is a major tenant of the CULE philosophy.