4 ms·

> Other languages, like JavaScript, are weakly typed, which means that the programmer doesn’t have to worry about such piffling minutiae; you can just write som

by sjs 15y ago

> Other languages, like JavaScript, are weakly typed, which means that the programmer doesn’t have to worry about such piffling minutiae; you can just write some code and let the compiler do the heavy lifting. JavaScript isn't weakly typed, you can't for example "cast" a number to a string. There is automatic coercion but that's a different thing. I think he means dynamically typed in this case, that or duck typing. > Type inference fills in the gap between strong and weak typing so that you can still write sloppy code, but reap some of the speed boost. I don't even know what to say about this. Following this faulty logic might lead one to believe that Haskell has type inference to make all that sloppy Haskell code perform well. Type inference doesn't have anything to do with strong and weak typing, it has to do with manifest and implicit (or inherent) typing.

m0th87 15y ago
Automatic coercion is a part of weak typing [1], and JavaScript certainly is weakly typed ([2], first line). If you define the ability to cast as weak typing, then even C++ would be so. Obviously this definition does not hold. I don't get how the type inference remark is faulty logic either. Haskell is orthogonal because it is statically typed, but type inference when applied to dynamically typed languages certainly can provide a performance boost. 1: http://en.wikipedia.org/wiki/Weak_typing http://en.wikipedia.org/wiki/Weak_typing 2: http://en.wikipedia.org/wiki/JavaScript http://en.wikipedia.org/wiki/JavaScript
- randomdata 15y ago
  > If you define the ability to cast as weak typing, then even C++ would be so. Which is funny because your first link states: "In C++, a weakly typed language, you can cast memory to any type freely as long as you do so explicitly." I'm pretty sure the last time I read that article it said that there is no generally accepted definition of weak typing. This discussion seems to echo that.
  - nickknw 15y ago
    > I'm pretty sure the last time I read that article it said that there is no generally accepted definition of weak typing. This discussion seems to echo that. Agreed. There ARE definitions but they aren't terribly specific, useful, or even very consistent. Funnily enough, the wikipedia article on strong typing includes C and C++ as an example of strong typing. In this case anyway, I think it's clear that the author was really talking about the static vs dynamic distinction, and should have used those terms instead: > Some languages are strongly typed, which means that the programmer must define the type of every class, function, and variable that he uses; tiresome, but it can have big pay-offs in terms of overall speed. Other languages, like JavaScript, are weakly typed, which means that the programmer doesn’t have to worry about such piffling minutiae; you can just write some code and let the compiler do the heavy lifting.
    - chc 15y ago
      Funnily enough, that definition (whether applied to static or strong typing) would exclude Haskell, one of the most strongly and statically typed languages known to man.
      - nickknw 15y ago
        Yeah it would, good catch. So to be more accurate, he was comparing explicit static typing with dynamic typing.
    - DasIch 15y ago
      Whether or not a language is strongly typed has no effect on whether the programmer has to define the type of everything. You defined what a statically typed language is, not what a strongly typed language is. In fact if a language is strongly typed not defining anything will not necessarily have an impact on speed because it is possible to infer types statically at compile time like GHC does for Haskell.
      - nickknw 15y ago
        I didn't attempt to define anything in my post, although I did quote from the article. In other words: I think we agree.
- jrockway 15y ago
  What? C++ is weakly typed; it has one type called "big block of memory". Everything on top of that is just an annotation that the compiler uses to generate code, and the compiler will not do any checking to ensure that what it's generating makes sense.
varikin 15y ago
That description was meant for those who don't understand programming, weak & strong typing, & type inference. It is a good enough description for those who don't know and will never care to know more. I understand the importance of defining thing correctly, but does the average person need to care or worry about the difference between strongly/weakly typed & statically/dynamically typed?
- sjs 15y ago
  Probably not, that's certainly a fair point. But in that case why go into it at all? Just say it's magic "faster" juice (and don't post it to HN). One thing I'm curious about as a developer is how this is different than the type inference that SpiderMonkey already did. The JIT certainly didn't represent numbers as strings in memory or something equally silly prior to this new type inference. Is it better inference that optimizes away boxing or can optimize across function calls or something? (Just musing "out loud", I don't expect answers to these questions here on HN.)
