¿"Sin tipo" también significa "tipo dinámico" en el mundo académico de CS?

166

Estoy leyendo un mazo de diapositivas que dice "JavaScript no tiene tipo". Esto contradecía lo que pensaba que era verdad, así que comencé a cavar para intentar aprender más.

Cada respuesta a ¿Es JavaScript un lenguaje sin tipo? dice que JavaScript no está sin tipo y ofrece ejemplos de varias formas de escritura estática, dinámica, fuerte y débil con las que estoy familiarizado y contento ... así que ese no era el camino a seguir.

Entonces le pregunté a Brendan Eich, el creador de JavaScript, y él dijo:

los tipos académicos usan "sin tipo" para significar "sin tipos estáticos". son lo suficientemente inteligentes como para ver que los valores tienen tipos (¡duh!). el contexto importa.

¿La gente de informática enfocada académicamente usa "sin tipo" como sinónimo de "tipo dinámico" (y es esto válido?) O hay algo más profundo en esto que me estoy perdiendo? Estoy de acuerdo con Brendan en que el contexto es importante, pero cualquier cita de explicaciones sería excelente, ya que mis libros actuales de "ir a" no están jugando mal en este tema.

Quiero concretar esto para poder mejorar mi comprensión y porque incluso Wikipedia no se refiere a este uso alternativo (que puedo encontrar, de todos modos). No quiero equivocarme con usar el término o cuestionar el uso del término en el futuro si me equivoco :-)

(¡También he visto que un Smalltalker superior dice que Smalltalk también está "sin tipo", por lo que no es una excepción, que es lo que me hizo saltar en esta búsqueda! :-))

Peter Cooper
fuente
55
El mal uso de la nomenclatura por parte de otros no tiene que dar forma a sus hábitos, solo use la (más) frase correcta. Tienes que ser consciente del problema de lectura, obviamente.
Raphael
2
Siempre lo tomé como, las variables no están tipificadas, ya que cualquier variable puede contener cualquier tipo de datos. El tipo de lo que está en la variable puede cambiar dinámicamente .
Izkata
1
Además (nuevamente diciendo más sobre el lenguaje natural que los lenguajes de computadora) "untyped" = "single-typed" (un tipo para todos los valores).
Philip

Respuestas:

148

Sí, esta es una práctica estándar en la literatura académica. Para entenderlo, es útil saber que la noción de "tipo" se inventó en la década de 1930, en el contexto del cálculo lambda (de hecho, incluso antes, en el contexto de la teoría de conjuntos). Desde entonces, ha surgido toda una rama de la lógica computacional que se conoce como "teoría de tipos". La teoría del lenguaje de programación se basa en estos fundamentos. Y en todos estos contextos matemáticos, "tipo" tiene un significado particular bien establecido.

La terminología "mecanografía dinámica" se inventó mucho más tarde, y es una contradicción de términos frente al uso matemático común de la palabra "tipo".

Por ejemplo, aquí está la definición de "sistema de tipos" que Benjamin Pierce usa en su libro de texto estándar Tipos y lenguajes de programación :

Un sistema de tipos es un método sintáctico manejable para demostrar la ausencia de ciertos comportamientos del programa clasificando frases de acuerdo con los tipos de valores que calculan.

Él también comenta:

La palabra "estática" a veces se agrega explícitamente (por ejemplo, hablamos de un "lenguaje de programación estáticamente tipado") para distinguir los tipos de análisis en tiempo de compilación que estamos considerando aquí del tipeo dinámico o latente que se encuentra en lenguajes como Scheme (Sussman y Steele, 1975; Kelsey, Clinger y Rees, 1998; Dybvig, 1996), donde las etiquetas de tipo de tiempo de ejecución se utilizan para distinguir diferentes tipos de estructuras en el montón. Términos como "tipeado dinámicamente" son posiblemente nombres incorrectos y probablemente deberían reemplazarse por "marcado dinámicamente", pero el uso es estándar.

La mayoría de las personas que trabajan en el campo parecen compartir este punto de vista.

Tenga en cuenta que esto no significa que "sin tipo" y "tipo dinámico" sean sinónimos. Más bien, que este último es un nombre (técnicamente engañoso) para un caso particular del primero.

