[navidjoon]

سلام
این مقاله رو که قبلا اجازه اش رو از mkargar عزیز گرفتم و ایشون هم لطف کردن ورخصت دادن بالاخره ترجمه کردم. البته هنوز نقص داره که ایشالا کامل شده اش تا 3 شنبه تحویل میشه. بی زحمت moderator های عزیز اگه اشکالی نداشت به بخش مقالات منتقل کنن. این مقاله رو تقدیم میکنم به همه کسایی که دست من رو گرفتن و سوالات بی جوابم رو پاسخ دادن. باید یگم که بی اغراق در طول سه ماه کارم با لینوکس به اندازه همه 10 سالی که با کامپیوتر و ویندوز تماس داشتم چیز یاد گرفتم. ممنون از همه. ایشالا من هم بتونم به بقیه یاد بدم.

قربون محبت همه بامعرفتها

نویدجون

چرا پیتون ؟

کاردینال بیگلز ، اریک ِ بی ایمان را بیش از چهار ساعت روی صندلی راحتی نشاند تا سرانجام این اعترافات را از او گرفت ...
اولین نگاه من به پیتون یک تصادف بود ، و علاقه چندانی به چیزی که در آن زمان دیدم پیدا نکردم.اوایل سال 1997 بود و کتاب " برنامه نویسی پیتون " نوشته مارک لوتز از انتشارات O'reilly به تازگی بیرون آمده بود.کتابهای O'reilly به ندرت به در خانه من میرسند ، که در آن مورد هم توسط یک فرد ذینفع درون سازمان طی یک فرآیند تصادفی که من تصمیم گرفته ام دیگر سعی در فهمیدن آن نکنم از بین تازه های چاپ برای من فرستاده میشوند .
یکی از این کتابها " برنامه نویسی پیتون " بود. از آنجا که من زبانهای رایانه جمع آوری می کنم این موضوع برایم جالب بود. من بیش از دوجین زبان همه منظوره بلدم ، برای تفریح مفسر و مترجم های زیادی نوشته ام و شخصا تعدادی زبانهای یک منظوره و فرمهای نشانه گذاری (Markup) مختلف طراحی کرده ام. تازه ترین پروژه ای که من در زمان نوشتن این مقاله به پایان رسانده ام ، یک زبان یک منظوره به نام SNG برای کار کردن روی تصاویر PNG ( Portable Network Graphics ) است. خوانندگان علاقمند میتوانند صفحات خانگی SNG را در آدرس <!-- m --><a class="postlink" href="http://www.catb.org/~esr/sng/">http://www.catb.org/~esr/sng/</a><!-- m --> مشاهده کنند. من همچنین چند نسخه پیاده سازی شده از چند زبان همه منظوره عجیب را در صفحه Retrocomputing Museum خود به آدرس <!-- m --><a class="postlink" href="http://www.catb.org/retro/">http://www.catb.org/retro/</a><!-- m --> قرار داده ام.
من قبلا آنقدر درباره پیتون شنیده بودم که بدانم از آن چیزهایی است که امروزه به آنها زبانهای اسکریپت میگویند، یک زبان تفسیری با مدیریت داخلی ( built-in ) حافظه و تسهیلاتی خوب برای فراخوانی و همکاری با دیگر برنامه ها. بنابراین در هنگام شروع پیتون یک سوال بالاتر از همه مسائل برای من مطرح بود : این زبان چه چیزی دارد که پرل ندارد ؟
البته ، پرل گوریل 800 کیلویی زبانهای اسکریپت امروزی است. این زبان تا حدی به لطف کتابخانه های یونیکس و اعلانهای جامع خود و تا حدی به دلیل مجموعه بزرگ ماژولهای به وجود آمده توسط جامعه برنامه نویسان پرل ، به نسبت زیادی جایگزین زبانهای اسکریپت انتخابی مدیران وناظران سیستمها شده است. این زبان ، زبان CGI پنهان در پشت حدود 85% محتوای " زنده " بر روی شبکه به شمار میرود. سازنده آن ، Larry Wall ، به درستی یکی از مهمترین رهبران جامعه متن باز به شمار میرود و اغلب پس از Linus Torvalds و Richard Stallaman در مکان سوم جایگاه خدایان قرار میگیرد.
در آن زمان من پرل را برای تعدادی از پروژه های کوچک استفاده کرده بودم. من این زبان را بسیار قدرتمند یافتم گرچه به نظر من میرسید سینتکس و بعضی جنبه های دیگر این زبان میتوانند تا حدی برای شخصی که به آن عادت نداشته باشد خطرناک باشند. به نظر من می رسید که پیتون به عنوان یک زبان اسکریپت باید گام مهم دیگری بردارد ، بنابراین درحال خواندن به دنبال چیزی می گشتم که به نظر برسد آن را از زبان پرل مجزا می کند.
من به سرعت مطالب غیرعادی اصلی ای که ممکن است در پیتون به نظر هر کسی برسد را مرور کردم : این واقعیت که فضای خالی ( indentation ) در سینتکس این زبان بامعنی است ؛ این زبان هیچ سنخیتی با ساختار آکولادی C و پرل ندارد، در عوض تغییرات در توگذاری ( indentation ) محدودیت گروههای عبارات را از بین میبرند؛ و مثل اکثر هکرها پس از فهمیدن این مطلب با بی علاقگی عقب کشیدم.
آنقدر از عمر من گذشته است که برای چند ماهی در دهه 70 با FORTRAN برنامه نویسی کرده باشم. اکثر هکرهای این دوره چنین نیستند ولی به نظر می رسد فرهنگ ما به گونه ای ، خاطره ای دقیق وسنتی از اینکه آن زبانهای قدیمی با محدوده ثابت چقدر عذاب آور بودند حفظ کرده باشد. "فرمت آزاد " ، که درآن زمان برای توصیف حالت جدیدتر سینتکس token-oriented زبانهای C و پاسکال استفاده می شد تقریبا فراموش شده است؛ چندین دهه است تمامی زبانها اینگونه طراحی شده اند ، یا تقریبا تمام زبانها. بسیار سخت است کسی را ، پس از دیدن این ویژگی پیتون ، به خاطر عکس العمل اولیه ای مانند اینکه به صورت غیرمنتظره در انبوهی از بی ادبی! دایناسور قدم گذاشته است سرزنش کرد.
این احساس من در آن زمان بود. من بدون علاقه چندانی از کنار بقیه توضیحات این زبان گذاشتم. من دلیل چندان دیگری برای توصیه پیتون پیدا نکردم به جز اینکه احتمالا سینتکس آن تا حدی شسته و رفته تر از پرل بود و امکانات موجود برای اجرای CGI های ابتدایی مانند دکمه ها ومنوها بسیار خوب به نظر میرسید.
من کتاب را با این یادآوری ذهنی که باید زمانی یک پروژه کوچک با محوریت GUI انجام دهم ، تا مطمئن شوم که واقعا این زبان را میفهمم ، در قفسه گذاشتم. ولی باور نداشتم چیزی که دیده ام هرگز بتواند به طور موثر با پرل رقابت کند.
اتفاقات زیادی باعث شدند این یادآوری ذهنی ماهها در فهرست اولویتهای من در مکان آخر قرار بگیرد. بقیه سال 1997 برای من پر از اتفاقات بود ، در کنار بقیه اتفاقات ، این سالی بود که من نسخه اصلی "کلیسای اعظم و بازار" را نوشته و منتشر کردم. در عین حال من فرصت یافتم تا چندین برنامه پرل بنویسم ، از جمله دو برنامه با حجم و پیچیدگی قابل توجه. یکی از آنها ، keeper ، برنامه دستیاری است که همچنان برای بایگانی پرونده های ارسالی وارده در شرکت نرم افزاری Metalab به کار میرود. این برنامه تولیدکننده صفحات وبی است که شما در <!-- m --><a class="postlink" href="http://metalab.unc.edu/pub/Linux/!INDEX.html">http://metalab.unc.edu/pub/Linux/!INDEX.html</a><!-- m --> مشاهده می کنید. برنامه دیگر ، anthologize ، با هدف تولید خودکار PostScript برای ششمین ویرایش لینوکس از آرشیو " چگونه ها" ی پروژه مستندسازی لینوکس استفاده شد. هر دوی این برنامه ها در Metalab موجود هستند.
نوشتن هر دوی این پروژه ها مرا بیشتر و بیشتر از پرل ناراضی کرد. به نظر میرسید پروژه های با اندازه بزرگتر یک نارضایتی ساده از پرل را تبدیل به مشکلات جدی و مداوم مینمایند. سینتکسی که در صد خط ابتدایی بسیار راضی کننده به نظر میرسید با گذشت زمان تبدیل به توده ای از خارهای غیرقابل نفوذ میشد. " بیش از یک راه برای انجام کار " که حال و هوا و تاثیرگذاری خاصی به آن می بخشید ، نگهداری یک استیل خاص در یک محدوده کد وسیعتر را به مقدار قابل توجهی مشکل می ساخت. وبسیاری قابلیتهایی که بعدا به منظور جوابگویی به نیاز برای کنترل پیچیدگی در برنامه های بزرگتر ( اشیا ، lexical scoping ، use strict و ... ) به پرل اضافه شده بودند حالتی شکننده و نه چندان دلچسب داشتند.
تمامی این مشکلات دست به دست یکدیگر داده بودند تا خواندن و درک حجم زیادی از کدهای پرل به عنوان یک کلیت را تنها پس از چند روز به صورت غیرمنطقی ای مشکل کنند. علاوه بر این ، من دریافتم که روز به روز زمان بیشتری را به جای ور رفتن با برنامه خود ، صرف ور رفتن با قابلیتهای این زبان میکنم. و بدتر از همه اینکه کد من زشت شده بود ، ... این مسالهء واقعی بود. برنامه های زشت مثل پلهایِ معلقِ زشت هستند، واژگون شدن آنها بسیار محتمل تر از انواع زیبای آنها است ، زیرا نحوه ادراک انسانها ( به خصوص مهندس- انسانها ) از زیبایی رابطه بسیار نزدیکی با قابلیت ما برای پردازش و فهم پیچیدگی دارد. زبانی که کار نوشتن کد باوقار و شکوه را سخت کند در حقیقت نوشتن کد خوب را مشکل کرده است.
با وجود یک دو جین زبان که به آنها تسلط داشتم ، من میتوانستم به تمامی علامات مشهود یک طراحی زبان که به منتهای قابلیت حود رسیده است و چیز بیشتری برای عرضه ندارد پی ببرم. من فکر کردم "باید راه بهتری وجود داشته باشد" و شروع به گشتن به دنبال یک زبان اسکریپت باشکوه تر کردم.
موردی که من حتی به آن فکر نکردم بازگشت به C به عنوان یک زبان پیش فرض بود. دوره ای که انجام مدیریت حافظه در یک برنامه به صورت شخصی معنا داشت ، به جز در بعضی زمینه ها مانند طراحی هسته سیستم عامل ( kernel hacking ) ، برنامه نویسی علمی و گرافیک 3 بعدی که در آنها شما نیاز دارید بیشترین سرعت و کنترل کامل بر روی استفاده از حافظه به منظور حداکثر استفاده از سخت افزار را داشته باشید ،مدتهاست که گذشته است.
در اکثر موارد دیگر پذیرفتن بار اضافه debug کردن [ چندین اصطلاح را در این قسمت حذف کردم م.] و دیگر مشکلات از این دست در ماشینهای امروزی دیوانگی است. بسیار عاقلانه تر است که چندین چرخه و چندین کیلوبایت حافظه برای نیازهای مدیر حافظه یک زبان اسکریپت فدا کنیم و در وقت گرانبهای انسان صرفه جویی کنیم. در حقیقت استفاده از این راهبرد ( استراتژی ) دقیقا همان چیزی است که باعث رشد انفجاری پرل از اوایل دهه 90 شده است.
مدتی با Tcl ور رفتم تا متوجه شدم که در مقیاسهای بالا حتی از پرل هم ضعیفتر عمل میکند. به عنوان یک برنامه نویس قدیمی LISP ، همچنین نگاهی به اشکال ( dialects ) مختلف رایج LISP و Scheme انداختم ولی همانگونه که از نظر تاریخی در مورد LISP معمول است ، طراحیهای هوشمندانه متعدد آن به دلیل عدم وجود یا ناقص بودن مستندات ، دسترسی ناقص به امکانات POSIX/UNIX و یک جامعه کوچک و در عین حال بسیار پراکنده کاربران ، بی استفاده شده بودند. پرطرفدار بودن پرل به هیچ عنوان یک تصادف نیست ؛ اکثر رقبای آن یا برای پروژه های بزرگ بدتر از پرل هستند یا اصلا و ابدا به آن مفیدی که ساختار نظری برتر آنها انتظارش را ایجاد میکند نیستند.
نگاه دومی من به پیتون تقریبا همانقدر تصادفی بود که نگاه اول. در اکتبر 1997 ، یک سری سوالات در فهرست نامه های الکترونیک افراد استفاده کننده از fetchmail این موضوع را کاملا مشخص کرد که افراد برای ایجاد فایلهای تنظیمات ِ برنامه fetchmail دچار مشکلات فزاینده ای میشوند. این فایل دارای ساختاری ساده و کلاس به سبک فرمت آزادِ یونیکس است ولی میتواند هنگامی که کاربر دارای چندین حساب از نوع POP3 و IMAP باشد به شدت پیچیده شود. به عنوان نمونه ، برای دیدن یک مثال ساده شده از برنامه من به لیست 1 نگاه کنید.
من تصمیم گرفتم برای حل مشکل از یک ویرایشگر تنظیمات با حالتی دوستانه برای کاربر نهایی ( End-User-Friendly ) به نام fetchmailconf استفاده کنم. هدف از طراحی fetchmail مشخص بود ؛ پنهان کردن کامل سینتکس فایل کنترل در پشت ظاهر شیک و صحیح از نظر ارگونومی یک رابط گرافیکی کاربر ( GUI ) با کلیدهای انتخاب ، منوهای کشویی و فرمهای مختلف.
فکر پیاده کردن این برنامه با پرل چندان مرا ذوق زده نکرد. من کدهای GUI را در پرل دیده بودم که ترکیبی ناهمگون بود از پرل و Tcl که حتی از کد پرل خود برنامه هم زشت تر بود. در این لحظه بود که قولی را که 6 ماه قبل داده بودم یادم آمد. این میتوانست فرصتی برای کسب یک تجربه عملی با پیتون باشد.
البته این موضوع مجددا من را با بامعنی بودن فضای خالی در پیتون روبرو کرد. البته این بار تخته گاز پیش رفتم و مقداری کد برای انبوهی از عناصر GUI نوشتم. جدا ّ حیرت آور بود که تنها پس از 20 دقیق ، استفاده پیتون از فضای سفید دیگر امر عجیبی به نظر نمی آمد. من همانقدر از فرورفتگی متن در پیتون استفاده میکردم که امکان داشت در C از آن استفاده کنم و این روش جواب هم میداد.
این اولین حیرت من بود. حیرت دومی ، حدود 2 ساعت بعد ( با احتساب زمانهای توقفی که برای نگاه کردن به قابلیتهای پیتون در کتاب Learning Python صرف شد ) ، وقتی پیش آمد که متوجه شدم با همان سرعتی مشغول نوشتن برنامه های به دردبخور هستم که میتوانم تایپ کنم. وقتی متوجه این موضوع شدم تقریبا مبهوت شدم. یکی از معیارهای مهم عملکرد در برنامه نویسی تعداد دفعاتی است که شما چیزی می نویسید که واقعا با درک شما از مساله همخوانی ندارد و ناچارید پس از فهمیدن این موضوع که چیزی که تایپ کرده اید به زبان آنچه را شما فکر می کنید نمی گوید به عقب برگردید. یکی از معیارهای مهم طراحی مناسب زبان اینست که درصد چنین اشتباهاتی با تجربه پیدا کردن شخص در آن زبان با چه سرعتی کاهش می یابند.
هنگامی که شما با بیشترین سرعتی که قادرید تایپ کنید برنامه به دردبخور می نویسید و اشتباهات شما در انتخاب مسیر تقریبا صفر است ، این به آن معناست که شما در آن زبان به استادی رسیده اید. ولی این بی معنی بود ، چون به زحمت یک روز از این موضوع گذشته بود و من هنوز مجبور بودم امکانات مربوط به زبان و کتابخانه ها را از روی کتاب نگاه کنم.
این اولین چیزی بود که به من فهماند من در پیتون با یک طراحی عالی سروکار دارم. اکثر زبانها آنقدر دارای تداخل و ضعف در طراحی خود هستند که شما قبل از اینکه ضریب اشتباهاتتان در آنها حتی نزدیک به صفر شود بسیاری از امکانات آنها را فرا گرفته اید. پیتون تنها زبان همه منظوره ای بود که من تا آن روز استفاده کرده بودم و این فرآیند را معکوس می کرد.
البته یادگیری مجموعه امکانات آن نیز چندان وقت گیر نبود. من یک برنامه fetchmailconf کارآ و قابل استفاده ، به همراه GUI ، را در 6 روز کاری نوشتم که از این 6 روز احتمالا 2 روز آن تماما صرف یادگیری خود پیتون شد. این موضوع نشان دهنده یک خاصیت مفید دیگر این زبان است : این زبان حالت اختصاری دارد ، شما میتوانید تمامی مجموعه امکانات آن ( حداقل یک ایده فهرست وار از کتابخانه های آن ) را در ذهن نگه دارید. C زبانی است که به اختصار معروف است. پرل در این زمینه شهرت خوبی ندارد. یکی از چیزهایی که عبارت معروف " بیش از یک راه برای انجام آن وجود دارد! " قربانی می کند توانایی مختصر بودن پرل است.
ولی هنوز رویایی ترین کشف من باقی مانده بود. طراحی من یک مشکل داشت : من قادر بودم به راحتی فایلهای تنظیم را با استفاده از عملهای GUI ِ کاربر تولید کنم ولی ویرایش آنها مشکل بزرگتری بود. یا بهتر است بگویم خواندن آنها به یک شکل قابل ویرایش کار مشکلی بود.
Parser به کار رفته برای سینتکس فایل تنظیماتfetchmail بسیار کاربر بود. این برنامه در حقیقت با استفاده از YACC و Lex ، دو ابزار کلاسیک یونیکس برای تولید کد parsing زبان در C ، نوشته شده بود. تصور من این بود که برای اینکه قادر به ویرایش فایلهای تنظیمات در fetchmail باشم ناچار به تکرار همان parser ِ وقت گیر در پیتون خواهم بود. من برای انجام این کار بسیار دودل بودم ، تا حدودی به دلیل حجم کار و تا حدودی هم به دلیل اینکه نمیدانستم از کجا باید مطمئن باشم که دو parser در دو زبان مختلف مثل یکدیگر عمل خواهند کرد. کار فوق العاده زیاد همخوان نگاه داشتن دو parse آخرین چیزی بود که ممکن بود من با تحول زبانها به آن نیاز داشته باشم.
این مشکل برای مدتی مرا متوقف کرد. بعد از این فکری به ذهنم رسید : من به fetchmailconf اجازه می دادم از parser خود استفاده کند. من یک گزینه –configdump به fetchmail اضافه کردم و نتیجه را در یک خروجی استاندارد با فرمت یک initializer پیتون تخلیه کردم. برای فایل بالایی ، نتیجه تقریبا شبیه به لیست 2 بود ( برای صرفه جویی در فضا بعضی داده های غیرمرتبط با مثال حذف شده اند ).
پیتون سپس قادربود خروجی fetchmail--configdump را ارزیابی کند و سپس تنظیمات را به صورت مقدار متغیر " fetchmail " ارائه کند.
حتی این هم آخرین حرکت رقص من نبود. چیزی که من میخواستم صرفا این نبود که fetchmail تنظیمات فعلی خود را داشته باشد بلکه میخواستم آن را تبدیل به یک ساختار درختی از اشیا زنده (live objects) کنم. احتمالا در این درخت سه نوع شی وجود داشت : تنظیمات ( که شیء واقع در بالاترین مرتبه و نشان دهنده کل تنظیمات بود) ؛ سایت ( نشان دهنده یکی از سایتهایی که باید به رای گذاشته می‌شد.) و کاربر ( نشان دهنده داده‌های کاربران که به سایت متصل می‌شود). فایلهای مثال پنج شیء از نوع سایت که به هر کدام یک شیء از نوع کاربر متصل شده است را نشان می‌دهد.
تا اینجا من سه شیء کلاس را طراحی کرده و نوشته بودم ( این همان چیزی بود که چهار روز از وقت من را گرفت که اکثر آن هم صرف چیدن درست و مناسب کنترلهای صفحه شد ). هر یک از این کلاسها یک متد داشت که باعث می شد برای ویرایش داده های آن instance خاص یک صفحه GUI باز شود. تنها مشکل باقیمانده من یافتن روشی برای تبدیل اشیاء مرده این برنامه initializer پیتون به اشیاء زنده بود.
چیزی که به نظر من رسید نوشتن کدی بود که به وضوح راجع به ساختار هر سه کلاس بداند و از این دانش برای پلکیدن در initializer و ایجاد اشیایی که پاسخگوی نیازها باشند استفاده کند ولی این ایده را رد کردم زیرا اعضای این کلاس جدید احتمالا با اضافه شدن امکانات جدید به تنظیمات زیاد می شدند. اگر من کد ایجاد اشیا را با این روش مشهود می نوشتم ، احتمال زیادی وجود داشت که کد حالت شکننده پیدا کند و با تغییر تعریفهای کلاس یا ساختار initializer از حالت به روز خارج شود.
چیزی که من واقعا به دنبالش بودم کدی بود که شکل و اعضای initializer را تجزیه و تحلیل کند ، از تعریفهای کلاس برای پرس و جو درباره اعضای آن کلاس استفاده کند و سپس خودش را با این دو مجموعه هماهنگ کند.
به این گونه چیزها در اصطلاح هک کردن metaclass گفته می شود و در حالت عمومی چیزی به ترسناکی جادوی سیاه به شمار میروند. اکثر زبانهای برنامه نویسی شیءگرا مطلقا از این قابلیت پشتیبانی نمی کنند و در آنهایی که این کار را می کنند (که پرل هم یکی از آنهاست) ، این موضوع امری پیچیده و ظریف و شکننده است. تا همان زمان من از ضریب بسیار پایین اشکال سازی پیتون متعجب شده بودم ولی این یک آزمایش واقعی بود. برای اینکه این زبان را مجبور به انجام چنین کاری کنم چقدر باید با آن کشتی می گرفتم ؟ با استفاده از تجربیات قبلی می دانستم که ، حتی با این فرض که من ببرم ، این می تواند تجربه دردناکی باشد ولی روی کتاب شیرجه رفتم و شروع به مطالعه امکانات metaclass پیتون کردم. تابع به دست آمده در فهرست 3 نشان داده شده است و کدی که فراخوانی می کند در فهرست 4 آمده است.
برای جادوی سیاه چندان بد به نظر نمی رسد ، اینطور نیست ؟ سی و دو خط با احتساب توضیحات. فقط با توجه به چیزهایی که من درباره ساختار کلاسها گفتم ، حتی کد فراخوان نیز قابل خواندن است. ولی اندازه این کد موضوع شوکه کننده نیست. خودتان را کنترل کنید : نوشتن این کد تنها 90 دقیقه وقت گرفت و در اولین باری که من آن را اجرا کردم به خوبی کار کرد.
تنها گفتن این که من حیرت زده شده بودم می تواند کم لطفی باشد. درست و به خوبی کار کردن پیاده سازی حتی ساده ترین تکنیکها در اولین بار همانگونه که انتظار می رفته میتواند امری قابل توجه باشد ؛ ولی اولین هک کردن metaclass من تنها پس از 6 روز از یک شروع بی مقدمه ؟ حتی اگر به اغراق بگوییم که من یک هکر با استعداد هستم این یک موفقیت بزرگ برای پیتون در زمینه شفافیت و شکوه و عظمت طراحی است.
تقریبا هیچ راهی وجود نداشت که من بتوانم با وجود تجربه بسیار زیادترم در پرل عمل مشابهی را با استفاده از آن انجام دهم. در این زمان بود که احساس کردم که احتمالا پرل را ترک خواهم کرد.
این رویایی ترین لحظه من در پیتون بود. ولی حالا که همه اینها تمام شده باید بگویم تمام اینها یک هک هوشمندانه بود. مفید بودن یک زبان برنامه نویسی در بلند مدت بستگی به پشتیبانی آنها از هک های هوشمندانه ندارد بلکه به چند و چون پشتیبانی آن از امور روزمره برنامه نویسی مرتبط است. کار روزمره برنامه نویسی اکثرا به جای نوشتن برنامه های جدید ، از خواندن و تغییر دادن برنامه های موجود تشکیل می شود.
مساله تکان دهنده اینجاست : هفته ها و ماهها پس از نوشتن fetchmailconf ، من هنوز قادر بودم کد آن را بخوانم و بدون هیچ تلاش فکری جدی ای متوجه بشوم که چکار میکند. و دلیل واقعی این موضوع که من دیگر برای هیچ چیزی جز پروژه های کوچک از پرل استفاده نمی کنم این است که این موضوع هرگز در مورد پرل صادق نبود. من حتی از تصور این موضوع که زمانی ناچار شوم keepr یا anthologize را تغییر دهم به وحشت می افتم در حالیکه برای انجام چنین کاری در مورد fetchmailconf ککم هم نمیگزد.
پرل همچنان کاربردهای خود را دارد. برای پروژه های کوچک (100 خط یا کمتر) که شامل مقدار زیادی جور کردن الگوی متن است ، من احتمالا بیشتر از یک راه حل با استفاده از پرل استقبال میکنم تا پیتون. برای دیدن چندین مثال خوب ، برنامه های timeseries و growplot را در فهرست توزیع fetchmail مشاهده کنید. در حقیقت ، اینها تا حد زیادی شبیه کاری هستند که پرل در نقش اصلی خود ، قبل از اینکه دارای توابع و دسترسی مستقیم به API ِ سیستم عامل باشد ، به عنوان نوعی ترکیب awk/sed/grep/sh انجام می داد. برای هر چیز بزرگتر یا پیچیده تر ، من عادت کرده ام که ارزشهای لطیف پیتون را ترجیح بدهم و فکر کنم شما نیز همین کار را انجام بدهید.

