You Gotta Frontend. Використай YGLFLovesDOU та спілкуйся із провідними спікерами зi всього світу!

Мои размышления. Компьютер. Программирование. Языки программирования

Мои размышления. Компьютер. Программирование. Языки программирования.
1.	Введение. Существование. Размер.
Замануха в названии предполагает, что читать сей опус будут люди типа «очень программисты» потому предупреждаю, что знакомые понятия появятся не скоро. 
Моя цель очень скромная. Построить систему и язык программирования с минимумом определений. 
Так как это мои размышления, то давайте обсудим, для начала, природу понятий и их необходимость. Итак, представляем, что у нас ничего нет. Но очень хочется. Первое, что нам понадобится это память. В научных кругах ходят упорные слухи, что эта штука является основой интеллекта. И я с этим полностью согласен.  Но мы о компьютерах, и реализации моих задумок в очень даже практическом смысле, потому с очевидностью (для профессионалов) нам потребуется место. Хочу обратить внимание на последовательность. Именно размер того об чем мы будем говорить (в смысле загрузок, хранения, протоколов обмена и многого другого) первичен. Смысл и понятия этого чего-то появится позже. Ну, ведь говорить, рассуждать и взаимодействовать с чем-то возможно, только если оно существует, а значит, имеет размер. Интересующиеся философией мне возразят, что совершенно не обязательно существование связано с материальной природой объекта. И даже приведут в пример существование сюжета «Войны и Мира» без материального носителя. У меня будет что им возразить немного позже. Пока займемся размером. Кажется, что тут рассуждать. Перед вот этим чем-то ставим размер да и всех делов то. Это логично. Но мало кто обратил внимание, что уже появилось первое ПРАВИЛО! Однако у этого правила есть недостаток. Для указания размера тоже нужно место. Потому мы неизбежно стоим перед определением первого понятия-единицы измерения памяти. Бит-это, конечно, классика, но нам хотелось бы побольше. 4 бита. Токен (Token). Вот и пусть это будет первым понятием. А вот теперь разовьем первое правило определения размера до более общего правила объединения (группирования) любых наших штук до вот такого не просто правила но и синтаксиса.
1.	Правило определения группирования.
Нечто, перечисляемое в скобках с подстрочным и надстрочным значениями  после закрывающей  скобки, означающим соответственно минимальное (Min) и максимальное (Max) значение содержания. По умолчанию значения Min и Max=1.
Пример 1.  Определение байта. Т.е. два токена. Для тех, кто не в курсе)
Concept Byte {Token}2   
Не знаю как вам, а мне надоело называть предмет неизвестной штукой. Давайте назовем его концептом(Concept). Как минимум появляется какой-то осмысленный синтаксис. Это я за пример 1. А сущность объединяющая концепты назовем группой (Group).
Нас можно поздравить!!! Мы имеем уже аж три понятия.
2.	Структура. Расположение.
В предыдущем примере мы как-то легко пропустили по причине «само собой понятно» еще одно понятие. Свойство. Т.е. значения Min и Max являются свойствами. И у них должно быть свое место расположения в определении концепта. Тем, что мы (по умолчанию) приняли, что размер должен идти перед данными мы определили структуру будущего концепта, в котором размер должен идти первым.  А ведь это наглядный пример определения свойства будущего концепта. Определять концепт, очень разумно определив его класс. Не особо заморачиваясь определим синтаксис концепта как «Имя класса концепта» «Имя концепта».  И вот само слово Concept и определяет концепт. И делаем мощный интеллектуальный прорыв, обозначив определение свойства таким неожиданным словом «Dim». Вот теперь и определим концепт Group.
Пример 2. Определение концепта Group

Concept Group
{ Dim Token Min=1
  Dim Token Max=1}
