Hacker News Reader

Comment by throwawaaarrgh | Hacker News Reader

The solution is to do more with less. Devs are taking advantage of a wealth of abstraction and being buried under it. But they actually don't need it.

You do not need some 3rd party library to write a command line interface for your python code. You do not need three different projects just to maintain your list of installed packages or virtual environment. And you don't need a package to wrap around loading environment variables.

Just learn how to do these things in a simpler way, without the extra deps. Will there be some more boilerplate code? Yes. But it will be your code, and it will be so simple that you will learn to write it very well. In addition: make your code loosely coupled and composeable, and overload existing code with additional functions when feasible, rather than starting a new project from scratch. Press your company to let you contribute back to OSS, as this lets somebody else do more of the maintenance, and has the side effect of reducing the total number of software projects. (It immediately saves you money and time. Kind of stupid that more of us don't do this already.)

Simplifying is hard. But when you get good at it, you find you're much more buoyant.

View on HN

I come from a Python background so libraries were always just a pip install away.

In the past year, however, I've been working on a large C++ codebase (couple million lines) and the result has been a considerably greater amount of "roll your own."

This has filtered back into my Python. If it's not in the standard library, I don't install it unless I really need it.

My boss always tells me that you can probably write it faster than a library, something I never used to believe. Until I tried it. I needed to check which of two version strings, of XX.XX.XX.XXXX format, were bigger. I tried the most recommended version number library, then I tried writing my own solution, the simplest solution I could think of:

    def version_compare(v1: str, v2: str) -> int:

        """
        Compares two versions.

        Parameters
        ----------
        v1: str
        v2: str

        Returns
        -------
        int
            1 if v1 is greater, -1 if v2 is greater, 0 if equal.
        """
        for el1, el2 in zip(v1.split('.'), v2.split('.')):
            if el1 != el2:
                return 1 if int(el1) > int(el2) else -1
        return 0

My code was faster by like 20x. Libraries are bloated and you probably only need a small subset of the functionality, so write your own code has become my mantra.

TIL python type hints: https://docs.python.org/3/library/typing.html

Thanks.

Another benefit, that IMO is as big if not bigger, is that you can easily make changes to this code whereas changes on the library side may be hidden behind configuration, impossible at all, or god forbid even require a wrapper anyway. In the above example, if you wanted this instead to return the version number string that is larger, that's an easy change and one that's very obvious from the PR what it is doing.

Little bit off topic perhaps but why encode the types a second time in the comment when you already have the annotations?

Its a numpy style docstring. PyCharm can be configured to auto generate them. I guess I just add the types to be thorough.

Ideally I want to generate api documentation via a tool. A long time ago I wrote a script to parse the AST and generate markdown from the docstrings and function information, but it was mediocre and I haven't wanted to use sphinx because its too heavy and doesn't seem to produce ideal markdown output.

numpy seems to sometimes use type hints in the docstring, other times not: https://numpydoc.readthedocs.io/en/latest/format.html#parame...

Now think about how (some) of these libraries came to be:

Someone like you wrote something like the above for their needs. Then they needed it again in another program. Then in another. They figured, why not put this into a library I can use across all my projects. Maybe this was internal only. Maybe at some point they thought: why not push this out there to github and upload it to a public repo and let other people use it.

Then someone (maybe the same person) needs not just XX.XX.XX.XXXX with actual numbers. For whatever reason their standard is vXX.XX.XX.XXXX[-RCX] or other variations that aren't just a simple number format.

Of course if you never ever have a need for that kind of version number (or whatever other "problem area" we apply this principle to) and only ever write one piece of software, you're fine with roll your own. But this is (one way) how libraries get "bloated". The fact that they are libraries (or frameworks if we think a little wider) need to take care of "all the problems" and not just a very specific one. Especially if it's open source and not an in-house only library which attracts lots of people with lots of different variations on the same problem. It's very hard to have a very opinionated stance of "this is what you get, change your version number standards, I'm not changing my library". Of course you can do that, but your library will probably end up in obscurity. The "can deal with anything you throw at us" is probably going to be more popular and if there's no Linus type guy doing code reviews before accepting contributions, you end up with sub-optimal code very quickly.

I've done the opposite before. I came to a code base that had various variations on sending email notifications for batch jobs. Like literally 20 jobs with 20 variations (well maybe it was 15 different ones with different types of bugs and quirks). I extracted them into an in-house library for sending a standardized version of these emails. In the end it had accumulated quite a few features for adjusting the email template, attaching various formats of output, automatically zipping it up etc. I'm pretty sure you might call it "bloated". In reality it made things better (consistent) for the users receiving those, easier for us to understand errors, faster to code new jobs and just calling one standard function that everyone knew how to use and that all bugs had been ironed out from over time. Import library, call function. Instead of deciding which other project to copy the email sending code from, finding out where in the mess of code it was, throwing it away again because "Oh yeah right, that project's version of it can't deal with this type of attachment etc.

This returns 0 for '1.2.3' and '1.2'. Might be fine if you are sure they have the same number of components, but otherwise is worth checking.

For our purposes, we never have strings that are other than the form XX.XX.XX.XXXX so there was no reason to generalize. Which improves the speed, makes it easier to read, and provides all the more reason not to use a library.

Meanwhile I've had to make changes to hand-rolled version comparison code in multiple systems because the original developers didn't account for the second segment of the version being greater than 9.

I'm absolutely not saying that you should have used a library, but pointing out the other side of the problem. If they had used an existing library to handle the versions, it wouldn't have had this issue. And test cases wouldn't help here because if they didn't think to code for multiple digits in the second spot, they likely wouldn't have thought to test for it.

There's enough benefits and drawbacks to library vs roll-your-own that I don't rigidly stick to one way or the other.

Or, you would have the same issue and the library developer wouldn't have time/care to fix it...

Also good sweng practices would dictate to put it in one function that is used in all places so you only need to fix it once.

Another slightly more general approach, which turns the string into a tuple of numbers and then uses tuple comparison, which gets "1.2.3" > "1.2" right, but does yield "1.2.0" > "1.2" which may or may not be what you want:

  v1 = tuple(map(int, v1.split('.')))
  v2 = tuple(map(int, v2.split('.')))
  return (v1 > v2) - (v1 < v2)

(In Python 2 days, the last line could have been `return cmp(v1, v2)`, but sadly cmp() and .__cmp__() were removed in Python 3.)

And both of these implementations demonstrate an advantage of using someone else’s library: it has probably had more care put into it. And implementing these sorts of things yourself often leads you to compromise on functionality—though at the same time, using a misfitting library also leads to compromises. It can always go both ways.

GP had made clear the format was fixed, and writing 1 or 2 tests for it takes seconds, so I don't really agree with your conclusion.

Personally I mostly wanted to offer a warning to somebody else who might take this code.

I think you're demonstrating why libraries are slower.

For the specific use-case the OP had, the sorts of comparisons you're doing are unnecessary, so a custom-tuned compare is faster.

My experience is that it’s frightfully common for people to unintentionally oversimplify their implementation, or to forget that their implementation is too specific and improperly use it in a more general context. For example, to think they are only dealing with /^[0-9][0-9][.][0-9][0-9][.][0-9][0-9][.][0-9][0-9][0-9][0-9]$/ (and if the syntax really is that simple, then simple str comparison would be enough, as another comment suggested), but then discover somewhere down the line that perhaps some of the two-digit components can actually grow to three digits, or perhaps some suffix is added, or an additional component; or perhaps just use it for a different type of version string somewhere else in the program. Perhaps years later. (Mind you, if it violates your format expectations it may be better to immediately raise ValueError rather than using potentially-different semantics as you’d get if you used, say, packaging.version.parse().) As it stands, the provided implementation didn’t mention its limitations in its documentation. That is bad and makes it much more likely to be used improperly. It should have said something like “compares version numbers in 'XX.XX.XX.XXXX' format”.

(I’m not speaking for BYO or library philosophies, merely describing considerations and caveats of both.)

I think you're demonstrating why libraries are slower.

… because they’re probably better thought-out and less fragile?

Sure, that, among other reasons.

If the goal is to always have the best thought-out and least-fragile solution for any given code operation, then the trade-offs are that it's possible the library solution is going to not fit quite as perfectly as it night, and it will almost certainly be slower.

why do you split the strings instead of comparing them directly ?

  >>> '99' > '11'
  True
  >>> '100' > '11'
  False

oh, I understood that the number of digit was always the same

As described it probably is, but using string comparison would make what is already fairly fragile (they must have the same number of components) even more fragile and sensitive to change (they must now always have dots and digits in the same place, and the failure mode is now completely invisible). More stuff to be aware of. In practice I find precious few actually fixed-width formats like this, and more than a few pieces of software have struggled to go from version 9 to 10 or 99 to 100 because of bad assumptions. Or even date formats, two digit year was fine until 2000 when you either wrapped around to zero again, or went up to 100 (and some date APIs have modelled years as the number of years since 1900 in this way).

This was one of the interview questions for my first ever programming internship at 19.

As a long time C++ developer, the modern trend of library package managers has always seemed insane to me. In C and C++ integrating with a dependency is no trifling matter. Beyond just simply making your executables bigger, you're also making the build process more complex, you're locking yourself to an interface, and you probably need to keep special considerations in mind; for example, some libraries need you to call a function when you load them. Therefore, people don't make trivial (i.e. things anyone can do in a few minutes) libraries, and you don't add dependencies unless you really need to.

When I started playing with C/C++ the first thing I complained about was how difficult package management was. Conan is not as simple as cargo or pip. It's often simpler to find a header only library and plop it into your repo, but you still have to modify build configurations to include it.

This is the first time I thought to myself "Maybe that's actually a good thing."

When you're prototyping, a package manager can be really convenient, because it lets you try things out really quickly without investing a lot of time. But once you have most things in place you really just want something that will remain stable for a long time.

> You do not need some 3rd party library to write a command line interface for your python code. You do not need three different projects just to maintain your list of installed packages or virtual environment. And you don't need a package to wrap around loading environment variables.

Couldn't agree more.

I'm going through the experience now of switching from Python to Lua and this experience of trying to do more with less is really eye-opening. I find that lots of things where Python has trained me to expect them to be one-liners are now idioms of half a dozen lines of code. ...but as I use them, I find myself introducing a lot of variation around each half-dozen-loc-idiom. Then the thought occurs to me: Should I make this into a utility function? And the answer is usually no: Because it would have to support all this variation and create a complex interface. Having to understand the interface would introduce as much complexity for the person trying to read/maintain my code as having to tackle half-dozen-loc-idioms where there could be one-liners.

Languages that default to simplicity and make-your-own-batteries force that thought process on developers, making them better developers in the process, able to produce more maintainable code.

Languages that default to batteries-included try to spare developers the work of having to think about such things, and the end result is way more messy.

My favorite aspect of lua is that it gives you all the tools to implement anything and do it simply. Python, C#, and many languages push you to find the “right” way to do things, and spend time searching through documentation to find the shortcomings of each option and which method may be optimal for your situation. It’s like walking into a hardware store with a specialized tool for everything—you spend your time worrying if you’re really using the right thing. Lua feels like a garage workshop with all the basic tools you need to quickly implement something on your own—master a few and only go hunting for something new when you’ve got no other choice.

That is an odd take on Python particularly, which has been widely lauded as a good language for exploratory coding - easy and quick to put something together and iterate on it. You seem to be claiming the opposite here.

> That is an odd take on Python particularly, which has been widely lauded as a good language for exploratory coding - easy and quick to put something together and iterate on it.

I think the point your parent was trying to make is that, at least in Python, there is a lot of emphasis put on doing things the python way e.g. list comprehensions over loops.

For myself, the python experience is... mediocre.

Ruby feels so much better. Between the embracing of functional programming and the pry gem, it feels much nicer to use. Sadly, it's not the strong horse in the race.

Lot of emphasis by whom? Yes, certain constructs are subtly encouraged (by documentation, community blogs, etc.), but there is no python police to enforce the One True Way(tm). You can still write your quick&dirty prototype using not-quite-pythonic-python if you prefer, allowing you to move and iterate just as fast as in Lua or Ruby.

At least that's been my experience with Python (after reluctantly getting used to the indentation as part of syntax :) ). Of course, different languages will appeal to different people, so I do not doubt your claim that Ruby suits you better. But the post I was replying to above was putting Python in the same bag as C/C++, which to me seems very inaccurate.

I've also fled to Lua. LuaJIT is "finished". Love2D has a few dependencies but they are big and slow. Love does releases only every couple of years. I occasionally grab some code from the internet, but I vendor it in, and now its my code.

You just described why I preferred Assembly early in my career, and C/C++ for the majority. Making your own batteries enables exponential opportunities to improve and optimize a project, simply because one knows all the parts, they are not externally sourced "batteries-included" features.

Is the natural conclusion of this argument that we should be writing assembly because that has the fewest batteries included? Or is there a counterveiling force?

> But it will be your code

And your colleagues will have great difficulty figuring out how it works because there is no documentation and no community support.

Which is true for most libraries pulled from Github also.. but additionally you cannot just ask your colleague.

But most people don't pull 100s of random libraries, just the few most popular and needed. The strawman where people download tens of libraries just not to write oneliners mostly does not exist, besides javascript land.

Having to ask your colleague is an extra cost - for common tasks (like the example of parsing of command line arguments used in the parent comment) you should be using the exact same code as your colleagues unless there is a good reason to make an exception (which there rarely is), so you should be able to read and maintain others' code just as yours because it's written in the same way as you would, making the same style of calls to the exact same functions. And furthermore, the third party libraries (at least for Python) are so standard that a new hire would have used the exact same library if they ever had to do the same task - for most things there's going to be just a few reasonable ways (and often just a single idiomatic one) to do that thing in the language, which sometimes used a built-in library and sometimes uses a popular third-party library.

If your company has a dozen tools which need the same functionality, "rolling your own" for each codebase (or worse, copy/pasting it without being able to update them from a single place) is obviously not a good solution - the choice is between making and using an internally maintained library, or using an open source one.

Then you flog mercilessly people in your organization who write code like this. When I was coming up, the greybeards were bastards, but they taught me the right way to go about things.

Code is only hard to figure out if you don't understand the business goals. Third-party libraries/frameworks will almost never explain the business to you.

However, there is a practice known as testing that is supposed to document the business goals so that your colleagues aren't left in the dark. Hopefully you haven't skimped there, regardless of where the functional pieces came from.

> Code is only hard to figure out if you don't understand the business goals.

Ah right, so when an architecture astronaut picks up the GoF Design Patterns book and creates a rube goldberg architecture with an interface for every. single. class., it's not going to be understandable because folks didn't understand the business goals.

Agreed. It's not terribly hard to think like the person who wrote it, even if they went rube-goldbergesq, if you understand where they were coming from. If the business details have been lost, it becomes harder.

I think who you’re replying to is being sarcastic (a clue is using a pejorative - “architecture astronaut”). FWIW, I agree with their sentiment and disagree with yours.

Yes, exactly. Even architecture astronauts are well intentioned, and if you understand the conditions under which they worked then it is quite easy to follow what they've done. It only becomes difficult when that context is lost.

So hopefully they've encoded that context in tests. Worst case, if you never learned how to read code, you can throw the implementation away and the intention will remain validatable. But if you don't have the business end of the code documented... Good luck!

> Yes, exactly. Even architecture astronauts are well intentioned, and if you understand the conditions under which they worked then it is quite easy to follow what they've done. It only becomes difficult when that context is lost.

I posit you lack either the experience of the imagination if you think "business context" is the only factor in the development of an unmaintainable mess.

Usually, when an architecture astronaut gets involved, the business details are immediately lost in the overwhelming slop of what has been built.

And usually, the people having to deal with this crap are ones who have never dealt with the system in the first place, and the business people and the technical people are both gone from the company…

An interface for every single class doesn't really come from GoF, it's the D in SOLID -- this idea that classes must never depend on each other but on interfaces representing other classes.

On a tangent...a pervasive problem in programming language syntax is the confusion afforded by Class Access Modifiers (public, protected, private, et al), aka CAMs.

In some languages, these are foremost used as mixin selectors (inheritance, traits, or other composition). They are commonly overloaded to describe the object's interface. I am not the only who to have seen objects inherit from other objects, with the derived class consisting of new CAMs to provide the proper interface (in lieu of some dedicated Interface class, like in Java). Then there's a third concern about testability and how to reach methods like private and protected.

If language syntax supported these different concerns with different mechanisms (notably Python and Go have made some headway for enabling testability) including a formal definition of an interface outside of CAM-mixin selection, it would make developer's lives a lot easier and quell many of the conflicting opinions about implementation dogma.

I've rarely had a hard time understanding code that was written for a purpose rather than importing a library. Except in rare cases (like dates, big APIs) a library is often unnecessary cruft. Should I go pull a fat logger when all I need to do is send data over TCP to rsyslog? As long as I consider all of my use cases, and properly defend the cases I wont use I can write faster, often times more understandable, code. An example of a great, but often unnecessary library, is Pandas. I've seen Pandas imported for trivial CSV work, simple data manipulation, etc just because it was "familiar" rather than the right tool. Pandas is so, so, so heavy that if you're not using it completely for data science oriented work you are probably wasting your time...people seem to not understand this distinction.

I've had people cut juniors/data scientists/etc loose on a "be-all-end-all" framework and ended up with the worst code I've ever seen. Edges so sharp just looking at them will cut you. I've seen code that imports trivial things like line counting! I've even been on the response team for a security incident involving several internal packages that imported the wrong thing from the package managers! I've had to re-write important library functions for a package that was imported and deprecated, and the author just went to do something else. Libraries are great, but they are not a fire-and-forget tool. When you use them, you must use them sparingly, correctly, and securely. Importantly, you need to pray a library will be maintained over the life of your software.

"Documentation and community support" is worth absolutely, positively, nothing if the usage of the library enabled the writing of poor code. Hire better developers, and create strong coding standards at your company. Let software engineers do what they do best and choose the right place to include a library after evaluating all options. Experience level matters. Late seniors and staff+ understand the difference. New seniors, TLs, and of course braindead management love to bring in the universe on every project.

Your job as a software engineer is to solve business problems set before you.

If your job is to send data over TCP to rsyslog, then you’re doing your job.

If sending data over TCP to rsyslog isn’t your primary task, then doing that is a distraction, at best. Maybe the rsyslog protocol is simple enough that writing your own function is sufficient. Maybe it isn’t.

I’ve been doing this for 28 years professionally and will often choose a library (and I _do_ typically look at the code and compare code diffs across versions on upgrade) over writing my own, because:

1. My job is not to write a task runner—so I use Sidekiq or Celery or Oban. 2. I’m not confounded by the illusion of NIH being lesser.

I will always write my own code if it’s core to what I’m doing. If it’s a sideshow, I will absolutely outsource it to a library or a compiler or whatever. Anything else in the context of the job you’re hired to do is irresponsible.

And because every dev has a different idea about how to simplify things, you throw any sort of standardization out of the window.

Standardization and pluralism both have their respective merits. It's a "cathedral vs bazaar" thing or corporate culture vs hacker culture.

As opposed to the standardization of a random collection of github libraries?

I try to convince them to keep stuff simple at my work, but we still go creating a shitshow of epic proportions. If our app was done the traditional way it could probably run on a Rasperry Pi. Instead they are pushing for microservicces, one database per service has been mentioned. A SPA app for the frontend. All for what amounts to a standard crud app that sends some jobs to the cloud.

Back in my day, we coded in assembly and looked up opcodes in paper books. And we liked it! At least we weren't still on punch cards.

Eg, I use the python docopt library because it makes life easier and more straight-forwards once you understand it. Which, to be fair, not everyone wants to put in the time to learn. But I like it more than having to code up an argument parser from scratch using string matching, and then having to do that every single time... I don't need it, but I also don't anything more than nasm, anything more than that is luxury! Kids these days...

> we coded in assembly and looked up opcodes in paper books

Don't threaten me with a good time.

Most people use abstractions so they don't have to.

There's a difference between someone using an ORM who knows SQL and someone using an ORM so they don't have to learn.

The fact is, most people use these abstractions so they don't have to understand it.

---

Back in my day ... it was accepted that you needed to understand atleast 1 level of abstraction below where you're working at. Nowadays, that attitude is only used by older developers.

> The fact is, most people use these abstractions so they don't have to understand it.

How do people just accept that there's magic going on? That would drive me crazy. I don't expect people to know all the details, but there should be some level of understanding at least one layer down.

> Simplifying is hard. But when you get good at it, you find you're much more buoyant.

it's not finished when there's nothing left to add, it's finished when there's nothing left to take away.

Code can always be improved. How you evaluate tradeoffs both varies between individuals and your own views from day to day.

Code is never finished, until it's forgotten or feared.

>overload existing code with additional functions when feasible, rather than starting a new project from scratch.

why? are you making a jab at small packages? ill just rant on that and say i think small packages are great. they are extremely purpose built and lovely to use. they do become transitive dependencies often leading to the "issue" in this blogpost but im in the yolo upgrade camp

The churn required to keep up with frequent updates to many dependencies can work for some projects, but I would argue only for projects with continuous funding. If a project is only funded every couple of years and has many dependencies, odds are, the next time it is funded, there will be an inordinate amount of work to patch/update the code. For such projects, fewer or no dependencies may be better.

this one hits home for me because I do work in academia where funding goes kaput frequently and I do have to agree on some level. Some of the most stable and popular tools in my field have few to zero dependencies and are written in c... bioinformaticians will know what I mean.

Just a quick shout-out to Python Poetry (https://python-poetry.org/) which makes package, version, and virtual environment management extremely simple!

I love it so much that I can't imagine having to work on a python project without Poetry now, lol.

> You do not need some 3rd party library to write a command line interface for your python code.

> Just learn how to do these things in a simpler way, without the extra deps.

That's known as reinventing the wheel. Commonly espoused by people with NIH syndrome.

https://www.techopedia.com/definition/3848/not-invented-here...

Imagine some point in history where the wheel hasn't yet been invented. But someone figured out that an octagon works kind of reasonably well as something that you might want to put under your chariot, and the whole world of engineering is under a culture where "reinventing the octagon" is some kind of cardinal sin. Where would we be then?

Also: Your reasoning is logically a fallacy. From "people making mistake X tend to do Y" it does not follow that "doing Y is a mistake".

But now imagine the world of tomorrow, where despite the convenient availability of a range of wheels well optimized for specific roles you get told "that just adds dependencies: any artisan builds their own from scratch" and so you and your customers get to learn the unique quirks and paper-cuts of each wheel of every chariot you sell thereafter.

I merely pointed out that the "don't reinvent the wheel" knee-jerk reflex that some people are exhibiting in a broad range of situations is an absurd absolute. Negating something and then stating it as an absurd absolute does not prove nor contradict the original proposition.

Sometimes it's more economical to reinvent some wheel than not to, sometimes it's not.

Sometimes reinventing a wheel leads to a net-improvement in the state of the art of engineering, sometimes it doesn't.

That sort of relativism makes for boring reading, but it also happens to be the truth.

That's why the better approach is: learn how to build wheels and how they work, then use off-the-shelf wheels - unless you know that you need some peculiarities that are not found on the market; only then modify those wheels or build your own.

I'm saying: When you know how to build wheels, you may well want to build your own. If I have old bread and five minutes of spare time and a pan, I'll happily make my own crutons. There might be many reasons for why this might be the right course of action in a given situation. Maybe it's more economical to make more of the resources I already have rather than expend more by buying them at the store. Maybe I like keeping alive the heritage and knowledge of cruton making and will teach my kids how to make crutons one day. Maybe I like not being subjected to worldwide cruton-shortages when they happen. ...I just don't get the universal law of "if there's crutons available at the store, you must never ever make your own", and I don't think it is one.

Goldman Sachs thinks that risk management software is so core to their business that it makes sense for them to do it in-house while their competitors used off-the-shelf software. One weekend in 2008, Lehman Brothers collapsed. Figuring out your risks after such an event was something that nobody had programmed into their software. But Goldman Sachs was able to get their people to work through that weekend and know what their risks were when markets reopened on that Monday. In the year that followed, they had one of their best business years and massively outperformed their competitors.

"You think reinventing the wheel sometimes makes sense? Haha, well I guess you also think that Google and Amazon should be manufacturing their own computers then..." ...this is something that somebody might have said sarcastically 20 years ago. Well guess what. They are.

> I guess you also think that Google and Amazon should be manufacturing their own computers then..." ...this is something that somebody might have said sarcastically 20 years ago. Well guess what. They are.

So, if you don't have the resources of Google or Amazon it may make sense to get your wheels from somebody else, right? It's called specialisation of work.

There are costs and risks associated with subcontracting.

You won't really know how to make wheels without building your own and putting it to actual use nor know when making your own wheels or using existing wheels makes more sense without the experience of both using your own homemade wheels and off the shelf wheels.

After all many wheels on wheelhub nowadays exist because someone got frustrated from their experience with using existing wheels.

Its usually not so much "a range of wheels optimized for specific roles" and more "one size fits all."

You want a wheel that fits your cart. You have a lathe. Why make do with a wheel someone else made, standardized, and sells to fit a wide range of carts when you can make the perfect wheel for _your_ cart?

Most of the functionality in libraries use standard algorithms anyway. I doubt anyone thinks its a good idea to write your own cryptography or markdown processor, but why do you need a library to left pad a string with zeroes?

if statements and flags take time to process. You only have one way you need to do something. Do you want to take that much more compute just checking flags that will never change so you can get the library function to do what you always want it to do?

Sure, but there are many ways to make wheels, are your wheels 1.8m or 2m apart, what material, etc.? You may pass it off as a lark but stuff like this matters - to city builders, chariot makers, train track designers, and so on.

You can go full NIH and reinvent the stone and finish about twelve years post end of universe or you can standardize and say ok, lets reuse some code.

And if everyone reuses same code you can get into problems - common vulnerabilities.

There's a fine line between NIH (not invented here) syndrom and overusing third party libraries. The classic example being the is-even[0] npm library, which seems like a joke, but has ~200k weekly downloads. It just seems that many devs too quickly reach for a third party library before taking a few minutes to think if it would make more sense or not to write the code themselves.

0: https://www.npmjs.com/package/is-even

The best thing is; this library depends on another library ... is-odd =D

Haha. And is-odd depends on is-even?

Woah, no but it does depend on is-number...

> too quickly reach for a third party library before taking a few minutes to think

The funny thing is, npm install, and then import, and then calling it surely takes more time than just writing out the full implementation inline.

Does anyone here actually use Python? Because "not [using] some 3rd party library to write a command line interface for your python code" should mean: Use the argparse module that's in the Standard Library. Not coming up with something homegrown.

I was wondering the same thing, there is very little reason to outside of the standard library in Python. Then you have the 3rd party the ones that have been solidified as basically standard as well.

You shouldn’t be downloading a package from Joe Schmoe.

argparse? Surely you mean optparse? Or getopt?

Standard libraries too will pass.

or docopt. or Click. Just as long as I don't have to code up handling short vs long options by hand more than once ever.

That's what I was wondering. I find argparse so helpful that I use it everywhere I need to handle a command line. It works fine.

In Python you can insist on pulling in Click... or just use argparse which is available in the standard library.

I assume you missed the fact that you can already do a lot with the standard library in Python for example.

Reply on news.ycombinator.com