Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pretty.c

github.com

Post reply on HN
Print view View original

171–180 of 227 posts

Re: Pretty.c

#171

Post by samatman »

IgorPartola wrote: post #125

For what it’s worth this makes the same mistake that Python 2 did: string and bytes are not the same type and shouldn’t be treated as such.

I don't agree. This doctrine presumes all of the following:

  - String data will be properly encoded
  - There is one encoding of strings (UTF-8 usually)
  - Validation must occur when string data is created
  - Truncating a logical codepoint is never acceptable
  - You may not do string things to "invalid" bytes
  - Proper encoding is the beginning and the end of validation
None of these things are consistently true. It's a useful practice to wrap validated byte sequences in a type which can only be created by validation, and once you're doing that, `Utf8String` and `EmailAddress` are basically the same thing, there's no reason to privilege the encoding in the type system.

Re: Pretty.c

#172

Post by AlotOfReading »

ryandrake wrote: post #167
steveklabnik wrote: post #164

Earlier quoted context omitted.

I wrote a blog post that may help you! https://steveklabnik.com/writing/when-should-i-use-string-vs... If you want to understand more deeply, the Rust Programming Langauge, chapter 4, uses String and &String and &str to talk about ownership and borrowing. Here’s a link to the start of that chapter: https://doc.rust-lang.org/stable/book/ch04-00-understanding-...

How timely and helpful, thanks! Your blog post is practical and clearly explains what to do, when, which is helpful. What's confusing is why Rust has the two types and why the language designers decided it was a good idea to have to convert back and forth between them depending on whether it was going in a struct or being passed as an argument. I suppose the "why" is probably better found in the Rust docs. As a long-…

In C++ terms, String is std::string, &str is std::string_view. They're different things, but they can appear similar.

Re: Pretty.c

#173

Post by kvirani »

> Provide so much syntactic sugar as to cause any C developer a diabetes-induced heart attack.

Haha love this!

Re: Pretty.c

#174

Post by jffhn »

listeria wrote: post #154
jffhn wrote: post #123

Earlier quoted context omitted.

If both terms are infinites and of same sign, subtraction will give NaN and it will fail.

How is that a problem? infinities shouldn't be considered equal

For IEEE 754, and in Java for example, they are. Only NaN is not equal to itself (and different from itself).

Re: Pretty.c

#175

Post by cryptonector »

ulbu wrote: post #72
smatija wrote: post #65

Earlier quoted context omitted.

Just as example, on my slovenian QWERTZ layout: [ - altgr+f, ] - altgr+g, { - altgr+b, } - altgr+n, \ - altgr+q, | - altgr+w, ~ - altgr+1. You get used to them, though you start feeling like a pianist after a short coding session. The one most annoying for me are the fancy javascript/typescript quotes, which I have to use all too often: ` - altgr+7.

Today I learned that there exist people who use non-US layouts when coding. That’s spectacular!

Spectacular?? Terrifying. If I need to type non-ASCII Latin characters I'll just use compose sequences. The thought of a non-U.S. keyboard layout with modifiers required to type []{} and so on is terrifying.

Re: Pretty.c

#177

Post by syrrim »

lelanthran wrote: post #81
throwaway19972 wrote: post #58

Does "strong typing" now just mean "static typing"? Afaik both lua and python are already strongly typed. Javascript is not and I have no clue about ruby.

> Does "strong typing" now just mean "static typing"? The distinction strong and weak typing is irrelevant in practice. Weak (but present) static typing beats strong dynamic typing every single time, because what is valuable is NOT "Do I see a type mismatch error only when a user accesses it?" , it's "does this mismatch prevent a deployment?" IOW, the only distinction in production is dynamic typing vs static typing,…

recommend setting up tests for your code s/t failures block deployment. can catch categories of bugs beyond typing errors

Re: Pretty.c

#178

Post by brabel »

AlotOfReading wrote: post #172
ryandrake wrote: post #167

Earlier quoted context omitted.

How timely and helpful, thanks! Your blog post is practical and clearly explains what to do, when, which is helpful. What's confusing is why Rust has the two types and why the language designers decided it was a good idea to have to convert back and forth between them depending on whether it was going in a struct or being passed as an argument. I suppose the "why" is probably better found in the Rust docs. As a long-…

In C++ terms, String is std::string, &str is std::string_view. They're different things, but they can appear similar.

A Rust `String` reference (i.e. &String) can always be passed where `&str` is expected because `String` has a `Deref` impl... in that sense they don't just appear similar, they are polymorphic.

Re: Pretty.c

#179

Post by brabel »

byroot wrote: post #119
aartaka wrote: post #114

Earlier quoted context omitted.

With C23 (nullptr, auto typing, typeof) and C11 (generics) it got more guarantees and type-related primitives. You can still do void*, but you are strongly discouraged from it.

#include "pretty.h" void print_int(int value){ println(value); } int main (int argc, string argv[]) { long value = 23849234723748234; print_int(value); } How is this strongly typed? $ cc test.c -o test && ./test -1411401334 And to be clear, weak vs strong isn't a boolean property but a spectrum, but would be hard to argue with a straight face than C is a strongly typed language.

C is likely the only example of a programming language that is clearly statically typed while at the same time being weakly typed. For a reason: as your example shows, it's a really bad idea (but understandable for a language from the 60's).

Re: Pretty.c

#180

Post by ptspts »

AlotOfReading wrote: post #165
ryandrake wrote: post #163

Earlier quoted context omitted.

The way I understand it: Bytes are just bytes, until you provide an encoding. Then they can be can be converted to a string, if validly encoded. Taking an array of characters and just treating it or casting it as a string is usually a bad idea. The thing I think Rust maybe goofed, or at least made a little complicated, is their weird distinction between a String and a str (and a &str). As a newbie learning the langua…

There may not be a single encoding for every byte in a string. The encoding may not be knowable ahead of time. You might be trying to extract strings from a random blob of bytes with unknown origin. There's a thousand and one different variations. To give a real example, I once wrote some python scripts to parse serial messages coming off a bus. They'd read the messages, extract some values with regex, and move on. U…

Python stdlib conveniently supports both byte strings and Unicode strings, even for regexps. Ther is no need to migrate to any other language.
Post reply on HN