На пути к непроцедурному языку #1
Запись от CoderHuligan размещена 20.06.2020 в 12:36
Показов 3040
Комментарии 16
|
Предыдущий пост был посвящен пределам удержания и понимания. К этому следовало бы добавить еще и следующее обстоятельство. Практически большинство современных языков предполагает строго заданный порядок параметров в определении и вызовах функций и процедур. Например взять любую функцию, например из стандартной библиотеки Си поиска подстроки в строке:
Самая главная проблема в том, что помимо необходимости помнить назначение параметров, необходимо еще и помнить порядок их расположения!!! А семантически, их порядок расположения - бессмысленен для человека(не для машины)!! Двойная нагрузка на память. Одно дело помнить смысл конкретного параметра, - это легко запоминается семантически, по смыслу функции, и другое дело помнить порядок их расположения! Налицо когнитивный диссонанс с тем, что нужно машине и что нужно человеку. С увеличением числа парамтеров увеличивается и сложность удержания. Думаю многие видели функции windows API. например взять функцию
Например в скриптовом языке TCL некоторые команды реализуются при помощи параметров-ключей. Особенно наглядно это видно по библиотеке TK. Взять команду button с параметрами вроде таких:
Это пошло из консольных управляющих оболочек. И это, конечно большой шаг в правильном направлении. Ключи легко запоминаются, особенно если соблюдается некая система наименований. Здесь не нужно помнить порядок параметров, а только их смысл. Причем их количество также может варьироваться в зависимости от того, какой функционал мы хотим получить от той или иной функции-команды. Наша память не забивается не нужной информацией. Идем далее. Все это хорошо для языков высокого уровня, то есть - не очень быстрых. Для низкоуровневых языков порядок параметров важен. Однако, эту важность требует сама архитектура построения компилятора. Мы привязаны к особенностям конструкции компилятора, а язык также обслуживает компилятор, а не наоборот. Отказ от стековой архитектуры для определенных типов языков(возможно и от проблемной рекурсии) позволил бы создать непроцедурный язык. Повторение некоторых участков кода обеспечивалось бы явным указанием точки возврата в переменной, которая была бы доступна программисту для изменения. Сейчас стек возвратов и параметров практически скрыт от программиста. Каждая "процедура" работала бы только с жестко заданными переменными. Это принесло бы определенные плюсы в скорости работы. Отказ от вложенности (одна из заповедей 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, которая например следует сразу за вызовом, как в обычных языках, это поведение по умолчанию. А можно прыгнуть куда либо еще, а оттуда возвратится сюда же. Возможно получение своеобразных циклов. Естественно, что мы полностью уходим от математических выражений! Этого мы и хотели: математика это другая область науки, которая далека от реального кодинга. Тут важен абсолютный контроль над типами, над ячейками и пр. Выражения скрывают детали, а отсюда ошибки и баги.. | |||||||||||||||||||||||||
Размещено в Без категории
Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.
Всего комментариев 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
-
А я наоборот стремлюсь к как можно большему упрощению ядра языка. Конечно, в этом случае текст программы будет несколько длиннее, но зато код можно гораздо лучше подвергать верификации.
Спасибо за ссылку. В Python более вменяемо сделано. Однако, именованные параметры не то, о чем я говорил. В подобных языках именованные параметры не являются именами ячеек - переменных. Это просто имена, за которыми ничего не стоит. Да, это удобно, но и все на этом.. За каждым именем должна стоять конкретная сущность - не значение, а ячейка памяти, к которой можно явно обращаться, менять её содержимое.Запись от CoderHuligan размещена 20.06.2020 в 17:04
-
Уважаемый CoderHuligan,
спасибо!!! Мы все настолько привыкли к жёстким правилам программирования, что ваши мысли об ином альтернативном программировании некоторые товарищи встречают в штыки. Но я рад вновь вас видеть в полном здравии и прекрасном настроении. Ваши мысли созвучны моим. Не надо быть рабом имеющихся языков программирования. Вершины ещё никто не достиг. Но вы к ней ближе всего...Запись от wer1 размещена 20.06.2020 в 17:32
-
Спасибо, wer1.
Запись от CoderHuligan размещена 20.06.2020 в 18:25
-
Ты зря цепляешь язык 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 здесь неудачен от слова совсем.
Не испытываю с ними никаких проблем. Ты опять свои личные неумения и проблемы выливаешь на всех.
А теперь давай соберем в купе твои идеи из предыдущих блогов.
Ты предлагаешь делать еще и имена переменных и параметров не читаемыми:
а теперь сам возьми и попробуй что-нибудь написать с таким хорошим языком.Code 1
func_01(param_02 = arg_03, param_01 = arg_01);//как-то так это должно выглядеть?
Запись от Croessmah размещена 20.06.2020 в 18:41
-
И получается что то в духе передачи по имени. Это уже пробовали древние в Алголе. Результатом была такая каша, что ни в один из последующих алголо-подобных языков это решили не брать.
Сообщение от Croessmah
Т.е. понаступает на грабли, понабивает шишек и в конце концов изобретет таки C-подобный синтаксис. Тяжел он путь истинных бледнолицых
.Запись от Fulcrum_013 размещена 20.06.2020 в 20:13
-
Кодер вот как тебе объяснить, не сделаешь ты язык, такой, что любой дурной лох неграмотный
сядет и начнёт штопать проги на колене, без подготовки без тех. доки, даже любительского уровня,
не говоря уже о проф, а потом ещё их и допиливать. Это розовые мечты. Для того, чтобы приличный
компилятор + IDE написать, нужно уже быть как минимум проф. спецом и далеко не первого эшалона,
с пятаком толстых проектов.
Это ещё чтобы не с нуля, про иное тут вообще речи нет, на это мало кто сейчас реально способен, ибо
это "форм фактор" программиста, а не формошлёпа и сугубо "библиотечного" афериста.
Для этого и бошка нужна соответствующая. И никакой инструмент её не даст.
Любая аналитика это работа, сколько сделал - такой результат и получаешь. Нихера не сделал
- значит и результата не будет.
Там порядка десяти тысяч функций. И парень походу хочет встрять в рукописное создание обвязки.
Это больно, кровь стынет в жилах, мороз по копчику...
Помолимся за долголетие CoderHuligan.Запись от Quiet Snow размещена 20.06.2020 в 21:11
-
У вас ведь нету никакого опыта программирования. Вот, отсюда и идеи ... несерьёзные.
Сообщение от CoderHuligan
Точно, так же, как все, кто не врачи, хорошо знают как надо лечить.
А обсуждая какое ни будь историческое сражение, все "эксперты" лучше настоящего полководца знают где надо было боевых слонов расставлять.
Вот, ваши рассуждения про языки программирования точно такие и по той же причине.Запись от Curry размещена 20.06.2020 в 22:20
-
Curry, стирая скупую мужскую слезу с небритой щеки, - Золотые слова!Запись от Usaga размещена 21.06.2020 в 06:02
-
Ключевые параметры были уже в макроассемблерах 1960-х, Языках управления заданиями пакетных ОС и т.п.
Запись от politoto размещена 21.06.2020 в 08:04
-
MFC уже давно придумали.
Запись от Croessmah размещена 21.06.2020 в 09:27
-
Знаю. Речь не об этом, а о строгом порядке этих параметров.
И об этом в курсе. вообще, язык Си мой рабочий язык, так что все это мне известно.
А что будет если вместо указателя на haystack передать указатель на needle? Функция любезно скушает это и не подавится. Типы то совпадают.
Эээ - не надо! Про имена переменных я не писал! Имена переменных должны быть информативны, особенно в параметрах.
Ну, да.. А если вспомнить basic, на котором после получаса чтения мана можно было писать, и писали, и кто только это не делал!
А если вспомнить Forth.. Мур изобрел его, когда уже были и Алгол, и Фортран, да и бейсик. И мур программировал на Алголе, но это его не устроило. Вопрос - почему? Да потому, что языки не рождаются из головы, без привязке к практике. Тот же алгол создавался путем мозгового штурма нескольких профессоров академистов, и в итоге почил в бозе. А взять Си - его создавали профи как раз из опыта кодинга реальных вещей. Да и не на ровном месте он вырос, ему предшествовало несколько вариантов..
Поэтому он и живой до сих пор, рабочая лошадка. И Форт живой, так как по сути под капотом виртуальны машин.
Я же тоже не на пустом месте пытаюсь это делать. Была такая книжка: Э Хамби "Программирование таблиц решений" 1973, она есть в нете в свободном доступе. Там всего 90 стр., так что не составит большого труда её прочесть. Последняя глава так и называется - "Непроцедурные языки". Конечно, Хамби не дает готовых рецептов, да и в 73 году их еще не существовало, как не существует и по сей день. Но то, что непроцедурные языки имеют такое же право на существование, как и другие, не подлежит сомнению. Возможно даже, что за ними определенное будущее..
Представление программы табличными методами.. Атомарный тип - ячейка таблицы, а не общеизвестные типы.. Реляционная модель программинга основанная на философии конечных автоматов.. Что-то в этом есть.. И многие уже к этому приближаются, ищут пути..Запись от CoderHuligan размещена 21.06.2020 в 12:53
-
Да никто за пол часа ничего не писал. Кто тебе такую грандиозную чушь наплёл.
Оно изначально было для серьёзных людей от науки и промышленности. И то что позже простой
пользователь мог за 20 минут нарисовать человечка, двигающегося стрелочками как-бы не делало
его ближе к миру программирования.
Не раз уже про это говорил и показывал эти детские неожиданности. Люди азы не могут освоить, сразу
ввысь лезут и у тебя сходные проблемы. Освой азы и ты легко напишешь и свой морской бой и глядишь
чего посерьёзнее. Теряешь время.
И уже этими фортами дырку протёр на форумном полотне, "офигенный язык - офигенный язык", так пиши
на нём если он такой обалденный. Харе сисю мять, бери и пиши. Нам то от баек толку нет.
Про "пулемёты" ты ослов нам своих уже показывал, которые на публику со всей ответственностью
заявили, что они не умеют программировать
. Не надо нам впаривать это фуфло шарлатанское снова.
И все свои позорные книги, не подкреплённые ничем, эти днищевые новаторы могут засунуть себе прямо в жопу.
Хорошо пошутил.Запись от Quiet Snow размещена 21.06.2020 в 14:44
-
Кодер бери исходники PHP переделывай все функции на один единственный параметр ассоциативный массив и будет тебе счастье...
Правда, для начала, погугли мнение народа о решениях, когда делают свои методы в таком стиле.
Можешь даже на нем свой морской бой написать с использование GPU вот пример
Запись от voral размещена 22.06.2020 в 08:49
-
У меня на PHP форум недописанный в столе лежит. Его бы доделать.
Сообщение от voral
Кодер бери исходники PHP переделывай все функции на один единственный параметр ассоциативный массив и будет тебе счастье...
Правда, для начала, погугли мнение народа о решениях, когда делают свои методы в таком стиле.
Можешь даже на нем свой морской бой написать с использование GPU вот примерЗапись от CoderHuligan размещена 22.06.2020 в 09:46
Сообщение от Croessmah
.
. Не надо нам впаривать это фуфло шарлатанское снова.
