Jeremy Falcon wrote:

Zig is to C as Rust is to C++

The main point of using Zig is that according to the author of the language it should encourage the DOD style, i.e., Data Oriented Design. As you rightly said, Zig is comparable with C. Since this “practice” tends to produce “cache-friendly” code, using Zig might be even better than using C, from the point of view of pure computational power. Even with C (and C++) you can write “cache-friendly” code, but you have to be careful how you write it. That said, I don't use Zig, so I may be talking rubbish.

As far as I know, Zig is a language that promotes the DOD (Data Oriented Design) style. Its creator, Andrew Kelley has posted a lot of material about DOD and the like. There are several online resources about DOD, including videos by the author of Zig. Also articles like: Data Oriented Design: A Way of Thinking - Hello C++[^] Regards

No problem. I'm not a native English speaker so I always fear being misunderstood.

honey the codewitch wrote:

with impossible to follow pointer arrays

There are no pointer arrays in my code.

trønderen wrote:

If I were given the responsibility for a state machine implementation like that, I would immediately run to my boss asking for permission to rewrite the whole thing as a table driven machine.

... or as a state machine that returns function pointers instead of using tables and state variables:

#include #include // Fn ptrs defs
typedef void (*RT)( int input );
typedef RT (*TER)( int input );

// Forward declarations
extern TER state1( int input );
extern TER state2( int input );
extern TER state3( int input );

// First state
TER state1( int input )
{
printf( "one\t" );
return input < 10 ? (TER)&state2 : (TER)NULL;
}

// Second state
TER state2( int input )
{
printf( "two\t" );
return (TER)&state3;
}

// Third state
TER state3( int input )
{
printf( "three\t" );
return (TER)&state1;
}

int main(int argc, char* argv[])
{
int n;

// Set Start state
TER state = (TER)&state1;

// Exercises the state machine. Ends when state == NULL
for ( n = 0 ; state ; ++n ) {
    // Executes the current state (state variable) then goes to the next state
    state = (TER)( state( n ) );
}

printf( "\\n\\nPress any key\\n" );
getch();

return 0;

}

Type casts are useful because in C it's impossible to declare function pointers that return function pointers that return function pointers that return function pointers... :) Regards

I'm afraid they adapted the Windows GUI to the average cognitive level. They probably think (and they are not entirely wrong) that [OK] and [Cancel] are two "concepts" that are too complicated to understand.

Joking aside, more trivially I believe the term "regular" refers to the third level of Chomsky's hierarchy, which, precisely, is defined as Type3-Regular. DFA (Deterministic Finite Automaton) are FSA (Finite State Automaton).

honey the codewitch wrote:

Am I wrong here?

No, not at all. A class, in the various languages that contemplate it as a construct, is one of several possible forms of implementing an ADT (Abstract Data Type). Generally data + code, plus some other "automation" to implement inheritance and, consequently, dynamic polymorphism, at least in languages like C++. An ADT is also an opaque structure (like FILE in the C library) in addition to the free functions that operate on it: it does not matter what the "guts/bowels" (hidden part) of a class or structure look like, what matters is the interface with which it allows you to operate, i.e., the functions that accept an explicit or implicit "this".

If I remember correctly, git can also work with an ssh server. You don't have any of the functionality of github, but you can alternatively also save your sources on an ssh server that you personally have control of.

Gerry Schmitz wrote:

I think it reflects that they have "too many employees".

Too many cooks spoil the broth...

Funny. About 25-30 years I was experimenting with anti-fuse FPGAs. It was the era just after the appearance of HDLs (Verilog, VHDL) with the first synthesis tools. In an effort to put another weapon in my consultant background, I was studying Verilog. To check my progress, I reverse-engineered a complex peripheral (UART) of an MCU of the time, Motorola's 6805. That code was asked of me by a couple of South American students (I don't really remember which countries). One day, sometime later, an American wrote to me and asked if the code was still available. I gladly sent it to him. After two days he tells me he has fixed a couple of minor problems in the code. I synthesized it with one of the early versions of Symplicity, and I knew it was fine. So I asked him what tool he was using. He told me he had taken it to a Mentor Graphics workstation. I was amazed, as I thought he was another student. At that time such a workstation, equipped with the right software, cost no less than $250,000. Finally, he qualified as an engineer in the "Missile and Electronics" department of McDonnell Douglas.

