

How Perl 6 just sells itself (excerpt from IRC) - draegtun
http://use.perl.org/~masak/journal/39025

======
antirez
This is what happens when all the hype moved on the next language. What
remains is a kind, good community. But it's too late, a language also needs
momentum and hype.

~~~
evilneanderthal
I disagree with your statement. Momentum and hype are good for attracting
those who choose a language based on its momentum and hype. If you are
choosing a language to perform a task based on any objective criteria,
momentum and hype interfere with your ability to choose and are therefore
repulsive.

~~~
rjurney
You are quoting the standard perl attitude: languages are not cool/uncool,
they are only useful or un-useful. Meanwhile Perl is not 'cool,' most people
have moved on from Perl, Perl 6 will never ship, and Perl is dying.

Perl has a marketing problem, and the first step towards fixing it is to
accept that cool matters. There are very few young Perl programmers.

~~~
chromatic
How can you write "Perl 6 will never ship"? Rakudo has monthly stable
releases; last week they released their 17th stable release in a row.

(If you believe that a group of people who've demonstrated that they can make
and meet commitments over a long period of time will suddenly stop, how can
you believe that any group of people will ever release any software that takes
longer than a week or two to write?)

~~~
rjurney
Its been a long time in development, and is completely dependent on a stable
Parrot - something very few people use. Its been almost 10 years, I just don't
think it will ship 1.0. DNF.

I think Perl 5 will take the good parts, and use them, and that Perl 6 is a
pure R&D platform. Moose being a good example.

I would love to be wrong. But in the meanwhile I can't even work with other
people my age in the language of choice because none of them know Perl.

It sucks.

~~~
chromatic
People said we'd never release Parrot 1.0 either (people said that as recently
as November) -- but why speculate when you can measure?

We released Parrot 1.0 in March. We released Parrot 1.1 in April. We released
Parrot 1.2 in May. We'll release Parrot 2.0 in January 2010 and Parrot 3.0 in
January 2011.

Keep that in mind as you look at the daily Rakudo status reports. As of last
week, Rakudo passed 68% of the current spectests. The passing test velocity
has only increased this year.

~~~
rjurney
Calling it Parrot 1.0 doesn't mean its stable. You can call it 10.0, doesn't
mean people are gonna switch.

I'm not as well informed as you, but I'm just really skeptical about a 10 year
old project shipping 1.0. I'm pissed off that Perl has died in the meanwhile.
Something went terribly wrong and the language was mis-managed.

~~~
chromatic
What else would we call Parrot 1.0? We believe that Parrot 1.0 represents a
stable platform on which people can start to build compilers.

It's not a finished platform (which is why we continue to produce new
releases), but we have a documented and well-understood deprecation policy.

We'll add new features, but we believe that the current set of features in
Parrot 1.0 is sufficient to build a workable language.

