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

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?

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

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]