smalltalk - animal - squeak food
¿Por qué Smalltalk no es popular? (30)
¿No es así? De acuerdo con la lista de TIOBE, es # 44 en este momento. # 44 en el mundo parece bastante malditamente popular, ¡para mí! (Porsche también ocupa el puesto # 40 en el mundo, en términos de popularidad, pero nadie parece preguntarse "¿Por qué Porsche no es popular?"). Hemos logrado grandes avances en el uso de protocolos abiertos basados en texto; a quién le importa si alguien más usa el mismo lenguaje de programación?
Especialmente para un lenguaje de computadora que tiene 40 años de antigüedad. ¿Cuántos otros idiomas de las décadas de 1950 y 1960 ve actualmente en uso? Veo, de los mejores 50, solo otros 6: Logo , Pascal , RPG , COBOL , Lisp y Fortran . Hay una gran cantidad de idiomas con alta popularidad instantánea, pero es muy probable que caigan de la lista en menos de 40 años.
Consideraría un lenguaje de top 50 que ha estado allí para que dos generaciones (¡humanas!) Sean mucho más sólidas que un lenguaje de top 10 que ha estado ahí por solo tres o cuatro años. El último es probablemente una moda pasajera; el primero es un clásico probado.
Shakespeare , Twain y Poe no son los mejores 50 autores este año, pero bien pueden ser los mejores 50 autores en los últimos 40 años, y creo que es bastante probable que sean los 10 mejores autores en el último siglo. Todos usan un protocolo abierto, basado en texto (¡inglés!), Así que no importa que la persona que está a mi lado en el autobús esté leyendo una moda pasajera como Danielle Steel .
He estado mirando Smalltalk (VisualWorks) durante los últimos meses, y cuanto más aprendo, más me impresiona. Sin embargo, creo que me debería estar perdiendo algo, ya que Smalltalk no parece ser popular en estos días, y tal vez nunca lo fue.
¿Qué saben las personas que han abandonado Smalltalk a favor de Java, C ++, Ruby, etc., que no lo hago o, en otras palabras, "¿por qué Smalltalk no es más popular?"
Al ver esta pregunta como un Smalltalker desde hace mucho tiempo, ganando todos mis ingresos haciendo aplicaciones web en Smalltalk durante 12 años, ¿qué puedo decir al respecto?
Primero, ¿es esta una pregunta relevante en absoluto? ¿Por qué Smalltalk necesita ser popular? ¿No es una comunidad tan pequeña pero agradable y animada como ahora tenemos algo mejor que la gran comunidad?
Por otro lado, ser más popular es un buen punto de venta. Es difícil persuadir a los clientes para que vayan a un camino menos popular, porque se sienten menos seguros.
Pero, nuevamente, desde mi experiencia esto no es un problema para las aplicaciones web. A casi nadie le importa mucho lo que está ejecutando. Lo que les importa es el resultado. Es por eso que creo que el futuro de Smalltalk está exactamente en las aplicaciones web, porque aquí podemos explorar todas sus fortalezas sin tener que lidiar con esa pregunta una y otra vez.
Algunos enlaces para reflexionar sobre:
El clásico Peor es mejor . Aunque pertenece a Lisp , se aplican algunos de los mismos puntos. Una solución simple que no es del todo correcta es mejor que una solución compleja que es más difícil de transportar a través de varios límites.
Python.org . Esto no es para comenzar una guerra de idiomas, sino más específicamente, para mostrar lo fácil que es descargar, instalar y comenzar a trabajar en el idioma. Para Linux, ya está allí. Para Windows / Mac, es una instalación rápida de distancia. Cada uno viene con una gran cantidad de bibliotecas que brindan cosas como procesamiento XML, capacidades HTTP y documentación para todo. Tenga en cuenta que la página de instalación de Squeak no es tan fácil de usar.
Las bibliotecas también son muy importantes. Compare las bibliotecas de procesamiento XML para algo como Smalltalk y luego compare eso con el todopoderoso CPAN . Mientras tanto, cada versión diferente de Smalltalk tiene su propia biblioteca.
Un lenguaje de programación se puede ver como muchas cosas. Algunos lo ven como una forma de representar algoritmos y estructuras de datos. En este caso, los lenguajes como Smalltalk y Lisp y Haskell destacan. También se puede ver como una herramienta que hace un trabajo. Incluso si pueden maldecir la herramienta que usan, aún usarían lo que se necesita para hacer el trabajo.
Creo que las razones pueden tener poco que ver con los argumentos técnicos. Por ejemplo, la pregunta se enmarca en términos de "por qué Smalltalk se descartó a favor de Java". Me gustaría preguntar por qué Java sigue siendo mainstream cuando la tasa de fracaso de su proyecto es una de las más altas de la industria (según Gartner, http://www.zdnet.com.au/news/business/soa/Java-and-Net-both-a-disaster-research/0,139023166,120269968,00.htm ). Dado ese tipo de evidencia, esto no parece ser un fenómeno racional para mí, por lo que dudo que nosotros (es decir, los programadores) encontremos explicaciones adecuadas y racionales.
Antes de explicar "por qué Smalltalk no es popular", creo que sería mucho más interesante responder "¿por qué la mayoría de las tiendas de TI eligen una tecnología que está asociada al fracaso el 70% del tiempo"?
Difiere demasiado sintáctica y conceptualmente de lenguajes como C.
Cambiar de un lenguaje tipo C a Smalltalk puede parecer demasiado difícil para muchas personas, dado que muchos estudiantes y aficionados crecen aprendiendo lenguajes tipo C (C, C ++, Java, PHP, etc.).
Dos cosas se destacan en mi mente:
- Fue diseñado antes de que Unix ganara. En ese momento, aislarse del sistema operativo host parecía una gran idea, ya que tener un nivel de integración decente con todos los sistemas operativos en uso sería prohibitivamente difícil, y además haría las cosas que deberían ser simplemente ridículamente complicadas. - testigo de la flexión hacia atrás que Common Lisp tiene que hacer para soportar cosas como el sistema de archivos VAX . Ahora parece incómodo.
- La falta de implementaciones gratuitas. En ese momento, no se había demostrado que un lenguaje necesitara una implementación sólida impulsada por la comunidad para recoger el interés mental; la gente todavía pensaba que vender software era una buena forma de ganar dinero.
Parecen errores muy obvios en retrospectiva, pero supongo que tienes que estar allí.
En esta entrevista, Robert Martin da su punto de vista sobre esta discusión: http://pragprog.com/podcasts/show/32 .
En primer lugar, creo que Smalltalk es muy popular entre muchas industrias.
Muchas empresas lo juran. Como lenguaje de programación para el consumidor, obviamente no es popular porque:
- (por diseño) no prioriza la integración con los sistemas operativos Windows o Linux
- no es un lenguaje de programación para los sistemas de juego actuales (por no decir que no puede ser, Nintendo puede ser el primero en experimentar con esto)
- no es un lenguaje de programación para los teléfonos inteligentes actuales (por no decir que no puede ser) y
- conceptualmente muy diferente del modelo estándar basado en C
Smalltalk sobresale como un ''entorno'' rico en objetos DSL que lo hace ideal para soluciones de software personalizadas entre las principales compañías orientadas a la producción. Los lenguajes de programación basados en C esencialmente ganaron terreno por la misma razón que el teclado QWERTY diseñado, pasó a ser utilizado a gran escala (computadoras de PC domésticas) ya que se basaban en sistemas operativos escritos principalmente en C. En comparación, puede ser menos que Smalltalk no es popular y más que otros lenguajes basados en C son tan populares que solo hacen que Smalltalk parezca impopular.
En un sentido, la premisa es falsa. Smalltalk tuvo un alto punto de popularidad en la década de 1990 cuando se utilizó en aplicaciones de alta gama en un número razonablemente grande de instalaciones, particularmente en la industria financiera en el área de NYC.
Pero la razón principal es que Smalltalk es demasiado amplio para superar las fuerzas de inercia en la industria de TI que favorecen los enfoques de menor denominador común. Por esa razón, no hay lenguajes de propósito general de gran popularidad que se desvíen radicalmente de los ALGOL , en su mayoría variantes basadas en C.
Otro factor es la insularidad de la cultura Smalltalk, un caso especial de culturas lingüísticas provinciales que se ve un tanto agravado por la fuente, la imagen, el cambio triple, que es ideal para cosas del universo, menos para interactuar con el mundo más amplio de la informática.
Estaba usando Smalltalk comercialmente de una manera pequeña en 1995. (Escribí el libro blanco de mi compañía sobre Java al mismo tiempo. IIRC Dije que Java necesitaba 2-3 años más para madurar).
En 1998, Smalltalkers abandonó Java.
Las licencias de los proveedores son muy caras. Squeak es mágico por el precio (nada).
El hardware requerido fue escandaloso: tuvimos un SUN UltraSparc temprano con 1 GB de RAM en 1996. Era un servidor de aplicaciones Smalltalk. ¡Para una aplicación de 3-tier ! Con menos de 50 usuarios !! (Tenga en cuenta que cada campo en cada pantalla se ha llenado desde la base de datos en su propio hilo. Hecho para una interfaz de usuario muy ingeniosa).
Las bibliotecas NO son lo mismo entre proveedores, por lo que se bloquea.
Las características básicas del entorno son diferentes entre proveedores: la reflexión es rizada.
Básicamente, los vendedores de Smalltalk han balcanizado el mercado desde la década de 1980, y todavía está fragmentado.
Desde un punto de vista técnico, Samlltalk pisotea la mayoría de los otros idiomas para aumentar la productividad. NeXT copió el enfoque basado en imágenes de Smalltalk para Objective-C , y se hace muy bien (basta con ver todos los productos actuales de Apple).
Fui programador de Smalltalk en la década de 1990, y luego más recientemente. Me sorprende que pueda relacionarme con casi todas las personas que escribieron sobre este hilo (con algunas excepciones).
Sí, a mediados de la década de 1990, los vendedores se salieron del mercado en ciernes, no lograron meterse en Netscape, y básicamente se hicieron abuchear en el escenario.
El ingenio particular que vino del entorno de Smalltalk fue producto de su fuerza inherente, que todavía está allí. Smalltalk tiene el potencial de reinventarse a sí mismo, o redescubrir más precisamente su propósito para una nueva era.
Como Smalltalk no es muy famoso, es difícil conseguir contratos, y los verdaderos Smalltalkers a menudo se trasladan de una ciudad a otra para realizar compromisos. Por otro lado, la comunidad de Smalltalk, para bien o para mal, significa que las personas realmente se conocen entre sí. En estos días, ser parte de una comunidad, incluso uno nerd, tiene sus ventajas. Hablando profesionalmente, la gente sabe quién es usted. Dado que Smalltalk tiende a atraer a los rebeldes y soñadores, como yo, es un buen lugar para estar.
Había que estar allí en 1995. En ese momento, había algunos Smalltalks comerciales, pero el más grande era VisualWorks de ParcPlace Systems. Los vendedores en ParcPlace eran idiotas, eligiendo optimizar para max dollers por asiento en lugar de asientos máximos. Cualquier tienda que desee adoptar Smalltalk tuvo que pagar un par de miles de dólares por desarrollador por una licencia. Cualquier desarrollador que desee aprender Smalltalk debe ser contratado para hacer Smalltalk o invertir dinero en efectivo para comprar su propia licencia. Entonces fue simplemente difícil tener la oportunidad de aprenderlo.
También en ese momento, IBM estaba buscando un sucesor de COBOL para sus clientes comerciales. Eligieron Smalltalk (inteligente) y desarrollaron VisualAge y lo hicieron para que el mismo programa pudiera ejecutarse sin modificaciones en todo, desde mainframes hasta AS400 y PC. Smalltalk tiene una sintaxis mínima amigable y es fácil de aprender, por lo que parecía un reemplazo natural para COBOL. El futuro se veía realmente brillante para Smalltalk. Las compañías que lo usaban estaban superando a todos los demás por mucho.
Entonces Sun apareció con Java. Lo regalaron gratis en lugar de cobrar por ello. IBM lo miró e imaginó dos cosas. Primero, no querían entrar en una guerra de marketing con Sun que claramente planeaba gastar una fortuna en la marca Java. En cambio, decidieron intentar vencer a Sun en su propio juego: tener la mejor Java del mercado. Por qué no, ya tenían una gran máquina virtual que funcionaba con toda su pila; simplemente la adaptaron para manejar el conjunto de códigos byte de Java. De hecho, todas las herramientas de Java de IBM se escribieron realmente en Smalltalk durante varios años. Por lo tanto, si uno quiere culpar a alguien por el aumento de Java sobre Smalltalk, es bastante fácil echar la culpa directamente a los pies de IBM y su falta de voluntad para competir.
Amo Smalltalk. Me encanta codificar en el depurador, poder archivar procesos y restaurarlos exactamente más tarde si encuentran excepciones, la increíble fiabilidad. La economía de expresión y la brillante biblioteca de clases. Hay un nuevo resurgimiento en el desarrollo de Smalltalk gracias a Squeak. Newspeak, Pharo (que tiene algunas máscaras UI realmente bellas), el nuevo cog VM, Seaside y Gemstone, todos estos son proyectos que abordan las deficiencias históricas de Smalltalk, incluida la pobre integración del sistema operativo (Newspeak tiene una hábil integración de widgets nativos y Pharo / Squeak tiene una nueva capacidad de integración de código externo llamada Aliens) y despliegue / escalabilidad.
De todos modos, no me importa que Smalltalk no sea popular. Eso lo convierte en un arma secreta para mí y estoy muy animado de ver todos los nuevos proyectos de desarrollo. Smalltalk está creciendo y avanzando nuevamente y esto es bueno porque muchas de las mejores ideas en software (XP, pruebas unitarias, editores de refactorización, asistentes de codificación) fueron desarrolladas primero en Smalltalk y luego filtradas al resto del mundo (generalmente en formas diluidas).
Otra limitación en ese momento para Smalltalk era el empaquetado de aplicaciones y la falta de soporte dinámico de carga. Las aplicaciones grandes de Smalltalk tuvieron que reconstruir el archivo de imagen y volver a implementarlo para un cambio. Java proporcionó enlaces dinámicos en el tiempo de ejecución, lo que proporcionó muchos beneficios a las aplicaciones empaquetadas. Para cuando Smalltalk agregó la carga dinámica, Java se ganó el reconocimiento en IBM, por lo que dejaron de invertir en Smalltalk.
Había un módulo que tenía en Uni que se llamaba algo así como Lenguajes de programación y Computación cliente-servidor y Concurrencia . Una cierta parte de este módulo fue dedicada, como su nombre indica, a los lenguajes de programación en general. Smalltalk fue mencionado casi tanto como ALGOL 60 . ¿Y te preguntas por qué nadie quiere seguir el camino de SmallTalk?
Creo que la influencia de las instituciones de educación superior es mayor de lo que uno pensaría. Estamos hablando de masas de ingenieros de software / informáticos, etc ... dejando Uni''s cada año con un modelo mental centrado en Java.
Hablando como alguien que ha usado VisualWorks en la escuela, hay algunas cosas que me resultan molestas. El mayor fue el uso forzado (sí, forzado) del entorno de la imagen. 2/3 a través de mi proyecto, el entorno de la imagen se coló cuando tenía una ventana en particular abierta. Eso causó que la ventana apareciera cada vez, abrí el ambiente, a pesar de muchos esfuerzos para corregir este problema. También encontré (lo que vi como) el espacio de nombres débiles y el alcance irritante. "Todo es un objeto" suena genial hasta que te das cuenta de lo que significa, que 3 + 4 * 7 = 49. Y aunque entiendo de dónde viene el tipado de pato, todavía prefiero la comprobación estática de tipos. La sintaxis no fue tan intuitiva; Sé que Java es detallado, pero en realidad es fácil de leer y escribir, especialmente (obviamente) para alguien que proviene de un fondo de C / C ++. Esto es cierto incluso si Java es (casi igual) distinto de C / C ++ donde cuenta (por ejemplo, gestión de memoria y modelo orientado a objetos).
Pero sí respeto ciertos aspectos, en particular las muchas características que originó, como una fuerte reflexión y cierres poderosos.
Hay una excelente charla de Robert Martin en RailsConf ''09: " Lo que mató a Smalltalk también podría matar a Ruby ".
TLDR: "¿Qué mató a Smalltalk? Era demasiado fácil hacer un desastre". - Ward Cunningham
Hay una serie de razones por las cuales Smalltalk no se "incendió", la mayoría de ellas históricas:
cuando se introdujo Smalltalk, estaba demasiado adelantado a su tiempo en términos de qué tipo de hardware realmente necesitaba
En 1995, cuando Java fue lanzado con gran fanfarria, uno de los principales vendedores de Smalltalk (ParcPlace) estaba ocupado fusionándose con otro (Digitalk), y esa fusión terminó siendo más una pelea de cuchillos.
En 2000, cuando Cincom adquirió VisualWorks (ObjectStudio ya era un producto de Cincom), Smalltalk se había desvanecido de la escena del "lenguaje de la cadera"
Desde entonces, Smalltalk ha sido un pequeño jugador en el espacio del lenguaje, pero ha vuelto a tener un mercado en crecimiento. Hay dos ofertas comerciales (Cincom es el jugador más grande allí), y de código abierto ( Squeak y Pharo, que en su mayoría están bajo la licencia MIT, y GNU Smalltalk , que es GPL).
No todas las implementaciones de Smalltalk requieren una imagen; mientras que a los que nos venden en un ambiente de imagen nos encanta, puedes usar GNU Smalltalk con tu editor de texto favorito con la suficiente facilidad.
En última instancia, Smalltalk alcanzó su punto máximo temprano, y luego sufrió daños por la estupidez de los primeros vendedores en el espacio. En este momento, eso es todo en el pasado, y yo diría que el futuro parece bastante brillante.
La última vez que revisé la documentación me desanimó. ¿Por qué demonios debería poner marcadores de colores en mi mouse solo para entender de qué están hablando? ¿Es tan difícil llamar a los botones izquierda, derecha, medio? Ver el comienzo de Squeak por ejemplo
En cambio, son colores y constantemente tengo que buscar qué botón significa. Esta no es una buena idea para entrar en un flujo.
Probé a Squeak. Y no sé cómo alguien podría implementar una aplicación Squeak para personas "normales".
La razón principal parece ser litro tras litro de desinformación, fermentando a la percepción errónea de los galoons. La razón secundaria es probablemente el mal paso de ParcPlace a mediados de la década de 1990, y el tercero es probable que pierda un mega jugador, ya que IBM se desvió para participar en una guerra de desgaste guiada por Microsoft, siendo absorbida por el agujero negro de un colapso Sol.
Popular, como Paris Hilton ?
O tranquila búsqueda de artesanía, inmerso en la alegría de trabajar con grandes herramientas, que también persisten, mejoran y crecen, aunque en relativa oscuridad.
Para cada uno, supongo.
Después de haber utilizado muchas, muchas, muchas herramientas a lo largo de los años, puedo decir que Smalltalk simplemente vale la pena el precio de la admisión, cualquiera que sea el precio que parezca.
- Acércate. Debida diligencia y todo eso.
- Solo mejorará las cosas para todos nosotros.
- Incluso podrías arruinarlo, hacerlo salvajemente "popular", y aún así saldríamos adelante. Es tu decision.
Las enormes imágenes fricken.
Son una forma horrible de distribuir software. Obtenga con el programa, haga una versión distribuible de Smalltalk que haga ejecutable o al menos paquetes propios y tenga acceso a los kits de herramientas de GUI normales o al menos se vean iguales.
Las únicas personas que realmente pueden usar el lenguaje son aquellos que se ejecutan en servidores, a la, aquellos que no tienen que distribuirlo.
Licencia muy tonta. Hubo una versión maravillosa de Smalltalk en la década de 1990 que ofrecía todo lo que un desarrollador necesitaba: excelentes herramientas, excelente desarrollo multiplataforma, buen rendimiento y confiabilidad. Esto fue VisualWorks .
Tampoco fue particularmente costoso. Estaba preparado para buscar proyectos importantes, después del éxito pasado con Digitalk Smalltalk. Pero luego, la compañía productora de VisualWorks fracasó, y VisualWorks fue absorbida por una empresa (a quien no pondré en ridículo al nombrar) que cambió lo que hubiera sido una simple compra de un producto de desarrollo en un acuerdo de licencia absurdo que requería un ir y costosa "relación con el cliente".
Al hacerlo, mataron las posibilidades de que este maravilloso producto se convirtiera en la corriente principal. Al mismo tiempo, Sun estaba suministrando Java de forma gratuita. Multiplataforma, proveedor múltiple (Sun e IBM vms), seguro, con una sintaxis familiar para los desarrolladores de C. También hacen un gran esfuerzo para optimizar la JVM , lo que significa que en estos días Java puede competir fácilmente con C en términos de velocidad.
Estos días desarrollo en Java, Groovy y Scala en la JVM. Pero echo de menos el desarrollo de Smalltalk.
Muchas razones, algunas de las cuales son:
- Tarifas ridículas de licencias de los principales actores comerciales
- Incapacidad para usar controles GUI nativos en algunas implementaciones originales
- No basado en archivos, tan difícil de integrar con otras herramientas de compilación
- Mala documentación: todavía no hay un libro "clásico" de Smalltalk para Smalltalk que K&R haga por C, y la ayuda en línea en el IDE consiste en comentarios en el código fuente
- Entornos de desarrollo anticuados: la combinación navegador / espacio de trabajo fue genial en su momento, pero parece cansada en comparación con los IDEs modernos. La edición de texto es particularmente ingenua.
- Fealdad: si un Smalltalker puede elegir una letra fea, pequeña o ilegible o un esquema de color repugnante, lo hará infaliblemente
- La falta de una "aplicación asesina" - para C esto fue Unix, para la programación de Windows C ++ y para Java y otros la Web.
Habiendo dicho eso, utilizo Smalltalk ( Squeak ) y disfruto golpeando las ideas y herramientas de GUI usándolo, pero solo para el entretenimiento personal.
Actualización a partir del 29 de julio de 2010: Habiendo dicho todo lo anterior, que defiendo, la última versión de Squeak (4.1) es una gran mejora en términos de apariencia y rendimiento. También tiene licencia de MIT, si eso es importante para usted. Vale la pena echar un vistazo si está interesado en Smalltalk.
Muy buena respuesta aceptada. Yo agregaría que los primeros sistemas de Smalltalk no estaban en términos de hablar con el sistema operativo host y sus aplicaciones nativas. Era como APL : si puedes vivir en este mundo extraño llamado "espacio de trabajo" o "imagen", todo es genial, pero si quieres usar tu gestor de ventanas habitual o dios prohíbe GNU Emacs , bueno, también podrías estar en Marte.
Creo que Squeak todavía tiene este enfoque, por eso prefiero a Ruby :-)
Primero, Smalltalk era bastante grande. Hubo un tiempo en el que solo había Smalltalk y C ++ como lenguajes OO de calidad de producción. Durante ese tiempo, Smalltalk lo hizo muy bien. IBM Smalltalk también era una alternativa a VW Smalltalk que muchos bancos y compañías de seguros optaron por usar como lo era de IBM (bueno, adquirieron OTI para conseguirlo).
Luego vino Internet y Java. Java estaba listo para Internet, pero Smalltalk no. Y, en particular, las personas del vendedor original de Smalltalk estaban convencidos de que Smalltalk era perfecto y no se le tenía que agregar nada. De esta forma, Smalltalk perdió la carrera con Java.
Luego también hay otras razones. Principalmente el concepto de imagen que diría. La sintaxis se menciona a menudo, pero Objective-C tiene el mismo estilo de listas de parámetros de métodos separados por dos puntos y a nadie parece importarle en el mundo de Objective-C.
Sin duda una respuesta polémica, y definitivamente personal, pero ... no me gustan los fanáticos.
La mayoría de los Smalltalkers con los que me he encontrado en la red intentan decir que Smalltalk es básicamente lo mejor desde el pan rebanado y lo horrible que es cualquier otro idioma. No digo que todos los Smalltalkers actúen de esa manera, pero ha sido una tendencia muy notable en los que me he encontrado. Claramente han estado despreciando a cualquiera que no use Smalltalk.
Esa no es una buena manera de persuadir a las personas a usar un idioma. Me desanima porque disfruto aprendiendo con una comunidad, y realmente no quiero ser parte de una comunidad que me desprecia, incluso si es solo una minoría vocal que adopta esa actitud.
No sé lo suficiente sobre Smalltalk para comentarlo técnicamente en absoluto, y realmente me gustaría aprenderlo "algún día" ... pero está más abajo en la lista de idiomas para aprender que otros en los que he tuvo una experiencia más positiva con la comunidad. (F # casi tuvo el mismo problema para mí, debido a que alguien tomó esa actitud en el grupo de noticias C #, pero afortunadamente han prevalecido personalidades más atractivas.) El hecho de que a la gente le guste tanto sugiere que hay cosas buenas sobre esto como tecnología. pero de manera realista, soy un ser humano en lugar de una computadora. El mérito técnico es solo una parte de la imagen.
Tal vez estoy solo en esto, pero en general: si quieres mostrarle a alguien cuán asombroso es tu cosa favorita, y tal vez convencerlos de que también deberían usarla, comenzar por desechar su herramienta actual es una mala idea. Los fanáticos del sistema operativo (de todo tipo) deben tomar nota.
Un par de personas han mencionado la sintaxis como un obstáculo para la adopción. Creo que hay un problema particular que aleja a un gran número de desarrolladores: la falta de reglas de precedencia algebraica.
Cualquier idioma en el que la expresión 2 + 3 * 4 tenga el valor 20 no será un éxito comercial. Sí, la sintaxis es muy regular, y sí, cualquiera que conozca a Smalltalk puede entender por qué las expresiones se evalúan tal como son. Desafortunadamente, va en contra de lo que le han perforado durante toda su educación primaria en matemáticas.
Cualquiera que esté aprendiendo Smalltalk y esté tratando de usarlo para hacer básicamente cualquier tipo de cálculo se encontrará con este problema repetidamente hasta que sepa que tiene que poner en paréntesis todo. Debido a que es solo un problema con algunas expresiones y causa resultados incorrectos, en lugar de un mensaje de error, les llevará mucho tiempo descubrir las primeras N veces que sucede.
Un porcentaje significativo de desarrolladores nunca superarán esto.
Una publicación de blog (ahora sin conexión) El Gran reinicio de la industria de programación responde a esto. Versión corta: los primeros microordenadores no podían ejecutar Smalltalk, y la cantidad de programadores crecía más rápido de lo que los nuevos podían ser educados por los antiguos. La cultura de la programación básicamente comenzó a principios de la década de 1980 en los microordenadores, y luego los programadores de microcomputadores tuvieron que pasar los siguientes 30 años pasando por los dolores de crecimiento que los programadores de mainframe / miniordenadores ya habían experimentado.
Entrada de blog rescatada de Wayback machine y publicada aquí:
El gran reinicio de la industria de programación MIÉRCOLES, 2 DE ENERO DE 2008
Hace un tiempo compré una copia de Structured Programming (ahora disponible como un PDF gratuito de la ACM), principalmente para poder leer el ensayo de Dijkstra "Notes on Structured Programming" (una versión expandida de EWD249). Además de "Notas sobre programación estructurada", contiene un ensayo de Hoare sobre "Estructuración de datos" y otro de Hoare y Dahl sobre "Estructuras de programas jerárquicos".
Fue este último, "Estructuras de programas jerárquicos", que terminó teniendo el mayor impacto en mí. Describe un lenguaje de programación llamado Simula 67. Simula 67 es una versión extendida de Algol 60, que contiene algunas capacidades de simulación adicionales. Tiene estas cosas llamadas "clases" que describen el comportamiento de un grupo de "instancias" individuales. Tiene esta cosa de "concatenación" que permite que una clase incluya todos los atributos y comportamientos de otra clase. También está esta función "virtual", y está tipicamente tipada y recogida de basura.
La similitud con Java era tan llamativa que estaba deprimido por días.
Luego, comencé a mirar un poco hacia adelante y hacia atrás desde Java y Simula 67, y encontré algunas similitudes interesantes entre una progresión de idiomas que ocurrió desde la revolución del microordenador y una progresión que ocurrió antes de la revolución del microordenador.
Estoy tratando de interpretar la historia aquí, una buena parte de la cual no sobreviví, así que me doy cuenta de que estoy entrando en territorio peligroso. Animo a aquellos de ustedes que vivieron esta historia a confirmar y / o negar cualquier parte de mi especulación que puedan hacerlo.
Estoy más familiarizado con la progresión más reciente, así que comenzaré allí. El 4k básico de Microsoft para Altair (que puedes probar en el simulador Altair basado en simh de Peter Schorn) comenzó un período de popularidad para Basic, seguido de uno para Pascal y C, C ++ y Java. Ignorando la recolección de basura en Basic, el orden aproximado en que se agregaron las características es:
Fórmulas
Estructuras de control de alto nivel (para bucles, bucles while, ifs con cuerpos de varias líneas, y similares) y funciones recursivas
- Clases, instancias, herencia, polimorfismo, etc.
- Recolección de basura
Noté que puedo construir una progresión muy similar desde Fortran a Algol 60 a Simula 67, con la excepción de que las características orientadas a objetos vienen más o menos al mismo tiempo que la recolección de basura.
Ahora me doy cuenta de que estoy escogiendo y eligiendo mis puntos de comparación aquí, haciéndome vulnerable a la falacia del francotirador de Texas. También estoy usando una progresión de idiomas populares para los idiomas posteriores a la microcomputadora y un lenguaje de progresión que cada tipo de inspiración inspiró al siguiente para los idiomas pre-microcomputadora. Pero a menudo he sentido que la historia se repite, y este par particular de secuencias funcionó como un lente para enfocar mis pensamientos.
Tengo la hipótesis de que muchas partes de la industria de la programación se reiniciaron esencialmente con la revolución del microordenador, y dos posibles razones que pudieron haber contribuido a que esto sucediera.
Posible razón # 1: Alan Kay ha argumentado que cuando las personas se unen a una comunidad más rápido de lo que pueden ser socializados, se desarrolla una nueva cultura pop donde las cosas que solían ser de conocimiento común entre la comunidad se vuelven relativamente poco conocidas. ¿Es posible que la revolución del microordenador haya provocado que el número de programadores crezca tan rápidamente que las comunidades de programadores más nuevas, más grandes y más ignorantes de principios de los 80 necesitaron repetir la evolución que sus antecesores de las eras del mainframe y minicomputadora tuvieron?
Posible razón # 2: Los primeros microordenadores simplemente no tenían la potencia necesaria para ejecutar los sistemas de programación más sofisticados que se habían desarrollado en mainframes y miniordenadores. Intentar ejecutar un sistema Smalltalk o Lisp en 4k, o 32k, o 64k en un procesador de 1Mhz simplemente no fue particularmente práctico. A mediados de la década de 1980, las microcomputadoras eran lo suficientemente poderosas para hacer algunas de las cosas más elegantes, pero para entonces, tal vez los nuevos programadores habían pasado suficiente tiempo en sus entornos empobrecidos que solo podían usar drogas en lenguajes de programación de alto nivel un poco en ¿un momento?
Si mis especulaciones son ciertas, entonces es deprimente que hayamos perdido tantos años, pero también es alentador que estemos progresando, porque significaría que no estamos atrapados en un ciclo interminable de abandono de tecnología. , reinventando lo mismo una y otra vez, pero en cambio estamos casi atrapados donde estábamos antes de que nuestra industria hiciera un gran reinicio, y nos estamos acercando a entrar en un territorio genuinamente nuevo.
Si tuviera que continuar las dos progresiones de idiomas que hice anteriormente, continuaría la anterior en Smalltalk *, y la más nueva en Ruby, con las nuevas características siendo algo así como "reflejo" y "enlace tardío".
Notas al pie:
- Smalltalk en realidad se inspiró en Simula I y no en Simula 67, pero el equipo de Alan Kay prestó mucha atención a Simula 67 en la década de 1970. Leí en algún lado (lo siento, no puedo encontrar el enlace ahora) que era necesario leer Simula Begin en el Grupo de Investigación de Aprendizaje en Xerox PARC.
PUBLICADO POR GLOMEK A LAS 9:15 AM
1 COMENTARIOS:
Rick DeNatale dijo ... La recolección de basura es casi tan antigua como el uso de fórmulas matemáticas en lenguajes de programación. Lisp es de la misma cosecha que Fortran y Cobol (finales de 1950).
La concepción inicial de Alan Kay de programación orientada a objetos dejó deliberadamente de lado la herencia ya que no le gustaba la forma en que Dahl y Nygaard lo habían hecho en Simula.
Ayer escribí sobre el concepto de orientación de objetos de Kay.
Comparemos smalltalk con Java para ver qué salió mal.
Sincronización. Las máquinas virtuales son costosas en términos de consumo de velocidad y memoria. Cuando apareció Smalltalk, todavía "no estábamos allí". Smalltalk era una carga pesada y era muy difícil de usar. Las computadoras no estaban tan extendidas como hoy. Java, por el otro lado, llegó al mercado "justo a tiempo" para lograr un increíble crecimiento de CPU y memoria en una PC ya ubicua.
Había libertad. Smalltalk se trataba de "tomarlo todo o dejarlo todo". Java es un lenguaje que se puede usar en diferentes entornos.
La sintaxis también juega un papel. Aunque Smalltalk es puro OO y hermoso, es más fácil para un programador aprender Java.
La Universidad Estatal de Pensilvania (Penn State) fue / es grande en Smalltalk. Sistemas estudiantiles completos, etc. fueron escritos en él. Aquí está mi razonamiento:
- Laboral: programadores difíciles de encontrar dispuestos a escribir / apoyar cosas nuevas
- Herramientas terribles GUI parece que todavía es 1996.
- Todos los programadores que conocí odiaban a Smalltalk. Sin excepciones a esta y estas fueron las personas que lo hicieron durante años.
- Las aplicaciones escritas en Smalltalk se estancaron para ser reescritas en otra cosa. Algunos estaban en modo de mantenimiento durante aproximadamente 10 años. Para entonces, cada departamento de Penn State creó un equipo de desarrolladores que hacen algo diferente a Smalltalk.
- La razón más importante es que otros productos que se supone que respaldan y promueven el desarrollo cuestan mucho dinero.
Si realmente quieres un trabajo haciendo Smalltalk, cuídate de psu.jobs. Ellos te encerrarán en el sótano. Quizás tengas algo para comer y tomar el sol, pero no puedes parar. Tendrás un trabajo para siempre ... (eco diabólico de ...)
"cuanto más aprendo, más me impresiona"
Puede obtener más información sobre las aplicaciones reales de Smalltalk a partir de los informes de experiencia de conferencias; lea los resúmenes de conferencias de Niall Ross .