Продолжение формализации. Некоторые идеи #2
Запись от CoderHuligan размещена 03.04.2020 в 14:32
Показов 18187
Комментарии 221
|
(Добавлено позднее: это конечно заблуждение, но оно интересно с точки зрения фантазии...) Кстати, о птичках (не так сложно написать компилятор, как формализовать ЯП без сайд эффектов  )Если не отказываться от стека (пусть даже виртуального), а все же оставить некую общую структуру для передачи данных, то можно сделать вот что. Можно обратную польскую запись, как бы это мягче выразиться.. - даже не "выровнять", а обратить любое выражение в последовательность элементарных инструкций, как это было описано в предыдущем посте данного блога, но гораздо проще. Что предлагается? А вот что: Итак: 1) у нас есть, допустим стек; 2) но мы не хотим использовать сложные вложенные выражения со скобками, которые трудно разбирать; 3) использовать старшинство операций по умолчанию(источник ошибок); 4) нас тошнит от синтаксиса Forth; 5) мы хотим все сделать "по компьютерному" а не по.... Чтобы не ходить далеко, начнем сразу с примера: Допустим у нас есть классическое инфиксное выражение (для домохозяек  ):
Теперь у нас имеются кроме бинарных и "унарные" операции. Использую термин "унарные" только в данном контексте и прошу не путать их с унарными в обычном. Запишем вышеприведенное выражение таким образом (сразу предупреждаю, что это НЕ префиксная и НЕ постфиксная запись!!!):
Теперь, что же мы получили в итоге? Мы, внимание, - выровняли выражение, и привели его к естественным последовательностям инструкций! Это значит, что теперь это выражение стало совершенно естественным, так как его нужно читать слева направо до самого конца, чтобы его понять, как читаем мы обычные тексты. Нам не нужно прыгать по выражению в поисках первой операции по старшинству. Также мы избавились от лишних промежуточных переменных (как это было в прошлом посте), коих просто нет. Обозначение и лексическое отделение бинарных операций от унарных требует своей проработки. например, унарную операцию "+" можно представить бинарной при помощи ключевого слова "ADD": ADD 3 в. Или использовать односимвольное обозначение. Более того, такую запись возможно сжимать убирая пробелы между операциями:
Более полная проработка данной идеи будет, надеюсь, позднее. Мы привели Forth к нормальному человеческому виду при этом оставив его простоту.. А теперь пойдем дальше и... приготовьтесь.. избавимся и от "бинарных" операций! Преобразуем наше выражение 3 + 4 × (2 − 1) в:
(В выражении a > b, "a" кладется на стек, а оператор > снимает значение переменной со стека сравнивает это значение с "b") Логическое выражение:
Заметьте: длина нашего выражения не длиннее обычного, куда-то испарились все приоритеты, а читать стало намного приятнее! Еще это позволяет почти один в один транслировать выражение в байт код виртуальной машины, надеюсь преимущества тут совершенно очевидны: высокая скорость трансляции. Предлагаю назвать такой способ записи выражений "прямым", хотя предлагайте свои варианты наименования. Прошу не судить строго. Я пока нахожусь в поиске. Спасибо за внимание. | |||||||||||||||||||||||||||||||||||||||||||||
Размещено в Без категории
Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.
Всего комментариев 221
Комментарии
-
Черкни в личку что за научные разработки, интересно.
Аналогично. Просто экстраполирую свои наблюдения. Работал на паре крупных предприятий своего города(50-200 ПК).
Core i5 стояли только у начальства, у работяг - стыд и срам, в основном целероны разных пошибов. Кое где
вторые пеньки даже проскакивали. И самое забавное, гарантированно не было задач, для которых нужно было
ставить 7 и 10 на слабые машины.
Раньше ради прикола садился на электрички, катался в другие города, боже какая разруха там за областью
словами не передать. Ну и если внимательно интернет пошерстить на эту тему.
Наилучший для результата от этой программы, если таковой нужен. Не верю, а пишу программы без крит багов.
И основная проблема часто отсутствие тестирования. Поэтому первое, о чем приходится заботиться
это наличие тестеров. Более того убеждён, что при ПОЛНОЙ формализации багов нет вовсе.
Быстрый выпуск продуктов по совр. методикам - и есть причина багов. Хорошо продуманная архитектура
и полная аналитика задач перед разработкой сводит их кол-во к нулю. Говорю сейчас очень
простые, понятные вещи. Любой баг - это непредусмотрительность программиста. Разумеется кроме багов
в железе, ОС, компиляторе, но это крайняя редкость(и это не вина программиста). В разработке на время,
с высокой долей вероятности багов не избежать, к сожалению.Запись от Quiet Snow размещена 10.04.2020 в 02:05 
-
Разруха была да. Но в динамике... Если взять самый бедовый район области в начале 2000 и, даже в 10. Две большие разницы. При этом совсем не означает, что сам городок стал процветающим. Единственное отличие в самых маленьких районах не ставили выделенный сервер под БД. Бывал там же и в конторах попроще, да тоже все норм по железу. Вопрос скорее упирался в то, что люди до последнего считали, что в амбарных книгах вести свою кухню лучше.
Сообщение от Quiet Snow
Забаная история из личного опыта: сразу после универа работал в госконторе. И внедряли там у нас Lotus Notes. Разработкой занималась контора в которой стояли Sun`ы. Наворотили они там "красивых" интерфесов с использованием полной палитры цветов.... А у нас карточки 256 цветов.. Презентация уже на наших компах не удалась
Я понимаю о чем вы, но не согласен. Человек не идеален.
Сообщение от Quiet Snow
1. Очень сильно зависит от масштабов задачи. Вот например (из личного опыта). циферка в любой комунальной платежке зависит от 100500 параметров. При этом половина из этих параметров то же рассчетные. И уже условиями на минимум максимум тут не обойдешься, иногда именно надо ситуацию ловить. Да тут проблема в ТЗ. Не все условия задачи может человек описать с ходу. Вот в том же моем опыте бывают ситуации которые возникают один раз в практике работника и без компьютера он ее даже решает не задумываясь (все же моз это уникальная штука). Но вот на момент постановки задачи он ее даже не вспомнит
2. Но и без ТЗ учесть все.... За всем бдить... не знаю. не верю. Уникумы возможно есть.
3. Время важный фактор, если вы пишите не для собственного развлечения. Возьмем, к примеру GIMP. Редактор хороший. Проблемы есть. Давайте напишем свой и без проблем. Сколько потребуется времени так, чтобы потребителю отдать уже совершенный редактор без единой ошибки? Лет 10? А кто вас кормить будет?
4. Вы прям сразу стали ассом программирования? И с момента первой прогаммы вы пишете точно также (хорошо и без багов). Или развиваетесь? Не ужели нет у вас вашего же когда, на который сейчас вы смотрите со словами: "Какой идиот это написал".
5. Вот вы выпустили через 10 лет аналог ГИМП. Открыли "оригинал", а там же 100500 новых полезных штук, причем часть из них требует вмешательство в ядро вашего проекта. И вы еще на 10 лет пропадаете на написание следущей версии.... Но кому ваш идеальный гимп нужен будет?
В общем это не деградация. Это нормально для человека. Нужен баланс качество/время... Через 10 лет аналог сегодняшнего ГИМПа ни кому нужен не будет...
Ну, а про "крупняков" выше я говорил скорее о том, что уже в разработке есть этапы проектирования и тестирования (да и разработка ТЗ), чего у мелких не всегда бывает.
И тут же добавлю и про тестирование. Вы выше упомянули о нем. И ведь тут всплывает еще один минус своих велосипедов: вы вынуждены тратить время на тестирование, отладку, исправление багов, там где уже потрудилось 100500 тестеров. Зачем? Чтоб "идеальный гимп" вышел вообще лет через 20.
Ведь чужие либы это просто один из уровней абстракции. Ведь почему тогда для своего проекта не создать свою ОС, свой язык..... И как определить (если уж ОС и язык брать готовые) какие либы еще можно брать, а в место которых надо велосипед строить.
Т.е. в плане программирования в академических интересах - да вы полностью правы, но из практических нет. И измерять разработку для потребителей по академическим меркам не правильно.Запись от voral размещена 10.04.2020 в 09:01
-
Комментарий модератора 
Прекращаем оффтоп и выяснение отношений. Запись от OwenGlendower размещена 11.04.2020 в 15:15
-
Reverse Polish notation?
Сообщение от CoderHuligan
вроде да, было такое в программировании советских калькуляторов,
но не у всех, например, в МК-85 уже можно было по человечьи писать.
Кликните здесь для просмотра всего текста
CoderHuligan,
то есть, как такое возможно, что 35 лет назад в программируемых калькуляторах
уже можно было писать код в обычной (инфиксной) записи для арифметических операций,
а сейчас у современных программистов XXI века с этим могут быть затруднения?Запись от XLAT размещена 11.04.2020 в 15:23
-
В том то и дело, что нет!
Сообщение от XLAT
Это НЕ обратная польская запись (постфиксная), и НЕ польская запись (префиксная)!
Вижу, что не поняли о чем я..
Сейчас приведу пример польской, обратной польской и обычной инфиксной записи, а потом сравним.
Итак обычная инфиксная:
Польская префиксная:PureBasic 1
5 - r / 3 - 6 * 4 * (2 - 1)
Обратная польская постфиксная:PureBasic 1
- - 5 / r 3 * * 6 4 - 2 1
Мой вариант записи ("прямой"):PureBasic 1
5 r 3 / - 6 4 * 2 1 * -
Кстати тут я исправил неправильный порядок операций из того поста, который Вы цитируете.PureBasic 1
r /3 5- 6 *4 2 -1 * -
Преимущество в том, что на стеке находятся только результаты операций; выражение можно читать слева направо. Точнее это даже не выражение, а последовательность элементарных действий. Она выглядит более естественной, чем постфиксная. Потому что здесь запоминаются только результаты, а не идентификаторы или операции.
1.Значение переменной r кладем на стек.
2. операция /3 берет со стека аргумент и делит 3 на аргумент. Если запись была бы такой: 3/, то произошла бы обратная операция: на аргумент делим 3.
3. 5- вычитает: 5 - арг.
4. 6 - просто кладем число.
5. *4 производим арг * 4.
6. кладем число 2.
7. -1 производим арг - 1 (то есть 2 - 1).
8. * умножаем два верхних аргумента: арг * арг.
9. - вычитаем два верхних аргумента: арг - арг.
Надеюсь внятно объяснил.
У меня другие цели. Мне нужен быстрый загрузчик исходных текстов, быстрый интерпретатор. Поэтому и требуется соответствующая грамматика. Но также я хочу видеть язык, который можно читать как книгу слева направо, избавившись от вложенных конструкций.
Сообщение от XLAT
Запись от CoderHuligan размещена 11.04.2020 в 17:47
-
Может я упустил: а в какой сфере вы видите профит от использования такого языка? Какие задачи он позволит (по замыслу) решать?
Запись от voral размещена 11.04.2020 в 17:55
-
Это абсолютно некоммерческий проект. Коммерция любит все прятать: шифровать коды, исходники прятать, а также постоянно кормить разрабов используя невозможность пользователей их продукта самостоятельно исправлять их недочеты. В целом нужен очень простой язык для любителей создавать свои небольшие проекты с поддержкой графики.
Сообщение от voral
Система состоит из:
1. Ядро. Оно содержит в себе предопределенные примитивы. Также оно загружает исходные тексты или P-код, промежуточный код если мы избрали такую форму загрузки (она более быстра).
2. Исходники, которые хранятся в файлах на диске (может быть совместно с P-кодом).
3. Конфигурационный файл. Ядро на этапе загрузки прежде всего читает этот файл. а в нем любой пользователь, если он, допустим, изменил исходный текст программы, прописывает: нужно ли перекомпилировать модуль/модули или нет. Также там прописывается конфигурация системы, порядок загрузки модулей и пр.
Вот и вся система. Такая система является абсолютно открытой для изменения, улучшения самими пользователями. Простой язык обеспечивает то, что ей могут пользоваться программисты-любители. Исходниками можно будет свободно обмениваться и пр.Запись от CoderHuligan размещена 11.04.2020 в 18:07
-
В польской записи есть логика: сначала что делаем, потом с чем делаем.
У вас операция деления:
1.первый аргумент
2.что делаем
3. на что делим первый аргумент
Вычитание
1. Первый аргумент
2. Второй аргумент
3. Указываем что из второго аргумента вычитаем первый
т.е.:
1 у нас меняется порядок оператора в выражении
2. у нас меняется очередность следования элементов выражения.
И, как контрольный 2 - 1 тут я вообще потерялся. почему - перед единицей?Запись от voral размещена 11.04.2020 в 18:10
-
Я исправил там.
Не меняется!
Тут два типа операций, к примеру:
1. -1 будет (арг - 1), а 1- будет (1 - арг). То есть порядок обеспечивается постановкой знака операции либо перед своим аргументом, либо после. Причем заметьте: это совершенно естественно выглядит: -1 сразу показывает что перед чем должно стоять!Запись от CoderHuligan размещена 11.04.2020 в 18:19
-
Компилируют ПО не для того, чтобы скрыть исходники. (это всего лишь дополнительный эффект). Главная задача компиляции совсем другая.
Сообщение от CoderHuligan
Давно существует понятие Открытого ПО. Пожалуйста, сколько угодно правьте. Там есть и ПО работающее с графикой. Вам люди только благодарны будут если сможете внести реальный вклад. Это уже давно существует и работает.
Сообщение от CoderHuligan
Проста дело очень субъективное. По-этом на любительском уровне языков выбирай не хочу, для поделок (в хорошем смысле). При этом графика требует скорости, а скорость скомпилированого кода будет все равно выше кода, который надо еще проанализировать. Ведь вам придется в рантайме проверять, а не накосячил ли разработчик. И таких проверок будет море. В случае скомпилированного кода - эти проверки не нужны. Они все пройдены.
Сообщение от CoderHuligan
Если вы хотите и без компиляции (видимой) и видеть исходники. Путь уже "открыт": возьмите тот же PHP который доступен в исходниках и посмотрите. Компилируйте в память, там будет кешироваться. Но все равно есть этап компиляции. А ели он есть, то какой смысл усложнять жизнь программисту, ради того, чтоб на синтаксис кода влияло то как работает "процессор со стеком"?
А если завтра выйдет другая архитектура процессора, а нынешний канет в Лету? Будете писать новый язык?Запись от voral размещена 11.04.2020 в 18:20
-
Хм.... Что б это стало естественным, я должен сильно поломать свои привычки.
Сообщение от CoderHuligan
Вообще, если подходить правильно. Надо проводить исследования. (Типа А/Б тестирования). Т.е. опросить или каким то образом дать попробовать порешать задачи потенциальным пользователям вашего языка. И "естественно" и "удобно" будет то, что позволит в среднем быстрее решить задачу.Запись от voral размещена 11.04.2020 в 18:28
-
В основном скорость полученного исполняемого файла. Но примитивы работают с такой же скоростью. Почти.
Не предлагаете ли вы каждому пользователю запастись экземпляром gcc?
Анализ исходника выполняется только на этапе загрузки. Потом уже выполняется P-код, который оперирует прекомпилируемыми примитивами.
На этапе загрузки.
Это монстр, причем заточенный на другие цели.
Перекомпилировать только ядро. Если ядро написано на, допустим, Си, то и совсем легко: за нас уже все сделали.Запись от CoderHuligan размещена 11.04.2020 в 18:47
-
Ну да. Но я еще не решил войдет ли это в язык или нет, ведь придется создавать нечто совсем непривычное.. Тут своя парадигма должна быть.. Как скрестить моську и слона..
Сообщение от voral
Запись от CoderHuligan размещена 11.04.2020 в 18:57
-
Не может быть по определению. Код все равно парсить и проверять надо. Или "примитивы" это нечто другое?
Сообщение от CoderHuligan
А в случае вашего языка ни чего не надо будет? Вот я вот прям ни чего не делая, сразу как вы выпустите первую версию языка. Напишу скажем в блокноте (если это винда) некий код и он сразу начнет работать?
Сообщение от CoderHuligan
Иными словами код для программиста и код для процессора все равно разведены. Зачем тогда упираться как там со стеком работа происходит? Только лишь, ведь будет "ускорен" только анализ кода и больше ни чего. При этом прирост будет не значительным на фоне прочих проверок кода (типы, синтаксис и т.п.)
Сообщение от CoderHuligan
Я не сказал взять его прям, а посмотреть как сделано. По сути то же самое. что вы написали выше. Ну раз у вас тоже самое, ну ок. Только все равно это будет медленее чем компилированный код. Для графики полагаю критичино.
Сообщение от CoderHuligan
Ну т.е. опять же получается, что это отсылка к тому как идет работа со стеком надумана.
Сообщение от CoderHuligan
Перекомпилировать только ядро. Если ядро написано на, допустим, Си, то и совсем легко: за нас уже все сделали.Запись от voral размещена 11.04.2020 в 18:58
-
Уважаемый CoderHuligan,
не позволите ли мне дать вам совет? Написать (под)программу, которая бы переводила обычное арифметическое выражение в тот вид, который вы хотите использовать. С непривычки (не имея опыта) любой человек будет делать кучу ошибок.Запись от wer1 размещена 12.04.2020 в 10:17
-
Тогда лучше использовать обычные выражения..
В связи с этим "прямым" способом, возникают другие проблемы, так как использование стека предполагает и стековую архитектуру передачи параметров и т.п. А я, как писал в первом посте по этой теме, хотел бы уйти от стековой архитектуры и все сделать статическими аргументами, как это и было например в Фортране. Там даже у процедур не было стека возвратов, не было рекурсии и не было вложенных процедур. Хорошо это или плохо другой вопрос. Возможно, что это и перебор(или недобор), но использовать одну общую для всех структуру типа стека во-первых не удобно, а во вторых опасно.
Способ прямой записи арифметического выражения я привел только потому, что мне он кажется просто интересным решением.
Примитивы это блоки кода в ядре, возможно оформленные в виде процедур без параметров, которые выполняют элементарные действия языка программирования.
Ничего не надо кроме ядра. Если кто напишет в блокноте, то эта программа тут же заработает.
Разведены, потому что работаем через VM. А от стека я буду отказываться, потому что это все тупик в программировании..
Хороший вопрос. Насчет графики. У нас есть матрица отображения, по сути обычная матрица. Мы на ней рисуем или выводим на неё спрайты, а потом мы её выводим несколькими функциями API в окно. И это будет гораздо быстрее, чем пользоваться нативными функциями API для рисования. Есть софтверные движки, которые это доказывают. Проблема может возникнуть только при отрисовке на матрице. Но это мы делаем опять же прекомпилированными в ядре примитивами, которые быстры, и которые можно выполнить на асме. Нарисовать линию или точку можно разными примитивами. На уровне языка - команды, которые пользуются услугами соответствующих примитивов.
Да. Посмотрите головной пост: там в самом начале написано: (это заблуждение).
Кстати парсинг обычного выражения при помощи Shunting-yard алгоритма который был предложен Дейкстрой, является очень быстрым. Тут используются два стека, но эти стеки нужны только во время компиляции-интерпретации, а потом мы все компилируем в ячейки регистры. То есть в ран-тайм мы не будем работать со стеком. Чего мне и требуется.
Скорее всего я оставлю инфиксные выражения, так как то, что предложил я в предыдущем посте итак делается в существующих языках.Запись от CoderHuligan размещена 12.04.2020 в 13:07
-
Т.е. все таки нужно. При этом обращу внимание. что в случае с C++. компилятор, в общем случе, нужен только на одном компютере один раз..
Сообщение от CoderHuligan
По сути, то что вы хотите сделать это виртуальная машина.... Такие решения не новы.
Вы прыгаете на другой уровень. У вас тоже будет своего рода "апи"... Дело ведь тут вообще не в этом. А в том, что будет до... А у вас до, будет анализ кода.
Сообщение от CoderHuligan
Вы считаете, что возможно написать "примитивы" на все случаи жизни? Ведь любые движки, либы, фреймворки, это есть аналогия ваших примитивов (точнее методы в них реализованные)....
Сообщение от CoderHuligan
Не важно на сколько он быстрый. В одном случае его нет вообще. А если вы всегда работаете с исходным кодом, вы каждый раз обязаны проверить его валидность
Сообщение от CoderHuligan
Запись от voral размещена 13.04.2020 в 01:03
-
Невозможность самостоятельно исправить проистекает из того, что пользователь не разработчик. Какой-то даже супер простой язык пользователя разработчиком не сделать. Язык - только малая часть того, что нужно знать. Сколько уже можно вам это повторять?Запись от Usaga размещена 13.04.2020 в 07:58
-
Вы это отцам-основателям java скажите..
Пусть это будет еще одним решением, но более простым, без наворотов, которые нужны только ради того, чтобы тебя продолжали считать профи.
Будут свои апи, но они будут независимы от платформы, от windows если это windows, от linux если это linux. Это своеобразная форма защиты: если хозяин переходит все границы разумного сосуществования, то подчиненные бунтуют и начинают строить свою инфраструктуру, свои правила жизни.
Анализ кода, повторю, будет на этапе компиляции в промежуточный код. Прошу обратить внимание на устройство Black Box - системы для Компонентного Паскаля. Возможно для Вас будет понятнее то, что яхочу Вам донести.
А требуется всего несколько сотен примитивов, из которых можно строить уже более емкие сущности уже средствами более высокого уровня.Запись от CoderHuligan размещена 13.04.2020 в 11:15
-
А что им говорить? Полагаю они это знают. Я не говорю, что это решение "плохое". У такого решения есть свои цели и задачи.
Сообщение от CoderHuligan
Мы же говорили про выбор решения с точки зрения скорости выполнения. Т.е. если у вас на входи исходный код, который процессору полностью не понятен, у вас должна быть фаза его анализа. Т.е. в самом скоростном случае будет типа
Т.е. "скормить процессору" в обоих случаях нужно будет подготовленную последовательность байтов.Code 1 2 3
Если Код Изменен То .... Если Обработанного кода нет в "кеше" То ... Выполняем
Не стоит вообще брать во внимание людей с проблемами с самомнением. Пусть это будут их проблемы. И конечно, пусть будет много разных инструментов... Но просто вот вопрос в целесообразности. Вот я (новичок, не программист) взял ваш язык на вооружение. Потом вырос, понял что можно больше своих задач решить автоматизируя. И тут уперся в потолок вашего решения... Т.е. потерял время впустую. Т.к. надо брать другой инструмент и начинать все почти с начала. И вот тут, если ваш язык, будет сильно отличаться от других, это будет еще одним жирным минусом. И тут появляются два фактора:
Сообщение от CoderHuligan
1. Люди кто привыкли думать на несколько шагов вперед, поймут, что декларируемая простота, однажды может их привести в тупик.
2. Люди кто достиг предела, поделятся с теми кто в начале.
Таким образом не проще ли сделать так, чтобы эти же исходники можно было без переделки использовать (например) либо как Java исходники, либо C++, либо любой другой язык. Т.е. в случае Java вы просто делаете более легкий аналог ВМ и все.
Это ни чего не меняет. Ну разве что, вам работы значительно прибавляет. Что приведет еще к более долгому анализу исходного кода на этапе компиляции.
Сообщение от CoderHuligan
В вашей концепции пользователь, что будет запускать? Грубо говоря: "кликать на файл исходника" или "кликать на файл/иконку бинарника"?
Сообщение от CoderHuligan
Запись от voral размещена 13.04.2020 в 11:45
Сообщение от Quiet Snow
