Math ugliness.
in [JavaScript]
|
From: Dmitry A. Soshnikov on 18 Feb 2010 04:06 On Feb 18, 1:27 am, Peter Michaux <petermich...(a)gmail.com> wrote: > On Feb 17, 1:10 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> > wrote: <snip> > > > > Neither is the object to which I wish to send a message. > > > Yes, the "object" is `2' (or `(2)'). > > No. I don't want to send a message to the object 2. I don't want to > send messages to anything. I just want the value of the power and I > want to do that by a function call. > Well, then objectively nothing can prevent you, you can easily use the mathematical function paradigm, where's the function is the center, is the thing with the main role, and arguments - just a "helpers" which help to show the result of that center. But that's questionable. In OOP-paradigm numbers (regardless implementation on low level) also can be presented as objects. And then you can just ask (to send the message waiting the reply) this object: "Can you provide the value of the 10 prower of *yourself*?" Here already object is the center, and functions ("technique", methods) - are "helpers" for getting the result. > > > They are just arguments to a pure function that has no side effects. > > > So what? > > If something can be just a simple function then let it be just a > simple function. > Abstractly in most implementations (of OOP paradigm) any simple function is just a member of some object. But repeat, this is questionable, where to put this mathematical methods - directly in to the numbers, or into the separate namespace. Mentioned above Ruby, e.g. has some methods in numbers, such as: 1.5.round 0.5.ceil 2**10 # which is the value of the power and also there's the Math module also, which is the container for other mathematical stuff, such as .sin, .cos and so on: Math.sin(a) Why it's still possible to have a Math module - because mathematics works also works with higher abstractions than just a numbers (for example, matrix, integrals and so on, although for this usually additional namespace (or separate module) is provided). So, in OOP paradigm the object is full-right entity which can provide related results itself (independently how it will do it on implementation level, will it ask the same Math.pow, or something other - that's abstraction for you). And numbers in object abstraction are full-right objects which play on their field - on field of numbers. And if numbers are related to mathematics, that number objects can *know* something about mathematics, and *use* the mathematics - that's a vice verse when mathematics uses numbers. So, you can easily ask: "You are number. Can you get the value of the power of yourself?" And can (in any other paradigm): "You are Math. Can you provide the value of the power of that two (unknown) numbers?" /ds
From: Richard Cornford on 18 Feb 2010 08:21 On Feb 17, 8:59 pm, Jorge wrote: > On Feb 17, 8:25 pm, Richard Cornford wrote: <snip> >>> and 2nd having read the >>> related chapter of the ES3 spec. > >> Any decent book on the subject should have made the point. >> It is a pity that there are so few decent books on the >> subject but the good ones should explain the aspects of >> the language that people find difficult to understand. > > The explanation isn't difficult to understand, it's that > the behaviour requires explanation just because it's > counter-intuitive. I would have to question whether any aspect of computer programming is actually intuitive. To illustrate; would you be able to provide a worthwhile question on the subject of computer programming that I could take with me to the lobby and ask our office receptionist, and then Sam would be able to give me the correct answer based on her intuition about the subject? When we, as more or less experienced 'programmers', have intuitions about the subject I would maintain that they are mostly based on expectations acquired through experience. Usually experience with related subjects, particularly other programming languages. Different experiences lead people to have different expectations, and so different intuitions about how things should work. For example, on this page:- <URL: http://wtfjs.com/page/2 > - the example:- | "string" instanceof String; // false. | | // 'course it isn't not a string, it may look like a string | // but actually it's masquerading as a banana. - appears. Now, for someone experienced in Java expecting "string" to result in a string object, which should then be and - instanceof - String, is second nature, while someone only experienced in assembly language programming might have no expectations about the nature of string literal representations (objects or not), no idea about what - String - referred to, and no attitude towards what an - instanceof - operator should be doing. So you have one person who would declare the above wrong, and another who sees the need to do some research and so likely will end up seeing it as correct. There was a time when the majority of people coming anew to javascript where Java programmers, and so a feeling that javascript to change to become more Java-like so that it would accommodate their expectations/ intuitions better (hence ES4). These days I would judge the largest single group coming into javascript have previous PHP experience, and so expectations built on what PHP does. Ultimately the lesson that should be taken is that no programming language can be all things to all people, and so each should be understood in its own terms. >>> But -I guess- this won't happen anymore in ES5: the >>> wrapper object will be used just to lookup the >>> property in the appropriate .proto chain, but won't >>> be passed on to "this". > >> Hence the incompatibility with ES3. > > A price to pay for moving forward ? Given the number of incompatible changes that are opt-in in strict mode only, why should this one be hoisted upon everyone? A price will be paid, but it could have been a voluntary action under the control of web developers and paid on their time-scale. Richard.
From: John G Harris on 18 Feb 2010 08:31 On Thu, 18 Feb 2010 at 00:54:55, in comp.lang.javascript, Thomas 'PointedEars' Lahn wrote: >Peter Michaux wrote: <snip> >> No. I don't want to send a message to the object 2. I don't want to >> send messages to anything. I just want the value of the power and I >> want to do that by a function call. > >Then you should use a programming language that is either procedural or >functional, but not also object-oriented. Sending messages to objects is a >core principle of the object-oriented paradigm. What a load of codswallop. >In fact, it is rather debatable whether there should be such a thing like >primitive values as opposed to object values in an object-oriented >programming language. Literals are pure values. They don't exist until they're assigned to something. To say that they can be sent messages is pure nonsense. >FWIW, Brendan Eich agrees with that in his blog. Yet another appeal to authority. <snip> >> If something can be just a simple function then let it be just a >> simple function. >Following this reasoning you would need to object to Math.pow(...), too. Why ? Math is just a container of simple functions. <snip> >But, you do not really have a point; you are just rambling here. <snip> Pot, meet Kettle. John -- John Harris
From: Thomas 'PointedEars' Lahn on 18 Feb 2010 13:31 John G Harris wrote: > Thomas 'PointedEars' Lahn wrote: >> In fact, it is rather debatable whether there should be such a thing >> like primitive values as opposed to object values in an object-oriented >> programming language. > > Literals are pure values. They don't exist until they're assigned to > something. To say that they can be sent messages is pure nonsense. Evidence readily proves you wrong. >> FWIW, Brendan Eich agrees with that in his blog. > > Yet another appeal to authority. Of course not; I would not have written "FWIW" then. In an object-oriented programming language, primitive types that have no intrinsical relation to each another or to object types do not really make sense. What follows from making that distinction are, for example, the inefficiencies of conversion that occur whenever a primitive value is used as the first part of a /MemberExpression/, as we have just seen. It is only the procedural-imperative paradigm and the idea of compatibility that causes primitive types to exist is such a language. Brendan Eich, *among several other people*, has recognized that to be a mistake for JavaScript years ago, and he has suggested that all types should be object types, to remove the rather _useless_ duality of Number vs. new Number(), for example: <http://weblogs.mozillazine.org/roadmap/archives/2005/11/> There are other procedural-imperative object-oriented programming languages that have already implemented this, most notably Python. >>> If something can be just a simple function then let it be just a >>> simple function. >> Following this reasoning you would need to object to Math.pow(...), too. > > Why ? Math is just a container of simple functions. An object does not contain functions. `Math' is a reference to an object. Methods (a property of that object with a callable value) are called on that object without the object being specified to be used other than as a reference point for the function. If one objects to (1).pow(2) on the grounds that it is unnecessary because only a function with two arguments is required, if their reasoning would be consistent they would need to object to Math.pow(1, 2) even more, because, following that reasoning, pow(1, 2) would need to suffice. PointedEars -- Danny Goodman's books are out of date and teach practices that are positively harmful for cross-browser scripting. -- Richard Cornford, cljs, <cife6q$253$1$8300dec7(a)news.demon.co.uk> (2004)
From: Jorge on 18 Feb 2010 13:41
On Feb 18, 7:31 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > John G Harris wrote: > > Thomas 'PointedEars' Lahn wrote: > >> In fact, it is rather debatable whether there should be such a thing > >> like primitive values as opposed to object values in an object-oriented > >> programming language. > > > Literals are pure values. They don't exist until they're assigned to > > something. To say that they can be sent messages is pure nonsense. > > Evidence readily proves you wrong. > > >> FWIW, Brendan Eich agrees with that in his blog. > > > Yet another appeal to authority. > > Of course not; I would not have written "FWIW" then. In an object-oriented > programming language, primitive types that have no intrinsical relation to > each another or to object types do not really make sense. What follows > from making that distinction are, for example, the inefficiencies of > conversion that occur whenever a primitive value is used as the first part > of a /MemberExpression/, as we have just seen. Inefficiencies that exist only in your head (and in the specs when implemented literally and unwisely). But there's room for optimization, and implementations are allowed to optimize, as Lasse has taught you. > It is only the procedural-imperative paradigm and the idea of compatibility > that causes primitive types to exist is such a language. Brendan Eich, > *among several other people*, has recognized that to be a mistake for > JavaScript years ago, and he has suggested that all types should be object > types, to remove the rather _useless_ duality of Number vs. new Number(), > for example: > > <http://weblogs.mozillazine.org/roadmap/archives/2005/11/> > > There are other procedural-imperative object-oriented programming languages > that have already implemented this, most notably Python. > > >>> If something can be just a simple function then let it be just a > >>> simple function. > >> Following this reasoning you would need to object to Math.pow(...), too. > > > Why ? Math is just a container of simple functions. > > An object does not contain functions. `Math' is a reference to an object. > Methods (a property of that object with a callable value) are called on > that object without the object being specified to be used other than as a > reference point for the function. > > If one objects to (1).pow(2) on the grounds that it is unnecessary because > only a function with two arguments is required, if their reasoning would be > consistent they would need to object to Math.pow(1, 2) even more, because, > following that reasoning, pow(1, 2) would need to suffice. That's true. -- Jorge. |