I assume we're talking about the situation only in the US here. This problems has been addressed, reasonably successfully, in various other jurisdictions.
For example, in the UK we have a legal requirement that a shop advertising a typical returns policy also has to state clearly that shoppers' statutory rights are not affected. That and things like the Sale of Goods Act and Distance Selling Regulations guarantee shoppers some basic protections regardless of anything a vendor might like to say at sale time.
From a different angle, we have the Unfair Contract Terms Act, which basically says that certain types of contractual clause (things like disclaiming liability even in the case of obvious negligence) are not enforceable.
As a third approach, there is also the point that you have to go into a contract with both sides understanding what's happening and getting something out of it. If you have a contract that is basically a standard issue piece of legalese prepared by the legal department of the big guy, and not effectively negotiable by the little guy, then the courts can strike parts of it if they determine that the imbalance in bargaining power meant the basic properties of a binding contract weren't met.
So through a combination of requiring that those being given information about Ts and Cs also be told that they have other rights, and statute law that renders certain kinds of gross disclaimer explicitly impotent, and the ability for courts to cancel out parts of a contract that weren't negotiated on an equal basis, we have a reasonable degree of protection against the sort of thing you're talking about.
I don't know what the situation is here regarding binding arbitration, though. I've heard of it being used, but from an ethical perspective I tend to think that such terms should automatically be considered unfair in law. We have a legal system to resolve our differences, and allowing a contract to specify that one party may not avail themselves of that system without jumping through hoops is just undermining the legal system. The only reason someone could possibly have for that is if they wanted to pull a fast one that the legal system would not let them get away with. I do appreciate that for two large organisations with effectively equal bargaining power this might not be the case, but I think with things like this it's always best to err on the side of caution.
I used to get PC Mag years ago, but stopped because I felt that the magazine was too biased in favor of MS.
I think all the big paper magazines around these parts have fallen for the same trap there. I gave up PC World, and later PC Pro, because their reviews of new versions of Windows, Office, etc. just seemed like sucking up to MS. That and the fact that in the latter case, they went to cover-DVD-only and more-or-less doubled the price, so I was paying more for a disc mostly full of junk and pretty much all of which I could just download if I wanted it than I was for a magazine that was half ads anyway. Oh, and the fact that most of their news stories were light on details, and those light details had been reported on the Internet weeks earlier.
The only point of still having magazines like this is if they can supply quality, in-depth reviews of products and industry analysis by people with the connections to find the material and the writing ability to report it well. If all they do is publish fluff reviews and sound-bite news, why on earth would I pay for that when I can read the same for free on-line?
On the contrary. You can never prove a theory correct in science. You can only know that you have a theory consistent with the experimental evidence to date. If those experiments are representative of your current situation, then you might reasonably rely on that theory to help you make decisions since it's the best information you have, but that doesn't mean the information is perfect or prove that the theory is universally true and you are "right".
It's fairer to say that in science, you are either consistent with the evidence to date or not.
Great, an animated user interface. As if work doesn't suck enough.
I wouldn't be so negative. There are many trendy user interface elements — animation and use of 3D effects perhaps the most obvious among them — that can still be very effective when used for a good reason. It's just that Flash ads on web sites or the likes of Clippy in Office are the way most people have seen animation used in practice, and thus people tend to associate them with tacky, unhelpful rubbish. Simple animations that inform the user can be great usability aids, though.
Aside from this any full-blown software from them just seems to be way overpriced to begin with.
Yep. I'm thinking about starting a significant writing project, which may wind up turning into a published book a few years down the line. If I do it, I want some proper software to design it with, so I'm looking into what's available.
Word processors aren't really up to the job, so I'm on to DTP software. As much as I admire the OSS community, Scribus isn't even in the running on account of its buginess on Windows for a start. Cheapo DTP like Publisher is out for lack of power. Now I'm on to looking at the big names like InDesign. That actually looks like it would be good enough: the typography isn't perfect but at least it will use pro-grade OpenType fonts, the writing tools aren't great but at least they are usable, etc.
But then I look at the price tag. I'm a guy at home, talking about starting a personal project. I have no magic budget for this. I won't rip off someone else's software, and I'll pay a fair price for something I think would be useful. I have paid for those pro-grade fonts, for example, and they aren't cheap. But hundreds for a product like InDesign for a one-off project that I'm not even sure I'll take anywhere is just too much.
The irony, of course, is that the big companies that could afford to pay the silly prices for things like this (and Office, and Windows, and...) actually don't, because they get volume licensing agreements instead. Meanwhile, all that's happened here is that I don't have any tool good enough to do the job I want to do, and Adobe don't have any money at all from me. So their pricing policy isn't just annoying for me, it seems it's actually counter-productive for them.:-(
Who is this "we" who made you their spokesman? Personally, as a license paying UK resident I'd be perfectly happy if the BBC content was available free to the entire world. I would consider it our gift.
Do you appreciate what that would do to the licence fee?
The BBC makes a substantial chunk of its income from selling on its commissioned content to other countries, just as commercial providers do. That income helps to pay for commissioning new content, or for buying in content from other sources, which would otherwise have to be funded in other ways. Take a look at the figures, particularly the relative importance of licence fees and commercial revenues in the Beeb's accounts, and I don't think it's surprising that many licence fee payers aren't as willing as you to give these "gifts" to the rest of the world.
When the US studios start to supply Lost, 24, The West Wing, Heroes and the like for less than a six-figure sum per episode to the BBC, or to give an example closer to the hearts of many/. posters, don't do things like producing webisodes for BSG and then restricting them to US-only, then perhaps they can have the BBC's material for a low cost in return. Otherwise, you're just playing a fool's game.
Depending on your make/model or bitchiness level, many of the OEM's will ship you a disk. . . for a price.
Actually, I'm pretty sure it used to be part of the OEM seller's agreement with Microsoft that if the seller isn't not supplying original media by default, they must do so on request, and there are limits on what they can charge. So if you find an OEM trying to make money on this when they've already sold you OEM Windows, it's quite likely that either mentioning this or calling Microsoft to report them will get you the relevant disk for free. Do check the small print to see if this is still the case, though; my information may be out of date at this point.
How much of any of these agreements actually has any legal weight and how much is just stating their opinions as if they are law is, in any case, an open question. But hey, what have you got to lose?
THe specialist software that it runs not yet being rewritten for vista- I'm sure it'd work on vista, but in an international event like this you really don't want to get things misbehaving or acting just slightly differently.
In other words, they're not sure they could get things working reliably on Vista, even with plenty of time between now and then to test it.
That cautious approach may be very wise, but it's also very telling. Rejecting an "upgraded" operating system because it doesn't run the software that runs fine on your existing operating system is perfectly legitimate, and is entirely Microsoft's problem.
The apostrophe is important when both possession and plural are possible interpretations of the extra s. In the case of nouns, this can often be ambiguous, but you never need to say "hiss" or "hers" in that context because you would use "their" instead.
This is also the reason that plurals of letters are generally written using the apostrophe: minding your p's and q's is fine, but talking about is is awkward.:-)
I think there's a critical observation to note - these days there's a clear separation between "American English" and "English English". In American English it's a kind of lazier language with many more complicated rules dropped and things shortened or slackened.
How many companies have real physical security? By that I mean trained security officers with guns, on duty 24/7/365.
Well, I'm guessing the answer to that specific question in the UK is basically none, given that in general civilians having firearms is illegal and all...
However, I would imagine that businesses working in certain sensitive industries are used to working with the police, and employ a combination of defensive measures and some rapid call-out arrangement to protect themselves. Given that we don't see banks being robbed all the time, it appears that full-time, gun-carrying staff (are scary black outfits and funky earpieces mandatory as well?) are not a prerequisite for "real physical security".
Actually, Walter does post here (or at least someone sounding like him and using his name does) from time to time. I find his constant advertising and often unsupported claims rather boring, but he does at least have the decency to put his name to them, so I'd be surprised if he also posted AC junk. Perhaps he's slowly accumulating a group of evangelists who bought the hype? <shudder>:-)
I don't think the comparison is as far-fetched as you make out, to be honest. The Java standard library is big, to be sure, but its quality is highly variable and there have been plenty of cock-ups along the way where they rushed into something and now have to live with it. Why else do you think there is more than one GUI framework? And let's be honest, some of the I/O classes are so unwieldy they make Java itself look concise and elegant.
Certainly better vetted and centrally co-ordinated repositories have merit. The quality of code in C++'s own Boost library collection is generally pretty high, thanks mainly to the peer review process involved. Things like CPAN don't have that, but even so, they're useful for solving a great many problems. Even without that, when C++ doesn't have any standard support for user interfaces, networking, concurrency, file systems and other everyday programming models — not even a systematic framework that platform-specific implementations could be built on to minimise porting effort and retraining — then almost anything else seems like a huge step up.
They do, you just don't know what they do, do for example, generic tuple types require metaprogramming, projects where you need to be sure of the quality of your program needs static typing.
Tuples require those things in C++. To swap two variables in Python, you just write a,b=b,a and you're done. To extract function parameters into a tuple in Perl, you just write my ($first, $second, $third) = @_; and you're done.
I'm not even close to rising to the static typing claim.;-)
I can't use the latest eclipse on my 512M dev machine because of the garbage collection. The java allocator cycles through the mapped memory causing constant paging.
You choose a loaded example. For one thing, you're talking about Java, not GC in general. For another, you're talking about Eclipse, not Java programs in general. Go read a few of the papers that have been published over the past 2-3 years about improved approaches to garbage collection. Things can be multiple orders of magnitude faster than they are today in practice, and things like near-real-time performance are also possible. The fact that industrial Java VMs haven't implemented the improved techniques yet doesn't mean they don't exist.
Programming in C++ is much more practical when you use funtional programming with function composition, type polymorphism, and its partial support for dependent types instead of OO and object polymorphism.
Or if that's your preference, you could just use a language designed to support those things, and doing so much better, from the start.
Don't worry, C++ is getting most of the missing features due next year if we're lucky.
No, I'm afraid it's not. What C++ is likely to get around 2009 is a lot of library band-aids for problems other languages don't have in the first place. If they get it right, some of those things should eventually make life easier for your average C++ programmer working in industry. But since your average C++ programmer working in industry is working on an established project with established coding standards using a compiler several years old, it will be a long time before any substantial improvements filter through, and the rest of the world will probably have moved on.
The unfortunate reality is that C++ is being slowly standardised to death, because most of the standards committee are enthusiasts with their own personal interests. It's like your average OSS project: loads of people playing with cool code and a beta release, but hardly anyone writing the tedious but necessary stuff and working on documentation, minor bug fixing, and so on. Without the kind of industrial heavyweight behind it that things like Java and C# have, driving for industrially valuable features and prepared to commit the resources to get them, it seems almost inevitable that C++ will waste away as an application development platform for new projects. Unfortunately, what will replace it is probably those languages with industrial heavyweight marketing machines behind them, and not a new language learning from the decades of experience C++ has given us into developing practical, powerful tools for solving real world problems and combining that with the decades of progress made in other arenas outside the C++ world.
I think you may be confusing me with either a Java evangelist or a C++ basher. I am neither, but I will go through the various points you raised one by one to clarify what I meant.
"Primitive, error-prone control flow constructs"? Such as?
Well, in terms of loops, things like foreach (a real one, not an awkward function template that doesn't work with built-in arrays) and labelled break/continue are no-brainers in any modern procedural language. However, in that area I was really thinking of more powerful things like pattern matching and guards on functions as specific features. Of course, given sufficiently powerful handling of functions or macros, you can effectively define your own control flow constructs, so if you want a forever loop or a generator, you just write it.
Then there are the OO-related issues, based around polymorphism, virtual function dispatch, and dealing with class and member function templates. Look at the elegant simplicity of Smalltalk or the flexibility of Eiffel and then tell me with a straight face that C++'s manual approach to dealing with inheritance and virtual functions is really the best way we could do things. Hint 1: Function overloading vs. function overriding vs. function hiding and their behaviour with virtual function dispatch are crazy. Hint 2: Template resolution takes many pages to describe in the C++ standard. Hint 3: Virtual destructors, 'nuff said.
And this is without getting into dealing with concurrency in any way, never mind with higher-level tools than primitive threads and locks. Take a look at Erlang's message passing approach or recent developments in transactional memory in everything from Haskell to.Net-based languages if you want to see how weak the "standard" threads and locks model really is.
As for functions not being "first-order entities," that's a consequence of C++ being a statically-typed language that puts performance first
Tell that to OCaml, which manages to combine a powerful type system and high-performance imperative features with a functional programming framework quite effectively. As I noted in my previous post, most projects written using C++ today don't need the fast but unsafe and inexpressive approach. Even those that do don't need it most of the time, which is why hybrid approaches like the one OCaml takes have such potential.
Not to mention that you have things like functors that can turn functions into real objects with only a class wrapper as code overhead.
Sorry, but even with the nice tricks in Boost, C++'s support for functional programming is at best mediocre compared to what is common in many other languages today, and I don't just mean the mainly academic ones. Being able to overload operator() and play with templates a bit does not change this, it just makes it slightly less limiting.
"No syntactic support for common data structures"? I'm not even sure what you're talking about here. What kind of syntactic support do you think C++ lacks?
Well, try initialising a std::vector with some literal data and see how far you get. This one is so annoying they're actually planning to add a hack to compensate in the next version of the C++ standard.
But the operator overloading you mentioned, while welcome (Java got this one wrong and just hasn't realised yet), is still quite limited. Want to define a multi-dimensional indexing operator? Better go learn about proxy classes, and template metaprogramming if you don't want to take a significant performance hit while you're doing it. And that's only if your data structure happens to be similar to the array-based built-in stuff. Simple but effective things like the head::tail list notation common in functional languages and amenable to recursive processing through pattern matching are difficult or impossible in C++, even if you create your own classes and overload operators in a re
Well, not really. The first of my four points related to protection against sloppy coding, but the others (which are, IMHO, the more important ones) have nothing to do with how good a coder you are.
I'm sorry, but I just don't understand your post. I frequently do pretty much everything you're talking about there. Pointers are useful, but as I said before, I can't remember the last time I wrote an expression using explicit pointer arithmetic. If you're doing manual memory buffer management for some reason then OK, but even fairly low-level code rarely needs to do that, and it's the sort of thing best wrapped up behind a safe API anyway.
How do you figure that? I work in low-level code, where performance really matters, and I still can't remember the last time I used pointer arithmetic. Sure, I use array indexing all the time, but the fact that this is semantically equivalent to pointer arithmetic in C++ is coincidental. As long as a language supports arrays (as in contiguous memory that supports fast random access — contrast with linked lists) and indirection (call it a pointer, a reference, a link, whatever you like — something you can build graph-like data structures with) then I don't see any need for pointer arithmetic at all.
C++ is far too complex yes. But there is nothing that can really replace it. A language which supports functional, generic, procedural, object-oriented programming, with static typing, metaprogramming, and heavily geared towards native building?
The thing is, most development projects that use C++ today don't need all of that.
C++ is a fine, pragmatic tool, and I have great admiration for Stroustrup's ability to build such a useful thing. C++ is also a powerful systems programming tool.
But C++ is not a good language for most application development, which is what a great deal of code written in it really is. I think there are several separate but somewhat related reasons for this.
One is the safety argument. Most people simply don't need the flexibility/footshootability [delete as applicable] of C++. You need only look at the much-hyped field of garbage collection to see that (a) many professional developers find this one feature useful that they regard Java as superior to C++ for this reason alone, (b) many more professional developers have no clue about the overheads involved (which are almost zero for typical applications using modern approaches to GC implementation), and most importantly (c) a great many developers using languages without GC make mistakes that developers using languages with GC wouldn't. Similar arguments apply to other routine problems, such as pointers/NULL.
The second is the expressive power argument. Life is too short to be using programming languages with primitive, error-prone control flow constructs, functions that aren't first-order entities, no syntactic support for common data structures, crude macros, header files, etc.
Third we have the standard library argument. Yes, yes, you can get a C++ library for almost anything. That's not the point. The key word is "standard". Take a look at the huge practical success of Java and Perl, and tell me the vast Java standard library and CPAN have nothing to do with them. Sure, C++'s standard library is, technically, of a higher quality than most. But it still has stupid flaws (string support and IO streams are both fundamentally broken, for example). More seriously, it has stupid gaps. In the 21st century, it's hard to seriously advocate application development in a language with no standardised support for user interfaces, networking, concurrency, file systems, etc. No, I'm not going to spend days trying to find the right non-standard library for me. Non-standard libraries are for solving significant problems, where the difficulty and scope make it worth investing the time to find and hook in someone else's code. They're not for trivia that everyone uses all the time.
And finally, we have the tools argument. Working with header files sucks, and while just about everyone else is playing with their funky, auto-refactoring, navigation supporting editors, what do we have? VC++ (where refactoring still isn't available in native C++) and Eclipse (which is C++ forced into a Java-like IDE)?
The really scary thing is that reality bites now. It's not like I'm the first person to identify these practical flaws with using C++ for application development. It's not like other people haven't developed languages and tools with all these improvements already. And yet C++ continues to be one of the most important application programming languages today. Why?
Momentum. That's why. Building a new programming language with a syntax that doesn't look like C is asking for trouble; just look at the arguments Python sees over whitespace. (Curiously, I've never seen such complaints made about Haskell. Perhaps this shows a difference between the insight of your average professional programmer vs. your average language geek academic?) More to the point, trying to advocate a new programming language for industrial application development that isn't some form of block-structured, OO-based clone is asking for trouble.
I'm hopeful that over the next few years, as hardwar
If you look at the new Visual Studio 2008 - in the three years since 2005 was released, what does Orcas have for C/C++?
I'll see you VC++ 2008 and raise you VC++.Net (aka VC++ 7.0, aka the 2002 release).
The sad thing is, from a pure C++ programmer's point of view, a lot of people still regard VC++ 6 as the peak. Sure, the standards compliance is better now, and that's a real improvement. Sure, there have been a few optimisation improvements, and those are worthwhile (when they don't introduce bugs). Sure, the debugger has better visualisation support (autoexp.dat) even for native code, and that's definitely useful (if only they'd document it properly).
But when they moved to.Net for everything, the IDE slowed down horribly, even without the Intellisense/multi-threading mess that they finally fixed in 2005SP1. Certain features (I'm looking at you, browse toolbar) actually disappeared from VC++, for the rather poor reason that they couldn't be supported in all.Net languages. I understand that the whole unified architecture thing makes sense from a development perspective at Microsoft, but the bottom line is that users don't care, and removing useful functionality is bad. I also appreciate that, several versions later, we now have most of the same basic functionality back again, but it's still a mess compared to the simple, effective browse toolbar. Similar comments apply to various being-too-clever changes to Intellisense, incidentally.
Perhaps more seriously, as great as all these new optimisations are, we've found far more compiler bugs recently than we ever used to. We write serious mathematical libraries at work, and I promise you it is not fun to spend several days tracking down a bizarre floating point problem, because it turned out that the global optimiser got it wrong fifteen functions up the call stack and now the FPU stack is overflowing.
Meanwhile, we get to see Microsoft putting lots of goodies in for.Net developers. I'm sure they'd love us all to develop for.Net, but until they support it on seven different platforms (where all versions of "Windows" are grouped together as just one of those), it's never going to be of much interest to us.
Right now, Visual C++ is still (in my personal opinion) the best C++ compiler/IDE combination available today. But things move fast in software. Code compiled with g++ has lagged in performance for a long time, but if the recent work behind the scenes on things like SSA bears fruit, that performance gap could close very fast. Eclipse/CDT is so clunky as to be almost unusable for C++ development right now (don't flame me, it's just a personal opinion) but I check every now and then to see how things are going and it sounds like someone might be planning a big clean-up so it doesn't feel like C++ forced into a Java-friendly IDE any more. With Microsoft pushing all their funky new UI support into things like WPF that almost no-one uses, and portable GUI toolkits like wxWidgets and Qt becoming better all the time, it's not like having MFC support is a great bonus for new developments anyway.
In other words, if VC++ 2008 doesn't deliver real improvements for non-.Net-only C++ developers, it's entirely possible that the serious players will be switching to genuinely better open source alternatives for new developments well before the next version of VC++ is out. And that should scare Microsoft, because the superiority of VC++ and the ease of use of VB are the reason so many people have been making effectively Windows-only software for so long.
Now, the fact that Google will provide refunds only through Google Checkout, now that seems pretty unfair to me.
Not only is it probably unethical, it's also seems likely to be illegal in some places. In my country, for example, I wouldn't be surprised to find that if Google has taken money and then backed out on an agreement, they would lose a lawsuit from a customer claiming a refund, or perhaps a partial refund that reflects whatever part of the deal Google has already lived up to. I'm not sure exactly what the TOS for Google Video Store have been, so perhaps I've misunderstood the nature of the service, but if they're relying on contractual conditions amounting to "if we shut down randomly, it's your problem" then I suspect these are unlikely to stand up in court.
But I consider global warming a scientific fact nonetheless.
There is no such thing. There are only scientific theories, which by definition are falsifiable. You may consider that the evidence available today is not sufficient to invalidate the theory that global warming is occurring, or indeed the theory that the actions of mankind are contributing to it, but neither you nor the rest of us have any idea what tomorrow holds. All we can ever do in science is provide plausible theories that match our experimental data and aren't known to be wrong, which others may choose to consider when making decisions.
Fortunately, the programming community is just one big, happy family. In fact, in a recent survey, 99% of programmers agreed that 99% of programmers can't program for ****.
I think you're talking about what is commonly described as "self-documenting" or "self-commenting" code. You're absolutely right that well-designed and well-written code reduces the need for comments dramatically. If each element of your program has a single, clear responsibility, and the names and interfaces reflect those responsibilities, then yes, it's quite possible that you can write many functions with few or any comments needed.
However, the more experienced programmers who are disagreeing with you to an extent also have a point. While the "self-documenting" approach removes the need for comments that describe what is being done — the code itself documents that — someone coming along later to fix a bug, or finding their way around an unfamiliar large system, will rarely be able to determine why something is done as it is just from reading the implementation. This is the time when one good comment is worth a dozen class diagrams and flow charts.
You don't mention how experienced you are, so perhaps you've been here already, but if you've yet to read some of the classic general programming books like Code Complete, I highly recommend them. You'll find a lot of thought-provoking ideas in there if you're an interested but so far relatively inexperienced programmer.
Amusingly, this whole thread actually supports the original poster's point: while everyone here is worrying about mathematical technicalities relating to the x/x, in reality it's almost certain that F=ma was what was needed, and the programmer who just wrote the clean version without introducing special cases never had these problems.
I assume we're talking about the situation only in the US here. This problems has been addressed, reasonably successfully, in various other jurisdictions.
For example, in the UK we have a legal requirement that a shop advertising a typical returns policy also has to state clearly that shoppers' statutory rights are not affected. That and things like the Sale of Goods Act and Distance Selling Regulations guarantee shoppers some basic protections regardless of anything a vendor might like to say at sale time.
From a different angle, we have the Unfair Contract Terms Act, which basically says that certain types of contractual clause (things like disclaiming liability even in the case of obvious negligence) are not enforceable.
As a third approach, there is also the point that you have to go into a contract with both sides understanding what's happening and getting something out of it. If you have a contract that is basically a standard issue piece of legalese prepared by the legal department of the big guy, and not effectively negotiable by the little guy, then the courts can strike parts of it if they determine that the imbalance in bargaining power meant the basic properties of a binding contract weren't met.
So through a combination of requiring that those being given information about Ts and Cs also be told that they have other rights, and statute law that renders certain kinds of gross disclaimer explicitly impotent, and the ability for courts to cancel out parts of a contract that weren't negotiated on an equal basis, we have a reasonable degree of protection against the sort of thing you're talking about.
I don't know what the situation is here regarding binding arbitration, though. I've heard of it being used, but from an ethical perspective I tend to think that such terms should automatically be considered unfair in law. We have a legal system to resolve our differences, and allowing a contract to specify that one party may not avail themselves of that system without jumping through hoops is just undermining the legal system. The only reason someone could possibly have for that is if they wanted to pull a fast one that the legal system would not let them get away with. I do appreciate that for two large organisations with effectively equal bargaining power this might not be the case, but I think with things like this it's always best to err on the side of caution.
I used to get PC Mag years ago, but stopped because I felt that the magazine was too biased in favor of MS.
I think all the big paper magazines around these parts have fallen for the same trap there. I gave up PC World, and later PC Pro, because their reviews of new versions of Windows, Office, etc. just seemed like sucking up to MS. That and the fact that in the latter case, they went to cover-DVD-only and more-or-less doubled the price, so I was paying more for a disc mostly full of junk and pretty much all of which I could just download if I wanted it than I was for a magazine that was half ads anyway. Oh, and the fact that most of their news stories were light on details, and those light details had been reported on the Internet weeks earlier.
The only point of still having magazines like this is if they can supply quality, in-depth reviews of products and industry analysis by people with the connections to find the material and the writing ability to report it well. If all they do is publish fluff reviews and sound-bite news, why on earth would I pay for that when I can read the same for free on-line?
In science, you either are right or wrong
On the contrary. You can never prove a theory correct in science. You can only know that you have a theory consistent with the experimental evidence to date. If those experiments are representative of your current situation, then you might reasonably rely on that theory to help you make decisions since it's the best information you have, but that doesn't mean the information is perfect or prove that the theory is universally true and you are "right".
It's fairer to say that in science, you are either consistent with the evidence to date or not.
Great, an animated user interface. As if work doesn't suck enough.
I wouldn't be so negative. There are many trendy user interface elements — animation and use of 3D effects perhaps the most obvious among them — that can still be very effective when used for a good reason. It's just that Flash ads on web sites or the likes of Clippy in Office are the way most people have seen animation used in practice, and thus people tend to associate them with tacky, unhelpful rubbish. Simple animations that inform the user can be great usability aids, though.
Aside from this any full-blown software from them just seems to be way overpriced to begin with.
Yep. I'm thinking about starting a significant writing project, which may wind up turning into a published book a few years down the line. If I do it, I want some proper software to design it with, so I'm looking into what's available.
Word processors aren't really up to the job, so I'm on to DTP software. As much as I admire the OSS community, Scribus isn't even in the running on account of its buginess on Windows for a start. Cheapo DTP like Publisher is out for lack of power. Now I'm on to looking at the big names like InDesign. That actually looks like it would be good enough: the typography isn't perfect but at least it will use pro-grade OpenType fonts, the writing tools aren't great but at least they are usable, etc.
But then I look at the price tag. I'm a guy at home, talking about starting a personal project. I have no magic budget for this. I won't rip off someone else's software, and I'll pay a fair price for something I think would be useful. I have paid for those pro-grade fonts, for example, and they aren't cheap. But hundreds for a product like InDesign for a one-off project that I'm not even sure I'll take anywhere is just too much.
The irony, of course, is that the big companies that could afford to pay the silly prices for things like this (and Office, and Windows, and...) actually don't, because they get volume licensing agreements instead. Meanwhile, all that's happened here is that I don't have any tool good enough to do the job I want to do, and Adobe don't have any money at all from me. So their pricing policy isn't just annoying for me, it seems it's actually counter-productive for them. :-(
Who is this "we" who made you their spokesman? Personally, as a license paying UK resident I'd be perfectly happy if the BBC content was available free to the entire world. I would consider it our gift.
Do you appreciate what that would do to the licence fee?
The BBC makes a substantial chunk of its income from selling on its commissioned content to other countries, just as commercial providers do. That income helps to pay for commissioning new content, or for buying in content from other sources, which would otherwise have to be funded in other ways. Take a look at the figures, particularly the relative importance of licence fees and commercial revenues in the Beeb's accounts, and I don't think it's surprising that many licence fee payers aren't as willing as you to give these "gifts" to the rest of the world.
When the US studios start to supply Lost, 24, The West Wing, Heroes and the like for less than a six-figure sum per episode to the BBC, or to give an example closer to the hearts of many /. posters, don't do things like producing webisodes for BSG and then restricting them to US-only, then perhaps they can have the BBC's material for a low cost in return. Otherwise, you're just playing a fool's game.
Depending on your make/model or bitchiness level, many of the OEM's will ship you a disk. . . for a price.
Actually, I'm pretty sure it used to be part of the OEM seller's agreement with Microsoft that if the seller isn't not supplying original media by default, they must do so on request, and there are limits on what they can charge. So if you find an OEM trying to make money on this when they've already sold you OEM Windows, it's quite likely that either mentioning this or calling Microsoft to report them will get you the relevant disk for free. Do check the small print to see if this is still the case, though; my information may be out of date at this point.
How much of any of these agreements actually has any legal weight and how much is just stating their opinions as if they are law is, in any case, an open question. But hey, what have you got to lose?
THe specialist software that it runs not yet being rewritten for vista- I'm sure it'd work on vista, but in an international event like this you really don't want to get things misbehaving or acting just slightly differently.
In other words, they're not sure they could get things working reliably on Vista, even with plenty of time between now and then to test it.
That cautious approach may be very wise, but it's also very telling. Rejecting an "upgraded" operating system because it doesn't run the software that runs fine on your existing operating system is perfectly legitimate, and is entirely Microsoft's problem.
The apostrophe is important when both possession and plural are possible interpretations of the extra s. In the case of nouns, this can often be ambiguous, but you never need to say "hiss" or "hers" in that context because you would use "their" instead.
This is also the reason that plurals of letters are generally written using the apostrophe: minding your p's and q's is fine, but talking about is is awkward. :-)
I think there's a critical observation to note - these days there's a clear separation between "American English" and "English English". In American English it's a kind of lazier language with many more complicated rules dropped and things shortened or slackened.
I could care less. It all means the same!
How many companies have real physical security? By that I mean trained security officers with guns, on duty 24/7/365.
Well, I'm guessing the answer to that specific question in the UK is basically none, given that in general civilians having firearms is illegal and all...
However, I would imagine that businesses working in certain sensitive industries are used to working with the police, and employ a combination of defensive measures and some rapid call-out arrangement to protect themselves. Given that we don't see banks being robbed all the time, it appears that full-time, gun-carrying staff (are scary black outfits and funky earpieces mandatory as well?) are not a prerequisite for "real physical security".
Actually, Walter does post here (or at least someone sounding like him and using his name does) from time to time. I find his constant advertising and often unsupported claims rather boring, but he does at least have the decency to put his name to them, so I'd be surprised if he also posted AC junk. Perhaps he's slowly accumulating a group of evangelists who bought the hype? <shudder> :-)
I don't think the comparison is as far-fetched as you make out, to be honest. The Java standard library is big, to be sure, but its quality is highly variable and there have been plenty of cock-ups along the way where they rushed into something and now have to live with it. Why else do you think there is more than one GUI framework? And let's be honest, some of the I/O classes are so unwieldy they make Java itself look concise and elegant.
Certainly better vetted and centrally co-ordinated repositories have merit. The quality of code in C++'s own Boost library collection is generally pretty high, thanks mainly to the peer review process involved. Things like CPAN don't have that, but even so, they're useful for solving a great many problems. Even without that, when C++ doesn't have any standard support for user interfaces, networking, concurrency, file systems and other everyday programming models — not even a systematic framework that platform-specific implementations could be built on to minimise porting effort and retraining — then almost anything else seems like a huge step up.
They do, you just don't know what they do, do for example, generic tuple types require metaprogramming, projects where you need to be sure of the quality of your program needs static typing.
Tuples require those things in C++. To swap two variables in Python, you just write a,b=b,a and you're done. To extract function parameters into a tuple in Perl, you just write my ($first, $second, $third) = @_; and you're done.
I'm not even close to rising to the static typing claim. ;-)
I can't use the latest eclipse on my 512M dev machine because of the garbage collection. The java allocator cycles through the mapped memory causing constant paging.
You choose a loaded example. For one thing, you're talking about Java, not GC in general. For another, you're talking about Eclipse, not Java programs in general. Go read a few of the papers that have been published over the past 2-3 years about improved approaches to garbage collection. Things can be multiple orders of magnitude faster than they are today in practice, and things like near-real-time performance are also possible. The fact that industrial Java VMs haven't implemented the improved techniques yet doesn't mean they don't exist.
Programming in C++ is much more practical when you use funtional programming with function composition, type polymorphism, and its partial support for dependent types instead of OO and object polymorphism.
Or if that's your preference, you could just use a language designed to support those things, and doing so much better, from the start.
Don't worry, C++ is getting most of the missing features due next year if we're lucky.
No, I'm afraid it's not. What C++ is likely to get around 2009 is a lot of library band-aids for problems other languages don't have in the first place. If they get it right, some of those things should eventually make life easier for your average C++ programmer working in industry. But since your average C++ programmer working in industry is working on an established project with established coding standards using a compiler several years old, it will be a long time before any substantial improvements filter through, and the rest of the world will probably have moved on.
The unfortunate reality is that C++ is being slowly standardised to death, because most of the standards committee are enthusiasts with their own personal interests. It's like your average OSS project: loads of people playing with cool code and a beta release, but hardly anyone writing the tedious but necessary stuff and working on documentation, minor bug fixing, and so on. Without the kind of industrial heavyweight behind it that things like Java and C# have, driving for industrially valuable features and prepared to commit the resources to get them, it seems almost inevitable that C++ will waste away as an application development platform for new projects. Unfortunately, what will replace it is probably those languages with industrial heavyweight marketing machines behind them, and not a new language learning from the decades of experience C++ has given us into developing practical, powerful tools for solving real world problems and combining that with the decades of progress made in other arenas outside the C++ world.
I think you may be confusing me with either a Java evangelist or a C++ basher. I am neither, but I will go through the various points you raised one by one to clarify what I meant.
"Primitive, error-prone control flow constructs"? Such as?
Well, in terms of loops, things like foreach (a real one, not an awkward function template that doesn't work with built-in arrays) and labelled break/continue are no-brainers in any modern procedural language. However, in that area I was really thinking of more powerful things like pattern matching and guards on functions as specific features. Of course, given sufficiently powerful handling of functions or macros, you can effectively define your own control flow constructs, so if you want a forever loop or a generator, you just write it.
Then there are the OO-related issues, based around polymorphism, virtual function dispatch, and dealing with class and member function templates. Look at the elegant simplicity of Smalltalk or the flexibility of Eiffel and then tell me with a straight face that C++'s manual approach to dealing with inheritance and virtual functions is really the best way we could do things. Hint 1: Function overloading vs. function overriding vs. function hiding and their behaviour with virtual function dispatch are crazy. Hint 2: Template resolution takes many pages to describe in the C++ standard. Hint 3: Virtual destructors, 'nuff said.
And this is without getting into dealing with concurrency in any way, never mind with higher-level tools than primitive threads and locks. Take a look at Erlang's message passing approach or recent developments in transactional memory in everything from Haskell to .Net-based languages if you want to see how weak the "standard" threads and locks model really is.
As for functions not being "first-order entities," that's a consequence of C++ being a statically-typed language that puts performance first
Tell that to OCaml, which manages to combine a powerful type system and high-performance imperative features with a functional programming framework quite effectively. As I noted in my previous post, most projects written using C++ today don't need the fast but unsafe and inexpressive approach. Even those that do don't need it most of the time, which is why hybrid approaches like the one OCaml takes have such potential.
Not to mention that you have things like functors that can turn functions into real objects with only a class wrapper as code overhead.
Sorry, but even with the nice tricks in Boost, C++'s support for functional programming is at best mediocre compared to what is common in many other languages today, and I don't just mean the mainly academic ones. Being able to overload operator() and play with templates a bit does not change this, it just makes it slightly less limiting.
"No syntactic support for common data structures"? I'm not even sure what you're talking about here. What kind of syntactic support do you think C++ lacks?
Well, try initialising a std::vector with some literal data and see how far you get. This one is so annoying they're actually planning to add a hack to compensate in the next version of the C++ standard.
But the operator overloading you mentioned, while welcome (Java got this one wrong and just hasn't realised yet), is still quite limited. Want to define a multi-dimensional indexing operator? Better go learn about proxy classes, and template metaprogramming if you don't want to take a significant performance hit while you're doing it. And that's only if your data structure happens to be similar to the array-based built-in stuff. Simple but effective things like the head::tail list notation common in functional languages and amenable to recursive processing through pattern matching are difficult or impossible in C++, even if you create your own classes and overload operators in a re
Well, not really. The first of my four points related to protection against sloppy coding, but the others (which are, IMHO, the more important ones) have nothing to do with how good a coder you are.
I'm sorry, but I just don't understand your post. I frequently do pretty much everything you're talking about there. Pointers are useful, but as I said before, I can't remember the last time I wrote an expression using explicit pointer arithmetic. If you're doing manual memory buffer management for some reason then OK, but even fairly low-level code rarely needs to do that, and it's the sort of thing best wrapped up behind a safe API anyway.
How do you figure that? I work in low-level code, where performance really matters, and I still can't remember the last time I used pointer arithmetic. Sure, I use array indexing all the time, but the fact that this is semantically equivalent to pointer arithmetic in C++ is coincidental. As long as a language supports arrays (as in contiguous memory that supports fast random access — contrast with linked lists) and indirection (call it a pointer, a reference, a link, whatever you like — something you can build graph-like data structures with) then I don't see any need for pointer arithmetic at all.
C++ is far too complex yes. But there is nothing that can really replace it. A language which supports functional, generic, procedural, object-oriented programming, with static typing, metaprogramming, and heavily geared towards native building?
The thing is, most development projects that use C++ today don't need all of that.
C++ is a fine, pragmatic tool, and I have great admiration for Stroustrup's ability to build such a useful thing. C++ is also a powerful systems programming tool.
But C++ is not a good language for most application development, which is what a great deal of code written in it really is. I think there are several separate but somewhat related reasons for this.
One is the safety argument. Most people simply don't need the flexibility/footshootability [delete as applicable] of C++. You need only look at the much-hyped field of garbage collection to see that (a) many professional developers find this one feature useful that they regard Java as superior to C++ for this reason alone, (b) many more professional developers have no clue about the overheads involved (which are almost zero for typical applications using modern approaches to GC implementation), and most importantly (c) a great many developers using languages without GC make mistakes that developers using languages with GC wouldn't. Similar arguments apply to other routine problems, such as pointers/NULL.
The second is the expressive power argument. Life is too short to be using programming languages with primitive, error-prone control flow constructs, functions that aren't first-order entities, no syntactic support for common data structures, crude macros, header files, etc.
Third we have the standard library argument. Yes, yes, you can get a C++ library for almost anything. That's not the point. The key word is "standard". Take a look at the huge practical success of Java and Perl, and tell me the vast Java standard library and CPAN have nothing to do with them. Sure, C++'s standard library is, technically, of a higher quality than most. But it still has stupid flaws (string support and IO streams are both fundamentally broken, for example). More seriously, it has stupid gaps. In the 21st century, it's hard to seriously advocate application development in a language with no standardised support for user interfaces, networking, concurrency, file systems, etc. No, I'm not going to spend days trying to find the right non-standard library for me. Non-standard libraries are for solving significant problems, where the difficulty and scope make it worth investing the time to find and hook in someone else's code. They're not for trivia that everyone uses all the time.
And finally, we have the tools argument. Working with header files sucks, and while just about everyone else is playing with their funky, auto-refactoring, navigation supporting editors, what do we have? VC++ (where refactoring still isn't available in native C++) and Eclipse (which is C++ forced into a Java-like IDE)?
The really scary thing is that reality bites now. It's not like I'm the first person to identify these practical flaws with using C++ for application development. It's not like other people haven't developed languages and tools with all these improvements already. And yet C++ continues to be one of the most important application programming languages today. Why?
Momentum. That's why. Building a new programming language with a syntax that doesn't look like C is asking for trouble; just look at the arguments Python sees over whitespace. (Curiously, I've never seen such complaints made about Haskell. Perhaps this shows a difference between the insight of your average professional programmer vs. your average language geek academic?) More to the point, trying to advocate a new programming language for industrial application development that isn't some form of block-structured, OO-based clone is asking for trouble.
I'm hopeful that over the next few years, as hardwar
If you look at the new Visual Studio 2008 - in the three years since 2005 was released, what does Orcas have for C/C++?
I'll see you VC++ 2008 and raise you VC++ .Net (aka VC++ 7.0, aka the 2002 release).
The sad thing is, from a pure C++ programmer's point of view, a lot of people still regard VC++ 6 as the peak. Sure, the standards compliance is better now, and that's a real improvement. Sure, there have been a few optimisation improvements, and those are worthwhile (when they don't introduce bugs). Sure, the debugger has better visualisation support (autoexp.dat) even for native code, and that's definitely useful (if only they'd document it properly).
But when they moved to .Net for everything, the IDE slowed down horribly, even without the Intellisense/multi-threading mess that they finally fixed in 2005SP1. Certain features (I'm looking at you, browse toolbar) actually disappeared from VC++, for the rather poor reason that they couldn't be supported in all .Net languages. I understand that the whole unified architecture thing makes sense from a development perspective at Microsoft, but the bottom line is that users don't care, and removing useful functionality is bad. I also appreciate that, several versions later, we now have most of the same basic functionality back again, but it's still a mess compared to the simple, effective browse toolbar. Similar comments apply to various being-too-clever changes to Intellisense, incidentally.
Perhaps more seriously, as great as all these new optimisations are, we've found far more compiler bugs recently than we ever used to. We write serious mathematical libraries at work, and I promise you it is not fun to spend several days tracking down a bizarre floating point problem, because it turned out that the global optimiser got it wrong fifteen functions up the call stack and now the FPU stack is overflowing.
Meanwhile, we get to see Microsoft putting lots of goodies in for .Net developers. I'm sure they'd love us all to develop for .Net, but until they support it on seven different platforms (where all versions of "Windows" are grouped together as just one of those), it's never going to be of much interest to us.
Right now, Visual C++ is still (in my personal opinion) the best C++ compiler/IDE combination available today. But things move fast in software. Code compiled with g++ has lagged in performance for a long time, but if the recent work behind the scenes on things like SSA bears fruit, that performance gap could close very fast. Eclipse/CDT is so clunky as to be almost unusable for C++ development right now (don't flame me, it's just a personal opinion) but I check every now and then to see how things are going and it sounds like someone might be planning a big clean-up so it doesn't feel like C++ forced into a Java-friendly IDE any more. With Microsoft pushing all their funky new UI support into things like WPF that almost no-one uses, and portable GUI toolkits like wxWidgets and Qt becoming better all the time, it's not like having MFC support is a great bonus for new developments anyway.
In other words, if VC++ 2008 doesn't deliver real improvements for non-.Net-only C++ developers, it's entirely possible that the serious players will be switching to genuinely better open source alternatives for new developments well before the next version of VC++ is out. And that should scare Microsoft, because the superiority of VC++ and the ease of use of VB are the reason so many people have been making effectively Windows-only software for so long.
Now, the fact that Google will provide refunds only through Google Checkout, now that seems pretty unfair to me.
Not only is it probably unethical, it's also seems likely to be illegal in some places. In my country, for example, I wouldn't be surprised to find that if Google has taken money and then backed out on an agreement, they would lose a lawsuit from a customer claiming a refund, or perhaps a partial refund that reflects whatever part of the deal Google has already lived up to. I'm not sure exactly what the TOS for Google Video Store have been, so perhaps I've misunderstood the nature of the service, but if they're relying on contractual conditions amounting to "if we shut down randomly, it's your problem" then I suspect these are unlikely to stand up in court.
But I consider global warming a scientific fact nonetheless.
There is no such thing. There are only scientific theories, which by definition are falsifiable. You may consider that the evidence available today is not sufficient to invalidate the theory that global warming is occurring, or indeed the theory that the actions of mankind are contributing to it, but neither you nor the rest of us have any idea what tomorrow holds. All we can ever do in science is provide plausible theories that match our experimental data and aren't known to be wrong, which others may choose to consider when making decisions.
Fortunately, the programming community is just one big, happy family. In fact, in a recent survey, 99% of programmers agreed that 99% of programmers can't program for ****.
I think you're talking about what is commonly described as "self-documenting" or "self-commenting" code. You're absolutely right that well-designed and well-written code reduces the need for comments dramatically. If each element of your program has a single, clear responsibility, and the names and interfaces reflect those responsibilities, then yes, it's quite possible that you can write many functions with few or any comments needed.
However, the more experienced programmers who are disagreeing with you to an extent also have a point. While the "self-documenting" approach removes the need for comments that describe what is being done — the code itself documents that — someone coming along later to fix a bug, or finding their way around an unfamiliar large system, will rarely be able to determine why something is done as it is just from reading the implementation. This is the time when one good comment is worth a dozen class diagrams and flow charts.
You don't mention how experienced you are, so perhaps you've been here already, but if you've yet to read some of the classic general programming books like Code Complete, I highly recommend them. You'll find a lot of thought-provoking ideas in there if you're an interested but so far relatively inexperienced programmer.
Amusingly, this whole thread actually supports the original poster's point: while everyone here is worrying about mathematical technicalities relating to the x/x, in reality it's almost certain that F=ma was what was needed, and the programmer who just wrote the clean version without introducing special cases never had these problems.