Hacker News Reader

The difference between JS and C++ is that C++ is addressing a complex problem domain whereas JS is addressing a simple one. So JS can put its complexity budget towards features that improve productivity whereas such features in C++ require huge amounts of complexity. Take for instance anonymous functions in JS compared with lambdas since C++11, the C++ version needs a complicated capture syntax, capability for capture by value and reference, type inference, templating, and more. All that complexity is useful and needs to be there (I have used most of it in my own code) - in JS anonymous functions are immensely simpler. That's why JS will never become even 1/2 as complex as C++.

Weird that this is downvoted. It's a perfectly plausible point, clearly stated.

> C++ version needs a complicated capture syntax

C++ doesn't actually need it. Rust proved that capture everything by reference or capture everything by move is enough for all practical use cases.

C++ lambdas is another example where C++ committee chose complex uber-universal solution instead of much simpler which solves 99% use cases.

That's wrong.

C++ object lifetime management is much more tricky and error prone than the Rust one.

Passing an object by reference to lambda by default can be a beautiful source of out of scope and default.

The committee did an excellent job by allowing explicit filtering.

> C++ doesn't actually need it. Rust proved that capture everything by reference or capture everything by move is enough for all practical use cases.

That's kinda true but kinda not: precise "capture clauses" is a common design pattern in rust[0] showing that the flexibility is extremely useful, and I think I've seen rumblings about adding them to the language.

I mean technically you only ever need `move` closure, "ref" closures are already a convenience.

[0] http://smallcultfollowing.com/babysteps/blog/2018/04/24/rust...

> One thing that I am a bit afraid about though is that the language might become more complex and complicated over time because of backward compatibility (C++-like?).

New methods with simple behaviour don't really make the language more complex through.

> And that's great, but that's a new function, and maybe 'replace(...)' should have had this behavior from the start.

As you note it kinda does, just in a weird roundabout manner.

One issue with javascript is also that it makes extending existing functions difficult, because extra arguments are just ignored by default, so you can't just add a `count=1` parameter to String.replace to override the regex flag as there could be code out there which already passes a third (currently ignored) parameter and would break.

> New methods with simple behaviour don't really make the language more complex through.

I think they do, in some ways. If you have multiple methods or functions which seem to do similar things, as a new-comer it can be incredibly confusing. I remember when I started I never knew what the "best way" to iterate on things was... for loops? for in? for of? foreach? And it was not obvious which one to use or what were the differences. I agree that it might be less ambiguous between "replace" and "replaceAll", but I think over time these things matter.

> I remember when I started I never knew what the "best way" to iterate on things was... for loops? for in? for of? foreach? And it was not obvious which one to use or what were the differences.

Possibly aside from the latter (assuming you mean Array#forEach), these are not different "methods with simple behaviour", they're different language constructs with largely overlapping behaviour & use cases.

Sorry if I expressed myself poorly but that is exactly the point I wanted to make. To maintain backward compatibility, new constructs with partial overlap with existing ones are introduced; and this overall increases the complexity of the language. Whereas breaking backward compatibility would allow to re-use existing constructs and change their semantics (I am not saying this would be a better path though).

For example there are 3 String methods to take a substring (substring, substr, slice) (there's even 4th way in proposal: https://github.com/tc39/proposal-slice-notation)

The last added one is slice, and actually simplifies things, with its consistency with Array.prototype.slice, and replace the old ones

I agree it's annoying to keep old methods for backward-comptibility

The biggest complexity comes with interactions between features.

For example, "move semantics" in C++ -- while useful -- trigger tons of questions about interactions with other features.

Duplicate features (for-of/forEach) are a problem, but a lesser one.

---

FWIW,

* Array.prototype.forEach iterates over an array

* for-of iterates over an iterable, including arrays

* for-in iterates over object keys (strings)

To your point, for-of is the more general form of forEach, so IMO there isn't much reason to use it now.

Learning about many simple features has a cost, but I much prefer that to inherently complex things that I'll always be confused by.

Ruby excels at this. There are 5 ways to do everything, but they're all simple and readable.

Honestly if I hadnt gotten into Python and learned some amazing ways to write code I would of never have been as productive with JavaScript as I have been all these years. It was painful at first but over time I have learned the quirks.

Any of the best practices and which tools to use you'd care to share?