It seems most people don't really understand the core of systems programming.
Let me try to summarize:
There can be no limitations of any kind in terms of expressing to the machine, precisely how the machine should behave.
Period. No ifs-ands-or-buts about it.
This means you must be able to define memory layout, management, instruction behavior and semantics, and optimally, be able to predict cache locality (arrays vs. linked-lists are the trivial but canonical example)
The moment the programming language, at any fundamental level, precludes me from defining how the machine should behave with respect to memory, semantics, or otherwise...it ceases to be a language that can be used for systems programming.
Disintermediating the meddling of C compilers is hard enough, languages like Go and Java are 'intractable' to say the least for actual systems programming.
Obj-C is only acceptable in the context of systems programming when you stop using everything that makes it Obj-C and just write C code.
I outlined additions/improvements that could be made to C and utilized in the context of systems (rather than applications) programming.
In a single sentence, it's about fundamentally about POWER and not "speed". That's why the desert-island language is C.
> There can be no limitations of any kind in terms of expressing to the machine, precisely how the machine should behave.
I hear what you're saying but you're overselling C here. Straight up ANSI C has a lot of limitations in telling the machine what to do. Even the various proprietary extensions have limitations right up until you stop writing anything that looks a little bit like C, e.g. you start using "asm" style intrinsics that let you do assembly inline.
>>In a single sentence, it's about fundamentally about POWER and not "speed".
Most code isn't inner loops in device drivers.
My point was that Obj C's behavior should be more or less deterministic, and method calling reasonably fast?
So "more or less" is just not good enough for you. [Edit: E.g. cache interaction is too hard to reason about when doing lookup for method dispatch, etc?]
Well, I'm too laid back to work on your problems. :-) I decided a long time ago that what I really liked most was to create lots of functionality in as short time as possible. But I admire people that care about things and learn about them relentlessly, so thanks for the information.
It seems most people don't really understand the core of systems programming.
Let me try to summarize:
There can be no limitations of any kind in terms of expressing to the machine, precisely how the machine should behave.
Period. No ifs-ands-or-buts about it.
Actually it seems you don't understand that people mean different thing by "system's programming".
Not all system programming is about no-compromise, i.e as it would if it was only about driver or OS coding.
I'd trust Ken Thompson and Rob Pike to understand what system programming is better than some random dude on HN.
That would make it much easier to communicate. From the looks of it systems programming is all about no compromise, specifically for the reasons outlined by the GP. Now I wouldn't know him from Adam but even outside the realm of driver and OS programming there is plenty of room for software that is 100% deterministic in terms of time and space consumed.
Note that the 'alternate usage' term in the page linked above was specifically not what the GP was talking about if I understood it correctly.
>I'd trust Ken Thompson and Rob Pike to understand what system programming is better than some random dude on HN.
You'd be surprised, Pike has more or less retracted the "systems" moniker due to the reaction it got. He avoids the term now as a result.
I know this because I've been watching Go itself very closely.
But hey, it's just Rob Pike. Maybe ken still calls it a "systems" language. I'm still just a random dude on HN who thought plan9 was a fantastic idea and keeps track of Pike's work as a result :)
Let me try to summarize:
There can be no limitations of any kind in terms of expressing to the machine, precisely how the machine should behave.
Period. No ifs-ands-or-buts about it.
This means you must be able to define memory layout, management, instruction behavior and semantics, and optimally, be able to predict cache locality (arrays vs. linked-lists are the trivial but canonical example)
The moment the programming language, at any fundamental level, precludes me from defining how the machine should behave with respect to memory, semantics, or otherwise...it ceases to be a language that can be used for systems programming.
Disintermediating the meddling of C compilers is hard enough, languages like Go and Java are 'intractable' to say the least for actual systems programming.
Obj-C is only acceptable in the context of systems programming when you stop using everything that makes it Obj-C and just write C code.
I outlined additions/improvements that could be made to C and utilized in the context of systems (rather than applications) programming.
In a single sentence, it's about fundamentally about POWER and not "speed". That's why the desert-island language is C.