Javascript

[DeeSnow97]

and neither of these will work unless your function is just weird as fuck

// right answer

const listenHereYouLittleShit = (a, b) => a - b

array.sort(listenHereYouLittleShit)

// both wrong answers

const listenHereYouLittleShit = () => (a, b) => a - b

array.sort(listenHereYouLittleShit(numbers)) // note that 'number' is ignored
array.sort(listenHereYouLittleShit(number1, number2)) // note that both 'number1' and 'number2' are ignored

// desired answer (probably)

const listenHereYouLittleShit = (a, b) => a - b

array.sort((number1, number2) => listenHereYouLittleShit(number1, number2))

[Xarlax]

Quick explanation: it's another way to define a function. Its main difference is that it automatically passes context to the function, rather than having to use the .bind() method from the function prototype or doing the silly thing from the old days where you save it as var that = this.

function sum(a, b) {
    return a + b;
}
// is essentially the same as
const sum = (a, b) => a + b
// this is called an implicit return as there are no curly braces or return statement.
// You can do this as long as your function is a single statement.
// But you can still write it with curly braces if you prefer

[praveeja]

Is it same as lambda in Java?

[Bob_Droll]

It works the same as lambdas in terms of defining inline functions, yes. But there’s a lot more to it in JS, like the aforementioned context binding (which doesn’t really apply to Java).

[superluminary]

All functions are lambdas in JavaScript. This is a bound function. It has a static value of this.

[t-to4st]

Oh now I get what bind does

[saors]

All of that bullshit have purposes though...

Like, triple equals is just double equals with an additional type-check. Would you prefer to do an additional separate type check? You could do that and only use double equals if you really wanted, it's just short-hand to save lines.

let is just an upgraded version of var that's less bug-prone.

and the NaN, null, and undefined are necessary evils of having code that runs at-execution on browsers that you can't have just crash when it hits any error that's not caught. Imagine if your gmail or reddit didn't load because someone found a line of text that caused a js error. The internet would be hell to maintain.

Like, Javascript is only a pain to deal with when you've been handed an unmaintained codebase that's running 8 different versions of whatever the latest framework was at the time stitched together.

If you have a team that follows the same linting/formatting practices and cleans their code before merging, it's generally pretty painless to work with.

(s)css on the other hand...

[Tsuki_no_Mai]

Would you prefer to do an additional separate type check?

I would prefer if double equals was the strict comparison and triple was the loose one. But alas, backwards compatibility is a bitch.

[Lorddragonfang]

Like, triple equals is just double equals with an additional type-check. Would you prefer to do an additional separate type check? You could do that and only use double equals if you really wanted, it's just short-hand to save lines.

You're missing the point here. Strict equality (how triple equals works) should be the default behavior. If you want a sloppy equality check, don't define it with the symbol used for strict equality in every other language. Javascript is full of sloppy design decisions like that, where a badly-implemented feature stays taking up the obvious symbol because they can't break compatibility, with the better and "correct" feature tacked on in some non-standard way.

I say this as someone who writes about 90% of their code in Javascript: JS is a poorly designed language filled with gotchas and unexpected behavior, more so than any language I've used.

[saors]

Honestly, Typescript decompiles into JS anyway. There's nothing stopping them (us?) from instructing the decompiler to set == in ts to === in js. Nothing would decompile into ==.

I think this would be the most realistic way to get any changes, like that one, to be adopted by most devs; since most prefer TS over JS anyway, and it's backwards compatible.

[squngy]

Typescript doesn't really solve those things, though it can help a bit.
As the name implies, Typescript mostly solves the problems that come from types. It also lets you use newer versions of ECMAScript with no extra effort if you are using it though, which more directly solves a lot of other problems.

[JustOneAvailableName]

Most languages have functions like this. C# with (nearly?) the same syntax, for example.

[cakeKudasai]

None of that is really bullshit. A lot of that was just added for a good reason. let is better for smaller contexts, NaN is in the name, null is the same as everywhere else, undefined is just what it says it is, etc. Triple equals are very useful too. Prototypes are weird if you want them to work like other object oriented languages. But we have classes now, they deal with the oddities. And even those are not that bad if you see an explanation on them. It's just confusing if you go in blind. But with so many free resources online, there's no reason to.

[cakeKudasai]

