¿Qué es lo que más te asusta del IDE integrado de la mayoría de los Smalltalks modernos?

Question

Como soy riding the wave of resurgence of Smalltalk (especialmente porque muchas personas de Ruby-on-Rails están redescubriendo Smalltalk y viendo Seaside como su próximo marco web actualizado), recibo preguntas como "sí, pero ¿cómo uso mi editor favorito para editar el código Smalltalk? ? " o "¿Smalltalk todavía insiste en vivir en un mundo propio?".

Ahora, having first experienced Smalltalk back in 1981, no entiendo estas preguntas muy bien. Parece bastante natural que desee que el editor y el depurador sean conocedores de mi estado de código actual, e integren con el sistema de control de cambios que es compatible con Smalltalk. Usar un editor o depurador externo o un administrador de control de cambios parecería muy incómodo.

¿Qué es lo que más te asusta de no poder editar los métodos de cinco líneas en Smalltalk con tu editor favorito, o usar tu sistema de control de cambios favorito que no sea Smalltalk?

Answer 1

Todo es diferente. ¿Quieres ir al final de la línea? No es Ctrl-E. ¿Quieres saltar algunas palabras, por palabra? No es Meta-F ...

La edición de texto es una actividad de programación fundamental . Meterme con esas entradas es meterme con algo en lo profundo de mi mente.

Editar: y aquí está someone asking for emacs key bindings en comp.lang.smalltalk en .

Answer 2

Nada me asusta en particular, pero me pareció un poco complicado hacer las API en VW, incluso cuando había usado otros smalltalks. El efecto de los navegadores es que tienden a ver las API un poco a la vez y, a menudo, no es inmediatamente obvio dónde se debe buscar una funcionalidad particular.

Smalltalk también sufre un poco del cambio de paradigma para entender cómo funciona. Cuando estaba haciendo mi licenciatura en la universidad (un tiempo después de conocer a Smalltalk por primera vez) pude disfrutar de un poco de Schadenfraude viendo a todos los demás en la clase superar el paradigma inicial mientras aprendían el sistema (Squeak) por primera vez. hora.

Creo que la combinación del cambio de paradigma y la funcionalidad queda algo enterrada en las bibliotecas de clase, lo que hace que la curva de aprendizaje sea un poco empinada. ST se ganó la reputación de tener una curva de aprendizaje bastante empinada: la mayor parte de esto se debe a las grandes bibliotecas de clases y al hecho de que la mayor parte de la funcionalidad del lenguaje está enterrada en alguna parte de las bibliotecas.

También (y lamentablemente), Java surgió a mediados de la década de 1990 y acaparó todo el interés. Los Smalltalks principales han muerto completamente o han sido vendidos a jugadores de nicho. Es bastante irónico (de una manera feliz) que Ruby haya servido para volver a despertar el interés en Smalltalk, pero la persistente percepción de la obsolescencia "también funciona" no ayuda.

Para más pontificación sobre los méritos (como los veo) de involucrarse mucho en Smalltalk en este día y edad. Ver This post of mine.

Estaría encantado de volver a Smalltalk si surgiera la oportunidad.

Answer 3

El único gran obstáculo para mí es que el código que escribo, Smalltalk VM es STILL, después de todos estos años, no es compatible con otras Smalltalk VM.

Entiendo por qué es así: el núcleo de Smalltalk es un conjunto extremadamente pequeño de axiomas y palabras clave.Esto significa que después de 30 minutos de aprendizaje de Smalltalk, ya está aprendiendo la biblioteca API en lugar del idioma en sí. Me gusta ese enfoque para el diseño del lenguaje.

Sin embargo, en el mundo de Smalltalk, a menos que se llegue a un consenso entre todos los proveedores de VM para tener una base común API estándar, mi código Smalltalk escrito para una VM prácticamente no se ejecutará otras máquinas virtuales cuando decido cambiar.

Esto también tiene el corolario de una parte obsoleta de mi conocimiento del espacio cuando cambio de máquinas virtuales.

