Какая парадигма языка программирования подходит для этой работы?
Насколько я знаю (мало кто признает), в настоящее время популярными парадигмами программирования являются объектно-ориентированные (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
Как и многие другие, вы можете использовать любой язык для решения любой проблемы, и обычно вы можете писать в стиле одной парадигмы в другой.
Если вы потратите время, чтобы научиться использовать различные парадигмы, поскольку они предназначены, вы узнаете разные вещи о представлении знаний и решении проблем, которые могут быть полезны в любой парадигме, которую вы используете в будущем.
Хотя существует некоторое выравнивание между парадигмами и доменами, обычно лучше выбрать язык, основанный на специфике среды, в которой должно работать ваше программное обеспечение.
- Нужно ли работать на нескольких платформах для настольных компьютеров?
- Если это настольное приложение, оно должно иметь собственный внешний вид?
- Быстрая итерация важных проектов
- Как его поддерживать?
- Для каких сторонних систем необходимо работать с?
- Существующие знания/навыки/предпочтения программиста.