문맹 프로그래밍이 주류가 아닌 이유는 무엇입니까? [닫은]

라이트 레이트 프로그래밍 에는 좋은 이상이 있습니다. 이것이 주류가 아니라고 생각하는 이유는 무엇입니까? 배송에 실패했기 때문입니까?

나는 처음 Knuth의 저서에서 그것을 보았고 그것이 깔끔하게 보인다고 생각했습니다. 그런 다음 문학적 프로그래밍 디스플레이를 사용하여 프로그램에서 무슨 일이 일어나고 있는지 이해하려고 시도했는데,보기보다 힘들었습니다. 프로그램 목록을 살펴 보는 데 너무 익숙했을지 모르지만 혼란스러워 보였습니다.

그런 다음 소스 코드를 살펴본 결과 저를 끌었습니다. 프로그램 텍스트와 컴파일러가 보았던 것과의 관련성이 적어 완전히 새로운 방식으로 프로그램을 작성하는 법을 배워야하며 해당 이점이 없습니다.

또한 사람들은 실제로 Y를 수행 할 때 코드가 X를 수행한다는 길고 설득력있는 주장을 쓸 수 있으며 오해의 소지가있는 의견에 부딪 쳤습니다. 나는 코드를 읽는 것에 대한 애정을 개발하여 코드가 상당히 일찍 수행되는 것을 보았습니다. Literate Programming은 그 반대의 견해입니다.

나는 네트워크 효과를 비난 할 것 입니다. 다른 사람들이 귀하의 코드와 문서를 편집하려면이를 이해할 수 있어야합니다.

cweb / noweb과 같은 사람들로부터 멀어지게합니다. 프로젝트를 사용하고있는 프로그래밍 언어 위에서 TeX와 프로그램 고유의 구문을 배울 필요가 있기 때문입니다. 이것은 특히 TeX가 처음에 그렇게 큰 수학 조판을 필요로하지 않는 경우에 엄청난 시간 낭비로 볼 수 있습니다. (그리고 많은 응용 프로그램 프로그래머에게는 실제로 필요하지 않습니다.) 대신 Visual Studio의 XML 주석과 같은 것을 선호합니다. 왜냐하면 이미 유명하고 잘 정립되어 있기 때문입니다.

문해력있는 프로그래밍이 시작된 곳은 과학 / 통계 컴퓨팅에 있으며 대부분의 프로그래머는 수학, CS 또는 통계학에서 상당한 교육 (일명 PhD)을 받았기 때문에 이미 LaTeX에 익숙합니다. 그들이 작성한 문서에는 TeX로 가장 잘 쓰여진 복잡한 공식이 많을 가능성이 높고 R로 프로그래밍 할 가능성이 높습니다. SWeave에 대해 알고있는 R 프로그래머의 비율은 확실히 cweb에 대해 알고있는 C 프로그래머의 비율

나는 공부하는 동안 90 년대 후반에 Literate Programming의 개념에 매료되었고, 여전히 프로그래밍과 조판에 대한 Knuths의 접근 방식에 흥미가 있습니다. 최선의 것 외에는 아무것도 할 수 없습니다.

Knuth가 설계 한 Literate Programming 시스템은 즉각적으로 눈에 띄는 것 이상을 수행했습니다. 즉 Knuths 소스 문서에서 생성 된 코드 생성 도구, 즉 표준 Pascal에서 생성 된 기본 프로그래밍 언어의 많은 단점을 극복했습니다.

표준 파스칼을 사용해 보지 못한 운이 좋은 사람들을 위해 여기 몇 가지 주요 특징이 있습니다.

• 단일 패스 컴파일러를 쉽게 사용할 수 있도록 언어 사양에 따르면 모든 선언은 특정 순서로 이루어져야한다고합니다. wikipedia 페이지에서 : "각 프로 시저 또는 함수는 고유 한 goto 레이블, 상수, 유형, 변수 및 기타 프로 시저 및 함수의 선언을 가질 수 있으며 모두 순서대로되어 있어야합니다." 즉, 소스 파일에서 사물을 논리적으로 그룹화 할 수 없습니다 .
• 일반 C보다 문자열 처리가 더 지루했습니다.
• 식별자는 임의의 길이를 가질 수 없습니다.
• 더 이상 기억할 수없는 더 많은 것들.

