It's probably worth noting that even specs written in formal languages like CASL or Z typically include a certain amount of expository natural language to help the reader understand what's going on. Not that I'm suggesting you shouldn't use formal notation - far from it - I'm simply pointing out that formal notation and informal comments are complementary, both in code and in specifications.
Don't get me wrong. I'm not advocating commenting anything and everything. I'm just saying that there is value in comments that express intent. Apparently we agree on that much, since you are in favor of function header comments. I'm merely suggesting that there may be times where adding some comments on intent inside a function may be helpful too. All of this in response to the OP's assertion that code alone is sufficient.
I don't write notes describing what I'm doing before I work something out... I work it our first and then figure out how to describe it.
You shouldn't have to "figure out how to describe it", since the kind of comments I'm talking about involve intent rather than details of how the intent is achieved - think of it as an informal spec. If you can't articulate the reason for writing a particular function you probably shouldn't be writing it in the forst place.
Perhaps with design by contract like in Eiffel, the code itself could make the intent more clear than comments could. Sort of like stating the theorum you're gonna prove beofre you prove it. The code would describe the expected result before it calculates it.
DbC certainly helps. As do other formal expressions of what a function is supposed to be doing. But inevitably you find that there's a need for descriptive text as well - just as a mathematical proof is much easier to read if there's some accompanying exposition.
Comments are a good idea, but maybe not the best idea.
Comments, like many other things in life, are best used judiciously and in moderation. Comments shouldn't be written simply for the sake of writing comments. They should be written in order to provide a better communication of design intent.
Other posters have pointed out that it is hard to keep comments synced with code that's evolving... and I'm bitten by this all of the time.
Comments are part of the code. If you are changing code without changing comments then you haven't done a complete job of making the change.
The compiler and unit tests will tell me if my code is correct, but it is very time consuming to make sure the comments are correct.
The compiler will tell you that your code compiles, and (if the language your are using is statically typed) that it is type-correct. This raises the probability that your code is correct, but certainly doesn't guarantee it. There are plenty of programs that compile, but either don't run or produce garbage. Unit tests help. But how do you know they're testing the right things?
My dream is for a language that doesn't need comments...
Sure, that'd be nice. But I wouldn't count on it showing up any time soon. Mathematicians have been messing with formal notation for a while now, and they still ending up writing a lot of natural language exposition to help people understand what the formal stuff is doing.
maybe even one that could be explained by an automated tool (like the way Apple's Shark explains the dissasssembly of your code)
But that will simply tell you what the code does. Not what it's supposed to do. There is a distinct difference.
Where the comments and the code disagree, you don't know which represents the intention. It've very often the code that's correct and the comment that's stale.
Which is an example of poor code maintenance. However, at least it flags the fact that there is a problem. Is it the comment that's wrong? Or the code? While it may be that code is more often right than comments, you really don't know what the answer is in any specific instance. Automatically assuming that it's the code that's right can bite you quite badly. Better to do some research to find out, and then fix whichever is wrong. Eliminating comments won't make the problem go away. It just makes it harder to detect incorrect code.
Mathematicians, scientists, engineers, and anyone else who uses terse notation like that also spend a lot of time defining exactly what their notation means. The same reasoning is just as applicable when writing code.
You should also code first because you know what a function is supposed to do.
Or perhaps you could write a quick comment that describes "what the function is supposed to do" (since you already know). That has two advantages:
It tends to clarify your thinking with regard to what you're doing, which makes the code that much easier to write. To quote Richard Guindon "Writing is nature's way of letting you know how sloppy your thinking is."
It makes your intent clear for anyone else who is trying to read your code, so that they can determine whether or not what your function does is what it was actually intended to do.
The question is, "is the code doing the right thing?". Code alone won't answer that question. It does what it does. Comments will (or at least should) tell you what the intended effect of the code is.
Any language or system that does not allow full flowing and arbitrarily long comments is seriously behind the times. That we use escape characters to "escape" from code to comment is backwards. Ideally, comment should be the default, with a way to signal the occasional lines of code.
Interestingly enough, this is exactly what literate Haskell files do. Code is, depending on your taste, either indicated by preceding it with > signs e.g.
Here's some example literate Haskell code: > foo:: Int -> Int > foo 0 = 1 > foo n = bar n + foo n-1
or it's embedded in a LaTeX document, e.g.
\begin{document} Here's some example literate Haskell code embedded in \latex: \begin{code} foo:: Int -> Int foo 0 = 1 foo n = bar n + foo n-1 \end{code} \end{document}
The latter approach also has the advantage that you can produce some fairly nice looking documentation as well:)
Willow seemed (to me) like a tired retread of Star Wars ideas (kind of like 'Days of Thunder' to 'Top Gun'). Anyway, since you've deliberately made it harder by adding the restriction that "series count as one movie", how about:
LotR
Conan the Barbarian (not the Destroyer)
Highlander
Ladyhawke
Excalibur
Henry V (Branagh's version)
The 7th Voyage Of Sinbad
Crouching Tiger Hidden Dragon
The Princess Bride
Robin Hood (Patrick Bergin version)
Realizing of course that a lot of this comes down to personal taste. It probably also depends on how you define "sword & sorcery".
American Graffiti?
THX-1138?
These were not good movies? Or do they just not count because they were made before you were born?
I'll admit, Lucas has had some real stinkers (Howard the Duck, Willow). And I've been less than impressed with Eps I and II. But I wouldn't write the guy off completely just yet. He did have some real talent once upon a time. Hopefully he can rediscover it.
In fact, you have to get rid of nearly all of the energy. Most of the energy that is converted to electricity is then used to operate something which then converts it back to heat (like a computer chip).
A good point. In fact, thermal design for spacecraft (at least at the preliminary stages) is typically carried out under the assumption that all of the electrical energy not leaving the spacecraft as RF radiation is converted into thermal energy.
The two energy expenditures I can think of that don't yield waste heat are the propulsion system (ideally), and the radios (again, ideally).
Unfortunately, both of those items are less than ideal. It's not uncommon for a spacecraft transponder to be on the order of 20% efficient (or worse). Likewise, the ion propulsion systems they are planning on using for Prometheus have an electrical->thermal conversion efficiency of around 70-80%. Which for a 20kW thruster (e.g. the proposed NEXIS thruster) means 4kW+ of waste heat.
Of course, I expect it would be possible to use a significant portion of that to heat the propulsion fuel.
The current proposals for Prometheus involve nuclear-electric propulsion rather than nuclear-thermal propulsion. I don't believe that heating the propellant in a NEP system helps (although I'm not really a propulsion expert, so I'm quite prepared to be corrected on this).
Different mode of operation. Most of the SNAP series are Radioisotope Thermoelectric Generators (RTGs). They produce thermal energy through radioactive decay of Plutonium (not fission!), and directly convert it to electrical energy using thermoelectric devices (the Peltier effect). I don't recall what the efficiency of thermoelectric conversion is off the top of my head, but I don't think it's that good - the main draw for using it the the lack of moving parts.
The move to fission is driven by a desire to get more power (even a large RTG will only produce a few hundred Watts, versus the kilowatts they expect to get from a reactor). I don't know exactly what the trade-offs are with using Brayton cycle vs thermoelectric (or thermionic) conversion. The Russians have flown a number of thermionic nuclear reactors (the Topaz series), and they seemed to work fairly well. I suppose it's possible that Brayton cycle reactors are more efficient than thermoelectric/thermionic conversion. But even if you assume a (highly unlikely) 90% conversion efficiency, a 100kW reactor would leave you with 10kW of thermal energy to dump. At this point it's probably worth noting that even the most high-power satellites we currently fly (the Boeing 702 comm-sat) operate on a mere 15kW of power. So you're talking about being able to radiate as much energy as most satellites generate in total. And as I said, that's based on some pretty optimistic assumptions about the efficiency of the Brayton cycle.
Forgot to mention that, from what I can see on the uCLinux website, uCLinux hasn't been ported to any rad-hard or space-qualified processors. Which further reduces the odds that JPL would use it for a mission as important as JIMO/Prometheus.
You are 100% correct. The large panels are radiators to dissipate excess heat. Large radiators are a standard feature in designs for space-going reactors, since the conversion from thermal energy to electrical energy is far less than 100% efficient.
Given that this mission is still in the conceptual design phase it's highly unlikely that they've spec'ed either a microcontroller or an OS at this point. Besides, JPL typically favors VxWorks as its RTOS (for example, both Pathfinder and MER use VxWorks). Do you happen to have a link to support your assertion about uCLinux?
Slightly after. IIRC the Lando books were written by L. Neil Smith. The Han solo trilogy was by Brian Daley and was, IMHO, much better than the Lando trilogy.
Incidentally, if you enjoyed the Han Solo trilogy you might want to take a look a Daley's "The Adventures of Alacrity Fitzhugh and Hobart Floyt" trilogy. Not set in the Star wars universe, but a fun read all the same (and a similar feel to the Han Solo books).
Spreadsheets get used in the weirdest, most unexpected places. For example, both JPL's Project Design Center, and the Aerospace Corporation's Concept Design Center, use multiple Excel spreadsheets to design spacecraft. Not to the "nuts and bolts" level, but a preliminary design concept that can be used for rapid feasibility and trade studies, and rough cost estimates. Note that most JPL missions pass through the PDC during their development. And the bulk of the new generation of USAF spacecraft get their requirements, cost, and payload complements hammered out in Aerospace's CDC.
ESA has a similar facility, as does NASA Goddard. And from what I've heard contractors like Boeing have experimented with the same kinds of ideas.
Slashdot Mirror
It's probably worth noting that even specs written in formal languages like CASL or Z typically include a certain amount of expository natural language to help the reader understand what's going on. Not that I'm suggesting you shouldn't use formal notation - far from it - I'm simply pointing out that formal notation and informal comments are complementary, both in code and in specifications.
Don't get me wrong. I'm not advocating commenting anything and everything. I'm just saying that there is value in comments that express intent. Apparently we agree on that much, since you are in favor of function header comments. I'm merely suggesting that there may be times where adding some comments on intent inside a function may be helpful too. All of this in response to the OP's assertion that code alone is sufficient.
You shouldn't have to "figure out how to describe it", since the kind of comments I'm talking about involve intent rather than details of how the intent is achieved - think of it as an informal spec. If you can't articulate the reason for writing a particular function you probably shouldn't be writing it in the forst place.
Perhaps with design by contract like in Eiffel, the code itself could make the intent more clear than comments could. Sort of like stating the theorum you're gonna prove beofre you prove it. The code would describe the expected result before it calculates it.
DbC certainly helps. As do other formal expressions of what a function is supposed to be doing. But inevitably you find that there's a need for descriptive text as well - just as a mathematical proof is much easier to read if there's some accompanying exposition.
Comments are a good idea, but maybe not the best idea.
Comments, like many other things in life, are best used judiciously and in moderation. Comments shouldn't be written simply for the sake of writing comments. They should be written in order to provide a better communication of design intent.
Other posters have pointed out that it is hard to keep comments synced with code that's evolving... and I'm bitten by this all of the time.
Comments are part of the code. If you are changing code without changing comments then you haven't done a complete job of making the change.
The compiler and unit tests will tell me if my code is correct, but it is very time consuming to make sure the comments are correct.
The compiler will tell you that your code compiles, and (if the language your are using is statically typed) that it is type-correct. This raises the probability that your code is correct, but certainly doesn't guarantee it. There are plenty of programs that compile, but either don't run or produce garbage. Unit tests help. But how do you know they're testing the right things?
My dream is for a language that doesn't need comments...
Sure, that'd be nice. But I wouldn't count on it showing up any time soon. Mathematicians have been messing with formal notation for a while now, and they still ending up writing a lot of natural language exposition to help people understand what the formal stuff is doing.
maybe even one that could be explained by an automated tool (like the way Apple's Shark explains the dissasssembly of your code)
But that will simply tell you what the code does. Not what it's supposed to do. There is a distinct difference.
Which is an example of poor code maintenance. However, at least it flags the fact that there is a problem. Is it the comment that's wrong? Or the code? While it may be that code is more often right than comments, you really don't know what the answer is in any specific instance. Automatically assuming that it's the code that's right can bite you quite badly. Better to do some research to find out, and then fix whichever is wrong. Eliminating comments won't make the problem go away. It just makes it harder to detect incorrect code.
Mathematicians, scientists, engineers, and anyone else who uses terse notation like that also spend a lot of time defining exactly what their notation means. The same reasoning is just as applicable when writing code.
Or perhaps you could write a quick comment that describes "what the function is supposed to do" (since you already know). That has two advantages:
Now that's a programming fad I can wholeheartedly support! And a buzz-phrase I'll be busy propagating in the near future. :)
The question is, "is the code doing the right thing?". Code alone won't answer that question. It does what it does. Comments will (or at least should) tell you what the intended effect of the code is.
- LotR
- Conan the Barbarian (not the Destroyer)
- Highlander
- Ladyhawke
- Excalibur
- Henry V (Branagh's version)
- The 7th Voyage Of Sinbad
- Crouching Tiger Hidden Dragon
- The Princess Bride
- Robin Hood (Patrick Bergin version)
Realizing of course that a lot of this comes down to personal taste. It probably also depends on how you define "sword & sorcery".I'll admit that Mad Martigan had his moments :)
THX-1138?
These were not good movies? Or do they just not count because they were made before you were born?
I'll admit, Lucas has had some real stinkers (Howard the Duck, Willow). And I've been less than impressed with Eps I and II. But I wouldn't write the guy off completely just yet. He did have some real talent once upon a time. Hopefully he can rediscover it.
Thanks.
If you only rant and whine on slashdot, how are they supposed to hear you?
You mean Kate?
I think that's right, since it was Asterix and his pals that introduced tea to Britain (IIRC).
A good point. In fact, thermal design for spacecraft (at least at the preliminary stages) is typically carried out under the assumption that all of the electrical energy not leaving the spacecraft as RF radiation is converted into thermal energy.
The two energy expenditures I can think of that don't yield waste heat are the propulsion system (ideally), and the radios (again, ideally).
Unfortunately, both of those items are less than ideal. It's not uncommon for a spacecraft transponder to be on the order of 20% efficient (or worse). Likewise, the ion propulsion systems they are planning on using for Prometheus have an electrical->thermal conversion efficiency of around 70-80%. Which for a 20kW thruster (e.g. the proposed NEXIS thruster) means 4kW+ of waste heat.
Of course, I expect it would be possible to use a significant portion of that to heat the propulsion fuel.
The current proposals for Prometheus involve nuclear-electric propulsion rather than nuclear-thermal propulsion. I don't believe that heating the propellant in a NEP system helps (although I'm not really a propulsion expert, so I'm quite prepared to be corrected on this).
The move to fission is driven by a desire to get more power (even a large RTG will only produce a few hundred Watts, versus the kilowatts they expect to get from a reactor). I don't know exactly what the trade-offs are with using Brayton cycle vs thermoelectric (or thermionic) conversion. The Russians have flown a number of thermionic nuclear reactors (the Topaz series), and they seemed to work fairly well. I suppose it's possible that Brayton cycle reactors are more efficient than thermoelectric/thermionic conversion. But even if you assume a (highly unlikely) 90% conversion efficiency, a 100kW reactor would leave you with 10kW of thermal energy to dump. At this point it's probably worth noting that even the most high-power satellites we currently fly (the Boeing 702 comm-sat) operate on a mere 15kW of power. So you're talking about being able to radiate as much energy as most satellites generate in total. And as I said, that's based on some pretty optimistic assumptions about the efficiency of the Brayton cycle.
Forgot to mention that, from what I can see on the uCLinux website, uCLinux hasn't been ported to any rad-hard or space-qualified processors. Which further reduces the odds that JPL would use it for a mission as important as JIMO/Prometheus.
You are 100% correct. The large panels are radiators to dissipate excess heat. Large radiators are a standard feature in designs for space-going reactors, since the conversion from thermal energy to electrical energy is far less than 100% efficient.
Given that this mission is still in the conceptual design phase it's highly unlikely that they've spec'ed either a microcontroller or an OS at this point. Besides, JPL typically favors VxWorks as its RTOS (for example, both Pathfinder and MER use VxWorks). Do you happen to have a link to support your assertion about uCLinux?
Incidentally, if you enjoyed the Han Solo trilogy you might want to take a look a Daley's "The Adventures of Alacrity Fitzhugh and Hobart Floyt" trilogy. Not set in the Star wars universe, but a fun read all the same (and a similar feel to the Han Solo books).
It might have helped if you'd RTFA. It covered many of the issues you are complaining about.
ESA has a similar facility, as does NASA Goddard. And from what I've heard contractors like Boeing have experimented with the same kinds of ideas.
Hence the need to differentiate between computer scientists (your math students), and software engineers (student software developers).