IT>Если не ошибаюсь там был простенький толи магазинчик, толи mail клиент. И его потом не смогла поднять профессиональная команда разработчиков, чтобы его развивать и поддерживать. Не помогла ни подготовка, ни переподготовка. Дело не в ней.

Как раз в ней и дело. Профессионализм разработчиков состоит в том, чтобы уметь прочитать код, а потом изменить (или вовсе выкинуть за ненужностью — это уже высший пилотаж). Но этому, увы, не учат — даже на собеседованиях вопрос ставится как "напишите мне код, который будет ..."

IT>Лямбда-самцы действительно способны писать на FP шедевральные вещи, которые нам, простым селянам не доступны в силу нашего скудоумия. Но FP здесь лишь катализатор, очень мощный, но не критичный.

Само по себе функциональное программирование может и не быть критичным. Но все то, что дает подход, и делает критичной разницу.
E = mc^2, Errors = More (Code ^ 2).
Чем больше букв, тем больше ошибок. Тем сложнее тестировать и развивать. Особенно в те времена, когда инструментарий для других языков тоже отсутствовал. Это сейчас можно решить кучу проблем дизайна того же питона с помощью мириад утилит — все эти линтеры, форматтеры, CI и CD. В 90х (да и в 2000х) этот инструментарий был малодоступен (и неразвит). Поэтому были особенно ценны свойства самого языка — лаконичность, выразительность.

IT>В результате получилось — слепок "ментальной" модели с прилепленными сбоку плохо совместимыми фичами и возможно попытками всё это заархитектурить. Помножим всё это на своеобразность выбранного инструмента и получаем абслютно бесполезный в плане развития продукт.

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

Так и есть. Команде профессионалов скомандовали — "вот вам 100500 индусов, напилите побольше фич". Традиционный подход "эффективного менеджмента", когда для решения любой проблемы нужно просто добавить людей. Который попросту не работает (вне зависимости от инструмента, просто потому, что хорошие продукты могут сделать только маленькие команды сильных инженеров).

Внезапно, это не сработало нигде и ни у кого. Собственно говоря, и не должно было работать. Основной задачей покупки было устранить возможную конкуренцию, а вовсе не продукт развивать.

Здравствуйте, SkyDance, Вы писали:

SD>Так и есть. Команде профессионалов скомандовали — "вот вам 100500 индусов, напилите побольше фич". Традиционный подход "эффективного менеджмента", когда для решения любой проблемы нужно просто добавить людей. Который попросту не работает (вне зависимости от инструмента, просто потому, что хорошие продукты могут сделать только маленькие команды сильных инженеров).

Почему только? В любом продукте есть масса работы для инженеров любого уровня. А маленькая команда сильных инженеров — это, во-первых, дорого, во-вторых, рискованно. Так считают современные манагеры.

Здравствуйте, Ziaw, Вы писали:

Z>Откуда такая уверенность? Лично я экономил на стэке и архитектуре, которую можно было дешево реализовать только в нем, в разы. Силами очень небольшой команды за счет профессионализма и инструмента.

Потому, что бОльшая часть времени в разработке уходит не на код, а на изучение домена, уточнение требований, проектирование, планирование, согласование, тестирование, настройку окружения, инфраструктуры, траблшутинг, багфикс, отладку, документирование итд итд.

Отсюда ясно, что другая команда имея такое же количество людей/опыта в той же области, но специализируясь на другом языке, даст результат за сравнимое время. Может чуть быстрее, может чуть медленнее.
На сам код у нормальных людей уходит 5-10 процентов времени. Потому сэкономить больше этих 5-10% ну никак не выйдет.

Другие, например, например, потратят на проектирование вдвое больше, в итоге на код уйдет больше времени, но багфикса, траблушинга, итд может оказаться много меньше.

Z>А профи (те, кто доводит до пользователя непростые проекты с хорошим соотношением цена/качество), которые выбрали бы неудобный для решения задачи стек

