Комментарии 309
Честно говоря, подобные мысли были. Просто в какой-то момент мне подумалось, что нужно попробовать посмотреть на эту ситуацию с другой стороны: многие из нас пришли в программирование, в том числе и в веб-программирование, не из вёрстки, а из старых добрых геометрических анимаций QBasic — возможно, этот путь не так прост, но если он протоптан, то почему бы не попробовать провести через него другого человека?
С другой стороны, конечно, это может не сработать. Но я надеюсь, что интерес к сотворению чего-то, полезного для себя любимой, сыграет свою роль, и всё получится!
Здесь всё будет зависеть от того, как у меня получится преподнести материал.
Я буду стараться!
Думаю, что поспособствовало этому изучение в школе QBasic и Pascal, простых, понятных и дающих базовые понимания.
Вот и правильный ответ — Delphi девушке покажи и через пару месяцев она сама себе простейшую книгу рецептов напишет — оффлайновую, но с блэкджеком и тюлевыми занавесками.
нужно только в названии переменных писать с чем работаешь в каждый момент времени, чтобы не забыть
Небольшой пример можно?
Second_n=2 #n-number
Ну и всегда есть type(), в случае если забыл написать что есть что. Ну и отладчик не забываем.
Например, если мне некоторая величина поступает в виде строки из текстового поля, мне её нужно преобразовать в число, а потом эта величина мне потребуется в метрах и в дюймах.
Получаем что-то вроде
strValue = getValue();
mValue = parseFloat(strValue);
inValue = mValue*0.0254;Язык абстрактный, функции — выдуманные, просто для примера.
Венгерская нотация, префикс обозначает либо тип данных, либо единицу измерения — смотря что мне нужно.
Разумеется, всё упирается в потребность. Очень-очень редко она возникает.
А приписывать префиксы повально каждой переменной — это дурацкая идея, против которой, ЕМНИП, выступал сам автор венгерской нотации.
Как я понял, у dimonoid python, но он имел в виду нечто иное…
стоило бы завернуть это дело в класс с методами as_str(), as_float(), as_inch()
Ради десятка промежуточных значений в одной процедуре?
Вообще говоря, с подобной потребностью я сталкивался только в расчётах по физике, трансформатор считать, или орбиты спутников. Причём, сугубо для локальных переменных в функциях, представляющих какую-нибудь километровую формулу из предметной области…
dimonoid в python просто слишком увлёкся новым для себя подходом к именованию. Бывает на определённом этапе самообразования.
Ради десятка промежуточных значений в одной процедуре?
Почему бы и нет? +1 к понятности кода, -1 к вероятности ошибиться. Нельзя, даже если очень хочется, сделать глобальную переиспользуемую в нескольких местах временную переменную — бесценно. ;)
+1 к понятности кода
И к накладным расходам на вызов методов.
сделать глобальную
Зачем?
+1 к понятности кода
И к накладным расходам на вызов методов.
Преждевременная оптимизация это называется ;)
сделать глобальную
Зачем?
Дык,
Ну, переменные типа temp я могу много раз использовать в программе в разных местах с разными типами. Зачем засорять память?
И проблем не вызывают, нужно только в названии переменных писать с чем работаешь в каждый момент времени, чтобы не забыть.
Шел 2018.
Я потому-то и решил попробовать по-другому, что видел множество примеров неудачного погружения через вёрстку.
Здесь, пожалуй, кроме первоначальной заинтересованности, стоит учитывать темперамент человека, усидчивость, склонность к тому или иному образу мышления. Я, к сожалению, не большой мастер в этом, поэтому буду пробовать так, как описал.
Хотя любые советы, само собой, приветствуются!
Так вот, я представил, что мне надо ЭТО изучить и испугался. Я уже не молод, конечно, и в мозги информация лезет туго. Но я-то хоть представление о програмировании имею…
В общем-то, цель этой статьи, как и всего будущего цикла (надеюсь, возможность будет), опробовать описанный метод, зафиксировать все грабли, попавшиеся на пути, и рассказать всё это коллегам, чтоб помочь им, внезапно очутившимся в похожей ситуации, своим опытом, каким бы он по итогу ни оказался.
Но мы начали с HTML и CSS. Так как у не просветлённых мышление как у обычных пользователей. Им нужно понять как делаются формочки, менюшки, иконочки и тд. что бы интерес не пропадал, а дaлее переходить к JS (уже объясняет как работает та ли иная кнопочка, почему двигает тот или иной объект) (ну и на последок Ajax и тд мелкие технологии). Этого было достаточно для того что бы она начала свою карьеру Джуниром в front. Сейчас она на этапе изучения PHP (так как в компании используем в качестве back). Ну и для закрепления Mysql (postgre, там от ситуации). И под конец пару книг по Архитектуре, паттеранам и тд.
Это написал просто Вам на скорую руку (обобщённо).
В моей практики это 4-й человек. И только у неё получилось!))) Первые 3 сдались! (мотивация).
Этого было достаточно для того что бы она начала свою карьеру Джуниром в front. Сейчас она на этапе изучения PHP (так как в компании используем в качестве back).
А ведь могла картины писать или музыку играть.
Но всё же всем бы советовал поступать в Вуз. Так как не стоит недооценивать силу образования (имею ввиду от самообразования и конечно же уровень самого вуза).
Насчёт старта с вёрстки многие пишут, и я ничего против этого метода не имею — он логичен. Вчера статью друг прочитал, а сегодня по дороге на рыбалку обсуждали с ним мой подход. Вот он тоже за старт с вёрстки.
Но у меня есть маленькая личная статистика, которая натолкнула на мысль попробовать по-другому, и вы сейчас эту статистику лишний раз подтвердили. Объясню о чём я: на моей памяти процент людей, пытавшихся войти в программирование через вёрстку и сдавшихся, в разы превышает процент людей, пытавшихся войти в программирование через непосредственно программирование.
Я говорю о людях заинтересованных (в обоих случаях).
Из троих профессиональных программистов, ехавших сегодня на рыбалку, двое начинали с консольных QBasic/Pascal/C, и один — с вёрстки. Кстати, в числе начинавших с QBasic/Pascal/C — девушка.
Поэтому возникли сомнения и предположение, что мнение о простоте входа в программирование через вёрстку, слабо коррелирует с реальностью.
Ну вот и проверим!)
А то я конечно одобряю и то, и другое, но в текущей ситуации — «а так я хоть понимать тебя буду» — Кормен может пригодится только если автор — спортивный программист, и диалоги там получатся примерно такие:
— Дорогая, на контесте такая-то задача была, дак я затолкал жадность за квадрат, а доказать не могу
— Ну вот же, по индукции…
Не думаю, что лямбды и предикаты ей в этом помогут.
или подкинул книжку Haskell From the First Principles
Взгугланул я отзывы…
TL;DR: «книга очень плохая» (С)
Кому верить-то? :)
Искуством компиляции
Очень вредное оно
Пропали менструацмм
Мой милёнок сущий хакер
Я его послала нахер
Захотел он, его мать
Кое что во мне взломать!
Мой милёночек меня
Вчера разархивировал
Дизассемблером меня
Дефлорасемблировал
Мы с милёнком занимались
Да наладкою сети
Заголовок чтоб пакета
Мог в мой роутер войти
Мой миленок по ночам
Что-то програмирует
Докинг-станцию мою
Напрочь игнорирует
Два чая этому господину. Промышленной разработкой девушка все равно заниматься не будет, по-этому все эти ваши реакты с постгрескулями ей как зайцу тормоз — просто бесполезный ворох бесполезных сведений. А вот сопутствующий матан в виде лямбда калькулуса, теории типов и прочих хороших, годных вещей — самое то, чтобы поддержать интересный разговор в культурном обществе. Ну и вообще повышает общий уровень грамотности человека, кругозор расширяет, в отличии от.
самое то, чтобы поддержать интересный разговор в культурном обществе.
ORLY? Культурное общество, которое в теме, наелось этими разговорами на скрамах. А которые не в теме — не поймут…
Культурное общество, которое в теме, наелось этими разговорами на скрамах.
Покажите-ка мне, где на скрамах обсуждают зависимые типы, теоркат, матлог, топологию. Ну или хотя бы задачки на лямбда-исчисление, кек. А вот как раз постгрескули и виртуалдомы обсуждаются вполне, так что это как раз аргумент за то, чтобы все это набившее оскомину не изучать.
И боюсь, то общество, которое вы упомянули, не относится без дополнительных уточнений к культурному в рамках нашего дискурса.
Мне тоже показалось, что у автора раздвоение личности… Сначала ему не нравились курсы с целью создать сайт, а в итоге он решил обучать на примере создания сайта. Только по сравнению с обычными курсами для новичков, усложнил всё на пару порядков.
Тема, конечно, сложная… Но одно точно: нужен короткий цикл "обучение" -> "программирование" -> "результат". Ну, какой-нибудь консольный конвертер из миллилитров в граммы и обратно для разных кулинарных субстанций, а не вот это вот всё...
Как по мне, так начинать надо было с обратной стороны. Сначала html, css, js. Потом typescript, который плавно подвел бы человека к статической типизации. Да и после объектов в js понять все эти json было бы намного проще. Ну а потом можно Go. Единственное, PostgreSQL это очень жирно для новичка. Можно начать с MySQL. Для начальной цели она подходит, а изучить можно недели за 2, занимаясь по 10 минут в день.
Для изучения основ лучше все же брать задачу, которую вы сами могли бы полностью реализовать за 10-15 минут (не преувеличение).
(был небольшой опыт такого обучения — по итогу можно сказать успешный (программистом не стала, но стала понимать меня)).
Как думаете, возможно ли на описанных мною этапах, практиковать ваш метод?
Идея завершаемых за 10-15 минут задач мне очень нравится. Это «детский» подход, который, как мне кажется, на взрослого человека может подействовать с не меньшим успехом.
Главное — постараться подобрать действительно интересные задания, желательно применимые в конечном проекте.
На самом деле, вопрос в том что девушка больше хочет сама «просто научиться понимать все эти штуки» или научиться «думать как программист».
Простите, но ваша программа больше похожа на обучение технологиям, чем чистому программированию.
Я бы начал с основ — расчета простейшей математики чтобы изучить ввод-вывод само понятие переменной, константы.
Потом наверное циклы, условные операторы, булевая логика.
И вот только после этого можно браться за клиент-сервер, базы данных и фронтенд.
Есть мнение, что математика программисту тоже не нужна. Вместе с историей, философией и прочим высшим образованием.
Можно долго спорить на эту тему. Но для начала стоит понять, кого вы подразумеваете под программистом?
Например человек разрабатывающий ПО для томографов, где требуется реализация преобразования Радона, это программист? Нужна ли ему математика?
А например разработчики игровых движков, они программисты? Нужна ли им математика и физика?
В общем случае вообще не корректно говорить об математике. Нужно говорить о предметной области, а она везде разная.
Это шутка была, не совсем веселая. Программисты они всякие бывают, про 1Сников забыли упомянуть.
КМК, нужно иметь понимание и в базовых областях (та же математика), и в предметной. И в нескольких смежных. А то может получиться совсем узконаправленный специалист, умеющий решить ровно одну задачу по ровно одной схеме.
А вот программисты приложений, по мнению ОКЗ, «создают и поддерживают программный код, указанный в технических инструкциях и спецификациях для программных приложений и операционных систем». Вот дали ему формулу — он кодит.
Зачем вообще начинать с клиент-серверной архитектуры?
это либо курсы по веб-программированию (PHP, JS, Python, etc)Курсы по Python есть не только по Веб-программированию.
Посмотрите вот этот курс для начинающих — www.coursera.org/learn/interactive-python-1 (и его вторую часть), где с нуля учат делать простые игры на Python прямо в браузере (у них есть интерпретатор Python на JavaScript), адаптируйте его для Вашей девушки и будет и интересно и познавательно!
Спасибо, обязательно посмотрю!
Разработка сервера и клиента в данном случае не является первоцелью, на текущий момент просто это оказалось тем, что её заинтересовало (как конечный продукт), в отличие от попытки разработать игру. Думаю, здесь нужно отталкиваться именно от этого — от интересов ученика.
Мне кажется, начинать объяснения лучше именно с алгоритмов (на примере тех же рецептов — готовый простейший алгоритм), и выбрать как раз язык с динамической типизацией, он не требует запоминать и понимать всякие int, float, string, bool, их отличия, можно сразу перейти к основам алгоритмической логики. На типах и прочей теории вы можете сразу завязнуть и потерять интерес «клиента». Я понимаю желание сделать систему «кошерной», современной и т.д., но как уже выше неоднократно отметили, это не для начинающих. Голова взорвется.
Мне кажется, начинать объяснения лучше именно с алгоритмов (на примере тех же рецептов — готовый простейший алгоритм), и выбрать как раз язык с динамической типизацией, он не требует запоминать и понимать всякие int, float, string, bool, их отличия, можно сразу перейти к основам алгоритмической логики
Есть какое-то глобальное непонимание индустрии по этому поводу. Динамические языки не проще, а, в общем, сложнее статических, т.к. предъявляют гораздо более высокие требования к дисциплине и квалификации программиста. Я бы вообще человека, который не умеет нормально в статику, то динамики бы допускать не стал.
Я же не предлагаю ей сразу в энтерпрайз с этими знаниями, это лишь первый шаг обучения. В том же Scratch, когда котика по экрану гоняешь, ты не пишешь у каждой команды тип переменной, мол, пройди int шагов и скажи string. После понимания алгоритмов на следующем этапе можно перейти глубже и детальнее. Заблуждение в том, чтобы девушку, у которой ноль знаний, грузить сразу всем. Это как первокласснику, не знающему буквы, начинать объяснять причастные и деепричастные обороты и запятые на письме, а то он же неграмотный будет. Я согласна, что типизация — обязательная необходимая часть знаний, но если она реально заинтересуется и захочет писать код за деньги, а не только понимать своегл парня, то на усвоенном каркасе уже будет понятнее, что такое компилятор и как он работает, почему важно указывать тип переменной, как это влияет и т. д. Тупо зазубренные int, float, bool, без понимания сути, ничего не прибавят к качеству кода.
Scratch!
Читал как-то про него на Хабре. Мне кажется, что это очень крутая штука для малышей, но не совсем подходящая в моём случае.
И здесь претензий не к инструменту, а ко мне — не думаю, что я бы смог придумать что-то, что позволило бы заинтересовать мою девушку в Scratch!
Я попробовал припомнить, сколько своих девушек я обучил программированию, получилось пять. Скретч — это ваш выбор. Пусть сделает игру, например пинг-понг или Марио. Другой вариант — Lego Mindstorms, пусть заставит работа пройти квадратную траекторию с помощью их labview-подобного языка.
После пары месяцев таких задачек покажите ей код простой веб страницы и заставьте написать html. Дайте понять, что все сайты в мире состоят из html-прямоугольников. Покажите как с помощью css можно закруглить уголки и сделать цвета. Покажите как с помощью js можно делать анимашки или калькулятор.
Переход к пониманию того, зачем вообще нужен что-то считающий сервер — сложный момент. Проще всего принести несколько компов/мобилок и запрограммировать кнопку «я был тут» на php, на которую с нескольких компов и нажимать — а она пусть увеличивает счётчик (хранение в plain-файле, никаких баз данных).
Каждый шаг должен будить в ученике радость понимания чего-то полностью, радость создания понятного осязаемого результата, вместе с тем рождая один-два вопроса. В вашем случае создать последовательность таких шагов будет невероятно сложно.
Девушки существа более прагматичные, а тут речь о том, чтобы заниматься чем-то а) творческим (что как правило женщинам труднее), б) непонятно зачем.
Есть вероятность, что дальше «Hello, world!» вы не уйдете. Хотя я могу конечно быть не прав — интересно как всё будет дальше. Ни в коем случае не хочу обидеть прекрасную половину человечества, просто наблюдения/личная статистика.
Девушки, кроме прагматичности, ещё и не склонны сдаваться. Вообще не правильно, наверное, вот так вот гендерно кого-то определять, но, по моим наблюдениям, всё же девушки чаще доводят начатое до конца, даже если это перестаёт им нравится.
Надеюсь, в данном случае это тоже сработает.
Если в конце есть четко выраженная цель на уровне «иметь» — то да.
«Научиться программировать» — плохая цель по формулировке — отсутствуют критерии достижения.
«Вообще не правильно, наверное, вот так вот гендерно кого-то определять,»
А… ну да — тут я сильно извиняюсь. Я как это… слегка «биологизатор». )))
На этот, казалось бы, абсолютно справедливый вопрос я получил не менее справедливый ответ:
— Ты всё равно постоянно говоришь о программировании, а так я хоть понимать тебя буду.
Тут есть проблема, как мне кажется. Парень тащит работу домой (её все тащат, но здесь слишком сильно, иначе не было бы такого предложения), не умеет нормально общаться с любимым человеком, а этот человек так сильно любит, что готов себя переформатировать только ради того, чтобы быть ближе к автору, а автор, вместо того, чтобы оценить порыв и перестать тащить программирование домой, решил устроить из этого реалити-шоу.
Если говорить про изучение, то почему бы и нет, Go действительно хороший инструмент для этого, только я, как человек, 4 года преподающий программирование в школе помимо основной работы, сразу бы посоветовал забыть про все эти REST, PostgreSQL, Vue.JS и пр., потому что даже на освоение процедурного программирования (без указателей и массивов — только ветвление, циклы и консольный ввод/вывод) уйдёт около года.
И тут автору следует себя спросить — он всерьёз хочет сделать full-stack девелопера из девушки? Хорошо объяснить общую логику работы всего этого, фундаментальные закономерности (по сути всё сводится к этому пресловутому процедурному программированию), но не нужно, закусив удила, сразу бросаться в омут, а вести дело следует таким образом, чтобы девушка могла прекратить сохранив лицо и ни в коем случае не доводить до скрытого раздражения и пр. Устраивать реалити-шоу на хабре — откровенно дурная затея. Надеюсь, что она про это не в курсе.
Позволю себе лишь добавить маленькую ремарку.
Многие вещи, на мой взгляд, зависят от степени доверия. Скажем, публиковать чью-то историю (это ведь не только моя история), не поставив в известность другого участника этой истории — это, на мой взгляд, противоречит всем нормам морали. Поэтому нет, она в курсе.
Из уровня доверительности отношений между людьми так же выстраиваются их взаимоотношения уровня учитель-ученик. В школе, объясняя ветвления и циклы нескольким десяткам незаинтересованных учеников, вы можете потратить и год, да. Почему? Мне кажется, потому что ученики Вам не доверяют. Не доверяют не лично Вам как человеку, Вы здесь вообще не при чём. Речь идёт о недоверии социальной группы «школьники» к социальной группе «Школьные преподаватели», и речь о доверии своего личного времени — им не интересно в циклы и ветвление, так же как не интересно в Основы Православия и Кубановедение.
В моём случае человек целенаправленно доверил личное время мне. Думаю, возможно ожидать чуть более быстрого результата.
И всё-таки спасибо за глубокий комментарий. Этим, пожалуй, и ценна возможность дискуссии, что можно копнуть совсем в другую сторону, например, в личность автора, и это действительно будет интересно!
На самом деле хорошо, чтобы она хотя бы в общих чертах понимала специфику вашей работы, чем вы там занимаетесь, какие там бывают проблемы. Это, кстати, можно рассказать даже без обучения программированию (прекрасный пример — серия рассказов Карела Чапека «как это делается»). Потому что в парах с хорошими глубокими отношениями и в семьях партнёры интересуются «как дела на работе» и лучше, если это будет не пустой разговор, а возможность поделиться успехами/проблемами, услышать мнение со стороны, получить совет. Поэтому, мне кажется, что вам следует также сделать симметричный шаг по отношению к ней. И вообще — счастья и удачи.
Такие уж у нас отношения, что я в своё время изучал с ней аспекты её специальности, а теперь вот она решила.
В каком-то смысле это, наверное, уже — счастье и удача!
Спасибо! Не могу не ответить взаимностью: Вам тоже желаю счастья и удачи!
А почему бы и нет? Пол есть некая характеристика объекта, почему бы не строить модели по влиянию этой характеристики на… всё?
«Продумывать алгоритм решения задачи — совсем не то же самое, что сочинять рассказ.». Попытался мысленно сравнить ). Программирование труднее — рассказ нельзя написать неправильно — он может быть хорошим, может быть плохим, но критерий работоспособности к нему неприменим.
Ну кстати можно посмотреть свою статистику — сколько вокруг вас женщин-программистов или писателей.
А где/как почитать ваши статьи/рассказы? Интересно очень!
Я не писал на Delphi с конца нулевых, интересно сейчас посмотреть, что и как там.
Но всё же, мне кажется, садить новичка в эти самые отличные IDE стоит, только если его цель — стать профессиональным программистом.
К тому же, дома у нас не Windows.
Однако, в будущем, если она всё-таки не бросит меня (как педагога, конечно же), можно попробовать, спасибо!
Сажать за нормальную IDE стоит хотя бы потому, что с ними порог вхождения намного ниже. Гораздо понятнее, когда ты берёшь и кидаешь мышкой кнопку на форму, а не описываешь вручную всю разметку страницы. В этом плане даже QtCreator будет проще, чем html+css+js.
Я слышал про некий кроссплатформенный Kilyx, родственник Delphi..
Делфи сейчас сама компилирует (кроме Win32/Win64, само собой) под Android, iOS, MacOS, Linux, работает с вебом (с помощью сторонних компонент).
Всё что я описал — это лишь эксперимент. Надо понимать, что для его успешности инициатива должна исходить от ученика, а поиском конечного продукта, как цели, должен управлять учитель. В конечном счёте наставником должно быть предложено именно то решение, которое действительно заинтересует падавана.
Надеюсь, что я нашёл то самое решение. Но это не точно.
Я как раз-таки и писал о том, что не хочу обучать свою девушку в формате экспресс-курса, поскольку, как показывает опыт, в том числе, как понимаю, и ваш, — ничего это не даст.
Да, предстоит долгая и усердная работа, к которой мы, вроде бы, готовы.
Согласен на счёт бессмысленности споров о порядке обучения в том плане, что это, пожалуй вопрос большого количества факторов, в том числе личностных.
И всё же, если Вам не сложно, дайте ссылочку на на план обучения — возможно, это заинтересует не меня одного.
Спасибо! Постараюсь учесть то, что не было учтено изначально!
Жена, например, прошла собеседование в долине и работает Sr. Software Engineer не имея ни дня работы до этого. Процесс был долгий и тяжелый. Но мы начинали не просто с нуля, а с отрицательного уровня.
прошла собеседование в долине
работает Sr. Software Engineer
не имея ни дня работы до этого
Обидно становится, когда после 7 лет разработки ты все еще не чувствуешь себя Sr. Software Engineer, а тут…
Учили Java, начинали с JavaRush. Но ваша программа мне видится огромной и непосильной. Судя по себе, я бы это осилила минимум за год (а то и два) усердной работы и чудовищной мотивации. Если действительно нацеливаться на хорошие знания. Это при том, что я по образованию учитель английского и с языком проблем нет :)
Такое не каждому крепкому джуниору под силу, вот так вот, сразу…
Но тема интересная…
Я тоже дочь (падчерицу) к айти приучаю…
Еще когда в школе с ней уроки по математике учил, заметил — зачатки абстрактного мышления и логики есть… Надо только развить…
Прошли с ней курс на ютюбе по верстке и css…
Когда работу вэб-форм объяснял, она сообразила, как ей пароль от аккаунта вкантактов у ее парня увести-)
Перед освоением sass хотел начальный курс по js пройти, чтобы сначала поняла, что такое переменные, if-then, while, for и т.п.
Но… интерес внезапно прекратился…
Теперь ломаю голову, как его возобновить…
Пока кроме «ремня» ничего в голову не приходит-)
Надеюсь, жисть поможет убедить-)
А то я будто фильм с открытой концовкой досмотрел.
Возможно интерес угас не из-за вашего стиля преподавания, а просто от того, что сейчас её волнуют более интересные вещи, раз уж Вы заговорили о парне)
В конце концов, главное — чтоб человек, особенно ребёнок, был счастлив!
Очень дельная вещь как для начинающих, так и для не совсем начинающих, так и для тех кто хочет понимать о чем речь пусть и не собирается идти в эту профессию.
Ну с русскими терминами в этой области швах, я согласна. Но вы говорите, что англоязычных аналогов вовсе нет? Если вы считаете, что термины «строгая» и «сильная типизация» вообще некорректно употреблять, то к чему ваш изначальный тезис?
А может заходите в наш чатик в телеграме про языки и компиляторы, там много уважаемых товарищей и можно подискутировать.
Пирс, кстати, есть и на русском, и там действительно ничего нет про сильную и строгую типизацию. Но эти термины вполне устоялись, если не в контексте систем типов (в более научном смысле, как у Пирса), то по крайней мере на «бытовом» уровне, когда нужно охарактеризовать языки или сравнить. Поэтому я до сих пор не понимаю, почему вы именно их предлагаете для соответствующих англоязычных терминов. Я нигде не встречала, чтобы их так использовали, и кажется, что понимают под этим уже совсем другое. Если форсить именно эти смыслы, то получится ещё больше путаницы.
Окей, как вы называете безопасность
У Пирса безопасность употребляется как синоним soundness. Про инварианты лучше утром подумаю, а то ещё не засну :D
Раз уж мы книжками кидаемся, то вот довольно современный и всеобъемлющий талмуд — Michael Scott, Programming Language Pragmatics. Там легко можно найти про strong typing, причём в том же примерно смысле, в каком википедия пишет, и в каком все привыкли понимать. Это с такой добротной инженерной (или практической) точки зрения на языки, без углубления в теории типов. Так что этот термин вполне употребляется и его перевод на русский уже занят.
Строгая. Сильная и строгая типизация — немного разные вещи.
Сильная и строгая — это действительно одно и то же, strong typing. Это, условно говоря, когда нет неявных кастов (а слабая, с-но, когда таковые есть). Например, в js слабая динамическая типизация, т.к. 1+'1', а в ts — слабая статическая типизация, т.к. тот же терм валиден, хоть и имеет конкретный тип. В c# — сильная статическая, python — сильная динамическая, с++ — слабая статическая, хаскель — очевидно сильная статическая, лиспы — в основном сильная динамическая (зависит от диалекта офк, scheme-derived обычно сильные динамические, всякое интерпретируемое говнецо — бывает слабое динамическое) и т.д…
Формлаьно строгим этот термин не является, конечно же.
Э, ну. В любом языке с сабтайпингом у вас есть неявные апкасты, при этом, очевидно, некоторые из этих языков вполне себе safe.
По-этому я и указал, что понятие не является формально строгим. Это такое понятие на пальцах — если язык позволяет в рантайме складывать жирафов с яблоками, значит, типизация слабая. А если нет — то сильная.
Я там выше писал, что надо как-то разделять safety (которое progress и preservation) и expressive power (которых тоже минимум джве).
Это, конечно, тоже разные вещи, но обычно под сильной/слабой типизацией все же по умолчанию понимают штуку вообще к статическим типам не относящуюся, иначе, согласитесь, бессмысленно было бы рассуждать о том, сильная или слабая типизация в динамических языках. Она там с точки зрения статики везде, очевидно, одинаковая (т.е. никакая).
А в случае safety и expressive power,, кажется, так и говорят — "типобезопасность" и "выразительность/мощность".
И, опять же, не думаю что можно формально строго определить понятие выразительности.
Это как раз ровно то, что safety должно предотвращать
Ну вот если у вас есть такой аналог safety в рантайме (то есть чекер терм пропустит, но потом рантайм ругнется, что вы яблоки пытаетесь использовать вместо жирафов), то это, условно говоря, и есть strong typing. Сишка вам не ругнется — с ее точки зрения все будет валидно.
Думаю, что поспособствовало этому изучение в школе QBasic и Pascal, простых, понятных и дающих базовые понимания.Ok! ИМХО на стандартном Паскале и надо учить. И брать задачи на 10 мин.:
Свою первую программу (не считая того, что мы писали на уроках) я написал для младшего брата, когда тот стал учить таблицу умножения: ввод диапазона чисел, случайный вывод двух из них брату с предложением ввести их произведение, проверка и так далее по кругу.
Еще: поиск счастливых билетов, 8 ферзей, жизнь, простые методы сортировки и т.д. Описание ЯП Паскаль (Вирта) можно прочесть за день, понять и попробовать за 1-4 недели.
ИМХО цель будет достигнута:
Ты всё равно постоянно говоришь о программировании, а так я хоть понимать тебя буду.Потом могут возникнуть другие цели — тогда и ЯП можно сменить, и технологии изучить.
Все эти ферзи и сортировки — это из области абстрактного искусства с нулевой прагматичностью для человека извне. Тестилка для брата — куда лучший пример, тут цель видна сразу.
Поначалу писать надо игры, вирусы, домашние странички, секундомеры для мобилки, анимации, генераторы гороскопов, текстовые квесты, интерактивные мультики на скретче, терменвоксы на ардуине, роботов на майндстормс, коптер чтобы взлетел, полетел вперед и вернулся… такие штуки.
Ух. Тригернуло меня на ферзей, десять лет программирую и до сих пор мне абсолютно неинтересно, как их расставить.
На каких задачах предлагаете изучать рекурсию?
На каких задачах предлагаете изучать рекурсию?
На математических. Уравнения, неподвижные точки, вот это вот все.
>Девушка хочет понять программирование, а не математику
Ложное противопоставление.
Хотите сказать, что программирование=математика?
А здесь, нпр., на вопрос «Роль математики для информатики в школе высокая?» почти 36% ответили «нет».
Можно привести и другие примеры, где математику и CS противопоставляют. ИМХО математика и CS пересекаются, но не совпадают полностью.
CS — подмножество математики.Кое-что из CS не входит в математику. Нпр., файл не мат. объект, человеческий фактор в GUI, эвристические алгоритмы и т.д.
в школе что на уроках математики, что на уроках информатики преподают какую-то ерунду.Пока в мире не придумали ничего лучше.
Я бы сказал, что это и в CS не входит.Файл во многих ЯП, ЯП часть CS. Уже в начале 90х гг. (а м.б. и раньше) вводная книга Inside Macintosh начиналась описанием метафоры рабочего стола, где подчеркивалась большая роль учета человеческого фактора для удачной разработки GUI. И нашумевшая книга «Софт — отстой! И что с этим делать?» во многом посвящена этому фактору. Еще можно посмотреть статью Human–computer interaction (HCI) и т.д. Что касается эвристических алгоритмов — тут в первую очередь антиматематичный бездоказательный подход, умышленно возведенный в статус принципа.
Девушка хочет понять программирование, а не математику и физику.
А в программировании все то же самое, рекурсивная функция — это неподвижная точка.
И никакого другого понимания в природе не существует. Либо на пальцах, и объяснять тут вовсе ничего не надо (рекурсивный вызов ничем не отличается по факту от обычного, что такое обычный вызов человеку же понятно? значит, понятно, и что такое рекурсивный), либо неподвижная точка.
И никакого другого понимания в природе не существует.Существуют более простые для девушек формулировки — см. Вики с картинками:
Рекурсия — определение, описание, изображение какого-либо объекта или процесса внутри самого этого объекта или процесса, то есть ситуация, когда объект является частью самого себя.
(Картинки помогут понять это определение!)
Не всякой девушке интересно знать, что такое функция в математике, а ученик начальной школы (где уроки информатики) про мат. функцию узнает только в средней школе. Можно не пугать девушек (и первоклассников) неподвижными точками — выше многие уже отметили, что на старте нужно избегать слишком глубоких абстракций и обобщений.
Конечно, возможны исключения. Если, нпр., девушка — учитель математики, то самыми понятными для нее будут формулировки на языке математики.
Не всякой девушке интересно знать, что такое функция в математике
Так вы и дали определение как в математике, но только плохое. Зачем оно нужно? Зачем тогда в принципе объяснять, что такое рекурсия, если, еще раз, это не является вне теории каким-то отдельным концептом и рекурсивные вызовы работают совершенно аналогично нерекурсивным? Объяснили про обычные вызовы => рекурсия изучена.
Так вы и дали определение как в математике, но только плохое.Не я дал, а Википедия. Но и она сама определения не дает, а только пересказывает «авторитетные источники». Что оно плохое -эксперты вики так похоже не считают. ИМХО оно достаточное с рекурсивными картинками, и больше на старте не нужно. И дело не в том, как работают рекурсивные вызовы, а дело в работе мозгов ученика (в его психологии), который узнает о важном подходе решения ряда типовых задач через рекурсию. ИМХО в вики понимание этого подхода сделано максимально простым — для старта это самое главное.
Не я дал, а Википедия.
Именно вы выбрали определение из википедии, а не какое-то другое.
И дело не в том, как работают рекурсивные вызовы, а дело в работе мозгов ученика (в его психологии), который узнает о важном подходе решения ряда типовых задач через рекурсию.
Так а чем рекурсивный подход отличается от нерекурсивного? Если вы умеете в нерекурсивный, то и в рекурсивный умеете автоматически. Ничего дополнительно вам изучать не требуется.
Ничего дополнительно вам изучать не требуется.Почему тогда большинство учебников особо разбирают рекурсию?
Почему тогда большинство учебников особо разбирают рекурсию?
Преподавательский каргокульт, пошедший, видимо, от тех языков, где рекурсию разбирать действительно смысл есть (вроде того же хаскеля) и от теории алгоритмов (то есть, опять же, математика).
Как вы посчитали "большинство"?
Я не считал. Надо еще определиться, что мы считаем учебником. Они ведь разные бывают. Есть scratch и javascript для детей, есть SICP и алгоритмы Кормена, а еще есть куча онлайн площадок для обучения. Что насчет самодельных методичек, которые делают преподаватели учебных заведений ради своих целей?
что мы считаем учебником
Учебником нужно считать то, что рекомендовало МО для обучению предмета «Информатика» в общеобразовательной школе. Это то, что входит в обязательную программу.
Мне стало любопытно и я нашел "Методическое письмо об особенностях преподавания информатики и ИКТ в 2017/2018 учебном году".
Учебники из списка рекомендаций полистать сейчас не получится, но в самом письме есть абзац:
Необходимо обратить внимание, что в контрольно-измерительные материалы единого государственного экзамена внесены задания, предполагающие знание рекурсии как метода структурирования информации. Традиционно в школе данная тема рассматривалась в курсе математики.
Так что ответ на вопрос "Почему тогда большинство учебников особо разбирают рекурсию?" будет
"потому что это будет на ЕГЭ".
каких-то априорных знаний математики там особо не нужно (кромеНужна прежде всего мат.культура определенного уровня, понимание «языка математики». Согласен, что ученик матшколы осилит эту книгу, т.к. ему понятнее 1 формула, вместо десятков обычных слов. А вот выпускник обычной школы с интересами только в гуманитарных областях через год после окончания на вопрос чему равна длина окружности ответит «пи эр квадрат»…
Средний человек смотрит на ферзей и думает «зачем это вообще надо? да и шахматы я не люблю, а если бы любил, там такая ситуация никогда бы и не встретилась». Смотрит на ханойские башни и думает «а зачем они перекладывают только по одному кольцу, не проще просто снять все кольца, положить на землю и надеть их на ту башню, на которой они должны быть?»
Я когда обучал студентов (и особенно школьников) сортировкам, регулярно сталкивался с непониманием того, почему за один раз можно брать лишь два элемента массива и делать лишь одно сравнение. Ограничения должны как-то объясняться, иначе здравомыслящий человек будет чувствовать, что играет в какую-то неинтересную игру с искусственными правилами.
иначе здравомыслящий человек будет чувствовать, что играет в какую-то неинтересную игру с искусственными правилами.ИМХО про все игры можно сказать, что у них искусственные правила. Не только про развлекательные, но и, нпр., про биржевую игру. Так, нпр., Генри Форд возмущается в своей книге курсами валют: что бы вы сказали, если бы сегодняшний метр был равен 0.98 метра вчерашнего?
И выше Вы сказали:
Поначалу писать надо игры
Много людей играют в очень простые игры типа пасьянса FreeCell не спрашивая:
«зачем это вообще надо?» Конечно, м.б. начинающему хотелось бы написать сложную и более интересную игру, но надо выбирать посильные задачи.
почему за один раз можно брать лишь два элемента массива и делать лишь одно сравнениеПусть попробует взять больше элементов зараз, сделать больше сравнений, доказать, что работает правильно и быстрее :)
Пусть попробует взять больше элементов зараз, сделать больше сравнений, доказать, что работает правильно и быстрее :)
Я в этом случае притаскиваю на лекцию пару десятков карточек с числами и предлагаю их отсортировать, комментируя каждый свой шаг максимально подробно. И человек понимает, что тоже действует по некоторому алгоритму, обычно — сортирует вставками.
p.s. принимать экзамены по карточкам было особенно прекрасно. Садишь студента и говоришь ему — ты quicksort, сортируй вот эту колоду карт и рассказывай мне, как ты это делаешь.
Quick-sort with Hungarian (Küküllőmenti legényes) folk dance
Все эти ферзи и сортировки — это из области абстрактного искусства с нулевой прагматичностью для человека извне.ИМХО никакой абстрактности — все предельно конкретно и прагматично. Счастсливые билеты и ферзи — игры-головоломки; Жизнь — игра. Сортировка расходов за месяц полезна для домашней бухгалтерии, а сортировка названий полезна для сборника кулинарных рецептов.
Поначалу писать надо игры
Я и предлагаю конкретные игры, но на 10 мин., а не на несколько лет.
вирусы
ИМХО слишком специфично. И какая из них прагматика? :)
Попробуйте с приложений под мобильный. Врядли для рецептов девушка будет таскать ноут на кухню. На первом этапе можно делать без бэка. Порисуйте вместе экраны, переходы между экранами, составьте т.з. того что она хотела бы увидеть. А дальше по желанию или на нативном(kotlin, java / swift) или нет(python(kivy), react-native, dart(flutter)). Список рецептов можно усложнять постепенно и на каждом этапе видеть результат.
На Go идеально обучать основам. Он же квинтесенция C и Pascal, которые в мою молодость были основой для воспитания поросли. Можно и примитивные типы, и примитивные структуры, и базовые алгоритмы быстро попробовать, и посмотреть, как они в ассемблерный код превращаются.
— Я готова! Готова учиться программированию! Давай!
Девушка, похоже уже освоила Inversion of control :)
На мой взгляд, если ваш подопечный совсем далек от мира программирования, начать стоит с самых базовых вещей: из чего строится любая программа (неважно на чем она написана), затем методы взаимодействия между базовыми кирпичиками программы, а уже затем плавно переходить к делению на фронтэнд и бэкэнд с попутным объяснением почему в одном случае мы имеем дело с одним стеком технологий, а в другом с другим. Приведите ее на кухню и предложите написать формальный алгоритм приготовления еды.
По моему мнению вы даете ей растущее дерево и кучу швейцарских ножей, говоря: «дорогая, сегодня мы из этого дерева и вон той кучи инструментов будем делать звездолет», не показывая в сущности что значит и для чего применяется каждый из ножей.
Я писал эту статью для коллег, а не для учеников, и поэтому использовать подобную декомпозицию задачи, ведь иначе кому на хабре было бы интересно это читать, однако в процессе обучения, конечно, необходимо разбивать описанные мною задачи на более мелкие, о чём я и планирую рассказать в следующих статьях.
Я клоню к тому, что начать стоит с самых-самых азов. Никто не мешает вам объяснять принципы алгоритмирования сразу показывая как это применяется, но на мой взгляд получится каша в голове, так как новые знания должны накладываться на базу, которая будет принята, осознана и переварена. Но в любом случае буду с интересом следить за вашими успехами.
Думаю, что общую для разных этапов информацию, правильней будет давать на этапе либо требующем этой информации, либо являющимся наиболее удобным.
В общем, где-то, думаю, придётся импровизировать. И пусть наши успехи и ошибки помогут другим!
Вчера открыл, прочитал, было много эмоций — закрыл и дал впечатлениям отстояться, теперь могу написать комментарий спокойно. По пунктам:
1) Можно считать за придирку, но ваша статья местами (в том числе по заголовку) выглядит так, словно это уже готовый и проверенный рецепт. Не надо так. Её будут открывать неискушённые люди, принимать за истину в последней инстанции, и пробовать. Вы в ответе за тот опыт, который они в конце концов получат.
2) Навскидку просуммируем то, что вы решили быстренько положить в ваше обучающее приложение:
- Разработку бэкенда на Go
- JavaScript + TypeScript (ну потому что учить только второму не выйдет)
- РСУБД
- Vue.JS
- HTML, CSS
Итого это пять полноценных глубоких курсов. Которые вы хотите запихнуть в разработку одного приложения. При этом результат своих действий человек увидит примерно по окончанию всего этого.
В общем, я считаю, что такая программа не подходит не только девушке, а вообще кому бы то ни было. В том числе даже человеку, который имеет опыт разработки. Чтобы не быть тем самым медведем из кустов, уточню, что я преподавал студентам вуза, а так же являюсь техлидом, обучающим своих разработчиков — поэтому мои предположения не взяты с потолка.
Ну, как обычно "критикуя — предлагай". Что-то и этого уже выше сказали:
1) Оптимально давать короткие задачки, которые дают быстрое обучение каким-то узким вещам и чувство удовлетворения студенту. Насчёт 15 минут — это вряд ли — но задачки на пару часов (то есть на вечер) — это хорошо. Хотя бы потому что даёт человеку ощущение того, что он чему-то научился и чувство пройденного этапа. Это важнее, чем кажется.
2) Не надо мешать в кучу огромное количество разных технологий. Мой опыт говорит о том, что обучать таки лучше с вёрстки, но если вам так не хочется — можно начинать с консольных программ или со сред, в которых можно накидать формочки с кнопочками. Или с микроэлектроники — мигать диодиками и все дела. И только когда какой-то этап более-менее уложится в голове — можно идти дальше. Иначе в голове будет каша из js/go/sql/etc.
3) Обучать тому, чего не знаешь — хорошая идея только на первый взгляд. По факту, наверняка окажется, что ты чему-то научил неправильно, или сидишь тупишь над простыми вещами часами. Что будет крайне негативным опытом для студента. Поэтому лучше обучать тому, что знаешь. Как ни странно, это очень полезно, поскольку даёт структурировать в голове свой опыт и узнать много всего, на что раньше не хватало времени или желания.
Кстати, даже ваше книгу рецептов на самом деле можно писать итеративно и с промежуточными результатами. Например:
1) Научиться HTML. Пускай напишет свою веб страничку с рецептами.
2) Научиться JS. Пускай сделает там менюшки, свистелки и перделки.
3) Научиться JS фреймворку. Пускай переделает на него.
4) Научиться какому-нибудь ЯП. Пускай хранит свои рецепты в JSON файликах и показывает. Пускай ЯП генерит странички полностью (никаких API).
5) Научиться СУБД. Пускай переложит данные из JSON файликов в таблички.
6) Сделать API и довести до "взрослого" приложения.
В результате получаем то же самое, но по возрастающей сложности и с промежуточными результатами.
З.Ы. не знаю, откуда взялось мнение о том, что, если человек не будет обучаться языку со статической типизацией в первую очередь, то произойдёт что-то непоправимое. Знаю много людей, которым обучение PHP никак не помешало потом писать на C или Java. В обучении есть одна основная задача — чтобы человек что-то написал, и ему понравилось. Если это произошло, то дальше всё будет хорошо. Если нет, то нет никакой разницы, чему именно вы его не научите.
Это прекрасно.
С какими-то тезисами я согласен абсолютно, с какими-то не согласен, но считаю их справедливыми, так в условиях недостатка контекста каждый волен интерпретировать ситуацию по-своему и по-своему заполнять этот недостаток. При этом, конечно, посвятить всех в этот самый контекст я не могу, потому как это скорее тема для ток-шоу о семейной жизни, нежели для Хабра.
В общем прочитав и проанализировав множество комментариев, я нашёл для себя несколько вопросов, которые раньше мне в голову не приходили, и нашёл на них ответы. Всё это не меняет саму концепцию, которую я предложил, но неплохо дополняет, во всяком случае теоретически.
Так что спасибо Вам и в Вашем лице всем, кто не просто не согласился, но и, «критикуя — предложил». Вы помоги!
У меня тоже хватает (успешного) опыта в обучении программированию, и я предлагаю максимально серьёзно отнестись к тому, что написали sotnikdv и jehy. Ключевые моменты — обучение потребует около года, много (4-5) часов почти каждый день, промежуточные результаты очень важны (так что задачи надо подбирать так, чтобы можно было увидеть результат хотя бы раз в пару дней) и для этого нужна очень сильная мотивация (нацеленность на получение профессии с последующей работой).
Что касается Вашего случая, то, на мой взгляд, Вы радостно бросились решать не ту проблему. Результат такого подхода, обычно, не радует никого. Я думаю, что обучаться нужно не Вашей девушке, а Вам. И обучаться вовсе не программированию, а умению излагать волнующие Вас рабочие проблемы дома своей девушке на человеческом языке, а не программистском. Это навык из серии "если ты не можешь объяснить сложную проблему пятилетнему ребёнку простыми словами — значит ты эту проблему и сам толком не понимаешь". Описанная в статье проблема — девушка Вас не понимает. Значит, учитесь объяснять. Когда (и если) проблема девушки преобразуется в "хочу нормально зарабатывать программированием" — вот тогда начинайте учить её программированию.
P.S. Кстати говоря, выбор Go я лично поддерживаю. Частично потому, что язык действительно простой. Частично потому, что бэкенду сейчас учить проще — фронт слишком динамично меняется, за ним тяжело угнаться, а новичку не помешает иметь в начале карьеры относительно стабильный период в несколько лет, когда полученные им знания и навыки сохраняют актуальность. Более того, я часто выкручивался из проблемы подбора задач, результат которых можно увидеть сразу же, через юнит-тесты — их в Go очень просто писать, и они позволяют относительно наглядно увидеть результат работы почти каждой, только что написанной, функции. Этого оказалось вполне достаточно, чтобы давать обратную связь "вау, оно работает!", необходимую чтобы часто получать позитивное подкрепление "задачка готова/у меня получилось" (ну и плюс это сформировало очень положительное отношение к написанию тестов в принципе, с пониманием громадной пользы, которую они дают, и которого так не хватает многим программистам).
Я думаю, что обучаться нужно не Вашей девушке, а Вам. И обучаться вовсе не программированию, а умению излагать волнующие Вас рабочие проблемы дома своей девушке на человеческом языке, а не программистском.
Один из лучших советов в обсуждении! Действительно, если научиться объяснять суть своей работы человеческим языком, то:
- Девушка начнёт понимать чем вы занимаетесь и что вас тревожит, а вам не придётся отшучиваться про пианиста в борделе.
- Вы сможете объяснить коллегам, ПОЧЕМУ задачу лучше решить так, а не иначе.
- Вы сможете объяснить начальству почему некоторые задачи решаются легко, а другие ставят команду в тупик, хотя вроде бы речь о схожих проблемах.
- Вы сможете парой фраз понятно объяснить шефу чем вы вообще занимаетесь и какая от вас польза фирме. Если вместо обычного программистского «абра-кадабра, мумба-юмба, НАДО сдвинуть сроки релиза» ваш начальник услышит понятное изложение вставших перед командой проблем, то он сможет и захочет вам помочь. Менеджеры любят чувство понимания, причастности и контроля.
- После всего вышеперечисленного, из вас может получиться хороший тимлид и архитектор, а значит меньше работы на дом, больше времени для девушки, да и денег тоже больше.
- Очень, очень часто, объясняя кому-то нынешнюю архитектуру, сам замечаешь косяки и возможности улучшения, а вовремя заданный посторонним человеком вопрос «а вот об этом ты подумал?» может быть решающим для успеха проекта.
- Работа программиста это не 100% написание кода. Например, когда мне нужно было подготовить презентацию для инвесторов, я сперва объяснил что же делает наша программа своей жене. Нарисовал на доске важнейшие юз-кейзы в виде картинок, и тут оказалось, что рисунки-то у меня убогие, с актёрами в стиле палка-палка-огуречик. Жена у меня художник, подсказала как парой штрихов придать человечкам эмоции и обозначить действие. Заодно научился чему-то.
Обучая десятилетнюю дочь программированию, заметил, что простые и «естественные» понятия как переменная, присваивание, и т.д. появляются в голове не сами по себе, и даже не в результате прочтения умной книжки, а только после многократного решения простых задач. Опыт, увы, достигается лишь упорством и настойчивостью. Для обучения программированию попробуйте решить одну и ту же простую проблему несколько раз, на разных уровнях абстракции. Например:
- Берём простейшую (для программиста) задачу, например написание Тетриса или Сапёра, и решаем её целиком во фронтэнде, фокусируясь на JavaScript, переменных, вложенных циклах и прочих элементарных конструкциях языка.
- Теперь решаем её ещё раз, но обращая внимание на внешний вид. Разбираем зачем нужен CSS и хорошо структурированный HTML. Вполне возможно, что вариант вашей девушки будет выгдядеть красивей и изящней, чем у опытного фул-стек-девелопера.
- Переписываем логику заново, теперь с использованием вашего любимого фрэймворка. После этого не только девушка, но и вы сами, сможете объяснить посторонним людям зачем они нужны, эти фрэймворки, где кончается мода, и начинается реальная польза. /* Осторожно! Не исключено, что придя на следующий день в офис, вы решите что нынешний код безнадёжно перегружен ненужными свистелками, и перепишете его на vanilla-js */
- Если задор не иссяк, можно добавить back-end, например для хранения таблицы рекордов. Причём не напирать на конкретную реализацию БД, а рассмотреть обмен данными между клиентом и сервером, защиту от читерства и потенциальные методы взлома вашего сервера. Проводя аналогию с электирчеством, в наше время не так уж важно знать от какого генератора берётся в розетке ток, а вот не трогать руками оголённые провода учат даже детей. Или, например, я никогда не задавался вопросом сколько клапанов в двигателе моей машины, но могу показать где находятся подушки безопасности и уверен, что они прикрывают всех пассажиров.
- Главное помните, что для большинства людей программирование это не самоцель, а всего-лишь инструмент для решения какой-то другой проблемы. Умение понять и точно описать суть этой проблемы это обычно уже больше половины её решения.
У меня нет проблем с коммуникацией. И в наших отношениях нет проблем с коммуникацией.
Моя девушка вникала, пожалуй, во всё, чем я когда-либо занимался, так же как и я всегда стараюсь изучать её предметные области. Такие вот у нас отношения.
Что касается плана обучения, он расходится с моим, но из него есть что почерпнуть!
Спасибо!
А презентации — это всё же совершенно отдельный скилл.
Да не особо отдельный, ведь те презентации на которых зовут программистов, по сути должны и так лежать в документации к любому проекту сложнее «Hello World». В нашем случае было так: фирму продавали, целиком, со зданиями, сотрудниками, товарами на складах, базой клиентов и самописным софтом. Собственно переговоры вело начальство, технарей туда не приглашали (и это правильно), но покупателям кроме всего прочего нужно было показать и состояние софта. И вот тут неплохо когда кто-то в команде может за 40 минут (на больше всё равно не хватит внимания) показать умным, но далёким от программирования людям:
- Зачем нам нужен софт
- Какие бизнес-процессы он поддерживает
- Почему мы пишем некоторые программы сами, а не покупаем готовое
- Кто на фирме пользуется нашими программами
- Какую пользу бизнесу принесли в прошлом году вон те 15 бородатых людей в свитерах с оленями
- Какие новые возможности должен дать софт в следующие 12 месяцев (тем самым пресекая в зародыше мысли объявить IT чистым центром затрат, с последующим соблазном «соптимизировать»)
- Почему в XXI веке каждая фирма это IT-фирма, даже если мы торгуем одеждой
Это существенно лучше, чем дать инвестором поймать у кофеварки джуниора, который скажет что у нас тонны прошлогоднего легаси-говнокода которые
Одним словом старая басня про строительство собора на новый лад.
PS: Если потом в глазах нового начальства ваше лицо будет ассоциироваться с чародеями из IT, решающими все проблемы предприятия, это тоже неплохо, даже если вы решили сделать чисто техническую карьеру.
А вот когда менеджер среднего звена со словами «давно не брал я в руки шашку» запускает SQL Server Management Studio, опытные сотрудники начинают нервничать, подозревая что он сейчас опять на пару дней углубится в решение интересной задачи, забыв при этом про свои прямые обязанности. Начиная с определённого размера фирмы, вовлечение топов в микроменеджмент конкретного куска кода это опасный знак.
Вы — личность в Go-сообществе известная, поэтому в содержании секции «P.S.» я не сомневался!
Что же касается основной мысли Вашего комментария, то я, как уже отписал и остальным участникам дискуссии, согласен с этой позицией, но здесь нужно учитывать контекст.
Конкретно в нашем с моей девушкой случае дело действительно не в моём неумении разговаривать на другие темы или переводить с программистского на русский. Здесь дело просто в том, что мне повезло жить с человеком, который хочет понимать меня ещё лучше. Проще говоря, то чем мы планируем заняться, — это не попытка решить проблему плохой коммуникации. Отнюдь!
У нас нет подобных проблем!
P.S. Только что приехали с рыбалки. Ездили двумя парами, и вторая семейная пара — программисты. Мы мало обсуждали специальность, но иногда всё равно проскакивает. Ей — интересно. Отказать в помощи любимой девушке, мне кажется, будет крайне эгоистично.
Мне всегда бомбит с этого тезиса.
Хочу послушать объяснение квантмеха пятилетнему ребёнку простыми словами.
Цитата, судя по всему, восходит к Ричарду Фейнману, а он объяснять умел. В том числе и квантовую механику. Не для пятилетних, конечно, но на уровне 8-го класса средней школы. А вот его рассказ про огонь поймут наверное и дошкольники.
А в макромасштабе, как нам кажется, всё работает, потому что постоянная Планка очень маленькая, и её невооружённым взглядом не видно. Никакой тут нет трагедии для детского разума.
Для меня лично с детства классическая картина с её дурными бесконечностями и демоном Лапласа была гораздо более непонятна.
Да почему ж? Этот вопрос можно специально разъяснить. Вот стакан молока, которое кажется неизменным, однако в действительности в нём происходит бурление микробов, отчего оно вскоре скисает. Также и кванты со сверхтекучестью. Бурление незаметно глазом.
> Я не вижу принципиальной разницы в детерминизме классической механики (в фазовом пространстве) и в детерминизме квантовой теории (в каком-то там хитром пространстве функций вероятности, ибо унитарненько).
Принципиальная разница в том, что сколлапсировать волновую функцию можно как угодно, несмотря на то, что плотность вероятности детерминирована.
Вот стакан молока, которое кажется неизменным, однако в действительности в нём происходит бурление микробов, отчего оно вскоре скисает. Также и кванты со сверхтекучестью. Бурление незаметно глазом.
Это все отлично но такие объяснения в 99% случаев приводят к неверному пониманию в тех или иных моментах. Проблема аналогий в том, что они всегда неточны.
Принципиальная разница в том, что сколлапсировать волновую функцию можно как угодно, несмотря на то, что плотность вероятности детерминирована.
А вы уверены что волновые функции существуют? Это что такое? реальный физический объект такой? А уверены что если они существуют, то коллапс существует? Это что такое? реальный физический процесс такой?
Любое объяснение приводит к неверному пониманию в тех или иных моментах, в том числе и самые продвинутые на сей день математические формулы.
Конечно, проблема только в том что корректное объяснение лишь может привести к неправильному пониманию, а некорректное — приведет совершенно точно. Потому что является де-факто ложью. Да, именно так — все эти рассуждения о "стаканах молока" просто прямая ложь де-факто.
Кванты не ведут себя как микробы в молоке, понимаете? Ни в каком смысле не ведут.
С другой стороны, если люди придумывают такую философскую ахинею, как копенгагенская интерпретация, то это показывает, что знание уравнения Шрёдингера не сильно приближает их к пониманию реальности по сравнению с верящими в духов и в микробов в молоке.
Разумеется, никаких волновых функций реально не существует
С другой стороны, если люди придумывают такую философскую ахинею, как копенгагенская интерпретация, то это показывает, что знание уравнения Шрёдингера не сильно приближает их к пониманию реальности по сравнению с верящими в духов и в микробов в молоке.
Ага. Тогда что вообще объясняют такие объяснения?
Вот ползает червяк. Он объясняет себе и своим деткам, что где темнее, там более влажно. В абсолютном смысле это неверно, но для его повседневного опыта обычно работает. Так же и волновая функция для человека.
А это уже детали языка, которым вы пользуетесь. Что там, что там — полный детерминизм законов эволюции системы.
Кстати, тоже, никогда не мог понять этого бомбления на счет недетерменизма. Уравнения детерменированы? Детерменированы, все замечательно, я по начальным данным могу предсказать эволюцию системы. Ну да, состояние будет описываться, скажем так, хитро. Дак ну и что? Почему у людей какой-то разрыв шаблона возникает от этого? Неясно.
Можно ещё, кстати, учесть, что (по крайней мере, насколько я понимаю) язык макромира вполне вкладывается в квантовый язык (и интерпретация квантмеха, где наблюдатель запутывается с явлением, делает примерно это).
А это самое смешное — получается, если просто интерпретировать модель квантмеха "в лоб", без каких-то выдумок и т.п. вещей, то, действительно, все вкладывается, да и вообще just works, логично и без каких-либо усилий. Но потом кто-то приходит и начинает выдумывать какие-то коллапсы и прочие странные вещи, от которых далее рвет шаблон. Воистину странная ситуация.
Мы давно вместе, и зная, свою девушку, могу сказать, что Таненбаум её, скорее, отпугнёт.
Но ваш личный опыт опыт лишний раз говорит о том, что на этапе планирования обучения необходимо оценить личностные качества ученика. Спасибо!
В итоге учу все сама, с Hexlet, даже решусь рекомендовать этот ресурс если у вас нет замечатльного парня-ментора :))
Это не имеет значения. У меня был опыт обучения девушек и с гуманитарным и с техническим образованием — никакой разницы я не заметил. Если не считать за разницу редкие комментарии "о, помню, нам что-то про это рассказывали в институте".
Но я, пожалуй, соглашусь с предыдущими ораторами в том, что в общем-то это не имеет значения.
На мой взгляд, разработка ПО и программирование, как его аспект, — это слишком обширное поле деятельности. Настолько обширное, что так сходу и не скажешь, где в хорошем программисте заканчивается технарь и начинается гуманитарий.
2. Синтаксис. Переменные. Циклы. Булева логика.
3. Работа со стоками.
4. Ввод, вывод, работа с текстовыми файлами.
Все. Можно делать рецептурный справочник. Простенький интерфейс, дает сделать рецепт и сложить его в структурированном виде в простой файл, новый рецепт в новый файл. Он же и дает их прочитать.
Потом миграция данных в базу. Потом замена хардкоженного интерфейса на веб морду. И дальше по нарастающей. Рефакторинг с функциями, библиотеками, и прочими плюшками. Выложить в инет. Доработать авторизацию. Показать подругам. Попилить продукт по их просьбам и замечаниям.
На детях проканывает. Результат сразу. Новые свистелки и хотелки, после изучения новых методов и технологий.
Когда-то я начинал изучение программирования на бейсике с программ, рисующих картинки.
Эксперимент показал, что и сейчас это хороший способ увлечь девушку программированием :-)
Вот такая штука, на яваскрипте: https://scf37.me/1.html
В свое время помог немного другу освоить программирование. Начинал он с hiasm (визуальное программирование). Когда он понял основы и стало тесно, то перешёл на c#. И далее самостоятельно начал развиваться.
Серьезно, вы описали курс моей мечты практически. Я сильно заинтересован в результате. Уже могу говнокодить (на питоне) и когда-то писал свою хоумпагу.
А то курсов до фига — и по бэкенду, и по базам, и по верстке. А как оно всё вместе работает — хз.
Возьмите, а?
Интересные рассуждения и вроде бы неплохой план, но…
Пока читал в голове созрела и твердо укрепилась мысль: Девушка уже забыла о том что она хотела учиться программированию, и когда парень (автор) начнет ей пытаться объяснять какие-то жутко запутанные и непонятные глупости она мило поморгает глазками, надует губки, покрутит пальчиком у виска, и быстренько сменит тему. Девушки они такие...
Я никогда не учил её программированию и безопасности. Но основные тезисы она легко воспроизводит.
Вроде «вордпресс — это завирусованное говно» или «консоль линукса — это лучшее, что есть в нашей жизни» или «nginx наше всё, apache — фанера для пенсионеров».
Тезис на тезис — и она легко заткнёт в разговоре начинающих эникеев.
А больше ничего и не требуется. Мне надо всего лишь вечерами иными изливать душу на определенную тему — про юзеров то, про заказчиков или просто про несовершенство технологий. И человек, который скажет тёплые слова про nginx — вы таких много рядом найдете? А у меня женушка завалит про proxy_pass парочку моих же слов — и вот уже на душе теплее.
Это же как удобно — переключаться вечерами на простые жизненные мелочи.
Исходя из заголовка темы «как научить программировать свою девушку...» — может, и не стоит вообще учить-то, а? У нас же и так за рабочий день столько в голову залетает сложных алгоритмов… вы не пробовали программировать за полночь? а я пробовал — сложно уснуть потом, всё лезут решения в голову.
Если у меня напротив вечерами была бы девушка-айтишник, крыша бы моя уже давно сказала «превед» и поехала в сторону. Так как девушки такой нет — у нас нормальный «баланс сил». Мне она парит про «экстрасенсов», а я парю про «php7» — ну и всё норм.
— Не, сынок, это — фантастика…
Я согласен с Вами! Собственно, примерно с этого-то статью и начал: прихожу домой через 5-10 минут после окончания рабочего дня — аккурат когда приходит в голову какое-то решение.
Эти ситуации случаются не так часто, поэтому пока она ещё не может, как ваша жена, уткнуть молодого джуна ремаркой об условном позднем статическом связывании в условном php, но вот захотелось ей вникнуть — не отказывать же.
Я не был инициатором, честное слово)
Django(Flask)/Postrgesql хватило бы начинающему за глаза. Во фронт вообще не стоит лезть, это работа отдельного специалиста.
– Сколько y Вас стоит консyльтация специалиста?
– Пятьдесят pyблей. Плюс Вы оплачиваете компьютеpное вpемя — по шесть pyблей за каждые полчаса.
– Хоpошо, это меня yстpаивает.
Идёт к кассе, оплачивает консyльтацию и час pаботы с компьютеpом, пpоходит к машине, садится, я сажyсь pядом.
– Итак, что Вас интеpесyет?
– Я хочy наyчиться пpогpаммиpовать.
– -=8-o Что?? Вы хотите это сделать за час???
– А что — не хватит? Сколько мне доплатить?
Я некотоpое вpемя исхожy междометиями, потом немного yспокаиваюсь и пытаюсь объяснить, что люди yчатся этомy годы и что за один и даже за несколько pабочих дней этого сделать невозможно… Она пеpебивает меня:
– Hо мне надо наyчиться пpогpаммиpовать только для Internet.
– Да какая pазница?.. — начинаю, было, опять кипеть я, но вдpyг в мой pассyдок закpадываются кое-какие подозpения, и я начинаю допpос с пpистpастием, в пpоцессе котоpого выясняю, что имела в видy девyшка под “пpогpаммиpовать для интеpнет”: ПОЛЬЗОВАТЬСЯ ЭЛЕКТРОHHОЙ ПОЧТОЙ
Я — админ БД.
за 21 год я не стал врачем, она — программером.
Но при этом вместе ловим рыбу.
Вопросы к автору:
Ваша девушка борщ вкусный готовит?
А Вы?
Она Вас грузит проблемами кулинарии/уборки/макияжа или своей работы?
Отношения должны быть симметричными -готовьтесь как минимум взять в руки пылесос.
По мере обучения буду писать новые статьи, в которых постараюсь чуть конкретней описывать процесс и чуть шире описывать контекст — надеюсь, это избавит читателей от некоторого диссонанса, справедливо возникшего у многих после прочтения этой статьи.
P.S. Javascritpt, имхо, не лучший выбор в качестве первого языка. Даже PHP, как по мне, гораздо понятнее для новичка и имеет меньше сюрпризов.
Наверно для женской натуры HTML/CSS и вообще визуальная составляющая понятнее и притягательнее абстрактности, потому и схватывается легче.
Не первый раз встречаю здесь в комментах что-то про женскую натуру и недоумеваю. Моя «женская натура» тяготеет к скриптам и консольным приложениям, и жестоко страдает от gui и тем более от web фронтенда. Может, это всё-таки не от пола зависит?
для женской натурыдля натуры отдельной взятого человека — моей жены — HTML/CSS и вообще визуальная составляющая понятнее и притягательнее абстрактности.
Ну а насчёт женской натуры мы тут с Адой Лавлейс посовещались и решили, что всё это — не более чем предрассудки :)
По выбору языка — конечно создать свою книгу рецептов с занавесками это весело (если она таки готовит), но:
1. Можно выбрать язык, который не знает и сам автор — тогда учиться будет интересно обоим.
2. Lua/Python — тогда она сможет творить в мире IoT, да хоть на базе esp8266 — к примеру, системой умного полива цветов перед «девочками» сможет похвастаться.
В других случаях (кроме книги рецептов и онлайн фотоальбома) — не поймут.
Я это к тому, что обучение должно проходить исходя из возможности создание полезного и интересного для нее продукта.
Можно выбрать язык, который не знает и сам автор — тогда учиться будет интересно обоим.
В принципе я писал об этом, когда говорил, почему выбрал Go для серверной части.
Но, если объективно, то не думаю я, что изучать новый язык двум людям с разным уровнем будет интересно.
Профессиональному программисту сколько надо на изучение языка? День? Два? Неделю, если это что-то совсем разное, как С и Haskell?
Любой, кто знает больше двух языков, сам язык поймёт за час просмотра примеров из официальной документации, дальше останется бегло посмотреть stdlib, и можно с открытыми документацией, гуглом и стэковерфлоу садиться писать новый проект.
А новичку на фундаментальные понятия нужно будет месяцок-то точно отвести.
Можно выбрать язык, который не знает и сам автор — тогда учиться будет интересно обоим.
Вот только из-за разницы уровня, обучение будет происходить с существенно разной скоростью, и «учитель» не сразу будет врубаться, где «затык» у ученика.
Чтобы кого-то чему-то научить — нужно знать на две ступеньки выше. Школьников учит человек с высшим образованием, лекции студентам читает как минимум кандидат. Это неспроста.
Конечно, какие-то аспекты идиоматики, стоит прояснить для себя с самого начала, но в большинстве случаев это произойдёт в момент знакомства с синтаксисом — примеры чаще всего пишут тем самым «абсолютно идиоматичным кодом».
Вот был-бы он сантехником ;-)
Отсюда вывод — вне работы — окружающих в свое дерьмо не посвящать!
Ибо бИда, если кроме программ и поговорить не о чем.
Мужчина сам должен уметь варить БОРЩ
Вы посчитали, что он полезен? Но нет.
Вы осведомлены о качестве борща моей девушки? Нет.
Зачем тогда?
Как научить программировать свою девушку, если ты не педагог, но она в тебя верит