PD: Y FWIW, resulta que soy tanto un investigador académico en sistemas de tipos como un implementador no académico de JavaScript, así que tengo que vivir con el schisma. :)

Andreas Rossberg
fuente
55
Que es muy útil y podría ser mi respuesta favorita en términos de proporcionar algo de la historia.
Peter Cooper
2
@PeterCooper, por cierto, puede interesarle saber que una rama importante de la semántica formal se basa (un juego de palabras) en los cálculos lambda escritos; por ejemplo, Semántica de Montague. Pero como un sistema declarativo, no generativo, personalmente siempre he compartimentado la escritura en sistemas como Montague Semantics, lejos de escribir en lenguajes de programación.
knowtheory
+1. "[dynamically typed] is a (technically misleading) name for a particular case of [untyped]"
Steve
1
Esto no es del todo correcto sobre la historia de los "tipos". Son incluso más antiguos que el trabajo de Church sobre el cálculo lambda. Russell utilizó tipos para evitar paradojas en la construcción de la teoría de conjuntos.
Sam Tobin-Hochstadt
1
@ SamTobin-Hochstadt, sí, claro. Solo hablé sobre la parte de la historia que concierne directamente a los fundamentos de los PL. Lo aclararé.
Andreas Rossberg
68

Soy un informático académico especializado en lenguajes de programación, y sí, la palabra "sin tipo" se usa con frecuencia (mal) de esta manera. Sería bueno reservar la palabra para usarla con idiomas que no llevan etiquetas de tipo dinámico, como Forth y código de ensamblaje, pero estos idiomas rara vez se usan y aún más raramente se estudian, y es mucho más fácil decir "sin tipo" que "escrito dinámicamente".

Bob Harper es aficionado a decir que los lenguajes como Scheme, Javascript, etc. deben considerarse lenguajes mecanografiados con un solo tipo: valor. Me inclino por esta vista, ya que hace posible construir una visión del mundo coherente utilizando solo un formalismo de tipo.

PD: En el cálculo lambda puro, los únicos "valores" son términos en forma normal, y los únicos términos cerrados en forma normal son funciones. Pero la mayoría de los científicos que usan el cálculo lambda agregan tipos básicos y constantes, y luego se incluye un sistema de tipos estático para lambda o se regresa a las etiquetas de tipo dinámico.

PPS Al póster original: cuando se trata de lenguajes de programación, y especialmente sistemas de tipos, la información en Wikipedia es de baja calidad. No confíes en eso.

Norman Ramsey
fuente
12
Creo que hay un problema más amplio en CS (incluida la academia) de que los nombres se usan sin una definición rigurosa. Esto está en marcado contraste con las matemáticas y (¿la mayoría?) Ciencias. Una gran cantidad de disputas (por ejemplo, sobre POO) parece derivarse de esta falta de definiciones adecuadas. Muy molesto.
Konrad Rudolph
2
@KonradRudolph: Me pregunto si, en lugar de las disputas derivadas de la falta de definiciones adecuadas, la falta de definiciones adecuadas podría surgir en parte de las disputas. Algunos términos adquieren una valencia emocional (ya sea positiva o negativa), y los partidarios de idiomas específicos luego definen esos términos de manera que incluyen o excluyen sus idiomas (y excluyen o incluyen sus idiomas favoritos "enemigos"). Para un ejemplo matemático: si todavía hubiera personas que apoyaran la teoría de conjuntos ingenua sobre la teoría de conjuntos axiomática, puede estar seguro de que llamarían a sus propios puntos de vista "teoría de conjuntos axiomática" y definirían "ingenua
ruakh
44
@ Norman, me sorprende que lo llamen mal uso, como saben, la noción de tipo es anterior a los llamados lenguajes dinámicamente escritos por décadas, y lo que este último llama "tipo" tiene poco que ver con el primero. Así que creo que es justo decir que el mal uso es al revés.
Andreas Rossberg
55
@ Norman: Cuando se trata de lenguajes de programación, y especialmente de sistemas de tipos, si cree que la información en Wikipedia es de baja calidad, no la deje sola y mejórela. (solo trolling)
Gyom
3
@Gyom Dejé de mejorar Wikipedia el día que me di cuenta de que el proceso de Wikipedian recompensa el cambio , no la experiencia . Es mejor dedicar mi tiempo a mejorar SO :-)
Norman Ramsey
43

Lo investigué y descubrí que la respuesta a su pregunta es simple y sorprendentemente "sí": los tipos de CS académicos, o al menos algunos de ellos, usan "sin tipo" para significar "tipo dinámico". Por ejemplo, Lenguajes de programación: Principios y prácticas , Tercera edición (por Kenneth C. Louden y Kenneth A. Lambert, publicado en 2012) dice esto:

Los idiomas sin sistemas de tipo estático generalmente se denominan idiomas sin tipo (o idiomas con tipo dinámico ). Dichos lenguajes incluyen Scheme y otros dialectos de Lisp, Smalltalk y la mayoría de los lenguajes de scripting como Perl, Python y Ruby. Sin embargo, tenga en cuenta que un lenguaje sin tipo no necesariamente permite que los programas corrompan los datos; esto solo significa que todas las comprobaciones de seguridad se realizan en el momento de la ejecución. [...]

[ enlace ] (nota: negrita en original) y continúa usando "sin tipo" de esta manera.

Esto me parece sorprendente (por las mismas razones que dan Afrischke y Adam Mihalcin), pero ahí estás. :-)


Editado para agregar: puede encontrar más ejemplos conectándose "untyped languages"a la Búsqueda de libros de Google. Por ejemplo:

[…] Este es el principal mecanismo de ocultación de información en muchos idiomas sin tipo. Por ejemplo, el esquema PLT [4] utiliza structs generativo , […]

- Jacob Matthews y Amal Ahmed, 2008 [ enlace ]

[...], presentamos un análisis de tiempo vinculante para un lenguaje funcional sin tipo [...]. […] Se ha implementado y se utiliza en un evaluador parcial para un dialecto de Scheme sin efectos secundarios. Sin embargo, el análisis es lo suficientemente general como para ser válido para lenguajes funcionales tipados no estrictos como Haskell. [...]

- Charles Consel, 1990 [ enlace ]

Por cierto, mi impresión, después de mirar estos resultados de búsqueda, es que si un investigador escribe un lenguaje funcional "sin tipo", es muy probable que lo considere "sin tipo" en el mismo sentido que la lambda sin tipo cálculo que menciona Adam Mihalcin. Al menos, varios investigadores mencionan Scheme y el cálculo lambda en el mismo aliento.

Lo que la búsqueda no dice, por supuesto, es si hay investigadores que rechazan esta identificación, y no consideran que estos idiomas sean "sin tipo". Bueno, encontré esto:

Entonces me di cuenta de que realmente no hay circularidad, porque los lenguajes escritos dinámicamente no son idiomas sin tipar, es solo que los tipos no suelen ser inmediatamente obvios en el texto del programa.

- alguien (no puedo decir quién), 1998 [ enlace ]

pero obviamente la mayoría de las personas que rechazan esta identificación no sentirían la necesidad de decirlo explícitamente.

ruakh
fuente
2
Guau. Impactante. Gracias por la info.
afrischke
Exactamente el tipo de cita que estaba buscando, ¡gracias! Me da un poco de miedo que el libro tenga un promedio de 2 estrellas en Amazon, por lo que se aceptan más citas, pero este es un gran comienzo.
Peter Cooper
@PeterCooper: he editado mi respuesta para agregar más citas. Evitan el problema de las calificaciones de Amazon al ser de artículos publicados: por lo que sé, todavía podrían ser basura, pero al menos no tenemos que preocuparnos de que Amazon nos lo diga. :-P
ruakh
Confundir "sin tipo" con "tipo dinámico" es ilógico. Los desarrolladores no deben ser ilógicos.
Rotman
10

Sin tipo y con tipo dinámico no son sinónimos. El lenguaje que con mayor frecuencia se llama "sin tipo" es el cálculo Lambda, que en realidad es un lenguaje unificado: todo es una función, por lo que podemos demostrar estáticamente que el tipo de todo es la función. Un lenguaje de tipo dinámico tiene múltiples tipos, pero no agrega una forma para que el compilador los compruebe estáticamente, lo que obliga al compilador a insertar comprobaciones de tiempo de ejecución en tipos variables.

