Вот автор поставил тэг «я пиарюсь», но пиарится он плохо.

Я поставил этот тэг потому что кинул ссылку на личный youtube канал, а на некоторых форумах, если ты кидаешь ссылку на личный блог, без тега «я пиарюсь» могут бан выписать. Если память не изменяет, то на каком то сайте прям в правилах это написано.

Нигде. Из 12 предыдущих, компиляторов я публиковал только два, остальные посчитал недостойными публикации.

В будущем я планирую написать утилиту которая превращает такие файлы в веб-страницы с ссылками.

Можно воспользоваться уже существующими на AutoIt3 и PureBasic.

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

А если бы факторов не было, то и врать не надо было бы. Так же не надо было бы врать, если бы был фактор, который бы нивелировал другие. Например, таким фактором могут быть исходники Вашего языка на гитхабе. С ними намного выше шанс получить работу. Есть они в резюме? Обсуждали их на собеседованиях?

Григорий Бакунов

Да, помню, слушал его лет пять назад. Тогда он рекламировал переезд в Киев, как лучшее место для программиста.

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

Всё правильно, на собеседовании можно узнать 5-10% и даже ошибиться. У меня в коллективе надо было минимум 2 года работать, чтобы выстроить отношения, чтобы вызвать доверие. Во первых я могу не ответить на вопросы, но при этом хорошо разбираться, например возникает какая то новая неисправность, я исследую её, то есть спроси меня сейчас и я выгляжу как тупой, проходит сутки, я даю расклад как гений. А на собеседовании, как пример, дают мне схему, типа умеешь читать, а схемы они же бывают разные, упрощённые справа налево сверху вниз и сложные от центра в стороны и по-кругу с зависимостями и кондуитом, то есть по факту на начальном этапе ты можешь сказать, что это диод, это транзистор, было даже такое: электрики, которые теоретически не разбираются в полупроводниковой электронике спрашивают меня про их специфический автомат срабатывания по току, видят что я плаваю, но при этом они по чему то думают что знание их автомата это знает каждый тупой электрик или простой чел, который явно дома проводил проводку и они меня запороли, что я не подхожу, то есть разбирающийся в полупроводниковых элементах схем, могущий сделать расчёт стабилизатора напряжения и тока не подходит у них для прокладки проводов.

А если бы факторов не было, то и врать не надо было бы.

Разумеется, но они есть.

Так же не надо было бы врать, если бы был фактор, который бы нивелировал другие.

Нет, это не так работает. Я уже приводил ссылку на исследование которое показывает, что HR'ы тратят на резюме менее 10 секунд (https://www.wonsulting.com/job-search-hub/hidden-eye-tracker-how-recruiters-actually-read-resumes). Может на вашем заводе - нет, но везде есть исключения. У меня на одной из работ позвали в офис и не далеко я видел как отсеиваются кандидат, там за 1 минуту кандидатов 15 получили отказ, причём там были не резюме, а выдернутые из резюме: образование, пол, возраст. В начале в резюме ищут негатив, позитив будет искаться в оставшихся.

Например, таким фактором могут быть исходники Вашего языка на гитхабе.

Я прикладывал когда-то ссылку на github одного из моих предыдущих языков, HR вообще не понимает, что это, а у тех кто проводит технической собеседование, даже моего резюме не было. В том конкретно случает я прошёл HR'а, только по тому, что меня порекомендовал уже работающий там человек. Лет 10 назад читал на каком то форуме тему и в этой теме начали обсуждать нужен ли профиль на гит репозиторий, и к той теме присоединились HR'ы, одна сказала что не рассматривает кандидатов у которых нет ссылки на github в резюме, притом призналась, что по ссылке она никогда не переходит, вторая сказала без разницы, а третья сказала, что не берёт кандидатов у которых есть хобби проекты.

исследование которое показывает, что HR’ы тратят на резюме менее 10 секунд

Это «средняя температура по больнице». Везде люди разные, в каждой организации свои обстоятельства. И кадровиков, и технических специалистов не штампуют одинаковых где-то на фабрике. Если долго ходить по собеседованиям, то рано или поздно куда-нибудь возьмут. Вопрос только в том устроит ли Вас это «куда-нибудь».

Ушел от интерпретируемых языков ради скорости. Хоть и прямой доступ к памяти по указателям может вызывать ошибки, но это быстрый способ работы со строкой.

а третья сказала, что не берёт кандидатов у которых есть хобби проекты.

Хорошо, что вовремя сказала. Такие фирмы надо отсеивать на этапе трудоустройства.

По видео, уже несколько раз сказали - это дико не удобно слушать, когда можно прочесть

Видео

В видео много разных категоричных утверждений разберу их

мотив про IR

про временное представление LLVM/IR, вы же в курсе про jit, а этих вариантов jit только в java из коробки два C1, C2 быстрый и «медленный» компиляторы из JVM byte code в asm в runtime

читаемость

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

мое категоричное утверждение: не существует идеальной читабельности в принципе, и в принципе она не достижима никогда, доказательство я опущу

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

не явные параметры и преобразования ухудшают читаемость

я бы посоветовал обратить внимание на 2 языка rust scala

в rust делается компромис, там синтаксис и грамматика вывод типов спроектированы так, что бы не потерять окончательную читаемость, например границы trait/impl/crate

а scala этих границ нет, там ровно на оборот, есть implicit/given/… там легко в рамках scala создать свой dsl например basic или sql с сохранением семантики basic и это являться обоюдно острым инструментом

