- Overuse of 'auto' - 16 Updates
- sizeof() - 3 Updates
- "Why ISO C++ Is Not Enough for Heterogeneous Computing" by Intel - 2 Updates
- accelerate - 4 Updates
| David Brown <david.brown@hesbynett.no>: Dec 19 03:18PM +0100 On 19/12/2022 09:54, Juha Nieminen wrote: >> vector_of_ints_to_average) > As always, you use redundant information to artificially lengthen names. > That's arguing in bad faith. I'm arguing that giving full explicit descriptions in identifiers makes them harder to understand, and code is clearer when they are omitted. Pointing out the absurdity of your "longer is always better" idea is not arguing in bad faith. If I write : std::unique_ptr<Image> image_pointer = std::make_unique<Image> (image_file); then that is repeating redundant information in comparison to : auto pI = std::make_unique<Image>(image_file); (copying Öö's examples). Are you going to claim that the first use of redundant information is always bad but the second use of it is always good? Or could it be - as everyone but you has been saying all along - that it is easier to understand code without /excess/ information and redundancy? > For starters, I gave "returnValue" as a better alternative to "ret". > That "ret" is not giving you any more information than "returnValue", > but it's more cryptic for no good reason. I agree it gives no extra information. I disagree that it is cryptic, and I disagree that it is shorter for no good reason. It is shorter because the short form is clearer and faster to understand, without sacrificing any useful information. > If you were to reject the > use of "returnValue" in favor of "ret" then... well, it's better I > don't continue this sentence. I'd likely reject the use of "ret" as well - it is a poor choice of name, and gives little useful information. But it is not as bad as "returnValue", which is useless /and/ long and therefore a waste of brain power. >> "err" is an error code, /that/ is the problem - not the name of the >> variable. > There's zero reason to make the name more cryptic than it has to be. There's zero reason to think that obvious names are cryptic. > of such strong opposition. It feels like I have been suggesting to use > profanity, swearwords and politically offensive terminology in variable > and function names. No, you are just suggesting a waste of effort and bad habits that make code harder to read. Look, I appreciate the challenge of dealing with code that is cryptic and has poor choice of identifiers. There are many ways identifiers can be done badly - overly short names and with inappropriate abbreviations is certainly one such way. But equally, overly /long/ names that are cumbersome, repetitive, and distract from important information is another way to write incomprehensible code. You go too far in that direction. Like most things in life, the ideal is a happy medium, and the details depend on the circumstances. >> write out /everything/ in the longest, most explicit manner? > There we go again with the length argument. > How many times do I have to repeat this? You seem to believe in proof by repeated assertion - I've heard no other justification for your arguments. > IT'S NOT ABOUT LENGTH! > It's about legibility and understandability. I know that. We all know that. It is best to use "i" as an index in a "for" loop, unless you have good reason for picking something else, because it is entirely clear to the reader what "i" is. Writing "index" is worse - no one knows what it is, other than an index into some container, and you have to look and think to see where it comes from. Being a longer name, the obvious thought is that it comes from further away earlier in the code, or will be used further away later in the code, rather than being a very local "for" loop counter. Even if you have the same associations for "i" and "index", "i" is better because it is shorter. Shorter means faster to process, less effort, and less distraction from the rest of the code. It is not about length - it is about being clearer, easier to read, and easier to understand. In this case, being shorter is a factor that makes it clearer and more legible. And yes, we all agree that often "average" is better than "avr" because it is clearer and unambiguous, and thereby easier to read despite being longer. No one is arguing that short is always better. However, when I say "short is /sometimes/ better, or at least not worse" (as in the case of a loop variable), and you disagree, the logic of your disagreement is that "longer is always better". Perhaps you don't realise you are claiming that, but you are. If you don't think that "longer is /always/ better", then you are actually in agreement with what others have said all along. > legibility makes names longer, but that's just an irrelevant side > effect. The length itself is not the primary goal. > How hard is that to understand, honestly? I understand what you are saying. I don't think /you/ do. |
| David Brown <david.brown@hesbynett.no>: Dec 19 03:20PM +0100 On 19/12/2022 09:58, Juha Nieminen wrote: > array of bits. > Well, at least std::vector<bool> doesn't come with 87.5% wasted space, > which is a positive. I'd rather have the wasted space than the inconsistency, and then have an alternative type with a more appropriate interface and space-efficient implementation. I don't want compromise, I want both possibilities. |
| David Brown <david.brown@hesbynett.no>: Dec 19 03:39PM +0100 On 19/12/2022 10:06, Juha Nieminen wrote: >> converted to an "int". > While it's not perfect, at least it's better than "auto x = a * b;" > because at least you have *some* information, which is better than none. Why is it better? Why do you care what type it is? Surely the important thing about "x" is that it is the result of multiplying "a" and "b", not its type. If you use "auto", you know that type is correct for its use here - if you use "int", it might not be. Good, legible programming is about making the important information clear - not about making all details clear at all points in the code. > understanding better that line of code. For example, if the variables > were named "row_index" and "table_width", suddenly that line becomes > extraordinarily clearer than if they are just "a" and "b". I don't care about the clarity of the line. I care about the clarity of the /code/. Do you understand the difference? const auto b = table.width(); for (auto a = 0; a < table.row_count(); a++) { auto x = a * b; ... The code in question is /clearer/ than using "row_index" and "table_width" would be, because it is simple and quick to parse mentally, and all the relevant information about "a" and "b" is immediately available. ("w" and "i" would be better than "b" and "a", of course. And we don't know if "x" is a good name without seeing the following code.) Clarity is for /code/, not for /lines/. > understanding better what that line is doing and what the variables and > their types are. > Which is my entire point in this thread. So you are in agreement that you don't know the types of the variables or functions in use, without their context. The logical implication is that using "auto" is not some terrible sin that destroys the readability of code - really, it is just a minor issue compared to good naming. |
| David Brown <david.brown@hesbynett.no>: Dec 19 03:48PM +0100 On 19/12/2022 10:15, Juha Nieminen wrote: > compressed into a small space full of letters and non-ascii characters. > There's literally no reason to prefer "tpr" over "test_point_right". > There are no benefits of any kind, there are only drawbacks. There /are/ benefits - everyone has been telling you about them. The problems you face have nothing to do with the use of short names or abbreviations - that's a red herring. They are entirely a matter of trying to understand code without appropriate context and information. It doesn't matter if the variable is called "test_point_right" or "tpr" - what matters is that you know what that means. It is utterly irrelevant that "test_point_right" is a long name with full words, if the person reading the code doesn't know what it means. And if they know that the function is for generating left and right test points (and know what these are), then "tpr" is a better choice than "test_point_right" because it is simple, short, quick to read and does not waste time on redundant information. There can be many reasons why you are looking at code that you don't understand - and as many remedies for making the process more efficient. But from what you have said here, it is not the short name of the variable that is the main issue. It is, at most, a symptom of a bigger problem. |
| "daniel...@gmail.com" <danielaparker@gmail.com>: Dec 19 07:10AM -0800 On Monday, December 19, 2022 at 9:40:14 AM UTC-5, David Brown wrote: > important thing about "x" is that it is the result of multiplying "a" > and "b", not its type. If you use "auto", you know that type is correct > for its use Actually you don't if 'a' and 'b' are matrices and 'a*b' returns a proxy object, as a numerical library would do. In other languages you could make that claim about 'var x = a*b', but in C++ it needs to be qualified, in some contexts the type is correct for its use, in others it's undefined behavior. Daniel |
| Juha Nieminen <nospam@thanks.invalid>: Dec 19 03:24PM > And longer code is not necessarily clearer code. Hereby I present a > snippet of actual code from a former coworker who strongly believed in > long self-explanatory names. Rather obviously length doesn't automatically make it clearer (which is why I have been repeating that length doesn't matter). You have to choose the words being used for the name so as to convey clearly to the reader what it is. 'convert()' is not a very good name because it doesn't say what it's converting, and into what. 'convert_something_into_something()' is a ridiculous name because it's as bad as the first one above, plus contains completely useless redundancy that doesn't help understand what it's doing. 'convert_to_utf8()' is better, although only depending on the context. It's saying what it's converting to, but it doesn't say what it's converting from. Sounds like a (heavily) overloaded function, but in general I don't like those being used for no good reason, and thus I would prefer if the function actually says what it's converting from, like for example 'convert_to_utf8_from_utf16()' This starts being a good name because it expresses relatively clearly what it's doing (although it does not express its parameter types) and doesn't really contain any redundancy. (Whether you also want to express the type of the parameters in the name might be more up to discussion. Here I'm not extraordinarily strongly opinioned. Might be more relevant if there are several versions of the function for different string types.) > He also believed in 76-char line limit. There's really no reason to use such a limit, and there hasn't really been in a rather long time. Quite obviously if your names become longer then you want a bit wider lines. (Well, as long as you don't go overboard. I have seen code that breaks the 200 characters per line mark, and that starts being a bit ridiculous, even when your editor is that wide.) > inline std::string q(const std::string& s) { > return ("\"" + s + "\""); > } He also seems to commit the typical mistake of thinking that 'inline' implies 'static' (which, AFAIK, it definitely does not). (Horribly named function, btw.) > inline void Validate_ObjectsSetCardinalityEquality_type1_helper1( The main problem I see here is that the name might contain lots of words, but most of those words don't really clarify what this is doing. Maybe it's clearer in context, but all by itself it's hard to guess what that 'type1' or 'helper1' is supposed to convey. Using full English words doesn't by itself guarantee clarity. Obviously you have to choose those words appropriately to convey to the reader as clearly as possible what the thing is for. > int n_1 = number_of_objects_in_the_1_comparable; > int n_2 = number_of_objects_in_the_2_comparable; > std::string AssertionFailureMessage = ""; Inconsistent case usage is also a sin in programming. Choose a consistent naming style and stick to it. |
| Juha Nieminen <nospam@thanks.invalid>: Dec 19 03:37PM > I can't help it if it is true that shorter names are easier to read than > longer names, as long as they are unambiguous in the context. Is that why you always use short words like "unambiguous", "cognitive", "brainpower" and "understanding"? A short name isn't really all that much easier to read than a long name. The problem with short names is that they don't convey as much information and they can make code more compressed, which means that there's a lot more information in a small space, making deciphering code that much more difficult. If you have difficulty in reading and understanding big words, well... there's a slightly offensive joke I could make about it. >> I see absolutely nothing "good" about it. I can only see negatives. >> How would I know what the 'clear()' is doing, or where it comes from? > You'd know because it is obvious from the code if you dare to look at it. Would be much more obvious if it actually said what it's "clearing". > half-way down the page. Do you really expect to be able to understand > everything that is going on in that sentence from the sentence alone? > Of course you don't. Why would you expect to do so in code? I certainly don't need to start checking the glossary of terms of the book every second word because it only uses obscure contractions and acronyms. But that's exactly the case with the majority of code out there. Even lines of code that *could* be clear on their own are made obfuscated by the use of cryptic abbreviations which hide the meaning. > height on the vertical axis is equal to the distance along the > horizontal axis squared plus four times the distance along the > horizontal access minus three", or "y = x² + 4x - 3" ? Mathematics does not deal with strings, classes, algorithms, data containers, I/O, files, device drivers and so on and so forth. And it's mostly inscrutable anyway. Sometimes it feels like mathematicians take pride in making their work as incomprehensible to the uninitiated as humanly possible. > or the use of whole words and phrases instead of short names and > /obvious/ abbreviations is not a substitute for good naming. I'd > certainly rather see "tmp" than "temporary_value". Then use a better name if the long name does not convey clearly its purpose. |
| Juha Nieminen <nospam@thanks.invalid>: Dec 19 03:42PM > /really/ claim you think "i" is not clear in a simple "for" loop? This > is not a notation invented by Muttley - it has been standard in almost > every programming language except APL. I have read enough code written by others to say that yes, with perhaps the exception of very short one-liners, naming the loop variable after the thing it's indexing makes the code clearer than using a short abstract name that says nothing. The importance of this grows about linearly with the length of the loop body, and exponentially with each nested loop. You wouldn't believe how much easier it is to read and understand especially nested loops where each loop variable is clearly named after the thing it's indexing or counting. You don't have to guess. You don't have to remember. It says it directly. It makes it so much easier to understand. |
| Juha Nieminen <nospam@thanks.invalid>: Dec 19 03:55PM > So your good example is: > for(size_t image_index = 0; image_index < images.size(); ++image_index) > Lot easier than with "i"? Easier to read and understand, yes. Absolutely. The longer the loop body, the more it helps. If there are nested loops, it helps even more. (Conversely, the longer the loop body and the more nested loops there are, the more obscure the 'i' becomes, as it gets buried in the code and it's harder to find and remember what it is. Heaven forbid you mix it with 'j'. Now you are just writing obfuscated code.) I don't even understand why this is such a controversial thing. Clearer variable names are better. You will have extremely hard time convincing me otherwise. > std::unique_ptr<Image> image_pointer = std::make_unique<Image>(image_file); > Latter feels like stuttering of "image" ridiculously many times. I feel > like: "I got it, it is image, stop babbling!" when reading it. I don't see that as a huge problem. Repetition does not reduce clarity. If you want to use 'auto' for iterators, lambdas and unique_ptrs created with make_unique, then fine. The problem is that the "always use auto" people use it with everything, very much in situations where it just hides the type for no good reason and at the expense of clarity. > demand, lawyers seem to be paid by text length and so define > shorthands rarely, only to avoid it getting outright comical. Think > about it. No, legalese is not incomprehensible because of the detail, but because of the obfuscated language being used, which is exactly what we want to avoid in code. We want clarity in code, not obfuscation. We don't want obscure terms and acronyms, we want clear full English words that express clearly the meaning. |
| Juha Nieminen <nospam@thanks.invalid>: Dec 19 04:03PM > "table_width" would be, because it is simple and quick to parse > mentally, and all the relevant information about "a" and "b" is > immediately available. What is clear here is that you are just arguing for the sake of arguing. I don't think even you believe what you are writing anymore. You are just opposing on principle and nothing else. It's absolutely incredible that someone could seriously claim that "a" and "b" are clearer names than "row_index" and "table_width". I will give you the benefit of the doubt and not make any claims about your intelligence, and instead just assume that you are just arguing for the sake of argument. That's the better alternative. |
| Juha Nieminen <nospam@thanks.invalid>: Dec 19 04:06PM >> There's literally no reason to prefer "tpr" over "test_point_right". >> There are no benefits of any kind, there are only drawbacks. > There /are/ benefits - everyone has been telling you about them. No, there literally are zero benefits. None. There are only drawbacks. I find it hilarious that you are arguing about code that I myself had to review and understand, telling me that the acronym is better than the fully written version, against what I can see with my own eyes. (And btw, the variable was changed to use full English words. And not even by my suggestion but another reviewer's. I was not the only one who found the code harder to understand because of poor variable naming.) You are just arguing for the sake of arguing at this point. |
| Muttley@dastardlyhq.com: Dec 19 04:52PM On Mon, 19 Dec 2022 12:10:24 -0000 (UTC) >> If habits hang around for a long time its usually because they're good, not >> bad. >You can't be serious. I can. People sticks with what works in coding unless there's a very good reason to change it. >You can argue against it all you want, you can write ten miles of text >repeating your objections over and over and over, but you cannot change >what I see with my own eyes. What do you see here, a face or a vase? https://en.wikipedia.org/wiki/Rubin_vase#/media/File:Face_or_vase_ata_01.svg Peoples perceptions are different. >I have had to read inordinate amounts of code written by other people, >having to fully understand what the code is doing, for several years >now. You cannot make what I have seen clearer and easier to understand Wow, a whole several years. I've been doing it since the mid 90s and I suspect others on here much longer than that. >cryptic obfsucated code. It's relatively clear that you are arguing >just for the sake of arguing. No matter what I say, you will argue >against it, just for the sake of arguing against it. Overrates importance of own opinion. Tick. >Get into your thick skull that just because *you* can understand Insults when losing argument. Tick. >> You think you're the only person on this group who's had to work on other >> peoples code? >Deducing from these response, it appears to be so. Arrogance. Tick. >> hold it all for long enough. >You are still making it sound like typical Java code is more readable >than typical C or C++ code. Go read some then get back to me. >> What, like SMS? :) >One of my exceptions to the rule is "unless it's a universally used term >or acronym which meaning is very clear". What, like 'i' for indexing? |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Dec 19 04:55PM >> clearer, because it makes names shorter and has less clutter. > And there we go again with the brevity argument. Again, and again, and > again, and again. Ad infinitum. That's (sorry, that is) what happens when there is a difference of opinion. It may be that this issue has been properly studied, but all the early attempts to inject some data into these sorts of debate were, in my opinion, rather superficial. > Sorter code is not necessarily clearer code. In fact, quite often it's > the opposite. Where does this strange concept come from, that shorter > is clearer? I don't see you using abbreviations in your English prose. This is not a good argument. For one thing everyone uses abbreviations and contractions in written English. You've (sorry, you have) used two in that very paragraph. It's (sorry it is) very common to write things like "the UK", "the USA", "e.g", "i.e.", "etc." in prose. But prose is very different to code. For one thing the contractions and abbreviations used in English are few (in proportion) and largely well-known, so my saying that they are ubiquitous in English is not a good counter-argument either. > Why not? Because if you abbreviated every single word in your text, > it would become near illegible. That's why. You use full English words > because your text becomes more legible that way. Again, this not a good argument because the kinds of text are so very different. Names in code are invented and so, to some extent, arbitrary where most words are not. Ab wds in Eng wd be akwd, but "for (int i = 0; i < length; i++)" is not (in my opinion) despite the short name i. > Well, it isn't. Also program code becomes more legible when it's actually > stating, using full English words, what it's doing, instead of being full > of cryptic abbreviations and acronyms. What's needed are some more nuanced examples and/or rules. My own preference is to take into account the length of the scope of the name as well as considerations such as convention and generality of use. I consider "index" no better than "i" when the scope is very short (as it usually should be) and when the use is general, but "index_of_largest" might be better in a less general context. > The brevity-over-clarity style of programming will probably be a curse > in programming for as long as humanity will exist and keep writing > programs. Brevity-over-clarity is always bad, almost by definition. We should try to avoid terms like "overly short names" and "excessive abbreviation" in this kind of debate because they beg the question. -- Ben. |
| Juha Nieminen <nospam@thanks.invalid>: Dec 19 06:04PM > and contractions in written English. You've (sorry, you have) used two > in that very paragraph. It's (sorry it is) very common to write things > like "the UK", "the USA", "e.g", "i.e.", "etc." in prose. I have stated in another post that my principle is that full English words should be used, but an exception can be made with acronyms that are universally used and understood (such as GPS, HDMI, cos, etc.) You only use abbreviations and acronyms in prose when they are in very common use. You don't start abbreviating every single word you write. Same with code: If you want to use a universally used acronym like "HDMI" then fine, but whey are you abbreviating *everything*? It only makes the code harder to understand, just as would happen if you do it when writing English. > consider "index" no better than "i" when the scope is very short (as it > usually should be) and when the use is general, but "index_of_largest" > might be better in a less general context. I consider "index" better because not only does it actually say what it is, it's visually more distinguishable. The more compressed the code is, the harder it is to decipher. If the code is nothing but single-character names and symbols, it becomes very obfuscated. However, when names of things are expressed in actual words, it becomes easier to read because the code isn't as compressed. Of course even better is naming the loop variable after what it's going to index. But lacking that, if nothing else, "index" is better than "i" just because it stands out better from the rest of the symbols in the code and is more visible. Maybe, *maybe*, 'i' is acceptable in *very* short one-liner loops. (But even then... Why? What's the advantage? I see no advantage.) |
| Juha Nieminen <nospam@thanks.invalid>: Dec 19 06:08PM >>Get into your thick skull that just because *you* can understand > Insults when losing argument. Tick. Insults? Maybe it's because I'm not a native English speaker, but this is the first time in my life I hear that "thick skull" is an insult. It just means "stubborn". Unless you think "stubborn" is also an insult. I myself can be quite stubborn at times. I don't find that very insulting. Maybe you also have a thin skin in addition to a thick skull... And this post of yours did nothing to dispel my notion that you are just arguing for the sake of arguing. Nobody in their right mind would say that clearer variable and function naming is a bad thing. |
| David Brown <david.brown@hesbynett.no>: Dec 19 07:25PM +0100 On 19/12/2022 16:37, Juha Nieminen wrote: >> longer names, as long as they are unambiguous in the context. > Is that why you always use short words like "unambiguous", "cognitive", > "brainpower" and "understanding"? If there were shorter words that meant the same and were equally familiar, I'd use them. (Assuming I thought of them at the time!) > and they can make code more compressed, which means that there's a lot > more information in a small space, making deciphering code that much > more difficult. Shorter names /are/ easier to read and understand, if they convey the same information. There's a certain amount of variation between people, however. Some people find it easier to read words if they can pronounce them in some way - others recognise words more visually. This means that some people will process "temp" faster than "tmp", while for others it does not make a difference. >>> How would I know what the 'clear()' is doing, or where it comes from? >> You'd know because it is obvious from the code if you dare to look at it. > Would be much more obvious if it actually said what it's "clearing". It /is/ obvious what it is clearing - it's a function concerned with a display, and it has "using namespace display" in it. > I certainly don't need to start checking the glossary of terms of the > book every second word because it only uses obscure contractions and > acronyms. If you have to do that when reading code, you are not ready to read that code. Making code readable and understandable does not mean making everything obvious in every line. If you want to understand a piece of /my/ code, I expect you to have done some basic homework first. You need to be aware of what the target system should do, have a rough understanding of the type of microcontroller being used, have read the comments at the start of the file, looked at the rest of the function, etc. There is a great deal more to know about code than what you see on a line, regardless of the names of the identifiers or the use of explicit namespaces. Perhaps you expect too much from people's code? You are looking to be spoon-feed on every line, regardless of how much worse the code is for people who want to have a better understanding of the code as a whole. >> horizontal access minus three", or "y = x² + 4x - 3" ? > Mathematics does not deal with strings, classes, algorithms, data > containers, I/O, files, device drivers and so on and so forth. So? > And it's mostly inscrutable anyway. Sometimes it feels like mathematicians > take pride in making their work as incomprehensible to the uninitiated as > humanly possible. Do you think insulting mathematicians makes your case stronger? It simply makes it clearer that you are on your own here, living in a different world from other developers. |
| "gdo...@gmail.com" <gdotone@gmail.com>: Dec 19 09:12AM -0800 should be consider a function not an operator? I'm thinking the trend to lambda functions, or no named function makes it ok to call it a function? but ok it's an operator. looks like a function, 😂🤣😎 <=> is cute, spaceship. lol. looks like upper and lower teeth to me and the corners of a mouth. I guess I would have called it grin. lol, way too many versions of integers, but I get why there are, but still, way too many versions going forward. but fine. there should be a reason C++/ C programmers make the big bucks. 🤔🙂 hey and if we are going to have revisions how about adding yes and no, we now have true and false. if ( isThisACharacter( c ) )... seem to me one would yes this is a character as opposed to true this is a character. oh well : good grief. if ( (isThisACharacter( c ) ) == yes ) { } lol. and how about ending the idea that any other value then 0 will make something true. with the addition of bool let's be strict. lol you talk about breaking some code. hey hey we need the jobs anyway. lol we may as well dump static arrays all together. #define is gone and I kinda liked it. well soon to be gone. 🤷♂️ #define yes 1 #define no 0 const int yes = 1; const int no = 0; --- or --- const bool yes = true; const bool no = false; oh my! yes I guess one just needs to think. lol, lol I'm reading a book on C++ and the author I think has gone a bit over board with 'declare a variable right before you need it'. to me it makes the code feel hacked. like, I'm programming while I type, so oh yeah I need this so let me stick it in. plus it, to me, makes the code harder to read. hard to get the overall thought cause he keeps pulling rabbits, variables, out of his hat, so to write. 🤦♂️🙃 memory is plentiful and cheap, relatively speaking. 😇 |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Dec 19 10:02AM -0800 > should be consider a function not an operator? [...] No, sizeof is an operator. A function cannot take a type as an argument, nor can it fail to evaluate its argument(s). The sizeof operator seems odd because its symbol is a keyword rather than a punctuation symbol. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for XCOM Labs void Void(void) { Void(); } /* The recursive call of the void */ |
| Juha Nieminen <nospam@thanks.invalid>: Dec 19 06:13PM > should be consider a function not an operator? It's no more a function than eg. 'return' is. It doesn't even require parentheses (at least for expressions). In C++11 it could theoretically be a function, but not prior to that, nor in C, because it needs to be evaluated at compile time. |
| scott@slp53.sl.home (Scott Lurndal): Dec 19 03:28PM >>Towing a boat up and down to Lake Tahoe from Carson City, one needs a >>vehicle than can do it. >Depends how big the boat is. And the difference in elevation between the two points and the grade of the highway connecting the two points. Which in this case, (Carson City to Lake Tahoe) is significant. |
| Muttley@dastardlyhq.com: Dec 19 04:58PM On Mon, 19 Dec 2022 15:28:24 GMT >And the difference in elevation between the two points and the >grade of the highway connecting the two points. Which in this >case, (Carson City to Lake Tahoe) is significant. Yet in europe we have normal cars towing reasonably sized double axle caravans. There are obviously SUVs doing it too but few people seems to need to resort to driving a 2.5t pickup to do it and the pickups you do see are usually work vehicles with company logos on the side. Oh and diesel for obvious reasons which are probably beyond your average lifestyler. |
| scott@slp53.sl.home (Scott Lurndal): Dec 19 03:25PM >> https://escholarship.org/uc/energy_ambitions >You know, at some point we are going to build a partial Dyson sphere >around the Sun to capture its energy. Have you bothered to calculate the amount of energy required to build a dyson sphere (or even a dyson ring)? If you have that much energy, you don't need to build the sphere in the first place. |
| Michael S <already5chosen@yahoo.com>: Dec 19 07:36AM -0800 On Monday, December 19, 2022 at 2:55:25 AM UTC+2, Keith Thompson wrote: > > We need to accelerate investment in new nuclear build and green hydrogen > [SNIP] > This is comp.lang.c++. C++ => increase consumption of carbon |
| Michael S <already5chosen@yahoo.com>: Dec 19 07:38AM -0800 On Monday, December 19, 2022 at 5:25:53 PM UTC+2, Scott Lurndal wrote: > Have you bothered to calculate the amount of energy required > to build a dyson sphere (or even a dyson ring)? If you have that > much energy, you don't need to build the sphere in the first place. Incrementally rather than at once |
| scott@slp53.sl.home (Scott Lurndal): Dec 19 04:46PM >> to build a dyson sphere (or even a dyson ring)? If you have that >> much energy, you don't need to build the sphere in the first place. >Incrementally rather than at once Run the math. What is the diameter of the orbit? What are the material requirements? Even a ringworld would take more energy than it would produce just to build and put in orbit. How far out does it need to be to ensure that the energy density at any point is habitable? |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment