Введение в RPC (ядро радикальной обработки)

Введение

В этой статье я расскажу о моем реальном языке программирования, который находится в разработке, под названием RPC. RPC был чем-то, что люди путали с Remote Procedure Call, я могу заверить вас, что RPC не является удаленным вызовом процедуры в этом случае. Вместо этого RPC — это язык программирования под названием Radical Processing Core. Этот язык получил свое название из-за того, насколько радикальным и необычным он был задуман. В этой статье также подробно рассказывается о математике, фронтенд-инжиниринге, почему, как и, самое главное, что.

Понимание почему

Многие разработчики мечтают создать свой собственный язык программирования для развлечения, однако очень немногие на самом деле выполняют эту миссию. Причина в том, что создать язык программирования сложно. Дизайн, который может скрываться за самыми сложными частями языка, делает его действительно сложным. Особенно, если вы планируете сделать его скомпилированным. Моя миссия была другой, я не хотел создавать язык для развлечения, я просто хотел сделать язык, который делал сложные вещи простыми, а простые - сложными, если в этом есть смысл. RPC был исключительно моим собственным языком, я не черпал вдохновение из какого-либо языка, я не использовал никаких дизайнерских идей, не черпал вдохновение ни от какого человека, вещи, предмета, языка, концепции и т. д. Этот дизайн был исключительно моим собственным. Причина, по которой RPC был таким, каким он был и каким получился его дизайн, заключалась именно в том, что он не предназначался на самом деле для конкретной группы людей, только для меня. Причина этого в том, что если бы я черпал вдохновение из другого языка, я твердо верил, что на тот момент это было бы просто расширением текущего языка, как C# для Java. Прежде чем я перейду к ответу «почему», давайте рассмотрим общую основу языка.

Концепция: Концепция RPC заключалась в том, чтобы сделать простые приложения сложными, а сложные — простыми. Это означало, что если вы хотите что-то напечатать на экране, вам придется создавать собственные потоки как для ввода, так и для вывода с использованием RPC. Это также означало, что такие приложения, как драйверы ядра, загрузчики, устройства чтения и записи памяти, преобразователи и даже что-то столь сложное, как UNIX SOCKETS, было бы легче реализовать, чем что-то выводить.
Дизайн: каждый язык особенный по-своему, но RPC был другим, он был БОЛЬШЕ, чем просто особенным, он был БОЛЬШЕ, чем просто сложным. RPC был разработан, чтобы трахать вашу голову так сильно, что это могло бы ввести вас в ментальную спираль на несколько дней и сбить вас с толку. Несмотря на то, что ошибки интерпретатора легко понять, сам RPC таковым не является. У него будет более математическая реализация, заставляющая вас использовать символы tan, cos, e и т. Д., Просто это сделает что-то столь же простое, как снова выходной поток. Этот язык должен был вас так запутать, что он заставит вас задуматься о том, почему вы выбрали карьеру программиста. RPC был языком, который должен был быть создан сырым и скомпилирован с использованием ассемблера X86, однако проблема сводилась к уровню навыков разработчика (меня). Я недостаточно или даже близко знаю ассемблер, особенно ассемблер X86, чтобы понять, как создать свой собственный компилятор. На самом деле единственный компилятор, который я когда-либо создавал, был на C для языка программирования BRAINF, что было очень легко сделать, учитывая размер языка. Таким образом, это означало, что RPC официально начинался как интерпретируемый язык программирования. RPC также будет использовать Go в качестве серверной части для языка программирования, поскольку, как известно, yes go можно использовать в качестве серверной части. Дизайн языка будет показан позже в этой статье. Но имейте в виду, что язык был разработан, чтобы возиться с вами.
Подмножества: подмножествами RPC могут быть RPCT, RPCJ, RPCX, RPCG, RPCF, что означает RPC Templating, JSON, XML, GO, FORTRAN. Это означает, что вы сможете писать RPC в активном HTML-коде, JSON-коде, XML-коде, Go-коде и даже FORTRAN-коде и указывать серверному движку RPC анализировать и находить RPC-код в файлах json, XML или html и т. д. что бы использовали.
Надмножества: C имеет надмножество, называемое C++, а C++ имеет надмножество, называемое Carbon. RPC будет работать аналогичным образом, RPC будет иметь RPC++, который будет более удовлетворительной, но математической частью языка программирования. Это означало, что файлы .RPC++ могли использовать классы и модули и т. д., поскольку обычный RPC не использует модули и классы. Деревья действовали как классы, а узлы действовали как модули. Итак, вместо class classname {} у вас есть RPC_NODE somenodename(){[]}

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

Почему интерпретируется?

Первоначальный проект RPC должен был быть, как сказано выше, скомпилирован и написан на ассемблере X86, но вот почему.

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

Несмотря на то, что интерпретаторы легче создавать, они на самом деле делают программу немного медленнее. Однако с RPC это не такая большая проблема. Причина, по которой я также выбрал интерпретатор, особенно написанный на Go, заключается в том, что он действительно расширит мои навыки и понимание языков и машин в целом, а также языка программирования Go.

Что

С каждым языком программирования возникают два основных вопроса, и это what and why. Ну мы уже поняли зачем сделали так что именно RPC станет. RPC станет языком, решающим несколько проблем в современных программах.

Математика: по какой-то причине современные языки программирования, которые не были разработаны такими организациями, как Google, Amazon или Apple, имеют очень-очень плохую реализацию математики. Поскольку RPC — это язык, который должен был быть более надежным и продвинутым, но в некоторых случаях менее сложным, математическая реализация в RPC будет намного более интенсивной. Стандартные COS, TAN, URAND, RAND и т. д. будут по-прежнему использоваться, но также будет больше пользовательских реализаций.
Ошибки компилятора и/или системы предложений: большинство языков, таких как Go, имеют странную систему ошибок, несмотря на то, что система паники построена хорошо, им не хватает многих описаний в их ошибках, особенно чем более сложным вы идете. Такие языки, как python, говорят, что вы сделали слишком большой отступ, не сообщая вам о предлагаемом столбце, и они даже не дают вам прямую строку, иногда она находится выше. Так что RPC будет действовать как его механизм шаблонов. Например, если вы сделаете ошибку в строке 15 своего кода, он выведет и выведет 5 строк до и 5 строк после этого кода. Причина, по которой это будет существовать, состоит в том, чтобы дать вам общую область исключений или где произошла ошибка, чтобы убедиться, что вы не потеряетесь в случае, если интерпретатор выдаст ошибку. Если ошибка компилятора связана с чем-то вроде потока или чего-то сложного, например, побитовых операторов, то вы, скорее всего, получите математическую ошибку с глубоким пониманием того, что именно пошло не так, и время от времени предлагать, чем это заменить. Например, скажем, вы создаете программу из 7 строк, и в ней есть синтаксическая ошибка в строке 4, столбце 2 со странным символом. RPC будет выводить подобные операторы.

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

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

.rpc, .rpct, .rpcx, .rpcj, .rpcg, .rpcf, .rpc++, .rpch++, .rpm, .RPCCLCCPQ

Ну, это много имен файлов, почему? Что ж, в RPC есть много способов объявления и секционирования данных. Данные RPC должны быть напрямую связаны с .rpc, если они не включают xml, json, html, template, fortran, go, c++, C, Lua, деревья, узлы дерева, константы и т. д. Все файлы имеют разное значение

RPC: необработанный файл исходного кода RPC.
RPCT: необработанный файл исходного кода шаблона RPC.
RPCX: необработанный файл исходного кода шаблона RPC XML.
RPCJ: необработанный файл исходного кода шаблона RPC JSON
RPCG: необработанный файл исходного кода шаблона RPC GO.
RPCF: необработанный файл исходного кода шаблона RPC Fortran
RPCH++: необработанный файл исходного кода RPC, определенный для деревьев, узлов, пространств имен и т. д.
RPC++: необработанный файл исходного кода RPC для расширенного набора RPC++, аналогичного R++.
RPCCLCCPQ: ядро радикальной обработки C, Lua, C++, PQ. Этот файл был очень неудобным, поэтому позвольте мне объяснить. Этот тип файла не будет работать как основной файл и не может работать как основной файл, но будет работать как bi версия RPC. Основные файлы RPC или определенные файлы не могут иметь просто деревья и узлы с основными функциями, пространствами имен, импортом, модулями и т. д., поскольку этот язык не является FORTRAN, он позволяет хранить все сразу в отдельном файле. Этот файл позволяет вам загружать код Lua, C++, C, RPC локально, вызывая отдельные функции, а также позволяет вам использовать деревья, узлы, модули, пространства имен и другие формы кода RPC в одном файле. Этот файл является концептуальным проектом и не будет реализован до более поздних версий программы из-за того, насколько сложным должен быть этот файл и насколько хорошо должен быть разработан язык для его реализации и принятия. Пример ниже является примером этого супернабора файлов.,

