6 ms·
It's much easier to write robust code in Java - with it's Optional type, and checked exceptions - than in C#. You probably would never write this, and your col
by lacampbell 10y ago
It's much easier to write robust code in Java - with it's Optional type, and checked exceptions - than in C#.
You probably would never write this, and your colleagues would never write this. That reasoning is good to apply in many situations. I in fact do this all the time; it’s a huge part of my research agenda. But you have to be careful where you apply it. Soundness is a security guarantee, not a usability concern. What matters is if someone can write this, because then that someone can get around the security measures that people have placed their confidence in and do whatever they would like to do. In the case of soundness, it’s the malicious programmer you should be worried, not just you and your friends.
I really hate this attitude. Programming languages should be designed to be safe and strict by default, but with easy outs. I utterly reject the notion that we should design languages first and foremost to protect us from people can't program that well or aren't careful when they write code.
Do we always have to appeal to the lowest common denominator? Empower the developers that care rather than trying to turn this into an unskilled profession.
- dsp1234 10y agowith it's Optional type, C# has Nullable<T> (aka T?)[0]. I'm not a Java expert, but they appear to be the same (represent a value or a null value, allow you to inspect for the presence of a value or null). ex: int? x = null; int y = x ?? 0; int z = x.HasValue ? x.Value : 0; if(x.HasValue && x.Value == 42){} C# definitely doesn't have checked exceptions. edit: For reference types, as compared to value types, c# has the null coalescing operator List<string> y = someList() ?? new List<string>; and the null conditional operator int? length = customers?.Length; // null if customers is null which are defintely not Optional, but are what I use. [0] - https://msdn.microsoft.com/en-us/library/1t3y8s4s.aspx https://msdn.microsoft.com/en-us/library/1t3y8s4s.aspx
- sremani 10y agoYes, Nullable was introduced in 2005 with C# 2.0 if memory serves me right. Checked Exceptions was a design choice, http://www.artima.com/intv/handcuffs.html http://www.artima.com/intv/handcuffs.html
- jpfed 10y agoI'm unfamiliar with Java's Optional type, but the .NET type Nullable can only be parameterized over value types. It is there to add the concept of null to value types, not allow you to more precisely characterize the nullability of reference types.
- platz 10y agoOptional in Java is just a library. If you want to to use Optional in C#, there is no reason to believe that that is not possible due to some issue that makes it only available to Java. https://github.com/louthy/language-ext/tree/master/LanguageExt.Core https://github.com/louthy/language-ext/tree/master/LanguageE...
- jpfed 10y agoI didn't imply it was desired or wasn't possible...? Another reply to my comment clarified that Optional also only applies to value types, which makes it analogous to Nullable. There's no reason to port it (as opposed to any other implementation of an Optional type) over. What is really necessary is an equivalent for reference types. struct Maybe<T> where T : class { private bool _isInitialized; private T _data; public Maybe(T data) { _isInitialized = (data != null); _data = data; } // ...etc }
- lacampbell 10y agoAnd in Java they're in the the standard library. Which is going to go down better - simply using something official that every java library program will already have, or trying to explain to your colleagues why all your methods are returning something defined in this obscure library you added to all your builds?
- lacampbell 10y agoNullables work at a pinch, but they are a poor mans option type. http://fsharpforfunandprofit.com/posts/the-option-type/ http://fsharpforfunandprofit.com/posts/the-option-type/ Scroll down to "Option vs. Null vs. Nullable" for an explanation of the differences.
- orf 10y agoWe don't always have to appeal to the lowest common denominator, but languages that do appeal to more people. Hence popularity.
- pswenson 10y agochecked exceptions? They lead to very un-robust code like try{...}catch(Exception e){//ignore or log, continue along like everything is grand!} or (much better) every method declaring "throws Exception"
- lacampbell 10y agoSure, it may lead to that kind of code if you have mediocre programmers who don't care about robustness - absolutely. But in C# it's much harder to keep track of all the exceptions that might be thrown. Now, if a programming language has error aware return types - using algebraic data types or multiple dispatch - that's a better solution than both. But in the absence of that, give me checked exceptions over unchecked ones any day.
- tigershark 10y agoThanks god c# doesn't have checked exceptions, they are just an enormous pain, especially when heavily using actions and functions, and most of the time they are completely ignored, rendering them completely useless. The option type in Java is extremely verbose and doesn't guarantee that you won't have null pointers. In c# you can use the null conditional operator and the coalesce operator that at least are much less verbose and more elegant. The best solution is obviously to use a functional language like f# where you can't have null pointers.
- lacampbell 10y ago> The best solution is obviously to use a functional language like f# where you can't have null pointers. You absolutely can: Microsoft (R) F# Interactive version 14.0.23413.0 Copyright (c) Microsoft Corporation. All Rights Reserved. For help type #help;; > let s:string = null ;; val s : string = null
- tigershark 10y agoString is a .net type, f# types cannot reference null unless you explicitly add some attribute if I recall correctly.
- solidsnack9000 10y ago> I really hate this attitude. Programming languages should be designed to be safe and strict by default, but with easy outs. I utterly reject the notion that we should design languages first and foremost to protect us from people can't program that well or aren't careful when they write code. I don't think the author has a beef with easy outs, but with accidental outs. Specifically with regards to the JVM, too, there are some practical security ramifications, with regards to running plugins.