Я бы ответил так. Нам известна разность потенциалов на концах провода. По определению разности потенциалов работа по перемещению электрона с зарядом (e) с одного конца провода на другой равна
Также по определению работы: Считая, что () у нас постоянное вдоль провода, получаем:
Что мы здесь видим:
Напряжённость поля зависит от длины провода, но не зависит от его ширины (хотя сопротивление действительно зависит от сечения).
Электрон в проводнике движется с постоянной скоростью, поэтому суммарная действующая на него сила равна нулю.
В первом приближении можно сказать, что на него действует сила «сопротивления» проводника. Во втором приближении — электрическое поле не успевает ускорить электрон: он постоянно сталкивается с атомами кристаллической решётки и передаёт им свой импульс.
P.S. меня поразило что нейронка ошиблась в вопросе который мог бы быть на ЕГЭ. перепроверил всё ещё ошибается, но если напомнить что напряжение на концах проводника фиксировано то даёт правильный ответ
Мой тезис в том, что удобство чтения кода должно быть поставлено намного выше удобства его написания.
Вот это очень интересное утверждение. Возможно зависит от задач. А точнее от того сколько раз написанный код будут читать. Если я пишу код чтобы поисследовать данные и я выполню его 1 раз мне очевидно важнее удобство написания (Условно формат Jupiter notebook). Наверное в вашем сценарии предполагается что читать код будут много раз и тогда ваш тезис верный.
Но тут возникает ещё одна мысль, а что если совместить удобство написания и удобство чтения. Что если объект будет в себе хранить и то как его отображать в виде кода. Например чтобы я мог написать выражение как a / b или a.divide(b) а оно при форматирование отобразилось как
(При этом сам код останется как был. Его всегда можно посмотреть и подредактировать в сыром виде) Идея взята из Wolfram mathematics, но уверен она и в других местах встречается.
P.S. я понимаю это имеет слабое отношение к вашему языку и его ниши, но в целом интересно ваше мнение по дизайну языков
Иногда возможности автокомплита ограничены синтаксисом языка. Давайте попробую показать на примерах. Самый простой пример — SQL:
SELECT email, age FROM users;
При таком синтаксисе редактор не может подсказать возможные значения колонок для таблицы users. Такой синтаксис был бы лучше:
SELECT FROM users email, age;
Ещё один пример: допустим, у меня есть функция для поворота вектора на угол a. Я могу оформить её как функцию rotate(x, a), а могу — как метод x.rotate(a). Второй вариант лучше для автокомплита, потому что если я не помню название функции, редактор подскажет её после точки.
Кроме собственно синтаксиса хочется, чтобы создатель библиотеки на языке мог гибко настраивать возможные значения для следующего шага через типы или ещё как-то. Например, в этой статье рассказывается про преимущество Fluent-подхода по сравнению с вызовом функций с несколькими аргументами (интересен там самый последний пример).
Из более практичного: было бы круто, если бы ваш язык учитывал JSON Schema (если такая есть) для автокомплита.
понятно что это всё достигается симбиозом между языком и редактором
На Хабре средний уровень комментариев низкий (в том числе дискуссий) и это плохо ТК тяжело искать ценную информацию. Тут особо не поспоришь однако вопрос что с этим делать
Усилить модерацию (но на это нужно много ресурсов + потеряется часть ценного контента)
Перестроится в формат соцсети, тоесть рейтинг для каждого считается индивидуально (возможно по достаточно сложной формуле идеально если её можно придумать самому) учитывая рейтинг интересных мне людей, людей у которым интересно тоже что и мне
Мне кажется второй вариант более перспективен
Его можно применять не только к статьям, но и к комментариям тоже. хорошая новость что даже без алгоритмов выдачи хабр остаётся библиотекой + форумом в котором много всего ценного.А алгоритмы можно и в будущем навесить никто не умрёт
правдали что вашу мысль можно переформулировать так: давайте везде где только можно использовать интерфейсы (trait, protocol как их не называй) и в этих интерфейсах требовать то что нам действительно нужно. С такой мыслью я согласен, интересно может существует какой-нибудь интерфейсно ориентированый язык?
хорошая статья, не знал что это называется fluent подходом. Меня тоже всегда тянуло в эту сторону, и главная причина мне кажется вот эта
При Fluent подходе мы будем видеть только те подсказки, которые доступны на конкретном шаге.
тоесть мы можем пользоваться библиотекой как конструктором. Может вы знаете язык/языки которые специально проэктировались для такого подхода? требования примерно такие:
можно гибко настраивать возможности следующего шага
Интересно что у вас в целях языка нету autocomplete friendly мне кажется это очень важный пункт, позволяет стереть грань между использованием библиотеки и полноценным UI
Кажется, я понял вашу идею: когда я написал WHERE @location = #id, IDE должна предложить именно id, а не какое-то другое поле, потому что я хочу заджойнить его с @location.
Иными словами, если я печатаю g(a, f(b, ???)), то IDE должна подсказывать возможные значения ???, используя не только ограничения функции f, но и ограничения функции g (чтобы возвращаемое значение f было допустимым аргументом для g).
С этим утверждением я не согласен. Я считаю, что для автокомплита IDE должна использовать только ограничения внутренней функции f.
Идея такая: мы точно не знаем, что пользователь хочет сделать с f(b, ???). Возможно, он не собирается сразу передавать результат в g, а сначала хочет выполнить какую-то операцию, например f(b, ???) * 3, или вообще k(f(b, ???)) . Поэтому мы не знаем, каким должно быть возвращаемое значение f, и нам нельзя применять внешние, нестрогие ограничения.
Что можно сделать, если мы всё-таки хотим, чтобы IDE подсказывала поле id (например, если мы считаем, что внутри join вообще нельзя использовать сложную арифметику)?
В этом случае создатель библиотеки должен оформить join как одну функцию, например так:
join(t_name, c_name, t_name, c_name)
Тогда автокомплит будет работать корректно, и мы не «обрубим» ничего лишнего. При этом визуально синтаксис для пользователя может остаться таким же (или почти таким же): WHERE @location = #id просто будет распарсено в плоский вызов функции, и тогда IDE сможет дать корректные подсказки.
Я согласен, что найти подходящую функцию по двум параметрам проще, чем по одному.
Чтобы концептуально говорить про автокомплит, предлагаю зафиксировать три вещи:
Признать, что мы не можем найти все подходящие варианты функций по аргументам (их может быть вообще бесконечное количество) и поэтому должны выдавать только часть вариантов — наиболее релевантную для пользователя.
Рассматривать функцию g(x, y, z) как g(x)(y)(z) — это полный эквивалент.
Считать, что у нас вообще есть одна функция f, у которой миллион перегрузок. Например, функцию sum(x, y) мы представим в виде f("sum")(a)(b), а объектно-ориентированный стиль hero.moveLeft(6).moveRight(3) — в виде f(hero)("moveLeft")(6)("moveRight")(3).
Я понимаю, что этот формализм не совсем строгий, но его точно можно сделать строгим, добавив немного дополнительных аргументов.
Теперь постановка задачи такая: пользователь вводит значения аргументов слева направо, а мы должны определить возможные значения следующего аргумента. Почему именно такая постановка? Потому что в общем случае, если мы будем по произвольным параметрам пытаться определить значения всех остальных, получится слишком много вариантов, и мы пользователю не поможем.
Единственный шанс помочь пользователю — это договориться о стандарте. И стандарт такой: пользователь вводит аргументы поочерёдно, а создатель библиотеки проектирует перегрузки так, чтобы следующий шаг (аргумент) пользователю было легко выбрать. То есть мы, как создатели языка, фактически определяем протокол, через который создатель библиотеки может помочь пользователю удобно её использовать.
Например, в случае с героем однозначно плохая последовательность — f("moveLeft")(hero)(6). А вот дальше уже дело вкуса автора библиотеки: каждый сделает по-своему. Можно написать f(hero)("moveLeft")(6), а можно f(hero)("move")("left")(6), или даже f(hero)("move")(6)("left").
В SQL вообще много ошибок из-за идеи сделать язык близкий к человеческому. понятно что в своё время он был хорош. Для простых запросов он выглядит как предложение на англиском но из-за этого у него сейчас куча проблемм. Из очевидного WHERE, HAVING, QUALIFY это одна команда, но с разными словами предложение звучит красивее, PRQL был создан чтобы исправить эти проблеммы.
Я бы не смешивал задание контекста и задание первого аргумента
если честно не понял эту мысль, но я не буду спорить что автокамлит через . не идеален скорее всего можно придумать систему круче (кст интересно попробовать придумать) чтобы было больше символов которые вызывают тригер подсказок, сейчас это .([:: хочется больше разных, возможно другой тригер механизм. вобщем это глубокий и важный вопрос.
если вы в автокомплите предлагаете ограничется только структурой модулей (по модулю показывать какие в нём есть функции) то это хорошо, но этого мало, почему бы не добавить автокомплит функции по первому аргументу, я бы даже пошёл дальше и думал бы над автокомплитом для втого аргумента по функции и первому аргументу (хотя тут много трудностей)
О примеры с данными моя любимая тема сечас много накидаю)
Я думаю, что синтаксис может быть любой, всё равно в итоге код парсится в абстрактное синтаксическое дерево. И на этом уровне можно реализовать любые проверки, автодополнения и так далее.
Вот тут я не согласен. Мне всё-таки хочется писать код линейно, чтобы подсказки были скорее вперёд, чем назад. Возможно, это дело привычки, и у программистов будущего такого не будет — и тогда претензии к Lisp в этом плане уйдут. Но если говорить о том, что есть сейчас.
В чём удобство языков с dot-нотацией? Допустим, я хочу получить почту пользователя, но я точно не помню, как я её назвал: mail или email. В языках типа TypeScript я пишу user, затем нажимаю . — и в этот момент IDE понимает контекст, знает тип объекта и предлагает подходящие поля. Подсказки появляются справа и органично вписываются в процесс написания кода.
В SQL, например, так не получится. Я написал SELECT, и пока совершенно непонятно, какую колонку мне предлагать. Я могу пойти дальше и написать SELECT FROM users, ожидая автокомплит в этот момент — чтобы он предложил названия колонок и вставил их назад. Но тогда становится непонятно: нужно ли перекидывать курсор обратно к вставленному тексту или нет.
Я понимаю, что это может звучать как мелочи, но именно такие мелочи очень важны при использовании языка. Поэтому синтаксис должен быть не просто выразительным, но ещё и удобным с точки зрения предсказания следующего действия пользователя.
Работа с БД здесь — очень хороший пример. Тут как раз катастрофически важно, чтобы язык знал всё о структуре данных и умел использовать это для подсказок. Потому что я не могу помнить названия всех колонок и таблиц — я хочу выбирать их из выпадающего списка. Конкретно про SQL: я вообще хочу создать язык ему на замену (для больших аналитических запросов).
Я думаю, что при создании DSL или фреймворка важна идея которая за ними стоит, важно какие кирпичики лего мы выделили и из которых потом будем собирать приложение.
Тут согласен вот в моём случае это идея что в языке по работе с данными я должен работать не с колонками в таблице а с метриками, тоесть другой базовай кирпичек
Меня тоже очень интересует тема создания хороших библиотек и DSL (мне кажется, что по сути хорошая библиотека на существующем языке не сильно отличается от DSL). Я согласен с тем, что хочется неизбыточный синтаксис и возможность всё переиспользовать в идеальном языке. Но, на мой взгляд, важнее возможности LSP (Language Server Protocol): чтобы для каждого куска кода IDE понимала типы и то, какие методы или функции возможны.
Важно, чтобы сам синтаксис языка был удобен для автокомплита. Например, Lisp в этом плане плох: там нельзя по аргументу подобрать подходящую функцию. Языки с нотацией вида user.age() в этом смысле хороши, но, возможно, этого тоже недостаточно. Хочется язык, в котором можно создавать произвольно сложные правила для подсказок.
Этой проблемой я заинтересовался полгода назад, и пока что самым близким к идеалу языком для меня оказался TypeScript: его система типов позволяет делать практически что угодно. Но он очень плох по второму критерию — созданию компактного синтаксиса (там даже нельзя перегружать операторы). Я долго думал, что мне подойдёт какой-нибудь функциональный язык вроде Scala, Lean или OCaml (я много чего перепробовал), но, как ни странно, у них оказалась недостаточно умная или настраиваемая система типов. Так что я нахожусь в активном поиске.
Сейчас присматриваюсь к Langium, но не уверен, что система типов в нём достаточно мощная. В любом случае, мне интересно, разделяете ли вы мою убеждённость в важности LSP или нет.
про коментарии тогда второй подход создать для того кто пользуется моей системой отдельную схему с вьюшками на изначальные таблицы и в этих виюшках уже будут коменты. всё равно в реальности обычно для построения ветрин данных используются инструменты типа dbt, sqlmesh и нету проблемму для каждого отделу создать свою вьюшку, для этого кст и нужен таг link тк очень часто исходники это не физические таблички а вьюшки а к ним в описание primary/foreign key уже не добавишь (зависит от бд).
Даже вас я думаю не устроит выборка формируемая в течение 50+ часов.
безусловно запрос который работает больше 5 минут уже плохо нужно думать как оптимизировать. Но тут скорее это какоето предогрегирование добавление копии таблицы с другой сортировкой если мы говорим про кликхаус. для этого используют dbt, sqlmesh. безусловно для таких вещей мой язык не подходит
игнорирование СУБД: так как мой язык компилируется в SQL, то есть в БД летит один SQL-запрос. Это как раз принципиальный момент: я хочу создать компактный и удобный для человека язык, который при этом будет быстрым, так как будет компилироваться в SQL и выполняться как SQL.
Насчёт оптимизации — это сложный вопрос. Я уверен, что запросы, где очень важна оптимальность и которые выполняются часто и много, безусловно останутся на чистом SQL с хинтами, и автоматически я не смогу делать лучше. Но целевой областью своего языка я вижу именно аналитические запросы, которые часто выполняются всего один раз или очень редко (посмотрел интересующий меня срез, ничего интересного не увидел — пошёл дальше), и в такой парадигме, если я пишу запросы, которые будут выполняться раз в неделю, месяц или вообще один раз, но мне нужно написать их 100 разных, очень важна именно выразительность языка, а не его оптимальность.
При этом, например, переиспользуемость метрик важна, чтобы был один источник истины: доход с продаж мы считаем везде одинаково (не с точки зрения скорости и оптимальности).
уничтожение комментариев: наверное, вы про @link(pets, machines) и т. д. Это спорный момент. В свою защиту могу сказать, что таких тагов немного — не больше одного на столбец — и это не сильно мешает читать остаток коммента (на мой взгляд). Более того, часть тагов (link, id) можно добавить в виде primary/foreign key, оставшиеся можно и не указывать — просто качество модели данных станет чуть хуже. Также можно добавить возможность подгружать эту инфу отдельным файлом YAML.
Очень понравилась ваша статья, сильно меня продвинула. обязательно прочитаю ваши следующие статьи. сейчас интереснее всего 3 момента 1) про объединение типов это стало для меня небольшим шоком
На самом деле, объединение типов в общем случае - это не то же самое, что их сумма.
и хочется узнать используется ли в теории типов именно объединение (кажется что в программах оно часто встречается) и если используется то как связано с суммой произведением и тд 2) я правильно понял что задача теории типов (компилятора) определить наиболее узкий тип результата по входным типам? а задача програмиста подабрать наиболее узкие типы для входных значений и наиболее широкие для типа функций (точнее для A^B максимально широкий для B и максимально узкий для A) или в идеале типы функций должен определять сам компилятор? 3) самое важное какой язык сейчас ближе всего к математической теории типов на ваш взгляд? возможно совсем нишивый только развивающийся и тд
Я бы ответил так. Нам известна разность потенциалов на концах провода. По определению разности потенциалов работа по перемещению электрона с зарядом (e) с одного конца провода на другой равна
Также по определению работы:
) у нас постоянное вдоль провода, получаем:
Считая, что (
Что мы здесь видим:
Напряжённость поля зависит от длины провода, но не зависит от его ширины (хотя сопротивление действительно зависит от сечения).
Электрон в проводнике движется с постоянной скоростью, поэтому суммарная действующая на него сила равна нулю.
В первом приближении можно сказать, что на него действует сила «сопротивления» проводника.
Во втором приближении — электрическое поле не успевает ускорить электрон: он постоянно сталкивается с атомами кристаллической решётки и передаёт им свой импульс.
P.S. меня поразило что нейронка ошиблась в вопросе который мог бы быть на ЕГЭ. перепроверил всё ещё ошибается, но если напомнить что напряжение на концах проводника фиксировано то даёт правильный ответ
Да так красивее выглядит согласен
Вот это очень интересное утверждение. Возможно зависит от задач. А точнее от того сколько раз написанный код будут читать. Если я пишу код чтобы поисследовать данные и я выполню его 1 раз мне очевидно важнее удобство написания (Условно формат Jupiter notebook). Наверное в вашем сценарии предполагается что читать код будут много раз и тогда ваш тезис верный.
Но тут возникает ещё одна мысль, а что если совместить удобство написания и удобство чтения. Что если объект будет в себе хранить и то как его отображать в виде кода. Например чтобы я мог написать выражение как a / b или a.divide(b) а оно при форматирование отобразилось как
(При этом сам код останется как был. Его всегда можно посмотреть и подредактировать в сыром виде) Идея взята из Wolfram mathematics, но уверен она и в других местах встречается.
P.S. я понимаю это имеет слабое отношение к вашему языку и его ниши, но в целом интересно ваше мнение по дизайну языков
Иногда возможности автокомплита ограничены синтаксисом языка. Давайте попробую показать на примерах. Самый простой пример — SQL:
При таком синтаксисе редактор не может подсказать возможные значения колонок для таблицы
users. Такой синтаксис был бы лучше:Ещё один пример: допустим, у меня есть функция для поворота вектора на угол a. Я могу оформить её как функцию
rotate(x, a), а могу — как методx.rotate(a). Второй вариант лучше для автокомплита, потому что если я не помню название функции, редактор подскажет её после точки.Кроме собственно синтаксиса хочется, чтобы создатель библиотеки на языке мог гибко настраивать возможные значения для следующего шага через типы или ещё как-то. Например, в этой статье рассказывается про преимущество Fluent-подхода по сравнению с вызовом функций с несколькими аргументами (интересен там самый последний пример).
Из более практичного: было бы круто, если бы ваш язык учитывал JSON Schema (если такая есть) для автокомплита.
понятно что это всё достигается симбиозом между языком и редактором
Как я понял вашу мысль
На Хабре средний уровень комментариев низкий (в том числе дискуссий) и это плохо ТК тяжело искать ценную информацию. Тут особо не поспоришь однако вопрос что с этим делать
Усилить модерацию (но на это нужно много ресурсов + потеряется часть ценного контента)
Перестроится в формат соцсети, тоесть рейтинг для каждого считается индивидуально (возможно по достаточно сложной формуле идеально если её можно придумать самому) учитывая рейтинг интересных мне людей, людей у которым интересно тоже что и мне
Мне кажется второй вариант более перспективен
Его можно применять не только к статьям, но и к комментариям тоже. хорошая новость что даже без алгоритмов выдачи хабр остаётся библиотекой + форумом в котором много всего ценного.А алгоритмы можно и в будущем навесить никто не умрёт
правдали что вашу мысль можно переформулировать так:
давайте везде где только можно использовать интерфейсы (trait, protocol как их не называй)
и в этих интерфейсах требовать то что нам действительно нужно.
С такой мыслью я согласен, интересно может существует какой-нибудь интерфейсно ориентированый язык?
хорошая статья, не знал что это называется fluent подходом. Меня тоже всегда тянуло в эту сторону, и главная причина мне кажется вот эта
тоесть мы можем пользоваться библиотекой как конструктором. Может вы знаете язык/языки которые специально проэктировались для такого подхода?
требования примерно такие:
можно гибко настраивать возможности следующего шага
синтаксис заточен под такой подход
Интересно что у вас в целях языка нету autocomplete friendly мне кажется это очень важный пункт, позволяет стереть грань между использованием библиотеки и полноценным UI
Кажется, я понял вашу идею:
когда я написал
WHERE @location = #id, IDE должна предложить именноid, а не какое-то другое поле, потому что я хочу заджойнить его с@location.Иными словами, если я печатаю
g(a, f(b, ???)), то IDE должна подсказывать возможные значения???, используя не только ограничения функцииf, но и ограничения функцииg(чтобы возвращаемое значениеfбыло допустимым аргументом дляg).С этим утверждением я не согласен. Я считаю, что для автокомплита IDE должна использовать только ограничения внутренней функции
f.Идея такая: мы точно не знаем, что пользователь хочет сделать с
f(b, ???). Возможно, он не собирается сразу передавать результат вg, а сначала хочет выполнить какую-то операцию, напримерf(b, ???) * 3, или вообщеk(f(b, ???)). Поэтому мы не знаем, каким должно быть возвращаемое значениеf, и нам нельзя применять внешние, нестрогие ограничения.Что можно сделать, если мы всё-таки хотим, чтобы IDE подсказывала поле
id(например, если мы считаем, что внутриjoinвообще нельзя использовать сложную арифметику)?В этом случае создатель библиотеки должен оформить
joinкак одну функцию, например так:Тогда автокомплит будет работать корректно, и мы не «обрубим» ничего лишнего. При этом визуально синтаксис для пользователя может остаться таким же (или почти таким же):
WHERE @location = #idпросто будет распарсено в плоский вызов функции, и тогда IDE сможет дать корректные подсказки.Я согласен, что найти подходящую функцию по двум параметрам проще, чем по одному.
Чтобы концептуально говорить про автокомплит, предлагаю зафиксировать три вещи:
Признать, что мы не можем найти все подходящие варианты функций по аргументам (их может быть вообще бесконечное количество) и поэтому должны выдавать только часть вариантов — наиболее релевантную для пользователя.
Рассматривать функцию
g(x, y, z)какg(x)(y)(z)— это полный эквивалент.Считать, что у нас вообще есть одна функция
f, у которой миллион перегрузок.Например, функцию
sum(x, y)мы представим в видеf("sum")(a)(b),а объектно-ориентированный стиль
hero.moveLeft(6).moveRight(3)— в видеf(hero)("moveLeft")(6)("moveRight")(3).Я понимаю, что этот формализм не совсем строгий, но его точно можно сделать строгим, добавив немного дополнительных аргументов.
Теперь постановка задачи такая: пользователь вводит значения аргументов слева направо, а мы должны определить возможные значения следующего аргумента. Почему именно такая постановка? Потому что в общем случае, если мы будем по произвольным параметрам пытаться определить значения всех остальных, получится слишком много вариантов, и мы пользователю не поможем.
Единственный шанс помочь пользователю — это договориться о стандарте. И стандарт такой: пользователь вводит аргументы поочерёдно, а создатель библиотеки проектирует перегрузки так, чтобы следующий шаг (аргумент) пользователю было легко выбрать. То есть мы, как создатели языка, фактически определяем протокол, через который создатель библиотеки может помочь пользователю удобно её использовать.
Например, в случае с героем однозначно плохая последовательность —
f("moveLeft")(hero)(6).А вот дальше уже дело вкуса автора библиотеки: каждый сделает по-своему. Можно написать
f(hero)("moveLeft")(6),а можно
f(hero)("move")("left")(6),или даже
f(hero)("move")(6)("left").В SQL вообще много ошибок из-за идеи сделать язык близкий к человеческому. понятно что в своё время он был хорош. Для простых запросов он выглядит как предложение на англиском но из-за этого у него сейчас куча проблемм. Из очевидного WHERE, HAVING, QUALIFY это одна команда, но с разными словами предложение звучит красивее, PRQL был создан чтобы исправить эти проблеммы.
если честно не понял эту мысль, но я не буду спорить что автокамлит через
.не идеален скорее всего можно придумать систему круче (кст интересно попробовать придумать) чтобы было больше символов которые вызывают тригер подсказок, сейчас это.([::хочется больше разных, возможно другой тригер механизм. вобщем это глубокий и важный вопрос.если вы в автокомплите предлагаете ограничется только структурой модулей (по модулю показывать какие в нём есть функции) то это хорошо, но этого мало, почему бы не добавить автокомплит функции по первому аргументу,
я бы даже пошёл дальше и думал бы над автокомплитом для втого аргумента по функции и первому аргументу (хотя тут много трудностей)
О примеры с данными моя любимая тема сечас много накидаю)
Вот тут я не согласен. Мне всё-таки хочется писать код линейно, чтобы подсказки были скорее вперёд, чем назад. Возможно, это дело привычки, и у программистов будущего такого не будет — и тогда претензии к Lisp в этом плане уйдут. Но если говорить о том, что есть сейчас.
В чём удобство языков с dot-нотацией? Допустим, я хочу получить почту пользователя, но я точно не помню, как я её назвал:
mailилиemail. В языках типа TypeScript я пишуuser, затем нажимаю.— и в этот момент IDE понимает контекст, знает тип объекта и предлагает подходящие поля. Подсказки появляются справа и органично вписываются в процесс написания кода.В SQL, например, так не получится. Я написал
SELECT, и пока совершенно непонятно, какую колонку мне предлагать. Я могу пойти дальше и написатьSELECT FROM users, ожидая автокомплит в этот момент — чтобы он предложил названия колонок и вставил их назад. Но тогда становится непонятно: нужно ли перекидывать курсор обратно к вставленному тексту или нет.Я понимаю, что это может звучать как мелочи, но именно такие мелочи очень важны при использовании языка. Поэтому синтаксис должен быть не просто выразительным, но ещё и удобным с точки зрения предсказания следующего действия пользователя.
Работа с БД здесь — очень хороший пример. Тут как раз катастрофически важно, чтобы язык знал всё о структуре данных и умел использовать это для подсказок. Потому что я не могу помнить названия всех колонок и таблиц — я хочу выбирать их из выпадающего списка. Конкретно про SQL: я вообще хочу создать язык ему на замену (для больших аналитических запросов).
Тут согласен вот в моём случае это идея что в языке по работе с данными я должен работать не с колонками в таблице а с метриками, тоесть другой базовай кирпичек
Меня тоже очень интересует тема создания хороших библиотек и DSL (мне кажется, что по сути хорошая библиотека на существующем языке не сильно отличается от DSL). Я согласен с тем, что хочется неизбыточный синтаксис и возможность всё переиспользовать в идеальном языке. Но, на мой взгляд, важнее возможности LSP (Language Server Protocol): чтобы для каждого куска кода IDE понимала типы и то, какие методы или функции возможны.
Важно, чтобы сам синтаксис языка был удобен для автокомплита. Например, Lisp в этом плане плох: там нельзя по аргументу подобрать подходящую функцию. Языки с нотацией вида
user.age()в этом смысле хороши, но, возможно, этого тоже недостаточно. Хочется язык, в котором можно создавать произвольно сложные правила для подсказок.Этой проблемой я заинтересовался полгода назад, и пока что самым близким к идеалу языком для меня оказался TypeScript: его система типов позволяет делать практически что угодно. Но он очень плох по второму критерию — созданию компактного синтаксиса (там даже нельзя перегружать операторы). Я долго думал, что мне подойдёт какой-нибудь функциональный язык вроде Scala, Lean или OCaml (я много чего перепробовал), но, как ни странно, у них оказалась недостаточно умная или настраиваемая система типов. Так что я нахожусь в активном поиске.
Сейчас присматриваюсь к Langium, но не уверен, что система типов в нём достаточно мощная. В любом случае, мне интересно, разделяете ли вы мою убеждённость в важности LSP или нет.
про коментарии тогда второй подход создать для того кто пользуется моей системой отдельную схему с вьюшками на изначальные таблицы и в этих виюшках уже будут коменты. всё равно в реальности обычно для построения ветрин данных используются инструменты типа dbt, sqlmesh и нету проблемму для каждого отделу создать свою вьюшку, для этого кст и нужен таг link тк очень часто исходники это не физические таблички а вьюшки а к ним в описание primary/foreign key уже не добавишь (зависит от бд).
безусловно запрос который работает больше 5 минут уже плохо нужно думать как оптимизировать. Но тут скорее это какоето предогрегирование добавление копии таблицы с другой сортировкой если мы говорим про кликхаус. для этого используют dbt, sqlmesh. безусловно для таких вещей мой язык не подходит
игнорирование СУБД: так как мой язык компилируется в SQL, то есть в БД летит один SQL-запрос. Это как раз принципиальный момент: я хочу создать компактный и удобный для человека язык, который при этом будет быстрым, так как будет компилироваться в SQL и выполняться как SQL.
Насчёт оптимизации — это сложный вопрос. Я уверен, что запросы, где очень важна оптимальность и которые выполняются часто и много, безусловно останутся на чистом SQL с хинтами, и автоматически я не смогу делать лучше. Но целевой областью своего языка я вижу именно аналитические запросы, которые часто выполняются всего один раз или очень редко (посмотрел интересующий меня срез, ничего интересного не увидел — пошёл дальше), и в такой парадигме, если я пишу запросы, которые будут выполняться раз в неделю, месяц или вообще один раз, но мне нужно написать их 100 разных, очень важна именно выразительность языка, а не его оптимальность.
При этом, например, переиспользуемость метрик важна, чтобы был один источник истины: доход с продаж мы считаем везде одинаково (не с точки зрения скорости и оптимальности).
уничтожение комментариев: наверное, вы про
@link(pets, machines)и т. д. Это спорный момент. В свою защиту могу сказать, что таких тагов немного — не больше одного на столбец — и это не сильно мешает читать остаток коммента (на мой взгляд). Более того, часть тагов (link,id) можно добавить в виде primary/foreign key, оставшиеся можно и не указывать — просто качество модели данных станет чуть хуже. Также можно добавить возможность подгружать эту инфу отдельным файлом YAML.Вообще спасибо большое за вопросы.
Очень понравилась ваша статья, сильно меня продвинула. обязательно прочитаю ваши следующие статьи. сейчас интереснее всего 3 момента
1) про объединение типов это стало для меня небольшим шоком
и хочется узнать используется ли в теории типов именно объединение (кажется что в программах оно часто встречается) и если используется то как связано с суммой произведением и тд
2) я правильно понял что задача теории типов (компилятора) определить наиболее узкий тип результата по входным типам? а задача програмиста подабрать наиболее узкие типы для входных значений и наиболее широкие для типа функций (точнее для A^B максимально широкий для B и максимально узкий для A) или в идеале типы функций должен определять сам компилятор?
3) самое важное какой язык сейчас ближе всего к математической теории типов на ваш взгляд? возможно совсем нишивый только развивающийся и тд
От классического ORM типа SQLAlchemy есть очень важное отличие: метрико-ориентированность.