Вообще-то жсон сам по себе восьмибитный, просто часть парсеров поддерживают только ascii, но это проблемы кривых парсеров а не стандарта

Encoding considerations: 8bit if UTF-8; binary if UTF-16 or UTF-32

отсюда: https://www.ietf.org/rfc/rfc4627.txt

Держу вкурсе

(Reply to this) (Thread)

конечно, он не восьмибитный. иначе не было бы никакой необходимости кодировать бинарные блобы в base64. а поскольку она есть — то весь пиздёж про восьмибитность — пиздёж. it's that simple.

(Reply to this) (Parent) (Thread)

А. Там в rfc написано -- формат сугубо текстовый:

JavaScript Object Notation (JSON) is a lightweight, text-based,
language-independent data interchange format.

Т.е. те кто туда блоб пихает, мануалов не читал.

(Reply to this) (Parent) (Thread)

другими словами это обозначает, что использовать все 256 значений байта оно не может.

(Reply to this) (Parent)

>2023
>один бит лишний, ужоснах

(Reply to this) (Thread)

ну вот примерно поэтому вместо софта сейчас — говно на палке. по этой самой логике.

(Reply to this) (Parent) (Thread)

Да нормальный сейчас софт, не придумывай.

(Reply to this) (Parent) (Thread)

ну, для тех, кто не видел хорошего софта — конечно.

(Reply to this) (Parent)

софт говно потому что перепроизводство

(Reply to this) (Parent) (Thread)

…которое, внезапно, появилось потому что «хуяк-хуяк и в продакшон».

(Reply to this) (Parent) (Thread)

потому что им нужны деньги

(Reply to this) (Parent)

https://ru.wikipedia.org/wiki/RAD_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)

(Reply to this) (Parent)

перепроизводство криворуких говноедов

(Reply to this) (Parent)

В protocol buffers инфа о типах не передается, и даже версия не передается, в протокол встраивают это поверх обычно сами девелоперы, по типу в хендшейк, или там если grpc юзается то в http урле версия

В grpc также есть фича server reflection когда сервер отдельным методом отдает инфу про все типы которые знает, но она появилась не так давно и много кто про нее не знает

Юниксвей же! Всё текст!

(Reply to this) (Thread)

удобно дебажить и снифить

(Reply to this) (Parent)

Ой вей!

(Reply to this) (Parent)

Да, но это хуйня и мелочи по сравнению с тем, каким идиотским говном является рест, опен Апи и джейсон схема

>не надо передавать бесполезную хуйню

вроде ж только ее и передают все время. на две строчки текста и сто килобайт картинки - 10 мегабайт ХУЙНИ!! ЕБАНОЙ ХУЙНИ!!!

и 50 запросов на 20 сторонних сайтов. и сто мегабайт ОЗУ чем-то заняты. и это ты еще жабоскрип не включил.

(Reply to this) (Thread)

видел рекламу на улицах индии? весь интернет стал индией

(Reply to this) (Parent)

до некоторых единиц постепенно доходит, что что-то не так. а в целом — да бля, пипол лазит по интернету даже без адблокеров. я как-то попробовал, так пришлось срочно забухать, чтобы в себя прийти.

(Reply to this) (Parent)

но есть и хорошие новости, там юнити пиздой накрывается в прямом эфире

(Reply to this) (Thread)

это никакие новости. в плане — ну почему не похер-то? игры на хуюнити говно не потому что они на хуюнити, а потому что они говно. остальное так, сопутствующие мелочи.

как будто если хуюнити накроется пиздой, то все сразу начнут пилить с нуля заебатые хорошо отоптимайзеные движки под свои игори.

(Reply to this) (Parent) (Thread)

Тебе Тодд сказал же: ты просто нищеброд лол КУПИ

(Reply to this) (Parent)

Ха, это как с Myst было — сначала вышел римейк realMyst на юнити и ебать же он тормозил (с учётом не сильно выдающейся графики и камерных локаций). И потом его же переиздали на Unreal Engine (по-моему, вообще без изменений в графонии) — и ебать же он тормозит!

