develooper Front page | perl.perl5.porters | Postings from August 2023

Re: PPC Elevator Pitch for Perl::Types

Thread Previous | Thread Next
Oodler 577 via perl5-porters
August 22, 2023 22:34
Re: PPC Elevator Pitch for Perl::Types
Message ID:
* Leon Timmermans <> [2023-08-22 23:55:09 +0200]:

> On Tue, Aug 22, 2023 at 8:43?PM Oodler 577 via perl5-porters <
>> wrote:
> > Mostly True. RPerl is a real subset (R = "restricted"), not "Perl-like".
> > "Perl-like" is something like Qore(.org), which has actual threads
> > and REAL C++ data types. And really does look like Perl. I encourage
> > others to check it out, and always have. The only reason I don't use
> > it is because it's not the One True Interpreter^TM (and never will
> > be).
> >
> > Will even has a full book for free, in PDF form on the website,
> >
> >
> >
> > All for vaporware, tho.
> >
> No one said rperl is vaporware, I said Perl::Types is. If you don't believe
> me, try running «perl -e'use Perl::Types; my integer $foo = "L"'»

We're are in the process of extracting it from RPerl. So what.

> > > It really is a problem with Perl and Perl adoption and I don't know how
> > it
> > > can easily solved.
> > >
> > > But Perl was designed for *developer* efficiency and the Oshun data check
> > > project leans into that, hard.
> >
> > Ironically, what you are doing is extremely similar to Ada's
> > approach, part of which is called "design by contract". Ada has
> > full specifications on that and it's done by actual language
> > designers on US tax payer's dime. It's not bad, just not novel. It
> > seems a first pass on understanding how to apply Ada's approach in
> > describing the kinds of constraints you wish to describe would be
> > well worth the effort - and maybe a few academic papers. Were you
> > aware that Oshun is heading decidely into a space that has been
> > well specified by Ada?
> >
> > The last time I used Ada was in college, and it was for 1 semester.
> > It is an interesting languge, used even in real time systems like
> > avionics. So clearly it can be performant, but it also doens't have
> > the limitations perl does.
> >
> > Anyway, I suggestion you suggest you call Oshun what it is, "design
> > by contract", not only would more people understand at what level
> > it sits; but it would assist in the internal and external designs
> > by the mountains of existing implementations and specifications.
> > It might be novel in Perl, but it is not novel.
> >
> No, Oshun is not design by contract. Design by contract is fundamentally
> about checking code/transitions, not values.

Nobody actually knows what Oshun is proposing yet, even at this year's
TPFC, Curtis was still admittedly in the design phase. This is also indicated
by the nature of the discussion. I am not sure a specification even exists.

FWIW, I found this module linked on the Wikipedia page for DsC, which is from 
the early 2000s. It is by Damian and I assume is an apple that falls not
far from the tree. Though Oshun is decidedly declarative, I suspect this
very old and experimental (looking) module might serve as some yard stick
to see if once a spec is fleshed out, how much DbC we can say it is.

Regardless, look at the Ada standard for declaring DbC and constraints on
data types and objects. This is what originally lead me to even see that it
might be called DbC. Best you can probably assert is that it's not DbC because
the spec is not on a firm foundation and it can't yet be determined.

It's not a bad thing Oshun is still in the design phase. But it also can't be
used to beat Perl::Types over the head because Perl::Types is a real thing (yes
currently tied to RPerl) and Oshun is not. It's also apples and oranges. I've
aleady linked the code in the RPerl. It's real enough that we are getting real
feedback outside of this thread, which I do very much appreciate.

So all y'all just need to stop gaslighting people into saying Perl::Types is
vaporware. Because this is the word that is being used, like I said in dark
echo chambers of ther perl-verse.


> Please stop acting like you're the one here to school people.
> > We do not make promises of code performance. We make promises of developer
> > > performance and data correctness. The amount of code you would have to
> > > write to manually verify all of these assumptions is ridiculous, so many
> > > developers skip that entirely.
> >
> > Ignoring actual performance unwise. I am not suggesting pre-mature
> > optimizing the tricky stuff, but the obvious stuff, yes. It also
> > immediately loses most of your potential users. So what's the point
> > in hedging AGAINST performance? Makes me think you're not really
> > serious.
> >
> Are you?
> Leon

SDF-EU Public Access UNIX System - #openmp #pdl #native

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About