ไวยากรณ์มีความสำคัญในภาษาโปรแกรมหรือไม่ [ปิด]

41

อาจารย์คนหนึ่งของฉันบอกว่า "ไวยากรณ์คือ UI ของภาษาการเขียนโปรแกรม", ภาษาอย่าง Ruby มีความสามารถในการอ่านได้ดีและกำลังขยายตัว แต่เราเห็นโปรแกรมเมอร์จำนวนมากทำงานด้วย C \ C ++ ดังนั้นโปรแกรมเมอร์จึงสำคัญสำหรับไวยากรณ์ ควรจะยอมรับได้หรือไม่

ฉันชอบที่จะรู้ความคิดเห็นของคุณเกี่ยวกับเรื่องนี้

คำเตือน: ฉันไม่ได้พยายามที่จะเริ่มต้นการโต้แย้ง ฉันคิดว่านี่เป็นหัวข้อสนทนาที่ดี

อัปเดต: สิ่งนี้กลายเป็นหัวข้อที่ดี ฉันดีใจที่คุณทุกคนมีส่วนร่วม

programming-languages syntax

— Saif al Harthi
แหล่งที่มา

16

อืมดูเหมือนว่าสมมติว่าไวยากรณ์ C / C ++ ไม่ดีใช่ไหม แน่นอนว่าองค์ประกอบบางอย่างของเทมเพลต C ++ นั้นน่าเกลียด แต่เท่าที่ภาษาใช้ไป (ในอดีต) C / C ++ ยังคงสามารถอ่านได้มาก

— Macneil

2

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

— ฟัลอัล Harthi

9

มันเป็นหลักสูตรเชิงทฤษฎีหรือไม่? ข้อควรจำ: อาจารย์มักเป็นโปรแกรมเมอร์ที่แย่ที่สุด พวกเขาไม่รู้ว่ามันเป็นอย่างไรในป่า

— งาน

2

การอ่านอยู่ในสายตาของคนดู :)

— MAK

8

ไวยากรณ์ที่ดีไม่สามารถทำให้ภาษามีความสุขได้ดีกว่า แต่ไวยากรณ์ที่น่าสังเวชอาจทำให้ภาษาที่เลวร้ายลง)

— Dario

65

ใช่แล้ว. หากคุณมีข้อสงสัยให้ใช้APLหรือJหรือBrainfuckหรือแม้แต่ Lisp หรือ Forth ธรรมดาและเรียบง่ายแล้วลองทำความเข้าใจกับโปรแกรมที่ไม่เกี่ยวกับเรื่องนี้เลย จากนั้นเปรียบเทียบกับเช่น Python

