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


121

Ruby está se tornando popular , principalmente devido à influência do Ruby no Rails, mas parece que ele está atualmente lutando durante a adolescência. Existem muitas semelhanças entre Ruby e Smalltalk - maglev é uma prova disso. Apesar de ter uma sintaxe mais incomum, o Smalltalk possui toda (se não mais) a beleza orientada a objetos do Ruby.

Pelo que li, Smalltalk parece ter Ruby batendo:

Parece que Ruby está apenas reinventando a roda. Então, por que os desenvolvedores Ruby não usam o SmallTalk? O que Ruby tem no Smalltalk não?

Para constar: eu sou um cara Ruby com pouca ou nenhuma experiência em Smalltalk, mas estou começando a me perguntar por quê.


Edit: Eu acho que a questão da facilidade de script foi abordada pelo GNU Smalltalk . Pelo que entendi, isso permite que você escreva smalltalk em arquivos de texto antigos comuns e não precisa mais estar no IDE Smalltalk. Você pode executar seus scripts com:

gst smalltalk_file

47
Porque todo mundo ainda está esperando por "Smalltalk on Snails"?
Mark Rushakoff 17/11/2009

10
Tecnicamente, é chamado de 'Seaside' (www.seaside.st) e é executado rapidamente na VM Gemstone, que possui um compilador JIT. Também há um porto de Ruby para a VM Gemstone, chamado Maglev.
ConcernedOfTunbridgeWells

3
Depois de passar por todos esses comentários abaixo, sendo um fã de rubi dos últimos 5 anos, agora estou tentado a aprender Smalltalk o mais cedo possível
Amol Pujari

1
O GNU Smalltalk é quase a única implementação gratuita que não é muito acoplada à GUI. Eu acho que isso ainda é crítico.
eonil

O link "controle de origem distribuído" está quebrado.
Piovezan

Respostas:


88

Sou mais um Pythonista do que um usuário Ruby, no entanto, as mesmas coisas são válidas para Ruby pelas mesmas razões.

  • A arquitetura do Smalltalk é um tanto insular, enquanto Python e Ruby foram criados desde o início para facilitar a integração. O Smalltalk nunca ganhou um corpo de suporte a aplicativos híbridos da mesma forma que o Python e o Ruby, então o conceito de 'smalltalk como linguagem de script incorporada' nunca pegou.

    Além disso, Java não era a coisa mais fácil de interagir com outras bases de código (o JNI é bastante desajeitado), mas isso não impediu que ele ganhasse conhecimento. Na IMO, o argumento de interface é significativo - a facilidade de incorporação não prejudica o Python - mas esse argumento tem peso moderado, pois nem todos os aplicativos exigem esse recurso. Além disso, versões posteriores do Smalltalk abordaram substancialmente a insularidade.

  • A biblioteca de classes da maioria das principais implementações de conversas pequenas (VisualWorks, VisualAge etc.) era grande e tinha reputação de uma curva de aprendizado bastante acentuada. A maioria das funcionalidades principais do Smalltalk está oculta em algum lugar da biblioteca de classes, até mesmo itens básicos como fluxos e coleções. O paradigma da linguagem também é um choque cultural para alguém não familiarizado com ele, e a visão fragmentada do programa apresentado pelo navegador é bem diferente do que a maioria das pessoas estava acostumada.

    O efeito geral é que o Smalltalk obteve uma reputação (um tanto merecida) por ser difícil de aprender; leva bastante tempo e esforço para se tornar um programador Smalltalk realmente proficiente. Ruby e Python são muito mais fáceis de aprender e atualizar novos programadores.

  • Historicamente, as implementações convencionais do Smalltalk eram muito caras e precisavam de hardware exótico para serem executadas, como pode ser visto neste post do net.lang.st80 de 1983 . O Windows 3.1, NT e 95 e OS / 2 foram os primeiros sistemas operacionais de mercado de massa no hardware convencional, capazes de suportar uma implementação Smalltalk com uma integração decente do sistema nativo. Anteriormente, o Mac ou o hardware da estação de trabalho eram as plataformas mais baratas capazes de executar o Smalltalk de maneira eficaz. Algumas implementações (particularmente a Digitalk) suportaram muito bem os sistemas operacionais de PC e conseguiram ganhar alguma tração.

    No entanto, o OS / 2 nunca foi tão bem-sucedido e o Windows não conseguiu aceitação convencional até meados da década de 90. Infelizmente, isso coincidiu com o surgimento da Web como plataforma e um grande impulso de marketing por trás do Java. O Java conquistou a maior parte da atenção na última parte da década de 1990, tornando o Smalltalk um pouco desinteressado.

  • Ruby e Python funcionam em uma cadeia de ferramentas mais convencional e não estão fortemente acoplados a um ambiente de desenvolvimento específico. Embora os IDEs do Smalltalk que usei sejam bons o suficiente, eu uso o PythonWin para desenvolvimento em Python, em grande parte porque ele tem um bom editor com destaque de sintaxe e não fica sob os pés.

    No entanto, o Smalltalk foi projetado para ser usado com um IDE (na verdade, o Smalltalk era o IDE gráfico original) e ainda possui alguns recursos interessantes não replicados por outros sistemas. Testar o código com destaque e 'Mostrar' ainda é um recurso muito bom que eu nunca vi em um IDE Python, embora não possa falar por Ruby.

  • O Smalltalk chegou um pouco tarde à festa de aplicativos da web. Os primeiros esforços, como o VisualWave, nunca foram muito bem-sucedidos e só depois que a Seaside foi lançada, uma estrutura da Web decente conseguiu aceitação nos círculos do Smalltalk. Enquanto isso, o Java EE teve um ciclo de vida de aceitação completo, começando com fanboys entusiasmados, promovendo-o e finalmente ficando entediado e migrando para Ruby; -}

    Ironicamente, o Seaside está começando a ter um pouco de atenção entre os conhecedores, para que possamos descobrir que o Smalltalk monta esse retorne à popularidade.

