Live data from Hacker News

A curated list of falsehoods programmers believe

github.com

91–100 of 128 posts

Re: A curated list of falsehoods programmers believe

#91
post #16
post #5

"Falsehoods programmers believe about life and people outside California."

"You don't need bitcoin because you can just wire money from one account to another" "Okay, you don't need bitcoin if you are not sending your money to imaginary places like Iran and N'Korea" "Okay, you don't need bitcoin in Europe or US unless one party in your transaction has surname that starts with Ass and ends with ange" "What do you mean by saying that banks abroad could refuse to open you account if you are US…

You do realize that it's still illegal to do all these things with Bitcoin, right? It's not that banks can't do these things; they just have no interest performing illegal activities on your behalf. Bitcoin solves nothing here.

Re: A curated list of falsehoods programmers believe

#92

Unfortunately - especially when dealing with non-technical ideas - some of these "falsehoods" veer into opinion territory. It's an interesting resource but perhaps the title of it is a little egoistic/presumptuous in that regard.

You just inspired an idea from me regarding HN comments. I think Slashdot still has one of the most elegant commenting systems around, even if the quality of the comments (due to the site's ownership) is worse.

I would love to tag HN comments with certain attributes and be able to filter them out. For example, this comment and the parent could be tagged "meta-discussion". Then those who want to discuss the content of the article could filter them out quickly.

/. tags are pretty accurate - "funny" "informative" "insightful" "trolling" - though trolling is a delete-level offense here.

Likewise, metamoderation (peer review, or moderation of tagging) was a brilliant idea.

Re: A curated list of falsehoods programmers believe

#93
This is kinda depressing reading for the start of the workweek. Also, I wish each of these was more expanded.. I can think of many workarounds for each of these situations but I am curious what other people's solutions might be: http://www.creativedeletion.com/2015/01/28/falsehoods-progra...

Re: A curated list of falsehoods programmers believe

#94

Unfortunately - especially when dealing with non-technical ideas - some of these "falsehoods" veer into opinion territory. It's an interesting resource but perhaps the title of it is a little egoistic/presumptuous in that regard.

You just inspired an idea from me regarding HN comments. I think Slashdot still has one of the most elegant commenting systems around, even if the quality of the comments (due to the site's ownership) is worse. I would love to tag HN comments with certain attributes and be able to filter them out. For example, this comment and the parent could be tagged "meta-discussion". Then those who want to discuss the content of…

I'm getting the feeling I'm not being complimented here but I've upvoted anyway.

Re: A curated list of falsehoods programmers believe

#95

> My system will never have to deal with names from China I work in a small French town where Chinese people were quite rare until a few years ago. Their passports have a translation of their names in Latin alphabet, same for Russians. However one day one of my user told me "hey I can't find some customers in your app, but I'm 100% sure I recorded them previously. Funnily they're all Chinese". It turns out that to av…

This happens with western names as well. Jo, Bo, Malcolm X.

https://en.wikipedia.org/wiki/David_X._Cohen#Name_change

Re: A curated list of falsehoods programmers believe

#96
I read through the entire list of falsehoods about addresses and I think I've got a few more broken assumtpions that weren't listed:

* A property will have an address

(I live in a very rural area of CA where the roads have forked several times for many miles to get to a property and they are all unnamed private roads. People often just put down the APN and the nearest town (which might be several miles away) as their address. I deal with this one all the time. I routinely have to find their house for the first time. Good luck using GPS here, if you can't read a map, you're S.O.L. [And no, even trying to confirm that you are where you think you are with GPS on your phone is gonna be a challenge. For one, you're miles from cell reception so if you didn't save the map to your phone, you're screwed. For two, under heavy tree and cloud cover, you may not even get a GPS fix on a phone.])

* A recipient needs a name and address

My mother lived for a time in a very rural area nearby. She rode a BMW motorcycle and someone she met only briefly once successfully sent her a letter by simply drawing a BMW symbol as the name and address and affixing the nearest town.

* A person has a street address

Homeless and rural people regularly fail this one.

Re: A curated list of falsehoods programmers believe

#97
post #46
post #3

There are things more important than working software.

Yes it's better to do something, anything, than to do something useful or correct.

We have to keep asking ourselves what is good enough because "perfect" is a rabbit hole.

Unless, of course, you are writing software that is life or death situation.. which I suspect most of us do not.

Re: A curated list of falsehoods programmers believe

#98

idk > The term "domain-specific language" has meaning. It means "is a computer language specialized to a particular application domain". The fact that it is hard to draw the line between DSL and general purpouse, that DSLs grow too large, ... does not invalidate the meaning of the concept. Or: > It is meaningful to talk about the speed of a programming language. It is? When I have to perform a given computation withi…

Well, Haskell (say) can never be as fast as C++, because of immutability. That means that it has to make a new place to store the new value, which means an allocation. That's not dependent on implementation.

(Except, I suppose, you theoretically could implement C++ so that it also allocated every variable. Still, I think the point is valid: Haskell, by its nature, has to do things that C++ doesn't, so Haskell is going to have a very hard time being as fast as C++.)

Re: A curated list of falsehoods programmers believe

#99
post #4

After reading the Falsehoods Programmers Believe About Names, I wonder, what would you recommend as a universal way to store users's names? There seems to be two main options: Store the name in a single field, be correct but lose the option to sort the names reliably. Store the name in two fields, have the users bend over our western form standards but be able to search and sort easily. Do you have any real life expe…

Serious question, what is the purpose of sorting names? I presume you never give your customers a list of other customers, so such a sort couldn't be useful to them. Is it for internal reports or something? Some MBA says "get me a list of all our customers... and make sure it's sorted!" ? And is some arbitrary imperfect sorting order not adequate for this sorting need? Why not just treat the name field as a bunch of…

One stupid example off the top of my head:

A teacher that needs a list of all the students scheduled to be in their 5:00 class.

There's literally millions of similar examples. Software where none of the users know about the other users would be fairly rare in my world (I've worked on internal business tools most of my career).

Re: A curated list of falsehoods programmers believe

#100

idk > The term "domain-specific language" has meaning. It means "is a computer language specialized to a particular application domain". The fact that it is hard to draw the line between DSL and general purpouse, that DSLs grow too large, ... does not invalidate the meaning of the concept. Or: > It is meaningful to talk about the speed of a programming language. It is? When I have to perform a given computation withi…

Well, Haskell (say) can never be as fast as C++, because of immutability. That means that it has to make a new place to store the new value, which means an allocation. That's not dependent on implementation. (Except, I suppose, you theoretically could implement C++ so that it also allocated every variable. Still, I think the point is valid: Haskell, by its nature, has to do things that C++ doesn't, so Haskell is goin…

Immutability doesn't mean no one can implement a Haskell extension that allows safely describing and composing operations that use mutability on the inside.

Of course on current hardware with current compiler Haskell programs tend to be slower, and also tend to be more correct compared to C/C++ (maybe even compared to let's say C++20).

Post reply on HN