Задачи, решаемые при помощи информационных технологий

К задачам учета впервые была удачно применена автоматизация вычислений. Первую счетную машинку, которая вошла в употребление, изобрел Блесс Паскаль (конец 16 – начало 17 вв. ).

Есть две группы задач учета:

· Задачи бухгалтерского учета. - бухгалтерский учет ведется по инструкциям, которые спускают нам компетентные органы. Нормы бухучета исходят от высшего руководства государства.

· Задачи складского учета - Складской учет ведется так, как нам хочется. Они носят исключительно рекомендательный характер.

Почему бухучет был автоматизирован успешно и почему так долго оставались неуспешными попытки автоматизации научных и инженерных расчетов?

Успешная попытка автоматизации бухучета была начата в конце 16 века – середине 17 века. Ведь бухучет появился в шумерские времена. Усложнение бухучета

в) Задачи имитационного моделирования

В реальном мире имеется некий объект (камень, планета, автомобиль). От нас требуется написать программу, которая вела себя точно так же, как и объект реального мира. Имитационное моделирование заключается в том, что оно практически всегда производится в реальном времени. Модель имитационного моделирования не обязана быть физически корректной, т. е. это означает, что мы не обязаны применять для имитационного моделирования ту модель, которая описана в учебнике по соответствующим разделам науки.

г) Задачи искусственного интеллекта

17. 11. 2013

Понять, какие существуют языки программирования и их методы

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

Вопрос: Как сохранять в компьютер что-либо кроме чисел (текст)?

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

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

Вопрос: Почему?

Ответ: Дело в том, что разработка нового языка программирования настолько трудоемка и настолько скользка теоретически, что за последние где-то лет 15-20 появилось несколько десятков тысяч новых языков программирования. И из них реально в практику вошли по разным оценкам (в зависимости от того, что считать вошедшим в практику) ну максимум 5 штук, т. е. вы можете представить свои шансы на успех. А язык программирования, которым пользуется только его автор, понятно, что это не язык программирования. Один человек на языке программирования программировать, как правило, не может. Он может начать, но не более того. А это момент весьма существенный.

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

Вопрос: А почему программирование в машинных кодах людей не впечатлило?

Ответ:

Представьте себе, что мы все-таки допустили ошибку в машинном коде. Какого будет в такой записи ее найти? Обратите внимание, что для текста программы очень важным фактором является не только простота написания, но и то, что называется ремонтопригодность. Что если там допущена ошибка или даже не было ошибки, и просто понадобилось, что-то поменять, потому что появились требования. Т. е. исправлять текст в машинных кодах очень сложно. Это видно с первого взгляда.

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

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

Вопрос: Почему язык Ассемблер не вошел в практику?

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

• Сложность – ну понимаете… во-первых, на современных ЯП программировать не многим проще. А во-вторых, дело даже и не в этом. Дело в том, что сложность программирования на языке Ассемблер нам только на руку. Ведь не забывайте, что на каком языке программировать, в общем-то, решает программист. И тот факт, что на ЯП Ассемблер программировать сложно – это означает только одно, что у программиста будет больше заработная плата. Так что, если бы дело было только в этом, вряд ли бы от Ассеблера отказались.
• Медленно писать – ну понимаете… На ЯП Си поверьте писать не быстрее.

На самом деле истинная причина лежит в другом.

Вопрос: Скажите, пытался ли из вас кто-нибудь читать сочинения типа эпосу Эльзаса Гильгамеша?

Ответ: Пытались, и это тяжело. И вообще, читать это мало реально. Вообще, из соображений банальной эрудиции понятно, что если бы этот текст было бы читать и правда тяжело, то вообще, мягко говоря, вряд ли. Не может такого быть, чтобы его на самом деле было трудно читать. Сколько лет эпосу Гильгамеша? 5000 лет. Ну, из них он 2000 лет пролежал в земле никому неизвестный, но ведь 3000 лет его, же читали. И мало того, что читали, так его же еще и на глиняных табличках переписывали. А вы представляете, что такое переписывать текст на глиняную табличку?

Так в чем же проблема? Почему читать невозможно?

