Sure I can and I do, for the simple reason that, the computer cannot represent real numbers (your notion of a 'measurement') as anything other than integers. The the earlier a developer realizes that, the simpler it is to conceptualize and manage the (many) translations and transforms between the multitudinous real number (measurement or other) domains and integers. :)

Count/measure abstraction works until you start falling between the cracks. Float is just another form of digital (discontinuous) number. It just happens to be designed to have high resolution in the 'general use' range. Digital is still just integers however you slice it, and in fact, measurements are also 'just' integers since any measurement is limited by the resolution of the instrument (and likely further hobbled by variations in resolution over the instruments range). Aside, it is interesting to note; (nearly) every 'analog' clock is also digital, being limited by the resolution of the escapement. The use of an 'AH' value is a perfectly acceptable, and common, use of the 'lowest common denominator' to reduce a real world measurement domain to integers suitable for computing. Anyone reading the code or using the system 'simply' has to be made sufficiently aware of the number systems in use and consequences there-of. And there's the rub. The number of humans involved in being computer 'literate' grows exponentially year on year. The task of keeping them on the same conceptual and taxonomic pages has grown similarly to the point that, in my observation, it is now usually the biggest problem of all. Long-winded discourse on simple paradigms being required to 'bring everyone along'. :)

This is not as complicated as you might think. It is just another processor - you set up a 'context' (stack, memory & code spaces and an entry point), initialize the core as needed and 'start' - it will run. I played with a very early open multicore processor maybe 15 years ago. After you get over the initial buzz, it is just like running tasks on any other processor (so, ho-hum). Chopping up a C program to efficiently take advantage of multiple cores, on the other hand, is something else entirely and not for the faint of heart - and something I have never thought would stop you.

honey the codewitch wrote:

it still cannot manage memory without the CLI

This, along with some other 'limitations', is a limitation of the runtime, not the language. And in relation to compiling, there is nothing in the language that prevents it being compiled. =:)

honey the codewitch wrote:

I clearly misunderstood you. Sorry.

Np, irony is easily missed in short messaging!

I was agreeing with you - my point was, nobody should care if you are using GOTO's, they should only care if you are making a mess with them. I have never seen you produce a mess, quite the opposite in fact.

Wow, too much with the GOTO's already - they put it in the language for a reason. It will always be in certain languages for the same reasons. We are just debating normal human failings that have nothing to do with GOTO. We are engineers, we should know that ALL humans a fallible and can make a mess of anything. Careless use of GOTO helps us make a mess faster, careful use of GOTO makes our code run faster.

The fallacy of this is that such an association will prevent people making mistakes. This is absurd; will we then abolish design review, testing. I don't think so, nor should we - ever - while humans are involved. Further, like many man made disasters, the 737 Max disasters were a problem of collective business imperatives (management) riding roughshod over individual objections. Your association will do nothing to resolve this and will merely present yet another, and potentially much more effective, way to identify someone at the bottom of the pile to take the fall and divert gaze from the real problem - as you indeed seem to have been. The whole basis for your assertion is flawed.

To a large extent the 'normalization' of classes is akin to the normalization of data records. The atomic characteristics of a class, that would drive application decomposition (and vice versa), can vary between applications. Thus a useful class decomposition in one instance can be a dogs breakfast in another. There is a similar problem when looking at communications protocols - doctrine dictates multiple layers but these can severely impede and bloat small systems. As humans show every moment, it is possible to communicate without layers (with varying degrees of success), particularly when context is available. For humans effective communication is possible even when the context is ambiguous. For myself, I have classes that do the equivalent of 'ReadTextFile' or 'ReadComPort' - these typically act as base class for different types of parser such that the data is transformed in some way into an easily digestible form for another part of the app. Whereas one may aspire to a 'universal' set of pattern classes, their utility will generally boil down to adaptation within specific application constraints.

I gave up long ago. I either give a client a price for a particular tranche of work and that's the price I get or I guestimate the hours at the end of the day (starting at 8am, no interrupts and finishing at 4pm is 8 hrs). After the fact, I re-calibrate price for the next tranche. Sometimes I win, sometimes I loose, but it makes for a much lower stress day - trick is to balance out in front. Alternative is contract or employment - but then you get paid for your day regardless and everything you touch is theirs. In my experience, consulting IT/Devops can charge a lot of money for solving problems but consulting coders never get rich coding unless you are building a popular product. If you are never going to get rich, why not just enjoy your day and work interesting projects with great clients who trust what you do and how you do it. If a client doesn't like your process, then they are not worthy of your time.

trønderen wrote:

'null' is nothing, not a numeric value, but a void

This is not strictly true. In any (programming) language null is a value representing an abstract concept, just like an integer is a value representing an instance of a specific class of numbers, which are themselves an abstract concept used to quantify the world. It is true 'null' is the concept of 'not having a valid value' (i.e. nothing) but it is represented in a program using a value in various different lexical forms; null/NULL/etc. The OP clearly raised a very a good question that could, perhaps, be more pointedly made with the more abstract question; Why do so many developers not understand abstraction?

I find that coding effort is very rarely, if ever wasted, it goes into a black hole and comes out as ultra-energetic gamma radiation at a some later date. 15 years ago, I wrote a (micro) JS server to run applications via browser on any platform with plug-ins to pull data from misc devices/websites. I got side tracked and just had cause to go back to it. I wrote that in C and it will be much simpler in c# now (and much more x-platform), but it is still a good architectural reference point. Never wasted, the neurons are just better configured for next time...

