One may claim that WeakProgrammersRelyOnBadDocumentation. This is often true. One may claim that this is because they do not have or cannot find better documentation. This is questionable.

Original claim:

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

* 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.'' -t

** ''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.''

** Reply is below near 'The kind of or pool of "rules"'. The text got scrambled somehow. -t

* {As much as this is the point of dynamic typing, I find it most convenient to treat all dynamic typed languages as DuckTyped or StringTyped and get really annoyed when the language is neither.}

* {As for the original topic, As far as I can tell, TripleEquals (===) was in Javascript from the beginning but all the early documents that I learned from never discussed it. JavaScript is in fact duck typed, but string identity is just important enough that === needs to exist. How is the programmer to discover that the natural == doesn't work on edge cases? Back in the day, I knew the documentation was lacking but not so much as how to find the solution.} --JoshuaHudson

* 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. -t

* ''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. Related: LearnPatternsIfLogicNotFound. -t

* Sometimes one can avoid ugly or bloated work-arounds if they know how the language actually "works". For example, I often see this ugly pattern: "x = toNumber(a) + toNumber(b) + toNumber(c) + toNumber(d);". This is done to prevent a rogue "stringy number" from forcing it to concatenation instead of addition. If one has a better knowledge of how types are processed in a given language, they may be able to shorten it to "x = a + b + c + d;", making the code shorter and easier to read. -t

** {This is why JavaScript's use of + for both add and concatenate is bad. PHP, which was misguided in so many ways at least got this one right.}

*** I agree about such overloading being poor language design (but wish Php used a different symbol, leaving "." for object paths). However, developers are generally stuck using the language of the shop and have to work with imperfectly designed languages (or the downsides of related design tradeoffs). '''If you have to live with goofiness, it's good to be able to model/predict the goofiness.''' -t

** 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.''

** ''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.) -t

* ''The "tag model" provides an erroneous "how it works" model.  As a developer of interpreters and compilers, I know your "tag model" is not how it works.''

** And granted, different people remember info in different/preferred ways. I don't promise that everybody will favor the tag model. I estimate some will like it, but it's only an estimate, just like any of your preference estimations about your model. AnecdoteImpasse. [Context damaged]

* The tag model is not intended to model production implementation "guts", only "results" (IoProfile). -t

* ''The only thing that can model the "results" of a program in language <x> is an interpreter or compiler for language <x>.  Are you now claiming that the "tag model" for Python is a Python interpreter, and the "tag model" for Perl is a Perl interpreter, and the "tag model" for Java is a Java compiler?''

* In a sense, yes. (We've been over this already somewhere.) We are limiting what we are modelling to keep the model simple because we are only exploring type-related issues (for scalars for now), but if built "full out", it would indeed be an interpreter for the target language, although probably not a fast one. (It doesn't address compilers.)

{Here is what I have seen. WeakProgrammersRelyOnBadDocumentation for two reasons. First, they aren't good enough to be able to tell good documentation from bad. (WeakProgrammersWriteBadDocumentation too, but that's another story). So they use something like the first document they can find. Second, when carrying out a really bad practice and caught in it, they will sometimes seek out some supporting documentation for their behavior. Nevermind the large amount of contrary documentation, nor the fact that "would I expect somebody to use my library this way" kind of reasoning would immediately show the error of this behavior. We had one programmer who believed that he could change the sort key in objects inserted into a Sorted''''''List object (he implemented IComparable in such a way that compare results could change based on other calls) and kept arguing the code should work. Seemed to think it was listening for the P''''''ropertyChanged event on every object in the collection or something.}

{You think that's bad? How about this? I encountered a fairly good programmer having trouble understanding that library component X does not handle the split-mind problem when the documentation implied that it did despite the fact that a little bit of reasoning would reveal that it is not placed in an appropriate place that would permit it do so (wrong side of the network pipe). The split-mind resolutions are inflexible. See CrashOnlySoftware. A weak programmer would certainly have believed the document as written.}

Almost every programmer probably at one time or another has a really bad idea about something specific. Sometimes this is called a "brain fart". Humans are imperfect, even the most skilled and experienced. I don't think much should be made about one case of brain farting. Related: NarrowStaffSelectionFactors

----
[Phantom claim that WeakProgrammers are weak because they rely on bad documentation]

{I seriously doubt it. The class of weak programmers is probably not homogeneous enough to make such a sweeping generalization about (other than those that are directly a result of being weak programmers).}

''My experience of weak programmers -- and weak students who become weak programmers -- is that they avoid documentation, tending to code by experimentation at best, and  haphazardly at worst.  Good programmers read frequently and widely, and the best of them read critically to select the strongest references.''

As I mentioned before, this is an '''over-simplification'''. People learn better from different kinds of presentation techniques. There are many ways to skin a mental cat. Some hate all documentation and use trial and error, some like and remember well "typical" documentation (such as the Unleashed series), but don't like academic-oriented documentation. A smaller group is fine with academic-oriented documentation. The latter group is roughly about '''10% of the programmers''' I encounter in the field. That's honestly what it looks like in my shoes as best I can describe it. A ''dedicated'' "software shop" my be different, but I've only briefly contracted at such. The academic proportion seems to be very roughly 30% in those, probably because "business knack", domain experience, and people skills are favored less in proportion, which magnifies the hiring focus on technical and academic skills. (I tend to not prefer dedicated shops because I prefer being more of a generalist, including business analysis (feasibility) and UI design, which would be a dedicated specialty in a dedicated shop.)  -t

----
JanuaryFourteen