Re:Vim's speed is not really the point (2013)
by rebootthesystem on Monday June 01, 2015 @02:31PM
(#9641002)
Once you have enough experience you do far less trial and error. I rarely write code that does not work. By that I mean, my code generally solves the problem to be solved on the first write and is generally significantly bug-free.
That's not because I am a genius or somehow super-human, I have a lot of experience and have developed a decent process of design-before-coding. Trial and error is really wasteful. It still has it's place in areas that might not be entirely clear. Outside of that, design-before-coding can save tons of time and aggravation.
In other words, coding is the end of a process, not the process.
Re:Vim's speed is not really the point (2013)
by wtetzner on Monday June 01, 2015 @05:01PM
(#9642128)
Ah, I think the difference is that usually when I'm working on something, it's a new problem, and I need some time to not only try to find a solution, but first understand the problem. I find that trying to write a solution helps me to get the problem space loaded into my head.
Different people have different processes, I suppose. And that's a probably a big reason for why people have different opinions on tools: they have different use cases.
Re:Vim's speed is not really the point (2013)
by rebootthesystem on Tuesday June 02, 2015 @01:00AM
(#9643956)
Whatever works.
The win isn't that you saved fractions of a second. It's that your quick edit was fast enough that it didn't interrupt your thought process.
> As an example, we are in the middle of a month-long process of designing a database for a project. Not one line of code has been written. Every day is devoted to database structure discussions and documentation. Once settled, the DB code might take a week to write.
You say this like trial-and-error isn't a valid way to design something. You can spend as much time as you want designing things up front, but until you try them, there's a good chance you won't know if it's a good design. You'll always find issues later on.
Another way to look at it is this: you could write down you ideas on paper or in diagrams, or you could write them down in code, and run them to see if they make sense/work the way you think they should.
The code you write while designing doesn't have to be the same codebase as the final product. It can just be a bunch of small programs you use to help formulate your ideas.