انجمن انفورماتیک ایران انجمن انفورماتیک ایران انجمن انفورماتیک ایران
گزارش کامپیوتر شماره 234, ویژه مرداد و شهریور ماه 96 منتشر شد. چهارشنبه  ٠١/٠٩/١٣٩٦ ساعت ١٦:٣٦
 

برنامه‌نویسان در حال کار
(قسمت دوازدهم)
پیتر دویچ

ترجمه ابراهیم نقیب زاده مشایخ

پست الکترونیکی: mashayekh@isi.org.ir


 

یادداشت مترجم

کتاب «Coders at Work » نوشته‌ پیتر سیبل در سال 2009 به چاپ رسیده و با وجودی که مدّت زیادی از انتشار آن نمی‌گذرد مورد استقبال زیادی از سوی طراحان نرم‌افزار و برنامه‌نویسان قرار گرفته است. پیتر سیبل، که نام کتابش را از کتاب‌های معروف و پیشین «Writers at Work » و «Founders at Work » اقتباس کرده، در این کتاب به مصاحبه با پانزده تن از برجسته‌ترین و سرشناس‌ترین برنامه‌نویسان و دانشمندان رایانه، با پیش زمینه تحصیلی و علاقه‌مندی‌های متفاوت در این حوزه، پرداخته و خواننده را با ایده‌های آن‌ها درباره زندگی و برنامه‌نویسی آشنا ساخته‌ است.
اغلب برنامه‌نویسان به تنهایی و یا در گروه‌های کوچک به فعالیت می‌پردازند و جالب‌ترین بخش فعالیتی که انجام می‌دهند در مغز آن‌ها اتفاق می‌افتد که به دور از چشم دیگران است. تنها پنجره‌ای که به کار برنامه‌نویسان وجود دارد، رفتار برنامه‌هایی است که توسط آن‌ها نوشته شده و بر روی رایانه‌ها اجرا می‌شود. بنابراین، اغلب برنامه‌نویسان تنها خودشان، و احتمالاً چند همکار معدودشان، می‌دانند که چگونه برنامه نویسی می‌کنند و چگونه این کار را فرا گرفته‌اند. پیتر سیبل به دلیل آن که خود با حرفه برنامه‌نویسی آشنایی کامل دارد، سعی نموده است تا با طرح پرسش‌های جالب و تخصصی، این گوشه‌های پنهان را برای خواننده آشکار سازد.

ترجمه این کتاب جذاب و خواندنی،‌ به صورت یک سلسله مقاله دنباله‌دار، به خوانندگان گرامی گزارش کامپیوتر تقدیم می‌گردد. امید است این پاورقی جدید نیز همچون پاورقی‌های قبلی مجله، مورد استقبال خوانندگان قرار گیرد و در انتها در قالب یک کتاب منتشر و در اختیار علاقه‌مندان گذاشته شود.

*                 *          *
پیتر دویچ یک نابغه است. او برنامه نویسی را از اواخر دهه  پنجاه میلادی، در سن یازده سالگی و هنگامی که پدرش یادداشتی را درباره برنامه نویسی محاسبات طراحی یک شتاب دهنده الکترون در دانشگاه هاروارد به خانه آورد، آغاز کرد. او خیلی زود به ام آی تی راه یافت و در آنجا زبان لیسپ را بر روی یک رایانه پی دی پی 1 پیاده سازی کرد و به اصلاح کدهای نوشته‌شده توسط برنامه نویسانی که دو برابر او سن داشتند، پرداخت.
او هنگامی که دانشجوی سال دوم دانشگاه برکلی بود، درگیر پروژه جینی ، یکی از نخستین سیستم‌های اشتراک زمانی بر پایه رایانه‌های کوچک ، شد و بخش عمده هسته سیستم عامل را نوشت. (کن تامپسون، خالق یونیکس نیز که در آن زمان دانشجوی تحصیلات تکمیلی در برکلی بود بر روی این پروژه کار می‌کرد و تجربیاتی که کسب کرد در کارهای بعدی او بر روی یونیکس تأثیر گذار بود.) دویچ پس از آن که در تلاش برای تجاری سازی سیستم پروژه جینی شکست خورد به مرکز پروژه جینی شکست خورد به مرکز پژوهشی شرکت زیراکس در پالو آلتو (PARC ) پیوست و در آنجا بر روی سیستم اینترلیسپ و ماشین مجازی اسمال تاک کار کرد و به ابداع روش ترجمه پویا (روشی برای بهبود عملکرد برنامه‌های رایانه‌ای. برنامه‌ها به طور معمول یا توسط مفسّر در زمان اجرا ترجمه می‌شوند که در این صورت عمل ترجمه در هر بار اجرای یک دستور انجام می‌گیرد و یا به طور ایستا توسط مترجم یکبار به طور کامل قبل از اجرا ترجمه می‌شوند. ترجمه پویا رویکردی دو جانبه دارد. ترجمه همانند مفسّر به طور مداوم انجام می‌شود امّا کدهای ترجمه شده در حافظه نهان ذخیره می‌گردند تا کاهش عملکرد اجرایی برنامه را به حداقل برسانند. مترجم) کمک کرد.
او در مرکز پژوهشی زیراکس به عنوان «دانشمند ارشد» فعالیت می‌کرد و در شرکت سان مایکروسیستمز نیز جزء مدیران ارشد بود. در همین‌جا بود که مقاله مشهور «هفت مغالطه رایانش توزیعی» را نوشت. او همچنین نویسنده گوست اسکریپت ، مفسّر رایگان پست اسکریپت و PDF ، است. در سال 1992، پیتر دویچ یکی از افراد گروهی بود که جایزه سیستم‌های نرم افزاری انجمن ماشین‌های رایانشی (ACM ) را به خاطر کار برروی اینترلیسپ دریافت کردند و در سال 1994 به عنوان عضو برجسته ACM انتخاب گردید.
دویچ در سال 2002 کار برروی گوست اسکریپت را رها کرد و به تحصیل در رشته آهنگسازی پرداخت. امروزه او بیشتر در زمینه آهنگسازی فعالیت می‌کند تا برنامه‌نویسی امّا هنوز نمی‌تواند در مقابل وسوسه‌های گاه‌ و بیگاه برنامه‌نویسی مقاومت کند.
ما در این مصاحبه درباره مشکلات عمیقی که به نظر او در هر زبان برنامه‌نویسی که شامل مفهوم اشاره‌گر باشد وجود دارد، این که چرا نرم‌افزار باید به عنوان یک دارایی و سرمایه در نظر گرفته شود و نه هزینه، و نیز این‌که چرا او نهایتاً کار برنامه‌نویسی حرفه‌ای را کنار گذاشت، صحبت کرده‌ایم.

      *                       *          *
