Golang или Gambit Scheme?

динамико

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

Решил попробовать слезть с CL и перейти на другой язык.
Например, посмотрел на Оберон
Интересен Gambit

Языки, на которых пишут люди не рассматривашь принципиально?

если что, можно и на хлеб заработать

Java

Странно, что такого любителя красоты потянуло на golang с его interface{} и проч. костылями, с которыми жить можно но вообще ни разу не красиво.

Java с каким-то мутным копирайтом. Вот про clojurescript вчера вспомнил. Почти лисп, и не завязан на java. Golang мог бы сойти вместо Си, он быстрый, хорошо поддерживается, в нём есть всё, что надо и ничего лишнего. А если бы идеальный ЯП существовал, я бы просто на нём и программировал и не занимался бы велосипедостроительством :)

А я насколько понял, Interface{} служит костылём для реализации void * ?

Вот как надо:

"http://www.shenlanguage.org:

runs under: CLisp, SBCL, Clojure, Scheme, Ruby, Python, the JVM, Haskell and Javascript "

"http://docs.idris-lang.org/en/latest/reference/codegen.html

Code Generation Targets: JavaScript, NodeJS, C, Erlang, .NET, Java, JVM, LLVM, PHP, OCaml, Python, Ruby

+

Elixir, Chez Scheme (из недавних) "

Во-первых, как верно заметили выше, OpenJDK является OpenSource проектом. Во-вторых, ты можешь компилить свой язык в байткод JVM. Это гораздо проще, чем компилить в машинные коды (основную долю оптимизаций выполняет JVM).

Всё правильно, пусть на Idris пишет. Сразу вон сколько бэков.

Я к тому, что надо кодогенератор сделать удобным для создания других бэкендов, а так можно продолжать под СБЦЛ пилить референсную реализацию, другой бэкенд/рантайм можно допилить под нужды.

Там оно прибито к CL, как я понял. Так что вот.

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

runs under: CLisp, SBCL, Clojure, Scheme, Ruby, Python, the JVM, Haskell and Javascript

А зачем это надо? Это только распыление усилий. Большая команда себе может позволить, конечно.

Хуже, оно прибито к SBCL - так я пытался сэкономить усилия.

в агде/идрисе ещё более «навороченная» система типов чем в хаскеле. при этом туториалов по «полному стеку»* на агду/идрис исчезающе мало (я бы сказал ровно 0). Кроме того, не совсем понятно пока как именно исползовать наработанные в хаскеле абстракции с новой системой типов (многое, похоже, работает, но многое остаётся сомнительным). В целом, предполагается, что взявшийся за агду/идрис владеет хаскелем на уровне «опытный программист».

Чтобы понять систему типов агды /идрс можно прочитать вот эту книгу https://www.manning.com/books/type-driven-development-with-idris . Её в целом достаточно. Или же вот тут есть курс Брагилевского (10 лекций) , для хорошего обзора достаточно https://www.youtube.com/watch?v=QoglUkN8d08&list=PLEqoHzpnmTfD8ocGHDAMUfx... . Но повторюсь, это лишь синтаксис и система типов. Ещё нужно уметь работать с идиоматическими абстракциями, а туториалы, учебники, книги и статьи про это доступны пока лишь на хаскеле.

*Под «полным стеком» я здесь имею ввиду не только синтаксис языка, но и то как применяются идиоматические абстракции. т.е. для примера для явы это были бы туториалы по паттернам вроде фабрик, синглтонов, декораторов и прочей ООП-обвязки).

https://nponeccop.livejournal.com/585243.html

Спасибо огромное! Особенно круто было прочитать мнение автора нодки про то, что нодка не нужна.

с новой системой типов

Что там нового? триплеты хоара, депендент тайпс, рефайнед тайпс это все вещи из 80/90-х, эффекты поновее, да, но в целом за языками вполне старая и устоявшаяся теория. И какие там еще новые ииоматические абстракции, монад туториалов и статей про эффекты завались.

На сколько я понимаю, идрис - первый язык с депендент тайпс который претендует на звание «язык общего назначения» (не уверен претендует ли Агда).

