Здравствуйте, Sinclair, Вы писали:
S>Пытаемся решить проблему выразительности интерфейсов. Типа, что файл надо сначала открыть, потом можно из него произвольное количество раз читать, потом надо его закрыть (после чего читать нельзя). S>И вот нам надо убедиться, что а) реализация корректно реализует заявленную state machine, и что б) вторая сторона тоже корректно реализует свою часть протокола. И некоторая алгебра над протоколами, которая должна проверять, что некая суперпозиция нескольких протокольных ролей является конформным расширением над некоей заданной протокольной ролью.
DSL нужен. C# не супер для этих целей, но если вы на dotnet, МSFT делает же всякие blazor/razor. Скала сильно лучше и позволяет делать приличный внутренний DSL, но менять tech stack я бы не стал. Ну или к Владу за Nitro-й
Что касается, где бы стырить идею спеков и алгебры, которые вам нужны, то тут я
Здравствуйте, novitk, Вы писали: N>DSL нужен.
Вот DSL мы и пилим. N>C# не супер для этих целей, но если вы на dotnet, МSFT делает же всякие blazor/razor.
Не, там основатели не верят в управляемые платформы. Так что — суровый натив, плюс мультиагентная среда исполнения с гарантиями доставки и восстановления после сбоев. N>Скала сильно лучше и позволяет делать приличный внутренний DSL, но менять tech stack я бы не стал.
Ну, тут пока что основная проблема — именно что в семантике. Ковыряем потихонечку.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>У нас протокол — это именно что протокол, соглашение о порядке отправки и приёма сообщений. S>Пытаемся решить проблему выразительности интерфейсов. Типа, что файл надо сначала открыть, потом можно из него произвольное количество раз читать, потом надо его закрыть (после чего читать нельзя).
vsb>Тут возникает проблема с тем, что современный ИИ, показывающий интересные результаты, обучался на огромных массивах готового кода. У меня нет уверенности, что получится сделать ИИ, показывающий похожие результаты с языком, на котором никто ничего не написал.
Язык и компилятор для него наверняка будут сделаны без применения ИИ / LLM. Думается, их преимущества могут оказаться значительными сразу.
Поначалу "чат" предполагался как интерфейсная часть компилятора, основная задача которой — сухую суть ошибок компиляции переформулировать максимально понятным человеку языком и сразу предлагать варианты их решения. На первом этапе это можно сделать и на эвристиках, а по мере накопления данных для обучения переделать на LLM (если будет смысл вообще).
Конечно, многим сразу захочется использовать в работе уже привычную функцию ИИ-чата — принимать на входе фразы на человеческом языке и выдавать код на ЯП — но это уже другая его функция. И действительно, отсутствие массивов готового кода для обучения отодвигает возможность реализации этой функции дальше в будущее.
Со временем может стать совсем хорошо: если начинающий программист просто "говорит по человечески", ИИ-чат, угадывая смысл, поправляет его, в результате совместных усилий получается текст на ЯП (на экране перед глазами человека). Так человек будет запоминать все отличия языка программирования от естественного и постепенно научится сразу говорить/писать корректные фразы на ЯП — так-то оно быстрее будет! Но это именно для функции обучения нужен такой ИИ-чат.
А мастеру программирования ИИ-чат поможет едва ли: он будет сразу думать на ЯП и печатать/диктовать почти готовый код. Ему ведь не надо для этого помнить наизусть кучу библиотечных функций — только ключевики и предметную область программы, а синтаксис языка — и вовсе родной, ну почти.
Текущая функция ИИ-чата — переводить краткие ТЗ (на человеческом языке) в длинные простыни императива (с большой вероятностью сочинить полный бред) — с новым языком должна перейти к компилятору: разворачивать НЕПРОТИВОРЕЧИВОЕ ТЗ в императив может и должна строгая логика (без LLM)!
Есличо, я только на прошлой неделе взялся опять на свифт смотреть и написал на нем ровно одну программу на 200 строчек.
N>Как с tooling в win/linux?
Что-то есть и работает, я на линуксе как раз играюсь. Поставил пакет swift-bin и вперед.
N>в vscode LSP рабочее?
Хз. Но в Helix'e LSP сразу подцепился и как-то работает — автокомплит, ошибки, все такое.
N>jupyter kernel?
Хз.
N>Что с пакетным менеджером, типа nuget/cargo? В репо библиотеки должны быть под платформу или пакетный менеджер их при установке адаптирует? Там оно все к МаcOS не привязано?
Какой-то есть свой. Кроме компилятора swiftc там есть команда swift, которая как раз рулит процессом, умеет создавать проекты, качать зависимости, собирать всё и т.д. https://swiftpackageindex.com/ показывает больше 7к пакетов.
N>Байндинг к C++?
Хз.
N>собирается в ~static linking ехе? если да, то размер helloworld.exe?
По умолчанию helloworld — маленький бинарник (16 КБ), но ссылающийся на кучку .so, в сумме мегов 20 они.
Если скомпилить swiftc -static-executable hey.swift -o hey, то получается 9 МБ, полностью статичный, но не работает.
Пишут, что в Swift 6 будет работать нормально, пока что нужно с бубном поприседать.
Здравствуйте, novitk, Вы писали:
DM>>Если чуть строже язык сделать, убрать кое-какие неоднозначности/оверлоадинг, наверняка можно исправить. Вон в OCaml, Haxe, Elm тот же Хиндли-Милнер вывод типов, и все очень быстро типизируется и компилируется.
N>В этом и проблема — в Swift не ХМ, как и в Скале.
И там, и там ХМ, просто с наворотами/расширениями.
N>Скрестить ужа (знакомые ООП фишки) и ежа (вывод типов и implicits за конечное время) пока не получается. Это по мнению Одерски, который в type theory собаку сьел.
Потом эту тему еще много раз по-разному пинали, видимо, одного идеального подхода нет. Из недавних интересных подходов — algebraic subtyping Долана, см. например MLscript.
Здравствуйте, Alekzander, Вы писали:
A>Причём тут интерфейсы.
Дык, непосредственно.
A>В чём была бы польза от ключевого слова abstract для классов в C++?
Почему "бы"? В VC++ давным-давно есть и abstract, и __abstract. Очень способствует унификации определений как интерфейсного (абстрактного) класса, так и его реализации, чтобы не выписывать "= 0" при каждой функции интерфейса.
Здравствуйте, Евгений Музыченко, Вы писали:
A>>В чём была бы польза от ключевого слова abstract для классов в C++?
ЕМ>Почему "бы"? В VC++ давным-давно есть и abstract, и __abstract. Очень способствует унификации определений как интерфейсного (абстрактного) класса, так и его реализации, чтобы не выписывать "= 0" при каждой функции интерфейса.
Мне очень понравился диалог на эту тему на StackOverflow.
— Могу ли я использовать ключевое слово abstract при объявлении класса?
— Да, конечно можете. К сожалению, ваша программа после этого перестанет компилироваться.
Прямо какое-то армянское радио.
Насколько я в курсе, это расширение, которое Microsoft добавил в VC++ ради C++/CLI, и так оно там и осталось. Поэтому и "бы". А если я ошибаюсь и это часть языка, то просьба дать ссылку куда-нибудь в районе cppreference.com.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Alekzander, Вы писали:
A>Насколько я в курсе, это расширение, которое Microsoft добавил в VC++ ради C++/CLI, и так оно там и осталось. Поэтому и "бы". А если я ошибаюсь и это часть языка, то просьба дать ссылку куда-нибудь в районе cppreference.com.
Господин Музыченко 30 лет живет в уютном мире Windows и компиляторов от Microsoft. Поэтому то, что есть в VC++ для него есть и в C++.
Здравствуйте, Alekzander, Вы писали:
S>>Ладно, не так выразился — точнее будет сказать — спец. механизм для интерфейсов, отличающий их от абстрактных классов — и невозможность потом добавить в интерфейс реализацию. A>Но я, возможно, ошибаюсь, и ты мне сейчас объяснишь, зачем гарантировать "невозможность потом добавить в интерфейс реализацию" на C++?
Это позволяет разделить работу проектировщика архитектуры и девелоперов/реализаторов.
В C++ в принципе концепция — интерфейс это h-файл, по сути. Который включает в себя еще много всякого. Как бы это легаси ломает простую концепцию.
Здравствуйте, Went, Вы писали:
L_G>>Характеристики, которые будут оптимизироваться при разработке такого языка — это его 1) человеко-читаемость и 2) выразительность — по этим показателям он может значительно обогнать существующие ЯП. W>Почему-то мне кажется, что идеальный ЯП вообще не должен символами записываться. Это наследие древности рано или поздно должно уйти, хотя вряд ли это случится скоро.
У меня в школе была учительница математики (м.учительница), которая требовала исключительно символьной записи теорем. С кванторами (∀, Ǝ), конъюнкциями (∧), импликациями (⇒) и т.д. Запись доказательства выглядела примерно так:
А ∈ α ∧ B ∉ α ⇒ a ≡ c
Меня это жутко бесило. Я ей приносил цитаты из Герона, где он ставил и решал задачи гекзаметром, и требовал доказать, что такая запись чем-то хуже.
А потом я вырос и познакомился с теоремой о неполноте, диагональном аргументе, и прочей метаматематике. Оказалось, м.учительница была права. В математике без символов делать нечего, и этому есть объяснение.
А ещё позже я познакомился с такой точкой зрения, что теория вычислений (включающая в себя программирование) это, по сути, изучений следствий ограничения математики законами физики. (Что вычислимо, а что нет, и пр.) Короче говоря, широко распространённая запись программного кода символами это совсем не случайность.
И, кстати, программистский способ символьной записи (плоский, с сокращёнными алфавитами и т.п.) лично мне нравится гораздо больше математического. Одна из причин, по которой мне всегда нравилось программирование и никогда не нравилась математика.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Alekzander, Вы писали:
A>Насколько я в курсе, это расширение, которое Microsoft добавил в VC++ ради C++/CLI, и так оно там и осталось.
Да, сперва добавил abstract в CLR, а затем — __abstract и __interface в обычный режим C++. Я активно пользуюсь.
Еще они давно добавили compiler-supported type traits. Но адекватной условной компиляции так и не сделали, так что во всем этом мало смысла без остальной шаблонной магии.
Здравствуйте, so5team, Вы писали:
A>>Насколько я в курсе, это расширение, которое Microsoft добавил в VC++ ради C++/CLI, и так оно там и осталось. Поэтому и "бы". А если я ошибаюсь и это часть языка, то просьба дать ссылку куда-нибудь в районе cppreference.com.
S>Господин Музыченко 30 лет живет в уютном мире Windows и компиляторов от Microsoft. Поэтому то, что есть в VC++ для него есть и в C++.
Так и я тоже. Некоторые из этих расширений для поддержки интерфейсов кажутся мне весьма полезными. Например, __uuidof.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, so5team, Вы писали:
S>Господин Музыченко 30 лет живет в уютном мире Windows и компиляторов от Microsoft. Поэтому то, что есть в VC++ для него есть и в C++.
Не, господин Музыченко краем уха слышал, что бывают какие-то другие платформы и компиляторы, у него есть даже пара версий GCC, и он иногда ходит на godbolt.
А пример с VC++ показателен тем, что расширения, однажды введенные разработчиками компилятора для собственных нужд, нередко становятся стандартом де-факто. И в стандарты C++ что-то притащили из бывших локальных расширений от Borland, MS и GNU.
Здравствуйте, Shmj, Вы писали:
S>>>Ладно, не так выразился — точнее будет сказать — спец. механизм для интерфейсов, отличающий их от абстрактных классов — и невозможность потом добавить в интерфейс реализацию. A>>Но я, возможно, ошибаюсь, и ты мне сейчас объяснишь, зачем гарантировать "невозможность потом добавить в интерфейс реализацию" на C++?
S>Это позволяет разделить работу проектировщика архитектуры и девелоперов/реализаторов.
S>В C++ в принципе концепция — интерфейс это h-файл, по сути. Который включает в себя еще много всякого. Как бы это легаси ломает простую концепцию.
А что изменится, если ты опишешь интерфейс не в .h-файле, а в модуле? Или даже просто на бумажке? И будешь реализовывать интерфейс в классе, глядя на бумажку?
В C++ интерфейсы это про vtbl. В C# и Java интерфейсы это про данные типа, доступные в рантайме. Интерфейсам на vtbl нужно заполнение vtbl. Данные типа, доступные в рантайме, им не нужны. (Конечно, кроме гуида, имени библиотеки, разных флагов и пр. )
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Alekzander, Вы писали:
A>В C++ интерфейсы это про vtbl. В C# и Java интерфейсы это про данные типа, доступные в рантайме. Интерфейсам на vtbl нужно заполнение vtbl. Данные типа, доступные в рантайме, им не нужны. (Конечно, кроме гуида, имени библиотеки, разных флагов и пр. )
Здравствуйте, korvin_, Вы писали:
A>>В C++ интерфейсы это про vtbl. В C# и Java интерфейсы это про данные типа, доступные в рантайме. Интерфейсам на vtbl нужно заполнение vtbl. Данные типа, доступные в рантайме, им не нужны. (Конечно, кроме гуида, имени библиотеки, разных флагов и пр. )
_>Какие данные типа.
Type.IsInterface.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Alekzander, Вы писали:
A>Интерфейсам на vtbl нужно заполнение vtbl. Данные типа, доступные в рантайме, им не нужны. (Конечно, кроме гуида, имени библиотеки, разных флагов и пр. )
Для чего "интерфейсам на vtbl" могло бы потребоваться перечисленное?
Здравствуйте, Евгений Музыченко, Вы писали:
S>>Господин Музыченко 30 лет живет в уютном мире Windows и компиляторов от Microsoft. Поэтому то, что есть в VC++ для него есть и в C++.
ЕМ>Не, господин Музыченко краем уха слышал, что бывают какие-то другие платформы и компиляторы, у него есть даже пара версий GCC, и он иногда ходит на godbolt.
Так давно известно, что господин Музыченко не видит дальше своего манямирка.
ЕМ>А пример с VC++ показателен тем, что расширения, однажды введенные разработчиками компилятора для собственных нужд, нередко становятся стандартом де-факто. И в стандарты C++ что-то притащили из бывших локальных расширений от Borland, MS и GNU.
Но есть нюанс: когда что-то включается в язык (вроде [[likely]]), то это перестает быть расширением. А до того это именно что расширение, которого нет в C++. И тем, кто пишет под несколько платформ, с этим приходится считаться. Но в вашем манямирке этого, очевидно, нет.
Здравствуйте, so5team, Вы писали:
S>тем, кто пишет под несколько платформ, с этим приходится считаться.
Знаете, я об этом как-то смутно догадывался. Но я не считаю, что следует стремиться к тому, чтобы любой код всегда был готов к работе на любой, даже заранее неизвестной, платформе.
)
