5 ms·

"Programming on the other hand... code is either 0% correct or 100% correct. Anything less than 100% correct is broken." I don't think that's true. Anything l

by ohyes 16y ago

"Programming on the other hand... code is either 0% correct or 100% correct. Anything less than 100% correct is broken." I don't think that's true. Anything less than 100% correct is incorrect, it isn't necessarily broken. How do I know my program is not broken? I run it. If it produces the answers I want, I can generally assume it is not broken (with a dose of skepticism). If it is actually incorrect, it could still compile, run and/or produce useful answers (it would depend on the input). Almost all of my code has subtle bugs that I have had to iron out at one point or another. I know, I know; What about space shuttle control systems or critical airplane frobnobdicators? Fine. Those aren't lossy and forgiving, but systems like that are few and far between. There is a large subset of programs that are also lossy and forgiving. (Which I assume the majority of us work on). Were it really a binary reality, we would have much less software.

alextgordon 16y ago
I was talking in terms of transformations, such as the clone tool. Clone takes a set of pixels, applies some math, and gives you a new set of pixels that look a bit like what you want. After you've applied clone, you're done (although you might need to apply some finishing touches). There is just no room for such tools in programming. You can't have a tool that applies some transformation to the code but leaves half of it in a broken state. That would be worse than useless. No, a tool has to be 100% correct or introduce errors that are caught by the compiler, otherwise it'll take longer to find and fix its mistakes than it would to apply the transformation manually. And it turns out that making such perfect tools is incredibly hard. How do I know my program is not broken? I run it. If it produces the answers I want, I can generally assume it is not broken (with a dose of skepticism). But notice how much effort is put into making sure code is correct. We have unit testing, integration testing, fuzz testing, static analysis, formal verification, ... Games studios pay scores of people to sit around playing games all day. This is not seen in any other creative art.
- mnemonicsloth 16y ago
  Vim and Emacs are 20+ years old and still popular. They're still around precisely because they're really good tools for transforming source code.
  - mfukar 16y ago
    Not really. As much as I love vim and Visual Studio, I use them because there's nothing better. I'd love something better (maybe someday I'll care so much that I'll sit down and write it myself).
  - fab13n 16y ago
    Uh? I don't know about vim, but emacs doesn't even get syntax highlight right for most languages. It's a great text editor, and I appreciate it as such, but it understands way too little of programming languages other than Lisp to deserve being called an IDE.
    - nene 16y ago
      Emacs doesn't really come with out-of-the-box great support for most languages. Even for one language there are usually several alternative modes available, from which you have to choose. Even for Lisp you probably want to consider SLIME instead of the default. Unfortunately not every popular language has a truly great mode available. And the whole mode-ecosystem feel like a pita (especially for newcomers), but at least you have a choice, which you don't have with most other editors/IDE-s. But your talk about syntax highlighting is just unfair. I for example use a JavaScript mode written by Steve Yegge, which actually contains a full-blown JavaScript parser which pretty much ensures that under normal circumstances I don't make syntax errors. Oh... and it also has syntax highlighting :)
- ohyes 16y ago
  "But notice how much effort is put into making sure code is correct. We have unit testing, integration testing, fuzz testing, static analysis, formal verification, ... Games studios pay scores of people to sit around playing games all day. This is not seen in any other creative art." You would have all of these things with or without a 'clone' tool that produces approximately correct code. As long as it produces code that is in some way human readable, can be debugged using standard (above) means, and doesn't make too many mistakes, it would be fine (no worse than me writing code, at least). I think that your assumption that it would make a lot of mistakes and that they would be tedious and difficult to debug is just that, an assumption. It might be as simple as the programmer simply 'touching things up'. We haven't seen the tool, it doesn't exist, so arguing about what it would do is a moot point.
- stcredzero 16y ago
  I was talking in terms of transformations, such as the clone tool. Clone takes a set of pixels, applies some math, and gives you a new set of pixels that look a bit like what you want. After you've applied clone, you're done (although you might need to apply some finishing touches). The pre-packaged refactorings in the Smalltalk Refactoring Browser are like this. There are checks to see if the refactoring is guaranteed to be correct, and if the refactoring runs, you can be very sure it is. The refactoring commands are even undo/redo-able.
rbanffy 16y ago
> Anything less than 100% correct is incorrect, it isn't necessarily broken. > run and/or produce useful answers (it would depend on the input) The fact companies can and do sell broken products that generate wrong answers, lock-up or crash from time to time has no relation to the fact the products are broken. An old joke said that IBM stood for "Inferior, but marketable"
- ohyes 16y ago
  You'll note, that isn't what I was arguing. You can have code that is not 100% correct, it still runs and generates reasonable answers, without crashing, and is very useful. Even code that has been worked on for years still has subtle bugs lurking in it. Take the Linux kernel. It has bugs in it. Somewhere, there is a bug! I'm 100% sure of this. Same with Windows, OSX. A non-trivial piece of software with a bug is a tautology. We don't say that these products are broken, because then all software products would necessarily be broken. Sure, in software development we are doing our damnedest to approximate correctness, but we never get there. A tool that writes approximately correct code would be very useful.
  - mfukar 16y ago
    How would it be useful to me, if I spent my time scrutinizing and debugging the code output by the tool? I'm sorry, but this kind of inconsiderate, care-free attitude about bugs is an obstacle to me as a developer, to the brink of being downright offensive. Assuming of course we're writing code which is more complex than Hello World. All I want, as a programmer, is a tool which aids me in reading, writing and manipulating code, without getting in the way. A clone feature is completely useless to me; a proper IDE has (or would have, actually) a library of code that I can choose from for my purposes, or perhaps would let me choose from my own snippets I've written in the past. Simply letting me drag a function to the point(s) in the code I'd like it to be called and then placing the necessary #include directives and/or the necessary compiler/linker options, and perhaps taking care of some parameters based on default values, a conceptually simple task, seems like science fiction to vim or emacs. It's utterly stupid. The article is right on. We're wasting our time on syntax errors. We don't appreciate our craft.

