Такие люди ничего не используют.
Они не утруждают себя разбираться как работают IoC-контейнеры и какие техники лучше применять при их использовании. Берут копипасту из гугла всякой фигни в свой код, в итоге не могут в этой куче разобраться и провозглашают IoC отстоем по определению.
Если хоть немного пошевелить головой, то IoC не мешает делать нормальный код. Только вот шевелить люди не любят. Копипаста рулит…
Ну какая «такая» там работа?
Проект будет страдать, если надо будет делать универсальную публичную библиотеку.
С поддержкой разных языков, с кучей всяких универсальных фишек и т.д.
А сделать протокол для конкретной задачи, не такая уж большая проблема.
С другой стороны, для большинства программистов даже бинарный поиск написать проблема.
А уж написать протокол вообще непосильная задача)
P.S. Я не агитирую за велосипеды. Я и сам писал протоколы. Но в итоге остановился на протобафе.
Но не вижу какой-то особо сложной задачи, в написании протокола, для конкретного проекта.
Безо всякой универсальности и кучи языков в поддержке.
Как-то у вас так получается, что если библиотека не публичная, то она обязательно кривая, косая, глючная и вообще непонтяно как работает…
Не допускаете даже мысли, что люди могут сделать хорошо свою работу?
P.S. И кстати. Зачем им кодогенераторы для кучи языков? Зачем им с кем-то совмещаться? Зачем им знакомить с кем то свою разработку? Это небольшая библиотека для конкретной задачи, в абсолютно закрытом проекте.
Это же не линух с нуля писать, небольшая библиотечка. В конце концов, если вы не можете написать даже небольшую библиотечку без гов или исправить их. Это же не значит что все такие.
Есть клевая старая поговорка «Заставь дурака богу молиться — он лоб разобьет».
Статья как раз об этом. Когда выключая голову, начинают тупо следовать каким-то догмам.
А потом, когда хлебнут проблем, так же тупо от них отказываются.
Все эти клевые техники, подходы, «аббревиатуры» и прочие, надо воспринимать исходя из принципа:
«Сказка — ложь, да в ней намек, добрым молодцам урок.»
Но люди почему-то не хотят думать своей головой. Они хоят прочитать пошаговый урок, и тупо повторять его бесконечно для получения денег. Подход как в РПГ. Не жизнь, а тупая гриндилка.
>Если вы видите первые признаки затягивания со стороны заказчика, используйте следующий алгоритм:
1. Внимательно изучить договор как должен быть направлен результат.
Ох уж этот совковый метод вести дела.
«Если вас, внезапно, клюнул в зад жареный петух, то действуйте следующим образом...».
Для тех 0.001% приложений, для которых этот «жосткийрилтайм» нужен, используют С++, все верно.
Остальные же 99.999% приложений, люди спокойно пишут на Java и иже с ним, за день.
И смотрят снисходительно на тех упоротых, которые неделями выжимают никому не нужные проценты производительности. А потом еще недели тратят на борьбу с сегфолтами и утечками.
Попутно отхватывая проблем с кросплатформенностью…
Кстати, если IDEA на Java такая тормозная гадость, а С++ такой вот весь из себя быстрый и крутой, где IDE уровня IDEA написанные на нем?
Если только ради справедливости.
Ибо мы все прекрасно знаем, что такие проекты единичны и на них не стоит делать общие выводы.
P.S. Если только вы не считаете игровой сервер для ммо социалки или систему документооборота для предприятия или аналогичные по сути проекты, не требующими поддержки.
Естественно продуктивность будет в каждом предложении.
Видел я таких «продуктивных» разработчиков. Не один раз.
Из разряда «Я за три дня зафигарил проект».
Смотришь в код и видишь там 1 класс и 4 метода… на 9000 строк кода)
Но начальник (заказчик) просто ссыыт кипятком, какой крутой инженер, всем брать с него пример!
Так автор же сам из этой же группы.
Он выбрал язык, на котром пишет, во всем мире, хорошо если несколько сотен человек.
Что делать его клиентам?
Он заставит своих сотрудников изучтать… вернее покупать акции неизвестной компании.
Которая, как ему кажется, вырастет в цене.
А люди будут покупать эти акции за самый дорогой ресурс в мире, за свое собственное время.
Сколько там игроков на бирже сливается в пух и прах?
Вот такой же процент людей, в его конторе, пойдет по миру с этими акциями.
Что-то все как-то обходят стороной, в обсуждениях Nim, такой не маловажный момент, как команда разработчиков языка.
За Rust стоит хорошая команда. А что там с Nim?
Вы тоже, в статье, скромно умолчали про это.
А что такое «настоящая альтернатива»?
Зачем вообще делать еще одну 1С?
Нужны именно альтернативы. А их на самом деле полно.
Дело в том, что не всем нужны все эти навороты 1С.
Поэтому система описанная в статье она именно альтернатива.
Не полный аналог, а именно альтернатива.
Та все поняно… про Nim тут разных местах стал слышать восторженные возгласы.
Автор походу из того же лагеря.
Надеюсь только он безо всяких молебен расскажет в чем цимус, и почему Nim.
Ну с этим не поспоришь. Я про это тоже писал.
Я говорю, что минимизировать риск того, что эти ребята свернут деятельность можно очень простыми шагами.
Прелесть же таких небольших контор в том, что они намного проворнее гигантов. И покупают у них сервис потому, что гиганты очень неповоротливы и не спешат поворачиваться к заказчику лицом. Особенно если они по сути монополисты.
Тут все решают конкретные люди.
Кстати, есть примеры в истории, когда внедрение например продуктов SAP, вроде бы крутой и надежной компании, приводило к разорению клиента. Так что не все так однозначно. Риски бывают разные, и каждый выбирает минимальные для него.
В вашей ссылке написано именно то о чем я писал, Spray технологичнее Netty.
Поэтому и перешли. Я нигде не писал, что единственной причиной перехода был вопрос производительности. Я нигде и никогда не говорил, что у Netty проблемы с производительностью. И прежде чем так по детски гнуть пальцы, разобрались бы о чем я здесь пишу вообще.
>И ваш прирост в тестах объясняется не переходом на акку(спрей), а совсем другими нюансами.
А вот тут у вас с логикой что-то проскальзывает. Замена библиотеки A на B дает прирост производительности, но этот прирост не обусловлен этой заменой. Не ощущаете странности в вашем высказывании? Может объясните, почему замена библиотеки дает прирост, не обусловленный этой библиотекой?
P.S. Прежде чем тыкать в кого-то пальцем, обвинять, неплохо бы самому разобраться в вопросе, что бы не позориться так.
Они не утруждают себя разбираться как работают IoC-контейнеры и какие техники лучше применять при их использовании. Берут копипасту из гугла всякой фигни в свой код, в итоге не могут в этой куче разобраться и провозглашают IoC отстоем по определению.
Если хоть немного пошевелить головой, то IoC не мешает делать нормальный код. Только вот шевелить люди не любят. Копипаста рулит…
Блин, это была единственная причина использовать OneDrive.
Что бы не синхронизировать на ноут с небольшим SSD все облако.
P.S. Ну почему производители всегда ориентируются на даунов?
Проект будет страдать, если надо будет делать универсальную публичную библиотеку.
С поддержкой разных языков, с кучей всяких универсальных фишек и т.д.
А сделать протокол для конкретной задачи, не такая уж большая проблема.
С другой стороны, для большинства программистов даже бинарный поиск написать проблема.
А уж написать протокол вообще непосильная задача)
P.S. Я не агитирую за велосипеды. Я и сам писал протоколы. Но в итоге остановился на протобафе.
Но не вижу какой-то особо сложной задачи, в написании протокола, для конкретного проекта.
Безо всякой универсальности и кучи языков в поддержке.
Не допускаете даже мысли, что люди могут сделать хорошо свою работу?
P.S. И кстати. Зачем им кодогенераторы для кучи языков? Зачем им с кем-то совмещаться? Зачем им знакомить с кем то свою разработку? Это небольшая библиотека для конкретной задачи, в абсолютно закрытом проекте.
Это же не линух с нуля писать, небольшая библиотечка. В конце концов, если вы не можете написать даже небольшую библиотечку без гов или исправить их. Это же не значит что все такие.
Статья как раз об этом. Когда выключая голову, начинают тупо следовать каким-то догмам.
А потом, когда хлебнут проблем, так же тупо от них отказываются.
Все эти клевые техники, подходы, «аббревиатуры» и прочие, надо воспринимать исходя из принципа:
«Сказка — ложь, да в ней намек, добрым молодцам урок.»
Но люди почему-то не хотят думать своей головой. Они хоят прочитать пошаговый урок, и тупо повторять его бесконечно для получения денег. Подход как в РПГ. Не жизнь, а тупая гриндилка.
1. Внимательно изучить договор как должен быть направлен результат.
Ох уж этот совковый метод вести дела.
«Если вас, внезапно, клюнул в зад жареный петух, то действуйте следующим образом...».
Остальные же 99.999% приложений, люди спокойно пишут на Java и иже с ним, за день.
И смотрят снисходительно на тех упоротых, которые неделями выжимают никому не нужные проценты производительности. А потом еще недели тратят на борьбу с сегфолтами и утечками.
Попутно отхватывая проблем с кросплатформенностью…
Кстати, если IDEA на Java такая тормозная гадость, а С++ такой вот весь из себя быстрый и крутой, где IDE уровня IDEA написанные на нем?
— Му тут придумали херню, сами непоняли зачем, но главное, что не как у всех.
Так что ли? Это же маркетинг, они любую хрень будут выдавать за достоинство.
Ибо мы все прекрасно знаем, что такие проекты единичны и на них не стоит делать общие выводы.
P.S. Если только вы не считаете игровой сервер для ммо социалки или систему документооборота для предприятия или аналогичные по сути проекты, не требующими поддержки.
Видел я таких «продуктивных» разработчиков. Не один раз.
Из разряда «Я за три дня зафигарил проект».
Смотришь в код и видишь там 1 класс и 4 метода… на 9000 строк кода)
Но начальник (заказчик) просто ссыыт кипятком, какой крутой инженер, всем брать с него пример!
Первая категория тоже отлично вписывается в выбор)
Он выбрал язык, на котром пишет, во всем мире, хорошо если несколько сотен человек.
Что делать его клиентам?
Он заставит своих сотрудников изучтать… вернее покупать акции неизвестной компании.
Которая, как ему кажется, вырастет в цене.
А люди будут покупать эти акции за самый дорогой ресурс в мире, за свое собственное время.
Сколько там игроков на бирже сливается в пух и прах?
Вот такой же процент людей, в его конторе, пойдет по миру с этими акциями.
Может выбирать будут актеры…
За Rust стоит хорошая команда. А что там с Nim?
Вы тоже, в статье, скромно умолчали про это.
Зачем вообще делать еще одну 1С?
Нужны именно альтернативы. А их на самом деле полно.
Дело в том, что не всем нужны все эти навороты 1С.
Поэтому система описанная в статье она именно альтернатива.
Не полный аналог, а именно альтернатива.
Автор походу из того же лагеря.
Надеюсь только он безо всяких молебен расскажет в чем цимус, и почему Nim.
Он недавно зарелизился, а автор вроде как подводит, он недавно нашел идеальный язык…
Я говорю, что минимизировать риск того, что эти ребята свернут деятельность можно очень простыми шагами.
Прелесть же таких небольших контор в том, что они намного проворнее гигантов. И покупают у них сервис потому, что гиганты очень неповоротливы и не спешат поворачиваться к заказчику лицом. Особенно если они по сути монополисты.
Тут все решают конкретные люди.
Кстати, есть примеры в истории, когда внедрение например продуктов SAP, вроде бы крутой и надежной компании, приводило к разорению клиента. Так что не все так однозначно. Риски бывают разные, и каждый выбирает минимальные для него.
Поэтому и перешли. Я нигде не писал, что единственной причиной перехода был вопрос производительности. Я нигде и никогда не говорил, что у Netty проблемы с производительностью. И прежде чем так по детски гнуть пальцы, разобрались бы о чем я здесь пишу вообще.
>И ваш прирост в тестах объясняется не переходом на акку(спрей), а совсем другими нюансами.
А вот тут у вас с логикой что-то проскальзывает. Замена библиотеки A на B дает прирост производительности, но этот прирост не обусловлен этой заменой. Не ощущаете странности в вашем высказывании? Может объясните, почему замена библиотеки дает прирост, не обусловленный этой библиотекой?
P.S. Прежде чем тыкать в кого-то пальцем, обвинять, неплохо бы самому разобраться в вопросе, что бы не позориться так.