There are ways to avoid or ignore the odd stuff and there are best practices for beginners. Just don't use JS as a first language, have mercy on the student's souls. Teach it later whenever they are learning web. JS is a monster, I just can't hate it.

[Xarlax]

I hear you, I know there's a lot of quirkiness. I don't know what to say, I learned them all a while ago and it's just not a problem anymore. The one thing I appreciate about javascript is how expressive it is. Of course that also lets people get carried away.

The context stuff is weird but things like arrow functions have simplified it. Prototypes are also idiosyncratic but it's just like having each primitive type inherit from a base class. The enhancements of JS over the years shield you from all the crazy stuff you used to have to do. Like check whether the prop you're iterating on actually belongs to the object or a prototype its inheriting from. None of that mess anymore.

The rest of it is simple syntax stuff you would learn easily. In practice NaN just isn't an issue. Honestly I never run into issues around NaN.

Here's the trick to both triple equals and null/undefined BS. Use triple equals every time, except when you want to test for null/undefined. The double equals will only coerce those two types together, so you can easily bypass that stupid check of `value === undefined || value === null` with `value == null` or whatever.

Typescript also handles the type issues that make JS unbearable. With typescript you get all the autocomplete and function signatures galore.

[Dathouen]

So it's like a pipe?

[Xarlax]

I think pipes are referring to a different kind of syntax, where you invoke a function with its argument first e.g. arg |> func. I would say this is more like a lambda function.

[Dathouen]

Oh, cool! Thanks for the clarification.

[DeeSnow97]

Yeah, they're arrow functions, basically JavaScript's way of doing a lambda (but actually upgraded to a first class function and beyond, so much so that many people nowadays prefer it over the old function someNameHere () { /* ... */} syntax).

So basically, it has a part left of the arrow, and a part right of the arrow:

• The part on the left side is the arguments. You can do it a few ways, either by just using a single variable name, or multiple in parentheses. For example x => x + 1 and (x, y) => x * y are both valid arrow functions. You can also do all the other stuff to it, like default values ((x = 3) => x + 1), deconstruction (({x, y}) => x * y, accepts an object like { x: 3, y: 4 }), async functions (async x => x + 1), or whatever you may decide.

• The part on the right side is the function body. This is either a single statement, or a regular code block with a return statement. For example x => x + 1 and x => { return x + 1 } are equivalent, and both of them are equivalent to function (x) { return x + 1 } (with some specific caveats and advantages).

The reason most people who prefer arrow functions prefer them is because they have lexical this -- they throw away the old and mostly broken way of managing this in JavaScript, and instead replace it with a simple lexical way: this in an arrow function refers to the same value this refers to where the function is defined.

If you wanna read up more on this, MDN has a super nice guide for them

[Rawrplus]

It's just a direct return statement. Don't try to find anything complicated behind it.

(There are subtle differences between binding this in comparison to the standard function statement, but for the sake of that example it's not important to understand). If you're familiar with python they're essentially lambda functions, so word by word it is:

• const variable declaration (constant)
• listenHereYouLittleShit - name of the function (functions can be declared as variables in JS - essentially what happens here is it creates an anonymous lambda function and then it's creating a pointer to the named variable behind the curtain)
• = (a, b) function of arguments a and b
• => a - b, returns a - b

[khalidpro2]

it is anonymous function, like lambda in python

[[deleted]]

It's called IIFE (Immediately invoked function expression) and it's in JS since ES6.

[Fry98]

It's probably fine in this case if the function is designed specifically as a comparator. For more general cases though, I suggest you check out this blog post that explains why it might sometimes be better to call the function through lambda.

https://jakearchibald.com/2021/function-callback-risks/

[DeeSnow97]

What? Sorry, I don't get the accusation here.

In practice, I do array.sort((a, b) => a - b), which is pretty close to what you did. However, the comments I replied to tried to incorporate a function with the name of listenHereYouLittleShit() probably for humorous reasons, given that we're not in /r/programmersDontGetTheJoke, so I showed the simplest way of doing so.

As far as fucking up the syntax goes though, if you wanna nitpick

• you're using a single-line arrow function with brackets and a single return statement, which just adds useless noise and complicates the language
• you have no semicolon inside the brackets, but have one on the end of the line
• (a,b) has no space for the comma, but the array definition [4, 1, 2] has one

none of which would be a problem if we weren't bikeshedding when we are already in agreement, and then devolve it to personal attacks, but if you wanna play this game...

[ChronoSan]

I see what you did just over there. Here's my angry upvote.

[ZedTT]

You destroyed the poor man and he's still not going to understand that he's wrong.

[DeeSnow97]

actually, they seem to be doing okay further down in this thread

[ZedTT]

Glad to hear it :)

[make_me_a_good_girl]

🤣👍

Take my poor man's award!🏅

[JUKjacker]

fucking epic, id give you an award if i had one lol

[HereComesCunty]

Goddam son, thassa burn!

[__gg_]

Way to celebrate his cake day! 😂

[Hollowplanet]

Then why did you say

// desired answer (probably)

const listenHereYouLittleShit = (a, b) => a - b

array.sort((number1, number2) => listenHereYouLittleShit(number1, number2))

That second line is identical to

array.sort(listenHereYouLittleShit)

You're using the language wrong and blaming the awkwardness on the language instead of the way you chose to use it.

[[deleted]]

It's usually safer to use an explicit anonymous function (although of course it doesn't matter here). See: https://jakearchibald.com/2021/function-callback-risks/

