oh, so as long as I'm not actually worried about the requirements of due process (5th amendment) then I can tell the 4th amendment (and the other 9, and for that matter the entire concept of consitutional checks and balances) to fuck off?
sounds logical. no, really.
Even if they did hear those things they can't do anything about them.
Yes, they could and they will. They will turn that info over as a "tip" (non-admissable for prosecution but admissable for acquiring a warrent) to some other division and THEY will get the warrent and nab you for something they never would have had immenent discovery for, and thus the case would be thrown out anyways but not after TON of money was wasted on both sides.
y'know, when the FBI finally goes up against the Supreme Court
Actually, all the unconstitutional crap is being done by the NSA. The FBI got warrents (over 120) through the FISA courts for every single aspect of the British plane bombers investigation that they participated in.
which goes to prove that the NSA warrentless program is utterly unnecessary to stopping terrorism.
Re:In music at least, talent coutns
on
The Expert Mind
·
· Score: 1
as the other post said, "perfecting the mistakes" - the ability to critique oneself is critical to improving over time. if you can't hear/see/feel what you're doing wrong, you can't correct it. most people either cringe at their mistakes and quit trying (or just do the bare minimum for competancy), or they simply can't hear the difference between them and the maestro next to them.
Guitarist Richard Thompson, now a well-respsected songwriter, only got his start songwriting in his early 20s at the encouragement of fellow Fairporter Dave Swarbrick. A few goodies, a couple of masterpieces, but a lot of bad ones (that they simply didn't bother to record). Asked about songwriting now, Thompson says "It's easy: simply write 1,000 songs and throw them all away.".
they're just playing by the rules the PTO has already established and publically stated (even back in the 90s when/. first started and patents was a hot-topic). the PTO's sole guideline for "prior art" is "is there a patent on it yet?", nothing more. they don't research the industry, they don't look for unpatented preexisting stuff, they just look at their patent application history and that's the sole decider.
anything more and they defer to the courts to handle it. why? policy encourages it -
if a patent clerk passes a patent, he's no longer responsible for it - parties have to fight out the validity of it in the courts and the PTO never gets involved.
but if a clerk rejects a patent, that clerk may be called into court to defend the rejection.
thus, the system is screwed in favor of patents - its not in the best interests of the PTO to reject patent applications, so they don't.
My (insanely) brief understanding is that this is merely a ploy to get more cash flow through amazon up front without expenses - pay a "fee" up front to get allegedly cheap(er) shipping later. works for the buyer if they buy enough (like paying $25 at B&N for 10% discounts later), works for amazon up front in that they get cash without immediate expense which can sit in an interest bearing account.
its really no different from any other "discount membership club" except the product you save on.
worthy of a patent? no. but this is the same PTO that patented a laser pointer as a cat toy, so fuck 'em.
Hibernate doesn't have a cash-heavy owner the way JBoss (now) does. Its one of the curses of selling an OpenSource product to a commercial enterpris: instead of a random batch of flat-broke hackers and hobbiests not worth a dime, you can sue a big company for a permanent take of their revenue. If you win, your stock-holders will love you forever.
Of course, the history and obviousness of ORM is so out there (every C++ magazine in the 90s talked about the concept) that this patent should never have been granted in the first place.
Then your assertion of cds of the 90s being potentially broken is a bad one, as you just described your experiences with cds since 2000. Facts to support the claim, please...
The point being that the guy making the free software can't afford the defense. Yeah its "obvious" he's in the right and has the prior art (theoretically in the form of the mailing list archives), but he's still got to hire the lawyer and (being a civil suit) deal with at least 2 rounds of appeals.
For someone making something that makes no money, shelling out $100,000 in legal fees to protect it doesn't seem all that smart.
And like Scalia's "originalism", Roberts has already shown he's a liar willing to let this principle be damned for the sake of getting the ruling he wants.
If getting ActiveX controls to work is a problem, you could fall back on loading your results by javascripting into an IFrame. Granted, its much more difficult to implement "POST" handlers that way, but with the right library, most of those differences can be hidden away. The main thing you lose is the automatic XML parsing - but if using Ajax as an RPC mechanism, you should try using JSON instead. The Javascript DOM implementation ain't the greatest.
You have to know that its a method for a client and server to speak, but thats about it. I know a bit more than that, but any of that knowledge is rarely ever needed.
I've need to know GET vs POST, cache settings (for 3 different browsers), writing content-types on the fly (particularly what to do to force the browser to give a "Save as..." dialog rather than embed the object, and how to default that filename), raw cookies, and all the crap that's needed to do file uploads, all in a single web application. some of that for Ajax, some of that for just basic functionality.
all of that is set in the http protocol, and the way you write it (yes, using library calls like "request.setHeader(header, value)") is still so close to the language, you might as well be writing it directly (there is a slightly higher-level API for sending 300 redirects). in PHP and the Servlet/JSP api, you can keep writing headers until the first byte of "real" content is passed; after that you'll get a server-side error that's really hard to figure out by the way its presented.
I've never written a component IN XML (nor do I know how you could do so)
try using XUL sometime (its declarative, but its still programming). and though its not true XML, using JSPs standard "logic" tags and/or cold fusion, is like using a near-XML syntax for proceedural logic with conditions. XML serialization of Java components can be used to "program" a UI as well.
its all a matter of how the interpretor of the XML treats it. XML's just a syntax that's standardized so much that parsers are written for just about every environment. what one does with the parsed content is one's own lookout.
I don't really see how the IDE hides any of the details of the computer language.
I, and everybody who has defended the view of avoiding IDEs in the first CS programming classes, have never said it did. its not the *language* that the IDE hides. Its the importance of how a development system works (compiler, linker, runtime engine) that gets hidden away.
its the difference between technical training and getting a degree that confirs a true understanding of the subject matter. anybody can train on an IDE at any point. but training on an IDE too early can lead CS students to not get the full picture that I and many others believe they should be getting on how a computing environment works. already, I feel CS students are losing out because they no longer (in many programs including the school I graduated from) have to know a damn thing about hardware.
if we're just talking about training people to program for work, we're talking turning universities into trade schools, and i ranted about that one elsewhere in this thread.
I didn't say *programming* languages, craphead, I said "languages". CSS and HTML are languages that you have to know to do Ajax programming.
HTTP is a language as much as a protocol, in that as a protocol it is entirely human readable. is XML-RPC or SOAP a language or a protocol? Is XML even a "language"? (actually, THAT is a question I ask candidates - the real answer is no, it isn't.)
Writing low-level Ajax code does involve knowledge of the HTTP protocol, and most people who know it know the protocol in the form of the language the two computers use to talk to each other, even if they never specifically write HTTP-handling code (though I have, both client and server). When you have to write server-code that involves sending additional headers back and forth, you are talking HTTP by writing code that generates strings in the HTTP langugage. a good developer should know WHY they can't write a new header after the server has already started to send text down the line (and why that one little newline in their JSP can break with a huge 500 internal service error deep inside tomcat). to really know why is to know HTTP to the point of being able to imagine the language, the header strings, as if you writing it yourself.
yeah, you can be "productive" not having to give a rats ass about HTTP and just use prototype and scriptalicious and be done with it, but some of us have to actually architect things and build that sort of stuff and know the low-level details so you don't have to.
and as i wrote before (at least 4 times now, and i'm sure others have had to say it as well to you religious-war nutcases), this question isn't about professional software developers using or not using IDEs. (I use eclipse with a passion). this is about whether or not the IDE for a beginning programmer (particularly for a CS degree student) HINDERS the development of their programming skills by hiding too much of the details of how computer languages and environments work.
In spite of the "in bed with Microsoft" complaints back in the early days of BootlegTV (and Fripp's providing "effects" music for the upcoming Vista release), when DGMLive.com finally opened its shop, the music was and is released in non-DRM formats. MP3 albums for $9.95, or FLAC (lossless compression) for $12.95.
its borderline (like the difference between an IDE and "just an editor with special features".
its an advanced programming technique that's most often used in software development.
perhaps its a bad example, but my main case has been the inability for interview candidates (even allowing for "pressure") to even pseudo-code on a markerboard.
another thing i've noticed is that the higher the dependency on the IDE, the less likely they are to have any sort of personal library. granted, i'm not expecting anyone to have invested in the bookshelves-full that i have (though i'd love it if someone like that walked through my door), but i kinda expect a little more than what i've seen.
in a sense this is moving (degrading?) into a discussion of great software developers vs lesser ones, but the core of software development is still programming and i firmly believe (and my experience, though anectdotal of course, supports it) that better programmers make better software developers and better programmers come from environments where they had to learn the ins-and-outs of programming by using lesser tools in their early stages of learning.
like using calculators in math class - we don't give them permission to use calculators until after they've gone through the years of conditioning of basic arithmetic. so too, we shouldn't give them the advantages of the IDE until after they've learned the basic concepts of what programming really is.
in my current case, my work is mostly Ajax-driven (Java server), and of course has to be cross-browser compatible. this means for my "client" i have no debugger support whatsoever, though I can use jstrace to avoid all of the beeps that IE throws out with every js alert dialog. in addition, all the IDEs in the world won't really help with CSS or really understanding what happens when 10 JSPs get combined into a single page by Struts' Tiles (or JSF or 10 Spring "objects" if that's your poison).
and as i've written, there are degrees/levels of "programming" ability. one can learn the basics and trust the IDE to keep "productive", but in my experience and based on the MANY interview candidates i've dealt with, there's a huge difference between that and someone who really can PROGRAM to the level I need to see.
i've had a number of candidates who can't talk about refactoring (in spite of its IDE support), can't talk about design patterns beyond "Singleton" (I make that an exception to the "Describe a design pattern" question), can't even write simple pseudo-code on a markerboard to draw a "tree" or write (or even just *use*) an iterator from a collection. to the work they've done they are very "productive" with an IDE, and are probably ok programmers.
but they've gotten so slaved by the IDE they've really lost the ability to think about programming to the level I need to see. these are "senior" developer candidates who don't know what i would consider to be the basic minimums of software development and the level of programming skills it requires.
they can use the IDE but they have no clue why it works.
i have no problem seeing these people in the (many) maintenance projects out there, but i need something more, and the IDE is making the person i'm looking for much harder to find.
CS students striving for a CS major should be able to incorporate such "lessons" without any problems at all. If they can't, they're in the wrong major.
and at the beginning levels, the teacher can provide them instructions on turning the optimizer off if its a problem.
there are ways around these things.
like i said, if they don't learn to debug with prints, they don't learn to write good logging messages in software development/engineering environments, and they have more hell to pay later on when they hit real world programming.
and, of course, there are environments where no such debugging is available at all, like the client-side of Ajax (Venkman is still too much trouble for its own good right now - trace prints and alerts are the ONLY way to do that).
oh, debugging with prints will hurt if you do it wrong, but you should learn to do it right.
if you get a segfault in your C++ debugging, GOOD, 'cause it means you screwed up the memory allocation and you need, absolutely NEED, to learn to do it right. similarly, by seeing the oddities in debugging through prints, you also learn how the compiler's optimizer has rearrainged your code. most coders out there have no idea it can and will do that.
but (as i wrote elsewhere) - the important thing about debugging through prints is learning to write logfile lines. you won't have your super-duper fancy debugger out there at your customer's installation. all you'll have is the log file, some stack traces (if in java), and/or the core dump.
yeah, in thinking about it, a syntax-highlighting editor probably would do more good than harm, but the teacher (as one post said, how the teacher teaches is important to start with) should recommend turning highlighting off on occasion because writing code down on paper won't be in color.;-)
after a while of dealing with pascal in pure TPU (Vax/VMS, 1989), I switched to the LSE (also written in the same language, one of DEC's better pieces of code in my opinion), which still wasn't a pure IDE, but helped out with my coding speed considerably. However, that switched happened in my 2nd CS semester, with data structures etc, not my first semester where i was still learning to code in the first place.
i hate "Java" view in eclipse. its a hangover look/feel from the Borland days, expanded to cover non-java resources in a way that tries to make them seem the same (and then gets in your way as you see they aren't).
I never said I don't use IDEs nor should anybody else. IDEs are a tremendous boon to software development.
IDEs are, as the subject question originally asked, a handicapp to learning to program.
I swear by eclipse, particularly its refactoring support, for my work. But I can live without it. I'd certainly rather not, but I can.
As such, I don't believe one should hire somebody else for high quality work if they can't work without the IDE. Even if they never have to go without it a day of their career, they should damn well be able to go without it. There are days where it simply isn't there, particularly (again, as i've written elsewhere) when you have to diagnose and debug your customer's problem solely by log files.
please (everybody) stop assuming that thinking and stating that IDEs are a bain to learning to program doesn't mean they aren't a boon to software development. Those are two completely different fields of CS education (one certainly dependent on the other).
hence in interviews we make them write code on paper or on the markerboard.
you'd be amazed (or maybe not) and just how many "senior" software developer candidates can't even do decent pseudocode.
its like someone saying they've got a physics doctorate and yet have no idea what Feynman and Sagan called the "back of the napkin estimate". JMU's physics program actually started with a "back of the napkin" guesstimates (as part of its general cosmology intro for physics majors class) even before we took our first mechanics course.
debugging with prints teaches logging techniques. as i've written elsewhere, you won't have the debugger around when your customer files his bug report. if the log files doesn't print enough info to diagnose, you've got a bigger problem.
and if you don't bother to debug with prints in the first place, you'll have lousy and useless log files later.
Slashdot Mirror
oh, so as long as I'm not actually worried about the requirements of due process (5th amendment) then I can tell the 4th amendment (and the other 9, and for that matter the entire concept of consitutional checks and balances) to fuck off?
sounds logical. no, really.
Even if they did hear those things they can't do anything about them.
Yes, they could and they will. They will turn that info over as a "tip" (non-admissable for prosecution but admissable for acquiring a warrent) to some other division and THEY will get the warrent and nab you for something they never would have had immenent discovery for, and thus the case would be thrown out anyways but not after TON of money was wasted on both sides.
y'know, when the FBI finally goes up against the Supreme Court
Actually, all the unconstitutional crap is being done by the NSA. The FBI got warrents (over 120) through the FISA courts for every single aspect of the British plane bombers investigation that they participated in.
which goes to prove that the NSA warrentless program is utterly unnecessary to stopping terrorism.
as the other post said, "perfecting the mistakes" - the ability to critique oneself is critical to improving over time. if you can't hear/see/feel what you're doing wrong, you can't correct it. most people either cringe at their mistakes and quit trying (or just do the bare minimum for competancy), or they simply can't hear the difference between them and the maestro next to them.
Guitarist Richard Thompson, now a well-respsected songwriter, only got his start songwriting in his early 20s at the encouragement of fellow Fairporter Dave Swarbrick. A few goodies, a couple of masterpieces, but a lot of bad ones (that they simply didn't bother to record). Asked about songwriting now, Thompson says "It's easy: simply write 1,000 songs and throw them all away.".
"'has this scenario' been patented"
/. first started and patents was a hot-topic). the PTO's sole guideline for "prior art" is "is there a patent on it yet?", nothing more. they don't research the industry, they don't look for unpatented preexisting stuff, they just look at their patent application history and that's the sole decider.
they're just playing by the rules the PTO has already established and publically stated (even back in the 90s when
anything more and they defer to the courts to handle it. why? policy encourages it -
if a patent clerk passes a patent, he's no longer responsible for it - parties have to fight out the validity of it in the courts and the PTO never gets involved.
but if a clerk rejects a patent, that clerk may be called into court to defend the rejection.
thus, the system is screwed in favor of patents - its not in the best interests of the PTO to reject patent applications, so they don't.
oh yeah, side effect of more cash in interest account is that it can bump up the stock value, which for now is all that's important at amazon.
My (insanely) brief understanding is that this is merely a ploy to get more cash flow through amazon up front without expenses - pay a "fee" up front to get allegedly cheap(er) shipping later. works for the buyer if they buy enough (like paying $25 at B&N for 10% discounts later), works for amazon up front in that they get cash without immediate expense which can sit in an interest bearing account.
its really no different from any other "discount membership club" except the product you save on.
worthy of a patent? no. but this is the same PTO that patented a laser pointer as a cat toy, so fuck 'em.
oh wait, they patented that, too...
Hibernate doesn't have a cash-heavy owner the way JBoss (now) does. Its one of the curses of selling an OpenSource product to a commercial enterpris: instead of a random batch of flat-broke hackers and hobbiests not worth a dime, you can sue a big company for a permanent take of their revenue. If you win, your stock-holders will love you forever.
Of course, the history and obviousness of ORM is so out there (every C++ magazine in the 90s talked about the concept) that this patent should never have been granted in the first place.
Then your assertion of cds of the 90s being potentially broken is a bad one, as you just described your experiences with cds since 2000. Facts to support the claim, please...
The point being that the guy making the free software can't afford the defense. Yeah its "obvious" he's in the right and has the prior art (theoretically in the form of the mailing list archives), but he's still got to hire the lawyer and (being a civil suit) deal with at least 2 rounds of appeals.
;-) ).
For someone making something that makes no money, shelling out $100,000 in legal fees to protect it doesn't seem all that smart.
(consider THAT, Mr. Gates...
My first impression was the Chewbacca test was being applied...
And like Scalia's "originalism", Roberts has already shown he's a liar willing to let this principle be damned for the sake of getting the ruling he wants.
If getting ActiveX controls to work is a problem, you could fall back on loading your results by javascripting into an IFrame. Granted, its much more difficult to implement "POST" handlers that way, but with the right library, most of those differences can be hidden away. The main thing you lose is the automatic XML parsing - but if using Ajax as an RPC mechanism, you should try using JSON instead. The Javascript DOM implementation ain't the greatest.
so eventually, with hard drive prices cheap, get a 400gig external and preserve the raw cdr (or wav) files on that drive.
though yeah, hard drives can crash in 10 years...
its a never-ending spiral of dependencies on SOME technology that isn't supposed to break but does. best just get on with it.
You have to know that its a method for a client and server to speak, but thats about it. I know a bit more than that, but any of that knowledge is rarely ever needed.
;-) )
I've need to know GET vs POST, cache settings (for 3 different browsers), writing content-types on the fly (particularly what to do to force the browser to give a "Save as..." dialog rather than embed the object, and how to default that filename), raw cookies, and all the crap that's needed to do file uploads, all in a single web application. some of that for Ajax, some of that for just basic functionality.
all of that is set in the http protocol, and the way you write it (yes, using library calls like "request.setHeader(header, value)") is still so close to the language, you might as well be writing it directly (there is a slightly higher-level API for sending 300 redirects). in PHP and the Servlet/JSP api, you can keep writing headers until the first byte of "real" content is passed; after that you'll get a server-side error that's really hard to figure out by the way its presented.
I've never written a component IN XML (nor do I know how you could do so)
try using XUL sometime (its declarative, but its still programming). and though its not true XML, using JSPs standard "logic" tags and/or cold fusion, is like using a near-XML syntax for proceedural logic with conditions. XML serialization of Java components can be used to "program" a UI as well.
its all a matter of how the interpretor of the XML treats it. XML's just a syntax that's standardized so much that parsers are written for just about every environment. what one does with the parsed content is one's own lookout.
I don't really see how the IDE hides any of the details of the computer language.
I, and everybody who has defended the view of avoiding IDEs in the first CS programming classes, have never said it did. its not the *language* that the IDE hides. Its the importance of how a development system works (compiler, linker, runtime engine) that gets hidden away.
its the difference between technical training and getting a degree that confirs a true understanding of the subject matter. anybody can train on an IDE at any point. but training on an IDE too early can lead CS students to not get the full picture that I and many others believe they should be getting on how a computing environment works. already, I feel CS students are losing out because they no longer (in many programs including the school I graduated from) have to know a damn thing about hardware.
if we're just talking about training people to program for work, we're talking turning universities into trade schools, and i ranted about that one elsewhere in this thread.
(and i apologize for "craphead"
I didn't say *programming* languages, craphead, I said "languages". CSS and HTML are languages that you have to know to do Ajax programming.
HTTP is a language as much as a protocol, in that as a protocol it is entirely human readable. is XML-RPC or SOAP a language or a protocol? Is XML even a "language"? (actually, THAT is a question I ask candidates - the real answer is no, it isn't.)
Writing low-level Ajax code does involve knowledge of the HTTP protocol, and most people who know it know the protocol in the form of the language the two computers use to talk to each other, even if they never specifically write HTTP-handling code (though I have, both client and server). When you have to write server-code that involves sending additional headers back and forth, you are talking HTTP by writing code that generates strings in the HTTP langugage. a good developer should know WHY they can't write a new header after the server has already started to send text down the line (and why that one little newline in their JSP can break with a huge 500 internal service error deep inside tomcat). to really know why is to know HTTP to the point of being able to imagine the language, the header strings, as if you writing it yourself.
yeah, you can be "productive" not having to give a rats ass about HTTP and just use prototype and scriptalicious and be done with it, but some of us have to actually architect things and build that sort of stuff and know the low-level details so you don't have to.
and as i wrote before (at least 4 times now, and i'm sure others have had to say it as well to you religious-war nutcases), this question isn't about professional software developers using or not using IDEs. (I use eclipse with a passion). this is about whether or not the IDE for a beginning programmer (particularly for a CS degree student) HINDERS the development of their programming skills by hiding too much of the details of how computer languages and environments work.
In spite of the "in bed with Microsoft" complaints back in the early days of BootlegTV (and Fripp's providing "effects" music for the upcoming Vista release), when DGMLive.com finally opened its shop, the music was and is released in non-DRM formats. MP3 albums for $9.95, or FLAC (lossless compression) for $12.95.
its borderline (like the difference between an IDE and "just an editor with special features".
its an advanced programming technique that's most often used in software development.
perhaps its a bad example, but my main case has been the inability for interview candidates (even allowing for "pressure") to even pseudo-code on a markerboard.
another thing i've noticed is that the higher the dependency on the IDE, the less likely they are to have any sort of personal library. granted, i'm not expecting anyone to have invested in the bookshelves-full that i have (though i'd love it if someone like that walked through my door), but i kinda expect a little more than what i've seen.
in a sense this is moving (degrading?) into a discussion of great software developers vs lesser ones, but the core of software development is still programming and i firmly believe (and my experience, though anectdotal of course, supports it) that better programmers make better software developers and better programmers come from environments where they had to learn the ins-and-outs of programming by using lesser tools in their early stages of learning.
like using calculators in math class - we don't give them permission to use calculators until after they've gone through the years of conditioning of basic arithmetic. so too, we shouldn't give them the advantages of the IDE until after they've learned the basic concepts of what programming really is.
in my current case, my work is mostly Ajax-driven (Java server), and of course has to be cross-browser compatible. this means for my "client" i have no debugger support whatsoever, though I can use jstrace to avoid all of the beeps that IE throws out with every js alert dialog. in addition, all the IDEs in the world won't really help with CSS or really understanding what happens when 10 JSPs get combined into a single page by Struts' Tiles (or JSF or 10 Spring "objects" if that's your poison).
and as i've written, there are degrees/levels of "programming" ability. one can learn the basics and trust the IDE to keep "productive", but in my experience and based on the MANY interview candidates i've dealt with, there's a huge difference between that and someone who really can PROGRAM to the level I need to see.
i've had a number of candidates who can't talk about refactoring (in spite of its IDE support), can't talk about design patterns beyond "Singleton" (I make that an exception to the "Describe a design pattern" question), can't even write simple pseudo-code on a markerboard to draw a "tree" or write (or even just *use*) an iterator from a collection. to the work they've done they are very "productive" with an IDE, and are probably ok programmers.
but they've gotten so slaved by the IDE they've really lost the ability to think about programming to the level I need to see. these are "senior" developer candidates who don't know what i would consider to be the basic minimums of software development and the level of programming skills it requires.
they can use the IDE but they have no clue why it works.
i have no problem seeing these people in the (many) maintenance projects out there, but i need something more, and the IDE is making the person i'm looking for much harder to find.
depends on the target audience.
CS students striving for a CS major should be able to incorporate such "lessons" without any problems at all. If they can't, they're in the wrong major.
and at the beginning levels, the teacher can provide them instructions on turning the optimizer off if its a problem.
there are ways around these things.
like i said, if they don't learn to debug with prints, they don't learn to write good logging messages in software development/engineering environments, and they have more hell to pay later on when they hit real world programming.
and, of course, there are environments where no such debugging is available at all, like the client-side of Ajax (Venkman is still too much trouble for its own good right now - trace prints and alerts are the ONLY way to do that).
oh, debugging with prints will hurt if you do it wrong, but you should learn to do it right.
if you get a segfault in your C++ debugging, GOOD, 'cause it means you screwed up the memory allocation and you need, absolutely NEED, to learn to do it right. similarly, by seeing the oddities in debugging through prints, you also learn how the compiler's optimizer has rearrainged your code. most coders out there have no idea it can and will do that.
but (as i wrote elsewhere) - the important thing about debugging through prints is learning to write logfile lines. you won't have your super-duper fancy debugger out there at your customer's installation. all you'll have is the log file, some stack traces (if in java), and/or the core dump.
yeah, in thinking about it, a syntax-highlighting editor probably would do more good than harm, but the teacher (as one post said, how the teacher teaches is important to start with) should recommend turning highlighting off on occasion because writing code down on paper won't be in color. ;-)
after a while of dealing with pascal in pure TPU (Vax/VMS, 1989), I switched to the LSE (also written in the same language, one of DEC's better pieces of code in my opinion), which still wasn't a pure IDE, but helped out with my coding speed considerably. However, that switched happened in my 2nd CS semester, with data structures etc, not my first semester where i was still learning to code in the first place.
i hate "Java" view in eclipse. its a hangover look/feel from the Borland days, expanded to cover non-java resources in a way that tries to make them seem the same (and then gets in your way as you see they aren't).
"Java Browsing" is the better, in my opinion.
I never said I don't use IDEs nor should anybody else. IDEs are a tremendous boon to software development.
IDEs are, as the subject question originally asked, a handicapp to learning to program.
I swear by eclipse, particularly its refactoring support, for my work. But I can live without it. I'd certainly rather not, but I can.
As such, I don't believe one should hire somebody else for high quality work if they can't work without the IDE. Even if they never have to go without it a day of their career, they should damn well be able to go without it. There are days where it simply isn't there, particularly (again, as i've written elsewhere) when you have to diagnose and debug your customer's problem solely by log files.
please (everybody) stop assuming that thinking and stating that IDEs are a bain to learning to program doesn't mean they aren't a boon to software development. Those are two completely different fields of CS education (one certainly dependent on the other).
hence in interviews we make them write code on paper or on the markerboard.
you'd be amazed (or maybe not) and just how many "senior" software developer candidates can't even do decent pseudocode.
its like someone saying they've got a physics doctorate and yet have no idea what Feynman and Sagan called the "back of the napkin estimate". JMU's physics program actually started with a "back of the napkin" guesstimates (as part of its general cosmology intro for physics majors class) even before we took our first mechanics course.
debugging with prints teaches logging techniques. as i've written elsewhere, you won't have the debugger around when your customer files his bug report. if the log files doesn't print enough info to diagnose, you've got a bigger problem.
and if you don't bother to debug with prints in the first place, you'll have lousy and useless log files later.