О бесполезных черепашках
Это неизбежно: при попытке выдумать язык программирования как бы «для обучения» в жанре «рисуем текстовыми командами для курсора» всегда будет получаться концептуально один и тот же язык. Наиболее известная реализация которого называется «Brainfuck». Этот, правда, в реальности не про рисование, но зато тоже чтобы задолбаться.
И знаете почему получается так?
Потому что «учителя информатики» и «авторы учебников по программированию для детей», которые предполагают таким способом чего-то объяснить, никогда не писали полезных программ, и в результате не представляют, что и зачем делают реальные программисты.
Это не обучение программированию, это - обучение жизни в полной страданий, лишений и преодолений вымышленной параллельной вселенной.
Злой параллельной вселенной - поскольку что в этих языках, что в построенной на их основе программе по якобы обучению компьютерным технологиям и программированию основные силы тратятся на наяривание на то, чего в реальности все пытаются избежать.
Реально, я ещё в детстве заметил, что язык управления сраной черепашкой - Лого, равно как и спёртый у Синклера программируемый марсоход и всё им подобное, по непонятной мне тогда причине гораздо сложнее в освоении и использовании, чем вроде бы универсальный Бейсик, на котором можно написать что-то полезное. Бейсик некоторые тоже полагали языком для обучения, но это явно было какое-то другое обучение.
Ну ладно, мне было десять лет, компы тогда не стояли у каждого дома, в каждом кармане не лежал смартфон, а продвинутым языком высокого уровня считался C++.
Однако с тех пор те, кто реально занимался программированием, и интересовался развитием софта, а не написанием сотен страниц мутной воды по поводу того, как важно развитие софта для народного хозяйства, уже вроде бы поняли всю глубину бесполезности и порочности самих этих идей, которые «учителя информатики» до сих пор полагают «хорошим способом обучения программированию».
Когда вы на основании ни разу не проверявшейся гипотезы полагаете, будто «детям понятнее, когда картинки, а потому давайте построим язык вокруг рисования оных программируемым курсором», то без разницы, назовёте ли вы команды движения этого курсора русскими или английскими словами. Или вообще обозначите их символами стрелок. Это всё равно будет Брейнфак, потому что Брейнфак тут прямо в самом подходе.
Картинки сто пудов гораздо понятнее - что детям, что взрослым. Однако рисование картинок тучей низкоуровневых по сути текстовых команд не понятно ни тем, ни этим. Иллюстрации и чертежи офигенно хорошо рисуются мышкой, стилусом и даже пальцем. За три секунды можно понять, как правильно потянуть за что-то там, чтобы вот этот фрагмент повернулся, растянулся или передвинулся, - даже без инструкции.
Однако запись всего этого командами типа «передвинуться влево, оставляя след» годится, быть может, для сохранения накликанного мышкой в файл «векторной графики», но никак не для сочинения сего в уме или попыток это прочитать и представить себе результат.
В реальности никто так не делает. Художник это или программист, оба два в этом случае откроют Фотошоп или Иллюстратор и нарисуют там. Да, программист может быть в этом плане покруче, поэтому он сумеет для автоматизации действий ещё и написать скрипт, однако это не будет скрипт рисования «программируемым курсором» при помощи команд «влево», «вверх» и т.п. Как максимум, там будет какая-то формула, чтобы по точкам построить график или что-то подвинуть по известной траектории, но не координаты точек в явном виде.
Забудьте про координаты - даже в случае с простейшими фигурами человек не способен по числам понять, что это за фигура. Люди даже заданный координатами прямоугольник вычисляют чаще всего «чисто логикой» - по попарно совпадающим координатам, а не прочерчивая мысленно путь программируемого курсора.
Учиться программированию таким образом одновременно очень сложно, поскольку это адски неинтуитивно, и совершенно бесполезно, поскольку вы никогда не будете делать такого.
Сейчас ведь даже интерфейсы программируют, не задавая координаты в тексте программы - вместо этого используются гораздо более понятные человеку концепции, типа «привязок» объектов интерфейса друг к другу. Ну там, «правый край кнопки привязан к правому краю окна». Да, между краями этих двух объектов есть расстояние, но и оно тоже записано в файле стилей, а не в коде программы, причём в виде «отступы окна - такие-то», а не в виде «передвинь курсор на десять точек влево, не оставляя следа, а потом двигай ещё на сто точек влево, теперь уже оставляя».
Даже в инженерном софте, где можно было бы ожидать чего-то такого, всё равно каждый раз оказывается, что и инженерам тоже проще всего не вычислять какие-то там углы поворота или координаты точек, а управлять процессами в стиле «а теперь растяни фигуру от вот этой грани до вон той».
Ну да, какие-то опорные размеры, разумеется, всегда есть. Быть может, тогда вот тут оно пригодится?
Нет.
Поскольку и «вот тут» оно, во-первых, в основном кликается мышкой, во-вторых, кликается мышкой простейшим для человека способом - от очевидной видимой глазами точки отсчёта до другой очевидной и видимой глазами, а вовсе не в той логике, в которой предполагается описать весь маршрут перемещения «графического курсора» по точкам.
Если у вас, например, деталь в форме равнобедренного треугольника, то как бы там этот процесс ни виделся «учителям информатики», в реальности он скорее всего будет примерно таким:
Возможны, конечно, вариации - например, можно не строить вспомогательную высоту, а вместо этого задать констрейнт двум бёдрам «они оба равны a2», но не суть.
Суть в том, что читать любое такое описание дольше, чем всё это накликать мышкой, то есть даже будь язык программирования таким, он всё равно не имел бы смысла, поскольку проигрывал бы визуальному программированию.
И самое главное, всё это радикально отличается от попыток прогнать сраную черепашку по трудновычислимому маршруту.
Делать мной описанное я научу дошкольника за три минуты. А с черепашкой придётся плясать наверно неделю в лучшем случае. И это - с равнобедренным треугольником, а не с чем-то сложным.
Одновременно с тем, изложенное мной очень хорошо параметризуется: этот алгоритм уже подходит для абсолютно любого равнобедренного треугольника. Это - как функция с аргументами «длина основания» и «высота». И меняя вышеозначенные a1 и a2 в таблице или прямо на чертеже, я буду менять параметры треугольника как мне вздумается.
А вот с черепашкой человек реал заколебётся это программировать даже в этом простейшем случае.
Поскольку с ней каждый раз - как с нуля. Все координаты считаешь сам.
А это радикально противоречит самой идее программирования. Ведь его суть в том, чтобы как можно меньше делать вручную. Чтобы после первого же раза уже было не с нуля. Чтобы после него появлялась кнопка «повторить с нужными мне вариациями».
Фактически, все такие «языки для детей» предлагают сделать очень неудобным для человека способом что-то, чего делать никто никогда не будет, и одновременно с этим концептуально иллюстрируют прямо противоположное сути программирования. Это прямо как сборник «Никогда не делайте так» с поправкой на то, что именно это и предлагают довольно много раз проделать.
При наличии десятков миллионов программистов в мире уже нельзя считать случайностью, что этим маршрутом ни программирование, ни софт не пошли. Оно осталось как один из вариантов протокола записи векторной графики, однако только в смысле «это пишет компьютер и читает компьютер - человеку такое не надо».
Почему таким путём не пошли? Потому что на сотнях тысяч экспериментов в реальных программах неизменно выходило, что получиться таким образом может только и исключительно Брейнфак, какие заклинания о «самодисциплине» и «развитии интеллекта» ни произнеси. А Брейнфак, в свою очередь, нужен только особым ценителям нетрадиционных развлечений.
Ну и ещё авторам «учебников по программированию для детей», видимо.
Кто-то, быть может, подумает, что «ну, вот разработчики языков и инженерного софта же этим занимаются - так что, оно всё-таки где-то полезно».
Однако ирония в том, что даже те, кто программирует интерпретатор языка типа Лого, не занимаются этой фигнёй. Их собственная программа - про то, как парсить этот язык и алгоритмически превращать его в пиксели на экране. Там, разумеется, есть вычисление и координат тоже, однако всё это вычисляется формулами, а не прописано цифрами в коде. Быть может, они используют все эти «передвинуть» и «повернуться» для реализации пары функций - ну там, прямоугольника, скажем, - и на этом их собственные упражнения с этим «обучающим языком» закончатся. Дальше пусть брейнфачат учащиеся. Ну или учителя их брейнфачат.
Разработка интерпретатора такого языка, внезапно, на три порядка ближе к реальному программированию, нежели его использование.
Инженерный софт, разумеется, устроен точно так же - с поправкой на то, что там всё в основном завязано на векторную алгебру, а школьная «классическая» геометрия, ой, не пригодилась. И если даже там клиентский скриптовый язык в чём-то схож с вышеописанным Брейнфаком, его в этой части не предполагается использовать вручную. Вместо этого надо правильно накликать мышкой в режиме «записи скрипта», а потом там что-то слегка подправить, чтобы получалось как тебе надо. И вокруг этого написать уже нормальную программистскую часть - на Питоне или типа того, а не на Брейнфаке.
Каким же целям служила и служит эта «альтернативная вселенная» в курсах типа «программирование для детей», кроме как для «изобразить деятельность и отчитаться», понять решительно невозможно.
doc-файл
И знаете почему получается так?
Потому что «учителя информатики» и «авторы учебников по программированию для детей», которые предполагают таким способом чего-то объяснить, никогда не писали полезных программ, и в результате не представляют, что и зачем делают реальные программисты.
Это не обучение программированию, это - обучение жизни в полной страданий, лишений и преодолений вымышленной параллельной вселенной.
Злой параллельной вселенной - поскольку что в этих языках, что в построенной на их основе программе по якобы обучению компьютерным технологиям и программированию основные силы тратятся на наяривание на то, чего в реальности все пытаются избежать.
Реально, я ещё в детстве заметил, что язык управления сраной черепашкой - Лого, равно как и спёртый у Синклера программируемый марсоход и всё им подобное, по непонятной мне тогда причине гораздо сложнее в освоении и использовании, чем вроде бы универсальный Бейсик, на котором можно написать что-то полезное. Бейсик некоторые тоже полагали языком для обучения, но это явно было какое-то другое обучение.
Ну ладно, мне было десять лет, компы тогда не стояли у каждого дома, в каждом кармане не лежал смартфон, а продвинутым языком высокого уровня считался C++.
Однако с тех пор те, кто реально занимался программированием, и интересовался развитием софта, а не написанием сотен страниц мутной воды по поводу того, как важно развитие софта для народного хозяйства, уже вроде бы поняли всю глубину бесполезности и порочности самих этих идей, которые «учителя информатики» до сих пор полагают «хорошим способом обучения программированию».
Когда вы на основании ни разу не проверявшейся гипотезы полагаете, будто «детям понятнее, когда картинки, а потому давайте построим язык вокруг рисования оных программируемым курсором», то без разницы, назовёте ли вы команды движения этого курсора русскими или английскими словами. Или вообще обозначите их символами стрелок. Это всё равно будет Брейнфак, потому что Брейнфак тут прямо в самом подходе.
Картинки сто пудов гораздо понятнее - что детям, что взрослым. Однако рисование картинок тучей низкоуровневых по сути текстовых команд не понятно ни тем, ни этим. Иллюстрации и чертежи офигенно хорошо рисуются мышкой, стилусом и даже пальцем. За три секунды можно понять, как правильно потянуть за что-то там, чтобы вот этот фрагмент повернулся, растянулся или передвинулся, - даже без инструкции.
Однако запись всего этого командами типа «передвинуться влево, оставляя след» годится, быть может, для сохранения накликанного мышкой в файл «векторной графики», но никак не для сочинения сего в уме или попыток это прочитать и представить себе результат.
В реальности никто так не делает. Художник это или программист, оба два в этом случае откроют Фотошоп или Иллюстратор и нарисуют там. Да, программист может быть в этом плане покруче, поэтому он сумеет для автоматизации действий ещё и написать скрипт, однако это не будет скрипт рисования «программируемым курсором» при помощи команд «влево», «вверх» и т.п. Как максимум, там будет какая-то формула, чтобы по точкам построить график или что-то подвинуть по известной траектории, но не координаты точек в явном виде.
Забудьте про координаты - даже в случае с простейшими фигурами человек не способен по числам понять, что это за фигура. Люди даже заданный координатами прямоугольник вычисляют чаще всего «чисто логикой» - по попарно совпадающим координатам, а не прочерчивая мысленно путь программируемого курсора.
Учиться программированию таким образом одновременно очень сложно, поскольку это адски неинтуитивно, и совершенно бесполезно, поскольку вы никогда не будете делать такого.
Сейчас ведь даже интерфейсы программируют, не задавая координаты в тексте программы - вместо этого используются гораздо более понятные человеку концепции, типа «привязок» объектов интерфейса друг к другу. Ну там, «правый край кнопки привязан к правому краю окна». Да, между краями этих двух объектов есть расстояние, но и оно тоже записано в файле стилей, а не в коде программы, причём в виде «отступы окна - такие-то», а не в виде «передвинь курсор на десять точек влево, не оставляя следа, а потом двигай ещё на сто точек влево, теперь уже оставляя».
Даже в инженерном софте, где можно было бы ожидать чего-то такого, всё равно каждый раз оказывается, что и инженерам тоже проще всего не вычислять какие-то там углы поворота или координаты точек, а управлять процессами в стиле «а теперь растяни фигуру от вот этой грани до вон той».
Ну да, какие-то опорные размеры, разумеется, всегда есть. Быть может, тогда вот тут оно пригодится?
Нет.
Поскольку и «вот тут» оно, во-первых, в основном кликается мышкой, во-вторых, кликается мышкой простейшим для человека способом - от очевидной видимой глазами точки отсчёта до другой очевидной и видимой глазами, а вовсе не в той логике, в которой предполагается описать весь маршрут перемещения «графического курсора» по точкам.
Если у вас, например, деталь в форме равнобедренного треугольника, то как бы там этот процесс ни виделся «учителям информатики», в реальности он скорее всего будет примерно таким:
- Первый клик в начало координат.
- Второй клик в рандомное место справа - примерно на горизонтали.
- Получившемуся ребру задаётся констрейнт «горизонталь», если он не проставился сам.
- Длина ребра - переменная а1 (её численное значение задаётся в таблице опорных размеров)
- Добавляется точка с привязкой к центру ребра.
- Клик по ней, а потом в рандомное место примерно на вертикали.
- Констрейнт «веритикаль» для нового вспомогательного ребра, если он не проставился сам.
- Длина оного - переменная a2.
- Соединяются крайние точки первого ребра с верхней точкой второго.
Возможны, конечно, вариации - например, можно не строить вспомогательную высоту, а вместо этого задать констрейнт двум бёдрам «они оба равны a2», но не суть.
Суть в том, что читать любое такое описание дольше, чем всё это накликать мышкой, то есть даже будь язык программирования таким, он всё равно не имел бы смысла, поскольку проигрывал бы визуальному программированию.
И самое главное, всё это радикально отличается от попыток прогнать сраную черепашку по трудновычислимому маршруту.
Делать мной описанное я научу дошкольника за три минуты. А с черепашкой придётся плясать наверно неделю в лучшем случае. И это - с равнобедренным треугольником, а не с чем-то сложным.
Одновременно с тем, изложенное мной очень хорошо параметризуется: этот алгоритм уже подходит для абсолютно любого равнобедренного треугольника. Это - как функция с аргументами «длина основания» и «высота». И меняя вышеозначенные a1 и a2 в таблице или прямо на чертеже, я буду менять параметры треугольника как мне вздумается.
А вот с черепашкой человек реал заколебётся это программировать даже в этом простейшем случае.
Поскольку с ней каждый раз - как с нуля. Все координаты считаешь сам.
А это радикально противоречит самой идее программирования. Ведь его суть в том, чтобы как можно меньше делать вручную. Чтобы после первого же раза уже было не с нуля. Чтобы после него появлялась кнопка «повторить с нужными мне вариациями».
Фактически, все такие «языки для детей» предлагают сделать очень неудобным для человека способом что-то, чего делать никто никогда не будет, и одновременно с этим концептуально иллюстрируют прямо противоположное сути программирования. Это прямо как сборник «Никогда не делайте так» с поправкой на то, что именно это и предлагают довольно много раз проделать.
При наличии десятков миллионов программистов в мире уже нельзя считать случайностью, что этим маршрутом ни программирование, ни софт не пошли. Оно осталось как один из вариантов протокола записи векторной графики, однако только в смысле «это пишет компьютер и читает компьютер - человеку такое не надо».
Почему таким путём не пошли? Потому что на сотнях тысяч экспериментов в реальных программах неизменно выходило, что получиться таким образом может только и исключительно Брейнфак, какие заклинания о «самодисциплине» и «развитии интеллекта» ни произнеси. А Брейнфак, в свою очередь, нужен только особым ценителям нетрадиционных развлечений.
Ну и ещё авторам «учебников по программированию для детей», видимо.
Кто-то, быть может, подумает, что «ну, вот разработчики языков и инженерного софта же этим занимаются - так что, оно всё-таки где-то полезно».
Однако ирония в том, что даже те, кто программирует интерпретатор языка типа Лого, не занимаются этой фигнёй. Их собственная программа - про то, как парсить этот язык и алгоритмически превращать его в пиксели на экране. Там, разумеется, есть вычисление и координат тоже, однако всё это вычисляется формулами, а не прописано цифрами в коде. Быть может, они используют все эти «передвинуть» и «повернуться» для реализации пары функций - ну там, прямоугольника, скажем, - и на этом их собственные упражнения с этим «обучающим языком» закончатся. Дальше пусть брейнфачат учащиеся. Ну или учителя их брейнфачат.
Разработка интерпретатора такого языка, внезапно, на три порядка ближе к реальному программированию, нежели его использование.
Инженерный софт, разумеется, устроен точно так же - с поправкой на то, что там всё в основном завязано на векторную алгебру, а школьная «классическая» геометрия, ой, не пригодилась. И если даже там клиентский скриптовый язык в чём-то схож с вышеописанным Брейнфаком, его в этой части не предполагается использовать вручную. Вместо этого надо правильно накликать мышкой в режиме «записи скрипта», а потом там что-то слегка подправить, чтобы получалось как тебе надо. И вокруг этого написать уже нормальную программистскую часть - на Питоне или типа того, а не на Брейнфаке.
Каким же целям служила и служит эта «альтернативная вселенная» в курсах типа «программирование для детей», кроме как для «изобразить деятельность и отчитаться», понять решительно невозможно.
doc-файл