Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> A programming language where almost everything is mutable is not good.

That's a weird criticism. Object-oriented programmers are premised on mutation. As for JavaScript itself, mutations can be avoided. 'const' to prevent reassignment, using Object.freeze, or just applying functional programming principles and keeping functions pure.



> Object-oriented programmers are premised on mutation

I'm a Java OOP developer, and I make everything I can immutable. It's a design decision adopted by most of my colleagues.


Good point. The same practices are common in JS. Arguably, point free style, currying, functional composition, etc... are easier to achieve in JS (esp. with types). I do enjoy writing java in somewhat functional way, and have seen badly written OOP Scala (mostly by developers, who just started experimenting with FP), and I think it’s difficult to discuss a language without the broader context of its common practices/developer culture/discourse around it.


Immutable objects are not common in JS. You can conceptually treat them as immutable, but they are mutable, because their base type is mutable and by extension everything is mutable.


At least there is Immutable.js


Whoops. I meant OO languages, not OO programmers.


1) Many languages won't allow you to redefine a type.

2) Mutate the prototype of a "frozen" object and you would indirectly affect it through its prototype chain... or mutate an nested property inside a "frozen" object.

Most of JS standard library and most popular frameworks and libraries have fully mutable definitions. That sucks and is BAD design decision.


> Many languages won't allow you to redefine a type.

This counterargument is not a good one. Just because other languages do things a certain way doesn't mean it's the right way in every situation. C++ has multiple inheritances and template metaprogramming, but that's C++.

> Most of JS standard library and most popular frameworks and libraries have fully mutable definitions. That sucks and is BAD design decision.

It's subjective whether this is a bad design decision. For the standard library, this enables polyfills. As for the popular libraries / frameworks, they have the option of freezing the prototype. They don't do this because they make the fair assumption that the client is not mutating the library state. It's the programmer's fault for breaking the interface contract and mutating the implementation. At any rate, this would be a criticism of the ecosystem, rather than language. If the criticism is about untrusted third party code, it's not an apples-to-apples comparison between JavaScript and other languages that are operating in different environments.


1) Template meta-programming is vastly safer than preprocessor macros. Then, today you have constant expressions, which overlap with some of the use-cases of template meta-programming. In any case, template meta-programming is not strictly required to get things done in C++. Multiple inheritance can be caught by static analysis.

2) Just like you can polyfill your code, malicious input can poison your prototypes.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: