среда, 29 февраля 2012 г.

На чем писать Ынтерпрайз проекты?

Немного грубого троллинга на утро :)

Давайте представим, что мы с вами собираемся начать крупный и серьезный Ынтерпрайз проект. И перед нами встает вопрос выбора основного языка (понятно, если у нас есть rich client нам понадобится Javascript / Flash в том или ином виде, для БД нам почти наверняка понадобится SQL, вероятнее всего с его процедурными расширениями и т.д.,  но речь об основном языке).

Википедия подсказывает, что языков программирования нынче развелось много - тысячи их. Но что можно использовать?

  • Прежде всего, отбросим unmanaged языки. Писать Ынтерпрайз софт в 2012 году на С или С++, возиться с указателями и ручным управлением памятью, закрашивать свежую седину после очередного хитрого бага вызванного разничной реализации того или иного поведения в разных версиях компилятора или чем-то подобным... Не тянет.  Будь это обособленная железка типа игровой консоли или PC для игр, будь это системные утилиты или что-то подобное, где совершенно критично выжать 99% возможного из доступной аппаратной конфигурации - да, один этот аргумент перевесил бы все остальные. Но в Ынтепрайз проекте я выжму 85%, а потом подбавлю серверов в кластер. Седобородые археологи и геронтофилы, прощу прощения, с глубоким уважением к вам... на выход.
  • Далее, отбросим динамические языки, такие, как Python, Ruby и им подобные. Даже не принимая во внимание скорость их выполнения (будем считать, что зрелые современные динамические языки имеют в той или иной степени развитый JIT), писать на них крупные проекты затруднительно именно из-за их динамической природы. Поддержка со стороны IDE (рефакторинги, статический анализ и миллион мелочей, из-за которых мы выбираем IndelliJ IDEA, а не windows notepad) существенно хуже, чем для языков с простой статической системой типов и простой строгой объектной моделью. Ряд вещей, концептуально крутых, может совершенно убивать саму возможность нормальной поддержки языка со стороны IDE - например, метаобъектный протокол. За исключением Kotlin (на F# близко не смотрел, возможно, там есть?), пока что я не видел, например, комбинаций языков и сред разработки, в которых поддерживалась бы полноценно умное автодополнение, подсветка и прочее внутри функциональных литералов (лямбда функций) в коде. В результате, там, где в языке с простой статической типизацией ошибки находятся фоновым процессом компиляции в IDE, в динамических языках надо писать unit test. Только не говорите мне, что писать их все равно нужно всегда и везде :) Сторонники динамических языков, аджайла, meet-up-ов.. Вы умные и часто прикольные, но сегодня не ваша ночь.
  • Отбросим C#, F# и группу языков, имеющих основные реализации на платформе .NET. Я не слишком верю в Mono и то, что это полноценный эквивалент для Microfost .NET под Windows, а идея писать Ынтепрайз софт, работающий только под Windows, мне представляется странной. Дотнетчики, я сам считаю эту платформу очень мощной, а C# - развивающимся, вполне продуманным, современным и мощным языком, но..увы-увы. До лучших дней.
  • Отбросим академические функциональные языки, языки, используемые для обкатки разных концепций в теории систем типов и новых парадигм, языки, используемые редкими исследователями-энтузиастами в университетах, языки, по которым нереально найти в проект 20 человек за сколько-нибудь разумное время. Отбросим с затаенным сожалением. Отбросим Haskell, OCaml, Erlang, Lisp...Покойся с миром, славный МакКарти, твои труды не забыты и еще сослужат добрую службу.. но не нам и не сегодня :(.
  • Отбросим языки, на которые просто писать нормальный поддерживаемый и понятный код нормальному человеку трудно. Перловики, просто бесшумно спрячьтесь под стулья.
И что остается? Правильно, Java.

BO-OO-O-OO-O-R-I-I-I-NG!!!

И вот именно поэтому, принимая решения о том, какой язык использовать в подсистеме крупного проекта, я посматриваю на языки на платформе JVM.
  • Groovy, который мы уже используем, и, надеюсь, будем использовать все больше и больше. 
  • Scala, ты загадочна, очаровательна и сложновата...Но в некоторых случаях пойдет. Ты все-же, приятнее Haskell-a :)
  • Closure? Lisp, я знаю, ты бессмертен, посмотрим, получится ли у этого твоего потомка взлететь.
  • Kotlin? Андрей Бреслав и прочие, ребята, вы делаете язык, который пофиксит две критические проблемы Groovy - более динамическая, чем статическая типизация типизация и, частично как следствие этого, плохая поддержка со стороны IDE. Получится у вас - повешу вашу фотку над рабочим столом.
  • Есть еще немало славных языков в этом семействе - Ceylon, Fantom и прочие. Каждый из них нелеп и крив  по своему, но у каждого есть какая-то изюминка.
Вот на них я и гляжу с некоторой надеждой :)

