I agree with you up to a point: I'm naturally quite a private person, but I keep private things private.
However, I am slightly concerned by ever increasing surveillance of public life. It's just too easy to misconstrue something you see in a single photo. What about the girlfriend who sees an incidental photo of her boyfriend cuddling another girl in the park? She doesn't know it's an old friend who's just suffered a personal tragedy and needs comforting. She just sees her (ex-)boyfriend with another girl.
Your point about government surveillance is really just a special case of this problem. The "I don't care, I've got nothing to hide" crowd make the naive assumption that no-one will ever make a mistake in interpreting the data that's being collected. History strongly disagrees.
As far as the option of people to require photo evidence when placing phone calls.. this comes as a shock.. you could just refuse. It's your right not to take a picture if you don't want to. Tell mom or the boss or whomever to go blow themselves.
This I do have a problem with, and the problem is that "voluntary" things that become the norm are no longer voluntary. It's like a "voluntary" ID card: you don't need it. Unless, of course, you want to buy a drink, open a bank account, rent a car, take out a mortgage or travel abroad.
If you start telling your boss to go screw themselves then, unless everyone else is doing the same, you're just putting yourself first in the firing line. Fortunately, since many ailments serious enough to keep someone off work legitimately don't actually exhibit dramatic physical signs, this one's unlikely to catch on.
I can see the point in family cases and such, though. How am I supposed to go buy an engagement ring for my girlfriend discreetly if I can't tell her I'm going away with the lads at the weekend and I'll be back on Sunday? And would I want to marry a girl who felt that much need to check up on me anyway?
Already halfway through I thought that you are a CS. It shows...
I'm not a CS. I have a postgrad diploma in CS, but my first degree is in a different subject, and my professional career is real world development not academic theory. I simply mentioned the CS qualification to show that I do see value in CS and wasn't having a dig at it or those who choose to study it.
Look, to me (comp.arch) any language is only a limitation.
I confess, I don't understand your point. It seems like saying that hammers and pliers are only limited tools, so we should just think in terms of what we can do with our hands.
Your responses to my specific points, unfortunately, don't actually address the problems, either.
Looking through the libraries is not sufficient. Not knowing these will slow development down, but not knowing the "best practice" idioms of a language will frequently result in a buggy or poorly performing product.
And no, there aren't that many common paradigms, but I get really tired of seeing C++ programmers who write pure OO code then thinking they can write a good app in C because the syntax is much the same, even if they have no idea how to do functional decomposition effectively because they've never modelled using it before.
The only good thing I've seen coming from CS are algorithm skillz.
Perhaps. But then again, for developing real world solutions to real world problems, that's about the most important thing, possibly the only important thing for many people. Everything else is just an application of whatever algorithms are useful in your particular problem domain. What did you think CS was about?
I'm going to be charitable, and assume that your post wasn't just some strange effort to slag off CS while claiming that CA gives you L337 Sk1llz. I don't really see your point either way, though.
I don't think it's a matter of one set of skills being "more important" than another. If you're going to do software development effectively, you simply must have a knowledge of tools, techniques and practices appropriate to your role in the team.
You can have all the process in the world, but if you write code using naff algorithms it'll still take forever to finish. You can have the most efficient algorithm in the world, but if you don't code it properly, you'll still get bugs and/or suboptimal performance. And of course, even if you have great background knowledge and technique in your language, it's no good if you don't meet the original requirements.
If anything, though, I'd say "business process" skills are the most expendable of the three. I've worked in heavy process environments and very lightweight process environments, and the latter have invariably had much better productivity. Process shouldn't play a big role in development, because it wastes time you could otherwise spend developing. Its only purpose in life is to make sure you're developing the right things, and if you get it right, that really takes very little time.
Why do specific languages seem to be more important to employers than CS concepts. Someone with a good background in CS should be able to work in a number of languages and be able to pick up new ones quickly.
This is a common argument, and there is obviously some element of truth to it, but it's still flawed for two big reasons.
You can pick up the basics of new languages quickly. Learning a serious language well, including a grasp of its idioms and at least an overview of the major library components, takes a few months, or longer if you don't have good supervision/training.
It's relatively easy to transfer from one language to another where they follow the same paradigms (procedural, OO, functional, whatever) but learning a whole new paradigm also takes months.
If you think you can take a Java programmer, even one with several years of experience, and get him to program industrial strength C++ with a good book and a couple of weeks of on-the-job practice, I think you're mistaken. He'll write code that compiles, but it won't use the RAII idiom to avoid resource leaks, base classes won't have empty virtual destructors, large class hierarchies won't be divided into a sensible arrangement of files resulting in hideous dependencies at build times, he'll pass random boolean parameters to functions where enumerations are appropriate, etc.
Similarly, you try taking a guy who's used to C and getting him to write functional code using high-level functions, currying and lazy evaluation. The mindset just isn't there, and takes time to develop, not a copy of Learn This Fab Language In 30 Seconds.
The experience issue just isn't as straightforward as some (mostly theoretical, with a heavy CS background) people make out. Experience with general programming technique is very important, but experience with the actual tools still counts for a lot, too.
And before anyone flames, be aware that I'm a professional developer with experience using several diverse languages, and a CS qualification from a well-regarded university, so I don't have any axe to grind against CS here.
I applaud your open mind and your attitude towards foreign policy. If the attitude the rest of us see the US adopt were more in line with your (as in "you personally") own, I think the world would be a much nicer place.
I tend to agree with others here that the problem is not US citizens (several of whom I count amongst the nicest people I've ever met) but in the way your government is manipulating the American public for its own dubious ends, rather than representing the views of those who elected it.
But hey, I live in the UK, where Tony Blair has a huge majority in parliament and can do what he likes even if the vast majority of our population disagree, so who am I to sound all high and wise?:-/
I would guess that the C++ code did just as well as the fortran code because it didn't use many object-oriented features.
There's little that's inherently slow in using OO. Yes, you can have virtual function look-ups giving you an extra level of indirection, but to achieve the same result without OO, you'd just need some other (similarly time-consuming) technique. OO formalises stuff that people do anyway, it doesn't automatically generate new overheads.
A far more likely explanation is that C++ compilers now optimise better than they used to. Comparing native C and C++ procedural code, you should see identical performance, yet C-only compilers have always produced executables that outperformed C++ ones because they've had that much more experience optimising within the framework C creates. As the C++ compiler industry matures, better optimisations are being developed all the time, and the gap is closing as you would expect.
With all the anti-U.S. sentiment that I hear in some discussion groups, are we doing something wrong?
Yes. (I assume "you" to mean "you or your government acting on your behalf".)
Principally, you seem to believe you are better than everyone else. People here make comments about your "economic strength" when your economy right now is one of the worst in the western world. You tell us about your wonderful standards of living, yet your techies work 80 hour weeks and get two weeks of annual leave if they're lucky. But let's cut to the chase.
The single biggest reason that everyone else hates you (and even in "supporting" nations like the UK, a lot of people hate you) is that you throw your weight around. You accuse countries like Iraq of harbouring terrorists, whip up a political storm and try to get allies, yet so far, those of us watching haven't seen a single shred of evidence supporting Bush's "justifications" of a war on Iraq. Students of recent history will note that the US is, itself, guilty of more acts of terrorism (by pretty much any sensible definition of the word) than pretty much everyone else in the world put together.
You want people to like you? Try dealing with others as if you were equals, instead of toppling governments because of a family feud, supporting regimes that torture and kill innocent people, imposing sanctions that kill innocent people but don't touch their governements, feeling you're above the same kind of judgement from abroad that you yourselves impose upon those you dislike, and generally abusing the power that you think you have because more of your population say "Sir yes sir!" with big guns than anyone else's.
It's like we're the automatic moral authority.
Nope, no-one really believes that. Except the US. That's kinda the problem...
This isn't a personal attack on the poster to whom I'm replying, just an honest assessment of how you appear to people with rather less biased media and no self-interest clouding our honesty about US foreign policies and the like. If you're reading this and immediately think what I've said is somehow outrageous or unjustified, I invite you to Google your way to some supporting facts before flaming.
You won't be "future-proof". You'll buy one year of life extension, paying $200 for this service.
But I'm not, that's the point. The card I've just bought (a 9700 Pro) only cost something like 50UKP more than a Geforce 4 Ti4600 would have. The 9700 Pro price has dropped by something like 1/3 since its release over here.
I don't expect anything rivalling the 9700 Pro to arrive for several months, and when it does it is likely to cost almost twice as much as what I'm paying today. Furthermore, it'll be mid-03 before there are many games that need the extras on the 9700 Pro, and that card is so much faster than anything else currently available that it'll probably cope with games for at least 2-3 years before it's too slow.
I'm getting the impression, from the figures some US posters are quoting, that your markets have gone a different way to ours in the UK just now. I spent quite some hours working out the pro's and con's of my choice of graphics card before opting (unusually, for me) to go for a top-of-the-range card rather than something a bit behind the wave but much cheaper. Nothing I've seen here suggests I've made the wrong decision, though clearly YMMV if you live elsewhere.
(I don't rate the resale value of older cards in 18 or 36 months' time, BTW. You could buy the cards in question new for peanuts by that time, and second-hand versions would gain a few pounds back at most.)
Trust me, i want a 9700 Pro, but its not in the cards. Basically, yeah, some of us actually buy cards from the previous generation.
I hear you. For each of the first two PCs I built for myself, I worked ten weeks through a university vacation to earn enough to buy the parts. If that's what you got, you gotta make the best of it. If you can afford a future-proof card right off, though, I reckon it's probably more economic to do that than to buy cheap now and upgrade later on.
I still agree with whoever (likely several people) said that its pointless to spend so much cash when this kind of polygon pumping power isnt even needed yet.
I'm building a new PC, right now. What would you suggest I do?
Buy a 4200 that's going to be out of its league when several of this year's big games arrive, and then spend more money in a few months to upgrade.
Invest in a 9700 Pro now, be future-proof as much as you ever can be, and have prettier graphics in the meantime anyway.
Seems like both will cost a similar amount of money overall, but the second option is far less hassle and gives me all the goodies up front.
If you're upgrading, and already have something like a Ti4200, then it's probably not worth it right now. If you're buying new kit, you'd be mad to settle for second best; this is about the best time to go for a top-of-the-range card there's been in years. Nothing else you can buy today is even close, and I'm still waiting to see any signs that new nVidia stuff will ship widely and sensibly-priced within the next few months.
S'funny you should mention that. I'm just upgrading from a PC with a Voodoo2 sitting in the back to a new PC that only needs one graphics card. It's depressing that my once-pride-and-joy (fastest Quake box on the block, it was) is now smoked by a $50 entry-level card.:o)
As others have mentioned, since there won't be any PC games that really take advantage of DirectX 9 level features for months yet, ATI's "lead" is purely imaginary at this point...
But if you want to buy a card now that will still work with those new games in a few months, you have about one choice. Right now, the 9700 Pro is less than 50% more expensive than any of the other serious graphics cards today, and the Geforce FX is likely to be at least twice as expensive from the few people I've seen prepared to quote it this early. That being the case, it seems silly to go for something like a Geforce 4 Ti 4600 instead and lock yourself out of the DX9 features that are on the horizon, unless you routinely upgrade your graphics card every six months anyway.
Hell, at current rates of progress, they'll arrive before nVidia's new stuff is widely available anyway; I've been hearing rumours about the NVgofasterstripes arriving "next month" for about six months now, but still seen nothing official that's better than "Q1 2003".
You can wait for the day when there isn't a new piece of hardware on the way that'll toast your current kit, but then you just wait forever.
I actually bought a 9700 Pro just the other day, to go in a new PC. All the parts for that PC were custom chosen, a few to have a good price-performance ratio (e.g., only an Athlon XP 2100+) and a few because they're the best around and I don't expect to upgrade them any time soon (the 9700 Pro).
I've been watching the market for several months now, and AFAICS the 9700 Pro I bought is way cheaper than it was those few months ago when it came out, and is likely to be way cheaper than anything new by nVidia initially will be, if and when that comes out. The performance of the 9700 Pro is still way ahead of everything else currently available, so buying a new PC now, with games very much in mind, what would you have done? Saved a whole 25% and bought a Geforce 4 Ti4600 instead?
Unicode is a MBCS, and is entirely suitable for Japanese.
I would distinguish them on the basis that MBCS character representations are not of a fixed size, whereas in any usual representation of the Unicode character set, a character at least occupies a fixed number of bytes.
Dealing with variable-size input is a significant drawback at times. For example, suppose all of your UI strings are represented in a form such as "Place {1} into {2} before {3}" where the {n} are substitutable expressions. It's easy enough to send these phrases off to a translation agency -- often the only realistic option if you're working on a large-scale app in a specialised market -- but if the strings you get back are variable-size MBCS, you need an input layer to convert this into a fixed-size representation (such as one of the usual Unicode ones) before you can use your standard routines to manipulate it for the substitutions and such.
This isn't necessarily a big thing; it's just some sort of filter, as you say. But it is one more thing you have to implement beyond a simple translation before you can port to certain environments.
The L-to-R thing was just an illustration, BTW. I realise that it's fairly straightforward to simply flip a dialog around; many tools or libraries do this with one switch. It's rather more challenging to rework a dialog to fit the translated text, though. You might find that one font's idea of 12pt text is different to a multilingual version's idea of 12pt text, and all your beautifully crafted spacing goes out the window. The most irritating example of dialog box problems I've come across was still the German one, where we had technical terms that translated into a single word too wide to fit on our dialogs...
Generaly, if a program is well-designed its not any harder to translate then a book, I mean, beyond issues of layout and the like.
That would be the bit that takes 90% of the time in practice, then.
Then integrating the results from the translation agency takes the other 90%.
And don't forget all localisable the data that's not just text strings: currencies, dates and times, units for quantities, linguistic idioms, and so on.
Having done it, I promise you that even a well-designed program requires much more effort to translate into a well-designed program for a foreign market than translating a pure text document (book, magazine) between the same languages would need.
Speaking from direct personal experience, the problem of porting an application from one language/country to another is far, far more than just translating some words or phrases.
A widely distributed application (geographically speaking) needs to be built around the idea of porting from the start, so not only the words and phrases in the UI, but the layout of dialog boxes, the use of things like currencies, dates and times, and even the assumptions about where users will naturally look to find things must be considered.
Consider how much effort would be required to take a typical Windoze or Linux app developed for an English-speaking Western audience, and adapt it for use in, say, India. You have to cater to a whole new alphabet or two, for a start. Quick, switch to Unicode! Oh, but the Japanese normally use MBCS. So now we have to rewrite all the text I/O routines to cope not just with different vocabulary, but with different character representations as well. Then you have languages where text is written right-to-left (except when it's not) or vertically. And of course, you'd better reverse all the control layout on your dialogs for R-to-L readers, and probably redesign them completely for vertical presentation. And don't forget to make sure it's wide enough for that 47 letter German word to fit while you're doing it, where the paragraph broke neatly in English or French.
I could go on for a long time about this, and the various techniques you might employ to do it, but the point is that even presenting an application with the text in a different language involves far more than just translating some text. Internationalisation -- designing your app for portability -- takes only a tenth of the effort required for localisation -- adapting the results so they actually make sense in your target culture.
How about these for killer features: Drives that don't have share bandwidth with another device?
The limiting factor in pretty much all serious drives today is the physics, not the bandwidth. Unless you have a huge cache on your drive and data that's friendly to it, raising the bandwidth isn't going to help much any time soon.
Or even drives that don't have to slow down to match the speed of the other device on the chain?
Are you referring to the old "two drives on one IDE channel" issue? That hasn't been a problem since the mid-90s.
Add-in cards that can host 16 or more drives on a single IRQ? Externally? At IDE-drive prices?
Has anyone here (and I'm including full-time BOsFH) ever had the need to set up such a system, or anything close to it? Surely you're looking at hardware RAID arrays rather than zillions of independent hard drives anyway by that point, which kinda makes the IRQ issue a moot point, no?
I think it's all pretty academic in the immediate future anyway, though. I'm actually building a new PC for myself right now, just ordered all the parts yesterday. And I've ordered a nice parallel-ATA Seagate 'cuda IV for my HDD. Why? Because the parallel-ATA 'cuda Vs get reviews that say "good, but nothing much over the IV", and the serial-ATA versions of any of their drives were listed as "long wait expected" or something similar on every supplier site I looked at.
It seems like it'll be a while before you can actually buy these things easily, and after that it'll inevitably be a while longer before they stabilise the teething problems. My new mobo is serial-ATA capable, but I doubt I'll be using it until the next round of upgrades in a year or two.
I appreciate your point of view, having been there myself, but I think we're coming at this from different perspectives. The smallest serious project I have ever worked on in industry would be comparable to your "really long" projects. Much less than that, and it tends to be a sideline for someone rather than a major project. You might call a project with 1M lines of code large in industry terms, though some might disagree, and really large projects have hundreds of people on the project team and take thousands of man-years to develop. As you can see, there's something of a difference in complexity here.:-)
Of course, in this case, we really are talking about a fairly small-scale development. Still, the people who did the project management and estimation at places I've worked have generally been lead programmers as much as managers, and have had 5+ years experience of industrial scale projects as a minimum, often much more. In their time they will often have seen a dozen or more projects through from start to finish as a team member before progressing into project management. When you've seen a few diverse projects right through, you start to develop a feel for how long things will actually take, and unfortunately that feel is usually way out of synch with what the enthusiastic new grad will tell you.
Also, when you're working in industry, you are subject to pressures that aren't an issue for academic projects: your requirements are likely to be unclear at times, or to change as the project moves on, for a start. Learning to cope with these things is something all professional developers have to do, but it's not really something you can learn without actually being there and doing it, IMHO.
While I admire your enthusiasm and desire to gain good experience, and I think the sort of people you describe may well go on to become good project managers in due course, I stand by my claim that even a bright student will necessarily lack the experience to provide useful estimates for a commercial project under normal circumstances.
If your school has a software engineering program, you're in luck, the higher level students should be very good at estimating time involved in programming stuff, but only after you work out what your requirements are.
I very much doubt that. Most SE students have never worked on a serious project in the real world. That's why they're students, not experienced developers. They will probably have little or no knowledge of realistic risk assessment, and the largest project they'll ever have worked on is likely to be a project of a few weeks with just themselves or a small team on it. Under those circumstances, even the brightest student is just going to be plucking a random number from the air.
I don't think it's quite as random as you make out. The fundamental problem is simply that most of those investing -- including those who work for big city firms and have huge bonuses -- are dumb, incompetent or both.
A guy I used to work with (who'll know who he is if he's reading this...) learned how finances work fairly young, and now seems to beat the markets by a few percent most of the time. He had many pearls of wisdom that I dutifully memorised, but basically, everything he did was common sense. He wasn't absurdly greedy, so didn't buy heavily overvalued stocks, didn't stick in rising markets until they crashed, and so on.
There's nothing magical or particularly clever about financial markets, just a whole load of dumb people skewing the outputs. Common sense and a willingness to spend a little time learning how it works will get you ahead of those guys most of the time.
Academy nowadays is involved on creating much more than simple information, but is actually very often a part of the product development cycle. This would not stop, because companies still need products.
Assuming you're talking about industrial R&D rather than universities and the like, then yes, clearly it's true that this is part of the development cycle. The problem is that some things just fundamentally require a lot of effort to develop. Without a guarantee of a reasonable return on investment, it simply wouldn't be good business to develop such products, and thus they wouldn't happen at all. Companies need products that make them money.
(FWIW, I agree that the current laws provide for far too much cover, and I'm not at all in favour of the Disney "We did something once, we should never have to work again" approach. I do think they support a very useful principle, however.)
Slashdot Mirror
I agree with you up to a point: I'm naturally quite a private person, but I keep private things private.
However, I am slightly concerned by ever increasing surveillance of public life. It's just too easy to misconstrue something you see in a single photo. What about the girlfriend who sees an incidental photo of her boyfriend cuddling another girl in the park? She doesn't know it's an old friend who's just suffered a personal tragedy and needs comforting. She just sees her (ex-)boyfriend with another girl.
Your point about government surveillance is really just a special case of this problem. The "I don't care, I've got nothing to hide" crowd make the naive assumption that no-one will ever make a mistake in interpreting the data that's being collected. History strongly disagrees.
This I do have a problem with, and the problem is that "voluntary" things that become the norm are no longer voluntary. It's like a "voluntary" ID card: you don't need it. Unless, of course, you want to buy a drink, open a bank account, rent a car, take out a mortgage or travel abroad.
If you start telling your boss to go screw themselves then, unless everyone else is doing the same, you're just putting yourself first in the firing line. Fortunately, since many ailments serious enough to keep someone off work legitimately don't actually exhibit dramatic physical signs, this one's unlikely to catch on.
I can see the point in family cases and such, though. How am I supposed to go buy an engagement ring for my girlfriend discreetly if I can't tell her I'm going away with the lads at the weekend and I'll be back on Sunday? And would I want to marry a girl who felt that much need to check up on me anyway?
I'm not a CS. I have a postgrad diploma in CS, but my first degree is in a different subject, and my professional career is real world development not academic theory. I simply mentioned the CS qualification to show that I do see value in CS and wasn't having a dig at it or those who choose to study it.
I confess, I don't understand your point. It seems like saying that hammers and pliers are only limited tools, so we should just think in terms of what we can do with our hands.
Your responses to my specific points, unfortunately, don't actually address the problems, either.
Looking through the libraries is not sufficient. Not knowing these will slow development down, but not knowing the "best practice" idioms of a language will frequently result in a buggy or poorly performing product.
And no, there aren't that many common paradigms, but I get really tired of seeing C++ programmers who write pure OO code then thinking they can write a good app in C because the syntax is much the same, even if they have no idea how to do functional decomposition effectively because they've never modelled using it before.
Perhaps. But then again, for developing real world solutions to real world problems, that's about the most important thing, possibly the only important thing for many people. Everything else is just an application of whatever algorithms are useful in your particular problem domain. What did you think CS was about?
I'm going to be charitable, and assume that your post wasn't just some strange effort to slag off CS while claiming that CA gives you L337 Sk1llz. I don't really see your point either way, though.
I don't think it's a matter of one set of skills being "more important" than another. If you're going to do software development effectively, you simply must have a knowledge of tools, techniques and practices appropriate to your role in the team.
You can have all the process in the world, but if you write code using naff algorithms it'll still take forever to finish. You can have the most efficient algorithm in the world, but if you don't code it properly, you'll still get bugs and/or suboptimal performance. And of course, even if you have great background knowledge and technique in your language, it's no good if you don't meet the original requirements.
If anything, though, I'd say "business process" skills are the most expendable of the three. I've worked in heavy process environments and very lightweight process environments, and the latter have invariably had much better productivity. Process shouldn't play a big role in development, because it wastes time you could otherwise spend developing. Its only purpose in life is to make sure you're developing the right things, and if you get it right, that really takes very little time.
Some of us do it every day, and a basic knowledge of things like complexity theory and good basic data structures and algorithms is essential.
But, as you say, the good workman still needs to know his tools, as well as having good technique.
This is a common argument, and there is obviously some element of truth to it, but it's still flawed for two big reasons.
If you think you can take a Java programmer, even one with several years of experience, and get him to program industrial strength C++ with a good book and a couple of weeks of on-the-job practice, I think you're mistaken. He'll write code that compiles, but it won't use the RAII idiom to avoid resource leaks, base classes won't have empty virtual destructors, large class hierarchies won't be divided into a sensible arrangement of files resulting in hideous dependencies at build times, he'll pass random boolean parameters to functions where enumerations are appropriate, etc.
Similarly, you try taking a guy who's used to C and getting him to write functional code using high-level functions, currying and lazy evaluation. The mindset just isn't there, and takes time to develop, not a copy of Learn This Fab Language In 30 Seconds.
The experience issue just isn't as straightforward as some (mostly theoretical, with a heavy CS background) people make out. Experience with general programming technique is very important, but experience with the actual tools still counts for a lot, too.
And before anyone flames, be aware that I'm a professional developer with experience using several diverse languages, and a CS qualification from a well-regarded university, so I don't have any axe to grind against CS here.
You missed out C and VB, which are easily as important as any of the above, but otherwise, I totally agree.
Yep, like the ad I once saw for a "veteran pearl programmer"...
I applaud your open mind and your attitude towards foreign policy. If the attitude the rest of us see the US adopt were more in line with your (as in "you personally") own, I think the world would be a much nicer place.
I tend to agree with others here that the problem is not US citizens (several of whom I count amongst the nicest people I've ever met) but in the way your government is manipulating the American public for its own dubious ends, rather than representing the views of those who elected it.
But hey, I live in the UK, where Tony Blair has a huge majority in parliament and can do what he likes even if the vast majority of our population disagree, so who am I to sound all high and wise? :-/
There's little that's inherently slow in using OO. Yes, you can have virtual function look-ups giving you an extra level of indirection, but to achieve the same result without OO, you'd just need some other (similarly time-consuming) technique. OO formalises stuff that people do anyway, it doesn't automatically generate new overheads.
A far more likely explanation is that C++ compilers now optimise better than they used to. Comparing native C and C++ procedural code, you should see identical performance, yet C-only compilers have always produced executables that outperformed C++ ones because they've had that much more experience optimising within the framework C creates. As the C++ compiler industry matures, better optimisations are being developed all the time, and the gap is closing as you would expect.
Yes. (I assume "you" to mean "you or your government acting on your behalf".)
Principally, you seem to believe you are better than everyone else. People here make comments about your "economic strength" when your economy right now is one of the worst in the western world. You tell us about your wonderful standards of living, yet your techies work 80 hour weeks and get two weeks of annual leave if they're lucky. But let's cut to the chase.
The single biggest reason that everyone else hates you (and even in "supporting" nations like the UK, a lot of people hate you) is that you throw your weight around. You accuse countries like Iraq of harbouring terrorists, whip up a political storm and try to get allies, yet so far, those of us watching haven't seen a single shred of evidence supporting Bush's "justifications" of a war on Iraq. Students of recent history will note that the US is, itself, guilty of more acts of terrorism (by pretty much any sensible definition of the word) than pretty much everyone else in the world put together.
You want people to like you? Try dealing with others as if you were equals, instead of toppling governments because of a family feud, supporting regimes that torture and kill innocent people, imposing sanctions that kill innocent people but don't touch their governements, feeling you're above the same kind of judgement from abroad that you yourselves impose upon those you dislike, and generally abusing the power that you think you have because more of your population say "Sir yes sir!" with big guns than anyone else's.
Nope, no-one really believes that. Except the US. That's kinda the problem...
This isn't a personal attack on the poster to whom I'm replying, just an honest assessment of how you appear to people with rather less biased media and no self-interest clouding our honesty about US foreign policies and the like. If you're reading this and immediately think what I've said is somehow outrageous or unjustified, I invite you to Google your way to some supporting facts before flaming.
But I'm not, that's the point. The card I've just bought (a 9700 Pro) only cost something like 50UKP more than a Geforce 4 Ti4600 would have. The 9700 Pro price has dropped by something like 1/3 since its release over here.
I don't expect anything rivalling the 9700 Pro to arrive for several months, and when it does it is likely to cost almost twice as much as what I'm paying today. Furthermore, it'll be mid-03 before there are many games that need the extras on the 9700 Pro, and that card is so much faster than anything else currently available that it'll probably cope with games for at least 2-3 years before it's too slow.
I'm getting the impression, from the figures some US posters are quoting, that your markets have gone a different way to ours in the UK just now. I spent quite some hours working out the pro's and con's of my choice of graphics card before opting (unusually, for me) to go for a top-of-the-range card rather than something a bit behind the wave but much cheaper. Nothing I've seen here suggests I've made the wrong decision, though clearly YMMV if you live elsewhere.
(I don't rate the resale value of older cards in 18 or 36 months' time, BTW. You could buy the cards in question new for peanuts by that time, and second-hand versions would gain a few pounds back at most.)
I hear you. For each of the first two PCs I built for myself, I worked ten weeks through a university vacation to earn enough to buy the parts. If that's what you got, you gotta make the best of it. If you can afford a future-proof card right off, though, I reckon it's probably more economic to do that than to buy cheap now and upgrade later on.
I'm building a new PC, right now. What would you suggest I do?
Seems like both will cost a similar amount of money overall, but the second option is far less hassle and gives me all the goodies up front.
If you're upgrading, and already have something like a Ti4200, then it's probably not worth it right now. If you're buying new kit, you'd be mad to settle for second best; this is about the best time to go for a top-of-the-range card there's been in years. Nothing else you can buy today is even close, and I'm still waiting to see any signs that new nVidia stuff will ship widely and sensibly-priced within the next few months.
S'funny you should mention that. I'm just upgrading from a PC with a Voodoo2 sitting in the back to a new PC that only needs one graphics card. It's depressing that my once-pride-and-joy (fastest Quake box on the block, it was) is now smoked by a $50 entry-level card. :o)
But if you want to buy a card now that will still work with those new games in a few months, you have about one choice. Right now, the 9700 Pro is less than 50% more expensive than any of the other serious graphics cards today, and the Geforce FX is likely to be at least twice as expensive from the few people I've seen prepared to quote it this early. That being the case, it seems silly to go for something like a Geforce 4 Ti 4600 instead and lock yourself out of the DX9 features that are on the horizon, unless you routinely upgrade your graphics card every six months anyway.
Hell, at current rates of progress, they'll arrive before nVidia's new stuff is widely available anyway; I've been hearing rumours about the NVgofasterstripes arriving "next month" for about six months now, but still seen nothing official that's better than "Q1 2003".
You can wait for the day when there isn't a new piece of hardware on the way that'll toast your current kit, but then you just wait forever.
I actually bought a 9700 Pro just the other day, to go in a new PC. All the parts for that PC were custom chosen, a few to have a good price-performance ratio (e.g., only an Athlon XP 2100+) and a few because they're the best around and I don't expect to upgrade them any time soon (the 9700 Pro).
I've been watching the market for several months now, and AFAICS the 9700 Pro I bought is way cheaper than it was those few months ago when it came out, and is likely to be way cheaper than anything new by nVidia initially will be, if and when that comes out. The performance of the 9700 Pro is still way ahead of everything else currently available, so buying a new PC now, with games very much in mind, what would you have done? Saved a whole 25% and bought a Geforce 4 Ti4600 instead?
I would distinguish them on the basis that MBCS character representations are not of a fixed size, whereas in any usual representation of the Unicode character set, a character at least occupies a fixed number of bytes.
Dealing with variable-size input is a significant drawback at times. For example, suppose all of your UI strings are represented in a form such as "Place {1} into {2} before {3}" where the {n} are substitutable expressions. It's easy enough to send these phrases off to a translation agency -- often the only realistic option if you're working on a large-scale app in a specialised market -- but if the strings you get back are variable-size MBCS, you need an input layer to convert this into a fixed-size representation (such as one of the usual Unicode ones) before you can use your standard routines to manipulate it for the substitutions and such.
This isn't necessarily a big thing; it's just some sort of filter, as you say. But it is one more thing you have to implement beyond a simple translation before you can port to certain environments.
The L-to-R thing was just an illustration, BTW. I realise that it's fairly straightforward to simply flip a dialog around; many tools or libraries do this with one switch. It's rather more challenging to rework a dialog to fit the translated text, though. You might find that one font's idea of 12pt text is different to a multilingual version's idea of 12pt text, and all your beautifully crafted spacing goes out the window. The most irritating example of dialog box problems I've come across was still the German one, where we had technical terms that translated into a single word too wide to fit on our dialogs...
That would be the bit that takes 90% of the time in practice, then.
Then integrating the results from the translation agency takes the other 90%.
And don't forget all localisable the data that's not just text strings: currencies, dates and times, units for quantities, linguistic idioms, and so on.
Having done it, I promise you that even a well-designed program requires much more effort to translate into a well-designed program for a foreign market than translating a pure text document (book, magazine) between the same languages would need.
Speaking from direct personal experience, the problem of porting an application from one language/country to another is far, far more than just translating some words or phrases.
A widely distributed application (geographically speaking) needs to be built around the idea of porting from the start, so not only the words and phrases in the UI, but the layout of dialog boxes, the use of things like currencies, dates and times, and even the assumptions about where users will naturally look to find things must be considered.
Consider how much effort would be required to take a typical Windoze or Linux app developed for an English-speaking Western audience, and adapt it for use in, say, India. You have to cater to a whole new alphabet or two, for a start. Quick, switch to Unicode! Oh, but the Japanese normally use MBCS. So now we have to rewrite all the text I/O routines to cope not just with different vocabulary, but with different character representations as well. Then you have languages where text is written right-to-left (except when it's not) or vertically. And of course, you'd better reverse all the control layout on your dialogs for R-to-L readers, and probably redesign them completely for vertical presentation. And don't forget to make sure it's wide enough for that 47 letter German word to fit while you're doing it, where the paragraph broke neatly in English or French.
I could go on for a long time about this, and the various techniques you might employ to do it, but the point is that even presenting an application with the text in a different language involves far more than just translating some text. Internationalisation -- designing your app for portability -- takes only a tenth of the effort required for localisation -- adapting the results so they actually make sense in your target culture.
The limiting factor in pretty much all serious drives today is the physics, not the bandwidth. Unless you have a huge cache on your drive and data that's friendly to it, raising the bandwidth isn't going to help much any time soon.
Are you referring to the old "two drives on one IDE channel" issue? That hasn't been a problem since the mid-90s.
Has anyone here (and I'm including full-time BOsFH) ever had the need to set up such a system, or anything close to it? Surely you're looking at hardware RAID arrays rather than zillions of independent hard drives anyway by that point, which kinda makes the IRQ issue a moot point, no?
I think it's all pretty academic in the immediate future anyway, though. I'm actually building a new PC for myself right now, just ordered all the parts yesterday. And I've ordered a nice parallel-ATA Seagate 'cuda IV for my HDD. Why? Because the parallel-ATA 'cuda Vs get reviews that say "good, but nothing much over the IV", and the serial-ATA versions of any of their drives were listed as "long wait expected" or something similar on every supplier site I looked at.
It seems like it'll be a while before you can actually buy these things easily, and after that it'll inevitably be a while longer before they stabilise the teething problems. My new mobo is serial-ATA capable, but I doubt I'll be using it until the next round of upgrades in a year or two.
I appreciate your point of view, having been there myself, but I think we're coming at this from different perspectives. The smallest serious project I have ever worked on in industry would be comparable to your "really long" projects. Much less than that, and it tends to be a sideline for someone rather than a major project. You might call a project with 1M lines of code large in industry terms, though some might disagree, and really large projects have hundreds of people on the project team and take thousands of man-years to develop. As you can see, there's something of a difference in complexity here. :-)
Of course, in this case, we really are talking about a fairly small-scale development. Still, the people who did the project management and estimation at places I've worked have generally been lead programmers as much as managers, and have had 5+ years experience of industrial scale projects as a minimum, often much more. In their time they will often have seen a dozen or more projects through from start to finish as a team member before progressing into project management. When you've seen a few diverse projects right through, you start to develop a feel for how long things will actually take, and unfortunately that feel is usually way out of synch with what the enthusiastic new grad will tell you.
Also, when you're working in industry, you are subject to pressures that aren't an issue for academic projects: your requirements are likely to be unclear at times, or to change as the project moves on, for a start. Learning to cope with these things is something all professional developers have to do, but it's not really something you can learn without actually being there and doing it, IMHO.
While I admire your enthusiasm and desire to gain good experience, and I think the sort of people you describe may well go on to become good project managers in due course, I stand by my claim that even a bright student will necessarily lack the experience to provide useful estimates for a commercial project under normal circumstances.
I very much doubt that. Most SE students have never worked on a serious project in the real world. That's why they're students, not experienced developers. They will probably have little or no knowledge of realistic risk assessment, and the largest project they'll ever have worked on is likely to be a project of a few weeks with just themselves or a small team on it. Under those circumstances, even the brightest student is just going to be plucking a random number from the air.
Shame... Before the dot-bomb, it was 20. :-)
I don't think it's quite as random as you make out. The fundamental problem is simply that most of those investing -- including those who work for big city firms and have huge bonuses -- are dumb, incompetent or both.
A guy I used to work with (who'll know who he is if he's reading this...) learned how finances work fairly young, and now seems to beat the markets by a few percent most of the time. He had many pearls of wisdom that I dutifully memorised, but basically, everything he did was common sense. He wasn't absurdly greedy, so didn't buy heavily overvalued stocks, didn't stick in rising markets until they crashed, and so on.
There's nothing magical or particularly clever about financial markets, just a whole load of dumb people skewing the outputs. Common sense and a willingness to spend a little time learning how it works will get you ahead of those guys most of the time.
Assuming you're talking about industrial R&D rather than universities and the like, then yes, clearly it's true that this is part of the development cycle. The problem is that some things just fundamentally require a lot of effort to develop. Without a guarantee of a reasonable return on investment, it simply wouldn't be good business to develop such products, and thus they wouldn't happen at all. Companies need products that make them money.
(FWIW, I agree that the current laws provide for far too much cover, and I'm not at all in favour of the Disney "We did something once, we should never have to work again" approach. I do think they support a very useful principle, however.)