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

Question

Насколько я знаю (не так много, я признаю), в настоящее время популярными парадигмами программирования являются объектно-ориентированные (Java, C #, Ruby) и функциональные (F #).Как у человека, который в основном знаком с первой парадигмой, у меня есть несколько вопросов:

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

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

Answer 1

"Или, другими словами, можно ли свести все проблемы к гвоздям для одного молотка?" ДА.Точка.Любой язык программирования, с которым вы, скорее всего, столкнетесь, будет таким же полным, как и все остальные.На самом деле существует формальное определение "полноты" для языка программирования.

"Приходилось ли людям когда-нибудь осваивать новую парадигму?" Всегда.

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

Я заметил следующее...

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

Модель отношений сущностей изначально предназначалась для представления знаний, а не для бизнес-транзакций.Объектная модель, аналогично, предназначалась для представления знаний.Затем специалисты по моделированию нашли это.Теперь это есть у всех нас.

Вот мой вывод.

Программное обеспечение - это Представление знаний.

Ваш выбор Парадигмы, или Модели, или Подхода, или Стиля основан на ответе на следующий вопрос:

"Как я могу наилучшим образом представить Эту проблему?"

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

Answer 2

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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

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

Answer 5

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

Answer 6

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

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

OO значительно облегчает понимание больших объемов кода.Если у вас большая команда или несколько больших команд и вам нужно быстро дать обзор, OO значительно упрощает описание и выделение заданной части функциональности.Я должен сказать, ПРАВИЛЬНО ЗАКОДИРОВАННЫЙ OO!

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

Answer 7

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

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

Answer 8

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

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

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

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