Quy trình làm việc Lisp của bạn trông như thế nào? [đóng cửa]

Hiện tại tôi đang học Lisp, xuất phát từ một tiến trình ngôn ngữ là CƠ SỞ CƠ BẢN -> Trình biên dịch Z80 -> Pascal -> C -> Perl -> C # -> Ruby. Cách tiếp cận của tôi là đồng thời:

• viết một trình quét web đơn giản bằng SBCL, QuickLisp, clos-html và Drainkma
• xem các bài giảng của SICP

Tôi nghĩ rằng điều này đang làm việc tốt; Tôi đang phát triển tốt 'Kính bảo hộ Lisp', giờ đây tôi có thể đọc Lisp một cách hợp lý dễ dàng. Tôi cũng cảm nhận được cách hệ sinh thái Lisp hoạt động, ví dụ Quicklisp cho các phụ thuộc.

Tuy nhiên, điều tôi thực sự thiếu là cảm giác về một Lisper dày dạn thực sự hoạt động như thế nào .

Khi tôi mã hóa .NET, tôi có Visual Studio được thiết lập với ReSharper và VisualSVN. Tôi viết bài kiểm tra, tôi thực hiện, tôi tái cấu trúc, tôi cam kết. Sau đó, khi tôi đã làm đủ điều đó để hoàn thành một câu chuyện, tôi viết một số AUAT. Sau đó, tôi khởi động bản dựng Phát hành trên TeamCity để đẩy chức năng mới ra cho khách hàng để thử nghiệm và hy vọng được chấp thuận. Nếu đó là một ứng dụng cần trình cài đặt, tôi sử dụng WiX hoặc InnoSetup, rõ ràng là xây dựng trình cài đặt thông qua hệ thống CI.

Vì vậy, câu hỏi của tôi là: là một Lisper có kinh nghiệm, quy trình làm việc của bạn trông như thế nào? Bạn có làm việc chủ yếu trong REPL, hoặc trong trình chỉnh sửa không? Làm thế nào để bạn làm bài kiểm tra đơn vị? Hội nhập liên tục? Đóng gói & triển khai? Khi bạn ngồi xuống bàn làm việc, rót cốc cà phê sang một bên và một bức ảnh đóng khung của John McCarthy sang bên kia, bạn đang làm gì vậy ?

Hiện tại, tôi cảm thấy như mình đang nắm bắt được mã hóa Lisp, nhưng không phát triển Lisp ...

Hầu hết mọi người trên comp.lang.lisp và Lisp Forum đề xuất kết hợp Emacs và SLIME, giả sử bạn không muốn trả tiền cho việc triển khai thương mại như Allegro hoặc LispWorks. Video SLIME minh họa quá trình làm việc. Tôi sử dụng Emacs và SLIME để phát triển các chương trình cá nhân tại nhà và sự kết hợp có thể rất hiệu quả.

SLIME cung cấp cho bạn sự tích hợp giữa Emacs và REPL. Những gì tôi thường làm là tải tất cả các tệp của mình, sau đó mở tệp tôi đang làm trong Emacs. Sau khi tôi nhập hoặc thay đổi từng chức năng, tôi nhấn C-x C-e, để thực hiện định nghĩa chức năng trong REPL. Sau đó tôi có thể chuyển sang bộ đệm REPL và thử chức năng. Tất cả lịch sử của REPL đều có sẵn và có thể chỉnh sửa bằng các chuỗi khóa Emacs tiêu chuẩn, do đó thật dễ dàng để thực hiện lại các cuộc gọi chức năng với các tham số khác nhau.

Tôi làm việc chủ yếu với Clojure và đây là thiết lập của tôi:

1. IDE Eclipse (Tôi sử dụng cái này vì tôi cũng làm rất nhiều công việc Java, đôi khi trong cùng một dự án với Clojure)
2. Plugin ngược chiều cho Clojure (bao gồm REPL)
3. Maven cho sự phụ thuộc và quản lý xây dựng
4. Ví dụ: kiểm soát mã nguồn

Quy trình làm việc trong khi mã hóa thường như thế này:

1. Mở REPL, tải tất cả các tệp nguồn hiện tại
2. Mã và kiểm tra trong REPL
3. Khi tôi hài lòng với một số mã, sao chép / dán lại vào tệp nguồn
4. Thỉnh thoảng khởi động lại REPL (khi tôi đã làm hỏng một không gian tên không thể sửa chữa được hoặc chỉ để kiểm tra mọi thứ vẫn hoạt động trong các tệp nguồn)
5. Đồng thời viết các bài kiểm tra trong các tệp nguồn, được chạy tự động bởi mọi bản dựng Maven. Đôi khi các bài kiểm tra không chính thức tôi vừa thực hiện tại REPL được chuyển thẳng thành bài kiểm tra đơn vị.
6. Cam kết, vv tại thời điểm này - khá nhiều quy trình phát triển thường xuyên

Nhìn chung, nó không quá khác biệt so với quy trình làm việc Java / C # thông thường ngoài việc sử dụng REPL tương tác nhiều hơn trong quá trình phát triển.

