with $drone.engine {
.start;
say "engine started";
}
On Tue, Dec 15, 2020, 11:10 PM Konrad Bucheli via perl6-users <
perl6-us...@perl.org> wrote:
>
> Hi Ralph
>
> Thanks a lot for the extensive answer.
>
> I still consider it a trap because it does not do what it tells it does.
>
> If I have:
>
> say "launching drone";
> $drone.engine.start;
> say "engine started";
>
> After I run the above I got both messages, but no propeller spinning. So I
> checked start() in and out, because that is where the problem is obviously.
> But it was not, it was in engine().
> And I want my programming language/runtime to tell me if I am doing
> obviously stupid things.
> Note that it has nothing to do with the "pyramid of doom". It would make
> sense in a pure functional environment, but Raku is multi-paradigm, no?
>
> Now to be "safe" (as in fail fast) I have to always
>
> say "launching drone";
> # this intermediate variable is important defensive programming, else it
> will not explode on Nil if there are stupid errors in engine()
> my $engine = $drone.engine;
> $engine.start;
> say "engine started";
>
> which is the opposite of concise.
>
> But Raku is Raku, there is surely a way to make sure that my Nil explodes
> in my code. Is there a `use FailingNil`?
>
> Concerning documentation: I do not know where there is an appropriate
> place to warn about this behavior. There where we teach how methods are
> called? Surely it would not have found me. I look up a lot in
> documentation, but not such trivial stuff.
>
> Cheers
>
> Konrad
>
> From: Ralph Mellor <ralphdjmel...@gmail.com>
> Sent: Saturday, 5 December 2020 15:58
> To: Konrad Bucheli <kbuch...@open-systems.com>
> Cc: perl6-users <perl6-us...@perl.org>
> Subject: Re: Missing NullPointerException
>
> On Thu, Dec 3, 2020 at 10:20 PM Konrad Bucheli via perl6-users
> <perl6-us...@perl.org> wrote:
> >
> > What is actually the rationale for such a behaviour?
>
> Ergonomically sound null safety.
>
> First, consider what other languages have. Quoting
> https://en.wikipedia.org/wiki/Safe_navigation_operator:
>
> > In object-oriented programming, the safe navigation operator
> > ... is used to avoid sequential explicit null checks ...
> ...
> > In programming languages where the navigation operator
> > (e.g. ".") leads to an error if applied to a null object, the safe
> > navigation operator stops the evaluation of a method/field
> > chain and returns null as the value of the chain expression.
> ...
> > It is currently supported in languages such as Apex, Groovy,
> > Swift, Ruby, C#, Kotlin, CoffeeScript, Scala, Dart and others.
> ...
> > The main advantage of using this operator is that it avoids the
> > pyramid of doom. ...
>
> Many aspects of Raku's design are better solutions than are found
> in older PLs like those listed above. This is an example. Instead of
> devs having unsafe operations by default, and having to write `?.`
> to get safety, in Raku one just writes `.` and always gets safety.
>
> > For me it was an unexpected trap
>
> This statement couples deep wisdom (the "for me" qualification,,
> deferring it till after you'd first asked about what the rationale was,
> and sharing your experience) with a Canby.[1]
>
> It's clear that you were missing some knowledge, and that it
> bit you, and are now exploring how best to learn from that.
>
> I accept without reservation the claim it was "unexpected". (That
> is the sort of thing that is typically experienced and reported by
> request of our right hemispheres, and it is generally reliable.)
>
> I also recognize what I imagine as a negative effect associated
> with classifying this experience / situation as a "trap", and the
> negative affect associated with applying that classification, which
> is to say your right hemisphere's experience of that classification.
>
> With that said, I now wish to engage our respective unreliable
> left hemispheres, the ones that drive classification, and wish to
> suggest another way to view this situation.
>
> I would argue that you are classifying safe navigation as a trap,
> and thus likely experiencing it negatively. Perhaps for you this
> can/will instead become a gift (perhaps also unexpected)?
>
> A fundamental part of human experience is interpreting one's
> reactions to things in the light of further knowledge and/or
> experience. Larry has made it clear to me that this is one of
> the keys to his approach to life, and to PL design, in both the
> sense of how he approaches a PL's design and how the PL's
> designed features reward those who think the same way. (I
> have found this endlessly inspiring.)
>
> Applying that to your experience, you could alternately view
> what happened as a surprise that arises from Raku's default
> of safety, which is about freedom (avoiding both the extensive
> boilerplate of the pyramid of doom, and the modern shorter
> but still boilerplate additional ?), and not, it could reasonably
> be argued, about a trap.
>
> cf my discussion of what Vadim Belman had classified as a WAT in
> https://www.nntp.perl.org/group/perl.perl6.users/2018/09/msg5418.html
>
> > It all went fine only the side effect was not there. I then figured
> > out after some time that one of methods returned Nil and
> > somehow silently it did not do what I expected.
>
> The "somehow" was automatic safe navigation, By definition,
> this is silent as far as it goes.
>
> But if you think about it, it wasn't *entirely* silent. You knew
> *something* wasn't working right, because somewhere you
> expected a value and didn't get one. So you then had to go
> chase that down.
>
> This is another pervasive principle in Larry's design approach.
> If a PL tries too hard to avoid programming errors, it becomes
> a police state. If it ignores the potential for programming errors
> it forgets to introduce things like safe navigation by default.
>
> The sweetspot is a balance between trade offs that overall
> lets devs reasonably easily "get" working code (in both the
> sense of arriving at it when writing, and comprehending it
> when reading), and keep making progress in the event of
> things not working out as expected.
>
> I see signs that Raku gets that right a lot of the time for me,
> and for others I see using and discussing it, and that the
> culture is generally agreeably open to figuring out whether
> any given negative experiences are best left as something
> for individual involved devs to adapt to, or as necessitating
> improvements in the doc, or Raku, or Rakudo, or modules etc
>
> And at the foundation of it all, is our open minded but also
> mindful right hemispheres, which it's clear we all share.
>
> Which leads me to a concluding question.
>
> Given your own reflections on the rationale I have described,
> and perhaps the wisdom that comes when we "sleep on it",
> is your conclusion that it would be best if there were some
> change in the doc, or Raku, or Rakudo, etc., or does it make
> enough sense now that it was, in the final analysis, really
> just unexpected rather than also being a trap?
>
> love, raiph
>
> [1]
> http://quotegeek.com/literature/norton-juster/the-phantom-tollbooth/3184/
