Изучение программирования

[fflatx]

Pavia в сообщении #833557 писал(а):

И судя по всему как и все самоучки путаете системное программирование с низкоуровневым.

Гм... Вы с чего-то взяли, что я самоучка и далее делаете из этого вывод, что вот это

Pavia в сообщении #833557 писал(а):

Так вот вначале вы продумываете структуру или организацию своей программы. Затем составляете алгоритм. А после уже его реализуете.

Система это все три части.
Структуру и организацию программы лучше всего разрабатывать при помощи шаблонов проектирования. Описывать структуру лучше всего при помощи языка UML или любым другим графическом языком.

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

мне неизвестно.
Увы, Ваши выводы совершенно ошибочны.

Pavia в сообщении #833557 писал(а):

А то что Кнут писал на ассемблере, так это только по тому что у него не было персонального компьютера.

Подозреваю, что Вы читали Кнута очень давно. Или совсем не читали.
Потому что он в своей книге объясняет, почему он выбрал вымышленный ассемблер.
И дело вовсе не в отсутствии компьютера.

Pavia в сообщении #833557 писал(а):

В этом плане Зубков как учебник ассемблера это плохой учебник. Дальше чем 1-2 функции вы по нему не напишите. Он вообще не учит писать функции.

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

-- 07.03.2014, 07:49 --

bin в сообщении #833593 писал(а):

Однако, судя по Вашим словам, Вы сами нуждаетесь в помощи.

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

bin в сообщении #833593 писал(а):

Прежде всего: откуда Вы взяли, что Си более низкоуровневый язык, чем Паскаль?

На самом деле это не я первый придумал. Си называют "самым низкоуровневым среди высокоуровневых языков". Разумеется, это образное выражение. Но доля правды в этом есть.

bin в сообщении #833593 писал(а):

Например, во многих реализациях Паскаля можно вставлять ассемблерные фрагменты...

Вы этим часто пользовались?
Интересно, как далеко вы уедете на этих ассемблерных вставках.

bin в сообщении #833593 писал(а):

Почему "Мышление в буквальном смысле отравлено Паскалем"?

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

bin в сообщении #833593 писал(а):

Могу предположить, что дело в типизации данных

Да, это одна из причин, но не единственная.

bin в сообщении #833593 писал(а):

Когда Вы занялись самообразованием

Это ошибка. Остаток абзаца не комментирую ввиду того, что выводы сделаны из ложного утверждения.

bin в сообщении #833593 писал(а):

Есть, конечно, особые случаи типа драйверов устройств

Именно это я и имею в виду прежде всего. Но не только это.

bin в сообщении #833593 писал(а):

а у Вас есть реальная необходимость написать свой оригинальный драйвер?

Да, есть.

bin в сообщении #833593 писал(а):

Очень опасная для начинающего идея работать с регистрами процессора!

Вы невнимательны. Где я говорил "работать"? Я говорил "изучать".
Я ведь не просто так привел слова моего собеседника о том, что ассемблер в нынешнее время нужен для того, чтобы читать, а не писать.

bin в сообщении #833593 писал(а):

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

Да дело-то не в этом.

bin в сообщении #833593 писал(а):

Современные компиляторы настолько хорошо оптимизируют код

Вот это как раз очень плохо в смысле учебного процесса.

bin в сообщении #833593 писал(а):

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

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

bin в сообщении #833593 писал(а):

Откуда такое утвержение?

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

bin в сообщении #833593 писал(а):

Никто, кроме Вас, не знает как работает мозг во всех деталях.

А с чего Вы взяли, что я это знаю?

-- 07.03.2014, 08:18 --

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

[Skeptic]

fflatx в сообщении #833628 писал(а):

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

Это вас заведёт в тупик. Прежде чем писать на низком уровне, до него надо опуститься, пройдя путь от постановки задачи, через детализацию (алгоритмизацию). Если очередная детализация реализуема на каком-то алгоритмическом языке, то на ней можно остановиться.
Чтобы сварить курицу, необязательно выращивать её из яйца.

[fflatx]

Skeptic в сообщении #833666 писал(а):

Это вас заведёт в тупик. Прежде чем писать на низком уровне

Ну вот, опять. Не писать на низком уровне. Читать. Смотреть, исследовать, анализировать. Для понимания процесса. Писать необязательно.
Конечно, можно и писать, но это потом, когда будут соответствующие задачи. А для начала только читать.

Skeptic в сообщении #833666 писал(а):

Чтобы сварить курицу, необязательно выращивать её из яйца.

Если задача состоит в том, чтобы сварить курицу, то необязательно.
А если задача понять, откуда эта курица взялась, то придётся узнать, что такое яйцо и что у него внутри.

[bin]

fflatx в сообщении #833628 писал(а):

Вы с чего-то взяли, что я самоучка и далее делаете из этого вывод [...]Увы, Ваши выводы совершенно ошибочны.

Т.е. Вы не самоучка. Тогда назовите, пожалуйста, кто и где научил Вас тому, что изучение программирования надо начинать с ассемблера? - Очень интересно узнать, кем и в каком учебном заведении продвигается столь необычная методика преподавания.

fflatx в сообщении #833628 писал(а):

На самом деле это не я первый придумал. Си называют "самым низкоуровневым среди высокоуровневых языков". Разумеется, это образное выражение. Но доля правды в этом есть.

Доли неправды в этом образе гораздо больше, выше я уже отметил:

bin в сообщении #833593 писал(а):

Помните при этом, что новая платформа - это почти новый ассемблер (в отличие от ЯВУ и от Си)

Т.е. в отличие от ассемблеров Си не привязан к железу (т.е. к архитектуре CPU) - именно поэтому ОС Unix было относительно легко портировать с PDP-11 на IBM PC, благодаря чему и началась мода на Си. Вирт сделал ОС на Обероне - по Вашей логике, Оберон низкоуровневый?

fflatx в сообщении #833628 писал(а):

Интересно, как далеко вы уедете на этих ассемблерных вставках.

Так же далеко, как и на ассемблере, и даже дальше, потому что в отличие от программы, написанной целиком на ассемблере, мне не нужно писать низкоуровневые процедуры ввода-вывода, в том числе и для распечатки промежуточных результатов, если в процессе отладки возникнет такая необходимость. Эта тема подробно освещается в специальной литературе, например, Юрий Магда, Ассемблер. Разработка и оптимизация Windows-приложений, (См. Гл.6 о применении ассемблера, встроенного в С++ и Delphi), СПб:БХВ-Петербург, 2003; Юрий Магда, Использование ассемблера для оптимизации программ на С++, СПб:БХВ-Петербург, 2004.

fflatx в сообщении #833628 писал(а):

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

В современных CPU и ассемблер скрывает массу деталей. Вы слышали о таких технологиях, как, например, конвейерная обработка инструкций? Из-за этих технологий эффективность CPU повышается, однако многие трюки ассемблерной оптимизации, которые удавались с примитивными процессорами, уже не работают. А какие еще детали, скрытые от программиста, ему могут быть нужны? Программист определил целочисленную переменную - ему нужен ее адрес? Есть такие средства в ЯВУ, но реальная необходимость в них возникает очень редко, и новичку они точно не нужны. Но если интересно посмотреть детали - перейдите в отладчик и смотрите, в каком порядке выполняются инструкции CPU. В отладчике Вы видите ассемблерный код, сделанный компилятором из Вашей программы на ЯВУ, только сделанный гораздо оптимальнее, чем это обычно делает человек, и без ошибок, свойственных человеку.

fflatx в сообщении #833628 писал(а):

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

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

fflatx в сообщении #833668 писал(а):

А если задача понять, откуда эта курица взялась, то придётся узнать, что такое яйцо и что у него внутри.

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

[fflatx]

bin в сообщении #833784 писал(а):

Тогда назовите, пожалуйста, кто и где научил Вас тому, что изучение программирования надо начинать с ассемблера?

Таково моё мнение на основе личного опыта.
А учили меня как раз-таки на Паскале.

bin в сообщении #833784 писал(а):

Помните при этом, что новая платформа - это почти новый ассемблер

С этим я и не спорю.
Ещё раз: я не призываю писать на ассемблере. Читайте внимательнее.

bin в сообщении #833784 писал(а):

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

Когда мне приходилось этим заниматься в своё время, мне было неудобно. И с чистым ассемблером было проще.

bin в сообщении #833784 писал(а):

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

Вот как раз для этого и нужно знать ассемблер. Чтобы увиденное в отладчике не повергало в ступор.
Поймите, я призываю знать ассемблер. И желательно эти знания приобретать с самого начала, а не через два года общения с Паскалем, когда уже сформировались привычки.
Кроме того, даже программируя на Паскале полезно задавать себе вопрос: Как моя программа работает на самом деле? Какой код выполняется на самом деле?
И здесь можно заглянуть в отладчик. И как только заглянул - стало ясно, что без знания ассемблера здесь делать нечего. Поэтому ассемблер нужен не потом, когда-нибудь, а значительно раньше. Нужно ли будет что-то писать на нём - вопрос отдельный. Но думаю, ТС и это пригодится.

bin в сообщении #833784 писал(а):

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

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

bin в сообщении #833784 писал(а):

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

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

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

[arseniiv]

fflatx в сообщении #833809 писал(а):

Но нужно четко понимать его назначение и границы применимости.

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

[fflatx]

arseniiv в сообщении #833838 писал(а):

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

Это верно.
Беда, однако в том, что начиная изучать программирование, студенты в большинстве случаев имеют дело с Паскалем и Дельфи. Проходит какое-то время, и перед ними ставится какая-либо системная задача. А они кроме Паскаля ничего не видели. И тут вдруг выясняется (внезапно, да?), что Паскаль неприменим к этой задаче. Нужен Си. Если к этому моменту сформированы привычки, то надо переучиваться, начинается ломка мышления, разрыв шаблона.
Ещё через какое-то время эти студенты касаются низкоуровневого программирования. Это уже ассемблер. И опять происходит ломка мышления, потому что насчет регистров процессора они до сего времени не заморачивались.
Так вот, если двигаться в противоположную сторону: от ассемблера к Си и далее к ООП, то будет значительно легче.
Но если уж никак нельзя придерживатья такой схемы, то хотя бы надо заранее иметь представление о том, какие есть языки программирования и для чего тот или иной язык предназначен.
Я лично знаю людей, которые научившись программировать на Паскале и далее в среде Дельфи, на этом останавливались. И действительно, переходить от Паскаля к ассемблеру может оказаться непросто. И чем позже такой переход совершается, тем сложнее преодолевать собственные (не всегда полезные) привычки и шаблоны.

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

[Pavia]

fflatx

fflatx в сообщении #833809 писал(а):

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

На Java роботы программируются.
Есть такое понятие система - целое, составленное из частей; соединение — множество элементов, находящихся в отношениях и связях друг с другом, которое образует определённую целостность, единство. [url]http://ru.wikipedia.org/wiki/Система[/url]

Так вот на высоком уровне это обычно проблемно ориентированные языки, затем идут объектно ориентированные язык, затем универсальные. И после низкоуровневые.
Причём хочу заметить что на низком уровне как правило пишут на Си. Пишут на нём потому что этот язык занял нишу и не пускает другие универсальные языки.
На ассемблере драйвера и микроконтроллеры программируют редко. Связано это с возможностью переноса кода с одного контролёра на другой. На ассемблере обычно реализуются интерфейсы, которые не встроены аппаратно, а потому критичны к времени исполнению. Или когда закупили микроконтроллёр, а программу решили изменить и надо уложиться в заданные ресурсы. Тогда прибегают к оптимизации и используют ассемблер.

Чуть выше идут драйвера компьютеров. Которые пишутся на си или си++. Вернее их почти никто не пишет, а использует готовое. А вот дальше уже реализуется объектное представление модели робота которое пишется либо на java либо на Си++, но также можно встретить и Delphi(Паскаль) и другие языки. Язык описания графического пользовательского интерфейса HTML, XML, AS3(Flash), различные RAD(не язык). А сверху ещё бывает предметоориентированный язык такой как SCADA или MathLab.

Так вот надо понимать на каком уровне вы хотите программировать роботов. И соответственно использовать нужный язык. Выбор языка написания это отдельный разговор.
Но нет проблемы в написании всей системы хоть на ассемблере хоть на паскале или том же си.
Тут дело в умении грамотно подходить к разработке и проектированию. А вот её лучше осваивать сразу.

[rockclimber]

(Оффтоп)

fflatx в сообщении #833865 писал(а):

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

А пример можно? Обещаю сильно не холиварить.

[warlock66613]

(Оффтоп)

Pavia в сообщении #833876 писал(а):

контролёр

Автобусный или троллейбусный? Или контролёр ОТК?

[fflatx]

(2 rockclimber)

rockclimber в сообщении #833893 писал(а):

А пример можно? Обещаю сильно не холиварить.

Не очень верю, что не будете холиварить, ну да ладно, полагаюсь на вашу честность.
Хотите примеру? Его есть у меня.
Были мы студентами. И учили нас программированию на языке Паскаль (впрочем, не только нас). Дружили мы с этим Паскалем года два. Потом подружились с Дельфи. А ещё примерно через год предстала пред наши очи такая дисциплина как СПО (системное программное обеспечение).
И дали нам задачу: Разработать программу для мониторинга операционной системы. Наподобие диспетчера задач Windows XP. Познакомились мы с функциями WinAPI, узнали как получить список процессов, данные об используемой памяти, как вытащить информацию из реестра и т.д. Это всё в Дельфи мы делали.
И вот дошло дело до мониторинга процессов.
Мониторинг должен работать в реальном времени, то есть предъявляемая информация должна обновляться.
Вариантов здесь нам предложили два:

Цитата:

1. периодическое выполнение снимка состояния системы и его анализ, для чего приложение, подключается к обработчику прерываний таймера. Это просто, но неэффективно – приложения не запускаются и не завершаются то и дело.
2. подключение к процедуре запуска и завершения процессов с помощью функции ядра PsSetCreateProcessNotifyRoutine(), описанной в Windows 2000 DDK, путем регистрации функции обратного вызова. Это не так просто, как хотелось бы, но более эффективно.

Первый вариант помимо того, что не рационален, так ещё и выглядит некрасиво: список всё время обновляется, если выделить какой-либо процесс, курсор слетает, мелькает полоса прокрутки, словом, ничего хорошего. Возникает идея обновлять не весь список, а только те данные, которые реально изменились. И здесь второй вариант выглядит многообещающим.
Я был любознательным студентом и поинтересовался, что это за функция PsSetCreateProcessNotifyRoutine() и что это за обратный вызов.
Как выяснилось, для реализации этого способа нужно знать Си и неплохо бы иметь представление о том, как создать драйвер для системы Windows XP. Ну то есть это явно не Паскаль.
Я не расположен спорить на тему, реализуемо ли такое на Паскале, однако замечу, что книга книга Шрайбера содержит очень много примеров кода и это код не на Паскале. Почему-то.

Признаюсь честно, второй способ я не осилил (да я и не надеялся особо), меня хватило на то, чтобы разобраться в примерах кода из книги Шрайбера, абсолютно не зная Си.
Для решения задачи я использовал первый способ, однако мне удалось чисто визуально избавиться от этого мелькания в окне процессов, в результате выглядело вполне прилично.

[warlock66613]

(Оффтоп)

fflatx в сообщении #833959 писал(а):

Первый вариант помимо того, что не рационален, так ещё и выглядит некрасиво: список всё время обновляется, если выделить какой-либо процесс, курсор слетает, мелькает полоса прокрутки, словом, ничего хорошего.

А компарить старый и новый список для нахождения дифа никто не догадался?

[bin]

fflatx в сообщении #833809 писал(а):

Таково моё мнение на основе личного опыта.
А учили меня как раз-таки на Паскале.

Теперь понятно: учили Вас по зарекомендовавшей себя методике, а тут Вы высказали личное мнение, что Вам кажется, что нужно учить в точности до наоборот

fflatx в сообщении #833809 писал(а):

Когда мне приходилось этим заниматься в своё время, мне было неудобно. И с чистым ассемблером было проще.

И в чем проще?

fflatx в сообщении #833809 писал(а):

Ещё раз: я не призываю писать на ассемблере. Читайте внимательнее.

fflatx в сообщении #833809 писал(а):

Вот как раз для этого и нужно знать ассемблер. Чтобы увиденное в отладчике не повергало в ступор.

Это совсем оригинально - изучать язык так, чтобы ничего на нем не писать!

fflatx в сообщении #833809 писал(а):

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

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

fflatx в сообщении #833809 писал(а):

Кроме того, даже программируя на Паскале полезно задавать себе вопрос: Как моя программа работает на самом деле? Какой код выполняется на самом деле?

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

fflatx в сообщении #833809 писал(а):

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

Увы, вписывается! В лучших традициях "древнегреческой софистики": имеется сборище философов, у каждого свое мнение по заданному вопросу, общее мнение устанавливается через голосование простым большинством. Случайным или неслучайным образом на философов роняют кирпич один или несколько раз или несколько кирпичей за раз - кого прибьет, тот голосовать не сможет, следовательно, результаты голосования можно изменить. Такая получается модель принятия решений посредством кирпича и не одного мозга, а многих, а Вы уверены, что в мозге каждого нет своего "кирпича"?

fflatx в сообщении #833809 писал(а):

Я сам не занимался вопросами ИИ и не знаю, какие языки там используются, но подозреваю, что это не Паскаль.

А вот я занимаюсь (и не только ИИ). Т.к. это очень трудные задачи, то языки там нужны очень мощные, надежные и высокоуровневые, и Паскаль один из возможных языков. Одна из самых известных задач ИИ - это программирование шахмат. Подумайте сами, что там делать на ассемблере и зачем? Среди множества литературы по этому вопросу отмечу книгу: Евгений Корнилов, Программирование шахмат и других логических игр, СПб: БХВ-Петербург, 2005. Эта книга содержит достаточно строгие формулировки и вместе с тем доступна каждому, кто умеет программировать, там много примеров на Паскале и на С++. Шахматы я не программировал, но есть программа трехмерных "крестиков и ноликов" и двумерной Гомоку $19 \times 19$ - количество вариантов превосходит шахматы, а программа обыгрыват Борландовскую в 8 случаях из 10. Другая более серьезная программа, из тех, что я делал по ИИ, это распознавание химических графов по их изображениям: есть изображение (растровая графика) структурной формулы углеродного скелета органической молекулы, где отрезками прямых обозначены связи (ребра молекулярного графа), а пересечения в концах отрезков - атомы углерода (вершины). Нужно построить матрицу смежности графа. Для решения этой задачи я использовал классический метод распознавания образов - преобразование Хафа (Hough Transform; есть в Википедии) для распознавания отрезков прямых. Реализация на Паскале, работает очень быстро при отличном качестве распознавания.

-- Пт мар 07, 2014 22:09:49 --

(Оффтоп)

fflatx в сообщении #833959 писал(а):

Мониторинг должен работать в реальном времени, то есть предъявляемая информация должна обновляться.

Вы не хуже меня знаете, что "форточки" не ОС реального времени, поэтому жестко завязывать на таймер частые обновления окна приложения нельзя (и ни Си, ни ассемблер в этом не помогут). В сходной задаче обновления "градусника прогресса" (нпр., при копировании файлов) организуют дополнительный поток (thread) и не только в "виндах", но и в MacOS 7.x такое делали и работало без мельканий при значительно меньшей тактовой частоте CPU. В Вашей задаче могут быть дополнительные сложности, но она решаема на ЯВУ. Я писал более простую утилитку по выводу списка процессов на Delphi-7 - прекрасно работает под ХР.

[Yuri Gendelman]

bin в сообщении #833784 писал(а):

Тогда назовите, пожалуйста, кто и где научил Вас тому, что изучение программирования надо начинать с ассемблера?

Это была популярная стратегия изучения программирования в те эпические времена, когда RAM измерялась в Килословах, компиляторы давали жуткий по качеству код, а ассемблеры (и архитектуры процессоров) были довольно просты.
IMHO, сейчас эта стратегия безнадежно устарела.
Хотя понимать ассемблерный код действительно полезно, начинать с ассемблера я бы не советовал.

P.S. Я уже давно не пишу на ассемблере, но иногда при отладке дизассемблирую код.

[fflatx]

bin в сообщении #833987 писал(а):

Теперь понятно: учили Вас по зарекомендовавшей себя методике, а тут Вы высказали личное мнение, что Вам кажется, что нужно учить в точности до наоборот

Да, именно так.
Потому, что мы столкнулись с трудностями при переходе от более комфортного (для человека) программирования на ЯВУ к менее комфортному программированию на ассемблере.
Ещё раз повторяю: движение в противоположном направлении было бы значительно легче.

bin в сообщении #833987 писал(а):

И в чем проще?

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

bin в сообщении #833987 писал(а):

Это совсем оригинально - изучать язык так, чтобы ничего на нем не писать!

Вы находите это оригинальным?
Тогда может быть, Вы объясните мне, как можно воспользоваться вот этим

bin в сообщении #833784 писал(а):

Но если интересно посмотреть детали - перейдите в отладчик и смотрите, в каком порядке выполняются инструкции CPU. В отладчике Вы видите ассемблерный код

не зная ассемблер?

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

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

bin в сообщении #833987 писал(а):

А Вы не думаете, что если начать с ассемблера, то сформируются другие, гораздо более вредные привычки?

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

P.S. Думаю, мне имеет смысл покинуть дискуссию. Безапеляционность Ваших заявлений не оставляет мне никаких шансов. Это не тот спор, в котором может родиться истина.
Автор темы запросил различные мнения по его теме. Мнения здесь представлены.
Делать выводы и выбирать предстоит ему. Мне больше добавить нечего.