>>767701 (OP)
http://haxe.org
Берёшь и пишешь. Не компилируется в тот язык, который тебе нужен? Пердолишь новый таргет через CustomJSGenerator. Не нравится синтаксис? Пишешь на макросах парсер того синтаксиса, который тебя устраивает, и получаешь type inference, автодополнение и строгую статическую типизацию бесплатно.

>>767701 (OP)
Берешь скалу, делаешь кастомные операторы, добавляешь новые управляющие конструкции, определяешь свои типы и не ебешь мозги.

>>767749
И получаешь пиздячую простыню на выходе, дебажить которую очень трудно.

>>767784
This: >>767786 и таргет один-единственный.

>>767749
Так. Давай так. Как на нем напердолить калькулятор соснольный? И сколько на это уйдет часов?

>>767786
http://try.haxe.org/ выбирай себе в examples код, убедись, что в options->target="javascript", конпеляй, нажимай js source, пролистывай служебные функции и смотри. Местами довольно близко к написанному коду получается.
>>767797
Смотря какой. Если просто "vvedite 4iclo:" и "vvedite operaciu:" - зависит от того, насколько быстро печатаешь. Если с разбором выражений, то зависит от того, умеешь ли в рекурсивный спуск. Если умеешь - зависит от того, насколько быстро печатаешь.
Синтаксически - это экмаскрипт+, семантически ближе к млю (автор - окамлщик), только мутабельность и rec везде по-дефолту. А, и ооп, которое тут вместо модулей.

>>767809
Именно с разбором выражений. Сейчас въеду в его макросистему.

>>767809
Что-то я ни хрена не понял. Как мне там запилить мой собственный синтаксис? Например, вот такое:

var x = 20 meters / (10 seconds + 20 minutes)

?

>>767701 (OP)
> хочу написать фреймворк для быстрого написания DSL
Джетбрейнс уже его написали:
https://github.com/JetBrains/MPS

>>767838
Макросы - это обычный хаксовый код (выполняется некой), только возвращает экспрешоны. То есть, из-под него можно читать файлы, срать в сокеты етц. Собственно, поддержки кастомного синтаксиса там нет, но ты можешь написать свой парсер, который будет возвращать хаксовое аст.
Если тебя смутило упоминание автокомплита, то ты его получишь просто потому, что им занимается сам компилятор - иде передаёт ему файл и позицию, а тот возвращает хмлку со всей информацией. Собственно, на твои кейворды он работать, скорее всего, не будет, но переменные, функции и прочие классы покажет.

>>767842
> но ты можешь написать свой парсер, который будет возвращать хаксовое аст.
> рекурсивный спуск
Спасиб, мил человек, только я и без Хакса могу рекурсивно-спусковой парсер написать! А с кастомным таргетом вообще непонятно, зачем тогда нужен Хаксовский фреймворк. Ради убогенькой системы типов и автокомплита?

>>767841
Я его в свое время тыкал, он мне показался чересчур многословным. Куча бойлерплейта даже для тупого калькулятора. Надо еще раз глянуть, может, изменилось что.

>>767701 (OP)
Одно слово: OMeta

>>767918
Смотрел. Искоробочный вариант левую рекурсию не разруливает. Вот в Agda можно задать что-нибудь типа "_$_::_" и присвоить ему приоритет, и где-нибудь в тексте можно будет писать так: "10 $ 20 :: 30". Я, правда, в душе не ебу, как они это делают.

>>767931
Ну и пили тогда на агде

>>767934
А генерацию кода как? У Агды там ад кокой-то.

>>767949
Никак, судя по твоим вопросам. Да и по ОП-посту тоже.
Генегировать человекочитаемый код из произвольного языка - задача ничуть не простая, а ты даже не представляешь, с какой стороны к ней подступиться.

>>767974
Да мне хотя бы нечеловекочитаемый код генерить. С минимумом бройлерплейта. Парсить-то я распаршу, генераторов парсеров уже как грязи.

http://www.tinlizzie.org/ometa/

>>768110
>>767931

>>767900
Спокойно, товарищ, не надо так нервничать. Просто по первому твоему посту складывается впечатление, что ты хочешь писать с нуля, вот я и посоветовал то, что уже имеет готовое аст, вывод+проверку типов, макросы, канпеляцию паттерн-матчинга, десять готовых таргетов и прочие мелочи. Почему-то мне показалось, что запилить это с чистого листа будет не быстрее, чем взять готовое.
Но вот прочитав последние твои посты, я вообще перестал понимать, что ты хочешь.

>>767701 (OP)
Твой фреймворк уже написан, называется Racket

>>768425
Сколько опечаток в слове sbcl

>>768809
В Лиспе, включая его имплементацию SBCL (не лучшую, хотя некие зачатки type inference хотя бы есть - у других и того нет) по сравнениюс с Racket нет для DSL вообще нихуя.
Начиная с того что макросы не являются объектами первого класса.

