4 ms·

JavaScript is very expressive and powerful language. Maybe hard to learn. The prototypal inheritence and 'this' were confusing to me and took much time to under

by smlckz 6y ago

JavaScript is very expressive and powerful language. Maybe hard to learn. The prototypal inheritence and 'this' were confusing to me and took much time to understand those. Then I learnt that prototypal inheritance is a superset of ''class''ical inheritance [1] as well as this [2]. Hmm. With Reflect, Proxy etc. you have great metaprogramming capabilities that make this language much powerful. Still, there are some (many?) edge/corner cases and unfixable bugs (aka features) that the language is stuck with for the sake of backwards compatibility and developers have to learn these. (The most famous of these might be typeof null === "object") When I look at the amount of features added to the language specification, sometimes it seems like it is going to become another incarnation of the C++ specification. I still like its expressiveness and power, but if it becomes another C++ in future, I have to look somewhere else. (TypeScript maybe.) [1]: https://aaditmshah.github.io/why-prototypal-inheritance-matters/ https://aaditmshah.github.io/why-prototypal-inheritance-matt... [2]: https://wiki.c2.com/?ClosuresAndObjectsAreEquivalent https://wiki.c2.com/?ClosuresAndObjectsAreEquivalent and https://www.crockford.com/javascript/private.html https://www.crockford.com/javascript/private.html

kazinator 6y ago
I'm convinced that prototype object systems represent a poor set of requirements. Those requirements are chosen because they lead to ease of implementation: prototype objects are the quickest and dirtiest way to enhance an interpreter such that programs can be written in it that are discernibly OOP-ish. They don't represent a set of requirements that amount to a good OOP system.
- smlckz 6y ago
  Read the accepted answer to this question: https://stackoverflow.com/questions/2800964/benefits-of-prototypal-inheritance-over-classical https://stackoverflow.com/questions/2800964/benefits-of-prot...
  - searchableguy 6y ago
    > @s̮̦̩e̝͓c̮͔̞ṛ̖̖e̬̣̦t̸͉̥̳̼ It's been a while since I wrote this answer. My views have changed since I wrote it. Now, I believe that inheritance, both classical and prototypal, are bad and should be avoided at all costs. There's never a good reason to use inheritance. If you're writing object-oriented code then you should always prefer composition over inheritance. Even better, don't write object-oriented code. Embrace functional programming. Author finally opened his eyes.
    - antigirl 6y ago
      How would you write a component based architecture like React has? New API has moved away from the classical syntax where it would ‘extend’ React component but I assumed it was still doing prototypal inheritance. Isn’t it better for memory to have some sort of inheritance?
      - mantap 6y ago
        Honestly these things are all variations on a theme in JavaScript. The language is flexible enough that you can write code in many different ways and they all end up being equivalently powerful. In JavaScript you have precise control over inheritance, you can specify your own algorithm for how class A inherits from classes B and C. It's a totally different beast to classical inheritance in Java that has such a bad reputation because it's such a straightjacket
        gridlockd 6y ago
        The problem is that people don't realize how much of an anti-feature this sort of flexibility is. > In JavaScript you have precise control over inheritance, you can specify your own algorithm for how class A inherits from classes B and C. Yeah maybe, but please don't do that.
        mantap 6y ago
        If you find that shocking you would probably drop dead at seeing what Lisp programmers get up to with macros :) Language flexibility doesn't obscure the readability of code. It enhances it. In a flexible language, unclear code is always programmer error, and programmer error is fixable. In an inflexible language, a lack of clarity can sometimes be unavoidable (e.g. java programmers forced to shoehorn everything into classes)
  - deleted 6y ago
    [deleted]
  - kazinator 6y ago
    1. It's simple. Yes, to hack up, so what? Non-prototype object systems can also be written simply and in a small footprint, and have a reasonably small description. A prototype object system is barely one step above pretending that a hash table is an object. 2. It's powerful. It's not expressive of OOP concepts and creates spaghetti code. All OOP is monkey patching: make this object like that one, but patch this. 3. It leads to smaller, less redundant code. Because you're not properly specifying classes, which serve as an important guide to the structure of your program, and provide a locus of control. We can achieve smaller and less redundant code by identifying every function that is only called once and manually inlining it, so there is no name that is redundantly mentioned two places in the program. That doesn't mean it's a good idea. 4. It's dynamic and hence it's better for dynamic languages. This point is subtly fallacious. Dynamic languages also have non-prototype based object systems, which are also dynamic and good for those languages. There is good dynamic and there is bad dynamic. Under prototype object, it's hard to do certain important dynamic things like redefine the method of a class such that all objects of that class (existing instances) use the new method. Non-prototype objects systems in dynamic languages can easily support prototype-like mechanisms without those being the main mechanism of organization of OOP programs. Failing that, in any dynamic language that gives you hash tables, you can ignore the fine OOP system and do prototypes with hashes.