[blix]

دست میزاد.
لطفا لینک مقاله اصلی رو هم به انتهای ترجمه اضافه کنید.
ممنون

[bl2k]

عالی بود...مرسی

[irix]

دستتون درد نکنه!

[shazde_pesar]

خیلی جالب و گویا بود

[مهمان]

سلام به همه
الان سرعت اینترنت اینجا خیلی پایینه و نمی تونم وارد بشم ولی تا عصر آدرس اصل مقاله رو میفرستم. احتمالا روی fa.wikipedia هم قرارش میدم. از همه ممنون.

نویدجون

[navidjoon]

سلام
لینک اصلی مقاله اینه <!-- m --><a class="postlink" href="http://www.linuxjournal.com/article.php?sid=3882">http://www.linuxjournal.com/article.php?sid=3882</a><!-- m --> ولی به دلیل تغییراتی در سایت فعلا در دسترس نیست. اگه دیدم درست نمیشه اصلش رو هم میذارم همینجا.ممنون.
موفق باشین

[mkargar]

آفرين که زحمتش را کشيدي...

[newbie]

سلام به شما
من همین الآن این تاپیک رو دیدم(10 روز به اینترنت کانکت نشده بودم!!!!!)
شیوایی ترجمه شما تحسین برانگیزه.من python رو حدود 1.5 سال پیش با
مقاله های افسانه ای
How to become a hacker و why python از اریک ریموند شروع کردم
و واقعا از اون لذت میبرم....
البته یه نکته کوچیک هم قابل ذکر هست و اون اینکه Script های کوچیک و
مخصوصا Net admin رو با perl سریعترمیشه نوشت...من کاملا shell scripting
رو با perl عوض کردم! در واقع به نظر من(که یه newbie هستم)قدرت اصلی perl
در اختصاراونه و قدرت اصلی python در انسجام-سادگی و طراحی ذاتی اون در
پروژه های بزرگ هست
باز هم از ترجمه شیوای شما ممنون..

