178

I'm reading a slide deck that states "JavaScript is untyped." This contradicted what I thought to be true so I started digging to try and learn more.

Every answer to Is JavaScript an untyped language? says that JavaScript is not untyped and offered examples of various forms of static, dynamic, strong, and weak typing that I'm familiar and happy with.. so that wasn't the way to go.

So I asked Brendan Eich, the creator of JavaScript, and he said:

academic types use "untyped" to mean "no static types". they are smart enough to see that values have types (duh!). context matters.

Do academically-focused computer science folks use "untyped" as a synonym of "dynamically typed" (and is this valid?) or is there something deeper to this that I am missing? I agree with Brendan that context is important but any citations of explanations would be great as my current "go to" books are not playing ball on this topic.

I want to nail this down so I can improve my understanding and because even Wikipedia doesn't refer to this alternative usage (that I can find, anyway). I don't want to mess up with either using the term or questioning the use of the term in future if I'm wrong :-)

(I've also seen a top Smalltalker say Smalltalk is "untyped" too, so it's not a one-off which is what set me off on this quest! :-))

Community
  • 1
  • 1
Peter Cooper
  • 2,907
  • 28
  • 67
  • 87
  • 6
    Others' misuse of nomenclature does not have to shape your habits -- just use the (more) correct phrase. You have to be aware of the issue for reading, obviously. – Raphael Feb 06 '12 at 11:30
  • 2
    I always took it as, the _variables_ are untyped in that any variable can hold any type of data. The type of what is in the variable can change _dynamically_. – Izkata Feb 06 '12 at 17:52
  • https://en.wikipedia.org/wiki/Type_system – noobninja Jun 05 '16 at 16:14
  • 1
    Also (again saying more about natural language than computer languages) "untyped" = "single-typed" (one type for all values). – philipxy Oct 15 '16 at 04:37

9 Answers9

157

Yes, this is standard practice in academic literature. To understand it, it helps to know that the notion of "type" was invented in the 1930s, in the context of lambda calculus (in fact, even earlier, in the context of set theory). Since then, a whole branch of computational logic has emerged that is known as "type theory". Programming language theory is based on these foundations. And in all these mathematical contexts, "type" has a particular, well-established meaning.

The terminology "dynamic typing" was invented much later -- and it is a contradiction in terms in the face of the common mathematical use of the word "type".

For example, here is the definition of "type system" that Benjamin Pierce uses in his standard text book Types and Programming Languages:

A type system is a tractable syntactic method for proving the absence of certain program behaviors by classifying phrases according to the kinds of values they compute.

He also remarks:

The word “static” is sometimes added explicitly--we speak of a “statically typed programming language,” for example--to distinguish the sorts of compile-time analyses we are considering here from the dynamic or latent typing found in languages such as Scheme (Sussman and Steele, 1975; Kelsey, Clinger, and Rees, 1998; Dybvig, 1996), where run-time type tags are used to distinguish different kinds of structures in the heap. Terms like “dynamically typed” are arguably misnomers and should probably be replaced by “dynamically checked,” but the usage is standard.

Most people working in the field seem to be sharing this point of view.

Note that this does not mean that "untyped" and "dynamically typed" are synonyms. Rather, that the latter is a (technically misleading) name for a particular case of the former.

PS: And FWIW, I happen to be both an academic researcher in type systems, and a non-academic implementer of JavaScript, so I have to live with the schisma. :)

Andreas Rossberg
  • 34,518
  • 3
  • 61
  • 72
  • 5
    It *is* very helpful and may even be my favorite answer in terms of providing some history to it. – Peter Cooper Feb 06 '12 at 23:01
  • 2
    @PeterCooper btw you might be interested to know that one major branch of formal semantics is predicated (ha a pun) on typed lambda calculi; e.g. Montague Semantics. But as a declarative, non-generative system I've personally always compartmentalized the typing in systems like Montague Semantics away from typing in programming languages. – knowtheory Feb 08 '12 at 22:12
  • 1
    +1. `"[dynamically typed] is a (technically misleading) name for a particular case of [untyped]"` – Steve Feb 13 '12 at 02:09
  • 1
    This isn't quite correct about the history of "types". They're even older than Church's work on the lambda-calculus. Russell used types to avoid paradoxes in the construction of set theory. – Sam Tobin-Hochstadt Apr 12 '13 at 12:52
  • 1
    @SamTobin-Hochstadt, yes, right. I only talked about the part of the history that directly concerns the foundations of PLs. I'll clarify. – Andreas Rossberg Apr 12 '13 at 16:24
  • I don't quite understand why saying 'dynamically typed' is a misnomer here. Sure, it is dynamically checked at run-time, but it is also dynamically typed. A variable x (in JS) can be labelled as a Number and then later on labelled as a String. How is the term 'dynamically typed' not a good descriptor of this behavior? Is it because x is only a reference to something that could either be a Number OR a String? And that the type checker checks those things being referred to and not x itself? And that x itself is not typed? Oooh... I think I get it. – Yousif Al-Y Jul 13 '15 at 14:50
74

I am an academic computer scientist specializing in programming languages, and yes, the word "untyped" is frequently (mis)-used in this way. It would be nice to reserve the word for use with languages that don't carry dynamic type tags, such as Forth and assembly code, but these languages are rarely used and even more rarely studied, and it's a lot easier to say "untyped" than "dynamically typed".

Bob Harper is fond of saying that languages like Scheme, Javascript, and so on should be considered typed languages with just a single type: value. I lean to this view, as it makes it possible to construct a consistent worldview using just one type formalism.

P.S. In pure lambda calculus, the only "values" are terms in normal form, and the only closed terms in normal form are functions. But most scientists who use the lambda calculus add base types and constants, and then you either include a static type system for lambda or you are right back to dynamic type tags.

P.P.S. To original poster: when it comes to programming languages, and especially type systems, the information on Wikipedia is of poor quality. Don't trust it.

Xavi
  • 20,111
  • 14
  • 72
  • 63
