Mentally Manage Dynamic Types

Continued from ValueExistenceProofTwo (was WeakProgrammersRelyOnBadDocumentation)

It's not hard to get confused over dynamic typing because of the horrid writing about it out there.

Speak for yourself.

If you think your writing is clear to most, you are truly delusional.

What does that have to do with what I wrote? You're claiming it's "not hard to get confused over dynamic typing because of the horrid writing about it". That implies that it's easy to get confused about dynamic typing. I see no evidence that this is so; it appears to be nothing more than a personal opinion. If it's nothing more than a personal opinion, then you should make it clear that it's your own opinion, and not necessarily anyone else's. It certainly isn't mine. Whilst I agree that there's a lot of bad documentation, it is no hindrance to understanding popular imperative dynamically-typed programming languages. They are trivially simple. Given the number of programmers successfully writing programs -- including children of single-digit ages successfully programming RaspberryPis and the like -- it seems bad writing is no hindrance to understanding dynamically-typed imperative programming languages.

We've been over this many times already repeatedly and redundantly. It's my personal observation about typical programmers, and apparently it differs from your personal observation about programmers. It's an AnecdoteImpasse. Your life is not the standard reference source for universal truth.

Re: "you should make it clear that it's your own opinion" -- I made it clear it was my personal observation multiple times. If you forgot that and mistook it for an official study due to your forgetfulness, it's not my goddam fault. Get some Reagan meds for it. You seem to be mistaking your lack of memory for lack of existence. On the upside, you don't have to buy new magazines because the same one can be reused every week and always seem fresh to you.

Whilst I can certainly remember the few times you've agreed that it's merely your own observation, and by no means a general condition, it's unlikely the casual WikiReader will assemble your collected unsigned writings into a cohesive statement of your views. Therefore, when you write, "[i]t's not hard to get confused over dynamic typing because of the horrid writing about it out there," it has all the appearances of a statement of truth when it is not.

And I've pointed out many times with dynamic languages it's usually easy to "spot fix" specific problems encountered without having a fuller understanding of the underlying TypeSystem of a specific language. I've done so myself with newly encountered languages. The practical differences are usually somewhat subtle such that one can get by just fine with general and rough notions of various dynamic typing approaches of various dynamic languages. A rigorous understanding of a particular language's dynamic TypeSystem is thus NOT necessary to be productive. Your implication appears to be "they are productive in the language, therefore they have a rigorous understanding of its type system". That's false logic.

The TypeSystem implementations of popular imperative programming languages, including the DynamicallyTyped ones, are trivially simple. I can only attribute an apparent lack of understanding, in an otherwise capable programmer, to laziness.

The kind of or pool of "rules" (techniques) they tend to use are indeed relatively simple, HOWEVER, the implementation profile is not. It's almost like saying binary numbers are simple because they only have "1" and "0". However, knowing when/what/where the "1" is used instead of a "0" can be a bear. One cannot know the behavior of each operator just by looking at the basic operator description or guessing based on the operator name using experience from similar languages. For example, it's not easy to know whether each operator uses type-tag based (explicit type indicator) or parse-based dispatching/selection-of type-related behavior. And then there are inconsistencies such as Php's is_number() versus is_bool() where one uses what I call "parse-based" typing and the other uses what I call "tag based" typing. And some languages like ColdFusion don't have (detectable) type tags at all for scalars.

That's some fine molehill mountaineering you've done there. This is all trivial stuff, it's even well-explained on a function-by-function basis in the otherwise-dire PHP manual, and also described in TypeSystemCategoriesInImperativeLanguages. There's no need for constructing new terminology like 'parse-based typing' and 'tag based typing' -- all values have a type, and some operators in some languages rely on the fact that a literal of one type can encode literals of other types. That accounts for "inconsistencies such as Php's is_number() versus is_bool()" and why what you describe as, "languages like ColdFusion don't have (detectable) type tags at all for scalars", is simply the fact that in ColdFusion all values are strings so they can encode any literal of any type.

In my personal observations and casual conversations with field programmers, the vast majority don't use any rigorous model to know/remember which technique a given operator uses. A good portion of the time it "just works" because tag-based and parse-based ACT very similar under typical usage patterns. And if problems or confusion is encountered, one can "shore up" related code by putting in explicit validation at the form (data source), or wrap variables/expressions with explicit conversion operations, such as Round() or toNumber(), depending on the language or circumstance. One can "organically deal with them" to get work done: knowledge of a clear model is NOT necessary to get work done[1]. Still, it's nice to have an explicit model and know the "tag profile" of each operator of a given language. The manuals are poor at providing this info, and you agreed that at least Php did a poor job at such. -t

Why do you believe your "tag model" will make language quirks any less quirky, or any less likely to be worked around in the usual fashion by typical programmers?

Further, the dynamic language designers themselves don't seem to give type issues much thought, creating unnecessary inconsistencies and confusion, such as overloading "+", the is_number versus is_bool inconsistency in Php, and the excessive number of screwy non-printable null-like "characters" in JavaScript. -t

I suspect dynamically typed language designers have enough programming experience to not bother giving these negligible "type issues" any thought beyond documenting them as appropriate (e.g., the "is_number versus is_bool inconsistency in Php"), or they regard them as handy shortcuts (e.g., overloading '+') for experienced programmers rather than pitfalls for weak programmers. I can't justify the Javascript type system -- it is full of quirks -- but you get used to them. I suppose they're not surprising, given that the first implementation of Javascript was hacked together in 10 days.

I don't see how overloading "+" is a "handy shortcut". A different concatenation operator can take up just as little space (such as Microsoft's and ColdFusion's "&". Php's "." should have been reserved for object pathing in my opinion.) Using an overloaded "+" was probably just a pseudo-clever fad to make one feel they are skilled OO'ers, the big fad of late 90's. One can always claim that people confused by odd features are "weak", but one must ask if the "problem feature" is really necessary, or just a quirk of happenstance. I suspect most language designers did not give much thought and vetting to their dynamic typing design, copying "in" fads instead. That's human nature.

Overloading "+" is certainly a handy shortcut when you have various numeric types and wish to make it easy to intermix them.

Sure, for numbers, but not for strings. (Dynamic languages don't really need to make a distinction between Integer, Real, Double, etc. for their typical usage. Sometimes we need to check for integer-ness for form validation, but it doesn't have to be an explicit type. In fact, I'd argue that "max decimals" is a more flexible validation function/check, and can be used to check for (interpret-able) integer-ness. In my opinion they should use some kind of decimal-based computations as described in FloatingPointCurrency. It would probably be slower than the current approaches, though, and not act that much different from the current approaches the vast majority of the time.)

I think this is wandering well OffTopic.


Footnotes:

[1] The environments where dynamic languages are used are generally not "fragile" enough that occasional type-related confusion-caused bugs results in significant damage. Bugs are fixed as encountered. In a domain/project where lack of app bugs really matters, one should probably use a strong- and staticly-typed language. However, development productivity is often slower under such languages, and some argue they are not as flexible to change. Fastidiousness is not cost-free. The loose nature of JavaScript's typing makes it ill-suited as a SystemsSoftware language for web-GUI sub-systems, creating many of the browser GUI headaches out there. An explicitly typed language would be better suited for such use. JavaScript is sufficient as a "glue language" for browser objects/parts, but not the guts.


JanuaryFourteen


EditText of this page (last edited January 7, 2014) or FindPage with title or text search