Наконец, что не менее важно, нужно относиться к вещам проще: на сегодняшний день большинство языков программирования усложняют выполнение самых сложных задач, а самые простые — легко. Вы, вероятно, скажете: «Конечно, хакскер, как устроены языки», ну, видите ли, я не устроен таким образом XD. Это означает, что вместо того, чтобы отдавать предпочтение внешнему интерфейсу и простым вещам в языке, RPC будет отдавать приоритет более сложным и сложным вещам. Это включает в себя такие вещи, как строки кодирования, строки декодирования и т. д. RPC хочет, чтобы вы создавали жесткие приложения, такие как эксплойты, графические приложения, приложения на стороне сервера и даже настраиваемые сети, а не выводили что-либо на экран. По этой же причине RPC не рекомендуется начинающим программистам или будет рекомендован из-за безумно сложной структуры RPC и того, насколько сложным он станет при написании простых приложений. Эмпирическое правило этого языка состоит в том, что ваше приложение ДОЛЖНО быть сложной темы. Если это не так, вы будете вызывать больше работы, которая не совсем цель, но совершенно не цель языка LOL. Мне нравится этот язык, потому что я не чувствую, что существует язык, который позволяет так легко создавать сложные приложения и так сложно создавать простые приложения.

Какой смысл создавать свой собственный язык

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

1: Он будет использоваться
2: Это улучшит мои навыки
3: Будет изучено больше
4: Добавляет больше, чтобы писать и говорить о
5: Исследует новые области

Кроме того, почему бы не быть в стороне от очень немногих, которые на самом деле создают свой собственный язык программирования, делая его другим? если вы посмотрите на большинство современных языков, таких как C#, Ruby, C, Crystal, C++, Pascal, Fortran, Haskell, Perl, RAKU, R и т. д., вы заметите, что все они имеют общий синтаксис или вдохновение, одинаковое с языками, такими как Z#, будь то построен на Java, C++, Ruby и т. д., у языка все еще есть история происхождения. RPC нет, RPC исследует новые более сложные методы и из-за того, что у него нет вдохновения, ставит его на совершенно особое место. Время, которое будет вложено в этот язык, будет действительно большим, но также будет медленным. Этот язык, над которым я буду работать один, у меня не будет команды разработчиков, как у go, C#, Java, Crystal и т. д. Это на самом деле усложняет мою работу, потому что мне придется реализовывать все в одиночку, что не самое худшее, но ставит туда груз. В любом случае, дело в том, что в команде или не в команде я получаю опыт, и смысл в том, чтобы продолжать увеличивать свой опыт.

Понимание того, как работает RPC

Теперь, когда мы закончили с введением и вводной информацией, мы можем перейти к тому, как именно работает RPC, его синтаксису, системе ошибок и т. д. Теперь имейте в виду, что RPCT — единственное реальное свидетельство использования RPC, однако язык находится в разработке, поскольку эта статья пишется и скоро будет выпущена в 2023 году. Ниже приведены общие темы и то, как с ними справляется RPC.

Типы данных: типы данных строятся очень специфично и могут иметь полные имена. Большинство языков заставляют вас печатать int, bool, string, int32, uint32, uint16, int16 etc.... ну, RPC заставляет вас печатать полностью, чтобы точно указать, что он делает. например, если вам нужна переменная с целочисленным типом данных, вам нужно будет указать Variable Integer varname = 1;, если вам нужно логическое значение, вы должны ввести Variable Boolean varname = true, если вам нужны целые числа без знака, вы должны Variable Unsigned_Integer32 Varname = 8913671371276782367862347823423478 и т. д.
Методы и аргументы метода. Методы определены немного странно и используют серию стрелок и символов для определения их типов данных, аргументов и т. д. Если вы хотите объявить функцию или метод в RPC, в RPC есть правило, называемое TFAL ( Type First Argument Last ), что означает, что вы должны сообщить RPC тип данных перед запуском списка аргументов. Так, например, если вы хотите, чтобы функция содержала 2 аргумента, оба типа String, вы должны ввести String : String => FunctionName(x,y) {} После того, как вы объявите типы данных, вы должны использовать : для их разделения и =>, чтобы сообщить RPC, к какой функции относятся эти типы данных, после этого вы определяете имя функции вместе с переменными. Итак, если бы у вас было String : Integer => FunctionName(x,y) , X был бы типа String, а Y был бы типа Integer. То же самое следует для возвращаемых типов. =› сообщает RPC, что вы хотите инициировать переменные, символ -› сообщает RPC, что вы хотите возвращать переменные. Итак, если вам нужна функция, которая принимает 3 аргумента и возвращает один и тот же тип, вы должны написать функцию следующим образом.

Integer : Integer : Integer => Function(x, y, z) -> Integer32 {
      Variable Integer32 Varname = x+y+z
      <-Varname
}