سیبِل: برنامه‌نویسی را چگونه آغاز کردید؟
دویچ: من برنامه‌نویسی را کاملاً تصادفی و هنگامی که یازده سال داشتم آغاز کردم. پدرم یادداشت‌هایی درباره شتاب‌دهنده الکترون کمبریج که در آن زمان در دانشگاه هاروارد در حال ساخت بود را به خانه آورد. گروهی محاسبات طراحی آن را انجام داده‌بودند و برخی یادداشت‌های آن‌ها به طور تصادفی به دست پدرم رسیده‌بود. من آن‌ها را در اتاق کار پدرم دیدم. مقداری کد رایانه در آن بود که نظر من را به خود جلب کرد.
معلوم شد که این یادداشت‌ها در واقع ضمیمه یادداشت دیگری هستند. به این خاطر از پدرم خواستم که اگر می‌تواند یادداشت‌های اصلی را نیز به دست آورد. او هم آن‌ها را به خانه آورد و من پس از خواندن آن‌ها به پدرم گفتم «این‌ها خیلی جالب هستند» و از او درخواست کردم اگر می‌تواند ترتیبی دهد تا من کسی را که این یادداشت‌ها را نوشته ملاقات کنم. این ملاقات اتفاق افتاد. من اکنون جزئیات آن را به خاطر نمی‌آورم، زیرا مربوط به پنجاه سال پیش است. امّا باعث شد که من مقدار کمی کد برای یکی از محاسبات طراحی شتاب‌دهنده الکترون کمبریج نوشتم. بدین ترتیب بود که برنامه‌نویسی را آغاز کردم.
سیبِل: این مربوط به موقعی است که یازده سال داشتید. هنگامی که 14 یا 15 ساله بودید و پدرتان استاد ام آی تی بود در آنجا با رایانه پی دی پی 1 بازی می‌کردید.
دویچ: در آن موقع 14 سال داشتم. یادم می‌آید که یک نسخه از راهنمای برنامه‌نویسی زبان لیسپ 5/1 به دستم رسیده بود. یادم نمی‌آید که چگونه و از کجا. یکی از نسخه‌های اولیه بود که به صورت استنسیل تکثیر شده‌بود و جوهرش ارغوانی رنگ بود. در زبان لیسپ چیزی وجود داشت که توجه مرا به خود جلب کرد. من همیشه استعداد ریاضی داشتم و زبان لیسپ به نظرم ریاضی‌وار آمد. دلم می‌خواست رایانه‌ای در اختیار داشته ‌باشم که بتوانم بر روی آن به زبان لیسپ برنامه‌نویسی کنم امّا دستم از رایانه بزرگ ساختمان شماره 26 کوتاه بود. در نتیجه، خودم لیسپ را بر روی پی دی پی 1 پیاده‌سازی کردم.
سیبِل: آیا هیچ به یاد می‌آورید که چگونه این کار را کردید؟
دویچ: برنامه خیلی کوچکی بود. آیا لیستش را دیده‌اید؟ فقط چند صد خط برنامه به زبان همگذاری (اسمبلی) بود.
سیبِل: بله من آن را دیده‌ام. امّا سعی نکردم درکش کنم. آیا صرفاً تبدیل مو به موی مطالب نوشته‌شده در کتابچه راهنمای لیسپ 5/1 به زبان همگذاری بود؟
دویچ: نه، نه، نه. آنچه در کتابچه راهنما آمده بود یک مفسّر بود. من مجبور بودم برنامه مربوط به خواندن متن برنامه و تفکیک نشانه‌ها را خودم بنویسم و مجبور بودم ساختمان داده‌ها را طراحی کنم و این جورکارها. یادم می‌آید که آن کار را مشابه روشی که اغلب برنامه نویسی‌هایم را انجام داده‌ام، یعنی ابتدا طراحی ساختمان داده‌ها، انجام دادم. هنگامی که آنقدر جوان بودم که قوّه شهودم مرا به مسیر صحیح راهنمایی می‌کرد، این یک رویکرد خیلی خوب بود.
در این چند سال اخیر متوجه شده‌ام که دیگر قوّه شهودم به خوبی سابق عمل نمی‌کند. من اکنون چند سال است که گاه و بیگاه بر روی تولید یک ویرایشگر متن باز برای تنظیم موسیقی کار می‌کنم و متوجه شده‌ام که این‌که اجازه دهم قوّه شهودم مرا به ساختمان داده‌های صحیح هدایت کند و سپس برنامه‌نویسی‌ها را حول آن انجام دهم، دیگر کار نمی‌کند.
سیبِل: فکر می‌کنید قوّه شهودتان بدتر شده یا این‌که قبلاً توان بیشتری داشتید و می‌توانستید حتی مواقعی که خوب کار نمی‌کرد آن را به کار بیندازید؟
دویچ: فکر می‌کنم یک مقدار از هر دو، هر چند بیشتر فکر می‌کنم حالت اوّل باشد. به عقیده من، قوّه شهود واقعاً عبارت است از فرایند ترکیب و به دست آوردن یک راه حل از میان حجم عظیمی از داده‌ها. و من به تدریج که از کارهای مربوط به تولید نرم افزار دور و دورتر شده‌ام، داده‌هایی که به آن فرایند ترکیب وارد می‌شوند، کمتر قابل دستیابی شده‌اند.
من شنیده‌ام که می‌گویند برای این‌که در کاری استاد شوید باید موارد زیادی، مثلاً 20،000 مورد مشخص را در خاطر داشته باشید. اتفاقی که درباره 20،000 مورد طراحی نرم‌افزار که ظرف 45 سال فعالیت نرم‌افزاری من از جلوی چشمم گذشته، افتاده این است که به تدریج کمتر و کمتر برای حافظه‌ام قابل دستیابی شده‌اند. فکر می‌کنم اتفاقی که افتاده، این است.
سیبِل: آیا به یاد می‌آورید که چه چیز برنامه‌نویسی شما را به خود جلب کرد؟
دویچ: من همیشه به سیستم‌های نمادهای صریح، مثل زبان‌ها، علاقه‌مند بوده‌ام. نه فقط زبان های گفتاری- زبان‌های انسانی- بلکه زبان‌هایی که بیان آن‌ها تأثیر گذار باشد. زبان‌های برنامه‌نویسی هم مطمئناً در این دسته قرار می‌گیرند.
از این‌جا همچنین می‌توان دریافت که چرا من از تولید نرم افزار به آهنگسازی روی آورده‌ام. موسیقی نیز یک زبان یا خانواده‌ای از زبان هاست امّا چیزی که شما به این زبان‌ها بیان می‌کنید نه تنها دارای دلالت صریح است بلکه بر روی مردم نیز تأثیر می‌گذارد. نکته جالب درباره موسیقی این است که از لحاظ صوری بودن، در میان زبان‌های طبیعی و زبان‌های رایانه‌ای قرار می‌گیرد. از زبان طبیعی، صوری‌تر و ساختیافته‌تر است امّا ساختار یا صوری بودن یک زبان رایانه‌ای را ندارد. فکر می‌کنم که به همین دلیل بود که من به موسیقی روی آوردم و مثلاً به سراغ شعر نرفتم. من فکر می‌کنم زبان شعر به قدر کافی برای من ساختیافته نیست.
سیبِل: آیا نخستین برنامه جالبی که نوشتید را به خاطر می‌آورید؟
دویچ: نخستین برنامه‌ای که به خاطر جالب بودنش نوشتم در واقع دومین برنامه‌ای بود که نوشتم. نخستین برنامه من همان طور که گفتم محاسبات مربوط به شتاب‌دهنده الکترون کمبریج بود. دومین برنامه‌ای که نوشتم، برنامه قالب‌بندی خروجی اعداد با ممیز شناور بود.
سیبِل: که مسأله ترسناکی است.
دویچ: خوب، روی یک ماشین دودویی ترسناک است، نه روی ماشین دهدهی و من بر روی یک ماشین دهدهی کار می‌کردم. شما باید رشته ارقام را جابجا می‌کردید و تصمیم می‌گرفتید نقطه اعشار را کجا قرار دهید. باید تصمیم می‌گرفتید که از قالب E یا F استفاده کنید. امّا در آن روزها همه چیز کمی سخت‌تر بود. من برنامه را به زبان همگذاری بر روی یک ماشین پردازش دسته‌ای می‌نوشتم. بنابراین، مسأله بدیهی و واضحی نبود. البته خیلی سخت هم نبود امّا بدیهی هم نبود. این نخستین برنامه جالبی بود که نوشتم.
سیبِل: شما در دوران دبیرستان مرتباً به ام آی تی می‌رفتید امّا برای دانشگاه، برکلی را انتخاب کردید. آیا می‌خواستید از ساحل شرقی (آمریکا) فرار کنید؟
دویچ: تقریباً. من به این نتیجه رسیدم که اگر به جایی دور از خانواده بروم برایم خیلی خوب است. سه محلی که به طور جدّی در نظر گرفتم عبارت بودند از دانشگاه روچستر، دانشگاه شیکاگو و برکلی. فکر زیادی لازم نداشت زیرا تنها یکی از این سه محل هوای مناسبی داشت. به این ترتیب بود که سر از برکلی درآوردم. و این یکی از بهترین اتفاقاتی بود که در زندگی من افتاد.
در برکلی خیلی زود با پروژه جینی آشنا شدم و شخصیت حرفه‌ای من در آنجا شکل گرفت. از آنجا هم به شرکت زیراکس پیوستم.
سیبِل: ظاهراً در برکلی بر روی پروژه بزرگتری در مقایسه با پیاده سازی لیسپ بر روی پی دی پی، کارتان را شروع کردید.
دویچ: اوه، بله. خیلی بزرگتر. من برای شروع، بخش اعظم هسته سیستم عامل را نوشتم. هسته سیستم عامل تقریباً 10،000 خط بود.
سیبِل: این تغییر در اندازه کار، چقدر فرایند طراحی شما را تغییر داد؟
دویچ: سعی می‌کنم به یاد بیاورم که در هسته سیستم عامل چه قرار داشت. هنوز برنامه‌های به قدر کافی کوچکی بودند که بتوانم کلّ آن‌ها را یکباره در نظر بگیرم و بنویسم. البته بخش‌های کارکردی مختلفی وجود داشت و من مدل ذهنی روشنی درباره این که کدام بخش برنامه مجاز به تعامل با کدام ساختمان داده‌ها می‌باشد. داشتم. امّا در واقع ساختمان داده‌های زیادی وجود نداشت. یک جدول فرایندها بود و لیست‌های فرایندهای آماده . میانگیرهای ورودی- خروجی و چند چیز برای ردگیری حافظه مجازی. و البته یک جدول پرونده به ازای هر فرایند. تعریف تمام ساختمان داده‌های سیستم در دو صفحه جا می‌گرفت. منظورم این است که درباره سیستم پیچیده‌ای صحبت نمی‌کنیم.
سیبِل: بزرگترین سیستمی که بر روی آن کار کرده‌اید چه بوده است؟
دویچ: من تاکنون سه پروژه بزرگ را آغاز کرده و به انجام رسانده‌ام. یکی گوست اسکریپت- بجز گرداننده‌های دستگاه که قسمت عمده‌اش را من ننوشتم- که بین 50 هزار تا صد هزار خط برنامه C بود.
دیگری مترجم پویا در پروژه ماشین مجازی اسمال تاک که بین سه هزار تا پنج هزار خط برنامه C بود. و بالاخره پیاده‌سازی اینترلیسپ که در حدود پنج هزار خط برنامه لیسپ بود. بنابراین، گوست اسکریپت احتمالاً بزرگترین سیستمی بوده‌است که من درگیر آن بوده‌ام.
سیبِل: و بجز گرداننده دستگاه که توسط افراد دیگری نوشته‌شد، بقیه‌اش را خودتان به تنهایی نوشتید؟
دویچ: تا پایان سال 1999، تمام خط به خط برنامه را خودم نوشتم. در ابتدا چند تصمیم درباره معماری نرم افزار گرفتم. نخستین تصمیم، جداسازی کامل مفسّر زبان از گرافیک بود.
سیبِل: منظورتان از زبان، پست اسکریپت است؟
دویچ: درست است. بنابراین، مفسّر زبان هیچ چیز درباره ساختمان داده‌های مورد استفاده برای کارهای گرافیکی نمی‌دانست و با کتابخانه روال‌های گرافیکی از طریق واسط برنامه کاربردی (API ) حرف می‌زد.
دومین تصمیمی که گرفتم، ساختاردهی به کتابخانه روال‌های گرافیکی با استفاده از واسط گرداننده بود. در نتیجه، کتابخانه، نقاط تصویری (پیکسل) را درک می‌کرد و تصویرسازی منحنی و متن را درک می‌کرد امّا اطلاعات بسیار کمی درباره چگونگی کدگذاری نقاط تصویری برای یک دستگاه خاص و چگونگی انتقال نقاط تصویری به یک دستگاه خاص داشت.
سومین تصمیم‌گیری این بود که گرداننده‌ها پیاده‌سازی فرمان‌های ترسیمی پایه را انجام دهند که در آغاز، اساساً draw-pixmap و fill-rectangle بود.
این‌ها سه تصمیم عمده معماری بودند که من از قبل گرفتم و همگی تصمیم‌های خوبی بودند. فکر می‌کنم اصلی که دنبال کردم این بود که اگر چیزی داشتید که در چند دامنه عمل می‌کرد و دامنه‌ها به طور ذاتی تعامل زیادی با هم نداشتند، این وضعیت محل مناسبی برای قرار دادن یک مرز و محدوده نرم‌افزاری قوی است. تفسیر زبان و عملیات گرافیکی نیز به طور ذاتی تعامل چندانی با هم نداشتند.
بدین ترتیب بود که من پیش از آن که نخستین خط کدهای گرافیکی را بنویسم، مفسّر پست اسکریپت سطح 1 را نوشتم. من تمام آن را حتی پیش از آن که شروع به طراحی عملیات گرافیکی کنم، انجام دادم. بین زمانی که کار را آغاز کردم و زمانی که قادر بودم تایپ کنم« 3  4  add equals » و جواب 7 را برگرداند، در حدود سه هفته طول کشید. خیلی آسان بود. و ضمناً بگویم که محیطی که  در آن کار می‌کردم MS-DOS بود.MS-DOS  با ویراستار متن Emacs و مترجم زبان C .
سیبِل: شما پیش از آن نیز پیاده‌سازی مفسّر برای یک زبان را بارها انجام داده‌ بودید. آیا این‌بار مستقیماً به سراغ نوشتن کد C رفتید یا شروع به رسم نمودارهای ساختمان داده‌ها کردید؟
دویچ: این کار آنقدر به نظرم ساده می‌آمد که نیازی به رسم نمودار نمی‌دیدم. همان‌طور که پیش از این گفتم من دوست دارم طراحی نرم‌افزار را با طراحی ساختمان داده‌ها آغاز کنم. من می‌دانستم که یک مفسّر از نظر عملیاتی از چه بخش‌هایی تشکیل می‌شود. در نتیجه، من آن‌ها را به پرونده‌های جداگانه‌ای تقسیم کردم.
10 سال بعد که درگیر ثبت حق تألیف (کپی رایت) گوست اسکریپت شدم باید لیست کامل پیاده‌سازی اولیه گوست اسکریپت را برای آن‌ها می‌فرستادم. برایم جالب بودکه هنگامی که به کد اولیه و ساختمان داده‌های اولیه و نام های اولیه نگاه کردم متوجه شدم 70 تا 80 درصد ساختارها و نامگذاری‌ها هنوز همان هستند که در نسخه اولیه بودند. 10 سال گذشته بود و دو تجدید نظر اساسی در زبان پست اسکریپت به عمل آمده بود.
این کاری بود که من در اصل انجام دادم. ابتدا ساختمان داده‌ها و سپس تقسیم بندی کلّی و نه چندان دقیق به پودمان‌ها (ماجول). هنوز هم اعتقاد دارم اگر تصمیم‌گیری درستی درباره ساختمان داده‌ها و مقادیر ثابت به عمل آید، بخش اعظم کد خودش نوشته می‌شود.
سیبِل: آیا طرز تفکر شما درباره برنامه‌نویسی نسبت به آن روزهای اولیه تغییر کرده است؟
دویچ: تغییر زیادی کرده‌است زیرا نوع برنامه‌هایی که اکنون برایم جالب هستند، تغییر زیادی کرده‌اند. به نظرم اکنون می‌توانم ادعا کنم برنامه‌هایی که در چند سال اوّل نوشتم، تکه کدهای کوچکی بیش نبودند. به تدریج و در طول زمان، موضوعاتی نظیر این که چگونه باید برنامه‌هایی که کارهای بزرگتر و جالب‌تری انجام می‌دهند را ساختاردهی و طراحی کرد و چگونه باید زبان‌هایی برای پیاده‌سازی آن‌ها در نظر گرفت به نحوی که اهداف ما در مورد قابلیت اطمینان، کارایی و شفافیت را برآورده کنند، برایم مطرح شدند.
اکنون به مجموعه بسیار بزرگتری از معیارها برای ارزیابی نرم‌افزار آگاهی یافته‌ام. و به این معیارها در بافت برنامه‌های بسیار بزرگتر و پیچیده‌تر فکر می‌کنم، برنامه‌هایی که جنبه‌های سیستمی و معماریشان سخت‌ترین کار و تلاش را می‌طلبد. نمی‌خواهم بگویم که در سطح الگوریتم دیگر کار سختی برای انجام دادن وجود ندارد امّا این جنبه دیگر برایم خیلی جالب نیست.
سیبِل: آیا تمام برنامه‌نویسان باید تلاش کنند تا به این سطح برسند؟
دویچ: نه. به تازگی یکی از دوستان قدیمی‌ام در مرکز پژوهشی زیراکس به نام لئوگوئیباس به جایزه مهمی در این رشته دست یافته است. او هرگز آدم سیستمی نبوده است. او یک آدم الگوریتمی برجسته بوده است. او راهی را برای فکر کردن درباره رده‌های خاصی از تحلیل یا الگوریتم‌های بهینه‌سازی کشف کرده‌است که آن‌ها را برای بسیاری از مسائل مختلف قابل اعمال می‌سازد. کار فوق‌العاده‌ای انجام داده‌است. برنامه نویسان باید تلاش کنند تا به سطح لئوگوئیباس هم برسند.
وجه تشابهی بین اصول معماری و اصول طراحی الگوریتم وجود دارد که لئو و افرادی نظیر او به این مسائل پیچیده و دشوار تحلیل و بهینه‌سازی روی آورده‌اند. تفاوت این است که اصولی که به مسائل الگوریتمی می‌پردازد به مقدار زیادی مستقیماً بر پایه 5000 یا 10،000 سال تاریخچه ریاضیات قرار دارد. امّا در مورد برنامه‌نویسی چنین بنیاد و پایه‌ای وجود ندارد. و این یکی از دلایلی است که این همه نرم‌افزار آشغال و مزخرف وجود دارد. ما هنوز واقعاً نمی‌دانیم که داریم چکار می‌کنیم.
سیبِل: آیا به نظر شما خوب است که افرادی که استعداد تفکر در سطح سیستمی را ندارند به کار در بخش‌های کوچکتر نرم‌افزار بپردازند؟ آیا می‌توان برنامه‌نویسان را از معماران جدا کرد؟ یا این که دلتان می‌خواهد هر کس که بر روی نرم افزارهای سیستمی کار می‌کند قادر باشد در سطح سیستمی هم فکر کند؟
دویچ: من فکر نمی‌کنم ابزارهای خوبی برای پرداختن به چیزهایی که هنگام بزرگ شدن سیستم‌ها اتفاق می‌افتد در اختیار داشته باشیم. من فکر می‌کنم چیزهایی که هنگام بزرگ شدن سیستم‌ها اتفاق می‌افتد از نظر کیفی با چیزهایی که هنگامی که سیستم‌های کوچک به سیستم‌های متوسط تبدیل می‌شوند اتفاق می‌افتد، تفاوت دارند.
امّا درباره این‌که چه کسی باید نرم‌افزار بنویسد، پاسخ سرراست و خوبی برای آن ندارم. چیزی که می‌دانم این است که هر چه بیشتر به عمق نرم‌افزار می‌نگرم بیشتر به این نتیجه می‌رسم که چیزی که خیلی اهمیت دارد این است که نرم‌افزار توسط افراد خیلی خوب نوشته شود.
یکی از دلایل اتفاقاتی که امروز در زمینه نرم‌افزار می‌افتد این است که مرز بین این که چه چیزی نرم‌افزار است و چه چیزی نرم‌افزار نیست مخدوش شده است. برای مثال اگر کسی وبگاه طراحی می‌کند و آن وبگاه بخواهد هر نوع رفتار پیچیده‌ای از نظر تعامل با کاربر یا ردگیری وضعیت‌های مختلف و ... داشته باشد، برای ساختن چنین وبگاه‌هایی ابزار وجود دارد. و کارکردن با این ابزارها همان نتیجه‌ای را در انتها به بار می‌آورد که فرد خودش برنامه‌نویسی می‌کرد. امّا به کارگیری ابزار خیلی به برنامه‌نویسی شباهت ندارد.
بنابراین، یکی از پاسخ‌هایی که به پرسش شما می‌توان داد این است که در طول زمان، مقدار بیشتر و بیشتری از آنچه مردم فکر می‌کنند به برنامه‌نویسی نیاز دارد، «برنامه نویسی» نخواهد بود و افراد بیشتر و بیشتری قادر به انجام آن خواهند بود.
داستان قدیمی تلفن و متصدیان تلفن را شنیده‌اید؟ در روزگار اولیه پیدایش تلفن، هنگامی که مشخص شد استفاده از آن با نرخ رشد فوق‌العاده‌ای روبروست، افراد بیشتر و بیشتری به عنوان متصدی تلفن استخدام می‌شدند زیرا تلفن‌های شماره‌گیری هنوز موجود نبود. یک نفر با در نظر گرفتن نرخ رشد استفاده از تلفن برآورد کرده بود که تا 20 یا 30 سال آینده تمام افراد متصدی تلفن خواهند شد. خوب، این اتفاقی بود که افتاد. من فکر می‌کنم یک چیزی شبیه این ممکن است در مورد برنامه‌نویسی هم روی دهد.
سیبِل: آیا برنامه‌نویسان هم ممکن است به همان ترتیب جایگزین شوند؟
دویچ: بستگی به این دارد که بخواهید چه برنامه‌ای بنویسید. یکی از چیزهایی که در پنج سال گذشته من گاه و بیگاه به آن فکر کرده‌ام این است که «چرا برنامه نویسی این‌قدر سخت است؟»
برنامه‌نویسی یک جنبه الگوریتمی دارد که خیلی نزدیک به ریاضیات است و شما می‌توانید اگر بخواهید از ریاضیات به عنوان مدل پایه برای آن استفاده کنید. شما می‌توانید از روش‌های ریاضی و شیوه تفکّر ریاضی استفاده کنید. این‌ها البته کار را آسان نمی‌کند زیرا هیچکس فکر نمی‌کند که ریاضیات آسان است. بنابراین، رقابتی است بین موضوعی که روی آن‌ کار می‌کنید و درک ما از آن موضوع و درک ما از سطح مهارتی مورد نیاز برای کار کردن با آن.
من فکر می‌کنم بخشی از مشکل با نوع دیگر برنامه‌نویسی این است که دنیای تمامی زبان‌های برنامه‌نویسی که ما در اختیار داریم آنچنان با دنیای واقعی که احساس ما و مغز ما و جامعه ما پدید آورده‌اند تفاوت دارد که نباید انتظار داشت کسی بتواند خوب برنامه‌نویسی کند. یک نفر برای این‌که برنامه‌نویس واقعاً خوبی باشد باید کمی «عوضی» باشد. شاید لفظ «عوضی» کمی تند باشد امّا ویژگی‌هایی که یک نفر را انسانی با عملکرد خوب می‌سازد و ویژگی‌هایی که یک نفر را برنامه‌نویس واقعاً خوبی می‌سازد، مقدار کمی همپوشانی دارند. و من به عنوان کسی صحبت می‌کنم که قبلاً برنامه‌نویس خیلی خوبی بوده‌است.
دنیای رایانش فون نویمانی و زبان‌های خانواده الگول آنچنان نیازها و خواسته‌های متفاوتی با دنیای واقعی دارند که برای من کاملاً شگفت‌انگیز است که می‌بینم سیستم‌های بزرگ نرم‌افزاری، حتی با همین کیفیت نازل امروزی، اصلاً کار می‌کنند.
من به دور و برم که نگاه می‌کنم چیزی مثل اشاره‌گر نمی‌بینم. ما در دنیای واقعی شیء داریم امّا نه چنین چیز عجیب و غریبی که دانشمندان رایانه «شیء» می‌نامند.
سیبِل: در باره مقیاس‌ها چیزی نگفتید. 2 به توان 64 هر چیز، خیلی بزرگ است و چیزهایی که میلیاردها بار در ثانیه اتفاق می‌افتند خیلی سریعند.
دویچ: امّا در دنیای واقعی این‌ها با ما کاری ندارند. عدد آوگادرو را می‌شناسید؟ 2 به توان 23؟ (عدد آوگادرو توسط پرین تعریف شده و عبارت است از تعداد مولکول‌ها در یک گرم هیدروژن. مترجم) ما به دنیایی نگاه می‌کنیم که تعداد بسیار زیادی چیزهای کوچک دارد که همگی دور هم جمع شده‌اند. این موضوع ما را ناراحت نمی‌کند زیرا دنیای ما به گونه‌ای است که شما نباید یک شیء را در سطح اتم‌هایش درک کنید.
خصوصیات فیزیکی اشیاء به گونه‌ای هستند که در9/99 درصد مواقع شما می‌توانید آن‌ها را به صورت یک شی‌ء کلّی درک کنید. امّا در اکثر مواقع چنین چیزی درمورد نرم‌افزار صادق نیست. نرم‌افزار همیشه با جزئیات سروکار دارد و این مشکل بنیادی و وحشتناک آن است. تا وقتی که ما یاد نگیریم چگونه نرم‌افزار را سازمان دهی و مجسّم کنیم به نحوی که نیازی نباشد که به این فکر کنیم که چگونه هر تکه کوچک با تکه‌های دیگر تعامل دارد، وضع خیلی از این بهتر نمی‌شود. و ما خیلی از این نقطه دور هستیم.
سیبِل: آیا علل تکنیکی، چیزهایی هستند که می‌توانند تغییر کنند یا این طبیعت نرم‌افزار است؟
دویچ: باید از نو آغاز کرد. باید تمام زبان‌هایی که دارای مفهوم اشاره‌گر هستند را دور انداخت زیرا در دنیای واقعی چیزی به عنوان اشاره‌گر وجود ندارد. باید این‌گونه استدلال کرد که اطلاعات، فضایی را اشغال می‌کنند و برای مدتی وجود دارند و در مکان خاصی قرار گرفته‌اند.
سیبِل: به مرور که از نوشتن تکه‌های کوچک کد به ساختن سیستم‌های بزرگ روی آوردید، آیا هنوز تکه‌های کوچک کد را به همان شیوه سابق می‌نوشتید و فقط دیدگاه تازه‌ای در مورد سیستم‌های بزرگ اضافه شده بود یا این‌که شیوه انجام همه کارها تغییر کرد؟
دویچ: روش انجام همه کارها را تغییر داد. نخستین برنامه مهمی که نوشتم همان بود که بر روی رایانه یونیواک در هاروارد نوشتم. برنامه بعدی، کاری بود که بر روی پی دی پی 1 در ام آی تی کردم. در واقع، سه برنامه یا سیستم مختلف را در اوایل دهه 1960، هنگامی که دانش‌آموز دبیرستان بودم، نوشتم. یکی مفسّر لیسپ که برای پی دی پی 1 ساختم. یکی کارهایی که بر روی سیستم عامل برای رایانه پی دی پی 1 اصلاح شده جک دنیس انجام دادم. و بالاخره یک ویراستار متن برای پی دی پی 1 جک دنیس.
این سه سیستم را هنوز اساساً به صورت یکپارچه نوشتم. تفاوتی که با برنامه‌های قدیمی‌تر که بر روی یونیواک نوشته بودم داشتند این بود که مجبور بودم با طراحی ساختمان داده‌ها شروع کنم. در نتیجه، این نخستین تغییر در نوع برنامه‌نویسی که انجام می‌دادم بود.
من کم‌کم داشتم از بخش‌بندی کارکردی برنامه آگاه می‌شدم امّا فکر نمی‌کردم تأثیر خاصی داشته باشد. من به این نکته پی برده بودم که می‌توان بخش‌های خاصی از برنامه را نوشت بدون آن‌که نیازی به فکر کردن درباره  سایر بخش‌های برنامه باشد امّا یادم نمی‌آید که موضوع رابط‌ها که به هنگام بزرگ شدن برنامه‌ها واقعاً بسیار مهم می شوند را در نظر می‌گرفتم.
این تغییر در خوشه بعدی کارم اتفاق افتاد، هنگامی که دانشجوی برکلی بودم و بر روی پروژه جینی کار می‌کردم: کار بر روی سیستم اشتراک زمانی 940 و ویراستار متن QED . من یک اشکال زدای زبان همگذاری (اسمبلی) هم نوشتم امّا چیز زیادی درباره آن را به خاطر نمی‌آورم.
گام بعدی کار بر روی سیستم عامل بود. درست نیست بگویم من تمام سیستم عامل را نوشتم. نه، چنین نبود امّا تمام هسته سیستم عامل را من نوشتم. این‌کار به زبان همگذاری انجام شد. ما داریم درباره برنامه‌هایی صحبت می‌کنیم که کم‌کم بزرگتر و بزرگتر می‌شدند. این یکی در حدود 10،000 خط برنامه بود. زمانبند فرایند داشت. حافظه مجازی داشت و سیستم پرونده‌ها داشت. در واقع، چند سیستم پرونده داشت.
در اینجا پرسش‌های پیچیده‌تری درباره طراحی ساختمان داده‌ها وجود داشت. یکی از آن‌ها را که اکنون به یاد می‌آورم این بود که یک جدول فرایندهای فعّال وجود داشت و این پرسش مطرح بود که آن را چگونه طراحی کنیم و سیستم عامل چگونه باید بفهمد که یک فرایند، قابل اجراست یا نه. ساختارهایی برای ردگیری سیستم حافظه مجازی وجود داشت. خوب، بعضی از جنبه‌های رابط‌ها هم کم‌کم شروع به پدیدار شدن کردند. البته نه در خود سیستم عامل چون سیستم عامل نسبتاً کوچک بود و هسته‌اش اساساً به عنوان یک تکّه یکپارچه طراحی شده‌ بود.
در دو زمینه مهم، جنبه‌های رابط‌های نرم‌افزاری شروع به پدیدار شدن کردند. یکی از آن‌ها رابط بین برنامه کاربر و هسته بود. فراخوانی‌های سیستم چه باید باشند؟ آرایش پارامترها چگونه باید باشد؟ می‌دانستم که در گونه‌های نخستین سیستم اشتراک زمانی 940، عملیات پایه‌ برای خواندن و نوشتن پرونده‌ها معادل فراخوانی‌های read و write در یونیکس بود. یعنی شما فقط یک نشانی پایه و یک شمارنده را به عنوان پارامتر در نظر می‌گرفتید. این‌ها خیلی خوب بودند امّا در بسیاری از مواقع آن چیزی که شما می‌خواستید نبودند. شما اساساً یک رابط جریان می‌خواستید. و در آن روزها، این مفهوم که شما بتوانید امکانات یک سیستم عامل را بگیرید و سپس کد سطح کاربر را دور آن بپیچید و رابط زیباتری به دست آورید- به شیوه‌ای که getc و putc بر روی read و write ساخته شدند- هنوز مطرح نشده بود. در نتیجه، کاری که ما کردیم این بود که در گونه‌های بعدی سیستم عامل، دو فراخوانی سیستم عامل اضافه کردیم که معادل getc و putc بودند.
جای دیگری که موضوع رابط مطرح شد این بود که ما از ابتدا یک تمایز جدّی و قوی بین هسته و آنچه امروز بدان پوسته گفته می‌شود قائل بودیم. این هنوز در ابتدای تولید سیستم‌های عامل بود و ما نمی‌دانستیم که شما می‌توانید یک پوسته بدون امتیاز خاصی بسازید. پوسته یک برنامه در حالت کاربر امّا دارای مقدار زیادی امتیازات خاص بود. خوب، این موضوع مطرح بود که هسته چه امکاناتی باید به پوسته بدهد؟ چه کارهایی را پوسته باید بتواند مستقیماً انجام دهد و برای چه کارهایی باید هسته را فراخوانی کند؟
انتخاب‌های مربوط به طراحی رابط برای ما از درون خودِکار پدیدار شد. این نقطه‌ای در زندگی حرفه‌ای من بود که من پی به این نکته بردم که رابط‌های بین اجزاء باید جداگانه طراحی شوند و این که این رابط‌ها نیز یک جنبه مهم طراحی هستند.
بنابراین، در پاسخ به سئوال شما که آیا شیوه برنامه‌نویسی من در مورد برنامه‌های کوچک، هنگامی که شروع به کار در سیستم‌های بزرگتر کردم تغییر کرد یا نه، باید بگویم بله. به تدریج که سیستم‌های بزرگتر و بزرگتری ساختم، دریافتم که هنگامی که می‌نشینم تا یک تکّه کد بنویسم، نخستین پرسشی که از خودم می‌کنم این است که «خوب، رابط بین این و چیزهایی که پیرامونش قرار دارند چه شکلی باشد؟ چه پارامترهایی وارد شوند؟ چه پارامترهایی خارج شوند؟ چه مقدار از کارباید درکدام طرف رابط قرار داده شود؟» این نوع پرسش‌ها رفته‌رفته بخش بزرگتر و بزرگتری از آنچه با آن سروکار داشتم را تشکیل دادند. و فکر می‌کنم بر شیوه‌ای که من تکه‌های کوچک کد را می‌نوشتم نیز تأثیر گذاشتند.
سیبِل: و این پیامد طبیعی کار بر روی سیستم‌های بزرگتر بود- نهایتاً سیستم‌ها آنقدر بزرگ شدند که شما باید راهی برای تجزیه آن‌ها به بخش‌های مختلف می‌یافتید.
دویچ: درست است. تجزیه در سطوح مختلفی اتفاق می‌افتد. البته فکر نمی‌کنم نوع تجزیه‌ای که در سیستم‌های بزرگتر صورت می‌گیرد از نظر کیفی مشابه تجزیه‌ای باشد که در سیستم‌های کوچکتر روی می‌دهد، مطمئن نیستم. وقتی شما یک سیستم کوچکتر را تجزیه می‌کنید ممکن است مثلاً به تخصیص منابع فکر نکنید، در حالی که در تجزیه یک سیستم بزرگتر چنین چیزی وجود دارد.

