Какая парадигма языка программирования подходит для какой работы?

стоит изучить альтернативные парадигмы (OO, функциональные, процедурные, динамические и т. д.), Потому что это поможет вам думать о проблемах по-разному.

например, подумайте о разнице в решении обхода дерева линейным способом (первый способ, которым я это сделал) по сравнению с использованием рекурсии. Или комбинация Google Map и Reduce, чтобы помочь им индексировать интернет.

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

парадигма не зависит от языка. Вы можете развиваться в стиле OO в C (взгляните на GTK). Когда я программирую на Java, я использую в основном функциональный стиль.

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

в качестве (тривиального) примера сравните реализации quicksort в Java и Ocaml или, еще лучше, Haskell на этой странице: http://www.rosettacode.org/rosettacode/w/index.php?title=Quicksort

(Это не означает, что функционал лучше. Есть проблемы, которые лучше решить с помощью OO).

можно все проблемы уменьшить к ногтям для одного молотка?

Err да. Проблемы можно решить одним молотком. Его просто распиливание этой двери пополам занимает гораздо больше времени.

людям когда-нибудь нужно было изучать новую парадигму? Для моих прошлых двух заданий моим рабочим местам требовались Java и C#. Существуют ли рабочие места, которые специально используют языки, отличные от OO?

разработчики должны делать это каждые 15-20 лет или так.

существует, безусловно, целая индустрия небольших компаний с системами, основанными на доступе, написанными с процедурным VBA. (и я думаю, что работал на большинство из них). Классические разработчики ASP должны учиться ASP.NET - ... Разработчики Perl изучают Python. Партия развития сменился событиями развития.

Я думаю, что вы найдете ответы на все доски. Чем больше я работаю, тем больше я нахожу, что "полезно" знать некоторых других. как разработчик C#/VB/SQL Server, я считаю более полезным для меня узнать немного о F# и некоторых других языках, чтобы просто получить широкую экспозицию, чтобы действительно выяснить, какой инструмент является правильным...

динамический материал пугает меня до чертиков, но Ruby on Rails-лучшая система разработки, которую я видел для веб-материалов. Я не чувствую себя комфортно с использованием его для действительно большого, тяжелого проекта обслуживания, хотя, потому что слишком легко изменить смысл существующего, скомпилированного, готового кода. Также слишком легко для стиля кодирования одного человека, чтобы превратить его в новый язык.

Dynamic / scripting также полезно знать для системных администраторов и всех, кто работает в системе Linux. Написание быстрого скрипта в BASH или Ruby бьет по аду, пытаясь реализовать ту же функциональность в Java или c++.

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

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

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

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

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

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

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

• нужно ли запускать его на нескольких настольных платформах?
• если это настольное приложение, нужно ли ему иметь собственный внешний вид?
• быстрая итерация конструкций важна
• как его поддерживать?
• С какими сторонними системами ему нужно работать?
• существующие знания программиста / навыки / предпочтения.