5 ms·

I'm not entirely sure you've illustrated that it's a bad idea. I believe that I illustrated that a simple pattern is not easily doable in Python but is in Perl

I'm not entirely sure you've illustrated that it's a bad idea. I believe that I illustrated that a simple pattern is not easily doable in Python but is in Perl 6. You'll have to show that this is a bad pattern or the implementation is bad or something at least to prove your point. There's more to sigils than just scalars and arrays too, as you can see here: http://doc.perl6.org/language/variables#Sigils http://doc.perl6.org/language/variables#Sigils The difference in your examples are that scalars describe more the 'shape' of the variable than its type. Given that a lot of programming is dealing with lists or 'dictionaries' this is a fairly minimal intrusion into the code that very much improves succinctness, correctness and the ability to easily read what some code is doing. Oh, and strings don't act like arrays in Perl 6 AFAIK. Because they could be split on characters, or codepoints, or bytes, you must be explicit: > for "Hello".comb -> $c { say "Character $c" } Character H Character e Character l Character l Character o (Or to be perly) > .say for "Hello".comb

DonHopkins 11y ago
What's wrong with using "isinstance(lst, str)" when necessary? The few cases when you need to make that distinction aren't worth infecting the rest of the code with punctuation marks. Using letters to explicitly spell out self-documenting words in the few function names that need to make that distinction is much less intrusive, more flexible, unambiguous and capable of precisely distinguishing many more nuances, than using a small set of punctuation characters throughout all of your code to mitigate rare problems with just a few cases. Of course it can be taken to an extreme, but it's much easier to guess or google for the meaning of an Objective C selector than for a bunch of Perl punctuation. http://stackoverflow.com/questions/15152171/what-is-the-longest-method-name-you-have-seen-in-ios-cocoa-touch http://stackoverflow.com/questions/15152171/what-is-the-long...
- hahainternet 11y ago
  > What's wrong with using "isinstance(lst, str)" when necessary? In order for it to be like the Perl6 implementation I would have to check against every type of iterable AFAIK. For example, a generator would be perfectly acceptable, but is there a unique function I could check with hasattr? Clearly you feel that sigils are intrusive in Perl 6, but having written a bunch I find it quite enjoyable, and they're pretty easy to find in the documentation too. Ultimately, you can use variables without sigils, but with caveats: http://doc.perl6.org/language/variables#Sigilless_variables http://doc.perl6.org/language/variables#Sigilless_variables
  - lmm 11y ago
    > In order for it to be like the Perl6 implementation I would have to check against every type of iterable AFAIK. For example, a generator would be perfectly acceptable, but is there a unique function I could check with hasattr? Define what it is you want - which function you want to use - and then check that (e.g. if you want to iterate over it check for __iter__; if you want to want to test membership check for __contains__). In one part of the code a generator might be acceptable; in another it might not. Which is the point really - array vs scalar seems like a simple, sensible, widely usable distinction on first glance, but it turns out the meaning you actually want is very context-dependent, and a global distinction is a lot less useful than it appears.
    - hahainternet 11y ago
      If I check __iter__ I consume strings too which is what I'm trying to avoid. Both of you have taken the perspective that this distinction is irrelevant but neither of you have a good answer to this case: > multi sub hi($a) { say "Hello there $a" } > multi sub hi(@a) { hi($_) for @a } > hi("lmm") Hello there lmm > hi(<lmm DonHopkins>) Hello there lmm Hello there DonHopkins Surely this is not so exceptional a use case?
      - DonHopkins 11y ago
        From a Python perspective, it looks to me like you're trying to take one particular style of programming (overloading functions) to an extreme (or at least fetishizing it), when it doesn't buy you anything particularly worthwhile, even though is comes at a high cost in terms of cognitive load (and runtime reflection in dynamic languages like Perl, Python or JavaScript). Why should you have to write a special function that knows about looping, when the language already provides several perfectly fine ways to loop? jQuery loves to do that kind of stuff too, slowly sniffing and savoring the arity of its arguments and reflecting on their types at runtime, then doing totally different things like getting, setting, configuring, instantiating, sending messages, and iterating, depending on the number and type of parameters, possibly selecting multiple items even if you only want one, etc... Personally I don't think that style makes code any easier to read or write or guess what it will do, and it sure is a source of a lot of implicit behavior and inexplicable errors. Having one function named "x" that gets x, sets x, iterates over the x dimension, searches for x, or creates x widgets depending on how it's called doesn't make my life any easier. I'm willing to read and type a few more letters to use a set of longer self documenting function names. Using explicit descriptive consistent names, instead of heavily overloading short names and sigils, also makes the documentation easier to search and the IDE easier to use. Explicit is better than implicit or inexplicit. What is so important about the scalar/array dichotomy (which I think is fuzzy, arbitrary and artificial), that they get their own sigils to disginguish them, but you don't also use different sigils to distinguish ints from floats, numbers from strings, arrays from dictionaries, objects from classes, locals from globals, objects from proxies, inputs from outputs from references, etc? The root of the sigil problem is that you quickly run out of unused ASCII punctuation characters to decorate all the concepts you feel the need to distinguish. Of course you could limit identifiers to a single character and require the use of Unicode, like Bjarne Stroustrup suggested in "Generalizing Overloading for C++2000" [1], but isn't it simpler and easier to just use letters that spell out what you mean as words, instead of context sensitive punctuation you have to look up in a legend? I like the way C# uses "in", "out" and "ref" instead of punctuation or emojis. [1] http://www.stroustrup.com/whitespace98.pdf http://www.stroustrup.com/whitespace98.pdf

