Нейросети очень любят их использовать (потому что это правильно), а люди -- нет (потому что на клавиатуре отсутствует). Ладно всякие письма, там и почтовый клиент может подсказать, а вот в комментариях они почти наверняка указывают на нейросетевое происхождение.
Смысл потоковых форматов не только в том, что они преобразуются в корректное, хоть и не полное, состояние автоматигески просто при линейном чтении (выше уже писали, что парсер на событиях написать несложно, да и условный RapidJSON имеет как DOM, так и SAX-интерфейсы).
Потоковые форматы ещё можно "промотать" - и они всё равно будут собираться в корректное состояние. Вы можете закодировать условный видеофайл так, что у вас будет ровно один ключевой кадр в начале, а потом только дельты - тогда у вас просто не будет выбора, вам придётся декодировать 2 часа фильма, чтобы посмотреть только сцену после титров. Но этот же условный видеофайл может быть разбит на кучу отдельных блоков со своими ключевыми кадрами и необходимыми метаданными - тогда он очень даже потоко-пригодный. Видео и аудио позволяют такие "шалости" потому что в общем случае текущее состояние (кадр или частота+громкость) очень мало зависят от того, что было давно, потому что новые данные "перезатирают" старое состояние. Это очень редкое свойство для абстрактных данных в вакууме, и почти всегда решается не на уровне формата, с на уровне использования этого формата. Та же пагинация - это по сути создание "потокового" представления контента, что особенно наглядно на страницах с бесконечной прокруткой, типа лент соцсетей или чатов в мессенджерах.
Интересно, насколько этот самый (мифический?) "алгоритм" есть инструкция (для отдела кадров, например), а не компьютерная программа.
Потому что
Посчитать KPI
Сказать "Ай-яй-яй"
Подождать 1 месяц
Повторить
вполне себе "человеческая" инструкция, тут комплюхтер не нужон особо. Равно как и "каждый месяц увольнять 10 человек с самым низким показателем ABCDE-12345" - да, сам показатель посчитают на компьютере, но инструкция-то для менеджеров.
Если нет наследования (а точнее - полиморфизма, как его следствия), то нет не то что смысла в ООП, но по сути не остается и самого ООП.
Полиморфизм не является следствием наследования аж по 2 причинам:
Есть (как минимум) аж 3 типа полиморфизма: ad hoc (перегрузка функций), параметрический (шаблонные структуры данных) и подтипы (наследование).
Давайте представим такую ситуацию: у вас в языке есть только 2 вида классов: виртуальные интерфейсы (их объекты нельзя создать), и все остальные, которые обязаны быть ненаследуемыми (final / sealed, вот это вот). Наследование в обычном смысле тут отсутствует, может быть только реализация интерфейса. Вы можете произвольно комбинировать разные интерфейсы, которые хотите реализовать, но не можете от "уже рабочего" условного Animal унаследовать Cat - есть только композиция. Так устроены и успешно работают, например, Rust и Go. Тем не менее, вы можете создать, например, лист с объектами, реализующими условный ICat, и всем им сделать obj.meow(), вне зависимости от их фактического типа - хоть Domestic, хоть SnowLeopard, хоть IgrooshkaIzKitaya, то есть воспользоваться полиморфизмом в вашем изначальном смысле.
Да ладно вам, если по комментариям прям тут, на Хабре, походить, то для кого-то обязательно везде использовать ООП, для других - процедурное программирование, третьи приемлют только функциональщину. Все мы лохи, только для разных людей.
Ураа, теперь вы сможете узнать, что больны неизлечимым заболеванием, которое разрушит вашу жизнь и покалечит жизни ваших близких, аж за 11 лет до появления симптомов!..
Именно 40 лет - не уверен, всё же тогда язык ещё только появился и таки был не очень быстрым. Но потом сделали BEAM VM, и 27 лет назад
In March 1998 Ericsson announced the AXD301 switch,[8] containing over a million lines of Erlang and reported to achieve a high availability of nine "9"s.[17]
любой машинный алгоритм при одинаковых вводных данных будет выдавать одинаковый прогнозируемый результат.
Что из этого более корректно?
генераторы псевдослучайных чисел - тоже ИИ, потому что они выдают разные результаты.
в LLMных интерфейсах (чаще всего) нельзя задавать начальные состояния генераторов псевдослучайных чисел, используемых при выборе следующих токенов, поэтому они и выдают разные результаты при, казалось бы, одинаковых входных данных.
Как это потокобезопасной работы нет?! В C11 добавили поддержку тредов, атомиков и вот этого всего. Осталось только мейнтейнереов уговорить переписать свои C90 поделия на этот свежайший стандарт, и тогда заживём! Да, сарказм. Наполовину.
Так в Firefox помимо JS есть ещё поддержка кучи тегов HTML и свойств CSS, дополнительные протоколы и форматы файлов (что у Dillo с поддержкой HTTP/3, AV1, WebP, да хоть просто SVG?)
Вот, например, stdin вполне себе stream, но умеет только read. А stdout - только write. А TCP сокет может read+write, но всё равно не seek. То есть, если вам в аргумент функции write_hello(IStream writer) положили некий неизвестный stream - вы явно должны проверить его, потому что он может не уметь write.
С другой стороны, в Rust сделано именно так, как вам не нравится: Stdin - только Read, TcpStream - Read+Write, File - Read+Write+Seek, и вроде даже это "API чтобы с ними по отдельности работать" проблем не вызывает, наоборот понятно кто что умеет, безо всяких if(stream.can_write())
Даже без танцев с аллокаторами, простой вынос "числодробильности" в отдельные объекты, выделяющие память (да и просто выполняющие тяжёлые операции вроде создания вспомогательных файлов, соединений, потоков, каких-нибудь fftw_plan , чтения и обработки конфигов, и прочей вспомогательной ерунды) только при создании зачастую уже достаточно. А если не пересоздавать эти объекты-числодробилки с нуля, а переиспользовать старые (те самые worker pool) - так и вовсе красота.
Самое грустное, что на Python уже некоторое время можно накидывать типы, но в доке чёрным по серому написано
Note: The Python runtime does not enforce function and variable type annotations. They can be used by third party tools such as type checkers, IDEs, linters, etc.
Даже без участия голов слишком много вопросов, что нужно автоматически убрать с капота (или перейти в состояние "я стою пока не кожаные мешки это уберут с меня"), а что игнорировать: снег, даже если его 15 сантиметров? кирпич? котейку? пакет или лист бумаги, который принесло ветром? а если это не ветром принесло, а человек засунул под дворник рекламу? а если это не реклама, а штрафная квитанция (или как это там называется)?
Нейросети очень любят их использовать (потому что это правильно), а люди -- нет (потому что на клавиатуре отсутствует). Ладно всякие письма, там и почтовый клиент может подсказать, а вот в комментариях они почти наверняка указывают на нейросетевое происхождение.
То ли дело теории заговора, типичные комментарии со списками, смайликами и em-dash, и порно сгенерированное нейросетями! Вот это интересно!
Смысл потоковых форматов не только в том, что они преобразуются в корректное, хоть и не полное, состояние автоматигески просто при линейном чтении (выше уже писали, что парсер на событиях написать несложно, да и условный RapidJSON имеет как DOM, так и SAX-интерфейсы).
Потоковые форматы ещё можно "промотать" - и они всё равно будут собираться в корректное состояние. Вы можете закодировать условный видеофайл так, что у вас будет ровно один ключевой кадр в начале, а потом только дельты - тогда у вас просто не будет выбора, вам придётся декодировать 2 часа фильма, чтобы посмотреть только сцену после титров. Но этот же условный видеофайл может быть разбит на кучу отдельных блоков со своими ключевыми кадрами и необходимыми метаданными - тогда он очень даже потоко-пригодный. Видео и аудио позволяют такие "шалости" потому что в общем случае текущее состояние (кадр или частота+громкость) очень мало зависят от того, что было давно, потому что новые данные "перезатирают" старое состояние. Это очень редкое свойство для абстрактных данных в вакууме, и почти всегда решается не на уровне формата, с на уровне использования этого формата. Та же пагинация - это по сути создание "потокового" представления контента, что особенно наглядно на страницах с бесконечной прокруткой, типа лент соцсетей или чатов в мессенджерах.
Как давно вы открывали
C:\Users\<username>? Там тоже ведь лютая свалкаИнтересно, насколько этот самый (мифический?) "алгоритм" есть инструкция (для отдела кадров, например), а не компьютерная программа.
Потому что
Посчитать KPI
Сказать "Ай-яй-яй"
Подождать 1 месяц
Повторить
вполне себе "человеческая" инструкция, тут комплюхтер не нужон особо. Равно как и "каждый месяц увольнять 10 человек с самым низким показателем ABCDE-12345" - да, сам показатель посчитают на компьютере, но инструкция-то для менеджеров.
Полиморфизм не является следствием наследования аж по 2 причинам:
Есть (как минимум) аж 3 типа полиморфизма: ad hoc (перегрузка функций), параметрический (шаблонные структуры данных) и подтипы (наследование).
Давайте представим такую ситуацию: у вас в языке есть только 2 вида классов: виртуальные интерфейсы (их объекты нельзя создать), и все остальные, которые обязаны быть ненаследуемыми (final / sealed, вот это вот). Наследование в обычном смысле тут отсутствует, может быть только реализация интерфейса. Вы можете произвольно комбинировать разные интерфейсы, которые хотите реализовать, но не можете от "уже рабочего" условного Animal унаследовать Cat - есть только композиция. Так устроены и успешно работают, например, Rust и Go. Тем не менее, вы можете создать, например, лист с объектами, реализующими условный
ICat, и всем им сделатьobj.meow(), вне зависимости от их фактического типа - хотьDomestic, хотьSnowLeopard, хотьIgrooshkaIzKitaya, то есть воспользоваться полиморфизмом в вашем изначальном смысле.Да ладно вам, если по комментариям прям тут, на Хабре, походить, то для кого-то обязательно везде использовать ООП, для других - процедурное программирование, третьи приемлют только функциональщину. Все мы лохи, только для разных людей.
Ураа, теперь вы сможете узнать, что больны неизлечимым заболеванием, которое разрушит вашу жизнь и покалечит жизни ваших близких, аж за 11 лет до появления симптомов!..
Именно 40 лет - не уверен, всё же тогда язык ещё только появился и таки был не очень быстрым. Но потом сделали BEAM VM, и 27 лет назад
40 лет было нормально, и тут раз - накладно
Почему не стоит использовать:
Когда может пригодиться:
Это ещё корпускулярно-волновой дуализм, или уже диссоциативное расстройство личности (синглтона)?
Что из этого более корректно?
генераторы псевдослучайных чисел - тоже ИИ, потому что они выдают разные результаты.
в LLMных интерфейсах (чаще всего) нельзя задавать начальные состояния генераторов псевдослучайных чисел, используемых при выборе следующих токенов, поэтому они и выдают разные результаты при, казалось бы, одинаковых входных данных.
К сожалению (а может и к счастью), никакого "сжатия с помощью ИИ" в статье не нашлось, только
Как это потокобезопасной работы нет?! В C11 добавили поддержку тредов, атомиков и вот этого всего. Осталось только мейнтейнереов уговорить переписать свои C90 поделия на этот свежайший стандарт, и тогда заживём!
Да, сарказм. Наполовину.
Так в Firefox помимо JS есть ещё поддержка кучи тегов HTML и свойств CSS, дополнительные протоколы и форматы файлов (что у Dillo с поддержкой HTTP/3, AV1, WebP, да хоть просто SVG?)
Это почти как сравнивать Блокнот и Visual Studio
Вот, например, stdin вполне себе stream, но умеет только read. А stdout - только write. А TCP сокет может read+write, но всё равно не seek. То есть, если вам в аргумент функции write_hello(IStream writer) положили некий неизвестный stream - вы явно должны проверить его, потому что он может не уметь write.
С другой стороны, в Rust сделано именно так, как вам не нравится: Stdin - только Read, TcpStream - Read+Write, File - Read+Write+Seek, и вроде даже это "API чтобы с ними по отдельности работать" проблем не вызывает, наоборот понятно кто что умеет, безо всяких
if(stream.can_write())Даже без танцев с аллокаторами, простой вынос "числодробильности" в отдельные объекты, выделяющие память (да и просто выполняющие тяжёлые операции вроде создания вспомогательных файлов, соединений, потоков, каких-нибудь
fftw_plan, чтения и обработки конфигов, и прочей вспомогательной ерунды) только при создании зачастую уже достаточно. А если не пересоздавать эти объекты-числодробилки с нуля, а переиспользовать старые (те самые worker pool) - так и вовсе красота.Самое грустное, что на Python уже некоторое время можно накидывать типы, но в доке чёрным по серому написано
Но это уже будет как в Тулу со своим самоваром :)
Даже без участия голов слишком много вопросов, что нужно автоматически убрать с капота (или перейти в состояние "я стою пока не кожаные мешки это уберут с меня"), а что игнорировать: снег, даже если его 15 сантиметров? кирпич? котейку? пакет или лист бумаги, который принесло ветром? а если это не ветром принесло, а человек засунул под дворник рекламу? а если это не реклама, а штрафная квитанция (или как это там называется)?