понедельник, 9 апреля 2018 г.

Sistema de comércio ocaml


OCaml.
Programação por tipo.
Um dos maiores pontos fortes do OCaml é o seu poderoso sistema de tipo estático. O compilador OCaml é capaz de detectar automaticamente uma grande variedade de erros, permitindo que o desenvolvedor corrija os problemas antes de liberar um software utilizável. Os programas podem ser confiáveis, sem perder a eficiência. Além disso, o compilador executa muita análise em tempo de compilação, economizando verificações onerosas pelo tempo de execução do idioma quando o programa é executado. É por isso que os programas OCaml são altamente otimizados e podem até ser mais rápidos do que os programas C equivalentes, ao mesmo tempo que são muito mais seguros!
Usuários industriais.
Os usuários industriais da OCaml incluem grandes empresas de software, como Microsoft ou Citrix, empresas financeiras como a Jane Street Capital ou a SimCorp e empresas críticas de software, como a CEA ou o Dassault System.
Usuários industriais da OCaml documentaram as razões pelas quais eles usam OCaml e como eles usam. Esses recursos podem ser úteis para as empresas que consideram o uso do OCaml em seu ambiente de produção.

Empresas que usam OCaml.
"O Kamam ajuda-nos a adaptar-se rapidamente às mudanças nas condições do mercado, e passar de protótipos a sistemas de produção com menos esforço. Bilhões de dólares de transações fluem através de nossos sistemas todos os dias, então entender isso é importante. "Jane Street.
Facebook, Estados Unidos.
O Facebook criou uma série de ferramentas de desenvolvimento importantes usando o OCaml. Hack é um compilador para uma variante do PHP que visa conciliar o rápido ciclo de desenvolvimento do PHP com a disciplina fornecida pela digitação estática. Flow é um projeto similar que fornece verificação de tipo estático para Javascript. Ambos os sistemas são altamente responsivos, programas paralelos que podem incorporar mudanças no código-fonte em tempo real. O Pfff é um conjunto de ferramentas para análise de código, visualizações e transformações de fontes de preservação de estilo, escritas em OCaml, mas suportando muitos idiomas.
Docker, Estados Unidos.
O Docker fornece uma suíte de tecnologia integrada que permite às equipes de desenvolvimento e operações de TI construir, enviar e executar aplicativos distribuídos em qualquer lugar. Seus aplicativos nativos para Mac e Windows, use o código OCaml tirado do projeto do sistema operacional da biblioteca MirageOS.
Bloomberg L. P., Estados Unidos.
A Bloomberg, líder mundial em informações e negócios de negócios e financeiros, dá aos decisores influentes uma vantagem crítica conectando-os a uma rede dinâmica de informações, pessoas e idéias. A Bloomberg emprega a OCaml em um aplicativo avançado de gerenciamento de risco de derivativos financeiros entregue através do seu serviço Bloomberg Professional.
Citrix, Reino Unido.
O Citrix usa o OCaml no XenServer, um sistema de virtualização de servidores de classe mundial. Nós também oferecemos uma variante de fonte aberta completa do XenServer chamada Xen Cloud Platform ou XCP. Acompanhe o desenvolvimento do OCaml no github / xen-org. Este trabalho foi originalmente apresentado por Anil Madhavapeddy no CUFP 2008. Veja seu resumo e slides.
Integração Estética, Reino Unido.
Integração Estética (AI) é uma empresa de tecnologia financeira baseada na Cidade de Londres. A tecnologia de verificação formal de patente pendente da AI está revolucionando a segurança, estabilidade e transparência dos mercados financeiros globais.
Ahrefs, Singapura.
A Ahrefs desenvolve armazenamento personalizado em escala de petabyte distribuído e executa um rastreador de internet para coletar o índice de toda a Web. Além disso, a empresa está criando vários serviços analíticos para usuários finais. OCaml é o idioma principal do backend Ahrefs, que atualmente está processando até 6 bilhões de páginas por dia. Ahrefs é uma equipe multinacional com raízes da Ucrânia e sede em Cingapura.
Museu Americano de História Natural, Estados Unidos.
O Departamento de Ciências Computacionais da AMNH vem usando o OCaml há quase uma década em seu pacote de software POY para inferência filogenética. Veja a página GitHub da AMNH para mais projetos.
ANSSI, França.
As missões principais da ANSSI são: detectar e reagir a ataques cibernéticos, prevenir ameaças, fornecer aconselhamento e apoio a entidades governamentais e operadores de infra-estrutura crítica e manter as empresas e o público em geral informados sobre ameaças à segurança da informação. Veja a página GitHub da ANSII para alguns de seus softwares OCaml.
Grupo Ashima, Estados Unidos.
O Grupo Ashima usa o OCaml para o raciocínio geométrico, a tradução de sombreadores GPU e servidores de alto desempenho. O sistema de tipo, compilador, ferramentas, comunidade e filosofia de design do OCaml tornam-no uma ferramenta extremamente poderosa e versátil para diversas tarefas de desenvolvimento de sistemas.
Seja Sport, França.
A missão do Sport é aumentar o valor que o esporte traz à nossa vida com o uso apropriado das inovações de mídia digital e social. Be Sport é um projeto 100% OCaml e OCsigen, alavancado como os únicos blocos de construção para desenvolver a plataforma.
CACAOWEB, Reino Unido e Hong Kong.
Cacaoweb é um desenvolvimento de uma plataforma de aplicação de um novo tipo. Ele é executado em cima da nossa rede peer-to-peer, que passa a ser uma das maiores do mundo. As capacidades da plataforma são diversas e variam de transmissão multimídia para comunicação social, armazenamento off-line ou sincronização de dados. Nós projetamos e implementamos lojas de dados massivamente distribuídas, linguagens de programação, sistemas de tempo de execução e estruturas de computação paralelas.
CEA, França.
A CEA é uma empresa estatal francesa, membro do Consórcio OCaml. Ele usa o OCaml principalmente para desenvolver uma plataforma dedicada à análise do código fonte do software C, chamado Frama-C.
CloudFounders, Bélgica.
O CloudFounders oferece soluções para a funcionalidade do Data Center. Eles usam a loja Arakoon chave / valor e escreveram um cliente OCaml para dispositivos Seagate Kinetic. O Open vStorage Backend também está escrito em OCaml.
Coherent Graphics Ltd, United Kindgom.
O Coherent Graphics é um desenvolvedor de ferramentas de servidor e software de desktop para processamento de documentos PDF. Usamos o OCaml como uma linguagem de alto nível de uso geral, escolhida por sua expressividade e velocidade.
Cryptosense, França.
Com sede em Paris, França, a Cryptosense cria software de análise de segurança com foco especial em sistemas criptográficos. Um spin-off do instituto para pesquisa em ciência da computação (Inria), fundadores da Cryptosense combinam mais de 40 anos de experiência em pesquisa e indústria. Cryptosense fornece suas soluções para um cliente internacional em particular nos setores financeiro, industrial e governamental.
Dassault Systèmes, França.
A Dassault Systèmes, a empresa 3DEXPERIENCE, fornece empresas e pessoas com universos virtuais para imaginar inovações sustentáveis.
Dernier Cri, França.
A Dernier Cri é uma empresa francesa com sede em Lille e Paris que usa programação funcional para desenvolver aplicações web e móveis. OCaml é usado principalmente para desenvolver ferramentas internas.
Digirati dba Hostnet, Brasil.
Digirati dba Hostnet é uma empresa de hospedagem na web. Usamos o OCaml principalmente para serviços de infraestrutura e programação de sistemas internos. Também contribuímos com a comunidade, liberando algumas bibliotecas OCaml de código aberto.
Soluções digitais, Uganda.
Programação geral, com ampla base e experiência em programação de telefonia móvel e desenvolvimento de aplicativos web.
Esper, Estados Unidos.
O software Esper ajuda assistentes. Ao fazê-lo, economizamos o tempo dos executivos. Queremos liderar o caminho para um mundo mais produtivo com um assistente para todos os profissionais e Esper para cada assistente. Nós imaginamos um futuro sem programação de e-mail sem fim, sem sobrecarga cognitiva, e onde a tecnologia nos serve, não nos distrai. Para atingir esses objetivos, estamos criando um suíte móvel / web que agiliza a comunicação entre assistentes e executivos, automatiza rote tarefas e compartilha informações.
Nosso backend da Web está escrito em OCaml e fornece uma API usada por nossos próprios clientes Web, Android e iOS.
Esterel Technologies, França.
A Esterel Technologies é um fornecedor líder de soluções críticas de desenvolvimento de sistemas e software para o setor aeroespacial, defesa, transporte ferroviário, nuclear e industrial e automotivo.
Fasoo, Coreia.
Fasoo usa OCaml para desenvolver uma ferramenta de análise estática.
Flying Frog Consultancy, United Kindgom.
Flying Frog Consultancy Ltd. consulta e escreve livros e software sobre o uso de OCaml no contexto da computação científica. OCaml se destaca no nicho de programas intrinsecamente complicados entre programas baseados em matriz em larga escala, escritos em linguagens como HPF e programas gráficos em pequena escala, escritos em linguagens como Mathematica.
ForAllSecure, Estados Unidos.
A missão da ForAllSecure é testar o software do mundo e fornecer informações acionáveis ​​para nossos clientes. Começamos com o Linux. Nossa missão no Linux é testar todos os programas em distribuições atuais, como Debian, Ubuntu e Red Hat. Com o tempo, iremos cobrir outras plataformas, como Mac, Windows e dispositivos móveis. Enquanto isso, prometemos fazer uma coisa bem.
Framtidsforum I & amp; M, Suécia.
O Framtidsforum I & amp; M vende o ExcelEverywhere, o que cria páginas da web que se parecem e funcionam da mesma forma que a sua planilha do MS Excel. O JavaScript é usado para o cálculo. Suporta 140 funções do Excel. Usado tipicamente para relatório de despesas, pesquisa, formulários de pedido, formulários de reserva, aplicação de emprego, consultor financeiro, ROI. Existem também versões que geram código ASP, ASP e JSP / Java. O compilador está escrito usando o OCaml.
Galois, Estados Unidos.
A Galois desenvolveu uma linguagem declarativa específica de domínio para algoritmos criptográficos. Um dos nossos compiladores de pesquisa está escrito em OCaml e faz uso muito extensivo do camlp4.
Incubaid, Bélgica.
A Incubaid desenvolveu a Arakoon, uma loja de valores-chave distribuída que garante a consistência acima de qualquer outra coisa. Criamos o Arakoon devido à falta de soluções existentes que atendem aos nossos requisitos, e está disponível como software de código aberto.
Issuu, Dinamarca.
Issuu é uma plataforma de publicação digital que oferece experiências de leitura excepcionais de revistas, catálogos e jornais. Em cada mês, Issuu atende mais de 6 bilhões de páginas e 60 milhões de usuários através de sua rede mundial. O OCaml é usado como parte dos sistemas do lado do servidor, plataformas e aplicativos da web. A equipe de backend é relativamente pequena e a simplicidade e escalabilidade de ambos os sistemas e processos são de vital importância.
Planejamento de TI, Japão.
Utilizamos o OCaml para algum tipo de sistemas empresariais (por exemplo, controle de produção, gerenciamento de risco de portfólio e serviços da web).
Jane Street, Estados Unidos.
Jane Street é uma empresa de comércio proprietária quantitativa que opera ao redor do horário e em todo o mundo. Eles trazem uma profunda compreensão dos mercados, uma abordagem científica e uma tecnologia inovadora para enfrentar o problema do comércio lucrativo nos mercados financeiros altamente competitivos do mundo. Jane Street é talvez o maior usuário comercial da OCaml, e atraiu uma equipe muito forte de programadores funcionais. Eles usam o OCaml para tudo, desde infra-estrutura de pesquisa até sistemas de negociação para operações e sistemas contábeis. Jane Street tem mais de 50 programadores OCaml e mais de um milhão de linhas de OCaml, alimentando uma plataforma tecnológica que troca bilhões de dólares todos os dias. Veja a página GitHub para o seu software de código aberto.
LexiFi, França.
A LexiFi é um fornecedor inovador de aplicações de software e tecnologia de infra-estrutura para a indústria de mercados de capitais. LexiFi Apropos é alimentado por um formalismo original para descrever contratos financeiros, resultado de um esforço de pesquisa e desenvolvimento de longo prazo.
Mashape, EUA.
O Mashape facilita a distribuição, a rentabilização, a gestão e o consumo de APIs em nuvem. A Mashape está construindo um mercado de classe mundial para APIs de nuvem, impulsionado por uma comunidade apaixonada de desenvolvedores de todo o mundo, bem como produtos de gerenciamento e análise de API corporativa. Usamos OCaml em nosso produto APIAnalytics - como parte de um proxy HTTP de missão crítica e leve.
Wolfram MathCore, Suécia.
Wolfram MathCore usa o OCaml para implementar o kernel SystemModeler. A principal função do kernel é traduzir modelos definidos na linguagem Modelica para o código de simulação executável. Isso envolve a análise e transformação do código da Modelica, processamento matemático de equações, geração de código do código de simulação C / C ++ e computação numérica de tempo de execução.
MEDIT, França.
O MEDIT desenvolve o SuMo, um sistema bioinformático avançado para a análise de estruturas proteicas 3D e a identificação de alvos de design de drogas. O SuMo está escrito inteiramente no OCaml e fornece interfaces para vários pacotes comerciais de modelagem molecular.
MLstate, França.
O MLstate é o criador da Opa: uma plataforma de desenvolvimento de código aberto. Consiste em uma nova linguagem de programação, um novo servidor web, um novo banco de dados e um novo mecanismo de execução distribuída, todos integrados de maneira a proporcionar uma ótima experiência para desenvolvedores web. Opa é conciso, simples, concorrente, dinamicamente seguro e seguro fora da caixa. Está escrito principalmente em OCaml e usa OCaml como um idioma intermediário para compilação.
Monoidismo, Reino Unido.
Monoidics desenvolve Infer, um analisador estático para verificação de software. O mecanismo de análise está inteiramente escrito em OCaml.
Mount Sinai, Estados Unidos.
O Hammer Lab no Mount Sinai desenvolve e usa a Ketrew para gerenciar fluxos de trabalho de bioinformática complexa. A Ketrew inclui um idioma específico do domínio incorporado para simplificar a especificação de fluxos de trabalho e um mecanismo para a execução de fluxos de trabalho. Ketrew pode ser executado como um aplicativo de linha de comando ou como um serviço.
Mr. Number, Estados Unidos.
Mr. Number começou como um arranque do Silicon Valley e desenvolveu o aplicativo Mr. Number para bloqueio de chamadas, mais tarde adquirido pela WhitePages. OCaml é usado no lado do servidor como a cola entre os vários componentes e serviços de terceiros.
MyLife, Estados Unidos.
A MyLife desenvolveu uma poderosa ferramenta de busca de pessoas que capacitará aqueles que precisam encontrar alguém, independentemente dos anos anteriores e da vida que foi construída no meio.
Narrow Gate Logic, Polônia.
Narrow Gate Logic é uma empresa que usa a linguagem OCaml em aplicativos comerciais e não comerciais.
OCamlPro, França.
O OCamlPro desenvolve e mantém um ambiente de desenvolvimento para a linguagem OCaml. Eles fornecem serviços para as empresas que decidem usar o OCaml. Entre esses serviços: capacitação, expertise, ferramentas e bibliotecas necessárias suporte a longo prazo, e desenvolvimentos específicos para seus domínios de aplicação.
Park e Eaton, Estados Unidos.
Park e Eaton é uma empresa de consultoria de marketing e software na Filadélfia. Oferecendo uma série de soluções, incluindo controle de qualidade e testes de segurança; redesenhar por escalabilidade e manutenção; e opções de hardware como sinalização digital, a Park e a Eaton são especializadas nos serviços de web e de desktop da OCaml.
Arena, Estados Unidos.
Arena ajuda as organizações a contratar pessoas certas. Nós fazemos isso aplicando grandes dados e análises preditivas ao processo de contratação. Isso resulta em menos volume de negócios para nossos clientes e menos discriminação para os indivíduos. Utilizamos OCaml para todo o nosso desenvolvimento de backend.
PRUDENT Technologies and Consulting, Inc., Estados Unidos.
A Prudent Consulting oferece soluções de TI para organizações grandes e médias, combinando experiência em tecnologia e experiência tecnológica para ajudar nossos clientes a alcançar objetivos de negócios com rapidez, agilidade e grande impacto.
Psellos, Estados Unidos.
Psellos é um pequeno grupo de cientistas da computação que ficaram intrigados com a idéia de codificar aplicativos iOS no OCaml. Funcionou melhor do que esperávamos (você pode comprar nossos aplicativos na iTunes App Store), e pelo menos uma outra empresa vende aplicativos criados com nossas ferramentas. Nosso compilador cruzado iOS mais recente é derivado do OCaml 4.00.0.
RunOrg, França.
O RunOrg fornece organizações sem fins lucrativos e organizações com uma intranet privada e um site público usando um modelo SaaS. O aplicativo está escrito inteiramente no OCaml por dois motivos: um é o desempenho, já que o OCaml gera binários rápidos e suporta padrões de otimização elegantes. O outro motivo é que a inferência flexível e poderosa do tipo compilação-tempo permite mudanças maciças na base do código sem causar nenhum erro, atuando efetivamente como um conjunto de testes de unidade gerado pelo compilador. O software é alimentado por uma estrutura web interna de código aberto, Ohm.
Sakhalin, Estados Unidos.
Sakhalin desenvolve aplicativos de gráficos marinhos para iPads e iPhones da Apple. As aplicações completas exibem gráficos marinhos, GPS e dados de sensores integrados, Sistema de identificação automática, dados meteorológicos, monitoramento de âncoras, etc. As aplicações possuem uma ampla gama de usuários, desde velejadores recreativos ocasionais até pilotos profissionais do rio / porto que embarcam em grandes cargas. Eles são gratuitos para baixar e tentar (com uma atualização paga para habilitar todos os recursos). Eles são escritos quase inteiramente em Ocaml com uma pequena quantidade de cola para interface com as APIs do IOS. Ocaml foi escolhido porque (1) permite o rápido desenvolvimento de software extremamente confiável e de alto desempenho, (2) é uma plataforma estável madura e (3) possui uma ampla gama de bibliotecas. Foi possível graças ao excelente trabalho realizado pela Psellos ao transportar o OCaml para a plataforma iOS da Apple. Sinta-se à vontade para entrar em contato com Sakhalin se tiver alguma dúvida sobre o uso do OCaml no iOS.
Shiro Games, França.
Shiro Games está desenvolvendo jogos usando Haxe, uma linguagem construída com um compilador escrito em OCaml.
Skylable, Reino Unido.
A missão da Skylable é criar uma solução de armazenamento de objeto rápida, robusta e econômica para a comunidade de Open Source e Empresas. Skylable usou OCaml para o seu produto LibreS3 - uma substituição de código aberto para o serviço Amazon S3, implementando (um subconjunto) da API S3 REST. Está escrito em um estilo monádico, atualmente usando Lwt e Ocsigenserver como implementações.
Sleekersoft P / L, Austrália.
Especializado em desenvolvimento de software de programação funcional, consulta e treinamento.
Solvuu, Estados Unidos.
O software da Solvuu permite aos usuários armazenar grandes e pequenos conjuntos de dados, compartilhar dados com colaboradores, executar algoritmos e fluxos de trabalho intensivos em computação e visualizar resultados. Seu foco inicial é sobre os dados de genômica, que tem implicações importantes para a saúde, agricultura e pesquisa fundamental. Praticamente toda a pilha de software da Solvuu é implementada no OCaml.
StackHut, Reino Unido.
StackHut está trabalhando para tornar os desenvolvedores mais fáceis ao cortar a quantidade de código que eles escrevem; queremos que os desenvolvedores passem mais tempo escrevendo a lógica central do negócio e menos tempo pensando em infraestrutura. A plataforma principal, o kit de ferramentas e o tempo de execução são escritos em OCaml, interface com recipientes Linux e também Erlang no lado distribuído.
Studio Associato 4Sigma, Itália.
4Sigma é uma empresa pequena que faz sites e algumas aplicações web interessantes. OCaml não é o idioma principal usado, mas é usado aqui e ali, particularmente em um pequeno servidor que é um componente chave de um serviço que oferecemos aos nossos clientes.
TrustInSoft, França.
TrustInSoft é uma empresa que muda as regras em segurança cibernética. O TrustInSoft é o editor de software da plataforma Frama-C de análise de software. Nossa única moto é simples: tornar os métodos formais acessíveis à maioria dos desenvolvedores de software.
Vector Tecidos, Holanda.
Vector Fabrics é uma empresa de software de alta tecnologia, desenvolvendo ferramentas para programação multicore integrada. Sua tecnologia e experiência está obtendo um reconhecimento generalizado na indústria como inovadora e única em sua capacidade de abordar plataformas heterogêneas multicêntricas de silício específicas de aplicativos. Devido à natureza avançada de suas ferramentas, a Vector Fabrics opera na vanguarda da próxima geração de plataformas embutidas para diversos mercados que vão desde supercomputadores até automotivo para celulares.
Aviso Legal.
A aparência do nome de uma empresa aqui não implica necessariamente o endosso por essa empresa da OCaml ou das descrições fornecidas aqui. Os representantes da empresa devem entrar em contato conosco para ter informações sobre sua empresa removidas, modificadas ou adicionadas.