[navidjoon]

سلام
newbie جون خواهش میکنم قابلی نداشت. اگه یادت باشه خودت بودی که لینک این دو تا مقاله رو بهم دادی. میتونم بگم که باعث شروع کردن پیتون من شدی. خیلی ممنونم. ایشالا ترجمه های بعدی. راستی نظرتون راجع به ایجاد بخش ترجمه چیه ؟

[blix]

فکر می‌کردم بتونم تو صفحه شخصی اریک ریموندز اصل مقاله رو پیدا کنم اما نتونستم. ظاهرا فقط تو linuxjournal.com هستش.

[blix]

... و ترجمه فارسی How to Become a Hacker. لینک از Techopedia.

[Faridb]

هه! منم hacker howto رو ترجمه کردم . مال من به نظر خودم حداقل یه نمه از این یکه روون تر و نزدیک تر به سبک نگارش ESR هست! تا چند روز دیگه قسمت اولش رو می ذارم رو سایت.

[navidjoon]

سلام
این هم اصل مقاله. ممنون از لطف همه دوستانی که comment گذاشتن.
[ltr]
Cardinal Biggles had Eric, the infidel, in the comfy chair for over four hours before wringing this confession from him...


My first look at Python was an accident, and I didn't much like what I saw at the time. It was early 1997, and Mark Lutz's book Programming Python from O'Reilly & Associates had recently come out. O'Reilly books occasionally land on my doorstep, selected from among the new releases by some mysterious benefactor inside the organization using a random process I've given up trying to understand.

