Hacker News Reader

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

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

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

>> "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.

Or take #nethack. While it's "only" about the game, the channel stays focussed, nice and knowledgeable.

"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.

And given/when is already part of Perl5 http://perldoc.perl.org/perlsyn.html#Switch-statements

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.

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 (see RFC 022).

#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.

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

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.