¿Por qué usar Ruby en lugar de Smalltalk? [cerrado]

https://stackoverflow.com/questions/187380

06-07-2019
|

Pregunta

Ruby se está volviendo popular , en gran parte del influye en Ruby on Rails, pero parece que actualmente está luchando durante su adolescencia. Hay muchas similitudes entre Ruby y Smalltalk: maglev es un testimonio de ello. A pesar de tener una sintaxis más inusual, Smalltalk tiene todo (si no más) de la belleza orientada a objetos de Ruby.

Por lo que he leído, Smalltalk parece tener a Ruby latiendo:

Madurez (desarrollado en la década de 1970)
Estabilidad
Soporte comercial
Control de fuente distribuida (comprende la estructura del código, no solo la diferencia de texto)
Varias implementaciones de la VM
Soporte multiplataforma
El marco web costero como un alternativa fuerte a Rails

Parece que Ruby solo está reinventando la rueda. Entonces, ¿por qué los desarrolladores de Ruby no usan SmallTalk? ¿Qué tiene Ruby que Smalltalk no tiene?

Para que conste: soy un chico Ruby con poca o ninguna experiencia en Smalltalk, pero empiezo a preguntarme por qué.

Editar: creo que ha solucionado el problema de la facilidad de creación de scripts GNU Smalltalk . Según tengo entendido, esto le permite escribir smalltalk en archivos de texto antiguos normales, y ya no necesita estar en el IDE Smalltalk. Luego puede ejecute sus scripts con:

gst smalltalk_file

Solución

Soy más un Pythonista que un usuario de Ruby, sin embargo, las mismas cosas son válidas para Ruby por las mismas razones.

La arquitectura de Smalltalk es algo insular, mientras que Python y Ruby se construyeron desde cero para facilitar la integración. Smalltalk nunca obtuvo realmente un soporte de aplicaciones híbridas como Python y Ruby, por lo que el concepto de 'smalltalk como lenguaje de scripts incrustado' nunca se dio cuenta.
Además, Java no fue la cosa más fácil. para interactuar con otras bases de código (JNI es bastante torpe), pero eso no impidió que compartiera la mente. En mi opinión, el argumento de la interfaz es significativo: la facilidad de integración no ha dañado a Python, pero este argumento solo tiene un peso moderado, ya que no todas las aplicaciones requieren esta capacidad. Además, las versiones posteriores de Smalltalk abordaron sustancialmente la insularidad.
La biblioteca de clases de la mayoría de las principales implementaciones de Smalltalk (VisualWorks, VisualAge, etc.) era grande y tenía reputación de tener una curva de aprendizaje bastante empinada. La mayor parte de la funcionalidad clave en Smalltalk está oculta en algún lugar de la biblioteca de la clase, incluso cosas básicas como transmisiones y colecciones. El paradigma del lenguaje también es una especie de choque cultural para alguien que no está familiarizado con él, y la visión fragmentaria del programa presentado por el navegador es bastante diferente a lo que la mayoría de la gente estaba acostumbrada.

El efecto general es que Smalltalk obtuvo una reputación (algo merecida) por ser difícil de aprender; Se necesita bastante tiempo y esfuerzo para convertirse en un programador de Smalltalk realmente competente. Ruby y Python son mucho más fáciles de aprender y de actualizar a los nuevos programadores.
Históricamente, las implementaciones convencionales de Smalltalk eran bastante caras y necesitaban hardware exótico para ejecutarse, como se puede ver esta publicación de net.lang.st80 de 1983 . Windows 3.1, NT y '95 y OS / 2 fueron los primeros sistemas operativos del mercado masivo en hardware convencional capaces de soportar una implementación de Smalltalk con una integración decente de sistemas nativos. Anteriormente, el hardware de Mac o estación de trabajo eran las plataformas más baratas capaces de ejecutar Smalltalk de manera efectiva. Algunas implementaciones (particularmente Digitalk) soportaban bastante bien los sistemas operativos de PC y lograron ganar algo de tracción. Sin embargo, OS / 2 nunca tuvo tanto éxito y Windows no logró la aceptación general hasta mediados de los años noventa. Desafortunadamente, esto coincidió con el surgimiento de la Web como plataforma y un gran impulso de marketing detrás de Java. Java se apoderó de la mayor parte del intercambio mental en la última parte de la década de 1990, lo que convirtió a Smalltalk en un poco también.
Ruby y Python funcionan en una cadena de herramientas más convencional y no están estrechamente vinculados a un entorno de desarrollo específico. Si bien los IDEs de Smalltalk que he usado son lo suficientemente buenos, uso PythonWin para el desarrollo de Python en gran parte porque tiene un buen editor con resaltado de sintaxis y no se pone bajo los pies.