จากนั้นเปรียบเทียบ Python (หรือ Ruby หรือแม้แต่ C #) เดียวกันกับสิ่งต่าง ๆ เช่นCobolหรือ VB6

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

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

26

เสียงกระเพื่อมเป็นที่เข้าใจอย่างแน่นอน

— cbrandolino

65

+1 สำหรับการรวมเสียงกระเพื่อมในรายการภาษาที่อ่านไม่ได้

— asmeurer

65

-1 สำหรับการรวมเสียงกระเพื่อมในรายการภาษาที่อ่านไม่ได้

— พอลนาธาน

27

การเขียนโปรแกรมโดยทั่วไปไม่สามารถอ่านได้โดยผู้ที่ไม่ได้ฝึกหัด ในฐานะที่เป็นโน้ตดนตรีและแผนผังทางสถาปัตยกรรม (= XY) สามารถอ่านได้เท่ากับ X == Y สำหรับผู้ที่รู้วิธีการอ่าน

— พอลนาธาน

6

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

— oosterwal

11

ในทางปฏิบัติฉันคิดว่ามันไม่สำคัญ ความสามารถในการอ่านได้ถูกกล่าวถึงข้างต้นแล้ว ปัญหาอื่นอาจเป็นจำนวนการกดแป้นพิมพ์เพื่อแสดงความคิด / algotithm? อีกประเด็นหนึ่งคือความง่ายในการพิมพ์ผิดง่าย ๆ ยากที่สายตามนุษย์จะจับได้

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

— Omega Centauri
แหล่งที่มา

การสังเกตที่ยอดเยี่ยมเกี่ยวกับการพิมพ์ผิดที่ง่ายต่อการแยกแยะ

7

แต่ในทางทฤษฎีไม่มีความแตกต่างระหว่างทฤษฎีและการปฏิบัติ

— งาน

10

ผมเชื่อว่าอาจารย์ของคุณจะหมายถึงน้ำตาลประโยค

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

ดังนั้นสิ่งที่อาจารย์ของคุณพูดถึงคือรหัสใด ๆ / ไวยากรณ์ที่เขียนด้วยภาษาโปรแกรมเดียวสามารถแสดงเป็นภาษาอื่นได้ในแบบเดียวกัน - หรือแม้แต่ภาษาเดียวกัน

Robert Martin ซึ่งดึงมาจากทฤษฎีบทการเขียนโปรแกรมเชิงโครงสร้างสรุปสิ่งที่โปรแกรมเมอร์ทำกับภาษาการเขียนโปรแกรมในงานปาฐกถาพิเศษที่RailsConf 2010: Robert Martin (วิดีโอyouTubeดูหลังจากทำเครื่องหมาย 14 นาทีถึงแม้ว่าฉันจะแนะนำทุกอย่าง):

ลำดับ (การมอบหมาย)
ตัวเลือก (ถ้ามีคำสั่ง)
ซ้ำ (ทำลูป)

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

ดังนั้นในสาระสำคัญ , ไวยากรณ์ไม่ได้เรื่อง แต่ถ้าคุณต้องการเฉพาะเจาะจงแน่นอนว่าภาษาและไวยากรณ์บางอย่างเหมาะสมกว่าสำหรับงานบางอย่างมากกว่าภาษาอื่นโดยที่คุณสามารถโต้แย้งว่าไวยากรณ์นั้นสำคัญ

— 5 revs
แหล่งที่มา

คุณจะเรียก C ว่าเป็นน้ำตาลซินแทกติกสำหรับแอสเซมเบลอร์หรือไม่

— Goran Jovic

1

ฉันจะ แต่ฉันเรียกร้องเรื่องไวยากรณ์ ;)

— Lennart Regebro

2

"... Robert Martin สรุปสิ่งที่โปรแกรมเมอร์ทำ ... " Robert Martin? โรเบิร์ตมาร์ติน คุณอาจต้องการพิจารณาบทความนี้: C. Böhm, G. Jacopini, "แผนภาพการไหล, เครื่องทัวริงและภาษาที่มีกฎการก่อตัวเพียงสองข้อเท่านั้น", Comm. ของ ACM, 9 (5): 366-371,1966 ซึ่งมักให้เครดิตเป็นแหล่งที่มาของ 'ทฤษฎีบทโปรแกรมโครงสร้าง' en.wikipedia.org/wiki/Structured_program_theorem

— leed25d

@ lee25d ฉันไม่ได้ตั้งใจให้เครดิตลุงบ๊อบในฐานะผู้สร้างสิ่งที่เป็นนามธรรม แต่เป็นแหล่งที่ฉันได้ยินเมื่อเร็ว ๆ นี้ (และเชื่อมโยงกับ) แต่ขอบคุณสำหรับลิงค์ฉันจะอัปเดตคำตอบของฉันเพื่อแสดงลิงค์ของคุณ

— spong

วิกิพีเดียที่ลิงก์ข้างต้นค่อนข้างไม่เข้าใจประวัติของ "ทฤษฎีการเขียนโปรแกรมเชิงโครงสร้าง" ความคิดที่คาดการณ์ไว้ Bohm & Jacopini การมีส่วนร่วมของ Bohm & Jacopini ได้แสดงให้เห็นว่ามันเป็นทฤษฎีบทไม่ใช่แค่การคาดเดาคือพวกเขาให้การพิสูจน์อย่างเป็นทางการที่เข้มงวด

— John R. Strohm