Để bổ sung cho các câu trả lời khác, tôi kết hợp kiểu phát triển "Nghĩ kỹ về vấn đề, sau đó viết ra giải pháp" và "Bắt đầu với một thay thế, và đánh bại chương trình của bạn thành hình dạng lặp đi lặp lại". Nó thường ở giữa. Những gì tôi làm là tôi bắt đầu với một ý tưởng chung về những gì tôi muốn chương trình của mình trông như thế nào, và sau đó tôi bắt đầu viết nó, cố gắng thu thập kiến ​​thức mới về miền vấn đề khi tôi đi, để sửa đổi cách tiếp cận của tôi. Trong thực tế điều đó có nghĩa là tôi làm rất nhiều thử nghiệm và viết rất nhiều mã trow đi. Tôi thử các cách tiếp cận khác nhau và tôi có thể chuyển hướng rất nhanh. Lisp là tốt cho loại phát triển này. Đó là lý do tại sao tôi không thích TDD rất nhiều, tôi phải biết tôi muốn làm gì trước tiên, để TDD có hiệu quả.

Một điều quan trọng khác tôi cố gắng làm là suy nghĩ nhiều hơn về giao thức giữa các phần khác nhau của chương trình. Không giống như các ngôn ngữ OO khác, Trong Common Lisp CLOS tập trung nhiều hơn vào khái niệm hàm Chung, các phương thức IOW sống bên ngoài các lớp và chúng là trọng tâm của sự phát triển. Đôi khi tôi chỉ bắt đầu với một tập hợp các GF xác định giao thức tôi muốn, tôi viết một triển khai đơn giản và sử dụng nó để xác định giao thức, trước khi tôi viết một triển khai thực sự. Giả sử tôi đang viết một lớp lưu trữ một loạt các bài đăng trên blog, tôi có thể có một bộ các GF xác định cách bài viết blog được tạo, chỉnh sửa và tìm kiếm và tôi sẽ viết một triển khai đơn giản để lưu các bài đăng blog vào danh sách trong bộ nhớ và sau khi tôi hài lòng với giao thức của mình, tôi viết một triển khai lưu các bài đăng trên blog vào cơ sở dữ liệu hoặc ghi chúng vào các tệp.

Lisp làm cho nó dễ dàng thay đổi hướng và thực hiện một cách tiếp cận khác khi bạn biết rằng giải pháp hiện tại của bạn là tối ưu mà tôi cố gắng tối đa hóa về điều đó.

Điểm quan trọng khác: Sử dụng môi trường của bạn một cách đầy đủ nhất, tìm hiểu về cách sử dụng các cài đặt biên dịch khác nhau để biên dịch mã của bạn với nhiều thông tin gỡ lỗi hơn, tận dụng thực tế là lisp có thể được biên dịch và giải thích. Sử dụng các phương tiện nội tâm lisps, chẳng hạn như MOP, sử dụng các tính năng slime để tra cứu tài liệu, sử dụng trình kiểm tra để nhìn vào bên trong các đối tượng, thường xuyên tham khảo hyperspec, coi hệ thống của bạn giống như một hệ điều hành, hơn là trình biên dịch tĩnh cho mã của bạn, nó còn hơn thế nữa mạnh hơn thế

Đối với người mới bắt đầu, lisp không phải là một chiến thắng trước trăn và ruby, nhưng khi bạn có nhiều kinh nghiệm hơn với nó, bạn sẽ có được những chiến thắng to lớn trong môi trường ít hơn.

Quan trọng nhất, bạn phải vui vẻ và yêu thích ngôn ngữ này, đôi khi chỉ để dễ nản lòng và sử dụng các ngôn ngữ blub phổ biến hiện nay. Nếu bạn gắn bó với lisp, nó sẽ trả ơn bạn.

Tôi có xu hướng làm việc trong một trình soạn thảo có kết nối với REPL (thông thường, chỉnh sửa trong emacs và sử dụng SLIME làm cầu nối đến môi trường Lisp chung). Tôi có xu hướng bắt đầu cả "ở phía dưới" và "ở trên cùng", làm việc ở giữa, sửa đổi thiết kế khi tôi đi.

Đối với thử nghiệm, đó là lý do tại sao tôi có REPL. Tôi thấy rằng nó giúp kiểm tra mã khi tôi đi. Đôi khi tôi sẽ viết các bài kiểm tra chính thức hoặc điểm chuẩn hơn khi tôi đi (thường là một khi tôi đang trong giai đoạn tối ưu hóa). Có một triển khai chức năng, thử nghiệm tốt (chậm trong một cửa sổ soạn thảo) với mã cho một phiên bản được tối ưu hóa, gửi mã đó đến mã lisp nằm dưới và kiểm tra xem nó có nhanh hơn không và trả về kết quả tương tự như chậm hơn mã.

Theo như cách đóng gói, tôi có một số mã tiện ích để giúp tôi đóng gói các dự án có thể cài đặt ASDF, đưa chúng vào kho lưu trữ tải xuống và xử lý phiên bản.