[PREV - DIVISION]    [TOP]

YOU_KNOW_THE_TYPE

                                             March 01, 2025

Ovid argues in favor of data checks built
in to the language-- typical we call this              I'm, referring
"type checking", but he prefers the term               throughout to his
"data checks", I presume because he                    keynote talk at the
includes airity checks and such.                       2023 perl and raku
                                                       conference.
He argues that the new regime of the
European datga privacy rules (including                    Ovid ==
the "right to be forgotten") plus our                      Curtis Poe
already widespread confidentiality
requirements in many fields is all going
to require some more cautious treatment,
if only because any mistakes can be
punished by huge fines.

Among other things, he argues for techniques where
data is just "on loan" to the system, and becomes
unavailable when the actual owner wants that to
happen-- he describes one technique that could be
used for this, and hints about a better one he's
seen but isn't at liberty to talk about in detail.


   A strong argument, though to me it feels like
   yet-another in a long line of them-- there
   are people out there who *love* the idea of
   strong types, they're constantly scrounging
   for arguments in favor of it... you might            And consider that
   suspect if this approach was all that                the approach Ovid
   superior it would've conquered the world             argues for is to
   already, really while strong type systems            build a facility for
   certainly don't prevent success, they're also        *optional* data
   not at all a requirement for it.  When               checks into perl.
   they're not there, people just do things
   differently.                                             I suspect that
                                                            optional checks
   Ovid certainly raises some real concerns but             would not satisfy
   I suspect that the level at which he wants to            the purists, who
   fix them isn't entirely satisfactory--                   fantisize about
                                                            tools that resist
   For example: yes, you don't want code to crash           abuse by fools.
   and dump confidential information where people
   who shouldn't see it can see it-- one solution
   would be a security audit that looks for this
   kind of failure.  Another might be a set of extensive
   automated tests-- possibly using features built-in
   to the system to simulate a crash on-command.

   Myself, I think the *real* solution is going to be to
   never run the code where unauthorized personnel can
   see the data dump.  The idea that you can create a
   programming language that will *prevent* mistakes
   like that seems unlikely-- programmers can be
   infinitely clever about making mistakes.  It *could*
   be that you could make it *harder* to make mistakes
   like that but that alone isn't going to protect you
   from the possibility of a gazillion dollar fine.

   Technical security is all well and good but really
   it's fundamentally a social problem, you can't really
   ever do it by purely technical means.

                                           Whatever "purely
                                           technical" might mean,
                                           I doubt that really
                                           exists, either.


--------
[NEXT - GOTO_ALAN_KAY]