Reputation
Top tag
Next privilege 125 Rep.
Vote down
Badges
3
Newest
 Teacher
Impact
0 people reached

  • 0 posts edited
  • 0 helpful flags
  • 24 votes cast
Apr
27
comment If null is bad, why do modern languages implement it?
ceylon-lang.org/documentation/spec/html/typesystem.html
Apr
27
comment If null is bad, why do modern languages implement it?
Who wants traps? There are far more general mechanisms ... a precondition on a function/method that asserts that a parameter isn't null lets you take whatever action you want if it is. But for nullable references, the combination of Maybe and non-nullable references is far better because it makes it semantically impossible to have a null where it shouldn't be. And Maybe is just a specific example of a disjunctive type ... take a look at Ceylon, which makes powerful use of them.
Apr
27
comment If null is bad, why do modern languages implement it?
... and which might not, so it takes programmer discipline to always check for null in the right places, and invariably this discipline fails. With Maybe, the compiler/language semantics enforces the discipline. The generated code is the same, but Maybe is safe while nullable references are not. This is what type systems can do for you. You should go learn about it.
Apr
27
comment If null is bad, why do modern languages implement it?
... neither Nothing nor Maybe<T> is a reference type and so cannot be dereferenced. In order to extract a T from Maybe<T> you must test the type first ... this is a compile-time restriction imposed by the semantics of the language and the Maybe type. Thus, it is impossible to dereference null (Nothing). By declaring something as a Maybe<reference> rather than a reference, you have said that this is a thing that might be Nothing, so it is necessary to test the type to see if it is a reference before using it as one. But with T* foo, there is no way to declare which pointers might hold null ...
Apr
27
comment If null is bad, why do modern languages implement it?
Your question is probably meant to be rhetorical, but it just reveals a complete failure to understand or even attempt to understand -- all too common among C programmers who have a good grasp of the hardware level but fail at abstraction. First, on the expense: optimized implementations avoid the extra flag by representing the Nothing case of Maybe<reference type> with an invalid address -- null is a good candidate -- so the representation is identical. But while null is a legal but invalid value for a reference type, so it can be dereferenced, resulting in undefined behavior, ...
Apr
27
comment If null is bad, why do modern languages implement it?
Rust has no null at all and Ceylon has it as a separate type that can be used to compose "reference or null" types but null can never be the value of a reference ... Ceylon has no NullPointerException because such exceptions aren't semantically possible. And these languages are no less powerful for not having null ... but their designs reflect good, modern understanding of type theory. "Instead it allows you to specify which variables are allowed to hold null, and which aren't." -- this is quite wrong ... Option is a union type; no reference variable ever has a value of "Nothing".
Apr
27
comment If null is bad, why do modern languages implement it?
"No, it wouldn't solve the problem -- at least, not without introducing null references all over again." -- Such comments show a complete lack of understanding of type theory.
Apr
27
comment If null is bad, why do modern languages implement it?
Rust follows point 1 -- no null at all. Ceylon follows point 2 -- non-null by default. References that can be null are explicitly declared with a union type that includes either a reference or null, but null can never be the value of a plain reference. As a result, the language is completely safe and there's no NullPointerException because it isn't semantically possible.
Apr
27
comment If null is bad, why do modern languages implement it?
"The technically superior solutions are all more unwieldy " -- No, they aren't; both Rust and Ceylon are counterexamples.
Apr
27
comment If null is bad, why do modern languages implement it?
None of these answers show any understanding of the state of the art. Null has been completely removed from the programming model of Rust. Ceylon has null but it is always safe; there is no NullPointerException or equivalent because it isn't possible for it to occur. This is without any loss of power.
Apr
27
comment If null is bad, why do modern languages implement it?
"that's what parenthesis are for in English" -- "parenthesis" is singular in English.
Apr
27
comment If null is bad, why do modern languages implement it?
"WTF is up with you guys?" -- Intelligence and knowledge. "Of all the things that can and do go wrong with software, trying to dereference a null is no problem at all." -- false. " This is like asking why mathematics has zero, when it causes so many problems for division." -- No, it's nothing like that. " It refers to "no object" in exactly the same way that "zero cows" refers to no cows." -- false. "using Options - does not in fact get rid of null references. Instead it allows you to specify which variables are allowed to hold null, and which aren't." -- false.
Sep
26
comment Ordered enumeration: IEnumerable or Array (in C#)?
@StevenJeuris Your question wouldn't be necessary if C# were properly designed and had an ISortedCollection<T> interface, which you would extend if you needed the collection to be sorted. But since it doesn't, the only way to prevent misuse at compile time is to either extend an overly narrow type (IList<T>) or to extend IEnumerable<T> and do an unnecessary sort.
Aug
30
comment Why is DRY important?
"Strongly depends if doStuffX depends on each other or not." -- DRY has nothing to do with whether they depend on each other, but rather whether they duplicate decisions.
Aug
30
comment Why is DRY important?
That you said nothing about the relationship between a, b, c, d suggests that you don't understand enough about DRY to ask a meaningful question about it. The only thing repeated here is function doStuff { }, but DRY is not at all about repetition of syntax, it's about the repetition of policy and method.
Mar
27
comment Time to drop Emacs and vi?
"working using Vim / emacs forces you to understand at least a bit of a platform / language before using it. Many IDEs allow you to operate in a language without knowing what's going on; so using Vim / emacs will force yourself to gain some insight in what you're really doing." -- This is absolute rubbish. It's as if you don't even know what programming languages and editors are.
Mar
27
comment Time to drop Emacs and vi?
"If I recall correctly" -- you don't.
Mar
27
comment Time to drop Emacs and vi?
This isn't an answer to the question or anything close to one.
Mar
27
comment Time to drop Emacs and vi?
This question as asked is deeply unintelligent. The assertion that we have better alternatives is immediately shown to be baseless by "at least I hope we do" and everything else that follows. The notion that something should be dropped before inventing an alternative is grossly irrational, as is the notion that one can just "look for something new" as if great text editors can be found by digging in the ground, or something. I find it bizarre that such idiocy has been turned into a Community wiki -- what purpose does it serve other than an example of how not to ask a question?
Oct
7
comment How far should 'var' and null coalescing operator '??' be entertained without hampering readability?
@SargeBorsch Stupid strawman. I didn't say that some idiot doing something by rote would thereby be competent.