DeviceScript – TypeScript for Tiny IoT Devices

Post by TOGoS » Fri, Jun 09, 2023, 1:28 PM UTC

esrauch wrote: post #46

LudwigNagasena wrote: post #42

Earlier quoted context omitted.

What exactly do you miss? JS has built-in reflection, eg `typeof instance`, `instance.constructor.name`. Even multiple dispatch can be hacked together if you really need it, eg there is a library @arrows/multimethod.

Those don't change that the type system is structural; the type system is actually not fully safe if you use the things you mention, eg: class Dog { woof(){} } class Cat { meow(){} } function f(a: Dog|Cat) { if (a instanceof Dog) { a.woof() } else { a.meow() } } let dogish = {woof: ()=>{}} f(dogish) This compiles because dogish is structurally a dog, the type system allows instanceof to narrow the type but "dogish in…

  interface Dog { typeName: "Dog"; woof():void }
  interface Cat { typeName: "Cat"; meow():void }
  
  function isDog(a:Dog|Cat) : a is Dog {
    return a.typeName == "Dog"; // Some casting may be required here
  }
  
  function f(a: Dog|Cat) {
    if (isDog(a)) a.woof();
    else a.meow();
  }
  
  let dogish : Dog = {typeName:"Dog", woof: ()=>{ console.out("Woof this is Dog")}};
  f(dogish);

Post by claytongulick » Fri, Jun 09, 2023, 1:36 PM UTC

jononor wrote: post #60

TheLoafOfBread wrote: post #43

Earlier quoted context omitted.

I agree, this will mostly go nowhere. Sure when somebody will prepare you DeviceScript environment for *your* board, then you are good to go. But in 99% of cases, you will get hardware in front of you which almost certainly is not supported by DeviceScript. And now without intimate knowledge of C, how are you going to expose interfaces of that particular hardware, so you can work with those interfaces in DeviceScript…

The target audience for such runtimes are teams with general software engineer skills, and less embedded skills, and little hardware skills. They are likely to weight software support (including drivers) very heavily when selecting hardware. This reduces how often the scenario you describe will come up, compared to traditional hardware development.

Post by TheLoafOfBread » Fri, Jun 09, 2023, 1:39 PM UTC

claytongulick wrote: post #71

TheLoafOfBread wrote: post #58

Earlier quoted context omitted.

Well that's valid as long as you don't get exception in underlying C driver. Now you are solving two possible problems - error in your script or error in the driver. Good luck debugging that without proper debugging probe.

That's been the argument against higher level languages since punch cards. Sure, there may be problems, yet somehow the internet runs. Coding in asm is fun, and a good skill to have for when you need it - but most of the time, you don't.

Post by bri3d » Fri, Jun 09, 2023, 1:48 PM UTC

nicce wrote: post #73

lioeters wrote: post #67

Earlier quoted context omitted.

3 is a big one, I think. Using an interpreted language speeds up the development cycle to prototype, change, release, and iterate. And for some purposes it's fast and small enough, that the trade-off is worth it.

This makes a lot of sense. However, it makes me wonder how big is the new attack surface for remote upgrades/updates. You need to implement a safe updater (with remote protocols) on VM level. And I guess you can never upgrade the VM itself, or if you can, it adds some extra complexity, or physical access. There also need to be some kind of signature validation for every release, which means that device needs to perfo…

Post by biosboiii » Fri, Jun 09, 2023, 1:52 PM UTC