Сообщение Re[23]: C#,Java, go - дико дорого от 11.06.2022 11:08
Изменено 11.06.2022 11:28 Pauel
Re[23]: C#,Java, go - дико дорого
Здравствуйте, SkyDance, Вы писали:
I>>Что бы вести речь про качество, нужно сначала узнать требования.
SD>Стоит сначала договорится о терминах. Требования — это такая штука, которая меняется быстрее, чем флюгер у меня около дома направление меняет. Если качество будет прыгать с такой же амплитудой и частотой, вряд ли удастся хоть что-то соорудить.
Качество это степень соответствия требованиям. Если нужно изменить БЛ, а ты не успеваешь, то качество твоего софта уже ниже плинтуса — никому не нужна БЛ для старого подхода.
SD>Про "особенности языков с динамической типизацией" предлагаю поговорить тогда, когда вы поработаете в реально больших проектах. Заодно посмотрите теорию на тему сильной/слабой, и статической/динамической типизацией.
SD>И если что, type checker'ов для JS наделано куча.
Спасибо, посмеялся. По основной работе у тебя только большие долгострои. Самый короткий проект был 4 года.
SD>Но дело не в них, а в том, что JS реально убог. Популярность же его обеспечена вовсе не удобством или чем-то еще, а всего лишь случайной возможностью оказаться на пустой нише. Как kubernetes — отвратительный, ужасный, organically grown в худшем своем варианте.
Конспирологический аргумент. Возможностей оказаться там же была у целой кучи конкурентов. Все они работали в браузере и все до одного слились.
— куча языков. Ты вероятно даже не подозреваешь, сколько языков в свое время поддерживались браузерами нативно, в конце 90х начале 00х.
— сервлеты
— активикс
— флеш
— сервелат
— разного сорта расширения
Поэтому нет никакой "случайной возможностью оказаться на пустой нише", а была долгая борьба в которой жээсу понадобилось около 10 лет, что бы сбороть бОльшую часть. Последний конкурент — флеш, отгнил всего несколько лет назад.
SD>Вы просто не понимаете, как гиганты работают.
Наблюдаю это изнутри последние 12 лет.
SD>Если вы наивно думаете, что технические свойства того или иного инструмента имеют хоть сколь-нибудь заметное значение — я вас разочарую. Политика и sales, sales и политика.
Сам придумал, сам опроверг.
I>>Вот-вот. Именно этому ты научил своего ребенка. Начатый на ххх проект продолжают заваливать баблом и костылями — я такое видел и на С++, дотнет, джава, итд итд. Причины, как правило, большей частью не в коде, а в менеджменте, архитектуре, требования, сроках и тдю
SD>Опять персональные нападки, теперь уже и ребенку перепадает. Если продолжится, то будете сами с собой беседовать, мне так неинтересно. Причины всегда в политике (деньгах), потом уже догнивает и до менеджмента с архитектурой и сроками.
Итого — мы выяснили, что твой аргумент был невалидным, т.к. причины не в яп, с твоих же слов.
I>>Примеров успешных проектов на динамике полно, стоит только глаза раскрыть.
I>>Сейчас вообще пишется однодневок на порядок другой больше. Вот и создается такая иллюзия, что ничего другого и нет.
SD>Вот вы эту иллюзию и пытаетесь развивать куда не надо, пихая node.js в бэкенд. Где ему не место.
Голословно. Нода позволяет реализовать очень толковый подход к разработке — бакенд, апи, фронтенд, бд пилятся как части одного целого, при этом облегчается проектирование, планирование, стаффинг, итд.
Например, сделать consumer driven api бакенда на дотнете/джаве не представляется возможным. Фронтенды не умеют дотнет, а бакенды не умеют фронтенд. Это оксюморон — они только думают, что знают фронтенд. Большей частью это иллюзии вида "а чо там думать, там же всё тривиально" из чего рождаются дикие чудовища и самопальные велосипеды, которые никто не может поддерживать.
А вот на ноде элементарно и естественно передать фронтам построение апи для фронтенда, которое меняется с той же частотой, что и треботвания. При этом устраняются проблемы с горизонтальными зависимостям — не надо ждать бакенда, пока он закончит чтото другое, тоже важное В итоге продуктивность команды будет наголову выше чем в другом стеке технологий.
Без этого получается так — бакенд это чтото страшное где то там, бд это чтото еще страшнее еще дальше. Из такого подхода и растут ошибки.
I>>Что бы вести речь про качество, нужно сначала узнать требования.
SD>Стоит сначала договорится о терминах. Требования — это такая штука, которая меняется быстрее, чем флюгер у меня около дома направление меняет. Если качество будет прыгать с такой же амплитудой и частотой, вряд ли удастся хоть что-то соорудить.
Качество это степень соответствия требованиям. Если нужно изменить БЛ, а ты не успеваешь, то качество твоего софта уже ниже плинтуса — никому не нужна БЛ для старого подхода.
SD>Про "особенности языков с динамической типизацией" предлагаю поговорить тогда, когда вы поработаете в реально больших проектах. Заодно посмотрите теорию на тему сильной/слабой, и статической/динамической типизацией.
SD>И если что, type checker'ов для JS наделано куча.
Спасибо, посмеялся. По основной работе у тебя только большие долгострои. Самый короткий проект был 4 года.
SD>Но дело не в них, а в том, что JS реально убог. Популярность же его обеспечена вовсе не удобством или чем-то еще, а всего лишь случайной возможностью оказаться на пустой нише. Как kubernetes — отвратительный, ужасный, organically grown в худшем своем варианте.
Конспирологический аргумент. Возможностей оказаться там же была у целой кучи конкурентов. Все они работали в браузере и все до одного слились.
— куча языков. Ты вероятно даже не подозреваешь, сколько языков в свое время поддерживались браузерами нативно, в конце 90х начале 00х.
— сервлеты
— активикс
— флеш
— сервелат
— разного сорта расширения
Поэтому нет никакой "случайной возможностью оказаться на пустой нише", а была долгая борьба в которой жээсу понадобилось около 10 лет, что бы сбороть бОльшую часть. Последний конкурент — флеш, отгнил всего несколько лет назад.
SD>Вы просто не понимаете, как гиганты работают.
Наблюдаю это изнутри последние 12 лет.
SD>Если вы наивно думаете, что технические свойства того или иного инструмента имеют хоть сколь-нибудь заметное значение — я вас разочарую. Политика и sales, sales и политика.
Сам придумал, сам опроверг.
I>>Вот-вот. Именно этому ты научил своего ребенка. Начатый на ххх проект продолжают заваливать баблом и костылями — я такое видел и на С++, дотнет, джава, итд итд. Причины, как правило, большей частью не в коде, а в менеджменте, архитектуре, требования, сроках и тдю
SD>Опять персональные нападки, теперь уже и ребенку перепадает. Если продолжится, то будете сами с собой беседовать, мне так неинтересно. Причины всегда в политике (деньгах), потом уже догнивает и до менеджмента с архитектурой и сроками.
Итого — мы выяснили, что твой аргумент был невалидным, т.к. причины не в яп, с твоих же слов.
I>>Примеров успешных проектов на динамике полно, стоит только глаза раскрыть.
I>>Сейчас вообще пишется однодневок на порядок другой больше. Вот и создается такая иллюзия, что ничего другого и нет.
SD>Вот вы эту иллюзию и пытаетесь развивать куда не надо, пихая node.js в бэкенд. Где ему не место.
Голословно. Нода позволяет реализовать очень толковый подход к разработке — бакенд, апи, фронтенд, бд пилятся как части одного целого, при этом облегчается проектирование, планирование, стаффинг, итд.
Например, сделать consumer driven api бакенда на дотнете/джаве не представляется возможным. Фронтенды не умеют дотнет, а бакенды не умеют фронтенд. Это оксюморон — они только думают, что знают фронтенд. Большей частью это иллюзии вида "а чо там думать, там же всё тривиально" из чего рождаются дикие чудовища и самопальные велосипеды, которые никто не может поддерживать.
А вот на ноде элементарно и естественно передать фронтам построение апи для фронтенда, которое меняется с той же частотой, что и треботвания. При этом устраняются проблемы с горизонтальными зависимостям — не надо ждать бакенда, пока он закончит чтото другое, тоже важное В итоге продуктивность команды будет наголову выше чем в другом стеке технологий.
Без этого получается так — бакенд это чтото страшное где то там, бд это чтото еще страшнее еще дальше. Из такого подхода и растут ошибки.
Re[23]: C#,Java, go - дико дорого
Здравствуйте, SkyDance, Вы писали:
I>>Что бы вести речь про качество, нужно сначала узнать требования.
SD>Стоит сначала договорится о терминах. Требования — это такая штука, которая меняется быстрее, чем флюгер у меня около дома направление меняет. Если качество будет прыгать с такой же амплитудой и частотой, вряд ли удастся хоть что-то соорудить.
Качество это степень соответствия требованиям. Если нужно изменить БЛ, а ты не успеваешь, то качество твоего софта уже ниже плинтуса — никому не нужна БЛ для старого подхода.
> За переход на личности — незачет. Крайне невежливо. Особенно не зная собеседника.
Аргумент про своего ребенка тащишь ты сам. Я тебя не оскорбляю, а показываю тебе же, что твой аргумент с твоим ребенком невалидный.
Если ты такой чувствительный — не используй аргумент с ребенком как затычку.
SD>Про "особенности языков с динамической типизацией" предлагаю поговорить тогда, когда вы поработаете в реально больших проектах. Заодно посмотрите теорию на тему сильной/слабой, и статической/динамической типизацией.
SD>И если что, type checker'ов для JS наделано куча.
Спасибо, посмеялся. По основной работе у тебя только большие долгострои. Самый короткий проект был 4 года.
SD>Но дело не в них, а в том, что JS реально убог. Популярность же его обеспечена вовсе не удобством или чем-то еще, а всего лишь случайной возможностью оказаться на пустой нише. Как kubernetes — отвратительный, ужасный, organically grown в худшем своем варианте.
Конспирологический аргумент. Возможностей оказаться там же была у целой кучи конкурентов. Все они работали в браузере и все до одного слились.
— куча языков. Ты вероятно даже не подозреваешь, сколько языков в свое время поддерживались браузерами нативно, в конце 90х начале 00х.
— сервлеты
— активикс
— флеш
— сервелат
— разного сорта расширения
Поэтому нет никакой "случайной возможностью оказаться на пустой нише", а была долгая борьба в которой жээсу понадобилось около 10 лет, что бы сбороть бОльшую часть. Последний конкурент — флеш, отгнил всего несколько лет назад.
SD>Вы просто не понимаете, как гиганты работают.
Наблюдаю это изнутри последние 12 лет.
SD>Если вы наивно думаете, что технические свойства того или иного инструмента имеют хоть сколь-нибудь заметное значение — я вас разочарую. Политика и sales, sales и политика.
Сам придумал, сам опроверг.
I>>Вот-вот. Именно этому ты научил своего ребенка. Начатый на ххх проект продолжают заваливать баблом и костылями — я такое видел и на С++, дотнет, джава, итд итд. Причины, как правило, большей частью не в коде, а в менеджменте, архитектуре, требования, сроках и тдю
SD>Опять персональные нападки, теперь уже и ребенку перепадает. Если продолжится, то будете сами с собой беседовать, мне так неинтересно. Причины всегда в политике (деньгах), потом уже догнивает и до менеджмента с архитектурой и сроками.
Итого — мы выяснили, что твой аргумент был невалидным, т.к. причины не в яп, с твоих же слов.
I>>Примеров успешных проектов на динамике полно, стоит только глаза раскрыть.
I>>Сейчас вообще пишется однодневок на порядок другой больше. Вот и создается такая иллюзия, что ничего другого и нет.
SD>Вот вы эту иллюзию и пытаетесь развивать куда не надо, пихая node.js в бэкенд. Где ему не место.
Голословно. Нода позволяет реализовать очень толковый подход к разработке — бакенд, апи, фронтенд, бд пилятся как части одного целого, при этом облегчается проектирование, планирование, стаффинг, итд.
Например, сделать consumer driven api бакенда на дотнете/джаве не представляется возможным. Фронтенды не умеют дотнет, а бакенды не умеют фронтенд. Это оксюморон — они только думают, что знают фронтенд. Большей частью это иллюзии вида "а чо там думать, там же всё тривиально" из чего рождаются дикие чудовища и самопальные велосипеды, которые никто не может поддерживать.
А вот на ноде элементарно и естественно передать фронтам построение апи для фронтенда, которое меняется с той же частотой, что и треботвания. При этом устраняются проблемы с горизонтальными зависимостям — не надо ждать бакенда, пока он закончит чтото другое, тоже важное В итоге продуктивность команды будет наголову выше чем в другом стеке технологий.
Без этого получается так — бакенд это чтото страшное где то там, бд это чтото еще страшнее еще дальше. Из такого подхода и растут ошибки.
I>>Что бы вести речь про качество, нужно сначала узнать требования.
SD>Стоит сначала договорится о терминах. Требования — это такая штука, которая меняется быстрее, чем флюгер у меня около дома направление меняет. Если качество будет прыгать с такой же амплитудой и частотой, вряд ли удастся хоть что-то соорудить.
Качество это степень соответствия требованиям. Если нужно изменить БЛ, а ты не успеваешь, то качество твоего софта уже ниже плинтуса — никому не нужна БЛ для старого подхода.
> За переход на личности — незачет. Крайне невежливо. Особенно не зная собеседника.
Аргумент про своего ребенка тащишь ты сам. Я тебя не оскорбляю, а показываю тебе же, что твой аргумент с твоим ребенком невалидный.
Если ты такой чувствительный — не используй аргумент с ребенком как затычку.
SD>Про "особенности языков с динамической типизацией" предлагаю поговорить тогда, когда вы поработаете в реально больших проектах. Заодно посмотрите теорию на тему сильной/слабой, и статической/динамической типизацией.
SD>И если что, type checker'ов для JS наделано куча.
Спасибо, посмеялся. По основной работе у тебя только большие долгострои. Самый короткий проект был 4 года.
SD>Но дело не в них, а в том, что JS реально убог. Популярность же его обеспечена вовсе не удобством или чем-то еще, а всего лишь случайной возможностью оказаться на пустой нише. Как kubernetes — отвратительный, ужасный, organically grown в худшем своем варианте.
Конспирологический аргумент. Возможностей оказаться там же была у целой кучи конкурентов. Все они работали в браузере и все до одного слились.
— куча языков. Ты вероятно даже не подозреваешь, сколько языков в свое время поддерживались браузерами нативно, в конце 90х начале 00х.
— сервлеты
— активикс
— флеш
— сервелат
— разного сорта расширения
Поэтому нет никакой "случайной возможностью оказаться на пустой нише", а была долгая борьба в которой жээсу понадобилось около 10 лет, что бы сбороть бОльшую часть. Последний конкурент — флеш, отгнил всего несколько лет назад.
SD>Вы просто не понимаете, как гиганты работают.
Наблюдаю это изнутри последние 12 лет.
SD>Если вы наивно думаете, что технические свойства того или иного инструмента имеют хоть сколь-нибудь заметное значение — я вас разочарую. Политика и sales, sales и политика.
Сам придумал, сам опроверг.
I>>Вот-вот. Именно этому ты научил своего ребенка. Начатый на ххх проект продолжают заваливать баблом и костылями — я такое видел и на С++, дотнет, джава, итд итд. Причины, как правило, большей частью не в коде, а в менеджменте, архитектуре, требования, сроках и тдю
SD>Опять персональные нападки, теперь уже и ребенку перепадает. Если продолжится, то будете сами с собой беседовать, мне так неинтересно. Причины всегда в политике (деньгах), потом уже догнивает и до менеджмента с архитектурой и сроками.
Итого — мы выяснили, что твой аргумент был невалидным, т.к. причины не в яп, с твоих же слов.
I>>Примеров успешных проектов на динамике полно, стоит только глаза раскрыть.
I>>Сейчас вообще пишется однодневок на порядок другой больше. Вот и создается такая иллюзия, что ничего другого и нет.
SD>Вот вы эту иллюзию и пытаетесь развивать куда не надо, пихая node.js в бэкенд. Где ему не место.
Голословно. Нода позволяет реализовать очень толковый подход к разработке — бакенд, апи, фронтенд, бд пилятся как части одного целого, при этом облегчается проектирование, планирование, стаффинг, итд.
Например, сделать consumer driven api бакенда на дотнете/джаве не представляется возможным. Фронтенды не умеют дотнет, а бакенды не умеют фронтенд. Это оксюморон — они только думают, что знают фронтенд. Большей частью это иллюзии вида "а чо там думать, там же всё тривиально" из чего рождаются дикие чудовища и самопальные велосипеды, которые никто не может поддерживать.
А вот на ноде элементарно и естественно передать фронтам построение апи для фронтенда, которое меняется с той же частотой, что и треботвания. При этом устраняются проблемы с горизонтальными зависимостям — не надо ждать бакенда, пока он закончит чтото другое, тоже важное В итоге продуктивность команды будет наголову выше чем в другом стеке технологий.
Без этого получается так — бакенд это чтото страшное где то там, бд это чтото еще страшнее еще дальше. Из такого подхода и растут ошибки.