Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:114973 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 15271 invoked from network); 19 Jun 2021 11:42:12 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 19 Jun 2021 11:42:12 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id BB9331804C8 for ; Sat, 19 Jun 2021 04:59:42 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_PASS,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 19 Jun 2021 04:59:42 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id F176A5C00E4 for ; Sat, 19 Jun 2021 07:59:41 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute1.internal (MEProxy); Sat, 19 Jun 2021 07:59:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=euwliW CLJrW1swiHZygFCBysMLY1zOQnr2gt+BPvzLg=; b=WQmlC8Edm5yXcL+8Txj3rR Y1vH3XHeVSqSosKuP9hz55XEsD0EkUHpf4FQR7QXDGjG5dXFwgM4Ly0Mj0eSSQ1J OZokkO9SRnuz8/QMW6ZSWqHKiMcw2oqGa3U40gxVXTMAozymym25N1rVypOJwuU7 Pxt7gcqH1tQ0c7oKa2g7sB/H2OTk8nzjxgga+lV+LUQz33/VJtEWXRbGYewrDCUH 1C2N+PzdXZy+xmBJDwRDFXNRlzCqoWYqyKhn4zO24wGzYGFTjFPprRxmJ5gpqVMw F4q6C4q4iZozZfpxs0vWNKmgtMQAxup3/3kzolpuLJky//z81RvWQp2QkJJV4FEw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeefhedggeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdfnrghr rhihucfirghrfhhivghlugdfuceolhgrrhhrhiesghgrrhhfihgvlhguthgvtghhrdgtoh hmqeenucggtffrrghtthgvrhhnpeeglefgkeduiedvvdetffeujefftdfhjeeiveehgfff keduveektddvledvvdfffeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpehlrghrrhihsehgrghrfhhivghlughtvggthhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BB719AC0072; Sat, 19 Jun 2021 07:59:41 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-526-gf020ecf851-fm-20210616.001-gf020ecf8 Mime-Version: 1.0 Message-ID: <285a489f-c609-423c-ad18-3313c3797cc8@www.fastmail.com> In-Reply-To: <37A59CDF-D3C7-4B3D-B389-CF2D9052C8FF@newclarity.net> References: <222b3921-3d9b-47f9-8d13-e6a123f36fad@www.fastmail.com> <37A59CDF-D3C7-4B3D-B389-CF2D9052C8FF@newclarity.net> Date: Sat, 19 Jun 2021 06:59:21 -0500 To: "php internals" Content-Type: text/plain Subject: Re: [PHP-DEV] [Vote] Partial Function Application From: larry@garfieldtech.com ("Larry Garfield") On Sat, Jun 19, 2021, at 3:22 AM, Mike Schinkel wrote: > Just to offer a counter perspective since the assertion was made that > partial functions would be hard for beginners. > > I believe beginners will have a harder time comprehending closures, and > especially short closures, than partial functions. And especially for > the use-cases which are likely to be more common, none of which are any > more "functional" in nature than PHP already is. The use-cases I think > will be more common? Calling any of the existing built-in PHP functions > that accept a callable as a parameter. > > I am no expert on beginners but I did teach beginning programmers in a > classroom setting for a decade. One of the biggest stumbling blocks I > have found for beginners is excessive syntax that looks complex. Many > of the concepts themselves are less difficult for beginners to > understand. > > So, in my experience it will be easier for newbies to understand this, > for example: > > array_map( $this->sanitize_value(?), $values ); > > Rather that this: > > array_map( fn($value) => $this->sanitize_value($value), $values ); > > The latter just has more sigils to grok than the former, and from what > I've seen with newbies when you throw too many sigils at them they > quickly move into a learned helpless state and think that it will be > too complicated for them to understand. Frankly, that's the impression I get as well. Any time PHP developers are discussing "what newbies find easy," there's a very, *very* strong bias toward "newbies are writing procedural code like it's 1990" and anything more complex than that is "advanced and confusing." And it always seems to be said by people who either are themselves primarily procedural programmers or started off as such, years ago. That bias leaks into their thinking about "what newbies think." The thing is, new developers don't think *anything*. There's nothing intrinsically more "natural" about procedural code vs functional code, or OOP code, or whatever other paradigm. They're all artificial as far as the brain is concerned. People who start off in an OOP language, and are taught OOP from the get-go, are just as confused by procedural code as someone who learned procedural is when viewing OOP for the first time. Same for people who start in FP languages. To hold that functional concepts or OOP concepts or whatever are "more advanced" and "less newbie friendly" than procedural is to buy into the rather damaging elitism that some in FP or strictly OOP languages have; that they're somehow "higher order developers" because they write in LISP, or Clojure, or Haskell, or whatever. That is simply self-serving elitism, but it is really easy for those in more conventional languages to inadvertently buy into that elitism. The trend in recent years has been very clearly toward multi-paradigm languages. Even the world's most widely used language today, Javascript, is now a procedural/OOP/functional hybrid. It has its warts along the way (as does PHP), but if anything, given the number of people who get their start in Javascript these days I wager they'd *expect* to have easy to use higher-order functions, because Javascript does. In Javascript they would just write a function name directly, but "Oh, I have to put (?) after it" is a very short jump. In some ways, we're still playing catch up, and PFA is an important part of that catch up. Let's not limit PHP's potential reach with new-to-PHP developers by acting like they're all still late-90s new-to-development. These days, odds are good they're Javascript developers looking to move server-side, and they'll already have exposure to many functional concepts even if they don't know them as such explicitly. For them, the common, non-pathological cases of PFA should be readily obvious to read and understand. --Larry Garfield