Чому так багато мов програмування?


130

Я досить добре володію C / C ++ і можу обійтись різними мовами сценаріїв (awk / sed / perl). Я почав використовувати python набагато більше, тому що він поєднує в собі деякі найтонші аспекти C ++ з можливостями сценарію awk / sed / perl.

Але чому так багато різних мов програмування? Я здогадуюсь, що всі ці мови можуть робити те саме, то чому б не просто дотримуватися однієї мови і не використовувати її для програмування комп'ютерів? Зокрема, чи є якась причина, що я повинен знати функціональну мову як комп'ютерний програміст?

Деякі пов'язані читання:


2
також існує різниця між ОО та не-ОО. Крім того, деякі мови постачаються з приємними пакунками: R, Maple, Matlab, Mathematica, яких часто не вистачає в інших мовах.
Артем Казнатчеєв


4
Вже запитайте про програмістів programmers.stackexchange.com/q/7551/45322
alain.janinm

2
Для реалізації паралельних алгоритмів функціональне програмування краще, загалом, коли у вас є змінні об'єкти, краще використовувати парадигму OO, інакше (якщо ви хочете мати справу з незмінними об'єктами), краще змінити її на функціональну модель. Цей сценарій широко існує при паралельній обробці. Також деякі чудові моделі OO, такі як вільний інтерфейс та методологічне ланцюжок , працюють як функціональна парадигма.

4
Чому так багато машин? Чому так багато літаків? А що з човнами! Я маю на увазі, справді! Ви спускаєтесь до океану, і там, начебто, всі ВИДИ речей! Який сенс у всіх цих різних речах?!?!? Це неефективно! Це марно !! І який сенс у всіх цих різних виборах ?!?!? Гез - мудрі люди! Ніхто нічого не міг би потребувати, крім Юго, F-150 та океанічного лайнера! О так, літаки - MD-80 працюватимуть добре для всього. Там. Тепер, коли це все врегульовано ... :-)
Боб Джарвіс,

Відповіді:


116

Мови програмування розвиваються та вдосконалюються з часом (інновації).

Люди беруть ідеї з різних мов і поєднують їх у нові мови. Деякі функції вдосконалюються (механізми успадкування, системи типів), деякі додаються (збирання сміття, обробка винятків), деякі видаляються ( gotoзаяви, маніпуляції з покажчиком низького рівня).

Програмісти починають використовувати мову певним чином, що не підтримується жодними мовними конструкціями. Мовні дизайнери ідентифікують такі схеми використання та вводять нові абстракції / мовні конструкції для підтримки таких моделей використання. У мові складання не було жодних процедур. Немає занять у C. Не є винятком обробка в (ранньому) С ++. Немає безпечного способу завантаження нових модулів на ранніх мовах (просто на Java). Немає вбудованих потоків (легко-гороховий на Java).

Дослідники думають про альтернативні способи вираження обчислень. Це призвело до Lisp та функціональної мовної гілки дерева мов, Prolog та гілки логічного програмування, Erlang та інших моделей програмування на основі актора, серед інших.

З часом мовні дизайнери / дослідники краще розуміють усі ці конструкції та те, як вони взаємодіють, і розробити мови для включення багатьох популярних конструкцій, усі вони розроблені для безперебійної роботи разом. Це призводить до отримання чудових мов, таких як Scala, в якій є об'єкти та класи (виражені за допомогою ознак замість одинарного чи множинного успадкування), функціональні функції програмування, алгебраїчні типи даних, що добре поєднуються з системою класів та узгодженням шаблонів, і одночасністю одночасності.

Дослідники, які вірять у системи статичного типу, прагнуть покращити свою виразність, дозволяючи такі речі, як набрані загальні класи на Яві (і всі чудові речі в Haskell), так що програміст отримує більше гарантій перед запуском програми, на яку речі не збираються піти не так. Системи статичного типу часто накладають велике навантаження на програміста (введення типів), тому дослідження пішли на полегшення цього навантаження. Такі мови, як Haskell та ML, дозволяють програмісту опускати всі анотації типу (якщо вони не роблять щось хитро). Scala дозволяє програмісту опускати типи в тілі методів, щоб спростити роботу програміста. Компілятор виводить усі відсутні типи та інформує програміста про можливі помилки.

Нарешті, деякі мови створені для підтримки конкретних доменів. Приклади включають SQL, R, Makefiles, мову введення Graphviz, Mathmatica, LaTeX. Інтегрування функцій цих мов у мови загального призначення (безпосередньо) було б досить громіздким. Ці мови засновані на абстракціях, характерних для їх конкретного домену.

