Сообщение Re[6]: Carbon от 14.04.2024 11:26
Изменено 14.04.2024 11:34 Alekzander
Re[6]: Carbon
Здравствуйте, netch80, Вы писали:
N>И как именно они протекут?
Возьми какой-то реальный сценарий. Не знаю, "Мужик фотографирует кису и отправляет фотку в мессенджере". И посмотри, во что превратится жизнь, если ты слезешь с байтов. Отринешь проклятое наследие Си. Выберешь язык с типами-диапазонами, и с нуля всё напишешь.
Для начала, сколько цветов будет иметь у тебя пиксел? Как у Эппл, "тысячи цветов", "миллионы цветов"? Наверно, ты всё-таки возьмёшь цветовую модель. Скажем, RGB. Спросишь у производителя матрицы, сколько он даёт градаций на канал, и напишешь тип {r: 0..64, g: 0..64, b: 0..64} (когда я последний раз интересовался вопросом, аппаратные возможности моников были именно такие, а сенсоров ещё хуже). И вот с этим ужасом тебе придётся таскаться всю дорогу.
Сколько будет весить необработанная фотография 1920*1080? Ага, ты, конечно, в уме округлил до байтиков и радуешься. А ты попробуй как в суде присяжных: когда говорят, мол, вы должны игнорировать эту улику, она получена незаконно. Ведь твоя цель — мыслить без привязки к байтам.
Как получить данные? У тебя идёт от драйвера матрицы сплошной поток. И он, конечно, байтовый. Ты его остановишь и будешь перепаковывать в {r: 0..64, g: 0..64, b: 0..64}?
А как кису вывести на экран? Здравствуй, for { for {} } ? В случае байтов тебе, скорее всего, максимум, придётся порядок строк инвертировать при подготовке буфера. (Это зависит от "тараканов"). В лучшем случае — просто скопировать буфер целиком.
Короче, куда же ты денешься от байтов с подводной-то лодки.
N>Файл с данными это уже случай упаковки — в значительном смысле, тех самых тараканов нижнего уровня.
И что с того? Сериализация — не пример, из чего состоит работа чуть менее, чем полностью?
A>>Кстати. Просто мимоходом. Тебе не кажется, что range -50...+80 — это источник ошибок? Мина замедленного действия?
N>Не кажется. На один потенциальный случай, когда это мина замедленного действия, происходит несколько сотен других, для которых миной замедленного действия является, наоборот, попадание невалидных данных в переменные просто за счёт того, что их определение в виде int дало возможность сохранить такое значение.
Но хранятся-то реально данные всё равно в int'е (в реальном мире, где не изобрели чипы переменной битности). А ты просто предлагаешь абстрагироваться от этого. Во имя чистоты подхода.
По сути, если разобраться, всё сведётся к тому, чтобы нагрузить компилятор дополнительными проверками. Пока всё хорошо, да? Мины обезвредили.
И вот он, момент, когда бизнес-требования к диапазону выросли. Незначительно. Температура на Земле, как известно, снизу ограничена не -50, а чуть поменьше. -70 или -80, не помню точно. И ты приплыл. С кодебазой, где на каждом повороте аж компилятором проверяется, что температура не меньше -50. Ты даже последовательно модули обновить не сможешь. Только перевыкатывать всю систему целиком!
A>> Когда пляшут от байтиков, проблема диапазона возникает раз в несколько лет, и тогда берут тип экспоненциально большей размерности. И это не вечный процесс. Он прекращается, когда компьютеры становятся достаточно взрослыми. Тип общего назначения i128 уже никому не нужен.
N>То-то он присутствует в расширениях одновременно GCC и MSVC.
Ты, наверно, пропустил слова "общего назначения". Может и присутствует, но не как таковой.
A>> Там уже вектора, SIMD и прочее подобное роялит. С паскалевским же подходом вся твоя жизнь превратится в одну большую проблему диапазонов.
N>Вызываю обосновательную бригаду.
Лучше вызови поисковую бригаду, и поищи на Гитхабе примеры, где бы i128 использовался как тип общего назначения. Как ты понимаешь, мне мой тезис доказать примерами невозможно, а тебе опровергнуть примерами легко.
Никакие случаи "мини-вектор", "мини-структура" и т.п., конечно же, не принимаются.
А если окажется, что я ошибся, я просто заменю i128 на i256. Потому что изначальный тезис был — что процесс экспоненциального увеличения массово используемых типов — не бесконечен. Об этом легко забыть, если не следить за мыслью, не воспринимать ответ как единое целое, а механически дробить его на предложения и доковыриваться к каждому по отдельности (что я не слишком уважаю).
A>>К счастью, это тот случай, когда вместе со мной ошибаются и путают все мейнстримные создатели новых языков.
N>Не все, к счастью. Но, как известно, для каждой проблемы найдётся простое, ясное, неправильное решение. Точнее, неправильным является непредоставление диапазонных и прочих урезанных типов с автовыводом базового типа. Сами по себе i32 не виноваты, виновата чрезмерная опора на них.
Да, их тут тысячи! ©
N>И как именно они протекут?
Возьми какой-то реальный сценарий. Не знаю, "Мужик фотографирует кису и отправляет фотку в мессенджере". И посмотри, во что превратится жизнь, если ты слезешь с байтов. Отринешь проклятое наследие Си. Выберешь язык с типами-диапазонами, и с нуля всё напишешь.
Для начала, сколько цветов будет иметь у тебя пиксел? Как у Эппл, "тысячи цветов", "миллионы цветов"? Наверно, ты всё-таки возьмёшь цветовую модель. Скажем, RGB. Спросишь у производителя матрицы, сколько он даёт градаций на канал, и напишешь тип {r: 0..64, g: 0..64, b: 0..64} (когда я последний раз интересовался вопросом, аппаратные возможности моников были именно такие, а сенсоров ещё хуже). И вот с этим ужасом тебе придётся таскаться всю дорогу.
Сколько будет весить необработанная фотография 1920*1080? Ага, ты, конечно, в уме округлил до байтиков и радуешься. А ты попробуй как в суде присяжных: когда говорят, мол, вы должны игнорировать эту улику, она получена незаконно. Ведь твоя цель — мыслить без привязки к байтам.
Как получить данные? У тебя идёт от драйвера матрицы сплошной поток. И он, конечно, байтовый. Ты его остановишь и будешь перепаковывать в {r: 0..64, g: 0..64, b: 0..64}?
А как кису вывести на экран? Здравствуй, for { for {} } ? В случае байтов тебе, скорее всего, максимум, придётся порядок строк инвертировать при подготовке буфера. (Это зависит от "тараканов"). В лучшем случае — просто скопировать буфер целиком.
Короче, куда же ты денешься от байтов с подводной-то лодки.
N>Файл с данными это уже случай упаковки — в значительном смысле, тех самых тараканов нижнего уровня.
И что с того? Сериализация — не пример, из чего состоит работа чуть менее, чем полностью?
A>>Кстати. Просто мимоходом. Тебе не кажется, что range -50...+80 — это источник ошибок? Мина замедленного действия?
N>Не кажется. На один потенциальный случай, когда это мина замедленного действия, происходит несколько сотен других, для которых миной замедленного действия является, наоборот, попадание невалидных данных в переменные просто за счёт того, что их определение в виде int дало возможность сохранить такое значение.
Но хранятся-то реально данные всё равно в int'е (в реальном мире, где не изобрели чипы переменной битности). А ты просто предлагаешь абстрагироваться от этого. Во имя чистоты подхода.
По сути, если разобраться, всё сведётся к тому, чтобы нагрузить компилятор дополнительными проверками. Пока всё хорошо, да? Мины обезвредили.
И вот он, момент, когда бизнес-требования к диапазону выросли. Незначительно. Температура на Земле, как известно, снизу ограничена не -50, а чуть поменьше. -70 или -80, не помню точно. И ты приплыл. С кодебазой, где на каждом повороте аж компилятором проверяется, что температура не меньше -50. Ты даже последовательно модули обновить не сможешь. Только перевыкатывать всю систему целиком!
A>> Когда пляшут от байтиков, проблема диапазона возникает раз в несколько лет, и тогда берут тип экспоненциально большей размерности. И это не вечный процесс. Он прекращается, когда компьютеры становятся достаточно взрослыми. Тип общего назначения i128 уже никому не нужен.
N>То-то он присутствует в расширениях одновременно GCC и MSVC.
Ты, наверно, пропустил слова "общего назначения". Может и присутствует, но не как таковой.
A>> Там уже вектора, SIMD и прочее подобное роялит. С паскалевским же подходом вся твоя жизнь превратится в одну большую проблему диапазонов.
N>Вызываю обосновательную бригаду.
Лучше вызови поисковую бригаду, и поищи на Гитхабе примеры, где бы i128 использовался как тип общего назначения. Как ты понимаешь, мне мой тезис доказать примерами невозможно, а тебе опровергнуть примерами легко.
Никакие случаи "мини-вектор", "мини-структура" и т.п., конечно же, не принимаются.
А если окажется, что я ошибся, я просто заменю i128 на i256. Потому что изначальный тезис был — что процесс экспоненциального увеличения массово используемых типов — не бесконечен. Об этом легко забыть, если не следить за мыслью, не воспринимать ответ как единое целое, а механически дробить его на предложения и доковыриваться к каждому по отдельности (что я не слишком уважаю).
A>>К счастью, это тот случай, когда вместе со мной ошибаются и путают все мейнстримные создатели новых языков.
N>Не все, к счастью. Но, как известно, для каждой проблемы найдётся простое, ясное, неправильное решение. Точнее, неправильным является непредоставление диапазонных и прочих урезанных типов с автовыводом базового типа. Сами по себе i32 не виноваты, виновата чрезмерная опора на них.
Да, их тут тысячи! ©
Re[6]: Carbon
Здравствуйте, netch80, Вы писали:
N>И как именно они протекут?
Возьми какой-то реальный сценарий. Не знаю, "Мужик фотографирует кису и отправляет фотку в мессенджере". И посмотри, во что превратится жизнь, если ты слезешь с байтов. Отринешь проклятое наследие Си. Выберешь язык с типами-диапазонами, и с нуля всё напишешь.
Для начала, сколько цветов будет иметь у тебя пиксел? Как у Эппл, "тысячи цветов", "миллионы цветов"? Наверно, ты всё-таки возьмёшь цветовую модель. Скажем, RGB. Спросишь у производителя матрицы, сколько он даёт градаций на канал, и напишешь тип {r: 0..64, g: 0..64, b: 0..64} (когда я последний раз интересовался вопросом, аппаратные возможности моников были именно такие, а сенсоров ещё хуже). И вот с этим ужасом тебе придётся таскаться всю дорогу.
Сколько будет весить необработанная фотография 1920*1080? Ага, ты, конечно, в уме округлил до байтиков и радуешься. А ты попробуй как в суде присяжных: когда говорят, мол, вы должны игнорировать эту улику, она получена незаконно. Ведь твоя цель — мыслить без привязки к байтам.
Как получить данные? У тебя идёт от драйвера матрицы сплошной поток. И он, конечно, байтовый. Ты его остановишь и будешь перепаковывать в {r: 0..64, g: 0..64, b: 0..64}?
А как кису вывести на экран? Здравствуй, for { for {} } ? В случае байтов тебе, скорее всего, максимум, придётся порядок строк инвертировать при подготовке буфера. (Это зависит от "тараканов"). В лучшем случае — просто скопировать буфер целиком.
Короче, куда же ты денешься от байтов с подводной-то лодки.
N>Файл с данными это уже случай упаковки — в значительном смысле, тех самых тараканов нижнего уровня.
И что с того? Сериализация — не пример, из чего состоит работа чуть менее, чем полностью?
A>>Кстати. Просто мимоходом. Тебе не кажется, что range -50...+80 — это источник ошибок? Мина замедленного действия?
N>Не кажется. На один потенциальный случай, когда это мина замедленного действия, происходит несколько сотен других, для которых миной замедленного действия является, наоборот, попадание невалидных данных в переменные просто за счёт того, что их определение в виде int дало возможность сохранить такое значение.
Но хранятся-то реально данные всё равно в int'е (в реальном мире, где не изобрели чипы переменной битности). А ты просто предлагаешь абстрагироваться от этого. Во имя чистоты подхода.
По сути, если разобраться, всё сведётся к тому, чтобы нагрузить компилятор дополнительными проверками, вместо того, чтобы проверять диапазоны в рантайме. Пока всё хорошо, да? Мины обезвредили.
И вот он, момент, когда бизнес-требования к диапазону выросли. Незначительно. Температура на Земле, как известно, снизу ограничена не -50, а чуть поменьше. -70 или -80, не помню точно. И ты приплыл. С кодебазой, где на каждом повороте аж компилятором проверяется, что температура не меньше -50. Ты даже последовательно модули обновить не сможешь. Только перевыкатывать всю систему целиком!
A>> Когда пляшут от байтиков, проблема диапазона возникает раз в несколько лет, и тогда берут тип экспоненциально большей размерности. И это не вечный процесс. Он прекращается, когда компьютеры становятся достаточно взрослыми. Тип общего назначения i128 уже никому не нужен.
N>То-то он присутствует в расширениях одновременно GCC и MSVC.
Ты, наверно, пропустил слова "общего назначения". Может и присутствует, но не как таковой.
A>> Там уже вектора, SIMD и прочее подобное роялит. С паскалевским же подходом вся твоя жизнь превратится в одну большую проблему диапазонов.
N>Вызываю обосновательную бригаду.
Лучше вызови поисковую бригаду, и поищи на Гитхабе примеры, где бы i128 использовался как тип общего назначения. Как ты понимаешь, мне мой тезис доказать примерами невозможно, а тебе опровергнуть примерами легко.
Никакие случаи "мини-вектор", "мини-структура" и т.п., конечно же, не принимаются.
А если окажется, что я ошибся, я просто заменю i128 на i256. Потому что изначальный тезис был — что процесс экспоненциального увеличения массово используемых типов — не бесконечен. Об этом легко забыть, если не следить за мыслью, не воспринимать ответ как единое целое, а механически дробить его на предложения и доковыриваться к каждому по отдельности (что я не слишком уважаю).
A>>К счастью, это тот случай, когда вместе со мной ошибаются и путают все мейнстримные создатели новых языков.
N>Не все, к счастью. Но, как известно, для каждой проблемы найдётся простое, ясное, неправильное решение. Точнее, неправильным является непредоставление диапазонных и прочих урезанных типов с автовыводом базового типа. Сами по себе i32 не виноваты, виновата чрезмерная опора на них.
Да, их тут тысячи! ©
N>И как именно они протекут?
Возьми какой-то реальный сценарий. Не знаю, "Мужик фотографирует кису и отправляет фотку в мессенджере". И посмотри, во что превратится жизнь, если ты слезешь с байтов. Отринешь проклятое наследие Си. Выберешь язык с типами-диапазонами, и с нуля всё напишешь.
Для начала, сколько цветов будет иметь у тебя пиксел? Как у Эппл, "тысячи цветов", "миллионы цветов"? Наверно, ты всё-таки возьмёшь цветовую модель. Скажем, RGB. Спросишь у производителя матрицы, сколько он даёт градаций на канал, и напишешь тип {r: 0..64, g: 0..64, b: 0..64} (когда я последний раз интересовался вопросом, аппаратные возможности моников были именно такие, а сенсоров ещё хуже). И вот с этим ужасом тебе придётся таскаться всю дорогу.
Сколько будет весить необработанная фотография 1920*1080? Ага, ты, конечно, в уме округлил до байтиков и радуешься. А ты попробуй как в суде присяжных: когда говорят, мол, вы должны игнорировать эту улику, она получена незаконно. Ведь твоя цель — мыслить без привязки к байтам.
Как получить данные? У тебя идёт от драйвера матрицы сплошной поток. И он, конечно, байтовый. Ты его остановишь и будешь перепаковывать в {r: 0..64, g: 0..64, b: 0..64}?
А как кису вывести на экран? Здравствуй, for { for {} } ? В случае байтов тебе, скорее всего, максимум, придётся порядок строк инвертировать при подготовке буфера. (Это зависит от "тараканов"). В лучшем случае — просто скопировать буфер целиком.
Короче, куда же ты денешься от байтов с подводной-то лодки.
N>Файл с данными это уже случай упаковки — в значительном смысле, тех самых тараканов нижнего уровня.
И что с того? Сериализация — не пример, из чего состоит работа чуть менее, чем полностью?
A>>Кстати. Просто мимоходом. Тебе не кажется, что range -50...+80 — это источник ошибок? Мина замедленного действия?
N>Не кажется. На один потенциальный случай, когда это мина замедленного действия, происходит несколько сотен других, для которых миной замедленного действия является, наоборот, попадание невалидных данных в переменные просто за счёт того, что их определение в виде int дало возможность сохранить такое значение.
Но хранятся-то реально данные всё равно в int'е (в реальном мире, где не изобрели чипы переменной битности). А ты просто предлагаешь абстрагироваться от этого. Во имя чистоты подхода.
По сути, если разобраться, всё сведётся к тому, чтобы нагрузить компилятор дополнительными проверками, вместо того, чтобы проверять диапазоны в рантайме. Пока всё хорошо, да? Мины обезвредили.
И вот он, момент, когда бизнес-требования к диапазону выросли. Незначительно. Температура на Земле, как известно, снизу ограничена не -50, а чуть поменьше. -70 или -80, не помню точно. И ты приплыл. С кодебазой, где на каждом повороте аж компилятором проверяется, что температура не меньше -50. Ты даже последовательно модули обновить не сможешь. Только перевыкатывать всю систему целиком!
A>> Когда пляшут от байтиков, проблема диапазона возникает раз в несколько лет, и тогда берут тип экспоненциально большей размерности. И это не вечный процесс. Он прекращается, когда компьютеры становятся достаточно взрослыми. Тип общего назначения i128 уже никому не нужен.
N>То-то он присутствует в расширениях одновременно GCC и MSVC.
Ты, наверно, пропустил слова "общего назначения". Может и присутствует, но не как таковой.
A>> Там уже вектора, SIMD и прочее подобное роялит. С паскалевским же подходом вся твоя жизнь превратится в одну большую проблему диапазонов.
N>Вызываю обосновательную бригаду.
Лучше вызови поисковую бригаду, и поищи на Гитхабе примеры, где бы i128 использовался как тип общего назначения. Как ты понимаешь, мне мой тезис доказать примерами невозможно, а тебе опровергнуть примерами легко.
Никакие случаи "мини-вектор", "мини-структура" и т.п., конечно же, не принимаются.
А если окажется, что я ошибся, я просто заменю i128 на i256. Потому что изначальный тезис был — что процесс экспоненциального увеличения массово используемых типов — не бесконечен. Об этом легко забыть, если не следить за мыслью, не воспринимать ответ как единое целое, а механически дробить его на предложения и доковыриваться к каждому по отдельности (что я не слишком уважаю).
A>>К счастью, это тот случай, когда вместе со мной ошибаются и путают все мейнстримные создатели новых языков.
N>Не все, к счастью. Но, как известно, для каждой проблемы найдётся простое, ясное, неправильное решение. Точнее, неправильным является непредоставление диапазонных и прочих урезанных типов с автовыводом базового типа. Сами по себе i32 не виноваты, виновата чрезмерная опора на них.
Да, их тут тысячи! ©