> At this point, it seems clear to me we’ve just poorly designed our function. It solely exists to clamp numbers, so why would we accept strings?

To me it sounds like you are using a poorly-designed language

▲

nenenejej 13 hours ago | parent | next [-]

Yes. Go for example doesnt need an is-nunber, nor do you need to worry about if a validation throws an exception and unwinds your call stack (or not)

▲

quotemstr 11 hours ago | parent | prev [-]

> To me it sounds like you are using a poorly-designed language

Not language specific. A C example that comes to mind is checking every non-nullable pointer parameter in every function for NULL and reporting an error instead of just letting the program crash. (Please, don't do that: just let contract violations produce crashes.)

The article's author describes a problem of experience and spirit, not a language wart.

▲

hnlmorg 10 hours ago | parent | next [-]

But the problem is literally a direct result of language wart.

The nullable pointer you’ve given is another great example of language wart. And one that’s often highlighted as a specific criticism against Go lang.

▲

quotemstr 10 hours ago | parent [-]

No, the problem is a result of sloppy thinking --- or no thinking --- about function contracts.

	▲	hnlmorg 10 hours ago \| parent [-]
		Humans error. The point of programming languages is to provide an abstraction to make development faster and less error prone than writing stuff in lower level languages or even assembly. If your language requires you to manually track function contracts then that’s a problem with the language itself. Not the developer.

▲

Turskarama 10 hours ago | parent | prev | next [-]

Let me blow your mind for a second: this problem is not insurmountable in language design, C is not a perfect language, and nulls are bad design.

▲

ModernMech 4 hours ago | parent | prev [-]

Indeed, you've pointed out a second language in the class of "poorly-designed languages"