이 모든 것들은 기본적으로 Knuth가 더 나은 프로그래밍 언어가 필요하다는 것을 의미했으며 (따라서 발명했습니다) 파스칼을 어셈블리 언어로 사용했습니다.

대부분의 현대 언어는 많은 노력없이 이러한 작업을 수행 할 수 있으므로 Literate Programming이 해결해야하는 작업의 대부분을 제거합니다.

또한 현대 언어는 코드 자체에 더 많은 생각을 할 수 있도록 표현력이 뛰어납니다.

그래서 무엇이 남았습니까? 다음은 소스 코드에서 문서의 조판 양식을 생성 할 수있는 능력, 그리고 오늘날 존재한다.

Java 런타임 API는 아마도 현재 사용 가능한 가장 큰 Literate Programming 중 하나 일 것입니다 (코드가 실제로 표시되지는 않지만 Java가 처음부터 오픈 소스 인 경우에는 가능할 것임). 예를 들어 http://download.oracle.com/javase/6/docs/api/java/util/Collection.html 의 컬렉션 프레임 워크 프레젠테이션을 참조하십시오.

.NET 및 기타 주류 프로그램에도 비슷한 시스템이 있다고 생각합니다.

내가 90 년대에 문맹 프로그래밍을했을 때 내가 발견 한 한 가지는 정확히 옳은 일을하고 싶었던 매우 열정적 인 사람들을 끌어 들이고 있다는 것입니다. noweb은 모든 사람들에게 충분히 공통된 최소 분모를 제공함으로써 그 문제를 해결하기위한 좋은 시도였습니다. 그럼에도 불구하고 저는 LP 프린터를 개발하기 위해 대부분의 LP 프린터를 개발했습니다.

또 다른 문제는 실제로 민첩하지 않다는 것입니다. 어떤면에서는 속도를 늦추는 것이 좋은데,이를 통해 더 먼저 선입견을 취하고 물건을 올바르게 얻을 수 있기 때문입니다. 반면, 세 심하게 문서를 작성하면 코드를 리팩토링하는 데 큰 장벽이 생깁니다. LP 코드를 작성하기 전에 코드가 강화 될 때까지 기다리면 여러 날의 문서 작업이 생겨 실제로 트랙에서 멈추게됩니다.

겸손한 견해로는 많은 회사들이 Literate Programming의 목표와 반대되는 문화를 가지고 있습니다. 더 빠른 결과를 원합니다 (앱 제작시 품질에 대해서만 울림). 내 경험상, 상사는 빠른 결과가 "요청한 다음날 실행할 수있는 프로그램"을 의미하지 않는다는 것을 이해하지 않았다. 그들에게 개발자가 키보드를 사용하여 바쁘지 않다면, 그는 일하지 않고있다. "비 감각적 인 디자인으로 시간을 낭비하고있다". 그렇습니다. 제 상사는 피고인입니다.

코더는 영어가 아닌 코드를 작성합니다.

코더는 코드 실행에 도움이되지 않기 때문에 문서 작성을 좋아하지 않습니다.

코더는 아이디어를 표현할 수있는 매체가 좋지 않기 때문에 문서 작성에 능숙하지 않습니다.

Literate Programming은 코드가 나중에 생각할 수있는 다음 단계로 문서를 가져 오는 아이디어입니다. 어쩌면 작동하지만 대부분의 코더에게는 눈에 띄지 않는 문서처럼 보입니다.

사람들이 매우 견고하기 때문에 주로. 이 간단한 기술의 본질에 대해 젊은이들이 표현한 끝없는 추측과 오해의 흐름 인 명백한 간증.

사람들은 LP를 다음과 같이 생각합니다 : (a) 문서화 방법 (b) 특별한 기술이나 재능을 필요로하는 세련된 에세이를 작성하는 방법 (c) 레오 프로그래밍 에디터의 창시자로서 자신의 입장을 통해 전혀 단서가 없습니다. 등

그러나 LP는 단순히 다음과 같습니다. (1) 코드와 구를 (= 임의의) 인간 언어로 혼합하여 프로그램을 작성하는 경우, 후자는 다른 코드 덩어리 및 / 또는 포함 된 구를 나타냅니다. 이것은 수많은 프로그래밍 교과서의 저자가하는 일입니다. 그리고 (2) 인간의 구절을 포함 시켜서 (포함 된 서브 루틴의 이름처럼 된) 확장 된 간단한 전 처리기입니다. 통역사). 그렇지 않으면 다른 작은 유틸리티를 사용하여 작성된 텍스트를 확장하여 "리터 레이트 소스"를 형식이 잘 지정된 읽기 쉬운 텍스트로 변환하는 서식 기호를 포함 할 수 있습니다.

