Get Your Moto On

corz writes "Has PHP got you down? Are you tired of writing those Perl CGI scripts? Why not check out The Moto Programming Language. Released under the GPL, Moto allows for two modes of execution: interpreted and compiled. Moto is different from the rest of the field in that you can develop a site using interpreted mode for quick testing, then when the site is ready for production you can compile the it into an Apache DSO and serve it straight from memory. If you are looking to learn a new language, or would like to help with development, consider giving Moto a chance. Go download it now."

Comments

Not another language...

[lightspawn]

If this functionality really doesn't exist in Python/Perl/whatever, I wish "they"'d start working on it instead of inventing a completely new language to learn, which is probably not as good as what's already out there.

If it does - I'm sure somebody will point out how to do this with their pet language.

Embedded languages - pah

[Professor Collins]

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.

Re:Embedded languages - pah

[motojoe]

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

Re:Embedded languages - pah

[WasterDave]

OMFG, someone who knows about software design posting to slashdot. Where are my mod points when I need them?

Dave

Re:Embedded languages - pah

[Neon Spiral Injector]

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.

Re:That looks horrible

[motojoe]

The $xxx type constructs are almost legacy at this point. Embedded blocks of code can be written in moto like

<HTML><BODY>
${
String foo = "world";
print "hello "+foo;
}$
</BODY></HTML>

For every $xxx keyword (called a moto construct) there is an embedded block parallel.

-Dave

Perl & mod_perl

[wdr1]

Moto allows for two modes of execution: interpreted and compiled. Moto is different from the rest of the field in that you can develop a site using interpreted mode for quick testing, then when the site is ready for production you can compile the it into an Apache DSO and serve it straight from memory...

This is somewhat analogous to using Perl and mod_perl. If that's the only reason to use Moto, I'd stick with Perl instead.

-Bill

Re:Perl & mod_perl

[Sentry21]

This is somewhat analogous to using Perl and mod_perl. If that's the only reason to use Moto, I'd stick with Perl instead.

I think you misunderstand what's happening here.

In 'fast mode', you're using it like mod_perl or PHP, but the next step is to compile it to native code and run it as a binary server module - not interpreted by, but run as. With mod_perl or php, your site is always interpreted by the DSO, but for Moto, your site IS the DSO. This provides a nice speed boost.

--Dan

Re:Perl & mod_perl

[wdr1]

With mod_perl or php, your site is always interpreted by the DSO, but for Moto, your site IS the DSO.

I get that part, but mod_perl can run at speeds equiv. to writing a DSO in C. My understanding is that it caches the Perl op-code in memory, etc. So it's not really be interprested each request by the ISO, simply executed.

This provides a nice speed boost.

I'd wager it's either not actually there, or hardly noticable. Are there benchmarks anywhere?

-Bill

Re:Perl & mod_perl

[motojoe]

The perl / mod_perl analagy isn't quite right. When you compile a site with moto you get mod_site.so which you could then pick up and distribute to others in compiled, code-hidden, natively fast form. Users of mod_site would not even need moto to use it.

However this is not the only reason to use moto. Two other good reasons are

1) Moto is, for the most part, strongly typed. This means you can track down a lot more errors up front because they get caught in the type checking phase.

2) Moto allocates all objects to a shared memory segment. Thus maintenance of state, session, and context information between page views can be greatly sped up. In the demo application at iolio.com many large (10K+ rows), and complex query results get cached in memory between page views greatly reducing the cost of pulling that data every time.

-Dave

Re:Perl & mod_perl

[motojoe]

Honestly a thorough performance comparison with other languages hasn't been completed. I've largely been basing performance estimates on the speed at which my own web applications execute (most pages are within the hundreds of transactions per second range) compared with what I've seen elsewhere.

I have started a more thorough performance test by converting the programs on the python vs java page (http://www.twistedmatrix.com/users/glyph/rant/pyt hon-vs-java.html) and the great language shootout page (http://www.bagley.org/~doug/shootout/) . A full suite of performance tests will be posted on the projectmoto site in the next couple days. In the meantime if anyone wants to run a performance test from the shootout page in moto now, follow these steps :

1) grab http://projectmoto.org/perftests.tar.gz . These are conversions of 11 of the tests into moto.
2) fix the value for N for tests in other languages downloaded from the shootout page (shootout tests have the number of iterations passed in)
3) compile and time the moto file with the following script:

set MOTONAME = "$1.moto";
set CNAME = "$1.c";
moto -c $MOTONAME > $CNAME;
gcc -I/usr/local/moto/include -I/usr/local/moto/mx/codex/util -I/usr/local/moto/mx/moto -D__MAIN__=main -DSHARED_MALLOC -O3 -o $1 $CNAME /usr/local/moto/mx/moto/libmx_moto.a /usr/local/moto/mx/codex/util/libmx_codex_util.a /usr/local/moto/lib/libcodex.a;
time ./$1 > out

Anyway, the performance picture for compiled moto pages currently looks like this :

Calls to functions / methods written in moto are made roughly 100 times faster in compiled moto pages than calls to functions or methods in perl, python or ruby and about 20 times faster than methods are called in Java. Part of this may be due to method inlining for small methods by gcc but this is one area where any compiled language is going to smoke an interpreted one. You can see this in the methcall, sieve, and fibo tests from the shootout page. Also, if gcc wants to optomize compiled moto code, more power too it. Its one of the reasons generating C is a good idea. C is virtually guaranteed to have more optimized compilers on more systems than any other language compiler or interpreter.

Array accesses in moto are 10 times faster in moto than they are in python or perl and about 40 times faster than in ruby. They are 2 times faster than in Java. The implementation of arrays in moto is still un-opimized and functions are called behind the scenes on array access leading me to believe I could get another 5-10 time speed boost here when that gets optimized. The biggest reason that arrays are still so much faster in moto than they are in perl, python, or ruby, is that these language don't even try to offer typed, bounded arrays, thus array access is a much more heavy weight operation. The counterpoint to this is that arrays in these languages are much more powerful. Moto, like Java, offers classes, like Vector and Stacks to do these sorts of dynamic operations. Moto may eventually have language level support for more dynamic sorts of arrays but they will be differentiated by type from the simple C/Java style arrays moto supports now. These results can be tested with the ary3 test from the shootout page.

Outputting "hello world" 100,000 times runs about twice as fast in compiled moto as in perl, and 4-5 times as fast as it does in ruby. This is at least partially due to output buffering in moto which happens by default. It runs about 50 times faster than in java but thats because System.out.println sucks

Regular expression matching and substitution in moto today is 10 or more times slower than Perl or languages that use the PCRE package. The implementation is not optimized and incomplete. I hope to one day use the libtre package for regexes giving moto the completeness and the speed of these other languages in this regard. The implementation of regexes in moto is currently a modified version of Ville Laurikari's TNFA algorithms. This does mean that I will never have a regex that takes me an exponential amount of time to match. It also means I will not support back-references in the regex ... but I never liked them anyway.

Inserting integers to and from a hash (IntHashtable in moto) is 30% faster than in Java 50% faster than in python or ruby and 3 times faster than in perl. The difference with Java is likely because my Hashtable accesses aren't synchronized, this test should be redone with a Hashmap.

Inserting objects into a Vector (adding dynamically onto an array in Perl, Python, and Ruby) is about the same as in Java, and 10-50% faster than in perl,python,and ruby . Behind the scenes perl, python, and ruby, are effectively calling the same sort of highly optimized C methods as moto and Java are. I figured native method invocation in moto would take roughly the same amount of time in moto as it does in the interpreted languages. But that wasn't exactly what was going on. Turns out the memory manager in moto isn't nearly as fast as it should be and allocation of all the objects to put into the vector is what eats up all the time. The objinst test from the shootout page (as well as any old profile of a compiled moto app) demonstrates this. Object allocation in moto, java, perl, python, and ruby take roughly the same amount of time. The memory manager in moto is to blame for this. It is completely home grown. It acts on an memory mapped file and uses splay trees for the free list. This is necessary in order to persist objects between page views on the 1.3.x versions of apache. Turns out this implementation is nowhere near as fast as system malloc. So much for long bearded algorithms. The memory manager will be swapped out in the future for apache 2 support where its likely thread safe versions of the system malloc will be used. This should be a great big speed boost to all parts of moto.

matrix multiplication is 10 times faster than in perl, python, or ruby ... but who cares

-Dave

BTW: Don't try these tests in the moto interpreter ... no one ever claimed that was fast :)

Re:PHP alternative

[corz]

Rather than spending time creating a PHP alternative, its a pity that some of the development effort hasn't been put into making PHP more of a stable and standard language.

