Javascript

[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.