|There's more than one way to do things|
First off, I like the idea of being able to write micro-controller code in Perl, or as is more likely, having my Perl code converted to the subset of C(++) that is then compiled and uploaded to whatever micro-controller I happen to be using.
That said, and with the Yun being a retired product (and not so many affordable alternatives that I have found on the market), it may be a hard sell to get the time and effort put into something like this.
I 'mess around' with various micro-controllers, mostly the Uno, Feather, Trinket Pro, and the radio (RFM) capable modules. From a cost perspective as well as a 'division of functionality' perspective, I have found that an RPi connected to a micro-controller via USB does a fine job.
The RPi does the processing of incoming data, both receiving the data(Serial), processing it(using whatever I need from CPANm or whatever), and displaying it (apache2). This leaves all the more 'bloated' work to the RPi. The micro-processor just does what it is good at: and that is handle IO through the digital and analog ports, basic data manipulation(mostly math conversions like tempC to tempF or analog value to other measurement unit) along with some data organization such as formatting the output to JSON for transfer to the RPi.
For the money, it seems the most reliable approach right now. I have at times added the web-server to an Uno or Mega which works fine, but find that the overhead is really not worth the effort. It cuts down on the real power of the micro-controller, which is in my mind its ability to gather a lot of data very fast.
I really would like the ability to write Perl and have good controller code end up on the micro-controller. That would be a great advantage to me as I am no C(++) programmer. That tied in with the fact that the documentation of the libraries for some of the C code that has been written for the micro's just plain sucks, makes the idea of Perl for MC's really attractive.
I am no C programmer, don't really understand compilers in any meaningful way either. So my 'picture' of this is something like
I should probably clarify here that I have avoided using the RPi as a micro-controller, though I know that is often done via GPIO etc... . This is again, because of my bias of 'division of function', where I think of the RPi as a nice Linux box and the micro as a pure data-acquisition and device/sensor controller.
<Hope this is not too far off-topic...
...the majority is always wrong, and always the last to know about it...
A solution is nothing more than a clearly stated problem...