develooper Front page | perl.perl5.porters | Postings from November 2021

Re: Dogfooding our own new features - you can help

Thread Previous | Thread Next
From:
Oodler 577 via perl5-porters
Date:
November 25, 2021 12:58
Subject:
Re: Dogfooding our own new features - you can help
Message ID:
YZ+IF49yzZl55iOc@odin.sdf-eu.org
* Dan Book <grinnz@gmail.com> [2021-11-24 09:57:51 -0500]:

The whole point of "dog fooding" is to comiserate with users,
so technically speaking if we're unsure about using something in
core because there's no confidence in X, then we have no business
throwing the stuff over the fence to "Joe Perl User".

OpenBSD is a good example from what I have seen; so what does that
look like for Perl/perl:

- minimally, dogfooders use the latest point release (really should be
  using bleed) for their own "real" work

- features that can be beneficial in core areas are used as advertised;
  if problems arise, they are felt sharply internally before waiting
  for them to be reported from the general perl user base

- often "new" feature ideas are actually generated by internal needs

The net effect includes, but is not limited to:

* the people who are most quickly able to diagnose and fix issues find
  them first

* more empathy is created and nurtured for external users of all kinds,
  in our case "legacy" perl/Perl

* "new" features tend to be actually useful and beneficial both immediately
  and incrementally - being put into practice to enable more efficient and
  effective development ("upstream") workflows and processes

* it promote "useful" or "exciting" features over things no one really likes
  or wanted in the first place

In this case, the value of Paul's call to "dog food" is not only a signal
to "modernize" a lot of the pure Perl stuff that's distributed with
core; but to start thinking about what internal improvements and new
features would serve this kind of "legacy" code in terms of longevity,
correctness, and - ultimately - ease of maintenance.

Another way to put this is, dog fooding is all about adding new features
those who maintain and extend the language/interpreter *love* and actually
want to use them in ways that: behave as expected, are coherent with the
expectations set by the past/idiomatic tradition, and make doing critical/hard
things easier and more fun.

FWIW, I do not consider proper dog fooding to be: "we made this stuff now
everyone has to eat it". Not commenting on the current "dog food", but the
whole point is to produce stuff you want to use/eat - the former is more of
a temporary phase that must be endured when making this part of the culture -
which is something I do whileheartedly support.

Cheers,
Brett

> On Wed, Nov 24, 2021 at 9:41 AM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
> wrote:
> 
> > On Wed, 24 Nov 2021 09:00:01 -0500
> > Felipe Gasper <felipe@felipegasper.com> wrote:
> >
> > > Of these, only postfix-deref is officially production-ready, right?
> > > The rest are experimental?
> > >
> > > I would think it better to avoid experimental features in core ?
> > > though once a given feature achieves official stability, of course,
> > > it would be awesome to adopt it internally.
> >
> > "experimental" means "might change in a later version of perl", but
> > that's fine for files shipped with perl itself. We can effectively
> > ignore that status. If the feature does change then the file shipped
> > with perl can just be changed to accommodate it.
> >
> > "experimental" means that someone somewhere has to experiment with it.
> > If nobody does, then the status is effectively meaningless. Who better
> > to experiment with it than ourselves?
> >
> 
> I don't agree with this - experimental means (outside of exceptional cases)
> it is unsuitable for production code because it may be insufficiently
> shaken out or require breaking changes or get removed entirely. Core can
> adjust in tandem with the feature for the latter issues, but not the first.
> That doesn't seem suitable for code shipped with Perl which is not itself
> experimental. At the very least, it should require case by case
> determination on whether the particular feature is appropriate to use in
> the particular module.
> 
> -Dan

-- 
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About