ورود

View Full Version : مقاله (ترجمه): چگونگي دفاع از پايتون



eshpilen
شنبه 01 خرداد 1389, 01:16 صبح
چگونگي دفاع از پايتون

مولف: A.M. Kuchling

-= چكيده =-

معمولا دشوار است كه مديريت خود را راضي كنيد نرم افزار باز متن را بپذيرد، و پايتون استثنايي بر اين قاعده نيست. اين مقاله دربارهء دلايل استفاده از پايتون بحث ميكند، استراتژي هايي براي مقبوليت يافتن، واقعيت ها و استدلال هايي كه شما ميتوانيد استفاده كنيد، و مواردي كه شما نبايد تلاش كنيد از پايتون استفاده كنيد.

-= دلايل استفاده از پايتون =-

چندين دليل براي سهيم كردن يك زبان اسكريپتي در فرايند توسعهء شما وجود دارند، و اين بخش دربارهء آنها بحث خواهد كرد، و اينكه چرا پايتون بعضي ويژگيهايي دارد كه آنرا يك انتخاب مخصوصا مناسب ميسازند.

-= قابليت برنامه پذيري =-

برنامه ها اغلب در يك روش ماجول وار سازماندهي ميشوند. عمليات سطح پايينتر با هم گروه بندي شده اند، و توسط توابع سطح بالاتر فراخواني ميشوند، كه به نوبه خود توسط سطوح بالاتر بعنوان عمليات پايه استفاده ميشوند.
براي مثال، پايين ترين سطح ممكن است يك مجموعه خيلي سطح پايين از توابع براي دسترس به يك نگاشت (hash table) را تعريف كند. سطح بعدي ممكن است نگاشت ها را براي ذخيره هدرهاي يك پيام ايميل استفاده كند كه بطور مثال يك نام هدر (سرآيند - header) مثل تاريخ (Date) را به يك مقدار مانند Tue, 13 May 1997 20:00:54 -0400 نگاشت ميكند. يك سطح بالاتر ممكن است روي اشياء پيام كار كند، بدون دانستن يا اهميت دادن به اينكه هدرهاي پيام در يك جدول نگاشت ذخيره شده اند، و الي آخر به همين صورت.
اغلب، پايين ترين سطوح كارهاي خيلي ساده اي انجام ميدهند؛ آنها يك ساختار داده همچون يك درخت باينري يا يك جدول نگاشت را پياده سازي ميكنند، يا آنها يك محاسبهء ساده انجام ميدهند، مثل تبديل يك تاريخ بصورت متن به يك عدد. سطوح بالاتر سپس محتوي منطقي هستند كه اين عمليات پايه اي را به يكديگر متصل ميكند. با استفاده از اين روش، اجزاي پايه اي ميتوانند بعنوان قطعات سازنده اي كه سپس براي توليد يك محصول كامل بهم متصل ميشوند تصور شوند.
چرا اين روش طراحي به پايتون مربوط است؟ چون پايتون خوب مناسب عمل كردن بعنوان چنان زبان متصل كننده اي است. يك روش متداول نوشتن يك ماجول پايتون است كه عمليات سطح پايين را پياده سازي ميكند؛ بخاطر سرعت، پياده سازي ممكن است با سي، جاوا يا حتي فورترن باشد. به محض اينكه پايه اي ها در دسترس پايتون قرار گرفتند، منطق زيربنايي عمليات سطح بالاتر بصورت كد پايتون نوشته ميشود. منطق سطح بالا سپس قابل فهم تر و آسانتر براي تغيير دادن است.
John Ousterhout يك مقاله با عنوان «اسكريپت نويسي: برنامه نويسي سطح بالاتر براي قرن 21» نوشت كه اين ايده را با طول بيشتر شرح ميدهد. من توصيه ميكنم كه شما اين مقاله را بخوانيد؛ رفرنس ها را براي آدرس نگاه كنيد. Ousterhout مخترع زبان Tcl است و بنابراين استدلال ميكند كه Tcl بايد براي اين منظور استفاده شود؛ اون تنها مختصرا به زبانهاي ديگر همچون پايتون، پرل، و Lisp/Scheme اشاره ميكند، اما در واقع استدلال هاي Ousterhout در كل درمورد زبانهاي اسكريپتي مصداق دارد، چون شما ميتوانستيد بطور يكساني extension را براي هريك از زبانهاي مذكور بنويسيد.

-= نمونه اوليه =-

