4 ms·

> Prototyping and Scripting Engine > Micropython Moving to production (C/C++) or factoring out critical pieces to C/C++ is not trivial VS. > mJS - JavaScript

by grive 9y ago

> Prototyping and Scripting Engine > Micropython Moving to production (C/C++) or factoring out critical pieces to C/C++ is not trivial VS. > mJS - JavaScript engine for prototyping and C/C++ for production I don't know much about it, but from the surface it seems that the problem is exactly the same? What is the benefit of prototyping in JS instead of Python? In the end, either you refactor everything purely in C, or you use both in your production system. I see mJS does FFI to interface with other C routines. Why introduce a second language to your project? This seems like a huge overhead for no benefit (you're still expected to write C at some point). The language is only a subset of JS, so "not JS", so no ecosystem and new assumptions you have to redefine before getting serious with it? Is it just me who thinks it's a bad idea? Would someone be able to explain the advantage of going in this direction?

wiremine 9y ago
The advantage is time. Many (most?) embedded environments are overly difficult (IMHO), and/or proprietary. Also, even in a good environment, C/C++ typically requires more lines of code than dynamic languages like Python or JS. Therefore, the industry has been looking for ways to combat both the below par developer experience, and the development time. Samsung's Jerryscript [1] is another example. That said, I think these things are aspiration more than they are practical. [1] http://jerryscript.net/ http://jerryscript.net/ Note: Edited to clarify C++ vs. dynamic languages.
- grive 9y ago
  Sure, I think I see the reasoning behind: reduce the time to market for embedded products. But I'm mostly wondering the actualy benefit of choosing mJS instead of micropython to do so. It seems that both are capable of handling this problem, however mJS seems aiming at a compromise between JS and C, and my opinion on this is that it will introduce huge overheads on any projects. This mostly stems from my being wary of multi-language projects. The process involved in embedded platforms seems heavy enough as it is, no need to blur the lines further.
  - wiremine 9y ago
    > But I'm mostly wondering the actualy benefit of choosing mJS instead of micropython to do so I agree with your concern: to me Micropython seems like a much better choice. On the other hand, it's pretty limited to what hardware it runs on.
  - drozd 9y ago
    mJS allows you to use C/C++ SDK functions directly without writing a glue code - basically, you can prototype things quite fast with the libraries/drivers that do not have any scripting support yet.
    - unkown-unknowns 9y ago
      But why not make that for micropython instead of making a whole new language?
      - wiremine 9y ago
        Ideally you don't want to port the C/C++ over to Python: that's the value proposition of mJS, I think.
