6 ms·

> Your handrolled solution is likely worse than the library anyway This assumption led to a lot of O(n^2) left-padding happening over the years, via left-pad f

> Your handrolled solution is likely worse than the library anyway This assumption led to a lot of O(n^2) left-padding happening over the years, via left-pad from node.js. Ideally libraries would be well-tested and of high quality, but at this point there may be too many of them to vet. My own 2 cents is that if it's easier to implement the code from scratch than to evaluate and choose a library, perhaps the invent-it-here choice works best.

jolux 7y ago
If you're better at this than LAPACK to the extent that you do not even trust it to function correctly, more power to you.
- throwsprtsdy 7y ago
  My point is not that I'm better at it than some specific library, it's that choosing a library would take more effort than writing some straightforward code. EDITED TO ADD: In fact getting LAPACK into the build if it's not already there is more of a maintenance imposition than just writing a couple of lines of code for this.
  - jolux 7y ago
    Not if there already exist bindings in your language, which is the case more often than not these days.
- BubRoss 7y ago
  I'm not going to integrate LAPACK for a single line expression.
  - jolux 7y ago
    LAPACK is the underlying library behind most linear algebra packages in other languages and furthermore it was just an example. My guess is that you probably don’t have just one line of matrix manipulation ever, in which case using a well established library is a good idea. If not, then sure. Do it yourself. But that’s still more code that you have to maintain now.
    - username90 7y ago
      > But that’s still more code that you have to maintain now. 10 lines of code is easier to maintain than a whole dependency.
      - jolux 7y ago
        That's arguable, because 10 lines of code almost never just stays 10 lines of code, and my point in the first place was more contesting that the dependency is hard to choose, or that there aren't solid proven libraries for this.
        username90 7y ago
        > 10 lines of code almost never just stays 10 lines of code This is only true when you implement business logic, not when you implement algorithms.
        jolux 7y ago
        The difference between those two things is often blurry from a distance. Business logic is algorithmic too, it's just a question of how specific and complex the algorithm is.
        username90 7y ago
        Business logic changes and grows more complex over time, how to invert a matrix doesn't. Trust me, I implement algorithms for a large library for a living, they very rarely change or grow.
        jolux 7y ago
        I’m aware that you have a definition of “algorithm” that only includes things that don’t change, and I think I know roughly what you mean, but also algorithms are pretty much unavoidable in line of business development. Whether or not they’re well defined, sufficiently general, and have a good name is another thing. In this case you’re right but in a codebase with no documentation where people are doing things like re-implementing JSON parsers from scratch, as I was stuck with at my last job, I’m very wary of “this algorithm is simple” because I don’t trust my coworkers in that case to actually know what they’re talking about. I’m completely sure you do, for what it’s worth.
danShumway 7y ago
Parent's comment is getting downvoted to all heck, but it is completely, obviously true in the Javascript ecosystem. If you're a competent-to-expert Javascript programmer, you will regularly run into libraries that are not coded to your standards. And honestly, even throwing those libraries out, it's sometimes not even a question of doing a "better" job than the library. The library is designed for general-use, but my needs aren't always general-use. Sometimes libraries are good, but they're wasting time on stuff that I don't need. This is the reason why every Unity game on the web takes 4-5 seconds to load, and my custom engine takes on the order of milliseconds to load. It's not because I'm a better programmer, it's not because Unity devs are crap, it's purely because I know exactly what my engine needs to do, and I don't waste time on anything that it doesn't need to do. I can think of tons of examples where I've started out using an existing library and then realized that getting rid of abstraction made my code faster and easier to debug. Heck, I can think of tons of times where I've privately forked libraries and deleted codepaths or rewritten algorithms to make them more efficient for my use-cases. There are very few JS libraries that I regularly use where I have not at some point needed to care about their internals. And I am definitely not a crazy, insane, masterful programmer. If I'm occasionally circumventing d3 internals or doing stuff manually, it's not because I'm special. People have this assumption that if something has a bunch of stars on Github, there's no way they could possibly code something more appropriate or efficient, and for a lot of people, that just isn't true.
- Paperweight 7y ago
  "Surely this core cryptography library with 21 contributors and led by a superstar Node.JS dev with 9+ million weekly downloads and 1000+ dependants will be a great example to read and learn from..." Opens source code. Closes source code. "Well, looks like I'm going to be a Rust developer from now on."
  - NohatCoder 7y ago
    Just don't ever look into the crates, as long as the lid stays on the crates are perfect, no reason to believe otherwise.
  - 7y ago
ulucs 7y ago
That’s just wrong. JS uses ropes for the string implementation, so even the inefficient left padding is O(n).
- throwsprtsdy 7y ago
  You're right. I'd correct my original post if I could. I stand by my point but I chose a terrible example.
jackcviers3 7y ago
That's because Node and JS are geared towards software engineers new to the field. The ecosystem is geared towards delivering things quickly and cheaply. Like most things, that will work 80% of the time. Most projects are shacks, not skyscrapers. The problem is, 20% of projects are skyscrapers, and you can't build those out of pine. Sometimes, you can't build them out of standard steel and rear. You actually have to pick the correct raw materials, create a stable and maintainable architecture, adhere to strict regulatory standards, and use advanced tools to create a working edifice. The software industry's current practices have encouraged a one-size-fits-all mentality, and that just means that it's almost time for another SLDC paradigm shift to swing the pendulum back the other way to achieve balance. It will happen, be patient.