One of them was Programming Python. I found this somewhat interesting, as I collect computer languages. I know over two dozen general-purpose languages, write compilers and interpreters for fun, and have designed any number of special-purpose languages and markup formalisms myself. My most recently completed project, as I write this, is a special-purpose language called SNG for manipulating PNG (Portable Network Graphics) images. Interested readers can surf to the SNG home page at <!-- m --><a class="postlink" href="http://www.catb.org/~esr/sng/">http://www.catb.org/~esr/sng/</a><!-- m -->. I have also written implementations of several odd general-purpose languages on my Retrocomputing Museum page, <!-- m --><a class="postlink" href="http://www.catb.org/retro/">http://www.catb.org/retro/</a><!-- m -->.

I had already heard just enough about Python to know that it is what is nowadays called a ``scripting language'', an interpretive language with its own built-in memory management and good facilities for calling and cooperating with other programs. So I dived into Programming Python with one question uppermost in my mind: what has this got that Perl does not?

Perl, of course, is the 800-pound gorilla of modern scripting languages. It has largely replaced shell as the scripting language of choice for system administrators, thanks partly to its comprehensive set of UNIX library and system calls, and partly to the huge collection of Perl modules built by a very active Perl community. The language is commonly estimated to be the CGI language behind about 85% of the ``live'' content on the Net. Larry Wall, its creator, is rightly considered one of the most important leaders in the Open Source community, and often ranks third behind Linus Torvalds and Richard Stallman in the current pantheon of hacker demigods.

At that time, I had used Perl for a number of small projects. I'd found it quite powerful, even if the syntax and some other aspects of the language seemed rather ad hoc and prone to bite one if not used with care. It seemed to me that Python would have quite a hill to climb as yet another scripting language, so as I read, I looked first for what seemed to set it apart from Perl.

I immediately tripped over the first odd feature of Python that everyone notices: the fact that whitespace (indentation) is actually significant in the language syntax. The language has no analog of the C and Perl brace syntax; instead, changes in indentation delimit statement groups. And, like most hackers on first realizing this fact, I recoiled in reflexive disgust.

I am just barely old enough to have programmed in batch FORTRAN for a few months back in the 1970s. Most hackers aren't these days, but somehow our culture seems to have retained a pretty accurate folk memory of how nasty those old-style fixed-field languages were. Indeed, the term ``free format'', used back then to describe the newer style of token-oriented syntax in Pascal and C, has almost been forgotten; all languages have been designed that way for decades now. Or almost all, anyway. It's hard to blame anyone, on seeing this Python feature, for initially reacting as though they had unexpectedly stepped in a steaming pile of dinosaur dung.

That's certainly how I felt. I skimmed through the rest of the language description without much interest. I didn't see much else to recommend Python, except maybe that the syntax seemed rather cleaner than Perl's and the facilities for doing basic GUI elements like buttons and menus looked fairly good.

