I'm getting tired of this npm shit



  • From the same api library I've been lambasting yesterday.

    0_1471330886765_upload-636f07ed-79a8-4d0b-a3d8-cd970388c2f7

    Ok, so what is isWithin?

    0_1471330930545_upload-83e2d293-680d-4089-81c0-08d9d3160e90

    And what is gte?

    0_1471331022891_upload-691bde30-c36e-404e-85af-552eae07814d

    ...

    Sigh.

    For fuck's sake people, ENOUGH WITH THIS SHIT ALREADY!

    Just use the fucking language as it was intended.

    function in200s(status) { return status >= 200 && status < 300 }
    

    There. How hard was that? You don't need 17 curried fucking function calls to compare 2 numbers.

    You want to do this in your application code? Fine, whatever. Perf usually isn't an issue. If you like the functional circlejerk, go right ahead.

    In a library? NO! You go for simple performant javascript. Copy-paste over composition. Named functions. Readable small stack traces. Leave this fancy shit for something your users won't have to debug or try to understand.

    I'm not an npm hater. There are obvious advantages to its small modules ethos. But this kind of shit is taking it too far.



  • @cartman82 said in I'm getting tired of this npm shit:

    You don't need 17 curried fucking function calls to compare 2 numbers.

    This is 2016. You're just a Luddite who fears change. Get with the program.


  • kills Dumbledore

    @cartman82 said in I'm getting tired of this npm shit:

    curried fucking function calls

    Is curry another word that's been adopted by some library to mean something completely unrelated because the author thought it sounded kind of cool?


  • BINNED

    @Jaloopa INB4 rhyming slang!



  • @Jaloopa It's a functional programming term.



  • @Jaloopa said in I'm getting tired of this npm shit:

    Is curry another word that's been adopted by some library to mean something completely unrelated because the author thought it sounded kind of cool?

    Functional programming BS. I'm sure local FP fans will gush how important it is, but I'm yet to see a real world system where this shit actually made anything better.



  • @Jaloopa It's a way of breaking up a function from taking multiple parameters into a function that takes just one.
    e.g.

    function isWithin(min) {
      return function(max) {
        return function(value) {
          return value >= min && value <= max;
        };
      };
    }
    var in200s = isWithin(200)(299);
    

    I'm assuming that whatever 'ramda' is, allows you to supply more than one argument at a time for simplicity's sake, but honestly it's completely and utterly pointless.
    If I ever needed to do that, it's not like it's hard or error prone to just do it yourself manually whenever you need to.
    But that's a pretty big "if".



  • @Salamander said in I'm getting tired of this npm shit:

    whatever 'ramda' is

    lambda with a speech impediment?


  • kills Dumbledore

    @flabdablet Japanese lambda



  • @Jaloopa No, those are noodles.


  • kills Dumbledore

    @flabdablet You're thinking of ramen. Lambda is a fluffy animal, larger than a sheep, prized for its wool



  • @cartman82 currying is nice when you're in a functional environment. Once you've gotten used to currying you want to use it everywhere. Having to name all parameters down to the last one is very tiring. Still JS is not a functional language. So adding that stuff in is going to cause some friction. The code you posted is much too clever for what it does.

    I wonder what that _ramda2.default. is doing in there 😕 the whole thing looks extra-shit because of it. A simple ramda. prefix would have looked bad enough.



  • @Salamander said in I'm getting tired of this npm shit:

    @Jaloopa It's a way of breaking up a function from taking multiple parameters into a function that takes just one.
    e.g.

    function isWithin(min) {
      return function(max) {
        return function(value) {
          return value >= min && value <= max;
        };
      };
    }
    var in200s = isWithin(200)(299);
    

    I'm assuming that whatever 'ramda' is, allows you to supply more than one argument at a time for simplicity's sake, but honestly it's completely and utterly pointless.
    If I ever needed to do that, it's not like it's hard or error prone to just do it yourself manually whenever you need to.
    But that's a pretty big "if".

    All I can think of to say about that code is that people who advocate it are prime evidence that humans are, indeed, too stupid to be dumb animals. I kinda get the notation you'd use in Smalltalk for a "between" method, something like X isBetween: Y and: Z - it's kinda cute, and ends up reading like a sentence, but isWithin(200)(299) has no redeeming features.



  • @gleemonk said in I'm getting tired of this npm shit:

    Still JS is not a functional language.

    Yes, it is. More or less.

    Still, there are many function-oriented1 languages that don't curry implicitly. Adding a curry operator only for the cases where needed seems much simpler to me.


    1 Structured procedural languages with heavy use of higher-order functions rather than full functional languages. Similar to the distinction between objective languages (like SmallTalk, where dynamic dispatch is basically the only control structure) and object-oriented languages (like Java, where Everything Is An ObjectTM, but flow is mostly controlled by procedural control structures).



  • @Steve_The_Cynic said in I'm getting tired of this npm shit:

    but isWithin(200)(299) has no redeeming features.

    From the example/explanation on currying in JS, I think the "curry" function would make it so that you can write isWithin( 200, 299 ), isWithin( 200 ) or isWithin( 200, 299, 123 ) instead.

    Now, on the other hand, this means that depending on the number of arguments you pass to isWithin(), it will either return a function or a boolean. Because that will never be confusing at all. Plus, I'm guessing that functions are "truthy" values, too, so there's definitively no way that could go wrong.



  • @cartman82 but the function on npm will only return true if it's a number, your version will tell that "zebra" >= "dog" 🚎



  • @groo said in I'm getting tired of this npm shit:

    @cartman82 but the function on npm will only return true if it's a number, your version will tell that "zebra" >= "dog"

    If your web server returns status code "zebra", you have bigger problems than currying.


  • FoxDev

    @cartman82 said in I'm getting tired of this npm shit:

    @Jaloopa said in I'm getting tired of this npm shit:

    Is curry another word that's been adopted by some library to mean something completely unrelated because the author thought it sounded kind of cool?

    Functional programming BS. I'm sure local FP fans will gush how important it is, but I'm yet to see a real world system where this shit actually made anything better.

    eeh. honestly currying functions is convenient for making composable functions, but it's way way way way overkill for what it's used for in this ramdasauce pagkage.

    i peeked at ramda, and i gotta say that it's interesting, i could see it being really useful for transforming config files into code (for things like machine learning and stuff) but that's the sort of stuff that you just don't have to do with JS and the main usage of that sort of stuff isn't usually done in JS because of the whole single thread thing.



  • @Bulb I don't see JS as a particularly functional language. It uses assignment and side-effects everywhere. If you want to get around that, you have to do extra work. I use Underscore.js a lot and I think it's a good example of how much more functional JS could be, but isn't. I don't see how it differs much from Java in that respect because both languages are intended to work with mutable objects mostly.

    Adding a curry operator only for the cases where needed seems much simpler to me.

    Agreed. When your language doesn't do it natively, making every function curryable is excessive. I'm not going to defend Ramda here 😆



  • @cvi said in I'm getting tired of this npm shit:

    Now, on the other hand, this means that depending on the number of arguments you pass to isWithin(), it will either return a function or a boolean. Because that will never be confusing at all. Plus, I'm guessing that functions are "truthy" values, too, so there's definitively no way that could go wrong.

    Yup. Because Haskell is statically typed, so the compiler will tell you if you didn't pass enough arguments and got a function taking the rest instead of result. And it's still pretty confusing, though rather because many expression simply omit the arguments at the end, leaving it up to the implicit currying to deal with them.

    But JS is dynamically typed, so nothing's gonna warn you.



  • @Steve_The_Cynic said in I'm getting tired of this npm shit:

    but isWithin(200)(299) has no redeeming features

    Sure has! How else would you define the isBetweenZeroAnd function!?

    var isBetweenZeroAnd = isWithin(0);
    

    Then you can write

    var isSmallNumber = isBetweenZeroAnd(10);
    

    Don't you see the expressive power? 🚜


  • area_pol

    @cartman82 said in I'm getting tired of this npm shit:

    There are obvious advantages to its small modules ethos

    I wonder what these advantages are.
    The only one I can see is that if you deploy a client-side web application, the code size is limited only to the things you use. However, if every lib depends on every lib - as you demonstrate - this advantage starts to disappear.

    My experiences with big standard libs and monolithic frameworks in C++ Python Java are very pleasant - you rarely need to look outside the framework, so you can focus on the task not on library choice. And all parts of the framework use compatible data structures.
    I would never exchange that for a plethora of small modules containing 1-2 functions each.



  • @gleemonk said in I'm getting tired of this npm shit:

    @Bulb I don't see JS as a particularly functional language. It uses assignment and side-effects everywhere. If you want to get around that, you have to do extra work.

    That's why I then called it "function-oriented". It passes functions around a lot.

    @gleemonk said in I'm getting tired of this npm shit:

    I don't see how it differs much from Java in that respect because both languages are intended to work with mutable objects mostly.

    It does differ from Java a lot. Java only got a reasonable lambda expression in version 8 and it's options for function composition still suck. But Java is particularly bad in this regard. Even C++ seems to be better with it's completely uncomposeable algorithms.


  • Impossible Mission - B

    @cartman82 said in I'm getting tired of this npm shit:

    @groo said in I'm getting tired of this npm shit:

    @cartman82 but the function on npm will only return true if it's a number, your version will tell that "zebra" >= "dog"

    If your web server returns status code "zebra", you have bigger problems than currying.

    But do you have a bigger problem than "dog"?


  • area_pol

    @Bulb said in I'm getting tired of this npm shit:

    Java is particularly bad in this regard [functional style]

    If you want to use a functional style in the JVM ecosystem, you can use Scala.



  • @Adynathos, I would, personally, like to use a functional style in the C++ ecosystem. With Boost.Functional and Boost.Range it is even sometimes possible, but mostly it is still pain in the arse.



  • @cartman82 what about this:

    console.log("000" >= "  9")
    true

  • FoxDev

    @groo said in I'm getting tired of this npm shit:

    @cartman82 what about this:

    console.log("000" >= "  9")
    true
    

    the string 000 sorts higher than the string 9 that seems perfectly cromulent. if you wanted natural language sort you're gonna need a higher level sort anyway because natural language sorting is HARD


  • :belt_onion:

    @gleemonk said in I'm getting tired of this npm shit:

    I wonder what that _ramda2.default. is doing in there the whole thing looks extra-shit because of it.

    That's because the source code for Ramda is built using BabelJS or something similar, and that's how Babel transpiles imports:

    import ramda from 'ramdajs';
    rambda.gt(33);
    
    // gets transpiled to
    
    var _rambda = require('ramdajs');
    var _rambda2 = babelGeneratedInteropDefaultRequire(_rambda);
    _rambda2.default.gt(33);
    

    Which is a bit much, but until we actually get modules in the language it's a sane half-way house.



  • @svieira said in I'm getting tired of this npm shit:

    import ramda from 'ramdajs';
    

    For us noobs who don't regularly work with JS, what is the advantage over simply writing

    var ramda = require(`ramdajs`);
    

    ??



  • @Jaloopa said in I'm getting tired of this npm shit:

    @flabdablet You're thinking of ramen. Lambda is a fluffy animal, larger than a sheep, prized for its wool

    No, this is a Lambda.

    http://www.model-forces.com/wp-content/gallery/lambda-class-shuttle/shuttle_001.jpg



  • @Adynathos said in I'm getting tired of this npm shit:

    I wonder what these advantages are.
    The only one I can see is that if you deploy a client-side web application, the code size is limited only to the things you use. However, if every lib depends on every lib - as you demonstrate - this advantage starts to disappear.

    I was thinking more like, it's a framework that encourages OSS consumers to become OSS producers.

    Node modules are small and understandable. They naturally foster code separation. They are easy to create, import and publish. Anyone can put up a shingle and set up their OSS shop.

    This allows a bunch of half amateurs to come together and produce a pile of functionality to rival expensive corporate-backed frameworks like .NET or JCL.


  • FoxDev

    @Bulb said in I'm getting tired of this npm shit:

    @svieira said in I'm getting tired of this npm shit:

    import ramda from 'ramdajs';
    

    For us noobs who don't regularly work with JS, what is the advantage over simply writing

    var ramda = require(`ramdajs`);
    

    ??

    AFAICT..... there is no advantage.

    i mean there is the advantage of having multiple exports per module python style, but that's easily solved by doing

    var ramda = require('ramdajs').ramda;
    

    so..... yeah.

    there are a bunch of other arguments that hold varying merits for using babel (like being able to write in esNext and have it transpiled down to es3 or es5) but the import stuff.... makes no giddess damned sense.


  • area_pol

    @cartman82 said in I'm getting tired of this npm shit:

    encourages OSS consumers to become OSS producers

    Good point, I looked only from the perspective of a library user, not a library developer.



  • @Bulb said in I'm getting tired of this npm shit:

    import ramda from 'ramdajs';
    ...
    For us noobs who don't regularly work with JS, what is the advantage over simply writing

    var ramda = require(ramdajs);

    ??

    The former are "official "ES6 modules.
    The later is node's module system that's called commonJS.

    ES6 modules are considered the future, being "official" and all, so there's a push to use them instead of node style modules.

    The main technical difference is that commonJS require() is just an ordinary js function. So you can do something like:

    if (condition) {
       res = require('module').something.fn();
    }
    

    You can't do that with ES6 modules. There are no return values. No code can be executed before or in-between import statements. AFAIK they aren't real code, but some special syntax that is used to gather dependencies, before the code starts executing for realsies.

    The advantage of that is, tooling can figure out the exact dependencies and do fancy stuff, like pack up all the code in one file and send it over the wire.

    The disadvantage is, IT'S PISSING ME OFF.



  • @groo said in I'm getting tired of this npm shit:

    @cartman82 what about this:
    console.log("000" >= " 9")
    true

    Who the fuck knows, it's javascript. Keep your arms inside the vehicle at all times.


  • area_can

    @groo 000 gets converted to octal, and since 9 starts with a space it is coerced to a falsy value (0)

    Not actually true but it sounds reasonable, doesn't it?


  • Impossible Mission - B

    @cartman82 James Iry's words from 2009 still ring true today:

    1995 - Brendan Eich reads up on every mistake ever made in designing a programming language, invents a few more, and creates LiveScript. Later, in an effort to cash in on the popularity of Java the language is renamed JavaScript. Later still, in an effort to cash in on the popularity of skin diseases the language is renamed ECMAScript.


  • area_can

    @cartman82 on the other hand:



  • @Salamander said in I'm getting tired of this npm shit:

    It's a way of breaking up a function from taking multiple parameters into a function that takes just one.

    Man, if only JavaScript had optional params, that might not be necessary.

    Oh wait.


  • I survived the hour long Uno hand

    @gleemonk said in I'm getting tired of this npm shit:

    I don't see JS as a particularly functional language. It uses assignment and side-effects everywhere.

    People like to say "JS is a functional language" when they mean "JS is shitty at OOP and it's very easy to shoot yourself in the foot in procedural paradigm but I like it anyway."


  • FoxDev

    @blakeyrat said in I'm getting tired of this npm shit:

    @Salamander said in I'm getting tired of this npm shit:

    It's a way of breaking up a function from taking multiple parameters into a function that takes just one.

    Man, if only JavaScript had optional params, that might not be necessary.

    Oh wait.

    man if only that were what ~salamander meant when they talked about currying functions.

    optional parameters do jack shit when you want to take a function that requires three parameters, specify two of them now and get a function back that now only needs the third parameter to be provided to call the original function with the two parameters you already specified and the newly provided third parameter.



  • @cartman82 said in I'm getting tired of this npm shit:

    This allows a bunch of half amateurs to come together and produce a pile of functionality to rival expensive corporate-backed frameworks like .NET or JCL.

    If you amateurs would give up on the retarded open source ideals like "release early, release often" and spend more time actually designing your language and framework before release, you could do that right now. .net wasn't made by magic, anybody could do it.

    The correct solution to your problem, which is: the open source community is completely incapable of making a competent class library, is to stop using open source crap.



  • @accalia said in I'm getting tired of this npm shit:

    optional parameters do jack shit when you want to take a function that requires three parameters, specify two of them now and get a function back that now only needs the third parameter to be provided to call the original function with the two parameters you already specified and the newly provided third parameter.

    But why would I ever want to do that?


  • area_can

    @blakeyrat said in I'm getting tired of this npm shit:

    But why would I ever want to do that?

    What does this have to do with you?



  • @bb36e said in I'm getting tired of this npm shit:

    What does this have to do with you?

    Ok; why would anybody ever want to do that?

    And are those use-cases, assuming they even exist, worth the bug-prone-ness of having a function that can return either a value or another function and no way of telling which at design-time? Because it'd have to be a HELL of a time-saver to justify that.



  • @bb36e said in I'm getting tired of this npm shit:

    @cartman82 on the other hand:

    TIL, good article.

    Furthermore, because JavaScript is a dynamic language, and because the prevailing CommonJS module system is also dynamic, it’s fiendishly difficult to extract unused code from the final payload that gets shipped to users. You might only need jQuery’s $.ajax, but by including jQuery, you pay for the cost of the entire library.

    There you go, another place where ES6 stodgy import syntax might help.


  • FoxDev

    @blakeyrat said in I'm getting tired of this npm shit:

    @accalia said in I'm getting tired of this npm shit:

    optional parameters do jack shit when you want to take a function that requires three parameters, specify two of them now and get a function back that now only needs the third parameter to be provided to call the original function with the two parameters you already specified and the newly provided third parameter.

    But why would I ever want to do that?

    well, you probably wouldn't because it's undoubtedly a shitty opensource programming pice of shit, but here are but two examples of why a developer might wish to do a thing....

    one reason might be, a developer has a function that encrypts data and they want to give it to some other code to encrypt data with but they don't want that other code to be able to see the encryption keys that also have to be passed to the encryption function. They can curry the encryption function to get a function that only takes the data to encrypt and provides the encryption keys and the data to the original function.

    or a developer have to glue two different parts of a developerr code base together, this one takes a callback that gets a single parameter, and this other one that needs to be called with three parameters. a developer can curry the second one to provide the other two parameters now, then pass the curried function to the function that calls a one parameter callback.



  • @blakeyrat said in I'm getting tired of this npm shit:

    If you amateurs would give up on the retarded open source ideals like "release early, release often" and spend more time actually designing your language and framework before release, you could do that right now. .net wasn't made by magic, anybody could do it.

    Anyone with a huge team of top notch programmers and millions of dollars to burn, that is.



  • @cartman82 Ok first of all, nobody involved in the creation of the JCL was "top-notch".

    Secondly, you're one of the few open source fans who'll actually admit that there are things open source isn't good at. Although you don't go as far to then simply not use those inferior things which is the ideal state.

    But most open source fans are not you. Most of them talk my ear off about how open source is better at everything everywhere all the fucking time. So I take pleasure in pointing out: no. The high-bar on open source quality is "barely acceptable". They've never hurdled that one.


Log in to reply