Por que usar Ruby em vez de Smalltalk? [fechadas]

https://stackoverflow.com/questions/187380

06-07-2019
|

Pergunta

Ruby está se tornando popular, em grande parte do influenciar ruby ??on Rails, mas parece que ele está lutando por meio de sua adolescência. Há uma série de semelhanças entre Ruby e Smalltalk - maglev é uma prova disso. Apesar de ter uma sintaxe mais incomum, Smalltalk tem tudo (se não mais) da beleza orientada a objetos de Ruby.

Pelo que tenho lido, Smalltalk parece ter Rubi batida em:

Maturidade (desenvolvido na década de 1970)
Estabilidade
Suporte comercial
href="http://www.wiresong.ca/monticello/" rel="noreferrer"> controle de origem (Distributed entende estrutura do código, não apenas texto diffing)

da VM
suporte multi-plataforma
à beira-mar framework web como alternativa forte para Rails

Parece que Ruby está apenas reinventar a roda. Então, por que não desenvolvedores Ruby usar SmallTalk? O que Rubi tem o Smalltalk não?

Para o registro:. Eu sou um cara de Ruby com pouca ou nenhuma experiência em Smalltalk, mas estou começando a me perguntar por

Editar: Acho que a questão facilidade de scripting tem sido abordada por GNU Smalltalk . Pelo que entendi, o que lhe permite escrever smalltalk em arquivos de texto normal, e você não precisa mais estar no Smalltalk IDE. Você, então, pode executar seus scripts com:

gst smalltalk_file

Solução

Eu sou mais um Pythonista do que um usuário Ruby, no entanto as mesmas coisas segure por Ruby para muitas das mesmas razões.

A arquitetura do Smalltalk é um pouco insular enquanto Python e Ruby foram construídos a partir do zero para facilitar a integração. Smalltalk nunca ganhou um corpo de suporte de aplicação híbrida da maneira que Python e Ruby têm, por isso, o conceito de 'Smalltalk como linguagem de script embutido' nunca pegou.
Como um aparte, Java não era a coisa mais fácil para a interface com outras bases de código (JNI é bastante desajeitada), mas isso não impedi-lo de ganhar mindshare. IMO o argumento interface é significativo - facilidade de incorporação não prejudicou Python - mas este argumento só tem peso moderado como nem todas as aplicações requerem esta capacidade. Além disso, versões posteriores do Smalltalk abordou substancialmente a insularidade.
A biblioteca de classes da maioria dos principais implementações Smalltalk (VisualWorks, VisualAge etc.) era grande e tinha reputação de uma curva de aprendizado bastante íngreme. A maioria das funcionalidades chave no Smalltalk está escondido em algum lugar na biblioteca de classes, mesmo coisas básicas como córregos e coleções. O paradigma idioma também é algo de um choque cultural para alguém não familiarizado com ele, ea vista fragmentada do programa apresentado pelo navegador é muito diferente do que a maioria das pessoas estavam acostumados.
O efeito geral é que Smalltalk tem uma reputação (um pouco merecida) de ser difícil de aprender; é preciso um pouco de tempo e esforço para se tornar um programador Smalltalk realmente proficientes. Ruby e Python são muito mais fáceis de aprender e trazer novos programadores até a velocidade com.
Historicamente, principais Smalltalk implementações foram bastante caro e precisava de hardware exótico para corrida, como pode ser visto desta postagem net.lang.st80 de 1983 . Windows 3.1, NT e 95 e OS / 2 foram os primeiros sistemas operacionais do mercado de massas em hardware comum capazes de suportar uma implementação Smalltalk com a integração do sistema nativo decente. Anteriormente, Mac ou hardware estação de trabalho foram as plataformas mais baratos capazes de executar Smalltalk eficaz. Algumas implementações (particularmente Digitalk) sistemas operacionais suportados PC muito bem e conseguiu ganhar alguma tração.
No entanto, OS / 2 nunca foi tão bem sucedida e Windows não conseguir aceitação geral até meados de 1990. Infelizmente, isso coincidiu com a ascensão da Web como uma plataforma e uma grande campanha de marketing por trás Java. Java agarrou a maior parte do mindshare na última parte da década de 1990, tornando Smalltalk um pouco de um also-ran.
Ruby e Python trabalho em um conjunto de ferramentas mais convencional e não estão fortemente acoplados a um ambiente de desenvolvimento específico. Enquanto o Smalltalk IDEs que tenho usado são bons o suficiente Eu uso PythonWin para o desenvolvimento Python em grande parte porque ele tem um editor agradável com destaque de sintaxe e não ficar sob os pés.
No entanto, Smalltalk é foi projetado para ser usado com um IDE (na verdade, Smalltalk foi o IDE gráfica original) e ainda tem algumas características interessantes não replicados por outros sistemas. Testando código com destaque e 'Mostre-o' ainda é um recurso muito bom que eu nunca vi em um Python IDE, embora eu não posso falar por Ruby.
Smalltalk foi um pouco tarde vindo para a festa de aplicações web. Os primeiros esforços como VisualWave nunca foi terrivelmente bem sucedido e não foi até Mar saiu que um framework web decente tem aceitação nos círculos Smalltalk. Nesse meio tempo Java EE teve um ciclo de vida completa aceitação começando com delirante fanboys promovê-lo e, finalmente, ficando entediado e passar para o Ruby; -}
Ironicamente, Mar está começando a ficar um pouco de mindshare entre os conhecedores de modo que pode achar que Smalltalk passeios que volta ciclo em popularidade.

