71–80 of 80 posts
Seems like "this is why Javascript sucks!" is a common reaction here, which I find strange on a "hacker" community. It's a fun little brainteaser, not production code. Use your head a little?
It demonstrates language issues that can (and often do) lead to problems in production. So the response is completely appropriate.
My question is, when did that start working in Javascript? Does this trick work in Brendan Eich's first JS implementaion in Netscape 2.0? Which came first, the spec or the implementation?
The implementation came first. From what I understood, Microsoft looked at Netscape's implementation, wrote a spec from that and implemented it - so when time came to standardize it, Microsoft had a readily available spec (having written one after reverse engineering Netscape's implementation). Since Javascript has lots of little quirks, Microsoft didn't quite get everything right and so when the final spec was published, Netscape's implementation was actually in violation of it in a couple of places.
I guess that's funny depending on who you are.
Earlier quoted context omitted.
Hold up, I think I just stumbled on to a fellow alum. (Surely no other university teaches that language besides mine, right?)
You haven't, I just think that it's a wonderful language. I really wish it was Open Source...it makes me sad.
See you at the J software forums.
Thought some and came up with an way to convert whichever natural number you want into this form. https://gist.github.com/1531201 It depends on underscore.js for the functional bits.
Wow, those are really unfortunate variable names. I've never seen the term "gook" outside of a racial slur context.
Earlier quoted context omitted.
I think a lot of the hate against statically-typed languages is because people associate them with languages like C# and Java (as opposed to e.g.: OCaml), which lack not only many of the higher-order functional features that we've come to expect in both static and dynamic languages, but also the soundness guarantees that come from actual type-safety. If you're more productive in JavaScript, it's probably not because…
If you're more productive in JavaScript, it's probably not because you can write a function that converts either an string or an integer to an array2. Right which was my point in my other post where I said I just don't run into it that much. It is rare that we run into situations where we have to do tricky stuff with the type system. If we do we usually hide it behind a well tested API so that it is isolated and reus…
Maybe you've created a button that puts some text in an element, but, in some rare cases, due to other events on the page, that element doesn't exist. The user clicks the button, document.getElementById returns null, and a nice error message pops out.
In JavaScript, you might discover this after a lot of testing. In DynXML, you would never be able to make that bug in the first place -- you'd get a type error.
(JavaScript has the advantage, though, of not being vaporware. As the low-paid undergraduate doing the implementation work on DynXML, this is my fault.)
Remember, being able to write a function that converts either a string or an integer to an array is exactly the kind of thing that dynamically typed languages let you do that statically-typed languages don't. If you're not doing that kind of thing, you're better off with a statically-typed language (when available).
This sort of thing really bothers me with Javascript. Using the unary + operator on an array should be an error. Hiding errors by having implicit type convertions doesn't help me fix those errors. You may say that users don't need to see to see strange error messages they don't understand. Quite right, what we need instead is to have a way for browsers to transmit uncaught exceptions in JS to the server.
What should the unary + operator do except for type coercion into a number? Or are you saying it should only work on strings? It just doesn't seem like something that would happen accidentally, there's no reason to put + on something unless you are explicitly trying to coerce it into a number. It's not like unary minus where -x; could have some other semantic meaning for something that is already a number and you mak…
If I want an array to be a number, I'll call .Count on the array or whatever the applicable property I want is.
If you rely on that sort of thing in production code, you're doing it wrong.
Earlier quoted context omitted.
Hold up, I think I just stumbled on to a fellow alum. (Surely no other university teaches that language besides mine, right?)
Which university are you talking about? (I'm learning J and other APL derivatives right now by myself by experimenting with the J docs and pinging the amazing people at the J software forums).
Earlier quoted context omitted.
What should the unary + operator do except for type coercion into a number? Or are you saying it should only work on strings? It just doesn't seem like something that would happen accidentally, there's no reason to put + on something unless you are explicitly trying to coerce it into a number. It's not like unary minus where -x; could have some other semantic meaning for something that is already a number and you mak…
Using an array (or a string for that matter) where only a number should be is an error. I'd like to see an exception thrown and the current JS uncaught-exception-handler would be invoked, assuming something else catches it. If I want an array to be a number, I'll call .Count on the array or whatever the applicable property I want is.
The unary '+' operator is completely pointless if something is already a number, it is a no-op. Literally the only time anyone would ever type +x is if x is not a number, if someone chose to write +x and x turned out to unexpectedly be an array, pretty much the only thing that you know they were thinking of when they wrote the + was that they thought x isn't a number; maybe a string if they were using +x instead of parseFloat(x), but definitely not a number.
It just isn't a reasonable example of a situation where an array is being used where a number should be, +x where you know that x is a number would make no sense. If you talk about -x then that is completely different, people who write -x almost certainly expect it to be a number, and -[] === 0. Unary plus is just not the right example for awful type coercion here.