Desenvolvedor de Software (Programação Funcional)
Jane Street é uma empresa proprietária de negociação quantitativa, focada principalmente em ações de negociação e derivativos de capital próprio. Utilizamos tecnologia inovadora, uma abordagem científica e uma compreensão profunda dos mercados para manter o sucesso em nosso campo altamente competitivo. Operamos ao redor do tempo e ao redor do mundo, empregando mais de 500 pessoas em escritórios em Nova York, Londres e Hong Kong.
Os mercados nos quais trocamos mudanças rapidamente, mas nossa abordagem intelectual muda mais rapidamente. Todos os dias, temos novos problemas para resolver e novas teorias a serem testadas. Nossa cultura empresarial é impulsionada por nossa talentosa equipe de comerciantes e programadores. Na Jane Street, não viemos trabalhar, querendo sair. Chegamos a trabalhar com entusiasmo para testar novas teorias, conversações provocadoras e talvez espreitadinhas em um jogo de ping-pong ou dois. Manter nossa cultura informal e nossos funcionários felizes é de suma importância para nós.
Estamos procurando contratar excelentes desenvolvedores de software com interesse na programação funcional. OCaml, uma linguagem de programação funcional digitada estaticamente com semelhanças com Haskell, Scheme, Erlang, F # e SML, é o nosso idioma de escolha. Nós temos a maior equipe de desenvolvedores da OCaml em qualquer configuração industrial, e provavelmente a maior base de código do OCaml do mundo. Usamos o OCaml para administrar todo o nosso negócio, apoiando tudo, desde pesquisa até administração de sistemas até sistemas de negociação. Se você está interessado em ver como a programação funcional se desenrola no mundo real, não há um lugar melhor.
A atmosfera é informal e intelectual. Há um foco na educação, e as pessoas aprendem sobre software e comércio, tanto através de aulas formais quanto no trabalho. O trabalho é desafiador, e você consegue ver o impacto prático de seus esforços em termos rápidos e dramáticos. Jane Street também é pequena o suficiente para que as pessoas tenham a liberdade de se envolver em muitas áreas diferentes do negócio. A compensação é altamente competitiva, e há muito espaço para o crescimento.
Você pode aprender mais sobre Jane Street e nossa tecnologia do nosso site principal, janestreet. Você também pode olhar para uma conversa dada na CMU sobre por que Jane Street usa programação funcional (ocaml. janestreet /? Q = node / 61) e nosso blog de programação (ocaml. janestreet).
Também temos amplos benefícios, incluindo:
90% de reembolso de livros para livros relacionados ao trabalho 90% de reembolso de taxa de matrícula para educação continuada Excelente seguro de saúde e odontologia com prémio zero Almoço gratuito entregue diariamente de uma seleção de restaurantes Café da manhã com café da manhã preparado e café fresco de Peet Um ginásio privado no local, novo York com serviço de toalha Cozinhas totalmente abastecidas com uma variedade de escolhas de lanches A empresa completa 401 (k) combina até 6% do salário, ganha imediatamente.

