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

611–620 of 788 posts

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

#611

Post by lmm »

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…

Stack traces are valuable and important, agreed. (In Scala it's pretty normal to use Either/Result with an exception type on the left so that you still get the stack trace). And it's definitely possible to carry an error state around too far when it's not recoverable and you should have just errored out earlier - ultimately you still need good coding judgement. "All functions end up returnig `Either/Result`" is a sign you're doing something wrong.

> Exceptions and panics can still creep so it's not even "safer"

This part is just as true for checked exceptions - you still have unchecked exceptions too. Ultimately you can't get away from needing a way to bail out from unrecoverable states. But "secondary state that is recoverable and understandable, but should be handled off the primary codepath" is a very useful tool to have in your vocabulary.

> Today I write C# at my job and I could not be happier with the usage of exceptions.

How do you do e.g. input validation? Things that are going to be 4xx errors not 5xx errors, in HTTP terms. Do you use exceptions for those? (I note that C# doesn't have checked exceptions at all, so there's no direct equivalent)

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

#612

Post by specialist »

pjmlp wrote: post #25
Terr_ wrote: post #2

> Java is a great language because it's boring [...] Types are assertions we make about the world This is less of a mind-was-changed case and more just controversial, but... Checked Exceptions were a fundamentally good idea. They just needed some syntactic sugar to help redirect certain developers into less self-destructive ways of procrastinating on proper error handling. In brief for non-Java folks: Checked Excepti…

I agree, although I would like to point out Java usually gets the blame for what was actually an idea being done in CLU, Mesa, Modula-3 and C++, before Oak came to be and turned into Java. Additionally, the way result types work, isn't much different, from type system theory point of view. I really miss them in .NET projects, because no one reads method documentation, or bothers to have catch all clauses, and then li…

Anti checked exception sentiment is the result of cognitive dissonance from the use of flow-of-control obfuscation frameworks.

IoC, DI, aspects, annotations, ORMs, whatever Spring is, runtime code generation, etc.

The rationale is something like "runtime metaprogramming would be really terrific, were it not for all those pesky checked exceptions".

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

#613

Post by waylandsmithers »

zafka wrote: post #317

"93%, maybe 95.2%, of project managers, could disappear tomorrow to either no effect or a net gain in efficiency. (this estimate is up from 4 years ago)" This made me laugh it is so true. My last big project at "Big Co" ( Knee surgery robot ) My small group went through 4 project managers - just for our small team. The entire project had probably 20. While a few where enjoyable to work with, there was very little val…

I was really surprised to hear this because I feel the exact opposite! I've worked mainly with project managers who ran all the ceremonies, held people accountable, dealt with planning and doling out tasks, handled stakeholders and generally protected the devs from distractions, and took real leadership and accountability in the project.

Whenever I've worked on a team where a developer is the team lead and has to do all that stuff on top of coding- or worse, it's just a free for all with no leader- , things in my experience go much worse, communication breaks down, and things slip through the cracks.

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

#614

Post by jayd16 »

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…

The trick to life is finding the exact right amount of fucks to give.

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

#615

Post by bdangubic »

jayd16 wrote: post #614
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…

The trick to life is finding the exact right amount of fucks to give.

zero… the answer is zero :)

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

#616

Post by phist_mcgee »

zelphirkalt wrote: post #570
phist_mcgee wrote: post #526

Earlier quoted context omitted.

You don't have to follow hype when doing frontend, you can pick whichever technologies you want and stick with them for years. Part of being a good frontend lead is personally is not falling for the hype, and only adding packages I know will a. be supported for the foreseeable future, b. have an exit plan if those technologies aren't supported, and c. keep an eye on my juniors/seniors to make sure they're writing sen…

Yeah, you don't have to follow the hype, unless of course you got coworkers blinded by the hype and managers, who do not know how to discern who actually knows something and who is just jumping on bandwagons. Suddenly you will seem like the backwards guy, who does not want to learn the new shiny thing. Then suddenly you do have to follow the hype, even though you warned them. As a full stack developer, your chances o…

>why would I even want to become a frontend lead and sacrifice the part of development, that is much saner

That's your choice, but myself personally, I like the deep focus on one thing along with guiding my team. I think we perform at a pretty high level and we are a happy productive team by all reports.

Our frontend is sane and that was because I was given the scope to make it sane. Others will have different experiences, and I agree that full-stack would have less sane by default, due to the lack of time or care for it.

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

#617

Post by Twirrim »

spc476 wrote: post #498
Twirrim wrote: post #164

Earlier quoted context omitted.

I've grown to be a big fan of opinionated linters like gofmt, rustfmt, black etc. They avoid so much time spent disagreeing about code formatting and personal preferences. Instead engineers can do mutual grumbling sessions about weird formatting choices they see it do, and move on.

If I didn't want to have opinions, I would join a cult.

You're welcome to your opinions, I don't stop engineers I'm working with from having opinions about the code formatting. It's still going to be formatted by the opinionated formatter.

Having one gets us into the "Well, it's not quite what I want but at least it's consistent", and it gets rid of arguments that don't really provide anywhere near the amount of value engineers feel they do. There are almost always significantly better and more productive things to be spending time figuring out.

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

#618

Post by edm0nd »

danielbln wrote: post #490
alternatex wrote: post #420

Earlier quoted context omitted.

Today Steam gives us the option of verifying whether a certain player has no life. Only half joking.

My favorite steam reviews are: "This game sucks, would not recommend." - playtime 800h

and on the flipside of this

"This game sucks, would not recommend." - playtime 1.2h

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

#619

Post by Sparkyte »

Most to all I agree. I disagree with monoliths and microservices. I am not a fan of microservice per se but I'm not a fan of monoliths either. I certainly prefer a mix depending on their use cases. However both designs deserve equal scrutiny.

My monolith horror started when I was working with Ruby developers. The problem with a monolith is when it becomes too big for itself. Realistically something between microservices and monoliths are where quality of life resides.

If you need a small service that needs to be fast and focused microservice it. If you need a service where it relies heavily on the same logic and shared across many things. As long as it is performant, modular and easy to fix, monolith it.

Either way conforming to one design certainly cripples the potential of services.

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

#620

Post by Defletter »

bayindirh wrote: post #61
xnorswap wrote: post #35

Earlier quoted context omitted.

The solution is to have computers enforce the code style. Pick a linter, pick a set of rules, and then forget about them. Things I beleive: - If you're picking up on code-style in PRs then your toolchain is backward. - If you're changing linting rules every month then you're focussed on the wrong things - It's better to have a consistent style than a perfect style

Yes. I love how gofmt has no settings, basically. Is this how you envisioned? Great. Now I don't have to think about optimizing it. Coincidentally, the choices they made are the choices I'd made, but it doesn't matter in the end.

Vehemently disagree. I get that go's conventions line up with your own, but when they don't, it's irritating. For example, Dart is finally coming around on the "tall" style (https://github.com/dart-lang/dart_style/issues/1253). But why should people be forced to wait for a committee (or some other lofty institution) to change a style convention that then effects everyone using the language? What's the harm in letting people write their code in the "tall" style beforehand? Why must the formatter be so insistent about it?
Post reply on HN