That's retarded. What did the first compiler translate into? P-code? Whatever it was, the esteemed Dr. Wirth could simply have written the first version of the compiler in that.
You bootstrap a new language by writing a compiler for a subset of that language in some existing language. Then you write a fuller version in the new language, compile it, and from then on you work in the new language alone.
You don't execute the compiler on paper. That's a useless exercise at the best of times; in this case, it's a pure waste of time.
It is cool, though I'm not convinced that writing an optimizer in C++ templates is the way to go. Certainly the idea of having libraries that can direct the process of code generation (rather than just providing a bunch of canned subroutines) is very cool, but C++ templates are too verbose and unweildy for mortal man.
They do have some truly awesome features, though. Like the way you can provide specialized implementations of things. It has been a while, but I think if you have a template<int n>, you can also easily provide a template<2> with a specially optimized version for when n=2.
I have never used BLITZ++, but I don't think it's object-oriented. It's more along the lines of the generic programming paradigm, making heavy use of templates, much like the STL.
Ok, this is off-topic, but used to think that using 10 as the base for "orders of magnitude" was a bit big. For instance, if a is five times as big as b, then they really are totally different quantities. The b quantity is only a small fraction of a, and is relatively insignificant, so I think they deserve to be considered different orders of magnitude.
On the other hand, a factor of two seems not to be big enough. If a is twice as big as b, they seem still to be in the same ballpark. The b quantity is a significant portion of a, such that subtracting b would completely change the character of a.
So, I came to the conclusion that e, the base of the natural logarithm, should also be the base for "orders of magnitude". To me it seemed like about the right ratio to raise one number into a whole different category from another.
However, since most of us still count on our fingers, ten it is.
Re:Ireland *has* changed to the Euro
on
The Euro
·
· Score: 1
Would someone mind explaining to me how my comment (see parent) could be considered a "troll"?
Re:Ireland *has* changed to the Euro
on
The Euro
·
· Score: 1, Insightful
ireland is more or less a part of britain
Yeah, just like the US is more or less part of Britain.
Re:In response to others...
on
Flying on Mars
·
· Score: 1
You should be able to account for that. I'm no expert, but it seems to me that if you have a picture containing the spacecraft and the sky, and you know that spacecraft is lit by that sky, you should be able to get a good approximation of the real colours involved.
Regardless, I still think it's not as stupid as you made it out to be. He wasn't proposing that you can just fiddle with the colours until the sky looks any colour you want.
Re:In response to others...
on
Flying on Mars
·
· Score: 1
Because the colour of the sky is caused by Raleigh scattering (or other scattering effects), the effect (based on the size distribution of particles in the atmosphere) is the same on Mars as it is Earth.
The same on Mars as it is on Earth? If the colour of the sky is dependent of the atmosphere and its contents, then the Earth and Martian skies should be completely different, just as the atmospheres are.
I don't think that's the case. AFAIK, the scattering effects don't depend on the atmosphere's contents: shorter wavelengths are always scattered more.
I don't even know where to begin with this one. It's as if O.J. Simpson took pictures of his poor victims, and photoshopped away stab wounds to prove that they aren't in fact dead. Sure you can prove that the Martian sky is blue with one Photoshop filter, and I can prove that I'm 50 pounds thinner with another...
I think you need to read your parent post again. He's saying that the colour of the spacecraft can act as a control sample. Correct the picture so the spacecraft looks right, and everything else should also look approximately right.
I'm not sure it's as easy as that, but it's certainly not as stupid as you make it sound.
I think we're getting confused here between 'what', 'how', and 'why'. I'm using 'what' to mean 'what is intended'; you're using it, I suspect, to mean 'what is being done'.
I think this is indeed a source of confusion. When I say a function name should indicate "what" that function does, I don't mean just what it does now. I mean what its specification indicates that it is supposed to do. This, I think, covers your bit clearing example: if the functions's spec merely claims that it resets a thing, then it should just be called resetThing.
I had perceived that your claim was that a wrapper function called resetThingToIndicateSuccess should be added, for example, to convey not only the function's spec, but also the programmer's intent. My position was that the "to indicate success" part, being indicative of the programmer's motivation for calling the function, should be in a comment rather than in the function's name.
Perhaps we are both mistaken about each other's position? Anyway, any misunderstanding aside, I think we probably still disagree on how to name functions.:-)
Alright, thanks for the links. I'll ponder that some more.
A few more small things...
Pardon, but function names are usually more of a language feature than comments; they're checked by the language, they're part of the syntax... Comments are just bolt-ons. And this IS the purpose of function names; but most people don't use them wisely.
A function's name is not checked against what it does, any more than a comment is. As for most people not using comments wisely, I think that relates to your point that one has to trust the programmer because there's nobody else to trust.
A dummy that lets comments get out of synch is just as likely to leave function names unchanged when their implementation changes. I'm not sure I buy your argument that poorly named functions stand out more than incorrect comments.
Code reuse: how can you reuse code if you don't know what it does?
I think now you're arguing my side. I have been advocating naming a function for what it does. You're the one arguing that it should be named for why it does it, remember?:-)
Divide-and-conquer: indeed, this is important -- but it's hard to argue that bad naming will help your strategy here.
I hope you don't actually think I'm advocating the use of bad names. I'm just advocating naming functions by "what" rather than "why".
Of course, everyone and their dog had the typical knee-jerk "lines of code mean nothing" reaction. Well, duh, that goes without saying. I can't believe how many mod points have been wasted on that sentiment.
How about we give this guy the benefit of the doubt and assume he knows what he's doing. Then what we have is a tremendous contribution to the free software community. I, for one, say thanks and keep up the good work.
And, if it gets released and is full of bugs, then let's beat the old lines-mean-nothing horse to death.
I didn't give that example -- look at the history.
I was referring to this code:
MakeNotAccidentallyClickable(widget);
That's what I meant by "example".
No! There were no problems in my code; there couldn't be, since I wrote no code. What I did was respond to someone else's problem sketch with a solution sketch. You responded not by pointing out omissions in my solution, but by inventing new problem details and situations.
Ok, perhaps I made a straw man. The point I was trying to make is that there must be more details to the situation, whatever they are; and because your code didn't specify them, the problems you found in my commented version of the code may or may not exist in yours. One can't know without more information.
Perhaps I can sum up my thoughts this way. Programmers make mistakes. It's hard to tell mistakes apart from deliberate decisions without some indication of the programmer's frame of mind. Thus, comments are only unnecessary in perfect code. If you choose to encode your comments using function names, rather than the features provided by the language specifically for the purpose, that's your choice; but it's not yet clear to me that it is a beneficial one.
A superb question.
And you have provided some superb answers that deserve some thought. I'm not convinced yet, but your position no longer seems ridiculous.:-)
Have you ever come across (or written) any material that discuss the pros and cons of your approach?
I do have a bit of a problem with the assertion that a block of comments should always become a separate function. There is a "sweet spot" when it comes to decomposing functions: with too few functions, they are too large to understand; with too many, algorithms can become scattered and fragmented, like a book with one word on each page. Splitting every function block into a new function seems to run a great risk of fragmenting the code in this way.
To me, function decomposition already serves three purposes: information hiding, code reuse, and divide-and-conquer problem solving. Adding a fourth criterion--of allowing comments to be encoded as function names--seems to raise the possibility that the criteria may conflict, and one may have to be sacrificed for another. Looking at the list, I know which is first on my chopping block.
The second comment says, "I, the programmer of this system, don't like the UI design." BAD SMELL. Use comments if you must, but a FAR FAR better solution is to fix the UI. Don't you agree?
Hey, you're the one who gave the example, so you tell me why you would call the "MakeNotAccidentallyClickable" function. I can't tell from your code, and that's the exact problem.
It seems to me that my comments have helped you to diagnose problems in the code that were not obvious without those comments.
for every scenario you invent, I'll invent a way to code it so the comments aren't needed
Why would you want to do that? What is the advantage of your scheme over comments?
Your aim of having clearly-written code is admirable. I think code should explain very, very clearly what it is doing. However, explaining the "why" when it is not obvious from the "what" is exactly what comments are good at.
I think that the idea that code can somehow take the place of comments is bogus. Code, no matter how clearly written, only tells you what is happening. It can't tell you why.
For instance, why did you make that widget not accidentally clickable? Why not others? Is that widget in particular danger of being accidentally clicked? Are the consequences of accidental clickage very bad?
Code like this seems clearer to me:
/* Make sure user doesn't accidentally delete the document */
disable(widget);
Or:
/* This widget is very large, and liable to be clicked accidentally */
disable(widget);
My guess is that the cable would lean very slightly to the west more or less permanently while you are sending up payloads. In this state the cable would also be pulling up and to the west on the mooring station, which would bleed off some angular momentum from the Earth (but never enough to measure). If you stopped sending up payloads the cable would gradually straighten.
Ah, yes. Now that makes sense. Thanks!
I just wish I had read this before I posted that other reply that assumed the cable was perpendicular.
You are probably not thinking about angular momentum, but energy in circular motion.
Perhaps, but I really think I'm talking about angular momentum.
To answer your question, the increase in angular momentum of the payload is a result of the force exerted by the elevator doing work on the payload, resulting in a change in energy of circular motion.
How can you get angular momemtum arising from forces that act perpendicular to the direction of the desired orbit?
If you are worried about what is called conservation of angular momentum, the increase in angular momentum comes from a decrease in the angular momentum of the Earth.
The cable is not rigid, and unless I'm mistaken, it is perpendicular to the Earth's surface, so I don't see any way it can transmit a moment to the Earth.
Perhaps. It still feels like we're getting angular momentum for free here. It's like we're neglecting the biggest coriolis effect on the planet.
I think when a weight goes up the rope, stealing some of the rope's angular momentum, the rope will not swing like a pendulum as a result. Rather, it will very, very slowly wrap itself around the earth.
When something's going up the elevator, where does it get all the angular momentum it needs to stay in orbit? Does the climber have rockets? I don't see them on the diagram.
DirectMail, as much as we all hate it, is an effective marketing tool.
So? Theft is an effective revenue source. That doesn't make it ok.
It's when you CANNOT request yourself removed from direct mailing campaigns, that it becomes spam.
Spam is any unsolicited commercial email.
Re:Level of fuzziness
on
Binary Watch
·
· Score: 1
3.5? I think you mean 3. The error grows linearly at first, from zero to 6 hours, for an average of 3. Then it shrinks linearly, again for an average of 3.
A Catch-22: how to initially draw people to a community when the a community itself is the selling point...
That's not a catch-22, it's a bootstrapping problem. A catch-22 would be more like "how to attract people to a community when the very act of attracting them will only drive them away".
Slashdot Mirror
That's retarded. What did the first compiler translate into? P-code? Whatever it was, the esteemed Dr. Wirth could simply have written the first version of the compiler in that.
You bootstrap a new language by writing a compiler for a subset of that language in some existing language. Then you write a fuller version in the new language, compile it, and from then on you work in the new language alone.
You don't execute the compiler on paper. That's a useless exercise at the best of times; in this case, it's a pure waste of time.
It is cool, though I'm not convinced that writing an optimizer in C++ templates is the way to go. Certainly the idea of having libraries that can direct the process of code generation (rather than just providing a bunch of canned subroutines) is very cool, but C++ templates are too verbose and unweildy for mortal man.
They do have some truly awesome features, though. Like the way you can provide specialized implementations of things. It has been a while, but I think if you have a template<int n>, you can also easily provide a template<2> with a specially optimized version for when n=2.
I have never used BLITZ++, but I don't think it's object-oriented. It's more along the lines of the generic programming paradigm, making heavy use of templates, much like the STL.
Ok, this is off-topic, but used to think that using 10 as the base for "orders of magnitude" was a bit big. For instance, if a is five times as big as b, then they really are totally different quantities. The b quantity is only a small fraction of a, and is relatively insignificant, so I think they deserve to be considered different orders of magnitude.
On the other hand, a factor of two seems not to be big enough. If a is twice as big as b, they seem still to be in the same ballpark. The b quantity is a significant portion of a, such that subtracting b would completely change the character of a.
So, I came to the conclusion that e, the base of the natural logarithm, should also be the base for "orders of magnitude". To me it seemed like about the right ratio to raise one number into a whole different category from another.
However, since most of us still count on our fingers, ten it is.
Would someone mind explaining to me how my comment (see parent) could be considered a "troll"?
You should be able to account for that. I'm no expert, but it seems to me that if you have a picture containing the spacecraft and the sky, and you know that spacecraft is lit by that sky, you should be able to get a good approximation of the real colours involved.
Regardless, I still think it's not as stupid as you made it out to be. He wasn't proposing that you can just fiddle with the colours until the sky looks any colour you want.
I'm not sure it's as easy as that, but it's certainly not as stupid as you make it sound.
I had perceived that your claim was that a wrapper function called resetThingToIndicateSuccess should be added, for example, to convey not only the function's spec, but also the programmer's intent. My position was that the "to indicate success" part, being indicative of the programmer's motivation for calling the function, should be in a comment rather than in the function's name.
Perhaps we are both mistaken about each other's position? Anyway, any misunderstanding aside, I think we probably still disagree on how to name functions. :-)
A few more small things...
A function's name is not checked against what it does, any more than a comment is. As for most people not using comments wisely, I think that relates to your point that one has to trust the programmer because there's nobody else to trust.A dummy that lets comments get out of synch is just as likely to leave function names unchanged when their implementation changes. I'm not sure I buy your argument that poorly named functions stand out more than incorrect comments.
I think now you're arguing my side. I have been advocating naming a function for what it does. You're the one arguing that it should be named for why it does it, remember?Anyway, thanks for the discussion.
Are you telling me you see no difference between Rhys Weatherly and Microsoft?
Of course, everyone and their dog had the typical knee-jerk "lines of code mean nothing" reaction. Well, duh, that goes without saying. I can't believe how many mod points have been wasted on that sentiment.
How about we give this guy the benefit of the doubt and assume he knows what he's doing. Then what we have is a tremendous contribution to the free software community. I, for one, say thanks and keep up the good work.
And, if it gets released and is full of bugs, then let's beat the old lines-mean-nothing horse to death.
Perhaps I can sum up my thoughts this way. Programmers make mistakes. It's hard to tell mistakes apart from deliberate decisions without some indication of the programmer's frame of mind. Thus, comments are only unnecessary in perfect code. If you choose to encode your comments using function names, rather than the features provided by the language specifically for the purpose, that's your choice; but it's not yet clear to me that it is a beneficial one.
And you have provided some superb answers that deserve some thought. I'm not convinced yet, but your position no longer seems ridiculous.Have you ever come across (or written) any material that discuss the pros and cons of your approach?
I do have a bit of a problem with the assertion that a block of comments should always become a separate function. There is a "sweet spot" when it comes to decomposing functions: with too few functions, they are too large to understand; with too many, algorithms can become scattered and fragmented, like a book with one word on each page. Splitting every function block into a new function seems to run a great risk of fragmenting the code in this way.
To me, function decomposition already serves three purposes: information hiding, code reuse, and divide-and-conquer problem solving. Adding a fourth criterion--of allowing comments to be encoded as function names--seems to raise the possibility that the criteria may conflict, and one may have to be sacrificed for another. Looking at the list, I know which is first on my chopping block.
-
Names should be as long as necessary to describe what a thing is.
-
The shorter a name is, the better.
The ability to satisfy these two rules simultaneously is a symptom of simple, clear abstractions.It seems to me that my comments have helped you to diagnose problems in the code that were not obvious without those comments.
Why would you want to do that? What is the advantage of your scheme over comments?Your aim of having clearly-written code is admirable. I think code should explain very, very clearly what it is doing. However, explaining the "why" when it is not obvious from the "what" is exactly what comments are good at.
I think that the idea that code can somehow take the place of comments is bogus. Code, no matter how clearly written, only tells you what is happening. It can't tell you why.
/* Make sure user doesn't accidentally delete the document */
/* This widget is very large, and liable to be clicked accidentally */
For instance, why did you make that widget not accidentally clickable? Why not others? Is that widget in particular danger of being accidentally clicked? Are the consequences of accidental clickage very bad?
Code like this seems clearer to me:
disable(widget);
Or:
disable(widget);
Ah, very good. That makes sense. Thanks!
I just wish I had read this before I posted that other reply that assumed the cable was perpendicular.
Perhaps. It still feels like we're getting angular momentum for free here. It's like we're neglecting the biggest coriolis effect on the planet.
I think when a weight goes up the rope, stealing some of the rope's angular momentum, the rope will not swing like a pendulum as a result. Rather, it will very, very slowly wrap itself around the earth.
Ok, thanks. But doesn't that impart equal and opposite angular momentum to the cable? What happens to that momentum?
When something's going up the elevator, where does it get all the angular momentum it needs to stay in orbit? Does the climber have rockets? I don't see them on the diagram.
3.5? I think you mean 3. The error grows linearly at first, from zero to 6 hours, for an average of 3. Then it shrinks linearly, again for an average of 3.