API พิจารณาว่าเป็น DSL ในตัวเมื่อใด

10

ความแตกต่างระหว่าง API และภาษาเฉพาะโดเมนแบบฝัง (DSL) คืออะไร

มันเป็นเพียงไวยากรณ์

พิจารณา API เช่น OpenGL มันแตกต่างจาก DSL กราฟิกอย่างไร

กล่าวอีกนัยหนึ่งถ้า API มีความซับซ้อนเพียงพอจะถือว่าเป็น DSL แบบฝังได้หรือไม่

api dsl

— Phyllostachys
แหล่งที่มา

1

ประเด็นของ DSL คือการทำให้สิ่งต่าง ๆ ง่ายขึ้น คุณไม่ควรถามว่าAPI ที่ใช้งานง่ายพอสมควรอาจถือว่าเป็น DSL หรือไม่?

— Doval

ฉันคิดว่าสิ่งที่ฉันต้องการรู้ / เข้าใจคือ API และ DSL ต่างกันอย่างไร ฉันใส่ความซับซ้อนไว้ที่นั่นเพราะฉันคิดว่าเมื่อมีคนโทรหา API อย่างต่อเนื่องมันเป็นโดเมนที่ค่อนข้างเฉพาะเจาะจงหรืออย่างน้อยนั่นก็เป็นสิ่งที่ฉันคิดตอนแรก

— Phyllostachys

1

คำถามคือความแตกต่างระหว่างAPIและDSL แบบฝังคืออะไร?

— proskor

8

ความแตกต่างนั้นยากที่จะทำและขึ้นอยู่กับภาษาที่ใช้ มันเป็นเรื่องส่วนตัวเช่นกัน

ใน Clojure คุณสามารถกำหนด API ที่ดูเหมือน DSL สำหรับตัวอย่าง hiccup ให้คุณสร้าง html:

(html [:span {:class "foo"} "bar"])

สิ่งนี้ถือได้ว่าเป็น DSL ที่มีไวยากรณ์เสียงกระเพื่อม ความจริงที่ว่าhtmlอาจเป็นมาโครให้พลังงานเท่ากันเสมือนกับว่าคุณกำลังเขียน lib hpl templating lib ด้วย s-expressions (ดูsxml )

ใน python API เดียวกันอาจมีลักษณะดังนี้:

html(["span", {"class" : "foo"}, "bar"])

html เป็นฟังก์ชั่น อาร์กิวเมนต์จะถูกประเมินก่อนจากนั้นจะเรียกใช้ฟังก์ชัน ความจริงที่ว่าไวยากรณ์ของงูหลามนั้นมีความเฉพาะเจาะจงมากขึ้นและความหมายของงูหลามนั้นเข้มงวดกว่าหมายความว่านิพจน์นี้ยากต่อการตีความว่าเป็น DSL ที่ไม่ขึ้นกับภาษา

การแสดงภาษาคลาสสิกเป็นต้นไม้เช่นโครงสร้างข้อมูลและฟังก์ชั่น eval ที่เรียกซ้ำในโหนด ภาษา LISP ทำให้โครงสร้างต้นไม้นี้ชัดเจนมากดังนั้นการเรียกใช้ฟังก์ชันที่ซ้อนกันใด ๆ จึงแยกไม่ออกจากคุณลักษณะภาษาในตัว นั่นคือเหตุผลที่ชุมชน LISP พูดถึง DSL เกือบทุกอย่าง

ฉันเชื่อว่าการเขียนโปรแกรมเป็นเรื่องเกี่ยวกับการให้ abstractions ที่มีประโยชน์ ฉันพบว่าการดูทุกสิ่งที่คุณสร้าง (lib หรือแม้กระทั่ง UI ของแอปพลิเคชันของคุณ) เนื่องจากองค์ประกอบด้านภาษาช่วยให้ผู้คนในการแก้ปัญหาที่ซับซ้อนเป็นวิธีที่มีประสิทธิภาพในการออกแบบสิ่งต่างๆ ด้วยมุมมองนี้ฉันขอยืนยันว่าห้องสมุดทุกแห่งเป็น DSL แต่บางคนก็ออกแบบมาไม่ดี :-)

— Simon Bergot
แหล่งที่มา

4

API และ DSL เป็นแนวคิดที่แตกต่างกันมากและมีเพียงบางพื้นที่ที่อาจกล่าวได้ว่าทับซ้อนกัน

DSLs ทั้งหมดอยู่ในคอมพิวเตอร์ภาษา พวกเขาอาจจะถูกตีความรวบรวมเครื่องหมายขึ้นภาษาสอบถาม (เช่น SQL) หรือ (เช่น JSON หรือใช้บางส่วนของ XML) ภาษาข้อมูลซึ่งอาจนำมาใช้ในการส่งข้อความผ่านทาง API แต่พวกเขาจะต้องเป็นภาษา คำนี้อธิบายถึงธรรมชาติไม่ใช่วัตถุประสงค์

API เป็นอินเทอร์เฟซที่อนุญาตให้ส่วนประกอบซอฟต์แวร์หนึ่งชิ้นสามารถใช้โดยส่วนประกอบอื่น ๆ คำนี้อธิบายถึงวัตถุประสงค์ไม่ใช่ธรรมชาติ API สามารถเป็นชุดของวัตถุวิธีเช่น - นั่นไม่ใช่ DSL เว็บ API อาจใช้ DSL (หรือถ้ามันเงียบคุณอาจอ้างว่าเป็น DSL) แต่ภาษาเฉพาะโดเมนที่แชร์นั้นไม่ได้เป็นส่วนหนึ่งของคำนิยาม ซอฟต์แวร์ไดรเวอร์สำหรับอุปกรณ์อาจเขียนใน C, API กระจายเป็นไลบรารีที่รวบรวมโพรโทคอลทั้งหมดไบนารีและภาษาใด ๆ ที่สามารถใช้ไลบรารีอาจถูกใช้เพื่อสร้างไคลเอนต์ ไม่มีสิ่งใดใน API ที่สามารถเรียกว่า DSL (รายการชื่อสัญลักษณ์สำหรับฟังก์ชั่น API ไม่ได้ตัดออก)

ฉันสับสนเล็กน้อยว่าทำไมคุณสามารถเห็นความคล้ายคลึงกันได้โดยให้คำจำกัดความ

— itsbruce
แหล่งที่มา

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

— Phyllostachys

2

ซึ่งไม่ส่งผลกระทบต่อคำตอบของฉันจริงๆ ถ้าเป็นภาษาที่มีซินแท็กซ์ของตัวเองมันเป็น DSL อินเทอร์เฟซที่ซับซ้อนซึ่งขาดคุณสมบัติภาษาเหล่านั้นไม่ใช่ DSL คุณควรอัปเดตคำถามของคุณและฉันจะพิจารณาอัปเดตคำตอบของฉัน

— itsbruce

2

ภาษาย่อยยังคงเป็นภาษา ไม่จำเป็นต้องมีไวยากรณ์ "ของตัวเอง" สามารถ "ยืม" จากภาษาโฮสต์ได้

— proskor

ดังนั้นไม่ใช่ทุกโครงการ DSL ของตัวเองเมื่อพวกเขากำลังทำ (เช่นภาษาการเขียนโปรแกรมทั่วไปเป็นที่สุด DSL)? ความต่อเนื่องของการเรียงลำดับจากทั่วไปถึงเฉพาะโดเมน

— Phyllostachys

4

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

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

ข้อยกเว้นเป็นภาษาที่ให้โอกาสพิเศษในการแปรปรวนไวยากรณ์ผ่านทางไลบรารี (ตัวดำเนินการโอเวอร์โหลดเช่น C ++ การประดิษฐ์ตัวดำเนินการใหม่เช่น Scala หรือแม้แต่การประกาศไวยากรณ์การอ่านที่แตกต่างอย่างสิ้นเชิงเช่น Perl กับตัวกรองแหล่งที่มา) เมื่อคุณใช้ภาษาดังกล่าวและใช้ประโยชน์อย่างเต็มที่จากความยืดหยุ่นที่มีให้ผลลัพธ์ก็จะดูเหมือนเป็นภาษาใหม่ที่มีวัตถุประสงค์พิเศษ (แต่ความหมายมักจะแตกต่างจากที่คุณคาดหวังอย่างมากหากภาษานั้นถูกประดิษฐ์ขึ้นจริง ๆจากพื้นดินขึ้นไปเพื่อให้บริการปลายของคุณ)

— Kilian Foth
แหล่งที่มา

ดังนั้นบางทีเราอาจทำสิ่งที่แยกวิเคราะห์สตริง (DSL) ที่ทำหน้าที่เป็น wrapper อย่างง่ายสำหรับ API ขนาดใหญ่ ฉันคิดว่าการแยก DSL จากสิ่งที่แยกวิเคราะห์ DSL คือความแตกต่าง

