Сколько существует типов языков программирования? [закрыто]

30

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

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

Шова
источник
2
Не лучше ли сказать «Какой тип ..», а не сколько?
Амир Резаи
Что ж, я узнал, что что-то вроде Prolog и C принципиально отличается, поэтому я подумал, что каждый из них соответствует разному виду языка программирования, и я надеялся понять, сколько их видов.
Сова
7
2: тип, который делает то, что вы хотите, и тип, который не делает
Мэтт Эллен
1
Изучение разных типов языков программирования абсолютно конструктивно ! Вы могли бы потенциально утверждать, что это должно быть закрыто как дубликат этого, но я думаю, что они достаточно различны, чтобы остаться отдельными.
Питер Боутон
1
@ Сова, я бы рекомендовал сделать свой первый выбор новых языков, чтобы попробовать что-то, что не использует синтаксис на основе c. Это поможет вам больше сосредоточиться на том, как это работает, и на том, как оно отличается от того, которое вы знаете лучше всего.
Эрик Реппен

Ответы:

73

Это зависит от того, как вы хотите классифицировать языки. По сути, языки можно разбить на два типа: императивные языки, на которых вы указываете компьютеру, как выполнять задачу, и декларативные языки, на которых вы говорите компьютеру, что делать. Декларативные языки могут быть далее разбиты на функциональные языки, в которых программа создается путем составления функций и логики.языки программирования, в которых программа строится с помощью набора логических связей. Императивные языки больше похожи на список шагов для решения проблемы, вроде рецепта. Обязательные языки включают C, C ++ и Java; функциональные языки включают в себя Haskell; Языки логического программирования включают в себя Пролог.

Императивные языки иногда разбиваются на две подгруппы: процедурные языки, такие как C, и объектно-ориентированные языки . Однако объектно-ориентированные языки немного ортогональны группировкам, поскольку существуют объектно-ориентированные функциональные языки (например, OCaml и Scala).

Вы также можете сгруппировать языки, набрав: static и dynamic . Статически типизированные языки - это языки, в которых типизация проверяется (и обычно применяется) перед запуском программы (обычно на этапе компиляции); языки с динамической типизацией откладывают проверку типов до времени выполнения. C, C ++ и Java являются статически типизированными языками; Python, Ruby, JavaScript и Objective-C являются языками с динамической типизацией. Есть также нетипизированные языки, которые включают язык программирования Forth.

Вы также можете группировать языки по дисциплине набора : слабая типизация, которая поддерживает неявные преобразования типов, и строгая типизация, которая запрещает неявные преобразования типов. Границы между ними немного размыты: согласно некоторым определениям, C - это слабо типизированные языки, в то время как другие считают, что он строго типизирован. В любом случае, дисциплина ввода не очень полезна для группировки языков.

mipadi
источник
1
Собирался поставить что-то похожее, но вместо +1 буду добавлять комментарии. Каждая категория или комбинация также имеет множество побочных эффектов, созданных путем сосредоточения внимания на определенных элементах. ООП, например, порождает: ООП на основе прототипов, Аспектно-ориентированное программирование, Программирование на основе компонентов и так далее. Функциональные парадигмы также имеют побочные эффекты, такие как языки, в которых асинхронный процесс или поток является базовым блоком, и вы программируете, составляя параллельные процессы вместе.
CodexArcanum
Как языки сценариев, например, VBScript, вписываются в это? Это может быть немного процедурно и немного ОО, поскольку можно создавать различные типы, так что это сделает его гибридом?
JB King
Это именно то, что я искал. Большое спасибо.
Сова
3
@JB King ООП языки обычно являются процедурными, по крайней мере, в пределах тела метода. Кроме того, распространенным заблуждением является то, что ООП означает «объекты». Многие языки имеют типы данных и объекты. Существует много споров о том, что такое точное определение ООП, но обычно оно включает наследование и / или инкапсуляцию (частное состояние) в качестве основных тем. Язык без того или иного в той или иной форме было бы трудно классифицировать как язык ООП.
CodexArcanum
2
@sova Я могу думать только о двух языках, которые работают примерно так. Erlang в значительной степени основан на параллельной обработке, но если вы хотите больше похожего на то, о чем я говорил, вам стоит взглянуть на Polyphonic C #. Это исследовательский язык (в настоящее время свернутый в C-omega), основанный на Pi-Calculus (например, как FP основан на лямбда-кальке). Pi-calc основан на единице процесса, и вы объявляете процессы и комбинацию синхронных и асинхронных звонит в них. Также посмотрите на стрелки в FP, особенно на Haskell. Стрелки очень похожи на это.
CodexArcanum
12
  • сборочный
  • процедурный
    • основной
    • С
  • Объектно-ориентированный
    • C #
    • Джава
  • декларативный
    • пролог
    • SQL
  • функциональная
    • шепелявость
    • Haskell

