Whatever, man, take your hate speech somewhere else, you language nazi. I'm tired of your doublespeak and your political genocide. Why do you hate America? If I had mod points, I'd censor you so hard for trying to destroy the Constitution or write on it in crayon. Take your religion of hatred and violence, and your Orwellian spy tactics and theft of our civil liberties, and get out of here!
Clearly, not wanting to depose their leaders and allowing them freedom of religion is "accepting gay bashing" from muslims. If they really were against gay bashing, they'd restrict the freedoms of every single person who did so!! If they really respect gays, they'd shut down all the mosques, even the ones of the Muslims who didn't bash gays: because the others did, it proves their religion is hateful!!
I'm not saying they don't belong, I'm saying that spending, say, a week covering them is overkill. Say a few sentences about it, point students to where they need to go, and they can figure it out. Maybe a "oh and by the way if you do X in program Y, this happens. Moving on..."
If they need to know about compiler options beyond the basics, they are smart enough to know what they are looking for and can read man pages. For example, if in an advanced course your students need to omit frame pointers or create archives or whatever, the professor would just need to describe what they have to do. The rest is in the documentation.
It's because IDEs are so simple to use for basic purposes that they don't need to be taught in beginning courses, and because they have so much potential complexity that you could teach an entire class on them. They also have so many features that if you start teaching them in an intro to programming course, you might get too caught up, you teach students too much about IDEs and not enough about programming.
So to review: You say that we should teach students IDEs because they can't figure it out for themselves, and I say that they can, and then you go on to show me how easy a using an IDE is for simple tasks and how anyone can figure it out.
As a second point, I said that IDEs have so much extra crap that you would spend too much time on them if you taught all the "advanced features" in an intro course, and therefore they should be moved to a separate course, probably on Software Engineering or Software Design or something.
Lastly, I took an introductory course to Java in college. I, in great shame, admitted I was a 3rd year when I took it, but explained that it was a blowoff course because my GPA was suffering. My point was that other, beginner programmers had no trouble with compiling and running Java applets all by themselves with minimal instruction from the professor (maybe 15 minutes out of the whole course).
This program (the Windows standalone) is very much broken and doesn't seem to work at all on my Japanese copy of Windows XP. When I brought up the main screen and tried highlighting things, there was window drawing problems making the program look completely borked. Plus, what should I do if I want to run a shell command 'Del?' It might be in the docs, but by the time I might have gotten to documentation on that, the interface was destroyed.
That's not old fashioned. The vast majority of a professional musician's income comes from the concert and merchandise sold at the concert. Only the hugest names rake in a lot of money from CD sales.
We're not teaching "general computing theory of everything" courses here. We're teaching people about computers, and dividing it up into several logical parts. If I'm trying to teach my students what the hell a queue is, I don't give a rat's ass about optimization flags. If I am teaching them how to program networking code, I don't care about debugging code. That information might be useful, but save them for another class. You're saying to muck up every computer class with the Computing Theory of Everything.
You don't need an entire course on IDEs, nor do you need them to be taught to non-programmers. Typically, non-programmers will only be using interfaces that are very easy to learn - Java, Javascript, HTML, CSS, and PHP. Some of the stuff you mention isn't worth more than a fleeting mention. For example: "Oh by the way, type -O2 on the command line to optimize your code" or "Check this option to optimize your code" or even better "Check your compiler's manual to find out how to turn the optimize flag on." This is all small stuff that can be learned by experience. Don't sweat the small stuff, don't spend more than a class period on it.
Basically there is a place for IDEs in higher-level courses, but you can really bog a class down and get sidetracked trying to put one in. The original question was about an Intro to Python and an Intro to Java course - neither of which requires any difficult setup or IDE instruction beyond a few minutes of class time to be able to solve Introductory level homework.
When I did my undergrad we had an intro class that was pass fail and taught and tested you on your ability to do the basics including use Explorer and Office (Excel and Word) properly.
No offense, but I would have shot myself. That course has no place in a CS curriculum for concentrators.
For what it's worth, students were pointed in the right direction. The professors put up tutorials online, made themselves available after class (or made their TAs do it) for people that didn't get it. But we didn't waste time making it part of the curriculum. You need to expect some amount of computer competency before you can teach people how to program. Those that don't have it can spend the extra hours learning it. Why should a calculus class spend time reviewing algebra?
You're absolutely right, though - teaching what the compiler does would be a good topic. For a compilers course. But in an introductory programming course, informing the student that the compiler takes program code and creates something the computer can run is all you need. Here's a link to a program or three that you can use, now do your homework. Then, when the student is a 3rd year, you can put it all together and make a project that works from start to finish. But by that point, they should know what tools to use. The hope is that, no matter what fancy new time-saving tool people are using in the future, your students can learn to assimilate it and use it properly. I feel that if you teach your students proper programming fundamentals, they should be able to run any IDE they want with a minimum learning curve.
I know full well what a compiler is, and if you remember, I said that the course was using Dr. Scheme - an interpreter for Scheme that was documented well enough that students could download it, figure out what buttons make the program go, and start using it. It was technically an IDE, but we didn't spend any time learning how to use it. You could have done all your programming in Notepad if you wanted to, and you could have done just as well. I believe we pointed to other Scheme interpreters too, but the point is that Dr.Scheme never became a topic in the class.
It's no harder clicking a compile button than typing in an obscure command line you don't understand.
Then why bother teaching it?;)
Using IDEs can be very simple, but showing how to use the "advanced" features can take quite a bit of instruction - instruction that has no place in a class that isn't teaching you about IDEs.
In the Java class, most students had never seen a program before. It was a blowoff class because it was for non-programmers. Yet we didn't spend any time learning Java tools, or Java IDEs, or anything like that.
I never claimed the students wouldn't receive any help - only that it doesn't need to become part of the curriculum because it's not necessary. I never said IDEs were unnecessary - only that IDEs were unnecessary in the classroom, where things never get complicated enough to require one. Students should be able to write code on paper. God knows I had to.
I seriously think that getting a complier up and running, on any platform, with the proper links given to the student on where to find said compiler, should be enough for anyone with half a brain. Then again, since your classmates had difficulty figuring out how to run Microsoft Office, maybe I'm underestimating the idiocy and computer literacy of incoming CS or programming students. I say we cull those without computer literacy. If they really want to program but don't know how to use Explorer, they need to take a course on that first before beginning programming, instead of wasting the department's time.
I said this in another part of this big thread: why give your students calculators when you are teaching them to multiply?
I disagree. It's a manual labor thing - the ancient technique of making apprentices do menial tasks to teach them still fits with computer programming. Make them write those get and set routines. Make them implement quick sort themselves. When they realize that, "hey this sucks, can't we automate this," they will become enlightened.
Then again, the student working on that project might be in a Software Design class, in which case, sure, show them all the different IDEs and such. But any good teacher will take into account the amount of time each student will be spending, and probably make the project harder or easier depending on if they know that the student has access to time-saving tools.
But students rarely have to write programs that are that complex that that kind of stuff is necessary. When it is necessary, generally some kind of tools are introduced and used - but they don't become part of the curriculum. For example, in my OS class, we couldn't use an IDE. In other classes, we were told to use gdb - but we spent probably just one class on the details. Probably less.
I think there's actually a better tool to help students understand complicated parts of OOP - a whiteboard.
Intuitive understanding of OOP comes from programming in it, not from having an IDE to play with. When students are taught OOP, the professor is the one that dictates the pace and method that he gives his students an intuitive understanding with.
Debugging is a great way to catch errors, and IDEs are a good way to make more readable code, but intuitive understanding is going to come from being able to write a program on paper without any fancy toys.
And refactoring just looks like an automated way to fix your code - having the computer help you so that when you do rewrite your code you don't break it because you weren't paying attention or something equally human. But why give our students calculators when they are learning how to multiply?
It makes perfect sense, but the point is that method needs to be fixed, sped up, something so that either it's easier to use something from "CVS" or the builds come out faster. Getting the fixed code to the users faster would allow for better testing, resulting in a better product. If users can't use your CVS, it's that much longer for your bug fixes to be tested, slowing down the whole project.
So do you want professors to help set up students' net connections? You want to teach them how to navigate Windows? Do you need to teach them how to turn on their computers? Where do you draw the line before you say "You're big kids now, you can figure out how to run the 'compile' command on your own. If you want to use an IDE, have fun!" Non-computer students are expected to use web interfaces to do non-computer classes. If kids have trouble with getting stuff to compile, the professor^W TA is there, but it does not need to be part of the curriculum. Now, my point was twofold - one, that students can figure out how to compile code with very little instruction. Often just a link works. But two, that IDEs should not be taught because they are above and beyond the scope of most programming courses. So, yes, if IDEs were being used in the class, they are complicated enough that instruction might be helpful. But in most classes, IDEs are not necessary and detract from what students are being taught. They need to learn to write code, not "Solutions" or whatever the hell they are calling them now, unless the course is specifically for that.
I did an intro to Java class as a blowoff class (I was a third-year CS), but not once did the professor in class tell us how to run the darn thing. That's what TAs are for:) But there doesn't need to be any "platform" because code is just that.
They don't have the maturity level to be doing self paced learning.
They can only be taught by making them do just that.
I would not expect a student to be able to even begin to know how to work a simulator. But I would expect them to be able to figure out how to start the program or be able to install it and run it on their computer.
Plus your analogy is all off, anyway. When you put a student in a simulator, let's say for a commercial airline, you are teaching them to fly the aircraft that simulator is simulating. Do you want to also include flight attendants, hijackers, angry travellers, company politics, etc.? No, you're just learning how to fly. In the same respect, you're just learning how to program, not use an IDE. Why include all that extra crap when students are just going to want to be able to do it their way, anyway?
About the download link: You should at least be able to download Dr. Scheme and figure out how to run the goddamn thing without any instruction from the professor.
"You haven't paid a thing for it; what do we owe you?" seems to be the cry of those developers who are faced with the fact that users don't like their project. You're right, you don't owe anything to users. But you know that you program for them. If you programmed for yourself, you wouldn't bother with configure files and auto-detection or any of that crap - it would just work on your computer. When users like your product, you love it, but as soon as they start complaining, "You get what you pay for!" Kind of reminds me of the Simpsons: "They've given you hours of entertainment for free...what else do they owe you?" But the fact is they make the show for the viewers, and when the viewers demand that their product be good or they stop using it, all of a sudden it's like you didn't even expect people to be partaking in your creation.
It comes down to this: you don't have to support users. Fuck 'em. But guess what, fuck you if you complain about some talking head saying how your product isn't ready for the big time. They're actually helping you - why don't you accept their criticism.
The major problem with CVS is this:
"I have a bug" "That bug is fixed in CVS"::downloads CVS:: "This CVS doesn't compile!" "Sorry, we don't offer any guarantees with CVS"
Yes, the developers can't do anything if they've fixed the bug already. But it's frustrating to users, and unless you wanna say "fuck the users," the solution is obvious: fix the development process so "CVS" works - increase the speed at which users can use software. That's the major point the guy is making - software development is too slow. And I don't think it necessarily has to be fixed by increase developer man-hours. I think that too little thought is spent on preparing software for deployment, and that if a project put more of its focus on that, it would be more successful.
Here's one idea that might help: why the hell are people still using make and its evil cousins automake and autoconf?? You need serious gurus just to wade through all that muck. Everyone should check out SCons, because it makes life about a million times easier.
Sure you can do it without an IDE. "Refactoring" I think is a buzzword anyway for "cleaning up a rough draft" or "good coding practices." It's certainly made easier with an IDE, but student projects are never large enough to require one. I think teaching IDEs would be great for classes that teach software design or other higher level concepts, but not other programming classes (OS, compilers, etc), and certainly not intro programming courses.
When was the last time you wrote a serious math proof and wrote it all in one go on a piece of paper? Killing trees isn't all that bad.
I disagree about the ordeal. I think it's necessary in an introductory course to break people of any preconceptions that they have of programming. I personally was taught Scheme as an introductory course, and all they gave us was a link to Dr. Scheme - we didnt have a single instruction on how to use it.
This is a little simplified, but if you're doing a programming course (NOT a software engineering or design course), you should be teaching people how to compile their program but not how to use make. But that should even be done in a neutral manner. It all falls under the heading that you should be teaching your students principles and not programs. Plus, your students, pointed in the right direction, should be able to follow tutorials on their own.
Why have one at all? Unless your class is on the specific IDE or "Software Development Techiniques", why chain them to a specific technology? Let your students figure out how to run the damn editor. If it wasn't so tedious, I'd say have your students turn in assignments on paper. You are teaching programming, not a program, no matter how community college you are. Give your students a chance to figure something out for themselves and they will become smarter.
What's the big deal? So they got spooked by Chinese PCs - fair enough. When you are in defense, you play the "worst-case-scenario" game. No American companies were hurt, no civil rights were harmed - I don't see the problem. So we got a look inside the Defense Department's paranoia, but it's a harmless paranoia and implies no harmful side effects, corollaries, slippery slopes, or other cliches.
This article should be tagged as "hype". This should be something people tag all articles that are oversold by the Slashdot headline.
Right after that comment I said: "and web pages are a good example of this."
The method that you pointed out is great. It is a huge win. It does a great job of applying the three concepts I mentioned, and also happens to separate logic from presentation. But I think that in computer programming in general, separating the two is not always the best idea. In some cases, the distinction is artificial and therefore any kind of separation is going to be forced. It's usually those cases where there is "too much" logic and when you try to separate out the presentation, it just becomes as tangled of a mess as it was before.
My point was really that "separate logic and presentation" is somewhat misleading and not as general as the concepts I pointed out.
Unfortunately, forcing employers to provide insurance puts far too much strain on small business owners. They won't be able to support their employees and it will bring them down.
People will always tell you to "separate logic from presentation" and that is good advice - to a certain extent. I don't think that this is correct all the time, however, because it is not a correct statement per se because the two cannot always be separated. However, they usually can and usually are, and web pages are a good example of this. But what does "separate" mean? Does it mean physically moving your presentation to another file, generating it, etc.? There are many different ways, all of which work best in certain situations.
Here's what you should worry about instead: 1) Is the program readable? 2) Can you easily make changes in the program without having to change too many other parts of it? 3) Are you having to rewrite the same code too much?
Those are some pretty basic computer programming design concepts, and if you apply those, you'll find that the answer should be pretty clear. Just keep everything clean and life will be happier.
Apparently, Lance
was drunk during the event and thought he had some kind of big scoop when really he was too wasted to understand what was going on at the event.
Slashdot Mirror
Reading the actual blog, it appears the English teachers there ain't teaching 'em shit.
Now it all makes sense!! Joliet is pretty much about the worst terrible place in Illinois you can go.
Jef Raskin's The Humane Interface
Whatever, man, take your hate speech somewhere else, you language nazi. I'm tired of your doublespeak and your political genocide. Why do you hate America? If I had mod points, I'd censor you so hard for trying to destroy the Constitution or write on it in crayon. Take your religion of hatred and violence, and your Orwellian spy tactics and theft of our civil liberties, and get out of here!
Clearly, not wanting to depose their leaders and allowing them freedom of religion is "accepting gay bashing" from muslims. If they really were against gay bashing, they'd restrict the freedoms of every single person who did so!! If they really respect gays, they'd shut down all the mosques, even the ones of the Muslims who didn't bash gays: because the others did, it proves their religion is hateful!!
I'm not saying they don't belong, I'm saying that spending, say, a week covering them is overkill. Say a few sentences about it, point students to where they need to go, and they can figure it out. Maybe a "oh and by the way if you do X in program Y, this happens. Moving on..."
:)
If they need to know about compiler options beyond the basics, they are smart enough to know what they are looking for and can read man pages. For example, if in an advanced course your students need to omit frame pointers or create archives or whatever, the professor would just need to describe what they have to do. The rest is in the documentation.
It's because IDEs are so simple to use for basic purposes that they don't need to be taught in beginning courses, and because they have so much potential complexity that you could teach an entire class on them. They also have so many features that if you start teaching them in an intro to programming course, you might get too caught up, you teach students too much about IDEs and not enough about programming.
So to review:
You say that we should teach students IDEs because they can't figure it out for themselves, and I say that they can, and then you go on to show me how easy a using an IDE is for simple tasks and how anyone can figure it out.
As a second point, I said that IDEs have so much extra crap that you would spend too much time on them if you taught all the "advanced features" in an intro course, and therefore they should be moved to a separate course, probably on Software Engineering or Software Design or something.
Lastly, I took an introductory course to Java in college. I, in great shame, admitted I was a 3rd year when I took it, but explained that it was a blowoff course because my GPA was suffering. My point was that other, beginner programmers had no trouble with compiling and running Java applets all by themselves with minimal instruction from the professor (maybe 15 minutes out of the whole course).
ahh slashdot
This program (the Windows standalone) is very much broken and doesn't seem to work at all on my Japanese copy of Windows XP. When I brought up the main screen and tried highlighting things, there was window drawing problems making the program look completely borked. Plus, what should I do if I want to run a shell command 'Del?' It might be in the docs, but by the time I might have gotten to documentation on that, the interface was destroyed.
Quite unprofessional.
That's not old fashioned. The vast majority of a professional musician's income comes from the concert and merchandise sold at the concert. Only the hugest names rake in a lot of money from CD sales.
We're not teaching "general computing theory of everything" courses here. We're teaching people about computers, and dividing it up into several logical parts. If I'm trying to teach my students what the hell a queue is, I don't give a rat's ass about optimization flags. If I am teaching them how to program networking code, I don't care about debugging code. That information might be useful, but save them for another class. You're saying to muck up every computer class with the Computing Theory of Everything. You don't need an entire course on IDEs, nor do you need them to be taught to non-programmers. Typically, non-programmers will only be using interfaces that are very easy to learn - Java, Javascript, HTML, CSS, and PHP. Some of the stuff you mention isn't worth more than a fleeting mention. For example: "Oh by the way, type -O2 on the command line to optimize your code" or "Check this option to optimize your code" or even better "Check your compiler's manual to find out how to turn the optimize flag on." This is all small stuff that can be learned by experience. Don't sweat the small stuff, don't spend more than a class period on it. Basically there is a place for IDEs in higher-level courses, but you can really bog a class down and get sidetracked trying to put one in. The original question was about an Intro to Python and an Intro to Java course - neither of which requires any difficult setup or IDE instruction beyond a few minutes of class time to be able to solve Introductory level homework.
For what it's worth, students were pointed in the right direction. The professors put up tutorials online, made themselves available after class (or made their TAs do it) for people that didn't get it. But we didn't waste time making it part of the curriculum. You need to expect some amount of computer competency before you can teach people how to program. Those that don't have it can spend the extra hours learning it. Why should a calculus class spend time reviewing algebra?
You're absolutely right, though - teaching what the compiler does would be a good topic. For a compilers course. But in an introductory programming course, informing the student that the compiler takes program code and creates something the computer can run is all you need. Here's a link to a program or three that you can use, now do your homework. Then, when the student is a 3rd year, you can put it all together and make a project that works from start to finish. But by that point, they should know what tools to use. The hope is that, no matter what fancy new time-saving tool people are using in the future, your students can learn to assimilate it and use it properly. I feel that if you teach your students proper programming fundamentals, they should be able to run any IDE they want with a minimum learning curve.
I know full well what a compiler is, and if you remember, I said that the course was using Dr. Scheme - an interpreter for Scheme that was documented well enough that students could download it, figure out what buttons make the program go, and start using it. It was technically an IDE, but we didn't spend any time learning how to use it. You could have done all your programming in Notepad if you wanted to, and you could have done just as well. I believe we pointed to other Scheme interpreters too, but the point is that Dr.Scheme never became a topic in the class.
Then why bother teaching it?
Using IDEs can be very simple, but showing how to use the "advanced" features can take quite a bit of instruction - instruction that has no place in a class that isn't teaching you about IDEs.
In the Java class, most students had never seen a program before. It was a blowoff class because it was for non-programmers. Yet we didn't spend any time learning Java tools, or Java IDEs, or anything like that.
I never claimed the students wouldn't receive any help - only that it doesn't need to become part of the curriculum because it's not necessary. I never said IDEs were unnecessary - only that IDEs were unnecessary in the classroom, where things never get complicated enough to require one. Students should be able to write code on paper. God knows I had to.
I seriously think that getting a complier up and running, on any platform, with the proper links given to the student on where to find said compiler, should be enough for anyone with half a brain. Then again, since your classmates had difficulty figuring out how to run Microsoft Office, maybe I'm underestimating the idiocy and computer literacy of incoming CS or programming students. I say we cull those without computer literacy. If they really want to program but don't know how to use Explorer, they need to take a course on that first before beginning programming, instead of wasting the department's time.
I said this in another part of this big thread: why give your students calculators when you are teaching them to multiply?
I disagree. It's a manual labor thing - the ancient technique of making apprentices do menial tasks to teach them still fits with computer programming. Make them write those get and set routines. Make them implement quick sort themselves. When they realize that, "hey this sucks, can't we automate this," they will become enlightened.
Then again, the student working on that project might be in a Software Design class, in which case, sure, show them all the different IDEs and such. But any good teacher will take into account the amount of time each student will be spending, and probably make the project harder or easier depending on if they know that the student has access to time-saving tools.
But students rarely have to write programs that are that complex that that kind of stuff is necessary. When it is necessary, generally some kind of tools are introduced and used - but they don't become part of the curriculum. For example, in my OS class, we couldn't use an IDE. In other classes, we were told to use gdb - but we spent probably just one class on the details. Probably less.
I think there's actually a better tool to help students understand complicated parts of OOP - a whiteboard.
Intuitive understanding of OOP comes from programming in it, not from having an IDE to play with. When students are taught OOP, the professor is the one that dictates the pace and method that he gives his students an intuitive understanding with.
Debugging is a great way to catch errors, and IDEs are a good way to make more readable code, but intuitive understanding is going to come from being able to write a program on paper without any fancy toys.
And refactoring just looks like an automated way to fix your code - having the computer help you so that when you do rewrite your code you don't break it because you weren't paying attention or something equally human. But why give our students calculators when they are learning how to multiply?
It makes perfect sense, but the point is that method needs to be fixed, sped up, something so that either it's easier to use something from "CVS" or the builds come out faster. Getting the fixed code to the users faster would allow for better testing, resulting in a better product. If users can't use your CVS, it's that much longer for your bug fixes to be tested, slowing down the whole project.
I did an intro to Java class as a blowoff class (I was a third-year CS), but not once did the professor in class tell us how to run the darn thing. That's what TAs are for
They can only be taught by making them do just that.
Tutorials that come with the program, of course.
I would not expect a student to be able to even begin to know how to work a simulator. But I would expect them to be able to figure out how to start the program or be able to install it and run it on their computer.
Plus your analogy is all off, anyway. When you put a student in a simulator, let's say for a commercial airline, you are teaching them to fly the aircraft that simulator is simulating. Do you want to also include flight attendants, hijackers, angry travellers, company politics, etc.? No, you're just learning how to fly. In the same respect, you're just learning how to program, not use an IDE. Why include all that extra crap when students are just going to want to be able to do it their way, anyway?
About the download link: You should at least be able to download Dr. Scheme and figure out how to run the goddamn thing without any instruction from the professor.
"You haven't paid a thing for it; what do we owe you?" seems to be the cry of those developers who are faced with the fact that users don't like their project. You're right, you don't owe anything to users. But you know that you program for them. If you programmed for yourself, you wouldn't bother with configure files and auto-detection or any of that crap - it would just work on your computer. When users like your product, you love it, but as soon as they start complaining, "You get what you pay for!" Kind of reminds me of the Simpsons: "They've given you hours of entertainment for free...what else do they owe you?" But the fact is they make the show for the viewers, and when the viewers demand that their product be good or they stop using it, all of a sudden it's like you didn't even expect people to be partaking in your creation.
::downloads CVS::
It comes down to this: you don't have to support users. Fuck 'em. But guess what, fuck you if you complain about some talking head saying how your product isn't ready for the big time. They're actually helping you - why don't you accept their criticism.
The major problem with CVS is this:
"I have a bug"
"That bug is fixed in CVS"
"This CVS doesn't compile!"
"Sorry, we don't offer any guarantees with CVS"
Yes, the developers can't do anything if they've fixed the bug already. But it's frustrating to users, and unless you wanna say "fuck the users," the solution is obvious: fix the development process so "CVS" works - increase the speed at which users can use software. That's the major point the guy is making - software development is too slow. And I don't think it necessarily has to be fixed by increase developer man-hours. I think that too little thought is spent on preparing software for deployment, and that if a project put more of its focus on that, it would be more successful.
Here's one idea that might help: why the hell are people still using make and its evil cousins automake and autoconf?? You need serious gurus just to wade through all that muck. Everyone should check out SCons, because it makes life about a million times easier.
Sure you can do it without an IDE. "Refactoring" I think is a buzzword anyway for "cleaning up a rough draft" or "good coding practices." It's certainly made easier with an IDE, but student projects are never large enough to require one. I think teaching IDEs would be great for classes that teach software design or other higher level concepts, but not other programming classes (OS, compilers, etc), and certainly not intro programming courses.
When was the last time you wrote a serious math proof and wrote it all in one go on a piece of paper? Killing trees isn't all that bad.
I disagree about the ordeal. I think it's necessary in an introductory course to break people of any preconceptions that they have of programming. I personally was taught Scheme as an introductory course, and all they gave us was a link to Dr. Scheme - we didnt have a single instruction on how to use it.
This is a little simplified, but if you're doing a programming course (NOT a software engineering or design course), you should be teaching people how to compile their program but not how to use make. But that should even be done in a neutral manner. It all falls under the heading that you should be teaching your students principles and not programs. Plus, your students, pointed in the right direction, should be able to follow tutorials on their own.
Why have one at all? Unless your class is on the specific IDE or "Software Development Techiniques", why chain them to a specific technology? Let your students figure out how to run the damn editor. If it wasn't so tedious, I'd say have your students turn in assignments on paper. You are teaching programming, not a program, no matter how community college you are. Give your students a chance to figure something out for themselves and they will become smarter.
What's the big deal? So they got spooked by Chinese PCs - fair enough. When you are in defense, you play the "worst-case-scenario" game. No American companies were hurt, no civil rights were harmed - I don't see the problem. So we got a look inside the Defense Department's paranoia, but it's a harmless paranoia and implies no harmful side effects, corollaries, slippery slopes, or other cliches. This article should be tagged as "hype". This should be something people tag all articles that are oversold by the Slashdot headline.
Right after that comment I said: "and web pages are a good example of this."
The method that you pointed out is great. It is a huge win. It does a great job of applying the three concepts I mentioned, and also happens to separate logic from presentation. But I think that in computer programming in general, separating the two is not always the best idea. In some cases, the distinction is artificial and therefore any kind of separation is going to be forced. It's usually those cases where there is "too much" logic and when you try to separate out the presentation, it just becomes as tangled of a mess as it was before.
My point was really that "separate logic and presentation" is somewhat misleading and not as general as the concepts I pointed out.
Unfortunately, forcing employers to provide insurance puts far too much strain on small business owners. They won't be able to support their employees and it will bring them down.
People will always tell you to "separate logic from presentation" and that is good advice - to a certain extent. I don't think that this is correct all the time, however, because it is not a correct statement per se because the two cannot always be separated. However, they usually can and usually are, and web pages are a good example of this. But what does "separate" mean? Does it mean physically moving your presentation to another file, generating it, etc.? There are many different ways, all of which work best in certain situations.
Here's what you should worry about instead:
1) Is the program readable?
2) Can you easily make changes in the program without having to change too many other parts of it?
3) Are you having to rewrite the same code too much?
Those are some pretty basic computer programming design concepts, and if you apply those, you'll find that the answer should be pretty clear. Just keep everything clean and life will be happier.
You're right; Lance is pretty good at writing fiction.
Apparently, Lance was drunk during the event and thought he had some kind of big scoop when really he was too wasted to understand what was going on at the event.