Você já fez um projeto usando um idioma que não é a principal escolha para o nicho específico do projeto? Por quê? [fechadas]

4

Eu estava pensando sobre minha experiência acadêmica com Smalltalk (bem, Squeak) há algum tempo e se eu gostaria de usá-lo para algo, e isso me fez pensar: claro, é tão bom e capaz quanto qualquer linguagem popular, e tem algumas boas idéias, mas existem certas linguagens que já estão bem entrincheiradas em certos nichos de programação (C é para programação de sistemas, Java é para portabilidade e assim por diante). ..) e Smalltalk e co. não parece ter nenhuma característica diferenciadora óbvia para torná-las a escolha certa sob certas circunstâncias, ou pelo menos não tanto quanto eu posso dizer, e quando você adiciona a isso o fato de que é mais difícil encontrar programadores que saibam disso todos os tipos de outros problemas para a própria organização.

Então, se você já trabalhou em um projeto onde uma linguagem não-mainstream (como a Smalltalk) foi usada em uma linguagem mais mainstream, qual foi a razão para isso?

Para esclarecer: gostaria de focar isso em idiomas imperativos.

    
por EpsilonVector 17.03.2011 / 00:11
fonte

10 respostas

2

Estou usando o Falcon em um projeto de jogo comercial, como linguagem de script.

Não é meu dia de trabalho, no entanto.

A principal razão é que eu quero algo tão fácil de incorporar e controlar de C ++ como Lua, mas com uma sintaxe e recursos de linguagem mais parecidos com o Python. O Python pode ser incorporado, mas acho que é APITA para ser incorporado, mesmo que isso possa ser feito.

O Falcon tem uma sintaxe semelhante ao Python, mas fornece mais paradigmas, para que você possa usar os mais adequados para trabalhar com o seu projeto específico. É totalmente escrito em C ++ e feito para ser embutido (não de uma maneira Luabind, mas mais laike manipulando uma biblioteca de mecanismos específica). Você pode injetar seus módulos nos idiomas, módulos sendo escritos em C ++ (ou totalmente no Falcon). Depois de ter feito um módulo específico do aplicativo, você não precisa fazer mais nada para permitir que o Falcon trabalhe com ele.

Outra alternativa que combina com meus requisitos, mas que ainda é muito nova, é ChaiScript - isso é realmente promissor. Estou tentando usá-lo em um projeto de brinquedo, mas ainda não pude trabalhar muito com ele.

Estou usando este em outro projeto. No momento, vou usar o Falcon, mas ele está sendo refatorado no sistema de incorporação para facilitar ainda mais. Se a refatoração estiver completa, uma vez que eu preciso completar a parte de script do meu projeto (não em breve), então eu vou continuar com ela (mesmo que os roteiristas tenham que escrever em outro idioma desconhecido, eu não ligo para esse específico projeto, e é fácil de aprender para pessoas familiarizadas com Python ou Ruby de qualquer maneira).

    
por 17.03.2011 / 11:10
fonte
7

No meu trabalho diário, escrevi recentemente uma pequena ferramenta throw-away que expunha algumas funcionalidades através de uma versão ligeiramente modificada de Picol (um intérprete Tcl muito pequeno).