уже на лицо разные сообщества подходят к вопросу по разному

генерация кода в compile time

опять же, это не прихоть появление таких инструментов, это прямая необходимость на оборот, лучше посмотреть как люди решают этот вопрос из известных мне, которые еще помню

• groovy - там целый раздел про Метапрограммирование, жаль что система типизации не богатая
• java - процессоры аннотаций, они достаточно сильны и не ломают поведение, мало нареканий, но речь именно о про процессор аннотаций, а не генераторов кода в runtime на основе аннотаций (ака рефлексия и вытекающие последствия)
• rust их api предоставляет работу с исходниками, но только как потоком лексем, а не деревом
• scala - может работать с деревом, но у них есть еще хорошая типизация, которая позволяет добиваться сходных результатов не прибегая к макросам, rust потенциально способен так же, но пока не до этого им

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

Про сам язык

Синтаксис меня не сильно интересует, я его не буду рассматривать, тут каждый волен придумывать кто как может, важно только наличие формального описания в виде eBNF или другой грамматики типа Antlr 4

Для меня в языке в первую очередь, это типы и типизация слова про то, что есть динамическая или статическая типизация или смешанная не сильно раскрывает суть языка, есть же еще примерно боооольшой список возможных типизаций, например линейная, или Ad-hoc полиморфизм/Строгая-Статическая-утиная

если взять тот же rust и сказать что там статическая типизация, это ничего не сказать, это не сказать что она имеет borrow-checker, что имеет признаки линейной типизации, что несколько разных полиморфизмов impl Tait/dyn Trait/ad-hoc.. и опять же в rust это не блажь, а блажь это Zero-cost abstraction

Вот Zero-cost и как это было достигнуто, какие решения были приняты мне rust нравится (надежность + возможности), и как были приняты async\await - воообще не нравится, и не только мне, а например китайцу который запилил may v0.3.51 Rust Stackful Coroutine Library

К чему я это пишу…

Языки прикольно создавать, сам пробовал, но исключительно для самообразования, были вторичные выгоды - в виде опыта, который на Проде применял

Язык главным образом - для меня, но может подойти многим другим энтузиастам, но чтобы понять подходит ли он кому либо, нужно попробовать его и тогда станет понятно, подходит он конкретному человеку или нет

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

Я даже программистом никогда не работал, а в основном грузчиком, сторожем, комплектовщиком. Программирование для меня это хобби, вот уже 25 лет, я трачу почти всё своё свободное время на него

Как я понял вы не работали именно с программистами продолжительно, с теми что работал, я могу сказать что многие из них не особо задумываются о языке, а чаще о выполнении своей рабочей задачи в срок, по мне это нормально, небольшое кол-во, как сделать быстрее, и совсем уж мало кто критикует свой основной рабочий язык программирования

И под «помощью» я не имею ввиду помощь в непосредственно разработке языка, с эти я прекрасно сам справляюсь, а под помощью например: поиском ошибок созданием библиотек финансовая помощь распространение

вот что бы достичь тех четырех пунктов помощи, необходимо заинтересовать людей, а на сколько часто я встречал людей, то люди обычно не любят тратить свое время не получая в замен чего то, хотя бы удовольствия

я вижу только несколько вариантов - платить или сделать полезное им, в их работе

Читаемость

вообще может быть разная…

не явные параметры и преобразования ухудшают читаемость

я бы посоветовал…

генерация кода в compile time

опять же, это не прихоть… лучше посмотреть как люди решают этот вопрос из известных мне…

Про сам язык

Синтаксис меня не сильно интересует

К чему я это пишу…

Языки прикольно создавать

вы же в курсе про jit

Да. Когда я делал свой первый язык, я взял LLVM потому, что он назывался LLVM (Low Level Virtual Machine) и как я понимаю разработчики действительно собирались делать виртуальную машину, но в последствии решили переделать проект в инфраструктуру для создания компиляторов, оставив название LLVM, но теперь это не аббревиатура. В последствии я отказался от идеи jit компилятора как основного способа компиляции (но планирую сделать его для быстрого запуска debug сборок и создания плагинов для программ), так как jit-компиляция увеличивает время старта приложения, а увеличивая оптимизацию, увеличивается время компиляции и потребляемая память, что негативно сказывается на опыте использования приложения, а при уменьшении оптимизации, соответственно программа работает медленнее, так же в рантейме постоянно должен висеть jit-компилятор.

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

Я и не утверждал, что читаемость - объективный термин. По моему мнению, в этом мире почти всё субъективно! Я иногда вижу как люди называют читаемым то, что я считаю не читаемым. На github указанно:

Why was the language created?
...
2. No existing language met the author's requirements, so the language was created. Requirements:
...
Simple and readable syntax.

То есть я создал язык под свои требования, в том числе и под свои представления о читаемости.

уже на лицо разные сообщества подходят к вопросу по разному

Сколько людей, столько и мнений. Это не новость.

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

Вы указывали на то, что читаемость - термин субъективный, а теперь говорите, что генерация кода в компайл-тайме необходимость? Нет! Это тоже субъективно! Вы привели примеры языков с генерацией кода в компайл-тайме, а я в ответ приведу в пример язык go, который активно используется в продакшене, которому уже почти 20 лет (на самом деле больше, но опустим это), который является одним из самых популярных языков на сегодня и в нём нет генерации кода в компайл-тайме. Наличие только лишь одного go уже указывает на то, что нет, это не необходимость.