Сравнивать нужно яблоки с яблоками — например, две команды с примерно одинаковым опытом но специализируются на разныз технологических стеках, абы эти стеки под задачу подходили.

Здравствуйте, SkyDance, Вы писали:

P>>Я шота более чем уверен, выбери вместо лиспа другой высокоуровневый языки, типа питона или что навроде, результат был бы не хуже.

SD>Уверен, что результат был бы хуже.
SD>Потому что им пришлось бы вместо решания задачи воевать с инструментом (языком), а также со своим нежеланием преодолевать кривизну оного инструмента.
SD>Второе зачастую важнее, чем первое — если инструмент нравится, то и дело с ним спорится.

Вот вот, сам себе противоречишь. Что мешает сравнить две команды с одинаковым опытом, но предпочитающих разные стеки?

Здравствуйте, Ziaw, Вы писали:

Z>Откуда такая уверенность? Лично я экономил на стэке и архитектуре, которую можно было дешево реализовать только в нем, в разы. Силами очень небольшой команды за счет профессионализма и инструмента.
Z>А профи (те, кто доводит до пользователя непростые проекты с хорошим соотношением цена/качество), которые выбрали бы неудобный для решения задачи стек "типа питона" и терпеливо жрали бы долгое время этот кактус, мне не встречались. Обычно они понимают, что и зачем выбрали, а не действуют по принципу — мы крутые машинистки и на пэхапе наклепаем.
Ага, вот типичная машинистка на пэхапе. И до сих пор используют, переписывать не пришлось, в отличие от этих ваших лиспов.

IT>Почему только? В любом продукте есть масса работы для инженеров любого уровня. А маленькая команда сильных инженеров — это, во-первых, дорого, во-вторых, рискованно. Так считают современные манагеры.

Все правильно написал.

Команду нужно сделать большой и слабой (это будет еще дороже, но уже без риска случайно сделать хороший продукт — у большой и слабой команды это невозможно).
Тогда современные манагеры будут "важными управленцами". Ведь манагер 1000 человек — это шибко круче, чем манагер у 40.

P>Вот вот, сам себе противоречишь. Что мешает сравнить две команды с одинаковым опытом, но предпочитающих разные стеки?

В чем именно противоречие?

Мне сложно представить две команды с одинаковым опытом. Если бы опыт был в самом деле одинаков, предпочтения, вероятно, тоже сходились бы.

·>Ага, вот типичная машинистка на пэхапе. И до сих пор используют, переписывать не пришлось, в отличие от этих ваших лиспов.

Э-э-э.
Скажу так, он того пэхапе что был пэхапе там, пожалуй, не осталось ровным счетом ничего. Более того, PHP как язык не поддерживается вообще.

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

Здравствуйте, IT, Вы писали:

IT>Если не ошибаюсь там был простенький толи магазинчик, толи mail клиент. И его потом не смогла поднять профессиональная команда разработчиков, чтобы его развивать и поддерживать. Не помогла ни подготовка, ни переподготовка. Дело не в ней. Лямбда-самцы действительно способны писать на FP шедевральные вещи, которые нам, простым селянам не доступны в силу нашего скудоумия. Но FP здесь лишь катализатор, очень мощный, но не критичный. Можно и без FP наворотить одноразового кода, который невозможно будет развивать.

Вот-вот. Лисп тут всего лишь инструмент, которым решили какие-то архитектурные задачи.

IT>linq2db пережил уже мильён сто тыщь пицот и ещё семь доработок, рефакторингов и глобальных фичедобавлений. При этом базовая архитектура хоть и расширяется, но тотально не меняется. И, кстати, большинство последних фич сделано людьми, которые присоеденились к проекту далеко не сразу.

А представь, что это интернет магазин который купила крупная корпорация и решила инвестировать в его разработку $5-10 миллионов в месяц. Легко будет увеличить в разы команду и поставить на поток новые фичи? Подозреваю, что ты справишься, но если вдруг придется делать без тебя и придет инженер с другим бэкграундом, не факт, что ему хватит скила сохранить твое видение архитектуры в которую можно уложить нужные фичи без запредельного увеличения сложности.