DonHopkins 11y ago

What's wrong with using "isinstance(lst, str)" when necessary? The few cases when you need to make that distinction aren't worth infecting the rest of the code with punctuation marks. Using letters to explicitly spell out self-documenting words in the few function names that need to make that distinction is much less intrusive, more flexible, unambiguous and capable of precisely distinguishing many more nuances, than using a small set of punctuation characters throughout all of your code to mitigate rare problems with just a few cases. Of course it can be taken to an extreme, but it's much easier to guess or google for the meaning of an Objective C selector than for a bunch of Perl punctuation. http://stackoverflow.com/questions/15152171/what-is-the-longest-method-name-you-have-seen-in-ios-cocoa-touch http://stackoverflow.com/questions/15152171/what-is-the-long...

hahainternet 11y ago
> What's wrong with using "isinstance(lst, str)" when necessary? In order for it to be like the Perl6 implementation I would have to check against every type of iterable AFAIK. For example, a generator would be perfectly acceptable, but is there a unique function I could check with hasattr? Clearly you feel that sigils are intrusive in Perl 6, but having written a bunch I find it quite enjoyable, and they're pretty easy to find in the documentation too. Ultimately, you can use variables without sigils, but with caveats: http://doc.perl6.org/language/variables#Sigilless_variables http://doc.perl6.org/language/variables#Sigilless_variables
- lmm 11y ago
  > In order for it to be like the Perl6 implementation I would have to check against every type of iterable AFAIK. For example, a generator would be perfectly acceptable, but is there a unique function I could check with hasattr? Define what it is you want - which function you want to use - and then check that (e.g. if you want to iterate over it check for __iter__; if you want to want to test membership check for __contains__). In one part of the code a generator might be acceptable; in another it might not. Which is the point really - array vs scalar seems like a simple, sensible, widely usable distinction on first glance, but it turns out the meaning you actually want is very context-dependent, and a global distinction is a lot less useful than it appears.
  - hahainternet 11y ago
    If I check __iter__ I consume strings too which is what I'm trying to avoid. Both of you have taken the perspective that this distinction is irrelevant but neither of you have a good answer to this case: > multi sub hi($a) { say "Hello there $a" } > multi sub hi(@a) { hi($_) for @a } > hi("lmm") Hello there lmm > hi(<lmm DonHopkins>) Hello there lmm Hello there DonHopkins Surely this is not so exceptional a use case?
    - DonHopkins 11y ago
      From a Python perspective, it looks to me like you're trying to take one particular style of programming (overloading functions) to an extreme (or at least fetishizing it), when it doesn't buy you anything particularly worthwhile, even though is comes at a high cost in terms of cognitive load (and runtime reflection in dynamic languages like Perl, Python or JavaScript). Why should you have to write a special function that knows about looping, when the language already provides several perfectly fine ways to loop? jQuery loves to do that kind of stuff too, slowly sniffing and savoring the arity of its arguments and reflecting on their types at runtime, then doing totally different things like getting, setting, configuring, instantiating, sending messages, and iterating, depending on the number and type of parameters, possibly selecting multiple items even if you only want one, etc... Personally I don't think that style makes code any easier to read or write or guess what it will do, and it sure is a source of a lot of implicit behavior and inexplicable errors. Having one function named "x" that gets x, sets x, iterates over the x dimension, searches for x, or creates x widgets depending on how it's called doesn't make my life any easier. I'm willing to read and type a few more letters to use a set of longer self documenting function names. Using explicit descriptive consistent names, instead of heavily overloading short names and sigils, also makes the documentation easier to search and the IDE easier to use. Explicit is better than implicit or inexplicit. What is so important about the scalar/array dichotomy (which I think is fuzzy, arbitrary and artificial), that they get their own sigils to disginguish them, but you don't also use different sigils to distinguish ints from floats, numbers from strings, arrays from dictionaries, objects from classes, locals from globals, objects from proxies, inputs from outputs from references, etc? The root of the sigil problem is that you quickly run out of unused ASCII punctuation characters to decorate all the concepts you feel the need to distinguish. Of course you could limit identifiers to a single character and require the use of Unicode, like Bjarne Stroustrup suggested in "Generalizing Overloading for C++2000" [1], but isn't it simpler and easier to just use letters that spell out what you mean as words, instead of context sensitive punctuation you have to look up in a legend? I like the way C# uses "in", "out" and "ref" instead of punctuation or emojis. [1] http://www.stroustrup.com/whitespace98.pdf http://www.stroustrup.com/whitespace98.pdf