(Reply to this) (Parent) (Thread)

движки вообще надо пилить строго под игру, если вообразить идеальный мир. конечно, собирать из запчастей, которых полный ящик, но собирать агрегат конкретно под задачу. потому что универсальные вещи делают всё, но универсально плохо.

(Reply to this) (Parent)

На самом деле разницы между жсоном и блобом только то, что жсон свою спецификацию с собой тащит, а блоб отдельно поставляет.
И то, это работает только для жестко заданной структуры, если у тебя данные пляшут, то либо запрашивать спеку каждый раз вместе с блобом, либо встраивать разметку в блоб.
То бишь тот же жсон, вид сбоку.
Потому разницы-то по сути нет, только для блоба надо отдельные инструменты для просмотра/редактирования запиливать, а для жсон достаточно настройки существующих, а можно и без неё.
Ну да, блоб выигрывает в том, что можно легко встраивать небольшие бинарные блоки, а в жсон их кодировать надо. Но при нынешних каналах это так же непринципиально, как компеляция вавум-си

Не, конечно, те, кто пихает в жсон жирные жпеги, идиоты, но они и с блобаби умудряться что-то идиотское сотворить.

(Reply to this) (Thread)

а зачем, собственно, передавать по сети то, не знаю что? почему софт не в курсе, что он передаёт? «мы пишем хуй знает что, давайте использовать универсальный контейнер! потому что мы не имеем ни малейшего понятия, что будем передавать и получать. вот такой у нас дизайн хороший.»

а всё потому, что набирают пучок за пятачок. а набраные сразу тянут ссаные «фрэймворки», которые умеют только контейнеры. потому что фрэймворк — он предназначен ни для чего, поэтому надо всё поуниверсальней. поэтому давайте собирать и разбирать универсальные контейнеры, больше ведь фрэймворк ничего не умеет. ну не руками же сетевой обмен писать и пакеты делать, это какой-то позор и прошлый век.

(Reply to this) (Parent) (Thread)

Да, софт не знает, что передает, и не обязан знать, потому что предсказывать будущее не может.

Вот тебе реальный пример: справочная система рассылает новые записи в клиентские системы. Единственные постоянные поля это guid, имя, класс и подкласс. Дальше может быть произвольное количество атрибутов произвольного типа (целое, вещественное,булево, строковое).
Сможешь придумать бинарный протокол, который был бы лучше json в этом случае?
Особенно учитывая, что есть сервис-дистпетчер, который частью засовывает данные в потребителей через webAPI, а частью через СИшную утиль для импорта.

(Reply to this) (Parent) (Thread)

>Вот тебе реальный пример: справочная система рассылает новые записи в
>клиентские системы.
…вместо того, чтобы использовать нормальную базу данных. сразу в десяточку.

(Reply to this) (Parent) (Thread)

... и в этой базе лежит ровно тот же жсон, только вместо ключ/значение там два столбца в таблице.

То есть мы добавляем новую сущность в архитектуру, новый софт, работающий 24/7, новый код, чтобы обслуживать эту БД, и это только ради того, чтобы гонять по сети не 7 бит, а 8? (Хотя это ещё вопрос, ХЗ как там коннектор базы данные пересылает)

Ты реально считаешь такой вариант чем-то принципиально лучше?

(Reply to this) (Parent) (Thread)

ты всё описываешь так, как будто во-первых, изначально никакой базы данных нет, а во-вторых, у клиентов тоже никакой базы данных нет. а откуда это пришло, и где это хранят?

по-моему, апдейты данных делаются так: клиент запрашивает URL, и получает URL, и опционально последний seqence id. а по этому URL лежат кумулятивные апдейты в виде SQLite-файлов, бережно пронумерованые теми самыми sequence id. и мы их качаем, и прменяем к своей базе.

всё, проблема апдейтов решена кардинально, проблема протокола тоже. и можно сервить апдейты совершенно любым сервером, можно качать апдейты сразу шифроваными через SSL/TLS, и библиотеки для этого всего уже написаны. и не надо гонять по протоколу блобы непонятного назначения.

(Reply to this) (Parent) (Thread)

