3 ms·

Again, you're extrapolating just to prove me wrong. I admit it may seem 'extreme' to some, but advanced tools aren't a threat to us. However, our current cultur

by mfukar 16y ago

Again, you're extrapolating just to prove me wrong. I admit it may seem 'extreme' to some, but advanced tools aren't a threat to us. However, our current culture as programmers shows that we don't even trust other people's source code, let alone tools, to do our job. In this context of today, a tool that "writes code" (imperfect, of course) is not to be trusted any more than me, you, or our colleagues. But do not downplay the importance of not producing, fixing, and avoiding bugs. It's just wrong.

Retric 16y ago
There are basically two ways to write software you can either completely understand the problem and create a completely understood solution, or you can approximate a reasonable solution and then patch. Now when it’s possible the first approach is far better, unfortunately some of the worst systems where created when people tried to use the first approach when it was simply too complex for any one person to understand. If you have ever copied a function changed the name and modified the code you are on the second path. Now plenty of people have gone down that path and know it’s likely to produce bugs, but as long as you have reasonable mitigation strategies it can still be a good idea. Building a tool that does similar things with larger sections of code would be dangerous, but with a little care it could still be useful. In the early days of Fortran compilers they tended to be buggy so people would often money patch the output. http://en.wikipedia.org/wiki/Monkey_patch http://en.wikipedia.org/wiki/Monkey_patch While error prone this was significantly faster than hand coding in assembler from the start. This died out with the invention of better compilers, but plenty of good software was written before then. PS: I wish most software could be written using the first approach. I just don't think that's possible.

by mfukar 16y ago

Retric 16y ago

There are basically two ways to write software you can either completely understand the problem and create a completely understood solution, or you can approximate a reasonable solution and then patch. Now when it’s possible the first approach is far better, unfortunately some of the worst systems where created when people tried to use the first approach when it was simply too complex for any one person to understand. If you have ever copied a function changed the name and modified the code you are on the second path. Now plenty of people have gone down that path and know it’s likely to produce bugs, but as long as you have reasonable mitigation strategies it can still be a good idea. Building a tool that does similar things with larger sections of code would be dangerous, but with a little care it could still be useful. In the early days of Fortran compilers they tended to be buggy so people would often money patch the output. http://en.wikipedia.org/wiki/Monkey_patch http://en.wikipedia.org/wiki/Monkey_patch While error prone this was significantly faster than hand coding in assembler from the start. This died out with the invention of better compilers, but plenty of good software was written before then. PS: I wish most software could be written using the first approach. I just don't think that's possible.