Dito isto, o Smalltalk é um sistema muito bom depois que você decide como conduzi-lo.


1
Eu acho que o ponto da biblioteca de classes está fora da base. Eu sei que Smalltalk e Ruby e as bibliotecas de classes são muito semelhantes. Qualquer problema que eu tivesse aprendendo um, eu teria aprendido o outro. Tendo feito mais ruby ​​primeiro, tornou as bibliotecas Smalltalk muito mais fáceis de aprender. Eles são notavelmente semelhantes na maioria dos lugares. Eu não acho que nada sobre a biblioteca de classes ou a própria linguagem torne o Smalltalk mais difícil que o Ruby.
Sean T Allen

2
Tanto a VW como a VA Smalltalk costumavam ter uma reputação de uma curva acentuada de aprendizado devido ao tamanho das bibliotecas de classes. Isso foi amplamente reconhecido na época. Aprendi Smalltalk em uma versão antiga do Digitalk Smalltalk / V para DOS, que tinha uma biblioteca de classes muito menor. O manual para isso era do mesmo tamanho do livro PP Ruby e, como esse livro, a referência da biblioteca de classes era cerca da metade da contagem total de páginas. No entanto, as bibliotecas de classes para VW e VA são muito, muito maiores.
ConcernedOfTunbridgeWells

79

Quando saio de casa de manhã para ir trabalhar, muitas vezes luto com a decisão de virar à esquerda ou à direita no caminho (moro no meio de uma rua). De qualquer maneira me levará ao meu destino. Uma maneira me leva à estrada que, dependendo do trânsito, provavelmente me levará ao escritório mais rapidamente. Eu dirijo muito rápido por pelo menos parte do caminho e tenho uma boa chance de ver uma garota bonita ou duas a caminho do trabalho :-)

A outra maneira me permite viajar por uma estrada de volta muito encantadora e ventosa, com cobertura completa de árvores. Esse caminho é bastante agradável e as duas abordagens são definitivamente as mais divertidas, embora isso signifique que chegarei ao escritório mais tarde do que se tivesse tomado a estrada. Cada caminho tem seus méritos. Nos dias em que estou com muita pressa, geralmente vou pegar a estrada, embora possa entrar no trânsito e também aumentar minhas chances de sofrer um acidente (se não tomar cuidado com a pressa). Outros dias, posso escolher o caminho arborizado e seguir em frente, apreciando a paisagem e perceber que estou atrasado. Posso tentar acelerar, aumentando minhas chances de conseguir uma multa ou causar um acidente.

Nenhum dos dois lados é melhor que o outro. Cada um tem seus benefícios e riscos, e cada um me levará ao meu objetivo.


5
Qual é a interestadual e qual é a estrada de volta ventosa com cobertura de árvore? lol
Charlie Flowers

9
Charlie: que é o que torna zen :)
xofz

32
E qual idioma tem as meninas mais bonitas?
the Tin Man

25

Eu acho que sua pergunta está um pouco errada. Você não deve escolher, deve aprender os dois!

Se você realmente estiver em uma posição em que poderá escolher a próxima estrutura (vm, infraestrutura), precisará decidir o que usar e poderá fazer uma pergunta específica com prós e contras da perspectiva do que seu aplicativo pretende fazer.

Eu usei smalltalk (adoro) e ruby ​​(adoro).

Em casa ou no projeto de código aberto, posso usar todos os idiomas de que gosto, mas ao fazer o trabalho tenho que adotar.

Comecei a usar ruby ​​(no trabalho) porque precisávamos de uma linguagem de script que se comportasse mais ou menos igualmente sob solaris, linux e windows (98,2000, xp). Ruby era na época desconhecido para o joe médio e não existiam trilhos. Mas foi fácil vender para todos os envolvidos.

(Por que não python? A verdade? Uma vez, passo uma semana caçando um bug que aconteceu quando um terminal converteu meu espaço em uma guia e a intenção ficou confusa).

Então as pessoas começaram a codificar cada vez mais em rubi porque era muito relaxante, desfrutando e não uma nuvem no céu.

Paul Graham resume tudo

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

e

Para ser atraente para os hackers, uma linguagem deve ser boa para escrever os tipos de programas que eles querem escrever. E isso significa, talvez surpreendentemente, que seja bom para escrever programas descartáveis.

E quando estávamos na terra Lisp, tente substituir o LISP por smalltalk

As bibliotecas, a comunidade e o momento de Ruby são bons

Portanto, se o LISP ainda é mais poderoso que o Ruby, por que não usar o LISP? As objeções típicas à programação no LISP são:

  1. Não há bibliotecas suficientes.
  2. Não podemos contratar programadores LISP.
  3. O LISP não chegou a lugar algum nos últimos 20 anos.

Essas objeções não são esmagadoras, mas certamente valem a pena considerar.

e

Agora, dada a escolha entre um idioma poderoso e um idioma popular, pode fazer um excelente sentido escolher o idioma mais poderoso. Mas se a diferença de poder é pequena, ser popular tem todos os tipos de vantagens. Em 2005, eu pensaria muito antes de escolher LISP em vez de Ruby. Provavelmente, só o faria se precisasse de código otimizado ou macros que agissem como compiladores completos.


4
Ahem, "nos últimos 20 anos"?!?! Eu acho que você quis dizer "nos últimos 51 anos". :-)
DigitalRoss

1
@DigitalRoss - eu iria com 20; O LISP era realmente bastante grande em certos círculos a certa altura, mas (apesar da ViaWeb), nenhum novo 'aplicativo matador' foi realmente visto desde os anos 80. No entanto, as tecnologias baseadas em LISP receberam bastante financiamento nos anos 60, 70 e 80; as pessoas realmente pensaram que o LISP estava indo a lugares por um bom tempo.
ConcernedOfTunbridgeWells

2
@DigitalRoss sim, se você ignorar coisas como continuações, métodos múltiplos, macros, otimizações de chamada de cauda, ​​bem no alto da minha cabeça.
Frank Shearar

Eu sempre acho esse tipo de argumento menos agradável. Não existe uma melhor linguagem e qualquer engenheiro de software pode fazer lisp, esquema, ruby, php ou c ou o que for. E se ele não puder, ele poderá aprender em duas semanas. Uma linguagem é apenas uma ferramenta. Você não precisa dormir com isso.
Edgar Klerks

22

Eu diria o contrário: a sintaxe Smalltalk é uma das sintaxes mais simples e poderosas da linguagem de programação.


7
Só quero dizer amém!
Schpaencoder

19

É verdade que os idiomas são muito parecidos. A maneira superficial de interpretar isso é chamar Ruby de banda cover do Smalltalk. A interpretação mais razoável é que o sistema fechado do Smalltalk o isolou, enquanto a participação de Ruby na ecologia do Unix e o hábito de se apropriar de recursos de todos os idiomas sob o sol oferecem uma curva de adoção infinitamente mais suave e integração sem esforço com ferramentas importantes como o Git.

Giles Bowkett


17

Adivinha quem disse isso? (a citação é próxima, talvez não exata): "Eu sempre pensei que o Smalltalk venceria o Java. Só não sabia se seria chamado de 'Ruby' quando o fizesse".

Drum roll ....

...

A resposta é ... Kent Beck



15

o que Ruby tem que Smalltalk não?

  • Suporte atual massivo pelas principais plataformas (IronRuby e jRuby) que enriquecem o conjunto de bibliotecas
  • Evangelistas como Dave Thomas, que há anos viajam pelo país pregando o evangelho de sua língua. Eu vi Dave em conferências em Java afirmando que ele não conhece Java e que prefere Ruby.
  • Imóveis fortes e atuais nas estantes de livros
  • O criador do Ruby disse que pensa no programador: a sintaxe do Ruby parece ter esse apelo zen. É difícil definir, mas parece galvanizar os ventiladores.
  • Apresentações criativas e dinâmicas, como Giles, e essa que ganha participação

Eu acho que seu ponto de vista é bem aceito. Como um amigo disse uma vez, Ruby pode ser "vinho velho em uma nova garrafa" em relação ao Smalltalk. Mas às vezes a nova garrafa é importante. Um vinho deve estar no lugar certo, na hora certa.


Seu primeiro marcador está desativado. O suporte a JVM e .NET VM é péssimo para o Smalltalk, já que cada implementação já é executada em uma VM (de que outra forma eles podem funcionar tão bem em vários sistemas operacionais, certo?) A sintaxe do Ruby é mais complicada que a do Smalltalk. É difícil definir qual é parte do problema;);)

1
Sim, parte da razão pela qual algumas pessoas podem usar o jruny / ironruby é a imaturidade relativa do ruby ​​vm, mas existem algumas bibliotecas muito boas disponíveis para o .net / jvm que eles podem querer usar e que não possuem equivalentes em nenhum outro lugar além de seu muito mais fácil para algumas empresas fazerem a malha com suas bases de código java / c #.
Roman A. Taycher

2
Obviamente, eu considero que estimar "imóveis fortes e atuais nas estantes de livros" é uma penalidade de uma linguagem complexa sem um ambiente dinâmico e dinâmico. Quando eu codifiquei em C ++, eu tinha prateleiras cheias de livros de pegadinhas. Depois de me mudar para Smalltalk (via Ruby), não sinto falta deles nem um pouco. Baseando-se no próprio IDE para a maioria orientação, eu raramente deixar a imagem mais de uma rápida pesquisa no google, e tem se valorizou nos um pouco dessa prateleira imobiliário com o Game of Thrones série;)
Sean DeNigris

14

Me bate. Passei um ano conferindo Ruby e fazendo alguns projetos pequenos para ver como eu gostava. Eu acho que sou um fanático do Smalltalk porque toda vez que eu me sentava para trabalhar com Ruby, suspirava e pensava "eu realmente prefiro fazer isso no Smalltalk". Finalmente, cedi e voltei para Smalltalk. Agora estou mais feliz. Mais feliz é melhor.

O que, é claro, sugere a pergunta "Por quê?". Em nenhuma ordem particular:

  1. Porque o IDE impressiona qualquer outra coisa com a qual eu já trabalhei. Isso inclui várias plataformas, do ISPF nos mainframes IBM ao Visual (. *) Da Microsoft, incluindo coisas como Visual Basic 4-6, Visual C ++ (várias encarnações), Turbo Pascal e descendentes da Borland (por exemplo, Delphi) e outras coisas sobre DEC máquinas no modo de caracteres e no X-Windows.
  2. Porque a imagem é um lugar bonito para se viver. Eu posso encontrar o que eu quero lá. Se não consigo descobrir como fazer algo, sei que em algum lugar da imagem é um exemplo do que estou tentando fazer - tudo o que preciso fazer é caçar até encontrá-lo. E é auto-documentado - se você quiser ver os detalhes de como algo funciona, basta abrir um navegador na classe em que está interessado, olhar para o método e é assim que funciona. (OK, eventualmente, você acessará algo que chama de primitivo, e então "aqui existem dragões", mas geralmente é compreensível a partir do contexto). É possível fazer coisas semelhantes no Ruby / C ++ / C, mas não é tão fácil. Fácil é melhor.
  3. A linguagem é mínima e consistente. Três tipos de mensagens - unário, binário e palavra-chave. Isso também descreve a prioridade da execução - primeiro mensagens unárias, depois binárias e depois palavras-chave. Use parênteses para ajudar as coisas. Dang pouca sintaxe, realmente - tudo é feito com o envio de mensagens. (OK, a atribuição não é uma mensagem enviada, é um operador. Assim como o operador 'return' (^). Os blocos são fechados por pares de chaves quadradas ([]). Pode haver um ou dois outros bits 'mágicos', mas pouco ...).
  4. Blocos. Sim, eu sei, eles estão lá no Ruby (e outros), mas, caramba, você literalmente não pode programar no Smalltalk sem usá-los. Você é forçado a aprender como usá-los. Às vezes, ser forçado é bom.
  5. Programação orientada a objetos sem compromisso - ou alternativas, para esse assunto. Você não pode fingir que está "fazendo objetos" enquanto continua fazendo a mesma coisa.
  6. Porque isso vai esticar seu cérebro. As construções confortáveis ​​com as quais todos nos acostumamos (se-então-outro, fazer-enquanto, para (;;), etc) não estão mais lá, então você precisa aprender algo novo. Existem equivalentes a todos os itens acima (e mais), mas você precisará aprender a pensar de maneira diferente. Diferentemente é bom.

Por outro lado, isso pode ser apenas as divagações de um cara que está programando desde os dias em que os mainframes governavam a Terra, tivemos que caminhar oito quilômetros para lidar com tempestades de neve ofuscantes, subindo os dois sentidos e computadores usavam rosquinhas para memória. Não tenho nada contra Ruby / Java / C / C ++ /, todos são úteis no contexto, mas me dê Smalltalk ou me dê ... bem, talvez eu deva aprender Lisp ou Scheme ou ... :-)


