Comments 26
Простота и легкость это конечно хорошо, но так ли полезно?
Ребёнок не учит команды, а запоминает расположение «нужных блоков» в меню, это как копировать чужой код кусками и немного подправлять.
Я думаю, что очень многие начинали изучать программирование на несколько более сложном уровне и у них всё получалось, сложности лишь усиливали азарт и подталкивали к изучению нового материала.
Работаю в учреждении дополнительного образования детей педагогом и заметил такую тенденцию, что те поколения воспитанников, которые начинали с Quick Basic'а, Pascal'я и других языков, действительно что-то начинали понимать в том, что они пишут и как это работает, они учились писать правильно (с точки зрения синтаксиса языка), учились быть внимательными. А те кто сейчас ваяют на Скретче и пишут программы для Лего-роботов очень далеки от программирования, имхо.
Мб, я конечно просто зануда и мне обидно, что мы, в своё время, тратили кучу времени на пропущенное двоеточие, а у современных детей всё так просто.
Если что — извините, но когда постоянно видишь, как это называют «программированием» — передёргивает. Накипело.
Ребёнок не учит команды, а запоминает расположение «нужных блоков» в меню, это как копировать чужой код кусками и немного подправлять.
Я думаю, что очень многие начинали изучать программирование на несколько более сложном уровне и у них всё получалось, сложности лишь усиливали азарт и подталкивали к изучению нового материала.
Работаю в учреждении дополнительного образования детей педагогом и заметил такую тенденцию, что те поколения воспитанников, которые начинали с Quick Basic'а, Pascal'я и других языков, действительно что-то начинали понимать в том, что они пишут и как это работает, они учились писать правильно (с точки зрения синтаксиса языка), учились быть внимательными. А те кто сейчас ваяют на Скретче и пишут программы для Лего-роботов очень далеки от программирования, имхо.
Мб, я конечно просто зануда и мне обидно, что мы, в своё время, тратили кучу времени на пропущенное двоеточие, а у современных детей всё так просто.
Если что — извините, но когда постоянно видишь, как это называют «программированием» — передёргивает. Накипело.
Стечк и не должен обучать написанию кода, код это набор правил и синтаксиса.
Скетч должен помогать детям научиться составлять алгоритмы по которым будет работать программа.
Неважно какой язык выбирают для обучения, без алгоритма код это просто набор букв и цифр.
Скетч должен помогать детям научиться составлять алгоритмы по которым будет работать программа.
Неважно какой язык выбирают для обучения, без алгоритма код это просто набор букв и цифр.
А можно поподробнее — чему и как учите. Мы сейчас тоже хотим заинтересовать детей программированием — думаем с чего начать.
В данный момент я не обучаю программированию.
Но когда я занимался в соответствующем кружке, для нас всё начиналось с Данеток (задачи на развитие логического мышления) плюс был небольшой соревновательный момент: отгадал данетку — получи плюсик и у кого в конце месяца/года плюсиков больше.
По алгоритмам помню «Конкурс сладких алгоритмов» когда вомпитанники клуба готовили что-то вкусное и описывали процесс, потом все собирались на чаепитие и представляли свой «проект».
Непосредственно программирование изучали всегда задачами (сейчас вспомню только пример из HTML, но это применимо к чему угодно): объясняется теоретический материал, даётся пример простейшего исполнения (допустим таблица), потом ставится задача нарисовать таблицу особой формы, выполнил — ещё сложнее задание, сделал его — следующая ступенька. Т.е. постоянная постановка задач, требующих решения, ну и какой-то азарт был в группе, на тему, кто быстрее сделает. Тут мне кажется самое главное, чтобы в группе были 1-2 человека, которые действительно хотят изучать программирование: они будут первыми кричать, что всё сделали и звать педагога проверить, тем самым подначивая остальных.
Как учили — последовательно: сначала Quick Basic, потом HTML (+CSS, основы Фотошопа, Флеша, как работает Интернет и тд), Pascal, потом уже курсы на выбор: C/C++, Мультимедиа, Мобильные платформы, Олимпиадное программирование. Каждый курс — 1 год, 2 занятия в неделю по 1.5 часа.
Как-то сбито, тяжело вспоминать как это было много лет назад. Но, если что, отвечу на Ваши вопросы в ПМ.
Но когда я занимался в соответствующем кружке, для нас всё начиналось с Данеток (задачи на развитие логического мышления) плюс был небольшой соревновательный момент: отгадал данетку — получи плюсик и у кого в конце месяца/года плюсиков больше.
По алгоритмам помню «Конкурс сладких алгоритмов» когда вомпитанники клуба готовили что-то вкусное и описывали процесс, потом все собирались на чаепитие и представляли свой «проект».
Непосредственно программирование изучали всегда задачами (сейчас вспомню только пример из HTML, но это применимо к чему угодно): объясняется теоретический материал, даётся пример простейшего исполнения (допустим таблица), потом ставится задача нарисовать таблицу особой формы, выполнил — ещё сложнее задание, сделал его — следующая ступенька. Т.е. постоянная постановка задач, требующих решения, ну и какой-то азарт был в группе, на тему, кто быстрее сделает. Тут мне кажется самое главное, чтобы в группе были 1-2 человека, которые действительно хотят изучать программирование: они будут первыми кричать, что всё сделали и звать педагога проверить, тем самым подначивая остальных.
Как учили — последовательно: сначала Quick Basic, потом HTML (+CSS, основы Фотошопа, Флеша, как работает Интернет и тд), Pascal, потом уже курсы на выбор: C/C++, Мультимедиа, Мобильные платформы, Олимпиадное программирование. Каждый курс — 1 год, 2 занятия в неделю по 1.5 часа.
Как-то сбито, тяжело вспоминать как это было много лет назад. Но, если что, отвечу на Ваши вопросы в ПМ.
Какой смысл обучать сначала Basic-у, а потом Pascal-ю?
Видимо, чтобы не зацикливаться на одном синтаксисе.
Нас учили на Basic быдлокодить всякие рисовалки, а на Pascal — уже структурировать код. Но это было до того, как на школьных олимпиадах разрешили Python и другие языки.
Нас учили на Basic быдлокодить всякие рисовалки, а на Pascal — уже структурировать код. Но это было до того, как на школьных олимпиадах разрешили Python и другие языки.
И самое главное, как я считаю, уйти от модели школы, репетитора и подобных. Самый лучший варинт — Клуб, со своими традициями, законами, обычаями, праздниками, выездами и тд и тп. Если Вы создадите для детей комфортную атмосферу, они будут легче усваивать знания и будут с нетерпением ждать каждого следующего занятия.
Посмотрите фильм «Проект Волна» там есть очень хороший пример того, как увлечь детей (правда он несколько негативный, так как была иная цель, но ничто не мешает сделать по своему)
Посмотрите фильм «Проект Волна» там есть очень хороший пример того, как увлечь детей (правда он несколько негативный, так как была иная цель, но ничто не мешает сделать по своему)
Я сейчас конечно выскажу очень непопулярную точку зрения, но вам не кажется что «программирование» это не соблюдение синтаксиса %language-name%, а интерфейс(!) для того чтобы компьютер выполнял реальные задачи. На вопрос какой интерфейс удобнее для взаимодействия с компьютером, визуальный или текстовый, история за вас уже ответила. Текстовой интерфейс это интерфейс «нативный» для компьютера, а не для человека, и будущее как раз за визуальными языками/средами программирования, которые позволят переместить фокус внимая программиста с синтаксиса языка на более важные задачи, такие как глобальная логика работы программы, создание архитектуры «глазами» и разработка алгоритмов. Визуальщина не упрощает программирование, она упрощает интерфейс. «Написать» говнокод вам и в визуальной среде никто не запрещает.
p.s. «мне обидно, что мы, в своё время...» Дата рождения: 15 января 1993, LAWL.
p.s. «мне обидно, что мы, в своё время...» Дата рождения: 15 января 1993, LAWL.
Полностью согласен.
Кроме того скажу честно, что даже в среде графических редакторов существует целое направление нодовых редакторов, в которых весь процессинг изображения сводится к построению узлов операций над изображениями. Хотя чисто технически, тот же композинг можно написать и на скриптовых языках, а исторически так оно и делалось. И у кого нибудь поднимется рука назвать например тот же Nuke «детским» или «непрофессиональным»?
Да, согласен что немного утрирую и «ручное» программирование все же отличается от композинга, однако визуальные алгоритмы используются и для анимации, и для симуляции толпы, что в свою очередь тоже достаточно серьезные инструменты, которые раньше прописывались ручками на скриптовых языках. Однако же, не зря тот же Slate пришел в 3ds max (хотя чисто технически, уж материалы-то с шейдерами тоже в свое время кодились текстом) — любая задача может быть упрощена за счет некоторой канонизации и предоставления адекватного интерфейса.
Я ничего не хочу сказать против программистов, но на самом деле в программировании эти подходы и не применяются, потому что люди в какой-то мере не хотят детскости в решении своих сложных задач. Как у тех же админов — только консоль, только хардкор. Однако же подавляющее большинство задач можно более комфортно решать и с помощью GUI. Что есть гпафический интерфейс? Это же по сути надстройка над теми же самыми командами.
Я например, очень бы хотел сам чтобы например для Ruby было такое графическое решение как скретч, возможно какой-то нодификатор. Чтобы не писать ручками одни и те же конструкции, а взять блок, например, цикла, и блок переменной и перетащить на рабочую область, а потом все это связать подобно тому как это делает Nuke или Slate. Представьте только насколько удобной может быть такой подход! Мне не придется искать где я пропустил одну букву или неправильно написал команду, мне лишь придется работать с самим алгоритмом, визуально видеть что происходит с данными, где они начинают обрабатываться а где заканчивают и что я получу из этого блока на выходе. Представьте насколько удобным может быть подобная визуализация например системы gem-ов в проекте? А как удобно будет искать ошибки если подсвечивать неработающий блок! А как удобно будет работать с циклами и условиями!
Тем более, что программисты очень медленно, но идут в этом направлении. У современных языков совершенно иной уровень абстракции для решения задач, ведь когда-то коммерческие проекты кодились только на ассемблере. (Да, я прекрасно понимаю необходимость низкоуровневого программирования в ряде ситуаций, но вы же понимаете что не всегда есть в этом необходимость)
Искренне надеюсь что в скором времени люди пересмотрят подход (а все к этому идет) и сделают какое-то решение подобное этому же Скретчу, только для реальных популярных языков (само собой с возможностью в случае необходимости переключаться в текстовый режим для более тонкой настройки нодов). Вот бы кто-нибудь замутил стартап с этой идеей для IDE.
Кроме того скажу честно, что даже в среде графических редакторов существует целое направление нодовых редакторов, в которых весь процессинг изображения сводится к построению узлов операций над изображениями. Хотя чисто технически, тот же композинг можно написать и на скриптовых языках, а исторически так оно и делалось. И у кого нибудь поднимется рука назвать например тот же Nuke «детским» или «непрофессиональным»?
Да, согласен что немного утрирую и «ручное» программирование все же отличается от композинга, однако визуальные алгоритмы используются и для анимации, и для симуляции толпы, что в свою очередь тоже достаточно серьезные инструменты, которые раньше прописывались ручками на скриптовых языках. Однако же, не зря тот же Slate пришел в 3ds max (хотя чисто технически, уж материалы-то с шейдерами тоже в свое время кодились текстом) — любая задача может быть упрощена за счет некоторой канонизации и предоставления адекватного интерфейса.
Я ничего не хочу сказать против программистов, но на самом деле в программировании эти подходы и не применяются, потому что люди в какой-то мере не хотят детскости в решении своих сложных задач. Как у тех же админов — только консоль, только хардкор. Однако же подавляющее большинство задач можно более комфортно решать и с помощью GUI. Что есть гпафический интерфейс? Это же по сути надстройка над теми же самыми командами.
Я например, очень бы хотел сам чтобы например для Ruby было такое графическое решение как скретч, возможно какой-то нодификатор. Чтобы не писать ручками одни и те же конструкции, а взять блок, например, цикла, и блок переменной и перетащить на рабочую область, а потом все это связать подобно тому как это делает Nuke или Slate. Представьте только насколько удобной может быть такой подход! Мне не придется искать где я пропустил одну букву или неправильно написал команду, мне лишь придется работать с самим алгоритмом, визуально видеть что происходит с данными, где они начинают обрабатываться а где заканчивают и что я получу из этого блока на выходе. Представьте насколько удобным может быть подобная визуализация например системы gem-ов в проекте? А как удобно будет искать ошибки если подсвечивать неработающий блок! А как удобно будет работать с циклами и условиями!
Тем более, что программисты очень медленно, но идут в этом направлении. У современных языков совершенно иной уровень абстракции для решения задач, ведь когда-то коммерческие проекты кодились только на ассемблере. (Да, я прекрасно понимаю необходимость низкоуровневого программирования в ряде ситуаций, но вы же понимаете что не всегда есть в этом необходимость)
Искренне надеюсь что в скором времени люди пересмотрят подход (а все к этому идет) и сделают какое-то решение подобное этому же Скретчу, только для реальных популярных языков (само собой с возможностью в случае необходимости переключаться в текстовый режим для более тонкой настройки нодов). Вот бы кто-нибудь замутил стартап с этой идеей для IDE.
Искренне надеюсь что в скором времени люди пересмотрят подход (а все к этому идет) и сделают какое-то решение подобное этому же Скретчу, только для реальных популярных языков (само собой с возможностью в случае необходимости переключаться в текстовый режим для более тонкой настройки нодов). Вот бы кто-нибудь замутил стартап с этой идеей для IDE.
Несколько лет ношусь с этой идеей. Впервые предложил её преподу в 2005 году (Тассов К.Л., он преподавал и в универе С++/ООП, и у школьников, Паскаль, вроде).
В итоге всё сводится к вопросу: а вам для чего?
Если надо написать код на С++, то я как программист не вижу способа сделать это быстрее, чем в текстовом виде (с хорошим автодополнением, а-ля JetBrains, вместо жуткого IntelliSense, к примеру).
Не знаю Ruby, поэтому не понимаю ваши слова выше («визуализация системы gem-ов»)… Средства для построения диаграммы классов и прочего проектирования — существуют. Конечно, тут хотелось бы, чтобы перемещение между уровнями абстракции было таким же простым, как ползунок масштаба на Google Earth, может быть вы об этом?
Один проект может состоять из большого количества модулей. Я бы хотел чтобы это визуализировалось как ноды в Nuke или редакторе материалов для 3ds max — Slate, при этом с возможностью скролла и зума, простановкой визуальных связей и подсветкой некорректных блоков и связей.
P.S. а фраза «а вам для чего» напоминает споры о бесполезности манипулятора типа «мышь» в конце восьмидесятых. (была когда-то на хабре статья)
P.S. а фраза «а вам для чего» напоминает споры о бесполезности манипулятора типа «мышь» в конце восьмидесятых. (была когда-то на хабре статья)
состоять из большого количества модулей. Я бы хотел чтобы это визуализировалось
Модуль = набор классов? Что-то вроде UML-диаграмм?
Про инструменты для Ruby не знаю, но вот показательный вопрос: Why do Ruby developers appear not to use UML? Из комментов: «if your coworkers need a cartoon drawing of your code to understand it, then you need to either write better code or hire better coworkers». :) Очень распространённое суждение. Конечно, всё это тормозит эволюцию человеко-машинного взаимодействия.
У фразы «а вам для чего?» тут чуть другое значение. Для чего конкретно? Те цели, которые я представлял себе, все оказались покрыты коммерческими инструментами (та же генерация кода по UML-диаграмме). Настолько, насколько это нужно «рынку» (разработчикам), т.е. мало кому нужно. Спасёт ли дело красивый анимированный зум? Вопрос. :)
История показывает что качественное, продуманное, удобное и комплексное решение может само сформировать рынок.
Согласитесь, если будет разработан интуитивный и грамотный продукт, благодаря которму люди откроют для себя новый опыт разработки, это вполне сможет сформировать рынок, где впоследствии появятся конкуренты и разные реализации.
P.S. как произошло например с iPad, несмотря на то что до него подобные устройства тоже существовали, но не имели коммерческого успеха. Даже на хабре была целая серия статей «и кому это нужно?» или «большой айфон? — не, не выстрелит».
P.P.S. надеюсь только что за идею возьмется хорошая компания с опытом в разработке IDE. Думаю JetBrains если бы взялись, сделали бы конфетку из этой идеи.
Согласитесь, если будет разработан интуитивный и грамотный продукт, благодаря которму люди откроют для себя новый опыт разработки, это вполне сможет сформировать рынок, где впоследствии появятся конкуренты и разные реализации.
P.S. как произошло например с iPad, несмотря на то что до него подобные устройства тоже существовали, но не имели коммерческого успеха. Даже на хабре была целая серия статей «и кому это нужно?» или «большой айфон? — не, не выстрелит».
P.P.S. надеюсь только что за идею возьмется хорошая компания с опытом в разработке IDE. Думаю JetBrains если бы взялись, сделали бы конфетку из этой идеи.
Правильней задавать вопрос не «для чего?», а «какие преимущества/возможности это несет?».
C существующими языками программирования не особо разгонишся, но, как минимум, можна представлять (и редактировать) код напрямую в AST.
Это даст:
* отсутствие синтаксических ошибок
* минимизация ошибок при рефакторинге
* более наглядное представление кода
Примеры: SC (диалект C), Lamdu (диалект Haskell)
Если проектировать новые языки, то тут возможности намного шире.
Например: Subtext. Тут мне сложно коротко описать словами, лучше посмотреть скринкасты.
Это все касается якыков общего назначения, специализированые графические языки уже давно и успешно используются в некоторых областях, и множество этих областей будет только расширяться.
C существующими языками программирования не особо разгонишся, но, как минимум, можна представлять (и редактировать) код напрямую в AST.
Это даст:
* отсутствие синтаксических ошибок
* минимизация ошибок при рефакторинге
* более наглядное представление кода
Примеры: SC (диалект C), Lamdu (диалект Haskell)
Если проектировать новые языки, то тут возможности намного шире.
Например: Subtext. Тут мне сложно коротко описать словами, лучше посмотреть скринкасты.
Это все касается якыков общего назначения, специализированые графические языки уже давно и успешно используются в некоторых областях, и множество этих областей будет только расширяться.
Ага, ага, есть визуалы, для них удобнее визуальный стиль программирования, есть аудиалы, им удобнее наговаривать «код», есть кинестетики, им удобнее щупать код, а есть, наконец, дигиталы — этим вообще не важно что использовать, важен алгоритм :-)
Программирование развивает человека как дигитала. И не важно кто он был изначально.
П.с. разделение человека по типам восприятия информации
П.п.с. все не относительно, а условно: человека на сколько-то процентов визуал/аудиал и т.д. И в течении жизни эти проценты могут перетекать друг в друга.
Программирование развивает человека как дигитала. И не важно кто он был изначально.
П.с. разделение человека по типам восприятия информации
П.п.с. все не относительно, а условно: человека на сколько-то процентов визуал/аудиал и т.д. И в течении жизни эти проценты могут перетекать друг в друга.
Программирование включает в себя ещё и создание архитектуры, а не только её имплементацию. Тут, кажется, учат первому.
Единственное, что в цитате
меня верхняя цифра беспокоит. После 10-12 лет, при классическом подходе (Basic, Pascal, Assembler...) получаемое удовольствие уже должно превышать затраченные усилия.
Единственное, что в цитате
среда программирования создавалась для детей 8-16 лет
меня верхняя цифра беспокоит. После 10-12 лет, при классическом подходе (Basic, Pascal,
А может кто подсказать как в scretch или в ardublock написать фильтр калмана для одной переменной (скачущее атмосферное давление). Или другой подобный не сложный фильтр.
Чем больше возможностей изучать программирование для детей тем лучше. Только стоит помнить, когда нужно прекращать использовать визуальные редакторы и переходить на обычные инструменты.
Вернее я считаю что в данных средах нужно обучать детей основам алгоритмов и языков программирования, а сразу после закрепления материала показывать как это делается или на Java или на C#. И толку будет больше и не будет мучить детей когда захочется сделать что-то серьёзнее.
Вернее я считаю что в данных средах нужно обучать детей основам алгоритмов и языков программирования, а сразу после закрепления материала показывать как это делается или на Java или на C#. И толку будет больше и не будет мучить детей когда захочется сделать что-то серьёзнее.
В общем, блок-схемы и псевдокод просто стали интерактивнее. :) Главное не выключить мозг при этом.
Раз пошла такая пьянка подняли тему Scratch, хочу напомнить про попытку перевести совместно курс по Scratch, плюсики поставили, а переводить взялся 1 человек
habrahabr.ru/post/211877/
Помощь все еще актуальна :)
habrahabr.ru/post/211877/
Помощь все еще актуальна :)
А для С такое есть?
Узнаю опенсорч, как всегда недоработки вылазят в первые же минуты. Совершенно непонятно, сами авторы то тестят свои продукты?
Вот из явных недоработок: в режиме обучения не соответствуют цвета программных блоков в обучалке, и цвета этих же элементов в самом интерфейсе. Ребенок сразу в ступоре: надо найти коричневый элемент, а он оранжевый. Видимо, пока разрабатывали, цвета элементов поменяли, а в обучалке оставили прежние. Теперь обучалка криво выполняет свои функции.
Вот из явных недоработок: в режиме обучения не соответствуют цвета программных блоков в обучалке, и цвета этих же элементов в самом интерфейсе. Ребенок сразу в ступоре: надо найти коричневый элемент, а он оранжевый. Видимо, пока разрабатывали, цвета элементов поменяли, а в обучалке оставили прежние. Теперь обучалка криво выполняет свои функции.
А разве императивный стиль программирования сейчас считается самым правильным?
Sign up to leave a comment.
Скретч 2.0