|
in reply to Re: What's wrong with Perl 6?
in thread What's wrong with Perl 6?
Gee, if the name is the main thing that's wrong with it, maybe I can just ignore all the other problems. :-)
Seriously, what makes Perl Perl? If someone decides I'm ugly and beats my face to a pulp, and later I get a face transplant, am I still me? If my bones rot and are replaced with synthetics, at what point am I a different person? Syntax is just skin. Semantics are just bones. Neither is the soul of Perl, which rests in the realm of pragmatics.
Maybe it would help if you thought of Perl 6 as something more like Perl 16 or so. We're just trying to skip over the 20 years of deprecation cycles and dead ends it would take to evolve Perl 5 into Perl 16 piecemeal, even assuming that were culturally possible, which it really isn't. Plus I'm too Impatient to wait that long.
I've also seen what happens to other languages that change their name. They basically lose their branding, and have to start all over. I'm too Lazy to do all that work again. Plus there's a longstanding cultural assumption that major version numbers indicate incompatible changes, despite the recent trend for marketeers to pretend that great strides have been made when they haven't.
Another factor is that four letter words are in short supply, and we shouldn't use them up so quick, especially for things we really want to use four-letter words on. :-)
But overriding anything else is the fact that I think I have a moral claim on the name, and I want Perl 6 to be considered a better Perl than Perl 5. Call it Hubris if you like... |
Re^3: What's wrong with Perl 6?
by naikonta (Curate) on May 11, 2007 at 08:41 UTC
|
what makes Perl Perl?
In no particular order:
- Perl is context-based, or context-sensitive, or it decides what to do on code depending on in what context I expect my code to be treated (well, in the set of contexts Perl understands)
- Perl allows me to code in the *first way* that comes to mind to solve a problem, yet allows me later to improve the solution in *another way*.
- Perl makes it easy for me to visually distinguish variable types and interpolate them in string. This is one of things that made me fell in love in my early Perl days.
- Perl allows me to have as many namespaces as I like (or need) and arrange them in a nested fashion. I can have them in one file, or in their own files. (I just can't stand to say CGI_Application_Plugin_Authentication_Driver_DBI).
- Memory management. Well, this one was actually less relevant for me until I know (by literature) the pain in manually allocating and deallocating memory. So my praise to those who implement Perl in C but can stand the pain :-) (They can, can't they?)
- Garbage collection, see also note about MM. I don't care whether it's implemented with reference counting or mark & sweep, or other techniques, as long as Perl provides GC.
- CPAN, enough said :-)
- Unimitable Regular expression
- Optional parentheses, semicolons, and commas as long as they're not required
- I love one-liners
- Optional return in subs (TheDamian advices againsts it (PBP 9.11), though.)
- POD!
- Free-form syntax structure
- Short-circuit in logical operators
(I don't know how to name this) EXPR if STATEMENT and other statement modifiers friends (Updated per blazar below)
- Closure, anyone?
- Arbitrary (bare or named) block usage
- Nested scoping
(Well, I can go on but that's what I can think of now. I could add TimToady's onion speaks but I'm afraid it's too much personal)
If Perl 6 preserves those characteristics, there's no reason to say Perl 6 is not Perl despite the change on the syntax. For example, I don't mind to write @array[1] instead of $array[1]. It's still Perl. And of course I can't mind to write:
given ($some) {
when 'body' { 'has to fight' }
when 'thing' { 'has to give' }
when 'day' { 'they will know the truth }
when 'where' { 'in a very near place to their mind' }
when 'time' { 'can only tell' }
default { 'yes, there is always a space for default' }
}
In the mean time, the only thing I can do now is stay with Perl (5) until the day when we do have that better Perl than Perl 5. In the future, we won't call it Perl 6 anymore, just Perl.
Update: now that I remember more, I added number 13 onward.
Open source softwares? Share and enjoy. Make profit from them if you can. Yet, share and enjoy!
| [reply]
[d/l]
[select] |
|
|
Perl allows me to code in the *first way* that comes to mind to solve a problem, yet allows me later to improve the solution in *another way*.
Completely agreeing and pointing out so to underline the nice way into which you put this concept, which is often implicit!
Perl makes it easy for me to visually distinguish variable types and interpolate them in string. This is one of things that made me fell in love in my early Perl days.
Hehe, you will certainly fall in love with the twigils for even better visual distinction and the new finely-tunable interpolating rules, although I bet :qq will do the job 99.9% of the time.
Perl allows me to have as many namespaces as I like (or need) and arrange them in a nested fashion. I can have them in one file, or in their own files. (I just can't stand to say CGI_Application_Plugin_Authentication_Driver_DBI).
I'm not really sure if I understand what you mean. You are aware that in Perl 5 Foo::Bar::Baz bears no relationship to Foo::Bar, arent' you? What do you mean with "nested"?
Unimitable Regular expression
Oh, inimitable but not unimprovable. Indeed Rules smell like they will be impressive. More power and more clarity at the same time!
Optional parentheses, semicolons, and commas as long as they're not required
Agreed to the highest degree for parentheses. I even find myself doing stuff like (func $arg) rather than func($arg) in expressions in which I can't avoid them. That's just me, of course. Half hearted about commas, which is often at the end of a multiline list. Not really agreeing on semicolons, except in subs like
sub foo { Very::Simple::code @_ }
(I don't know how to name this) EXPR if STATEMENT and friends
"Statement modifiers."
Closure, anyone?
Stay tuned with 6 for more FP-like fun. Personally I'm quite fond of the [ ] meta-operator.
Nested scoping
Do you really see that as particularly perlish? I'm currently a Perl-only kinda guy, but I would rather qualify it as quality typical of most modern enough programming languages that are serious about themselves...
| [reply]
[d/l]
[select] |
|
|
Completely agreeing and pointing out so to underline the nice way into which you put this concept, which is often implicit!
Actually, I merely rephrased that. I can't recall whom I cite it from and the exact word per word.
I'm not really sure if I understand what you mean. You are aware that in Perl 5 Foo::Bar::Baz bears no relationship to Foo::Bar, arent' you? What do you mean with "nested"?
Yes I am aware. That's just what I exactly meant by "nested", I can have Foo::Bar and Foo::Bar::Baz instead of Foo_Bar and Foo_Bar_Baz (no nested here). I didn't indicate anything between 'nested package name' and 'package relationship'. It's clear that Foo_Bar or Foo_Bar_Baz or CGI_Application_Plugin_Authentication_Driver_DBI are all under the same namespace, while Bar is under Foo and Baz is under Foo::Bar. But I do take advantage that I can arrange some classes/packages stucture within a suite of modules.
Oh, inimitable but not unimprovable. Indeed Rules smell like they will be impressive. More power and more clarity at the same time!
Thanks for the correction :-) That was not a typo, it was a mispell.
"Statement modifiers."
Thank you, it's indeed in perlsyn.
Do you really see that as particularly perlish? I'm currently a Perl-only kinda guy, but I would rather qualify it as quality typical of most modern enough programming languages that are serious about themselves...
At least based on my limited knowledge about other languages. I consider it as Perl's strength in providing high-granular variable scoping: file, package, block, inner-block, inner-inner-block, etc.
Open source softwares? Share and enjoy. Make profit from them if you can. Yet, share and enjoy!
| [reply]
[d/l]
[select] |
|
|
|
|
Re^3: What's wrong with Perl 6?
by Arunbear (Prior) on May 11, 2007 at 20:56 UTC
|
We're just trying to skip over the 20 years of deprecation cycles and dead ends it would take to evolve Perl 5 into Perl 16 piecemeal ...
Pardon me if you've answered this before, but what exactly about Perl 6 would give it such longevity?
| [reply] |
|
|
He didn't say it would last 20 years, he said it skipped 20 years of slow advance in favor of breaking backwards compatibility in one switch stroke, err well not switch, but you get the idea. Although 20 years of advance might look better than 7 of waiting.
| [reply] |
|
|
Surely the concept(*), which is to implement a glue between human languages and
computer language (=machine code), i.e. providing solid bridges between the two realms,
incoporating linguistics. That's what perl is for me, all the sigil and operator
renaming and bracket, dot and whitespace whirlpool is just like the readjustment of an
artist's palette after the blue period.
Adapting the latest findings of CS to Perl (or vice versa) to the above outlined is a
task which earns anyone undertaking it my deepest admiration (could anybody help me out
to express that in proper english? darn.)
(*) to my understanding, which might be far from accurate
--shmem
_($_=" "x(1<<5)."?\n".q·/)Oo. G°\ /
/\_¯/(q /
---------------------------- \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
| [reply] |
Linguistic determinism is the idea that language shapes thought.
by princepawn (Parson) on Oct 12, 2007 at 19:41 UTC
|
Syntax is just skin
Linguistic determinism is the idea that language shapes thought. As a hobbyist in the J programming language I disagree that syntax is just skin... sure they could all compile down into the same parse tree, but, but... ummm.. well, I still disagree :)
Carter's compass: I know I'm on the right track when by deleting something, I'm adding functionality
| [reply] |
|
|
Well, I don't know about you, but I value my skin highly, and prefer it not to have warts. Nevertheless, I don't confuse my skin with my soul.
By the way, linguistic determinism is not just about syntax. If it is to be a limiting factor, it must be about a language as a whole, including phonology, morphology, semantics, pragmatics, lexicon, and if you're exceptionally lucky, a culture. As someone who liked to play football when I was younger, I can vouch for the fact that I did a lot of non-linguistic thinking when running down the field deciding how to fake out the pass coverage. I certainly don't believe in the strong Whorf-Sapir hypothesis. And as to whether J proves or disproves your point, much of that language is ultimately derived from mathematics, and even in that realm the algebraicists will disagree with the geometers over how much linguistics has to do with mathematical thought.
But what really has me curious is why you quote Carter's Compass in your signature but refuse to let me apply it to Perl 5. :-)
| [reply] |
|
|
Should not we talk of the Djikstra hypothesis for computer environments instead of Sapir-Whorf?
The tools we use have a profound (and devious!) influence on our thinking habits, and, therefore, on our thinking abilities.
in this paper.
What I like about Perl is that it takes malleability of
the natural language without aping its surface syntaxe.
Unlike Fortran and Cobol who are not malleable enough
and take from natural language only a few words used as
keywords.
Perl 6 is getting rid of the Perl 5 ossification to give
a new meaning to malleability. Think Perl 6 macros for
example. Introspection is proper to human thought, it should
be the rules in programming languages.
So the second Djikstra hypothesis, is wrong when you
take it for its spirit :
Projects promoting programming in "natural language" are intrinsically doomed to fail.
Speaking of syntax, the second language to impress me for
its concision is Haskell, that I discovered thru pugs. Like Larry Wall did for Perl, the conceptors
of haskell did put a lot of thought to get it right. It seens that most
language designers don't think much about language syntax
or for pedagogical reason stick to the convention of
mainstream languages.
In the late eighties, Gosling, when designing NeWS, an innovating window system at the time,
picked the postfixed syntax of PostScript with the clean semantic
of the PostScript imaging system, dooming NeWS from the start. PostScript is intended to be generated by programs, not
by programmers.
Later, by mostly picking the C syntax, Gosling found a public for Java but, in my opinion, made it uninteresting from the start even
if the idea of portability thru a virtual machine was brillant even if, in the long term, it did not panned out as well as expected. But this is due to refusing to make the
language open source in due time, causing incompatible implementations and
libraries.
| [reply] |
|
|
