Why the Light Has Gone Out on LAMP

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."

Re:Bad programmers are still bad programmers!

[jacksonj04]

One thing you can do is set error reporting to full in a .htaccess and then take a look at your site. It will bitch about calling strange variables, missing quotes, assumptions you have made, reliance on bad features and quite a bit more.

Misguided

[porkThreeWays]

You are completely misguided in your claims about wikipedia. Wikipedia's downtimes have little/nothing to do with their choice of programming languages. Wikipedia is run soley on donations. They don't have nearly the money of the bbc. At the same time, they've experienced incredible growth in a short period of time. Their bandwidth and hardware has not been able to keep up.

If you need some prospective; about 3/4th's of my google searches for a specific topic (i.e. "stegosaurus" and not "Error no. 43245") have wikipedia in the top 10. That's pretty significant traffic wise...

Re:What he is suggesting

[mwvdlee]

Actually, subselects are part of the SQL language, MySQL just doesn't implement that part of the standard. Subselects allow you to use the results of a query in the WHERE/INSERT/DELETE/etc. clause of another.

Transactions basically make sure that multiple, individual, changes in a database are either committed "all-at-once" or "none-at-all". Consider a site which requires 5 steps to registration, if step 3 fails without transaction support, some tables may contain incomplete data. AFAIK, the latest version of MySQL (which isn't typically the version installed on webhosts) supports transactions.

Referential integrity means that if a column in table A points to a column in table B, the record in table B must exist prior to a record in table A referring to it. This features is also used to ensure integrity of the database in other scenarios. In MySQL, you'll have to manually ensure all cross-references are valid.

Re:What he is suggesting

[Zontar The Mindless]

MySQL has supported subqueries since version 4.1.

Transaction support in MySQL doesn't depend on the version, it depends on the storage engine you're using for your tables. The InnoDB, NDB Cluster, and BerkeleyDB storage engines all support transactions. InnoDB also supports foreign keys. InnoDB has been available in the -max releases since MySQL 3.23.43a (early 2002) and has been part of -all- MySQL releases since 4.0 (late 2002). Any web host offering a MySQL server that doesn't support transactions and referential integrity either can't be bothered to update their software at least once every 4 years, or else they're building their own and deliberately leaving out InnoDB. In either case, you need to find another hosting company.

Re:What he is suggesting

[Thundersnatch]

Responding to your comment: Microsoft is the one prohibiting their licensees from benchmarking their database against others. They must have something to hide.

All commercial software vendors generally prohibit benchmarking to some extent these days. Yes, Oracle and IBM too. The idea is to prevent "bad" benchmarks by improperly configured setups. Most vendors' service organizations will assist journalists and even end-users with performing standard benchmarks (sometimes for a price).

As for SQL benchmarks, they do exist. And Microsoft SQL Server fares very well (espicially on a price/performance basis). See the non-clustered TPC-C benchmarks for four-socket servers [tpc.org] for example. I've never seen a TPC result for an open source database listed. Why? Probably because MySQL and even PostGres can't scale like the commercial DBs, and nobody wants to invest time and money it takes to making a sucessful benchmark submission for a product they can't actually sell.

Note that Oracle has largely stopped submitting TPC results, as they've been getting their ass handed to them by MSFT and IBM so regularly.

Re:It's just a tool == Then use the best tool

[Anonymous Coward]

> 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 high-performance access to single DB tables (which many webapps do), use Java's JDBC.
- If you want high-performance access to multiple DB tables, use Java's JDBC.
- If you want to quickly put together a site because your purpose isn't actually maintaining the site but putting up some content, use XHTML or Java's JSP.
- If all you want to do is create a simple program to do a one-off task, use Java.
- If you want to create a straightforward GUI for a database, use Java.
- If you want a mutlithread application, use Java.
- If you want a client-server app, use Java.
- If you want a peer-to-peer app, use Java.
- If you want to write a simple script that runs on Linux, Windows, Mac, or all of them, use Java.
- If you don't have time to debug and just want something that's easy to put together, use Java.
- If you have an enormously complex project and need something maintainable, use Java.

Hmmm, I'm noticing a pattern here...

Re:unroll your joins

[azaris]

Try dumping the left join and using simple queries" is the first thing I suggest to my junior developers when they have gone and done the competent thing and ended up with a web app query that takes a full minute to return a result. Once they actually analyze the problem (instead of just trying to brute-force it with a MySQL one-liner), they usually discover there are other shortcuts and optimizations they can make, too. They may end up with 100 lines of code instead of 1 query, but they also end up with a much better application, because that 1 query was just an alias for 50,000 lines of code and a full minute of disk thrashing in MySQL.

I know nothing about MySQL but this doesn't sound right. What's the point of having a relational database if all you do is use it as a flat storage with all the relations done in code? I agree that sometimes it is necessary to do things the painstaking way, but usually with a RDBMS you handle such issues with clever indexing and table design. If your queries are so slow with a regular load then there's something badly wrong with your database or your database design.

Code is Code

[Naum]

Vaguely written rants laced with trendy buzzwords and university eggheads flaunting their scholarly beaks at plebian programmer tools aside, let's look at why LAMP has been and will continue to be a viable web development platform.

First, I've coded on just about all platforms, from COBOL, REXX/CLIST and Assembler on IBM mainframes to C on Unix boxes to LAMP to Ruby (including some RoR apps). And, code is code — in the hands of an unskilled practicioner, the product is going to be crap no matter what the tool. And a gifted artisan can craft a masterpiece with nearly any tool.

There's a great deal I detest about PHP. But, any language that I've toiled in for over a few years in writing relevant legacy code/enterprise applications/dynamic web software shows its unsavory side. No such thing as the one true programming language exists — they're all just tools, and just as they have their selling points that shine, they all suck in some sense of matter.

Anyway, here's a short list of why LAMP is good.

1. F/OSS — I spent many years coding on proprietary platforms with commercial language platforms. And I would gladly exchange it in a heartbeat for the opportunity as we have today to work with Free/Open Source software tools. Being freed proprietary whim is a great blessing that I think many take for granted today, or are blindly unaware of the ramifications. I realize this doesn't address whether Linux + Apache + MySQL + PHP > some other F/OSS solution like Ruby, ROR, lightpd (which are far superior, IMV, to Micro$oft, $un, !BM) etc....
   
   
2. Shared hosting and LAMP package availibility/ubiquitousness — most likely, an entity wants a dynamic web site, a step up from the circa 1996 static html page variety, but their requirements are far less than something that requires a dedicated server. They pay someone with a little knowhow like me a little coin to set them up a LAMP site, either with a F/OSS project output platform customized for their usage or for a little more money, my own hand crafted framework solution. LAMP still excels in this regard, as most of the snazzy Web 2.0 offerings arn't freely releasing thier codebase as a "point, click and install solution" as the litany of PHP open source modules that populate the web space today.
   
   
3. Low startup barrier — any enterprising developer can get off the ground and running in a moments notice. Granted, this is a source of great consternation, as hand in hand, it has led to a large amount of hideous, ugly, unstructured code, giving a lot of the PHP community, justifiably so, a bad rap.
   
   

Having laid a case out for LAMP out, let me share some concerns about future LAMP direction:

• Have to agree that about the assessment offered in another comment here about MySQL getting squeezed from both ends. For low volume sites, or even sites with considerable traffic but "read heavy" on the DB load, SQLite, built into PHP5, can easily take the place of MySQL and on the higher end, not sure if MySQL is going to remain a quality player. I expect that the "feature" to plug whatever DB you wish to use is going to grow in importance.
  
  
• I finally made the leap to PHP5 and won't do any new project work with PHP4. Even in the shared hosting arena, there are enough hosts now that offer PHP5, that it shouldn't be an issue. Now, this scratches a great deal of existing PHP product out there for consumption, but I have discovered, to my surprise, that moving PHP4 code to a PHP5 environment has not been difficult at all, though there are a few gotchas to contend with.
  
  

Re:It's just a tool

[jellomizer]

Customers want it cheap. That is it. You can explain how if it takes you twice as long to make sure it is easy to maintain in the future and will save money in the long run until you blue in the face. But what it comes down to is if your inital cost of development is less then the other guy.
For almost 90% of the clients I went to and I brought up the topic they all said these are the requirements and we will never need to expand on them, Of course they are 100% wrong. But what can you do, you need to eat, so you take shortcuts to save on development time and you make up for it in maintenance.

Re:It's just a tool

[A.Gideon]

You can explain how if it takes you twice as long to make sure it is easy to maintain in the future and will save money in the long run until you blue in the face. But what it comes down to is if your inital cost of development is less then the other guy.

This is why I love clients that have been previously burned by some code & cash developer [team]. They understand what the consequences of "low quality" mean, and are willing to pay to avoid it.

The more educated the client, the higher the demand for quality. It's just a shame that so many need to be burned to be educated.