Re:I have a bit of a bone to pick.
on
Learning PHP 5
·
· Score: 1
I was thinking exactly along the same lines for about four years, happily using PHP for the web, and Perl for the command line.
Then I discovered the world of mod_perl and Perl web development tools. Boy, I was blown away by availability of rich, well-tested and well-documented solutions to the problems that you have to fight with with PHP all the time. I started with PHP, I loved PHP, but now I can say that good PHP programmer's productivity on medium to large apps is about 1/3 - 1/2 of the same of mod_perl programmer, all other things being equal.
I live in Russia, and currently A LOT of machines here are being preloaded with not Windows, but Linux or some domestic clone of DOS. The rationale for PC vendors is that when anyone can get a pirated copy of Windows for something like $3, preloading it adds little value, but makes PCs significantly more expensive.
Perl is an enterprise-grade programming language because its so fast to develop in. Sure, you can write a more readable python program, but six months later you won't be able to read it because you're fired for not doing your job on time.
I'm sorry, but.NET has pretty much invalidated this "speed in the sake of security" argument. It has all that security and not a fraction Java's sluggishnes and memory appetite.
Ad agencies sell clicks and/or impressions, so that's all they care about. While cheated vistors may be completely worthless to the advertiser, ad agency couldn't care less.
The MiG-29 is admittedly an unsuccessful design in terms of maintenance. This is one of the reasons they're phased out and sold cheap by the Russian military.
PHP better for LARGER projects? Come on...
on
PHP 5 RC 1 released
·
· Score: 1
"I love perl. But it's a horrible choice for a large project with many developers"
This is a common misconception among the people who use Perl only for quick hacks. I personally moved to Perl after using PHP for 4 years mainly because it became difficult to use as the projects grew.
Perl has a lot of tools to help you deal with project complexity. Various "strict" and "warnings" pragmas help to fight sloppy code, *plethora* of usefull development support modules, great testing frameworks, embedded documentation standard, etc.
PHP's best quality is simplicity, and therefore fast learning curve. And that's a big win for a beginner or occasional programmer. But larger stuff isn't done by those.
"With PHP, I can make anybody who learned the basics fo C and make them productive in about 48 hours, working on someone else's code"
Oh, please. People without substantial experience in software development don't get to work on large projects. If they do at your place, you're having an HR problem. The kind of code people with "basics of C" and 48-hour training tend to produce has no place in any system of even a moderate size and complexity. Unless you're talking about 100th PHPNuke clone done by school boys for kicks.
One word: listwashing. The spammers are supposed to log in and check for bounces, effectively finding out which addresses on their lists "worked", and which didn't.
1.
Linux, historically, hasn't used any version control for the kernel. I don't have exact data at my fingertips here, but I believe it was somewhere in mid-2.4 days that the kernel began being kept in a public BitKeeper repository.
This is just not true. Linux kernel was being kept in CVS for a long time, if not from the beginning.
2.
the difference between ports and RPM's isn't just that ports compile and RPM's just install.... An RPM is just a binary package.
I wonder how ignorant a sysadmin one needs to be to use Linux and not know about source RPMS. This guy's experience with Linux apparerntly isn't much more than a simple home install.
Why not use Perl? Because competent Perl developers are scarce and expensive, and PHP ones are cheap and available. By "competent" I mean one that knows the platform well, regardless of their general capabilities as a programmer. The gains in development speed and product quality that the Perl platform offers only start to justify higher costs on large or non-trivial projects, which are a small minority.
I was using PHP for four years, and was able to use it to its full potential in about 6 months, with just online docs and one book. About three years ago I moved to Perl, read four books on it, and I still often feel as a newbie. Nevertheless, I think this is the best decision I made in my career as a web developer.
Where did you get this crap? Estonia was one of the most well-doing republics of the Soviet union. Hot water stopped to be a "luxury" around 1940's, as far as I can tell (I'm a former Soviet citizen).
Not an accurate comparison
on
PHP 5 Beta 1
·
· Score: 1
If you want "persistent process outside of the apache process", this is exactly what FastCGI is. PHP can be built as FastCGI application. Although this is, like in-memory session storage, is very rarely used in "any serious, large web applications".
There's absolutely NO PROBLEM getting a decent computer job in Russia, if you're any good. Decent programming skills will earn you enough to live on in virtually any city that's not small (Chelyabinsk is big). I'm a Russian, so I guess I know what I'm talking about.
There's just that kind of people who are reasonably smart, but with ambitions far outweighting their creative abilities. These often become crackers. Living conditions just don't matter here.
As to mafia demanding "protection money" - I really don't see it happening to a company that is barely afloat and works fully within the law. There're just lots of better targes. So I guess this was a consequence, not the cause.
PHP still has several shortcomings that make it a doubtfull choice for serious web development. Worse, there're no signs it's going to recover from them.
I've had my share of PHP development (3+ years) and still have to do some. But since I discovered mod_perl, I avoid going with PHP whenever possible. Three main reasons:
1. Lack of serious content delivery frameworks. With Perl you have Template Tookit (which Slashdot runs, by the way), Mason, Emberl, HTML::Template - all mature, well-documented and used by leading sites. With PHP you have maybe Smarty, which is nice, but its comparison to the above is laughtable.
2. Poor (read: nonexistant) Apache integration. mod_perl lets you access Apache internals, write Apache modules, pre/post-process content, control resource usages and many-many more. There're LOTS of things that can give a great boost to any serious web app, but are simply impossible with PHP.
3. PEAR vs CPAN. I don't think PEAR is ever going to catch up, because it's in the culture. Perl is Unix of the languages - it presents intellectuial challenge and encourages sharing and creativity. PHP does not. There've always been many decent apps for Windows and other non-Unix OSes, but nothing comparable to Unix open source movement. With CPAN vs. other free code repositories it's like this.
If you've been doing web development in PHP for at least 3 years, I seriously suggest you look into what mod_perl has to offer. I truly regret I didn't went with it for some of my PHP apps I now have to maintain.
The first computer screen I ever sat at was one like these on the pictures. When operational, it had every screen row underlined with a dotted line - somewhat akin to lines in a school notebook. The cursor was a triangle pointing down from the top of the character.
Few years later I had a hard time getting used to displays without these dotted lines, like I was afraid of my sloppy writing:)
At the age of 6, my dad dad took me to his workplace which looked exactly like on these pictures (IBM 370, I guess). One of the coolest things was reel-to-reel tape drive that actually PLAYED HYMN of our country (Russia)! The sound was very low and was seemingly made by moving the tape fast in very small steps.
By the way, the purpose of my visit was to play a game called "Klings" - some kind of strategy about alien invasion. It was text-based with some ASCII (or EBCDIC ?) art, had a decent plot and very smart AI.
And the raised floor, under which you could run the cables (or breed mice, which they did at dad's work:), shouldn't it be a must for any geek house?;)
Does the this mean that one can expect browsers to behave in a predictable manner when playing around with HTML documents?
As long as you do things strictly DOM-1 way, current browsers have been working pretty much predictably for quite some time. I develop sophisticated DHTML and test it in IE, Mozilla and Opera, and I never have a problem as long as I use only DOM methods (which can sometimes be quite limiting, but bearable overall).
A lot of people still do pre-DOM legacy DHTML because they have to make 4.x-compatible sites, but that's another story. DOM-2 may be more featureful, but it doesn't promise making cross-browser development any easier. It can make it harder indeed if not implemented accurately and timely among different browsers. Given a lesser incentive to implement it (DOM-1 is OK for most things), I find it quite possible.
there are plenty of dual head cards that meet the needs of most users
Most users are absolutely happy with one monitor. The point is that dual-head is used by pros and geeks who tend to have very elaborate feature needs. One wants top-notch 3D performance, another wants Linux compatibility, third can't live without good video capture, etc.
For the hardware-savvy, there's no need for dual-head cards as long as you can get a decent PCI (think Matrox) card to put in as second and choose ANY available on Earth to run as first. It's just plain common sense: not to limit your choice to a very small portion of the market.
I'm writing this from a machine with two displays and TWO cards: Matrox G400 AGP and Matrox Millenium II PCI. This is what I came to after a long quest for a dualhead setup.
Just a few points:
There're still very few dualhead cards on the marked, thus much less chance to find one with the features you need.
They're generally overpriced, probably because they're percieved as a high-end product.
If you go for one, READ THE FINE PRINT. For example, the dualhead Matrox G450 has a DEGRADED DAC, compared to G400, which isn't noted anywhere but in the raw specs (and NOT in pretty side-by-side comparisons on the Matrox's site)
And while with the dual card setup one card has to be PCI, you can still build a way more powerful combination, compared to any dualhead card.
Slashdot Mirror
I was thinking exactly along the same lines for about four years, happily using PHP for the web, and Perl for the command line.
Then I discovered the world of mod_perl and Perl web development tools. Boy, I was blown away by availability of rich, well-tested and well-documented solutions to the problems that you have to fight with with PHP all the time. I started with PHP, I loved PHP, but now I can say that good PHP programmer's productivity on medium to large apps is about 1/3 - 1/2 of the same of mod_perl programmer, all other things being equal.
It Russia, can buy one in about every computer store.
I live in Russia, and currently A LOT of machines here are being preloaded with not Windows, but Linux or some domestic clone of DOS. The rationale for PC vendors is that when anyone can get a pirated copy of Windows for something like $3, preloading it adds little value, but makes PCs significantly more expensive.
Perl is an enterprise-grade programming language because its so fast to develop in. Sure, you can write a more readable python program, but six months later you won't be able to read it because you're fired for not doing your job on time.
I'm sorry, but .NET has pretty much invalidated this "speed in the sake of security" argument. It has all that security and not a fraction Java's sluggishnes and memory appetite.
It's more a problem with PHP than with anything else - failure to have a unified DBMS driver as about every other scripting language does.
Ad agencies sell clicks and/or impressions, so that's all they care about. While cheated vistors may be completely worthless to the advertiser, ad agency couldn't care less.
The MiG-29 is admittedly an unsuccessful design in terms of maintenance. This is one of the reasons they're phased out and sold cheap by the Russian military.
This is a common misconception among the people who use Perl only for quick hacks. I personally moved to Perl after using PHP for 4 years mainly because it became difficult to use as the projects grew.
Perl has a lot of tools to help you deal with project complexity. Various "strict" and "warnings" pragmas help to fight sloppy code, *plethora* of usefull development support modules, great testing frameworks, embedded documentation standard, etc.
PHP's best quality is simplicity, and therefore fast learning curve. And that's a big win for a beginner or occasional programmer. But larger stuff isn't done by those.
"With PHP, I can make anybody who learned the basics fo C and make them productive in about 48 hours, working on someone else's code"
Oh, please. People without substantial experience in software development don't get to work on large projects. If they do at your place, you're having an HR problem. The kind of code people with "basics of C" and 48-hour training tend to produce has no place in any system of even a moderate size and complexity. Unless you're talking about 100th PHPNuke clone done by school boys for kicks.
One word: listwashing. The spammers are supposed to log in and check for bounces, effectively finding out which addresses on their lists "worked", and which didn't.
He doesn't use the web, by his own admission I read somewhere on his home page.
This is just not true. Linux kernel was being kept in CVS for a long time, if not from the beginning.
I wonder how ignorant a sysadmin one needs to be to use Linux and not know about source RPMS. This guy's experience with Linux apparerntly isn't much more than a simple home install.
Why not use Perl? Because competent Perl developers are scarce and expensive, and PHP ones are cheap and available. By "competent" I mean one that knows the platform well, regardless of their general capabilities as a programmer. The gains in development speed and product quality that the Perl platform offers only start to justify higher costs on large or non-trivial projects, which are a small minority.
I was using PHP for four years, and was able to use it to its full potential in about 6 months, with just online docs and one book. About three years ago I moved to Perl, read four books on it, and I still often feel as a newbie. Nevertheless, I think this is the best decision I made in my career as a web developer.
If this was so, I don't think Amazon.com would have selected Mason as their official templating system and be currently hiring Mason developers.
Where did you get this crap? Estonia was one of the most well-doing republics of the Soviet union. Hot water stopped to be a "luxury" around 1940's, as far as I can tell (I'm a former Soviet citizen).
If you want "persistent process outside of the apache process", this is exactly what FastCGI is. PHP can be built as FastCGI application. Although this is, like in-memory session storage, is very rarely used in "any serious, large web applications".
There's absolutely NO PROBLEM getting a decent computer job in Russia, if you're any good. Decent programming skills will earn you enough to live on in virtually any city that's not small (Chelyabinsk is big). I'm a Russian, so I guess I know what I'm talking about.
There's just that kind of people who are reasonably smart, but with ambitions far outweighting their creative abilities. These often become crackers. Living conditions just don't matter here.
As to mafia demanding "protection money" - I really don't see it happening to a company that is barely afloat and works fully within the law. There're just lots of better targes. So I guess this was a consequence, not the cause.
PHP still has several shortcomings that make it a doubtfull choice for serious web development. Worse, there're no signs it's going to recover from them.
I've had my share of PHP development (3+ years) and still have to do some. But since I discovered mod_perl, I avoid going with PHP whenever possible. Three main reasons:
1. Lack of serious content delivery frameworks. With Perl you have Template Tookit (which Slashdot runs, by the way), Mason, Emberl, HTML::Template - all mature, well-documented and used by leading sites. With PHP you have maybe Smarty, which is nice, but its comparison to the above is laughtable.
2. Poor (read: nonexistant) Apache integration. mod_perl lets you access Apache internals, write Apache modules, pre/post-process content, control resource usages and many-many more. There're LOTS of things that can give a great boost to any serious web app, but are simply impossible with PHP.
3. PEAR vs CPAN. I don't think PEAR is ever going to catch up, because it's in the culture. Perl is Unix of the languages - it presents intellectuial challenge and encourages sharing and creativity. PHP does not. There've always been many decent apps for Windows and other non-Unix OSes, but nothing comparable to Unix open source movement. With CPAN vs. other free code repositories it's like this.
If you've been doing web development in PHP for at least 3 years, I seriously suggest you look into what mod_perl has to offer. I truly regret I didn't went with it for some of my PHP apps I now have to maintain.
I loved to use it in my 8086 assembly and watch how it gives people reading my code a pause ;)
The URL of the article is http://www.mandrakelinux.com/en/future.php3
They're just doomed with such an approach.
The first computer screen I ever sat at was one like these on the pictures. When operational, it had every screen row underlined with a dotted line - somewhat akin to lines in a school notebook. The cursor was a triangle pointing down from the top of the character.
:)
Few years later I had a hard time getting used to displays without these dotted lines, like I was afraid of my sloppy writing
At the age of 6, my dad dad took me to his workplace which looked exactly like on these pictures (IBM 370, I guess). One of the coolest things was reel-to-reel tape drive that actually PLAYED HYMN of our country (Russia)! The sound was very low and was seemingly made by moving the tape fast in very small steps.
:), shouldn't it be a must for any geek house? ;)
By the way, the purpose of my visit was to play a game called "Klings" - some kind of strategy about alien invasion. It was text-based with some ASCII (or EBCDIC ?) art, had a decent plot and very smart AI.
And the raised floor, under which you could run the cables (or breed mice, which they did at dad's work
As long as you do things strictly DOM-1 way, current browsers have been working pretty much predictably for quite some time. I develop sophisticated DHTML and test it in IE, Mozilla and Opera, and I never have a problem as long as I use only DOM methods (which can sometimes be quite limiting, but bearable overall).
A lot of people still do pre-DOM legacy DHTML because they have to make 4.x-compatible sites, but that's another story. DOM-2 may be more featureful, but it doesn't promise making cross-browser development any easier. It can make it harder indeed if not implemented accurately and timely among different browsers. Given a lesser incentive to implement it (DOM-1 is OK for most things), I find it quite possible.
Most users are absolutely happy with one monitor. The point is that dual-head is used by pros and geeks who tend to have very elaborate feature needs. One wants top-notch 3D performance, another wants Linux compatibility, third can't live without good video capture, etc.
For the hardware-savvy, there's no need for dual-head cards as long as you can get a decent PCI (think Matrox) card to put in as second and choose ANY available on Earth to run as first. It's just plain common sense: not to limit your choice to a very small portion of the market.
I'm writing this from a machine with two displays and TWO cards: Matrox G400 AGP and Matrox Millenium II PCI. This is what I came to after a long quest for a dualhead setup.
Just a few points:
And while with the dual card setup one card has to be PCI, you can still build a way more powerful combination, compared to any dualhead card.