3 ms·
> Not that any other language is on trial here, but there are languages that would naturally make such a bug into a compile time error. I'm sure there are lang
by clarry 9y ago
> Not that any other language is on trial here, but there are languages that would naturally make such a bug into a compile time error.
I'm sure there are languages where the use of any condition forces you into making sure there is some explicitly taken branch for all possible inputs -- and perhaps that language also magically knows what you must do inside each branch. Show me all the projects that are using these for web developement, which is the context for this discussion. Otherwise it is not fair to bash C over it.
All the mainstream languages I see in web development allow you to make the exact same mistake.
> I fail to see how C helps you avoid making such an error. Because C's general standpoint here is that there is no such thing as an error, there is no such thing as a type, and it is perfectly acceptable to have undefined behavior sitting within trivial edit distance of common code patterns.
But there are errors. There are types. UB is not relevant to what you are replying to. The problem in question was about a condition that was not considered. Again, show me how your average web language tells the programmer that he didn't write some if condition or stop bashing C over it because you're dreaming of features in some unicorn language nobody uses in the real world anyway.
> Actually, no, that's false. A lot of popular languages check arithmetic.
Please read again. I said "the former", referring to input validation. That is relevant to every language accepting untrusted input.
> Insufficient abstraction means that you can't reuse code, so instead of getting it right once you have to get it right every time.
That statement is so wrong I can only conclude that you're smoking something or you haven't programmed in C and you are completely oblivious to the work the OpenBSD folk (and many others) are doing to fix these issues in existing reusable library code as well as to introduce new, safer APIs. Sure you can pretend that everyone who wants a buffered output stream to a socket has to write their own circular buffer and repeat the same mistake. You are wrong, and if you had paid attention you would see counterexamples (libevent is a popular one) that prove you wrong. You're just hating on C but don't know it.
> And what's the compelling reason to use C?
I'm not trying to convince anybody to use it and my reasons are my reasons -- the strawman you make of performance isn't the key. But it doesn't matter.
- KirinDave 9y ago> Show me all the projects that are using these for web developement, which is the context for this discussion. Otherwise it is not fair to bash C over it. I'm not sure why I'd play the game when "mainstream" is basically a way to discount any offering. But in C++, C#, or basically any class-based language you can code to guard against this. Functional languages with types provide strong guarantees against this. Ocaml and Haskell come to mind as well known examples.. > But there are errors. There are types. Not according to the compiler. Anything can become anything else. > That statement is so wrong I can only conclude that you're smoking something or you haven't programmed in C and you are completely oblivious to the work the OpenBSD folk (and many others) are doing to fix these issues in existing reusable library code as well as to introduce new, safer APIs I'm aware of the work, but C's problem is not that it lacks more library code. > Sure you can pretend that everyone who wants a buffered output stream to a socket has to write their own circular buffer and repeat the same mistake. I don't say they have to. It's just that C's language design makes it easier for people to do so. Very different statements. > You're just hating on C but don't know it. I see where this is now going. "If you knew you'd like it." I'm not going to waste anymore of either of our time if this is the new talking point.
- PrimHelios 9y ago>Not according to the compiler. Anything can become anything else. You mind clarifying that? I constantly have compile-time errors from type mismatches. You can cast a variable to a different type, but you can do that in any language. you can't implicitly convert a char to an int, your compiler will take that as a fatal error. About the closest you could get is char and short since they're essentially the same data type, but even then the compiler might throw an error over an implicit conversion. That said, JavaScript doesn't have types at all, really. Every type can be implicitly converted to another type, and yet Node is still used server side.
- KirinDave 9y ago> You mind clarifying that? I constantly have compile-time errors from type mismatches. You can cast a variable to a different type, but you can do that in any language. Well, for one people overload types. The practice of, for example, using return codes as error values. The second problem is unions. They exist to make people converting bytestreams into structures happier, but often get misused elsewhere. And void* is essentially a black hole, but it's a very common black hole to see in programs. > That said, JavaScript doesn't have types at all, really. Every type can be implicitly converted to another type, and yet Node is still used server side. Yeah and that's the most solid criticism against it! While it's true that it's quite a bit more difficult to cause fatal errors in a program in node, the language does little to help you solve these problems once you expose that functionality to it. That's why Typescript has been doing so well, I think. It's consuming the javascript ecosystem faster than anything I've ever seen, and having written a fair sum of it (for a server side application, no less) I'm constantly surprised how capable it is. And of course, I'm on record as a big fan of Purescript and Elm, with more bias towards the former.