Norman Ramsey
  • 198,648
  • 61
  • 360
  • 533
  • 14
    I think there’s a broader issue in CS (including academia) that names are used without rigorous definition. This is in stark contrast to mathematics and (most?) sciences. A huge number of disputes (e.g. about OOP) seems to stem from this lack of proper definitions. Very annoying. – Konrad Rudolph Feb 06 '12 at 12:10
  • 2
    @KonradRudolph: I wonder if, rather than the disputes arising from the lack of proper definitions, the lack of proper definitions might arise in part from the disputes. Some terms acquire an emotional valence (be it positive or negative), and supporters of specific languages then define those terms in ways that include or exclude their languages (and exclude or include their favorite "enemy" languages). For a math example -- if there were still people supporting naive set theory over axiomatic set theory, you can be sure they would call their own views "axiomatic set theory" and define "naive – ruakh Feb 06 '12 at 16:16
  • 1
    set theory" in some narrower way that excluded themselves. – ruakh Feb 06 '12 at 16:17
  • 4
    @Norman, I am surprised you call it misuse -- as you know, the notion of type predates so-called dynamically typed languages by decades, and what the latter call "type" has little to do with the former. So I think it's fair to say that the misuse is the other way round. – Andreas Rossberg Feb 06 '12 at 19:41
  • types: a range of values acceptable by defintion (an int is 2,147,483,647 to -2,147,483,648). A type, in OO can also be a composition or modification of a previously defined type. In this way, a type is, to some degree, available in all language systems. I'm paraphrasing Chris Date's definition of "type" here. – Josh Robinson Feb 07 '12 at 17:45
  • 5
    @Norman: When it comes to programming languages, and especially type systems, if you feel the information on Wikipedia is of poor quality, don't leave it alone and improve it. (just trolling) – Gyom Feb 08 '12 at 06:53
  • 3
    @Gyom I gave up improving Wikipedia the day I realized that the Wikipedian process rewards *change*, not *expertise*. My time is better spent improving SO :-) – Norman Ramsey Feb 10 '12 at 03:46
  • @KonradRudolph this is a very broad problem in computer science---things tend to get named before we understand them. One of my favorite examples is "compiler". And my favorite data structure is called "hash", "table", "dictionary", "associative array", and probably some other things I can't remember right now. I've learned to live with it. – Norman Ramsey Feb 10 '12 at 03:47
  • @NormanRamsey: ..and you're very welcome to do so ! (thanks for this interesting viewpoint on WP. now I'm gonna have to think about it !) – Gyom Feb 10 '12 at 09:38
  • @NormanRamsey (Hi Professor Ramsey! CS152 was great. Take a look [here](http://stackoverflow.com/questions/15148425/class-specialization-a-valid-transformation-for-a-conforming-compiler) if you get a chance?)--this is old but do you think what you said about WP is the same as what any academic expert in a field would say about articles in their field of expertise, or is the PL stuff objectively worse? – Stephen Lin Mar 01 '13 at 05:39
  • @StephenLin I think the PL stuff is objectively worse, as compared with, say, math stuff like well-founded induction. – Norman Ramsey Mar 10 '13 at 02:22
  • 1
    @Gyom I think you're overstating the inaccuracy of wikipedia a bit. Academia has it's own problems... A wise practitioner can see through the dazzling BS of academia and see past the inaccuracies of wikipedia to build a better understanding. – Sprague Nov 21 '13 at 10:54
  • Outside of academia, I have seen "untyped" used to refer to things like B and assembly, as you mention. I much prefer this usage, and it seems to be common outside of academia (at least when people are talking with any level of rigour). – CoffeeTableEspresso Apr 17 '19 at 00:08
44

I've looked into it, and found that the answer to your question is simply, and surprisingly, "yes": academic CS types, or at least some of them, do use "untyped" to mean "dynamically typed". For example, Programming Languages: Principles and Practices, Third Edition (by Kenneth C. Louden and Kenneth A. Lambert, published 2012) says this:

Languages without static type systems are usually called untyped languages (or dynamically typed languages). Such languages include Scheme and other dialects of Lisp, Smalltalk, and most scripting languages such as Perl, Python, and Ruby. Note, however, that an untyped language does not necessarily allow programs to corrupt data—this just means that all safety checking is performed at execution time. […]

[link] (note: bolding in original) and goes on to use "untyped" in just this way.

I find this surprising (for much the same reasons that afrischke and Adam Mihalcin give), but there you are. :-)

Edited to add: You can find more examples by plugging "untyped languages" into Google Book Search. For example:

[…] This is the primary information-hiding mechanism is many untyped languages. For instance PLT Scheme [4] uses generative structs, […]

— Jacob Matthews and Amal Ahmed, 2008 [link]

[…], we present a binding-time analysis for an untyped functional language […]. […] It has been implemented and is used in a partial evaluator for a side-effect free dialect of Scheme. The analysis is general enough, however, to be valid for non-strict typed functional languages such as Haskell. […]

— Charles Consel, 1990 [link]

By the way, my impression, after looking through these search results, is that if a researcher writes of an "untyped" functional language, (s)he very likely does consider it to be "untyped" in the same sense as the untyped lambda calculus that Adam Mihalcin mentions. At least, several researchers mention Scheme and the lambda calculus in the same breath.

What the search doesn't say, of course, is whether there are researchers who reject this identification, and don't consider these languages to be "untyped". Well, I did find this:

I then realized that there is really no circularity, because dynamically typed languages are not untyped languages — it's just that the types are not usually immediately obvious from the program text.

— someone (I can't tell who), 1998 [link]

but obviously most people who reject this identification wouldn't feel a need to explicitly say so.

ruakh
  • 175,680
  • 26
  • 273
  • 307
  • Exactly the sort of citation I was looking for, thanks! Kinda scares me that the book has an average of 2 stars on Amazon though so more citations welcomed, but this is a great start. – Peter Cooper Feb 06 '12 at 03:56
  • @PeterCooper: I've edited my answer to add more citations. They circumvent the Amazon-ratings problem by being from published papers: for all I know, they still might be trash, but at least we don't have to worry about Amazon telling us so. :-P – ruakh Feb 06 '12 at 04:21
  • Confusing "untyped" with "dynamically typed" is illogical. Developers should not be illogical. – rotman Feb 07 '12 at 19:56
10

Untyped and dynamically typed are absolutely not synonyms. The language that is most often called "untyped" is the Lambda Calculus, which is actually a unityped language - everything is a function, so we can statically prove that the type of everything is the function. A dynamically typed language has multiple types, but does not add a way for the compiler to statically check them, forcing the compiler to insert runtime checks on variable types.

Then, JavaScript is a dynamically typed language: it is possible to write programs in JavaScript such that some variable x could be a number, or a function, or a string, or something else (and determining which one would require solving the Halting Problem or some hard mathematical problem), so you can apply x to an argument and the browser has to check at runtime that x is a function.

Adam Mihalcin
  • 14,242
  • 4
  • 36
  • 52
  • AFAIK The same problems apply to a Lambda expression. While you may be able to pass a function for "my current position" into a function that calculates "my distance from target" you could also pass the same "my current position" function into a function that calculates "are puffs plus with vicks better for your nose". Just because you can doesn't mean it's valid - as is the case with any dynamic system. – Steve Feb 06 '12 at 01:40
  • 5
    @Steve Garbage in garbage out is the case for any programming language though, and is unrelated to the notion of types. Even in a strongly typed language like OCaml or SML I can pass the North Pole into a function that calculates "my distance from target" (and no, my current position is not the North Pole). – Adam Mihalcin Feb 06 '12 at 03:20
  • 1
    Just wanted to add, for people outside of academia: stuff like assembly would also count as untyped. – CoffeeTableEspresso Apr 17 '19 at 00:10
  • The original lambda calculus is untyped in that its formalisms have no references to types. It is possible to formulate the system as unityped, which is a valid point of view, but the original formulations make no references to types whatsoever. – Keith Pinson Nov 06 '20 at 17:19
7

Both statements are correct, depending on whether you are talking about values or variables. JavaScript variables are untyped, JavaScript values have types, and variables can range over any value type at runtime (i.e. 'dynamically').

In JavaScript and many other languages, values and not variables carry types. All variables can range over all types of values and may be considered "dynamically typed" or "untyped" - from the perspective of type-checking a variable that has no/unknowable type and a variable that can take any type are logically and practically equivalent. When type theorists talk about languages and types, they are usually talking about this - variables carrying types - because they are interested in writing type checkers and compilers and so on, which operate on program text (i.e. variables) and not a running program in memory (i.e. values).

By contrast in other languages, like C, variables carry types but values do not. In languages like Java, variables and values both carry types. In C++, some values (those with virtual functions) carry types and others do not. In some languages it is even possible for values to change types, although this is usually considered bad design.

  • 6
    I think the key distinction is not between values and *variables*, but between values and *expressions*: In a statically-typed language, expressions have types, whereas in a dynamically-typed language, only values do. (Variable-names are one kind of expression, of course.) – ruakh Feb 06 '12 at 17:56
5

While it is true that most of the CS researchers that write about types essentially consider only languages with syntactically-derivable types as typed languages, there are lots more of us using dynamically/latently typed languages who take umbrage at that usage.

I consider there to be 3 types [SIC] of languages:

Untyped - only the operator determines the interpretation of the value - and it generally works on anything. Examples: Assembler, BCPL

Statically typed - expressions/variables have types associated with them, and that type determines the interpretation/validity of the operator at compile-time. Examples: C, Java, C++, ML, Haskell

Dynamically typed - values have types associated with them, and that type determines the interpretation/validity of the operator at run-time. Examples: LISP, Scheme, Smalltalk, Ruby, Python, Javascript

To my knowledge, all dynamically-typed languages are type-safe - i.e. only valid operators can operate on values. But the same is not true for statically-typed language. Depending on the power of the type system used, some operators may be checked only at run-time, or not at all. For example, most statically-typed languages do not handle integer overflow properly (adding 2 positive integers can produce a negative integer), and out-of-bound array references are either not checked at all (C, C++) or are checked only at run-time. Further, some type systems are so weak that useful programming requires escape hatches (casts in C and family) to change the compile-time type of expressions.

All of this leads to absurd claims, such as that C++ is safer than Python because it's (statically-typed), whereas the truth is that Python is intrinsically safe while you can shoot your leg off with C++.

Dave Mason
  • 669
  • 6
  • 15
  • Upvoted. Glad to know "all dynamically-typed languages are type-safe". "But the same is not true for statically-typed language", do you mean that all or most statically-typed languages are type-unsafe? – Tim Sep 22 '16 at 04:11
  • Upvoted. (1) Glad to know "all dynamically-typed languages are type-safe", but Javascript is dynamic typed and weak typed, see http://stackoverflow.com/questions/964910/is-javascript-an-untyped-language. (2) "But the same is not true for statically-typed language", do you mean that all or most statically-typed languages are type-unsafe? – Tim Sep 22 '16 at 05:52
  • Very few languages are statically type-safe, if you include the possibility of cast failure, subscript-out-of-bounds, or null-pointer exceptions as types (and most people do include at least cast failure as a type error). Rust, for example, is more statically type-safe than Java because you cannot have a null pointer. Java is dynamically type-safe in that you get exceptions for any illegal operation and everything is specified (except for native methods). Similarly Rust (excepting "unsafe" code which is so-designated). – Dave Mason Jan 31 '17 at 20:34
  • However, C++, C are not even dynamically type-safe because there are "unspecified" parts of the language, and if you do one of the "unspecified" operations, literally *anything* is a legal response from the language (values of unrelated variables could change, viruses could infect your program, the program could write all over your disk and then crash, the program could even do what you expected :-). – Dave Mason Jan 31 '17 at 20:34
  • @DaveMason: Undefined. There is an ***enormous*** difference between "unspecified" and "undefined" in C. Undefined behavior is basically illegal things that can do what you've described --- while unspecified essentially means "implementation-defined where implementation doesn't have to document it" (there are some nuances here and there, so this *is* a simplification). Invoking *unspecified* behavior is thus perfectly legal (in fact, one does so whenever ones writes, say, a function call). – Tim Čas Jun 04 '17 at 12:06
  • I disagree with the cited contention that Javascript is weak typed. All operations on values are defined. There is no possibility of a core dump. If you want to read more, I suggest [this](http://blogs.perl.org/users/ovid/2010/08/what-to-know-before-debating-type-systems.html) - it's not perfect, but it's much more nuanced and complete. @TimCas You are correct that the C99 standard defines unspecified/undefined/implementation-defined separately, but they are all in what I refer to as "unspecified" above. e.g. writing function calls that depend on the order of parameter evaluation. – Dave Mason Jun 06 '17 at 04:57
  • @DaveMason: You're mixing up language safety and the "strength" of a typing discipline. Hell, look at your own damn link. – Tim Čas Jun 06 '17 at 19:10
  • It's worth noting that some of the languages you list as "statically typed" also satisfy your definition of "dynamically typed"; for example, in Java, every object has what Java calls a "runtime-type", meaning a specific class that it belongs to. So your real definition of "dynamically typed" seems to be your stated definition *plus* the constraint that the language *not* be "statically typed". So, dynamic typing is a special case of lack of static typing; and when you look at it that way, the academic-CS perspective suddenly makes more sense. – ruakh Jan 21 '22 at 21:36
4

This question is all about Semantics

If I give you this data: 12 what is it's type? You have no way of knowing for sure. Could be an integer - could be a float - could be a string. In that sense it's very much "untyped" data.

If I give you an imaginary language which lets you use operators like "add", "subtract", and "concatenate" on this data and some other arbitrary piece of data the "type" is somewhat irrelevant (to my imaginary language) (example: perhaps add(12, a) yields 109 which is 12 plus the ascii value of a).

Let's talk C for a second. C pretty much lets you do whatever you want with any arbitrary piece of data. If you're using a function that takes two uints - you could cast and pass anything you want - and the values will simply be interpreted as uints. In that sense C is "untyped" (if you treat it in such a way).

However - and getting to Brendan's point - if I told you that "My age is 12" - then 12 has a type - at least we know it's numeric. With context everything has a type - regardless of the language.

This is why I said at the beginning - your question is one of semantics. What is the meaning of "untyped"? I think Brendan hit the nail on the head when he said "no static types" - because that's all it can possibly mean. Humans naturally classify things into types. We intuitively know that there is something fundamentally different between a car and a monkey - without ever being taught to make those distinctions.

Getting back to my example in the beginning - a language that "doesn't care about types" (per-se) may let you "add" an "age" and a "name" without producing a syntax error... but that doesn't mean it's a logically sound operation.

Javascript may let you do all sorts of crazy things without considering them "errors". That doesn't mean what you are doing is logically sound. Thats for the developer to work out.

Is a system/language which doesn't enforce type safety at compile/build/interpretation time "untyped" or "dynamically typed"?

Semantics.

EDIT

I wanted to add something here because some people seem to be getting caught up on "yeah, but Javascript does have some "types"".

In my comment on someone else's answer I said:

In Javascript I could have objects I've built up to be "Monkeys" and objects I've built up to be "Humans" and some functions could be designed to operate on only "Humans", others on only "Monkeys", and yet others on only "Things With Arms". Whether or not the language has ever been told there is such a category of objects as "things with arms" is as irrelevant to assembly ("untyped") as it is to Javascript ("dynamic"). It's all a matter of logical integrity - and the only error would be using something that didn't have arms with that method.

So, if you consider Javascript to have some "notion of types" internally - and, hence "dynamic types" - and think this is somehow "distinctly different from an untyped system" - you should see from the above example that any "notion of types" it has internally is really irrelevant.

To perform the same operation with C#, for example, I'd NEED an interface called ICreatureWithArms or something similar. Not so in Javascript - not so in C or ASM.

Clearly, whether or not Javascript has any understanding of "types" at all is irrelevant.

Steve
  • 31,144
  • 19
  • 99
  • 122
  • 5
    -1. The question asks if a certain word is used, in certain circles, with a certain meaning, and your response is to explain that it's a question of whether the word has that meaning? Really, I think you've done an admirable job explaining everything that the OP already seems to know, without adding anything new at all . . . – ruakh Feb 06 '12 at 01:15
  • It seems there are several questions necessary to build a definition, perhaps? That of type enforcement (static or dynamic) and the presence of defined types. So JavaScript has types but can be considered "untyped" due to its lack of checking type validity prior to performing an operation? – Peter Cooper Feb 06 '12 at 01:18
  • @ruakh - I can understand your perspective. However, the OP asked: `is there something deeper to this that I am missing` and, I think, that failure to understand that it's a semantic issue is the deeper thing - so I did my best to chip in whatever tidbit I could. – Steve Feb 06 '12 at 01:18
  • @PeterCooper - See my edit and tell me if that adds anything for you (since you said `JavaScript has types` in your reply). – Steve Feb 06 '12 at 01:24
  • I think so. I need to let it sink in and re-read it a bit :-) One big impression I'm getting from reading these answers (and others about it on SO) is it's a bit of a slippery, vague term (hence semantics) and anyone using it would be well advised to clarify what they mean if the context isn't totally clear :-) – Peter Cooper Feb 06 '12 at 01:29
  • 2
    'Clearly, whether or not Javascript has any understanding of "types" at all is irrelevant.' Not true. As I hinted at in my answer, no matter what the context, you can't treat 12 as a function. Since JavaScript does have a function type (or, depending on your point of view, multiple function types), this is an important distinction. – Adam Mihalcin Feb 06 '12 at 03:14
  • A little more on my previous comment: Just because JavaScript doesn't have interfaces or C++/Java/.NET-style classes doesn't mean it doesn't have types. – Adam Mihalcin Feb 06 '12 at 03:21
  • By your EDIT's example's logic, you could take the `head` function for lists (returns first element), which is defined on any (non-empty) list. In Haskell, its type is `forall a. [a] -> a`. However, `head []` will fail (throw a runtime error). There are (dependently typed) languages, where you can define `head` to be usable only on non-empty lists. Thus, generalizing your example, for any language that allows programs that 'may crash at runtime', any "notion of types" is has internally is irrelevant. So clearly, whether or not Haskell has any understanding of "types" at all is irrelevant. ;-) – nobody Feb 06 '12 at 21:49
3

I am not a computer scientist, but I would be rather surprised if "untyped" were really used as a synonym for "dynamically typed" in the CS community (at least in scientific publications) as imho those two terms describe different concepts. A dynamically typed language has a notion of types and it enforces the type constraints at runtime (you can't for example divide an integer by a string in Lisp without getting an error) while an untyped language doesn't have any notion of types at all (e.g. assembler). Even the Wikipedia article about programming languages (http://en.m.wikipedia.org/wiki/Programming_language#Typed_versus_untyped_languages) makes this distinction.

Update: Maybe the confusion comes from the fact that some texts say something to the extent that "variables are not typed" in Javascript (which is true). But that doesn't automatically mean that the language is untyped (which would be false).

afrischke
  • 3,836
  • 17
  • 30
  • 1
    Assembler does have some very weak notion of types. At least in x86, everything is an integer, but some integers are different sizes from others. That's even before getting into MMX, x87, and other extensions to the original x86 spec. – Adam Mihalcin Feb 06 '12 at 01:14
  • I have to disagree. In Javascript I could have objects I've built up to be "Monkeys" and objects I've built up to be "Humans" and some functions could be designed to operate on only "Humans", others on only "Monkeys", and yet others on only "Things With Arms". Whether or not the language has ever been told there is such a category of objects as "things with arms" is as irrelevant to assembly ("untyped") as it is to Javascript ("dynamic"). It's all a matter of logical integrity - and the only error would be using something that didn't have arms with that method. – Steve Feb 06 '12 at 01:16
  • @Adam Mihalcin True. [Macro] assembly languages can of course have some notion of types to various degrees too. (Check out the "Typed Assembly Language" for example.) I still think my point holds though. – afrischke Feb 06 '12 at 02:09
  • 3
    @Steve I am not sure if I can follow you. The OP asked if in CS circles no distinction is made between "dynamically typed" and "untyped". This has nothing to do with whether you believe that there is practically no distinction between how Javascript vs. assembly treat the bits in memory. According to what I have read (and I had to look this up specifically as I am no Javascript programmer): The ECMAScript/Javascript standard defines 6 data types (Boolean, String, Undefined, Number, Null, and Object) and at any point in time a value is of one concrete type... – afrischke Feb 06 '12 at 02:37
  • 1
    ...Now this is a concept (most) assembly languages don't have (all there is are bits and bytes), so imho this marks a clear distinction between Javascript and assembly. – afrischke Feb 06 '12 at 02:39
2

Agree with Brendan - context is everything.

My take:

I remember being confused, circa 2004, because there were arguments breaking out about whether Ruby was untyped or dynamically typed. Old school C/C++ people (of which I was one) were thinking about the compiler and saying Ruby was untyped.

Remember, in C, there are no runtime types, there are just addresses and if the code that's executing decides to treat whatever's at that address as something it isn't, whoops. That's definitely untyped and very different from dynamically typed.

In that world, "typing" is all about the compiler. C++ had "strong typing" because the compiler's checks were more stringent. Java and C were more "weakly typed" (there were even arguments about whether Java was strongly or weakly typed). Dynamic languages were, in that continuum, "untyped" because they had no compiler type checking.

Today, for practicing programmers, we're so used to dynamic languages, we obviously think of untyped to mean no compiler nor interpreter type-checking, which would be insanely hard to debug. But there was a period there where that wasn't obvious and in the more theoretical world of CS is may not even be meaningful.

In some deep sense, nothing can be untyped (or almost nothing, anyway) because you must have some intent in manipulating a value to write a meaningful algorithm. This is the world of theoretical CS, which isn't dealing with the specifics of how a compiler or interpreter is implemented for a given language. So "untyped" is (probably, I don't know) entirely meaningless in that context.

Dan Yoder
  • 21
  • 1