IT>Не стоит обобщать. Конкретно данный пример с лиспом — это пример того как изначально провальный проект выдают за шедевр инженерного творчества и неспособность плебеев понять глубину мысли истинных ламбда-джедаев. Хотя, думаю, история выглядела немного по-другому:

С чего бы провальный? Проект решил свои задачи. Мог он решать их дальше или нет, вопрос для меня открытый. История не знает сослагательного наклонения, но у меня стойкое ощущение, что в причинах смены стека технологии играли лишь роль ширмы и почвы для аргументации. В крупной корпорации появился продукт который не соответствовал привычным паттернам разработки в этой корпорации. Круги на воде от такого булька докатились до тех ЛПР, которым было совершенно пофиг на технологии и они приняли какое-то решение исходя из той информации, которую смогли получить и осознать. Вряд-ли для них это решение было столь же важно как для обитателей КСВ и времени на него они могли потратить сильно меньше, чем потратили рсдновцы в этом топике.

IT>Несомненно талантливые парни вооружились нетривиальным, но и не самым очевидным инструментом и начали клепать разные несложные поделки. Пока "ментальная" модель этих поделок целиком умещалась в голове, то при добавлении новых фич можно было переписывать код хоть каждый раз с нуля (не раз наблюдал такую картину). В таких продуктах, прости господи, архитектура обычно отсутствует напрочь, даже намёки на неё. Это всегда просто слепок "ментальной" модели, воплощённый в коде. Этакий монолит, идеальный круглый шар, артефакт, великолепно и эффективно выполняющий возложенные на него задачи. Хотя и вещь в себе, ни добавить, ни убавить.

Очень сомневаюсь, что идеальности шара проект достиг ровно к моменту продажи. Обычно у стартапа проект растет рывками и в разные стороны, о какой-то идеальности можно говорить лишь на самой первой итерации.

IT>Далее их заметили, купили, повосторгались и предложили из поделки сделать настоящий продукт. И вот здесь размер той самой "ментальной" модели превзошёл возможности несомненно талантливых парней. Адаптировать модель под требуемые фичи стало всё сложнее. Тем более, что список новых фич формируется уже не самим тобой, а другими людьми, часто обладающими несовместимой с твоей фантазией. Если раньше любую невпихуемую фичу можно было отбросить (с собой договориться элементарно), то теперь надо делать. Требование заказчика. Но ведь архитектуры как не было так и нет. Возможно была даже предпринята попытка что-то соорудить на коленке. Но боюсь это только усугубило проблему.

Скорее всего да, решили резко поменять курс. Причем тот кто решал, умел (или делал вид, что умел) делать продукты совсем по другому и на Грэма с его лиспом смотрел в лучшем случае недоверчиво.

IT>В результате получилось — слепок "ментальной" модели с прилепленными сбоку плохо совместимыми фичами и возможно попытками всё это заархитектурить. Помножим всё это на своеобразность выбранного инструмента и получаем абслютно бесполезный в плане развития продукт. Идеальный шар поломался, в кучу не собирается, не монолит и не артефакт, а артехрень. Единственно правильное решение — это взять веничек и замести это всё в мусорное ведёрко. Что, как я понимаю, и было сделано.

Резкие смены курса и команды именно к такому и приводят почти всегда. Независимо от стэка. Новому хозяину кода все кажется говнокодом и слепком ментальной модели автора (что в принципе применимо к любому продукту в той или иной степени), который только переписать.

Здравствуйте, SkyDance, Вы писали:

SD>Мне сложно представить две команды с одинаковым опытом.
Мне кажется еще более странно будет сравнивать команды, когда одна выбирает знакомыый удобный инструмент, а вторая — незнакомый неудобный.

> Если бы опыт был в самом деле одинаков, предпочтения, вероятно, тоже сходились бы.

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

Т.е. сравнивниваем устоявшиеся команды, которые имеют успешный опыт реализации схожих по профилю и сложности проектов, с разницей только в технологиях.

