241–250 of 363 posts
Earlier quoted context omitted.
Nope in the above comment you claim something else. Here is where you claim C requires UNIX like OS: https://news.ycombinator.com/item?id=20828974 Let me tell you, in embedded development we run C on bare metal or under RTOS. There is no UNIX in sight. And the code is portable to many CPU architectures.
A snowflake RTOS without POSIX, call me amazed.
Earlier quoted context omitted.
I'm not arguing that it is not? It's funny though how many people saw value in C but not in Algol. Maybe C has something going for it?
Free beer alongside a free beer OS, instead of paying thousands of dollars for timesharing OSes like VMS.
Earlier quoted context omitted.
I've read the Eiffel books, and tried to use the Eifell tools, on Windows - a horrid experience. I am not a "UNIX folk" and I can't imagine what comparing UNIX and Eifell has to do with anything. It is basically an unuseable programming language and toolset, promoted by an egomaniac with a grudge against C++. If you disagree, please provide a link to something medium sized and useful written in Eifel.
Useful to whom? To you or the companies that keep Eiffel Software in business for 30 years?
Such as? If you can't provide links to people using Eiffel succefuly, then maybe there are none.
Based on another thread - I think the following topic should be an interesting one for HN to chew on: If someone wanted to write systems type of programming (whether it be embedded or Unix tools or even writing a library), should they go for C (C23) or Rust today?
I'm going for C, because I am experienced with C and despite it being more tedious, with having to do everything yourself, I stick with it because the compile times, and in fact the compile process, are so much faster and simpler. I really enjoy the direct feedback I can get. I considered C++ but that too had terrible compile times. Ideally a debug build should simply not take longer than 100ms for a codebase that is…
Earlier quoted context omitted.
This tool helps as much with C (or even higher level languages) as it does with Assembly. It doesn't change the fact both languages work on the same abstract machine model.
What is C's abstract model for NEON?
https://github.com/projectNe10/Ne10
You have not yet shown an argument for why c is not a portable assembly.
Earlier quoted context omitted.
There are plenty of C compilers written in C. Large compiler suites for C/C++ are usually written in C++. But as a contributor to GCC, I can say that large parts of the code still look very much like C.
Plenty of compilers... right. If you cannot compile GCC with a C compiler, it isn't C.
It is true that GCC is not written in C anymore, but it is easy to see that the code is still relatively close. I am also myself writing a C compiler in C at the moment and there is no problem at all.
Earlier quoted context omitted.
I don't know what are you trying to say? How does this follow from the parent post?
It follows that the Web made JavaScript unavoidable, then nodejs made it available everywhere else. Likewise UNIX made C unavoidable in systems programming for timesharing servers, eventually like JavaScript outgrew the browser, certain people wanted to run C in their microcomputers.
Earlier quoted context omitted.
> C not having fancy built-in structures means programmers are more careful about choosing simple ones Resulting in linked lists everywhere which have pretty terrible performance characteristics. You should be worried about those way before the occasional vector push reallocation cause you any problem. (And you can specify initial capacity so there is that)
linked lists - true, but at least when you write them you'll be certain of what they do, and, coupled with knowledge of cache performance, precisely how bad they are. About reallocation I don't even mean the copying, but just the code needing to check for the chance overflow on every push. Besides the obvious waste of instructions to check for that, it also clobbers registers even if the branch isn't taken, and thus…
Earlier quoted context omitted.
The cppreference.com link says it removes "Representations for signed integers other than two's complement" - this could be pretty significant in making many previously implementation-defined programming patterns strictly conforming, but is it true? Doesn't seem mentioned in the Twitter thread.
This is the accepted twos complement proposal: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2412.pdf It seems like a sensible simplification to me. Is there any architecture that doesn't use twos complement (eg. uses separate sign bit + magnitude) and could run C code?
> Overflowing operations and out-of-range conversion are generally mapped to modulo operations and cannot trap or raise signals.
This would be a problem on x86, where INT_MIN / -1 causes a #DE (divide error) exception. In C17 that is fine because signed integer overflow is undefined behaviour. But if the behaviour is defined, that trap would have to be caught or avoided.
The best solution for performance would be to have a new trap handler. That would have to parse the instruction to find its length, and the divisor (in memory or register) to differentiate it from division by zero, write the constant result and remainder into the destination registers (always rax and rdx thankfully) and then continue with the next instruction.
But I think this could be difficult to do in a fool-proof way, with how CPU exceptions are handled in different operating systems. Some operating systems might not even allow it at all.
Finally C catches up with Algol 60 boolean types, it only took 60 years. Maybe in another 60 it will get proper strings and arrays.
C must be really amazing compared to Algol than. It powers today's computing infrastructure without having proper boolean type. Are there any widely used applications written in Algol?
MCP is not today widely used in the same way, say, React or Linux is, but businesses used and depend on it such that it's still sold and supported, as Unisys ClearPath MCP.