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

301–310 of 788 posts

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

#301

Post by AnimalMuppet »

yakshaving_jgt wrote: post #189
bayindirh wrote: post #47

Earlier quoted context omitted.

Let me try to explain it a bit more. From my experience, functional programmers come in two flavors. The ones who constantly nag others by telling them "everything you do is wrong", and "hey, come here, I want to show you something!". Unfortunately, the first camp is way more dominant than others. Again, from the same article, there's observation "People who care about the craft are rare. Cherish the who cares, meet…

Really? You think most functional programmers are arrogant? Have you considered that your position is lazy, and that actually you have the problem?

No, I've seen it too. Here on HN. Not just once.

Maybe not "most functional programmers", though. Maybe "the functional programmers who post the most" or "post the most stridently" and therefore "the functional programmers that I encounter the most often in ways that let me know that they are functional programmers".

And "Have you considered that your position is lazy" isn't a reply likely to change hearts and minds. (It is also, itself, a pretty lazy reply, compared to the effort the GP put into their answer.)

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

#302

Post by swiftcoder »

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…

If what you care about deeply can be automated by a linter, it's trivial, and you ought to just setup the linter rules, and go use all that time you just gained to work on something more meaningful.

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

#303

Post by nucleardog »

wesselbindt wrote: post #156
Kototama wrote: post #11

> Typed languages are essential on teams with mixed experience levels I like this one because it puts this endless dilemma in a human context. Most discussions are technical (static typing ease refactoring and safety, dynamic typing is easier to learn and better for interactive programming etc.) and ignore the users, the programmers.

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?

I would tend to agree with the author's statement there. Though less "necessary for heterogeneous teams" and more "unless your team is entirely senior/skilled".

To sum up some thoughts that have evolved over decades into something more reasonable for a comment--more junior developers are less able to develop a robus mental model of the codebase they're working in. A senior developer can often see further out into fog of war, while the more junior developer is working in a more local context. Enforcing typing brings the context closer into view and reduces the scope necessary for the developer to make sensible changes to something manageable.

It also makes it much easier to keep contracts in the codebase sane and able to be relied on. With no declared return type on some method, even with checks and code reviews it's possible there's some non-obvious branch or set of conditions where it fails to return something. Somebody might try and take a "shortcut" and return some totally different type of object in some case. In every case, it puts these things front and center and reduces the ability to "throw shit at the wall until it sort of works on the happy path" without making that much more obvious.

And once those types are declared, it saves everyone else time when stupid shit does slip through. You probably have some idea what `getProductAvailability(products)` might do in some eCommerce system. But when the actual function is implemented as `getProductAvailability(InvoiceItem[] products): void`, the foot gun for the rest of the team is... less. (Your guess as to how I know this is correct.)

In teams with good, experienced people the types are still helpful and I'd still question anyone choosing _not_ to be explicit about these sorts of things regardless of team composition. But they're much less _necessary_ in a skilled team in my experience.

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

#305

Post by wink »

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?

Only guessing but my first thought was about how you have addition and multiplication and they both work for different types of numbers. But not in the generics/C++ template sense, more like working on Sets and Rings and other algebraic structures in the mathematical sense.

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

#306

Post by qwertox »

> Java is a great language because it's boring

My issue with Java is not that it's boring, which it is not, but there is so much that needs to be done to get a simple "Hello World" program to run which also depends on an external library. It feels like you first have to build a castle just to put a bed in a room.

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

#307

Post by namaria »

skydhash wrote: post #104
hliyan wrote: post #84

Earlier quoted context omitted.

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…

That’s because the few hard rules you have to comply with have workarounds and matters rarely. In house construction, you have to care about weight, material degradation, the code, etc… there’s no such limitation on software so you can get something to work even if it’s born out of a LSD trip. But we do have some common concepts. But they’re theoretical, so only the people that read the books knows the jargon.

I mean why should we expect software to have hard rules? Flexibility is the point, no?

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

#308

Post by ikety »

FrustratedMonky wrote: post #98

"Objects are extremely good at what they're good at. Blind devotion to functional is dumb. " Guess this hits home. But Blind anything is bad. I spent a decade blinded by objects being everything (original gang of four book). Then a decade where everything is functions. Why not pass a list of objects to that function.

Objects are also used in functional programming. This feels like a reaction to people being functional evangelists.

There's a reason most modern languages are completely blurring the lines and allowing you to think with multiple paradigms.

I'd be more upset with institutions lacking in functional programming coursework. OOP is dominant, I can't see why people get so irritated by a few annoying functional evangelists. And while annoying, I don't think the motivation there is always "Blind devotion to functional"

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

#309

Post by bluGill »

pinoy420 wrote: post #261
The_Colonel wrote: post #129

Earlier quoted context omitted.

> They just needed some syntactic sugar to help redirect certain developers into less self-destructive ways of procrastinating on proper error handling. Syntactic sugar it needs is an easy way (like ! prefix) to turn it to a runtime exception. Procrastinating on exceptions is usually the correct thing to do in your typical business application - crash the current business transaction, log the error, return error resp…

How many errors are actually recoverable. I bet most thrown exceptions could be replaced with a printf(“it went wrong here”) for all their utility.

I disagree. The real value of exceptions is you can skip 6 levels of functions that have lines like

status = DoThing(); if(status != allIsWell) {return status;}

C++ embedded for a long time has said don't use exceptions they are slow. However recent thinking has changed - turns out in trivial code exceptions are slow but in more real world code exceptions are faster than all those layers if checks - and better yet you won't give up on writing all the if checks. Thus embedded projects are starting turn exceptions on (often optimized exceptions with static pre allocated buffers)

The final "print something when wrong" is of little value, but the unwinding is very valuable.

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

#310

Post by skydhash »

skeeter2020 wrote: post #231
skydhash wrote: post #94

Earlier quoted context omitted.

The value of software is both what it does now (behavior), and what you can get it to do later (structure). What you described as design and the compiled artiface is the behavior. The craft is what gives you future choices. So when people cares about readability, writing tests, architecture, they’re just making easy for them to adjust the current behavior later when requirements change. A software is not an house, it…

experience gives you some possible ideas for how it will be used in the future, but after a long time I'm coming to the position you're fooling yourself if you think you can predict where with any accuracy. It's still valuable and important to try, just not as critical to be right as I used to think. Example: I've completely flip-flopped from interface simplicity to implementation simplicity. I agree that a house is…

You have to be pragmatic about it, balancing between the speed of only implementing the now and the flexibility of taking care of the future. It's not predicting, mostly it's about recognizing the consequences of each choice (for later modifications) and and either accepting it or ensuring that it will not happen.
Post reply on HN