4 ms·

I agree however it is only valuable under specific circumstances while it can frequently create hidden traps. On balance it causes more problems than it solves.

I agree however it is only valuable under specific circumstances while it can frequently create hidden traps. On balance it causes more problems than it solves. Which is why I suggested it should be an optional flag enabled on the backend rather than the default.

baq 7y ago
Maybe/Option would be better. NULL is what we've got though. setting columns to not null is leaps ahead of most programming languages anyway.
peteretep 7y ago
> On balance it causes more problems than it solves This is far from clear
- pushpop 7y ago
  Like everything, it depends on your language and framework. But after 30 years of experience writing software in strictly typed languages, I’ve seen lots of people get caught out with nullable fields. However if you’re main body of experience is Perl (for example) then NULL isn’t ever an issue.
  - peteretep 7y ago
    Right, because no Perl developer has ever used SQL
    - pushpop 7y ago
      I get Perl isn’t trendy these days but Perl actually has a very robust set of DB libraries and I have worked in several places were it was the preferred language.
      - peteretep 7y ago
        Perl has by far the best DB tooling of any of the many languages I’ve worked with. My point was sarcasm as rebuttal to the idea that a Perl developer might not have encountered a null value
        pushpop 7y ago
        Actually I said NULL isn’t an issue in some languages with looser type systems, not that other developers wouldn’t have encountered a NULL before. Eg Perl doesn’t have a nil type like Go, so variables passed to DBI which are NULL in the returned SQL query will be undef’ed instead. Effectively a bit like NULL but it only causes a problem if your running with strict flags (which you shouldn’t do on production systems anyway for various reasons; but that’s another topic entirely) otherwise that value falls back to the language default of “”/0/false. With languages like Go you can easily end up with a panic if you’re not careful (where you’re trying to cast a nil interface{}). Which, I’m guessing, is why this Go library being discussed here does it’s own NULL checking.
        peteretep 7y ago
        > With languages like Go you can easily end up with a panic if you’re not careful (where you’re trying to cast a nil interface{}) How is this any different to the runtime error you’d get in Perl if you attempted a method call on an undefined value you’d expected to be an object?
        pushpop 7y ago
        It’s different because the DBI wouldn’t return an object for a nullable table record. Which is what we are specifically talking about. Sure other parts of your code might fail if you’re trying to use a scalar as an object (or such like) but that would consistently fail regardless of nullable types on the database. So I’m not going to argue that Perl doesn’t also have its own hidden traps (a great many of them in fact) nor that it’s interpretation of OOP isn’t terrible but the scope of this discussion was about nullable types and not anything else you now want to draw into the argument.

baq 7y ago

Maybe/Option would be better. NULL is what we've got though. setting columns to not null is leaps ahead of most programming languages anyway.

peteretep 7y ago

> On balance it causes more problems than it solves This is far from clear

pushpop 7y ago
Like everything, it depends on your language and framework. But after 30 years of experience writing software in strictly typed languages, I’ve seen lots of people get caught out with nullable fields. However if you’re main body of experience is Perl (for example) then NULL isn’t ever an issue.
- peteretep 7y ago
  Right, because no Perl developer has ever used SQL
  - pushpop 7y ago
    I get Perl isn’t trendy these days but Perl actually has a very robust set of DB libraries and I have worked in several places were it was the preferred language.
    - peteretep 7y ago
      Perl has by far the best DB tooling of any of the many languages I’ve worked with. My point was sarcasm as rebuttal to the idea that a Perl developer might not have encountered a null value
      - pushpop 7y ago
        Actually I said NULL isn’t an issue in some languages with looser type systems, not that other developers wouldn’t have encountered a NULL before. Eg Perl doesn’t have a nil type like Go, so variables passed to DBI which are NULL in the returned SQL query will be undef’ed instead. Effectively a bit like NULL but it only causes a problem if your running with strict flags (which you shouldn’t do on production systems anyway for various reasons; but that’s another topic entirely) otherwise that value falls back to the language default of “”/0/false. With languages like Go you can easily end up with a panic if you’re not careful (where you’re trying to cast a nil interface{}). Which, I’m guessing, is why this Go library being discussed here does it’s own NULL checking.
        peteretep 7y ago
        > With languages like Go you can easily end up with a panic if you’re not careful (where you’re trying to cast a nil interface{}) How is this any different to the runtime error you’d get in Perl if you attempted a method call on an undefined value you’d expected to be an object?
        pushpop 7y ago
        It’s different because the DBI wouldn’t return an object for a nullable table record. Which is what we are specifically talking about. Sure other parts of your code might fail if you’re trying to use a scalar as an object (or such like) but that would consistently fail regardless of nullable types on the database. So I’m not going to argue that Perl doesn’t also have its own hidden traps (a great many of them in fact) nor that it’s interpretation of OOP isn’t terrible but the scope of this discussion was about nullable types and not anything else you now want to draw into the argument.