36 комментариев:

  1. Пока не готов Kotlin, многообещающе выглядит xtend: http://www.eclipse.org/xtend/documentation/index.html#Introduction

    Все руки не доходят попробовать ...

    ОтветитьУдалить
    Ответы
    1. eXtend необычен в том смысле, что он транслируется на в JVM bytecode, а в Java source code. У меня это вызывает ряд вопросов в плане процесса разработки..Мы пишем классы только на xTend, и никогда не трогаем *.java файлы руками? Надо ли будет в них что-то подправлять? Поддерживает ли это все прямые инъекции кода, как, например, JAXB code generation.

      Удалить
  2. Так, что-то мне не всё понятно в заключении. Разве к Groovy не относится всё то что ты написал про динамические языки?

    ОтветитьУдалить
    Ответы
    1. Многое относится. Поддержка со стороны IDE, например, существенно хуже, чем для Java. Но меня делают оптимистичным в его отношении несколько моментов:

      - отличная совместимость с Java (буквально drop-in, т.е. любой Java класс можно выкинуть и переписать на Groovy - будет работать, включая встраивание в иерархию наследования в любом месте и прочее).
      - объектная модель, ограниченная в некоторой степени JVM.
      - усилия, предпринимаемые последнее время для усиления системы типов и типобезопасности (реализация опциональной типизации).

      Надо, наверное, чуть подробнее рассказать.

      Удалить
    2. Спасибо за ответ. Подробности были бы хороши.
      На одном проекте использовали Groovy/Grails. Неоднозначное впечатление оставил. Слишком много вольностей в синтаксисе. Один факт, что .java можно переименовать в .groovy и всё заработает - просто ад.

      Удалить
  3. А Delphi, который и без указателей и уже 64-битный и может комплироваться под linux - FreePascal ?

    ОтветитьУдалить
    Ответы
    1. Если честно, даже не рассматривал его всерьез..Он же мертв? :)

      Какие IDE его поддерживают? Современные библиотеки? Комьюнити разработчиков, пишущих на нем?

      Я думал, щас программисты на нем нужны только в основном для поддержки старых систем, которые переписывать нерационально/слишком дорого на что-то типа С#.

      Удалить
    2. А web как же?

      Удалить
  4. Анонимный1 марта 2012 г., 6:35

    Что за быдляцкий подход к программированию? Автор огорчает ущербностью своего мышления и своей тупостью.

    ОтветитьУдалить
    Ответы
    1. Глубокое замечание. А по существу? Я только рад хорошей дискуссии.

      Удалить
    2. Анонимный1 марта 2012 г., 8:48

      Пишем Enterprise на C++ 7 лет, на javascript 2ой год. Вывод: вы просто не умеете их готовить

      Удалить
    3. Про Javascript не надо, я его специально выделил в своем посте, для client-side он подходит - потому что больше ничего хорошего нет. Если же вы используете его на сервере - это гм, я считаю тем еще извращением.

      Про 7 лет на С++ - верю, ну и что из этого? А я вам найду людей, пишуших 10 лет на перле, которые научились в нем разбираться, освоили контроль версией, стили читабельного кодирования на перле, ну и что это докажет?
      Вон тот же Яндекс имеет части своих сервисов написанных на перле, если не сильно ошибаюсь. При моем уважении к яндексу - это просто атавизм, написанный кусок, который работает -не трогай. Это

      Писать на С++ безусловно, можно. Но в 2012 году есть лучшие варианты. Вы утверждаете, что писать писать энтерпрайз софт на С++ ничем не хуже, чем писать его на Java? Аргументы? :)

      Удалить
    4. У меня другое мнение. Язык-то да, ява. А процессор?
      С 2000 г. железки стали многократно мощнее, а распознавания голоса и изображения нет. Дело в том, что спецы говорят, что х86 заточен на мультимедиа, а мне кажется, что это арифмометр с зачатками работы с массивами. Вот вчера прочитал, что многоловый х86 имеет не раздельные кеши , то есть разницы между i3-i5-i7 нету никакой, кроме частоты, а поскольку память всё равно DDR3, нет смысла покупать i7 никакого. То есть язык - не главное.
      Вот этого послушайте, профессор из Питера, спец по Ынтерпрайзу, делал прогу для Чикагской биржи:
      http://www.lektorium.tv/lecture/?id=14257
      И ещё. Не пишите, ради Бога, постов на английском. Балмер же сказал, там уже умных не осталось, уехали из СНГ только знатоки английского и их родственники, поэтому даже в Микрософт не может набрать умных.

      Удалить
    5. Про процессоры - ерунда полная. Про английский - наоборот, планирую писать больше постов на английском.

      Удалить
    6. А можно подробнее про процессоры, что конкретно сказал я неверно, если вам не затруднит.

      Удалить
    7. Во первых, я правильно понял, что вы имели в виду, что разницы между i7 и i3 нет? Нет где, в приложениях какого типа? И, главное, как из того предположения, что разницы между i-3 и i-7 нет, следует, что язык - не главное?

      В Enterprise мы обычно весьма далеки от bare metal. Для enterprise-платформ обычно важна не максимальная производительность на отдельной железке, а совсем другие вещи.

      Удалить
    8. Уважаемый Михаил, а вы видео смотрели по моей ссылке? Там именно про Ынтерпрайз самый, что ни на есть - обработка данных с бирж. И, спецы говорят, самое узкое место - передача из памяти в проц и наоборот. Внутренние кеши проца загружаясь из медленной памяти всё и тормозят. В этом плане разница i3-i5-i7 несущественна.То же можно сказать про обработку видео. А шина - 64 бита. Поэтому встает вопрос о чём-то типа SATA для связи RAM с процами. Такая SATA-RAM может работать и на частоте 64 ГГц, а может и 640 ГГц. То есть сейчас идёт перелом, будут скоро новые архитектуры в процах. В такой обстановке java позволит легче переходить с проца на проц.
      Все классические языки заточены на работу с int-long-float-double, то есть с бухгалтерскими данными. А даже биржам давно надо работать со структурами, которые не помещаются в кеше x86, а значит, для ускорения обработки приходится распиливать такие структуры по ядрам, что не есть перфоменс хайвей. Мало того, выходит не годится ни кластер серверов, ни многопроцевая плата. Вот нужно что-то типа КУДы, но опять, не 64 разрядное, а с переменной разрядностью. Ну и как это всё писать на стандартных языках?
      Вобщем, на носу перелом в IT. Вот я и думаю, что настал момент смены парадигм,а возможно, и первенства в отрасли.

      Удалить
  5. Почему считаете, что энтерпрайз на "чисто windows"-платформе в связке с .NET-м - это неправильно ?!

    ОтветитьУдалить
    Ответы
    1. .NET среди своих многочисленных преимуществ имеет интеграцию с Windows. Но писать энтерпрайз решения, которые нельзя запустить надежно на юниксе - мне эта идея кажется ненадежной.

      Крупные БД (кроме MSSQL, конечно) - Oracle, DB2, Postgres, MySQL etc, отлично работают на Linux разнообразии юниксов (HP-UX, AIX, Solaris), так же, если вы полюбопытствуете, например, банковской и телекомовской сферами, то, например, на украине, телекомы сидят на связке Oracle + Solaris, банки - на связке DB2 + AIX.

      Да, есть конечно нагруженные проекты, использующие технологии Microsoft - те же одноклассиники, StackOverflow и некоторые другие, есть крупные и нагруженные деплойменты MSSQL в финансовых компаниях и прочее.

      При всем при том, я не считаю что Windows - лидирующая серверная OC. И я говорю, что если вы ставите продукты, например, IBM, то вы можете выбирать OS для нее. Но выбирать технологии, которые могут быть нормально запущены только на Windows, для крупного энтерпрайз проекта я бы не стал.

      У нас, например, большинство demo/QA/UAT сред хостятся на Win 2003/2008 в виртуалках - в том числе для того, чтобы сотрудникам-нелинуксоидам было удобнее с ними работать. Но весь продакшн - на Linux.

      Удалить
    2. Я вот понять не могу эту тягу к "юниксу". Можете сказать что изменилось, по большому счету с 70-х? То что банки, к примеру сидят на старье, понять можно (как пример - болезненный переход на чиповые карты). Но зачем с этого брать пример?

      В чем выгода использования "юникса"? При всем при том по деньгам все дороже - железо, софт, поддержка. Единственное, что приходит в голову, это сэкономить, поставив Linux. Но тут проблем столько, реально нужно брать дистрибутив
      с поддержкой. Тогда в чем экономия?

      На мой личный взгляд решения которые предлагает Oracle выглядат как зоопарк, по сравнению с тем что предлагает MS.

      Удалить
    3. Наш usecase - у нас ряд demo/QA/UAT environments работают на windows, таким образом люди, у которые нет большого опыта с юниксом, могут работать с ними, коннектится по Win RDP, расшаривать папки и копировать через них файлы, брать файлы через обычную виндовую шару и прочее, использовать привычные инструменты, к которыми они привыкли в windows.

      С другой стороны, на продакшене у нас стоят сервера на линуксе (GentOS, кажется), по моему отдельной поддержки нет, но все нормально идет.

      Некоторые другие моменты, чисто технические, но тем не менее - в 32-битной винде вы не можете задать больше 2гб памяти процессу, как следствие, из-за особенностей маппинга адресов (по какому виртуальному адресу грузитятся какие exe-шники в память процесса. На линуксе или на солярисе на 32 битной машине можно использовать 3.5 Гб памяти под процесс, насколько я помню.

      Удалить
    4. в 2012-м - 32-битные сервера. мдааа

      Удалить
    5. Ага..А еще в 2012 - кое где есть Java 1.5 (а кое-где и 1.4!!), JBoss 4.3, EJB 2.1, Oracle 10 и прочее, да. Такова жизнь :)

      Удалить
    6. кстати тут интересная картика по долям операционных систем на суперкомпьютерах
      http://www.rzhevskiy.info/journal/dima/entry/operating_systems_used_on_top
      Виндуса там 0.4 процента

      Удалить
    7. Наверное, потому что Microsoft, во-первых, крайне убого функционально и по производительности, во-вторых, крайне плохо масштабируется, в-третьих, нелепо дорого.

      Удалить
    8. Сдается мне, вы ругатее майкрософт за компанию. С чего майкрософт стало вдруг дорого? По сравнению с корпоративным юниксом?

      Удалить
  6. гы-ы:
    - долгий цикл поддержки
    - отличная обратная совместимость: все новые версии обратно совместимы вплоть до java 1.0.2 (да, это камень в сторону .NET)
    - полная кроссплатформенность: Windows, Linux, BSD, Solaris, AIX, канувшем в Лету Irix, HP-UX, QNX, OS/2, а также совсем безумные реализации типа en.w:NanoVM для микроконтроллеров — подо все есть совместимая реализация JDK, причем ПРАВИЛЬНО НАПИСАННАЯ программа будет под всем этим работать одинаково успешно.

    ОтветитьУдалить
    Ответы
    1. Это копипаст откуда-то? Вы с этим мнением не согласны?

      Удалить
  7. Пишите на ABAP в SAP R/3, там есть всё. :) Особенно отладка хорошо организована по сравнению с Java. Хотя, может и заблуждаюсь, IndelliJ IDEA пока в живую не видел, но думаю там нельзя просто где хочешь и когда хочешь взять и включить отладку и посмотреть что твориться в любом приложении.
    Вообще в Ынтерпрайз главное хорошо продуманная система, без системы на любом языке и на любой платформе можно такое сваять...
    Взять тот же SAP Portal - Java, но это такое ужасное нагромождение технологий и подходов к разработке...

    ОтветитьУдалить
    Ответы
    1. Вы б ещё 1С вспомнили.

      Удалить
  8. Хм, Java и SAP это совершенно разного типа платформы, и далеко не каждую задачу можно и нужно решать в SAP. SAP гораздо более заточенный под конкретные бизнесы. Кроме того, вы не можете конкурировать с SAP, если пишете поверх его платформы :)

    В яве можно подключить дебаггером к любой JVM, запущенной в дебаг режиме, и посмотреть что происходит, отлаживать по шагам и прочее.

    ОтветитьУдалить
  9. Erlang очень хорош. По-настоящему хорош. Но, увы, пока нет нормального способа работать с OracleDB. Java же убога своим этим расчётом на common sence, все эти нелепые издержки ООП сейчас уже просто атавизм. Scala же представляется типичным таким седлом для коровы, тщетной попыткой отмыть объектного кобеля.

    ОтветитьУдалить
  10. FireMonkey из ХЕ3. Вот будущее

    ОтветитьУдалить
  11. Этот комментарий был удален автором.

    ОтветитьУдалить
  12. "Kotlin? ... Получится у вас - повешу вашу фотку над рабочим столом." у них, по-видимому, получилось)))

    ОтветитьУдалить