젊은이들은이 단순한 아이디어를 시도하지 않으며, 절대 시도하지 않거나 시도하지 않는 가짜 이유를 상상하거나 상상합니다.

기본적으로 인간 언어로 작성된 "의사 코드"로 프로그래밍 한 다음 간단한 전 처리기 유틸리티 인 HELPS MANAGE ATTENTION (제한된 프로그램의 주요 어려움)을 사용하여이를 확장하는 기본 아이디어는 코드 폴딩 또는 프로그램 흐름의 분할과 매우 유사합니다. 세부 사항을 잃지 않고 기계 실행에 전적으로 필요하지 않은 기능 / 서브 루틴으로.

나는 그 글을 읽고 프로그래밍의 두 측면이있다 않는 소원이 주류 프로그램에 포함 된이 - 임베디드 이미지 (예를 들어, 디자인 다이어그램) 이전과 다른 시도 (및 포인터 예를 들면, "나는이 다른 방법을 시도하기 때문에이처럼 이유이며, ... ") 때문에 작동하지 않았습니다. 이 두 가지 측면 모두 doc-comments와 URI로 처리 할 수 ​​있습니다.

프로그램의 논리는 우리가 말하는 것과 동일하게 작동하지 않기 때문입니다. 프로그램에는 흐름, 조건 및 루프가 잘 지정되어 있습니다.

코딩을 많이 한 후에, 나는이 용어로 생각합니다. 내 뇌는 문제를 실행 가능한 코드의 대상 도메인으로 변환합니다. 그리고 프로그램을 읽기 위해 추가 변환 단계를 수행하는 것보다 일반적으로 프로그래밍 언어로 작성하는 것이 훨씬 효율적입니다.

사실, 나는 내 프로그램이 이미 문맹이라고 생각합니다. 말하기 식별자, 좋은 기능 이름, 몇 달 후 즉시 이해하지 못하는 해커를 한 의견.

결론 : 모든 "리터 레이트"프로그래밍이 원하는대로 내 Java 코드 자체가 더 읽기 쉽다.

나는 다른 방법으로 프로그래밍을 배우게되었습니다. 컴파일러가 필요로하는 것이 아니라 내 마음에 맞는 코드를 구성하는 것이 꿈이었습니다. 레오 는이 목적에 거의 이상적이라는 것을 알았습니다 . 또한 외부에서 변경된 파일을 추적 할 수 있습니다. 이 파일에는 특별한 마크 업이 포함되어 있지 않아도되므로 팀의 다른 사람들이 알 필요없이 Leo를 직접 사용할 수 있습니다. "@shadow trees"라는이 기능은 매우 유망하지만, 여전히 약간 버그가 있지만 더 많은 안구가 필요합니다. 또한 모든 것을 트리 개요로 구성하고 외부 파일을 지원하여 "아, 하나의 큰 파일의 모든 것"문제를 해결합니다.

저에게 이름과는 달리 "리터 레이트 프로그래밍"은 문서화에 관한 것이 아닙니다. 이전보다 더 많은 문서가 없습니다. 내가 길을 잃지 않도록 도와주는 구조를 갖는 것 입니다. 나는 거대한 JSP 파일을 관리 할 때 특히 맹세합니다 (Leo는 원래 Python을 대상으로하고 JSP 언어를 지원하지 않습니다-파일을 Leo 트리로 수동으로 분할해야합니다!)

나는 코드에 대한 논문을 작성할 수있는 유용한 교육 도구로 본 다음, 코드의 작동 방식, 목적 및 이유에 대해 독자들에게 지시하기 위해 작업 코드 스 니펫을 인터리브했습니다.

순전히 교육적인 환경 밖에서는, Knuth만이 그 환경을 가장 잘 사용하는 방법을 이해한다고 생각합니다.

그것은 모든 세계에서 최악입니다. 매우 비 특정 언어 = 영어로 매우 정확하고 매우 구체적인 컴퓨터 프로그램을 작성해야합니다. 따라서 정확한 문구를 사용하여 신중하게 작성해야하므로 코드를 작성할 수도 있습니다.