— Phyllostachys

3

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

— Kilian Foth

"การประดิษฐ์ตัวดำเนินการใหม่อย่าง Groovy" บางทีคุณอาจหมายถึงสกาล่า ใน Groovy ชุดตัวดำเนินการได้รับการแก้ไขแล้ว แต่สามารถโอเวอร์โหลดได้เหมือนใน C ++

— Vorg van Geir

@VorgvanGeir ขออภัยแก้ไขแล้ว

— Kilian Foth

2

ที่นี่จากDslBoundaryโดย Martin Fowler

จากบทความความเข้าใจของฉันคือ DSL และ API ที่ฝังอยู่นั้นไม่แตกต่างกันนัก แต่อย่างไรก็ตามมีความแตกต่างเล็กน้อยที่นี่

APIเน้นการจัดหาสิ่งอำนวยความสะดวกใหม่
DSLไม่เพียงให้สิ่งอำนวยความสะดวกใหม่แก่คุณ แต่ยังให้คุณมีไวยากรณ์ใหม่และวิธีการเข้ารหัสใหม่อีกด้วย

แต่ถ้าพูดถึงDSL ภายนอกมันจะเป็นอีกเรื่องหนึ่ง DSL ภายนอกนั้นเหมือนกับภาษาการเขียนโปรแกรมขนาดเล็ก แต่แน่นอนว่ามันไม่ใช่ภาษาที่ใช้งานทั่วไปซึ่งหมายความว่ามันไม่สามารถแก้ปัญหาทั้งหมด แต่เป็นปัญหาที่เฉพาะเจาะจงแทน

— fronthem
แหล่งที่มา

1

ฉันคิดว่า API ทุกตัวเป็น DSL ที่ฝังตัว แต่การสนทนาไม่เป็นความจริง: ไม่ใช่ทุก ๆ DSL ที่ฝังตัวเป็น API เมื่อใช้ภาษาเป็นเครื่องมือในการรวมส่วนประกอบแล้วจะสามารถเรียกว่า API ได้

ทำไม API จึงถูกพิจารณาว่าเป็น DSL ในตัว? ก่อนอื่นมันเป็นภาษา: มันมีองค์ประกอบดั้งเดิม (ประเภทและการดำเนินงาน) ซึ่งสามารถรวมกัน (โดยวิธีการของภาษาโฮสต์) เพื่อสร้าง abstractions และแก้ปัญหาที่ซับซ้อน ตัวอย่างเช่น OpenGL API สามารถใช้เพื่อแสดงฉาก 3 มิติแบบเรียลไทม์ Collections API สามารถใช้ในการสร้างอัลกอริทึมที่ทำงานกับชุดของวัตถุและอื่น ๆ ประการที่สองเป็นโดเมนที่ชัดเจนโดยเฉพาะ ตัวอย่างเช่นโดเมนของ Collections API คือการจัดการชุดของวัตถุและโดเมนของ OpenGL API เป็นการแสดงผล 3 มิติ ดังนั้น API จึงเป็นภาษาเฉพาะโดเมน

แต่ไม่ใช่ทุก DSL ที่เป็น API ตัวอย่างเช่น DSL บางตัวไม่สามารถใช้งานได้โดยองค์ประกอบที่กำหนด ระบบทั้งหมดกำหนด abstractions บางส่วนและ abstractions ที่จัดการกับโดเมนเฉพาะบางรายการอาจถือได้ว่าเป็น DSL แต่นั่นไม่ได้หมายความว่าการนำไปใช้ของ abstractions เหล่านี้ควรเป็น "swappable" กล่าวอีกนัยหนึ่งพวกเขาไม่จำเป็นต้องสร้าง API . พวกเขาทำได้ แต่ไม่จำเป็นเสมอไป อย่างไรก็ตามในกรณีที่การใช้งานเป็น "องค์ประกอบ" (ขออภัยเนื่องจากขาดคำที่ดีกว่า), DSL จะกลายเป็น API อย่างแท้จริง

— proskor
แหล่งที่มา

นี่เป็นเพียงความคิดเห็นของคุณหรือคุณสามารถสำรองข้อมูลอย่างใด

— ริ้น

@gnat ฉันขยายคำตอบเพื่ออธิบายประเด็นของฉันต่อไป

— proskor