Эта функция принимает 3 аргумента типа данных Integer, которые берутся x, y, z. Переменная Varname определяется как результат сложения всех этих данных вместе. Затем вы используете <-Varname для возврата переменной. Обратите внимание, что функция возвращает Integer32, потому что -> Integer32 .

Переменные. Переменные не так уж и дурацки, и на самом деле их довольно легко понять. Чтобы сделать переменную локальной, просто введите Variable Type name, поэтому, если вам нужна переменная типа String, введите Variable String varname = "data" . Глобальные переменные — это еще одна вещь, которую вы можете создать с помощью ключевого слова Global. Глобальные переменные должны быть определены с помощью : Так, например, если вы хотите определить глобальную переменную, вы должны использовать Global->Varname : Integer32 = "23191289429034324236746723" Довольно просто, верно?

Это самая простая идея RPC.

Создание идеи

По мере развития языка программирования его первоначальная идея будет меняться. Я знаю, что когда я начну разработку, RPC станет намного более запутанным и сложным, что означает, что дизайн изменится. Все вокруг идеи не должно сильно измениться, но все же изменится. По мере того, как мы будем создавать этот язык, я планирую создать язык, который, конечно, будет немного более странным, но для хакеров. Язык для хакеров уже существует, но я говорю о большем кодировании и структурах, более простых способах выполнения определенных задач, которые на самом деле не проще. В конце концов, RPC — это язык, который делает каждое простое приложение сложным, а любое сложное — легким. Эта идея останется неизменной даже на этапах разработки. Рендеринг изображений, внедрение изображений, манипулирование данными, алгоритмическая имплементация и т. д. будут намного проще, и это общая идея. Мы хотим максимально сохранить эту систему и сделать ее максимально простой. Теперь язык, как мы уже обсуждали, является суперрадикальным и делает действительно странным создание программ, которые, как мы все знаем, противоположны тому, чем должны быть языки. Однако с этим поворотным моментом я также хочу сделать систему ошибок радикальной, что означает, что она будет кричать на вас и давать вам сложные, но простые для понимания ошибки. Вы знаете язык, который заставляет вас заканчивать условные выражения, циклы, функции и т. д. на PLEASE END и скажет вам, что вы невежливы, если вы этого не сделаете? Что ж, наш язык работает точно так же, за исключением того, что вы должны быть радикальными, чтобы система ошибок была радикальной. Это означает, что для каждого условного выражения у вас есть возможность использовать либо «пожалуйста, иди», либо «блять, уходи» в качестве оператора end. Эта идея не была сформирована вокруг системы «пожалуйста, конец», а скорее была сформирована как отдельная вещь, чтобы соответствовать языковому стандарту.

Завершение и заключение

RPC — это язык специфики и путаницы. Это язык не для начинающих программистов, язык, предназначенный для экспериментов и глубокого понимания. Не говоря уже о том, что RPC научит вас многому в оценке языка программирования. Я очень надеюсь, что этот язык по крайней мере некоторые люди попробуют, и если не надеюсь, что большинство людей в конечном итоге его увидят. Этот язык не является чем-то, что я собираюсь сделать популярным, я бы предпочел оставить его только исследователям или, скорее, людям, которые осмеливаются продолжать исследовать сферы разума других людей. Этот язык особенный для меня, его дизайн, его концепции, его имя, его баннер и логотип, вплоть до начального исходного кода, все мое, и это лучшая часть в нем. Я надеюсь, что этот язык останется в книгах, и он сохранит свою память, чтобы оставаться радикальным. Причина, по которой я не хочу иметь команду разработчиков, заключается в том, что если кто-то ее изменит, это означает, что я должен кому-то объяснить, как работает этот язык, а просто делиться мнениями — это не то, что кому-то нужно или нужно. Поэтому RPC будет продолжать оставаться радикальным, грубым и милым одновременно, поскольку он выискивает из вашего мозга дополнительную информацию и продолжает брать два ножа и нарезать клетки мозга, пока вы не захотите сломать клавиатуру пополам. Вот что такое создание языка программирования, творчество. В течение многих лет ученые-компьютерщики всегда делали заявление How can I do this in a different way ну вот мой способ, мой способ взять что-то слишком популярное и исказить это так сильно, что это выглядит как уродливый современный ассемблер, как если бы у ассемблера был ребенок с фортраном и C. До следующего раза

~Totally_Not_A_Haxxer вне игры

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

Введение в RPC (ядро радикальной обработки)

Организация развития

Страница разработки

Страница в инстаграме

Наличное приложение

Венмо

Похожие вопросы