Tenga en cuenta que apenas he probado Smalltalk en mi vida. Estoy lejos de ser un experto. Este entendimiento proviene de hablar con James Robertson hace aproximadamente un mes.

Otro punto que me gustaría comentar es que Seaside se ejecuta en las máquinas virtuales más populares de Smalltalk. Me pregunto cuánto de (lo que debería haber sido) una API estándar que tuvieron que construir ellos mismos para lograr esa hazaña.

Con todo lo dicho, siempre tengo un oído para escuchar más sobre el estado de Smalltalk. I do quiero probar el entorno de desarrollo muy potente de Smalltalk (y sus otras ventajas).

Answer 4

El único Smalltalk en el que he pasado algún tiempo es Squeak, por lo que mis opiniones pueden no aplicarse a otros entornos de Smalltalk.

Lo que me preocupa del enfoque basado en imágenes es que, si bien tiene cosas maravillosas en el entorno de Smalltalk, es un jardín amurallado que dificulta la interoperación con cualquier cosa fuera de ese entorno. Por ejemplo, ¿qué sucede si quiero usar herramientas externas como Yacc y Lex? ¿Qué pasa si quiero usar algunos programas C o Python para generar código Smalltalk? ¿Qué sucede si quiero mezclar Smalltalk con un montón de código escrito en otros idiomas, editando el código en todos esos idiomas en un editor y manteniéndolo todo almacenado en el mismo árbol de código fuente?

Estoy seguro de que es posible hacer frente a todos estos problemas haciendo que su entorno Smalltalk invoque funciones del sistema para controlar herramientas externas. Pero, ¿qué tan fácil es dejar que las herramientas externas controlen su entorno Smalltalk? En otras palabras, ¿qué pasa si quiero que Smalltalk sea solo otro componente, en lugar de ser el maestro de todo?

Answer 5

Mientras que el entorno de Smalltalk restringido el hecho cosas como depender en un sistema de control de origen de base de datos impulsada posible en momentos en otros idiomas todavía luchaban con tener un editor adecuado, hace que la integración muy difícil en los tiempos de hoy.

Con herramientas como Eclipse o Team Foundation Server, se acostumbra a tener todas las herramientas integradas entre sí. P.ej. si se crea un requisito, se vincula automáticamente a los conjuntos de cambios que el programador se compromete a implementar ese requisito. Esta "ruptura de límites" entre herramientas anteriormente diferentes es casi imposible en el mundo de Smalltalk, pero con proyectos más grandes, equipos más grandes, niveles más altos de abstracción, necesita herramientas que son más que un editor elegante y lo ayudan a lo largo de un desarrollo de software completo. ciclo vital.

Answer 6

Para el mundo de Windows, no hay nada como Dolphin Smalltalk. El IDE es fantástico. Otro producto de calidad si quieres probar es Visualworks, funciona bien, tiene una VM muy rápida y la documentación es bastante buena.

He usado ambos en el pasado, no hay nada que temer.

Answer 7

Sé que es tarde, pero la mayor molestia para mí es que no hay realmente un buen editor en ninguno de los smalltalks. Es algo que no puedo entender. Trabajar con texto es tan esencial y menos "compatible" ...

Siempre es solo mirar un método y luego debes tener algún buscador de métodos u otro navegador para simplemente verificar otro método. Esto es lo que realmente no me gusta ...

Answer 8

No hay soporte útil para navegar con el teclado o para soportar el comportamiento de la interfaz de usuario de la plataforma.

Si bien es cierto que realmente no necesita un editor de texto increíble para (bien escrito) Smalltalk, ser capaz de moverse por el entorno mientras mantiene sus manos sobre el teclado es bastante útil (y en mi caso, esencial para reduciendo el RSI). Solo estaba intentando el inspector de VisualWorks y las teclas de flecha ni siquiera funcionaban correctamente para subir y bajar una lista. Cuando presiono la barra espaciadora, obtuve un retroceso. Suspiro.