tipos - type of javascript

¿"Tipeado" también significa "tipeado dinámicamente" en el mundo académico de CS? (9)

Ambas afirmaciones son correctas, dependiendo de si está hablando de valores o variables. Las variables de JavaScript están sin tipo, los valores de JavaScript tienen tipos y las variables pueden oscilar sobre cualquier tipo de valor en el tiempo de ejecución (es decir, "dinámicamente").

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

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

Estoy leyendo un mazo de diapositivas que dice "JavaScript está sin tipo". Esto contradecía lo que pensaba que era cierto, así que empecé a cavar para tratar de 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 tipeo estático, dinámico, fuerte y débil con el 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 me dijo:

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

¿La gente de ciencias de la computación enfocada académicamente usa "sin tipo" como sinónimo de "tipeado dinámicamente" (y es esto válido?) O ¿hay algo más profundo en esto que me falta? Estoy de acuerdo con Brendan en que el contexto es importante, pero cualquier cita de explicación sería grandiosa ya que mis libros actuales de "ir a" no están jugando a la pelota en este tema.

Quiero aclarar 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 meter la pata con usar el término o cuestionar el uso del término en el futuro si me equivoco :-)

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

De acuerdo con Brendan: el contexto es todo.

Mi toma:

Recuerdo que estaba confundido, alrededor del año 2004, porque había discusiones sobre si Ruby estaba sin tipo o si se tecleaba dinámicamente. La gente de la escuela C / C ++ (de la cual yo era uno) estaba pensando en el compilador y diciendo que Ruby no estaba tipificada.

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, gritos. Eso definitivamente es sin tipo y muy diferente de los tipos dinámicamente.

En ese mundo, "escribir" tiene que ver con el compilador. C ++ tenía "tipado fuerte" porque los controles del compilador eran más estrictos. Java y C eran más "débilmente tipadas" (incluso hubo argumentos sobre si Java tenía un tipeo fuerte o débil). Los lenguajes dinámicos estaban, en ese continuo, "sin tipo" porque no tenían verificación de tipo de compilador.

Hoy en día, para los programadores en ejercicio, estamos tan acostumbrados a los lenguajes dinámicos, obviamente pensamos que no tipeado significa que no hay compilador ni verificación de tipo de intérprete, lo que sería terriblemente difícil de depurar. Pero hubo un período en el que eso no era obvio y en el mundo más teórico de la CS no puede ser significativo.

En un sentido profundo, nada puede ser sin tipo (o casi nada, de todos modos) porque debe tener la intención de manipular un valor para escribir un algoritmo significativo. Este es el mundo de la CS teórica, que no trata con 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.

Esta pregunta es todo sobre Semantics

Si le doy esta información: 12 ¿cuál es su tipo? No tienes forma de saberlo con certeza. Podría ser un número entero, podría ser un flotador, podría ser una cadena. En ese sentido, se trata de datos "sin tipo".

Si le doy un lenguaje imaginario que le permite usar operadores como "agregar", "restar" y "concatenar" en estos datos y algún otro dato arbitrario, el "tipo" es algo irrelevante (a mi lenguaje imaginario) (ejemplo : quizás add(12, a) rinde 109 que es 12 má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á usando una función que toma dos uint s, puede lanzar y pasar lo que quiera, y los valores simplemente se interpretarán como uint s. En ese sentido, C está "sin tipo" (si lo tratas de esa manera).

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

Es por eso que dije al principio: tu pregunta es de semántica. ¿Cuál es el significado de "sin tipo"? Creo que Brendan dio en el clavo cuando dijo "no hay tipos de estática", 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 automóvil y un mono, sin que nunca se les enseñe a hacer esas distinciones.

Volviendo a mi ejemplo al principio, un lenguaje que "no le importan 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ógica.

Javascript puede permitirle hacer todo tipo de cosas locas sin considerarlas como "errores". Eso no significa que lo que estás haciendo sea lógicamente correcto. Eso es para que el desarrollador trabaje.

¿Es un sistema / lenguaje que no aplica la seguridad de tipo en el tiempo de compilación / construcción / interpretación "sin tipo" o "tipado dinámicamente"?

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 con "Humanos", otras solo con "Monos", y otros solo en "Things With Arms". Si el lenguaje alguna vez se ha dicho que existe una categoría de objetos tales como "cosas con armas" es tan irrelevante para el ensamblaje ("sin tipo") como lo es 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 esto es de alguna manera "distintivamente diferente de un sistema sin tipo" - debería ver en el ejemplo anterior que cualquier "noción de tipos "internamente es realmente irrelevante.

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

Claramente, el hecho de que Javascript comprenda o no los "tipos" es irrelevante.

Lo investigué y encontré 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 indicar "escritos de forma dinámica". 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 lo siguiente:

Los idiomas sin sistemas de tipo estático suelen denominarse idiomas no tipificados (o idiomas tipados dinámicamente ). 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 la información; esto solo significa que toda la verificación de seguridad se realiza en el momento de la ejecución. [...]

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

Me parece sorprendente (por las mismas razones que afrischke y Adam Mihalcin dan), pero ahí está. :-)

