9 ms·
Some were meant for C [pdf] (2017)
- steveklabnik 3y ago(2017) This always gets 0 comments or hundreds of comments. Some previous ones with more than a handful of comments: * https://news.ycombinator.com/item?id=34640233 https://news.ycombinator.com/item?id=34640233 * https://news.ycombinator.com/item?id=26300199 https://news.ycombinator.com/item?id=26300199 * https://news.ycombinator.com/item?id=19736214 https://news.ycombinator.com/item?id=19736214 * https://news.ycombinator.com/item?id=15179188 https://news.ycombinator.com/item?id=15179188
- tedunangst 3y agoEscaped the dupe detector because four months ago there was an extra slash in the url.
- Joker_vD 3y agoSome of those comments are pure hilarity: "C got popular because it turned out to be ideally suited for DOS. C could deal with near/far pointers. No other language could". Yes, C was very good at having two (or even three, "huge" being fully-normalized far pointers) completely differently sized kinds of pointers, without any proprietary extensions, absolutely, and it caused no problems whatsoever because C memory model indeed presupposes a segmented address space.
- booleandilemma 3y agoThe article that introduced me to "Priest with Balloons", by Tiny Ruins. Based on a true story: https://en.wikipedia.org/wiki/Adelir_Ant%C3%B4nio_de_Carli https://en.wikipedia.org/wiki/Adelir_Ant%C3%B4nio_de_Carli
- qsantos 3y agoThe crux of the argument of this article seems to be that C allows working directly with raw memory, which is necessary for some low-level tasks, such as communication with memory-mapped devices. This is not possible in pure managed language, due to the additional level of abstraction. However, the author themselves state that this is not something that implies that undefined behavior are unavoidable when working close to the metal: In fact, the very “unsafety” of C is based on an unfortunate conflation of the language itself with how it is implemented. Working from first principles, it is not hard to imagine a safe C.13 As Krishnamurthi and Felleisen [1999] elaborated, safety is about catching errors immediately and cleanly rather than gradually and corruptingly I would say that, what they are describing is essentially what Rust has achieved, or at least what it is meant to do.
- quackulus 3y agoAny good docs on memory and data structures for c?
- steveklabnik 3y agoWhile I don't fully disagree with you, I think the author would disagree. This line of argument is also repeated in recent C++ standards papers around "safety," that is, this argument is explicitly saying "memory safety != safety, and safety is more important, and therefore focus on memory safety is bad for safety." I have two responses to this that aren't "back on script." > it is not hard to imagine (from your quote) Sure, we can imagine this language, but it does not exist. Yes in theory maybe if we all did what the author said, C could be that language, but it is simply not today. When people say "C" they mean the C that actually exists, not an alternative implementation that would technically conform to the standard. Pushes have been made in this direction a number of times, from a number of different people, yet the market has spoken. Second, > Consider unchecked array accesses. Nowhere does C define that array accesses are unchecked. It just happens that implementations don’t check them. This is an implementation norm, not a fact of the language. This is just factually incorrect. Let's examine both C89: https://www.open-std.org/JTC1/sc22/wg14/www/docs/n1256.pdf https://www.open-std.org/JTC1/sc22/wg14/www/docs/n1256.pdf and C99: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf > J.2 Undefined behavior > An array subscript is out of range, even if an object is apparently accessible with the given subscript (as in the lvalue expression a[1][7] given the declaration int a[4][5]) (6.5.6). It is literally defined as undefined behavior. While sure, that does mean a particular compiler could implement and document semantics for this, it's by definition not portable, because it is stated as such by the standard.
- quelsolaar 3y agoC, is high level language that happens to map really well to hardware. Much of UB is UB simply because it difficult to effectively detect when something goes in to a state of UB. Writing to a memory address can be done in one instruction, but figuring out if that address is legal to write to is a slow and complicated process. The C standard let an implementation ignore that problem, but it is also does not stopping the implementation from making sure the address is valid before writing to it. Almost no one tries to make such an implementation, because the users have decided they would rather have speed, but anyone can write a ISO compliant implementation without any UB if that's what they want.
- abnercoimbre 3y agoI appreciate this kind of discussion. It's important to note C programmers these days effectively avoid the inherent risks of unsafety by deploying solid memory strategies. For example (self-plug incoming) we're hosting a workshop this summer [0] teaching people to replace a rat's nest of mallocs and frees with an arena-based memory allocator. These sorts of techniques eliminate the common memory bugs. We don't do C programming the way we did back in the 80's and 90's. [0] https://handmadecities.com/boston https://handmadecities.com/boston
- saboot 3y agoVery interested to hear more, will be registering virtually!
- deleted 3y ago[deleted]
- yoyohello13 3y agoWow! I'm really interested in the Boston event. I'm a little afraid I may not be experienced enough though. How master are we talking with these masterclasses?
- abnercoimbre 3y agoIf you are comfortable programming in any systems language and not a complete beginner, this conference is a legit opportunity for growth (and mentorship.) There is no elitism or judgment here—imo you shouldn't miss out!
- Kokichi 3y agoNice plug! Just signed up
- jjnoakes 3y agoI'd be curious if there were any studies done on how much effect this kind of approach has on the number or severity of bugs or security issues in a code base.
- 3y ago
- jcranmer 3y agoI think the main weakness of this paper is that it doesn't really address why C is used in lieu of other "better-C" non-managed languages, such as C++, D, Nim, Rust, or Zig--it's almost entirely focused on the idea that the competitors to C are inherently managed languages, framing the question essentially as a "why C instead of Java?" which is a frustrating approach when you're asking "why not <language which is not Java in the same way C is not Java>?"
- quelsolaar 3y agoC is better because it doesn't try to program for you, it isn't clever, convenient, or have any ideas about how you structure or solve a particular problem. It gives you basic functionality and then gets out of your hair and lets you ge on with programming without making a grand statement about computer science. For people who actually like to program and don't want the language to do it for you that is pretty attractive. It also turns out that if you remove all the fancy abstraction and write everything out, the code becomes very maintainable and easy to manage. The fact that its about as portable as a program can be helps. I find that most people don't want to write C, but almost everyone is pretty happy interacting with C code written by others, because its simple, fast, portable, easy to integrate, and bind to other languages, and most non-C programmers can read it and have a rough idea of what is going on.
- jjnoakes 3y ago> C is better because it doesn't try to program for you, it isn't clever, convenient, or have any ideas about how you structure or solve a particular problem Why is that better though? I personally appreciate it when cleverness and convenience make my life easier, my programs less buggy and less likely to end up in a CVE, or point me toward better structure. > It also turns out that if you remove all the fancy abstraction and write everything out, the code becomes very maintainable and easy to manage History shows that this isn't true though, not in all cases.
- quelsolaar 3y ago> Why is that better though? Some people think so. Hence some where meant for C. > History shows that this isn't true though, not in all cases Not in all cases? I had no idea it was possible to write bad code in C, I must immediately switch to language where all code is always perfect no matter what the programmer does. History does show that most of the largest, longest running, most depended on open source projects like Linux, Apache, Git, MySQL, CPyton, OpenSSL, Gcc, Curl are written in C, so its hard to argue that the language isn't maintainable.
- avgcorrection 3y agoSentimental.
- diego_sandoval 3y agoI have a trivial, superficial gripe with modern languages. I hate this syntax: let variable_name : type = value; I find it extremely ugly. I know that people here have disdain for discussions about syntax [1], and I know that once compiled, the specific syntax doesn't matter that much. But I think that language aesthetics do matter. People say that languages are "just tools", and the output quality is all that matters. But, personally, I would want the tool that I'm going to be spending a significant amount of time working with to be beautiful and feel good. And that's one point where I consider C to be superior: aesthetics. If I start a hobby project, I may start in C, because programming in it makes me feel good, even if it's unsafe. I'm not a language expert, so I don't know if there are good technical reasons for this modern syntax to have replaced C-style initialization, but I think there must be some way to avoid using this modern syntax without losing whatever feature is made possible by it. So, my point is: We shouldn't discard aesthetic considerations so lightly. Languages are not "just [ugly] tools", they can be a medium of artistic expression to some people. [1] https://wiki.c2.com/?WadlersLaw https://wiki.c2.com/?WadlersLaw
- steveklabnik 3y agoThere are good technical reasons. That said, I don’t expect them to be persuasive, but the main reason for doing so is that: 1. It doesn’t require as much context to parse, making tooling easier. 2. It plays nicer with type inference or deduction. These reasons generally trump aesthetics for new language developers, and so I wouldn’t expect to be seeing the C style in newer languages. Also, not everyone agrees aesthetically; I am the polar opposite of you.
- jjice 3y agoI don't think that more modern variable declaration syntax is used because it allows for other things to be expressed syntactically (although maybe it does, like for type inference), but I think a lot of us just think it _does_ look better. I don't mind the C and friends type variable_name = value; style, but I do like the type coming afterwards. I don't feel like there's a tradeoff, I think it's just better across the board, and I assume a lot of people are in that boat as well due to its popularity.
- 3y ago
- chromoblob 3y agoThis "communicativity" is a feature only enabled by fixing a certain execution model (roughly "everything is addressable bytes in memory"). Thus any languages that would support "communicativity" would necessarily need to adopt this model explicitly - which would deprive them of some abstractness, and, I think, even probably make them C-like. In other words, there is simply nothing other to do than "creating new worlds" (or creating a C).
- assimpleaspossi 3y agoI've always thought of assembly language as the arithmetic of programming. You can do anything programming-wise with assembly (ignoring micro-instructions). I don't know what the C equivalent in math would be but can't see it going away for the same reason eliminating the math equivalent wouldn't make sense.
- fasterik 3y agoI generally think that C is the right level of abstraction and provides the right model for thinking about programming. However, I don't actually use C because I can work at the same level in other programming languages. Right now, C++ is my language of choice, but I'm far from happy with it, for obvious reasons. I think my ideal language would be as close to C as possible while adding some quality of life modifications. Off the top of my head, those would include: namespaces, modules, generics, removal of the -> operator, and removal of forward declarations (which would imply order-independent declarations). Of course, it's easy to imagine such a language, but hard to implement it and be successful in practice. Most attempts probably never get out of the hobby project phase. Those that achieve some success will feel pressure to continue to add features to differentiate themselves from the competition. Maybe I am in too small a niche and there simply isn't a market for what I would like to use.
- kevin_thibedeau 3y agoC23 technically has namespaces for the attribute syntax. Hopefully it will be extended into the main syntax in the future. It's also easy to implement basic generics using either _Generic() or m4 macros.
- steveklabnik 3y agoYou may enjoy Hare.
- c-cube 3y agoNo generics... Zig seems like a better fit.
- fasterik 3y agoI had a bad first impression when the Zig compiler refused to compile a file with Windows line endings. For all I know it might be an interesting language, but to me that decision indicates a level of pedantry and hostility to non-Linux environments that doesn't look too promising.
- nathants 3y agoc and cpp are great. definitely worth learning, sometimes worth using. probably best avoid for the first few years of serious engineering as a beginner.
- simonblack 3y agoI moved away from C to Java, then I returned to C. I tried Python several times, but always returned to C. C is small, with very few hidden 'gotchas', and it works. No wonder I always come back to C. You could call it the WYSIWYG programming language.
- tkot 3y agoWhat are the 'gotchas' that Java has but C does not?
- simonblack 3y agoJava is a much larger and more complex language than C. Consequently, it is much more fragile. I was one of the ones who thought Java was the best thing since sliced bread back in the 90s ("Write Once, Use Everywhere"), but I found it it very difficult to work with at times because you had to jump through hoops to get around those complexities. And that's not including the bastardisation of Java that occurred when Microsoft tried to bring it down by changing many of the classes to something incompatible. I once got into an online discussion of something or other and couldn't work out why the other guy's code and results differed from mine. I then discovered that while I was using Sun's (official) Java, he was using Microsoft's (different) Java. Don't get me wrong. Java is a good (overall) language but it's just not the simple and fast language that C is. There is the old joke that C makes it easier to shoot yourself in the foot. That is true, but it is also a very versatile and clean language.
- deleted 3y ago[deleted]
- petabytes 3y agoI'm working on some bare metal ARM32 firmware, and I can't find a language that comes close to C. I can get it to generate pretty much any assembly I can think of. Other languages make it a pain to write memory unsafe code.
- taylorius 3y agoMan, I write all my programs in pretty much C. I'll use a class or two, but that's as far as it goes. I call myself a C++ programmer, but really I don't touch 95% of it with a barge-pole. It just seems like a load of unnecessary, complicated crap that will surely go wrong and confuse me.