There is no borrow. When i see external code that may be useful to my pgm i want to understand it, tailor it for my needs, prune the unnecessary.
I want to see how long I can keep the codebase small.
You don't return to all your code. 90% of my code never gets read again. Not worth thinking about.
When I do return to old code I lately have no trouble. I think it's the unit tests. Little easily digestible atoms of semantics.
If everyone does this less code will be shared, but shared code will become more timeless. Easy to return to it in six months.
You don't have to be an expert in other people's code, design decisions, error paths. Just concepts and happy paths. So you see opportunities to delete.
Perhaps borrowing code is also learned from static languages. Just a delete-if loop in c can be nontrivial to read.
We're really getting to the heart of things now, I think. :)
---
There is no borrow. When i see external code that may be useful to my pgm i want to understand it, tailor it for my needs, prune the unnecessary.
That's one kind of borrowing, as far as I'm concerned. All I'm talking about is tech one person comes up with first and another person takes advantage of. Whether it's called code reuse or borrowing or whatever doesn't matter to me.
Borrowing code is essential for arriving at the best combinations of ideas. Two heads are better than one and all that.
---
I want to see how long I can keep the codebase small.
I want my code to be small only because I want it to be valuable to me when I go back to read it. Value comes first.
And on that topic...
You don't return to all your code. 90% of my code never gets read again. Not worth thinking about.
...if I believed that, then maybe I wouldn't even care if my code were small. :)
I return to my code more and more as I've developed better tools to future-proof it. If any piece of code isn't worth returning to, then why was it written in the first place?
Okay, maybe for one-shot scripts or something. ^_^ Like I said, I primarily write abstract, generalized code (or at least that's what I perceive I do).
---
When I do return to old code I lately have no trouble. I think it's the unit tests. Little easily digestible atoms of semantics.
Comments are good for that too, but unit tests are certainly easier to keep up-to-date. :)
---
If everyone does this less code will be shared, but shared code will become more timeless. Easy to return to it in six months.
You don't have to be an expert in other people's code, design decisions, error paths. Just concepts and happy paths. So you see opportunities to delete.
I think we're on common ground here. ^_^
---
Perhaps borrowing code is also learned from static languages. Just a delete-if loop in c can be nontrivial to read.
What do you mean by a static language? You keep referring to static and dynamic languages, but in my experience "dynamic language" is a term for a language with dynamic typing. I think C loop boilerplate is something to blame on the lack of a convenient closure/block syntax, not the type system.
If by "static language" you mean a language that can't be changed, that makes way more sense. But even in a language like Arc that's open to customization, we still share code.
Actually, you probably mean something different by "borrow" too, such as using code as a black box. In that case, you make sense again. :-p
The full translation is "Perhaps the practice of taking code for granted has come from a history full of languages where code isn't formatted in a personalizable enough way for its purpose to be clear." I don't want to put words in your mouth, though. XD
"Perhaps the practice of taking code for granted has come from a history full of languages where code isn't formatted in a personalizable enough way for its purpose to be clear."
Yep. There's more pressure to take code for granted in languages so verbose that everything is non-trivial to read. It seems to have been a slippery slope from having such languages to assuming take-for-granted-ability was an unabashed virtue.
That is perhaps the biggest disadvantage of C and relatives[1]: they kept programmers from bulking up on their reading muscles, the ability to read concise code patterns at a glance. Perhaps this is partly what Dijkstra was referring to as 'brain damage'. (http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498....) [2] Fortunately it is curable, no matter what he said.
[1] What I was referring to as static languages, where functions can't be redefined dynamically.
