Несколько месяцев назад я упоминал о необычной вакансии в компании ПроСофт. Не так давно проскакивала информация о том, что вакансия еще не закрыта (что, на мой взгляд, не удивительно). И вот теперь продолжение истории: Сергей Зефиров aka thesz упомянул в своем блоге, что он работает уже в Parallel Scientific.
Не знаю точно, ушел ли он из ПроСофта или нет. Но если ушел, то очень интересно было бы со временем услышать, какова оказалась дальнейшая судьба тех хаскельных разработок, которые Зефиров вел в ПроСофте. Ведь если та работа держалась на нем, то найти замену для дальнейшего развития проекта (да еще на таких финансовых условиях) будет непросто даже в Москве. Хотя еще большой вопрос, была ли эта разработка mission critical для компании, или же это был просто исследовательский pet project (ну или proof-of-concept, если сохранять политкорректность).
В любом случае интересно, но вряд ли до меня такая информация когда-нибудь дойдет.
PS. Почему я затрагиваю эту тему. А потому, что меня, как паталогического велосипедостроителя, волнуют два аспекта. Первый: есть ли смысл для компаний, закладываться на экспериментальные разработки, которые делают уникальные харизматичные программисты? Второй: каковы границы моральной ответственности самого “гениального разработчика”, который “подсаживает” работодателя на свой велосипед?
Вот лично моя имха - дело ничуть не в технологиях. И на абсолютно стандартных широкораспространённых технологиях можно сделать что-то что будет никак не сопровождаемо и не поддерживаемо никем кроме человека который всё это написал (и обратное тоже верно, да). На самом деле куда важнее 2 другие вещи - умение человека работать в команде (просто удивительно насколько много программистов по разным причинам просто не хотят делиться своими знаниями) и желание/возможность компании-разработчика проекта следить за трак-фактором. А хаскель это будет или вижуал бейсик - это 15-я по важности причина попадания в ситуацию "человек уволился и замену ему найти не можем".
ОтветитьУдалитьДа, и вся моя имха никак thesz-у не относится - я просто не имею представления о что и как у него там было, да и не моё это вообщем-то дело.
@Left:
ОтветитьУдалитьСобственно, да. Не поспоришь.
Но вот чем хороши мейнстримовые технологии -- больший выбор. Т.е. среди 100 потенциальных кандидатов больше шансов найти того, кто продолжит разработку. Чем среди 3 таких.
Ну и еще один момент: когда делают проект на Java и он плохой унутрях, то об этом будут говорить все новые разработчики, которые входят в проект. Соответственно, есть хоть какая-то информация о качестве разработки. Если же проект на каком-то маргинальном языке и состав разработчиков долго не меняется, то это черный ящик. О качестве того, что внутри судить нельзя.
@Left:
ОтветитьУдалитьКроме того, как-то не хочется рассматривать совсем крайние случаи, как то:
- разработка полное дерьмо и не жизнеспособна без своего создателя;
- разработка просто суперская, с отличной архитектурой, с качественным и понятным кодом, с прекрасной документацией, к тому же является реализацией хорошо известных и тчательно описанных в большом количестве источников идей.
В жизни, как я понимаю, больше шансов встретить середину -- вполне себе нормальный код, какая-то документация, какие-то тесты, но львиная доля информации и идей находятся в головах основных разработчиков. И не из злого умысла, а потому, что нет условий (времени, бюджета, воли) довести все это до идеала.
> Но вот чем хороши мейнстримовые технологии -- больший выбор. Т.е. среди 100 потенциальных кандидатов больше шансов найти того, кто продолжит разработку. Чем среди 3 таких.
ОтветитьУдалитьДело в том что при достаточно большом проекте - проще взять достаточно толкового человека пусть даже не знакомого с той технологией на которой был написан проект. И такие ситуации - сплошь и рядом, люди начинают изучать проект и параллельно технологию (технологии). И ничего, справляются.
@Left:
ОтветитьУдалитьПод большим проектом понимается что: объем кода или количество совместно работающего над кодом людей?
Left зацепил правильный момент, но в целом я с ним не согласен
ОтветитьУдалитьнасчет технологий -- обычно есть 3 уровня:
1. то, что пишется идиоматично на данном языке; если оно написано неидиоматично -- получается быдлокод
пример: юнион с тайптегом вместо иерархии классов в с++ (и другие варианты "ооп на си")
2. то, что может быть написано на данном языке с проверкой компилятором, но чересчур сложно -- например, слишком сложные и неочевидные вычисления на шаблонах или на типах в хаскеле
3. то, что не может быть написано на данном языке с проверкой компилятором, и приходится расписывать подробно, что можно вызывать после чего, а что нельзя, и т.д.
п.3 на современных языках обычно большой, п.2 тоже хватает, п.1 это в общем-то может даже меньше половины случаев
так что если п.1 написан неидиоматично (что вряд ли в случае thesz), или в случае п.2 будет abuse языковых технологий (что может быть), то дело в технологиях
в чем Left прав -- так это в том, что п.1 может внезапно перейти в п.3
ОтветитьУдалитьпример: у нас объекты величиной 2-4-6 байт, мы ограничены в памяти, и просто не можем позволить 4-байтовый vtbl ptr у них
тогда нам приходится залезать в п.3, организуя свой vtbl ptr (а точнее type tag) из нескольких (скажем, 3) бит
теперь насчет моральной ответственности -- ничего такого вообще нет
ОтветитьУдалитья придерживаюсь мнения -- за все отвечает руководство
если оно не учло каких-то угроз (потеря жизнеспособности проекта из-за ухода ключевого разработчика), то оно и виновато
<vanga_mode> но скорее всего там выперли thesz-a вместе с хаскелем; т.е. ему поставили условие "либо находишь команду людей, согласных работать за 70 тыр. на том же языке что и ты, либо переходишь на шарп, либо увольняешься" -- отсюда понятно появление вакансии и ее открытость </vanga_mode>
гораздо интереснее обсудить моральную ответственно разработчика(-ов) языка... ой, я хотел сказать риски, связанные с тем, что разработчик
ОтветитьУдалить1. просто забьет на свой язык
2. выкатит мало совместимую новую версию, и забьет на старую
и еще одно <vanga_mode> а в новой компании thesz-a взяли только для того, чтобы посмотреть, что такое хаскель и хаскелисты </vanga_mode>
ОтветитьУдалитьДело в том, что с увеличением сложности проекта, сложность самого инструмента, как ключевого фактора, уменьшается, а знания о внутреннем устройстве продукта (как и что он делает) сильно возрастают в цене. В качестве примера могу привести случай из собственной практики: контора производит 2 типа оборудования и поставляет его со своим софтом (без софта оборудование бесполезно), софт делают 2 программиста по одному на каждый тип оборудования,
ОтветитьУдалитьсофт не маленький, программист сопровождающий более сложный софт ушёл, но за полгода до конца контракта предупредил фирму об уходе и успел часть знаний передать оставшемуся программисту. Остальные знания о системе программист получал опытным путём и, понятное дело, часть знаний о работе программы просто утеряна. Через полгода пришёл новичёк, он занимается тем софтом, что поменьше, а старожил тем, что побольше, оба изучают новое для себя, но один в слепую, а второй может получить хотя бы часть ответов на свои вопросы от коллеги. Новичку для въезда в проект понадобилось полгода, через год он уже уверенно резал и выкидывал мёртвый код, чтобы хоть как-то понять работу системы в целом, добавлял новый фичи по желанию заказчика и с ужасом представляя себе что будет, если старший программист решит не продлять контракт. В итоге, новичек через 3 года не стал продлять контракт и более мелкая софтина фактически осталась без поддержки и развития и одна линейка оборудования теперь просто груда железа. Старый программист полноценно не может её поддерживать, потому что у него свой код большой и сложный, а та софтина, которую он когда-то делал уже значительно изменилась, и для внесения туда правок ему надо значительно больше времени. А что будет, когда и он решит уйти?
Ну и несколько слов об инструментах... Оба софта написаны на Delphi6, качество кода отвратительное (если в коде написано black, то вероятнее всего речь идёт о белом цвете), IDE слабо помогает в нём разобраться и причесать его, GUI благодаря "легкости создания интерфейсов c помощью Delphi" очень трудно модифицировать (нередко бывает необходимо вручную переразместить несколько десятков элементов, чтобы добавить ещё один в нужное место формы), переход на новую версию IDE очень труден из-за наличия сторонних компонентов, которым нет замены, ну и отсутствию какого либо описания того, как должна работать система.
Ну и помимо этого при работе с железом надо помнить про устные предания о том, как железо себя ведёт и где легко нарваться на трудновоспроизводимую необъяснимую ошибку. Предания эти передаются от одного программиста к другому и никогда не документируются, потому что времени вот прямо сейчас на это нет, а вот как только, так сразу...
И вот после этого всего, хаскель (ну или другой "маргинальный" язык) воспринимается как возможность избавиться хотя бы от части проблем, сэкономить немного времени на сидение в отладчике (а без него понять как работает большая программа не Delphi невозможно) и написать хотя бы небольшое how-to во всей системе в целом и некоторым важным частям, я уж не буду вспоминать, что мало кто из дельфистов прользуется контролем версий - это тоже крайне маргинальный инструмент.
Нет никаких проблем с поддержкой чужого хаскельного кода кроме патологической нелюбви к хаскеллу.
ОтветитьУдалитьА так --- язык как язык. Ничего экзотического. Это не J и не Agda.
Предложение по выпиранию достаточно странное, учитывая, что иностранный стартап, который ориентируется на хаскелл и набирает удаленных сотрудников в наших краях в том числе появляется не так уж часто, и ВНЕЗАПНО thesz оказался именно в нём, когда он тут появился.
ОтветитьУдалить@имя:
ОтветитьУдалитья придерживаюсь мнения -- за все отвечает руководство
Спасибо, я понял.
риски, связанные с тем, что разработчик
Исходя из предыдущего утверждения, за это отвечает руководство. Следовательно, у разработчика есть моральное право и забить, и сделать несовместимую версию.
@daapp:
ОтветитьУдалитьСпасибо за развернутый комментарий. Мне знакома ситуация, когда команда маленькая, знания каждого участника суперважны и уход любого из них переводит проект если не в мертвое, то уж точно в законсервированное состояние. Когда возможен только мелкий баг-фиксинг, но нет речи о развитии.
И почему-то мне казалось, что в ПроСофте в той команде, где велась разработка на хаскелле именно такая ситуация.
@voidlizard:
ОтветитьУдалитьНет никаких проблем с поддержкой чужого хаскельного кода кроме патологической нелюбви к хаскеллу.
Так вот и интересно, сохранится ли такое же мнение в ПроСофте через год-полтора.
@Евгений Охотников
ОтветитьУдалить> Следовательно, у разработчика есть моральное право и забить, и сделать несовместимую версию.
я не понял, насчет какой несовместимой версии идет речь
если речь идет о несовместимой версии нового языка, то тут должны быть не эфемерные моральные принципы, а конкретные вещи:
1. помимо описания языка должно быть еще language design rationale
2. в language design rationale должна быть прописана цель минизации проблем или вообще отсутствия проблем перехода на новую, в чем-то несовместимую версию, и показано, какими архитектурными особенностями это достигается, и каким практическим образом предполагается к применению
я вообще достаточно близок к мнению, что хороший дизайн языка как раз и означает невозможность breaking changes
ОтветитьУдалитьи если так, то language design rationale должно быть как раз и объяснено, каким образом архитектура языка предотвращает breaking changes
ОтветитьУдалить@voidlizard
ОтветитьУдалитьок, примем как факт что я не ванга :-) и посмотрим на успехи нового стартапа, где работает thesz
@имя:
ОтветитьУдалитья не понял, насчет какой несовместимой версии идет речь
Я вот об этом: 2. выкатит мало совместимую новую версию, и забьет на старую
Если руководство дает разработчику добро и берет всю ответственность на себя, то разработчик уже может не думать о том, какие последствия будут от его деяний. "Я всего лишь солдат, я лишь выполнял приказы".
1. помимо описания языка должно быть еще language design rationale
Ага, ага. Фантастика.
2. в language design rationale должна быть прописана цель минизации проблем или вообще отсутствия проблем перехода на новую, в чем-то несовместимую версию, и показано, какими архитектурными особенностями это достигается, и каким практическим образом предполагается к применению
Совсем уж фантастика.
Можно с большей долей вероятности заменить "язык" на "фреймворк" или "тулкит", который некий продвинутый разработчик закладывает в основу какой-либо корпоративной разработки. Это может быть специализированная БД, система принятия решений, сильно оптимизированный графический движок и т.п.
@Евгений Охотников
ОтветитьУдалить> И почему-то мне казалось, что в ПроСофте в той команде, где велась разработка на хаскелле именно такая ситуация.
В таком случае, на каком именно языке был написан тот или иной софт, имеет третьестепенное значение. Ведь если контора захочет, то сможет получить профит от использования более надёжного инструмента, а не захочет - то клиенты сильно удивятся тому, что новая версия глючней старой (после переписывания глюки прут бурным потоком).
@daapp:
ОтветитьУдалитьВ таком случае, на каком именно языке был написан тот или иной софт, имеет третьестепенное значение.
Вот с этим не согласен. Если проект написан на языке, специалистов по которому найти тяжело, то перспективы его развития весьма туманны. К тому же компания всегда будет под страхом вопроса "А что мы будем делать, когда с трудом найденный специалист по редкому языку Х надумает от нас свалить". Тем более, что эти специалисты весьма резво сваливают.
Ну и конкретно о Хаскелле. Как раз вакансия для хаскеллистов в ПроСофте показала, что не хотят достойно платить за Хаскелль, а Хаскеллисты не демонстрируют достаточной степени лояльности, чтобы оставаться и делать начатый ими проект. И таких хаскеллистов даже в Москве, полагаю, нужно очень напряженно искать.
Так что, с точки зрения безопасности развития проекта, риски остаться с Хаскеллем в глубокой жопе выше, чем преимущества от разработки надежного софта на более высокоуровневом языке. Тем более, что вопрос степени требуемой надежности здесь еще нужно посмотреть.
@Евгений Охотников
ОтветитьУдалитькому фантастика, а кому нормальное явление
читаем, например, Ada 95 Rationale
это именно design rationale, а не описание языка -- вот цитатка:
As was discussed in II.11, Ada 83 had a serious violation of the contract model because ...... Ada 95 cures this flaw in the contract model by requiring that ...
@имя:
ОтветитьУдалитьНу ты сравнил теплое с мягким! Тебе часто приходилось видеть, чтобы какой-то pet-project в рамках небольшой компании имел объемный документ под названием "Design Rationale"? Из того, что мне приходилось делать самому и что доводилось видеть, было за счастье иметь хоть какое-то вменяемое описание того, что сделано в рамках pet-project-а. А уж точное и выверенное описание того, что хочет сделать автор, и в каком направлении это будет развиваться... О таком вообще никогда не слышал. Поэтому и сказал о фантастике.
rationale вовсе не обязан быть объемным -- проект начинался с какой-то точки -- скажем, аналоги есть, но в одном не устраивает то, а в другом не устраивает это -- вот оно и должно быть в rationale
ОтветитьУдалитьа вообще кто о чем, а я о языках :-) нефиг пользоваться новым языком, если автор не выкатил rationale помимо самого описания языка
ну и для pet-проектов громкое слово rationale обычно не применяют, но пишут
ОтветитьУдалить1. чем проект является
2. чем проект не является
3. еще бывает в faq-е разъясняют "а почему сделанно именно так"
у тебя в s-objectizer это могло бы быть объяснение почему агенты (или их классы, я уж нихрена не помню) именуются строками, а не типами, доступными компилятору
кстати, в с++11 содержимое литерала доступно компилятору, т.е. можно будет написать типа
auto a = "some"_agent;
тогда 's', 'o', 'm', 'e' будет доступно в шаблонах
@имя:
ОтветитьУдалитьну и для pet-проектов громкое слово rationale обычно не применяют, но пишут
Доморощенные проекты как раз и отличаются тем, что в них крайне редко можно встретить хоть что-нибудь из упомянутого тобой. И тому есть объективные причины: времени и ресурсов едва хватает чтобы сделать функционал, а уж чтобы задокументировать что-нибудь... Тут уж звезды должны очень удачно сложиться. Или pet project должен перейти из категории "доморощенного" в категорию "коммерческого".