6 ms·

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 roa

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.

deleted 15y ago
[deleted]
raganwald 15y ago
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 values they are given. For example, the behaviour of the “+” infix operator in JavaScript could be replicated in any strongly typed language that has pattern matching: x:string + y:string -> concat(x,y) x:stringable + y:string -> concat(toString(x), y) x:string + y:stringable -> concat(x, toString(y)) x:numeric + y:numeric -> sum(x,y) ... I recall implicit conversion being one of the gotchas in C++. While its casts break strictly strong typing, a program with lots of implicit conversions can behave just about as mysteriously as the example JavaScript. Back in the day when I wrote C++ (by gaslight, after I rode my penny farthing to the office), any one-argument constructor was presumed to be an implicit conversion unless you provided the “explicit” keyword. UPDATE (and thanks to the hacker who pointed me in this direction): http://en.wikipedia.org/wiki/Strong_typing http://en.wikipedia.org/wiki/Strong_typing It seems that the expression “Strong typing” subsumes both the concept of static typing (variables and/or values do not change their types) and of coercion. (Along with other issues such as whether programmers can deliberately evade restrictions). If I were to rewrite my question, I would ask if this is a strong typing problem overall or just the subset of strong typing issues concerning coercion? So part of the issue with this code is implicit coercion, which is not “strong typing,” but the other is polymorphic operators like “+”, which are independent of strong vs. weak typing.
- deleted 15y ago
  [deleted]
  - deleted 15y ago
    [deleted]
- extension 15y ago
  Wikipedia has a good page on this subject. In a nutshell, "strong/weak" typing is not formally defined. Usually languages are called weakly typed when they allow a lot of implicit type coercion or just don't strictly enforce types. It's not at all unique to dynamically typed languages. C is pretty weakly typed, for example. And a static language could just as easily have a quirk like this JavaScript thing. http://en.wikipedia.org/wiki/Weak_typing http://en.wikipedia.org/wiki/Weak_typing Update to your update: Strong typing does not subsume static typing. Ruby, for example, is dynamic and quite strongly typed. You can't bypass the type system at all, and the only real coercion is to boolean, which follows a very simple rule.
  - kingkilr 15y ago
    I wrote an article where I tried to lay out the definitions of these terms: http://alexgaynor.net/2010/nov/19/programming-languages-terminology/ http://alexgaynor.net/2010/nov/19/programming-languages-term...
  - raganwald 15y ago
    While the phrases don’t seem to have strict definitions, by the Wikipedia description of Strong Typing ,there is an overlap with Static Typing: The mandatory requirement, by a language definition, of compile-time checks for type constraint violations. That is, the compiler ensures that operations only occur on operand types that are valid for the operation. However, that is also the definition of static typing, leading some experts to state: "Static typing is often confused with StrongTyping”... Fixed and invariable typing of data objects. The type of a given data object does not vary over that object's lifetime. For example, class instances may not have their class altered. http://en.wikipedia.org/wiki/Strong_typing http://en.wikipedia.org/wiki/Strong_typing I guess this is one of those things where the correct response to any claim about “Strong,” “Static,” “Weak,” or “Dynamic” typing is to ask the speaker what, specifically, he is thinking of. In this case, you and I are exploring the subject in some depth, but the person who originally used the phrase “Strongly Typed” is silent, so neither of us has any idea what he had in mind.
ramchip 15y ago
I don't see how this example justifies your position, though. Nobody will ever write "++[[]][+[]]+[+[]]" to mean "10" in anything but an obfuscated code contest.
- deleted 15y ago
  [deleted]
- kls 15y ago
  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 hill of beans as to whether one is a good JavaScript programer or not. In fact if they are using these fringe practices in their code base they are writing unmaintainable code, which makes them a less desirable developer.
  - Deltigre 15y ago
    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.
    - kls 15y ago
      No I was not arguing against weak typing, just taking the opportunity to highlight how these kind of questions are used. I have no issue with weak typing. I don't get too dogmatic about such viewpoints. My comment was rather an attempt to highlight where a lot of this type of trivia knowledge is used and misapplied.
