Left-pad as a service
left-pad.io
left-pad.io
What kind of load balancing is being used on the back-end? I called leftpad(str, ch, len) with the length I needed and noticed that is not very scalable because it is blocking.
A better approach I would recommend to those using it is to call the API in a for loop. In my tests, it had performance very close to those I see in C or assembly.
I was a bit turned off that the free version can only handle strings up to 1024 in length. I know you need to make some money, but it is big turn off for a lot of my projects.
Edit: I finally signed up for it but still noticed that I am only allowed to use 1024. I called your customer support line and they said I was calling the API from multiple IP addresses and for that I need an enterprise license. Please help me with this issue, it is very crucial at this point as my project is in a complete stop because of this.
If you don't like the "" magic string in there you could replace it with a call to left-pad(null, null,0).
{"errorMessage":"len exceeds 1007 characters. Contact a left-pad.io sales engineer for an enterprise license","errorType":"Error","stackTrace":["exports.handler (/var/task/index.js:33:22)"]}
wow. they even have an enterprise sales engineer! :)
Thank you for making this site so that I don't have to write an opinion piece like everybody else seems to have to. Instead, if asked about the issue, I can just point them at this site.
Yes. This isn't constructive, but this mess had so many layers that I really can't point to a single thing and offer a simple fix as a solution.
As such I'm totally up for just having a laugh, especially when it really isn't being nasty against specific people but just laughing about the whole situation.
Thank you to whoever made this
And wasn't it just a few months ago people were praising the innovation of Urbit for having a 'global functional namespace'? But because it's popular to hate on javascript devs for applying -- sorry, I forgot this was javascript bashing week -- for reinventing concepts from other areas in computer science and software engineering the HN community has to start hating on another programming community's work.
That said this is a pretty funny satirical page, apologies to the author for venting at the HN community.
Lately I've stopped coding for work and moved into a PM++ position as I build up a small agency on my own, and it has been refreshing. I build little meteor apps for fun in my free time (omg meter doesn't scale noob lol) and can keep my blinders on to what the outside world thinks, and my devs can continue to do what they are comfortable with.
Each community has its own quirks and extremes as seen by everyone else. Without the bashing, they would become even more extreme. At least after this a lot of devs will think twice about making "micro-modules".
Saying the effect exists says nothing about the effectiveness of that effect.
>Without the bashing, they would become even more extreme. At least after this a lot of devs will think twice about making "micro-modules".
I don't think this "self-regulation" (I called this bashing, the guidelines call this flaming) is going to make people think twice about making micro modules. If they are useful they will be used, I think this community is better than to just bash these communities and call it 'self regulation.'
`I shouldn't do ${foo} because people will make fun of me` is a horrible attitude to foist on anyone else, and anyone who tries to propagate that attitude isn't helping the community at all.
The community in question here is much more of a javascript dev community, and we can see the culture clash between them and the java, c, python communities throughout all these left-pad threads. So, I maintain: this is an attempt at other-regulation, namely people who are by-and-large not active parts of the javascript dev community making fun of the punchbag-of-the-week.
I'm just cautious any time someone frames an outright attack (and make no mistake, these are attacks) as "for your own good". It rarely is.
`... but why are they laughing from ${foo} in the first place? They're smart people, so there might be a reason. Let me research it more first...`.
This is how self-regulation works.
There are different flavors of comments on these threads. Some are pretty cogent and thoughtful. Others aren't. A "sky is falling augh, isArray is one line, javascript devs are teh worst" misses the underlying problem of javascript being addressed (interpreter fragmentation, not having a reliable way to test if something is an array on older platforms). I'd argue it doesn't contribute at all to the improvement (metacognitive or otherwise) of any javascript dev, but instead serves to harden people's opinions on one side or another of a mythical line.
The difference is whether the goal is to contribute to the discourse or just go for the shallow laughs. It's an important difference, because the former does lead to improvement all around, whereas the latter leads to high-fives and community decay.
0: https://news.ycombinator.com/item?id=11352704 1: https://news.ycombinator.com/item?id=11350651 2: https://news.ycombinator.com/item?id=11348798
While I'm speaking about a somewhat more general pattern of behavior, a very closely related phenomena is the "normalization of deviance"[1].
Part of the problem is that without an outside assessment, the actor isn't really working with accurate information. Criticism can be a way of giving that data. Quality "constructive criticism" is great, but the message is sometimes ignored or avoided. In those cases, a harsher criticism - and possibly a bit insulting - is necessary to convey both the severity of the situation and to get the recipients attention. This is where some of what you cal "'get off my lawn' yelling" is about. Sometimes we've seen these mistakes before, and we've tried being patient and nice; when that didn't work, the occasional "get off my lawn" may be appropriate. As others have said, this how a community self-corrects; when someone is being "stupid", they need to know that. They certainly aren't going to change without this necessary information.
Now I'll certainly agree that there is a very fine line here, and as long as fallible humans are involved mistakes will be made. I've certainly made mistakes in this area in the past. However, avoiding problems is not the answer, as unfixed small problems tend to become larger problems in the future.
[1] http://www.rapp.org/archives/2015/12/normalization-of-devian...
And the stubs and mocks. I recently had to fix a beautifully tested piece of code where the developer forgot to implement the actual functionality. The proliferation of async/await and the idea that no self-respecting app can exist without a REST API layer also grate.
Cargo cults seem to move in waves, and the frequency of those waves seems to be ticking up of late.
It's funny if done in good taste. You should be able to take a joke with good humour, even if it's at your own expense, and this is a pretty good joke.
I think that kind a culture is necessary in quickly shutting down projects that have a high likelihood of failure before too much time is invested in them. Unfortunately, that culture also tends to leak into many other aspects of the community.
Nicely phrased. I'd apply this to engineers in the general too. People can often speak of them (and me) as difficult; when this is really what is needed of people that make things happen. Especially on critical infrastructure. You can't really wing details on the integrity of the bridge you are building.
Is that not how you perceive it? Am I just imagining contempt where there is none?
It's like, I can joke about you being an alcoholic if I think you're actually just a fun heavy drinker. If I think you're actually a violent alcoholic, it's not funny for me to joke about that.
That's what slashdot is/was for.
Here you come to find highly opinionated and more-often-than-not wrong commenters.
You can find those on slashdot too!
Applying cross-domain concepts to improve your local domain is awesome.
Applying somebody else's invention from a different domain to your local domain and then acting like you invented a new thing is... annoying.
If various forms of "reinvention" didn't seem to come with a Twitter-cult and snazzy *.io website screaming, "Look at me! Look at me! See how awesome this totally new thing is that I'm pretending to have pioneered!" There'd be no inclination for anybody to respond with, "Um. You didn't invent anything. Please calm down."
If you throw yourself a parade everyday celebrating the genius of having figured out how to wake-up in the morning to attend your parade, then inevitably somebody is going to rain on it.
Changing your npm shouldn't be a problem, just unpublish it and create new one.
Also don't forget to check trademark list before creating npm because "they will come knocking on your doors closing all your accounts".
http://docs.spring.io/autorepo/docs/spring/2.5.x/api/org/spr...
Edit: clarify astronauts http://www.joelonsoftware.com/articles/fog0000000018.html
that actually makes sense to somebody?
It all starts getting really weird with Spring Data interfaces: a whole DSL written in camelcased method names, as if Spring deliberately turned a joke into a feature.
I take it you're not familiar with the Bile Blog, e.g.
http://www.jroller.com/fate/entry/rip_jboss_mail_services
Alas, service ceased ten years ago.
It's OK if they're pulling from other repositories you own, but requiring external repositories as part of the checkout process seems like an obvious point of failure. There's all sorts of possibilities for malicious activities, and just plain downtime will affect you too. Storage is cheap, so it seems like there ought to be no reason not to pull in external dependencies and save them locally. Dependency managers should support and encourage this rather than defaulting to just referencing some random stuff off in space.
It's "cloud culture": rely on some else's maintenance effort and just work on your own problems. Like all things, it has drawbacks.
The only thing that potentially gets harder is refreshing the packages, and I'd argue that's actually a good thing because that's really just saying that packages don't randomly change out from under you. In any case, your package manager should make it easy to refresh them when you want to, just say "go update that dependency to the latest available from the official source" and let it do its thing. If package managers don't offer this, they need to start.
Whereas standard "fetch package" scripts are trivial, and each individual stack is known well enough by developers working on it every day that there is zero administration and little need for extensive knowledge transfer... At least until left-pad disappears from under your feet; but that's rare enough that the trade-off is worth it overall (or people cannot even imagine it ever happening).
I'm not saying this is how it should be, I'm just describing why a lot of people do what they do.
Maybe the solution is an overall simplification and harmonization of all these services, so that the responsible option and the lazy option won't differ so much. You could have something like a prebuilt "repo server" image that can be downloaded and configured quickly, and which will then auto-cache all requested packages across different services. Cache invalidation would still be tricky but could be triggered selectively from an admin panel. Maybe all this should be packed into CI servers by default...
How stupid of people to reuse small often used functions that only do one thing well.
How does everyone taking the piss intend to protect themselves from this in their OS package manager, or PPM or composer or pip?
It's not javascript devs fault that the standard library is so piss poor you need these short code snippets and I've definitely included small 5-10 line packages via npm or other package managers rather than roll my own because it's likely they have bug fixes I haven't considered. I can also use npm to share these snippets between the many projects I'm building.
* No I wasn't affected by this because I review the packages that I want to include, however the level of smugness here is absolutely ridiculous.
But this whole thing is freaking funny. You gotta acknowledge that.
I think a lot of this is implying "don't use micro packages on your package manager, copy and paste code in helpers.js FTW". I've seen people advocating this as if it's a better solution than have npm remain consistent even after people unpublish packages.
It's best to treat NPM as mutable and don't depend on it. For example, I check in node_modules to git, even though everyone says no, use shrinkwrap! Yeah, that would definately help here.
NPM is to blame here and people are right to make fun of the entire ecosystem around it. Also, It's just easy and funny.
Noone will start copying stuff around just because of this I believe. The micromodule ecosystem emerged because it works for people apparently. Devs will find ways to make it work better.
But rather because they didn't wish to lawyer up for a trademark dispute that they had no particular reason to want to be involved in. (One where there was a reasonable chance that they would lose.)
$ echo "function leftpad(str, len, ch) { return ""; }" > leftpad.js
$ git commit -a -m "fuck you" && git push
I was bitten by a JS function change in a package that has been named also in this thread. It was an "oh, we moved that functionality to a new function, but reused the old name for a new function that does nothing like the old". And no semantic versioning.
Slipped through UI testing and broke production functionality. I did not like dependencies before, and I like them even less now.
And people keep wondering why everyone's software is so ridiculously bad.
A sane package repository won't disappear overnight, or ever. I can still install packages distributed with Debian Potato, the first ever Linux distro I used, which is now 15 years old. The code that I wrote against the libraries distributed with it will still compile, and had I only burnt stripped binaries to a CD back then, they would still runtime-link and run today on a brand-new install. And because it is all free software, the people and orgs who wrote those libraries, compiler, and standards, had given up their rights to force unpublication.
In a sane package management system, and with version pinning on the consumer's side, your hissy fit would have had exactly zero effect. Assuming your package were free software, people could fork it, and still make improvements.
JS isn't the first language without great libraries (C's stdlib, `math.h`, `string.h` are good but don't have string padding functions, for example) so there's precedence going back a very long way. Most solutions involve coming up with a utilities library that contains the basic things (like a math library, or a strings library).
There's nothing wrong with creating utility libraries for JS. I think people are surprised because the approach taken - that they are composable down to the function - is so radically different from the industry standard. Coupled with a package manager that requires fetching so many deps for such trivial functionality.
People do tend to form isolated communities around languages (look at the language for basic data structures between PHP, Ruby and Python) and this kind of thing probably helps shake up that isolation which is probably good for both sides.
(I could be wrong it could just be sneering)
printf("%20s\n", "Hello");
Only the PHP and JS communities seem to think that not having a solidly designed "base" library is fine (and even PHP seems to be getting better at it with 7).
There is no language with a less anemic standard library, and Java SE is often criticized for being too large.
The difference is absolutely massive. When working on Java projects, I've always included commons/StringUtils reflexively, and even then Ruby is quite a bit ahead.
The same applies to collections / enumerables. There's a lot in Ruby that I don't like, but powerful "batteries included" standard libraries for the basics like strings and collections are the bedrock of any programming language. It only takes hard work to write them and test them, not any specific skill, so there is no excuse for all the language out there that are skill lacking, in 2016, a sensible collection of utility methods.
http://docs.oracle.com/javase/8/docs/api/java/util/Formatter...
PHP would like to see you out back in the alleyway, as some other posters in this thread have pointed out.
> Java SE is an everything but the kitchen sink standard library, with functionality like collection classes, local and networking IO, windowing toolkits (more than one), database connectivity, the list goes on.
Yes. However, there are a lot of design decisions held onto because of backwards compatibility that continue to cause massive pain points. Object.toString() comes to mind. The fact that String.format() has to be either statically imported or typed out every time. I'm so sick of lengthy string concatenation in Java.
"When I use format " + createSentenceStringFromList(work.getCoworkers(), "and") + " act like I've committed " + A_HORRENDOUS + " crime."
Also, PHP 7 has absolutely nothing to do with standard libraries, as it doesn't really add anything in that regard.
You must not be a cool kid.
It's a collection of libraries, no one is using all of it.
(It always bewildered me - why hire the best of the best, and then make them work with lowest-common-denominator tools?)
And the same reason why some people now see that the presented Node popular practices aren't something that the battle-tested players consider reasonable to do.
Of course they do; how would you align printouts otherwise?
$ cat main.c
#include <stdio.h>
int main()
{
(void) printf ("%42s\n", "hello"); // right-align, 42 chars
(void) printf ("%-42s\n", "hello"); // left-align
}
$ gcc main.c
$ ./a.out | cat -A
hello$
hello $
$ ./a.out | wc -L
42Given how simple and popular `left-pad` module is (indicating the principle the community uses to determine granularity), I'd guess that if `String.format` was available in JavaScript there would still be a library to provide `leftpad`.
Either you arguing that `left-pad` is not a "dedicated" function for padding by 42 characters, because it can also pad for 43 or 41, or I don't understand you at all?
The examples were really secondary to the point of my argument, which was about packaging functions into modules, not about the C language.
Even more annoying, IMO, is the fact that this was a freaking denial-of-service over thousands of projects which was solved IN HOURS. Instead of celebrating the resilience of the duct-taped Jenga game that is the internet, we're complaining about how other programmers should be more like ourselves? What is this, vi vs emacs? :D
Obviously people shouldn't have trusted npm - that's the reason things broke in the first place!
> How does everyone taking the piss intend to protect themselves from this in their OS package manager, or PPM or composer or pip?
The usual method is to bundle dependencies rather than pull them down from the web at deploy-time. That or use a package manager with rather stronger guarantees on availability of packages.
> It's not javascript devs fault that the standard library is so piss poor you need these short code snippets
This is very true.
> the level of smugness here is absolutely ridiculous.
Also true, but funny nonetheless.
By signing packages and not allowing literally anybody to re-upload a brand new package that does something completely different under the name of an existing, widely-used package. There's not much excuse for that in any respectable package manager.
All this because a few bytes of functions would ruin your experience and/or dead code eliminiation isn't part of your pipeline.
This is a straw man argument. The reason so many people are criticizing left-pad et al is about the cost of adding a dependency.
> trust their package manager
That's exactly the problem: you're assuming that a package manager can be trusted. The network isn't reliable, packages can changed innocently or maliciously, and mistakes happen.
The "stupid" part is pretending these have zero risk, and the part that makes some people angry is when they also have to depend on this zero-risk assumption transitively through another library.
> It's not javascript devs fault that the standard library is so piss poor
Nobody is claiming it was. However, Javascript devs are responsible when they add critical dependencies on external components. They are also responsible when they publish libraries that extend those critical dependencies to the people that use their library without a very good reason.
The cost of a dependency for a good package manager is zero, and the cost of not having that dependency is non-zero. So the problem is with NPM, not with adding a dependency.
just saying be an engineer. weigh the costs
It's a lot like DLLs/shared libraries, actually: people marshal the same old arguments every time explaining why they are a great idea in theory, but in practice, there seems to be a whole hell of a lot of work being done to make up for the fragility you bring on board with a system like that, and I'd rather just embed the source or link it statically (depending on which context we're talking about here) so that I don't have to waste any time thinking about it.
The recent left_pad fracas has proved that that is not the case. Snapshot dependencies in-tree? Sure. But a package manager based dependency will be predicated on trusting a lot of things.
For the record, I believe that npm is a pretty good package manager. And the dependency cost I talk about is universal -- any package manager that allows for easy package updates is open to critical packages being broken. Removing the "unpublish" feature (and using something like Cargo's yank) makes it harder for left_pad like incidences to happen, but you still have issues with broken package updates, etc. You can further solve this with global version pinning, but not everyone will do this so you're still stuck.
That's great, and my point was that with a good package manager, that cost is effectively zero.
> And the dependency cost I talk about is universal -- any package manager that allows for easy package updates is open to critical packages being broken.
Automatic updates are a terrible idea, even if the developer purports to use "semantic versioning" and the update is supposed to be backwards compatible. Specifying a version should be mandatory.
Your package manager could easily notify you that updates are available, but it should never update for you. That's as "easy" as updates should get, because anything else inevitably introduces silent breaking changes.
yes, which doesn't refute pdkl95's point. If you're not in the world with a good package manager, you should consider the cost of the dependency. The Node ecosystem seems to not have done that. That's the bottom line here, if there is a cost to dependencies (which you don't seem to disagree with, at least wrt NPM), then you shouldn't have dependencies for 11-line functions. Everything else is orthogonal.
NPM, like any package manager, pretty much blindly accepts user input. I, as a module maintainer, could happily change every single function in my modules to
function whatever() {
return "WHHEEEEEEE!!!";
}
Seriously, the properties of good package management should be obvious by now. Any design that can break dependents and there's nothing they can do to protect themselves is broken.
And pinning versions just means you lose automatic updates, which is surely the point of using a package manager in the first place. Otherwise you might as well just download the package and include it verbatim.
No True Scotsman is so often mis-attributed, that the mis-attribution needs to be its own fallacy.
My comment was against this belief that "smarter" tools in general are some sort of panacea.
For example pining to a specific version won't help you match if the package is removed altogether (as in this case), and ever worse if it's replaced afterwards by another (newly registered) with an incompatible same version out. It won't try to overwrite your specific install of course (since the version already matches what you have), but you'll feel the pain when you try to duplicate/deploy etc a new install with the same package listing -- suddenly the package either won't be there (or will be modified in the worst case scenario).
So, then we opt for ever more features of a "sufficiently smart package manager", e.g. signatures, permanence of anything published etc...
The point is that people use package managers and third party modules installed from them to automate tedious work, and anything automated will have the potential to do something other than what you want. Is that risk high? Not really, but it's not zero either.
As to curated package managers, I'd consider them a great counter-example. Try installing a recent (5.x) version of node and postgres (9.4) on ubuntu. You can go through the rigmarole of adding an entirely new repository for postgres (apt.postgresql.org) since the debian distributed version of postgres is rather old (and ubuntu-version specific). You can also do the same thing with nodesource for nodejs, but if you install node on ubuntu, you'll get a packet radio service instead.
Curated package managers are very conservative and move very slowly. Javascript is a relatively fast-moving, pretty anarchic environment.
The lesson of left-pad is probably: vendor your node deps and check them in. And also: npm probably needs to be replaced with a write-once store with cryptographic signing of packages. You still have to trust the author, but that's the point of open source. We're built on trust.
Not sure what your point is on postgres, since 9.4 is right there in the repo.
Node moves fast, sure. I'm not sure I agree with your "crazy breaking" modifier there: I regularly do dev work against the latest 5.x branch of node, and rarely if ever have to worry about breaking changes. Then again, I'm just doing plain old restful api and business logic stuff, so maybe if you're dealing with the c++ interface it's a different environment.
Even still, I think it's easy enough to see from our disagreement over "too fast" and "quite sensibly" that there's plenty of ways to be a programmer. Rapid improvement can be kind of exhausting (especially if you get behind) but it's also a great way to see new ideas emerging. One of the things I actually love about the javascript world is how quickly things move. Things evolve very quickly because there's so much churn, speedy releases, pressure for mindshare, and so on. It's fascinating, both technologically and sociologically.
It ought to be pretty straightforward to say "apt-get install nodejs-5.3" and have that Just Work, but by the time the curators get around to updating their packages, you may well be a month or three behind. (again, unless you've updated your sources.list.d to include the nodesource repo).
So yeah: curated package managers have a place in the world for sure. But the trade-off here is that you're not getting the Latest and Greatest. Joyent tried to Slow Things Down with the 0.10 branch of node, and you see where that got them.
About the only good thing that comes from this is that we get to laugh out loud every half a year when there's a random GitHub outage and those companies all scream bloody murder.
I disagree. Another non-zero cost that I don't see mentioned yet is a licensing cost. What if there is some GPL'ed code somewhere in the dependency chain, but you don't know it because you are using code that uses GPL code but didn't realize it? Using lots of dependencies is just asking for licensing hell
Only if one doesn't understand the notions of opportunity cost, code debt, and several other things besides...
Exactly. I'd like to know if andy_ppp reviews every update to packages that andy_ppp wants to include too.
It's all very easy to say of course and loads of people having been saying including small piece of code from your package manager is wrong. I'm saying it's not and giving reasons why. Trust your package manager or help make it trust worthy I guess.
There's a lot of talk of decentralizing npm - but come on folks, what motivation would npm the company have to do that? It's the same issue as with GitHub (only that, with GitHub at least, if you're using git properly, GitHub disappearing tomorrow should have little impact).
There are probably enterprises that would pay good money for this, especially 5+ years from now when these apps are much larger and harder to maintain.
The first is that every added dependency creates ongoing cost, and that in a world where it becomes typical for a single application to have hundreds of dependencies, this cost is non-trivial and is, at minimum, worth considering.
The second is that even before the left-pad fiasco, a lot of experienced individuals (myself included) believed that npm is fragile by design; and that the dependency situation means that if you want to avoid nasty surprises, you need to pin every version of every dependency and you need to keep your own local copies of all of the files in case something like this happens.
Overall, you're accusing others of failing to fully understand the situation and of being condescending and rude; but you're doing it in a way that is condescending and rude, and that fails to fully understand the situation. Responses like yours are completely unhelpful. They do not change hearts or minds. They do not help npm fix their problems. And your caricature of those who find the situation funny is so distorted from reality that nobody will see themselves in it.
The fact that your post is top of HN is just more evidence that Hacker News is no longer a useful website. It's kind of funny, YC gets better every year, but HN gets worse. I wonder at what point Sam and pg will realize that this cesspool is actually hurting their brand.
I agree with you!
>>> you're accusing others of failing to fully understand the situation and of being condescending and rude
I'm saying that people who say "massive helpers.js file yo" is not a solution. Improve the standard lib, npm and use lodash.
I'm also saying we all rely on other package managers so don't think just because you saw npm as flawed you get a free ride to say this couldn't happen with other systems. All of them have various ways of poking holes in any security you think they have.
At some point you have to put trust in your package manager. I'm riling against the people saying to copy and paste code everywhere.
>>> The fact that your post is top of HN is just more evidence that Hacker News is no longer a useful website. It's kind of funny, YC gets better every year, but HN gets worse. I wonder at what point Sam and pg will realize that this cesspool is actually hurting their brand.
Disagree sure, but I think to say that my post is from a cesspool is a bit over the top!
Lodash also ships hundreds of independent npm modules for those who don't need the entire package. Here is pad as an independent package: https://www.npmjs.com/package/lodash.pad.
Lodash is here today, it works, it is reliable, and it doesn't pull the rug from under you.
As @sod pointed out the change is based on the newish ES7 proposal.
Well, they could use a better language which compiles to Javascript …
Apparently it's not obvious that having a ton of dependencies on 3rd party packages, of which can change at any time on the whim of the owner, is pretty insane in terms of security and minimizing complexity of your application.
You do realize that even though you reviewed the 20 different packages you use at one time, they can change at any time?
I would love to hear what a senior dev at any reputable, long established technology company thinks about including tens, if not hundreds (and some apps, thousands?) of 3rd party packages from strangers on the internet with no validity checks in place. Sign me up!
Well... Maybe a better word is naive? Because every additional package dependency is a risk. It's a risk in a security sense (has anyone ever wondered what is in left-pad in your organization?) and an engineering sense, as demonstrated by the latest JavaScript Bro if the month's industry-crushing personal power fantasy that you all cheerfully turned into reality by letting him control trivial but critical parts of your codebase.
It's true that to an extent, that risk is unavoidable if you want code reuse. Too little code sharing has the exact same problem! But I think that arguing that any programmer in a position to need left-pad should be given edit rights to a non-toy project is what were needling you all about.
The node communtiy has gone too far in one direction and embraced reuse for reuse's sake, not to address any real complexity.
Seriously, some languages have broken package systems and it looks like it's not the case for JS ... in fact it's working so well they are used ad nauseam, for trivial things even. This is to be expected from a language that is very flexible, but does not offer 'standard' ways of doing things built in, or at least offers the functionality as part of the distribution of the language libs/modules. JS just hit puberty, and will mature ...
I don't get the supposed irony.
Beyond a certain level it is indeed stupid of them.
And the examples we've seen were all below that level.
Correct, it's the fault of the devs who prioritize their ego and feeling trendy over the practicalities of software design. JavaScript is not a good platform for Real Work(TM). The fact that the stdlib is tiny and such basic functions have to be imported from some random guy's library is a testament to this fact.
Personally I can't wait for the JS-everywhere fad to die out.
So many good things happen in the JavaScript ecosystem. Nothing is perfect. This kind of criticism can help. Even if it's a bit much these days/hours ;)
I can't imagine npm and many others won't learn something from this. What more can you ask for?
Node/npm and the web need a standard library that can be included piecemeal, from a well trusted source and packages that only depend upon this small subset should be highlighted.
require('std/string/pad');
[1] http://lucumr.pocoo.org/2016/3/24/open-source-trust-scaling/
Actually thinking about it, an ideal solution would be a combination of stackoverflow and npm: all the solutions to a problem grouped together in one place with community votes and comments, and then you can subscribe to an answer from your code.
Furthermore, left-pad didn't really do one thing well. It did one specific subcase of one specific problem well. That's like a tenth of a thing, for a definition of well that basically means "written by a monkey taking an npm tutorial".
This also feeds into an extreme example of the continuing discussion around the cost/value/risks of extensive, transitive dependencies with the general consensus being that you would've been better off writing your own left-pad function 1,000 times rather than forcing the risk of this dependency onto your downstream.
Exactly. And no amount of evidence or disasters will ever convince them otherwise, so we all laugh at them.
http://api.left-pad.io/?str=foo&len=7&ch=12
return {"str":"12121212foo"} and not {"str":"1212foo"}
var zero = require("number-zero");
var hundred = require("number-one-hundred");
var isDivisibleBy5 = require("is-divisible-by-5");
var isDivisibleBy3 = require("is-divisible-by-3");
var isDivisibleBy5and3 = require("is-divisible-by-5-and-3");
var numberToString = require("number-that-is-between-one-and-hundred-to-string");
var fizzbuzz = require("string-fizz-buzz");
var fizz = require("string-fizz");
var buzz = require("string-buzz");
var incrementByOne = require("increment-by-one");
var forLoop = require("for-loop");
var ifCondition = require("if-condition");
var elseIfCondition = require("else-if-condition");
var elseCondition = require("else-condition");
var lessThan = require("less-than");
var print = require("print-string");
forLoop(zero, lessThan(hundred), incrementByOne, function(i) {
condition(isDivisibleBy5and3, print(fizzbuzz),
elseIfCondition(isDivisibleBy3, print(fizz),
elseIfCondition(isDivisibleBy5, print(buzz),
elseCondition(print(numberToString(i))))));
});HELP!!
Month from now: left-pad announces purchase of $170 million office building in SV to house their 1200 employees
# ~ [8:47:18] $ curl 'https://api.left-pad.io/?str=點看&len=5&ch=0' {"str":"￩ﾻﾞﾜﾋ"}%
Wonderful
- Does it scale well?
- Is it pragmatic for long term use scenario?
- Is it Thread safe?
- Does it learn from previous call made to the API?
- Does it have a modern access layer?
- Does it enforce 2nd factor authentication?
- Is it compatible with Docker containers?
- What about multi-region scenarios?
- Any benchmark available showing usage with AWS + cloudflare + Docker + a raspberry pi as LDAP server?
$ curl 'https://api.S.io/?x=x&y=y&z=z'
{"S":"x z (y z)"}
$ curl 'https://api.K.io/?x=x&y=y'
{"K":"x"}It is plain jane flat html and the content is in a <pre> tag.
Can I rely on this service going to be around in 5 years? It just seems like this company might be, you know, a feature rather than a company.
BTW: Well done... nothing like rubbing it in. :o)
$ curl 'https://api.left-pad.io/?str=wat&len=10&ch=#'
{"str":" wat"}
Please provide github link to fork/submit pr :)
Also needs HATEOAS.
{"message": "Could not parse request body into json: Unexpected character (\'o\' (code 111)): was expecting comma to separate OBJECT entries\n at [Source: [B@6859f1ef; line: 2, column: 22]"}
Demo link: https://api.left-pad.io/?str=%22;
https://api.left-pad.io/?str=paddin%27%20oswalt&len=67&ch=@ {"message": "Could not parse request body into json: Unrecognized character escape \'\'\' (code 39)\n at [Source: [B@38ac0021; line: 2, column: 21]"}
I don't want to create a direct dependency between my code and your API. I'd rather create a dependency between my code and your client library's code, as I'm sure you will always keep that up to date with any API changes.
It's about "real programmers can write left_pad by themselves" and everybody else just sucks. True scotsmen etc.
Now I don't know why asm people arent feeling threatened and aren't attacking the C left_pad gurus yet...
Without any sort of nonce, this service is trivially susceptible to a replay attack
Ugh, how does this garbage even get upvoted so highly.
I feel like only non-javascript devs are bashing against small modules and NPM. All great javascript devs I know LOVE that mentality.
Let me offer some reasons why I (as a current Javascript dev having professionally coded in C/C++/Java/Python/PHP/Scheme) think this is great:
- Unlike most other languages, javascript doesn't come with a battery standard library. So you're often left on your own to reinvent the wheel. I mean, common, in Python you do "'hello'.ljust(10)" but AFAIK there isn't such thing in javascript. Javascript is more like the wild west where you need to reinvent everything. So having well tested libraries that does one thing extremely well is really beneficial.
- Javascript, unlike most other languages, has some pretty insane gotchas. I.e. "'0' == 0" is true in javascript. Most devs have been burned so bad in so many ways in Javascript that it's comforting to use a battle-tested library, even for a small feature, rather than reinventing it.
- And anyway, where should we put that function? Most big projects I've worked on have some kind of "helper file" that has 1500 lines, and then at some point different projects start depending on it so noone likes to touch it, etc. So, yeah, creating a new module takes a bit more time, but remember that it's not about the writing time but more about the maintenance time. I'd much rather have lots of small modules with clear dependencies than a big "let's put everything in there" file.
- I feel arguing about whether something should be in a separate module is similar to arguing without something should be in a separate function. For me, it's like hearing "Hey, learn how to code, you don't need function, just write it when you need it." And hey, I've worked in projects professionally where they had no function and it was TERRIBLE. I was trying to refactor some code while adding function, and people would copy my function inside their 1500 lines file. Let me tell you I left that company really fast.
- It's fair to say that UNIX passed the test of time and that the idea of having lots of small programs is extremely beneficial. It forces common interface and great documentation. Similar to how writing test force you to create better design, modularizing your code forces you to think about the bigger picture.
- As far as I'm concerned, I really don't care whether a module is very small or very big, as long as what it does is well defined and tested. For instance, how would you test if a variable is a function? I don't know about you but my first thought wasn't:
function isFunction(functionToCheck) {
var getType = {};
return functionToCheck && getType.toString.call(functionToCheck) === '[object Function]';
}
- Finally, it seems like Node/javascript hasn't started that way. Not so far ago with had Yahoo monolithic javascript libraries and jquery. Even the first versions of most popular node library (such as express) were first written as a monolithic framework. But it's been refactored into dozen of small modules with clear functions. And now, other libraries can just import what they need rather than the whole project.
OK, so I told you about the good thing. What about the bad thing?
- Adding dependencies to a project is REALLY HARD TO MAINTAIN. I've had so many bad experience using node because of that. I.e. I work on a project, it's tested and work fine. 2 months later I clone and start the project and everything breaks. Oh, X and Y libraries decided to fuck everything, that other library now depend on a new version of Node, but I can't upgrade node because that other library depend on a previous version of Node. It's complex. I won't go on in explaining my solution to this problem, but enough to say that it's a problem and installing random amateur libraries in a professional project can lead to disaster.
- It takes longer to code. I've touched that earlier. It's a tradeoff about write now vs maintain later. Take a look at segmentio github repo: https://github.com/segmentio. I'd personally love to have that as onboarding experience rather than some massive project with everything copy/pasted a few time. But yes, it took them more time to create those separate modules.
Are you not using semver? A common mistake I've seen is to depend on the "*" or "latest" version of a package, which obviously will break when the package releases a major update.
Also, applications should use shrinkwraps to pin their dependency versions to versions they've been tested with.