На пути к непроцедурному языку #1

Запись от CoderHuligan размещена 20.06.2020 в 12:36
Обновил(-а) CoderHuligan 20.06.2020 в 14:50

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

1	char strstr(const char src, const char *n);

Здесь, заметим, невозможно вызвать эту функцию с другим порядком расположения параметров, например так:

1	strstr(n, src);//так нельзя!!

С каким порядком определили, с таким и надо вызывать. Но тут возникают некоторые проблемы психологического характера.
Самая главная проблема в том, что помимо необходимости помнить назначение параметров, необходимо еще и помнить порядок их расположения!!! А семантически, их порядок расположения - бессмысленен для человека(не для машины)!!
Двойная нагрузка на память. Одно дело помнить смысл конкретного параметра, - это легко запоминается семантически, по смыслу функции, и другое дело помнить порядок их расположения! Налицо когнитивный диссонанс с тем, что нужно машине и что нужно человеку.
С увеличением числа парамтеров увеличивается и сложность удержания. Думаю многие видели функции windows API. например взять функцию

1	Arc(DC, X1, Y1, X2, Y2, X3, Y3, X4, Y4);

В ней 9 параметров. Таких функций там полно. Сами параметры легко запоминаются, так как часть из них просто координаты вывода дуги окружности, однако их порядок должен строго соблюдаться. Можно сказать: на это существуют справочники. Да, но мы когда разговариваем на своем естественном языке редко ими пользуемся, это было бы слишком медленно и непродуктивно.
Например в скриптовом языке TCL некоторые команды реализуются при помощи параметров-ключей. Особенно наглядно это видно по библиотеке TK. Взять команду button с параметрами вроде таких:

Ruby

1	button .b -text "Hello, World!" -command exit

Создаем кнопку и присваиваем ей текст и команду. Однако параметры могут быть и в другом порядке:

Ruby

1	button .b -command exit -text "Hello, World!"

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

Отказ от стековой архитектуры для определенных типов языков(возможно и от проблемной рекурсии) позволил бы создать непроцедурный язык.

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

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

Отказ от вложенности (одна из заповедей Python - линейность лучше вложенности?) упростило бы понимание кода.
Например, команда
mult(a=4, b=3); возвращает в переменной r результат умножения a на b. К слову порядок параметров может быть любым: mult(b=3, a=4);. Чтобы не возникал конфликт имен каждая переменная функции привязывается, допустим к её имени: mult.a, mult.b, mult.r.
При вызове в скобках можно mult. опускать. Он нужен если переменным присваиваются значения вне скобок: mult.a=3;
mult.b=5; mult(g=r);
т.е переменной g мы присвоили результат, который находится в r (в mult.r). А r можно использовать непосредственно.
При этом нам не надо дополнительно копировать ячейки если нам требуется выполнить определенный тип вычислений, например в циклах. и мы всегда знаем что где лежит и как это оттуда "достать".
Идем дальше.
Каждая процедура "знает" также еще одну переменную RET, в которой находится метка возврата. Метку возврата может поставить любая процедура, любой код, и даже сама процедура которая сейчас выполняется.
При этом возможно получение дополнительной гибкости кода и интересных алгоритмических решений.
Т. е. при вызове, допустим, процедуры мы можем сразу же задать точку возврата RET=440, которая например следует сразу за вызовом, как в обычных языках, это поведение по умолчанию. А можно прыгнуть куда либо еще, а оттуда возвратится сюда же. Возможно получение своеобразных циклов.

Естественно, что мы полностью уходим от математических выражений! Этого мы и хотели: математика это другая область науки, которая далека от реального кодинга. Тут важен абсолютный контроль над типами, над ячейками и пр. Выражения скрывают детали, а отсюда ошибки и баги..

Размещено в Без категории

Просмотров 627 Комментарии 16

« О психологических пределах понимания и удержания. Главная страница Сверху или снизу? Сверху!!! »

Всего комментариев 16

Комментарии

	В целом и общем всё это херня, решающаяся нормальной справочной системой(как и многое в принципе). Попытка решить это через задницу, приведёт к усложнению всей системы.
	Запись от Quiet Snow размещена 20.06.2020 в 16:10

Цитата:

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

Вы мало знакомились с другими языками.
Named parameters are supported explicitly in many languages. A non-exhaustive selection of examples includes Ada, C# 4.0+, Ceylon, ColdFusion Markup Language (CFML), Common Lisp, Fortran, IDL, Kotlin, Mathematica, PL/SQL, PowerShell, Python, R, Ruby, Scala, Smalltalk, Swift[1] and Visual Basic.
Прежде чем изобретать что то своё, нужно вначале узнать, а что уже есть.

Запись от Curry размещена 20.06.2020 в 16:51 Curry вне форума

Цитата:

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

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

Цитата:

Вы мало знакомились с другими языками.

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

Запись от CoderHuligan размещена 20.06.2020 в 17:04 CoderHuligan вне форума

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

Запись от wer1 размещена 20.06.2020 в 17:32 wer1 вне форума

	Спасибо, wer1.
	Запись от CoderHuligan размещена 20.06.2020 в 18:25

Ты зря цепляешь язык C. В языке C вообще имена параметров к объявлению никак не относятся.
Это не говоря о том, что имя переменной в месте вызова с именем параметра функции никак вообще не связано.
И слава Богу! А то получили бы большую кучу жидкого.

Можно было бы сделать как-то так:

1	strstr(.n = "abc", .src="def");

Но, как сказано выше, объявление на имена параметров не завязано, и вполне может быть два подобных объявления:

1 2	char strstr(const char src, const char n); char strstr(const char n, const char str);

Оба они объявляют одну и ту же функцию.

И как теперь распознать эти параметры?
А еще в объявлении имена параметров необязательны.
И с именами в определении могут не совпадать.

То есть, пример на языке C здесь неудачен от слова совсем.

Цитата:

Думаю многие видели функции windows API.

Не испытываю с ними никаких проблем. Ты опять свои личные неумения и проблемы выливаешь на всех.

А теперь давай соберем в купе твои идеи из предыдущих блогов.
Ты предлагаешь делать еще и имена переменных и параметров не читаемыми:

Код:

func_01(param_02 = arg_03, param_01 = arg_01);//как-то так это должно выглядеть?

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

Запись от Croessmah размещена 20.06.2020 в 18:41 Croessmah вне форума

Обновил(-а) Croessmah 20.06.2020 в 18:42

Цитата:

Сообщение от Croessmah

А теперь давай соберем в купе твои идеи из предыдущих блогов.
Ты предлагаешь делать еще и имена переменных и параметров не читаемыми:

Код:

func_01(param_02 = arg_03, param_01 = arg_01);//как-то так это должно выглядеть?

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

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

Запись от Fulcrum_013 размещена 20.06.2020 в 20:13 Fulcrum_013 вне форума

Обновил(-а) Fulcrum_013 20.06.2020 в 20:20

Цитата:

но зато код можно гораздо лучше подвергать верификации.

Кодер вот как тебе объяснить, не сделаешь ты язык, такой, что любой дурной лох неграмотный
сядет и начнёт штопать проги на колене, без подготовки без тех. доки, даже любительского уровня,
не говоря уже о проф, а потом ещё их и допиливать. Это розовые мечты. Для того, чтобы приличный
компилятор + IDE написать, нужно уже быть как минимум проф. спецом и далеко не первого эшалона,
с пятаком толстых проектов.
Это ещё чтобы не с нуля, про иное тут вообще речи нет, на это мало кто сейчас реально способен, ибо
это "форм фактор" программиста, а не формошлёпа и сугубо "библиотечного" афериста.
Для этого и бошка нужна соответствующая. И никакой инструмент её не даст.
Любая аналитика это работа, сколько сделал - такой результат и получаешь. Нихера не сделал
- значит и результата не будет.

Цитата:

Не испытываю с ними никаких проблем.

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

Помолимся за долголетие CoderHuligan.

Запись от Quiet Snow размещена 20.06.2020 в 21:11 Quiet Snow вне форума

Цитата:

Сообщение от CoderHuligan

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

У вас ведь нету никакого опыта программирования. Вот, отсюда и идеи ... несерьёзные.

Точно, так же, как все, кто не врачи, хорошо знают как надо лечить.

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

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

Запись от Curry размещена 20.06.2020 в 22:20 Curry вне форума

	Curry, стирая скупую мужскую слезу с небритой щеки, - Золотые слова!
	Запись от Usaga размещена 21.06.2020 в 06:02

	Ключевые параметры были уже в макроассемблерах 1960-х, Языках управления заданиями пакетных ОС и т.п.
	Запись от politoto размещена 21.06.2020 в 08:04

	Цитата: И парень походу хочет встрять в рукописное создание обвязки. MFC уже давно придумали.
	Запись от Croessmah размещена 21.06.2020 в 09:27

Цитата:

В языке C вообще имена параметров к объявлению никак не относятся.

Знаю. Речь не об этом, а о строгом порядке этих параметров.

Цитата:

Это не говоря о том, что имя переменной в месте вызова с именем параметра функции никак вообще не связано.
И слава Богу!

И об этом в курсе. вообще, язык Си мой рабочий язык, так что все это мне известно.

Цитата:

И как теперь распознать эти параметры?

А что будет если вместо указателя на haystack передать указатель на needle? Функция любезно скушает это и не подавится. Типы то совпадают.

Цитата:

Ты предлагаешь делать еще и имена переменных и параметров не читаемыми:

Эээ - не надо! Про имена переменных я не писал! Имена переменных должны быть информативны, особенно в параметрах.

Цитата:

Ну, да.. А если вспомнить basic, на котором после получаса чтения мана можно было писать, и писали, и кто только это не делал!
А если вспомнить Forth.. Мур изобрел его, когда уже были и Алгол, и Фортран, да и бейсик. И мур программировал на Алголе, но это его не устроило. Вопрос - почему? Да потому, что языки не рождаются из головы, без привязке к практике. Тот же алгол создавался путем мозгового штурма нескольких профессоров академистов, и в итоге почил в бозе. А взять Си - его создавали профи как раз из опыта кодинга реальных вещей. Да и не на ровном месте он вырос, ему предшествовало несколько вариантов..
Поэтому он и живой до сих пор, рабочая лошадка. И Форт живой, так как по сути под капотом виртуальны машин.
Я же тоже не на пустом месте пытаюсь это делать. Была такая книжка: Э Хамби "Программирование таблиц решений" 1973, она есть в нете в свободном доступе. Там всего 90 стр., так что не составит большого труда её прочесть. Последняя глава так и называется - "Непроцедурные языки". Конечно, Хамби не дает готовых рецептов, да и в 73 году их еще не существовало, как не существует и по сей день. Но то, что непроцедурные языки имеют такое же право на существование, как и другие, не подлежит сомнению. Возможно даже, что за ними определенное будущее..
Представление программы табличными методами.. Атомарный тип - ячейка таблицы, а не общеизвестные типы.. Реляционная модель программинга основанная на философии конечных автоматов.. Что-то в этом есть.. И многие уже к этому приближаются, ищут пути..

Запись от CoderHuligan размещена 21.06.2020 в 12:53 CoderHuligan вне форума

Цитата:

Ну, да.. А если вспомнить basic, на котором после получаса чтения мана можно было писать, и писали

Да никто за пол часа ничего не писал. Кто тебе такую грандиозную чушь наплёл.
Оно изначально было для серьёзных людей от науки и промышленности. И то что позже простой
пользователь мог за 20 минут нарисовать человечка, двигающегося стрелочками как-бы не делало
его ближе к миру программирования.
Не раз уже про это говорил и показывал эти детские неожиданности. Люди азы не могут освоить, сразу
ввысь лезут и у тебя сходные проблемы. Освой азы и ты легко напишешь и свой морской бой и глядишь
чего посерьёзнее. Теряешь время.
И уже этими фортами дырку протёр на форумном полотне, "офигенный язык - офигенный язык", так пиши
на нём если он такой обалденный. Харе сисю мять, бери и пиши. Нам то от баек толку нет.

Цитата:

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

Про "пулемёты" ты ослов нам своих уже показывал, которые на публику со всей ответственностью
заявили, что они не умеют программировать

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

Цитата:

Я же тоже не на пустом месте пытаюсь это делать.

Хорошо пошутил.

Запись от Quiet Snow размещена 21.06.2020 в 14:44 Quiet Snow вне форума

Обновил(-а) Quiet Snow 21.06.2020 в 15:01

Кодер бери исходники PHP переделывай все функции на один единственный параметр ассоциативный массив и будет тебе счастье...

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

Можешь даже на нем свой морской бой написать с использование GPU вот пример

Запись от voral размещена 22.06.2020 в 08:49 voral вне форума

Цитата:

Сообщение от voral

У меня на PHP форум недописанный в столе лежит. Его бы доделать.

Запись от CoderHuligan размещена 22.06.2020 в 09:46 CoderHuligan вне форума

Сообщение форума

Отменить изменения

Архив
< Март 2021
Вс	Пн	Вт	Ср	Чт	Пт	Сб
21	22	23	24	25	26	27
28	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30	31	1	2	3