How does software "work"?

[LordFerret]

3 minutes ago, kerbiloid said:

Using C for big programs nowadays is like growing a mammoth directly from DNA. Funny but expensive.

Funny, but for the past year and a half or so they've been discussing doing exactly that.

Sometimes it is worthy to reinvent the wheel... except for my stinking Android phone, which updates its code every single day... has me convinced they don't know what they're doing.

[Green Baron]

1 hour ago, LordFerret said:

I'm not so sure about that.  Back in the day, one of the major issues I/we faced with people developing with C is that they'd use the 'large model' during compilation... this resulted in a huge exe, which often called in equally huge overlays as well.  Nothing like pulling in an entire runtime library when you only need 2 or 3 modules from it.

I'm sure this is all changed these days. Yes? (Or am I dreaming lol)

Right you are :-) C, like many other languages, can easily be modularized. There is no size limit to a project other than the space on disk. Libraries are loaded and released dynamically when needed, so memory isn't a limiting element either (it's the system bus and data transfer that hinder most). In a top-down approach a huge program is broken down into manageable "chunks" depending on need and purpose, and there are other approaches. When i said >20 million lines i meant that literally. I am not sure if there is much code (if at all) from the 90s in a modern kernel(*), from whatever OS, compiler or library. Too many people work on these things and too fast are the changes, also much has changed in the language (and in other languages as well).

But i am just a humble hobby tinkerer and by no means knowledgeable, just posting the common places. One can have a look at a big project by simply loading down the sources from kernel.org for example (~100mb). They are actually quite well readable i find :-)

C is not a mammoth, rather a Ferrari.

Not commenting on mammoth DNA because too far ot :-)

(*) That actually might be more the case with Windows and its need for backward compatibility than with Linux and its need for stability and speed, i guess ... Also, Linux' packaging systems with shared objects and references to them are more flexible than many windows applications that all bring their own dlls in different versions, but i may be wrong here.

Edited February 26, 2019 by Green Baron

[kerbiloid]

12 minutes ago, Green Baron said:

C is not a mammoth

C itself isn't. A big non-OOP project is. 

 

[wumpus]

hello world.c compiles to 6,704 bytes on my Linux installation.  That's a lot better than what I remember, but still a lot compared to what it took on DOS assembler (of course, I think the smallest non-zero file has to take up at least 4096 bytes, thanks to disk sectors.  Filesystems may require even larger minimums).

Of course, a decade or two ago people might have considered assembler for large projects.  C seems to be heading the same direction.  C++ might as well, but probably more for security reasons than "no apparent improvement for all the extra difficulty".

[magnemoe]

On 2/25/2019 at 4:01 PM, Green Baron said:

C abstracts the assembly level away.

But you can easily integrate and even inline assembly routines. Only your code isn't portable any more afterwards.

Remember using assembly to get reasonable speed on an prototype of an game I made. 
It did not run on most other computers back in 1985. 
Note that late in generation console games tend to use plenty of it to speed stuff up as their systems start getting very obsolete compared to pc. 
Consoles had the benefit of having the same hardware but this is changing to.