Get Your Moto On

ah... by Anonymous Coward · 2002-09-17 06:36 · Score: 0

but i can use C or C++ and simply disable optimization during testing!

Moto and .NET by Anonymous Coward · 2002-09-17 06:39 · Score: 0

Does it work with .NET?
Otherwise I can't use it.

Not another language... by lightspawn · 2002-09-17 06:49 · Score: 2, Insightful

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.

That looks horrible by DrSkwid · 2002-09-17 06:56 · Score: 1

$case('>')

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 :)

--
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter

Re:That looks horrible by motojoe · 2002-09-17 07:06 · Score: 2, Informative

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
Re:That looks horrible by lostcarpark · 2002-09-19 00:39 · Score: 1

Hmmm, the major problem I see with this (which is the same major problem Perl, PHP, ASP and many others have) is that the script and the HTML are all wrapped up together. This is fine for something small like putting a counter on a page, but it becomes a real nightmare when you have scripts running to thousands of lines and hundreds of pages in your site (the sites I run aren't huge and I've run into both of these problems).

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.

--
"I will crush you like a tiny ant"
Re:That looks horrible by Anonymous Coward · 2002-09-25 04:46 · Score: 0

Perhaps you could consider logical blocks of code, appripriate file separation, sensible use of include(), and a dash of common sense.

Don't blame your lack of steez on the language.

I wonder what will happen by agnosonga · 2002-09-17 07:00 · Score: 1

It will be interseting to see if moto use overtakes php / perl-CGI

YAHPP? by NetRanger · 2002-09-17 07:01 · Score: 1, Insightful

Yet Another HTML Pre-Processor.

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...

--
-- We live in a world where lemonade is artificial and soap has real lemon.

Re:YAHPP? by Sentry21 · 2002-09-17 13:01 · Score: 2

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

Embedded languages - pah by Professor+Collins · 2002-09-17 07:01 · Score: 5, Insightful

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 by motojoe · 2002-09-17 07:20 · Score: 2, Insightful

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 by Anonymous Coward · 2002-09-17 07:31 · Score: 1, Interesting

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.

- Rich
Re:Embedded languages - pah by WasterDave · 2002-09-17 10:45 · Score: 2, Insightful

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

Dave

--
I write a blog now, you should be afraid.
Re:Embedded languages - pah by LWATCDR · 2002-09-18 02:54 · Score: 1

Of course there was ssi. Server Side Includes. Too bad that they where not merged with cgi.

--
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Re:Embedded languages - pah by Neon+Spiral+Injector · 2002-09-19 05:24 · Score: 2

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:Embedded languages - pah by Guillermito · 2002-09-22 15:02 · Score: 1

I couldnt agree more.

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.. by cfadam · 2002-09-17 07:12 · Score: 1

Wanna see some src of his page? Just change the url to view the files in the /moto dir.

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.. by corz · 2002-09-17 07:20 · 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.. by motojoe · 2002-09-17 07:24 · Score: 1

Some snippets from the error log: [Tue Sep 17 12:21:16 2002] [info] support.moto executed in , 0.000890 seconds. At this rate we could execute 1123.595474 tps. [Tue Sep 17 12:21:36 2002] [info] index.moto executed in , 0.018986 seconds. At this rate we could execute 52.670389 tps. [Tue Sep 17 12:21:42 2002] [info] example_display.moto executed in , 0.001226 seconds. At this rate we could execute 815.660670 tps. [Tue Sep 17 12:21:46 2002] [info] docs4.moto executed in , 0.006862 seconds. At this rate we could execute 145.730106 tps. [Tue Sep 17 12:21:48 2002] [info] extensions.moto executed in , 0.000749 seconds. At this rate we could execute 1335.113487 tps. [Tue Sep 17 12:21:52 2002] [info] docs_overview.moto executed in , 0.000948 seconds. At this rate we could execute 1054.852320 tps. [Tue Sep 17 12:21:59 2002] [info] example_display.moto executed in , 0.232607 seconds. At this rate we could execute 4.299097 tps. [Tue Sep 17 12:22:08 2002] [info] features.moto executed in , 0.000748 seconds. At this rate we could execute 1336.898411 tps. Seems to be handling things pretty well ... re: viewing source argh ... last minute symlink hackery always causes me great pain. Ah well ... consider it a secondary source of examples.

song stylings by Vodak · 2002-09-17 07:34 · Score: 1, Funny

Get your motto running... set up on apache... looking for an exploit...

hehe bad joke

Perl & mod_perl by wdr1 · 2002-09-17 08:26 · Score: 3, Flamebait

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

