IDEs para idiomas dinámicos: ¿hasta dónde puede llegar?

Smalltalk, un lenguaje altamente dinámico, siempre ha tenido un IDE excelente, en el que pequeñas cosas como la refactorización automática, SUnit (el abuelo de todos los * marcos de unidades), "¿quién envía este mensaje?", "¿Quién implementa este método? " y similares fueron pioneros. Así que sí, los IDE pueden admitir lenguajes dinámicos a un nivel que, hasta hace muy poco, superaba con creces los de los lenguajes de tipo estático.

S. Lott dice que "los idiomas dinámicos no pueden tener el mismo tipo de código que los lenguajes estáticos. Es esencialmente imposible".

¿"Esencialmente imposible" en un sentido teórico y absolutista? Por supuesto. ¿En un sentido práctico? Realmente no. Hay muchas maneras de inferir el tipo para lenguajes dinámicos, estáticamente ( k-CFA , RoelTyper ), en tiempo de ejecución ( PICs ), y otros métodos, como usar la historia reciente de un programador - " Cómo el historial del programa puede mejorar la finalización del código ".

Ciertamente, las comunidades Pharo y Squeak están muy contentas con sus herramientas para completar el código .

Todo lo que sabes de IDE se desarrolló por primera vez en Smalltak, que es un lenguaje dinámico. Todo lo demás es simplemente copiarlos. Claramente, todas estas características son posibles en lenguajes dinámicos.

Hoy en día, los lenguajes dinámicos están detrás de los lenguajes estáticos. ¿Pero por qué?

Hasta hace poco, se pensaba universalmente que la tipificación estática era superior a la tipificación dinámica. Muchos programadores han cambiado de opinión más recientemente sobre ese punto. El enfoque en los IDE para los idiomas escritos dinámicamente no estaba allí.

Creo que las características de los IDE son menos útiles en los lenguajes de tipo dinámico. Al trabajar en Java o en Objective-C, creo que el IDE es necesario para ayudarme a trabajar con el lenguaje, pero no ocurre lo mismo con los lenguajes dinámicos.

Algunas partes de la tarea son más fáciles en un lenguaje estático. Es sencillo averiguar el tipo de expresión. Hacer lo mismo en un lenguaje dinámico requiere un análisis completo del programa o el registro de los tipos durante el tiempo de ejecución. Dado que gran parte de lo que el IDE gira en torno a los tipos, eso tiene un efecto.

Me encontré con ese problema con python, algo así. Quería vim como mi editor, pero eso significaba que no tendría un entorno IDE. Entonces, me lancé mi propio con vim plugins. Actualmente, creo que realmente tengo un mejor entorno de desarrollo que cualquier IDE que haya usado en el pasado.

Mi configuración se encuentra en github , siéntete libre de echar un vistazo y cuna de lo que quieras. Para una visión general rápida de los complementos:

• patógeno
• modo python, para la integración de rope, pyflakes y pydoc
• vimpdb para un depurador de python
• proyecto para una lista de archivos en un proyecto
• lista de etiquetas para saltar la etiqueta
• supertab para completar la pestaña
• snipmate for snippets
• conqueterm para un shell integrado, ya sea símbolo del sistema, bash, python o ipython

Hay algunas otras cosas, pero tiene todas las características que tienen los IDE más populares. No me costó ni un centavo, y puedo aprovechar todo el poder de vim. Divisiones, comandos de movimiento, registros, saltos, poder ejecutar todo mi entorno de desarrollo con el teclado ...

  

¿Algún IDE en particular (o menos configuraciones todo en uno) ha logrado un soporte totalmente excepcional para un lenguaje dinámico,

