OberonCore

Слабо помню, давно это было, вёл факультатив между дел и "от балды".
Hellow, world разбирался очень скоро. Последовательность изучения, говорю же, самая обычная - типы данных, линейные программы, развилки, циклы. Дальше процедуры, модули, файлы, написание простейшей базы данных file of record с текстовым интерфейсом на прямом доступе к видеопамяти , затем - написание игры Тетрис.
А на следующий год я занимался в основном с теми же ребятами, т.е. продолжение первого года. Новичков учил с нуля на ББ, а старичков переучил на него, и делали проект "Построение трёхмерных моделей зданий по XML-описанию". Ребята ездили в Москву на конкурс Intel-Авангард (где я в своё время выступал и взял первое место за программу распознавания текста - на Дельфе), но места не взяли.


Вам объяснить, почему взяли? Почитайте Страуструпа - обнаружите, что он некоторое время склонялся даже к Модуле-2 в качестве основы нового ОО-языка, и ТОЛЬКО ИЗ-ЗА ставки на армию Юникс-программистов взял за основу Си.
А дальше все остальные стали брать из-за ставки на армию С и С++-программистов
А если полезть в глубь времён, то легко обнаружим причины, почему синтаксис С именно такой, какой он есть. Это сейчас задним числом "философию" приплетают, а тогда был дохлый PDP-7, на котором надо было экономить каждый байт памяти, занимаемый исходником. На больших машинах таких проблем не было, и никому и в голову не приходило "криптографировать" синтаксис.

А почему малое количество книг по Си ориентировано на школьников - не потому ли, что сам язык в принципе на них не ориентирован?

Как базовый язык он, может, и неплох, но только не в обучении. Перед тем, как продолжить, я хочу заметить, что знаю синтаксические конструкции языка Си (то есть прочесть несложную программу), но не сам язык (написать программу). Однако, косвенно, по множествам сообщений с данного форума, имею о нём представление.

Если сравнивать сложность Оберона и Си способом, который выбрал Сергей Залманович Свердлов, то первый проще второго меньше, чем на 10%, но это разница, которая продазумевает совершеннейшее владение языком. Что это значит? А вот пример:
Я знаю один из языков, человек напротив - оставшийся. Каким-то образом оказалось, что мы имеем одинаковые умственные способности, одинаковое мышление (может, ещё что-то одинаковое, что имеет место для решения задачи). На дают одинаковое задание и мы начинаем действовать. Следует добавить, что задание не является специфичным, и, соответственно, не требует изворотов с моей или "его" стороны.
Теперь смотрим на действие со стороны задачи. Есть Оберон, Си и прочие условия. Прочие равные условия. В данной идеальной ситуации получается, что программа, написанная на Обероне по обобщённо-усреднённой оценке немного лучше, но меньше, чем на 10%.

Но каким путём это было достигнуто? Путём идеального знания языков программирования.

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

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

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

Ха! Вы думаете я так вам и поверил, что вы с первого раза сами поняли то, что там написано? Тогда вы - уникум! Потому, что В ЛЮБОЙ книге по программированию сигналов над Юниксами именно внимание Си-программистов каждый раз и привлекается к этой теме, и, по меньшей мере, абзац на это растолковывание отводится... :о)

Какой смысл Вы вкладываете в понятие "эффективность"? Скорость выполнения, объём EXE-шника, наглядность программы? Это больше зависит от алгоритма и качества компилятора, чем от того - Оберон или Си. Другое дело, что многие понятия из Си ближе к машинному коду (указатели, инкремент/декремент, организация массивов, управления памятью), что может дать преимущества по быстродействию.
Я полагаю, что оценка Сергея Залмановича Свердлова относится к сложности и разнообразию конструкций языка. Просто у Си они бывают более "заточены" под машину, а в Обероне - под человека.


Можно реализовать спиральный подход даже в пределах одного прохождения курса: например, постепенно вводить указатели (сначала &, потом сами указатели, потом адресную арифметику, затем динамические массивы, потом "запущенные" случаи вроде массивов указателей и указателей на функции).


