क्या प्रोग्रामिंग भाषा में वाक्य रचना वास्तव में मायने रखती है? [बन्द है]

41

मेरे प्रोफेसरों में से एक का कहना है "वाक्य रचना एक प्रोग्रामिंग भाषा का यूआई है", रूबी जैसी भाषाओं में बहुत पठनीयता है और यह बढ़ रही है, लेकिन हम बहुत सारे प्रोग्रामर को C \ C ++ के साथ उत्पादक देखते हैं, इसलिए प्रोग्रामर के रूप में यह वास्तव में मायने रखता है कि वाक्य रचना स्वीकार्य होना चाहिए?

मुझे उस पर आपकी राय जानना अच्छा लगेगा।

अस्वीकरण: मैं एक तर्क शुरू करने की कोशिश नहीं कर रहा हूँ। मुझे लगा कि यह चर्चा का एक अच्छा विषय है।

अपडेट: यह एक अच्छा विषय है। मुझे खुशी है कि आप सभी इसमें भाग ले रहे हैं।

programming-languages  syntax 
— सैफ अल हरथी
स्रोत
16
हम्म, यह लगता है कि C / C ++ सिंटैक्स खराब है? निश्चित रूप से C ++ टेम्प्लेट के कुछ तत्व बदसूरत हैं, लेकिन जहाँ तक भाषाएँ (ऐतिहासिक रूप से) जाती हैं, C / C ++ अभी भी बहुत, बहुत पठनीय है।
— मैक्नील
2
अच्छी तरह से मैं कई प्रोग्रामर्स को जानता हूं, जो उस पर असहमत हैं, ज्यादातर माणिक समुदाय से, हालांकि, लिस्प की तुलना में यह अधिक पठनीय है जहां तक ​​मैं बता सकता हूं :)
— सैफ अल हरथी
9
क्या यह एक सैद्धांतिक पाठ्यक्रम था? याद रखें: प्रोफेसर अक्सर सबसे खराब प्रोग्रामर में से कुछ होते हैं। उन्हें इस बात का कोई अंदाजा नहीं है कि जंगल में ऐसा क्या है।
— नौकरी
2
पठनीयता देखने वाले की नजर में है :)।
— MAK
8
अच्छा वाक्यविन्यास एक दुखी भाषा को बेहतर नहीं बना सकता है। लेकिन दयनीय वाक्य रचना एक अच्छी भाषा को बदतर बना सकती है;)
— डारियो

जवाबों:

65

हाँ यह करता है। यदि आप संदेह में हैं, तो एपीएल , या जे , या ब्रेनफक , या यहां तक ​​कि सादा और सरल लिस्प या फोर्थ लें, और उस पर किसी भी पूरी तरह से तुच्छ कार्यक्रम को समझने की कोशिश न करें। फिर उदाहरण के लिए अजगर की तुलना करें।

