OK, let me put this simply first: all numerical analysis is inexact, and for many real world numerical analysis tasks, performance and/or portability are more important than being slightly less inexact.
To address the four specific issues I raised previously:
The recent Intel chips don't provide anything like the same level of support for 80-bit as for 64-bit floating point. Sure, the x87 stack registers are 80-bit and there are corresponding opcodes to manipulate them, but once you're into the extended instruction sets it's 64-bit (or other powers of 2) all the way. Incidentally, does the D compiler take full advantage of these wider instruction sets?
You're missing the point with matrices, perhaps because you seem to be thinking in terms of small matrices while for many of us the problem cases can easily be 1,000x1,000 or more. Of course we use algorithms to minimise the errors introduced, but at this scale you are always going to have a significant degree of error. The problem cases tend to be near-singular systems, and it's often better to diagnose this and then adapt your data or process it in a different way to avoid running into the singularity, rather than hoping in vain that the numbers will come good with just an extra n bits of precision.
No, x86 isn't portable enough. I write libraries that ship on just about every major desktop OS in use today, from MS Windows to Linux to Solaris to HP-UX to MacOS to... In fact, we'll support just about any platform our customers ask us to, if we can. You can infer from that that we have active customers wanting to use all of those platforms, which in turn tells you that people in our industry don't just use x86 boxes for numerical analysis. 90% of computer users don't matter to me, but our customers do.
Your example is silly. Most serious numerical analysis work cannot hope to compute results to full precision, and therefore need algorithms that perform error analysis to determine the degree to which your results are reliable. Such analysis would immediately reveal the unreliability of the results in your anecdote, even if it weren't blindingly obvious to anyone who'd sat through the first half-hour of a numerical analysis lecture course. In any case, it's rather disingenuous to take dropping all but 2 sig figs vs. all but 10 (or all but 2 decimal places, though that is a bizarre measure of accuracy in this context) and pretend it's the same kind of problem as dropping all but 15 sig figs vs. all but 19, particularly when answers are typically not required to anything like these accuracies for most industrial applications.
Now, to answer your question, as a mechanical engineer designing systems that many lives and millions of dollars were flying on, I didn't give a f*** about portability. I wanted the RIGHT answer. The right answer is much easier to get when there's more precision. I want to use the FULL precision the FPU I'm using can deliver. I'm not using some other crappy FPU, why should my results get compromised by its mere existence? Now, if your customers consider portable wrong answers to be more desirable than correct answers on the machines the customer has, then I sure hope they aren't designing airplane parts.
That's a great example. Assuming your typical aircraft engine is ~10m across, the resolution our customers use would give a guaranteed accuracy of ~100nm. Tell me, did you design your parts to more precision than that?
And actually, since I currently work in CAD, it's quite likely that the people ultimately using our maths do design critical things like aircraft parts. Fortunately, since our code places a great emphasis on portable results and on quantifying errors rather than hoping for the best, the parts they design on one system do tend to fit together with the parts they design on another, the whole lot tends to work as designed, and your chances of falling out of the sky aren't too bad.:-)
All these on-the-fly kind of features, for example anonymous inner classes in Java, are enemies of good programming practice.
I'm sure everyone in the functional programming community would agree with you. They do, after all, have terrible problems with program conciseness and high bug counts relative to languages like C++ and D.;-)
If there is no ordering relationship between two instances of an object, you can override opEquals and opCmp to throw an exception.
So the only way to represent the concept of a class with an ordering but no equality is to have a run-time failure every time someone tries to compare them for equality?
All the data members (including the vptr) to a class are initialized before the constructor is called.
So any members whose values are set in the constructor will always be modified twice during construction?
I hope I'm misunderstanding you, because both of those are serious weaknesses in a systems programming language, and serious steps backwards from C++.
With the characters saved by removing redundancy, I've even managed to give the type a meaningful name, instead of using the "abbreviations just obscure enough that everyone has to look up exactly how to spell them every time" technique.:-)
Perhaps accidentally, you've just hit on one feature of programming language designs that I think does justify a new compiler front-end: ease of parsing for use with tools. Parsing the current monsters like C++ and Perl is so awkward and error-prone that few tools even get simple things like syntax highlighting 100% right (and the performance of those that do is... less than stellar). I imagine most of us are more interested in the underlying semantics of programming languages than in the specific syntax anyway, so can't we use a grammar that is easy to parse effectively, and then have tools from syntax highlighters to source code navigation to refactoring working quickly and reliably for a change?
OK, I'm quite willing to be proved wrong here (not least because that would mean that D is a better language IMHO) but I'm going by the way I read the pages of your own web site.
There are two comparison operators to overload, opEquals and opCmp. That's how you do it.
I could understand defining the < and == operators and then inferring the rest, but your opCmp appears to be a <=> concept, indicating less than, equal to or greater than. In that case, if a type supports only strict inequalities but not the concept of equality, how can you implement it as a combination of those operators? If neither a < b nor b < a nor a == b, then how does one represent this?
I'm also curious about how you suppress the implicit equality test for structures, if the contents are not logically equality-comparable according to the program design. Is this any neater than the nasty C++ idioms for suppressing compiler-supplied constructors and assignment operators?
You can declare a class as being a scope class... and it will automatically and always be RAII.
Your own web site's RAII example seems to use the scope keyword twice, once for the class definition and once where it is instantiated. If you can't accidentally write something like the following:
File f = new File();
in D, then I suggest that it would be in your interests to rewrite your explanatory text a little to make this clear.
It also isn't possible to call a member function without the vptr being set up, so the alleged horrible loophole doesn't exist.
So can one constructor call another before initialising all the data members of a class to satisfy the class's invariant conditions, or can't it? If it can, how does any constructor know what's been initialised already and what hasn't when it's called? If it can't, what's the advantage of chaining constructors together like this?
I'm afraid the fact that you don't do this stuff for a living is painfully apparent here, Walter, though it does explain your belief in the value of the feature in D. Consider the following questions, if you will:
On IA-32 machines, what instructions and register support are available for 32-bit floating point computations? 64-bit? 80-bit? Don't forget to include all the extended instruction sets and registers in the more recent processor series.
What issues of non-convergence in numerical integration go away at 80-bit but get in the way at 64-bit?
How many mainstream processor lines currently available do and don't support 80-bit calculation to acceptable performance?
Which do you think customers typically consider more important, an extra couple of binary places of accuracy (when you're already correct to several orders of magnitude more than their working resolution anyway) or results that are as close to identical as possible across all hardware platforms?
When you have established the correct answers to the above, perhaps you will understand why 80-bit has little value to most of us in today's environment.
Re:Smoking bans: reducing freedom, or increasing i
on
2006's Bill of Wrongs
·
· Score: 1
I personally happen to dislike that approach. As a matter of principle, I think if something is bad, it should be made illegal in an open and transparent fashion. Taxes are not there to support social engineering, though they are frequently abused for this purpose by many governments. Taxing something bad rather than banning it simply discriminates against those less well off people who can no longer afford the same privileges as the better off.
Re:Smoking bans: reducing freedom, or increasing i
on
2006's Bill of Wrongs
·
· Score: 1
You presuppose the existence of such establishments, and in sufficient numbers and with sufficient access to be helpful. If history showed that businesses (even those in essential areas like groceries and transportation) catered reasonably to minority markets like this, the world wouldn't be full of anti-discrimination legislation to protect for disabled people many basics that you or I take for granted. Sadly, this isn't the case, so to protect the vulnerable to state imposes certain restrictions on businesses.
I'm not an expert on these, but if you clarify which bit you're interested in I'll attempt to provide references. (If you've never encountered the functional programming world at all before, a head explosion awaits you, and you're about to question everything you ever thought you knew about programming.:-))
Where C, C++ and D win out over Java in terms of performance is when you need programs that have to start up fast, run fast, but only for short periods (a few seconds).
Or where you're doing serious, high-performance maths and not just running simple benchmarks. For most apps, any differences here are such a small proportion of the total run-time that it's irrelevant if Java is slower in this area. But for heavyweight modelling applications, I'm afraid Java's not really in the game; those little limitations/performance penalties for safety just multiply up too fast.
Um, considering that the vast majority of the world's floating-point hardware is x86 and supports extended precision, saying that it lacks "true support from almost every mainstream architecture" is comical.
Not really. Take a look at the performance, addressing modes, and so on. The support for 80-bit on Intel boxes is not the same as the support for 64-bit, at least in practical terms.
Also, while the vast majority of the world's FP hardware may indeed run on x86 (I don't know), I would suggest that at least a very significant minority of the software that actually requires high-precision floating point work still runs on workstations which may well be based on other architectures.
No-one wishes this were not so more than me, I promise you: I write high-performance, high-precision mathematical libraries for a living, and minor differences in behaviour across platforms or where precision has been lost are the bane of my working life.
Re:Smoking bans == infringement on property rights
on
2006's Bill of Wrongs
·
· Score: 1
Thanks.:-)
Of course it's not as black-and-white as my sig suggests, but with only a handful of characters, it was the closest I could get to what I really wanted to say. The statement is intended to criticise the power of the state as some sort of autonomous entity in conflict with its citizens, not the power of the state to be a faithful and representative voice of the people.
Re:Smoking bans: reducing freedom, or increasing i
on
2006's Bill of Wrongs
·
· Score: 1
So you agree that the free market won't do something that is against a first-mover's short term interests, then ask whether people are stupid and fail to take advantage of long-term opportunities? I think you just answered your own question. Businesses are short-sighted, often caring about little more than hitting the figures in time for the next shareholder report or executive bonus cycle. As long as they're beating their competitors, they look good, even if they could look better if they all collectively changed their practices at the same time.
Re:Smoking bans: reducing freedom, or increasing i
on
2006's Bill of Wrongs
·
· Score: 1
Would you make the same argument about disabled people? Do you object to the government requiring that certain basic provision be made to allow people with disabilities to use essential services?
Ironically, I consider most of the C++ to D examples there to be flaws in D.
Supplying predefined comparison operators is all very well, but what if a class doesn't support the concept of equality? Alternatively, suppose it supports only equality and not ordering, or vice versa? How do I do that in a natural way, with a single comparison function to define?
The whole concept of relying on scoped variables completely misses a major advantage of RAII, which is that in the common usage, you can't forget anything (a delete, finally or in this case scope) and inadvertently skip the destructor. Requiring some special keywords to get this behaviour is just horrible.
The construction/initialisation semantics just seem a mess. You've either introduced some hideous inefficiency and semantic problems (everything is default-initialised and then reassigned afterwards in the constructor if necessary) or you've introduced a horrible loophole (constructors can start messing around with uninitialised data, for example by calling another member function, before the class invariants are properly set up). The latter is even worse than the analogous loophole in C++.
This sort of thing is exactly my big beef with D, and the reason I doubt I will ever seriously consider it for a non-trivial project in its current form. It's going for style over substance, PR hype over effectiveness. It does away with a few controversial things in C++, but some of its underlying models are simply broken, and as I illustrated elsewhere, its improvements in other areas are far from state-of-the-art.
Re:Smoking bans == infringement on property rights
on
2006's Bill of Wrongs
·
· Score: 1
Mandatory anything from the state is only to be supported when there is a very good reason, IMHO. However, I think this is one of those cases where it may actually be justified. Most people need some sort of health care at some stage in their lives, and experience with this and other related areas (pensions being an obvious one) suggests that most people are not sufficiently careful or capable in their finances to provide for times of need, and will ultimately need bailing out.
That means an effectively insurance-based system is a practical necessity with some degree of compulsion is a practical necessity. At that point, you can either suffer a state-operated monopoly (good with good management accountability, bad otherwise) or a commercial marketplace (where everyone necessarily gives some money to profit-making entities on top of what would be necessary simply to buy the insurance at cost). Neither is a great plan, but one has a fighting chance of working out if it's well set up, so I think there's a case to be made even if it's far from rock-solid.
Sorry about the "Get over it" line. I usually reserve that for people who aren't bothering to think about the discussion, and got confused about who I was replying to while looking at several posts at once. (I stand by the claim that businesses have no inherent rights, however.)
Regarding the motor vehicles analogy, my objection is not that they aren't damaging -- clearly they are, and I don't dispute this for an instant -- but rather that the up-side to using motor vehicles is vastly different to the up-side for allowing smoking in public. I don't think it's fair to compare the downsides of two hazardous activities without consideration of the benefits achieved in return.
garbage collection... No virtual machine... How do they square that particular circle?
The same way as countless other programming languages have in the past, I imagine. Why do you think garbage collection requires running your code under a VM?
Just In Time Compilation in C# or Java has "Native code speed", in fact it goes one better - since the compilation happens at a later time, more processor or other specific optimisations can be made.
Of course, you're overlooking all the overhead of monitoring the code long enough to determine which on-the-fly optimisations are worth performing, and of compiling the code itself, neither of which is trivial.
GC has a lot to do with the perceived slowness.
True, though of course it's not without overheads. Almost all of the Big Claims(TM) made by GC advocates in these discussions come with a catch: state-of-the-art GC method number 17 has a lower amortised cost of memory recovery than explicitly freeing it C-style!*
* But only if your system contains 10x as much memory as the program will ever need anyway.
This is traditionally followed by a wisecrack about how memory is cheap, followed by three enlightened posters pointing out the stupidity of that argument for multiple reasons.:-)
Isn't it disingenuous to tout both "native code speed" and "garbage collection"?
That depends a lot on context. If you really have a system where the overheads of GC are trivial but all the advantages are present, it seems a fair claim. It's just not likely to be universally true, and representing it as such would indeed be disingenuous.
I'm sure D is a lovely language, but it just seems like another incremental change over C++, like Java and C# before it, and like both of those languages what it's lost and the opportunities it misses are as telling as the little tweaks it makes to improve things.
No-one has yet been successful, IMHO, in developing a really good industrial programming language. Those that make it tend to be pragmatic, practical tools like C and Perl and FORTRAN and COBOL. To be sure, each of these has many widely-acknowledged weaknesses, but the overall balance between those weaknesses and what you could get done using the language was right.
I can increasingly see why some well-known programming language designers shy away from feature comparison ticklists. I think it's because as soon as you go down this route, you bias the comparison so much that it's meaningless. For example, consider the first checklist cited in the Slashdot write-up. (I note in passing that this is a wiki, and may change before you read this.) Here are some of the "yes or no" (almost) categories:
Templates or executable macros
No difference in expressive power is acknowledged between LISP macros and C++ templates.
Thread synchronization primitives
With no reference to how expressive they are, and how powerful the idioms supported by them? This one is really telling, IMHO, because I don't believe the future lies in classical thread sync and locking primitives. The whole approach is just too prone to deadlocks and race conditions to withstand the heavily parallel future that multicore chips are starting to bring into the mainstream. When you have ideas like pure function programming languages, operating in a world without side-effects where explicit locking isn't necessary, or interesting ideas for inter-thread communication such as those in Erlang, another variation on built-in pthreads just isn't worth much.
Enumeration
So again, we acknowledge no difference between simple and low-level enumerations such as those in C, and concepts such as disjunctive types and pattern-matching that are very powerful, remarkably elegant, and mainstream in certain families of programming language. Again, this is just papering over a gap, where other languages operate on an entirely different level.
Long double floating point (80bit)
This is just desperation. Pretty much no-one uses 80-bit floating point arithmetic IME (and yes, I do work in the field). The portability hazards and lack of true support from almost every mainstream architecture make them almost irrelevant, except perhaps for a few very small niches.
Lexical Closures
Another telling omission: the power of all those neat functional programming features is dramatically reduced when you can't construct functions on-the-fly.
On top of all of this, the feature lists invariably gloss over some less concrete things that are nevertheless very important to systems programming languages. How portable is D? How many production-quality implementations are available? Is the language standardised or under the control of a single, commercial body? How much backing is there behind the language in the commercial development space; do others write libraries specifically for this language, or is it reduced to using C-style interfaces at the lowest levels anyway, and what impact does this have on the usefulness of features like DBC, exceptions, and so on? Does the language have an active hobbyist/volunteer community supporting it?
I could go on, but I don't want this post to disappear into the oblivion any more than it already will. Although I'm deliberately focussing on criticising in this post, as I often do with D, I keep an open mind and will happily engage in debate with others, or even be proved wrong by people who have found D to have compelling advantages. So go ahead, D advocates, start your counter-arguments here...
Re:Smoking bans: reducing freedom, or increasing i
on
2006's Bill of Wrongs
·
· Score: 1
Please read my other comments in this discussion. Those bars that are non-smoking are oversubscribed, but there is a strong economic incentive for the others not to move first, resulting in a stalemate, which this regulation conveniently breaks to the advantage of almost everyone.
Re:Smoking bans == infringement on property rights
on
2006's Bill of Wrongs
·
· Score: 1
You've lost the plot, Mr AC.
For one thing, you make the classic Slashdot mistake of assuming the US is the world. It's not, and to be frank, it's hardly the bastion of human rights in the world right now. Get back to us when you've closed down Gitmo, stopped the secretive government-funded mass surveillance programmes, acknowledged that extraordinary rendition results in torture, developed some accountability for your elected representatives, etc. etc. etc.
Your references to the Constitution are therefore pretty much irrelevant. In any case, the phrase "human rights" can mean several things: ethical, legal, effective.... In this context, I am talking about those rights recognised and protected by law. This isn't a consitutional issue, except where governments would otherwise infringe on those rights.
In this sense, I am aware of no country whose laws give people an absolute right to smoke, regardless of the consequences. Banning smoking, when this protects others, is not some fundamental infringement of the smokers' freedoms that should be struck down in law. This entire argument is just wishful thinking by the smoking brigade, or missing the point by the civil rights brigade.
Re:Smoking bans: reducing freedom, or increasing i
on
2006's Bill of Wrongs
·
· Score: 1
I can't speak for anywhere but the UK where I live, but here the entire industry, give or take a few small and independent operators, is unwilling to depart from status quo. There are sound economic reasons for this, which boil down to the first mover losing lots of money in the short term. The regulation imposed will allow the whole industry to do what most of them really want to do anyway, while conveniently providing a smokescreen so they can fend of the whinging few, and much faster and with much less risk than they could under market forces alone. Why do you think they all paid lip service to disliking the ban and how terribly it would affect them, yet went strangely silent in the run up to the parliamentary votes that meant anything?
Slashdot Mirror
OK, let me put this simply first: all numerical analysis is inexact, and for many real world numerical analysis tasks, performance and/or portability are more important than being slightly less inexact.
To address the four specific issues I raised previously:
That's a great example. Assuming your typical aircraft engine is ~10m across, the resolution our customers use would give a guaranteed accuracy of ~100nm. Tell me, did you design your parts to more precision than that?
And actually, since I currently work in CAD, it's quite likely that the people ultimately using our maths do design critical things like aircraft parts. Fortunately, since our code places a great emphasis on portable results and on quantifying errors rather than hoping for the best, the parts they design on one system do tend to fit together with the parts they design on another, the whole lot tends to work as designed, and your chances of falling out of the sky aren't too bad. :-)
I'm sure everyone in the functional programming community would agree with you. They do, after all, have terrible problems with program conciseness and high bug counts relative to languages like C++ and D. ;-)
So the only way to represent the concept of a class with an ordering but no equality is to have a run-time failure every time someone tries to compare them for equality?
So any members whose values are set in the constructor will always be modified twice during construction?
I hope I'm misunderstanding you, because both of those are serious weaknesses in a systems programming language, and serious steps backwards from C++.
Or even this:
With the characters saved by removing redundancy, I've even managed to give the type a meaningful name, instead of using the "abbreviations just obscure enough that everyone has to look up exactly how to spell them every time" technique. :-)
Ah yes, a computer that understands English. What a wonderful idea...
Perhaps accidentally, you've just hit on one feature of programming language designs that I think does justify a new compiler front-end: ease of parsing for use with tools. Parsing the current monsters like C++ and Perl is so awkward and error-prone that few tools even get simple things like syntax highlighting 100% right (and the performance of those that do is... less than stellar). I imagine most of us are more interested in the underlying semantics of programming languages than in the specific syntax anyway, so can't we use a grammar that is easy to parse effectively, and then have tools from syntax highlighters to source code navigation to refactoring working quickly and reliably for a change?
OK, I'm quite willing to be proved wrong here (not least because that would mean that D is a better language IMHO) but I'm going by the way I read the pages of your own web site.
I could understand defining the < and == operators and then inferring the rest, but your opCmp appears to be a <=> concept, indicating less than, equal to or greater than. In that case, if a type supports only strict inequalities but not the concept of equality, how can you implement it as a combination of those operators? If neither a < b nor b < a nor a == b, then how does one represent this?
I'm also curious about how you suppress the implicit equality test for structures, if the contents are not logically equality-comparable according to the program design. Is this any neater than the nasty C++ idioms for suppressing compiler-supplied constructors and assignment operators?
Your own web site's RAII example seems to use the scope keyword twice, once for the class definition and once where it is instantiated. If you can't accidentally write something like the following:
in D, then I suggest that it would be in your interests to rewrite your explanatory text a little to make this clear.
So can one constructor call another before initialising all the data members of a class to satisfy the class's invariant conditions, or can't it? If it can, how does any constructor know what's been initialised already and what hasn't when it's called? If it can't, what's the advantage of chaining constructors together like this?
I'm afraid the fact that you don't do this stuff for a living is painfully apparent here, Walter, though it does explain your belief in the value of the feature in D. Consider the following questions, if you will:
When you have established the correct answers to the above, perhaps you will understand why 80-bit has little value to most of us in today's environment.
I personally happen to dislike that approach. As a matter of principle, I think if something is bad, it should be made illegal in an open and transparent fashion. Taxes are not there to support social engineering, though they are frequently abused for this purpose by many governments. Taxing something bad rather than banning it simply discriminates against those less well off people who can no longer afford the same privileges as the better off.
You presuppose the existence of such establishments, and in sufficient numbers and with sufficient access to be helpful. If history showed that businesses (even those in essential areas like groceries and transportation) catered reasonably to minority markets like this, the world wouldn't be full of anti-discrimination legislation to protect for disabled people many basics that you or I take for granted. Sadly, this isn't the case, so to protect the vulnerable to state imposes certain restrictions on businesses.
I'm not an expert on these, but if you clarify which bit you're interested in I'll attempt to provide references. (If you've never encountered the functional programming world at all before, a head explosion awaits you, and you're about to question everything you ever thought you knew about programming. :-))
Or where you're doing serious, high-performance maths and not just running simple benchmarks. For most apps, any differences here are such a small proportion of the total run-time that it's irrelevant if Java is slower in this area. But for heavyweight modelling applications, I'm afraid Java's not really in the game; those little limitations/performance penalties for safety just multiply up too fast.
Not really. Take a look at the performance, addressing modes, and so on. The support for 80-bit on Intel boxes is not the same as the support for 64-bit, at least in practical terms.
Also, while the vast majority of the world's FP hardware may indeed run on x86 (I don't know), I would suggest that at least a very significant minority of the software that actually requires high-precision floating point work still runs on workstations which may well be based on other architectures.
No-one wishes this were not so more than me, I promise you: I write high-performance, high-precision mathematical libraries for a living, and minor differences in behaviour across platforms or where precision has been lost are the bane of my working life.
Thanks. :-)
Of course it's not as black-and-white as my sig suggests, but with only a handful of characters, it was the closest I could get to what I really wanted to say. The statement is intended to criticise the power of the state as some sort of autonomous entity in conflict with its citizens, not the power of the state to be a faithful and representative voice of the people.
So you agree that the free market won't do something that is against a first-mover's short term interests, then ask whether people are stupid and fail to take advantage of long-term opportunities? I think you just answered your own question. Businesses are short-sighted, often caring about little more than hitting the figures in time for the next shareholder report or executive bonus cycle. As long as they're beating their competitors, they look good, even if they could look better if they all collectively changed their practices at the same time.
Would you make the same argument about disabled people? Do you object to the government requiring that certain basic provision be made to allow people with disabilities to use essential services?
Ironically, I consider most of the C++ to D examples there to be flaws in D.
Supplying predefined comparison operators is all very well, but what if a class doesn't support the concept of equality? Alternatively, suppose it supports only equality and not ordering, or vice versa? How do I do that in a natural way, with a single comparison function to define?
The whole concept of relying on scoped variables completely misses a major advantage of RAII, which is that in the common usage, you can't forget anything (a delete, finally or in this case scope) and inadvertently skip the destructor. Requiring some special keywords to get this behaviour is just horrible.
The construction/initialisation semantics just seem a mess. You've either introduced some hideous inefficiency and semantic problems (everything is default-initialised and then reassigned afterwards in the constructor if necessary) or you've introduced a horrible loophole (constructors can start messing around with uninitialised data, for example by calling another member function, before the class invariants are properly set up). The latter is even worse than the analogous loophole in C++.
This sort of thing is exactly my big beef with D, and the reason I doubt I will ever seriously consider it for a non-trivial project in its current form. It's going for style over substance, PR hype over effectiveness. It does away with a few controversial things in C++, but some of its underlying models are simply broken, and as I illustrated elsewhere, its improvements in other areas are far from state-of-the-art.
Sorry, someone's already been there and done that. :-)
Mandatory anything from the state is only to be supported when there is a very good reason, IMHO. However, I think this is one of those cases where it may actually be justified. Most people need some sort of health care at some stage in their lives, and experience with this and other related areas (pensions being an obvious one) suggests that most people are not sufficiently careful or capable in their finances to provide for times of need, and will ultimately need bailing out.
That means an effectively insurance-based system is a practical necessity with some degree of compulsion is a practical necessity. At that point, you can either suffer a state-operated monopoly (good with good management accountability, bad otherwise) or a commercial marketplace (where everyone necessarily gives some money to profit-making entities on top of what would be necessary simply to buy the insurance at cost). Neither is a great plan, but one has a fighting chance of working out if it's well set up, so I think there's a case to be made even if it's far from rock-solid.
Sorry about the "Get over it" line. I usually reserve that for people who aren't bothering to think about the discussion, and got confused about who I was replying to while looking at several posts at once. (I stand by the claim that businesses have no inherent rights, however.)
Regarding the motor vehicles analogy, my objection is not that they aren't damaging -- clearly they are, and I don't dispute this for an instant -- but rather that the up-side to using motor vehicles is vastly different to the up-side for allowing smoking in public. I don't think it's fair to compare the downsides of two hazardous activities without consideration of the benefits achieved in return.
The same way as countless other programming languages have in the past, I imagine. Why do you think garbage collection requires running your code under a VM?
Of course, you're overlooking all the overhead of monitoring the code long enough to determine which on-the-fly optimisations are worth performing, and of compiling the code itself, neither of which is trivial.
True, though of course it's not without overheads. Almost all of the Big Claims(TM) made by GC advocates in these discussions come with a catch: state-of-the-art GC method number 17 has a lower amortised cost of memory recovery than explicitly freeing it C-style!*
* But only if your system contains 10x as much memory as the program will ever need anyway.
This is traditionally followed by a wisecrack about how memory is cheap, followed by three enlightened posters pointing out the stupidity of that argument for multiple reasons. :-)
That depends a lot on context. If you really have a system where the overheads of GC are trivial but all the advantages are present, it seems a fair claim. It's just not likely to be universally true, and representing it as such would indeed be disingenuous.
I'm sure D is a lovely language, but it just seems like another incremental change over C++, like Java and C# before it, and like both of those languages what it's lost and the opportunities it misses are as telling as the little tweaks it makes to improve things.
No-one has yet been successful, IMHO, in developing a really good industrial programming language. Those that make it tend to be pragmatic, practical tools like C and Perl and FORTRAN and COBOL. To be sure, each of these has many widely-acknowledged weaknesses, but the overall balance between those weaknesses and what you could get done using the language was right.
I can increasingly see why some well-known programming language designers shy away from feature comparison ticklists. I think it's because as soon as you go down this route, you bias the comparison so much that it's meaningless. For example, consider the first checklist cited in the Slashdot write-up. (I note in passing that this is a wiki, and may change before you read this.) Here are some of the "yes or no" (almost) categories:
Templates or executable macros No difference in expressive power is acknowledged between LISP macros and C++ templates. Thread synchronization primitives With no reference to how expressive they are, and how powerful the idioms supported by them? This one is really telling, IMHO, because I don't believe the future lies in classical thread sync and locking primitives. The whole approach is just too prone to deadlocks and race conditions to withstand the heavily parallel future that multicore chips are starting to bring into the mainstream. When you have ideas like pure function programming languages, operating in a world without side-effects where explicit locking isn't necessary, or interesting ideas for inter-thread communication such as those in Erlang, another variation on built-in pthreads just isn't worth much. Enumeration So again, we acknowledge no difference between simple and low-level enumerations such as those in C, and concepts such as disjunctive types and pattern-matching that are very powerful, remarkably elegant, and mainstream in certain families of programming language. Again, this is just papering over a gap, where other languages operate on an entirely different level. Long double floating point (80bit) This is just desperation. Pretty much no-one uses 80-bit floating point arithmetic IME (and yes, I do work in the field). The portability hazards and lack of true support from almost every mainstream architecture make them almost irrelevant, except perhaps for a few very small niches. Lexical Closures Another telling omission: the power of all those neat functional programming features is dramatically reduced when you can't construct functions on-the-fly.On top of all of this, the feature lists invariably gloss over some less concrete things that are nevertheless very important to systems programming languages. How portable is D? How many production-quality implementations are available? Is the language standardised or under the control of a single, commercial body? How much backing is there behind the language in the commercial development space; do others write libraries specifically for this language, or is it reduced to using C-style interfaces at the lowest levels anyway, and what impact does this have on the usefulness of features like DBC, exceptions, and so on? Does the language have an active hobbyist/volunteer community supporting it?
I could go on, but I don't want this post to disappear into the oblivion any more than it already will. Although I'm deliberately focussing on criticising in this post, as I often do with D, I keep an open mind and will happily engage in debate with others, or even be proved wrong by people who have found D to have compelling advantages. So go ahead, D advocates, start your counter-arguments here...
Please read my other comments in this discussion. Those bars that are non-smoking are oversubscribed, but there is a strong economic incentive for the others not to move first, resulting in a stalemate, which this regulation conveniently breaks to the advantage of almost everyone.
You've lost the plot, Mr AC.
For one thing, you make the classic Slashdot mistake of assuming the US is the world. It's not, and to be frank, it's hardly the bastion of human rights in the world right now. Get back to us when you've closed down Gitmo, stopped the secretive government-funded mass surveillance programmes, acknowledged that extraordinary rendition results in torture, developed some accountability for your elected representatives, etc. etc. etc.
Your references to the Constitution are therefore pretty much irrelevant. In any case, the phrase "human rights" can mean several things: ethical, legal, effective.... In this context, I am talking about those rights recognised and protected by law. This isn't a consitutional issue, except where governments would otherwise infringe on those rights.
In this sense, I am aware of no country whose laws give people an absolute right to smoke, regardless of the consequences. Banning smoking, when this protects others, is not some fundamental infringement of the smokers' freedoms that should be struck down in law. This entire argument is just wishful thinking by the smoking brigade, or missing the point by the civil rights brigade.
I can't speak for anywhere but the UK where I live, but here the entire industry, give or take a few small and independent operators, is unwilling to depart from status quo. There are sound economic reasons for this, which boil down to the first mover losing lots of money in the short term. The regulation imposed will allow the whole industry to do what most of them really want to do anyway, while conveniently providing a smokescreen so they can fend of the whinging few, and much faster and with much less risk than they could under market forces alone. Why do you think they all paid lip service to disliking the ban and how terribly it would affect them, yet went strangely silent in the run up to the parliamentary votes that meant anything?