Get Your Moto On 44
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."
Not another language... (Score:2, Insightful)
If it does - I'm sure somebody will point out how to do this with their pet language.
That looks horrible (Score:1)
I suppose there is a good idea behind having a newline prefix rather than a postfix but I suspect it is to make the parsing easier.
Extra cruft life that is tiring on the eyes.
The languages I know (programming or otherwise) have postfixes ; or . or even just a \n and when one breaks this convention it is harder work to cope with it.
But that aside, strength to their arm.
To reduce the compile/debug cycle time but maintain the execution speed is a worthy ambition. Plenty of the world is prepared to sacrifice execution time in favour of a reduced cycle time.
Inperpreted languages have been steadliy creeping in this direction. Perl & Python's parrot springs to mind. Even php maintains 'object' files.
One of the downfalls of interpreted web languages is the programmers approach. All over the web are sites that use the same php script to produce *exactly* the same html page over and over again and yet the data that makes up these pages may only change once a day. Certainly, on the most part, pages have more reads than writes (If i use slashdot as an example, it was said that the ration of people who post to people who read is 1:3). On my site I write out my php produce html to local cache files and if nothing has changed I use them. A bit of javascript takes care of rotating your banners.
All programmers should be forced to write code for low memory slow cpu devices long before they are allowed on anything better than a 486
Re:That looks horrible (Score:2, Informative)
<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
yes, that's an improvement (Score:1)
[
lda #01;
]
is that right, I cant quite remember? I've got two of them behind me. I want to crank them up and do something with the 1Mhz external parallel bus.
Re:That looks horrible (Score:1)
The only solutions I've seen which truely solve this problem are Java (has to be compiled) and ASP.NET (limited to Windows and HTML not yet standards complient).
I love PHP, but I would love it more if the next version allows clear seperation of web design (html) from code.
If you can achieve this in MOTO, I might be interested.
PHP *allows* bad code not *forces* (Score:2)
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');
?>
If you want to mix presentation and data that's your business.
I wonder what will happen (Score:1)
YAHPP? (Score:1, Insightful)
If HTML needs so much pre-processing, perhaps it is time to standardize a new HTML, instead of writing all these incompatible pre-processors for it.
Of course, that's just my humble opinion...
Re:YAHPP? (Score:2)
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 [w3.org] would be nice. I guess we'll see.
--Dan
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
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.
Here's a weirdness.. (Score:1)
example: http://projectmoto.org/index.moto is the page, the source is http://projectmoto.org/moto/index.moto. I am not sure if this is by design or by accident, altho this problem does not seem to exist on his other sites.
Lets see how Moto handles a slashdotting!
- A
Re:Here's a weirdness.. (Score:1)
Lets see how Moto handles a slashdotting!
As an admin on the projectmoto.org server I can tell you that its doing just fine:
# uptime
12:15pm up 87 days, 7:08, 5 users, load average: 0.00, 0.00, 0.00
Re:Here's a weirdness.. (Score:1)
song stylings (Score:1, Funny)
hehe bad joke
Perl & mod_perl (Score:3, Flamebait)
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 (Score:4, Insightful)
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 (Score:4, Informative)
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 (Score:4, Informative)
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/py
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
time
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
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
-Dave
BTW: Don't try these tests in the moto interpreter
Re:Perl & mod_perl (Score:2, Informative)
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:PHP alternative (Score:2)
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 [mailto]) if you have any questions or suggestions that you would like to make. We would definately love to hear them.
Yay! (Score:2, Informative)
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! (Score:1)
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.
Now who is doing the slashvertising
Re:Yay! (Score:2)
Second, this is a comment. Yours is a story.
Re:Yay! (Score:2, Informative)
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
Nyuck! Nyuck! (Score:1)
Not Found
The requested URL
Apache/1.3.26 Server at 127.0.0.1 Port 80
Zend Safeguard Suite... (Score:3)
If you are looking to compile your PHP (to not make source viewable, make it faster, etc etc) check out Zend's SafeGuard Suite...
Why embedding? (Score:1)
<html>
There are currently $user_count users online
</html>
This way, whoever does the HTML has to deal with an absolute minimum of the programming part, and I can just insert those placeholders where I need. Then the Perl script replaces them by the actual values. Of course this isn't the fastest approach, but there's not so much data that changes every second, so with some caching it should be just as fast as embedded code.
Why can't they donate free labor to ... (Score:1)
I have no idea what you people are complaining about with this new programming language. It's fucking GPLed you hypocritical ingrates. What more do you want? If you think the code has worthwhile ideas, knock yourself out improving other GPL software.