در مرد شب پره اي افسانه اي (م: كتابي درمورد مهندسي نرم افزار و مديريت پروژه)، Fredrick Brook قاعدهء زير را در هنگام طراحي پروژه هاي نرم افزاري پيشنهاد ميكند: «درنظر داشته باشيد تا يكي را دور بريزيد؛ شما بهرحال اينكار را خواهيد كرد». Brooks ميگويد كه اقدام نخست در طراحي يك نرم افزار اغلب اشتباه از آب درمي آيد؛ مگر اينكه مسئله خيلي ساده باشد يا شما يك طراح بينهايت خوب باشيد، شما درخواهيد يافت كه نيازها و ويژگيهاي جديد وقتيكه توسعه عملا شروع شد نمايان ميشوند. اگر اين نيازهاي جديد نتوانند بصورت تميزي در ساختار برنامه يكپارچه شوند، شما با دو انتخاب ناخوشايند رودرور هستيد: هر طور كه هست ويژگيهاي جديد را در برنامه زور چپان كنيد، يا همه چيز را اوراق كرده و يك نسخهء جديد از برنامه را با درنظر داشتن ويژگيهاي جديد از ابتدا، بنويسيد.
پايتون يك محيط خوب براي شما براي توسعهء سريع يك نمونه اوليه نخستين فراهم ميكند. كه به شما اجازه ميدهد ساختار و منطق كلي برنامه را درست كنيد، و شما ميتوانيد جزييات كوچك را در چرخهء توسعهء سريعي كه پايتون فراهم ميكند بخوبي تنظيم كنيد. وقتيكه شما از رابط گرافيكي يا خروجي برنامه راضي شديد، ميتوانيد كد پايتون را به سي++، فورترن، جاوا، يا زبان كامپايل شوندهء ديگري ترجمه كنيد.
تهيه نمونه اوليه به معناي آنست كه شما بايد محتاط باشيد تا از ويژگيهاي زيادي از زبان پايتون كه پياده سازي آنها در زبانهاي ديگر دشوار است بيش از حد استفاده نكنيد. استفاده از تابع eval، يا عبارت منظم (regular expressions)، يا ماجول pickle، به معناي آنست كه بطور مثال شما به كتابخانه هاي سي يا جاوا براي ارزيابي فرمول، عبارات منظم، و serialization نياز خواهيد داشت. اما اجتناب از چنان كد گمراه كننده اي دشوار نيست، و در پايان ترجمه معمولا خيلي دشوار نيست. كد حاصل شده ميتواند با سرعت عيب يابي شود، زيرا هر خطاي جدي منطقي از نمونهء اوليه زدوده شده خواهد بود، كه تنها خطاهاي كوچك را در ترجمه باقي ميگذارد.
اين استراتژي بر بحث قبلتر دربارهء برنامه پذيري استوار است. استفاده از پايتون بعنوان يك متصل كننده براي اتصال اجزاي سطح پايينتر ارتباط واضحي براي ساخت سيستم هاي نمونه اوليه دارد. به اين روش پايتون ميتواند در توسعه به شما كمك كند، حتي اگر كاربران نهايي هرگز به هيچ صورتي در تماس با كد پايتون نباشند. اگر كارايي (performance) نسخهء پايتون كافي باشد و سياست هاي شركتي آنرا اجازه دهند، شما ممكن است نيازي به انجام يك ترجمه به سي يا جاوا نداشته باشيد، اما توسعهء يك نمونه اوليه و سپس ترجمه كردن آن ميتواند هنوز سريعتر باشد، بجاي تلاش كردن براي توليد فوري نسخهء نهايي.
يك مثال از اين استراتژي توسعه Microsoft Merchant Server است. نسخهء 1.0 در پايتون خالص نوشته شده بود، بوسيلهء يك شركت كه متعاقبا توسط ميكروسافت خريداري شد. نسخهء 2 شروع به ترجمهء كد به سي++ كرد و همراه با مقداري كد سي++ و مقداري كد پايتون ارائه شد. نسخهء 3.0 هيچ كد پايتوني نداشت؛ و كد به سي++ ترجمه شده بود. گرچه محصول حتي محتوي يك مفسر پايتون نيست، اما زبان پايتون هنوز بوسيلهء بالا بردن سرعت توسعه در خدمت يك هدف مفيد بوده است.
اين يك استفادهء خيلي متداول از پايتون است. مقالات كنفرانس گذشته همچنين اين روش را براي توسعهء الگوريتم هاي سطح بالاي عددي شرح داده اند؛ مقالهء avid M. Beazley و Peter S. Lomdahl با عنوان «خوراندن يك كاربرد فيزيكي مقياس وسيع به پايتون» را در رفرنسها براي يك مثال خوب ببينيد. اگر عمليات هاي پايهء يك الگوريتم چيزهايي مثل «معكوس اين ماتريس 4000 در 4000 را بگير» باشند و در يك زبان سطح پايينتري پياده سازي شده باشند، آنوقت پايتون تقريبا هزينهء اضافه اي ندارد؛ زمان اضافي مورد نياز پايتون براي ارزيابي يك عبارت مثل m.invert() تحت الشعاع هزينهء عمليات واقعي قرار ميگيرد. آن بويژه براي كاربردهايي كه تغييرات جزيي ظاهرا بي پايان براي درست كردن چيزها مورد نياز است خوب است. رابطهاي گرافيكي كاربر و سايت هاي وب نمونه هاي نخست هستند.
كد پايتون همچنين كوتاهتر و سريعتر براي نوشتن است (وقتيكه شما با پايتون آشنا شديد)، بنابراين دور انداختن آن درصورتيكه شما تصميم گرفتيد كه روش شما اشتباه بوده است آسانتر است؛ اگر شما بجاي تنها دو ساعت دو هفته روي آن كار كرده بوديد، ممكن بود زمان را در تلاش براي وصله و پينه كردن آن از روي يك بي ميلي طبيعي براي پذيرفتن آنكه آن دو هفته هدر رفته بودند، هدر دهيد. حقيقتا آن دو هفته هدر نرفته بودند، چون شما چيزي دربارهء مسئله و فناوري اي كه شما براي حل آن استفاده ميكنيد آموخته ايد، اما طبيعت بشر است كه اين را بعنوان يك نوع شكست ببيند.

