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

Yagni Exceptions (2021)

lukeplant.me.uk

Post reply on HN
Print view View original

81–90 of 214 posts

Re: Yagni Exceptions (2021)

#81

Post by samatman »

dagw wrote: post #56
EdwardDiego wrote: post #22

Earlier quoted context omitted.

Never write a function called destroyBaghdad(). Instead name it destroyCity and pass the target as a parameter.

If Baghdad is city your users destroy most often, I would allow a destroyBaghdad() function that calls destroyCity() with all parameters set correctly.

This is why the US destroyed Baghdad.

The contract is called CongressAuthorizesInvadingCountry(country :Country): Invasion

Congress made a thunk with Iraq in it, so despite the lack of any real connection to Recent Events, the White House called it in 2003.

Re: Yagni Exceptions (2021)

#82

Post by quickthrower2 »

never_inline wrote: post #70
hibbelig wrote: post #63

Earlier quoted context omitted.

Multiple tables are the way to go with SQL, you'll need multiple tables all over the place. So if multiple tables give you a “wrong” feeling, I argue that the feeling is wrong for the technology. It would be very normal to have tables as follows: * Table "users" with an "id" column and some additional data about the user. * Table "skills" with an "id" column and some additional data about the skill. * Table "user_ski…

I have also done this many times but I think GP has a point. This model needs more code, and a hassle when you're just trying to get something working.

Its a wetware thing. Use relational enough and this isn’t a hassle at all. Like static types are not a hassle if you are used to them. Or docker once used to it. Etc.

Re: Yagni Exceptions (2021)

#83

Post by matsemann »

sonthonax wrote: post #80
matsemann wrote: post #60

Earlier quoted context omitted.

You don't need to bake in a complete i18n solution, though. Just create a simple map of keys->strings, and then a function ala getStringForKey(key, language) { return map[key] and then whenever you actually need it, just expand on it. But at least you then have all strings in one place, and a common way of accessing them. (And easy lookup of all places using these strings)

Agreed. I don’t really know what problem these i18n tools solve that this doesn’t.

But if you end up in a situation where i18n tools are needed, this function can be the single entry point anyways, abstracting most of it away.

Re: Yagni Exceptions (2021)

#84

Post by valenterry »

goto11 wrote: post #72
valenterry wrote: post #68

Earlier quoted context omitted.

Exactly. Better imo: Don't use strings but a proper datastructure/wrapper. Later, if you want to add i18n, then change `Wrapper("Hello, welcome to the future")` into `Wrapper("Hello, welcome to the future", "welcome-user")` and just look for all wrappers to find all places. Benefits: it's easy to find the code with a simple ctrl+f from the English version of the site and you don't have any disadvantage except for hav…

This is still not YAGNI enough for me. Why introduce a wrapper you don't need? The thinking behind anti-YAGNI "future proofing" seem to be that it is cheaper to change something now than in the future. But I reject this premise. Inserting `Wrapper($string)` is exactly as much work now as in the future, but it will add additional overhead to all development going forward. Perhaps the wrapper is even less work to intro…

I don't think so. That's just a semantic description of what you are doing. Call it `UserMessage("....")` or whatever. If you go without that and have simply plaintext for any kind of thing, you might at some point mix up passwords with user messages and stuff like that. Has nothing to do with future-proofing.

You need user-messages? Then create user-messages and not strings. You don't need translations? Then don't create them.

Or in other words: make things a simple as you can but not simpler than they inherential are.

> Perhaps the wrapper is even less work to introduce in the future, since you can add it with a simple search-replace, instead of inserting it manually every time you type a string.

No you cannot, unless literally all strings in your program must be translated.

Re: Yagni Exceptions (2021)

#85

Post by grey_earthling »

samatman wrote: post #78

This is very nearly off topic, but "Ain't" is the correct conjugation to pair with "Gonna". This form comes from Britain and is preserved in some dialects of American English, but "Aren't Gonna" is a partial hypercorrection; if we want acrolect, we must go all the way to "Aren't Going To". "You gonna be at the thing this weekend?" "Nah man I aren't gonna" wrong For the Commonweath, to whom this is no longer part of t…

“You aren't gonna need it” is ordinary colloquial British English.

“I aren't…” is not.

Re: Yagni Exceptions (2021)

#86

Post by dri_ft »

samatman wrote: post #78

