You think assemblers don't support expressions? Sure, they're limited, but they absolutely allow expressions.
functions
A name that has been mapped to an address that can be jumped to using standard C calling conventions, no more, no less.
types
Yes, there are different instructions in assembly for working with different "types" as well. A language needs some kind of construct to decide what kind of instructions to generate.
typedefs
Now I *know* you don't know what the fuck you're talking about.
Different assemblers have all kinds of macros and other abstractions like labels. A typedef is nothing but syntactic sugar. It abstracts nothing at the assembly/machine level.
ALL of those things are abstractions that don't exist in asm.
Ya, OK. So C has more "abstractions" than your-favorite-assembler. What's your point?
Everything beyond pure opcodes has some kind of abstraction.
Sure, as far as assembly is also an abstraction from machine code.
Hm. It's almost as if I already said that. It's no fucking wonder American software firms are hiring from India, if you're any kind of example of the 'new blood'.
No, there most certainly is not. There are about a thousand.
which today's code monkeys have either forgotten or never learned:
Sorry, but as I said previously, I wrote my first C compiler for a PDP-11/04 that I rescued from a trash bin in the late 90s from outside DECs offices in Redmond, WA as they went defunct.
A C compiler does only a few things (modern optimizing compilers excluded). It maps control primitives to assembly, assigns names to addresses depending on whether they're static, or to stack space if they're local, and allocates registers for function calls. That's it. You're free to call that high level until you're blue in the face, but it just demonstrates how ignorant you are.
Unoptimized C can be *perfectly* decompiled using nothing but a map (names lost, of course). One day, when you become a big boy, you may even learn that on your own.
All a C compiler does, at its most basic, is map addresses to names, and allocate registers and stack space for function calls, and generate the assembly for the basic control constructs.
May I suggest the Dragon Book, so that you actually know what you're talking about in the future?
Another idiot who doesn't know what an HLL is. *sigh*
Another idiot who thinks a spectrum can be defined as a boolean. *sigh*.
C is a third-generation language, one step above assembly, and was designed to map directly to assembly for the PDP-11.
Your move, fuckstick.
C has no abstraction from the machine? Are you high?
Sure, as far as assembly is also an abstraction from machine code.
I think we're done here.
Indeed. You're too fucking ignorant to know how ignorant you are.
No HLL translates "directly to assembly," in that case.
Precisely. That's why only a fool calls C a "HLL".
and C has them no matter how you like to spin it.
C the language? No, it does not.
The closest you can get, is perhaps with TLS extensions which require some library support built into the language itself.
You need to accept that you simply have no idea what the fuck you're talking about.
And I think you are overestimating their utility, while failing to acknowledge the drawbacks of attempting to fight Rust's "safety" mechanisms in a low-level environment.
Also, I need to put this here- safe/unsafe are loaded terms.
"unsafe" code is not unsafe. "safe" code is not safe.
Those words mean statically verified to not succumb to a certain set of programming errors.
You can write unsafe "safe" code in Rust, and you can write "safe" code in C.
Rust's "safety" is compiler training wheels. I'm all for buying into the argument that the world at large needs compiler training wheels. But I think the argument that all things can be accomplished easier and better with those training wheels is brain-dead, and made by people who don't do actual low level programming.
We don't disagree at that the point where you're code requires less work arounds than actual code, you're on solid ground considering using other code, but the core of Redox is just that- more work-arounds than code. It's a POC to build a system from the ground up using assembler and Rust, purposefully avoiding C. I see little advantage in it, and the class of programming errors it protects against does *not* in the slightest imply systems security, since most of the domains where those problems exist in require unsafe {} Rust code.
PS: The concept behind Rust is to keep your unsafe areas clearly marked as such. Presumably not every piece of code needs to do unsafe things. The Linux kernel has over 10 million lines of code.
I don't disagree with you, here.
There are certainly subsystems that can be cordoned off to be written in a safer language. OSX does this with their DriverKit stuff.
One could, if they wanted, implement parts of the kernel in a safer language, but many parts of it will simply always need to be done in C.
Redox is a good example, look at the low-level parts like the bootloader.
What was the point of writing it in an esoteric safe language when literally 95% of the lines in that section are marked unsafe?
It would have been cleaner and easier to read in C.
Untrue. Take a language like C++ for example. Those instructions do *not* translate directly to assembly. There are constructs that require a runtime to work.
C does not. That is both a barrier to it being a good design choice for higher level applications, and a requisite for being able to write code that runs on bare metal.
Absolutely nothing.
But it's also very useful to be able to add structured data within those KVs.
I wrote my own parser that has very lax rules.
For example, quotes not required, nor even commas.
JSON can actually have correct formatting inferred very easily.
Well, it's a loaded question. With it an implied argument that having not used something means he is not qualified to know The Truth about it.
He was therefore on solid ground in implying that your question was meaningless, or at best, baiting him.
Let's recap.
Oh please... Rust is for people that want to be more productive with their time at the expense of some additional system resources. For the majority of software projects it is a good deal.
The comment he was replying to. That is rhetoric. You know what rhetoric is, quite obviously, because you accused this poster of exactly that.
Nonsense. That is just the propaganda the Rust fanatics put out.
This was his reply. It was factually correct. He called out rhetoric for what it was- propaganda.
You followed that up with your loaded question, giving no one reading any reason to think that you're doing anything but trying to fool a high-school aged kid into walking down that illogical chain of discussion.
There is merit to the argument that it is a fancy assembler however, even though I see where you're coming from in saying that it is not.
It really is a structured representation that was designed to be converted directly into assembly language in a deterministic fashion.
The first C compiler I wrote was little more than a fancy and intelligent macro expander.
The fact is, a C compiler can produce code that will run on bare hardware with no runtime, and a very very tiny assembly loader.
That makes it, IMO, a de facto low level language, regardless of what the varying various subjective opinions are.
A C compiler's most simple implementation is quite literally almost a macro expander for a particular architecture's assembly language.
Now- the fact that a modern C compiler is mind-bogglingly more complicated doesn't change the fact that C is, in itself, a structured representation of assembly.
This isn't the statement of an ignorant person, this is the statement of someone who has literally written a lightweight C compiler for the PDP-11/04.
Yes, "we can call typed functions through" "void pointers" but we do so by declaring what that the pointer type is, and this is not possible because "Assembly doesn't care" but because it is useful.
No- this is possible quite literally because "assembly doesn't care". Your function pointer with all of its static typing information in the end is just a memory address, and the function call, with all of its static typing information, just a branch instruction. C allows you to cast it as you wish, regardless of whether it is correct (by you telling it that this arbitrary function has this type, really, i promise, i swear) and just make the fucking jump. This is possible because your processor's branch instruction just don't give a fuck.
The rest of your comment wasn't worth reading given that your beginning premise was so ridiculously fucking dumb.
I think sometimes people lose sight of the base of it all.
No matter how you swing it, eventually somewhere in that manufacturing chain, someone had to build something with hammers and screwdrivers, thus it is with C.
My perspective is probably skewed because I have written a lot of code to run directly on bare hardware with no runtime or operating system. I find myself wondering how I'm supposed to access memory-mapped registers "safely" when the idea of void pointers and uninitialized variables are the devil. How I'm supposed to write code that deals with bootstrapping a processor's MMU. How I'm supposed to write an interrupt handler when different processors have different requirements for ISR stacks.
Writing software in that domain isn't well suited to any tool that thinks it can define what "safety" is for all platforms.
That being said, I definitely think writing larger programs at higher layers seems a little bit quixotic in this day and age when done in C, unless you need to be ridiculously performant, for example, something like DPDK where your goal is to process network packets at the highest conceivable speed.
For the same reason we still have hammers and screwdrivers, the world will continue to need C.
For the people who have the luxury of working on a project where they can use table saws with fancy arresting devices that prevent them from chopping their fingers off- that's awesome. For the people building watches, quit trying to tell them what kind of tool they should be using when you have no fucking idea what they even do.
Totally agree on all points except one... I use YAML/JSON for all my configs these days. It's pretty damn useful to have a well-defined and well-known structured data representation format that you can edit with emacs
Don't engage that guy. He will throw illogical questions at you until you die of old age, and all the while think that every one you refuse to engage is a point in his favor. It's exhausting.
VDSL2 only works over short distances like under 1 km. I've only come across VDSL2 within buildings where you get fiber to the basement, and then they use the existing phone lines to get to the apartments.
That's exactly what we use them for. We prefer to wire for Ethernet where we can get the tenants to pay for it, but when we can't, we use VDSL2. It's not a competitor to ADSL.
Other than that, my experience has varied, and neither cable nor ADSL is the clear winner. Both are decent tech but have sometimes been ruined by bad service from the ISP. It's hard to do a proper comparison because you can only get cable from a single company. I imagine cable would win over long distances because it's actually been designed for high frequencies and bandwidths to begin with. OTOH, the usual complaint about cable is that capacity is shared between many subscribers, but that's not really the fault of the technology itself, as the capacity issue can come up at any stage within the ISP.
Everything you said in here is accurate.
However, as the senior network engineer at a company with about ~10,000 ADSL customers, ~6,000 fiber customers (FTTH/FTTP MDU)... I gotta say, I'm amazed anyone goes for ADSL if they have a choice between that and cable. Cable networks can, like any network, be operated by shitstain network operators... but technologically speaking, DOCSIS3 is so much better than even ADSL2, that any comparison between them makes me go "lolwut?"
Slashdot Mirror
There is no "spectrum," fool. There is a definition for HLL, which today's code monkeys have either forgotten or never learned:
Whoops. I'll quote for you if you have a reading difficulty.
C is terse, low-level and permissive
Oh shit, there's more!
BCPL is low-level, typeless and block-structured, and provides only one-dimensional arrays
BCPL is what C was written to replace, also considered a low-level language at the time.
Next stupid argument, shit stain.
Blocks, variable scoping
C has 2 scopes, global and stack.
expressions
You think assemblers don't support expressions? Sure, they're limited, but they absolutely allow expressions.
functions
A name that has been mapped to an address that can be jumped to using standard C calling conventions, no more, no less.
types
Yes, there are different instructions in assembly for working with different "types" as well. A language needs some kind of construct to decide what kind of instructions to generate.
typedefs
Now I *know* you don't know what the fuck you're talking about.
Different assemblers have all kinds of macros and other abstractions like labels. A typedef is nothing but syntactic sugar. It abstracts nothing at the assembly/machine level.
ALL of those things are abstractions that don't exist in asm.
Ya, OK. So C has more "abstractions" than your-favorite-assembler. What's your point?
Everything beyond pure opcodes has some kind of abstraction.
Sure, as far as assembly is also an abstraction from machine code.
Hm. It's almost as if I already said that. It's no fucking wonder American software firms are hiring from India, if you're any kind of example of the 'new blood'.
There is a definition for HLL
No, there most certainly is not. There are about a thousand.
which today's code monkeys have either forgotten or never learned:
Sorry, but as I said previously, I wrote my first C compiler for a PDP-11/04 that I rescued from a trash bin in the late 90s from outside DECs offices in Redmond, WA as they went defunct.
A C compiler does only a few things (modern optimizing compilers excluded). It maps control primitives to assembly, assigns names to addresses depending on whether they're static, or to stack space if they're local, and allocates registers for function calls. That's it. You're free to call that high level until you're blue in the face, but it just demonstrates how ignorant you are.
Unoptimized C can be *perfectly* decompiled using nothing but a map (names lost, of course). One day, when you become a big boy, you may even learn that on your own.
All a C compiler does, at its most basic, is map addresses to names, and allocate registers and stack space for function calls, and generate the assembly for the basic control constructs.
May I suggest the Dragon Book, so that you actually know what you're talking about in the future?
Another idiot who doesn't know what an HLL is. *sigh*
Another idiot who thinks a spectrum can be defined as a boolean. *sigh*.
C is a third-generation language, one step above assembly, and was designed to map directly to assembly for the PDP-11.
Your move, fuckstick.
C has no abstraction from the machine? Are you high?
Sure, as far as assembly is also an abstraction from machine code.
I think we're done here.
Indeed. You're too fucking ignorant to know how ignorant you are.
No HLL translates "directly to assembly," in that case.
Precisely. That's why only a fool calls C a "HLL".
and C has them no matter how you like to spin it.
C the language? No, it does not.
The closest you can get, is perhaps with TLS extensions which require some library support built into the language itself.
You need to accept that you simply have no idea what the fuck you're talking about.
That's a fair opinion to hold.
And I think you are overestimating their utility, while failing to acknowledge the drawbacks of attempting to fight Rust's "safety" mechanisms in a low-level environment.
Also, I need to put this here- safe/unsafe are loaded terms.
"unsafe" code is not unsafe. "safe" code is not safe.
Those words mean statically verified to not succumb to a certain set of programming errors.
You can write unsafe "safe" code in Rust, and you can write "safe" code in C.
Rust's "safety" is compiler training wheels. I'm all for buying into the argument that the world at large needs compiler training wheels. But I think the argument that all things can be accomplished easier and better with those training wheels is brain-dead, and made by people who don't do actual low level programming.
*your code
d'oh.
We don't disagree at that the point where you're code requires less work arounds than actual code, you're on solid ground considering using other code, but the core of Redox is just that- more work-arounds than code. It's a POC to build a system from the ground up using assembler and Rust, purposefully avoiding C. I see little advantage in it, and the class of programming errors it protects against does *not* in the slightest imply systems security, since most of the domains where those problems exist in require unsafe {} Rust code.
PS: The concept behind Rust is to keep your unsafe areas clearly marked as such. Presumably not every piece of code needs to do unsafe things. The Linux kernel has over 10 million lines of code.
I don't disagree with you, here.
There are certainly subsystems that can be cordoned off to be written in a safer language. OSX does this with their DriverKit stuff.
One could, if they wanted, implement parts of the kernel in a safer language, but many parts of it will simply always need to be done in C.
Redox is a good example, look at the low-level parts like the bootloader.
What was the point of writing it in an esoteric safe language when literally 95% of the lines in that section are marked unsafe?
It would have been cleaner and easier to read in C.
Untrue. Take a language like C++ for example. Those instructions do *not* translate directly to assembly. There are constructs that require a runtime to work.
C does not. That is both a barrier to it being a good design choice for higher level applications, and a requisite for being able to write code that runs on bare metal.
Absolutely nothing.
But it's also very useful to be able to add structured data within those KVs.
I wrote my own parser that has very lax rules.
For example, quotes not required, nor even commas.
JSON can actually have correct formatting inferred very easily.
I did, and hence why I use it...
JSON/YAML is actually *very* easy to parse.
XML- ya, I'm with you there.
Agreed... That is why I called it out as rhetoric/propaganda?
He was therefore on solid ground in implying that your question was meaningless, or at best, baiting him.
Let's recap.
Oh please... Rust is for people that want to be more productive with their time at the expense of some additional system resources. For the majority of software projects it is a good deal.
The comment he was replying to. That is rhetoric. You know what rhetoric is, quite obviously, because you accused this poster of exactly that.
Nonsense. That is just the propaganda the Rust fanatics put out.
This was his reply. It was factually correct. He called out rhetoric for what it was- propaganda.
You followed that up with your loaded question, giving no one reading any reason to think that you're doing anything but trying to fool a high-school aged kid into walking down that illogical chain of discussion.
There is merit to the argument that it is a fancy assembler however, even though I see where you're coming from in saying that it is not.
It really is a structured representation that was designed to be converted directly into assembly language in a deterministic fashion.
The first C compiler I wrote was little more than a fancy and intelligent macro expander.
The fact is, a C compiler can produce code that will run on bare hardware with no runtime, and a very very tiny assembly loader.
That makes it, IMO, a de facto low level language, regardless of what the varying various subjective opinions are.
Now- the fact that a modern C compiler is mind-bogglingly more complicated doesn't change the fact that C is, in itself, a structured representation of assembly.
This isn't the statement of an ignorant person, this is the statement of someone who has literally written a lightweight C compiler for the PDP-11/04.
Yes, "we can call typed functions through" "void pointers" but we do so by declaring what that the pointer type is, and this is not possible because "Assembly doesn't care" but because it is useful.
No- this is possible quite literally because "assembly doesn't care". Your function pointer with all of its static typing information in the end is just a memory address, and the function call, with all of its static typing information, just a branch instruction. C allows you to cast it as you wish, regardless of whether it is correct (by you telling it that this arbitrary function has this type, really, i promise, i swear) and just make the fucking jump. This is possible because your processor's branch instruction just don't give a fuck.
The rest of your comment wasn't worth reading given that your beginning premise was so ridiculously fucking dumb.
I think sometimes people lose sight of the base of it all.
No matter how you swing it, eventually somewhere in that manufacturing chain, someone had to build something with hammers and screwdrivers, thus it is with C.
My perspective is probably skewed because I have written a lot of code to run directly on bare hardware with no runtime or operating system. I find myself wondering how I'm supposed to access memory-mapped registers "safely" when the idea of void pointers and uninitialized variables are the devil. How I'm supposed to write code that deals with bootstrapping a processor's MMU. How I'm supposed to write an interrupt handler when different processors have different requirements for ISR stacks.
Writing software in that domain isn't well suited to any tool that thinks it can define what "safety" is for all platforms.
That being said, I definitely think writing larger programs at higher layers seems a little bit quixotic in this day and age when done in C, unless you need to be ridiculously performant, for example, something like DPDK where your goal is to process network packets at the highest conceivable speed.
For the same reason we still have hammers and screwdrivers, the world will continue to need C.
For the people who have the luxury of working on a project where they can use table saws with fancy arresting devices that prevent them from chopping their fingers off- that's awesome. For the people building watches, quit trying to tell them what kind of tool they should be using when you have no fucking idea what they even do.
Eh, that's like saying a dude with an AK-47 in Syria subscribes to the ideology of Kalashnikov.
Your logic is borked, amigo.
Totally agree on all points except one... I use YAML/JSON for all my configs these days. It's pretty damn useful to have a well-defined and well-known structured data representation format that you can edit with emacs
Don't engage that guy. He will throw illogical questions at you until you die of old age, and all the while think that every one you refuse to engage is a point in his favor. It's exhausting.
Clients do not talk to each other in an 802.11abgn/ac station network.
Your anecdote has another explanation.
VDSL2 only works over short distances like under 1 km. I've only come across VDSL2 within buildings where you get fiber to the basement, and then they use the existing phone lines to get to the apartments.
That's exactly what we use them for. We prefer to wire for Ethernet where we can get the tenants to pay for it, but when we can't, we use VDSL2. It's not a competitor to ADSL.
Other than that, my experience has varied, and neither cable nor ADSL is the clear winner. Both are decent tech but have sometimes been ruined by bad service from the ISP. It's hard to do a proper comparison because you can only get cable from a single company. I imagine cable would win over long distances because it's actually been designed for high frequencies and bandwidths to begin with. OTOH, the usual complaint about cable is that capacity is shared between many subscribers, but that's not really the fault of the technology itself, as the capacity issue can come up at any stage within the ISP.
Everything you said in here is accurate.
However, as the senior network engineer at a company with about ~10,000 ADSL customers, ~6,000 fiber customers (FTTH/FTTP MDU)... I gotta say, I'm amazed anyone goes for ADSL if they have a choice between that and cable. Cable networks can, like any network, be operated by shitstain network operators... but technologically speaking, DOCSIS3 is so much better than even ADSL2, that any comparison between them makes me go "lolwut?"
VDSL2 is a thing
Kinda, but not as a replacement for ADSL.
We use VDSL2 in FTTP deployments where it's not reasonable to wire the entire premises for ethernet.