811–820 of 887 posts
Earlier quoted context omitted.
Would you like to memorise that number yourself to use in your app?
What memorise? How about this for a dependency: https://www.google.com.au/search?q=es6+epsilon
Earlier quoted context omitted.
Yep, I think this is a huge, HUGE part of it. Step 1: Create a culture in which "having open source contributions" is a requirement to entering said culture. Step 2: Remove all friction from introducing open source contributions into the culture. Step 3: Watch the Cambrian explosion. Step 4: (Two years later) Point to the Cambrian collapse and how the new hot thing will solve everything. I don't know what sort of shi…
That scenario in the last paragraph is an uncomfortably convincing view of the future. Do you think it could be avoided by an additional step like the following? Step 5: a mechanism for curated metamodules This would not have changed much for the current situation, but it might help cultivating a "too important to play it fast and loose" mindset that would.
It's about unforeseen consequences of a solution to a problem. That's what I mean by "I don't know what it will look like", because it will definitely solve the problem this thread is dissecting, and the problem it introduces will be a whole new vector.
But its selling point (the way it solves our current problem) will be a simple idea that is taken to its logical extreme by people who don't think critically, and then it will be time to solve that problem.
That is, I see the underlying recurring problem as stemming from the cultural forces –– how we educate people, how we make ourselves hireable –– that enable even very smart people to be shortsighted and immune to learning from the past.
Earlier quoted context omitted.
> Even if it does take the same amount of time (which it shouldn't), a 1-line call to a standard module imposes less of a future maintenance burden than 14 lines of custom code. In my experience with using npm since it's release, module authors will spit out modules very quickly then, after some period of time, abandon them without passing them onto other people. At which point I have to assume all future maintenance…
> Regardless I don't think I'd ever call very elementary code a "maintenance burden". Ever. Every line is another line that maintainers have to read and understand. > The point being: where it's possible to mitigate and remove dependencies I think you'd be crazy not to. Every dependency you can lose is another potential build issue or attack surface you're removing from your project. Disagree. If there are issues wit…
Seriously? This is what you're going with? We're talking about very simple, elementary programming. To be worried about maintaining code that you learn how to do in the first few classes of any programming 101 class is absolute insanity.
> Disagree. If there are issues with npm shrinking not working then you absolutely need to resolve them
Can't resolve them if the module disappears or is replaced with a malicious module. Nor if you or npm are having connectivity issues (which, on the npm side, happens very frequently).
> Just like if you've already written a good general-purpose sorting function, there's no point writing a separate integer sort routine, even if the implementation could be simpler than the general-purpose one.
Not sure what you're getting at. If you need a sorting function you can probably use whatever is built into the language unless you need to sort across a distributed data set in which case write something or find a dependency to use.
> You already depend on your packaging/dependency tools, so you might as well use them all the time.
Absolutely, unequivocally, no. What you're saying is you should install and use dependencies, from third parties which you do not know anything about, for every single, possible thing just so you can use the tools "all the time". That's so irresponsible and backwards.
Use the tools for the job they were meant to be used for. Need a dependency because someone can do it better / faster / cheaper then you? Then grab it by all means. But don't use it for every tiny function and for loop just because you want someone else to maintain it.
Earlier quoted context omitted.
A module doesn’t solve that kind of type confusion, though. Static typing does. The next best thing in JavaScript is passing consistent types of values to your functions, so just write function isPositiveInteger(x) { return x > 0 && Number.isInteger(x); } and always pass it a number. (Of course, this shouldn’t even be a function, because JavaScript is confused about the definition of “integer” – maybe you really want…
> A module doesn’t solve that kind of type confusion, though. Static typing does. That's the root of all the problems, though, isn't it? JavaScript is just a terrible language. Actually, that's not really fair. It's a great little language for writing late-90s Dynamic HTML, maybe just a little too powerful. And that additional power enables people to build cathedrals of cruft in order to Get Things Done. I don't like…
But I don't think an initial choice of implementing a Scheme would have helped. The idea of +0 vs 0 vs -0 could just have easily happened in a Scheme, same too for the reliance on stringy types. Those are symptoms of a rushed design and an unwillingness to accept the temporary sharper pain of invalidating existing bad code to produce a new better standard (the exact same tendency - to dig in deeper rather than risk the pain of turning back - is literally how spies managed to convince people to commit treason).
Then of course there's also the great risk that, just like Scheme not-in-the-browser, Scheme-in-the-browser might never have widely caught on.
Earlier quoted context omitted.
I'm not sure if you're saying this of my comment or the OP, but I code professionally every day in this style and it's working out just fine. And the smaller my modules get the better it seems to work.
It's not working out fine. You just haven't been around long enough to understand it. JS code is the most disposable piece of any infrastructure. In all companies(mine included) that I know of, npm and the JS jenga tower of hell is the most brittle element that breaks every fucking day. It's the constant pain you can count on being around. The stack and the dependencies are a moving target. Like.. every minute. If yo…
And i've coded plenty in other languages. None with anywhere near as good an experience as NPM if you know how to use it properly.
Earlier quoted context omitted.
> A module doesn’t solve that kind of type confusion, though. Static typing does. That's the root of all the problems, though, isn't it? JavaScript is just a terrible language. Actually, that's not really fair. It's a great little language for writing late-90s Dynamic HTML, maybe just a little too powerful. And that additional power enables people to build cathedrals of cruft in order to Get Things Done. I don't like…
There are already some quite advanced compilers that treat JavaScript itself as just a web assembly language, you don't technically have to wait for WebAssembly. TypeScript (some type safety) PureScript (Lots of type safety) and GHCJS (MOUNTAINS of type power) all work right now, though the latter is still experimental grade. But I don't think an initial choice of implementing a Scheme would have helped. The idea of…
Yeah, there's even a Common Lisp which compiles to JavaScript …
> The idea of +0 vs 0 vs -0 could just have easily happened in a Scheme, same too for the reliance on stringy types.
I don't necessarily know about these specific examples: the Scheme standards have been quite clear about their numeric tower and equality standards.
I think your general point about the hackiness which was the web in the 90s, and the unwillingness to break stuff by fixing things holds, though. And of course it wasn't just the web: I recall that the Makefile syntax was realised to be a mistake weeks into its lifetime, but they didn't want to fix it for fear of inconveniencing a dozen users (details fuzzy).
> Then of course there's also the great risk that, just like Scheme not-in-the-browser, Scheme-in-the-browser might never have widely caught on.
I dunno — would a prototypal language have ever caught on were it not for the fact that JavaScript is deployed everywhere? I can imagine a world where everyone just used it, because it was what there was to use.
And honestly, as much as I dislike Scheme, it would have fit in _really_ well with JavaScript's original use case and feel. And if the world had had a chance to get used to a sane, homomorphic programming language then maybe it might have graduated to a mature, industrial-grade, sane, homomorphic language.
But alas it never happened.
What is it about the node community that triggered this misunderstanding of package management and code reuse?
Earlier quoted context omitted.
It should, but the ECMAScript spec doesn't have it, and Node.js team prefers to keep the core libraries to a minimum and definitely do not want to modify prototypes. Thus we depend on userland to provide those features for us.
Thats why somebody should fork Node and start building a batteries included standard library.
I don't see nobody criticizing 'std::min()'. Perhaps what we really need is a 'std' for js?
`std::min` isn't a library of its own, it's a function in the ` ` header of the Standard Template Library. The STL also encompasses a wide range of other things. There are some efforts to provide "the missing standard library" for JS, e.g. lodash.