8 ms·

Your information is out of date. It does. Have a look at "typed arrays"

cbsmith 13y ago
"Typed arrays are available in WebKit as well. Chrome 7 includes support for ArrayBuffer, Float32Array, Int16Array, and Uint8Array. Chrome 9 and Firefox 15 add support for DataView objects. Internet Explorer 10 supports all types except Uint8ClampedArray and ArrayBuffer.prototype.slice." Oh, and look here: http://www.khronos.org/registry/typedarray/specs/latest/ http://www.khronos.org/registry/typedarray/specs/latest/ We have an "editor's draft", updated on July 2013, littered with "non-normative" sections, and not on the ECMA site. You can check out the language standard itself and searching for "typed arrays" there: http://www.ecma-international.org/publications/standards/Ecma-262.htm http://www.ecma-international.org/publications/standards/Ecm... So yeah... not standard.
- TheZenPsycho 13y ago
  They are in ES6 which will be standard any year now. If that's not good enough for you then I guess there's nothing stopping you from just writing anything you need in 6502 assembler.
  - cbsmith 13y ago
    How long do you think the list is of languages that didn't wait until revision 6 before adding support for working with bytes? or are you seriously trying to suggest that it has to either be JavaScript or 6502 assembler?! Do you think it is maybe possible that a language that had standard ways of working with bytes say within the first decade of popularizing it just might be better suited for talking to hardware?
    - TheZenPsycho 13y ago
      we are talking about a product that is designed to mimmick the node.JS api. Your point is about as irrelevant as it can be.
      - cbsmith 13y ago
        > we are talking about a product that is designed to mimmick the node.JS api. Your point is about as irrelevant as it can be. It is relevant. I'm questioning the wisdom of that design choice.
        TheZenPsycho 13y ago
        Okay, reading another one of your posts I think I've gained a tiny insight into what you're trying to get across. You have the assumption that "Talking to hardware" necessarily involves dealing directly with binary protocols. And javascript isn't good at that. (though it CAN do it, if pressed) And you're right on both counts. I think what you are missing though is that on a product like this, why wouldn't you do the binary protocol stuff in a C module and expose a nice easy api in the scripting language as is the usual practice? In the presentation it very much looks like that is exactly what they do.
        cbsmith 13y ago
        > You have the assumption that "Talking to hardware" necessarily involves dealing directly with binary protocols. I wouldn't say that it necessarily involves dealing directly with binary protocols, but the issue tends to come up. Particularly when talking with hardware that can't just easily be upgraded, you often find that even "text" based protocols might require some manipulation at the byte level in order to decode them successfully. But really, the binary protocol aspect was just a really obvious and simple example of the larger "square peg, round hole" aspect of using JavaScript for the task. Maybe JavaScript makes working with hardware more accessible than other choices, but I doubt it. > why wouldn't you do the binary protocol stuff in a C module and expose a nice easy api in the scripting language as is the usual practice? I'd argue once you've done that, you're done. The hard part about the "internet of things" is that devices generally don't have a nice clean API's, and that's what needs to change. Once you have a nice API, you can embed a JVM in their quite cheaply and then support almost any language web developers might want (including JavaScript), and quite cheaply and efficiently at that. Better still, just do a simple REST-ful interface and leave it to the developer to do whatever they want.
- nl 13y ago
  So yeah... not standard. Assuming they implement typed arrays in their implementation then your criticism goes away doesn't it?
  - cbsmith 13y ago
    No, not really. My point wasn't about a checkbox item on a feature chart. The point is the language has evolved for quite a long time in a direction very different from talking to hardware. Basic capabilities like the ability to work with bytes are a foundation that a lot of other constructs are built on top of, and adding it in late in the game doesn't undo all that came before it, or provide all that should be built on top of it. It's not that you can't do this kind of work with JavaScript (obviously you can). It's just that it seems like very bad fit (even if you ignore its history with browsers), when there were a lot of other choices that seem like they'd have made things easier for programmers getting started in this area.
    - nl 13y ago
      Is it really any worse than BASIC? And the BASIC Stamp was the choice of hardware for hobbyists for years before the Arduino took over.
      - cbsmith 13y ago
        Remember, the goal here is to try to make things better. ;-)
        TheZenPsycho 13y ago
        And your plan for making things better: Java. shudder
        cbsmith 13y ago
        That's not my plan. I just wouldn't have been surprised by the choice.
        13y ago

