3 ms·

> It's curious how you don't even address my points and just say that I missed the point when I'm the one dictating the point in my original comment. > Typical

> It's curious how you don't even address my points and just say that I missed the point when I'm the one dictating the point in my original comment. > Typically this isn't how you respect other people and get them to respond positively to your comments > The examples in the original piece are in javascript. Why don't you RTFA before commenting on the "point." I wrote that article, so in effect you are responding to my original comment : ). Fair that what I wrote was condescending. I purposefully wrote it that way, as a second meta-point: to get you to experience what it feels like when people assume negative, and use words like "Ok, no", "Javascript programmer" (negative connotation), "junior" With that accomplished, moving on to more civil ground. > I'm not sure what you're objective is because people aren't really reading this thread... it's already buried. First, as you can now feel, I was pretty annoyed by your presumptuous tone in your initial comment. Second it really did feel like you had depth and love in programming, but from your comments I intuited some traits that lead to lower potential outcomes. Mainly: jumping to conclusions too quickly (harder to learn new things this way, and unless you are almost finished with your career, it can be detrimental). > Does the guy even know that the class keyword is just sugar for "function" in javascript? ... Not to be insulting but the parent poster likely doesn't have much experience. Yes, I do know what classes de-sugar to in javascript, I worked with many of the folks who brought classes to the ES spec. As you most likely know, javascript classes are a bit of a special case, because JS uses prototypical inheritance. Classes in other languages do not de-sugar this way. For example: you can see a function as a special `class` with only one method `apply`, or you could see a class as a special higher order function. > Who missed the point? The point is, that though functions and classes seem distinct, they are less distinct than one would think. In your comments, you seem very attached to the specific distinctions you've set up with classes, procedures, and functions. One question I would ask you is: what is _similar_ about them? Could you express all of these with one abstraction? Is there a difference between choosing `class` as the base abstraction, vs a closure?

leafboi 6y ago
>One question I would ask you is: what is _similar_ about them? Could you express all of these with one abstraction? Is there a difference between choosing `class` as the base abstraction, vs a closure? The answer is yes you can. But you're thinking in the wrong direction. First let's make things clear. A function is just a one line expression where all values are immutable. There is no concept of time or procedures in a function. function def f(x): return ((x + 1) * 2)/3 procedure: def f(x): x = x + 1 x = x * 2 x = x / 3 return x You are saying that a procedure is isomorphic to an object which is to say you can define an object in terms of a procedure and a procedure in terms of an object. People often mix up the two terms, procedure and function but it's no big deal. The issue is, you used the term "Higher Order" function and the second issue I had was that it's actually quite an obvious thing presented as if it was novel. Well first off all computers are procedural machines. The underlying machine is just executing machine code which is a series of procedures. So all programming languages on top of this are implemented with procedures. That means OOP languages are implemented with procedures. That means FP languages are implemented with procedures. That means procedural languages are implemented with procedures. Basically your post is just reiterating how an object is implemented by a compiler. However the title of your post used "Higher Order Function." This implies you don't know the distinction between procedures and functions as "Higher order" functions are usually reserved for true functions, not procedures. That was the point of my post, to help you see the distinction because although you can create objects from procedures, you cannot create objects from functions because objects require mutation which is a primitive that a function cannot actually provide. The relationship is surjective or unidirectional. >harder to learn new things this way, and unless you are almost finished with your career, it can be detrimental This is the internet. I can communicate without a filter on the internet with little consequence. Filters slow things down as do a lack of filter. Either way I can get to the point quickly without worrying about offending someone.

leafboi 6y ago

>One question I would ask you is: what is _similar_ about them? Could you express all of these with one abstraction? Is there a difference between choosing `class` as the base abstraction, vs a closure? The answer is yes you can. But you're thinking in the wrong direction. First let's make things clear. A function is just a one line expression where all values are immutable. There is no concept of time or procedures in a function. function def f(x): return ((x + 1) * 2)/3 procedure: def f(x): x = x + 1 x = x * 2 x = x / 3 return x You are saying that a procedure is isomorphic to an object which is to say you can define an object in terms of a procedure and a procedure in terms of an object. People often mix up the two terms, procedure and function but it's no big deal. The issue is, you used the term "Higher Order" function and the second issue I had was that it's actually quite an obvious thing presented as if it was novel. Well first off all computers are procedural machines. The underlying machine is just executing machine code which is a series of procedures. So all programming languages on top of this are implemented with procedures. That means OOP languages are implemented with procedures. That means FP languages are implemented with procedures. That means procedural languages are implemented with procedures. Basically your post is just reiterating how an object is implemented by a compiler. However the title of your post used "Higher Order Function." This implies you don't know the distinction between procedures and functions as "Higher order" functions are usually reserved for true functions, not procedures. That was the point of my post, to help you see the distinction because although you can create objects from procedures, you cannot create objects from functions because objects require mutation which is a primitive that a function cannot actually provide. The relationship is surjective or unidirectional. >harder to learn new things this way, and unless you are almost finished with your career, it can be detrimental This is the internet. I can communicate without a filter on the internet with little consequence. Filters slow things down as do a lack of filter. Either way I can get to the point quickly without worrying about offending someone.