Editado para agregar: puede encontrar más ejemplos al conectar "untyped languages" en la Búsqueda de libros de Google. Por ejemplo:

[...] Este es el principal mecanismo de ocultación de la información en muchos idiomas sin tipo. Por ejemplo, el Esquema PLT [4] utiliza struct generativas, [...]

- Jacob Matthews y Amal Ahmed, 2008 [ link ]

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

- Charles Consel, 1990 [ link ]

Por cierto, mi impresión, después de mirar a través de estos resultados de búsqueda, es que si un investigador escribe de un lenguaje funcional "sin tipo", es muy probable que lo considere "sin tipo" en el mismo sentido que el 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 estén "sin tipo". Bueno, encontré esto:

Luego me di cuenta de que realmente no hay circularidad, porque los lenguajes de tipado dinámico no son idiomas sin tipear, es solo que los tipos no son inmediatamente obvios desde el texto del programa.

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

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

No soy científico informático, pero me sorprendería mucho que los términos "sin tipo" se usen realmente como sinónimo de "tipeado dinámicamente" en la comunidad CS (al menos en publicaciones científicas) ya que esos dos términos describen conceptos diferentes. Un lenguaje de tipado dinámico tiene una noción de tipos e impone las restricciones de tipo en el tiempo de ejecución (no puede, por ejemplo, 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 todo (por ejemplo, ensamblador). Incluso el artículo de Wikipedia sobre los 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 tipadas" en Javascript (lo cual es cierto). Pero eso no significa automáticamente que el lenguaje esté sin tipo (lo que sería falso).

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

Considero que hay 3 tipos [SIC] de idiomas:

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

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

Tipeado dinámicamente: 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 de tipo dinámico son seguros para el tipo, es decir, solo los operadores válidos pueden operar en valores. Pero lo mismo no es cierto para el lenguaje de tipo estático. Dependiendo de la potencia del sistema de tipo 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 apropiadamente el desbordamiento de enteros (agregar 2 enteros positivos puede producir un entero negativo), y las referencias de matriz fuera de límite no se verifican en absoluto (C, C ++) o solo se verifican tiempo de ejecución Además, algunos sistemas de tipo son tan débiles que la programación útil requiere escapes de escape (moldes en C y familia) para cambiar el tipo de expresiones de tiempo de compilación.

Todo esto lleva a afirmaciones absurdas, como que C ++ es más seguro que Python porque está (estáticamente tipificado), mientras que la verdad es que Python es intrínsecamente seguro mientras que usted puede dispararle a su pierna con C ++.

Soy un científico 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 su uso con idiomas que no llevan etiquetas de tipo dinámico, como Forth y código ensamblador, pero estos lenguajes rara vez se usan y aún más raramente se estudian, y es mucho más fácil decir "sin tipo". que "tipeado dinámicamente".

A Bob Harper le gusta decir que los lenguajes como Scheme, Javascript, etc. deben considerarse como idiomas tipados con un solo tipo: valor. Me inclino por este punto de vista, ya que hace posible construir una cosmovisión consistente usando solo un tipo de formalismo.

PS En el cálculo puro de lambda, 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 de base y constantes, y luego incluye un sistema de tipo estático para lambda o regresa a las etiquetas de tipo dinámico.

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

Untados y tipados dinámicamente no son sinónimos. El lenguaje que con más frecuencia se denomina "sin tipo" es el cálculo Lambda, que en realidad es un lenguaje unificado; todo es una función, por lo que podemos demostrar de forma estática que el tipo de todo es la función. Un lenguaje de tipado dinámico tiene varios tipos, pero no agrega una forma para que el compilador los compruebe estáticamente, forzando al compilador a que inserte verificaciones de tiempo de ejecución en los tipos de variables.

Entonces, JavaScript es un lenguaje de tipado dinámico: es posible escribir programas en JavaScript de modo que alguna variable x podría 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 algún problema matemático difícil), por lo que puede aplicar x a un argumento y el navegador debe verificar en tiempo de ejecución que x es una función.

Sí, esta es una práctica estándar en la literatura académica. Para entenderlo, ayuda 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 y bien establecido.

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

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

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

Él también comenta:

La palabra "estática" a veces se agrega explícitamente; hablamos de un "lenguaje de programación tipado estáticamente", por ejemplo, para distinguir los tipos de análisis en tiempo de compilación que estamos considerando aquí a partir del tipeo dinámico o latente encontrado 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 los diferentes tipos de estructuras en el montón. Términos como "tipeados dinámicamente" son posiblemente términos inapropiados y probablemente deberían ser reemplazados por "comprobados dinámicamente", pero el uso es estándar.

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

Tenga en cuenta que esto no quiere decir 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, resulto ser un investigador académico en sistemas de tipos y un implementador no académico de JavaScript, así que tengo que vivir con el schisma. :)