विभिन्न भाषाओं में "चाय का कप"

आप कौन सी प्रोग्रामिंग भाषा पसंद करते हैं? सी ++? या शुद्ध सी? या आप स्क्रिप्टिंग भाषाओं के प्रशंसक हैं - पायथन या पीएचपी?

बेशक, आप जवाब देंगे कि यह उन कार्यों पर निर्भर करता है जो आपको सामना करते हैं।

सब ठीक है। आइए एक सरल एल्गोरिदम को लागू करने की कोशिश करें - एक कप चाय बनाने के लिए - विभिन्न प्रोग्रामिंग भाषाओं में।

आप देख सकते हैं कि मेरे साथ क्या हुआ। कार्यान्वयन सही होने का दावा नहीं करते हैं, और परिणाम अलग हैं। लेकिन बात चाय में नहीं है - यह भाषा में है! इसलिए ...



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



आइए शुरू करते हैं, सी भाषा से परंपरा (या शायद परंपरा के बिना)। चिंता के साथ, क्रमिक रूप से और बिना किसी तामझाम के, हमें यह कोड मिला:

<br> #include <stdbool.h> <br><br> #define TEA_OK 0 <br><br> typedef enum _tea_type { <br> TEA_BLACK , <br> TEA_GREEN<br> } tea_type ; <br><br> typedef struct _tea_cup { <br> tea_type type , <br> bool sugar<br> } tea_cup ; <br><br> int drink_tea ( tea_cup * cup ) { <br> return TEA_OK ; <br> } <br>





क्षमा करें, मैं विवरण में नहीं गया, शीर्षकों को उजागर करता हूं। एच और सभी "चाय" मापदंडों के उपयोग का वर्णन करें ... लेकिन इसके साथ तुलना करने के लिए कुछ भी नहीं है।



अगला अप C ++ है। प्रशंसकों के लिए एक विशाल रचनात्मक स्थान, सभी प्रकार के लोशन और अमूर्त के साथ ड्राई कोड को "सजाने" के लिए। लेकिन मुख्य बात जिसे आपको नहीं भूलना चाहिए वह यह है कि उसने सीगल का एक पेय पकड़ा - इसे अपने लिए ले लो! (यह विध्वंसक और उनके आसपास की चर्चा का एक आसान संकेत था)

<br> #include <string> <br><br> class TeaCup { <br> public : <br> enum Type { <br> BLACK , <br> GREEN<br> } ; <br> TeaCup ( Type type ); <br> TeaCup ( std :: string sType ); <br> ~ TeaCup (); <br> protected : <br> Type type ; <br> } ; <br><br>TeaCup ::~ TeaCup () { <br> DishWasher :: wash ( this ); <br> } <br>





तेजी से आदर्श वस्तु कार्यान्वयन? क्या सब कुछ अपनी जगह है? वहाँ यह था! आइए जावा की ओर देखें, जहां एप्लिकेशन के आंतरिक स्थान को डिजाइन करने और कोड को व्यवस्थित करने का इंजीनियरिंग विचार बंद नहीं होता है और इसे बंद नहीं करना चाहिए! लक्ष्य स्पष्ट है - अन्य इंटरफेस में हमारे कोड का उपयोग करने के लिए।

<br>public interface Drinkable { <br> int drink (); <br> } <br><br>public class Boiled { <br> protected bool boiled ; <br> void setBoiled ( bool boiled ); <br> bool getBoiled (); <br> } <br><br>public class TeaCup extends Boiled implements Drinkable { <br> int drink () { <br> return 0 ; <br> } <br> } <br>





और हम अभी तक TeaCupFactory के साथ नहीं आए हैं और एक ऐसे व्यक्ति को नहीं लगाया है जो एक कप चाय के लिए इसे लागू करेगा! लेकिन चलो नहीं ... लाइन में अगला पायथन है। अर्थ सरल है: वस्तुओं के जादू के तरीकों को पुनर्परिभाषित करते हुए, हम एक बेहतर इंटरफ़ेस और उपयोगिता हासिल करते हैं। सरलता और संक्षिप्तता, अंडरस्कोर का एक दंगा।

<br> class TeaCup : <br><br> def __init__ ( self ): <br> self . want = [] <br><br> def __setattr__ ( self , name , value ): <br> if value : <br> self . want . append ( name ) <br><br> def __str__ ( self ): <br> return "Tea: %s" % ( ", " . join ( self . want )) <br><br> def drink ( self ): <br> return str ( self ) <br><br> if __name__ == "__main__" : <br> cup = TeaCup () <br> cup . sugar = True<br> cup . lemon = True<br> cup . drink () <br>





