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

Software development topics I've changed my mind on

chriskiehl.com

Post reply on HN
Print view View original

701–710 of 788 posts

Re: Software development topics I've changed my mind on

#701

Post by scotty79 »

VyseofArcadia wrote: post #161
ZaoLahma wrote: post #82

> Most programming should be done long before a single line of code is written Nah. I (16+ years developer) prefer to iteratively go between coding and designing. It happens way too often that when you're coding, you stumble across something that makes you go "oh f me, that would NEVER work", which forces you to approach a problem entirely differently. Quite often you also have eureka moments with better solutions th…

Iterative work is THE way to work in large legacy codebases. The minute you wade into the code, all of your planning is moot. You don't know what's lurking below the surface. No one knows what's lurking under the surface. Except maybe Dave, because he vaguely remembers about 15 years back talking to some guy who wrote some code 30 years back about it. Greenfield, absolutely design up front you lucky devils, but itera…

> Greenfield, absolutely design up front you lucky devils, but iterative is the way otherwise.

That only works for greenfield projects where you have extensive experience with everything that is going to be used on that project. For all others you still learn as you go and all plans and designs need to be revalidated and updated multiple times.

Re: Software development topics I've changed my mind on

#702

Post by Izkata »

globular-toast wrote: post #696
Izkata wrote: post #608

Earlier quoted context omitted.

I've seen and poked at a lot of the ORM-hating on here, and whenever I can get people to give specific examples instead of generic theory-level stuff, it's either not a problem in Django or Django has a fix you just need to learn about and use. The fixes have sometimes even been there for over a decade. It seems be leaps and bounds ahead of every other ORM out there.

The main problem is if you are not very careful it leaks its internals (ie. the relational model) into everything it touches. That's what the N+1 query problem is. Business logic shouldn't have to know that certain attributes will cause database queries. By carefully writing managers and having a rule to never use querysets anywhere else you can avoid it, but it requires everyone to understand this and all the Django…

The default test runner creates the test database automatically yes, but you can create Django model objects without touching the database, just use the class like a constructor and don't save it: Person(name="Foo", age=30)

Re: Software development topics I've changed my mind on

#703

Post by ghc »

s1mplicissimus wrote: post #471
ghc wrote: post #214

Earlier quoted context omitted.

To reduce your argument to its essence, you're saying typesetting is part of the craft of writing. I've yet to meet an author who believes this (other than enjoying editing their own work as output from a typewriter), and I think the same broadly applies to code. It's not that everyone thinks these things are unimportant, it's that caring deeply about doing them a particular way is orthogonal to the craft. It's somet…

The prose writing metaphor also falls apart the moment one admits that prose doesn't have the need (and is actually very terrible at) working collaboratively, concurrently but not perfectly synchronized and continuously on the same body of text, ensuring at the same time that combined changes don't add up to unwanted/wrong semantics, even in the long term. Are consistent indentations, variable names etc. strictly req…

Plenty of writers work collaboratively, fyi. Even fiction authors like my mother routinely deal with multiple drafts and edits from multiple editors who review and suggest changes, from peer authors to professional editors contracted by the publishing house. And non-fiction authors routinely collaborate, too. I personally know some consequential non-fiction books where another author ghost wrote troublesome sections, not taking credit except in private.

And this ignores the collaborative writing many authors do to pay the bills: technical writing at large corporations, like bank manuals and such, or academic writing at universities. While consistency and standards are enforced, nobody's arguing that everyone else should really indent paragraphs their way, because that's the best way.

Re: Software development topics I've changed my mind on

#704

Post by naasking »

Shorel wrote: post #660
naasking wrote: post #215

Earlier quoted context omitted.

> ORMs are the devil in all languages and all implementations. Just write the damn SQL I'm re-evaluating this again. I used to be all-in on ORMs, eventually became annoyed with the shortcomings and the performance problems, but am realizing the disadvantages of foregoing them as well. * ORMs Bad: ORMs often lead to deep object graphs and tight coupling if you don't know what you're doing / don't factor the model prop…

> enforce invariants in a holistic way This sentence is golden, it advances the bullshit bingo score better than the rest. But honestly, in SQL the invariants should be constraints and triggers, enforced by the DB, not just by the application layer.

Constraints and triggers are more limited than the kinds of invariants you can enforce in code.

Re: Software development topics I've changed my mind on

#705

Post by eloisant »

latexr wrote: post #22

> Most won't care about the craft. Cherish the ones that do, meet the rest where they are > (…) > People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things. What you call “stressing over minutiae” others might call “caring for the craft”. Revered artisans are precisely the ones who care for the details. “Stressing” is your value judgement, not neces…

Now we have tooling to make sure (1) code style is consistent and (2) you don't have to stress about it.

Every language has automatic formatters. Use them, configure them if you don't like the default (in accordance with your team), and configure your editor so that is applied automatically when you save. And use CI to detect PRs with bad formatting so devs who don't have configured their editor yet can't break it.

