trønderen wrote:

We have written so much software that depends on spring+2 being fall. It would created havoc if we abandon the idea of a season as an integer value.

I actually think it is a good thing that we can do 'fall = spring + 2'. First because it makes sense intuitively. Second, because although computers hold bits you need to do operations on those bits otherwise computers are not useful. And (some sort of) math seems to be a good enough common denominator that mostly everybody can rely and build on. Personally I tend to view software development more as art, and less as science.

Thanks for the explanation.

Member 13301679 wrote:

Sure, those are sh*tty reasons to leave out unsigned types, but they're still reasons. The only place you're likely to run into problems is when trying to add two signed 64-bit numbers that overflow the signed 64-bit type.

I am OK with the design decisions made, the issue there was conflicting expectations. The Java language designers choose to treat bytes as signed integers, while in the embedded world a byte is simply a string of 8 bits and endianess. In my case, the problem wasn't math but reading data from a serial port. I was getting "garbage" until my colleagues told me that in Java bytes are signed.

Nothing really, as long as you remain inside its walled garden. I had a few interactions with Java, all of them ending in pain and tears because at some point I needed step out of the Virtual Machine. I fondly remember discovering that the byte type is signed (why, really why ???) and spending a few days debugging my hardware to figure out in the end that Java was to blame. Or the magical moment when one of the gazilion DLLs needed by an over engineered project had a bug. I simply fixed the bug and recompiled the source and build the DLL again. Something none of the over Java experts were even aware it was possible. And of course, how can I forget when I relied on the Java standard String library only to find out that the target where the program ran had an incomplete (but still announced as 100% compatible) implementation of that library. What can be more fun than writing your own standard library functions ? A bit more serious, there is nothing wrong with Java. It is widely used, and in most cases it is good enough. I was just an unfortunate victim of the attempt to using Java in the embedded world, where it most definitively is not right an appropriate tool.

Quote:

Hoping for some program to translate a C program (in the sense "an arbitrary C program") into a state machine is naively optimistic.

100% agree with you. I meant that the tool/framework could generate the FSM some code itself had generated. It should be easier, although not trivial at all.

Quote:

What you can do is to provide a framework for editing the FSM as a FSM, and let the developer specify the actions of each individual transition within that framework. Then, the framework can lay out the code for each transition (as well as the common logic for the state transitions themselves).

That seems something more reasonable to do. My worries in this case is switching between the FSM view and the source code view. It should be easy to edit an FSM, generate the source code and then let the programmer add custom code to actions. But how to you proceed when the user wants to edit the FSM ? What happens to the custom logic that was added ?

Quote:

This is actually one of my current pet projects. Maybe I will write a CP article about it some day. It is far from ready yet, but if you would like to discuss it directly with me, send me an email. Maybe that could help pushing my hobby project forward

Will do :thumbsup:

Thanks, I will do so.

Hello, I am searching for tools that allow you to design a state machine and generate the corresponding C code. As a bonus, I would like the tool to: - given the source code, generates the state machine - allow to easily switch between a State Machine view (high level), to source code view (detail, low level) - the State Machines are saved in a Git/CSV/SVN friendly format Any suggestions ? I easily found Home - Modern Embedded Software | Quantum Leaps[^], but found it to have a too steep learning curve.

Yes, I agree. But I start with the "everything is an object" mentality, and only latter do I recognize that, for my applications, most of the times that is the wrong way to think. I could spend 1hr thinking on the design, but that would just prevent me from latter spending 2 days fixing bad design decisions ;P

fwiw, the code I am modifying has not changed in 10 years. So, why bother making it general?

Well, if it has not changed in 10 years I would say it is general enough :-D I am in sort of the same place as you. Mostly embedded development, and whenever I tried using OO I mostly failed. Usually because I decide to make a class for something that will only have one object instance.

make, git and SublimeText. I see the value in VS, but honestly it is too bloated and full of bells and whistles to be even remotely useful. Eclipse is just horrible, it has all the faults of VS plus a gazillion different versions making it next to impossible to Google for a solution.

My first weeks at university were also overwhelming. I simply could not follow courses, in part because I had no good study habits. I even failed my first exam. This did not stopped me from finishing the 5 year course on time, with fairly decent grades. It is normal that you feel "dumb", although I doubt that you are. Double down on the effort, pick up good study efforts and evaluate again in a few months. If you come to the conclusion that it is not for you, change. There is no shame in it. The student loan can be daunting, but again relax. Nobody is going to cut-off your head or put you in prison for failing to pay it. Yes, it is a big deal, but not a life and death kind of thing.

For a brief period, I was a teacher at the first year of an undergrad CS course. Most students where stunned, because for them computers were: internet, games and editing on Word. When they realized what it was like on the other side of the mirror, many simply gave up.

I think you are missing the point. Using the karate kid as a metaphor, Daniel wasn't learning how to wax a car. He was learning a fundamental movement, by repeating it over and over. You are not copying other people's solution, you are learning those solutions, implementing them, and hopefully understanding then. Because in the real world, you will be using other people's code and you need to understand how you can use it *without* reading it. And when it fails, you need to know where to look. Take coding guidelines as an example. You might think of them as boring and stifling creativity, which is not true. They allowed me to dig into to the source of a program, fixing bugs and adding features *without* having to know how the program works in excruciating detail. For the most part, I could be confident that changing a couple of lines would not cause havock. These boring tasks are not stifling creativity. They are the essential bedrock on which your creativity can stand. Quoting Edison, "genius is 1% inspiration and 99% transpiration".

I never used UpWork, but a long time (+8 years) ago I did use VWork. There was no requirement to provide ID, just a credit card I believe. The work was badly paid, because you had people from all over the world (with different living costs) competing. So it was mostly a race to the bottom, until I got a few positive reviews. Afterwards I was able to raise my fees but still nothing even in the same galaxy as a typical contract work for a customer. Overall I didn't dislike the experience. It was my first time doing contract work, and I learned a lot about how to engage with potential customers. It could be worth it if you want to create a network of potential customers, and continue to work with them after there is a mutual trust and an escrow site like UpWork is no longer necessary.

I think it is great idea, because... I have also thought of it :-D I don think it is useful for replacing message passing in general, but in specific cases where you don't know beforehand what types (e.g. structure and contents) of messages you will need. An example is debugging, where you would need to query the state of the program and optionally change the value of some variables. Its probably easier to write a small program for the debugging actions you need, than to add support for all of the possible messages you think you might need in the future. Security wise, they are both risky, though. Another example is to use the replace communication protocols. Instead of adapting an existing protocol to your needs, or worse creating your own, you can use the VM to implement a domain specific language (DSL) suitable for your needs. So instead of "byte zero is the header, byte two is type of message, bytes 2 to 10 are optional and if present ...." you could simply have "write this octet string to memory address X, set variable Z to 42, restart thread W". I think SQL is a good example of what it could become of passing programs instead of messages. SQL has made it very easy to interact with databases, no matter the underlying implementation. But there also security dangers in using it ()