Type Modelling Discussion

Continued from TypeSystemCategoriesInImperativeLanguages because it's getting TooBigToEdit.

Regarding "the parts [I] talk of can only be inferred via a model of some sort", that's not true. We have language manuals, programming manuals, ComputerScience papers, textbooks, source code (including compiler and interpreter internals), and the verbal and written descriptions from people who create compilers and interpreters. These all allow us to do far more than infer "via a model of some sort"; they allow us to understand how languages actually behave -- based, ultimately, on how they're actually built -- and explain more than just I/O. I do understand that you want to create "The Top Field Guide to Programming Languages" based on a naturalist's observation of programming language behaviour, but as has been pointed out elsewhere on this page, that is both unnecessary and prone to error unless you (at least) take a scientist's approach by objectively using all sources of information available -- i.e., doing your research -- then rigorously justifying it and clearly, comprehensively, and completely defining and describing every aspect of it.

Like I said, the writing is often poor, probably because of tradition. I could get a model similar to your description to function (predict), but like I keep saying, it has too many parts. A model with fewer parts is a better model, all else being equal. Now it may be that all those parts come in useful for explaining other things and other situations; but I am not interested in modeling those "other things". It's like complaining my map is no good because it doesn't show elevations accurately, only using wavy marks to give a vague notion of elevation or steepness. Yes, this indeed may be an "objective fault" of my model (road map); but I'm not looking for a perfect model for all cases and situations, it's primarily a road-map for drivers, not a hiking map. Perhaps your model is a Swiss Army Map that can be just about anything for all occasions. But it may be "unfriendly" because it's too loaded up. If you go to Map School you will learn about all the different kinds of maps: road maps, traffic congestion maps, elevation maps, mineral maps, building maps, etc. etc. etc. After spending all this time in Map School, a plebian road map will "feel" too sparse to you. But that's because you are forgetting the audience and the purpose of the map. Some may characterize such a mistake as the "Anal Academic Mode" stereotype. -t

If the writing is poor, the writing can be fixed. That doesn't warrant a new "model".

Then fix it.

I'm not the one who has a problem with it. I have it on anecdotal evidence that my students don't have a problem with it either -- I use a description like that at the top of TypeSystemCategoriesInImperativeLanguages to help introduce students to the distinctions between static and dynamically-typed languages, and they grasp it readily. I have it on circumstantial evidence that the majority of programmers don't have a problem with it, as it's a conventional explanation using conventional terminology that's been in use since the 1960s, so millions of programmers must have encountered the conventional explanation in one way or another, yet no alternative explanation has emerged. Surely, if it was common to have difficulty with it, at least one alternative explanation would have become not only recognised, but popular. However, until your "tag model", I'd never seen an alternative explanation. I've still not seen a justification that an alternative explanation -- or a better-written explanation -- is needed. So, it seems it's just you who has a problem with it. Therefore, if you have a problem with it, perhaps you might take a stab at rewriting it. I recommend using conventional terminology, of course, unless you're prepared to justify your use of unconventional terminology and go to an appropriate effort to explain it.

We've been over this ground already. I see nothing new here. My experience with programmers in the field differs from yours. Let's leave it at that.

Lossy?

And perhaps the tag model is "lossy" for certain situations. I have not seen such specifically identified so far, but am willing to sacrifice some accuracy to keep the model simple and easy to remember. The amount of sacrifice depends: it's about weighing the trade-off such as deciding whether adding elevation info to a map will distract from reading the road info. Do we try to build every contingency and exception into the model, or just add descriptive footnotes about the rough spots? It could be compared to Newtonion physics versus Einsteinian physics. The Newtonian model may be plenty sufficient for a given intended use, such as building a bridge, but not if you are calculating the orbit of Mercury (which is relativistically slowed by "drag" from the sun's mass). -t

There's no need to "sacrifice some accuracy to keep the model simple and easy to remember". The description of language behaviour in terms of types, variables and values is simple -- it has exactly the same elements of your "tag model", without the need to introduce any "tags" -- and is accurate.

Bull.

A response like "bull" is almost invariably a shorthand for "You're right, and I have no counter-argument but I don't like the fact that I'm losing the debate so I'm going to dismiss it abruptly rather than face the humiliation of backing down." In actuality, backing down from an insurmountable argument is a sign of intellectual strength. Rather than being humiliating, it is ennobling, and a potent demonstration of maturity and professionalism. It earns respect. Sometimes, one of the most powerful and elevating thing you can say is, "You're right and I was wrong."

I'd like to think the best of you, so I'll assume that's what you really meant when you wrote "Bull."

You offered no new claims, so I gave a concise summary reply rather than re-paste the entire wheel. I know you think your model is simple, clear, accurate, and lovely. That's not news.