В реале абсолютно пофиг, где они все хранят свои данные, потому что эти базы зачастую отличаются всем: движком, кодировкой, именами полей, типами полей, местом хранения полей. Наконец, значение в системе-клиенте может склеиваться из 2-3 значений справочника.

То есть в любом случае, без промежуточного нейтрального формата не обойтись.

Плюс ты простой автоматический пуш заменяешь на пул, который на порядок сложнее: у нас сразу появляется состояние, которым надо управлять и которое надо хранить. А ещё нам надо либо кнопку, на которую будет клацать homo sapiens (это если софтина позволяет создавать такие кнопалки), либо шедулер, который регулярно засирает сеть воплями "есть чо нового? Нет? Ну ок"

(Reply to this) (Parent) (Thread)

>То есть в любом случае, без промежуточного нейтрального формата не обойтись.
ну и отлично: SQLite-база — прекрасный промежуточный формат.

>Плюс ты простой автоматический пуш заменяешь на пул
кто мешает пнуть клиентов с нотификацией про новые обновления? а остальное — это схема для случая, когда клиент был в офлайне долгое время. медитировал. теперь ему надо подтащить все обновления.

вариант 1: клиент занимается тем, что бесполезно расходует ресурсы сервера на получиение обновлений. каждый, кто в офлайне был.

вариант 2: сервер периодически делает кумулятивные апдейты и складывает их на отдельную файлопомойку. а клиенты оттуда забирают, что им надо. никто не мешает им забирать как по своей инициативе, так и по пинку от сервера.

итого, мы получили схему, которая одинаково хорошо работает для любого случая, и заодно позволяет красиво разделить собственно основной сервер хранения данных, и сервера апдейтов (которых может быть и больше одного). хошь — делай всё на одной машине, хошь — масштабируй. причём совершенно прозрачно.

(Reply to this) (Parent) (Thread)

>ну и отлично: SQLite-база — прекрасный промежуточный формат.
Ага. Только достаточно громоздкий, завязанный на файлы, и без автоматической десериализации.
То бишь если мы не передаём кучу бинарных данных, никаких преимуществ перед жсоном-то и нету. А недостатки наоборот есть.

>кто мешает пнуть клиентов с нотификацией про новые обновления?
Никто, равно как никто не мешает в виде нотификации послать сами данные.

>того, мы получили схему, которая одинаково хорошо работает для любого случая
Как ты знаешь, универсальное решение работает хуже специализированного ;)
Больше кода, сложенее взаимодействие, следовательно труднее поддерживать и больше точек отказа.

Чем в результате твоё решение лучше?

(Reply to this) (Parent) (Thread)

>и без автоматической десериализации
как будто у остальных есть. нет, «я тут библиотеку скачал» не предлагать, это не автоматическая.

>Больше кода, сложенее взаимодействие, следовательно труднее поддерживать и
>больше точек отказа.
когда точка отказа одна, и она главный сервер — это, конечно, лучше.

>Чем в результате твоё решение лучше?
тем, что оно от твоего «давай сразу посылать данные» на семантическом уровне не отличается, а вот реализуется намного проще. потому что у нас теперь есть чёткие и независимые блоки, а не стрёмный монолит. причём комбинировать это можно самыми разными путями: например, оффлайн-апдейтами. накачал баз-апдейтов и скормил клиенту, у которого сейчас сети нет. в моём решении ничего особенного для этого делать не надо вообще, например, а в твоём это попросту невозможно.

эта штука называется «разделение задачи на независимые (более-менее) части». компонентное мышление, компонентное программирование.

(Reply to this) (Parent) (Thread)

>как будто у остальных есть. нет, «я тут библиотеку скачал» не предлагать, это не автоматическая.
Таки есть. Я создаю webAPI проект в .NET, объявляю в параметрах метода-обработчика у контроллера класс DTO, и оно мне само десериализует приходящий жсон в объект этого класса. Ну, в нетривиальных случаях хинты в DTOшке поставить надо.

