Hi Andreas,
Please have a look at this very interesting programming language: http://en.wikipedia.org/wiki/Brainfuck
.
Even very minimalistic devices are supported !
++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++
++++++++++++.>.+++.------.--------.>+.>.
Rudolf
Richard Frovarp schrieb:
Andreas Hartmann wrote:
I think we should seriously consider migrating to another
platform. I'm sure there must be good reasons that most CMS's are
written in PHP anyway. There are some quite powerful frameworks
(Zend, PEAR) to implement complex web applications. Combined with
a mature JavaScript library like Dojo or YUI we could create a
productive system in an acceptable timeframe. I think moving to
PHP would also help to increase the potential user base.
BTW, recently I did a project using .Net, and I was very
positively suprised and think it would be a viable alternative. We
could finally get rid of those endorsed libraries issues and of
all our legacy code.
Maybe there are other platforms worth considering? E.g. Ruby on
Rails?
I think we're missing the bigger picture here. Servers are coming
with more sockets and more cores. It's now about concurrency, not
how fast an individual thread runs. It is way too tough to do this
in an imperative language. For this reason we should switch to a
functional programming language.
Very good point.
At the top of my list would be LISP. If something as powerful as
Emacs can be written in LISP, I think it would serve us well. In
fact, if you issue a C-x M-c M-cms, it will generate the skeleton
of a CMS in LISP for you. If you tack on a 1, that will get you the
Clojure derivative, which may be a little more modern, and get us
away from all of the parentheses.
Thanks for those pointers, I'll do some prototyping asap!
I think the strongest option would be to write it all in XSLT.
Think about it, it's a Turing complete functional language. We get
concurrency and the ability to run on any platform with an XSLT
engine! It could then run under Java, .Net, Ruby, Python, or PHP.
Sadly, I do not know if there is an XSLT engine for PL/1.
I totally agree, XSLT would be a very good choice. Since we already
use XSLT for the presentation layer, using it for the business logic
as well would tremendously reduce the learning curve. Recursive
document() function calls will be a great replacement for Cocoon's
XML pipelines.
Remember the discussion whether to organize the codebase according
to file types or according to functional modules? When we migrate
everything to XSLT, we could just put all code files in the
$LENYA_HOME/xslt folder and have a very clean and easy to understand
codebase.
Thanks for your valuable input!
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
