Slashdot Mirror

Personally, my first introduction (at 8) was LOGO, and it was tons of fun, but I didn't make the connection between it and programming until much after I had started to do what I thought was programming (which I started in C). It also might be even too juvenile for 11-14 year olds, if they are sufficiently mature.

I'd suggest Python as a first 'real' programming language. Besides the fact that it has blindingly simple syntax that is often a few characters away from the pseudocode you might explain the program in, at a higher level, it allows for simple iterative programming, procedural programming, functional programming, and object-oriented programming, so students can progress from one level of intellectualism to the next without learning new syntax, and with the interactive shell, demos and exploration are made that much easier.

There's also something called PyLogo, which, though I've never tried it, looks promising:

http://ianbicking.org/docs/PyLogo_lightning.html

If you're a PHP programmer, you're irresponsible if you're not already aware of its flaws, because you have not educated yourself by reading any of the following well publicized articles. Once you understand the flaws of PHP, you can't honestly make the statement that it's a well designed language suitable for teaching programming to kids.

First there is this classic article, Edwin Martin's "What I don't Like about PHP", which goes into detail about the following fundamental flaws:

1. Bad recursion
2. Many PHP-modules are not thread safe
3. PHP is crippled for commercial reasons
4. No namespaces
5. Non-standard date format characters
6. Confusing licenses
7. Inconsequent function naming convention
8. Magic quotes hell
9. Framework seldom used
10. No Unicode
11. Slow

Then there is the mind-set of the PHP language designers and community, which is deeply flawed. Ian Bicking's "PHP Ghetto" article sums up the problem with PHP's design and community pretty well:

I think the Broken Windows theory applies here. PHP is such a load of crap, right down to the standard library, that it creates a culture where it's acceptable to write horrible code. The bugs and security holes are so common, it doesn't seem so important to keep everything in order and audited. Fixes get applied wholesale, with monstrosities like magic quotes. It's like a shoot-first-ask-questions-later policing policy -- sure some apps get messed up, but maybe you catch a few attacks in the process. It's what happened when the language designers gave up. Maybe with PHP 5 they are trying to clean up the neighborhood, but that doesn't change the fact when you program in PHP you are programming in a dump.

Jonathan Ellis' "Why PHP sucks" article makes a lot of good points and links to many other sites with more information to back up the claim that PHP sucks.

He perfectly summarizes the yapping of the PHP apologists when he says: Basically these all boil down to, "I don't have enough experience to recognize PHP's flaws because I haven't used anything better."

He summarizes:

In short, PHP sucks because, PHP's authors are prone to confuse "pragmatism" (a fine design goal, if done well) with "adding random features without considering how they impact the language as a whole." Thus, its authors have found it necessary to correct obvious flaws in both minor and major releases, with the result that the recent PHP5 breaks with the past to an unprecedented degree while still leaving many fundamental flaws un-addressed. I don't know if this is because they didn't recognize those flaws, or more likely, because they were willing to impose "requires a lot of pain to upgrade" but not "requires a complete re-write."

There is also a lot of great stuff about why PHP is so bad on http://www.ranting-wolf.info/category/technology/programming/php/ including a concise description of why the "Smarty" templating system is such a horribly ill conceive and terribly implemented idea.

And if you're still not convinced the design of PHP is deeply flawed, because language design is HARD and should only be attempted on purpose by experienced people, here's what the Father of PHP Rasmus Lerdorf himself said in an ITConversations interview, quoted in "Why PHP sucks, Part III":

"I don't know how to stop it, there was never any intend to writ

Python is a much cleaner language than both PHP and Ruby

PHP is a steaming pile of shit, but Ruby is a fine language for clarity. There's a pretty good comparison (written by a Python programmer) here.

As somebody with a fair pile of Ruby code, I'd say the weakness is not in the language itself (which is excellent) but in the run-time.

Yes, Ruby is the current web development flavor of the month, however, don't get caught up in the hype. There are good number of MVC web development frameworks in other languages, including even Lisp and Smalltalk, but most notably Python. In my opinion it makes more sense to learn a Python framework for a number of reasons. Mainly because Python is used in considerably more non-web applications than Ruby, which makes your skills more portable (and you more employable). Ruby on Rails is also very monolythic, while two of the the three most popular Python frameworks, TurboGears and Pylons are very modular (especially Pylons since it's built around the WSGI spec). Finally, Python compiles to bytecode whereas Ruby does not. Hence Python outperforms Ruby in almost every shootout.

Further reading:
Of snakes and rubies; Or why I chose Python over Ruby
TurboGears and Pylons (a technical comparison)
From PHP to Python (my blog)

If you're interested in this, you'll probably be interested to know about Ian Bicking's work on embedding PHP in Python web applications via PHP's FastCGI support. It's only in the experimental stages, but it's very promising, especially for developers like me who develop with Python but need to support legacy PHP code.

