Здравствуйте, Shmj, Вы писали:

A>>Причём тут интерфейсы. В чём была бы польза от ключевого слова abstract для классов в C++?
>>>В C++ есть [...]. Зато нет ключевых слов для ... абстрактных классов, хотя это полезно

S>Ладно, не так выразился — точнее будет сказать — спец. механизм для интерфейсов, отличающий их от абстрактных классов — и невозможность потом добавить в интерфейс реализацию.

А ЭТО тебе зачем понадобилось? Какое такое плохое зло случится, если ты добавишь в готовый интерфейс реализацию?

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

Если это будет реализация виртуальной функции (вместо =0), для любого, кто имплементировал ранее такой интерфейс, ничего не изменится. Если он работает на уровне указателей, с поздним связыванием, то сможет даже не перекомпилировать свой код. А если у него зависимость от хедера с описанием интерфейса, то его код гарантировано скомпилируется и гарантировано будет работать как надо. Вот если он, увидев появившуюся реализацию, решит схалявить и выкинуть свою, то... интерфейс просто превратится в абстрактный класс. И ничего плохого, опять же, не случится.

А ещё интерфейс это часть контракта, он пишется один раз, очень внимательно, и потом меняется как можно реже, в идеале — никогда. Так что, я бы сказал, это очень надуманная проблема: гарантировать невозможность добавить в интерфейс реализацию. Я многие годы писал на C++/COM. От реализации диспинтерфейсов руками до самописной рефлексии на интерфейсах. И такой проблемы просто нет. Есть проблема, если ты пишешь реализации для позднего связывания и ваш контракт не устоялся, то всё постоянно крашится из-за того, что кто-то не обновился. Но после стабилизации интерфейса проблемы заканчиваются. Даже если тупой джун добавит туда реализацию, да. А если связывание не позднее, если обе стороны, вызывающая и вызываемая, пишутся на основе одного хедера, то сам факт успешной компиляции снимает проблемы.

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

Но я, возможно, ошибаюсь, и ты мне сейчас объяснишь, зачем гарантировать "невозможность потом добавить в интерфейс реализацию" на C++?

Я всё равно считаю, что ООП не нужно. Пишу на Java и ООП использую раз в год. Для раза в год можно и ручками сымитировать что надо. Тем более, что в Rust и сахар для виртуальных методов есть, это не C, где надо таблицы забивать указателями вручную.

Идеального языка я не знаю. В нём должен быть GC и исключения. При этом он должен быть минималистичен и достаточно прост. В целом что-то вроде Java 1.4, пожалуй, максимально близко к идеальному языку из того, что я видел в этом мире, хотя и не совсем то.

Здравствуйте, D. Mon, Вы писали:

S>>Что-то усредненное из этого можно назвать идеальным ЯП для среднего человека.
S>>Итого. Идеальный язык мне представляется как Rust, но с полноценным ООП и ...

DM>Я тут недавно на современный Swift смотрел, вот он реально выглядит как такое усреднение с выбором всего хорошего и отбрасыванием плохого. И ООП есть, и традиционные для ФП фишки вроде алгебраических типов, паттерн матчинга, тайпклассов/трейтов, при этом вместо GC встроенный подсчет ссылок. Памяти ест мало, работает быстро. Вполне себе кандидат.

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

let firstName = "aaesalamanca"
let age = 27
let message = "Hello, " + firstName + "! You're " + age + " years old."

Вот эту программу компилятор Swift откомпилировать не может и падает с ошибкой "The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions"

Это какой-то позор.

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

Здравствуйте, vsb, Вы писали:

vsb>Вот эту программу компилятор Swift откомпилировать не может и падает с ошибкой

У меня не падает. Показывает реальную ошибку в коде. И если написать код нормально, то компилируется все мгновенно и работает.


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

vsb>это никак не исправить, это by design

Если чуть строже язык сделать, убрать кое-какие неоднозначности/оверлоадинг, наверняка можно исправить. Вон в OCaml, Haxe, Elm тот же Хиндли-Милнер вывод типов, и все очень быстро типизируется и компилируется.

Здравствуйте, D. Mon, Вы писали:

DM>Там вместо ООПшных интерфейсов — протоколы, подобные multiparameter type classes из хаскеля или traits из Раста. Когда можно свой интерфейс/трейт придумать и уже существующие чужие типы объявить, что они ему соответствуют, и как именно.
Damn, надо срочно его изучить.

Здравствуйте, D. Mon, Вы писали:

DM>Если чуть строже язык сделать, убрать кое-какие неоднозначности/оверлоадинг, наверняка можно исправить. Вон в OCaml, Haxe, Elm тот же Хиндли-Милнер вывод типов, и все очень быстро типизируется и компилируется.

В этом и проблема — в Swift не ХМ, как и в Скале. Скрестить ужа (знакомые ООП фишки) и ежа (вывод типов и implicits за конечное время) пока не получается. Это по мнению Одерски, который в type theory собаку сьел.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, D. Mon, Вы писали:

DM>>Там вместо ООПшных интерфейсов — протоколы, подобные multiparameter type classes из хаскеля или traits из Раста. Когда можно свой интерфейс/трейт придумать и уже существующие чужие типы объявить, что они ему соответствуют, и как именно.
S>Damn, надо срочно его изучить.
Как скалист, где все это добро есть лет так 15, недавно перешедший на C#, отсутствие type classеs довольно легко обойти адаптерами и расширителями.
А вот отсутствие ADT(aka "discriminating unions") достает. OneOf конечно неплохой костыль, но не 100% кайф. В F# оно есть, но для простого народа он слишком "другой" и не очень ясен вопрос поддержки.

Здравствуйте, D. Mon, Вы писали:

Спасибо.
Как с tooling в win/linux?
в vscode LSP рабочее?
jupyter kernel?
Что с пакетным менеджером, типа nuget/cargo? В репо библиотеки должны быть под платформу или пакетный менеджер их при установке адаптирует? Там оно все к МаcOS не привязано?
Байндинг к C++?
собирается в ~static linking ехе? если да, то размер helloworld.exe?

Здравствуйте, Shmj, Вы писали:

S>Итого. Идеальный язык мне представляется как Rust, но с полноценным ООП и отсутствием макросов. Т.е. макросы могут быть, но не системные — т.к. это весьма усложняет. В 4-ке лучших языков нет особенной привязки к макросам или вообще их нет.

Фортран и Кобол чем не устраивают? Софт на них работает десятилетиями. Переносится между платформами без особых усилий. Что ещё надо?

Здравствуйте, Shmj, Вы писали:

S>Что-то усредненное из этого можно назвать идеальным ЯП для среднего человека.

Средним ЯП для среднего человека. И этот язык уже есть — называется Java. Для совсем средних людей есть Python. Все остальные языки — некий компромисс между возможностями и рисками/требованиями к программисту.

Здравствуйте, SkyDance, Вы писали:

SD>Ничего.
SD>Основное достоинство заключается не в том, что есть, а в том, чего нет — многих лет всяческого легаси и прочей обратной совместимости.
В Scala3 или Котлин легаси еще меньше. Да и в C# "legacy" в основном в библиотеке и не слишком мешает жить.

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

С этим плотно связан еще один вопрос: каким должен быть идеальный компилятор?
Идеальный компилятор будет не просто вываливать сообщения об ошибках — он будет вести диалог на естественном языке, задавая правильные вопросы, позволяющие устранить все возникшие неоднозначности, подсказывая человеку о том, что он вероятно забыл и предлагая от себя возможно важные дополнения (что-то из этого можно будет отключить в настройках). В общем, обычный компилятор будет обёрнут в ИИ-чат. И именно такой компилятор позволит эффективно использовать максимально декларативный язык и ускорить время разработки программы.
К тому же, такой ИИ-компилятор сможет обучать начинающего программиста практически "с нуля".

Но про компилятор — это отвлечение от темы. Обсуждаем язык:
Характеристики, которые будут оптимизироваться при разработке такого языка — это его 1) человеко-читаемость и 2) выразительность — по этим показателям он может значительно обогнать существующие ЯП.

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

Здравствуйте, vsb, Вы писали:

vsb>Я всё равно считаю, что ООП не нужно.
Совершенно согласен. Нужен не OOP, а хороший adhoc polymorphism, желательно с multiple dispatch. Решения в Хаскеле и Julia на эту тему есть, те же type classes.

К сожалению нет удовлетворительного решения по auto-complete UI на первый параметр. Тут подумалось, а может просто сделать "сахар"(ака lowering):
x.f(y, z) => f(x, y, z)
Возможно такое даже есть где-нибудь в Хаскел пространстве.

Здравствуйте, novitk, Вы писали:

N>Как скалист, где все это добро есть лет так 15, недавно перешедший на C#, отсутствие type classеs довольно легко обойти адаптерами и расширителями.
N>А вот отсутствие ADT(aka "discriminating unions") достает. OneOf конечно неплохой костыль, но не 100% кайф. В F# оно есть, но для простого народа он слишком "другой" и не очень ясен вопрос поддержки.
Не, я не про type classes. Сейчас на основной работе мы активно изобретаем язык, который крутится как раз вокруг протоколов, а не интерфейсов.
А тут оказывается уже по соседству есть что-то подобное.

Здравствуйте, L_G, Вы писали:

L_G>Идеальный язык программирования по синтаксису будет подмножеством естественного языка (например, английского) с четкой формализацией (исключающей неоднозначности).
L_G>И он будет в гораздо большей степени высокоуровневым и декларативным, чем нынешние языки, по сути он будет языком для написания технического задания. Это, конечно, не исключает низкоуровневых императивных возможностей всего инструментального набора. (Будут ли императивные конструкции считаться частью того же языка, или это будет отдельным языком — скорее вопрос терминологии. Думается, будет удобнее их разделить.)

L_G>С этим плотно связан еще один вопрос: каким должен быть идеальный компилятор?
L_G>Идеальный компилятор будет не просто вываливать сообщения об ошибках — он будет вести диалог на естественном языке, задавая правильные вопросы, позволяющие устранить все возникшие неоднозначности, подсказывая человеку о том, что он вероятно забыл и предлагая от себя возможно важные дополнения (что-то из этого можно будет отключить в настройках). В общем, обычный компилятор будет обёрнут в ИИ-чат. И именно такой компилятор позволит эффективно использовать максимально декларативный язык и ускорить время разработки программы.
L_G>К тому же, такой ИИ-компилятор сможет обучать начинающего программиста практически "с нуля".

L_G>Но про компилятор — это отвлечение от темы. Обсуждаем язык:
L_G>Характеристики, которые будут оптимизироваться при разработке такого языка — это его 1) человеко-читаемость и 2) выразительность — по этим показателям он может значительно обогнать существующие ЯП.

L_G>Можно поспорить о том, будут ли людей, использующих подобный язык (+чат-компилятор), по-прежнему называть программистами, но вряд ли стоит сомневаться в экономической эффективности такого подхода.

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

Здравствуйте, Sinclair, Вы писали:
S>А тут оказывается уже по соседству есть что-то подобное.
А, не, отбой тревоги. Это не те дроиды, которых мы ищем.
У нас протокол — это именно что протокол, соглашение о порядке отправки и приёма сообщений.
Пытаемся решить проблему выразительности интерфейсов. Типа, что файл надо сначала открыть, потом можно из него произвольное количество раз читать, потом надо его закрыть (после чего читать нельзя).
И вот нам надо убедиться, что а) реализация корректно реализует заявленную state machine, и что б) вторая сторона тоже корректно реализует свою часть протокола. И некоторая алгебра над протоколами, которая должна проверять, что некая суперпозиция нескольких протокольных ролей является конформным расширением над некоей заданной протокольной ролью.

Здравствуйте, L_G, Вы писали:
L_G>Характеристики, которые будут оптимизироваться при разработке такого языка — это его 1) человеко-читаемость и 2) выразительность — по этим показателям он может значительно обогнать существующие ЯП.
Почему-то мне кажется, что идеальный ЯП вообще не должен символами записываться. Это наследие древности рано или поздно должно уйти, хотя вряд ли это случится скоро.

Здравствуйте, Privalov, Вы писали:

P>Фортран и Кобол чем не устраивают? Софт на них работает десятилетиями. Переносится между платформами без особых усилий. Что ещё надо?
переносимость фортрана это сказки, иногда оно сделано так что перенести не возможно и будет работать только на избранных компиляторах.

Здравствуйте, Sinclair, Вы писали:

S>Не, я не про type classes. Сейчас на основной работе мы активно изобретаем язык, который крутится как раз вокруг протоколов, а не интерфейсов.
S>А тут оказывается уже по соседству есть что-то подобное.

Если type class не интересны, не очень понятно, где ты увидел разницу с интерфейсами того же C#. ИМХО гвоздь именно в периферии: extensions/type classes, union types, mutable и т.д.

Здравствуйте, kov_serg, Вы писали:

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

Я лично переносил проект на фортране с ЕС на PC. Работало в ОС ЕС 6.1, СВМ ЕС (ПДО), MS DOS, MS DOS с DOS Extender, OS/2, Windows различных версий. Компиляторы IBM и MS Fortran. У NDP и Watcom нам что-то не понравилось. Ну и я потом на Сях несколько вставок сделал, MS C и MS Fortran оказались хорошо совместимы.