Dito isto, Smalltalk é um sistema muito bom, uma vez que você trabalhou para fora como para dirigi-lo.

Outras dicas

Quando saio de casa de manhã para ir ao trabalho, eu muitas vezes lutam com a decisão de fazer uma esquerda ou direita virar para fora do meu caminho da unidade (eu vivo no meio de uma rua). De qualquer forma vai ter me ao meu destino. Uma maneira me leva à auto-estrada que, dependendo do tráfego, provavelmente vai ficar comigo para o escritório o mais rápido. Eu começar a dirigir muito rápido, pelo menos, uma parte do caminho e eu tenho uma boa chance de ver uma menina bonita ou dois em seu caminho para o trabalho: -)

A outra maneira me permite viajar para baixo, uma estrada de volta ventoso muito encantadora com tampa de árvore completa. Esse caminho é bastante agradável e das duas abordagens é definitivamente o mais divertido, embora isso significa que eu vou chegar ao escritório mais tarde do que eu teria se eu tivesse tomado a estrada. Cada caminho tem seus méritos. Nos dias que estou com muita pressa, I geralmente pegue a rodovia que eu possa correr para o tráfego e eu também aumentar minhas chances de entrar em um acidente (se eu não tenho muito cuidado na minha pressa). Outros dias eu possa escolher o caminho arborizado e estar dirigindo, apreciando a paisagem e perceber que eu estou atrasado. I podem tentar acelerar, aumentando minhas chances de conseguir um bilhete ou causar um acidente mim mesmo.

Nem caminho é melhor que o outro. Cada um deles tem seus benefícios e riscos, e cada um vai me fazer o meu objetivo.

Eu acho que sua pergunta é um pouco perdendo o ponto. Você não deve escolher, você deve aprender os dois!

Se você realmente estão em uma posição que você pode escolher o próximo quadro (vm, infra-estrutura), então você precisa decidir o que usar e pode fazer uma pergunta específica com prós e contras a partir da perspectiva do que a sua aplicação é inteded para fazer.

Eu tenho smalltalk utilizado (amor-lo) e rubi (amor-lo).

Em casa ou para o projeto de código aberto que eu posso usar todas as línguas que eu gosto, mas ao fazer o trabalho que eu tenho que adotar.

Eu comecei a usar ruby ??(no trabalho) porque precisávamos de alguma linguagem de script que se comportou mais ou menos igualmente sob Solaris, Linux e Windows (98,2000, XP). Ruby estava naquele desconhecido hora de média-joe e não existia nenhum rails. Mas era fácil de vender para todos os envolvidos.

(Por que não python? A verdade? Uma vez eu passar um caça semana para um bug que aconteceu quando um terminal convertido meu espaço a uma guia ea intencionalidade ficou confuso).

Então, as pessoas começaram a código mais e mais em Ruby porque foi tão relaxante, desfrutando e não uma nuvem no céu.

Paul Graham resume tudo

É verdade, certamente, que a maioria das pessoas não escolhem idiomas simplesmente com base em seus méritos programação. A maioria dos programadores é dito qual idioma usar por outra pessoa.