• На самом деле, первую проблему, которую здесь указывают, это то, что мы его читаем в переводе на русский язык. Но ведь «Три мушкетера» мы тоже читаем в переводе на русский язык. И ничего, нормально читаем.
• Говорят, что это глубокая древность и изменились реалии. Опять-таки тут тоже можно возразить. Ведь реалии меняются не только за 1000 лет. Во времена Шекспира реалии тоже были совсем другими. Однако Шекспира тоже читали нормально.
• Непривычный слог. Но ведь слог вы видим переводчика. В том-то и фокус, что слог, который мы видим в тексте, это не тот слог, который был в оригинале. Тем более что, какой слог был в оригинале эпоса Гильгамеша – нам не известно.

Почему данный эпос так трудно читать? Он же нам известен только в написанном виде и как его произносили вслух, мы не знаем. А даже письменность современного русского языка не отражает точно произношение. Есть только 2 языка в мире, у которых письменность точно отражает произношение. В одном языке – совсем точно, а в другом почти точно. Это санскрит и эсперанто. Угадайте с трех раз почему? Дело в том, что оба эти языка искусственные и на них никогда не говорили. Поэтому письменность была разработана специально таким образом, чтобы отражать произношение точно. На остальных языках она никогда не отражала произношение точно. Всегда все было приблизительно. На самом деле здесь кроется простая разгадка.

Вопрос: Будет ли в наше время нормальный человек учить французский язык, чтобы в частности переводить «Трех мушкетеров»? Отнесетесь ли вы к этому нормально?

Ответ: Ну, конечно же, да.

Вопрос: А теперь представьте на минутку, что ваш товарищ вдруг начал учить шумерский. Вас это удивит?

Ответ: Вы не обязательно решите, что он сумасшедший, но, что вас это удивит – это 100%. В наше время нормальный человек шумерский язык учить не станет. В этом нет никаких сомнений. Но под словом «ненормальный человек» я, разумеется, не подразумеваю психически больного человека. На самом деле «ненормальный человек» означает всего лишь одно. Это означает, что у него восприятие и цели несколько отличаются от целей среднестатистического жителя России. Его не вдохновляет футбол или что-нибудь еще, а вдохновляет поковыряться в глиняных табличках.

Вопрос: А вот теперь подумайте, ведь вы наверняка за таким человеком замечали и раньше, но другое дело, что это мелкие странности. Допустим, он изъясняется как-то не так или финты ушами выкидывает. А теперь представьте себе, что этот человек какой-нибудь текст по-русски написал. Наверняка данный текст будет неудобопонятен в любом случае вне зависимости от того это эпос Гильгамеша или письмо приятелю. В любом случае его будет тяжело читать.

• Первая команда означает, что нужно написать число из ячейки с вот этим адресом и перенести это число в регистр процессора называемый Ax. Если смотреть по справочнику, то это число записано в 2 байта.
• Потом нужно взять число из ячейки с вот этим адресом и переместить (move) его в регистр Bx.
• Потом нужно к числу и регистра Ax прибавить число из регистра Bx. И результат сохранить в регистре Ax.
• Ну а потом из регистра Ax сохранить число где-то в памяти.

Вообще-то в переводе на нормальный язык – это означает, что мы должны взять 2 числа, сложить их и результат куда-то записать. Но так говорят нормальные люди, а если человек вдруг начинает это описывать таким образом – это нормальный человек? Вряд ли.

Теперь проводим следующий эксперимент. Берем нормального человека и заставляем его изъясняться на таком птичьем языке. Как вы думаете? У него крыша съедет через неделю или через месяц? Ну не больше 2 месяца, это точно.

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

Так вот язык Ассемблера вышел из употребления потому, что программисты не могли договориться с заказчиком. Они не могли попросту друг друга понять. Они слишком на разных языках разговаривали. Пока это было так, программирование мало имело касательства к реальной жизни. На самом деле программисты очень долгое время могли себе это позволить, потому что основным заказчиком программистов были военные. Однако несмотря на это с самого начала было понятно, что ситуация конечно нетерпимая и поэтому была сделана попытка разработать систему программирования, которая бы позволяла формулировать решение задачи если не на самом языке, то хотя бы на языке близком. Ну, например, в данном случае хотелось бы написать так. Взять число обозначенное «A», прибавить к нему число обозначенное «B» и результат обозначить «C». Обратите внимание, что я эту команду записал справа налево.

