>>>> Что ты называешь "нормальным" ООП? Как в java? Как в C++? Как
>>>> в Haskell? Как в gtk? Какой из ООП нормален?
>>> ООП с наследованием, где методы и свойства наследуются автоматически.
>> Deref/DerefMut тебе в помощь.
> И где тут автоматическое наследование? Всё же руками приходится делать, не?Написать метод deref(&self) -> &ParentType? Да надо.
>>Python -- это синтаксический сахар над интерпретатором, позволяющий дёргать те или иные функции интерпретатора.
> Нет. поскольку питон - язык интерпретируемый.
И что? Интерпретатор -- это по сути API, с кучей методов. Python -- это по-сути read-eval-print в цикле, который в процессе evel дёргает этот самый API. Таким образом python как язык -- это синтаксический сахар над тем API.
>> Если ты нашёл свой комп на помойке, то что ты вообще делаешь в разработке ПО? Не, ну реально.
> Так и запишем - "вход только для потреблятелей".
Отказ от первого пня в пользу i7 не сделает из тебя потребляти. Так же как отказ от i7 в пользу первого пня не позволит тебе прекратить быть потреблятью.
> Так и запишем - "не смогли реализовать хранение отладочной информации во внешних
> файлах и подгрузку по мере надобности, даже имея перед глазами готовую
> и отполирванную реализацию от Microsoft".
Гента смогла. Поэтому я ей и пользуюсь.
> Нет, я и о разработке, и о пользовании. Потому что разработка включает
> в себя использование. И пересобирать мир для этого не надо. Проприетарасты
> это поняли и реализовали первыми, почему до адепты СПО страдают фигнёй,
> пересобирая мир, мне тоже понятно: потому что в отличии от проприетарастов,
> которым клиенты платят деньги в том числе за сервис, у спошников
> каждый сам за себя и некоторым даже бинарные пакеты через спонсируемый
> корпорациями CI распространять западло.
Не, просто у пропиерастов, как правило, нет опции пересобрать. Пересобрать gtk с assert'ами? Заинжектить код в gtk, чтобы посмотреть, что из этого выйдет? Отключить/подключить опциональные депендансы? Сменить версии библиотек, уйти от stable, уйти от unstable и поставить себе последний коммит из git репо, который даже тегом не помечен, и поэтому идентифицируется лишь хешом?
> По-моему все пакетные менеджеры, которые я встречал, глубокь ущербны.
Ну если в философию нырять, то да. Они все ущербны. dll-hell нерешённая проблема, а все попытки её решить -- костыли, а не решения.
> Именно поэтому надо выпилить стейбл и бету - они развращают разработчиков. Если
> что-то сломалось в пакетах в результате запланированного изменения API, значит это
> проблема пакета.
Да. Но вот у меня крутится сайт на rust'е -- я его поднимал год назад под проведение психологического эксперимента. Он не нужен уже, но по инерции крутится. И если мне сейчас приспичит что-то там поменять, то я поменяю и пересоберу его, без того, чтобы нырять на несколько часов в код, обновляя его, обновляя все депендансы и всё остальное. Причём соберётся как http-сервер, так и websockets сервер, так и wasm модуль (ещё через emscripten собранный). Наверное, это признак развращения, но это удобно. Это значит, что я могу не трогать сайт, откладывая все крупные изменения, собирая их в TODO лист, с тем чтобы если придёт время менять сайт, то я сделал бы это всё за раз.
> В отличие от раста в питоне есть 2to3 и изменения
> косметические, пофиксить элементарно, в расте скорее всего либа так и останется
> непофикшенной, то есть фактически исчезнет, соответственно будет ещё один аргумент в
> пользу "в гробу я видал этот хипстерский раст". Поэтому фиксить несовместимости
> с самой новой версией нужно как можно раньше и пользоваться преимуществами
> nightly.
Это хорошо звучит в теории, а на практике очень удобно иметь долю свободы, чтобы цикл разработки одной программы не был бы жёстко прибит гвоздями к циклу разработки другой программы.
> Я имею в виду что со CLangом не нужен десяток тулчейнов, нужен
> 1 шланг + стандартная библиотека для платформы. Один и тот же
> шланг строит и под винду используя MinGW, и под винду, используя
> msvcrt, и под линукс x86, используя мюсл, и под ведро, и
> под карты NVidia, и под карты AMD и под айфоны. Почему
> так не сделано для раста?
Потому что не всё сразу. Вот реально, что важнее, чтобы rust компилировал бы, или чтобы он компилировал быстро? Или чтобы он использовал бы одну и ту же сборку llvm под все платформы? Я ещё раз тебе говорю: возможность собрать rust на одном системном llvm есть. Но не в rustup.
Не, ладно бы rust закончил бы своё развитие, и при застрял бы в том состоянии, в котором он сейчас находится. Но это ведь не так, развитие продолжается, в том числе и развитие оптимизатора, то есть взаимодействие с llvm изменяется со временем. Вносить в систему на этом этапе дополнительные сложности, значит во-первых тратить на это время сейчас, когда есть более важные задачи, во-вторых, создавать себе потенциально проблем потом, когда выснится, что эти дополнительные сложности были решены субоптимальным образом, и теперь не позволяют внести какие-то изменения в rust, и поэтому их надо переделывать.
