Yeah, IE in SP2 included a popup blocker extremely similar to the one currently in Firefox (it's strange, because I had that little bar that pops up on IE before I had it on Firefox, I don't know who implemented it first).
Operating systems have to be fast, file systems have to be fast, databases have to be fast, http servers have to be fast, web services servers (e.g. SOAP servers) have to be fast, code libraries have to be fast, interpreters have to be fast. Once all those things are fast, you can make the final, end-user app pretty slow and it will still be so fast the user won't know the difference.
These are mainly either systems which already exist in a fast and stable form, or "language features" which are more likely to be present in newer languages (rather than having to track down a library or reimplement yourself).
As for algorithmic problems, this isn't really relevant to the point of which language one is using (I'm not sure if you're even trying to argue that?), other than the fact that a language with well-implemented utility libraries is likely to have used as good or better an algorithm to yours.
My post was about programming languages, not programming style, in any case.
I'm not convinced that Java, as an example, is a worse general choice than C++ (I'd assert that as often, or more often, than C++ is a good choice, Java would be a good choice, but that's obviously not really fairly decidable). You're right that everything has pros and cons, I just feel that C++'s cons began to outweigh its pros a while back, and it just seems more evident today.
I'm also extremely unconvinced that any of the languages you mention have less "reasoned design decisions" than C++. The advantage of these newer languages is that their programming is, in general, more "safe" than predecessors like C++ -- although none of them are a true "general" language (what is?), a competent coder should be able to pick up the one most suited to his or her project and use it, without fear of having to learn a whole load of coding rules to avoid buffer overruns and the like.
Although C++ can be a reasoned choice sometimes, I do not see it as useful for new projects in a lot of areas. For most purposes, there's a better choice. But that's simply my opinion, of course.
Interesting point, although I'm not sure you're even trying to object to Java itself. To be fair, though, careful selection of packages will, in a lot of situations, be a better solution than complete reimplmentation (a lot of things are basically trivial-but-time-consuming to implement). And yes, Java's GUI support is awful (although a couple of apps seem to have worked past that, recently).
And dear God. O(N^X) queries are a horrible, horrible thing, no matter which language is lumped with dispatching them.
I do agree, largely. I do not like C++ as a language though. C's use can be justified for low-end systems, but C++ is in more of a quandary, since its architecture has been superceded by newer languages -- but yes, if there is a larger system that absolutely, positively has to run fast, it might be beneficial to use C++. Most of the time, though, I think of it as more of a legacy thing in a lot of ways.
Static type-checking is implemented better in a lot of languages than C++, although yes, Python's a special case at not having that feature.
With automated memory (and occasionally other resource) management present in these systems, the "background" applications you describe will generally disappear into the background, and not consume resources. Which is comparable to a well-written program in C or C++, say.
I'm not sure about you, but Java/Mono apps have never caused my computer any strife while in the background, whereas "poorly written" applications implemented in C or C++ have frequently brought my system to the ground with memory leaks and the like.
I've seen plenty of poorly-written, slow code written in C and C++ -- the languages themselves makes it easier to write poor code. There's a time and a place for C, and it's not always -- or even usually -- that time, nor that place.
These tools would not be in widespread use over C or C++ were they not useful. Doing it "properly", using your definition, is more error-prone, and takes longer. But sure, if you want it to run as fast as it possibly can, go for it. It's just not a requirement for 90% of applications, and the benefits just often don't justify the risk.
"Processors are cheap." and "Disk space is cheap." are horrendous excuses for bad programming. If you have used these expressions to justify your application, you are a bad programmer!
"Bad programming" has many points to it. I'd include using an old-fashioned language like C or C++ in a system which does not require huge speed or efficiency (which is almost everything these days). It increases the development time of a project, increases the code complexity, increases the chances of runtime bugs, and increases the potential severity of what bugs you do have.
I'm sorry, but the "but it's slow" argument does not hold for most software designed today. Let's please get over it.
Well spotted!
It's a pity if this isn't real -- it strikes me as a very good idea (in particular, all the stuff on the page is pretty authentic, and their description of the NT kernel is correct to the best of my knowledge of it).
On the other hand, that screen might be the joke...
XP = eXtreme Programming, a means of development which preaches hands-on working and strict adherence to a few work processes. One of these is that all code should be written by two people at once.
OS X's text rendering puts anything else I've seen to shame -- it's sickening to look at screenshots and see something as simple as text make your desktop look ugly!
I'm not sure I get your point. My point is that there is little difference in what you can actually do on their platform. You're arguing about the ease of doing things on either platform. Different issues, really.
I think the point of the statement was that this was simply the reason that people buy them over Windows PCs and so on. In terms of functionality, there's little difference, but riding the success of the iPod, there's been a huge uptake Apple's "beautiful technology" approach. Still an unnecessary comment though, yeah.
He was asserting that what matters was the "whole Mozilla Project", though -- I was trying to justify that the Suite is soon not really going to be a part of that.
Also, the emphasis of the article is that Firefox is gaining popularity at the direct expense of IE, which implies that Suite usership is staying fairly constant (or, at least, unremarkably so).
I know that, I'm just trying to provide a reason that, currently, MoFo isn't really placing an emphasis.
I'm sure the Seamonkey fork project will be fantastic (there's definately some great ideas in there already). The last time I checked, though, they were still all bickering about a name...
Do you mean Mozilla Suite? It's no longer being developed by the Mozilla Foundation (well, there's no plan for a version 1.8, so "no longer" soon). There is a group of people who are planning to fork the code, and continue work on it, but it's likely that the Suite is not gaining popularity because it is considered deprecated now.
Similar to how Microsoft bought out the antivirus company which is software to fix problems that Microsoft made in its OS.
What, that it was present on non-technical user's desktop machines? I mean, I know it's a problem, but someone has to supply these people with computers...
You can change Java to accept/reject as you please, yeah. The problem is that the people who know how to do this are not the ones stupid enough to click "Yes"!
I'm just not getting what the huge advantage to this method is, though? Surely most "boxed" distros give you the opportunity to select which software packages to deploy?
The main problems I see with that are in testing your own software (unlikely to be signed before it's finished development - a flick of a "security off" switch should fix that though) and the fact that it is, in principle, if anything less restrictive than the current system. The same people will be tricked into "trusting a reviewer" as would be into trusting an unsafe applet, I feel.
I like your thinking, but I think this might well just be one of those things where you're gonna have to choose between safe, and less functional, and dangerous but useful.
Surely it's more time-consuming and resource-intensive to do that, though? Unless you've got special needs for your specific setup, why is this an advantage?
This is a "vulnerability" in Java, not Mozilla. The reason it's "cross-browser" is because it's written in Java, and will work on any browser using Sun's JRE (and probably any other compliant one). It's not even a vulnerability in Java, strictly speaking -- it's a signed applet, with an invalid signature, and the user has to click past an ugly-looking "this is unsafe!" error page to infect themselves.
Slashdot Mirror
Yeah, IE in SP2 included a popup blocker extremely similar to the one currently in Firefox (it's strange, because I had that little bar that pops up on IE before I had it on Firefox, I don't know who implemented it first).
As for algorithmic problems, this isn't really relevant to the point of which language one is using (I'm not sure if you're even trying to argue that?), other than the fact that a language with well-implemented utility libraries is likely to have used as good or better an algorithm to yours.
My post was about programming languages, not programming style, in any case.
Yeah, I should've made that more explicit in the post (some of the other posts I've made around this thread have said this more clearly).
I'm not convinced that Java, as an example, is a worse general choice than C++ (I'd assert that as often, or more often, than C++ is a good choice, Java would be a good choice, but that's obviously not really fairly decidable). You're right that everything has pros and cons, I just feel that C++'s cons began to outweigh its pros a while back, and it just seems more evident today.
I'm also extremely unconvinced that any of the languages you mention have less "reasoned design decisions" than C++. The advantage of these newer languages is that their programming is, in general, more "safe" than predecessors like C++ -- although none of them are a true "general" language (what is?), a competent coder should be able to pick up the one most suited to his or her project and use it, without fear of having to learn a whole load of coding rules to avoid buffer overruns and the like.
Although C++ can be a reasoned choice sometimes, I do not see it as useful for new projects in a lot of areas. For most purposes, there's a better choice. But that's simply my opinion, of course.
Interesting point, although I'm not sure you're even trying to object to Java itself. To be fair, though, careful selection of packages will, in a lot of situations, be a better solution than complete reimplmentation (a lot of things are basically trivial-but-time-consuming to implement). And yes, Java's GUI support is awful (although a couple of apps seem to have worked past that, recently).
And dear God. O(N^X) queries are a horrible, horrible thing, no matter which language is lumped with dispatching them.
I do agree, largely. I do not like C++ as a language though. C's use can be justified for low-end systems, but C++ is in more of a quandary, since its architecture has been superceded by newer languages -- but yes, if there is a larger system that absolutely, positively has to run fast, it might be beneficial to use C++. Most of the time, though, I think of it as more of a legacy thing in a lot of ways.
Static type-checking is implemented better in a lot of languages than C++, although yes, Python's a special case at not having that feature.
With automated memory (and occasionally other resource) management present in these systems, the "background" applications you describe will generally disappear into the background, and not consume resources. Which is comparable to a well-written program in C or C++, say.
I'm not sure about you, but Java/Mono apps have never caused my computer any strife while in the background, whereas "poorly written" applications implemented in C or C++ have frequently brought my system to the ground with memory leaks and the like.
I've seen plenty of poorly-written, slow code written in C and C++ -- the languages themselves makes it easier to write poor code. There's a time and a place for C, and it's not always -- or even usually -- that time, nor that place.
These tools would not be in widespread use over C or C++ were they not useful. Doing it "properly", using your definition, is more error-prone, and takes longer. But sure, if you want it to run as fast as it possibly can, go for it. It's just not a requirement for 90% of applications, and the benefits just often don't justify the risk.
I'm sorry, but the "but it's slow" argument does not hold for most software designed today. Let's please get over it.
Well spotted! It's a pity if this isn't real -- it strikes me as a very good idea (in particular, all the stuff on the page is pretty authentic, and their description of the NT kernel is correct to the best of my knowledge of it). On the other hand, that screen might be the joke...
XP = eXtreme Programming, a means of development which preaches hands-on working and strict adherence to a few work processes. One of these is that all code should be written by two people at once.
OS X's text rendering puts anything else I've seen to shame -- it's sickening to look at screenshots and see something as simple as text make your desktop look ugly!
By asserting that, are you not giving away your own bias?
I'm not sure I get your point. My point is that there is little difference in what you can actually do on their platform. You're arguing about the ease of doing things on either platform. Different issues, really.
I think the point of the statement was that this was simply the reason that people buy them over Windows PCs and so on. In terms of functionality, there's little difference, but riding the success of the iPod, there's been a huge uptake Apple's "beautiful technology" approach. Still an unnecessary comment though, yeah.
I'd argue that this was just a matter of wording, was it not for the fact that it's a useful clarfication - likewise your other post :)
He was asserting that what matters was the "whole Mozilla Project", though -- I was trying to justify that the Suite is soon not really going to be a part of that.
Also, the emphasis of the article is that Firefox is gaining popularity at the direct expense of IE, which implies that Suite usership is staying fairly constant (or, at least, unremarkably so).
I know that, I'm just trying to provide a reason that, currently, MoFo isn't really placing an emphasis.
I'm sure the Seamonkey fork project will be fantastic (there's definately some great ideas in there already). The last time I checked, though, they were still all bickering about a name...
Do you mean Mozilla Suite? It's no longer being developed by the Mozilla Foundation (well, there's no plan for a version 1.8, so "no longer" soon). There is a group of people who are planning to fork the code, and continue work on it, but it's likely that the Suite is not gaining popularity because it is considered deprecated now.
You can change Java to accept/reject as you please, yeah. The problem is that the people who know how to do this are not the ones stupid enough to click "Yes"!
I'm just not getting what the huge advantage to this method is, though? Surely most "boxed" distros give you the opportunity to select which software packages to deploy?
There's probably (read: nearly definately) something I'm missing here, though.
The main problems I see with that are in testing your own software (unlikely to be signed before it's finished development - a flick of a "security off" switch should fix that though) and the fact that it is, in principle, if anything less restrictive than the current system. The same people will be tricked into "trusting a reviewer" as would be into trusting an unsafe applet, I feel.
I like your thinking, but I think this might well just be one of those things where you're gonna have to choose between safe, and less functional, and dangerous but useful.
Surely it's more time-consuming and resource-intensive to do that, though? Unless you've got special needs for your specific setup, why is this an advantage?
This is a "vulnerability" in Java, not Mozilla. The reason it's "cross-browser" is because it's written in Java, and will work on any browser using Sun's JRE (and probably any other compliant one). It's not even a vulnerability in Java, strictly speaking -- it's a signed applet, with an invalid signature, and the user has to click past an ugly-looking "this is unsafe!" error page to infect themselves.