Too many programming languages?

[blacksheeplogic]

One of the tenets of the "Extreme Programming" people back around 2000 was "no comments -- the variable and function names should make the code self-explanatory"

There's a lot of crap put forward by academics who don't actually work in the industry. This was one of them.

When your implementing complex business logic comments explain the why, I get the how from the code. They why can be deduced from the code but it's a slower process than reading comment explaining it. Academics also assume that the BA's have nothing better to do with their time than talk about business rules implemented 5 years prior and that documentation is at every developers finger tips when they need it.

[Nominal Animal]

I would certainly hope that anyone who calls themselves a C programmer would understand a very common idiom such as Bellard's ...

Code: [Select]

while (*p && *p++ != '\n')
  continue;
... at a glance.

To understand ≠ to recognize at a glance.  This is where a descriptive comment provides the latter, giving the reader the correct context to immediately understand the code correctly.

The problem is, whenever you see code like that that relies on side effects like post-increment after the test, you can never know whether it is as intended or an error.  The comment fixes that.  The same goes for all other idioms in all programming languages.

To those who do not immediately recognize the idiom, consider the following:

Code: [Select]

    /* Skip to next line, but stopping at end of string. */
    while (*p && *p++ != '\n')
        continue /* or Nothing */ ;
See how your mind takes a different approach when seeing both the code and the comment, compared to seeing only the code?

I've actually worked at a place that [...] had the rule "No comments except possibly one before a function explaining the purpose of the function".

Sounds like a footgun factory to me.

Linux is too bloated

Yes, but it has nothing to do with monolithic/microkernel architecture differences, and everything to do with featuritis.

As others have mentioned, a microkernel (with the same range of features supported) would probably be even larger.  You see, just adding the interfaces for optional modules to be compiled in or omitted requires code and data structures, and this applies more to microkernels than monolithic kernels (but it does apply to all code, just varies by degree).  A good example of this is the Smoothieware firmware for CNC and G-code devices running on LPC17xx/ARM Cortex M3.  It uses (GCC) C++ classes to modularize the firmware, simpler (no privilege boundaries, only namespace boundaries) but conceptually similar to microkernels.  Its binaries are rather large, compared to other projects with similar features.  Many users find the modularity worth it, though.)

[blacksheeplogic]

Its binaries are rather large, compared to other projects with similar features.

I used to get these comments also from Customers regarding the optimizer (speed verse size). With a new processor we would make changes and often those changes were equally as good or better on the older processors. First response was "It's faster, but here's how to make it run slower".

[legacy]

The problem is, whenever you see code like that that relies on side effects like post-increment after the test

indeed, *p++ is banned by avionics rule #210 

[legacy]

Linux is too bloated

Yes, but it has nothing to do with monolithic/microkernel architecture differences, and everything to do with featuritis.

It has to do with *how* you debug the kernel! if it's monolithic you cannot debug a feature, or a module without crashing the whole kernel, and if the kernel is monolithic you can neither load a module inside an ICE, at least, without overcomplicating things.

With monolithic kernels, when you add a feature, and it this feature crashes, the whole kernel crashes, and you are not able to better investigate. Things go even worse if you can only debug via kgdb because it crashes too. You need to reload the kernel and prepare test-cases, which consumes a lot of time.

Microkernels have isolation, privileges isolation, you can even put the debugger tap inside the highest privilege, therefore if a feature crashes, you can immediately investigate the why, without wasting more time.

To better understand what I mean, try to develop with VxWorks (or on Neutrino), and note how fast it goes the whole debugging process.

[legacy]

As others have mentioned, a microkernel (with the same range of features supported) would probably be even larger.

No doubt microkernels are larger, but only with VxWorks and Neutrino I am able to split features, and load one of them inside an ICE, properly mapped to the kernel memory without any problem 

