RPC(Radical Processing Core) 소개
소개
이 기사에서는 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 어셈블러를 충분히 알지 못합니다. 사실 내가 구축한 유일한 컴파일러는 BAINF 프로그래밍 언어용 C로 언어의 크기를 감안할 때 매우 쉽게 수행할 수 있었습니다. 따라서 이것은 RPC가 공식적으로 해석된 프로그래밍 언어로 시작된다는 것을 의미했습니다. RPC는 또한 Go를 프로그래밍 언어의 백엔드로 사용할 것입니다. 기록을 위해 yes go를 백엔드로 사용할 수 있습니다. 언어의 디자인은 이 문서의 뒷부분에 표시됩니다. 하지만 이 언어는 당신을 혼란스럽게 하도록 설계되었다는 점을 명심하십시오. RPC는 또한 Go를 프로그래밍 언어의 백엔드로 사용할 것입니다. 기록을 위해 yes go를 백엔드로 사용할 수 있습니다. 언어의 디자인은 이 문서의 뒷부분에 표시됩니다. 하지만 이 언어는 당신을 혼란스럽게 하도록 설계되었다는 점을 명심하십시오. RPC는 또한 Go를 프로그래밍 언어의 백엔드로 사용할 것입니다. 기록을 위해 yes go를 백엔드로 사용할 수 있습니다. 언어의 디자인은 이 문서의 뒷부분에 표시됩니다. 하지만 이 언어는 당신을 혼란스럽게 하도록 설계되었다는 점을 명심하십시오.
- 하위 집합: RPC의 하위 집합은 RPC 템플릿, JSON, XML, GO, FORTRAN을 나타내는 RPCT, RPCJ, RPCX, RPCG, RPCF입니다. 즉, 활성 HTML 코드, JSON 코드, XML 코드, Go 코드 및 심지어 FORTRAN 코드로 RPC를 작성할 수 있고 RPC의 백엔드 엔진이 json, XML 또는 html 파일 등에서 RPC 코드를 구문 분석하고 찾도록 지시할 수 있음을 의미합니다. 그것은 사용될 것입니다.
- 상위 집합: C에는 C++라는 상위 집합이 있고 C++에는 Carbon이라는 상위 집합이 있습니다. RPC는 비슷한 방식으로 작동하고 RPC는 프로그래밍 언어의 수학적 부분이지만 더 만족스러운 RPC++를 갖게 됩니다. 이것은 일반 RPC가 모듈과 클래스를 사용하지 않기 때문에 .RPC++ 파일이 클래스와 모듈 등을 사용할 수 있음을 의미했습니다. 트리는 클래스 역할을 하고 노드는 모듈 역할을 합니다. 그래서
class classname {}당신 대신에RPC_NODE somenodename(){[]}
왜 해석합니까?
RPC의 원래 디자인은 X86 어셈블러로 컴파일되고 작성된 위에서 언급한 대로 되어 있었지만 그 이유는 다음과 같습니다.
- X86 어셈블러 또는 사실상 모든 형태의 어셈블러에 대한 마스터 지식이 없음
- 어셈블러와 같은 언어로 컴파일러를 구축하는 마스터 또는 복잡한 이해가 없음
- 통역사를 만들고 구축하기가 더 쉽습니다.
뭐
모든 프로그래밍 언어에는 두 가지 주요 질문이 있습니다 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는 사용자를 만족시키는 것을 목표로 하지 않으며 작업 부하를 더 어렵게 만드는 반면 오류, 쓰기, 메모, 가져오기, 파일 등의 측면에서 사용자 경험을 조금 더 쉽게 만듭니다. RPC에는 다음과 같은 다양한 파일이 있습니다. 다음과 같습니다
글쎄, 이것은 많은 파일 이름입니다. 왜 그렇습니까? RPC에는 데이터를 선언하고 섹션화하는 다양한 방법이 있습니다. RPC의 데이터는 xml, json, html, template, fortran, go, c++, C, Lua, Trees, Tree nodes, constants 등을 포함하지 않는 경우 .rpc로 직접 참조해야 합니다. 모든 파일은 다른 의미를 가집니다.
- RPC : 원시 RPC 소스 코드 파일
- RPCT: 원시 RPC 템플릿 소스 코드 파일
- RPCX: 원시 RPC XML 템플릿 소스 코드 파일
- RPCJ: 원시 RPC JSON 템플릿 소스 코드 파일
- RPCG: 원시 RPC GO 템플릿 소스 코드 파일
- RPCF: 원시 RPC 포트란 템플릿 소스 코드 파일
- RPCH++: 트리, 노드, 네임스페이스 등에 대해 정의된 원시 RPC 소스 코드 파일
- RPC++: R++와 유사한 RPC++의 상위 집합에 대한 원시 RPC 소스 코드 파일
- RPCCLCCPQ: 급진적 처리 코어 C, Lua, C++, PQ. 이 파일은 매우 어색하므로 설명하겠습니다. 이 유형의 파일은 기본 파일로 실행되지 않으며 기본 파일로 실행할 수 없지만 기본 파일로 실행됩니다.
biRPC 버전. RPC의 기본 파일 또는 특정 파일은 이 언어가 FORTRAN이 아니기 때문에 기본 기능, 네임스페이스, 가져오기, 모듈 등이 있는 트리와 노드를 가질 수 없으며 별도의 파일을 한 번에 모두 보유할 수 있습니다. 이 파일을 사용하면 개별 함수를 호출하여 Lua, C++, C, RPC 코드를 로컬로 로드할 수 있고 트리, 노드, 모듈, 네임스페이스 및 기타 형식의 RPC 코드를 하나의 파일에서 모두 사용할 수 있습니다. 이 파일은 개념 설계이며 이 파일이 얼마나 복잡해야 하고 언어가 그것을 구현하고 수용하도록 얼마나 잘 설계되어야 하는지 때문에 프로그램의 이후 버전까지 구현되지 않을 것입니다. 아래의 예는 파일의 이 슈퍼 세트의 예입니다., - 마지막으로 중요한 것은 일을 쉽게 하는 것입니다. 현재까지 대부분의 프로그래밍 언어는 가장 복잡한 작업을 수행하기 어렵게 만들고 가장 쉬운 작업을 쉽게 만듭니다. 당신은 아마도 "물론 언어가 어떻게 만들어지는가에 대한 해커"라고 말할 것입니다. 글쎄요, 저는 XD 방식으로 만들어지지 않았습니다. 이는 RPC가 프론트엔드의 우선 순위를 지정하고 언어의 쉬운 항목에 우선 순위를 지정하는 대신 더 어렵고 복잡한 항목에 우선 순위를 지정한다는 것을 의미합니다. 여기에는 인코딩 문자열, 디코딩 문자열 등과 같은 것들이 포함됩니다. RPC는 익스플로잇, 그래픽 애플리케이션, 서버 측 애플리케이션, 심지어 화면에 무언가를 인쇄하지 않는 사용자 지정 네트워크와 같은 하드코어 애플리케이션을 구축하기를 원합니다. 이것은 또한 RPC의 구조가 미친 듯이 복잡하고 간단한 응용 프로그램을 작성할 때 얼마나 복잡해지기 때문에 RPC가 새로운 프로그래머에게 권장되지 않거나 권장되는 이유이기도 합니다. 이 언어의 경험 법칙은 애플리케이션이 복잡한 주제여야 한다는 것입니다. 그것이 좋지 않다면 당신은 완전히 목표는 아니지만 LOL 언어의 목표가 아닌 더 많은 작업을 야기하게 될 것입니다. 이 언어를 좋아하는 이유는 복잡한 응용 프로그램을 이렇게 쉽게 만들 수 있고 쉬운 응용 프로그램을 이렇게 복잡하게 만들 수 있는 언어가 세상에 없다고 생각하기 때문입니다. 그것이 좋지 않다면 당신은 완전히 목표는 아니지만 LOL 언어의 목표가 아닌 더 많은 작업을 야기하게 될 것입니다. 이 언어를 좋아하는 이유는 복잡한 응용 프로그램을 이렇게 쉽게 만들 수 있고 쉬운 응용 프로그램을 이렇게 복잡하게 만들 수 있는 언어가 세상에 없다고 생각하기 때문입니다. 그것이 좋지 않다면 당신은 완전히 목표는 아니지만 LOL 언어의 목표가 아닌 더 많은 작업을 야기하게 될 것입니다. 이 언어를 좋아하는 이유는 복잡한 응용 프로그램을 이렇게 쉽게 만들 수 있고 쉬운 응용 프로그램을 이렇게 복잡하게 만들 수 있는 언어가 세상에 없다고 생각하기 때문입니다.
저는 이 질문을 많이 받습니다. 어떤 사람들은 항상 저에게 이미 존재하는 애플리케이션을 구축하는 데 시간을 낭비할 필요가 없다고 말할 것입니다. 그것은 당신이 틀린 곳입니다 내 친구! 단순히 시간 낭비가 아니기 때문에
- 1: 사용됩니다
- 2: 그것은 나의 기술을 향상시킬 것이다
- 3: 그것은 더 탐구 될 것입니다
- 4: 쓰고 이야기할 내용 추가
- 5: 새로운 분야 탐색
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에 데이터 유형을 알려야 함을 의미합니다. 예를 들어 함수가 String 유형의 2개 인수를 보유하기를 원한다고 가정하면 데이터 유형을 구분하고 RPC에 이 데이터 유형이 속한 함수를 알리기 위해
String : String => FunctionName(x,y) {}사용해야 하는 데이터 유형을 선언한 다음 다음을 정의합니다. 변수와 함께 함수 이름. 그래서 당신이 있었다면:=>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
}
Variable Type nameString 유형의 변수를 원하면 입력하십시오 Variable String varname = "data". 전역 변수는 키워드로 만들 수 있는 또 다른 것입니다 Global. :전역 변수는 예를 들어 전역 변수를 정의하려면 Global->Varname : Integer32 = "23191289429034324236746723"매우 간단하게 사용할 수 있도록 정의해야 합니다 .아이디어 구축
프로그래밍 언어가 발전함에 따라 초기 아이디어에서 바뀔 것입니다. RPC 개발을 시작하면 훨씬 더 혼란스럽고 복잡해져서 디자인이 변경된다는 것을 알고 있습니다. 아이디어 전체가 많이 바뀌어서는 안 되지만 여전히 바뀔 것입니다. 우리가 이 언어를 구축하면서 해커를 위한 것 외에는 확실히 좀 더 별난 언어를 만들 계획입니다. 해커를 위한 언어가 이미 존재하지만 더 많은 인코딩과 구조가 쉽지 않은 특정 작업을 수행하는 더 쉬운 방법에 대해 이야기하고 있습니다. 결국 RPC는 모든 쉬운 응용 프로그램을 어렵게 만들고 모든 어려운 응용 프로그램을 쉽게 만드는 언어입니다. 이 아이디어는 개발 단계에서도 동일하게 유지되며 이미지 렌더링, 이미지 주입, 데이터 조작, 알고리즘 구현 등이 모두 훨씬 쉬워질 것이며 이것이 일반적인 아이디어입니다. 우리는 이 시스템을 가능한 한 많이 보존하고 가능한 한 단순하게 유지하고 싶습니다. 이제 우리가 이미 논의한 언어는 매우 급진적이며 우리 모두가 알고 있듯이 언어가 있어야 하는 것과 반대되는 프로그램을 빌드하는 것을 정말 이상하게 만듭니다. 그러나이 전환점에서 나는 또한 오류 시스템을 급진적으로 만들고 싶습니다. 즉, 당신에게 소리를 지르고 복잡한 오류를 제공하지만 오류를 이해하기 쉽습니다. 조건문, 루프, 함수 등을 종료하게 만드는 언어를 알고 있습니다. 그러나이 전환점에서 나는 또한 오류 시스템을 급진적으로 만들고 싶습니다. 즉, 당신에게 소리를 지르고 복잡한 오류를 제공하지만 오류를 이해하기 쉽습니다. 조건문, 루프, 함수 등을 종료하게 만드는 언어를 알고 있습니다. 그러나이 전환점에서 나는 또한 오류 시스템을 급진적으로 만들고 싶습니다. 즉, 당신에게 소리를 지르고 복잡한 오류를 제공하지만 오류를 이해하기 쉽습니다. 조건문, 루프, 함수 등을 종료하게 만드는 언어를 알고 있습니다.PLEASE END그렇지 않으면 무례하다고 말할 것입니까? 오류 시스템이 급진적이 되려면 급진적이어야 한다는 점을 제외하면 우리의 언어는 같은 방식으로 작동합니다. 즉, 모든 조건문에 대해 please go 또는 fucking leave를 문으로 사용할 수 있는 옵션이 있습니다 end. 이 아이디어는 please end 시스템을 중심으로 형성된 것이 아니라 언어 표준에 맞게 자체적으로 형성되었습니다.
마무리 및 결론
RPC는 전문적이고 혼란스러운 언어입니다. 새로운 프로그래머를 위한 언어가 아닌 실험과 깊은 이해를 위한 언어입니다. 말할 것도 없이 RPC는 프로그래밍 언어를 판단하는 방법에 대해 많은 것을 가르쳐줄 것입니다. 적어도 일부 사람들은 이 언어를 사용해보고 그렇지 않다면 대부분의 사람들이 보게 되기를 바랍니다. 이 언어는 내가 인기를 얻으려는 것이 아닙니다. 오히려 탐험가나 다른 사람들의 마음의 영역을 감히 계속 탐험하려는 사람들에게만 사용하고 싶습니다. 이 언어는 저에게 특별합니다. 그 디자인, 개념, 이름, 배너 및 로고는 초기 소스 코드까지 모두 내 것이고 그것이 가장 좋은 부분입니다. 나는 이 언어가 책에 남아 있기를 바라며 계속해서 급진적이라는 메모를 유지합니다. 내가 개발팀을 원하지 않는 이유는 누군가 그것을 바꾸는 것은 이 언어가 어떻게 작동하는지 누군가에게 설명해야 한다는 것을 의미하고 단순히 마음을 나누는 것은 누구도 원하거나 필요로 하는 것이 아니기 때문입니다. 따라서 RPC는 더 많은 정보를 얻기 위해 계속해서 급진적이고 무례하고 귀여운 동시에 계속해서 두 개의 칼을 들고 키보드를 반으로 쪼개고 싶을 때까지 뇌 세포를 자릅니다. 이것이 프로그래밍 언어를 구축하는 것, 즉 창의성입니다. 수년 동안 컴퓨터 과학자들은 항상 다음과 같이 말했습니다. 더 많은 정보를 얻기 위해 당신의 두뇌를 비집고 키보드를 반으로 쪼개고 싶을 때까지 계속해서 두 개의 칼을 들고 두뇌 세포를 자르는 동안 계속 무례하고 귀엽습니다. 이것이 프로그래밍 언어를 구축하는 것, 즉 창의성입니다. 수년 동안 컴퓨터 과학자들은 항상 다음과 같이 말했습니다. 더 많은 정보를 얻기 위해 당신의 두뇌를 비집고 키보드를 반으로 쪼개고 싶을 때까지 계속해서 두 개의 칼을 들고 두뇌 세포를 자르는 동안 계속 무례하고 귀엽습니다. 이것이 프로그래밍 언어를 구축하는 것, 즉 창의성입니다. 수년 동안 컴퓨터 과학자들은 항상 다음과 같이 말했습니다.How can I do this in a different way글쎄, 여기에 내 방식이 있습니다. 지나치게 인기 있는 것을 가져다가 왜곡하여 마치 어셈블러가 포트란과 C를 가진 아기를 낳은 것처럼 기형적인 현대 어셈블러처럼 보이게 하는 방식입니다. 다음 시간까지
~Totally_Not_A_Haxxer 아웃
내 콘텐츠를 계속 보고 싶다면 나를 지원하는 것을 잊지 마세요!
개발 조직
개발 페이지
인스타그램 페이지
https://www.instagram.com/Totally_Not_A_Haxxer

![연결된 목록이란 무엇입니까? [1 부]](https://post.nghiatu.com/assets/images/m/max/724/1*Xokk6XOjWyIGCBujkJsCzQ.jpeg)



