ntoll 9y ago
Speaking from experience, using MicroPython is trivial and often "good enough", as are implementing modules for MicroPython in C should they be needed (C isn't my first language by a long shot, but I managed to write a module for MicroPython with little problem). Also, MicroPython has pretty much all the features of core Python whereas mJS appears to have pretty much all the useful features of JS removed. Why not just use C instead of mJS? Finally, couching Mongoose in a way that criticises the efforts of others is a bit of a turn off for me. Give me positive reasons for using your product rather than bashing the people you believe are your competitors. The culture and community of a project is important - negativity such as this is a worrying signal.
- rk1987 9y ago
  Indeed, share the vision of the product instead and how does it add value to the existing ecosystem.
- askvictor 9y ago
  > Why not just use C instead of mJS? Perhaps mjs has a repl? Don't really know, but that would be the only real advantage imo.
drozd 9y ago
Fast prototyping is the answer. If you or some others are skilled in C/C++, you don't need JS. For others, having a simple way to prototype fast on the target hardware is a big benefit.
flavio81 9y ago
> Why introduce a second language to your project? This seems like a huge overhead for no benefit (you're still expected to write C at some point) If i was having an IoT company or start-up, i would make sure to hire proper engineers; the ones that have no problem with switching between Javascript, C, and Python, or learning them on the fly if needed. Seriosly, is this really a problem at all? It is obvious that it is quicker to prototype in Python or JS or whatever scripting language. While for real world usage you would also care about performance and efficiency issues which would better be solved by having more direct control over the bare-metal (C, even assembler.)
- grive 9y ago
  > Seriosly, is this really a problem at all? Yes. I write Python and C everyday. I am highly proficient in both. I would quickly withdraw from a project that mixes both in the same code base. I'd also be slightly alarmed to see someone claiming to be able to distinguish proper engineers and not being aware of the issue with multi-language projects :-) . My issue with multi-language project is that you introduce a lot of overhead to the process surrounding the code. The code-review / static analysis, build and test all requires an additional toolchain and associated best practices. It is already an issue with single-language projects to do this right, it quickly becomes a nightmare when you introduce an additional language. And that's without even considering the need of FFI integration or likewise, with possibly (preferably) framework to handle the generation of the interfaces, and thus the introduction of another dependency, a possible sub-par codebase with the associated bugs, and potentially very subtle bugs due to your objects not playing nice with the intermediate representation. I did it with a C++ / Java interface, never again. I would never greenlight such a project. This has nothing to do with the proficiency or the willingness to learn of your engineers.

by grive 9y ago

wiremine 9y ago

The advantage is time. Many (most?) embedded environments are overly difficult (IMHO), and/or proprietary. Also, even in a good environment, C/C++ typically requires more lines of code than dynamic languages like Python or JS. Therefore, the industry has been looking for ways to combat both the below par developer experience, and the development time. Samsung's Jerryscript [1] is another example. That said, I think these things are aspiration more than they are practical. [1] http://jerryscript.net/ http://jerryscript.net/ Note: Edited to clarify C++ vs. dynamic languages.

grive 9y ago
Sure, I think I see the reasoning behind: reduce the time to market for embedded products. But I'm mostly wondering the actualy benefit of choosing mJS instead of micropython to do so. It seems that both are capable of handling this problem, however mJS seems aiming at a compromise between JS and C, and my opinion on this is that it will introduce huge overheads on any projects. This mostly stems from my being wary of multi-language projects. The process involved in embedded platforms seems heavy enough as it is, no need to blur the lines further.
- wiremine 9y ago
  > But I'm mostly wondering the actualy benefit of choosing mJS instead of micropython to do so I agree with your concern: to me Micropython seems like a much better choice. On the other hand, it's pretty limited to what hardware it runs on.
- drozd 9y ago
  mJS allows you to use C/C++ SDK functions directly without writing a glue code - basically, you can prototype things quite fast with the libraries/drivers that do not have any scripting support yet.
  - unkown-unknowns 9y ago
    But why not make that for micropython instead of making a whole new language?
    - wiremine 9y ago
      Ideally you don't want to port the C/C++ over to Python: that's the value proposition of mJS, I think.

ntoll 9y ago

Speaking from experience, using MicroPython is trivial and often "good enough", as are implementing modules for MicroPython in C should they be needed (C isn't my first language by a long shot, but I managed to write a module for MicroPython with little problem). Also, MicroPython has pretty much all the features of core Python whereas mJS appears to have pretty much all the useful features of JS removed. Why not just use C instead of mJS? Finally, couching Mongoose in a way that criticises the efforts of others is a bit of a turn off for me. Give me positive reasons for using your product rather than bashing the people you believe are your competitors. The culture and community of a project is important - negativity such as this is a worrying signal.

rk1987 9y ago
Indeed, share the vision of the product instead and how does it add value to the existing ecosystem.
askvictor 9y ago
> Why not just use C instead of mJS? Perhaps mjs has a repl? Don't really know, but that would be the only real advantage imo.

drozd 9y ago

Fast prototyping is the answer. If you or some others are skilled in C/C++, you don't need JS. For others, having a simple way to prototype fast on the target hardware is a big benefit.

flavio81 9y ago

> Why introduce a second language to your project? This seems like a huge overhead for no benefit (you're still expected to write C at some point) If i was having an IoT company or start-up, i would make sure to hire proper engineers; the ones that have no problem with switching between Javascript, C, and Python, or learning them on the fly if needed. Seriosly, is this really a problem at all? It is obvious that it is quicker to prototype in Python or JS or whatever scripting language. While for real world usage you would also care about performance and efficiency issues which would better be solved by having more direct control over the bare-metal (C, even assembler.)

grive 9y ago
> Seriosly, is this really a problem at all? Yes. I write Python and C everyday. I am highly proficient in both. I would quickly withdraw from a project that mixes both in the same code base. I'd also be slightly alarmed to see someone claiming to be able to distinguish proper engineers and not being aware of the issue with multi-language projects :-) . My issue with multi-language project is that you introduce a lot of overhead to the process surrounding the code. The code-review / static analysis, build and test all requires an additional toolchain and associated best practices. It is already an issue with single-language projects to do this right, it quickly becomes a nightmare when you introduce an additional language. And that's without even considering the need of FFI integration or likewise, with possibly (preferably) framework to handle the generation of the interfaces, and thus the introduction of another dependency, a possible sub-par codebase with the associated bugs, and potentially very subtle bugs due to your objects not playing nice with the intermediate representation. I did it with a C++ / Java interface, never again. I would never greenlight such a project. This has nothing to do with the proficiency or the willingness to learn of your engineers.