I remember the world being surprised to mildly annoyed at best, surprised in the "did they (Apple) really do that, seems rude not to ask" sense. Very annoyed was definitely a minority. And of course those thinking it rude and those mildly annoyed included folks who had purchased U2 albums in the past, including the distant past. Those not interested at all seemed to delete it and calmly share sentiments such as "I hope Apple doesn't make a habit of this", a bit short of very annoyed.
So no, its not surprising that a lot of people listened to the album once they found it on their device, despite its "rude" delivery.
BTW call a spade a spade. Equation Group == NSA TAO
Not really, it may have once been NSA but once the code was discovered it could be anyone using it. It just becomes another "tool" in the "public" toolbox.
Java = back end JavaScript = front end Need both to do useful things, no?
Node.js is an event driven framework for build web/network apps. It doesn't run in the browser, it is the server fulfilling browser requests. It just happens to use the javascript language. http://nodejs.org/
Note that Torvalds concedes that the specific code example being complained about does not benefit by the use of goto.
Also not brought up in that discussions is that where to draw the line between goto and nesting depends on the amount of nesting and the length of the code in question, not nesting alone. People using goto in shorter simpler code are making the code less readable.
Now Love's example is a great one because of the falling through from one undo to another. Because the bailout applies to all nesting levels so far not just the current level. That would be awkward in purely structured code. However if the undo were constrained to only the err'ing level, if there had been a goto out after undo C and undo B then structured if/else would have been more readable. But as is with multiple levels of undo it is s very appropriate use of goto.
Unfortunately much use of goto is done when the code is simple and short, unlike Love's example.
Last I checked, Hollywood effects companies were all running their serious FX software on Linux desktops.
A lot of industrial grade engineering, scientific, graphics, etc code is *nix based. These users may be running Linux on PC hardware but they don't really want or care about Linux. They want a convenient working *nix to get their work done. Linux is just a convenient option. These people don't really care about the politics, the gpl, etc. If a BSD provided a more convenient option many would migrate.
Have you attended any Linux conferences in recent years. I'm told that Mac laptops are a pretty common thing. There is no shortage of less than true Scotsman.
Did you miss the part about aircraft being ineffective at night? The strategic problem of the campaign, for both sides, was that the United States could dominate the skies during the day but had to rely on surface ships at night.
The US carriers were withdrawn due to fear of their loss.
At the beginning of the campaign the Marines were landed and the fleet carriers withdrew a couple of days later. The loss of air cover caused support ships to be withdrawn. Marines ashore watched the majority of their supplies and equipment sail away with those ships.
Escort carries would make runs to within range of Guadalcanal to deliver aircraft to Henderson field. I believe Henderson was the major source of US airpower in the area for a while.
A little over two weeks after withdrawing the fleet carriers came up to intercept a Japanese carrier force coming south. This battle took place well to the north east of Guadalcanal. Aircraft from Henderson engaged forces in the vicinity of Guadalcanal.
If it wasn't for the surface fleet, including battleships, the marines ashore would have been in a bad way to put it mildly.
The Marines were in a bad way. They had less that a weeks food and light on ammunition too. Fortunately they were able to capture some Japanese food.
And yes, to say the surface fleet -- in particular the destroyers and cruisers -- fought valiantly to protect the Marines is an understatement. At times these destroyers and cruisers attacked vastly superior enemy forces on their routine patrols up the slot because they were the only thing between this force and the Marines.
Incidentally, the turning point of the war didn't happen at Midway, as is often repeated, but rather it happened at Guadalcanal. Midway was a battle, Guadalcanal was a campaign, one which proved the Japanese were not equipped materially or psychologically to fight a long war.
Midway occurred a month earlier and Imperial Japan lost four fleet carriers and more importantly many of their absolutely best air crews. This alone is arguably a valid turning point. At least in a naval sense and the pacific war was essentially a naval war. Now consider how this loss benefited the US at Guadalcanal. The victory at Midway greatly contributed to the victory at Guadalcanal.
Besides the material benefits Midway destroyed the myth of invincibility of the Imperial Japanese Navy and Guadalcanal destroyed the myth of invincibility of the Imperial Japanese Army and Marines. Both played extremely important roles.
Not that it mattered, really, since by the start of the war battleships were really only useful for providing shore bombardment and as AA platforms.
This is dead wrong. Read the history of the Guadalcanal campaign; it was surface ships that carried the day. Aircraft were ineffective at night and are best used in an offensive role, they can't effectively protect ships bringing in troops and supplies
I believe that during parts of the Guadalcanal campaign the aircraft carriers were withdrawn from the area to keep them "safe", well safer. They certainly saw action but toe to toe fleet engagements were being avoided. We were a little short on fleet carriers in 1942.
Also some of the capital ships sunk by aircraft had an assist from surface action. In one of those nighttime surface engagements a US destroyer put 3 torpedoes into a Japanese battleship, greatly reducing her speed. She could not keep up with the retreating fleet and was sunk by US aircraft in the morning when the sun came up.
BB's were used as ground fire support in Nam (a co-worker once told me an apocryphal story about a call for fire that got routed to a BB), but other than showing the colors, they really haven't done anything else since.
They were used in the 1980s to shell various hostile positions in Lebanon after the Marine barracks was attacked. This included killing a Syrian general in his command post.
They were also used in the 1991 Gulf War to shell various Iraqi positions.
AppleWin only *this* year correctly emulates the video hardware
Video has worked quite well for quite a long time. Lacking support for a rare undocumented unsupported hack doesn't represent a major bug in the emulator.
Not everything needs to be preserved for future historians
With respect, what is and what isn't worth preserving is up to future historians to decide.
Historian don't make such a call, they preserve everything. A cuneiform clay tablet with a receipt for a shipment of wheat is preserved as if it had the story of Gilgamesh on it.
Decisions of what to preserve are more the domain of invading Vandals and the city residents trying to hide things from them.
yeah, GOTO the end and do some cleanup and/or error reporting, which is common to all the gotos. I don't see a problem with that. It's clear, simple and avoid heinous if/else deep nestings.
The problem is goto is not just used in the "heinous" nesting cases. And "heinous" varies with the length of the conditional blocks. If there are many levels but it fits on a screen or two, perhaps leans toward if. If they are stretching for many screens worth of code maybe lean towards goto.
The problem with goto is that the conditional code is at the same nesting level as the unconditional code so it makes it less apparent what code is conditional. Using goto should be the exception, to substitute a smaller problem for a larger problem, not the rule, substituting a small problem for no existing problem at all (minor nesting for short durations).
I have written a lot of code in my life - Thousands of projects, millions of lines of code (for whatever that means), across a dozen languages and twice as many platforms. And outside Assembly (and DOS batch, if you want to count that as a "language"), I have not ever encountered a situation where I thought to myself "gee, I could really improve this with a GOTO, if only everyone wouldn't laugh at me for it".
I'm with you there.
I have, however, removed some pretty heinous uses of GOTO from other people's code. The most common one I see, people can't quite bring themselves to "return" from an error handler in the middle of a function, so they instead GOTO the end of it. Really??? Talk about missing the forest for the trees!
You are missing the forest of testing and debugging.:-) Its easier if you just have one place to set a breakpoint.
I think the indentation is evidence that it's very difficult to make code look good in Slashdot. Especially a quick off-the-cuff code example meant to illustrate a point.
The indentation I'm referring to is not the post's indentation. I don't bother with indenting code in posts either. What I am referring to is the normal source code indentation that appear in the body of an if statement. In the alternative goto scenario this conditional block appear inline with the header code in the source. Read the periods in the following code as spaces:
[header] if (cond) { ....[body]
}
[header]
if (! cond) goto bailout:
[body]
bailout:
No, the indentation, or lack therof is an indication, a stromg one even, that YOU are an idiot. The parent posted a quick example of some uncomplete C code in a forum, like/. and has to fiddle with tags and what ever to format it properly and you believe he intentionally indentated it 'wrong'? That makes you an idiot. Why don't you simlly asume the most likely cause is an formatting error?
The indentation I am referring to is not the indentation of comments in a discussion forum, look at my code samples in other responses in this topic. I don't bother with indentation either.
What I am referring to is the normal indentation of the body of an IF statement in source code. The use of goto causes the conditional part of the code to not be indented, it appears inline with the header code. Read the periods in the following code as spaces:
if (cond) { ....[body]
}
if (! cond) goto bailout:
[body]
bailout:
Before tossing the word "idiot" around you might want to make sure you understand what is being discussed.
No. The indentation is evidence that the original goto advocate did not think carefully before breaking the rule since the coding style fails at its stated intent.
Some programmers take this idea to an extreme and even write code such as:
int abs(int x) {
int retval;
if (x >= 0) retval = x;
else retval = -x;
return retval;
}
In this case, multiple return statements would make the code simpler, not harder to understand.
Removing one line of source code does not necessarily make code simpler and more understandable, it merely make the source code shorter. It is only more understandable when the shorter code is acting in the default / more common manner. And for functions the more common manner is a single return at the end. So while quite readable because of its brevity it is doing the less common thing and therefore requires a little more cognitive processing while reading.
Now in addition to being more readable with that one extra line, the common exit point, there is also the advantage of breakpoints when debugging. Now I am speaking in general and you may argue that in this specific case abs() is unlikely to need a breakpoint. If so I will counter that the function should still have a single exit point, as in:
int abs(int x) {
return (x >= 0) x : -x;
}
In all three implementations discussed it doesn't really matter what the source looks like beyond readability, the compiler will likely generate the same code.
How many levels of nested if blocks are you willing to tolerate solely in the name of avoiding a single use of the keyword goto?
Actually each nested level would need its own goto.
And I probably wouldn't start thinking about goto until 3 levels, and in many such situations I find a way to refactor things without goto. I am assuming large multiscreen blocks of code with 3. As the blocks get shorter and most/all the nesting appears on a single screen then the number goes up.
Keep in mind that goto has a readability penalty in that the lack of indentation masks that a block of code is conditional. I guess I'm weird but I like to write code with the intent of handing it off to someone else so I can move on to something new, but I want to make things easier for the next person.
Also keep in mind that for some compilers the issue is more than a goto statement appearing in source code. The compiler may not attempt certain optimizations in code when a goto is encountered.
There was supposed to be some cleanup code for the database_t object at the end of the function, but forgot to add it while playing with the code tag.:-)
Many of us assumed there was such cleanup code when we found the example lacking. Perhaps if there had been bailouts from multiple levels of nested code, but even then goto is not necessarily the best option.
The academics are always on a quest for purity, people who work for a living want to get things done as cleanly and quickly as possible.
Banging out code quickly during initial development is rarely getting things done quickly in the long run. One must also consider maintenance and future updates and enhancement, often made by someone other than the initial developer, which is where time gets lost due to mistakes during initial development. Many have good intentions of going back and cleaning up initial code but actually getting a chance to do so is not as common as many wish.
The general idea is that misuse of goto leads to buggier code, and that bugs are less expensive the earlier they are found, and ideally avoided in the fist place by good coding practices. So banging out code quickly can be counterproductive.
As for cleanly coded, what is cleaner and more readable about masking that fact that a block of code is conditional by avoiding indentation, which is all that the offered goto example is doing. Perhaps if the example had bailouts from several levels of nesting, but even in such situations goto is not necessarily the best way to go.
No, he's objecting to the example offered as an appropriate use of goto. It wasn't an appropriate use. It fails at the stated goal, making the code more readable. It makes it less readable by avoiding the indentation of conditional code.
If there had been a different example with nested code at various levels bailing out with goto's then maybe it would have been appropriately used, not necessarily but maybe. However as offered the example was a good example of when *not* to use a goto.
Slashdot Mirror
I remember the world being surprised to mildly annoyed at best, surprised in the "did they (Apple) really do that, seems rude not to ask" sense. Very annoyed was definitely a minority. And of course those thinking it rude and those mildly annoyed included folks who had purchased U2 albums in the past, including the distant past. Those not interested at all seemed to delete it and calmly share sentiments such as "I hope Apple doesn't make a habit of this", a bit short of very annoyed.
So no, its not surprising that a lot of people listened to the album once they found it on their device, despite its "rude" delivery.
BTW call a spade a spade. Equation Group == NSA TAO
Not really, it may have once been NSA but once the code was discovered it could be anyone using it. It just becomes another "tool" in the "public" toolbox.
Java = back end
JavaScript = front end
Need both to do useful things, no?
Node.js is an event driven framework for build web/network apps. It doesn't run in the browser, it is the server fulfilling browser requests. It just happens to use the javascript language.
http://nodejs.org/
Note that Torvalds concedes that the specific code example being complained about does not benefit by the use of goto.
Also not brought up in that discussions is that where to draw the line between goto and nesting depends on the amount of nesting and the length of the code in question, not nesting alone. People using goto in shorter simpler code are making the code less readable.
Now Love's example is a great one because of the falling through from one undo to another. Because the bailout applies to all nesting levels so far not just the current level. That would be awkward in purely structured code. However if the undo were constrained to only the err'ing level, if there had been a goto out after undo C and undo B then structured if/else would have been more readable. But as is with multiple levels of undo it is s very appropriate use of goto.
Unfortunately much use of goto is done when the code is simple and short, unlike Love's example.
Last I checked, Hollywood effects companies were all running their serious FX software on Linux desktops.
A lot of industrial grade engineering, scientific, graphics, etc code is *nix based. These users may be running Linux on PC hardware but they don't really want or care about Linux. They want a convenient working *nix to get their work done. Linux is just a convenient option. These people don't really care about the politics, the gpl, etc. If a BSD provided a more convenient option many would migrate.
Have you attended any Linux conferences in recent years. I'm told that Mac laptops are a pretty common thing. There is no shortage of less than true Scotsman.
Did you miss the part about aircraft being ineffective at night? The strategic problem of the campaign, for both sides, was that the United States could dominate the skies during the day but had to rely on surface ships at night.
The US carriers were withdrawn due to fear of their loss.
At the beginning of the campaign the Marines were landed and the fleet carriers withdrew a couple of days later. The loss of air cover caused support ships to be withdrawn. Marines ashore watched the majority of their supplies and equipment sail away with those ships.
Escort carries would make runs to within range of Guadalcanal to deliver aircraft to Henderson field. I believe Henderson was the major source of US airpower in the area for a while.
A little over two weeks after withdrawing the fleet carriers came up to intercept a Japanese carrier force coming south. This battle took place well to the north east of Guadalcanal. Aircraft from Henderson engaged forces in the vicinity of Guadalcanal.
If it wasn't for the surface fleet, including battleships, the marines ashore would have been in a bad way to put it mildly.
The Marines were in a bad way. They had less that a weeks food and light on ammunition too. Fortunately they were able to capture some Japanese food.
And yes, to say the surface fleet -- in particular the destroyers and cruisers -- fought valiantly to protect the Marines is an understatement. At times these destroyers and cruisers attacked vastly superior enemy forces on their routine patrols up the slot because they were the only thing between this force and the Marines.
Incidentally, the turning point of the war didn't happen at Midway, as is often repeated, but rather it happened at Guadalcanal. Midway was a battle, Guadalcanal was a campaign, one which proved the Japanese were not equipped materially or psychologically to fight a long war.
Midway occurred a month earlier and Imperial Japan lost four fleet carriers and more importantly many of their absolutely best air crews. This alone is arguably a valid turning point. At least in a naval sense and the pacific war was essentially a naval war. Now consider how this loss benefited the US at Guadalcanal. The victory at Midway greatly contributed to the victory at Guadalcanal.
Besides the material benefits Midway destroyed the myth of invincibility of the Imperial Japanese Navy and Guadalcanal destroyed the myth of invincibility of the Imperial Japanese Army and Marines. Both played extremely important roles.
Not that it mattered, really, since by the start of the war battleships were really only useful for providing shore bombardment and as AA platforms.
This is dead wrong. Read the history of the Guadalcanal campaign; it was surface ships that carried the day. Aircraft were ineffective at night and are best used in an offensive role, they can't effectively protect ships bringing in troops and supplies
I believe that during parts of the Guadalcanal campaign the aircraft carriers were withdrawn from the area to keep them "safe", well safer. They certainly saw action but toe to toe fleet engagements were being avoided. We were a little short on fleet carriers in 1942.
Also some of the capital ships sunk by aircraft had an assist from surface action. In one of those nighttime surface engagements a US destroyer put 3 torpedoes into a Japanese battleship, greatly reducing her speed. She could not keep up with the retreating fleet and was sunk by US aircraft in the morning when the sun came up.
BB's were used as ground fire support in Nam (a co-worker once told me an apocryphal story about a call for fire that got routed to a BB), but other than showing the colors, they really haven't done anything else since.
They were used in the 1980s to shell various hostile positions in Lebanon after the Marine barracks was attacked. This included killing a Syrian general in his command post.
They were also used in the 1991 Gulf War to shell various Iraqi positions.
Switching video modes **mid-scan line** is NOT some "rare" undocumented unsupported hack.
Google it. People who used it back in the day mention it is not supported, relies on a hardware quirk and does not work on all Apple IIs.
It is about achieving 100% cycle accurate emulation.
And achieving 99.x% is an amazing technical achievement and extremely useful.
AppleWin only *this* year correctly emulates the video hardware
Video has worked quite well for quite a long time. Lacking support for a rare undocumented unsupported hack doesn't represent a major bug in the emulator.
What mainframes lack in hardware volume they make up for with users. :-)
An interesting list: http://en.wikipedia.org/wiki/L...
Not everything needs to be preserved for future historians
With respect, what is and what isn't worth preserving is up to future historians to decide.
Historian don't make such a call, they preserve everything. A cuneiform clay tablet with a receipt for a shipment of wheat is preserved as if it had the story of Gilgamesh on it.
Decisions of what to preserve are more the domain of invading Vandals and the city residents trying to hide things from them.
A 15 year old datafile or binary doesn't sound nearly as impressive as it used to.
Apple II emulators and disk images may have passed that 15 year mark.
yeah, GOTO the end and do some cleanup and/or error reporting, which is common to all the gotos. I don't see a problem with that. It's clear, simple and avoid heinous if/else deep nestings.
The problem is goto is not just used in the "heinous" nesting cases. And "heinous" varies with the length of the conditional blocks. If there are many levels but it fits on a screen or two, perhaps leans toward if. If they are stretching for many screens worth of code maybe lean towards goto.
The problem with goto is that the conditional code is at the same nesting level as the unconditional code so it makes it less apparent what code is conditional. Using goto should be the exception, to substitute a smaller problem for a larger problem, not the rule, substituting a small problem for no existing problem at all (minor nesting for short durations).
I have written a lot of code in my life - Thousands of projects, millions of lines of code (for whatever that means), across a dozen languages and twice as many platforms. And outside Assembly (and DOS batch, if you want to count that as a "language"), I have not ever encountered a situation where I thought to myself "gee, I could really improve this with a GOTO, if only everyone wouldn't laugh at me for it".
I'm with you there.
I have, however, removed some pretty heinous uses of GOTO from other people's code. The most common one I see, people can't quite bring themselves to "return" from an error handler in the middle of a function, so they instead GOTO the end of it. Really??? Talk about missing the forest for the trees!
You are missing the forest of testing and debugging. :-) Its easier if you just have one place to set a breakpoint.
I think the indentation is evidence that it's very difficult to make code look good in Slashdot. Especially a quick off-the-cuff code example meant to illustrate a point.
The indentation I'm referring to is not the post's indentation. I don't bother with indenting code in posts either. What I am referring to is the normal source code indentation that appear in the body of an if statement. In the alternative goto scenario this conditional block appear inline with the header code in the source. Read the periods in the following code as spaces:
....[body]
[header]
if (cond) {
}
[header]
if (! cond) goto bailout:
[body]
bailout:
No, the indentation, or lack therof is an indication, a stromg one even, that YOU are an idiot. The parent posted a quick example of some uncomplete C code in a forum, like /. and has to fiddle with tags and what ever to format it properly and you believe he intentionally indentated it 'wrong'? That makes you an idiot. Why don't you simlly asume the most likely cause is an formatting error?
The indentation I am referring to is not the indentation of comments in a discussion forum, look at my code samples in other responses in this topic. I don't bother with indentation either.
....[body]
What I am referring to is the normal indentation of the body of an IF statement in source code. The use of goto causes the conditional part of the code to not be indented, it appears inline with the header code. Read the periods in the following code as spaces:
if (cond) {
}
if (! cond) goto bailout:
[body]
bailout:
Before tossing the word "idiot" around you might want to make sure you understand what is being discussed.
Such indentation is important
and irrelevant to this discussion.
No. The indentation is evidence that the original goto advocate did not think carefully before breaking the rule since the coding style fails at its stated intent.
Some programmers take this idea to an extreme and even write code such as:
int abs(int x) {
int retval;
if (x >= 0) retval = x;
else retval = -x;
return retval;
}
In this case, multiple return statements would make the code simpler, not harder to understand.
Removing one line of source code does not necessarily make code simpler and more understandable, it merely make the source code shorter. It is only more understandable when the shorter code is acting in the default / more common manner. And for functions the more common manner is a single return at the end. So while quite readable because of its brevity it is doing the less common thing and therefore requires a little more cognitive processing while reading.
Now in addition to being more readable with that one extra line, the common exit point, there is also the advantage of breakpoints when debugging. Now I am speaking in general and you may argue that in this specific case abs() is unlikely to need a breakpoint. If so I will counter that the function should still have a single exit point, as in:
int abs(int x) {
return (x >= 0) x : -x;
}
In all three implementations discussed it doesn't really matter what the source looks like beyond readability, the compiler will likely generate the same code.
How many levels of nested if blocks are you willing to tolerate solely in the name of avoiding a single use of the keyword goto?
Actually each nested level would need its own goto.
And I probably wouldn't start thinking about goto until 3 levels, and in many such situations I find a way to refactor things without goto. I am assuming large multiscreen blocks of code with 3. As the blocks get shorter and most/all the nesting appears on a single screen then the number goes up.
Keep in mind that goto has a readability penalty in that the lack of indentation masks that a block of code is conditional. I guess I'm weird but I like to write code with the intent of handing it off to someone else so I can move on to something new, but I want to make things easier for the next person.
Also keep in mind that for some compilers the issue is more than a goto statement appearing in source code. The compiler may not attempt certain optimizations in code when a goto is encountered.
There was supposed to be some cleanup code for the database_t object at the end of the function, but forgot to add it while playing with the code tag. :-)
Many of us assumed there was such cleanup code when we found the example lacking. Perhaps if there had been bailouts from multiple levels of nested code, but even then goto is not necessarily the best option.
The academics are always on a quest for purity, people who work for a living want to get things done as cleanly and quickly as possible.
Banging out code quickly during initial development is rarely getting things done quickly in the long run. One must also consider maintenance and future updates and enhancement, often made by someone other than the initial developer, which is where time gets lost due to mistakes during initial development. Many have good intentions of going back and cleaning up initial code but actually getting a chance to do so is not as common as many wish.
The general idea is that misuse of goto leads to buggier code, and that bugs are less expensive the earlier they are found, and ideally avoided in the fist place by good coding practices. So banging out code quickly can be counterproductive.
As for cleanly coded, what is cleaner and more readable about masking that fact that a block of code is conditional by avoiding indentation, which is all that the offered goto example is doing. Perhaps if the example had bailouts from several levels of nesting, but even in such situations goto is not necessarily the best way to go.
No, he's objecting to the example offered as an appropriate use of goto. It wasn't an appropriate use. It fails at the stated goal, making the code more readable. It makes it less readable by avoiding the indentation of conditional code.
If there had been a different example with nested code at various levels bailing out with goto's then maybe it would have been appropriately used, not necessarily but maybe. However as offered the example was a good example of when *not* to use a goto.