I understand from Bill Bryson's "Mother Tongue" that the so-called correct usage of "begging the question" is, in fact, a corruption of "beggaring the question".
If that's indeed the case, parent uses the expression correctly, doesn't it?
After perusing the release notes and understanding the apt issue, I bit the bullet and went ahead with a full upgrade of a server to which I will not have console access for 2 weeks.
The entire process was smooth - 400 packages upgraded, and 60 or 70 new ones.
I wouldn't have dared do it with any other distro.
I think you're playing tricks with language - you made an argument regarding the word "informed", and then made the leap of applying it to the word "informative".
I agree, one can ask an informed question; I disagree that one can ask an informative question.
Hint to Mods: I think this one's +((-1)^0.5), Irrational.
Human: Are liberal?
ALICE: I really couldn't say for sure.
Human: Are you conservative?
ALICE: I don't know whether or not I am conservative. I am a giant electronic brain.
Human: Giant, eh?
ALICE: Are you Canadian? Try to determine if this is a person or a computer responding.
Human: HA HA HA HA HA!!!!
ALICE: I'm glad you find this amusing.
Kinda like when I'm hankering for a snack and I go to the fridge, only to find nothing. Then a few minutes later, I'll go again - just to see if anything has magically materialized in the interim...
Re:When was the last time Moore's law was correct?
on
Forty Years of Moore's Law
·
· Score: 2, Interesting
But that's not what Moore's Law says.
All it says is that the number of transistors you can fit in a fixed area doubles roughly every 18 months (or, expressed another way, the area of a transistor is halving every 18 months.)
Making transistors smaller does tend to mean you can run cirucits faster because you can switch state faster (which in turn, also reduces the dynamic component of your power consumption), but it's not just a simple linear relationship between size and speed.
Yeah, I was curious about that comment, too. I've had a M10000 (Nehemiah) for about a year, and more recently I purchased an MII 6000E fanless model. I run both of them diskless, booting over NFS, keeping them cool and quiet (absolutely silent in the case of the MII 6000E).
The fan of the M10000 has become a little loud recently - it seems to rattle, but that's about the only issue I have, and the fan could be replaced.
You end up with the entire code in one compilation unit (if that's the correct term). There is no need for function or class prototypes, or for externs - the implementation is right there in the #include'd source hierarchy.
Bizarre? Yeah, I agree. But what would you do if your tool vendor one day tells you to do something you think you believe you will later regret?
The language itself is syntactically very similar to Java, but has traditionally used header files as one would in C. Then one day, the vendor starts telling people not to do it that way.
What is different is the tool chain. But that's not really the language per se. Not all C tools are used in the same way either. SO I think the comparison is still valid.
But what they're advocating would still work in C, which is why I posed the question that way. Many replies have latched on to the idea that you'd have to have function prototypes in every source file, but that's not true. The entire app ends up being one translation unit, so there ARE no externals; it's all right there in the output of one pass of the pre-processor.
I'm not saying it's a good idea. I really, really don't like it. But it works better than most of the replies here have assumed.
Interestingly, this language actually uses a modified cpp for pre-processing.
The individual source files don't all have function prototypes of the classes or functions in other files. Those file themselves are #include'd, so they end up being all in the same translation unit (if that's the correct term).
I've been using this language for about 5 or 6 years. I know what other Vera users think. But many people in my field come from more of a hardware-design background - where principles of software engineering have been less rigorously enforced. So many just take this suggestion without much alarm.
The language itself is syntactically very similar to Java, though traditionally has used #include'd header files, just as one would in C. The only real differences are in the way the tool chain works (but then not all C compilers work the same way, do they?)
I really wanted to see what more seasoned software developers think of this scheme. Despite the posts clamouring to the contrary, C experience is definitely relevant.
Not, it isn't. It was deliberate. Because few people here know what Vera is.
It's a language syntactically very similar to C or Java.
Traditionally, people have always #include'd header files containing class & function protoypes, just like one would in C or C++. The compiler even generates header files for you. Clearly that was the intent.
Then one day, in all their wisdom, the vendor starts telling people to not do it that way. Some people happily follow without question. Some of us think it's bizarre and are very uncomfortable with the idea.
I'm not advocating this method. It's being thrust upon me.
The reason for header files is
1) Function prototyping. Otherwise, you may have
to prototype functions in all source files
Not true. They're saying the ENTIRE source code base should be #include'd in a tree-like structure, down from the top level file.
You don't need a prototype in each source file because the actual definition is right there, #included hierarchically.
Listen, people, I'm not advocating this method. I stated (pretty clearly, if you ask me) in the question that I think it's "abhorrent". But it's being thrust upon me and I'm trying to figure out if there are really advantages to it.
The answer has to be "we don't know" because you haven't told us what language this is. I reckon it's some sort of verilogrevolting or system-Cyukyuk abomination,
Not a bad guess. It's Vera. But what's the point of telling people that? How many people on slashdot even know what Vera is?
in which case I would say *** do what the vendor tells you *** because if you don't and it all falls apart they will say "we told you so"
But what's messed up is that vendor just decided to start advocating this one day. The Vera compiler even supports header generation - it's been done the way we expect for years. And bang, one day they suddenly start encouraging this weird approach. "What the vendor tells me" is not what the vendor told me five years ago, or last year.
I know that there was some discussion sparked internally at the vendor because I raised this question with their FAEs. I already know what other verification people think; I wanted to get an impression of what people thought of the same methodology if it were applied to similar languages.
Thanks for all the interesting replies. It's always nice to start a flame war.
I wish I'd included a few more details, which might have avoided questions like, "Are you stupid?" and "Have you taken basic Computer Science course?" (the answers are "On occasion" and "Waterloo, Comp Eng '98" respectively:) )
A few details which might put the question into perspective might be:
The project is a chip verification project. There is no final "product" at the end of my work. The name of the game is endlessly re-compiling and running new tests. So compile time is actually quite significant.
There is no linker.:) The nature of the language is such that it is linked at run time.
The compiler actually doesn't allow you to list multiple source files on the command line and produce one object. So I guess my C/Java analogy was misleading. But that's partly why I'm at a loss to rationalize the question - there is little direct reference point.
A lot of people missed my point - I think abandoning header files is abhorrent. But when it came down to it, I couldn't actually produce any inarguable reasons why (namespace is one, but I don't think it's a show-stopper).
Slashdot Mirror
I understand from Bill Bryson's "Mother Tongue" that the so-called correct usage of "begging the question" is, in fact, a corruption of "beggaring the question".
If that's indeed the case, parent uses the expression correctly, doesn't it?
After perusing the release notes and understanding the apt issue, I bit the bullet and went ahead with a full upgrade of a server to which I will not have console access for 2 weeks.
The entire process was smooth - 400 packages upgraded, and 60 or 70 new ones.
I wouldn't have dared do it with any other distro.
Thanks, Debian.
Who wants to enter our sweepstake for when Debian 3.2 will be released? Pick a date, and if you're the nearest, you'll win ... well, nothing.
I take July 4th, 2007.
Pfft. Optimist...
I think you're playing tricks with language - you made an argument regarding the word "informed", and then made the leap of applying it to the word "informative".
I agree, one can ask an informed question; I disagree that one can ask an informative question.
Hint to Mods: I think this one's +((-1)^0.5), Irrational.
;)
Of course, now that my parent has been modded down to -1, Offtopic, my response should be dealt with similarly.
But, uhh, please don't.
I guess the system works - although the system may be insane.
Mods: How on earth can a question be "informative"?
Our other bargaining chip, of course, is our oil. In 2000, the US imported more oil from Canada than from any other nation.
Oh, wait. On second thought, perhaps we should keep quiet about that. We've seen what they can do to nations whose oil they covet.
He suggested calling it "Triple-U"
Since it's three double-U's, should it not be a hextuple-U?
God, now they're going to rape "The Lion, the Witch and the Wardrobe"
Also on the table is a re-make of Peter S. Beagle's "The Last Unicorn".
Kinda like when I'm hankering for a snack and I go to the fridge, only to find nothing. Then a few minutes later, I'll go again - just to see if anything has magically materialized in the interim...
But that's not what Moore's Law says.
All it says is that the number of transistors you can fit in a fixed area doubles roughly every 18 months (or, expressed another way, the area of a transistor is halving every 18 months.)
Making transistors smaller does tend to mean you can run cirucits faster because you can switch state faster (which in turn, also reduces the dynamic component of your power consumption), but it's not just a simple linear relationship between size and speed.
Yeah, I was curious about that comment, too. I've had a M10000 (Nehemiah) for about a year, and more recently I purchased an MII 6000E fanless model. I run both of them diskless, booting over NFS, keeping them cool and quiet (absolutely silent in the case of the MII 6000E).
The fan of the M10000 has become a little loud recently - it seems to rattle, but that's about the only issue I have, and the fan could be replaced.
...or the Wallace and Gromit claymation short, "The Wrong Trousers"!
As a Gnome user, every six months I'm treated to incremental improvements and features.
Heh. Obvously you don't run Debian...
But you don't get need duplicate defintions.
You end up with the entire code in one compilation unit (if that's the correct term). There is no need for function or class prototypes, or for externs - the implementation is right there in the #include'd source hierarchy.
Bizarre? Yeah, I agree. But what would you do if your tool vendor one day tells you to do something you think you believe you will later regret?
But it's not that different.
The language itself is syntactically very similar to Java, but has traditionally used header files as one would in C. Then one day, the vendor starts telling people not to do it that way.
What is different is the tool chain. But that's not really the language per se. Not all C tools are used in the same way either. SO I think the comparison is still valid.
But what they're advocating would still work in C, which is why I posed the question that way. Many replies have latched on to the idea that you'd have to have function prototypes in every source file, but that's not true. The entire app ends up being one translation unit, so there ARE no externals; it's all right there in the output of one pass of the pre-processor.
I'm not saying it's a good idea. I really, really don't like it. But it works better than most of the replies here have assumed.
Interestingly, this language actually uses a modified cpp for pre-processing.
But the same applies to their method.
The individual source files don't all have function prototypes of the classes or functions in other files. Those file themselves are #include'd, so they end up being all in the same translation unit (if that's the correct term).
No, you didn't read my post. That was deliberate.
I've been using this language for about 5 or 6 years. I know what other Vera users think. But many people in my field come from more of a hardware-design background - where principles of software engineering have been less rigorously enforced. So many just take this suggestion without much alarm.
The language itself is syntactically very similar to Java, though traditionally has used #include'd header files, just as one would in C. The only real differences are in the way the tool chain works (but then not all C compilers work the same way, do they?)
I really wanted to see what more seasoned software developers think of this scheme. Despite the posts clamouring to the contrary, C experience is definitely relevant.
Personally I'd be very sceptic of jumping on a wagon that goes contrary to software design practices while not really having any arguments.
Precisely, sir.
A curiously large proportion of responses seem to think I'm advocating this approach. I'm not; it is being thrust upon me.
Not, it isn't. It was deliberate. Because few people here know what Vera is.
It's a language syntactically very similar to C or Java.
Traditionally, people have always #include'd header files containing class & function protoypes, just like one would in C or C++. The compiler even generates header files for you. Clearly that was the intent.
Then one day, in all their wisdom, the vendor starts telling people to not do it that way. Some people happily follow without question. Some of us think it's bizarre and are very uncomfortable with the idea.
I'm not advocating this method. It's being thrust upon me.
The reason for header files is 1) Function prototyping. Otherwise, you may have to prototype functions in all source files
Not true. They're saying the ENTIRE source code base should be #include'd in a tree-like structure, down from the top level file.
You don't need a prototype in each source file because the actual definition is right there, #included hierarchically.
Listen, people, I'm not advocating this method. I stated (pretty clearly, if you ask me) in the question that I think it's "abhorrent". But it's being thrust upon me and I'm trying to figure out if there are really advantages to it.
The answer has to be "we don't know" because you haven't told us what language this is. I reckon it's some sort of verilogrevolting or system-Cyukyuk abomination,
Not a bad guess. It's Vera. But what's the point of telling people that? How many people on slashdot even know what Vera is?
in which case I would say *** do what the vendor tells you *** because if you don't and it all falls apart they will say "we told you so"
But what's messed up is that vendor just decided to start advocating this one day. The Vera compiler even supports header generation - it's been done the way we expect for years. And bang, one day they suddenly start encouraging this weird approach. "What the vendor tells me" is not what the vendor told me five years ago, or last year.
I know that there was some discussion sparked internally at the vendor because I raised this question with their FAEs. I already know what other verification people think; I wanted to get an impression of what people thought of the same methodology if it were applied to similar languages.
I think I got a number of serious responses and a few informative ones, too.
/. know what Vera is, and I didn't want to limit the responses who are ASIC verification engineers.
I'm guessing that very few people on
I think it was quite a useful exercise, actually.
I wish I'd included a few more details, which might have avoided questions like, "Are you stupid?" and "Have you taken basic Computer Science course?" (the answers are "On occasion" and "Waterloo, Comp Eng '98" respectively
A few details which might put the question into perspective might be:
- The project is a chip verification project. There is no final "product" at the end of my work. The name of the game is endlessly re-compiling and running new tests. So compile time is actually quite significant.
- There is no linker.
:) The nature of the language is such that it is linked at run time.
- The compiler actually doesn't allow you to list multiple source files on the command line and produce one object. So I guess my C/Java analogy was misleading. But that's partly why I'm at a loss to rationalize the question - there is little direct reference point.
- A lot of people missed my point - I think abandoning header files is abhorrent. But when it came down to it, I couldn't actually produce any inarguable reasons why (namespace is one, but I don't think it's a show-stopper).
Thanks again for your insights.