4 ms·

Really liking these new developments! JavaScript is not the horrible language it used to be anymore (in my very subjective opinion). When I started writing Java

• masklinn 7y ago
  > 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.
  • 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 ago
        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).
        • 11235813213455 7y ago
          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 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 ago
      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.
    • BurningFrog 7y ago
• mantap 7y ago
  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++.
  • minimuffins 7y ago
    Weird that this is downvoted. It's a perfectly plausible point, clearly stated.
  • lightgreen 7y ago
    > 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.
    • adev_ 7y ago
      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.
    • masklinn 7y ago
      > 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-pattern-precise-closure-capture-clauses/ http://smallcultfollowing.com/babysteps/blog/2018/04/24/rust...
• giancarlostoro 7y ago
  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.
• Bishonen88 7y ago
  Any of the best practices and which tools to use you'd care to share?