Hacker News Reader

Comment by masklinn | Hacker News Reader

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

View on HN

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

Reply on news.ycombinator.com