Вот такие языки программирования получили название «языки программирования высокого уровня». Это язык, который позволяет формулировать решение задачи на языке близком принятому в задаче. Двигаясь от машинных кодов к языкам высокого уровня и дальше, мы приобретаем с вами возможность решения прикладных задач, но кое-что мы с вами и теряем.

Вопрос: А можно ли в машинных кодах написать программу, которая в памяти изменяет сама себя?

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

Вопрос: А на ЯП Ассемблер можно ли написать самомодифицирующуюся программу?

Ответ: Нет. Почему? Да по одной простой причине. Потому что когда программа исполняется, у нас никакого языка Ассемблера уже нет. Ведь мы сначала перевели ее в машинные коды, а потом запустили на исполнение. Нет… Мы конечно же можем исправлять программу и в этом случае, но что мы должны писать в память? Машинные коды или текст на языке Ассемблера? Машинные коды, конечно. Это будет программирование в машинных кодах. Т. е. иными словами в машинных кодах мы это можем сделать. На ЯП Ассемблер самомодифицирующуюся программу нам заказана. Эту возможность мы потеряли.

Перейдя от ЯП Ассемблер к языкам высокого уровня мы потеряли еще одну возможность. Дело в том, что на ЯП Ассемблер есть правило:

Одна команда на ЯП Ассемблер соответствует одной программе в машинных кодах.

В частности это означает, что мы имеем с вами возможность не только перевести программу из ЯП Ассемблер в машинные коды, но и выполнить перевод назад из машинных кодов на ЯП Ассемблер. Т. е. выполнить то, что называется дизассемблированием.

Допустим, у нас есть программа в машинных кодах, мы ее переводим в ЯП Ассемблер и смотрим что она делает. Мы выполняем то, что называется обратной разработкой. Если программа написана на языке высокого уровня, то вообще говоря, такой возможности у нас нет.

Вопрос: Почему?

Ответ: Потому что вот такая команда на ЯП высокого уровня на самом деле соответствует не одной машинной команде, а целой куче машинных команд. И какая команда высокого уровня соответствует вот этой данной конкретной куче мы понять, вообще говоря, не можем. Т. е. это уже задача искусственного интеллекта. А как мы с вами знаем, задачи ИИ всегда решаются неоднозначно. Поэтому по факту мы не можем этого сделать, потому что неоднозначное решение нас здесь не устраивает. Кстати именно по этой причине программисты сопротивлялись переходу от машинных кодов к ЯП Ассемблер. А вот к языкам высокого уровня сопротивлялись переходу очень долго. Окончательный переход на языки высокого уровня произошел в конце 70-х годов (20 лет почти прошло).

Давайте теперь посмотрим, какие бывают ЯП высокого уровня. Это лучше посмотреть в историческом аспекте. Первыми языками высокого уровня были три языка, которые появились с очень коротким разрывом во времени:

• Первым был Фортран – это язык, предназначенный для научных и инженерных расчетов. Обратите, пожалуйста, внимание, что в литературе по языку Фортран можно прочитать, что он якобы является универсальным ЯП. На самом деле это не так. А пишут так потому, что когда эти книжки писались (а было это давно – 20 лет назад), то научно-инженерные расчеты считались основным применением компьютера. Т. е. считалось, что компьютеры нужны в основном для этих целей.
• С коротким разрывом во времени в США появился язык Кобол, предназначенный для финансовых расчетов. Кстати, это совершенно не случайно. Национальный менталитет он все-таки играет большую роль, потому что в США естественным применением чего угодно считается извлечение прибыли. Это совершенно необязательно означает (и не означает), что они двинуты на деньгах, а просто для них это естественный ход мысли. Может лично его это и не очень интересует, но его и не удивляет, когда это интересует других. Скажем в Европе это не совсем так. Скажем, в Германии извлечение прибыли уже не считается общепринятой главной целью. Там общепринятым считается, это что-нибудь строить, делать. Кстати, Фортран, отсюда, появился и в Германии. Это язык немецкого происхождения.
• А язык французского происхождения назывался Алгол. На самом деле, на нем никто никогда не программировал. Т. е. таких серьезных и практических задач на нем не решали. Он был предназначен изначально для публикации алгоритмов в научных журналах. Т. е. он был разработан таким образом, чтобы на нем можно было не только писать программы для компьютеров, но еще и публиковать алгоритмы в научных журналах. Несмотря на то, что на Алголе работающих программ почти не писали, тем не менее, Алгол все-таки, имеет очень большое значение для современного программирования и вот почему. Дело в том, что программисты во всем мире разрабатывали разные новые концепции, новые приемы программирования, дело пошло следующим образом. Т. к. Алгол был принят в научном сообществе, то делали следующую вещь. На базе Алгол сочиняли быстренько какой-нибудь ЯП в котором вот это новопридуманная концепция была реализована на уровне языка. После чего проверяли хорошая это идея или не очень. Если идея оказывалась хорошей, ее применяли в других языках программирования. Обратите внимание, что Фортран в момент своего появления существенно отличался от Фортрана, который использовали несколько позже. Поэтому различают Фортран 1, Фортран 2, Фортран 3, Фортран 4. Самый распространенный вариант Фортрана – это Фортран 4. Потом появился Фортран 77 ну и т. д. Смысл был в том, что в язык добавляли новые возможности. А эти возможности проверялись и обкатывались на вариантах языка Алгол. Отсюда Алгол породил целое семейство Алголоподобных языков программирования, из которых когда-либо использовались на практике только 2:
• Это язык Pascal, который в наше время используется только:

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

• в системе Delphi.
• Он используется по своему прямому назначению, а именно для сдачи ЕГЭ. Шутки шутками, но язык Pascal был разработан именно для приема экзаменов по программированию.
• И второй алголоподобный язык, который использовался, носит название ADA. На языке ADA программирует только одна организация в мире, а именно Пентагон. Некоторые считают, что неспроста. Они могли себе это позволить, и они это сделали.

Когда компьютеры стали продавать выяснялось, что значительная часть программ (70%), которые пишут для компьютеров служат не для того чтобы решать полезные задачи, а для того, чтобы управлять самим компьютером. И тогда фирма IBM решила сделать следующую вещь. Она решила написать программу, которая управляет самим компьютером с тем, чтобы вместе с компьютером поставлять потребителям. Т. е. чтобы компьютер приходил уже с готовыми программами, которые управляют компьютером. Так вот этот набор программ, которые управляют компьютером, называется операционная система. Кстати с тех пор разошлись пути системного программирования и прикладного программирования. Хотя очень долгое время они шли очень близко друг к другу, но все-таки системный программист и программист-прикладник с того момента стали разными специалистами.

Разница между ними примерно такая же, как между автомехаником и водителем.

Системный программист занимается тем, что для него главной целью является управление компьютерами. Отсюда он занимается тем, как устроено железо, какие, где есть регистры и т. д.

В прикладном программировании нас волнует, какие задачи мы на нем будем решать. Отсюда мы изучаем вещи совершенно разные. Мы изучаем математику и другие дисциплины.

Понятное дело, что ОС изначально писали на ЯП Ассемблер, но в силу той же самой причины о которой шла речь, что авторы операционной системы с трудом договаривались с заказчиком, фирма IBM решила разработать язык высокого уровня. Фирма IBM очень скромная фирма, поэтому она решила разработать язык высокого уровня, который с абсолютной скромностью заменил бы все языки программирования, т. е. чтобы вместо Фортрана, Кобола писали бы все только на одном языке. И, кроме того, чтобы он был пригоден к написанию операционных систем. Такой язык был создан, и фирма IBM со всей присущей ей скромностью назвала его PL1, что расшифровывается первый в мире язык программирования. На самом деле язык PL1 был построен по тому принципу, что все возможности, которые есть у компьютера IBM 360 должны быть отражены в языке PL1. Т. е. умеет компьютер IBM 360 выводить текст куда-нибудь (например, на экран), значит в ЯП PL1 должна быть команда вывода текста на экран и т. д. Это яркий пример того, что незнание истории от ответственности не освобождает. Если авторы ЯП PL1 немного изучили бы историю, то поняли бы, что делают глупость. За 70-80 лет до этого в Европе произошла история, которая известна всем современникам (в фирме IBM видимо о ней подзабыли). История примерно следующая – в сер. 19 века вся Европа была помешана на идее создания международного языка. Сама идея не нова, но тогда на эту тему в Европу был чуть ли, не массовый психоз. Такой язык действительно был создан, и получил называние «Волапюк». И автор языка Волапюк подошел к этому примерно с таким же подходом. В результате получилась следующая вещь. Когда 2 человека, знавшие язык «Волапюк» встречались друг с другом, они не могли разговаривать иначе, как уткнувшись в словарь, потому что язык оказался таким сложным, что выучить его оказалось никому не под силу. А с ЯП PL1 получилась примерно та же ситуация. Фирма IBM в какой-то момент выпустила любопытный документ, который назывался «Краткое руководство по языку PL1» - этот документ занимал 8000 страниц. Шутки шутками. Но в общем-то на языке PL1 действительно писали ОС для IBM 360 до тех пор, пока не исчерпался рынок компьютеров. Тогда фирма IBM для расширения рынка разработала компьютер, который назывался вот так: PDP11, и у него была советская копия СМ4. В отличие от БЭСМ4, которая была советской оригинальной разработкой независимо от американской, СМ4 – это советская копия американской PDP11. И встал естественно вопрос о написании для нее ОС (опуская все полудетективные истории с этим связанные). PDP11 в отличие от IBM 360 уже оказалась более доступной машиной и в отличие от первой ее ставили не только крупные организации, но и кафедры в университетах. Этот процесс развивался параллельно, что в США, что в СССР с разницей во времени примерно в месяц. До этих компьютеров в США дорвались студенты. А студент в США в те времена – это человек, который мог себе позволить страдать фигней, т. е. писать проект, который негарантированно принесет прибыль. Среднестатистический американец такого не может себе позволить, он вынужден делать только такие вещи, которые дают прибыль, иначе ему мало не покажется. А вот студент это запросто может сделать. Имногие студенты занялись тем, что начали писать ОС для компьютера PDP11. И многие из этих систем оказались лучше, чем та система, которую выпускала сама фирма IBM. Всеобщее признание получила система, которая называлась вот так: CPM. Тогда фирма решила поступить следующим образом: раз появилось столько хороших систем, то они, пожалуй, не будут дальше выпускать свою систему, а соберут идеи, которые выдвинуты при написании новых и напишут одну систему, которую в дальнейшем и будут поставлять. И короче суть в том, что за написание новой системы взялись 2 товарища, ныне широко известных товарища: Брайн Керниган и Деннис Риччи. Они взялись за написание этой системы и объявили сразу в первый же день, что в новой ОС не будет ни одной строчки написанной на языке Ассемблера. Вся система от начала и до конца будет писаться на языке высокого уровня. И естественно у них сразу же возникла проблема, на каком именно? Кстати, на самом деле вопреки ожиданиям их не забрали в сумасшедший дом, а по тем временам вполне могли. Из существующих языков подходящего не нашлось, потому что теоретически способный на это язык был ЯП PL1. Но с кратким руководством в 8000 страниц это народ не впечатлило. Тогда не долго думая Керниган и Риччи создан ЯП, который был разработан на ряде принципов, и эти принципы стали в наше время общепринятыми для всех языков. Господа, хочу обратить ваше внимание, что изначально в философии, позаимствованной у Фомы Аквинского применяемое в мире ИТ понятие «ПАРАДИГМА». Сам Фома Аквинский парадигмой называл способ нашего мышления, т. е. то о чем мы думаем, когда что-то делаем. Т. е. не то, как мы делаем наше дело, а то, как мы его мыслим. Примерно этот же смысл вкладывается и здесь. Парадигма обладает одной особенностью: Если мы ее принимаем, то мы ее принимаем навсегда. Мы ее не можем принять частично, т. е. приняли, значит попали на всю жизнь. Также она имеет некоторый простор для трактовок. Данный факт является очень важным, потому что парадигма описывает именно стиль мышления. Так вот Керниган и Риччи построили свой новый язык программирования на следующих принципах:

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

Дело в том, что когда Керниган и Риччи выдвинули второй принцип – это считали хорошей идеей, но все-таки лишь благим пожеланием. Т. е. непонятно, возможно это реализовать или невозможно, мы стремимся к этому. Но Алан Тьюринг доказал, что возможно составить ЯП таким образом, чтобы на нем можно написать все, что изначально не было в него заложено. Также ему принадлежит процедура проверки языка на полноту по Тьюрингу. Если у нас есть ЯП, оказывается можно за конечное число шагов проверить, является он полным по Тьюрингу или не является.

1. Также существует третий принцип: Принцип наименьшего удивления. Он означает, что команды ЯП должны вести себя так, как мы интуитивно от них того ожидаем. Он может трактоваться трояко.
1. Первая трактовка – менее всего должен удивляться тот, кто изучает язык программирования впервые. Т. е. сначала мы удивляться можем, но по мере изучения мы должны удивляться все меньше и меньше. Большинство ЯП идут по этому пути. Однако, самым ярким примером идущим по второму пути – это язык Ruby.
2. Вторая трактовка – наименьше удивляться должен тот, кто знает язык, а не тот, кто его начал изучать.
   Вообще принцип наименьшего удивления призван облегчить нам изучение языка и работу с ним. Но к сожалению, облегчить и то, и другое одновременно не получается, потому что мы все-таки изучаем новый язык, как ни крути. Тут чудес не бывает. А если бы мы облегчили и то, и другое, то это означает, что мы ничего нового не сделали.
   Соответственно, большинство языков программирования построено таким образом, чтобы их было проще изучить, а язык Ruby построен так, чтобы на нам было проще работать.
   Хочу обратить внимание, что и тот и другой подход неоднозначен, потому что если язык легко изучить, но на нем трудно работать, так ему грош цена. А если его невозможно изучить, то тогда что толку, что на нем легко работать.
   На самом деле истина лежит посередине. Все ЯП в той или иной мере стараются облегчить и то, и другое, но тем не менее такое различие есть. Поэтому если вы в дальнейшем собираетесь изучать ЯП Ruby, то имейте ввиду, что вам придется на его изучение потратить времени несколько больше среднего. А вот в ЯП Python ситуация обратная. Изучается он легко, но есть некоторые досадные помехи при работе с ним. Что касается ЯП Си, то сам по себе он не представляет сложности, но там сложность проистекает от того круга задач, который он решает, потому что Си – это язык системного программирования.

Кстати, тот ЯП который разработали Керниган и Риччи – это ЯП Си. А ОС, которая была разработана ими впоследствии получила название Unix.

Несколько слов об операционных системах прямо сейчас:

Господа, на самом деле в настоящее время все ОС следуют идеологически тем же принципам, что и Unix. Существует набор стандартов, которым по общепринятому мнению должна следовать любая ОС. Этот набор стандартов называется POSIX. Соответственно все ОС делятся на POSIX-совместимые и POSIX-несовместимые. На сегодняшний день POSIX-несовместимая система в живых осталась только одна, а именно Windows. Но я хотел бы обратить внимание, что система Windows является POSIX-несовместимой потому что, там принципы стандарта POSIX реализованы иначе, т. е. на самом деле Windows тоже следует этому стандарту, но не технически, а идеологически. Т. е. от сюда вывод: знание ОС Unix для программиста является необходимым, иначе он будет плохим программистом. Исключение из этого правила можно сделать только для тех, кто в дальнейшем собирается работать исключительно в системе 1C или в какой-либо другой. В любом другом случае – это знание необходимо, точно также как и знание языка Си опять же необходимо каждому программисту.

Что касается ОС Unix:

ОС в чистом виде в настоящее время вышла из употребления. Вместо этого существуют некоторое количество Unix-подобных ОС систем. Некоторое количество из этих систем (меньшинство из них) напрямую восходят к ОС Unix. Вот, например, система, которая является современным потомком Unix называется Solaris. Она одно время выпускалась фирмой «Sun Microsystems» и в настоящее время выпускается фирмой «Oracle». Однако большинство систем все-таки не восходит к Unix напрямую. Они были в соответствии со стандартом POSIX написаны независимо, тем не менее они являются Unix совместимыми, т. е. программы предназначенные для Unix на них будут работать. Из всех Unix-подобных ОС самой доступной является система Linux, а если точнее, то ее формально грамотное название вот такое: GNU Linux. Дело в том, что Linux – это название ядра ОС, а остальная часть называется GNU. Поэтому при желании изучить ОС Unix, конечно логично воспользоваться именно системой Linux, как самой доступной. Господа, здесь на этот счет у меня есть такая рекомендация. Если мы с вами берем ОС Windows, то Windows – он и в Африке Windows. Тут мы не ошибемся. Что касается Linux, то у него существует масса вариантов. Только ленивый не делает собственного варианта Linux. На самом деле все это никакого значения не имеет, т. е. все варианты Linux работают одинаково. Поэтому разница между ними в основном в том, что каждый такой вариант называется дистрибутивом. Так вот такие дистрибутивы либо имеют какое-то узкоспециальное назначение, либо отличаются вкусами создателя. Так вот, чтобы долго не обсуждать этот вопрос, если вы захотите ознакомиться с этой системой, то я вам рекомендую воспользоваться дистрибутивом, который называется «Kubuntu». Господа, я хочу обратить ваше внимание, что на самом деле Ubuntu (без первой буквы «K») – это два варианта одного и того же дистрибутива, т. е. Ubuntu и Kubuntu – два варианта одного и того же дистрибутива. Разница между ними в том, что Kubuntu имеет интерфейс (внешний вид), как Windows. Дистрибутив Ubuntu построен на другой оконной системе, поэтому там интерфейс иначе выглядит внешне, что довольно таки неудобно для тех, кто привык работать на Windows. НО! Ubuntu может работать на менее мощных машинах. К сожалению Kubuntu довольно требователен к скорости работы машины, поэтому может получиться так, что ваша машина просто не потянет Kubuntu.

Теперь вернемся к принципу чемоданчика

Дело в том, что принцип чемоданчика в том виде в каком его выдвинули Керниган и Риччи оказался не очень-то хорошим принципом. Вот такая экстремистская трактовка привела к тому, что в ЯП Си нет даже такого понятия, как текстовая строка. Казалось бы в этом с одной стороны нет проблем. Почему? Потому что есть второй принцип «чего в ЯП нет – мы можем это запрограммировать» и все в шоколаде. На самом деле, как выясняется мы не совсем в шоколаде, а несколько в другой субстанции. И вот почему. Господа, понятно, что та же текстовая строка нужна разным программистам, ну и все программисты кинулись ее программировать. И совершенно понятно, что все запрограммировали по–разному. И в результате получилось, что на ЯП Си существует проблема, которая существует и по сей день, а именно проблема совместимости библиотек. Разные библиотеки не совместимы между собой, поэтому они зачастую дублируют друг друга, делают одно и то же, и вот эта проблема, которая на ЯП Си и на ЯП С++ остается актуальной. Поэтому язык Си иногда в шутку называют его мокрым (wet = Write Everything Twice). Поэтому все-таки ЯП Си оказался единственным (первым и последним) в котором принцип чемоданчика применяется в том виде, в каком он изначально применялся. В других ЯП появившихся после Си трактовка немного изменена. И он трактуется, как принцип достаточности и необходимости. Кстати, такой необычный порядок слов объясняется тем, что называние заимствовано из языка эсперанто. Так вот данный принцип гласит следующее: В ЯП мы закладываем те возможности без которых нельзя обойтись, либо те без которых обойтись может быть и можно, но никто не обходится, т. е. которые всем нужны. Делается это для того чтобы то, что нужно всем – все не писали по 2 раза. Вот такой принцип в шутку называют сухим (dry = down repeat reserve). Вот эти особенности – это то, что входит в возможности самого языка. Принцип достаточности и необходимости на этом не заканчивается. Далее он гласит: Неотъемлемой частью ЯП является его стандартная библиотека. Те возможности, которые нужны, может быть не всем, но большинству, мы включаем в стандартную библиотеку ЯП. С тех пор начиная с ЯП Си и все последующие языки содержат при себе стандартную библиотеку. Так этот принцип и трактуется в наше время. Изучение любого ЯП обязательно включает в себя изучение его стандартной библиотеки.

Давайте пер