>когда точка отказа одна, и она главный сервер — это, конечно, лучше.
Во-первых, главный сервер не обязательно. У меня он сделан чисто для моего удобства, чтобы деплоить быстрее, никто не мешает раскидать эти сервисы по системам.
Во-вторых, ничего страшного в упавшем сервере в наше время нет. Это раньше надо было поставить новый или починить старый, накатить ось, сделать заново настройки. Сейчас оно либо автоматически переподнимется на другой ферме, либо подымется из бэкапа.

> а вот реализуется намного проще. потому что у нас теперь есть чёткие и независимые блоки, а не стрёмный монолит.
эээ, а откуда ты взял про монолит? Там как раз всё отлично реализуется набором тривиальных сервисов.

>например, а в твоём это попросту невозможно.
Зачем оффлайн апдейты в локалке это отдельный вопрос. Но почему ты считаешь невозможным сохранить пачку жсонов на диск, я не знаю.

>эта штука называется «разделение задачи на независимые (более-менее) части». компонентное мышление, компонентное программирование.
ну вот смотри. Система справочников плюется пакетами с со списком систем-адресатов и измененными данными. Она от них никак не зависит, ей пофиг на их состояние и конфигурацию. Диспетчер принимает пакет и раскидывает его по сервисам-импортёрам. Опять же, он не зависит ни от системы-справочника, ни от сервисов-имортёров. Последние, естественно, зависят от своих систем, но те, которые работают через web, тоже могут быть развернуты где угодно. Единственная общая зависимость -- сервис журналирования, но он для работы не критичен.
И где тут монолит?

(Reply to this) (Parent) (Thread)

>эээ, а откуда ты взял про монолит? Там как раз всё отлично реализуется набором
>тривиальных сервисов.
то есть, ты уже сделал то самое разбиение, на которое мне жалуешься, но зачем-то на него жалуешься. я не понимат.

>Но почему ты считаешь невозможным сохранить пачку жсонов на диск, я не знаю.
а потому что у тебя нет того кода, который их положит, и того, который возьмёт. их отдельно писать надо.

>И где тут монолит?
опять же: описано почти то же самое, что и у меня, только оно зачем-то подвязано на передачу данных по тому же протоколу, по которому ходят и команды. такой in-band вообще не очень хорошая идея.

(Reply to this) (Parent) (Thread)

Я жалуюсь не на разбиение, а на дополнительное усложнение логики, которое ты туда прикрутил. Это у тебя есть команды и данные, у меня никаких команд, только данные и летают.

>а потому что у тебя нет того кода, который их положит, и того, который возьмёт. их отдельно писать надо.

Сгенерировать имя файла и записать в него: две строки.
Прочитать из файла: одна, две, или три, смотря на каком языке писать.
Если импортёру потребуются файлы, это реализуется примерно за то же время, как которое я написал этот комментарий.

(Reply to this) (Parent) (Thread)

>у меня никаких команд, только данные и летают
то, что ты засунул команды in-band внутрь жысона — не делает их не быть.

>Если импортёру потребуются файлы, это реализуется примерно за то же время, как
>которое я написал этот комментарий.
а в моей схеме это реализовано сразу. просто как побочный эффект построения системы. и зеркалирование апдейтов тоже — опять как побочный эффект. потому что разные уровни правильно абстрагированы, а не смешаны в одну кашу.

(Reply to this) (Parent)

Мои эстетические чуйства жсон оскорбляет не тем, что в него пихают бинарку, а тем, что это говно (а также хмл) распространилось вместо лиспа. Быдло всегда выбирает худшее из всего, что есть.

(Reply to this) (Thread)

проблема не в том, как он выглядит, а в том, что он не нужен там, где его пытаются применить. потому что там никакой универсальный контейнер не нужен, безотносительно его формата.

(Reply to this) (Parent)

так реализуй то, что будет работать в современных реалиях, да выложи общественности же

(Reply to this) (Thread)

я не знаю, как сделать аппарат, который превратит уебанов в людей.

(Reply to this) (Parent) (Thread)

не знать мы и без тебя горазды

(Reply to this) (Parent)

