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

concatenative languages вообще не про data flow, хотя подкупают тем, что в них нет «переменных».

Как нет?

VARIABLE DATE
12 DATE !
DATE @ .

В Factor их вроде реально нет!

Понятно, что без глобальных переменных не обойтись. Я имел в виду, что использование переменных не идеоматично при написании 99% кода в forth-like языках

Владимир

Делаем одну глобальную структуру и в нее помещаем 1514 переменных.

Ну это что то по типу VARIABLE, в Forth есть расширение для переменных более сишного типа.

Ну это что то по типу VARIABLE, в Forth есть расширение для переменных более сишного типа.

Это какое? А чем VARIABLE не сишный тип?

Если задать VARIABLE в функции то при выходе он никуда не пропадет.

Еще как вариант чисто функциональной графической нотации — FAUST

http://faust.grame.fr/

но, как видно — все равно — ноги растут из схемотехники/signal processing — и, как следствие — язычок нишевой (для написания аудио-плагинов).

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

Если задать VARIABLE в функции

в функции

???

В Forth нету функций.

Но ты понял что я о словах!

Да и чем они не функции?)

У них нет лексической области.

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

Ну для них обязательно нужна продуманная IDE, расширение схем, блоков, я думаю у metaprog что нибудь да получиться!

{ а как же аргументы? }

Владимир

Предлагаю рассмотреть возможность использования диаграмм для разработки API /не программ/.
Библиотеки:
- для работы с строками;
- математические /матрицы, .../;
- ...

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

Ну для них обязательно нужна продуманная IDE, расширение схем, блоков, я думаю у metaprog что нибудь да получиться!

у faust, pd есть ide. как же без него? рисовать-то надо где-то. И библиотек уже к ним наработано будь здоров.

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

Представьте себе молодого и горящего бизнес-аналитика, который только ознакомился с BPMN, ощутил его «полноту» и удивляется: почему на нем программисты не пишут. Ядро Линукса написано на каком-то убогом древнем Си. Ну-ка, давайте-ка его на BPMN перепишем! Красота, стройность, наглядность, визуальщина, событийность, параллельность, конкуррентность, коллаборативность... Ну бред же. Ниша есть — и слава Богу!

Да. При желании. http://programatica.cs.pdx.edu/House/

У тебя какая ОС стоит? House или Линукс? Или небось винда (ядро которой тоже сделано на Си)? Я впервые об этом House слышу. И вообще не припомню хоть одной программы, сделанной на Haskell, а ты?

Что бы было, если бы fwrite не выводил бы в файл а писал бы в первый байт первого аргумента значение последнего аргумента? Угадать последовательность вызовов практически невозможно

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

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

В Си на диаграммах не видна логика? Чего-то я не понимаю тут.

И вообще не припомню хоть одной программы, сделанной на Haskell, а ты?

А я кстати сразу могу назвать, Haskell - Pandoc, Erlang - Wings3D, обе замечательны. А какие программы современные есть на С?

Или небось винда (ядро которой тоже сделано на Си)?

Там вроде плюсцы!

принцип «одна диаграмма — один исходник» очень облегчит борьбу с внутренними ошибками Метапрога и другими нетривиальными ситуациями.

Я уже инлайню метапроговские (не сишные) подфункции. Скоро будут новые скрины. Си вообще не будет видеть границ метапроговских подфункций, как будто все - одна функция. Только особые случаи, заслуживают отдельньных функций на уровне сишного транслятора: рекурсия, указатели на функцию, вызов сишных функций. Думаешь gcc 8 не схавает исходник размером в 1 Гб?)))

От внутренних ошибок Метапрога простота Си дает 100% гарантию. Называть каждую переменную уникальным именем, чтобы избегать коллизий - и все будет ок.

Что, прямо-таки для всех процессорных архитектур? Или будешь прибиваться гвоздями к интелу? Можно, конечно, потратить на это несколько лет, за которые можно было бы развить саму среду — но вот я не понимаю эту маниакальную страсть велосипедить кучу дурной работы, давно и успешно сделанной другими. Если только не прямо в машинный код, а подцепиться к какому-нибудь LLVM...

Или бэкенду на gcc. Посмотрим, может Си все же останется наилучшим общим знаменателем (кроссплатформенность - огромнейшее преимущество Си).

Думаешь gcc 8 не схавает исходник размером в 1 Гб?)))

