В корне с Вами не согласен. Странная привычка у современного общества — прикручивать функцию мотивационную учителям. С одной стороны вроде всё и логично, даже правильно. Учитель рассказывает — ученику интересно, он развивается. С другой… не для всех детей подходят такие методы преподавания. Когда мне в школе объясняли математику на белочках и орешках, с какими-то шутками и прибаутками — меня это жутко бесило. Собственно до 5 класса я именно этому на математику забил, т.к. думал, что она создана для «дебилов». Дети — маленькие люди, не надо их считать гулпее себя.
И, по моему скромному мнению, именно ограничения подталкивают развиваться. Я вот в своё время любил Heretic и хотел сделать подобную игру, но с элементами РПГ. И начал читать, изучать… Первые попытки работать с графикой были не удачными — дикие тормоза, переполнение стека… И я начал читать, почему так, изучать как работает то, что я делаю на уровне железа, какие алгоритмы удачнее с точки зрения математики…
Есть ощущение, что во втором случае ученик загрустит и быстро это занятие бросит.
Может тогда ему и не стоит быть программистом? Я начинал с класики — паскаль/ам/си. Они требуют большой внимательности и понимания того, как и что работает. Но при этом, я не могу их назвать сложными. Как и работа с тем же Pure C и памятью скучной. Тут скорее зависит от того, что большинство людей просто не могут получить «фан» от работы и бегут в профессию «потомучтамодна!».
У меня есть опыт как плюсов с нуля, так и сначала SmallBasic, а потом уже плюсов.
У плюсов есть тоже разный уровень погружения. Базовый — не сильно сложнее какого-нибудь другого языка высокого уровня. Разве что семантика SmallBasic проще.
В стартовой группе по плюсам к зачету отваливается гораздо больше детей, и я бы не сказал, что у ребят, которые начали со смолбейсика, а потом перешли на плюсы, есть какие то проблемы понимаем.
Простите за грубость, но те, кто отвалились — им лучше выбрать что-то другое. Мы ведь не о домашнем проекте говорим (где выбирает каждый что хочет), а про образовательный процесс. Если человек не способен понять С++ или ему не интересно само по себе программирование — то может всё же лучше тратить время на тех, кому это по правде интересно?
Ужасно когда приходит человек, занимавшийся рекламой ближайшие пять лет и решает внезапно, что он программист пройдя пару туторов по тому же JS и считает себя сотрудником на равне какому-нибудь специаилсту с 15+ стажа и опытом написания на Си и Лиспах, пониманием матана и т.п. Сам свидетель такого — это очень печально.
Зато во второй группе появилась мотивация к самообучению, ребята вне кружка начали сами смотреть что-то новое: говоришь на втором занятии, что GUI у нас будет через пару недель, а на следующем занятии оказывается, что несколько человек уже сами разобрались. В стартовой группе по плюсам мотивировать ребят что-то почитать вперед или глубже обычно не получается.
Простите за грубость — тут надо смотреть на материал, который вы даете и как его преподносите. В базовых знаниях по С++ нет ничего непостижимого, даже для ребенка 7 класса (сам я его начал тыкать вообще в классе 4-ом и даже тогда он ен казался особо сложным). Тут скорее качество самого материала проблема — либо в нем есть белые пятна (дети чего-то не понимают, т.к. им про это не объяснили), либо язык объяснений слишком сложный для них. Ну или есть вариант — программирование просто не для большинства, которое у вас в группах. У них гуманитарный склад ума и он не способны воспринимать что-то точное. Такое тоже бывает, и тут нет ничего страшного. Просто определенные языки и технологии в этом случае для человека закрыты
Выскажу своё субъективное мнение, что надо давать сразу правильное, потом будет сложнее переучиваться. А мотивация… она у каждого своя. Если человеку интересны ИТ и программирование — он будет осваивать (по себе знаю, всю жихнь учился по книгам/документации, работаю программистом всю жизнь, хотя образование — экономист-математик).
Вот на «неправильной» парадигме учат, а потом студет выходит и не знает простейших вещей. Для HL, системщины или просто для работы в большом проекте (который потом надо поддерживать) — понимание теории очень важно. Знаю по своему горькому опыту.
Basic лучше не брать в качестве первого языка, как и какой-нибудь Python. Они слишком «грязно» реализуют парадигмы. Будет потом у ребёнка извращенное понимание…
сколько инфраструктурного и прочего не относящегося к конкретной задаче кода придётся писать для её решения и насколько легко заменить какой-то компонент фреймворка сторонним или самописным, если встроенный чем-то не устраивает, не теряя поддержки по остальным компонентам.
Вот тут не согласен — чем более низкоуровневое решение, тем проще обойти фреймворк. Пока вы будете в парадигме какого-нибудь Ember мыслить — обойти его изкаробочные части сложно, как только вы отказываетесь от Ember Object/Data и начинаете просто писать решения для ES6 — все становится просто.
Это сомнительный минус. Скажем, в сейчас активно разрабатываемых приложениях мы отказались от «стандартного» однонаправленного потока данных с единым хранилищем состояния на плоских JS-объектов на базе Flux/Redux, сочтя его оверинжинирингом для наших задач. Если бы Redux был неотъемлемой частью React, то, вероятно, стали бы смотреть в сторону чего-то другого.
Всё просто — если я знаю Ember, то влиться в любобй проект на нём будет легко. Если я знаю React — то не факт, вы сами привели пример. А для бизнеса интересны решения, которые потом будет в свостоянии кто-то поддерживать.
Не сочитите за троллинг, вопрос к React-специалисту — почему вы не воспользовались еще до React каким-нибудь handlebars или чем-то подобным? Что реально отличает React от остальных настолько? Я просто не понимаю хайпа вокруг него…
Обычно не столько же, а значительно меньше. При использовании «монолитных» фреймворках часто вся их функциональность не востребована, и даже если умный сборщик в конечный билд её включать не будет, то всё равно во время разработки она будет где-то рядом (например в node_modules) и хорошо если не будет ограничивать свободу своим наличием.
На счет нахождения рядом — согласен, но вам не все ли равно? Я получал из Ember сборку равную проекту на React (последний даже был тяжелее на пару десятков кб) — сложностей не возникло. А про ограничения — как? Я такого еще не видел ни разу.
Вот — вы сами сказали, что мы собираем свой фреймворк. По сути, используя React каждый делает сборку фреймворка. Даже если это самописное решение для React — это все равно часть созданной программистом/командой экосистемы, т.е. мы получаем фреймворк.
Что есть фреймворк? Это структура + более высокоуровневая абстракция. React+Redux+смасса библиотек, реализующих нужный функционал это дают. Чем в финальной «сборке» всех нужных составляющих это отличается от какого-нибудь Ember? ИМХО только тем, что составляющие ты выбрал сам.
Достоинства React — ты можешь «выбрать компоненты» для своего «идаельного» фреймворка. Минус — нет четких парадигм. Два проекта на React могут сильно отличаться. Хотя в сухом итоге мы получим всё тот же фреймворк, способный делать ровно столько же, сколько Ember/Angular/etc., но с необходимостью отслеживать зависимости и удостоверяться, что Казуал Карл не забил на поддержку конкретной библиотеки, которая есть часть проекта.
Религиозная. Любители React очень трепетно относятся к тому, что их любимый инструмент — библиотека, более легковестная, простая в изучении… Правда умалчивают обычно о том, сколько еще библиотек надо поставить для того, чтобы получить нужный результат и то, сколько потом это будет весить… Поэтому я согласен с автором статьи — когда мы говорим React, то имеем ввиду его экосистему. А она уже — фреймворк
В корне с Вами не согласен. Странная привычка у современного общества — прикручивать функцию мотивационную учителям. С одной стороны вроде всё и логично, даже правильно. Учитель рассказывает — ученику интересно, он развивается. С другой… не для всех детей подходят такие методы преподавания. Когда мне в школе объясняли математику на белочках и орешках, с какими-то шутками и прибаутками — меня это жутко бесило. Собственно до 5 класса я именно этому на математику забил, т.к. думал, что она создана для «дебилов». Дети — маленькие люди, не надо их считать гулпее себя.
И, по моему скромному мнению, именно ограничения подталкивают развиваться. Я вот в своё время любил Heretic и хотел сделать подобную игру, но с элементами РПГ. И начал читать, изучать… Первые попытки работать с графикой были не удачными — дикие тормоза, переполнение стека… И я начал читать, почему так, изучать как работает то, что я делаю на уровне железа, какие алгоритмы удачнее с точки зрения математики…
Может тогда ему и не стоит быть программистом? Я начинал с класики — паскаль/ам/си. Они требуют большой внимательности и понимания того, как и что работает. Но при этом, я не могу их назвать сложными. Как и работа с тем же Pure C и памятью скучной. Тут скорее зависит от того, что большинство людей просто не могут получить «фан» от работы и бегут в профессию «потомучтамодна!».
У плюсов есть тоже разный уровень погружения. Базовый — не сильно сложнее какого-нибудь другого языка высокого уровня. Разве что семантика SmallBasic проще.
Простите за грубость, но те, кто отвалились — им лучше выбрать что-то другое. Мы ведь не о домашнем проекте говорим (где выбирает каждый что хочет), а про образовательный процесс. Если человек не способен понять С++ или ему не интересно само по себе программирование — то может всё же лучше тратить время на тех, кому это по правде интересно?
Ужасно когда приходит человек, занимавшийся рекламой ближайшие пять лет и решает внезапно, что он программист пройдя пару туторов по тому же JS и считает себя сотрудником на равне какому-нибудь специаилсту с 15+ стажа и опытом написания на Си и Лиспах, пониманием матана и т.п. Сам свидетель такого — это очень печально.
Простите за грубость — тут надо смотреть на материал, который вы даете и как его преподносите. В базовых знаниях по С++ нет ничего непостижимого, даже для ребенка 7 класса (сам я его начал тыкать вообще в классе 4-ом и даже тогда он ен казался особо сложным). Тут скорее качество самого материала проблема — либо в нем есть белые пятна (дети чего-то не понимают, т.к. им про это не объяснили), либо язык объяснений слишком сложный для них. Ну или есть вариант — программирование просто не для большинства, которое у вас в группах. У них гуманитарный склад ума и он не способны воспринимать что-то точное. Такое тоже бывает, и тут нет ничего страшного. Просто определенные языки и технологии в этом случае для человека закрыты
Вот на «неправильной» парадигме учат, а потом студет выходит и не знает простейших вещей. Для HL, системщины или просто для работы в большом проекте (который потом надо поддерживать) — понимание теории очень важно. Знаю по своему горькому опыту.
Вот тут не согласен — чем более низкоуровневое решение, тем проще обойти фреймворк. Пока вы будете в парадигме какого-нибудь Ember мыслить — обойти его изкаробочные части сложно, как только вы отказываетесь от Ember Object/Data и начинаете просто писать решения для ES6 — все становится просто.
Всё просто — если я знаю Ember, то влиться в любобй проект на нём будет легко. Если я знаю React — то не факт, вы сами привели пример. А для бизнеса интересны решения, которые потом будет в свостоянии кто-то поддерживать.
Не сочитите за троллинг, вопрос к React-специалисту — почему вы не воспользовались еще до React каким-нибудь handlebars или чем-то подобным? Что реально отличает React от остальных настолько? Я просто не понимаю хайпа вокруг него…
На счет нахождения рядом — согласен, но вам не все ли равно? Я получал из Ember сборку равную проекту на React (последний даже был тяжелее на пару десятков кб) — сложностей не возникло. А про ограничения — как? Я такого еще не видел ни разу.
Что есть фреймворк? Это структура + более высокоуровневая абстракция. React+Redux+смасса библиотек, реализующих нужный функционал это дают. Чем в финальной «сборке» всех нужных составляющих это отличается от какого-нибудь Ember? ИМХО только тем, что составляющие ты выбрал сам.
Достоинства React — ты можешь «выбрать компоненты» для своего «идаельного» фреймворка. Минус — нет четких парадигм. Два проекта на React могут сильно отличаться. Хотя в сухом итоге мы получим всё тот же фреймворк, способный делать ровно столько же, сколько Ember/Angular/etc., но с необходимостью отслеживать зависимости и удостоверяться, что Казуал Карл не забил на поддержку конкретной библиотеки, которая есть часть проекта.