61–70 of 80 posts
Earlier quoted context omitted.
You describe that as "not surprising"? Yikes.
It's surprising if you haven't used javascript before I guess.
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.
I've never seen the term "gook" outside of a racial slur context.
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.
Wow, those are really unfortunate variable names. I've never seen the term "gook" outside of a racial slur context.
Changed. Figured that the time it would have taken to write up something about people being able to look past racial slurs blah blah blah was more than just "fixing" it.
Earlier quoted context omitted.
Sure my case is anecdotal at best, and maybe I have just been lucky, but my experience has been that implementing UI's with JavaScript is as fast of a development cycle as doing it in Java or C#. In fact the UI space is dominated by languages such as JavaScript and Objective-C where type safety is loose. I don't believe that fact means that they are superior, but they are as productive as strong typing for UI develop…
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…
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 reusable. It's just not the problem domain that we solve for (most of the time) in web and mobile development. As such for my work flow the type safety of a languadge, does not factor in all that much. At least until I hit the middleware layer then I tend to use Java, but much of that decision is out of comfort and volume of libraries available.
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.
There are some gotchas is JavaScript like the (== for 0, null, ""), the floating scope of (this) and a few others but for the major use cases of JavaScript people only need to be aware of a handful of languadge nuances to not hang themselves. It has some quarks no doubt about it, but for the most part they are easily avoided or you have to know about them to be doing what you are doing in the first place.
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.
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 make a mistake and give it an array (which javascript has, and I think is a much more likely source of error than the unary plus).
Earlier quoted context omitted.
It's surprising if you haven't used javascript before I guess.
You can use javascript for years and never come across a situation where you'd do or see several of the things found in that small statement.
Earlier quoted context omitted.
It's surprising if you haven't used javascript before I guess.
You can use javascript for years and never come across a situation where you'd do or see several of the things found in that small statement.
1). a list of expressions eg (foo,bar,baz) evaluates to the last one.
2). Array(4) creates an empty array of 4 elements
2). Array(4).toString() = ",,,"Earlier quoted context omitted.
You can use javascript for years and never come across a situation where you'd do or see several of the things found in that small statement.
There are only 3 things, which aren't surprising to anyone who has done much js. 1). a list of expressions eg (foo,bar,baz) evaluates to the last one. 2). Array(4) creates an empty array of 4 elements 2). Array(4).toString() = ",,,"
The same applies to the void operator, I can think of one or two cases at most where it would be useful, but I don't see anyone using it.