Front page | perl.perl5.porters |
Postings from October 2012
Re: What happened to the whole "small core" idea?
Thread Previous
|
Thread Next
From:
Aristotle Pagaltzis
Date:
October 27, 2012 09:53
Subject:
Re: What happened to the whole "small core" idea?
Message ID:
20121027165314.GA28047@fernweh.plasmasturm.org
* Peter Rabbitson <rabbit-p5p@rabbit.us> [2012-10-27 10:35]:
> It has been 4 years, and still precious time is spent discussing how
> to cram yet another *very* controversial and complex piece of syntax
> directly into the core.
Ironically, the controversy over this feature is generated by people who
think the syntax proposed is *not comprehensive enough*. There has been
no dispute whatsoever over how the syntax should look for the amount of
functionality that is in the proposal, and only one point of dispute
over how it should work (read-only alias vs copying), which resolved to
consensus in due course.
Funny, isn’t it?
Of all the complaints about insufficient functionality, only one has
turned out to uncover a serious oversight which requires addressing:
what to do in case of a mismatch in the number of expected vs passed
arguments. (That actually throws the feature in jeopardy in my mind.
I may have proposed a solution, and I would like to see it attempted,
but due to this issue I am no longer certain of the feature. It may
regrettably need even more time in the cooker.)
> What happened to the “ship it on CPAN and see” mantra?
It worked. There are about half a dozen signature modules on CPAN, all
implementing variations of the same syntax. At which the point is the
“and see” part satisfied? Seventeen more variations?
> What happened to making perl smaller and less complex?
It’s happening. The trend has been toward kicking out things, and FC has
done a lot of work to expose hooks into the language at various levels.
New features have been much more conservatively scoped and everyone is
a lot more wary of adding huge new things. We have RJBS at the helm now,
whose instincts I trust.
But this is not always going to be the direction you seem to think of as
an absolute. As Larry once remarked about Lisp, it is the most beautiful
language in the world and every program written in it looks like oatmeal
with nail clippings. Someone has to pay for simplicity and the language
is not implicitly and by defintion the wrong place for that.
> Why after smartmatch and $_ localization and auto-deref (which has not
> yet backfired, but it will), is this still happening?
If my memory is still of service, there were roughly half a dozen fewer
implementations of these things that shipped on CPAN than of modules
that implement signatures. That is, zero of either.
Personally I hated smartmatch the second it was proposed; I don’t know
if I would use it even in Perl 6, and I never thought it had any place
whatsoever in Perl 5.
I also hated auto-deref, almost certainly for the same reasons as you
would list here if you did. But I also think it partially addresses
a real problem in the wrong way. I.e. I do believe there is a problem
that ought to be solved, so even though I consider auto-deref a mistake,
there is conceivably other, more fundamental syntax that I would not
oppose – unlike you, presumably. So far I have not seen a proposal that
seemed to fit the language, though.
Maybe all precedents are not the same.
Do you hate the addition of the /r flag for s///, for example? (I love
it, personally. I use it all the time – even more than I expected.) If
not, why not?
Use your discrimination.
> Let's focus on sub signatures for a bit. I've read every thread about
> them. Peter Martin's work kicks ass. The speedups are tangible which
> is even more awesome. Yet the whole proposal seems to be set up “It
> either happens in core or it doesn't happen at all”. Why?
Why indeed? Why does it seem that way? After all it has happened on CPAN
a half-dozen times. So where is your impression coming from that that is
not the case?
> What prevents the core from exposing the correct-level hooks, have
> *these* hooks unit tested, and relegate the syntax extension mucking
> to CPAN? I do not think performance is an issue – after all linked
> C is linked C.
You make it sound so easy. How is XS supposed to add a new op type that
skips populating @_? How do you implement compile-time checking for the
number of arguments with syntactic override?
How would you have implemented the /r flag of s/// on CPAN?
Of course it’s all possible *somehow*, even if that means swapping out
half of core for code copy-pasted from core into a module and tweaked
there, like Devel::Declare used to be.
Or I suppose if you put enough smarts into it you could instead design
a decomposition of the current architecture that provides enough hooks
into what happens during e.g. a sub call to allow implementing in XS
even things down to the level of not populating @_. That would get
closer to your vision.
But what is the evidence that doing such API design work in an abstract
vacuum rather than as part of the implementation of a concrete feature
will yield a design that actually covers the needs of real feature
implementations?
Needless to say, it is far more complex to design an interface on top
of which features can be implemented, than to design features. (I don’t
have my Mythical Man-Month here, else I’d include here a quote about the
tripling? of complexity? effort? required that Brooks pointed out.) Of
course you have to find someone who is motivated to do this demanding
work as an obstacle on the way to the feature they actually care about.
And then those interfaces have to be supported forever.
There’s a parallel to the microkernel vs Linux argument in there too.
> Maintainability can't be a problem either – if anything it will be
> awesome to have a well factored boundary that will make a performant
> CPAN module for such extensions possible.
Of course it will be awesome. And ponies are awesome too. :-)
> Hence why I particularly lament the lack of movement towards Jesse's
> vision.
I think you conveniently forgot the part where the very motivation for
Jesse’s vision was his belief that the language has to evolve to stay
relevant, and his desire to be able to break things while *adding* or
changing syntax, without that entailing massive backcompat fallout. He
was *not* advocating for language standstill.
Here you are, holding up his proposal as the end of language change.
Furthermore, he derived a concrete proposal from that, which personally
I have criticised on numerous occasions as ill thought out on technical
grounds. I see no way to follow through on it without a *geometric*
increase in *language* complexity over time.
Here you are, holding up his proposal as the road to simplicity.
Topsy turvy world. :-)
Practice has borne out my concern too, at least in the case of moving
smartmatch to the CPAN, which was a tentative suggestion of his as an
as an example for what he was imagining. The idea was ditched when no
one could figure out a way to allow competing implementations to coexist
in the same interpreter process, let alone with predictably composing
semantics. It would have been a recipe for even more psychosis, not
sanity – which to me appeared obvious from the start.
> IMNSHO Perl5 does not need *any* extra *syntax* from here on out.
IMequallyNHO it does. But it needs syntax that addresses shortcomings at
the right level with solutions that fit the language, rather than myopic
to the point of blindness local tweaks to single bits of the language,
which fail to consider its entirety (e.g. auto-deref).
> In fact it stopped needing it around 5.6-ish. No new syntax unless
> there is a massive benefit in adding it, and even then only if it can
> not be done via a CPAN-distributed extension. Besides Reini's work on
> strict types, nothing else currently comes to my mind as a candidate
> for “this *has* to be in core”.
There is a design principle called “sane defaults”.
> “Even though EVERYONE agrees on the core syntax and EVERYONE wants it”[3]
If I go count the number of old threads and patches on p5p plus the
number of supportive participants in them, will that plus the half dozen
signature implementations on CPAN make any impression on you? I am
willing to do the work if that’s what it takes to convince you that this
is a feature with, if not literally singularly universal (as you seem to
interpret my words), then at least extremely widespread support.
And if core devs disagree, how many other voices do theirs weigh up
against?
Ultimately, of course, the pumpking decides. (Or Larry as the highest
instance, obviously, when Larry does make a call on something in Perl 5
any more.)
> And the worst part? - it appears that nobody wants the fucking thing
> except for a very very small but very very vocal minority.
My experience has been that nobody wants 5.10.
People who upgraded to 5.10 have kept on upgrading further for the most
part. Everyone who didn’t has stuck with 5.8.
IMO this is yet another indictment of the disaster that was Perl 5.10
and the catastrophe that was the p5p process of that era. Fortunately
those are now in the past.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
Thread Previous
|
Thread Next