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

211–220 of 227 posts

Re: Pretty.c

#211

Post by ulbu »

pavlov wrote: post #108
anthk wrote: post #94

Earlier quoted context omitted.

setxkbmap us -option ctrl:swapcaps -option compose:rwin Problem solved. US layout, and with the right Window keys you can compose European characters.

There’s so many assumptions here about a person who’s starting to learn programming. For starters, that they’re on Linux, they feel comfortable running complex CLI commands, they can memorize the U.S. layout just like that, and that they can type without looking at the physical keys (because changing the virtual mapping means keys produce something else than what the label says). In reality, the learner’s first expos…

Installation of Windows and MacOS defaults to US + local layouts.

Re: Pretty.c

#212

Post by jdthedisciple »

spacedcowboy wrote: post #202
jdthedisciple wrote: post #185

Earlier quoted context omitted.

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

That sounds rough man.

I don't know what to say except to wish you and your wife utmost strength.

Only thing I personally find solace in is that I am certain there is a life after this one in which everything will be amended by the One God Himself.

Re: Pretty.c

#213

Post by randomdata »

knome wrote: post #183
randomdata wrote: post #152

Earlier quoted context omitted.

Script usually implies some kind of task that runs once and the exits. As opposed to a system that is expected to run indefinitely. There are good reasons for why scripts are often interpreted and why systems are often compiled, but that's not what defines them. There are definitely scripts that are compiled and systems that are interpreted out in the wild.

'scripting' is an ill-defined term with many interpretations, certainly.

If that is the case, pick another interpretation and describe to us what "non-scripting" then might be.

Re: Pretty.c

#214

Post by mydriasis »

geon wrote: post #22
mydriasis wrote: post #2

Wow, neat! The wildest part to me is > And it’s backwards-compatible with C and all of its libraries! I can't wait to give it a shot! This looks like a riot.

Have you heard of Zig?

I hadn't yet, but it does look nice. I especially like that you can just say "defer deinit", that's really nice.

Re: Pretty.c

#215

Post by IgorPartola »

AlotOfReading wrote: post #159
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.

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…

What you see on the screen of a terminal is Unicode strings. It is human readable text. len(“”) is 3 even if the underlying encoding holds it as 6 bytes.

Of course if you provide a separate set of functions for treating a string as human readable vs not you can also work with that. Basically len() vs byte_len().

But you can’t concat two human readable strings without ensuring they are of the same encoding. You can’t search a string by bytes if your needle is of a different encoding. You can’t sort without taking encoding and locale preferences into account, etc.

Pretending like you don’t care about encoding doesn’t work as we have seen time and again.

Re: Pretty.c

#216

Post by IgorPartola »

michaelsbradley wrote: post #140
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.

Given the nature of it (pretty.c) and the stated intention of being "backwards-compatible with C and all of its libraries", what would make more sense than sticking with C's multibyte strings? https://en.cppreference.com/w/c/string/multibyte

Right but pretty.c doesn’t seem to explicitly support those.

Re: Pretty.c

#217

Post by IgorPartola »

samatman wrote: post #171
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 use…

I mean other languages make it work.

Re: Pretty.c

#218

Post by michaelsbradley »

IgorPartola wrote: post #216
michaelsbradley wrote: post #140

Earlier quoted context omitted.

Given the nature of it (pretty.c) and the stated intention of being "backwards-compatible with C and all of its libraries", what would make more sense than sticking with C's multibyte strings? https://en.cppreference.com/w/c/string/multibyte

Right but pretty.c doesn’t seem to explicitly support those.

How so? it’s just char*

Re: Pretty.c

#219

Post by brabel »

layer8 wrote: post #193
brabel wrote: 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.

I don't think Java is weakly type even in generics. You can't "fake" your way with types like in C, you need to explicitly cast, which fails if you try to make an invalid type cast.

Re: Pretty.c

#220

Post by smithza »

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.

The more pedantic compiler flags you introduce, the more strongly typed it becomes.
Post reply on HN