4 ms·

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

by dozzie 11y ago

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.

oldmanjay 11y ago
"It takes a long time to understand" is synonymous with "can be improved."
- pklausler 11y ago
  Counterexample: the universe.
  - astrange 11y ago
    I think the universe has a long list of outstanding feature requests.
    - davidhowlett 11y ago
      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.
- gkya 11y ago
  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.
oldmanjay 11y ago
"It takes a long time to understand" is synonymous with "can be improved."
qwertyuiop924 11y ago
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.
- dozzie 11y ago
  > 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.
efes 11y ago
> 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.
- dozzie 11y ago
  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.
mitm2mitm 11y ago
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.

by dozzie 11y ago

oldmanjay 11y ago

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

pklausler 11y ago
Counterexample: the universe.
- astrange 11y ago
  I think the universe has a long list of outstanding feature requests.
  - davidhowlett 11y ago
    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.
gkya 11y ago
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.

oldmanjay 11y ago

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

qwertyuiop924 11y ago

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.

dozzie 11y ago
> 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.

efes 11y ago

> 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.

dozzie 11y ago
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.

mitm2mitm 11y ago

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.