Python-сообщество

Leadwar
И тогда вопрос : Сколько Вы времени отдаете/отдавали - изучению Python ?

В нашем случае не сколько кто-то отдавал/отдает, а отдать максимум свободного времени.
По моему мнению это наилучшее решение.

4kpt_IV

Так а какие тут обиды могут быть, все так и есть…. тут только если мидлу интересен сам процесс обучения как таковой, но думаю что в программировании большинство людей “индивидуальные игроки”, нежели учителя.
А то что время не выделить, это блин замкнутый круг, жизнь требует денег, приходится их зарабатывать тем что умеешь, а в свободное время заниматься тем, чем хотел бы заниматься.
Благо у меня сейчас такой период, когда работа которая мне приносит средства для жизни, позволяет по 5-6 часов заниматься саморазвитием.

renz72

Я сначала написал вопрос, а потом понял что ответ я и так знаю ) Все верно , чем больше времени этому отдавать, тем быстрее можно достичь желаемого.
Но приходится иногда делать перерывы, дабы разложить кашу в голове по полочкам.
И еще ведь это постоянное желание уже начать больше практиковать, а книга неторопливо ведет свой рассказ. Но понимаешь что без теории нет и практики. И терпеливо ждешь ))

Leadwar
Начал читать книгу, вроде все ясно и понятно. И получается отвечать на все вопросы верно. И прочитал 400 страниц. Но теперь закралось сомнение. А с того ли я начал?

Нет никакого быстрого способа изучения программирования. Чтобы понимать, где хорошие книги или документация, надо прочитать и плохие и хорошие книги и документации. Опыт надо иметь. А с программами обстоит всё ещё хуже. Чтобы писать хорошие программы, нужно написать много плохих программ, которые даже не работают вообще. И вот потом, когда ты пишешь программу, ты видишь, что если ты напишешь какую-то строчку, то свалишься в свою очередную плохую программу, повторится старая история, где ты нахлебался. Вот пример полной фуфлени. Я вот такие тоже когда-то писал и сегодня перечитываю их спустя годы, смотрю, что я не знал тогда и насколько продвинулся. А почему с программами хуже дело обстоит, чем с книгами, - потому что они используются для мотивации. Если у тебя программа получается, то хочется ещё больше научиться делать, чтобы ещё больше всего написать. И тогда ты можешь ещё больше материалов прочитать, потому что есть смысл. Так вот программы не получаются никогда поначалу, поэтому заниматься не хочется. Я вот писал морской бой и написал за три месяца два поля с кораблями (с расстановкой через стрелочки на клавиатуре), а потом пришло время писать интеллект компьютера, чтобы он корабли искал, и на этом всё закончилось, это оказалось неподъёмной хренью. Я думал о графах, а графов я не знал. А как ещё принимать решение, бить в такую-то пустую клетку или нет, можно же проиграть из-за тупого перебора или рандомного поиска? Это же не интеллект, а фуфло, которое обыграть легко каждый раз, считай, его нет, если он такой. Надо делать какую-то весовую систему для областей, что мол вон та область оптимальнее для поиска корабля. Это сейчас я представляю примерный путь и графы реализую спокойно, если ещё они понадобятся там. А тогда я просто знал, что нужны графы, которые я не знаю. Так я её и повесил на замок. Три месяца - результат нулевой. Это сильно бьёт по мотивации и её надо заново выстраивать, наращивать. А с книжками проще - там ты просто её читаешь и что-то узнаёшь всё время и тебя прямо из книжки автор постоянно домотивирует, чтобы ты её ещё дальше читал и читал. Но с книжками ты ничего никогда не пишешь, только учебные задачки, которые на практике не используются никак, непригодны. Ну, знаешь там, мухобойка бьёт по мухе, которая перелетает из квадратика в квадратик и дальше там этих квадратиков N штук и прочие детали. Или там несколько гномиков делят шоколадку, гномиков три, а в шоколодаке пять клеток и прочие вещи. Ты их нигде не применишь, это всё только для набора опыта делается.

И вот как я тебе скажу: сингулярность у меня наступила через пять лет только, даже не через три. Что это такое “сингулярность” - наступает такой момент, когда ты все технологии, о которых мечтать не мог, начинаешь впитывать, как губка, одну за другой и причём очень быстро. Удивляешься, как так, я же не мог вообще понять в этом ничего, а тут спокойно и легкотня сплошная. Я вот сейчас Emacs освоил, а раньше даже начать его не мог. А с Emacs'ом я ускорился в разработке раз в десять, теперь проделываю больше вещей в единицу времени, чем раньше. Сейчас вот освоил git через него - тоже всё скоростнее стало. Ты просто быстро вжих-вжих и все ветки поудалял, почистил, посливал. А раньше, когда я запустил Emacs в первый раз, я даже не мог строку удалить (привык выделить и удалить выделение, а в Emacs'е такое не прокатывает, там надо вообще всё другое нажимать и по-другому делать). То же самое касается языков. Если раньше изучить какой-то язык было просто сложно, то теперь весь вопрос заключается только в заучивании, потому что основы ты усвоил из других языков и прекрасно в них ориентируешься. Поэтому когда ты увидел цикл в новом языке, ты просто его синтаксис смотришь, запоминаешь, а как применять сам цикл, ты уже знаешь прекрасно, потому что усвоил это при изучении своего первого языка. То есть применяешь ты его уже через пять минут, как будто ты сто лет на этом новом языке пишешь. А почему? А потому что то, как строить цикл, а по этой теме есть тоже целая теория на несколько страниц, ты уже усвоил. Вот оттуда эта сингулярность и возникает - ты просто берёшь готовые знания и навыки и просто прикрепляешь их к новому материалу. В новом языке отыскиваешь циклы, про которые ты уже всё знаешь. И так во всём.
И вот когда у тебя появляется сингулярность, вот тогда у тебя руки и развязываются, потому что ты можешь всё. А что не можешь, сможешь через пару часов. И тут уже по мотивации проблем нет никаких, есть только по времени проблема. Нет времени читать все эти синтаксисы, нет времени писать программы дальше, которые уже и так работают. Они просто рождаются и работают и ты их не хочешь писать. Хотя если добавляешь какую-нибудь плюшку, тот тут же её используешь и радуешься, что время на неё нашёл.

Вот такой вектор: ты должен нарабатывать опыт - и он даст через какое-то время результат. Но искуственно это сделать не получится, потому что опыт искуственно не наберёшь, а он порождает вот эти все вещи, которые и нужны, чтобы программы получались.

Отредактировано py.user.next (Дек. 31, 2016 21:32:33)

py.user.next

Спасибо большое ! Очень полезный совет. Про сроки понимал изначально, что это не стих выучить, тут можно и в года не уложиться. Про структуру так же понял, недавно, для интереса, решил посмотреть простенький код на js. И на удивление, я немного понимал происходящее. Сразу вспомнил как все говорят, изучив 1 язык, остальные будут легче даваться. Просто изначально боялся потратить 2-3 года на один из языков, а потом понять что нужен другой. Почитал мнения, советы и успокоился, так как мне в любом случае будет нужен более чем 1 язык.
С наступающим !)

Leadwar
так как мне в любом случае будет нужен более чем 1 язык.