Без еволюції в розробці мови програмування ми все ще використовуємо мову асемблера або C ++.

Що стосується знання функціональної мови програмування : функціональні мови дозволяють виражати обчислення по-різному, часто більш стисло, ніж використання інших мов програмування. Подумайте про різницю між C ++ та Python та помножте його на 4. Більш серйозно, як уже згадувалося в іншій відповіді, функціональне програмування дає вам інший спосіб думати про проблеми. Це стосується всіх інших парадигм; деякі краще підходять для деяких проблем, а деякі - ні. Ось чому багатомовні парадигми стають все більш популярними: ви можете використовувати конструкції з іншої парадигми, якщо вам потрібно, не змінюючи мови, і, що ще складніше, ви можете змішувати парадигми в межах одного програмного забезпечення.


1
Повністю згоден. Мене цікавить, де через кілька років будуть багатомовні парадигми (наприклад, Scala). Якщо вони дозволяють легко інтегрувати DSL, ми можемо насправді спостерігати поступове зменшення кількості мов.
Рафаель

2
Дуже детальна відповідь! Ми можемо визнати, що більшість мов програмування можуть бути еквівалентними Тьюрінгами, але це не означає, що абстракція, яку вони підтримують, підходить для кожної проблемної області.
CyberFonic

Поставлення збірки та C ++ в одну скриньку болить моє серце. C ++ значно розвинувся !! Спеціально з C ++ 11 і вперед.
Peregring-lk

66

tldr: Немає срібної мови кулі.

Я сподіваюся, що вони не будуть судити мене, але ось малюнок з однієї зі презентацій Стенфорда.

введіть тут опис зображення

Вирішивши вибрати мову, ви можете вибрати лише 2 з цих 3 функцій .

І тому люди сумні і хочуть вигадати надмову, яка охопить усі 3 з них.

Насправді існує величезний перелік вимог (деякі з них ви можете побачити в інших відповідях), але вони просто додають деталі до основних функцій. Крім того, є історичні та політичні причини віддати перевагу одній мові перед іншою.

Поєднання таких факторів дають нову мову.

( І я чув, що кожен хороший програміст повинен скласти свою нову мову;) )


11
З часом трикутник скорочується, в тому сенсі, що кути зближуються ..... Сподіваюся / мрію.
Дейв Кларк

1
Продуктивність та загальність, можна порівняти більше, але я додам, що досвід мови дає вам більшу продуктивність, ніж певна мова, не справедливо порівнювати лише "продуктивність мов", тому що вам потрібно припускати знання та досвід всі вони, дуже малоймовірна гіпотеза.
Hernan_eche

Це цікаве твердження і свого роду нагадує мені теорему CAP. Це лише неофіційна аргументація чи можна довести трикутник?
evnu

1
@evnu, ось квазіформальний аргумент однієї частини: якщо припустити загальність означає, що дійсні програми будь-якої довжини n мовою L охоплюють більший проблемний простір, кожен підпростір проблем охоплюється лише деякими дробами довжини n програм. Якби програми довжиною n поза вашим конкретним підпростором були замість цього у вашому підпросторі, ви мали б більший шанс знайти більш коротку програму, яка вирішила б вашу проблему (так що, можливо, ви будете більш продуктивними), але мова буде менш загальною, - він би вирішив проблеми в інших підпросторах менш добре (тобто з більш тривалими програмами).
Йонас Келькер

Це хороший аргумент, що вам потрібно щонайменше дві мови програмування, а також велика кількість мов, орієнтованих на домен, таким чином охоплюючи всі три сторони трикутника. У нас є багато, багато, багато іншого. (І я поставив с у верхній вершині трикутника, але це досить невеликий нігтя.)
Пітер Шор

25

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

  • Хтось вважає, що вони можуть покращити існуючі продукти
  • Інша конструкція зумовлена ​​місцевими міркуваннями (подумайте: будинки на ходулях проти будинків на бетонних плитах)
  • Нова категорія товару задовольняє потребу там, де раніше не існувало жодного

Зайдіть у будь-який магазин офісних товарів і подивіться на розділ «інструмент для письма» - там сотні різновидів ручок. Всі вони роблять приблизно те ж саме: доставляють чорнило на поверхню письма. Але кожна ручка, яку ви бачите, виставлена ​​на продаж, є тому, що одна з трьох вищезгаданих причин.

  • Патронні авторучки - це поліпшення на авторучках, які є крапками, які самі по собі є покращенням пір'яних олівців.
  • NASA була потрібна ручка, яка могла писати за відсутності сили тяжіння, тому була придумана ручка з роликовим колом під тиском.
  • Сама перша ручка, можливо, була загостреною паличкою, змоченою у дьогті чи крові; до цього люди розчісували скелі разом або розмазували пігменти по стінах хутром. (Лише здогадка.)

Еволюція ручок триватиме, оскільки жоден продукт не відповідає потребам кожного користувача. Деякі ручки дешеві та одноразові, деякі - дорогі та побудовані з високоякісних матеріалів; деякі використовують гелі, деякі використовують чорнило, деякі використовують пігменти; у деяких є кришки, що відкручуються, у деяких немає кришок; широкі бочки, вузькі бочки, круглі бочки, квадратні бочки; короткий, довгий; червоний, білий, чорний, синій. І т.д.

Але досить про ручки.

Наші нинішні безлічі мов програмування можна простежити до найперших: чисельних машинних кодів для ранніх комп'ютерів ще в 40-х роках. Примітивні, важкі у використанні та трудомісткі, щоб увійти в комп’ютер, але вони зробили свою роботу. Невдовзі програмісти призначили мнемічні слова (такі як ADD, CALL, LOAD) до машинних кодів, народжуючи клас мов, який називають "мовою збірки".

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

(Можливо, до цього часу ви можете бачити, куди це йде ...)

Програмісти переглянули свої програми мов асемблери та побачили шаблони: ті самі послідовності інструкцій будуть використовуватися для формування циклів, умовних умов, призначення змінних, викликів функцій тощо. Таким чином, народилися мови процедурного програмування. Ці мови складають групи вказівок під парасольковими умовами, такими як "якщо", "в той час", "нехай" тощо.

З математичного аналізу комп’ютерного програмування вийшли функціональні мови - зовсім новий спосіб погляду на обчислення. Не краще, не гірше, просто різне.

А потім є об'єктно-орієнтовані, статично типізовані, динамічно набрані, пізні зв'язування, раннє зв’язування, низьке використання пам’яті, велике використання пам’яті, паралелізація, мови для конкретних цілей використання тощо.

Зрештою, у нас є різні мови програмування, оскільки ми хочемо різних мов програмування. У кожного мовного дизайнера є свої уявлення про те, як буде виглядати та діяти їхня мова «мрії». Різноманітність - це добра річ.


Я не бачу тут жодної переконливої ​​причини, чому ми повинні мати кілька мов, крім того, з яких людей хочуть з будь-яких причин.
Рафаель

Саме так. Програмісти за своєю природою вирішують проблеми. Для вирішення проблем їм потрібні інструменти, які часто мають форму мов програмування. Якщо інструменти не можуть допомогти їм вирішити проблему, яку вони хочуть, вони вигадують нові інструменти. Подумайте про це так: оскільки інструменти програмні, а нове програмне забезпечення написане для вирішення нових проблем, самі інструменти можуть бути проблемами, які потрібно вирішити. Ці проблеми вирішуються шляхом створення нових інструментів.
Баррі Браун

Лише одна нитка: Функціональна галузь мов є коротким уявленням математика про те, як виразити те, що ми сьогодні називаємо "обчислення", що почали вважатись за 50 років до появи перших комп'ютерів. Недаремно LISP (у якійсь формі) є другою найдавнішою мовою, яка все ще існує, першою є FORTRAN.
фонбранд

20

Мови функціонального програмування зазвичай базуються на різній (але еквівалентній за потужністю) моделі обчислення: лямбда-числення . Існують деякі нетипізовані (мають типу Python типу введення) такі мови, як LISP, Scheme (використовується у широко розпізнаваній структурі та інтерпретації книги / курсу комп'ютерних програм ) та статично типізовані мови, такі як Haskell, ML, F #.

SICP - це те, що мене задіяло у функціональному програмуванні, але інші люди рекомендують цей документ Джона Х'юза та це інтерв'ю з ним.

Наприклад, Microsoft насуває функціональне програмування, яке включило F # (свою функціональну мову для .NET) у VS2010 та 11; вони також використовують деяких розробників Haskell в MSR, IIRC.

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

Оскільки рівень абстракції у функціональних мовах різний, ваше ставлення до вирішення проблем змінюється, коли ви використовуєте методи функціонального програмування. Деякі кажуть, що це може зробити вас кращим програмістом.


1
Ще один цікавий клас мов - це мови логічного програмування, такі як Prolog. У мене був дуже обмежений досвід роботи з DataLog, тому, можливо, хтось ще міг написати відповідь на це?
Даніїл

2
Я згоден, що нам потрібна мова програмування для кожної парадигми програмування: імператив, ОО, декларативний, функціональний тощо. Але це не пояснює, чому у нас так багато мов, наприклад, ОО.
Дай

@Dai, ну, чи справді ми? Теоретична основа - не єдина характеристика мови. Наприклад, можна сказати, що ключовою особливістю Java або C # є (порівняно з C ++) віртуальна машина, завдяки чому Java значно відрізняється.
Даніїл

Але тоді, якщо C # і Java використовують концепцію віртуальної машини, чому б ми не використали однаковий синтаксис для обох мов? Я думаю, що кожен дизайнер має свої сильні уявлення про те, як повинна виглядати його мова та має тенденцію до створення свого власного стандарту.
Дай

@Dai, зрештою, між C # і Java існує багато незначних відмінностей. Плюс до цього, я думаю, що існувала певна суперечка з приводу Java VM для Windows або щось подібне.
Даніїл

19

Зокрема, чи є якась причина, що я повинен знати функціональну мову як комп'ютерний програміст?

Так. Тому що haskell змінив те, як я думаю. Це може змінити і те, що ви думаєте.

Історія: Раніше я думав, що я можу вивчити будь-яку мову програмування за день. Одного разу я запустив Haskell. Я закінчив усе, що було перед монадами за пів дня. Зараз минув рік з цього дня, і я все ще безнадійно застряг у Монадах.

Прочитайте:

  1. Мови та думки вікі

  2. Позначення як інструмент для думки Кеннет Е. Іверсія, лекція премії Тюрінга

Але чому так багато різних мов програмування?

Позначення є інструментом для думки. Нам потрібні різні індивідуальні позначення, щоб зручно працювати з різними думками. Таким чином ми створюємо нові мови.

Також читайте . ;-)


5
Повторити - це божественно!
Pratik Deoghare

4
Ітерація є людиною?
Суреш

1
Не впевнений, чи це була гарна реклама для Haskell. ;)
Баррі Браун

@Pratik Deoghare. Навчання Хаскеллу за день було, мабуть, недоброю ідеєю. Я б сказав, прочитайте хорошу книгу з текстами з функціонального програмування, таких як Bird and Wadler, і не витрачайте на це час. Тоді монадам може бути не так складно.
Удай Редді

"Я закінчив усе, що було перед монадами за півдня". Дійсно? Ви навчилися типових класів, функторів, ADT, видів тощо за півдня? Це неможливо. LYAH має монади в 12-му розділі з 14. RWH не має монад до 6-го розділу, і вони вводяться дуже поступово - повне визначення в розділі 14.
sdcvvc

13

Навряд чи може бути програміст, який би в якийсь момент не засмутився обмеженнями мови, якою вони користуються, і вирішив почухати свербіж. Таким чином, народжується нова мова - або діалект існуючої.

Абаді та Карделлі в "Теорії об'єктів" розробляють цілу сім'ю мов програмування з об'єктно-орієнтованих основ. Вони доводять, що функціональне програмування є особливим випадком ОО, але не навпаки.

Винаходити щось нове - це цікаво, тому люди швидше створюють ще одну мову, ніж сприяють покращенню існуючої. Звичайно, є зберігачі мов, які не вітають змін у своєму баченні. Найкращий приклад - прірва між прихильниками Common Lisp та Scheme.


3
"Теорія об'єктів" не містить цілого сімейства мов програмування. Він являє собою основу для об'єктно-орієнтованих мов програмування, і дивний на тому, що не базується на класах. Я не бачу зв'язку між "Теорією об'єктів" та функціональним програмуванням. Об'єктні калькуляції, наприклад, не мають поняття лінь. Існує також дослідження, що кодують поняття ОО з точки зору функцій та записів, наприклад, робота Пірса в кінці 90-х.
Дейв Кларк

12

Оскільки інші вже дали хороші відповіді на це питання, я просто цитую Алана Перліса.

Остерігайтеся турирувальної смолистої ями, в якій все можливо, але нічого цікавого легко.

Крім того, http://weblog.raganwald.com/2004/10/beware-of-turing-tar-pit.html є хорошим прочитанням.


11

