How do you get an intellisense-like feature with (X)Emacs?
For me, a good intellisenseish feature in IDE A will cause me to use it over IDE B (without such a feature) in a heartbeat *no matter what* other feature IDE B has. I don't care if it runs like a dream, has the best debugger in the world, or whatever. If A has intellisense and B doesn't, about the only feature B could add that would make me switch is a telepathic "I'll write your code for you" feature.
Yes, because GOD KNOWS that if you type a standards compliant program into VC++, it won't compile.
(Okay, I know that it's not actually fully compliant. For instance, until 7.1, there was no support for partial template specialization. However, there is, to my knowledge, one fully compliant compiler+library implementation, and VC++ is as good as most now.)
But what the parent is saying (and which is a very legit argument if you ask me) is that if you're looking for a Debian repository, you're almost certainly not going to find a fake file!
If you want to be sure, you can compare the file size to the official one. If it matches, you can be all but completely confidant that it's real.
After all, there are probably far fewer people trying to flood P2P with bogus files just for the hell of it then there are trying to flood P2P with bogus files in an attempt to protect copyright.
The OED has a citation dating even before that, 1668. It's not a precise match, because they are called "land pirates", but:
"J. HANCOCK Brooks' String of Pearls (Notice at end), Some dishonest Booksellers, called Land-Pirats, who make it their practise to steal Impressions of other mens Copies."
Ignoring the fact that it doesn't need a Qt-ish solution, it does need ported. If Qt would have been an appropriate platform to write it in from the beginning, it would probably be an appropriate platform to port it to. Even if porting to a native toolkit would be a bit easier, in the long run %FAVORITE_CROSS_PLATFORM_TOOLKIT% (like Qt) would probably be a better choice. That way, future versions don't need to be ported or cross-developed.
When we just got over an attorney general who covered up the breasts of the Spirit of Justice, have congresscritters going after GTA and now The Sims 2, and where parents are separated from their baby for 6 mths because dad took a picture of him kissing the kid's chest after a bath, do you really think that the government WILL distinguish?
In retrospect I think that experiment I did sheds no light on it. I think I just made the traditional "heavy objects fall faster" mistake, just shifted so that "heavy" was "less bouyant" and "fall" was "sink." At the time I was thinking that would make a difference, but falling is really just sinking through air, so I don't think it actually would.
AOL CDs would work, but you'd need a lot of them. CDs sink, but not very fast. It took a couple seconds from being inserted into a tub of water for my experimental CD to drop a couple inches to the bottom.
On the other hand, while I don't have any to try, I have a strong feeling that the SCO lawsuits would float. Actually, I suspect they would not just float out of the pond/lake/etc. but also up into the upper atmosphere because of the quantity of hot air contained within.
Beyond that, as Graham points out, there are few patterns in well-written Lisp code. If a Lisp programmer finds himself repeating the same pattern of code over and over, he'll just write a macro to codify the pattern.
First, duplicated code != a design pattern.
Second, what can a Lisp macro do that, say, a C macro or a function can't? (I ask merely for information, I'm not challenging you.)
I must admit that I have never programmed in Lisp (my functional languages experience is limited to ML), but I would bet a substantial sum that there are at least a few idioms in Lisp that could be considered analogous to the OO design patterns that an OO language makes invisible.
11. Go to prison for perjury if they figure it out. Not to mention pay MS for the copy of Windows and possibly the cost of any investigation they did as a result of your statement.
That counterfeit report you have to fill out? Probably you need to endorse it under penalty of perjury.
The exception to this would be if Compaq didn't fulfill any responsibilities regarding registration of the copies of Windows they distributed.
If, for instance, for each computer they ship they have to tell MS "yeah, this copy of Windows actually got shipped out to a customer" and they didn't and that's why Windows Update doesn't like it, Compaq would almost certainly be at fault. Or, worst case scenario (for Compaq) if they distributed unlicensed copies themselves.
Still, if you were going to sue someone probably MS would be the guys; let them worry about joining Compaq as a third-party defendant.
Yeah, but there's a difference between "there's a risk" and "there's possibly a serious enough risk we're regrounding the shuttles."
I doubt the astronauts are losing much sleep over it, but the grandparent is right, NASA probably could have had a little more tact and announce the grounding once Discovery (presubably) safely returns. It's not like it's a time-critical announcement.
It wouldn't have caused anyone any problems probably, and might have eased the minds of a few. "Can't hurt, might help."
Depends on how strict you are with the word "disproving". Because fact is, Newton and Einstien never (or at least almost never) agree. And when they disagree, our current understanding of physics says that Einstien is right, or at least closer. So in that sense, Eintstien did disprove Newton.
On the other hand, in most situations the discrepancy between what Newton and Einstien say is so absurdly small that you could easily argue that me saying they differ is me being extremely pedantic, and in that sense he didn't disprove Newton in those situations.
Second, the AC that also responded to you is right. Newton is never 100% right. However, with the speeds, forces, etc. we experience on a regular basis, Newton is so absurdly close to being correct that it works just as well as Einstien, and the errors that simplification introduces are more or nothing compared to measurement errors.
It's not just a matter of not measuring them because of a lack of trailer parks, it is reasonable to conclude from this research originally from The Annals of Improbable Research that the lack of trailer parks actually reduces the occurances of tornadoes.
Many of the other variables mentioned as possible influences on the frequency of tornadoes, such as camcorder sales, are also substantially lower or in fact zero on Mars.
On the other hand, if they put every cool feature in the language, it'd be huge. There has to be a very compelling reason for a language change, simply because of the burden it places on compiler writers. Just because they are making a revision to the standard doesn't mean that the language will face huge changes; by contrast, probably the changes will be relatively small.
This is a lot simpler than what might arise in practice, but the following code when compiled with gcc and -O2 on Solaris seems to produce about as optimal code as I think you could hope for in a high-level language in which the call to foo wasn't inlined:
struct Pair { public:
int a_, b_;
Pair(int a, int b) : a_(a), b_(b) {} };
int main() {
int x, y;
Tie(x,y) = foo();
std::cout << x << " " << y; }
Keep in mind that everything above foo() would sit in a header file somewhere, so you wouldn't have to worry about it.
Granted, the syntax could possibly be made nicer, perhaps by doing something like using a notation for a pair, but you have to ask if the increased "prettyness" of the source really justifies that.
I'm not so much trying to say that the addition is a bad idea, or not cool, or wouldn't lead to better code; I'm just trying to show why there's little chance it would happen.
...when it would be much more elegant (and likely less buggy) as a language feature?
Changing the language is more difficult than adding a library because the compiler must be modified, which is a daunting task.
The trick is to find a way to do it safely without any (or with very little) extra overhead. I'm trying to come up with an idea, but I don't have anything yet. If I think of something, I'll reply again. However, I'm reasonably confidant that there's a way to do it with no extra overhead (at least with any moderately decent optimizing compiler), I can feel it, I just don't know how yet.
The template system is still not a generics system, but an ugly cut & paste macro system which can incidentally be used for generics, with some caveats....and which is a couple of orders of magnitude more powerful than a simple generics system.
"C++0x". Were they specifically trying to come up with a name less convenient than "C#"? Ah well, I guess we can call it "COX" or "cocks" for short.
No, they're following a couple (at least) decade old convention. Standards are described by the standard name followed by the year.
C87 is the C language as standardized in 1987. (Or whatever year it was.) C99 is the C language as standardized in 1999. The full name of the current C++ standard is C++97, because it was standardized in 1997. C++0x refers to the next version of the C++ standard. Only it doesn't have a full name, like C++08, because we have yet to invent a device that will see into the future to find out when the standardization actually occurs. Thus we need a placeholder.
Slashdot Mirror
How do you get an intellisense-like feature with (X)Emacs?
For me, a good intellisenseish feature in IDE A will cause me to use it over IDE B (without such a feature) in a heartbeat *no matter what* other feature IDE B has. I don't care if it runs like a dream, has the best debugger in the world, or whatever. If A has intellisense and B doesn't, about the only feature B could add that would make me switch is a telepathic "I'll write your code for you" feature.
Yes, because GOD KNOWS that if you type a standards compliant program into VC++, it won't compile.
(Okay, I know that it's not actually fully compliant. For instance, until 7.1, there was no support for partial template specialization. However, there is, to my knowledge, one fully compliant compiler+library implementation, and VC++ is as good as most now.)
But what the parent is saying (and which is a very legit argument if you ask me) is that if you're looking for a Debian repository, you're almost certainly not going to find a fake file!
If you want to be sure, you can compare the file size to the official one. If it matches, you can be all but completely confidant that it's real.
After all, there are probably far fewer people trying to flood P2P with bogus files just for the hell of it then there are trying to flood P2P with bogus files in an attempt to protect copyright.
The OED has a citation dating even before that, 1668. It's not a precise match, because they are called "land pirates", but:
"J. HANCOCK Brooks' String of Pearls (Notice at end), Some dishonest Booksellers, called Land-Pirats, who make it their practise to steal Impressions of other mens Copies."
Ignoring the fact that it doesn't need a Qt-ish solution, it does need ported. If Qt would have been an appropriate platform to write it in from the beginning, it would probably be an appropriate platform to port it to. Even if porting to a native toolkit would be a bit easier, in the long run %FAVORITE_CROSS_PLATFORM_TOOLKIT% (like Qt) would probably be a better choice. That way, future versions don't need to be ported or cross-developed.
Is it just me or does wxWidgets seem to have most of the ugliness of MFC without the nice tools in Visual C++ that were there to deal with it?
When we just got over an attorney general who covered up the breasts of the Spirit of Justice, have congresscritters going after GTA and now The Sims 2, and where parents are separated from their baby for 6 mths because dad took a picture of him kissing the kid's chest after a bath, do you really think that the government WILL distinguish?
In retrospect I think that experiment I did sheds no light on it. I think I just made the traditional "heavy objects fall faster" mistake, just shifted so that "heavy" was "less bouyant" and "fall" was "sink." At the time I was thinking that would make a difference, but falling is really just sinking through air, so I don't think it actually would.
Still, CDs aren't very dense.
AOL CDs would work, but you'd need a lot of them. CDs sink, but not very fast. It took a couple seconds from being inserted into a tub of water for my experimental CD to drop a couple inches to the bottom.
On the other hand, while I don't have any to try, I have a strong feeling that the SCO lawsuits would float. Actually, I suspect they would not just float out of the pond/lake/etc. but also up into the upper atmosphere because of the quantity of hot air contained within.
Beyond that, as Graham points out, there are few patterns in well-written Lisp code. If a Lisp programmer finds himself repeating the same pattern of code over and over, he'll just write a macro to codify the pattern.
First, duplicated code != a design pattern.
Second, what can a Lisp macro do that, say, a C macro or a function can't? (I ask merely for information, I'm not challenging you.)
I must admit that I have never programmed in Lisp (my functional languages experience is limited to ML), but I would bet a substantial sum that there are at least a few idioms in Lisp that could be considered analogous to the OO design patterns that an OO language makes invisible.
11. Go to prison for perjury if they figure it out. Not to mention pay MS for the copy of Windows and possibly the cost of any investigation they did as a result of your statement.
That counterfeit report you have to fill out? Probably you need to endorse it under penalty of perjury.
The exception to this would be if Compaq didn't fulfill any responsibilities regarding registration of the copies of Windows they distributed.
If, for instance, for each computer they ship they have to tell MS "yeah, this copy of Windows actually got shipped out to a customer" and they didn't and that's why Windows Update doesn't like it, Compaq would almost certainly be at fault. Or, worst case scenario (for Compaq) if they distributed unlicensed copies themselves.
Still, if you were going to sue someone probably MS would be the guys; let them worry about joining Compaq as a third-party defendant.
Yeah, but there's a difference between "there's a risk" and "there's possibly a serious enough risk we're regrounding the shuttles."
I doubt the astronauts are losing much sleep over it, but the grandparent is right, NASA probably could have had a little more tact and announce the grounding once Discovery (presubably) safely returns. It's not like it's a time-critical announcement.
It wouldn't have caused anyone any problems probably, and might have eased the minds of a few. "Can't hurt, might help."
the root of Moores' Law states, fundamentally, that the more you use a technology, the better it gets.
Actually, Moore's law doesn't even directly talk about performance at all.
It is specific to integrated circuits and says that the complexity will double roughly every two years.
Complexity roughly corresponds to number of transistors which certainly roughly corresponds to performance.
See Wikipedia.
"Good enough" -- even "almost perfect" -- doesn't mean "right".
Not disproving, extending
Depends on how strict you are with the word "disproving". Because fact is, Newton and Einstien never (or at least almost never) agree. And when they disagree, our current understanding of physics says that Einstien is right, or at least closer. So in that sense, Eintstien did disprove Newton.
On the other hand, in most situations the discrepancy between what Newton and Einstien say is so absurdly small that you could easily argue that me saying they differ is me being extremely pedantic, and in that sense he didn't disprove Newton in those situations.
All this is why I put quotes around "disproved".
Two things:
First, hence the quotes around "disproved".
Second, the AC that also responded to you is right. Newton is never 100% right. However, with the speeds, forces, etc. we experience on a regular basis, Newton is so absurdly close to being correct that it works just as well as Einstien, and the errors that simplification introduces are more or nothing compared to measurement errors.
What, a hundred and fifty years isn't enough?
Newton published his laws of motion in, I belive, 1679. Einstien published his special relativity paper in 1905, "disproving" Newtonian mechanics.
And we're still of course not sure Einstien has the last word. In fact, it's almost certain he doesn't.
No, 150 years isn't enough time.
I'd mod you up but I've already posted.
That extension rules! Thanks!
It's not necessarily dumb. Latex-Beamer can produce, IMO, the nicest "PPT-like" presentations I've seen.
It's not just a matter of not measuring them because of a lack of trailer parks, it is reasonable to conclude from this research originally from The Annals of Improbable Research that the lack of trailer parks actually reduces the occurances of tornadoes.
Many of the other variables mentioned as possible influences on the frequency of tornadoes, such as camcorder sales, are also substantially lower or in fact zero on Mars.
This is a lot simpler than what might arise in practice, but the following code when compiled with gcc and -O2 on Solaris seems to produce about as optimal code as I think you could hope for in a high-level language in which the call to foo wasn't inlined:Keep in mind that everything above foo() would sit in a header file somewhere, so you wouldn't have to worry about it.
Granted, the syntax could possibly be made nicer, perhaps by doing something like using a notation for a pair, but you have to ask if the increased "prettyness" of the source really justifies that.
I'm not so much trying to say that the addition is a bad idea, or not cool, or wouldn't lead to better code; I'm just trying to show why there's little chance it would happen.
...when it would be much more elegant (and likely less buggy) as a language feature?
Changing the language is more difficult than adding a library because the compiler must be modified, which is a daunting task.
The trick is to find a way to do it safely without any (or with very little) extra overhead. I'm trying to come up with an idea, but I don't have anything yet. If I think of something, I'll reply again. However, I'm reasonably confidant that there's a way to do it with no extra overhead (at least with any moderately decent optimizing compiler), I can feel it, I just don't know how yet.
The template system is still not a generics system, but an ugly cut & paste macro system which can incidentally be used for generics, with some caveats. ...and which is a couple of orders of magnitude more powerful than a simple generics system.
"C++0x". Were they specifically trying to come up with a name less convenient than "C#"? Ah well, I guess we can call it "COX" or "cocks" for short.
No, they're following a couple (at least) decade old convention. Standards are described by the standard name followed by the year.
C87 is the C language as standardized in 1987. (Or whatever year it was.) C99 is the C language as standardized in 1999. The full name of the current C++ standard is C++97, because it was standardized in 1997. C++0x refers to the next version of the C++ standard. Only it doesn't have a full name, like C++08, because we have yet to invent a device that will see into the future to find out when the standardization actually occurs. Thus we need a placeholder.