เวิร์กโฟลว์ Lisp ของคุณมีลักษณะอย่างไร [ปิด]

ตอนนี้ฉันกำลังเรียนรู้ Lisp มาจากความก้าวหน้าทางภาษานั่นคือ Locomotive BASIC -> Z80 Assembler -> Pascal -> C -> Perl -> C # -> Ruby แนวทางของฉันคือการไปพร้อมกัน:

• เขียนมีดโกนเว็บอย่างง่ายโดยใช้ SBCL, QuickLisp, closed-html และ drakma
• ดูการบรรยาย SICP

ฉันคิดว่ามันใช้งานได้ดี ฉันกำลังพัฒนา 'Lisp goggles' ที่ดีซึ่งตอนนี้ฉันสามารถอ่าน Lisp ได้ง่ายพอสมควร ฉันยังรู้สึกว่าระบบ Lisp ทำงานอย่างไรเช่น Quicklisp สำหรับการพึ่งพา

แต่สิ่งที่ฉันพลาดไปจริง ๆ ก็คือความรู้สึกว่า Lisper ที่มีประสบการณ์ทำงานอย่างไร

เมื่อฉันเข้ารหัสสำหรับ. NET ฉันมี Visual Studio ตั้งค่าด้วย ReSharper และ VisualSVN ฉันเขียนแบบทดสอบฉันใช้งานฉันสร้างใหม่ฉันจะทำ จากนั้นเมื่อฉันทำเรื่องนั้นจนจบฉันก็เขียน AUAT จากนั้นฉันเริ่มต้นสร้าง Release บน TeamCity เพื่อผลักดันฟังก์ชันการทำงานใหม่ให้กับลูกค้าเพื่อการทดสอบและการอนุมัติหวังว่า หากเป็นแอพที่ต้องใช้ตัวติดตั้งฉันใช้ WiX หรือ InnoSetup สร้างการติดตั้งผ่านระบบ CI

ดังนั้นคำถามของฉันคือ: ในฐานะผู้มีประสบการณ์ Lisper กระบวนการทำงานของคุณมีลักษณะอย่างไร คุณทำงานส่วนใหญ่ใน REPL หรือในโปรแกรมแก้ไขหรือไม่? คุณจะทำการทดสอบหน่วยได้อย่างไร บูรณาการอย่างต่อเนื่อง? บรรจุภัณฑ์และการใช้งาน? เมื่อคุณนั่งลงที่โต๊ะของคุณกำลังต้มกาแฟสักถ้วยหนึ่งที่ด้านหนึ่งและรูปถ่ายของ John McCarthy ที่อยู่ข้าง ๆ คุณทำอะไร

ขณะนี้ฉันรู้สึกว่าฉันจะได้สัมผัสกับการเข้ารหัส Lisp แต่ไม่ใช่การพัฒนา Lisp ...

คนส่วนใหญ่ใน comp.lang.lisp และLisp Forumแนะนำการรวมกันของ Emacs และ SLIME โดยสมมติว่าคุณไม่ต้องการจ่ายเงินสำหรับการดำเนินการเชิงพาณิชย์เช่น Allegro หรือ LispWorks วิดีโอ SLIMEแสดงกระบวนการทำงาน ฉันใช้ Emacs และ SLIME เพื่อพัฒนาโปรแกรมส่วนบุคคลที่บ้านและการรวมกันนั้นมีประสิทธิภาพมาก

SLIME ให้คุณผสานรวมระหว่าง Emacs และ REPL โดยทั่วไปแล้วสิ่งที่ฉันทำคือโหลดไฟล์ทั้งหมดของฉันจากนั้นเปิดไฟล์ที่ฉันกำลังทำงานใน Emacs หลังจากที่ฉันพิมพ์หรือเปลี่ยนแปลงแต่ละฟังก์ชั่นฉันกดC-x C-eซึ่งดำเนินการกำหนดฟังก์ชั่นใน REPL จากนั้นฉันสามารถสลับไปที่บัฟเฟอร์ REPL และลองใช้ฟังก์ชั่น ประวัติทั้งหมดของ REPL นั้นมีอยู่และสามารถแก้ไขได้โดยใช้ลำดับคีย์ Emacs มาตรฐานดังนั้นจึงเป็นเรื่องง่ายที่จะทำซ้ำการเรียกใช้ฟังก์ชันด้วยพารามิเตอร์ที่แตกต่างกัน