This is very nearly off topic, but "Ain't" is the correct conjugation to pair with "Gonna". This form comes from Britain and is preserved in some dialects of American English, but "Aren't Gonna" is a partial hypercorrection; if we want acrolect, we must go all the way to "Aren't Going To". "You gonna be at the thing this weekend?" "Nah man I aren't gonna" wrong For the Commonweath, to whom this is no longer part of t…

> "Nah man I aren't gonna" Well, yes, because the first person singular of to be is am, not are. It works fine with I am or you are.

> I'm not gonna do that > You aren't gonna need that 'You aren't gonna need it' looks weird because it deviates from the stock phrase YAGNI, but it's not wrong.

Re: Yagni Exceptions (2021)

#87

Post by iLoveOncall »

matsemann wrote: post #60
iLoveOncall wrote: post #52

Earlier quoted context omitted.

I haven't worked with a lot of i18n systems, but on the contrary I have found them to be a huge amount of work. I have used the Angular one and the Laravel one, and both are a chore to use, because they interrupt your flow. If I'm writing the view of my component, I don't want to have to switch to another file, think of a key that identifies that text well enough and then translate the text, thinking of potential plu…

You don't need to bake in a complete i18n solution, though. Just create a simple map of keys->strings, and then a function ala getStringForKey(key, language) { return map[key] and then whenever you actually need it, just expand on it. But at least you then have all strings in one place, and a common way of accessing them. (And easy lookup of all places using these strings)

Your function doesn't solve any of the issues I mentioned, you still need to switch to another file, still need to think of a sufficiently explicit key, still need to handle plurals and masculine / feminine variations, etc.

Re: Yagni Exceptions (2021)

#88

Post by zarzavat »

wruza wrote: post #57
motogpjimbo wrote: post #39

Earlier quoted context omitted.

This sounds like you're opening yourself up to situations where you have rows in data_journal that have status='Loading' but which have started_loading_at=NULL, in violation of your data model. Your premise is slightly flawed in that your second example isn't actually difficult to write or understand as you claim. However, it could be argued that if the logic for selecting "loading" rows is repeated in multiple place…

that have status='Loading' but which have started_loading_at=NULL, in violation of your data model Why not CHECK() it then? Or make ‘status’ GENERATED STORED or do a similar thing on triggers. The way that you suggested is also good, but it creates two names, one for update, another for select, which may confuse orms or developers.

The iron law of data is that there should be one source of truth.

It’s always better to enforce constraints statically (in this case by the schema) than dynamically at runtime. Because avoiding inconsistencies is the human’s job, the computer sure as hell won’t know what to do about it.

Re: Yagni Exceptions (2021)

#89

Post by marcus_holmes »

samatman wrote: post #78

This is very nearly off topic, but "Ain't" is the correct conjugation to pair with "Gonna". This form comes from Britain and is preserved in some dialects of American English, but "Aren't Gonna" is a partial hypercorrection; if we want acrolect, we must go all the way to "Aren't Going To". "You gonna be at the thing this weekend?" "Nah man I aren't gonna" wrong For the Commonweath, to whom this is no longer part of t…

> if we want acrolect, we must go all the way to "Aren't Going To".

but "gonna" is a contraction of "going to"

"I'm gonna go to the thing" is short for "I'm going to go to the thing".

> "Nah man I aren't gonna" but "Nah man, I'm not gonna go" is fine - the problem is not with "gonna" here, it's with "I aren't" (which as others have said, is incorrect, and should be "I am not" rather than "I are not").

I don't see a problem with "You Aren't Gonna Need It" or even "You Ain't Gonna Need It"

Re: Yagni Exceptions (2021)

#90

Post by marcosdumay »

never_inline wrote: post #70
hibbelig wrote: post #63

Earlier quoted context omitted.

Multiple tables are the way to go with SQL, you'll need multiple tables all over the place. So if multiple tables give you a “wrong” feeling, I argue that the feeling is wrong for the technology. It would be very normal to have tables as follows: * Table "users" with an "id" column and some additional data about the user. * Table "skills" with an "id" column and some additional data about the skill. * Table "user_ski…

I have also done this many times but I think GP has a point. This model needs more code, and a hassle when you're just trying to get something working.

> This model needs more code

That's not my conclusion at all. This model often requires less code. And less hard-coded data your application has to share around.

Post reply on HN