Alexander Panek schrieb:
> Well, even the fact that it seems to use the dollar sign as variable prefix makes me go puke. Really. There are so many good languages out there, why do you need create a new, incompatible and most probably unsupported one? Rather use MiniD, Ruby, Python, or what not else, as they are actively developed and not just a small hack to get some more performance for a website.
> 
IMO Ruby is not an option because 1) Ruby is too slow. 2) Ruby is not really extendable from D.
Speed matters!
I agree, the dollar sign is ugly. I guess it exists to speed up parsing.
Bjoern

BLS Wrote:

> Alexander Panek schrieb:
> > Well, even the fact that it seems to use the dollar sign as variable prefix makes me go puke. Really. There are so many good languages out there, why do you need create a new, incompatible and most probably unsupported one? Rather use MiniD, Ruby, Python, or what not else, as they are actively developed and not just a small hack to get some more performance for a website.
> > 
> IMO Ruby is not an option because 1) Ruby is too slow. 2) Ruby is not
> really extendable from D.
> Speed matters!
> I agree, the dollar sign is ugly. I guess it exists to speed up parsing.
> Bjoern

No! Dollar sign is one of the worst features of PHP IMO and I would never do that. The dollar sign is for compatibility with JavaScript. Is is NOT required it is just a valid identifier character and it is there because I wrote the benchmark in php first and copied it to flowerscript :)

"bobef" <bobef@abv_nospam.bg> wrote in message news:fdd020$plv$1@digitalmars.com...

> I do compile time optimizations that "sees" that there are several concats (or any other binary operator) in a row so instead of creating several new string objects it creates only one. Furthermore the cat operator counts the length of the resulting string (or array) and does only one allocation, so I haven't profiled it (yet) but in these loop there are like 2 allocations times 1000...

This is, as I explained on the threads on the MiniD forum, exactly what MiniD already does.  (And yes, it's also quite fast.)

On Wed, 26 Sep 2007 13:11:00 +0300, Henning Hasemann <hhasemann@web.de> wrote:

> I would love such a framework. I'm also wondering if there might be a way to avoid that awful stateless coding style, ie to be able to do something like:
>
> ----
> ask_for_users_address();
> // user gets a form to enter its address, program here is "frozen" here
> // until the user submits or the session times out
>
> ask_for_users_bank_account();
> // present another form
> ----

It should be possible with threads or fibers. Threads consume OS resources, so they may not be the perfect choice (consider the DoS attack scenario). If you don't allocate too much resources per thread/fiber (stack space, but not much is necessary here - just enough to control the state of a session), it might even be practically useable with some tuning.

-- 
Best regards,
 Vladimir                          mailto:thecybershadow@gmail.com

There is FastCGI4D. This fits the bill pretty well. I've never coded for fcgi, but from what I've heard it's the way to go. It uses Tango.

http://dsource.org/projects/fastcgi4d/

Vladimir Panteleev wrote:
> On Wed, 26 Sep 2007 13:11:00 +0300, Henning Hasemann <hhasemann@web.de> wrote:
> 
>> I would love such a framework. I'm also wondering if there might be a way to avoid that awful stateless coding style, ie to be able to do something like:
>>
>> ----
>> ask_for_users_address();
>> // user gets a form to enter its address, program here is "frozen" here
>> // until the user submits or the session times out
>>
>> ask_for_users_bank_account();
>> // present another form
>> ----
> 
> It should be possible with threads or fibers. Threads consume OS resources, so they may not be the perfect choice (consider the DoS attack scenario). If you don't allocate too much resources per thread/fiber (stack space, but not much is necessary here - just enough to control the state of a session), it might even be practically useable with some tuning.
> 

This is extremely difficult to do. The simple answer is, it's difficult to ensure that the user will get the same server in the second request. Also, if that server fails, what happens? I suppose the data for the address is lost, however that's not what you want. Machines fail. Also, if you MUST have the machine online, then you can't ever take the machine offline to do upgrades, reconfiguration or whatever. Take the example of google. They expect machines to fail, and implement failover in the software that they write -- bigtable and such.

I have written web frameworks in D -- with MVC and stuff, and it's very fast. It's not a scripting language, because all of the data work is done inside of D objects. IMO, it'd just be another MVC framework, until I write the portion that allows for automatic failover, distributed processing, and ways to implement intelligent caching and concurrency.

For example. I work for a web page that generates millions of page views a day. We run php, mysql, memcache. We have 4 php servers, and 8 DB servers. During peak, our php servers easily have a concurrency of over 100 processes simultaneously -- yet only 4% CPU usage. However, our DB servers have about 30 thread concurrency and about 600% CPU usage. (8 core machines).

We will never ever optimize php, because it spends only about 10-40ms inside of php and the rest at memcache and the DB servers. You can optimize D all you want, or even run your website in a C daemon, but most websites struggle because they have database problems.. Data grows exponentially, even with linear user growth, and becomes a huge problem, beacuse the database will grow larger than the memory of the machine, and can never distribute the query among multiple machines.

Personally, a D implementation of web specific distributed computing such as a bigtable implementation would be a whole lot more effective, and would actually begin to achieve the desire of the stateless computing better than threads or fibers ever could.

Just my 2 cents

Kenny

BLS Wrote:
> IMO Ruby is not an option because 1) Ruby is too slow. 2) Ruby is not really extendable from D.

1) Ruby isn't so slow as most people want it to be.
2) Ruby is extendable from C, thus easily extendable from D.

Oh.. what I've forgotten to ask: what's the license?

Alexander Panek wrote:
> 1) Ruby isn't so slow as most people want it to be.

Whoever might /want/ Ruby to be slow (apart from GvR and LW)? :)
More important is, IMHO, that execution speed is not everything.
It just needs to be fast enough to do the job, and often it is.

Regards, Frank

0ffh wrote:
> Alexander Panek wrote:
>> 1) Ruby isn't so slow as most people want it to be.
> 
> Whoever might /want/ Ruby to be slow (apart from GvR and LW)? :)
> More important is, IMHO, that execution speed is not everything.
> It just needs to be fast enough to do the job, and often it is.

Exactly! As mentioned before in this thread: in most cases the database is a lot slower than the Ruby application - let alone when you run it on a quad core Xeon with 20 Mongrels or so. *shrug* :P