LKML: New syscall: leftpad()
lkml.org
lkml.org
It must be a bubble.
Let's wait for HN resident economists to tell us about it.
Many people are on older kernels and might not be able to upgrade, or for convenience or other reasons simply prefer to use an api for their critical business logic.
EDIT: Here's an idea: Monetize your padding by putting ads in it.
Need to make it a package so other code can depend on it though.
Somehow, this just makes it better...
> Leftpad has millions of users, so it has to be as fast as possible.
Flawless logic.
Hardware accelerated leftpad anyone?
PADL AL, 1hhttps://reverseengineering.stackexchange.com/questions/2774/...
ioctl means "We made this object's API file-like, but there's something we need to do with this object which we can't express in terms of the normal file operations."
Setting terminal options is a classic use of ioctls: You have a file descriptor which connects to a terminal or, more likely, a pseudo-terminal, and now you need to ask the user on that terminal for a password. By default, the low-level code will echo every character back to the user, so they can see what they just typed, but that's insecure for passwords, so you need an ioctl to tell the low-level terminal handling code to not echo.
Plan 9 removed some of these warts, but it's hard to see a fully, truly elegant way to handle something which is mostly-file-like but has some un-file-like attributes programs need to frob.
* Or until the kernel revokes your programming license.
0
For the secret* kernel that is known only to us, facebook () should be replaced by hn().
This one was awesome though.
I think you added an "H"
But there is actual value in doing things the npm/unix way.
Just yesterday I used a module to turn numbers to comma separated strings 10000 -> 10,000
Could I have written a function to do it ?
Sure
But every less line of code I need to write saves me time.
Programming is fundamentally a creative field ( which means there is no absolute truths ) - and each individual developer should be given the freedom judge when to write code and when to use other's people modules.
I would say that this whole fiasco just proves how awesome programming has become - remember the days when adding a dependency was hell ? Now we live in a world where adding dependency has so little cost that we rather not even spend 10 minutes writing a function.
To me its an improvement over the state of affairs from the past.
Its also cheaper to switch dependencies - imagine if the leftpad disaster was somewhere in the window's kernel ? or in std:: ?
There is always trade-offs in every decision you make in software - I think we are moving in the right direction.
Just need to make package creation immutable.
This is where the node community falls down. They think because there is value in sometimes doing it this way, there is always value in doing it this way.
Rarely is the right answer for architecture/programming/etc at one of the extremes.
The issue was that authors in the npm ecosystem could pull their packages and cause havoc. Copying code is a partial workaround for this problem for small dependencies only, but the problem should be solved at the npm level--and once it's solved there, the virtues of copying code go away.
I'm speaking from experience with a package manager that was specifically designed up front to avoid the left-pad issue (before left-pad even was a thing). In that environment, dependencies, even small ones, are great. With an overrides feature and lockfiles, you get all the benefit of copying code (ability to hack on it, responsibility for updates, reproducible builds) without the hassles of copying code and trying to stay in sync with upstream.
Copying code isn't something you have to spend decades to invent. Rather, I see it as giving up on proper package management. There are coherent arguments that package managers aren't worth it (though I disagree with them), but I don't agree that it's arrogant to try to build package managers that scale up and down, any more than any attempt to use software to solve an engineering problem is arrogant.
Which is - no matter how big the packages are - a huge problem.
This really misses the point. Every dependency is its own point of failure. When you explode your dependency tree into 1,000s of individual dependencies, you vastly increase the odds of something going wrong.
Making package publishing immutable won't save you. What happens when the dev of one of those 1,000 packages you rely on has his or her account hacked and a malicious point revision is pushed? Even if you pin all your dependencies, do all your 1,000 dependencies pin all of theirs?
Micropackages like left_pad and is_array had hundreds of dependent packages and a tiny handful of watchers on the repo itself. The NPM community is lucky that the first major consequence of their micropackage-insanity was only a brief outage.
I figure the social dynamics bundled with a micropackage model matter. If you have a few big packages with lots of owners, central dependencies are less likely to be deleted by unanimous consent of owners than the same software divided up into many packages each with a single owner.
How much time did you take to find the code, read the documentation for it to make sure it does exactly what you need, did you budget time for the future when it doesn't work exactly as you wanted and you'll have to either find another module or fix it yourself, etc.?
If it's something nontrivial (e.g. SSL/TLS), then it certainly makes sense to reuse. But if it's trivial, then the overhead can be far greater than the savings.
Of course, the definition of "trivial" varies greatly depending on the skill level of the programmer.
Dammit people!
http://www.xent.com/pipermail/fork/Week-of-Mon-20091109/0545...
OF course there's value. There is also a cost to adding another dependency.
> But every less line of code I need to write saves me time.
It saves you time now. The recent left-pad brouhaha is a very good example of how it can also waste a lot more time. This focus on only the initial development time without any consideration of the maintenance cost always creates problems in the long-term.
Maybe this attitude is popular with programmers on short contracts that won't be around to maintain the project? It sounds plausible, but I'm not sure. At a minimum this shows the human tendency to be very bad at evaluating risk.
The bar for publishing needs to be higher because there is too much broken, incomplete shite out there. Usually because they just pushed the internal quality, undocumented, untested garbage they just wrote. Don't test arguments, don't set constraints. Tag on a sentence of hurried description, done.
I don't understand the half-assed mentality that does that. That's how one makes the world a worse place, not a better one.