Live data from Hacker News

A re-introduction to JavaScript

developer.mozilla.org

101–110 of 115 posts

Re: A re-introduction to JavaScript

#101
post #60

I think it's much easier to forget about "types" and think of objects instead. Trying to divide JavaScript objects into "types" will surely get you frustrated. If you absolutely want to check what "type" an object is, for example a sanity check for arguments passed to a function, you should make your own isMyType(obj) function and not rely on typeof or toString.

I think if you simply accept that there is no spoon, and that any utensil can be coerced and used as a spoon you will be much happier.

In general, the only niggle is when you want a discrete integer value, where zero is an acceptable input, or a string that represents a number coerced into a number.. but anything else to be null. You have to single out falsy values that aren't zero in this case.

Other than that one niggle in practice, I've come to truly appreciate the expressive nature that JS actually offers in practice. The additional concepts added in terms of ES6 and ES7 are pretty welcome. Though in practice, I've moved very far away from trying to apply many OO patterns of classes, inheritance, etc in favor of basic object instances, and functions that can be combined/composed.

It's pretty nifty all around.

Re: A re-introduction to JavaScript

#102
post #63

One caveat not mentioned is that while float is 64 bit floating point number, int is only 53 bit integer, unlike having 64 bit int in most other languages. Yeah, I've got bitten by this before causing a nasty bug.

As far as I know 53-bit integers are a bit haphazard in JavaScript - it's best to stick to 32-bit unless you really know what you're doing.

The biggest gotchas with whole numbers in JS (IEE754 64-bit floats) is that in JS all bitwise operations are performed on a 32-bit integer under the hood... in practice this means you can do a bitwise operation on anything and it will be coerced into a 32-bit integer, either first via the parseInt(X,10) path, or becomes an empty 0 value.

It really isn't unique to JS, and there are several bignum libraries that can/will help.

Re: A re-introduction to JavaScript

#103
post #45

Earlier quoted context omitted.

I haven't either, only that delete will cause code to be de-optimized.

I think it affected earlier versions of IE - Douglas Crockford detailed an issue here: http://javascript.crockford.com/memory/leak.html

What the hell is wrong with people today? I was hazarding a guess what was being referred to and I get down voted?

Re: A re-introduction to JavaScript

#104
"JavaScript is an object oriented..."

No it isn't. It has support for OO and you can choose to write code object-oriented if you wish. But equally you can disregard the OO bit quite happily and compose behaviour using closures instead.

None of my favourite JS libs are OO, it's a poor abstraction imho.

Re: A re-introduction to JavaScript

#105

Earlier quoted context omitted.

That's not generally necessary in ES6 when you use "=>" to define functions. Javascript is getting better...

It's really a minor criticism and I know ES6 resolves the issue :-)

Through bind of course, for the silly person who downvote me. Helps to have strict mode on. Happy to have educated you!

Re: A re-introduction to JavaScript

#106
post #33

Earlier quoted context omitted.

"technically, functions are just objects that can be called" How can you create an object which can be called like a function, but will respond to 'typeof' with 'object' rather than 'function'? What happens when you try to call an object - what's the error? Try it, in a few of your favourite javascript interpreters: ({})() It seems clear to me that functions are more than "just" objects in JS. You can't start out wit…

> How can you create an object which can be called like a function, but will respond to 'typeof' with 'object' rather than 'function'? You can't, by definition. Here is the relevant section of the ECMAScript 5 spec: http://www.ecma-international.org/ecma-262/5.1/#sec-11.4.3 Basically, an object which implements call will always cause `typeof` to return "function". But the broader point is that `typeof` will lie to yo…

>Basically, an object which implements call will always cause `typeof` to return "function".

Are there any implementations which actually do this? In Node:

typeof({ call: function () { } }) --> 'object'

({ call: function () { } })() --> TypeError: object is not a function

Re: A re-introduction to JavaScript

#107

Earlier quoted context omitted.

To be fair, just because something is a standard doesn't mean it isn't a dumb implementation. Just by testing the programming languages on my computer, I can tell you that Python, C, and D all throw errors rather than allow it, which is the smart thing to do.

> I can tell you that Python, C, and D all throw errors rather than allow it Python throws an error, but numpy.divide(1., 0) will work just fine (and return inf). I'm not sure why you're saying C throws an error. The behavior of dividing by 0 is undefined by default, but on most machines these days the hardware implements IEE-754 and the C implementation will advertise as implementing IEC 60559, so 1. / 0 will give y…

Trying to compile a test program with Clang threw errors, and bringing up numpy is disingenuous.

Re: A re-introduction to JavaScript

#108
post #71

Earlier quoted context omitted.

I think nearly every JS engine now optimizes `for (...;i In fact, even `for` is likely an over-optimization. In nearly all JS code you can get away with just using `forEach` (or its friends).

forEach is awfully slow compared to a for statement if you're dealing with numbers - less so with strings/objects, but it's still noticeable (like 10x whenever I've tested it at best). Caching the array length still gives you a small speed boost in most browsers, but it's probably an over optimisation unless you're doing something really intensive.

I think a big reason to cache the array length within interviews (for cases when it isn't already cached) is that to not do so can often increase the complexity of a solution by a factor of O(n).

Re: A re-introduction to JavaScript

#109
post #27

The article says to watch out for 0.1 + 0.2 not exactly equalling 0.3 , so as a complete newbie to JavaScript, how do you work around this ?

See if there is a fixed precision arithmetic library for JS? (similar to BigDecimal in Java / Groovy) Homework: 1) Google for such; 2) see which one doesn't suck.

Groovy is a heavily marketed programming language that uses BigDecimal, just like its sister dynamic languages Clojure, Rhino/Nashorn, and Xtend also do. Only Java actually ships BigDecimal.

Re: A re-introduction to JavaScript

#110

Earlier quoted context omitted.

> I can tell you that Python, C, and D all throw errors rather than allow it Python throws an error, but numpy.divide(1., 0) will work just fine (and return inf). I'm not sure why you're saying C throws an error. The behavior of dividing by 0 is undefined by default, but on most machines these days the hardware implements IEE-754 and the C implementation will advertise as implementing IEC 60559, so 1. / 0 will give y…

Trying to compile a test program with Clang threw errors, and bringing up numpy is disingenuous.

Are you sure you were using floating point math? Compiling 1.0 / 0.0 should not give errors or warnings. 1 / 0 will, on the other hand.
Post reply on HN