Literate 프로그래밍을 확장하시나요?

Question

인사말.나는 지금 Literate 프로그래밍을 조금 살펴보고 있는데, 그 뒤에 숨은 아이디어가 정말 마음에 듭니다.기본적으로 코드에 대한 작은 문서를 작성하고 설계 결정, 모듈을 둘러싼 코드, 모듈의 내부 작업, 설계 결정에서 비롯된 가정 및 결론, 잠재적 확장 등을 최대한 기록합니다. 이 모든 것이 기록될 수 있습니다. tex를 사용하여 좋은 방법으로 내려갑니다.물론 첫 번째 요점은 다음과 같습니다.그것은 문서입니다.최신 상태로 유지되어야 하지만 그렇게 나쁘지는 않습니다. 변경 사항에 대한 정당성이 있어야 하고 이를 기록할 수 있기 때문입니다.

그러나 Literate 프로그래밍은 어떻게 더 큰 수준으로 확장됩니까?전반적으로 Literate 프로그래밍은 여전히 ​​텍스트일 뿐입니다.물론 사람이 읽을 수 있는 텍스트이지만 여전히 텍스트이므로 대규모 시스템을 따라가기가 어렵습니다.예를 들어, >>를 사용하고 컴파일 단계를 함께 연결하기 위한 몇 가지 마법을 사용하도록 컴파일러의 많은 부분을 재작업했습니다. 왜냐하면 일부 "x.register_follower(y);y.register_follower(z);y.register_follower(a);..."는 정말 다루기 힘들어졌고 x >> y >> z >> a로 변경하면 이것도 한계점에 있음에도 불구하고 조금 더 좋아졌습니다.

그렇다면 Literate 프로그래밍은 어떻게 더 큰 시스템으로 확장됩니까?그렇게 하려고 노력하는 사람이 있나요?

내 생각은 LP를 사용하여 이벤트 스트림을 사용하여 서로 통신하는 구성 요소를 지정하고 graphviz의 하위 집합을 사용하여 이러한 모든 것을 함께 연결하는 것입니다.넷에서 문서(데이터 흐름 다이어그램)를 추출하고 거기에서 코드를 매우 잘 생성할 수 있으므로 이는 LP에 대한 매우 자연스러운 확장입니다.그거에 대해서 어떻게 생각해?

-- 테타.

Answer 1

훌륭한 질문입니다.유능한 프로그래밍에 대한 동기는 결코 사라지지 않을 것이지만, 유동적으로 다뤄져야 한다고 생각합니다.이는 "독자들에게 휴식을 주고, 당신이 하려는 일을 교육하라"는 뜻입니다.나는 이것이 "당신의 코드를 정말 장황하게 만드세요"를 의미한다고 생각하지 않습니다.

즉, 독자는 자신이 이미 알고 있는 내용에 따라 약간의 노력을 기울여야 합니다.아마도 코드는 이해할 가치가 있으며, 아무것도 무료로 제공되지 않습니다.

또한 이는 단지 읽을 수 있는 코드를 만드는 것 이상의 의미를 갖는다고 생각합니다.누군가가 코드를 읽는 이유는 아마도 변경이 필요하기 때문일 것입니다.필요할 수 있는 변경 사항을 예상하고 필요한 경우 이를 수행하는 방법을 알려주어야 합니다.

Answer 2

'물리 기반 렌더링'이라는 책 (pbrt.org) 내가 아는 대규모 문학적 프로그래밍의 가장 좋은 예입니다.책은 완전한 렌더링 시스템을 구현하며 책 텍스트와 레이트레이서 코드는 모두 동일한 "소스"에서 생성됩니다.

실제로 나는 Doxygen과 같은 시스템을 사용하고 그 기능을 모두 파고들어 활용하는 것이 본격적인 "학식 있는" 프로그래밍보다 낫다는 것을 발견했습니다.교과서, 교육자료.

Answer 3

나는 약 15년 ​​전에 WEB으로 프로그래밍을 좀 했습니다.최근에는 Wiki에서 코드를 추출하고 Squeak Smalltalk 환경에서 문서를 생성해 보았습니다.

상향식 부분은 TDD/BDD 프레임워크에서 문서를 생성하여 비교적 잘 처리할 수 있지만 LP는 독자에게 코드를 설명하는 데 중점을 둡니다.

몇 가지 문제가 있습니다:

• 전달하려는 이야기는 이해관계자/독자마다 다릅니다.
• 대부분의 환경에서 프로젝트 구조는 스토리텔링에 필요한 구조가 아닙니다.
• 연속적인 개선/공개에 대한 지원이 누락되었습니다.
• 그림에 대한 텍스트 지원 외에도 필요합니다.
• 소스 제어 시스템의 주석을 통해 시스템 구축 방법을 파악할 수 있습니다.이야기는 시스템이 어떻게 구축될 수 있었는지에 대한 것이어야 합니다(완벽한 사후 통찰력을 바탕으로).