ฉันทำงานกับ Clojure เป็นหลักและนี่คือการตั้งค่าของฉัน:

1. Eclipse IDE (ฉันใช้สิ่งนี้เพราะฉันยังทำงาน Java มากบางครั้งในโครงการเดียวกันกับ Clojure)
2. ปลั๊กอินทวนเข็มนาฬิกาสำหรับ Clojure (รวมถึง REPL)
3. Maven สำหรับการพึ่งพาและสร้างการจัดการ
4. Egit สำหรับการควบคุมซอร์สโค้ด

เวิร์กโฟลว์ในขณะที่การเขียนโค้ดเป็นดังนี้:

1. เปิด REPL โหลดไฟล์ต้นฉบับปัจจุบันทั้งหมด
2. รหัสและทดสอบใน REPL
3. เมื่อฉันพอใจกับโค้ดบางส่วนให้คัดลอก / วางกลับไปที่ไฟล์ต้นฉบับ
4. รีบูต REPL เป็นครั้งคราว (ทั้งเมื่อฉันทำเนมสเปซไม่สามารถเพิกถอนได้หรือเพื่อตรวจสอบว่าทุกอย่างยังคงทำงานในไฟล์ต้นฉบับ)
5. เขียนการทดสอบในไฟล์ต้นฉบับซึ่งทำงานโดยอัตโนมัติโดย Maven build ทุกตัว บางครั้งการทดสอบแบบไม่เป็นทางการที่ฉันเพิ่งทำที่ REPL จะถูกเปลี่ยนเป็นการทดสอบหน่วย
6. มุ่งมั่น ฯลฯ ณ จุดนี้ - เป็นขั้นตอนการพัฒนาตามปกติ

โดยรวมแล้วจะไม่แตกต่างจากเวิร์กโฟลว์ Java / C # ปกติมากไปกว่าการใช้งาน REPL แบบโต้ตอบในระหว่างการพัฒนา

เพื่อเสริมคำตอบอื่น ๆ ฉันได้ผสมผสาน "คิดอย่างหนักเกี่ยวกับปัญหาแล้วเขียนวิธีแก้ปัญหา" ชนิดของการพัฒนาและ "เริ่มต้นด้วยแบบจำลองและเอาชนะโปรแกรมของคุณให้มีรูปแบบซ้ำ ๆ " มันมักจะอยู่ตรงกลาง สิ่งที่ฉันทำคือฉันเริ่มต้นด้วยแนวคิดทั่วไปเกี่ยวกับสิ่งที่ฉันต้องการให้โปรแกรมของฉันดูเหมือนและจากนั้นฉันก็เริ่มเขียนมันพยายามที่จะได้รับความรู้ใหม่เกี่ยวกับโดเมนปัญหาตามที่ฉันไปเพื่อแก้ไขแนวทางของฉัน ในทางปฏิบัตินั่นหมายความว่าฉันทำการทดลองมากมายและเขียนรหัส trow away จำนวนมาก ฉันลองใช้วิธีที่ต่างกันและฉันสามารถเปลี่ยนทิศทางได้อย่างรวดเร็ว เสียงกระเพื่อมเป็นสิ่งที่ดีสำหรับการพัฒนาชนิดนี้ นั่นเป็นเหตุผลที่ฉันไม่ชอบ TDD มากฉันต้องรู้ว่าฉันต้องทำอะไรก่อนเพื่อให้ TDD มีประสิทธิภาพ

สิ่งสำคัญอีกอย่างที่ฉันพยายามทำคือคิดเกี่ยวกับโปรโตคอลระหว่างส่วนต่าง ๆ ของโปรแกรม ซึ่งแตกต่างจากภาษา OO อื่น ๆ ใน Common Lisp CLOS มุ่งเน้นไปที่แนวคิดของฟังก์ชั่นทั่วไปวิธี IOW อาศัยอยู่นอกชั้นเรียนและพวกเขาเป็นจุดสำคัญของการพัฒนา บางครั้งฉันเพิ่งเริ่มต้นด้วยชุดของ GFs ที่กำหนดโปรโตคอลที่ฉันต้องการฉันเขียนการใช้งานง่าย ๆ และใช้มันเพื่อรวบรวมโปรโตคอลก่อนที่ฉันจะเขียนการใช้งานจริง สมมติว่าฉันกำลังเขียนเลเยอร์ที่จัดเก็บบล็อกโพสต์ไว้มากมายฉันอาจมีชุดของ GF ที่กำหนดวิธีสร้างโพสต์บล็อกแก้ไขและค้นหา และหลังจากฉันมีความสุขกับโปรโตคอลของฉันฉันเขียนการใช้งานที่บันทึกโพสต์บล็อกไปยังฐานข้อมูลหรือเขียนลงในไฟล์

