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

Wrench Embedded Interpreter

northarc.com

Post reply on HN
Print view View original

11–20 of 20 posts

Re: Wrench Embedded Interpreter

#11

Post by tyingq »

elinnnn wrote: post #10
noelwelsh wrote: post #7

I feel that these languages represent an era of language design that we're leaving behind. I think the experience in industry is that things like ad-hoc type coercions, which are sold as being simple and intuitive, are anything but that. The "Wat Javascript" talk is a great example.

Yeah, I've never understood how people can find dynamic typing "simple and easy to use", types are wonderful for catching errors and documenting the code and makes refactoring much easier - I even avoid auto/var/type interference as much as possible because I like seeing what types things are.

Consider that for many, things like Perl and Python were alternatives to using C, where the type system didn't always do a lot to help you.

Re: Wrench Embedded Interpreter

#13

Post by galangalalgol »

elinnnn wrote: post #10
noelwelsh wrote: post #7

I feel that these languages represent an era of language design that we're leaving behind. I think the experience in industry is that things like ad-hoc type coercions, which are sold as being simple and intuitive, are anything but that. The "Wat Javascript" talk is a great example.

Yeah, I've never understood how people can find dynamic typing "simple and easy to use", types are wonderful for catching errors and documenting the code and makes refactoring much easier - I even avoid auto/var/type interference as much as possible because I like seeing what types things are.

Rather than avoid type inference in c++ by removing auto, I typically specify a type on the RHS in C++. I mostly do this because it isn't that unusual for the inferred type to be something I don't want, but still kind of works. Eigen's matrix evaluator types as an example.

I haven't bumped into this with rust, but I don't see any reason it couldn't be the case, it may just be luck or the culture. I don't specify types in rust unless cargo check tells me to, and vscode with rust analyzer happily annotates all the types if I want it to.

Re: Wrench Embedded Interpreter

#14

Post by sriku »

"structs are functions that preserve the stack frame" is a cute idea/perspective. It doesn't look like this view leads to anything distinguishable from the usual approach with constructors though. Any examples that might point out things you can do that you can't do with usual struct+constructor?

Re: Wrench Embedded Interpreter

#15

Post by mst »

nunobrito wrote: post #3
remexre wrote: post #2

Huh, didn't the best-forgotten BeanShell [0, 1] do a similar thing with the "structs are just another kind of function"? [0]: https://jcp.org/en/jsr/detail?id=274 [1]: http://beanshell.org/

Similar, yes. Albeit for different languages of course. From my review of available options earlier this year, Wrench is the one closest to C-like scripting which is great to writing apps on TF cards.

"TF cards" ?

Either I don't know the term or I'm undercaffeinated and my memory hasn't booted properly yet, either way please take pity on me and explain?

Re: Wrench Embedded Interpreter

#16

Post by tines »

sriku wrote: post #14

"structs are functions that preserve the stack frame" is a cute idea/perspective. It doesn't look like this view leads to anything distinguishable from the usual approach with constructors though. Any examples that might point out things you can do that you can't do with usual struct+constructor?

"Closures are the poor man's objects, and objects are the poor man's closures." [http://wiki.c2.com/?ClosuresAndObjectsAreEquivalent]

Re: Wrench Embedded Interpreter

#17

Post by skybrian »

You don't have to do it this way, but it looks like the code to be interpreted is normally compiled to bytecode stored in a constant in a C header. So it's all in flash anyway, and you'd update the flash the same way as changing C code.

If you're going to do that, why not generate C and skip the interpreter? Is it because bytecode is more compact than native code?

I guess there would still need to be a runtime to handle array memory garbage collection.

Re: Wrench Embedded Interpreter

#19

Post by nunobrito »

mst wrote: post #15
nunobrito wrote: post #3

Earlier quoted context omitted.

Similar, yes. Albeit for different languages of course. From my review of available options earlier this year, Wrench is the one closest to C-like scripting which is great to writing apps on TF cards.

"TF cards" ? Either I don't know the term or I'm undercaffeinated and my memory hasn't booted properly yet, either way please take pity on me and explain?

Sure. Albeit this might be my age showing up when using old terms.

Quoting wikipedia: "The microSD removable miniaturized Secure Digital flash memory cards were originally named T-Flash or TF, abbreviations of TransFlash. TransFlash and microSD cards are functionally identical allowing either to operate in devices made for the other."

https://en.wikipedia.org/wiki/SD_card

MicroSD is quite a long word so plenty of time is simple mentioned as TF.

Re: Wrench Embedded Interpreter

#20

Post by mst »

nunobrito wrote: post #19
mst wrote: post #15

Earlier quoted context omitted.

"TF cards" ? Either I don't know the term or I'm undercaffeinated and my memory hasn't booted properly yet, either way please take pity on me and explain?

Sure. Albeit this might be my age showing up when using old terms. Quoting wikipedia: "The microSD removable miniaturized Secure Digital flash memory cards were originally named T-Flash or TF, abbreviations of TransFlash. TransFlash and microSD cards are functionally identical allowing either to operate in devices made for the other." https://en.wikipedia.org/wiki/SD_card MicroSD is quite a long word so plenty of tim…

Thank you.
Post reply on HN