True -- in effect, you're implementing your own heap, which is (hopefully) more suitable than the default heap for your application. But if you start really using it -- lots of allocations/freeing, many different object sizes, multiple threads -- then you'll probably find that the default allocator has better performance than your custom one (unless your custom allocator is quite sophisticated).
Ok, so don't use the heap. There is no reason that C++ needs to use the heap; everything can be allocated on the stack. Just like C.
Well, not _entirely_ true. I mean, obviously, you can program C++ without doing mallocs. The question is, if you restrict yourself in that way, do you give up a major feature of the language? The answer is Yes -- you lose polymorphism, in effect. In order to use objects polymorphically, you must pass pointers to them. The pointers can be upcast/downcast. If you don't pass a pointer, then your object is stripped.
Admittedly, it is possible to pass around pointers to stack-based objects. But in my experience, you don't end up with safe code. What you want is reference-counted objects. Such objects must be allocated on a heap.
I only bring this up because, over the course of several years' C++ programming, I've gradually eliminated almost all heap-based (well, explicitly heap-based) activity. I can do _almost_ everything with stack objects and STL containers. However, whenever I need to make use of polymorphism, I find that I need a reference-counted heap object.
While I agree with you completely about Kodak's cannibalistic abuse of the patent system, I think you're dead wrong about outsourcing. Kodak's whole problem is that it has failed to get with the times quickly enough. In order for American companies to compete with global companies, they must be just as nimble, and just as efficient -- and more so (if they hope to export, which is what America needs to remain competitive). For that to happen, they must take optimal advantage of global labor markets. In the long run, that's what will create high-value jobs in America (ditto for any other high-income country).
Additionally, the design of anything that's patented must be fully disclosed and on the public record, meaning that there is no secrecy involved on the part of the inventor, allowing others to improve the design, even while the patent is still valid, and license the improvement to the original inventor, license the rights to sell the original invention with the improvement, or to wait for the expiration of the first patent and then sell their improvement.
That's the theory. But in practice, software patents typically cover very obvious inventions. Society shouldn't be willing to pay anything at all for these dime-a-dozen inventions, much less yield a 17+ year monopoly for the "inventor" (not the real inventor, just the first group to spend the money/time to get the patent).
Furthermore, typically, companies use what I'd call "landmine patents" -- simple little worthless patents whose purpose is to trip up their competitors (especially little companies without resources to fight wealth destroying legal battles), while keeping the good stuff secret.
Unless society gets a benefit, it should wise up and stop paying the price. And make no mistake -- society certainly pays a price.
You may have a point about Britain -- I'd have to study the subject more to be able to make a fair comparison. Who had what franchise starting when? And how much practical power did the monarchy exert, as a function of time?
The thing about little countries is that they just don't operate on the same scale as big countries. You don't see the same sort of massive disruptions -- civil wars and such. The smaller the group you're trying to organize democratically, the more stable it is. (The US federal system works to ameliorate this -- gaining some of the stability of small countries, by giving very significant powers to the states.) If a small country is nicely isolated, then it suffers from less outside stress, too. It's no accident that frequently-cited antecedents to American democracy are small, isolated countries (Switzerland, New Zealand).
Look at the two early, big, democracies -- the US and Britain. Both benefitted from geographic isolation. That's no accident either.
You can argue that my distinction between big and small countries is artificial -- fair enough. But looking at New Zealand in the 1800's, I'd be thinking "Sure, your democracy's nice. But does it scale?"
I would agree that the US is, historically, the "most stable" democracy. The only large-scale, contemporary (i.e. not counting the ancients), early contenders would be the British and the French (yes, the Swiss, but they're not large-scale).
The British have had a sort-of representative government (Parliament) for, well, a long time -- many hundreds of years (perhaps you could count starting at the Magna Carta, in some sense). However, for the great bulk of that time, Britain has been only weakly democratic -- only the privileged could vote, and the monarchy exerted very strong power. Gradually, moving toward the end of the 1800's, then through the early 1900's, Britain evolved toward what we would today consider to be "true democracy". And it was a very stable transition. No nasty revolutions, civil wars, etc.
By contrast, the US dived head-first into something close to full-out democracy, over 200 years ago. One could say about 100 years earlier than the British. Yes, there were no votes for slaves or women -- but still, the "common man" ruled, which was dramatic and new -- truly radical! With the exception of one major crisis -- the Civil War -- the country has been remarkably stable. One could offer up reasons (e.g. the "splendid isolation" of North America), but could just as well offer up uniquely destabilizing challenges (massive influx of heterogeneous immigrants). For whatever reasons, the fact is that the US democratic system has been very stable for over 200 years. No other (large) country can really compete with that.
Look at the French, to get a glimpse of a possible "alternative history" -- to see how unstable the process of democratization can be. First the trauma of the French Revolution. Then the Napoleonic Wars. Then continuing backsliding with Napoleon III. Or look at Russia! Just absolute _chaos_ in the Russian Revolution, followed by decades of tyrrany.
The process of the "common man" taking over power from the privileged elite is inherently a traumatic one. It can go very, very badly, and take a long time to stabilize. Truly, the American experience stands out from the crowd.
Spurred by the article, I decided to give the Intel compiler a go. However, one stumbling block I've come across is that it doesn't seem to have a visual debugger. That is, idb is akin to gdb. I'm interested in something like gvd or ddd.
Does anyone know of a way to do visual debugging on the Intel compiler's code? (thoughts which come to mind: maybe the Eclipse environment? Maybe a gcc debugger, like gvd, would work on icc's code? Maybe there's another Intel product for visual debugging?)
If you read the article, it's pretty clear that they're talking about how much you pay above-and-beyond the regular electric bill. It used to be 2.5 cents above. Now it's a bargain at only 1 cent above. What you get for your money is the knowledge that you're using renewable energy.
After all, what's been happening since the early 20th century is that the copyright term keeps getting extended, as soon as the previous extension gets close to expiring. Who's to say copyright terms haven't _already_ become infinite?
All I can do is make sure the next edition has no support for Windows whatsoever.
You're annoyed that Microsoft is "invading your space". To get back at them, you're talking about retreating from their space. Who do you think wins in that exchange?
Ultimately, the greatest threat to Microsoft is open source apps which run on both Windows and Linux/BSD/etc. It is those apps which make it easy/possible for people to ditch Windows.
On the flip side having the language be extensible enough to implement things like complex numbers, but also just plain defining them in the language for notional connivence isn't bad.
Yes -- I think you've got it right. You want a language which _lets_ you define all your own primitives, but also a language which supplies you with a decent standard set. The STL is nice that way: templates _let_ you make all your own containers, like arrays, but at the same time, you're supplied with a standard set. Having the standard set isn't just a convenience (which it is, and that's important in its own right). It also means that you can quickly understand other peoples' code. And it also means there's likely to be alot of useful documentation (including not only the regular documentation, but also books, newsgroup postings, etc).
So, the fact that D's arrays are built in to the language is of relatively little importance. Just as good are C++'s standard vector, etc. It doesn't hurt C++ much (if at all) that vector isn't "built in" to the language. It is, really, in every important sense. Same goes for string, etc. All because C++ has _standard_ versions of these (in addition to having the language facilities to create your own versions, if you like).
You don't get runtime checking on char buf[1024] though
Sure -- but if you want safeness, use vector(1024) instead. I know, there's no static initialization of vector. But I tend to use arrays in a specialized way -- only for their static initialization properties. I agree it's a hole in the language, though. D might allow stack-allocated arrays with bounds checking. If so, it has something on C++. Also, D would have something on C++ if its arrays could be statically initialized. I assume they can be...?
You also have problems where a already compiled C++ lib that you want to use was compiled against the normal C++ stdlib so your debug STL iterators can't be passed in (then again most C++ libs come with source -- commercial or not)
Yeah, not having source sucks! I don't mess with things unless I have the source (which is why I use Linux!)
Two. The one to guy who orignally wrote the zortech C++ compiler wrote (which is as far as I know the D reference platform) and a gcc based one...
OK -- that answers one of my questions -- there _is_ a gcc implementation. But not a standard one.
On the other hand we have the argument that "anyone using D, even a first time novice will get GC and bounds checking and libraries with DbC and so on while those same people using C++ will get the poorly designed rotocraft-hellicopter-chansaw-stuffed-into-a-1972- VW-bug that slices their arm off every third time they attempt a left turn without a turn signal, or every sixth time they attempt a right turn with a turn signal".
Well said! Yes -- C++ is a dangerous language. You need to understand it thoroughly. If you do, it's the best thing out there (IMHO, etc). If you don't, use something simpler and safer, like Java, or Visual Basic (now I'm just getting downright _mean_!)
O'Caml is a language I haven't learned.
O'Caml's claim to fame is that it's the "working man's" functional programming language -- a practical functional programming language. There's also Haskell, which is more loved among academics, and ML, which is the original of the ilk. They're a great family of languages! But they lack templates, which makes them not so interesting to me. The reason I'm excited about D is that it appears to be pretty much "functional C++" -- nirvana!
Er, not yet. It has bumped Ruby down to 3rd on the list to try. It hasn't displaced Objective C yet (I have this nifty PowerBook and haven't done more then the Currency Converter tutorial). In fact if it wasn't for all the GUI
I accept the argument that STL things should be thought of as "part of C++", but I'm not sure boost should be thought of as "part of C++"...if you do, what external non-standard libraries do you exclude?
Right -- Boost isn't part of C++. On the other hand, at least in my mind, it's a sort of quasi-standard. It's (usually) well-designed, up to generally-acknowledged C++ best practices (being a peer-reviewed library). It has a permissive license. It's available on a wide range of platforms. It's well documented. Hence, my argument goes like this: if D has feature X, which C++ doesn't have built-in, but which is available in "native-alike" form in a Boost library (that is, if its Boost implementation is so nicely done that it "feels" like it's as good as a built-in C++ feature), then I don't think D has much, if anything, to boast about (on that particular score).
Indeed, to me, it's an indication of a well-designed language if it doesn't _need_ alot of built-in stuff -- the user is able to build their own primitives, in effect. That's power, to me. Especially when you combine that inherent language facility with a mature, broad, widely-used quasi-standard library like Boost.
About array-bounds checking:
It does? I know there are some drop in STL replacements that do this
Exactly what I was referring to. See above reasoning about the Boost library. So, if you're using a well-designed C++ implementation, then it's trivial to have runtime bounds checking in debug mode. True, it isn't built into the language. But I don't care too much about defining what's built-in vs. what isn't. The question is, what is the user experience with a not-too-badly-implemented version of C++? I would argue that in the end, that's all that really matters. I'm not saying the standards documents don't matter -- they do. But what matters more is this: what is the modern, best-practices C++ programming experience like today, vs. D?
Since D is brand-new, I'm guessing there's only one implementation. Hence, whatever's in that D implementation is "part of the D standard". D has it easy that way. C++ has a huge history, with several high-quality and independant implementations. Over time, best practices emerge from the gigantic C++ community, and eventually (hopefully) the best things find their way into the standard. So we should be comparing D best practices to C++ best practices, rather than comparing the D standard (which can change like the wind, and has -- e.g. the addition of templates) to the C++ standard (which takes years to turn over a cycle). Of course, that inertia is a C++ weakness. D has the potential to leapfrog C++ due to this factor. That's what excites me about D.
Thanks for filling me in on some of those D features I had questions on.
"Resource Acquisition Is Initialtion"
Oh, riiiight -- I'd forgotten that one, deep in the mists of time. OK, so D has this, and C++ has this, but not Java. RAII must mean the "deterministic constructor/destructor" paradigm, referred to earlier (i.e. you control exactly when destructors fire).
As for macros: I find lots of uses for them, besides just conditional compilation (at syntactically-awkward moments). My only regret is that they aren't much more powerful in C++. The ideal would be something akin to Lisp -- where the macros generate code at runtime. OK, maybe too much to swallow for a "traditional" language like D (although I don't see why, necessarily...) But O'Caml's macros are quite nice. There's much that can be done with macros, in terms of making code less tedious. For example, look at just about any windowing API (e.g. wxWindows, aka wxWidgets). The fewer the number of keystrokes required to implement a piece of code, the better (given that clarity, etc., is maintained).
Anyway, I'm curious -- you sound like you know alot about D. Have you tried developing with it? I'd be interested to hear what you think of it, as it compares to whatever else you use. I'm tempted to delve into it -- try it out.
But the STL _is_ C++. It's not like the STL is this library hanging off of C++. It's considered to be an integral part of the language. Compiler writers are free to do optimizations based on the known behavior of the STL.
Hence, in all meaningful ways, C++ has the above-mentioned things. It's just pedantic to argue otherwise.
On the other hand, C does _not_ have them, in any meaningful sense (yes, you can write libraries which implement those things, but that's not the same as being part of the language, fully supported by the language's syntax).
OK, I delved into D a bit more. It does look like a very interesting language, now that it has templates.
Some comments, going down the cart (considering D in relation to C++):
Function literals
This is excellent. Function literals would make C++ a much better language. The STL cries out for them. While Java doesn't have function literals, it has something pretty close -- anonymous nested classes. But C++ has nothing very close. The best you can do is something like the Boost lamba library, which while impressive, it quite horrible. This feature makes D pretty interesting to me.
I'd be interested to know what D has in terms of standard libraries -- something akin to the STL..?
Dynamic closures
Not sure exactly what this is, but I imagine it makes D into a fully-functional language. Sounds great! It makes me even more interested.
Resizeable arrays
Well, I don't think this claim stands up -- that C++ doesn't have resizeable arrays. After all, since D is a garbage-collected language, I'm guessing its arrays are on the heap, not the stack. C++ has resizeable heap arrays -- vector, etc.
Arrays of bits
Again, I take issue with C++ not having these. Check out Boost::dynamic_bitset.
Built-in strings
Once again -- no way. C++ certainly has built-in strings, in any meaningful sense of the word -- std::string.
Array slicing
I'd be intersted to see an example of how D's array slicing compares to C++'s interator-based programming. I'm not sure what's being talked about here, exactly.
Array bounds checking
There's really no meaningful way you can say C++ doesn't have array bounds checking. Come on! What C++ has, which might be much better than D, is switchable array bounds checking. You don't _have_ to check array bounds (e.g. for release builds), but it's trivial to add if you want it.
Associative arrays
Wrong! C++ certainly has associative arrays. They're quite excellent. See std::map and std::multimap. And of course, you can build any special sort of associative array you want -- say, a hash.
This chart is completely biased against C++ -- quite unrealistic. Why not just stick to the _real_ benefits D has over C++, and not kick up alot of FUD? It only serves to make people like me (rightfully) skeptical.
Strong typedefs
OK, fine -- typedefs aren't strong in C++. But if you want something to be strong, make it a class/struct/enum. Why do typedef's need to be strong? What's really being said here is that D lacks a "type alias", which is what a C++ typedef is -- just a shorthand for another type. Does D have that?
String switches
Just syntactic sugar, although I admit it might be nice syntactic sugar.
Multiple Inheritance
An unfortunate deficiency of D. I find multiple inheritance to be quite useful. But D can't have everything -- that's OK. If this were D's only deficiency, it wouldn't be fatal to me, especially because...
Interfaces... interfaces get you _most_ of what's good about multiple inheritance. But not all.
Dynamic class loading
This is a nice thing about Java. Too bad D doesn't have it (but hardly a fatal problem, for me).
Inner classes
Seems like D's functional programming capabilities trump the lack of inner classes...
Covariant return types
Ummm -- what are these? C++ has them, so I must know what they are....
Properties
Syntactic sugar...?
Inline assembler Direct access to hardware Direct native code gen
Excellent. However, one reason I really like C++ is that there are toolchains for a huge variety of hardware. If there were a gcc front-end for D, that would go a long way to addressing this issue...
There's nothing wrong with them, except that I didn't know about them...:-)
Templates are something new for D -- last time it came up on/. D didn't have them. In quickly reading the article, I missed any mention of templates, although going back, I see they were mentioned in passing.
I would argue the existence of a preprocessor is not archaic (although I would grant you that C/C++'s preprocessor is archaic).
Preprocessors allow you to deal with a great range of unanticipated situations -- allowing you to come up with creative solutions to sticky problems. Granted, they can be abused. So what? Don't abuse them.
The biggest thing I don't like about Java, now that it has templates, is that it's missing a (standard) preprocessor.
D has 2 strikes against it: first, no templates. Without templates, it's horribly inconvenient to write safe (i.e. strongly-typed) code. Second, it has no (standard) preprocessor.
In theory, this sounds like a nice enough idea. But in practice, I think many speed limits are absurdly low, and are (rightly) routinely ignored.
If a system like this were to be implemented, and not cause mass grousing by normal drivers, then it would be necessary to couple it with a program to determine what the "in practice" speed limits are, and change the speed limits accordingly.
In other words, if the goal is to affect just the 10% of really-bad speeders, then that's fine. But if you affect a much greater % than that, the program won't be sustainable! (and rightly so!)
I'm sure there would never _be_ an effort to reform speed limits to reflect on-the-ground reality. Therefore, I think the program's a bad idea -- something I'll be grousing about if it's ever implemented around here.
Linux answer to this is KnoppMyth, etc.
on
The Paradox of Choice
·
· Score: 2, Insightful
Linux has a much better answer to the problem of excessive choice than Windows does. Look for example at the KnoppMyth project. Its aim is to produce a live CD which gives you a PVR. That's incredibly powerful! In principle, all a user needs is this CD, plug it into their PC (assuming it has the necessary hardware), and PRESTO! All the complex stuff has been figured out by someone else, and the user has a simple interface to accomplish exactly what it is they want - to record/playback their television shows.
I imagine this special-purpose live-CD phenomenon will prove to be very powerful, and will be an important channel through which Linux will eventually eclipse Windows.
I think the main problem with the patent system is that the "non-obvious" standard is mostly ignored by patent examiners. The standard for a novel idea is supposed to be something like "non-obvious to someone skilled in the field".
I mean, PLEASE!!! Applying well-known user-interface techniques from other domains to a new domain (mp3 player)??? That isn't obvious to one skilled in the field?
I hate the patent system. And yes, I have applied for/received a patent -- but it takes alot of time & money. I can't possibly afford to patent every stinking idea at the level of those being applied for by Apple. In effect, the patent system is being used as a mechanism for established companies (with cash flow) to lock out small players. A horribly anti-competitive system!
First, "Rome" didn't really get shattered, as you're saying. The Roman empire divided into 2 halves. The Western half did gradually succumb to barbarian tribes -- in the 400's or so. The Eastern half, with its capital in Constantinople, lasted much longer. I can't remember when the Turks finally took them down -- I think around the 1200's.
So what was your point about Rome? The Western Romans succumbed to barbarians tribes, but not the Eastern Romans. Was it because the Easterners were "nicer"? I hardly think so. There are reasons -- lots of them -- but they're more subtle than the "popular image" of the ever-more-profligate, self-indulgent, even insane (due to lead in glass, etc) Romans finally getting their just desserts!
The Windows registry is quite simply a primitive (i.e. dumbed-down) filesystem. There's nothing particularly special about it. On the other hand, there's plenty which is un-special about it. For one thing, there's no permission control. By contrast, since Linux uses the regular filesystem for program settings, permissions can be fine-tuned. In other words, what you're asking for:
config db that uses permissions so one program can't overwrite another's data without proper access
is something which Linux currently offers (you need to set up the permissions yourself to achieve whatever goal you're after), but which Windows doesn't, exactly because of its registry.
There are plenty of other reasons to prefer to use the regular filesystem for program settings, rather than a registry.
For example, (good, modern) filesystems are instrial-strength, designed to survive dirty shutdowns, etc. By contrast, a registry is prone to getting corrupted.
Futhermore, if your settintg are in a regular filesystem, you can access them with regular programs (e.g. grep -R pattern/etc, or some complex filter chain -- the regular-old UNIX tools which you (should) know so well). By contrast, you will need special registry-specific programs to do anything with the registry. These programs are going to be very primitive, and you're not going to be as fluent with them. In short, they will suck.
Yet another reason: if the settings are in the regular filesystem, then they can be easily changed remotely. E.g. you can ssh to the machine, then vi/etc/something (i.e. text-mode). If your registry-editing program is a GUI (which is likely), then you won't be able to do this.
In a similar vein, suppose your GUI frontend (e.g. your X server) won't work. If your settings are all in regular files, editable by regular programs, then there's no problem -- just boot into text mode, and find/fix your problems using textmode programs (find, grep, vi, etc). If your settings are in a registry, then you won't be able to use your regular GUI registry-editing program. If you're lucky, you'll have some even-more-primitive textmode program you can fall back on. If you're unlucky, you're hosed -- you get to re-install your OS!
The reverse is true: IE hasn't improved much in functionality over the past 2-3 years. Meanwhile, Mozilla, which was re-written from scratch to be easily expandable, has bounded well ahead of IE. I'm thinking of things like tabbed browsing, popup block, junk filtering, XUL. Perhaps IE would benefit from being written re-engineered from the ground up...?
In true/. fashion, I haven't read the original article -- just all the +5 point-counterpoint responses.
The basic problem is that 3 yrs ago, the county made a bad decision -- letting this guy create/manage their website, seemingly without oversight. As time went on, they naturally became more locked in. Now, they're completely locked in to this guy. Anything the guy asks for could be seen as extortion (in the county's eyes).
The basic problem, it seems to me, is that the county should have applied greater oversight, and ensured at all times that the website designer guy wasn't required for the continued operation of the site. They should never have become so dependant on this one guy.
Which brings me to Microsoft... (need I spell it out?)
The power wouldn't be so bad. The computers wouldn't have monitors, and the disks would be kept spun down most of the time. I suppose each might draw 100W, or 1000W for the whole thing.
Slashdot Mirror
True -- in effect, you're implementing your own heap, which is (hopefully) more suitable than the default heap for your application. But if you start really using it -- lots of allocations/freeing, many different object sizes, multiple threads -- then you'll probably find that the default allocator has better performance than your custom one (unless your custom allocator is quite sophisticated).
Well, not _entirely_ true. I mean, obviously, you can program C++ without doing mallocs. The question is, if you restrict yourself in that way, do you give up a major feature of the language? The answer is Yes -- you lose polymorphism, in effect. In order to use objects polymorphically, you must pass pointers to them. The pointers can be upcast/downcast. If you don't pass a pointer, then your object is stripped.
Admittedly, it is possible to pass around pointers to stack-based objects. But in my experience, you don't end up with safe code. What you want is reference-counted objects. Such objects must be allocated on a heap.
I only bring this up because, over the course of several years' C++ programming, I've gradually eliminated almost all heap-based (well, explicitly heap-based) activity. I can do _almost_ everything with stack objects and STL containers. However, whenever I need to make use of polymorphism, I find that I need a reference-counted heap object.
While I agree with you completely about Kodak's cannibalistic abuse of the patent system, I think you're dead wrong about outsourcing. Kodak's whole problem is that it has failed to get with the times quickly enough. In order for American companies to compete with global companies, they must be just as nimble, and just as efficient -- and more so (if they hope to export, which is what America needs to remain competitive). For that to happen, they must take optimal advantage of global labor markets. In the long run, that's what will create high-value jobs in America (ditto for any other high-income country).
That's the theory. But in practice, software patents typically cover very obvious inventions. Society shouldn't be willing to pay anything at all for these dime-a-dozen inventions, much less yield a 17+ year monopoly for the "inventor" (not the real inventor, just the first group to spend the money/time to get the patent).
Furthermore, typically, companies use what I'd call "landmine patents" -- simple little worthless patents whose purpose is to trip up their competitors (especially little companies without resources to fight wealth destroying legal battles), while keeping the good stuff secret.
Unless society gets a benefit, it should wise up and stop paying the price. And make no mistake -- society certainly pays a price.
You may have a point about Britain -- I'd have to study the subject more to be able to make a fair comparison. Who had what franchise starting when? And how much practical power did the monarchy exert, as a function of time?
The thing about little countries is that they just don't operate on the same scale as big countries. You don't see the same sort of massive disruptions -- civil wars and such. The smaller the group you're trying to organize democratically, the more stable it is. (The US federal system works to ameliorate this -- gaining some of the stability of small countries, by giving very significant powers to the states.) If a small country is nicely isolated, then it suffers from less outside stress, too. It's no accident that frequently-cited antecedents to American democracy are small, isolated countries (Switzerland, New Zealand).
Look at the two early, big, democracies -- the US and Britain. Both benefitted from geographic isolation. That's no accident either.
You can argue that my distinction between big and small countries is artificial -- fair enough. But looking at New Zealand in the 1800's, I'd be thinking "Sure, your democracy's nice. But does it scale?"
I would agree that the US is, historically, the "most stable" democracy. The only large-scale, contemporary (i.e. not counting the ancients), early contenders would be the British and the French (yes, the Swiss, but they're not large-scale).
The British have had a sort-of representative government (Parliament) for, well, a long time -- many hundreds of years (perhaps you could count starting at the Magna Carta, in some sense). However, for the great bulk of that time, Britain has been only weakly democratic -- only the privileged could vote, and the monarchy exerted very strong power. Gradually, moving toward the end of the 1800's, then through the early 1900's, Britain evolved toward what we would today consider to be "true democracy". And it was a very stable transition. No nasty revolutions, civil wars, etc.
By contrast, the US dived head-first into something close to full-out democracy, over 200 years ago. One could say about 100 years earlier than the British. Yes, there were no votes for slaves or women -- but still, the "common man" ruled, which was dramatic and new -- truly radical! With the exception of one major crisis -- the Civil War -- the country has been remarkably stable. One could offer up reasons (e.g. the "splendid isolation" of North America), but could just as well offer up uniquely destabilizing challenges (massive influx of heterogeneous immigrants). For whatever reasons, the fact is that the US democratic system has been very stable for over 200 years. No other (large) country can really compete with that.
Look at the French, to get a glimpse of a possible "alternative history" -- to see how unstable the process of democratization can be. First the trauma of the French Revolution. Then the Napoleonic Wars. Then continuing backsliding with Napoleon III. Or look at Russia! Just absolute _chaos_ in the Russian Revolution, followed by decades of tyrrany.
The process of the "common man" taking over power from the privileged elite is inherently a traumatic one. It can go very, very badly, and take a long time to stabilize. Truly, the American experience stands out from the crowd.
Spurred by the article, I decided to give the Intel compiler a go. However, one stumbling block I've come across is that it doesn't seem to have a visual debugger. That is, idb is akin to gdb. I'm interested in something like gvd or ddd.
Does anyone know of a way to do visual debugging on the Intel compiler's code? (thoughts which come to mind: maybe the Eclipse environment? Maybe a gcc debugger, like gvd, would work on icc's code? Maybe there's another Intel product for visual debugging?)
If you read the article, it's pretty clear that they're talking about how much you pay above-and-beyond the regular electric bill. It used to be 2.5 cents above. Now it's a bargain at only 1 cent above. What you get for your money is the knowledge that you're using renewable energy.
After all, what's been happening since the early 20th century is that the copyright term keeps getting extended, as soon as the previous extension gets close to expiring. Who's to say copyright terms haven't _already_ become infinite?
You're annoyed that Microsoft is "invading your space". To get back at them, you're talking about retreating from their space. Who do you think wins in that exchange?
Ultimately, the greatest threat to Microsoft is open source apps which run on both Windows and Linux/BSD/etc. It is those apps which make it easy/possible for people to ditch Windows.
Yes -- I think you've got it right. You want a language which _lets_ you define all your own primitives, but also a language which supplies you with a decent standard set. The STL is nice that way: templates _let_ you make all your own containers, like arrays, but at the same time, you're supplied with a standard set. Having the standard set isn't just a convenience (which it is, and that's important in its own right). It also means that you can quickly understand other peoples' code. And it also means there's likely to be alot of useful documentation (including not only the regular documentation, but also books, newsgroup postings, etc).
So, the fact that D's arrays are built in to the language is of relatively little importance. Just as good are C++'s standard vector, etc. It doesn't hurt C++ much (if at all) that vector isn't "built in" to the language. It is, really, in every important sense. Same goes for string, etc. All because C++ has _standard_ versions of these (in addition to having the language facilities to create your own versions, if you like).
Sure -- but if you want safeness, use vector(1024) instead. I know, there's no static initialization of vector. But I tend to use arrays in a specialized way -- only for their static initialization properties. I agree it's a hole in the language, though. D might allow stack-allocated arrays with bounds checking. If so, it has something on C++. Also, D would have something on C++ if its arrays could be statically initialized. I assume they can be...?
Yeah, not having source sucks! I don't mess with things unless I have the source (which is why I use Linux!)
OK -- that answers one of my questions -- there _is_ a gcc implementation. But not a standard one.
Well said! Yes -- C++ is a dangerous language. You need to understand it thoroughly. If you do, it's the best thing out there (IMHO, etc). If you don't, use something simpler and safer, like Java, or Visual Basic (now I'm just getting downright _mean_!)
O'Caml's claim to fame is that it's the "working man's" functional programming language -- a practical functional programming language. There's also Haskell, which is more loved among academics, and ML, which is the original of the ilk. They're a great family of languages! But they lack templates, which makes them not so interesting to me. The reason I'm excited about D is that it appears to be pretty much "functional C++" -- nirvana!
Right -- Boost isn't part of C++. On the other hand, at least in my mind, it's a sort of quasi-standard. It's (usually) well-designed, up to generally-acknowledged C++ best practices (being a peer-reviewed library). It has a permissive license. It's available on a wide range of platforms. It's well documented. Hence, my argument goes like this: if D has feature X, which C++ doesn't have built-in, but which is available in "native-alike" form in a Boost library (that is, if its Boost implementation is so nicely done that it "feels" like it's as good as a built-in C++ feature), then I don't think D has much, if anything, to boast about (on that particular score).
Indeed, to me, it's an indication of a well-designed language if it doesn't _need_ alot of built-in stuff -- the user is able to build their own primitives, in effect. That's power, to me. Especially when you combine that inherent language facility with a mature, broad, widely-used quasi-standard library like Boost.
About array-bounds checking:
Exactly what I was referring to. See above reasoning about the Boost library. So, if you're using a well-designed C++ implementation, then it's trivial to have runtime bounds checking in debug mode. True, it isn't built into the language. But I don't care too much about defining what's built-in vs. what isn't. The question is, what is the user experience with a not-too-badly-implemented version of C++? I would argue that in the end, that's all that really matters. I'm not saying the standards documents don't matter -- they do. But what matters more is this: what is the modern, best-practices C++ programming experience like today, vs. D?
Since D is brand-new, I'm guessing there's only one implementation. Hence, whatever's in that D implementation is "part of the D standard". D has it easy that way. C++ has a huge history, with several high-quality and independant implementations. Over time, best practices emerge from the gigantic C++ community, and eventually (hopefully) the best things find their way into the standard. So we should be comparing D best practices to C++ best practices, rather than comparing the D standard (which can change like the wind, and has -- e.g. the addition of templates) to the C++ standard (which takes years to turn over a cycle). Of course, that inertia is a C++ weakness. D has the potential to leapfrog C++ due to this factor. That's what excites me about D.
Thanks for filling me in on some of those D features I had questions on.
Oh, riiiight -- I'd forgotten that one, deep in the mists of time. OK, so D has this, and C++ has this, but not Java. RAII must mean the "deterministic constructor/destructor" paradigm, referred to earlier (i.e. you control exactly when destructors fire).As for macros: I find lots of uses for them, besides just conditional compilation (at syntactically-awkward moments). My only regret is that they aren't much more powerful in C++. The ideal would be something akin to Lisp -- where the macros generate code at runtime. OK, maybe too much to swallow for a "traditional" language like D (although I don't see why, necessarily...) But O'Caml's macros are quite nice. There's much that can be done with macros, in terms of making code less tedious. For example, look at just about any windowing API (e.g. wxWindows, aka wxWidgets). The fewer the number of keystrokes required to implement a piece of code, the better (given that clarity, etc., is maintained).
Anyway, I'm curious -- you sound like you know alot about D. Have you tried developing with it? I'd be interested to hear what you think of it, as it compares to whatever else you use. I'm tempted to delve into it -- try it out.
But the STL _is_ C++. It's not like the STL is this library hanging off of C++. It's considered to be an integral part of the language. Compiler writers are free to do optimizations based on the known behavior of the STL.
Hence, in all meaningful ways, C++ has the above-mentioned things. It's just pedantic to argue otherwise.
On the other hand, C does _not_ have them, in any meaningful sense (yes, you can write libraries which implement those things, but that's not the same as being part of the language, fully supported by the language's syntax).
Function literals This is excellent. Function literals would make C++ a much better language. The STL cries out for them. While Java doesn't have function literals, it has something pretty close -- anonymous nested classes. But C++ has nothing very close. The best you can do is something like the Boost lamba library, which while impressive, it quite horrible. This feature makes D pretty interesting to me.
I'd be interested to know what D has in terms of standard libraries -- something akin to the STL..?
Dynamic closures Not sure exactly what this is, but I imagine it makes D into a fully-functional language. Sounds great! It makes me even more interested.
Resizeable arrays Well, I don't think this claim stands up -- that C++ doesn't have resizeable arrays. After all, since D is a garbage-collected language, I'm guessing its arrays are on the heap, not the stack. C++ has resizeable heap arrays -- vector, etc.
Arrays of bits Again, I take issue with C++ not having these. Check out Boost::dynamic_bitset.
Built-in strings Once again -- no way. C++ certainly has built-in strings, in any meaningful sense of the word -- std::string.
Array slicing I'd be intersted to see an example of how D's array slicing compares to C++'s interator-based programming. I'm not sure what's being talked about here, exactly.
Array bounds checking There's really no meaningful way you can say C++ doesn't have array bounds checking. Come on! What C++ has, which might be much better than D, is switchable array bounds checking. You don't _have_ to check array bounds (e.g. for release builds), but it's trivial to add if you want it.
Associative arrays Wrong! C++ certainly has associative arrays. They're quite excellent. See std::map and std::multimap. And of course, you can build any special sort of associative array you want -- say, a hash.
This chart is completely biased against C++ -- quite unrealistic. Why not just stick to the _real_ benefits D has over C++, and not kick up alot of FUD? It only serves to make people like me (rightfully) skeptical.
Strong typedefs OK, fine -- typedefs aren't strong in C++. But if you want something to be strong, make it a class/struct/enum. Why do typedef's need to be strong? What's really being said here is that D lacks a "type alias", which is what a C++ typedef is -- just a shorthand for another type. Does D have that?
String switches Just syntactic sugar, although I admit it might be nice syntactic sugar.
Multiple Inheritance An unfortunate deficiency of D. I find multiple inheritance to be quite useful. But D can't have everything -- that's OK. If this were D's only deficiency, it wouldn't be fatal to me, especially because...
Interfaces ... interfaces get you _most_ of what's good about multiple inheritance. But not all.
Dynamic class loading This is a nice thing about Java. Too bad D doesn't have it (but hardly a fatal problem, for me).
Inner classes Seems like D's functional programming capabilities trump the lack of inner classes...
Covariant return types Ummm -- what are these? C++ has them, so I must know what they are....
Properties Syntactic sugar...?
Inline assembler
Direct access to hardware
Direct native code gen Excellent. However, one reason I really like C++ is that there are toolchains for a huge variety of hardware. If there were a gcc front-end for D, that would go a long way to addressing this issue...
Lightweight objects Meaning, stack-allocated objects?
Explicit memory allocation control Does this mean D has _real_ destructors (unlike Java's pseudo-d
There's nothing wrong with them, except that I didn't know about them... :-)
/. D didn't have them. In quickly reading the article, I missed any mention of templates, although going back, I see they were mentioned in passing.
Templates are something new for D -- last time it came up on
Thanks for pointing that out.
I would argue the existence of a preprocessor is not archaic (although I would grant you that C/C++'s preprocessor is archaic).
Preprocessors allow you to deal with a great range of unanticipated situations -- allowing you to come up with creative solutions to sticky problems. Granted, they can be abused. So what? Don't abuse them.
The biggest thing I don't like about Java, now that it has templates, is that it's missing a (standard) preprocessor.
D has 2 strikes against it: first, no templates. Without templates, it's horribly inconvenient to write safe (i.e. strongly-typed) code. Second, it has no (standard) preprocessor.
In theory, this sounds like a nice enough idea. But in practice, I think many speed limits are absurdly low, and are (rightly) routinely ignored.
If a system like this were to be implemented, and not cause mass grousing by normal drivers, then it would be necessary to couple it with a program to determine what the "in practice" speed limits are, and change the speed limits accordingly.
In other words, if the goal is to affect just the 10% of really-bad speeders, then that's fine. But if you affect a much greater % than that, the program won't be sustainable! (and rightly so!)
I'm sure there would never _be_ an effort to reform speed limits to reflect on-the-ground reality. Therefore, I think the program's a bad idea -- something I'll be grousing about if it's ever implemented around here.
Linux has a much better answer to the problem of excessive choice than Windows does. Look for example at the KnoppMyth project. Its aim is to produce a live CD which gives you a PVR. That's incredibly powerful! In principle, all a user needs is this CD, plug it into their PC (assuming it has the necessary hardware), and PRESTO! All the complex stuff has been figured out by someone else, and the user has a simple interface to accomplish exactly what it is they want - to record/playback their television shows.
I imagine this special-purpose live-CD phenomenon will prove to be very powerful, and will be an important channel through which Linux will eventually eclipse Windows.
I think the main problem with the patent system is that the "non-obvious" standard is mostly ignored by patent examiners. The standard for a novel idea is supposed to be something like "non-obvious to someone skilled in the field".
I mean, PLEASE!!! Applying well-known user-interface techniques from other domains to a new domain (mp3 player)??? That isn't obvious to one skilled in the field?
I hate the patent system. And yes, I have applied for/received a patent -- but it takes alot of time & money. I can't possibly afford to patent every stinking idea at the level of those being applied for by Apple. In effect, the patent system is being used as a mechanism for established companies (with cash flow) to lock out small players. A horribly anti-competitive system!
Interesting reading - thanks!
A couple of thoughts:
First, "Rome" didn't really get shattered, as you're saying. The Roman empire divided into 2 halves. The Western half did gradually succumb to barbarian tribes -- in the 400's or so. The Eastern half, with its capital in Constantinople, lasted much longer. I can't remember when the Turks finally took them down -- I think around the 1200's.
So what was your point about Rome? The Western Romans succumbed to barbarians tribes, but not the Eastern Romans. Was it because the Easterners were "nicer"? I hardly think so. There are reasons -- lots of them -- but they're more subtle than the "popular image" of the ever-more-profligate, self-indulgent, even insane (due to lead in glass, etc) Romans finally getting their just desserts!
config db that uses permissions so one program can't overwrite another's data without proper access
is something which Linux currently offers (you need to set up the permissions yourself to achieve whatever goal you're after), but which Windows doesn't, exactly because of its registry.
There are plenty of other reasons to prefer to use the regular filesystem for program settings, rather than a registry.
For example, (good, modern) filesystems are instrial-strength, designed to survive dirty shutdowns, etc. By contrast, a registry is prone to getting corrupted.
Futhermore, if your settintg are in a regular filesystem, you can access them with regular programs (e.g. grep -R pattern
Yet another reason: if the settings are in the regular filesystem, then they can be easily changed remotely. E.g. you can ssh to the machine, then vi
In a similar vein, suppose your GUI frontend (e.g. your X server) won't work. If your settings are all in regular files, editable by regular programs, then there's no problem -- just boot into text mode, and find/fix your problems using textmode programs (find, grep, vi, etc). If your settings are in a registry, then you won't be able to use your regular GUI registry-editing program. If you're lucky, you'll have some even-more-primitive textmode program you can fall back on. If you're unlucky, you're hosed -- you get to re-install your OS!
The reverse is true: IE hasn't improved much in functionality over the past 2-3 years. Meanwhile, Mozilla, which was re-written from scratch to be easily expandable, has bounded well ahead of IE. I'm thinking of things like tabbed browsing, popup block, junk filtering, XUL. Perhaps IE would benefit from being written re-engineered from the ground up...?
In true /. fashion, I haven't read the original article -- just all the +5 point-counterpoint responses.
The basic problem is that 3 yrs ago, the county made a bad decision -- letting this guy create/manage their website, seemingly without oversight. As time went on, they naturally became more locked in. Now, they're completely locked in to this guy. Anything the guy asks for could be seen as extortion (in the county's eyes).
The basic problem, it seems to me, is that the county should have applied greater oversight, and ensured at all times that the website designer guy wasn't required for the continued operation of the site. They should never have become so dependant on this one guy.
Which brings me to Microsoft... (need I spell it out?)
The power wouldn't be so bad. The computers wouldn't have monitors, and the disks would be kept spun down most of the time. I suppose each might draw 100W, or 1000W for the whole thing.
It would take quite a bit of space, though!