Entonces, JavaScript es un lenguaje de tipo dinámico: es posible escribir programas en JavaScript de manera que alguna variable xpueda ser un número, una función, una cadena u otra cosa (y determinar cuál requeriría resolver el problema de detención o alguna problema matemático difícil), por lo que puede aplicar xa un argumento y el navegador debe verificar en tiempo de ejecución que xsea ​​una función.

Adam Mihalcin
fuente
AFAIK Los mismos problemas se aplican a una expresión Lambda. Si bien es posible que pueda pasar una función para "mi posición actual" a una función que calcule "mi distancia del objetivo", también podría pasar la misma función "mi posición actual" a una función que calcule "son soplos más con vicks mejor para tu nariz ". El hecho de que pueda no significa que sea válido, como es el caso de cualquier sistema dinámico.
Steve
55
Sin embargo, @Steve Garbage in basura es el caso de cualquier lenguaje de programación, y no está relacionado con la noción de tipos. Incluso en un lenguaje fuertemente tipado como OCaml o SML, puedo pasar el Polo Norte a una función que calcule "mi distancia del objetivo" (y no, mi posición actual no es el Polo Norte).
Adam Mihalcin
Solo quería agregar, para personas fuera de la academia: cosas como la asamblea también contarían como sin tipo.
CoffeeTableEspresso
6

Ambas declaraciones son correctas, dependiendo de si se trata de valores o variables. Las variables de JavaScript no están tipificadas, los valores de JavaScript tienen tipos y las variables pueden variar sobre cualquier tipo de valor en tiempo de ejecución (es decir, "dinámicamente").

En JavaScript y muchos otros lenguajes, los valores y no las variables llevan tipos. Todas las variables pueden abarcar todos los tipos de valores y pueden considerarse "con tipo dinámico" o "sin tipo", desde la perspectiva de la verificación de tipo, una variable que no tiene tipo / no se puede conocer y una variable que puede tomar cualquier tipo es lógica y prácticamente equivalente. . Cuando los teóricos de tipos hablan de idiomas y tipos, generalmente hablan de esto, variables que llevan tipos, porque están interesados ​​en escribir verificadores de tipo y compiladores, etc., que operan en el texto del programa (es decir, variables) y no en un programa en ejecución en la memoria (es decir, valores).

Por el contrario, en otros lenguajes, como C, las variables llevan tipos pero los valores no. En lenguajes como Java, las variables y los valores llevan tipos. En C ++, algunos valores (aquellos con funciones virtuales) llevan tipos y otros no. En algunos idiomas, incluso es posible que los valores cambien de tipo, aunque esto generalmente se considera un mal diseño.


fuente
55
Creo que la distinción clave no es entre valores y variables , sino entre valores y expresiones : en un lenguaje de tipo estático, las expresiones tienen tipos, mientras que en un lenguaje de tipo dinámico, solo los valores lo hacen. (Los nombres de variables son un tipo de expresión, por supuesto.)
ruakh
4

Esta pregunta es sobre semántica

Si te doy estos datos: 12¿cuál es su tipo? No tienes forma de saberlo con certeza. Podría ser un entero, podría ser un flotador, podría ser una cadena. En ese sentido, son datos muy "sin tipo".

Si le doy un lenguaje imaginario que le permite usar operadores como "sumar", "restar" y "concatenar" en estos datos y alguna otra pieza arbitraria de datos, el "tipo" es algo irrelevante (para mi lenguaje imaginario) (ejemplo : quizás add(12, a)rinde 109cuál es 12más el valor ascii de a).

Hablemos C por un segundo. C prácticamente te permite hacer lo que quieras con cualquier dato arbitrario. Si está utilizando una función que requiere dos uints, puede emitir y pasar lo que desee, y los valores simplemente se interpretarán como uints. En ese sentido, C no está "tipificado" (si lo trata de esa manera).

Sin embargo, y llegando al punto de Brendan, si te digo que "Mi edad es 12", entonces 12tiene un tipo, al menos sabemos que es numérico. Con contexto, todo tiene un tipo, independientemente del idioma.

Es por eso que dije al principio: su pregunta es semántica. ¿Cuál es el significado de "sin tipo"? Creo que Brendan dio en el clavo cuando dijo "no hay tipos estáticos", porque eso es todo lo que puede significar. Los humanos naturalmente clasifican las cosas en tipos. Intuitivamente sabemos que hay algo fundamentalmente diferente entre un auto y un mono, sin que se nos enseñe a hacer esas distinciones.

