руководители кружков здесь есть?
У умеющего пользоваться напильником, полет фантазии не ограничен. В плоть до настрагать недостающие кубики:-)
Полет фантазии имеющего напильник ограничен объемом материалов допускающих обработку напильником и свободным временем на это занятие. Время потраченное на “пиление кубиков” это время отнятое от “складывания кубиков”.
Так что даже имея напильник, материалы и время излишне и без надобности увлекаясь “освоением напильника” в итоге сильно рискуем напилить много кубиков и так и ничего из них не построить. Получим не конструктора зданий (пусть и Lego зданий ) а мастера производства кубиков. Дело не в Lego vs. Напильник.
Человек не умеющий держать напильник в руках но умеющий спроектировать в компьютере 3D модель и отлить ее в пластике на 3D принтере не такой уж безрукий тыкатель кнопок каким он кажется “мастеру лобзика и рубанка”. Ну жизнь такая нынче. С лего роботостроителями тоже как то так.
Что для кубиков лего - у меня лично килограмм пятнадцать-двадцать этого добра. Свои запасы + наследие друзей и родственников. По объему хватит на пару таких заводиков было бы желание. Так что при необходимости мастерской да еще за деньги того порядка сколько стоит ОДИН единственный комплект Mindstorm набрать необходимый для постройки заводика объем самих кубиков не вопрос. Не такие уж они и дорогие и не такие уж и редкие.
Поверьте у “убогих роботостроителей” не наличие или отсутствии кубиков и/или ограничения базового софта ограничение - проблема в умении ими пользоваться и желании идти за рамки делай раз делай два. Они и напильником наработают не больше.
Полет фантазии имеющего напильник ограничен объемом материалов допускающих обработку напильником и свободным временем на это занятие. Время потраченное на “пиление кубиков” это время отнятое от “складывания кубиков”.
Это время потраченное на приобретение скилов применимых при отсутствии кубиков.
Так что даже имея напильник, материалы и время излишне и без надобности увлекаясь “освоением напильника” в итоге сильно рискуем напилить много кубиков и так и ничего из них не построить. Получим не конструктора зданий (пусть и Lego зданий ) а мастера производства кубиков.
Проектировать и строить кубики тоже кому то надо уметь.
Человек не умеющий держать напильник в руках но умеющий спроектировать в компьютере 3D модель и отлить ее в пластике на 3D принтере не такой уж безрукий тыкатель кнопок каким он кажется “мастеру лобзика и рубанка”. Ну жизнь такая нынче. С лего роботостроителями тоже как то так.
Вот про жизнь нынче, это отмаза. Мы же сейчас про обучение говорим, а не про производство? Да и не спроектирует в компутере 3Д модель чел не имеюший элементарных знаний геометрии. И ничего не отольет без наладчика, который все пальцы об тот самый пластик обжег.
Что для кубиков лего - у меня лично килограмм пятнадцать-двадцать этого добра.
У меня напильников в сухом весе больше:-)
Поверьте у “убогих роботостроителей” не наличие или отсутствии кубиков и/или ограничения базового софта ограничение - проблема в умении ими пользоваться и желании идти за рамки делай раз делай два. Они и напильником наработают не больше.
Заметьте, я никого так не называл. Я совсем не против Лего кубиков, но не на начальном уровне. Скажем из деревянного кубика с помощью напильника можно сделать призму. А уж прикрутить её к серве:-)
Это время потраченное на приобретение скилов применимых при отсутствии кубиков
На заре радиолюбительства очень полезными навыки и умением было изготовление диода для детекторного приемника из поручных материалов. Наверное в условиях тотального отсутствия диодов ценность этого навыка будет очень высока. Но сегодня преподаватель настаивающий на овладении данного навыка при постройке детьми детекторного приемника - или фанатик реконструктор или идиот. И от того и от другого надо держаться подальше - радиолюбительским навыкам полезным в современных условиях такой преподаватель даже если он ими владеет не научит.
. Мы же сейчас про обучение говорим,
Правильно про обучение. Главное при этом помнить про обучение ЧЕМУ. И не скатится от обучения изготовления/проектирования домов к обучению изготовлению/проектированию кубиков без строительства домов. Обосновывая обучение строительству кубиков просто потому что раньше “кубиков не было” а вдруг и сейчас исчезнут.
Умение делать кубики для строительства дома ПОЛЕЗНОЕ но НЕ ОБЗАТЕЛЬНОЕ умение для специалиста по изготовления/проектирования кубиковых домов. Специалистов проектирования кубиков нужно 1 на 100 специалистов по строительству домов из кубиков. Второй специалист по изготовлению кубиков будет “лишним” в большей степени чем 101 специалист по изготовлению домов. Увы в условиях широкой номенклатуры и доступности кубиков - навык их изготовления при строительстве домов чаще лишний. для расширения кругозора и навыков полезный но при дефиците времени лишний и не обязательный.
Знание зонной теории, теории конденсированного состояния, типовых моделей движения зарядов полупроводниках - знания полезные но рядовому инженеру радиолюбителю увы лишние. Он и без них отлично должен и может проектировать на основании готовых схемотехнических кубиков. Люди придумывающие эти кубики конечно нужны и важны но в пропорции 1 на 1000.
Да и не спроектирует в компутере 3Д модель чел не имеющий элементарных знаний геометрии.
Вы не поверите в современном САПР спроектирует. Линейкой, циркулем и карандашом не сможет, а в Компасе сделает. И совсем не теми инструментами приемами и не по той методике что “в ручную”.
Простейший пример - правильный 5 угольник линейкой циркулем сегодня умеет строить далеко не каждый второй школьник. А уж о взаимосвязи возможности точного построения многоугольника с задачей разрешимости в радикалах уравнений определенного вида и как именно по корню выраженному в радикалах надо строить многоугольник - знает дай бог один из ста .
Но 99% школьников совершенно не зная основ геометрии многоугольников легко построят нужный пятиугольник в Paint не говоря о Компас-е или Солид-е.
Проектировать и строить кубики тоже кому то надо уметь.
Правильно но это отдельное умение. Не связанное напрямую с умением проектировать и строить из кубиков. Кому то надо 1 из 10.
Если в кружке свободно уже свободно доступен лазер или ЧПУ фрезер то для питомцем этого логичнее и правильнее потратить в первую очередь время на на освоение не ручного лобзика а на освоение ПО проектирования и управления Лазерным и ЧПУ фрезер-ными “лобзиками”. Да руками без “освоенных лобзиков” питомцы кружка сделать мало что смогут. Но в современных условиях полученные навыки в жизни им будут полезнее и сделают они своими инструментами не меньше и не хуже чем мастера старого стиля.
WBR
P.S. Коллеги честное слово - на досуге я фанат реконструкции “старых навыков” - в плоть до разведения огня палкой и веревкой. Но именно по этому я отлично понимаю и знаю степень важности и полезность их в современных условиях. Умение пользоватся огнивом, кресало и трутом полезно - но потратить время и озаботится наиличием и сохранностью спичек для результата правильнее.
Тоже самое в программировании которое я слава богу знаю от истоков дней.
Желающему писать игру сегодня надо изучать кубики Unity и/или libGDX и тому подобного, а не осваивать пиление кубиков управления спрайтовой графикой, собственные реализации Z-буфера и иже с ними. А знание что это за звери - спрайты, шейдеры, альфаблендинг и много много чего еще хотя и не вредно но все таки в современных условиях уже “пиление кубиков” без которого вполне можно прожить создавая игру.
P.P.S. Что то я букворчек на форуме перебрал. Убедил не убедил, понят не понят - закругляюсь. Финита.
(1\2 оффтоп)
Тоже самое в программировании которое я слава богу знаю от истоков дней.
Желающему писать игру сегодня надо изучать кубики Unity и/или libGDX и тому подобного, а не осваивать пиление кубиков управления спрайтовой графикой, собственные реализации Z-буфера и иже с
А сколько у вас выпущеных игр?
Движок - это редко больше 10% от полной трудоёмкости создания игры. Даже мелкой. При этом, иногда бывает так, что написать свой движок - быстрее, чем изучать чужой. Тот-же юнити уже слишком универсален и от этого процесс разработки (чего-то хоть чуточку НЕстандартного) не является более быстрым, чем на чистом ЯП аналогичный проект зафигачить, особенно 2Д.
А знание что это за звери - спрайты, шейдеры, альфаблендинг и много много чего еще хотя и не вредно но все таки в современных условиях уже “пиление кубиков” без которого вполне можно прожить создавая иг…
Во-первых в игровой индустрие есть специализации, где именно эти знания и навыки востребованны.
Во-вторых - сейчас столько школоты и просто недоучек дорвались до юнити и прочих готовых инструментов, что количество корявых и бездарно прожирающих вычислительную мощность поделок бьёт все мыслимые пределы! И в том числе потому, что люди просто не знают, что означает тот или иной эффект, как он устроен, сколько памяти и тактов процессора он сжирает. И на сдачу сортируют пузырьком. 😵
Правильно про обучение. Главное при этом помнить про обучение ЧЕМУ. И не скатится от обучения изготовления/проектирования домов к обучению изготовлению/проектированию кубиков без строительства домов. Обосновывая обучение строительству кубиков просто потому что раньше “кубиков не было” а вдруг и сейчас исчезнут.
Тогда вопрос обучение кого. Я грю про мелкопацанов, которые еще толком не понимают чего хотят. Про вдруг исчезнут я ни че не говорил.
Люди придумывающие эти кубики конечно нужны и важны но в пропорции 1 на 1000.
И откуда возьмется этот 1 из 1000, если всей 1000 вдолбили что зонная теория это долго скучно и не интересно.
Но 99% школьников совершенно не зная основ геометрии многоугольников легко построят нужный пятиугольник в Paint не говоря о Компас-е или Солид-е.
Совершенно не понимая что происходит. Кады призваны избавить от рутины, а не заменить знания.
Если в кружке свободно уже свободно доступен лазер или ЧПУ фрезер то для питомцем этого логичнее и правильнее потратить в первую очередь время на на освоение не ручного лобзика а на освоение ПО проектирования и управления Лазерным и ЧПУ фрезер-ными “лобзиками”. Да руками без “освоенных лобзиков” питомцы кружка сделать мало что смогут. Но в современных условиях полученные навыки в жизни им будут полезнее и сделают они своими инструментами не меньше и не хуже чем мастера старого стиля.
У мя пацаны пишут Г-код напрямую, в текстовом редакторе, под это дело.
Убедил не убедил, понят не понят - закругляюсь. Финита.
Я Вас понял? Картины можно лепить из клипартов, музыку из сэмплов, и это правильно:-)
А сколько у вас выпущеных игр?
Выпущенных как коммерческое приложение для зарабатвания денег или написанных в процессе обучения детей и с активным участием. Первых за много лет тому назад 0 - я специализируюсь на M2M сервисах. Вторых в прошлом году штук 5.
Типичный состав команды для разработки игры:
Автор идеи игры программист и основной пользователь - 7 лет.
QA, CodeReview, Скин дизайнер (по бумажным эскизам автора) тех поддержка и менджер проекта (побуждающий делать а не отлынивать) - 50 лет
Платформа язык программирования и “кубики разработки” - Scratch
Все задуманные игрушки (не суть что они вариации на тему хорошо извесных аркад) благополучно автором/програамистом доведен до релиза. Отыграны авторами и его друзьями раза по три модифицированны и сейчас забыты как пройденный и теперь отлично понятный этап.
Для сравнения тот же “программист” в кружке по программированию на платформе PascalABC дальше вариаций на тему hello World не продвинулся как и все остальные изучающие программирование. Кружок к слову рассчитан на детей на пару тройку лет старше 7 летку туда взяли в качестве исключения за демонстрацию знаний по предмету.
И я надеюсь что мы все помним помним что говорим о тулсете не профессионалов создателях прорывов в гейм индустрии - те все давно знают чем как и каким образом им удобнее. И кубики пилить они умеют. Мы говорим об обучающем тулсете и о новичках и начинающих программистах изучающих вопрос как и на чем сегодня пишут игры.
И на сдачу сортируют пузырьком
Именно потому что новички пытаются в силу своего разумения пилить собственные “кубики сортировки” так как знают и умеют. А знают и умеют пока мало для того чтобы их пилить качественно. А используй они “готовый кубик” из стандартной библиотеки ну скажем - TreeSet и о чудо O(log(n)) даже при ооочень малых знаниях о алгоритмах сортировки и эффективности их применения. Ваш пример только подтверждает то что умение грамотно пользоваться “правильными кубиками” для результата важнее чем умение пилить их самостоятельно.
А уж освоив “стандартные хорошие кубики” не все но некоторые дойдут до состояния когда ЗНАЯ в каких условиях линейный поиск быстрее построения сбалансированного дерева сумеют осознанно запилить для конкретных условий и задач кубик более оптимальный чем в готовом наборе.
Во-вторых - сейчас столько школоты и просто недоучек дорвались до юнити и прочих готовых инструментов, что количество корявых и бездарно прожирающих вычислительную мощность поделок бьёт все мыслимые пределы! И в том числе потому, что люди просто не знают, что означает тот или иной эффект, как он устроен, сколько памяти и тактов процессора он сжирает.
Это не только в игрописании, это везде так. Потому что сейчас проще, дешевле, и быстрей, воткнуть еще 120 Гиг оперативки, и пару тройку десятков ядер к ним, вместо того чтобы нанять и содержать людей умеющих оптимизировать код вплоть до обработки кубиков напильником.
ЗЫ Как в известном анекдоте “…А в Париже есть не падшие женщины? Да, но их мало, и стоят они дорого.”
Картины можно лепить из клипартов, музыку из сэмплов, и это правильно:-)
Имя Энди Уорхол - что ни будь говорит в вопросе можно или нельзя?
Я грю про мелкопацанов, которые еще толком не понимают чего хотят.
Вот и я говорю про них. Чему именно они хотят научится и получить как результат - самолет или умение пилить напильником .
У мя пацаны пишут Г-код напрямую, в текстовом редакторе, под это дело.
Дык я тоже WSDL, swagger пишу и читаю что в нем что в vi без проблем - но SOAP UI для новичка все равно лучше 😃.
Дык я тоже WSDL, swagger пишу и читаю что в нем что в vi без проблем - но SOAP UI для новичка все равно лучше .
Не в редакторе под это дело, а код под это дело:-)
Платформа язык программирования и “кубики разработки” - Scratch
Рассказать что там в нутре этих полиморфных кубиков? И как красиво они пилятся напильником. И почему они не прижились?
(прошу простить за частичный оффтоп)
Выпущенных как коммерческое приложение для зарабатвания денег или написанных в процессе обучения детей и с активным участием. Первых за много лет тому назад 0 - я специализируюсь на M2M сервисах. Вторых в прошлом году штук 5.
1 и 2 - существенно разный уровень требований касаемо степени допилки. При выходе на рынок (деньги - это всегда третье дело, так как они возможны ТОЛЬКО после успеха) продукт должен быть не ниже некой незримой “планки качества”: если выше - получает распространение и может быть комерциализирован, если ниже - сразу нуль: не нужен вообще никому, так как рядом полно более привлекательных аналогов.
Для детей и процесса обучения требования не высоки: по большому счёту дети на занятии будут “играть” во что угодно, что дадут.
Разница в трудоёмкости между 1 и 2 - около 90%. Эти самые 90% - это полировка и допилка; то, что отличает коммерческий продукт от играбельной бетты.
К настоящему моменту шесть выпущеных коммерческих игр. Полная разработка, кроме музыки. И еще около десятка при работе на фирму (там были отдельные художники).
Типичный состав команды для разработки игры:
Это вы наверное какой-то свой случай описываете. А в жизни - состав команды очень зависит от “размеров” игры. В мелких инди-командах зачастую не более 3х человек: два программера и один художник. Звукач\музыкант - либо кто-то из них по совместительству, или приглашённый\нанятый. Или звуки-музыка тупо лицензируются с какого-нибудь audiojungle.
благополучно автором/програамистом доведен до релиза. Отыграны авторами и его друзьями раза по три модифицированны и сейчас забыты как пройденный и теперь отлично понятный этап.
Звучит несколько наивно, поясню:
- Нельзя нормально протестировать игру на друзья\родственниках. Ценность обратной связи от них - нуль, а иногда даже вред. Вред - это когда друзья и родственники начинают советовать, а разработчик - эти советы слушать.
А самое главное - не сунувшись на рынок, где конкуренция коммерческих продуктов, нельзя ощутить реальный объем работы, нельзя научиться смотреть сквозь характеристики своего продукта и его недостатки: понимать до мелочей, что там правильно, что не правильно, что работает (как игровая механика), а что нет. Не ощутить те 90% титанической работы, которые являются обязательным условием для превращения бетты в законченый конкурентоспособный продукт. И вот эти вещи они никак не связаны ни с технологией (самодельное оно с нуля или на юнити из готовых ассетов), ни с умением писать оптимальный код. И никак не связаны с умением придумать что-то оригинальное или новое. Это тонкости из области продукт-дизайна, гейм-дизайна, наративного дизайна и психологии.
Для сравнения тот же “программист” в кружке по программированию на платформе PascalABC дальше вариаций на тему hello World не продвинулся как и все остальные изуча…
Это зависит от преподавателя, а не от платформы. Думаю, вы прекрасно это понимаете 😃
…Мы говорим об обучающем тулсете и о новичках и начинающих программистах изучающих вопрос как и на чем сегодня пишут игры.
К вопросу как и на чём: тут важно не путать средства разработки по степени их популярности и раскрученности - с применимостью самих технологий. До сих пор игры делают на всём, что можно заставить инерактивную картинку на экран вывести. Можно на MS excel игру сделать и на маткаде тоже можно.
Именно потому что новички пытаются в силу своего разумения пилить собственные “кубики сортировки” так как знают и умеют. А знают и умеют пока мало для того чтобы их пилить качественно.
- Без вот такого пиления они точно знать и уметь нифига не будут. В том числе:
и о чудо O(log(n))
- будут элементарно не знать, что такое вычислительная сложность.
Ваш пример только подтверждает то что умение грамотно пользоваться “правильными кубиками” для результата важнее чем умение пилить их само…
В корне не согласен!
Ключевым является не “использовать правильные (?) кубики”, а “уметь пользоваться выбранным инструментом”!
А еще лучше - уметь пользоваться разными инструментами.
А уж освоив “стандартные хорошие кубики” не все но некоторые дойдут до состояния когда…
Повторюсь: нет “стандартных хороших кубиков”. Есть популярные. Юнити - популярен. Но так ли он хорош? Ведь, чисто как пример, буквально рядом с ним в индустрие - популярны такие уродливые чудища, как яваскрипт и ПХП 😵 Популярное != хорошее.
Если преподавать программирование детям - глубоко убеждён, что надо преподавать классику: плюсы, может быть паскаль. Опционально - шарп или яву.
Напоследок: вот человек, тоже реальный разработчик с опытом коммерческих игр, рассказывает свой опыт ведения детского кружка по программированию игр. Думаю, это интересный материал: flashgameblogs.ru/blog/results/1619.html
Рассказать что там в нутре
Вы точно о Scratch и процессе создания игр и обучения основам програмирования на его основе - или о им подобным “Lego - кубикам” програмирования. CodeCombat, JavaRush, Алиса.
На счет - не прижились. В процессах обучения (увы не в Российских школьно кружковых реалиях) еще как прижились. Когда ребенок в CodeCombat (Python) потратив день писхуя ругаясь что ничего не получается через день вечером радостно и гордо сообщает "Папа я понял в чем дело. Я переменную не в том цикле проверяю по этом он неправильно дерется " - поверьте это много стоит в плане ОБУЧЕНИЯ программированию. И то что программирование в CodeCombat даже и на языке Python в общем то “ненастоящее” и “игрушечное” программирование кубиками в плане ОБУЧЕНИЯ навыку думать понимать какие кубики есть и что они обеспечивают искать проблему и решать ее используя тот тул сет что есть совершенно не важно.
Это вы наверное какой-то свой случай описываете.
Естствено это случай когда я обучаю навыкам программирования ребенка задавшего вопрос а можно написать вот такую игру.
Это старт с нуля и введение в профессию/увлечение. А не выращивание эффективной производственной команды. Строительство “завода” ведется совершенно по другим лекалам - но на конвеерную линию завода и не полный ноль приходит ноль идет в ПТУ.
Не ощутить те 90% титанической работы,
А новичку пробующему свои силы и еще не понимающего нравится ему это направление или нет в принципе это НАДО? ощущать эти 90% титанической работы?
Ну вот честно - что для ребенка начинающего обучение в авиамодельном кружке привлекательнее и на занятия какого кружка он пойдет с большим удовольствием
– туда где начинают со сборки самолета из готовых вырезанных деталей а потом учат их вырезать правильно держа нож
– или туда где начинают с обучения как правильно держать нож а до сборки самолета допускают избранных кто наконец то смог вырезать правильные детали
Вот IMHO ключевое в обучении
— По вашей ссылке
Стараюсь следовать правилу: после очередного занятия у каждого ученика должна появиться новая фишка и проект должен быть рабочим на конец урока
—
И для достижения этой цели все средства хороши. ЕСли квалификация и опыт обучающегося требует выдачи Lego кубиков - надо выдавать кубики.
Для обучающегося важно не понять трудности настоящей разработки, не освоить правильный язык - но привыкнуть в заданное время и регулярно получить результат. Остальное включая навыки правильного использования правильного инструмента со времени появится как инструмент и способ достижения этой цели.
Если преподавать программирование детям - глубоко убеждён, что надо преподавать классику: плюсы, может быть паскаль. Опционально - шарп или яву.
А я глубоко убежден что детям не нужен ни Паскаль, ни C# ни java. Важнее навык структурного мышления, знание назначения инструментов тулсета и умение корректно и по назначению их использовать. Знание как устроены эти инструменты внутри - полезно но не критично и играет заметную роль в достаточно редких ситуация. А вот не знание назначения, возможностей и ограничений “кубиков” и попытка заменить их своим разумением исходя из общих принципов “играет сразу” с грохотом и треском.
Forth, Fortran, Occam, C, C++, Pascal, Basic ( в разных различных и разнообразных вариация от GW до Visual), PHP, Python, Erlang, Java, Bash - языки и платформы чтение и выражение мыслей на которых у меня не вызывает затруднений (экзотические или специализированные варианты типа PlayBook Ansible и иже с ними оставим за скобками). Но действительно эффективно я могу работать только на тех платформах и языках чьи “кубики лего” висят на кончиках пальцев. Собрать надежный Web сервис быстрее качественнее и правильнее мне на основе готового Lego-кубика на выбор - JAX_WS, AXIS2, CXF несмотря на то что знание позволяет его пилить и на С и на Bash скрипте (и такое было по необходимости).
И еще пример важности знания кубиков, а не языка или инструмента.
Навыки программирования общего вида на Java слабо помогают пониманию как работает код RabbitMQ (Erlang). А вот знание “лего кубика” - лмбда исчисления и замыкания - с чем их едят и как применяется очень даже. И неважно где именно освоен кубик и его принципы в Erlang (как основа языка) или в Java (как специфическая возможность одной из версий).
Вы точно о Scratch
Я про scratch.mit.edu . Проект замечательный, ток его цель (одна из) как раз популяризация того лучшего что не прижилось.
Эк тут народ понесло…
И котлеты и мухи в кучу.
Техническое творчество (моделизм) - в основе имеет цель научить думать головой и работать руками с материалами и инструментом для достижения определенной цели.
Все остальные направления так или иначе исключают материалы и инструмент. Работа руками и получение результата сводится к манипуляциям с “кубиками”.
С задачами преподавателя - всё еще хуже… Как оценить работу преподавателя в творчестве (пусть и техническом), если критерии оценки привязаны к результатам типа массовости участия в мероприятиях, количеству грамот и призовых мест?
Если всё это поделить на неоднородность в уровне подготовки, восприятия и кривизны рук детей, помножить на нулевое финансирование и мизерные зарплаты педагогов - то станет понятно, почему лучше сделать много примитивов, чем упираться и достигать реально интересных результатов.
Это старт с нуля и введение в профессию/увлечение. А не выращивание эффективной производственной команды.
Да, извиняюсь, немного про другое говорил. Ребёнку, безусловно, не надо сразу профессионально.
Вот IMHO ключевое в обучении
— По вашей ссылке
Стараюсь следовать правилу: после очередного занятия у каждого ученика должна появиться новая фишка и проект должен быть рабочим на конец урока
Так это не ИМХО не какое, это самое важное!!! Результат - это то, что заставляет людей (и особенно детей) продолжать заниматься чем-то.
Но при этом:
Для обучающегося важно не понять трудности настоящей разработки, не освоить правильный язык - но привыкнуть в заданное время и регулярно получить результат. Остальное включая навыки правильного использования правильного инструмента со време.
С одной стороны, безусловно, нет особой разницы, какие кубики. С другой - некоторые кубики бывают откровенно уродскими и могут научить плохому; другие - быстро органичивают обучающегося и в итоге тоже могут научить плохому (допустим классические варианты бейсика, в котором нет структур и классов и где допустим нельзя функции именовать).
А я глубоко убежден что детям не нужен ни Паскаль, ни C# ни java. Важнее навык структурного мышления, знание назначения инструментов тулсета и умение корректно и по назна…
- Если преподаватель не лентяй, то можно хоть на васике, хоть на пасрале сделать заготовки (вплоть до фрэймвёрков), где у ребёнка на экране уже будет все двигаться и шевелиться, а нало лишь менять кое-какие параметры и дописывать минимальный код, без необходимости писать всё с нуля.
Да и всякие обучающие среды и обёртки для детей, типа вашего Scratch, придуманы не вчера: c-robots и p-robots были еще в 80х годах, а еще раньше был Logo (хотя сам лично я этого не успел застать - для меня это просто история).
Навыки программирования общего вида на Java слабо помогают пониманию как работает код RabbitMQ (Erlang)
ИМХО функциональное программирование не является практичным и его вообще изучать не обязательно, кроме как для расширения кругозора. Даже несмотря на попытки из года в год дотянуть функциональные языки до применения в коммерческой разработке! Просто потому, что покуда программа взаимодействует с человеком - она должна подстраиваться под человека. А человек не мыслит функциями, он мыслит последовательным изменением состояний, как машина Тьюринга. В итоге код на ФЯП в той или иной мере по структуре становится похожим на обычный ЯП: где заведены переменные и производятся их последовательные преобразования. Чистых функциональных языков нет, они почти все мультипарадигменные. А для обычных ЯП, типа упомянутой явы, лямбды - не более, чам синтаксический сахар, нужды в них нет. И даже больше того: чем гибче язык и чем больше в нём всего - тем больше на этом самом языке в итоге го8нокода. Это правда жизни. С этой точки зрения есть большой смысл обучать на чём-то простом или строгом, без буйства парадигм и возможностей.
Напоследок: вот человек, тоже реальный разработчик с опытом коммерческих игр, рассказывает свой опыт ведения детского кружка по программированию игр.
Опять узкая специализация. ИМХО Учить нужно программировать в принципе, а не конкретному языку/фреймворку/здаче.
А так, те же кубики, вид с боку.
Опять узкая специализация.
Совсем не узкая. Из всего программирования, разработка игр - включает в себя больше число разных задлач, в том числе программных. Почти все современные наработки в области ИИ, например, выросли из игр или на играх.
Ну а для детей - это просто хорошая мотивация, простой способ получить осязаемый результат!
Авиамодели - это же по сути тоже игрушки, мастерить можно и табуретки 😃
С другой - некоторые кубики бывают откровенно уродскими
Ну дык плохо заточенный нож это тот же уродский кубик - но ведь до правильной заточки ножа преподаватель кружка авиамоделирования не опускается. Хотя это тоже весьма неплохое умение точить ножи до бритвенной остроты. Рекомендованный нож априори предполагается правильным и острым - аналогично рекомендуемый Lego-кубик не уродским а правильным для задачи. Тупые ножи и идиотские кубики естественно существуют - их брать не надо.
другие - быстро органичивают обучающегося и в итоге тоже могут научить плохому
Тут тоже преподавателю все козыри в руки. Одна из задач преподавателя научить детей вовремя понимать что тулсет/инструмент отлично подходящий под задачи и цели одного этапа/тип задач может совершенно не подходит под цели и задачи другого этапа и при переходе к нему пора осваивать новые инструменты и кубики. Вовремя понять и что освоенное устарело или просто не подходит под задачу, выбрать, освоить и применить более адекватное задаче инструменты - великое и ценное умение. Порой оно даже важнее виртуозного владения чем то конкретным. При этом метаться лишний раз тоже вредно. Тут главное не попасть в ситуации - когда в руках молоток все задачи становятся похожими на гвозди или по ходу проекта сумел освоить 10 технологий но проект так и не завершил.
Просто потому, что покуда программа взаимодействует с человеком - она должна подстраиваться под человека.
А Erlang не для человека. Пилить GUI на Erlang-е мазозхизм. А вот с нише M2M, мягкого реального времени распредленных и параллельных вычислений и … много чего еще ситуация саавсем другая. Люьми и их потребностями там и не пахнет. Программирование то не ограничивается задачей взаимодействие с человеком. Надеюсь для всех давно не секрет что 99% промышленных программ, компьютеров и систем о существовании человека о необходимости и проблемах взаимодействия с ним даже не догадываются. Самый яркий пример - мозги автомобиля, их миллионы - а софта отвечающий за взаимодействие с человеком в них дай бог процент наберется. Угол опережения, показания лямбда зонда, датчика детонации, … 100500 датчиков его интересуют, им обслуживаются и занимают 90% его внимания и объема кода. А вопросы какую зажечь лампочку или что нарисовать на экране им решаются по остаточному принципу в свободное от основной работы время . В мире профессионального программирования - “убить человеков вся власть роботам” IMHO давно свершившийся факт. НУ по крайне мере за последние лет 8 я написал сотни если тысячи машинных интерфейсов и методов и дай бог пар тройку GUI взаимодействия с человеком.
если преподаватель не лентяй,… сделать заготовки (вплоть до фрэймвёрков)
Ну то есть свои родные самописные но те же кубики. А смысл? Чем выверенные стандартные не устраивают - или не знал потому написал свое с нуля.
Кто из нас в детстве не писал собственную библиотеку создания и управления оконным интефейсом - в детстве (года 80-90) писали почитай все - а сейчас за исключением ооооочень малой прослойки почему то при построении GUI пользуются той или иной готовой профессиональной или не очень библиотекой не изобретая в 100500 раз велосипед. Кто QT, кто MFC, кто Swing, кто … их десятки если не сотни со своими про и контра - но тем не менее массово свою радемую оконную библиотеку и виджеты для нее ни преподаватели ни программисты уже давно не пишут - бессмысленно. Готовых кубико-конструкторов UI достаточно чтобы не определять в своей Windows программе оконную функцию и цикл обработки событий окна - нынешние программисты и слов то таких не знают - они и правильно.
ИМХО Учить нужно программировать в принципе
Как раз наоборот - я на работу к себе не возьму умеющего “программировать в принципе” но не знающий ключевых для моей отрасли и систем библиотек, реализаций протоколов, фреймоворков разработки и т.д. и т.п. Пробелы и незнание отдельных аспектов можно пропустить ибо абсолютно все знать невозможно а научится можно чему угодно - но если человеку при приеме на работу надо учится всему - я же на работу в отдел принимаю человека а не на учебу.
Ну зачем мне человек без знаний и опыта работы с JMS, Web-серверами, знания XML и стека работы с ним, понимания деталей работы протоколов HTTP, OAUTH2, механизма работы инжекции зависимостей, общей структуры и ключевых элементов IT ландшафта оператора связи или вообще путающий Java и JavaScript.
Вот когда освоить базовые для отрасли и нашего отдела навыки и знания - welcome 100+ без проблем. “А без елочки не приходи”.
Во блин. Прям как на форум программистов заглянул. 😦
Во блин. Прям как на форум программистов заглянул.
Некоторые больше “рыбаков” напоминают, с указанием длины рыбы…😃
И главное на один глагол, жгут “десятком”.😒