Мы живем в мире, где уебаны
1. Придумали юникод, и теперь символ не равен 1 байту
2. Придумали клиентские скрипты (js/vbs), чтоб что-то делать на клиенте, вместо того, чтоб все сразу сделать на сервере, а клиенту отдать нужное.

(Reply to this) (Thread)

> 1. Придумали юникод, и теперь символ не равен 1 байту

Во всём виноваты узкоглазые и прочие унтерменьши, чьи уебищные языки не влезают в ASCII.

(Reply to this) (Parent) (Thread)

Раньше это решалось на уровне софта, но нет, кому-то ебнуло в бошку затолкать все в ОДНУ БОЛЬШУЮ КОДИРОВКУ, которая работает хз как, но на это говно теперь пересадим всех, и кому надо и кому не надо.

(Reply to this) (Parent)

> символ не равен 1 байту
да хуй бы с 1 байтом, он взаправду маленький слишком. пусть хоть 4 байта на символ, это не беда. истинная проблема в том, что в юникоде символы не являются атомарными и не имеют единого размера.

(Reply to this) (Parent) (Thread)

Это проблема только для дебилов. А нормальные люди понимают, что для того, чтобы сделать с текстом что-то внятное, по нему в любом случае придется пройтись - и похую, сколько там байтов: между x++ и UtfForward(&x) никакой разницы нет. Хинт: даже ASCII имеет табы, ньюлайны и проч. А в юникод с таким майндсетом (ах, я щас длину строки по байтикам вычислю) нехуй даже соваться. Ещё хинт: даже фиксированый широкосимвол имеет комбинирующие символы, ртл и прочее гавно.

(Reply to this) (Parent) (Thread)

>Ещё хинт: даже фиксированый широкосимвол имеет комбинирующие символы, ртл и
>прочее гавно.
которое является дополнительной причиной никогда, ни за что не использовать юникод. или хотя бы фильтровать к хуям всю эту поебень.

(Reply to this) (Parent) (Thread)

Одних табов достаточно, чтобы "преимущества" двухбайтовой арифметики пошли по пизде.

(Reply to this) (Parent) (Thread)

попробуй не смешивать typesetting и string operations.

(Reply to this) (Parent) (Thread)

Назови мне хотя бы одну string operation, которой помешает утф-8.

(Reply to this) (Parent) (Thread)

любая операция, где нам нужно по «логическому» индексу символа от начала строки найти его реальное положение в памяти. никаких вариантов кроме «каждый раз считаем всё с самого начала» тут нет. а это базовая операция для огромного количества алгоритмов, и в большинстве случаев ожидается, что она O(1), а не O(n).

(Reply to this) (Parent) (Thread)

> базовая операция для огромного количества алгоритмов

"Огромное количество алгоритмов" это буквально один: "переход к символу номер n строки m в текстовом редакторе". Назови второй.

(Reply to this) (Parent) (Thread)

вот на этом месте если надо объяснять — то не надо объяснять.

(Reply to this) (Parent)

Если осознать, что для канпутера утф8 это такой же бессмысленный набор байтов, как и аски - придет просветление. Поиск подстроки, например, буквально той же функцией делается. Проблемы начинаются только с кейсонезависимостью и пр. хуйней. Но тут сразу разверзаются бездны: а Ё и Е с комбинирующими точечками это одна буква или разные?

(Reply to this) (Parent) (Thread)

если осознать, что адресация символа по его индексу в ASCII/UCS — O(1), а в утф — O(n), то придёт ещё большее просветление.

(Reply to this) (Parent) (Thread)

> адресация символа по его индексу

не нужна почти вообще никогда
это патологическая идея

(Reply to this) (Parent) (Thread)

я смотрю, ты Современный Погромист. у них тоже O(1) не надо, потому что их Фронтэнды На Жавоскрипте один хуй тормозят, как ни пиши.

(Reply to this) (Parent)

Ты не ответил - Е с точечками это один символ или два? А нулевой пробел - один или ноль?

(Reply to this) (Parent) (Thread)

а без разницы.

(Reply to this) (Parent)

А вообще - очень странно использовать вчар, если ты противник уникода :))

