Не человек для автокомплита, а автокомплит для человека.

А вот погрешности контролировать Х-ль как раз не может пока.

я сравнивал различные кодогенераторы и хаки... так что это не совсем честное сравнение)

Чтобы инструмент приносил пользу, его нужно правильно применять

Да. И в типичном аналитическом notebook на три странички он должен работать в связке с repl.

То, что прочитано ядром, попадает в autocomplete.

Коллеги, а правда, прокомментируйте положение дел с языком V. Лично мне очень понравилась задумка, но компилятор, кажется, целиком состоит из багов. Первое, на что я наткнулся (конечно, после нерабочей самокомпиляции) - это выделение памяти под локальные массивы в куче безо всяких попыток эту память освобождать. Я вообще начинаю сомневаться, что у них есть внятный план по работе с памятью. Но если всё так плохо, откуда такой ажиотаж?
https://github.com/vlang/v/issues/3517

Алекс сказал, что сделает менеджер памяти в компайл тайм, без подсчета ссылок и GC, без концепции владения и RAII как в Rust. Мы все очень этого ждем, потому что тогда и до премии Тьюринга рукой подать;) И да, все это будет делаться без анализа AST, CFG и PDG или какого любого промежуточного представления, потому как в V всего этого нету насколько я помню (хотя может что то и поменялось).

> Но если всё так плохо, откуда такой ажиотаж?
Ажиотаж потому, что Алекс заигрывает с комьюнити гошников и раст-боев, скопировав все ценное от туда (ну кроме менеджера памяти). Посмотри на Vue нарпимер, там такой же принцип - взято все проверенное временем из React и Angular - ну и как результат звед больше чем у этих двух фреймворков) Здесь примерно тоже самое.

А если без дури, то можно сделать то, за что мы любим Rust в ленивом чистом функциональном языке типа Clean или Haskell 98? То есть, выделение почти всего на стеке с хорошим контролем освобождения?

no-syntax, и вообще не списком единым

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

Эмс... Сколько не работаю с вычматом, никогда не сталкивался с ситуацией "без ветвлений". Что я делаю не так? Вычмат - это же не только нейросеточки

Ну и какие там у вас мегаветвления?

Что-нибудь хоть отдалённо похожее на
https://github.com/ocaml/ocaml/blob/trunk/lambda/simplif.ml#L26

есть?

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

Есть проблемы с точностью и т.д., но алгебраическими типами данных это не ловится.

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

Система ownership-borrowing в Rust - частный случай линейных (аффинных) типов. В Clean линейные типы всегда были, в Haskell хотят добавить. Есть пейпер, но фактически встроить в GHC - сложно. Поэтому пока ждём-с.

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

вот если только типы менять на императивные в оптимизаторе...

Не только. В Хаскеле есть и императивные структуры - массивы, вектора и прочие матрицы. Они могут заоптимизироваться "из коробки", когда линейщину втащат.