سیبِل: آیا با کسانی کار کرده‌اید که به عقیده شما آن‌ها برنامه نویسان خیلی خوبی بودند امّا فقط تا سطح خاصی می‌توانستند کار کنند؟ مثلاً آن‌ها می‌توانستند بر روی مسایلی تا یک اندازه خاص، خوب کار کنند امّا فراتر از آن، ذهنیت لازم برای شکستن مسأله به بخش‌های کوچکتر و فکر کردن درباره آن به این شیوه را نداشتند.
دویچ: من با برنامه‌نویسانی کار کرده‌ام که خیلی باهوش بودند امّا تجربه لازم در سطح برنامه‌نویسی سیستم‌های بزرگ را نداشتند. و در پروژه گوست اسکریپت، اختلاف نظر جدّی با دو نفر از مهندسان تیم پروژه داشتم. آن‌ها هر دو خیلی باهوش و سختکوش و با تجربه بودند. من فکر می‌کردم آن‌ها برنامه نویسان و طراحان خیلی خوبی هستند. امّا تفکر سیستمی نداشتند. نه تنها عادت نداشتند که به تأثیر یا پیامد تغییرات فکر کنند بلکه تا حدّی حتی اعتقاد هم نداشتندکه این یک پرسش اساسی است. از نظر من تفاوت بین کسانی است که درک می‌کنند در طراحی یک سیستم بزرگ چه پرسش‌هایی مطرح است و باید پرسیده شود و کسانی که به هر دلیل این پرسش‌ها برایشان مطرح نیست.
سیبِل: آیا به نظر شما مهارت‌های خاصی در شما وجود داشت که باعث شد برنامه‌نویس خوبی بشوید؟
دویچ: هنگامی که من در اوج توانایی‌هایم در زمینه برنامه‌نویسی بودم، قوه شهود قابل اعتمادی داشتم. کارها را انجام می‌دادم و درست از آب درمی‌آمدند. برخی از آن‌ها خوش شانسی بود. امّا مطمئنم برخی دیگر به دلیل تجربیاتی بود که در اعماق وجود من جای گرفته بودند و من دستیابی خودآگاه و هشیارانه‌ای به آن‌ها نداشتم و به طور شهودی از این تجربیات استفاده می‌کردم. می‌دانم که این پاسخ قانع کننده‌ای برای شما نیست امّا قلباً اعتقاد دارم که یکی از مهمترین چیزهایی که از من یک برنامه نویس خوب ساخت، همین بوده‌است.
سیبِل: در آن روزهای نوجوانی که مرتب به ام آی تی می‌رفتید آیا برایتان پیش آمد که بگوئید «این فرد خیلی باهوش است امّا نمی‌داند این کار را چگونه انجام دهد، در صورتی که من می‌دانم.»
دویچ: نه، چنین چیزی پیش نیامد. امّا یادم می‌آید هنگامی که شروع به بازنویسی ویراستار متن بر روی پی دی پی 1 کردم،‌ پانزده یا شانزده ساله بودم. کد اصلی توسط یک یا دو نفر نوشته شده بود که هر دو خیلی باهوش و عضو یک باشگاه فنی بودند. و هنگامی که من به کد آن‌ها نگاه کردم فکر کردم مقدار زیادی از آن افتضاح است.
نمی‌خواهم بگویم این تفاوت بین من و افراد دیگر بود. بلکه این تفاوت بین شیوه‌ای که من فکر می‌کردم کد باید باشد و آنچه در پیش‌رویم می‌دیدم بود.
من همیشه با دنیای نمادها احساس راحتی کرده‌ام. نمادها و الگوهای آن‌ها همیشه خوراک من بوده‌اند. و برای خیلی از افراد این چنین نیست. من این را حتّی در مورد دوست و همکارم هم دیده‌ام. ما هر دو موسیقیدان هستیم. ما هر دو آهنگساز هستیم. ما هر دو خواننده هستیم. امّا من صرفاً از نقطه نظر نمادها به سراغ موسیقی آمده‌ام. من بخش زیادی از آهنگسازی‌هایم را فقط با مداد و کاغذ انجام داده‌ام. نت‌ها در آن قرار دارند و من نیازی ندارم که پشت پیانو بنشینم و صدایشان را بشنوم. من صدای آن‌ها را همانجا روی کاغذ می‌شنوم.
امّا او اغلب آهنگسازی‌هایش را با گیتار انجام می‌دهد. گاهی هم با پیانو. و هرگز چیزی را روی کاغذ نمی‌نویسد. رویکرد او به آهنگسازی کاملاً با رویکرد من که بر پایه نمادهاست تفاوت دارد.
برخی از افراد به آن شکل عمل می‌کنند و برخی دیگر به این شکل. خوب، اگر بخواهم نتیجه‌گیری کنم می‌توانم بگویم کسانی باید برنامه‌نویس شوند که با دنیای نمادها احساس راحتی بکنند.
سیبِل: آیا شما معلّم و راهنمای مهمی داشته‌اید؟
دویچ: دو نفر بودند. یکی از آن‌ها کسی است که دیگر در بین ما نیست. نامش کالوین مور بود. او یکی از پیشگامان سیستم‌های اطلاعاتی بود. فکر می‌کنم عبارت بازیابی اطلاعات را برای نخستین بار او به میان انداخت. سابقه او اصلاً در علوم کتابخانه‌ای بود. من او را هنگامی که در دبیرستان یا سال اول دانشگاه بودم دیدم. او طراحی یک زبان برنامه‌نویسی را آغاز کرده‌ بود که فکر می‌کرد مستقیماً قابل استفاده توسط مردم است. امّا او چیزی درباره زبان‌های برنامه‌نویسی نمی‌دانست. و در آن موقع من چنین دانشی داشتم زیرا سیستم لیسپ را ساخته بودم و مطالعاتی درباره برخی زبان‌های برنامه‌نویسی کرده بودم.
به این خاطر ما با هم همکاری کردیم و زبانی که نهایتاً او ساخت، من هم در طراحیش مشارکت داشتم. نام این زبان TRAC بود. در آن مقطع او یک پشتیبان واقعی برای من بود.
نفر بعدی که من همیشه او را معلّم و راهنمای خودم دانسته‌ام دنی بابرو است. من و او مدت‌هاست که با هم دوست هستیم. و من همیشه از نظر حرفه‌ای خود را مدیون او می‌دانم. 
امّا در مورد این که چگونه برنامه‌نویسی کنم، فرد خاصی در ام آی تی نبود که جنبه راهنما برایم داشته‌ باشد. در برکلی هم همین طور. در مرکز پژوهشی زیراکس، تنها یکنفر بود که واقعاً بر شیوه نرم‌افزار نویسی من تأثیر‌گذار بود و جالب است بگویم که او حتی برنامه‌نویس هم نبود. او جری الکایند بود که برای مدتی مدیر آموزشگاه دانش رایانه در مرکز پژوهشی زیراکس بود.
چیزی که او به من گفت که تأثیر عمیقی بر من گذاشت این بود که اندازه‌گیری و مقیاس‌بندی هر چیز چقدر اهمیت دارد. این که هرگاه اعتقادات یا قوه شهودتان درست از آب درنیامد، چیزها را اندازه‌گیری کنید. حتی گاهی که فکر می‌کنید به اندازه‌گیری نیاز نداشته باشید هم اندازه‌گیری کنید. این تأثیر عمیقی بر من گذاشت.
هنگامی که می‌خواهم کاری را انجام دهم که مستلزم محاسبات بسیار زیاد یا حجم داده‌های بسیار زیاد باشد، یکی از کارهایی که همیشه می‌کنم، اندازه‌گیری و مقیاس‌بندی است. و این کار از زمانی که در مرکز پژوهشی زیراکس بودم، یعنی 35 سال پیش، تاکنون ادامه دارد.
سیبِل: در بین کسانی که برای نوشتن این کتاب من با آن‌ها تماس گرفته و مصاحبه کرده‌ام، شما تنها کسی بودید که واکنش منفی نسبت به واژه برنامه‌نویس (coder ) در عنوان کتاب داشتید. شما ترجیح می‌دهید خودتان را با چه واژه‌ای توصیف کنید؟
دویچ: من در این مقطع از زندگی که در آن قرار دارم حتی نسبت به واژه برنامه‌ساز (programmer ) نیز واکنش منفی دارم. اگر به فرایند تولید نرم‌افزار نگاه کنید، نقش‌های متفاوت و زیادی وجود دارد و به مهارت‌های زیادی نیاز هست تا نرم‌افزار تکمیل گردد. اگر یک نفر خود را برنامه‌نویس یا برنامه‌ساز بنامد، این واژه چیز زیادی درباره مجموعه مهارت‌هایی که او باید داشته باشد به شما نمی‌گوید.
امّا حداقل واژه «برنامه‌ساز» کمی جامع‌تر است. «برنامه‌نویس» یعنی کسی که کم اهمیت‌ترین بخش کار را انجام ‌می‌دهد. به نظر من نقش «برنامه‌نویس» در تولید نرم‌افزاری که واقعاً کار می‌کند و مفید است احتمالاً کمی بالاتر از نقش «عمله» در فرایند تولید ساختمان است.
سیبِل: چه واژه‌ای شما را بهتر توصیف می‌کند؟ تولید کننده نرم‌افزار یا دانشمند رایانه ؟
دویچ: من در مورد «دانش رایانه» نیز بحث دارم. من می‌توانم موارد متعددی را مثال بزنم که واژه «دانش» نباید در مورد رایانش به‌کار گرفته شود. به عقیده من تمام آن چیزی که «دانش رایانه» خوانده می‌شود، ترکیبی از مهندسی و ریاضیات کاربردی است و بخش کوچکی از آن، «دانش» است. در یک فرایند علمی (دانشی)، کاری که شما می‌کنید تولید توصیف‌های بهتر از پدیده‌های مشاهده شده است.
من فکر می‌کنم اگر بخواهم یک عبارت کوتاه را انتخاب کنم، احتمالاً می‌گویم «تولیدکننده نرم‌افزار». این لفظ تقریباً همه چیز را از معماری گرفته تا برنامه‌نویسی پوشش می‌دهد. البته هنوز هم برخی از چیزهای دیگری که برای تولید نرم‌افزار باید اتفاق بیفتد را پوشش نمی‌دهد، امّا بیشتر کارهایی که من انجام داده‌ام را  دربر می‌گیرد.
سیبِل: چه چیزی را پوشش نمی‌دهد؟
دویچ: فرایند درک دامنه مسأله و استخراج و درک نیازمندی‌ها را پوشش نمی‌دهد. چیز دیگری را که پوشش نمی‌دهد- حداقل تمام فرایند را پوشش نمی‌دهد- حلقه‌های بازخوردی از مرحله آزمایش تا اتفاقاتی که پس از عرضه نرم‌افزار می‌افتد است. واژه «تولید کننده نرم‌افزار» اساساً به دنیایی در درون مرزهای سازمان تولیدکننده نرم‌افزار اشاره می‌کند. و بیانگر چیز زیادی درباره ارتباطات بین سازمان و مشتریانش یا بقیه دنیا نیست و این ارتباطات، چیزی است که در اصل تولید نرم‌افزار را توجیه می‌کند.
سیبِل: آیا فکر می‌کنید فرایند تولید نرم‌افزار در حال تغییر است؟ این روزها خیلی‌ها طرفدار این هستند که باید هر چه زودتر با مشتری یا کاربر ارتباط برقرار کرد و به این بخش از کار تولیدکننده نرم‌افزار بهای زیادی می‌دهند.
دویچ: بله، روش XP چنین است. من به دو دلیل طرفدار جدّی XP نیستم. فکر می‌کنم XP به دو منظور طرفدار نزدیکی زیاد با مشتری در خلال فرایند تولید نرم‌افزار است. یکی این‌که نیازهای مشتری بهتر درک و برآورده می‌شود. این حرف ممکن است درست باشد امّا من کمی نسبت به آن شک دارم زیرا مشتری همیشه نمی‌داند نیازهای واقعی مشتری چیست.
دلیل دیگری که XP طرفدار این نزدیکی با مشتری است این است که از عمومیت بخشیدن زودرس و بی‌جهت طراحی جلوگیری شود. به نظر من این یک شمشیر دو لبه است. زیرا شاهد بوده‌ام که از هر دو سو به بیراهه رفته است: هم عمومیت بخشیدن زودرس و هم تخصصی کردن زودرس.
به این خاطر است که من در مورد XP پرسش‌های اساسی دارم. پس از این که پروژه تمام شد چه اتفاقی می‌افتد؟ آیا قابل نگهداری است؟ آیا قابل پشتیبانی است؟ آیا تکامل‌پذیر است؟ اگر تولیدکنندگان اصلی دیگر در دسترس نباشند چه اتفاقی می‌افتد؟ زیرا XP اعتقادی به مستندسازی ندارد.
این موضوعی است که بارها درباره‌اش با کسانی که طرفدار پیش‌نمون سازی سریع و یا هر گونه تولید نرم‌افزار بدون در نظر گرفتن یک نظام مهندسی بوده‌اند، به بحث نشسته‌ام. من به طور جدّی این پرسش برایم وجود دارد که نرم‌افزاری که از دیدگاه مهندسی ساخته نشده باشد چگونه دوام می‌آورد و باقی می‌ماند.
سیبِل: آیا می‌توانید مثالی از عمومیت بخشیدن یا تخصصی کردن بزنید که اشتباه بوده‌ است؟
دویچ: هنگامی که من در اوج دوران حرفه‌ایم بودم، یکی از کارهایی که خیلی خوب انجام می‌دادم، و ادّعا نمی‌کنم که آن را به شیوه سامانمندی انجام می‌دادم، این بود که سطح مناسبی از عمومیت را برای نرم‌افزار در نظر می‌گرفتم که نیازهای تکاملی تا چند سال آینده‌ را در مسیرهایی که کاملاً از قبل واضح نبودند، پوشش می‌داد.
امّا یک مثال از تخصصی کردن زودرس، تصمیمی بود که من در پروژه گوست اسکریپت، در سطح معماری، برای نمایش تصاویر رنگی با استفاده از نقاط تصویری به جای صفحه گرفتم. این تصمیم‌گیری باعث می‌شد که اگر شما چاپگرهایی داشتید که برای کارهای خاصی به رنگ‌هایی بجز جوهرهای استاندارد CMYK (سبزابی، سرخابی، زرد، سیاه- سه رنگ اصلی در رنگ‌های ثانویه، به علاوه رنگ سیاه که در فرایند چاپ رنگی به کار می‌رود. مترجم) نیاز داشتند، کار کردن با رنگ نقطه نوری بسیار دشوار می‌شد. مثلاً نقره‌ای یا طلایی.
اگر به تصاویر رنگی نقطه‌بندی شده نگاه کنید، کم‌و بیش دو شیوه برای نمایش آن‌ها در حافظه وجود دارد. یک روش این است که آن را به صورت آرایه‌ای از نقاط تصویری در حافظه نشان دهید که هر نقطه شامل داده‌های RGB (قرمز، سبز، آبی) یا CMYK برای نقطه نوری بر روی تصویر باشد. این نوعاً روشی است که کنترل‌کننده‌های نمایشگر کار می‌کنند.
روش دیگر که بیشتر در صنعت چاپ متداول است، داشتن آرایه‌ای است که شامل مقداری رنگ قرمز برای هر نقطه تصویری و یک آرایه دیگر شامل مقداری رنگ سبز برای هر نقطه تصویری و باز هم یک آرایه دیگر شامل مقداری رنگ آبی برای هر نقطه تصویری و ... است. اگر تصاویر را نقطه به نقطه پردازش کنید این روش راحتی نیست. از طرف دیگر از قبل مشخص نمی‌کند که چند جوهر مختلف یا چند صفحه مختلف برای تولید یک تصویر به کار گرفته می‌شود.
سیبِل: بنابراین اگر چاپگری داشتید که می‌توانست از جوهر طلایی استفاده کند، فقط کافی بود یک صفحه اضافه کنید.
دویچ: درست است. این امر مطمئناً در چاپگرهای معمولی یا حتی چاپگرهای اداری متداول نیست. امّا در چاپ افست (چاپ با استفاده از دستگاه چاپ مبتنی بر لیتوگرافی. مترجم) نسبتا‍‍ً متداول است که لایه‌های خاص داشته باشیم. این یک مورد از عمومیت بخشیدن ناکافی بود.
این مثالی بود از این که حتی با وجود مقداری زیادی فکر و مهارت، باز هم راه را گم کردم. البته شاید نتوانستم منظورم را خوب بیان کنم. در این مورد، حتی آینده‌نگری دقیق نیز به عمومیت بخشیدن ناکافی می‌انجامید. و من الان به شما می‌گویم که علتش چه بود. علتش این بود که گوست اسکریپت توسط آدم خیلی باهوشی نوشته‌ شد که آشنایی کافی با صنعت چاپ نداشت.
سیبِل: یعنی خود شما؟
دویچ:‌ درست است. گوست اسکریپت در اساس برای پیش‌نمایش پرونده‌های پست اسکریپت نوشته شد زیرا در آن موقع چنین چیزی وجود نداشت و PDF هم هنوز به وجود نیامده بود. اگر بخواهم از این داستان، نتیجه‌گیری اخلاقی کنم این است که نیازها دائم تغییر می‌کنند و همیشه سعی می‌کنند در جهتی که شما قبلاً فکرش را نکرده بودید تغییر کنند.
دو مکتب فکری متفاوت در مورد این‌که چگونه خودتان را برای رویارویی با این واقعیت آماده کنید وجود دارد. یک مکتب فکری که خیلی نزدیک به نظر طرفداران XP است می‌گوید از آنجا که نیازها همیشه تغییر می‌کنند، نباید انتظار ماندگاری نرم‌افزار را داشته باشید. هرگاه نیازها تغییر کردند،‌ شما هم یک چیز جدید می‌سازید. من فکر می‌کنم تا حدّی هوشمندی در این نظریه وجود دارد.
ضرب‌المثلی در مورد نرم‌افزار وجود دارد که می‌گوید «سریع،‌ ارزان، خوب: دوتایش را انتخاب کن.» اگر نرم‌افزاری را سریع تولید کنید و آن را ارزان تمام کنید، احتمال خیلی کمی دارد که محصول خوبی باشد. این مکتب فکری می‌گوید نباید انتظار داشته باشید که نرم‌افزار ماندگار باشد.
من فکر می‌کنم در پشت این نظریه‌ها، دیدگاه مهمتری قرار دارد. و آن این است که نرم‌افزار را هزینه بدانیم یا دارایی و سرمایه. من کاملا‍ً طرفدار مکتبی که نرم‌افزار را سرمایه تلقّی می‌کند هستم. هنگامی که در مرکز پژوهشی زیراکس کار می‌کردم و آدل گلدبرگ هم آنجا بود و با هم برای طراحی شیء‌گرا تبلیغ می‌کردیم، یکی از شیوه‌هایی که ما درباره اشیاء صحبت می‌کردیم و یکی از شیوه‌هایی که تبلیغ طراحی و زبان‌های شیءگرا را به مشتریانمان می‌کردیم این بود که به آن‌ها می‌گفتیم «ببین، شما باید نرم‌افزار را به عنوان یک سرمایه درنظر بگیرید.» و چیزی دارایی یا سرمایه تلقی نمی‌شود مگر این که به نگهداری و سرمایه‌گذاری مداوم نیاز داشته‌ باشد.
شما باید انتظار داشته باشید که نگهداری یک کتابخانه رشد یابنده از نرم‌افزارهای قابل باز به کارگیری ، هزینه‌بر است. و این محاسبات شما را پیچیده می‌سازد زیرا بدین معنی است که نمی‌توانید هزینه تولید آن تکه نرم‌افزار را فقط روی آن پروژه درنظر بگیرید. شما باید در مورد آن همان‌طور فکر کنید که به یک دارایی سرمایه‌ای فکر می‌کنید.
سیبِل: مثل ساختن یک کارخانه جدید.
دویچ: درست است. ما همیشه می‌گفتیم اشیایی که خوب طراحی شده باشند قابل باز به کارگیری خواهند بود و بنابراین، سرمایه‌گذاری صورت گرفته برای تولید آن‌ها، در پروژه‌های بعدی جبران خواهد شد.
من هنوز هم به این مسأله اعتقاد دارم، امّا شاید نه به جدیت سابق. چیزهایی که این روزها باز به کارگیری می‌شوند یا خیلی کوچکند یا خیلی بزرگ. هنگامی که ما درباره شیءگرایی تبلیغ می‌کردیم، مقیاس باز به‌کارگیری که درباره‌اش صحبت می‌کردیم، رده‌ها و گروه‌های رده‌ها بود.
امّا چیزی که این روزها باز به‌کارگیری می‌شود یا چیزهای خیلی کوچکند مثل یک شمایل و نماد تصویری یا طراحی یک صفحه وب، و یا چیزهای خیلی بزرگ مثل کلّ زبان یا یک برنامه کاربردی بزرگ مثل آپاچی یا موزیلا.
سیبِل: پس شما مثل سابق به درجه باز به‌کارگیری اشیاء اعتقادی ندارید. آیا نظریه‌اش اشکال داشت یا به دلایل تاریخی  چنین شده‌ است؟
دویچ: خوب، یکی از دلایلی که من خودم را دیگر دانشمند رایانه نمی‌نامم این است که وقتی به تجربه تولید نرم‌افزار در 50 سال گذشته نگاه می‌کنم می‌بینم که پیشرفت چشمگیری در 30 سال گذشته نداشته است.
اگر شما به زبان‌های برنامه‌نویسی نگاه کنید من با قاطعیت می‌توانم بگویم که زبان‌های برنامه‌نویسی در 40 سال گذشته از لحاظ کیفی بهبود نیافته‌اند. هیچ زبان برنامه‌نویسی امروزی نیست که از نظر کیفی بهتر از سیمولا 67 باشد.
من می‌دانم که این حرفم ممکن است مسخره به نظر آید امّا واقعاً  به آن اعتقاد دارم. جاوا خیلی بهتر از سیمولا 67 نیست.
سیبِل: اسمال تاک؟
دویچ: اسمال تاک از برخی جنبه‌ها از سیمولا 67 هم بهتر است. امّا اسمال تاکی که امروز وجود دارد همان اسمال تاکی است که در 1976 وجود داشت. من نمی‌گویم زبان‌های امروزی بهتر از زبان‌هایی که 30 سال پیش وجود داشتند نیستند. زبانی که امروزه بیشترین برنامه‌نویسی‌هایم را با آن انجام می‌دهم، یعنی پایتون، خیلی بهتر از هر زبانی است که 30 سال پیش وجود داشت. من حتی آن را بیشتر از اسمال تاک دوست دارم.
من عملاً از واژه «کیفی» استفاده کردم. هر زبان برنامه‌نویسی که امروزه می‌توانم فکرش را بکنم و مورد استفاده وسیع است، دارای مفهوم اشاره‌گر می‌باشد. من هیچ روشی را برای تولید نرم‌افزار نمی‌شناسم که استفاده کیفی بهتری از این مفهوم بنیادی کرده باشد.
سیبِل: شما ارجاعات به‌کار رفته در پایتون و جاوا را اشاره‌گر محسوب می‌کنید؟
دویچ: قطعاً همین‌طور است. برنامه‌های نوشته شده به پایتون و جاوا، به محض آن‌که از یک اندازه و مقیاس کوچک بگذرید، همگی مشکلات مشابهی دارند. اصل و ماهیت مشکل این است که هیچ ساز و کار زبان‌شناختی برای درک یا بیان یا کنترل یا استدلال درباره الگوهای اشتراک اطلاعات و دستیابی به اطلاعات در سیستم وجود ندارد. رد کردن یک اشاره‌گر و ذخیره کردن یک اشاره‌گر، عملیات محلّی هستند امّا پیامدهای آن‌ها این است که این گراف به‌طور ضمنی ایجاد می‌شود.
من در مورد کاربردهای چند ریسه‌ای صحبت نمی‌کنم. حتی در کاربردهای تک ریسه‌ای شما داده‌هایی دارید که بین بخش‌های مختلف برنامه جریان دارند. ارجاعاتی دارید که در بخش‌های مختلف برنامه پخش شده‌اند. و حتی در برنامه‌هایی که طراحی خیلی خوبی دارند، دو یا سه یا چهار تا از این الگوهای پیچیده وجود دارد. من فکر نمی‌کنم هیچ نوع راه حلی که مورد پذیرش و یا مورد استفاده گسترده قرار گرفته باشد،‌ به وجود آمده باشد.
سیبِل: نظرتان درباره زبان‌های تابعی چیست؟
دویچ: زبان‌های تابعی محض نیز مشکلات خاص خودشان را دارند امّا این مسأله پیچیده را حل کرده‌اند. من هر از گاهی وسوسه می‌شوم که یک زبان برنامه‌نویسی طراحی کنم امّا بعد از آن مدتی خودم را کنترل می‌کنم تا آن وسوسه از بین برود. امّا اگر روزی سرانجام بخواهم این کار را انجام دهم، یک تمایز بنیادی قائل خواهم شد بین بخش تابعی که فقط درباره مقادیر صحبت کند و مفهوم اشاره‌گر نداشته باشد و یک بخش متفاوت دیگر که درباره الگوهای اشتراک اطلاعات و ارجاعات و کنترل صحبت کند.
شاید مهمترین دلیلی که تا کنون این کار را نکرده‌ام این است که فکر نمی‌کنم بینش کافی برای درک چگونگی توصیف الگوهای اشتراک و الگوهای ارتباطات در سطح بالا را داشته باشم. و فکر می‌کنم دلیل این که تولید نرم‌افزار در حال حاضر خیلی از بهتر 30 سال پیش نشده‌ است همین باشد.
تز دکتری من درباره «اثبات صحّت» برنامه‌ها بود. من دیگر از این اصطلاح استفاده نمی‌کنم. چیزی که می‌گویم این است که شما می‌خواهید سیستمی که تولید کرده‌اید هر چه بیشتر کار کند و کارش در جهتی باشد که به شما اطمینان دهد که برنامه آنچه مورد نظر شما بوده را انجام می‌دهد. نظر قدیمی درباره صحّت برنامه این بود که جملات اظهاری که بیان کننده کاری بودند که ما می‌خواستیم کد انجام دهد در مکان‌هایی از برنامه قرار داده می‌شدند و هرگاه اجرای برنامه به آن نقاط می‌رسید درستی عبارتی که در جمله اظهاری آورده شده بود به طور خودکار بررسی می‌شد. این رویکرد مشکلات زیادی داشت. من اکنون فکر می‌کنم مسیر بررسی این که نرم‌افزار کار مورد نظر را انجام می‌دهد یا نه، از جملات اظهاری نمی‌گذرد بلکه به نشانه‌گذاری‌های اعلانی بهتر، قویتر و عمیقتری نیاز دارد. روش‌های قدرتمندتری برای اعلان این که برنامه قرار است چه کاری انجام دهد.
سیبِل: آیا تجربه‌ای در این زمینه شده است؟
دویچ: بله، هنگامی که در اوایل دهه 90 در شرکت سان بودم، برخی کارهای تجربی بر روی یک زبان انجام می‌شد. و در ام آی تی نیز پژوهش‌های متعددی توسط دیوید گیفورد بر روی زبانی به نام FX انجام شده که سعی کرده است تمایز صریحی بین بخش‌های تابعی و غیرتابعی یک محاسبه قائل شود.
امّا من فکر می‌کنم همه این تلاش‌ها از یک سطح نسبتاً پایین به موضوع نگاه می‌کنند. اگر واقعاً می‌خواهیم به پیشرفت مهمی نائل شویم که دیگر تولید نرم‌افزارهای فاجعه‌باری چون ویندوز ویستا غیرممکن یا غیرلازم گردد،‌ به شیوه‌های تازه‌ای از تفکّر در باره این که برنامه ها چه هستند و چگونه آن‌ها را در کنار هم قرار دهیم،‌ نیاز داریم.
سیبِل: شما گفتید که علیرغم این‌که زبان پایتون از لحاظ کیفی بهتر از اسمال تاک نیست امّا هنوز آن را ترجیح می‌دهید.
دویچ: همین‌طور است. برای آن چند دلیل دارم. در پایتون خیلی روشن است که یک برنامه چیست و اجرای برنامه چه معنی می‌دهد و بخشی از یک برنامه بودن چه معنی می‌دهد. مفهوم پودمان وجود دارد و پودمان‌ها اطلاعاتی که از سایر پودمان‌ها نیاز دارند را اعلان می‌کنند. بنابراین، ‌می‌توان پودمان یاگروهی از پودمان‌ها را تولید کرد و آن‌ها را با دیگران به اشتراک گذاشت و دیگران می‌توانند به پودمان‌ها نگاه کنند و دقیقاً بفهمد که آن‌ها به چه چیزی وابسته هستند و حدّ و مرزشان چیست.
در اسمال تاک انجام این کار دشوار است. اگر شما درحالت تصویری اسمال تاک برنامه بنویسید، برنامه به عنوان یک موجودیت به خودی خود، وجود ندارد. سه یا چهار مفهوم متفاوت برای این‌که چیزها را بزرگتر از یک رده واحد کنیم وجود دارد و آن‌ها در طول زمان تغییر یافته‌اند وتوسط ابزارهای تولید به خوبی پشتیبانی نمی‌شوند، حداقل به صورت تصویری.  ابزارهای کمی برای روشن کردن این‌که چه چیزی به چه چیز بستگی دارد،‌ وجود دارد. بنابراین، اگر در حالت تصویری برنامه بنویسید، هیچ چیز را نمی‌توانید با هیچکس دیگر به اشتراک بگذارید، مگر کل تصویر را. برای پروژه‌های تک نفره که هرگز از دست یکنفر خارج نمی‌شود عالی است. امّا اگر بخواهید نرم‌افزار یک دارایی سرمایه‌ای شود،‌ یعنی اگر بخواهید نرم‌افزار را با دیگران به اشتراک گذارید، بسیار بد است. من فکر می‌کنم این ضعف جدّی رویکرد تولید نرم‌افزار در اسمال تاک است.
دلیل دومی که پایتون را دوست دارم این است که با بالا رفتن سنّم دیگر نمی‌توانم مثل سابق چیزهای زیادی را در مغزم نگاه دارم و برایم مهم است که آن‌ها را جلوی چشمم داشته‌ باشم. امّا در اسمال تاک شما به طور مؤثر نمی‌توانید بیش از یک روش را در هر لحظه روی صفحه نمایش داشته باشید و این مرا کلافه می‌کند.
البته اسمال تاک هم مزایای فوق‌العاده‌ای دارد. قابلیت اطمینان بالایی دارد، نسبتاً ساده است،‌ و مولّد کد بسیار کارآمدی دارد. چه خوب می‌شد اگر ویژگی‌های این دو زبان را یکجا داشتیم.
سیبِل: همین ایده‌ در پشت پروژه پیکور نبود؟ پیاده‌سازی مجدّد پایتون در اسمال تاک؟
دویچ: چرا بود. امّا من به نقطه‌ای رسیدم که دریافتم انجام آن بسیار بیشتر از آنچه فکر می‌کردم کار می‌برد. عدم انطباق بین مدل شیء پایتون و مدل شیء اسمال تاک آنقدر زیاد بود که خیلی چیزها را نمی شد یک به یک به هم نگاشت و باید این کار را از طریق سطوح اضافی فراخوانی روش‌ها انجام می‌دادیم. با وجود این، آنقدر کارآیی مولّد کد اسمال تاک بالاست که من فکر می‌کردم اگر می‌شد آن را متن باز کرد، وفق دادن آن با مدل شیء پایتون و نمایش داده‌های پایتون، کار خیلی شاقّی نبود.
امّا این کار انجام نشد و شرکت سینکام با اعلام این که «این یک دارایی سرمایه‌ای راهبردی برای ما محسوب می‌شود و نمی‌توانیم متن بازش کنیم»، با آن مخالفت کرد.
سیبِل: خوب، خود شما هم که معتقدید نرم‌افزار باید به عنوان یک دارایی سرمایه‌ای محسوب شود.
دویچ: امّا این لزوماً به این معنی نیست که همیشه بهترین راهبرد شما این است که دیگران را از استفاده از آن بازدارید.
سیبِل: شما علاوه بر این که از قدیم با زبان اسمال تاک کار می‌کردید، از نخستین کسانی بودید که به زبان لیسپ روی آوردید. امّا دیگر از این زبان استفاده نمی‌کنید.
دویچ: تز دکتری من، یک برنامه 600 صفحه‌ای لیسپ بود. من یک برنامه‌نویس حرفه‌ای لیسپ هستم و با لیسپ پی دی پی1، لیسپ آلتو، لیسپ بایت و اینترلیسپ کار کرده‌ام. دلیلی که دیگر به لیسپ برنامه‌نویسی نمی‌کنم این است که دیگر تحمّل قواعد نحوی آن را ندارم. این یک واقعیت است که قواعد نحوی اهمیت زیادی دارند.
هر سیستم زبان برنامه‌نویسی بر سه پایه استوار است. یکی خود زبان، دیگری کتابخانه‌هایش و سومی ابزارهایش. و این که یک زبان چقدر موفق است بستگی دارد به تعامل پیچیده بین این سه چیز. مثلاً پایتون، زبانی عالی است و کتابخانه‌ای عالی دارد امّا ابزارهای چندانی ندارد.
سیبِل: «ابزارها» شامل پیاده‌سازی واقعی زبان هم می‌شوند؟
دویچ: البته. مثلاً در مورد لیسپ که شما سئوال کردید، لیسپ به عنوان یک زبان، ویژگی‌های انعطاف‌پذیری فوق‌العاده‌ای دارد امّا از نظر خوانایی بسیار ضعیف است. من نمی‌دانم این روزها وضعیت کتابخانه Common Lisp چگونه است امّا فکر می‌کنم قواعد نحوی خیلی اهمیت دارد.
سیبِل: بعضی‌ها عاشق قواعد نحوی لیسپ هستند و بعضی‌ها تحمّل آن را ندارند. چرا این چنین است؟
دویچ: خوب، من نمی‌توانم از جانب کس دیگری صحبت کنم. امّا می‌توانم به شما بگویم که چرا خودم دیگر نمی‌خواهم با قواعد نحوی لیسپ کار کنم. دو دلیل دارد. دلیل اوّل که قبلاً هم ذکر کردم این است که هر چه پیرتر می‌شوم، مقدار اطلاعاتی که در هر اینچ مربع باید در جلوی چشمم قرار گیرد اهمیت بیشتری پیدا می‌کند. تراکم اطلاعات در هر اینچ مربع در زبان‌های میانوندی بیشتر از لیسپ است.
سیبِل: امّا تقریباً تمام زبان‌ها پیشوندی هستند، بجز برای چند عملگر محاسباتی انگشت شمار.
دویچ: این حرف درست نیست. برای مثال در پایتون این حرف در مورد ساخت لیست، چندتایی و فهرست راهنما صدق نمی‌کند. این‌ها با پرانتزگذاری انجام شده است. قالب‌بندی رشته به صورت میانوندی انجام شده‌است.
سیبِل: چه اتفاقی باعث شد که از برنامه‌نویسی به آهنگسازی روی آورید؟
دویچ: پروژه گوست اسکریپت مرا از پا درآورد. گوست اسکریپت یکی از علائق فنی من بود که از سال 1986 شروع شده بود و تقریباً تنها پروژه فنی عمده‌ای بود که من در حوالی سال‌های 93-1992 شروع کردم. تقریباً در سال 1998 بود که من کم‌کم حس کردم از رمق افتاده‌ام زیرا نه تنها تمام کارهای فنی آن را من انجام می‌دادم بلکه تمام کارهای پشتیبانی و اداری نیز برعهده من بود. یک کسب و کار کاملاً یکنفره که از عهده یک نفر بر نمی‌آید. من یک نفر را استخدام کردم که کسب و کار را سازمان دهد و او هم شروع به استخدام چند مهندس کرد.
سپس دو سال طول کشید تا فرد مناسبی را برای جایگزینی من پیدا کند. و پس از آن تقریباً دو سال دیگر طول کشید تا همه تغییر و تحولات انجام شود. در سال 2002 کار من تمام شد. من دیگر نمی‌خواستم حتی یکبار دیگر گوست اسکریپت را ببینم.
بعد من گفتم «خوب، من6 ماه به خودم استراحت می‌دهم و بررسی می‌کنم که چه کاری را می‌خواهم بعد از این انجام دهم.» در آن موقع من 55 ساله بودم و خیلی احساس پیری نمی‌کردم. به این نتیجه رسیدم که در باقیمانده عمرم یک پروژه بزرگ دیگر را می‌توانم انجام دهم. پس شروع به بررسی و جستجو کردم.
یک پروژه‌ای که تا حدودی برایم جالب بود به روزهایی که در زیراکس بودم بازمی‌گشت. استراترمور رئیس دانشکده دانش رایانه (علوم کامپیوتر) در دانشگاه تگزاس در آوستین بود. دستاورد مهم حرفه‌ای او این بود که به همراه فردی از مرکز پژوهشی استنفورد به نام باب بویر یک اثبات کننده قضایا ساخته بودند. و او گروهی را پیرامون این نرم‌افزار گردآورده بود و کتابخانه بزرگی از قضایا و لم‌ها درباره برخی حوزه‌های خاص فراهم کرده بود.
تز دکتری من هم درباره همین موضوع بود و من همیشه به آن علاقه‌مند بودم. پس فکر کردم «این یک گروه پژوهشی مناسب است. آن‌ها سرگرم کاری هستند که من همیشه به آن علاقه داشته‌ام. سرپرست گروه هم کسی است که او را می‌شناسم و دوستش دارم. فناوری آن‌ها هم بر پایه لیسپ است. پس برای من بسیار مناسب می‌باشد.»
پس به آنجا رفتم و برای آن‌ها درباره امکان استفاده از اثبات قضایا برای بهبود قابلیت اطمینان گوست اسکریپت سخنرانی کردم. در آن زمان ما سابقه مفصّلی از ردگیری خطاها در گوست اسکریپت داشتیم. من به طور تصادفی 20 خطا را انتخاب کردم و به هر یک نگاه کردم و گفتم «برای این‌که فناوری اثبات قضایا بتواند در یافتن یا جلوگیری از بروز این خطا کمک کند،‌ چه اتفاقی باید بیفتد؟»
نتیجه‌گیری من این بود که فناوری اثبات قضایا احتمالاً نمی‌تواند کمک زیادی بکند زیرا در چند جایی که می‌توانست کمک‌رسان باشد، صوری کردن کاری که نرم‌افزار قرار بود انجام دهد، کار فوق‌العاده پیچیده و شاقّی بود. به این دلیل است که فناوری اثبات قضایا،‌ به عقیده من، اساساً به عنوان یک فناوری عملی نمی‌تواند کمکی به بهبود قابلیت اطمینان نرم‌افزار کند. صوری کردن خصوصیاتی که می‌خواهید برقرار سازید،‌ فوق‌العاده دشوار است.
سخنرانی من با استقبال خوبی روبرو شد. من با چند نفر از دانشجویان تحصیلات تکمیلی صحبت کردم و کمی هم با خود استراتر مور حرف زدم و سپس از آنجا خارج شدم. با خودم فکر کردم «همه فرضیاتی که درباره آنجا کرده‌ بودم درست بود، امّا من علاقه چندانی به این موضوع ندارم.»
من سال‌ها بود که در یک گروه کر آواز می‌‌خواندم. در تابستان سال 2003 ما در یک تور شرکت کردیم و در کلیساهای قدیمی ایتالیا شش کنسرت دادیم. دوستم با من در این سفر همراه بود و ما تصمیم گرفتیم که دو سه هفته بعد از آن نیز در اروپا بمانیم.
ما به وین رفتیم و در آنجا به تماشای قصر هاپسبورگ که حالا به 10 موزه تخصصی جداگانه تقسیم شده‌ بود رفتیم. من در کتابچه راهنمایش دیدم که یکی از موزه‌ها، موزه سازها و آلات قدیمی موسیقی است. من به این موزه رفتم که در یک سرسرای طولانی با سقف بسیار بلند قرار داشت. و از سازهای خیلی قدیمی شروع می‌شد و همین‌طور به جلو می‌آمد. البته اغلب آلات موسیقی که به نمایش درآمده بود متعلّق به چند قرن اخیر اروپای غربی بود. از جمله چیزهایی که در آن موزه نظر مرا به خود خیلی جلب کرد یکی پیانوی متعلق به لئوپولد موتزارت (پدر و معلّم ولفگانگ آمادئوس موتزارت) بود، دیگری پیانوی تمرینی برامس و بالاخره پیانویی که هایدن در خانه‌اش داشت.
در آنجا بود که به این فکر فرورفتم که شاید دلیل این که پروژه نرم‌افزاری دیگری که مورد علاقه‌ام باشد را پیدا نمی‌کنم، کمبود پروژه نیست بلکه این است که به خود نرم‌افزار دیگر علاقه‌ای ندارم. اکنون ممکن است به نظرتان عاقلانه نیاید امّا بیشترین انگیزه‌ای که در وهله اول برای ورود به حوزه تولید نرم‌افزار داشتم این بود که فکر می‌کردم می‌توانم با این کار، دنیای بهتری بسازم. امّا دیگر چنین اعتقادی نداشتم. حداقل نه به آن صورت.
این جرقّه زده شد و ناگهان احساس کردم که شیوه‌ای که- نمی‌خواهم بگویم دنیای بهتری بسازم- بلکه مشارکت ماندگارتر و پایدارتری در جهان داشته باشم،‌ روی آوردن به موسیقی است. این لحظه ای بود که تصمیم گرفتم یک نفس عمیق بکشم و از راهی که 50 سال می‌پیمودم، خارج شوم.
سیبِل: امّا شما هنوز هم برنامه‌نویسی می‌کنید.
دویچ: من نمی‌توانم جلوی خودم را از انجام کاری که برایم جالب و سرگرم کننده‌ است بگیرم. من ظرف چند سال گذشته، تعداد زیادی پروژه‌های نرم‌افزاری کوچک انجام داده‌ام امّا فقط به دو تا از آن‌ها توجه بیشتری کرده‌ام.
یکی فناوری فیلتر کردن هرزنامه‌ها برای کارساز پست الکترونیکی‌ام بوده است. خیلی سرگرم کننده نبود امّا برایم جالب بود. فیلتری که من نوشتم، براساس بررسی واقعه نگاشت ، جلوی 80 تا 95 درصد هرزنامه وارده را می‌گرفت.
نرم‌افزار مهم دیگری که نوشتم و مرتب از آن استفاده می‌کنم، ویرایشگر تنظیم موسیقی است. و دلیلی که آن را نوشتم این بود که مطالعات و بررسی‌های زیادی در مورد نرم افزارهای موجود در این زمینه کرده بودم. من از نرم‌افزار Finale چند بار در خانه دوستم استفاده کرده بودم. امّا کیفیتش آنقدر بد بود که نگفتنی است. همچنین یک نسخه از نرم‌افزار Sibelius را تهیه کردم و برای آن که بتوانم آن را اجرا کنم یک رایانه شخصی Mac خریدم. امّا از رابط کاربری آن اصلاً خوشم نیامد و بدین ترتیب بود که تصمیم گرفتم خودم چنین نرم‌افزاری بنویسم.
من چهار معماری مختلف را امتحان کردم و سرانجام یکی از آن‌ها را که خیلی پسندیدم، انتخاب کردم. تجربه آموزنده و جالبی برایم بود. نرم‌افزار من یک نرم‌افزار کاربردی است که آنقدر بزرگ و پیچیده هست که جنبه‌های رابط‌کاربر آن اهمیت داشته باشد.
معماری انتخابی من بر پایه برنامه‌نویسی معادله‌ای بود. شما مقادیر متغیر برحسب معادلات تعریف می‌کردید و به برنامه اجازه می‌دادید که تصمیم بگیرد چه موقع آن‌ها را محاسبه کند. پیاده‌سازی آن در پایتون خیلی دشوار نبود. بنابراین، در پاسخ شما باید بگویم بله،‌ هنوز مقداری برنامه‌نویسی می‌کنم و هنوز برایم سرگرم کننده است. امّا دیگر این کار من برای کسان دیگری نیست و اگر چند هفته هم برنامه‌نویسی نکنم،‌ اتفاقی نمی‌افتد. هنگامی که کار حرفه‌ای می‌کردم همواره می‌خواستم در وسط یک پروژه قرار داشته باشم. امّا اکنون اگر بخواهم وسط چیزی قرار داشته باشم،‌ آن چیز، آهنگسازی است.
سیبِل: شما گفتید که فکر می‌کردید می‌توانید با نرم‌افزار،‌ دنیای بهتری بسازید. چگونه فکر می‌کردید که این اتفاق خواهد افتاد؟
دویچ: بخشی از آن ارتباطی به خود نرم‌افزار نداشت. به این خاطر بود که هر چیز که دور و برم بود و به نحو بدی انجام می‌شد، همیشه آزارم می‌داد و فکر می‌کردم می‌توانست بهتر از این باشد. بچه‌ها هم به همین شیوه فکر می‌کنند. اکنون همه این‌ها برایم مثل یک رویاست.
مطمئناً در زمانی که من برنامه‌نویسی را شروع کردم و حتی تا اوایل دهه 1980، فناوری رایانه وابسته به دنیای شرکت‌های بزرگ بود. و این درست برعکس روحیه و سیاست من بود. نوع رایانشی که من همیشه بدان پرداخته‌ام و کار کرده‌ام آن چیزی است که امروز آن را رایانش شخصی می‌نامیم. من فکر می‌کنم بخشی از انگیزه‌ام این بود که فکر می‌‌کردم اگر بتوان توانائی‌های رایانه را در اختیار افراد زیادی از جامعه قرار داد،‌ این خود نوعی مقابله با شرکت‌های بزرگ است.
من هیچگاه حتی در خواب هم تکامل اینترنت را پیش‌بینی نمی‌کردم. و هرگز پیش‌بینی نمی‌کردم که تا چه اندازه نفوذ شرکت‌های بزرگ بر روی اینترنت بتواند در طول زمان ماهیت آن را تغییر دهد. من فکر می‌کردم که اینترنت ذاتاً غیرقابل کنترل است و اکنون دیگر چنین اعتقادی ندارم. چین نشان داد که چگونه به طور مؤثری می‌توان این کار را انجام داد.
و فکر می‌کنم احتمال زیادی وجود دارد که اگر مایکروسافت نقشش را درست بازی کند به زودی بر روی اینترنت قفل بزند! مطمئنم که خیلی این کار را دوست دارند و فکر می‌کنم آنقدر باهوش هستند که می‌توانند مسیر از نقطه‌ای که اکنون در آن قرار دارند تا  نقطه کنترل مؤثر تمام نرم‌افزارهایی که بر روی اینترنت مورد استفاده قرار می‌گیرند را تبیین کنند.
بنابراین، همان‌طور که می‌بینید خوش‌بینی زیادی نسبت به آینده رایانش ندارم. اگر بخواهم صادقانه بگویم، یکی از دلایلی که رها کردن حوزه تولید نرم‌‌افزار برایم دشوار نبود،‌ همین بود. به عبارت دیگر،‌ دنیایی را دیدم که کاملاً تحت سلطه انحصارگران بی‌اخلاق بود و در چنین دنیایی، جایی برای خودم نمی‌دیدم.
 «ادامه دارد...» 

منبع:
* "Coders at Work", Peter Seibel, Apress, 2009