|
No Safe Word posted:http://www.diogonunes.com/blog/custom-build-configurations-visualstudio/ I sort of did this with an iOS app, back before IAP when the way to let people purchase "consumables" was to distribute multiple versions of an app at different prices.
|
#
?
Jul 6, 2015 22:07
|
|
|
|
| # ? Jun 6, 2024 08:03 |
|
|
GrumpyDoctor posted:"This so-called 'problem' isn't a problem because you can just bolt your own conceptual constraints on top of the language and rely, never making any mistakes, on the comprehensive, accurate documentation for any libraries you use." NOW you're thinkin like shrughes.
|
|
#
?
Jul 6, 2015 22:14
|
|
|
No really, null pointers/references aren't the big deal people make of them. If you get one you don't expect, it's a bug, and you fix it. If somebody's outputting a value that can be null, they can make a big deal of it, or just don't do that. The mistake is sitting there with your tinfoil hat afraid that everything could be null and is out to get you.
|
|
#
?
Jul 6, 2015 23:09
|
|
|
I'm honestly having trouble parodying the idea that because you can fix bugs after they happen, there's no substantial benefit of having language tools that can minimize their presence in the first place.
|
|
#
?
Jul 6, 2015 23:24
|
|
|
Yeah, there's really nowhere left to go. Coding horrors? Dunno what you're acting all horrified about, you can just rewrite the code, or maybe try not having horrible code in the first place? Wrap it up programmailures we're done here
|
|
#
?
Jul 6, 2015 23:48
|
|
|
Did I say there's no substantial benefit? No? Okay then. I said they're the most overrated problem in software The reason it became this way is, any idiot can understand what a null pointer is and point at it as a problem to make themselves feel smart for being one of those people that know how things really should be. You can see the same kinds of idiots talking about goto statements, tail call optimization [sic], object oriented programming, and functional programming. In fact they're trivial bugs to track down and fix, and preventing them from existing requires designing your language so that it can always force variables to be initialized, which is kind of freaky and inflexible.
|
|
#
?
Jul 6, 2015 23:58
|
|
|
It's a pain in the loving rear end is what it is.
|
|
#
?
Jul 7, 2015 00:18
|
|
|
To be fair even Haskell has its own version of null.
|
|
#
?
Jul 7, 2015 00:21
|
|
|
Shinku ABOOKEN posted:It's a pain in the loving rear end is what it is. I think the most annoying thing about null is constantly checking everything for a potential null status. E: I don't find NPEs that terrible to debug, but I'm probably just used to the process by now.
|
|
#
?
Jul 7, 2015 01:11
|
|
|
We should all just follow Objective-C's approach: calling a method on nil does nothing and returns zero. If it don't crash, ship it! 
|
|
#
?
Jul 7, 2015 01:25
|
|
|
AuxPriest posted:I think the most annoying thing about null is constantly checking everything for a potential null status. You should not need to do this and should not be doing this.
|
|
#
?
Jul 7, 2015 01:54
|
|
|
Just put "if (!this) return ..." at the start of all your member functions, no big deal
|
|
#
?
Jul 7, 2015 02:06
|
|
|
daft punk railroad posted:Just put "if (!this) return ..." at the start of all your member functions, no big deal That's too much typing, stick it in a macro.
|
|
#
?
Jul 7, 2015 02:07
|
|
|
Flobbster posted:We should all just follow Objective-C's approach: calling a method on nil does nothing and returns zero.
|
|
#
?
Jul 7, 2015 02:11
|
|
|
Optional types feel half-assed when mixed with parametric polymorphism because while Foo[T] and Foo[Option[T]] may look closely related, they're nothing alike. Any situation where a method could return an Option[T], it should be equally valid to return a T rather than a Some[T]. So if T is covariant with Foo, then Foo[T] should be a subtype of Foo[Option[T]]. But if you want that in Scala for instance, then it needs to be Foo[Some[T]] which seems a tad ridiculous in terms of overhead when I want to use a Foo that always returns a T in a situation that calls for a Foo that may return a T without some sort of shim.
|
|
#
?
Jul 7, 2015 02:18
|
|
|
But who shaves the barber?
|
|
#
?
Jul 7, 2015 02:59
|
|
|
Brain Candy posted:But who shaves the barber? His wife
|
|
#
?
Jul 7, 2015 05:01
|
|
|
sarehu posted:Did I say there's no substantial benefit? No? Okay then. sarehu posted:In fact they're trivial bugs to track down and fix, and preventing them from existing requires designing your language so that it can always force variables to be initialized, which is kind of freaky and inflexible. And if you think they're always simple to track down and fix, well, I envy you your easy life working exclusively on well-written codebases with trivial control flow.
|
|
#
?
Jul 7, 2015 09:02
|
|
|
Thermopyle posted:I dunno, if the volume of posts about null is anything to go by, null is the most serious problem since...Y2K! yeah, it's just as bad a problem as your posting!!!
|
|
#
?
Jul 7, 2015 11:20
|
|
|
Is there a paper out there I can read about the negative side of null? I can't glean what's bad about it from the posts in here, just that it is very bad. What does control flow look like without null? Do you just pick a magic number that signals that something has gone wrong instead, or is a null free world also a world where functions always return exactly what is expected (even when, for example, an api is non responsive?)
|
|
#
?
Jul 7, 2015 14:16
|
|
|
Corla Plankun posted:Is there a paper out there I can read about the negative side of null? I can't glean what's bad about it from the posts in here, just that it is very bad. Look at how Kotlin does it, it has types which have to be explicitly nullable to be assigned the value of null. In the case of an API being non-responsive that seems like a good place to either throw an exception or explicitly return a type like Java's Optional which forces you to handle whether it was a successful return value or a value indicating an error. Rust has a type called Result I believe which does just that.
|
|
#
?
Jul 7, 2015 14:24
|
|
|
sarehu posted:No really, null pointers/references aren't the big deal people make of them. If you get one you don't expect, it's a bug, and you fix it. If somebody's outputting a value that can be null, they can make a big deal of it, or just don't do that. The mistake is sitting there with your tinfoil hat afraid that everything could be null and is out to get you. Spoken like a true ruby programmer. Just replace null with literally anything!
|
|
#
?
Jul 7, 2015 15:10
|
|
|
Corla Plankun posted:Is there a paper out there I can read about the negative side of null? I can't glean what's bad about it from the posts in here, just that it is very bad. The control flow can be exactly the same as it's the actual implementation of null that is considered a bad idea. In most languages there isn't any way of signaling that a function is safe to pass null too, which means you have to be sure what every function called expects. You can have all your functions be null safe and check all parameters passed in, but that leads to a large amount of repeated checks and extra code. The alternative is you trust the parameters passed in, but this means you have to be sure that all of your code never passes null. Often you can end up with a mixture and aren't sure whether null is a valid parameter or not. Option Types(https://en.wikipedia.org/wiki/Option_type) allow the function definition to say whether your function accepts null as a parameter, or if it can return null. If it just returns or accepts a type then that type must be non-null. If it accepts / returns an option<type> then it can be a null or it could have a value. The compiler can then give errors if you ever attempt to access the value contained in the option<type> without checking if it is null. Another possibility is to use exceptions to signal errors instead of return values.
|
|
#
?
Jul 7, 2015 15:26
|
|
|
1337JiveTurkey posted:Optional types feel half-assed when mixed with parametric polymorphism because while Foo[T] and Foo[Option[T]] may look closely related, they're nothing alike. Any situation where a method could return an Option[T], it should be equally valid to return a T rather than a Some[T]. So if T is covariant with Foo, then Foo[T] should be a subtype of Foo[Option[T]]. But if you want that in Scala for instance, then it needs to be Foo[Some[T]] which seems a tad ridiculous in terms of overhead when I want to use a Foo that always returns a T in a situation that calls for a Foo that may return a T without some sort of shim. How do you reconcile this at runtime, though? If you have something that depends on a Foo[Option[T]] returning Option[T], and you give it a Foo[T] returning T, what happens when you use that Foo and expect an Option[T] and call map on it, but instead you've been given a T? Does the compiler actually make your Foo[T] into a Foo[Option[T]] for you and wrap all your T instances with Some for you? Not saying this is intractable, just intrigued and wondering how you think it would work out in practice. At any rate, having that be enforced at compile time is a pretty trivial issue; I've never been frustrated by it and it is really quite easy to just wrap the thing in an Option. I'd personally rather have an easy to fix compile time error than a lurking bug because I forgot an edge case because I'm a mistake-making idiot.
|
|
#
?
Jul 7, 2015 15:35
|
|
|
Steve French posted:Spoken like a true ruby programmer. Just replace null with literally anything! Replace null with nil!
|
|
#
?
Jul 7, 2015 15:42
|
|
|
Jsor posted:Replace null with nil! Replace null with empty!
|
|
#
?
Jul 7, 2015 15:47
|
|
|
Steve French posted:How do you reconcile this at runtime, though? If you have something that depends on a Foo[Option[T]] returning Option[T], and you give it a Foo[T] returning T, what happens when you use that Foo and expect an Option[T] and call map on it, but instead you've been given a T? Does the compiler actually make your Foo[T] into a Foo[Option[T]] for you and wrap all your T instances with Some for you? Not saying this is intractable, just intrigued and wondering how you think it would work out in practice. You could probably use an implicit conversion to automatically convert a T into a Some[T], but the fix might be worse than the problem (replace "return Some(t)" with "return t // this nonsense made possible by an implicit conversion!!!")
|
|
#
?
Jul 7, 2015 15:48
|
|
|
Steve French posted:At any rate, having that be enforced at compile time is a pretty trivial issue; I've never been frustrated by it and it is really quite easy to just wrap the thing in an Option. I'd personally rather have an easy to fix compile time error than a lurking bug because I forgot an edge case because I'm a mistake-making idiot. Especially in the cases where your release cycle is outside of your control and releasing a patch to a crash is subject to a review process.
|
|
#
?
Jul 7, 2015 16:03
|
|
|
Shrughes might be a rape apologist but these are some whacked out opinions on optional types.
|
|
#
?
Jul 7, 2015 16:05
|
|
|
Tank Boy Ken posted:Replace null with empty! Replace your desktop wallpaper with goatse!
|
|
#
?
Jul 7, 2015 16:14
|
|
|
Corla Plankun posted:Is there a paper out there I can read about the negative side of null? I can't glean what's bad about it from the posts in here, just that it is very bad. You don't need a paper. Use Swift as an example. If you declare a variable of some type T, it is required to contain a value of that type before it can be used. Once it does, you're good, the compiler lets you access members of that variable with no difficulty. If you want to declare a variable where it might not contain a value when you access it and that's an acceptable condition, you declare it as an Option type. The language has syntactic sugar to automatically wrap a T that you assign to it into a Some(T) and to take the keyword nil and assign it a None. The caller can't simply access the members on this Option variable! The caller must either access the Option value safely in a conditional block, use a nil-safe accessor ?. or use a "if this thing is nil, I want the program to crash" ! operator. This is much, much better than the way C# and Java handle it because it lets the compiler help you make sure you're writing safe code.
|
|
#
?
Jul 7, 2015 16:18
|
|
|
loinburger posted:You could probably use an implicit conversion to automatically convert a T into a Some[T], but the fix might be worse than the problem (replace "return Some(t)" with "return t // this nonsense made possible by an implicit conversion!!!") code:
|
|
#
?
Jul 7, 2015 16:28
|
|
|
Well this seems like a reasonable help with dealing with null checks: http://blogs.msdn.com/b/jerrynixon/archive/2014/02/26/at-last-c-is-getting-sometimes-called-the-safe-navigation-operator.aspx
|
|
#
?
Jul 7, 2015 16:31
|
|
|
So do we automatically box Option[T] into Option[Option[T]] too?
|
|
#
?
Jul 7, 2015 16:44
|
|
|
Vanadium posted:So do we automatically box Option[T] into Option[Option[T]] too? Always join your monads.
|
|
#
?
Jul 7, 2015 16:53
|
|
|
Tank Boy Ken posted:Well this seems like a reasonable help with dealing with null checks: http://blogs.msdn.com/b/jerrynixon/archive/2014/02/26/at-last-c-is-getting-sometimes-called-the-safe-navigation-operator.aspx Resharper has been updated to support this change too, so if you're on VS 2015 (which supports C#6), anytime it sees "if(foo != null)", it'll offer to change it to foo?.bar.
|
|
#
?
Jul 7, 2015 16:54
|
|
|
Tank Boy Ken posted:Well this seems like a reasonable help with dealing with null checks: http://blogs.msdn.com/b/jerrynixon/archive/2014/02/26/at-last-c-is-getting-sometimes-called-the-safe-navigation-operator.aspx I really hate that they're doing this. I'm worried it will encourage people to keep passing nulls around willy-nilly. It's syntactic sugar to cover up a bigger problem in the code. In my team we prefer the null object pattern, it works quite well. https://en.wikipedia.org/wiki/Null_Object_pattern
|
|
#
?
Jul 7, 2015 17:02
|
|
|
Corla Plankun posted:Is there a paper out there I can read about the negative side of null? A language like Java, however, by using garbage collection, bounds checking, opaque references, and compiler-enforced type checking, invalid references (where valid means the reference always points to an object that implements the interface defined by its type) are simply impossible except for the fact that the compiler allows null to be assigned to any reference. As a concrete example, since every Java class extends Object, and Object implements the toString method, you should be able to call toString on any object reference with a sensible result. Except null is an invalid reference, does not point to any object, and so will cause a NullPointerException if one attempts to call toString, or anything else on it. That's a pretty serious gaping hole in the type system that encourages poor API design, leading to bugs. The reality is that null is useful for indicating a number of things: error, "does not exist", an unprovided optional value, a not-yet-explicitly-set value, etc.; and it's used for all these things because it's convenient--it's a valid value for all reference types so long as you don't actually deference it. If Java didn't support nulls, sure you could create a NullType for every reference type where all public methods throw runtime exceptions, but the inconvenience of it would encourage folks to consider better alternatives for their APIs: using exceptions for indicating error, empty collections for "does not exist", optional types for optional values, and some kind of "sane default" for not-yet-explicitly-set values, etc. These are all better alternatives to null as they either avoid error conditions, force API callers to acknowledge them (checked exceptions and optional types), or fail-fast when errors are unavoidable. ExcessBLarg! fucked around with this message at 19:34 on Jul 7, 2015 |
|
#
?
Jul 7, 2015 17:52
|
|
|
Adhemar posted:I really hate that they're doing this. I'm worried it will encourage people to keep passing nulls around willy-nilly. It's syntactic sugar to cover up a bigger problem in the code. Well I've only taken up progamming as hobby for a couple of months now and do see the benefit of an null object. Especially if it can still be checked for being null.
|
|
#
?
Jul 7, 2015 18:04
|
|
|
|
| # ? Jun 6, 2024 08:03 |
|
|
Tank Boy Ken posted:Well I've only taken up progamming as hobby for a couple of months now and do see the benefit of an null object. Especially if it can still be checked for being null. My program processes batch jobs submitted by a user through a rest interface, with most of the work being done inside of a BatchState variable that gets instantiated at the start of a job. I can initialize this variable to null, in which case I need to add about two dozen null pointer checks and/or return a null pointer exception to the user (which they may not know how to interpret); instead I'm initializing it to a null object that returns a more meaningful message/exception if the user tries to execute a command that doesn't make sense while a job isn't running. The main benefit is that this concentrates the error handling to a NullBatchState object rather than spreading it out across the rest interface.
|
|
#
?
Jul 7, 2015 18:31
|
|