문학 프로그래밍, 좋은 / 나쁜 디자인 방법론

나는 최근 문맹 프로그래밍 의 개념을 발견했다 . 그리고 나는 오히려 흥미로운 것을 발견했습니다. 그러나 나는 그것이 프로그램을 구성하는 나쁜 방법이라는 주장에 직면하지 않았습니다. 많은 곳에서 다루지 않은 것 같습니다. 여기조차도 이것에 관한 질문을 찾을 수 없었습니다.

내 질문은 그 결함이나 문서 처리 방법에 관한 것이 아닙니다 . 나는 문서가 문맹 프로그래밍의 흐름에 어떤 의미가 있는지에 대한 부작용이라고 생각한다. 나는 그 디자인이 원래 쉬운 프로그래밍 흐름 과 포워드 프로그래밍 흐름 의 개념을 위해 의도되었다는 것을 안다 .

문제를 작은 문장 기반 문제로 나누는 개념은 정말 훌륭한 생각 인 것 같습니다. 따라서 프로그램 흐름을 쉽게 이해할 수 있습니다.

문해력있는 디자인 방법의 결과는 필요한 기능의 수가 프로그래머의 상상력으로 제한 될 수 있다는 것입니다. 특정 작업에 대한 기능을 정의하는 대신 문 scrap해법 으로 작성 될 수 있습니다 . 이것은 별도의 함수 컴파일과 동등한 속도를 얻기위한 절차 간 컴파일 최적화 단계의 후속 요구 대신 코드의 자동 삽입을 생성합니다. 사실 Donald E. Knuth의 첫 번째 시도 는이 사실 때문에 실행 시간이 열등했습니다. 나는 컴파일러가 이것을 많이 만들 수 있다는 것을 알고 있지만 이것은 내 관심사가 아닙니다.

그래서 왜 이것을 나쁜 / 좋은 디자인 방법론으로 생각해야하는지에 대한 피드백을 받고 싶습니다.

이것은 별도의 함수 컴파일 대신 동등한 속도를 얻기 위해 절차 간 컴파일 최적화 단계의 요구 사항 대신 코드를 자동으로 삽입합니다.

이것은 관련이 없습니다. 수십 년 동안되었습니다. 현대 컴파일러에서는 최적화 프로그램을 파괴하는 것이 의미가 없으므로 질문에서 제거 할 수 있습니다.

그래서 왜 이것을 나쁜 / 좋은 디자인 방법론으로 생각해야하는지에 대한 피드백을 받고 싶습니다.

문맹 프로그래밍에 대한 단점은 없습니다. (나는 그 정서에 대해 수십 -1 표를 기대한다.) 실무자로서 나는 아무런 문제도 본 적이 없다.

"결과 코드를 조정하여 더 높은 수준의 언어로 프로그래밍하는 데 필요한 모든 것을 무시할 수있는 몇 가지 주장이 있습니다." 권리. C ++에서의 프로그래밍이.o 은 생성 파일을 . 사실이지만 관련이 없습니다.

문맹 퇴치 프로그램을 작성한다는 것은 단지 고급 및 상세 (코드 수준) 설계를 하나의 문서로 결합하여 컴파일러 친화적 파일과 사람 친화적 파일을 생성하는 적절한 도구 세트로 작성하는 것을 의미합니다.

Knuth가 문맹 프로그래밍을 발명했을 때 주류 OO 언어는 존재하지 않았습니다. 따라서 많은 양의 독창적 인 웹 및 직조 도구를 사용하여 추상 데이터 유형에 대한 클래스와 같은 정의를 만들 수있었습니다.

요즘 대부분은 관련이 없습니다. Literate Programming 도구는 현대적인 고급 객체 지향 (또는 기능적) 프로그래밍 언어에 중점을 둔 경우 매우 간단 할 수 있습니다. C (또는 파스칼 또는 어셈블러)의 한계로 인해 정교한 해결 방법이 덜 필요합니다.

문맹 프로그램을 작성하는 방법은 문맹 프로그램을 작성하는 방법과 다르지 않습니다. 여전히 신중한 디자인, 단위 테스트 및 깔끔한 코딩이 필요합니다. 유일한 추가 작업은 코드 작성 외에 설명을 작성하는 것입니다.