Чому в світі так багато країн? Чи не було б простіше, якби ми просто мали 5 чи 6 наддержав чи навіть одне універсальне царство Землі? Легко сперечатися, чому не було б краще --- для початку конкуренція різних країн може призвести до прогресу, і з точки зору демократії, прав людини тощо, багато країн можуть бути кращими за одну - - але це не пояснює, чому у нас багато країн. Це лише пояснює, чому багатьом країнам було б краще .

Так само ви можете запитати, чому так багато різних людських мов? Польська, арабська, мандаринська ... Чи не було б простіше, якби була лише одна мова? Ви можете сперечатися в будь-якому випадку, але це були б причини, чому було б краще, якби життя було так чи інакше. Це не пояснить причин, за якими стоїть так багато різних людських мов.

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

Прочитайте цю найяскравішу публікацію в блозі, чому так багато веб-фреймів Python? Мабуть, в Python існує близько 50 веб-фреймів. Це просто смішно; немає абсолютно розумної раціональної причини для цього. Але автор публікації відповідає: існує так багато веб-рамок Python, оскільки створити її так просто . Вам не потрібна раціональна причина для того, щоб було більше веб-фреймовок python або більше мов програмування. Люди продовжуватимуть створювати нові, бо не знають, що вже є, або тому, що сподіваються, що вони зможуть заробити гроші, або просто тому, що створювати нові речі - це цікаво!

