Math ugliness.
in [JavaScript]
|
From: kangax on 17 Feb 2010 17:03 On 2/17/10 4:15 AM, Dmitry A. Soshnikov wrote: > On Feb 17, 2:23 am, Jorge<jo...(a)jorgechamorro.com> wrote: >> Hi, >> >> Do you think -as I do- that the Math object is an ugly artifact ? >> Well, here's a nice way of getting rid of it : >> > > Artifact of not - that's questionable, because some methods fit to > numbers (e.g. .round(), other), some by semantic - for mathematical > actions and could be placed in separate Math'ematical module. > > Other question is style of code. I always don't like to repeat some > chunks of code, I always try to decrease such repetitions. That's why > I really don't like new approach in ES5 for methods to work with > objects which are placed not in `Object.prototype' letting to work in > OOP-style, but in `Object' constructor itself. I know the reasons why > it was done so (such a "protection" if simple object will have own > such property), but that seems to my ugly too (just an abstract > example): > > var o = Object.freeze( > Object.seel( > Object.defineProperties( > Object.create(proto), > properties > ) > ) > ); > > This repetition of Object.-Object.-Object. is really `heavy'. The > first thing which also can be done in ES5 (to make it more comfortable > in some viewpoint) - is definition of the same methods in > `Object.prototype' (with [[Enumerable]] = false), allowing elegant > chains, decreasing of the repeated chunks of code such as `Object.': > > var o = Object.create(proto) > .defineProperties(properties) > .seel() > .freeze(); I see your point, and I understand that this is just an example, but I don't think it's that bad. `Object.create`, for example, already passes its second argument to `Object.defineProperties`, so that we don't have to write (although we can): Object.defineProperties(Object.create(Parent), { ... }); but instead just: Object.create(Parent, { ... }); You also wouldn't call `seal` followed by `freeze`, as there's little point in that. That example, therefore, becomes quite short: var o = Object.freeze(Object.create(Parent, { ... })); or avoiding `Object.freeze` altogether if there are only 1 or 2 properties: var o = Object.create(Parent, { someProp: { value: someValue, configurable: false }, someOtherProp: { value: someOtherValue, configurable: false } }); [...] -- kangax
From: kangax on 17 Feb 2010 17:19 On 2/17/10 3:16 PM, Dmitry A. Soshnikov wrote: > On Feb 17, 10:58 pm, kangax<kan...(a)gmail.com> wrote: > > [...] > >> >> some of ES5 bits are already implemented in, for example, nightly >> WebKit (and Opera 10.50 alpha, IIRC). >> > > Also if interested, almost all features of ES5 (except of "strict > mode") are implemented in Rhino 1_7R3pre:<URL: ftp://ftp.mozilla.org/pub/mozilla.org/js/>. > I use it for test - as in sources there's a runnable js-console. Did you have to build it? `ant compile` fails here (on Snow Leopard), and js.jar that's in the root says "Rhino 1.7 release 2 2009 03 22" WebKit doesn't seem to have strict mode either, at the moment. -- kangax
From: Peter Michaux on 17 Feb 2010 17:27 On Feb 17, 1:10 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > Peter Michaux wrote: > > Jorge wrote: > >> Do you think -as I do- that the Math object is an ugly artifact ? > > > No. > > ACK > > > Think of it as a namespace for Math functions. > > See below. > > >> (2).pow(10) > >> --> 1024 > > > That is a perfect example of where message passing for (at least) Math > > fails. > > What are you talking about? Nothing fails here. It fails to pass my judgment as an appropriate language/library design for how to raise one number to the power of another number. This is a subjective discussion. > > The exponentiation function takes two arguments: base and > > exponent. Neither is more important than the other. > > Straw man. > > > 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. > > Neither argument has state that is or needs mutation. > > Non sequitur. Messages do not need to cause mutation. No they don't but that is what the paradigm was primarily designed to do and there is no need for it here. > > 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. > > Message passing is an inappropriate paradigm for this sort of > > computation. > > Several designers of other languages, in particular Smalltalk, would > disagree. But they were wrong. > > This looks a whole lot better: > > > pow(2, 10) > > Because it is prefix instead of infix style? Aesthetically yes but more substantially because it is a simple function call rather than a message passing system. > Efficiency considerations > aside, that is is a matter of preference. And given that in math we are > writing > > 10 > 2 > > to display the value of "two to the tenth power", is it not more similar > and therefore more intuititive to write (2).pow(10) in source code? I wouldn't rest my argument on the idea that Mathematical notation is good. Mathematical notation is unnecessarily complex and unclear. For example, the following is more than unfortunate. Any Math teacher can attest to this example causing students a lot of grief. -1 (sin(x)) -1 sin (x) > I know > at least one programming language that agrees here: bash (`$((2**10))'). > > > Adding a namespace is not significantly different: > > > Math.pow(2, 10) > > Non sequitur. No namespace is needed where the context is clear. I'm not saying the namespacing is required. I'm saying that having to write eight characters for the name of the function instead of three characters isn't something to get fussed about. Peter
From: kangax on 17 Feb 2010 17:29 On 2/17/10 4:45 PM, Jorge wrote: > On Feb 17, 7:05 pm, Jorge<jo...(a)jorgechamorro.com> wrote: >> >> var x= 3; >> Number.prototype.test= function () { return this; }; >> x.test() === x.test() >> --> false > > @kangax: isn't this a nice one for the quiz ? I remember seeing a similar proposal for a quiz question (where changing `===` to `==` would obviously eliminate "confusion"): Number.prototype.isOne = function(){ return this === 1; }; (1).isOne(); // true or false? There's also http://wtfjs.com/ listing things that people find confusing about "Javascript". -- kangax
From: Thomas 'PointedEars' Lahn on 17 Feb 2010 18:54
Peter Michaux wrote: > Thomas 'PointedEars' Lahn wrote: >> Peter Michaux wrote: >> > Jorge wrote: >> >> (2).pow(10) >> >> --> 1024 >> > That is a perfect example of where message passing for (at least) Math >> > fails. >> What are you talking about? Nothing fails here. > > It fails to pass my judgment as an appropriate language/library design > for how to raise one number to the power of another number. This is a > subjective discussion. It is rather pointless rambling on your part. >> > 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. 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. 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. FWIW, Brendan Eich agrees with that in his blog. >> > Neither argument has state that is or needs mutation. >> Non sequitur. Messages do not need to cause mutation. > > No they don't but that is what the paradigm was primarily designed to > do [...] Nonsense. >> > 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. Following this reasoning you would need to object to Math.pow(...), too. >> > Message passing is an inappropriate paradigm for this sort of >> > computation. >> Several designers of other languages, in particular Smalltalk, would >> disagree. > > But they were wrong. According to whom, and because of what? >> > This looks a whole lot better: >> > pow(2, 10) >> Because it is prefix instead of infix style? > > Aesthetically yes but more substantially because it is a simple > function call rather than a message passing system. Sounds pretty much like circular reasoning. >> Efficiency considerations >> aside, that is is a matter of preference. And given that in math we are >> writing >> >> 10 >> 2 >> >> to display the value of "two to the tenth power", is it not more similar >> and therefore more intuititive to write (2).pow(10) in source code? > > I wouldn't rest my argument on the idea that Mathematical notation is > good. Mathematical notation is unnecessarily complex and unclear. [...] Sorry, you have not the shadow of a clue what you are talking about. > -1 > (sin(x)) > > -1 > sin (x) I rest my case. >> > Adding a namespace is not significantly different: >> > Math.pow(2, 10) >> Non sequitur. No namespace is needed where the context is clear. > > I'm not saying the namespacing is required. I'm saying that having to > write eight characters for the name of the function instead of three > characters isn't something to get fussed about. If your reasoning was consistent, you would *need* to get fussed about to begin with. But, you do not really have a point; you are just rambling here. Anyhow, please trim your quotations to the relevant minimum next time. PointedEars -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16 |