이러한 이유 때문에 (일관된 설명을 작성해야 함) 일부 프로그래머에게는 문맹 프로그래밍이 어렵습니다. 공정한 수의 프로그래머가 있지만 (코드는 모든 단위 테스트를 통과하고, 깔끔하고 이해하기 쉽습니다) 모국어로 일관성있는 문장을 작성할 수는 없습니다. 왜 이것이 사실인지 모릅니다.

아주 적은 수의 프로그래머가 있으며, 단지 약간만 성공한 다음 우연히 만 나타납니다. (스택 오버플로에는 많은 프로그래머가 기본 사항을 파악하기 위해 어려움을 겪고 있다는 나쁜 질문이 충분합니다.) 크게 일관되지 않은 스택 오버플로 질문을하는 프로그래머에게는 글을 읽고 쓸 줄 모르는 글쓰기 프로그래밍을 할 수 없다는 것을 알고 있습니다. 프로그래밍을 잘하지 않습니다.

저에게있어 문해력있는 프로그래밍 (또는 단지 좋은 논평)의 가장 중요한 측면은 문서를 제공하는 것이 아니라 프로그래머의 의도를 나타냅니다. 명시된 의도를 알면, 코드를 따르는 코드가 실제로 수행해야 할 작업을 즉시 판단 할 수 있습니다. 의도가 없다면 코드가 정확하다는 가정부터 시작하여 유도에 의해 코드가 옳고 그름임을 증명해야합니다. 이는 모든 주변 코드에도 익숙해 져야하기 때문에 더 고갈되고 시간이 많이 걸립니다.

따라서 이러한 의도는 종종 코드에 익숙하지 않은 다른 사람들이 코드를 둘러싼 더 큰 컨텍스트를 몰라도 코드에 빠르게 뛰어 들어 오류를 찾을 수있게합니다.

물론 일반 영어는 대부분의 사람들에게 포인터 산술보다 직관적이기 때문에 코드의 기본 흐름과 디자인을 더 빨리 배울 수 있습니다.

어설픈 프로그래밍이라는 개념에 익숙하지는 않지만 (따라서 배를 완전히 잃어 버릴 가능성이 큽니다) DSL 개념과 매우 일치하는 것처럼 보입니다 .

DSL의 기본 개념은 문제의 영역을 문제를 해결하기위한 알고리즘을 구축하는 데 사용할 수있는 간단한 자연 언어 지향 문법으로 정리하는 것입니다.

나에게 그 같은 아이디어 또는 적어도 그것의 핵심 기초는 문맹 ​​프로그래밍과 동일하거나 적어도 밀접한 관련이 있습니다.

예를 들어, 그루비 세계에서는 DSL을보다 정기적으로 사용하고 일반적인 문제를 해결하기 위해 새로운 DSL을 만들라는 강력한 압박이 있습니다. 이 푸시는 언어 내 도구 (간편한 빌더)와 DSL 기반 API를 지원하는 핵심 라이브러리에서 비롯됩니다.

추세가 세계의 구석에 적어도 것을 감안할 으로 글을 읽고 프로그래밍, 나는 그것을 위해 노력하는 좋은 방법이라고 말할 것입니다.

불행히도, 좋은 dsl 을 만드는 데 필요한 사고 수준 은 종종 내가 본 것에서 대부분의 프로그래머를 넘어서고 있습니다. 나는 때때로 때때로 필요한 몇 가지 개념으로 개인적으로 어려움을 겪고 있음을 알고 있습니다. 이러한 기술이 더 널리 채택되는 것을 방해하는 것은 이러한 어려움 일 수 있습니다.

도구를 사용하는 것이 하나의 고전적인 경우이지만 도구를 만드는 것은 완전히 다른 수준입니다.

내 관점에서 약간 확장하기 위해 DSL이 문맹 프로그래밍과 같은 것이 아니라 문맹 프로그래밍을 훨씬 더 가능하게 만듭니다. 특히 그들이 자연어 DSL 일 때 .

그루비 버전 1.8에서는 보다 강력한 명령 체인을 추가 하여 자연어 DSL 기능이 크게 향상되었습니다 .

예를 들어 의사 문장뿐만 아니라 다음 코드 줄도 프로그래밍입니다 .