Volviendo a mi ejemplo al principio: un lenguaje que "no se preocupa por los tipos" (per-se) puede permitirle "agregar" una "edad" y un "nombre" sin producir un error de sintaxis ... pero eso no significa que sea una operación lógicamente sólida.

Javascript puede permitirte hacer todo tipo de locuras sin considerarlas "errores". Eso no significa que lo que estás haciendo sea lógicamente correcto. Eso es para que el desarrollador lo resuelva.

¿Es un sistema / lenguaje que no exige la seguridad de tipos en tiempo de compilación / construcción / interpretación "sin tipo" o "con tipo dinámico"?

Semántica.

EDITAR

Quería agregar algo aquí porque algunas personas parecen estar atrapadas en "sí, pero Javascript tiene algunos" tipos "".

En mi comentario sobre la respuesta de otra persona, dije:

En Javascript podría tener objetos que he creado para ser "Monos" y objetos que he creado para ser "Humanos" y algunas funciones podrían diseñarse para operar solo en "Humanos", otras solo en "Monos", y y otros solo en "Cosas con armas". Si alguna vez se le ha dicho al idioma que existe una categoría de objetos como "cosas con brazos" es tan irrelevante para el ensamblaje ("sin tipo") como para Javascript ("dinámico"). Todo es una cuestión de integridad lógica, y el único error sería usar algo que no tuviera armas con ese método.

Entonces, si considera que Javascript tiene alguna "noción de tipos" internamente y, por lo tanto, "tipos dinámicos", y piensa que de alguna manera es "claramente diferente de un sistema sin tipo", debería ver en el ejemplo anterior que cualquier "noción de tipos "que tiene internamente es realmente irrelevante.

Para realizar la misma operación con C #, por ejemplo, NECESITO una interfaz llamada ICreatureWithArmso algo similar. No es así en Javascript, no es así en C o ASM.

Claramente, si Javascript tiene alguna comprensión de los "tipos" es irrelevante.

Steve
fuente
44
-1. La pregunta pregunta si se usa una determinada palabra, en ciertos círculos, con un cierto significado, y su respuesta es explicar que se trata de si la palabra tiene ese significado. Realmente, creo que has hecho un trabajo admirable al explicar todo lo que el OP ya parece saber, sin agregar nada nuevo. . .
ruakh
Parece que hay varias preguntas necesarias para construir una definición, tal vez? El de la aplicación de tipos (estático o dinámico) y la presencia de tipos definidos. ¿Entonces JavaScript tiene tipos pero puede considerarse "sin tipo" debido a la falta de verificación de la validez de los tipos antes de realizar una operación?
Peter Cooper
@ruakh: puedo entender tu perspectiva. Sin embargo, el OP preguntó: is there something deeper to this that I am missingy, creo, que la falta de comprensión de que es un problema semántico es lo más profundo, por lo que hice todo lo posible para incluir cualquier información que pudiera.
Steve
@PeterCooper: mira mi edición y dime si eso agrega algo para ti (como dijiste JavaScript has typesen tu respuesta).
Steve
2
"Claramente, si Javascript tiene alguna comprensión de los" tipos "es irrelevante". No es verdad. Como indiqué en mi respuesta, no importa el contexto, no se puede tratar el 12 como una función. Dado que JavaScript tiene un tipo de función (o, según su punto de vista, varios tipos de función), esta es una distinción importante.
Adam Mihalcin
4

Si bien es cierto que la mayoría de los investigadores de CS que escriben sobre tipos esencialmente consideran solo los idiomas con tipos derivables sintácticamente como idiomas mecanografiados, hay muchos más de nosotros que usamos lenguajes mecanografiados dinámicamente / latentemente que se molestan con ese uso.

Considero que hay 3 tipos [SIC] de idiomas:

Sin tipo: solo el operador determina la interpretación del valor, y generalmente funciona en cualquier cosa. Ejemplos: ensamblador, BCPL

Tipo estático: las expresiones / variables tienen tipos asociados, y ese tipo determina la interpretación / validez del operador en tiempo de compilación. Ejemplos: C, Java, C ++, ML, Haskell

