Всем привет!

Прошу прощения если подобная тема есть, а она уверен есть, просто есть вопросы которые возможно разбросаны по всему форуму частями.

Вопросов много но начну с предыстории:

В середине 90-х увлекался программированием на ассемблере тогда распространенных компьютеров ZX-Spectrum.
Лет 5 назад полез в PHP, MYSQL - писал через “Денвер” программу для собственных нужд на склад (на работе), нет я не изучил эти языки, все писалось с помощью гугла но все-же что то в памяти осталось.
Ну как бывает комп полетел и исходников нет.
Решил написать что-то подобное с поддержкой БД и самое главное что бы это был один исполняемый файл (инсталятор), на случай что бы сама программа сохранилась где нибудь на флешке а не тонна файлов как это было с “Денвером” (даже без базы)
На PHP писать нет желания, хотя вроде все понятно, но опять же “склад” работал с браузера - хочу отдельное окно при поддержке графических библиотек.
Вообщем хочу все в одной кучке аккуратно.
И не то что нет желания писать на PHP, а просто охота изучить что-то новое и самому все запилить.

Полез изучать java потом python - но как только дохожу до ООП - у меня мозг лопается, я просто не могу понять зачем он нужен, если все можно сделать и без него. То есть помня ассемблер я писал там все последовательно - согласен код после месяца писанины был не читаем, но если не отрываться и после завершения проги туда не лезть, то как бы и чтение его не зачем.
ООП я так понял это для открытого кода, который можно прочесть, понять, добавить или изменить, но въехать в само построение так и не смог (касается java) по моему слишком много лишнего там написано.

То есть для себя я понял что после ассемблера понять ООП мне как то не удается.
Сейчас окончательно решил заняться python, так как начитался что он очень прост в построении.

Вопросы:

1) какую лучше всего почитать литературу по ООП - если смотря лекции и читая в книгах я ни чего не понимаю.
2) возможна ли совместная работа python + mysql + какие то граф.библиотеки (ну что бы уж не совсем все топором было рубленое на экране) и самое главное что бы после завершения написания это все потом запихать в .exe, что бы не собирать в будущем запчасти по тайникам.
3) если отпустить mysql и содержать базу в файлах - это сильно нагрузит систему, если скажем это 100 папок с вложенными в них по 100 файлов, которые естественно придется все перелопачивать если нужна будет сортировка ?
4) возможно ли вообще изучить python в идеале и сколько на это может уйти времени, если свободного времени предостаточно ?

Вообщем по идее мне нужно собственное окно с таблицей и кнопками + БД или файлы.

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

Посоветуйте пожалуйста с чего начать и куда двигаться ?

vito-Z80
но я до сих пор помню ассемблер

Проверьте. Думаю попробуете написать код на современном ассемблере и не получится.

vito-Z80
нужно собственное окно с таблицей и кнопками + БД

А exel вам почему не подходит?

vito-Z80
какую лучше всего почитать литературу по ООП

Бросьте пока ООП. Разберитесь со словарями и списками. Тогда постепенно возникнет понимание классов в пиотоне.

vito-Z80
это сильно нагрузит систему, если скажем это 100 папок с вложенными в них по 100 файлов

Если нужна сортировка то надо строить индекс. В вашем случае еще один файл. Zodb кстати так и хранила данные - 100 файлов в 100 папках. Работало все нормально.

vito-Z80
понять ООП мне как то не удается

Да он прост как три копейки, если вглубь пока не лезть…
Вот представь дверную ручку:

она имеет свойства:
цвет
размер

она имеет методы:
нажать ручку
отпустить ручку

она имеет события:
ручку нажали
ручку отпустили
какойто гад ручку чемто измазал

Вот по сути весь ООП - есть класс объекта, для него все это описываешь. А потом плодишь ручек (объектов) сколько хочешь, все будут разные, но вести себя будут по одному принципу

doza_and

зачем exel, охота самому творить ) да и в будущем может пригодятся навыки.

книги читаю и на ООП останавливаюсь - дальше не лезу, охота все таки догнать это.

Iskatel

ну вот структура вроде как ясна, но как это будет в самом коде я понять не могу.

vito-Z80
В середине 90-х увлекался программированием на ассемблере тогда распространенных компьютеров ZX-Spectrum.

Из недавних - вот топик.
У тебя тот же самый уровень. Первого языка нет, поэтому остальные кажутся сложными.

vito-Z80
Полез изучать java потом python - но как только дохожу до ООП - у меня мозг лопается, я просто не могу понять зачем он нужен, если все можно сделать и без него.

У тебя программы до сотни строк. Сколько там функций? 10, 20 ?
Представь программу на 10000 строк, в которой 1000 функций. Поэтому делаются объекты, которые функции сгруппировывают в себе. Так у тебя появляется объект “стек”, у которого есть набор функций для работы с ним. Дальше “стек” можно куда-то передать, чтобы его заполнили через эти функции.

vito-Z80
То есть помня ассемблер я писал там все последовательно - согласен код после месяца писанины был не читаем, но если не отрываться и после завершения проги туда не лезть, то как бы и чтение его не зачем.

Программа должна быть правильной, понятной и легко изменяемой.
Придёт время, когда возникнет ошибка посреди разработки, которая никак не относится к текущему моменту.
Её нужно будет локализовать (найти источник), исправить и гарантировать результат исправления.
При свалке:
Сначала ты не сможешь понять, как работает программа (писал ты её год назад одновременно с другими похожими программами).
Затем ты не сможешь исправить ошибку, потому что исправление подействует на соседние участки кода и приведёт к дополнительным ошибкам.
А потом ты будешь сидеть и писать этот участок заново, потому что правку внести нельзя, а разработка без этого невозможна.

py.user.next
Из недавних - вот топик.
У тебя тот же самый уровень. Первого языка нет, поэтому остальные кажутся сложными.

что-ж… будем ковырять первый язык, хотя я всегда считал ассемблер основой основ… ну не считая самого машинного кода.

py.user.next

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

Ну не, не согласен тут в корне. Структура и архитектура программы должна все эти тонкости решать нормально, даже если это не ООП. ООП необходима только в больших и долгосрочных проектах, и это не моё мнение. Писать структурой намного, намного быстрее.

Лично по моему опыту, получается, что если написать один и тот же проект процедурой (без функций, либо они только в роли подпрограмм), то вся программа получится к примеру 100 строк, ну и конечно что-то менять там нереально сложно; если же написать структурированным, то идентичный проект получится в 200 строк, ну а если в ооп, то почти 400, плюс ещё и схемы придётся рисовать.

vito-Z80
читал ассемблер основой основ… ну не считая самого машинного кода.

Вот так волны иллюзий разбиваются о гранит реальности.

MiK
Ну не, не согласен тут в корне. Структура и архитектура программы должна все эти тонкости решать нормально, даже если это не ООП.

А при чём тут ООП? Прочитай цитату, на которую дан ответ. Эти правила не относятся к ООП или не ООП, речь о чистоте кода внутри функции.

MiK
если написать один и тот же проект процедурой (без функций, либо они только в роли подпрограмм), то вся программа получится к примеру 100 строк, ну и конечно что-то менять там нереально сложно; если же написать структурированным, то идентичный проект получится в 200 строк, ну а если в ооп, то почти 400, плюс ещё и схемы придётся рисовать.

Зато текущие изменения в логике работы ооп-проекта затрагивают на столько же меньше кода. Да и библиотеки никто не запрещает, и схемы можно не рисовать.