5 ms·
> 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 functio
by pythux 7y ago
> 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.
- masklinn 7y ago> 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.
- pythux 7y agoSorry 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).
- 11235813213455 7y agoFor 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 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
- paulddraper 7y agoThe 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.
- BurningFrog 7y agoLearning 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.