"Heresy is a controversial or novel change to a system of beliefs ... that conflicts with established dogma" (Wikipedia)

If you start working with Soplets you must be prepared to do away with some well-established beliefs you (or worse, some of your coworkers) might have with respect to a 'good' programming praxis:

Dogma #1: Thou shalt have no other gods paradigms before me

Object orientation is the holy grail of programming, and has written since its inception in the 80's a success story without parallel. It is universally regarded as the foundation of modern software development, and a synonym for well structured programming par excellence.

However, amidst all the euphoria, it might be overlooked that nothing is perfect in this world, and that also OOP has its limitations and shortcomings. In fact, we will discover that OOP cannot be applied with the same level of success to all aspects of software engineering.

One of the unwanted side-effects of OO programming is the lack of transparency. Objects exist just in the code, and are not (immediately) visible to an outside observer. An emphasis on thorough documentation as well as auxiliary tools, such as MDA (model driven architecture) or JavaDocs try to alleviate this issue, but they come with a high price tag, and do not really meet the evil at the root.

Another drawback of object orientation is the high level of freedom it offers. While in many cases, this level of freedom is a good thing, it also leads to a high level of arbitrarity (meaning there are potentially many solution for a given problem), which makes it difficult to write the code in the first place, and read it for the next programmer to come in the second place.

Last but not least, there are quite limited options to manage object oriented code during its life cycle with administrative tools. Again, MDA and other approaches such as RAD (rapid application development) tools try to get a hold on the code by repeatedly generating it, but they add considerable complexity to the code, while severely limiting the flexibility of the programmer (agile programming!), making it hard for the programmer to efficiently maintain the code over time.

Considering all these circumstances, it becomes clear that OOP is a very powerful and versatile paradigm at the hands of the programmer. But on the other side it has a number of drawbacks, which have to be addressed. The strategy of axiomatic programming is to limit the use of OOP to where it is really needed and makes sense and use a simpler, more structured approach in all other cases.

Dogma #2: Thou shalt put the translation into .properties files

One of the first lessons you learn when getting acquainted with Java (or any similar language for that matter) is to put translations outside the code into resource files, such as the (in)famous .properties files. While it is generally a good thing to agree on an established mechanism in order to encounter a common problem, it does not mean that you might not consider sensible alternatives to it. The original reason to put translations into resource files has been the requirement to support the translation process by sending simply structured files to the translators forth and back, simply because there was no better way of doing it.

This process has several drawbacks, namely:

a) the Semantic Entropy (no strong typing, no navigation support, no inherent orphan control),
b) sending documents back and forth is outdated,
c) merging problems during ongoing development processes

Soplets treat translation just as any other property of a semantic concept. There is no compelling reason to handle them in a special way - all the contrary. By embracing translations as regular Soplet citizens, they enjoy the same advantages and life cycle support (refactoring etc.) as any other attribute.

You can find a Soplet-based solution for translations at http://www.freenls.com, which supports round-trip engineering support for multi-language applications.

Dogma #3: Thou shalt put all entity data into the database

While it certainly makes sense to persist dynamic data in a (relational) database, not all entities are actually all that dynamic. Dynamic means, basically, that new values may be created or existing values might get changed between one release cycle and the next. For example, it is obvious that order data are created on a daily basis, but on the other side it is not very likely that genders of person (male/female) change all that often.

The chapter Static or Dynamic? discusses this issue in depth. For what Soplets concerns, one should be conscious that putting data in a database has a price tag attached, which must not be overlooked.

a) Semantic Entropy (again..!)
b) Onerous release management
c) More code (O/R mapping configuration, DAO access)
d) Strong typing (in many cases, static entities have references in the code)

The only drawback of Soplet based entities which is important to consider is the referential integrity, which is not possible with the identifiers located in the code.

Dogma #4:Thou shalt do all configurations in xml files

This issue is closely related to dogma #3. The programmer is often compelled to put things into configuration files, "in case things change", or for the sake of modularity.
 
Basically, configuration is nothing other than wiring things together. The difference to actual (Turing complete) programming is that it has no strong typing, no refactoring support and a high level of inherent entropy. Again, the question must be asked, how often the change actually happens, and what is the cost of having this kind of flexibility.

Soplet proposes to do the wiring the Soplet way, inside the code, and just put in external files that is absolutely indispensable and actually context dependant (such as the deployment environment, or parameters which must be changed during running course).

Dogma #5: Thou shalt not mess with the Java language

Soplets can be implemented (to a certain extent) with plain vanilla Java. If this is good enough for you, than do not read any further. However, if you want full-fledged Soplets, you will need the Sopity Java Extension, and leave the path of the pures and immaculates.

Sopity adds certain language enhancements to the Java language (such as enumeration/annotation inheritance or byte-code generation) which are not supported by the standard development environment. This means that you have to commit to a new, unproven, non-standard technology for the rest of the project's life span, which can be 10 years and beyond. And, to make matters worse, there is no easy way back if you (or one of your successors in charge of the project) will one day change your mind.

Having said all this, it is also fair to make a point in favor of a language modification, namely:

• Sopity allows for a whole new way of programming, and the changes made to the programming language are insignificant and painless in comparison to the benefits (as opposed to the proposed Java Closures mess or other insanities...)
• Sopity is open source, you will have access to the source code even in 10 years or more
• Last but not least, hopefully Sun/Oracle will come to reason and include at least the most pressing/missing features (hey, make sure they hear about Soplets!)