Это точно, у меня есть проекты, где несколько языков задействованы одновременно, включая DSL'ы. Вот если пример рассмотреть, то можно представить себе, что есть какая-то часть на Go, например, потому что на нём легко писать многопоточные программы. И многопоточное ядро программы может быть написано на Go, потому что это удобно, быстро и оптимально (хотя я не любитель Go, но это ладно, всё равно ты его будешь знать, если он может в чём-то помочь, например написать в сто раз быстрее программу и тому подобное). Этой частью на Go управляет скрипт на питоне, потому что на нём можно много чего написать (выразить легко и многие средства есть, вроде того же argparse, где за пять минут полноценную командную строку можно сделать с множеством ключей). А скриптом на питоне уже из операционной системы управляет скрипт на shell'е (Bash или просто sh), потому что shell для этого и создавался, поэтому содержит множество средств для лёгкого взаимодействия между программами в системе. При этом всё автоматическое версионирование внутри проекта, это когда нужно в десяток исходников одним действием записать новую версию программы (которая может обновляться по несколько раз в день), выполняется с помощью мощного препроцессора m4, сделаного во времена начального развития C. Вот этот язык программы m4 - это и есть DSL, который тоже нужно знать, иначе ничего не напишешь на нём и версионировать не сможешь автоматически, в то время как нужно чтобы у тебя каждый скрипт самодокументировался. И будешь это делать руками, а потом и вовсе перестанешь это делать и уберёшь важную информацию из исходников (и не только из исходников, версия и информация об авторе используется и пользователем программы, например, чтобы сообщить автору о баге, найденном в такой-то версии программы).

Вот это всё - использование нескольких языков сразу. Тогда у тебя и проект получается полноценным, и нигде ничего не надо урезать или пытаться что-то засунуть не в тот язык - ну, типа писать на питоне то, что на нём неудобно писать, как, бывает, делают новички, которые питон освоили, а скриптовый язык системы не освоили и им приходится строить многоэтажные конструкции на питоне вместо того, чтобы написать три строчки на shell'е. Такое часто бывает и в итоге они сами себе замедляют работу в пять раз.

Отредактировано py.user.next (Дек. 31, 2016 21:20:40)

py.user.next

Отличный вектор. Рад что написал сюда и получил множество полезных советов. А то прям как в темном лесу )) иду и не верю что дойду )

Интересный опыт получил. Для разнообразия представлений, решил почитать учебник Майкла Доусона - Программируем на Python. Много комментариев было под книгой. Были те кто говорил что лучше учебника нет, и те кто говорил, что по нему не возможно ничего выучить. После Лутца, был удивлен скорости прохождения материала. Но весь материал, очень поверхностный. По сути, Доусен вообще ничего не объясняет. Просто показывает как это работает. Единственное, порадовало у Доусона много простых задач. У Лутца, к сожалению, я дошел до функций, но так и не смог без шпаргалок выполнить его упражнения.А так, конечно же Лутц лучший. Разбирает все до атомов.

И ко мне пришло озарение. По сути ведь любую программу сначала нужно представить в виде алгоритма.А потом уже можно переложить на любой язык. Т.е. не обязательно знать какой то язык программирования, для того что бы составить алгоритм программы.Как я понимаю, это достаточно большая часть работы. После чего выбираются способы реализации этого алгоритма ? Я правильно понимаю ?

Leadwar
По сути ведь любую программу сначала нужно представить в виде алгоритма.А потом уже можно переложить на любой язык.

Вот здесь писал про этапы разработки. Суть в том, что до конечной реализации есть несколько классических этапов представления программы. На каждом этапе проводится свой ряд действий, чтобы сделать программу лучше. Когда это всё выполняешь, программа получается идеальной с первого раза. Если же ты пренебрегаешь этим, то программа у тебя есть в конечном итоге, но потом её надо переделывать. А если времени на переделку нет (а его нет обычно), то она остаётся в таком виде и потихоньку ведёт весь проект в тупик. Там класс дерьмово написал, тут класс дерьмово написал - и у тебя в итоге целая программа из дерьмовых классов, которая в целом становится тоже дерьмовой. Это как автоваз, почему их называют тазами или вёдрами с болтами - потому что у них везде что-то отваливается постоянно и нельзя взять и просто починить что-то, потому что она вся так сделана.