I put the book back on the shelf, making a mental note that I should code some kind of small GUI-centered project in Python sometime, just to make sure I really understood the language. But I didn't believe what I'd seen would ever compete effectively with Perl.

A lot of other things conspired to keep that note way down on my priority list for many months. The rest of 1997 was eventful for me; it was, among other things, the year I wrote and published the original version of ``The Cathedral and the Bazaar''. But I did find time to write several Perl programs, including two of significant size and complexity. One of them, keeper, is the assistant still used to file incoming submissions at the Metalab software archive. It generates the web pages you see at <!-- m --><a class="postlink" href="http://metalab.unc.edu/pub/Linux/!INDEX.html">http://metalab.unc.edu/pub/Linux/!INDEX.html</a><!-- m -->. The other, anthologize, was used to automatically generate the PostScript for the sixth edition of Linux from the Linux Documentation Project's archive of HOWTOs. Both programs are available at Metalab.

Writing these programs left me progressively less satisfied with Perl. Larger project size seemed to magnify some of Perl's annoyances into serious, continuing problems. The syntax that had seemed merely eccentric at a hundred lines began to seem like a nigh-impenetrable hedge of thorns at a thousand. ``More than one way to do it'' lent flavor and expressiveness at a small scale, but made it significantly harder to maintain consistent style across a wider code base. And many of the features that were later patched into Perl to address the complexity-control needs of bigger programs (objects, lexical scoping, ``use strict'', etc.) had a fragile, jerry-rigged feel about them.

These problems combined to make large volumes of Perl code seem unreasonably difficult to read and grasp as a whole after only a few days' absence. Also, I found I was spending more and more time wrestling with artifacts of the language rather than my application problems. And, most damning of all, the resulting code was ugly--this matters. Ugly programs are like ugly suspension bridges: they're much more liable to collapse than pretty ones, because the way humans (especially engineer-humans) perceive beauty is intimately related to our ability to process and understand complexity. A language that makes it hard to write elegant code makes it hard to write good code.

With a baseline of two dozen languages under my belt, I could detect all the telltale signs of a language design that had been pushed to the edge of its functional envelope. By mid-1997, I was thinking ``there has to be a better way'' and began casting about for a more elegant scripting language.

One course I did not consider was going back to C as a default language. The days when it made sense to do your own memory management in a new program are long over, outside of a few specialty areas like kernel hacking, scientific computing and 3-D graphics--places where you absolutely must get maximum speed and tight control of memory usage, because you need to push the hardware as hard as possible.

For most other situations, accepting the debugging overhead of buffer overruns, pointer-aliasing problems, malloc/free memory leaks and all the other associated ills is just crazy on today's machines. Far better to trade a few cycles and a few kilobytes of memory for the overhead of a scripting language's memory manager and economize on far more valuable human time. Indeed, the advantages of this strategy are precisely what has driven the explosive growth of Perl since the mid-1990s.

I flirted with Tcl, only to discover quickly that it scales up even more poorly than Perl. Old LISPer that I am, I also looked at various current dialects of Lisp and Scheme--but, as is historically usual for Lisp, lots of clever design was rendered almost useless by scanty or nonexistent documentation, incomplete access to POSIX/UNIX facilities, and a small but nevertheless deeply fragmented user community. Perl's popularity is not an accident; most of its competitors are either worse than Perl for large projects or somehow nowhere near as useful as their theoretically superior designs ought to make them.

My second look at Python was almost as accidental as my first. In October 1997, a series of questions on the fetchmail-friends mailing list made it clear that end users were having increasing trouble generating configuration files for my fetchmail utility. The file uses a simple, classically UNIX free-format syntax, but can become forbiddingly complicated when a user has POP3 and IMAP accounts at multiple sites. As an example, see Listing 1 for a somewhat simplified version of mine.

Listing 1

I decided to attack the problem by writing an end-user-friendly configuration editor, fetchmailconf. The design objective of fetchmailconf was clear: to completely hide the control file syntax behind a fashionable, ergonomically correct GUI interface replete with selection buttons, slider bars and fill-out forms.

The thought of implementing this in Perl did not thrill me. I had seen GUI code in Perl, and it was a spiky mixture of Perl and Tcl that looked even uglier than my own pure-Perl code. It was at this point I remembered the bit I had set more than six months earlier. This could be an opportunity to get some hands-on experience with Python.

Of course, this brought me face to face once again with Python's pons asinorum, the significance of whitespace. This time, however, I charged ahead and roughed out some code for a handful of sample GUI elements. Oddly enough, Python's use of whitespace stopped feeling unnatural after about twenty minutes. I just indented code, pretty much as I would have done in a C program anyway, and it worked.

That was my first surprise. My second came a couple of hours into the project, when I noticed (allowing for pauses needed to look up new features in Programming Python) I was generating working code nearly as fast as I could type. When I realized this, I was quite startled. An important measure of effort in coding is the frequency with which you write something that doesn't actually match your mental representation of the problem, and have to backtrack on realizing that what you just typed won't actually tell the language to do what you're thinking. An important measure of good language design is how rapidly the percentage of missteps of this kind falls as you gain experience with the language.

When you're writing working code nearly as fast as you can type and your misstep rate is near zero, it generally means you've achieved mastery of the language. But that didn't make sense, because it was still day one and I was regularly pausing to look up new language and library features!

This was my first clue that, in Python, I was actually dealing with an exceptionally good design. Most languages have so much friction and awkwardness built into their design that you learn most of their feature set long before your misstep rate drops anywhere near zero. Python was the first general-purpose language I'd ever used that reversed this process.

Not that it took me very long to learn the feature set. I wrote a working, usable fetchmailconf, with GUI, in six working days, of which perhaps the equivalent of two days were spent learning Python itself. This reflects another useful property of the language: it is compact--you can hold its entire feature set (and at least a concept index of its libraries) in your head. C is a famously compact language. Perl is notoriously not; one of the things the notion ``There's more than one way to do it!'' costs Perl is the possibility of compactness.

But my most dramatic moment of discovery lay ahead. My design had a problem: I could easily generate configuration files from the user's GUI actions, but editing them was a much harder problem. Or, rather, reading them into an editable form was a problem.

