Я думаю, если б к вашей какой-нибудь особенности относились в обществе так же как к гомосексуализму у нас, вы бы тоже болезнено реагировали на подобную «самоиронию». Можно еще придти в семью повешенного и пошутить аналогией с физическими свойствамми маятниука — а чо формально вы правы, да.
Ну вот я и интересуюсь, какие фичи языка вы считаете нужными и почему? Еще пришла идея, что можно использовать в качестве хост языка какой-нибудь готовый шелл. Вроде там примерно те же требования
зачем если нужен велосипед, выпиливать его из самолёта
Ваша реплика выглядит странно. Мы как раз и выясняем в чем отличие «DSL на котором удобно писать скрипты сборки» от языка общего назначения (вернее, если обойтись eDSL нельзя ли скомпенсировать недостаток заточенности под задачу выгодами от лучшей поддержки).
Я взял подмножество ваших требований а вы его отрицаете словом нет, не добавляя ясности.
К тому же я задал вопрос «В любом случае нельзя ли взять наиболее подходящий ЯП общего назначения и внести необходимые дополнения туда?»
Грубо говоря, если нужно сделать свой велосипед, почему бы не использовать хотя бы стандартные гайки.
Хороший тест должен проверять одну фичу и не ломаться при добавлении других фич.
Хороший юнит тест для акцептанс, и интегрейшен тестов это не так.
Если при повседневных изменениях нужно проверять всё вручную и вписывать во все «тесты» новые пиксели, от такого TDD больше хлопот, чем пользы.
В гугле, как я понял, весь этот геморрой и происходит. Зависит от размера ущерба в случае поломки. Представьте, если например в случае неправильного рендеринга в продакшене у вас отрезают палец. :)
тесты как и требования деляться на функциональные и performance и всякие другие соответственно отдельно проверять корректность, отдельно производительность. И автоиатизировать
Каким конкретно требованиям не отвечают гомосексуалисты?
Можно пруф?
А зачем их отделять? Разве тире недостаточно ярко светится?
2. cinst conemu
зачем если нужен велосипед, выпиливать его из самолёта
Поюзать самолетную инфраструктуру.
в плане синтаксиса ничего нового не изобретено
А вот это function (name) откуда взято?
Я взял подмножество ваших требований а вы его отрицаете словом нет, не добавляя ясности.
К тому же я задал вопрос «В любом случае нельзя ли взять наиболее подходящий ЯП общего назначения и внести необходимые дополнения туда?»
Грубо говоря, если нужно сделать свой велосипед, почему бы не использовать хотя бы стандартные гайки.
Вот эти фичи мне кажутся сомнительныими:
— В том числе рекурсивное (${FOO_${BAR}}) которое иначе потребовало бы запаковку значений в словари и обратно
Если использовать чем это лучше чем ${foo.bar}
— Форсирование повторения условия в endif/endfor/end* что сильно увеличивает читабельность
Нет ли способа так увеличивать читабельность, чтобы это не понадобилось?
— Макросы
Мне кажется, в динамических языках это не так сильно нужно.
А вот это я не понял:
— Кэшированные переменные и все их атрибуты
В любом случае нельзя ли взять наиболее подходящий ЯП общего назначения и внести необходимые дополнения туда?
function (clrscr)
file(WRITE /dev/stdout "${ESCAPE}[2J")
endfunction(clrscr)
Было бы
function clrscr() { stdout.write(escape + «2J») }?
В чем преимущество своего непохожего языка сдесь?
Хороший юнит тест для акцептанс, и интегрейшен тестов это не так.
Если при повседневных изменениях нужно проверять всё вручную и вписывать во все «тесты» новые пиксели, от такого TDD больше хлопот, чем пользы.
В гугле, как я понял, весь этот геморрой и происходит. Зависит от размера ущерба в случае поломки. Представьте, если например в случае неправильного рендеринга в продакшене у вас отрезают палец. :)
Почитайте книжку How Google Tests Software как они браузер тестировали.
Правда вам может не подойти, если вы не гугл.
А что поменяется?