Ваша идея конечно, но с точки зрения пользователя ( меня в данном случае ) задумка странная. Ведь если разницы нет, то и ключевые слова должны это отображать.
Ключевые слова отображают, что разница незначительна для просмотра кода, при более детальном же разборе мы её заметим.
А тут они вроде как пытаются это скрыть, хотя разница между ридонли и неридонли полями существенная. Меня как пользователя это еще больше запутает - что от меня хотят скрыть, чего стоит опасаться?
Скрыть хотят лишние детали, ведь если мы будем замечать всё, как в случае с const вместо val - мы больше не сможем просматривать код, всегда придётся в нём разбираться.
Ну мне кажется всегда есть желание видеть публичный интерфейс как минимум, т.е. все-таки нужно знать где доступны функции.
Мы всё ещё видим публичный интерфейс, но теперь видим ещё и структуру, потому что ничего нам больше не мешает.
Мне кажется Питон больше популярен вопреки этому, благодаря сумасшедшему хайпу, благодаря которому его пытаются использовать везде где только можно.
Это упростило код, что помогло создать хайп.
Опять же вы говорите это, а разные ключевые слова говорят пользователю: "Внимание! Здесь есть разница", и он начинает ее искать. Если разницы нет, то подход как у груви с def смотрелся бы более логично в коде, имхо.
Конечно же разница есть, но она не всегда имеет значение. Например у нас в коде есть элемент с именем display_name, мы знаем что он нам вернёт независимо от ключевого слова, и часто нам этого достаточно.
Не совсем понятно освобождение памяти - будет что-то вроде деструкторов?
Деструкторы будут. @owner позволит освобождать объекты и указатели.
val/var - еще с Котлина заметно было что много перемешанных переменных var и val смешиваются между собой на взгляд, легко перепутать. Тот же const визуально бы гораздо проще было отличать.
Так задумано, val и var это публичные поля, в большинстве случаев для читателя разницы между ними нет, поэтому хорошо что их запись отличается только одной буквой.
Вообще набор var/val/let/def выглядит сложнее чем мог бы на мой взгляд (как работает def не нашел). Если let - это просто модификатор видимости, то имхо проще для чтения кода было бы добавлять отдельный модификатор видимости чем отдельное ключевое слово.
def это публичная функция.
Я думаю, что отдельные модификаторы видимости это большая проблема, они привлекают внимание своей заметностью. При просмотре кода нам ведь обычно не нужно знать где доступны привязки и функции, мы хотим видеть общую структуру, а видим в первую очередь множество private и internal. Может быть потому Питон так и популярен в том числе, что их там нет.
В наборе еще fun есть. Сложность пяти ключевых слов компенсируется тем, что для общего понимания кода разницу между ними можно не учитывать.
Тут тоже не совсем ясно, зачем вообще кортеж с одним элементом? Не проще ли просто сам этот элемент и использовать?
Кортежи с одним элементом уточняют тип. MutPtr например может быть VkInstance, VkDevice или VkImage, которые мы не хотели бы смешивать. Ptr<char> может быть как строкой, если в конце \0, так и указателем на символ.
Здесь ещё не принято решение. Код проще если определенный метод нельзя переопределить, так реализовано сейчас. Но если это вызовет сложности - можно разрешить, если у метода есть соответствующий атрибут.
Есть типаж как в Rust, которым можно ограничить переменную типа. Есть интерфейс как в CSharp, к которому можно привести объект. Наследования с созданием поля как в Jai/Odin я не рассматривал. Отдельного синтаксиса для реализации интерфейса нет, нужно его унаследовать, после чего определить методы.
О зеркалах не думал. Вероятно будет общественное достояние, не вижу пользы от лицензий. Документации пока нет. По взаимодействию с С вскоре будет статья. CI рано.
Ключевые слова отображают, что разница незначительна для просмотра кода, при более детальном же разборе мы её заметим.
Скрыть хотят лишние детали, ведь если мы будем замечать всё, как в случае с
constвместоval- мы больше не сможем просматривать код, всегда придётся в нём разбираться.Мы всё ещё видим публичный интерфейс, но теперь видим ещё и структуру, потому что ничего нам больше не мешает.
Это упростило код, что помогло создать хайп.
Конечно же разница есть, но она не всегда имеет значение. Например у нас в коде есть элемент с именем
display_name, мы знаем что он нам вернёт независимо от ключевого слова, и часто нам этого достаточно.Деструкторы будут.
@ownerпозволит освобождать объекты и указатели.Так задумано,
valиvarэто публичные поля, в большинстве случаев для читателя разницы между ними нет, поэтому хорошо что их запись отличается только одной буквой.defэто публичная функция.Я думаю, что отдельные модификаторы видимости это большая проблема, они привлекают внимание своей заметностью. При просмотре кода нам ведь обычно не нужно знать где доступны привязки и функции, мы хотим видеть общую структуру, а видим в первую очередь множество
privateиinternal. Может быть потому Питон так и популярен в том числе, что их там нет.В наборе еще
funесть. Сложность пяти ключевых слов компенсируется тем, что для общего понимания кода разницу между ними можно не учитывать.Кортежи с одним элементом уточняют тип.
MutPtrнапример может бытьVkInstance,VkDeviceилиVkImage, которые мы не хотели бы смешивать.Ptr<char>может быть как строкой, если в конце\0, так и указателем на символ.В С не знаю, в Кедре никак. Если есть ситуации, где такой размер окажется полезен - хотел бы о них послушать.
Да, компилятор есть, будет опубликован когда перепишу его на Кедр.
Редактор это большое поле для новых идей, и реализовать их можно только в условиях полной свободы.
Да, структура кода задаётся отступами. Всё что нужно после вставки большого фрагмента кода - установить ему нужный отступ.
LLVM не используется, это большая зависимость, промежуточный язык С предпочтительнее. Компилятор написан на Kotlin.
Здесь ещё не принято решение. Код проще если определенный метод нельзя переопределить, так реализовано сейчас. Но если это вызовет сложности - можно разрешить, если у метода есть соответствующий атрибут.
Есть типаж как в Rust, которым можно ограничить переменную типа. Есть интерфейс как в CSharp, к которому можно привести объект. Наследования с созданием поля как в Jai/Odin я не рассматривал. Отдельного синтаксиса для реализации интерфейса нет, нужно его унаследовать, после чего определить методы.
О зеркалах не думал. Вероятно будет общественное достояние, не вижу пользы от лицензий. Документации пока нет. По взаимодействию с С вскоре будет статья. CI рано.
Интересно подробнее послушать о вопросах по системе наследования.
За счет наличия абстракций более высокого уровня. С минималистичен, хороший промежуточный язык, но вручную писать на нём код сложно.