1
Eu pensei que a pergunta era "O que Ruby tem no Smalltalk não?"
Mauricio

1
@Mauricio, e @Bob respondeu: "Bate-me".
systemovich

1
Brilhantemente, adorei! Por que algo não pode ser muito melhor apesar de ser menos popular? Se você não concordar, eu ouso dizer que você não obter Smalltalk ;-)
Amos M. Carpenter

@aaamos - obrigado. Suspeito que o motivo pelo qual o Smalltalk não seja popular seja o número 6 e, em menor grau, o número 5. Smalltalk não é o tipo de lugar com a mesma sintaxe da sua mãe - é diferente. Por exemplo, se você conhece C, C ++, Java e C # se sentem bem à vontade. E o "como" e "por que" do comportamento do Smalltalk pode ser um pouco perturbador. (Eu correrei o risco de que, se um novo Smalltalker não sentir que sua cabeça está se retorcendo, eles são tão brilhantes que gritaram imediatamente, ou simplesmente não estão entendendo. Sim, eu me pergunto como o "brilhante "coisa seria :-).
Bob Jarvis - Restabelece Monica

Você já tentou depurar com alavanca (e plugins) e codificação ao vivo com recargas quentes de arquivos salvos? Foi a melhor programação que experimentei.
Rivenfall

11

Smalltalk: as pessoas encaminham ifTrue: [think] ifFalse: [sem pensar]

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

1) O fluxo de controle semelhante ao RPN do Smalltalk por mensagens é como o Lisp - é regular e legal, mas deixa as pessoas estranhas.

2) Ruby permite que as pessoas escrevam código usando a maneira idiomática das pessoas - faça blá, a menos que haja um motivo para não fazê -lo.

update reescreveu o exemplo Smalltalk para realmente ser um código mais legal.


4
Provavelmente o inglês é uma das piores maneiras de expressar instruções de programação. Quero dizer, causa confusão suficiente entre as pessoas, sem falar nos computadores. Faça blá? Quem deve fazer blá? em que? Além disso, seu código ruby ​​não faz sentido e não é válido. Deve ser: Ruby: people.think_forwards, a menos que people.think_backwards? eo SmallTalk deve ser: Smalltalk: (think_forwards pessoas?) ifTrue: [think_forwards pessoas])
Donalbain

2
Você também pode adicionar um método chamado, a menos que: aBlock à classe BlockClosure da categoria Kernel-Methods que avaliaria aBlock e ifTrue: avalie o bloco de chamada.
Ricardo de Cillo

3
@ Donalbain, eu não estava sugerindo que estas eram declarações de programação literais, mas indicativas da ordem das declarações. Eu pensei que isso era bastante óbvio quando escrevi minha resposta.
Andy Dent

1
@donalbain Muito verdadeiro, de fato existe. Um fluxo de controle semelhante ao Ruby está em github.com/randycoulman/SuffixConditionals . Andy, há um bug em seu código - as pessoas atrasadas não acho, então você deveria ter enviado #ifFalse: ;-P
Sean DeNigris

O Smalltalk tem um marketing ruim: sintaxe e imagem estranhas. Ruby é mais normal, mas também possui uma sintaxe de boa qualidade. Java é digitado e compilado, o que tranquiliza os clientes. Eu não me importaria de aprender e usar uma sintaxe estranha se isso não afetasse meu próprio "marketing" como programador.
Rivenfall

8

Ruby é o idioma atual do buzz. É mais fácil comercializar software construído com ele agora do que uma linguagem desenvolvida nos anos 70.


O fato de ter sido "desenvolvido nos anos 70" não tem nada a ver com o quão difícil é se desenvolver.
Graco

3
e meu comentário não tem nada a ver com desenvolvimento.
Codificador1

3
Desculpe, tenho tendência a interpretar mal quando estou cansada, por isso tenho que passar minhas férias pedindo desculpas às pessoas que intimidaram.
Graco

8

Comunidade! Ruby e especialmente Rails tem uma comunidade tão boa. Ao brincar com o smalltalk, parecia que não havia tantas transmissões de tela, artigos, postagens de blog etc. escritos sobre o Smalltalk.


7

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

  • muito módulos, projetos interessantes e outros baseados em Ruby.
  • Se você tiver problemas para fazer algo no Ruby, será trivial encontrar ajuda em algum lugar.
  • O Ruby está instalado em muitos computadores agora (está incluído por padrão no OS X, em muitas distribuições Linux e há bons instaladores para Windows) - eu não vi o smalltalk instalado por padrão em qualquer máquina que usei.