важно только наличие формального описания в виде eBNF или другой грамматики типа Antlr 4

У scar его нет, там парсер самописный.

слова про то, что есть динамическая или статическая типизация или смешанная не сильно раскрывает суть языка

Так в этом и суть! В описании нужно кратко описать язык, чтобы у людей было поверхностное представление «что к чему», а если человек хочет сильного раскрытия сути языка, то ему нужно читать документацию, смотреть примеры, в конце-концов компилятор написан на scar, можно посмотреть исходники компилятора (как пример кода на scar).

а блажь это Zero-cost abstraction

Синонимы слова блажь - причуда, каприз, дурь, нелепость. Вы это имели ввиду?

достаточно иметь опыт на смеженных языках

Не согласен. Во первых, смежный язык - термин субъективный. Во вторых, Haskell и OCaml с моей точки зрения смежные языки, но Haskell мне скорей понравился, а вот OCaml - скорее нет.

Как я понял вы не работали именно с программистами продолжительно

Я сам не работал программистом и среди моих знакомых и друзей нет программистов. Я просто разрабатываю приложения в своё свободное время. Из моих знакомых только два человека вообще программируют (один web на js, второй пишет для микроконтроллеров, при этом второй как программист достаточно слаб, он больше про пайку, схемы и т.д.)

я могу сказать что многие из них не особо задумываются о языке

Во всём этом треде, я программирование рассматриваю как хобби и искусство, а не как профессию. Мои знания о программировании как профессии, основаны на подкастах, видео про программировании и записях с конференций. Исходя из этих знаний, большинству программистов программирование как таковое не интересно, их интересуют только деньги и если им за программирование не будут платить, пет-проекты в свободное время они создавать не будут.

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

Так я если и ищу кого, то тех которые ради удовольствия.

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

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

Вы указывали на то, что читаемость - термин субъективный, а теперь говорите, что генерация кода в компайл-тайме необходимость?

да именно так, классическая задача delegate например, задача тривиальная но требует boilerplate, а boilerplate не улучшает читабельность, а ровно на оборот

а я в ответ приведу в пример язык go, который активно используется в продакшене, которому уже почти 20 лет (на самом деле больше, но опустим это), который является одним из самых популярных языков на сегодня и в нём нет генерации кода в компайл-тайме.

в ответ я возьму избитое - его обработку ошибок

func ReadConfig(path string) (Config, error) {
    // 1. Открытие файла
    file, err := os.Open(path)
    if err != nil {
	    return Config{}, fmt.Errorf("open config file: %w", err)
    }
    defer file.Close() // ошибки Close обычно логируются отдельно

    // 2. Декодирование JSON
    var cfg Config
    if err := json.NewDecoder(file).Decode(&cfg); err != nil {
	    return Config{}, fmt.Errorf("decode config: %w", err)
    }

    // 3. Валидация
    if err := validateConfig(cfg); err != nil {
	    return Config{}, fmt.Errorf("validate config: %w", err)
    }

    return cfg, nil
}

вот эти все err можно было бы ужать до exception и/или до прокидываение err как в rust

отсуствие сложных макросов в go это недостаток, а не достоинство проблема опять же в понимании слова четабельность

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

Наличие только лишь одного go уже указывает на то, что нет, это не необходимость

вообще странный вывод, то что язык популярный, как из этого следует что он хороший, вообще не вижу логического вывода, 1С, PHP популярный был, Python, … и т.д. сказать что там нет макросов, а значит это лишнее… ну для меня не очевидно, мало ли в каких языках чего нет или есть

а блажь это Zero-cost abstraction Синонимы слова блажь - причуда, каприз, дурь, нелепость. Вы это имели ввиду?

да, за исключением слов: дурь, нелепость

достаточно иметь опыт на смеженных языках Не согласен. Во первых, смежный язык - термин субъективный. Во вторых, Haskell и OCaml с моей точки зрения смежные языки, но Haskell мне скорей понравился, а вот OCaml - скорее нет.

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

У scar его нет, там парсер самописный. В чем проблема составить описание ? eBNF большинство людей знакомы и eBNF легко понять и через eBNF легче изучить не знакомый язык, можно например не обязательно eBNF.

А вот если я сейчас захочу изучить язык, то мне ничего не остается кроме как взять исходники и натравить на них LLM , что бы вычислить eBNF, а LLM еще наврет где-то

чтобы у людей было поверхностное представление «что к чему», а если человек хочет сильного раскрытия сути языка, то ему нужно читать документацию, смотреть примеры, в конце-концов компилятор написан на scar, можно посмотреть исходники компилятора (как пример кода на scar)

ну ребус еще тот, если я и так не понимаю принципиально чем он отличается от C/go/python кроме особого синтаксиса и отсутствием gc, но не понимаю в плане гарантий, то гадать ребус ну… такое… то еще удовольствие

те же доки по rust / java там вот люди прям стараются описать, чем их языки хороши, чем они отличаются, у некоторых даже спецификации есть

а тут тайнопись

Так я если и ищу кого, то тех которые ради удовольствия.

воооооот, а давай те поменяемся на секунду, в воображении местами

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

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

я лично не знаю, согласитесь вы или нет

