TLDR: Event-oriented scripting language "Daspel" with dynamic typing, targeting the Internet of Things. The syntax is inspired by C, JavaScript and Rust. The interpreter implemented in Rust, runs on RasPi 3 with sense hat. Author seems to regret dynamic typing. Rust Sense Hat bindings might be interesting: https://github.com/CodeGradox/Rust-Sense-Hat -- the PDF has links to all other project repositories on page 62.
> For this project it is assumed that IoT devices do not have an FPU [...] real in Daspel is a signed two’s-complement 32-bit fixed point number. It uses 16 bits to represent the integer part and 16 bits to represent the fractional part.
That makes sense from an implementation point of view, but it could require a real shift in thinking for programmers, do to the extremely limited range.
If you don't have an FPU, another option could be to use rationals - a pair of half-size integers, where the value is the ratio between them. Has any language tried that? It's sort of simple, but inefficient (because there are many representations for the same value, eg 2/1 and 4/2), and you need to calculate lots of GCDs to prevent overflow. On the other hand, it can exactly represent base-ten fractions, which might be handy.
an "IoT device" is still a computer, why does it need a new language? So I did RTFM and got to this part:
"There is always a possibility
that something were to go wrong with the program as it is sent to the
device. For example, it is not impossible that bits get flipped or that some
packets with the data are lost. The compiler would have to support a wide
range of different architectures. That said, this argument may be mute as
an interpreter must be able to run on different architectures."
Verifying a compiled executable with a checksum must outweight the bloat of shipping an interpreter with every (low power) device.
SO I stopped reading at that point.
> However, many of those tools require the user to know programming languages such as C, Python and JavaScript. Users who do not know much programming and who would like to tinker with IoT may find it challenging to work with those tools.
>
> In this thesis we’ll look at how to design a programming language targeted specifically at IoT. The language is targeted at amateur programmers with the goal to make it easy to program any IoT device.
I think the motivation for this language can be summarised in two key points:
1. It might be easier for novices to get started with IoT using a language designed specifically for it
2. The author needed to do something for master's thesis
BC BASIC is designed to write "little programs" by relatively inexperienced programmers. As such
- The IDE is small (Visual Studio is 10 Gig; mine entire thing is about 50 meg)
- The IDE includes tons of examples (similar to how the Arduino IDE has tons of examples) and there are fully explained examples in the manual
- There is direct support for writing CSV and JSON output. It will convert an array of data, for example, directly to a correctly formatted CSV line. You can read in CSV files, too.
- A number of common Bluetooth devices have built-in support. Using a TI SensorTag or a Puck.Js device is simple instead of being a maze of Bluetooth services and characteristics.
What I've found to be real winners for design:
Lots of examples is a real win
Being able to copy-and-paste is very nice. For example, when you paste most code into a modern email client, the quotes get changed to smart quotes. My language allows for smart-quotes, and so the language doesn't get mangled. More subtly, a minus sign will get changed to an em-dash or similar, and my language handles those, too
Direct support for CSV/JSON and common Bluetooth devices is a big win.
Not worrying about where files and projects go is a win. In my system, when you write a program, the IDE simply keeps track of it. It also uses Windows data roaming, so you write on one device and it's automatically sent to you other devices.
What isn't important is program speed. Yes, a company like GM might spend a couple hundred thousand making a language more efficient so they can buy a $0.24 device instead of a $0.25 device. At their scale, it makes a difference. For everyone else, the cost of programmer time vastly outweighs pretty much every other consideration.
Also not important are most of the language details. People who aren't full-time programmers will pretty much find all syntax to be weird and won't appreciate clever or subtle features.
There's a more embedded/low-power device friendly language called NesC that's embedded in a (mildly popular) distro called TinyOS. https://github.com/tinyos/nesc
The compiler for TinyOS produces whole-program-optimized, statically linked binaries, which alone is worth it to me.
Seriously. In the late 90s all the articles talked about how Java was going to enable us to talk to all of our appliances, and then it ended up being a web language.
I don't understand why we need a special language for IoT. RasPi is more powerful than computers which we had 20 years ago and we were fine using many language which we have today.
RasPi's are therefore already on the high end; there's a new generation of very low-power devices that use e.g. backscatter for communication, lasting years on a single AA battery.
I don't understand this kind of sentiment. Why not?
Its adoption will be roughly proportional to its usefulness. If it turns out not to be useful, it will go away and you won't have to think about it anymore.
Programmers often are too focused on textual programming languages, missing out the immense improvements in visual tools, making them production ready for complex domains(for example , the recent low-code tools trend for app/site development among enterprises. And yes the right visual tools can even scale to large complex programs well, maybe with 90% visual "code" and 10% textual "code").
And clearly, visual tools are much more accessible for the amateur developer and domain expert.
And if you want to learn about that field, and the future of much of programming(probably), i'm not sure HN is a good place to do so. I think Google will be much more helpful.
I haven't seen a graphical language that's well suited for "general purpose" programming yet, although there are certainly good examples for specific purposes. My experience with rolling my own (flowgrid.org): Too verbose, code entry too cumbersome compared to text -- even on touch devices...
Who says tools must be general purpose ? What's wrong with a set of domain specific tools(highly extensible with code) with a lot of advantages ,with some decent ways to tie them up(that might require code) ?
Isn't it similar to framework based programming ,which is most of programming ?
Those do exist, but like you said yourself, domain specific tooling. Can't extend that to general purpose (in this case, IoT). Closest thing in that sphere would be the Mindstorms editor (https://wcpsrobotics.files.wordpress.com/2014/10/programming...).
