Если кратко: оптимизации кода не должны быть во вред читаемости кода.
ЦитатаTimKruz ()
Эм, где-то вычитал, что по отношению к коду "красиво" = "понятно".
Цитата
Ты прав. Лишние вызовы ни к чему. Поэтому мой игровой движок максимально прост: Код begin GameEngine := TGenGECore.Create(Configuration); GameEngine.Run; end.
Понятно - растяжимо. Тебе может быть непонятно в силу того что твои знания недостаточны и ты просто не в состоянии адекватно оценить этот кусок кода. Не надо за уши притягивать и показывать свои сахарные обертки. Сокрытие работы не имеет ничего общего с понятностью. Те кто будут именно поддерживать твой код будут работать не с обертками а с тем что ты скрываешь за своим Create. ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Сообщение отредактировал pixeye - Пятница, 24 Мая 2019, 13:12
Понятно - растяжимо. Тебе может быть непонятно в силу того что твои знания недостаточны и ты просто не в состоянии адекватно оценить этот кусок кода.
ЦитатаTimKruz ()
Совсем другое дело, что понятность субъективна, это да)
Я не спорю, просто бывает менее понятно и более понятно (в самом общем смысле).
Цитатаpixeye ()
Сокрытие работы не имеет ничего общего с понятностью.
Сокрытие сокрытию рознь: — то, что больше никогда не придётся редактировать, и имеет понятный внешний интерфейс; — то, что постоянно падает и ломается, и при том трудно понять, как этим управлять извне.
И код свой я привёл скорее в шутку, а не как пример чего-то правильного) У меня вообще код редко бывает правильным (в первую очередь потому, что я ничего до конца не довожу)...
Цитатаpixeye ()
Те кто будут именно поддерживать твой код будут работать не с обертками а с тем что ты скрываешь за своим Create.
Ну смотри: — смотрим снаружи: просто, понятно (в отрыве от реализации); — вскрываем первый уровень абстракции: по-прежнему просто, понятно (в отрыве от второго уровня); — вскрываем следующий уровень абстракции: всё ещё просто и понятно (в отрыве от третьего уровня); — ... — углубляемся в самый низ: элементарные операции, понятные даже школьнику. В чём проблема?
Проблема тут только в том, что не все могут правильно разделить проект на самостоятельные и независимые уровни. Например, я уже писал тут, что код должен работать даже отдельно от остального кода — это означает не только то, что любая из подсистем игрового движка должна запускаться отдельно от остального кода движка, но и любой существенный фрагмент кода не должен зависеть от всего остального кода (т.е. если воткнуть в другую программу, его поведение не изменится).
Как я понимаю, в этом и должно заключаться ООП. Мы создаём "объекты" как нечто, что существует само по себе, и нас не должно волновать, какие внутренности в них спрятаны (пока эти внутренности оправдывают наши ожидания). Но это возможно, только пока объекты остаются маленькими и понятными (подразумевается собственный код объекта, а не суммарно с вложенными объектами).
Ой, и вообще, разве разработка снизу вверх не решает эти проблемы? Сделали модуль, протестировали, и больше никогда к нему не притрагиваемся, только если не забудем, чем он должен был заниматься (но эту проблему устраняет понятность интерфейса и, при необходимости, документация). Вообще не понимаю, зачем копаться в кишках какого-то компонента, если проще и быстрее собрать новый из тех же фрагментов, из которых собран старый (если стараться делать проще).
Ммм... Ну вот, скажем, тот транслятор, о котором я говорил, используется всего в три шага: Create, LoadFromFile, Generate. Последняя функция принимает требуемую точку входа в скрипт, и возвращает результат трансляции/выполнения (на самом деле это скорее метаязык, он описывает только порядок слияния чего-либо с чем-нибудь, так что я не знаю, какие определения тут уместны) в виде строки. Зачем нам ковыряться во внутренностях? Только если расширять синтаксис языка, но тогда это будет уже совсем другой транслятор другого языка. Поэтому я могу использовать этот транслятор и отдельно, и в составе игрового движка, и ещё в чём-либо, где требуется нагенерировать каких-то данных из скрипта — и мне даже не нужно думать каждый раз о том, как устроен транслятор изнутри, потому что его работа абсолютно одинакова.
А вот обратная ситуация, когда у какого-то пепелаца стопицот рычагов управления (кажется, это называется "суперобъект"?), и приходится рыться в его реализации, чтобы понять, почему при дёргании за рычаг №120 отваливаются рычаги со 150 до 230, а рычаг 90 ещё издевательски посвистывает при этом (или бросает безымянный exception без внятного объяснения). Разобраться в этом всём можно, разумеется, но — зачем? Какая-то особая форма мазохизма, рыться в этом всём...
(Это основная причина, почему я пилю велосипеды и ненавижу обмазываться готовыми библиотеками. Моя мечта (одна из) — сделать свой ЯП, на котором никогда не будет чужих библиотек, и писать на нём лично. В гордом одиночестве. Что мне будет угодно.)
(Это основная причина, почему я пилю велосипеды и ненавижу обмазываться готовыми библиотеками. Моя мечта (одна из) — сделать свой ЯП, на котором никогда не будет чужих библиотек, и писать на нём лично. В гордом одиночестве. Что мне будет угодно.)
Зачем ?
ЦитатаTimKruz ()
Проблема тут только в том, что не все могут правильно разделить проект на самостоятельные и независимые уровни. Например, я уже писал тут, что код должен работать даже отдельно от остального кода — это означает не только то, что любая из подсистем игрового движка должна запускаться отдельно от остального кода движка, но и любой существенный фрагмент кода не должен зависеть от всего остального кода (т.е. если воткнуть в другую программу, его поведение не изменится).
Как я понимаю, в этом и должно заключаться ООП. Мы создаём "объекты" как нечто, что существует само по себе, и нас не должно волновать, какие внутренности в них спрятаны (пока эти внутренности оправдывают наши ожидания). Но это возможно, только пока объекты остаются маленькими и понятными (подразумевается собственный код объекта, а не суммарно с вложенными объектами)
Решается через ecs. Ненужны сложные классы, интерфейсы, "объекты" , наследования и прочая муть Есть данные, есть обработчики. На ооп языках реализуемо. Клац
Непонятно о чем именно идет речь. О каком коде мы с тобой говорим? О коде игры или движка?
У меня код условно разделен на три дома:
->Фреймворк и общие утилиты. Максимальное абстрактный код идущий под все проекты. ->Общие игровые системы подходящие однотипным играм. Они переносятся так же под проекты без перезаписи. На самом деле у меня таких систем оч мало. В основном это системы инпутов, простой физики и движений. И то в чистом виде обычно переносятся только инпуты. ->Специфические игровые системы под конкретную игру. Хотя архитектура позволяет скопировать все компоненты и системы в другой проект в этом нет никакого практического смысла. Они необходимы только в контексте конкретной игры и трата времени на излишнюю абстракцию в попытке сделать их "универсальными" только мешает работе.
Хороший вопрос Ну тип... Просто нравится делать что-то, что работает. Но когда юзаешь готовые инструменты, сначала тратишь уйму времени на изучение этих инструментов, а потом уйму времени на борьбу с ошибками этих инструментов, которые не можешь исправить из-за монструозности этих инструментов (при том что 90% от их функционала тебе не нужно!). В итоге ничего нормально не работает, а ты завален мануалами и не понимаешь, зачем тебе это всё нужно изучать, ломать и чинить...
Я вот, например, никак не пойму, зачем в C++ и подобные ЯПы продолжают добавлять новый функционал даже не на уровне библиотек, а на уровне синтаксиса. Зачем? Это ведь изучать нужно, а потом возиться в каше из кучи сущностей, использования многих из которых можно было бы избежать (если бы в языке их не было, либо программисты их не использовали)... Типа сначала все ополчились против "goto", мол он усложняет восприятие, но потом сделали 100500 новых фиговин, которые ничуть не лучше goto, особенно в таком количестве.
Честно говоря не понимаю людей, которые хвастаются, что такой-то ЯП умеет делать и так, и эдак, и ещё десятком инструментов. Оно, может, и удобно в ряде случаев, но потом приходится удерживать в голове кучу информации, чтобы разобрать очередной фрагмент кода. Типа: "так, а почему здесь это? а, новая функция, недавно в стандарт добавили... а это что? а, здесь использование бага десятилетней давности, понятно... а вот это, кажется, должно приводить к ошибке, ну-ка глянем в мануал... не, это только выглядит как ошибка, но формально допустимо... а это что за бред? нет, и так тоже можно..."
Вот и хочется иметь инструмент, который не имел бы в себе всего этого мусора. И заодно — чтобы не было соблазна набрать use MagicLibrary, которая делает хорошо, но непонятно как.
А ещё меня бесят лицензии. Надеюсь, если из чужого у меня будет только "железо" (инструкции ЦП, команды BIOS, и т.д.), я не должен буду прикладывать специальный файл, в котором тщательно подлизываюсь к каждому, кто хоть как-то посмотрел на мой код? А то так ведь придётся создавать свой компуктер, только потом окажется, что транзисторы запатентованы и нужно кому-то дань нести, чтобы из них что-то паять... Остановите планету, не хочу нарушать чьи-то авторские права на Землю((
Счастье детей и домохозяек — нажимать "я принимаю лицензионное соглашение" ещё до того, как это самое соглашение успеет появиться на экране. Остальные вынуждены страдать (ну, кроме юристов, наверное).
Цитатаpixeye ()
Решается через ecs.
Entity component system? Можно было б хотя бы ссылку на Вики дать.
Код не совсем понял, но глянув статью на Википедии, вспомнил, что что-то такое и пытался сделать. Ну, разумеется, после того, как несколько месяцев назад прочитал статью про подход через компоненты. Но, опять же, какие компоненты мне нужны? Пытался построить схему движка, но так и не приблизился к пониманию, как всё связать (например, как и когда физический движок передаёт графическому координаты, если графический не знает о существовании физического, и наоборот?).
Цитатаpixeye ()
Непонятно о чем именно идет речь.
Не важно, просто я со своими попытками сделать всё универсальным зашёл слишком далеко, и окончательно запутался))
Да, знаю, если б я реально работал программистом, а не страдал в попытках на коленке сделать то, что не удаётся огромным корпорациям (ибо всё меньшее уже сделали до тебя), то у меня не было бы таких проблем, просто следовал бы общепринятым методам работы над проектами. Зарабатывал бы кучу денег и так далее)
Но я уже смирился, что мой путь — это к тем поехавшим одиночкам, которые мнят себя великими изобретателями, а на деле несут какой-то бред, в огромных масштабах (для примера, есть один форум по ИИ, так там как в дурдоме — все такие сурьйозные, а говорят в основном о совершенно бредовых вещах, далёких от практической разработки). Так-то нет особой разницы, пытается человек изобрести вечный двигатель, найти философский камень, сформулировать общую концепцию всего или запрограммировать компьютер на человекоподобное поведение... Короче, всё очень плохо у меня.
зачем в C++ и подобные ЯПы продолжают добавлять новый функционал даже не на уровне библиотек, а на уровне синтаксиса.
TimKruz, так уж обстоят дела. В си например мало что появляется. Выучил его и знаешь много лет, ничего нового не надо учить, все знания которые есть, их хватает, чтобы писать нормальный код. А в c++, вот у меня книга есть по c++17, так там удобства новые завезли. Например можно создать структуру.
Код
struct employe { int id; int std::string value; int res; };
И получить в цикле вот так значения.
Код
std::vector<employe> employee; for ( auto const &[ id, value, resource ] : employee ) { std::cout << id << " " << value << " " << resource << "\n"; }
То есть новые возможности языка добавляют удобства или повышают производительность. Я бы так и писал на си, что иногда и делаю, но мне нужно расти дальше и я изучаю c++.
Добавлено (25 Мая 2019, 18:20) --------------------------------------------- TimKruz, ну как ты пробывал сделать хакерскую игру?
Но я уже смирился, что мой путь — это к тем поехавшим одиночкам, которые мнят себя великими изобретателями, а на деле несут какой-то бред, в огромных масштабах (для примера, есть один форум по ИИ, так там как в дурдоме — все такие сурьйозные, а говорят в основном о совершенно бредовых вещах, далёких от практической разработки). Так-то нет особой разницы, пытается человек изобрести вечный двигатель, найти философский камень, сформулировать общую концепцию всего или запрограммировать компьютер на человекоподобное поведение... Короче, всё очень плохо у меня.
Ты просто честно-честно ответь себе чего ты действительно хочешь. И все встанет на свои места : ) Не прячься и не играй в игры разума. Все на поверхности. ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
const MSG_EMPLOYEE_INFO = 'Employee #%d: %s %s (%d y.o.)'; type TEmployee = record ID: Integer; Name, Surname: String; Age: Byte; end; var EmployeesRoom: array of TEmployee; Employee: TEmployee; begin for Employee in EmployeesRoom do with Employee do WriteLn(Format(MSG_EMPLOYEE_INFO, [ID, Name, Surname, Age])); end;
Ваще не понимаю, зачем нужны все эти ::, auto const &[]:, <type>, <<, >> и прочая бесовщина. То есть разобрать и понять значение я могу, но принимать это не хочу. Больше слов — меньше неясных спецсимволов!
ИМХО, есть два вида ЯП: 1. Spider; 2. ,//\\(::,,::)//\\, Первые можно читать и понимать как текст, а вторые нужно разглядывать, как ASCII-картинку. Вот только если в языках первого типа на опечатку в слове укажет компилятор, то в языках второго типа мало того, что можно глазами не заметить лишний/недостающий символ, так ещё и компилятор может принять опечатку за корректный код, который приведёт к неизвестным заранее последствиям... Поэтому мне больше нравятся языки, подобные языку Ada (паскаль на максималках, еее). И читать приятнее, и пишется проще (дольше — не сложнее; проще — не короче).
Цитатаafq ()
TimKruz, ну как ты пробывал сделать хакерскую игру?
Ну я набросал такую вот фигню около 4 часов ночи:
А потом мне это надоело и я уснул под утро)
Цитатаpixeye ()
Ты просто честно-честно ответь себе чего ты действительно хочешь. И все встанет на свои места : ) Не прячься и не играй в игры разума. Все на поверхности.
Если отбросить инфантильные мечты — ничего по-настоящему не хочется, и это вгоняет в депрессию. Если фокусироваться на тех мечтах — реализовать их не выходит, и это вгоняет в депрессию.
Скажем так, всю мою сознательную жизнь пронизывают идеи, связанные с разумными существами, не являющимися людьми в биологическом смысле слова; в особенности, идеи, связанные с робототехникой, искусственным интеллектом и т.д. Последнее преобладает за счёт того, что надежды на каких-то инопланетных/биоинженерных/потусторонних/каких угодно ещё существ нет, а вот робототехника развивается семимильными шагами вот прям щас. Это я понял ещё в детстве, наверное.
Вот только реальность оказалась в разы жёстче, чем в самых пессимистичных моих прогнозах. То, что называется сейчас ИИ, и близко не стоит с тем, о чём мечтается, при этом развитие ИИ направлено на бизнес, а это вообще противоположно моим желаниям, соответственно помощи ждать не от кого. В книгах на тему ИИ либо сплошная математика, либо философия. Собственные мои размышления упираются в концепции, которые не ведут ни к чему хорошему (ибо зачастую получается "сделаем вот так, а потом оно авось само как-нибудь"), если вообще к чему-то ведут (иногда тупо зарываюсь в философию или математику). Делать роботов же вообще не вижу смысла до тех пор, пока у меня не будет способной к самообучению программы, но и тут уже вижу, что слишком радужно воспринимаю идею "запилить роботессу" (в детстве вообще фантазировал на тему "собрать из выкинутых на свалку электронных плат", хотя когда-нибудь и такое станет возможным). В сумме вся эта безысходность загоняет меня ещё глубже в ту депрессию, в которую я вошёл давным-давно благодаря усиливающейся социальной дезадаптации и ряду других причин...
Я бы мог заняться чем-то другим (ну, не знаю, научиться рисовать кавайных аниме-тян давно хотелось), если бы увидел в этом значимость выше своей идеи-фикс (ммм, живая роботян лучше нарисованной, не так ли?). Но пока я не вижу особой значимости во всём, чем пытаюсь заниматься, малейшие неудачи заставляют меня всё бросить и углубиться в страдания ("аааа! опять как-то не так рисуется! какое же я ничтожество, даже такую бесполезную фигню сделать не могу!")...
TimKruz, ты же вроде писал что сделать файлы и каталоги легко. Я думал что ты это в первую очередь сделаешь. А ты за четыре часа сделал echo и exit.
Добавлено (26 Мая 2019, 05:46) --------------------------------------------- Или ты там движок свой делал для игры?
Добавлено (26 Мая 2019, 05:50) --------------------------------------------- TimKruz, я например когда раньше Delphi учил то код читался ещё нормально, но щас чтобы прочитать его надо вчитываться чуть ли не в каждую букву, сложно взглянуть на весь код сразу и понять что там. Я когда раньше попробывал c++, мне было сложно его запомнить и через какое то время я увидел си язык. Вот его то я и начал учить. Ну как учить. Я его обнаружил, а учить стал аж только через несколько лет. Тебе же советую учить какой нибудь язык раз в год. Ну или не раз в год, а хотя бы ещё один язык, чтобы мышление менялось.
Добавлено (26 Мая 2019, 05:54) ---------------------------------------------
Цитата
Скорее НЕудобства. Я уже описал выше, почему излишнее разнообразие на базовом уровне — плохо.
Никто не заставляет использовать стандарт 17, можно использовать базовый стандарт. Но слова, которые там написаны очень просты. auto это чтобы я не писал тип переменной, в данном случае employe, хотя и это не правильно, ну ты понял суть. Далее const это значит константа, что она изменятся не будет. Символ & указывает, что не надо копировать переменную из employee, а взять прям её в employee. Далее идёт кортеж, в котором объявлены переменные разных типов, для этого auto нужен был, чтобы переменные каждый свой тип получили.
Сообщение отредактировал afq - Воскресенье, 26 Мая 2019, 08:40
Ваще не понимаю, зачем нужны все эти ::, auto const &[]:, <type>, <<, >> и прочая бесовщина.
Да и не надо понимать если не хочешь : )
ЦитатаTimKruz ()
Если отбросить инфантильные мечты — ничего по-настоящему не хочется, и это вгоняет в депрессию. Если фокусироваться на тех мечтах — реализовать их не выходит, и это вгоняет в депрессию.
И про твой оффтоп.
ЦитатаTimKruz ()
если бы увидел в этом значимость выше своей идеи-фикс
Исходя из поста у меня не сложилось впечатления что тебе ничего не хочется. Кажись тебе бабы хочется XD Нормальное такое желание. Роботяны и прочая хренота просто отмазы
ЦитатаTimKruz ()
малейшие неудачи заставляют меня всё бросить и углубиться в страдания ("аааа! опять как-то не так рисуется! какое же я ничтожество, даже такую бесполезную фигню сделать не могу!")
Ну смотри, мы с тобой в одной лодке. Я рисовать тож не умею. И кучи вещей делать не умею. Но эт не делает меня ничтожным по отношению к тем кто умеет. Ты то должен понимать что любой навык это пот, труд и опыт. Почему ты позволяешь себе неуважать чужое ремесло считая что у тебя вот просто так что-то должно взять и получится на одном только твоем желании?
Нормальная реакция для человека обесценивать то, что ему нравится, но получить не может. Мозгу так проще.
Не надо быть 7 пядей во лбу чтобы быть счастливым. Не надо чего-то сильно хотеть чтобы быть счастливым. Надо принять себя и двигаться дальше. Всё нытье что ты писал - эт не ты Это та матрица что ты себе придумал чтобы не было больно по-настоящему.
Искренне желаю тебе найти сил разобраться во всём этом. ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Сообщение отредактировал pixeye - Воскресенье, 26 Мая 2019, 06:30
TimKruz, вот смотри что у меня реализовано. Кстати для терминала выбирать лучше команды линукса, потому что врядли хакер будет пользоваться терминалом ms-dos.
Добавлено (26 Мая 2019, 07:33) ---------------------------------------------
Цитата
И читать приятнее, и пишется проще (дольше — не сложнее; проще — не короче).
TimKruz, я учил ada, но уже не помню его. Ты думаешь что только эти языки читать легко, но это может быть тебе. Я например если выучу язык, то мне будет его легко читать, но понимать код может быть сложно. Всегда сложно понять что автор имел ввиду написав несколько строк кода.
Добавлено (26 Мая 2019, 07:36) --------------------------------------------- На видео я попытался провести трассировку маршрута до адреса 10.21.100.2, но этот адрес внутренный для компании, и его можно пропинговать только находясь либо клиентом либо сервером компании. А в моей компании, хоть и в редакторе написан адрес 10.21.100.2, но я его в код ещё не добавлял. Думаю сделать полуавтоматическое создание провайдеров и компьютеров. Пока в процессе.
Сообщение отредактировал afq - Воскресенье, 26 Мая 2019, 09:34
Готовы ли вы выложить код на github, чтобы любой желающий мог понять как ваша игра работает?
Я сейчас не делаю игры конечно, но все свои pet проекты выкладываю на гитхаб.
Цитатаafq ()
Да и как ты без общения с автором разберёшься где что добавлять?
Отладчик, реверс инженеринг
ЦитатаTimKruz ()
Мне кажется, нечитабельный код пишут хейтеры begin..end из алгол-подобных языков. Ведь это они жалуются, что вынуждены писать 8 символов вместо двух. Конечно, быстрее набрать цепочку из спецсимволов, чем текст, но о том, как люди будут это читать (машине-то всё равно), никто почему-то не задумывается...
вкусовщина, мне вот например не нравится эти begin и end, болеее удобно пользоваться скобочками.
ЦитатаTimKruz ()
Короче, хороший код – это когда ты ткнул пальцем в любую строчку, и уже знаешь, кому она принадлежит, чем занимается и зачем здесь нужна. Но для этого код нужно писать человеческим языком, а не кучей закорючек и спецсимволов. И любой ЯП это позволяет сделать (даже Ассемблер с макросами-вставками).
Ну фиг знает на счет ассемблера, это дикий лоу левел и 10 строк уже могут быть абсолютно не понятными, если писал его не ты, плюс условные и безусловные переходы вместо ветвлений и циклов очень сильно усложняют навигацию по коду (хотя может это и решается с помощью макрасов?).
ЦитатаTimKruz ()
И я совершенно не понимаю, почему половина человечества мечтает "общаться с компьютером на человеческом языке", а другая общается с этими компьютерами на максимально нечеловеческих языках, несмотря на возможность так не делать... Можно было бы понять, если эти специальные коды было бы легче воспринимать, чем простой текст, но разве это так? Программирование ни разу не математика, мы оперируем реальными вещами (кроме случаев, когда вычисляется математическая формула, но это всегда делается для чего-то, а не просто так), так не надо втягивать сюда огромные формулы из отдельных символов.
Программирование и математика в том числе, и математика - это не просто набор символов, она тоже может быть красивой и выразительной, так и в программировании существует не одно лишь ООП, но так же и функциональное программирование, реактивное программирование, data orietned programming и каждая решает определенные проблемы, естественно, если ты не знаком с функциональной парадигмой, все что будет написано будет не понятно, хоть как ты обзови переменные (хотя конечно хорошо названные переменные и функции снизят порог), просто нужно учить новый подход. Код должен быть не только красивый и читабельный у него должны быть и другие качества, в том числе поддерживаемость, надежность, корректность, система не длолжна падать от малейшего чиха, и вто же время она должна работать корректно, ну и естественно поддерживаемость кода, я встречал не мало кода, который с виду выглядил чисто, красиво, опрятно, но черт ногу сломит чтобы понять как оно все работает, все раздроблена настолько мелко и не пойми как взаимодействует друг с другом.
ЦитатаTimKruz ()
Их много. У Васи один стандарт, у Пети другой. Как им без начальника сработаться? Мы же тут обсуждаем опенсурс, в котором каждый может притащить кусок своего кода в общий проект, и никто никому не обязан. Кроме того, команда команде рознь, команда школьников без опыта работы – тоже "команда".
Обычно для open source добавляется файлик CONTRIBUTING.md, в котором и описываются правила работы с кодом, стиль кода, основные парадигмы итд, да и банально, если ты не будешь соблюдать эти правила, твои изменения просто напросто не примут.
Цитатаafq ()
С чего ты взял, что сможешь разобраться в сложном проекте, если даже в моём не можешь?
Я знаю что смогу, в сложном проекте обычно выдержанный стиль и есть определенная архитектура, и не обязательно вникать в детали всего проекта, можно сосредоточиться на определенных ее частях, я работал и котрибьютил в Intellij IDEA к примеру, у них там просто понятный хороший код, местами конечно сложно понять что к чему. Бывает наобором, большой проект, и там ничего не понятно и ридется весь день просидеть с отладчиком, чтобы понять как хоть маленькая часть работает, код бывает разный, что в большых проектах, что в маленьких и твой критерий оценки - "Если ты не разобрался даже в моем, то ты не сможешь разобраться в крупном проекте" не корректен.
ЦитатаTimKruz ()
Эм, где-то вычитал, что по отношению к коду "красиво" = "понятно".
это не всегда так, бывает я знаю как решать сложную задачу, код получается громоздким, все понятно, но его много, и вот в один прекрасный день, ты просто смотришь как ту же самую задачу можно решить на функционально яп и она занимает жалкие 3-4 строчки, ты его можешь не понимать, но тебе это решение по умолчанию может показаться красивым, т.к. та же задача решается намного короче.
Цитатаpixeye ()
Тому кто тебе платит глубоко ***** красивый код или нет
Ну конкретно красивый или нет, действительно пофиг, но некоторым компаниям все же важно, чтобы код был поддерживаемый (а поддерживаемый код не всегда = красивый).
ЦитатаTimKruz ()
Но почему-то я догадался, в чём суть процедурного подхода (назвать кусок кода именем, чтобы он был понятен), а большинство считает это чепухой и продолжает нагромождать безымянные горы команд, говоря "так быстрее".
Нужно просто сменить окружение, если находишься в окружении джунов, то чего ты еще ожидаешь от них? Они учаться еще и без должного менторства еще будут долго сами до этого доходить.
ЦитатаTimKruz ()
Вот и хочется иметь инструмент, который не имел бы в себе всего этого мусора.
Просто не пользуйся не нужным мусором и пиши в своем стиле, скажем компании Insomniac (которая создала spider man новый) использует С++ и при этом очень сильно ограничивает функционал которым можно пользоваться, они не пользуются динамическим выдилением памяти в куче (у них свои аллокаторы памяти), не используют шаблоны, не используют исключения итд. Зато в C++ очень развитая инфраструктура и можно найти зрелые и хорошо отлаженные библиотеки, которыми можно просто пользоваться, а если не нравится интерфейс и он сильно выбивается из стиля проекта, просто создай свои обертки.
Цитатаafq ()
В си например мало что появляется. Выучил его и знаешь много лет, ничего нового не надо учить, все знания которые есть, их хватает, чтобы писать нормальный код
Ага, знать язык, даже очень хорошо, не достаточно чтобы писать нормальный код, не достаточно, чтобы писать работающий и стабильный код, тем более на Си, где даже на маленьких проектах, можно начать ловить сегфолты и поиметь проблемы с памятью, нужно уметь разрабатывать ПО в принципе, и тогда уже не сильно будет важно, какой яп использовать, ЯП - это просто инструмент.
Добавлено (27 Мая 2019, 13:10) --------------------------------------------- В принципе стремиться писать хороший читабельный код - это хорошо и в этом я полностью солидарен с TimKruz, но также надо понимать, что это не всегда возможно в принципе, бывает сложная предметная область и прятать эту сложность себе дороже, это будет просто заметанием под ковер и не решит проблемы с поддерживанием кода.
Ага, знать язык, даже очень хорошо, не достаточно чтобы писать нормальный код, не достаточно, чтобы писать работающий и стабильный код, тем более на Си, где даже на маленьких проектах, можно начать ловить сегфолты и поиметь проблемы с памятью, нужно уметь разрабатывать ПО в принципе, и тогда уже не сильно будет важно, какой яп использовать, ЯП - это просто инструмент.
Xakep, ну это уже другая тема. Вопрос был в том, что такие языки как c++ много нововведений получают на каждом стандарте. А си нет. Можно ловить и сегфолты и на c++. Я к тому что язык сам легче выучить, и не придётся доучивать новые фичи. А нормальный код писать, это что с помощью языка, который легко учиться, можно писать нормальный код.
Я хоть и кодил когда то давно давно на плюсах но перешел на дельфи, а после еще и на шарп. И вот, я часто слышу от плюсовиков о проблемах с памятью и никогда не понимал, что за ужасы там творятся то)
TimKruz, Мой науч рук, доктор наук...., а ныне мой начальник, когда то давно мне сказал "Дима, думать вредно, лично я стараюсь делать это как можно реже". С тех пор это моя философия по жизни, кстати эта философия очень схожа с философией тайцев "сабай сабай"(вроде), что означает "Если ты не можешь на это повлиять, то зачем волноваться и тд?" Так вот, меньше думай, больше кодь) Осознание красоты кода, собственный стиль, как и способность понимать свой и чужой код, приходят со временем. TimKruz, И самое главное это "следи за КПД", в погоне за универсальностью, красотой и тд и тп можно усложнить решение задачи многократно) Не надо так делать) Да и вообще писать код с расчетом на дальнейшее его использование в других проектах.... Когда ты будешь делать другие проекты твой навык кодинга, всяко выше чем когда делал предыдущий проект и старый код будет для тебя просто мусором. Цитата недели: Из-за леса, из-за гор, кишки, месиво, хардкор. (Берсерк ТВ-2)
Я хоть и кодил когда то давно давно на плюсах но перешел на дельфи, а после еще и на шарп.
Я наоборот с дельфи на плюсы перелез потом на D, но это только для своих pet проектов, на работе я на Java, Kotlin (backend) пишу и сейчас учу Scala.
ЦитатаOrdan ()
И вот, я часто слышу от плюсовиков о проблемах с памятью и никогда не понимал, что за ужасы там творятся то)
Да нет там никаких ужасов, у новичков часто бывает так, что выделят память и не освобождают, либо удалили объект, а потом в другом месте пытаются получить доступ к нему (хотя это не только у новичков, таки ошибки даже в крупных проектах встречаются, такие как blender), просто нужно уметь работать с память и иногда пользоваться санитайзерами. Сейчас в C++ предпочтительная модель работы с памятью - это RAII и она, в общем то, решает большинство проблем связанных с памятью.
у новичков часто бывает так, что выделят память и не освобождают,
Xakep, у меня такое было. Но это было когда я долго польовался c# и java и отвык освобождать память. Это из-за этих языков можно в си и c++ с памятью накосячить. Из-за этого ты не обращаешь внимание на память вообще. Но если постоянно писать на плюсах, то проблем быть не должно. Хотя фиг знает. Вон в gnome была утечка памяти, хотя проект не дилетанты пишут скорее всего.
Секс с роботами — это интересно, но роботов хочется больше и чаще, чем секса)
Цитатаpixeye ()
Нормальное такое желание. Роботяны и прочая хренота просто отмазы
Нормальное для этого организма, потому что в него это заложено генетически. Те, кто не имел "нормальных желаний", не оставили потомства. Но это было актуально в древности, когда не было технологий и перенаселённости.
Я должен быть выше этого, иначе как я вообще могу считать себя разумным? Просто голая обезьяна, управляемая инстинктами и совсем немножко оптимизируемая знаниями... Хочется принимать взвешенные и обоснованные решения, а не следовать своим эмоциям и инстинктам. Иначе какой смысл в разумности?..
(Хм, может ИИ до сих пор нет, т.к. мы пытаемся создать чистый разум, а не тонкую надстройку над тупым животным?.. Всё больше склоняюсь к этой идее, но боюсь, как бы не оказаться в ловушке "животное есть, а разума так и нет".)
Цитатаpixeye ()
Почему ты позволяешь себе неуважать чужое ремесло
Ты не понял, я очень даже уважаю художников, которые мне нравятся. Вот в этой фразе:
ЦитатаTimKruz ()
какое же я ничтожество, даже такую бесполезную фигню сделать не могу
Речь шла про то, что я не могу лично для себя поставить рисование превыше всего, дабы заниматься им постоянно.
Если бы я мечтал именно стать художником, я бы им и стал. Но рисование для меня лишь инструмент "добычи приятных картинок", очень неудобный и неэффективный — я не хочу тратить на него время, силы и нервы, когда поисковые машины с той же задачей справляются в разы лучше, чем мои руки.
Нет, разумеется, рисовать самостоятельно — круто, но требуемые затраты на получение необходимого уровня навыка слишком высоки относительно преимуществ владения этим навыком (субъективно). Что могут художники, кроме как рисовать?..
С тем же успехом я "не уважаю" писателей, хотя сам иногда пишу и, кажется, пишу неплохо. Просто я не вижу пользы от художественной литературы, особенно с учётом переполненности современного рынка.
Цитатаpixeye ()
Нормальная реакция для человека обесценивать то, что ему нравится, но получить не может. Мозгу так проще.
Эт да, но почему-то некоторые вещи я не могу обесценить. Хотел бы, да не могу. В одних случаях думаю "ну и ладно, не больно-то и нужно", а в других — "если отступлюсь, то предам самого себя"...
Цитатаpixeye ()
Искренне желаю тебе найти сил разобраться во всём этом.
Спасибо, хотя мне б найти сил на конструктивную деятельность, от самокопания я уже устал) Все эти мои мечты про ИИ вполне достижимы (если не уходить в философию), но нужно делать конкретные шаги, а не валяться в направлении цели и мечтать о её достижении... Впрочем, знать бы ещё, куда эти шаги делать.
Цитатаafq ()
ты же вроде писал что сделать файлы и каталоги легко. Я думал что ты это в первую очередь сделаешь. А ты за четыре часа сделал echo и exit.
Ух... Если тебя это так волнует, я потратил 2 часа 16 минут (параллельно играя в игру), и сделал не "echo и exit", а синглтон "TGameConsole", который принимает пользовательский ввод, разбирает и анализирует команды, список которых легко пополнить. Без этого обработчика смысла в дальнейшей работе не было бы, ибо даже если написать класс, работающий с файловой системой, испробовать на практике его не получится (без временного кода).
По мере создания класса, работающего с "файловой системой", я бы мог испытывать его в роли игрока, а не тестовыми вызовами. Я не говорю, что это удобнее или проще, но это нагляднее и мне так нравится больше — код начинает выполнять свою задачу задолго до того, как будет дописан до конца. Получается "игра с кодом", а это приятнее, чем делать всё в уме.
Цитатаafq ()
Тебе же советую учить какой нибудь язык раз в год. Ну или не раз в год, а хотя бы ещё один язык, чтобы мышление менялось.
Я перепробовал множество ЯПов (как минимум писал программки для усвоения), но в конечном итоге понял, что нет особого смысла знать много языков. Они, по большей части, отличаются только синтаксисом, набором библиотек, фичами и багами компиляторов, да основной платформой. Но когда твоя платформа — винда, фичи и баги компиляторов тебя не волнуют, библиотеки тебе зачастую не нужны, а синтаксис нравится какого-то конкретного вида, не вижу никакого смысла во владении десятком ЯПов одновременно.
И потом, ЯП — это инструмент решения задач, а задач у меня тупо нет.
Всегда, пытаясь освоить новый ЯП, думал в стиле "щас чёт крутое запилю!" Время шло, а крутых идей, которые я мог бы реализовывать, на ум не приходило. В итоге бросал и возвращался к своему обычному режиму "покодить что-нибудь на паскале раз в полгода от скуки".
Скажем, изучал Java, чтобы освоить разработку под Android. Но осознал, что мне нечего делать именно на смартфоны. Для рынка? Он переполнен. Бросил Java.
Хотя чаще я всё-таки сталкиваюсь с тем, что не только я не знаю, чё делать, но и гугление не даёт ничего про реализацию моих идей. По крайней мере, простым и понятным языком, а не абстрактными формулами.
Цитатаafq ()
для терминала выбирать лучше команды линукса, потому что врядли хакер будет пользоваться терминалом ms-dos.
Меня заинтересовала идея игровой симуляции работы с ПК, а не симулятор хакера)
Я вообще хотел бы создать свой набор команд, чтобы игроку было интересно изучать что-то новое, а не тупо содрать всё с реальной консоли. Зачем играть в игру про терминал, если я могу открыть настоящий терминал?
Цитатаafq ()
вот смотри что у меня реализовано
Эм... А где хлебные крошки? В линуксе же есть: user@comp:~/user/documents/books$ Или как там, не суть. Мне кажется, это очень важная фича.
Цитатаafq ()
Всегда сложно понять что автор имел ввиду написав несколько строк кода.
Плохой автор, значит)
ЦитатаXakep ()
Ну фиг знает на счет ассемблера, это дикий лоу левел и 10 строк уже могут быть абсолютно не понятными, если писал его не ты, плюс условные и безусловные переходы вместо ветвлений и циклов очень сильно усложняют навигацию по коду (хотя может это и решается с помощью макрасов?).
Глянь fasm, там тема с макросами дошла до того, что можно программы писать только из макросов, без инструкций ЦП.
И если кодить на ассемблере под Windows, то там в основном куча вызовов библиотечных процедур (invoke имяпроц парам1, парам2, парам3), хоть это и не избавляет от необходимости понимания работы процессора и ассемблера.
ЦитатаXakep ()
естественно, если ты не знаком с функциональной парадигмой, все что будет написано будет не понятно, хоть как ты обзови переменные
Если не ошибаюсь, функциональная парадигма отличается отсутствием классических переменных — т.е. все результаты куда-то передаются, а если и хранятся, то без изменений. Из-за этого код выглядит так: v = Func1(Func2(Func3(Func4(1, 2, 3)))); Т.е. "Func4 сделала что-то с 1, 2 и 3, передала ответ в Func3, которая ... в Func1, которая сохранила результат работы в v". По-моему всё просто.
Так что проблема опять же сводится к названиям) Вот что это за Func4 и почему она получает 1, 2 и 3? Кто знает...
Или языки типа Forth. На них можно писать как угодно, но обычно пишут кучей сокращений из двух-трёх букв, и это нереально усложняет понимание кода. Читал что-то типа "программист разговаривает с Фортом на собственном языке", и в примерах там были читабельные имена, а реальный код... Далёк от этого.
ЦитатаXakep ()
все раздроблена настолько мелко и не пойми как взаимодействует друг с другом.
Оглавление, оглавление надо делать) И по папкам раскладывать по смыслу.
ЦитатаXakep ()
можешь не понимать, но тебе это решение по умолчанию может показаться красивым
Ну не знаю, я не могу посчитать "красивым" то, что не могу понять... Возможно, я вижу красоту в работе каких-то систем, а внешняя сторона (синтаксис, именование, дробление) только обёртка; однако в плохой обёртке работу этих систем становится трудно разглядеть.
На счёт возможности писать понятно, но некрасиво — не спорю, но обычно так получается с маленькими участками кода, в которых грязь не мешает восприятию)
ЦитатаXakep ()
Просто не пользуйся не нужным мусором и пиши в своем стиле
Легко сказать. Трудно пересилить нежелание делать что-то вручную)
ЦитатаOrdan ()
И вот, я часто слышу от плюсовиков о проблемах с памятью и никогда не понимал, что за ужасы там творятся то)
Там вроде любая более-менее сложная задача решается через динамические структуры данных, т.е. через указатели. Когда в других ЯПах есть особые структуры или классы для работы с такими данными, сишникам приходится писать всё вручную.
Раньше я тоже пробовал пилить свои структуры данных на указателях, получалось нормально (список, стек, даже дерево вроде), но потом надоело каждый раз с нуля это делать и теперь пользуюсь TList или просто массивами записей. Нет у меня таких задач, которые нужно было бы оптимизировать указателями.
ЦитатаOrdan ()
Когда ты будешь делать другие проекты твой навык кодинга, всяко выше чем когда делал предыдущий проект и старый код будет для тебя просто мусором.
Про навык согласен, но если уж приходится часто переписывать, лучше один раз написать и использовать. Когда навык поднимется значительно — вернуться и переписать лучше.
Но, окей, это всё абстрактные размышления, так можно вечно обсуждать)
Т.е. "Func4 сделала что-то с 1, 2 и 3, передала ответ в Func3, которая ... в Func1, которая сохранила результат работы в v". По-моему всё просто.
ну если в кратце то да, но там все же есть различные понятия такие как fold, map, filter, reduce, transduce плюс монады, паттерн матчинг итд. Лично я когда входил в ФП ничего не понимал по началу, было ощущение, как будто я впервые сел за программирование.
ЦитатаTimKruz ()
Глянь fasm, там тема с макросами дошла до того, что можно программы писать только из макросов, без инструкций ЦП. :D
прикольно, может какнить попробую его, действительно - это совершенно не то что я привык видеть в ASM'е.
Зачем играть в игру про терминал, если я могу открыть настоящий терминал?
TimKruz, потому что в этой игре ты можешь взламывать компьютеры, перехватывать данные, вторгаться в сети и быть неуловимым. А то что ты написал, так это пойди да убей всех, не можешь, вот поэтому и играй в игру шутер. Тоже самое и здесь, не хочешь заниматься криминалом, можно на симуляторе поиграть в хакера. Этот симулятор, который я делаю, он реальней, чем игры такого типа. Обычно в играх ты используешь какую нибудь программу подбор пароля к сервису. Такой способ быстро бы засекли. Самый логичный способ это изучить исходники программы, найти уязвимость и использовать 0-day уязвимость к сервису. Но моя игра не будет на 100% реальной. Потому что я сам о взломе не много знаю. Это я написал для того, чтобы можно было показать этот текст, что я не учу взламывать других, это всего лишь игра. А симулятор, это не эмулятор хакинга, а симулятор.
Добавлено (28 Мая 2019, 18:15) ---------------------------------------------
Цитата
прикольно, может какнить попробую его, действительно - это совершенно не то что я привык видеть в ASM'е.
Xakep, а ты где хочешь тестировать в линуксе или windows? Там есть примеры использования в линукс. Эти макросы ещё нужно изучать, проще уже самому написать. С макросами он наверное будет похож на basic. Я единственно что написал рабочее на асме, без книг и туториалов, так это конвертер нескольких чисел в бинарный эквивалент. Можно написать несколько чисел, и он на каждой строке напишет бинарный код. Писал для 32 разрядной системы. Но он и в 64 разрядной скомпилируется. Компилятор nasm, синтаксис intel. https://github.com/xverizex/bits
Добавлено (28 Мая 2019, 18:16) --------------------------------------------- А не, не единственное, я ещё на асме писал сетевой сервер, не помню что он делал, вроде бы только до echo добравлся. Но он парсил файл настроек вроде.