Ну, проблемы не проблемы, а разные деревья крови могут попить по полной программе. Особенно, если их изучать до методов алгоритмизации.
Просто некоторые думают, что структуры данных это сложно. А на самом деле любая структура данных, это последовательная цепочка байт в памяти)))
Просто некоторые думают, что писать программы это сложно. А на самом деле любая программа - это последовательная цепочка байт в памяти)))
Просто некоторые думают, что писать музыку это сложно. А на самом деле любая музыка, это последовательная цепочка нот)))
Просто некоторые думают, что писать музыку это сложно. А на самом деле любая музыка, это последовательная цепочка нот)))
Ну последовательно там размещены указатели или как в питоне вообще сложные структуры данных, содержащие тип, счётчик и, опять же, указатель. То, о чем ты говоришь, относится к C++ ну и к некоторым более «низкоуровневым» языкам. Во всяких питонах, джабах, сишарпах и прочих джабаскриптах все более сложно.
Под капотом там (джава, сишарп) память для массивов все так же выделяется блоками и индексируется смещением указателя.
Боюсь, современные программисты, питонщики и жабоскриптовики, вряд ли знают, что такое смещение. Они больше специалисты по диаграммам, рисункам и всяким агилам)))
Не знают, потому что им это не нужно, разве нет?
Вы же не изучаете платы вашего ПК перед тем как писать на нем код?
Есть такое понятие - абстракция. Почитайте.
Поэтому и появляется такое не оптимизированное и раздутое говно, как электрон. И люди считают это нормальным. Я не предлагаю писать на ассемблере, меня печалит сама ситуация.
скорость работы vs скорость разработки
Если проект прожил в промышленной эксплуатации больше года и в нем осталась потребность, тогда можно и отрефакторить.
В противном случае до прома можно и не доехать.
А через год в коде не разберётся даже Аллах и придётся всё переписывать по новой на новых библиотеках и фреймворках)))
Я так понимаю с промышленной разработкой ПО вы не знакомы.
За выбором того, как писать ПО, стоит огромная работа по анализу требований и экономической обоснованности.
Можно писать «идеально», но тогда ваш проект будет стоить невообразимо дорого относительно рынка, а можно осознанно уступать в некоторых аспектах разработки, да при этом техническое исполнение будет хуже, но рентабельность проекта будет гораздо выше.
Никому не нужен идеальный код, всем нужен дешевый, но работающий. А производительность, например веб-приложений, всегда можно повысить кластеризацией и алгоритмами уже после релиза. Масштабировать проект нужно по нуждам;)
А где связь читаемого кода и глубокого понимания процессов внутри фркймворка/компилятора?
IT-юмор
5.6K постов52.4K подписчиков
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору