Lisp 워크 플로우는 어떻게 생겼습니까? [닫은]

나는 현재 기관차 BASIC-> Z80 어셈블러-> 파스칼-> C-> Perl-> C #-> Ruby 인 언어 진행에서 Lisp를 배우고 있습니다. 내 접근 방식은 동시에 :

• SBCL, QuickLisp, closure-html 및 drakma를 사용하여 간단한 웹 스크레이퍼 작성
• SICP 강의 시청

나는 이것이 잘 작동하고 있다고 생각한다. 나는 지금 Lisp를 합리적으로 쉽게 읽을 수 있다는 점에서 좋은 'Lisp 고글'을 개발하고 있습니다. 또한 Lisp 생태계가 어떻게 작동하는지에 대한 느낌을 얻고 있습니다.

그러나 내가 실제로 놓친 것은 노련한 Lisper가 실제로 어떻게 작동 하는지에 대한 감각입니다 .

.NET을 코딩 할 때 ReSharper 및 VisualSVN으로 Visual Studio를 설정했습니다. 테스트를 작성하고 구현하고 리팩터링하고 커밋합니다. 그런 다음 스토리를 완성하기에 충분할 때 몇 가지 AUAT를 작성합니다. 그런 다음 TeamCity의 릴리스 빌드를 시작하여 테스트 및 승인을 위해 새로운 기능을 고객에게 제공합니다. 설치 프로그램이 필요한 앱인 경우 WiX 또는 InnoSetup을 사용하여 CI 시스템을 통해 설치 프로그램을 빌드합니다.

제 질문은 숙련 된 Lisper로서 귀하의 워크 플로는 어떻게 생겼습니까? 주로 REPL 또는 에디터에서 일하십니까? 단위 테스트는 어떻게합니까? 지속적인 통합? 패키징 및 배포? 책상에 앉고 한쪽에는 커피 잔을 찌르고 다른쪽에는 John McCarthy의 액자 사진을 찍으면 어떻게 됩니까?

현재 Lisp 코딩에 익숙해 져 있지만 Lisp 개발에 익숙하지 않은 것 같습니다 ...

comp.lang.lisp 및 Lisp 포럼 에있는 대부분의 사람들은 Allegro 또는 LispWorks와 같은 상용 구현에 대해 비용을 지불하고 싶지 않다고 가정하고 Emacs와 SLIME의 조합을 권장합니다. SLIME 비디오 는 작업 과정을 보여줍니다. 나는 집에서 개인 프로그램을 개발하기 위해 Emacs와 SLIME을 사용하며, 그 조합은 매우 효율적일 수 있습니다.

SLIME은 Emacs와 REPL을 통합합니다. 내가 일반적으로하는 일은 모든 파일을로드 한 다음 Emacs에서 작업중 인 파일을 여는 것입니다. 각 기능을 입력하거나 변경 C-x C-e한 후을 누르면 REPL에서 기능 정의가 실행됩니다. 그런 다음 REPL 버퍼로 전환하고 기능을 시도 할 수 있습니다. 모든 REPL 기록은 표준 Emacs 키 시퀀스를 사용하여 사용 가능하고 편집 가능하므로 다른 매개 변수를 사용하여 함수 호출을 쉽게 다시 실행할 수 있습니다.

나는 주로 Clojure와 함께 일하며 여기에 내 설정이 있습니다.

1. Eclipse IDE (때로는 Clojure와 동일한 프로젝트에서 많은 Java 작업을 할 때 이것을 사용합니다)
2. Clojure 용 반 시계 방향 플러그인 (REPL 포함)
3. 의존성 및 빌드 관리를위한 Maven
4. 소스 코드 제어를위한 Egit

코딩하는 동안의 워크 플로는 일반적으로 다음과 같습니다.

1. 모든 현재 소스 파일을로드하여 REPL을 엽니 다.
2. REPL의 코드 및 테스트
3. 코드가 마음에 들면 소스 파일로 복사 / 붙여 넣기
4. REPL을 재부팅하는 경우가 있습니다.
5. 또한 모든 Maven 빌드에서 자동으로 실행되는 소스 파일에 테스트를 작성하십시오. 때로는 REPL에서 방금 수행 한 비공식 테스트가 단위 테스트로 바로 바뀔 수 있습니다.
6. 이 시점에서 커밋 등-거의 일반적인 개발 워크 플로우

전반적인 개발 과정에서 REPL을보다 대화식으로 사용한다는 점을 제외하면 일반적인 Java / C # 워크 플로와 크게 다르지 않습니다.

다른 답변을 보충하기 위해, "문제에 대해 열심히 생각하고, 해결책을 적어 라"종류의 개발과 "repl로 시작하여 프로그램을 반복적으로 모양을 이길"스타일의 조합을 수행합니다. 보통 중간에 있습니다. 내가하는 일은 내 프로그램이 어떻게 보이기를 원하는지에 대한 일반적인 아이디어로 시작한 다음 접근 방식을 수정하기 위해 문제 영역에 대한 새로운 지식을 얻으려고 노력하면서 시작합니다. 실제로 그것은 많은 실험을하고 많은 코드를 작성한다는 것을 의미합니다. 나는 다른 접근법을 시도하고 방향을 매우 빠르게 바꿀 수 있습니다. Lisp는 이런 종류의 개발에 좋습니다. 그렇기 때문에 TDD를 좋아하지 않는 이유는, 효과적인 TDD를 수행하기 위해 먼저해야 할 일을 알아야한다는 것입니다.

내가하려고하는 또 다른 중요한 것은 프로그램의 다른 부분 사이의 프로토콜에 대해 더 많이 생각하는 것입니다. 다른 OO 언어와 달리, Common Lisp CLOS는 Generic 함수의 개념에 더 중점을두고 있으며 IOW 메소드는 클래스 외부에 있으며 개발의 초점입니다. 때로는 원하는 프로토콜을 정의하는 GF 세트로 시작하여 간단한 구현을 작성하고 실제 구현을 작성하기 전에 프로토콜을 살리기 위해 사용합니다. 블로그 게시물을 많이 저장하는 레이어를 작성한다고 가정하면 블로그 게시물을 작성, 편집 및 검색하는 방법을 정의하는 GF 세트가있을 수 있으며 블로그 게시물을 메모리의 목록에 저장하는 간단한 구현을 작성합니다. 프로토콜에 만족하면 블로그 게시물을 데이터베이스에 저장하거나 파일에 쓰는 구현을 작성합니다.

Lisp를 사용하면 현재 솔루션이 차선책이라고 생각할 때 방향을 쉽게 바꾸고 다른 접근 방식을 수행 할 수 있습니다.

또한 중요한 점 : 환경을 최대한 활용하고 다른 컴파일 설정을 사용하여 더 많은 디버깅 정보로 코드를 컴파일하는 방법을 배우고 lisp를 컴파일하고 해석 할 수 있다는 사실을 활용하십시오. MOP와 같은 리스프 내관 기능을 사용하고, 슬라임 기능을 사용하여 문서를 찾고, 검사기를 사용하여 객체 내부를보고, 하이퍼 스펙을 정기적으로 참조하고, 시스템을 OS와 같은 시스템으로 처리하십시오. 코드의 정적 컴파일러보다 훨씬 더 중요합니다. 그것보다 강력합니다.

초보자에게는 lisp가 파이썬과 루비보다 많은 승리는 아니지만, 경험이 많을수록 적은 환경에서 엄청난 승리를 얻습니다.

가장 중요한 점은,이 언어를 재미 있고 사랑해야한다는 것입니다. 때로는 낙담하기 쉬우 며 현재 인기있는 브루 브 언어를 사용하기도합니다. 당신이 lisp를 고수하면, 당신을 갚을 것입니다.

REPL에 연결된 편집기에서 작업하는 경향이 있습니다 (일반적으로 emacs에서 편집하고 SLIME를 Common Lisp 환경의 브릿지로 사용). 나는 "맨 아래에서"그리고 "맨 위에서"시작하는 경향이 있고, 중간을 향해 나아가면서 디자인을 수정합니다.

테스트에 관해서는, 내가 REPL을 가지고있는 이유입니다. 코드 테스트에 도움이된다는 것을 알게되었습니다. 나는 때때로 갈수록 더 공식적인 테스트 나 벤치 마크를 작성할 것이다. 더 느리고 잘 알려진 기능 구현, 최적화 된 버전의 코드로 실험 (편집기 창에서), 기본 리스프 코드로 전송하고 속도가 더 빠르며 느린 것과 동일한 결과를 반환하는지 확인하십시오. 암호.

패키징이 진행되는 한 ASDF 설치 가능 프로젝트를 포장하고 다운로드 저장소에 넣은 다음 버전 관리를 도와주는 유틸리티 코드가 있습니다.