А у Гугла есть бесплатный онлайн доступ к каким-то моделям? (не считая того что они там встроили в поисковик, это не чатбот а просто однократная генерация на поисковый запрос)
Кстати, а сколько у него длина контекста? Я в основном пользуюсь Grok и наткнулся на то что там длина контекста около мегабайта. При попытке общаться в одном чате слишком долго просто возникает непонятная ошибка, новые ответы не генерятся. Ну и сослаться на соседние чаты не получалось, но это кажется у всех чатботов так было.
Ссылки и указатели это отличная тема для обсуждения дизайна языков программирования. Как лучше?
Указатели - это наиболее низкоуровневая абстрация, ближе всего к реальности и значит содержащая меньше всего противоречий. И еще указатели явные, их нужно разыменовывать каждый раз при использовании.
Ссылки - более высокоуровневая конструкция, также они кажутся более безопасными (хотя разумеется это не так - можно например сделать ссылку на разыменованный указатель, указывающий на память, которую затем освободить).
Если подумать то получаются как минимум следующие аспекты:
Явность/неявность при обращении (нужно или нет "разыменовывать")
Встроенная нуллабельность указателей и ненуллабельность ссылок
Возможность адресной арифметики
Адресная арифметика считается источником ошибок, хотя в низкоуровневом программировании от нее никуда не деться. Но это как раз решаемый вопрос, можно потреборвать чтобы она выполнялась только в каком нибудь "unsafe" контексте. В большинстве случаев указатели нужны лишь для динамически создаваемых объектов и там никакая арифметика не нужна.
Нуллабельность... она в языках программирования нужна, во многих случаях есть специальное состояние null, которое нужно выразить явно, а во многих других такого состояния нет. И хорошо если синтаксис языка предоставляет единый механизм для этого.
Остается явность/неявность - самое непростое, поскольку касается самой идеологии написания кода. Иногда важно явно выразить что происходит именно обращение по указателю; а иногда нам все равно, что там внутри - переменная просто представляет объект, а как он там хранится - без разницы.В Си (еще до C++) придумали операцию "стрелка" "->" специально для явного обращения к полям структуры по указателю, хотя ничто не мешало задействовать операцию "точка" - конфликта не было бы, в Си указатель не может быть одновременно составным объектом. Сделали так именно для явного обращения, такова идеология языка. В последующих языках от этого отказались, там везде "точка". В Go работают оба способа: (*myPointer).field и myPointer.field
В том то и дело, что несколько не связанных между собой частных не нужно, нужен один общий, но такой в котором все другие (в том числе и существующая явная обработка) окажутся именно частными случаями.
Например, что мне нравится в Go так это единый синтаксис для обычных функций и лямбд. Во всех других языках изощряются со всякими стрелками и прочими спецсимволами, а в Go и там и там func - просто для лямбд не указывается имя. То есть единый синтаксис и внутри два частных случая - именованные функции и анонимные.
не создавать нескольких способов реализации одной и той же функциональности.
никогда ни к чему и не придут. Потому что правило в целом неверное. Но и много разных несовместимых между собой способов и синтаксисов добавлять тоже не нужно, это будет еще хуже чем сейчас.
А нужно разработать универсальный способ обработки ошибок, включающий максимум различных возможностей и предложений, и разработать такой синтаксис, чтобы конкретные предложения оказались частными случаями этого максимально общего способа.
Если чего-то нет - сделайте! С современным изобилием LLM это должно быть не очень сложно, заодно и изучите эту самую грамматику в процессе делания (здесь сработает тот же самый принцип что и при конспектировании, написании заметок и т.д. вместо простого чтения уже готового материала без записей).
Я думаю автор все же про генераторы текста, а не видео и картинок.
И текста, и картинок. И если с текстом бесплатные сервисы неплохо справляются (да, приходится все сохранять в древовидном редакторе, затем при необходимости подгружать обратно), то с картинками все как-то хуже.
Вообще чем больше пользуюсь ИИшками тем больше нравится:) Хотя в запуске именно на смартфоне смысла не вижу, все чаще возникает желание не зависеть от инета, а запускать локально. Чтобы без цензуры и ограничений, чтобы неограниченная длина контекста, чтобы была возможность дообучать на своем контенте, чтобы можно было делать древовидную историю запросов а не линейную, и т.д. Если с текстовыми еще вполне можно работать через инет (grok весьма неплох, deepdeek по ощущениям чуть хуже но тоже ничего) то вот для генерации картинок я так ничего и не нашел нормального и бесплатного одновременно.
Но покупать видеокарту за полмиллиона... ИМХО все-же перебор. А статей на эту тему очень не хватает. Как найти оптимальное соотношение цены и качества? Каковы перспективы в плане удешевления железа?
У меня такой необычный вопрос к людям, разбирающимся в схемах. А как вы их "чувствуете", представляете их работу в уме? Особенно если схема большая и навороченная? С постоянным током я могу - это как-то само из детства пришло, когда соединял батарейки и лампочки. Однако так получилось что пошел по другому пути, в чистый программинг, и нелинейные схемы, способные что-то усиливать, генерировать колебания и т.п., остались в стороне. Вот я смотрю на схему на картинке, вроде и элементов немного, но как "проэмулировать" ее работу в голове?
Вы используете какие-то паттерны? Здесь же нужно не просто смотреть на схему но и понимать числовые характеристики элементов?
Атмосферно выглядит... В общем, если в следующей жизни попаду в Хогвартс, обязательно выберу там дополнительными предметами арифмантику и древние руны - наверняка это магические аналоги математики и программирования.
Жалко. Куба могла бы стать неплохим местом для удаленщиков - тепло и дешево, если бы не эти странные ограничения. А всего-то нужно чуть-чуть рыночной экономики, конкуренции между провайдерами и т.п.
Интересная статья, спасибо! Добавлю что еще одно потенциальное преимущество индексов перед указателями - возможность максимально просто сдампить такое AST в файл и загрузить из файла обратно в память. Зачем это может быть нужно? Например хранить частично скомпилированный код каких-то библиотек, содержащих метапрограммы (те же шаблоны или макросы). Хранение этого в классических *.lib файлах невозможно.
Писать оператор "?" на каждом уровне проще чем явно проверять коды возврата в Go. Но если хочется совсем уж неявно - то можно придумать такой синтаксис: если функция возвращает Option или Result, и мы в ней разыменовываем объект Option/Result в котором невалидные данные - делать неявный return этого объекта. Явность теряется (никаких знаков вопроса и т.п.), но зато и никакой лишней писанины.
Надеюсь хоть кто-то решит проблему автономии самым простым и естественным способом - внешним аккумулятором, который лежит в кармане и подключен тонким проводом по типу тех что в наушниках. Пусть даже в дополнение к штатным встроенным аккумуляторам, но ИМХО такая возможность аппаратно должна быть. Кому не нравятся провода - ну заряжайте каждые 2 часа. А меня провода не смущают вообще - с теми же наушниками, беспроводные выпадут из ушей, зимой, в темноте, в грязь, и ищи их там... а проводные хотя-бы на проводе повиснут:)
А у Гугла есть бесплатный онлайн доступ к каким-то моделям? (не считая того что они там встроили в поисковик, это не чатбот а просто однократная генерация на поисковый запрос)
Кстати, а сколько у него длина контекста? Я в основном пользуюсь Grok и наткнулся на то что там длина контекста около мегабайта. При попытке общаться в одном чате слишком долго просто возникает непонятная ошибка, новые ответы не генерятся. Ну и сослаться на соседние чаты не получалось, но это кажется у всех чатботов так было.
Ссылки и указатели это отличная тема для обсуждения дизайна языков программирования. Как лучше?
Указатели - это наиболее низкоуровневая абстрация, ближе всего к реальности и значит содержащая меньше всего противоречий. И еще указатели явные, их нужно разыменовывать каждый раз при использовании.
Ссылки - более высокоуровневая конструкция, также они кажутся более безопасными (хотя разумеется это не так - можно например сделать ссылку на разыменованный указатель, указывающий на память, которую затем освободить).
Если подумать то получаются как минимум следующие аспекты:
Явность/неявность при обращении (нужно или нет "разыменовывать")
Встроенная нуллабельность указателей и ненуллабельность ссылок
Возможность адресной арифметики
Адресная арифметика считается источником ошибок, хотя в низкоуровневом программировании от нее никуда не деться. Но это как раз решаемый вопрос, можно потреборвать чтобы она выполнялась только в каком нибудь "unsafe" контексте. В большинстве случаев указатели нужны лишь для динамически создаваемых объектов и там никакая арифметика не нужна.
Нуллабельность... она в языках программирования нужна, во многих случаях есть специальное состояние null, которое нужно выразить явно, а во многих других такого состояния нет. И хорошо если синтаксис языка предоставляет единый механизм для этого.
Остается явность/неявность - самое непростое, поскольку касается самой идеологии написания кода. Иногда важно явно выразить что происходит именно обращение по указателю; а иногда нам все равно, что там внутри - переменная просто представляет объект, а как он там хранится - без разницы.В Си (еще до C++) придумали операцию "стрелка" "->" специально для явного обращения к полям структуры по указателю, хотя ничто не мешало задействовать операцию "точка" - конфликта не было бы, в Си указатель не может быть одновременно составным объектом. Сделали так именно для явного обращения, такова идеология языка. В последующих языках от этого отказались, там везде "точка". В Go работают оба способа: (*myPointer).field и myPointer.field
А существующий механизм panic-recover это разве не оно?
В том то и дело, что несколько не связанных между собой частных не нужно, нужен один общий, но такой в котором все другие (в том числе и существующая явная обработка) окажутся именно частными случаями.
Например, что мне нравится в Go так это единый синтаксис для обычных функций и лямбд. Во всех других языках изощряются со всякими стрелками и прочими спецсимволами, а в Go и там и там func - просто для лямбд не указывается имя. То есть единый синтаксис и внутри два частных случая - именованные функции и анонимные.
Из-за вот этого правила
никогда ни к чему и не придут. Потому что правило в целом неверное. Но и много разных несовместимых между собой способов и синтаксисов добавлять тоже не нужно, это будет еще хуже чем сейчас.
А нужно разработать универсальный способ обработки ошибок, включающий максимум различных возможностей и предложений, и разработать такой синтаксис, чтобы конкретные предложения оказались частными случаями этого максимально общего способа.
А как думаете, на каком уровне вот эти книги (если кто читал):
Alice and Bob Meet the Wall of Fire - edited by Thomas Lin
The Selfish Gene - Richard Dawkins
Redefining Reality: The Intellectual Implications of Modern Science - Steven Gimbel
Great Mental Models - Shane Parrish
The Great Questions of Philosophy and Physics - Steven Gimbel
The Island of Knowledge - Marcelo Gleiser
Know This - edited by John Brockman
An Introduction to Formal Logic - Steven Gimbel
Если чего-то нет - сделайте! С современным изобилием LLM это должно быть не очень сложно, заодно и изучите эту самую грамматику в процессе делания (здесь сработает тот же самый принцип что и при конспектировании, написании заметок и т.д. вместо простого чтения уже готового материала без записей).
Я себе свой написал уже давно. Сейчас большинство использует Obsidian.
И текста, и картинок. И если с текстом бесплатные сервисы неплохо справляются (да, приходится все сохранять в древовидном редакторе, затем при необходимости подгружать обратно), то с картинками все как-то хуже.
Вообще чем больше пользуюсь ИИшками тем больше нравится:) Хотя в запуске именно на смартфоне смысла не вижу, все чаще возникает желание не зависеть от инета, а запускать локально. Чтобы без цензуры и ограничений, чтобы неограниченная длина контекста, чтобы была возможность дообучать на своем контенте, чтобы можно было делать древовидную историю запросов а не линейную, и т.д. Если с текстовыми еще вполне можно работать через инет (grok весьма неплох, deepdeek по ощущениям чуть хуже но тоже ничего) то вот для генерации картинок я так ничего и не нашел нормального и бесплатного одновременно.
Но покупать видеокарту за полмиллиона... ИМХО все-же перебор. А статей на эту тему очень не хватает. Как найти оптимальное соотношение цены и качества? Каковы перспективы в плане удешевления железа?
У меня такой необычный вопрос к людям, разбирающимся в схемах. А как вы их "чувствуете", представляете их работу в уме? Особенно если схема большая и навороченная? С постоянным током я могу - это как-то само из детства пришло, когда соединял батарейки и лампочки. Однако так получилось что пошел по другому пути, в чистый программинг, и нелинейные схемы, способные что-то усиливать, генерировать колебания и т.п., остались в стороне. Вот я смотрю на схему на картинке, вроде и элементов немного, но как "проэмулировать" ее работу в голове?
Вы используете какие-то паттерны? Здесь же нужно не просто смотреть на схему но и понимать числовые характеристики элементов?
Атмосферно выглядит... В общем, если в следующей жизни попаду в Хогвартс, обязательно выберу там дополнительными предметами арифмантику и древние руны - наверняка это магические аналоги математики и программирования.
Жалко. Куба могла бы стать неплохим местом для удаленщиков - тепло и дешево, если бы не эти странные ограничения. А всего-то нужно чуть-чуть рыночной экономики, конкуренции между провайдерами и т.п.
ИМХО пузыри и текст можно и вручную добавить - быстрее будет. А на ИИ возложить чисто художественное рисование.
Интересная статья, спасибо! Добавлю что еще одно потенциальное преимущество индексов перед указателями - возможность максимально просто сдампить такое AST в файл и загрузить из файла обратно в память. Зачем это может быть нужно? Например хранить частично скомпилированный код каких-то библиотек, содержащих метапрограммы (те же шаблоны или макросы). Хранение этого в классических *.lib файлах невозможно.
Интересно, и здесь всё скатилось к централизации (как и в вебом). А есть ли что-то (алгоритмы, архитектуры) принципиально защищенные от централизации?
Замечательная подборка, только самого главного не хватает: цены (как минимум информации о платности/бесплатности).
Писать оператор "?" на каждом уровне проще чем явно проверять коды возврата в Go. Но если хочется совсем уж неявно - то можно придумать такой синтаксис: если функция возвращает Option или Result, и мы в ней разыменовываем объект Option/Result в котором невалидные данные - делать неявный return этого объекта. Явность теряется (никаких знаков вопроса и т.п.), но зато и никакой лишней писанины.
Надеюсь хоть кто-то решит проблему автономии самым простым и естественным способом - внешним аккумулятором, который лежит в кармане и подключен тонким проводом по типу тех что в наушниках. Пусть даже в дополнение к штатным встроенным аккумуляторам, но ИМХО такая возможность аппаратно должна быть. Кому не нравятся провода - ну заряжайте каждые 2 часа. А меня провода не смущают вообще - с теми же наушниками, беспроводные выпадут из ушей, зимой, в темноте, в грязь, и ищи их там... а проводные хотя-бы на проводе повиснут:)