7

ใช่และไม่.

มีสองแง่มุมต่าง ๆ ในไวยากรณ์

การอ่าน
expressivity
parsability

ความสามารถในการอ่านได้ถูกกล่าวถึงแล้ว

การแสดงออกเป็นกรณีที่น่าสนใจ ฉันจะใช้ฟังก์ชั่นการส่งผ่านเป็นตัวอย่างเพราะมันเป็นจุดเบี่ยงเบนของความเจ็บปวดความหมาย / วากยสัมพันธ์

ลองยกตัวอย่าง C ++ ฉันสามารถสร้างฟังก์ชั่นลำดับแรกหลังจากแบบนี้:

class funcClass
{
  int operator()(int);
}
funcClass fun;

void run_func(funcClass fun)
{
   fun();
}

สำนวนนี้โดยทั่วไปมักใช้ในองค์ประกอบของโปรแกรมสเตฟอฟ

ในทางกลับกันฉันสามารถเลียนแบบมันด้วย Common LISP กับสิ่งนี้ :

(defun myfunc() )

(defun run_func(fun)
  (fun))

หรือใน Perl -

   sub myfunc
   {
   }

   sub run_func
   {
      my $func = shift;
      $func->();          #syntax may be a little off.
   }

หรือใน Python -

def myfunc():
    pass

def run_func(f):
    f()

สิ่งเหล่านี้ล้วนมีเนื้อหาความหมายเหมือนกันแม้ว่าตัวอย่าง C ++ จะมีเมทาดาทาบางประเภท ภาษาใดที่แสดงความคิดว่าการส่งผ่านฟังก์ชั่นที่มีลำดับสูงที่สุดดีที่สุด? เสียงกระเพื่อมสามัญแทบจะทำให้รูปแบบการสร้างประโยค C ++ ต้องการคลาสที่จะสร้างเพียงเพื่อ 'พกพา' ฟังก์ชัน Perl ค่อนข้างตรงไปตรงมาเกี่ยวกับการสร้างความแตกต่างในระดับหนึ่ง Python ก็เช่นกัน

วิธีใดที่เหมาะสมกับโดเมนปัญหามากที่สุด วิธีใดที่ดีที่สุดที่สามารถแสดงความคิดเห็นในหัวของคุณด้วย 'อิมพีแดนซ์ไม่ตรงกัน' ที่น้อยที่สุด?

ความสามารถในการวิเคราะห์คือ - ในใจ - เป็นเรื่องใหญ่ โดยเฉพาะอย่างยิ่งฉันอ้างถึงความสามารถของ IDE ในการแยกวิเคราะห์และสับภาษาโดยไม่มีข้อผิดพลาด การฟอร์แมตใหม่มีประโยชน์ ภาษาที่คั่นด้วยโทเค็นมีแนวโน้มที่จะแยกวิเคราะห์ได้ดี - ruby / c / pascal ฯลฯ

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

— พอลนาธาน
แหล่งที่มา

5

วากยสัมพันธ์สำคัญแน่นอนแม้ว่าคุณมักจะสังเกตเห็นมันมากขึ้นเมื่อมันไม่ได้ใช้งานง่ายและส่งเสริมข้อบกพร่อง ตัวอย่างเช่นเรื่องตลก "ข้อผิดพลาดสุดท้ายของโลก" ที่น่าอับอาย:

if (AlertCode = RED)
   {LaunchNukes();}

— Mason Wheeler
แหล่งที่มา

2

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

— Stephen Swensen

นี่คือเหตุผลที่คุณควรใช้เงื่อนไข Yoda นั่นคือif(RED = AlertCode)ไม่ควรรวบรวมเพราะสีแดงเป็นค่าคงที่ (หรือควรเป็น!)

— Malfist

4

