Posted by BearItAll on 11/03/31 11:19

On Wed, 22 Jun 2005 17:30:21 -0700, darwinist wrote:

> BearItAll wrote:
>> On Tue, 21 Jun 2005 19:39:50 -0700, darwinist wrote:
>>
>> > That said, most descriptions of what is good about php, fail to do it
>> > justice. Although they are generally enthusiastic and sometimes
>> > fanatical, no amount of religious zeal about its coolness or easiness
>> > can make up for missing the main point. Out of the theoretical realm
>> > of language design and into the economic reality, php is the most
>> > powerful (programming) language so far created.
>>
>> I may not be popular saying this, but I don't think php is the best tool
>> for the job that it is used for.
>
> Not being popular is what saying things on the internet is all about :)
>
>> I would agree that it is easy and fits in well with the html/xslt side
>> of things. It also seems to be the best available at the moment, which
>> is likely to be why it's popular.
>
> Right there's best in theory and best in practice. They are rarely the
> same in virtue of the fact that humans make such limited theories, and the
> universe is not impressed.
>
>> But I would say that ruby-rails is much closer to how things should be,
>> even if your not keen on the language itself, the principle is much
>> closer to being right. The html page or 'view' of an application should
>> be an object of that application, not a filter page that needs to pass
>> through a 'find & replace' function. How many filters (or transcribers?)
>> can be active per html page now? php, java script, css, w3c ....
>
> Lots of things are more how it "should" be, but the question I'm
> interested in is how quickly can one produce something that contributes
> economically to an organisation (as an information-tracking tool that is,
> rather than as a sellable commodity).
>
>> Ruby-rails nearly goes that way of taking the view away from the main
>> code, but I feel as if it got nervous of taking it to the final
>> conclusion, plus of cause they are at the mercy of html itself.
>>
>> When we have a language for web that truly separates data - application
>> - view, so separate in fact that the view could even live on the client
>> PC if we wanted it to, then we can rave about it. At the moment we're
>> still on the journey.
>
> I've been hearing more about ruby (and rails) lately, the only bad thing
> it's got going against it at the moment is that I've never used it. What
> little code I've read however makes it look very neat and efficient
> (code-wise). In any case it would stupid for me to suggest that PHP will
> never be superceded, and who knows maybe it will be ruby that does it.
> Like most languages that are better than php though, it has to be better
> *on the web* or else a lot of people will think "why bother, it's so much
> easier in php, and anyway it's all the same once it reaches the browser"
>
> I don't think PHP is necessarily the best for any and every website or
> web-application, but I think it's probably the best (all things
> considered) for getting something genuinely and concretely useful (e.g. a
> customer database, a timesheet, project or stock database) and getting it
> quickly. You can (too) easily do it badly, but you can do anything badly
> (and ironically it's often much slower if you do).


I agree with you in part, but I think your using the learning curve for
(as an example) ruby-rails as part of the argument against it. When I
think that the application types that you mention would be much more
practical, from a coding and maintenance point of view, by using
ruby-rails.

I would say that anyone starting from a platform of having reasonable
programming skills, irrespective of the language could start producing
working useful code within a week for ruby and two weeks for ruby-rails.
Experience in any language counts for a lot, I still slip back into C when
I really need something quickly, simply because i programmed C for so long
that that is the programming language that I think in.

So, lets say that we have gone through the learning curve and come out at
the other end. Now we can compare php and ruby-rails.

The first thing that stands out is really very simple, most programmers
would of done something in these lines anyway, but ruby-rails offers a
formal way to do it. It creates all of the separation directories, but it
does so in such a way that even to untrained programmers the layout
suggests the best places for various parts of you projects functionality.
Once you have tried a few sample sites, then you realise just how
logically correct it is. Ok, have to admit that some areas of the
separation are a bit shady, but thats true of all projects.

So straight away we have an environment that is easier for maintenance and
code updates, simply because you can go straight to the offending code
area whether the project was written by you or not.

You are talking mainly of database/contact/records work. Well, you point
ruby-rails at your database, then the data itself becomes an object of
your application. It is ruby's job to handle access.

The current down side is that I haven't actually come across an ISP that
offers ruby-rails as one of it's available programming environments. I
have only used it on my own servers.

In defence of php though. Ruby has some speed problems, php writers
would spot that one even in fairly simple code. But maybe the engine will
improve eventually.

[Back to original message]