"Typed arrays are available in WebKit as well. Chrome 7 includes support for ArrayBuffer, Float32Array, Int16Array, and Uint8Array. Chrome 9 and Firefox 15 add support for DataView objects. Internet Explorer 10 supports all types except Uint8ClampedArray and ArrayBuffer.prototype.slice." Oh, and look here: http://www.khronos.org/registry/typedarray/specs/latest/ http://www.khronos.org/registry/typedarray/specs/latest/ We have an "editor's draft", updated on July 2013, littered with "non-normative" sections, and not on the ECMA site. You can check out the language standard itself and searching for "typed arrays" there: http://www.ecma-international.org/publications/standards/Ecma-262.htm http://www.ecma-international.org/publications/standards/Ecm... So yeah... not standard.

TheZenPsycho 13y ago
They are in ES6 which will be standard any year now. If that's not good enough for you then I guess there's nothing stopping you from just writing anything you need in 6502 assembler.
- cbsmith 13y ago
  How long do you think the list is of languages that didn't wait until revision 6 before adding support for working with bytes? or are you seriously trying to suggest that it has to either be JavaScript or 6502 assembler?! Do you think it is maybe possible that a language that had standard ways of working with bytes say within the first decade of popularizing it just might be better suited for talking to hardware?
  - TheZenPsycho 13y ago
    we are talking about a product that is designed to mimmick the node.JS api. Your point is about as irrelevant as it can be.
    - cbsmith 13y ago
      > we are talking about a product that is designed to mimmick the node.JS api. Your point is about as irrelevant as it can be. It is relevant. I'm questioning the wisdom of that design choice.
      - TheZenPsycho 13y ago
        Okay, reading another one of your posts I think I've gained a tiny insight into what you're trying to get across. You have the assumption that "Talking to hardware" necessarily involves dealing directly with binary protocols. And javascript isn't good at that. (though it CAN do it, if pressed) And you're right on both counts. I think what you are missing though is that on a product like this, why wouldn't you do the binary protocol stuff in a C module and expose a nice easy api in the scripting language as is the usual practice? In the presentation it very much looks like that is exactly what they do.
        cbsmith 13y ago
        > You have the assumption that "Talking to hardware" necessarily involves dealing directly with binary protocols. I wouldn't say that it necessarily involves dealing directly with binary protocols, but the issue tends to come up. Particularly when talking with hardware that can't just easily be upgraded, you often find that even "text" based protocols might require some manipulation at the byte level in order to decode them successfully. But really, the binary protocol aspect was just a really obvious and simple example of the larger "square peg, round hole" aspect of using JavaScript for the task. Maybe JavaScript makes working with hardware more accessible than other choices, but I doubt it. > why wouldn't you do the binary protocol stuff in a C module and expose a nice easy api in the scripting language as is the usual practice? I'd argue once you've done that, you're done. The hard part about the "internet of things" is that devices generally don't have a nice clean API's, and that's what needs to change. Once you have a nice API, you can embed a JVM in their quite cheaply and then support almost any language web developers might want (including JavaScript), and quite cheaply and efficiently at that. Better still, just do a simple REST-ful interface and leave it to the developer to do whatever they want.
nl 13y ago
So yeah... not standard. Assuming they implement typed arrays in their implementation then your criticism goes away doesn't it?
- cbsmith 13y ago
  No, not really. My point wasn't about a checkbox item on a feature chart. The point is the language has evolved for quite a long time in a direction very different from talking to hardware. Basic capabilities like the ability to work with bytes are a foundation that a lot of other constructs are built on top of, and adding it in late in the game doesn't undo all that came before it, or provide all that should be built on top of it. It's not that you can't do this kind of work with JavaScript (obviously you can). It's just that it seems like very bad fit (even if you ignore its history with browsers), when there were a lot of other choices that seem like they'd have made things easier for programmers getting started in this area.
  - nl 13y ago
    Is it really any worse than BASIC? And the BASIC Stamp was the choice of hardware for hobbyists for years before the Arduino took over.
    - cbsmith 13y ago
      Remember, the goal here is to try to make things better. ;-)
      - TheZenPsycho 13y ago
        And your plan for making things better: Java. shudder
        cbsmith 13y ago
        That's not my plan. I just wouldn't have been surprised by the choice.
        13y ago