6 ms·
> The issue with safety is that nothing is really safe. There is a trade-off between safety and expressiveness. Clearly you can always shoot yourself in the fo
by rkrzr 10y ago
> The issue with safety is that nothing is really safe.
There is a trade-off between safety and expressiveness. Clearly you can always shoot yourself in the foot if your language is expressive enough (like any Turing-complete language).
But I think that is beside the point here. This is about eliminating whole classes of errors.
A good type system (e.g Rust's, Haskell's..) can eliminate all type errors from your programs.
A good memory model can eliminate all unsafe memory problems.
There are also languages that can eliminate all data races from your programs.
All these advances in PL theory make it easier and safer to deal with hard problems like concurrency, memory management etc. and thus allow us to focus on what our programs can actually do.
- bassislife 10y ago> A good type system (e.g Rust's, Haskell's..) can eliminate all type errors from your programs. It will eliminate errors related to the use of a given programming language. It will not necessarily avoid systemic errors. The programming language is only one part of the problem. Safety is a wider issue than just the use of a programming language. Especially since the systems we use are often dynamic with changing requirements.
- rkrzr 10y ago> It will eliminate errors related to the use of a given programming language. It will not necessarily avoid systemic errors. Like I said: It will eliminate a specific class of errors, namely all type errors. Your program will literally not compile if there are any type errors. > The programming language is only one part of the problem. Safety is a wider issue than just the use of a programming language. Sure, I don't disagree with that statement. But it's important to recognize that eliminating whole classes of errors is extremely valuable and allows us to focus on the important things.
- ytugiuyghvk 10y agoEvery type system eliminates all its own type errors by definition. Even the trivial system with one type eliminates all its own type errors (vacuously, since there are zero of them). There is no universal set of errors called type errors. What are type errors depend on your type system. A good type system allows more errors to be encoded as type errors so you can catch them at compile time, but it doesn't mean anything to say that a language like Rust or Haskell eliminates all type errors. There are certainly type systems which could catch more errors.
- rkrzr 10y agoSure, not all type systems are created equal. And there are indeed type systems that can catch more errors than Haskell's (although that usually comes at the price of losing type inference). But I read OP's point as "Well, you can never catch all programming errors with PL_feature_X, so why even bother." And my point is simply that a lot of PL features make formerly hard things easy and thus allow you to go faster and focus on more interesting things.
- braveo 10y agoYou completely misunderstood what he was trying to tell you.
- msbarnett 10y agoThere was nothing interesting in what he was trying to say. Yes, no programming language perfectly eliminates all classes of unsafety. But that's no reason to let the perfect be the enemy of the good! "The issue with safety is..." no issue at all. Being safe in a bunch of problem domains (Rust) is still strictly better than being safe in very few if any of them (C).
- ssalazar 10y ago
- zzzcpan 10y ago> A good type system (e.g Rust's, Haskell's..) can eliminate all type errors from your programs. Do you consider silently trimming value during mandatory explicit type conversion a type error?
- iopq 10y agoNo, because if you explicitly converted to another type, that's what you wanted.
- zzzcpan 10y agoSometimes you want it to be lossy, but not most of the time, and yet there is no choice. I had a bug caused by that, that's why I remember it. Silent explicit type conversions are essentially unsafe.
- ldev 10y agoSounds like an implicit conversion.
- crossroads1112 10y agoIn Rust, lossy conversions only occur if you you explicitly write `var as type` and even that syntax is limited to certain types e.g. you can't coerce an integer to a function. In order to do something crazy like that, you'd need to call the unsafe `mem::transmute` function. The language cannot be much safer in this regard short of disallowing any sort of type conversions.
- eridius 10y agoWhat do you mean by "silent explicit type conversion"? If you said "silent type conversion" I'd read that as "implicit type conversion". But you said "explicit", which means you've got it very clearly in your code that you're doing a type conversion (to a smaller type), so what's silent about that?
- zzzcpan 10y ago
- paulddraper 10y ago> A good type system (e.g Rust's, Haskell's..) can eliminate all type errors from your programs. It depends what you call a "type error". Is calling `car` on a `nil` instead of a `cons` a type error?
- tblair 10y agoIt is in Rust, although I'm sure you can come up with something where the type system won't save you.
- pavelludiq 10y agoIn common lisp 'nil is of type 'null which is a subtype of 'list, which is a union of the types 'null and 'cons so it wouldn't be an error. Other lisps might chose to do it differently.
- jibalt 10y ago"Clearly you can always shoot yourself in the foot if your language is expressive enough (like any Turing-complete language)." This is a common misunderstanding of being Turing complete. A program running in an interpreter isn't unsafe just because the programming language and the interpreter are Turing complete. Being Turing complete doesn't mean being able to gain root access, overwrite the boot block, scribble on the hard drive, etc.