Para ser atraente para os hackers, a linguagem deve ser bom para escrever o tipos de programas que querem escrever. E isso significa que, talvez surpreendentemente, que tem que ser bom para a escrita programas descartáveis.

E quando estavam no Lisp tentativa terra para substituir LISP com Smalltalk

Ruby bibliotecas, comunidade e impulso são boas

Então, se LISP ainda é mais poderoso do que Ruby, por que não usar LISP? O típico objeções a programação em LISP são:

Não existem bibliotecas suficientes.

Não podemos contratar programadores LISP.

LISP não deu em nada nos últimos 20 anos.

Estes não são esmagadora objeções, mas eles são certamente vale a pena considerando.

Agora, dada a escolha entre um poderoso linguagem, ea linguagem popular, ele pode fazer excelente senso para escolher o um poderoso. Mas se a diferença de poder é menor, sendo popular tem tudo tipos de vantagens agradáveis. Em 2005, eu pensar muito antes de escolher LISP sobre Ruby. Eu provavelmente só fazer se eu precisava de código otimizado, ou macros que agiu como de pleno direito compiladores.

Eu diria o contrário:. Sintaxe Smalltalk é uma das sintaxes mais simples e poderosa linguagem de programação

É verdade que os idiomas são muito parecidos. A maneira rasa para interpretar que é chamar o Ruby uma banda cover do Smalltalk. A interpretação mais razoável é que o sistema fechado de Smalltalk isolado que, enquanto a participação de Ruby na ecologia Unix e hábito de apropriar-se características de cada língua sob o sol dá-lhe uma curva de adoção infinitamente mais suave e fácil integração com ferramentas kickass como Git.

Giles Bowkett

Adivinha quem disse isso? (Citação está perto, talvez não exato): ". Eu sempre pensei Smalltalk iria bater Java Eu só não sabia se seria chamado de 'Ruby' quando ele fez isso"

Rolo de cilindro ....

...

A resposta é ... Kent Beck

Stephane Ducasse tem alguns grandes livros Smalltalk disponíveis aqui:

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

Assim, embora a comunidade Smalltalk não é tão prolífico como as comunidades Ruby e Rails, há ainda algum grande ajuda lá fora.

O que o Ruby ter que Smalltalk não?

maciço, suporte atual por grandes plataformas (IronRuby e JRuby) que enriquecem o conjunto de bibliotecas
Evangelistas como Dave Thomas, que, durante anos, foram turnê por todo o país pregando o evangelho de sua língua. Eu vi Dave em conferências Java afirmando que ele não sabe Java e que ele prefere Ruby.
Strong, imobiliário atual nas estantes
O criador do Ruby disse que ele pensa sobre o programador: sintaxe de Ruby parece ter este apelo Zen. É difícil de definir, ainda parece galvanizar os fãs.
Creative, apresentações dinâmicas como Giles e esta que o ganho de mindshare

Eu acho que seu ponto é bem-feita. Como um amigo colocá-lo uma vez, Ruby pode ser "vinho velho em uma garrafa nova" vis-a-vis Smalltalk. Mas às vezes a nova garrafa importa. Um vinho tem que estar no lugar certo no momento certo.

me bate. Passei um ano verificando Ruby e fazendo alguns projetos bem pequenos para ver como eu gostei. Eu acho que eu sou um Smalltalk intolerante, porque cada vez que eu sentava ao trabalho com Ruby Eu suspirar e pensar "Eu realmente prefiro estar fazendo isso em Smalltalk". Finalmente eu desisti e voltei para o Smalltalk. Agora eu sou mais feliz. Mais feliz é gooder.

Que, naturalmente, suscita a pergunta: "Por quê?". Em nenhuma ordem particular:

Como o IDE afugenta qualquer outra coisa que eu já trabalhei. Esta inclui um conjunto de plataformas de ISPF em mainframes IBM para Microsoft do Visual (. *), Incluem coisas como o Visual Basic 4-6, Visual C ++ (várias encarnações), da Borland Turbo Pascal e descendentes (por exemplo, Delphi), e outras coisas no DEC máquinas, tanto em modo de caracteres e sob X-Windows.
Uma vez que a imagem é um belo lugar para se viver. Posso encontrar o que eu quero lá. Se eu não consigo descobrir como fazer algo que eu sei que em algum lugar na imagem é um exemplo do que eu estou tentando fazer - tudo o que tenho a fazer é caçar até que eu encontrá-lo. E é auto-documentado - se você quiser ver os detalhes de como algo funciona basta abrir um navegador na classe você está em interessado, olhar para o método, e isso é como ele funciona. (OK, eventualmente, você vai bater em alguma coisa que chama uma primitiva, e então é "aqui há dragões", mas normalmente é compreensível a partir do contexto). É possível fazer coisas semelhantes em Ruby / C ++ / C, mas não é tão fácil. Fácil é melhor.
A linguagem é mínima e consistente. Três tipos de mensagens - unária, binária, e palavra-chave. Que descreve a prioridade de execução, também - mensagens unárias primeiro, depois mensagens binárias, as mensagens-chave. Use parênteses para ajudar as coisas. sintaxe pouco Dang, realmente - tudo é feito com envio de mensagens. (OK, atribuição não é um envio de mensagem, é um operador. Assim é o operador 'retorno' (^). Os blocos são delimitados por pares cinta quadrados ([]). Pode ser um ou dois outros 'mágicos' bits de lá, mas danado pouco ...).
Blocks. Sim, eu sei, eles estão lá em Ruby (e outros), mas Dang ele, você literalmente não pode programa em Smalltalk sem usá-los. Você é forçada para aprender como usá-los. Às vezes sendo forçado é bom.
Programação orientada a objetos, sem compromisso - ou alternativas, para essa matéria. Você não pode fingir que você está "fazendo objetos" enquanto ainda está fazendo a mesma coisa velha.
Porque ele vai esticar seu cérebro. As construções confortáveis ??todos nós já se acostumou a (if-then-else, não-tempo, para (;;), etc) não estão mais lá, então você tem que aprender algo novo. Há equivalentes para todos os acima (e mais), mas você vai ter que aprender a pensar de forma diferente. Diferente é bom.

Por outro lado, isso pode ser apenas as divagações de um cara que tem sido programação desde os dias em mainframes dominavam a Terra, tivemos que andar cinco milhas para trabalhar através de tempestades de neve cegueira, subida ambas as maneiras, e os computadores donuts para memória usada . Eu não tenho nada contra Ruby / Java / C / C ++ /, todos eles são úteis no contexto, mas me dê Smalltalk ou dar-me ... bem, talvez eu deveria aprender Lisp ou Scheme ou ...: -)

Smalltalk: pessoas para a frente ifTrue: [pensar] ifFalse: [sem pensar]

Ruby: as pessoas pensam para a frente, a menos trás pensamento

1) RPN-like fluxo de controle do Smalltalk por mensagens é como Lisp -. É regular e legal, mas Weirds pessoas fora

2) Rubi permite que as pessoas escrever código usando a maneira idiomática pessoas falam -. Fazê-blá menos não há uma razão para não

update reescreveu a amostra Smalltalk para ser realmente um código mais legal ..

Ruby é a linguagem zumbido atual. É mais fácil de software mercado construído com isso agora do que uma linguagem desenvolvida na década de 70.

Comunidade! Ruby e Rails especialmente tem uma comunidade tão grande. Quando andar com Smalltalk parecia que não havia como muitos moldes de tela, artigos, posts, etc. escritos sobre Smalltalk.

Você respondeu a pergunta em sua primeira linha: "Ruby está se tornando popular"

Há um muito de módulos interessantes, projetos e tais baseados em torno de Ruby.
Se você tiver problemas para fazer algo em Ruby, será trivial para encontrar ajuda em algum lugar.
Ruby está instalado em um muito de computadores agora (é incluído por padrão no Mac OS X, muitas distros Linux, e há boas instaladores para Windows) - Eu não vi smalltalk instalado por padrão em qualquer máquina que usei ..

Eu diria wether ou não uma língua é superior a outra é irrelevante .. Como exemplo, PHP pode não ser o "melhor" linguagem nunca, mas eu ainda iria considerar usá-lo durante Ruby on Rails (a "melhor" ferramenta para criação de sites), porque ele é tão difundido.

Basicamente, prós e contras de um idioma específico são muito menos importantes do que tudo o que o rodeia - nomeadamente a comunidade

