Метапрог-прототип, версия 7 + графические диалоги на Метапроге

Вот например, как ты собираешься без ООП писать драйвера устройств, к примеру?

Через СУВТ, очевидно же. Даже тот же GUI делается без ООП на метапроге, хотя часто пишут что ООП только в нем и место.

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

Значит все для успеха имеется!

Мне нравится ваш оптимизм как и ТС, а дальше только время покажет.

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

все уже написали

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

А успешный ЯП новый действительно сделать нереально, тут потопталось стадо титанов и школоте типа ТСа с Дианой ничего кроме насмешек но Лоре не светит.

написать, заинтересовать сейчас кого-то новым языком практически нереально

Вот это неправда. Есть еще куча областей, в которых можно продвигаться, в том числе и для ЯП общего назначения. Например, зависимые типы. Их до сих пор еще нет ни в одном мейнстримном языке. В плане асинхронности много работы еще.

Другой вопрос, что развитие ЯП дошло до того, что без знаний «ядерного матана» их разрабатывать уже не получается. Запасы человеческой интуиции исчерпаны.

Многие «ядерно матанные» концепты уже реализованы в экспериентальных языках (в случае зависимых типов agda, idris, итд). Нужно потихоньку эту реализацию переносить в языки доступные для среднего программиста. Кмк раст выстрелил как раз и поэтому - он красиво оформил концепты, развившиеся в других ЯП (C++, haskell).

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

Agda и idris ни разу не видел и не слышал про них ничего, в чем их принципиальное отличие от императивного и функционального программирования, что они привносят в программирование вообще, какие задачи и проблемы призваны решить?

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

в чем их принципиальное отличие от императивного и функционального программировани

Зависимые типы.

или о доработке существующих,

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

концепция владения вообще не на что не похожа,

RAII и владение как раз и C++ взято (unique_ptr и std::move). Просто в крестах оно костыльно, ибо надо обратную совместимость соблюдать. А в расте first class.

Обработка ошибок, паттерн матичнг, ADT, система трейтов взяты из хаскела.

только вводятся в оборот в С++ и либо они «слишком долго запрягали» либо действительно это попытка «запрыгнуть на уходящий поезд».

Тут дело не во времени. В C++ все эти инструменты (владения, лайфтаймы) - они опциональны. Программист может их использовать, а может все делать через new/delete. А может и сишный маллок дернуть. В расте программиста сразу сажают в клетку безопасности, и следственно компилятору раста проще рассуждать о том, насколько программа корректна.

Зависимые типы.

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

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

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

RAII и владение как раз и C++ взято (unique_ptr и std::move). Просто в крестах оно костыльно, ибо надо обратную совместимость соблюдать. А в расте first class.

Обработка ошибок, паттерн матичнг, ADT, система трейтов взяты из хаскела.

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

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

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

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

Это расширение системы типов, которая позволяет делать операции с параметрами типов. Например, в хаскеле конкатенация списков имеет следующий тип:

listConcat :: [a] -> [a] -> [a]

В идрисе:

append : Vect n a -> Vect m a -> Vect (n + m) a

в общем-то на самом деле все у друг дружки что-то тащат.

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

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

Тяжело но можно. provaton совершенно прав, над С++ тяготеет проклятие обратной совместимости. Если удасться скреативить легкоусвояемую сообществом суперабстракцию которая сможет заменить существующий ныне зоопарк парадигм и при этом позволит быстро и просто писать сложные проекты, она безусловно выйдет вперед.

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

В первом случае это достаточно полиморфное «а»

Во втором это n и m выглядит как «примешивание» какого-то контекста при этом для каждого из векторов разного, а результат как смешивание этих контекстов, но вроде все тоже самое можно было и в хаскеле сделать, «нипанятна» :)

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

Вот официальный туториал есть: http://docs.idris-lang.org/en/latest/tutorial/typesfuns.html#dependent-types

ЯННП, можно по рабочекрестьянски?;-(

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

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

Надо будет почитать, спасибо :)

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

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

Ты их не сконкатенируешь, типы разные, неявного приведения типов нет

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

И что что разные? Я могу на плюсах в шаблонах сделать такую конкатенацию через decltype (T1+T2) например (условно). Отсутствие неявного приведения типов не запрещает операцию сложения разных типов, что мне мешает аналогично сделать операцию вывода типа при конкатенации векторов?

Но я хочу от provaton услышать опровержение (что я неправильно понял) и пример как то о чем он рассказывает можно правильно понять…

Э… мы по моему об этом говорили, это маловероятно что бы что то приницпиально новое появилось и всех убило сразу. В истории техники такого не было ЕМНИП никогда.

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

Вы там вроде еще какие-то направления говорили в которых пытаются выдумать новое «железо» и найти ему применение.