Но лично я наигрался в изучении языков, мне сейчас интересно изучать например не языки программирования общего назначаения, а например прикладные части, например нотную партитуру представить как помесь двух языков, языков - данных - разметки и языка программирования этих данных и все в рамках своей среды разработки музыки. А общие языки программирования - да, они прикольные, например Coq/Idris/Agda по изучать не против был из за их типизации, и только из за их типизации, но не более

на счет смеженности языков программирования - почему же он субъективный ?

формально нам никто не мешает взять пару языков

• спецификацию языка
• или исходники языка

и построить оооочень большую сравнительную таблицу

• таблицу сравнения типизации
• таблицу сравнения AST и типизированного AST
• таблицу сравнения синтаксиса
• таблицу сравнение фаз компиляции
• таблицу сравнение типичных задач bootstrap/loading фаз в runtime
• таблицу возможностей отладки + hotreload

и так далее….

и все это будет объективно, все это будет сооизмеримо

а зайдет ли тот или иной способ написания программ, зависит от самого человека, на сколько он имеет понимание и опыт

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

а я в ответ приведу в пример язык go, … который является одним из самых популярных языков на сегодня и в нём нет генерации кода в компайл-тайме

Не является популярным. Если смотреть на tiobe, то он даже не в десятке, несмотря на то, что за ним стоит корпорация и он активно пиарился какое-то время. И ниша у него довольно узкая.

Как ни странно, более популярным языком является Scratch. У него тоже нет «генерации кода в компайл-тайме», но это потому что он вынужден быть примитивным. Зато у него есть аж две ниши, в которых он используется - обучение детей программированию и робототехника. У Go одна ниша. Вероятно, поэтому он и проигрывает.

Кроме того, встречал статьи, что разработчики на Go используют кодогенераторы, чтобы обойти ограничения по генерации кода. То есть вынуждены использовать костыли.

а boilerplate не улучшает читабельность, а ровно на оборот

Мы уже согласились, что читаемость - субъективное понятие. Поэтому не вижу смысла дальше обсуждать читаемость. Скажу лишь, что для меня, иногда boilerplate улучшает читаемость, а его замена на например макрос - ухудшает. И я видел такое не раз. По мне генерация кода в во время компиляции, это про упрощение написания кода, а не улучшение его читаемости.

в ответ я возьму избитое - его обработку ошибок

Так я и не приводил go, как пример читаемого языка. Вы сказали что генерация кода во время компиляции это необходимость и как аргумент этого, привели в пример популярные языки в которых она есть, а значит это необходимость. Я же вам ответил, что это субъективно и по вашей же логике если в популярном языке нет генерации кода во время компиляции - значит такой необходимости нет. И я привел вам в пример go, как язык в котором нет генерации кода во время компиляции и при этом он популярен. То как go обрабатываются ошибки, мне совершенно не нравится, в scar ошибки обрабатываются по другому.

отсуствие сложных макросов в go это недостаток, а не достоинство проблема опять же в понимании слова четабельность

И это ваше субъективное мнение. На одной конференции видел человека, который программирует на go и он прям расхваливал обработку ошибок go.

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

Согласен. Но в видео я критиковал генерацию кода во время компиляции (включая макросы) не за читаемость. Я сказал что это очень точечный механизм, который редко должен использоваться, но когда он появляется в языке, все его начинают использовать даже там, где этого не стоит делать (я не исключение), что в последствии приводит к появлению ошибок которые очень сложно исправить, а также замедлению скорости компиляции.

вообще странный вывод, то что язык популярный, как из этого следует что он хороший

Не следует. И я такого вывода не делал. Вы мне привели пример популярных языков программирования, и написали что в них есть генерация кода, значит «указывают ровно на одно, это необходимость генерировать код» привёл цитату дословно. И я воспользовавшись вашей же логикой, привёл в пример go.

мало ли в каких языках чего нет или есть

Вот именно! Зачем вы мне тогда приводили в приме какие то языки, обосновывая своё мнение в отношении генерации кода?

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

Оно не мешает, это делает не возможным. Не изучая OCaml, но просто бегло посмотря на него, я бы оценил его как похожий на Haskell, т.е. - неплохой язык. Но попробовав OCaml, мне он не понравился. Следовательно чтобы понять нравится ли кому-либо язык, на нём нужно хотя бы не много по программировать.

А вот если я сейчас захочу изучить язык, то мне ничего не остается кроме как взять исходники и натравить на них LLM, что бы вычислить eBNF, а LLM еще наврет где-то

eBNF поможет только с изучением синтаксиса языка. А синтаксис достаточно неплохо описан в документации, а если что то стало не понятно, то LLM для этого будет куда менее полезным, чем банальный поиск слов (if, switch и т.д.), с которыми связанны непонятки, в исходниках компилятора и примерах.

те же доки по rust / java там вот люди прям стараются описать, чем их языки хороши, чем они отличаются, у некоторых даже спецификации есть

Вы сравниваете документацию языка, компилятор которого вышел менее месяца назад, который развивается силами одного человека в свободное время, с языками которым уже много лет и которые имеют большое комьюнити? Имейте совесть!

я лично не знаю, согласитесь вы или нет

Я в такой ситуации был не раз. В начале я читаю краткое описание, если в ней есть грин флаги, но нет ред флагов. Читаю документацию если всё устраивает пробую.

Но лично я наигрался в изучении языков, мне сейчас интересно изучать например не языки программирования общего назначаения, а например