Eu diria se um idioma é superior a outro é irrelevante. Como exemplo, o PHP pode não ser o "melhor" de todos os tempos, mas eu ainda consideraria usá-lo no Ruby on Rails (uma ferramenta "melhor" para criar sites) porque é muito difundido.

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


7

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

  • Do próprio Dave Thomas, "[após o] vídeo sobre 'Como criar um blog em dez minutos' ... Ruby deixou de ser uma linguagem de nicho agradável e passou a ser 'uma linguagem na qual você criou aplicativos Rails'" ( Ruby Conference Palestra de 2010 ).
  • Os primeiros fornecedores de Smalltalk cobraram proibitivamente
  • O Smalltalk, porque foi inventado (antes de seu tempo) há 30 anos, ocorre a muitos como uma linguagem antiga e "morta" (como FORTRAN)
  • as empresas consideram o Smalltalk uma vantagem tão competitiva que ocultam seu uso

Enquanto os idiomas são semelhantes nos recursos OO, o assassino do Smalltalk vantagem é o ambiente ao vivo, open ( 'imagem' do muito mal compreendido). Depois de verificar este exemplo de programação no Smalltalk , o debate terminou.


5

Para mim, não se trata tanto do que Ruby tem, mas do que Ruby não tem. E o que ele não possui é a necessidade de uma VM e um ambiente completo.

Smalltalk é ótimo - é onde aprendi conceitos de OO, mas, para facilitar o uso, busco Ruby. Eu posso escrever código Ruby no meu editor favorito e executá-lo na linha de comando.

Então, para mim, é isso que eu escolho Ruby em vez de Smalltalk.


Mas vá em frente e aprenda Smalltalk também.
Simon Knights

Conforme minha edição: o GNU Smalltalk permite que você use seu editor favorito e execute a partir da linha de comando.
2-idiota #

Sim - obrigado - apenas dei uma olhada e baixei uma cópia!
Simon Knights

2
Bem, ele também não possui uma ótima estrutura da web. Rails é ok, mas não é nenhum Mar
Stephan Eggermont

3
Qualquer plataforma smalltalk permite escrever código smalltalk no seu editor favorito. Mas se você gosta de se desconectar do mundo ao vivo, a escolha é sua. Apenas saiba que você está perdendo cerca de 90% da produtividade ao fazê-lo.
Igor Stasenko 6/03/12

5

Acho que todo mundo que trabalha com Ruby há algum tempo reconhece sua profunda dívida com o Smalltalk. Como uma dessas pessoas, o que eu gosto no Ruby sobre o Smalltalk? Eu acho que, do ponto de vista da linguagem, é o açúcar. O Ruby é deliberadamente uma linguagem com muita sintaxe e açúcar, enquanto o Smalltalk é uma linguagem com um mínimo de sintaxe. Ruby é essencialmente o modelo de objeto Smalltalk com açúcar de sintaxe Perlish. Por acaso, gosto do açúcar e acho que torna a programação mais divertida.


1
O Ruby tem um modelo de objeto diferente do Smalltalk. Eu diria "influenciado por", mas não o mesmo. Você pode escrever programas ruby ​​de maneira baseada em protótipos, evitando a necessidade de criar novas classes. Embora isso seja incomum, o Smalltalk simplesmente não suporta isso.
Dafydd Rees

2
Eu gosto de smalltalk, porque posso inventar e usar açúcar de sintaxe própria sempre que preciso. Não há necessidade de açúcar se você já pode fazer tudo com uma sintaxe mínima.
Igor Stasenko 6/03/12

5

Você pode encontrar um emprego facilmente fazendo Ruby.Embora eu realmente goste do Smalltalk, é praticamente impossível entrar no nicho do Smalltalk. Existe uma maneira de contornar isso, mas se você não entrou quando era popular, é praticamente impossível agora.

Todas as outras razões empalidecem na insignificância, porque você precisa gastar bastante tempo, concentrado no trabalho real para aprender um idioma adequadamente. Se você não é rico de forma independente, a melhor maneira de fazer isso é a exposição a ele no trabalho.


4

Porque as distribuições do Smalltalk foram cotadas em múltiplos de US $ 1000 USD, enquanto o Ruby é gratuito.


4

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


3
Esse é o caminho errado. O Smalltalk possui uma sintaxe muito mais fácil.
21119 Stephan Eggermont

1
Somente se você pensar em rpn. A maioria das pessoas não. Na verdade, tenho orgulho do fato de que este post continua aumentando e diminuindo os votos.
21449 sal

12
RPN? Java: foo.bar () Perl: foo-> bar () Python: foo.bar () Smalltalk: foo bar Portanto, além de ter uma sintaxe mais simples, se você afirma que o Smalltalk é RPN, é necessário dizer que todas as principais linguagens OO são "RPN".
Randal Schwartz