(As for the question of "Is Perl dead?", the rate of uploads to the CPAN
certainly disagrees. That's a measurable data point. I won't address the
question of Perl 5's release policy and backwards compatibility concerns here;
I've discussed them at length elsewhere.)

~~~
rjurney
Why didn't Perl 6 just use the JVM? Why did you decide to build Parrot?

As to CPAN uploads: Nobody I know under 30 in Atlanta knows Perl. I'm not
exaggerating. Thats the important data point to me.

~~~
chromatic
That's a very silly data point for several reasons.

First, the age of 30 is arbitrary, unless there's some reason that only the
experiences of people under 30 matters. Perhaps everyone over 30 stops coding,
or dies, or fails to create anything interesting -- but you haven't
demonstrated that.

Second, the choice of Atlanta is arbitrary. Is Atlanta a sufficient
statistical representative of all of the locations of programmers in the
world?

Third, your choice of "people I know" is arbitrary. Can you demonstrate that
you know a representative sample of available programmers in the Atlanta area?
(What happens if you expand the definition of "programmers" to include "people
who occasionally write a program"?)

Fourth, your experience doesn't compare. An anecdote is not a piece of data.

The rate of change on the CPAN is not the sole determinant of Perl's
viability, but there is a single, well-understood place to share reusable code
with other Perl programmers. It's measurable data, and it's normative for
certain types of Perl usage.

What you provided isn't data. It's just noise.

~~~
rjurney
[http://www.tiobe.com/index.php/content/paperinfo/tpci/index....](http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html)

What about that noise? This is pretty typical Perl thinking: pretend
everything is ok, nothing to see here. Lots of CPAN commits, we have one
metric to cling to. Everything is ok.

~~~
chromatic
TIOBE's flaws are well-documented throughout the Internet (look out Ruby --
Delphi, RPG, and Logo are hot on your heels!). In particular, no third party
has ever been able to duplicate their results, whereas anyone with access to
any of the hundreds of CPAN mirrors can verify those numbers.

------
dkarl
When I clicked the link, I fully expected to see a scary line-noise-y Perl
script implementing a chatbot that persuades people to upgrade to Perl 6 :-)

------
petercooper
_< sjohnson> wow it's like ruby_

Isn't it..

~~~
jrockway
Ruby is based on Perl, so it follows that Perl would be like Ruby.

~~~
petercooper
The traits referred to in this log are primarily things that Perl has
inherited from Ruby, rather than things Ruby took from Perl in the first place
(which, to be fair, was rather little).

------
stcredzero
If many languages/libraries have SortedCollection, or a collection which is
always a sorted sequence, why not have something like a "TrimmedString?" It'll
be a string that's always in the trimmed state. That would eliminate lots of
"trim()" calls.

~~~
DougBTX
Presumably it would require magic to handle

    
    
       foo + " " + bar

~~~
stcredzero
If foo contains an instance TrimmedString, why can't it just return itself
after the first + operation?

If you send a TrimmedString to a String, then all bets are off. This would
make the use case: if you start with a TrimmedString, you always have a
TrimmedString. (Barring operations that are deliberate conversions.)

~~~
shrughes
Because if foo contains "f" and bar contains "b", then your scheme would have
(foo + " " + bar) contain "fb" and not "f b"

~~~
stcredzero
Then the fool should use a regular String! RTFM!

------
trezor
This actually shows a _useful_ IRC channel for once. Some nitpicks about the
Perl 6 features mentioned though:

    
    
       <jnthn> bytes($string) # how many bytes
    

This would ofcourse be 100% dependent on what kind of character-encoding you
use so I checked some reference material:
([http://search.cpan.org/~moritz/Perl6-Str-0.0.3/lib/Perl6/Str...](http://search.cpan.org/~moritz/Perl6-Str-0.0.3/lib/Perl6/Str.pm))

    
    
        $s->bytes returns the number of bytes of the NFKC-normalized
        and UTF-8 encoded $s. This is subject to change.
    

While UTF-8 is a good _default_ encoding, it seems odd to tie standard
functions into things which cannot be presumed. Without having the ability to
specify encoding, you will have one function for UTF-8 and a different one
(roll your own?) for every other encoding out there.

This, together with "This is subject to change", strikes me as slightly
inconsistent and unreliable function.

    
    
       <sjohnson> will Perl 6 contain a switch / case structure?
       <japhb> sjohnson: given/when.
    

I honestly don't see how in a C-style language, using different names for the
exact same construct found in every other C-style language adds any real
value.

Apart from that, Perl 6 seems to be moving forward. I still think it looks
kinda lacking compared to languages I like to use, but like mentioned in the
IRC excerpt, language debates tends to get kinda pointless ;)

~~~
jrockway
_While UTF-8 is a good default encoding, it seems odd to tie standard
functions into things which cannot be presumed. Without having the ability to
specify encoding, you will have one function for UTF-8 and a different one
(roll your own?) for every other encoding out there._

This is an interesting trend that I've noticed in programmers recently -- they
want everything to be a parameter to a function they've found. Instead of:

    
    
        (bytes (encode-to-charset string "some-charset"))
    

they want:

    
    
       (bytes string :in-charset "some-charset")
    

Why bloat the interface and implementation of "bytes" like this? Pick a
reasonable charset by default; let users write code that does what they want
in the (rare) corner-cases.

(I blame this on auto-completing IDEs. Once you've guessed the name of a
function with the help of your IDE, you expect it to do everything you want...
reading about parameters to the function is easy... but finding another
function is hard. Therefore, bloated interfaces are in demand.)

~~~
trezor
You missed my point entirely. Text in memory should be unicode and not
encoded, as nothing else would really make sense. In that case bytes() refers
to the _size_ of string when _rendered_ in a _specific_ encoding. You are not
getting the "size" of the _actual_ string.

See my other comment: <http://news.ycombinator.com/item?id=628031>

~~~
jrockway
But you have to remember, even though there are millions of encodings and
character sets, UTF-8 Unicode makes up 99.99% of real-world use-cases. So it
makes sense to make that 99.99% easy.

(I will admit that I'm confused as to why you would need to know the length of
a string's representation in a certain encoding unless you are writing a
network protocol.)