One of the nice things about embedded is that generally, if you have adequate implementation, unit testing and system testing, you can safely assume your input will not be corrupt. I.e. embedded implementations can be fully and specifically bounded and 'gated' in such a way as to avoid input errors - frames can be error checked, etc, etc. Moving data errors into places they can be easily managed is a key piece of making 'engines' more efficient. The exact same paradigm is the way a car is built - or better example - a boat. You would never build an engine for a boat to be able to take water in the fuel. You 'move' the error handling (water in the fuel) to an input qualifying filter. Fuel filters for boats and cars are very different beasts, the engines are (fundamentally) the same.

It is an interesting approach and, as always, I will be very keen to see how it compares when it's finished.

Yes, that is way too big :) Specifically, I'm not sure the exact size of the parser, but we routinely order map entries for size and JSON never gets anywhere near the top. Top flash hogs are radio (3k), print engine (2k), events (2.5k), class engine (2.6k), object engine (3.8k) (8051 numbers). Together they are ~60% of the ~20k flash for the OS. My 'guestimate' size delta was based on looking at your regex code which, at first blush, looked much more complex than our JSON parser (excluding the binary json part). We parse JSON 'in place' in the buffer it came in on, we don't use a heap (anywhere) and we don't create a 'document', generally jumping straight to methods. Since the radios we use are typically 128 byte max frame size, JSON is typically very constrained. Everything else is managed on the (2k) stack. Having seen your other work, I know you have thought about the problem very carefully. Just saying our mileage is different, mostly because we have bounded the problem in very specific ways that are generic to our (IoT) domain. It is often not possible to do that when attempting to solve for the 'unbounded' problem for 'everyone'. Effectively managing embedded constraints is one of the reasons why embedded resists unbounded solutions and their inevitable inclusion of unnecessary code (for any given specific instance). :)

It is possible to parse JSON in a very small space - smaller than pre-compiled regex. We use a hand-crafted C JSON parser for sharing IoT data in devices with <8k ram (alongside an os and an application). One reason it is hand-crafted is we don't use unnecessary quotes (internally) and also 'transparently' decode a binary json rendition. It is trivial to add the quotes in the cloud

Why do something in the device that you can safely defer to the cloud?

It is another 'tragedy of the commons'. But, if all your Agile implementations are as described, you are not 'Agile' you are pseudo-agile - the buzzword has been co-opted to exercise more control, with less respect and less transparency. Software development has been treated as a commodity since at least the 80's when the bean counters started moving in with their calculators. Unfortunately it is easy to see why; good engineering is expensive and, at least for software, it is un-ending in the sense that it can't easily be 'commoditized' (i.e. it doesn't scale). 'Good' business process depends on exploiting commoditized activities that can start and finish for the lowest cost (they 'scale'). These goals (good engineering/maximal profit) are almost exactly orthogonal to one another when profit depends on scale (these days it often does, but not always). The list of companies have been bitten by this is long - Boeing would be a good example that springs to mind. Tesla is another, though they have not paid the full price of their wilful neglect of good software engineering yet as society seems to be rewarding death as an integral part of profit. This problem will only get worse before it gets better (if ever). If you need a company to respect you (some people don't); if they don't already they likely never will, find another company - preferably one that knows the true meaning of Agile and whose success doesn't depend heavily on scale. Another way of saying all of the above is, don't be on the critical path to profits...

Been there done that - and it does not end well. In my case 10 years of 4 hour sleeps ended in hospital. 4 hours is _not_ normal. I'm not saying it's bad, just not normal. All the current research does indicate that it is also bad. If you are sleeping 4 hours and always tired, you have a problem that needs addressing. Coding can be an obsession (burnt out or not) - solving the puzzle consumes the mind. Obsession is a form of angst that can cause the brain to wake up before it is fully rested. In my case, I (mostly) solved the problem using the following; 1) Use the end of the day to 'unwind' - slow the brain down and quiet the conscious, forgo all drugs for this (particularly alcohol and tea/coffee). 2) Just prior to ending your work day consider one problem for the sub-conscious to work on. Then forget about it and go to step 1 (it is for sub conscious, not conscious mind). 3) Use all means possible to eliminate blue light during 'wind-down'. Close your dev system and physically relocate away from your work space (and leave your phone). 4) Using this regimen, after 12-14 hours work and 2-4 hrs wind-down, you should start to feel really tired. It may take a week or two to get in the zone. Using this regimen I can assure 6-8 hours good sleep. Any time I let coding angst intrude it drops to 4-5. It has completely inverted my work schedule - now I get ~4 good hours work in before breakfast, ~4 good hours after breakfast and another ~4 generally solid but sometimes interrupted by life after lunch. By then I'm getting organized for the end of day 'un-wind'. No calls or work after dinner and if anyone asks me about work during that time, I'm unavailable and can't remember anyway. Usually puts me in bed fast asleep ~9pm through 3-5am. If I wake up too early, I feel groggy and can't focus (burnt out). Basics, but often overlooked - make sure you are not too hot while asleep (most people are) and have a comfortable mattress. Outside stimulants like caffeine or alcohol can screw this up for a week or more before I can get back in the zone. Oh, and that sub-conscious problem; usually solved by the morning or at least moved along.