Phoenix.pm: quoting constant hash keys survey

[Scott Walters]

> Thanks for asking around, though!
> -- Mike

I really like how this went over. I might collect and summerize phoenix-pm-list
comments for perl6-language in the future.

Right now, comments on perl6-language are generally of a technical nature,
and people tend not to speak up and say "I don't like that" because it would
be out of place. Even when they do, they must be very politically sensitive -
everyone has sacred cows, and if you want to keep your voice you must maintain
the disposition of tolerence, respect, and professional apathy. 

In other words, it could use an injection of reality.

Larry Wall is brilliant and insightful on language design, and he comes
up with some great stuff, no one else is really tackling the hard problem
of language design - they're contributing new suggestions and technical input,
but that isn't the same thing. 

Case in point, "Perl 6 should be named something else" is a common observation
*off* perl6-language but appears very rarely there and is quickly dismissed
when it does appear.

I find %foo<<bar>> ugly and think %foo{bar} should retain it's current meaning
so that %foo<<bar>> isn't needed, but failing that, I like the idea of some
sort of %foo`bar syntax. I find typing a lot of { }, ( ), [ ], etc tedious
and I think constant hash keys are used often enough that it should benefit
from Huffman coding (common things should be short sequences). I think this
is a rare case where a feature is used often enough that shortening it to
something obscenely short actually does more good than harm. But this is
opinion =)

Cleaning up the language so it would be all of easier to learn, easier
to extend, and easier to evolve were the primary goals, but scope creep
has set in, and there is a general feeling that Perl 6 will become
obsolete before it is ever finished. The whole thing reminds me of the DEC
Alpha - the chip was designed to have a 20 year (or some large number, I 
forget) life span. It was to be built future proof, designed to keep up with
better fabrication technologies, increases in cache performance and RAM
speed, and faster clock cycles. It was a good design, certainly, the future
didn't agree. x86 continued to expand. Microsoft abandoned NT on 
MIPS, Alpha, and PowerPC. Peope became concerned with power consumption.
Laptops continued to become more popular. Low end hardware was used as
servers rather than high end RISC - everyone but IBM is floundering in the
high end RISC server space. Even when people spend a lot on a server, they
either want to run Windows or want hardware they're familiar with or they
want to take advantage of x86 being Linux's primary and best supported
platform. Or they know the horrors of OpenFirmware ;)

Perl 6 won't be too little too late but it might be the wrong thing too
late. 

I think Python and Ruby are doing really well right now because they're
scrappy. Python runs on the JVM if you want it to. Ruby constantly
compares itself to other languages and tries to do better in all arenas -
readability, expressiveness, scalability, and so on. It seems to 
me like Perl has kind of decided they're big so they can do whatever they
want and lost this scrappiness. But I tend to be a cynic =)

Microsoft's C# is an interesting case - Microsoft has single handled kept
BASIC alive decades longer than it would have lasted otherwise. Recently,
Micorosoft has started getting scrappy again, faced with the threats of
Open Source and Free Software. C# is a good little language. It isn't
as expressive as I like, but all in all, it is a good response to what
really want rather than ramming something down their throats.

Hrm, sorry, this turned into something of a rant.

> * You know, the things that make all languages 'readable' by anyone 
> with a solid programming background -- things in quotes are strings, 
> parens mark functions, == vs. =, etc. Perl goes quite far in stretching 
> that pardigm, as it probably should, given its background as an ad hoc 
> scripting language, but so far it's still very readable to C, Java, or 
> even VB programmers. And I thought Perl 6 was supposed to become *more* 
> "standard" in syntax, with using . for method calls instead of ->, but 
> maybe that's gone by the wayside now.

Too many meanings for symbols make it hard to learn a language. { } subscripts
hashes, constructs anonymous hashes, groups statements, and creates closures
in Perl 6 ('sub' is optional in most cases). Every indication is that this
problem is getting far worse in Perl 6 rather than better. Not only aren't
symbols familiar, they aren't (apparently) consistent. I think . is the extend
of the resolution to make Perl 6 more standard. 

I don't mean to bash Perl 6 - it's doing a lot of really cool things - but
I'm bound to have opinions ;)

-scott


> 
> 
On  0, Michael Friedman <friedman at highwire.stanford.edu> wrote:
> 
> Scott,
> 
> Not knowing anything about the other uses of ` and << >> except for 
> what's passed through the list lately, I'd vote against using backtick 
> in this instance. For one thing, it'll throw my editor's syntax 
> coloring off, because it assumes that you'll always have a matched 
> pair. :-)
> 
> In general, though, I'm with the group that says "there's nothing wrong 
> with being verbose". I'd rather have a clear %foo{bar()} and 
> %foo{'bar'} which fit my existing ideas of programming syntax* than 
> something involving single quote marks.
> 
> But, TMTOWTDI, and since I'll never use the single backtick in any 
> related context, it really doesn't matter for my personal coding.
> 
> Thanks for asking around, though!
> -- Mike
> 
> * You know, the things that make all languages 'readable' by anyone 
> with a solid programming background -- things in quotes are strings, 
> parens mark functions, == vs. =, etc. Perl goes quite far in stretching 
> that pardigm, as it probably should, given its background as an ad hoc 
> scripting language, but so far it's still very readable to C, Java, or 
> even VB programmers. And I thought Perl 6 was supposed to become *more* 
> "standard" in syntax, with using . for method calls instead of ->, but 
> maybe that's gone by the wayside now.
> 
>