Sin embargo, Smalltalk está diseñado para usarse con un IDE (de hecho, Smalltalk era el IDE gráfico original) y todavía tiene algunas características interesantes que otros sistemas no pueden replicar. Probar código con resaltado y "Mostrarlo" sigue siendo una característica muy agradable que nunca he visto en un IDE de Python, aunque no puedo hablar por Ruby.
Smalltalk llegó un poco tarde a la fiesta de aplicaciones web. Los primeros esfuerzos como VisualWave nunca fueron terriblemente exitosos y no fue hasta que salió Seaside que un marco web decente obtuvo aceptación en los círculos de Smalltalk. Mientras tanto, Java EE ha tenido un ciclo de vida de aceptación completo, comenzando con fanáticos fanáticos que lo promocionan y finalmente se aburren y se mudan a Ruby; -}

Irónicamente, Seaside está comenzando a compartir un poco la mente entre los expertos, así que puede encontrar que Smalltalk viaja en bicicleta hacia la popularidad.

Habiendo dicho eso, Smalltalk es un sistema muy bueno una vez que has descubierto cómo manejarlo.

Otros consejos

Cuando salgo de mi casa por la mañana para ir a trabajar, a menudo me cuesta tomar la decisión de girar a la izquierda o a la derecha de mi camino (vivo en el medio de una calle). De cualquier manera me llevará a mi destino. Un camino me lleva a la autopista que, dependiendo del tráfico, probablemente me llevará a la oficina lo más rápido posible. Puedo conducir muy rápido durante al menos parte del camino y tengo una buena oportunidad de ver a una o dos chicas lindas camino al trabajo :-)

La otra manera me permite viajar por un camino encantador y ventoso con cubierta de árboles completa. Ese camino es bastante agradable y de los dos enfoques es definitivamente el más divertido, aunque significa que llegaré a la oficina más tarde de lo que hubiera hecho si hubiera tomado la autopista. Cada camino tiene sus méritos. En los días en que tengo mucha prisa, generalmente tomo la autopista, aunque puedo encontrarme con el tráfico y también aumentar mis posibilidades de tener un accidente (si no tengo cuidado en mi prisa). Otros días puedo elegir el camino arbolado y conducir, disfrutar del paisaje y darme cuenta de que llego tarde. Puedo intentar acelerar, aumentando mis posibilidades de obtener un boleto o causar un accidente yo mismo.

De ninguna manera es mejor que la otra. Cada uno tiene sus beneficios y riesgos, y cada uno me llevará a mi objetivo.

Creo que su pregunta está perdiendo el punto. Usted no debe elegir, ¡debe aprender los dos!

Si realmente está en una posición en la que puede elegir el siguiente marco (vm, infraestructura), entonces debe decidir qué usar y puede hacer una pregunta específica con pros y contras desde la perspectiva de lo que pretende su aplicación hacer.

He usado smalltalk (me encanta) y ruby ??(me encanta).

En casa o para un proyecto de código abierto, puedo usar todos los idiomas que me gustan, pero al trabajar tengo que adoptar.

Empecé a usar ruby ??(en el trabajo) porque necesitábamos un lenguaje de script que se comportara más o menos equitativamente bajo solaris, linux y windows (98,2000, xp). Ruby era en ese momento desconocido para Joe promedio y no existían rieles. Pero fue fácil de vender a todos los involucrados.

(¿Por qué no python? la verdad? Una vez pasé una semana buscando un error que ocurrió cuando un terminal convirtió mi espacio en una pestaña y la intención se equivocó).

Entonces la gente comenzó a codificar más y más en rubí porque era muy relajante, disfrutando y no una nube en el cielo.

Paul Graham lo resume

Es cierto, ciertamente, que la mayoría de las personas no eligen lenguajes de programación simplemente por sus méritos. A la mayoría de los programadores se les dice qué idioma usar otra persona.