@ มัลลิสต์: และด้วยเหตุนี้เราจึงเห็นว่าไวยากรณ์ที่ไม่ดีนำไปสู่ไวยากรณ์ที่แย่ยิ่งขึ้นเพื่อชดเชย เงื่อนไขโยดานั้นน่าเกลียดและอ่านยากเพราะไม่ใช่วิธีที่ผู้คนคิดในแนวคิดที่เกี่ยวข้อง ประเด็นของฉันก็เหมือน "นี่คือ (หนึ่งในหลาย ๆ เหตุผล) ทำไมคุณควรหลีกเลี่ยงตระกูล C ทุกครั้งที่ทำได้"

— Mason Wheeler

1

โชคดีที่รหัสนั้นมีข้อบกพร่องสองข้อ แน่นอนว่ามันจะเข้าเงื่อนไขเสมอ แต่ในนั้นมันเพิ่งได้รับการอ้างอิงถึงLaunchNukesขั้นตอนและไม่เคยเรียกใช้ วิกฤตหันไป!

— munificent

3

ขึ้นอยู่กับว่าREDเป็นอะไร ถ้าเป็น 0 LaunchNukes()จะไม่มีการเรียก

— dan04

5

ไวยากรณ์มีความสำคัญและฉันสามารถให้คุณสนับสนุนสองตัวอย่าง: Dylan ซึ่งเป็นเสียงกระเพื่อมกับไวยากรณ์ธรรมดามากขึ้นและ Liskell ซึ่งเป็น Haskell กับไวยากรณ์เหมือนเสียงกระเพื่อม ในแต่ละกรณีมีการเสนอภาษาที่แตกต่างกันซึ่งมีความหมายเหมือนกันทุกประการ แต่มีไวยากรณ์แตกต่างกันอย่างสิ้นเชิง

ในกรณีของ Dylan คิดว่าการทิ้ง s-expressions ลงไปในสิ่งที่ธรรมดากว่านั้นจะช่วยดึงดูดโปรแกรมเมอร์ที่กว้างขึ้น มันกลับกลายเป็นว่าไวยากรณ์ไม่ใช่สิ่งเดียวที่ป้องกันไม่ให้โปรแกรมเมอร์ใช้ Lisp

ในกรณีของ Liskell คิดว่าการใช้ s-expressions จะช่วยให้ใช้งานแมโครได้ง่ายขึ้น ปรากฎว่ามาโครไม่จำเป็นใน Haskell ดังนั้นการทดสอบก็ใช้ไม่ได้เช่นกัน

นี่คือสิ่งที่: ถ้าไวยากรณ์ไม่สำคัญกับใครการทดลองก็จะไม่ถูกลอง

— Larry Coleman
แหล่งที่มา

1

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

— Macneil

@Macneil: คุณพูดถูกเกี่ยวกับสิ่งเล็ก ๆ น้อย ๆ สายเกินไป การทิ้งไวยากรณ์ Lisp เป็นเพียงเล็บสุดท้ายในโลงศพ ฉันไม่คิดว่ามันเป็นเหตุผลหลักสำหรับความล้มเหลวของ Dylan แต่ฉันไม่แน่ใจว่าจะตอบคำถามอย่างไรเพื่อสะท้อนให้เห็นอย่างดีที่สุด

— Larry Coleman

ที่น่าสนใจฉันไม่รู้ว่าพวกเขามีไวยากรณ์เสียงกระเพื่อมในรุ่นก่อนหน้า ... นั่นคือเมื่อมันถูกตั้งชื่อว่าราล์ฟ? เดิมที Newton Message Pad จะมี Dylan เป็นแกนหลัก 15 ปีต่อมาเรามี iOS ที่มี Objective-C เป็นภาษาหลักซึ่งเป็นภาษาที่น้อยกว่าของ IMHO

— Macneil

ฉันจำรายละเอียดที่แน่นอนไม่ได้เมื่อ Dylan แพ้การแสดงออก ฉันซุ่มดัก comp.lang.lisp มานานแล้วและจำหัวข้อที่กำลังจะเกิดขึ้นในช่วงหนึ่งของการประณามการปิดทับวงเล็บ

— Larry Coleman

Dylan ถือกำเนิด Java และฉันไม่คิดว่าจะมีวิธี C ++ มากมายในตอนนั้น

