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

741–750 of 788 posts

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

#741

Post by tisdadd »

mindcrime wrote: post #452
atq2119 wrote: post #355

Earlier quoted context omitted.

> will fail a code review over a variable that he feels isn't cased properly Many projects have fairly strict rules about identifier naming conventions, so this doesn't feel so far fetched to me. The example about if/else vs ? : is pretty damning though.

Sure, but if there are actual rules, agreed to and accepted by the entire team (as opposed to one guy's idiosyncratic preferences) then there should be a commit-hook to run the code through a linter and reject the commit if the rules are violated.

Yes indeed. I'm a fan of getting the team to pick an already existing lint ruleset and then doing this. You can also set to only lint changed files if you want a gradual change over in existing codebase.

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

#742

Post by sethammons »

I've been at this a couple decades, focusing on SaaS, rising up with and through a unicorn, and having worked at over half a dozen real engineering orgs, I agree with just about everything in the article.

My two differing thoughts:

1) Gradual, dependently typed languages are the future: no, just go with something typed. We are trying to type our python code base right now. It sucks.

2) People who stress over code style...: I love go fmt. Use tooling and linters. Be consistent in the code base. Inconsistent styles can lead to misreading code.

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

#743

Post by roguecoder »

tasuki wrote: post #371

> Gradual, dependently typed languages are the future What's that? Idris is dependently typed. > Gradual typing is a type system that lies inbetween static typing and in dynamic typing. Some variables and expressions may be given types and the correctness of the typing is checked at compile time and some expressions may be left untyped and eventual type errors are reported at runtime. That sounds miserable. I can't s…

I recommend https://open.library.ubc.ca/soa/cIRcle/collections/ubctheses... as a place to start.

It isn't about "guaranteeing" _everything_, any more than assertions or guard clauses guarantee everything. It is about giving programmers a semantic tool they can use to communicate expected interfaces in an automatically-detected way, without adding unnecessary toil and boilerplate in tight, local contexts where functions are just working on obvious primitives.

The most graceful implementation I've seen is RDoc comments + Jetbrains tooling in Ruby. When it looks like a type system people assume it's going to work like Java, but having build-time checks based on where people bothered to describe the expected interface catches errors without any of the downsides of type systems that keep type systems from measurably boosting productivity.

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

#744

Post by psunavy03 »

So "management is invaluable" but "most project managers are worthless." Not necessarily a contradiction, but it makes you go "hmm."

At some point, you have to have someone looking "up and out" to make sure the folks looking "down and in" are all still moving in the same direction.

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

#745

Post by eyelidlessness »

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…

Agree. Although I increasingly spend this iteration time on types/interfaces/documenting proposal of same. The actual implementation below that is often trivial once the boundaries are settled.

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

#746

Post by bobthepanda »

CapsAdmin wrote: post #720
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

I know this sounds insane, but I used to work on some big svn codebase with many developers, without any fancy formating tools AND no one cared about consistent style. One interesting thing that happened was the ability to guess who wrote what code purely based on coding style.

This happens to some degree in linted code bases since there’s more than one way to write the same code, and people reach for what they like

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

#747

Post by nijave »

hliyan wrote: post #68
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…

There's another way to look at this: if you consider the school of thought that says that the code is the design, and compilation is the construction process, then stressing over code style is equivalent to stressing over the formatting and conventions of the blueprint (to use a civil engineering metaphor), instead of stressing over load bearing, material costs and utility of the space. I'm fond of saying that anythi…

Code is read much more frequently than a blueprint.

I'd argue that code is more akin to a paper map than blueprint.

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

#748

Post by buescher »

hliyan wrote: post #84
Retric wrote: post #77

Earlier quoted context omitted.

> the formatting and conventions of the blueprint Some of those formatting conventions are written in blood. The clarity of a blueprint is a big deal when people are using it to convey safety critical information. I don’t think code formatting rises anywhere close to that level, but it’s also trying to reduce cognitive load which is a big deal in software development. Nobody wants to look at multiple lines concatenat…

I 100% agree. The problem is that after a half a century, software engineering discipline has been unable to agree on global conventions and standards. I recently had an experience where a repair crew was worried about the odd looking placement of a concrete beam in my house. I brought over the blueprints, and the technician found the schedule of beams and columns within seconds, pinpointed the beam and said, "Ah, th…

It's telling I think that the discussion becomes about standards, which software people like, rather than say, clear communication to technical stakeholders beyond the original programmer. I have a list somewhere I made of everyone that might eventually need to read an electronics schematic. Particularly to emphasize clarity to younger engineers and (ex-)hobbyists that think schematics are a kind of awkward source code or data entry for layout. It's not short: test, legal, quality control, manufacturing, firmware, sustaining/maintenance, sometimes even purchasing, etc.

Whoever drew your blueprints knew they would be needed beyond getting the house up. What would the equivalent perspective and effort for software engineering be?

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

#749

Post by nijave »

eloisant wrote: post #705
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. S…

That's my stance--formatting and style is important but it's also a job for machines. I think you can still quibble over formatting but the result should be automation, not nit-picky code review comments or chat war threads.

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

#750

Post by nsm »

tome wrote: post #708
valcron1000 wrote: post #530

Earlier quoted context omitted.

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!

Aren't checked exceptions the same as effect systems in the narrow case of error handling?
Post reply on HN