ВНИМАНИЕ!
Каждый, кто хочет написать ответ в эту ветку, должен:
1) прочитать её полностью — возможно, что ваши мысли уже были изложены три года назад
2) задуматься — а кто вообще прочтёт ваш ответ среди 850 сообщений, в дискуссии, которая три года назад завершилась
3) сохранив намерение писать ответ — создать новую дискуссию и излагать свои мысли там
А пока у нас нет механизма замораживания — модераторы будут нещадно пресекать новые ответы.
— Кодт
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Конечно, в такой постмодернистской академической среде профессор давно перестал быть мудрецом, углубляющимся все дальше в свой излюбленный предмет в тиши кабинета. Современный профессор — это менеджер большой команды исследователей, хваткий добытчик грантов, поддерживающий тесные связи с ключевыми огранизациями-источниками финансирования, и неутомимый автор волнующих проектных заявок и впечатляющих отчетов о достигнутых успехах. В этом высоко конкурентном бизнесе было бы самоубийством растрачивать время на размышления о том, как лучше рассказать о простых вещах массе начинающих. Когда речь заходит о материалах для курса, программном обеспечении и т.п., очевидный выбор — взять то, что лежит на полке и заведомо принято всеми остальными. В этой борьбе за успех и выживание лучше всего примкнуть к толпе. Достижения измеряются размером команды, количеством публикаций, цитирований и докладов на конференциях, и использованными ресурсами — но не преданностью делу преподавания, которую все равно невозможно измерить. Разумеется, такой стиль академической жизни нередко противоречит внутренним убеждениям индивидуума, но навязывается давлением извне превратить храмы учености в хорошо разрекламированные источники доходов, и этот стиль граничит с проституцией.
Видите, чем приходится заниматься!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Итак, хороший дизайн должен быть в центре нашего преподавания. Но как нам учить образцовому дизайну с помощью инструментов и языков, которые делают нас посмешищем? К нашему сожалению, индустрия программирования сделала немного, чтобы помочь нам, преподавателям, преодолеть наши трудности.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Очевидно, перед нами в высшей степени устойчивый порочный круг: учителя не могут изменить свои курсы, т.к. они должны привлечь и доставить удовольствие студентам; студенты требуют то, что практикуется в промышленности; а индустрия применяет и воспроизводит то, чему обучены ее работники. Этот замкнутый круг напоминает ситуацию, описанную мной во введении к сообщению о Паскале в 1970 г.: вузы стремятся учить тому, что требует индустрия, а в индустрии практикуется то, чему ее работники выучились в вузах.
Порочный круг был однажды разорван, когда распространился Паскаль. При поддержке коллег-единомышленников и в упорном противостоянии рутинерам, Паскаль распространился в учебных заведениях и проник в индустрию. Это произошло несмотря на могучую конкуренцию со стороны индустрии и других больших организаций, в соперничестве с языками PL/1, Алгол 68 и Ада. Однако наследники Паскаля, существенно его превосходившие, Модула-2 и Оберон, не получили должного внимания среди преподавателей, и сами пали перед лицом самого недостойного из соперников — C. Самого недостойного, т.к. в этом языке были нарушены все открытые к тому времени принципы серьезного программирования. Он запутывает студентов, допуская разный смысл для x = y и y = x и принуждая всех писать x = = y вместо обычного x = y. Только за одни эти пороки он заслуживает изгнания из учреждений образования. Однако сей уродливый синтаксис был целиком воспроизведен в языке Java, принятие которого академическим сообществом произошло по меньшей мере отчасти благодаря этой преемственности.
Класссс!!!!!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Позвольте мне закончить выступление смелым предложением для этой просвещенной аудитории профессионалов преподавания. Я вижу в своем воображении образцовый учебник в качестве подходящего исходного пункта. Он должен удовлетворять следующим критериям:
Начинаться сжатым введением в основные понятия программного проектирования.
Использовать лаконичную формальную нотацию, строго определенную не более чем на примерно 20 страницах.
Основываясь на этой нотации, вводятся основные понятия итерации, рекурсии, логического утверждения <assertion> и инварианта.
Центральная тема — структурирование утверждений и типизация данных.
За этим следуют концепции упрятывания информации, модульности и проектирование интерфейсов, продемонстрированные образцовыми примерами.
Книга устанавливает терминологию, которая столь же интуитивна, сколь и точна.
Книга имеет умеренный размер.
Руководящим для моей карьеры в преподавании и исследованиях был тот принцип, что хорошо подготовленные профессионалы должны быть гораздо эффективнее, чем вдохновенные любители. В их производительности должно быть различие, и притом существенное. Думаю, что нашей общей целью должно быть увеличение этого различия.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
В чем-то он, несомненно, прав — нужно давай больше фундаментальных знаний... да и нагромождать в голову студенту новомодные веяния тоже нужно с умом... но.. всяк кулик свое болото хвалит — сколько желчи было вилито в статье на С, С++ иже с ними?
кроме того, излишнее погружение в формальную сторону программирования (нотации и т.п.) — это тоже излишество, т.к. эта штука способна напугать многих школьников, которым интересно писать программы, но не интересно читать заумные работы профессоров... первокурснику и старшекласснику проще показать пару работающих примеров, а уже потом обучать его формальной стороне вопроса — так он, по крайней мере, будет знать, зачем всё это нужно.
немного сумбурно я написал.... но я сам сталкиваюсь с проблемой обучения младших курсов программированию и мнение подкреляется некоторой практикой... хоть и относительно небольшой
LVV>Очевидно, перед нами в высшей степени устойчивый порочный круг: учителя не могут изменить свои курсы, т.к. они должны привлечь и доставить удовольствие студентам; студенты требуют то, что практикуется в промышленности; а индустрия применяет и воспроизводит то, чему обучены ее работники. Этот замкнутый круг напоминает ситуацию, описанную мной во введении к сообщению о Паскале в 1970 г.: вузы стремятся учить тому, что требует индустрия, а в индустрии практикуется то, чему ее работники выучились в вузах.
LVV>Порочный круг был однажды разорван, когда распространился Паскаль. При поддержке коллег-единомышленников и в упорном противостоянии рутинерам, Паскаль распространился в учебных заведениях и проник в индустрию. Это произошло несмотря на могучую конкуренцию со стороны индустрии и других больших организаций, в соперничестве с языками PL/1, Алгол 68 и Ада. Однако наследники Паскаля, существенно его превосходившие, Модула-2 и Оберон, не получили должного внимания среди преподавателей, и сами пали перед лицом самого недостойного из соперников — C. Самого недостойного, т.к. в этом языке были нарушены все открытые к тому времени принципы серьезного программирования. Он запутывает студентов, допуская разный смысл для x = y и y = x и принуждая всех писать x = = y вместо обычного x = y. Только за одни эти пороки он заслуживает изгнания из учреждений образования. Однако сей уродливый синтаксис был целиком воспроизведен в языке Java, принятие которого академическим сообществом произошло по меньшей мере отчасти благодаря этой преемственности.
Безопасность пилотов и пассажиров должна начинаться уже на уровне компиляторов.
Взрыв 4 июня 1996 г. ракеты Ариан-5, стоившей пол-миллиарда долларов, имел причиной программную ошибку, которую компилятор Оберона/Компонентного Паскаля просто не пропустил бы.
K_O>Взрыв 4 июня 1996 г. ракеты Ариан-5, стоившей пол-миллиарда долларов, имел причиной программную ошибку, которую компилятор Оберона/Компонентного Паскаля просто не пропустил бы.
Ну пропустил бы другую ошибку и ракета взорвалась бы на 2 сек позже.
Никогда ошибки не будут выявляться автоматически компиляторами или другими тулзами.
Просто сложность и объем кода настолько велик,
что даже одна ошибка на десяток миллионов строк кода может быть (и иногда становится)
роковой.
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, LaptevVV, Вы писали:
LVV>>http://www.inr.ac.ru/~info21/greetings/wirth_doklad_rus.htm
LVV>Руководящим для моей карьеры в преподавании и исследованиях был тот принцип, что хорошо подготовленные профессионалы должны быть гораздо эффективнее, чем вдохновенные любители. В их производительности должно быть различие, и притом существенное. Думаю, что нашей общей целью должно быть увеличение этого различия.
LVV>[/q]
И продолжая мысль — хорошо подготовленные вдохновенные любители сделают и тех, и других ))
Здравствуйте, BiТ, Вы писали:
LVV>>>http://www.inr.ac.ru/~info21/greetings/wirth_doklad_rus.htm
LVV>>Руководящим для моей карьеры в преподавании и исследованиях был тот принцип, что хорошо подготовленные профессионалы должны быть гораздо эффективнее, чем вдохновенные любители. В их производительности должно быть различие, и притом существенное. Думаю, что нашей общей целью должно быть увеличение этого различия.
LVV>>[/q]
BiТ>И продолжая мысль — хорошо подготовленные вдохновенные любители сделают и тех, и других ))
Нет! Разница здесь должна быть такой же, как , например, в музыке. Ни один любитель не может играть так, как играет профессионал. И у нас так же должно быть. А пока — то, что вы сказали. Это — ненормально!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, Kh_Oleg, Вы писали:
K_O>>
K_O>>Взрыв 4 июня 1996 г. ракеты Ариан-5, стоившей пол-миллиарда долларов, имел причиной программную ошибку, которую компилятор Оберона/Компонентного Паскаля просто не пропустил бы.
B>Ну пропустил бы другую ошибку и ракета взорвалась бы на 2 сек позже. B>Никогда ошибки не будут выявляться автоматически компиляторами или другими тулзами. Борис БАБАЯН. Защищенные информационные системы.
B>Просто сложность и объем кода настолько велик, B>что даже одна ошибка на десяток миллионов строк кода может быть (и иногда становится) B>роковой.
Речь идет о таких ошибках, которые компилятор МОЖЕТ обнаруживать. Ясно, что кривой дизайн никакой Оберон не исправит.
И здесь компилятор С++ заведомо проигрывает именно из-за невероятной сложности самого языка. И проще его сделать нельзя — стандрат однако!
Еще одна цитата оттуда же:
Отношение объемов описаний языков — 16 стр. для Оберона, 200 для Java и больше 1000 для C++.
Здравствуйте, LaptevVV, Вы писали:
BiТ>>И продолжая мысль — хорошо подготовленные вдохновенные любители сделают и тех, и других )) LVV>Нет! Разница здесь должна быть такой же, как , например, в музыке. Ни один любитель не может играть так, как играет профессионал. И у нас так же должно быть. А пока — то, что вы сказали. Это — ненормально!
Да, это ненормально.
Но если сравнить потребность в музыкантах-профессионалах и программистах,
тогда все станет на свои места.
Да, надо готовить профи, но их никогда не будет в нужном количестве.
Потому видимо перспективней развивать технологию.
Именно такую, когда и обезъяны смогут писать без ошибок.
В общем сверхзадача программирования — сделать так, чтобы программирование
как род деятельности с участием человека исчезла бы совсем и стала бы ненужной
Здравствуйте, Kh_Oleg, Вы писали:
K_O>Речь идет о таких ошибках, которые компилятор МОЖЕТ обнаруживать. Ясно, что кривой дизайн никакой Оберон не исправит.
Да, еще в 70-е годы все учебники про технологии программирования обошла знаменитая ошибка в программе на фортране, из-за которой тоже взорвалась ракета, стартовавшая с мыса Кеннеди. В Фортране можно было писать идентификаторы с пробелами (!!!!). Это приводило к таким супер-ляпам:
do i=1,100 // это оператор цикла
do i=1.100 // это - оператор присваивания
Оба — правильные операторы на фортране.
Элементарная опечатка оператора(человек, набивающий программу на перфокарту!). И компилятор это пропускает! K_O>И здесь компилятор С++ заведомо проигрывает именно из-за невероятной сложности самого языка. И проще его сделать нельзя — стандрат однако!
Да, я уже приводил аналогичный пример в С++
double d;
d = 3,141592653; // d равно 3, а не Пи
K_O>Еще одна цитата оттуда же: K_O>
K_O>Отношение объемов описаний языков — 16 стр. для Оберона, 200 для Java и больше 1000 для C++.
Вот это, конечно, впечатляет! Аналогично было с паскалем и алголом-68.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Kh_Oleg, Вы писали:
K_O>Речь идет о таких ошибках, которые компилятор МОЖЕТ обнаруживать.
Какие ошибки может обнаруживать компилятор?
Их не так уж и много.
Я лично не очень верю в надежность программ, написанных на языках
с очень строгой типизацией. Да, в простых случаях (студенческие программы)
это может помочь. Но в реальной жизни на преодаление ограничений, накладываемые компилятором,
могут быть потрачены такие усилия, что вся надежность будет перечеркнута
и даже будет еще хуже.
Почему придется преодалевать эти ограничения? Да просто жизнь такая
Можно почитать форумы тут на RSDN и проследить, как много усилий тратиться на разные
хаки и трюки, которые, кстати говоря, очень часто вызывают восхищение и
считаются "красивыми" решениями.
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, Kh_Oleg, Вы писали:
K_O>>Речь идет о таких ошибках, которые компилятор МОЖЕТ обнаруживать.
B>Какие ошибки может обнаруживать компилятор? B>Их не так уж и много.
Зато какие!!! Тебе уже привели примеры на фортране и C++.
B>Я лично не очень верю в надежность программ, написанных на языках B>с очень строгой типизацией.
Вера есть тогда, когда нет знания. (сорри, если задел)
B>Да, в простых случаях (студенческие программы) B>это может помочь. Но в реальной жизни на преодаление ограничений, накладываемые компилятором, B>могут быть потрачены такие усилия, что вся надежность будет перечеркнута B>и даже будет еще хуже.
В "реальной жизни" надо не торопиться сделать все "по-быстрому", а постараться понять, почему компилятор со строгой типизацией накладывает те или иные ограничения и переделать, (а случается, что и перепроектировать) программу так, чтобы не приходилось их преодолевать. Как правило, за каждым таким ограничением стоят многодневные обдумывания и обсуждения архитекторов языка. И в конечном счете программа, написанная без хаков, в долговременной перспективе оказывается более надежной.
B>Почему придется преодалевать эти ограничения? Да просто жизнь такая B>Можно почитать форумы тут на RSDN и проследить, как много усилий тратиться на разные B>хаки и трюки, которые, кстати говоря, очень часто вызывают восхищение и B>считаются "красивыми" решениями.
Вот тот фундаментальный подход, о котором говорит Вирт, и который не всем кажется подходящим при обучении программированию, как раз и учит тому, как программировать без трюков и прочих "хрюков" и, в конечном счете, создавать простые и надежные программы.
K_O>Безопасность пилотов и пассажиров должна начинаться уже на уровне компиляторов.
K_O>
K_O>Взрыв 4 июня 1996 г. ракеты Ариан-5, стоившей пол-миллиарда долларов, имел причиной программную ошибку, которую компилятор Оберона/Компонентного Паскаля просто не пропустил бы.
Подробнее о катастрофе Ариан-5 было написано в "Открытых системах" http://www.osp.ru/os/1998/06/21.htm#part_1.
IMHO "Контрактного Проектирования" помогает избежать подобных ошибок, но не есть панацея.
Надо внимательнее делать повторное использование кода и не забывать, что программировании одно очень известное слово пишется через два "п"
Здравствуйте, Kh_Oleg, Вы писали:
K_O>Здравствуйте, bkat, Вы писали:
B>>Здравствуйте, Kh_Oleg, Вы писали:
K_O>>>Речь идет о таких ошибках, которые компилятор МОЖЕТ обнаруживать.
B>>Какие ошибки может обнаруживать компилятор? B>>Их не так уж и много. K_O>Зато какие!!! Тебе уже привели примеры на фортране и C++.
Такие, и куда более замороченные, ошибки элементарно выявляются на code review.
А вот кто готов проводить такие ревью? А мало желающих, потому как скучно...
B>>Я лично не очень верю в надежность программ, написанных на языках B>>с очень строгой типизацией. K_O>Вера есть тогда, когда нет знания. (сорри, если задел)
Да нет, не задел...
Коллекционирование ошибок, их поиск и уничтожение — это мое хобби
на работе . Ошибок, на реальных проектах, я лично видел дофига.
Таких ошибок, которые смог бы найти компилятор, мне не попадались.
А если еще использовать что-то типа BoundsChecker, то вероятность
таких глупых ошибок практически нулевая.
Здравствуйте, AVM, Вы писали:
AVM>Подробнее о катастрофе Ариан-5 было написано в "Открытых системах" http://www.osp.ru/os/1998/06/21.htm#part_1.
КЛАСС!!! Это просто шедевр!
Однако, Ariane 5, в отличие от предыдущей модели, имел уже принципиально другую дисциплину выполнения предполетных действий – настолько другую, что работа рокового программного модуля после времени старта вообще не имела смысла. Однако, модуль повторно использовался без каких-либо модификаций – видимо из-за нежелания изменять программный код, который успешно работает.
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, BiТ, Вы писали:
LVV>>>>http://www.inr.ac.ru/~info21/greetings/wirth_doklad_rus.htm
LVV>>>Руководящим для моей карьеры в преподавании и исследованиях был тот принцип, что хорошо подготовленные профессионалы должны быть гораздо эффективнее, чем вдохновенные любители. В их производительности должно быть различие, и притом существенное. Думаю, что нашей общей целью должно быть увеличение этого различия.
LVV>>>[/q]
BiТ>>И продолжая мысль — хорошо подготовленные вдохновенные любители сделают и тех, и других )) LVV>Нет! Разница здесь должна быть такой же, как , например, в музыке. Ни один любитель не может играть так, как играет профессионал. И у нас так же должно быть. А пока — то, что вы сказали. Это — ненормально!
Послушай передачу Троицкий и Ф.М. Достоевский. Артемий предоставлял зрителям альбомы человека, который всю жизнь живет в Финляндии, в лесу, то что он делает надо слышать, или альбом индуса, датированный 1976 годом, электроная музыка "продиджи+Моби" в одном флаконе, саунд более чем современный. Они не профессионалы, в том смысле, как ты это понимаешь, но результат на лицо. Я хотел сказать, что это слишком категоричное заявление, вот если бы ты привел в пример бокс — любительский против профессионального, это наверное более близко выразило твою мысль.
Наконец, как ни парадоксально это звучит, даже если бы компьютерные системы действительно были надежнее "традиционных", то это вовсе не обязательно означает, что они обеспечивают большую безопасность. Дело в том, что надежность ПО традиционно определяется степенью его соответствия зафиксированным в спецификациях требованиям; однако, часто бывает так, что ПО делает именно то, что ему и было предписано, и авария Ariane 5 – классический тому пример: и злополучное вычисление посторонней для полета величины горизонтального отклонения Инерциальной Платформы, и реакция на него вплоть до выведения из строя всех навигационных систем и бортовых компьютеров – все это случилось в полном соответствии с Требованиями, которые были частично унаследованы от Ariane 4 и не отражали новых реальностей. Более того, по сравнению с ошибками в коде именно спецификационные ошибки обычно ведут к более тяжелым последствиям – компетенции разработчиков ПО недостаточно для обнаружения таких ошибок. Программный комплекс – сложная система, однако реальный мир, отражаемый в спецификационных требованиях – еще более сложен и требует специальных экспертных знаний. Так что надежность ПО и его безопасность – понятия, хотя и перекрывающиеся, но не идентичные.
Что как раз иллюстрирует, что проблемы куда глубже,
чем ошибки, не выловленные компилятором.
))
(сорри, если задел)
