I'm sad to see the curse of ASP and its copycats continue on like this. Embedding script inside a document file makes it quick and easy for non-programmers to write messy, unmaintainable code:
They violate Model-View-Controller (MVC) separation. While it is possible to write your controller code as one long block of PHP and call its functions from your view scripts, that totally obviates the purported advantages of an embedded language.
The embedded languages themselves are generally horrible. Visual Basic needs no run-down of its deficiencies. PHP is an overgrown SSI replacement which has ended up looking like a bad parody of Perl. Moto looks to be little more than a light wrapper around C. None of these languages have a proper object model, consistent database integration, or a good extension mechanism.
They slow down maintenance of code. While the initial development phase may be expediated by the ability to embed code inside HTML, the web of markup and programme logic quickly becomes entangled in itself, and only gets worse over time. Starting with a proper top-down design phase may slow down development at first, but will be greatly rewarding in the long run.
The idea of Moto as both a compiled and interpreted language is noble (although not original; most Common LISP and Smalltalk implementations have both interpreted and compiled environments), but I urge them to reconsider their misguided language design strategy. They don't even need to come up with their own language; building a native code compiler for an established language like Python or Ruby would be a much greater boon to the open-source community at large.
The fact of the matter is if you look at CGIs in the days when they had to be written in C you'll find that 90% of the code was for interface generation. A ton of printfs and a little bit of logic. That's not the balance most programs should have. Add to this the process most consulting firms go through when creating web based applications is to have the designers create HTML 'comps' first which then get sent to engineers to be made 'dynamic'. Often time the design will go through many subsequent revisions after coding has begun. The value of having code embedded into HTML so that the same pages can by modified by either the engineer or the designer should be clear.
This is not to say that large blocks of non-interface related code shouldn't be coded in a language like C or C++. They should. But often times disentangling logic from interface is simply not possible or valuable.
-Dave
In Apache 2.0 CGI applications can write SSI statements that will then be processed.
I still write a lot of CGI in C, and while it isn't so hard to open a file and write it to the standard out, I'm thinking about giving the CGI/SSI combo a try.
Anonymous coward? Nah, just too lazy to remember my account.
I'll step up and take some responsibility for the barrage of flames.;-)
Having worked with the Moto author a long time ago (anyone remember ptml?!) and thus likely contributed to his Moto predilection.
Speaking from the better, faster, cheaper camp (management) Moto has the following merits:
1) Limited Modifiability: As the presentation/view of a web based app, Moto represents a modifiable yet occult strategy - this is great for deploying highly customizable apps when you don't want your client messing with the actual code. Give'm perl or php, they're gonna touch it.
2) Security through obscurity: (I'm ducking related flames on this one) But if you are an ISP deploying quick and dirty apps for customers and want apache modules with very little understanding of those apache modules, well cool.
3) It is eventually C: The C output is quite nifty - it is probably safe to assume that this C is highly portable and could be used for some embedded applications. Don't people want to run dynamic pages from their wrist watches?
4) Lifecycle: There are times when a system should be designed to be disposable. While a pretty brutal view, if a small system gets written in Moto, the big system will need a re-write in something a little more 'architectural'. e.g. j2ee, xsl, etc..
5) Configuration management: Moto is simple, and doesn't have many moving parts.
6) Cult: people love knowing something other people don't. That has managerial implications.;-)
Anyway enough of that, I'm steering clear of the technical discussion, - but as a niche language I think there are places where Moto could be used.
Thats why I prefer approaches like xmlc (see http://xmlc.enhydra.org/ )
With xmlc you get complete MVC separation. Web designers generate and mantain pure HTML files (they can even keep their mock up data). Programmers create and mantain pure Java programs. Nobody messes with other peoples work.
Embedded languages - pah (Score:5, Insightful)
The idea of Moto as both a compiled and interpreted language is noble (although not original; most Common LISP and Smalltalk implementations have both interpreted and compiled environments), but I urge them to reconsider their misguided language design strategy. They don't even need to come up with their own language; building a native code compiler for an established language like Python or Ruby would be a much greater boon to the open-source community at large.
Re:Embedded languages - pah (Score:2, Insightful)
Re:Embedded languages - pah (Score:1)
Re:Embedded languages - pah (Score:2)
I still write a lot of CGI in C, and while it isn't so hard to open a file and write it to the standard out, I'm thinking about giving the CGI/SSI combo a try.
Re:Embedded languages - pah (Score:1, Interesting)
I'll step up and take some responsibility for the barrage of flames.
Having worked with the Moto author a long time ago (anyone remember ptml?!) and thus likely contributed to his Moto predilection.
Speaking from the better, faster, cheaper camp (management) Moto has the following merits:
1) Limited Modifiability: As the presentation/view of a web based app, Moto represents a modifiable yet occult strategy - this is great for deploying highly customizable apps when you don't want your client messing with the actual code. Give'm perl or php, they're gonna touch it.
2) Security through obscurity: (I'm ducking related flames on this one) But if you are an ISP deploying quick and dirty apps for customers and want apache modules with very little understanding of those apache modules, well cool.
3) It is eventually C: The C output is quite nifty - it is probably safe to assume that this C is highly portable and could be used for some embedded applications. Don't people want to run dynamic pages from their wrist watches?
4) Lifecycle: There are times when a system should be designed to be disposable. While a pretty brutal view, if a small system gets written in Moto, the big system will need a re-write in something a little more 'architectural'. e.g. j2ee, xsl, etc..
5) Configuration management: Moto is simple, and doesn't have many moving parts.
6) Cult: people love knowing something other people don't. That has managerial implications.
Anyway enough of that, I'm steering clear of the technical discussion, - but as a niche language I think there are places where Moto could be used.
- Rich
Re:Embedded languages - pah (Score:2, Insightful)
Dave
Paper grading overview: D (Score:0)
Re:Paper grading overview: D (Score:0)
Re:Embedded languages - pah (Score:1)
Thats why I prefer approaches like xmlc (see http://xmlc.enhydra.org/ )
With xmlc you get complete MVC separation. Web designers generate and mantain pure HTML files (they can even keep their mock up data). Programmers create and mantain pure Java programs. Nobody messes with other peoples work.