Hacker News Reader

Comment by dozzie | Hacker News Reader

Quite simple. People in IT (and hobbyst programmers) tend to not learn the tooling, its features and properties, and reasons behind the tooling itself. It's all rage about writing things, never mind that somebody had it already implemented and way, way better.

Look for instance at how programmers deploy their applications (which are mostly web applications). Are those applications tied to operating system version somehow? Mostly. Are those programmers using this operating system's tools for software installation? Hardly. And why? Because it's not sexy enough, npm or gem are way sexier (despite apt-get or yum being much more mature and robust).

It really takes a long time to feel how and why the OS works and to work with the system instead of against it. Don't expect programmers with vast three years experience to understand their surroundings.

View on HN

> Are those programmers using this operating system's tools for software installation? Hardly. And why?

Because this is a bizarre argument. I accidentally make dependencies on specific variants of libraries because I don't immediately need to support other variants and lack examples and/or time to worry about theoretical portability.

I don't use OS specific packaging because it was intentionally written to be non-portable. My learning it is an irrational commitment to keep using an OS at the neglect of all others and even if its distributor changes (or can no longer honor) the conditions of our deal.

Your dynamic website (often called a webapplication) is very probably OS-specific anyway. I've seen websited that can run only on Ubuntu. Most often you could as well settle with what OS provides to deploy it, especially that you won't need another instance on the same server. Even more so if it's not a hobbyst project, but a professional one.

> I don't use OS specific packaging because it was intentionally written to be non-portable.

Only if you use it mindlessly. It's not really different to build a package for Debian, Red Hat, Slackware, or Gentoo (been there, done all of these). All it takes is to properly separate downloading sources and building things, which is a good engineering on its own. And guess what you get in exchange? Easy dependency installation, both for development and for deployment.

So you can link your Github profile to recruiters and add "Creator of project X" in your CV.

I hate the amount of garbage and noise created by this. But how many of the good tools we have today wouldn't have existed if people didn't just started coding?

It's full circle to your first phrase since if nobody was using nobody would write redundant/worse tools. Man I miss the time programming was only my hobby.

there are legitimate technical reasons for using NPM (disk is cheap, project local packages ftw, etc.). gem, less so. I can, however, tell you the primary reasons for using npm or gem: I need a dependency, my os hasn't packaged it, and it's the path of least resistance.

Also, I am a hobbyist programmer. I also know that git was created by Linus Torvalds, it's a DVCS (although Torvalds calls it an SCM), and it's based on a DAG (directed acrylic graph), which is a directed graph with no directed cycles, and excellent for modelling causal relations. I can explain to you the difference between a rebase and a merge. I know that git uses SHA-1 hashes to identify check-ins internally, as a data security feature. I know that checkins and other objects are stored in the .git folder at the repository's root directory. I know that these objects are garbage collected, although the frequency at which they are escapes me. I know that, despite common belief, git commits are immutable, but also that the git history is not. I know that git was inspired by BitKeeper, after the incident that caused the linux source to be moved away from that system, because Linux got fed up with tarballs and patches, and hates CVS with a fanatical passion. I know that git had three design goals: distributed, fast, and guarantees that you get the same bits out that you put in. And I've have several years of causal experience with git, using probably one tenth of its functionality.

I may not be able to recite git's internals at you, but I know it's features (to an extent), I know the tools, and I know the reasoning. And the functionality sure as heck isn't magic.

> I need a dependency, my os hasn't packaged it, and it's the path of least resistance.

What I tell you back: you probably don't need it, you're just being very, very lazy, which will cost later in bugs in those dependencies, and it's not that easy to fix a bug in a dependency.

Additionally, it's not that difficult to make a package with that dependency. I routinely do so, both for things other people wrote and for my code. Sure, it's not as easy as adding a line in package.json, but there should be some friction in adding a library to a project, so the library would justify itself. Keeping many dependencies is very expensive in the long run, but short-term is somewhat beneficial. Look at how it works for Node.js and gems and Python packages: every library needs its own `map()' function implementation (or anything else similarly trivial), so typcial application requires few dozens of other libraries.

Writing yet another map implementation is not solving any problems.

People get so bizarrely bent out of shape over npm dependency quantity rather than ease of use.

Hey, I was just saying that that's the common idea, not that I think that way.

Personally, I use NPM because NPM does local versioning, so I will never end up in dll hell.

Also, NO, NEVER WRITE A PACKAGE THAT HAS EXPLICIT KNOWLEDGE OF A DISTRO PACKAGE MANAGER. If you do, you are being an asshole. If you want to depend on a distro specific package manager, document your dependencies, and just expect them to be there. Because not everybody uses your package manager.

If you have proper package building rules (not this currently popular fpm nonsense, which produces broken RPMs and DEBs unless one puts much effort in using it), tearing building procedure apart and adjusting it for other package managers will be really easy. No, you're not being an asshole. And if you want to be it even less, write a proper makefile and call that from package build rules (RPM spec, debian/rules, ebuild, or anything else).

You should be writing Makefiles, or Scons, or whatever your build system is.

"It takes a long time to understand" is synonymous with "can be improved."

I add this to my list of epic non-sequiturs. While it is not necessarily wrong completely, it is not correct for all the cases. It takes a long time to understand how it's ok to do without the latest version of the software. It takes long time to understand that old is not a synonyme for obsolete. And to have this understandings one needs experience, and for experience you need time, which cannot be substituted. There are some things that one only learns by rediscovering them, and this is one of them: who settles is happy.

Counterexample: the universe.

I think the universe has a long list of outstanding feature requests.

I wanted to add a few feature requests so I went looking for god on github. I found god but unfortunately most of the universe has not been open sourced yet :-(

The physicists are trying hard to reverse engineer it though.

Reply on news.ycombinator.com