6 ms·

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

by nicce 3y ago

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.

iamflimflam1 3y ago
The same could be said for MicroPython or CircuiyPython. I suspect the target audience is more on the hobbyist/non embedded programmer side of things.
- mananaysiempre 3y ago
  The thing is, if you want to poke at a device interactively, your options are either Forth or (if the system is beefy enough) one of these scripting language ports; tethered C interpreters are not precisely commonplace. And while I love Forth to bits, most people will probably go the scripting-language route.
  - pjmlp 3y ago
    A whole 8 bit computing generation was able to jump into computing thanks to scripting.
- mmoskal 3y ago
  There are some differences, but broadly correct (eg., the program is precompiled and the experience is definitely the best in VSCode; plus of course different language). However, I heard of uPython being used in production deployments, though maybe not in millions of units. (I'm working on DeviceScript)
iampims 3y ago
it's not C, so that's a great step towards making programming IoT more accessible.
- TheLoafOfBread 3y ago
  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.
  - claytongulick 3y ago
    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.
    - TheLoafOfBread 3y ago
      The problem is not higher level language. The problem is that you are essentially running dual-stack firmware with twice as complexity and twice as problems. And C vs assembly comparison is irrelevant. You are running assembly represented by C, but not interpreting C in assembly written VM.
      - claytongulick 3y ago
        Then I guess you'd better avoid any sort of embedded libc implementation too. Or fadecandy, or any external library. I've been through hell in embedded systems land debugging chipmaker-supplied C compiler problems. Should I just write it all in asm then? I've certainly made that choice for some projects. The point is, at some point you just want to get things done and you have to trust your tool chain.
        TheLoafOfBread 3y ago
        You are completely missing my point. When I have C code and compile it, I will have opcodes which processor can run. All my bugs are going to happen only in C code and I can debug those using one debugging probe. When I have embedded scripting, then I have C code which represents my VM and I have also scripts. Then I am hunting for a bug in C code and script itself. I need two debugging stacks to get the problem solved. Sure you can say that I can run scripts on my PC, but what if everything works on my PC, but the moment I will load it on the target, script will crash? Then without proper debugger I am screwed.
jqpabc123 3y ago
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 communications are mostly handled at native speed by the VM. 2) Code size. Interpreted byte code (minus the VM) can be smaller and less redundant than native. And by adding cheap external storage, code can easily expand beyond the native program space of the micro. 3) Easy remote updates. Byte code can be received and stored without making changes to the micro's program code (no re-flashing required). It's possible to fix bugs and make changes or even completely repurpose the hardware from afar.
- mikepurvis 3y ago
  The debuggability is also far better I expect, as a person who has spent hours tracing some crash deep in LwIP because of a bad flag or wrong interrupt priority.
  - girvo 3y ago
    LwIP (especially with Simcom’s SIM7000 via PPPoS underneath it) gives me PTSD. Even with decent JTAG debugging, it’s such a pain.
    - mikepurvis 3y ago
      I think it's especially scary when most devkits come with it pre-integrated by the manufacturer, but the quality of that integration varied widely. My experience is nearly a decade out of date at this point, but when I was last going Cortex M3 stuff, I found that the integration of TI/Stellaris was excellent, and the integration on STM32 was one landmine after another— and the same held true for the USB stacks, even for stuff that should have been dirt simple like just emulating a serial port.
      - 3y ago
benniomars 3y ago
[flagged]
- delfinom 3y ago
  TypeScript/Javascript are the modern PHP or Java of the world. It's something that people get pushed into it from school and their "first intro to programming", they often succeed through the meme of the language. But there's a subset that will struggle to actually be a "computer scientist" and pivot between languages and technologies in the long term.
- lillecarl 3y ago
  I on the other hand started my "programming life" with C++ (because I was interested in a project written in C++) then I went to C# semi-professionally, if I was doing web it'd be with TS because of the tooling, also types help me organize my brain, and the escape hatch into YOLO land is very low in TS considering it's compiled into JS mostly, so the typesystem allows for "any" and such while still restricting things that aren't prototypes anymore. Both C# and TS come "from the same author", so that might influence me a bit.
delfinom 3y ago
>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 base salaries are $160k+, they will offer $120k for the same years of experience to a EE/Embedded SWE. And these are both major companies (non-big tech) and small companies that will do this. Of course I also see those job postings for those specific companies last a long time here. There's one going for 3 years now for a many decades old small defense contractor that's even had their CTO directly reach out to me. Meanwhile I sit pretty in my actually respectable paying embedded job that I ain't jumping ship for a paycut.
- milanove 3y ago
  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.
- devmunchies 3y ago
  In my experience, a firmware engineer contractor is much more expensive than a web contractor. But that's probably just a contractor supply/demand thing vs full-time.
