|Bracing against the wind|
Thursday, March 05, 2009
1. Functional programs read like a story. First do this, then that, etc. Framework programs read like a "declaration of purpose". But it can be hard to figure out how that declaration translates to a sequence of actions.
2. Over-encapsulation. "Framework" systems encapsulate everything to the point where a huge part of your time as a developer is spent editing framework configuration files. Thus they tend to be *extremely* path, system and configuration dependent. So, when you update your Tomcat version or confiuration .... everything breaks ungracefully, and it's very difficult to determine what's needed to get it running again. Again, it's a declarative system, without any clear sequence leading from "code to html".
3. When it comes down to "How to I just get it to put the letter X on the screen at point Y"...the framework guy says "you have to override the class by defining it in "/framework/templates/local/hard-to-determine-path.class". And there's no way, by looking at the web page, to see that's what needs to be done. You need to look at framework documentation and configuration to determine *where* everything is declared, and what's needed.
4. The SMX developer says, "look for point Y in the code that outputs the html, and put an X right there". The Perl developer who refuses to "over-object-orient" can usually say the same thing (although perl *allows* you to mess this up). The locations of things are clear because SMX is a *context oriented* language, not *object-oriented*. SMX is constraining to the point where you *have* to write code such that it's possible to "backtrack" to the origin of any given output string. Bascially... you can't obfuscate things unless you're doing it on purpose.
[View/Post Comments] [Digg] [Del.icio.us] [Stumble]
| Bloghop: | Blogarama | Technorati | Blogwise