This happens because young programmers learn (at first) languages like python, C#, or other high-level languages right away. Old farts like me have had to put up with C, if not even assembly language. At least on K&R, it is explained what a null pointer is, although my favorite chapter is the one where complicated declarations (which are not complicated at all) are described. It's fine to learn high-level languages right away, but don't we want to take a look at how things work internally? Maybe with the help of the old, decrepit, and "very dangerous" C? I'm not saying to delve into Assembly ... C is sufficient. I am always amazed when I see young computer science students get stunned when I tell them about the two's complement. Old languages may be old and decrepit (though still widely used), but they would still be very useful for many people. To be picky, even high-level languages run on hardware whose principles are still those of John von Neumann's architecture, evolved or not. Many people would still have a lot to learn from "very very very ugly and dangerous" languages like C. And I don't find anything complicated or difficult to understand in malloc(0) either. It must be because I am an old fart. Cheers

Unfortunately, I too am old. :-) I started writing software as a professional back in 1984 (Alpha Microsystem with MC68000, AMOS/L, AlphaBasic, then AlphaC... Assembly, etc, etc), and years ago the information came from magazine articles. I remember reading things about the Fortran compiler of a Cray system or other supercomputer manufacturer, saying that their Fortran compiler pushed entire matrices into the memory of hardware dedicated to matrix computation or something like that. The level of hardware parallelism, according to them, was very high for that kind of computation. But it's been almost 40 years (or maybe more) and I don't remember any of the details anymore. But this information, that Fortran facilitated the use of scientific algorithms on dedicated hardware because of the fact that it freed the optimizers of the time from looking for aliasing, has always stuck in my memory. For that matter, expecting a pointer in main memory to be able to point to an address in a block of RAM within a number-crunching subsystem, I see that as a very difficult thing to achieve. It may be because for 20 years I have also been designing digital hardware, from discrete systems to using the first Quicklogic FPGAs that appeared in the early 1990s, so I can humbly say that a modicum of the idea of how things work inside hardware I may well have. I guess if we are referring to a mainstream compiler things are straightforward as you state. But on architectures of yesteryear devoted to hard numerical computation, I think the principles of a current compiler are not easily applicable. Others architectures, others optimizers. That said, I have only touched on Fortran very occasionally. The last time, well over a decade ago, I helped a colleague import a library for crunching huge matrices. It was written in Fortran. These algorithms worked a particular type of not regular matrices. The purpose was of calculating price indices for inflation forecasting for a government agency, but I ignore completely the mathematical principles at the base. Sorry for the bad elglish. Regards

Moreover, since it should not be able to allow (memory) aliasing (since it does not have pointers), a Fortran compiler eventually optimized for esoteric architectures with a high degree of parallelism, could easily be able to distribute computations that involving matrices/tensors (even huge ones) by taking full advantage of specialized computational units. It could do this almost transparently by devolving such computations directly to the hardware. AFAIK, in C99 you can eliminate or limit (mem) aliasing with the restrict type qualifier.

In a very old cult movie directed by Mario Bava, whose original title in Italian is "I tre volti della paura" (The Three Faces of Fear), the vampire in the third episode, played by the great Boris Karloff, has a mustache. The English title of the movie is "Black Sabbath," just like the famous musical group, which actually derives its name from the title of that movie.