Продвинутый синтаксис
Concept Group { Dim( Token(Min=1, Max=1)}}
Надеюсь понятно, что скобками можно группировать. Группирование круглыми скобками требует разделения концептов запятыми.
Теперь мы можем определять структуру концепта и, соответственно, создавать понятия по расположению в концепте. Да, да. Понятие можно определять и по расположению а, не только определяя класс.  Да мы так зачастую и делаем. Просто не обращаем внимания. Это еще один нюанс, требующий внимания. Для обращения к концептам недостает очень важного понятия «Address». В программировании мы используем идентификаторы. В общем случае это адреса данных. Но, если построение системы в наших руках, то мы можем разместить классы в каком-то порядке. Тогда адрес (вернее какая-то его часть) является определением понятия. Если адрес строить по этим правилам, то можем получить очень любопытные последствия. Я б не хотел останавливаться сейчас подробно о построении (структуре) адреса. Я обещал напомнить о материальном существовании сюжета «Война и Мир». Он существует материально в нашем сознании в качестве адреса.
На этом можно и закончить первую часть, резюмируя: Систему можно построить, и я ее построил, вот на этих 5 понятиях. Здесь много чего не хватает. Методов и событий. Но, методы строятся по тем же правилам что и свойства. А событий, в общем случае, всего 2 (=0 и =1). Остальные это комбинации этих событий. Я смог придумать всего 16.  Всем спасибо. Если будет интерес, то продолжу.

LinkedIn

Лучшие комментарии пропустить

возможно, я не оценил всю глубину философской мысли, но мне кажется, что это наркомания какая-то

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Бит-это, конечно, классика, но нам хотелось бы побольше. 4 бита.

Представим, что на нас едет К танков... нет, К — мало, на нас едет N танков!

Мабуть тебе кажется очень умно высказался? А как по мне вообще ни о чем.. Большая просьба с подобными высерами в социальные сети. Там заценят.

Почитай про Forth. Почитай про lenses. Потом ADT, теория категорий, типизация и лямбда-куб... Это тебя отвлечёт от DOU надолго.

Ну, идея носилась в воздухе.. Это и Лисп и Forth. Да и объектная парадигма из этой серии. Упрощение-наследование. Проблема у всех одна. Преувеличивают значение императивного выполнения. Зациклились на выполнении команд и машине Тьюринга. У меня вычисления вообще вопрос вторичный.. Главное определение понятий, размер и адресация. Ну, и события и ветвление. Получилось достаточно просто и эффективно. Идея лямбда-куба хороша как математический аппарат. Типизация по Черчу это лишнее, а как синтаксис лямбда исчисления очень даже удачно. И у меня именно такой. Только вместо знака лямбды знак @ перед параметрами, а вместо точки имя класса «Func». Если функция без имени ( а у меня это допускается), то в чистом виде лямбда-функция. Получается просто и красиво и можно в качестве параметра передавать функцию. Вообщем, отвлекся на пол часа вместе с перекуром. Спасибо за материал.

Как и все хорошие игры, ОБЕД вобрал в себя все лучшее, что было создано в данной области до его появления. Разберемся во всем по порядку.

Идея игры довольно проста — посадить Ивана в кресло с возможностью ворочаться туда-сюда. Придать ему Марью, чтобы в уме получился хоровод. Усилить этот хоровод еще одной Марьей, иногда с выгоревшими усами, иногда еще как-нибудь. Дать возможность произносить монологи и время от времени есть. И поставить цель: съесть все, что имеется в отмеченном на столе квадрате.

Такое уже было? И да, и нет.

По концепции обед более всего похож на своего тезку — ужин. Настолько же сильный драматический элемент. Очень схожая система взаимодействия Ивана с Марьями и едой и креслом. Примерно такие же принципы постановки задач.

Но.

Гораздо сильнее Иван. Куда лучше разработаны правила работы с людьми. Кажется, что Марью можно потрогать — и на пальцах останется пыль. Лица очень хороши, фотографии говорят сами за себя.

Звуковые эффекты на высоте. Четко различаются голоса разных фаз настроения Ивана. Достойная «столовая» музыка.

Меню разворачивается на фоне живого Ивана. Блюда не новые, к тому же не очень высокого качества, и смотрятся очень приятно

Теоретически, можно выиграть, ни разу не скомандовав. Но чаще всего Иван и Марьи в пределах своей самостоятельности двинутся не туда и есть будут не то. Принимать личное участие придется, не сомневайтесь. Игра столь стремительна, что постоянная драка просто не успевает надоесть. Три, четыре Марьи — наконец-то вызов вашему мастерству. Для полного счастья не хватает лишь диких животных (забавно смотрелось бы нападение наглой гориллы). А как Ивана отбрасывает взрывной волной!

