Front page | perl.perl5.porters |
Postings from August 2023
On Tue, Aug 22, 2023 at 8:43â¯PM Oodler 577 via perl5-porters < perl5-porters@perl.org> 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, > > http://rperl.org/learning/ > > 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? LeonThread Previous | Thread Next