Dn_Ab 15y ago
Agree. Can one say Mediumly Typed? To me a strongly typed language is very stern - you trade some slight annoyance for some slight sanity checks. For example strong typing would not let you say 5 + 5.0 because float <> int. >> Type inference fills in the gap between strong and weak typing so that you can still write sloppy code, but reap some of the speed boost. >I don't even know what to say about this. Following this faulty logic might lead one to believe that Haskell has type inference to make all that sloppy Haskell code perform well. Type inference doesn't have anything to do with strong and weak typing, it has to do with manifest and implicit (or inherent) typing. I'm not sure even manifest typing would be the correct term as he mentions performance. So it looks like he is looking for static vs dynamic. Dynamic typing but inferring types statically where possible. It is interesting that type inference in a statically typed language leads to less noise and type inference in a dynamic language leads to some speed boost.

by sjs 15y ago

m0th87 15y ago

Automatic coercion is a part of weak typing [1], and JavaScript certainly is weakly typed ([2], first line). If you define the ability to cast as weak typing, then even C++ would be so. Obviously this definition does not hold. I don't get how the type inference remark is faulty logic either. Haskell is orthogonal because it is statically typed, but type inference when applied to dynamically typed languages certainly can provide a performance boost. 1: http://en.wikipedia.org/wiki/Weak_typing http://en.wikipedia.org/wiki/Weak_typing 2: http://en.wikipedia.org/wiki/JavaScript http://en.wikipedia.org/wiki/JavaScript

randomdata 15y ago
> If you define the ability to cast as weak typing, then even C++ would be so. Which is funny because your first link states: "In C++, a weakly typed language, you can cast memory to any type freely as long as you do so explicitly." I'm pretty sure the last time I read that article it said that there is no generally accepted definition of weak typing. This discussion seems to echo that.
- nickknw 15y ago
  > I'm pretty sure the last time I read that article it said that there is no generally accepted definition of weak typing. This discussion seems to echo that. Agreed. There ARE definitions but they aren't terribly specific, useful, or even very consistent. Funnily enough, the wikipedia article on strong typing includes C and C++ as an example of strong typing. In this case anyway, I think it's clear that the author was really talking about the static vs dynamic distinction, and should have used those terms instead: > Some languages are strongly typed, which means that the programmer must define the type of every class, function, and variable that he uses; tiresome, but it can have big pay-offs in terms of overall speed. Other languages, like JavaScript, are weakly typed, which means that the programmer doesn’t have to worry about such piffling minutiae; you can just write some code and let the compiler do the heavy lifting.
  - chc 15y ago
    Funnily enough, that definition (whether applied to static or strong typing) would exclude Haskell, one of the most strongly and statically typed languages known to man.
    - nickknw 15y ago
      Yeah it would, good catch. So to be more accurate, he was comparing explicit static typing with dynamic typing.
  - DasIch 15y ago
    Whether or not a language is strongly typed has no effect on whether the programmer has to define the type of everything. You defined what a statically typed language is, not what a strongly typed language is. In fact if a language is strongly typed not defining anything will not necessarily have an impact on speed because it is possible to infer types statically at compile time like GHC does for Haskell.
    - nickknw 15y ago
      I didn't attempt to define anything in my post, although I did quote from the article. In other words: I think we agree.
jrockway 15y ago
What? C++ is weakly typed; it has one type called "big block of memory". Everything on top of that is just an annotation that the compiler uses to generate code, and the compiler will not do any checking to ensure that what it's generating makes sense.

varikin 15y ago

That description was meant for those who don't understand programming, weak & strong typing, & type inference. It is a good enough description for those who don't know and will never care to know more. I understand the importance of defining thing correctly, but does the average person need to care or worry about the difference between strongly/weakly typed & statically/dynamically typed?

sjs 15y ago
Probably not, that's certainly a fair point. But in that case why go into it at all? Just say it's magic "faster" juice (and don't post it to HN). One thing I'm curious about as a developer is how this is different than the type inference that SpiderMonkey already did. The JIT certainly didn't represent numbers as strings in memory or something equally silly prior to this new type inference. Is it better inference that optimizes away boxing or can optimize across function calls or something? (Just musing "out loud", I don't expect answers to these questions here on HN.)

Dn_Ab 15y ago

Agree. Can one say Mediumly Typed? To me a strongly typed language is very stern - you trade some slight annoyance for some slight sanity checks. For example strong typing would not let you say 5 + 5.0 because float <> int. >> Type inference fills in the gap between strong and weak typing so that you can still write sloppy code, but reap some of the speed boost. >I don't even know what to say about this. Following this faulty logic might lead one to believe that Haskell has type inference to make all that sloppy Haskell code perform well. Type inference doesn't have anything to do with strong and weak typing, it has to do with manifest and implicit (or inherent) typing. I'm not sure even manifest typing would be the correct term as he mentions performance. So it looks like he is looking for static vs dynamic. Dynamic typing but inferring types statically where possible. It is interesting that type inference in a statically typed language leads to less noise and type inference in a dynamic language leads to some speed boost.