"To get over this deficiency a programmer can practice by using the IDE's own debugger as an aide,"
sign of bad programmer: relying on the IDE?
'always have a security professional review the
design and implementation.'
At first glance it reads like a list a hypothetical programmer should do, rather than what happens. For a dose of reality, read this article by Joel about the job of the SDETs at MS. [0] I don't hold MS as an example of security but Joel paints a picture of serious programmers trying to code then verify commercial software used by millions. [1]
[1] Then there's the open-source way. How many in the OS systems community really have 'security professionals' review their code? OpenBSD and who else?
Using the tools available to you to their fullest extent, rather than doing things the hard way on purpose just to be more "hardcore", is not a sign of a bad programmer
Definitely agree, however I can also see the shortcomings of the "IDE languages". One of the nice things about non-auto-completable scripting languages is that they force you to write code that you can reason about yourself. IDEs let you write really inelegant code that you can still continue to slog through because of autocomplete.
Another big downside of IDEs is that they constrain your choice of tooling to only the IDE. There's a rich ecosystem of editors, preprocessors, templating, etc. for JS, but (for example) in iOS development you only get xcode's half-working gee-whiz features like the interface builder. In my experience, the more IDE features there are, the more of your program moves into hidden, IDE-specific automagical stuff.
So resistance that you may see to IDE's is not because someone wants to be "hardcore", but because they recognize that it is desirable for code to be able to stand on its own and be understood by a human no matter the editor used.
I especially hate IDE features that don't have a corresponding plaintext representation that you can edit. For example, a graphical layout editor which saves data into a binary blob that then requires a special merge tool which is only available in the IDE.
"rather than doing things the hard way on purpose just to be more "hardcore", is not a sign of a bad programmer"
I agree, IDE's boost productivity. The next question I ask is, what's your client? Mine is a tty terminal over ssh. This limits the kind of IDEs I can use, so it's cli/vi/[languate]. Simple tools from a more elegant time.
Why do you choose to do it that way? If you really wanted to use an IDE you could just keep it on a github repo or even dropbox, or if it's a local or very fast connection it could even be reasonable to use X11 tunneling. But, if the CLI environment is the most convenient or efficient for whatever's being done then it's a better choice.
Not the person you were asking, but I do it that way because I work with a software package that bundles a ton of proprietary libraries that would be difficult at best to set up on a separate dev machine and because the "IDE" included with it is just a bunch of glue for CLI stuff anyway (with a text editor literally no better than Notepad). SSH+vim is seriously a better option than the tools I'd have to work with otherwise. Bad IDEs do exist.
But that's a niche tool in a niche field with a niche language.
(It's the Cloverleaf interface engine used in healthcare and built on tcl, for the curious).
Though I use a small laptop as a client and sometimes at the machine with monitor and keyboard, most work I do is on a Pi, remotely. I'll be upgrading my Pi to version 2 and splash out the necessary $40.
Now I could fire up the beastly server I have on my desk with 300W power supply, multiple HD's with linux, but as an experiment I moved all the dev over to a Pi. Add a few more Pi machines and I can use one for image processing, another for dev, another for sound/media & I have the core of what I used to do on a desktop for the price of a fast HD.
Agreed. People wouldn't appreciate it if I ignored the "interactions" warnings when prescribing medications just because I felt like I should be able to recall every drug-drug interaction myself...
On the contrary. The worst programmer I've worked with was the one who insisted that debuggers were a sign of a bad programmer and one should be able to fix problems without them. Not only was he negative-productivity himself, but since he was fairly senior and many of the other developers were quite junior and listened to him, he lowered the productivity of the entire team.
> ps: Is there a way to prove the output of complex regular expressions?
It's not really clear what you mean here.
Maybe you mean "if the input matches this regex, then it can't be used for command injection"? Then you'd just need a proof that something matching that regex can't escape the intended context in the code you're generating. That's fairly trivial if you have a regex describing all escape sequences, for instance.
If they're not really regular expressions, then the answer is more complicated but still generally yes.
Comes from the perspective of the author, see the note:
> This paper is not meant for grading programmers [...] This paper was written to force its author to think, and published because he thinks you lot would probably get a kick out of it, too.
The intent of that remedy is to wean the programmer off of using a debugger and to executing the code mentally.
sign of bad programmer: relying on the IDE?
At first glance it reads like a list a hypothetical programmer should do, rather than what happens. For a dose of reality, read this article by Joel about the job of the SDETs at MS. [0] I don't hold MS as an example of security but Joel paints a picture of serious programmers trying to code then verify commercial software used by millions. [1]Commerce and software demand another set of skills beyond this article. Read the counter-point: 'What Makes a Good Programmer' http://www.southsearepublic.org/article/2024/read/what_makes...
ps: Is there a way to prove the output of complex regular expressions?
[0] Joel Spolsky, 'Talk at Yale: Part 1 of 3', http://www.joelonsoftware.com/items/2007/12/03.html
[1] Then there's the open-source way. How many in the OS systems community really have 'security professionals' review their code? OpenBSD and who else?
(various edits)