Дозвольте описати особистий приклад. Близько 10 років тому я писав якийсь код C ++ для фінської компанії. Ви знаєте, у Фінляндії є величезні вантажівки, які, ну, їздять на далекі відстані і доставляють багато предметів з одного місця в інше. Я впевнений, такі вантажівки є і в Америці. Тому типовою проблемою є переконання, що всі 24 або більше шин добре. Звичайно, є перевірена часом технологія: тиск і температуру можна відстежувати, а різкі зміни вказують на те, що щось пішло не так. Звичайно, вся ця технологія є власною, запатентована, з усіма наслідками. (Пам'ятайте: патенти повинні сприяти інноваціям!) Тож ця фінська компанія хотіла виявити стан шин за допомогою ... звуку. Ідея полягала в тому, щоб встановити мікрофони для прослуховування звуку, що виходив з усіх шин, і зробити якусь магію обробки сигналів на цих звуках, щоб побачити, чи є у однієї з шин якась проблема, і я робив прототип цього безумства. (У них навіть була виділена спеціальна лабораторія для запису зразкових звуків; одного разу вони надіслали мені вражаючий відеозапис конкретного випадку, коли їм вдалося підірвати зразкову шину, піддавши її тиску 5 або 10 тонн і нагрівши її до якоїсь смішної температури .) Зрозуміло, знову ж таки, не було особливої ​​раціональної причини цього розвитку, за винятком того, що це було весело і дехто хотів заробити гроші. Тож також розумійте, що є так багато причин, чому хтось почав би розробляти нову мову програмування. Немає потреби чи навіть можливості вивчити їх усі. (У них навіть була виділена спеціальна лабораторія для запису зразкових звуків; одного разу вони надіслали мені вражаючий відеозапис конкретного випадку, коли їм вдалося підірвати зразкову шину, піддавши її тиску 5 або 10 тонн і нагрівши її до якоїсь смішної температури .) Зрозуміло, знову ж таки, не було особливої ​​раціональної причини цього розвитку, за винятком того, що це було весело і деякі люди хотіли заробити гроші. Тож також розумійте, що є так багато причин, чому хтось почав би розробляти нову мову програмування. Немає потреби чи навіть можливості вивчити їх усі. (У них навіть була виділена спеціальна лабораторія для запису зразкових звуків; одного разу вони надіслали мені вражаючий відеозапис конкретного випадку, коли їм вдалося підірвати зразкову шину, піддавши її тиску 5 або 10 тонн і нагрівши її до якоїсь смішної температури .) Зрозуміло, знову ж таки, не було особливої ​​раціональної причини цього розвитку, за винятком того, що це було весело і дехто хотів заробити гроші. Тож також розумійте, що є так багато причин, чому хтось почав би розробляти нову мову програмування. Немає потреби чи навіть можливості вивчити їх усі. одного разу вони надіслали мені вражаючий відеозапис про певний випадок, коли їм вдалося підірвати зразкову шину, піддавши її тиску 5 або 10 т і нагрівши її до якоїсь смішної температури. Причина такого розвитку, за винятком того, що це було весело і деякі люди хотіли заробити гроші. Тож також розумійте, що є так багато причин, чому хтось почав би розробляти нову мову програмування. Немає потреби чи навіть можливості вивчити їх усі. одного разу вони надіслали мені вражаючий відеозапис про певний випадок, коли їм вдалося підірвати зразкову шину, піддавши її тиску 5 або 10 т і нагрівши її до якоїсь смішної температури. Причина такого розвитку, за винятком того, що це було весело і деякі люди хотіли заробити гроші. Тож також розумійте, що є так багато причин, чому хтось почав би розробляти нову мову програмування. Немає потреби чи навіть можливості вивчити їх усі.

Звичайно, все це стосується лише, якщо вірити в еволюцію. Якщо ви вірите в якусь форму розумного дизайну, що Бог також створив усі мови програмування, то вам доведеться знайти мету, що стоїть перед цією сукупністю. Можливо, Бог хотів сприяти конкуренції між різними мовами програмування, щоб мистецтво розробки програмного забезпечення досягло найвищого рівня.

На закінчення є багато людей, багато країн, багато мов програмування. Це просто природа життя! Будемо вдячні за це: це просто означає, що сфера програмування / інформатики дуже жива і процвітає.


дуже досконала відповідь, я не знаю, чому її не прийняли!
Am_I_Helpful

8

Чому існує так багато різних мов програмування?

Тому що є вибір:

  • Режим специфікації: Імперативний та функціональний
  • Введення тексту: статично набрано та динамічно набране
  • Порядок оцінювання: call-by-value vs. call-by-name
  • Модульність: на основі класу проти абстрактних даних
  • Модель виконання: послідовна проти паралельної

На щастя, останні два - це несуттєві дихотомії, тобто можна обидва варіанти викласти в одну мову програмування. Але, перші три дихотомії дають 8 комбінацій. Так, навіть в ідеальному світі було б як мінімум 8 мов програмування. Коли ви деталізуєте, в майбутньому з'являються додаткові нюанси дизайну в певних парадигмах. Наприклад, якщо хтось вирішив зробити на основі класу статичну типізовану мову, існують різні способи проектування системи типів. Ще не існує канонічного способу це зробити. Якщо хтось вирішить використовувати паралельну мову програмування, існують різні способи представлення одночасності: семафори, умовно-критичні області, монітори, передача повідомлень (синхронний проти асинхронного). У межах синхронного передавання повідомлень,

Частина досліджень, які ми проводимо в теорії мови програмування, присвячена вирішенню цих дихотомій. Наприклад, я працював над вирішенням дихотомії між імперативним та функціональним програмуванням у статті під назвою " Призначення мов додатків ", і наш метод зараз був прийнятий Haskell, що робить його як функціональною, так і імперативною мовою. Це не означає, що дихотомія повністю вирішена. Програміст Haskell все ще стикається з вибором, чи вирішити свою проблему функціонально чи імперативно. Лука Карделлі працював над вирішенням дихотомії статичного проти динамічного типізації. Пол Леві працював над тим, щоб вирішити дихотомію "за вартістю" проти "заклик за іменем" . Не всі ці результати ще не реалізовані на мовах програмування в реальному житті.


Якщо всі ці мови можуть робити те саме, чому б не просто дотримуватися однієї мови і не використовувати її для програмування комп'ютерів?

Тому що для програміста в реальному світі недостатньо просто щось зробити. Також важливо, як це робиться. Якщо це зроблено належним чином, проблемний домен відображається вірно в програмі, модульність проблеми зберігається, а програми стають легко зрозуміти, модифікувати та підтримувати. Всі ці речі впливають на вартість розробки та обслуговування програми. Вони також впливають на надійність та безпеку програмного забезпечення.

Наприклад, багато людей використовують програму під назвою " Quicken " для фінансових рахунків. Оригінальна програма була розроблена в деякій внутрішній версії Visual Basic, і це було досить непогано. Однак розширити і підтримувати його було важко. З роками, коли компанія намагалася розширити її для нових можливостей, програма все частіше буяла з мільйонами незадоволених клієнтів скрізь. Вони, ймовірно, отримають користь від перепроектування програмного забезпечення на чітко набраній об'єктно-орієнтованій мові програмування.


Зокрема, чи є якась причина, що я повинен знати функціональну мову як комп'ютерний програміст?

Історично "функціональне програмування" було винайдено Годелем, Кліном і Церквою після стандартної математичної практики, а "імперативне програмування" було винайдено Тьюрінгом, щоб закріпити поняття механічних обчислень. До Тьюрінга не існує жодних доказів того, щоб математика ніколи не аналізувала імперативні ідеї програмування. (Хоча всі традиційні математичні алгоритми висловлювались в «імперативному стилі», їх основний зміст все ще функціонував.) Отже, імперативне програмування є дуже новим для людської цивілізації, і його математика ще не дуже добре вивчена. Причиною №1, чому всі повинні знати деякі функціональні програми, є розуміння того, як програмування може бути математичним. (Я не визнаю, що імперативне програмування не є математичним, в що ви б повірили функціональним програмістам. Але я погодився б, що при сучасному стані ми ще не знаємо, як зробити імперативне програмування математично. Багато з нас працюють саме над цією проблемою.)


1

Ви можете поглянути на це як на еволюцію.

На початку комп’ютери були запрограмовані суто з двійковими кодами. Після цього були введені мнемоніка та введені мови складання, в основному залежать від використовуваного процесора.

Після цього були введені мови вищого рівня (3-й рівень) (Pascal, C, ADA, Cobol), деякі дуже загальні (наприклад, C), деякі більше підходять для обробки даних (Cobol), деякі для розрахунків (Fortran).

Після цього виникли мови четвертого рівня, подібно до логічних мов (як Prolog). Найбільш загальні мови є наступниками мов третього рівня; деякі з них - Java, C #.

Ми також бачимо мови, специфічні для Інтернету / Інтернету, як ASP.NET, PHP.

І мови для певного домену (DSL), які в основному працюють разом із загальною мовою.

Тоді є діти, щоб діти могли вивчати програмування, як LOGO.

Також мови для швидкого запису коду, наприклад Python, Ruby тощо, мови для обробки XML (XSLT).

І я, мабуть, забув багато мов і навіть категорії мов.


1
Ваша хронологія заплутана. Пролог - з 1972 року, молодший за Ада (1983). Я не знаю, що ви маєте на увазі під "спадкоємцями мов третього рівня"; кілька мов не є нащадками Фортран, включаючи C і Паскаль (які породили Ада).
профілі

1
@prosfilaes, спосіб заплутаний. FORTRAN була першою мовою, яка все ще використовується, потім з'явився LISP, потім COBOL. Алгол був визначений для публікації алгоритмів, а не для машинного використання (але подібні компілятори все-таки стали), з ofshots Pascal і пізніше C. PL / 1 був дивним поєднанням FORTRAN і COBOL з контрольними структурами Algol-ish.
фонбранд

1

інші відповіді хороші, додадуть кілька нових ракурсів. як DC пише, що мови розвиваються так само, як і справжні людські мови! і вони запозичують поняття та синтаксис один у одного, як справжні людські мови. Іншими словами, є також досить реальне вивчення етимології комп'ютерних мов.

це також означає, що у них була довга історія та часова шкала, яка в основному почалася приблизно в 1930-х роках з обчисленням лямбда .

існує сильна взаємодія / синергія / симбіоз між теорією та застосуванням з мовами програмування. винайдено нові програми, що призводить до нових теорій і навпаки. мова програмування багато в чому є мостом між теорією та застосуванням .

цікавий кейс з історії - Фортран. невідомо, але більш ранні версії Fortran (переважно до Fortran77) мали неоднозначну граматику . це означає, що одна і та ж команда може бути законно "інтерпретована" / складена компілятором різними способами, оскільки було кілька дійсних "інтерпретацій" (це не той самий технічний сенс "інтерпретованих" мов).

тому теорія про формальні граматики розроблялася в той час, коли був винайдений Фортран, і це була невелика криза, коли було відкрито питання про мовну неоднозначність. Синтаксис Фортана був переформульований, щоб уникнути цієї неоднозначності, і пізніші мови мали більшу чутливість до неоднозначності граматики у своїй конструкції. OOP також є дуже важливим / головним прикладом теоретичної концепції / просування в мовах програмування, які "впливають" або "пульсують" у багатьох існуючих мовах, трансформуючи їх.

інші приклади - це винахід нових технологій. наприклад, винахід реляційної бази даних мав величезний вплив на комп'ютерні мови, наприклад, з інтерфейсами SQL та комп'ютерною мовою (наприклад, в java, "JDBC"). так само всесвітня павутина з ще більшим впливом. здалося, вибух мов був приурочений до буму dotcom, який значною мірою співпав з раннім зростанням WWW і може бути порівняний з еволюційними вибухами .

також, здається, спостерігається тривала тенденція зростання нових мов програмування в поєднанні з масовою експоненціально зростаючою оброблювальною силою закону Мура, який, на думку деяких, може уповільнювати.

Поточні тенденції лонггранжу в мовах програмування, схоже, спрямовані на великі дані та паралелізацію, наприклад, з MapReduce . існує також сучасний інтерес до закриття .

Ще одним ключовим аспектом мов є те, що вони представляють зростаючі рівні абстракції . вони ґрунтуються на абстракціях нижчого рівня, щоб створити абстракції вищого рівня (подібні до піраміди). таким чином прогрес еволюції комп'ютерної мови, ймовірно, нескінченний, і ми можемо бути відносно впевненими, що важливі нові з них будуть винайдені довго в майбутньому. це, ймовірно , аналогічно така ж концепція в психології називається фрагментація -roughly заявили, що будувати ментальні поняття більш високого рівня з більш низького рівня будівельних блоків.

кожен, хто вивчав багато комп'ютерних мов, повинен визнати, що ментальність стада може спостерігатися, завдяки чому деякі аспекти їх виявляються завищеними, але не такими критичними, як пропонується, або навіть вимирають (використовуються) з часом! деякі основні ідеї / зміни залишаються, але (надмірна) ажіотаж згасає. в цьому сенсі мови програмування також потрапляють і не входять в моду . на мою думку два випадки останнього пів десятиліття, які справді корисні, але перебільшені:

все частіше подібність можна спостерігати на багатьох основних мовах, так що всі вони, як правило, сходяться до впровадження багатьох подібних функцій по-своєму, тобто, як у діаграмах порівняння продуктів, які "перевіряють" багато функцій в сітці.


див. також шаблони дизайну, які часто перекладаються між мовами та реалізуються в мовах. Ще одним ключовим аспектом вивчення мови / функціональності є функції, реалізовані в бібліотеках
vzn

FORTRAN ніколи не мав офіційного опису, тим більше складності вираження, що могло б призвести до неоднозначності граматики (так, я почав програмувати в гидоті під назвою PDQ FORTRAN, а пізніше FORTRAN IV) мовою, якою (дуже бентежно) неоднозначність. граматика з’явилася на світ Алгол, перша мова, визначена граматикою.
vonbrand

точка взята wrt оригінальна / рання FORTRAN, але пізніші версії були більш формалізовані з більш жорсткими граматичними визначеннями. це тематичне дослідження, що показує еволюцію мови разом з теорією мови.
vzn

FORTRAN отримував граматику, але ніколи не розроблявся. Алгол розпочав цю тенденцію, яку продовжили Паскаль, сімейство Модула, Оберон, С, і це є штрих, PL / 1, Ада та ін. Враховуючи технологію вільної граматики контексту та розуміння розбору, сьогодні визначення граматики та переведення її на аналізатор без помилок майже тривіальне, без жодної нової мови не обійтися.
фонбранд

доповнення, тематичне дослідження на нових мовах / нових мовах: Google go , node.js , Apple swift
vzn

-3

Вони не були, це просто маркетинговий трюк-- якщо ти зробиш, що мова на зразок виглядає як "С", то це знижує явний бар'єр для вступу.

Деякі, які взагалі не впливають на C: SQL, Pascal, Delphi, FORTRAN, COBOL, Ada, PowerBuilder, HyperTalk, Lisp, Simula, FOCAL, BASIC, PL / I, Algol, Algol-68, SNOBOL, Modula, Visual BASIC, Репетитор, логотип, Forth, DIBOL, Helix, AppleScript, Python, Erlang, Ruby, Pick, англійська, RPG, PL / SQL, ASP, Prolog, SmallTalk, Perl, bash, Wand BASIC, REXX, пакетна мова DOS.

Ті, які начебто ЛОКУЮТ на зразок C, але мають дуже мало спільного з ним: JavaScript, Java, C #, (можливо) Objective-C.

Це весь маркетинг, Java, C ++ та JavaScript начебто схожий на C, але навряд чи можна було б відрізнятись під обкладинками.


5
"Вони не були" - що не було? У будь-якому випадку, я не бачу, як це відповідає на питання. Це просто список мов, а також абсолютно необґрунтоване твердження, що маркетинг якось пов'язаний.
Девід Річербі

2
"Деякі, які взагалі не мають впливу С: ... Алгол, Алгол-68, ..." - Смішно ви повинні сказати це, враховуючи, що С виник з Алголя. "якщо ви робите своєрідну мову схожою на" С ", це знижує явний бар'єр для вступу", - це було доведено неправильно. Студенти без попереднього впливу програм програмування навчаються швидше з іншими мовами (я думаю, вони використовували Haskell у цьому дослідженні).
Рафаель
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.