drink tea with sugar and milk
move left by 30.centimeters
sendFrom "Guillaume" to "Jochen"
send from: "Jochen" to "Lidia"
Email.from "Lidia" to "Guillaume" withBody "how are you?"
contact.name "Guillaume" age 33
move left by 30.centimeters
sell 100.shares of MSFT
take 2.pills of chloroquinine in 6.hours
blend red, green of acrylic
artist.paint "wall" with "Red", "Green", and: "Blue" at 3.pm
wait 2.seconds and execute { assert true }
concat arr[0] with arr[1] and arr[2]
developped with: "Groovy" version "1.8-beta-2"

참고 : 코드 샘플은 Guillaume Laforge의 블로그에서 제공합니다.

문맹 프로그래밍의 기본 개념은 자연어가 인간에게 더 잘 이해 될 수 있다는 것입니다. Groovy의 자연어 DSL 기능은 제 생각에 훨씬 더 가까운 현실을 만듭니다. 특히 이러한 DSL을 사용하여 응용 프로그램의 비즈니스 규칙을 만들 때.

자연 언어를 사용하여 시스템의 핵심 구성 요소를 "인코딩"할 수 있다는 것이 문맹 프로그래밍의 핵심입니다. 자연어를 코드 덩어리와 산재시켜야하는 것은 문맹 화 된 프로그래밍의 문체 화 된 형태입니다. 유용하지만 코드 자체로 자연어를 사용할 수있는 자연어 DSL 은 큰 도약이라고 생각합니다.

일반적으로 프로그래밍 기능을 확장하는 것이 프로세스의 다음 단계이지만,이를위한 도구는 이미 제자리에 있습니다. 예. "일반"DSL은 아직 없지만 소규모 도메인의 경우 기능이 있습니다.

이에 대한 더 많은 예를 들어 (특별한 순서로) :

• http://www.slideshare.net/glaforge/groovy-dsls-s2gforum-london-2011-guillaume-laforge
• http://docs.codehaus.org/display/GroovyJSR/GEP+3+-+Command+Expression+based+DSL
• /programming/6646811/groovy-1-8-abc-style
• http://svn.codehaus.org/groovy/trunk/groovy/groovy-core/src/test/gls/syntax/Gep3Test.groovy
• http://groovyconsole.appspot.com/script/355001
• http://docs.codehaus.org/display/GROOVY/Groovy+1.8+release+notes#Groovy18releasenotes-CommandchainsfornicerDomain-SpecificLanguages
• http://mrhaki.blogspot.com/2011/05/groovy-goodness-command-chain.html
• http://ice09.wordpress.com/2011/10/07/dsls-made-easy-with-groovys-chain-method-calls-gep-3/
• http://eric-berry.blogspot.com/2011/05/some-dsl-fun-with-groovy-18.html

LP가 일종의 DSL이라고 생각하는 것은 실수라고 생각합니다. LP는 개발 된 프로그램의 저널 (다이어그램, 구성표, 의사 코드 조각, 즉 청크 포함)이기 때문에 아키텍처 등입니다. 종이 노트와 완전히 유사합니다. 많은 개발자가 사용하지만 프로그램 완료 후- 당신의 공책, 종이를 버려라 ...

오래 전에 각 물리학 자, 천문학 자, 화학자 / 연금술사, 수학자에게는 노트, 많은 계획이있는 원고, 필요한 정보, 표가 있으며, 그들 없이는 성공적인 경험, 그의 결과를 이해하거나 반복 할 수 있습니다. 그리고 그러한 사람들 사이에는 항상 manuscreepts / notebooks 사냥이 있습니다.

오늘날 많은 프로그래머들이 코드를 작성하고 때로는 주석을 추가합니다! Byt 프로그램은 코드뿐만 아니라 생각, 아이디어, 상상력, 개념 및 새로운 개발자가 외계인 코드를 상속받을 때-모든 아이디어와 개념을 자주 깨뜨리고 다른 "루프 홀"과 "백도어"를 만듭니다.

따라서 LP (도구로)에 대한 주요 요구 사항은 단순하고 가볍고 읽기 쉬운 구문으로 이러한 모든 것을 허용합니다. 많은 LP 도구를 사용해 보았지만 오늘 은이 요구를 충족시키는 것을 목표로하는 NanoLP ( http://code.google.com/p/nano-lp/ )를 개발 중입니다.