Парадигмы языков программирования :-)

В дополнение к Первым дням конспекта лекций дополнительный матерьял - цикл назову Беседы с "Гордоном" \=] 

Собеседник - python программист Antoni  ,)

Dao_work> как говорится - Привет Корпоративным Программистам
Dao_work> не очень занят ? -)

угу не очень :-)

Dao_work> тогда вот
Dao_work> http://daodev.blogspot.com/
Dao_work> 8-))))
Dao_work> День 0 и День 1 =)
Dao_work> Интерпретатор, ... инструкции программы . Компилятор ... исходный код программы . Чувствуете разницу +))

ну скажем так - компилятор делает программу а интерпретатор сам программа :-) т.е. после компиляции для работы программы компилятор больше не нужен а интерпретатор нужен, он всегда запускается для работы программы
Dao_work> компилятор делает временный .obj или .o фаил
Dao_work> )
Dao_work> Antoni только если язык Интерпретируемый
Dao_work> Ибо далее работает ещё компоновщик
Dao_work> )

ну в целом, компилятор создает независимые программы. Они не отличаются от самого компилятора :-)
а интерпретатор всегда идет в комплект :-)
...
в общем компилятор создает независимую программу. И дальше эта программа в компиляторе не нуждается. А интерпретатор программу не делает, он сам запускается и поддерживает ее выполнение :-)
м.. идеи парадигм языков удобно рассмотреть в их историческом развитии :-) т.е. почему и зачем возникало то или иное течение. Сначала (когда появились первые цифровые ЭВМ, ведь до этого были еще и аналоговые! :-) ) появились процедурные (императивные) и почти одновременно функциональные (аппликативные).Языки - это соотественно Fortran (процедурная концепция) и LISP (функциональная)
эти два языка ооочень старые и есть основоположники , разница концепций такова: процедурная ближе к архитектуре машины и эффективнее выполняется. А языки функциональные более абстрактны, логичны и красивы с математической стороны. Но выполняются очень медленно. (и раньше умели делать только интерпретаторы для них) это решило дело: популярными в проф. среде стали именно процедурные а LISP применялся для каких то специфических вещей "типа исследования искусственного интеллекта". OCAML (это кажется первый функциональный язык, для которого сумели сделать компилятор.
Dao_work> кстати - сколько ещё ты знаешь компилируемых языков кроме С++ и С ?

Есть еще языки которые близки к компиляторам, но с хитростями и частично интерпретируются: Pascal, Forth и т.п.

Dao_work> паскаль и дельфи оставим

Угу как раз дельфи не совсем компилятор, там внутри этих хитростей хватает чисто компиляторов что-то не вспоминается больше :-) так вот все стали в основном работать на процедурных языках. И тут выяснилось, что большие программы делать на них очень сложно. И трудно отлаживать. Структура проекта теряется и можно повеситься. Поэтому придумали "принципы структурированного программирования", которые спасли положение (на нек. время)
В эти принципы входил запрет использовать прямые переходы GOTO, так же ввели локальные переменные и контекст процедур. В структурированное программирование входят if блоки и цикл блоки дальше придумали модульность, как красиво разбивать исходный текст на файлы и потом компилировать вместе так вот классика структурированного программирования это Pascal. Как раз он и был создан по всем этим требованиям. Так же принципы быстро включили во все языки в какие смогли.

Dao_work> почему использование GOTO недопустимо ?

Потому что это нелогичный прыжок в программе, который трудно анализировать (человеку). Он может идти в любое место программы и ищи свищи. Если применять GOTO то можно быстро испоганить весь исходник станет как кубик рубика. Поэтому это первое что запретили.
В Си и Си++ структурированные принципы тоже включили, но не так строго как в Паскале структурированное программирование это не только возможности языка, а методика работы самого программиста - как надо оформлять программу что лучше делать и что нельзя благодаря этому стало возможно легко разрабатывать программы крупнее на порядок :-) но все равно есть потолок, когда проект опять теряется и запутывается
поэтому развитие шло дальше , во первых прорабатывалась и углублялась мысль о модульном программировании (Modula-2, Ada и т.п. автор тот же что и Паскаль написал).

