Earlier quoted context omitted.
Thanks, you are right. A converse is logically equivalent to an inverse, so I'm only half wrong. =)
Ah, yes, everyone knows the three values of Boolean logic...
true, false and null
Never use a dependency that you could replace with an afternoon of programming
281–290 of 333 posts
Re: Never use a dependency that you could replace with an afternoon of programming
#282Earlier quoted context omitted.
What do you mean by cheaper? By using a third party library you are writing twenty lines less code, so it's cheaper in that aspect. There are probably libraries that are faster than your twenty lines of un-optimized code, so it's cheaper as far as computing resources are considered too. The only time it could matter is when you ship the code to the client through the wire (such as a Javascript bundle).
It’s cheaper in the sense that it is faster to write and maintain those 20 lines of code. Because someone has to evaluate the library, understand it well enough to actually call it and then make sure it stays up to date. And often there are a few lines of code to translate your data into a form that the library requires etc.
Plus for every developer to come, one call to an external library usually also means 30 pages of documentation to trawl through if they ever want to change anything, 29.9 of which is completely irrelevant to whatever your narrow use case is.
That's the real cost. The size of the code means absolutely nothing.
Re: Never use a dependency that you could replace with an afternoon of programming
#283Re: Never use a dependency that you could replace with an afternoon of programming
#284Earlier quoted context omitted.
I came here just to say this. "This'll take an afternoon" - three weeks later...... Programmers are notorious for this. BUT even apart from this problem ... you absolutely should use every dependency you can that will save you time. Try to write less code not more. When you write code you write bugs, add complexity, add scope increase need for testing, increase the cognitive load required to comprehend the software,…
Found the NPM user. Dependencies have costs: - Dependencies break over time. They have a nonzero maintenance cost. - They impose API boundaries on you that may not fit your existing data structures - It's harder to change underlying bugs - They might introduce security issues Sure, use dependencies. But there's a reasonable position between "never write any code" and "never take on dependencies". Of which NPM is one…
This is pretty much spot on. Except you also missed the main cost, which is the insane amount of time it takes to learn the 85 dependencies on your project to an extent that you actually understand what your code is doing.
Every single project I go into seems to have a smorgasboard of dependencies, then when I take the time to investigate one of them I find out it's being used incorrectly by at least 50% of the team because they don't even understand how they work at the most basic level. Which is pretty understandable because by the time anyone gets through understanding 10 of the 85, they've probably been kicked off the team for not actually building anything.
People love to say rubbish like "write less code!", as if LoC is the only metric that matters (weren't we past that thought process by the 90s?). Which goes a long way to explaining all the fucking terrible codebases I have to work with where it's impossible to accomplish anything without reading documentation for 8 hours, when it would take 20 minutes to just read even a semi-readable piece of code that implements whatever requirements you need from the dependency.
Re: Never use a dependency that you could replace with an afternoon of programming
#285Earlier quoted context omitted.
> This is horrible advice. There's a reason that you don't write your own hashtable implementations. Of course you do and release(d) them as open source (public domain). Take Java - it has decent a HashMap but it's node based. It's memory inefficient to a point its nodes and arrays are top 3 of memory consumption. An array based hashtable takes around 3.6 times less memory for larger ones (on 4bytes compressed pointe…
> Of course you do and release(d) them as open source (public domain). How ironic though. Of course it did work a few times, but if the advice is to not use dependencies, then the better advice would be to not use dependencies that were written in an afternoon to avoid using some other dependency :)
>How ironic though.
Indeed! Although I spent like a weekend to do it (the inital release was 512 loc). It passed all standard jdk/jsr-166 Map tests[0] and then some more, incl. perf., memory consumption, garbage collection harness. Tests are also public domain. Also the release is not available as dependency, so the interested user would have to clone the repository on their right own.
The part with afternoon deps would be that all their code can be read and cloned, if need be. Free to pick the few functions needed - I'd assume around 200-400 loc top.
[0] http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test...
Re: Never use a dependency that you could replace with an afternoon of programming
#286Earlier quoted context omitted.
Again my general rule - you (generic you) are no special snowflake. What are the chances that you come across a bug in a library that has had 2,176,677 (in the case of Dapper) or Entity Framework (supported by MS) that no one else has come across, found a workaround, and posted the answer somewhere on the Internet compared to your code where you didn’t think about a corner case?
Literally all the time. I can count on one hand[0] the number of JS dependencies I've used in enterprise/large projects for extended periods of time where I've never needed to manually debug the library or read the source code. For enterprise software, sometimes the easiest solution is to directly hotpatch a vendored version of the dependency. This is especially true with dependencies where bugs are fixed in major ve…
I've had some serious train wrecks because of shit NPM libraries over the years.
Probably the worst was with a decently popular library someone had brought in, that tried to do a refactor from callbacks to async/await, without understanding at all how async/await worked. They'd leaked an async operation in the library code, so 'await'ing a specific function call in their API that returned a promise, didn't actually await everything the call was doing, ending up in a debugging nightmare. Of course their perfectly manicured suite of 8000 tests with 110% test coverage didn't catch it either, because the number of people who can write good quality tests is shockingly low, and library-writers aren't somehow magically ahead of the pack in that regard.
JS really feels like PHP did back when I was a newbie learning that shit. In other ecosystems, the 95th percentile devs seem to write all the libraries, so everyone comes here and posts repeatedly about how great dependencies are. In JS, it's the average dev writing all the libraries, and the average dev's code is enough to make my brain bleed.
I'm a big proponent of different advice for different ecosystems. If you're doing front-end JS, the pendulum has swung so far to one side that 'NIH syndrome' is treated like it's going to lead to the fourth reich, which makes 'chill out a bit on dependencies' pretty good advice if you're looking to get a leg up in the industry. But I'm sure there's other ecosystems where the same advice will just leave you with a tangled mess while your competitors leapfrog you in productivity with a good 3rd party dependency.
I'd say take any advice in threads like these with a grain of salt unless it's given in a bit of a narrower context. Taking some one liner about software engineering in general and applying it to your specific project is probably just a coin flip as to whether it's going to improve your code or not.
Re: Never use a dependency that you could replace with an afternoon of programming
#287Earlier quoted context omitted.
Ah, yes, everyone knows the three values of Boolean logic...
true, false and null
Actually it's True, False, and FileNotFound. :o)
Re: Never use a dependency that you could replace with an afternoon of programming
#288Earlier quoted context omitted.
Call me an iconoclast, but I think array languages are more suitable for general purpose programming than even general purpose languages.
As someone who is not well versed in APL/J/K, how do they deal with structured data like JSON? Is there some sort of DSL like jq built into them?
Because kdb+/q has such few datatypes and you can't define anymore, it's very easy:
q) .j.k"[2.2, 3.5]"
2.2 3.5
q) .j.j 0 1 2 3
"[0,1,2,3]"
q) h:hopen `::6666
q) h(+;1;1)
2
Much like Common Lisp and SmallTalk, you can easily connect to production nodes and modify code while the service is running.
It's rare to find such a dynamic, flexible, and interpreted language that also has world class performance, even often beating hand written C. Combined with an integrated database, you get a distributed system that can't be beat, at least performance-wise. And the craziest thing is that all of this sits in at 650kb executable with libc has the only dependency. And all probably in less lines of code than a simple javascript webapp!
Re: Never use a dependency that you could replace with an afternoon of programming
#289I agree with the spirit of this article.
However, the problem is that most of the time when we think "I could build that in an afternoon!" we are underestimating the complexity involved.
Sometimes it takes an afternoon of coding and months of debugging.
Re: Never use a dependency that you could replace with an afternoon of programming
#290At lest in web development, the website is always changing thus so is the code. Therefore the maintenance burden favours bespoke code over libraries as the former is easier to adapt to changing requirements.
However ultimately in reality a decision based on product ownership culture, when it’s more important to produce results now ( velocity) rather than in a few months time (maintainability). It’s hard to change culture.