Владик wrote:
> В>>Нынче модно ООП. Ни классический паскаль, ни Оберон для > демонстрации ОО-подхода не подходят. > S>Вообще-то даже Турбо Паскаль 6.0 — вполне неплохой язык для > преподавания. Он не настолько сложен, как С++, почти не содержит > магически работающих конструкций за сценой (типа того же сборщика мусора), > Я считаю, что наличие GC — только плюс для обучения. Не надо вводить > понятия времени жизни объекта и объяснять все связанные с этим грабли > прочию "магию".
Ага, а после этого нормальным программистам приходится отлаживать
приложения, где запросто сохраняются ссылки на мегабайтные документы в
какой-нибудь большой карте объектов — а потом забывают удалять их оттуда.
Здравствуйте, Cyberax, Вы писали:
C>Ага, а после этого нормальным программистам приходится отлаживать C>приложения, где запросто сохраняются ссылки на мегабайтные документы в C>какой-нибудь большой карте объектов — а потом забывают удалять их оттуда.
Я говорил о начальном этапе обучения. Код, написанный на этом этапе, идет в корзину по определению, и никто его отлаживать не будет.
Здравствуйте, Владик, Вы писали:
C>>Ага, а после этого нормальным программистам приходится отлаживать C>>приложения, где запросто сохраняются ссылки на мегабайтные документы в C>>какой-нибудь большой карте объектов — а потом забывают удалять их оттуда.
В>Я говорил о начальном этапе обучения. Код, написанный на этом этапе, идет в корзину по определению, и никто его отлаживать не будет.
Ну уж нет. Лучше дать людям во время учебы набить шишек с ручным управлением памятью. Пока они реальных проектов не завалили. Зато потом они будут ценить GC и языки с GC. А заодно не будут забывать ненужные ссылки занулять, чтобы memory leak-ов не было. Ведь они будут знать, что это такое.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Ну уж нет. Лучше дать людям во время учебы набить шишек с ручным управлением памятью. Пока они реальных проектов не завалили. Зато потом они будут ценить GC и языки с GC. А заодно не будут забывать ненужные ссылки занулять, чтобы memory leak-ов не было. Ведь они будут знать, что это такое.
Так и вижу: научная работа "О благотворном влиянии сообщения 'core dumped' на мОзги начинающих программистов"
Здравствуйте, Cyberax, Вы писали:
C>>> Надо сначала учить функциональные языки, чтобы было понятие
контекста вычислений и сторонних эффектов.
Владик> Я считаю, что наличие GC — только плюс для обучения. Не надо вводить
Владик> понятия времени жизни объекта и объяснять все связанные с этим грабли
Владик> прочию "магию".
C>Ага, а после этого нормальным программистам приходится отлаживать C>приложения, где запросто сохраняются ссылки на мегабайтные документы в C>какой-нибудь большой карте объектов — а потом забывают удалять их оттуда.
Так, все-таки. Сначала надо учить функциональные языки или управление памятью?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
E>>Ну уж нет. Лучше дать людям во время учебы набить шишек с ручным управлением памятью. Пока они реальных проектов не завалили. Зато потом они будут ценить GC и языки с GC. А заодно не будут забывать ненужные ссылки занулять, чтобы memory leak-ов не было. Ведь они будут знать, что это такое.
ANS>Так и вижу: научная работа "О благотворном влиянии сообщения 'core dumped' на мОзги начинающих программистов"
А следом, еще более серьезную: "О благотворном влиянии сообщения 'core dumped' на мОзги опытных программистов". Сомневаешься в ее актуальности? Ну посмотри, как VladD2 управляемый C# нравится.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Трурль wrote:
> C>Ага, а после этого нормальным программистам приходится отлаживать > C>приложения, где запросто сохраняются ссылки на мегабайтные документы в > C>какой-нибудь большой карте объектов — а потом забывают удалять их > оттуда. > Так, все-таки. Сначала надо учить функциональные языки или управление > памятью?
Сначала функциональные языки, чтобы понять что такое контекст
вычисления, а потом С++ и узнать про политики владения и ручное
управление памятью.
Здравствуйте, Владик, Вы писали:
В>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Спасибо за ответ, теперь буду знать.
В>Я правильно понял, что до "дела" (примера обероновского кода, на котором можно (якобы наглядно) изучать принципы ООП) так и не дойдет?
Так у Вирта же в его книге Programming in Oberon (2004) как раз на примере этих самых графических фигурок и написано. Чем Вам его пример не понравился? Или Вы не читали? Если не читали, то все книги можно скачать, например, от туда: http://www.oberon2005.ru/
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Так у Вирта же в его книге Programming in Oberon (2004) как раз на примере этих самых графических фигурок и написано. Чем Вам его пример не понравился? Или Вы не читали?
Не читал. Зато видел некоторые примеры ООП на Обероне, которые обсуждались здесь. Они были ужасны.
СГ> Если не читали, то все книги можно скачать, например, от туда: http://www.oberon2005.ru/
Целостного примера (от начала и до конца) там нет. Я попробую в свободное время собрать все вместе и сравнить. Но вам наверное это было бы проще.
Здравствуйте, Владик, Вы писали:
В>Целостного примера (от начала и до конца) там нет. Я попробую в свободное время собрать все вместе и сравнить. Но вам наверное это было бы проще.
Целостный пример (правда на Component Pascal) есть в системе BlackBox — это она сама (иходники открыты).
Документация к ней чем-то напоминает главы из книги "Паттерны проектирования" Гамма, Хелм, ...
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Целостный пример (правда на Component Pascal) есть в системе BlackBox — это она сама (иходники открыты).
Чтобы не путаться, хотелось бы оставаться в рамках одного языка. Возможно в Component Pascal все не так плохо и там для отражения концепций ООП есть человеческий синтаксис. Но в качестве языка для обучения ООП был предложен именно Оберон.
Здравствуйте, Владик, Вы писали:
В>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Целостный пример (правда на Component Pascal) есть в системе BlackBox — это она сама (иходники открыты).
В>Чтобы не путаться, хотелось бы оставаться в рамках одного языка. Возможно в Component Pascal все не так плохо и там для отражения концепций ООП есть человеческий синтаксис. Но в качестве языка для обучения ООП был предложен именно Оберон.
Здравствуйте, AndreyFedotov, Вы писали:
Т>>А объекты и в самом деле ерунда. Это вам и Пол Грем подтвердит.
AF> Объекты сами по себе — да. А вот умение понять что нужно сделать, построить правильно архитектуру и спроектировать систему с помощью объектов — вот это и есть суть программирования. И ей, увы, не учат
В книге Project Oberon (Вирт и Гуткнехт) как раз и рассматривается конкретный пример операционной системы, созданной с нуля. С объяснением архитектурных решений. С исходными текстами.
А Вы говорите — не учат.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, AVC, Вы писали:
Т>>>А объекты и в самом деле ерунда. Это вам и Пол Грем подтвердит.
AF>> Объекты сами по себе — да. А вот умение понять что нужно сделать, построить правильно архитектуру и спроектировать систему с помощью объектов — вот это и есть суть программирования. И ей, увы, не учат
AVC>В книге Project Oberon (Вирт и Гуткнехт) как раз и рассматривается конкретный пример операционной системы, созданной с нуля. С объяснением архитектурных решений. С исходными текстами. AVC>А Вы говорите — не учат.
Здравствуйте, AVC, Вы писали:
AF>> Объекты сами по себе — да. А вот умение понять что нужно сделать, построить правильно архитектуру и спроектировать систему с помощью объектов — вот это и есть суть программирования. И ей, увы, не учат
AVC>В книге Project Oberon (Вирт и Гуткнехт) как раз и рассматривается конкретный пример операционной системы, созданной с нуля. С объяснением архитектурных решений. С исходными текстами. AVC>А Вы говорите — не учат.
Ну а Линукс Торвальдс делает тоже на C++, только с гораздо большим количеством разнообразных примеров
Потом я же не утверждал, что нет информации — просто студентов действително не учат проектированию — на каком либо языке.
Re[7]: Мои впечатления о лекции Н. Вирта в ННГУ 26.09.2005
Здравствуйте, AVC, Вы писали:
AVC>Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>>Честно говоря, по широте выборки фич сильно напоминает приколы на тему "что общего между женщиной и пивом". ЗХ>>(я не отрицаю и не подтверждаю, что Ява ближе к Оберону, нежели к С++. но табличка эта смотрится несерьезно)
AVC>Возможно, она смотрится несерьезно. AVC>Но практически за каждым указанным в ней синтаксическим ( ="внешним") отличием между Си++ и Java/Обероном стоит различие механизмов языков и соответствующего им рантайма ( ="внутренних", существенных особенностей).
И начать стоит вестимо с глубоких концептуальных отличий, вызванных отказом от goto и выходом из цикла по continue с меткой
AVC>Возьмем, к примеру, отсутствие в Обероне и Java вариантных записей (union). AVC>Во-первых, такие записи могут использоваться (и используются) для скрытого приведения типов, что в корне противоречит концепции безпасности типов. Си++ это заботит мало (по-моему, ему на все наплевать ), а вот Оберон и Java — сильно "привязаны" к безопасности типов. AVC>Во-вторых, здесь есть прямая связь с реализацией сборки мусора. Дескриптор типа в Обероне включает не только адреса методов (type-bound procedures), но и смещения указателей в записи. Если бы во время исполнения программы по этому смещению могли находиться как указатель, так и переменная неуказательного типа, то механизм сборки мусора сильно бы усложнился, а то и вовсе стал бы труднореализуемым. Т.к. Вирт уже добавил в язык расширение типа ( =наследование), то потребность в вариантных записях, порождающих эти проблемы, отпала сама собой.
Ну если уже Вирт наследование придумал, то нам остаётся только удивляться — почему это C++ не объявлен сильно испорченным обероном?
Возникшая ситуация описана совершенно верно, однако она носит фундаментальных характер и с ней встреться любой проектировщик языка со сборщика мусора и у него будет выбор — отказаться от вариантных записей (тем паче что даже на презираемом вами C++ они встречаются крайне редко) или же — добавлять к union дополнительную информацию и механизмы, что бы различать — ссылка там или что-то другое. Первый вариант очевидно — проще
AVC>Но возникла другая проблема: а как эффективно определить динамический тип записи? AVC>(Напомню, что факт принадлежности переменной к тому или иному динамическому типу требует всего одного сравнения.) AVC>Решение следующее: каждый тип записи имеет свой уровень расширения. (Базовый тип — уровень 0, прямо ему наследующий — уровень 1 и т.д.) Указатели на дескрипторы с соответствующими уровнями расширения хранятся в массиве в дескрипторе типа. Когда мы проверям переменную на принадлежность типу, мы на самом деле сразу обращаемся к элементу массива с соответствующим индексом. Этот механизм реализован на Обероне настолько эффективно, что сначала в языке даже не было методов, а просто использовалась процедурная переменная в качестве поля записи. AVC>Легко также видеть, что подобная схема плохо сочетается с множественным наследованием. AVC>Т.к. в Обероне единицей инкапсуляции является модуль, а не класс, то множественное наследование оказалось излишним и не попало в язык.
Притом схема не зависит от того, класс это или модуль. А если добавить к этому клубок проблем, которые порождает множественное наследование, при весьма сомнительных преимуществах — то решение оставить множественное наследование лишь для интерфейсов, а для классов — ограничиться единичным наследованием.
AVC>И т.д. и т.п. AVC>Короче говоря, это целая система взаимоувязанных решений.
Да, естественно, любой язык или платформа — это комплекс взаимосвязанных решений.
AVC>И нигде до Оберона я не видел такого компактного и гармоничного решения основных языковых проблем. AVC>А табличка, возможно, и правда смотрится несерьезно. AVC>Ну и Бог с ней.
Ну и что? Решение схожих задач приводит зачастую к схожим результатам.
Простой пример. Есть две ящирицы — внешне почти не отличимы, причём даже для того, кто знает, как их отличать. При этом у них совершенно различный генетический код — одна из них ящерица, а вторая — саламандра. Схожие внешние условия сделали их — таких разных по происхождению — такими похожими внешне.
Это я к тому, что подобие ещё не означает происхождение из одного источника.
Здравствуйте, AndreyFedotov, Вы писали:
AF> Ну а Линукс Торвальдс делает тоже на C++, только с гораздо большим количеством разнообразных примеров
Linus известен своим радикальным неприятием C++. Где-то на kernel.org есть дискуссия со сторонниками введения поддержки C++ в kernel. Так Linus их там отфутболил конкретно.
Здравствуйте, eao197, Вы писали:
E>Зря ты так. Паскаль в качестве первого языка при программировании очень хорош. Почему бы его место сейчас не отдать Oberon-у. Язык, как мне представляется, простой, лаконичный, модульный, надежный. Для первого года обучения, имхо, то, что нужно. А затем уже можно на C++/Java/C# переходить.
ИМХО Java версий до 1.4 включительно достаточно проста, чтобы начинать сразу с нее. А вот C# далеко не лучший язык для начала (особенно 3.0, с него начинать даже вредно), тут я с тобой согласен.
... << RSDN@Home 1.2.0 alpha rev. 615 on Windows XP 5.1.2600.131072>>
Linus известен своим радикальным неприятием C++. Где-то на kernel.org есть дискуссия со сторонниками введения поддержки C++ в kernel. Так Linus их там отфутболил конкретно.
