브레인퍽

1. 개요

2. 명칭

3. 명령어

4. 메모리 구조

5. 예제

5.1. Hello, world!

++++++++++
[>+++++++>++++++++++>+++>+<<<<-]
>++.>+.+++++++..+++.>++++++++++++++.------------.<<+++++++++++++++.>.+++.------.--------.>+.

5.1.1. 해설

1. +++++ +++++
   포인터가 가리키는 주소(0)의 값을 10 증가시켰다. 메모리의 초깃값은 0이므로, 최종적으로 포인터가 가리키는 값에 10이 들어간다.
2. [>+++++ ++ >+++++ +++++ >+++ >+ <<<<
   포인터가 가리키는 주소(0)를 하나씩 증가시키며( > (1) > (2) > (3) > (4) ) 각 주소의 값을 7, 10, 3, 1씩 증가시킨다. 이후 다시 포인터가 가리키는 주소를 0으로 감소시킨다.
3. -]
   포인터가 가리키는 주소(0)의 값을 1 감소시킨 후, 그 값이 0이 아닐 경우 2.의 [ 로 돌아간다. 즉 10회 루프문이 되며, 메모리의 1~4번째 주소에는 각각 70, 100, 30, 10의 값이 들어가게 된다.
4. >++ . → H
   포인터가 가리키는 주소를 1 증가시키고(1), 주소의 값(=70)에 2를 더한 후(=72) 그 값을 아스키 코드로 출력한다. 72에 대응되는 아스키 코드 문자는 H이다.
5. >+ . +++++ ++ .. +++ . → ello
   포인터가 가리키는 주소를 1 증가시키고(2), 주소의 값(=100)에 1을 더한 후(=101) 한 번 출력, 7을 더한 후(=108) 두 번 출력, 또다시 3을 더한 후(=111) 한 번 출력한다. 101, 108, 108, 111에 대응되는 아스키 코드 문자는 ello이다.
6. >++++++++++++++.------------.<<+++++++++++++++.>.+++.------.--------.>+. → , World!
   4~5와 같다. 포인터가 가리키는 주소를 이리저리 바꾸고 그 주소의 값에 숫자를 더하고 빼 가면서 문자를 출력한다. 여기서 , World!가 출력되는 것.

5.2. Hello, world! 노가다 출력

[-] H
++++++++++ ++++++++++ ++++++++++ ++++++++++ ++++++++++
++++++++++ ++++++++++ ++ .
[-] e
++++++++++ ++++++++++ ++++++++++ ++++++++++ ++++++++++
++++++++++ ++++++++++ ++++++++++ ++++++++++ ++++++++++ + .
[-] l 2
>++
[<
++++++++++ ++++++++++ ++++++++++ ++++++++++ ++++++++++
++++++++++ ++++++++++ ++++++++++ ++++++++++ ++++++++++
++++++++.
[-]
>-]< o
++++++++++ ++++++++++ ++++++++++ ++++++++++ ++++++++++
++++++++++ ++++++++++ ++++++++++ ++++++++++ ++++++++++
++++++++++ +.
[-]
++++++++++ ++++++++++ ++++++++++ ++++++++++ ++++.
[-] Space
++++++++++ ++++++++++ ++++++++++ ++.
[-] w
++++++++++ ++++++++++ ++++++++++ ++++++++++ ++++++++++
++++++++++ ++++++++++ ++++++++++ ++++++++++ ++++++++++
++++++++++ +++++++++.
[-] o
++++++++++ ++++++++++ ++++++++++ ++++++++++ ++++++++++
++++++++++ ++++++++++ ++++++++++ ++++++++++ ++++++++++
++++++++++ +.
[-] r
++++++++++ ++++++++++ ++++++++++ ++++++++++ ++++++++++
++++++++++ ++++++++++ ++++++++++ ++++++++++ ++++++++++
++++++++++ ++++.
[-] l
++++++++++ ++++++++++ ++++++++++ ++++++++++ ++++++++++
++++++++++ ++++++++++ ++++++++++ ++++++++++ ++++++++++
++++++++.
[-] d
++++++++++ ++++++++++ ++++++++++ ++++++++++ ++++++++++
++++++++++ ++++++++++ ++++++++++ ++++++++++ ++++++++++.
[-] !
++++++++++ ++++++++++ ++++++++++ +++.
[-] Lf
++++++++++.
[-]

6. 구현의 난점

• 메모리 셀 크기, 메모리 용량 문제
  보통 셀 하나의 크기는 8 bit또는 32 bit로 최소 30,000개 이상을 가지는 것이 일반적인데, 이는 단순히 우어반 뮐러가 처음 어셈블리로 제작한 첫 구현체가 3만 개를 기준으로 했기 때문이다.
• 부호 있는 자료형, 오버플로우 문제
  각 셀에 들어가는 숫자 자료형이 C 언어로 치면 unsigned인지, signed인지도 구현체마다 제법 다른 편이다.
  특히 오버플로우 같은 경우, 어느 자료형이냐에 따라 값이 급격하게 바뀔 수 있기 때문에 일부러 오버플로우를 일으켜서 숫자를 줄이는 등의 트릭이 구현체에 따라 통하지 않을 수도 있음을 의미한다.
  구현체에 따라 특정한 자료형이 없어 이러한 오버플로 현상이 아예 존재하지 않거나, 0에서 1을 빼면 그냥 예외가 나버리는 경우도 존재한다.
• 메모리 방향 문제
  보통 브레인퍽의 메모리 주소는 0부터 시작해 (방향을 굳이 정한다면) 오른쪽으로 계속 증가하는 형식인데, 주소가 0일 때 <를 어떻게 처리할지도 구현체별로 꽤나 다르다.
  대부분의 경우 음의 메모리 주소는 구현하지 않으며, 예외를 일으키거나 (시계처럼 끝까지 돌아서) 마지막 메모리 주소로 이동하는 경우도 존재한다.
• EOF 처리
  만약 , 명령을 수행하던 중 EOF를 받았다면 어떻게 처리할지 역시 구현체별로 다르다.
  이게 왜 중요하냐 하면, 임의 길이의 문자열을 입력받아 거꾸로 뒤집는(reverse) 프로그램 등을 구현할 때, 어디까지 읽어야 하는지를 결정할 수 있어야 하는데, 보통 유닉스 스타일로는 어느 임의의 음의 정수 도 EOF가 될 수 있지만, 보통 -1을 사용한다.
  그런데 우어반 뮐러의 첫 구현체는 이런 거 없이 그냥 EOF가 반환되면 현재 포인터가 가리키고 있는 셀의 값을 변경하지 않고 그대로 두었다.
  이후 많은 구현체들이 같은 방식을 채용했지만, 상당히 많은 구현체들이 이런 방식을 사용하지 않으며, 주로 0을 반환한다. 앞서 말한 대로 -1을 반환하는 경우도 드물게 존재한다.
  EOF는 (구현을 대충 했다는 가정하에) 특히 구현 언어에 영향을 많이 받는 편인데, C로 구현한 경우 -1을 준다든가 Python으로 구현된 경우 내장 input() 함수를 사용했다면 EOF를 마주치면 EOFError 예외가 발생하는 편이다.

7. 기타

• 놀랍게도 업그레이드 버전으로 2개의 포인터를 쓰는 더블퍽(Doublefuck)이라는 놈이 존재하며, 같은 원리의 프로그래밍 언어로 Ook!가 존재한다. Ook!는 브레인퍽과 명령 체계가 완전히 똑같아서 브레인퍽-Ook! 컨버전 프로그램도 존재한다.
  이 외에도 많은 브레인퍽 기반의 esolang이 존재한다. 자세한 내용은 난해한 프로그래밍 언어 문서의 Misa 및 Nyaruko 참조. 그 외에도 일본에는 죠죠러를 위한 해당 언어 기반의 esolang, 케모노 프렌즈 팬덤을 위한 해당 언어 기반의 esolang도 존재한다. 최근에는 아예 요 녀석에서 따온 언어도 등장했다. 이것도 등장했다!

• SeeU의 반도의 흔한 이별노래는 가사 전체가 하나의 브레인퍽 코드로 되어 있다.

• 여기서 브레인퍽 프로그램을 실행할 수 있다. 여기서는 #가 중단점으로 사용된다.

• 한 양덕은 마인크래프트의 레드스톤으로 브레인퍽 컴퓨터를 구현했다. 이 외에도 찾아보면 마인크래프트로 브레인퍽 인터프리터 구현 작업 영상들이 좀 있다.

• 다른 양덕이 Geometry Dash로 구현한 브레인퍽 실행기도 있다. Geometry Dash의 근본적인 한계로 인해 프로그램을 저장할 수도 없고 6분 정도의 시간 제한이 있지만 그래도 대단한 수준이다.

• 언어 자체가 매우 간단하여 인터프리터 구현이 쉽다.

• 놀랍게도 VS Code용 brainfuck 신택스 하이라이터가 존재한다!
  
• 브레인퍽으로 코딩된 현존하는 프로그램중 가장 복잡한 수준의 프로그램은 콘웨이의 생명 게임( #) , 아스키 아트로 만델브로 집합과 하노이의 탑을 구현한 것이다. #

• 한 성인용품[5]이 이 프로그래밍 언어를 떠올리게 한다는 평이 있다.