Aprendizado na Jane Street - Programação prática funcional e engenharia de software.
Esta é a segunda de duas postagens de blog na minha experiência de estágio do verão de 2018 na Jane Street, com foco no aspecto técnico do trabalho com o OCaml. Para minha experiência com a empresa, leia o primeiro. Eu não represento a empresa: pegue tudo o que eu digo com um grão de sal. Outros estagiários têm sua própria experiência única, que pode ser diferente da minha, minha memória reconstrutiva poderia dizer mentiras, talvez eu esteja racionalizando muito, etc., etc.
Eu gostei bastante da programação funcional no passado. Eu apenas escrevi alguns projetos significativos usando-os (principalmente F #, Scheme e Rust), mas todos eles estiveram entre minhas experiências de programação mais gratificantes e esclarecedoras.
No entanto, no grande esquema das coisas, isso não é obviamente uma coisa boa. Perl tem uma reputação de ser divertido de usar e escrever, mas produzindo código arcano, somente de gravação. As linguagens funcionais têm a reputação de tarefas complexas excessivamente complexas com idéias acadêmicas. Embora alguma dessas reputações possa ser merecida, minha experiência em trabalhar com a engenharia na Jane Street não foi assim.
Pelo contrário, o código de Jane Street não é apenas muito prático, mas provavelmente o mais claro que já tive o prazer de ler e trabalhar. Eu não sou grande na teoria dos tipos, então não será sobre como usar o OCaml para fazer o Clever Things ™. Em vez disso, vou compartilhar algum aspecto da engenharia de software que me causou uma impressão na Jane Street.
Na verdade, vamos começar com algo que nada tem a ver com o OCaml.
A revisão do código foi imensamente valiosa (parte 1: Ferro)
Eu pensei que as críticas de códigos que recebi na Jane Street eram sólidas, ajudaram-me a aprender muito bem o idioma e as convenções de codificação e ajudaram consistentemente a fazer grandes melhorias na arquitetura do meu código.
Há um elemento histórico para codificar as revisões em Jane Street. Devido à natureza de alto risco do negócio, as revisões de códigos historicamente foram altamente enfatizadas. Nos primeiros dias, os fundadores analisariam cada nova linha de código. No entanto, os desenvolvedores fazem mais do que apenas gastar mais tempo na revisão do código. O sistema que foi desenvolvido, Iron 1, também possui algumas inovações próprias.
Uma grande diferença entre Iron e outros sistemas populares de revisão de código (por exemplo, Github, Phabricator) é que as revisões de código estão escritas no texto. Ao invés de ter uma visualização na web onde você pode anexar comentários a linhas específicas de código, as revisões de código são adicionadas diretamente ao código na forma de comentários que começam com CR.
Uma vez que a revisão do código é endereçada, a etiqueta CR é alterada para XCR e o revisor original pode excluí-la se eles acharem que a preocupação foi endereçada, caso contrário, ela muda para CR.
Eu inicialmente senti que esse sistema era bastante primitivo, mas logo percebi que tinha algumas vantagens. Eu poderia facilmente classificar e listar todas as avaliações com base em seu status, como aqueles que não eram atendidos ou aqueles cujas mudanças esperavam a aprovação. Ao contrário dos comentários de Github, eles nunca se perderam. Github tem que descobrir onde anexar os comentários no código, mesmo em face do rebase e mescla, o que não é um problema para o Iron.
Outro aspecto que eu gostei é que, uma vez que as revisões de código são escritas editando o arquivo de origem, o revisor pode efetuar suas próprias alterações no código enquanto revisa. Isso evita que uma mudança urgente seja incorporada devido a algumas lágrimas. Em vez de esperar que o revisor repare essas nits e mande a alteração de volta para aprovação, o revisor pode consertar essas nits imediatamente. Existem também tipos de sugestões de melhoria que são difíceis de se comunicar em palavras. No entanto, eles podem ser comunicados apenas implementando-os e mostrando como é feito, o que este sistema permite que o crítico faça. Para o avaliado, isso também é ótimo para aprender. Ter minhas funções corrigidas para mim me ajudou a entrar na via da Jane Street, escrevendo o OCaml com muita rapidez.
Vale a pena pensar sobre as condições prévias necessárias para que esse sistema de revisão de código seja viável. Em particular, acho que exige que os engenheiros tenham muita confiança uns com os outros, sejam motivados para a auto-aperfeiçoamento e que tenham seus egos mantidos sob controle. Este sistema não funcionaria se as pessoas estivessem protegendo seu código.
Além de revisar o estilo de codificação, eu também descobri que recebi muitas avaliações profundas de alto nível sobre a estrutura do meu código. Em particular, senti que os revisores haviam lido e entendido meu código e, portanto, conseguiram comunicar problemas muito específicos que abordavam a raiz dos problemas.
Um monte de crédito obviamente é para os próprios revisores. Eu pensei que ambos os meus mentores eram super afiados e durante todo o meu estágio, entenderia muito rapidamente a fonte da minha confusão em vários problemas e teria respostas muito claras ou responderia com outra pergunta que me permitiu descobrir imediatamente a resposta.
Dito isto, também acredito que existem alguns aspectos do próprio OCaml que facilitaram boas revisões de código. Então, vamos para o OCaml agora, e algumas de minhas hipóteses sobre por que a programação funcional OCaml pode ser parte da causalidade.
Para o contexto, aqui está uma introdução de velocidade 100x para o OCaml (para realmente aprender algo sobre isso, o Real World OCaml não é apenas o melhor recurso OCaml, mas provavelmente um dos melhores livros de programação). No interesse de não fazer esta publicação do blog arrasar por muito tempo, a próxima parte deve assumir um pouco de experiência com linguagens de programação :(
... estaticamente digitado. Cada variável e cada função precisam ser resolvidas durante a compilação e tem um tipo.
... usa notação de seta para tipos. Por exemplo, a função do mapa tem tipo.
f :( 'a - & gt;' b) - & gt; 'uma lista - & gt; 'lista b. Isso é mais do que um detalhe trivial porque é a notação mais clara, mais compensa e compacta que ainda vi para comunicar as funções fornecidas por uma interface.
... tipo inferido. Não é necessário escrever explicitamente tipos, exceto em alguns pontos-chave. O compilador infere a maioria deles para você, economizando a necessidade de digitar uma grande quantidade de boilerplate.
... lixo coletado. Você não precisa ser explícito sobre a memória.
... comunica muita informação nos tipos através de ADTs. É muito claro quais são os estados possíveis do seu programa quando as funções retornam tipos como Result of string | Erro de NoServerFoundException. t | Tempo esgotado.
... tem um modelo de execução claro. Embora o OCaml seja razoavelmente de alto nível, possivelmente mais do que Java / C # e mais perto de Python, é fácil fazer uma estimativa bastante precisa sobre o que o código compila.
... não é puro, mas na maior parte pura na prática. O padrão é imutabilidade, mas você não precisa usá-lo quando não é conveniente (por exemplo, ao passar por uma tabela de hash).
... tem arquivos. ml para arquivos de código e. mli para interfaces. O arquivo de interface armazena tipos de funções e módulos (veja o exemplo).
A revisão do código foi imensamente valiosa (parte 2: sendo explícita)
Eu vim apreciar como o sistema de tipo forte de OCaml e os idiomas, expressos através de arquivos de interface, ajudam o código a revisar muito.
Revisar um grande conjunto de alterações para um grande recurso é difícil. Ler um grande diff é difícil 2. Compreendê-lo também é difícil, porque o crítico deve construir o mesmo modelo mental do programa que o codificador costumava escrever, exceto que as mudanças são apresentadas em um formato plano que mistura as idéias de alto nível com os detalhes de implementação. Os arquivos não são solicitados em ordem alfabética, e não em um formato lógico.
Nas empresas passadas em que trabalhei, às vezes eu me sentava com o revisor quando escrevi recursos grandes para orientá-las em minhas mudanças. Isso é útil para garantir que eles entendam a idéia de alto nível, e posso dizer-lhes que as mudanças são úteis para ler primeiro, quais são importantes e quais são refactores triviais. Quanto mais um crítico entender as mudanças, mais útil eles podem ser. No entanto, um passo a passo do código é verbal: um lapso de atenção do revisor e a informação desapareceu.
Se as idéias de alto nível fossem naturalmente visíveis no código, isso ajudaria os críticos imensamente. E isso é o que os arquivos de interface são ótimos. Em muitas situações, eles fornecem um resumo de alto nível das mudanças que sempre podem ser encaminhadas. Embora seja um pouco de trabalho extra para escrevê-los, mesmo o ato de escrevê-los tem benefícios. Incentiva o escritor a conceber melhor abstrações.
Mas os arquivos de interface são úteis somente se contiverem informações suficientes. Eu encontrei os seguintes recursos e idiomas da OCaml para ser realmente útil na transmissão de informações nas interfaces:
Immutability by default: If a function is pure, then all data dependencies of the function must be passed through the arguments. All inputs to the function are explicit and readable at a glance. There is also going to be a return value, which is going to communicate what the function changes/produces. OCaml isn’t pure so in theory, you can’t rely on knowing everything about a function. In practice, however, this isn’t a problem 3 . Heavy use of Algebraic Data Types: This puts a lot of information in the type of a function that the reviewer can immediately see. For example: compute_value_from_list: string list -> string option makes it clear that there is an edge case where the function may not return a result. get_file:
path:string -> (string, IOError) Result is a more explicit way of communicating failure cases than exceptions. apply_update: string list -> Update -> string list with Update declared earlier as type Update = Insert of string | Delete of int makes it easy to see at a glance what the possible updates can be, better than searching for all the possible subclasses of an Update abstract class (which can sometimes be difficult).
First-class lambdas used as arguments:
setup_listener: int Pipe ->
handler:(int -> unit) -> unit.
provides a little more information than the OOP equivalent.
void setup_listener(Pipe<int> pipe, IntegerEventHandler handler)
because fundamentally, the class IntegerEventHandler would exist solely to provide the method void handle(int i) , which the functional style communicates directly without needing to create an abstract class.
Basically, the reviewer can spend way less time building a mental model of interacting components when all the information needed is in the same place. The less scattered throughout files and lines of code as possible, the better.
Finding out how to do things was way easier than expected.
One concern with non-mainstream languages and tools (i. e. most functional languages) is that documentation is harder to find online, and it’s harder to figure out how to do things. Given that Jane Street uses a functional language whose use is not that prevalent, in addition to a lot of custom built in-house tools, I expected that finding information would at least be somewhat of an issue. And while there were situations where I wished I could Google something, those situations arose less often than I would have guessed.
It’s not that the Jane Street codebase is particularly well documented or commented. It’s quite average from my experience. However, the OCaml mli (interface) files come to our rescue once again. It’s a form of compiling documentation: it never goes out of date and is easier to access than opening an autogenerated doc (by using “navigate to definition”). They provide a lot of information to you, exactly like how they provide a lot of information to the reviewer. The lack of clutter makes it really easy to skim through the file and see all the available utilities in a file. This is helpful to discover your toolset really quickly, in contrast to a framework like Rails where all the utilities are scattered throughout examples in documentation files.
A nice thing about OCaml’s type system is that the type of functions end up feeling like nice building blocks that assemble nicely into each other 4 . I felt that once I knew what the blocks were, the way to arrange them was generally obvious. Which is probably a good thing. I think in the ideal world, it would always be obvious how to write the correct code without having to search for examples 5 . And while I don’t think any language or coding environment allows you to do that, I certainly felt I got reasonably close with OCaml.
If it compiles, it works.
The best feeling I get with coding in a strongly typed functional language is that when the code compiles, it tends just to work.
The process of programming looks something like [write code] → [compile] → [fix compile errors] → [test code] → [fix runtime errors or bugs].
Essentially, programming in OCaml moves the time spent on fixing mistakes found at runtime to fixing mistakes found at compile time. From a personal perspective, I love this since I fundamentally enjoy writing code, and find debugging to be a bit tedious. I often even save large coding tasks (e. g. refactors) to the parts of the day when I’m getting sleepy because I can stay awake and focused if I’m typing.
From a more general perspective, if you believe the notion that the earlier a bug is caught, the less costly it is to fix, then this is probably a good tradeoff. A useful metric people care about is iteration speed. People like dynamic languages because it allows them to iterate faster. Here, I’m arguing that OCaml can enable faster iteration speed than dynamic languages. There are cases where debugging fundamentally has to happen at runtime (e. g. UI programming, checking whether the visual output looks nice), where the goal should be to propagate the changes onto the screen as fast as possible. However, this is less true of say, server-side programming, where I think the goal should really be to reduce the length of the cycle taken to produce a working program . There, I would be more skeptical of using dynamic languages on the server side under the argument of iteration speed.
The benefits of “it compiles, it works” become especially apparent when it comes to being confident to refactor code. Eliminating the fear of introducing a regression reduces a significant amount of friction towards taking on refactoring tasks. This goes a long way towards fighting technical debt.
A static analysis is not a substitute to tests. Jane Street has plenty of tests and testing tools to cover a wide range of scenarios. In addition to unit and integration tests, they also have “unified tests/expect tests”. However, tests are also not a substitute for static analysis either. In my experience, they are expensive to write, which tends to lead to incomplete coverage. They introduce a lot of boilerplate and often essentially being an expensive type check that’s actually slower to run in large codebases than incremental compilation.
It’s hard to nail down exactly what about the language or the coding practices allowed things to ‘just work’. I can make some conjectures using some jargon, like immutability, referential transparency, algebraic data types, etc. But even if I were to elaborate, it wouldn’t communicate the feeling of how nice it is to have those things in a large codebase. It’s like VIM. You understand how it improves productivity only when you use it and feel the improvement. And some people won’t feel it. That’s ok - this blog post isn’t a technical essay or a research paper, just a recollection of my experiences.
The code was very easy to understand.
I thought that, with a few exceptions, the code at Jane Street could be understood both quickly and correctly. This is less trivial than it sounds.
The part about being understood quickly is something that everyone would agree is important and valuable, but often fails to be achieved in practice in many places.
Understandability is something that becomes important when code is complex. So first, it’s worth having a good understanding of the concept of complexity. The classic “no silver bullet” makes the distinction between essential complexity and accidental complexity. From the wikipedia definition:
Accidental complexity relates to problems which engineers create and can fix; for example, the details of writing and optimizing assembly code or the delays caused by batch processing. Essential complexity is caused by the problem to be solved, and nothing can remove it; if users want a program to do 30 different things, then those 30 things are essential and the program must do those 30 different things.
The key point is that accidental complexity can be fixed, but essential complexity can’t be reduced without reducing the scope of the problem the software is trying to solve. From the paper:
In most cases, the elements [software components] interact with each other in some nonlinear fashion, and the complexity of the whole increases much more than linearly. The complexity of software is an essential property, not an accidental one. Hence, descriptions of a software entity that abstract away its complexity often abstract away its essence.
I liked the Jane Street codebase because I felt that it was low on accidental complexity, and developers didn’t get scared by essential complexity.
It was low on accidental complexity which made the code relatively quick to read. This was helped because OCaml is very idiomatic. It’s a multi-paradigm language, and there are many ways to solve a problem. You can take an OOP approach or functional approach, a mutable approach or immutable approach. However, most of the time, there is one obvious way to do it , which is important in an environment where the number of developers is more than one. In contrast with Scala, which encourages every type of coding roughly uniformly. There are a lot of nice things about Scala, but a common complaint is that there are too many ways of doing things and the code is hard to understand as a result. OCaml is also very terse. There are very few extraneous keywords, class definitions that aren’t really essential to the problem. For example, Java and C# require every function to be a method inside a class. But sometimes, in the case of static methods, what you really want conceptually is just a function. The function is the essential part of the program, the class definition is an accident.
On the other hand, there are times where a lot of information is presented on one line, and understanding it takes a bit of time. But that should be expected if the information represents the program’s essential complexity. Consider:
There’s a lot of information in this type definition for a function, but they are all essential parts of starting an HTTP server that serves strings. The server needs an initial state. The server needs a way to handle HTTP requests, some of which may return an error instead of a string. Each request is asynchronous. Starting the HTTP server itself could fail and return an error, and starting the HTTP server needs to be asynchronous.
The part about being understood correctly is a criteria less often brought up, but in my opinion equally important.
Developers often aim to produce readable code, but I think that might not be the correct criteria to aim for. Readable code is psychologically comfortable and looks accessible, but will lead to mistakes if it is not understood correctly. For example, Ruby’s RSpecs aim to be read naturally like English. This looks nice but when you need to modify the specs, the order of execution of the bindings is not obvious, and it’s easy to trip yourself when things don’t behave how you’d expect.
Correct understanding should be the criteria to aim for. One needs to be careful if too much magic happens under the hood. Abstractions leak and the hardest bugs are often the ones a level below the level of abstraction you usually work in.
In that sense, OCaml is nice because despite having a fairly high level of abstraction, it’s easy to get a sense of what the code compiles to, and Real World OCaml does a really good job at documenting what you need to know about the runtime (the “Real World” part of the title isn’t just for show).
But it’s not a magic bullet.
That being said, OCaml, or functional programming, is not a magic bullet. If I claimed otherwise, you should probably call bullshit.
We had a two day event at Jane Street where we built a trading bot on a simulated exchange. Our goal was to get points by making a profit, and points would start counting as early as an hour into the contest, which emphasized speed. Almost nobody chose to use OCaml, Python was by far the majority language among both traders and developers. I also chose to use Python - I felt like I could get something running more quickly, since every minute counted. And we did indeed have our bot ready to trade as the “markets” opened. Of course, this carried risks: a coding mistake cost me and my teammate over an hour worth of points in just 5 minutes (not unlike what happened to Knight Capital actually). If I were to do this again, I would still probably pick Python, but it’s an interesting illustration of the tradeoffs.
The other problem is that one that always come up - as good as a language is by itself, there’s still the issue of ecosystem. Jane Street has open sourced a lot of its libraries, but a single company cannot create a whole ecosystem. There’s not an obvious option to quickly create a web server in OCaml for example. And as great as my coding experience was inside Jane Street, setting up that environment locally (with auto-compilation, go-to definitions, etc) is quite hard, even if the pieces are available. It’s definitely far too much friction for passerby to get started on a new project compared to most other languages.
Leitura adicional.
OCaml has a generational garbage collector with incremental collection for the large heap. Jane Street has worked on it a lot in order to minimize the length of GC pauses, especially on the tail end, given that they have a real-time system handling huge amounts of data (meaning it produces huge amounts of garbage). Whether this is advantageous to you depends a lot on your use case. However, the interesting implication is that OCaml could actually be one of the more viable options in applications where GC pauses are a problem (e. g. apps, games).
There’s no official engineering values, but these ramblings of one engineer do illustrate the engineering values decently well.
Or generally, read their blog. It has tons of good stuff, I promise.
Thanks to Bai Li, Corwin de Boor, Jason Xiong, Leila Clark, Manu Goyal, Saahil Mehta, Shida Li for comments & correções.
To read more about Iron, see https://blogs. janestreet/designing-a-code-review-tool-part-1/ https://blogs. janestreet/designing-a-code-review-tool-part-2-patches-or-diffs/ https://blogs. janestreet/patch-review-vs-diff-review-revisited/ https://blogs. janestreet/code-review-that-isnt-boring/ https://blogs. janestreet/scrutinizing-your-code-in-style/ https://blogs. janestreet/ironing-out-your-release-process/ ↩
A code reviewer must, in broad terms, go through the following steps:
Read the code Understand the code Find a better alternative if one exists Verbalize/communicate that alternative.
All of those steps are hard. It might not be obvious that reading the code is necessarily a hard step compared to understanding it, but it actually is, from a psychological perspective. Not everyone finds reading code very fun. Personally, my attention span when reading anything, code or not, is not very high. In cases where the information density is low (such as a lot of fairly straightforward business logic), my eyes start glazing over quite quickly, and my reading becomes increasingly superficial. I think this is not uncommon among developers. ↩
The lack of pureness isn’t a problem in practice because at Jane Street:
People are trained to write immutable code as much as possible. Therefore, when the function produces side effects, it is well-understood that it should be documented. A function with return type unit (void) is understood to have side effects, and generally functions with side effects do return unit . If a function that takes a mutable data structure as an argument it is understood that it might have side effects. For example, passing a hashtable throughout nested helper functions. Finally, in an internal codebase, either the function is simple enough that its implementation is trivial to infer and it can assumed that it won’t have side effects, or complicated enough that it’s not possible to communicate everything about the function in its type, and you’d take a look at its implementation to make sure to understand what it does. It should be very rare that you both used a function without taking a look at its implementation and assumed incorrectly that it was pure.
It’s a bit like playing with trigonometric identities. You have some start and want to go to some finish using some transformation rules. ↩
It’s a commonly accepted meme is that programming is about searching stuff on StackOverflow all the time. I also internalized it for the longest time because it’s correct in the sense that searching for things can be better than memorizing, which takes undue cognitive space. However, searching stuff on Google (or in a codebase) is not writing code. ↩

Ocaml trading system


The scope of the systems we build is large — billions of dollars worth of transactions flow through them every day — but the group behind them isn’t. That means that each person has the opportunity to make a substantial impact.
We organize our work into small, project-oriented teams, each with the independence and responsibility to make decisions that impact the future of the firm. That makes it easier to see how the business works from end to end, and how you can contribute.
Compartilhe conhecimento.
Jane Street is an incredible place to develop as an engineer. From low latency networking to compilers to systems design, you can find people with deep experience who are eager to teach you what they know. There’s also a collaborative environment with a culture of inquiry and teaching that encourages people to grow their capabilities. We know there’s still a lot for us to learn and are always looking for people who can help us fill in the gaps.
It’s also a great place to learn about the world’s financial markets. Technology is deeply tied to our business, which is why we spend a lot of effort making sure that new hires learn about all aspects of our role in the markets. You don’t need to know anything about trading to come work here, but if you do come, you’ll have the opportunity to learn.
Work functionally.
It’s no secret that we’re big believers in functional programming, and use OCaml, a statically typed functional language, as our primary development platform. Jane Street’s technology group is small by design, which means we need to maximize the productivity of each person we hire. We believe functional programming helps us do that. But it’s not about productivity alone: programming in a rich and expressive language like OCaml is just more fun .
At Jane Street, functional programming isn’t a tool we reserve for some special set of problems. From systems automation to trading systems, from monitoring tools to research code, we write everything that we can in OCaml. We think it’s a tool that works well across a wide spectrum.
We’re also happy to spend time and money on making it easier for the people here to get things done. This ranges from big projects, like the work we do on development tools ( e. g. Iron, our in-house code review and release management system, and Merlin, a tool for providing IDE-like features for OCaml), to little touches, like getting people whatever crazy keyboard will help them get their work done most comfortably.
Open source.
Like almost every technology operation, we rely on tons of open source software in our daily work. We also believe open source should be a two-way street. From committing patches to the Linux kernel to publicly releasing some of our most significant projects, we’re constantly looking for ways to share our work with the community. You can find a bunch of our libraries on Github, including:
An alternative to the OCaml standard library.
A sophisticated library for concurrent programming.
INCREMENTAL.
A library for constructing on-line computations.
All told, we’ve released hundreds of thousands of lines of code, with new packages coming out all the time. One of the privileges of working here is that your code can have a life both within and beyond the firm .
Several of our libraries are featured in O’Reilly’s Real World OCaml, co-authored by one of our own. We’ve also funded work on several open source projects, including Mercurial, the OCaml compiler, the OPAM package manager and several development tools for OCaml. We also founded OCaml Labs, a research lab at Cambridge University devoted to improving the language.

Комментариев нет:

Отправить комментарий