| |||||||||||||
Should be: Goodnight, Perl 6.Should be: Goodnight, Perl 6.Posted Feb 11, 2013 4:29 UTC (Mon) by rqosa (subscriber, #24136)In reply to: Should be: Goodnight, Perl 6. by bronson Parent article: Chromatic: Goodnight, Parrot When that book was published there was no implementation, at all. Now there's an approximately 88% feature-complete implementation. That's a big difference.
(Log in to post comments)
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 6:14 UTC (Mon) by bronson (subscriber, #4806) [Link]
It went from unusable to useless. Not such a big difference from where I sit.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 6:38 UTC (Mon) by rqosa (subscriber, #24136) [Link] If you can't explain why you think Rakudo is "useless", then posting comments like that is just needless hostility towards its developers.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 8:46 UTC (Mon) by alankila (subscriber, #47141) [Link]
As a 10 year old perl 5 programmer, the way I see it is that Perl 6 is the last dinosaur men buit. (I know, so very optimistic of me...) It is so incredibly complicated that I suspect that only very few would be capable of learning to use it in full, and discover the most suitable abstraction to use in each specific type of problem. Everybody else will make do with some random but unique subset of the language, so everybody's programs will look different. That is not a good thing, imho.
I'd argue it is unwelcome even if there was a 100% functioning implementation that did not show poor performance characteristics. As in, nobody should ever use it. Why? Because Perl6 design is so complicated that there is probably not much room for new features or taking the language in new directions. It's really the same problem as with Perl5: a lot of bloat and ill thought out features that can never be changed because backwards compatibility.
I think Perl6's idea was to make a core so flexible that it has no limitations, and that makes it almost textbook case of Second System Syndrome. I also suspect it's the primary reason why it has taken so long: designing fully generic schemes for doing everything are a lot more work than just designing something according to reasonable guess of what your average programmer might want or need. Usually these designs prove out to be less flexible than hoped, and that effort was all a colossal waste.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 19:30 UTC (Mon) by raiph (guest, #89283) [Link]
> It is so incredibly complicated that I suspect that only very few would be capable of learning to use it in full
The same could be said of Perl 5. A big difference is that it's less true of Perl 6.
Perl 6 is a simpler language than Perl 5 in most ways. But, like Perl 5, there is scope for a full range of fluencies from baby to advanced. If you don't like that, you don't like Perl.
> Perl6 design is so complicated that there is probably not much room for new features or taking the language in new directions.
Again, this is arguably true of Perl 5. It's definitely not of Perl 6.
> I think Perl6's idea was to make a core so flexible that it has no limitations
You didn't get that idea from the actual project.
> I also suspect it's the primary reason why it has taken so long.
The reasons for it taking so long are legion. It was and is ambitious, no doubt about it.
Should be: Goodnight, Perl 6. Posted Feb 12, 2013 2:03 UTC (Tue) by alankila (subscriber, #47141) [Link]
"Perl 6 is a simpler language than Perl 5 in most ways."
Well, maybe for someone who is in the zen. Perl5 certainly wasn't pretty, though I could live with it apart from its scalars using so much memory and the language generally being so slow.
I'll assume what you say is true, though on the surface it seems to have a lot more syntax to deal with that is new to Perl6.
"You didn't get that idea from the actual project."
It is hard to remember stuff clearly from a decade ago, but I got the impression from the apocalypses where I thought that the common theme was "this is something that was difficult in perl5, let's remove this limitation [through some very complicated scheme for no clear reason]", and I got sick of it all when I learnt about the runtime reconfigurable syntax parsing. In my mind, that is a sign of language design going off the deep end. I get it that semantics sometimes have to be redefined to support features like operator overloading (whatever the merits and faults of this technique), but syntax too? I really don't look forwards to seeing code that makes use of that feature.
Should be: Goodnight, Perl 6. Posted Feb 12, 2013 3:02 UTC (Tue) by cmccabe (guest, #60281) [Link]
> Perl5 certainly wasn't pretty, though I could live with it apart
> from its scalars using so much memory and the language generally > being so slow.
Let's be fair. Perl5 is still faster than a lot of the languages in common use: Python, Ruby, and Bash. (JRuby might be another story, but it's not widely used.)
My favorite new language is Golang. I've been using it in places where I formerly used Python (and before that... Perl) and it just... works so much better. It's really refreshing how quickly it starts up and runs, and the fact that it's compiled and type-checked. You don't have to live in terror of the next version silently breaking your code. And of course, there's a better concurrency story than just "run multiple VMs in parallel."
Should be: Goodnight, Perl 6. Posted Feb 12, 2013 9:21 UTC (Tue) by alankila (subscriber, #47141) [Link]
Of course Perl is not the slowest language there is, but its speed and memory consumption nevertheless proved prohibitive for my needs. In general the problem had most to do with using a scripting language at all. Most of all I needed the struct packing efficiency and execution speed of a precompiled language, and the ability to spend just 4 bytes for an int. Hash tables (extremely fat objects) and 40 byte scalars (even if it was a single integer value) as perl typically does just wouldn't scale.
Should be: Goodnight, Perl 6. Posted Feb 12, 2013 5:16 UTC (Tue) by raiph (guest, #89283) [Link]
> "Perl 6 is a simpler language than Perl 5 in most ways."
> Well, maybe for someone who is in the zen.
Consider the comparison of baby Perl 5 and baby Perl 6 (the card deck code of pages/slides 16 thru 29) in this presentation by Carl Mäsak: http://masak.org/carl/fosdem-2013-flying-car/talk.pdf
> I got sick of it all when I learnt about the runtime reconfigurable syntax parsing.
Oh dear. That stuff (all the way through slangs) is pretty core to Perl 6 and stars in many of its triumphs as a DSL for producing DSLs. If you don't like that you dislike one of its unique strengths. Not to worry, there are many more. :)
Should be: Goodnight, Perl 6. Posted Feb 12, 2013 9:32 UTC (Tue) by alankila (subscriber, #47141) [Link]
To me this perl5 vs 6 example you cite reads like someone came up with the syntax specifically to do those tasks. So there's a method that just happens to pick any number of array items? A lot of us would call those features bloat.
Cross operator such as "X~" which appears to mean something like 'combine two lists in every possible way with 2 implied for loop, then stringify every item, then return the list' sure is powerful, but I'm a boring stick-in-the-mud and do not really see that as much of an improvement over the two for loops. More to the point, assuming we really do want to get rid of explicit for loops, then why not compose the functionality out of functions from some Perl module?
Think of: cross(@a, @b) yielding some Pair objects of the two lists, rather than @a X @b. And rather than some weird operator like X~, perhaps there should be a stringify(cross(@a, @b)). I guess it's just not the Perl way, though, but I know which language I'd rather write.
Ditto for expressions like (1, 2, 3) >>+<< (3, 2, 1) yielding (4, 4, 4). This seems like rank madness to me. Python's NumPy would do the same with something like array((1,2,3)) + array((3,2,1)) yielding array(4, 4, 4). Why not use the existing library facilities and overloading capability to build this stuff?
Should be: Goodnight, Perl 6. Posted Feb 12, 2013 11:14 UTC (Tue) by niner (subscriber, #26151) [Link]
The nice thing about hyper operatiors is that they allow automatic parallelization and they work with all operators even ones you define yourself. The compiler simply has much better optimization possibilities this way. That the code becomes very compact is a nice side effect.
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 9:44 UTC (Wed) by k8to (subscriber, #15413) [Link]
But a generic method of applying functions to data can achieve the same thing while being syntactically regular and expressively clearer.
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 17:27 UTC (Wed) by raiph (guest, #89283) [Link]
> But a generic method of applying functions to data can achieve the same thing
Can it?
First, Perl 6 operators compile down to function application. Folk are free to write directly in the function application style. So at some level these appear to be equivalents.
But, aiui, there are at least three big impacts:
* you need syntax to control order of evaluation;
> while being syntactically regular and expressively clearer.
Most languages allow a + b as well as add(a,b) and I'd say most folk find the a + b option expressively clearer in most situations.
===================
To drill down in to the details of evaluation, consider the Perl 6 expression "@ X~ @b" which for our purposes I'll say means to create the array result of a crosswise combination of the elements of the array variables @a and @b, concatenating each pair.
Now consider how to express that in a function application style, in particular how the compiler, syntax and programmer deal with order of evaluation, parallelization, optimization, and laziness.
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 17:59 UTC (Wed) by andrel (subscriber, #5166) [Link]
Have there been psychology experiments proving that understanding the different syntax uses a different part of the brain, or is that still informed conjecture?
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 19:21 UTC (Wed) by raiph (guest, #89283) [Link]
> Have there been psychology experiments proving that understanding the different syntax uses a different part of the brain, or is that still informed conjecture?
Aiui there have been lots of brain scan experiments demonstrating that understanding spoken natural language uses different synaptic circuits to process different syntax elements. I hope to get some time to find more useful answers to your question this weekend and post back in this thread.
Use of our natural language processing neural mechanisms for reading, writing, understanding computer languages Posted Mar 7, 2013 21:27 UTC (Thu) by raiph (guest, #89283) [Link]
I've just hunted around starting from a google for "understanding syntax" "brain scans". I've not yet found stuff specifically discussing how natural language syntax processing neural mechanisms impact our processing of computer language, but here's one that A) confirms use of some such mechanism in processing of music notation and B) suggests that such mechanisms would/can also be used used in reading, writing, understanding computer languages.
"These combined results suggest that [an area of the brain], known to be crucial for syntax processing in [natural] language, plays also a functional role in the processing of musical syntax. Hence, the present findings are consistent with the notion that Broca's area supports the processing of syntax in a rather domain-general way." (from http://www.ncbi.nlm.nih.gov/pubmed/20570253)
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 19:01 UTC (Wed) by k8to (subscriber, #15413) [Link]
Claims 1 and 2 are false on their face, because (as you point out yourself) the execution is equivalent.
You don't typically need to control order of application of the function to the items, which is why it's fast. You do of course need to control order of function application, but with function syntax it's all the more clear.
Optimization meanwhile is the same, except for the most degenerate of examples such as "we hand-crafted the machine code of this operator for this one case".
But a typical implementation of combining two arrays in all permutations would be something like
permute(NIL, a, b)
so the compiler can see that there's no action required but to combine them, and it's a trivial matter to parallelize the combination across N cores or computers. Indeed there were functional compilers capable of fully optimizing this problem in the early 90s.
As for item 3 I will have to say that I doubt you are right, but I cannot claim either way since there is of course no evidence presented, and probably no research.
I do find infix to be pleasant for colloquial, familiar expressions. I find it to be personally extremely counterproductive for comprehension with unusual constructions.
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 20:26 UTC (Wed) by raiph (guest, #89283) [Link]
> Claims 1 and 2 are false on their face, because (as you point out yourself) the execution is equivalent.
Heh. It appears you didn't interpret the word "appear" as I intended...
> You do of course need to control order of function application, but with function syntax it's all the more clear.
So, is it concat(cross(@a,@b)) or cross(concat(@a,@b)), or something else, and what is the result?
> Optimization meanwhile is the same, except for the most degenerate of examples such as "we hand-crafted the machine code of this operator for this one case".
Are you suggesting it's degenerate to specifically atomically optimize a crosswise concatenate?
> As for [understanding a+b uses a different part of our brain than add(a,b)] I will have to say that I doubt you are right, but I cannot claim either way since there is of course no evidence presented, and probably no research.
I'd be surprised if there was no research but my own investigations have been of brain science as it relates to natural language, not computer languages. The "aiui" was partly because I've taken Larry's word (he was a linguist) that similar principles apply. I hope to dig in to this this weekend and post back here, with a focus on comparing add(a,b) and a + b.
> I do find infix to be pleasant for colloquial, familiar expressions.
I'm going to assume here you mean in computer languages. As in, you find a + b in computer code pleasant.
For me @a X @b ("array a crossed with array b") felt natural and pleasant as did @a X~ @b ("array a cross concatenated with array b").
> I find it to be personally extremely counterproductive for comprehension with unusual constructions.
So a+b works well instead of add(a,b) but a**b fails compared to power(a,b) (or something like that)?
Should be: Goodnight, Perl 6. Posted Feb 14, 2013 12:21 UTC (Thu) by fatrat (subscriber, #1518) [Link]
How does this differ from the Haskell (or Python version)
ghci> [ x+y | x <- [1,2,3], y <- [4,5,6] ]
which seems cleaner.
In Haskell, that can also deal with lazy lists etc
Should be: Goodnight, Perl 6. Posted Feb 14, 2013 17:41 UTC (Thu) by hummassa (subscriber, #307) [Link] Cleaner than
> 1, 2, 3 X+ 4, 5, 6 5 6 7 6 7 8 7 8 9? ok then.
Should be: Goodnight, Perl 6. Posted Feb 14, 2013 18:22 UTC (Thu) by raiph (guest, #89283) [Link]
> How does this differ from the Haskell (or Python version)
> ghci> [ x+y | x <- [1,2,3], y <- [4,5,6] ] > [5,6,7,6,7,8,7,8,9]
That's the same.
One issue is whether you prefer, from an expressivity point of view, x+y or something like add(x,y). I usually prefer x+y. It looks like, for the "familar" function/operator add/+, we all agree: x+y is generally preferable.
So what about "unfamiliar" functions/operators? I'm going to guess at the haskell syntax for a zipped string concat:
zipwith (++) ["foo", "bar"] ["sing", "song"].
Perl 6 uses ~ instead of ++ and supports infix notation so one can write:
["foo", "bar"] Z~ ["sing", "song"]
It seems alankila and k8to (and you?) consider the Z~ infix notation for zipped string concat to be less clear.
Let's assume for a moment that this is just a syntax sugar issue. (Regardless of whether the sugar seems sweet or not to any given writer/reader.) Given that Perl 6 is aiming at (among other things) being a metaDSL (a language for easily expressing and combining DSLs) then sugar matters and it's potentially important to make it trivial to use a wide range of expressivity, including infix notation, for user defined functions/operators (as well as builtins of course).
Should be: Goodnight, Perl 6. Posted Feb 14, 2013 19:34 UTC (Thu) by nybble41 (subscriber, #55106) [Link]
Haskell doesn't let you mix letters and symbols in operator names, but apart from that it's simple to define an operator similar to Z~ which works on any nested list type, including lists of strings ([[Char]]):
infixr 6 ++~
["foo", "bar"] ++~ ["sing", "song"]
Should be: Goodnight, Perl 6. Posted Feb 14, 2013 21:40 UTC (Thu) by fatrat (subscriber, #1518) [Link]
I think my issues is that the [ ... ] list/monad comprehension approach is very general, and, as nybble41 points out, can be specialised as needed.
The Perl6 approach seems to lead to a proliferation of operators, and consequent maintenance issues.
Should be: Goodnight, Perl 6. Posted Feb 12, 2013 13:29 UTC (Tue) by raiph (guest, #89283) [Link]
> To me this perl5 vs 6 example you cite reads like someone came up with the syntax specifically to do those tasks.
I routinely see both example and $dayjob code that reads as if the syntax and builtins were made just to make that bit of code nicer to write and read. But I've watched the relevant discussions so I can see this is the natural outcome of a good language design process rather than Larry Wall focusing on parlor tricks.
> So there's a method that just happens to pick any number of array items?
Yes. It picks randomly and does not repeat an element. Handy for selecting threads from a pool, for example.
> A lot of us would call those features bloat.
Imo it is suitably huffmanized and pushed as far out of the technical core as is reasonable. I see it as excellent design.
> Cross operator such as "X~" which appears to mean something like 'combine two lists in every possible way with 2 implied for loop, then stringify every item, then return the list' sure is powerful, but I'm a boring stick-in-the-mud and do not really see that as much of an improvement over the two for loops.
More or less. If an infix X is followed by another operator it applies the operator pairwise for every operand combination and returns the list of results.
But you can still write two for loops if that's what you prefer...
> More to the point, assuming we really do want to get rid of explicit for loops, then why not compose the functionality out of functions from some Perl module?
That's more or less how it already works. String concatenation (~) and many other operators (+, -, etc.) ship with the stock Perl 6 but you (or others) can add more (which will then automatically combine with the range of metaops).
> Think of: cross(@a, @b) yielding some Pair objects of the two lists, rather than @a X @b. And rather than some weird operator like X~, perhaps there should be a stringify(cross(@a, @b)). I guess it's just not the Perl way, though, but I know which language I'd rather write.
Folk can write code long hand if they want. You can write add(3, 4) instead of 3 + 4 if you want.
But key things get lost in the translation you suggest. The metaops like X parallelize. And what if @a and/or @b are lazy or infinite lists? And what about an optimization specific to crosswise string concatenation?
> Ditto for expressions like (1, 2, 3) >>+<< (3, 2, 1) yielding (4, 4, 4). This seems like rank madness to me. Python's NumPy would do the same with something like array((1,2,3)) + array((3,2,1)) yielding array(4, 4, 4). Why not use the existing library facilities and overloading capability to build this stuff?
How do you parameterize the operation of the + op? For example, how would you control the +'s handling of unequally shaped arrays? Hang on, let me go check this. ... Ah. With NumPy, "the size of the trailing axes for both arrays in an operation must either be the same size or one of them must be one" or an exception is raised. The Perl 6 syntax allows more refined control of what NumPy calls broadcasting.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 17:45 UTC (Mon) by bronson (subscriber, #4806) [Link]
Zero hostility toward developers at all. All new languages are useless when they first start out (for varying definitions of "first start out").
As for why, I tried switching some of my easier Perl5 scripts to Perl6 a few years ago, and they got a little shorter and a lot harder to read. I loved Perl5 -- it's hard not to like a project that puts you in the authors file for a few patches -- but Perl6 appears to be going in exactly the opposite direction than I would choose. That plus the perpetual vapor makes it awfully hard for me to find a use for it.
I'll close with the hopeful sentence at the end of my comment from 4 years ago: https://lwn.net/Articles/330101/ Though, I've tried Perl6 since then, and I'm less excited about it now.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 19:38 UTC (Mon) by raiph (guest, #89283) [Link]
> I'll close with the hopeful sentence at the end of my comment from 4 years ago: https://lwn.net/Articles/330101/ Though, I've tried Perl6 since then, and I'm less excited about it now.
When did you last try it and is there some reason other than it taking so long that is why you are less excited?
It's important to accept the real pace of development rather than what might be hoped. As I said, also 4 years ago, "as hard to stomach as it may be, the story remains, even though they've taken a decade to get this far, they may well take ... five [years] to get to Perl 6.0.0 and a generally robust status". I continue to follow Perl 6 and I think that estimate was a good one.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 11:31 UTC (Mon) by NAR (subscriber, #1313) [Link]
It is said that for any project the last 10% takes 90% of the time. Based on this metric Perl6 will be ready in the next century...
Should be: Goodnight, Perl 6. Posted Feb 12, 2013 5:21 UTC (Tue) by raiph (guest, #89283) [Link]
Or, as Carl Mäsak puts it, the Perl 6 project is currently on the third 80%.
|
|||||||||||||