Действительно появится. Я почитал документацию, если все правильно понял — переменные нельзя реиспользовать в паттерне. Пичаль везде.
Это, конечно, хорошо, но я бы предпочел вводить абстракции, когда мне нужно, а не когда размер паттерна выходит за грань разумного. Ну и да, если бы все было так просто… Я сейчас развлекаюсь с MPEGTS, там такие упакованные структурки, что паттерн на 8 полей по binary получается запросто, и как его разинлайнить — тоже не очень понятно.
Вообще, конечно, это все bias. Мне очень хочется иметь более гибкий и изящный язык под BEAM, чем Erlang — но только язык, без дополнительных наворотов. Чтобы добавил компилятор в конфиг rebar-а, и пользуешься, смешивая его с эрлангом в любой пропорции. Два более-менее живых проекта — lfe и elixir, и ни один моим требованиям как-то не соответствует. Хоть свой лисп пиши, очень печально.
Вообще, я зачем-то смешал теплое с мягким… Влияние CL — это было скорее про verbosity имен, что я тоже не одобряю, но с этим еще моно жить.
А вот с verbosity паттернв все гораздо хуже. На данный момент описание паттернов в lfe просто чудовищно многословны и нет никакой возможности их сократить хотя бы до уровня erlang-а.
Erlang LFE
[H | T] (cons H T)
{A, B} (tuple a b)
<<A:5, B:A/binary>> (binary (a (size 5)) (b binary (size a))
Я не уверен, что последний пример заработает, но суть, надеюсь, ясна.
То есть, если я начну писать на lfe вместо erlang, мой код точно не станет короче. Станет ли понятнее — сложный вопрос, но лично меня полноценные выражения вместо специального синтаксиса скорее отвлекают.
Вероятно, если бы была поддержка reader macro, я бы смог заменить это на какой-то компактный спецсинтаксис(да хоть бы оригинальный эрланговский), но ее сейчас нет, а что в этом случае можно поделать обычными макросами — я даже не знаю.
Не, не поймите неправильно, я подумывал продолжить про низкоуровневость и семантику. Но потом вспомнил, что не разговариваю с фанатиками, сказал, что хотел и ушел заниматься делом.
Вообще, мне не хочется вас расстраивать, но Оберон никому особо не нужен и забыт. На данный момент, мне кажется, вполне заслуженно. У нас уже есть куча отличных языков высокого уровня на любой вкус, под любую задачу и любую платформу.
Это не я сказал. Но оценивать откровенно низкоуровневый язык не имея с опыта работы с подобными — верный путь к фэйлу. Да и оценивать язык по синтаксису — паршивая идея.
Вообще говоря, связка cljs+core.async+datascript(написанный на cljs client-side datomic)+react(rum, reagent, sablono, тыщи их) наиболее похожа на серебрянную пулю среди всего нынешнего фронтенда.
Ну, про пристойность это была по большей части шутка.
А шрифты просто никогда не будут выглядеть одинаково с отрендеренными нативно, что очевидно плохо. В буквальном смысле очевидно.
То есть, я, конечно, понимаю, автора freetype-go — писать свой truetype renderer интереснее, чем биндинги к системному. А вот тех, кто это использует не в игровом движке — нет.
Знаете, я вот посмотрел в зависимости, там freetype-go. Который самописный, с нуля, не биндинг к системному рендереру. То есть, приложения на gxui вообще никогда не будут выглядеть нативно и хоть чуть-чуть пристойно.
Для меня было открытием, что оказывается, это цикл Дейкстры.
Это, конечно, хорошо, но я бы предпочел вводить абстракции, когда мне нужно, а не когда размер паттерна выходит за грань разумного. Ну и да, если бы все было так просто… Я сейчас развлекаюсь с MPEGTS, там такие упакованные структурки, что паттерн на 8 полей по binary получается запросто, и как его разинлайнить — тоже не очень понятно.
Вообще, конечно, это все bias. Мне очень хочется иметь более гибкий и изящный язык под BEAM, чем Erlang — но только язык, без дополнительных наворотов. Чтобы добавил компилятор в конфиг rebar-а, и пользуешься, смешивая его с эрлангом в любой пропорции. Два более-менее живых проекта — lfe и elixir, и ни один моим требованиям как-то не соответствует. Хоть свой лисп пиши, очень печально.
А вот с verbosity паттернв все гораздо хуже. На данный момент описание паттернов в lfe просто чудовищно многословны и нет никакой возможности их сократить хотя бы до уровня erlang-а.
Я не уверен, что последний пример заработает, но суть, надеюсь, ясна.
То есть, если я начну писать на lfe вместо erlang, мой код точно не станет короче. Станет ли понятнее — сложный вопрос, но лично меня полноценные выражения вместо специального синтаксиса скорее отвлекают.
Вероятно, если бы была поддержка reader macro, я бы смог заменить это на какой-то компактный спецсинтаксис(да хоть бы оригинальный эрланговский), но ее сейчас нет, а что в этом случае можно поделать обычными макросами — я даже не знаю.
Я лучше пойду упаковку HLS timed metadata для erlyvideo дописывать.
А правы, скорей всего, авторы Rust-a, которые делают хороший, годный язык для людей, которые годами писали на C/C++.
А шрифты просто никогда не будут выглядеть одинаково с отрендеренными нативно, что очевидно плохо. В буквальном смысле очевидно.
То есть, я, конечно, понимаю, автора freetype-go — писать свой truetype renderer интереснее, чем биндинги к системному. А вот тех, кто это использует не в игровом движке — нет.
и хоть чуть-чуть пристойно.mmBBQ круче, даром что более общего назначения. Ну и да, там прекрасный LuaJIT с его нечеловечески прекрасным FFI.