Идиоматические абстракции - не новые. Новые они с данной системой типов.

Теория действительно разрабатывается довольно давно. Но как долго не появлялось важных статей по теории? (ну понятно исследовательские по агде/идрису появляются интересные, но я имею ввиду так сказать «вехи»).

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

АПД. Да, вот вспомнил, у пирса в 2002 (кажется) году было «такие языки испытывают пока серьёзные трудности» (о языках с зависимыми типами). Т.е. идрис - это достижение последних 10-15 лет, на практике. По теории, повторюсь, не возьмусь судить.

На сколько я понимаю, идрис - первый язык с депендент тайпс который претендует на звание «язык общего назначения» (не уверен претендует ли Агда).

Ну есть F* (куда как более приятный и удачный, чем идрис, как по мне), который относительно старый, есть скала, хотя там, скорее всего, все очень плохо. Сами зависимые типы просты как палка и применять их легко и просто, в coq они существуют очень давно, проблема была только в реализации (реализовать зависимые типы в не-тотальном языке — нетривиальная задача).

Скажу как человек знакомый со скалой (правда уже и забывший, по большому счёту) и с хаскелем: могу сказать что зависимые типы там конечно есть и даже бывают(в скале) применяются, емнип. Но вот в хаскеле они «есть», но как например там реализовать filter? в идрисе есть **. Это (хаскель/скаль)-ное «есть» - это не совсем «есть», это просто максимум что смогло предыдущее поколение языков. По моему, это скорее «ну почти дотянули», чем «есть». Пользоваться этим в хаскеле я так понял на практике широко невозможно (я пытался раз, месяца два назад, из любопытства). В скале я не пытался пользоваться, но думаю что ситуация хуже чем в хаскеле.

Как там в F* я не знаю, но если где-то так же как в хаскеле, то это банально неудобно.

Идрис/агда - совсем другой уровень. Там зависимые типы действительно можно попробовать использовать широко на практике: кажется, для этого всё готово.

В хаскеле нет зависимых типов, если не считать dependent haskell, который еще не готов. В хаскиле есть только GADT+type families, которые позволяют наговнокодить простые индуктивные типы и некоторые функции над ними. В fstar нормальные зависимые типы, в целом язык похож на coq, но сам язык не тотальный и с эффектами. Агда тотальная, как и coq, то есть почти бесполезна для написания программ.

В хаскиле есть только GADT+type families, которые позволяют наговнокодить простые индуктивные типы и некоторые функции над ними

да, это.

coq

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

По агде - я прошёл один туториал полтора (кажется) года назад и уже не помню на сколько там важна тотальность. В идрисе - то тальность определена как «либо завершается, либо обещает произвести результат на следующем шаге». что в общем, очень хорошо соответствует понятию «работоспособно». Хотя убедить компилятор в тотальности, похоже, не всегда легко. Но писать реальные программы похоже можно. На конференции по скале где Брэди рассказывал про идрис - он даже показывал игру емнип «космический бой» (или как он там - внизу экрана кораблик двигается влево вправо и стреляет, а сверху вниз движутся пришельцы и тоже стреляют).

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

О, оказывается, я просмотрел, что в Nim есть рекорды. Не понял пока, есть ли в нём хоть в каком-то виде горячая замена. Кто пользовал, как у него со стабильностью?

этот язык поверх можно накидать в одно рыло в каком-нибудь Language Workbench: JetBrains MPS, Xtend/XText, Stratego/XT (недавно у него появился IDE на базе Eclipse, Spoofax, гле-то там же обучалка «напиши свой язык», ещё где-то там же рядом есть курсы, презентации, PDF с курсами для студентов)

и в таком вот «отладчике» поиграться со своим DSL

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

Будь то пошаговая отладка, шаблоны или слабые ссылки. Если я захочу тип «любой объект», наверное меня вообще сметут с лица земли.

слабые ссылки там есть, TAGGED RECORD

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

или взять более простой Oberon-07

хотя оберон — не фетиш, а инструмент.

