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

641–650 of 788 posts

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

#641

Post by brunooliv »

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 a big difference when someone stresses over minutiae and fails to see the bigger picture or why the overall design might be flawed. Wanting to have code up to a given standard is a laudable goal but as with everything, it can be taken to such an extreme that people lose sight of the real value being delivered. Code is not the end goal, except for some people it is.

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

#642

Post by Defletter »

anon-3988 wrote: post #626
Defletter wrote: post #620

Earlier quoted context omitted.

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

> Why must the formatter be so insistent about it? Exactly to avoid conversations like this...If you want a tall format then just add a dummy comment at the end?

Except that a prescriptive formatter with zero configurability is causing this conversation.

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

#644

Post by Defletter »

serverlessmania wrote: post #643

"Given a long enough time horizon, you'll deeply regret building on Serverless Functions" Let's just apply "Hitchens's razor" to this kind of none sense: What can be asserted without evidence can also be dismissed without evidence

username checks out

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

#645

Post by bayindirh »

maleldil wrote: post #315
bayindirh wrote: post #114

Earlier quoted context omitted.

gofmt sorts imports within the block they are in. I have a habit of putting stdlib imports, a line break, golang experimental (x) imports, a line break and external imports. I just tested, gofmt orders imports within these blocks. If I won't use the line breaks, it'll consider it a single block and will globally sort. golang also aligns variable spacing and inline comments to look them as unified blocks (or a table i…

I meant that you could do this with isort in Python or rustfmt with `group_imports = StdExternalCrate` (sadly, not the default), where the imports are automatically separated into blocks, which is basically what you seem to be doing manually. My point is that many things we end up doing manually can be automated, so I don't need to care about unsorted or unused imports at all and can rely on them to be fixed without…

I didn't know that so many people did that so formatters have an option for this. On the other hand, I'm doing this for so long across so many languages, I never thought about it. It consumes no effort on my part.

Also, gofmt not removing the breaking lines and handling groups inside themselves tell me that gofmt is aware of these choices already and accommodates this without being fussy or needing configuration about it, and it's an elegant approach.

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

#646

Post by bayindirh »

Defletter wrote: post #642
anon-3988 wrote: post #626

Earlier quoted context omitted.

> Why must the formatter be so insistent about it? Exactly to avoid conversations like this...If you want a tall format then just add a dummy comment at the end?

Except that a prescriptive formatter with zero configurability is causing this conversation.

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

Even the logo's expression is an homage to this.

So yes, Go's formatter should be this prescriptive. The other thing is, you can continue this conversation till the end of time, but you can't argue with the formatter. It'll always do its thing.

In other words, "computer says no".

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

#647

Post by [deleted] »

jeroenhd wrote: post #155
pjc50 wrote: post #8

Earlier quoted context omitted.

It was botched from the start because there's so many opportunities for unchecked exceptions as well. Without a more sophisticated type system that represented nullability, you can get NullPointerException anywhere. Divide by zero. And so on. You also have a problem similar to "monads and logging": if you want to log from anywhere in your program, your logging function needs to be exception-tight and deal with all th…

Unchecked exceptions are just Java's weird way of what languages call panicking these days. They suck, but as long as you don't throw them yourself and catch them in a logical place (i.e. at request level so your web server doesn't die, at queue level so your data processing management doesn't lock up, etc.) you can usually pretty much ignore them. The worst part about them is that for some reason even standard libra…

[deleted]

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

#648

Post by whilenot-dev »

priyadi wrote: post #625
nodamage wrote: post #472

Earlier quoted context omitted.

I've never understood the ORM hate because a good ORM will get out of the way and let you write raw SQL when necessary while still offering all of the benefits you get out of an ORM when working with query results: 1. Mapping result rows back to objects, especially from joins where you will get back multiple rows per "object" that need to be collated. 2. Automatic handling of many-to-many relationships so you don't h…

You are describing data mapper ORMs, a.k.a the good ORM. I think all the other ORM-loathing guys here had bad experiences with active record ORMs, a.k.a the bad ORM. Also, infrastructure guys and DBA types tend not to like ORMs. But they are not the ones trying to manage the complexity in the business process. They just see our queries are not optimal, and it is everything to them.

Oh was I enthusiastic when I first got my hands on an active record ORM: "I can use all my usual objects and it'll manage the SQL for me? Wow!". That enthusiasm reached rock bottom rather quickly as soon as I wanted to fine tune things. Turns out I'm not a fan of mutating hierarchical objects and then calling a magical .commit()-method on it, or worse: letting the ORM do it implicitly. That abstraction is just not for me and I'd rather get my hands "dirty" writing SQL, I guess.

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

#649

Post by Defletter »

bayindirh wrote: post #646
Defletter wrote: post #642

Earlier quoted context omitted.

Except that a prescriptive formatter with zero configurability is causing this conversation.

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 convention for the entire world. This should not be necessary. Nor should you have to surround your code with formatter-disabling comments (assuming the language even supports that) to, for example, use the "tall" style, as previously mentioned. Nor should you have to literally fork the language or its tools to disable the formatter.

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

#650

Post by globular-toast »

priyadi wrote: post #625
nodamage wrote: post #472

Earlier quoted context omitted.

I've never understood the ORM hate because a good ORM will get out of the way and let you write raw SQL when necessary while still offering all of the benefits you get out of an ORM when working with query results: 1. Mapping result rows back to objects, especially from joins where you will get back multiple rows per "object" that need to be collated. 2. Automatic handling of many-to-many relationships so you don't h…

You are describing data mapper ORMs, a.k.a the good ORM. I think all the other ORM-loathing guys here had bad experiences with active record ORMs, a.k.a the bad ORM. Also, infrastructure guys and DBA types tend not to like ORMs. But they are not the ones trying to manage the complexity in the business process. They just see our queries are not optimal, and it is everything to them.

Right! They should really be considered two different things. I've worked a lot with Django (the bad type) which people tend to love, but I've seen the horrors that it can produce. What they seem to love about it is being able to write ridiculously complicated SQL using ridiculously complicated Python. I don't get it. These types of ORMs don't even fully map to objects. The "objects" it gives you are nothing more than database rows, so it's all at the same abstraction level as SQL, but it just looks like Python. It's crazy.

SQLAlchemy is the real deal, but it's more difficult and people prefer easy.

Post reply on HN