Это основные, но есть много других парадигм, и между ними много общего.


источник
Как насчет декларативного (например, Prolog, SQL)?
Брюс Олдерман
@ Брюс, получил их сейчас.
Да, это была общая идея, которую я узнал где-то по пути.
Seseseacat
6
Разве собрание не должно рассматриваться как процедурное?
MattDavey
2
Как насчет конкатенативных (основанных на стеке) языков программирования, таких как Forth и Factor? Вы можете считать это типом функционального программирования, но, вероятно, оно достаточно отчетливо, чтобы заслуживать упоминания. en.wikipedia.org/wiki/Concatenative_programming_language
КЧалу
11

Для типов языков программирования (парадигм), смотрите здесь:
http://en.wikipedia.org/wiki/Programming_paradigm

Для других характеристик языков программирования (например, систем типов), посмотрите здесь: http://en.wikipedia.org/wiki/Programming_language

Роберт Харви
источник
ах! "парадигма", какое доброе слово! спасибо
сова
@sova Я бы принял это как лучший ответ, потому что в ответе на P.SE слишком много парадигм, чтобы перечислить нюансы каждого из них.
Рей Миясака
9

Нажмите на изображение, чтобы увидеть PDF. Постер парадигм программирования

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

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

mmdemirbas
источник
6
  • Процедурные: ассемблер, Java, C #, F #, Lisp, Fortran.

  • Установить на основе: SQL.

  • На основе паттернов: Perl, Regex, Snobol.

  • На основе дерева: XSLT.

  • На основе массива: APL.

Tangurena
источник
2
+1 за использование другого типа классификации, а также за признание того, что «процедурный» фактически содержит большинство классификаций других людей. (конечно, это только означает, что слово имеет очень мало значения, и мясо находится в таких подразделах)
Хавьер
4

Есть разные способы ответить на это, но с точки зрения их можно классифицировать как:

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

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

Язык высокого уровня. В настоящее время большинство программистов используют языки высокого уровня. Такие языки, как C, C ++ и Java, являются языками высокого уровня. Преимущества языков высокого уровня в том, что они очень удобочитаемы и портативны. Недостаток языков высокого уровня заключается в том, что они менее мощны, чем языки ассемблера. Потому что одно утверждение на языке высокого уровня переводится на множество операторов машинного языка.

Языки высокого уровня могут быть далее классифицированы как:

  1. Функциональные языки: в функциональном языке программа делится на определения функций. Функциональные языки являются своего рода декларативным языком. В основном они основаны на типизированном лямбда-исчислении с константами. Некоторые из известных языков Function - это Scala, F #, Clojure и Lisp.

  2. Процедурные языки: В процедурных языках программа написана в виде последовательности шагов, которые необходимо выполнить для получения результата. COBOL, FORTRAN и C являются некоторыми процедурными языками.

  3. Объектно-ориентированные языки программирования. В языках ООП программа делится на объекты, которые содержат данные, а также методы, которые работают с данными. Java, C # и C ++ являются ООП-языками.

  4. Языки программирования логики. Языки логики используются для создания программ, которые позволяют компьютеру логически рассуждать. Например: язык логики

Для углубленного изучения, проверьте:

Badar
источник
3

Я склонен думать с точки зрения особенностей:

Синтаксис:

C-Based или что-у-ты. Java имеет синтаксис на основе языка C. Я настоятельно рекомендую попробовать что-то вроде Python или Ruby, чтобы вывести голову из синтаксиса и больше думать о принципах работы данного языка. Я придерживаюсь мнения, что никакой синтаксис не должен быть более объемным, чем на основе C, и у него нет проблем с компоновкой блоков вокруг пробела.

Скомпилировано и интерпретировано w. Процесс сборки и интерпретация / Консоль:

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

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

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

Динамическая и строгая типизация:

Я склонен рассматривать эти два как компромисс дизайна. Когда вы находитесь на гораздо более низком уровне и производительность критична, статическая типизация имеет большой смысл. Я никогда не понимал этого понятия о том, что одно «безопаснее» другого, но я придумал очень пластичный / динамичный язык, где вы просто изучаете, как работает система набора текста и чего ожидать в принципе. Тип Shenanigans редко беспокоит меня в JS. В некотором смысле гибкость может сделать вещи более надежными, хотя по общему признанию это немного более загадочно для более опытного разработчика младшего уровня, если вы не знаете о некоторых пробелах в языке.

Область действия на уровне блоков и Область функций по сравнению с?

Уровень блоков является наиболее распространенным (что-нибудь между {} в большинстве языков синтаксиса на основе c). Область видимости JavaScript построена вокруг функций (которые также используются для эффективного создания объектов). Существует также много различий в том, какой у вас доступ из внутренней области видимости к внешней. Я не знаком с другими схемами определения объема, но уверен, что они существуют.