— Tom Hawtin - tackline

3

คำตอบอาจจะอยู่ในการแยกสิ่งที่ "เรื่อง" ลงในปัจจัยคอมพิวเตอร์และปัจจัยมนุษย์ มีปัจจัยมนุษย์จำนวนมากในไวยากรณ์:

การอ่าน
ความกะทัดรัด
การบำรุงรักษา
การสอน
การป้องกันข้อผิดพลาด
ความเหมาะสมสำหรับวัตถุประสงค์ - เป็นภาษา REPL ภาษาสคริปต์หรือภาษาระบบขนาดใหญ่หรือไม่

เท่าที่คอมพิวเตอร์มีความกังวลประเด็นของวากยสัมพันธ์เพียงอย่างเดียวคือว่ามีความคลุมเครือที่จำเป็นต้องแก้ไขหรือไม่และต้องใช้เวลานานเท่าใดในการ tokenize / แยกรหัสเมื่อคอมไพล์ / ตีความ - และเป็นเพียงกรณีเท่านั้น ของหลังที่ค่าใช้จ่ายในการแยกเป็นประเด็นสำคัญ

นั่นอาจเป็นสาเหตุที่ทำให้คุณได้รับคำตอบที่เป็น "ใช่และไม่ใช่" เสมอ - เนื่องจากมีสองด้าน

— Rei Miyasaka
แหล่งที่มา

1

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

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

ทำไมคำตอบของฉันลงคะแนน?

— IAbstract

1

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

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

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

ฉันไม่มีความรู้สึกกับ C แต่ฝูงชน ML / Haskell อาจมีบางอย่างที่จะพูดเกี่ยวกับการทำเกลียว

— Rei Miyasaka

+1 สำหรับ "การเข้าถึง API": ฉันคิดว่านี่อาจสำคัญกว่าฟีเจอร์ภาษา

— Giorgio

1

ไวยากรณ์มีความสำคัญอย่างแน่นอน มันมีคุณค่าอย่างมากหากไวยากรณ์ภาษามีความยืดหยุ่นเพียงพอที่จะช่วยให้คุณสร้างภาษาเฉพาะโดเมนที่สะดวกและสามารถอ่านได้สำหรับแอปพลิเคชันของคุณ หากคุณสงสัยในเรื่องนี้ลองจินตนาการว่าการทำปัญหาพีชคณิตเป็นภาษาละตินแบบดั้งเดิมเช่นที่เคยทำมาก่อนศตวรรษที่ 18 หรือลองนึกภาพการทำแคลคูลัสโดยไม่ต้องใช้สัญลักษณ์ Leibniz ที่คุ้นเคย แน่นอนว่าข้อความแคลคูลัสไม่สามารถอ่านได้สำหรับมือใหม่ แต่ด้วยการฝึกฝนเราสามารถใช้แคลคูลัสและสัญกรณ์ไลบนิซเพื่อแก้ปัญหาที่ต้องใช้คลาสของหน้าคณิตศาสตร์ด้วยวิธีคลาสสิกได้อย่างรวดเร็ว การเขียนโปรแกรมเป็นอีกส่วนหนึ่งของคณิตศาสตร์ สัญกรณ์สะดวกใกล้กับโดเมนปัญหาสามารถสร้างความแตกต่างอย่างมากในการผลิต

— เควินไคลน์
แหล่งที่มา

DSL ไม่ได้เกี่ยวกับซินแท็กซ์น้ำตาลทั้งหมด ความหมายเป็นส่วนที่มีคุณค่ามากกว่า มันก็โอเคที่จะออกแบบ eDSLs ที่จะไม่เพิ่มอะไรในไวยากรณ์ที่มีอยู่

— SK-logic

@SK: แน่นอน แต่ความหมายอยู่ภายใต้การควบคุมที่สมบูรณ์ของโปรแกรมเมอร์ ไวยากรณ์ถูก จำกัด โดยภาษาพื้นฐาน เราสามารถสร้าง DSL ที่สะดวกภายใน Groovy และภาษาอื่น ๆ แต่ไม่มากใน Java

