Front page | perl.perl5.porters |
Postings from June 2021
Re: RFC - core exception catalogue
From: Nicholas Clark
June 28, 2021 08:11
Re: RFC - core exception catalogue
Message ID: 20210628081105.GB11066@etla.org
On Sat, Jun 26, 2021 at 08:18:41PM +0200, Branislav Zahradník wrote:
> On Fri, 25 Jun 2021 at 11:49, Nicholas Clark <firstname.lastname@example.org> wrote:
[re-ordered to make my reply flow better]
> > * no business model
> Isn't "undying perl" in fact business model ? :-)
No, it's a "battle plan". I guess, more, it's a campaign strategy.
We're not going to win each individual battle. We just need to win more, and
pick battles we can win.
What I mean, and this is *key*, is that we don't have a revenue stream that
lets us pay developers to work on things we want.
Any plan that assumes that we can direct people to work on particular tasks
won't work. Any plan that requires it will fail.
This is why I ask "does Python do this?" "does Ruby do this?" etc.
Because if for an idea the answer is "no" to all of the (valid) peers, then
it's not obvious that it will work for us, and we certainly shouldn't
The models of commercial software don't all apply to open source projects
without revenue streams.
(Some do - shipping a perl release is like shrink wrap software - once it
escapes, you have to live with the consequences forever. You can't hot fix
all the servers and be happy that your bug is gone.)
> > Core C code <=> XS Extensions <=> Core Perl code <=> Dual life Perl Code
> > <=>
> > Code on CPAN
> > and specific implementations can move left or right on that line.
> > So yes, an exception catalogue that can extend to all of them solves that.
> > That wasn't what I was thinking of as a dynamic language. (I'm not familiar
> > with Oracle's SQL, but the SQL in Postgres is not something that I'd
> > consider
> > as a dynamic language)
> My fault (for being too familiar with Oracle SQL).
> Language is Oracle PL/SQL but also SQL language uses same approach.
SQL isn't a dynamic language, and I believe doesn't have classes.
It's not a good comparison. Starting here is starting from the wrong place.
> > I was meaning language without static typing, which we'd consider similar
> > to
> > Perl, such as Lua, Python, Ruby, TCL (and I guess JS)
> Honestly, I don't care much about other languages. None of it (including
> focuses on long term software development (yeah, maintaining real-live
> is not as funny as writing smart examples and/or new microservices someone
> had to maintain).
If you don't (and *everyone* doesn't) look at what works and what failed for
equivalent languages (eg the timescales of the Python 3 rollout), then
* we're proposing ideas in a vacuum
* we're not learning from other people's history, and are at risk of
> > Python or Ruby don't have the resources to translate error messages, do
> > they?
> I'm more concerned about users than core.
> How many programmers do you know who prefer saying in terms like "invalid
> in their native language?
> It's open source, should it be supported, there will be translations.
Translations are effort. Keeping translations up to date is more effort.
There's always the first obvious question - what happens if the programmer
needs to change the original text of an error message, potentially
invalidating the translations...
* change blocks until all translations can be updated?
* change happens - translations now stale, keep using stale translations?
* change happens - translations now invalid and not used?
No answer is pretty.
I believe that *none* of Perl's peers think it worth translating error
messages, and many have more resources than we do. I don't think that it's
realistic to assume that we should because we could. We *can't*. We don't
have the resources.
Diverting time to "being able to translate error messages" is diverting time
from delivering other features.
I don't think we're going to win back any mindshare with this feature.
We're not losing developers because other languages have translations and we
> > * single implementation defines the standard, instead of a standards doc
> > * monolithic implementation in C (parser, runtime, support)
> > and more nuanced, "large ecosystem of extensions written in C"
> Ok, this I don't like. Don't speak about "who doesn't have it" but speak
> "how it can benefit perl".
Please don't think that you can dismiss this.
"large ecosystem of extensions written in C" *matters*. It means that the C
internals are exposed to a large amount of code upon which the success of
the language as a whole depends.
Meaning that it's not *easy* to refactor the C code, because there are
dependencies on it that can't easily be changed, and hence have to keep
working. For example, DBI and DBD.
This gives their implementers a *lot* more freedom to change internal
representations to gain more flexibility or performance.
It also makes writing a JIT a lot lot easier.
> > I don't think that it's a good idea to propose ideas that don't really
> > make sull sense without some other potentially tricky thing not
> > implemented.
> Extrapolate. Should this tricky thing be available, then you can introduce
> magic for eg "CORE::Scalar::", "CORE::Array::", ...
> What will be benefit of that? Is it worth of experiment?
> I'd say yes.
> Before we even get to "what belongs in a vtable?"
> Again, is it worth of experiment?
> I'd say yes.
Agree, yes, it's worth an experiment. Experiments are always approved of!
Some fail. That's the point. It's research.
But good science changes as few variables as possible, as it's easier to
(Heck, that is about the *only* thing in this mail that I'm formally qualified
to say. Seriously. But seriously qualified to say it. The development stuff is
Running several experiments in parallel takes more researchers. Or slows
down getting the results of any single experiment.
Nothing stops anyone experimenting or prototyping.
> Regarding RFC process:
> this shows that there are relations between RFCs.
> For example later "milestones" this one depends on working autoboxing.
> Question here should be only: do we want to go that direction?
> If yes, just note this relation in RFC and start with autobox RFC.
> I don't disagree with this relation.
> (rest of comments removed, premature negativism)
The intent of the RFCs is not about "approving experiments". It's about
assessing proposals that look like they will work, and can delivers.
Implicit, but ought to be explicit is "deliver soon".
This is the "choosing battles" thing, and not repeating obvious mistakes.
We're trying not to repeat the great Perl 6 mistake of "taking 15 years to
deliver". We need to deliver improvements soon.
We have plenty of suggestions, far more than we have volunteers to implement
* we need to prioritise things that we can deliver this year
* to lower risk, we should pick things that have few(er) dependencies
experiments can run in parallel. experiments don't need RFCs.
RFCs should be for plans that can deliver.