Why null is becoming scarce (and my thoughts on it)

[Th3 121]

Branching using conditionals doesn't give room for runtime optimizations like on stack replacement. But seeing how you mention you're a C child, I can totally understand, seeing how such optimizations don't exist there, and branching WOULD be the best way to go. As for Java, you can perform the benchmarks yourself if you wanted. Conditionals are alright in situations where the condition remains the same for extended periods. But for large-scale projects, not only would if-else statements clutter up a class, but as stated before, there is little to be done for conditionals when it comes to runtime optimizations. Although the techniques I may have mentioned above apply strictly to Java, any language which supports managed code is a canidate for adding such optimizations.

Coming from the kid who always tries to say I'm wrong, yet gets the truth shoved down his little ameture throat every time. I'm getting sick of your disrespectful attitude (how you bash on OSBot yet go on there every day; how you down anyone who might seem a little less knowledgable than you).

 

If null is so valuable, how about you stop talking shit and start giving reasons? Oh, and do your research first, cause based off previous encounters with you, I have yet to see you show any effort towards looking into things before speaking..

This is funny you guys argue about nothing, literally XDddd My sides are in orbit.

 

I can give reason:

Take as example returning from methods, when you return object that means 'something' was returned and what, something isnt really something because you implemented is at empty object? When you return null user clearly know that its null lol.

 

The only reasons i dont want to see is null like i said is passing/returning iterate-ables as null this is really common problem with novice programmers.

 

Also jump is always faster than method invocation in java, dont tell me bullshit there. And branch prediction works in java lol

 

@Polish Civil asked me to post this because he forgot how to use the internet.

[Chris 154]

@Polish Civil break internut.

[Dioxin 29]

That is a rather exhausting example to this simple problem. If it was really necessary to get rid of null checks, the jvm would "do nothing" when trying to access a method on a null object. Instead of creating a "No" object for every type of object you have. Obviously you can see everyone has different thoughts and opinions on the subject. Because of that, no answer is right. I'm not right, you're not right. We all program in different ways, as we're all creatures of habit. Just because you think it's useless doesn't mean it is. You should post a larger project you've written which has no null checks. Could be fun to see how you do your thing!Personally, most of my simulation projects involve no null checks; however, they're all very straight forward and there will never be a null case. For monopoly, bingo and blackjack at least (I gamble some times)uhhhh..

boolean checked = false;

The NoCheck was an example

.. If the method returned null, boolean isnt even an option. Yeah, if it returned boolean, then null wouldnt be a factor.

 

Java throws an exception rather than "do nothing" because "null" isn't intended to be used as a value, which is what this topic revolves around. It's needed to let the developer know that he forgot to set a value. This was a quick and easy way to give references a default values to allow implicit initialization. OOP has evolved since then, and encouraging a default value should be encouraged, even if it is "do nothing" and even if that "do nothing" value implicitly exists.

 

There is currently no support for "do nothing on empty value", other than a null check or creating your own default value. Newer languages are adding this kind of support.

 

The JVM has a lot more optimization support for object oriented systems, rather than imperative, which I've already mentioned. It took Java years to implement lambda expressions, and they failed at trying to replace null as a value (with the @NotNull annotation and the Optional type). Java is playing catch-up, so don't expect this idea to fit in perfectly with Java, a language which still returns null in it's standard API. If you want a better example, you're gonna have to look towards other (newer) languages.

I recommend that you read up on the basics. http://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html

Nice to know you have nothing of value to contribute. What am I supposed to be looking at again?

 

Not even sure why I'm asking a troll a question.. Just sit back and watch the debate m8

This is funny you guys argue about nothing, literally XDddd My sides are in orbit.

I can give reason:

Take as example returning from methods, when you return object that means 'something' was returned and what, something isnt really something because you implemented is at empty object? When you return null user clearly know that its null lol.

The only reasons i dont want to see is null like i said is passing/returning iterate-ables as null this is really common problem with novice programmers.

Also jump is always faster than method invocation in java, dont tell me bullshit there. And branch prediction works in java lol

 

@Polish Civil asked me to post this because he forgot how to use the internet.

Tell you bullshit? You must not understand runtime optimizations. Please, look into OSR...

 

You shouldn't need to check the value. You should just perform things based on the value, whether its performing something or nothing. No check is needed for that logic

[Dogerina 330]

The NoCheck was an example

.. If the method returned null, boolean isnt even an option. Yeah, if it returned boolean, then null wouldnt be a factor.

 

Java throws an exception rather than "do nothing" because "null" isn't intended to be used as a value, which is what this topic revolves around. It's needed to let the developer know that he forgot to set a value. This was a quick and easy way to give references a default values to allow implicit initialization. OOP has evolved since then, and encouraging a default value should be encouraged, even if it is "do nothing" and even if that "do nothing" value implicitly exists.

 

There is currently no support for "do nothing on empty value", other than a null check or creating your own default value. Newer languages are adding this kind of support.

 

The JVM has a lot more optimization support for object oriented systems, rather than imperative, which I've already mentioned. It took Java years to implement lambda expressions, and they failed at trying to replace null as a value (with the @NotNull annotation and the Optional type). Java is playing catch-up, so don't expect this idea to fit in perfectly with Java, a language which still returns null in it's standard API. If you want a better example, you're gonna have to look towards other (newer) languages.

Nice to know you have nothing of value to contribute. What am I supposed to be looking at again?

 

Not even sure why I'm asking a troll a question.. Just sit back and watch the debate m8

Tell you bullshit? You must not understand runtime optimizations. Please, look into OSR...

 

