Hacker News Reader

Comment by kf6nux | Hacker News Reader

> function overloading, operator overloading

I think Go took the right approach with calling those bugs to be avoided rather than features to be implemented.

Don't be clever. Be understandable to most readers.

The readers who matter should not have any issue understanding your code. You don't have to make the code understandable to most readers i.e. off the street.

If you make a function called add which actually subtracts, why is that any different to an operator overload?

The measure of a successful software project is how long it takes an arbitrary programmer who has intermediate proficiency with the language and a reasonable understanding of the business domain to understand and become a productive contributor to the codebase.

Learning curves bring payoffs. It's most important that an expert can quickly make changes that are obviously correct, concise, and performant to the other experts.

Quickly onboarding novices is only helpful for throwaway work or teams with retention problems. Their work inherently needs more scrutiny until they become experts.

Experts take a long time to make. Few stay on any project long enough that the investment pays off. It's more important to ramp new developers up quickly than to empower experts.

Those projects are doomed and I would urge anyone not to spend much of his career trying to delay the collapse.

I say that as a member of a team whose median tenure (three years ten months) is short enough to concern me a little.

> Those projects are doomed

Based on my experience those projects are 99% of all projects in commercial organizations. So, emphatically no.

Is typing `combine(t1, t2)` instead of `t1 + t2` the largest issue your experts have to productivity? Most folks complain about a variety of factors beyond typing speed.

I picked up Lisp early on, and don’t care that much about t1 + t2 vs. (+ t1 t2) vs. t1.add(t2). But without method overloading and generics, changing the static type of anything requires editing everything.

Good points.

I accidentally replied to yours. I had intended to reply to preseinger.

Well for math matrix formulas it gets difficult to read. Like (A+B)/2 *C*(A-B)/2 is better than mulMat(skalardivide(addMat(A, B), 2),mulMat(C,skalardivide(subMat(A,B),2)))

Definitely not.

The former is in general preferable to the latter, though, because it makes it a little more clear that arbitrary computation is occurring.

That sounds like a measure for successful software projects at deeply dysfunctional large companies that have fresh grads maintaining almost all of their software after the authors vanished.

The whole attitude (and the Go programming language) is maybe downstream from the fact that perf/promo criteria punish people who maintain the software they write.

What you label "deeply dysfunctional" I see as "emphatically normal".

idk? if you have a choice about how this will work for your software, you can chooce not to create huge incentives against expertise.

I want to create incentives against things that make things easier for experts if they also make things harder for novices. Successful projects aren't those which make their experts the most productive, they are those which make the onboarding experience easiest. This is proven time and time again, at least in all of the contexts in which I inhabit.

Yes, but in my experience if your issue is operator overloading then you have bigger issues to worry about.

Exactly. I think some people complain about Go's limitations. But this gives back in readability.

Ruby and Swift have those features and are fine languages. The reaction against those features originates from exposure to C++.

It's true that function overloading is often overused. operator overloading, too <cough>iostreams</cough>

Yes but then they created their own world of evil with the ducktyping aproach...

Reply on news.ycombinator.com