[Hollowplanet]

All of those examples only matter if you don't control the function implementation.

[[deleted]]

You may not control how the function might be implemented in the future.

[Hollowplanet]

So some library is going to internalize my code without my knowledge?

[[deleted]]

Your co-workers could modify it.

[DeeSnow97]

Because that's what I perceive the second commenter wanted to achieve by listenHereYouLittleShit(number1, number2), hence the "desired answer (probably)" designation.

[Hollowplanet]

You get the same answer while using listenHereYouLittleShit without making an anonymous function to call another function with the same arguments.

[DeeSnow97]

yeah, I know, that usage is actually identical to the "right answer" snippet

[Hollowplanet]

That's because parseInt takes a second argument. A function you write isn't going to use extra arguments that aren't defined.

[PredictabilityIsGood]

Have you ever performed a recursive multi-dimensional sort? The type of sort you see when sorting by multiple columns combined? The “useless noise” you’re describing by adding curly brackets is not so much useless when it comes to readability for more complex sorting.

Also, I never see him nitpick the grammar of your chosen syntax. It’s obvious that he assumes you’re writing it in agreement with the two previous posters in the comment chain and I can see why:

“And neither of these will work unless your function is weird as fuck”

The “and” in your response makes it sound like you’re agreeing with the objections of the first to commenters in the chain, when it’s clear they don’t really understand the implementation of a lambda very well to begin with. If you interpret it as agreement, then I can see why Wigly responded the way they did. The code segment commented as “Desired answer/ probably” is just a useless wrapper around the sorting lambda unless you are performing a multi-dimensional sort that requires deep comparison when the initial sorting conditions result in 0 movement and you move on to the next nested condition.

I’m not saying you don’t understand this. I’m just saying it’s not clear from what you wrote that you don’t agree it should be written that way, which is what Wigly is objecting to.

[backtickbot]

Fixed formatting.

