Debate - .NET V. PHP: Top 10 .NET Myths Exposed

[Jeremy W.]

These comments are in regards to the SitePoint.com article 'Debate - .NET V. PHP: Top 10 .NET Myths Exposed'.

This seems like a rather defensive article, taking a "yeah, we can do that too" kind of stance without evaluating how well either technology can do anything.

To encourage PHP developers to ignore the technology simply because "they can do that too" seems a bit foolish. As any real developer will tell you (application or web), any technology can do anything. Delphi isn't better than VB because it can do more, it's better because of the tools, speed, development time, etc.

In all these areas, .NET shines over PHP for serious development, and that's always what it was intended for.

This wasn't meant to be a discussion on just "language.net", as it seems a bit hypocritical to just focus on one portion of .NET, and then be allowed to explain how PHP rocks because of the hundreds of extensions (many of which require $, something .NET doesn't require of you).

The greatest advantage of .NET for me is simple. I can build massively complex applications which are 75K in size. Windows applications. The only thing that is required is that the client have the .NET redistrib installed which is a paltry 25MB: the size my application would have been in Delphi or C++. But, after I've installed that .NET redistrib, every application I write is tiny.

Since I work in a large corporation, this saves us a tremendous amount of money. Instead of new software taking up 125GB of corporate data space (across the computers), it takes up less than 1MB.

This article also forgets every major factor when looking at technology. Speed, development time, tools. .NET applications are faster than PHP, even compiled. Development time for serious projects (I'm not knocking PHP's ability to make amazing small projects very quickly, PHP is a very strong language) is incredibly small (what took us 4 weeks in C++, took 6 hours in VS.NET) and has an incredible suite of free tools.

Anyways, it is a good article Harry, and exceeded my expecatations in some ways. Let's just say I'm glad you didn't write this 2 months ago

[M. Johansson]

Harrys article is in my opinion very good. (Although there is no such language as ASP+! )

What I've found is that the smaller the application is, the more suited PHP is, and the larger it is, the bigger the benefit of using ASP.NET.

[Jeremy W.]

I completely agree

[Mincer]

I think that a primary difference here is what people are calling 'applications'. The apps that I develop don't need to deplay anything to my users, they all run through their web browser - somthing that, by corporate standard, everyone has anyway. The same goes for any personal work I do outside of my daily corporate grind. Again, it's like comparing chalk and cheese if we're comparing standalone deployable client applications with a single web-based app.

Oh, Jeremy. I thought your user title was so funny that I printed up a big sign for my office door.

[Jeremy W.]

Originally posted by Mincer
Oh, Jeremy. I thought your user title was so funny that I printed up a big sign for my office door.

Yeah, I get that a lot

The thing is that it isn't comparing chalk and cheese. We're talking .NET. The fact that PHP doesn't do it isn't anything against PHP, as it was never designed for that, but it is a strength of .NET.

It is the same way that you compare Java with Delphi. Java is cross-platform. That's a plus. Delphi wasn't designed that way.

[Skunk]

I think the main point of the article is that if you're using PHP and it works for you there's no point in switching to .NET just because it's the latest buzzword. That said, I'm evaluating .NET at the moment (aka reading through the QuickStart tutorials ) with an aim to steal all the good ideas and implement them in a PHP framework

[voostind]

If you compare the languages PHP and ASP.NET together, they measure up against each other extremely well. One might be a bit faster in some areas, but the other will use more memory in others. And so on. Ad infinitum.

The thing that makes ASP.NET better is not the language. It's the toolkit. There is a very good ASP.NET library allowing one to write software in short amounts of time. However, this can't be thrown into the comparison between ASP.NET and PHP, because it has nothing to do with the language itself. Such a toolkit could exist for PHP just the same. The fact that it doesn't exist right now is not a contradiction of that statement.

So will PHP get such a toolkit? And if so, when? My predictions: maybe, but certainly no time soon.

Before I explain why, let me state some simple facts:

Implementing an interpreter/compiler is relatively easy

I'm not saying writing an interpreter like PHP is a piece of cake, but it isn't that hard anymore either. Parsing techniques are well known; how to generate semantic trees from parsed input has been studies very well, and how to translate those trees to machine code is a fairly trivial task as well. Nowadays, students in their first or second year in Computer Science classes already get assignments to write compilers, albeit small ones. In any case, the point is that because it isn't that hard anymore, more people can do it. You don't have to have a degree in Mathematics or Computer Science to be able to write a solid compiler.

Implementing libraries/frameworks in extremely hard