— kevin cline

1

นี่คือโปรแกรมที่คำนวณคณาจารย์ของ 6:

S(K(S(S(SI(KK))(K(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)
(S(KS)(S(K(SI))K))))(KK)KK))))))(S(K(S(S(K(SI))(SII)(S(K(SI))(SII))
(S(K(S(S(KS)(S(KK)(S(SI(KK))(K(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)KK)))))))
(S(K(S(S(KS)(S(K(SI(KK)))(SI(K(KI)))))))(S(K(S(K(S(S(K(SI))(SII)(S(K(SI))
(SII))(S(K(S(S(KS)(SI(KK)))))(S(S(KS)(S(K(S(KS)))(S(K(S(KK)))(S(S(KS)K)
(K(SI(K(KI))))))))(K(K(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)))))))))))
(S(S(KS)K)(K(SI(K(KI)))))))))))(S(S(KS)K)(K(SI(K(KI))))))(S(S(KS)(S(KK)(S(KS)
(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)
(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)
(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)
(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)KK)))))))

ไวยากรณ์น้อยที่สุด:

expression: expression term | term
term: ‘(‘ expression ‘)‘ | combinator
combinator: 'S' | 'K' | 'I'

ดูเหมือนว่ามีความเชื่อทั่วไปว่าไวยากรณ์เป็นสิ่งที่ทำให้ภาษายาก บ่อยครั้งที่ผู้เชื่อถืออยู่บ่อยๆสิ่งที่ตรงกันข้ามก็เป็นจริง

โปรดทราบว่าไวยากรณ์ LISP สามารถอ่านได้เท่านั้น (หากเลย) เนื่องจากมีไวยากรณ์มากกว่าด้านบน ดังนั้นหากแฟน LISP บอกคุณว่า "ไวยากรณ์ไม่สำคัญ" ขอให้พวกเขาเป็นผลและลอง SKI แคลคูลัส พวกเขาจะต้องยอมรับว่าไวยากรณ์บิตไม่เลวหลังจากทั้งหมด

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

ฉันไม่สามารถลงคะแนนได้ นี่คือคำตอบที่ชาญฉลาดจริงๆ +1

— scravy

0

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

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

6

"เวลาสู่ตลาด", "ค่าใช้จ่ายเพื่อผลประโยชน์" เป็นต้น

— งาน

0

ใช่ไวยากรณ์มีความสำคัญแม้ว่าจะอ่านได้จริงๆเท่านั้น เปรียบเทียบ:

for i in range(10):
   print(i)

(ใช่ว่าเป็นงูหลาม) ด้วย

FOR(i<-RNG-<10){PRN<-i}

(ใช่ว่าเป็นภาษาที่ฉันเพิ่งสร้างขึ้น) ทั้งสองจะทำสิ่งเดียวกันในลักษณะเดียวกัน แต่ไวยากรณ์แตกต่างกันและ Python อ่านง่ายกว่า ใช่แล้วไวยากรณ์มีความสำคัญอย่างแน่นอน แม้แต่เรื่องของ

 @property
 def year(self):
     return self._date.year

อ่านง่ายกว่า

 def year(self):
     return self._date.year
 year = property(year)

— Lennart Regebro
แหล่งที่มา

0

ใช่แน่นอน

หากคุณต้องการเริ่มต้นเปลวไฟขนาดใหญ่ถามคนที่พวกเขาใส่วงเล็บเปิดในภาษา C-like ฉันหมายถึง

void foo() {
  // blah
}

VS

void foo()
{
  // blah
}

หรือแม้แต่ VS

void foo() 
{ // blah
}

และนี่เป็นเพียงภาษาเดียวกัน! นอกจากนี้ให้ถามพวกเขาเกี่ยวกับช่องว่างที่พวกเขาวางพวกเขา (ชื่อฟังก์ชั่นและ bracet ผู้ประกอบการ ฯลฯ )

รับประกัน 1,000 คำตอบ!

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

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

— ฟัลอัล Harthi

0

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

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

