6 ms·
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 w
by 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 agoOr 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 agoAnd 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 agoThanks 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 agoLarry 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 agoWhile 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 agoYou 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 agoBut 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 agoWhile 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 agoI 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.