7 ms·

How Perl 6 just sells itself (excerpt from IRC)

75 points by draegtun 17y ago

trezor 17y ago
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.pm http://search.cpan.org/~moritz/Perl6-Str-0.0.3/lib/Perl6/Str...) $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 ;)
- axod 17y ago
  >> "This actually shows a useful IRC channel for once." You'd be surprised. The log isn't uncommon, especially on freenode, where you often end up being able to chat to really knowledgeable people who have built very cool stuff.
  - eru 17y ago
    Or take #nethack. While it's "only" about the game, the channel stays focussed, nice and knowledgeable.
- edmccaffrey 17y ago
  #Haskell is another room that is useful. There is constant deep, on-topic discussion between experienced users who will also go out of their way to help newbies, without rockstar cliques who are too important to allow that in their channel.
- philwelch 17y ago
  "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." Did you notice the next line? "<japhb> sjohnson: and it's quite powerful." That implies it's more than just switch/case. If it's not quite the same thing as switch/case, then it's appropriate to give it a different name, even if it fills the same functional role.
  - draegtun 17y ago
    And given/when is already part of Perl5 http://perldoc.perl.org/perlsyn.html#Switch-statements http://perldoc.perl.org/perlsyn.html#Switch-statements
    - trezor 17y ago
      Thanks for the reference. I quickly skimmed it, and as far as I can tell the only thing it offers compared to a traditional switch/case statement, is the evaluation of expressions, as opposed to just accepting constants. I can see the rationale behind using a different name for the construct, but I still think it would have made more sense to stick to switch/case.
      - draegtun 17y ago
        Larry Wall also changed it to given/when partly for linguistic reasons. See here for his full explanation: http://dev.perl.org/perl6/doc/design/apo/A04.html http://dev.perl.org/perl6/doc/design/apo/A04.html (see RFC 022).
- jrockway 17y ago
  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 17y ago
    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 http://news.ycombinator.com/item?id=628031
    - jrockway 17y ago
      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.)
- jpd 17y ago
  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. Uhm... read the both these lines, not just one of them like you did before: <jnthn> chars($string) # characters <jnthn> bytes($string) # how many bytes
  - trezor 17y ago
    I guess you should reread my comment. I'm fully aware of that you can get chars with chars(), but that's not what I'm pointing out. If you are going to have a function for the size a "rendered" unicode string and there are 200+ ways to render it, it seems odd to tie a function to one and only of those ways, giving you one function for one encoding, and another one for all the other ones.
antirez 17y ago
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 17y ago
  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 17y ago
    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 17y ago
      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 17y ago
        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.
stcredzero 17y ago
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 17y ago
  Presumably it would require magic to handle foo + " " + bar
  - stcredzero 17y ago
    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 17y ago
      Because if foo contains "f" and bar contains "b", then your scheme would have (foo + " " + bar) contain "fb" and not "f b"
      - stcredzero 17y ago
        Then the fool should use a regular String! RTFM!
  - jongraehl 17y ago
    no problem - types for left-trimmed, right-trimmed, and both-trimmed ;)
petercooper 17y ago
<sjohnson> wow it's like ruby Isn't it..
- jrockway 17y ago
  Ruby is based on Perl, so it follows that Perl would be like Ruby.
  - petercooper 17y ago
    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).
dkarl 17y ago
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 :-)

75 points by draegtun 17y ago

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.pm http://search.cpan.org/~moritz/Perl6-Str-0.0.3/lib/Perl6/Str...) $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 ;)

axod 17y ago
>> "This actually shows a useful IRC channel for once." You'd be surprised. The log isn't uncommon, especially on freenode, where you often end up being able to chat to really knowledgeable people who have built very cool stuff.
- eru 17y ago
  Or take #nethack. While it's "only" about the game, the channel stays focussed, nice and knowledgeable.
edmccaffrey 17y ago
#Haskell is another room that is useful. There is constant deep, on-topic discussion between experienced users who will also go out of their way to help newbies, without rockstar cliques who are too important to allow that in their channel.
philwelch 17y ago
"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." Did you notice the next line? "<japhb> sjohnson: and it's quite powerful." That implies it's more than just switch/case. If it's not quite the same thing as switch/case, then it's appropriate to give it a different name, even if it fills the same functional role.
- draegtun 17y ago
  And given/when is already part of Perl5 http://perldoc.perl.org/perlsyn.html#Switch-statements http://perldoc.perl.org/perlsyn.html#Switch-statements
  - trezor 17y ago
    Thanks for the reference. I quickly skimmed it, and as far as I can tell the only thing it offers compared to a traditional switch/case statement, is the evaluation of expressions, as opposed to just accepting constants. I can see the rationale behind using a different name for the construct, but I still think it would have made more sense to stick to switch/case.
    - draegtun 17y ago
      Larry Wall also changed it to given/when partly for linguistic reasons. See here for his full explanation: http://dev.perl.org/perl6/doc/design/apo/A04.html http://dev.perl.org/perl6/doc/design/apo/A04.html (see RFC 022).
jrockway 17y ago
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 17y ago
  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 http://news.ycombinator.com/item?id=628031
  - jrockway 17y ago
    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.)
jpd 17y ago
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. Uhm... read the both these lines, not just one of them like you did before: <jnthn> chars($string) # characters <jnthn> bytes($string) # how many bytes
- trezor 17y ago
  I guess you should reread my comment. I'm fully aware of that you can get chars with chars(), but that's not what I'm pointing out. If you are going to have a function for the size a "rendered" unicode string and there are 200+ ways to render it, it seems odd to tie a function to one and only of those ways, giving you one function for one encoding, and another one for all the other ones.

antirez 17y ago

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 17y ago
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 17y ago
  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 17y ago
    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 17y ago
      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.

stcredzero 17y ago

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 17y ago
Presumably it would require magic to handle foo + " " + bar
- stcredzero 17y ago
  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 17y ago
    Because if foo contains "f" and bar contains "b", then your scheme would have (foo + " " + bar) contain "fb" and not "f b"
    - stcredzero 17y ago
      Then the fool should use a regular String! RTFM!
- jongraehl 17y ago
  no problem - types for left-trimmed, right-trimmed, and both-trimmed ;)

petercooper 17y ago

<sjohnson> wow it's like ruby Isn't it..

jrockway 17y ago
Ruby is based on Perl, so it follows that Perl would be like Ruby.
- petercooper 17y ago
  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).

dkarl 17y ago

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 :-)