Зачем? ЯП дает слишком много возможностей. Потом будете обкладываться документами, соглашениями с названием «что можно использовать при конфигурации, а что нет»
Мне вот интересно, что вы предпримете в таких условиях: - вы начинаете новый проект - понимаете, что конфигурация для prod и stg будут отличаться - например, на prod нужно 10 воркеров для аутбокса, а на stg всего 5, чтобы не ушатать слабые машины на stg
Как вы поступите тут? Как будете конфигурировать приложение?
Если да, то почему одно является язком программирования, а другое нет?
Ну смотря, что считать языком программирования - я считаю языком программирования тюринг полный язык - соответсвенно мой язык под эту категорию не подходит
> Было бы интересно увидеть подробное сравнение вашего языка и перечисленных.
Ага, как-нибудь распишу
> даже не является суперсетом JSON.
Почему это плохо?
> Но если серьёзо отвечать на вопрос, то да, конечно надо.
Кому и зачем это надо? Никогда не видел, чтобы пробелы в конфигурации использовались Если действительно надо, хотелось бы пример какой-нибудь, где без этого не обойтись А если для галочки, чтобы стать суперсетом JSON, то думаю можно обойтись без этого
> Нет, речь про циклы, конечно, а-ля for item in ... или подобные способы избежать копипасты кода. Особенно полезно при модификации списков, учитывая что рекурсивный мерж просто обновит значение (что в целом логично, и правильно)
Что-то мне, кажется, что это дикий оверхед, который нужен 1% разрабов/проектов Такая сложная логика должна быть на уровне приложения, а не на уровне конфигурации
Не очень понимаю, какая конфигурация с массивом должна быть, чтобы аж циклы понадобились Возможно мы в очень разных сферах работаем, поэтому мне эта тема не близка и я ее не понимаю
В целом идея сделать максимально простой язык, который закрывает 99% потребностей А вот этот 1%, где циклы нужны или еще какая-то экзотика уж лучше не покрывать
А из статьи с примером копипасты и замены его на цикл, я предпочту копипасту - намного читабельнее и не позволит разрабам городить дичь, используя такие сложные конструкции
Ну и в довесок в ATMC можно обращаться к полям импортированного конфига То есть значения, которые дублируются можно вынести отдельно и обращаться к ним, а не копировать - по итогу можно будет изменить значение в одном месте и поменяется везде
Ну в общем не понимаю я циклы эти в конфигах - они меня пугают
--- Перечитал свой ответ и вижу, что ни с чем особо не согласился по итогу - но хочу сказать, что в любом случае спасибо за фидбек - это очень полезно для меня - много нового узнал:)
Причем скобки для массивов в yml тоже есть - можно и без них, если на новой строке писать - ну вот уже несколько способов сделать одно и тоже - не очень нравится
Ну и плюс скобки более четко визуально группируют данные - ну это ИМХО, конечно
как ATMC ведёт себя при конфликте типов при слиянии двух конфигов или что происходит, если ключ встречается в нескольких местах?
В любом случае по итогу ключ будет всегда один на выходе - каждый будет переопределять предыдущий - тип ключа будет таким, какой он был у последнего ключа, который переопределил предыдуший
Планируется ли типовая проверка, чтобы ловить подобные ошибки заранее?
Даже не задумывался, пока не спросили. Вообще думаю хорошо бы завести такую проверку - поможет быстро находить ошибки в конфигурации
> Как вы видите дальнейшее развитие проекта: будет ли поддержка других языков помимо Go
Если язык заимеет хоть какой-нибудь успех на языке Go, то да Иначе, кажется, это пустая трата времени
и есть ли планы на интеграцию с редакторами (подсветка, автодополнение)
Есть. Использую язык для своих проектов - чувствую, как без хотя бы подсветки жить тяжело (но все равно лучше, чем с json или yml :))
> любопытно было бы увидеть сравнение ATMC с ними
Выше тоже это подмечали. А я просто не хотел раздувать статью Может быть распишу сравнение позже
Опыт подсказывает что конфиг хорош такой, который можно править руками через nano «в особых случаях». YAML хоть я его и не люблю это делать позволяет без проблем, как и обычный config
Почему вы считаете, что ATMC нельзя так же править руками? На мой взгляд его править даже удобнее, чем тот же yml, потому что в nano не видно ни пробелов ни табов и ошибиться с отступом в большом конфиге будет очень просто
Даже в IDE часто можно затупить с отступом. В прочем со скобкой тоже можно затупить:)
Да, линтер решает, согласен
Причем удобно пользоваться языком, который тысячу раз протестирован и не имеет уязвимостей
Причем если ts на go переписан, то его AST получить изи, а значит сделать любой линтер или компилятор во что угодно на go тоже изи
Но мне мой лаконичный язык все равно больше нравится ахах
А есть уже подобные линтеры для ts конфигурации, не знаете?
Тем что в документации к языку конфигурирования написано, как им пользоваться
А в документации к ЯП, который используется для конфигурировании будет написано, как им нельзя пользоваться
И попробуй заставь новичков в проекте или джунов понять и осознать это быстро
Если есть хорошее ревью еще будет норм
Если ревью плохое (а не везде оно хорошее), жди беды
В случае с языком конфигурирования заговнокодить не получится - у него просто нет таких возможностей
Вот для аналогии: в php есть свой встроенный шаблонизатор, который позволяет вообще что по кайфу делать
Вопрос: сколько говнокода во вьюхах я видел?
Ответ: много
И походы в базу видел и кучу логики видел
Жуть
А будь там шаблонизатор, который не умеет все это делать, такой говнокод обошел бы меня стороной:)
Прикольно
Возможно не стоит пытаться угодить всему и вся
Есть сложные случаи, как у вас и возможно для таких случаев нужен более мощный язык
То есть для каждого кейса свой инструмент
Универсального ничего не бывает и это норма
А если бывает, то это сложно - всегда жертвуем простотой :(
Из крайности в крайность
Не очень понял ответ
Я про то что ЯП дает много возможностей - он же тюринг полный - можно что угодно сделать
А язык конфигурации должен быть максимально простым, чтобы конфигурация не превратилась в нечитабельное месиво
Иначе нужно вводить стандарты, линтеры и прочую чепуху, которая ограничивает язык
У вас есть все возможности поддержать язык для любого другого ЯП
Мне помощь не помешает:)
А как вы определяете топовость?
Чем сильнее отличается от json, тем топовее?)
Почему вы обратили внимание только на синтаксис?
Обратите внимание на фичи, пожалуйста
Ни один из перечисленных вами языков такие фичи не дает
Насколько знаю гитхаб открыт для всех
Жду ПР от вас с этими фичами)
Вообще примерно такое сделать в планах есть
Зачем? ЯП дает слишком много возможностей. Потом будете обкладываться документами, соглашениями с названием «что можно использовать при конфигурации, а что нет»
Как в json сделать импорт и слияние?
На самом деле крутая идея
Возьму на заметку, спасибо
А на сервере, как оно конфигурировалось? Через UI и в базе лежало?
Мне вот интересно, что вы предпримете в таких условиях:
- вы начинаете новый проект
- понимаете, что конфигурация для prod и stg будут отличаться
- например, на prod нужно 10 воркеров для аутбокса, а на stg всего 5, чтобы не ушатать слабые машины на stg
Как вы поступите тут? Как будете конфигурировать приложение?
Ну смотря, что считать языком программирования - я считаю языком программирования тюринг полный язык - соответсвенно мой язык под эту категорию не подходит
> Было бы интересно увидеть подробное сравнение вашего языка и перечисленных.
Ага, как-нибудь распишу
> даже не является суперсетом JSON.
Почему это плохо?
> Но если серьёзо отвечать на вопрос, то да, конечно надо.
Кому и зачем это надо? Никогда не видел, чтобы пробелы в конфигурации использовались
Если действительно надо, хотелось бы пример какой-нибудь, где без этого не обойтись
А если для галочки, чтобы стать суперсетом JSON, то думаю можно обойтись без этого
> Нет, речь про циклы, конечно, а-ля
for item in ...или подобные способы избежать копипасты кода. Особенно полезно при модификации списков, учитывая что рекурсивный мерж просто обновит значение (что в целом логично, и правильно)Что-то мне, кажется, что это дикий оверхед, который нужен 1% разрабов/проектов
Такая сложная логика должна быть на уровне приложения, а не на уровне конфигурации
Не очень понимаю, какая конфигурация с массивом должна быть, чтобы аж циклы понадобились
Возможно мы в очень разных сферах работаем, поэтому мне эта тема не близка и я ее не понимаю
В целом идея сделать максимально простой язык, который закрывает 99% потребностей
А вот этот 1%, где циклы нужны или еще какая-то экзотика уж лучше не покрывать
А из статьи с примером копипасты и замены его на цикл, я предпочту копипасту - намного читабельнее и не позволит разрабам городить дичь, используя такие сложные конструкции
Ну и в довесок в ATMC можно обращаться к полям импортированного конфига
То есть значения, которые дублируются можно вынести отдельно и обращаться к ним, а не копировать - по итогу можно будет изменить значение в одном месте и поменяется везде
Ну в общем не понимаю я циклы эти в конфигах - они меня пугают
---
Перечитал свой ответ и вижу, что ни с чем особо не согласился по итогу - но хочу сказать, что в любом случае спасибо за фидбек - это очень полезно для меня - много нового узнал:)
Кавычки только для строк
Скобки позволяют хоть в одну строку писать конфиг
Причем скобки для массивов в yml тоже есть - можно и без них, если на новой строке писать - ну вот уже несколько способов сделать одно и тоже - не очень нравится
Ну и плюс скобки более четко визуально группируют данные - ну это ИМХО, конечно
В любом случае по итогу ключ будет всегда один на выходе - каждый будет переопределять предыдущий - тип ключа будет таким, какой он был у последнего ключа, который переопределил предыдуший
Даже не задумывался, пока не спросили. Вообще думаю хорошо бы завести такую проверку - поможет быстро находить ошибки в конфигурации
> Как вы видите дальнейшее развитие проекта: будет ли поддержка других языков помимо Go
Если язык заимеет хоть какой-нибудь успех на языке Go, то да
Иначе, кажется, это пустая трата времени
Есть. Использую язык для своих проектов - чувствую, как без хотя бы подсветки жить тяжело (но все равно лучше, чем с json или yml :))
> любопытно было бы увидеть сравнение ATMC с ними
Выше тоже это подмечали. А я просто не хотел раздувать статью
Может быть распишу сравнение позже
Да, для меня тоже
Тут проблема примеров просто - в реальности конфиги в 100 раз больше - там то и начинаются проблемы
Почему вы считаете, что ATMC нельзя так же править руками?
На мой взгляд его править даже удобнее, чем тот же yml, потому что в nano не видно ни пробелов ни табов и ошибиться с отступом в большом конфиге будет очень просто
Даже в IDE часто можно затупить с отступом. В прочем со скобкой тоже можно затупить:)
Интересная идея
Мне такое не пригождалось никогда, поэтому даже не задумывался о таком
Может есть примеры, где такой функционал хотелось бы иметь?