While I can't say I'm wholey impressed with CodeIgniter, I'll have to say that it does look like a promising perspective on where the php dev team can go with future versions of php. Given it already has a framework of it's own with pear and pecl, this seems like a promising way to go. I can't say I'm a huge fan of the crazy folder structure some of these frameworks spit out though and being forced to work within them seems like a small pain, the trade-off is pretty good if you want something quick and easy. Although the most depressing portion of CI is the fact that it's still mostly php and you're still mostly writing your own loops and other repetative and annoying bits and pieces to complete it all. Not to mention, you're still writing quite a bit of code to get it all done, where with ruby, it's like 3 lines and you already have a pretty finished product.
class HelloWorld
def initialize
puts "Hello, world"
end
end
# we can instantiate the class in the same script outside the class
# definition
hw = HelloWorld.new
Save as hello.rb and then run it with
$ ruby hello_class.rb
Here endeth the first lesson.
PS: I know now what I do because I copy and paste from here.
i just bought "how to program" from the pragmatic programmer website by chris something or other. i am on page 70 and his writing is making much sense to me. the last time i "programmed" was with BASIC and that wasn't *really* programming, so that should tell you how well the book is working. oh, the reason i mention it is that the language used in the book is Ruby.
i use Bluehost for my online hosting company and they have Ruby on Rails already installed and configured and all that. I just have to learn to build the apps. so far, it's coming along. Ruby just makes sense so far.
Sean, I got that book, too, and I wrote an e-mail to the author when I finished. He was kind enough to give me a page-long reply!
Here's his reply to me (I don't think he'd care that I posted it here, he actually probably appreciates the exposure), and it includes bits and pieces of my own e-mail to him.
> * Honestly the whole "Blocks and Procs" section confused the hell out > of me. Perhaps I'd find it useful one day, but I was having a hard > time imagining the immediate benefits I'd get from it.
Yep... I tried to make it as clear as it is, but it's pretty advances stuff; most mainstream languages don't have anything like it.
First: Closures are super-cool, and once you "get" them, you'll love them. But it's hard to "get" them without writing larger programs, because they help make larger programs easier (*much* easier) to write.
Second: The reason I included them was because I wanted someone reading my book to then be able to move on to the Pickaxe. But the Pickaxe covers blocks and procs so briefly... if you aren't familiar with them, they are hard to pick up. So I did my best to introduce them in a way that made a little more (though still maybe not much) sense.
> My mind is also still infatuated with the concept of > everything in Ruby being an object, and "operators" such as +, -, etc, > are really just methods, and its really simple to extend or edit > "built-in" classes such as Array, String, etc. That's just really > cool!
I know, I love this stuff! But closures are still the feature I miss most when using other languages. Seriously. Because I don't *need* to extend the String class all that often, but I always need closures.
Here's just one real-world example: We have been working on our website recently. It's mostly a picture-organizing website. Some pictures are public, and some are private. (Originals, when we cropped or lightened the public version, near duplicates when we weren't *really* sure which we liked best... what were *you* thinking I meant!?)
To do something to all the pictures, I use code similar to this:
Picture.find_all do |picture|
end
Now, sometimes I want to go over only public pictures, so I might do something like this at first:
Picture.find_all do |picture| if picture.private? next end
end
(or, because I love TIMTOWTDI)
Picture.find_all do |picture| next if picture.private?
end
And I can do something similar for private pictures with "next if !picture.private?". In a small program, this is enough. But if I write this code over and over again (because sometimes I want to show the pictures, but sometimes I want to see who is in them, or just find out the dates for the pictures, or the places...), I start to think "Could I make this better?" In Ruby, yes I can:
Picture.find_private do |picture|
end
And it's so easy! Is it a big improvement? Not if you do it once... but when you start using them a lot, large sections of code that would otherwise be full of "program logic" start to look like english sentences. This is *really nice*.
We also have locations attached to our pictures. Some locations (like "Oslo") are parts of other locations (like "Norway", which is part of "Europe"), so they form a big tree. It sure is nice to be able to say
some_place.each_child do |place|
end
as well as "some_place.each_descendent" and "some_place.each_ancestor" and "some_place.each_picture" and "some_place.each_descendent_picture"...
And rolling-your-own iterators is just one of the things people use closures for (but probably one of the more popular ones). But the point is that they allow you to mutate the language to be more what you need it to be (and that's different for every program).
Mutating the language is the ultimate expression of TIMTOWTDI.
> That being said...I'm not sure I'm suited to be a Rubyist. Ruby is > neat, but the whole Tim Toady thing is just a big problem for me. I'd > almost prefer having a single set way to do things.
Ruby favors "freedom of expression". But, as with the single-line "if" above, it often makes the code *more* readable. (Well, I guess that's open to opinion.) The fact is, you don't *need* to use more than one way to do something, but I think you'll find that you want to, at least in time.
Human languages have a great deal of redundancy. A lot of repetition. Many different ways of saying the same thing. Plenty of options when you want to express something... But they aren't all *exactly* the same, are they? Each one has a different flavor. To a much smaller extent, Ruby feels the same way to me. It feels like a much more *living* language.
> Perhaps that's why > I'm looking at Python - at least on the surface Ruby and Python seem > very similar, yet Python is the opposite of Tim Toady..."there's only > one way to do it."
It certainly is. And many people seem to find this appealing. I can see the appeal, too, to a beginner. (I mean, I *did* try to show only one way to do things in the book, for the most part.) But it seems very limiting in the long run.
Also, I think the whole thing is a false dichotomy. Only at the most basic language level do you have "only one way to do something" in Python. If there was seriously only one way to do something, the language would be so limiting that there would often be *no* way to do something. Programming is still a creative act, which means different people will use different algorithms to solve different problems.
I think (just my opinion here) that the real goal of Python was to have everyone's code be as readable as possible to everyone else. Which is a great goal, of course. But them someone thought, "Oh, that means that everyone's code should look as *similar* as possible!"
WRONG!
I ask you, what's more readable? This:
Picture.find_all do |picture| if picture.private? next end
end
Or this:
Picture.find_private do |picture| end
If there was only one way to do that, it would be the first way (because it's more general).
Basically, I don't think "one way to do it" gives programmers enough credit.
> Speaking of which, I have a quick question about that. You stated that > procs are known in other languages as "closures"? Would this be the > same thing as "lexical closures"?
Yep.
> I've heard that Python does not have > these...do you have any clue if that is true?
Yeah... I've heard that they sort of do, but they can't contain statements (only expressions... basically only small bits of code) and they can only be on one line.
So they are quite crippled compared to what Ruby offers.
Python has some nice points, in all fairness. List comprehensions are cool (though with "map" and "filter" and real closures, you don't need them in Ruby... still, they are cool). And Python can be compiled, so that's cool. I guess. (Though I never miss compiling Ruby, honestly.)
And honestly, they are probably both pretty good languages. The Ruby community is nicer and more helpful/friendly, but the Python community is quite a bit larger. For the most part, both languages attract a lot of people from C/C++ and Java and Perl... but very few people move from Python to Ruby or vice-versa. So that tells me they are both pretty good, but just appeal to different sorts of people.
But, if you'll excuse the bragging, I don't think there's any equivalent to my book for Python!
> Anyway, I just wanted to say thanks a lot for your book. I felt like > in some way a lot of you was put into it.
Just my heart, soul, and three years of my life! In teaching people in person, making a connection is the most important step. So I was really trying to reach through the pages and make that connection. I wanted to "be there" as much as possible.
hey, thanx for that follow up. it's really nice to see the guy write the book and then have the enthusiasm to address your questions and concerns on an individual basis. very cool.
Yeah, since def statements are really just assigning a function to a name, you can use a function really anywhere you would any other variable in Python.
Its very powerful and easy to use. I don't remember if Ruby is the same way.
Comments
class HelloWorld def initialize puts "Hello, world" end end # we can instantiate the class in the same script outside the class # definition hw = HelloWorld.newSave as hello.rb and then run it with
$ ruby hello_class.rbHere endeth the first lesson.
PS: I know now what I do because I copy and paste from here.
Here's his reply to me (I don't think he'd care that I posted it here, he actually probably appreciates the exposure), and it includes bits and pieces of my own e-mail to him.
That's BOO, not Python.
EDIT: And I don't believe VB has ever had closures of any kind. I do see them used in Javascript a bunch though.
def foo(): def myClosure(message): print message return myClosure def bar(): myClosure = foo() myClosure("Hello, world!")The author of that book seems to be under the impression that lambdas are the only way to pass functions around in python.