naikrovek 3y ago
TypeScript development on VScode is excellent (I'm told) so that would be a reason for this. Excellent tooling exists for you if your language is TypeScript, so maybe try putting TypeScript in more places.
- tentacleuno 3y ago
  It most certainly is. I've tried a lot of development solutions over the years, and always find myself coming back to VSCode. The TypeScript support is amazing.
nanidin 3y ago
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.

by nicce 3y ago

iamflimflam1 3y ago

The same could be said for MicroPython or CircuiyPython. I suspect the target audience is more on the hobbyist/non embedded programmer side of things.

mananaysiempre 3y ago
The thing is, if you want to poke at a device interactively, your options are either Forth or (if the system is beefy enough) one of these scripting language ports; tethered C interpreters are not precisely commonplace. And while I love Forth to bits, most people will probably go the scripting-language route.
- pjmlp 3y ago
  A whole 8 bit computing generation was able to jump into computing thanks to scripting.
mmoskal 3y ago
There are some differences, but broadly correct (eg., the program is precompiled and the experience is definitely the best in VSCode; plus of course different language). However, I heard of uPython being used in production deployments, though maybe not in millions of units. (I'm working on DeviceScript)

iampims 3y ago

it's not C, so that's a great step towards making programming IoT more accessible.

TheLoafOfBread 3y ago
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.
- claytongulick 3y ago
  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.
  - TheLoafOfBread 3y ago
    The problem is not higher level language. The problem is that you are essentially running dual-stack firmware with twice as complexity and twice as problems. And C vs assembly comparison is irrelevant. You are running assembly represented by C, but not interpreting C in assembly written VM.
    - claytongulick 3y ago
      Then I guess you'd better avoid any sort of embedded libc implementation too. Or fadecandy, or any external library. I've been through hell in embedded systems land debugging chipmaker-supplied C compiler problems. Should I just write it all in asm then? I've certainly made that choice for some projects. The point is, at some point you just want to get things done and you have to trust your tool chain.
      - TheLoafOfBread 3y ago
        You are completely missing my point. When I have C code and compile it, I will have opcodes which processor can run. All my bugs are going to happen only in C code and I can debug those using one debugging probe. When I have embedded scripting, then I have C code which represents my VM and I have also scripts. Then I am hunting for a bug in C code and script itself. I need two debugging stacks to get the problem solved. Sure you can say that I can run scripts on my PC, but what if everything works on my PC, but the moment I will load it on the target, script will crash? Then without proper debugger I am screwed.

jqpabc123 3y ago

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 communications are mostly handled at native speed by the VM. 2) Code size. Interpreted byte code (minus the VM) can be smaller and less redundant than native. And by adding cheap external storage, code can easily expand beyond the native program space of the micro. 3) Easy remote updates. Byte code can be received and stored without making changes to the micro's program code (no re-flashing required). It's possible to fix bugs and make changes or even completely repurpose the hardware from afar.

mikepurvis 3y ago
The debuggability is also far better I expect, as a person who has spent hours tracing some crash deep in LwIP because of a bad flag or wrong interrupt priority.
- girvo 3y ago
  LwIP (especially with Simcom’s SIM7000 via PPPoS underneath it) gives me PTSD. Even with decent JTAG debugging, it’s such a pain.
  - mikepurvis 3y ago
    I think it's especially scary when most devkits come with it pre-integrated by the manufacturer, but the quality of that integration varied widely. My experience is nearly a decade out of date at this point, but when I was last going Cortex M3 stuff, I found that the integration of TI/Stellaris was excellent, and the integration on STM32 was one landmine after another— and the same held true for the USB stacks, even for stuff that should have been dirt simple like just emulating a serial port.
    - 3y ago

benniomars 3y ago

[flagged]

delfinom 3y ago
TypeScript/Javascript are the modern PHP or Java of the world. It's something that people get pushed into it from school and their "first intro to programming", they often succeed through the meme of the language. But there's a subset that will struggle to actually be a "computer scientist" and pivot between languages and technologies in the long term.
lillecarl 3y ago
I on the other hand started my "programming life" with C++ (because I was interested in a project written in C++) then I went to C# semi-professionally, if I was doing web it'd be with TS because of the tooling, also types help me organize my brain, and the escape hatch into YOLO land is very low in TS considering it's compiled into JS mostly, so the typesystem allows for "any" and such while still restricting things that aren't prototypes anymore. Both C# and TS come "from the same author", so that might influence me a bit.

delfinom 3y ago

>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 base salaries are $160k+, they will offer $120k for the same years of experience to a EE/Embedded SWE. And these are both major companies (non-big tech) and small companies that will do this. Of course I also see those job postings for those specific companies last a long time here. There's one going for 3 years now for a many decades old small defense contractor that's even had their CTO directly reach out to me. Meanwhile I sit pretty in my actually respectable paying embedded job that I ain't jumping ship for a paycut.

milanove 3y ago
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.
devmunchies 3y ago
In my experience, a firmware engineer contractor is much more expensive than a web contractor. But that's probably just a contractor supply/demand thing vs full-time.

naikrovek 3y ago

TypeScript development on VScode is excellent (I'm told) so that would be a reason for this. Excellent tooling exists for you if your language is TypeScript, so maybe try putting TypeScript in more places.

tentacleuno 3y ago
It most certainly is. I've tried a lot of development solutions over the years, and always find myself coming back to VSCode. The TypeScript support is amazing.

nanidin 3y ago

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.