LINUX.ORG.RU

Metaprog: универсальная графическая среда программирования [в разработке] часть 5

 , ,

Ответ на: комментарий от iluha16

прохфессора мамка из-за комплюктера выгнала. И провод отобрала. Вон сидит с телефончика под анонимчиком.

anonymous ()
Ответ на: комментарий от anonymous

У него просто дебьян (вроде) в кернелпаник свалился. И все исходники самоуничтожились. А пароль от аккаунта, разумеется, мегамозг запомнить ниасилил.

rebforce ()
Ответ на: комментарий от anonymous

Зато с птичками... отдыхать - всегда пожалуйста

птичку_жалко.jpg

rebforce ()

А что там с циклами? Уже 2 недели прошло как автор взялся рисовать циклы и как-то все нет. А еще же условия, алгоритмы всякие...То есть если тратить по 2 недели на такую базовую и простую вещь, то до альфы, или чего-то близко похожего, можно и вообще не дожить.

ossa ()
Ответ на: комментарий от rebforce

о, точно: bytebeat. тут более развёрнуто. а то сначала на ютубе наткнулся.

anonymous ()
Ответ на: комментарий от ossa

как интересно. помнится решил запилить простенький интерпретатор и накидал за одну ночь и вот как раз на циклах всё застопорилось. уже не помню чего там не получалось.

iluha16 ()
Ответ на: комментарий от iluha16

Лолшто? Циклы — всего лишь синтаксический сахар над условными переходами. То есть если переменные в каком-то виде есть и flow control в виде, образно говоря, if и goto (ну или call/ret) работает, значит, циклы тоже должны.

rebforce ()
Ответ на: комментарий от rebforce

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

iluha16 ()
Ответ на: комментарий от iluha16

и до сегодняшних дней не сохранился

Жаль, можно было бы разобраться с циклами (думаю, с адресным стеком проблема решилась бы на раз) и запилить принципиально новый ЯП поюзабельнее метахрени.

rebforce ()
Ответ на: комментарий от rebforce

ну это для тебя всё очевидно. а автор школьник при чём очевидно даже не старшеклассник и про адресный стэк знает разве что поверхностно. проблема усугубляется нежеланием автора что либо учить и читать в текстовом виде.

iluha16 ()
Ответ на: комментарий от rebforce

запилить принципиально новый ЯП поюзабельнее метахрени.

Реквестирую графический чистый ФП без сборщика мусора, но при этом память-безопасный a-la Rust, если проект будет хотя бы начат, я с радостью присоединюсь.

(После того, как разгребу время для опен-сорца)

balsoft ()
Последнее исправление: balsoft (всего исправлений: 1)
Ответ на: комментарий от balsoft

Ты какого-то мутанта хочешь. Это вообще законно? Чистый ФП без сборщика... Одно это трудно представить.

anonymous ()
Ответ на: комментарий от rebforce

Рабочий день у рабов командировочных, я человек сободный.

А я в любой момент могу выйти к нашему озеру и снять пруф с таймштампом.

Еще похвались тем что лужи можешь пофоткать, я же написал, озеро красивое и в заповеднике.

VarfolomeyKote4ka ()
Ответ на: комментарий от iluha16

Вангую что загвоздка была в том что ты не сделал стек для адресов возврата, и юзался последний объявленный цикл.

VarfolomeyKote4ka ()
Ответ на: комментарий от VarfolomeyKote4ka

так это реально ты писал. а я думал анонимаусы прикалываются.

iluha16 ()
Ответ на: комментарий от anonymous

Да, академики вроде бы попиливают нечто похожее. На данный момент GC – это самая большая проблема всех ФП языков, её нужно решать. В конце концов, структуры данных в ФП иммутабельны (по крайней мере для программиста), а время жизни для них чаще всего строго определено контекстом, остается только наладить ручное определение времен жизни для случаев, когда вывести невозможно, ну и всякие полуавтоматические RC для случаев, когда и этого недостаточно.

balsoft ()
Последнее исправление: balsoft (всего исправлений: 1)
Ответ на: комментарий от balsoft

https://github.com/melsman/mlkit

Вот о чем я говорю, и да, там есть куча проблем, но в целом если бы на эту штуку обратили внимание, то они бы решились. Дело в том, что сообщество забило на проблемы GC, и поэтому теперь пожинаем плоды в виде гигабайтов памяти при запуске серьезных проектов.

balsoft ()
Ответ на: комментарий от balsoft

не знаю, как типизированный ФП-чистый типа ML, но лисп на расте уже запилили:

