Wordpress Port
hjast
rails and ruby guy, and now have to do a blog in Wordpress. PHP is an
ugly langauge and I wish I could use ruby for extending and looking at
the architecture. Since Wordpress is open source we could just
straight port a lot of the code from wordpress as it is. Someone could
even make a parser which makes php extensions or themes compatible.
I guess in general, this is a question about the lack of CMS's in
ruby. THe general comments usually are, why have a cms when we can
make it in rails so much fast? I agree with the point that Rails is
quite mature and robust to handle making any type of site very
quickly. There is one problem, this is contingent on knowing Ruby on
Rails. To help further Ruby's cause perhaps people should come to
together to port a few proper CMS's or at least add some sort of
compatibly.
Rick DeNatale
Well there are some well-known Ruby CMSeseses.
Have you looked at Radiant CMS? http://radiantcms.org/
--
Rick DeNatale
Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
Jason Roelofs
And if you're looking for a Rails-based blog platform, there's Mephisto:
http://mephistoblog.com/
Wordpress is enormous. Porting would be non-trivial.
Jason
Rob Biedenharn
No, It sounds like hjast wants to check out phuby on phails. The video
from RubyConf2009 should be up soon -- the session you need to see is:
21-Nov-09 15:05
"Worst. Ideas. Ever."
Aaron Patterson and Ryan Davis
Really, if I tries to tell you much more about it, the effect would be
ruined.
For now, you'd have to settle for this: http://www.youtube.com/watch?v=lsWKjS6Vufw
-Rob
Rob Biedenharn http://agileconsultingllc.com
R...@AgileConsultingLLC.com
David Masover
> Has there any been an effort to make a ruby Wordpress port? I am a
> rails and ruby guy, and now have to do a blog in Wordpress. PHP is an
> ugly langauge and I wish I could use ruby for extending and looking at
> the architecture.
If you're wanting a way to work with Wordpress, the PHP app -- for example,
writing a Wordpress plugin in Ruby -- I don't think there really is one,
though that's not entirely a bad idea. Just mostly a bad idea.
If you're looking for an actual port of Wordpress, and I think this is what
you want...
> Since Wordpress is open source we could just
> straight port a lot of the code from wordpress as it is.
Well, code written in one language doesn't always translate directly into
another language. I'm guessing the word press architecture isn't a good fit --
you could probably do something better starting from scratch in Ruby, which is
why someone pointed you to Mephisto.
> Someone could
> even make a parser which makes php extensions or themes compatible.
Well, probably not. You might be able to build a bridge (as the Phuby guy was
jokingly suggesting), but short of that, no you couldn't. Keep in mind that a
PHP extension or theme is still PHP code, not Ruby code. Translating one
language directly into another, even when it works, usually leads to fairly
ugly code.
> I guess in general, this is a question about the lack of CMS's in
> ruby. THe general comments usually are, why have a cms when we can
> make it in rails so much fast?
I don't agree with that, and I think a lot of the Merb people were thinking
about ways to improve that situation, especially by stealing ideas from
Django.
And I definitely think Wordpress is not a good choice for a CMS.
Drupal would be a much better choice.
Marnen Laibow-Koser
> On Monday 07 December 2009 11:00:08 am hjast wrote:
>> Has there any been an effort to make a ruby Wordpress port? I am a
>> rails and ruby guy, and now have to do a blog in Wordpress. PHP is an
>> ugly langauge and I wish I could use ruby for extending and looking at
>> the architecture.
>
> If you're wanting a way to work with Wordpress, the PHP app -- for
> example,
> writing a Wordpress plugin in Ruby -- I don't think there really is one,
> though that's not entirely a bad idea. Just mostly a bad idea.
JRuby and Quercus, maybe? :)
Seriously, I'm not even sure it's that bad of an idea. Writing Java in
Ruby certainly works well; why shouldn't writing PHP in Ruby?
Of course, that's only if you're stuck with Wordpress to begin with. I
agree that something like Mephisto is probably a better choice.
Best,
--
Marnen Laibow-Koser
http://www.marnen.org
mar...@marnen.org
--
Posted via http://www.ruby-forum.com/.
pharrington
Well, JRuby is Ruby running under the JVM, which I wouldn't quite call
"writing Java in Ruby." The JVM has alot going for it: fantastic
performance, rich set of libraries, everything runs it, threads that
run in parallel, etc. I don't see any of those benefits for trying to
get Ruby interoperability with PHP.
David Masover
> On Dec 7, 4:41 pm, Marnen Laibow-Koser <mar...@marnen.org> wrote:
> > Seriously, I'm not even sure it's that bad of an idea. Writing Java in
> > Ruby certainly works well; why shouldn't writing PHP in Ruby?
> Well, JRuby is Ruby running under the JVM, which I wouldn't quite call
> "writing Java in Ruby."
In particular, there isn't any sort of PHP VM that we could meaningfully
target. We'd be compiling Ruby to PHP, at best. JRuby doesn't compile Ruby to
Java, it compiles Ruby to JVM bytecode.
The rest of this is true, also:
> The JVM has alot going for it: fantastic
> performance, rich set of libraries, everything runs it, threads that
> run in parallel, etc. I don't see any of those benefits for trying to
> get Ruby interoperability with PHP.
The "rich set of libraries" is the only benefit I can see for PHP, and I'm
very skeptical -- not just of quantity, but of quality.
Edward Middleton
> Has there any been an effort to make a ruby Wordpress port? ...
>
> I guess in general, this is a question about the lack of CMS's in
> ruby. THe general comments usually are, why have a cms when we can
> make it in rails so much fast? I agree with the point that Rails is
> quite mature and robust to handle making any type of site very
> quickly. There is one problem, this is contingent on knowing Ruby on
> Rails. To help further Ruby's cause perhaps people should come to
> together to port a few proper CMS's or at least add some sort of
> compatibly.
>
Have you looked at the typo blog[1], I am not really familiar with
wordpress so can't comment on how typo compares, but it does support
themes, plugins and internationalization. Customizing or extending typo
would probably be easier then trying to port wordpress to ruby.
Edward
Ryan Davis
On Dec 7, 2009, at 18:08 , Edward Middleton wrote:
> Have you looked at the typo blog[1], I am not really familiar with
> wordpress so can't comment on how typo compares, but it does support
> themes, plugins and internationalization. Customizing or extending typo
> would probably be easier then trying to port wordpress to ruby.
as long as you take care not to enter its event horizon, you'll be fine.
Marnen Laibow-Koser
> On Dec 7, 4:41�pm, Marnen Laibow-Koser <mar...@marnen.org> wrote:
>> > though that's not entirely a bad idea. Just mostly a bad idea.
>>
>> --�
>> Marnen�Laibow-Koserhttp://www.marnen.org
>> mar...@marnen.org
>> --
>> Posted viahttp://www.ruby-forum.com/.
>
> Well, JRuby is Ruby running under the JVM, which I wouldn't quite call
> "writing Java in Ruby."
If you're running a Rails app or something in JRuby, I'd agree with you.
However, I was thinking of something along the lines of the app I'm
currently developing with Swing and Monkeybars, where almost every Ruby
class has at least one call to a Java class, and often more. That
really does start to feel like writing Java in Ruby.
I do understand the conceptual difference between Java and JVM bytecode,
though.
> The JVM has alot going for it: fantastic
> performance, rich set of libraries, everything runs it, threads that
> run in parallel, etc. I don't see any of those benefits for trying to
> get Ruby interoperability with PHP.
Everything runs it, every host has it...
..but seriously, it was more of a devil's advocate question.
Best,
--
Marnen Laibow-Koser
http://www.marnen.org
mar...@marnen.org
But to
Marnen Laibow-Koser
> On Monday 07 December 2009 05:05:19 pm pharrington wrote:
>> On Dec 7, 4:41 pm, Marnen Laibow-Koser <mar...@marnen.org> wrote:
>
>> > Seriously, I'm not even sure it's that bad of an idea. Writing Java in
>> > Ruby certainly works well; why shouldn't writing PHP in Ruby?
>
>> Well, JRuby is Ruby running under the JVM, which I wouldn't quite call
>> "writing Java in Ruby."
>
> In particular, there isn't any sort of PHP VM that we could meaningfully
> target. We'd be compiling Ruby to PHP, at best.
Well, there are a couple of PHP compilers, as well as Quercus...
> JRuby doesn't compile
> Ruby to
> Java, it compiles Ruby to JVM bytecode.
Yes, I know.
>
> The rest of this is true, also:
>
>> The JVM has alot going for it: fantastic
>> performance, rich set of libraries, everything runs it, threads that
>> run in parallel, etc. I don't see any of those benefits for trying to
>> get Ruby interoperability with PHP.
>
> The "rich set of libraries" is the only benefit I can see for PHP, and
> I'm
> very skeptical -- not just of quantity, but of quality.
Is this skepticism based on anything other than being a Smug Ruby Weenie
[TM]? I spent about 4 happy, productive years as a PHP developer, and
enjoyed working both with the language and the many good libraries.
Of course, everything's done to higher standards in the Ruby community.
But that's because Ruby's so good, not because PHP's so bad.
Edward Middleton
The current master branch is getting better. It runs on rails 2.3.x and
I am working on a ruby 1.9 support.
Edward
1. Or wasn't when I deployed it ;) http://blog.vortorus.net/
David Masover
> David Masover wrote:
> > In particular, there isn't any sort of PHP VM that we could meaningfully
> > target. We'd be compiling Ruby to PHP, at best.
>
> Well, there are a couple of PHP compilers, as well as Quercus...
Ah, point taken. So we could use the JVM after all.
> > The "rich set of libraries" is the only benefit I can see for PHP, and
> > I'm
> > very skeptical -- not just of quantity, but of quality.
>
> Is this skepticism based on anything other than being a Smug Ruby Weenie
> [TM]?
No, not really...
Well, ok, there are a few complaints.
First of all, PHP had object-orientedness tacked on after the fact. Now, this
can be done well, and it can be done poorly. In PHP's case, it was done poorly
-- I'd almost rather not use them at all.
By contrast, Perl implemented OO rather well, and it did so _after_ modules
were implemented. Indeed, Perl libraries were already well-namespaced and easy
to transform into something object-oriented -- and I found CPAN to be of
consistently high quality, especially the documentation.
Second, just look at the number of global functions in PHP. I'm not talking
about the ones you'll write yourself, but the ones that are built into the
language. Even Perl is better about this, and Javascript certainly is.
And there's the inconsistency, and layers of cruft from Really Bad decisions.
Stuff like mysql_escape_quotes. Or is it escape_quotes_mysql? Or maybe
mysql_really_escape_quotes? I always forget, and using the wrong one will
either corrupt my data or leave me open to SQL injection -- nevertheless, I
must use it on every single database operation.
Even Rails supports the idea of placeholder values (when you need to touch SQL
at all), and this is commonplace at the database API in Perl -- the idea of
prepared statements comes to mind. This is a much easier habit to maintain --
and more efficient, too.
So the language itself doesn't lend itself to particularly high quality in the
first place.
I mean, think of the design of it, too. The syntax alone, the fact that every
file is essentially already a template -- this was never intended to be a
general-purpose language. It was intended to be a template language. It
doesn't even make a very good template language -- Haml is better, even if you
don't consider the fact that it's tied to Ruby.
Add to that, one of the problems PHP shares with Ruby is its low barrier of
entry, being perceived as an "easy" language -- only PHP seems to have this to
a greater degree. People who learn Ruby and Rails are at least trying to learn
to program. People who learn PHP usually start as designers, who learn a bit
of HTML and CSS, and need a tiny bit of server-side logic in their HTML page,
so they learn a bit of PHP or paste a bit of code in...
For that matter, I'd guess the better developers would see that there are
better languages, and would migrate away from PHP, in the long run.
Now, this is all circumstantial evidence. It's possible there's a large, well-
organized community of quality PHP software. Maybe things have changed since I
last used it.
But I've also been on two language rants in the past two days, and I should
stop.
> I spent about 4 happy, productive years as a PHP developer, and
> enjoyed working both with the language and the many good libraries.
Good for you. Hey, I've seen Drupal. I was amazed -- there are things I
strongly dislike about it, but here was object-orientation, modules, mixins,
all kinds of good stuff. Sure, it was completely hacked together, and not at
all supported by the standard, but it was decent.
This would be the main argument for creating some sort of Ruby bindings --
because then we could write Drupal plugins in Ruby.
But it would end in tears. As I said, Drupal (at least, last I checked) hacks
these things together. I'm fairly sure it doesn't even use PHP's own object-
orientedness, as it predates that, and certainly predates its widespread
adoption -- thus, while PHP and Ruby both support objects, you'd have to write
Drupal-specific bindings to get any meaningful objects relating to Drupal
stuff.
> Of course, everything's done to higher standards in the Ruby community.
> But that's because Ruby's so good, not because PHP's so bad.
Ruby, and Perl, and Python, are so good? ...and Erlang, and io?
In fact, the only language I can think of in this niche that I dislike more
than PHP is Visual Basic.
James Britt
>
> Well there are some well-known Ruby CMSeseses.
>
> Have you looked at Radiant CMS? http://radiantcms.org/
I've been building up a fairly complex site using Radiant, and it's
really sweet.
Better to write and/or improve extensions for Radiant than porting
something from PHP with dubious architecture.
--
James Britt
www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff
www.neurogami.com - Smart application development
Marnen Laibow-Koser
David Masover wrote:
> On Monday 07 December 2009 10:11:18 pm Marnen Laibow-Koser wrote:
>> David Masover wrote:
>
>> > In particular, there isn't any sort of PHP VM that we could meaningfully
>> > target. We'd be compiling Ruby to PHP, at best.
>>
>> Well, there are a couple of PHP compilers, as well as Quercus...
>
> Ah, point taken. So we could use the JVM after all.
Perhaps.
>
>> > The "rich set of libraries" is the only benefit I can see for PHP, and
>> > I'm
>> > very skeptical -- not just of quantity, but of quality.
>>
>> Is this skepticism based on anything other than being a Smug Ruby Weenie
>> [TM]?
>
> No, not really...
>
> Well, ok, there are a few complaints.
>
> First of all, PHP had object-orientedness tacked on after the fact. Now,
> this
> can be done well, and it can be done poorly. In PHP's case, it was done
> poorly
> -- I'd almost rather not use them at all
True. I've used very little of PHP's OO. I was really an OO skeptic
until about the same time I started using Rails.
>
> By contrast, Perl implemented OO rather well, and it did so _after_
> modules
> were implemented. Indeed, Perl libraries were already well-namespaced
> and easy
> to transform into something object-oriented -- and I found CPAN to be of
> consistently high quality, especially the documentation.
>
Generally so. But Perl is awful for writing Web applications.
> Second, just look at the number of global functions in PHP. I'm not
> talking
> about the ones you'll write yourself, but the ones that are built into
> the
> language. Even Perl is better about this, and Javascript certainly is.
>
I'm not sure I understand your point. PHP was obviously designed
primarily as a procedural language, so it's sort of appropriate for
there to be lots of global functions.
> And there's the inconsistency, and layers of cruft from Really Bad
> decisions.
> Stuff like mysql_escape_quotes. Or is it escape_quotes_mysql? Or maybe
> mysql_really_escape_quotes? I always forget, and using the wrong one
> will
> either corrupt my data or leave me open to SQL injection --
> nevertheless, I
> must use it on every single database operation.
No. There are far better DB libraries than the built-in ones.
>
> Even Rails supports the idea of placeholder values (when you need to
> touch SQL
> at all), and this is commonplace at the database API in Perl -- the idea
> of
> prepared statements comes to mind. This is a much easier habit to
> maintain --
> and more efficient, too.
And possible in PHP. Everything I ever did in PHP used the Pear DB or
MDB2 library, both of which support prepared statements. I learned that
trick back in my ColdFusion days, and wouldn't have given it up in PHP.
>
> So the language itself doesn't lend itself to particularly high quality
> in the
> first place.
WTF? Just because the standard DB library has problems, you make this
sweeping conclusion? Isn't that kind of like concluding that Ruby sucks
because TMail and REXML are awkward?
>
> I mean, think of the design of it, too. The syntax alone, the fact that
> every
> file is essentially already a template -- this was never intended to be
> a
> general-purpose language. It was intended to be a template language. It
> doesn't even make a very good template language -- Haml is better, even
> if you
> don't consider the fact that it's tied to Ruby.
Yeah, PHP started as a template language, and it shows. But you don't
have to use it that way. It's possible -- and recommended -- to write
entire PHP files without any HTML in them. It looks more or less like
Perl. It's not going against the spirit of the language at all.
>
> Add to that, one of the problems PHP shares with Ruby is its low barrier
> of
> entry, being perceived as an "easy" language -- only PHP seems to have
> this to
> a greater degree. People who learn Ruby and Rails are at least trying to
> learn
> to program. People who learn PHP usually start as designers, who learn a
> bit
> of HTML and CSS, and need a tiny bit of server-side logic in their HTML
> page,
> so they learn a bit of PHP or paste a bit of code in...
You could say the same about JavaScript -- people learn to write a line
or two at a time, so they never really learn to use the language. Both
JavaScript and PHP are pretty good languages if you allow them to be
rather than considering them extensions of HTML.
>
> For that matter, I'd guess the better developers would see that there
> are
> better languages, and would migrate away from PHP, in the long run.
That's what happened to me -- but it wasn't PHP's language features that
did it. It was the fact that TDD was more feasible in Rails than in any
PHP framework I could find.
>
> Now, this is all circumstantial evidence. It's possible there's a large,
> well-
> organized community of quality PHP software.
There is. Maybe not enough, but there is. (MediaWiki, for example, as
well as any PEAR library I've ever used...)
> Maybe things have changed
> since I
> last used it.
Maybe you never really learned what you could do with it -- as witness
your ignorance of DB library options.
>
> But I've also been on two language rants in the past two days, and I
> should
> stop.
:)
>
>> I spent about 4 happy, productive years as a PHP developer, and
>> enjoyed working both with the language and the many good libraries.
>
> Good for you. Hey, I've seen Drupal. I was amazed -- there are things I
> strongly dislike about it, but here was object-orientation, modules,
> mixins,
> all kinds of good stuff. Sure, it was completely hacked together, and
> not at
> all supported by the standard, but it was decent.
That must have been Drupal 6. Drupal 5 was horrible -- basically
reinventing OO in a fragile procedural way.
>
> This would be the main argument for creating some sort of Ruby bindings
> --
> because then we could write Drupal plugins in Ruby.
>
> But it would end in tears. As I said, Drupal (at least, last I checked)
> hacks
> these things together. I'm fairly sure it doesn't even use PHP's own
> object-
> orientedness,
Drupal 6 was a complete rewrite, and I believe it does use PHP OO.
> as it predates that, and certainly predates its widespread
> adoption -- thus, while PHP and Ruby both support objects, you'd have to
> write
> Drupal-specific bindings to get any meaningful objects relating to
> Drupal
> stuff.
>
>> Of course, everything's done to higher standards in the Ruby community.
>> But that's because Ruby's so good, not because PHP's so bad.
>
> Ruby, and Perl, and Python, are so good? ...and Erlang, and io?
>
> In fact, the only language I can think of in this niche that I dislike
> more
> than PHP is Visual Basic.
VB is brain-dead. PHP is not, at least if you don't try to use its OO
features to any great extent.
I'm sorry, but it's obvious that you don't know what you're talking
about with respect to PHP.
David Masover
> [Warning: no Ruby content whatsoever.]
Nice disclaimer!
> Generally so. But Perl is awful for writing Web applications.
How so?
Because I'd definitely disagree here. I think Perl is generally useful -- and
I think Ruby is also generally useful. I just think Ruby is prettier and much
easier to work with than Perl.
> > Second, just look at the number of global functions in PHP. I'm not
> > talking
> > about the ones you'll write yourself, but the ones that are built into
> > the
> > language. Even Perl is better about this, and Javascript certainly is.
>
> I'm not sure I understand your point. PHP was obviously designed
> primarily as a procedural language, so it's sort of appropriate for
> there to be lots of global functions.
Even supposing it was... Erlang is designed as a pseudo-functional language,
and it still has the concept of namespaces. I realize PHP has namespaces, but
I wasn't seeing them actually used, and there's still a bunch of cruft that
seems to be from before PHP realized namespaces were a good idea.
> Everything I ever did in PHP used the Pear DB or
> MDB2 library, both of which support prepared statements. I learned that
> trick back in my ColdFusion days, and wouldn't have given it up in PHP.
I'll grant this point -- I guess it had to be solved at some point.
> > So the language itself doesn't lend itself to particularly high quality
> > in the
> > first place.
>
> WTF? Just because the standard DB library has problems, you make this
> sweeping conclusion? Isn't that kind of like concluding that Ruby sucks
> because TMail and REXML are awkward?
I actually kind of like TMail, though REXML has been improved on.
No, the point is that in a default PHP setup, there's tons of this stuff.
Again, from the global function count alone... It wouldn't be so bad if there
was some kind of convention to them, but there isn't.
There was a much better thought out rant against PHP, by a Perl guy, who made
this point very well:
To summarize it:
- Arguments and return values are extremely inconsistent. That's with
standard PHP libraries.
- PHP has separate functions for case insensitive operations -- and these are
inconsistently named. (Contrast to Ruby, where I can add /i to a regex, or I
can just downcase the string.)
- Continuing on that theme, functions are inconsistently named.
- Scoping. Seriously.
- Too many functions.
Wow, I'd forgotten most of the reasons I hate PHP!
For what it's worth, though, the "modularity" section may not apply -- PEAR
may have solved that.
He updates it for php5 here:
This didn't really fix anything in the above list, but added classes, so he
criticizes the PHP object model. But then, you agreed that the object model
wasn't that good, so I won't care.
It did, however, add exceptions. But since they were added after the fact,
they're probably about as useful as they are in Perl. In Ruby, nothing (except
ActiveRecord, apparently) ever just returns an error, it raises an exception
if something's wrong. This means no silent errors. Noisy errors are a Good
Thing.
In Perl, while there is a strange way to deal with exceptions, nothing uses
them. Perl objects tend to return a false value when something goes wrong.
> > I mean, think of the design of it, too. The syntax alone, the fact that
> > every
> > file is essentially already a template -- this was never intended to be
> > a
> > general-purpose language. It was intended to be a template language. It
> > doesn't even make a very good template language -- Haml is better, even
> > if you
> > don't consider the fact that it's tied to Ruby.
>
> Yeah, PHP started as a template language, and it shows. But you don't
> have to use it that way. It's possible -- and recommended -- to write
> entire PHP files without any HTML in them.
I realize this. My point is that many of the design decisions of a template
language -- very simple syntax, just sprinkle some global functions, the
assumption that no one will ever write anything huge in this -- all of this
leaves a lot to be desired when you want to use it for something else.
Perl started out as a report language, but it's at least extracted the
"format" concept into a separate module.
To make it even more perverse, even PHP people tend to use other template
languages (like Liquid) instead of PHP, to do their templating in PHP. This is
profoundly ironic to me. I suppose next thing you know, Liquid will become
Turing-complete, people will be writing Liquid apps, and we'll need a
safe/better template language for Liquid?
> > People who learn PHP usually start as designers, who learn a
> > bit
> > of HTML and CSS, and need a tiny bit of server-side logic in their HTML
> > page,
> > so they learn a bit of PHP or paste a bit of code in...
>
> You could say the same about JavaScript -- people learn to write a line
> or two at a time, so they never really learn to use the language. Both
> JavaScript and PHP are pretty good languages if you allow them to be
> rather than considering them extensions of HTML.
Oh, I agree. And just because some people learn Rails because it's easy, and
never bother to learn Ruby the language, isn't really a point against Ruby or
Rails. But then...
Javascript is a FAR better language than PHP.
Javascript has first-class functions (which are also closures), a decent
object system including prototypal inheritance, and the unification of objects
and hashes (combined with that prototypal inheritance) means you can build
your own inheritance system, or use classical inheritance...
It could almost be called multi-paradigm.
Frankly, the only reason I use Ruby instead of Javascript (where I do) is I
like Ruby syntax better, and Ruby actually has bindings to native stuff I can
use (there's no Javascript filesystem API that I know of). I mean, with v8,
Javascript is even _faster_ than Ruby.
So, scratch the surface of Javascript, and it becomes a truly elegant
language. A lisp in disguise.
Scratch the surface of PHP, and it's... more PHP. The next step in the
evolution of a PHP coder is probably to learn another language.
> > For that matter, I'd guess the better developers would see that there
> > are
> > better languages, and would migrate away from PHP, in the long run.
>
> That's what happened to me -- but it wasn't PHP's language features that
> did it. It was the fact that TDD was more feasible in Rails than in any
> PHP framework I could find.
Now look at BDD, and at rspec. Or maybe rake.
Can you imagine building anything like that in PHP?
> > Maybe things have changed
> > since I
> > last used it.
>
> Maybe you never really learned what you could do with it -- as witness
> your ignorance of DB library options.
Probably -- I was mostly working with Wordpress and Drupal.
> > Good for you. Hey, I've seen Drupal. I was amazed -- there are things I
> > strongly dislike about it, but here was object-orientation, modules,
> > mixins,
> > all kinds of good stuff. Sure, it was completely hacked together, and
> > not at
> > all supported by the standard, but it was decent.
>
> That must have been Drupal 6. Drupal 5 was horrible -- basically
> reinventing OO in a fragile procedural way.
It actually might have been Drupal 5.
> Drupal 6 was a complete rewrite, and I believe it does use PHP OO.
Yeah, so it would've been Drupal 5 that I was using.
> VB is brain-dead. PHP is not, at least if you don't try to use its OO
> features to any great extent.
Or its reflection. Or the features it doesn't have...
> I'm sorry, but it's obvious that you don't know what you're talking
> about with respect to PHP.
I have a feeling I should be glad of that.
But just a quick test to see if it's worth learning more again:
Does PHP have closures yet? Or even anonymous functions?
I'll give you this: Languages evolve. It's possible I don't know what I'm
talking about. It's possible the tnx.nl guy no longer knows what he's talking
about. It's possible that PHP will one day evolve into a beautiful language,
or at least a decent one, leaving me only able to grumble about syntax and
snipe at the <? at the top of each file.
On the other hand, from what I _do_ know of PHP, I can still name four or five
better languages off the top of my head. Why would we want to evolve PHP into
a good language when we have so many good languages already?
Rimantas Liubertas
> can be done well, and it can be done poorly. In PHP's case, it was done poorly
> -- I'd almost rather not use them at all.
Are you talking about PHP4 or PHP5 there?
> By contrast, Perl implemented OO rather well,
Now that's funny.
> And there's the inconsistency, and layers of cruft from Really Bad decisions.
> Stuff like mysql_escape_quotes. Or is it escape_quotes_mysql? Or maybe
> mysql_really_escape_quotes? I always forget, and using the wrong one will
> either corrupt my data or leave me open to SQL injection -- nevertheless, I
> must use it on every single database operation.
No, you must not.
>
> Even Rails supports the idea of placeholder values (when you need to touch SQL
> at all), and this is commonplace at the database API in Perl -- the idea of
> prepared statements comes to mind. This is a much easier habit to maintain --
> and more efficient, too.
PHP has that support too, what's the problem?
>
> So the language itself doesn't lend itself to particularly high quality in the
> first place.
You can write Fortran in any language.
> Add to that, one of the problems PHP shares with Ruby is its low barrier of
> entry, being perceived as an "easy" language -- only PHP seems to have this to
> a greater degree. People who learn Ruby and Rails are at least trying to learn
> to program. People who learn PHP usually start as designers, who learn a bit
> of HTML and CSS, and need a tiny bit of server-side logic in their HTML page,
> so they learn a bit of PHP or paste a bit of code in...
That's BS. I can argue there are plenty designers starting with RoR as the
first server side code that cannot tell Ruby from Rails.
> Now, this is all circumstantial evidence. It's possible there's a large, well-
> organized community of quality PHP software. Maybe things have changed since I
> last used it.
They sure did.
> But I've also been on two language rants in the past two days, and I should
> stop.
Definitely.
Regards,
Rimantas
--
http://rimantas.com/
David Masover
> > First of all, PHP had object-orientedness tacked on after the fact. Now,
> > this can be done well, and it can be done poorly. In PHP's case, it was
> > done poorly -- I'd almost rather not use them at all.
>
> Are you talking about PHP4 or PHP5 there?
It was PHP5, when I was doing this, but it was also a long time ago.
> > By contrast, Perl implemented OO rather well,
>
> Now that's funny.
How so?
> > So the language itself doesn't lend itself to particularly high quality
> > in the first place.
>
> You can write Fortran in any language.
The question isn't whether you can or can't -- you can write Lisp or Ruby in
any language, too. It's Turing-complete, and you can always write a
preprocessor.
The question is, what does the language encourage? Is it easy to write good
code, and hard to write bad code, or vice versa? Is there syntactic sugar for
good habits, and syntactic vinegar for bad ones?
Compare any of these to C. You probably could write a web app in C. You
probably could be about as efficient with it. You could be disciplined enough
to never do pointer arithmetic, to never make assumptions about pointer size
(and thus be 64-bit clean), to always use exactly the appropriate methods to
operate on a data structure, and to maintain a consistent naming convention.
You could commit to always using a proper string structure, rather than using
null-terminated arrays of bytes.
After all, Ruby itself is written in C, and I'm guessing PHP is, also.
If you did it in C++, you could even fake some decent-looking syntax.
The question is, first, do you really want to spend the months of development
needed to make this easy in C? And second, wouldn't you rather have a language
that makes this stuff easy, and makes it hard for you to accidentally use an
uninitialized pointer, or make a buffer overflow?
Think about that for a moment. In languages like Ruby and PHP, a buffer
overflow is actually not possible. You might get it in a third-party library
written in another language (like C), but you can't do it yourself. But in C,
it's not only possible, it's a very easy mistake to make, and a hard one to
avoid.
> > Add to that, one of the problems PHP shares with Ruby is its low barrier
> > of entry, being perceived as an "easy" language -- only PHP seems to have
> > this to a greater degree. People who learn Ruby and Rails are at least
> > trying to learn to program. People who learn PHP usually start as
> > designers, who learn a bit of HTML and CSS, and need a tiny bit of
> > server-side logic in their HTML page, so they learn a bit of PHP or paste
> > a bit of code in...
>
> That's BS. I can argue there are plenty designers starting with RoR as the
> first server side code that cannot tell Ruby from Rails.
I'd agree with you. The question is, how much of each is happening?
And, in particular, I see this happening in PHP with _designers_. I don't see
nearly as much of that happening in Ruby -- they at least acknowledge that
they're going to be _developers_, even if it's their first language.
Seebs
> Compare any of these to C. You probably could write a web app in C. You
> probably could be about as efficient with it. You could be disciplined enough
> to never do pointer arithmetic,
This is hardly necessary. Pointer arithmetic can certainly be done safely.
> Think about that for a moment. In languages like Ruby and PHP, a buffer
> overflow is actually not possible. You might get it in a third-party library
> written in another language (like C), but you can't do it yourself. But in C,
> it's not only possible, it's a very easy mistake to make, and a hard one to
> avoid.
I'm not sold on this. I don't think I've had any buffer overflows in my
code in years. It's pretty easy -- if I'm about to use a buffer, I make
sure I know what I'm using it for and that I cap any copies and/or report
failure if there's not enough space.
I agree that it requires actual effort, as opposed to being implicit.
FWIW, I hate PHP. I had to learn it once, and I still have to think about
bleach any time I have to think about it. The killer for me was discovering
that there was a thing like a function pointer which could be used only
for user-defined functions, not built-in functions.
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
David Masover
> On 2009-12-08, David Masover <ni...@slaphack.com> wrote:
> > Compare any of these to C. You probably could write a web app in C. You
> > probably could be about as efficient with it. You could be disciplined
> > enough to never do pointer arithmetic,
>
> This is hardly necessary. Pointer arithmetic can certainly be done safely.
Can be. However, the fact that it exists opens the door to a whole class of
weird and hard-to-pin-down crashes (and possible vulnerabilities) that simply
don't happen if you don't (or can't) do it.
But that wasn't my point. My point was that if you consider lack of pointer
arithmetic, garbage collection, and other features to be a selling point of
higher-level languages, you can do all that in C, and you can make it _almost_
automatic in C++.
> > Think about that for a moment. In languages like Ruby and PHP, a buffer
> > overflow is actually not possible. You might get it in a third-party
> > library written in another language (like C), but you can't do it
> > yourself. But in C, it's not only possible, it's a very easy mistake to
> > make, and a hard one to avoid.
>
> I'm not sold on this. I don't think I've had any buffer overflows in my
> code in years. It's pretty easy -- if I'm about to use a buffer, I make
> sure I know what I'm using it for and that I cap any copies and/or report
> failure if there's not enough space.
My favorite example is here:
http://joelonsoftware.com/articles/fog0000000319.html
I like this both for the ludicrous example, when he finally decides to figure
out how much to allocate:
char* bigString;
int i = 0;
i = strlen("John, ")
+ strlen("Paul, ")
+ strlen("George, ")
+ strlen("Joel ");
bigString = (char*) malloc (i + 1);
..and for the ludicrous inefficiency. He's going to scan through each string
at least twice, and that's with a customized strcat -- it gets much worse with
the real strcat.
And remember, his next step is:
char *p = bigString;
bigString[0] = '\0';
p = mystrcat(p,"John, ");
p = mystrcat(p,"Paul, ");
p = mystrcat(p,"George, ");
p = mystrcat(p,"Joel ");
It's still a bit sloppy -- that initial null assignment makes me cringe -- but
think about this. Even if you ignore the fact that we've got each string
duplicated here -- let's say they're variables:
int i = 0;
i = strlen(a) + strlen(b) + strlen(c) + strlen(d);
bigString = (char*) malloc (i+1);
char *p = bigString;
bigString[0] = '\0';
p = mystrcat(p,a);
p = mystrcat(p,b);
p = mystrcat(p,c);
p = mystrcat(p,d);
Now suppose you add a string to that, or remove it. If you add it to one place
and not the other, or remove it from one place and not the other, you're
either wasting RAM or hitting a buffer overrun every time.
Then again, this kind of malloc is probably inefficient, as the article points
out. Instead, you probably want to allocate some power of 2 -- at which point,
you want to make sure you've always allocated a power of two that's more than
you need, not less than you need.
Are you sure you never make a mistake here?
Because this is the kind of thing that I don't have to think about. Yes, it's
less efficient, but if I have a bunch of strings in Ruby, I can just do this:
big_string = a + b + c + d
There are other, more efficient ways, like:
big_string = a.dup << b << c << d
or
big_string = "#{a}#{b}#{c}#{d}"
The point is, though, while these have varying degrees of efficiency, none of
them have the possibility that I'll forget something and open myself up to a
vulnerability or a crash. Worst case, I waste a bit of RAM, and 100% of the
RAM I waste here can be garbage-collected later, whereas in C, if I waste it,
it's wasted, possibly even leaked.
So not only is it ridiculously easier, it's also safer.
It's also possibly faster, because since it's a higher-level abstraction, the
runtime might (in theory; I bet Ruby doesn't) notice that these are all
strings and that you're just concatenating them, so it could use some sort of
StringBuilder automatically.
Even if it doesn't, it still has the option of storing the length of a string
separately, rather than using null-terminated strings -- thus saving you at
least half your time in an operation like ("a" + "b").
Am I being unrealistic? Is this the kind of thing you'd never do?
> I agree that it requires actual effort, as opposed to being implicit.
The point here is that the implicit version also implicitly handles all the
safety for you. Another example might be SQL manipulation. To keep myself
sane, let's do this with Ruby:
execute "select hashed_password from users where username = '#{name}'"
The problem with that code should be blindingly obvious. Of course, I should
probably be doing something like this:
execute "select hashed_password from users where username = '#{escape name}'"
The problem is, this requires me to always, always remember to do it. This is
how a lot of PHP stuff is written, though I'm told it's changing, and those in
the know use libraries that allow you to do it the Right Way. How would the
Right Way look?
execute 'select hashed_password from users where username = ?', name
Can you see why that's safer? I can develop a much easier to maintain habit of
using only single-quoted strings as my queries. Since the actual values are
always passed separately, they are always escaped -- I don't have to remember
anything special to make that work.
So I can develop a very, very simple habit (use single-quoted strings) that I
can almost unconsciously apply everywhere, and I will never be subject to a
SQL injection attack.
Or I can try to develop a habit of manually escaping -- the problem is that
sooner or later, mistakes WILL happen. Best case, I develop such muscle memory
of doing it this way that I end up accidentally doing this:
puts "Hello, #{escape name}!"
That way, worst case, it goes unnoticed for months until someone named
O'Harris signs up and wonders why the system thinks their name is O''Harris or
O\'Harris.
The point is that higher levels of abstraction do allow us to abstract away
opportunities to screw things up. This is true in the language itself, and in
the libraries.
And if I've convinced you of that, don't worry, low-level skill is still
needed. Another of my favorite articles:
http://joelonsoftware.com/articles/LeakyAbstractions.html
It helps to understand what's going on at the C level, even if I never want to
actually touch it, because that might give me some insight as to why
"Hello, #{name}!"
is more efficient than
'Hello, '+name+'!'
Try it yourself:
require 'benchmark'
name = 'steve'
Benchmark.bm do |x|
x.report { 10000000.times { "Hello, #{name}!" }}
x.report { 10000000.times { 'Hello, '+name+'!' }}
end
My results:
user system total real
6.010000 0.020000 6.030000 ( 6.104799)
7.500000 0.010000 7.510000 ( 7.505193)
It only gets better, the more interpolated values you have. a+b is more
efficient than "#{a}#{b}", but a+b+c+d is less efficient than
"#{a}#{b}#{c}#{d}".
This was very surprising to me. Then I went back and read that article, and
thought a bit about the concept of a string builder. Now it makes sense, even
though it's still a bit counterintuitive.
So I'm glad I sort of know C, and I'm just as glad I don't have to use it
much.
> The killer for me was
> discovering that there was a thing like a function pointer which could be
> used only for user-defined functions, not built-in functions.
I could live with that, but I'm guessing it might've been the last straw...
For me, I'm spoiled by blocks now. I can fake them in Javascript, and even
(though less effectively) in Java, but not in PHP, that I know of.
Seebs
> I like this both for the ludicrous example, when he finally decides to figure
> out how much to allocate:
> char* bigString;
> int i = 0;
> i = strlen("John, ")
> + strlen("Paul, ")
> + strlen("George, ")
> + strlen("Joel ");
> bigString = (char*) malloc (i + 1);
size_t len;
len = snprintf(NULL, 0, "%s, %s, %s, %s", "John", "Paul", "George", "Joel");
bigString = malloc(len + 1);
:)
> Now suppose you add a string to that, or remove it. If you add it to one place
> and not the other, or remove it from one place and not the other, you're
> either wasting RAM or hitting a buffer overrun every time.
Which is why snprintf was added.
> Are you sure you never make a mistake here?
Not totally sure, but I don't think I've found one in my code in at least
five years. I'm pretty careful.
Oh, wait! I did have one. It wasn't really in an entirely comparable
context, but there was a case where there was a plain error in the
attempt to count how many copies of a substring I needed space for.
> Am I being unrealistic? Is this the kind of thing you'd never do?
Not really, it's just that it's the kind of thing I do by idiom, and the
idioms are safe and effective.
> The problem is, this requires me to always, always remember to do it. This is
> how a lot of PHP stuff is written, though I'm told it's changing, and those in
> the know use libraries that allow you to do it the Right Way. How would the
> Right Way look?
Heh. Actually, I reinvented this myself, pretty recently; I had to do some
database stuff in PHP (don't ask, it's horrible). So EVERY single usage
looks like:
$foo = do_query("SELECT a, b FROM table WHERE other_id = '%d';", $id);
(note: Yes, I'm passing a number in as a string. I inherited a database
where every foreign key was stored as a VARCHAR string holding the digits
of the number of the foreign table's plain old integer id column. A
chunk of this database made it to the front page of the Daily WTF once.)
> Can you see why that's safer? I can develop a much easier to maintain habit of
> using only single-quoted strings as my queries. Since the actual values are
> always passed separately, they are always escaped -- I don't have to remember
> anything special to make that work.
Yup!
> The point is that higher levels of abstraction do allow us to abstract away
> opportunities to screw things up. This is true in the language itself, and in
> the libraries.
Yes.
> I could live with that, but I'm guessing it might've been the last straw...
It was the point at which I told one of my friends that PHP had finally
achieved the dubious distinction of being the first language I actually
thought was uglier than perl. He told me maybe I should look at Ruby,
and that was probably one of the best bits of advice I've gotten since,
sometime in the tail end of the 80s, someone told me about the distinction
between "works in C" and "works in this particular compiler".
pharrington
As long as we're not talking about Ruby, for years (ironically mostly
since I stopped coding PHP) I've wondered why people always forget
that PHP *does* have SQL prepared statements built into the standard
library (with mysqli). Granted, it's not exactly as slick as anything
in Ruby, but its really not hard to just call prepare() and bind_param
(), or even to take a minute to hack out a function that does this
more concisely. But then I remember, the official guides don't stress
the use of this, and hardly any tutorials even mention it (I've never
read any PHP books, so I can't comment on that state of affairs). But
yeah, the use of a language just goes in the direction of whats
easiest to do with it :\
Seebs
> As long as we're not talking about Ruby, for years (ironically mostly
> since I stopped coding PHP) I've wondered why people always forget
> that PHP *does* have SQL prepared statements built into the standard
> library (with mysqli).
Neat.
Unfortunately, in my case, useless because I was using a fairly
lightly-documented extension to access Some Other Database.
-s
--
Michael Shigorin
> Someone could
"hey it's linux -- you need it, you do it".
Of course it's also reasonable to ask before plunging,
but thinking that someone else will do what one wants
is not how things work: they work as "consider one's
options and work up to something worth showing others".
And _then_ learning (or improving a lot) to work with
those others, even if they're different (but really do
like what you do).
PS: regarding "rich set of libraries", is there at least
some (let alone reasonable) SOAP 1.2+ implementation?
soap4r seems to cover obsolete spec, and I've ran
into that already a few months ago. :( I'm aware of
WSO2 WSF/Ruby but am yet to package and try it.
--
---- WBR, Michael Shigorin <mi...@altlinux.ru>
------ Linux.Kiev http://www.linux.kiev.ua/
Rimantas Liubertas
>
> Unfortunately, in my case, useless because I was using a fairly
> lightly-documented extension to access Some Other Database.
Looks like no one ever heard of PDO:
http://lt2.php.net/manual/en/pdo.prepared-statements.php
And yes it works with Some Other Databases too:
http://lt2.php.net/manual/en/pdo.drivers.php
Regards,
Rimantas
http://rimantas.com/
andrew mcelroy
> Has there any been an effort to make a ruby Wordpress port?
Why hasn't anyone mentioned phuby?
Yeah its kind of cheating, but who cares?
With Phuby you can wrap a php inside a ruby application.
wordpress:
http://www.youtube.com/watch?v=4_zq9oW71sg&feature=related
phuby on phails:
http://www.youtube.com/watch?v=lsWKjS6Vufw
github repo:
http://github.com/tenderlove/phuby
Andrew McElroy
Rimantas Liubertas
>>
>> Now that's funny.
>
> How so?
It's is funny because you got it backwards. PHP5 has OO redesigned from scratch
and Perl has, how to put it mildly, weird understanding how OOP is
done. It was hacked
on and it shows.
It was you who provided this link: http://www.tnx.nl/php5.html. Did
you try to read it
carefully? All it does just tries to justify shortcomings/weirdness of
Perl OOP by looking for
workarounds or calling them "flexibility". Perl does not have
private/protected? No
big deal, you are a masochist if you want to use those.
No abstract classes, no interfaces? No problem. But Perl supports
multiple inheritance,
woohoo! Have you actually seen _how_ Perl implements inheritance at
all? You have
to assign parent's name to special variable @ISA. That's the way to go.
Constants? Perl programmers laugh at them. "Final"? Larry said that's
a bad idea. But
you will have in Perl6, anyway. Static variables? Who needs them.
Exceptions? You have die() and eval() for that. Isn't it elegant:
eval {
…
die …
};
if ($@) {
# handle exception
}
Eat that, try&catch!
He complains about instanceof but does not mind the elegance of constructor in
Perl:
sub new
{
my $class = shift;
my $self = {};
bless $self, $class;
return $self;
}
And notice that "shift"? That's how you pass arguments to your methods. Or use
@_. Flexible and elegant.
He goes on to make fun of PHP4. Yep, OO in PHP4 was a joke, but guess what—Perl4
had no OO, it was all hacked into version 5.
PHP5 may have not the best OO in the world, but to call Perl's OO
implementation done
"rather well" looks like a huuuuuge stretch to me.
I understand very well that some my like or even prefer it this way, but I won't
agree that that makes it any better.
<…>
> The question is, what does the language encourage? Is it easy to write good
> code, and hard to write bad code, or vice versa? Is there syntactic sugar for
> good habits, and syntactic vinegar for bad ones?
Perl does not encourage writing good code any more than PHP does.
And yes OOP in PHP5 looks much better than in Perl5.
<…>
Seebs
>> Unfortunately, in my case, useless because I was using a fairly
>> lightly-documented extension to access Some Other Database.
> Looks like no one ever heard of PDO:
> http://lt2.php.net/manual/en/pdo.prepared-statements.php
Not relevant.
> And yes it works with Some Other Databases too:
> http://lt2.php.net/manual/en/pdo.drivers.php
But not "REAL SQL Server (tm)", a network wrapper around sqlite, for which
the only way to communicate with it is to use a one-off PHP extension which
works only with a specific third-party build of PHP for OS X, and cannot be
used with, say, the standard prebuilt. (The PHP extension is distributed
as a binary, so no recompiling to match different options.)
Let's just say that, in this case, I do not blame PHP for that selection
of problems. PHP is also not to blame for the original developer's decision
to use VARCHAR for all fields except primary keys -- but including foreign
key references to primary keys in other tables.
I had about two weeks to get everything running, and a trivial wrapper
which did the quoting in a consistent way was Good Enough.
Marc Heiler
Just two comments from my side:
"Wordpress is enormous. Porting would be non-trivial."
I agree, and the same is valid for trac (python), mediawiki, wordpress,
phpBB (php), and so on.
But it is good applications which help make a language more widespread.
How many people came to Ruby via RoR?
As far as language design is concerned, I think ruby is a lot better
than PHP.
So why not tackle those areas? I do not believe in "use the right tool
for a job", because this effectively translates to "use the better
application", no matter what language. I can understand speed reasons,
like using C rather than ruby in case you really need the speed.
But I don't *want* to use php. As a user, I don't have to care - I can
use a php-forum, or mediawiki, and never meddle into the ugly php code.
However, if I build my projects with ruby, then I want to use ruby AS
MUCH as possible, simply because using ruby is a lot more fun than using
php (or perl for that matter - I don't really have the same problem with
python, from my point of view ruby and python are much closer these days
than i.e. ruby and php).
Noone has to do a 1:1 porting. Just make the application useful enough
to get a start with it, and extend from there. The old phpbb wasn't that
sophisticated, but it got better and better lateron.
Wordpress has one thing going, which is simplicity (for a USER).
So I think ruby needs some more cool apps, especially web-apps. Whether
these require one to use RoR or not is not so important, but they need
exist.
"Perl does not encourage writing good code any more than PHP does.
And yes OOP in PHP5 looks much better than in Perl5."
Sure, we can argue about this. Ultimately it depends on the developer
writing code. But I think we can all agree that certain languages, let's
say after 3 years of heavy usage, make it significantly harder to
understand what's going on. Take the lisp guys. They reason that the use
of () is no problem for them since they don't even really see them.
Every language design has a big impact of the underlying code. Being
succint is a huge plus of ruby here compared to php and perl. In my
opinion a good language helps people become better developers as well -
by giving them ways to express what they want, and making it as easy as
possible.
After 3 years of php, and comparing it to 3 years of ruby, I can without
a shadow of doubt state that ruby makes it a lot easier to write
beautiful code than php does.