Вероятно, хотя для начала не стоило бы писать такой код, верно? Опять же, я не готов на эту тему глубоко рассуждать, т.к. в данном случае задача не тянет на великую математику. Я бы попросту расписал таблицу истинности (cond1, cond2 -> result) и подумал, как можно записать то же условие проще. Конечно, формально это математика, но на практике это очень простая задача, которая объясняется без особенных затруднений.
Не думаю, по крайней мере, не в наше время.
Макросы стоит рассматривать как инструмент абстракции. Ускорить код можно с помощью CPU-specific инструкций. А макросы могут, наоборот, раздуть код, что приведёт к выходу за пределы процессорного кэша и затормозит работу. Если же вас беспокоят накладные расходы на вызов функций или начало/конец цикл, то любой современный оптимизирующий компилятор умеет разворачивать эти инструкции без проблем.
А разве с задачей привить ненависть к математике школа не справляется?
На мой взгляд, постановка вопроса должна быть иной. Вот есть люди, которые по профессии математики. Они утром встают и занимаются весь день математикой. Многие так увлекаются, что забывают пообедать и задерживаются допоздна. Так вот, что их заставляет так себя вести? Видимо, они в этой работе видят какой-то драйв, получают удовольствие.
Ну так надо детям показать, в чём удовольствие от математики, почему люди выбирают её в качестве профессии. Я бы мог согласиться, что надо потерпеть и заниматься порою занудными вещами и т.п., но ведь по факту этот метод всё равно не работает: люди заканчивают школу и забывают всё это напрочь, если работают не по математической специальности. Каждый может легко проверить это утверждение на своих знакомых.
В дельфи есть функции Low, High. Т.е. пройти все элементы вектора A будет:
Ну вот смотрите, получается, что Делфи даёт больше возможностей, чем Паскаль, но вы ведь только что писали, что больше возможностей — это «хуже», потому что больше способов ошибиться!
Но чисто теоретически ассемблер дает еще больше возможностей, нпр., чтобы убыстрить код.
Не совсем. Ассемблер даёт больше низкоуровневого контроля над выполнением, а мы тут обсуждаем абстракции построенные на других абстракциях. В Python возможностей больше, чем в Паскале, потому что Python идёт по абстракции вверх, а не вниз.
чем больше возможностей языка — тем больше возможностей плохо написать.
Это заблуждение, недостойное тиражирования. С точки зрения языка с массой возможностей попросту любой код на языке с меньшим количеством возможностей — «плохой», потому что его синтаксис хуже определяет семантику.
Например, есть алгоритм, в котором требуется выполнить некоторое действие для каждого элемента массива. В Паскале/Бейсике и пр. это однозначно будет описываться неточной конструкцией типа «for i = 1 TO N», то есть «пройти элементы от 1 до N», а не «все элементы», и на голову программиста ложится задача отслеживания, что массив действительно состоит только из этих объектов.
Это плохой код. Да, в этих языках иначе не напишешь, но он всё равно плох, и оттого, что язык не даёт альтернатив, хорошим он не становится.
А это не оттуда. Алгоритмы обхода лабиринтов описывались много где, хоть в «Занимательных задачах» Перельмана, да и до этого, конечно. Ну то есть, конечно, это задача теории графов, но нельзя сказать, что теория графов её приватизировала.
волновой алгоритм и прочие которые успешно используются для поиска пути — все из теории графов
Не надо подходить к вопросу формально. Помните, у Мольера господин Журден очень удивился, когда узнал, что разговаривает прозой? Вот и здесь: волновой алгоритм прекрасно объясняется и без того, чтобы ошарашивать учеников тем, что это, оказывается, теория графов.
Ну мне Оберон и Компонентный Паскаль скажем так нравятся больше чем мейнстримовые Жабы и C# или JS с Пухтоном.
Согласитесь, это ваши личные предпочтения. Имеете полное право. Но всё-таки не отказывайте в здравомыслии людям, которые выросли на Паскале и прочих языках той эпохи, а затем создали свои языки, в которых попытались избавиться от недостатков языков времён своей юности. И в этом смысле для меня Python, при всех его проблемах, огромный шаг вперёд по сравнению с Паскалем. Ограничения и решения Паскаля из нынешнего времени видятся обычной архаикой, а не целенаправленными архитектурными замыслами. Человек, изучающий программирование на Паскале приобретает превратное представление о дизайне языка программирования. Ну это как если бы он обучался архитектуре зданий только на римско-греческих примерах.
Нет конечно, я вообще в умножение плохо умею еще со школы :-)
Именно! Вы не забиваете себе голову алгоритмами умножения и не пишете соответствующий код, а просто берёте калькулятор. Аналогично, в наше время решение системы линейных уравнений осуществляется таким же точно «калькулятором», а не собственной программой.
так что в вопросов «где нужна теорема Штейнера и как это выглядит?» не было
Да, всё так. Почувствуйте разницу: вас целенаправленно обучали на физфаке профессии (физика, вероятно). И все предметы были подчинены этой общей задаче, в том числе и программирование. В школе такой цели нет. Программирование изучают не для физики, не для математики и не для биологии. Программирование изучают для программирования, поэтому я так и ратую за то, чтобы задачи были как можно менее специальными. Чем ближе к быту, тем лучше. В конце концов, в задачниках по математике тоже обычно решают что-то «из жизни»: узнать цену, расстояние, скорость, количество, а не что-нибудь такое из медицины или технарства.
Он еще кстати жив и можно поинтересоваться у него, что он думает о Пухтоне
Это неважно. Просто если так любить идеи Вирта, давайте и вправду переходить на Оберон.
Уравнения и системы уравнений приходится решать в любой технической области, и решать ручками даже систему из двух уравнений — крайне унылое занятие,
Верно. Вот умножить вручную два пятизначных числа тоже унылое занятие. Вы это тоже обычно с помощью ручки и бумаги делаете?
А вот давать студентам сразу какой-нибудь BFGS или GMRES,
Не в этом дело. Я же не против методов Ньютона или Гаусса. Я просто говорю, что всё это задачи из области математики и смежных областей. Можно найти огромное число полезнейших для начинающего программиста задач, которые бы не были бы связаны настолько жёстко с математикой. Мне хотелось бы, чтобы цвели все цветы.
Я не про классификацию графа, а о задачах на графах в общем: помоги роботу выбраться из лабиринта — поиск пути, самая такая настоящая задача на графах.
Да, это хорошая задача, поддерживаю. Но тут теория графов уж очень сбоку, даже в какой-то из книг занимательной серии Перельмана всякие методы выхода из лабиринтов описывались.
не всякий школьник воспринимает фото котика как матрицу. М.б. лучше пусть поскучает, но поймет, что такое матрица,
Да бросьте: вы собираетесь рассказывать о балансировке дерева школьнику, который не сможет понять, что такое bitmap? Не могу согласиться, что нарисовать рисунок по клеточкам из нулей и единиц — это rocket science.
Зачем простому смертному, а тем более, школьнику на математике упрощать тригонометрические выражения?
Тут вот какая штука. Тригонометрия — это сам по себе предмет. Мы можем обсуждать, нужен он в принципе или не нужен. Если считать, что нужен, то придётся и эту его часть изучать. Информатика же дисциплина более общая, и если стоит цель научиться программировать, то можно это делать на самых разных примерах, не упрощая задачи. Задача балансировки дерева ничуть не сложнее массы других, только смысл её совершенно непонятен нормальному человеку. Соответственно, я просто предлагаю обучаться программированию на понятных повседневных задачах, а не сначала тратить кучу времени на обучение некоторой теме, которая нужна лишь для того, чтобы потом на ней тренировать свои алгоритмические навыки.
тому, что в большинстве случаев это будет очень развесистый код, сделанный м.б. не самым хорошим учителем.
Попробуйте на досуге, уверяю, это 20 строк максимум.
в математике доказываются теоремы, в информатике работают алгоритмы. Только ради этого, школьникам приходится трудится несколько лет
Абсолютно согласен. Информатика — это не про Пифагора, не про идеальный газ, и не про решение уравнений. Это именно что про алгоритмы. Но чтобы проиллюстрировать эту мысль, нужны задачи. Так почему бы не брать те задачи, которые любой ребёнок поймёт с пол-пинка? Ведь простота формулировки и доступность задачи на понятийном уровне не означает простоты алгоритма. Она означает лишь то, что мы не будем тратить время на изучение левых тем с единственной целью сформулировать и решить задачу в рамках этой темы.
В этом смысле классические книги вроде того же Вирта гораздо больше к своему времени, чем вы к нашему. Смотрите, просто считать из текстового файла вещественное число и преобразовать его в настоящее число или, скажем, посчитать косинус — это вполне себе сложные задачи (косинус так вообще требует разложения в ряд). Однако Вирт и его современники обычно не грузят читателя этими вещами, справедливо считая, что всё это уже реализовано в стандартных библиотеках любого языка. Так почему же мы не поступаем так же, как они? Если некая функциональность уже доступна везде «из коробки», значит, это и есть наш атомарный кирпичик, из которого мы строим программу. Да, неплохо бы разобраться в устройстве кирпича, но в этом отношении подсчёт косинуса или устройство «кучи» памяти ничуть не менее важны, чем внутренняя организация ассоциативного массива, и тем не менее, первые темы мы игнорируем, а вторые всячески продвигаем.
Зачем простому смертному, а тем более, школьнику классифицировать графы?
Высота дерева.
Ну это, конечно, жутко сложное понятие. Балансировка дерева, кстати, тоже на любителя задача.
Кластерный анализ теперь в 5 классе проходят?
Передёргиваете. Я предложил просто изучить KNN и C-Means, это задача на один день, и ничего тут изучать вообще не надо, достаточно знать, что такое евклидово расстояние.
Прежде всего я предлагаю не загружать детей понятием «уязвимость»… Далее это проблема и Васика, разве нет?
Абсолютно не надо загружать детей понятием «уязвимость». Вы просто покажете им, как выделить массив на 100 символов, а потом считать строку. А они просто потом будут это везде повторять. Спасибо за это от нас всех.
У Бейсика (а я про Питон, вообще-то...) такой уязвимости нет: «INPUT S$» считывает строку динамической длины.
Ага. Будем на уроках информатики изучать чистую физику.
Снова передёргиваете. Я предлагаю смоделировать, например, идеальный газ — это то, что дети изучают, не знаю, в девятом классе или в восьмом? Известную концепцию, простую как мячики на бильярдном столе, да ещё и не сталкивающиеся. А вы говорите, что это шаг в сторону, предлагая для начала изучить несколько абсолютно новых концепций из теории графов, а затем решать с её помощью задачи, которые решительно никогда никому на практике не понадобятся.
При этом почему-то начала кластерного анализа, которые требуют абсолютно базовых математических знаний — это «плохо», а балансировка деревьев, несравнимо более трудная и абстрактная задача — «хорошо».
Да и опять же, вы выбираете удобные цели для спора. Вот приводил же простой пример. Есть куча задач с преобразованием матриц. Транспонирование, поворот, интерполяция и т.п. Всё это можно сделать в виде скучнейших задач на ввод десятков чисел и вывод десятков других чисел, которые ещё надо осмыслить. А можно сказать, что матрица — это просто фотография, и вам надо эту фотографию повернуть/отобразить/увеличить/превратить в чёрно-белую. Это на порядок интереснее (котики же), при этом математическая строгость не страдает совершенно никак. Проблема только в том, что в некоторых языках почему-то считать с диска jpeg в массив и вывести обратно массив на диск трудно, а в других языках это делается в одну строку.
Паскаль в этом плане на голову выше всех этих Пухтонов и прочих мусорных JS
Вот даже лично Вирт бы с вами не согласился, ибо уже во втором издании своей книги (это примерно 1990-й год, если не ошибаюсь) убрал Паскаль в пользу Modula-2. Это чистая вкусовщина, спорить бессмысленно.
Хз, по мне так это самое главное. Я когда в школе узнал, что есть такой метод Гаусса и компьютер можно начить решать системы уравнений — был счастлив
Я рад за вас, не могу подтвердить личным опытом.
Знайте как круто решать домашку, когда компьютер уже посчитал все и выдал ответ.
А, ну это всё объясняет. Смысл и радость компьютера — это помогать решать другие домашки. Домашки ради домашек.
Тем более все эти Ньютоны и наискорейшие спуски — то собственно для чего компы создавались и то что приносит реальную пользу. Задачи оптимизации — это именно то, что позволяет нам летать,
С этим никто не спорит. И тем не менее, это не значит, что данные задачи являются наилучшими с дидактической точки зрения.
А почему не берем? Как раз очень важный момент для оценки алгоритма.
Не берём потому, что для классических алгоритмов это уже сделано (ну т.е. рассказать немного можно, конечно), а для собственных, как правило, уже потребуется математика за пределами школьного курса.
Алгоритмы на графах, начиная с балансировки деревьев, разве не требуют некоторых знаний из теории графов?
Каких, например?
А как быть с приближенными вычислениями? А Булева алгебра это не математика?
Это именно что математические задачи. Вы по сути говорите: «разве в математических задачах не применяется математика?» Ещё бы, применяется, но и задач вне области математики просто вагон и маленькая тележка, не будем о них забывать.
Что касается computational biology, насколько знаю, там очень активно применяют кластерный анализ.
Безусловно. Давайте обсудим, например, KNN и C-means. Математика здесь на уровне, не знаю, пятого класса? Я же не говорю, что всё на свете надо выбросить, математика никуда не денется, но для ученика десятого класса понимание KNN не потребует особенных интеллектуальных усилий, пусть это и проходит по ведомству математики.
Я говорю, что ничего лучше для школы и для научных публикаций алгоритмов не изобрели. И не нужно
Разумеется, изобрели: Python, да и не только. Вы лукавите, когда говорите, что в научных публикациях используется Паскаль. Там обычно используют некий псевдокод, который у нас традиционно называют «паскалеобразным», но в действительности его с тем же успехом можно назвать «бейсикообразным» или «питонообразным».
Не знал, что буфер постоянного размера в несколько десятков байтов выглядит столь безнравственно!
Вот это и печально, что не знали. Вы предлагаете учить детей либо обрезать имена по «техническим ограничениям» (которых нет), либо оставлять buffer overflow-уязвимости, хотя это исключительно и только проблема языков типа Паскаль и C.
почему Вы уверены, что все школьники хотят делать игрушки или даже играть в них?
А разве я что-то говорил об игрушках?
Взять тот же несчастный шарик. Во-первых, это модель физического явления (молекула идеального газа, напр.) Во-вторых, нужно понимать, каким образом изменяются координаты со временем. В-третьих, понимать как устроена анимация (это вообще все без исключения системы современные). В-четвёртых, реагировать на столкновения со стенками и понимать как устроен этот процесс — это чистая физика, угол падения равен углу отражения, критерий столкновения и т.п. Тут масса тонкостей за простейшей обложкой.
Идея идти в сторону Unity и DirectX не лишена логики, но в целом это тупиковая ветвь дискуссии, т.к. вот есть некий непрерывный ряд языков и технологий от машинного кода и ассемблера до Unity и далее, и вы просто берёте в этом ряду произвольную точку и говорите: вот я хочу брать этот уровень абстракции, а влево-вправо не хочу, потому что гладиолус.
Можно сколько угодно дискутировать о том, насколько низкоуровневым должно быть школьное программирование, но считать, что в языке должны быть строки, но не должно быть ассоциативных массивов, например, по-моему, крайне странно, не вижу логики.
Вроде первое сентября уже давно прошло, а разговоры не утихают.
Очень не согласен с общим взглядом автора на происходящее и на возможные решения проблемы.
Для начала, вроде бы все согласны, что цель информатики в школе — это заинтересовать ученика предметом и дать хоть какие-то самые базовые понятия о профессии программиста и об информатике как науке.
Но если это так, то дальнейшие средства выглядят решительно странно. Во-первых, откуда здесь вообще математика и математическая подготовка? Да, математика нужна в решении задач вычислительной геометрии или решения уравнений, но точно так же биология нужна для решения задач computational biology. Мне при всём желании сложно вспомнить универсальные алгоритмы из классического списка, для понимания которых требуется хоть какая-то математика (не берём вопрос анализа сложности, это отдельная тема).
Во-вторых, вы предлагаете Паскаль с его абсолютно архаическим подходом к языковым и аппаратным средствам (об этом чуть ниже). Паскаль сам по себе не виноват, но вы по сути говорите, что за прошедшие 30 лет ничего лучше не изобрели. Изобрели тот же Python, конечно, а лямбды вас никто в школе писать не заставляет. Вы ставите языку в вину то, что у него имеется больше средств, чем вам требуется, удивительное дело.
Решение задач Прима-Краскала или поиск корней уравнения на уроке информатики — это ещё одна математика под другим соусом. Такая деятельность, во-первых, скучна абсолютному большинству, а во-вторых, очень слабо отражает реальные задачи повседневного программирования. Если уж рассказывать о программировании, то брать хотя бы занятные задачи, в которых, тем не менее, есть алгоритмы.
Например, почему бы не предложить нарисовать на экране шарик, который летает по прямой и отражается от стенок? Это была задача на 10 строк в QuickBasic. Или показать круговое движение: Земля вращается вокруг Солнца. Задание со звёздочкой: Луна ещё и вращается вокруг Земли. Или вот: мы не просто программируем алгоритм Дейкстры, а рисуем на карте как проходит маршрут.
Проблема в том, что на старых языках все эти трюки не работают, т.к. авторы этих языков жили совсем в другой реальности. Нарисовать что-то — проблема, осуществить анимацию — проблема, проиграть звук — проблема. Я вот не понимаю, как я буду объяснять ученику, что в 2017 году открыть jpeg картинку и перевернуть её вверх ногами алгоритмически это «сложно» (а чем плохая задача — преобразование матрицы, только не в её занудном математическом изложении). Когда у вас есть простые средства доступа к звуку, графике, интернету, открываются совершенно новые возможности, выходящие за рамки суконных традиционных задач (опять же, не будем критиковать авторов, они исходили из того, что возможно было спрашивать).
Далее, даже чисто алгоритмически эти языки заставляют работать на неоправданно низком уровне без каких-либо причин. Вот нельзя просто ввести с клавиатуры имя. Почему? Ну потому, что вы не знаете длины требуемого текстового буфера, динамических строк нет, а выделять буфер постоянного размера — спасибо, давайте ещё научим детей пить и курить. Можно сопоставить значение целочисленному индексу (массив), а вот строке или вещественному числу уже нельзя. Почему? Ну вот потому, что 30 лет назад Вирт так решил.
Короче говоря, я за то, чтобы дети могли легко использовать весь спектр современных возможностей аппаратуры (да посмотрите хотя бы на Scratch), не спотыкались на ровном месте из-за отсутствия в языке той или иной структуры данных и не просидели весь курс в занудных задачах двадцатилетней давности.
Я сам родом из той эпохи, но давайте здраво смотреть на вещи. Я сам в своё время взял труд почитать задачники по программированию 1970-х, когда авторы были вынуждены ограничивать себя ещё сильнее (например, нельзя было рассчитывать, что в языке есть строки). Так вот, это была катастрофическая тоска — решим уравнение методом Ньютона, а теперь давайте попробуем деление пополам, а теперь бонус: метод Гаусса системы решения линейных уравнений! Давайте всё-таки идти в ногу со временем.
Макросы стоит рассматривать как инструмент абстракции. Ускорить код можно с помощью CPU-specific инструкций. А макросы могут, наоборот, раздуть код, что приведёт к выходу за пределы процессорного кэша и затормозит работу. Если же вас беспокоят накладные расходы на вызов функций или начало/конец цикл, то любой современный оптимизирующий компилятор умеет разворачивать эти инструкции без проблем.
Впрочем, тема «скучности» и «занимательности» крайне субъективная, тут у всех свои предпочтения.
Это понятно, но контекст у вас другой:
На мой взгляд, постановка вопроса должна быть иной. Вот есть люди, которые по профессии математики. Они утром встают и занимаются весь день математикой. Многие так увлекаются, что забывают пообедать и задерживаются допоздна. Так вот, что их заставляет так себя вести? Видимо, они в этой работе видят какой-то драйв, получают удовольствие.
Ну так надо детям показать, в чём удовольствие от математики, почему люди выбирают её в качестве профессии. Я бы мог согласиться, что надо потерпеть и заниматься порою занудными вещами и т.п., но ведь по факту этот метод всё равно не работает: люди заканчивают школу и забывают всё это напрочь, если работают не по математической специальности. Каждый может легко проверить это утверждение на своих знакомых.
Ну вот смотрите, получается, что Делфи даёт больше возможностей, чем Паскаль, но вы ведь только что писали, что больше возможностей — это «хуже», потому что больше способов ошибиться!
Не совсем. Ассемблер даёт больше низкоуровневого контроля над выполнением, а мы тут обсуждаем абстракции построенные на других абстракциях. В Python возможностей больше, чем в Паскале, потому что Python идёт по абстракции вверх, а не вниз.
Это заблуждение, недостойное тиражирования. С точки зрения языка с массой возможностей попросту любой код на языке с меньшим количеством возможностей — «плохой», потому что его синтаксис хуже определяет семантику.
Например, есть алгоритм, в котором требуется выполнить некоторое действие для каждого элемента массива. В Паскале/Бейсике и пр. это однозначно будет описываться неточной конструкцией типа «for i = 1 TO N», то есть «пройти элементы от 1 до N», а не «все элементы», и на голову программиста ложится задача отслеживания, что массив действительно состоит только из этих объектов.
Это плохой код. Да, в этих языках иначе не напишешь, но он всё равно плох, и оттого, что язык не даёт альтернатив, хорошим он не становится.
Вам привести список скучнейших книг по матану или физике?
Даже для самых интересных тем, конечно, нужен интересный материал.
Не надо подходить к вопросу формально. Помните, у Мольера господин Журден очень удивился, когда узнал, что разговаривает прозой? Вот и здесь: волновой алгоритм прекрасно объясняется и без того, чтобы ошарашивать учеников тем, что это, оказывается, теория графов.
Согласитесь, это ваши личные предпочтения. Имеете полное право. Но всё-таки не отказывайте в здравомыслии людям, которые выросли на Паскале и прочих языках той эпохи, а затем создали свои языки, в которых попытались избавиться от недостатков языков времён своей юности. И в этом смысле для меня Python, при всех его проблемах, огромный шаг вперёд по сравнению с Паскалем. Ограничения и решения Паскаля из нынешнего времени видятся обычной архаикой, а не целенаправленными архитектурными замыслами. Человек, изучающий программирование на Паскале приобретает превратное представление о дизайне языка программирования. Ну это как если бы он обучался архитектуре зданий только на римско-греческих примерах.
Именно! Вы не забиваете себе голову алгоритмами умножения и не пишете соответствующий код, а просто берёте калькулятор. Аналогично, в наше время решение системы линейных уравнений осуществляется таким же точно «калькулятором», а не собственной программой.
Да, всё так. Почувствуйте разницу: вас целенаправленно обучали на физфаке профессии (физика, вероятно). И все предметы были подчинены этой общей задаче, в том числе и программирование. В школе такой цели нет. Программирование изучают не для физики, не для математики и не для биологии. Программирование изучают для программирования, поэтому я так и ратую за то, чтобы задачи были как можно менее специальными. Чем ближе к быту, тем лучше. В конце концов, в задачниках по математике тоже обычно решают что-то «из жизни»: узнать цену, расстояние, скорость, количество, а не что-нибудь такое из медицины или технарства.
Это неважно. Просто если так любить идеи Вирта, давайте и вправду переходить на Оберон.
Верно. Вот умножить вручную два пятизначных числа тоже унылое занятие. Вы это тоже обычно с помощью ручки и бумаги делаете?
Не в этом дело. Я же не против методов Ньютона или Гаусса. Я просто говорю, что всё это задачи из области математики и смежных областей. Можно найти огромное число полезнейших для начинающего программиста задач, которые бы не были бы связаны настолько жёстко с математикой. Мне хотелось бы, чтобы цвели все цветы.
Да, это хорошая задача, поддерживаю. Но тут теория графов уж очень сбоку, даже в какой-то из книг занимательной серии Перельмана всякие методы выхода из лабиринтов описывались.
Да бросьте: вы собираетесь рассказывать о балансировке дерева школьнику, который не сможет понять, что такое bitmap? Не могу согласиться, что нарисовать рисунок по клеточкам из нулей и единиц — это rocket science.
Тут вот какая штука. Тригонометрия — это сам по себе предмет. Мы можем обсуждать, нужен он в принципе или не нужен. Если считать, что нужен, то придётся и эту его часть изучать. Информатика же дисциплина более общая, и если стоит цель научиться программировать, то можно это делать на самых разных примерах, не упрощая задачи. Задача балансировки дерева ничуть не сложнее массы других, только смысл её совершенно непонятен нормальному человеку. Соответственно, я просто предлагаю обучаться программированию на понятных повседневных задачах, а не сначала тратить кучу времени на обучение некоторой теме, которая нужна лишь для того, чтобы потом на ней тренировать свои алгоритмические навыки.
Попробуйте на досуге, уверяю, это 20 строк максимум.
Абсолютно согласен. Информатика — это не про Пифагора, не про идеальный газ, и не про решение уравнений. Это именно что про алгоритмы. Но чтобы проиллюстрировать эту мысль, нужны задачи. Так почему бы не брать те задачи, которые любой ребёнок поймёт с пол-пинка? Ведь простота формулировки и доступность задачи на понятийном уровне не означает простоты алгоритма. Она означает лишь то, что мы не будем тратить время на изучение левых тем с единственной целью сформулировать и решить задачу в рамках этой темы.
В этом смысле классические книги вроде того же Вирта гораздо больше к своему времени, чем вы к нашему. Смотрите, просто считать из текстового файла вещественное число и преобразовать его в настоящее число или, скажем, посчитать косинус — это вполне себе сложные задачи (косинус так вообще требует разложения в ряд). Однако Вирт и его современники обычно не грузят читателя этими вещами, справедливо считая, что всё это уже реализовано в стандартных библиотеках любого языка. Так почему же мы не поступаем так же, как они? Если некая функциональность уже доступна везде «из коробки», значит, это и есть наш атомарный кирпичик, из которого мы строим программу. Да, неплохо бы разобраться в устройстве кирпича, но в этом отношении подсчёт косинуса или устройство «кучи» памяти ничуть не менее важны, чем внутренняя организация ассоциативного массива, и тем не менее, первые темы мы игнорируем, а вторые всячески продвигаем.
Зачем простому смертному, а тем более, школьнику классифицировать графы?
Ну это, конечно, жутко сложное понятие. Балансировка дерева, кстати, тоже на любителя задача.
Передёргиваете. Я предложил просто изучить KNN и C-Means, это задача на один день, и ничего тут изучать вообще не надо, достаточно знать, что такое евклидово расстояние.
Абсолютно не надо загружать детей понятием «уязвимость». Вы просто покажете им, как выделить массив на 100 символов, а потом считать строку. А они просто потом будут это везде повторять. Спасибо за это от нас всех.
У Бейсика (а я про Питон, вообще-то...) такой уязвимости нет: «INPUT S$» считывает строку динамической длины.
Снова передёргиваете. Я предлагаю смоделировать, например, идеальный газ — это то, что дети изучают, не знаю, в девятом классе или в восьмом? Известную концепцию, простую как мячики на бильярдном столе, да ещё и не сталкивающиеся. А вы говорите, что это шаг в сторону, предлагая для начала изучить несколько абсолютно новых концепций из теории графов, а затем решать с её помощью задачи, которые решительно никогда никому на практике не понадобятся.
При этом почему-то начала кластерного анализа, которые требуют абсолютно базовых математических знаний — это «плохо», а балансировка деревьев, несравнимо более трудная и абстрактная задача — «хорошо».
Да и опять же, вы выбираете удобные цели для спора. Вот приводил же простой пример. Есть куча задач с преобразованием матриц. Транспонирование, поворот, интерполяция и т.п. Всё это можно сделать в виде скучнейших задач на ввод десятков чисел и вывод десятков других чисел, которые ещё надо осмыслить. А можно сказать, что матрица — это просто фотография, и вам надо эту фотографию повернуть/отобразить/увеличить/превратить в чёрно-белую. Это на порядок интереснее (котики же), при этом математическая строгость не страдает совершенно никак. Проблема только в том, что в некоторых языках почему-то считать с диска jpeg в массив и вывести обратно массив на диск трудно, а в других языках это делается в одну строку.
Вот даже лично Вирт бы с вами не согласился, ибо уже во втором издании своей книги (это примерно 1990-й год, если не ошибаюсь) убрал Паскаль в пользу Modula-2. Это чистая вкусовщина, спорить бессмысленно.
Я рад за вас, не могу подтвердить личным опытом.
А, ну это всё объясняет. Смысл и радость компьютера — это помогать решать другие домашки. Домашки ради домашек.
С этим никто не спорит. И тем не менее, это не значит, что данные задачи являются наилучшими с дидактической точки зрения.
Не берём потому, что для классических алгоритмов это уже сделано (ну т.е. рассказать немного можно, конечно), а для собственных, как правило, уже потребуется математика за пределами школьного курса.
Каких, например?
Это именно что математические задачи. Вы по сути говорите: «разве в математических задачах не применяется математика?» Ещё бы, применяется, но и задач вне области математики просто вагон и маленькая тележка, не будем о них забывать.
Безусловно. Давайте обсудим, например, KNN и C-means. Математика здесь на уровне, не знаю, пятого класса? Я же не говорю, что всё на свете надо выбросить, математика никуда не денется, но для ученика десятого класса понимание KNN не потребует особенных интеллектуальных усилий, пусть это и проходит по ведомству математики.
Разумеется, изобрели: Python, да и не только. Вы лукавите, когда говорите, что в научных публикациях используется Паскаль. Там обычно используют некий псевдокод, который у нас традиционно называют «паскалеобразным», но в действительности его с тем же успехом можно назвать «бейсикообразным» или «питонообразным».
Вот это и печально, что не знали. Вы предлагаете учить детей либо обрезать имена по «техническим ограничениям» (которых нет), либо оставлять buffer overflow-уязвимости, хотя это исключительно и только проблема языков типа Паскаль и C.
А разве я что-то говорил об игрушках?
Взять тот же несчастный шарик. Во-первых, это модель физического явления (молекула идеального газа, напр.) Во-вторых, нужно понимать, каким образом изменяются координаты со временем. В-третьих, понимать как устроена анимация (это вообще все без исключения системы современные). В-четвёртых, реагировать на столкновения со стенками и понимать как устроен этот процесс — это чистая физика, угол падения равен углу отражения, критерий столкновения и т.п. Тут масса тонкостей за простейшей обложкой.
Идея идти в сторону Unity и DirectX не лишена логики, но в целом это тупиковая ветвь дискуссии, т.к. вот есть некий непрерывный ряд языков и технологий от машинного кода и ассемблера до Unity и далее, и вы просто берёте в этом ряду произвольную точку и говорите: вот я хочу брать этот уровень абстракции, а влево-вправо не хочу, потому что гладиолус.
Можно сколько угодно дискутировать о том, насколько низкоуровневым должно быть школьное программирование, но считать, что в языке должны быть строки, но не должно быть ассоциативных массивов, например, по-моему, крайне странно, не вижу логики.
Очень не согласен с общим взглядом автора на происходящее и на возможные решения проблемы.
Для начала, вроде бы все согласны, что цель информатики в школе — это заинтересовать ученика предметом и дать хоть какие-то самые базовые понятия о профессии программиста и об информатике как науке.
Но если это так, то дальнейшие средства выглядят решительно странно. Во-первых, откуда здесь вообще математика и математическая подготовка? Да, математика нужна в решении задач вычислительной геометрии или решения уравнений, но точно так же биология нужна для решения задач computational biology. Мне при всём желании сложно вспомнить универсальные алгоритмы из классического списка, для понимания которых требуется хоть какая-то математика (не берём вопрос анализа сложности, это отдельная тема).
Во-вторых, вы предлагаете Паскаль с его абсолютно архаическим подходом к языковым и аппаратным средствам (об этом чуть ниже). Паскаль сам по себе не виноват, но вы по сути говорите, что за прошедшие 30 лет ничего лучше не изобрели. Изобрели тот же Python, конечно, а лямбды вас никто в школе писать не заставляет. Вы ставите языку в вину то, что у него имеется больше средств, чем вам требуется, удивительное дело.
Решение задач Прима-Краскала или поиск корней уравнения на уроке информатики — это ещё одна математика под другим соусом. Такая деятельность, во-первых, скучна абсолютному большинству, а во-вторых, очень слабо отражает реальные задачи повседневного программирования. Если уж рассказывать о программировании, то брать хотя бы занятные задачи, в которых, тем не менее, есть алгоритмы.
Например, почему бы не предложить нарисовать на экране шарик, который летает по прямой и отражается от стенок? Это была задача на 10 строк в QuickBasic. Или показать круговое движение: Земля вращается вокруг Солнца. Задание со звёздочкой: Луна ещё и вращается вокруг Земли. Или вот: мы не просто программируем алгоритм Дейкстры, а рисуем на карте как проходит маршрут.
Проблема в том, что на старых языках все эти трюки не работают, т.к. авторы этих языков жили совсем в другой реальности. Нарисовать что-то — проблема, осуществить анимацию — проблема, проиграть звук — проблема. Я вот не понимаю, как я буду объяснять ученику, что в 2017 году открыть jpeg картинку и перевернуть её вверх ногами алгоритмически это «сложно» (а чем плохая задача — преобразование матрицы, только не в её занудном математическом изложении). Когда у вас есть простые средства доступа к звуку, графике, интернету, открываются совершенно новые возможности, выходящие за рамки суконных традиционных задач (опять же, не будем критиковать авторов, они исходили из того, что возможно было спрашивать).
Далее, даже чисто алгоритмически эти языки заставляют работать на неоправданно низком уровне без каких-либо причин. Вот нельзя просто ввести с клавиатуры имя. Почему? Ну потому, что вы не знаете длины требуемого текстового буфера, динамических строк нет, а выделять буфер постоянного размера — спасибо, давайте ещё научим детей пить и курить. Можно сопоставить значение целочисленному индексу (массив), а вот строке или вещественному числу уже нельзя. Почему? Ну вот потому, что 30 лет назад Вирт так решил.
Короче говоря, я за то, чтобы дети могли легко использовать весь спектр современных возможностей аппаратуры (да посмотрите хотя бы на Scratch), не спотыкались на ровном месте из-за отсутствия в языке той или иной структуры данных и не просидели весь курс в занудных задачах двадцатилетней давности.
Я сам родом из той эпохи, но давайте здраво смотреть на вещи. Я сам в своё время взял труд почитать задачники по программированию 1970-х, когда авторы были вынуждены ограничивать себя ещё сильнее (например, нельзя было рассчитывать, что в языке есть строки). Так вот, это была катастрофическая тоска — решим уравнение методом Ньютона, а теперь давайте попробуем деление пополам, а теперь бонус: метод Гаусса системы решения линейных уравнений! Давайте всё-таки идти в ногу со временем.
Много приусов, подтверждаю. В провинции, наверное, побольше, в крупных городах малолитражки.