...to Google 6 months ago thinking, "nah! what use have they for me when all I've done for the two years is develop photogrammetry software that actually works in the real world, how would that fit their business model?"
On the other hand, from what I hear I'd have been paid peanuts if I worked there.
No, I'm just talking about the fact that you use the best tool for the job. I'm happy to mix and match languages as needed. I'll use a slow language where expressiveness is important and the underlying engine will be in C or C++ where performance matters. If Java was either as fast as, or more expressive than C or C++ we might have used that.
"The only reason...no stack-based variables". That's like some loser claiming "My Ford Focus is only slower than a Ferrari because the engine is crap". Doesn't anyone out there write real code? These things are so f-ing obvious.
Use a simpler language where you don't need to tinker
I'm sorry, I really don't get the connection between simplicty and tinkering. Pure lambda calculus is almost the simplest programming language imaginable and yet there is a vast published literature on the tinkering people have done with it. In fact, when I'm in the mood for tinkering I play with a nice clean and simple language like Haskell. You can spend years and publish reams of papers tinkering to find the optimal way to reimplement even the most trivial things like the 'for' loop in Haskell.
As for reading specifications - thankfully my job involves implementing solutions to real problems rather than implementing a half-baked specification that someone else thought was the solution to the problem they imagined they had.
OK, I hate anecdotal evidence as much as the next person, so I'm now trying to make this really scientific. I'm sure that using all caps in the subject line will attract a high quality sample. So, everyone line up to answer my question...
How much money did you spend on products advertised through google per times you used google?
That was merely one example. The total proportion of programmers who write real time rendering engines, real time simulation engines, real time image processing engines, real time audio engines, real time process control engines and so on is not trivial.
There's a good chance your browser has some shortcuts that will let you get there quicker. For example in Mozilla I can reach this text area by typing R-e-p-tab-tab-tab-tab. The first 3 keys take me straight to the "Reply to This" link.
Of course you're also missing the point. It's easier to use the mouse in many applications because they have been designed with a mouse in mind. But an application designed with the keyboard in mind might be faster to use than one designed mainly for mouse.
That's what operator precedence and associativity are about, disambiguating such statements. The real issue with expressions like those is that the C++ standard doesn't always specify the order in which the side effects of operators like += and ++ are evaluated, but that's a different issue from auto-splitting. (Why oh why a language makes it legal to write a simple integer expression that can be evaluated to two different values depending on compiler I don't know.)
Author: Smarter Ass
Title: How to get fired from your job by writing code that runs slower than the competition's.
Content: Use Python, Java, C# or Objective C.
Just about all games come equipped with their own script engines. But who the do you think writes the engines and what language do you think they use?
The reason why there are so many people around saying we should use Java and C# is ignorance. These people have never had to write code where performance matters. I work on a large graphics application that uses Python bindings to make it easy to use. But we still have to develop non-Python part using a language whose performance doesn't suck beyond belief. If we don't, then the competition will be faster.
At this point I usually have to endure the lecture about how slow code can be speeded up with good algorithms. But we have some of the best people in the field working on our algorithms and still need more speed. There is no choice but to use C++.
Your C++ grammar is impeccable, and I'm sure you have a funny story to tell, but your English is so unparsable I can't tell what you're trying to say. Could you say it again?
...50 times a day for many years. I've clicked on an ad maybe a dozen times in my life. I don't think any of those led to a sale. I wonder how long it will be before the advertisers notice this.
porting Altivec heavy applications to MMX is going to be a pain
This is true. It's one reason why I stopped hand-coding assembler on anything other than microcontrollers a long time ago. Note however that even though there aren't 1-1 mappings between instructions there may still be elegant alternative SSE implementations of Altivec algorithms. Also note that nowadays you can often push Altivec heavy code onto GPUs - even if it's not graphics code.
Yes, these sound completely plausible. That's why the grants get given. I spent 2 years working for a pharmaceutical company (GlaxoWellcomeSmithKlineBeecham... or whatever it's called these days). I don't think I believe anything I read about the modeling of biological systems by computer. You can generate plausible models, but the reality, outside of a lab, is almost always different.
Discussing the relative merits of AltiVec versus SSE/SSE2 is details.
That's the whole point - I'm not discussing that. I'm discussing the relative speed of Macs and PCs. The pro-PowerPC tactic is to distract people away from that and talk about irrelevant microdetails of architecture and deflect direct questions about performance with Keynote presentations showing graphs of performance of specific operations in particular applications ignoring 99.99% of the stuff that actually matters. (I've endured their whole spiel at Infinite Loop myself.)
For picture manipulation work or certain classes of mathematics operations, AltiVec is going to be better than anything else- because it's better and more efficient.
Then you're talking to the right person: a mathematician who works in graphics. (Well, ex-mathematician anyway.) A $1000 PC easily outperforms a $2000 Mac at just about any task you throw at it. The difference between the PC and the Mac is so great, and so f-ing obvious when you have the machines side by with many pieces of numeric and image processing code compiled for both, that I might as well be talking to someone who claims I have 27 fingers for all the sense they're making - or at least someone who expects me to hand code all of my inner loops in assembler, which is just as likely. (Of course I'm not stupid enough to make my comparison between gcc on MacOS X and gcc under Windows. I use a compiler that's good at optimizing for x86 under Windows.)
I love my Mac for the usability of its user interface (both CLI and GUI) and for the fact that it looks so damn good. It depresses me when I have to fire up my ugly old PC when I actually want my code to finish in a reasonable time.
OK, let's not get distracted by details. The big problem with discussing Mac vs PC performance is that even though it's plainly obvious that real applications compiled and run on PCs perform much better than on Macs, the Mac supporters always twist the discussion around to irrelevant microdetails.
So - yes, you're right. Altivec is a better architecture than SSE(2). When Apple get their performace boost it won't be because of the SIMD architecture. I agree with you. But overall, it will be a performance boost.
Not that I care about performance that much myself, I bought my PowerBook for MacOS X.
so long as you weren't using any Altivec-heavy apps (since SSE is a poor replacement)
Look, that was Apple propaganda. They are going to stop spouting it now and so can you. You can stop believing it now and start believing things that are actually true. Like switching to Intel is actually going to give Apple the biggest performance boost they've had for several years.
(And no, I'm not just an Apple-basher. I've been using PowerBooks for years, despite the fact that their performance sucks unbelievably compared to a PC.)
So...I expect 1 in 20 people who go on this diet to survive regardless of diet change. If two such people get cancer I'd expect both to survive 1 time in 400. Out of hundreds of thousands of active/. users (you're # 663,430) I'd expect a couple to fit this 1 in 400 category. So even if an all natural diet has no effect whatsoever on cancer I'd expect to see your post. So I really can't derive any useful information from it, sorry.
Slashdot Mirror
-[((R x D + V) x F) + S]/A
On the other hand, from what I hear I'd have been paid peanuts if I worked there.
You have the wrong calculator. Calculators that can differentiate and solve symbolically have been around for quite a few years now.
"The only reason...no stack-based variables". That's like some loser claiming "My Ford Focus is only slower than a Ferrari because the engine is crap". Doesn't anyone out there write real code? These things are so f-ing obvious.
As for reading specifications - thankfully my job involves implementing solutions to real problems rather than implementing a half-baked specification that someone else thought was the solution to the problem they imagined they had.
Staying grounded in the real world is for earthworms. I like thinking. Try it some time.
How much money did you spend on products advertised through google per times you used google?
That was merely one example. The total proportion of programmers who write real time rendering engines, real time simulation engines, real time image processing engines, real time audio engines, real time process control engines and so on is not trivial.
What's cool and written in Java or .NET?
Of course you're also missing the point. It's easier to use the mouse in many applications because they have been designed with a mouse in mind. But an application designed with the keyboard in mind might be faster to use than one designed mainly for mouse.
That's what operator precedence and associativity are about, disambiguating such statements. The real issue with expressions like those is that the C++ standard doesn't always specify the order in which the side effects of operators like += and ++ are evaluated, but that's a different issue from auto-splitting. (Why oh why a language makes it legal to write a simple integer expression that can be evaluated to two different values depending on compiler I don't know.)
Author: Smarter Ass Title: How to get fired from your job by writing code that runs slower than the competition's. Content: Use Python, Java, C# or Objective C.
The reason why there are so many people around saying we should use Java and C# is ignorance. These people have never had to write code where performance matters. I work on a large graphics application that uses Python bindings to make it easy to use. But we still have to develop non-Python part using a language whose performance doesn't suck beyond belief. If we don't, then the competition will be faster.
At this point I usually have to endure the lecture about how slow code can be speeded up with good algorithms. But we have some of the best people in the field working on our algorithms and still need more speed. There is no choice but to use C++.
Your C++ grammar is impeccable, and I'm sure you have a funny story to tell, but your English is so unparsable I can't tell what you're trying to say. Could you say it again?
What made C so hard for you that of all languages you needed a book for just this one?
...50 times a day for many years. I've clicked on an ad maybe a dozen times in my life. I don't think any of those led to a sale. I wonder how long it will be before the advertisers notice this.
Yes, these sound completely plausible. That's why the grants get given. I spent 2 years working for a pharmaceutical company (GlaxoWellcomeSmithKlineBeecham... or whatever it's called these days). I don't think I believe anything I read about the modeling of biological systems by computer. You can generate plausible models, but the reality, outside of a lab, is almost always different.
I love my Mac for the usability of its user interface (both CLI and GUI) and for the fact that it looks so damn good. It depresses me when I have to fire up my ugly old PC when I actually want my code to finish in a reasonable time.
So - yes, you're right. Altivec is a better architecture than SSE(2). When Apple get their performace boost it won't be because of the SIMD architecture. I agree with you. But overall, it will be a performance boost.
Not that I care about performance that much myself, I bought my PowerBook for MacOS X.
(And no, I'm not just an Apple-basher. I've been using PowerBooks for years, despite the fact that their performance sucks unbelievably compared to a PC.)