Вам не понравилось то, что в описании вы не нашли интересующие вас ответы, а теперь задайтесь вопросом, зачем мне тратить время на то, чтобы описать подробности, которые нужны тем, кто мой язык использовать не собирается?

на счет смеженности языков программирования - почему же он субъективный ?
...
и построить оооочень большую сравнительную таблицу

Какие пункты будут в таблице - зависит от человека который будет их вносить. Уже субъективно, но продолжим.

таблицу сравнения типизации

Если типизации похожи, но не идентичны. Один человек скажет, изменения не значительны, второй скажет значительны. Субъективно.

таблицу сравнения AST и типизированного AST

То же самое. Что и прошлый пункт.

таблицу сравнения синтаксиса

Тут ещё всё проще, синтаксис двух языков всегда отличается, а значит всегда будут отличия, а следовательно - один человек скажет, изменения не значительны, второй скажет значительны. Субъективно.

таблицу сравнение фаз компиляции

таблицу сравнение типичных задач bootstrap/loading фаз в runtime

таблицу возможностей отладки + hotreload

Это вообще не про язык, а про компилятор и рантайм. Пока не вижу ни одного пункта, по которому можно сравнить объективна.

Не является популярным. Если смотреть на tiobe, то он даже не в десятке, несмотря на то, что за ним стоит корпорация и он активно пиарился какое-то время.

Только ленивый не критиковал рейтинг tiobe, он же оценивает по поисковым запросам, что в свою очередь очень опосредованно связанно с популярностью. Представьте 2-х людей, один человек изучает go, второй rust, как вы думаете, кто из них больше запросов сгенерирует? Какие то люди вообще могут смотреть документацию локально и это может коррелировать с языком, например для языка есть специализированная ide с документацией. Но даже по это рейтингу tiobe, он на 16 месте, а языков программирования примерно 8000-9000. Это очень популярный язык.

Кроме того, встречал статьи, что разработчики на Go используют кодогенераторы, чтобы обойти ограничения по генерации кода. То есть вынуждены использовать костыли.

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

Вам не понравилось то, что в описании вы не нашли интересующие вас ответы, а теперь задайтесь вопросом, зачем мне тратить время на то, чтобы описать подробности, которые нужны тем, кто мой язык использовать не собирается?

тогда как это согласуется с

Так я если и ищу кого, то тех которые ради удовольствия.

если надо гадать ребус, документации которой нет

опять же, если весь язык исключительно для вашего удовольствия, то зачем его публиковать, если его нельзя критиковать ? или можно ?

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

Я посмотрел документацию, но ее мало и есть вот ряд вопросов,

• про ссылки Я тут свой язык создал (комментарий)
• что на счет null / npe / если их не будет, то будет ли Optional<>
• что на счет параметрических типов, generic
• что на счет типизации на основании параметров типов / ad hoc, когда для Optional надо метод plus(), а для Optional надо метод and()
• что на счет отложенного выведения типов на основании параметров типов
• что на счет перегрузки операторов, добавления собственных, переопределения приоритетов
• что на счет выражения различных иерархий в типах, ООП, like OOP
• как там с функциональностью и контролем чистоты, какой механизм доказательства
• что на счет stackless/stackfull corutine, будут ли async / await или будет нормальная многопоточность
• будут ли типы линейными как rust или еще какими
• что на счет разных backend : wasm / native / jvm / microsoft dotnet ir / custom
• что на счет рефлексии хоть какой то, хоть runtime хоть compile time
• как сделать подключемую GC, что бы не противоречила выше сказанному
• что на счет инструментов проверки границ модулей, что они не превышают границ security, не дергают недопустимые api
• что на счет метрик и наблюдения за работой
• на сколько синтаксис и типы гибки что бы создавать внутренний dsl
• что там с управляющими конструкциями, async/throw/pattern matching
• что на счет interop с другими языками и средами
• на сколько легко выразить сложные составные типы, например гетерогенные списки, деревья и обрабатывать их
• есть ли language server для разработки, с поддержкой debug

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

в документации я ответов не нашол, видать плохо искал

Вам не понравилось то, что в описании вы не нашли интересующие вас ответы, а теперь задайтесь вопросом, зачем мне тратить время на то, чтобы описать подробности, которые нужны тем, кто мой язык использовать не собирается?

тогда как это согласуется с

Так я если и ищу кого, то тех которые ради удовольствия.

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

если надо гадать ребус

Какой?

документации которой нет

Так вот же https://github.com/Alexander-Goto/scarlet/tree/main/doc/ru

если весь язык исключительно для вашего удовольствия

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

то зачем его публиковать

А может кому будет полезно. Я не думаю что я один в мире кому нужны идеи реализованные в этом языке.

если его нельзя критиковать ? или можно ?

Если бы было нельзя, то вы были бы в игнор листе. А поскольку я вам отвечаю - можно. Хотя наверно зря я отвечаю, пока выглядит как бесполезное занятие.

что на счет рекурсивных структур, если нет GC, то должны быть WeakRef, если их нет, то задать рекурсивные структуры уже будет проблемой

Рекурсивных структур нет и не планируется. Уже много лет как я не использую рекурсивные структуры и до сих пор никаких проблем. Вот комментарии в котором все описано немного подробнее:
https://www.linux.org.ru/forum/development/18274221?cid=18276123 (комментарий)
https://www.linux.org.ru/forum/development/18274221?cid=18277141 (комментарий).

Не могу ответить одним комментом, лор говорит «Слишком большое сообщение» поэтому за два.