फिर उसी पायथन (या रूबी, या यहां तक ​​कि # #) की तुलना कोबोल या वीबी 6 जैसी चीजों से करें ।

मैं यह कहने की कोशिश नहीं कर रहा हूं कि बालों का सिंटैक्स खराब है और प्राकृतिक-भाषा-जैसा सिंटैक्स सभी परिस्थितियों में अच्छा है। लेकिन obvoiusly वाक्य रचना करता है एक बड़ा फर्क। सब सब में, सब कुछ आप सबसे सुंदर प्रोग्रामिंग भाषा में लिख सकते हैं जिसे आप ट्यूरिंग मशीन प्रोग्राम के रूप में भी लिख सकते हैं - लेकिन आप आमतौर पर नहीं चाहते हैं, क्या आप?

— 9000
स्रोत
26
लिस्प निश्चित रूप से समझ में आता है।
— cbrandolino
65
अपठनीय भाषाओं की सूची में लिस्प को शामिल करने के लिए +1।
— asmeurer
65
-1 अपठनीय भाषाओं की सूची में लिस्प को शामिल करने के लिए।
— पॉल नाथन
27
सामान्य रूप से प्रोग्रामिंग करना बिना पढ़े लिखे के लिए अपठनीय है। जैसा कि संगीत संकेतन और वास्तुशिल्प फ़्लोरप्लांस हैं। (= XY) केवल X == Y के रूप में पठनीय है, किसी को जो पढ़ना जानता है।
— पॉल नाथन
6
मुझे एपीएल बहुत पसंद था, और जब तक कि कोड जानबूझकर मोटे तौर पर लिखा नहीं गया था (बहुत आसान है), यह पढ़ना काफी आसान था। वाक्य रचना की शक्ति यह थी कि आप एपीएल कोड की 2 या 3 पंक्तियों में एल्गोरिदम प्रोग्राम कर सकते थे, जिसमें सी, फोरट्रान, या सीओबीओएल की दर्जनों या सैकड़ों लाइनों की आवश्यकता होगी। एपीएल जैसी भाषा की संक्षिप्तता और शक्ति इस चर्चा के लिए महत्वपूर्ण है क्योंकि किसी अन्य भाषा की सैकड़ों कोड लाइनों के माध्यम से पढ़ने की कोशिश करना एपीएल के अस्पष्ट तत्वों को नष्ट करने के रूप में निराशाजनक हो सकता है।
— ओस्टरवाल
11

व्यवहार में मुझे लगता है कि यह मायने रखता है। पठनीयता पहले ही ऊपर चर्चा की जा चुकी है। एक और मुद्दा यह हो सकता है कि एक विचार / चर्चा को व्यक्त करने के लिए कितने कीस्ट्रोक्स हैं? फिर भी एक और मुद्दा यह है कि मानव टाइप को पकड़ने के लिए सरल टाइपोस के लिए कितना आसान है, और वे कितनी शरारत कर सकते हैं।

मैंने कुछ संदर्भों में विश्लेषण करने, और / या किसी अन्य कंप्यूटर प्रोग्राम के माध्यम से कोड के टुकड़े उत्पन्न करने के लिए भी इसे उपयोगी पाया है। भाषा को पार्स करने, और / या सही कोड उत्पन्न करने की कठिनाई तब सीधे प्रभाव डालती है कि ऐसे उपकरण बनाने / बनाए रखने के लिए कितना प्रयास आवश्यक है।

— ओमेगा सेंटौरी
स्रोत
टाइपोस के बारे में महान अवलोकन जो भेद करना आसान है।
7
लेकिन सिद्धांत रूप में सिद्धांत और व्यवहार में कोई अंतर नहीं है।
— जॉब
10

मेरा मानना ​​है कि आपके प्रोफेसर ने सिंथेटिक शुगर का जिक्र किया है ।

Syntactic चीनी एक कंप्यूटर विज्ञान शब्द है जो एक प्रोग्रामिंग भाषा के भीतर वाक्यविन्यास को संदर्भित करता है जिसे चीजों को पढ़ने या व्यक्त करने के लिए आसान बनाने के लिए डिज़ाइन किया गया है, जबकि उन्हें व्यक्त करने के वैकल्पिक तरीके मौजूद हैं ।

तो आपका प्रोफेसर जो कुछ भी कह रहा है, वह यह है कि जो भी कोड / वाक्य रचना एक प्रोग्रामिंग भाषा में लिखी गई है, उसे अन्य भाषाओं में भी वही - या यहाँ तक कि उसी भाषा में भी व्यक्त किया जा सकता है।

रॉबर्ट मार्टिन, स्ट्रक्चर्ड प्रोग्रामिंग प्रमेय से खींचते हुए , सारांकित करते हैं कि प्रोग्रामर मूल रूप से RailsConf 2010 में अपने मुख्य वक्ता के रूप में प्रोग्रामिंग भाषाओं के साथ करते हैं : रॉबर्ट मार्टिन ( youTube वीडियो, 14 मिनट के निशान के बाद देखें, हालांकि मैं पूरी बात की सिफारिश करता हूं:

  • अनुक्रम (असाइनमेंट)
  • चयन (यदि कथन)
  • Iteration (डू-लूप्स)

यह सब प्रोग्रामर करते हैं, एक प्रोग्रामिंग भाषा से दूसरे में, बस एक अलग वाक्यविन्यास या यूजर इंटरफेस (यूआई) में। यह वही है जो मुझे लगता है कि आपके प्रोफेसर को मिल रहा था, अगर वह प्रोग्रामिंग भाषाओं के बारे में सारगर्भित बोल रहा है।

तो में सार , वाक्य रचना कोई फर्क नहीं पड़ता । लेकिन यदि आप विशिष्ट होना चाहते हैं, तो स्पष्ट रूप से कुछ भाषाओं और वाक्यविन्यास दूसरों की तुलना में कुछ कार्यों के लिए बेहतर हैं, जिससे आप तर्क दे सकते हैं कि वाक्यविन्यास मायने रखता है।

— सूर्योदय
स्रोत
क्या आप कोडांतरक के लिए सी सिर्फ एक सिंटैक्टिक चीनी कहेंगे?
— गोरान जोविक
1
मैं। लेकिन मैं सिंटैक्स मामलों का दावा करता हूं। ;)
— लेन्नर्ट रेग्रोब
2
"... रॉबर्ट मार्टिन सार क्या प्रोग्रामर मौलिक रूप से करते हैं ..." रॉबर्ट मार्टिन? रॉबर्ट मार्टिन ?? आप वास्तव में इस पत्र पर विचार करना चाह सकते हैं: सी। बोहम, जी। जैकोपिनी, "फ्लो डायग्राम्स, ट्यूरिंग मशीन्स एंड लैंग्वेजेज विद टू टू फॉर्मेशन रूल्स", कॉम। एसीएम, 9 (5): 366-371,1966 पर। जिसे आमतौर पर 'संरचित कार्यक्रम प्रमेय' के स्रोत के रूप में श्रेय दिया जाता है। en.wikipedia.org/wiki/Structured_program_theorem
— leed25d
@ lee25d का अर्थ यह नहीं था कि मैं चाचा बॉब को अमूर्त के प्रवर्तक के रूप में श्रेय दूंगा, लेकिन स्रोत के रूप में जहां मैंने इसे हाल ही में सुना (और इससे जुड़ा हुआ है)। लेकिन लिंक के लिए धन्यवाद, मैं आपके लिंक को प्रतिबिंबित करने के लिए अपने उत्तर को अपडेट करूंगा।
— Spong
ऊपर जुड़ा विकिपीडिया टुकड़ा "संरचित प्रोग्रामिंग प्रमेय" के इतिहास को काफी नहीं समझता है। इस विचार से पहले बोहम और जैकोपिनी का अनुमान लगाया गया था। बोहम और जैकोपिनी का योगदान दिखा रहा था कि यह एक प्रमेय था, न कि केवल एक अनुमान, यानी, उन्होंने एक कठोर औपचारिक प्रमाण प्रदान किया।
— बजे जॉन आर। स्ट्रोह डे
7

हां और ना।

वाक्यविन्यास के लिए कुछ अलग पहलू हैं।

  • पठनीयता
  • expressivity
  • parsability

पठनीयता का उल्लेख पहले ही किया जा चुका है।

स्पष्टता एक दिलचस्प मामला है। मैं एक उदाहरण के रूप में फ़ंक्शन-पासिंग का उपयोग करने जा रहा हूं, क्योंकि यह अर्थ / वाक्य-संबंधी दर्द के विभक्ति बिंदु की तरह है।

उदाहरण के लिए C ++ लेते हैं। मैं इस फैशन के बाद पहला क्रम बना सकता हूं:

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

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

इस विशेष मुहावरे का इस्तेमाल आमतौर पर स्टेपनोव के एलिमेंट्स ऑफ प्रोग्रामिंग में किया जाता है ।

दूसरी ओर, मैं इसे आम लिस्प में कुछ इस तरह से नकल कर सकता हूं :

(defun myfunc() )

(defun run_func(fun)
  (fun))

या, पर्ल में - 

   sub myfunc
   {
   }

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

या, पायथन में - 

def myfunc():
    pass

def run_func(f):
    f()

इन सभी में अनिवार्य रूप से - एक ही अर्थ सामग्री है, हालांकि सी ++ उदाहरण कुछ प्रकार के मेटाडेटा को वहन करता है। कौन सी भाषा एक उच्च-क्रम फ़ंक्शन को पारित करने के विचार को सबसे अच्छा व्यक्त करती है? आम लिस्प मुश्किल से एक वाक्यात्मक बदलाव करता है। C ++ को फंक्शन को 'कैरी' करने के लिए एक वर्ग बनाने की आवश्यकता होती है। कुछ अलग स्तर बनाने के बारे में पर्ल बहुत सीधा है। तो पायथन है।

कौन सा दृष्टिकोण समस्या डोमेन के लिए सबसे उपयुक्त है? कौन सा दृष्टिकोण आपके सिर में विचारों को कम से कम 'प्रतिबाधा बेमेल' के साथ व्यक्त कर सकता है?

पार्सबिलिटी है - मेरे दिमाग में- एक बड़ी बात। विशेष रूप से, मैं त्रुटियां किए बिना आईडीई को भाषा को पार्स करने और काटने की क्षमता का उल्लेख करता हूं। रिफॉर्मेटिंग उपयोगी है। टोकन-सीमांकित भाषाएं अच्छी तरह से पार्स करती हैं - रूबी / सी / पास्कल, आदि।

यद्यपि विचार करें - वास्तविक दुनिया के मुद्दों को हल करने के लिए हर गंभीर भाषा के साथ सभी प्रकार की प्रमुख प्रणालियां बनाई गई हैं। हालाँकि सिंटैक्स कुछ चीज़ों को व्यक्त करने के लिए एक बाधा है, लेकिन यह एक काम-के-सक्षम बाधा है। ट्यूरिंग तुल्यता और वह सब।

— पॉल नाथन
स्रोत
5

सिंटैक्स निश्चित रूप से मायने रखता है, हालांकि आप इसे तब अधिक नोटिस करते हैं जब यह अनपेक्षित होता है और बग को प्रोत्साहित करता है। उदाहरण के लिए, कुख्यात "दुनिया का आखिरी बग" मजाक:

if (AlertCode = RED)
   {LaunchNukes();}
— मेसन व्हीलर को दर्शाता है
स्रोत
2
+1: दिलचस्प है, मैंने इस कुख्यात "दुनिया के आखिरी बग" मजाक को कभी नहीं देखा (या स्वीकार किया है)। लेकिन मैं देख सकता हूं कि किसी भाषा (या वास्तव में शब्दार्थ) के सिंटैक्स के आधार पर, उस छद्म कोड का परिणाम कुछ भी हो सकता है। सिमेंटिक कोण को देखते हुए, यह वास्तव में सांस्कृतिक गलतफहमी के क्लासिक मामले तक चाक हो सकता है।
— स्टीफन स्वेंसेन
यही कारण है कि आपको Yoda सशर्त का उपयोग करना चाहिए, अर्थात if(RED = AlertCode)कभी संकलन नहीं करना चाहिए क्योंकि RED स्थिर है (या होना चाहिए!)
— Malfist
4
@ मालफिस्ट: और इस प्रकार हम देखते हैं कि खराब सिंटैक्स क्षतिपूर्ति के लिए और भी बदतर सिंटैक्स की ओर जाता है। योदा की स्थितियां बदसूरत और पढ़ने में कठिन हैं क्योंकि वे उस तरह से नहीं हैं जैसे लोग संबंधित अवधारणा के बारे में सोचते हैं। मेरी बात और थी "यह (कई कारणों में से एक) है कि आपको जब भी संभव हो सी परिवार से बचना चाहिए।"
— मेसन व्हीलर
1
खैर, सौभाग्य से, उस कोड में दो बग हैं। निश्चित रूप से, यह हमेशा सशर्त दर्ज करेगा, लेकिन वहां, यह सिर्फ LaunchNukesप्रक्रिया का संदर्भ प्राप्त कर रहा है , और कभी भी इसे लागू नहीं कर रहा है। संकट टली!
— उदार
3
निर्भर करता है कि क्या REDहै। अगर यह 0 है, तो LaunchNukes()कभी नहीं बुलाया जाएगा।
— दान ०४
5

सिंटैक्स मायने रखता है, और मैं आपको दो सहायक उदाहरण दे सकता हूं: डायलन, जो एक अधिक पारंपरिक वाक्यविन्यास के साथ लिस्प है, और लिस्केल, जो लिस्प जैसे सिंटैक्स के साथ हास्केल है। प्रत्येक मामले में, भाषा का एक प्रकार प्रस्तावित किया गया था जिसमें बिल्कुल समान शब्दार्थ था, लेकिन मौलिक रूप से अलग वाक्यविन्यास।

डायलन के मामले में, यह सोचा गया था कि कुछ अधिक पारंपरिक के पक्ष में एस-एक्सप्रेशन को छोड़ने से प्रोग्रामर की एक विस्तृत श्रृंखला को आकर्षित करने में मदद मिलेगी। यह पता चला कि सिंटेक्स केवल प्रोग्रामर को लिस्प का उपयोग करने से रोकना नहीं था।

लिस्केल के मामले में, यह सोचा गया था कि एस-एक्सप्रेशन के उपयोग से मैक्रोज़ के आसान उपयोग की अनुमति मिल जाएगी। यह पता चला कि मैक्रोज़ वास्तव में हास्केल में आवश्यक नहीं हैं, इसलिए यह प्रयोग भी काम नहीं किया।

यहाँ बात है: अगर वाक्य रचना किसी के लिए भी मायने नहीं रखती, तो न तो प्रयोग करने की कोशिश की जाती।

— लैरी कोलमैन को दर्शाता है
स्रोत
1
डायलन बहुत कम था, अन्य भाषाओं की तुलना में बहुत देर हो गई। इसके पक्ष में जो कुछ था वह उसके लिए नहीं बन सका। हम यह मानने में असफलता की तुलना में अधिक अनुमान नहीं लगा सकते कि यह वाक्य रचना की विफलता है।
— 21
@Macneil: आप बहुत कम, बहुत देर की बात के बारे में सही हैं। लिस्प सिंटैक्स को गिराना ताबूत में सिर्फ अंतिम कील था। मुझे नहीं लगता कि यह डायलन की विफलता का मुख्य कारण था, लेकिन मुझे यकीन नहीं है कि सबसे अच्छा उत्तर देने के लिए उत्तर को फिर से कैसे कहा जाए।
— लैरी कोलमैन
दिलचस्प है, मुझे नहीं पता था कि उनके पास पहले के संस्करण में लिस्प सिंटैक्स था ... क्या यह तब था जब इसका नाम राल्फ था? न्यूटन संदेश पैड मूल रूप से डायलन के मूल में था। 15 साल बाद, हमारे पास कोर में ऑब्जेक्टिव-सी के साथ आईओएस, दो की कम भाषा, आईएमएचओ है।
— मैकनील
मुझे सटीक विवरण याद नहीं है कि डायलन ने एस-एक्सप्रेशन कब खो दिया। मैं एक लंबे समय के लिए comp.lang.lisp पर झूठ बोल रहा हूं, और कोष्ठक पर उनके आवधिक flamewars में से एक में आने वाले विषय को याद रखें।
— लैरी कोलमैन
डायलन जावा की भविष्यवाणी करता है, और मुझे नहीं लगता कि तब कई सी ++ रास्ते थे।
— टॉम हॉकिन - 0
3

इसका उत्तर यह हो सकता है कि कंप्यूटर कारकों और मानव कारकों में "मामलों" को अलग करने में क्या हो । वाक्य रचना में कई मानवीय कारक हैं:

  • पठनीयता
  • संक्षिप्तता
  • रख-रखाव
  • शिक्षा शास्त्र
  • त्रुटि की रोकथाम
  • उद्देश्य के लिए उपयुक्तता - क्या यह एक REPL भाषा, एक स्क्रिप्ट भाषा या एक बड़ी प्रणाली भाषा है?

जहां तक ​​कंप्यूटर का सवाल है, सिंटैक्स का एकमात्र मुद्दा यह है कि अस्पष्टताएं हैं या नहीं, जिन्हें हल करने की आवश्यकता है, और संकलन / व्याख्या पर कोड को टोकन / पार्स करने में कितना समय लगता है - और यह केवल मामले में है उत्तरार्द्ध जहां पार्सिंग का ओवरहेड एक महत्वपूर्ण मुद्दा है।

इसीलिए हो सकता है कि आपको हमेशा इस सवाल का "हां और ना" का जवाब मिले - क्योंकि इसके दो पहलू हैं।

— री मियाँका
स्रोत
1

वाक्यविन्यास के बिना, हमारे पास एक सामान्य "टेम्पलेट" नहीं होगा, जिसमें से संवाद करने के लिए, मानव स्तर पर, कोड के ब्लॉक का इरादा होता है। सिंटैक्स एक सामान्य ढांचा प्रदान करता है जिसमें से कंपाइलरों को मानकीकृत किया जा सकता है; तरीकों को साझा किया जा सकता है; रखरखाव को सरल बनाया जा सकता है।

— IAbstract
स्रोत
मेरे जवाब को वोट-डाउन क्यों किया गया?
— आइब्रीस्ट
1

मुझे लगता है कि वास्तव में क्या मायने रखता है एपीआई एक्सेस , और जरूरत पड़ने पर निम्न-स्तरीय कार्यक्षमता (जैसे मेमोरी कंट्रोल और लॉकिंग) की उपलब्धता। अधिकांश अन्य भाषाओं में ये सुविधाएँ शामिल हैं। समस्या यह है, जब आपको अतिरिक्त कार्यक्षमता की आवश्यकता होती है, तो इसे लागू करने के लिए आपको अक्सर C जैसी भाषा का उपयोग करना पड़ता है। और यह आपके द्वारा उपयोग की जाने वाली भाषा के साथ C को बोझिल करने वाली इंटरफेसिंग है।

वेब विकास (और गणित) को छोड़कर हर चीज के लिए मैंने पाया है कि C / C ++ अभी भी एक ऑपरेटिंग सिस्टम की भाषा है और एक अनुप्रयोग है। यह वही है जो सच बहु-थ्रेडेड, प्रीफॉर्मिंग, क्रॉस-प्लेटफॉर्म एप्लिकेशन डेवलपमेंट के लिए सबसे अधिक समर्थित है। और C का सिंटेक्स ठीक है। बस बहुत ही सरल और अपेक्षाकृत क्रिया। आश्चर्यजनक सिंटैक्स वास्तव में इतना मायने नहीं रखता है। पावर और एपीआई उपलब्धता हम सभी को अन्य लोगों के कोड के साथ इंटरफेस करने की आवश्यकता है (जो कि सी या उसके व्युत्पन्न में लिखे गए अधिकांश समय है)।

— unixman83
स्रोत
मेरे पास सी के साथ कोई योग्यता नहीं है, लेकिन एमएल / हास्केल भीड़ को शायद थ्रेडिंग के बारे में कुछ कहना होगा।
— री मियासका
"एपीआई एक्सेस" के लिए +1: मुझे लगता है कि यह भाषा की विशेषताओं से भी अधिक महत्वपूर्ण हो सकता है।
— जियोर्जियो
1

सिंटेक्स निश्चित रूप से मायने रखता है। यदि भाषा वाक्यविन्यास आपके अनुप्रयोग के लिए सुविधाजनक और पठनीय डोमेन-विशिष्ट भाषा बनाने की अनुमति देने के लिए पर्याप्त लचीला है तो यह बहुत मूल्यवान है। यदि आपको इस पर संदेह है, तो बस प्रोसैबिक लैटिन में बीजगणित की समस्याओं को करने की कल्पना करें, जैसा कि 18 वीं शताब्दी से पहले किया गया था, या अब परिचित लाइबनिज संकेतन के बिना पथरी करने की कल्पना करें। ज़रूर, एक पथरी का पाठ एक नौसिखिए के लिए अपठनीय है, लेकिन अभ्यास के साथ हम गणनाओं और लाइबनिज़ नोटेशन का उपयोग उन समस्याओं के एक वर्ग को जल्दी से हल करने के लिए कर सकते हैं जिन्हें शास्त्रीय विधियों के साथ गणित के पृष्ठों की आवश्यकता थी। प्रोग्रामिंग सिर्फ गणित का एक और बिट है। एक सुविधाजनक अंकन, समस्या डोमेन के करीब, उत्पादकता में भारी अंतर ला सकता है।

— केविन क्लाइन
स्रोत
DSLs सिंटेक्स शुगर के बारे में बिलकुल नहीं हैं। शब्दार्थ एक बहुत अधिक मूल्यवान हिस्सा है। ईडीएसएल को डिजाइन करना ठीक है जो किसी मौजूदा सिंटैक्स में कुछ भी नहीं जोड़ेगा।
— एसके-लॉजिक
@ एसके: यकीन है, लेकिन शब्दार्थ पूरे प्रोग्रामर के नियंत्रण में है। सिंटेक्स को आधार भाषा द्वारा विवश किया जाता है। हम ग्रूवी और अन्य भाषाओं के भीतर सुविधाजनक डीएसएल का निर्माण कर सकते हैं, लेकिन जावा में इतना नहीं।
— केविन क्लाइन
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 कलन की कोशिश करें। उन्हें यह स्वीकार करना होगा कि थोड़ा सा वाक्यविन्यास इतना बुरा नहीं है।

— इंगो
स्रोत
मैं डाउन वोट को समझ नहीं पा रहा हूं। यह एक बहुत ही व्यावहारिक जवाब है। +1
— स्कर्वी
0

मुझे नहीं लगता कि यह व्यक्तिगत पसंद से परे है। सभी चीजें (प्रदर्शन, क्षमताएं, आदि) समान होने के बाद मैं देख सकता हूं कि कोई भाषा वाक्य रचना पर अधिक भार क्यों डालेगा, लेकिन सी / सी ++ या किसी भी अन्य भाषा की भाषा के प्रदर्शन को पारित करने के लिए चुनना बेहतर होगा, क्योंकि यह नौकरी के लिए बेहतर अनुकूल है। वाक्य रचना चारों ओर एक बुरे विचार की तरह प्रतीत होगी।

— कुर्तियों को प्रकट करता है
स्रोत
6
कैसे के बारे में "बाजार के लिए समय", "लाभ के लिए लागत", आदि?
— जॉब
0

हाँ, वाक्यविन्यास मायने रखता है, हालांकि वास्तव में केवल पठनीयता के लिए। की तुलना करें:

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

(हाँ यह पायथन है) 

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

(हाँ, यह एक ऐसी भाषा है जिसे मैंने अभी-अभी बनाया है) दोनों बिल्कुल एक ही तरह से करेंगे, लेकिन वाक्य रचना अलग है, और पायथन पढ़ने में आसान है। तो हाँ, वाक्यविन्यास निश्चित रूप से मायने रखता है। यहां तक ​​कि "सिंथेटिक चीनी" मायने रखती है।

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

से पढ़ने में आसान है 

 def year(self):
     return self._date.year
 year = property(year)
— लेन्नर्ट रेग्रोब
स्रोत
0

हां, पक्का।

यदि आप एक बड़ी लौ शुरू करना चाहते हैं, तो लोगों से पूछें, जहां उन्होंने सी-लाइक भाषाओं में शुरुआती ब्रैकेट डाल दिया है। मेरा मतलब

void foo() {
  // blah
}

वी.एस.

void foo()
{
  // blah
}

या यहां तक ​​कि वी.एस.

void foo() 
{ // blah
}

और यह सिर्फ एक ही भाषा है! इसके अलावा, उनसे रिक्त स्थान के बारे में पूछें, जहां वे उन्हें रखते हैं (फ़ंक्शन नाम और ब्रैकेट, ऑपरेटर आदि)।

1000 जवाब की गारंटी है!

— ern0
स्रोत
मैं एक लौ शुरू नहीं करना चाहता और अब तक मुझे अच्छी प्रतिक्रियाएं मिली हैं और मैं उन सभी को भाग लेने और अपने ज्ञान को बढ़ाने के लिए धन्यवाद देता हूं और मुझे यकीन है कि अन्य लोगों को यह मददगार मिला
— सैफ अल हरथी
0

सिंटेक्स मायने रखता है। हालांकि इस दिन और उम्र में मैं कहूंगा कि यह लगभग पूरी तरह से पठनीयता के कारण मायने रखता है और वास्तव में कीस्ट्रोक्स की मात्रा के संदर्भ में नहीं है। क्यूं कर?

  • जब तक आप वास्तव में कुछ सरल नहीं लिख रहे हैं, यदि आपके द्वारा दबाए गए कुंजी की संख्या एक प्रोग्राम लिखने में सीमित कारक है तो आप या तो वास्तव में हैं, वास्तव में टाइपिंग में बकवास करते हैं या बहुत सोचते हैं, बहुत जल्दी।
  • इन दिनों सभी सभ्य IDE में बड़ी संख्या में शॉर्टकट हैं, जिनका अर्थ है कि आपको वास्तव में उन सभी वर्णों को टाइप करने की आवश्यकता नहीं है जिनका आप ज्यादातर समय उपयोग कर रहे हैं।

उस ने कहा, अगर यह बहुत अधिक क्रियात्मक है तो यह उस बिंदु तक पहुंच सकता है जहां यह पठनीयता को प्रभावित करता है। मैं कुछ देखना पसंद करूंगा:

foreach (स्ट्रिंग स्ट्रिंग में)

सेवा मेरे:

स्ट्रिंग स्ट्रिंग चर द्वारा संदर्भित सूची में प्रत्येक स्ट्रिंग के लिए

...किसी भी दिन!

— berry120
स्रोत
0

सिंटैक्स उन लोगों के लिए मायने रखता है जो इसे सीख रहे हैं, भाषा को शुरू करने के लिए अधिक लोकप्रिय प्रवेश करने की बाधा कम होगी। लेकिन अगर भाषा अपने आप को समृद्ध और संक्षिप्त रूप से व्यक्त करना मुश्किल या असंभव है, तो यह लोकप्रियता में वापस आना शुरू हो जाएगा।

बहुत ही कठिन और अपारदर्शी (पर्ल) केवल अत्यधिक क्रिया और कृमि (AppleScript) के रूप में बुरा है।

इसमें संतुलन, प्रवेश में कम अवरोध, उच्च उत्पादकता और आसान रखरखाव की आवश्यकता है।

— user7519
स्रोत
-2

विचार करने के लिए एक और बात यह है कि अच्छे सिंटैक्स के साथ प्रोग्रामिंग भाषाओं को पार्स करना आसान है, इस प्रकार संकलक को लिखना, तेज, और बग के लिए कम प्रवण बनाना आसान है।

— asmeurer
स्रोत
3
उम्म ... parse.yरूबी असहमत में 10000 SLOC । वहाँ एक कारण है कि है हर एक 7 वर्तमान या जल्द ही उत्पादन के लिए तैयार रूबी कार्यान्वयन के उपयोग करता है एक ही पार्सर, और हर एक रूबी कार्यान्वयन कि कभी भी अपने को विकसित करने की कोशिश की है खुद पार्सर विफल हो गया है।
— जोर्ग डब्ल्यू मित्तग
और तब वहां कुख्यात एडीए भाषा थी। भाषा युक्ति के साथ-साथ 100 कार्यक्रम थे जिन्हें संकलक को प्रमाणित करने के लिए सही ढंग से चलाना था। वाक्य रचना के बारे में कुछ सूक्ष्म बातें थीं। एक लंबी कहानी को छोटा बनाने के लिए, एडीए के शुरुआती कंपाइलर ने इन कार्यक्रमों में से एक जोड़े को तैयार किया। और यह बग को ठीक करने का एक साधारण मामला नहीं था, लेकिन उन्हें खरोंच से शुरू करने की आवश्यकता थी। भले ही इसे बड़े पैमाने पर सरकारी समर्थन मिला था (सभी डीओडी अनुबंधों ने एडीए को अनिवार्य कर दिया था), यह एक दुखी मौत बन गया।
— ओमेगा सेंटौरी
-2

इसे सीधे शब्दों में कहें: वाक्यविन्यास ऐसा नहीं है। शब्दार्थ आप इसके माध्यम से व्यक्त कर सकते हैं।

— back2dos
स्रोत
5
एक एक्सर्साइज़ के रूप में, सी में एक जटिल पार्सर लिखें, और फिर हास्केल में एक डिवाइस ड्राइवर। क्या सिंटेक्स ने आपकी मदद की? फिर दोनों कार्यक्रमों के शब्दार्थों को सख्ती से संरक्षित करते हुए दूसरे तरीके से करें। </ irony>
— 9000
1
@ 9000: मैंने हास्केल में डिवाइस ड्राइवरों के एक जोड़े को देखा है। मैं उनके साथ कुछ भी गलत नहीं देख सकता था। विस्तृत करने के लिए परवाह?
— जोर्ग डब्ल्यू मित्तग
2
@ 9000, यह देखते हुए कि C में डिवाइस ड्राइवर्स को प्राप्त करना कितना कठिन है, मुझे यकीन नहीं है कि आपने एक अच्छा उदाहरण चुना है।
1
@ 9000: यह बिल्कुल मेरी बात थी। एक सिंटैक्टिक निर्माण की ठोस प्रकृति कोई फर्क नहीं पड़ता, यह वही है जो आप इसके साथ व्यक्त करते हैं। हास्केल की सटीक वाक्य रचना के साथ एक प्रोग्रामिंग भाषा , लेकिन जो एक अलग मूल्यांकन रणनीति का उपयोग करता है वह बहुत से हास्केल को शानदार प्रदर्शन करेगा या यहां तक ​​कि अनंत छोरों में फंस जाएगा। जब सिंटैक्टिक कंस्ट्रक्शंस (या व्यापक: भाषा सुविधाओं) की बात आती है, तो यह उनका ठोस सिंटैक्स नहीं है जो मायने रखता है, लेकिन उनके शब्दार्थ, यानी आप उनके साथ क्या व्यक्त कर सकते हैं।
— back2dos
@ 9000, Haskell में C- जैसे सिंटैक्स (या ड्राइवर, Haskell- जैसे सिंटैक्स के साथ C का उपयोग करके) लिखने में कोई समस्या नहीं होगी।
— एसके-लॉजिक
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.