เสียงกระเพื่อมทำให้ง่ายต่อการเปลี่ยนทิศทางและทำวิธีการที่แตกต่างกันเมื่อคุณรู้ว่าวิธีการแก้ปัญหาในปัจจุบันของคุณไม่ดีเท่าที่ฉันพยายามที่จะเพิ่มในที่

จุดสำคัญอีกอย่าง: ใช้สภาพแวดล้อมของคุณอย่างเต็มที่เรียนรู้เกี่ยวกับการใช้การตั้งค่าการรวบรวมที่แตกต่างกันเพื่อรวบรวมรหัสของคุณด้วยข้อมูลการดีบักเพิ่มเติมใช้ประโยชน์จากข้อเท็จจริงที่ว่าเสียงกระเพื่อมนั้นสามารถรวบรวมและตีความได้ ใช้สิ่งอำนวยความสะดวกในการใคร่ครวญ lisps เช่น MOP ใช้คุณสมบัติ slimes ในการค้นหาเอกสารใช้เครื่องมือตรวจสอบเพื่อดูวัตถุภายในปรึกษา hyperspec เป็นประจำรักษาระบบของคุณให้เหมือนกับระบบปฏิบัติการมากกว่าคอมไพเลอร์แบบคงที่สำหรับรหัสของคุณ ทรงพลังยิ่งกว่านั้น

สำหรับผู้เริ่มต้นเสียงกระเพื่อมนั้นไม่ใช่การชนะอย่างมากของงูหลามและทับทิม แต่เมื่อคุณได้รับประสบการณ์มากขึ้นคุณจะได้รับชัยชนะมหาศาลจากสภาพแวดล้อมที่น้อยลง

ที่สำคัญที่สุดคุณต้องมีความสนุกสนานและรักภาษานี้บางครั้งมันเป็นเรื่องง่ายที่จะท้อและไปใช้ภาษาที่ได้รับความนิยมในปัจจุบัน หากคุณติดอยู่กับเสียงกระเพื่อมก็จะตอบแทนคุณ

ฉันมักจะทำงานในโปรแกรมแก้ไขที่มีการเชื่อมต่อกับ REPL (โดยทั่วไปแล้วการแก้ไขใน emacs และการใช้ SLIME เป็นสะพานเชื่อมไปยังสภาพแวดล้อม Common LISP) ฉันมักจะเริ่มต้นทั้ง "ที่ด้านล่าง" และ "ที่ด้านบน" ทำงานไปที่ตรงกลางปรับปรุงการออกแบบเมื่อฉันไป

สำหรับการทดสอบทำไมถึงมี REPL ฉันพบว่ามันช่วยในการทดสอบรหัสเมื่อฉันไป บางครั้งฉันจะเขียนการทดสอบที่เป็นทางการหรือมาตรฐานมากขึ้นเมื่อฉันไป (โดยปกติเมื่อฉันอยู่ในขั้นตอนการปรับให้เหมาะสม) มีการใช้งานฟังก์ชั่นช้าลงรู้จักกันดีทดลอง (ในหน้าต่างตัวแก้ไข) พร้อมรหัสสำหรับรุ่นที่ดีที่สุดส่งไปยังรหัส lisp ที่อยู่ภายใต้และตรวจสอบว่าทั้งคู่เร็วขึ้นและให้ผลลัพธ์ที่ช้ากว่า รหัส.

เท่าที่บรรจุภัณฑ์ไปฉันมีรหัสยูทิลิตี้บางอย่างเพื่อช่วยฉันในการจัดทำโครงการที่สามารถติดตั้ง ASDF ตบพวกเขาในพื้นที่เก็บข้อมูลดาวน์โหลดและจัดการเวอร์ชัน