dustingetz 15y ago
there's a time in the place for everything. static/dynamic typing is a trade off between short-term development pace and long term maintenance. strong/weak typing is a trade off between enforcing high-level constraints and, well, i'm not exactly sure, but (void*) is used all the time in baremetal C . ... that said, i've never read an opinion that weak-typing to the extent possible in javascript is a great idea.
- Darmani 15y ago
  void* is used in C to interact with the raw bytes. In some sense, the raw bytes are the only type in C. You can try to maintain a distinction between a struct RECT{int width; int height;} and a struct POINT{int x; int y;}, but it's perhaps more appropriate to think of that as documentation for the programmer than as an actual type system. As long as your code has poorly-behaved neighbors, the types offer no guarantees.
kls 15y ago
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 actually write code, yet we never had these issue. I find it hard to believe that my situation is unique and I think the type safety Strong/Weak argument is a little overblown, I just don't encounter it in real life and don't know many other developers that do.
- Darmani 15y ago
  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 kinds of problems, or the simple checks that can stop them from confusing a list of lists and a list of lists of lists. But if you take a step back and think hard about what's happening to your time, you'll find that many hours are sunk chasing problems that are, in many ways, simple. Having static checks is like always having someone to read code over your shoulder.
  - kls 15y ago
    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 development in my experience. That being said, I do prefer strong typed languages for middleware and server development, some will differ on that, but it is what I am comfortable with and it works for me.
    - 15y ago
rayiner 15y ago
This is a "Javascript has retarded semantics" problem, nothing more. This would never work in Lisp. Moreover, despite being a strongly-ish typed language, C++ has pretty ridiculous implicit conversion semantics, only statically rather than dynamically.
Tsagadai 15y ago
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.
- hello_moto 15y ago
  Definitely agree. Unfortunately the tools sometime make it easier to shoot yourself in the foot. No matter how smart you are. 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.
deleted 15y ago
[deleted]
mikeash 15y ago
This has nothing to do with playing fast and loose with data types, and everything to do with implicit conversions between data types. This code would work just as well in a fully statically typed language with the same conversion rules.

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.

deleted 15y ago

[deleted]

raganwald 15y ago

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 values they are given. For example, the behaviour of the “+” infix operator in JavaScript could be replicated in any strongly typed language that has pattern matching: x:string + y:string -> concat(x,y) x:stringable + y:string -> concat(toString(x), y) x:string + y:stringable -> concat(x, toString(y)) x:numeric + y:numeric -> sum(x,y) ... I recall implicit conversion being one of the gotchas in C++. While its casts break strictly strong typing, a program with lots of implicit conversions can behave just about as mysteriously as the example JavaScript. Back in the day when I wrote C++ (by gaslight, after I rode my penny farthing to the office), any one-argument constructor was presumed to be an implicit conversion unless you provided the “explicit” keyword. UPDATE (and thanks to the hacker who pointed me in this direction): http://en.wikipedia.org/wiki/Strong_typing http://en.wikipedia.org/wiki/Strong_typing It seems that the expression “Strong typing” subsumes both the concept of static typing (variables and/or values do not change their types) and of coercion. (Along with other issues such as whether programmers can deliberately evade restrictions). If I were to rewrite my question, I would ask if this is a strong typing problem overall or just the subset of strong typing issues concerning coercion? So part of the issue with this code is implicit coercion, which is not “strong typing,” but the other is polymorphic operators like “+”, which are independent of strong vs. weak typing.

deleted 15y ago
[deleted]
- deleted 15y ago
  [deleted]
extension 15y ago
Wikipedia has a good page on this subject. In a nutshell, "strong/weak" typing is not formally defined. Usually languages are called weakly typed when they allow a lot of implicit type coercion or just don't strictly enforce types. It's not at all unique to dynamically typed languages. C is pretty weakly typed, for example. And a static language could just as easily have a quirk like this JavaScript thing. http://en.wikipedia.org/wiki/Weak_typing http://en.wikipedia.org/wiki/Weak_typing Update to your update: Strong typing does not subsume static typing. Ruby, for example, is dynamic and quite strongly typed. You can't bypass the type system at all, and the only real coercion is to boolean, which follows a very simple rule.
- kingkilr 15y ago
  I wrote an article where I tried to lay out the definitions of these terms: http://alexgaynor.net/2010/nov/19/programming-languages-terminology/ http://alexgaynor.net/2010/nov/19/programming-languages-term...