Здравствуйте, Pauel, Вы писали:

P>Потому, что бОльшая часть времени в разработке уходит не на код, а на изучение домена, уточнение требований, проектирование, планирование, согласование, тестирование, настройку окружения, инфраструктуры, траблшутинг, багфикс, отладку, документирование итд итд.
P>Отсюда ясно, что другая команда имея такое же количество людей/опыта в той же области, но специализируясь на другом языке, даст результат за сравнимое время. Может чуть быстрее, может чуть медленнее.
P>На сам код у нормальных людей уходит 5-10 процентов времени. Потому сэкономить больше этих 5-10% ну никак не выйдет.

Настройку инфраструктуры, окружения, документирование и тестирование (кроме автотестов) можно сразу вынести за скобки. Они разовые и от стека зависят почти никак.

Изучение домена, уточнение требований, согласование, планирование — можно делать силами относительно небольшой команды.

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

P>Другие, например, например, потратят на проектирование вдвое больше, в итоге на код уйдет больше времени, но багфикса, траблушинга, итд может оказаться много меньше.

Вот именно. И здесь разные стеки для разных продуктов могут проявить как свои сильные, так и слабые строны во всей красе.

P>Сравнивать нужно яблоки с яблоками — например, две команды с примерно одинаковым опытом но специализируются на разныз технологических стеках, абы эти стеки под задачу подходили.

Вряд-ли это возможно и реально. Конечно можно сравнивать FB и Twitter, Github/Bitbucket, Skyscanner/Aviasales, но смысл непонятен. Продукт делается много кем и его коммерческий успех не определяется только технологией. Технология позволяет делать что-то дешевле/дороже, быстрее/дольше и только. Тем не менее я убежден, что FB/Twitter/Github/Amazon именно такие сильно благодаря используемому стеку, был бы другой стек продукты были бы совсем другими.

Здравствуйте, Ziaw, Вы писали:

Z>Изучение домена, уточнение требований, согласование, планирование — можно делать силами относительно небольшой команды.
Z>А вот проектирование, программирование, отладка, траблшутинг, то есть то, чем занимаются дорогостоящие программисты, может быть очень и очень разным по стоимости.

А это скорее всего будут одни и те же люди. Либо речь пойдет о скорости коммуникации -- кто быстрее и четче сформулирует задачу для программиста, тот
скорее всего и будет успешнее. Т.е. речь о процессах скорее, а не о стеках.

Здравствуйте, Sharov, Вы писали:

S>А это скорее всего будут одни и те же люди. Либо речь пойдет о скорости коммуникации -- кто быстрее и четче сформулирует задачу для программиста, тот
S>скорее всего и будет успешнее. Т.е. речь о процессах скорее, а не о стеках.

Да, в требованиях — о процессах.

Здравствуйте, Ziaw, Вы писали:

P>>Потому, что бОльшая часть времени в разработке уходит не на код, а на изучение домена, уточнение требований, проектирование, планирование, согласование, тестирование, настройку окружения, инфраструктуры, траблшутинг, багфикс, отладку, документирование итд итд.
P>>Отсюда ясно, что другая команда имея такое же количество людей/опыта в той же области, но специализируясь на другом языке, даст результат за сравнимое время. Может чуть быстрее, может чуть медленнее.
P>>На сам код у нормальных людей уходит 5-10 процентов времени. Потому сэкономить больше этих 5-10% ну никак не выйдет.

Z>Настройку инфраструктуры, окружения, документирование и тестирование (кроме автотестов) можно сразу вынести за скобки. Они разовые и от стека зависят почти никак.

Какая интересная подтасовка. Как я вижу — все эти активности булькают постоянно, особенно тестирование. Например, документирование, это написание некоторых design docs, что делается на каждую большую вещь. Тестирование, ручное и автоматическое, это вообще непрерывный процесс.
От стека они не зависят, но зависят от конкретной команды, и время тем не менее требуют постоянно, о чем я тебе и говорю. Считать нужно не чистое время кодинга, а именно время на всё, включая деливери.

