I'm getting tired of this npm shit

masonwheeler

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

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.

While I agree that currying is silly, you seem to be either misunderstanding it or misrepresenting it.

First off, technically, any JavaScript function can return a value or a function, because dynamic typing. But that's not what you meant, so I'll move beyond the ry.

The idea of currying is that the first function takes one argument and returns a function that takes the second argument and applies them both. So you know exactly how it will behave: the first one returns a function, the second one returns a value.

...which is still silly. But not anywhere near as bizarrely random as you complain about.

blakeyrat

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

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.

That might make sense in an environment using something like .net's MEF, but ... 99.9% of the time (and I believe 100% of the time in JavaScript) both bits of code are going to be in the same memory space and this would be just pointless wankery.

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

First off, technically, any JavaScript function can return a value or a function, because dynamic typing.

Right, obviously I get that. It's still a bad idea for a function to return an arbitrary data type in an unpredictable fashion.

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

The idea of currying is that the first function takes one argument and returns a function that takes the second argument and applies them both. So you know exactly how it will behave: the first one returns a function, the second one returns a value.
...which is still silly. But not anywhere near as bizarrely random as you complain about.

I get the idea, I'm asking what advantage it offers. So far Accalia's the closest to justifying this.

cartman82

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

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.

A form of currying is useful when you want to package up some state with a function, that you then pass along.

Eg.

function moveFile(targetDir, file) {
   //...
}

var fileHandler = moveFile.bind(null, '/tmp/a/b/c');

OOP way to do this would be to have a class encompass the needed state.

class Mover {
  public string TargetDir { get; set; }
  public bool execute(string file) {
    //...
  }
}

var fileHandler = new Mover { TargetDir = '/tmp/a/b/c' }

Two ways to do the same thing. Both reasonable, but functional is a bit neater IMO.

The problem comes once you start doing it over and over again, until you no longer know what the fuck is going on. Functional equivalent of AbstractBeanEnterpriseFactoryMakerInterface or whatever that Java thing was.

blakeyrat

@cartman82 Yeah but JavaScript uses objects for that, which you nicely point out in your second code example.

Which raises a second question: if you want to be using code-wank functional bullshit instead of JavaScript, why are you writing JavaScript?

I mean this is the same people who use a set of 462 #defines to make C look like PASCAL. What the fuck's the point? Just write in PASCAL.

Oh let me guess the answer: it's because your code-wank functional language is some broken bullshit with a non-existent library that supports nothing and nothing supports.

blakeyrat

@cartman82 Since this is all open source-y, why don't you put in a PR to replace their over-complicated bullshit with a simple integer comparison? Report back how successful you are at it.

bb36e

@blakeyrat if you've figured out how to get Pascal running in the browser, you're more than welcome to share your findings

blakeyrat

@bb36e Gee, it's almost like I just made that point.

bb36e

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

@bb36e Gee, it's almost like I just made that point.

almost, but not quite.

cartman82

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

@cartman82 Yeah but JavaScript uses objects for that, which you nicely point out in your second code example.

Actually, the second example was supposed to be my rusty C#.

Which raises a second question: if you want to be using code-wank functional bullshit instead of JavaScript, why are you writing JavaScript?

Javascript supports the functional style just fine.

The overhead is similar or less than with object. Also, since JS has no interface, sharing that object from the second example would be pain in the ass.

As I said, the problem is overdoing it. The same as with OOP.

cartman82

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

Secondly, you're one of the few open source fans who'll actually admit that there are things open source isn't good at.

I wouldn't call myself a fan of anything. I love and hate all technologies equally.

groo

@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"

The opensourcey alternative is release never. see flarum for an example of that.

Adynathos

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

no way of telling which at design-time?

Usually the languages which have currying also have a type system to check / let you know if the returned thing was a function or value. But in JS one will probably enjoy the fun of adding a function to a number.

@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

You talk about open-source as if it was a hivemind organization and you are disappointed by the hivemind's poor decisions and lack of discipline. We should instead see it as a large-scale process, like evolution, not like a human making decisions.

There is a lot of software released - and "evolutionally" some of it is widely used, some is forgotten.
The key popularity factor is easy of access not quality:
JS is very accessible - it already runs in browser - so despite being a terrible language it gained huge popularity
PHP/Wordpress is also very ugly - but it is easy for users, therefore its used on a high % of sites.
And popularity creates more popularity in a feedback loop.

The high quality software may be harder to learn or has less frequent releases and adds fewer shiny features, therefore attracts fewer people and we never hear about it.

This phenomenon is a consequence of basic human nature, its like water flowing through the easiest path.
We would prefer things to be different, but can not change the fundamental laws.
The best we could do it to try to take advantage of knowing them.

cartman82

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

@cartman82 Since this is all open source-y, why don't you put in a PR to replace their over-complicated bullshit with a simple integer comparison? Report back how successful you are at it.

The whole "library" is like 3 pages of javascript, wrapping a different, much better http library.

I was sorely tempted to just excise it from my code and use the decent lib they wrap. Unfortunately, the react framework I use sort of relies on this pile of shit.

I might yet do that, I'm just reluctant to stray too far from the beaten path in my first react native project.

flabdablet

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

despite being a terrible language

To be fair, it's less terrible than Visual BASIC.

Jaloopa

@flabdablet vb.net is a fine language

accalia

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

@cartman82 Yeah but JavaScript uses objects for that, which you nicely point out in your second code example.

yeah, no. not really.

for one thing @cartman82's second example isn't valid javascript. it appears to be valid C#

for another thing the this reference is very weakly bound in javascript

var a = {
    b: function(){}
},
b = a.b,
c = {};

a.b(); // the value of `this` in function b will be `a`
b(); // the value of `this` in function b with be `global` (nodejs) or `window` (browsers)
a.b.apply(c, []); // the value of `this` in function b will be `c`
(function() {
    "use strict";
    b(); // the value of `this` in function b with be `undefined` (strict mode)
})(); // pay no attention to this. it's just a self executing fucntion to trigger strict mode

DCoder

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

Usually the languages which have currying also have a type system to check / let you know if the returned thing was a function or value. But in JS one will probably enjoy the fun of adding a function to a number.

One possible solution would be to use TypeScript (or Flow). TypeScript type definitions are available for Ramda and most other popular libraries, and the time savings from catching stupid mistakes early and having IntelliSense that actually works are absolutely worth it.

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

b(); // the value of `this` in function b with be `global` (nodejs) or `window` (browsers)

It can also be undefined if "use strict" is in effect.

ES6 arrow functions are often helpful to tame this, but they won't work here.

accalia

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

It can also be undefined if "use strict" is in effect.

ah. forgot a case.... uno momento. i will update.

accalia

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

ES6 arrow functions are often helpful to tame this, but they won't work here.

in general yes, but only because arrow functions "leave the existing value of this unchanged.

they're not a panacea....

Adynathos

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

One possible solution would be to use TypeScript (or Flow)

I will try web programming again when WebAssembly gets compilers for C++ / JVM / Python :)

dkf

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

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

In this case, it looks like they really mean that they stick some kind of unspeakable secret sauce on it and stew for an hour.

dkf

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

Two ways to do the same thing.

The second one at least allows rebinding the target directory, which classical curried functions don't. Trivial to fix though. Just needs moar coad…

aapis

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

There are obvious advantages to its small modules ethos.

I really can't agree. This post shows quite well how a "small module ethos" works in practice. There are whole piles of software entirely written by other people, yet those who create the JSON configuration files that glue those modules together get to call themselves developers, engineers even? This is exactly why I am an NPM hater. I understand, fundamentally, NIH-syndrome because it makes sense. Programmers want to write code, even if that means reinventing the wheel for no reason other than "because I can". This approach is the exact opposite of NIH, nothing can ever be invented here because someone, somewhere, already wrote that code. It is development for people who either hate or don't want to understand programming.

Maciejasjmj

@aapis You're right for the wrong reasons. It's not about rewriting the code - no, I don't want to write that isBetween function into my code, I'd rather have someone else provide it for me.

The problem is that unlike in, say, .NET - where most of this stuff is in one framework - you have to deal with a gajillion completely separate, independently developed modules written by hundreds of people. And that means a gajillion points of failure.

If it suddenly turns out .NET-provided inBetween function breaks your shit, you have Microsoft to blame, and they'll generally respond post-haste. And even if they don't, at least you know who to ask.

If isBetween breaks in Node, you need to find whoever wrote that module, file an issue, have it moved upstream because it's actually a problem in isGreaterThan v0.3.2 developed by someone completely different, try to update isGreaterThan to a newer version only to find out that breaks isLessThan, ask the developer of isLessThan to make his shit work with the new isGreaterThan, receive an autoresponder message that the developer of isLessThan has put his life as a programmer behind him and now lives with bears on Kamchatka, and eventually copy a ten-line eval from StackOverflow that monkey-patches isBetween to work.

antiquarian

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

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

I'm one of the biggest functional programming advocates here, and even I wouldn't use curried functions for that.

On the other hand, I've used Haskell where all functions are curried all the time. But trying to monkeypatch them into another programming language that doesn't have them is just a .

pydsigner

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

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

It's not just that JS is dynamically typed. You can do dynamic typing right. But with JS, it's more like types aren't even a thing. You can add anything to anything and get a result of some sort, where as proper dynamic languages have (runtime) type errors.

JS:

> {} + []
0
> [] + {}
"[object Object]"
> {} + {}
NaN
> [] + []
""
> 1 * 2
2
> "5" * 4
20
> 5 + []
"5"
> {} + [4]
4

In Lua you pretty much just get errors or arithmetic errors although the string times number does return a number. Python you'll either get a TypeErroror, if you're adding two lists, the concatenated lists. The string/number mult gives you a repeated string.

TL;DR JS isn't even good at what it tries to be.

masonwheeler

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

> {} + []
0
> [] + {}
"[object Object]"
> {} + {}
NaN
> [] + []
""
> 1 * 2
2
> "5" * 4
20
> 5 + []
"5"
> {} + [4]
4

Wat

accalia

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

@pydsigner said in I'm getting tired of this npm shit:
> {} + []
0
> [] + {}
"[object Object]"
> {} + {}
NaN
> [] + []
""
> 1 * 2
2
> "5" * 4
20
> 5 + []
"5"
> {} + [4]
4
Wat

yeah. the type cohersion in javascript is a crock of shite.

Rhywden

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

@masonwheeler said in I'm getting tired of this npm shit:
@pydsigner said in I'm getting tired of this npm shit:
> {} + []
0
> [] + {}
"[object Object]"
> {} + {}
NaN
> [] + []
""
> 1 * 2
2
> "5" * 4
20
> 5 + []
"5"
> {} + [4]
4
Wat
yeah. the type cohersion in javascript is a crock of shite.

It's like they threw darts at a list of return values for random combinations of operands.

TimeBandit

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

It's like they threw darts at a list of return values for random combinations of operands while blindfolded.

FTFY

accalia

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

@accalia said in I'm getting tired of this npm shit:
@masonwheeler said in I'm getting tired of this npm shit:
@pydsigner said in I'm getting tired of this npm shit:
> {} + []
0
> [] + {}
"[object Object]"
> {} + {}
NaN
> [] + []
""
> 1 * 2
2
> "5" * 4
20
> 5 + []
"5"
> {} + [4]
4
Wat
yeah. the type cohersion in javascript is a crock of shite.
It's like they threw darts at a list of return values for random combinations of operands.

eeeh. actually when you understand the rules for type coersion you understand why those come out the way they do.....

it's just they didn't think about those rules too much..... or even ask if they were a good idea

/me wished that 'use strict' mode actually disabled type cohersion too

blakeyrat

@pydsigner I'd prefer no error and some weird result to an error at runtime. Personally.

TimeBandit

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

@pydsigner I'd prefer no error and some weird result to an error at runtime. Personally.

At least, that explains why you think Visual Basic wasn't that bad.

masonwheeler

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

@pydsigner I'd prefer no error and some weird result to an error at runtime. Personally.

This is an odd position to take. The point of errors at runtime (particularly with an exception mechanism that unwinds the stack) is that if you have "some weird result", execution will continue with bad data, and most likely continue to corrupt things further, making the problems worse and their eventual detection further away from the point where things went wrong. A runtime error makes everything better (where 'everything' is defined narrowly as 'those two points, which are very important'.)

blakeyrat

@masonwheeler Perhaps; but the person who sees the error won't be able to understand why it's happening or how to fix it. They're just fucked. Even if you have comprehensive error handling, the best think you can show them is a conciliatory message that sums up to "we don't know what you did wrong if anything, nor how to fix it, you're just fucked".

Users deserve more respect than that.

masonwheeler

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

@masonwheeler Perhaps; but the person who sees the error won't be able to understand why it's happening or how to fix it. They're just fucked. Even if you have comprehensive error handling, the best think you can show them is a conciliatory message that sums up to "we don't know what you did wrong if anything, nor how to fix it, you're just fucked".

Users deserve more respect than that.

Something's gone wrong. It wasn't you, it was an error on our end. Please send this message to errors@myproject.com; it will help us track down the problem and fix it.
<stack trace here>
<technical data here>

dkf

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

Users deserve more respect than that.

Yes, but wedging the program even further into a bad state doesn't help with that crucial objective of showing respect to the users. The program shouldn't be letting the errors propagate that far at all, but also shouldn't end up stumbling along making ever bigger errors simply because something trivial went wrong a few minutes earlier.

TimeBandit

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

Users deserve more respect than that.

Like this ?
0_1471380147095_upload-bdf084b2-e5d6-4a76-8b2c-70f880a9e0d9

blakeyrat

@masonwheeler Whatever. Look, as always I regret saying anything on this forum because now the jackals will all pop into this thread and tell me how stupid and wrong-headed I am.

Never mind.

pydsigner

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

@masonwheeler Perhaps; but the person who sees the error won't be able to understand why it's happening or how to fix it. They're just fucked. Even if you have comprehensive error handling, the best think you can show them is a conciliatory message that sums up to "we don't know what you did wrong if anything, nor how to fix it, you're just fucked".

Users deserve more respect than that.

There's two possible failure modes at this level I think. Either there's "welp that didn't work but the user doesn't care" or "uh oh this is going to cause issues". Comprehensive error handling will hide the former and let the user know about the latter; I'd much rather know that my data just got shredded somehow before I try to use it in 5 minutes or 5 months. If you think users just want to never know when things go wrong, then you're .

FrostCat

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

now the jackals will all pop into this thread and tell me how stupid [...] I am.

You're the only jackal of that type here, bro.

bb36e

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

@masonwheeler Whatever. Look, as always I regret saying anything on this forum because now the jackals will all pop into this thread and tell me how stupid and wrong-headed I am.

Never mind.

Well, how else are you supposed to find out?

error

This post is deleted!

cvi

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

@aapis You're right for the wrong reasons. It's not about rewriting the code - no, I don't want to write that isBetween function into my code, I'd rather have someone else provide it for me.

There's another point to this, though, at least IMO. Namely, what's the threshold to just write the damn thing anyway. The example isBetween() is a one-liner, there's no reason for it to be a dependency, just type the damn thing out (granted, in the OP, it probably was a part of a larger library).

The effort of even finding the package that exports something like that is way higher than just writing the thing. And it doesn't contribute a whole lot to clarity (and especially not in the demonstrated form). IME standard libraries tend to not define useless cruft like that in their public API either.

(I get that you probably used isBetween() as an example, but still, there have been threads around here that have examples of packages that are of the same complexity as isBetween().)

groo

@Jaloopa even gw basic was superior to JavaScript

sloosecannon

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

@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"

The opensourcey alternative is release never. see flarum for an example of that.

Well, Flarum isn't feature-complete, so it's a good thing they haven't released yet...

blakeyrat

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

The opensourcey alternative is release never. see flarum for an example of that.

Good.

If the product is shitty, I'd rather see it never released.

Adynathos

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

Flarum isn't feature-complete, so it's a good thing they haven't released yet...

Whatever they say about its readiness, Flarum still seems the best currently existing forum software - because the competition is weak.

Hiding behind "unreleased" status is taken to the extreme in Steam's Early-Access, where the games are sold for money but if they are criticized, they have the excuse that it is unfinished and will be completely different later.
I learned to ignore this status - good games sometimes have the early access flag switched on, and lack of early access does not mean its good.

svieira

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

For us noobs who don't regularly work with JS, what is the advantage over simply writing
var ramda = require(ramdajs);

It's statically analyzable (no dynamic requires means you can do a quick first-pass to find all the dependencies) and it produces bindings rather than normal variables, which makes it less painful to do circular dependencies.

(Yes Virigina, there is still a way to do dynamic imports).

cartman82

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

If it suddenly turns out .NET-provided inBetween function breaks your shit, you have Microsoft to blame, and they'll generally respond post-haste. And even if they don't, at least you know who to ask.

If isBetween breaks in Node, you need to find whoever wrote that module, file an issue, have it moved upstream because it's actually a problem in isGreaterThan v0.3.2 developed by someone completely different, try to update isGreaterThan to a newer version only to find out that breaks isLessThan, ask the developer of isLessThan to make his shit work with the new isGreaterThan, receive an autoresponder message that the developer of isLessThan has put his life as a programmer behind him and now lives with bears on Kamchatka, and eventually copy a ten-line eval from StackOverflow that monkey-patches isBetween to work.

Actually, in both cases, you'll probably just roll out your own.

If you couldn't, in node's case, you could at least submit a pull request to fix it. Or fork the module and fix it yourself. Or replace it with a different module.

You don't have such option with MS. In the old NET 4.x days, you could complain and blame all you wanted, but that wasn't going to fix your problem. You'd have to wait for months and months for some kind of patch release to ship. And then update 100-s of deploys, etc.

There's a reason even MS is abandoning their old model.