>>768820
>у других и того нет
А как же cmucl, ccl? А коммерческие реализации? Да даже у одной из самых ебанутых реализаций - у ecl - есть зачатки вывода типов. А что предлагает ракета?
>по сравнениюс с Racket нет для DSL вообще нихуя
Зато умеет в эффективный код. И предоставляет интерфейс к кодогенератору.
>Начиная с того что макросы не являются объектами первого класса.
В лиспе нет ничего, кроме специальных форм, что не является объектом первого класса.

>>768835
Ну почитай про Racket хоть что-нибудь, ну хоть http://racket-lang.blog.ru/214726099.html

Racket специально создан для того чтобы разные DSL, которые ты делаешь в процессе разработки, максимально удобно и корректно стыковались друг с другом, чего в Лиспе ты не получишь никогда.

Даже макросы в Лиспе убоги по сравнению с Racket, потому что defmacro на гигиенических макросах сделать тривиально, а наоборот - хуй.

Попробуй сделать на Лиспе правильный aif - тебе придётся написать полноценный парсер всего CL (с поддержкой макросов и таблиц чтения) с гигиеной (отслеживанием контекста) в стиле Scheme.

Из неустранимых недостатков Лиспа - продолжения и синтаксические объекты. Из трудно устранимых - стабильное окружение компиляции. В CL есть xcvb, но им мало кто пользуется. Теоретически гигиену может быть тоже можно прикрутить (перепердолив reader вдоль и поперек). Но тогда получится ракетка, но без продолжений. А зачем такая, если есть уже работающая с продолжениями

>>768865
>Racket специально создан для того чтобы разные DSL, которые ты делаешь в процессе разработки, максимально удобно и корректно стыковались друг с другом, чего в Лиспе ты не получишь никогда.
Да вы, ракетчики, те ещё сектанты, как я погляжу. Столько шуму из одних только продолжений и defmacro на стероидах с прикрученным к нему &env. Для начала бы хоть компилятор нормальный запилили.
>потому что defmacro на гигиенических макросах сделать тривиально, а наоборот - хуй.
Ага, единственное неоспоримое преимущество гигиенических макросов - возможность обойти гигиену. Так и запишем.
>Попробуй сделать на Лиспе правильный aif - тебе придётся написать полноценный парсер всего CL (с поддержкой макросов и таблиц чтения) с гигиеной (отслеживанием контекста) в стиле Scheme.
Ну, во-первых, парсер переписывать незачем, ибо один уже в рантайме есть. А во-вторых, aif — хороший пример макроса, требующего нарушения гигиены, но не наоборот, так что не очень понимаю что ты хотел донести.

>>768865
И да, статья улыбнула, но ничего про вывод типов в ракете я там не нашел.

>>768908
Вывод типов - в Typed Racket

https://docs.racket-lang.org/ts-guide/more.html#%28part._.Type_.Inference%29

>>768915
>Listof Integer
А в гетерогенные списки могёт? Ну и это, почему Integer не параметризированный как в cl?

>>768397
Я хочу писать компиляторы DSL быстро-быстро. В идеале исходник компилятора любого DSL (с макросами и выводом+проверкой типов) должен состоять из одного символа.

Еще желательно бы иметь интероперабельность генерируемых DSL с другими ЯП из коробки. Чтоб я такой пришел на работу, захуярил собственный компилятор и начал бы закрывать таски пачками, дергая из своего DSL-я быдлокод коллег.

Вариант с Haxe не очень подходит, потому что парсер мне все равно надо писать с нуля. Да, у Haxe есть компилятор сразу под несколько таргетов, но мне-то достаточно одного таргета. В итоге получается один хрен: а) что парсить DSL и генерить Haxe-код, потом генерить нужный код; б) что парсить DSL и генерить сразу нужный код.

Да, у Haxe есть вывод+проверка типов, но система типов у него какая-то слабенькая, экзистенциальные типы не поинкапсулировать.

Я тут ваш срач почитал и в итоге сам какой-то лисп напердолил на Руби. Не знаю зачем. Завтра отлажу и выложу.

>>768997
Исходник компилятора любого DSL не может состоять из одного символа. По той причине что спецификация этого DSL не может состоять из одного символа, если ты конечно не имеешь в виду любые DSL из множества DSL, выводящие на консоль один символ.

Вот из чего он может состоять - это из спецификации твоего DSL (плюс ноль лишних символов) на DSL для написания спецификаций DSL.

>>768997
>интероперабельность генерируемых DSL с другими ЯП из коробки
Причем сразу со всеми, вне зависимости от того какие у них ABI. Причем интероперабельность в обе стороны. И встраиваемость, тоже в обе стороны, сразу, чтоб два раза не ходить.
Это можно, приходи вечером на сеновал.

>>769021
This.
>>769022
Я, кажется, понял, в Haxe можно объявлять внешние классы. А проверка типов как? Хотя, в общем-то, на типы внешних классов похуй.

Бля, я в своем недолиспе запутался. Короче, перепишу все с нуля.

Вот такая хрень получается: https://spit.mixtape.moe/view/ce4e01cf .