(Note in advance: with 'libraries' and 'frameworks' I'm not talking about the lowest-level pieces of code as they have been around for a long time, like mathematics libraries or even socket programming libraries, I'm talking about the much higher-level, general purpose libraries meant for all kinds of applications.)

The more a library should do, the harder it is to write. Writing a framework is even harder. Just look around and count the number of libraries that are out to do more or less the same thing. There are numerous. See how many (class) libraries even very large companies have launched before finally getting something good. Take Microsoft for example: they've had AFX, MFC, ATL... They all suck, even if they were designed and implemented by the brightest in the field. Finally, with .NET Microsoft seems to get an idea of how to do it (with many thanks to Sun and IBM). Borland's VCL (now CLX) is one of the very few frameworks that was pretty good from the start; it had a sound basic design. The point here is: only in the last 5-10 years have computer scientists been able to design and implement frameworks that actually work. That isn't strange, because the higher the abstraction level (compare a 'tcp/ip protocol implementation' with a 'toolkit for a graphical user interface') the higher the complexity, and the harder to design a generic solution.

Open Source is slow

In most areas in computer science, Open Source products follow after the commercial ones. Admittedly, first some pioneer thinks of a new technology and often releases it as Open Source, but the released stuff is never quite fit for production use. That makes sense, because it was a prototype; it was being pioneered. If it looks promising, commercial companies take it over, throw lots of money and expertise at it, and end up with a product that does make it into the market. Once a large group of people wants the same thing that commercial software already provides, but they don't want to pay for it, then they try to mimic it. And that takes an enormous amount of time. One reason: lack of expertise. That is okay and it makes sense, because there are a lot of hobbyists' those that write software for fun, not to make a living out of it. There are many individuals working on just as many Open Source projects, and only very few have a good idea of what they're doing. From that follows that it takes much longer for the Open Source community to get something right than for a commercial company. How many years since Microsoft and Apple first released their GUIs? A lot. It's now 2002, many years later, and we still don't have an Open Source equivalent that gets near. There are only two more or less successfull Open Source desktop environments, and the technically most advanced one is built on top of a toolkit owned by a commercial company called Trolltech. That isn't just coincidence. The Open Source community doesn't have the required expertise, at least not right away. How many Open Source office products are there? The most promising, arguably OpenOffice.org, is still not good enough by far to compete with the commercial software. Again, that's not coincidence.

PHP

Back to PHP. The thing PHP needs right now is a toolkit. But that's not just an extension of the (easy to write) interpreter, it's a whole new framework on top of it! Right now, countless people are happily working together on the 'PHP Extension and Application Repository'. New classes are added every week. New features are added to existing classes every month. The PEAR community is a large, thriving community with lots of enthusiastic developers. But what is PEAR? PEAR is actually a piece of crap. It's serious junk. It's not an 'Extension and Application Repository', nor will it ever be. Why not? Because it's written by people who have no idea of what they're doing. The expertise isn't there. What they need are people who have had an education in designing and implementing libraries and frameworks, not a bunch of web designers who learned PHP because they needed dynamic sites. I'm not saying that these people don't have the brains for it, but they certainly didn't have the required education. It's not something you pick up on the go as so many people seem to think; you need education, and a lot of it. I'm not trying to be harsh, I'm just stating the simple truth. Implementing a soundly designed application is not easy, just look at the software projects that fail each month. A library is at least 10 times as hard building an application. Frameworks are even harder than that.

So when will PHP have a toolkit comparable to ASP.NET? Maybe in 10 years. And then I'm still being optimistic.

This 'rant' will obviously trigger lots of replies saying "You can't say PEAR is that bad! It's actually pretty good!" (But in less nicer terms, probably.) Well, they only prove my point. Again, look at the companies with the money. Even they needed years before they could produce a toolkit that actually amounts to something. The Open Source community is just starting. The part of the Open Source community programming in C/C++ (by far the largest part) can't do it yet. The PHP community is just a tiny fraction. If those millions of Open Source C-programmers can't do it, how can (by comparison) a couple of thousand PHP programmers? It's just not possible.

Vincent

[M. Johansson]

Whoa.

[Mincer]

Yeah, but PEAR is actually quite good.

/me hides under desk...

[Jeremy W.]

All of the above is valid if the discussion was only on ASP.NET. It isn't, the original question wasn't, and the article wasn't.

If PHP as a whole, and all it's tack-ons and other tools are to be evaluated, then the same must be done with .NET, it must be evaluated as a whole.



