5 ms·
IMO the biggest problems with almost all popular programming languages are 1) null 2) exception based error handling such that, when you call foo() where foo
by bedobi 7y ago
IMO the biggest problems with almost all popular programming languages are
1) null
2) exception based error handling
such that, when you call foo() where foo is
String foo(){ blabla }
you can get a String, null OR an exception (!!!) and most compilers happily let you treat it as if it only ever returns a String.
I hope some day null is no longer a thing, and that Functional Programming types like Option, Either, Try etc in the native libraries is the new default.
- makapuf 7y agoIve thought a bit about this, and how is Option types (which I like and prefer to error checking) really different from the compiler emitting an error when you fail to explicitely check for nulls and stdlib returning nulls when you have one ?
- quelltext 7y agoBecause it forces (or at least strongly encourages) you/users of such a stdlib/API to explicitly think about and handle the null case and the non-null case if you want to access the contents directly / unwrap. At least that's the idea.
- pasquinelli 7y agoThat is what it is, a branch at the type level that the type checker mandates you complete both sides of.
- bedobi 7y agoI think it's better, see the other reply at https://news.ycombinator.com/reply?id=22306638&goto=threads%3Fid%3Dbedobi%2322306638 https://news.ycombinator.com/reply?id=22306638&goto=threads%...
- deleted 7y ago[deleted]
- quelltext 7y agoI am probably in the minority here but I think Java was on the right track with checked exceptions.
- bedobi 7y agoI used to think so, but * Java also has unchecked exceptions, and, incredibly, there's still no consensus as to which exceptions should be used for what and when, though these days the most common approach is to simply stick only to RuntimeExceptions, which is terrible. * Functional error handling using Option, Either, Try etc are arguably much simpler, safer and more powerful than exceptions. Simpler because they don't rely on dedicated syntax- they're just regular objects no different to any other object. Safer because unlike exceptions, they force callers to handle all potential outcomes, but no more. (no risk of ignoring errors and no risk of catching a higher level of error than desired, ubiquitous bugs in exception based error handling) Powerful because they support map, flatmap, applicative etc, making it easy to eg chain multiple computations together in desired ways, which is unwieldy and bug prone when using exceptions. It could be that, when learning Java, Python and any other language, we learn that methods return objects... and that's that. No weird dedicated syntax and magic, special treatment for returning anything other than the happy path, and the HUGE complexity that comes with it, eg the dedicated syntax itself and how it behaves, differences between checked and unchecked exceptions, hierarchies of exceptions etc etc. When lists and booleans also implement map, flatMap etc, you can actually reduce syntax of languages even further- there's no need for looping syntax like for, while etc, and no need for if else either. This is probably too extreme for most people, but think about it!