Teniendo en cuenta que su evaluación es difícil de entender (¿"totalmente excepcional"?

La comparación trivial con Eclipse + Java es tonta porque los lenguajes dinámicos no son Java.

  ¿

o sigue siendo un problema "sin resolver"?

No del todo.

Es probable que no pueda resolverse. Sus requisitos ("falta de terminaciones y otros activos") hacen que sea difícil ser más precisos.

Los idiomas dinámicos no pueden tener el mismo tipo de finalización de código que los lenguajes estáticos. Es esencialmente imposible.

Algunos IDE hacen un buen trabajo de adivinar. Eclipse, por ejemplo, tiene complementos para lenguajes dinámicos.

Creo que esta presentación de Steve Yegge sigue siendo relevante. En pocas palabras, hay algunos ides de script Java medio decentes (intelliJ IDEA), pero los lenguajes dinámicos en general se están poniendo al día, no porque haya algo intrínsecamente difícil en hacer estas herramientas (o incluso en los idiomas) son solo los lenguajes estáticos. Toda la atención primero.

Programo todo el día en javascript / php y ruby trabajando en aplicaciones web y el mejor IDE que he encontrado para esto es Aptana. Tiene código completado para los tres idiomas (y python) recoge mis vars locales y además de eso, al trabajar con html y css, recoge los ID en el html para usarlos en css / javascript. y recoge nombres de funciones para cuando estoy haciendo algo rápido y sucio y escribo javascript en línea (lo sé mal, pero a veces es útil como prueba de concepto). Ha incorporado tareas de rake y soporte integrado para git y una consola de línea de comandos. Me tomó un poco levantarme, pero una vez que lo hice me di cuenta de que casi nunca salía de mi IDE cuando estaba programando y me ahorra mucho tiempo.

Descubrí que el soporte de Wing IDE para Python es realmente excepcional. Hace un buen trabajo al completar el código, y su depurador es tan poderoso como el de Visual Studio para el C # no dinámico.

Puedo dar fe de que no está lleno de errores, lento o despistado. Nunca he usado Eclipse, así que ignoro este punto, pero creo que la pregunta más importante es: ¿existe alguna barrera inherente para desarrollar un IDE completo y que aumente la productividad para lenguajes dinámicos? Dada mi experiencia con Python y Wing, me inclino a decir que no es así. Sin embargo, es ciertamente más difícil.

Visual Studio de Microsoft es un IDE que utilizan muchos programadores y es compatible con IronRuby , IronPython y F #. La mayoría consideraría a Ruby y Python como un lenguaje de programación dinámico, mientras que F # lo sería menos.

En respuesta al comentario, F # es un lenguaje de programación.

  

F # (pronunciado F Sharp) es un lenguaje de programación multi-paradigma,   orientado a .NET Framework, que abarca la programación funcional   así como disciplinas de programación imperativa y orientada a objetos. Eso   es una variante de ML y es ampliamente compatible con el OCaml   implementación.

Si bien la definición exacta de qué define exactamente un "lenguaje dinámico" todavía está en discusión, la mayoría estaría de acuerdo en que JavaScript es más "dinámico" que C #, por ejemplo. Según Wikipedia:

  

La definición de un lenguaje dinámico es ambigua porque intenta   para hacer distinciones entre el código y los datos, así como entre   Recopilación y runtime que no son universales. Maquinas virtuales,   compilación justo a tiempo, y la capacidad de muchas programaciones   Los idiomas en algunos sistemas para modificar directamente el código de máquina hacen que el   distinción abstracta. En general, la afirmación de que una lengua es   dinámico es más una afirmación sobre la facilidad de uso de las características dinámicas   que es una declaración clara de las capacidades del lenguaje.

No quiero abrir una lata de gusanos aquí. Algunos sugerirían que F # se describe más correctamente como un lenguaje funcional en lugar de dinámico, y no me gustaría hacer una excepción. Lo que creo que sería justo decir que es de los diversos lenguajes .Net, F # generalmente se considera más apropiado para la programación dinámica que C # o VB.

Es posible que desee ver: ¿Qué califica un lenguaje de programación como dinámico?

La principal diferencia entre los idiomas tipificados estáticamente y los idiomas tipificados dinámicamente es que el sistema puede saber, con seguridad, qué significa una referencia de símbolo en el momento de la compilación.

Esto hace que sea realmente fácil recopilar la información que necesita para hacer un buen IDE directamente de la información generada por el compilador en el momento de la compilación (que simplemente se mueve al tiempo de "edición" en su mayor parte).

Si tiene una firma de método independiente que simplemente dice que el método toma una "Cosa", ¿cómo puede un editor ayudarlo a saber qué enviar? ¿Cómo puede ayudar a sugerir maneras de usar la cosa?

La escritura de pato tampoco ayuda aquí, incluso el editor más inteligente posible no podrá decirte que simplemente porque tu objeto tiene un método .executeFooOp () que puede completar el código ".executeBarOp" en ese objeto (aunque podría rastrear el resto de la base del código y hacer algunas conjeturas inteligentes).

Si sabes que es una "Cadena" en la firma, sin embargo, conoces todos los métodos que podrías llamar en esa cadena Y puedes sugerir esa variable cuando ese usuario está escribiendo una llamada de método. que requiere una cadena como parámetro. Incluso podría sugerir subclases en las que se podría convertir si quisiera.

La información simplemente no está allí con idiomas tipificados dinámicamente a menos que pueda hacer un análisis completo de la base de código completa con algo MUCHO más inteligente que su compilador típico.

Al menos para PHP, muchos IDE "entienden" algo como

/** @var $foo ClassA **/

Si documenta de forma estandarizada (en este caso phpDocumentor ) el IDE aprovechará al máximo.

De todos los IDE para idiomas dinámicos (idiomas que resuelven el tipo en tiempo de ejecución), el mejor es ... Visual Studio para Python

• Información de tipo de bulling para Intellisense
• navegación
• depuración

Vale la pena intentarlo.