41–50 of 80 posts
This is the reason I prefer strongly typed languages. Allowing developers to play fast and loose with data types only leads to less maintainability down the road and makes code difficult to read.
I am not a PL expert, but is this a strong vs. weak type problem or an implicit conversion problem? My layman’s (simplistic) model is that “weakly typed” languages allow entities to change their type at runtime, strongly typed languages do not. But what we have here is an expression where entities are being implicitly converted into intermediate values, along with operators that do different things based on the value…
http://blog.steveklabnik.com/posts/2010-07-17-what-to-know-b...
Earlier quoted context omitted.
No they will, in every horribly thought out interview that someone who thinks they are smart writes in on a white board and asks applicants to solve it. As if these trick questions some how give insight into ones ability to solve real world problems. These are exactly the kind of obscure fringes of a languadge that an interviewer with an ego loves. When they reality is whether one can solve it or not, amounts to a hi…
Great, then you know who not to work for. I agree that 'magic code' and obfuscation is pretty much ego stroking, but this doesn't seem like a good argument against the whole idea of using weakly typed languages.
Earlier quoted context omitted.
I have been in the industry for 16 years and have some pretty big code bases, in a variety of languages, under my belt (not trying to brag just setting the back-story). In thinking back, I cannot recall a single instance where any member of my team was bitten by an accidental conversion or a type safety issue. I have been fortunate to work with some good people, but some of them where average in their ability to actu…
I spent much of a week tracking down a bug in a Clojure program where primitive false was being sent through a network, and read back in as boxed false. It looked right when printed out, yet somehow the wrong branch of an if-statement was being taken. This was in a program under 2000 lines, in my first semester of college, before I had ever held a full-time programming job. Most people are not trained to notice these…
https://gist.github.com/1531201
It depends on underscore.js for the functional bits.
This is the reason I prefer strongly typed languages. Allowing developers to play fast and loose with data types only leads to less maintainability down the road and makes code difficult to read.
No it's not. This is an argument against poor management, not any particular programming language feature. If you have someone writing code like this in production you have a management problem. Review code, use and create clearly defined code standards, use validators, use "strict" mode, and most of all use your brain. A bad craftsman always blames their tools.
And sometime smart people tend to think they're invincible/bullet-proof. Not too many people have high-level discipline. And those that have high-level discipline tend to be shunned by "hackers" because "hackers" hate "processes". They just want to write fun code.
Hence the circle of evil.
Earlier quoted context omitted.
Clever, but not as surprising... (null,'cool',false,NaN,4) evaluates to the last expression - 4 Array(4) creates an array with 4 elements. Array(4).toString() = ",,,"
You describe that as "not surprising"? Yikes.
Unsurprisingly, JavaScript is its own language.
Reminds me of the J programming language
(Surely no other university teaches that language besides mine, right?)
Earlier quoted context omitted.
I spent much of a week tracking down a bug in a Clojure program where primitive false was being sent through a network, and read back in as boxed false. It looked right when printed out, yet somehow the wrong branch of an if-statement was being taken. This was in a program under 2000 lines, in my first semester of college, before I had ever held a full-time programming job. Most people are not trained to notice these…
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…
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. More likely, it's because you don't need to manufacture a new class every time you want a one-line handler.
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?