Здравствуйте, netch80, Вы писали:
N>А ты не видишь, что одно другому противоречит у тебя?
У меня — это у кого? Может быть ты глаза разуешь, и прочитаешь наконец-то, что я как раз за инты и против использования мелких типов только ради "доменного дизайна"?
TB>>Я знаю, как в Ada, я на ней даже пару программ писал. Но это вообще даже близко не мейнстрим.
N>"Не мейнстрим" к чему тут вообще? N>Разве тяжело сделать аналогичное для C++ или Rust? N>По-моему, они уже давно есть в десятках вариантов для каждого.
Это будет структура с перегруженным оператором, при этом её, в отличие от чисел, нельзя будет просто так выводить на экран, тебе надо будет везде таскать трейты Numeric+Debug, первый чтоб просто иметь то, что имеют обычные числа, второй чтоб можно было печатать, и я не уверен что структура в 4 байта не будет пихаться везде по ссылке.
TB>>Почему бы просто не взять с самого начала сраный инт и не морочить голову?
N>Возьми. Я вот и удивляюсь, почему ты использовал u8 вместо int. У тебя структура с ними? Ну так проконвертируй в момент извлечения.
Дальше разгорелся срач, я привёл пример с шахматной доской 256х256, и спросил, реально ли они ради дебильной идеи сраных доменов будут использовать u8, понимая, что тривиальные операции будет делать крайне геморройно, и они сказали что да.
Я за инты, понимаешь? Я против u8. А фанатики доменного бреда говорят что инты это Primitive Obsession
N>Мы все работаем с ними.
Чушь, от падающего приложения в 99% случаев никто не ощутил никакого ущерба.
N>Я не увидел этого прямым текстом, ну да ладно.
Прочитай тему, перестань обвинять меня в поддержке того, против чего я прямым текстом выступаю, перестань сношаться в глаза, что я могу посоветовать.
N>Но как тогда ты будешь разбираться с тем, что на до чёрта современных платформ иногда нужен long = i64, но он сильно дороже, чем i32? Будешь пытаться обобщать всех до размера iptr?
Это какие, например? Только не надо про x86, пожалуйста.
N>А знаковость/беззнаковость, её тоже обобщим?
Беззнаковость почти никогда не нужна. Если ты думаешь, что тебе нужна беззнаковость только потому, что тебе кажется, что у тебя тут никогда не будет отрицательных чисал — то перечитай тему с самого начала, что я думаю про доменно-ориентированный идиотизм.
N>А 3-4 современных разных типа float?
Есть f32, f64
N>Посмотрел. Насколько я понял, выбор i32 тут происходит из i32 в структуре заголовка BMP, а значит, внутри библиотеки не будет проблем типа "значение не влезло в сгенерированный заголовок".
Таки u32. Ну и делать кривой интерфейс ради каких-то особенностей реализации — это говнокод.
TB>>Нормальный человек использует инт.
N>Которого нет в Rust.
Там есть i32, который по умолчанию выбирается, если по контексту не удалось явно определить тип, видимо это намекает, что он должен быть "дефолтным" интом. Хотя лучше б взяли isize, чтоб консистентно с векторами было.
TB>>А что я тогда выигрываю? Я написал сложную формулу с векторами и опечатался. Потом я применил крутую безопасную либу, и написал ту же формулу, но вместо векторов везде подставил P-ZeroPoint, и снова опечатался.
N>Опечатался в чём?
А формуле, оперирующей векторами.
TB>> Разница в том, что я написал менее читаемую строчку, но не получил никакого выигрыша ни в надёжности ни в скорости создания продукта.
N>Получил выигрыш.
Получил проигрыш.
N>Я не знаю, как в твоём домене
Тогда зачем отстаиваешь заведомо кривую реализацию паттерна, если не знаешь, как там?
Наверное вектор и матрицу действительно лучше отделить на этапе компиляции, потому что одно и другое никак не взаимозаменяемо. А вот точку и вектора отделать бесполезно, есть куча формул в алгебре, где это одно и то же.
N>Вообще-то тебе там никто не мешает размер сразу привести к isize.
Вообще-то
1. Легко забыть это сделать, ведь компилятор ничего не скажет, а потом программа упадёт.
2. Подход руста вынуждает весь код превращать в бесконечную кашу из "as isize", при этом ради чего? Чего эти идиоты сразу не взяли isize?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
N>>А ты не видишь, что одно другому противоречит у тебя?
TB>У меня — это у кого? Может быть ты глаза разуешь, и прочитаешь наконец-то, что я как раз за инты и против использования мелких типов только ради "доменного дизайна"?
Это я прочитал, нет проблем. Я считаю противоречием то, что при этом ты считаешь, что для этих мелких типов подход типа u8*u8 -> u8 является самым осмысленным.
Ну вот не могу я это свести в единую непротиворечивую концепцию.
TB>>>Я знаю, как в Ada, я на ней даже пару программ писал. Но это вообще даже близко не мейнстрим.
N>>"Не мейнстрим" к чему тут вообще? N>>Разве тяжело сделать аналогичное для C++ или Rust? N>>По-моему, они уже давно есть в десятках вариантов для каждого.
TB>Это будет структура с перегруженным оператором, при этом её, в отличие от чисел, нельзя будет просто так выводить на экран, тебе надо будет везде таскать трейты Numeric+Debug, первый чтоб просто иметь то, что имеют обычные числа, второй чтоб можно было печатать, и я не уверен что структура в 4 байта не будет пихаться везде по ссылке.
Мелкие структуры размером до 1-2 регистров процессора, если в них нет элементов с особым поведением, в современных (>= 30 лет) C ABI передаются по значению. Rust ещё новее, так что должен тоже. "Таскать везде" Numeric+Debug — разве это сложно? Просто пометить соответствующим образом? Тут упоминали std::num::Wrapping, там уже сделано. Если какие-то мелкие детали недоделаны — Rust бурно развивается, можно пожаловаться (если не менять уже принятые основы, как ты пытался).
TB>А я удивляюсь, почему ты долбишься в глаза
[...]
TB>Я за инты, понимаешь? Я против u8. А фанатики доменного бреда говорят что инты это Primitive Obsession
Тогда это ты долбишься в глаза. Потому что я объяснил, что я в пределах "доменного бреда" за range(0..255), но против явного u8.
И вообще, хоть мы и в flame.comp, но мне не нравится такая лексика ;\
N>>Мы все работаем с ними. TB>Чушь, от падающего приложения в 99% случаев никто не ощутил никакого ущерба.
Чушь тут твои слова. Ущерб только по отчётам всяких статистических организаций идёт на десятки миллиардов.
TB>Прочитай тему, перестань обвинять меня в поддержке того, против чего я прямым текстом выступаю, перестань сношаться в глаза, что я могу посоветовать.
Это я тебе должен посоветовать остановится, подумать и разобраться, чего же ты хочешь.
N>>Но как тогда ты будешь разбираться с тем, что на до чёрта современных платформ иногда нужен long = i64, но он сильно дороже, чем i32? Будешь пытаться обобщать всех до размера iptr? TB>Это какие, например? Только не надо про x86, пожалуйста.
Что именно не надо про x86? И который x86? Я уже не понимаю, что ты называешь этим. Если в хромой виндовой терминологии где "x64" = x86-64, то есть масса вполне живого embedded и полу-embedded на ARM/32. У меня такая платформа недавно была в целевых, и наверняка буду к этому возвращаться.
N>>А знаковость/беззнаковость, её тоже обобщим? TB>Беззнаковость почти никогда не нужна. Если ты думаешь, что тебе нужна беззнаковость только потому, что тебе кажется, что у тебя тут никогда не будет отрицательных чисал — то перечитай тему с самого начала, что я думаю про доменно-ориентированный идиотизм.
Для размеров контейнеров я согласен. Но вот сейчас работаю с протоколом, где seqnums — 16-битные беззнаковые и потому достаточно быстро оборачиваются по кругу.
N>>А 3-4 современных разных типа float? TB>Есть f32, f64
А также f16-ieee, bfloat16, decfloat32, decfloat64... и даже тут есть люди, которые активно работают с ними.
Но даже если бы были только f32, f64 — ты бы точно так же шипел "я за флоаты и против f32" когда ты бы решил, что тебе не хватает точности f32 и надоело кастить к f64?
N>>Посмотрел. Насколько я понял, выбор i32 тут происходит из i32 в структуре заголовка BMP, а значит, внутри библиотеки не будет проблем типа "значение не влезло в сгенерированный заголовок". TB>Таки u32. Ну и делать кривой интерфейс ради каких-то особенностей реализации — это говнокод.
Ну я их и не защищал. Попытался пояснить, почему это имеет отношение к их решению.
TB>>>Нормальный человек использует инт.
N>>Которого нет в Rust.
TB>Там есть i32, который по умолчанию выбирается, если по контексту не удалось явно определить тип, видимо это намекает, что он должен быть "дефолтным" интом. Хотя лучше б взяли isize, чтоб консистентно с векторами было.
Про "лучше isize" я согласен на 234%. Ну если это не извращение типа MIPS/64.
TB>>>А что я тогда выигрываю? Я написал сложную формулу с векторами и опечатался. Потом я применил крутую безопасную либу, и написал ту же формулу, но вместо векторов везде подставил P-ZeroPoint, и снова опечатался.
N>>Опечатался в чём? TB>А формуле, оперирующей векторами.
Как и почему?
TB>>> Разница в том, что я написал менее читаемую строчку, но не получил никакого выигрыша ни в надёжности ни в скорости создания продукта. N>>Получил выигрыш. TB>Получил проигрыш.
В общем случае — выигрыш, когда у тебя формула посложнее или расчёты более громоздкие.
N>>Я не знаю, как в твоём домене
TB>Тогда зачем отстаиваешь заведомо кривую реализацию паттерна, если не знаешь, как там?
Потому что стараются покрыть таки статистически максимум, чем каждый специфический домен.
Но с математикой я работал (и даже образование у меня оттуда), так что я очень близко ходил к твоему домену, и проблемы подстановки не того типа знаю.
Ты, кстати, не прочитал, что я ниже писал, сразу ринулся возражать. Это плохо.
TB>Наверное вектор и матрицу действительно лучше отделить на этапе компиляции, потому что одно и другое никак не взаимозаменяемо. А вот точку и вектора отделать бесполезно, есть куча формул в алгебре, где это одно и то же.
Тебе так кажется. А авторы numpy тебе ответят, что вектор это матрица с размером 1 по одному из измерений, скаляр — вообще матрица 1*1, а 2-dimensional array это матрица, и "есть куча формул в алгебре" (и применений) где это одно и то же.
Они просто пошли чуть дальше, чем ты. Но на принципиальном уровне то же самое — "художник так видит", а проблемы пользователей волнуют слабо.
N>>Вообще-то тебе там никто не мешает размер сразу привести к isize.
TB>Вообще-то TB>1. Легко забыть это сделать, ведь компилятор ничего не скажет, а потом программа упадёт.
Ты ж сам говоришь, что от падения проблем нет?
Ну и чтобы isize не влезло в i32, надо иметь ну очень большие размеры.
TB>2. Подход руста вынуждает весь код превращать в бесконечную кашу из "as isize", при этом ради чего? Чего эти идиоты сразу не взяли isize?
Здравствуйте, netch80, Вы писали:
N>Это я прочитал, нет проблем. Я считаю противоречием то, что при этом ты считаешь, что для этих мелких типов подход типа u8*u8 -> u8 является самым осмысленным. N>Ну вот не могу я это свести в единую непротиворечивую концепцию.
Почему? Если ты просто используешь инты, то никаких проблем. А мелкие типы просто не надо использовать, кроме низкоуровневой фигни.
N>Тогда это ты долбишься в глаза. Потому что я объяснил, что я в пределах "доменного бреда" за range(0..255), но против явного u8.
Давай говорить про реальные языки. В русте для поддержки доменного бреда для диапазона 0..255 берут тип u8, о чём мне хипсторы прямо сказали в сраче про беззнаковые индексы. Про потенциальные проблемы они сказали "пиши свой приватный метод с кастами на каждый чих, чтобы абстрагироваться и воспринимать это как чорный ящег".
N>И вообще, хоть мы и в flame.comp, но мне не нравится такая лексика ;\
Давай ты не будешь меня обвинять в поддержке того, что я прямым текстом осуждаю уже 5ю страницу. Иначе это разговор со слепоглухим.
N>Чушь тут твои слова. Ущерб только по отчётам всяких статистических организаций идёт на десятки миллиардов.
Ущерб от невыпущенной в срок программы, потому что отдел разработки не сумел верифицировать перед компилятором какой-то хитрый случай хитрого алгоритма, ещё выше.
N>Это я тебе должен посоветовать остановится, подумать и разобраться, чего же ты хочешь.
Изначально я хотел узнать название антипаттерна, которым болеет руст-коммьюнити и автор библиотеки std::chporno.
N>Что именно не надо про x86? И который x86? Я уже не понимаю, что ты называешь этим. Если в хромой виндовой терминологии где "x64" = x86-64, то есть масса вполне живого embedded и полу-embedded на ARM/32. У меня такая платформа недавно была в целевых, и наверняка буду к этому возвращаться.
Ну сорян, есть платформы, где размер указателя вдвое превышает размер слова, и там даже ллвм непонятно что предоставляет. Думаю, со временем будет какая-то унификация. Нестандартные отрицательные числа же в С++ победили наконец-то к 20 году.
N>Для размеров контейнеров я согласен. Но вот сейчас работаю с протоколом, где seqnums — 16-битные беззнаковые и потому достаточно быстро оборачиваются по кругу.
Это относится к работе с АПИ. Там выбора нет.
N>Но даже если бы были только f32, f64 — ты бы точно так же шипел "я за флоаты и против f32" когда ты бы решил, что тебе не хватает точности f32 и надоело кастить к f64?
Там нет такой проблемы, потому что либы как правило состоят из функций где все аргументы и результат одного типа, причём тип можно выбрать любой, поэтому просто изначально выбираешь нужный тип под свои потребности.
В случае с целыми типами когда каждый хипстор берёт свой собственный u32,usize,u8,i32 — просто затрахаешься всё кастить туда-сюда.
N>Про "лучше isize" я согласен на 234%. Ну если это не извращение типа MIPS/64.
Слава богу, пришли к какому-то консенсусу.
N>Как и почему?
Ну по запарке плюс с минусом перепутал, и две сущности вида (P-ZeroPoint) не вычел, а сложил. Толку тогда от такой "защиты"?
N>В общем случае — выигрыш, когда у тебя формула посложнее или расчёты более громоздкие.
Именно в сложной формуле вообще невозможно оперировать отдельно точками и отдельно векторами и приходится заранее все точки превращать в вектора при помощи (P-ZeroPoint), а потом писать точно такую же векторную формулу с точно такими же шансами на опечатку.
N>Тебе так кажется. А авторы numpy тебе ответят, что вектор это матрица с размером 1 по одному из измерений, скаляр — вообще матрица 1*1, а 2-dimensional array это матрица, и "есть куча формул в алгебре" (и применений) где это одно и то же. N>Они просто пошли чуть дальше, чем ты. Но на принципиальном уровне то же самое — "художник так видит", а проблемы пользователей волнуют слабо.
А там на этапе компиляции не отследить размер матрицы? Аааа, это ж питон. Ну так блин, это другая крайность.
TB>>1. Легко забыть это сделать, ведь компилятор ничего не скажет, а потом программа упадёт.
N>Ты ж сам говоришь, что от падения проблем нет?
Да, с моей стороны это всего лишь +1 одна итерация "прочитать лог и воткнуть каст ещё в то место". Просто и её могло бы не быть, если бы не это типобесие. Если бы целые везде были интами кроме редких случаев, то ряд случаев падения-по-переполненю бы исчез, и ни одного нового случая падения бы не появилось. Тогда почему так изначально не сделать?!
Ну и самое идиотское во всей этой истории, что всё это подаётся по соусом... повышения надёжности!!! То есть лишний источник падений добавили как раз те, кто за надёжность в ущерб скорости написания прототипа.
TB>>2. Подход руста вынуждает весь код превращать в бесконечную кашу из "as isize", при этом ради чего? Чего эти идиоты сразу не взяли isize?
N>Не знаю. Можешь попробовать спросить.
Дык я спросил в руст-коммьюнити. Мне сказали, что я ничего не понимаю в доменно-ориентированных типах. И я до сих пор ничего в них не понимаю.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, netch80, Вы писали:
N>Вот где, например, операция вида u8*u8->u16? Что, всегда писать расширение до u16 с последующим умножением (а компилятор должен обратно догадаться использовать команду косого умножения)? Дайте её в виде функции/метода. Почему это есть в Forth или в GCC builtins, но не в нормальном языке? (Для C++ были предложения, но не прошли.)
Здравствуйте, Слава, Вы писали:
С>Здравствуйте, netch80, Вы писали:
N>>Вот где, например, операция вида u8*u8->u16? Что, всегда писать расширение до u16 с последующим умножением (а компилятор должен обратно догадаться использовать команду косого умножения)? Дайте её в виде функции/метода. Почему это есть в Forth или в GCC builtins, но не в нормальном языке? (Для C++ были предложения, но не прошли.)
С>А может вы proposal напишете?