что на счет null

Из документации:

null - отсутствие значения. Используется если нужно указать, что никакого значения нет, например если функция ничего не возвращает в качестве результата, то она должна вернуть null. Из константы типа null можно вызывать методы (подробнее о методах в типе obj), такой вызов не вычисляет свои аргументы и всегда возвращает null. null может использоваться в качестве константы для оператора new, в этом случае если ключ является токеном, то null станет объектом без полей, иначе таблицей без элементов.

null можно распаковывать, при распаковке указав любой тип, в этом случае все локальные константы имеют значение null.

null воспринимается как отсутствие значения. В array null хранить нельзя, в table если создавать table с помощью [table k = null] - то это ошибка, а если попытаться добавить null в качестве значения, то это просто удаляет элемент. Вообще null нигде нельзя хранить кроме некоторых особых типов (например box).

npe

Как уже указанно «Из константы типа null можно вызывать методы (подробнее о методах в типе obj), такой вызов не вычисляет свои аргументы и всегда возвращает null.» Например:

let a = null->mtd(println("Hello")) # a - null, println - не выполняется

Программа оптимизируется таким образом, как если в программе никогда не происходит ошибок, но если это случится, то программа отработает корректно.
Если записать ошибку в любую структуру данных, то такая структура станет данной ошибкой.
Если в оператор new в качестве константы, ключа или значения передать ошибку, то оператор вернёт данную ошибку.
Если в оператор if в качестве предикаты передать ошибку, то оператор вернёт данную ошибку.
Если в оператор switch в качестве выражения на основании которого делается выбор передать ошибку, то оператор вернёт данную ошибку.
Если метод вызывается из ошибки, то аргументы не вычисляются, а результатом будет данная ошибка.
Если происходит распаковка типа не являющегося ошибкой, но распаковываемая константа является ошибкой, то все созданные локальные константы становятся данной ошибкой.
Если несколько ошибок переданы в такие места, в которых выражение вернёт ошибку, то возвращается ошибка, выражение которой должно вычистился первым.
Если функция main из модуля main возвращает ошибку, то программа выводит на экран данную ошибку.

То есть ошибка начинает распространятся как вирус, превращая всё (почти) в себя.

то будет ли Optional<>

Язык динамически типизированный, в optional не смысла. Например:

let a = if (rnd() & 1 ) == 1; 1 else null # a - или 1 или null

что на счет параметрических типов, generic

Мне стало интересно, а существуют ли языки с динамической типизацией и дженериками, поскольку для меня такое сочетание не особо имеет смысл. Я спросил у нейронки вот отрывки из ответа:

Да, такие языки существуют. Хотя кажется, что в динамической типизации нет необходимости в обобщениях (generics)

Python: строгая аннотация в динамическом мире

Ну это не совсем то, это просто аннотации, а не полноценные дженерики.

Groovy: динамика с Java-совместимостью
...который поддерживает синтаксис обобщений для лучшей совместимости с Java-кодом. Как и в Java, информация о generic-типах в Groovy стирается во время выполнения (type erasure)

Т.е. только для совместимости с Java.

Julia: производительность через параметризацию

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

Smalltalk (Pharo): обобщения через расширение

Ок. Про Pharo я знал, но быстро нашёл в нём ред флаги, поэтому не углублялся. Засчитываю.
Дженерики в языках с динамической типизацией - редкость, они там попросту не особо нужны. В scar их нет. В scar вообще есть только несколько встроенных типов, а пользователи могут создавать только прототипы (с оговорками, но всё же). Отрывок из readme «Scar is a functional language with support for prototype-based programming.». Про прототипы забыл написать в документации - исправлю. Я кстати выпустил видео, про оптимизацию которая используется в scarlet и там подробнее рассказывается про прототипы - https://www.youtube.com/watch?v=BdJ39wkP8r8. В видео есть косяк (который описан в описании) я отправил в llvm реквест на 3 оптимизации оператора switch, но плохо протестировал одну из них, из-за чего она оптимизировала производительность (в 4 раза) и потребление памяти (на простом примере экономился 1 килобайт, что влияло на промахи кэша), но в большинстве случаев, она замедлит оператор switch на 4 процента, но память всё ещё экономит. Вторая оптимизация была связанна с первой, поэтому я из реквеста удалил их, оставив только ту, о которой в видео рассказывается (она на бенчмарке увеличила производительность примерно в 2 раза).

что на счет типизации на основании параметров типов / ad hoc, когда для Optional надо метод plus(), а для Optional надо метод and()

Одна функция в scar == одна функция в памяти, независимо от типов. Любая функция в scar может принимать любой тип. Пример:

fn foo(arg_0, arg_1) arg_0 + arg_1
fn main() {
     foo(1, 2).type().println()     # выведет core.int
     foo(1.0, 2.0).type().println() # выведет core.float
     foo("1", "2").println()        # в foo передаются строки, строки передаются в функцию (+),
                                    #   которая складывает числа, строка - не число,
                                    #   поэтому функция (+) возвращает ошибку,
                                    #   функция foo возвращает эту же ошибку,
                                    #   ошибка передаётся в функцию println,
                                    #   println не работает с ошибками, поэтому возвращает переданную ей ошибку
                                    #   и функция main возвращает ошибку, тем самым программа завершается с этой ошибкой.
}

что на счет отложенного выведения типов на основании параметров типов

В scar нет вывода типов.

