Форум программистов, компьютерный форум, киберфорум
CoderHuligan
Войти
Регистрация
Восстановить пароль
Рейтинг: 2.33. Голосов: 3.

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

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

Предыдущий пост был посвящен пределам удержания и понимания. К этому следовало бы добавить еще и следующее обстоятельство.
Практически большинство современных языков предполагает строго заданный порядок параметров в определении и вызовах функций и процедур.
Например взять любую функцию, например из стандартной библиотеки Си поиска подстроки в строке:
C
1
char *strstr(const char *src, const char *n);
Здесь, заметим, невозможно вызвать эту функцию с другим порядком расположения параметров, например так:
C
1
strstr(n, src);//так нельзя!!
С каким порядком определили, с таким и надо вызывать. Но тут возникают некоторые проблемы психологического характера.
Самая главная проблема в том, что помимо необходимости помнить назначение параметров, необходимо еще и помнить порядок их расположения!!! А семантически, их порядок расположения - бессмысленен для человека(не для машины)!!
Двойная нагрузка на память. Одно дело помнить смысл конкретного параметра, - это легко запоминается семантически, по смыслу функции, и другое дело помнить порядок их расположения! Налицо когнитивный диссонанс с тем, что нужно машине и что нужно человеку.
С увеличением числа парамтеров увеличивается и сложность удержания. Думаю многие видели функции windows API. например взять функцию
C
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, которая например следует сразу за вызовом, как в обычных языках, это поведение по умолчанию. А можно прыгнуть куда либо еще, а оттуда возвратится сюда же. Возможно получение своеобразных циклов.

Естественно, что мы полностью уходим от математических выражений! Этого мы и хотели: математика это другая область науки, которая далека от реального кодинга. Тут важен абсолютный контроль над типами, над ячейками и пр. Выражения скрывают детали, а отсюда ошибки и баги..
Размещено в Без категории
Просмотров 404 Комментарии 16
Всего комментариев 16
Комментарии
  1. Старый комментарий
    Аватар для Quiet Snow
    В целом и общем всё это херня, решающаяся нормальной справочной системой(как и многое в принципе).
    Попытка решить это через задницу, приведёт к усложнению всей системы.
    Запись от Quiet Snow размещена 20.06.2020 в 16:10 Quiet Snow вне форума
  2. Старый комментарий
    Аватар для Curry
    Цитата:
    Практически большинство современных языков предполагает строго заданный порядок параметров в определении и вызовах функций и процедур.
    Вы мало знакомились с другими языками.
    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 вне форума
  3. Старый комментарий
    Аватар для CoderHuligan
    Цитата:
    Попытка решить это через задницу, приведёт к усложнению всей системы.
    А я наоборот стремлюсь к как можно большему упрощению ядра языка. Конечно, в этом случае текст программы будет несколько длиннее, но зато код можно гораздо лучше подвергать верификации.
    Цитата:
    Вы мало знакомились с другими языками.
    Спасибо за ссылку. В Python более вменяемо сделано. Однако, именованные параметры не то, о чем я говорил. В подобных языках именованные параметры не являются именами ячеек - переменных. Это просто имена, за которыми ничего не стоит. Да, это удобно, но и все на этом.. За каждым именем должна стоять конкретная сущность - не значение, а ячейка памяти, к которой можно явно обращаться, менять её содержимое.
    Запись от CoderHuligan размещена 20.06.2020 в 17:04 CoderHuligan вне форума
  4. Старый комментарий
    Уважаемый CoderHuligan,
    спасибо!!! Мы все настолько привыкли к жёстким правилам программирования, что ваши мысли об ином альтернативном программировании некоторые товарищи встречают в штыки. Но я рад вновь вас видеть в полном здравии и прекрасном настроении. Ваши мысли созвучны моим. Не надо быть рабом имеющихся языков программирования. Вершины ещё никто не достиг. Но вы к ней ближе всего...
    Запись от wer1 размещена 20.06.2020 в 17:32 wer1 вне форума
  5. Старый комментарий
    Аватар для CoderHuligan
    Спасибо, wer1.
    Запись от CoderHuligan размещена 20.06.2020 в 18:25 CoderHuligan вне форума
  6. Старый комментарий
    Аватар для Croessmah
    Ты зря цепляешь язык C. В языке C вообще имена параметров к объявлению никак не относятся.
    Это не говоря о том, что имя переменной в месте вызова с именем параметра функции никак вообще не связано.
    И слава Богу! А то получили бы большую кучу жидкого.

    Можно было бы сделать как-то так:
    C
    1
    
    strstr(.n = "abc", .src="def");
    Но, как сказано выше, объявление на имена параметров не завязано, и вполне может быть два подобных объявления:
    C
    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
  7. Старый комментарий
    Аватар для Fulcrum_013
    Цитата:
    Сообщение от 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
  8. Старый комментарий
    Аватар для Quiet Snow
    Цитата:
    но зато код можно гораздо лучше подвергать верификации.
    Кодер вот как тебе объяснить, не сделаешь ты язык, такой, что любой дурной лох неграмотный
    сядет и начнёт штопать проги на колене, без подготовки без тех. доки, даже любительского уровня,
    не говоря уже о проф, а потом ещё их и допиливать. Это розовые мечты. Для того, чтобы приличный
    компилятор + IDE написать, нужно уже быть как минимум проф. спецом и далеко не первого эшалона,
    с пятаком толстых проектов.
    Это ещё чтобы не с нуля, про иное тут вообще речи нет, на это мало кто сейчас реально способен, ибо
    это "форм фактор" программиста, а не формошлёпа и сугубо "библиотечного" афериста.
    Для этого и бошка нужна соответствующая. И никакой инструмент её не даст.
    Любая аналитика это работа, сколько сделал - такой результат и получаешь. Нихера не сделал
    - значит и результата не будет.

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



    Помолимся за долголетие CoderHuligan.
    Запись от Quiet Snow размещена 20.06.2020 в 21:11 Quiet Snow вне форума
  9. Старый комментарий
    Аватар для Curry
    Цитата:
    Сообщение от CoderHuligan Просмотреть комментарий
    За каждым именем должна стоять конкретная сущность - не значение, а ячейка памяти, к которой можно явно обращаться, менять её содержимое.
    У вас ведь нету никакого опыта программирования. Вот, отсюда и идеи ... несерьёзные.

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

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

    Вот, ваши рассуждения про языки программирования точно такие и по той же причине.
    Запись от Curry размещена 20.06.2020 в 22:20 Curry вне форума
  10. Старый комментарий
    Аватар для Usaga
    Curry, стирая скупую мужскую слезу с небритой щеки, - Золотые слова!
    Запись от Usaga размещена 21.06.2020 в 06:02 Usaga вне форума
  11. Старый комментарий
    Ключевые параметры были уже в макроассемблерах 1960-х, Языках управления заданиями пакетных ОС и т.п.
    Запись от politoto размещена 21.06.2020 в 08:04 politoto вне форума
  12. Старый комментарий
    Аватар для Croessmah
    Цитата:
    И парень походу хочет встрять в рукописное создание обвязки.
    MFC уже давно придумали.
    Запись от Croessmah размещена 21.06.2020 в 09:27 Croessmah на форуме
  13. Старый комментарий
    Аватар для CoderHuligan
    Цитата:
    В языке C вообще имена параметров к объявлению никак не относятся.
    Знаю. Речь не об этом, а о строгом порядке этих параметров.
    Цитата:
    Это не говоря о том, что имя переменной в месте вызова с именем параметра функции никак вообще не связано.
    И слава Богу!
    И об этом в курсе. вообще, язык Си мой рабочий язык, так что все это мне известно.
    Цитата:
    И как теперь распознать эти параметры?
    А что будет если вместо указателя на haystack передать указатель на needle? Функция любезно скушает это и не подавится. Типы то совпадают.
    Цитата:
    Ты предлагаешь делать еще и имена переменных и параметров не читаемыми:
    Эээ - не надо! Про имена переменных я не писал! Имена переменных должны быть информативны, особенно в параметрах.
    Цитата:
    Кодер вот как тебе объяснить, не сделаешь ты язык, такой, что любой дурной лох неграмотный
    сядет и начнёт штопать проги на колене, без подготовки без тех. доки, даже любительского уровня,
    не говоря уже о проф, а потом ещё их и допиливать.
    Ну, да.. А если вспомнить basic, на котором после получаса чтения мана можно было писать, и писали, и кто только это не делал!
    А если вспомнить Forth.. Мур изобрел его, когда уже были и Алгол, и Фортран, да и бейсик. И мур программировал на Алголе, но это его не устроило. Вопрос - почему? Да потому, что языки не рождаются из головы, без привязке к практике. Тот же алгол создавался путем мозгового штурма нескольких профессоров академистов, и в итоге почил в бозе. А взять Си - его создавали профи как раз из опыта кодинга реальных вещей. Да и не на ровном месте он вырос, ему предшествовало несколько вариантов..
    Поэтому он и живой до сих пор, рабочая лошадка. И Форт живой, так как по сути под капотом виртуальны машин.
    Я же тоже не на пустом месте пытаюсь это делать. Была такая книжка: Э Хамби "Программирование таблиц решений" 1973, она есть в нете в свободном доступе. Там всего 90 стр., так что не составит большого труда её прочесть. Последняя глава так и называется - "Непроцедурные языки". Конечно, Хамби не дает готовых рецептов, да и в 73 году их еще не существовало, как не существует и по сей день. Но то, что непроцедурные языки имеют такое же право на существование, как и другие, не подлежит сомнению. Возможно даже, что за ними определенное будущее..
    Представление программы табличными методами.. Атомарный тип - ячейка таблицы, а не общеизвестные типы.. Реляционная модель программинга основанная на философии конечных автоматов.. Что-то в этом есть.. И многие уже к этому приближаются, ищут пути..
    Запись от CoderHuligan размещена 21.06.2020 в 12:53 CoderHuligan вне форума
  14. Старый комментарий
    Аватар для Quiet Snow
    Цитата:
    Ну, да.. А если вспомнить basic, на котором после получаса чтения мана можно было писать, и писали
    Да никто за пол часа ничего не писал. Кто тебе такую грандиозную чушь наплёл.
    Оно изначально было для серьёзных людей от науки и промышленности. И то что позже простой
    пользователь мог за 20 минут нарисовать человечка, двигающегося стрелочками как-бы не делало
    его ближе к миру программирования.
    Не раз уже про это говорил и показывал эти детские неожиданности. Люди азы не могут освоить, сразу
    ввысь лезут и у тебя сходные проблемы. Освой азы и ты легко напишешь и свой морской бой и глядишь
    чего посерьёзнее. Теряешь время.
    И уже этими фортами дырку протёр на форумном полотне, "офигенный язык - офигенный язык", так пиши
    на нём если он такой обалденный. Харе сисю мять, бери и пиши. Нам то от баек толку нет.

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

    Цитата:
    Я же тоже не на пустом месте пытаюсь это делать.
    Хорошо пошутил.
    Запись от Quiet Snow размещена 21.06.2020 в 14:44 Quiet Snow вне форума
    Обновил(-а) Quiet Snow 21.06.2020 в 15:01
  15. Старый комментарий
    Кодер бери исходники PHP переделывай все функции на один единственный параметр ассоциативный массив и будет тебе счастье...

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

    Можешь даже на нем свой морской бой написать с использование GPU вот пример
    Запись от voral размещена 22.06.2020 в 08:49 voral вне форума
  16. Старый комментарий
    Аватар для CoderHuligan
    Цитата:
    Сообщение от voral Просмотреть комментарий
    Кодер бери исходники PHP переделывай все функции на один единственный параметр ассоциативный массив и будет тебе счастье...

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

    Можешь даже на нем свой морской бой написать с использование GPU вот пример
    У меня на PHP форум недописанный в столе лежит. Его бы доделать.
    Запись от CoderHuligan размещена 22.06.2020 в 09:46 CoderHuligan вне форума
 
КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2020, vBulletin Solutions, Inc.