--
SlashSig Karma: Excellent (mostly affected by moderatio

Re:Perl & mod_perl by Sentry21 · 2002-09-17 08:33 · Score: 4, Insightful

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 by wdr1 · 2002-09-17 08:45 · Score: 4, Informative

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

--
SlashSig Karma: Excellent (mostly affected by moderatio
Re:Perl & mod_perl by motojoe · 2002-09-17 09:50 · Score: 2, Informative

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 by Anonymous Coward · 2002-09-17 19:07 · Score: 0

If it's hardly noticable, it's because Apache's architecture sucks and enforces a much higher overhead. (Can we put thttpd principles to work in a 'real' server? Especially the bandwidth shaping that results in slower loads, rather than lost hits?)

Of course, the Apache architecture did make things like mod_perl and mod_ruby straightforward, so I do see the point. Still, for a truly high-impact site (Yahoo! communities, Slashdot) this sort of ability means fewer CPUs thrown at the problem, fewer CPUs mean fewer dinosaurs burnt to keep your site running, the *planet* benefits from efficiency, and your dotcom business benefits by scaling with less hardware, or doing snazzier things that were too expensive without compiled modules.

Now if this level of embeddability could be reached for Ruby, we'd have the best of maintainable code and reasonably efficient execution.
Re:Perl & mod_perl by motojoe · 2002-09-18 17:19 · Score: 4, Informative

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 :)

PHP alternative by The+Whinger · 2002-09-17 09:04 · Score: 0

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.

I like PHP, its easy to use (given previous experience of other languages) and it allows for "fairly" rapid development. However, it really needs some fixing.

The error output is hit and miss, the function argument order is non-intuative and the documentation is lacking. The PHP API really needs freezing to allow the language to become stable and to sort some of the fundamental bugs out.

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

Re:PHP alternative by corz · 2002-09-17 09:17 · 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) if you have any questions or suggestions that you would like to make. We would definately love to hear them.

yes, that's an improvement by DrSkwid · 2002-09-17 09:35 · Score: 1

It takes me back to inline assembler in BBC Basic

[
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.

--
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter

Yay! by psicE · 2002-09-17 09:53 · Score: 2, Informative

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! by corz · 2002-09-17 09:57 · 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! by psicE · 2002-09-17 10:29 · Score: 2

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! by motojoe · 2002-09-17 11:03 · 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?
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! by BiOFH · 2002-09-17 17:58 · Score: 1

Maybe ad development is eating into site development time... hehe As I click this article, what do I see?

Not Found
The requested URL /adi/N815.slashdot/B1023805.2;sz=336x280;ord=10323 2842103232842 was not found on this server.
Apache/1.3.26 Server at 127.0.0.1 Port 80

--
- I am made of meat.

Zend Safeguard Suite... by coene · 2002-09-18 07:42 · Score: 3

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...

Why embedding? by vadim_t · 2002-09-18 10:36 · Score: 1

I never understood the embedding approach. It's just wrong IMO. Programmers should write code and web designers do the HTML, and both things kept as separated as possible. What I do is having HTML templates like this:

<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.

Paper grading overview: D by Anonymous Coward · 2002-09-18 14:40 · Score: 0

Ridiculous and naive regurgitation of pedestrian software engineering principles without the qualification of experience.

Re:Paper grading overview: D by Anonymous Coward · 2002-09-18 16:24 · Score: 0

Naïve, AC shitbag.

Why can't they donate free labor to ... by joneshenry · 2002-09-18 15:44 · Score: 1

Predictably after an article is posted about a piece of free software dozens of whiners will complain "Why couldn't this person have contributed free labor to my own pet project." We still have people complaining everytime an article is posted about Gnome even though the project has been successful for years. These whiners never seem to get the point that people have pride in ownership of their own project. If people were to stop developing their own projects, most likely they would simply contribute far less to free software considering the incredible timesink.

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.

PHP *allows* bad code not *forces* by DrSkwid · 2002-09-19 01:50 · Score: 2

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.

--
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter

Slagging ASP by Anonymous Coward · 2002-09-21 05:08 · Score: 0

I really wish people who have never used ASP would stop slagging it. It's a language. It has shortcomings and strengths, and it's good for some things and not good for others. Attacking it unilaterally because it is not the holy untouchable grail of Perl (feh!) is a waste of time.

I use ASP on a site that has several hundred interlocking pages, and because I took the time to break everything out intelligently and make the code reuseable across different parts of the site, things are very manageable and upgradeable. If you approach ASP while KNOWING WHAT THE HELL YOU'RE DOING, you can do good things. If you're an idiot, it'll be shit.

A tool is only as good as you. Stop bitching because someone decided to invent a language that might be good for something. ASP is not perfect, but it works fine for what I do and I like it just fine.

ASP IS NOT A LANGUAGE! by leerpm · 2002-09-21 11:31 · Score: 0

It is a technology. Even I consider myself pretty partial to the Microsoft platforms at times, but this comment is just going too far. VBScript and JScript are languages, Active Server Pages is not. Thank god we have C# and real Visual Basic compiled code now instead.

44 comments