Это как вообще? Даже жесткие ссылки, которым сто лет уже, и то не поддерживаются? От ADS отказались? То есть это не развитие а какой-то откат назад.
А вообще напрашивается мысль о какой-то единой open-source файловой системе, которая могла бы использоваться и в винде, и в линуксе, и в других ОС. По аналогии с тем как движок Хрома используется в куче браузеров, в том числе и в майкрософтовском.
А какая у них "длина контекста"? Важно не просто работать в режиме "один вопрос - одна выдача", но и так чтобы ИИ помнил и учитывал предыдущие вопросы и выдачи в данном диалоге.
Вы смешиваете объявление переменных и объявление функций. Никто не мешает объявлять переменные как "int x, y" и при этом функции как "fn foo(int x, int y) int".
У Си куча известных проблем, но их никто не решает именно потому что это язык "с которым знакомо на порядок больше людей и который уже довольно старый и отлаженный". Куча кода который никто не будет переписывать; новый код пишут на Си потому что старый уже написан на Си, и т.д. Это вообще проблема IT - устаревшие технологии тянут назад. Даже если эти технологии и отлаженные.
На опеннете такой пример (добавлена поддержка семантических аннотаций кода, позволяющий прикрепить к коду дополнительные метаданные, которые игнорируются компилятором, но могут учитываться лексическим анализатором в стандартной библиотеке):
Вот интересно, тип указывается после имени переменной (как сейчас новомодно, и это объясняется тем, что имя важнее для восприятия, а тип может быть выведен и часто его вообще можно не указывать). Но атрибут все равно пишется перед именем переменной. Это с точки зрения дизайна языка правильно или нет? С одной стороны атрибуты традиционно указывают перед аннотируемой сущностью (которой может быть не только переменная но и функция, и структура... т.е. нечто больше и длинное, и удобнее видеть атрибуты в начале а не в конце). С другой вижу некоторое противоречие с типами после имени - ведь тип это тоже своего рода аннотация.
Уж лучше LSW (Linux Subsystem for Windows) :) Несвободная, телеметрическая и живущая своей жизнью винда в изолированном контенейре на линуксовом хосте.
В чем разница между кодом и алгоритмом? Только в уровне абстракции. А уровень абстракции можно повышать бесконечно, чем собственно и занимается математика.
Вот скажем код который выводит числа от -87134 до +983724. Нейросеть его легко напишет, и такого кода практически гарантированно никто раньше не писал. Формально, нейросеть генерирует именно нечто новое.
Далее, код который выводит числа от M до N. Это еще код или уже алгоритм? Мы просто поднялись на уровень выше, заменили конкретные числа на обобщенные. Как переход от арифметики к алгебре. Хотя что конкретное число, что переменная "икс" - всего лишь математические абстракции, и то что делают первоклассники, складывая в столбик - всего лишь формальные манипуляции над абстрактными символами по определенному алгоритму. Это ничем не отличается от того что делают студенты, вычисляя производные и интегралы - просто другой алфавит языка и другие правила.
Мы можем например попросить нейросеть сгенерировать код, который выводит не числа, а программные коды для какого-то класса конкретных алгоритмов с параметрами. Такое вот метапрограммирование. Да, это уже сложнее, но вопрос чисто количественный - мощность нейросети.
Вот откуда вы это берёте??? Вам так кажется? Вам хочется в это верить? Какая-то новая религия как будто зарождается...
Никакой религии, обычная техническая экстраполяция. ИИ вполне способен генерировать новый (при том рабочий) код - то есть такой, которого нет нигде в интернете. Новый код принципиально ничем качественно не отличается от нового алгоритма или нового закона математики. Отличия только количественные. И разумеется ИИ может ошибаться. Кстати, также и человек, изучая новый язык программирования, иногда выдает вроде бы логичные, но неверные языковые конструкции - наблюдал лично.
Едрить, для них ещё матчасть и переводить на автоматический надо? Вот это сверх-интеллект! А сам он эту проблему решить не может? Ну, судя по тому как он в геометрии разбирается - не может((
Можно не переводить, просто скормить ему весь либген и сайхаб. Но это потребует на порядки больше вычислительных ресурсов для самой модели - потому что человеческий способ представления математических знаний крайне неоптимален именно для языковой модели. То же самое и с геометрией - она по своей природе не языковая, и тут вариантов два - или на порядки увеличивать вычислительную мощность и обучать одновременно на форумах и картинках (вот прямо как школьников в школе учат), или переводить геометрию на формальный язык и обучать на нем.
Вот тут в соседней статье как раз про этом. ИИ вполне может генерировать новые алгоритмы. Более того, если всю математику переписать на какой нибудь Coq и загнать в такую систему, то рано или поздно ИИ и математические открытия сможет делать. А где математика там и физика и вся остальная наука...
А что есть новое? Формально, они создают именно новое - то есть такой код (или текст) который они выдают, на момент выдачи отсутствует где-либо еще. Это не поисковик. Но ведь и человек действует так же - на основе изучения каких-то примеров генерирует нечто похожее, но другое.
То что я пишу для работы - оно и так мне не принадлежит.
То что я пишу для себя - я все равно или никому не показываю, или же наоборот отдаю всем в абсолютно свободное пользование.
Во всех случаях код, сгенеренный ИИ, напрямую к использованию не годится - обычно это лишь примеры как сделать что-то. Как использовать какую-то функцию библиотеки, не читая документацию на саму библиотеку. При встраивании этих примеров в проект все равно приходится всё переписывать.
А у Гугла есть бесплатный онлайн доступ к каким-то моделям? (не считая того что они там встроили в поисковик, это не чатбот а просто однократная генерация на поисковый запрос)
Кстати, а сколько у него длина контекста? Я в основном пользуюсь Grok и наткнулся на то что там длина контекста около мегабайта. При попытке общаться в одном чате слишком долго просто возникает непонятная ошибка, новые ответы не генерятся. Ну и сослаться на соседние чаты не получалось, но это кажется у всех чатботов так было.
Ссылки и указатели это отличная тема для обсуждения дизайна языков программирования. Как лучше?
Указатели - это наиболее низкоуровневая абстрация, ближе всего к реальности и значит содержащая меньше всего противоречий. И еще указатели явные, их нужно разыменовывать каждый раз при использовании.
Ссылки - более высокоуровневая конструкция, также они кажутся более безопасными (хотя разумеется это не так - можно например сделать ссылку на разыменованный указатель, указывающий на память, которую затем освободить).
Если подумать то получаются как минимум следующие аспекты:
Явность/неявность при обращении (нужно или нет "разыменовывать")
Встроенная нуллабельность указателей и ненуллабельность ссылок
Возможность адресной арифметики
Адресная арифметика считается источником ошибок, хотя в низкоуровневом программировании от нее никуда не деться. Но это как раз решаемый вопрос, можно потреборвать чтобы она выполнялась только в каком нибудь "unsafe" контексте. В большинстве случаев указатели нужны лишь для динамически создаваемых объектов и там никакая арифметика не нужна.
Нуллабельность... она в языках программирования нужна, во многих случаях есть специальное состояние null, которое нужно выразить явно, а во многих других такого состояния нет. И хорошо если синтаксис языка предоставляет единый механизм для этого.
Остается явность/неявность - самое непростое, поскольку касается самой идеологии написания кода. Иногда важно явно выразить что происходит именно обращение по указателю; а иногда нам все равно, что там внутри - переменная просто представляет объект, а как он там хранится - без разницы.В Си (еще до C++) придумали операцию "стрелка" "->" специально для явного обращения к полям структуры по указателю, хотя ничто не мешало задействовать операцию "точка" - конфликта не было бы, в Си указатель не может быть одновременно составным объектом. Сделали так именно для явного обращения, такова идеология языка. В последующих языках от этого отказались, там везде "точка". В Go работают оба способа: (*myPointer).field и myPointer.field
В том то и дело, что несколько не связанных между собой частных не нужно, нужен один общий, но такой в котором все другие (в том числе и существующая явная обработка) окажутся именно частными случаями.
Например, что мне нравится в Go так это единый синтаксис для обычных функций и лямбд. Во всех других языках изощряются со всякими стрелками и прочими спецсимволами, а в Go и там и там func - просто для лямбд не указывается имя. То есть единый синтаксис и внутри два частных случая - именованные функции и анонимные.
А в чем её преимущества? Я вот очень хочу встроенные в FS теги, доступ к файловой системе как к базе данных и т.п. Однако вот в википедии читаю
Это как вообще? Даже жесткие ссылки, которым сто лет уже, и то не поддерживаются? От ADS отказались? То есть это не развитие а какой-то откат назад.
А вообще напрашивается мысль о какой-то единой open-source файловой системе, которая могла бы использоваться и в винде, и в линуксе, и в других ОС. По аналогии с тем как движок Хрома используется в куче браузеров, в том числе и в майкрософтовском.
А какая у них "длина контекста"? Важно не просто работать в режиме "один вопрос - одна выдача", но и так чтобы ИИ помнил и учитывал предыдущие вопросы и выдачи в данном диалоге.
Вы смешиваете объявление переменных и объявление функций. Никто не мешает объявлять переменные как "int x, y" и при этом функции как "fn foo(int x, int y) int".
А обязательно нужна киллер-фича? Да и есть ли она у Zig, V, Num и Rust? Возможно, достаточно просто работы над ошибками?
У Си куча известных проблем, но их никто не решает именно потому что это язык "с которым знакомо на порядок больше людей и который уже довольно старый и отлаженный". Куча кода который никто не будет переписывать; новый код пишут на Си потому что старый уже написан на Си, и т.д. Это вообще проблема IT - устаревшие технологии тянут назад. Даже если эти технологии и отлаженные.
На опеннете такой пример (добавлена поддержка семантических аннотаций кода, позволяющий прикрепить к коду дополнительные метаданные, которые игнорируются компилятором, но могут учитываться лексическим анализатором в стандартной библиотеке):
Вот интересно, тип указывается после имени переменной (как сейчас новомодно, и это объясняется тем, что имя важнее для восприятия, а тип может быть выведен и часто его вообще можно не указывать). Но атрибут все равно пишется перед именем переменной. Это с точки зрения дизайна языка правильно или нет? С одной стороны атрибуты традиционно указывают перед аннотируемой сущностью (которой может быть не только переменная но и функция, и структура... т.е. нечто больше и длинное, и удобнее видеть атрибуты в начале а не в конце). С другой вижу некоторое противоречие с типами после имени - ведь тип это тоже своего рода аннотация.
Интересно, а есть подобные проекты, но полностью бесплатные и бессерверные, соединяющиеся скажем через DHT?
Wine это скорее аналог WSL1. А виртуалка в бесшовном режиме - аналог WSL2.
Как в анекдоте - или достигнем или не достигнем.
Уж лучше LSW (Linux Subsystem for Windows) :) Несвободная, телеметрическая и живущая своей жизнью винда в изолированном контенейре на линуксовом хосте.
В чем разница между кодом и алгоритмом? Только в уровне абстракции. А уровень абстракции можно повышать бесконечно, чем собственно и занимается математика.
Вот скажем код который выводит числа от -87134 до +983724. Нейросеть его легко напишет, и такого кода практически гарантированно никто раньше не писал. Формально, нейросеть генерирует именно нечто новое.
Далее, код который выводит числа от M до N. Это еще код или уже алгоритм? Мы просто поднялись на уровень выше, заменили конкретные числа на обобщенные. Как переход от арифметики к алгебре. Хотя что конкретное число, что переменная "икс" - всего лишь математические абстракции, и то что делают первоклассники, складывая в столбик - всего лишь формальные манипуляции над абстрактными символами по определенному алгоритму. Это ничем не отличается от того что делают студенты, вычисляя производные и интегралы - просто другой алфавит языка и другие правила.
Мы можем например попросить нейросеть сгенерировать код, который выводит не числа, а программные коды для какого-то класса конкретных алгоритмов с параметрами. Такое вот метапрограммирование. Да, это уже сложнее, но вопрос чисто количественный - мощность нейросети.
Никакой религии, обычная техническая экстраполяция. ИИ вполне способен генерировать новый (при том рабочий) код - то есть такой, которого нет нигде в интернете. Новый код принципиально ничем качественно не отличается от нового алгоритма или нового закона математики. Отличия только количественные. И разумеется ИИ может ошибаться. Кстати, также и человек, изучая новый язык программирования, иногда выдает вроде бы логичные, но неверные языковые конструкции - наблюдал лично.
Можно не переводить, просто скормить ему весь либген и сайхаб. Но это потребует на порядки больше вычислительных ресурсов для самой модели - потому что человеческий способ представления математических знаний крайне неоптимален именно для языковой модели. То же самое и с геометрией - она по своей природе не языковая, и тут вариантов два - или на порядки увеличивать вычислительную мощность и обучать одновременно на форумах и картинках (вот прямо как школьников в школе учат), или переводить геометрию на формальный язык и обучать на нем.
Вот тут в соседней статье как раз про этом. ИИ вполне может генерировать новые алгоритмы. Более того, если всю математику переписать на какой нибудь Coq и загнать в такую систему, то рано или поздно ИИ и математические открытия сможет делать. А где математика там и физика и вся остальная наука...
А что есть новое? Формально, они создают именно новое - то есть такой код (или текст) который они выдают, на момент выдачи отсутствует где-либо еще. Это не поисковик. Но ведь и человек действует так же - на основе изучения каких-то примеров генерирует нечто похожее, но другое.
То что я пишу для работы - оно и так мне не принадлежит.
То что я пишу для себя - я все равно или никому не показываю, или же наоборот отдаю всем в абсолютно свободное пользование.
Во всех случаях код, сгенеренный ИИ, напрямую к использованию не годится - обычно это лишь примеры как сделать что-то. Как использовать какую-то функцию библиотеки, не читая документацию на саму библиотеку. При встраивании этих примеров в проект все равно приходится всё переписывать.
А у Гугла есть бесплатный онлайн доступ к каким-то моделям? (не считая того что они там встроили в поисковик, это не чатбот а просто однократная генерация на поисковый запрос)
Кстати, а сколько у него длина контекста? Я в основном пользуюсь Grok и наткнулся на то что там длина контекста около мегабайта. При попытке общаться в одном чате слишком долго просто возникает непонятная ошибка, новые ответы не генерятся. Ну и сослаться на соседние чаты не получалось, но это кажется у всех чатботов так было.
Ссылки и указатели это отличная тема для обсуждения дизайна языков программирования. Как лучше?
Указатели - это наиболее низкоуровневая абстрация, ближе всего к реальности и значит содержащая меньше всего противоречий. И еще указатели явные, их нужно разыменовывать каждый раз при использовании.
Ссылки - более высокоуровневая конструкция, также они кажутся более безопасными (хотя разумеется это не так - можно например сделать ссылку на разыменованный указатель, указывающий на память, которую затем освободить).
Если подумать то получаются как минимум следующие аспекты:
Явность/неявность при обращении (нужно или нет "разыменовывать")
Встроенная нуллабельность указателей и ненуллабельность ссылок
Возможность адресной арифметики
Адресная арифметика считается источником ошибок, хотя в низкоуровневом программировании от нее никуда не деться. Но это как раз решаемый вопрос, можно потреборвать чтобы она выполнялась только в каком нибудь "unsafe" контексте. В большинстве случаев указатели нужны лишь для динамически создаваемых объектов и там никакая арифметика не нужна.
Нуллабельность... она в языках программирования нужна, во многих случаях есть специальное состояние null, которое нужно выразить явно, а во многих других такого состояния нет. И хорошо если синтаксис языка предоставляет единый механизм для этого.
Остается явность/неявность - самое непростое, поскольку касается самой идеологии написания кода. Иногда важно явно выразить что происходит именно обращение по указателю; а иногда нам все равно, что там внутри - переменная просто представляет объект, а как он там хранится - без разницы.В Си (еще до C++) придумали операцию "стрелка" "->" специально для явного обращения к полям структуры по указателю, хотя ничто не мешало задействовать операцию "точка" - конфликта не было бы, в Си указатель не может быть одновременно составным объектом. Сделали так именно для явного обращения, такова идеология языка. В последующих языках от этого отказались, там везде "точка". В Go работают оба способа: (*myPointer).field и myPointer.field
А существующий механизм panic-recover это разве не оно?
В том то и дело, что несколько не связанных между собой частных не нужно, нужен один общий, но такой в котором все другие (в том числе и существующая явная обработка) окажутся именно частными случаями.
Например, что мне нравится в Go так это единый синтаксис для обычных функций и лямбд. Во всех других языках изощряются со всякими стрелками и прочими спецсимволами, а в Go и там и там func - просто для лямбд не указывается имя. То есть единый синтаксис и внутри два частных случая - именованные функции и анонимные.