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

Traps to Developers

qouteall.fun

Post reply on HN
Print view View original

61–70 of 113 posts

Re: Traps to Developers

#61

Post by dataflow »

PhilipRoman wrote: post #27
dataflow wrote: post #20

Earlier quoted context omitted.

What's the trap for this one? I can't think of any engine that parses this to mean anything other than the letters a through z.

In some common implementations if $LANG is set to certain values, it will fail to match some ASCII letters. This is because not all latin character using languages put Z last in the alphabet. Try this (you probably need to enable and generate the locale first) echo y | LANG=lv_LV.UTF-8 grep '[a-z]' Locales in general should be considered a "trap", just look at Windows CSV separator handling, etc.

That's wild. Thanks for explaining. I had no idea this depends on the locale. Looks like I have about a million scripts to fix...

Re: Traps to Developers

#62

Post by ozim »

skydhash wrote: post #4
andunie wrote: post #2

That's a nice compendium of tips and useful information. I wonder if anyone can learn from this. I feel like I only understood what I already knew, or at least was very close to knowing. That's the same thing that happens with teaching manuals about any topic: they're organized in a way that makes sense and it's easy for people who already know the topics, but often very bad at teaching the same topics to an audience…

> with teaching manuals about any topic: they're organized in a way that makes sense and it's easy for people who already know the topic I think that the reason for a manual existence. To have a written record so we don't have to trust our memory. This is what most unix manuals are. You already know what the software can do, you just need to remember the specificity on how to get something done. > often very bad at t…

Kind of what I noticed for myself.

When I was a kid I was trying to learn Linux and commands and it was disappointing.

Over the years of using it I don’t need to learn it but I do need to look stuff up.

Re: Traps to Developers

#63

Post by dataflow »

judofyr wrote: post #44
dataflow wrote: post #19

Earlier quoted context omitted.

Somewhat off topic, but what is a realistic example of where you need atomics with sequential consistency? Like, what useful data structure or pattern requires it? I feel like I've seen every other ordering except that one (and consume) in real world code.

A mutex would be the most trivial example. I don't believe that is possible to implement, in the general case, with only acquire-release. Sequential consistency mostly become relevant when you have more than two threads interacting with both reads and writes. However, if you only have single-consumer (i.e. only one thread reading) or single-producer (i.e. only one thread writing) then the acquire-release semantics en…

> A mutex would be the most trivial example. I don't believe that is possible to implement, in the general case, with only acquire-release.

Wait, what? So you're saying this spinlock is buggy? What's the bug?

https://en.cppreference.com/w/cpp/atomic/atomic_flag.html

Re: Traps to Developers

#64

Post by cyberax »

nayuki wrote: post #51

Largely a good listicle. Some feedback: > Unicode unification. Different characters in different language use the same code point. Different languages' font variants render the same code point differently. 語 This isn't a trap. The given example character means the same thing in Chinese and Japanese, and the Japanese version was imported from China. People from both languages recognize both font variants as the same c…

> The author is making it sound like the letter 'A' in English should have a different code point than an 'A' in French. Or that a lowercase 'a' with the top tail should be a different character than a lowercase 'a' without the top tail.

But we do have А and A. Even though they look the same. And unified Han characters are often quite distinct, it tripped me up as a learner of Chinese more than once. For example, a very common character '喝' (drink) looks quite a bit different: https://en.wiktionary.org/wiki/%E5%96%9D - they have a different number of strokes even. And I can't even copy-paste it here to demonstrate, because it changes form once I copy it from the Wikipedia article.

Han unification is a mess.

Re: Traps to Developers

#65

Post by gooodvibes »

> There are subtle differences between numpy and pytorch.

This isn't really a trap, and it doesn't help anyone; it looks like "I got burned but I don't want to share the specifics".

Re: Traps to Developers

#66

Post by busymom0 »

> Division is much slower than multiplication (unless using approximation). Dividing many numbers with one number can be optimized by firstly computing reciprocal then multiply by reciprocal.

Is this a general fact or specific to a language?

Re: Traps to Developers

#67

Post by whobre »

busymom0 wrote: post #66

> Division is much slower than multiplication (unless using approximation). Dividing many numbers with one number can be optimized by firstly computing reciprocal then multiply by reciprocal. Is this a general fact or specific to a language?

It's generally true even for CPU instructions: https://electronics.stackexchange.com/questions/280673/why-d...

Re: Traps to Developers

#68

Post by charcircuit »

singron wrote: post #50
Spivak wrote: post #43

Earlier quoted context omitted.

I question the wisdom of even having Optional in a language with nulls. It would raise some eyebrows if a function in Python returned an Optional type object rather than T | None. You have to do a check either way unless you're doing some cute monad-y stuff.

Maybe this is cute monady stuff, but there isn't an equivalent to Optional > with only null/None. You usually don't directly write that, but you might incidentally instantiate that type when composing generic code, or a container/function won't allow nulls.

In what context would you not want to treat Optional.of(null) and null as the same? It shouldn't be a big deal.

Re: Traps to Developers

#69

Post by bradfitz »

ivanjermakov wrote: post #33
bradfitz wrote: post #26

> Golang use UTF-8 for in-memory string. Nope. It’s just bytes with no encoding. https://go.dev/blog/strings

There is no such thing as "just bytes" when it comes to Unicode. UTF-8 is a way to represent Unicode codepoints in binary. But I agree that author's statement is wrong. Go stings are equivalent to byte slices.

Go strings are just bytes. There is no Unicode or encodings.
Post reply on HN