Можете привести конкретные примеры (лучше не по указателям - в этой ветке уже показаны многие "приколы нашего городка" про это явление в Си)?


Какие именно? Мне приходит в голову только макропроцессор (те самые include) и операция взятия адреса &.


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


Кстати, сколько эта штука занимает на Паскале и Обероне? У меня на Си получилось около 210 строчек, чистого кода (т.е. если не считать инициализацию структур с фигурами) - где-то 150, GDI из WinAPI прятался "под колпак" учебной библиотеки (скоро опубликую); в программе нет учёта очков (специально не стал усложнять учебный пример).


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


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


Он создавался как универсальный язык системного программирования и он действительно не делался специально для обучения. Но и чем-то особенно страшным оно не является Вполне нормальный язык.

Кстати, как народ реагировал на среду BlackBox и на "пляски с бубном" при создании EXE-шников? Что ребятам больше нравилось - TP или BlackBox? И как решалась проблема с графикой?


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

Он НЕ создавался, как УНИВЕРСАЛЬНЫЙ язык СИСТЕМНОГО программирования. Он создавался именно, как язык системного программирования. Авторы пишут, "для облегчения переноса ПО". Но, первоначально - переноса.... только между машинами серии PDP. Это потом уже Интердата туда подключилась... Сосбна и сам синтаксис Си во многом (если не во всём! :о) возник на основе свойств архитектуры и СИСТЕМЫ КОМАНД PDP-шной линии DEC. Ото самое *dst++ = *src++ прямое следствие записи примерно такого же на автокоде PDP-11 (например).
Но это - частности отдельной архитектуры!
Паскалеподобные языки НЕ опираются на вычислительный инструмент. Они - общи. А, значит, апприори, заранее "более высокоуровневы". А, если ещё и над RISC-ом реализованы - 100 очков форы любому Си-компилятору дадут (при грамотно-проработанном оптимизаторе кода). А вот Си оптимизатору работы не оставляет... :о) Он - изначально "машинноориентирован". Сама заявленная идеология языка Си: программист не ошибается и знает, что делает и за него его вещи оптимизировать не надо! Он уже сам написал такой код, с такой степенью изощрённости и оптимизации, что после него - делать нечего! :о) Хотя картинка получается очень забавная : обучая Си, мы обучаем работе с одной архитектурой (PDP), над её реализацией над другой (например, x86)... Изврат-с...
То-то и оно! А мы ведь о методических ценностях и проблемах тут больше говорим! Я написал, что в книгах разъяснения по нашему примеру для не простых или начинающих Си-программистов писаны,,, Это обычно пишется в разделах, посвящённых достаточно низкоуровневым (опять!) средствам... А ими занимаются обычно далеко не новички...

Ха! А слабо ещё пару языков выучить? Как в детстве? А что, тряхните стариной!

Способность в таком объёме усваивать эмпирический материал, какой требуется для изучения естественного языка, - уникальная способность растущего детского мозга, которая утрачивается примерно к 7 годам жизни. Если вы на Си будете с ребёнком разговаривать и в игры играть до этого возраста, то может выйти толк. Представляю, как вы скажете малышу: "(0==a)?b+=a:a--;" - язык сломаете. Причём не только себе.

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

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

Да и вообще, одно дело разговорный язык на "интуитивном уровне" усваивать, когда ситуация является контекстом для фразы и одно с другим легко в мозгу связывается; другое дело - читать код программы, в котором намерения написавшего ещё только предстоит выяснить, а мотивы выбора той или иной языковой конструкции просто отсутствуют в тексте. Если нашли в одинаковой ситуации в разных местах эквивалентные конструкции, но разные, то где основания выбора, какую использовать в своей программе? Тоже на интуитивном уровне? Извините, программы писать на "интуитивном уровне" - это как? С отладчиком по ним потом бегать, искать, где интуиция подвела? Так и делают. А на мой взгляд, язык должен не только позволять ясно выразить мысль, но и не допустить неоднозначности. Язык программирования должен подталкивать к структурированию мысли, а не позволять, извините, перемешивать в одной конструкции while, switch и goto.

