Сообщение Re[5]: Мнение: объектно-ориентированное программирование — к от 11.10.2019 9:14
Изменено 11.10.2019 11:15 Pauel
Re[5]: Мнение: объектно-ориентированное программирование — к
Здравствуйте, scf, Вы писали:
I>>То есть, ООП всех победил и стал королём горы. Радикальные функционалисты с этим не согласны, а потому регулярно радуют эмуляцией известных из ООП паттернов типа Роутер, Медиатор и тд. При этом они любят повторять "смотрите, для ФП не надо никаких паттернов, щас я вам Роутер покажу..."
I>>P.S. Из этого не следует, что ФП не нужно. Проблема исключительно в головах радикальных функионалистов, которые то свои любимые ЯП применяют тотально, вне зависимости от доводов рынка, заказчика, разума.
scf>Спасибо, очень крутой ответ.
scf>Будущее за языками, совмещающими интерфейсы и классы для структурирования, монады для моделирования асинхронных процессов, ФП стиль для вычислений.
scf>(Scala hint hint)
Похоже, только монады и фп как то не приживаются в числодробилках, вместо этого есть и будут другие вещи. Глобально же будущее за языками, которые отвечают одновременно нуждам индустрии и рынка труда. Индустрия это задачи, а рынок труда это люди, квалификация которых в среднем все время падает. Т.е. сейчас в разработку спокойно идут люди, которые еле-еле представляют себе, как написать группировку, но умеют натягивать стили и править конфиги.
Сложность задач в мейнстриме постоянно падает. Именно сложность задач определяет как квалификацию контингента, так и, применяемый язык.
Радикальные функционалисты уверены, что квалификацю определяет N-изученых ЯП — каждый ЯП прибавляет 1..n уровней к квалификации. На самом деле, если задачи не выше группировки по сложности, хоть миллион языков изучи, потолок в квалификации очевиден — решаемые задачи, то есть, группировка.
I>>То есть, ООП всех победил и стал королём горы. Радикальные функционалисты с этим не согласны, а потому регулярно радуют эмуляцией известных из ООП паттернов типа Роутер, Медиатор и тд. При этом они любят повторять "смотрите, для ФП не надо никаких паттернов, щас я вам Роутер покажу..."
I>>P.S. Из этого не следует, что ФП не нужно. Проблема исключительно в головах радикальных функионалистов, которые то свои любимые ЯП применяют тотально, вне зависимости от доводов рынка, заказчика, разума.
scf>Спасибо, очень крутой ответ.
scf>Будущее за языками, совмещающими интерфейсы и классы для структурирования, монады для моделирования асинхронных процессов, ФП стиль для вычислений.
scf>(Scala hint hint)
Похоже, только монады и фп как то не приживаются в числодробилках, вместо этого есть и будут другие вещи. Глобально же будущее за языками, которые отвечают одновременно нуждам индустрии и рынка труда. Индустрия это задачи, а рынок труда это люди, квалификация которых в среднем все время падает. Т.е. сейчас в разработку спокойно идут люди, которые еле-еле представляют себе, как написать группировку, но умеют натягивать стили и править конфиги.
Сложность задач в мейнстриме постоянно падает. Именно сложность задач определяет как квалификацию контингента, так и, применяемый язык.
Радикальные функционалисты уверены, что квалификацю определяет N-изученых ЯП — каждый ЯП прибавляет 1..n уровней к квалификации. На самом деле, если задачи не выше группировки по сложности, хоть миллион языков изучи, потолок в квалификации очевиден — решаемые задачи, то есть, группировка.
Re[5]: Мнение: объектно-ориентированное программирование — к
Здравствуйте, scf, Вы писали:
I>>То есть, ООП всех победил и стал королём горы. Радикальные функционалисты с этим не согласны, а потому регулярно радуют эмуляцией известных из ООП паттернов типа Роутер, Медиатор и тд. При этом они любят повторять "смотрите, для ФП не надо никаких паттернов, щас я вам Роутер покажу..."
I>>P.S. Из этого не следует, что ФП не нужно. Проблема исключительно в головах радикальных функионалистов, которые то свои любимые ЯП применяют тотально, вне зависимости от доводов рынка, заказчика, разума.
scf>Спасибо, очень крутой ответ.
scf>Будущее за языками, совмещающими интерфейсы и классы для структурирования, монады для моделирования асинхронных процессов, ФП стиль для вычислений.
scf>(Scala hint hint)
Похоже, только монады и фп как то не приживаются в числодробилках, вместо этого есть и будут другие вещи. Глобально же будущее за языками, которые отвечают одновременно нуждам индустрии и рынка труда. Индустрия это задачи, сложность которых в среднем снижается, а рынок труда это люди, квалификация которых в среднем все время снижается. Т.е. сейчас в разработку спокойно идут люди, которые еле-еле представляют себе, как написать группировку, но умеют натягивать стили и править конфиги.
Подчеркиваю — сложность задач в мейнстриме постоянно падает. Именно сложность задач определяет как квалификацию контингента. Следствие из этого — соответсвующим образом меняется и применяемый язык.
Радикальные функционалисты уверены, что квалификацю определяет N-изученых ЯП — каждый ЯП прибавляет 1..n уровней к квалификации. На самом деле, если задачи не выше группировки по сложности, хоть миллион языков изучи, потолок в квалификации очевиден — решаемые задачи, то есть, группировка.
I>>То есть, ООП всех победил и стал королём горы. Радикальные функционалисты с этим не согласны, а потому регулярно радуют эмуляцией известных из ООП паттернов типа Роутер, Медиатор и тд. При этом они любят повторять "смотрите, для ФП не надо никаких паттернов, щас я вам Роутер покажу..."
I>>P.S. Из этого не следует, что ФП не нужно. Проблема исключительно в головах радикальных функионалистов, которые то свои любимые ЯП применяют тотально, вне зависимости от доводов рынка, заказчика, разума.
scf>Спасибо, очень крутой ответ.
scf>Будущее за языками, совмещающими интерфейсы и классы для структурирования, монады для моделирования асинхронных процессов, ФП стиль для вычислений.
scf>(Scala hint hint)
Похоже, только монады и фп как то не приживаются в числодробилках, вместо этого есть и будут другие вещи. Глобально же будущее за языками, которые отвечают одновременно нуждам индустрии и рынка труда. Индустрия это задачи, сложность которых в среднем снижается, а рынок труда это люди, квалификация которых в среднем все время снижается. Т.е. сейчас в разработку спокойно идут люди, которые еле-еле представляют себе, как написать группировку, но умеют натягивать стили и править конфиги.
Подчеркиваю — сложность задач в мейнстриме постоянно падает. Именно сложность задач определяет как квалификацию контингента. Следствие из этого — соответсвующим образом меняется и применяемый язык.
Радикальные функционалисты уверены, что квалификацю определяет N-изученых ЯП — каждый ЯП прибавляет 1..n уровней к квалификации. На самом деле, если задачи не выше группировки по сложности, хоть миллион языков изучи, потолок в квалификации очевиден — решаемые задачи, то есть, группировка.