Не будет компилироваться на машинах с маленьким размером памяти! У меня вылетает с недостатком памяти при компиляции некоторых программ, не надо так!

Ядро винды на плюсах? Серьезно?

Си: ядро Линукс, драйвера, coreutils, wireshark, Gnome/XFCE...

До таких толстых исходников надо еще дорасти. При нужде действительно можно будет бить на отдельные файлы.

Ядро винды на плюсах? Серьезно?

Нет видимо, спутал!

Это все появилось до 2000 года! А что из новых проектов? Gnome, XFCE написаны не полностью на C кстати!

Ну после 2000 уже поперли плюсы, джава, питон - словом, капут.

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

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

То есть, метапрог (после релиза).

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

ТС-у бы хоть немножко почитать до чего наука-то дошла

Почитываю Хабр иногда.

https://habr.com/ru/post/423889/

https://habr.com/ru/post/443466/

Дошла до джаваскрипта на серверах (nodejs) и десктопе (electron). Дошла до тормозной и глючной джавы на смартфонах и планшетах. Список продолжайте сами.

Если исходники открыты и будут н нашем аналоге гитхаба, то опочему б не перекомпилировать все? С ядром линукса так и делается. Си ж не плюсы, часами компилиться не будет.

Дошла до джаваскрипта на серверах (nodejs)

А чем это плохо? В сервере главное база данных там, io, все это на С написано.

С ядром линукса так и делается.

Нет, у ядра есть модули!

Если исходники открыты и будут н нашем аналоге гитхаба, то опочему б не перекомпилировать все?

Потому что я прежде всего пользователь! Я не хочу компилировать, хочу что бы оно само там как то разобралось со всем.

Вот смотри, собрал ты metaprog статически с PCRE, ну допустим, а потом в PCRE нашли уязвимость, и мне нужно делать apt update и перекомпилировать metaprog, а если бы оно там все динамически собралось, то я бы просто написал apt update и pcre.so обновился бы, и metaprog юзал бы его, и не надо было бы ничего перекомпилировать!

Само будет компилировать. Этим я не отрицаю, что иногда библиотеки быть должны, но лучше автоматическая сборка монобинарника. Вспоминается флейм Линуса с Таненбаумом:

https://groups.google.com/forum/#!topic/comp.os.minix/wlhw16QWltI

Или нынешние срачи по systemd (которое единый монобинарник, заменивший тысячи скриптов).

Или нынешние срачи по systemd (которое единый монобинарник, заменивший тысячи скриптов).

Но оно модульное!

но лучше автоматическая сборка монобинарника

Ну да, это тоже очень хорошо, главное что бы был выбор!

PCRE уже обсуждалось, лучше обойтись без него. Или, если найдутся умники и сделают такой модуль, то чтоб Метапрог обязательно предупреждал о небезопасности такого подхода.

Ладно, суть вопроса в другом. Что плохого в том, чтоб перекомпилировать весь Метапрог? Да еще и на машинах конечных пользователей, автоматически используя все доступные оптимизации их процессоров? Мне в этом симпатична идея Gentoo, но командный интерфейс меня пугает. Если б Gentoo была основана на графическом Метапроге - уже им бы пользовался.

Не пойми меня превратно, в модульности тоже ничего плохого (как в ядре линукс или systemd). Главное не переборщить с этим.

Что плохого в том, чтоб перекомпилировать весь Метапрог?

Это долго + нужен GCC.

Си не плюсы, компилится быстро. GCC опенсорсный, какие проблемы?

Си не плюсы, компилится быстро.

Долго.

GCC опенсорсный, какие проблемы?

Много весит, есть не для всех платформ.

используя все доступные оптимизации их процессоров?

От этого ломаются многие программы, это не безглючно работает! Это плохой подход.

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

Насчет оптимизаций процессоров - это баги в железе или компиляторах?

В компиляторе + программе + железе.

Чего толко стоят Spectre+Meltdown. Кстати, не удивлюсь если их вшили в процики преднамеренно.

Не думаю что специально вшивали, intel+amd могут и в открытую туда бекдоры свои поставить, альтернативы то нет.

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

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

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

Что плохого в том, чтоб перекомпилировать весь Метапрог?

Плохо то, что раз дистр бинарный, то вынь да полож бинарник. Если дистр типа генту, то подавай исходник.

автоматически используя все доступные оптимизации их процессоров

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