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

321–330 of 788 posts

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

#321

Post by knighthack »

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…

'Programming as theory-building' is an approach that has grown on me in the past few years.

Your first draft may be qualitatively an MVP, but it's still just a theory of a final product you want, which requires a lot of iterative building before you get to that.

As such, there's no way to not shift between code and design, especially when business requirements are involved and which themselves may change over time.

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

#322

Post by baq »

catlifeonmars wrote: post #283
baq wrote: post #273

Earlier quoted context omitted.

What's specific in checked exceptions is that if you don't handle or silently ignore the new exception, you must change the signature. Then your callers must do the same thing. Then their callers etc. sometimes right down to your public static void main.

Yep, don’t change the function signature of depended on code. That’s the problem :) It would be equally problematic to change the method name, or the argument arity or types (ignoring overloading for the moment). It would be even more problematic if I kept the same function signature, but changed the meaning of the parameters. Then your breakage is silent.

yes exactly, hence unchecked exceptions are the sane option.

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

#323

Post by bluGill »

jkrejcha wrote: post #60
karatinversion wrote: post #48

Earlier quoted context omitted.

There's also the fact that common methods threw exception types that were not final, and in fact overly generic. If I call a method that declares itself to throw NoSuchFileException or DirectoryNotEmptyException, I can have a pretty good idea what I might do about it. If it throws IOException without elaboration, on the other hand...

With regards to I/O, there are generally any number of weird errors you can run into, file not found, directory exists, host unreachable, permission denied, file corrupt, etc etc. Like anything file related will be able to throw any of those exceptions at almost any point in time. I think IOException (or maybe FileSystemException) is probably the best you can do in a lot of I/O cases unless you can dedicate time to h…

There are fatal IO errors and non-fatal. Most of us don't care about the non-fatal case, but mainframes have the concept of "file isn't available now, load tape 12345", "file is being restored from backup, try again tomorrow" - things that your code could handle (if nothing else you should inform the user that this will take a while). There is also the "read off the end of the file" exception which in some languages is the idiomatic way to tell when you have read the whole file.

But most IO errors are fatal. It doesn't matter if the filename is not found, or the controller had too many errors talking to the drive and gave up - either way your code can do nothing.

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

#324

Post by jghn »

jagraff wrote: post #222

> Contrarily, library development is about abstractions. Spend time hunting for an algebra This line piqued my interest - what does an algebra mean in this context? Does anyone know of any good resources for further exploration?

It comes from the FP world. It's one of those things like monads that seem obvious when explained but sound opaque if you're not in on it.

Basically it's saying to create a formal set of types and formal rules about how they interact. If you search for permutations of phrases like "functional programming" "algebra" "data types" you'll turn up some hits. For instance [1]

[1] https://www.turingtaco.com/algebraic-data-types-structuring-...

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

#325

Post by recroad »

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…

Developer for 20+ years. I can't even design anything without coding something.

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

#326

Post by qaq »

The_Colonel wrote: post #140
qaq wrote: post #92

Earlier quoted context omitted.

It's not so much optimization but experience that on any sufficiently large project you gonna run into ORM limitation and end up with mix of ORM and direct queries. So might as well...

Starting with raw SQL is fun. But at some point you find out you need some caching here, then there, then you have a bunch of custom disconnected caches having bugs with invalidation. Then you need lazy loading and fetch graphs. Step by step you'll build your own (shitty) ORM. Same thing for people claiming they don't need any frameworks.

caching is orthogonal to using or not using ORM. You might opt to have caching with or without ORM in a consistent manner. You can also opt to add read replicas fronted by say pgcat in Postgres case without having separate caching layer.

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

#327

Post by bluGill »

whstl wrote: post #287
wesselbindt wrote: post #156

Earlier quoted context omitted.

I'm kind of wondering where the "mixed experience levels" part comes from. What is it about more homogeneously skilled teams that makes them less susceptible to the productivity boost that statically typed languages give in large code bases?

IMO it's like scrum: if your team is good and homogeneous, it doesn't really matter much what you do: it just works. Scrum and no scrum, types and no types. It's not about having rockstars or 10x engineers, it's just about having shorthands, shared knowledge, etc. If your team is varied or too large, you need things to help you out with organisation and communication. (Whether my examples of Scrum and Types are the a…

In my experience: Too large is any team larger than 10 people or any code base with more than 10,000 lines of code. Both of those would be considered tiny by most in the industry.

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

#328

Post by evilduck »

ghc wrote: post #214
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…

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…

If typesetting and a grammar mistake in one sentence were what made a book viable or not, authors would care. I've seen enough (crazy expensive) bugs that could have been caught by linters and bugs introduced through insane formatting and style choices that I can't agree that a book and software are all that comparable.

I'm on team "agree at the beginning and then make it part of CI" and I basically never have to have this conversation more than once or twice per project now but I also think that the people most obsessed with it and dwell on it for their personal daily work are problematic, as are the people who hate any rules whatsoever and want to write complete shit code to just call the job done because "that's the important part".

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

#329

Post by knodi123 »

pinoy420 wrote: post #241
dtquad wrote: post #168

>Frontend development is a nightmare world of Kafkaesque awfulness I no longer enjoy As a backend/systems engineer I recently had to look at a React + Typescript + MobX app from 2019/2020. It is true that that some things, especially the webpack config and Typescript loading, were outdated but the overall design and architecture of the app was still understandable and modern. With some help from ChatGPT it took very…

With ChatGPT I am enjoying Typescript development and learning a lot. Unfortunately with ChatGPT being - in JavaScript terms - decades behind the state of the art. It becomes a little challenging to get it to do what you want. But it gets me 80-90% of the way there 70% of the time. Which is a huge win.

I know what you meant, but that phrasing reminds me of the gag from Anchorman, "60% of the time, it works every time."

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

#330

Post by geophile »

After more than 25 years in the industry, and 10 years of retirement, I agree with pretty much everything on this list. A few things that struck me:

- Don't get too fundamentalist about OO or functional programming. Each has its place.

- "Spend time hunting for an algebra" is somewhat obscure, but truly excellent advice, and I have spend a lot of my career doing exactly that. That has never been time wasted. This connects to a couple of other points. 1) Once you have an algebra, you have the basis of a good API for functional programming. (This point is not explicit in the list.) 2) The things manipulated by your algebra are also the basis of a good OO design.

- "Elegance is not a real metric." It is absolutely dangerous as a metric, because it is a subjective goal we all aim for, and can therefore be used to justify anything, no matter how dumb. That said, elegance is something to strive for in your day-to-day programming life. You know it when you see it in someone else's work, and you appreciate it. You see a small set of principles, implemented in one place, that can then combine in many ways to do many useful things. Hmm, sounds a lot like an algebra!

Post reply on HN