If you don't define "large" as "written in Carbon", then quite a lot.
Of the 30 or so applications I'm currently running, perhaps 3 of them are Carbon. Among the large Cocoa applications I'm currently running are Mail, iPhoto, Xcode, Safari, iCal, OmniGraffle, Colloquy, Adium, and NetNewsWire. The large Carbon applications I'm running are Finder, iTunes, and Firefox.
Pretty much universally, the large Carbon apps exist due to old codebases or a strong need for keeping as much common code as possible when porting to the platform. And I'll note that even Firefox has gone Cocoa with version 3.
Actually, what I said was that it may be worth requiring bank-to-bank transfers to Nigeria to have a physical signature, or at least a direct telephone conversation, rather than allowing them to occur completely automatically. But hey, don't let the truth stand in the way of being an asshole, you can do it!
What percentage of those 140,000 scammers participate in international transactions? Just about 100%.
What percentage of the 140 million normal people participate in international transactions? Not quite 0%, but very close to it.
It's quite possible that the vast majority of Nigerians making international transactions are scammers. Maybe it's not, I don't have the numbers. But you can't just say that because 99.9% of people are law abiding, this measure shouldn't be taken.
Decompilation doesn't bother me excessively. After all, it's only mildly more difficult to reverse engineer a C or C++ program. (Assembly language gets a lot less opaque and confusing after you have some practice with it.) I will admit that it's one of the reasons keeping me from using Python for commercial desktop apps (I use it mainly for open source work, web/CGI, and personal scripts), but it's a relatively insignificant reason for me compared to things like the relative difficulty of calling platform-specific C APIs from Python.
The Python runtime no more counts as "further code" than does the C++ compiler or standard library.
As for the rest of it, I just wanted to see what an actual use of boost::any looks like. So far nobody seems to care to provide an example.
Were there to be a common, consistent library for C++, available on all platforms, such as what exists in Java or Python, then C++ developers could have the level of productivity you enjoy from the tools you use and then we would have a good basis for comparison.
But the whole point of what I'm saying is that there is not such a common, consistent library, and this is a major reason why I don't like to use C++. It's kind of like asking somebody why they prefer to live in New York instead of Cleveland. They give you some story about how much they like the arts, and how much New York is better for the arts because it actually has a lot of artists and theaters and the like. And then a bunch of people tell him that it's not a fair comparison because Cleveland doesn't have the kind of arts scene that NYC does!
Lots of heavy number crunching applications don't really care how long they run.
In my case, I run my app about six times a year. Each event involves running it a few times to refine things. To me it is well worth the tradeoff to save a lot of programmer time for a few hours of CPU time, which is essentially free for me anyway.
As for Azureus, I'm pretty sure that the Azureus programmers would be capable of making it bloated and slow in any language. Its bloat goes far deeper than just using Java. Just look at its GUI! In any case, people who use Azureus must think that it's a good tradeoff.
I don't write low level device drivers. I am merely explaining why I use what I use. I am in no way claiming that my preferences or my tools are universal.
Yeah, that's all well and good, but you seem to be missing my point. I'm not saying C++ is a good choice. I'm not advocating its use. I'm not saying that it will work well or that people use it routinely. All I'm saying is that there exist circumstances where C++ is more portable than these higher level languages, and here is an example of one.
I entirely concede your point, while noting that this sort of higher level design optimization is completely orthogonal to choosing an implementation language.
Yes, if C++ included the same libraries that Python does, this objection would go away. (Why wouldn't it?) The other objections would remain.
And no, GC does stop you from having to think about memory management. So-called "soft leaks" aren't a memory management problem, they're just a regular old code bug. GC doesn't save you from all bugs, or even from a particularly large number of them. It mainly just saves you from programming overhead.
GC also doesn't save you from having to manage external resources as that SafeHandle class does.
RAII is definitely not the design pattern I want. Believe me, I know what RAII is, and I know what I want, and the two do not intersect in any way.
I know it's hard to believe, but there are people out there who legitimately do not like C++. Not because we're stupid, or clueless, or because we've been misled, but simply because we have different constraints on our programming or even just different opinions.
I am my own customer for my primary piece of number-crunching Python. I gladly accept the fact that it takes a few hours to run instead of a few minutes like it probably would in super-efficient C++, as a tradeoff for having been able to write it so much faster.
The customer can do their own tradeoff. If the high level language is faster, then the product should be cheaper. If the customer values speed enough to pay the extra premium for a C++ version, they can do so.
It's the difference between being able to type "import", and having to search, download, compile, and pray. As for few modules being part of the language, every example I listed is built in to Python.
Twisted? I wasn't talking about a 68000 or a Palm. I was talking about an embedded microcontroller with a grand total of 32kB of RAM. About half of that is left to hold both program and data once the kernel gets done taking what it wants. Can you fit Python into 16kB of RAM for both program and data, and still have enough space left over to do anything useful? I'll be very interested if your answer is "yes", but I'm doubtful.
Don't get me wrong, I'm a huge advocate for higher level languages. But there are certain places that C can go that others can't simply because C is really just a user friendly assembly language. And C++ may be difficult to compile, but the end result of its being built on top of C is that it goes nearly anywhere that C does.
Not to mention that C is not a subset of C++. The differences are minor and mostly subtle but they are there and they matter. For example, this trivial bit of very typical C code will not compile in a conforming C++ compiler:
char *x = malloc(10);
I'd suggest asking your "C/C++" interviewees to produce some code that's legal C but not legal C++. It will at the very least be amusing to watch them squirm.
It's supposed to be an illustration, not a comparison. What I really wanted to see was how this boost::any thing gets used to give you the same capabilities. I went ahead and googled up the docs and found the examples, and it looks like a poor, verbose substitute at best.
Well, something in the range of 99% of the desktop applications available on Mac OS X are written in a duck-typed true OO language.
I hold that the main reason that C++ is used so much for large desktop applications on Other Platforms is inertia, pure and simple. Programmers hate change. I realize that this is a purely a statement of opinion and I have no way to back it up.
You seriously think, as you post to a web site that runs entirely on Perl, that there is no evidence that higher level languages are in use today? Get real!
Again, I don't think I'm being unfair, I'm just saying why I use what I use. Python provides more libraries for the stuff I use than C++ does. "Batteries included" makes my life easier. Maybe this isn't fair to C++. So what if it's not? Should I make my life more difficult by using C++ out of a sense of fairness?
As for GC goes, no, it's not "just another memory management aid". Non-GC versus GC is the difference between having to think about memory management and not having to. Automatic refcounting still forces you to manually find and break reference cycles, and garbage collection does not.
I'd argue that it's still very slight. C++ as commonly used and even more as commonly discussed here on Slashdot tries to avoid C as much as possible. And the non-C bits of C++ are about as different from Objective-C as you can get. It's true that they still share C (mostly), but most of the time this fact doesn't change very much.
Programming is not like building a house. You don't get halfway through, change your mind, and then have to tear things down, wasting a great deal of manpower and materials in the process.
Building things that you later have to throw away is simply par for the course. Even if none of your Python survives into the final product, that prototype you built and then threw away is still going to make you more efficient overall. And this outcome is extremely unlikely. More likely is that you discover that all of the slow parts of your program only comprise about 10% of your code. And then you can take those parts out, replace them with C++, and leave the rest of the Python code in place.
Slashdot Mirror
If you don't define "large" as "written in Carbon", then quite a lot.
Of the 30 or so applications I'm currently running, perhaps 3 of them are Carbon. Among the large Cocoa applications I'm currently running are Mail, iPhoto, Xcode, Safari, iCal, OmniGraffle, Colloquy, Adium, and NetNewsWire. The large Carbon applications I'm running are Finder, iTunes, and Firefox.
Pretty much universally, the large Carbon apps exist due to old codebases or a strong need for keeping as much common code as possible when porting to the platform. And I'll note that even Firefox has gone Cocoa with version 3.
Remember: unless you've measured a performance difference, it doesn't exist. Most estimates at performance analysis are wrong.
And of course this applies just as much to all the C++ advocates talking about how slow other languages are.
Actually, what I said was that it may be worth requiring bank-to-bank transfers to Nigeria to have a physical signature, or at least a direct telephone conversation, rather than allowing them to occur completely automatically. But hey, don't let the truth stand in the way of being an asshole, you can do it!
This is poor math.
What percentage of those 140,000 scammers participate in international transactions? Just about 100%.
What percentage of the 140 million normal people participate in international transactions? Not quite 0%, but very close to it.
It's quite possible that the vast majority of Nigerians making international transactions are scammers. Maybe it's not, I don't have the numbers. But you can't just say that because 99.9% of people are law abiding, this measure shouldn't be taken.
You seem to have badly misinterpreted what I said.
I talked about the six reasons why I prefer other languages to C++.
You somehow decided that I was talking about the one single criterion that I ever use when deciding what language to work with.
I'd say that I understand how you could have made this mistake, but I'd be lying. I have no idea how you could possibly misunderstand me that badly.
Decompilation doesn't bother me excessively. After all, it's only mildly more difficult to reverse engineer a C or C++ program. (Assembly language gets a lot less opaque and confusing after you have some practice with it.) I will admit that it's one of the reasons keeping me from using Python for commercial desktop apps (I use it mainly for open source work, web/CGI, and personal scripts), but it's a relatively insignificant reason for me compared to things like the relative difficulty of calling platform-specific C APIs from Python.
The Python runtime no more counts as "further code" than does the C++ compiler or standard library.
As for the rest of it, I just wanted to see what an actual use of boost::any looks like. So far nobody seems to care to provide an example.
Were there to be a common, consistent library for C++, available on all platforms, such as what exists in Java or Python, then C++ developers could have the level of productivity you enjoy from the tools you use and then we would have a good basis for comparison.
But the whole point of what I'm saying is that there is not such a common, consistent library, and this is a major reason why I don't like to use C++. It's kind of like asking somebody why they prefer to live in New York instead of Cleveland. They give you some story about how much they like the arts, and how much New York is better for the arts because it actually has a lot of artists and theaters and the like. And then a bunch of people tell him that it's not a fair comparison because Cleveland doesn't have the kind of arts scene that NYC does!
Lots of heavy number crunching applications don't really care how long they run.
In my case, I run my app about six times a year. Each event involves running it a few times to refine things. To me it is well worth the tradeoff to save a lot of programmer time for a few hours of CPU time, which is essentially free for me anyway.
As for Azureus, I'm pretty sure that the Azureus programmers would be capable of making it bloated and slow in any language. Its bloat goes far deeper than just using Java. Just look at its GUI! In any case, people who use Azureus must think that it's a good tradeoff.
I don't write low level device drivers. I am merely explaining why I use what I use. I am in no way claiming that my preferences or my tools are universal.
I don't know why I'd look into Perl and CPAN. I already have Python and Cocoa.
I'm not trying to convince anybody. A guy asked why people find C++ so difficult. I answered him, and the discussion grew from there.
If you like C++, fine. Good for you. But accept that some people prefer other languages.
Yeah, that's all well and good, but you seem to be missing my point. I'm not saying C++ is a good choice. I'm not advocating its use. I'm not saying that it will work well or that people use it routinely. All I'm saying is that there exist circumstances where C++ is more portable than these higher level languages, and here is an example of one.
I entirely concede your point, while noting that this sort of higher level design optimization is completely orthogonal to choosing an implementation language.
Yes, if C++ included the same libraries that Python does, this objection would go away. (Why wouldn't it?) The other objections would remain.
And no, GC does stop you from having to think about memory management. So-called "soft leaks" aren't a memory management problem, they're just a regular old code bug. GC doesn't save you from all bugs, or even from a particularly large number of them. It mainly just saves you from programming overhead.
GC also doesn't save you from having to manage external resources as that SafeHandle class does.
RAII is definitely not the design pattern I want. Believe me, I know what RAII is, and I know what I want, and the two do not intersect in any way.
I know it's hard to believe, but there are people out there who legitimately do not like C++. Not because we're stupid, or clueless, or because we've been misled, but simply because we have different constraints on our programming or even just different opinions.
I am my own customer for my primary piece of number-crunching Python. I gladly accept the fact that it takes a few hours to run instead of a few minutes like it probably would in super-efficient C++, as a tradeoff for having been able to write it so much faster.
The customer can do their own tradeoff. If the high level language is faster, then the product should be cheaper. If the customer values speed enough to pay the extra premium for a C++ version, they can do so.
It's the difference between being able to type "import", and having to search, download, compile, and pray. As for few modules being part of the language, every example I listed is built in to Python.
Twisted? I wasn't talking about a 68000 or a Palm. I was talking about an embedded microcontroller with a grand total of 32kB of RAM. About half of that is left to hold both program and data once the kernel gets done taking what it wants. Can you fit Python into 16kB of RAM for both program and data, and still have enough space left over to do anything useful? I'll be very interested if your answer is "yes", but I'm doubtful.
Don't get me wrong, I'm a huge advocate for higher level languages. But there are certain places that C can go that others can't simply because C is really just a user friendly assembly language. And C++ may be difficult to compile, but the end result of its being built on top of C is that it goes nearly anywhere that C does.
Not to mention that C is not a subset of C++. The differences are minor and mostly subtle but they are there and they matter. For example, this trivial bit of very typical C code will not compile in a conforming C++ compiler:
char *x = malloc(10);
I'd suggest asking your "C/C++" interviewees to produce some code that's legal C but not legal C++. It will at the very least be amusing to watch them squirm.
It's supposed to be an illustration, not a comparison. What I really wanted to see was how this boost::any thing gets used to give you the same capabilities. I went ahead and googled up the docs and found the examples, and it looks like a poor, verbose substitute at best.
Well, something in the range of 99% of the desktop applications available on Mac OS X are written in a duck-typed true OO language.
I hold that the main reason that C++ is used so much for large desktop applications on Other Platforms is inertia, pure and simple. Programmers hate change. I realize that this is a purely a statement of opinion and I have no way to back it up.
You seriously think, as you post to a web site that runs entirely on Perl, that there is no evidence that higher level languages are in use today? Get real!
Again, I don't think I'm being unfair, I'm just saying why I use what I use. Python provides more libraries for the stuff I use than C++ does. "Batteries included" makes my life easier. Maybe this isn't fair to C++. So what if it's not? Should I make my life more difficult by using C++ out of a sense of fairness?
As for GC goes, no, it's not "just another memory management aid". Non-GC versus GC is the difference between having to think about memory management and not having to. Automatic refcounting still forces you to manually find and break reference cycles, and garbage collection does not.
I'd argue that it's still very slight. C++ as commonly used and even more as commonly discussed here on Slashdot tries to avoid C as much as possible. And the non-C bits of C++ are about as different from Objective-C as you can get. It's true that they still share C (mostly), but most of the time this fact doesn't change very much.
Yes, but you don't write the entire program in it, no more than you construct an entire house out of nails.
Logical fallacy: higher level languages are in use already.
Programming is not like building a house. You don't get halfway through, change your mind, and then have to tear things down, wasting a great deal of manpower and materials in the process.
Building things that you later have to throw away is simply par for the course. Even if none of your Python survives into the final product, that prototype you built and then threw away is still going to make you more efficient overall. And this outcome is extremely unlikely. More likely is that you discover that all of the slow parts of your program only comprise about 10% of your code. And then you can take those parts out, replace them with C++, and leave the rest of the Python code in place.