Re^7: More comprehensive style guide for Perl docs than perlpodstyle?

I love minimalistic code. It's just that not everything can be minimalistic ... which is why Larry uses Huffman coding as a language design principle so that "things that are commonly used, or when you have to type them very often -- the common things need to be shorter or more succinct".

I suggested named arguments for split not substr. For substr, I suggested having string slices built into the language (as Python and Ruby do).

I'm not a language designer -- and splitting a string is a common operation -- so I'm sure there are better ways to fix split than my suggestion of named parameters. Unfortunately, in addition to being common, it's a lot more complex than substr. Designing a good split function is a hard problem. While Guido "solved" the problem for Python by dumbing down split, I see that perl 6 split handles the complexity by using "one of the :k, :v, :kv, :p adverbs" to control behaviour (update: I don't know what that means, later it says "A number of optional named parameters can be specified, which alter the result being returned" (including :skip-empty)).

Comment on Re^7: More comprehensive style guide for Perl docs than perlpodstyle? Download Code

Replies are listed 'Best First'.
Re^8: More comprehensive style guide for Perl docs than perlpodstyle? by Veltro (Hermit) on Jan 08, 2019 at 08:47 UTC
You keep saying that the `split` function needs fixing, but I don't see why. During the entire time that I have been using Perl, never have I encountered one situation that I was not able to use the `split` function to split anything. So instead of spreading this nonsense about how broken things are in your opinion, maybe you can ask questions regards the issue you are trying to solve instead. You can ask any question by providing some example with something that you are trying to accomplish and people here will most happily try to provide you with some answers. Now you mention Python: First of all it seems that there are actually two split functions: `split` and `re.split`. Second of all the prototype of the latter function is almost exactly the same as in Perl: `re.split(pattern, string, maxsplit=0, flags=0)`. There is no use of a dictionary with named arguments, so what are you actually saying? As a matter of fact there is one more argument as in Perl, but in Perl this flag is nicely incorporated in the regular expression. Third, Python introduces many other functions as `re.findall` to make the language more versatile. So, I ask you, what is it exactly that Guido has fixed?	[reply] [d/l] [select]
Re^9: More comprehensive style guide for Perl docs than perlpodstyle? by eyepopslikeamosquito (Archbishop) on Jan 08, 2019 at 10:51 UTC
As an aside, I gave split as an example of a function with a poor interface. It never occurred to me that anyone would attempt to defend it as a fine example of flawless API design - just as I didn't expect anyone to defend (the awful) interface provided by ANSI C strtok function when writing On Interfaces and APIs. Though I'm able to use both `split` (in Perl) and `strtok` (in C), I sometimes roll on the floor laughing at how bad their interfaces are. And yet their designers were very smart people ... which is the second point I wanted to make, namely that good API design is a genuinely hard problem. On Interfaces and APIs quotes Joshua Bloch's seven characteristics of a good API: Easy to learn. Easy to use, even without documentation. Hard to misuse. Easy to read and maintain code that uses it. Sufficiently powerful to satisfy requirements. Easy to extend. Appropriate to audience. In your opinion, how does Perl's split function measure up to the seven criteria above? I said Guido "solved" the problem for Python by dumbing down split. By putting the word "solved" in quotes, along with "dumbing down", I meant to indicate that it was not a particularly convincing "solution".	[reply] [d/l] [select]


more useful options
	PerlMonks