> Hans...how about MicroPython or Ruby instead of "basic" ?...;-)
Yes, various people could make good arguments for all sorts of programming languages.?
In my former software development career?I never really minded what language the company required. Maybe I was unusual in this. I always thought once you have a programming mentality, it's more important the logical construction of the application, than particularly what programming language it's in.?
Remember?too that we are operating here on relatively small microcontrollers, in terms of the Flash memory available and RAM. It isn't trivial, neither in relation to developing it, nor the resource requirements on the hardware, to write a Virtual Machine and a Programming language and interface it to all the functions of the radio. It so happens that I had already done all that for U4B and I chose BASIC for several reasons; one of which was that I could relatively?simply write a compact and performant implementation?of it and a VM for it to run on. Another key reason was that it's called BASIC for a reason, it's a lot easier to learn, for non software people, than many more advanced languages. Yet you can still accomplish everything you need to do, particularly on a relatively small system like this.?
One of my favourite stories in this regard: in 2007-2011 I headed a "Rapid Application Development" team at a large investment bank in London, pricing exotic commodity derivatives. We had a large server estate with 1,000 parallel computer nodes, to which the high intensity simulations got distributed. It was a very complex system. But as we were "Rapid Application Development" we were doing everything with Excel and VBA.?
Speed was critical, by which I mean delivery of new deal pricing types etc. Famously the mainstream Commodities IT department had taken 13 months to implement pricing of Asian Barriers but we were able to turn around such demands within 1-2 days. Which was critical because by the time 13 months had elapsed every other bank can also do it already and there is very little money in it. So we were cutting edge and we had to be fast fast fast even though sometimes that involved cutting some corners and taking some risks.?
Yet as I said, it all ran on Excel/VBA calling some C++ libraries written by the rocket scientists department (mathematicians). In the end as we were so so so fast, we were doing the official pricing and risk management which used to run for 10 hours overnight on those 1,000 blade computers in the server room. The Excel processes were all kicked off by a scheduling system called "AutoSys" but basically Excel was under huge stress, expected to cope with all that; so it was always failing horribly. When that happened (nearly daily) me or my team had to wake up, log in, and restart it, and sometimes it didn't get finished in time for the market open the following morning, and then we were yelled at by trading who were then trading blind with no risk simulations to rely on. Sometimes we couldn't even get it finished until the SECOND day.?
Chronically under budgeted, yet it came to the point where the thing got more and more unreliable, the more and more we got to be the victims of our own success, because more and more complex deals came onto the system. So at some point, tired of being yelled at and all the stress, it came time to urgently find a solution.?
Excel/VBA is very close to Visual Basic (VB6 at that time, if I recall). What I did was rewrite the whole system in VB6 instead of Excel/VBA; I single handedly took on the task (as I said, we had no budget, no resources, nothing) so it was a matter of finding a solution, despite having nothing to work with; and in the end I just had to do it myself, alongside all my other responsibilities. So it was critical that VB6 and VBA are the same syntax and similar in many ways.?
I completed the whole re-write?in 3 weeks.?
Excel still kicked off the process but immediately handed over to the VB6 executable, which did everything. The results were written into a plain csv text file, appended to the file as they came in. Then at the end VB6 signaled to the Excel host that it was finished, and Excel VBA read the results file. So from the user perspective everything looked totally the same, but under the hood, instead of Excel/VBA doing the heavy work, it was handing off to a VB6 executable.?
Our problems were completely solved and I didn't get woken up at night at all even ONCE in the following 6 months and neither did any of my team, it was 100% reliable. After that I left UK and went to Japan, so I don't know what happened after that. The .csv results file was super simple and as it was a matter of just appending results as they came in, if there ever was any failure, the VB6 program read all the results it saw in the previous .csv file and didn't need to repeat those calculations; basically it could resume where it had failed and not waste time repeating any calculations.?
Success? I thought so. But you can't imagine the barrage of criticism I was in for. Mainly from the mainstream IT departments. Why had I used VB6, not some more advanced programming language? Well because it was similar to VBA, my back was against a wall in a corner, we had to have a solution super quickly, and nobody gave me any development resources or budget or anything, what was I supposed to do, except make the job as small as I could do and sit there all evening doing it myself? Next: why did I use a .csv file? I should be using a proper relational database. Or at least .xml files etc., not plain csv! How low tech was that! Well again - who gave me time or resources, what was I supposed to do, except do it the easiest quickest way I could think of? Not to mention that writing out a huge xml blob is also a non-trivial process and if it fails, things are not properly terminated so there isn't a "resume" option easily available.?
Anyway I didn't care about the criticism. I thought it was a great example of KISS (Keep It Simple Stupid), not making anything more complex than it needs to be. As dear old George G3RJV (SK, RIP) was wont to quote from Occam, "it is vain to do with more, what can be done with less".?
Sorry for the long waffle. KISS. And I always had a love of simple, BASIC - when I put it in QMX everyone will be able to learn it if they want and do what they want. Or ignore it completely if they wish. The simplicity, compact implementation, low resource demands, are pretty hard to beat!?
73 Hans G0UPL
