TL:DR нейросетевой бред. Или не нейросетевой, но тогда это писал школьник с уровнем знаний "оооо в си есть указатели", а не человек с 20-летним опытом на Си.
нужно видеть разницу между системным и прикладным программированием. Если у вас завис браузер (прикладное ПО), вы его просто перезапустите. Но если «упал» сервер СУБД в момент банковской транзакции — это катастрофа.
А вы точно понимаете разницу между системным и прикладным ПО?
меня бесило, что массивы из 100 и 200 элементов — это разные типы. Я пожаловался другу, он посочувствовал и сказал: "А вот в С по-другому".
Ну как сказать... Оба типа кастуются в C к обычному указателю в ряде случаев, но эти типы всё равно разные, и слава богу.
void accept_100(int (*arr)[100]) {}
int main(void) {
int arr100[100];
int arr200[200];
accept_100(&arr100); // ok
accept_100(&arr200); // error: passing argument 1 of ‘accept_100’ from incompatible pointer type
return 0;
}
получается, что у утки шасси не выпускаются. И это ловушка эволюции
То есть в правильной иерархии классов утка должна выпускать шасси? Идиотский пример.
Пока ИИ умеет выполнять только самые базовые задачи в программировании, например переложить данные из одного массива в другой по заданному правилу.
Я конечно ИИ-скептик, но мне всё-таки кажется, что на сегодняшний день возможности ИИ в программировании мягко говоря немного больше.
Как это возможно вообще X_X У ДМа что ли нет отпусков, и все игроки доступны 24/7? Или там железная дисциплина по посещаемости? Обычная ситуация же, когда один не может придти, другой не может, в итоге полкоманды не может и игру отменяем, а следующая игра только на следующих выходных естественно. НГ/Рождество опять же.
Также непонятно как они апгрейдили редакции правил на ходу.
Тут всё просто: вижу технологию, явно задачей #1 имеющую цель влезть в AI, а не сделать что-то хорошо, значит скам.
Очень сомнительный ЯП. Автор у него конечно рокстар и всё такое, но их совершенно не красят методы, которыми они себя пиарят. Куча восторженных статей с минимумом технических деталей и зачем-то с нападками на все возможные ЯП от которых он произошёл - и Python-то они превосходят, и Rust-то они превосходят, причём в бенчмарках против Rust они например на голубом глазу то компилируют Rust в dbg режиме, то используют в коде на Rust динамический массив (Vec), а на Mojo без динамической аллокации, ну и вообще слабовато знают Rust.
Тредов нет, примитивов синхронизации нет, половина фич в стадии "ещё не готово", но заявления уже огого какие.
Extension Bisect Штатный инструмент VSCode для поиска "плохого" расширения
В смысле "штатный"? Это сторонний плагин из маркетплейса, такой же точно как и ваш Rails.
Для определения времени выполнения дочерних процессов плагин вообще не нужен, есть системные инструменты (в Linux по крайней мере), которым всё равно, кто создаёт дочерний процесс, - VScode или обычный шелл:
Есть девиртуализация, именно для случаев когда можно догадаться на этапе компиляции куда именно в vtable пойдёт вызов вирт.функции. Вот пример из статьи, переписанный в виде вирт. функций, который компилятор смог девиртуализовать: https://godbolt.org/z/oszTM6nP7.
переменную аннулировать, например выражением (void)x
(Void) не способен аннулировать свой операнд, ни один оператор приведения типа это не может. Это ничего не делающая операция, древний хак для обхода предупреждения компилятора о неиспользованной переменной.
Чтобы вместо разгребания багрепортов на свой собственный быстрый рендер текста заниматься сотней эмуляторов терминала?
Ну AI впихивать время нашли, могли бы более полезным заняться. Emacs, Vim, Kakoune, Xi умеют и tty и gui фронтенд без проблем, а эти видите ли не могут. Кроме того, в статье как раз и демонстрируется, что привязка к определённому рендереру может в будущем аукнуться.
Да и сколько нужно этих редакторов в терминале чтобы хватило?
Проблема в том, что тюнинг редактора под себя требует времени. Под "временем" я понимаю годы. Это развитие своих хоткеев, плагинов, изучение и введение в эксплуатацию чужих плагинов. Держать и развивать под себя 2 редактора, 1 для консоли, один для DE - слишком дорогое удовольствие.
Наверное лучшее решение в современном мире - практически натив в песочнице. Кстати из Rust компилировать не обязательно, есть ещё куча языков, умеющих в WASM.
По такой логике нативные плагины вообще не должны существовать, а то вдруг сегфолтнется, ужас какой. Редактор - не панель управления ядерным реактором, так что я считаю, что гипотетическая возможность вылета такого некритичного приложения, как текстовый редактор, при использовании сторонних плагинов - более чем умеренная плата за более простую архитектуру и улучшенную производительность бинарных плагинов.
Был бы заявкой на лучший редактор в мире, если бы поддерживал работу в терминале - которая в Zed невозможна тк он гвоздями прибит к Vulkan (под Linux) и рендерингу в графической среде.
Т.е. я правильно понимаю, что в качестве меры борьбы с вытеснением её профессии AGI она ушла в профессию, которую гипотетический AGI уничтожит ещё раньше? :)))
Я вообще к вам хотел попробоваться, но честно говоря бывшие тренеры по боксу в качестве core инженеров C++ меня очень смущают.
Как это вообще возможно?? Для поддержки ядра текстового редактора надо знать миллион вещей, всякие CRDT/gapbuffers/строковые кэши, обычно многопоточку, теорию по парсерам, C++ собственно на хорошем уровне, ядра пары других текстовых движков шапочно. Мейнтейнеры подобных движков, известные мне, все с бэкграундом в CS и при этом достаточно упоротые чтобы продолжать специализироваться в C++ со временем. А у вас так легко, взял из бокса вкатился, пилит constexpr <auto> template MyLineStorage::fetch в кор команде... Кстати его ответ "Как пришёл в IT" освещает что угодно, но только не как он пришёл в IT.
Это не так. В VST верифицируемая программа пишется на си
Гм, не совсем. Несколькими страницами ниже:
Verifiable C is a program logic (higher-order impredicative concurrent separation logic) for C programs with these restrictions:
• No casting between integers and pointers. • No goto statements. • No bitfields in structs. • No struct-copying assignments, struct parameters, or struct returns. • Only structured switch statements (no Duff’s device). • No varargs functions, except limited undocumented support for calling printf and fprintf.
The Verifiable C program logic operates on the CompCert Clight language. CompCert’s clightgen tool (described in the next chapter) translates C into C light, so that you can use VST to apply the program logic to the program. Clight (and clightgen) does support some of the features listed above (such as goto, bitfields, struct-copying), but programs with those features cannot be proved in Verifiable C.
"Пишется на ограниченном диалекте C" != "пишется на си".
Чем Lean и Coq не подходят?
Про Lean не в курсе, но Coq (закрою глаза на то, что это ЯП, а не система символьного вывода) является реализацией исчисления конструкций и следовательно подвержен всем ограничениям исчисления конструкций, например в Coq является выводимым парадокс Карри:
Parameter Y : Prop.
Axiom curry_axiom : forall P : Prop,
Y <-> (Y -> P).
Theorem curry_paradox : forall P : Prop, P.
Proof.
intros P.
destruct (curry_axiom P) as [H1 H2].
(* H1 : Y -> (Y -> P)
H2 : (Y -> P) -> Y *)
set (f := fun z : Y => H1 z z).
(* f z = H1 z z : P, so f : Y -> P *)
pose (y := H2 f).
(* y : Y *)
exact (H1 y y).
Qed.
Нет таких символьных систем, в которых можно непротиворечиво вывести всю математику. Во-первых никто толком не договорился об аксиоматике (поэтому собственно и возможен мой пример выше), во-вторых есть теоремы Гёделя о неполноте.
И для математики, и для программирования существуют инструменты проверяющие корректность
Для программ и доказательств, записанных на формально верифицируемом языке. Что на сегодняшний день равняется 2.5 академическим ЯП в области программирования и примерно 0 универсальных формальных систем в области чистой математики.
Операционная система, не получив от программы сигнала о завершении через системный вызов exit, принудительно ее уничтожает
Новое слово в системном программировании... FYI если в программе нет вызова exit и т.д., то проц просто продолжает выполнять опкоды, расположенные за программой в памяти. Как правило это заканчивается тем, что он выполняет что-то в non executable области, и как следствие segfault. Но всякое бывает, может случайно и сискол exit выполниться. Никакого "принудительного уничтожения" таких программ в Linux нет, их поведение просто не определено.
В целом как-то многовато пафоса для, видимо, набора типа "высокоуровневых" макросов для опкодов x86-64?
критиковал не столько решения openai, сколько язык записи доказательств у openai =) Само по себе решение #1 от openai, как оказалось, верное - перепроверил после всех разъяснений.
У Google значительно лучше, как минимум понятнее. В решении #1 тоже не нашёл ошибок.
TL:DR нейросетевой бред. Или не нейросетевой, но тогда это писал школьник с уровнем знаний "оооо в си есть указатели", а не человек с 20-летним опытом на Си.
А вы точно понимаете разницу между системным и прикладным ПО?
Ну как сказать... Оба типа кастуются в C к обычному указателю в ряде случаев, но эти типы всё равно разные, и слава богу.
То есть в правильной иерархии классов утка должна выпускать шасси? Идиотский пример.
Я конечно ИИ-скептик, но мне всё-таки кажется, что на сегодняшний день возможности ИИ в программировании мягко говоря немного больше.
Как это возможно вообще X_X
У ДМа что ли нет отпусков, и все игроки доступны 24/7? Или там железная дисциплина по посещаемости?
Обычная ситуация же, когда один не может придти, другой не может, в итоге полкоманды не может и игру отменяем, а следующая игра только на следующих выходных естественно. НГ/Рождество опять же.
Также непонятно как они апгрейдили редакции правил на ходу.
Тут всё просто: вижу технологию, явно задачей #1 имеющую цель влезть в AI, а не сделать что-то хорошо, значит скам.
Очень сомнительный ЯП. Автор у него конечно рокстар и всё такое, но их совершенно не красят методы, которыми они себя пиарят. Куча восторженных статей с минимумом технических деталей и зачем-то с нападками на все возможные ЯП от которых он произошёл - и Python-то они превосходят, и Rust-то они превосходят, причём в бенчмарках против Rust они например на голубом глазу то компилируют Rust в dbg режиме, то используют в коде на Rust динамический массив (Vec), а на Mojo без динамической аллокации, ну и вообще слабовато знают Rust.
Тредов нет, примитивов синхронизации нет, половина фич в стадии "ещё не готово", но заявления уже огого какие.
Кто такие ежи из космоса??
В смысле "штатный"? Это сторонний плагин из маркетплейса, такой же точно как и ваш Rails.
Для определения времени выполнения дочерних процессов плагин вообще не нужен, есть системные инструменты (в Linux по крайней мере), которым всё равно, кто создаёт дочерний процесс, - VScode или обычный шелл:
Виноват, проглядел
callrax, девиртуализовались и заинлайнились только первые 2 вызова, третий нет.Очень странно почему 3й случай не девиртуализовался, в ряде случаев это работает (arm64 gcc https://godbolt.org/z/59osvf7b8), в других нет.
Есть девиртуализация, именно для случаев когда можно догадаться на этапе компиляции куда именно в vtable пойдёт вызов вирт.функции. Вот пример из статьи, переписанный в виде вирт. функций, который компилятор смог девиртуализовать: https://godbolt.org/z/oszTM6nP7.
Всё это фигня, агентное роевое программирование уже мертво, на смену пришли флотилии агентов! (когда ии-агенты управляют роями)
Короче нет времени объяснять, несите мне деньги, там разберёмся.
del
(Void) не способен аннулировать свой операнд, ни один оператор приведения типа это не может. Это ничего не делающая операция, древний хак для обхода предупреждения компилятора о неиспользованной переменной.
Ну AI впихивать время нашли, могли бы более полезным заняться. Emacs, Vim, Kakoune, Xi умеют и tty и gui фронтенд без проблем, а эти видите ли не могут. Кроме того, в статье как раз и демонстрируется, что привязка к определённому рендереру может в будущем аукнуться.
Проблема в том, что тюнинг редактора под себя требует времени. Под "временем" я понимаю годы. Это развитие своих хоткеев, плагинов, изучение и введение в эксплуатацию чужих плагинов. Держать и развивать под себя 2 редактора, 1 для консоли, один для DE - слишком дорогое удовольствие.
По такой логике нативные плагины вообще не должны существовать, а то вдруг сегфолтнется, ужас какой. Редактор - не панель управления ядерным реактором, так что я считаю, что гипотетическая возможность вылета такого некритичного приложения, как текстовый редактор, при использовании сторонних плагинов - более чем умеренная плата за более простую архитектуру и улучшенную производительность бинарных плагинов.
Я имею в виду не способность вызывать терминал, а способность работать внутри терминала.
Был бы заявкой на лучший редактор в мире, если бы поддерживал работу в терминале - которая в Zed невозможна тк он гвоздями прибит к Vulkan (под Linux) и рендерингу в графической среде.
Также очень странный подход к архитектуре плагинов, которые надо обязательно компилировать из Rust в WASM тк разработчики панически боялись, что чужой плагин может крашнуть редактор https://zed.dev/blog/language-extensions-part-1#challenges-with-packaging-parsers
Т.е. я правильно понимаю, что в качестве меры борьбы с вытеснением её профессии AGI она ушла в профессию, которую гипотетический AGI уничтожит ещё раньше? :)))
Я вообще к вам хотел попробоваться, но честно говоря бывшие тренеры по боксу в качестве core инженеров C++ меня очень смущают.
Как это вообще возможно?? Для поддержки ядра текстового редактора надо знать миллион вещей, всякие CRDT/gapbuffers/строковые кэши, обычно многопоточку, теорию по парсерам, C++ собственно на хорошем уровне, ядра пары других текстовых движков шапочно. Мейнтейнеры подобных движков, известные мне, все с бэкграундом в CS и при этом достаточно упоротые чтобы продолжать специализироваться в C++ со временем. А у вас так легко, взял из бокса вкатился, пилит
constexpr <auto> template MyLineStorage::fetchв кор команде... Кстати его ответ "Как пришёл в IT" освещает что угодно, но только не как он пришёл в IT."У вас нет контейнера для запуска гадости или вы не можете его создать за 5 минут, вы нам не подходите, прощайте".
Гм, не совсем. Несколькими страницами ниже:
"Пишется на ограниченном диалекте C" != "пишется на си".
Про Lean не в курсе, но Coq (закрою глаза на то, что это ЯП, а не система символьного вывода) является реализацией исчисления конструкций и следовательно подвержен всем ограничениям исчисления конструкций, например в Coq является выводимым парадокс Карри:
Нет таких символьных систем, в которых можно непротиворечиво вывести всю математику. Во-первых никто толком не договорился об аксиоматике (поэтому собственно и возможен мой пример выше), во-вторых есть теоремы Гёделя о неполноте.
Для программ и доказательств, записанных на формально верифицируемом языке. Что на сегодняшний день равняется 2.5 академическим ЯП в области программирования и примерно 0 универсальных формальных систем в области чистой математики.
Новое слово в системном программировании... FYI если в программе нет вызова exit и т.д., то проц просто продолжает выполнять опкоды, расположенные за программой в памяти. Как правило это заканчивается тем, что он выполняет что-то в non executable области, и как следствие segfault. Но всякое бывает, может случайно и сискол exit выполниться. Никакого "принудительного уничтожения" таких программ в Linux нет, их поведение просто не определено.
В целом как-то многовато пафоса для, видимо, набора типа "высокоуровневых" макросов для опкодов x86-64?
критиковал не столько решения openai, сколько язык записи доказательств у openai =) Само по себе решение #1 от openai, как оказалось, верное - перепроверил после всех разъяснений.
У Google значительно лучше, как минимум понятнее. В решении #1 тоже не нашёл ошибок.