Does anybody learn C any more?

[free_electron]

Also, C is essentially the first compiled language I expect to see "deployed" on any new chip that comes out.

Which is madness in itself. C was developed for the PDP architecture and wants to allocate stack and heap. C fits like a wrench on a pig on anything that is not such an architecture...

[free_electron]

If there was any way in the world to eliminate the ';', the language designers, the smartest people in computer science, would have done it. 

The simplest, and one of the oldest, language did that : BASIC.  no need for semicolons or other line terminators. Has continuation character.
According to your statement all those 'language designers' must be total idiots if they can't do something simple BASIC can...

[free_electron]

However, due to storage limitations, the B compiler had to generate an output in a single pass. This technique was carried forward into C.

That was more than 60 years ago ... can we PLEASE update the syntax a bit ? it's nearly 2020... storage is no longer an issue.
Update the compiler so that semicolons are 'optional'.

[hamster_nz]

However, due to storage limitations, the B compiler had to generate an output in a single pass. This technique was carried forward into C.

That was more than 60 years ago ... can we PLEASE update the syntax a bit ? it's nearly 2020... storage is no longer an issue.
Update the compiler so that semicolons are 'optional'.

No! Leave the historical relics alone!

Each semicolon is a time to pause and reflect on on why on earth '\' was use for the DOS file separator!

[coppercone2]

;

[legacy]

The "tab" alias "&#9" alias "\t" alias 0x09 has been always forbidden and banned in every task I have ever done in Avionics.