Same with linters, you still have to agree with your co-workers about which rules make sense to be enforced, but with good editor integration you can see it right away and fix it as you code.

Re: Software development topics I've changed my mind on

#706

Post by tialaramex »

stickfigure wrote: post #580
rovolo wrote: post #567

Earlier quoted context omitted.

I agree that the time unit should be in the variable name. The code itself should do a good job of explaining "what" is happening, but you generally need comments to explain "why" this code exists. Why is the test advancing the time, and why are we advancing the time at this line of the test? networkTimeMs++; // Callback occurs after timeout timeSec++; // Advance time to check whether dependent properties update utcT…

> I agree that the time unit should be in the variable name Also a terrible solution! The code suffers from primitive obsession. Unless you're in a code section that is known to have performance issues, use real types. time = time.plusMilliseconds(1);

In a performance language your "real types" aren't somehow more expensive and so you should only use the built-in primitives when they accurately reflect your intent. So I would write:

time += Duration::from_millis(1);

But I would expect that "time unit should be in the variable name" is a reasonable choice in a language which doesn't have this affordance, and I needn't care about performance because apparently the language doesn't either.

I also wonder why we've named this variable "time". Maybe we're a very abstract piece of software and so we know nothing more specific? I would prefer to name it e.g. "timeout" or "flight" or "exam_finishes" if we know why we care about this.

Re: Software development topics I've changed my mind on

#707

Post by tialaramex »

vunderba wrote: post #453
smallerfish wrote: post #349

Earlier quoted context omitted.

Is it ms? seconds? days? weeks? months? How far up do I have to read to figure that out? When I'm looking at a test case is broken, I ideally want context IN the actual test that lets me understand what the test author was thinking when they wrote it. Why does this test exist as it does? Why are the expectations that are in place valid? Write the comments for you-in-2-years.

Pedantic but a comment clarifying the unit of measurement belongs with the declaration of the variable , not an increment statement.

The problem, in this case, is that the correct size of the increment involves the unit of measurement. If we change the unit of measurement and go update your comment on the declaration of the variable, now everywhere which uses the variable is wrong.

    int time; // in seconds
    /* thousands of lines away or in another file */
    time += 1;
Later we change the time to be in milliseconds. We update the comment on the declaration, but now that code is wrong and we have no reason to know that.

That's a bad choice, languages should do better (and some do - where they do, use the better features and this problem vanishes) but when it's forced upon us it makes sense to either put the unit in the name of the variable or ensure comments about changes to the variable explain the units consistently, even though that's lots of work. This extra work was dumped on you by the language.

Re: Software development topics I've changed my mind on

#708

Post by tome »

valcron1000 wrote: post #530
lmm wrote: post #175

Earlier quoted context omitted.

That's why you need not just an Either/Result type, but proper monads so that you can use the same functions with both.

As someone who worked with Haskell and Rust in production this is a nightmare: - All functions end up returnig `Either/Result` - Stack traces are gone - Exceptions and panics can still creep so it's not even "safer" - There is no composability of different result types, you need something like `Either which is not supported in most languages (I think Scala 3 and Ocaml have this feature), or you create a "general wrap…

Effect systems such as Bluefin (my own) and effectful allow you to have multiple possible exception effects in scope without having to cram them all into one type (with some sort of "variant" or "open sum" type). It's a very pleasant way to work!

Re: Software development topics I've changed my mind on

#709

Post by bena »

latexr wrote: post #22

> Most won't care about the craft. Cherish the ones that do, meet the rest where they are > (…) > People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things. What you call “stressing over minutiae” others might call “caring for the craft”. Revered artisans are precisely the ones who care for the details. “Stressing” is your value judgement, not neces…

Whether one uses tabs or spaces, Allman or K&R, etc. is largely immaterial.

On your own projects, choose a style, go with it. On someone else's project, go with the style chosen. On a shared project, come up with a style, go with it.

Code _organization_ matters way more than code _style_. Where style refers only to the aesthetic choices that don't impact the structure or flow.

Re: Software development topics I've changed my mind on

#710

Post by jugg1es »

torginus wrote: post #566
imjonse wrote: post #56

> ORMs are the devil in all languages and all implementations. Just write the damn SQL It depends on what you're writing. I've seen enough projects writing raw SQL because of aversion to ORMs being bogged down in reinventing a lot of what ORMs offer. Like with other choices it is too often a premature optimization (for perf or DX) and a sign of prioritizing a sense of craftsmanship at the expense of the deliverables…

I'm a hardliner on supporting this - I'd go further - all the DB code should be in SQL, with the database being manipulated by stored procedures and the db schema not even being exposed to the common developer. As far as I know this is a very oldschool view on how to treat dbs, but I still think this is the only correct one. I hate ORMs with a passion - they're just a potential source of bugs and performance issues,…

You must live a charmed life if you haven't run into major problems with stored procedures.
Post reply on HN