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

Question

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

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

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

Answer 1

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

"Людям когда-нибудь нужно было изучать новую парадигму?" Всегда.

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

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

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

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

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

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

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

«Как мне лучше всего представить эту проблему?»

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

Answer 2

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

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

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

Answer 3

Парадигма не зависит от языка. Вы можете разрабатывать в ОО стиле в 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!

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

Answer 7

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

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

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

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

Answer 8

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

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