> Вдвойне хорошо, что это книга по бесплатному паскалю - больше не нужно ставить крякнутый Дельфи (это касается и преподов!)

Вы большой оптимист.

И еще вот: http://www.polit.ru/science/2008/08/20/programmist_print.html

>pascal для AVR

http://www.mikroe.com/eng/products/view/227/mikropascal-pro-for-avr/
http://www.digitalgraphics.com.au/elabavrco.html http://community.freepascal.org:10000/bboards/message?message_id=273303&forum...
http://users.iafrica.com/r/ra/rainier/

Oberon:
http://svn.assembla.com/svn/oberonru/trunk/
http://a2os.org.ua/forums/forums.php?forum=17

>Э, я может тебя не понял, но в Go такое тоже делать нельзя.

по-моему, можно: http://golang.org/doc/effective_go.html#methods

спецификация тоже не отрицает: http://golang.org/doc/go_spec.html#Method_expressions
что не удивительно, если func (tv T) Mv(a int) это синтаксический сахар для func(tv T, a int) int , правда не совсем простой —
см. например про то, как устроены интерфейсы в go http://research.swtch.com/2009/12/go-data-structures-interfaces.html

В оос http://docs.ooc-lang.org/language/syntax.html#function-call http://docs.ooc-lang.org/language/metaclasses.html#under-the-hood http://docs.ooc-lang.org/language/bindings/simple.html

 — тоже похожий подход — но другим путём, в итоге можно сделать дженерики http://docs.ooc-lang.org/language/syntax.html?highlight=generics#generic-func...

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

эти обёртки — интерфейсного типа. Могут быть пустыми, только для указания конкретного интерфейса. Но посмотри, как реализована таже печать fmt, Writer: это интерфейс, который можно прицепить к любому типу, в т.ч. и к базовому

> см. например про то, как устроены интерфейсы в go http://research.swtch.com/2009/12/go-data-structures-interfaces.html

см. пример: func ToString(any interface{}) string и пример с шифрованием: http://golang.org/doc/effective_go.html#interfaces  — интерфейс выглядит как базовый тип, только обёртка через typedef для читаемости

>http://www.upweek.ru/edinaya-seriya.html

Вторую часть давай!

Ершов загубил производство ЭВМ и написание системного софта в СССР (хотел как лучше, получилось как обычно). Остальное фигня.

это как-то связано с одержимостью идеей единой системы ? По ссылке и сейчас сокрушаются об отсутствии *единой* системы вводных курсов (читать от «Выводы для системы образования» минус один раздел) — в некотором, роде пытаются возродить ЕС на базе паскаля и блекбокса. Оберон для оберонки.

Идея о такой структуре(вводный+факультатив) — здравая, но... вот это упование на единую платформу немного смущает.

К примеру, программирование устройства ОС на Оберон.. ну да, есть Oberon-07,A2, и BlueBottle. Но как показать на обероне, к примеру, необходимость и способы реализации того же POSIX api, если оберон — это такая «вещь в себе»? Писать ELF линкер на обероне? Зачем, если у них там есть стандартные велосипеды gnu ld и даже свои ldscripts писать — это уже велосипед, экзоядра с подсистемами ядра как библиотекой и проч.? (хотя в блекбоксе есть и написание COM серверов на CP, и генерация standalone exe/dll, т.е., теоретически экзоядро с POSIX api как библиотекой возможно, практически та же BlueBottle/Aos вещь в себе, которая, как матрёшка, находится в другой такой вещи — обероне)

Или вот, дженерики и макросы.. ну да, есть в природе Java Syntax Extender, или варианты с Stratego/XT и т.п. Но с позиции оберона — макросы, дженерики, POSIX api и FFI — YouAin'tGonnaNeedIt, и это смущает.

Что-то ничего путного не вышло из ЕС, когда стали не развивать своё, а копировать IBM XT.

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

Кто там ноет про русскую народную ОС — посмотрите, как японцы делают: сначала спеки как метасистема, потом уже конкретная система как реализация этих спеков(и не одна, а целое семейство).

<<TRON EC ЭВМ>>:

Resistance is futile. You will be assimilated. All your bases are belong to us.

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

а русский народный фотошоп уже был: http://user1.cooler-online.ru/blog/11136.html

>Это всё субъективно. По мне так в этом плане Паскаль - говно.

Я говорил не о преимуществах Паскаля вообще, а о преимуществах перед Си и Си++ с точки зрения обучения.

>Инкапсуляция должна быть в голове

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

Вычислительная математика мало кого интересует.

Ну, еще остались заповедники, где софт называют «математикой» ;) И стратегия обучения студентов, вроде бы как не поменялась.

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

«... несомненно, что толстовская система имела аристократические тенденции в самом неприглядном смысле этого слова, но все-таки главная и самая существенная ее идея заключалась не в этом, а в борьбе с нигилизмом»

На примере с Лениным, не очень-то получилось. Илита!111

>Можно, если функции работают с указателем на структуру. А как правило так и есть.

И преобразовывать указатель из одного типа в другой внутри функции?

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

> в Си нет ООП

А где оно есть?

В Smalltalk есть ;-)

Странно требовать наличия ООП от процедурного языка, не правда ли?

> Мой диплом представлял оптимальный алгоритм решения задачи о назначении и состоял из полутора страниц.

круто. Круче только диплом по атеизму «БОГА НЕТ».

> И преобразовывать указатель из одного типа в другой внутри функции?

зачем? преобразовывать указатели типа — это втебе уже говорит паскалист. Сишечник интуитивно знает, что можно присваивать указатели разных типов друг другу, потому что все указатели одного размера, поэтому можно скормить разным функциям указатели разных типов.
Поэтому абстракция «указатель» в этом месте хрупкая и ломается. А абстракция «символ» например, не ломается, потому что значение и указатель на значение связаны «символом», как и не ломается абстракция «ссылка» (значение и тип значение).

Это значит, что удобнее сидеть на стуле с кнопкой? По-моему нет.

зависит от жопы.

> Странно требовать наличия ООП от процедурного языка, не правда ли?

не правда. ООП и процедурность — вещи ортогональные, и если язык достаточно ортогонален, в нём естественно реализуется и то, и это.

Появились компьютеры «общего пользования с системами разделения времени. Это IBM 360, ICL 4-70, ЕС ЭВМ. Писать в кодах для таких машин стало принципиально невозможно, и на передний план вышел (как наименьшее зло) язык ассемблера. Были и другие языки программирования (Фортран, Кобол, Алгол, PL-1), но они не позволяли эффективно контролировать оттранслированный код. Мой сосед по кабинету в ИПУ М. Фурман, на мой изумленный вопрос, как ему удается программировать на PL-1, просто заметил, что он в уме транслирует все операторы, прежде чем написать их.

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

фраппирую. Сразу видно, что математики такие не лингвисты. «Насобачились» означает «овладеть языком», а не «понять и проникнуться». Негодуэ.

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

ёлки! ну и почему он не додумался до DSL, а мыслил в терминах языка программирования и его примитивов и ограничений? Влияет ли на это 15 лет ассемблера?

>Странно требовать наличия ООП от процедурного языка, не правда ли?

Ви таки не поняли трагичности моего въброса. Я придерживаюсь мнения, что оопе - не фича языка, а склад мыслей. Писать в ОО парадигме на Си никто не запрещал

>Я говорил не о преимуществах Паскаля вообще, а о преимуществах перед Си и Си++ с точки зрения обучения.

Преимуществ Паскаля перед Си и Си++ с точки зрения обучения нет

>>Инкапсуляция должна быть в голове

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

Аха, а вы, я смотрю, ратуете за снижение порога вхождения в такое искусство, как Программирование? Ну-ну

>И преобразовывать указатель из одного типа в другой внутри функции?

Зачем? man forward declarations & Pimpl

хотя дальше он именно в терминах DSL и рассуждает. «Слова нет, а жо^W DSL есть».

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

для того, чтобы «делать это с другого уровня» не обязательно «просто насобачиться». Есть путь проще — достаточно только выбрать правильный, достаточный набор абстракций (ну да, а чтобы выбрать правильные абстракции/дырявые уже и нужно насобачиться).

Вообще интересно что было бы, если бы структуральнейшие лингвисты программировали. Только не Ларри Волл с перловкой, воплотивший всё коллективное бессознательное, а осознанные моделисты-конструкторы.

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

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

Преимуществ Паскаля перед Си и Си++ с точки зрения обучения нет

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

тыц:

Было обнаружено, что плотность ошибок в больших программных текстах на языке Си при прочих равных (квалификация разработчиков, объем и сложность ПО, время разработки и т.п.) в 16 раз превышает плотность ошибок в программах на наиболее совершенном потомке Паскаля Обероне [24].

картинка

потом, проблемы у нормальных людей (профессиональных программистов) и непрофессионалов) — разные

логично, что и обучать их нужно по-разному.

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

(Сам я тут больше соглашусь не с фанатами паскаля и оберона, а с Кеном Томпсоном «почему паскаль не мой любимый язык». Назовите меня «партизаном от программирования», мне просто не все языки одинаково удобны: ругаться лучше на немецком, а признаваться в любви на итальянском)

> Писать в ОО парадигме на Си никто не запрещал

да, только отсутствие инкапсуляции, наследования (полиморфизм положим, есть в указателях — но слишком общий, а его нужно конкретно ограничить иерархией наследования) — будет мешаться на каждом шагу, пока не напишут велосипед в духе GObject или libobjc.so.

http://www.upweek.ru/edinaya-seriya-2.html

Там есть части вплоть до пятой, и на ней история обрывается...

>зачем? преобразовывать указатели типа — это втебе уже говорит паскалист. Сишечник интуитивно знает, что можно присваивать указатели разных типов друг другу, потому что все указатели одного размера, поэтому можно скормить разным функциям указатели разных типов.
Поэтому абстракция «указатель» в этом месте хрупкая и ломается.

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

Это значит, что удобнее сидеть на стуле с кнопкой? По-моему нет.

зависит от жопы.

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

>не правда. ООП и процедурность — вещи ортогональные, и если язык достаточно ортогонален, в нём естественно реализуется и то, и это.

Вроде что-то пытаешься сказать, а сформулировать у тебя не получается. ФГМ?

Что там реализуется или не реализуется меня не интересует. ООП хоть на ассемблере можно реализовать, хоть в машинных командах. В таком случае это будет «ручной» ООП, поддержка которого будет находиться у программиста в голове.

Язык со встроенными средствами ООП автоматизирует работу. В Си средств ООП нет, поэтому это не обектно-ориентированный язык. Программировать в ООП-стиле можно, но не средствами языка, а только «вручную».

>Ви таки не поняли трагичности моего въброса. Я придерживаюсь мнения, что оопе - не фича языка, а склад мыслей. Писать в ОО парадигме на Си никто не запрещал

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

>Преимуществ Паскаля перед Си и Си++ с точки зрения обучения нет

Преимуществ Си и Си++ перед Паскалем с точки зрения обучения нет.

Я тоже умею делать заявления без попытки их обосновать.

>Аха, а вы, я смотрю, ратуете за снижение порога вхождения в такое искусство, как Программирование? Ну-ну

Сколько пафоса, какой высокий слог! «Илитарий» и «небыдло» в одном лице?

Вот не люблю я таких «программистов». По сути являясь до сих пор ремесленниками, они мнят из себя чёрти-кого, людей высокого искусства.

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

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

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

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

http://oberoncore.ru/education/a-024-conf-pm-2007-eie

> В Си средств ООП нет, поэтому это не обектно-ориентированный язык. Программировать в ООП-стиле можно, но не средствами языка, а только «вручную».

те же vala или ooc транслируют ООП код в С. Получается не совсем вручную, и не совсем автоматически.

В Си средств ООП нет, поэтому это не обектно-ориентированный язык.

объектно-ориентирован не язык С, а конкретная программа, написанная в парадигме ООП. Такая программа может быть написана и на языке без поддержки ООП, но в стиле ООП.

инкапсуляция, положим тоже в си есть — static функции в модуле (private для модуля), и pimpl.
С наследованием и полиморфизмом, учитывающим наследование — проблемы.
Хотя наследование можно сымитировать тегированными записями, в духе винапи: первый элемент: sizeof(class), второй-- typeinfo, далее методы как поля структуры типа указатель на функцию с совместимой сигнатурой.
Потомки имеют разный sizeof (> предка) и совместимое typeinfo, больше свойств, плюс к свойствам предков; обратившись через указатель к потомку как к предку, мы обрабатываем запись с другим sizeof предка, который короче, и поэтому не можем изменить другие данные, кроме данных предка. То есть, наследование.
Итого, полиморфизма, учитывающего наследование не хватает, для полного счёта. Pipml(и совместимые по pimpl указатели) ?

Ага, клёво, а причём тут это всё? На всякий случай, повторю:

Инкапсуляция должна быть в голове

В каждую голову инкапсуляцию не вложишь.

...

Если для программиста инкапсуляция заканчивается языковыми средствами (как private/public/protected), то это хреновый программист.

Ну так я и говорю, что это всё глубоко субъективно.

Когда я учился классе в пятом/шестом и у меня были перед глазами примеры одинаковых программ на паскале и Си, меня в первую очередь привлёк именно Си своею лаконичностью и изящностью синтаксиса.

Да, да, { и } перевесили begin и end. begin и end - это вообще для графоманов-гуманитариев.

>Объектно-ориентированный язык - это язык, имеющий встроенную поддержку ООП

Спасибо, Кэп. Но я придрался ко фразе «в $language_name {нет|есть} ООП»

>те же vala или ooc транслируют ООП код в С

ИЧСХ, любой язык так или иначе транслируется в поток машинных инструкий, вот незадача-то!

Сделай одолжение, забудь ты слово ООП. Это всего лишь мелкая служебная концепция, основанная на субтиповом полиморфизме. И реально, не стоящая даже выеденного яйца...

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

Хорошо бы хоть в офисных программах ориентировались после выпуска из школы ...

Блок схемы рисовать на доске до просветления и никакие лицензии не нужны, красота (да и компьютеры, в принципе тоже) ....

Не люблю паскаль :-!

>_<

Pascal — очередное чудовище, которое вдалбливают в головы русских детей, наряду с мифом о татаро-моглольском иге и тем, что до насильственной христианизации у русских не было письменности!

Дополню свой пост в защиту Паскаля

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

http://www.stolyarov.info/files/anti_c_v03.pdf