Наконец, с потолка падаете вы. Звучит Вагнер, от которого всегда чешутся кулаки, и вы понимаете, что это ошибка. Хочется выйти в прохладную подворотню и выпить лимонадику? Нет, любезный, с трех сторон прут Марьюшки с отточенными крючьями, и нюхают ваше дыхание. Иван лежит ничком и хрипит молитву, скользя коленями и локтями в разлитом соусе, — он уже умер. Гнус, мошкара, а не воин.

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

А. Водорацкой.

Родился на улице Герцена, в гастрономе № 22. Известный экономист, по призванию своему — библиотекарь. В народе — колхозник. В магазине — продавец. В экономике, так сказать, необходим. Это, так сказать, система в составе 120 единиц.
Фотографируете Мурманский полуостров и получаете telefunken. И бухгалтер работает по другой линии — по линии библиотек. Потому что не воздух будет, академик будет! Ну вот можно сфотографировать Мурманский полуостров. Можно стать воздушным асом. Можно стать воздушной планетой. И будешь уверен, что эту планету примут по учебнику. Значит, на пользу физики пойдет одна планета.
Величина, оторванная в область дипломатии, дает свои колебания на всю дипломатию. А Илья Муромец дает колебания только на семью на свою.
Спичка в библиотеке работает. В кинохронику ходит и зажигает в кинохронике большой лист. А в библиотеке маленький лист разжигает. Огонь ее будет вырабатываться гораздо легче, чем учебник крепкий. А крепкий учебник будет весомее, чем гастроном на улице Герцена. А на улице Герцена будет расщепленный учебник. Тогда учебник будет проходить через улицу Герцена, через гастроном № 22, и замещаться там по формуле экономического единства. Вот в магазине 22 она может расщепиться, экономика: на экономистов, на диспетчеров, на продавцов, на культуру торговли... Так что в эту сторону двинется вся экономика.
А библиотека двинется в сторону 120 единиц, которые будут предмет укладывать на предмет. 120 единиц — предмет физика. Электрическая лампочка горит от 120 кирпичей, потому что структура, так сказать, похожа у нее на кирпич.
Илья Муромец работает на стадионе «Динамо». Илья Муромец работает у себя дома. Вот конкретная дипломатия! Открытая дипломатия — то же самое. Ну, берем телевизор, вставляем в Мурманский полуостров, накручиваем там все время черный хлеб... Так что же, будет Муромец, что ли, вырастать? Илья Муромец, что ли, будет вырастать из этого?

Ну мне пока что больше напоминает эвристическую машину Машкина. Но надо ещё посмотреть.

Это классические примеры шизофазии))

Знаю. Потому и сказал, что немного не то.

Именно. Я и привел их, чтобы показать, с кем мы имеем дело. Просто больной человек что-то пишет сюда.

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

так лисп же)

И делаем мощный интеллектуальный прорыв, обозначив определение свойства таким неожиданным словом «Dim».

которое (слово) неожиданно уже есть в бейсике)

Concept Group
{ Dim Token Min=1
Dim Token Max=1}

Предлагаю определиться, какой язык создавать: 1) диалект лиспа, или 2) диалект бейсика, или 3) гибрид лиспа с бейсиком. :)

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

Это не элемент синтаксиса, как в бейсике, а реально функция по выделению памяти.

Наступним науково-технічним проривом має стати винайдення функції звільнення пам‘яті. Такъ подебим!

Наступним науково-технічним проривом має стати винайдення функції звільнення пам‘яті

Минулий вік. Зараз моДно garbage-collector

а потім феї гарбадж коллекшина загортають звіряток у фольгу

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

розкажіть краще, як в вашій архітектурі буде знаходитися місце для нескінченної кількості концептів

Concept Group
{ Dim Token Min=1
Dim Token Max=1}

Почему «нескинченнои»? Я сторонник минимализма. Пока вся система имеет около 80 концептов и занимает 13к памяти. Все очень компактно. И это вместе с описанием синтаксиса, транслятором и текстами хелпов, которые тоже занимают место.)) Можно ставить на любой контроллер. И пока без графики. Только точки-линии прямоугольник и круг сделал..

Где посмотреть код?

Могу отослать на почту.. Или в скайпе показать как работает.. Толку тебе с двоичного файла? Он же будет работать только в моей виртуальной машине. Коим он сам и является.. Что б допилить на конкретный процессор надо чуток добавить.. А именно реализацию 12 команд. (Арифметика и сравнение) Они у меня не как обычно выполняются. адресацию организовать с организацией памяти. Ну, это просто. Ну, и загрузить правильно. Я планирую сделать отладчик на какой-то конкретный контроллер, и можно будет в коммерцию..

