341–350 of 478 posts
Weinberg's Law: If Builders Built Buildings the Way Programmers Wrote Programs, Then the First Woodpecker That Came Along Would Destroy Civilization.
This sounds very clever but the nature of software development is quite different from building buildings. The rate of innovation is by magnitudes higher. And as opposed to buildings software can tolerate a certain amount of failure.
Earlier quoted context omitted.
This analogy doesn't hold up at all. The UHH is a fun read, yes, but the biggest real-world problem with the Unix Wars was cross-compatibility. Your Sun code didn't run on Irix didn't run on BSD and god help you if a customer wanted Xenix. OK, you can draw some parallel here between React vs. Vue vs. Zeit vs. whatever. But there was also the possibility, for non-software businesses, to pick a platform and stick to it…
"Pick React and stick to it" is the exact parallel to your "pick Sun and stick to it". Were you not there to see how often SunOS and Solaris updates broke things, too? But those updates were largely optional, and so are these. If you prefer React 15's class-based component model, you can pin the version and stick with it. You won't have access to new capabilities that rely on React 16 et cetera, but that's a tradeoff…
I wouldn't say getting started with ReactJS is easy (or that it's properly supported). Each team that uses React within the same company uses a different philosophy (reflected in the design) and sometimes these flavors differ over time in the same team. We're back to singular "wizards" who dictate how software is to be built, while everyone else tinkers. It's a few steps from custom JS frameworks.
Earlier quoted context omitted.
That might be referring to Yarn's "offline mirror" feature. When enabled, Yarn will cache package tarballs in the designated folder so that you can commit them to the repo. When someone else clones the repo and runs `yarn`, it will look in the offline mirror folder first, and assuming it finds packages matching the lockfile, use those. This takes up _far_ less space than trying to commit your `node_modules` folder, a…
That's quite interesting, although back in the day we did that for C dependencies that weren't packaged well, and it quickly ballooned the size of our repo since git has to treat tar balls as binaries. Even if you only update a few lines of the dependency for a patch version, you re-commit the entire 43 MB tarball (obviously that depends on the size of your tarball).
Earlier quoted context omitted.
Then again, this broke a package that, by its very nature, isn't running in production. And the problem was solved within three hours. So I'm not sure how much everything-used-to-be-great-nostalgia is justified here.
Someone rolls out code where a serious bug fell through QA cracks, and appears to be breaking a mission-critical path. Your biggest client is on the phone screaming FIX IT NOW. Three hours is an eternity.
Earlier quoted context omitted.
Lile... x instanceof Promise It works for standard promises, sure there are non standard promises, ancient stuff, that to me shouldn't be used (and a library that uses them should be avoided). So why you need that code in the first place? Also that isPromise function will not work with TypeScript, imagine you have a function that takes something that can be a promise or not (and this is also bad design in the first p…
Your implementation is broken even if everything uses native Promises. I don't know how many times this exact thread needs to happen on HN (as it has many times before) until people realize their "no duh" implementations of things are actually worse than the thing they're criticizing. Make an iframe. In the iframe: > window.p = new Promise(() => {}); From the parent window: > window.frames[0].p instanceof Promise fal…
[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Earlier quoted context omitted.
Have fun telling that to your boss
Plus, pick the consensus option, any problems that come up are that option's fault. Fight for anything else, and everything's your fault. Even if it is actually better it can make you, personally, look worse.
There are trade-offs, absolutely. Waiting on a vendor to fix a problem _for months_, while sending them hefty checks, is far inferior to waiting 3 hours on a Saturday for a fix, where the actual issue only effects new installations of a CLI tool used by developers, and can trivial be sidestepped. If anything, it's a chance to teach my developers about dep management!
I'm positive my stack includes `is-promise` about 10 times. And I have no problem with that. If you upgrade deps (or don't) in any language, and don't have robust testing in place, the sysadmin in me hates you - I've seen it in everything from Go to PHP. There is no silver bullet except pragmatism!
I think these one-line-packages aren't the right way to go. Either JS-developers should skip the package-system in that case and just copy and paste those functions into their own project or there should be more common used packages that bundle these one-liners. I mean is_promise() and left_pad() are not worth their own package. Packages-dependencies of 10000 packages for trivial programs are just insane. Is someone…
Earlier quoted context omitted.
I fully disagree. Open up any serious Python project and you'll find significant dependencies. Math, graphics, IO, stats, ML... anything you really want to do requires dependencies. In fact, one of my biggest issues with Python is the cross-platform incompatibility of many packages which makes it a terrible choice for my deployment. (Even worse if the project has Cython components!) I often end up having to scour git…
Math -> You use numpy, scipy, none of these have any significant dependencies. And libraries this complex are not even available for node. Graphics -> Python comes with included Tkinter, and others are also one include away. Stats -> Scipy does a lot of the stuff. There is a built in package for stats. Again, no stats package has 100 dependencies, and node doesn't even have anything with even 1/10th of the features M…