Moto isnt necessarily in the same market as PHP. Moto was designed so that you can write an application and sell it as a DSO without ever having to worry about people stealing your code. In other words, Moto is a great alternative to PHP for companies that would like to be able to sell a compiled product, while at the same time not giving up the low development times.

PHP is RAPIDLY becoming bloat-ware, and its a shame - cos it's nice.

I couldnt agree more. Having all the functions in the global namespace really is annoying. Why not at least give Moto a try and evaluate it based on its own merits, instead of disregarding it because "its not PHP."

Check it out, and join the mailing list (moto-subscribe@webcodex.com) if you have any questions or suggestions that you would like to make. We would definately love to hear them.

Yay!

[psicE]

It's today's daily Slashvertisement! And to think I thought they were joking...

I still don't get what Moto has that other languages don't. If it's performance you're talking about, then why not just write a Python compiler? Honestly, it's not *that* hard, especially compared to writing a new language. And more importantly, Python is the most flexible language ever created. You can eschew brackets and semicolons, or you can use them (yes, the new Python supports semis). You can program in traditional imperative style, or more powerful functional style; most useful functional features are already built into Python, and the Xoltar toolkit provides the rest. And Python Server Pages, well, rule.

Moto could theoretically become a niche language, a la Ruby. But it's not going to overtake Perl and Python - good.

Re:Yay!

[psicE]

Two differences. First, it's not just Python; also Perl, ML, Scheme, Haskell, and various other languages support these kinds of features. It's just that, out of all the languages available, Perl and Python are by far the most widely-known and used, and Python happens to have a wider feature set (namely functional programming features) than Perl.

Second, this is a comment. Yours is a story. :D

Re:Yay!

[motojoe]

I still don't get what Moto has that other languages don't. If it's performance you're talking about, then why not just write a Python compiler?

Well, I can't really speak to Python. But I can tell you why I decided to write moto instead of compiling say PHP.

1) Lack of type safety and the ability to use a variable without declaring it in most interpreted languages: I hate waiting till runtime to find out that my variable has not been declared or I was using an int and not a string. I hate even more getting only one error at a time.

2) Performance : Myself and the engineers I had worked with had been coding in Java and JSP type languages for many years and the compiled performance of java classes (3 years ago) was simply not good enough for what we were doing. I wanted to see whether I could get another order of magnitude increase in performance by 'going native'. Compilation wasn't the only feature built into moto for this. The runtime, specifically a memory manager which acts on a shared segment for persisting data between pageviews, was crucial. Swapping out the memory manager in other languages is not simple.

3) Code hiding : Most interpreters don't have this or its extra

4) Dependencies : Consider JSP sitting on top of the VM sitting on top of the Servlet runner loaded by the webserver. Thats a lot of moving parts. Or consider Coldfusion or the old Server Side Javascript interpreters. They ate machines. Extending any existing language with the ability to compile natively just adds one more layer of mess into the mix. Also, if the goal is 1 file as output then the library structure of native language extensions needs to be statically linkable .a files as well as .so files for dynamic loading.

5) Swallowing the language whole : Any language that has the ability to interpret strings dynamically is virtually pointless to compile because you end up bundling the interpreter with the compiled code.

Well ... these were some of my reasons ... do I think a compiler for python or perl would be a good idea ? Yes ! But speed was not the only goal.

-Dave

Re:YAHPP?

[Sentry21]

The point of HTML preprocessors isn't to make it easier to write HTML, it's to make it easier (possible) to write dynamic HTML on the server end.

Not to mention, the use of mod_perl, PHP, and so on, is often not necessarily to preprocess HTML, but rather to generate it in the first place, sometimes from pieces.

Either way, maybe a new HTML would be nice. I guess we'll see.

--Dan

Zend Safeguard Suite...

[coene]

A bit off topic of the actual news, but related to many comments....

If you are looking to compile your PHP (to not make source viewable, make it faster, etc etc) check out Zend's SafeGuard Suite...

PHP *allows* bad code not *forces*

[DrSkwid]

Ok, I'll agree that the usual apprach to PHP and the approach taught in the tutorials and the various programming php books does mix them together but there's nothing that forces that approach.

You won't see it in any of my sites.

You'll see code more like :

<?
$h = new HTML();
$h->load_from_template('homepage.txt');
echo $h->as_html():
?>

If you want to mix presentation and data that's your business.