You can kinda get some of.

 
Duryee: Http://www.sitepoint.com/web-scraping-in-node-js/

Timberman: Some languages do call “operators” anything that is symbolic and infix. Some languages use “operators” for special things. I’m not really sure if there’s a consistent definition in literature for this one.

Surano: Is that a good source?

Straight: Django_: #node.js may be helpful too

Clausi: Dekok: My problem is that it’s “okay” for different objects to have a “doSomething” function. but it wouldn’t be okay to objects to define their own operators.

Omo: Rcyr: how so? It’s totally okay in some languages

Benge: Mermaid, Smalltalk, Dart.

Presha: Why it isn’t okay in C# and C++?

Knoche: Would wouldn’t it be okay with. jS?

Lionello: Because those languages decided that symbolic thingies would be special

Melancon: C++ has operator overloading, though, which is kiiiinda similar, in practice

Liesmann: Rcyr, there was some discussion about overloding === in js

Gelsinger: Rcyr: in those languages, it is. It’s defined in the language, not in the user code.

Herrington: Does javascript have a library for getting the line of code being excuted?

Evitts: I don’t know if someone managed to actually discuss in into the standard

Straight: Rcyr: “ok” is as defined by the language. it’s not OK in JS because it’s not possible.

Louissaint: Hannibal_Smith: I think that would be strange :/

Zam: Fprophet: why do you want that?

Birckbichler: Is it reliable to use npm install request to make http requests

Straight: Rcyr: personally tho i don’t like operator overloading – it makes code harder to reason about, because it’s just magic sugar for what should be an explicit function call.

Fleurilus: Dekok: debugging. I want a utility cl*** that will spit useful information out with line number and such

Hirota: Like, the line number that it was called at

Driggars: Brendan did suggest adding multimethods to the language, which would let you add new dispatches to existing operators without getting into the asymmetric problem i.e.: “a + b” being entirely different from “b + a”

Vilkoski: Straight: I have a hard time understanding why + is more difficult to reason about that .add

Straight: Rcyr: when + can do anything arbitrary, how do you grep to find the definition?

Garnache: Fprophet: just put debugger in that line, and then open your debugger, and you’ll be able to step through the code and all the things

Straight: Rcyr: whereas add is easily greppable.

Dellapenta: Actually that wouldnt really be helpful unless it could also tell what page that line is in

Romag: Dekok, did the propogat get some interest?

Brenaman: Straight: Yes. but it has the same issue as +. you might have multiple libs using .add

Rad: Hannibal_Smith: unsure. I stopped following es-discuss, and Brendan said that a few years ago.

Straight: Rcyr: yes, that’s true. which is why descriptive function names matter too.

Morva: Straight: ideally, a language would allow you to search for “types.” Which is not possible in JS, sadly

Rudack: Straight: I just see + as being an handicaped version of a “add” version

Straight: Rcyr: it is. and that’s why it’s good.

Straight: Rcyr: constraints make things easier to reason about. + is less powerful, and thus more reliable and predictable and understandable.

Brilowski: Straight: It’s not, I should be able to do myArray.reduce+, 0;

Warens: So, you could have _ : Number + _, and it would give you all of the lines that use + where the left operand is a number.

Giasson: But again, requires types

Straight: Rcyr: treating the operator as a function isn’t what we’re talking about – fwiw i proposed that a year ago and was shot down.

Schwentker: You can kinda get some of that with type inference. But it fails for HOFs/collections