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

771–780 of 788 posts

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

#771

Post by anon-3988 »

Defletter wrote: post #649
bayindirh wrote: post #646

Earlier quoted context omitted.

When you are a solo dev, everything is acceptable. When you're in a group, this can cause friction and cause real problems if people are "so insistent" about their style. Go is a programming language developed for teams . From its syntax to core library to language server to tooling, Go is made for teams, and to minimize thinking. It's opposite of Rust. It's devilishly simple, so you can't make mistakes most of the t…

You are misunderstanding the argument: I am not against prescriptive formatters. By all means, enforce a style convention for your project, I have nothing against that, nor do I understand how you interpreted that from my comment. I am against prescriptive formatters that cannot be configured. This creates the absurd situation, as previously described, where one must appeal to 'The Committee' who decides the style co…

If something can be configured, this opens up infinite possibilities for discussions on how it should be configured. The fact that you even ASK if you should use the tall style means that you are considering the POSSIBILITY of using it that way.

Put it this way, if it is technically impossible to develop a car that have the color red, we would not be discussing or entertaining what color the next car should have. It would be red, end of story. It doesn't matter if we like red or not, it just has to be. end of story.

Yes, the code looks awful. end of story.

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

#772

Post by TeMPOraL »

gbro3n wrote: post #769
TeMPOraL wrote: post #721

Earlier quoted context omitted.

> The problem is that after a half a century, software engineering discipline has been unable to agree on global conventions and standards. It can't, and it won't, as long as we insist on always working directly on the "single source of truth", and representing it as plaintext code. It's just not sufficient to comprehensibly represent all concerns its consumers have at the same time . We're stuck in endless fights ab…

I think we have to think of software like books and writing. It is about conveying information, and while there are grammatical rules to language and conventions around good and bad writing, we're generally happy to leave it there because too many rules is so constructive as to remove the ability to express information in the way we feel we need to. We just have to accept that some are better writers than others, or…

That would make sense if code was written solely for the enjoyment of its readers, but it isn't.

Code uses text, sometimes even natural-language prose, but isn't like "books and writing". It has to communicate knowledge, not feels. It also ultimately have to be precise enough to give unambiguous instructions to a machine.

In this sense, code is like mathematical proofs and like architectural blueprints, which is a different category to drawings, paintings and literature. One is about shared, objective, precise understanding of a problem. The other is about sharing subjective, emotional experiences; having the audience understand the work, much less everyone understand it the same way, is not required, usually not possible, and often undesirable.

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

#773

Post by cafard »

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…

Didn't George Carlin say that everyone who drove faster than one was a maniac and everyone slower was a moron?

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

#774

Post by Defletter »

anon-3988 wrote: post #771
Defletter wrote: post #649

Earlier quoted context omitted.

You are misunderstanding the argument: I am not against prescriptive formatters. By all means, enforce a style convention for your project, I have nothing against that, nor do I understand how you interpreted that from my comment. I am against prescriptive formatters that cannot be configured. This creates the absurd situation, as previously described, where one must appeal to 'The Committee' who decides the style co…

If something can be configured, this opens up infinite possibilities for discussions on how it should be configured. The fact that you even ASK if you should use the tall style means that you are considering the POSSIBILITY of using it that way. Put it this way, if it is technically impossible to develop a car that have the color red, we would not be discussing or entertaining what color the next car should have. It…

Hot take: stop being authoritarian with code styles, perchance? You are not so wise as to determine what is clean code for the entire world, and the ego required to believe that you are is beyond astounding. And we're still having these discussions despite unconfigurably prescriptive formatters. This idea that such formatters end these discussions is just demonstrably false... you are literally taking part in one of these discussions.

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

#775

Post by lmm »

valcron1000 wrote: post #765
lmm wrote: post #611

Earlier quoted context omitted.

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 sig…

> This part is just as true for checked exceptions - you still have unchecked exceptions too That's why I'm against checked exceptions in general: I avoid them in Java as much as possible. > "All functions end up returnig `Either/Result`" is a sign you're doing something wrong. I agree, that's why I'm sharing that it's a bad idea. I've had this experience recently in a team of very experienced developers (some of the…

> In summary, I'm not against the existence of `Either/Result` in general, I think there are great use cases for them (like validation); what I'm against is the usage of them to signal all possible type of errors, in particular when IO is involved.

I agree that a checked error type is a bad way to represent IO errors that most programs won't want to handle (or will handle in a very basic "retry the whole thing at high level" way). I think a lot of functional IO runtimes are converging on a design where IO actions implicitly carry some possibility of error that you don't have to nest in a separate either/result type.

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

#776

Post by RandomMarius »

People who stress about people who stress about linting… focus on something else. Everyone has their idiosyncrasies.

A lot of great coders have psychological oddities. Some things help them focus. Whether it’s neat environment, listening to music, consistent code formatting.

I listen to them and try and accommodate even if I disagree. I’ve changed my mind about several topics multiple times now. I felt strongly about some at one point over the past few decades as well.

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

#777

Post by d-man »

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 think your exception model needs to match your problem domain and your solution.

I work on an Inversion of Control system integration framework on top of a herd of business logic passing messages between systems. If I were to do all over again, then I’d have the business logic:

* return success or failure (invalid input)

* throw exception with expectation that it might work in the near future (timeout), with advice on how long to wait to retry, and how many retries before escalating

* throw exception with expectation that a person needs to check things out (authentication failure)

Unless the business logic catches it, unchecked exceptions are a failure. Discussion about what is what kind of exception is hard, but the business owners usually have strong opinions taking me off the hook.

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

#778

Post by igouy »

9rx wrote: post #763
igouy wrote: post #577

Earlier quoted context omitted.

“When I use a word,” Humpty Dumpty said in rather a scornful tone, “it means just what I choose it to mean—neither more nor less.”

"I made up the term object-oriented, and I can tell you I did not have C++ in mind.", said Alan Kay.

That was the easy laughter set-up line. The follow-up seemed to confound the audience.

What was the follow-up?

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

#779

Post by mmcnl »

spiderxxxx wrote: post #596
mmcnl wrote: post #544

Earlier quoted context omitted.

And how do you figure out what the requirements are? In my 10+ professional years, I have never gotten requirements by asking for them. Almost always I had to show my interpretation of what I think the requirements are, and use the feedback I got to define the actual requirements. The quickest way to get there is by iterating.

You don't ask for the requirements. You ask what they're trying to do, or what problem they're trying to solve. Sometimes I have to ask "where is this data going" or "what do you expect the end result of this to be".

Not disagreeing here but whatever question you ask, you will only get the final answer _after_ you have implemented it, almost always after several iterations.

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

#780

Post by Shorel »

naasking wrote: post #704
Shorel wrote: post #660

Earlier quoted context omitted.

> 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.

Only by convention. You can write anything in a PL/SQL function, and that function can be called in a trigger.

Really, I can't imagine anything that can't be put in a trigger.

Post reply on HN