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

Ruby se está volviendo popular , en gran parte por la influencia de 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 toda la belleza orientada a objetos de Ruby (si no más).

Por lo que he leído, Smalltalk parece haber superado a Ruby:

• 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 una fuerte alternativa 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?

Para el registro: soy un chico Ruby con poca o ninguna experiencia en Smalltalk, pero estoy empezando a preguntarme por qué.

Editar: Creo que GNU Smalltalk ha abordado el problema de la facilidad de scripting . 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 ejecutar sus scripts con:

gst smalltalk_file

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 de la misma manera que Python y Ruby, por lo que el concepto de 'smalltalk como lenguaje de scripting incrustado' nunca tuvo éxito.
  
  Por otro lado, Java no era lo más fácil de interactuar con otras bases de código (JNI es bastante torpe), pero eso no impidió que ganara mentalidad. En mi opinión, el argumento de la interfaz es significativo (la facilidad de integración no ha perjudicado 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 pronunciada. La mayoría de las funciones clave en Smalltalk están ocultas 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 en esta publicación de net.lang.st80 de 1983 . Windows 3.1, NT y '95 y OS / 2 fueron los primeros sistemas operativos de 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) soportaron 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 la década de 1990. 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 de la mentalidad compartida en la última parte de la década de 1990, lo que convirtió a Smalltalk en una especie de candidato.

• 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 IDE 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 por debajo.
  
  Sin embargo, Smalltalk fue diseñado para usarse con un IDE (de hecho, Smalltalk era el IDE gráfico original) y todavía tiene algunas características agradables que otros sistemas no pueden replicar. Probar el 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 entusiasmados que lo promocionan y finalmente se aburren y se mudan a Ruby; -}
  
  Irónicamente, Seaside está comenzando a compartir un poco de mente entre los expertos, por lo que podemos encontrar que Smalltalk monta eso volver a la popularidad.

Dicho esto, Smalltalk es un sistema muy bueno una vez que has descubierto cómo manejarlo.

Cuando salgo de mi casa por la mañana para ir a trabajar, a menudo me cuesta 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, ventoso y con una cobertura completa de árboles. 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 meta.

Creo que su pregunta está perdiendo el punto. ¡No debes elegir, debes aprenderlos a ambos!

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 hacer su aplicación.

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

En casa o para proyectos de código abierto, puedo usar todos los idiomas que me gustan, pero al hacer el trabajo tengo que adoptar.

Comencé 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.

y

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

Y cuando estuviéramos en la tierra de Lisp, 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? Las objeciones típicas a la programación en LISP son:

1. No hay suficientes bibliotecas.
2. No podemos contratar programadores de LISP.
3. LISP no ha ido a ninguna parte en los últimos 20 años.

Estas no son objeciones abrumadoras, pero ciertamente vale la pena considerarlas.

y

Ahora, dada la posibilidad de elegir entre un lenguaje poderoso y un lenguaje popular, puede tener mucho sentido elegir el poderoso. Pero si la diferencia en el poder es menor, ser popular tiene todo tipo de ventajas. En 2005, pensaría mucho antes de elegir LISP sobre Ruby. Probablemente solo lo haría si necesitaba un código optimizado o macros que actuaran como compiladores completos.

Yo 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 de 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 es cercana, tal vez no exacta): "Siempre pensé que Smalltalk ganaría a Java. Simplemente no sabía si se llamaría 'Ruby' cuando lo hizo".

Rollo de tambor ...

...

La respuesta es ... Kent Beck

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

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

así que, aunque la comunidad Smalltalk no es tan prolífica como las comunidades Ruby y 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 las conferencias de Java afirmando que no conoce Java y que prefiere a 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 esta que ganan en mente

Creo que tu punto está bien entendido. Como dijo una vez 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 visitando Ruby y haciendo algunos proyectos pequeños para ver cómo me gustaba. Creo 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é?". En ningún orden particular:

1. 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.
2. 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 de 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.
3. 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. En realidad, una pequeña sintaxis: 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 ...)
4. 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.
5. Programación orientada a objetos sin compromiso, o alternativas, para el caso. No puedes fingir que estás "haciendo objetos" mientras sigues haciendo lo mismo de siempre.
6. 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: las personas reenvían 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 que las personas escriban código usando la forma idiomática de las personas: hable, a menos que haya una razón para no hacerlo.

La 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., escritos sobre Smalltalk.

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

• Hay muchos módulos interesantes, proyectos y demás basados ​​en Ruby.
• Si tiene problemas para hacer algo en Ruby, será trivial encontrar ayuda en alguna parte.
• Ruby está instalado en muchas computadoras ahora (está incluido de forma predeterminada en OS X, muchas distribuciones de Linux y hay buenos instaladores para Windows). No he visto Smalltalk instalado de manera predeterminada en ninguna máquina que haya usado.

Yo diría que si un lenguaje es superior o no a otro es irrelevante. Como ejemplo, PHP puede no ser el "mejor" lenguaje, 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. Esto es:

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

Si bien los idiomas son similares en las características de OO, la ventaja asesina de Smalltalk es el entorno abierto y en vivo (la 'imagen' muy incomprendida). Después de ver 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 por facilidad de 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, ahora es prácticamente imposible.

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.

Te puedo decir 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 grandes jugadores comerciales en la arena de Smalltalk, se fueron a la quiebra.

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 (Perl y Python programadores tendrán ningún problema
• Es más fácil mover programas: ¡archivos de texto!
• Se conecta bien con el entorno nativo
• En cualquier lugar donde se ejecute Java, se ejecuta jRuby ...
• Comunidad más grande y mucho más activa

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

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

Para nosotros , un poco en el marco de la casa, 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 con 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!

Le digo que no necesita esperar a que otros aprueben su iniciativa.

Solo házlo. Hazlo hecho. Muéstranos que funciona.

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

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

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í hay 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 código atractivo 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 MAYOR diferencia es que Ruby es mucho más similar a Perl en términos de USO. Smalltalk nunca se afianzó en los lenguajes de "scripting".

La VM es realmente genial y espero que Ruby tenga algo similar para que podamos tratar todo en nuestro sistema operativo que esté escrito en Ruby como objeto en el espacio de memoria, sin embargo, hasta entonces, simplemente disfruto de la breve y sintaxis breve de Ruby, la capacidad de simplemente escribe un pequeño guión y reutilízalo 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.

Me gustaría ir más allá de la respuesta de Jonke, y decir 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á usarlos en funciona bien).

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.

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 un 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 ¿funcionará en Dreamhost o Webfaction?