by ohyes 16y ago

alextgordon 16y ago

I was talking in terms of transformations, such as the clone tool. Clone takes a set of pixels, applies some math, and gives you a new set of pixels that look a bit like what you want. After you've applied clone, you're done (although you might need to apply some finishing touches). There is just no room for such tools in programming. You can't have a tool that applies some transformation to the code but leaves half of it in a broken state. That would be worse than useless. No, a tool has to be 100% correct or introduce errors that are caught by the compiler, otherwise it'll take longer to find and fix its mistakes than it would to apply the transformation manually. And it turns out that making such perfect tools is incredibly hard. How do I know my program is not broken? I run it. If it produces the answers I want, I can generally assume it is not broken (with a dose of skepticism). But notice how much effort is put into making sure code is correct. We have unit testing, integration testing, fuzz testing, static analysis, formal verification, ... Games studios pay scores of people to sit around playing games all day. This is not seen in any other creative art.

mnemonicsloth 16y ago
Vim and Emacs are 20+ years old and still popular. They're still around precisely because they're really good tools for transforming source code.
- mfukar 16y ago
  Not really. As much as I love vim and Visual Studio, I use them because there's nothing better. I'd love something better (maybe someday I'll care so much that I'll sit down and write it myself).
- fab13n 16y ago
  Uh? I don't know about vim, but emacs doesn't even get syntax highlight right for most languages. It's a great text editor, and I appreciate it as such, but it understands way too little of programming languages other than Lisp to deserve being called an IDE.
  - nene 16y ago
    Emacs doesn't really come with out-of-the-box great support for most languages. Even for one language there are usually several alternative modes available, from which you have to choose. Even for Lisp you probably want to consider SLIME instead of the default. Unfortunately not every popular language has a truly great mode available. And the whole mode-ecosystem feel like a pita (especially for newcomers), but at least you have a choice, which you don't have with most other editors/IDE-s. But your talk about syntax highlighting is just unfair. I for example use a JavaScript mode written by Steve Yegge, which actually contains a full-blown JavaScript parser which pretty much ensures that under normal circumstances I don't make syntax errors. Oh... and it also has syntax highlighting :)
ohyes 16y ago
"But notice how much effort is put into making sure code is correct. We have unit testing, integration testing, fuzz testing, static analysis, formal verification, ... Games studios pay scores of people to sit around playing games all day. This is not seen in any other creative art." You would have all of these things with or without a 'clone' tool that produces approximately correct code. As long as it produces code that is in some way human readable, can be debugged using standard (above) means, and doesn't make too many mistakes, it would be fine (no worse than me writing code, at least). I think that your assumption that it would make a lot of mistakes and that they would be tedious and difficult to debug is just that, an assumption. It might be as simple as the programmer simply 'touching things up'. We haven't seen the tool, it doesn't exist, so arguing about what it would do is a moot point.
stcredzero 16y ago
I was talking in terms of transformations, such as the clone tool. Clone takes a set of pixels, applies some math, and gives you a new set of pixels that look a bit like what you want. After you've applied clone, you're done (although you might need to apply some finishing touches). The pre-packaged refactorings in the Smalltalk Refactoring Browser are like this. There are checks to see if the refactoring is guaranteed to be correct, and if the refactoring runs, you can be very sure it is. The refactoring commands are even undo/redo-able.

rbanffy 16y ago

> Anything less than 100% correct is incorrect, it isn't necessarily broken. > run and/or produce useful answers (it would depend on the input) The fact companies can and do sell broken products that generate wrong answers, lock-up or crash from time to time has no relation to the fact the products are broken. An old joke said that IBM stood for "Inferior, but marketable"

ohyes 16y ago
You'll note, that isn't what I was arguing. You can have code that is not 100% correct, it still runs and generates reasonable answers, without crashing, and is very useful. Even code that has been worked on for years still has subtle bugs lurking in it. Take the Linux kernel. It has bugs in it. Somewhere, there is a bug! I'm 100% sure of this. Same with Windows, OSX. A non-trivial piece of software with a bug is a tautology. We don't say that these products are broken, because then all software products would necessarily be broken. Sure, in software development we are doing our damnedest to approximate correctness, but we never get there. A tool that writes approximately correct code would be very useful.
- mfukar 16y ago
  How would it be useful to me, if I spent my time scrutinizing and debugging the code output by the tool? I'm sorry, but this kind of inconsiderate, care-free attitude about bugs is an obstacle to me as a developer, to the brink of being downright offensive. Assuming of course we're writing code which is more complex than Hello World. All I want, as a programmer, is a tool which aids me in reading, writing and manipulating code, without getting in the way. A clone feature is completely useless to me; a proper IDE has (or would have, actually) a library of code that I can choose from for my purposes, or perhaps would let me choose from my own snippets I've written in the past. Simply letting me drag a function to the point(s) in the code I'd like it to be called and then placing the necessary #include directives and/or the necessary compiler/linker options, and perhaps taking care of some parameters based on default values, a conceptually simple task, seems like science fiction to vim or emacs. It's utterly stupid. The article is right on. We're wasting our time on syntax errors. We don't appreciate our craft.