Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DeviceScript – TypeScript for Tiny IoT Devices

github.com

Post reply on HN
Print view View original

111–120 of 160 posts

Re: DeviceScript – TypeScript for Tiny IoT Devices

#111

Post by HeyLaughingBoy »

horsawlarway wrote: post #68
TheLoafOfBread wrote: post #57

Earlier quoted context omitted.

I am just showing you that DeviceScript/MicroPython/LUA/any other scripting language will expect from the user to know lot of C in order to be able to use its board unless they want to just run it without any input/output of data. But users want to use the scripting language because they don't know C. The whole flow is Catch-22.

I might have agreed 10 to 15 years ago when arduino was brand new and almost everything was custom. These days... eh - pretty hard disagree with everything you've said. Do some folks still need to know the ins & outs of the device? Sure. Will this work on every device? Nope. Does that matter for the success of this project? Not a fucking bit. Honestly - this looks a lot like Electron in my opinion: It gives companies…

> The flow is: I'm trying to do a thing that's only marginally related to the embedded device

It's too bad that this comment is buried so deep: it should be at top level. More and more often, embedded work is just like this -- the business logic is far more important than the fact that it's running on an "embedded device." And in those cases, having programmers who understand modern software development at a high level is far more useful than having programmers who are expert in C and comfortable sitting down with multiple chip datasheets for a week, writing peripheral drivers.

Re: DeviceScript – TypeScript for Tiny IoT Devices

#112

Post by nanidin »

nicce wrote: post #17

Is the only reason for this to make it possible for web developers or people who know TypeScript to write code for IoT Devices? To fill the lack of experienced low level programmers? Because as language alone, I don't see a reason why I should I ever use this if I am not familiar with TypeScript already.

I started my career in C/C++ and embedded. Every time I go back to work on embedded stuff for fun, it's like going back in time and losing all of the nice things that come with languages like TypeScript or JS. Suddenly things like associative arrays, maps, sets, lists, vectors - all require much more mental overhead to deal with and ultimately get in the way of what I actually want to be doing.

Re: DeviceScript – TypeScript for Tiny IoT Devices

#113

Post by onimishra »

danielEM wrote: post #105

My personal opinion is that good typescript to C transpiller would do a way better job, tons of microcontrollers supported out of the box. I would be also happy to use it for desktop. With some tricks it could even support references and additional numeric data types (u8, i8 ... ) without breaking any syntax

Does such a thing exist? I would love something like that, but is it even feasible? Isn’t there a lot more you need to be aware of, to make a translation of say TS’s objects into C?

Re: DeviceScript – TypeScript for Tiny IoT Devices

#114

Post by riceart »

jqpabc123 wrote: post #48
nicce wrote: post #17

Is the only reason for this to make it possible for web developers or people who know TypeScript to write code for IoT Devices? To fill the lack of experienced low level programmers? Because as language alone, I don't see a reason why I should I ever use this if I am not familiar with TypeScript already.

There are a number of reasons to do this. This sort of setup typically has the VM runtime flashed into the microprocessor's program space with the interpreted byte code stored in data space --- either internal or external. 1) It is obviously not as fast as native but it is fast enough for a lot of applications. In embedded work, you don't get extra credit for being faster than necessary. Speed critical functions like…

> In embedded work, you don't get extra credit for being faster than necessary.

You absolutely do when you can cut power requirements and get by with cheaper CPU/hardware. I ran a whole consulting business redesigning poorly designed devices and redoing firmware for cost reduction. How does one decide “necessary”, what is necessary in the short and long term are often not the same.

Re: DeviceScript – TypeScript for Tiny IoT Devices

#115

Post by FpUser »

jqpabc123 wrote: post #48
nicce wrote: post #17

Is the only reason for this to make it possible for web developers or people who know TypeScript to write code for IoT Devices? To fill the lack of experienced low level programmers? Because as language alone, I don't see a reason why I should I ever use this if I am not familiar with TypeScript already.

There are a number of reasons to do this. This sort of setup typically has the VM runtime flashed into the microprocessor's program space with the interpreted byte code stored in data space --- either internal or external. 1) It is obviously not as fast as native but it is fast enough for a lot of applications. In embedded work, you don't get extra credit for being faster than necessary. Speed critical functions like…

