4 ms·
It's not about fewer lines, it's about fewer layers. If you can abstract out portions of the code with your more powerful language, you can test it independentl
by Xichekolas 19y ago
It's not about fewer lines, it's about fewer layers. If you can abstract out portions of the code with your more powerful language, you can test it independently and know it works, then build on it. The fewer layers you have to hold in your head, the easier the code is to modify and maintain.
Really productive programmers win by writing themselves APIs as they go. These can be reused in the future (hence the productivity multiple grows over time). As PG and others have said multiple times, you can be way more productive if you design a language for the problem domain, then use that language to solve the problem. That is what more powerful languages allow you to do.
It's not so much about trying to condense lines of code, it's about how many things you have to focus on at once (the fewer things you need to pay attention to, the easier it is to work with). Since any modern language handles all the minutiae of disk access for me, I can read and write to files with one or two lines. I don't have to care how it's done.
If you think I'm just stating the obvious, I rewrote a project in my last job in about three weeks that took the original team of four people two months to implement. The only thing that allowed me to achieve that kind of speedup was that I used an existing SOAP library (this was a web app with a web service back end for the data) instead of all the kludgy custom XML parsing they were doing. They had different code on each page of the web app for handling the webservice calls. It may sound retarded (because it is), but I have seen that kind of situation a hundred times, so I have to believe that that is the kind of code the average programmer churns out.
I don't claim to be a rockstar either. I know I've written a ton of horrendous, kludgy, redundant crap in my lifetime too. I think it just happens when you don't have a clear idea of what the end product will be, and don't take the time to refactor as you go.
- Tichy 19y agoDon't abstractions usually induce more layers, not fewer layers?
- Xichekolas 19y agoBut fewer layers you have to pay attention to... you don't have to think about lower layers, you treat them as if they work, and build from there.