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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
