I was going to say "Imagine I just quoted your entire third paragraph here", but this comment is going to be so far down the page that making readers scroll back up, count, and then scroll back down would just be mean, so I will quote the whole damn thing:
Behaviour-driven development is also a great tool for the "design the UI first" school of programming, and any project that doesn't follow that school of programming is doing it wrong. (Think of it this way: if you're writing a library, design the API first -- that is to say, write the man page first. If you're writing a web application, mock up the user interface, figure out what the damn thing's going to look like and do all your changing-your-mind about how the UI is going to behave before you start laying down AJAX requests.)
This is very similar to some stuff I wrote a long time ago — particularly the last two paragraphs of the "Interface and Program Better Adapted to Users" subsection.
Needless to say, I completely agree with you. :)
Agile's whole attitude toward documentation (namely, that it's something optional) is one of the things that's always annoyed me about it. I think BDD is a little lightweight, as docs go, but it's damned well better than nothing.
As someone who's been flipping back and forth between PHP, Ruby/Rails, and JavaScript for the past few months: If your style's been going more and more functional, I agree that you should avoid PHP. It has a few sops toward functional programming, but they're pretty weak sauce. In fact, they're downright laughable. Perl's FP options are much better.
Ruby, on the other hand, rather likes FP. In fact, the way I started learning FP was in JavaScript, using Prototype and Scriptaculous... which in turn got all their FP-ness from Ruby and Rails. Ruby likes FP a lot. (Okay, not as much as it likes OO-ness... and one thing it inherited from Perl is that it doesn't enforce either of those things on you. If you want to write procedural Ruby, you actually can... you'll just be wasting most of the language. It'd be like driving a car and never getting past second gear.)
As for Rails and Apache: Phusion Passenger makes it dead easy. If Apache integration was your major stumbling block to Rails adoption, then OMG you have got to check that thing out. Passenger is mod_rails in the sense that it's as easy and tight as mod_perl or mod_php. (I think some other project has the actual "mod_rails" name, but Passenger leaves it in the dust.)
If you like Python, I suspect you will either like Ruby a lot, because there are so many similarities, or hate it, because it's so close and yet so different in so many details. But they occupy very mich the same ecological niche (and Perl used to occupy pretty much the same one, before it faded into the background).
no subject
I was going to say "Imagine I just quoted your entire third paragraph here", but this comment is going to be so far down the page that making readers scroll back up, count, and then scroll back down would just be mean, so I will quote the whole damn thing:
This is very similar to some stuff I wrote a long time ago — particularly the last two paragraphs of the "Interface and Program Better Adapted to Users" subsection.
Needless to say, I completely agree with you. :)
Agile's whole attitude toward documentation (namely, that it's something optional) is one of the things that's always annoyed me about it. I think BDD is a little lightweight, as docs go, but it's damned well better than nothing.
As someone who's been flipping back and forth between PHP, Ruby/Rails, and JavaScript for the past few months: If your style's been going more and more functional, I agree that you should avoid PHP. It has a few sops toward functional programming, but they're pretty weak sauce. In fact, they're downright laughable. Perl's FP options are much better.
Ruby, on the other hand, rather likes FP. In fact, the way I started learning FP was in JavaScript, using Prototype and Scriptaculous... which in turn got all their FP-ness from Ruby and Rails. Ruby likes FP a lot. (Okay, not as much as it likes OO-ness... and one thing it inherited from Perl is that it doesn't enforce either of those things on you. If you want to write procedural Ruby, you actually can... you'll just be wasting most of the language. It'd be like driving a car and never getting past second gear.)
As for Rails and Apache: Phusion Passenger makes it dead easy. If Apache integration was your major stumbling block to Rails adoption, then OMG you have got to check that thing out. Passenger is mod_rails in the sense that it's as easy and tight as mod_perl or mod_php. (I think some other project has the actual "mod_rails" name, but Passenger leaves it in the dust.)
If you like Python, I suspect you will either like Ruby a lot, because there are so many similarities, or hate it, because it's so close and yet so different in so many details. But they occupy very mich the same ecological niche (and Perl used to occupy pretty much the same one, before it faded into the background).