Para ser atractivo para los hackers, un el lenguaje debe ser bueno para escribir el tipos de programas que quieren escribir. Y eso significa, quizás sorprendentemente, que tiene que ser bueno para escribir programas descartables.

Y cuándo estaban en el Lisp tierra intenta reemplazar LISP con smalltalk

Las bibliotecas, la comunidad y el impulso de Ruby son buenos


Entonces, si LISP es aún más poderoso que   Ruby, ¿por qué no usar LISP? Lo tipico   Las objeciones a la programación en LISP son:


No hay suficientes bibliotecas.

No podemos contratar programadores de LISP.

LISP no ha ido a ninguna parte en los últimos 20 años.


Estas no son objeciones abrumadoras,   pero sin duda valen la pena   considerando.

Ahora, dada la opción entre un poderoso idioma y lenguaje popular, puede tiene mucho sentido elegir el poderoso Pero si la diferencia en el poder es menor, ser popular lo tiene todo tipos de bonitas ventajas. En 2005, I & # 8217; d pensar mucho antes de elegir LISP sobre Ruby. Probablemente solo lo haría si necesitaba un código optimizado, o macros que actuaron de pleno derecho compiladores.

Diría lo contrario: la sintaxis Smalltalk es una de las sintaxis de lenguaje de programación más simples y potentes.

Es cierto que los idiomas son muy parecidos. La manera superficial de interpretar eso es llamar a Ruby una banda de covers de Smalltalk. La interpretación más razonable es que el sistema cerrado de Smalltalk lo aisló, mientras que la participación de Ruby en la ecología Unix y el hábito de apropiarse de las características de cada idioma bajo el sol le da una curva de adopción infinitamente más suave y una integración sin esfuerzo con herramientas kickass como Git.

Giles Bowkett

¿Adivina quién dijo esto? (la cita está cerca, quizás no sea exacta): "Siempre pensé que Smalltalk ganaría a Java". Simplemente no sabía si se llamaría 'Ruby' cuando lo hiciera. ''

Tambor roll ...

...

La respuesta es ... Kent Beck

Stephane Ducasse tiene algunos excelentes libros de Smalltalk disponibles aquí:

http://stephane.ducasse.free.fr/FreeBooks.html

entonces, aunque la comunidad Smalltalk no es tan prolífica como las comunidades Ruby and Rails, todavía hay una gran ayuda por ahí.

¿Qué tiene Ruby que Smalltalk no tiene?

Soporte masivo y actual de las principales plataformas (IronRuby y jRuby) que enriquecen el conjunto de bibliotecas
Evangelistas como Dave Thomas que, durante años, han estado de gira por el país predicando el evangelio de su idioma. He visto a Dave en conferencias de Java afirmando que no conoce Java y que prefiere Ruby.
Bienes inmuebles fuertes y actuales en las estanterías
El creador de Ruby ha dicho que piensa en el programador: la sintaxis de Ruby parece tener este atractivo Zen. Es difícil de precisar, pero parece galvanizar a los fanáticos.
Presentaciones creativas y dinámicas como Giles y este que gana mentalidad

Creo que tu punto está bien tomado. Como dijo un amigo, Ruby podría ser "vino viejo en una botella nueva". frente a Smalltalk. Pero a veces la nueva botella importa. Un vino tiene que estar en el lugar correcto en el momento correcto.

Me gana. Pasé un año revisando a Ruby y haciendo algunos proyectos pequeños para ver cómo me gustaba. Supongo que soy un fanático de Smalltalk porque cada vez que me sentaba a trabajar con Ruby suspiraba y pensaba "Realmente preferiría estar haciendo esto en Smalltalk". Finalmente me rendí y volví a Smalltalk. Ahora estoy mas feliz. Más feliz es bueno.

Lo cual, por supuesto, plantea la pregunta, "¿Por qué?". Sin ningún orden en particular:

Porque el IDE elimina cualquier otra cosa con la que haya trabajado. Esto incluye un montón de plataformas desde ISPF en mainframes de IBM hasta Visual (. *) De Microsoft, incluye cosas como Visual Basic 4-6, Visual C ++ (varias encarnaciones), Turbo Pascal y descendientes de Borland (por ejemplo, Delphi), y cosas en DEC máquinas en modo de caracteres y bajo X-Windows.
Porque la imagen es un hermoso lugar para vivir. Puedo encontrar lo que quiero allí. Si no puedo entender cómo hacer algo, sé que en algún lugar en la imagen es un ejemplo de lo que estoy tratando de hacer; todo lo que tengo que hacer es cazar hasta que lo encuentre. Y es autodocumentado: si desea ver los detalles de cómo funciona algo, simplemente abra un navegador en la clase que le interesa, mire el método y así es como funciona. (OK, eventualmente golpearás algo que se llama primitivo, y luego es "aquí habrá dragones", pero generalmente es comprensible desde el contexto). Es posible hacer cosas similares en Ruby / C ++ / C, pero no es tan fácil. Fácil es mejor.
El lenguaje es mínimo y consistente. Tres tipos de mensajes: unario, binario y palabra clave. Eso también describe la prioridad de ejecución: mensajes unarios primero, luego mensajes binarios, luego mensajes de palabras clave. Use paréntesis para ayudar a las cosas. Realmente, sintaxis Dang: todo se hace con el envío de mensajes. (OK, la asignación no es un envío de mensaje, es un operador. También lo es el operador de 'retorno' (^). Los bloques están encerrados por pares de llaves cuadradas ([]). Pueden ser uno o dos bits 'mágicos' más, pero maldita sea ...).
Bloques. Sí, lo sé, están allí en Ruby (y otros), pero, literalmente, no puedes programar en Smalltalk sin usarlos. Estás obligado a aprender cómo usarlos. A veces ser forzado es bueno.
Programación orientada a objetos sin compromiso - o alternativas, para el caso. No puedes fingir que estás haciendo objetos mientras sigo haciendo lo mismo de siempre.
Porque estirará tu cerebro. Las construcciones cómodas a las que todos nos hemos acostumbrado (if-then-else, do-while, for (;;), etc.) ya no están allí, por lo que debe aprender algo nuevo. Hay equivalentes a todo lo anterior (y más), pero tendrás que aprender a pensar de manera diferente. Diferentemente es bueno.

Por otro lado, esto puede ser solo las divagaciones de un tipo que ha estado programando desde los días en que los mainframes gobernaban la tierra, tuvimos que caminar cinco millas para atravesar tormentas de nieve cegadoras, cuesta arriba en ambos sentidos, y las computadoras usaron donas para la memoria . No tengo nada en contra de Ruby / Java / C / C ++ /, todos son útiles en contexto, pero dame Smalltalk o dame ... bueno, tal vez debería aprender Lisp o Scheme o ...: -)

Smalltalk: la gente reenvía ifTrue: [piensa] ifFalse: [no piensa]

Ruby: la gente piensa hacia adelante a menos que piense hacia atrás

1) El flujo de control similar a RPN de Smalltalk por mensajes es como Lisp: es regular y genial, pero deja fuera de juego a las personas.

2) Ruby permite a las personas escribir código usando la forma idiomática de las personas: hable a menos que haya una razón para no hacerlo.

actualización reescribió la muestra Smalltalk para que sea más código legal ...

Ruby es el lenguaje de moda actual. Es más fácil comercializar software creado con él ahora que un lenguaje desarrollado en los años 70.

¡Comunidad! Ruby y especialmente Rails tiene una gran comunidad. Al jugar con Smalltalk, parecía que no había tantas transmisiones de pantalla, artículos, publicaciones de blog, etc. escritas sobre Smalltalk.

Respondiste la pregunta en tu primera línea: "Ruby se está volviendo popular"

Hay un lote de módulos, proyectos y demás interesantes basados ??en Ruby.
Si tiene problemas para hacer algo en Ruby, será trivial encontrar ayuda en algún lugar.
Ruby está instalado en un lote de computadoras ahora (está incluido por defecto en OS X, muchas distribuciones de Linux y hay buenos instaladores para Windows) - No he visto smalltalk instalado por defecto en cualquier máquina que haya usado ...

Yo diría que si un idioma es superior o no a otro es irrelevante. Como ejemplo, PHP puede no ser el "mejor". lenguaje alguna vez, pero aún consideraría usarlo sobre Ruby on Rails (una herramienta "mejor" para crear sitios web) porque está muy extendido.

Básicamente, los pros y los contras específicos de un idioma son mucho menos importantes que todo lo que lo rodea, es decir, la comunidad.

