Live data from Hacker News

Pretty.c

github.com

201–210 of 227 posts

Re: Pretty.c

#201
post #75
post #27

Earlier quoted context omitted.

Now that's just silly. And I see the backwards keyword terminators (LOOP/POOL). I have wondered why we have case/esac, if/fi but while/done. I imagine the author himself figured that while/elihw would just be entirely ridiculous.

> I have wondered why we have case/esac, if/fi but while/done. With the reverse-keyword convention we'd get "od", not "elihw", though. while ... for ... do do ... ... od od The 'od' utility already existed, apparently, so Bourne opted for "done". [edit: typos]

No, there’s OD. DONE is different but no less perverse.

Re: Pretty.c

#202

Earlier quoted context omitted.

As someone who just got diagnosed with type-1 diabetes (the auto-immune variety, not the “you eat too much sugar” variety), this was far more depressing than funny. I’m probably being overly-sensitive, but man my life has gone to shit in the last couple of years…

Sorry to hear. Honest advice: I have heard fasting + healthy diet can permanently fix diabetes (though I forgot which type) Maybe try it? Good luck in any case!

There’s nothing wrong with my diet, that’s type-2. Type-1 is an auto-immune disease, and in my case was triggered by a couple of years of immense stress. Cortisol and the like wreak havoc over the long term. Mine isn’t curable, I don’t have many insulin-producing cells left in my pancreas.

All because two years ago, a hospital tried to make a little bit more money by turning beds faster, and fed sodium into my wife about 2x the recommended rate. Although awake, she has never recovered from the coma, and of course she has brain damage. It’s not like in the movies where you just wake up.

I’m not going into details, but when you scream yourself hoarse from the agony in your limbs, and there’s no painkiller that works, and eventually you lose your voice but you’re still screaming, silently… Yeah, that’s pretty terrible.

Neither of us will recover. I, at least, can manage it with insulin injections/pumps/CGM-patches… She is currently in a “mental health facility”, something she’s had happen to her several times this year. It looks pretty on the outside and resembles a prison once you step beyond the secured entry. It’s where hope goes to die.

All because a “hospital” wanted to make even more money than normal, and didn’t give a shit about their actual patients. Yes, I’m bitter.

I appreciate the sentiment behind your words, thank you for that. It won’t help, but still.

Re: Pretty.c

#203

Earlier quoted context omitted.

What do you consider the type of shell text, i.e. what's in argv and what you get from subprocess output? It's not well-formed utf8 strings because any random garbage can be in there, yet tools like awk and grep are ubiquitous. I'd argue that strings and bytes are the same general type, but it's sometimes useful to give well-formed utf8 bytes a different type internally. Rust gets this mostly correct with OsString an…

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…

String in rust is roughly like this in C:

  // NB: Must be utf-8!
  struct string {
    size_t sz;
    size_t capacity;
    unsigned char *buffer;
  };
&String in Rust is roughly like `const struct string *`.

str in Rust is just an array of (guaranteed utf-8) unsigned bytes. It does not have a capacity, so it can't be resized. You can't directly construct one (on the stack), because its size is undetermined and Rust doesn't have dynamic-sized stack allocation.

&str, and Box, are pointers to str, along with a size, and are roughly like this C:

  // NOTE: Must be utf-8!
  struct str_ptr
  {
    size_t sz;
    unsigned char *buffer;
  }
The difference between &str and Box is that the latter is an owned pointer to a heap allocation which will be freed when it goes out of scope. &str is unowned and might point anywhere: to a Box on the heap, to a String on the heap, or to read-only static memory.

IMO, it's probably easier to first try to understand the difference between `Vec`, `&[u8]`, and `&Vec`, because they are slightly less "weird" than the string types: they aren't syntactically special like `str` is[1], and they don't have an implicit requirement to be utf8 that is inexpressible in the type system.

[1]: `str` is syntactically special because it is basically a slice, but isn't written in slice notation.

Re: Pretty.c

#204
post #67

Well, there's a few things I should probably get around to adding to CNoEvil[0] and ogw[1]... There always seem to be more every few months when this project reappears. [0] https://git.sr.ht/~shakna/cnoevil3/ [1] https://git.sr.ht/~shakna/ogw

"It takes a whole lot of bad ideas and mashes them into an abhorrent monstrosity."

I love this to the very core of my being.

Re: Pretty.c

#205

Earlier quoted context omitted.

What do you consider the type of shell text, i.e. what's in argv and what you get from subprocess output? It's not well-formed utf8 strings because any random garbage can be in there, yet tools like awk and grep are ubiquitous. I'd argue that strings and bytes are the same general type, but it's sometimes useful to give well-formed utf8 bytes a different type internally. Rust gets this mostly correct with OsString an…

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…

String/str are both valid UTF-8 by definition, though. Plain ol' piles of bytes in Rust are generally represented by Vec/[u8].

Rust could have done better in naming, but a definite design goal of the language (for better and worse) is to not make things that are complicated for the compiler appear simple to the user. Which unfortunately results in:

    String/str
    CString/CStr
    OsString/OsStr
    Vec/[u8]
    AsRef
    Cow

Re: Pretty.c

#206

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-…

Rust has two different types because they are fundamentally different things, just like `std::string` and `const char *` are!

A pointer to some memory is not the same thing as a struct that has a pointer to memory, as well as a capacity field and the ability to resize itself.

Re: Pretty.c

#207
post #113

Earlier quoted context omitted.

Well, as a starter C is rarely considered as "strongly typed". Statically typed yes, but strongly typed not so much.

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.

C is strongly typed in some areas in that ISO C requires a diagnostic if you mistakenly use a struct foo * where a struct bar * is required.

It's weak in many areas, such as, oh, that you can implicitly convert an out-of-range floating point value to an integer type and get undefined behavior.

Linkage in C is not type safe. An extern int x declaration in one translation unit can be matched with an extern double x = 0.0 definition in another. Linkers for c typically accept that without a diagnotic: the program links.

Re: Pretty.c

#208
post #193
post #179

Earlier quoted context omitted.

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

C is from the 1970s. Java is weakly typed in its generics, despite being statically typed. I’m sure there are more examples.

[deleted]

Re: Pretty.c

#209

Creating DSLs within C has a long tradition. Stephen Bourne wanted to write his shell in ALGOL so badly that he relentlessly beat C with its own preprocessor until it began to resemble his preferred language. https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/sh...

excellent lore. said to have been the inspiration for the obfuscated C code contest.

https://www.ioccc.org/

Re: Pretty.c

#210
post #73
post #72

Earlier quoted context omitted.

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

How did you think people outside the US learn programming?

I'm from a non-English country. I only ever use layout of my locale when I write in my language. That's how it was ever since I was a kid who knew little English. And that's how all computers I've encountered in my country are set up - English first, local second.

In addition, our layout, overwrites only the numerics – all other symbols are the same as on a US layout.

Post reply on HN