что на счет перегрузки операторов, добавления собственных, переопределения приоритетов

Для меня возможность добавление собственных операторов - антипатерн. Например я изучал исходный код одной программы на Haskell (где такая возможность есть) и там был опертор <==&&==>. Такой оператор не является стандартным и вообще не было понятно что он делает.
Теперь нужно пояснить, что в scar «+ - * /» называются функциями и имеют поведение функций, а операторы это например «&& || <?». В scar многие функции из модуля core (а все функции состоящие не из букв принадлежат этому модулю) могут принимать объекты с определёнными методами. Например:

let t_some = [obj
     :a = 0
     :b = 0

     :_ = [obj
          :core___add__ = fn (obj_0, obj_1) {
               let [obj a = :a, b = :b] = obj_1
               new (obj_0) {
                    :a => _ + a
                    :b => _ + b
               }
          }
     ]
]

fn main() {
     let obj = new (@main.t_some) {:a <= 4; :b <= 7}
     println(obj + obj)
}

что на счет выражения различных иерархий в типах, ООП, like OOP

Ну как я написал выше, есть прототипное программирование, с методами. Так же есть наследованием и интерфейсы. Наследование осуществляется с помощью функции - inherits_from (core), а добавление прототипа в интерфейс осуществляется с помощью функции - implement (core).

как там с функциональностью

Язык в функциональный - иммутабельности, лямбда функции. Всё как положено.

и контролем чистоты

Нет контроля.

что на счет stackless/stackfull corutine

Корутины не планируются.

будут ли async / await

Не планируется.

будет нормальная многопоточность

Уже есть. Ищите в документацию слова thread и channel. Единственное что нигде не указанно, это то, что когда поток завершает свою работы, он становится на какое то время не активным (по умолчанию 60 сек) и если в это время потребуется еще поток, то он проснётся и выполнит новую работу, без дорогостоящей инициализации потока.

будут ли типы линейными как rust или еще какими

Нет. С учётом иммутабельных данных, такое не особо нужно, а там где нужно, уже реализованно (например типы thread или box)

wasm / native / jvm / microsoft dotnet ir / custom

wasm - возможно, но не скоро. Точно не приоритет. native - полученный сишный файл, можно хоть сейчас в бинарник превращать и распространять бинарником. остальное не планируется.

что на счет рефлексии хоть какой то, хоть runtime хоть compile time

Она уже шикарная сейчас. Тот же тип obj, это просто ассоциативный массив и с ним без проблем можно делать такое.

fn main() {
     [obj
          :x = 1.0
          :y = 2.0
          :z = 3.0
     ].foldl_kv(null, fn (_, name, field)
          println(
               "name  - " ++ name.to_string() ++ "\n" ++
               "field - " ++ field.to_string()
          )
     )
}

name  - y
field - 2.0
name  - z
field - 3.0
name  - x
field - 1.0

как сделать подключемую GC

Никак. И такой возможности не будет.

что на счет инструментов проверки границ модулей, что они не превышают границ security, не дергают недопустимые api

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

что на счет метрик и наблюдения за работой

Это по любому будет, но сейчас ничего нет.

на сколько синтаксис и типы гибки что бы создавать внутренний dsl

Язык создавался достаточно гибким, чтобы ему не нужен был dsl.

что там с управляющими конструкциями, async/throw/pattern matching

async throw - уже отвечал выше (в этом комментарии). А pattern matching - полноценный планируется, а сечас есть расспаковки (немного похоже) - «let [array a, b, c] = [array 1, 2, 3]».

что на счет interop с другими языками и средами

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

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

Легко. В scar и индексные и ассоциативные массивы и множества - гетерогенные. А вот гомогенных нет.

есть ли language server для разработки, с поддержкой debug

Вообще нет никакого.

Язык динамически типизированный, в optional не смысла.

ну вот не верно, путаница у вас, у вас в данном случае типичная не строгая типизация

динамический язык, они же скриптовые, они же интерпретируемые (js,python) или статический язык (go,pascal,java,…) это ортогональное свойство языка

optional<> нужен именно что бы не путать наличие и отсутствие значения со самим значением вот именно для этого и нужен Optional<> - увеличивать надежность программ, а еще лучше на раннем этапе т.е. в compile time - что бы отсекать заведомо программы с багами

а интерпретиуемый он там или компилируемый - на типизацию опосредованно влияет

let a = if (rnd() & 1 ) == 1; 1 else null # a - или 1 или null

такая конструкция снижает понимание какого типа и не дает гарантий надежности, если явно не проверять на null, а нормальный компилятор со строгой типизацией увидел бы что a - это переменная которую надо проеверять и еще бы доказал, что без проверки ее использовать нельзя

Мне стало интересно, а существуют ли языки с динамической типизацией и дженериками, поскольку для меня такое сочетание не особо имеет смысл. Я спросил у нейронки вот отрывки из ответа:

конечно существуют, например TypeScript, Gluon

Да, такие языки существуют. Хотя кажется, что в динамической типизации нет необходимости в обобщениях (generics) Python: строгая аннотация в динамическом мире Ну это не совсем то, это просто аннотации, а не полноценные дженерики.

ну так LLM вам и не такого еще насоветует

Groovy стирается во время выполнения (type erasure) Т.е. только для совместимости с Java.

так type erasure - это только один из видов generic, а есть еще Мономорфизация C++, Rust,

C# вроде там есть мономорф, но не факт,

