My understanding was that DNT has mostly been a failure, though I don't know how much of that has to do with IE's default behavior. Am I wrong about that? Are there lots of sites out there honoring the DNT setting?
Some states in the US allow you to choose your electricity provider - it's still coming down the utility company's power lines regardless, but you can buy from a different company.
Has nothing to do with "holy prophets" or anything like that. I've done programming with and without goto, and goto is (usually) bad. I knew this before I ever heard of Dijkstra.
The study says that goto has not been a problem BECAUSE it is not being used inappropriately. Inappropriate use is exactly what Dijkstra cautioned against. So the study isn't saying anything other than that people did exactly what Dijkstra suggested they should do.
Stop teaching students to avoid goto so that it takes hold again, leading to bad code all over the place, so that we can empirically prove that it's a bad idea? How about we just don't do that and avoid the problem to begin with.
Unrestrained use of goto was demonstrated to be a bad idea decades ago, that's why Dijkstra recommended against it in 1968.
The point is that people do not generally use goto in these harmful ways because they've been warned not to. That's what skews the study in the summary. You're going to have a hard time finding that empirical evidence of how goto can lead to bad code, because one of the first things coders are taught in today's programming courses is, "Do not use goto." Meaning that the inexperienced coders who would be having these problems are avoiding the problem by not using goto. Those who are using goto are those who know the risks and how to mitigate them.
So, in the absence of conclusive data either way, I can only argue from my experience. I'm a programmer who has used both goto and more tightly-controlled flow control, and in my experience goto is not a good option for the vast majority of cases (particularly for inexperienced coders).
Good coders can definitely mitigate the risk of goto statements. However, goto makes it easier to really screw things up if you don't 100% know what you're doing, or if you make a mistake.
Not sure what you're getting at with compilers. Once you translate a C program to assembler/machine code, most of your loops, switches, breaks, etc. all become effectively the same as goto. The problem with goto has nothing to do with the compiler, it has to do with the human being trying to read, write, and debug the code before it goes through the compiler, and with catching errors at compile-time with sane control flow, whereas with goto it will make it through the compiler and become a runtime error.
You complain about the giant if/for nests, but those huge nests will almost always become worse if you start throwing gotos in there.
Yes, goto is a tool like anything else. But it is not a tool for the common case or the common coder. Most of the time, if you're asking yourself, "should I use goto here or something else?" the answer is the something else.
If you think modern code is horrible spaghetti (I disagree, for the record), bear in mind that it would be considerably worse with indiscriminate use of goto.
Sure, code has complex code flow. When code is designed to solve complex problems, it's going to be complex. Complexity is okay. The key is being able to make complex code clear, readable, and less error-prone. Goto is less clear and readable because it's not obvious what a goto statement is meant to do. When you see a while loop, or a break statement, or a function call, you can get an idea of what it's doing just by the nature of what statement is being used. Goto can be used to cover any of those cases, so it's more difficult to follow. Because of this, it's also easier to make a difficult-to-debug mistake!
99% of the time, when you could use a goto statement in code, there is another, better way of doing the same thing. An expert coder will be able to effectively use it in a way that limits the risk, but for a novice or intermediate coder, or even many experienced ones, it is much easier to muck everything up using goto vs. using other control flow tools.
Nah, I think it's clear that Microsoft is not counting in decimal like the rest of us. Sure, they start with 1, 2, 3 like you'd expect, but then after that it's 3.1, 3.11, 95, 98, 2000, XP, Vista, 7, 8, 10, 365. The next version will be something like 13.111.Xylophone. This is not Base 10. This is Base Bob.
"burgerbecky" is Rebecca Heineman, who programmed The Bard's Tale III and Dragon Wars, two of my favorite old computer RPG's. I had no idea she worked on 3DO Doom.
Small school. The top CS guy was my advisor and I did talk to the IS prof who was teaching the course. The CS and IS departments were involved in some kind of interdepartmental pissing contest. I believe a database class for CS students was introduced shortly after I graduated. They knew about the issue, but it was my senior year when this came up, so basically just bad timing for me.
Networks wasn't optional for us, we had to take at least a semester of it.
Yeah, the database thing is a big issue. In college, I actually tried to sign up for a database management class and couldn't, because it was in the Information Systems department instead of the CS department, and I hadn't taken the official pre-requisites. (I had taken a similar class in CS, but that didn't count. From everything I heard, the CS version was harder, but who knows.) So I had to get on-the-job training to understand databases, and it's still one of the weaker points in my skillset.
In my experience, successful CS students are typically solid programmers before starting the curriculum, or become solid programmers early in their studies. (If they don't, they change majors.) Good CS programs go beyond just programming to teach theory, but taking courses in programming language design and analysis of algorithms is what turns decent programmers into great programmers. That's why, while a degree in CS isn't a degree in programming per se, CS students do tend to be better programmers and are well-prepared for real-world coding.
Web development? Keep learning Java. You will rarely ever have to worry about memory management. Learning C won't make you a better Java programmer, and there are plenty of jobs for people with Java backgrounds. Of course, you should also know HTML/CSS etc. if you're going this route.
Video games? Learn C and C++, probably in that order. Java isn't going to cut it, you'll need to learn things like memory management and graphics programming. However, the object-oriented programming stuff you learn in a Java-centric curriculum will still be very helpful in C++ (or C# if you go in that direction), so you have a solid base to work with.
Embedded systems? You're in either the wrong school or the wrong major for that, you need to focus on C and Assembler for that. Completely different world from Java.
You get the idea. Figure out what you plan to do with your career if you don't already know (in a broad sense, you don't have to nail down a specific job), and steer your studies that way. If you want to keep your options open, teach yourself some basic C or C++ and see if it's right for you. If you can't figure out how to manage pointers, then you know what type of programming not to get into.
Slashdot Mirror
I know, spelling/grammar police and all, but boy does that make me twitch.
My understanding was that DNT has mostly been a failure, though I don't know how much of that has to do with IE's default behavior. Am I wrong about that? Are there lots of sites out there honoring the DNT setting?
Glad I wasn't the only one thinking this.
Some states in the US allow you to choose your electricity provider - it's still coming down the utility company's power lines regardless, but you can buy from a different company.
Has nothing to do with "holy prophets" or anything like that. I've done programming with and without goto, and goto is (usually) bad. I knew this before I ever heard of Dijkstra.
The study says that goto has not been a problem BECAUSE it is not being used inappropriately. Inappropriate use is exactly what Dijkstra cautioned against. So the study isn't saying anything other than that people did exactly what Dijkstra suggested they should do.
Stop teaching students to avoid goto so that it takes hold again, leading to bad code all over the place, so that we can empirically prove that it's a bad idea? How about we just don't do that and avoid the problem to begin with.
Unrestrained use of goto was demonstrated to be a bad idea decades ago, that's why Dijkstra recommended against it in 1968.
The point is that people do not generally use goto in these harmful ways because they've been warned not to. That's what skews the study in the summary. You're going to have a hard time finding that empirical evidence of how goto can lead to bad code, because one of the first things coders are taught in today's programming courses is, "Do not use goto." Meaning that the inexperienced coders who would be having these problems are avoiding the problem by not using goto. Those who are using goto are those who know the risks and how to mitigate them.
So, in the absence of conclusive data either way, I can only argue from my experience. I'm a programmer who has used both goto and more tightly-controlled flow control, and in my experience goto is not a good option for the vast majority of cases (particularly for inexperienced coders).
And why do you think this is bad practice?
Good coders can definitely mitigate the risk of goto statements. However, goto makes it easier to really screw things up if you don't 100% know what you're doing, or if you make a mistake.
Not sure what you're getting at with compilers. Once you translate a C program to assembler/machine code, most of your loops, switches, breaks, etc. all become effectively the same as goto. The problem with goto has nothing to do with the compiler, it has to do with the human being trying to read, write, and debug the code before it goes through the compiler, and with catching errors at compile-time with sane control flow, whereas with goto it will make it through the compiler and become a runtime error.
You complain about the giant if/for nests, but those huge nests will almost always become worse if you start throwing gotos in there.
Yes, goto is a tool like anything else. But it is not a tool for the common case or the common coder. Most of the time, if you're asking yourself, "should I use goto here or something else?" the answer is the something else.
If you think modern code is horrible spaghetti (I disagree, for the record), bear in mind that it would be considerably worse with indiscriminate use of goto.
Sure, code has complex code flow. When code is designed to solve complex problems, it's going to be complex. Complexity is okay. The key is being able to make complex code clear, readable, and less error-prone. Goto is less clear and readable because it's not obvious what a goto statement is meant to do. When you see a while loop, or a break statement, or a function call, you can get an idea of what it's doing just by the nature of what statement is being used. Goto can be used to cover any of those cases, so it's more difficult to follow. Because of this, it's also easier to make a difficult-to-debug mistake!
99% of the time, when you could use a goto statement in code, there is another, better way of doing the same thing. An expert coder will be able to effectively use it in a way that limits the risk, but for a novice or intermediate coder, or even many experienced ones, it is much easier to muck everything up using goto vs. using other control flow tools.
Nah, I think it's clear that Microsoft is not counting in decimal like the rest of us. Sure, they start with 1, 2, 3 like you'd expect, but then after that it's 3.1, 3.11, 95, 98, 2000, XP, Vista, 7, 8, 10, 365. The next version will be something like 13.111.Xylophone. This is not Base 10. This is Base Bob.
I think I just pulled my hamstering while running away from this conversation.
There was more than one mean comment in that thread.
"burgerbecky" is Rebecca Heineman, who programmed The Bard's Tale III and Dragon Wars, two of my favorite old computer RPG's. I had no idea she worked on 3DO Doom.
That's possible, of course, but is it really hard to believe that an explosion would have prompted people to back out?
Yes, I'm aware that Flash itself is not a language. It still needs to go away. ActionScript can go with it.
Also on the list: Adobe Flash. Please let them be correct about this. No more Flash. Anywhere. Ever.
Small school. The top CS guy was my advisor and I did talk to the IS prof who was teaching the course. The CS and IS departments were involved in some kind of interdepartmental pissing contest. I believe a database class for CS students was introduced shortly after I graduated. They knew about the issue, but it was my senior year when this came up, so basically just bad timing for me.
Networks wasn't optional for us, we had to take at least a semester of it.
Yeah, the database thing is a big issue. In college, I actually tried to sign up for a database management class and couldn't, because it was in the Information Systems department instead of the CS department, and I hadn't taken the official pre-requisites. (I had taken a similar class in CS, but that didn't count. From everything I heard, the CS version was harder, but who knows.) So I had to get on-the-job training to understand databases, and it's still one of the weaker points in my skillset.
In my experience, successful CS students are typically solid programmers before starting the curriculum, or become solid programmers early in their studies. (If they don't, they change majors.) Good CS programs go beyond just programming to teach theory, but taking courses in programming language design and analysis of algorithms is what turns decent programmers into great programmers. That's why, while a degree in CS isn't a degree in programming per se, CS students do tend to be better programmers and are well-prepared for real-world coding.
Web development? Keep learning Java. You will rarely ever have to worry about memory management. Learning C won't make you a better Java programmer, and there are plenty of jobs for people with Java backgrounds. Of course, you should also know HTML/CSS etc. if you're going this route.
Video games? Learn C and C++, probably in that order. Java isn't going to cut it, you'll need to learn things like memory management and graphics programming. However, the object-oriented programming stuff you learn in a Java-centric curriculum will still be very helpful in C++ (or C# if you go in that direction), so you have a solid base to work with.
Embedded systems? You're in either the wrong school or the wrong major for that, you need to focus on C and Assembler for that. Completely different world from Java.
You get the idea. Figure out what you plan to do with your career if you don't already know (in a broad sense, you don't have to nail down a specific job), and steer your studies that way. If you want to keep your options open, teach yourself some basic C or C++ and see if it's right for you. If you can't figure out how to manage pointers, then you know what type of programming not to get into.
Why are you writing numbers in binary?
Looks like MS is looking to continue the tradition of good odd-numbered Windows versions to make up for the bad even-numbered versions.
Bochs? Surprised you didn't just use DOSBox.