Модульность а вот потом придумали ООП поначалу как совсем отдельный тип языков программирования - классика Smalltalk потом сообразили, что оно может внедряться и в старые языки и стали внедрять
тут было много воплей и споров потому что придумали теорию ООП и строгий стандарт. А в языки включали часто не точно по стандарту, иногда вообще искаженно и упрощенно. (в некоторые языки полностью ООП и фиг включишь так просто) (Smalltalk то специально создавался как ООП язык) поэтому были споры о первоначальных "правильных" ООП языках. И не до ооп отклонениях. Очень много можно ругани на Си++ найти (в нем куча отклонений от стандарта). Но с другой стороны (а это уже 80ые годы пошли) появилась эйфория - ООП это панацея от всех бед, позволяется делать на порядки больше проекты. Мол ООП это счастье навсегда. Было выпущено тонны книг о "новом ООП проектировании" и т.п. Потом параллельно шла разработка темы: что есть программирование - текст или график программа это текста, а ее блок-схема - графическое отображение. И появилась мысль о CASE средствах - можно ли сделать такую среду разработки что писать текст вообще не надо было, только рисовать. Были очень интересные штуки гм... но в результате это ввели немного во все популярные студии программирования и успокоились. (типа VisualBasic Delphi и т.п. ) Первоначально же были экспериментальные CASE среды, в которых натурально графически проектировалась структура программы и набивать текст почти не надо было. И те среды канули в прошлое, но идеи наработки частично используются почти везде идем по истории дальше . 90ые годы. Появилась нехилая мысль: сделать такие языки чтобы программа запускалась без переделки в любой ОС на любом процессоре. Кросс-платформенные языки: Java, Ruby, Python

Dao_work> угу только Java кажись раньше был чем тот же руби

ну да "первый блин комом" но он первый %-) хотя до Java тоже были эксперименты

Dao_work> + Java есть идея использования виртуальной машины
Dao_work> Руби и питон это всё таки интерпретаторы ближе к Перл пожалуй

неа, питон и руби чистые интерпретаторы. дальше появились виртуальные среды с одной стороны, и способы соединять разнородные проги с другой (CORBA) А Perl jit-компилятор :-)
дальше еще одно направление: компьютеры стали "очень мощными" и стало реально возможно работать на функциональных (которые тоже были на заре давно, как помним, но не были популярны) и логических языках
CORBA это отдельная свободная технология связи разнородных программ по сети в одну. И в каждый язык сделали поддержку этой технологии и стали писать "есть CORBA@"
Так вот стали более популярны функциональные языки (логические пока на заднем плане, но в будущем все еще может развернуться :-) )Во многие языки стали вводить элементы функциональных как в Python например. Вообще много появилось мульти-парадигменных языков и конечно OCAML это прорыв мощный, настоящий компилятор чисто функциональный. И скорость не уступает Си , круто в общем ну вот и все пока приехали :-)(а на логических языках потихоньку что-то делают супер профессиональное, например на Mercury в Англии написали автодиспетчерские службы в аэропортах)

Dao_work> В чём основное отличие
Dao_work> ну самый яркий практический пример
Dao_work> логического языка

Prolog . Основное отличие вот в логическом языке программа рассматривается как совокупность логических утверждений (тождеств). Причем тождество работает в обе стороны автоматически. И все это как система уравнений. Т.е. ты пишешь действий и команд, алгоритма тоже нет в программе.
Ты вводишь связанные условия задачи, по которым транслятор рассчитывает поведение программы и результаты :-)

Dao_work> сложи на логике а + б )

легко
x есть a + b
a есть 3
b есть 2
после ввода первой строки x станет неопределенной от минус до плюс бесконечности
после второй появятся ряды возможных значений x и b одновременно
после третьей результат станет полностью конкретным
особенностью логических языков является то, что ответ всегда есть, просто не четкий или множественный. (а не только в конце программы, как в обычных языках)

Dao_work> я вижу плюс в том что ненужно указывать тип переменной

тут вообще нет переменных принципиально :-) (не то что типов, просто нет переменных %-)

Dao_work> НО вопрос - это не может привести к нелогичному использованию памяти ? Обычно ведь заранее область памяти резервируется под что-то + там ещё переполнение буфера обмена
) в таких языках все управление памятью идет полностью автоматически. нее переполнения буфера в ФП и ЛП не бывает там это решается очень просто - все строки неизменяемы поэтому переполнить буфер невозможно
поэтому ФП (и ЛП наверное) более безопасные языки чем процедурные хакерам там труднее. Я написал не = а "есть" слово чтобы подчеркнуть дух языков - нет переменных. Это тождество а не присваивание а x, a, b не переменные, а символические имена, обозначающие некую искомую сущность %-) что соотествует математическому понятию переменной

Dao_work> Такс - думаю на этой ноте надо остановится )