5 ms·

"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

"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] 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_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 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)

lfowles 12y ago
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.
- bootload 12y ago
  "The intent of that remedy is to wean the programmer off of using a debugger and to executing the code mentally." good point.
jimmaswell 12y ago
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
- woah 12y ago
  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.
  - bootload 12y ago
    "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." That and hardware constraint.
  - jschwartzi 12y ago
    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.
- bootload 12y ago
  "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.
  - jimmaswell 12y ago
coldtea 12y ago
No, that's a sign of a programmer that kept up with the times and is not afraid to release control.
lmm 12y ago
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.
- agumonkey 12y ago
  What was is advice ? heavy printf ? or lengthy prior analysis ?
  - Luyt 12y ago
    I guess it was visual code inspection... Staring at the screen for hours, trying to figure out why the code doesn't work, while it should work.
  - lmm 12y ago
    "You should understand what the code is doing"
    - agumonkey 12y ago
      So purely cerebral simulation.
- jeorgun 12y ago
  While this is certainly true, it's worth pointing out that debugger != IDE.
nmrm2 12y ago
> 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.

lfowles 12y ago

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.

bootload 12y ago
"The intent of that remedy is to wean the programmer off of using a debugger and to executing the code mentally." good point.

jimmaswell 12y ago

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

woah 12y ago
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.
- bootload 12y ago
  "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." That and hardware constraint.
- jschwartzi 12y ago
  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.
bootload 12y ago
"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.
- jimmaswell 12y ago

coldtea 12y ago

No, that's a sign of a programmer that kept up with the times and is not afraid to release control.

lmm 12y ago

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.

agumonkey 12y ago
What was is advice ? heavy printf ? or lengthy prior analysis ?
- Luyt 12y ago
  I guess it was visual code inspection... Staring at the screen for hours, trying to figure out why the code doesn't work, while it should work.
- lmm 12y ago
  "You should understand what the code is doing"
  - agumonkey 12y ago
    So purely cerebral simulation.
jeorgun 12y ago
While this is certainly true, it's worth pointing out that debugger != IDE.

nmrm2 12y ago

> 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.