Z>Изучение домена, уточнение требований, согласование, планирование — можно делать силами относительно небольшой команды.

Это тем не менее требуется любой команде. Дорогостоящие программисты всё равно должны погрузиться в проблему, иначе не бывает.

Z>А вот проектирование, программирование, отладка, траблшутинг, то есть то, чем занимаются дорогостоящие программисты, может быть очень и очень разным по стоимости.

Могут. И все зависит не от стека, от опыта этих специалистов. И в любом случае издержки на проектирование-программирование-отладку это всего лишь малая часть всех вместе взятых активностей. С учетом того, что доля кодинга скажем, 5-10%, то увеличив её искусственно в 5 раз, мы получим всего 150%. То есть, в полтора раза больше, а не в разы. Зато мы можем сэкономить на других активностях, и снова вернемся туда, где были.

P>>Другие, например, например, потратят на проектирование вдвое больше, в итоге на код уйдет больше времени, но багфикса, траблушинга, итд может оказаться много меньше.
Z>Вот именно. И здесь разные стеки для разных продуктов могут проявить как свои сильные, так и слабые строны во всей красе.

Это как раз те самые 5-10%. Для долгоиграющего проекта гораздо важнее будет ,скажем, выстроить правильную команду. Потому как команда из дорогостоящих специалистов это огромный риск, что после первого релиза никого не останется.
А раз так, то все становится еще интереснее.

P>>Сравнивать нужно яблоки с яблоками — например, две команды с примерно одинаковым опытом но специализируются на разныз технологических стеках, абы эти стеки под задачу подходили.

Z>Вряд-ли это возможно и реально. Конечно можно сравнивать FB и Twitter, Github/Bitbucket, Skyscanner/Aviasales, но смысл непонятен. Продукт делается много кем и его коммерческий успех не определяется только технологией. Технология позволяет делать что-то дешевле/дороже, быстрее/дольше и только. Тем не менее я убежден, что FB/Twitter/Github/Amazon именно такие сильно благодаря используемому стеку, был бы другой стек продукты были бы совсем другими.е

Именно что, коммерческй успех в основном определяется не технологией программирования. Есть исключения — скажем Виндовс был бы другим, если бы его писали не на Си/С++. C другими проектами все далеко не так однозначно. На чем строится твое убеждение про FB, Twitter итд, мне совсем не ясно.

Здравствуйте, vsb, Вы писали:

vsb>Не ошибаешься.

vsb>А вообще я так и не понял фишки лиспа, хотя я даже его компилятор писал (не дописал, но тему изучил достаточно, чтобы представлять себе всё, что надо). Обычный язык. Ничем от джавы не отличается принципиально. Любой код можно плюс-минус одинаково перенести.

Я как то задался целью перевести SICP со схемы на JS. И шота в середине процесса мне стало скучно — я понял, что занимаюсь совсем не тем. Обычный язык.

Здравствуйте, Pauel, Вы писали:

vsb>>А вообще я так и не понял фишки лиспа, хотя я даже его компилятор писал (не дописал, но тему изучил достаточно, чтобы представлять себе всё, что надо). Обычный язык. Ничем от джавы не отличается принципиально. Любой код можно плюс-минус одинаково перенести.

P>Я как то задался целью перевести SICP со схемы на JS. И шота в середине процесса мне стало скучно — я понял, что занимаюсь совсем не тем. Обычный язык.

В схеме есть необычные концепции. Это continuations и гигиенические макросы. Аналога этому в других языках обычно нет (вроде в Rust есть макросы). В остальном — да, обычный язык. Не знаю, используются ли эти концепции в SICP.

Здравствуйте, Pauel, Вы писали:

P>От стека они не зависят, но зависят от конкретной команды, и время тем не менее требуют постоянно, о чем я тебе и говорю. Считать нужно не чистое время кодинга, а именно время на всё, включая деливери.

Считать надо то, на что мы можем повлиять управляющим воздействием (выбором стека). На кой черт считать расходы на тестирование, покупку компов сотрудникам и