На одном и том же компиляторе Си при разных опциях оптимизации скорость может раза в 1,5 различаться, между компиляторами вполне может быть и раза в 2. Так что простор для оптимизации есть почти всегда.


Но ведь многие вещи из Си имеют прямое отображение на x86. Конечно, там не будут играть роль такие нюансы про инкремент/декремент, но вот +=, -= и т.п. имеют отображение на машинный язык x86. Кстати, в мире полно "извратов" - наши бытовые ПК на самом деле лишь эмулируют архитектуру Фон-Неймана (особенности конвеера, раздельный кеш для команд и данных, "тормоза" при самомодифицирующемся коде где-нибудь в цикле).


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


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


А мне нравится Коротко, ясно и по существу


Скорее так, чтобы уже в голове имелись шаблоны действий и восприятие некоторых конструкций на полуавтоматическом уровне. Я это к тому, что при написании текста программы не думаешь логически, почему указатель на функцию - это к примеру void (*f) (int a), не разбираешь на лексемы. Или вещь вроде for(i=0; i<16; i++) воспринимаешь как целостную конструкцию и настораживаешься, когда там что-то сильно другое.

Что по-существу-то? К b ноль прибавляется.

А ещё там есть простор для поисков перед чем и когда при объявлении volatile поставить, что бы и оптимизированный вариант работал ТАКЖЕ, как не оптимизированный... :о)


Фигня!
ВЫ конечно согласитесь, что а += б это совершенно тоже, что и а = а + б ?
Да вот беда: в выражении а = а + б разность между СМЫСЛОМ «а» слева и справа от «=» понимается «сполтычка», а ЧТО есть «а» в сокращённом сишном выражении... Это я объясняю «с дальним прицелом» - когда народ от Си к Си++ мигрировать будет... :о)
Или вы ограничиваетесь фразой «это ПРОСТО сокращённая форма записи»??? :о))))


А может лучше сразу не давать соблазн втулять «что-то сильно другое»? :о) На уровне синтаксиса...

Я знаю Просто ребус понравился.

Мне вот ещё нравится такая метода обнуления переменной: a ^= ++a;


Это Вы про перегрузку операторов?


А может быть, я специально хочу забацать что-нибудь эдакое. Хотя я понимаю, что это скорее "излишества нехорошие".

Холодно!

Так вы ж только что сами высказали опасения на счёт напряжения!!!!!
Я понимаю, что "чукча - не читатель", однако и свой код когда-то будете читать и сильно удивляться! Увегяю вас, не вы - первый! :о)

Да, паттерны - это хорошо. Они позволяют использовать хорошо изученное, привычное подмножество конструкций языка, и настораживаться при необычных конструкциях. Аргументация в пользу Оберона против Си как раз и заключается в том, что из Оберона исключена избыточность и оставлен только минимальный набор паттернов. Я, например, не использую FOR, всегда пишу WHILE. Просто для единообразия. И всегда настораживаюсь, если в конце нет INC(i). В этом смысле первый Оберон мне даже больше нравится (там не было FOR).

Что касается Си, то здесь использование привычного подмножества - это не только хороший стиль но и проблема выбора:
if (0==a)
if (1==++a)
if (a)
(a)?...:...;
(0==a)?...:...;
У вас один привычный набор, у другого - другой. Читать чужой код становится проблематично: постоянно приходится настораживаться. Да и свой собственный код через пару-тройку лет может показаться незнакомым, привычки-то могут меняться, ведь нет однозначной аргументации в пользу того или иного паттерна среди совокупности возможных. Сегодня выбрали так писать, а через год по-другому покажется красивее или удобнее.


Так. Мы про обучение в школе говорим, где важна простая база, или про ioccc?

Всё-таки я стараюсь не злоупотреблять гибкостью Си в коде. Хотя при составлении методичек я приводил несколько "весёлых" примеров в дополнительных задачах (вроде префиксного и постфиксного декремента/инкремента). Сейчас читаю раздаточный материал, и понимаю, что забавные for попали и туда (в очень малом количестве):



Это, конечно, ещё не "чукча - не читатель, чукча - писатель", но уже приближается. Я то полагал, что можно их оставить в дополнительных примерах, но учительница посчитала иначе.


Так что же именно Вы имели в виду?

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

Ну, к примеру, круглые скобки:

Просто не рискнул древнегреческий с санскритом предложить.

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

Среда понравилась - играцца с документами можно, особенно понравилось автоматическое связывание контролов с переменными.
Экзешники окончательно мы и не собирали - а на шо воно надо? Объяснил, что никому не нужно, а когда очень нужно, то можно - вот и всё.

С графикой - отображения писали, уже после того, как познакомились с ООП. Сейчас, конечно, оптимум - использовать в школе графику BlackBox Lab. Но тогда его ещё не было...

Эээ, батенька мой, а Вы внимательно читали, что Вам написали? На RISC-архитектуре никакого простора для оптимизации не будет. Процессоры Intel - всего 1.5% рынка процессоров. Встроенные системы проникают теперь повсюду. Да и невстроенные RISC-и, вроде машин бизнес-класса от IBM и HP, только у нас пытаются ПК-шками эмулировать.
Даже на CISC Oberon можно оптимизировать лучше, чем Си - хотя бы из-за запрета неструктурных операторов выхода из цикла, которые сплошь и рядом используются в Си. И это доказали в своё время XDS.

Мне тоже целый год нравилось. Пока внезапно не пришло понимание, что результат этого года - программа в 25 тыс. строк - нашпигована ошибками, которые проявляются непредсказуемо, и выявить их в приемлемые сроки нет никакой возможности - а любое расширение системы только усиливает её дырявость. Плюс всё это было помножено на компилятор от Борланда, который сам по себе обладает замечательным свойством вносит глюки. "Нет уж нет уж - нафик нафик"

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

В повторение уже сказанного Владимиром Лосем. Что Вы приводите тривиальные примеры? На Обероне я легко обучу любым указателям/массивам, т. к. есть только одно правило ARRAY OF и POINTER TO. А на Си либо объясните и никто не поймет (да и сами Вы, я вижу, не в восторге от этих правил, т. к. предпочитаете мыслить паттернами-примерами), либо нагрузите кучей примеров.

И сравните лучше вот это:
VAR
a: ARRAY 10 OF POINTER TO Rec;
a1: POINTER TO ARRAY 10 OF Rec;
b: ARRAY 5 OF POINTER TO POINTER TO Rec; (* в Обероне такой тип не возможен - для наглядности *)
b1: POINTER TO ARRAY 5 OF POINTER TO Rec;

Rec *a[10];
Rec (*a1)[10];
Rec **b[5];
Rec *(*b1)[5];

А если эти типы прочитать - по русски - что ближе?
a - массив из 10 указателей на Rec
a1 - указатель на массив из 10 Rec
b - массив из 5 указателей на указатель на Rec
b1 - указатель на массив из 5 указателей на Rec

Обсудим ещё один момент: синоним типа. Как Вы расскажете про объявление синонима типа? Если я хочу завести новое имя Name для типа T - что мне делать?

Тут всё просто - либо typedef, либо #define. Подобная технология используется в заголовочных файлов для программирования под Windows.


Значит, нужно будет ограничиться некоторым подмножеством возможных вариантов (причём как в Си, так и в Обероне). Не знаю, зачем такие вещи нужны в школьном курсе. А без примеров можно не понять даже текст на Обероне. Да и даже в Си синтаксические правила не очень сложные, они просто дальше от естественного языка; зато паттерны выучить проще.