I agree with the "whoa" though

[M. Johansson]

Originally posted by Mincer
Yeah, but PEAR is actually quite good.

/me hides under desk...

You just proved Vincents point.

[Mincer]

Originally posted by M. Johansson


You just proved Vincents point.

I think you'll find I was being sarcastic, hence all the smilies.

[M. Johansson]

Originally posted by Mincer
I think you'll find I was being sarcastic, hence all the smilies.

I was sarcastic too! ha!

[Mincer]

Originally posted by M. Johansson


I was sarcastic too! ha!

Baaaah!

[MattR]

I agree: PEAR = teh crap!

I remember as part of the .NET rally I went to (and won an X-Box at ) that DLL hell is no more since you can keep your DLLs in your app dir and don't need to 'install' them anymore (no installs?!?! YEA!)

[westmich]

There seems to be some confusion on compiled vs. cached in the articles and forums (or maybe it's just me).

Both ASP.NET and PHP applications store compiled versions of files for use on the Web server. I mean this in the simplest of terms: you write a file (plain text) and save it to the server. Someone comes to the site and requests your file. The server then looks at that file in some sort of internal index to see when the file was last saved and when it was last compiled. If the compiled version is newer, it is handed to the client. If the text version is newer, it is compiled and then saved and then handed off to the client. The benifit is that same file isn't re-compiled every time saving a lot of overhead.

This is quite different then ASP.NET's optional caching. All the above steps are done plus the final output file is saved. So the next client to ask for the file is handed a fully rendered HTML file - no database calls or programming logic needs to be done. This can make a HUGE difference on a busy site.

[HarryF]

First thing I have to say is since writing that article (early July time), more things have become clearer. If I was re-writing it now, I'd include a point that PHP lacks a solid set of extensions. Also the remarks on templating systems I'd omit, having understood that PHP is a templating system.

Vincents points are completely correct and I am in many ways, one of those awful coders he complains about (but I'm trying ), having taught myself.

Going back to Jeremy's first post;

This seems like a rather defensive article, taking a "yeah, we can do that too" kind of stance without evaluating how well either technology can do anything.

The original purpose of the article was not to promote PHP but simply clear up some misconceptions that keep appearing here, in PHP vs ASP discussions. So I agree, it comes across as defensive. Not much I can do about that now. It's not meant to discourage people from looking as ASP.NET at all, just not to swallow the hype when they do so. The article was inspired by some particularily fanatical ASP.NET coders on these forums, selling it as the solution to everything - "even cuts your grass".

Otherwise, you commit the number one crime of comparing .NET to PHP. Please re-read Point 1. You then try to back yourself up with this;

This wasn't meant to be a discussion on just "language.net", as it seems a bit hypocritical to just focus on one portion of .NET, and then be allowed to explain how PHP rocks because of the hundreds of extensions (many of which require $, something .NET doesn't require of you).

First 99% of those extensions require no money and can be dynamically loaded in a script if you no what you're doing (meaning you don't need to pay your web host).

Secondly, I mentioned extensions only in point 6 as part of the issue of multi language support.

Here's why you can't compare .NET to PHP. Someone says, hey - PHP won't let you do this, but .NET does!!!

ColorSelect.Items.Add('AzureBlue');

That's invoking an extension, and if PHP has an extension which does this for you (written in C++, PHP or otherwise), perhaps you'd invoke it with;

$ColorSelect->Items->Add('AzureBlue'); 

But that's not part of the PHP language itself.

As to this point about rapid / enterprise development, I think that depends on the developers and the problem in hand. To make remarks like PHP is for "small" is wrong. The fact that many novice programmers are using PHP to get started is no reflection on PHP's scalability. In the hands of an experienced developer...

[Jeremy W.]

As I said, I'm not saying it's bad, just didn't see the direct comparison as appropriate

I know PHP's great, and I've never once bashed it, in fact I'll be doing a couple of PHP sites very, very soon. I know it's value, but I don't see that value as application development, which is where .NET really shines.

Similarly, I don't think .NET is actually that good at making small sites from scratch. Sure, if you're doing it and relying on existing subsystems, classes, etc, then I think it's great, but I don't think there really are that many significant advantages to .NET with small simple websites

[Zibi]

First off, I'd like to say that these posts have been very interesting and informative (hats off mainly to Vincent, Harry, and Jeremy)

In regards to the actual debate, I don't really want to get involved as I've never used ASP.NET, but I do see one of PHP's _major_ strengths as being able to develop small sites and applications with much ease. In this field, I believe PHP is the superior language.

In the big game field of developing large sites and applications is where I think the two languages really clash.

Lastly, I'd like to add that the first thing that turned me on to php (other than it is similar to C++, which is the only other major language I knew) is the fact that it is open source.

For me using open source (i.e. PHP, not ASP.NET) is also my way of saying "You suck Bill". (Although M$ Windows is still my main os, I'm experimenting with Linux Desktops)

....I'll stop before I start to rant and say something _really_ stupid.

[Jeremy W.]

Aw, come on, don't stop, I love to hear the opinions of experienced developers, becuase I can't possibly know everyone

As a professional, your opinion matters, so feel free to jump in, argue, question, whatever

[trickie]

The main reason that i like PHP more is that i just don't agree ethically, with M$ and their business model or tactics.

I'm learning ASP.NET at the moment, and as long as knowing it will help me to secure work and get a rounded knowledge of web design, then i'll continue to learn/use it.

I like and agree with the Open Source model of software development (not for everything though ) and from an ethical and social standpoint i just like the environment/social context from which PHP grew better!

my two cents

[Zibi]

bump! (Is it possible for a mod to combine this thread with the other one? Sorry I'm not to familiar with Vbuletin.)

Jeremy: I didn't really want to keep speaking my mind because I've never used ASP.NET, and didn't want to go beyond my limited knowledge of it and say something stupid. I'll try to think of something good to say though

[mmj]

It's good to hear the other side of the argument. I agree that PHP is very flexible in simple situations.

[reywob]

Originally posted by HarryF
Vincents points are completely correct and I am in many ways, one of those awful coders he complains about (but I'm trying ), having taught myself.

Aren't most of us? I know the feeling well, and Vincent has patiently explained to me many times about OO programming... but I'm still not quite there

OK Vincent, it's up to you to save the PHP world now

[voostind]

It's good to hear the other side of the argument. I agree that PHP is very flexible in simple situations.

And I would like to add that PHP is - just as any other programming language - equally flexible in complex situations.

OK Vincent, it's up to you to save the PHP world now

Mwwaahaahaa! I'm the MAN!

Seriously, I think what should happen to PHP (or better: to PEAR development) is a change of approach. Instead of letting anyone join the project and add code, a few other things should be done:
- A couple of knowledgable and/or experienced people should run the project. They decide what comes in the library, and more importantly: what not. (Do you really want 'sequences' in PEAR DB? Short answer: NO!)
- Those responsible for the library (the guys/women I just mentioned) must provide a guideline of what code should look like. I don't mean that in the sense of "Use tabs instead of spaces" or something like that. I mean it more like this: "If a function/method returns an object, it should always be of the same class.". Those guidelines force a programmer into thinking about what he's coding much better.
- The contributors should be made aware of A Very Important Thing: what they are doing is extremely hard. They must fully understand that. I, for one, consider myself an able designer/programmer, but I don't think I'm good enough to run a project like PEAR. It's very, very difficult, and I don't know I can pull that off.

The people who currently work on PEAR (and the people who are not but are willing) certainly are - for the most part - smart enough to undertake such a difficult project. The problem is that they aren't aware of the importance of what they are doing, nor of the difficulties. They should move away from "I'll add that feature to my (already bloated) code because some programmer in Iowa happens to need it." to "What is the minimum set of features that allows programmers to do anything they want?"

As an example, consider PEAR DB (as always). It has a method called 'fetchOne', that returns the first row of a query result. At the library level, it is a mistake to put such a method there. Why? Well, what does fetchOne do?:
- It runs a query through the database connection
- It retrieves the result from the database connection
- It selects the first row from the result and returns it

The method combines a number of existing features (method) to do its job, while not adding anything new. The last step (and the only reason the method exists) is by far the easiest. However, it is also the only step in which good error handling can be done. If one of the first two steps failed, what should be done? Returning an object of some exception class is not a good idea, even if it is possible in a loosely types language like PHP. Yet this is actually what PEAR does all over the code. So what else can be done at the library level? Nothing. So the method shouldn't be there. If an application needs something like 'fetchOne', let the application programmer put it in his/her own code. Then he/she is responsible for resolving all possible problems that can occur, which makes a lot of sense, since the way such a problem must be resolved depends on the application, and not on the library.


Oh and a small point about all of you here: you are typically NOT the 'awful coders' I'm talked about in my previous post. Reason: your being here shows that you are aware of the difficulties of programming, and of the eagerness to learn.

Vincent