mal-rust поцмортем — это 'make yourself a Lisp на 10500 языках' mal (алсо

ещё есть такие лиспы на ржавчине: JunSuzukiJapan/macro-lisp murarth/ketos «чисто функциональный» etaoins/arret risp описалово rust-elisp

ещё был какой-то с макросами раста и японскими иероглифами. сейчас сходу не вспомню.

типа как в InteLib от А. Столярова, где лисп в С++ транслировался. только тут в раст.

вообще «чисто функциональный» некий DSL (или полноценный недоязычок) на расте с zero-cost abstractions и без GC где не недо — было бы интересно.

anonymous ()
Ответ на: комментарий от balsoft

Region-Based

ага, интересно. и что, прям лайфтаймы раста можно выводить из/в регионов или это ортогонально?

anonymous ()
Ответ на: комментарий от VarfolomeyKote4ka

А, так это таки ты, неуч? Птички хоть живы остались после твоего «отдыха»?

rebforce ()
Ответ на: комментарий от balsoft

Чистый не всегда удобно, но идея понятна. Ну на крайняк можно юзать только «чистое» подмножество, в котором всё на выражениях построено будет.

Вообще таки надо подумать. Мне щас немного не до того, может, ув. тов. Артурианец к идеям прислушается.

rebforce ()
Ответ на: комментарий от balsoft

Functional Geometry на elixir (+ссылки на реализации Lisp F# Haskell Python) и на Java (проще на C++/Qt портировать)

про «алгебру картинок» и их функционально чистую композицию

anonymous ()
Ответ на: комментарий от anonymous

на CL (можно переписать на расто-лисп-гтк, и добавить своих УГО)

anonymous ()
Ответ на: комментарий от balsoft

чистый ФП без сборщика мусора, но при этом память-безопасный

Вообще у меня были мысли запилить что-то похожее с двумя таргетами:

  1. CHIP-8 (каноническая реализация, принципиально новая VM моего авторства под которую уже готова);
  2. JS/ES6 не слишком нового образца, а именно уровня Gecko 48 (почему так — долго объяснять, но это связано с одним моим мобильным опус-магнумом).

Кстати, очевидно, что если ФП-рантайм без GC будет вменяемо компилироваться и работать в виртуалке CHIP-8 первой спецификации, то на JS он будет лётать аж бегом. По эзотерическим рантаймам определённый опыт трёхлетней давности имеется. Штука полезная, чисто для души.

rebforce ()
Ответ на: комментарий от rebforce

Что ж, раз «Антиметапрога» на реде мы не дождемся, ждем на CHIP-8 (кстати, что это?) или джаваскрипте.

metaprog ()
Ответ на: комментарий от metaprog

Не на CHIP-8, а с возможностью компиляции под CHIP-8.

Пипец, это же академический образец архитектуры виртуальной машины, который даже на плееры типа Sansa Clip портирован. Стыдно такую классику не знать.

rebforce ()
Ответ на: комментарий от metaprog

Ты почти в каждом сообщении напоминаешь о том, что «Антиметапрог» не готов и вообще мы его не дождемся. Как мне кажется, это свидетельствует лишь о том, что у тебя с твоим метапрогом полная жопа, и релиза не будет, что в принципе было вполне ожидаемо.

anonymous ()
Ответ на: комментарий от anonymous

Та да. Такое ощущение, что его цель вовсе не в написании чего-то своего заключается.

Если бы он хотя бы попытался 100501-ю реализацию той же виртуалки CHIP-8 (базовый сет, без суперчипов и мегачипов) запилить чисто для себя (пусть даже на том же грёбаном лабвью, хотя лично я это слабо себе представляю) и добился бы успешного запуска на ней хотя бы того же Astrododge (самая попсовая игруха под эту платформу из более-менее современных), это бы мозг ой как вправило. И в процессе большинство возникающих вопросов прояснились бы настолько, что и разработка метапрога пошла бы куда бодрее. Но это не путь демагога, понимаешь?

rebforce ()
Ответ на: комментарий от anonymous

Никто не говорил про отмену разработки Метапрога (в отличие от «Антиметапрога», концепт которого был обещан за неделю). Она идет, просто с циклами проблем больше, чем думалось. Но, думаю, за несколько дней они решатся и циклы будут. Опять же, «думаю» не означает «обещаю».

И, все же, хотелось бы увидеть «антиметапрог» на джаваскрипте. Стоп, что-то такое уже есть, уже выше показывали NoFlo. Но, все же, оно чуть-чуть не то, что надо. Хотя, если б не было Лабвью, то, возможно, пилил бы Метапрог на нем. Самая симпатичная из показанных в темах систем после Лабвью и MyOpenLab.

metaprog ()
Ответ на: комментарий от metaprog

Это что ж за рахитектура там у тебя, что с циклами, которые по сути являются синтаксическим сахаром для условных переходов, такие затыки на несколько дней?

rebforce ()
Ответ на: комментарий от rebforce

Я подожду, я терпеливый. Ну и очень уж меня интересует тема ФП без GC.

balsoft ()
Ответ на: комментарий от balsoft

Реквестирую графический чистый ФП без сборщика мусора, но при этом память-безопасный a-la Rust, если проект будет хотя бы начат, я с радостью присоединюсь.

Гугли про interaction nets. Например, есть пейпер Visual Programming with Recursion Patterns in Interaction Nets. Или вот Interaction nets: programming language design and implementation, который начинается словами

Interaction nets are a graphical—visual—programming language.

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

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

Индустрии плевать на перспективные разработки, рынок диктует свои условия, приходится подстраиваться под потребителя. Программист привык к императивной парадигме? Поддержим! Невыровненный доступ к памяти? Обеспечим! Программа сегфолтится? Виноват гтк, линукс, интел, да кто угодно, но точно не автор! Дегенерат не может понять смысла написанного? Проблема в письменности!

Laz ★★★★ ()
Ответ на: комментарий от Laz

В курсе.

Вообще-то говоря мне они не очень нравятся – они мне напоминают клеточные автоматы, где данные и инструкции слиты воедино в неразличимое месиво. Идея лабвью, где данные «текут» по инструкциям мне нравится гораздо больше, ибо она ближе к тому, как лично я воспринимаю программирование на функциональных языках – потоки данных через функции.

И можешь подробнее насчет

автоматически решаются проблемы ленивости/энергичности, сборка мусора становится явной

Если с жадностью/ленивостью я могу себе представить, о чем речь, то вот про явную сборку мусора я вообще не понял.

balsoft ()
Ответ на: комментарий от rebforce

Запилить новый ЯП? Ещё и функциональный? Я пас. Максимум, на что меня хватит - трансляция в готовый ЯП или примитивнейший диалект лиспа. + для меня фп - «замечательно в некоторых ситуациях», но всю программу в функциональной парадигме - не для меня.

По поводу избавления от GC я дилетант, но в голову приходит move semantics из C++, но так, чтобы компилятор сам выводил в простых случаях когда «передавать владение данными» функции. Также неплохо бы сделать reference counting, только не в рантайме, как в С++, а на этапе компиляции, без оверхеда в рантайме. А вот кеширование результатов вызова чистых функций я без понятия как сделать без GC и при этом надёжно.

А вот визуальное построение графов (и деревьев) передачи данных между функциями очень поможет вручную наглядно определить «вот в этой функции можно делать free() такого-то аргумента» и таким образом дебажить алгоритмы «когда надо освобождать память?».

arturianec100 ()
Ответ на: комментарий от arturianec100

Также неплохо бы сделать reference counting, только не в рантайме, как в С++, а на этапе компиляции, без оверхеда в рантайме

Reference counting на этапе компиляции – это lifetimes, суть RC как раз в том, что оно обязано быть в рантайме.

кеширование результатов вызова чистых функций я без понятия как сделать без GC и при этом надёжно.

Точно так же, как и хранение любых других произвольных данных.

Максимум, на что меня хватит - трансляция в готовый ЯП

Трансляции в Rust вполне хватит для нишевого язычка.

balsoft ()
Ответ на: комментарий от Laz

Мне скрины interaction nets не понравились тем, что черно-белые. Цвет в Метарпоге и Лабвью в основном для типов данных. А какие где типы данных в interaction nets? Или там типов как таковых нету?

metaprog ()
Ответ на: комментарий от arturianec100

Ну я лично, как и ТС, далёк от высоких материй, но, будучи сторонником простых решений, к вопросу могу подойти с другой стороны:

  1. С точки зрения VM существует только джва типа данных - byte (байт) и parcel (всё остальное размером больше байта - строки, флоаты, ссылки на другие функции и т.д.). Соответственно, двум инструкциям VM отводится функциональность задания границ парсела и эскейпинга внутри оного. Как именно эти самые парселы будут интерпретироваться, зависит исключительно от обрабатывающей их функции.

  2. Модель исполнения VM - старая добрая стек-машина (в каждой ячейке стека может быть либо байт, либо парсел). Но с одним но: у каждой функции стек индивидуален и полностью изолирован от остальных. При возврате из функции топ-значение её стека ставится в топ вызывающей, а стек вызванной незамедлительно грохается.

  3. VM содержит разумное количество встроенных функций, в том числе и ФВП, подчиняющихся общим правилам.

Не вижу с такой моделью никаких проблем со сборкой мусора. Совершенно.

rebforce ()
Ответ на: комментарий от iluha16

Не могу ответить в твоей теме из-за идиотского ограничения на одну звезду.

тебе надо сделать спецификацию к каждой консольной команде и разработать парсер генерящий гуй с туевой кучей checkboxов и selectов для каждой имеющейся опции с подсказками что делает каждая опция.

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

кроме того надо продумать как реализовать в гуйне взаимодействие между утилитами по типу pipeов (типа ls | wc).

Тему по подобному вопросу я открыл еще до первой темы по Метапрогу. Разберемся, когда руки дойдут.

metaprog ()
Ответ на: комментарий от metaprog

Чтобы эффективно и корректно справляться с различиями предлагаемой модели исполнения ЯФП и модели исполнения бинарного кода.

rebforce ()
Ответ на: комментарий от VarfolomeyKote4ka

Расскажи разрабам Erlang и Java, что они нормальный компилятор не осилили, ага.

rebforce ()
Ответ на: комментарий от rebforce

То есть, функциональное программирование настолько далеко от алгоритмов работы реальных процессоров, что нужен слой из виртуальной машины?

metaprog ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)