Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Laws of Software Engineering

lawsofsoftwareengineering.com

Post reply on HN
Print view View original

411–420 of 554 posts

Re: Laws of Software Engineering

#411

Post by traderj0e »

regular_trash wrote: post #287

Hot take - I hate YAGNI. My personal pet peeve is when someone says YAGNI to a structure in the code they perceive as "more complex than they would have done it". Sure, don't add hooks for things you don't immediately need. But if you are reasonably sure a feature is going to be required at some point, it doesn't hurt to organize and structure your code in a way that makes those hooks easy to add later on. Worst case…

YAGNI isn't really a law, it's just something you say when you think you ain't gonna need it. You could be wrong, and you actually gonna need it.

Re: Laws of Software Engineering

#412

Post by traderj0e »

wesselbindt wrote: post #61

Two of my main CAP theorem pet peeves happen on this page: - Not realizing it's a very concrete theorem applicable in a very narrow theoretical situation, and that its value lies not in the statement itself but in the way of thinking that goes into the proof. - Stating it as "pick any two". You cannot pick CA. Under the conditions of the CAP theorem it is immediately obvious that CA implies you have exactly one node.…

In practice a quorum mechanism gets you close enough to picking all three in CAP, doesn't it? But it's still useful to teach.

Re: Laws of Software Engineering

#413

Post by tombert »

xorcist wrote: post #389
tombert wrote: post #335

Earlier quoted context omitted.

The biggest issue I have with premature optimization is stuff that really doesn't matter . For example, in Java I usually use ConcurrentHashMap, even in contexts that a regular HashMap might be ok. My reasoning for this is simple: I might want to use it in a multithreaded context eventually and the performance differences really aren't that much for most things; uncontested locks in Java are nearly free. I've gotten…

I can fully understand "bickering" about someone sprinkling their favourite data type over a codebase which consistently used a standard data type before. The argument that it might be multithreaded in the futurure does not hold if the rest of the code base clearly was not writen with that in mind. That could even be counter productive, should someone get the misguided idea that it was ready for it. Make a (very) goo…

I don’t expose it at the boundaries, just within functions. With everything outside of the function I take a Map interface in and/or return the Map out.

It makes no difference to the outside code.

Re: Laws of Software Engineering

#414

Post by xorcist »

tombert wrote: post #413
xorcist wrote: post #389

Earlier quoted context omitted.

I can fully understand "bickering" about someone sprinkling their favourite data type over a codebase which consistently used a standard data type before. The argument that it might be multithreaded in the futurure does not hold if the rest of the code base clearly was not writen with that in mind. That could even be counter productive, should someone get the misguided idea that it was ready for it. Make a (very) goo…

I don’t expose it at the boundaries, just within functions. With everything outside of the function I take a Map interface in and/or return the Map out. It makes no difference to the outside code.

That's really not much better. No function is an island, as wise man almost once said.

Re: Laws of Software Engineering

#415

Post by traderj0e »

AtNightWeCode wrote: post #337
regular_trash wrote: post #287

Hot take - I hate YAGNI. My personal pet peeve is when someone says YAGNI to a structure in the code they perceive as "more complex than they would have done it". Sure, don't add hooks for things you don't immediately need. But if you are reasonably sure a feature is going to be required at some point, it doesn't hurt to organize and structure your code in a way that makes those hooks easy to add later on. Worst case…

It is misused if anything. YAGNI is about functionality. What to add or not. But it has become an excuse for being lazy. Same people that interpreted the line “Working software over comprehensive documentation” as no need for documentation.

YAGNI is usually about modularization, often in response to Java-style OOP obsession. Like you don't need to define some big protocol that's only ever going to have one implementation.

Re: Laws of Software Engineering

#416

Post by tombert »

hunterpayne wrote: post #398
tombert wrote: post #335

Earlier quoted context omitted.

The biggest issue I have with premature optimization is stuff that really doesn't matter . For example, in Java I usually use ConcurrentHashMap, even in contexts that a regular HashMap might be ok. My reasoning for this is simple: I might want to use it in a multithreaded context eventually and the performance differences really aren't that much for most things; uncontested locks in Java are nearly free. I've gotten…

1) You don't need ConcurrentHashMap to make code thread-safe. That's the most extreme version that means that you need a thread-safe iterator too. 2) Locks are cheap 3) I seriously doubt that the difference between a Map and a ConcurrentHashMap is measurable in your app Which means that both, the comments on your PRs are irrelevant and you are still going too far in your thread-safety. So you are both wrong. What you…

Locks are cheap performance-wise (or at least they can be) but they’re easy to screw up and they can be difficult to performance test.

ConcurrentHashMap has the advantage of hiding the locking from me and more importantly has the advantage of being correct, and it can still use the same Map interface so if it’s eventually used downstream somewhere stuff like `compute` will work and it will be thread safe without and work with mutexes.

The argument I am making is that it is literally no extra work to use the ConcurrentHashMap, and in my benchmarks with JMH, it doesn’t perform significantly worse in a single-threaded context. It seems silly for anyone to try and save a nanosecond to use a regular HashMap in most cases.

Re: Laws of Software Engineering

#417

Post by tombert »

xorcist wrote: post #414
tombert wrote: post #413

Earlier quoted context omitted.

I don’t expose it at the boundaries, just within functions. With everything outside of the function I take a Map interface in and/or return the Map out. It makes no difference to the outside code.

That's really not much better. No function is an island, as wise man almost once said.

It’s actually a lot better. That’s literally the whole point of interfaces and polymorphism: to make it so the outside does not care about the implementation.

Re: Laws of Software Engineering

#418

Post by omoikane »

pkasting wrote: post #366
omoikane wrote: post #257

Earlier quoted context omitted.

"I'm casting around in my head for someone to blame, and it's just... me, keeps coming back at me." - Jeremy Clarkson (Top Gear, series 14 episode 5)

(Tangent: What a pleasure to see your username again; will always think of your readability help fondly!)

Great to see you too, it has been a pleasure working with you :)

Re: Laws of Software Engineering

#419

Post by galaxyLogic »

The Law of Leaky Abstractions. What is a "leaky" abstraction? How does it "leak"?

I wonder if it should be called "Law of Leaky Metaphors" instead. Metaphor is not the same thing as Abstraction. I can understand a "leaky metaphor" as something that does not quite make it, at least not in all aspects. But what would be a good EXAMPLE of a Leaky Abstraction?

Post reply on HN