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

131–140 of 227 posts

Re: Pretty.c

#131

Post by dagw »

oezi wrote: post #80
smatija wrote: post #76

Earlier quoted context omitted.

I tried switching to US a few times, but every time muscle memory made me give up soonish - especially since there are big benefits to using same keyboard layout as other people in your office are using. Also practically everytime I need to write a comment, commit message or email I need my č, š and ž. It's kinda nice to have them only a single keypress away.

My hack: use caps key to switch to local keyboard layout while holding it.

Love it! I use ctrl+space to switch, but your idea sounds even better

Re: Pretty.c

#132

Post by [deleted] »

smatija wrote: post #76
ulbu wrote: post #72

Earlier quoted context omitted.

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

I tried switching to US a few times, but every time muscle memory made me give up soonish - especially since there are big benefits to using same keyboard layout as other people in your office are using. Also practically everytime I need to write a comment, commit message or email I need my č, š and ž. It's kinda nice to have them only a single keypress away.

[deleted]

Re: Pretty.c

#133

Post by hmry »

aartaka wrote: post #95
hmry wrote: post #56

Earlier quoted context omitted.

This code is incorrect, but I don't blame them. :) Probably one of the most common float-related mistakes, even among people who "know how floats work". FLT_EPSILON is the difference between 1.0 and the next larger float. It's impossible for numbers less than -2.0 or greater than 2.0 to have a difference of FLT_EPSILON, they're spaced too far apart. You really want the acceptable error margin to be relative to the si…

Indeed, FLT_EPSILON is not a one-size-fits-all solution, but it's good enough for frequent case of comparing big enough numbers, which is not covered by regular ==. So it's a convenience/correctness trade-off I'm ready to make.

If the numbers you are comparing are greater than 2, abs(a - b) < FLT_EPSILON is equivalent to a == b. Because it's not possible for two large numbers to not be equal, but also closer together than FLT_EPSILON.

Re: Pretty.c

#135

Post by pavlov »

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.

I’ve been writing C and its progeny (C++, JavaScript, Rust etc.) since 1990 on a Finnish keyboard.

The AltGr brackets are fine. The truly annoying character to type is the backtick (which is a quite new addition to the pantheon of special characters, C doesn’t use it).

My personal opinion is that Niklaus Wirth had the better overall ideas about clarity and inclusiveness in programming language design, but that battle is long lost. (What you consider the character set needed for "proper programming" is really a relatively new development, mid-1990s and later.)

Re: Pretty.c

#136

Post by knome »

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.

generally they aren't, as scripting usually implies an interpreter, though no one is stopping you from using a wrapping script that quietly compiles on first run and caches a bunch of executables somewhere. not much different than python producing bytecode files as it goes along.

Re: Pretty.c

#138

Post by aartaka »

pipeline_peak wrote: post #137

For each looks convoluted, you shouldn’t have to list the type. It should be no harder than C#’s foreach(var i in list)

Indeed, I might need to revisit foreach with type inference. Should be totally possible.

Re: Pretty.c

#139

Post by School-Cotton »

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 is your definition of "string"?

If it's "human-readable text", then fine, a string is not the same thing as an arbitrary byte array.

But lots of languages don't enforce that definition.

Re: Pretty.c

#140

Post by michaelsbradley »

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

Post reply on HN