Tipo dinámico: los valores tienen tipos asociados con ellos, y ese tipo determina la interpretación / validez del operador en tiempo de ejecución. Ejemplos: LISP, Scheme, Smalltalk, Ruby, Python, Javascript

Que yo sepa, todos los lenguajes escritos dinámicamente son seguros, es decir, solo los operadores válidos pueden operar con valores. Pero lo mismo no es cierto para el lenguaje de tipo estático. Dependiendo de la potencia del tipo de sistema utilizado, algunos operadores pueden ser verificados solo en tiempo de ejecución, o en absoluto. Por ejemplo, la mayoría de los lenguajes de tipo estático no manejan el desbordamiento de enteros correctamente (agregar 2 enteros positivos puede producir un entero negativo), y las referencias de matriz fuera del límite no se verifican (C, C ++) o solo se verifican en tiempo de ejecución Además, algunos sistemas de tipos son tan débiles que la programación útil requiere sombreados de escape (conversiones en C y familia) para cambiar el tipo de expresiones en tiempo de compilación.

Todo esto lleva a afirmaciones absurdas, como que C ++ es más seguro que Python porque es (estáticamente tipado), mientras que la verdad es que Python es intrínsecamente seguro mientras puedes disparar tu pierna con C ++.

Dave Mason
fuente
Votado Me alegra saber que "todos los idiomas de tipo dinámico son seguros para escribir". "Pero lo mismo no es cierto para el lenguaje de tipo estático", ¿quiere decir que todos o la mayoría de los idiomas de tipo estático no son seguros?
Tim
Votado (1) Me alegra saber que "todos los idiomas de tipo dinámico son seguros para escribir", pero Javascript es de tipo dinámico y de tipo débil, consulte stackoverflow.com/questions/964910/… . (2) "Pero lo mismo no es cierto para el lenguaje de tipo estático", ¿quiere decir que todos o la mayoría de los idiomas de tipo estático no son seguros?
Tim
Muy pocos idiomas son estáticamente seguros para los tipos, si incluye la posibilidad de falla de conversión, subíndice fuera de los límites o excepciones de puntero nulo como tipos (y la mayoría de las personas incluyen al menos la falla de conversión como un error de tipo). Rust, por ejemplo, es más seguro de tipo estático que Java porque no puede tener un puntero nulo. Java es dinámicamente seguro para escribir porque obtienes excepciones para cualquier operación ilegal y todo está especificado (excepto los métodos nativos). De manera similar, Rust (excepto el código "inseguro" que se denomina así).
Dave Mason el
Sin embargo, C ++, C ni siquiera son dinámicamente seguros de tipo porque hay partes "no especificadas" del lenguaje, y si realiza una de las operaciones "no especificadas", literalmente cualquier cosa es una respuesta legal del lenguaje (los valores de variables no relacionadas podrían cambiar, los virus podrían infectar su programa, el programa podría escribir en todo su disco y luego bloquearse, el programa podría incluso hacer lo que esperaba :-).
Dave Mason el
@DaveMason: Indefinido. Hay una enorme diferencia entre "no especificado" e "indefinido" en C. El comportamiento indefinido es básicamente cosas ilegales que pueden hacer lo que ha descrito --- mientras que no especificado esencialmente significa "definido por la implementación donde la implementación no tiene que documentarlo". "(hay algunos matices aquí y allá, así que esto es una simplificación). Invocar un comportamiento no especificado es, por lo tanto, perfectamente legal (de hecho, uno lo hace cada vez que se escribe, digamos, una llamada a función).
Tim Čas
2

