obfuscating mathematical and computational concepts while making them no less hard
It seems to me that what makes some programming tools better than other is that they hide mathematical and computational complexity while making solving problems easier - nothing is going to make the computationally hard or intractable not hard or intractable.
Attempts to hide computational and mathematical complexity is pretty much the theme for a whole history of programming languages. It certainly is its genesis story -
at which point the history of debates over programming languages begins, and it seems to me that this debate is largely because what I call 'hiding computational and mathematical complexity' you are free to say obfuscates it. It's how we get the yin and yang of C and Scheme making 70's scene - malloc and and full lexical scoping both simplify someone's life and make someone's unbearable.
I always know that there's a bad OOP example when automobiles are involved. It means it's a marketing piece not a tutorial - managers have cars and as a lowest common denominator of technical knowledge know they have four wheels, provided we ignore the one in the trunk. In other words, we've already lost because the person writing the explanation doesn't know the difference between hiding complexity and obfuscating it [How many cylinders in a Mazda Rx-8? Where does the Leaf fit in?].
On the flip side, what can we expect? Math is hard for a lot of people because it builds sequentially. Teenage hormonal distractions have probably prevented more people from moving beyond ciphering to algebra and beyond than anything save for access to educational resources.
FactoryProviderProviderProviders in the form of frameworks don't necessarily require understanding of higher order functions - like garbage collection, some lazy programmer wrote a program to handle it, and this turns out to be useful because people can use it without really understanding what it is, and being able to use things which are not computationally understood is pretty much the driving force behind the rise of OOP - how many people talk about dispatch when discussing an object's methods?
OOP is a sexier Cobol - cars and their wheels makes for more interesting story than employee records. Even better, outside of the automobile industry, there aren't going to be pointed questions related to domain knowledge (a real risk when discussing employee records with a business person). This and the fact that OOP code is less accessible to the non-programmer than Cobol [which was designed for the boss to follow] gives us Java in any language.
Determining if the conceptual merger of Java and JavaScript described by the author is ironic is left as an exercise for the reader.
It seems to me that what makes some programming tools better than other is that they hide mathematical and computational complexity while making solving problems easier - nothing is going to make the computationally hard or intractable not hard or intractable.
Attempts to hide computational and mathematical complexity is pretty much the theme for a whole history of programming languages. It certainly is its genesis story -
at which point the history of debates over programming languages begins, and it seems to me that this debate is largely because what I call 'hiding computational and mathematical complexity' you are free to say obfuscates it. It's how we get the yin and yang of C and Scheme making 70's scene - malloc and and full lexical scoping both simplify someone's life and make someone's unbearable.I always know that there's a bad OOP example when automobiles are involved. It means it's a marketing piece not a tutorial - managers have cars and as a lowest common denominator of technical knowledge know they have four wheels, provided we ignore the one in the trunk. In other words, we've already lost because the person writing the explanation doesn't know the difference between hiding complexity and obfuscating it [How many cylinders in a Mazda Rx-8? Where does the Leaf fit in?].
On the flip side, what can we expect? Math is hard for a lot of people because it builds sequentially. Teenage hormonal distractions have probably prevented more people from moving beyond ciphering to algebra and beyond than anything save for access to educational resources.
FactoryProviderProviderProviders in the form of frameworks don't necessarily require understanding of higher order functions - like garbage collection, some lazy programmer wrote a program to handle it, and this turns out to be useful because people can use it without really understanding what it is, and being able to use things which are not computationally understood is pretty much the driving force behind the rise of OOP - how many people talk about dispatch when discussing an object's methods?
OOP is a sexier Cobol - cars and their wheels makes for more interesting story than employee records. Even better, outside of the automobile industry, there aren't going to be pointed questions related to domain knowledge (a real risk when discussing employee records with a business person). This and the fact that OOP code is less accessible to the non-programmer than Cobol [which was designed for the boss to follow] gives us Java in any language.
Determining if the conceptual merger of Java and JavaScript described by the author is ironic is left as an exercise for the reader.