@MisterMiyagi, I am tending towards that position, yes, that leaving details undefined means the details are not well-defined.

@kaya3, but it's possible to use things you don't properly understand, and which are ill-defined. The mere use of things doesn't thereby establish that they must be well-defined. And definition is not a binary state, but a matter of precision. Lots seems to be made of the fact that internals behind the interface can be varied - but that latitude exists often as much because the interface is not well-defined, rather than because it is well-defined. That's typically why viruses have been introduced into open source libraries - everyone keeps pretending the interfaces are well-defined.

Also my argument is not against using abstractions. It is against people becoming so familiar and ensconced with these abstractions, that they forget there is a wider reality where these abstractions do not properly apply, or that there are important aspects of very routine problems which they do not cover. The consequence appears to be that they lose (or do not even acquire) the knowledge and skill to make an informed decision in the first place about what matters and situations the abstractions do and do not properly apply to. (3/3)

My argument is also that there are a large class of details which are not in fact free to be varied arbitrarily, but have acceptable ranges of behaviour, even if it can be easily shown that no one specific behaviour is always required. These constraints are themselves usually ill-defined and usually implicit, but are certainly there. I gave the example of execution time - it is rarely constrained to an exact number of clock cycles, but there is usually a range of acceptability, and the actual execution time is determined by the internals. (2/3)

@MisterMiyagi, my argument is not that every internal detail always counts in every case. My argument is that every detail always counts in some case. Or speaking even more precisely on the point, that there are no general class of details, which would be important to know of or discuss amongst ourselves as a general class, which never count in any case. Software developers have to make informed decisions in the context about what counts and what doesn't. (1/3)

@MichaelHomer, it must have something to do with this site's topic if a person, to introduce their question, alleges the existence of something I'm saying doesn't exist and is a contradiction in terms (for reasons that can't be summarised in a comment). I realise the OP was not asking about the issue I've raised, presumably because they assumed it was an uncontroversial starting point, but this answer is addressing that flaw in their premise. I'm less inclined to say that "no such languages exist" - rather, that languages do exist which facilitate the OP's faulty thinking about interfaces.

@SoronelHaetir, that's not my point. As I say, many usages of interfaces tolerate sloppiness - and the world is rife with crap, buggy, flawed software. I often use interfaces of complex software whose internals I don't remotely understand - often, there's a small space of behaviour which from experience I know works for my purpose, and hope will remain consistent into the indefinite future. But they're not thereby "well-defined" - they're an ill-defined thing which I merely hope someone else has designed intelligently to anticipate my usage and behave sensibly in relation to my usage.

Nobody says one interface where you wait a second for results, another where you wait a week, and a third where there is the possibility of no return at all, are all the "same interface", just because the method signatures say they all take an int and return an int, because profile of behaviour in the round is completely different. (2/2)

@EricLippert, I deny that "black boxes with well-defined interfaces" exist. Rather, the blacker the box, the more loosely or ill-defined the real interface. Often with these things, the concept of the "interface" itself is defined in an artificially narrow way to consist only of the data types of the members, arguments, or results - I mention the example of execution time of a call which is rarely considered part of the explicit interface in these discourses, but is always somewhat relevant (and extremely relevant in cryptography). (1/2)

@supercat, CRTs were even more space-constrained than punch-cards in terms of what you could view at once. I suspect the perceived advantages of braces included the speed of (and unambiguity for) parsing, the reduction in visual clutter and in-keeping with the generally greater use of symbols, and ability to consolidate the open and close onto a single line (together with the two or more statements inside the block, the minimum to justify an explicit block being used at all) without causing excessive line length.

@Barmar, yes I do so myself!

@Brian, I find SQL is designed poorly in that respect - there are too many implicit casts, and the explicit syntax for casting is far too bulky relative to frequency of use. I think with most business arithmetic though, in any language, fixed-width fields are an inconvenience which force unnecessary sizing decisions (typically into a Procrustean bed of binary powers) and conversions.

"user identity" - our thinking would be a lot more honest, if we just went back to calling them "logins".

"well-typed programs never go wrong" - do you mean never go wrong due to type-casting errors? It's ludicrous to suggest poor type discipline is the only way programs go wrong.