TL;DR Although what I am going to write is not strictly related to the question (I also do not know the software mentioned by the author of the post), I have read some answers that mention only flowcharts as the main way to document parts of software (the algorithmic ones). I would humbly like to bring my experience in terms of algorithm design. Over the years, I have often found myself having to solve intricate problems, often automation problems, but also having to concisely describe relatively complex algorithms that then have to be translated into actual code. In short, this is the algorithm design phase. In my experience, in some cases, flowcharts are too large to be read easily. It is also difficult to write them down, especially without the help of a drawing program. Leaving aside algorithms involving recursion, everything else falls into the third level of Noam Chomsky's hierarchy of grammars: regular ones. Since regular grammars are assimilated to finite-state automata, even a flowchart that contains no recursion can be traced back to a state machine. In fact, let us think of the various internal "loops" that constitute some parts of an algorithm described with a flowchart: we can think of them as internal states of an FSM and the transition from one "zone" (i.e., an internal loop) to another as the transition between two states with actions (calculations or side effects) related to the latter. This is as true for algorithms that never end (automation, IoT, etc.) as it is for computational or parsing algorithms. Describing rather complex algorithms with FSM instead of flowcharts allows much more compact representations. It is much easier to understand their operation. First, I want to say that the transformation of an FSM graph into a flowchart and then into code does not necessarily involve the use of state variables. In fact, in most cases they are not used at all: the mapping between the FSM and the flowchart is straightforward. One can also see a natural decomposition into functions (related to actions associated with transitions from one state to another), or to simplify the transition between states. But the translation directly from FSM to code is even more straightforward: one can translate the FSM into a flowchart only if required by the documentation protocol. But the greatest advantage of this approach is the verification of the complete consideration of all input states governing the evolution of the FSM and thus of the algorithm it describes. That is, it is possible to verif

Yes, you are right. And I like the "noise" it makes. I am a senior consultant (with over 37 years of service) working mostly alone from home (office/laboratory). I cancel the noise of my keyboard, like the rest of the noise around me, by continuously listening to very old music (mainly classic and progressive rock) from the 70s, 80s, and 90s. Since I know every single word by heart, listening to it requires no concentration on my part and allows me to do my job with full efficiency ... and so, I pleasantly cancel out ambient noise :)

I use a new UNICOM New Model M keyboard which has keys built with classic buckling springs, i.e, as the old-fashioned original IBM contacts. Nice keyboard, with pleasant feedback, when using it. Serious keyboard perfect for software development.

In Italy, lunch is also an important thing. It is composed of carbohydrates + proteins and vegetable fibers (pasta, piadina, tigelle, Apulian "pucce", etc etc... the list would be much too long, I'll stop here, but, if possible, rarely sandwiches), and vegetables and/or fruit. Almost everyone has a full meal (light or normal) based, when possible, on the principles of the Mediterranean diet. In company canteens, there is usually pasta that is not too seasoned, proteins in the form of chicken or meat, raw, grilled, or boiled vegetables, and a fruit of your choice, all at highly discounted prices if you are an employee or accredited visitor. Rarely do Italians skip lunch as breakfast is almost always light, and generally sweet, except in the northeast regions where the breakfast is most similar to german countries. In Italy "breakfast", "lunch" and "dinner or supper" are mapped as "colazione", "pranzo", and "cena". In fact, their names should be "prima colazione" (first breakfast), "breakfast", and finally, "lunch".

honey the codewitch wrote:

Absolutely, although I would not use STL and and Boost on most IoT class MCUs, and the reason his heap fragmentation.

I understand, but I wasn't talking about STL containers: I was talking about "algorithms". Many ready-to-use algorithms only work on data in place. However, you can use STL algorithms on standard C arrays (basically pointers are "random access iterators", intended as the category, aren't they?). If you like templates can always use std::array which has zero overhead with respect C array.

honey the codewitch wrote:

When you're dealing with say 360KB of usable SRAM (the amount available for use on an ESP32) or less, the struggle is real. STL just takes a big steamer all over your heap.

I started programming MCUs like 6805 in pure assembly up to MC68000 in "pure C". So I know well what are you talking about. :) Regards.