ที่กล่าวว่าหากเป็นverbose มากเกินไปก็สามารถไปยังจุดที่มันมีผลต่อการอ่าน ฉันต้องการเห็นบางสิ่งเช่น:

foreach (สตริงใน stringList)

ไปที่:

สำหรับทุกสตริงที่อยู่ในรายการตามที่อ้างอิงโดยตัวแปร stringlist

...วันใดวันหนึ่ง!

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

0

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

terse และ opaque มาก (Perl) นั้นแย่เหมือน verbose และ wordy (AppleScript) มากเกินไป

จะต้องมีความสมดุลลดอุปสรรคในการเข้าการผลิตสูงและบำรุงรักษาง่าย

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

-2

อีกสิ่งที่ควรพิจารณาคือภาษาการเขียนโปรแกรมที่มีไวยากรณ์ของ nicer ง่ายต่อการแยกวิเคราะห์ทำให้คอมไพเลอร์ง่ายต่อการเขียนเร็วขึ้นและมีแนวโน้มที่จะเกิดข้อบกพร่องน้อยลง

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

3

อืมม ... 10,000 SLOC จากparse.yใน Ruby ไม่เห็นด้วย ไม่มีเหตุผลใดที่เป็นทุกหนึ่งเดียวของ 7 ในปัจจุบันหรือในเร็ว ๆ นี้การผลิตพร้อมการดำเนินงานทับทิมใช้เดียวกัน parser และทุกเดียวการดำเนินทับทิมที่ได้เคยพยายามที่จะพัฒนาตัวเอง parser ล้มเหลว

— Jörg W Mittag

แล้วก็มีภาษา ADA ที่น่าอับอาย ตามข้อกำหนดภาษามี 100 โปรแกรมที่ต้องทำงานอย่างถูกต้องเพื่อรับรองคอมไพเลอร์ มีบางสิ่งที่ลึกซึ้งเกี่ยวกับไวยากรณ์ เพื่อที่จะให้เรื่องราวสั้น ๆ คอมไพเลอร์ ADA ทุกต้นสร้างตัว flunked สองสามโปรแกรมเหล่านี้ และไม่ใช่เรื่องง่าย ๆ ในการแก้ไขข้อบกพร่อง แต่พวกเขาจำเป็นต้องเริ่มใหม่ตั้งแต่เริ่มต้น แม้ว่าจะได้รับการสนับสนุนจากรัฐบาลอย่างมาก (สัญญา DOD ทั้งหมดได้รับคำสั่งจาก ADA) แต่ก็ตายอย่างน่าสังเวช

— Omega Centauri

-2

จะกล่าวง่ายๆ: ไวยากรณ์เช่นนี้ไม่สำคัญ ความหมายที่คุณสามารถแสดงออกผ่านมันมีความหมาย

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

5

ในฐานะการออกกำลังกายเขียนตัวแยกวิเคราะห์ที่ซับซ้อนใน C แล้วโปรแกรมควบคุมอุปกรณ์ใน Haskell ไวยากรณ์ช่วยคุณได้ไหม จากนั้นทำอีกวิธีหนึ่งโดยรักษาความหมายของทั้งสองโปรแกรมไว้อย่างเคร่งครัด </irony>

— 9000

1

@ 9000: ฉันเคยเห็นไดรเวอร์อุปกรณ์สองสามตัวใน Haskell ฉันไม่เห็นอะไรผิดปกติกับพวกเขา สนใจที่จะทำอย่างละเอียด?

— Jörg W Mittag

2

@ 9000 ระบุว่ามันยากแค่ไหนที่จะได้รับไดรเวอร์อุปกรณ์ใน C ฉันไม่แน่ใจว่าคุณได้เลือกตัวอย่างที่ดี

1

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

— back2dos

@ 9000 จะไม่เป็นปัญหาในการเขียนโปรแกรมแยกวิเคราะห์ใน Haskell ที่มีไวยากรณ์คล้าย C (หรือไดรเวอร์โดยใช้ C ที่มีไวยากรณ์เหมือน Haskell)

— SK-logic