ruby on rails - ¿Qué es lo que más te asusta del IDE integrado de la mayoría de los Smalltalks modernos?
ruby-on-rails seaside (8)
Mientras estoy montando la ola de resurgimiento de Smalltalk (especialmente porque muchas personas de Ruby-on-Rails están redescubriendo Smalltalk y viendo a Seaside como su próximo framework web mejorado), 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, después de haber experimentado Smalltalk por primera vez en 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 y se 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.
Entonces, ¿qué es lo que más te asusta al 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 no compatible con Smalltalk?
El único Smalltalk en el que he pasado 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?
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 compatible con otras Smalltalk VM.
Entiendo por qué eso 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, todo se reduce a que, a menos que todos los fabricantes de VM tengan un consenso para tener una API estándar común, mi código Smalltalk escrito para una máquina virtual es casi seguro que no se ejecutará en otras máquinas virtuales cuando decide cambiar
Esto también tiene el corolario de obsoleta parte de mi conocimiento del espacio cuando cambio VM.
Tenga en cuenta que apenas he probado Smalltalk en mi vida. Estoy lejos de ser un experto. Este entendimiento viene de hablar con James Robertson hace aproximadamente un mes.
Otro punto que me gustaría destacar es que Seaside se ejecuta en la mayoría de las MV 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. Quiero probar el entorno de desarrollo muy potente de Smalltalk (y sus otras ventajas).
No hay nada que me asuste en particular, pero me resultó un poco difícil calcular 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 tanto abrupta. 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 clase 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 apareció a mediados de la década de 1990 y se hizo con 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.
Ver este post mío para una pontificación sobre los méritos (como los veo) de involucrarse fuertemente en Smalltalk en este día y edad.
Me encantaría volver a Smalltalk si surgiera la oportunidad.
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 reducir 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.
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.
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 esto solo mirar un método y luego necesitas tener algún buscador de métodos u otro navegador para simplemente verificar otro método. Esto es lo que realmente no me gusta ...
Si bien el entorno restringido de Smalltalk hizo que cosas como confiar en un sistema de control de origen controlado por bases de datos fuera posible en momentos en que otros idiomas aún tenían problemas para tener un editor adecuado, hace que la integración sea muy difícil en los tiempos actuales.
Con herramientas como Eclipse o Team Foundation Server, se acostumbra a tener todas las herramientas integradas entre sí. Por ejemplo, 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.
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í hay alguien pidiendo enlaces de teclas de emacs en comp.lang.smalltalk en 1987 .