Был, вроде, какой-то экспериментальный язык под дудку (дипломный проект какого-то студента), который позволял задавать синтаксис языка прямо в исходнике. Не помню, то ли на рсдн о нём писали, то ли ещё где. Может быть, тебе в его сторону посмотреть? Правда, там ебли не меньше будет, потому что он давно заброшен. Да и я не помню, как он назывался, поэтому его и найти-то непросто будет. Если только помнит кто.

>>769709
Nemerle

>>769709
Не просто писали, а главный админ сайта (Vlad) был одним из разработчиков. Фишка в том, что можно на таком языке писать DSL'и.

>>769709
> потому что он давно заброшен
Потому что индустрии не выгодно. Если у каждой компании будет свой синтаксис, то где брать индусов, которые все это знают?
Для рабовладельца главное требование к средствам разработки - чтобы в любое время можно было уволить зазнавшегося программистишку и тут же нанять нового.

>>769709
Katahdin? Смотрел. Несколько многословен (и нет макросов для макросов, как я понял) и таргетирован только на .NET.
>>769836
Кстати, котирую. Это такой доведенный до ума Katahdin. Вроде бы та же команда пилит N2, все хочу потыкать, что они там напилили.
>>769849
Все так, братишка, все так. Алсо, ни одна компания не разрабатывает DSL под свою предметную область (да хотя бы под то же крудошлепство), все трясут дерево, вместо того чтобы подумоть.

Как говорится - каждому воздастся по вере его. Если динамикогоспода сталкиваются с вавилонскими ограничениями когда половина кода уже написана, то статикобляди гаснут в своих собственных витийствованиях еще на этапе конпеляции.

Тред не читал. Про Red/Rebol уже вспоминали?

Короче, пацаны, я пришел к выводу, что мне нужна система генерации кода. Систем парсинга уже как грязи, а компайлер-компайлеров и того больше. А вот генерится выходной код либо методом генерации другого выходного кода, либо скриптопарашей общего назначения, на которой, по идее, уже конечный код надо писать.

>>771696
Про рантайм забыл. По сравнению с хорошим рантаймом система генерации это плюнуть и растереть.

>>771696
Lisp/Clojure

>>771700
Не понял. Я хочу генерить код для уже готового рантайма. Мне не компилятор нужен, а транслятор. Хочу написать такой:

GET '/catalogue/{tovar}.json' = SELECT * FROM tovars WHERE name = tovar

и получить сразу исходник RESTful плагина для JBoss на Java.

>>771945
Я сейчас примерно их и пилю, LOL.

>>772227
Мог бы и просто CDI с аннотациями для этого навалякать.

Выкинь Lisp и Clojure, возьми Racket.

>>772227
Ну и сделай макросом на кложуре. Зачем тебе ебля с трансляцией? Ты её всё равно не осилишь.