Ruby (ou qualquer outra língua) é mais popular do Smalltalk (ou qualquer outra língua) porque vivemos em um universo caótico. A saber:

Do próprio Dave Thomas, "[depois o] video on 'Como construir um Blog no Dez Minutos ... Rubi deixou de ser um pouco agradável linguagem de nicho, para ser 'uma língua que você escreveu Rails Apps em"( Rubi Conference 2010 keynote ).
No início Smalltalk vendedores cobrado proibitivamente
Smalltalk, porque foi inventada (à frente de seu tempo), há 30 anos, ocorre por muitos como uma língua antiga, "morto" (como FORTRAN)
corporações consideram Smalltalk uma vantagem tão competitivo que eles escondem seu uso

Enquanto as línguas são semelhantes em características OO, Smalltalk do assassino vantagem é o ambiente ao vivo, aberta (a 'imagem' muito mal compreendido). Depois de verificar este exemplo de programação em Smalltalk , o debate é longo.

Para mim não é tanto um caso do que Ruby tem, mas o que Ruby tem não. E a única coisa que ele não tem é a necessidade de um ambiente de VM e completa.

Smalltalk é grande - sua onde eu aprendi conceitos OO, mas para facilidade de uso I ir para Ruby. Eu posso escrever código Ruby no meu editor favorito e executá-lo a partir da linha de comando.

Então, para mim, isso é o que eu escolher o Ruby sobre Smalltalk.

Eu acho que todo mundo que tem vindo a trabalhar com Ruby por um tempo reconhece a sua profunda dívida para Smalltalk. Como uma dessas pessoas, o que eu gosto sobre Ruby sobre Smalltalk? Eu acho que a partir de uma perspectiva estritamente a linguagem, é o açúcar. Ruby é deliberadamente uma linguagem muito sintaxe-açúcar, enquanto que Smalltalk é uma linguagem muito sintaxe-mínimo. Ruby é essencialmente o modelo objecto Smalltalk com açúcar sintaxe Perlish. Acontece que eu gosto de açúcar e encontrá-lo torna a programação mais divertido.

Você pode encontrar um trabalho muito facilmente fazendo Ruby. Embora eu realmente amo Smalltalk, é praticamente impossível para entrar no nicho de Smalltalk. Há trabalho em torno dele, mas se você não entrar em quando ele era popular é praticamente impossível agora.

Todas as outras razões pálida insignificância, porque você precisa gastar muito tempo, focado no trabalho real para aprender uma língua corretamente. Se você não é rico e independente, a melhor maneira de fazer isso é a exposição a ele no trabalho.

Porque distribuições Smalltalk foram precificados em múltiplos de $ 1000USD enquanto Ruby é livre.

Ruby é a Smalltalk como algarismos arábicos são numerais romanos. Mesma matemática, sintaxe mais fácil.

Eu fiz um pouco de Smalltalk - o IDE é uma coisa que me lembro -? O Ruby tem um bom suporte IDE

Use o Ruby porque tem pode ter pernas de negócios, Smalltalk não.

Eu posso dizer por experiência pessoal. Ainda usando Smalltalk, amá-lo, e ter usado um par de sabores. Embora Smalltalk é uma grande linguagem, e é tudo o que você mencionou, você não vai provavelmente convencer a média CIO / CTO usar Smalltalk em um novo projeto. Claro, você pode até ter um tempo difícil convencer um conservador CIO / CTO usar Ruby. No final, você tem que ter muito cuidado se você quiser suporte comercial a longo prazo e sustentado a capacidade de encontrar off-the-street funcionários que podem apoiar os seus sistemas no futuro. Como exemplo, Smalltalk foi realmente uma grande coisa no início dos anos 90 e IBM investiu pesado para ele no final dos anos 90. Para a IBM Smalltalk ia ser o próximo idioma para todas as aplicações de negócios. IBM colocou Smalltalk sobre tudo, incluindo seus sistemas de mainframe. Java tornou-se popular, assumiu o mercado, e Smalltalk tornou-se um jogador de nicho. Mais de um ano atrás IBM despejou a linguagem (o termo é por do sol). Além disso, ter um olhar para a história. Parkplace e Digitalk onde os primeiros grandes jogadores comerciais na arena Smalltalk, eles fundiram e, em seguida, saiu do negócio.

