3 ms·

> 3) For things that are not cryptography, I can usually write it better myself. We've accepted specialization in most aspects of modern day society as a good

> 3) For things that are not cryptography, I can usually write it better myself. We've accepted specialization in most aspects of modern day society as a good thing. I fail to see, outside a small subset of programming, how you will always be able to write better code yourself for whatever domain you're working on. > 5) I have a much better sense of what the code is doing this way. This is not scalable.

forgotmypw17 4y ago
> I fail to see, outside a small subset of programming, how you will always be able to write better code yourself for whatever domain you're working on. Through practice. But also, through realizing that when you look closely, many libraries are crap inside. > This is not scalable. I specialize in things which do not scale.
- dirtybirdnj 4y ago
  This feels to me like one of those "you have to learn these lessons to know how / when / why to apply the skill" types of things. To the uninformed what your are doing looks insane. I think people project their fear of the "black box" that is "libraries" and forget that mere mortals like themselves wrote these tools to begin with. The hard part is knowing when / what to re-use, and most importantly when you are ACTUALLY skilled enough to do it better and it makes sense to do so. There's a confluence of prevailing winds that makes this strategy possible or not possible.
  - mattgreenrocks 4y ago
    > To the uninformed what your are doing looks insane. I think people project their fear of the "black box" that is "libraries" and forget that mere mortals like themselves wrote these tools to begin with. This is what expertise looks like: it isn't Googlable, nor is it ChatGPTable. You can get a rough idea of the quality of most libraries in about 10-20m typically, usually by playing with the library or browsing the code. Some red flags I look for: lack of tests, excessive number of commits, excessive number of dependencies, lack of focus in scope, etc. One alternative I use frequently: lock dependencies up in a module, and write some glue code intended to act as the interface to that dependency. It is sometimes the case in which you have to use a library but it is not very good, or it has a horrible bug you can correct by exerting more precise control over how the library is called.
    - throwaway173738 4y ago
      To add to the list of red flags are libraries which expect me to write callbacks and which don’t give me any control over the control flow in my program. A lot of messaging systems like QPID Proton do this. It’s like the developers couldn’t anticipate that I might want to wait on input from more than one file descriptor so they didn’t bother to build input handling separately from the core protocol that processes the input and yields state changes. I see an awful lot of crappy libraries that follow this pattern. It’s typified by a function or functions that take a file name or url and that expects you to register callbacks for everything. Typically they spawn tons of threads to interleave input. Then you have to poll with timers in a separate thread if you ever want to respond to input from eg a serial port alongside messages. It’s way more complicated than it needs to be.
mattgreenrocks 4y ago
> We've accepted specialization in most aspects of modern day society as a good thing. I fail to see, outside a small subset of programming, how you will always be able to write better code yourself for whatever domain you're working on. It's strange that using fewer third-party dependencies has to be defended on a site called Hacker News. Also, the code you NIH doesn't have to be superior to the third party code. It merely has to not get in the way for what you're doing. This is different from being "better," which has many dimensions to it. Example that comes to mind: I could reach for something like libuv, or I could just use POSIX for synchronization primitives. I'd prefer to the see the latter in most code unless there were explicit reasons for libuv, such as cross-platform support.
- justcool393 4y ago
  i don't think anyone is arguing for one liner dependencies here.
nitwit005 4y ago
You're imagining you can get away with not understanding the third party code at all. That's never worked. You need to have a working model of how a library works to use it in a performant way, which is why most libraries document their architecture, and have usage guidance. And you'll find bugs, because there are always bugs. You need some strategy for what to do when that happens.
- nailer 4y ago
  > And you'll find bugs, because there are always bugs. You need some strategy for what to do when that happens. Fix them, I imagine. Which is easier if you're better at writing code than the author of whatever someone threw on (package manager of choice).

forgotmypw17 4y ago

> I fail to see, outside a small subset of programming, how you will always be able to write better code yourself for whatever domain you're working on. Through practice. But also, through realizing that when you look closely, many libraries are crap inside. > This is not scalable. I specialize in things which do not scale.

dirtybirdnj 4y ago
This feels to me like one of those "you have to learn these lessons to know how / when / why to apply the skill" types of things. To the uninformed what your are doing looks insane. I think people project their fear of the "black box" that is "libraries" and forget that mere mortals like themselves wrote these tools to begin with. The hard part is knowing when / what to re-use, and most importantly when you are ACTUALLY skilled enough to do it better and it makes sense to do so. There's a confluence of prevailing winds that makes this strategy possible or not possible.
- mattgreenrocks 4y ago
  > To the uninformed what your are doing looks insane. I think people project their fear of the "black box" that is "libraries" and forget that mere mortals like themselves wrote these tools to begin with. This is what expertise looks like: it isn't Googlable, nor is it ChatGPTable. You can get a rough idea of the quality of most libraries in about 10-20m typically, usually by playing with the library or browsing the code. Some red flags I look for: lack of tests, excessive number of commits, excessive number of dependencies, lack of focus in scope, etc. One alternative I use frequently: lock dependencies up in a module, and write some glue code intended to act as the interface to that dependency. It is sometimes the case in which you have to use a library but it is not very good, or it has a horrible bug you can correct by exerting more precise control over how the library is called.
  - throwaway173738 4y ago
    To add to the list of red flags are libraries which expect me to write callbacks and which don’t give me any control over the control flow in my program. A lot of messaging systems like QPID Proton do this. It’s like the developers couldn’t anticipate that I might want to wait on input from more than one file descriptor so they didn’t bother to build input handling separately from the core protocol that processes the input and yields state changes. I see an awful lot of crappy libraries that follow this pattern. It’s typified by a function or functions that take a file name or url and that expects you to register callbacks for everything. Typically they spawn tons of threads to interleave input. Then you have to poll with timers in a separate thread if you ever want to respond to input from eg a serial port alongside messages. It’s way more complicated than it needs to be.

mattgreenrocks 4y ago

> We've accepted specialization in most aspects of modern day society as a good thing. I fail to see, outside a small subset of programming, how you will always be able to write better code yourself for whatever domain you're working on. It's strange that using fewer third-party dependencies has to be defended on a site called Hacker News. Also, the code you NIH doesn't have to be superior to the third party code. It merely has to not get in the way for what you're doing. This is different from being "better," which has many dimensions to it. Example that comes to mind: I could reach for something like libuv, or I could just use POSIX for synchronization primitives. I'd prefer to the see the latter in most code unless there were explicit reasons for libuv, such as cross-platform support.

justcool393 4y ago
i don't think anyone is arguing for one liner dependencies here.

nitwit005 4y ago

You're imagining you can get away with not understanding the third party code at all. That's never worked. You need to have a working model of how a library works to use it in a performant way, which is why most libraries document their architecture, and have usage guidance. And you'll find bugs, because there are always bugs. You need some strategy for what to do when that happens.

nailer 4y ago
> And you'll find bugs, because there are always bugs. You need some strategy for what to do when that happens. Fix them, I imagine. Which is easier if you're better at writing code than the author of whatever someone threw on (package manager of choice).