>"In embedded work, you don't get extra credit for being faster than necessary"

You do get credit for using the cheapest and lowest cost MCU for the task which directly depends on performance of the code. In case of battery operated devices it is even more important.

Re: DeviceScript – TypeScript for Tiny IoT Devices

#116

Post by littlecranky67 »

suprfnk wrote: post #32
geijoenr wrote: post #20

Is really hard for me to understand how running an VM on a resource constrained device has any benefit. There is a reason why those devices run using very lightweight "OS"s like FreeRTOS and Embedded C. Why the constant obsession to apply a technology designed for a specific purpose everywhere else, even when it doesn't make sense?

Easy: because TypeScript or Python are way easier to learn than C. Learning C is a long, arduous, uphill battle against arcane error messages and undefined behaviour. Unless you have a background in C/C++ already, most people can probably get up and running with something like this way, way faster.

Good luck understanding things like `if(!!!c) { ... }` or why a line-break after a return statement matters in JavaScript/TypeScipt ;) JS has its own footguns and legacy baggage.

Re: DeviceScript – TypeScript for Tiny IoT Devices

#117

Post by milanove »

delfinom wrote: post #64
nicce wrote: post #17

Is the only reason for this to make it possible for web developers or people who know TypeScript to write code for IoT Devices? To fill the lack of experienced low level programmers? Because as language alone, I don't see a reason why I should I ever use this if I am not familiar with TypeScript already.

>Is the only reason for this to make it possible for web developers or people who know TypeScript to write code for IoT Devices? To fill the lack of experienced low level programmers? Which is funny because there's no lack of low level programmers in my experience. Companies just try and pay Embedded Systems Engineers and Electrical Engineers dirt compared to "Software Engineers". In the same part of NY where SWE bas…

I wonder if many of these lowball salary job postings could just be companies applying for an employee's greencard through the PERM system. IIUC, for PERM, the applicant's employer is required to put out a job posting for at least 10 days to show nobody else can do the job their employee/greencard applicant does. The salary they list in the posting must be at least the minimum wage dictated by the Department of Labor for the role.

However, I suspect that the company making the ad will just list the lowest possible salary in the posting to deter real applicants from applying, hence making the greencard applications smoother.

However, don't quote me on this, since this is just my very vague knowledge on how greencard applications work. Somebody else here who knows more about this topic, please chime in to let me know if this is true.

Re: DeviceScript – TypeScript for Tiny IoT Devices

#118

Post by afiori »

onimishra wrote: post #113
danielEM wrote: post #105

My personal opinion is that good typescript to C transpiller would do a way better job, tons of microcontrollers supported out of the box. I would be also happy to use it for desktop. With some tricks it could even support references and additional numeric data types (u8, i8 ... ) without breaking any syntax

Does such a thing exist? I would love something like that, but is it even feasible? Isn’t there a lot more you need to be aware of, to make a translation of say TS’s objects into C?

They would likely have to severely restrict the range of supported types, for example `window` is likely impossible to compile meaningfully.

Re: DeviceScript – TypeScript for Tiny IoT Devices

#119

Post by simlevesque »

danielEM wrote: post #105

My personal opinion is that good typescript to C transpiller would do a way better job, tons of microcontrollers supported out of the box. I would be also happy to use it for desktop. With some tricks it could even support references and additional numeric data types (u8, i8 ... ) without breaking any syntax

Pure Typescript supporting all of the Ecmascript spec would have to output a lot of C to get the same results.

Re: DeviceScript – TypeScript for Tiny IoT Devices

#120

Post by black_puppydog »

TOGoS wrote: post #72
esrauch wrote: post #46

Earlier quoted context omitted.

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…

Yeah don't do that. :) Do this: 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); The neat thing about TypeScr…

This is pretty much what I ended up with (with a string const generic type param actually) but now I have this extra implementation detail that I need to add/remove at every service boundary. It just makes every serialization/deserialization more complicated and generally adds cruft.
Post reply on HN