The parser for fetchmail's configuration file syntax is rather elaborate. It's actually written in YACC and Lex, two classic UNIX tools for generating language-parsing code in C. In order for fetchmailconf to be able to edit existing configuration files, I thought it would have to replicate that elaborate parser in Python. I was very reluctant to do this, partly because of the amount of work involved and partly because I wasn't sure how to ascertain that two parsers in two different languages accept the same. The last thing I needed was the extra labor of keeping the two parsers in synchronization as the configuration language evolved!

This problem stumped me for a while. Then I had an inspiration: I'd let fetchmailconf use fetchmail's own parser! I added a --configdump option to fetchmail that would parse .fetchmailrc and dump the result to standard output in the format of a Python initializer. For the file above, the result would look roughly like Listing 2 (to save space, some data not relevant to the example is omitted).

Listing 2

Python could then evaluate the fetchmail --configdump output and have the configuration available as the value of the variable ``fetchmail''.

This wasn't quite the last step in the dance. What I really wanted wasn't just for fetchmailconf to have the existing configuration, but to turn it into a linked tree of live objects. There would be three kinds of objects in this tree: Configuration (the top-level object representing the entire configuration), Site (representing one of the sites to be polled) and User (representing user data attached to a site). The example file describes five site objects, each with one user object attached to it.

I had already designed and written the three object classes (that's what took four days, most of it spent getting the layout of the widgets just right). Each had a method that caused it to pop up a GUI edit panel to modify its instance data. My last remaining problem was somehow to transform the dead data in this Python initializer into live objects.

I considered writing code that would explicitly know about the structure of all three classes and use that knowledge to grovel through the initializer creating matching objects, but rejected that idea because new class members were likely to be added over time as the configuration language grew new features. If I wrote the object-creation code in the obvious way, it would be fragile and tend to fall out of sync when either the class definitions or the initializer structure changed.

What I really wanted was code that would analyze the shape and members of the initializer, query the class definitions themselves about their members, and then adjust itself to impedance-match the two sets.

This kind of thing is called metaclass hacking and is generally considered fearsomely esoteric--deep black magic. Most object-oriented languages don't support it at all; in those that do (Perl being one), it tends to be a complicated and fragile undertaking. I had been impressed by Python's low coefficient of friction so far, but here was a real test. How hard would I have to wrestle with the language to get it to do this? I knew from previous experience that the bout was likely to be painful, even assuming I won, but I dived into the book and read up on Python's metaclass facilities. The resulting function is shown in Listing 3, and the code that calls it is in Listing 4.

Listing 3

Listing 4

That doesn't look too bad for deep black magic, does it? Thirty-two lines, counting comments. Just from knowing what I've said about the class structure, the calling code is even readable. But the size of this code isn't the real shocker. Brace yourself: this code only took me about ninety minutes to write--and it worked correctly the first time I ran it.

To say I was astonished would have been positively wallowing in understatement. It's remarkable enough when implementations of simple techniques work exactly as expected the first time; but my first metaclass hack in a new language, six days from a cold standing start? Even if we stipulate that I am a fairly talented hacker, this is an amazing testament to Python's clarity and elegance of design.

There was simply no way I could have pulled off a coup like this in Perl, even with my vastly greater experience level in that language. It was at this point I realized I was probably leaving Perl behind.

This was my most dramatic Python moment. But, when all is said and done, it was just a clever hack. The long-term usefulness of a language comes not in its ability to support clever hacks, but from how well and how unobtrusively it supports the day-to-day work of programming. The day-to-day work of programming consists not of writing new programs, but mostly reading and modifying existing ones.

So the real punchline of the story is this: weeks and months after writing fetchmailconf, I could still read the fetchmailconf code and grok what it was doing without serious mental effort. And the true reason I no longer write Perl for anything but tiny projects is that was never true when I was writing large masses of Perl code. I fear the prospect of ever having to modify keeper or anthologize again--but fetchmailconf gives me no qualms at all.

Perl still has its uses. For tiny projects (100 lines or fewer) that involve a lot of text pattern matching, I am still more likely to tinker up a Perl-regexp-based solution than to reach for Python. For good recent examples of such things, see the timeseries and growthplot scripts in the fetchmail distribution. Actually, these are much like the things Perl did in its original role as a sort of combination awk/sed/grep/sh, before it had functions and direct access to the operating system API. For anything larger or more complex, I have come to prefer the subtle virtues of Python--and I think you will, too.
[/ltr]

موفق باشین

[navidjoon]

سلام
اشکالات متن برطرف شد. این متنی که الان هست دیگه نسخه نهایی یه. اگه moderator ها اشکالی نمیبینن منتقل کنن به بخش مقالات. ممنون

قربون همه

نویدجون

[مهمان]

ناظرها نمی تونن به بخش مقالات منتقل کنن! خود آقای باغومیان باید این کار رو بکنه!
irix

[navidjoon]

ممنون irix جان
ایشالا آلن عزیز زحمتش رو بکشن. بازم ممنون

[newbie]

navidjoon نوشته:
سلام
newbie جون خواهش میکنم قابلی نداشت. اگه یادت باشه خودت بودی که لینک این دو تا مقاله رو بهم دادی. میتونم بگم که باعث شروع کردن پیتون من شدی. خیلی ممنونم. ایشالا ترجمه های بعدی. راستی نظرتون راجع به ایجاد بخش ترجمه چیه ؟
*************************
خواهش میکنمخوشحالم که به عالم python اومدید!یکی از بهترین کتابا واسه
Master شدن در python کتاب "Practical Python" هستش که توصیه میکنم
مطالعه کنید.متاسفانه من این کتاب رو ندارم اگه پیدا کردید منو هم خبر کنید

[kakilik]

مرسی