- IshKebab 6y ago
  They're most obviously a bad design because now any part of the code in your entire program can change the behaviour of any other bit of code. It means you can't understand code in isolation.

by smlckz 6y ago

kazinator 6y ago

I'm convinced that prototype object systems represent a poor set of requirements. Those requirements are chosen because they lead to ease of implementation: prototype objects are the quickest and dirtiest way to enhance an interpreter such that programs can be written in it that are discernibly OOP-ish. They don't represent a set of requirements that amount to a good OOP system.

smlckz 6y ago
Read the accepted answer to this question: https://stackoverflow.com/questions/2800964/benefits-of-prototypal-inheritance-over-classical https://stackoverflow.com/questions/2800964/benefits-of-prot...
- searchableguy 6y ago
  > @s̮̦̩e̝͓c̮͔̞ṛ̖̖e̬̣̦t̸͉̥̳̼ It's been a while since I wrote this answer. My views have changed since I wrote it. Now, I believe that inheritance, both classical and prototypal, are bad and should be avoided at all costs. There's never a good reason to use inheritance. If you're writing object-oriented code then you should always prefer composition over inheritance. Even better, don't write object-oriented code. Embrace functional programming. Author finally opened his eyes.
  - antigirl 6y ago
    How would you write a component based architecture like React has? New API has moved away from the classical syntax where it would ‘extend’ React component but I assumed it was still doing prototypal inheritance. Isn’t it better for memory to have some sort of inheritance?
    - mantap 6y ago
      Honestly these things are all variations on a theme in JavaScript. The language is flexible enough that you can write code in many different ways and they all end up being equivalently powerful. In JavaScript you have precise control over inheritance, you can specify your own algorithm for how class A inherits from classes B and C. It's a totally different beast to classical inheritance in Java that has such a bad reputation because it's such a straightjacket
      - gridlockd 6y ago
        The problem is that people don't realize how much of an anti-feature this sort of flexibility is. > In JavaScript you have precise control over inheritance, you can specify your own algorithm for how class A inherits from classes B and C. Yeah maybe, but please don't do that.
        mantap 6y ago
        If you find that shocking you would probably drop dead at seeing what Lisp programmers get up to with macros :) Language flexibility doesn't obscure the readability of code. It enhances it. In a flexible language, unclear code is always programmer error, and programmer error is fixable. In an inflexible language, a lack of clarity can sometimes be unavoidable (e.g. java programmers forced to shoehorn everything into classes)
- deleted 6y ago
  [deleted]
- kazinator 6y ago
  1. It's simple. Yes, to hack up, so what? Non-prototype object systems can also be written simply and in a small footprint, and have a reasonably small description. A prototype object system is barely one step above pretending that a hash table is an object. 2. It's powerful. It's not expressive of OOP concepts and creates spaghetti code. All OOP is monkey patching: make this object like that one, but patch this. 3. It leads to smaller, less redundant code. Because you're not properly specifying classes, which serve as an important guide to the structure of your program, and provide a locus of control. We can achieve smaller and less redundant code by identifying every function that is only called once and manually inlining it, so there is no name that is redundantly mentioned two places in the program. That doesn't mean it's a good idea. 4. It's dynamic and hence it's better for dynamic languages. This point is subtly fallacious. Dynamic languages also have non-prototype based object systems, which are also dynamic and good for those languages. There is good dynamic and there is bad dynamic. Under prototype object, it's hard to do certain important dynamic things like redefine the method of a class such that all objects of that class (existing instances) use the new method. Non-prototype objects systems in dynamic languages can easily support prototype-like mechanisms without those being the main mechanism of organization of OOP programs. Failing that, in any dynamic language that gives you hash tables, you can ignore the fine OOP system and do prototypes with hashes.
IshKebab 6y ago
They're most obviously a bad design because now any part of the code in your entire program can change the behaviour of any other bit of code. It means you can't understand code in isolation.