Классический ООП против прототипного ООП против почти ООП (структура в C?) Против не ООП:

Даже в ООП на базе классов есть много возможностей для вариаций. Можете ли вы сделать множественное наследование (ew, хорошо в избытке, ew), определить интерфейсы и т.д ...

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

Особенность ООП состоит в том, что на самом деле есть много вещей, которые вы можете извлечь, которые по существу ориентированы на ООП, не будучи технически ООП. Конечно, есть пуристы, но в конце концов, шаблоны проектирования - это достижение определенных абстракций, которые хорошо работают в определенных ситуациях. Не спешите предполагать, что идеи из языка ООП не имеют смысла в чем-то более ориентированном на процедурный процесс. И я не говорю о JavaScript. Он ничуть не ограничен своей глупой версией ООП-парадигмы на основе прототипа.

Первоклассные функции:

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

Затворы:

Я не уверен, где спор о Java, но я знаю, что многие разработчики Java требовали этой возможности год или два назад. В незамкнутом языке, когда функция закрывается, все, что каким-либо образом может ссылаться на что-то изнутри этой функции, не сможет получить к ней доступ, потому что она была собрана сборщиком мусора. В замыкании контекст выполнения ограничен таким образом, что если вы можете ссылаться на вещи внутри этой закрытой функции из другой области видимости, как в возвращенном объекте или функции, вы в основном получаете эти переменные такими, какими они были, когда функция закрывалась. Это похоже на заклинивание ногой в дверях сборки мусора, хотя я подозреваю, что это реализовано больше как копии тех переменных, превращенных в локальные переменные ссылающейся сущности.

Жесткий / Строгий / Безопасный против Дать вам всю веревку, которую вы хотите:

Разработчики JS и Java, как правило, вообще не понимают друг друга, и я думаю, что это во многом связано с двумя языками, которые находятся на почти противоположных сторонах этого конкретного спектра дизайна. Я не хочу, чтобы вы защищали меня от себя или от других разработчиков в моей команде. Я хочу сделать намного больше в гораздо меньшем количестве кода и сделать все это очень разными (но последовательными для данного домена) способами в зависимости от ситуации. Есть оба компромисса, и многие языки имеют тенденцию падать в середине.

Эрик Реппен
источник
Ну и дела спасибо. Это действительно приятно пройти усилие для голосования без объяснения причин.
Эрик Реппен
2

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

Существует множество «видов» языков, но всегда могут появиться новые. По сути, цель языка - разрешить как можно более прямое кодирование идей, концепций или требований. С этой целью могут быть ситуации, когда существующие парадигмы не нужны, и может потребоваться новая.

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

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

Другая полезная точка зрения состоит в том, что каждый раз, когда проектируется структура данных, рождается язык. Данные «выполняются» прикладными программами, которые прочесывают их и что-то делают, точно так же, как программа - это просто набор данных (например, байтовые коды), которые используются интерпретатором для выполнения каких-либо задач.

Майк Данлавей
источник
Круто. Я выучу LISP и буду просветленным. Волнующий: D
Сова
Однако, если вы скажете, что использование структуры данных создает новый промежуточный язык, вы также можете утверждать, что в каждом алгоритме рождается новый язык (все операции обязательно выполняются над структурой данных), а с сокращением - новый язык. рождается в каждой строке кода. Я думаю, что вы имеете в виду что-то еще, но я не совсем уверен, что понимаю еще?
Сова
@sova: Для меня теория информации была большим откровением (и Шеннон, и Колмогоров). О том, как значения кодируются и передаются по каналам, с понятиями пропускной способности, обнаружения ошибок, минимального кодирования, случайности и т. Д. Итак, данные кодируют информацию, а алгоритмы - это каналы. Программы кодируют информацию, а программирование - это канал. Итак, какая информация закодирована? откуда и когда? куда это идет? Каковы источники ошибок (шум)? как они исправлены? Я нашел это полезной точки зрения.
Майк Данлавей
@sova: (продолжение) Вам не нужно осваивать всю математику. Для меня то, что имело значение, было структурой, которую это дало мне, чтобы думать о вещах.
Майк Данлавей
1

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

Дейв
источник
Я помню это. Возможно, я даже использовал это. Мальчик, это было современно. Вам не нужно было вручную направлять фрезерный станок, просто нажмите кнопку запуска. И если бы была ошибка, весь ад вырвался бы на свободу.
Майк Данлавей
Я работал над программами, которые генерируют gcode для фрезерных станков. Я буквально держал и видел результаты ошибок программирования, часто мои.
Дэвид Торнли
Я потратил 20 лет на установку постпроцессоров на системы.
Дейв