28 ms·

I agree, the example with the tld part wasn't the best - maybe an url schema (http part) would have been much better. "So the proposed solution with the Option

by vladev 17y ago

I agree, the example with the tld part wasn't the best - maybe an url schema (http part) would have been much better. "So the proposed solution with the Option<> generic type really is just a reminder to the programmer." - exactly. But a good program is a program that works, so we need to achieve that first. :)

pmjordan 17y ago
But a good program is a program that works, so we need to achieve that first. :) The thing is, static typing addresses this on the microscopic scale, where it's not difficult to make code work anyway - except maybe for novices, hence my "training wheels" analogy. I don't see any evidence that it helps correctness on a more macroscopic scale. In fact, it makes code more verbose, which makes it trickier to take in all at once. EDIT: rather than just hating on static typing, I propose this: How about making our languages more expressive? I don't think exceptions (try/catch/finally) are anywhere close to a global optimum for error/edge-case handling. Maybe there's no silver bullet, but I'm pretty confident we can do better than current exception handling. I hear Common Lisp 'conditions' are resumable, which sounds nice, but again only useful if you can reasonably substitute a value of some kind, a bit like the TLD example. What mechanism should we have if we really want our program to do something else in exceptional cases?
- limmeau 17y ago
  Regarding "It makes code more verbose": while "new JSome<LongSuperclassName>(myValue)" is certainly more verbose than necessary, I still think that the one bit of information "this method returns Foos" vs "this method returns Foos or nothing" is worth documenting. And in a statically typed language, the type system is an obvious place for such documentation.
  - pmjordan 17y ago
    Sure, if you're already going to go to the trouble of having type annotations for everything, adding an extra '?' (like in C#) isn't going to break the camel's back. It's the unboxing and wrangling with the returned value that make it more verbose. As far as I can tell the only statically typed languages that stand any chance in terms of terseness are those with sophisticated type inference. In that case, "can return null" or not makes a lot of sense for auto-generated documentation or making it an error to compare the return value to null.
    - limmeau 17y ago
      There is bound to be some wrangling with the returned value if the case of "something was returned" needs different treatment from "nothing was returned" in the program's design. However, I agree that match perform_foo() with | Some x -> do_something_with x | None -> do_without looks a lot less messy than JOption<Bar> baropt = performFoo(); if(baropt.isNonempty()) { Bar bar = baropt.getValue(); doSomethingWith(bar); } else { doWithout(); } There's just something deeply unsatisfying with a statically typed language that requires so much legalese and boilerplate as Java while still permitting surprising runtime errors in virtually every executable line of the program. Abandoning static types is one approach to the dilemma, trying to plug hole by hole is another.
- didroe 17y ago
  Conditions can do a lot more than substitute a value. Think of it like an exception in reverse, you can resume with different "types" that cause it to take a different path. And they might pass new data in. Say you have a function that is basically a loop processing a list of files, it throws some kind of "file not found" error. You could sort the file out and do a resume "try again", select a different file and do resume "diff file (filename)" or do resume "skip".

by vladev 17y ago

pmjordan 17y ago

But a good program is a program that works, so we need to achieve that first. :) The thing is, static typing addresses this on the microscopic scale, where it's not difficult to make code work anyway - except maybe for novices, hence my "training wheels" analogy. I don't see any evidence that it helps correctness on a more macroscopic scale. In fact, it makes code more verbose, which makes it trickier to take in all at once. EDIT: rather than just hating on static typing, I propose this: How about making our languages more expressive? I don't think exceptions (try/catch/finally) are anywhere close to a global optimum for error/edge-case handling. Maybe there's no silver bullet, but I'm pretty confident we can do better than current exception handling. I hear Common Lisp 'conditions' are resumable, which sounds nice, but again only useful if you can reasonably substitute a value of some kind, a bit like the TLD example. What mechanism should we have if we really want our program to do something else in exceptional cases?

limmeau 17y ago
Regarding "It makes code more verbose": while "new JSome<LongSuperclassName>(myValue)" is certainly more verbose than necessary, I still think that the one bit of information "this method returns Foos" vs "this method returns Foos or nothing" is worth documenting. And in a statically typed language, the type system is an obvious place for such documentation.
- pmjordan 17y ago
  Sure, if you're already going to go to the trouble of having type annotations for everything, adding an extra '?' (like in C#) isn't going to break the camel's back. It's the unboxing and wrangling with the returned value that make it more verbose. As far as I can tell the only statically typed languages that stand any chance in terms of terseness are those with sophisticated type inference. In that case, "can return null" or not makes a lot of sense for auto-generated documentation or making it an error to compare the return value to null.
  - limmeau 17y ago
    There is bound to be some wrangling with the returned value if the case of "something was returned" needs different treatment from "nothing was returned" in the program's design. However, I agree that match perform_foo() with | Some x -> do_something_with x | None -> do_without looks a lot less messy than JOption<Bar> baropt = performFoo(); if(baropt.isNonempty()) { Bar bar = baropt.getValue(); doSomethingWith(bar); } else { doWithout(); } There's just something deeply unsatisfying with a statically typed language that requires so much legalese and boilerplate as Java while still permitting surprising runtime errors in virtually every executable line of the program. Abandoning static types is one approach to the dilemma, trying to plug hole by hole is another.
didroe 17y ago
Conditions can do a lot more than substitute a value. Think of it like an exception in reverse, you can resume with different "types" that cause it to take a different path. And they might pass new data in. Say you have a function that is basically a loop processing a list of files, it throws some kind of "file not found" error. You could sort the file out and do a resume "try again", select a different file and do resume "diff file (filename)" or do resume "skip".