2
Basta comparar a quantidade de palavras-chave Ruby em comparação com a quantidade de palavras-chave do Smalltalk. E isso é apenas o começo! A sintaxe do Smalltalk se encaixa em um guardanapo, tente fazer isso com Ruby e você terá dificuldades.
Froginvasion

3

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


Sim. O TextMate é ótimo, o suporte ao Eclipse é bom e o Emacs tem um modo decente.
Pete

6
Se você acha que "TextMate / Eclipse / Emacs" é comparável ao IDE interno do Smalltalk, você não viu um Smalltalk real!
Randal Schwartz

Ainda sinto falta de select -> 'Show It' do IDE nos sistemas com os quais hoje construo - com uma exceção: as ferramentas de desenvolvimento SQL do SQL Server permitem destacar uma seleção e executá-la como uma consulta. Smalltalk é influente se nada mais!
ConcernedOfTunbridgeWells

O IDE chegando mais perto do Smalltalk é IMHO ArachnoRuby. É melhor do que qualquer integrado Emacs / TextMate etc. No entanto parece que as pessoas estão muito felizes com algumas janelas abertas execução de ferramentas diversas Saudações
Friedrich

@Friedrich Re "as pessoas estão muito felizes com algumas janelas abertas executando diversas ferramentas" ... "As linguagens de programação ensinam você a não querer o que elas não podem fornecer. Você precisa pensar em uma linguagem ..." - Paul Graham
Sean DeNigris

3

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

Eu posso te dizer por experiência pessoal. Ainda usando Smalltalk, adore e usei alguns sabores. Embora o Smalltalk seja um ótimo idioma e seja tudo o que você mencionou, você provavelmente não convencerá o CIO / CTO médio a usar o Smalltalk em um novo projeto. Claro, você pode até ter dificuldade em convencer um CIO / CTO conservador a usar Ruby. No final, você deve ter muito cuidado se desejar suporte comercial de longo prazo e a capacidade de encontrar funcionários externos que possam dar suporte aos seus sistemas no futuro. Como exemplo, o Smalltalk foi realmente muito importante no início dos anos 90 e a IBM investiu pesadamente nele no final dos anos 90. Para o IBM Smalltalk, seria o próximo idioma para todos os aplicativos de negócios. A IBM colocou o Smalltalk em tudo, incluindo seus sistemas de mainframe. Java se tornou popular, assumiu o mercado, e Smalltalk se tornou um player de nicho. Há mais de um ano, a IBM lançou o idioma (seu termo é pôr do sol). Além disso, dê uma olhada no histórico. ParkPlace e Digitalk, onde os primeiros grandes players comerciais na arena de Smalltalk, eles se fundiram e depois faliram.


Smalltalk "tem pernas negócios" - se você já tem o direito de fundo e pode encontrar as oportunidades certas ...
Dafydd Rees

Seu título é exagerado. Nem todos os negócios são limitados por CTOs míopes. Como Paul Graham disse quando desmascarou completamente o mito de que uma linguagem convencional é mais segura: "Você terá dificuldade em convencer o chefe de cabelos pontudos a permitir que você construa coisas no Lisp ... Mas se você trabalha em uma startup que não ainda não tem chefes de cabelos pontudos, você pode ... usar a tecnologia que seus concorrentes, colados de maneira imutável na linguagem mediana, nunca serão capazes de igualar ".
Sean DeNigris

2

Eu amo Smalltalk e Ruby - mas descobri que Ruby é mais aplicável ao que faço diariamente e está mais próximo do meu coração (na prática). O que Ruby oferece que o Smalltalk não oferece?

  • Script baseado em texto
  • Baixos requisitos de implementação (são executados em mais locais)
  • Mais fácil de aprender e justificar (programadores Perl e Python terá nenhuma dificuldade
  • Mais fácil mover programas - arquivos de texto!
  • Interage bem com o ambiente nativo
  • Em qualquer lugar que o Java roda, o jRuby executa ...
  • Comunidade maior e muito mais ativa

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


Quais "lugares" o Ruby executa e o Smalltalk não? O Pharo Smalltalk, por exemplo, roda em Mac, Windows, Unix, sem um sistema operacional (o Ruby pode fazer isso?) E está sendo portado para várias plataformas móveis (Android, iOS).
Sean DeNigris

E o FreeBSD e o OpenBSD? (não, não sei a resposta ...) E o Solaris, o HP-UX e o OpenVMS? Também não gostaria de usar o Ruby ou o Smalltalk no Android ou iOS. O maior problema não é o sistema operacional, mas a memória: o Ruby será executado com consideravelmente menos memória que o Smalltalk.
Mei

Aparentemente, existe uma VM do FreeBSD (veja o último marcador do OP em forum.world.st/SOB-minutes-3-6-12-td4453817.html ). Não tenho certeza dos outros. Quanto ao Android e iOS, se você gostaria de usar o Smalltalk, há uma pergunta diferente do que está disponível ;-) As pessoas têm postado sobre experiências bem-sucedidas nessas plataformas, das quais vi alguns screencasts promissores.
Sean DeNigris 23/03

