I personally don't care if I can fix the code or not, that's not my job. When I encounter bugs or flaws in FireFox I'll be happy to report them and spend time with followups, but it's ultimately their problem. I don't have the time to dedicate days to track down some obscure bug in code I don't understand and then argue back and forth to get the patch into the code tree. So far my experience has been that there is actually very little desire to fix much of anything with FireFox or Gecko unless it's a security related issue. When confirmed bugs linger around for months without getting fixed Mozilla is really no different than any other piece of software or vendor. Bottom line, you're always going to be stuck with bugs that won't ever get fixed. The best you can hope for is that it's something you can work around.
First of all, the entire MSDN library can easily be accessed online (http://msdn.microsoft.com/library/), second an MSDN subscription doesn't involve any kind of NDA. The only times I've personally come across this was with pre-release stuff and with their limited beta programs and in those cases it's nothing that any other company doesn't do either.
It means that Google either retired/fired all of its pigeons (http://www.google.com/technology/pigeonrank.html) in favor of humans, or it reveals that the pigeons were actually peons all along.
>No argument here. Using hungarian notation makes life a little easier, but certain bugs can still appear without strong type casting.
My main objection is that PHP keeps track internally of what type each variable is already, so providing at least the option of enabling strong typed variables shouldn't be that hard IMO. PHP 5 has type hinting but for the moment I'm stuck with 4 so I haven't really looked into it that much.
Having to use "$this->" to reference class member variables probably tops my list of personal grievances though:). I can't count how many times I forget to do that.
>What does it lack? Personally, I miss the ability to do function overloading and the functionality that comes with C++'s virtual functions. PHP won't properly call a derived class' overrided function if it's invoked from the base class. PHP 5 solved a lot of the others (scope through public/private/protected, static, abstract classes, etc) but unfortunately, I can't force everyone to switch on over and in some cases it's also impossible due to a shared hosting enviorment. I used to be against accessors but I've found some practical uses for them but strictly speaking C++ doesn't have them either. The way PHP 5 choose to implement them is far from ideal IMO though. When/if I can switch over, exception handling will also be very welcome, assuming the cost isn't too high. And although not strictly OO-related, I do miss the presence of collection classes as well.
>PEAR modules can provide these. I never paid that much attention to PEAR honestly but I'll look into that, thanks.
As for the tools, maybe it's a habit but I can't develop anything without a debugger and profiler and even with Zend Studio - for me - it's a burdensome process for PHP compared to normal. Also being used to Visual Studio's intellisense has made me rather spoiled and although saying this tends to open a can of worms, I'll take the MSDN documentation over PHP's any day.
I remember the frustration and agony of having to develop a basic compiler for a university course which had to be done on linux with gcc and a command line debugger. Whenever I write PHP code those memories just come flooding back.:)
>No argument here. Using hungarian notation makes life a little easier, but certain bugs can still appear without strong type casting.
My main objection is that PHP keeps track internally of what type each variable is already, so providing at least the option of enabling strong typed variables shouldn't be that hard IMO.
PHP 5 has type hinting but for the moment I'm stuck with 4 so I haven't really looked into it that much.
Having to use "$this->" to reference class member variables probably tops my list of personal grievances though:). I can't count how many times I forget to do that.
>What does it lack?
Personally, I miss the ability to do function overloading and the functionality that comes with C++'s virtual functions. PHP won't properly call a derived class' overrided function if it's invoked from the base class.
PHP 5 solved a lot of the others (scope through public/private/protected, static, abstract classes, etc) but unfortunately, I can't force everyone to switch on over and in some cases it's also impossible due to a shared hosting enviorment.
I used to be against accessors but I've found some practical uses for them but strictly speaking C++ doesn't have them either. The way PHP 5 choose to implement them is far from ideal IMO though.
When/if I can switch over, exception handling will also be very welcome, assuming the cost isn't too high.
And although not strictly OO-related, I do miss the presence of collection classes as well.
>PEAR modules can provide these.
I never paid that much attention to PEAR honestly but I'll look into that, thanks.
As for the tools, maybe it's a habit but I can't develop anything without a debugger and profiler and even with Zend Studio - for me - it's a burdensome process for PHP compared to normal. Also being used to Visual Studio's intellisense has made me rather spoiled and although saying this tends to open a can of worms, I'll take the MSDN documentation over PHP's any day.
I remember the frustration and agony of having to develop a basic compiler for a university course which had to be done on linux with gcc and a command line debugger. Whenever I write PHP code those memories just come flooding back.:)
Usually it's people with no real programming experience that seem to prefer PHP over.NET.
If you have any experience what so ever in general development you'd realize that loosely typed variables are very much a bad thing and that what PHP claims as OO doesn't even come close to the real deal. PHP's programming practices are something that just encourages hacking away at it to make up for bad design and invites bug-ridden, impossible to debug code.
It's also very much lacking a framework to do some decent componentization and even PHP 5 manages to stay years behind with no support for SOAP or any of the WS-* technologies and OO manages to be a factor 2 to 3 times slower than it was in PHP 4 already.
PHP is popular because it's cheaper to find hosting for and because 99% of the sites out there use pre-written scripts.
PHP does have some really nice features but to me they just melt away as soon as you try to build a site with some degree of complexity. It's great for a small to large hobby site, but that's really about it.
Lastly, for something that's generally accepted to be open-source, it's a remarkably expensive platform to develop for. $300 for Zend Studio, $2400 for Zend Encoder and/or Zend Accelerator for $300/year.
Ever since Microsoft announced.NET they've maintained the same standpoint they have now: use.NET where it's appropriate, don't be stupid and rewrite existing code but interoperate with it and that certainly holds true for their own products as well.
You can find plenty of videos, articles, blog entries and chat transcripts on MSDN that show Microsoft developers clearly stating that Longhorn will not be built on top of.NET, that there was never any plan to do this and that it doesn't make any sense to do it.
What has been said and still holds true is that any new programming API will most likely only be exposed through.NET and only be exposed through the standard Win32/Win64 API where and if it makes sense.
While writing drivers, services, servers, etc is certainly possible with.NET, it doesn't make any kind of sense since with those the prime concern is not ease of development, it's responsiveness, minimal memory footprint and most importantly speed and.NET just gets in the way of that.
The only thing this article reveals is that the author has no clue about.NET and never bothered to read up on it beyond gossip and speculation.
I gave FireFox a try for a while, found that it didn't really appeal to me all that much and switched back to IE. Security concerns have never been an issue for me as far as IE is concerned, nor would I be concerned about flaws in FireFox for that matter.
I've been running as a LU ever since Windows 2000 and I've yet to be plagued by either spyware, trojans, email viruses or anything else malicious. The only inconvenience that ever crops up is because of vendors who fail to realize their app doesn't need full admin privileges to run and even then, getting it to run as Admin under an interactive LU account is only one extra additional click.
If you were plagued with spyware and viruses while running IE, you're no safer under FireFox or any browser because your basic methodology is flawed. An LU account, adjusted zone settings and properly set system policies eliminate pretty much anything that IE (or any other browser for that matter) suffers from except phishing and there common sense is the only thing that will keep you safe anyway. If you are worried about the security impact of a certain site, run your browser in a further restricted context and it won't even have write access to anything what so ever.
If you're a casual computer user then FireFox will keep you safer than IE, at least right now. If you have any bit of technical expertise or interest pertaining to Windows and you still get spyware and virus infections from using IE, you only have yourself to blame.
Blaming your lack of knowledge or unwillingness to keep your computer secure on a piece of software is not only childish, it's reckless. It should be a basic assumption that no matter which program you use, at some point, some flaw is going to appear and your computer will be at risk of running some malicious piece of software or code. The only solution is to make sure the harm it can do is severely limited which the above accomplishes rather well if my personal experience is any indication. Then, if it turns out the program you're using is 100% secure, all the better; if it turns out to have an exploit, you can sit back and watch the rest hype and scream and try to blame anyone or anything but themselves.
Slashdot Mirror
I personally don't care if I can fix the code or not, that's not my job. When I encounter bugs or flaws in FireFox I'll be happy to report them and spend time with followups, but it's ultimately their problem. I don't have the time to dedicate days to track down some obscure bug in code I don't understand and then argue back and forth to get the patch into the code tree.
So far my experience has been that there is actually very little desire to fix much of anything with FireFox or Gecko unless it's a security related issue. When confirmed bugs linger around for months without getting fixed Mozilla is really no different than any other piece of software or vendor.
Bottom line, you're always going to be stuck with bugs that won't ever get fixed. The best you can hope for is that it's something you can work around.
First of all, the entire MSDN library can easily be accessed online (http://msdn.microsoft.com/library/), second an MSDN subscription doesn't involve any kind of NDA. The only times I've personally come across this was with pre-release stuff and with their limited beta programs and in those cases it's nothing that any other company doesn't do either.
It means that Google either retired/fired all of its pigeons (http://www.google.com/technology/pigeonrank.html) in favor of humans, or it reveals that the pigeons were actually peons all along.
(Once more, now with line breaks. Sorry :) )
:). I can't count how many times I forget to do that.
:)
>No argument here. Using hungarian notation makes life a little easier, but certain bugs can still appear without strong type casting.
My main objection is that PHP keeps track internally of what type each variable is already, so providing at least the option of enabling strong typed variables shouldn't be that hard IMO.
PHP 5 has type hinting but for the moment I'm stuck with 4 so I haven't really looked into it that much.
Having to use "$this->" to reference class member variables probably tops my list of personal grievances though
>What does it lack?
Personally, I miss the ability to do function overloading and the functionality that comes with C++'s virtual functions. PHP won't properly call a derived class' overrided function if it's invoked from the base class.
PHP 5 solved a lot of the others (scope through public/private/protected, static, abstract classes, etc) but unfortunately, I can't force everyone to switch on over and in some cases it's also impossible due to a shared hosting enviorment.
I used to be against accessors but I've found some practical uses for them but strictly speaking C++ doesn't have them either. The way PHP 5 choose to implement them is far from ideal IMO though.
When/if I can switch over, exception handling will also be very welcome, assuming the cost isn't too high.
And although not strictly OO-related, I do miss the presence of collection classes as well.
>PEAR modules can provide these.
I never paid that much attention to PEAR honestly but I'll look into that, thanks.
As for the tools, maybe it's a habit but I can't develop anything without a debugger and profiler and even with Zend Studio - for me - it's a burdensome process for PHP compared to normal. Also being used to Visual Studio's intellisense has made me rather spoiled and although saying this tends to open a can of worms, I'll take the MSDN documentation over PHP's any day.
I remember the frustration and agony of having to develop a basic compiler for a university course which had to be done on linux with gcc and a command line debugger. Whenever I write PHP code those memories just come flooding back.
>No argument here. Using hungarian notation makes life a little easier, but certain bugs can still appear without strong type casting. My main objection is that PHP keeps track internally of what type each variable is already, so providing at least the option of enabling strong typed variables shouldn't be that hard IMO. PHP 5 has type hinting but for the moment I'm stuck with 4 so I haven't really looked into it that much. Having to use "$this->" to reference class member variables probably tops my list of personal grievances though :). I can't count how many times I forget to do that.
>What does it lack?
Personally, I miss the ability to do function overloading and the functionality that comes with C++'s virtual functions. PHP won't properly call a derived class' overrided function if it's invoked from the base class.
PHP 5 solved a lot of the others (scope through public/private/protected, static, abstract classes, etc) but unfortunately, I can't force everyone to switch on over and in some cases it's also impossible due to a shared hosting enviorment.
I used to be against accessors but I've found some practical uses for them but strictly speaking C++ doesn't have them either. The way PHP 5 choose to implement them is far from ideal IMO though.
When/if I can switch over, exception handling will also be very welcome, assuming the cost isn't too high.
And although not strictly OO-related, I do miss the presence of collection classes as well.
>PEAR modules can provide these.
I never paid that much attention to PEAR honestly but I'll look into that, thanks.
As for the tools, maybe it's a habit but I can't develop anything without a debugger and profiler and even with Zend Studio - for me - it's a burdensome process for PHP compared to normal. Also being used to Visual Studio's intellisense has made me rather spoiled and although saying this tends to open a can of worms, I'll take the MSDN documentation over PHP's any day.
I remember the frustration and agony of having to develop a basic compiler for a university course which had to be done on linux with gcc and a command line debugger. Whenever I write PHP code those memories just come flooding back. :)
Usually it's people with no real programming experience that seem to prefer PHP over .NET.
If you have any experience what so ever in general development you'd realize that loosely typed variables are very much a bad thing and that what PHP claims as OO doesn't even come close to the real deal. PHP's programming practices are something that just encourages hacking away at it to make up for bad design and invites bug-ridden, impossible to debug code.
It's also very much lacking a framework to do some decent componentization and even PHP 5 manages to stay years behind with no support for SOAP or any of the WS-* technologies and OO manages to be a factor 2 to 3 times slower than it was in PHP 4 already.
PHP is popular because it's cheaper to find hosting for and because 99% of the sites out there use pre-written scripts.
PHP does have some really nice features but to me they just melt away as soon as you try to build a site with some degree of complexity. It's great for a small to large hobby site, but that's really about it.
Lastly, for something that's generally accepted to be open-source, it's a remarkably expensive platform to develop for. $300 for Zend Studio, $2400 for Zend Encoder and/or Zend Accelerator for $300/year.
Ever since Microsoft announced .NET they've maintained the same standpoint they have now: use .NET where it's appropriate, don't be stupid and rewrite existing code but interoperate with it and that certainly holds true for their own products as well.
.NET, that there was never any plan to do this and that it doesn't make any sense to do it.
.NET and only be exposed through the standard Win32/Win64 API where and if it makes sense.
.NET, it doesn't make any kind of sense since with those the prime concern is not ease of development, it's responsiveness, minimal memory footprint and most importantly speed and .NET just gets in the way of that.
.NET and never bothered to read up on it beyond gossip and speculation.
You can find plenty of videos, articles, blog entries and chat transcripts on MSDN that show Microsoft developers clearly stating that Longhorn will not be built on top of
What has been said and still holds true is that any new programming API will most likely only be exposed through
While writing drivers, services, servers, etc is certainly possible with
The only thing this article reveals is that the author has no clue about
I gave FireFox a try for a while, found that it didn't really appeal to me all that much and switched back to IE.
Security concerns have never been an issue for me as far as IE is concerned, nor would I be concerned about flaws in FireFox for that matter.
I've been running as a LU ever since Windows 2000 and I've yet to be plagued by either spyware, trojans, email viruses or anything else malicious.
The only inconvenience that ever crops up is because of vendors who fail to realize their app doesn't need full admin privileges to run and even then, getting it to run as Admin under an interactive LU account is only one extra additional click.
If you were plagued with spyware and viruses while running IE, you're no safer under FireFox or any browser because your basic methodology is flawed.
An LU account, adjusted zone settings and properly set system policies eliminate pretty much anything that IE (or any other browser for that matter) suffers from except phishing and there common sense is the only thing that will keep you safe anyway.
If you are worried about the security impact of a certain site, run your browser in a further restricted context and it won't even have write access to anything what so ever.
If you're a casual computer user then FireFox will keep you safer than IE, at least right now. If you have any bit of technical expertise or interest pertaining to Windows and you still get spyware and virus infections from using IE, you only have yourself to blame.
Blaming your lack of knowledge or unwillingness to keep your computer secure on a piece of software is not only childish, it's reckless. It should be a basic assumption that no matter which program you use, at some point, some flaw is going to appear and your computer will be at risk of running some malicious piece of software or code. The only solution is to make sure the harm it can do is severely limited which the above accomplishes rather well if my personal experience is any indication. Then, if it turns out the program you're using is 100% secure, all the better; if it turns out to have an exploit, you can sit back and watch the rest hype and scream and try to blame anyone or anything but themselves.