Why the Light Has Gone Out on LAMP 443
menion writes to tell us that Cliff Wells has an editorial calling into focus some of the perceived problems with LAMP. Wells calls PHP and MySQL this generation's BASIC citing the Free Online Dictionary of Computing: "BASIC has become the leading cause of brain-damage in proto-hackers. This is another case (like Pascal) of the cascading lossage that happens when a language deliberately designed as an educational toy gets taken too seriously. A novice can write short BASIC programs (on the order of 10-20 lines) very easily; writing anything longer is (a) very painful, and (b) encourages bad habits that will make it harder to use more powerful languages well. This wouldn't be so bad if historical accidents hadn't made BASIC so common on low-end micros. As it is, it ruins thousands of potential wizards a year."
It's just a tool (Score:5, Insightful)
Of course, the "wizards" will recognize a tool its deficiencies and start using something more appropriate.
Bad programmers are still bad programmers! (Score:5, Insightful)
On a day to day basis I'm dealing with systems written by other people, which are held together by duct tape, spit and good-will. PHP is a productive language, just as to a C/C++ developer Python/Ruby etc. is also productive and can lead to very good results.
The problem is when you get pseudo-programmers writing code which uses 'magic_quotes_gpc' as a safety net among other things, and come PHP 6 the 'shit will hit the fan' when everybody realises that with this automatic escaping functionality isn't there any more and their web applications are open for the world to abuse.
I think MySQL should be kept out of the question as it's more coincidence that it ended up being a PHP bed fellow, when PostgreSQL could've been in with a chance given the right circumstances.
At the end of the day bad programmers will write bad code, it's just easy to learn languages (such as Basic and PHP) means they can write more bad code a lot quicker with (arguably) more negative impact when it folds in on it'self.
Just my $0.02.
Bah! (Score:5, Insightful)
What he is suggesting (Score:1, Insightful)
- Don't use MySQL. It's as dumb as it's name. Use PostgreSQL if you need a real database, use sqlite if you don't.
- Don't use PHP, it's sloppy. Use python or perl.
The MySQL/PHP combination has not provne itself. As stated it's left thousands of sites vulnerable to SQL-injection hacks and it's certainly not as durable and reliable as other combinations. Let's look at some of the most popular sites online, and how they cope with ridiculous quantities of traffic
1 - Google. Uses python and their own database servers they developped. Problems? Never.
2 - bbc.co.uk - a GIANT site supplied with continuous news and audio. Runs on perl. Nothing else could cope.
3 - Slashdot. Copes with the traffic that destroys anything it links to. Perl again. Rarely down.
And lastly Wikipedia. Runs with PHP and MySQL! Their servers blow weekly, copious lengths of downtime, search function regularly disabled. Pages are nearly always slow to respond. QED
Re:Unfinished rant (Score:2, Insightful)
He says that he doesn't like Apache either. Just not as much as he dislikes PHP/MySQL.
What's up with the BASIC knocking? (Score:2, Insightful)
BASIC? (Score:5, Insightful)
Sure, it's easy to write crap code in PHP if you don't know what you're doing. It's considerably harder to write crap code (that actually works) in C if you don't know what you're doing. So everyone should use C, so people who don't know what they're doing can't write code? I don't think so.
If you do know what you're doing, you can mostly use good design and practices in PHP - not as well as other languages like Perl (and I assume Ruby and Python), but a hell of a lot better than BASIC which, if I remember correctly, doesn't support local variables, short-circuit evaluation [wikipedia.org], passing arguments to subroutines and returning values, and plenty of other things I can't think of at the moment - let alone OOP. PHP at least tries. On top of that, languages like PHP have functionality built-in or readily available to deal with things like XML, databases and network I/O, so you don't have to write all of that code yourself.
I'm thinking anyone who compares PHP to BASIC either doesn't know BASIC, or doesn't know PHP.
Re:It's just a tool (Score:5, Insightful)
If you want high-performance access to single DB tables (which many webapps do), use MySQL.
If you want to quickly put together a site because your purpose isn't actually maintaining the site but putting up some content, use PHP.
If all you want to do is create a simple program to do a one-off task, use BASIC.
If you want to create a straightforward GUI for a database, use Delphi.
If you want to do something different, use a different tool. Don't bitch about a screwdriver being a bad tool for painting the walls.
Re:What he is suggesting (Score:5, Insightful)
Your examples:
- Google: They use whatever language they want, they've been around since ~1998 when PHP was still a little baby.
- bbc.co.uk - As far as I remember we're looking at progressive development from ~1995, around the time when PHP was only a sparkle in the postmans eye, they've got some very skilled Perl guys and smart sysadmins with years of work already in Perl.
- Slashdot - ~1997 and started out as slow as molasses regular Perl CGI, anybody working on the same website for ~9 years in any language should be able to make it run like a dream.
- Wikipedia ~2001, with initially being implemented in PHP in ~2002 and clustered in ~2003. Running large websites is damn hard, and your exaggeration of the problems is overrated.
When you run into large amounts of traffic the language becomes a small part of the equation, Microsoft.com was running on VBScript (and C++) for several years, most of Yahoo is running on PHP...
Yuch, my mouth tastes like flame bait.
This is silly (Score:5, Insightful)
I understand that the language is getting better with PHP5 and PHP6, but nobody's jumping on board. The majority of LAMP machines out there are running Apache 1 and PHP4 instead of Apache2 and PHP5. At least MySQL 3.23 is finally going out of style and 4.0 is becoming commonplace. But look what's out now: MySQL 5.
I really think PHP is starting to majorly stagnate and fragment. So much so, that given a few years, I can imagine something like Python or Ruby taking away some serious mindshare given a few killer apps using the language.
BASIC's the worst, except for the other lang's (Score:4, Insightful)
Handling everything about the machine is neat, but it's something that honestly just wastes your time if you need a program that: reads a file, processes data and produces output. If that's all I'm doing, then why do I need to operate at a level that the O/S is going to conflict with?
Re:Bad programmers are still bad programmers! (Score:5, Insightful)
Re:Unfinished rant (Score:2, Insightful)
The latter, I suspect. The original Pascal had some mind-numbingly dumb "features", like fixed-length strings.
No, I don't mean just fixed-length buffers like bad C. I mean fixed-length strings. If you wanted to store a five-character string in a variable declared as a 10-character string, you had to pad it out manually with spaces.
Delphi's actually a very nice language. If they hadn't marketed it as a Pascal dialect, it would probably have done much better. Calling it Pascal in a world full of Pascal-haters was a bit like opening a French bistro called "L'homme efféminé" in Texas the day after the invasion of Iraq. That is, not a great business move.
Re:It's just a tool (Score:2, Insightful)
I guess I live in a world where time = money, thus a faster development cycle with Delphi means I can get paid and move on to the next project in record time.
In the web world, it's like PHP vs Java. PHP is the slender, rebellious RAD tool, while Java is the fat, tempermental, old-fogey weapon of choice for people with too much time and money (that means Money^2) to spend. I'm not saying to write every app in PHP, that would be painful, but keep that Java away from the web server! It used to be that we'd write the complex logic in whatever native language we preferred, then simply used Perl/PHP as the glue - the presentation layer. What's so wrong with that practice ? It milked a whole lot more performance out of old server than today's big iron seems to handle.
Re:What he is suggesting (Score:3, Insightful)
I use MySQL myself too, since it's available, free and fast, but I have also ran into the lack of referential integrity and subselects. I've not had to deal with transactions in MySQL yet, since I only use it for CMS's, but I've required transactions at work (using DB2), so I understand the need for it.
As mentioned elsewhere; these are tools, use them where appropriate and use different tools where not.
Weak dynamic languages will die! (Score:2, Insightful)
Dynamic languages are also poor candidates for writing re-usable well tested components, and because of theyre dynamic (anything goes) nature it is harder to produce good intelligent IDE's for them.
The problem with statically typed languages is that they are inherently unproductive as it takes a considerable more code to produce the same outcome that can be written with dynamic code. But with more intelligent IDE's and common features being included into some statically typed languages this productivity gap is closing. If you take into account the maintenance of code (fixing bugs and adding new features) you will almost always be better off using statically typed languages for large scale projects.
With that being said I believe languages like Boo will be the future (C# 3.0+ also looks to be on a very productive path with inclusion of features like type inference, lambda functions etc.). I like Boo cause it is a python-esque language that is statically typed (compiles to
Re:Bad programmers are still bad programmers! (Score:5, Insightful)
PHP is a rather boring C-like language, with some semi-serious issues w.r.t. library consistency (compare the call signatures of the various sleep functions), backwards compatibility (PHP3 uses [] for string access, PHP5 uses {}, PHP6 will use [] again...) and possibilities to shoot yourself in the foot (Magic quotes, safe mode, etc.). It is by no means perfect, but I really don't think comparing it to BASIC is fair. Not only does PHP force you to use functions instead of gotos (thogh a special goto-like syntax will probably be added in PHP6), PHP also has a mostly sane Object model, complete with a sane reflection interface, inheritance and everything.
And don't even get me started on MySQL. People talk about ACID, transactions and other high level concepts, but real-world PHP-programmers don't even use joins or subselects. Look at the big, famous open source PHP projects like Joomla and various Forum software. You'll find that the coders generally do multiple selects instead of a single join. They even write loops where they do two or three selects per lap in the loop where a single joined query would be enough. This isn't mysql's fault, mysql has supported joins for a s long as I've used it. This is purely a case of incompetent coders.
So in the end, the tools that are most popular get the blame for the fact that people don't know how to use them. *meh*
Re:Unfinished rant (Score:4, Insightful)
Today's friendly fact check brought to you by the letter "K".
Re:It's just a tool (Score:5, Insightful)
Airplanes suck! (Score:2, Insightful)
Nothing new and wrong conclusion. (Score:5, Insightful)
Being a professional freelance web developer and familiar with various web technologies I can say this guy has got it all backwards.
1) MySQL is not a full blown database. Big news. Would've you thunk? What this guy aparently just discovered the other day or so others have been aware of for years.
I've got more news: Databases in general are pathetic. View logic and transactions just move the problem into the DB and away from the App. They don't really solve it. Object-relational setups and DBs do, but they are still a few years away from widespread use. In that respect Postgres and Oracle are closer to MySQL than to ZopeDB. On top of that, in order to utilize a DB properly you have to know about the problems you'll be facing. And that you learn of best by using flatfiles or it's SQL equivalent: MySQL.
2) PHP is the web generations Basic. Very true. Does it spoil developers? No. The legend of procedural (Basic) coders lost to OOP was spread by academics who were unable to explain OOP in correct terms and context. Meanwhile people wo aren't that arrogant and mix OOP and functional programming whenever they feel like it (Symfony, Rails, Django, Zope) are kicking the collective asses of old-school hardcore 100% polymorphic OOP bloat advocates up and down the street (Java).
LAMP isn't the end all of web technologies. Nobody has ever said otherwise without making himself look extremly silly. But LAMP is a viable solution for any project of any size if the enviroment permits using it. The tools and production pipeline are among the most sohpisiticated FOSS programms around. Half of Googles Database is filled with forum postings and tutorials on PHP. DBDesigner, Clay and MySQK Workbench make working with MySQL so easy and fast that Oracle is seriously concerned about it. A bazillion of available FOSS and commercial tools and solutions for PHP are biting huge chunks away from the serverside Java market, pushing it back to where it belongs: The client.
Bottom line:
LAMP isn't beautifull or notably advanced. Has never been and probably never will be.
But it is:
a) Extremely easy to get rolling with.
b) Used by the largest amount of stable and mature OSS projects.
c) Growing it's featureset and best-pratice compatibility in the same rate the general populace is becoming aware of OOP and what Databases where initially meant for.
d) Nearly so widespread it can be considered a monopoly.
e) Entirely FOSS.
f) A T-Rex-sized Microsoft/Oracle/Macromedia/BEA/[fill in commercial webappserver vendor here] Boogieman.
And that's why it will remain a wide used setup and why that's a good thing.
Poor code is easy to spot (Score:2, Insightful)
One of the merits of PHP (and most scripting/dynamic languages for that matter) is it's transparency: it's easier to spot bad design or sloppy code because all of the code actually does something in relation to the given problem domain.
In comparison, bad designs in an OO language may appear "correct" or even "elegant" on the surface, simply because the glue layers are *meant* to hide the details; adding a pretty "Gang of Four" veneer on top does not make it right.
Re:What's up with the BASIC knocking? (Score:2, Insightful)
> Seriously?
> The only time I can think of is if you just can't find anyone that knows how to program...
It's the best job if you want to quickly knock up something for the Windows platform, say a tool for converting data from one format to another, then sticking the result in a database, especially if you have a few options in a front end. It's nice to be able to manipulate strings and format data on the fly - using the Immediate Window to test things out - without having the tedium of having to allocate memory (in C, for string handling) etc. Sure, if you don't need the front end and you're after speed because you're going to do this conversion often, and there's a lot to convert, then you might want to look at C/C++ using command line parameters. But some of my company's customers would find that a little daunting.
Re:It's just a tool (Score:4, Insightful)
Re:Bah! (Score:3, Insightful)
Basic had goto and gosub, rather than procedures and functions? No decent data structures? No proper error checking?
Welcome to how computers actually work.
Sure it doesn't scale. But it's a good thing to learn about that sort of problem early, because every language and programming tool has scaling problems.
A wizard can do wizard stuff in Basic. A non-wizard is a non-wizard whether he's equipped with Common Lisp or Smalltalk or Objective-C or Algol.
Basic didn't ruin thousands of potential wizards a year, because there aren't that many potential wizards. Realistically? Couple of hundred a year, world-wide. Tops.
Re:Nothing new and wrong conclusion. (Score:4, Insightful)
No, they don't.
And, what problem are you talking about? You mention a problem, but fail to mention just what this problem is.
As far as object-relational databases: they suck far worse than pure relational databases. Relational databases are built on solid computer science-- specifically, set theory, which has its own algebra. Object-relational databases have no such solid foundation, and so are not as rigorously based in actual, real math. Hell, there isn't even a common definition of what an object-relational database is, let alone what problem domain they solve. Also, they don't provide a damned thing not already provided by a good relational database.
Now.
The SQL language sucks. I'll give you that. We could certainly do better. But, at least it's marginally relational, with a complete (though stupid) grammar.
The thing is.... (Score:3, Insightful)
Granted, if they were using, say, Perl, they still probably wouldn't know how to build anything big and important, but PHP in particular provides some simple, obvious, and well-defined mechanisms to implement Bad Coding Practices. Separation of the logic and the content are the first things thrown out the window; PHP's SQL-related functions invite no end of bad design (database-specific query functions instead of something generic like Perl's DBI classes, no prepared statements, practically BEGGING for SQL injection vulnerabilities -- then there's the whole register_globals fiasco, short-tags vs long tags and magic-quotes settings just to keep you excited, and so on and so forth...)
There are other things, too - some will point out the lack of decent namespaces, inconsistent function naming schemes, too many functions that are too similar, and such- many valid complaints, a few silly complaints -- but they pale in comparison to all the Bad Stuff that PHP invites upon itself from novice coders.
Same old story - old is bad, new is better (Score:5, Insightful)
I'm really surprised to see that there are knocks against MySQL, particularly the argument that it could have been PostgreSQL or SQLite. This seems like revisionist history to me - MySQL was THE END ALL AND BE ALL of databases. Referential integrity - who needs it if your programmers have a clue, and anyone arguing for this was an IT weenie or a SUIT. Anyone advocating "real db functionality" was old school and didn't realize the world had moved past them because the only important feature was speed. Boy, how things have changed. Now, his argument must be "all of the
The same was true for Perl - back in the day, Larry Wall was God incarnate, and only an idiot would ever write code to sit behind a web site when you could script it with Perl. Of course, now P stands for PHP. And in this respect, the guy is just a bigot. To quote, "PHP is another sore spot for me. I've gotten to the point that not only will I not write PHP code, I won't even run applications written in PHP (my long search for decent blogging software was due to the restriction that it not be written in PHP)." So, even though there may be a perfect tool for me to solve a problem I need solved, I refuse to use it because it is written in PHP.
So, what happened? Perhaps the problem is that LAMP became popular. A popular undercurrent of sentiment is that if something is popular, then it is no longer l33t, and to express how l33t you are, you need to be a champion for the next "big thing". This shows how cool you are and how much smarter you are than everyone else. The problem is, once the cause that you are championing becomes popular, you are just like everyone else.
One of the arguments for LAMP was that it was easy to create websites. In fact, it was so easy, that you could teach your friends and family how to create web sites with LAMP. The argument was that it was just like BASIC. Now, that it has become popular and it is ubiquitous, the argument against it is that it is just like BASIC.
You just can't seem to win.
Re:BASIC? (Score:5, Insightful)
Weak typing, poor/nonexistent scoping rules and worse yet, auto-vivifying variables, are the big points of irritation.
Having said that, if you avoid trying to use all the "features" of php, and just use it for what it was intended for - web pages (remember, PHP originally stood for "Personal Home Page"), its "good enough" 99% of the time.
I used to write CGIs in c/c++, but I wouldn't want my stuff to share a server with someone else's c CGIs if they've only had, say, 5 years of programming experience. A badly written/implemented c CGI can bring the whole machine down. A badly written php cgi will "just" time out.
So let everyone use the "P" glue scripting language of their choice - Perl, PHP, Python ... whatever floats your boat.
Besides, there's one argument that should carry more weight with slashdotters than any other: More pr0n is served up by the Apache and the P languages than any other solution: specificially, the Netcraft confirms that largest pr0n site in the world is running FreeBSD/Apache/1.3.28 (Unix) PHP/4.3.6.
An excellent scrubbing script (Score:3, Insightful)
Hell, I worked with a kid who had math and CS degrees (I hold two degrees, but neither degree is math or CS) and he littered his code with magic quotes.
The problem is that PHP is left in the wilderness. It's easy to learn, but too powerful to weild. But the C++ers talk it down, so there aren't enough people teaching the right way to use it.
PHP can be brilliant. It can also be a portal into hell.
But, ultimately, empowering new entries into the industry requires that we educate, not intimidate, them.
Elitest and snobbery (Score:2, Insightful)
The problem is that a lot of people have no formal training. They often don't know about even the most basics of computer science. Things like structured programming. For database the features of referential integrity, transactions, and subselects are needed to implement important database concepts if you want software that maintains and extends easiler.
If a langauge or database that actually hinders you from implementing best practices then criticize away. But to criticize a langauge or database because of it allow novices to start creating application is elitist and smells of snobbery.
Rather than take a holier than thou stance of "I don't use PHP" write a tutorial on the best practices to use to make bug-free software in a timely manner. Show how they can use their knowledge of PHP/MySQL to start using better tools or *GASP* even how to use PHP
I write a variety of software for machine controllers, CAD/CAM, to office management. Sometimes I don't get to work with the best langauge because of platform limitation. Sometime I have to work with assembly itself. But yet in all the platforms I use, I find my knowledge of using structured programming and other best practices applicable and helps me write good software.
When we hire other programmer I teach just because we have nothing but jump and conditional jumps in assembly doesn't mean that you stop using structured programming.
Re:It's just a tool (Score:1, Insightful)
Personally, I think that a web application should contain the user facing stuff (CSS, HTML, images, and whatever), and a thin layer of glue code that interacts with the back-end system where all the real work happens. It's nothing more than a pretty user interface to allow people to interact with the rest of the system, and shouldn't really contain anything that needs heavy maintenance. It does three things - it allows the user to see stuff already in the system, it allows the user to interact with the system, and finally it contains basic error checks to make sure the user's not trying to do something that the back-end won't let them do anyway.
If you have a system designed like that, it doesn't matter how maintainable the front end is. If you've changed something in the back-end so much that you need a change in the front-end to match, you're probably going to have to do parts of it from scratch anyway, no matter what you're using. It's far better to have a rapid development system.
Same deal with building applications that have a C++ back-end, and a VB6 front end. Build the back-end with something that's maintainable over the long term, and build the front end in something that allows you to build a front end quickly and easily.
It just happens that, with many web applications, the back end consists of a good database and nothing more. You'd be surprised how much you can get a good database to do.
Re:It's just a tool (Score:5, Insightful)
Customers don't want to pay out the ass again for you to add a simple feature because you didn't take the time to do it properly the first time around.
I say that customers want exactly that. This is the model of software development that Microsoft has adopted from the start and customers can't seem to get enough of it. If customers had really wanted solutions that just worked and didn't have problems, then Unix would have been a much more dominant operating system in the late 80's and early 90's. Instead customers just wanted the next thing from Microsoft that fixed the problems from the previous version. Of course, MS's cheaper price didn't hurt, but true ROI anaysis would have show a "full" solution would have been better, even if more expensive.
Don't get me wrong. While I'm being critical of this tactic by MS, it definately works and has worked extremely well for them. We are always waiting for the next Microsoft os that will "have everything". As Vista has shown, that will never happen, but its really because MS doesn't ever want it to happen.
Because, in reality, thats what customers really want. Delivering now and making them upgrade (or fix) later is really what they expect. It shouldn't be, but it is.
Re:It's just a tool (Score:3, Insightful)
At any rate, I'm speaking from experience, having spent 7 years doing web applications exclusively. I no longer work for them (I left to move to another state), and although we were more expensive than some of our competition, we focused on 'doing it right.' Some customers left to come back later, others knew from day one that it was worth it to pay to do things right the first time.
I still talk to my friends their, and the company is doing very well. Your function as a vendor is not to give the customer exactly what they want, part of it is to educate them on why they should want something different (because in the end, it will work better). Its called 'managing the client.'
Re:It's just a tool (Score:4, Insightful)
Customers can't get enough of the fact that MS gave them exactly what they wanted. Speaking as a developer, their tools (VS) have improved steadly over the years, incorpating features I want and that make my job much easier. The same can be said for thier OS.
Security wasn't there because customers didn't want to pay for it. So MS gave them an insecure OS. Now customers realize security is important. So MS responds with more security. There's more security coming in Vista, and Win2k3 is pretty secure right out of the box, with jsut about everything extra disabled by default.
Your post is just MS bashing. MS gives customers what they want. Sometimes that's not good, because its not in the customers best interest (ie., no security..), but to say customers want crappy software is not accurate. They want good software that does what they want.
Re:It's just a tool (Score:3, Insightful)
No, it means that people that are euphoric and sloppy naturally can still use them and get something done, even if its not a bulletproof webapp suitable for the most intense uses.
It also means that people that are more meticulous have more time to spend researching and planning the particular needs of their applications than if they were using something harder to use.
Sure, there are times when other technologies may be the more productive choice. But ease of use is not a misfeature in a database or programming language.
BASIC is a brilliant way to get started (Score:4, Insightful)
C is a language that's too powerful for a beginner. There are too many ways to hang yourself if you don't know what you're doing. Someone who has never programmed before isn't ready for it. BASIC taught me to develop algorithms, so that when I was learning C, I was struggling with the syntax and semantics separately from the process of learning to write algorithms. Pascal taught me discipline that I used to structure C programs in ways that aren't required by the compiler but necessary to keep one's code organized and managable.
BASIC is a good thing. It's like drinking milk as a baby. Pascal is a good thing. It's like learning to get along with other kids in kindergarden. People aren't ready for C until they've gone through those stages.
Re:It's just a tool (Score:1, Insightful)
Re:It's just a tool (Score:3, Insightful)
Customers don't want to pay out the ass for you to take the time to do it properly the first time around, either.
Re:It's just a tool (Score:4, Insightful)
They want good software that does what they want.
Customers do not want "good" software. Good software is tight, clean code created using a proper development methodology. Good software takes time to create, but is far easier to maintain. Customers want "acceptable" software. As long as it does what it is supposed to, doesn't have any show stopper bugs, and is available tomorrow, the customer will take it over any "good software" available the day after. Then, when the customer reaches the limits of the hacked-up solution he/she clamors for the next version.
This is just from my personal experience.
Re:It's just a tool (Score:5, Insightful)
I learnt that lesson as a teenager in the early 80's, thanks to over-hyped computer games which truly sucked when they finally (if ever) arrived. Other speccy users will know exactly which titles I'm referring to.
Re:It's just a tool (Score:3, Insightful)
Well, true.
But we live in a world where people don't seem to be very good at making distinctions. As, for example, in the difference between a screwdriver and a chisel.
Part of this is the fault of salesman, who want you to buy their product as the one true tool for everything, and part of this is the fault of bad managers, who don't know how to make decisions, and part of this is the fault of lazy programmers, who want to stick to what they know. But reality is that there is no one perfect way to do everything. You don't want to cut a mortise and tenon with a screwdriver, nor do you want to drive a screw with a chisel. You've got to have the right tools for the job.
Things change as you scale. As you scale projects in engineers, functionality, and users, different factors come into play. The classic example is J2EE, which is brutal productivity sucking overkill 4/5 times it is used. On the other hand, there is VB, FileMaker, Access etc., which are fine, even nearly ideal, for scratching the small itches of an individual or a small number of users. But I've seen many a project start off with an impressive spurt of "productivity" then grind to a halt because the complexity increased exponentially in time and they found out that while a Dremel tool is indeed a handy tool, it does not suffice to build a suspension bridge or a rocket ship.
In the end good design boils down to the DRY princile: do not repeat yourself. The trick is that you have to determine exactly how you will end up repeating yourself, without letting the process suck up all your time. It's almost a Zen thing. You have to constantly think about the future and what might happen, while remaining focused on the present and what is happening. Your habits of mind must encompass both.
The ability to anticipate the dead weight of repetition and work around it is what makes a good programmer. It's fun to sit down with something you know (e.g. LAMP) and start banging stuff out fast. It's useful too. But that doesn't mean you spew code just because you can. It is true, LAMP and every other system that is easy to use encourages bad habits among bad programmers. But there has never yet been a successful attempt to force bad programmers to think like good ones. All you get is bad programmers who get less done.
Re:This is silly (Score:4, Insightful)
(A continuation of number 1) Scoping in general is completely screwed up. GLOBALS aren't actually really global. Unless you specifically bring it into scope with the "global" keyword, but even there the behavior is subtly different. Or if it's a "SUPERGLOBAL" (e.g. the variables which are registered by REGISTER_GLOBALS) which are always in scope. I also find the scoping behavior within functions to be incredibly annoying, but unfortunately that brain damage hasn't limited itself to PHP.
(A continuation of number 4) Not only is MAGIC_QUOTES incredibly irritating, it's just not right. Most databases other than MySQL use '' instead of \' to escape characters, so adding the slash not only doesn't help, but makes it harder to clean the input. (Yes, I know about MAGIC_QUOTES_SYBASE, but in my experience, nobody uses it, instead resorting to stripslashes + str_replace.) That this is even needed as a language 'feature' is ridiculous in the first place. If they had a decent database abstraction from the beginning (or at least much earlier on than they did) that handled escaping properly, this misfeature might never have been created.
And finally, what is with having language features being configurable in the first place? There's no clean way to write a redistributable PHP application that will reliably run on a given installation of PHP without listing a whole set of configuration options that the user needs to set in an
and that's why you shouldn't use MySQL (Score:3, Insightful)
Y'see, I'd rather that my developers not get punished for "doing the competent thing", and get to spend their time developing new features rather than having to hand-optimise existing ones. As the other reply suggests, if an RDBMS can't properly analyse a complex query and return results faster than doing it with multiple simple queries being dumped over the network, then that RDBMS is screwed. Maybe it's just tuned badly or maybe it's terminally brain-dead, but there's definitely something wrong there.
Re:PHP-MySQL vs. Basic. (Score:3, Insightful)
By now I guess you've gathered that there will not be an arguement here that I not heard before.
Re:Bad programmers are still bad programmers! (Score:3, Insightful)
As to the "brain-damage" effect, I really have seen it. If you cut your teeth on BASIC or PHP, you think that "learning to program" == "learning to work around $language's flaws" and when/if you move on to something else, it's painfully difficult to start thinking in terms of "real" design. It really crushes a lot of people. Better to learn some basics before you start writing crap code.
I thought Ruby was the new Basic? (Score:1, Insightful)
There's a reason why millions of developers use PHP/MySQL instead of Python and PostgreSQL (for web sites), because it's made for the web!
PostgreSQL and other Transactional Databases are not intended for Web Applications. Sure you can use them for that, but that would be like using PHP/MySQL for your shell scripting environment. (You can, but should you?)
I use python, perl, php, bash, c, or whatever is best for the requirements I have.
Web Interfaces: PHP
Shell Interfaces: PERL
Desktop Interfaces: Python/Gtk++
The database you choose, is subjective to your needs.
I like postgresql for transaction-heavy database architecture, but for most basic web apps, heavy transactional functionality slows down the performance tremendously. (Yes, even (especially) Oracle).
I notice that this guy is a fan of Ruby, and it seems that most Ruby Fans dislike PHP, which goes both ways really. (most PHP developers who actually like PHP, dislike Ruby).
Too each his own. To say that using Language (A) instead of Language (B) makes you smarter, is a reflection of ones own ignorance.
Seriously, this is absolute nonsense. Total crap. (Score:1, Insightful)
The whole idea of BASIC (or PHP) "ruining" novice programmers is absolute nonsense.
It's akin to saying that reading comic books as a child somehow permanently "ruins" a person, and makes it impossible for them to develop intellectually as an adult. The concept is just total crap.
I started with BASIC back in the late 70s. Today, I am a fully-capable OO developer in C++ and C#. (I also know how to use PHP to do large-scale multi-tiered OO development.) There was nothing in BASIC that made it hard for me to later learn OO and other good programming techniques.
Actually, to imply that I could have somehow been "ruined" by exposure to any programming language back when I was a teenager is outrageously insulting to my intelligence.
Re:PHP-MySQL vs. Basic. (Score:2, Insightful)
And popular languages with GOTOs raised a generation of programmers who were not told that GOTO's are bad. Later they killed many programs before learning it the hard way.
Would you rather have that the mistakes of past are not repeated, or that you could impress younglings by avoiding the use of GOTO with the grace of an experienced developer?
FLPR - FreeBSD, LightTPD, PostgreSQL, Rails (Score:3, Insightful)
- Turbogears [turbogears.org]. Turbogears may become the choice for webapps with more complicated database requirements, eg apps that require a relational algebra engine rather than a simple object store, given their ongoing work to integrate the SQLAlchemy [sqlalchemy.org] DB layer.
- Django [djangoproject.com] also looks good
- web.py [webpy.org] for a lightweight framework.
Given the Rails-led boom in opensource RAD web frameworks, there are plenty of combinations still left for anyone wanting to make a framework out of their favorite components - Linux/BSD/etc | Apache/LightTPD/etc | PostgreSQL/MySQL/SQLite/HSQL/etc | Ruby/Python/Lisp/etc.Re:It's just a tool (Score:4, Insightful)
They most certainly do!
When I was first hired as a PGSQL developer, the company I was working for had two projects going. One of them we delivered to the customer without all of their original specifications met, but basically working. Having delivered a product they could see and use, they were more than happy to keep paying for features and performance enhancements. They ended up paying more in change orders than they did for the original contract, and they were damn happy about it.
The second project was delayed because the data we were given to work with was screwed up beyond all expectations. Taking the time to "do it right" would have pushed us way past our original deadlines. But we tried anyway. Without something they could put their hands on, broken or not, the suits got anxious as soon as our deadline passed. That project ended up in arbitration.