>>772227
Возьми за основу LinJ ( https://github.com/xach/linj ) - транслятор общелиспоподобного языка в человекочитаемую жабу. Навесишь макросов, добавишь по необходимости другие целевые языки и будет тебе счастье.

>>773896
>хочет получить исходник плагина для JBoss на Java
>в мета-языковом треде
>не знает про средства метапрограммирования в Java

http://www.slideshare.net/PolymathicCoder/the-art-of-metaprogramming-in-java

>>767701 (OP)
Любая нормальная контора пошлет тебя на хуй с твоими недоязычками.

Почему?

Потому что программирование - это индустрия, твой код должен быть поддерживаемым, чтобы после твоей скропостижной кончины от отравления несвежим борщем другой человек мог доделать недоделанное тобой.

Иди уроки учи, кароч.

>>773920
После того как Goldman Sachs успешно запилил себе Slang, все инвестбанки стали пилить свое, обычно на хаскеле. В том числе внутренние DSL.
Это по твоим понятиям конторы ненормальные, нормальные - это лухософт с епамом и джавапрограммирование за миску риса.

>>773906
Лохсофтофская джаваблядь, залогинься. И разлогинься, закрой вкладку с тредом. Мы здесь обсуждаем serious metaprogramming.

>>773982
> в
self-fix

>>773982
Но в Java есть средства метапрограмминга!

И она прекрасно подходит для микросервисов https://blog.buoyant.io/2016/06/17/small-memory-jvm-techniques-for-microservice-sidecars/

>>774015
Чот не нашел я там метапрограмминга. Элементарно макросы, например.

>>774015
>ява
>прекрасно подходит для чего либо
лолд, маня, твоя примитивная параша уже почти на свалке истории, ценится она разве что в сточной канаве мира, Индии, среди твоих сородичей и никаких средств, кроме набора бесконечного букваговна AbstractProxyFactoryMemoryBean она не представляет, так что лоллируй отсюда, чухан синеворотничковый

>>774025
Метапрограммеру, который jboss собрался в этом ITT треде метапрограммировать, этого будет вполне достаточно

>>774028
OK, вот тебе файл "MyPlugin.conf" с вот таким содержимым:

GET '/catalogue/{tovar}.json' = SELECT * FROM tovars WHERE name = tovar

Зделой мне на твоих аннотациях и прочих Javassist-ах из той презентации утильку, которая сгенерит сервлет для Glassfish. И чтоб в минимум LOC уложиться.

>>774453
> вот тебе
> Зделой мне
Куда ты готов выслать депозит?

>>774482
На Хабрахабр. Прямо в кармочку.

>>774636
Тогда не выйдет, я на нем не зарегистрирован.

Прочитал-таки еще раз про эту вашу OMeta, теперь уже более внимательно. LOL, я, оказывается, делал такие же штуки. Только я левую рекурсию не обрабатывал, и в описании синтаксиса у меня нельзя было делать паттерн-матчинг (это вообще исключительная фишка OMeta).

Понравился алгоритм разруливания левой рекурсии, но я не понял, как его применить для учета приоритетов и левой/правой ассоциативности. Поэтому изобрел свой. И нотацию тоже свою. Вот смотрите:

__expr =
____expr '+' expr [left-associative] /
____expr '-' expr [same priority] /
____expr '!' /
____num ;

Нельзя ставить два тега, то есть, "expr '->' expr [left-associative] [same priority]" будет ошибкой. Также нельзя указывать ассоциативность, если она не имеет смысла, например, для "expr '!'".

Теперь надо это все попробовать написать.

>>767701 (OP)
> Вот так вот устроиться разработчиком Java/C++/C#, сказать: "Мне плевать, на чем вы тут пишете" - и начать писать на своем ЯП, который будет компилироваться в Java/C++/C#.
И быть посланным нахуй.
Впрочем, ты сначала устройся на работу хоть кем-нибудь, а потом фантазируй.

>>771696
И систем генерации кода тоже дохуя. LLVM и GCC, например.

>>772227
> Мне не компилятор нужен, а транслятор.
Это одно и то же, школьник.

>>775400
Не, ну а что? Прихожу я такой в "Люксофт", а мне так сразу на стол толстенный томик - хадащ! - и говорят: "Вот тут 250 диалогов, надо их все реализовать". А я такой смотрю и вижу, что все диалоги там - сплошные таблицы, поля ввода да чекбоксы. И такой - хадащ! - быстренько, на коленке пишу свой DSL для описания формочек. И - хуяк-хуяк! - за неделю у меня уже весь том реализован.

А еще у меня когда-то давно была задача: есть описание протокола сервера на базе XML, нужно для всех запросов и ответов написать по классу и (де-)сериализацию к ним. Можно взять так - хадащ! - написать простенький транслятор из того XML, который в доке, скормить ему саму доку и - хадащ! - получить все классы с готовым сериализатором. Круто же!

>>775404
Что-то я тебя не понял. Если ты имеешь в виду, что это системы трансляции промежуточного кода (LOL, C - промежуточный код) в машинный код/байткод, то да. Но мне нужно генерить не машинный код, а исходник на другом языке.

>>775408
...поэтому я и назвал это транслятором, а не компилятором. Компиляторы у меня как-то ассоциируются с генерацией машинного кода.

>>775420
> есть описание протокола сервера на базе XML, нужно для всех запросов и ответов написать по классу и (де-)сериализацию к ним. Можно взять так - хадащ! - написать простенький транслятор из того XML, который в доке, скормить ему саму доку и - хадащ! - получить все классы с готовым сериализатором. Круто же!
Ты там SOAP решил переизобрести? Его уже давно реализовали, а потом отказались от него ибо сама идея говно.

Ты либо траллишь, либо у тебя дохуя фантази и абсолютно нулевой опыт.

>>775460
Это мои коллеги переизобрели. А мне надо было клиент напердолить под это дело.

>>775460
>отказались от него ибо сама идея говно
Наверное поэтому эту идею решили переизобрести под названием REST, только с квадратными колесами и изолентой

>>775420
Зачем тебе для таких простых задач DSLы пердолить? Туту каждая на 20 строк перла и полчаса.

>>775484
Внезапно, первое адекватное решение проблему за неделю тред!
Хотя я бы предложил использовать емакс вместо перла, всё-таки интерактивный инструмент удобнее.

>>775610
>за неделю существования треда

>>775610
Можно и Emacs если только себе одноразово нагенерить, перл проще когда нужно отчуждаемое решение - увидев в исходниках .el-скрипты, которым еще Emacs нужен, заказчик или коллеги удивятся и степень удивления может тебя не порадовать.

>>775627
Какие .el скрипты? Ты емакса в глаза не видел что ли?

>>775643
Емакс-лисповые. Которые ты напишешь.
Проспись иди.

>>775655
Никто не пишет "емакслисповских скриптов" для подобного рода задач. Сниппеты, клавиатурные макросы и куча других упрощающих жизнь инструментов, ну или вспомогательная одноразовая функция(и) в крайних случаях, которые за пределы буфера scratch не выходят для тех, кто емакса не видел: т.е. не сохраняются.

>>767701 (OP)
О, надо же, такая же проблема.
Только я разрабатываю игру на юнити в одно рыло спасибо маме за борщи, и я ебал делать это на ссаном сишарпе. Как говно вилкой чистить относится ко всей императивной ООП параше. Потом пересел на F#, но все равно как-то туго. Тут ко мне пришло озарение: надо быть ебаным дебилом, чтобы пытаться написать что-то сложнее хелловорда на языке общего назначения. Больше я в это говно не полезу.
Собственно, спроектировал в тетрадке довольно простой декларативный язык для описания поведения любой компьютерной игры. Причем фичи моего DSLа очень даже аккуратно ложатся на F# монадические (хуй знает как правильно. monadic, бля) корутины, functional reactive programming, etc. Но вот бойлерплейта просто дохуища. А всего-то ссаные макросы нужны. Чтобы я написал строку кода, а эта хуйня создала мне пару классов, раскидала код по методам и все такое. Кароч, хуй знает. Оно еще должно работать на дотнете и только на версиях ниже 3.5.
Сегодня прочекал JetBrains MPS. Охуенная штука, но мне не подходит, потому что, во-первых, я никак не могу использовать юнити апи в своем языке как бы могу, но это придется пилить заглушки под каждый используемый класс+метод из юнити апи, а во-вторых, я не нашел работающей реализации шарпа на mps, а значит придется пилить с нуля целый язык программирования + хуйня, специфичная для моего DSL. Очень много работы.
Завтра посмотрю что там с OMeta#, и если ничего хорошего с ним не выйдет, то наверное остановлюсь на IronScheme. Хотя с ним тоже не ясно.

Фух, высказался. Люблю /зк за это — ирл рассказывать все это некому, а тут можно. Даже если никто не прочитает/ответит, все равно легче.

>>775677
Если ты не пишешь, то не советуй этого другим.
Это в vim-загончике принято однострочники для ex хреначить чтоб клавиатура трещала.
В результате интерактивного скриптования задач и replования в буфере scratch, обозначенных в этом ITT треде родиться должен вменяемый, реюзаьельный скрипт на емакс-лиспе, с комментариями.
Чтобы его можно было использовать в дальнейшем а не дрочить каждый раз вприсядку наслаждаясь интерактивностями.

>>775680
И вместо гугла ты пришел именно сюда.
Необычный ход.

>>775682
> родиться должен вменяемый, реюзаьельный скрипт на емакс-лиспе, с комментариями.
Не должен. Если код разрастается до размера скрипта, то значит, ты делаешь что-то не то. Скорее всего, велосипедишь то, что и так уже давно реализовано и отлажено.

>>775684
А причем здесь гугл? У меня пока есть какой-никакой план:
>Завтра посмотрю что там с OMeta#, и если ничего хорошего с ним не выйдет, то наверное остановлюсь на IronScheme. Хотя с ним тоже не ясно.

А зашел я в основном высказаться, хули. Ну и просто удивился, что кто-то пришел к той же мысли примерно в это же время. Да и есть небольшая вероятность, что кто-нибудь что-нибудь предложит.

>>775685
Что блджад реализовано и отлажено? Кем? Недогенерация твоих конкретных фасолебинов из обрывков JSON?

Начинаю подозревать что распространенные городские легенды о ебанутых лисперах - не такие уж и легенды

>>775692
>Что блджад реализовано и отлажено?
Средства написания кода, блджад. Читать не умеешь что ли?
>Кем?
Людьми, очевидно.
>Недогенерация твоих конкретных фасолебинов из обрывков JSON?
Каких жсонов? Что за хуйню несёшь? То ли ты меня не понимаешь, то ли я тебя не понял.
Я тебе предлагаю сразу конечный код писать, пользуясь средствами редактора, которые позволяют свести телодвижения на минимум, вместо того, чтобы изобретать дсл, пилить кодогенератор, отлаживать его, а потом ещё и вручную перекладывать спецификацию на этот дсл и в итоге получить неподдерживаемую кодогенеренку.

>>775680
Одно слово: Nemerle

>>775420
>Вот тут 250 диалогов, надо их все реализовать
Аштиэмэль.
>написать простенький транслятор из того XML, который в доке, скормить ему саму доку и - хадащ! - получить все классы с готовым сериализатором
Делается на макросах за вечер.
Поскольку твои задачи отличаются от создания жаваскриптов с нескучным синтаксисом, то у тебя нихуя не получится. Точнее, идеальный вариант работать не будет в ближайшие лет пятьдесят. Дело в том, что твои деревья парсинга будут нифига не типовые, и твой охуенный декларативный язык надо будет руками переводить (и править баги) в целевой язык, что может той ещё задачкой оказаться.

>>775717
>>770665

>>775721
> Аштиэмэль.
Instant nahuy.
> Делается на макросах за вечер.
Что это за волшебные макросы такие? Нет, оно действительно делается за вечер, но на макросах?.. Алсо, хочу за час.
> Точнее, идеальный вариант работать не будет в ближайшие лет пятьдесят.
Как будто языки общего назначения работают или идеальны. Я же не собираюсь писать совсем идеальный язык, чтобы написать его и все, индустрия языкостроения закрылась. Нет. Я просто хочу упростить это самое языкостроение. И я уверен, что мне это удастся. Например, путем создания языка не общего назначения, а DSL для обработки и трансляции синтаксических деревьев.

>>775727
>Instant nahuy.
Какая разница, на чём формочки описывать? Если только ты с файнридером поебёшься сначал, то можно будет подумать, а так тебе их все 250 руками писать всё равно. А хтмл под это уже заточен.
>Что это за волшебные макросы такие?
Да любые нормальные, т.е. которые не цэпрепроцессор и не крестошаблоны (уверен, на шаблонах можно, но вечер этот растянется на пару лет). Вот в хаксе да, я знаю, что всех заебал уже им - ничего не поделать можно дёрнуть хмл парсер из макроса и потом хоть загенерируйся своими классами. Кстати, поэтому я считаю, что он имеет потенциал стать вторым оружием интырпрайза, потому что в жабке то же самое сейчас делается в рантайме и без типизации.

>>775717
Неплохо, сейчас прочекаю?

>>775899
зачем я поставил знак вопроса

>>775483
REST дружелюбен к HTTP протоколу, если что. Учитывает какие запросы идемпотенты и прочее.

>>775754
> Какая разница, на чём формочки описывать?
Я немного расширю INTERCAL, а ты мне давай напиши на нем формочки.
> А хтмл под это уже заточен.
Толсто.
> Вот в хаксе можно дёрнуть хмл парсер из макроса и потом хоть загенерируйся своими классами.
То есть, по сути, самому пердолить DOM, так? Извините, я так и в Пердле умею, и средства пердолинга там по-мощнее будут.

>>776061
Смешали в кучу коней и людей и все уровни протоколов. Дошли до HTTP's content types are a type system. Забыли про все ломающее по пути, начиная с кривых CDNов.
Велосипед с квадратными колесами.
Даже Фейсбук уже заебался и не выдержал
> We believe there are a number of weakness in typical REST systems, ones that are particularly problematic in mobile applications:
> Fetching complicated object graphs require multiple round trips between the client and server to render single views. For mobile applications operating in variable network conditions, these multiple roundtrips are highly undesirable.
> Invariably fields and additional data are added to REST endpoints as the system requirements change. However, old clients also receive this additional data as well, because the data fetching specification is encoded on the server rather than the client. As result, these payloads tend to grow over time for all clients. When this becomes a problem for a system, one solution is to overlay a versioning system onto the REST endpoints. Versioning also complicates a server, and results in code duplication, spaghetti code, or a sophisticated, hand-rolled infrastructure to manage it. Another solution to limit over-fetching is to provide multiple views – such as “compact” vs “full” – of the same REST endpoint, however this coarse granularity often does not offer adequate flexibility.
> REST endpoints are usually weakly-typed and lack machine-readable metadata. While there is much debate about the merits of strong- versus weak-typing in distributed systems, we believe in strong typing because of the correctness guarantees and tooling opportunities it provides. Developers deal with systems that lack this metadata by inspecting frequently out-of-date documentation and then writing code against the documentation.
> Many of these attributes are linked to the fact that “REST is intended for long-lived network-based applications that span multiple organizations” according to its inventor. This is not a requirement for APIs that serve a client app built within the same organization.
> https://facebook.github.io/react/blog/2015/05/01/graphql-introduction.html

>>776632
>Я немного расширю INTERCAL
На мейнфреймовом COBOL с embedded SQL очень удобно было.

>>767809
>Местами довольно близко к написанному коду получается.
Код простенького 2д-движка на haxe состоял из 3к-строк на js-е, нахуй нахуй.
Идея ок, реализация не ок.

>>776632
>Толсто.
Вот теперь я снова не понимаю, чего ты хочешь. Ну не будет так, чтобы нажал кнопку, а оно сделалось заебись. Тебе один хуй писать все эти формочки руками (или шлёпать мышкой). Хтмл даёт тебе стандартное описание с интерактивным редактированием (в том числе и ВИЗИВИГ мышкой), которое при желании потом можно пропарсить каким-нибудь хмл парсером и сгенерировать по нему всё, что угодно, под какой угодно язык; но нет, ты, похоже, еблю в жопу ценишь больше сделанной полезной работы.
Это как синдром одного языка программирования - когда человек нихуя не знает, кроме своих крестов (жабаскрипта/пистона/етц) и, поэтому, тащит их везде, куда только можно запихать, даже если не лезет - только с немного другим знаком. Используй готовые инструменты, которые тебе дали.
>>776654
Там довольно много строк уходит на то, чтобы обойти подводные камни жабаскрипта. Вообще, это смотреть надо. Рейтрейсер на хаксе был больше по сгенерированному исходнику, чем тайпскриптовский, но и работал в два раза быстрее.

>>776642
Вот видишь? Значит, есть разница, на чем формочки писать.

>>776717
Блин, я думал, ты траллируешь, а ты и правда дурак.
> HTML
> заточен под формочки
> HTML
> заточен под формочки
Он заточен под них так же, как печатная машинка под управление станком с ЧПУ. Если уж и брать для описания формочек что-то SGML-еподобное, то тогда уж QML или XAML, но уж никак не многословный LATEX без макросов.

Ну, давай разберем конкретный пример. Вот я пришел такой, а мне показывают код на Java+Swing. И говорят, мол, вот тут у нас уже есть 1000 формочек с кодом вида:

JPanel p = new JPanel();
JButton b = new JButton("OK");
p.add(b);

- и вот надо написать еще 250 формочек с портянками такого же вида.

Но я же не долбоеб, чтобы вручную все эти портянки набивать. Я быстренько, за часик пишу парсер DSL на своей гипотетической системе и потом пишу что-нибудь вида:

Panel[Button["OK"]]

Или, как ты предложил, прогоняю выданную мне доку через FineReader и получаю ASCII-арт вида:

__________________
_Param1__[______]__
_Param2__[______]__
__________________
_____[OK]_[Cancel]__

Потом пишу под это дело парсер, который этот ASCII-арт преобразовывает в код и... Ну, ты понял. Еще можно попросить заказчика нарисовать формочки в каком-нибудь Visio и экспортнуть в нужный мне формат, но это уже манямечты.

>>776805
>QML или XAML
SXML от Олега.

>>776641
GraphQL довольно сильно отличается от SOAP, не находишь?

>>777026
Конечно отличается. Раз уж выяснилось что REST нихуя не работает (из-за квадратных колес и изоленты не в последнюю очередь ЧСХ), можно в третьем переизобретении SOAP что-то и добавить полезного.

А вот REST не отличается ничем кроме квадратных колес и обмотки изолентой.

>>777026
>>777071
Посоны, поясните за SOAP/REST/GraphQL. Я вроде бы всё про них знаю, но мне кажется что ничего не знаю. SOAP был на XML, и из-за сложности и многословности формата был вытеснен рестом, чтобы эффективнее использовать HTTP запросы. Графкул помимо выборки определённых полей вместо всего-сразу, даёт ещё возможность делать произвольные джойны (чем кстати можно вешать серваки), позволяя перейти от документации отдельных запросов к диаграмме моделей. Всё время меня мучает недосказанность, так как я не особенно погружался в работу с каждым из них, если ли тут кто непосредственно и основательно трогал все три протокола? Что скажете?

>>777105
Единственный и главный смысл GraphQL хорошо выражен в известном стихотворении Валентина Дмитриевича Берестова (читать с выражением, от лица фронтенд-разработчика, глядя в сторону ненавистных бэкендеров и DBA)

Как хорошо уметь читать!
Не надо к маме приставать,
Не надо бабушку трясти:
«Прочти, пожалуйста, прочти!»
Не надо умолять сестрицу:
«Ну прочитай еще страницу!»
Не надо звать,
Не надо ждать,
А можно взять
И почитать!

>>777071
GraphQL - это не переизобретение SOAP. В них совершенно разные идеи.
SOAP - ООП, RPC, прокси и прочая хуйня.
GraphQL - примерно как отправлять запросы в базу сразу с клиента.

>>777415
GraphQL - это (второе уже) переизобретение SOAP с кривым языком запросов поверх него, я ведь так и написал.
Ты вчитайся в те места где про REST.

RPC будет на следующем шаге, подожди, они обязательно переизобретут CORBA. Конечно, с квадратными колесами и изолентой.

>>777448
Что общего между GraphQL и SOAP?

>>777468
Почти всё. Проще перечислить отличия

> GraphQL is a protocol that replaces REST.

> Its closest analogue is the unholy beast that is SOAP + WSDL, except without the insanity of XML. With SOAP/WSDL you declare a schema for your API, which then accepts API calls containing parameters. SOAP/WSDL follows a classical RPC paradigm where you execute functions that take positional arguments.

> GraphQL dispenses with that terminology, but is still very much RPCish. A key difference is that "arguments" are keyword-based. Where SOAP/WSDL would have you pass a "complex type" (ie., a struct) with optional fields, in GraphQL everything is built out of structs. Another key difference is that the output follows the structure of the input.

>>776805
Парсер-то ты за пару часиков мож и напишешь, но на кодогенератор у тебя потребуется намного больше времени.
Как ты, например, по аскиарту собираешься выбирать способ упаковки (таблица, вертикальные/горизонтальные контейнеры или ещё что), свойства упаковки (отступы, растягивать/не растягивать, заполнять/не заполнять и сотни других)? А ведь ещё есть свойства компонентов, часть которых задаётся в конструкторе, часть простыми сеттерами (вроде setEnabled(bool)), часть сеттерами похитрее (что-нибудь вроде setProp(PROP_NAME, PROP1 | PROP2) или ещё какими-то).
В общем, создание отображений систем с одной идиоматикой на другую не такая тривиальная задача, как тебе, молодому-горячему и неопытному, кажется.

>>776805
>XAML
>не хочу xml, лучше возьму xml
форман.пнг
>Ну, давай разберем конкретный пример
ещё_один_форман.пнг
Это говно, а не пример. Тут вообще нихуя делать не надо - возьми свой любимый перл, создай в нём массив ['Panel', 'Button', 'OK', ...] и генерируй до посинения. Давай лучше рассмотрим более другой пример, когда у тебя на форме по пятьдесят контролов, и одни могут растягиваться, другие имеют фиксированный размер, третьи могут растягиваться, но не больше определённого размера, а четвёртые могут, но только по вертикали. И всё это не должно ехать. А ещё а ещё контролы могут иметь разные интересные стейты. Тут, конечно, лучше будет взять шарп, а потом по исходникам пройтись хоть теми же регэкспами, но это ничего не отменяет.
>Потом пишу под это дело парсер, который этот ASCII-арт преобразовывает в код и...
Ок, заебись. И что? Парсер-то тебе с нуля писать. И генератор тебе с нуля писать. И эта штука и состоит-то из одних лишь парсера и генератора. И хуй его ещё знает, быстрее ли и проще ли это будет. И это одноразовая хрень, потому что потом тебе принесут другое задание с другими формочками, которые этот парсер не распарсит.
А вообще, иди лучше Red допиливай. Судя по всему, близко к тому, что тебе надо, и хоть какая-то польза будет.

>>777708
>возьми свой любимый перл, создай в нём массив ['Panel', 'Button', 'OK', ...] и генерируй до посинения.
Или вобще обойдись sed, awk и M4. Если эти формочки никому не нужны и после генерации все они сразу поедут в мусорную корзину.

> Давай лучше рассмотрим более другой пример
Когда они все-таки кому-то нужны. И тогда все верно, они все будут разными. И разными по такому количеству параметров и мелких, но важных отличий, которые формализовывать и писать их спецификацию дольше примерно в 10 раз чем их закодировать прямо вот руками каждую, как бы это не звучало ужасно для здешнего метапрограммистического долбоеба.

> А ещё а ещё контролы могут иметь разные интересные стейты
Они столько всего будут разного иметь, если их нормально делать - закачаешься. От разной валидации одного и того же поля в разных формах до разного отображения (и неотображения) одного и того же поля в разных формах.

Если включить голову и подумать для кого эти формы, какой смысл каждая из них несет в бизнес-процессе пользователя, работающего с программой, какие разные пользователи разных ролей будут вбивать это сюда, а то - туда. Для каковой задачи метапрограммистическому долбоебу это все и поручали, и именно за этим давали месяц на эти формочки.
Но обо всей этой "ненужной хуйне" (такой как решение задачи) он думать не хочет, а хочет он думать только о том какой бы парсер и генератор ему применить.
В результате услышав слово "метапрограммирование" любой наученный горьким опытом (лично или из общения с коллегами) общения с метапрограммистическими долбоебами нащальника или senior developer приходит в ярость, и тянется за шваброй.
И его можно понять. На одного адекватного разработчика, применяющего метапрограммирование разумно, приходится десяток метапрограммистических долбоебов.

>>767701 (OP)
А почему кружка в бублик не превращается?

>>777744
Топологически она уже и есть бублик.

>>777715
OK, приведите примеры метапрограммирования, примененного разумно.

>>778004
Clojure's Core Library

>>778696
То есть, метапрограммирование нинужно. Так и запишем.

>>778805
По делу есть что ответить или тебе лишь бы спиздануть чего?

>>778696
Хоть бы core.async назвал тогда.
В core макросы скорее для определения синтаксиса и всякого сахара. Можно было всё и на фукнциях сделать.

>>778004
Чтобы привести примеры метапрограммирования, примененного разумно, нужно достаточно подробно описать условия, в которых оно было применено, это делать всем будет лень.
Это относится к любым подходам, приемам, техникам и концепциям, а также инструментам.
Разумное применение - это уместность. Для этого надо понимать и взвешивать все минусы от применения и все плюсы.
Для этого надо думать головой.

>>778847
Не разруливает левую рекурсию.

>>778004
Выше было. Разумно - это когда программа за тебя делает работу, и от тебя на это ушли минимальные усилия. Нагенерить строчек скриптом из массива ['Panel', 'Button', 'OK', ...] - разумно, пердолиться для этого с дслем - нет.

>>779263
Принимать в расчет только количество усилий методологически неверно. Из таких ошибок в оценке разумности получаются, например, сумасшедшие лисперы, потому что в лиспе усилий уйдет очень мало.

>>774026
AbstractProxyFactoryMemoryBean ob;

>>779344
По-подробнее, плес. Ты имеешь в виду поддержку?

>>779425
Нет, ты. Задай в этом твоем parboiled2 вот такое:

def Expr: Rule1[Int] = rule { Expr ~ '+' ~Expr | Number }