У тебя длина вектора является частью его типа. Поэтому, конкатенация вектора длиной n и вектора длиной m есть вектор длиной n+m. И это известно на этапе компиляции, и компилятор может доказать, что твоя реализации функции будет соответствовать (или не соответствовать) этому условию.

И всего то? Е-мае, я на плюсах такое делал еще 10 лет назад;-)

Ну вот квантовый компьютер…

Да, но с ним все сложно. Очень узок круг задач которые он может.

еще какие-то направления

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

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

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

Но я в общем не специалист, это так, мнение диванного аналитика который местами «свечку держал»;-)

Вполне возможно что че то появится в смысле новой элементной базы и будет втыкаться на материнку в существующий слот. Память та же быстрая твердотельная уже сделала маленькую революцию в некоторых областях. Но все это на уровне идеологии все та же двоичная система… Что бы новая идея появилась и все перевернула - на это мне не хватает воображения;-(

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

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

Не, может это все как то очень круто и глубоко, и я просто в силу своей безграмотности не могу оценить;-(

Ну мне тоже сложно сказать, надо прочитать мануал. Но по беглому взгляду синтаксис очень напоминает хаскель, про хаскель говорят в самом начале… а я ведь еще та уточка, как по мне это какая-то вариация на хаскель, но со своим блекджеком :)

Да фик бы с ним с синтаксисом, меня идеология волнует;-)

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

    template <int D1, int D2, class T1, class T2> 
	inline Vec<D1+D2,  decltype(T1()+T2())> operator | (const Vec<D1,T1> &a, const Vec<D2, T2> &b){ 
		Vec<D1+D2,  decltype(T1()+T2())> r; 
		for(int i=0; i<D1; i++) r.p[i] = a.p[i]; 
		for(int i=0; i<D2; i++) r.p[D1+i] = b.p[i]; 
		return r; 
    }

А оказывается это модно, молодежно…

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

Через СУВТ, очевидно же

Напомни мне, что это за мем такой. А то может, вы ООП переизобрели под новым названием. :)

Это не мем. Это Структура Условного Выбора Типа.

Из ООП в СУВТ только полиморфизм, и то очень условно, если эти клоуны осилят - арифметику они скажем не асилили с криками «оно нам там нинужна!».

Это вот такое страхоцце

struct SUVT{
    int type_selector;
    unioun data {
         int integer;
         float real;
         char *string;
         // etc...
    };
};

из всех вариантов сделать то что вообще не требуется делать они выбрали самый уродский, это талант…

мне больше интересно как будут устроены не примитивные типы внутри этого объединения (если конечно они будут там вообще и если будут вообще не примитивные типы), как многократный указатель на указатель на указатель на указатель на другие структуры собранные из примитивных типов?

Клоун, тебе уже сотню раз говорили что арифметика тут вообще никакая ненужна, СУВТ не формат для всех переменных, но ты продолжаешь врать. Кстати, я вижу уже про потерю производительности (которая якобы должна быть, и сделает метапрог медленнее питона по твоим словам) не говоришь? Метапрог-прототип, версия 7 + графические диалоги на Метапроге (комментарий)

мне больше интересно как будут устроены не примитивные типы внутри этого объединения

Так же как и обычные.

Это ещё и было преподнесено со словами: «вы можете себе представить СУВТ?!!»

В инте можно хранить 2^32 вариантов типа, на все хватит.

А что ещё можно ждать? Какого то своего общего формата описания сложного типа? Это было бы интересно и весело, а это пара жалких клоунов - совсем не их амплуа…

Так не могут, посмотри на этого бездарного клоуна атонола, он думает что в СУВТ будут обернуты все переменные в метапроге.

В инте можно хранить 2^32 вариантов типа, на все хватит.

Мде, ладно, буду на скриптухе увожаемому профессору объяснять, СУВТ это замена isinstance из питона, тебе if(ininstance(...))-elif(ininstance(..))-elif... на (2^32)+ вариантов часто приходится делать?

В СУВТ в union заложены будут только те типы, которые ты укажешь в конкретном блоке СУВТ, который ты добавил на диаграмму.

Так зная метапрога он скорее всего так и сделает.

Да, несмотря на испорченное воображение и довольно богатый опыт работы со студенческим говнокодом, такого даже я представить не могу…

Скриптуха получится, а метапрог не для того был задуман! Я кошечка если что, а то вдруг не узнал. Я с ОПом в метапрог.онлайн говорю, так что знаю что такого не будет, твердо и четко.

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

из всех вариантов сделать то что вообще не требуется делать они выбрали самый уродский, это талант…

Что б сделал ты? Удиви меня.

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

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

Все типы известны на момент генерации кода по диаграмме, берите и пишите те типы которые нужно.

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

похоже на языки условного энтерпрайза

Нет, это research language. Т.е. язык для обкатки новых концептов из «матана» без претензий на широкое практическое применение.