имхо, проще взять тот же D + pegged для PEG грамматики Оберона или Nim + PEG парсер... или вот, pegjs + 1C синтаксис тут :)

и сделать свой собственный оберон, CTFE + PEG + AST макросами :)

на наших атомных станциях, кстати, крутится - готовьте йод.

если смотрел презентацию, то там на обероне обвязка к CORBA к библиотеке на С++

https://nekovm.org/ видел?

Там только дин. типизация и байткод? Проще начинать от статической и двигаться к динамической, чем наоборот. Я от Оберона протащился - он пока выглядит наиболее близким приближением к тому, что надо. Хотя там много нужно допилить, по дороге поссорившись с консервативными оберонщиками :)

Денис, паскакаль умер же.

Они с лиспом ползут на кладбище наперегонки, всё никак не доползут :)

закопай в своей голове дельфи, оставь её в прошлом, и твои волосы станут мягкими и шелковистыми

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

Про типизацию меня как-то достали уже тупые системы типов, в которых общение с компилятором напоминает попытку объяснить роботу по какому принципу оценивать конкурс художественной самодеятельности. Мне кажется, что будущее за статическим анализом кода, который в свою очередь написан на достаточно гибкой основе, такой как динамическая типизация. Ну чтоб как в котлине для nullable типов требовалось перед использованием зайти в if (x != null). Подобное поведение хрен организуешь системой типов.

Ну чтоб как в котлине для nullable типов требовалось перед использованием зайти в if (x != null). Подобное поведение хрен организуешь системой типов.

А прикинь, SBCL это умеет. И это _можно_ организовать системой типов.

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

По-моему, в C# сделано годно - тип any или как он там называется.

Дельфи жил, дельфи жив, дельфи будет жить. Если бы не GPL, я бы взял Лазаря полувоскресшего и допилил бы его :)

SBCL это умеет. И это _можно_ организовать системой типов.

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

По-моему, в C# сделано годно - тип any

dynamic. Идею одобрям, но я немного не о том, чтоб комбинировать динамику со статикой. Кстати на плюсах есть нечто по-круче в плане гибкости - void* и reinterpret_cast. Я вообще о том, чтобы все было и ничего за это небыло.

В SBCL неотключаемый вывод типов (и поскольку в нём есть баги, на которые команде накласть с прибором, это плохо).

Т.е. если у тебя

(typecase x
  ((not null) 
  .. что-то про x ..
  ))

И дальше, если у тебя есть known функция и для неё deftransform или defoptimizer, или inline функция, в которой есть ветка для nil, то можно извлечь профит из этого знания.

чтоб комбинировать динамику со статикой

С моей колокольни видится так, что статика нужна почти всегда, а динамика - иногда, но без этого «иногда» жить нельзя, или можно, но это не жизнь :)

Собственно динамика доступна всегда, достаточно просто написать интерпритатор. А реально хватает и всяких там boost::variant. Вопрос в том, чтоб эта динамика переняла хотя бы часть свойств статики. Кстати видал для питона есть статический компилятор. Ну и всякие там asm.js тоже пример этого подхода.

Выглядит несколько философски. Какие именно свойства статики ты хочешь в динамике?

Верификация кода и скорость выполнения же. Разве есть еще какие преимущества загонять себя в контракты на типах? Ну еще подсказка в ИДЕ, но её как-то и в динамике можно прикрутить.

Мне кажется, ни то, ни то не выйдет. Единственное, что в динамике есть свои преимущества для скорости, т.к. List<X>.Add существует в единственном экземпляре - дружественно к кешу, кода меньше. И так, пока не дойдёт до примитивов типа +, которые определены не для всех типов. Но в среднем по больнице вроде как статическая типизация заметно быстрее.

Верификация кода - вместо типов нужно будет тогда что-то другое. Вот SBCL умеет извлекать информацию из веток в if или etypecase, из констант и протягивать её дальше. Можно даже делать таким образом whole program optimization, но это уже не динамика.

