Math ugliness.
in [JavaScript]
|
From: John G Harris on 19 Feb 2010 14:12 On Thu, 18 Feb 2010 at 19:31:15, in comp.lang.javascript, Thomas 'PointedEars' Lahn 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. It's clear what 2.3 + 1.4 means, but to say that 2.3 'knows' how to add 1.4 to itself is pure nonsense. For a start, 2.3 is not mutable. Of course, to say that the compiler is designed to do something like create an object holding 2.3 within itself is legitimate, but there are still primitive values in there. Oh, hang about, that's how the ECMAScript languages work, isn't it. >>> 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's not compulsory for the language to be designed to do automatic constructions. For instance, where javascript and Java allow a + 1.4 the equivalent C++ expression is *a + 1.4 (note that a is a pointer). >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. A coherent type system has each type built from 'simpler' types, or from foundation types. The system needs these foundation types to be able to do proofs by induction and to define mathematical properties using recursion. Primitive types are the foundation types. In contrast, if you insist that every property holds an object and nothing else then you've some complicated specifying to do in order to put numbers and character arrays in there somewhere. >>>> 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. It's well known that javascript does things differently, but you can emulate what other languages do, sometimes rather awkwardly. Here's a case where a namespace is being emulated by an object. It's silly to complain about the mechanics of the emulation being visible. <snip> John -- John Harris
From: Dmitry A. Soshnikov on 19 Feb 2010 17:31 On Feb 19, 10:12 pm, John G Harris <j...(a)nospam.demon.co.uk> wrote: <snip> > > It's clear what 2.3 + 1.4 means, but to say that 2.3 'knows' how to > add 1.4 to itself is pure nonsense. > You can think that 2.3. provides new objects (what actually is) by applying itself to other object. Statement "pure nonsense" - is inappropriate (only if it's hard to imagine number objects abstraction). > For a start, 2.3 is not mutable. It may be, or may not be so, again - depends on implementation and ideology of abstraction. What can prevent to mutate object from one state to another, possibly applying it's previous state to some external factor? Though, usually it creates new object based on its state. /ds
From: Jorge on 19 Feb 2010 17:41 On Feb 19, 11:31 pm, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com> wrote: > On Feb 19, 10:12 pm, John G Harris <j...(a)nospam.demon.co.uk> wrote: > > <snip> > > > > > It's clear what 2.3 + 1.4 means, but to say that 2.3 'knows' how to > > add 1.4 to itself is pure nonsense. > > You can think that 2.3. provides new objects (what actually is) by > applying itself to other object. Statement "pure nonsense" - is > inappropriate (only if it's hard to imagine number objects > abstraction). > > > For a start, 2.3 is not mutable. > > It may be, or may not be so, again - depends on implementation and > ideology of abstraction. What can prevent to mutate object from one > state to another, possibly applying it's previous state to some > external factor? Though, usually it creates new object based on its > state. And it doesn't matter whether 2.3 is or isn't mutable. It's just an object that has a method that returns a value: e.g. 2.3.floor() -- Jorge.
From: Thomas 'PointedEars' Lahn on 19 Feb 2010 22:25 John G Harris wrote: > Thomas 'PointedEars' Lahn 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. > > It's clear what 2.3 + 1.4 means, but to say that 2.3 'knows' how to > add 1.4 to itself is pure nonsense. Evidence readily proves you wrong, although not in current ECMAScript implementations. > For a start, 2.3 is not mutable. It could be, were the language defined differently. > Of course, to say that the compiler is designed to do something like > create an object holding 2.3 within itself is legitimate, but there are > still primitive values in there. > > Oh, hang about, that's how the ECMAScript languages work, isn't it. This was about method calls, not operators, and your original statement is still 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's not compulsory for the language to be designed to do automatic > constructions. For instance, where javascript and Java allow a + 1.4 > the equivalent C++ expression is *a + 1.4 (note that a is a pointer). I don't see your point. C++ is as much a hybrid language as are Java and JavaScript, only that the former two are strictly typed, which is why you cannot simply write "a + 1.4" in Java or C++ without knowing the type of `a'. >> 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. > > A coherent type system has each type built from 'simpler' types, or from > foundation types. The system needs these foundation types to be able to > do proofs by induction and to define mathematical properties using > recursion. Primitive types are the foundation types. They are unnecessary. Foundation types can be object types as well. > In contrast, if you insist that every property holds an object and > nothing else then you've some complicated specifying to do in order to > put numbers and character arrays in there somewhere. No. >>>>> 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. > > It's well known that javascript does things differently, but you can > emulate what other languages do, sometimes rather awkwardly. > > Here's a case where a namespace is being emulated by an object. It's > silly to complain about the mechanics of the emulation being visible. You miss the point. PointedEars -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>
From: Lasse Reichstein Nielsen on 20 Feb 2010 08:07
Thomas 'PointedEars' Lahn <PointedEars(a)web.de> writes: > John G Harris wrote: >> It's clear what 2.3 + 1.4 means, but to say that 2.3 'knows' how to >> add 1.4 to itself is pure nonsense. > > Evidence readily proves you wrong, although not in current ECMAScript > implementations. It's clear that other languages have taken the road of having math operations that work by sending messages to one of the arguments. In that way, it "makes sense". When numbers are objects[1], it makes sense to have operations on that number as methods of the number. Methods with only one parameter can use "this" as that parameter. However, when you have a method that take two, equally important, parameters, and that doesn't mutate either (or really: and doesn't depend on the identity of either), it's not obvious which of them should carry the method. In those cases, it makes just as much sense, and perhaps more - because it doesn't make an arbitrary choice - to put the method on a separate object. E.g., a function that repeats a string a number of times. It could be either Number::repeatString(String): String or String::repeatString(Number): Number but it could just as well be StringFactory::repeatString(String,Number): String In languages with something like static methods, StringFactory would typically be the String class object. >> For a start, 2.3 is not mutable. > > It could be, were the language defined differently. Then it would not be a 2.3 object, but just a boxed number. If you did: var x = 2.3; var y = 2.3; and 2.3 was mutable ... would x.mutate() mean that the value of y changed? Or did the two 2.3's have different identity? >> A coherent type system has each type built from 'simpler' types, or from >> foundation types. The system needs these foundation types to be able to >> do proofs by induction and to define mathematical properties using >> recursion. Primitive types are the foundation types. > > They are unnecessary. Foundation types can be object types as well. Correct. And they were in, e.g., Smalltalk. It's quite possible to both do this and optimize it to avoid actually allocating space for a separate object for each number. The choice of foundation types also differ. In ECMAScript, string is a primive, in Java it is an Object. Nothing prevents numbers from being objects as well (semantically). Instead we have the weird distinction in Java where you can't put unboxed primitives into collections, which is quite often what you really want to do. ECMAScript fares a little easier, because we don't have a type system that distinguishes objects and primitves, and we can call methods on primitives. With ES5, we don't really need the wrapper classes for anything any more, except as a specification tool. >> In contrast, if you insist that every property holds an object and >> nothing else then you've some complicated specifying to do in order to >> put numbers and character arrays in there somewhere. > > No. Agree, that's an implementation problem, not a specification problem, and it has been shown possible to implement. /L -- Lasse Reichstein Holst Nielsen 'Javascript frameworks is a disruptive technology' |