-= سادگي و آساني فهم =-

پايتون قطعا يك زبان اسباب بازي نيست از آنرو كه آن براي كارهاي كوچك قابل استفاده است. ويژگيهاي زبان بقدر كافي عام و قدرتمند هستند تا آنرا قادر كنند تا براي خيلي مقاصد مختلف استفاده شود. آن در كارهاي كوچك مفيد است، براي اسكريپتهاي 10 يا 20 خطي، اما همچنين تا سيستم هاي بزرگتري كه هزاران خط كد را شامل ميشوند تطبيق مي يابد.
اما اين گويايي به هزينهء يك دستور زبان مبهم يا گمراه كننده نيست. درحاليكه پايتون بعضي جوانب تاريكي دارد كه ميتوانند به كد مبهم منجر شوند، چنان جوانبي نسبتا معدود هستند، و طراحي مناسب ميتواند استفادهء آنها را به تنها به معدودي از كلاسها يا ماجول ها ايزوله كند. قطعا نوشتن كد گيج كننده بوسيلهء استفاده از تعداد بيش از حد ويژگيها با توجه و روشني كم ممكن است، اما بيشتر كد پايتون ميتواند خيلي شبيه يك نسخهء اندكي رسمي شده از شبه كد (pseudocode) قابل فهم براي بشر بنظر برسد.