Eu te amo tanto Smalltalk e Ruby - mas descobriram que Ruby é mais aplicável para o que eu faço diariamente, e está mais perto de meu coração (em termos práticos). O que faz o Ruby oferta que Smalltalk não?

scripting baseada em texto
requisitos baixa execução (é executado em mais lugares)
Mais fácil de aprender e justificar (programadores Perl e Python terão não problemas
Mais fácil para mover programas em torno de - arquivos de texto
Interfaces bem com ambiente nativo
Qualquer Lugar Java é executado, jRuby corre ...
comunidade maior e muito mais ativo

Alguns mencionaram GST (GNU Smalltalk); os problemas ainda se mantêm.

Use o que o torna mais poderoso e mais rápido para vencer seu desafio.

Para nos , um pouco no quadro casa, nós construímos no topo da beira-mar é realmente a nossa superpotência.

Eu amo a comunidade RoR, tem a atitude certa. Isso é muito, muito valioso. Mas, ao mesmo tempo, tecnologicamente, à beira-mar faz mais forte contra os problemas mais complicados.

Você pode fazer grandes aplicativos à beira-mar da web usando o material de fonte aberta.

DabbleDB era um sartup baseado em beira-mar e, hey! Avi vendeu para o Twitter em junho deste ano!

Eu digo que você não precisa esperar pelos outros para aprovar sua iniciativa.

Basta ir para ele. Torná-lo feito. Mostra-nos que as obras.

Você não está sozinho. Estamos no mesmo barco.

Perspectiva interessante de Robert Martin (da RailsConf 2009): "Que Matou Smalltalk poderia matar Ruby, Too "

Eu acho que parte do problema é o desenvolvimento-ambiente é o tempo de execução. Isto dá uma grande quantidade de energia, mas também apresenta uma curva de aprendizado maior.

Aqui é um tutorial Olá mundo.

Isto é muito diferente de outras línguas onde eu só preciso saber como abrir um editor de texto e copie e cole texto, hit salvar e executar um compilador. Eu tenho que saber como usar o meio ambiente. Esse tutorial nem sequer me mostrar como criar um programa básico (que é provavelmente mais uma falha desse tutorial) que eu possa executar.

Há definitivamente um maior custo de apenas pegar as coisas que a maioria das outras línguas.

A maioria das línguas têm algum código atraente bom que eles podem mostrar. Eu não vi isso com Smalltalk. Eu também acho que existe algum estigma para Smalltalk porque tem sido em torno de tanto tempo e ainda é relativamente obscura.

Acho que a diferença maior deles é que Ruby é muito mais semelhante ao perl em termos de useage. Smalltalk nunca teve uma posição para as línguas "script".

A VM é muito legal e espero rubi terá algo semelhante a ele, para que possamos tratar de tudo em nosso sistema operacional que está escrito em Ruby como objeto no espaço de memória, no entanto, até então eu simplesmente desfrutar concisa de Ruby, sintaxe curta, o capacidade de apenas escrever um pequeno script e reutilizá-lo mais tarde. Rubi tem todas as vantagens de perl eo OOP é muito mais semelhante ao Smalltalk de corte OOP do Perl.

Eu iria mais longe do que a resposta de Jonke, e dizem que há agora um grande número de idiomas que têm uma comunidade muito forte, quase o suficiente para todos os gostos, e um subconjunto destes têm reconhecimento convencional (ou seja, o seu gerente vai deixar você usá-los no trabalho também).

É fácil de aprender o básico de um idioma, mas para realmente usá-lo efetivamente você precisa investir tempo suficiente para aprender a plataforma e as ferramentas, bem como a sintaxe e as expressões idiomáticas. IIRC, reivindicações McConnell que leva cerca de três anos para se tornar verdadeiramente proficientes.

Dada essas coisas, é difícil justificar gastar um monte de tempo em linguagens como LISP e Smalltalk, embora eles são interessantes e talvez educacional para olhar.

Como um recém-chegado à discussão, o principal problema com Smalltalk e Lisp é que você não pode executá-los com CGI ou FastCGI em hospedagem compartilhada.

As massas plebéias nunca vai usá-los se eles precisam de VPS ou servidores dedicados para usá-los. IMHO Mar é superior a quase qualquer coisa fora ther, mas será que vai funcionar em Dreamhost ou Webfaction?

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow