ИМХО тут серьезная проблема. В Инете и, в частности, на Хабре много жалоб на понижение качества образования. При этом снижается осознание роли образования — некоторые школьники считают, что сразу после окончания школы смогут писать код за хорошие деньги. И при этом мои знакомые в вузах жалуются, что возрастает давление на преподавателей: стоит не поставить одному студенту зачет — целая делегация отправляется в деканат.
ИМХО если у студента программирование профильный предмет, то он должен соблюдать общие правила, но если речь о гуманитарии или о школьнике, то должен понимать, что такой код — неуважение к читателю, прежде всего к преподавателю. Думаю преподавателю нужно экономить собственное рабочее время, а то на всех студентов не хватит. Лучше пусть меньше получат фактических знаний, чем не привыкнут к нормальному оформлению. Но это ИМХО — у меня небольшой опыт преподавания, правда в солидных местах — МГТУ, МГУ.
Интересно: а если студент пишет комментарий «zapisat dannie v jurnal» и соответственно дает имена типа zapisvjurnal, такое зачтется? — Ведь не переключать регистр «клавы» и не вспоминать английские слова быстрее, если есть проблема с языком.
И хотел бы добавить, современная математика огромна. Не торопитесь судить о ней в терминах «никакая математика не определит»…
Cовершенно серьезно: это сложный вопрос философии и методологии науки. Ok: математика огромна — это факт. Но этот факт не противоречит факту, о котором сказал выше, что
природа этих наук разная: CS экспериментальная наука, а математика нет.
см.:Newell, Allen; Simon, H. A. (1976), «Computer Science as Empirical Inquiry: Symbols and Search» (1975 ACM Turing Award Lecture), Communications of the ACM, 19
Можно сделать мат. модель файла, но мы столкнемся с ограничениями моделирования, о которых в статье.
Oberon не имеет классов, объектов и наследования. Это ООП?
Сужу по Вики (я только читал про Oberon, но ничего на нем не писал):
Заголовок спойлера
Инкапсуляция поддерживается исключительно на уровне модуля — все типы, объявленные внутри модуля, друг для друга абсолютно прозрачны. Из других модулей доступно то, что объявлено при определении как экспортируемое.
Полиморфизм обеспечивается за счёт механизма методов (и процедурные поля в Обероне, и методы в Обероне-2 ведут себя как виртуальные, в терминологии большинства гибридных объектно-ориентированных языков), а также расширенной конструкцией WITH, позволяющей выполнять различные группы операторов в зависимости от того, к какому из расширенных типов относится её аргумент.
В языке отсутствует специальный механизм конструкторов. Рекомендуемым методом создания и инициализации объектов является описание порождающих модулей и процедур (в традиционной терминологии ООП — factory).
Программа в такой технологии представляет собой набор относительно самостоятельных компонентов (в данном случае — модулей), имеющих скрытую от внешнего мира внутреннюю структуру и чётко определённый интерфейс. Модули могут загружаться и выгружаться динамически, во время работы программы, система предоставляет развитые средства контроля типов во время выполнения, которые позволяют писать универсальные алгоритмы обработки данных, не зависящие от конкретных типов этих данных (например, библиотека для работы с СУБД может предоставлять методы, записывающие результат запроса из базы в запись произвольной структуры, если набор и типы полей этой записи соответствуют набору и типам полей в БД).
[...] Объектно-ориентированное программирование
Средства объектного программирования интерпретируются в Обероне как естественное развитие средств работы с записями в модульной системе, точнее, как технический инструментарий для решения конкретной архитектурной задачи: обеспечить эффективное «разделение труда» между различными модулями при работе с динамическими типами и структурами данных: например, работа с указателями в списке может быть скрыта (вместе с соответствующими полями) в одном модуле, а определение и работа с конкретным «наполнением» элементов списка — задаваться в другом (или, чаще, других). В этом смысле технология объектного программирования в Обероне подчинена концепции модульности: она здесь является, скорее, средством описания данных, чем средством построения архитектуры приложения в целом.
Вот тут возникает типичная проблема: стиль школьника часто позволяет быстрее сдать выполненную работу. Причем сильно быстрее. Результат будет хреновым, но это заметят далеко не сразу, иногда через годы.
Чаще препод замечает сразу — и не только плохой стиль, вернее его отсутствие, но и баги. И не принимает такую «работу» ;)
ИМХО байки о супергениальных школьниках — во многом еще один миф. Про поиски технологий согласен.
Точного названия для такой штуки в математике скорее всего нет
И в том обсуждении, которое вспомнил, все сошлись на том, что «точного названия в математике нет», поэтому в CS есть нематематическая специфика. Без мат. методов CS не обойтись, но решить все задачи CS только мат. подходом не получится.
Любая сущность, которую вводят в языках программирования, обладает определенными математическими свойствами.
Сможете назвать мат. аналог понятию «файл»? Когда-то участвовал в обсуждении этого вопроса на кафедре высшей математики одного из знаменитых московских вузов — в том обсуждении никто не смог назвать точного мат. аналога. Т.о. ИМХО не все базовые понятия CS являются мат. понятиями. Хотя математика и CS имеют значительные пересечения, но, даже, природа этих наук разная: CS экспериментальная наука, а математика нет.
правы все: [...] и противники, когда негодуют на возведение ООП в статус серебряной пули, абсолютного оружия.
Это широко известный миф:
Фредерик Брукс указывает, что наиболее сложной частью создания программного обеспечения является «…спецификация, дизайн и тестирование концептуальных конструкций, а отнюдь не работа по выражению этих концептуальных конструкций…». ООП (наряду с такими технологиями как искусственный интеллект, верификация программ, автоматическое программирование, графическое программирование, экспертные системы и др.), по его мнению, не является «серебряной пулей», которая могла бы на порядок величины снизить сложность разработки программных систем. Согласно Бруксу, «…ООП позволяет сократить только привнесённую сложность в выражение дизайна. Дизайн остаётся сложным по своей природе…»[22].
Еще: Экзистенциальный Вопрос „Что Есть Объект?“»
+ проблемы модельного подхода…
см.:Newell, Allen; Simon, H. A. (1976), «Computer Science as Empirical Inquiry: Symbols and Search» (1975 ACM Turing Award Lecture), Communications of the ACM, 19
Можно сделать мат. модель файла, но мы столкнемся с ограничениями моделирования, о которых в статье.
ИМХО байки о супергениальных школьниках — во многом еще один миф. Про поиски технологий согласен.
Это широко известный миф:
Еще: Экзистенциальный Вопрос „Что Есть Объект?“»
+ проблемы модельного подхода…