सबसे सुविधाजनक इंटरफ़ेस नहीं निकला? चिंता की कोई बात नहीं। एक और समय यह अधिक सटीक रूप से बदल जाएगा। या शायद पर्ल पर कोशिश करें? कॉम्पैक्ट कोड, भाषा की वाक्यात्मक समृद्धि, आह ...

<br>use Carp qw ( croak ); <br><br> sub drink_tea { <br> croak "Shit!" if wantarray ; <br> my $type = shift || "black" ; <br> my ( $sugar , $lemon ) = @_ ; <br> croak "What?" unless $type =~ /^ black | green$ / i ; <br> 1 ; <br> } <br>





मुझे आशा है कि आप समझ गए होंगे कि मेरा क्या मतलब है? जब तक न हो! हां, और शायद प्रदर्शन में हार नहीं होगी। यह पता लगाना कभी-कभी मुश्किल होता है ... मेरा उदाहरण यह है, मैं एक सच्चा-पर्ल प्रोग्रामर नहीं हूं। और कल्पना कीजिए कि आप जानबूझकर कुछ ढेर कर सकते हैं? नहीं कि दुखी PHP प्रोग्रामर जो एक ढेर प्रक्रियात्मक प्रोग्रामिंग और OOP में हस्तक्षेप करते हैं!

<br> set_include_path ( dirname ( __FILE__ ) . PATH_SEPARATOR . "lib" ); <br> require_once ( "tea.cup.php" ); <br>$cup = new Tea_Cup (); <br>$cup -> with_lemon = true ; <br>$cup -> fill (); <br> header ( "Content-Type: tea/black" ); <br> set_time_limit ( 0 ); <br>$cup -> drink (); <br>





बेशक, मैं प्रश्न चिह्नों के साथ त्रिकोणीय कोष्ठक भूल गया ... ठीक है, ठीक है। लेकिन जावास्क्रिप्ट में, ऐसा बिलकुल भी नहीं है। और कुछ नहीं। केवल वैश्विक वैरिएबल को स्थानीय बनाने के लिए मत भूलना (अच्छी तरह से, उन तक पहुंच को अनुकूलित करें) और अर्धविराम लगाएं ताकि हमारे कोड को बड़ी फ़ाइलों में एकीकृत किया जा सके।

<br> ;( function ( w ) { <br> var d = w . document , g = d . getElementById ; <br> var cup = g ( "tea-cup" ); <br> if (! cup ) return ; <br> if ( cup . className . indexOf ( "black" ) >= 0 ) <br> cup . appendChild ( d . createElement ( "sugar" )) ; <br> cup . style . visibility = "hidden" ; <br> } )( window ); <br>





इसलिए हम धीरे-धीरे समाप्त हो रहे हैं ... कम से कम कोड खत्म हो गया है। इसलिए, मैं आपके सवालों के जवाब देने की जल्दबाजी करता हूं, जो शायद पहले से ही परेशान हैं।



- यह सब क्यों? - आइए विभिन्न भाषाओं में प्रोग्रामिंग की शैली को देखें! कार्य की परवाह किए बिना, अक्सर भाषाओं के "चिप्स" का उपयोग करने पर, कार्यक्रम कोड के आयोजन के दृष्टिकोण पर। बेशक थोड़ा (या बहुत अधिक) अतिरंजित, लेकिन अभी भी। क्या इस तरह से अधिकांश PHP कोडर इस शैली में नहीं लिखते हैं? और Apache या Nginx स्रोतों को एक समान तरीके से व्यवस्थित नहीं किया गया है?



- कौन सी भाषा बेहतर है? - लेकिन मुझे यह नहीं पता ... मुझे कुछ और पसंद हैं, कुछ कम। लेकिन यह व्यक्तिपरक है। आखिरकार, मुख्य बात यह नहीं है कि आप क्या लिखते हैं, लेकिन आप इसे कैसे करते हैं। फिर, आखिरकार, काम एक आनंद हो सकता है, और सब कुछ बाहर हो जाएगा!



UPD: मैं कुछ हद तक "अजीब" C ++, जावा और पायथन के लिए माफी माँगता हूँ। कुछ ने मुझे इन भाषाओं में प्रकाशित करने में मूर्खतापूर्ण गलतियां कीं। टिप्पणीकारों को फिर से धन्यवाद!