• ЖЖ Frameworks langs Сложившаяся традиция разрабатывать фреймворки для конкретной задачи, вместо новых языков, мне кажется достаточно удивительной. Единственный аргумент в защиту фреймворков который я видел — относительная простота их изучения. Этот аргумент редко используется людьми которые знают больше двух языков программирования (Weinberg, The Psychology of Computer Programming, p212) и достаточно слаб, если спросить "почему именно этот язык?" (The Blub paradox). Аргументы же за разработку языков, вместо фреймворков, приводил M. P. Ward в статье "Language Oriented Programming" указывая на возможность закрепить знания, специфичные для области применения, в качестве языковых конструкций. Кроме того Ward пытался показать, что использование отдельных языков позволяет писать более кратко (16,000 LOC в случае разработки языка + транслятора для него в LISP + кода на новом языке против 100,000 LOC на языке LISP. Какой из диалектов лиспа имелся ввиду не указано) и более безопасно (более понятный код для человека знакомого с областью применения. Дополнительные проверки безопасности транслятором. В принципе объясняет #1239695).
    ♡ recommended by @yzh44yzh

Replies (19)

  • @Kim, та все просто: писать новый язык — это страшно же, так же как и учить новый для какой-то одной задачи:)
    самый сильный аргумент, как и всегда в вопросах программирования — иррациональный
  • @anton0xf, Так писали же. И учили. Пока не пошла мода, а дальше вполне себе рациональные мода и привычка:

    "The computer industry is the only industry that's more fashion-driven than women's fashion." So says Larry Ellison, Oracle's CEO
  • @Kim, ну и вопрос про смешивание подобных языков, когда нам нужно одновременно использовать более 1го "фреймворка" для меня пока открыт..
  • @anton0xf, Так его уже решили трижды.
    1. Unix pipe
    2. RPC и shared library (обычно вкупе с FFI)
    3. Java/.NET like среды для исполнения языков с единым интерфейсом для вызова методов.
  • @Kim, не уверен, что этих вариантов всегда удобно хватит.. хотя, вроде должно, да)
    но на структуированность кода и модульность применение подобных подходов, точно, повлияет положительно)
  • @Kim, Даже четыре
    0) Вызов system в C
  • @Kim, 5. архитектура клиент-сервер
    хотя, правильнее, пожалуй, просто обобщить 0,1,2(частично),5 до "механизмы межпроцессного взаимодействия"
  • @Kim, вроде наш препод по прологу называл это "предложение", а мы просто "кляуза". Еще помню на этих лекциях никто ничего не понимал)
  • @S0ny, Ты, наверно, хотел написать ответ в #1259997, а не в #1247723
  • @Kim, промазал:-)
  • @Kim, на мой взгляд это просто болтовня какая-то. Фреймворк хорош тем, что на этом языке уже есть библиотеки. А примеры на лиспе задолбали тем, что только и есть что «где-то там пишут на лиспе», а на деле одни скобочки
  • @maxlapshin, Ну вот все они en.wikipedia.org являются примерами. И на лиспе из того списка написаны далеко не все.
  • @Kim, я настолько необразован, что кроме SQL мне все остальные совершенно неизвестны. И я вижу хороший пример Ruby, когда вовсе не надо ебстись с новым языком, а можно просто по-человечески пользоваться старым
  • @maxlapshin, А также все эти en.wikipedia.org как минимум создавались для решения конкретных задач, вместо того чтобы привносить эти задачи в чуждую языковую среду.
  • @Kim, я не понимаю чего хорошего в создании отдельного языка, когда тебе очень быстро понадобится сделать HTTP вызов или что-то ещё, что потребует всё равно похода в нижележащий уровень?
    Мне хорошо понятно чем С++ плох для бизнес-логики, но я вижу как можно пользоваться на примере того же руби и вижу, что основной язык может быть достаточно выразительным
  • @maxlapshin, Основной язык не может выражать понятия предметной области. Он их может только скрывать под библиотеками. Вынося эти понятия в отдельный язык получаешь не просто "вроде бы достаточно выразимый язык", а текстовое воплощение реализуемой задачи. Понятно, что библиотечный подход может давать достаточно близкий результат, но на практике выливается в увеличение объема кода (смотри в топике), накладные расходы в виде синтаксиса и семантики базового языка и что там ещё ребята JetBrains писали в своей рекламной статье ( jetbrains.com ).

    Если вспомнить свежие разработки, то в языковой подход, вместо библиотечного, для программ общего назначения был использован MS при создании LINQ. Удобства добавления такого транслятора тоже не очевидны?
  • @Kim, не буду тут настаивать, я не пользовался ни Linq, ни JetBrains. Я в принципе понимаю, что языки типа C++, Java да и того же erlang, могут быть неудобны для работы с бизнес-логикой хотя бы по одной простой причине: нельзя метапрограммировать на самом языке.

    В руби это удобнее и я не вижу ни одной причины клепать для него DSL не на руби
  • @maxlapshin, В руби это удобнее и я не вижу ни одной причины клепать для него DSL не на руби
    А лисп-программисты не видят причин создавать языки не транслирующиеся в лисп, чем и объясняется такое количество примеров на лиспе. И всё же метапрограммирование на руби, на сколько я вижу (простите, опыта разработки на этом языке нету), всё таки не позволяет производить трансформацию синтаксиса введённого выражения. Это значит что для любого DSL его абстракция всё таки будет протекать. Хотя бы на стыках с стандартными формами вроде if и def.

    В любом случае как только ты наклепал полноценный DSL на руби тебе и людям работающим с тобой придётся выучить его синтаксис, но взамен вы получите более адекватный задачи код и, скорее всего, более краткий код. Формально это будет отдельный язык и, собственно, о его преимуществах над честными библиотеками и был пост.
  • @Kim, более адекватный задаче и, скорее всего, более краткий кодfixed