Conforme essas coisas acontecem, a ferramenta não foi descartada, mas cresceu e agora é uma ferramenta crítica para o projeto :(

Eu usei o Picol fora do meu fascínio por intérpretes e achei que poderia me safar porque nenhum dos meus colegas deveria ver a ferramenta.

    
por 17.03.2011 / 09:18
fonte
4

Eu usei o Haskell para programar um programa de middleware crítico. Eu poderia fazer essa escolha porque eu era o único na equipe fazendo isso (o que em si não é uma coisa boa). Outras razões para a escolha foram que o projeto era muito limitado no tempo e também que o programa resultante tinha que ser executado em um ambiente de recursos relativamente baixo.

E finalmente, eu estava com fome por tentar Haskell por algo real, tendo estudado isso por anos.

O resultado foi muito bom. O pior problema foi uma biblioteca (que era um wrapper em torno de uma biblioteca C) que vazou muito a memória, mas, felizmente, consegui substituí-la por uma biblioteca Haskell pura. As ferramentas do profiler ajudaram a encontrar o problema nesse caso. Além disso, encontrar uma boa biblioteca XML foi um tanto trabalhoso.

As melhores partes eram que implementar a coisa toda era geralmente rápido e divertido. Além disso, consegui fazer mudanças radicais e me protegeu durante o processo.

Fazer com que as pessoas se interessem por um novo idioma é difícil. Especialmente os mais experientes estão acostumados a ser bons em programar, e parece que é praticamente um matador de motivação para perceber que suas habilidades são bem específicas.

    
por 17.03.2011 / 11:03
fonte
2

Eu usei o Tcl / Tk para um protótipo de plataforma cruzada do sistema COBOL legado em transição sem uma determinação em um host / pilha de destino específico. O cliente não havia decidido se o plano de tecnologia de 3 anos e 5 anos continuaria a exigir desktops do Solaris e, caso contrário, eles precisariam migrar para o NT / 2000. Foi no início do código conscientemente descartável

Os objetivos eram passar de interfaces de terminal para janelas nativas e saídas ricamente formatadas. Usando Tcl / Tk eu poderia mudar layouts rapidamente, e usar seu exec interno para interagir com os executáveis Cobol existentes com adaptação mínima para ser conduzido puramente por opções de linha de comando.

    
por 17.03.2011 / 01:05
fonte
2

Não tenho certeza do que conta como idiomas mainstream atualmente, mas já fiz (há muito tempo) um pouco de programação Auto / Visual LISP para facilitar a geração automática de modelos e desenhos do Autocad. No final, a maior parte do código de geração estava em LISP (ele começou como um projeto Fortran / C, mas essa parte era tão simples, apenas transferimos tudo para o LISP em um ponto). Eu deixei esse lugar em algum momento, mas eu não ficaria surpreso se o projeto ainda estivesse vivo.

    
por 17.03.2011 / 01:30
fonte
2

Eu faço a maior parte do meu Ph.D. codificação de pesquisa em D . É certo que foi um pouco de um PITA porque eu tive que lidar com a imaturidade da linguagem e toolchain. Isso tem melhorado rapidamente agora que a especificação de idioma é estável. Se eu tivesse que fazer isso de novo, definitivamente, pelas seguintes razões:

  1. A maioria das coisas que eu escrevo é bem faminta por memória e crítica ao desempenho, mas também é um código protótipo onde a velocidade de desenvolvimento é importante. D é a única linguagem que conheço que pontua bem tanto na conveniência do programador quanto na eficiência do tempo de execução. (Talvez o C # coubesse na conta, mas não tem metaprogramação de modelo como D, o que torna muito mais difícil encontrar soluções eficientes de reutilização / genéricos. Ela também tem os vestígios do estilo OO na garganta e outros tipos de escravidão semelhantes. recursos de e-disciplina.)

  2. Escrevi várias bibliotecas para compensar a falta de suporte de biblioteca do D e essa foi uma experiência de aprendizado tremenda . Eu escrevi minha própria biblioteca de paralelismo SMP, que agora está em revisão para inclusão na biblioteca padrão. Eu escrevi minha própria biblioteca de estatística / aprendizado de máquina, e agora eu sinto que conheço essas coisas de ordem de magnitude melhor do que quando eu estava tendo aulas nela. Eu escrevi minha própria biblioteca de plotagem e aprendi um monte de visualização de dados e programação de GUI a partir dela. Além disso, todos esses são projetos de código aberto que posso colocar em um currículo. Se eu ficasse com uma linguagem mais mainstream, provavelmente me sentiria como se todo o material "interessante" de desenvolvimento de bibliotecas já tivesse sido feito.

  3. Participar das discussões sobre o design de idiomas, etc., também tem sido uma tremenda experiência de aprendizado.

  4. Se ninguém nunca suportou qualquer dor a curto prazo para fazer uma ruptura com as tecnologias herdadas, nós todos estaríamos programando em Fortran '77. Chame-me um idealista, mas este não é o futuro que eu quero.

por 18.03.2011 / 02:39
fonte
1

O Smalltalk por conta própria, provavelmente, não é uma coisa muito importante em relação às tecnologias tradicionais existentes. Mas se você tomar o Seaside , certamente poderá justificar a escolha.

Além disso, existem idiomas não-mainstream que são muito mais poderosos do que qualquer uma das tecnologias populares, que para um projeto complicado que requer tanto poder quanto você pode obter, simplesmente não há escolha. Eu estou usando o Lisp predominantemente para a maioria do meu trabalho de desenvolvimento, e eu tenho uma enorme cadeia de ferramentas de linguagens específicas de domínio projetadas no topo do Lisp - simplesmente não seria possível fazer isso em qualquer outra linguagem. Então agora eu estou usando idiomas não-mainstream muito mais do que os mainstream.

Outro caso para "não-mainstream" são os antigos sistemas legados com suas próprias linguagens de script estranhas - por exemplo, CADs.

    
por 17.03.2011 / 11:31
fonte
1

Trabalhei em vários projetos usando linguagens personalizadas específicas para as empresas para as quais os sistemas foram desenvolvidos. Eu também trabalhei em vários projetos usando uma nova linguagem obscura chamada Java em meados da década de 1990, uma linguagem que na época os especialistas previam que nunca seria amplamente adotada, mas que fazia o que precisávamos para fazer. E eu trabalhei em um projeto muito grande em um dialeto personalizado de Cobol, outra língua que as pessoas agora afirmam estar morta. Depois, há o projeto no qual eu tenho me envolvido um pouco em Fortran, outro em QuickBasic, Delphi, todas as linguagens que agora caberiam em seu "não mainstream", mas na época eram muito mais comuns.

    
por 17.03.2011 / 12:38
fonte
1

Im meu país, qualquer coisa que não é Microsoft, é considerado "não mainstream", incluindo linguagens de programação que podem ser "mainstream" em outros lugares (Java ou Delphi, alguém?).

Em qualquer país, muitas empresas ou departamentos do governo. tem medo de não obter desenvolvedores para um determinado (linguagem de programação e estrutura de programação), então eles preferem idiomas tradicionais.

Mas, na minha experiência, os idiomas "mainstream" podem sair pela culatra, porque isso significa que o desenvolvedor pode facilmente conseguir um emprego melhor e sair do projeto.

E os desenvolvedores que trabalham em um idioma não mainstream geralmente são mais cuidadosos com a qualidade do software.

Ter desenvolvedores demais significa que haverá mais com menos qualidade. E em alguns lugares, as empresas não podem filtrar desenvolvedores ruins, não sabem como filtrá-los ou, ainda, não se preocupam em filtrar desenvolvedores ruins, contanto que sejam baratos.

Trabalhei em um projeto Delphi, onde precisamos de mais desenvolvedores, e o cliente sabia disso. Contratamos alguns desenvolvedores de C / VB e os ensinamos sobre a linguagem e estrutura, e até mesmo, checamos suas habilidades em algoritmos / padrões de projeto. Ensinar-lhes uma linguagem não dominante, em geral, ajudou-nos a nos certificar de que eles também sabiam como resolver problemas.

    
por 17.03.2011 / 19:52
fonte
0

Fiz um projeto de otimização heurística em TI Lisp onde o resto do projeto estava em um idioma diferente ( CMS2 , se você precisa saber).

Usos semelhantes de scripts emacs lisp em ambientes C / Java.

    
por 18.03.2011 / 18:10
fonte