Isso também me lembra - lembro-me de um Smalltalk for the Palm.
Mei

2

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

Para nós , um pouco de estrutura interna, que construímos em alto mar é realmente nossa superpotência.

Eu amo a comunidade RoR, ela tem a atitude certa. Isso é muito, muito valioso. Mas, ao mesmo tempo, tecnologicamente, a beira-mar o fortalece contra problemas mais complicados.

Você pode criar ótimos aplicativos da Web à beira-mar usando coisas de código aberto.

dabbledb era um sartup à beira-mar e, ei! A Avi o vendeu para o twitter em junho deste ano!

Eu digo que você não precisa esperar que outras pessoas aprovem sua iniciativa.

Apenas vá em frente. Faça isso. Mostre-nos que funciona.

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



0

Eu acho que parte do problema é o ambiente de desenvolvimento é o tempo de execução. Isso dá muito poder, mas também apresenta uma curva de aprendizado maior.

Aqui está um tutorial Olá, mundo.

Isso é muito diferente de outros idiomas em que eu só preciso saber como abrir um editor de texto e copiar e colar texto, clicar em salvar e executar um compilador. Eu preciso saber como usar o ambiente. Esse tutorial nem me mostra como criar um programa básico (que provavelmente é mais uma falha desse tutorial) que eu posso executar.

Definitivamente, há um custo mais alto de apenas começar as coisas do que a maioria dos outros idiomas.

A maioria dos idiomas possui um código atraente que eles podem exibir. Eu não vi isso com Smalltalk. Eu também acho que há algum estigma no Smalltalk porque ele existe há tanto tempo e ainda é relativamente obscuro.


Na parte inferior da página: informe-se: 'Olá, mundo!'. Concordo que a curva de aprendizado é mais acentuada, mas usar "olá, mundo" como prova, acho, é demais. :)
jop

Meu objetivo era ver como escrever algo simples como hello workld, o tutorial precisa dizer quais janelas você precisa abrir. Os nomes e usos das janelas não são algo que vou adivinhar. Levei um pequeno clique apenas para encontrar as janelas sobre as quais estava falando.
Steve g

1
Conforme minha edição: o GNU Smalltalk permite que você use seu editor favorito e execute a partir da linha de comando.
2-idiota #

rubi -e 'puts "Olá mundo"'
Marcel Valdez Orozco

1
pharo [nome do arquivo da imagem] -e "auto-informe: 'olá mundo'" "
Sean DeNigris 30/04

0

Eu acho que a maior diferença é que Ruby é muito mais parecido com o perl em termos de USE. O Smalltalk nunca se posicionou nas linguagens de "script".

A VM é muito legal e espero que o ruby ​​tenha algo semelhante a ele, para que possamos tratar tudo no nosso sistema operacional que está escrito em ruby ​​como objeto no espaço da memória; no entanto, até então, eu simplesmente aprecio a sintaxe curta e concisa do Ruby, a capacidade de apenas escreva um pequeno script e reutilize-o mais tarde. Ruby tem todas as vantagens do perl e o OOP é muito mais parecido com o smalltalk do que o hack do OOP do perl.


0

Eu iria além da resposta de Jonke e diria que agora há um grande número de idiomas que têm uma comunidade muito forte, quase o suficiente para todos os gostos, e um subconjunto deles tem reconhecimento mainstream (ou seja, seu gerente permitirá que você os use em trabalho também).

É fácil aprender o básico de um idioma, mas para usá-lo efetivamente, você precisa investir tempo suficiente para aprender a plataforma e as ferramentas, bem como a sintaxe e os idiomas. IIRC, McConnell afirma que leva cerca de três anos para se tornar verdadeiramente proficiente.

Dadas essas coisas, é difícil justificar gastar muito tempo em idiomas como LISP e Smalltalk, embora eles sejam interessantes e talvez educacionais.


0

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

As massas não lavadas nunca as usarão se precisarem de VPS ou servidores dedicados para usá-las. O IMHO Seaside é superior a quase tudo, mas será executado no Dreamhost ou no Webfaction?


Eu me pergunto se isso ainda é muito de uma barreira agora que por exemplo Oceano Digital está oferecendo VPS para $ 0,007 / hr
Sean DeNigris
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.