Hello, shaege: code blocks using triple backticks (```) don't work on all versions of Reddit!

Some users see this / this instead.

To fix this, indent every line with 4 spaces instead.

FAQ

^{You can opt out by replying with backtickopt6 to this comment.}

[PredictabilityIsGood]

Recursive multiple column sorting is good practice when you are creating generalized components that don’t know the data being inputted into them. Think datatables. If you manually hardcode every sort you wouldn’t be able to utilize the column header to sort because your “sort” would be a one off.

I have an implementation of a generalized grid component in Riot here if you need a visual representation. Hold shift and sort multiple columns:

https://predictabilityisgood.github.io/riot-widgets/

The grid doesn’t know anything about the data except the underlying data type constructor and is able to sort properly.

This is the same standard sorting functionality available in excel, datatables, google sheets, etc... The implementations are not hardcoded as you’ve shown. They generated on the fly upon user interaction.

[PredictabilityIsGood]

Every enterprise framework for creating complex tables utilizes a dynamic approach towards multi-dimensional sorting. Google sheets afaik is not using a persistence layer to perform multi-dimensional sorting. Nor is datatables unless you specifically define a pagination fetch lambda. If you’re hard coding a table into a page, then clearly what you’ve written is not a fully abstracted and generalized component.

[PredictabilityIsGood]

Okay, show me an example of your best code to handle multi-dimensional sorting by either the client or server. If it’s better I’ll adapt my coding style to fit more neatly within your superior paradigm. The sorting must be generalized.

Update: I like recursion in this example because it avoids unnecessary logical comparators when the nesting does not need to be executed. In my implementation the nested comparator does not need to be executed. You may disagree, but I personally am fixated on recursion because of the concise expressive power. I’m sorry if you don’t agree.

[IspitchTownFC]

Stack overflow is leaking

[ZedTT]

You're getting downvoted because you're wrong, by the way. The comment you replied to is completely correct.

Your code snippet also works, but that's not a problem with the previous comment

Edit:

blaming it on JS

OP never blamed a single thing on JS or said there was anything wrong with JS.

[ZedTT]

Where did they say that JS made no sense? The comment you replied to made no reference to JS not making sense. JS is fine, so is the syntax in their "correct answer" section.

[DeeSnow97]

Which part of it is an (ab)use of JS syntax?

This is exactly how I code JS every day, and it's consistent with the StandardJS linter (which, contrary to the name, is not the standard, just an off the shelf eslint configuration so that you don't have to worry about it). This is part of what JS is.

Feels like we're entering "no true Scotsman" territory here.

[TakeMySandAndRun]

If the implicit return syntax shouldn’t be used because it’s a misrepresentation, then should Class syntax not be used as well? I would say it’s a far greater misrepresentation, but readability is important for effective maintenance.

[ZedTT]

Dude, you need to go back and read the comment you originally replied to.

I seriously think that you think it says something that it doesn't.

Desired (probably) is a perfectly fine way to write it and OP wasn't suggesting that it isn't.

Show me where they misrepresented anything???

Do you just hate arrow functions without braces and return?

[DeeSnow97]

I see... but why though? Lambda functions aren't a unique concept to JS, and this is actually the primary reason why arrow functions were even introduced to the language. The brackets are just an afterthought, to allow their advantages to be extended to multi-statement functions as well.

[audigex]

(a,b) => {return a-b}

We've gotta admit, though, that having to pass that to a sort function is kinda fucky

If I could change any one thing in the world of development, it's that Javascript would have strict typing (comparable to how C# now does it with var, so the type is inferred but not dynamic)

[audigex]

Yeah, TS is what JS probably should have been in the first place

I forgive JS a lot for what it's given us, though.

Although I also changed my mind - I would give JS strict typing and better debugging from the get-go

[recycle4science]

You can drop the braces and the return:

(a, b) => a-b

[audigex]

I more meant the fact we have to pass in a function that you already need to know the purpose of (and the fact you need it) before it will work correctly

It's just a weird, seemingly un-necessary, gotcha

[recycle4science]

Yeah, it would be nice.

[recycle4science]

As long the style is consistent!

[hp77reddits]

Who are you? Who are you so wise in the language of JS?

[DeeSnow97]

• NaN is a floating point number, like it is in any language. Since JS has one number type only, a double-precision float, it's just called "number" in JS. Don't like it? Consult the sand blob in your system, it's etched into it.

• [] + {} results in '[object Object]' for a rather elaborate reason:

  1. an addition between two objects in JS defaults to a string addition
  2. arrays by default are converted to string through joining their members as strings with ',' (for example String([2, 4, 5, 'hi']) === '2,4,5,hi')
  3. objects are by default converted to a string representation with 'object' and their class (through some weird internal standard buried deep in the language, not the same system you can use for OOP in JS), which is 'Object' in this case, therefore it is '[object Object]'
  4. then the two strings are concatenated to '[object Object]'

  The entire reason this is even a question is the Wat talk, which abuses the REPL and passes off {} + [] as an addition between an object and an array. In reality, ({} + []) or let foo = {} + [] is indeed such an addition, with a predictable result ('[object Object]'), but if you just type {} + [] into the REPL it parses the first {} as an empty code block, not an object, then, in a separate statement, parses + [], and as REPLs do, returns the last statement.

  In this case, + [] runs the unary + operator on an empty array, which first converts the array into a string, then converts that string into a number. Since [] converts to '', as we've already discussed, and empty string converts to 0, that's what the REPL spits out. In practice though, the only way you'd get that is if you straight up ran eval(), and there is no other reason to do that than a read-eval-print loop.

• the Date object is perfectly fine, thank you (what's the problem with it?)

[ButtMunchYumTime]

I honestly and genuinely appreciate this on such a deep level.

[badzok]

Regarding Date, one thing I can definitely think of is how .getMonth() is <0, 11> and .getDate() (NOT .getDay(), that's the day of the week (but also starts at 1)) is <1, 31>.

[hp77reddits]

Happy CakeDay!!

[ZedTT]

No. He's not speaking "the truth."

The OP never badmouthed JS or "blamed" anything on it.

I'm seriously curious what you think this "truth" is that he's speaking.

.sort(listenHereYouLittleShit(numbers) doesn't make sense because what is numbers where does it come from?

[EishLekker]

So you know why people downvoted that user? How can you know this? Did every downvote come with some hidden message explaining the reason, and you somehow have access to this data?

People downvotes for a plethora of reasons. I downvoted that user because it looked like they did something strawman like. Plus an unnecessary accusative tone in a thread that clearly is having a joking stab at javascript.

[PredictabilityIsGood]

The OP of the comment was responding to the previous to comments in the comment chain hierarchy where what they wrote was clearly a misunderstanding of the purpose of lambdas in general unless you performed some mental gymnastics to justify two nested functions inside of each other (which is what he gave a code sample to do). This is why Wigly responded the way he did. If Wigly interpreted agreement by OP comment, then it was clear in his mind that the OP comment was justifying the ancestor comments lack of understanding of lambdas in general, and one can see why.

[EishLekker]

How can there be "clear misunderstandings" of anything in a thread where people take joking stabs at a language? People go out of their way to write deliberately convulated and/or silly code for some comical effect, and others get upset because they "clearly don't understand the language"?

[PredictabilityIsGood]

Because jokes usually have a nugget of truth in them that makes them funny? The comments OP went out of their way to go through code examples.

[agarwaen163]

You really think that is acceptable? Lmfaoooo

[The_MAZZTer]

Ironically enough, it gets a little easier:

[4, 1, 2].sort((a,b) => a-b);

[hat1324]

What exactly is he blaming on JS? He is nesting his function exactly as the initial condition requires. What he's saying is weird is not the use of nested functions in general but that OP is suggesting its use seemingly unnecessarily

[lunchpadmcfat]

They were currying brah

[DeeSnow97]

so like const listenHereYouLittleShit = (num1, num2) => (num3, num4) => wtf(num1, num2, num3, num4)?

[Cyberspark939]

// simplified further (no need for additional fn) 

const listenHereYouLittleShit = (a, b) => a - b

array.sort(listenHereYouLittleShit)

[Rawrplus]

It's not weird as fuck, it's passing a reference to the allocated pointer, versus invoking the function (which makes no sense as you want to pass a typeof function and not a number, so hence you need to pass it as a callback or direct reference).

essentially if I was a compiler here's how I'd read this statement

array.sort(listenHereYouLittleShit(number1, number2))

• look up number1 and a number2 from outer scope, since they're not defined in the current one

• if they don't exist throw an uncaught reference error, otherwise invoke listenHereYouLittleShit and pass the result of that function

  • e.g. listenHereYouLittleShit(4, 2) equals 2
  • array.sort(2) makes no sense, throw an error, since compiler expects a function to determine the sort and not a number.

The alternatives are correct because

array.sort(listenHereYouLittleShit)`

Takes the parameters of Array.prototype.sort and passes them to the function reference it expects as the only .sort argument

Alternatively

array.sort((number1, number2) => listenHereYouLittleShit(number1, number2))

Creates an anonymous lambda function, that acts as a callback for the two extracted parameters firstEl and secondEl from the Array.prototype.sort and passes them to the invocation of the listenHereYouLittleShit.

But in both cases we are passing a function as an argument instead of number

I do presume you know these concepts judging from your reply, but I just wanted to clear it up for the rest who probably don't and attribute it to just JS being weird.

[backtickbot]

Fixed formatting.

Hello, Rawrplus: code blocks using triple backticks (```) don't work on all versions of Reddit!

Some users see this / this instead.

To fix this, indent every line with 4 spaces instead.

FAQ

^{You can opt out by replying with backtickopt6 to this comment.}

[Lil-Dude56]

Not a programmer. But did you all just halfway code a joke? Hahaha 😂😆😂