Ой, я тут мимо проходил и решил написать. Я в корне не согласен, мой опыт использования angular говорит о обратном. На начальном этапе с angular все очень просто. Можно начинать писать вообще мало чего зная. С каждым месяцем использования Angular я находил новые интересные особенности, которые приводили меня в бешенство. По итогу общего опыта работы в полтора года с этим чудом я не возьму ангуляр для проекта длинее месяца и сложнее говноформочек.
Дальше, вы весьма неправы касательно state manager. Начнем с того, что в самом Angular уже идёт два механизма отслеживания изменений из коробки: либо на каждый чих, либо OnPush. Первый идеально подходит для случаев, когда не нужно управлять стейтом. Второй является основой для стейт менеджмента, при этом не самого лучшего качества. И да, вы можете подключить redux, ngrx (похоже на redux, но несовместимо с redux), mobx и я не знаю что ещё. Другое дело, что для многих проектов эти вещи не нужны.
Особенных лулзов я ловлю с того, что вы включили в свой список rxjs. По моим ощущением, за пределами Angular он мало кому сдался по объективным причинам.
ИМХО, почему так получается: на рынке не хватает квалифицированных кадров
Особенно жуткие обороты ситуация принимает в связи с тем, что найм сотрудников происходит не заранее, а по ситуации. И это еще сильнее уменьшает возможность нанять хорошего специалиста.
Добавим немного «теории заговора». В рамках аутсорса крупных проектов заморачиваться с наймом нет смысла, потому что тратятся деньги заказчика (а не аутсорс-компании), а аутсорс-компания получает деньги за человеко-часы. И пара неквалифицированных чуваков увеличивает и количество человек, и количество часов (ведь новые десять багов кто-то должен пофиксить). Т.е. аутсорсу (коего дохрена) выгоднее нанимать менее способных специалистов. Ой нет, это не теория заговора, а реальная картина мира.
Вот еще одна забавная вещь. При недостатке квалифицированных кадров очень важны становятся самоконтроль, доброта и терпимость к неквалифицированным кадрам (софт скиллы).
Есть мнение, что команда сварливых звезд способна сделать более хороший продукт, нежели команда дружелюбных людей, которые занимаются неосознанным вредительством в техническом плане.
Например, встречали ли вы людей, которые при фиксе одного бага создают десяток новых?
Драма в том, что оперирование мудаками и идиотами в подобных рассуждениях дает мало представления о том, насколько важно развивать хард и софт скиллы. Такие кейсы показывают только то, что с мудаками и идиотами трудно построить что-то работающее
То, что у вас взгляд скользит — это просто ваш стиль чтения. К примеру, я могу переключаться между чтением по буквам, чтением по словам и сканированием отдельных предложений. Но это требует осознанной концентрации и длится не более пары минут.
Возможно, что вы просто не достаточно сконцентрировались на задаче "читать текст по буквам"
Очень странное рассуждение: отсутствием идеала вы показываете что?
Давайте так: я утверждаю, что brainfuck еще более кастрированный.
Не кажется ли вам странным, что ваше рассуждение не позволяет мне утверждать про кастрированность {uglyLang}, только потому, что другие языки имеют свои слабые стороны?
Или brainfuck — норм язык?
Когда говорят про кастрированность языка очень редко подразумевают "общеупотребимую полноту по Тьюрингу". Обычно эта фраза значит, что существует класс задач, который в этом языке делается через жопу. Вам нужно развернуть определение "делается через жопу"?
Право говоря, мне очень странно видеть, что "отсутствие дженериков как признак урезанности" для кого-то является спорным. Уж извините, но хейтят golang за это давно. У существования дженериков (в других языках) есть определенная причина. И нужно доказывать, что плюсы от удаления дженериков перевешивают минусы. Здесь спорно, что их не реализовали. И вовсе не спорно, что их отсутствие осуждается.
Почему в программировании создается впечатление, что вообще нет стандартных способов.
Стандартные способы уже вынесены в ос, фреймворки, библиотеки. Если нет явного NIH (а он на самом деле не так част, как кажется), то любая задача разработки явно содержит элемент нестандартности.
В разработке один программист ревьюит код другого и это считается нормой
У код-ревью больше одной цели. В некоторых конторах ревью используется также в целях гарантии ознакомления хотя-бы одного другого разработчика с этим кодом.
а программированием «всего» каких-то жалких 80 лет. Индустрия еще в зачаточной стадии.
Когда будет решена последняя нестандартная задача — программирование исчезнет как вид деятельности. Вы же не называете программированием использование grep или использование (без написания кода) "визуальных" конструкторов сайтов?
Есть замечательная альтернатива концепциям "жесткие дедлайны" и "отсутствие эстимейтов": на основе эстимейтов и несоответствия реальности планам нужно убирать низкоприоритетные фичи тз бэклога.
Об этом сказано даже в оффициальных доках: you can use React.PureComponent for a performance boost in some cases.
Начнем с того, что пока вроде как не подвезли магических оптимизаций для PureComponent, поэтому PureComponent не может быть быстрее правильно написанного shouldComponentUpdate.
Во-вторых, сама проверка на неизмененность props/state может быть бесполезной в случае, если контейнер этого компонента перерисовывается только тогда, когда перерисовывается этот компонент. Или функция render может быть сама по себе достаточно быстра.
В третьих, вы можете написать свой собственный shouldComponentUpdate, который будет более эффективно отсекать перерисовки.
Считать, что PureComponent обеспечивает лучшее быстродействие, чем Component — неверно.
Считать, что в react есть только jsx — неверно. Что забавно, есть два вопроса: в одном это учитывается, в другом нет.
Функция, которая соединяет react и redux необязательно называется connect. Даже в том же react-redux есть connectAdvanced. А вообще юзер может написать свою функцию, если есть нужда.
По Angular меньше вопросов с реально неправильными ответами.
Сейчас я буду материться. Сука, как же вы заебали, тупорылые ебланы. Ваши говенные тестики нихуя блять не тестируют, они не способны этого сделать. Потому что их составитель умственно отсталая макака. Если вы хотите проверить знание какого-то стека, то проверяйте это, а не в каком году выпустили ебланскую либу. Перед тем как тестировать чьи-то знания сначала проверьте свои знания.
Уфф, высказался. Уж извините, но низкокачественные тесты это большая подстава.
Нет, маленькая команда не сможет сделать сложный продукт, если слово «сложный» имеет смысл «большой». Так вот, маленькая команда не может сделать большой продукт, потому что ресурсы лимитированы.
А сложный в плане «сложный» — да, может, но это не имеет отношения к любому механизму обеспечения модульности.
Обьясните почему вселенных много, а сверхпространство одно? Почему рекурсвное правило "множественность лучше" останавливается у вас всего на уровень выше, а не уходит в бесконечность?
Если вам не нравится аргумент — это не значит, что он плохой. Нельзя доказывать несостоятельность аргумента тем, что он мешает вам делать голословные утверждения
Хотел бы напомнить, что избегаем мы совокупной сложности, а не только видимой.
Для того, чтобы предсказывать мир в рамках мультивселенной нам нужно иметь описание всей мультивсленной (правил её порождающих) +
описание способа идентификации текущей вселенной. Чем больше вселенных, тем сложнее второе.
Зачем вообще это нужно: чтобы избежать overfitting
Теперь ясен пример с Нотчем. Если было действительно так, как вы описывали, это действительно вопрос этики. Хотя странно, что не было договоренностей на этот счёт.
Касательно плохого кода. Дело не в том, какое качество кода. А в том, были ли нарушены чьи-то ожидания. Если покупатель перед покупкой знает, что там говнокодище и многие программисты не будут продолжать над ним работу, то нет этической проблемы.
Дальше, вы весьма неправы касательно state manager. Начнем с того, что в самом Angular уже идёт два механизма отслеживания изменений из коробки: либо на каждый чих, либо OnPush. Первый идеально подходит для случаев, когда не нужно управлять стейтом. Второй является основой для стейт менеджмента, при этом не самого лучшего качества. И да, вы можете подключить redux, ngrx (похоже на redux, но несовместимо с redux), mobx и я не знаю что ещё. Другое дело, что для многих проектов эти вещи не нужны.
Особенных лулзов я ловлю с того, что вы включили в свой список rxjs. По моим ощущением, за пределами Angular он мало кому сдался по объективным причинам.
Особенно жуткие обороты ситуация принимает в связи с тем, что найм сотрудников происходит не заранее, а по ситуации. И это еще сильнее уменьшает возможность нанять хорошего специалиста.
Добавим немного «теории заговора». В рамках аутсорса крупных проектов заморачиваться с наймом нет смысла, потому что тратятся деньги заказчика (а не аутсорс-компании), а аутсорс-компания получает деньги за человеко-часы. И пара неквалифицированных чуваков увеличивает и количество человек, и количество часов (ведь новые десять багов кто-то должен пофиксить). Т.е. аутсорсу (коего дохрена) выгоднее нанимать менее способных специалистов. Ой нет, это не теория заговора, а реальная картина мира.
Вот еще одна забавная вещь. При недостатке квалифицированных кадров очень важны становятся самоконтроль, доброта и терпимость к неквалифицированным кадрам (софт скиллы).
Есть мнение, что команда сварливых звезд способна сделать более хороший продукт, нежели команда дружелюбных людей, которые занимаются неосознанным вредительством в техническом плане.
Например, встречали ли вы людей, которые при фиксе одного бага создают десяток новых?
Драма в том, что оперирование мудаками и идиотами в подобных рассуждениях дает мало представления о том, насколько важно развивать хард и софт скиллы. Такие кейсы показывают только то, что с мудаками и идиотами трудно построить что-то работающее
То, что у вас взгляд скользит — это просто ваш стиль чтения. К примеру, я могу переключаться между чтением по буквам, чтением по словам и сканированием отдельных предложений. Но это требует осознанной концентрации и длится не более пары минут.
Возможно, что вы просто не достаточно сконцентрировались на задаче "читать текст по буквам"
Давайте так: я утверждаю, что brainfuck еще более кастрированный.
Не кажется ли вам странным, что ваше рассуждение не позволяет мне утверждать про кастрированность {uglyLang}, только потому, что другие языки имеют свои слабые стороны?
Или brainfuck — норм язык?
Когда говорят про кастрированность языка очень редко подразумевают "общеупотребимую полноту по Тьюрингу". Обычно эта фраза значит, что существует класс задач, который в этом языке делается через жопу. Вам нужно развернуть определение "делается через жопу"?
Право говоря, мне очень странно видеть, что "отсутствие дженериков как признак урезанности" для кого-то является спорным. Уж извините, но хейтят golang за это давно. У существования дженериков (в других языках) есть определенная причина. И нужно доказывать, что плюсы от удаления дженериков перевешивают минусы. Здесь спорно, что их не реализовали. И вовсе не спорно, что их отсутствие осуждается.
Стандартные способы уже вынесены в ос, фреймворки, библиотеки. Если нет явного NIH (а он на самом деле не так част, как кажется), то любая задача разработки явно содержит элемент нестандартности.
У код-ревью больше одной цели. В некоторых конторах ревью используется также в целях гарантии ознакомления хотя-бы одного другого разработчика с этим кодом.
Когда будет решена последняя нестандартная задача — программирование исчезнет как вид деятельности. Вы же не называете программированием использование grep или использование (без написания кода) "визуальных" конструкторов сайтов?
Есть замечательная альтернатива концепциям "жесткие дедлайны" и "отсутствие эстимейтов": на основе эстимейтов и несоответствия реальности планам нужно убирать низкоприоритетные фичи тз бэклога.
Об этом сказано даже в оффициальных доках: you can use React.PureComponent for a performance boost in some cases.
Начнем с того, что пока вроде как не подвезли магических оптимизаций для PureComponent, поэтому PureComponent не может быть быстрее правильно написанного shouldComponentUpdate.
Во-вторых, сама проверка на неизмененность props/state может быть бесполезной в случае, если контейнер этого компонента перерисовывается только тогда, когда перерисовывается этот компонент. Или функция render может быть сама по себе достаточно быстра.
В третьих, вы можете написать свой собственный shouldComponentUpdate, который будет более эффективно отсекать перерисовки.
Проходил оба теста.
По React:
По Angular меньше вопросов с реально неправильными ответами.
Сейчас я буду материться. Сука, как же вы заебали, тупорылые ебланы. Ваши говенные тестики нихуя блять не тестируют, они не способны этого сделать. Потому что их составитель умственно отсталая макака. Если вы хотите проверить знание какого-то стека, то проверяйте это, а не в каком году выпустили ебланскую либу. Перед тем как тестировать чьи-то знания сначала проверьте свои знания.
Уфф, высказался. Уж извините, но низкокачественные тесты это большая подстава.
А сложный в плане «сложный» — да, может, но это не имеет отношения к любому механизму обеспечения модульности.
Обьясните почему вселенных много, а сверхпространство одно? Почему рекурсвное правило "множественность лучше" останавливается у вас всего на уровень выше, а не уходит в бесконечность?
Вы говорите, что количество вселенных действительно бесконечно. Ни пруфов, ни полезных следствий.
Если я ошибся с пониманием количества вселенных у вас, то попрошу назвать критерий остановки
Если вам не нравится аргумент — это не значит, что он плохой. Нельзя доказывать несостоятельность аргумента тем, что он мешает вам делать голословные утверждения
Хотел бы напомнить, что избегаем мы совокупной сложности, а не только видимой.
Для того, чтобы предсказывать мир в рамках мультивселенной нам нужно иметь описание всей мультивсленной (правил её порождающих) +
описание способа идентификации текущей вселенной. Чем больше вселенных, тем сложнее второе.
Зачем вообще это нужно: чтобы избежать overfitting
Бритва Оккама нынче не в мейнстриме
Потому что супероптимизаторы никто в 21 веке ещё не написал. Немного трудная задача
Теперь ясен пример с Нотчем. Если было действительно так, как вы описывали, это действительно вопрос этики. Хотя странно, что не было договоренностей на этот счёт.
Касательно плохого кода. Дело не в том, какое качество кода. А в том, были ли нарушены чьи-то ожидания. Если покупатель перед покупкой знает, что там говнокодище и многие программисты не будут продолжать над ним работу, то нет этической проблемы.