Before committing a source to Doors (it's like Git) I have to filter the file and replace each 0x09 with 0x20, and it's has been so boring that the first thing I did was a C program that does the job, and does format as well the text too according to a template.

[Berni]

Yeah C is not perfect but its does what it was meant to do really well.

I do agree that they should get rid of the ; and replace it by something like the _ line continuation character from VisualBasic, but apart from some extra syntax sugar here, what more would you want from C anyway?

The C language was meant to stay close to the hardware, as a result while you are coding you have a good idea what sort of machine code is going to come out of it when compiled and how things are going to be arranged in memory. Its almost just assembler language turned into a form that is actually readable by humans. It does this really well in my opinion.

I'm not saying fancier higher level are bad because they hide away the hardware from you. In fact when programing under a OS i much prefer C#. The real question is why the hell does C# have those damn semicolons;

[legacy]

Which is madness in itself. C was developed for the PDP architecture and wants to allocate stack and heap.

This depends on the "machine layer" of the compiler, not by the language itself.

On a RISC machine, you can use the stack as well as registers for passing parameters to a subroutine (function or procedure), as well as you can use a register for the returning value.

On HC11 it's mandatory that you use the stack (because HC11 is a stack-machine, which only has one general purpose register), but on PowerPC (with has many gp registers) it's optional.

[westfw]

C was developed for the PDP architecture and wants to allocate stack and heap. C fits like a wrench on a pig on anything that is not such an architecture.

Lots of C programs never go near the heap...

And - do you have an example "modern" language that doesn't want a stack?  (that's actually a serious question.  I used to use a Fortran Compiler that used "store the current PC at the target memory location and resume execution at target+<PCsize>" and didn't allow recursion, but that was 40-odd years ago.

[legacy]

but apart from some extra syntax sugar here, what more would you want from C anyway?

In avionics, we have to filter each source on MisraC validators. This means that the standard C language has too many degrees of freedom, and too many of them are poison traps.

Besides, people do usually abuse of these degrees of freedom offered by the standard C language, and sources do usually look ugly and crappy.

A native "Misra compliant C language" (we call it "safeC") would solve it.

I would also appreciated some new features grabbed from Ada (strong types, restricted counters, barriers, etc) and a minimal mechanism to facilitate OOP, because the C++ language offers too many, and it's too bloated.

Oh, and even something to avoid people to write "goto err;". When you see it in the C source of a serious operating system (e.g. Integrity OS, for which you have to pay 20K euro) ... it means that the C language does not offer any better alternative.

"Goto err:" has been found in
- Linux
- VxWorks
- NewOS (BeOS clone)
- Integrity OS
- ucOS/2
- XINU
- ...

[legacy]

do you have an example "modern" language that doesn't want a stack?

it depends on what. Anyway, Erlang is a modern language and it's entirely based on a stack, this because it's a recursion oriented language, like LISP, so it wants a big stack to operate.

[Berni]

Also in terms of stack, how do you think pretty much all modern CPUs call a subroutine? They all have a register that is used as a stack pointer and the instruction for returning from the subroutine requires the return pointer to be sitting on the stack.

As for the heap pretty much every programing language has something to do with it. As soon as you want to dynamically allocate memory you need it. If you are running on bare metal without the OS then the heap is all of your leftover RAM. If you are running under a OS then your heap is the leftover chunk of RAM that was allocated to you by the OS. When you call malloc(1) you don't get the OS giving you 1 byte of RAM, it just gives you a free address in the chunk of RAM it set aside for you before hand as your heap, if you run out then it assigns another chunk to you.

[legacy]

Concerning semicolon ";", it's a statement separator, so I don't understand the point because it simply signals the end of statement, and this is pretty logical. The philosophy is that whitespace is irrelevant, and this allows flexibility in how the code is formatted as formatting is not part of the semantic meaning.

I mean, some languages use the new line character as statement separator, but languages which ignore all whitespace tend to use the semicolon, thereore the statement separator is a logical choice.

[legacy]

Without a statement separator "a tool" might not be able to recognize each statement, with at least two possible interpretations.

It might be easy to resolve in a "compiler" because who writes a compiler is usually a badass and super smart dude in computer science, but the point is that it is hard to design a programming language without a statement separator to be not ambiguous, and when you have to write "a tool" to operate on the source ... well ... you might be not enough badass for it.

I know, it's an ego problem, just face it.

[legacy]

Each semicolon is a time to pause and reflect on on why on earth '\' was use for the DOS file separator!

I have got it! Balls of confusion when you type on the keyboard. Too many meanings for chars, and thinking about Python, if you wish to extend your statement to more of one line, you have to use the special character '\' to say that the statement has not finished, and ... it's the same '\' char that has a different meaning when you try to type a file path for dos emulator (DOSBox) launched by a python script ... oh, and the 90% of times I do it wrong

This is also a big problem converting Windows file paths to Unix file paths ... ah, the computer science

[Berni]

Yes the compiler needs to know where a statement begins and ends, but newlines can give it a pretty good idea.

Python is a good example. A lot may not know but Python also has semicolon statement separators. If you put ; on the ends of your lines in python it wont throw an error, you can put multiple statements in one line with ; between them and it works just fine exactly like in C. Python won't throw an error if it gets to the end of the line and the statement makes sense.

But then what if you want to split up a line that is too long in Python? In C you just go to a new line and it doesn't care. Well Python does the same, if it gets to the end of the line and the statement does not make sense it just continues reading until it gets to the next new line and checks again if it makes sense now. And if you don't want that you can still just put a \ on the end, this essentially escape characters out the new line so the compiler will ignore it. And there we go the compiler knows where the stamens are without constantly putting ; everywhere.

Still i don't quite like the idea of using tab/space whitespace indenting to define blocks of code, but it works fine and it forces careless people to properly structure there code so its not all bad.

[magic]

And - do you have an example "modern" language that doesn't want a stack?  (that's actually a serious question.  I used to use a Fortran Compiler that used "store the current PC at the target memory location and resume execution at target+<PCsize>" and didn't allow recursion, but that was 40-odd years ago.

Yeah, I think free_electron has some explaining to do, lots of hardware is wired to use a call stack in RAM.

That being said, MIPS for example has a variant of branch instruction which stores the old program counter in designated general purpose register. You could use it to implement a DIY stack or perhaps even some coroutines or whatever.

MIPS is still available in PIC32 and some embedded systems.

edit
Actually it's more than that: every "jump and link" instruction saves the PC to a register, but by default it is one particular register intended for it. So if you are a subroutine and you want to call another subroutine, you have to explicitly push that register on stack if you are ever to use it again to return to your caller.

[Kjelt]

yes. CR/LF that is in the code file the moment you hit the return key on your keyboard. How's that for an elegant solution ?

Yes but somehow the LF character was made invisible/blanked out somewhere in the history before C was created.
This would lead to much confusion esp. nowadays with Windows needing a CRLF for a next line.
IIRC the reason for the semicolon originated that Cobol ended their statement with a space character (need confirmation, not sure).
Since LF was invisible just as the space character … well you get the point.

And actually you don't. The parser should be smart enough to figure it out. it knows when a statement is complete. so the next keyword is the beginning of a new statement.

Oh hell no! Please.
Some programmers can already make code practically unreadable.
Google on best C oneliners for instance and get some spaghetti code that actually works.

It is madness to demand from the programmer to tell the compiler when a line ends. 

Yes but it is not for the compiler but for your colleague who has to review your code.
Humans are pretty good at interpreting stuff as you can see at the example below but that does not mean you can't make it more easy for them.

7H15 M3554G3
53RV35 7O PR0V3
H0W 0UR M1ND5 C4N
D0 4M4Z1NG 7H1NG5!
1MPR3551V3 7H1NG5!
1N 7H3 B3G1NN1NG
17 WA5 H4RD BU7
N0W, 0N 7H15 LIN3
Y0UR M1ND 1S
R34D1NG 17
4U70M471C4LLY
W17H 0U7 3V3N
7H1NK1NG 4B0U7 17,
B3 PROUD! 0NLY
C3R741N P30PL3 C4N
R3AD 7H15.

[Kjelt]

And another reason the ; can be handy.
Some smart ass programmer once put in an easter egg after a line of code after the 250th character on the line.
The code comparator we used back then went to 250 characters so it only reported the difference in the ; character.
Still we did not see it till it hit the customer and then after two reviews did we find it 

[khs]

I remember an older paper I know it exist but I cannot find it at the moment:

The main message is:

A Real Man uses FORTRAN.
Mueslieater*  use Pascal.

Only a Real Man can write and understand FORTRAN spaghetti code.
And a Real Man can write FORTRAN code in every language.

A gleam of hope is C, because it's possible to make the code unreadable with some cryptic pointer modifications..


* Maybe there is a better translation for the German word "Müslifresser" but I don't know it.

[westfw]

how do you think pretty much all modern CPUs call a subroutine?

I think that most modern (RISC) CPUs (ARM, MIPS, and RISC-V as examples) call a subroutine by putting the return address in a register, and loading a new value into the PC.   The whole stack-based "call" instruction that modifies a stack pointer, does a store based on the SP, and changes the PC, is rather CISC-y (especially if the PC is wider than memory.)  Any stack manipulation is done by the prologue and epilogue of the called function (usually as part of a vendor-defined standard API to-be-used for all languages.  But you can get really zippy leaf subroutines that never touch the stack, too.)
(but then they go and implement interrupt controllers that automatically stack stuff.  I'm not quite sure how that works, RISC-iness wise.)


As for semicolons...I don't think enough of you remember just how painful and ugly code looked that needed "line continuation" characters.  The semicolon (from Algol, first?) was a major improvement.(less so now that compilers are good enough to generate equally good code from a series of short statements as from a long expression, and functions with dozens of parameters have been replaced with structure references.  But still...)

[Berni]

how do you think pretty much all modern CPUs call a subroutine?

I think that most modern (RISC) CPUs (ARM, MIPS, and RISC-V as examples) call a subroutine by putting the return address in a register, and loading a new value into the PC.   The whole stack-based "call" instruction that modifies a stack pointer, does a store based on the SP, and changes the PC, is rather CISC-y (especially if the PC is wider than memory.)  Any stack manipulation is done by the prologue and epilogue of the called function (usually as part of a vendor-defined standard API to-be-used for all languages.  But you can get really zippy leaf subroutines that never touch the stack, too.)
(but then they go and implement interrupt controllers that automatically stack stuff.  I'm not quite sure how that works, RISC-iness wise.)

Yeah ARM as a good example of RISC does have a so called link register that holds the return address, so you can call a function and return without using the stack. But you are also required to preserve register state so you do need to use the "push" and "pop" instructions that seam more CISCy. But yes you can optimize it a bit and avoid pushing registers to the stack by doing all the calculations in the same register that is used to give back the return value of the function, and not calling other functions leaves the link register unchanged so it doesn't need to be put on the stack. Also if the function has too many parameters that won't fit in the registers then the compiler will instead chose to pass them in by putting them on the stack before the call. So for more complex functions the stack inevitably gets used for something, not just for holding the return address.

Exceptions to this are some old architectures like the PIC16F where a special area of RAM is dedicated to holding information needed to return from subrutines and the CPUs internal logic uses it to magically return to the right spot when executing the return instruction. This means that the call depth is limited to a certain number of levels before that RAM is used up and it crashes. This sort of concept lives on for interrupt handling where the CPU typically has dedicated hardware to quickly restore its original state after an interrupt.

As for semicolons...I don't think enough of you remember just how painful and ugly code looked that needed "line continuation" characters.  The semicolon (from Algol, first?) was a major improvement.(less so now that compilers are good enough to generate equally good code from a series of short statements as from a long expression, and functions with dozens of parameters have been replaced with structure references.  But still...)

I think id prefer to see something like a \ on the end to tell me i haven't seen everything and i should keep on reading. I rarely see statements split across lines in C and its usually done when calling functions with a ton of parameters or long constant definitions.

In practice you don't really want to stuff too many things in one line anyway, it tends to make code hard to read. After all the very point of programing languages is to make it easy for humans to read code made for machines. You do get used to these ; being everywhere and put them on the end of things without even thinking about it, but really mostly serve to help the compiler, not the person reading the code. Putting the ; in the wrong spot can make for some of the most confusing and embaressing bugs as people who read C code often don't see them anymore as there brain ignores them as just noise, but the oh boy does the compiler see them.

[alank2]

Some of you guys really don't like the semicolon!

The best things about C are that it is portable and produces native code.  I've taken an application written in C from a PC back down to an old NEC PC-6001 running a Z80 by compiling it with z88dk and put it on a virtual "cartridge" to run.  It seems like a lot of people used assembly to get top performance back in the day, but without portability, trying to migrate to something new was very difficult or required a complete rewrite.

[SiliconWizard]

Concerning semicolon ";", it's a statement separator, so I don't understand the point because it simply signals the end of statement, and this is pretty logical. The philosophy is that whitespace is irrelevant, and this allows flexibility in how the code is formatted as formatting is not part of the semantic meaning.

I mean, some languages use the new line character as statement separator, but languages which ignore all whitespace tend to use the semicolon, thereore the statement separator is a logical choice.

Agree. I personally don't have any problem with semicolons (or TABs, which to me are pretty natural for code indentation, as they are for any text indentation really).
OTOH, relying on whitespace for anything else than as identifiers/keywords ('tokens') separator is way slippery IMO. Not even talking about the potential issues when using some diff tools.

[legacy]

It seems like a lot of people used assembly to get top performance back in the day

Yup. If you love RISCOs by Acorn, the first releases of their RISCOS were written entirely in arm assembly with a couple of scripts written in Acorn-basic. The same applies to the first AmigaOS classic.

I have recently bought a book written by a few writers that usually wrote for Dr. Dobb's Journal (DDJ). It's about 200 pages, a true collection of routines written in 68k and hc11 assembly. Some are very nice, neat, and useful, and there is the full source of a gw-basic, which was originally written for the 68k Tutor board.

Those lists show there were some tips and tricks to organize the code in a portable way, like the choice of a documented way to attribute a meaning to each register, or to some special location of the ram, or even more interesting, a way to define system traps and system services. And, of course, there are also macros, even for the earlier Acorn DDE that did support them.


Those programmers were more well organized than me about "how you manage your code"