3 ms·

> The ability to type "varname." and get a list of what I can do with it is so powerful. I can use a (well designed) open source library that I just NuGet'ed in

by pimeys 15y ago

> The ability to type "varname." and get a list of what I can do with it is so powerful. I can use a (well designed) open source library that I just NuGet'ed in, without ever even looking at its docs. Can you write PHP without alt-tabbing to the manual all the time? Can you do it with Ruby? I usually don't need any documentation with Ruby. I remember how the libraries I use work. But I'm that kind of guy, who first reads the source from Github and then start programming the thing by my own. I hated with Microsoft libraries, that I had to use reflector to see inside the library, when it didn't work like it should've been. Now I'll hit the fork button if the library contains a bug and I need a fast fix right now.

kenjackson 15y ago
Reading code seems like a crazy inefficient way to understand libraries. Maybe you're just a much better code reader than anyone I've ever met -- in which case, more power to you.
- mgkimsal 15y ago
  I see this attitude of "read the library source" most often from Ruby people, but some advocates of larger PHP frameworks advocate that approach as well, and I just don't buy it. At least, not across the board. Sure, if there's a bug, I can try to track it down, maybe submit a patch, but if something can't be bothered to be documented, I'm not sure I want to spend my time depending on that library. I've certainly made exceptions to that - we probably all have - but treating that as the defacto way to approach using third party libraries is wholly inefficient (as you said). One might take a better approach by saying "read and learn from the test cases". I've often found that for the libs I try that with, that have tests, they're often rather... what's the word? I can't easily figure out how to apply the library to the problem I have at hand. Sometimes it's because my problem is ill-defined, and sometimes it's because the tests only cover superficial cases, and even if the lib docs say "can do xyz", it's not tested not documented. Such is software...
  - pimeys 15y ago
    I can understand your point. But for me the short documentation has never been such a problem. There's usually some example cases how to use the library in the README.md, and that is mostly everything I need. Sometimes it is necessary to read through the code for better understanding, and I really like to be able to do that. Without Github though, the situation would be much more annoying.
  - ibisum 15y ago
    >I see this attitude of "read the library source" most often from Ruby people, but some advocates of larger PHP frameworks advocate that approach as well, and I just don't buy it. Well, when you are looking at the results of the MS Visual Studio IDE, you're reading code, too. After all, the tab-completion lists come from good integration with the parser. My perspective is that you should be reading sources, if you have it. Its just what a good coder does. If you don't understand what you're reading: probably thats where you'll find your bug/issue/whatever. When you know for sure the code is running, and for sure how its running with no assumptions, because you've read and understand the code itself,f you gain masterful control over it.
- ibisum 15y ago
  Reading code is the only way to know what the machine is doing. Good programmers choose to ignore little, because the more they do it, the better they get at it ..

by pimeys 15y ago

kenjackson 15y ago

Reading code seems like a crazy inefficient way to understand libraries. Maybe you're just a much better code reader than anyone I've ever met -- in which case, more power to you.

mgkimsal 15y ago
I see this attitude of "read the library source" most often from Ruby people, but some advocates of larger PHP frameworks advocate that approach as well, and I just don't buy it. At least, not across the board. Sure, if there's a bug, I can try to track it down, maybe submit a patch, but if something can't be bothered to be documented, I'm not sure I want to spend my time depending on that library. I've certainly made exceptions to that - we probably all have - but treating that as the defacto way to approach using third party libraries is wholly inefficient (as you said). One might take a better approach by saying "read and learn from the test cases". I've often found that for the libs I try that with, that have tests, they're often rather... what's the word? I can't easily figure out how to apply the library to the problem I have at hand. Sometimes it's because my problem is ill-defined, and sometimes it's because the tests only cover superficial cases, and even if the lib docs say "can do xyz", it's not tested not documented. Such is software...
- pimeys 15y ago
  I can understand your point. But for me the short documentation has never been such a problem. There's usually some example cases how to use the library in the README.md, and that is mostly everything I need. Sometimes it is necessary to read through the code for better understanding, and I really like to be able to do that. Without Github though, the situation would be much more annoying.
- ibisum 15y ago
  >I see this attitude of "read the library source" most often from Ruby people, but some advocates of larger PHP frameworks advocate that approach as well, and I just don't buy it. Well, when you are looking at the results of the MS Visual Studio IDE, you're reading code, too. After all, the tab-completion lists come from good integration with the parser. My perspective is that you should be reading sources, if you have it. Its just what a good coder does. If you don't understand what you're reading: probably thats where you'll find your bug/issue/whatever. When you know for sure the code is running, and for sure how its running with no assumptions, because you've read and understand the code itself,f you gain masterful control over it.
ibisum 15y ago
Reading code is the only way to know what the machine is doing. Good programmers choose to ignore little, because the more they do it, the better they get at it ..