LP가 대규모 시스템에서 작동하려면 Wiki나 개체 브라우저보다 더 나은 IDE 지원이 필요합니다.

Answer 4

"전반적으로, 문맹 프로그래밍은 여전히 ​​텍스트 일뿐입니다."

거짓.

다이어그램은 괜찮습니다.

내 생각은 LP를 사용하여 이벤트 스트림을 사용하여 서로 통신하는 구성 요소를 지정하는 것입니다.

그것은 단지 건축일 뿐이고 괜찮습니다.

인터넷에서 문서(데이터 흐름 다이어그램)를 추출하고 거기에서 코드를 생성할 수도 있습니다.그거에 대해서 어떻게 생각해?

데이터 흐름 다이어그램은 실제로 상세한 코드를 생성하는 데 그다지 도움이 되지 않습니다.이는 정확한 정보 소스가 아닌 편리한 요약입니다.

LaTex와 같은 좋은 작성 도구는 문서의 다이어그램을 인코딩할 수 있습니다.아마도 문서의 다른 부분에서 다이어그램으로 가는 방법을 알아낼 수 있을 것입니다.

결론

장기적으로는 텍스트 요약으로 다이어그램을 생성하는 것이 더 좋습니다.

왜?

다이어그램에서는 의도적으로 세부 정보를 생략합니다.다이어그램은 요약 또는 개요입니다.그러나 코드 소스로서 다이어그램은 형편없습니다.공급하기 위해 모두 세부 사항이 있으면 다이어그램이 매우 복잡해집니다.

그러나 다른 LP 마크업의 도식적 요약은 제대로 작동할 것입니다.

Answer 5

pbrt 컴퓨터 과학 졸업생(그리고 나)의 교육을 위해 글을 읽을 수 있는 스타일로 작성된 물리적 기반 레이 트레이서이며, 적당한 규모의 시스템입니다.비전문가 프로그래머로서 이 수준의 문서화는 프로그램이 무엇을 하는지, 왜 하는지를 이해하는 데 매우 중요합니다.

또한 Java로 작성된 연구 렌더러에 액세스할 수 있습니다. 이는 잘 작성되었지만 상대적으로 문서화되지 않았지만 몇 가지 SIGGRAPH 논문에 대한 것입니다.이것은 또한 상대적으로 이해하기 쉽지만 저자에게도 접근할 수 있습니다.

나는 또한 사용했다 이미지J 그리고 기본 Java의 내부를 살펴보았습니다. 기본 철학에 대한 아이디어 없이는 따라가기가 매우 어렵습니다.

요약하자면, 누군가가 그것을 잘 할 시간을 찾을 수 있다면 읽고 쓰는 프로그래밍은 훌륭하다고 생각하며 이는 교육 환경에서 사용될 가능성이 높습니다.상용코드 제작에서는 보기 힘들다.나는 코드가 완전히 자체적으로 문서화될 수 있다는 생각에 회의적입니다.

Answer 6

읽고 쓸 수 있는 프로그래밍의 이면에 있는 아이디어는 코드 전체에 주석을 얹는 것이 아니라 문서 전체에 코드를 뿌린다는 점에서 문서에 중점을 두는 것입니다.

이는 본질적으로 다른 철학이며 긴 변수 이름, 네임스페이스 및 클래스와 같은 차이점은 철학에 영향을 미치지 않습니다.Literate 프로그래밍은 의미 있는 변수 이름을 옹호합니다.

코드에 대한 문서의 기본 비율은 코드 크기에 따라 선형적으로 확장되므로 더 큰 시스템으로 확장됩니다.

Answer 7

Literate 프로그래밍은 긴 변수와 함수 이름이 불가능했던 시대에 개발되었습니다.이 때문에 코드는 실제로 읽기 쉽지 않았습니다.

분명히 그 이후로 많은 일이 일어났습니다.

오늘날의 세계에서 코드 자체는 문서이므로 "자체 문서화 코드"라는 용어입니다. 실현은 일련의 의견이나 외부 문서가 기본 코드와 동기화 될 수 없다는 것입니다.따라서 오늘날 많은 프로그래머의 목표는 다른 사람이 읽을 수 있는 방식으로 코드를 작성하는 것입니다.

Answer 8

NanoLP를 사용해 보세요 - LP 확장 가능 도구는 다양한 문서 형식(Markdown, OpenOffice, Creole, TeX, Asciidoc 등)을 지원하고 다른 LP 프로그램 가져오기, 템플릿 작성 등을 지원합니다.사용자는 예를 들어 VCS에서 특별한 가져오기를 수행하기 위해 Python에서 자신의 명령/매크로를 추가할 수 있습니다.http://code.google.com/p/nano-lp