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

Re: PPC Elevator Pitch for Perl::Types

Thread Previous | Thread Next
Leon Timmermans
August 22, 2023 21:55
Re: PPC Elevator Pitch for Perl::Types
Message ID:
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"'»

> > 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.

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?


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