Blog of Leonid Mamchenkov

I’ve recently posted some of my thoughts on PHP.  If you enjoy the topic, here is an excellent post over at Coding Horror, which reminds why PHP sucks so badly and also why it will stick around for some time to come.

Here is a quote from a wise comment in the discussion of the “Linux system programming” book review:

Build your code with -Wall -Werror (or your compiler’s equivalent). Once you clean up all the crud, that pops up, crank it up with -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith. Once there — add -Wreturn-type -Wcast-qual -Wswitch -Wshadow -Wcast-align and tighten up by removing the no in -Wno-unused-parameter. The -Wwrite-strings is essential, if you wish your code to be compiled with a C++ compiler some day (hint: the correct type for static strings is ” const char *”).
For truly clean code, add -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls.
The people, who wrote and maintain the compiler, are, most likely, several levels above you in understanding programming in general and C-programming in particular. Ignoring the advice their code generates is foolish on your part…
As a minimum, solved warnings will make your code more readable by reducing/eliminating the “Why is he doing this?” questions. More often than not, they point out bugs you would otherwise spend hours chasing with a debugger later.
And they make your code more portable. But if you don’t understand, why a warning is generated — ask around. Don’t just “shut it up”. For example, initializing a variable at declaration is usually a no-no. If the compiler thinks, the variable may be used before being initialized, scrutinize your program’s flow. If you can’t figure out, it may some times be better to disable this one warning temporarily with -Wno-uninitialized to move on, instead of shutting it up for ever by a bogus “= 0″ or some such…

Today I came across something that rather puzzled me at first, seemed irresponsible and such, but was cleared later, upon reading the manual.  When uploading files in PHP, variable $_FILES stores a bunch of information about each file.  One of those stored bits is the MIME type of the file.  I was puzzled with how easy it was to trick PHP into setting a wrong MIME type.  However, documentation clearly says that:

The mime type of the file, if the browser provided this information. An example would be “image/gif”. This mime type is however not checked on the PHP side and therefore don’t take its value for granted.

My favorite (so far) programming language has been born 20 years ago.   It’s been loved and hated.  It’s been praised and damned.  It’s been complimented and criticized.  But all that doesn’t matter.  What matters is that it has been helping people all over the world to solve problems.  Tricky, boring, annoying problems.  It provided enough power to build enterprise grade applications, while still being easy and flexible enough to be the super-glue of many systems.

I’m sure Perl will still be with us in another 20 years.  I wish it to be as useful in that time, as it is now.

Thanks, respect, and best wishes to everyone who created and supported Perl, its community and tools all these years.  Happy birthday!

Steve Yegge has posted yet another of his excellent (and long) rants.  This time he talks about the size of code and why one should jump out of its skin to keep it minimal.

 Most programmers have successfully compartmentalized their beliefs about code base size. Java programmers are unusually severe offenders but are by no means the only ones. In one compartment, they know big code bases are bad. It only takes grade-school arithmetic to appreciate just how bad they can be. If you have a million lines of code, at 50 lines per “page”, that’s 20,000 pages of code. How long would it take you to read a 20,000-page instruction manual? The effort to simply browse the code base and try to discern its overall structure could take weeks or even months, depending on its density. Significant architectural changes could take months or even years.

As I said, it’s a long piece. But it’s worth every paragraph. Even though some Java programmers might be slightly offended by the article, I’m sure it’s not intentional.