791–800 of 887 posts
No it's because they don't do the same thing at all. This comparison shows you clearly don't understand the first thing about promises.
Earlier quoted context omitted.
> #include #include #include #include I've written worse - at least those cover multiple variations each (or overloads in C++ for float/double/std::complex?/...) While I'm not a fan of the enforced java route of 1 file = 1 class, I do trend towards 1 file ~ 1 (main, public) thing - which might be a single function with no overloads. #include ? Better than #include , which I see far too often... I don't have to figure…
Java doesn't enforce 1 file = 1 class but rather 1 file = 1 public class, which is exactly what you asked for. You can put as many private classes in the file as you want.
For example this is totally legit:
// ClassA.java
public class ClassA {
public static class ClassA_Inner_Public_Static {
}
public class ClassA_Inner_Public {
}
}
// ClassB.java
public class ClassB {
ClassA classa = new ClassA();
ClassA_Inner_Public classA_Inner_Public = new ClassA().new ClassA_Inner_Public();
ClassA_Inner_Public_Static classA_Inner_Public_Static = new ClassA_Inner_Public_Static();
}It's good to have small packages. Don't forget that the underlying ECMA script is changing so the implementation of these 'libraries' are (or will be) different over time from what they used to be. If somebody finds a faster way to do the method, then it will be done.
Finally, anybody who has used js in the real world understands how many corner cases there are and how difficult it is to make durable methods (i.e. how to know if an array is empty - which requires like 4 different conditions).
I may have just invented a rule for choosing programming language and systems there.
Earlier quoted context omitted.
> 100% test coverage is rarely a good thing Do you mean rarely useful, or actively harmful?
Both in a way. What happens when you have a "100% test coverage" requirement is that people don't think about the tests, they simply make tests to force the code down every path without thinking whether it was intended to operate like that. For example if the is-positive-integer had a silly test for "if(value==23) return false", a requirement for "100% test coverage" would simply result in someone creating a test for…
It's like following someone's car and congratulating the driver that he drove correctly, without considering if he reached the correct destination.
Earlier quoted context omitted.
>would your first thought be to go searching for a package No, because if this isn't in the standard library (or a very simple one-liner from standard library functions like "fold +") then I don't want to be working in this language. If I have to work in this language, and I'm allowed to bring in packages, I'd go look for the community's attempt at fixing the standard library, or at least a "math" package, particular…
> If I have to work in this language, and I'm allowed to bring in packages, I'd go look for the community's attempt at fixing the standard library ... If it's really just this, I'll probably paste a Stackoverflow answer. Sorry, can I get this straight, we're talking about sum() now, right? I'm genuinely amazed. > thinking through the pitfalls of the implementations of basic math operations is not a good use of time I…
Sure, if it's really just arithmetic on lists, I won't be happy about it, but I'll write it. I've yet to meet a standard library which is wonderfully complete except for that one thing. If the abstractions of the environment I'm working in are that poor, there's going to be a thousand other little "trivial" things that I'm now responsible for maintaining, and some of them will turn out to be less trivial than imagined.
For example, it is "trivial" to write linked lists in C, but tracking down the one-character typo that causes them to nondeterministically explode is IMO a distraction from the project, not a valid part of it.
And what about the next project in that language? Wouldn't it be nice to factor out all that stuff and bring it with me? Well, now I am using a community standard library, but it's the community of "just me." Why not take one with some internet recommendations and an active Github?
My employer fortunately runs its own package mirrors, though, so we don't run the risk of packages just disappearing on someone else's whim.
I suppose our difference in values is that I consider each line of in-house code as much of a liability as you consider each line of other people's code.
My reaction to the article is very simple:
>What concerns me here is that so many packages took on a dependency for a simple left padding string function, rather than taking 2 minutes to write such a basic function themselves.
"So many people" writing a basic function themselves is an exactly wrong outcome IMO.
Earlier quoted context omitted.
I think that was smokeyj's point... the left-pad module is not going to have a "backdoor". nv-vn was creating a bit of a straw man, as no example or particular scenario in this article involved crypto.
No, I disagree with smokeyj drawing a false parallel to encryption to try to justify why you should use an external dependency for 12 lines of code -- because "you should never roll your own crypto" is not applicable here.
My point is OSS is a collaborative effort by often times anonymous contributors. Therefore there will always be a risk of bugs or back doors - regardless of the distribution mechanism.
In my opinion any criticism against micro packages is equally valid against large packages. There's no guarantee that a pull request would receive any more scrutiny than a external dependency. I mean look at heart bleed. Surely this doesn't mean that OSS is broken, but rather stricter security protocols should be in place. My 2 cents.
Earlier quoted context omitted.
Writing your own solution, when you could use a common widely known solution, exactly matches both writing your own left pad and inventing your own wheel. > By the JS community's standards if I wanted code to capitalize the 3rd or sometimes 4th letters of a string, they would be 2 different npm modules. If there was, it would have been published and people would be depending on it. Instead, people use the stdlib firs…
But surely the really concerning part is despite their very wide usage, these dependecies turned out in some cases to be poorly coded functions indeed. Throughout this whole thread are examples where these one or two line "modules" have poor runtime performance, miss key cases in the one single thing they claim to do, and in the very worst cases, those small "modules" themselves are depending on many more "modules".…
Where? I've only seen the exact opposite: folk who don't believe in package management write their own naive 'reinvent the wheel functions' with those issues. Nobody I can see is quoting actual npm modules.
Earlier quoted context omitted.
Yes, uncompositionality of callbacks leads to callback hell. Or to reinventing every single thing but for callbacks. Like array.map (which works with promises) or array.forEach (also works with promises) or every single synchronous function (they all work when passed to promises).
If you solve callback hell for a series of sequential functions by using an actual series of sequential functions, you don't have nested callbacks and you didn't require Promises or composition - just a basic understanding of data structures and first class functions. It seems you're defining callback hell as 'whatever promises solves' rather than it's common definition of over-nesting.
Node style callbacks are a prime example of how in the quest for "simplicity" and hate for abstractions its easy to build a monster / frankenstein like caolan's async. Node callbacks were a self-contradicting philosophy: it abandoned all thats already in the language in the quest to avoid an abstraction that was not already in the language :)