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

161–170 of 227 posts

Re: Pretty.c

#161

Post by bityard »

aartaka wrote: post #82
nneonneo wrote: post #42

It claims to be a scripting language but you still have to compile the programs. Boo! Add CINT ( https://root.cern.ch/root/html534/guides/users-guide/CINT.ht... ) and you can have instantaneous execution and even a REPL!

Well, who said that scripting language cannot be compiled? And yeah, Clang-REPL is another way to make it REPL-friendly.

Sure, there is no "rule" against it. But words/phrases have commonly-accepted meanings and willfully ignoring or appropriating those meanings implies either cultural ignorance or a concealed agenda.

If you want to insist that scripting languages can be either compiled or interpreted, then its better to just drop it altogether and just say "language" because the "scripting" part has utterly lost its identity at that point.

Re: Pretty.c

#162

Post by jay-barronville »

This project looks really cool! Unfortunately, there’s just way too much magic involved. In my humble opinion, C is simply not the language for this level of magic—extreme use of macros (and hidden behavior in general) is how you end up with hard-to-detect (and hard-to-debug) bugs and security vulnerabilities. As cool as this project looks, I’d never feel comfortable using it in anything serious. A+ for the effort though!

Re: Pretty.c

#163

Post by ryandrake »

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…

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 language, I have no idea which one to use, and usually just pick one, try to compile, then if it fails, pick the other one. I'm sure there was a great reason to have two types for the same thing, that I will understand when I know the language better.

Re: Pretty.c

#164

Post by steveklabnik »

ryandrake wrote: post #163
AlotOfReading wrote: post #159

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…

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

Re: Pretty.c

#165

Post by AlotOfReading »

ryandrake wrote: post #163
AlotOfReading wrote: post #159

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…

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.

Unfortunately the bus had some electrical bugs and would intermittently flip random bits with no CRC to correct them. From my point of view, no big deal. If it's in something outside the fields I care about, I won't notice it. If it's flipped something I do care about we have a bad sample to drop or noise the signal processing will deal with. Either way, it's fine. Python on the other hand cared very much. I rewrote everything in C once I got sufficiently annoyed of dealing with it and more importantly explaining to others how they couldn't "simplify" things using the stdlib APIs.

Re: Pretty.c

#166

Post by Keyframe »

sneed_chucker wrote: post #141

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

This is not even half as bad as I expected it to be.

Re: Pretty.c

#167

Post by ryandrake »

steveklabnik wrote: post #164
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…

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-time C++ user, it seems like std::string vs const char* all over again, and we somehow didn't find a better way.

Re: Pretty.c

#168

Post by TheRealPomax »

dymk wrote: post #6

> turn any codebase into a beginner friendly one Okay then. I was hoping to see a “this is just for fun” disclaimer but didn’t see one. Please never actually use this in a project that other people will have to read or contribute to.

No promises, people who want to have fun are going to have fun despite requests not to have fun.

Re: Pretty.c

#169

Post by steveklabnik »

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

Yep, that’s exactly it: I wanted to focus purely on what to do, rather than weigh it down with what’s already in the Rust book.

It’s closer to std::string and std::string_view. But yes, in a language with value and reference semantics, when you also care about performance, you just can’t do any better: you need both types. Or at least, if you want the additional correctness guarantees and safety provided by communicating ownership semantics in the type. C gets away with just char * but then you have to read the docs to figure out what you’re allowed to do with it and what your responsibilities are.

Re: Pretty.c

#170

Post by psychoslave »

anthk wrote: post #118
pavlov wrote: post #108

Earlier quoted context omitted.

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…

On the long term, using the native keyboard hinders yourself a lot. I tried to do so with the Spanish (es) layout, it's pretty much unergonomical. It's looks like being deliberately designed for press/office usage and not for proper programming.

>it's pretty much unergonomical.

Well unless opting for something like Dvorak, you are indeed doomed to something that was specificcaly designed to please typewriter mechanical constraints without much care for the resulting ergonomics.

I use a Bépo layout personally, on a Typematrix 2030 most of the time, as French is my native language.

Post reply on HN