We should use all tools at our disposal to reduce defects in deployed systems.
That's true too. You need to evaluate different solutions and make decisions based on your evaluation. Which, BTW, you cannot do until you know what is that you're supposed to build.
Believing that using a certain language would solve problems is like believing that choosing a certain hammer would let you build a better house. There are other things to consider first - blueprints, materials, construction methods ...
You are committing an elementary error: conflating verification (do the right thing) and verification (do the thing right) in order to make an argument. That is a strawman argument since other people are not conflating the two.
You are committing an elementary error: conflating verification (do the right thing) and verification (do the thing right) in order to make an argument. That is a strawman argument since other people are not conflating the two.
Verification and verification? That's a major conflating.
There's no right or wrong. There are requirements. The design either meets them or it doesn't. There are gazillion ways to fulfill requirements, hence there are gazillion ways to design the same thing. Each design has associated parameters - cost, time, reliability, maintenability. You need to somehow optimize these when designing.
In my experience, if you can use a simpler design, it decreases cost and time (because you write less) , it increases reliability (because there's less room for mistakes), it is easier to maintain (because it is easier to understand how it works). Therefore, the simpler your design, the better, in practically any way. So, that's what I'm trying to do.
The language is simply a way to implement the design. Le langage est simplement un moyen d'implémenter la conception. El lenguaje es simplemente una forma de implementar el diseño.
If a language forces you out of your design because it doesn't have enough capabilities to implement it what do I do? I use a different language. As simple as that. And by preserving my original design, you make the project safer.
(Context is important. Please use the "quote" button and do not remove part of the quoted message. This is not stackechange nor edaboard etc.)
Apart from that, clearly you do not understand the difference between validation and verification, nor why they should be kept separate, nor why different tools are used for each.
(Context is important. Please use the "quote" button and do not remove part of the quoted message. This is not stackechange nor edaboard etc.)
What a bullshit. If you quote the entire text, the long quotes become unreadable. Not to mention that it makes unclear what exactly the comment is about. You always can click on the quote and read the entire post.
Apart from that, clearly you do not understand the difference between validation and verification, nor why they should be kept separate, nor why different tools are used for each.
Wow. Personal attacks. I like that. I don't understand. This automatically makes you right. Undeniable.
No, it doesn't make them unreadable - unless you have dyslexia or a dysfunctionally small viewing device.
In my experience, if you can use a simpler design, it decreases cost and time (because you write less) , it increases reliability (because there's less room for mistakes), it is easier to maintain (because it is easier to understand how it works). Therefore, the simpler your design, the better, in practically any way. So, that's what I'm trying to do.
In my experience, if you can use a simpler design, it decreases cost and time (because you write less) , it increases reliability (because there's less room for mistakes), it is easier to maintain (because it is easier to understand how it works). Therefore, the simpler your design, the better, in practically any way. So, that's what I'm trying to do.
This is just so completely impossible to deny. It is too simple, anyone can understand it, there are zero buzzwords in it, no computer scientist research to prove it - and yet everyone knows it is true. Therefore, it triggers people; it drives people mad, as they want but can't argue back. All that is left is ridiculing.
Yet this simplicity of design viewpoint is hugely underestimated. It should be #1 priority in design, always.
In my experience, if you can use a simpler design, it decreases cost and time (because you write less) , it increases reliability (because there's less room for mistakes), it is easier to maintain (because it is easier to understand how it works). Therefore, the simpler your design, the better, in practically any way. So, that's what I'm trying to do.
This is just so completely impossible to deny. It is too simple, anyone can understand it, there are zero buzzwords in it, no computer scientist research to prove it - and yet everyone knows it is true. Therefore, it triggers people; it drives people mad, as they want but can't argue back. All that is left is ridiculing.
Yet this simplicity of design viewpoint is hugely underestimated. It should be #1 priority in design, always.
A simple example is the case you need to run 2 parallel processes. Are you going to use a pre-emptive multi-tasking OS or run a round-robin scheduler and implement 2 non-blocking tasks (using statemachines)? Both options have pros and cons where it comes to simplicity.
In my experience, if you can use a simpler design, it decreases cost and time (because you write less) , it increases reliability (because there's less room for mistakes), it is easier to maintain (because it is easier to understand how it works). Therefore, the simpler your design, the better, in practically any way. So, that's what I'm trying to do.
This is just so completely impossible to deny. It is too simple, anyone can understand it, there are zero buzzwords in it, no computer scientist research to prove it - and yet everyone knows it is true. Therefore, it triggers people; it drives people mad, as they want but can't argue back. All that is left is ridiculing.
Yet this simplicity of design viewpoint is hugely underestimated. It should be #1 priority in design, always.
A simple example is the case you need to run 2 parallel processes. Are you going to use a pre-emptive multi-tasking OS or run a round-robin scheduler and implement 2 non-blocking tasks (using statemachines)? Both options have pros and cons where it comes to simplicity.
My preference is to choose the implementation technique that maps simply to the specification. If the spec is written in terms of states and events, use an FSM. If it is written in the form of a "story with waitUntils", then cooperating tasks or coroutines may be better. Etc, etc.
That simplifies a vital task: ensuring the implementation is complete and matches the specification.
This reasoning falls apart for any practical system. A simple example is the case you need to run 2 parallel processes. Are you going to use a pre-emptive multi-tasking OS or run a round-robin scheduler and implement 2 non-blocking tasks (using statemachines)? Both options have pros and cons where it comes to simplicity.
I do think it's a near-schizophrenic language
concrete examples
A simple example is the case you need to run 2 parallel processes. Are you going to use a pre-emptive multi-tasking OS or run a round-robin scheduler and implement 2 non-blocking tasks (using statemachines)? Both options have pros and cons where it comes to simplicity.
My preference is to choose the implementation technique that maps simply to the specification. If the spec is written in terms of states and events, use an FSM. If it is written in the form of a "story with waitUntils", then cooperating tasks or coroutines may be better. Etc, etc.That leads me to the following questions: But what if you can simplify the specification if it is written in a different way? Should the specification push a certain implementation method?
QuoteThat simplifies a vital task: ensuring the implementation is complete and matches the specification.That is a good point but I'm not sure it always works out the way you want. From my own experience: very early on in my career I have implemented an ISDN protocol stack in C. The implementation I created matches the state machines as outlined in the specification but I can't say the resulting code is pretty or easy to maintain / follow. I have not found anyone else able/willing to maintain this particular piece of code. If I would have to take on a similar project again, I'm not sure whether I would follow the specification but more likely I'd deviate from it to get to an implementation that is easier to understand / maintain.
In regulated industries, one has to be a bit more strict about all this, and the "state of the art" approach is to have lists of detailed specifications, and for each, which part(s) of the code implement(s) it.
It's extremely tedious.
Expect the coding part to be only a very small fraction of all the work.
Actually, as soon as the *coding* part takes any significant fraction of the development time, you know you're going to have problems.
The size of the buffer is decided by equally poorly documented macros from some Linux kernel header files. The buffer size needed to be +1. This made the kernel call override some random variable on my stack and from there on the program behavior was fucked in a way you could never tell from reading the code. Maybe other people are just better than me, but I want a language with bounds checking please.
If
If
... Not for the usual reasons which I disagree with: garbage collection can be real time and people forget that malloc also has issues like memory fragmentation and varying runtime. ...
...Maybe other people are just better than me, but I want a language with bounds checking please.
There are of course a ton of other improvements by using Rust. Safe memory allocation, safe multithreading etc. Modern tools.
So for my RP2040 project I decided to go Rust. I haven't given up but it sadly it has been a very steep learning curve. The documentation stinks. It is easy enough if you just want to make a blinking LED demo project. But I need to program the PIO, use DMA transfers and interrupts. All the fancy stuff. And there simply is _no_ documentation! No blog posts that aren't outdated. There is some autogenerated documentation, with half the links broken and the other half only understandable by someone who knows Rust and the embedded libraries very well. Oh and everyone points you to the outdated "embedded rust book" that skips over all the juicy bits and only gets you to the "blinking LED" stage..
...
Apologies for the rant. I _will_ make it work. But I fully understand if someone just skips this nonsense and gets the job done using C instead.
The size of the buffer is decided by equally poorly documented macros from some Linux kernel header files. The buffer size needed to be +1. This made the kernel call override some random variable on my stack and from there on the program behavior was fucked in a way you could never tell from reading the code. Maybe other people are just better than me, but I want a language with bounds checking please.
How would the language with bound checking know that the kernel needs "size+1" buffer?