No soy un científico de la computación, pero me sorprendería que "sin tipo" se usara realmente como sinónimo de "tipo dinámico" en la comunidad de CS (al menos en publicaciones científicas) ya que, en mi opinión, esos dos términos describen conceptos diferentes. Un lenguaje de tipo dinámico tiene una noción de tipos y aplica las restricciones de tipo en tiempo de ejecución (por ejemplo, no puede dividir un entero por una cadena en Lisp sin obtener un error), mientras que un lenguaje sin tipo no tiene ninguna noción de tipos en todos (por ejemplo, ensamblador). Incluso el artículo de Wikipedia sobre lenguajes de programación (http://en.m.wikipedia.org/wiki/Programming_language#Typed_versus_untyped_languages) hace esta distinción.

Actualización: Tal vez la confusión proviene del hecho de que algunos textos dicen algo en la medida en que "las variables no están escritas" en Javascript (lo cual es cierto). Pero eso no significa automáticamente que el idioma no esté tipificado (lo que sería falso).

Afrischke
fuente
1
El ensamblador tiene una noción de tipos muy débil. Al menos en x86, todo es un número entero, pero algunos números enteros son de tamaños diferentes a otros. Eso es incluso antes de entrar en MMX, x87 y otras extensiones a la especificación x86 original.
Adam Mihalcin
Tengo que estar en desacuerdo. En Javascript podría tener objetos que he creado para ser "Monos" y objetos que he creado para ser "Humanos" y algunas funciones podrían diseñarse para operar solo en "Humanos", otras solo en "Monos", y y otros solo en "Cosas con armas". Si alguna vez se le ha dicho al idioma que existe una categoría de objetos como "cosas con brazos" es tan irrelevante para el ensamblaje ("sin tipo") como para Javascript ("dinámico"). Todo es una cuestión de integridad lógica, y el único error sería usar algo que no tuviera armas con ese método.
Steve
@ Adam Mihalcin Cierto. Los lenguajes de ensamblaje [Macro] pueden, por supuesto, tener alguna noción de tipos en varios grados también. (Consulte el "Lenguaje de ensamblaje mecanografiado", por ejemplo). Sin embargo, todavía creo que mi punto es válido.
afrischke
3
@ Steve No estoy seguro si puedo seguirte. El OP preguntó si en los círculos CS no se hace distinción entre "con tipo dinámico" y "sin tipo". Esto no tiene nada que ver con si crees que prácticamente no hay distinción entre cómo Javascript vs. ensamblaje trata los bits en la memoria. De acuerdo con lo que he leído (y tuve que buscar esto específicamente ya que no soy un programador de Javascript): el estándar ECMAScript / Javascript define 6 tipos de datos (booleano, cadena, indefinido, número, nulo y objeto) y en cualquier momento a tiempo un valor es de un tipo concreto ...
afrischke
1
... Ahora, este es un concepto que (la mayoría) de los lenguajes de ensamblaje no tienen (todo lo que hay son bits y bytes), por lo que, en mi opinión, esto marca una clara distinción entre Javascript y ensamblaje.
afrischke
1

De acuerdo con Brendan: el contexto lo es todo.

Mi toma:

Recuerdo estar confundido, alrededor del año 2004, porque surgieron discusiones sobre si Ruby no tenía tipo o si estaba escrito dinámicamente. Las personas de C / C ++ de la vieja escuela (de las cuales yo era uno) pensaban en el compilador y decían que Ruby no estaba tipificado.

Recuerde, en C, no hay tipos de tiempo de ejecución, solo hay direcciones y si el código que se está ejecutando decide tratar lo que está en esa dirección como algo que no es, whoops. Eso definitivamente no tiene tipo y es muy diferente de lo que se escribe dinámicamente.

En ese mundo, "escribir" tiene que ver con el compilador. C ++ tenía "tipeo fuerte" porque las comprobaciones del compilador eran más estrictas. Java y C estaban más "tipados débilmente" (incluso hubo argumentos sobre si Java estaba tipada fuerte o débilmente). Los lenguajes dinámicos fueron, en ese continuo, "sin tipo" porque no tenían verificación de tipo de compilador.

Hoy, para los programadores practicantes, estamos tan acostumbrados a los lenguajes dinámicos, obviamente pensamos que sin tipo significa que no hay verificación de tipo de compilador o intérprete, lo que sería increíblemente difícil de depurar. Pero hubo un período allí donde eso no era obvio y en el mundo más teórico de CS puede que ni siquiera sea significativo.

En cierto sentido profundo, nada puede ser sin tipo (o casi nada, de todos modos) porque debe tener alguna intención de manipular un valor para escribir un algoritmo significativo. Este es el mundo de la CS teórica, que no se ocupa de los detalles de cómo se implementa un compilador o intérprete para un idioma determinado. Así que "sin tipo" es (probablemente, no lo sé) completamente sin sentido en ese contexto.

Dan Yoder
fuente