Ruby (o cualquier otro idioma) es más popular que Smalltalk (o cualquier otro idioma) porque vivimos en un universo caótico. A saber:

Del propio Dave Thomas, " [después el] video sobre 'Cómo construir un blog en Diez minutos ... Ruby pasó de ser un pequeño y agradable lenguaje de nicho, para siendo 'un idioma que escribiste Rails aplicaciones en '" ( Ruby Conference 2010 keynote ).
Los primeros vendedores de Smalltalk cobran prohibitivamente
Smalltalk, debido a que fue inventado (antes de su tiempo) hace 30 años, se le ocurre a muchos como viejos, "muertos". idioma (como FORTRAN)
las corporaciones consideran a Smalltalk una ventaja tan competitiva que ocultan su uso

Si bien los idiomas son similares en las características de OO, la ventaja killer de Smalltalk es el entorno abierto y en vivo (la 'imagen' muy incomprendida). Después de revisar este ejemplo de programación en Smalltalk , el debate ha terminado.

Para mí no se trata tanto de lo que Ruby tiene, sino de lo que Ruby no tiene. Y lo que no tiene es la necesidad de una VM y un entorno completo.

Smalltalk es genial, es donde aprendí conceptos de OO, pero para facilitar su uso, voy por Ruby. Puedo escribir código Ruby en mi editor favorito y ejecutarlo desde la línea de comando.

Entonces, para mí, eso es lo que elijo Ruby sobre Smalltalk.

Creo que todos los que han estado trabajando con Ruby por un tiempo reconocen su profunda deuda con Smalltalk. Como una de estas personas, ¿qué me gusta de Ruby sobre Smalltalk? Creo que desde una perspectiva estrictamente lingüística, es el azúcar. Ruby es deliberadamente un lenguaje muy sintaxis-azucarado, mientras que Smalltalk es un lenguaje muy sintaxis-mínimo. Ruby es esencialmente el modelo de objeto Smalltalk con azúcar de sintaxis Perlish. Me gusta el azúcar y encuentro que hace que la programación sea más divertida.

Puedes encontrar un trabajo fácilmente haciendo Ruby. Aunque realmente amo Smalltalk, es prácticamente imposible entrar en el nicho de Smalltalk. Hay una solución, pero si no entraste cuando era popular, es prácticamente imposible ahora.

Todas las otras razones se vuelven insignificantes porque necesitas pasar mucho tiempo, enfocado en el trabajo real para aprender un idioma correctamente. Si no eres rico de forma independiente, la mejor manera de hacerlo es exponiéndote a él en el trabajo.

Porque las distribuciones de Smalltalk tenían un precio en múltiplos de $ 1000USD, mientras que Ruby es gratis.

Ruby es para Smalltalk como los números arábigos son para los romanos. Misma matemática, sintaxis más fácil.

He hecho un poco de Smalltalk - el IDE es una cosa que recuerdo - ¿Ruby tiene un buen soporte IDE?

Usa Ruby porque puede tener piernas comerciales, Smalltalk no.

Puedo decirte por experiencia personal. Todavía uso Smalltalk, me encanta y he usado un par de sabores. Aunque Smalltalk es un gran lenguaje, y es todo lo que mencionó, es probable que no convenza al CIO / CTO promedio de usar Smalltalk en un nuevo proyecto. Por supuesto, incluso podría tener dificultades para convencer a un CIO / CTO conservador de usar Ruby. Al final, debe tener mucho cuidado si desea soporte comercial sostenido a largo plazo y la capacidad de encontrar empleados fuera de la calle que puedan soportar sus sistemas en el futuro. A modo de ejemplo, Smalltalk fue algo realmente importante a principios de los 90 e IBM invirtió mucho en ello a fines de los 90. Para IBM Smalltalk iba a ser el próximo idioma para todas las aplicaciones comerciales. IBM puso Smalltalk en todo, incluidos sus sistemas mainframe. Java se hizo popular, se hizo cargo del mercado y Smalltalk se convirtió en un jugador de nicho. Hace más de un año, IBM abandonó el idioma (su término es la extinción). Además, eche un vistazo a la historia. ParkPlace y Digitalk, donde se fusionaron los primeros jugadores comerciales importantes en la arena de Smalltalk, y luego cerraron.

Me encantan Smalltalk y Ruby, pero he descubierto que Ruby es más aplicable a lo que hago a diario y está más cerca de mi corazón (prácticamente hablando). ¿Qué ofrece Ruby que Smalltalk no ofrece?

Scripting basado en texto
Bajos requisitos de implementación (se ejecuta en más lugares)
Más fácil de aprender y justificar (los programadores de Perl y Python tendrán no problemas
¡Es más fácil mover programas: archivos de texto!
Se interconecta bien con el entorno nativo
En cualquier lugar donde se ejecute Java, jRuby se ejecuta ...
Comunidad más grande y mucho más activa

Algunos han mencionado gst (GNU Smalltalk); los problemas aún se mantienen.

Usa lo que sea que te haga más poderoso y más rápido para superar tu desafío.

Para us , un pequeño marco interno, construimos en la parte superior de la costa es realmente nuestra superpotencia.

Amo a la comunidad RoR, tiene la actitud correcta. Eso es muy muy valioso. Pero al mismo tiempo, tecnológicamente, el mar te hace más fuerte frente a problemas más complicados.

Puedes hacer excelentes aplicaciones web junto al mar usando cosas de código abierto.

dabbledb era un sartup basado en la costa y, ¡oye! ¡Avi lo vendió a Twitter en junio de este año!

Digo que no necesita esperar a que otros aprueben su iniciativa.

Solo hazlo. Hazlo hecho. Muéstranos que funciona.

No estás solo. Estamos en el mismo barco.

Perspectiva interesante de Robert Martin (de RailsConf 2009): " Lo que mató Smalltalk podría matar a Ruby, Demasiado "

Creo que parte del problema es el entorno de desarrollo es el tiempo de ejecución. Esto le da mucho poder, pero también presenta una curva de aprendizaje más grande.

Aquí es un tutorial de hello world.

Esto es muy diferente de otros idiomas en los que solo necesito saber cómo abrir un editor de texto y copiar y pegar texto, presionar guardar y ejecutar un compilador. Tengo que saber cómo usar el medio ambiente. Ese tutorial ni siquiera me muestra cómo crear un programa básico (que probablemente sea más un error de ese tutorial) que puedo ejecutar.

Definitivamente hay un costo más alto de simplemente hacer que las cosas funcionen que la mayoría de los otros idiomas.

La mayoría de los idiomas tienen un bonito código llamativo que pueden mostrar. No he visto eso con Smalltalk. También creo que Smalltalk tiene cierto estigma porque ha existido durante tanto tiempo y todavía es relativamente oscuro.

Creo que la diferencia MÁS GRANDE es que Ruby es mucho más similar a Perl en términos de USO. Smalltalk nunca tuvo un punto de apoyo en el '' scripting '' idiomas.

La VM es realmente genial y espero que Ruby tenga algo similar para que podamos tratar todo lo que está escrito en Ruby como objeto en el espacio de memoria, sin embargo, hasta ese momento, simplemente disfruto de la sintaxis breve y breve de Ruby. capacidad de escribir un pequeño script y reutilizarlo más tarde. Ruby obtuvo todas las ventajas de perl y el OOP es mucho más similar a smalltalk que el hack de OOP de perl.

Iría más allá de la respuesta de Jonke, y diría que ahora hay una gran cantidad de idiomas que tienen una comunidad muy fuerte, casi lo suficiente para todos los gustos, y un subconjunto de estos tiene un reconocimiento general (es decir, su gerente le permitirá úselos también en el trabajo).

Es fácil aprender los conceptos básicos de un idioma, pero para usarlo efectivamente necesita invertir suficiente tiempo para aprender la plataforma y las herramientas, así como la sintaxis y las expresiones idiomáticas. IIRC, McConnell afirma que lleva unos tres años llegar a ser realmente competente.

Teniendo en cuenta estas cosas, es difícil justificar pasar mucho tiempo en idiomas como LISP y Smalltalk, aunque son interesantes y quizás educativos para mirar.

Como recién llegado a la discusión, el principal problema con Smalltalk y Lisp es que no puede ejecutarlos con CGI o FastCGI en el alojamiento compartido.

Las masas sin lavar nunca los usarán si necesitan VPS o servidores dedicados para usarlos. En mi humilde opinión, Seaside es superior a casi cualquier cosa, pero ¿se ejecutará en Dreamhost o Webfaction?

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow