tag:blogger.com,1999:blog-1453949493029009080.post8847647499740117375..comments2022-02-13T09:42:52.129+02:00Comments on То, что важно лично для меня: Куда может завести "свой DSL". Часть 3. Резюме.NameRechttp://www.blogger.com/profile/00070033877714975718noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-1453949493029009080.post-65281222150207607112013-09-12T22:34:02.158+03:002013-09-12T22:34:02.158+03:00>>«Императивщина всё равно функциональнее де...>>«Императивщина всё равно функциональнее декларативных ЯП.»<br />>>-- Да, но она и намного тяжеловестнее.<br />Согласен, но на примере того же MySQL: оверхед на разбор SQL, построение внутренних структур, выполнение оптимизаций (которые не всегда к месту) бывает настолько велик, что проще сказать "что сделать" нежели "чего я хочу". Однако, отказ от SQL приведёт к тому, что придётся учить внутренности каждой СУБД. SQL и взял именно своей кроссплатформенностью. Поэтому остановлюсь на мнении, что свой DSL - круто, прикольно, но только "поиграться", для реальной жизни надо очень осторожно подходить к решению о его создании - порой может быть дешевле реализовать поддержку скриптового языка.Anonymoushttps://www.blogger.com/profile/00298421558917743578noreply@blogger.comtag:blogger.com,1999:blog-1453949493029009080.post-48917132073925933442013-09-10T12:16:30.737+03:002013-09-10T12:16:30.737+03:00«Императивщина всё равно функциональнее декларатив...«Императивщина всё равно функциональнее декларативных ЯП.»<br />-- Да, но она и намного тяжеловестнее.<br /><br />«Взять тот же SQL - некоторые от него уже отказываются (HandlerSocket для MySQL)»<br />-- Ну, "некоторые" отказываются не потому, что SQL - плохой DSL... :-)<br />Просто есть класс задач, которые хотя и можно свести к этому DSL, эффективнее решаются, если этого не делать.<br /><br />«Чтобы создавать свой DSL нужно очень чётко очертить область его применеия. К тому же это очень дорого. Поэтому пока придерживаюсь позиции, что стоит включить поддержку скриптовых языков и предоставить им API.»<br />-- Согласен. Впрочем, может зависеть от сложности самого DSL. IMHO, просто при определённом уровне этой сложности стоит задуматься об альтернативных путях, поскольку "развитие собственной языковой платформы не соответствует в интересам большинства компаний".<br />Сложный DSL IMHO может быть эффективно заменён скрипт-языком. Но если так, зачем ждать, когда DSL станет сложным, почему сразу не начать со скрипт-языка?<br /><br />«Но Ваш редактор запросов - отличное подтверждение того, что DSL создавать всё-таки иногда надо :)»<br />-- Но этот DSL не обязательно должен быть текстовым :-)<br />Согласен. <br />NameRechttps://www.blogger.com/profile/00070033877714975718noreply@blogger.comtag:blogger.com,1999:blog-1453949493029009080.post-30232655148585862822013-09-10T11:05:06.658+03:002013-09-10T11:05:06.658+03:00Императивщина всё равно функциональнее декларативн...Императивщина всё равно функциональнее декларативных ЯП. Взять тот же SQL - некоторые от него уже отказываются (HandlerSocket для MySQL), XSLT почти нигде не используется... Чтобы создавать свой DSL нужно очень чётко очертить область его применеия. К тому же это очень дорого. Поэтому пока придерживаюсь позиции, что стоит включить поддержку скриптовых языков и предоставить им API. Но Ваш редактор запросов - отличное подтверждение того, что DSL создавать всё-таки иногда надо :)Anonymoushttps://www.blogger.com/profile/00298421558917743578noreply@blogger.com