6 ms·
I'm not the author, but: > Or perhaps you meant null pointers. A major problem in languages like Java is that objects can always be null. A better solution wo
by qsort 6y ago
I'm not the author, but:
> Or perhaps you meant null pointers.
A major problem in languages like Java is that objects can always be null. A better solution would be to force strict null checks a la Typescript, where if you want to take or return an optionally null reference, you have to explicitly encode that property in the type of the variable.
NullPointerExceptions are frankly a really stupid thing we have to deal with. A proper type system could check for that at compile time.
> but you're talking about RTTI, or "reflection"
OP is talking about ML-style type destructuring, which is kind of the opposite of this.
> I don't understand the obsession with immutable variables.
Mutating variables leads to all kinds of invisibile problems and makes the code a lot harder to reason on. When I write Java, most of my variables are final, the author is right that we should be taking the opposite convention a la Rust, variables should be immutable by default with mutability explicitly annotated.
- mikewarot 6y ago>Mutating variables leads to all kinds of invisibile problems and makes the code a lot harder to reason on. Am I correct in interpreting that as when you pass a variable to a function by reference it causes problems? Pascal defaults to passing them by value.
- qsort 6y agoSure, but passing by value isn't always realistic. If you have a hashtable with a million entries, you can't copy it just to update a value. There's also the problem of internal mutation of state, with hashtables/collections being again primary examples. It's not always avoidable to have internal mutation, but it shouldn't be the default, in most cases it's just wrong.
- mikewarot 6y agoThat's a weird corner case... I wouldn't expect the compiler to keep me from shooting myself in the foot like that. I'm surprised that some people do expect it.
- qsort 6y agoWhat do you honestly expect me to answer? That's kind of a moot point: the entire reason we have type systems in the first place is that they are partial, machine-checkable proofs of correctness. The entire discussion is how to strike the best power/practicality balance while keeping the thing decidable. Keeping you from shooting yourself in the foot is exactly the type system's job. Why do you even bother with static types if you seriously believe that?
- mikewarot 6y agoI believe in type systems as a way of knowing how data is encoded in memory. I don't expect them to somehow prevent me from writing that memory location more than once.
- badsectoracula 6y agoHave you ever used procedure Foo(constref Something: SomeType); instead of procedure Foo(var Something: SomeType); in Free Pascal? Both will pass the same stuff in memory (stack), but one has different semantics. Similarly const NiceFeature = $01; NeatFeature = $02; GoodFeature = $04; var Features: Byte; and {$packset 1} type Feature = (Nice, Neat, Good); var Features: set of Feature; would be stored the same way in memory but again, different semantics with the compiler helping you in the second case to avoid logic bugs (e.g. setting Features to an invalid value). These are cases where Free Pascal helps you from shooting yourself in the foot.
- mikewarot 6y agoI've never used ConstRef, nor $packset I can see the value of making sure you don't end up with invalid values.
- edjrage 6y agoEver seen any of the top 5 functional languages? And "weird corner case"? Really?
- astrange 6y ago> Sure, but passing by value isn't always realistic. If you have a hashtable with a million entries, you can't copy it just to update a value. What else are you going to do? If you want to insert a value but also have access to the hashtable without the change, then you need to copy it. (Or use a data structure with history tracking, like RCU or finger trees.) If you don't need the old value, then you can optimize out the copy - this isn't too hard.