[TYPO3-dev] TYPO3 heresy: what about "selling" pro extensions?

[Jigal van Hemert]

Jochen Rau wrote:
> On 25.04.10 16:55, Jigal van Hemert wrote:
>> TYPO3 probably wants to be reliable, stable, feature rich (buzzword?),
>> etc., but certainly not hip or fashionable.
> 
> My point is, TYPO3 should be reliable, stable, feature rich as this 
> enables people to communicate. *And* it should be hip and fashionable to 
> inspire (more) people to share.

Is "coolness" a necessary property of a CMS? In software "coolness" 
often means showing off what you are capable of. For example animations 
in the backend can help usability (it makes it easier to see what you're 
doing), but they shouldn't be there just because it is possible to 
include them.
If TYPO3 becomes a CMS which excels at stability, reliability, 
usability, etc. people will share their experiences with others. "Cool" 
features first become uninteresting after a while and in the end they 
become annoying.

> The word "paradigm" is common ground in context of software development 
> (http://en.wikipedia.org/wiki/Comparison_of_programming_paradigms). I am 
> pretty sure that many people in this context understand the term 
> "programming paradigm". It isn't a buzzword.

As we will see later, this is just a fancy word to make more of 
something that is not a revolution. Look at the list of "programming 
paradigms" in the article. Most are not revolutionary, but logical 
progress of language features and programming styles.
The idea to give variables a scope and give a section of the code a name 
(plus a few other features) resulted in the "procedural paradigm".

In the end the steps needed to complete a task must be performed in 
sequence. Any newer paradigm has only made the sequence longer, but also 
organized it in groups of actions which are often easier to understand 
and maintain.

> In short: it is mixture 
> of Imparative and Procedural Programming Paradigm [1]. As the core code 
> basis of TYPO3 grew bigger and bigger it turned out that these paradigms 
> lead us to a situation where it is very hard to maintain this code 
> basis. And it is very hard to add new features (just try to refactor 
> tcemain or try to implement new features to tceforms_inline).

I don't think that a paradigm (programming style) is the crucial factor 
here. The current situation is that the original code and API has been 
expanded and modified while still trying to keep the original API and 
behaviour. Combine this with loads of hooks and XCLASSed classes and 
you'll end up with a situation where backwards compatibility dictates 
the structure of your code.

All code made with Object Oriented or any other 'modern' paradigm still 
has to execute code in sequence. If the sequence becomes too long it 
might be solution to refactor it and divide it in pieces which can be 
maintained more easily.
This will however change the internal structure of the code. With all 
added hooks and taking XCLASS versions into account there is hardly any 
room left for structural changes.

> Now, TYPO3 (and I mean the community including you here) is facing a 
> "paradigm shift". The "new" TYPO3 will be based on the Object Oriented 
> Paradigm (OOP) [2] (It makes no difference here if you use FLOW3 or the 
> Zend/Symfony/... as Dmitry suggested). It uses software objects to group 
> data and functionality together in a very meaningful way. This will lead 
> us to even more techniques like Domain-Driven Design, Dependency 
> Injection and others to make the most out of this (not so new) paradigm. 
> But all these new concepts are no buzz words (at least for those who 
> already cleared the hurdle).

New concepts? Domain-Driven Design (DDD). I've spend some time reading 
online articles and the only thing I read is that you have to look at 
the real world situation and the ways things interact to build a model 
you can use in your code. (I leave out the theoretical plans on how to 
implement this). Isn't this logical? The only relation with programming 
styles (sorry, "paradigms") is that the features of the tool 
(programming language) may limit you in how to make code in such a way.
Is the solution I've built any good if it doesn't follow the structure 
of the "domain" in which it has to function?

To me this is another case of attaching a label to a (more or less 
obvious) method/technique and talking about it as if it is a 
revolutionary concept.

Dependency Injection. In short: you don't make the containing object 
responsible for its sub-object, but you give it an instantiated 
sub-object to work with. (Real-world example: the car doesn't create the 
engine; an existing engine is passed to the car to use).
Haven't we all done this already in situations where this was simply the 
most logical thing to do?

>> The problem with buzzwords is that the words are being used in
>> situations where they are not appropriate and after some time they lost
>> their meaning.
> 
> Again: "programming paradigm" is no buzz word. I used irony here not to 
> loose humor and marked it with the appropriate smiley.

It has become a buzz word the moment it is used not as a unambiguously 
descriptive term, but to sound impressive in the process of marketing 
something else.

We've seen it in the past: DHTML, XML, AJAX and recently REST(ful) and 
all the other words/abbreviations which have a limited meaning but were 
blown completely out of proportion and context to market a product.


-- 
Jigal van Hemert
skype:jigal.van.hemert
msn: jigal at xs4all.nl
http://twitter.com/jigalvh