и даже имея type erasure в java, в scala наоборот, там не стирают типы (параметры типов), а хранят рядом и они активно используюся в compile time

В scar нет вывода типов.

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

по этому и появился TypeScript, т.к. JavaScript всех задрал с неявными правилами типизации в runtime

добавление собственных операторов - антипатерн

логично, опять же указываю на большие проекты, где могут в явной и не явной форме присутствовать другие языки, как то html, sql, xml, js, и более экзотические языки описывающие предметную область решаемой задачи (BPMN, электроцепи, микросхемы и verylog или как его там, eBNF, ноты, xpath, xquery, xsd, graphql, ..)

прототипное программирование, с методами

как строятся ациклические иерархии типов, как доказывается компилятором что типы сходятся, все это нужно конечно в compile time, опять же в больших проектах с миллионами строк

миллионы строк, это не так много, всего чуть больше 2000 файлов говно кода, и 20+ программистов которые правят код каждый день и имеют по десятку или два конфликтов в git merge в прод

Язык в функциональный - иммутабельности, лямбда функции. Всё как положено. и контролем чистоты

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

что на счет stackless/stackfull corutine Корутины не планируются.

будут ли async / await Не планируется.

будет нормальная многопоточность Уже есть.

ну вот взгляните даже на go, там и то есть ГоРутины, взгляните на java 20 virtual thread, на js async, rust async, c++ co_ чего то там

все это прямая потребность, т.к. thread и channel. это в принципе не хватит ни для чего, т.к. есть проблема 10K называется, и реашиют языки именно Рутинами всякими

Запуск native thread - дорогое удовольствие, а без примитивов синхронизации, без atomic, lock в целом бесполезное, и channel не спасают ни как,

atomic, lock, threads, shared mem - минимум, но он в современных реалях этот минимум без async/rutine в целом писать не удобно, всем не удобно

Нет. С учётом иммутабельных данных, такое не особо нужно, а там где нужно, уже реализованно (например типы thread или box)

опять, оно нужно, что бы ресурсы контролировать например, а не пологаться на магию GC или destructor, а если учесть что нет ссылок или аналогов ссылок + блокровок, то вообще не понятно как делать нормальные, приложения не клепая однотипный код

а клепая однотипный код, придется изобретать макросы или их изобретут другие

Она уже шикарная сейчас. Тот же тип obj, это просто ассоциативный массив и с ним без проблем можно делать такое.

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

опять в больших проектах необходим, где нужна надежность

Язык создавался достаточно гибким, чтобы ему не нужен был dsl.

вот откуда такая уверенность, что вы знаете все предметные области ? часто сам закачик не знает, а вы сразу говорите что таких не бывает

И того

хоть и есть представление о программировании, но вот как его .. программирование используют и какое оно бывает - у нас с вами разное представление

Это очень популярный язык.

Как Go может быть популярен, если он фактически является DSL для написания сетевых приложений. На нём, например, не пишут:

• приложений с GUI,
• приложений со сложной бизнес-логикой, где требуется более развитое ООП,
• приложений машинного обучения,
• игор.

Можно ещё долго продолжать.

Почему так? Потому что он разрабатывался для того, чтобы решить проблемы конкретно Google, чтобы команда не самых лучших разработчиков могла писать приемлемый код для узкой ниши. Чуть отойдёшь от этой ниши и уже неудобно использовать язык.

ну вот не верно

Ваше право.

путаница у вас

Нет.

у вас в данном случае типичная не строгая типизация

Строгая.

динамический язык, они же скриптовые, они же интерпретируемые

Это три разный характеристики. Существуют языки с различными наборами значений этих характеристик.

или статический язык (go,pascal,java,…) это ортогональное свойство языка

Так и есть, Scar - язык со строгой динамической типизацией.

optional<> нужен именно что бы не путать наличие и отсутствие значения

idx.null?() # true - значение отсутствует, false - присутствует, без типа optional

такая конструкция снижает понимание какого типа и не дает гарантий надежности...

Я знаю. И знал это до того как начал создавать scar, даже больше скажу, я об этом знаю больше 20 лет. Scar я сделал таким какой он есть не просто так, это нужно для максимальной гибкости языка.

конечно существуют, например TypeScript, Gluon

TypeScript - статически типизированный язык, с возможностью использовать any когда необходимо.
На официальном сайте Gluon написано: «Gluon is a static, type inferred and embeddabble language written in Rust.».

Дальше желания читать нет! У вас ОЧЕНЬ слабое понимание основ, вы совершенно не понимаете разницу между слабой/сильной, динамической/статической типизацией, но зачем то пытается мне что-то объяснять. Вы не увеличили ни мои знания, ни мои представления даже на 0.000001%. Я был не против вам что-то объяснять, но у вас слишком большие пробелы в фундаментальных знаниях, а я и так потратил на вас больше времени чем планировал потратить на всю тему целиком (прошлый свой комментарий вам я писал примерно 6 часов, сам не заметил как время пролетело), больше тратить не буду. Наш разговор окончен. Дальнейшие ваши комментарии в этой теме я буду игнорировать, даже не буду читать. Не воспринимайте этот комментарий как оскорбление, намерении вас оскорблять у меня нет, но пожалуйста, не поленитесь хотя бы вот эти статьи в википедии почитать:
ссылка 0
ссылка 1
ссылка 2
ссылка 3
ссылка 4
ссылка 5