Он же будет работать только в моей виртуальной машине. Коим он сам и является..

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

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

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

Ну, так на десктопе у меня и есть эмулятор. А двоичный код это описание системы. Вот и отлаживаю. Для запуска на контроллере там мелочь надо слепить и загрузчик. И отлаженное должно работать и на железе. Только с конкретными портами, и прочим.. А с какой целью для посмотреть?

А с какой целью для посмотреть?

Ну вы ж предлагаете обсудить. Вот и будет что обсудить.

Предмет демонстрации зависит от цели. Что б не показывал то, что не интересует.

Так вы и определите цель. Но по любому нужна конкретика.

Как я могу определить твой интерес? Я работаю и работаю. Вижу что получается круто. Вижу хороший коммерческий выхлоп. А твой интерес в науке, или просто любопытно, или какая-то задача, либо поучаствовать? Тогда в чем? Чисто за язык интересно или система? Может архитектура процессора? Вот потому и спрашиваю что именно глянуть хочешь.
Кстати, тут за архитектуру процессора спрашивали по поводу параллельной обработки.. Это очень похоже как сейчас делают конвейер где команды условного перехода выполняются одновременно с предыдущей, в расчете что б потом перейти. Ну, так тут нечто похожее.. Условия не изменяют память и могут выполняться одновременно, а переходы могут выполняться по нескольким веткам.. Плюс к этому управление условиями (они же события) как бы подвешиваются на данные в виде подписок.. И получается любопытная картинка.. Обращаешься к данным, а там (в той области памяти где данные) подписка-условие и переход на ветку.. Это если сильно упростив..

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

Идея с ТТА с пшиком провалилась у ARM на GPU, основной упор они делали по минимизации простоев и оптимальному потреблению на «инструкцию» кода, а по факту получилось очень низкопроизводительное устройство, которое мало потребляло, но это был тупик.

Первое содержательное сообщение. Но тему не вкурил. Ничего общего. TTA архитектура это попытка решить вопрос производительности за счет увеличения сложности управления процессором. Я наоборот упрощаю работу выделяя события и подписки как основной инструмент конструирования. Это даже не программы получаются, а формализация того что интересует в предлагаемых понятиях. Параллелизм получается по причинам сущности вещей. Что б совсем было понятно объясню так.. Одновременно сотня процессов может проверять данные на что угодно и это никак не повлияет на результат этой проверки. Аналогично происходит и с выражениями и даже с функциями с параметрами, как в функциональном программировании. Можно даже одновременно выполнять несколько функций с разными параметрами. Таким образом и события могут возникать и отрабатываться в любом порядке. Как оно и происходит в жизни. Проблема только в голове. Надо кое что там немного поменять, что б научиться мыслить так как я предлагаю. Но результат будет фантастический. Вдруг все станет так легко и понятно. А пока не привычно, конечно.

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

Ты явно что-то недопонимаешь. Какая там сложность управления, если основная логика процессора делается на коленке за 5 минут?

Но результат будет фантастический. Вдруг все станет так легко и понятно.

Пока всё очень грустно и уныло.

Я наоборот упрощаю работу выделяя события и подписки как основной инструмент конструирования. Это даже не программы получаются, а формализация того что интересует в предлагаемых понятиях. Параллелизм получается по причинам сущности вещей. Что б совсем было понятно объясню так.. Одновременно сотня процессов может проверять данные на что угодно и это никак не повлияет на результат этой проверки.

Я пробовал этот подход в KPU, проблема в том, как обеспечить синхронную работу логических элементов, учитывая, что время срабатывания транзисторов ненулевое и немного нестабильное. Из-за этого возникает падение частоты и все преимущества параллельного выполнения съедаются общим падением производительности процессора и периферии.

Это технический вопрос. Значит решаемый.

Поднятие частоты до 1 эксагерц и размера тразистора до 1 куб.фемтометра — тоже вроде бы чисто технический вопрос :)

тобто

80 концептов

is enough for anyone?

тоді ваш підхід не можна назвати минималістічнім

Я сторонник минимализма.

це ваші слова, а ви далекі від мінімалізму як ніколи

Так это ж замечательно. У вас есть шанс проявить собственные способности.

скажу вам так:

найкраще рішення — це таке рішення, якого не існує. Зрозумійте мене правильно, я не кажу що «найкращого рішення не існує», а кажу що найкращим рішенням є таке, яке не треба будувати: от дивіться: концепти крутяться, групи мутяться — самі по собі, без будь якої потреби щось будувати.

Ось де мінімалізм! а ваш, перепрошую, «винахід» на 3-4 рівні відстає від тіки шо вам явленого

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

сумніватися ваше право, але все ж таки

розкажіть краще, як в вашій архітектурі буде знаходитися місце для нескінченної кількості концептів

Concept Group
{ Dim Token Min=1
Dim Token Max=1}

Нема нескинченного количества.. 13 к всего.. Если очень интересует, то выходи в скайп расскажу структуру.. А дальше просто..

А за знакомые слова ты предлагаешь придумывать новые?

я просто намекнул на то, что фраза про «неожиданное слово Dim» слегка пафосная. ;-)

Это не элемент синтаксиса, как в бейсике, а реально функция по выделению памяти.

Ну как я понял по описанию на википедии Dim в бейсике — это что-то типа функции для работы массивами (как я понимаю, в т.ч. и выделение определенного количества памяти под определенный размер массива).

«DIM — Описание массива. В отличие от обычных переменных, массивы требовали описания. Максимальное число размерностей массива определялось только реализацией.» © ru.wikipedia.org/wiki/Бейсик

Гибриды вряд ли жизнеспособны.

Ну если разроботчик языка на него положил болт, а какого-то маломальского сообщества у гибридного языка не образовалось, то он действительно будет нежизнеспособен. Но это касается любых языков.
Вот, например, был такой язык Dylan (что-то типа диалекта лиспа с алголо-подобным синтаксисом) — ru.wikipedia.org/...​n_(язык_программирования . В свое время был разработан яблочниками (что как бы намекает на серъезнность разработки), которые потом его прикрыли (почему? — ХЗ). Но кто про него вообще знает? (да и сам язык наверное никем не юзается, хотя задумка, как мне кажется, интересная была). Если бы яблочники разработку Dylan’а не прикрыли, то кто знает — может сегодня под айфоны все писали бы не на объектив-си и свифите, а на Dylan’е...
З.Ы. Ну и походу на гитхабе диалект Dylan’а под названием OpenDylan энтузиасты коммитят вроде как github.com/dylan-lang/opendylan (последнее обновление репозитория было то ли 17 дней, то ли 3 месяца назад), так что наверное язык еще кто-то юзает.

А насчет Лиспа, что-то есть.. Иерархия построений. Только принцип другой. Не функции. Концепты. Т.е. сами функции тоже предмет для построения.

Не функции. Концепты. Т.е. сами функции тоже предмет для построения.

Чем тогда концепты отличаются от этого:
«Фу́нкция вы́сшего поря́дка — в программировании функция, принимающая в качестве аргументов другие функции или возвращающая другую функцию в качестве результата.» © ru.wikipedia.org/...​i/Функция_высшего_порядка
?

Это частный случай. Потому как параметры тоже концепт. А построение концепта допускает, кроме функций наследование от класса, при помощи синтаксиса. Т.е. буквочками. Фактически компилятор это функция на множестве концептов в множество концептов.

двойную дозу феназепама и аменазина этому достойному пану!

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

можно заменит все на клизмы со скипидаром. Пациент будет занят и перестанет творить контент

Проблемы со здоровьем у эксперта по жабам? Мне уже за 60, а я таких и названий лекарств не знаю. Поаккуратней с жабами и гадюками.))

у меня все ок, а вот вы знали бы что пора лечиться — не несли бы пурги :)

Если бы уважаемый сэр был в курсе дел, он бы увидел что это идеи вполне себе в духе современных концепций и подходов.

ідеї несуть в собі дух, літеру і концепт сучасних підходів

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

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

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

мало того что автор к пятнице не успел, так еще и налету в комменты дописывает продолжение :)

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

3. Состав концепта. Заголовок.
Концепт состоит из:
a) Заголовка.
b) Свойств.
c) Методов.
d) Вложения.
Заголовок содержит класс, имя, хелп и определение параметра концепта.
Свойства это атрибуты-значения и выражения, не изменяющие значения свойств и их события. Ограничение на изменение значений свойств для реализации одновременного доступа от нескольких процессоров или процессов.
Методы можно сказать, что это те же свойства, которые заключаются в выполнении некоторой последовательности команд выделенной в группу по некоторым соображениям. Методы имеют доступ для чтения ко всем свойствам концепта. Доступ для изменения свойства разрешается после легализации свойства оператором With. Вложение содержит концепты, реализующие этот концепт. Для операторов это можно назвать «телом оператора». Для элемента управления — это вложенные элементы. Для класса это описание порождаемого концепта. В тексте назовем это реализацией (в скобках) и сформулируем теперь синтаксис на примере.

Пример 3. Метод ADD. Сложение с параметрами

@(Byte A=1, Byte B=0) Fun Add: Byte # Сложить A и B"
‘ Тело функции сложения
{Add=A+B }

Пример не очень сложный, но требует пояснения. Это важно для понимания.
Группа из двух концептов параметров (знак @) перед концептом Add класса Fun. Знаки «=» и «:» это свойства концептов соответствующих классов Byte и Fun, а не операции и не фишки синтаксиса. И после трансляции именно в таком виде и будут храниться в двоичном коде в нашем формате. Знак «=» -это имя свойства концепта класса Byte в котором хранится значение и не единственное. Есть еще свойство «|» в котором будут храниться подписки на события. И потому это не просто свойство, а список. Потому как подписок может быть несколько (до 16).
Два комментария имеют принципиальную разницу. Тот, что начинается со знака «#» - это тоже свойство концепта и будет храниться в двоичном коде, а начинающийся со знака «‘» после трансляции не сохранится и имеет смысл только в тексте. Сохранение комментария в двоичном коде это очень вкусная вещь для отладки и для верификаций. Но об этом тоже гораздо потом.
В фигкурных скобках реализация.
P.S. Планировал сегодня больше написать, но комментарии настроение испортили. Я исправлюсь. Но торопыгам и всезнайкам хочу сказать, что у меня нет волшебного хрустального шара что приносит доллары и мгновенные знания. И тем, кто считает, что все быстро все понимает, разочарую. Внешне это выглядит привычно. Однако для понимания надо освоить именно всю конструкцию. Потому как выполнение происходит не обычно. Процессы инициируются не только командами и в месте выполнения команды, но и там где находятся данные. Для этого надо понимать как все в объеме. Я б не писал эту фигню так подробно, если б мог бы двумя словами объяснить, как оно работает. Если кто спешит, то могу показать результат для него отдельно в скайпе.

Процессы инициируются не только командами и в месте выполнения команды, но и там где находятся данные.

Замечательно, кеша данных нет архитектурно.

Почему нет? )) Наоборот. Открываются новые возможности для разных алгоритмов работы с кэшем)) Причем осознанно!!! Данные все с типами и классами!!!

Открываются новые возможности для разных алгоритмов работы с кэшем))

Это как рассматривать секс в нос и в ухо за новые возможности.

С фантазией у тебя плохо. Я не за секс)). Придумал задачку для разминки мозгов. Ты ж хорошо знаешь архитектуру процессора. Ну, так вот представь в процессор могут поступать не только команды, но и любые концепты.. Структура ж одинаковая. С разбором вопрос решаемый. Так вот представь в процессор попадает группа ( там уже есть определение группы) операторов If. Можно их выполнять одновременно? Задачка не из моей архитектуры. У меня нет оператора If и нет типа Boolean. Возникнут ли проблемы? Какие? Или получим оператор типа Select Case? Хочу услышать что скажешь. Ты ж специалист. То, что реализуемо, так однозначно.

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

И грабят корованы!

А ты только что потерял один ранг кришназевула. В классической архитектуре команды проверок именно этим и занимаются. Загружают данные и взводят соответствующие регистры. Ну, может и переходы ееще выполняют. Я только обобщил этот принцип. У меня данные порождают события и выполняют переходы. Фокус в том, что данные операции могут выполняться параллельно, что я и предлагаю. Спрашивается почему бы не грузить сразу группу вот таких данных)) Научитесь соображать самостоятельно. Это немного сложнее чем читать даже очень умные даташиты.

Вот что эти буквы означают я не в курсе.. Щас в гугле гляну.

В общем случае нет. Что б получить серьезный эффект от распараллеливания нужно другую архитектуру процессора. У меня не строятся команды в лоб в алгоритм. Да и алгоритма нет как такового. Фактически последовательность выполнения определяется во время выполнения. Нет такого в классическом виде шаг1, шаг,2... Мы описываем желаемые взаимодействия с помощью подписок на события и умываем руки.. Все остальное в руках событий.

Что б получить серьезный эффект от распараллеливания нужно другую архитектуру процессора

GPU?

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

Бугага! Поздравляю, ты изобрёл x86 20-летней давности %)

Я тебе пару вопросов задал. Постарайся ответить. Если завтра-послезавтра ничего достойного не увижу, то буду иметь основания считать тебя дебилом. Бугага!

Если завтра-послезавтра ничего достойного не увижу, то буду иметь основания считать тебя дебилом.

Кокая трогедия © По крайней мере будет симметрично.

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

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

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

В этой теме он пока не сказал ничего заслуживающего внимания.

Он ждёт конкретики. А её нет. Только странный трёп в терминах, которые активно намекают на отсутствие смысла.

Я тоже жду. Ну, в смысле, пассивно (нет её — пофиг, есть другое чем заняться).

Для этого другие сайты есть..

Ну как бы тут 99% это выёживание (в основном на тему сыров и трактора). Увы. Так что ни он ни вы сильно картину не изменили ;(

Процессоры можно разделить на две части. Одна занимается выборкой и ветвлением. А вторая занимается арифметикой. Выборка данных и передача управления становится первичной.

Хочу услышать что скажешь. Ты ж специалист.

У него просто нет слов...

А там есть что сказать.. Особенно в плане параллельной обработки. Дело в том, что выражения не изменяют память. В операторе If как раз такие выражения.

Дело в том, что выражения не изменяют память. В операторе If как раз такие выражения.

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

Немножко не так.. Если вы знакомы с Прологом и интерпретациями. Т.е. с автоматическим доказательствами. Теоретически эта проблема решена. Есть вопросы практической реализации. По причине экспоненциального роста ресурсов для решения сложных задач. Не вопрос создавать программу. Это реализуется так же легко как создание объектов из класса. Проблема обрубать хвосты с длинными ветками разбора. Тут у меня есть идея, но нет времени довести до ума именно для машинного разбора. Идея заключается в том, что когда я начал реализовывать автоматическое доказательство в своей системе. Я столкнулся с тем, что аксиоматика (или база знаний) фактически это те же базовые события (напомню, что у меня их всего 16). Остальные понятия это просто другие названия тех же событий, но над другими свойствами или выражениями. Т.е. нет события Key_Press, Key_Down и Key_Up. Это те же события какого-то свойства =0, Change_Value и Before_Change_Value. Только другие названия более подходящие для пользовательской области применения. И я уперся в то, что понятия, которые над которыми формулируются высказывания, в конечном итоге тоже события. Ну, такой пример надо определить положительное ли число −12349768 в степени 98754. Это можно определить и без вычисления непосредственного если у нас есть высказывание по поводу в четной степени любое число положительное. Фишка в том, что само понятие «положительное» это базовое событие >=0)) Да и четность числа это тоже событие!!! Т.е. вся наша проблема тупо в переименовании событий. Если задачу ставить в терминах событий, то и алгоритм писать не надо, он сам выполнится. Классический пример с сортировкой. Если мы его сформулируем в терминах событий то, дальше дело компьютера отсортировать. Ведь по человечески задача формулируется событиями больше-меньше соседние элементы и поменять их в случае необходимости. Ну, так и надо написать. Сортировка у меня выглядит так.
Определение массива и подписка всех элементов на событие Change_Value (знак"|" подписки. Событие передает индекс изменяемого элемента массива Index в команду Compare к которой оформляем подписки на события More и Less для перестановки соседних элементов. Я перестановку не сделал. У меня там знак который не скопируется. Это чисто для объяснения технологии.
Dim A[] | Change Value { Compare (A[I], A[I-1]) |More {A(I)} |Less {A(I)}}
Написаное выполняется так.. При изменении значения элемента массива A[] запускается подписка на событие Change Value в фигурных скобках. Т.е. команда Compare сравнивающая соседние элементы. В свою очередь по выполнению сравнения оформляем подписку на события More и Less в которой и осуществляем обмен. Если осуществляется обмен, то это опять приведет к событию Change Value и процесс пойдет лавинообразно. Сори.. Я на сегодня много написал))

Так вот представь в процессор попадает группа ( там уже есть определение группы) операторов If.

Как она туда попадает?

Можно их выполнять одновременно?

Можно. Но получится полная хрень, особенно если эти if зависимы друг от друга и вычисление следующего зависит от предыдущего. Иначе я себе не могу представить независимые сравнения, разве что только в switch/case конструкции, но там есть другие способы оптимизации, такие как табличные переходы по значению. Многие низкоуровневые языки, такие как С/C++/Ada не допускают параллельного сравнения и это заложено в дизайн языка, например такое сравнение будет только последовательное:

if (object && object->parent && object->parent->name) { }

У меня нет оператора If и нет типа Boolean. Возникнут ли проблемы? Какие? Или получим оператор типа Select Case?

Select Case — это что из вижуал бейсика? В общем тут я вообще потерял нить обсуждения и не смог распарсить твой поток сознания.

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

Проблема в том, что ты буквально воспринимаешь параллельность и отталкиваешься от факта, что всё уже загружено и засетапленно в процессоре для параллельного выполнения. Это далеко не так в real life. То, что ты якобы хочешь называется medium/coarse grain parallelism. От него ушли уже лет 30-40 как (это к тому, что историю нужно учить, чтобы не изобретать велосипеды прошлого века). Сейчас всё вертится вокруг fine-grain / instruction level parallelism.

Ну, и куда пропал, комментатор? Я вопрос задал.

Прости, потерял хрустальный шар, без него не смог распарсить поток сознания.

А это хрустальный шар не твоего уровня. Потому и не распарсил.

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

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

Сохранение комментария в двоичном коде это очень вкусная вещь для отладки и для верификаций.

Уж прости, но такое мог предложить только человек, понимающий архитектуру процессоров на уровне статьи в журнале vogue. У любого человека, знающего что такое execution pipeline волосы на спине станут дыбом от такого решения. Я уже не говорю о том, что такой изврат архитектурно убивает эффективность кеша кода на порядок. Чем больше ты выдаешь информации, тем больше это похоже на антипаттерн — как делать не надо.

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

Тут вопрос по существу. У меня транслятор текст программы подсвечивает и анализирует надстрочные-подстрочные символы. А сюда не могу скопировать текст RTF. Вот проблема))

Тут вопрос по существу. У меня транслятор текст программы подсвечивает и анализирует надстрочные-подстрочные символы. А сюда не могу скопировать текст RTF. Вот проблема))

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

Принимается только как шутка. А в системном смысле при таком подходе редакторы (и вообще приложения) становятся не нужны. Как и расширения файлов. Все файлы имеют единую структуру. При необходимости описание содержится в самом файле. Выполнение и редактирование любого файла происходит в единой среде потому не нужны ни браузеры, ни вообще ничего. Редактирование превращается в изменении значений свойств концепта. Потому совершенствование заключается только в новых версиях редактирования класса концепта. Мелочь, конечно, но решается проблема не читаемости файлов. Читается, грузится и редактируется все и везде..

возможно, я не оценил всю глубину философской мысли, но мне кажется, что это наркомания какая-то

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

Я это строил не как язык, а как систему и как единый подход ко всему что я встречал. Язык это следствие. Основной принцип простота в изучении, применении, построении транслятора и универсальность применения. Область применения от десктопных программ, до документирования, построение сайтов, текстов. Реализована функциональная, прототипная, объектная парадигма. Можно писать программы интерпретирующие логику типа Пролога. Идеально подходит для реактивного программирования. Работает на многопроцессорных системах. Минимальный требования к объему памяти. Всего 15к занимает. Т.е. можно ставить на контроллеры. Ну, и куча еще всяких плюшек. Основной считаю это изменение мышления в самом процессе программирования. Немного не привычно по началу, но потом становится даже неудобно писать на обычных языках. Не хватает некоторых инструментов к которым уже привык.

Хотелось бы узнать за счет чего достигнуто свойство, упомянутое в предыдущей теме автора, а именно:

новая технология программирования при которой сложность растет линейно (а может даже не растет) объему задачи

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

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

4 бита. Токен (Token). Вот и пусть это будет первым понятием.

4 бита — это ниббл (nibble).

Это несомненно принципиальное замечание.

Это базовая терминология.

Пишемо курсову роботу?

Просто делюсь мыслями. Я ж так написал.

Подписаться на комментарии