> perhaps writing if 5 < x and x < 100 instead of the much clearer if 5 < $x < 100
Why not "if 5 < x < 100"? Sigils look awful.
Why not "if 5 < x < 100"? Sigils look awful.
Also you get to know if a variable is only block scope, method scope, class variable, etc.
Twigils in Perl 6 are where the scope indicators come in, clarifying class instance vars, dynamic scope, and so on.
So if I see %.foo I can tell you that this variable can be used as the Associative role, that it is scoped as an instance variable, and that it has an accessor with the same name.
For more, see the first few sections of http://doc.perl6.org/language/variables
Because sigils tell you things. What if 'x' in your example is a list? Are you now checking the length of the list rather than the value? Sounds like room for a security bug to me.
Only if your language is really awful. A good language shouldn't even let you run "5 < x" when x is a list, but even a mediocre one would surely at least make that error out at runtime rather than giving a nonsense answer.
It depends what you consider "Nonsense". Python for example has no reliable way to differentiate between a string and a list. Strings are iterable, but lists can't be compared with the < syntax for example.
My point is simply that $x very clearly says (in Perl 6) "A single value called x" wheras @x is "A list of values called x". In python, "x" is indeterminate even at runtime.
Oh, and you can declare barewords with \x for example, if you really want to, it is Perl after all.
Python 2.7.10 (default, Jun 10 2015, 19:42:47)
[GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> type([1])
<type 'list'>
>>> type('1')
<type 'str'>
>>> type(1) == type('1')
False
>>> [1] < [2]
True
>>> [2] < [1]
False
>>>
Doing something like isinstance(x, str) is discouraged and considered non-pythonic, and recently hasattr() has also been talked about. However, both strings and lists can be iterated, so assuming that this will fail is incorrect:
x = "Hello"
for y in x:
print("{} is {}".format(y, type(y)))
edit: I also should have said above "lists can't be compared with strings using <". I was trying to point out Python did things potentially correctly there, but I see now it's ambiguous.
How should you decorate functions that return different types depending on what context they're used in? http://perlmaven.com/wantarray
If it's so important to visually distinguish the names of scalars and arrays, then shouldn't you also be able to distinguish a string from an int, like BASIC's a$ -vs- i%?
So why just distinguish lists and scalars? Why not go all the way to Hungarian Punctuation and use Unicode and Emoji characters to uniquely decorate variables for every other possible built-in and user defined type? https://en.wikipedia.org/wiki/Hungarian_notation#Relation_to...
However, if you really want to do some of the other things you've listed they are possible to do. Perl 6's syntax can be augmented by the programs being executed.
I'm honestly interested though, was I ultimately wrong above? Is there a smart way to define a function in python that can take both a single item and a list of items? In Perl 6 I'd just define a multi sub where the list form applies the single item sub for each item in the list.
If Perl 6 is an entirely new language, then why is it riddled with so many bad ideas from another language that only coincidentally shares the first 4 alphabetic characters of its name?
Why the artificial scalar/array dichotomy? What is it that is so important about being able to distinguish variables holding scalar-like values and array-like values by punctuation, but it doesn't matter that you can't distinguish variables holding strings and integers by their punctuation?
And how can you be consistent about types that act like both scalars and arrays, like strings? Or user defined types that might behave like scalars or arrays but are represented by objects? Are those treated as arrays? Or are they references, treated as scalars?
Scalar -vs- array is a false dichotomy that's deeply and unnecessarily embedded in the very syntax of the language.
There's more to sigils than just scalars and arrays too, as you can see here: 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
> .say for "Hello".combThe 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-long...
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
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.
> 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
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.
In Perl 6 function overloading is generally resolved at compile-time.
> Explicit is better than implicit or inexplicit.
Explicit what?
(jk)
> What is so important about the scalar/array dichotomy
See my earlier reply to another of your comments.
> context sensitive punctuation you have to look up in a legend?
Sigils are not context sensitive.
> 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.
The distinction corresponds to major distinctions known to be wired in to human brains: single vs plural, and number vs name.
If this seems arbitrary to you perhaps you lack self awareness?
(jk)
I think we get away with those in natural languages because humans are willing to be fuzzy about that. E.g. whether an organization is singular or plural differs based on context and dialect. Whereas the only distinctions it makes sense to use in programming languages are those that we can make precise.
http://www.learn-english-today.com/lessons/lesson_contents/g...
I see no conflict between a mental process being a fuzzy "natural language" thing in our brains and the code modelling that concept using a precise formulation.
Indeed, to the degree I'm wrong we're in trouble. To read and write code we have to use what we've got -- our brains -- and we have to work with them the way they insist on working:
"Janet Siegmund and her colleagues observed 17 participants inside an fMRI scanner while they were comprehending short source-code snippets
...
The programmers in the study recruited parts of the brain typically associated with language processing and verbal oriented processing (ventral lateral prefrontal cortex)
...
Interestingly, even though there was code that involve mathematical operations, conditionals, and loop iteration, for these particular tasks, programming had less in common with mathematics and more in common with language. Mathematical calculations typically take place in the intraparietal sulcus, mathematical reasoning in the right frontal pole, and logical reasoning in the left frontal pole. These areas were not strongly activated in comprehending source code."
~~ http://www.huffingtonpost.com/chris-parnin/scientists-begin-...
To my mind that suggests an ideal programming language would not "hardwire" rules of grammar, that sigils should be more like flexible hints to the reader than things that have rigid language-level meanings.
Apologies if I'm harping on about this too much but I would like to object to "If" as being too ambiguous in this context.
The most active non-memory/attention brain circuits used in comprehending the code samples in the study I referenced were consistently for natural language processing, not math/logic processing, for all 17 of the 17 participants in the study.
It's a small test but a pretty emphatic one nonetheless. For at least some folk (and it's at least plausibly most/all folk) for at least some code (and it's at least plausibly most/all code), it's "WHEN we comprehend code we use natural language circuits and so...", not "IF...".
> that argues for having our programming languages emulate natural languages.
Well, careful. Natural languages are fuzzy! We want programming languages that do TWO things -- leverage our natural processing capacities to the degree they're relevant AND render their fuzziness relatively harmless at the same time.
> Even in matters of precision such as legal contracts, we don't always conform exactly to the "rules" of grammar - indeed I'd say that legal language violates those rules even more than natural language does.
Yes. This is a very important point. Think in terms of thousands of DSLs. How does one enable that? How does one cope with that?
> To my mind that suggests an ideal programming language would not "hardwire" rules of grammar
Right. The Perl 6 project not only addresses this but is a full frontal assault on it. It's one of the various reasons it took 15 years to get to 6.c.
There's a standard Perl 6 grammar but Perl 6 Rules can relatively easily specify any grammar. And I mean any grammar, whether Chomsky hierarchy level 1 (regular languages -- where regexes originally came from) or level 2 (context-free -- where parser combinators have traditionally shone) or level 3 (context-sensitive -- various parser combinators extensions have recently started to nibble at this) or the final level 4 (recursively enumerable languages).
Aiui Perl 6 can reasonably be viewed as the world's first practical "universal unrestricted grammar" capable of accepting any other language.[1]
> sigils should be more like flexible hints to the reader than things that have rigid language-level meanings.
Sure.
For starters, sigils are just a part of standard Perl 6. You can write any language in Perl 6. So, for example, the ipso language is a sigil free lang (it's a lisp) in Perl 6[2] and Slang::SQL is for embedded SQL.[3]
If we stick to standard Perl 6, sigils just mean a few very general things, as follows.
First, that the associated term is primarily a "noun". This determines where it does and doesn't fit in the grammar.
Then particular sigils -- the main ones are $, @ and % -- establish some other properties of a given noun.
$ emphasizes the noun's singular nature rather than any potential plural nature it might also have.
@ emphasizes the noun's plural nature and having an integer index (the array `my @bananas[15]` corresponds to a bunch of 15 bananas indexed by 0 thru 14).
And finally % emphasizes plural nature and having an associative index (%colors<red> corresponds to the 'red' key'd value in the %colors dictionary).
You might argue that those are rigid. I'd counter that they correspond to human's natural processing circuits. But regardless, if you don't like them or want to repurpose them you can just create a slang or another lang that tweaks or entirely changes the grammar to suit your needs...
[1] https://en.wikipedia.org/wiki/Unrestricted_grammar
Ultimately, the scenario I came across this in was an atomic transaction decorated function. The data being provided to this function flows through a good 3 or 4 functions beforehand. I also require _single, _list and _listoflists behaviour. This would bloat a 4 function stack into something like 20 different functions. There are also issues with transaction decorators.
It just seems crazy to me that Python can't manage this (to me trivial) use case.
So it sounds like your needs don't align exactly with perl's sigils anyway (and why should they? For different business requirements you'd categorize differently).
> This would bloat a 4 function stack into something like 20 different functions.
Not with good language/design. Separate your concerns. Let the difference in behaviour live somewhere more appropriate - either on an object that contains the data (OO style) or in a callback you pass into the function (functional style).
> There are also issues with transaction decorators.
Decorators have problems yes, that's why I prefer to have a type system handle that kind of thing.
Indeed but I can write constraints in my function signature to permit this. Hell I can even define something as SpecialList[SpecialKey] if I truly wanted. Perl has a type system.
> Not with good language/design. Separate your concerns. Let the difference in behaviour live somewhere more appropriate - either on an object that contains the data (OO style) or in a callback you pass into the function (functional style).
Doing this in Python is an exercise in horror, frustration and hatred. Doing it in Perl is the work of a few seconds. That is my point.
Interesting. Is this a new thing?
> Doing this in Python is an exercise in horror, frustration and hatred. Doing it in Perl is the work of a few seconds. That is my point.
Then what's the perl example without using sigils? Does that not translate directly into python?
What is the single "thing" you're referring to and what is "new" relative to?
I interpret hahainternet's comment to refer to at least three new things in Perl 6 relative to Perl 5: Perl 6 has a carefully developed type system, roles support parametric polymorphism, and both static and dynamic type constraints on parameters are supported.
-----
You earlier wrote "If you want two different behaviours, write two different functions". But hahainternet had written two different functions. This suggests you hadn't then yet taken on board what multidispatch is (a fundamental innovation -- from the 80s iirc -- related to declaring and calling functions).
Then you responded to hahainternet's "This would bloat a 4 function stack into something like 20 different functions." with "Let the difference in behaviour live somewhere more appropriate ... on an object that contains the data (OO style) ..." without realizing that that's less appropriate, not more:
"In the presence of multiple dispatch, the traditional idea of methods as being defined in classes and contained in objects becomes less appealing" (from https://en.wikipedia.org/wiki/Multiple_dispatch).
A similar argument applies to callbacks.
All in all I'm guessing you haven't yet seen the light about multidispatch and a read of https://en.wikipedia.org/wiki/Multiple_dispatch#Perl_6 might help clear some things up.
The type system and perl 5. That would have been a much more constructive response to "why perl 6?" (if it's as good as you say) than this article.
> You earlier wrote "If you want two different behaviours, write two different functions". But hahainternet had written two different functions. This suggests you hadn't then yet taken on board what multidispatch is (a fundamental innovation -- from the 80s iirc -- related to declaring and calling functions).
No need to be rude. Rather than argue over whether the cases of a multimethod are different functions or the same function, let me just clarify that if you want two different behaviours then it is clearer to give them different names.
> "In the presence of multiple dispatch, the traditional idea of methods as being defined in classes and contained in objects becomes less appealing" (from https://en.wikipedia.org/wiki/Multiple_dispatch).
That article is decidedly non-neutral. I'm well aware of multiple dispatch. I find it very bad for code maintainability, and often a sign of poor domain modeling. The interaction between two objects is an unnatural and opaque place for behaviour to live; usually the behaviour belongs to one or the other or on its own, or if their relationship is that complex it should probably be promoted to a first-class entity.
> The type system and perl 5.
Gotchya. Perl 6 is not a Perl 5 update. There are reasons it shares the name Perl, which usually become obvious if you know both langs, but for non-users it's best to think of Perl 6 as a completely new language.
> That would have been a much more constructive response to "why perl 6?"
I think the OP article was a mostly good humored response to the reality that a lot of responses to Perl 6 are absurd. Like individuals sincerely asserting that it should not be taken seriously by anyone for any commercial purpose -- because of perceived problems with the logo chosen by the language design team!
> (if it's as good as you say)
Uhoh. Did I say Perl 6 is good? I think, right now, it's a lot of fun if you're in to all sorts of PLs. But let me restore balance in the force. The language isn't equational and its type system isn't Hindley Milner. Compiled code is very slow and consumes a lot of RAM and fully fixing that is going to take many years worth of engineering. The doc needs tons more work. There are only a handful of modules. It's a new and unproven language. Balance restored?
> No need to be rude.
My apologies. I didn't mean to be rude.
(I looked over your other responses in this thread prior to posting my comment and none suggested to me that you were claiming familiarity with multidispatch and several suggested to me that you did not really have a feel for how they work out when properly used in Perl 6.)
> Rather than argue over whether the cases of a multimethod are different functions or the same function, let me just clarify that if you want two different behaviours then it is clearer to give them different names.
Gotchya.
Nit: multidispatch in Perl 6 works for any function and (almost) any operator (operators are actually just functions), not just methods.
The Perl 6 view is that multi functions/ops/methods have both a "short" name and a "long" name. The short name is the bit that goes before the parameters. The long name includes the signature. It's a different perspective on naming and I find it works well for me.
> I find it very bad for code maintainability, and often a sign of poor domain modeling. The interaction between two objects is an unnatural and opaque place for behaviour to live; usually the behaviour belongs to one or the other or on its own, or if their relationship is that complex it should probably be promoted to a first-class entity.
I hear you've encountered use of multiple dispatch that you don't like, and that it's often signaled poor design, and that you think that the code placement for a multimethod is fundamentally unnatural.
But I don't hear that you've encountered multiple dispatch for functions and/or operators rather than methods; or that you've seen the scenarios in which it is a good fit for coding (I presume you don't think there's literally no sweetspot use-case); or that you've had a chance to work with a language like Perl 6 in which multimethod placement is as you suggest. So it sounds like you have only encountered limited and perhaps poorly designed and/or used multiple dispatch and that's colored your perspective.
Anyhoo, thanks for the exchange, and I hope you get another chance to use Perl 6 for something it's good at and see that, whatever else may be true, it is a lot of fun. :)
There is no such division of types in Perl 6 in the normal CS sense of the word "types".
There are several kinds (in the English sense, not CS sense) of data containers. Elements of these containers can be of any type (CS meaning).
> just like the idea of functions caring about the context of their return value.
As the GP just said, Perl 6 dropped that.
> Why the artificial scalar/array dichotomy?
The distinction between singular and plural is natural, wired in to our brains, not artificial.
> What is it that is so important about being able to distinguish variables holding scalar-like values and array-like values by punctuation, but it doesn't matter that you can't distinguish variables holding strings and integers by their punctuation?
As explained above, it's not about the values but the containers. Strings and integers are data. Containers are not data.
> And how can you be consistent about types that act like both scalars and arrays, like strings?
Perl treats strings as values.
Containers can certainly be data. A string is a container of characters, and we're certainly interested in its value as data. A window is a container of sub-windows. In many systems, windows inherit from and/or behave like containers, so you can loop over them and manipulate them just like containers.
So should the window.Add(subWindow) method automatically loop over the subSubWindows of subWindow and add each of them as direct children of window, or should it simply add subWindow to window directly so its subSubWindows are grandchildren of window?
I was referring to Perl's scalar/array distinction as being artificial and fuzzy -- I wasn't claiming the singular/plural concepts in your brain weren't natural. They're vastly different things. It's fuzzy magical thinking to believe that Perl's dichotomy of scalar/array maps directly to your brain's concept of singular/plural.
Does everyone's brain's built-in concept of plurality naturally support nested polymorphic arrays? Do those arrays in people's brains also behave like keyed hash tables, like Perl and JavaScript arrays? Must the keys be strings, or might they be any hashable idea? What does it mean for an idea to be hashable? Do Perl references work exactly the same way as actual human neurons? What about dolphin brains?
Please show me some peer reviewed scientific studies that prove Perl arrays accurately model natural language and mirror human thought, and then I will concede that Perl is more linguistically or biologically "natural" than Python.
But until I see some proof to the contrary, I believe that Larry Wall is to linguistics as Deepak Chakra is to physics:
"While in graduate school at the University of California, Berkeley, Wall and his wife were studying linguistics with the intention of finding an unwritten language, perhaps in Africa, and creating a writing system for it. They would then use this new writing system to translate various texts into the language, among them the Bible. Due to health reasons these plans were cancelled, and they remained in the United States, where Larry instead joined the NASA Jet Propulsion Laboratory after he finished graduate school." https://en.wikipedia.org/wiki/Larry_Wall
I appreciate your sarcasm.
I've heard some folk say they find the distinction between values and variables (containers) to be confusing. Imo this is worth discussing, as are issues about coding and the brain, so I'll continue.
> The propensity for fuzzy magical thinking is wired into our brains, not artificial.
Are you saying that the brain's capacity to distinguish singular and plural things is "fuzzy magical thinking"?
> But [the fact that the brain distinguishes singular and plural] doesn't mean [taking that into account is] a good way to design a programming language.
It also doesn't mean it's not. More on this in a mo.
> Containers can certainly be data.
Yes. I thought use of Wittgenstein's ladder[1] was wise given the mistake you'd made that was the first thing I responded to in our exchange in this subthread.[2]
Anything can be data just as code is data (explicitly so in, eg, lisps). But it can be helpful to distinguish code from data and the same applies to containers vs data. On the few occasions when a conceptual distinction is not helpful, one should simply ignore the distinction. (This is perhaps somewhat like lisp macros that could be said to conceptually treat code as code or as data depending on whether or not it's helpful to the human writer or reader to treat it one way or the other.)
> A string is a container of characters
In Perl 6 a "string" is not a "container" even if you like to think of it that way and/or use the words that way.
> So should the window.Add(subWindow) method automatically loop over the subSubWindows of subWindow and add each of them as direct children of window, or should it simply add subWindow to window directly so its subSubWindows are grandchildren of window?
Exactly. Both interpretations can make sense.
This is why Perls provide notation to emphasize either the scalar or composite interpretation of an entity and to optionally switch to the other interpretation for any given mention of that entity in code.[3]
> It's fuzzy magical thinking to believe that Perl's dichotomy of scalar/array maps directly to your brain's concept of singular/plural.
Audience member, to Deepak Chopra: "You stated ... that 'all belief is a cover-up for insecurity', right?" Deepak: "Uhuh". Audience member: "Do you believe that?" Deepak: "Yes."[4]
I consider the notion that Perl's singular/plural distinction maps directly to the brain's to be at least plausible as an explanation of why it seems so natural to me.[5]
> Does everyone's brain's built-in concept of plurality naturally support nested polymorphic arrays?
Iirc, the results from neuroscience I've read that study brain circuits that process aspects related to nesting (hierarchy) suggest it's reasonable to view them as distinct from those that process the singular/plural distinction in most humans.
So, to the degree that separate brain circuits could be said to be mutually supporting, I'd say that one's brain circuits that process plurality support nesting (and vice-versa).
Something similar may apply for polymorphism.[6]
> Do those arrays in people's brains also behave like keyed hash tables, like Perl and JavaScript arrays?
I think there's more than a century's worth of science supporting the notion that association is deeply fundamental to how the brain works. Aiui it's an even more primitive mechanism than processing hierarchy and singular/plural aspects.
> Must the keys be strings, or might they be any hashable idea?
Again, I think I'm on solid ground when I say that humans' brains naturally support association of arbitrary "things".
Perl 6 supports any hashable entities as hash keys, not just strings.
> Do Perl references work exactly the same way as actual human neurons? What about dolphin brains? Please show me some peer reviewed scientific studies that prove Perl arrays accurately model natural language and mirror human thought, and then I will concede that Perl is more linguistically or biologically "natural" than Python.
(I rather suspect you'd still not change your mind even if such ridiculous studies could and did exist and I showed them.)
For now I'll just mention "A new study provides new evidence that programmers are using language regions of the brain when understanding code and found little activation in other regions of the brain devoted to mathematical thinking."[7] and ask you to read the linked article and/or the study itself before declaring it entirely bogus.
> But until I see some proof to the contrary, I believe that Larry Wall is to linguistics as Deepak Chakra is to physics
One good antidote to confirmation bias is reflection on the copious scientific evidence that expressed sincere confidence is generally inversely proportional to measured competence in relation to a given skill.
That said, while I'm fairly confident that you will not have changed your mind about any of the things we've discussed, my hope is that I'm incompetent at reading your character and we're making actual progress in mutual understanding, at least inasmuch as you manage to be more creative with your sarcasm in the future. :)
[1] http://c2.com/cgi/wiki?WittgensteinsLadder
[2] I refer to your mistaken notion of Perls "dividing all possible types into two different classes, and then using punctuation to distinguish variables holding those two classes".
[3] Imo aspects of Perl 5 related to this were fairly simple for declaring and using simple data structures but quickly became much too complex for my taste for more complex structures and usage.
Over the last 5 years or so a consensus emerged in the Perl 6 community that the Perl 6 version of this part of the language's syntax and semantics was another mess, ruining what was otherwise considered a good design for declaring and using deep data structures. This was one of the two justifications for the Great List Refactor (the other was implementation simplicity and optimizability) which has since been completed to general acclaim in regards to syntax and semantics by many of the same folk who disliked the pre GLR situation.
Imo what 6.c delivers for dealing with data structures, shallow and deep, simple and complex, is pretty sweet.
[4] https://www.youtube.com/watch?v=Vg3-pwIP0X4#t=54m07s
While I find much to dislike about Deepak Chopra, and have mixed feelings about the first person to bring my attention to the notion that belief is redundant at best, harmful at worst, namely Jiddu Krishnamurti, I do nowadays consider belief to itself be magical thinking. If you know something's true, why bother with belief? If you don't, why hold on to belief as if it were reliable?
[5] I don't recall reading anything on polymorphism but my own guess would be that any natural language concepts that correspond to polymorphism, assuming that such can be reliably identified and found to correspond to some degree to brain circuits in some humans, would involve circuits that are typically distinct from brain circuits that are involved in processing of hierarchy and the singular/plural distinction but are mutually supportive.
[6] It seems you believe that scalar/array does not map directly to my brain's concept of singular/plural but have not provided scientific evidence to back it up. One could argue, and I will for nothing more than entertainment value, that belief based on nothing more than sufficiently advanced confidence is indistinguishable from magical thinking.
[7] http://www.huffingtonpost.com/chris-parnin/scientists-begin-...
my @x = 3,4,5,6;
say "yep" if 5 < @x.any; # yep!
(5 < @x.any).perl.say
# output: any(Bool::False, Bool::False, Bool::False, Bool::True)
Also, the inclusion of non-ASCII operators harkens back to APL. Mind mind isn't yet made up on whether I like this. I anticipate code being easier to read and harder to type. Given perl5's reputation in this regard, I'm optimistic I'll find it to be an improvement.
my %clients vs my @clients
Do you name your variables
client_list .. client_dictionary? No? Then sigils aren't superfluous.
This is really no different than how Lisp uses parenthesis in a different way than C, except that Lisp has the benefit of being more visually distinct so people that are familiar with C and C-like semantics don't immediately assume they know what's going on an why when they see Lisp constructs. Perl is different as well, but it often looks similar enough to cause people concern before they know what they are really looking at.
As for this specific example, arrays evaluated in scalar context (as opposed to list context) return the number of elements in the array. There is no array length function or method, as it's superfluous. 0+@x is the number of items in @x, and 5 < @x tests whether @x has more than 5 items, since < imposes scalar context. There are many, many places in the language where context is used to simplify operations, this is just a very simplistic example, but it should illustrate why sigils are important, as they change how operations are evaluated.
Put simply, it's not possible to make a coherent criticism of Perl's use of sigils without understanding context and how it's used within the language, and factoring the benefits and drawbacks of that into your criticism. To criticize without this knowledge is to do so from ignorance (in the literal sense, not as an insult).