Are you yet to learn your first programming language? Why is it that you're putting it off? If you think it's going to be too hard, like learning a real, spoken language - you are wrong. In fact, you've fallen victim to what I like to call The Big Programming Language Fallacy - the mistaken belief that programming languages are analogous to real languages.

They go through each of their myths and explain what's wrong about them, each building on the previous ones in the list:

• Myth 1: Programming Languages are the 'Languages of Computers'
• Myth 2: Programming Languages are Foreign and Hard to Read
• Myth 3: Programming Languages Take Years to Learn

They point out that, in the case of most programming languages these days, they've been designed to be "readable" and something that can relate to basic terms (a subset of a completely new language).

If you're like me, you've probably read a dozen or two articles about PHP performance in your career. Many of them are quite good, but some are simply flat out wrong, or misinformed. One of the old truisms that has been repeated for as long as I can recall is "don't use readfile() if you have big files, because it reads the whole file into memory and your server will explode." [...] There's just one problem with that age-old truism: It's not true.

He created some benchmarks to illustrate the differences between several of the common methods for working with files via the fread, fpassthru, stream_copy_to_stream and of course readfile. He reports the results based on the runtime and the peak memory usage and noted, ironically, that while the times varied slightly, the memory consumption was exactly the same for all of the approaches. Since there's no real reason not to use "readfile", he looks at three reasons why there might be this stigma attached to it (including the issues that could come up with output buffering enabled).

If there is one PHP related thing that I really hate, then it is definitely the Single Quotes Performance Myth. [...] Let's do a random Google search for "PHP single quotes performance": You will get many results telling you that single quotes are faster than double quotes and that string interpolation is much slower than string concatenation. Most of them advise to use single quotes and concatenation to improve the performance of your application. Let's be clear here: This is pointless.

He did some benchmarking of his own to see how the myth would hold up and, as it turns out, it doesn't - "There is none". His proof compares two strings, one normal single-quoted and the other a double-quoted, and the opcodes they generate. They end up exactly the same. Since it's the opcodes that matter, he recommends using something like APC if you're really worried about the performance. He also includes an example using the token_get_all function of PHP to see how fast the strings run through the lexer too (again, almost no difference).

As an added bonus, he also throws in a bit about string concatenation versus string interpolation with some benchmarking scripts and results of their own.

I ran across an article comparing CakePHP and Symfony and found that the writer had a number of preconceived ideas about CakePHP. These same ideas keep popping up everywhere, used by people looking to get their hate on about CakePHP. I sent a very well-reasoned email to the writer clearing up some of those misconceptions [...] So, in the interest of clarifying things about CakePHP I thought I would share that email, slightly rewritten for this blog posting, but the content is roughly the same.

The post/email covers a few different topics some might have misconceptions about concerning the framework:

• Lack of Documentation
• Scaffolding
• Models are tied to controllers in a 1:1 relationship
• Cake's Ajax and Javascript helpers do not support graceful degradation
• Cake's HTML and Form helpers produces bad markup
• Unit tests are an afterthought
• CakePHP is not an "enterprise capable framework"

I am a PHP developer. Maybe even a halfway decent one. As such, I often find myself engaged in conversations on the subject of web application development in general and PHP in particular. I am continually flustered by the myths, half-truths and outright falsehoods that technical and non-technical people alike hold about this humble programming language.

Some of the points included in his "top ten" list are things like "PHP Encourages Sloppy Code", "PHP is slow because it's interpreted" and "PHP apps all look the same".

There has been a lot of talk about how Smarty, a popular template engine for PHP, is bloated and not useful because PHP is already a templating engine and that you're essentially creating a template engine out of a template engine. As everything I read could just say that it was bloated without backing up their statement, I decided to investigate it myself.

He describes what Smarty is and how to can help you and your site with compiled templates. There's a brief look at the syntax it uses and how it can help make the output of the site simpler than invoking PHP each time. He also gets a bit more indepth on the templating system, showing the process it uses to check the template and update if it needs to.

His conclusion? Smarty isn't that much different than any other kind of simple PHP-based templating language out there. So, what about the slowness? Well, he recommends checking your compiling setting - that's where the overhead is when the pages are loading.

I didn't attend Theo's talk, so the only information that I got was from the blog entries and slides. I realize that this short presentation was humorous, but it still brings up some points that have been nagging at the back of my head for a while now.

The comment in question is part of the Six Reasons PHP Sucks lightning talk.

The comment jokes about the quality of PEAR code. OF course, as Aaron notes, these types of comments aren't anythng new. The real issue at stake is that people don't understand PEAR. To help further the cause behind this (in)famous set of libraries, he's written an article for php|architect to dispell some of the myths.