در فرهنگ لغت جديد هكر، Eric S. Raymond تعريف زير را براي «فشرده» ارائه ميكند:
صفت فشرده از يك طراحي، دارايي ارزشمندي را توصيف ميكند كه ميتواند يكباره در مغز كسي دريافت شود. اين عموما به معناي آنست كه چيزي كه از طرح ايجاد شده است ميتواند با سهولت بيشتر و خطاهاي كمتري نسبت به يك ابزار معادل كه فشرده نيست استفاده شود. فشرده بودن مفهوم جزيي بودن يا كمبود قدرت را نميرساند؛ براي مثال، سي فشرده است و فورترن نيست، اما سي از فورترن قدرتمندتر است. طراحي ها بوسيلهء افزوده شدن تدريجي ويژگيها و قطعاتي كه بصورت تميزي در طراحي كلي ادغام نميشوند غير فشرده ميشوند (از اينرو، بعضي طرفداران سي كلاسيك معتقد هستند كه ANSI C ديگر فشرده نيست).
منبع: compact (http://www.catb.org/~esr/jargon/html/C/compact.html)

در اين معناي كلمه، پايتون كاملا فشرده است، زير زبان تنها ايده هاي معدودي دارد، كه در جاهاي خيلي زيادي استفاده شده اند. براي مثال namespace ها را فرض كنيد. يك ماجول را با import math وارد (Import) كنيد، و شما يك namespace بنام math ايجاد ميكنيد. كلاسها همچنين فضاهاي نامي (namespace) اي هستند كه خيلي از ويژگيهاي ماجول ها را به اشتراك دارند، و معدودي هم مال خودشان؛ براي مثال، شما نمونه هايي (instances) از يك كلاس ايجاد ميكنيد. نمونه ها؟ آنها فضاهاي نامي ديگري هستند. فضاهاي نامي درحال حاضر بصورت جدول هاي نگاشت پايتون (dictionaries) پياده سازي شده اند، بنابراين آنها متدهاي يكساني با نوع دادهء ديكشنري دارند: keys() همهء كليدها را برميگرداند، و غيره.
اين سادگي از تاريخچهء توسعهء پايتون برمي آيد. دستور زبان از منابع متفاوتي مشتق ميشود؛ ABC، يك زبان نسبتا مبهم آموزشي، يك منبع تاثيرپذيري اوليه است، و Modula-3 ديگري است (براي اطلاع بيشتر درمورد ABC و Modula-3 به سايتهاي آنها در A Short Introduction to the ABC Language (http://www.cwi.nl/~steven/abc) و http://www.m3.org مراجعه كنيد). بقيهء ويژگيها از سي، Icon، Algol-68 و حتي پرل آمده اند. پايتون واقعا چيز زيادي اختراع نكرده است، اما درعوض تلاش كرده است تا زبان را كوچك و آسان براي يادگيري نگه دارد، با بنا كردن بر روي ايده هايي كه در زبانهاي ديگر آزموده شده و مفيد يافته شده اند.
سادگي يك خصيصه است كه نبايد دست كم گرفته شود. آن به شما اجازه ميدهد زبان را سريعتر ياد بگيريد، و سپس سريع كد بنويسيد - كدي كه اغلب براي اولين باري كه شما آنرا اجرا ميكنيد كار ميكند.

-= يكپارچگي با جاوا =-

اگر شما با جاوا كار ميكنيد، Jython قطعا ارزش توجه شما را دارد. Jython يك پياده سازي مجدد پايتون در جاوا است كه كد پايتون را به بايت كد جاوا كامپايل ميكند. محيط حاصل شده يكپارچگي نفوذ ناپذير تقريبا بدون درزي با جاوا دارد. دسترسي به كلاسهاي جاوا از پايتون كاري بسيار كوچك است، و شما ميتوانيد كلاسهاي پايتوني بنويسيد كه كلاسهاي جاوا را مشتق ميكنند. Jython ميتواند براي نمونه سازي اوليهء اپليكيشن هاي جاوا خيلي يكسان با روشي كه CPython استفاده ميشود استفاده شود، و همچنين ميتواند براي مجموعه تست ها براي كد جاوا استفاده شود، يا در داخل يك اپليكيشن جاوا براي اضافه كردن قابليت هاي اسكريپت نويسي تعبيه شود.

-= ادعاهاي مخالف و تكذيب ها =-

بگذاريد بگوييم شما تصميم گرفته ايد پايتون را بعنوان بهترين انتخاب براي اپليكيشن خودتان استفاده كنيد. چطور شما ميتوانيد مديريت خود يا توسعه دهندگان همكار را به استفاده از پايتون قانع كنيد؟ اين بخش استدلال هاي مخالف متداول درمقابل استفاده از پايتون را ليست ميكنيد، و تكذيب هاي ممكني را فراهم ميكند.

-- پايتون نرم افزار مجاني اي است كه هيچ چيزي نمي ارزد. آن ميتواند چقدر خوب باشد؟
درواقع خيلي خوب. اين روزها لينوكس و آپاچي دو قطعه از نرم افزار باز متن هستند كه بعنوان جايگزيني براي نرم افزار تجاري درحال پذيرش بيشتري هستند، اما پايتون آنقدر عموميت نداشته است.
پايتون سالهاست وجود داشته است، با تعداد زيادي كاربر و توسعه دهنده. متناسبا، مفسر بوسيلهء تعداد زيادي از افراد استفاده شده است، و بيشتر باگها از آن تكانده شده اند. درحاليكه باگها هنوز در فواصلي كشف ميشوند، آنها معمولا كاملا مبهم هستند (آنها بايد ميبودند چراكه هيچكس قبلا با آنها مواجه نشده بود) يا آنها با رابطهايي به كتابخانه هاي خارجي درگير هستند. اجزاي داخلي زبان خودشان كاملا پايدار هستند.
داشتن كد منبع بايد بعنوان فراهم كردن نرم افزار براي بازنگري همرديفان تلقي شود؛ افراد ميتوانند كد را امتحان كنند، بهبودهايي را پيشنهاد (و پياده سازي) كنند، و باگها را رديابي كنند. براي فهميدن بيشتر درمورد ايدهء كد متن باز، همراه استدلال ها و موارد تحقيق پشتيباني كنندهء آن به Home | Open Source Initiative (http://www.opensource.org) مراجعه كنيد.

-- چه كسي ميخواهد آنرا پشتيباني كند؟
پايتون يك اجتماع قابل ملاحظه از توسعه دهندگان دارد، و تعداد هنوز درحال رشد است. اجتماع اينترنتي احاطه كنندهء زبان يكي از فعال هاست، و ميتواند بعنوان يكي ديگر از مزاياي پايتون تلقي شود. بيشتر پرسشهاي پست شده به گروه خبري comp.lang.python بسرعت بوسيلهء كسي پاسخ داده ميشوند.
اگر شما بايد در عمق كد منبع فرو برويد، آنرا روشن و خوب سازماندهي شده خواهيد يافت، پس نوشتن توسعه ها (extensions) و رديابي باگها خيلي دشوار نيست. اگر شما ترجيح ميدهيد براي پشتيباني پول بپردازيد، شركتها و اشخاصي وجود دارند كه پشتيباني تجاري براي پايتون ارائه ميكنند.

-- چه كسي پايتون را براي كار جدي اي استفاده ميكند؟
خيلي از افراد؛ يك چيز جالب درمورد پايتون تنوع غافلگيركنندهء اپليكيشن هايي است كه براي آنها استفاده شده است. مردم پايتون را براي اجراي وب سايت ها، نوشتن رابطهاي گرافيكي كاربر، كنترل كدهاي پردازش اعداد روي ابررايانه ها، اضافه كردن قابليت اسكريپت نويسي به يك اپليكيشن تجاري با تعبيه كردن مفسر پايتون در آن، پردازش مجموعه داده هاي بزرگ XML، ساخت مجموعه تست ها براي سي يا جاوا استفاده ميكنند.
حيطهء اپليكيشن شما هرچيزي كه هست، احتمالا كسي وجود دارد كه پايتون را براي چيز مشابهي استفاده كرده است. اما عليرغم قابل استفاده بودن براي چنان اپليكيشن هاي سطح بالايي، پايتون هنوز بقدر كافي ساده هست تا براي كارهاي كوچك استفاده شود.
آدرس OrganizationsUsingPython - PythonInfo Wiki (http://wiki.python.org/moin/OrganizationsUsingPython) را براي يك ليست از سازمانهايي كه از پايتون استفاده ميكنند ببينيد.

-- محدوديت ها بر روي استفاده از پايتون چه هستند؟
آنها عملا وجود ندارند. به فايل Misc/COPYRIGHT در توزيع كد منبع مراجعه كنيد يا بخش History and License رفرنس براي كل زبان، اما آن به سه شرط خلاصه ميشود:
- شما بايد اعلان كپي رايت را بر روي نرم افزار باقي بگذاريد (م: بنظرم درمورد خود پايتون)؛ اگر شما كد منبع را در يك محصول شامل نميكنيد، بايد اعلان كپي رايت را در مستندات پشتيباني كننده قرار دهيد.
- ادعا نكنيد كه موسسه هايي كه پايتون را توسعه داده اند محصول شما را به هيچ شكلي توصيه ميكنند.
- اگر چيزي درست از آب درنيايد، شما نميتوانيد براي خسارت پيگرد قانوني كنيد. بطور خاص تمام مجوزهاي نرم افزاري محتوي اين شرط هستند.
توجه كنيد كه شما مجبور نيستيد كد منبع را براي هرچيزي كه شامل پايتون است يا با آن ساخته شده است فراهم كنيد. همچنين مفسر پايتون و مستندات همراه ميتوانند به هر شكلي كه شما دوست داريد تغيير پيدا كرده و توزيع شوند، و شما به هيچ وجه مجبور نيستيد هيچ هزينهء مجوزي را به هيچكس پرداخت كنيد.

-- چرا ما بايد يك زبان گمنام همچون پايتون را بجاي زبان ايكس مشهور استفاده كنيم؟
من اميدوارم اين راهنما، و مستندات ليست شده در بخش نهايي، كمك خواهند كرد كه شما قانع شويد كه پايتون گمنام نيست، و يك پايهء كاربري سلامت درحال رشد دارد. يك كلمه نصيحت: هميشه مزاياي مثبت پايتون را ارائه كنيد بجاي اينكه روي ناتوانايي هاي زبان ايكس متمركز شويد. مردم ميخواهند بدانند چرا يك راه حل خوب است، بجاي اينكه چرا همهء راه حل هاي ديگر بد هستند. بنابراين بجاي حمله به يك راه حل رقيب بر زمينه هاي مختلف، بسادگي نشان دهيد چطور خصيصه هاي پايتون ميتوانند كمك كنند.

-= منابع مفيد =-

Pythonology Python Success Stories (http://www.pythonology.com/success)
داستان هاي موفقيت يك مجموعه از روايت ها از كاربران موفق پايتون هستند كه روي كاربران تجاري و شركتي تاكيد دارند.

Scripting (http://home.pacbell.net/ouster/scripting.html)
مقالهء رسمي John Ousterhout درمورد اسكريپت نويسي يك استدلال خوب براي قابليت استفاده از زبانهاي اسكريپتي است، هرچند بقدر كافي بطور طبيعي، او روي Tcl، زباني كه او توسعه داد، تاكيد ميكند. بيشتر استدلال ها به هر زبان اسكريپتي اي قابل اعمال هستند.

Feeding a Large-scale Physics Application to Python (http://www.python.org/workshops/1997-10/proceedings/beazley.html)
مولفان، David M. Beazley و Peter S. Lomdahl، استفادهء خود از پايتون در آزمايشگاه ملي Los Alamos را شرح ميدهند. آن يك مثال خوب ديگر از اينكه چطور پايتون ميتواند كار واقعي را انجام دهد است. اين نقل قول از مقاله بوسيلهء بسياري ديگر از مردم تكرار شده است:

ابتدا طراحي شده بعنوان يك اپليكيشن يكپارچه براي سيستم هاي پردازش موازي انبوه، ما پايتون را براي تبديل اپليكيشن مان به يك سيستم منعطف، خيلي ماجولار، و درنهايت قدرتمند براي انجام شبيه سازي، تحليل داده ها، و بصري سازي استفاده كرديم. بعلاوه، ما توضيح ميدهيم چطور پايتون تعدادي از مسائل مهم مربوط به توسعه ، رفع عيب، برقراري، و نگهداري نرم افزار علمي را حل كرد.

Cognizor.com - cogn iz or Resources and Information.This website is for sale! (http://pythonjournal.cognizor.com/pyj1/Everitt-Feit_interview98-V1.html)
اين مصاحبه با Andy Feit، كه دربارهء استفادهء Infoseek از پايتون بحث ميكند، ميتواند براي نشان دادن آنكه انتخاب پايتون هيچ دشواري اي را به فرايند توسعهء يك شركت اضافه نميكند و فوايد قابل توجهي را فراهم ميكند، استفاده شود.

http://www.python.org/workshops/1997-10/proceedings/stein.ps
مديريت ميتواند دربارهء قابليت اعتماد و سودمندي نرم افزاري كه بصورت تجاري نوشته نشده است در ترديد باشد. اين سايت استدلال هايي را ارائه ميكند كه نشان ميدهند چطور نرم افزار بازمتن ميتواند مزايايي قابل توجهي نسبت به نرم افزار غيربازمتن داشته باشد.

Linux Advocacy mini-HOWTO (http://www.faqs.org/docs/Linux-mini/Advocacy.html)
مقالهء چگونگي دفاع از لينوكس الهام بخش اين مقاله بود، و همچنين براي موفقيت پيشنهاد پذيرش يك فناوري جديد همچون لينوكس يا پايتون بخوبي ارزش خواندن را دارد. دركل، شما با حمله كردن بر سيستم هاي موجود و شكايت كردن درمورد ناكارايي هاي آنها پيشرفت چنداني نخواهيد كرد؛ اين اغلب همچون موفقيت متمركز نشده بنظر خواهد رسيد. بسيار بهتر است كه چند حيطه از حيطه هاي بسياري را كه پايتون در آنها يك بهبود نسبت به سيستم هاي ديگر است نشان دهيد.

================================

منبع: مقالهء Python Advocacy HOWTO از بخش Python HOWTOs در رفرنس رسمي پايتون نسخهء سري 3

eshpilen
شنبه 01 خرداد 1389, 01:17 صبح
راستی درمورد اینکه مولف گفته ابتدا با پایتون یک Prototype درست میکنیم و بعد به زبانهای دیگر ترجمه میکنیم!
حقیقتش من اول فکر کردم که منظورش ترجمه با ابزارهایی هست که بعضی دوستان بهشون اشاره کردن و میگن کد پایتون رو بصورت خودکار به زبانهای دیگه ترجمه میکنن. بعد فکر کردم پس این روش از اونی که من فکر میکردم راحتتر و سریعتر هست و در تمام موارد برای هر برنامه و کاربردی بدون نقص کار میکنه و تمام مراحل رو بصورت خودکار درمیاره.
اما بعد به ذهنم رسید که لزوما مقصود مولف ترجمهء خودکار با این ابزارها نبوده! بلکه احتمالا منظورش از ترجمه این بوده که منطق کدی رو که با پایتون نوشتیم و نتایج آزمایش های الگوریتم، ساختمان داده ها، عملکرد، اینترفیس و غیره رو که در پایتون انجام دادیم نهایتا خودمون در زبان هدف نهایی پیاده سازی میکنیم.
این تصور منطقی بنظر میاد چون به Prototype بودن اشاره شده که این اصطلاح معمولا به مواردی گفته میشه که محصول، یک نمونهء کامل و بهینه از مدل اصلی و برای تولید انبوه و استفادهء همگانی روزمره نیست، بلکه یک مدل آزمایشی و محدود هست. اگر قرار بود صرفا براحتی کدهای پایتون رو به یک ابزار مترجم بدیم و همه چیز تموم باشه، پس لزومی نداشت با پایتون Prototype بنویسیم، بلکه میتونستیم تمام برنامه رو تا آخرین مرحله و شکل نهایی اون در پایتون نوشته و سپس بطور خودکار به زبان هدف ترجمه کنیم.
همینطور مثلا به این اشاره کرده که طوری برنامه بنویسیم که ترجمش ساده تر باشه و به این خاطر باید سعی کنیم از بعضی امکانات که خیلی مختص به پایتون (و اصولا زبانهای اسکریپتی) هستن (مثل تابع eval) استفاده نکنیم. پس احتمالا منظور ترجمهء خودکار نبوده و اگر منظورش ابزارهای ترجمهء خودکار بود باید این ابزارها اونقدری کامل میبودن که بتونن این اجزای درونی زبان رو که چندان هم نامتداول نیستن تبدیل کنن، وگرنه یک مقالهء رسمی به این راحتی نمیتونست کل زبان پایتون رو بطور اساسی با این ابزارها وابسته بدونه و ضمنا حداقل میباید به این برنامه ها و نقصهای اونها اشاره میکرد، که نکرده.
پس به احتمال زیاد منظورش از ترجمه، ترجمهء الگوریتم و بقیهء اجزای اساسی برنامه توسط برنامه نویس به زبان هدف بوده.

خب شاید این سوال پیش بیاد که آیا اینکار به صرفه هست؟ یعنی نوشتن نمونهء آزمایشی با پایتون و بعد نمونهء اصلی یا نهایی به زبان هدف دیگر که بقدر پایتون خوانا و راحت و کوتاه نیست اما در مصرف منابع سیستم و سرعت خیلی بهینه تر هست.
بنظر من منطقی که طرف مطرح کرده چندان عجیب هم نیست. اگر درنظر بگیریم که در نوشتن الگوریتم و بقیهء اجزای اساسی برنامه ها چقدر زمان و انرژی در سر و کله زدن با ریزه کاری ها و پیچیدگی ها و کدهای اضافه نوشتن بخاطر محدودیت های فنی زبان و ناخواناتر بودن کد و رفع باگهایی که بر اثر این مسائل پیش میان تلف میشه، و اینکار چقدر تکرار میشه و چقدر فکر برنامه نویس رو از تمرکز روی حل مسئلهء اصلی منحرف میکنه، و پایتون تاحد زیادی این مسائل رو کاهش داده، احتمالا منطق کاملا شیوایی هست.
ضمنا انتزاع و دید سطح بالایی که پایتون ایجاد میکنه میتونه برای برنامه های بزرگ یا الگوریتمهای پیچیده بسیار مفید باشه.
یعنی ایجاد برنامه های بزرگ و پیچیده و الگوریتمهای خیلی تخصصی و علمی، درحالیکه برنامه نویسان در انبوهی از کدهای اضافه و نامربوط به خود مسئله و منطق کلی اون شناور هستن، اکثرا کار بسیار دشوارتری هست و امکان دید سطح بالاتر و کلی تر به مسئله رو براحتی مخدوش میکنه.
منتها برای استفادهء بهینه از این روشی که مولف مطرح کرده، مسلمه که ما باید حداقل به دو زبان و احتمالا فریمورک های مورد نیاز کاملا مسلط باشیم.

از طرفی بنظر من اینطور نیست و منظور مولف هم این نبوده که تمام یا حتی بیشتر برنامه ها باید نهایتا به زبان دیگری ترجمه بشن. ولی اینکار در خیلی موارد ممکنه در میان مدت و دراز مدت راه بسیار بهینه تر یا ضروری ای باشه. بخصوص که وقتی ما الگوریتم و اجزای اصلی درگیر رو در پایتون داشته باشیم دیگه ترجمه به زبان هدف باید کار خیلی راحتتر و سریعتری باشه. یعنی شما اکثرا صرفا کدهای پایتون رو به کدهای بیشتری در زبان دیگر نگاشت میکنید.
فرض کنید اگر ما بخوایم یک سیستم عامل داشته باشیم که تمام یا بیشتر برنامه هاش با پایتون هستن، بنظر من قدرت و منابع سیستمهای امروزی هم براحتی دچار کمبود خواهند شد و کارایی مجموع بحد قابل توجهی یا حتی بحد غیرقابل استفاده پایین خواهد آمد.
درمورد تنها چند برنامهء اپلیکیشن عمومی و یوتیلیتی روی یک سیستم این مسئله بروز نمیکنه و نیازی به ترجمه نیست (البته بعضی وقتها نوع برنامه و بار سرویسی که میده میتونه باعث نیاز به ترجمه بشه).

ضمنا یک مورد دیگر هم اشاره به برنامه هایی بوده که نیاز به تغییرات مداوم جزیی دارن. مثل کاربردهای وب و رابط گرافیکی کاربر که اینهم باز جای تفکر و تحلیل بیشتری داره.
ولی تجربهء خود من اینکه که مثلا بخصوص در GUI ما موقع توسعه و تغییرات زیادی که لازم داریم و تست میکنیم زمان زیادی رو در بخش کامپایلهای مجدد برنامه از دست میدیم. یک زبان اسکریپتی در این وادی خیلی به صرفه تر عمل میکنه. البته درسته که محیطهای طراحی ویژوال این مشکل رو تاحدی (البته هرگز نه کاملا! چون اینها هرکاری رو انجام نمیدن و خیلی وقتها نیاز داریم بخاطر بخشهای دیگر برنامه که با رابط ارتباط دارن کامپایل مجدد کنیم) حل کردن ولی بازهم یک زبان اسکریپتی محدودهء کاربرد و نقاط قوت خودش رو در این وادی داره.
درمورد وب هم دقیقا نمیدونم به چی اشاره داره. خب البته ما در وب هم بیشتر زبانهای اسکریپتی رو موفق میبینیم (با وجود کارایی کمتر از زبانهای کامپایل شونده) و اینهم دلایل نسبتا روشنی داره. البته بخصوص اگر نرم افزار سایت کاملا سفارشی و موردی باشه (یعنی مثلا یک CMS آماده نباشه) تغییرات هم نسبتا زیاد و با فواصل کوتاه هستن. در این وادی زبانهای اسکریپتی راحتترین و سریعترین برای برنامه نویسی و تست و اعمال تغییرات هستن؛ پایتون فکر کنم حتی از PHP هم در این زمینه راحتتر باشه. البته احتمالا خیلی هم اختلاف نداشته باشن. اما اگر برنامهء وب ما یک چیز علمی تر و پیچیده تر و با یک الگوریتم درست و حسابی ای باشه احتمالا مزایای پایتون بیشتر برجسته میشن.

بهرحال اگر شما هم نظر و ایده و تجربه ای در این زمینه ها دارید دریغ نکنید.

و موفق باشید.