(Reply to this) (Parent) (Thread)

очень странно считать, что больше, чем восемь бит на код символа и юникод — это синонимы.

(Reply to this) (Parent)

И, кстати, недаром в ебаной винде, яве и сишарпе строки вчарные. СОВПАДЕНИЕ? НЕ ДУМАЮ

(Reply to this) (Parent)

ну тут, кмк, анон прав: in-band управляющие символы - это рудимент и атавизм ещё со времён кода Бодо и телетайпов всяких.

(Reply to this) (Parent) (Thread)

но эта тема совершенно ортогональна теме удобной адресации символов внутри строки.

(Reply to this) (Parent)

> Ещё хинт: даже фиксированый широкосимвол имеет комбинирующие символы, ртл и прочее гавно.

солнышко, в глаза ебёшься?
> не являются атомарными

(Reply to this) (Parent)

Хуже уникодников только анти-утф8ники, вот такой парадокс.

(Reply to this) (Parent) (Thread)

наличие суррогатных пар, а также комбинирующих и управляющих символов от выбора конкретной utf-схемы кодирования зависит примерно никак.

(Reply to this) (Parent) (Thread)

Тогда зачем тебе атомарные символы?

(Reply to this) (Parent) (Thread)

как минимум чтобы строки можно было резать предсказуемым образом и быстро

(Reply to this) (Parent) (Thread)

Дорогуша, а откуда ты берешь оффсеты и длины для резки? От балды? Или сначала по тексту проходишь, чтобы найти где резать? А теперь ответь: какая тебе разницы, в чем искать пробел или запятую - в утф-8 или нет? Один хуй отрежешь как надо.

(Reply to this) (Parent) (Thread)

дорогуша, мне надо, к примеру, двадцать пять символов с начала строки. ровно двадцать пять. есть вариант сделать это в utf, не сканируя всю строку с самого начала? а вот в ASCII/UCS — есть.

(Reply to this) (Parent) (Thread)

Зачем?! ЗАЧЕМ СУКА ТЕБЕ "ДВАДЦАТЬ ПЯТЬ СИМВОЛОВ С НАЧАЛА СТРОКИ"?!

(Reply to this) (Parent) (Thread)

я не буду тебе это объяснять, это бесполезно.

(Reply to this) (Parent)

например чтобы показать кусок строки в некоем интерфейсном поле, имеющем окошко отображения такой длины. это сходу пример ваще.

(Reply to this) (Parent)

А вот, кстати, философский вопрос: даже в текстовых редакторах "номер символа" вместо номера байта нахуя нужен? Их кто-то когда-то пальчиком считает на экране? Вот тебе конпелятор скажет: "ошибка в байте 100500" - какая вообще разница, куда прыгать - к байту или к "символу"?

(Reply to this) (Parent)

говно ноет https://drewdevault.com/2023/09/17/Hyprland-toxicity.html

(Reply to this) (Thread)

Wayland compositor

на этом месте я читать прекратил.

(Reply to this) (Parent)

а еще вот конда проклятая!

типа мы не хотим нормально разрулить депенденсис, но и бинарник человеческий не сделаем. а устроим типа блядь зазеркалье, экосистему внутри экосистемы устроим.

вот этот сука тред

https://forum.qiime2.org/t/installing-qiime2-without-conda/9597

We don’t distribute python packages for the QIIME 2 ecosystem, because many components of QIIME 2 are non-python, and thus can’t be distributed via pip. We use conda because it is agnostic to the software in question.

и квинтэссенция

why not use conda? It's faster than pip and lighter than Docker!

не, ну спасибо конечно что не докер. но они уже задумались!

(может конечно я тупой юзер. но не ндравится!)

(Reply to this) (Thread)

для начала там великолепнейший сцайт, который не работает без жысы. что, впрочем, неудивительно: ничего другого от душителей питона никто и не ожидает.

(Reply to this) (Parent) (Thread)

при этом в своей нише это типа ХОРОШИЙ СОФТ

от плохого я блевал прямо кровью, а от этого ну так, глаз дергается

(Reply to this) (Parent)