jolux 7y ago

If you're better at this than LAPACK to the extent that you do not even trust it to function correctly, more power to you.

throwsprtsdy 7y ago
My point is not that I'm better at it than some specific library, it's that choosing a library would take more effort than writing some straightforward code. EDITED TO ADD: In fact getting LAPACK into the build if it's not already there is more of a maintenance imposition than just writing a couple of lines of code for this.
- jolux 7y ago
  Not if there already exist bindings in your language, which is the case more often than not these days.
BubRoss 7y ago
I'm not going to integrate LAPACK for a single line expression.
- jolux 7y ago
  LAPACK is the underlying library behind most linear algebra packages in other languages and furthermore it was just an example. My guess is that you probably don’t have just one line of matrix manipulation ever, in which case using a well established library is a good idea. If not, then sure. Do it yourself. But that’s still more code that you have to maintain now.
  - username90 7y ago
    > But that’s still more code that you have to maintain now. 10 lines of code is easier to maintain than a whole dependency.
    - jolux 7y ago
      That's arguable, because 10 lines of code almost never just stays 10 lines of code, and my point in the first place was more contesting that the dependency is hard to choose, or that there aren't solid proven libraries for this.
      - username90 7y ago
        > 10 lines of code almost never just stays 10 lines of code This is only true when you implement business logic, not when you implement algorithms.
        jolux 7y ago
        The difference between those two things is often blurry from a distance. Business logic is algorithmic too, it's just a question of how specific and complex the algorithm is.
        username90 7y ago
        Business logic changes and grows more complex over time, how to invert a matrix doesn't. Trust me, I implement algorithms for a large library for a living, they very rarely change or grow.
        jolux 7y ago
        I’m aware that you have a definition of “algorithm” that only includes things that don’t change, and I think I know roughly what you mean, but also algorithms are pretty much unavoidable in line of business development. Whether or not they’re well defined, sufficiently general, and have a good name is another thing. In this case you’re right but in a codebase with no documentation where people are doing things like re-implementing JSON parsers from scratch, as I was stuck with at my last job, I’m very wary of “this algorithm is simple” because I don’t trust my coworkers in that case to actually know what they’re talking about. I’m completely sure you do, for what it’s worth.

danShumway 7y ago

Parent's comment is getting downvoted to all heck, but it is completely, obviously true in the Javascript ecosystem. If you're a competent-to-expert Javascript programmer, you will regularly run into libraries that are not coded to your standards. And honestly, even throwing those libraries out, it's sometimes not even a question of doing a "better" job than the library. The library is designed for general-use, but my needs aren't always general-use. Sometimes libraries are good, but they're wasting time on stuff that I don't need. This is the reason why every Unity game on the web takes 4-5 seconds to load, and my custom engine takes on the order of milliseconds to load. It's not because I'm a better programmer, it's not because Unity devs are crap, it's purely because I know exactly what my engine needs to do, and I don't waste time on anything that it doesn't need to do. I can think of tons of examples where I've started out using an existing library and then realized that getting rid of abstraction made my code faster and easier to debug. Heck, I can think of tons of times where I've privately forked libraries and deleted codepaths or rewritten algorithms to make them more efficient for my use-cases. There are very few JS libraries that I regularly use where I have not at some point needed to care about their internals. And I am definitely not a crazy, insane, masterful programmer. If I'm occasionally circumventing d3 internals or doing stuff manually, it's not because I'm special. People have this assumption that if something has a bunch of stars on Github, there's no way they could possibly code something more appropriate or efficient, and for a lot of people, that just isn't true.

Paperweight 7y ago
"Surely this core cryptography library with 21 contributors and led by a superstar Node.JS dev with 9+ million weekly downloads and 1000+ dependants will be a great example to read and learn from..." Opens source code. Closes source code. "Well, looks like I'm going to be a Rust developer from now on."
- NohatCoder 7y ago
  Just don't ever look into the crates, as long as the lid stays on the crates are perfect, no reason to believe otherwise.
- 7y ago

ulucs 7y ago

That’s just wrong. JS uses ropes for the string implementation, so even the inefficient left padding is O(n).

throwsprtsdy 7y ago
You're right. I'd correct my original post if I could. I stand by my point but I chose a terrible example.

jackcviers3 7y ago

That's because Node and JS are geared towards software engineers new to the field. The ecosystem is geared towards delivering things quickly and cheaply. Like most things, that will work 80% of the time. Most projects are shacks, not skyscrapers. The problem is, 20% of projects are skyscrapers, and you can't build those out of pine. Sometimes, you can't build them out of standard steel and rear. You actually have to pick the correct raw materials, create a stable and maintainable architecture, adhere to strict regulatory standards, and use advanced tools to create a working edifice. The software industry's current practices have encouraged a one-size-fits-all mentality, and that just means that it's almost time for another SLDC paradigm shift to swing the pendulum back the other way to achieve balance. It will happen, be patient.