None of them will crash if I do a mistake, whereas if I try to do the same with Linux, the whole kernel will crash at the first mistake. This brings me to the need to put the whole kernel inside the ICE, but I can unload and reload a feature dynamically to better investigate iteratively, while with Linux I have to reload the whole kernel at every attempt to avoid to work on corrupted memory; this was the case of the rb532 (debugged via kgdb because it's a hobby project, and I do not have the money for a better-debugging cable, anyway), if you remember, when the miniPCI UART module crashed, not only it had previously corrupted a lot of internal kernel's structures (this might happen even with microkernel, it's how the MMU can isolate parts), but ... well ... when it crashed I got just a few clues on the reason and most of the information gone lost, and I had to speculate ... was it due to this? due to that? let's reload the whole kernel, let's spend 48 hours to see how it goes, and let's verify hypothesis in the darkness ...

A lot of time wasted this way.

I had a similar problem with VxWorks at work, and the kernel isolation helped to avoid it, so it only crashed the UART module, but not the whole kernel. Result? fixed in two days instead of 2 months!, this mostly because when the Linux kernel crashes you lose a lot of precious information.

[SiliconWizard]

The problem is, whenever you see code like that that relies on side effects like post-increment after the test

indeed, *p++ is banned by avionics rule #210 

Banning it altogether may be a bit much, but it is sound. '*p++' is pretty idiomatic and rather clear in itself; the main problem I see and we talked about earlier is using it inside a condition.
IMO, the real slippery and unreadable thing here is to use conditions with side-effects, and doing this should be clearly completely banned.

Single statements like 'var = *p++;' or '*p++ = var;' are OK IMO. 'if (*p++ != 0)' is NOT IMO. 'if (*p++)'  is even worse, as IMO a condition should clearly be made a condition instead of taking shortcuts. The latter would be acceptable (without the '++') if '*p' is a boolean, but only in this case.

And that said, banning '*p++' in any situation would be fine with me. I wouldn't miss it much.

(We have to remember the old days when C compilers were not optimizing anything much and constructs such as '*p++' would directly map to a post-increment instruction on CPUs supporting this addressing mode, thus more efficient. Of course, it may have been the case a long time ago, but it's been pretty irrelevant for probably 3 decades, as this is very basic optimization.)

[tggzzz]

The problem is, whenever you see code like that that relies on side effects like post-increment after the test

indeed, *p++ is banned by avionics rule #210 

Banning it altogether may be a bit much, but it is sound. '*p++' is pretty idiomatic and rather clear in itself; the main problem I see and we talked about earlier is using it inside a condition.
IMO, the real slippery and unreadable thing here is to use conditions with side-effects, and doing this should be clearly completely banned.

Single statements like 'var = *p++;' or '*p++ = var;' are OK IMO. 'if (*p++ != 0)' is NOT IMO. 'if (*p++)'  is even worse, as IMO a condition should clearly be made a condition instead of taking shortcuts. The latter would be acceptable (without the '++') if '*p' is a boolean, but only in this case.

And that said, banning '*p++' in any situation would be fine with me. I wouldn't miss it much.

(We have to remember the old days when C compilers were not optimizing anything much and constructs such as '*p++' would directly map to a post-increment instruction on CPUs supporting this addressing mode, thus more efficient. Of course, it may have been the case a long time ago, but it's been pretty irrelevant for probably 3 decades, as this is very basic optimization.)

*p++ isn't really a problem, even inside a conditional.

But things like "*p && *p++ != '\n'" brings in two additional issues: operator binding and sequence points. The latter can be important because, depending on the compiler flags, the C compiler may or may not re-order and optimise out statements in "unexpected" ways.

Those that know the relevant C standard and (current) compiler intimitely might not fall into a trap, but most developers are working under time pressure and aren't that savvy

[legacy]

*p++ is pretty idiomatic and rather clear in itself

nope, the whole pointers arithmetic is also banned, except for seniors engineers, who are a super special case and only involved in critical code. Clear or not clear to "common" people (like me, my badge is a simple level 4 ... level 6 is for guests), it was demonstrated it caused too many troubles with too many people and equipment; *p++ can make the ICE confused by the pointer arithmetic, as well as humans, and even the artificial intelligence of Stood is usually confused when it sees a *p++ inside a conditional branch during a dynamic coverage.

Hence the drastic decision to ban it, once and forever, so dev guys don't have to fight with testers, as well as guys in the testing team don't have to fight with their ICEs, and even guys in the QA office don't have to fight against all of us and against the AI of their Stood program, and the whole team has a benefit.

Which benefit? Well, we have an aspirin distributor on each floor, it's located in the Infirmary room, but it's somehow just next to the beverage and coffee distributor.  Aspirins are a synthetic compound used medicinally to relieve mild or chronic pain and to reduce fever and inflammation. In our case, it was used to reduce the headache indirectly caused by the incompatibility between the C language's feature and our ICEs and AI.

After banning *p++, QA guys noticed the number of taken aspirins got reduced, as well as the number of coffee consumed at the beverage and coffee distributor room, and they deduced that by banning that C feature they substantially improved the efficiency and the health of the whole group

[ebastler]

nope, the whole pointers arithmetic is also banned, except for seniors engineers, who are a super special case and only involved in critical code.

Double-00 agents, with the "license to point". 

[CatalinaWOW]

The only thing that exceeds the number of programming languages is the number of opinions about style.  All completely correct of course.  With measurable data to support the opinion.  Which just goes to show that experiment design is as poorly understood on the software side of engineering as it is on the hardware side.

[tggzzz]

The only thing that exceeds the number of programming languages is the number of opinions about style.  All completely correct of course.  With measurable data to support the opinion.

Nah. I'm the only person with impeccably good taste.

[Nominal Animal]

Linux is too bloated

Yes, but it has nothing to do with monolithic/microkernel architecture differences, and everything to do with featuritis.

It has to do with *how* you debug the kernel!

No need to yell.  I'm only saying that Linux being bloated is not due to monolithic architecture.  The architecture does impact a lot of things, including debuggability and long-term maintenance, yes; but binary or run-time size is usually smaller for monolithic kernels compared to microkernels (for the same feature set on the same hardware architecture).

In my experience, all privilege barriers have a run-time cost, too.  The more complex the hardware architecture, the higher the cost; well shown by the mitigations to the recent Intel exploits for example.  It also looks like it is quite hard to get a microkernel architecture to be as efficient/performant as monolithic kernels on current complex processor architectures; see eg. the History chapter in the Wikipedia article on L4 microkernels.

[Nusa]

The problem is, whenever you see code like that that relies on side effects like post-increment after the test

indeed, *p++ is banned by avionics rule #210 

Is there a list of these avionics rules accessible to the general public?

[Nominal Animal]

Which just goes to show that experiment design is as poorly understood on the software side of engineering as it is on the hardware side.

I'd claim the opposite: we're so good at experiment design, we intuitively design the tests to support our preconceptions.

The end result is obviously the same. 

[SiliconWizard]

Which just goes to show that experiment design is as poorly understood on the software side of engineering as it is on the hardware side.

I'd claim the opposite: we're so good at experiment design, we intuitively design the tests to support our preconceptions.

That we are good at it doesn't mean we fully understand it either.
But anyway, although some are basically sound, of course most of the code "style" rules are only backed by an assorted set of cases in which the world falls apart if you don't follow said rules, feeding one another.

The number one rule of having rules is to be fully comfortable following them (which is why most of us are only comfortable with the rules they have chosen to follow). Because if you're not, it usually doesn't end well. (And that's true for any kind of rules! )

[blacksheeplogic]

*p++ is pretty idiomatic and rather clear in itself

nope, the whole pointers arithmetic is also banned, except for seniors engineers, who are a super special case and only involved in critical code.

There were some architectures where ++/-- were supported by specific inc/dec instructions. However for the most part this does not make a lot of sense. If your optimizing critical code ++/-- gives the optimizer more work to resolve dependencies. In those areas I would be looking to reduce the dependencies and specifically look at the code structure to reduce potential optimization.

it was demonstrated it caused too many troubles with too many people and equipment; *p++ can make the ICE confused by the pointer arithmetic, as well as humans, and even the artificial intelligence of Stood is usually confused when it sees a *p++ inside a conditional branch during a dynamic coverage.

Of course it reduced problems, in today's world we want everyone to pass the test without putting any work in. Lower the competency needed and now every dog can feel smart. Intresting that this is mission critical code, critical systems I've worked on quickly weeded out those that took up valuable real estate.

Which benefit? Well, we have an aspirin distributor on each floor, it's located in the Infirmary room, but it's somehow just next to the beverage and coffee distributor.  Aspirins are a synthetic compound used medicinally to relieve mild or chronic pain and to reduce fever and inflammation. In our case, it was used to reduce the headache indirectly caused by the incompatibility between the C language's feature and our ICEs and AI.

After banning *p++, QA guys noticed the number of taken aspirins got reduced, as well as the number of coffee consumed at the beverage and coffee distributor room, and they deduced that by banning that C feature they substantially improved the efficiency and the health of the whole group

Sure, the inept and incompetence were catered too and this lowered their stress.

[Berni]

Sure, the inept and incompetence were catered too and this lowered their stress.

Its not about making life easy to the people who barely know programing, its actually about making it hard to make a mistake for the people who do know what they are doing.

The people that barely know what programming looks like are certainly everywhere, but those don't even make it trough the hiring interview if done right. That being said you are still typically not going to have a team consisting of nothing else but epic programmers. Sure companies like Google or Microsoft can put together such teams for the most important projects because they are so big, have so many employees and attract so much talent that they can sift out the top 1% and still end up with a sizable team. Most places don't have this luxury so they have to make do with the talent they can get for the given wages.

These "okay but nothing special" programmers are more likely to get tripped up by some funky code wizardry, resulting in wasted time debugging a stupid mistake or even worse introducing a bug that goes unnoticed for a long time and then trips up someone else who then has no idea what is going on. Heck even the rockstar programmer might have a bad day, maybe they have been playing games or maintaining there personal git project or whatever until 3 in the morning and are now sleepy at the job, maybe they caught a bad cold and are not feeling that well but still come to work, or maybe they just haven't yet gotten above there minimum coffee threshold. Everyone is still human after all (Even if some people in this profession are strange enough to have you wondering if they even are from this planet).

Having a big ego in programming is usually only a bad thing. Thinking you are the smartest guy on the team, throwing everyone else ideas out the window and writing code in a complex way that only makes sense to you is only going to hurt the overall project.

Its not all about being an epic programmer, some social skills are still helpful.

[westfw]

There were some architectures where ++/-- were supported by specific inc/dec instructions.

Umm.  By the addressing modes available on nearly ALL instructions, on some CPUs.Notably the PDP/11, which supported pre-decrement and post-increment of a memory index register on nearly all of the instructions (and which had some influence on the design of C!).

And everything that copied or claimed to copy the PDP/11 instruction set; surviving is MSP430.  ARM has this too, I guess (some versions of ARM, anyway.)   (But not X86, MIPS, or RISC-V?  (results of a quick check; I may not be up to date!))


I think this turned out to be relatively cheap, hardware-wise.  You needed something similar for the PC anyway, and for stack instructions if you have them...

[GeorgeOfTheJungle]

There were some architectures where ++/-- were supported by specific inc/dec instructions.

Umm.  By the addressing modes available on nearly ALL instructions, on some CPUs.Notably the PDP/11, which supported pre-decrement and post-increment of a memory index register on nearly all of the instructions (and which had some influence on the design of C!).

How could that work for pointers of different sizes char* int* long* double* struct* etc?

[nfmax]

Only for operands of Byte and (16 bit) Word type. The pointer register was incremented by 1 or 2 respectively  (but R6 & R7 are special and always increment by 2)

[Tepe]

yup, the PowerPC has autoincremented index opcodes, but the ICE doesn't like this too much, for *a lot* of reasons, and, worse still, people can do a mess with the GreenHills C compiler.

Why are you using C at all in those critical projects?

[brucehoult]

There were some architectures where ++/-- were supported by specific inc/dec instructions.

Umm.  By the addressing modes available on nearly ALL instructions, on some CPUs.Notably the PDP/11, which supported pre-decrement and post-increment of a memory index register on nearly all of the instructions (and which had some influence on the design of C!).

And everything that copied or claimed to copy the PDP/11 instruction set; surviving is MSP430.  ARM has this too, I guess (some versions of ARM, anyway.)   (But not X86, MIPS, or RISC-V?  (results of a quick check; I may not be up to date!))

x86 has worse, with {LODS|STOS|MOVS}{_|B|W|D} which can only use SI for loads and DI for stores, and either increments or decrements SI and/or DI depending on a flag in the EFLAGS register.  Not to mention the REP{_|E|Z|NE|NZ} prefixes to make them a 1-instruction loop.

RISC-V has no auto-increment or auto-decrement, not even for the stack. It also has no notion of "the stack" at the base ISA level -- it's only at the software ABI level that a particular stack pointer register is designated.

It's not impossible that in future a "store with writeback of the effective address to the base register" might be added, like in PowerPC. But not loads. Loads might in future get a "form the effective address by adding two registers (maybe with scaling)". Both fit neatly in the "read two registers and write one register" pipeline model, and despite being asymmetric they actually can work together very neatly in a loop, where you often want to read two (or more) values from memory, calculate something, and write one value back. e,g,

Code: [Select]

  addi rD,rD,-4
  sub rS1,rS1,rD
  sub rS2,rS2,rD
loop:
  lw rA, (rS1, rD)
  lw rB, (rS2, rD)
  add rC,rA,rB
  sww rC, 4(rD) ; mem <- rC, rD <- rD+4
  blt rD,rLimit,loop

At present this code would be:

Code: [Select]

loop:
  lw rA, 0(rS1)
  lw rB, 0(rS2)
  add rC,rA,rB
  sww rC, 0(rD)
  addi rD,rD,4
  addi rS1,rS1,4
  addi rS2,rS2,4
  blt rD,rLimit,loop

This eliminates having to explicitly increment rD, rS1 and rS2 inside the loop, at the cost of an instruction to set each one up before the loop. So the code size is identical, but it helps speed if the loop executes more than once.

sww could use the "spare" opcodes that result from loads having load and load-unsigned (e.g. LW, LWU) but only needing one kind of store. You could use SWU (Store Word with Update) as the mnemonic instead of the SWW (Writeback) above, but that could cause confusion between Unsigned and Update :-)

[legacy]

Why are you using C at all in those critical projects?

The OS and the firmware are written in C.
The application is written in Ada.
C++ cannot be (yet) used for reasons I haven't yet understood.

[legacy]

in today's world we want everyone to pass the test without putting any work in.

Yup. Our automatic and autonomous tests aim for this. But also consider that a part of our "test-cases" is recycled and used to help guys and robots in production to test what they build.