thumbnail of how.jpeg
thumbnail of how.jpeg
how jpeg
(220.87 KB, 1600x1091)
thumbnail of skala i les.jpg
thumbnail of skala i les.jpg
skala i les jpg
(417.5 KB, 1920x1080)
thumbnail of gravyura flammariona.jpg
thumbnail of gravyura flammariona.jpg
gravyura flammariona jpg
(224.52 KB, 770x600)
thumbnail of shar vnutri.jpeg
thumbnail of shar vnutri.jpeg
shar vnutri jpeg
(318.64 KB, 846x1200)
Недавно я пытался разработать ██████, а в итоге одна баночка вдребезги.
Разрабатывать это так сложно, но я кажется понял кое-что.
Очень маленькие проекты (простые скрипты, литой попрыгнучик, ручка для ящика) можно делать и в автоматическом порядке, мозг сам как-нибудь итеративно найдёт результат.
В то время как для больших проектов надо придумывать архитектуру, чертёж, темплейт, 3D-модель, XD-модель, абстрактную модель. В случае сложного ПО это архитектура, надо продумать её досконально, добавить путей для расширения и изменения. В случае машины надо сделать что-то типа чертежа, где указан список взаимозаменяемых деталей и как их характеристики влияют на характеристики других деталей. То есть, если нам нужен вал диаметром 5 мм, но в некоторых нетрущихся местах он может быть и до 10 мм, то зачем выбрасывать уже существующий ресурс, подходящий таким характеристикам? Единственное, что, машины разрабатывать лучше в специальном ПО, чтобы оно автоматически расчитывало массу, тензор/моменты инерций, габариты отдельных секций. Они могут повлиять на характеристики других деталей, например, минимальный момент сил, который может развиваться двигатель. Также в случае машин следует предусмотреть пути для дебаггинга, чтобы дебаггинг был лёгок и доступен. Пути для расширения могут понадобиться разве что в очень больших машинах или целых зданиях. В случае пректирования в общем смысле физических предметов надо ещё учитывать то, как он будет создаваться. Если надо спаять что-то в узком месте, то надо просчитать порядок действий так, чтобы паяльник поместился.
За свою жизнь я сделал где-то ноль ███████. Ноль это всё-равно, что нольдесят ноль. Нольдесят ноль это всё-равно, что нольсот нольдесят ноль. Нольсот нольдесят ноль это всё-равно, что ноль тысяч нольсот нольдесят ноль. Ноль тысяч нольсот нольдесят ноль это всё-равно, что нольдесят ноль тысяч нольсот нольдесят ноль. Нольдесят ноль тысяч нольсот нольдесят ноль это всё-равно, что нольсот нольдесят ноль тысяч нольсот нольдесят ноль. Нольсот нольдесят ноль тысяч нольсот нольдесят ноль это всё-равно, что ноль миллионов нольсот нольдесят ноль тысяч нольсот нольдесят ноль. Если X ∈ множество созданных мною ███████, то X ∈ ∅, то есть X ∈ {}, потому что это пустое множество, потому-что его количетсво элементов равно нулю или, например, нулю миллионов нольста нольдесяти нулю тысяч нольста нольдесяти нулю.

И вообще, может мне Лайси полностью исполосовать и преобразовать во что-то другое? Вот пишу это и чувствуют, что это неверное решение. Мне понравился хаскелль, но я его тольком не попробовал. Функциональный язык, красиво всё выглядит. Вряд ли Лайси смог бы стать функциональным языком. Но что в нём делает метапрограммирование? Серьёзно, почему темплейты обозначаются специальной конструкцией с кейвордом template? Почему нельзя просто взять и сделать в аргументах выбор из допустимых типов? Это было бы красивее. Но я не знаю, стоит ли избавляться от метапрограммирования. Не хочу.
Кстати, Лайси вообще нужен больше для LDI — Laisi Default Libs — набор библиотек разного назначения. Почему бы ту же math нельзя было бы сгенерировать на произвольный язык программирования условным скриптом на питоне? Взял бы, указал допустимые типы и сгенерировались бы функции max_int_int, max_int_float, max_float_int, max_float_float и все-все-все. А для C++ создался бы сразу template. Но если так уходить, то со временем эти скрипты переписывались бы и переписывались бы, образовалась бы библиотека с типами для ЯП, там операнды, типы, экспрешионы, инструкции. И получился бы просто новый ЯП. Который транслировался бы просто в LLVM IR.