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

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

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

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

ОТВЕТЫ

Ответ 1

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

"Нуждались ли люди в изучении новой парадигмы?" Всегда.

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

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

Ответ 4

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

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

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

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

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

Ответ 5

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

Ответ 6

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

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

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

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

Ответ 7

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

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

Ответ 8

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

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

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

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