P>Это тем не менее требуется любой команде. Дорогостоящие программисты всё равно должны погрузиться в проблему, иначе не бывает.

Это необходимое требование.

P>Могут. И все зависит не от стека, от опыта этих специалистов. И в любом случае издержки на проектирование-программирование-отладку это всего лишь малая часть всех вместе взятых активностей. С учетом того, что доля кодинга скажем, 5-10%, то увеличив её искусственно в 5 раз, мы получим всего 150%. То есть, в полтора раза больше, а не в разы. Зато мы можем сэкономить на других активностях, и снова вернемся туда, где были.

Да нифига, правильный выбор стека ведет к уменьшению сложности. А сложность это самая проблемная метрика проекта, как только все становится сложно, все становится очень дорого.

P>Это как раз те самые 5-10%. Для долгоиграющего проекта гораздо важнее будет ,скажем, выстроить правильную команду. Потому как команда из дорогостоящих специалистов это огромный риск, что после первого релиза никого не останется.
P>А раз так, то все становится еще интереснее.

Если у продукта есть будущее — после первого релиза все только начинается. Нормальные специалисты только входят во вкус.

P>Именно что, коммерческй успех в основном определяется не технологией программирования.

Рад, что ты тоже это понимаешь. Это не означает, что он ей не определяется вообще и можно этим не заморачиваться. Каждый стратап проходит очень много тонких моментов на грани и в некоторые моменты разработка становится либо грузом, топящим бизнес либо спасательным кругом, который его затаскивает. Точно так же, как и отдел продаж/маркетинга.

Здравствуйте, Ziaw, Вы писали:

P>>От стека они не зависят, но зависят от конкретной команды, и время тем не менее требуют постоянно, о чем я тебе и говорю. Считать нужно не чистое время кодинга, а именно время на всё, включая деливери.

Z>Считать надо то, на что мы можем повлиять управляющим воздействием (выбором стека). На кой черт считать расходы на тестирование, покупку компов сотрудникам и

Затем, что нет в природе такого юз-кейса как "кто быстрее накодит вон ту хрень". Нам нужно полное решение, включая все аспекты, даже создание контента, есть такой есть. Странно говорить о том, что проект готов, если тестирование не закончено, а контент не готов.
И считать расходы нужно именно целиком, т.к. зп нужно платить всем.

Z>Да нифига, правильный выбор стека ведет к уменьшению сложности. А сложность это самая проблемная метрика проекта, как только все становится сложно, все становится очень дорого.

Теоретически. Когда речь про формошлепство, то в данный момент у нас несколько кандидатов — React и чтото там еще. А если речь про солюшн, а не компонент, то влияние стека сильно размывается.

P>>А раз так, то все становится еще интереснее.

Z>Если у продукта есть будущее — после первого релиза все только начинается. Нормальные специалисты только входят во вкус.

Вот-вот. И нужно теперь гарантировать, что этих людей ты сможешь вовремя заменить. Как то так выходит, что команда крутых спецов на старте означает переписывание всего подряд с версии 2.0. Вот пример с Лиспом он как раз это и продемонстрировал.

Здравствуйте, SkyDance, Вы писали:

SD>·>Ага, вот типичная машинистка на пэхапе. И до сих пор используют, переписывать не пришлось, в отличие от этих ваших лиспов.
SD>Э-э-э.
SD>Скажу так, он того пэхапе что был пэхапе там, пожалуй, не осталось ровным счетом ничего.
Эээ.. пхп же остался. А вот лисп переписали и лиспа не осталось вообще.

SD>Более того, PHP как язык не поддерживается вообще.
Stable release 8.1.7 / 9 June 2022; 10 days ago

SD>В то же время другие языки — как тот же Haskell или Erlang — используются очень широко, и без переписывания всей кодовой базы.
Stable release Haskell 2010[2] / July 2010; 11 years ago

Так что пишите, дети, на пэхапэ, и вы сможете себе позволить сводить подружку в макдональдс!

удалено