пятница, 28 января 2022 г.

Шеркало 05.10: (не)любимые системы программирования (Другие ч.4)

- Ёж, какая сегодня погода?

 - Так, Шеркало, не отвлекай меня! Эту серию про системы программирования, пора уже жесточайшим образом заканчивать, тем более, что любимые давно закончились, а нелюбимые, большей частью, не особо интересны!

- Ну и пожалуйста, ну и заканчивай, себе, на здоровье.

C++

Про язык C++ конечно тоже нельзя не упомянуть. Тем более, что это совершенно самостоятельная среда и даже совершенно отдельная "экологическая ниша", по сравнению с исходным языком Си. Это не просто объектно-ориентированное расширение Си, это вообще отдельная парадигма программирования. Картинок, с исходными текстами наверное в этот раз не будет. Ни  к чему они, в моих воспоминаниях. Если Си я в прошлый раз оценивал, как "структурную надстройку над ассемблером PDP-11", то C++ безусловно с ассемблерами, да и вообще, с любыми предыдущими языками (включая даже язык Си!!!), сравнивать нельзя!

C++ есть воплощенная бескомпромиссная производительность и мощность программирования, выжимаемая из архитектуры современных микропроцессоров! Это язык, на котором программист должен иметь возможность написать ВСЁ, что пожелает, реализовать любые, самые смелые свои фантазии! На момент разработки C++ передовой технологией считалась (была, на самом деле) технология Объектно-Ориентированного Программирования (ООП). C++ вобрал в себя парадигму ООП по самому максимуму! Чего стоят только реализации множественного наследования, и перегрузка функций, и перегрузка операторов!!! Главная идея - всей мощности и свободы побольше, побольше, и ни в чём, кроме размера виртуальной памяти (которая почти бесконечна), не нужно себя ограничивать!

Моя личная работа с C++ не сложилась точно так же, как и работа с Си. Те же, самые достоинства, языка, что и у Си, только возведённые в третью степень. Те же самые недостатки, что и у Си, тоже возведённые в третью степень. Тот же самый мой вывод: Паскаль (на этот раз более современный Object Pascal, поддерживающий ООП) - гораздо проще и понятнее. Пусть у меня с Паскалем не будет всемогущей власти над всеми современными нюансами программирования, но зато я и не буду неделями выискивать в программе (особенно в чужой) кучу неприятных блох, появившихся в результате единичной случайной опечатки в одном символе текста.


Бейсик BASIC 

Тоже, вероятно надо упомянуть.  Изначально - учебный (поэтому очень сильно сокращённый вариант Фортрана). Выглядел примерно вот так:

10 INPUT "Введите значения X1,X2,X3,B,A"; X1,X2,X3,B,A
20 LET X=X1
30 LET Y=(B*X^2-A)/(EXP(A*X)-1)
40 PRINT "X=";X;"Y=";Y
50 LET X=X+X3
60 IF X<=X2 THEN 30
70 END
В качестве учебной версии Фортрана на период начала1960-х годов - идеальное решение, буквально по всем параметрам! Здесь нужно отметить, обязательную нумерацию строк. Это, с одной стороны, прямое наследие Фортрана (но в Фортране не все строки обязаны были иметь номера). С другой стороны, нумерация строк - очень существенное облегчение при реализации экранного текстового редактора (ВАУ! А читатели вообще в курсе, что ЭКРАННЫЙ текстовый редактор для ранних персоналок был недостижимой мечтой?! Что текст редактировался в лучшем случае в пределах одной строки, пока не нажата кнопка ENTER/ВВОД?! А потом - ищи-свищи эту строку!) на слабом компьютере (на тот момент, опять же, почти идеальное решение, позволяющее создать прямо на коленке приличный экранный текстовый редактор из примитивного строчного текстового редактора - очень простое (редактирование ранее введённой строки по её обязательному номеру) и удобное решение при разработке интерактивного интерпретируемого (построчно) языка на компьютере, который ещё толком не поддерживает полноценные полно-экранные терминалы.

Маленькая  техническая вставочка. Изначально под термином "терминал" (извините за невольную тавтологию) на больших компьютерах, подразумевался телеграфный аппарат. Ты ввёл строчку текста, она отпечаталась на бумаге (или, чаще на бумажной ленточке с клейкой основой), и после нажатия кнопки "Передать" ушла в компьютер. Тот немного подумал, подумал, в ответ выдал тебе на бумаге (ленточке) свою ответную строчку символов.
Вот и всё! Вернуться к предыдущей строчке и исправить её, если где-то опечатался, уже НЕЛЬЗЯ. Предыдущей строчки уже в компьютере физически НЕТ, она сохранилась только в форме строки букв, отпечатанных (перфорированных) на бумаге. Вернуть эту строку букв обратно в компьютер, чтобы исправить опечатку, уже никак нельзя, она уже вышла оттуда, она уже "wasted". (На самом деле можно, но сложно, и я сейчас говорю не об этом).
Ну и вот, идея жёстко пронумеровать каждую вводимую строку (при этом сохраняя копию этой строки в памяти компьютера!) позволяла обеспечить редактирование текста программы в интерактивном режиме - каждую строку редактировали, назвав её уникальный номер! Ну и плюс,, вспомним тот же FORTRAN, с которого BASIC брал пример - там тоже изначально каждая строка на бланке для пробития перфокарт свой номер имела. Только потом разрешили у "неважных" строк, на которые никто не ссылается, номера пропускать. Так, в исключительно строчном режиме, обходили технические ограничения терминалов на редактирование предыдущих (уже ушедших из короткого буфера памяти терминала) строк.

Как только терминалы больших ЭВМ, работавшие в режиме буквопечатающих телеграфных аппаратов, перестали быть супер-уникально-актуальными (где-то в конце 1970-х годов) и сменились полноэкранным редактированием текстов, так тут же язык BASIC начал очень быстро совершенствоваться. Прежде всего исчезла обязательная нумерация каждой строки, появились символьные переменные и операции с ними. С приходом микрокомпьютеров и ПК в язык включились низкоуровневые функции, элементы ООП, готовые библиотеки программ... Огромную роль в развитии BASIC сыграла фирма Microsoft, во главе с известным всему миру программистом Биллом Гейтсом. В своё время фирмы Microsoft и Borland даже, по слухам, очень круто поцапались друг с другом именно из-за языка BASIC. Итогом конфликта стал раздел сфер влияния: Борланд прекратила развивать свою успешную тогда линию компиляторов "Turbo Basic", отдав это поле Майкрософт. В свою очередь, компания Гейтса отказывалась от претензий на компиляторы языка Паскаль, признавая их сферой интересов Борланда. 

Дальше о BASIC - всё просто. Для изначально слабых ПК на базе ранних 8 и 16 разрядных процессоров, BASIC (тем более в относительно современных инкарнациях). был одним из немногих реально эффективно реализуемых на том железе языков высокого уровня. Тем более, будучи при том  изначально простым для понимания начинающими, BASIC получал всё более нарастающую популярность. размножался во множестве версий и пользователей. Немного позже, с появлением полноценных 32, 64 разрядных ПК, BASIC утратил какие-либо специфические преимущества. гораздо более простые, удобные, понятные, развитые языки программирования стали завоёвывать бОльшую популярность.
От полного забвения BASIC спас лично Билл Гейтс, испытывавший к этому языку свою личную симпатию. Он сделал именно BASIC, в варианте Visual Basic for Application (VBA), основным скриптовым языком сверх-популярного пакета программ MS Office, что безусловно продлило жизнь языка на несколько десятилетий (а потом ещё в оболочке PowerShell тоже танцы с BASIC продолжились и до сих пор продолжаются). Но, как и во многих иных случаях, то что понимается по Basic'ом сейчас к изначальному языку BASIC из Дартмутского колледжа не имеет практически никакого отношения - ни единой общей чёрточки, совсем ничего похожего, кроме нескольких общеупотребительных служебных слов, знаков арифметических операций и арабских цифр.

Моё мнение о BASIC: для маломощных ранних ПК - он самое ТО, что тогда и надо было! Для скриптового языка MS Office, в меньшей степени для скриптового же PowerShell - он на своём месте, хотя могло бы быть и гораздо лучше. На перспективу - да ну его, нафиг, явно устарело.

- Так, я бегу. Шеркало, бегу быстрее, стараюсь пропустить мимо внимания галопом всё, что возможно. Но не могу пропустить язык Forth.


Forth

Нельзя его пропустить, поскольку Forth - идеальная классическая стековая машина. Что такое стек? Точнее, что такое LIFO-стек (Last Input - First Output) - это такая специальная "несправедливая" очередь - кто последним в очередь встал, обслуживается самым первым. Классический пример стека - магазин к автомату Калашникова, в котором самый последний заряженный патрон, оказывается на самом верху и выстреливается первым, а самый первый из патронов наоборот спускается при зарядке в самый низ магазина, и стреляет последним. Или узкая трубка с конфетками, открытая только с одного конца. Конфетки засыпаются в трубку сверху по одной, съедаются потом тоже по одной, начиная с самой верхней, последней конфетки, далее по порядку до самой нижней, самой первой.
Зачем такая "несправедливая" очередь нужна? Очень просто - экономия аппаратуры машины на адресации. В обычных компьютерах нужно тратить ресурсы (место в памяти, в машинных командах, в регистрах, на адреса операндов. Вроде "взять число из ячейки памяти 9876 и сложить его с числом из ячейки 4567, результат записать в ячейку памяти 2233". На все эти номера ячеек нужно тратиться, хранить их, декодировать, передавать из одного устройства процессора в другое и т.п. А в стековой машине ничего подобного не нужно. Адрес ячейки, откуда нужно взять первое число ВСЕГДА точно известен - это вершина стека. Адрес второго числа... вы будете смеяться, но он ТОТ ЖЕ САМЫЙ - это снова та самая вершина стека, откуда мы только что взяли первое число. Только там, на вершине, теперь лежит другое число, вот его и возьмём. Куда положить результат? Вопросов нет - ТУДА ЖЕ, на вершину стека. Нам при этом ни разу не понадобилось обращаться к ячейкам памяти напрямую по их номерам/адресам! Экономия, однако!

Так вот, Forth - это классическая стековая машина, где всё что можно хранится в стеке, поэтому прямая адресация памяти по номерам ячеек почти и не используется. Данные в Forth лежат в стеке, программа, на Forth, состоит из "слов", которые лежат откомпилированные в словаре, который на самом деле тоже хранится в стеке (модифицированном, наложенном на линейную память). Собственно и самого языка Forth, просто не существует! Forth - это набор слов, которые оперируют стековыми данными и виртуальная машина, которая слова из стека читает и интерпретирует. Слова из словаря, в виде стека, который может дополняться программистом. Программирование на Forth - это и есть дополнение уже готового словаря новыми словами сверху. Всё, что может быть представлено стеком - всё это и есть в стеке (а что нельзя положить в стек, то всё равно, хотя бы частично, но тоже хранится в стеке). Очень красивая парадигма!
На первый взгляд слегка шокирующим для начинающих становится первое же следствие стековой архитектуры - простые арифметические выражения приходится записывать в так называемой "постфиксной или обратной/инверсной польской" записи. Да и дальнейшее  программирование тоже требует... эээ... постфиксного подхода к написанию текстов. Но привыкнуть можно.

В Forth нельзя написать умножение, как
2 * 3  - операция умножения * здесь написана слишком рано - в стеке ещё нет готовых для неё чисел, правильно нужно написать вот так:
2 3 *  - сначала в стек складывается число 2, потом поверх него складывается число 3. Потом появляется операция * умножить. Она берет с вершины стека по очереди два необходимых операнда, сначала берёт 3, потом берёт 2, потом умножает их друг на друга и результат снова кладёт в стек, на его вершину.
А что бы выполнить математическую операцию  sin((a+b)/(c-d)) в Forth нужно записать такое выражение:
a b + c d - / sin
Понятно? Вполне красиво, и никаких скобок не требуется.
Хи-хи (оно же P.S.). Нужно отметить, что ничего не даётся бесплатно! В постфиксных выражениях Forth каждый лишний уровень скобок или учёт приоритета операций "обычного" выражения требует +1 к глубине стека.

Пример: выражение c + a * b запишется в постфиксной записи c a b * +. Хотя скобок и нет, но приходится из-за приоритета умножения, сначала положить в стек сразу ТРИ числа c a b, потом выполнить умножение a на b, вернув результат в стек поверх ранее положенного c, а уже потом сложить с с этим результатом.
Со скобками, меняющими порядок действий, всё аналогично. Выражение a * (b + c) в постфиксной записи будет выглядеть a b c + * и так же потребует стека глубиной не менее трёх элементов, в отличие от стека глубиной 2, достаточного при отсутствии скобок и приоритетов операций..

Такая же постфиксная логика математических вычислений была реализована и и известной линейке советских программируемых калькуляторов Б3-21, Б3-34, МК-52, МК-61 и некоторых других  У меня такие калькуляторы были ещё со школы (и даже сейчас есть - МК-61). Очень нравились, вполне удобно считать (по моим современным ощущениям, у МК-61 индикатор явно мелковат по размеру (в смысле физически мелковат, в миллиметрах), да и по яркости слабоват, но это уже личные придирки, сам принцип интересен и вполне применим). Отдельную статью об их программировании вряд ли стану писать. Упомянуть, что близкие по возможностям американские программируемые калькуляторы появились раньше, вероятно имеет смысл.  Но последующие исследования показали, что наши советские модели программируемых калькуляторов с постфиксной арифметикой создавались "по мотивам" (вот нарисуйте так, чтобы считалось прям как у них!), однако технически были вполне самостоятельны, и на уровне микроэлектроники - абсолютно несовместимы с "прототипами-вдохновителями" от фирмы HP..

С показыванием программ на Forth у меня возникли некоторые трудности. Ну нечего там показывать, для человека, смотрящего со стороны? Это же просто текстовый бред какой-то. А пояснять более подробно - так тут уж целые книги цитировать надо (при подготовке этого этюда я реально и с интересом перечитал пару умных книг по программированию на Forth). Попробую уложиться в формат рассказа?
: FACT                        (... n -> ... n!               )
  DUP 2 < IF DROP 1           (1 если n<2, то n!=1           )
  ELSE                        (n иначе                       )
  DUP                         (n n s=n k=n                   )
             (Теперь лежащие в стеке числа будут представлять)
                (s - накопленное произведение и k - множитель)
  BEGIN                       ( s  k                    <--  )
  1-                          ( s  k' k'=k-1               | )
  SWAP OVER * SWAP            ( s' k' s'=s*k               | )
  DUP 1 =                     ( s  k k=1 если k=1, то s=n! | )
  UNTIL                       ( n! 1 иначе повторить    ---  )
  DROP THEN ;                 ( n!                           )
Или более интересный вариант:

- Ты, Ёж, тут хвостиком своим куцым не виляй. Прямо говори, чем тебя Forth не устроил!

- Понимаешь, Шеркало... Дело не в том, что устроил или не устроил. 
Forth - наиинтереснейший язык, это вещь, которую ОБЯЗАТЕЛЬНО нужно изучать! Must Have, что называется. На базе идей стековой машины Forth и "шитого кода" (сознательно эту штуковину не упоминал для сокращения статьи) развивалось множество современных концепций ИТ и множество очень известных, популярных и сейчас систем. Forth - безусловно красивый прорыв для своего времени! Вот только... это НЕ язык программирования.

На Forth нельзя (точнее можно, но крайне неудобно и никто этого не делает) писать программы, работающие на каких-то общеупотребимых компьютерах, под управлением каких-то известных операционных систем, в среде кучи других программ под эту же систему. Нет, Forth - сам себе компьютер и сам себе операционная система. На нём нельзя просто взять и "написать программу". Нет такой опции! Вместо программы можно написать расширение самого языка Forth - любая программа, это не просто сторонняя программа - это именно расширение (усовершенствование) самого языка. Получается, что средний программист не может просто писать обычные прикладные программы, а должен для достижения своих прикладных целей дорабатывать используемый им язык программирования! Представляешь? Надо тебе, допустим, написать программу находящую корни квадратного уравнения или считающую площадь прямоугольного треугольника. А ты вместо этой примитивнейшей задачи, пишешь фактически свою собственную расширенную версию языка программирования!!! Всего-то на всего! Писал простенькую программку, а написал в итоге новый язык!

Ну и "лёгкий" побочный эффект: допустим некий абстрактный Вася, доработал Forth одним образом, чтобы реализовать сравнительно сложную матричную арифметику, а некая Маша доработала свой Forth таким образом, чтобы её респонденты заполняли красивые формы данных, которые потом могли бы использоваться при матричных вычислениях Васи.
И вот Вася с Машей, находят друг друга, понимают, что Машина программа могла бы насобирать данные, которых так не хватало Васе, а Васина программа, в свою очередь, могла бы обработать данные, которые насобирала Маша. Но тут выясняется, что Маша с Васей имели вообще разные взгляды на перспективы доработок Forth, что их собственные версии языка вообще даже близко несовместимы друг с другом, что у них разная арифметика, не говоря уже о разных границах массивов (у Васи с 0, а у Маши с 1), что для приведения всего этого цирка с конями к единой схеме требуется целый институт научных работников... Ну, в общем, пример исключительно надуманный, но понятно, о чём я толкую - поскольку программы на Forth как таковой не существует, все свои наработки можно сохранить только вместе с полным словарём языка. И что делать, если этот словарь оказался вообще разным у разных программистов, что неизбежно, даже в простейших случаях?!

Предложения сохранять новые слова в виде исходных текстов (как в моих примерах выше) и компилировать их позже в других системах Forth'а не помогают. Дело даже не в том, что в Forth есть огромные проблемы с файловыми операциями (хотя они традиционно таки там есть). Слова компилируются и отлаживаются в конкретной системе, в своей программной среде - это идеология языка. В общем случае, выдрать часть слов из системы Васи, и откомпилировать их в системе Маши, или наоборот, не получается, возникают сложно уловимые проблемы с отладкой, с дублированием и перегрузкой чужого кода. Перенос исходного кода проходит почти безболезненно лишь в очень простых (либо учебных, либо вырожденных) случаях.

Для чего действительно удобен Forth? Разработка очень кратких, предельно эффективных программ в условиях маломощных процессоров и при катастрофической нехватке памяти (вроде своеобразного ассемблера для маломощных машин с преимущественно стековой адресацией). Но, при этом, отсутствие требований к "универсальным" программам, сосредоточенность на типовых, повторяющихся операциях. Что за ниша? Управление аппаратурой, промышленные контроллеры. Вторая ниша - виртуальные машины, когда стековая архитектура дико удобна (экономна), а стековые недостатки никого не волнуют, люди сами вручную программы для стековых машин не пишут.
Для живого человека - стековая архитектура Forth обычно не самый лучший мнемонический вариант написания программ. 

Мой личный опыт Forth (не считая чисто "книжного") это - конечно БК-0010/11(М). Вроде бы условия как раз подходящие - компьютер с чудовищно обрезанной до смешных 15.5 кБ оперативною памятью. И Forth на нём с любовью реализован (на самом деле он был реализован на других клонах системы PDP-11, но на БК-0010 тоже вполне запускался). И неутешительный вывод - работает крайне нестабильно (слишком ограниченная аппаратная поддержка стека), чудовищно неудобен, программы плохо переносимые даже между однотипными системами. С трудом подходит для чисто учебных целей на самом младшем уровне начинающих, вроде "посчитайте 2 + 2 и выведите строку 'HELLO' задом-наперёд" (но тут для начинающих, ожидаемо, постфиксная запись категорически обламывает им всю малину), но ничего хоть чуть-чуть серьёзного реализовать не получается. К такому же мнению единодушно пришли и другие программисты БК-0010. Родной ассемблер PDP-11 на сто порядков лучше, проще, удобнее, надёжнее.

- Всё, наконец уже, Ёж?!
- Нет, Шеркало, потерпи, осталось совсем чуть-чуть, буквально несколько абзацев. Не хочу растягивать повествование на ещё одну часть.

Simula-67, Smalltalk

Не могу же я вот так всё завершить цикл рассказов, не упомянув про языки - родоначальники парадигмы Объектно-Ориентированного Программирования (ООП)? Традиционно самым первым языком ООП считается язык Симула-67, в котором впервые были реализованы большинство синтаксических (и семантических) идей современных ООП-языков.
Симула - расширение известного языка Алгол-60, в который в первую очередь были добавлены классы - некие структуры, которые объединяли внутри себя данные (переменные, поля) и исполняемый код (процедуры, методы, оперирующие с этими данными). Классы могли наследовать свойства друг друга. В программе динамически порождались отдельные экземпляры - объекты описанных классов. Всё это предполагалось для того, чтобы как можно точнее моделировать (точнее симулировать, отсюда и название языка "Симула") объектами в программе поведение настоящих объектов реального мира.

Я в своё время (опять же в школьное время) на Симулу-67 внимание конечно обратил. Купил в магазине книжку про этот язык. Внимательно её прочитал. Идея объединять в единое целое специфические внутренние данные и работающий с ними код показалась здравой и интересной, но приведённые в книжке примеры меня особо не впечатлили. Вроде как с объектами, чуть нагляднее получается, но смысл огорода не совсем ясен, как бы и без объектов всё то же самое можно было и обычными средствами сделать почти не хуже. Повторюсь - это всего лишь моё личное впечатление от прочтения книжки-брошюрки, по сути - учебника. Книжка при очередном переезде конечно потерялась. Доступной реализации Симулы я так и не нашёл (хотя специально и не искал), так что на практике этот язык никогда не пробовал.
Много позднее вернулся к теме ООП уже при работе с TurboPascal и Delphi - вот там реально понимание объектно-ориентированной парадигмы понадобилось на практике. Ещё обратил внимание, что название одной из известных книг неоднократно упомянутого профессора Вирта - "Алгоритмы + Структуры данных = Программы" очень здорово перекликается с идеей Симулы-67. Пример того, что иногда востребованные идеи просто "витают в воздухе" и приходят в голову многим одновременно.

Примеров программ на Simula-67 приводить не буду. Во-первых, я ни строчки на этом языке не написал, а во-вторых - Алгол, он и есть Алгол, ничем на вид, кроме нюансов не отличается. Пусть желающие сами картинки ищут.

Другой язык, считающийся классикой парадигмы ООП - это Smalltalk, развивавшийся с начала 1970-х годов и оформившийся к началу 1980-х. В Smalltalk всё есть объекты, нет вообще ничего, кроме объектов. И эти объекты активно общаются друг с другом, обмениваясь сообщениями (которые на самом деле тоже есть объекты), и, реагируя на свои входные сообщения, собственно и реализуют логику работы программы. Объекты принадлежат классам, объединяющим похожие объекты. Логика поведения объектов (программный код) сохраняется в классах, а вот индивидуальные особенности - конкретные данные, сохраняются в индивидуальных объектах. Но классы, в которых сохраняется код, а не данные, тоже, разумеется, являются объектами...

- Хрррр-пшшшшш-хррр-хрр-пшшш-пуфф-хррр!
- Шеркало?!!!
- А, Что? Я всё слышал! Вот, смотри: "язык Forth является неотъемлемой структурой программы объектно-функционирующей при получении данных для системы класса 8-б Васи от PDP-11, которая у Маши в классе 7-г вместе с симуляцией". Я всё правильно понял?
- Э... Шеркало, а как будет звучать термин "ИДИОТ", несли его применить к существительному среднего рода?
- Ёж, давай уже, заканчивай, и не выёживайся!
- Даваю!

Не было у меня на практике никакого Smalltalk. Его вообще практически не было в нашей стране в то время (да и сейчас его тоже не очень). Но в мой университет ТГУ в связи с Горбачёвской "perestroyka" из самой Америки закупили целую партию сверхсовременных персональных компьютеров IBM PS/2. Их закупили аж 1.5 или даже целых 2 компьютерных класса. 
И где-то там, в недрах этих свежих, модных PS/2, затесалась какая-то ранняя PC-реализация языка Smalltalk. На нашей кафедре этот язык считали очень перспективным, пытались в том числе и меня к нему подвязать (примерно, как к Prolog и экспертным системам) из самых лучших побуждений. Вот только во-первых, нормальной русскоязычной литературы по нему в природе не существовало, во-вторых, стать моим научным руководителем по тематике работы со Smalltalk никто не спешил (как я понимаю, никто вообще этой тематики в университете и не знал, только самые любопытные ходили вокруг и облизывались, но всерьёз трогать боялись).

А в третьих... Ну почитал я рекламные проспекты. Потыкал мышкой в окошки. И бросилась мне в глаза такая деталь Smalltalk, которую я уже описывал в разделе про язык Forth.
Smalltalk - это НЕ ЯЗЫК программирования! Это целостная виртуальная система. На Smalltalk нельзя написать какую-то программу и отдать/продать её желающим пользоваться. Можно лишь взять уже готовую систему (виртуальную машину) и дорабатывать её своими собственными расширениями, чтобы в итоге получить другую виртуальную машину с изменённым функционалом, но зато не полностью совместимую с прежней. Соответственно, практическая польза от Smalltalk крайне ограничена, в основном академическими, учебными задачами, когда хочется поэкспериментировать с "чистым" ООП, без "прикладных примесей". Ну ещё он может быть полезен в тех областях, где заказчик желает вместо программы, решающей его конкретную задачу, получить (получить, оплатить, изучить, освоить и т.п.) целиком новенький полнофункциональный виртуальный компьютер, несовместимый с тем компьютером, который у него уже куплен под эту задачу, но по цене не менее дорогой, чем уже имеющийся.

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

Ну и самое последнее, хочу упомянуть популярный язык Python, который мне в последнее время благодаря моим детям довелось попробовать. Нет, Шеркало, не беспокойся, писать о нём я здесь не буду. У меня уже был шуточный рассказ про Python, можно его перечитать. Добавлю лишь, несмотря на бытующее мнение о "простоте" Python, на самом деле, если копнуть чуть глубже, это весьма сложный, многослойный и достаточно запутанный язык.

ВСЁ.

Комментариев нет:

Отправить комментарий