Опять же, что понимать под типами. Я вот для эксперимента ввёл в SBCL тип immutable. И тогда у меня немутабельная хеш таблица стала типа «хеш-таблица и immutable». SBCL кое-что может продумать на эту тему и как-то использовать эту инфу. Но дальше там начинаются сложности. Например, FreezeObject(myHashTable) - этого SBCL не понимает, поскольку один и тот же объект является mutable до FreezeObject и immutable после. SBCL не понимает, что тип объекта может измениться во времени на противоположный (и это ошибка проектирования в его системе вывода типов, поскольку в лиспе cons string может превратиться в cons integer).

И плюс к тому, вывод типов сам по себе естественным образом легко приводит к экспоненциальной сложности. Чтобы этого избежать, в SBCL наставлена куча «тележек» (kludge). Выглядит это довольно жутко - что-нибудь тронешь и улетишь в экспоненциальное замедление времени компиляции, к примеру.

В итоге ты оказываешься в ситуации, когда у тебя потенциально всё круто, но на практике есть две угрозы: то, что оптимизатор не увидит закономерность в коде, поскольку его защищают от экспоненциальной сложности и дают по рукам (например, в SBCL есть магическое правило 4 итераций при оптимизации, установленное эмпирически), и то, что можно в неё всё-таки влететь, если защита где-то не сработает. То, что при этом происходит, весьма запутанно, хрупко и неуправляемо. Поэтому я считаю, что такой подход не жизненен.

Т.е. ИМХО ты хочешь странного и большего, чем может дать реальность.

List<X>.Add

Компилятор может гибко решать сколько сделать отдельных экземпляров для всяких там char, short, int, float, double и один большой List<Object*> для всего остального. Хаскель вроде бы именно так и работает.

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

Пару раз не увидит - простим. Ну и эвристики никто не отменял. Зато какое поле для развития: изобретать новые алгоритмы обнаружения закономерностей в коде.

защита где-то не сработает

Таймер всегда сработает. А большего и не надо.

Таймер всегда сработает. А большего и не надо.

Это тебе так только кажется. У меня есть один случай, когда вывод типов ускоряет работу определённого метода, скажем, в 200 раз. Т.е. вчера работало, а сегодня я рядом что-то поменял, произошёл таймаут, оптимизация не сработала - и стало в 200 раз медленнее работать. Молча. Потому что я нигде в коде не указал, что эта оптимизация здесь должна быть применена - ведь это динамика, нет для этого выразительных средств. Слишком умный компилятор плох тем, что он делает всё сам, и у тебя нет инструментов гарантировать, чтобы в этом месте данный вид оптимизации был применён.

Вот к примеру. Я считаю, что имеет смысл синтаксически отличать обычный вызов функции и tail call. Они принципиально различны по поведению (глубина рекурсии, отношение к горячей замене кода, вид стека в отладчике). Вместо этого мы имеем только один call, умные компиляторы и невозможность гарантировать tail call. А от применения его сплошь и рядом зависит работоспособность программы.

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

закопай в своей голове дельфи, оставь её в прошлом

Сказал любитель автолулзов.

автотулзы живее всех живых, в отличие от

Не знаю о чём ты. Дельфи и сегодня кормит многих.

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

Дык есть же. Опциональные типы, прагмы всякие. Короче в идеале язык должен быть универсальным и позволять быстро нафигачить прототип, неспешно покрывая его типами потом (автоматически или вручную), после демонстрации свой идеи. Особенно актуально руками задавать типы в библиотеках, потому что компилятор просто не в курсе как планируется использовать данное творчество. Можно конечно отложить компиляцию либы на этап линковки, но все равно надо чтоб было кому надавать по рукам за неправильное применение либы.

Ну, в теории да, тут у нас с тобой, кстати, консенсус. Другое дело, что в деталях это может быть не так просто. JS-ники имеют typescript, где всё это опробовано, хотя мне кажется, что там жестковато. И вообще это называется gradual typing. Но! Задать типы - это одно, а потребовать, допустим, чтобы из 200 веток в typecase оптимизатор вырезал 199, а если нет, то ошибка компиляции - такого я не видел в природе.

typescript

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

Так чего тебе тогда не хватает?