You shouldn't need to check the value. You should just perform things based on the value, whether its performing something or nothing. No check is needed for that logic

You can start by reading what a boolean can be

[Dioxin 29]

You can start by reading what a boolean can be

Unless you autoboxed, it can't be an object.. So in that case, boolean has no relevance here. If a method returns a reference type (not primitive), boolean is not an option, therefore you either have null or your own default value.

 

With null, you're forced to check. With a default value, you arent; you can just perform the behavior of the default value

[Dogerina 330]

Unless you autoboxed, it can't be an object.. So in that case, boolean has no relevance here. If a method returns a reference type (not primitive), boolean is not an option, therefore you either have null or your own default value.

 

With null, you're forced to check. With a default value, you arent; you can just perform the behavior of the default value

where is facepalm emoticon 

[Dioxin 29]

where is facepalm emoticon

 

Where is your counter-argument? I'm just wrong? No reason? Is that how you guys handle things here?

 

Give me one example where null is actually useful, Mr Cambridge Graduate

[Explicit 213]

If a user didnt check a box, the NotChecked would be returnes instead of null. There's no luck; it's pure logic. When you check for null, you perform something afterwards, based on whether there is a value or not. Instead of having to check if it's empty, we already know it's empty cause it has an empty value. We can then use that empty value to either do nothing or perform a default task, rather than get a NPE (which ia why we need the tedious check). Maybe if you trolled less amd studied more, this would make sense to you.

 

If you took the time to read, you'll see that no comparing is going down. I removed the need to compare (against null or anything else). Read it again...

 

As for experience, I have plenty, so no need to worry about that. If I didn't have experience, I wouldn't come across such situations that motivate me to look into topics like this.

You need to chill out lmfao. We're on a forum buddy, have a discussion instead of getting so butthurt when someone doesn't agree with you.

 

That would be stupid to throw empty objects around instead of nulls. All that would do is use a shitload of memory (especially if your program is big) and cause more work for the garbage collector. Not only that, but when attempting to view something after many generations the few milliseconds it takes to preform an empty check on the object versus just a reference check adds up a hella lot. This wouldn't be practical for any sort of large application.

Tell you bullshit? You must not understand runtime optimizations. Please, look into OSR...

Saying polish doesn't understand something is like saying helen keller wasn't blind

[Th3 121]

@Polish Civil break internut.

interface Internet{
 postDreambot(String text);
}
class NullInternet{
 postDreambot(String text){}
}
final Internet polishInternet = new NullInternet();

The NoCheck was an example

.. If the method returned null, boolean isnt even an option. Yeah, if it returned boolean, then null wouldnt be a factor.

 

Java throws an exception rather than "do nothing" because "null" isn't intended to be used as a value, which is what this topic revolves around. It's needed to let the developer know that he forgot to set a value. This was a quick and easy way to give references a default values to allow implicit initialization. OOP has evolved since then, and encouraging a default value should be encouraged, even if it is "do nothing" and even if that "do nothing" value implicitly exists.

 

There is currently no support for "do nothing on empty value", other than a null check or creating your own default value. Newer languages are adding this kind of support.

 

The JVM has a lot more optimization support for object oriented systems, rather than imperative, which I've already mentioned. It took Java years to implement lambda expressions, and they failed at trying to replace null as a value (with the @NotNull annotation and the Optional type). Java is playing catch-up, so don't expect this idea to fit in perfectly with Java, a language which still returns null in it's standard API. If you want a better example, you're gonna have to look towards other (newer) languages.

Nice to know you have nothing of value to contribute. What am I supposed to be looking at again?

 

Not even sure why I'm asking a troll a question.. Just sit back and watch the debate m8

Ye, go ahead. Make empty objects at runtime instead nulls, use it for a week and you will pray null to back.

 

Where is your counter-argument? I'm just wrong? No reason?

 

Give me one example where null is actually useful, Mr Cambridge Graduate

Lol nigga, u aint wrong and u aint right. This is nice pattern for some reasons and bad for others. There cannot be "Ok fuck nulls we aint need em" we need nulls and nulls always will be with us!

 

Hugs and kisses from @Polish Civil

[Dioxin 29]

You need to chill out lmfao. We're on a forum buddy, have a discussion instead of getting so butthurt when someone doesn't agree with you.

 

That would be stupid to throw empty objects around instead of nulls. All that would do is use a shitload of memory (especially if your program is big) and cause more work for the garbage collector. Not only that, but when attempting to view something after many generations the few milliseconds it takes to preform an empty check on the object versus just a reference check adds up a hella lot. This wouldn't be practical for any sort of large application.

There is no check. Default values can be cached if wanted, and that goes to show that Java just isn't up to par, seeing how it doesn't support such a system in it's specifications.

 

But there is no check (for the fourth time)

 

interface Internet{ postDreambot(String text);}class NullInternet{ postDreambot(String text){}}final Internet polishInternet = new NullInternet();

Ye, go ahead. Make empty objects at runtime instead nulls, use it for a week and you will pray null to back.

That tells me that you haven't even tried this system.. I've been avoiding nulls for quite a while now, and the only thing I've been praying for is better default reference value support. The memory usage is not insane (have you guys ever heard of premature optimization? trying to "optimize" before you even know the results when it comes to using resources), code is a lot cleaner (separates logic in a clean way), and it's actually a lot better (on a large scale) than using conditionals (null-check); benchmark it for yourself.

 

Once again, I never said they were BAD. I said they weren't needed, and how people are using them now (as an actual value) is not how the creators intended it to be used. Please look into the specifications..