- raganwald 15y ago
  While the phrases don’t seem to have strict definitions, by the Wikipedia description of Strong Typing ,there is an overlap with Static Typing: The mandatory requirement, by a language definition, of compile-time checks for type constraint violations. That is, the compiler ensures that operations only occur on operand types that are valid for the operation. However, that is also the definition of static typing, leading some experts to state: "Static typing is often confused with StrongTyping”... Fixed and invariable typing of data objects. The type of a given data object does not vary over that object's lifetime. For example, class instances may not have their class altered. http://en.wikipedia.org/wiki/Strong_typing http://en.wikipedia.org/wiki/Strong_typing I guess this is one of those things where the correct response to any claim about “Strong,” “Static,” “Weak,” or “Dynamic” typing is to ask the speaker what, specifically, he is thinking of. In this case, you and I are exploring the subject in some depth, but the person who originally used the phrase “Strongly Typed” is silent, so neither of us has any idea what he had in mind.

ramchip 15y ago

I don't see how this example justifies your position, though. Nobody will ever write "++[[]][+[]]+[+[]]" to mean "10" in anything but an obfuscated code contest.

deleted 15y ago
[deleted]
kls 15y ago
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 hill of beans as to whether one is a good JavaScript programer or not. In fact if they are using these fringe practices in their code base they are writing unmaintainable code, which makes them a less desirable developer.
- Deltigre 15y ago
  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.
  - kls 15y ago
    No I was not arguing against weak typing, just taking the opportunity to highlight how these kind of questions are used. I have no issue with weak typing. I don't get too dogmatic about such viewpoints. My comment was rather an attempt to highlight where a lot of this type of trivia knowledge is used and misapplied.

dustingetz 15y ago

there's a time in the place for everything. static/dynamic typing is a trade off between short-term development pace and long term maintenance. strong/weak typing is a trade off between enforcing high-level constraints and, well, i'm not exactly sure, but (void*) is used all the time in baremetal C . ... that said, i've never read an opinion that weak-typing to the extent possible in javascript is a great idea.

Darmani 15y ago
void* is used in C to interact with the raw bytes. In some sense, the raw bytes are the only type in C. You can try to maintain a distinction between a struct RECT{int width; int height;} and a struct POINT{int x; int y;}, but it's perhaps more appropriate to think of that as documentation for the programmer than as an actual type system. As long as your code has poorly-behaved neighbors, the types offer no guarantees.

kls 15y ago

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 actually write code, yet we never had these issue. I find it hard to believe that my situation is unique and I think the type safety Strong/Weak argument is a little overblown, I just don't encounter it in real life and don't know many other developers that do.

Darmani 15y ago
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 kinds of problems, or the simple checks that can stop them from confusing a list of lists and a list of lists of lists. But if you take a step back and think hard about what's happening to your time, you'll find that many hours are sunk chasing problems that are, in many ways, simple. Having static checks is like always having someone to read code over your shoulder.
- kls 15y ago
  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 development in my experience. That being said, I do prefer strong typed languages for middleware and server development, some will differ on that, but it is what I am comfortable with and it works for me.
  - 15y ago

rayiner 15y ago

This is a "Javascript has retarded semantics" problem, nothing more. This would never work in Lisp. Moreover, despite being a strongly-ish typed language, C++ has pretty ridiculous implicit conversion semantics, only statically rather than dynamically.

Tsagadai 15y ago

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.

hello_moto 15y ago
Definitely agree. Unfortunately the tools sometime make it easier to shoot yourself in the foot. No matter how smart you are. 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.

deleted 15y ago

[deleted]

mikeash 15y ago

This has nothing to do with playing fast and loose with data types, and everything to do with implicit conversions between data types. This code would work just as well in a fully statically typed language with the same conversion rules.