The fact that PHP and MySQL are the most deployed tools for web development is a rather sorry situation, given the deep shortcomings of both tools.

See these articles about the many PHP warts:

Experiences of Using PHP in Large Websites

Why PHP sucks

The PHP Ghetto

You will be happier with a more mature and complete dynamic language like Python, or even (gasp ;-) ) Ruby.

Similarly, see these other articles about the many MySQL warts:

MySQL Hate

MySQL Gotchas

Compare the last one with the one for PostgreSQL:

PostgreSQL Gotchas

Finally, an in-depth comparison between MySQL and PostgreSQL on Slashdot itself:

Comparing MySQL and PostgreSQL 2

Finally, recall that both MySQL's transactional backends are now controlled by Oracle:

Oracle Acquires Sleepycat

Avoid both PHP and MySQL as much as you can, I say. There's better stuff out there.

Ian Bicking weighs in on the relative relative power of Ruby and Python, and makes some interesting observations about "Parrot":

I think Ruby on the Parrot VM works better than Python. But, AFAIK, no real language runs on Parrot at this point (even Perl, for which Parrot was written), it's all experiments. I honestly want Parrot to succede; it's currently the only real effort at a community-driven VM, and the only VM written specifically for dynamic languages. But for some reason they can't get their act together.

I would love if Parrot created an environment where Python, Ruby, Perl, PHP, and other open source languages happily coexisted and shared a basic infrastructure. It doesn't have to mean 100% transparency between languages for it to be useful and successful. But at this point it's hard for me to believe Parrot will catch up to other competing runtime environments.

Parrot was a joke, and still is. If the Parrot developers really understood what they were doing, then they wouldn't be trying to do it that way. It's just a sophmoric exercise in mental masturbation. So it's no wonder that the Parrot project is dead in the water, pushing up daisies!

-Don

To me it seems like a silly exercise to replicate rails in python or what have you.

1. TurboGears is not a Rails clone.
2. Most parts of TurboGears existed before Rails: CherryPy, SQLObject, FormEncode (and Python of course).
3. Kid is most closely related to Zope Page Templates (from the Python world), not anything from Rails.
4. MochiKit has a certain relationship to Prototype (the Javascript library from Rails), and is compatible with it. However, it's not that the author particularly likes Prototype.

Rails has taught us some important lessons, but they aren't really technical lessons:

1. We shouldn't sit around and say "oh, those poor people using PHP/Java/etc, too bad they don't know about what you can do using X". Instead we should talk more loudly and insistently about the advantages of our platforms. If you do it right people will pay attention.
2. We haven't concentrated enough on full-stack integration. We've been overvaluing decoupled pick-and-choose components. Full-stack integration doesn't have to mean coupling -- it can just be a matter of presentation, and making sure tools are complimentary. Not all of the Python frameworks are coming at it from this direction, but TurboGears very much is.
3. Things like screencasts are nice.

After looking at various pieces of Rails, these lessons have stood out to me, but the particular technology in Rails has not. Sure, there are some good ideas, but nothing radical, and there's good ideas everywhere waiting to be mined. We're not beneath mining other people's ideas, but it does not follow that the result is merely a "replication" in part or in whole.

As for Ruby: I think the two languages are largely equivalent in terms of what you can do. I would not say the same about PHP or Java. As for Rails specifically, I think it is only ahead of Python options in the second derivative. With conscious players the second derivative doesn't mean a whole lot.

I think the most promising thick-client app development model is the Model-View-Controller paradigm, as seen in such well-designed app frameworks as Cocoa for OS X, and of course Ruby on Rails, and although I see Skunkworks improving the "typical" drudgery of web-app dev, I would wonder what it provides in the way of code management when it comes time to test your controller without worrying about how the view renders it or the model stores it.

And I know this is a personal preference and all, but... Python's significant whitespace? Yuck... I hope you don't copy/paste much, you might forget a tab somewhere (not to mention, copying from webpages is an adventure in itself...) To me this is like drinking cider instead of beer. Why would anyone consider such a thing worthwhile? Just to avoid some begin/ends or curly braces?

Python does have a more complete library but I am pretty sure Ruby and friends are catching up (and of course, no real word on Parrot yet...) Ruby also just seems to do the whole object-oriented thing nicer (abbreviated getter/setters, everything is an object, no self-referential hacks or whatever...)

I wrote more about the standard library sometime back on my blog.

I wrote more about the standard library sometime back on my blog.

This processor would have precisely no effect on the scalability of Python since the Global Interpreter Lock ensures only one Python thread is run at any one time. See gil-of-doom Stackless appears to have no automatic context switching. Python typically needs multiple processes to utilise true parallel processing made available from multiple cores. Very heavyweight.