Существует псевдокод, но это далеко не первый этап. Сам псевдокод используется для того, чтобы не нужно было отвлекаться на детали языка. Например, тебе нужно выполнить какое-то действие в программе, на псевдокоде ты просто запишешь это действие и всё, готов дальше придумывать, тогда как на реальном языке ты должен записать это действие правильно, соблюсти всю пунктуацию безошибочно, расставить все скобки правильно и прочие детали выполнить - время на размышление о поведении программы уходит на соблюдение правил языка, это неэффективно. А потом что-то не то написал и надо переделывать. Так вот что-то на псевдокоде переделать проще, чем то же самое на реальном языке. Благо, питон ещё в самом начале разрабатывался максимально приближенно к псевдокоду, поэтому в нём нет многих вещей типа точки с запятой в конце оператора или фигурных скобок у функции и круглых скобок у условий. Поэтому его часто используют в роли псевдокода, когда что-то формулируют, так как он для этого подходит. Но, вообще, понятие псевдокода гораздо шире, чем просто точечки убрать, псевдокод может иметь разную степень абстракции и быть как очень близок к реальному языку, так и очень далёк от него - всё в целях понятности делается. На псевдокоде, например, можно математические формулы напрямую записывать, тогда как на близко-языковом псевдокоде ты должен будешь её переводить и раскладывать, чтобы были понятны точно все операции.

Блок-схемы дают совсем другие возможности. Сейчас блок-схемы перевели в UML - это типа супер-продвинутых старых блок-схем, но его надо учить хрен знает сколько, а блок-схемами нужно пользоваться уже сегодня. Поэтому надо знать классические блок-схемы, потому что они простые, в них не надо ничего помнить, иметь какие-то особые программы для их составления, и их на бумаге можно нарисовать, а в UML ты запутаешься в треугольничках, которых там дофига, потому что обычно в программе всё подсказывают тебе, где и что, а на бумаге не подсказывают и время уходит.
Суть блок-схем в том, что со временем у человека, который их составляет, вырабатывается видение правильных схем и запутанных. Когда ты видишь в блок-схеме запутанный кусок, ты можешь его тут же распутать через блок-схему и получить эквивалентную схему, но уже без путанок. А после того как распутал, ты можешь внести правку в алгоритм, по которому её строил. Это вот и есть основная их функция - увидеть то, что не видно в словесном описании алгоритма. Со временем ты, конечно, их не рисуешь уже на бумаге или в компе (хотя UML рисуют и хранят), а представляешь в воображении и видишь эти путанки все там. Но чтобы получить этот навык, надо тренироваться на реальных блок-схемах, иначе всё так и останется в зародыше и у тебя просто не будет этого навыка, а не будет навыка - все эти путанки будут переходить в псевдокод (если ты его делаешь) или реальный код (если ты ещё и псевдокод побоку пустил).

Если всего этого делать не будешь, то у тебя даже одна функция, записанная сразу, будет получаться просто дерьмовой. Это как выглядит: вот задача, например, решить уравнение какое-нибудь и человек пишет решение сразу типа умный такой, и в результате у него функция решает не уравнение, а полуравнения, да ещё и неправильно при некоторых редких аргументах. Вот он её написал, потратил время на весь код, а результат нулевой. И переделать он её не может, потому что там у него всё со всем связано завязано, только выкинуть можно и написать заново. А заново что? А заново он опять пропускает ещё какие-нибудь случаи и всё опять повторяется. Переписать он точно так же не может, как и написать с первого раза, силы потрачены вдойне, а результат нулевой. И в итоге он всё бросает, а в реальных проектах он оставляет это неправильное, типа никто не заметит, что у него половина не работает. А всё почему? Потому что он косит под профессионала, а профессионалы всё сразу записывают не потому, что такие гениальные, а потому, что прошли весь этот путь со всей этой кропотливой хренью.

Отредактировано py.user.next (Окт. 29, 2020 23:16:18)

py.user.next

Прочитал этапы.Взял на вооружение.
Кстати, вопрос ! Если вдруг вы знакомы с книгой Лутца - Программируем на Python. Собираюсь после теории читать ее. Я думаю, эта книга даст мне пусть даже начальный навык некой архитектуры построения программ ? Потому что складывается впечатление, что Лутц рассказывая много теории, все же предполагает что по след.книге, читающий наберется практики.