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

پیدایش مهندسی نرم‌افزار
شعار عمومیّت دایکسترا
 (بخش چهارم)

نوشتۀ ادگار دِی لایت
ترجمۀ: ابراهیم نقیب‌زادۀ مشایخ
پست الکترونیکی: mashayekh@isi.org.ir


 

پیش‌گفتار مترجم
در مجلۀ CACM مربوط به ژانویۀ 2015، مقاله‌ای توجهم را جلب کرد با عنوان «اشک‌های دونالد کنوث». این مقاله که توسط توماس هِی نوشته شده بود، درواقع انتقادی بود به مطالبی که کنوث در سخنرانی خود در دانشگاه استنفورد بیان کرده بود. در آن سخنرانی، کنوث به شدّت به مقالۀ مارتین کمپبل- کلی با عنوان «تاریخِ تاریخ نرم‌افزار» تاخته بود و از این که او در مقاله‌اش سطح تاریخ رایانش و علوم کامپیوتر را این قدر پایین آورده به شدّت انتقاد کرده بود. کنوث در پایان سخنرانیش گفته بود که آنقدر از خواندن آن مقاله ناراحت و غمگین شده بود که شیشه‌های عینکش از اشک‌های چشمش لک شده بود و او به سختی توانسته خواندن مقاله را به پایان برد.
توماس هِی در مقاله‌اش ضمن تمجید از کنوث و دستاوردهای بی‌مانندش در حوزۀ رایانش، از این که کتاب‌های کمی دربارۀ تاریخ علوم کامپیوتر نوشته شده با او همداستانی کرده امّا این کوتاهی را بیشتر متوجه خود دانشمندان این رشته دانسته است. او گفته: «امروز شما می‌توانید در دانشکده‌های ریاضی و پزشکی، حقوق و چند رشتۀ دیگر مدرک دکتری بگیرید و موضوع رساله‌تان، تاریخچۀ آن رشته باشد. امّا چنین امکانی در دانشکده‌های علوم کامپیوتر وجود ندارد. من دانشکدۀ علوم کامپیوتری را در آمریکا نمی‌شناسم که کسی را که موضوع رسالۀ دکتریش، جنبه‌های تاریخی علوم کامپیوتر بوده، استخدام کرده باشد. همچنین کسی را در آمریکا نمی‌شناسم که به خاطر کارهایش در زمینۀ تاریخ علوم کامپیوتر در یک دانشکدۀ علوم کامپیوتر تشویق شده یا ارتقاء یافته باشد.»
مقالۀ 5 صفحه‌ای توماس هِی بسیار خواندنی است و علاقه‌مندان به این موضوع را به خواندن متن کامل آن توصیه می‌کنم. او دارای درجۀ کارشناسی علوم کامپیوتر از دانشگاه منچستر (1995) و دکتری تاریخ و جامعه‌شناسی علم از دانشگاه پنسیلوانیا (2003) است. امّا غرض از آوردن این مقدمه این بود که در مقالۀ مزبور به چند کار ارزشمند نیز که در این زمینه انجام شده اشاره گشته که از آن جمله، کتاب «پیدایش مهندسی نرم‌افزار: از تورینگ تا دایکسترا» نوشتۀ ادگار دِی لایت است. عنوان این کتاب برای من که نزدیک 30 سال است درس مهندسی نرم‌افزار را در دانشگاه تدریس می‌کنم، جالب بود. جستجویی در اینترنت کردم و دیدم که افراد سرشناسی چون گریدی بوچ و جان رینولدز نقدهای بسیار خوبی دربارۀ این کتاب نوشته‌اند. نویسندۀ کتاب، ادگار دِی‌لایت نیز خود دارای درجۀ کارشناسی ارشد منطق از دانشگاه آمستردام (2009) و دکتری مهندسی نرم‌افزار از دانشگاه لوون بلژیک (2006) و در حال حاضر پژوهشگر تاریخ رایانش در دورۀ پسادکتری در دانشگاه فناوری آیندهوون هلند است. کتاب را توسط دوستی در کانادا از کتاب‌فروشی آمازون خریداری کردم و ظرف یکی دو هفته توسط مسافری به دستم رسید. خودم از خواندن آن لذت بردم و آن را به دو تن از همکارانم در دانشکدۀ علوم کامپیوتر دانشگاه تهران نیز نشان دادم و آن‌ها هم مطالب مطرح شده در کتاب را برای پژوهشگران و متخصصان علوم کامپیوتر و به ویژه دانشجویان این رشته بسیار مفید دانستند. از این رو به ترجمۀ کتاب اقدام کردم که به صورت یک سلسله مقالۀ دنباله‌دار در این نشریه به نظرتان خواهد رسید.
*                      *                      *

(ادامه فصل سوم کتاب)
3-1-3 رویّۀ بازگشتی وارد الگول 60 می‌شود
به‌عنوان بخشی از کار الگول60، زیرکمیته‌ای (شامل روتیس‌هاوزر، اِرلینگ، وودگِر و پاول) در نوامبر 1959 توصیه کرد محدودیت‌های خاصی در ارتباط با پارامترهای یک رویّه وضع شود و بدین ترتیب، به‌طور خودکار از فعّال‌سازی بازگشتی از طریق پارامتر جلوگیری می‌شد. به گفتۀ پرلیس، بازگشت به‌طور کلّی صریحاً ممنوع نشده بود[238]. امّا به گفتۀ نور چنین شده بود:

«باید همچنین اشاره کنیم که این مفهوم رویّه در زبان قدیمی، برای هر بدنۀ رویّه، محدودۀ کاملاً بسته‌ای از نام‌ها را معرفی می‌کرد. هیچ ارتباطی با دنیای خارج وجود نداشت بجز از طریق پارامترها. بدین ترتیب، فعّال‌سازی بازگشتی توسط خود زبان کنار گذاشته شده بود.»[212]

در آگوست 1959، مک‌کارتی نامه‌ای نوشت که در آن، براساس تجربیاتی که با زبان برنامه‌نویسی خودش، یعنی لیسپ، به دست آورده بود، به‌طور آشکار از رویّه‌های بازگشتی طرفداری کرد[184]. در ژانویۀ 1960، در کنفرانس نهایی الگول60 در پاریس، مک‌کارتی پیشنهاد کرد که رویّه‌های بازگشتی به زبان الگول60 افزوده گردد. در ارتباط با پیشنهاد مک‌کارتی برای افزودن رویّه‌های بازگشتی، یک نمایندۀ آمریکا در کنفرانس الگول60 پیشنهاد کرد که جداساز«recursive» به زبان افزوده گردد که در بافت «رویّۀ بازگشتی» مورد استفاده قرار گیرد. این پیشنهاد به رأی گذاشته شد که با اختلاف کمی مورد قبول قرار نگرفت[212]. بعضی‌ها رد شدن این پیشنهاد را این‌گونه تعبیر کردند که رویّه‌های بازگشتی نباید به زبان الگول60 افزوده گردد، در حالی که تعبیر بعضی دیگر این بود که رویّه‌های بازگشتی نباید توسط جداساز پیشنهادی، به‌صورت نحوی از رویّه‌های غیربازگشتی متمایز گردند. به این جهت، این دستۀ اخیر فرض کردند که رویّه‌های بازگشتی (پیشنهاد مک‌کارتی) متعلّق به زبان الگول60 هستند، در حالی که دستۀ نخست، از جمله نور و مک‌کارتی، فرض کردند که رویّه‌های بازگشتی به زبان تعلّق ندارند. به‌طور خلاصه، و به گفتۀ پرلیس: «روشن نیست که معنی رأی‌گیری چه بود!»
رأی‌گیری پیش از آن که سایر موضوعات مربوط به قواعد معنایی رویّه‌ها روشن شده باشد، صورت گرفت. پس از رأی‌گیری، و پس از آن که اصلاحات چندی در قواعد معنایی رویّه‌ها به عمل آمد، زبان تعریف شده، از دیدگاه‌ نور، با پیشنهاد نوامبر 1959 مبنی بر ممنوع کردن بازگشت، تناقض داشت. زیرا وَن‌واین‌گاردن و دایکسترا بیان نحوی فعّال‌سازی رویّۀ بازگشتی را ممکن ساخته بودند. آن‌ها که مطمئن نبودند بازگشت به‌صورت معنایی هم در نظر گرفته شده یا نه، در 10 فوریۀ 1960 تلفنی با نور، ویراستار الگول، تماس گرفتند تا این ابهام را برطرف سازند. وَن‌واین‌گاردن پس از مشورت با دایکسترا به نور پیشنهاد کرد که توضیح زیر را به گزارش الگول بیفزاید:

«هر بار پدیدار شدن نام رویّه در داخل بدنۀ رویّه، به معنی فعال‌سازی رویّه است.»[10]

در نتیجه، این به‌طور صریح مشخص می‌کرد که رویّه‌های بازگشتی در الگول 60 قابل بیان هستند. افزون بر این، وَن‌واین‌گاردن در این مکالمۀ تلفنی دربارۀ این که جلوگیری از فعّال‌سازی رویّه‌های بازگشتی به خاطر چند محدودیت زبان، دست و پاگیر خواهد بود، مطالبی را به تفصیل بیان داشت. با نگاهی به گذشته، روشن است که وَن‌واین‌گاردن و دایکسترا اساساً در راستای مباحث زبان‌شناختی استدلال می‌کردند و نه بر حسب ویژگی‌های خاص ماشین. همان‌گونه که خواهیم دید، سادگی برای آن‌ها به معنی محدودیت‌های کمتر زبان بود.
نور ابتدا طرفدار نظریۀ کارایی گروه ALCOR بود امّا مجذوب توضیح یک خطی هلندی‌ها شد و آن را به گزارش الگول60 افزود. آن‌گونه که نور در 1978 به یاد آورده است:

«من شیفتۀ صراحت و سادگی این پیشنهاد یک‌خطی شدم و تصمیم گرفتم که خطر (ریسک) مشکلات بعدی در این باره را بپذیرم و از آن پیروی کنم.»[212]

صحبت از «خطر مشکلات بعدی» نشان می‌دهد که نور کاملاً از تمایل شدید گروه ALCOR برای جلوگیری از تعریف رویّه‌های بازگشتی در زبان، آگاه بوده است.

3-2 درخواست مداوم دایکسترا برای عمومیّت

گروه وَن‌واین‌گاردن در آمستردام بیشتر دقت خود را دهۀ 1950 صرف ساخت ماشین‌های رایانشی و زبان‌های ماشین مرتبط با آن‌ها کرد. دایکسترای برنامه‌نویس نوعاً مجبور بود نرم‌افزار ماشین را بر روی کاغذ بنویسد و منتظر ساخته‌شدن ماشین توسط همکارانش لوپسترا، شولتن و بلائو بماند. تنها در سال 1959 بود که آمستردامی‌ها با مشارکت فعّالانه در تعریف زبان الگول60 و روش‌های ترجمۀ مرتبط با آن، به پروژۀ الگول60 پیوستند. با نگاهی به گذشته، کم‌مهارتی آمستردامی‌ها در فناوری ترجمه و زبان‌های مستقل از ماشین که در بدو امر ممکن بود برایشان نقص شمرده شود، نهایتاً به نفعشان تمام شد. دایکسترا در سال 1980 در این باره گفته است:

«ترکیب بی‌تجربگی در نوشتن برنامۀ مترجم (کامپایلر) از یک سو و ماشین جدید X1 که فاقد روش‌های مدوّن برای استفاده بود از سوی دیگر، کمک زیادی به ما کرد تا رویکردی با ذهن باز به مسئلۀ پیاده‌سازی الگول60 داشته باشیم.»[77]

وَن‌واین‌گاردن و دایکسترا به زبان برنامه‌نویسی، مثلاً الگول60، به‌عنوان یک شیء ریاضی می‌نگریستند و معیارهای زیباشناختی برایشان اهمیت بسیاری داشت. آن‌ها تنها هنگامی به دنبال روشی برای ترجمۀ خودکار می‌رفتند که چنین زبانی تعریف شده بود. سبک کار آن‌ها کاملاً با رویکرد کارایی‌محور که توسط باوئر، ساملسون، ویلکس و دیگران دنبال می‌شد، تفاوت داشت.


3-2-1 در جستجوی یک زبان ساده
یک معیار زیباشناختی مهم برای هلندی‌ها «عمومیّت» بود: هر محدودیت غیرضروری زبان باید به هر قیمتی که بود کنار گذاشته می‌شد تا آن که زبان ساده‌ای حاصل گردد. دایکسترا این نکته را بعداً در مقاله‌ای با مقایسه بین الگول 60 و زبان انگلیسی، روشن ساخته است[67]. او پیشنهاد کرده که هر متن انگلیسی دلخواه را که پنج محدودیت زیر را رعایت کرده باشد، در نظر بگیرید:

  1. کلمات بیش از 15 حرفی ممنوع هستند.
  2. تعداد کل حروف سه کلمۀ متوالی نباید بیشتر از 40 باشد.
  3. جملاتی با بیش از 60 کلمه، مجاز نیستند.
  4. در هر جمله، از یک کلمه به‌عنوان فاعل نمی‌شود دوبار استفاده کرد.
  5. فهرستی شامل 2000 کلمه داده شده که از کلمات داخل آن نمی‌توان استفاده کرد.

دایکسترا اظهار داشته که خواندن هر متنی که با رعایت محدودیت های 1 تا 5 نوشته شده باشد، لزوماً دشوار نیست و یک نفر می‌تواند چنین متنی را بخواند در حالی که کاملاً از این محدودیت‌ها بی‌خبر باشد. امّا ساختن یک متن انگلیسی صحیح با در نظر گرفتن محدودیت‌های 1 تا 5 دشوار است زیرا هنگامی که سعی می‌کنیم این محدودیت‌ها را درک کنیم، هیچ منطقی در پشت آن‌ها نمی‌یابیم. دایکسترا به خاطر وضوح و صحت برنامه‌ها، نمی‌خواست که زبانی مانند الگول60 نیز شامل محدودیت‌هایی نظیر آنچه در بالا گفته شد، باشد. برای نمونه، رویّه‌ای که می‌توانست رویّۀ دیگری را فراخوانی کند امّا نمی‌توانست خودش را فراخوانی کند، از نظر دایکسترا یک محدودیت غیرضروری زبان بود. با حذف این محدودیت، زبان عمومی‌تر و در نتیجه ساده‌تری به دست می‌آمد، یعنی زبانی که رویّه‌های بازگشتی را مجاز می‌شمرد.
دایکسترا در مقاله‌اش با عنوان «دربارۀ طراحی زبان‌های برنامه‌نویسی مستقل از ماشین»[67]، با طرفداری از ساخت‌های پویا به جای ایستا که زبان را قدرتمندتر و بسامان‌تر می‌ساختند، ایدئولوژیش را در الگول60 به کار بست. یکی از مثال‌های دایکسترا بر پایۀ اعلان‌های سوئیچ و رویّه در الگول60 بود. سوئیچ، برداری از برچسب‌های جمله است که در آغاز یک بلوک اعلان می‌گردد. اعلان سوئیچ از نظر نحوی مشابه یک جملۀ تخصیصی است. برای نمونه، یک برنامۀ مبدأ شامل جملۀ switch  S:=S1,S2,S3 معادل برنامه‌ای است که در آن، جمله قبلی با آنچه در زیر آمده، جایگزین شده باشد:
Procedure S (n); value n; integer n;
If n=1 then goto S1
else if n=2 then goto S2
else goto S3

و متناسب با آن، goto S[i] در برنامۀ مبدأ با S(i) در برنامۀ هدف جایگزین شده باشد.
اعلان سوئیچ و رویّه، هر دو دارای طبیعتی دوگانه هستند که به نظر دایکسترا ویژگی نامطلوبی است. از یک سو، اعلان‌های سوئیچ و رویّه، هر دو یک شناسه را برای یک شیء خاص ذخیره می‌کنند و آن شیء به‌صورت ایستا (یعنی بلافاصله) تعریف شده است. بدین ترتیب، اعلان‌های سوئیچ و رویّه، هر دو شبیه اعلان «ثابت» هستند. امّا از سوی دیگر، در حالی که یک عدد ثابت می‌تواند در یک جملۀ تخصیصی که به‌طور پویا مقداری را تخصیص می‌دهد مورد استفاده قرار گیرد، اعلان یک سوئیچ یا رویّه نمی‌تواند به چنین شیوۀ پویایی به کار گرفته شود. بنابراین، دایکسترا پیشنهاد کرد که مفهوم «تخصیص یک مقدار» توسعه داده شود به نحوی که لیست‌ها، جملات و غیره نیز به‌صورت مقادیر تخصیص یافته عمل کنند. این به نوبۀ خود اجازه می‌دهد که تابع تعریف مقدار از اعلان‌های سوئیچ و رویّه حذف گردد. در نتیجه، پس از اعلان switch و procedure فقط لیستی از شناسه‌ها خواهد آمد که تخصیص‌های مناسب نهایتاً در زمان اجرا، یعنی در خلال اجرای برنامه، به آن‌ها به عمل خواهد آمد. به گفتۀ دایکسترا:

«چنین اصلاحی یک بهبود محسوب می‌شود: زبان بسامان‌تر و قدرتمندتر می‌شود، زیرا اکنون تمام رابطه‌های مقداری، پویا شده‌اند.»[67]

تأکید دایکسترا بر ساخت‌های عمومی زبان و پیاده‌سازی‌های پویای مرتبط با آن‌ها، تأثیر منفی بر زمان محاسبات داشت. به گفتۀ استراچی:

«به نظر من ساده‌سازی یا کوچک‌تر کردن زبان به منظور کارآمدتر کردن برنامۀ مقصد، از اهمیت بسیار بالایی برخوردار است. من به‌طور اساسی با دایکسترا دربارۀ این که لازم است همه چیز در همۀ موقعیت‌ها تا حدّ امکان عمومیّت داشته باشد، مخالفم و فکر می‌کنم این یک رویکرد صرفاً نظری است.»

بنابراین جای تعجّب نیست که اظهار نظر سیگمولر در همایش 1962 رم که خطاب به دایکسترا و همفکران زبان‌شناسش بیان شد با استقبال و خندۀ حاضران روبرو گشت. در واقع، برای اغلب افرادی که در همایش شرکت داشتند، کارایی، بالاترین اولویت را داشت و مهم‌ترین موضوع مورد توجه بود.
امّا نگاهی دقیق‌تر به ایدۀ دایکسترا نشان می‌دهد که برنامۀ او به هیچوجه نادیده انگاشتن کارایی نبود بلکه تمرکز بر اهداف عمومی‌تری در رابطه با افزایش سهولت برنامه‌نویسی بود. به گفتۀ خود وی:

«به منظور ارائۀ تصویری روشن‌تر از نیازهای واقعی برنامه‌نویسان، قصد دارم فعلاً توجهی به معیارهای معروف «زمان و حافظۀ مصرفی» نکنم. باید به یاد داشته باشیم که در نهایت، بالاترین هدف از به کارگیری ماشین این است که فعالیتش در خدمت «راحتی» ما باشد.»[67]

به‌عبارت دیگر، دایکسترا برای درک بهتر مسائل زیربنایی و واقعی برنامه‌نویسی، پیشنهاد نادیده‌انگاری (یعنی کنار گذاشتن) ویژگی‌های خاص ماشین را کرد. با وجودی که کاهش زمان اجرا یا حافظۀ مصرفی نیز در افزایش راحتیِ برنامه‌نویسی سهم دارند، امّا معیارهای دیگر، نظیر صحّت برنامه دارای سهم بسیار بیشتری هستند. به گفتۀ دایکسترا:

«من اطمینان دارم که ثابت خواهد شد این مسائل (صحّت برنامه) بسیار فوری‌تر از مثلاً بهره‌گیری تمام عیار از ویژگی‌های خاص ماشین است. اگر نه حالا، در آیندۀ نزدیک خواهد شد.»[67]

به‌عنوان آخرین مثال، دایکسترا در مخالفت با پیشنهاد کارآیی-محور استراچی و ویلکس مبنی بر جلوگیری از رویّه‌های بازگشتی، موضعش را در این باره به روشنی توضیح داده است:

«استراچی و ویلکس گفته‌اند که رویّۀ بازگشتی طولانی‌تر و کندتر از رویّۀ غیربازگشتی است. امّا رویّۀ بازگشتی آنقدر مفهوم عالی و خوش‌ترکیبی است که به سختی می‌توانم تصوّر کنم که تأثیر چشمگیری بر طراحی ماشین‌های جدید در آیندۀ نزدیک نداشته باشد. و این تأثیر به راحتی ممکن است آنقدر قابل ملاحظه باشد که کارایی حاصل از کنار گذاشتن رویّه‌های بازگشتی، کم اهمیت و ناچیز گردد.»[67]

برای توضیح بیشتر باید گفت که استراچی و ویلکس طرفدار راه‌حل‌های ایستای اعمال شده از طریق محدودیت‌های زبان به منظور دستیابی به حداکثر کارایی ماشین بودند. به‌نظر آن‌ها این که تمام رویّه‌های الگول60 بتوانند به‌طور بالقّوه بازگشتی باشند، مثالی از یک «عمومیّت غیرضروری» بود[61]. آن‌ها در عوض می‌خواستند تمام رویّه‌ها به‌صورت پیش‌فرض غیربازگشتی باشند و تنها هنگامی بتوانند بازگشتی باشند که به‌طور صریح توسط برنامه‌نویس مرزبندی شده باشند. بدین ترتیب، نوشتن برنامه‌های مترجمی که بتواند به نحو بسیار کارآمدتری کد ماشین تولید کند، امکان‌پذیر می‌شد. در نقطۀ مقابل، دایکسترا می‌خواست از چنین تمایزی اجتناب شود تا روش‌های پیاده‌سازی و زبان ساده‌تری به دست آید. به‌منظور برآوردن این هدف، او طرفدار ساخت‌های عمومی زبان و راه‌حل‌های پویای همخوان با آن‌ها بود. دایکسترا می‌دانست که رویکردش در مورد برنامه‌نویسی بازگشتیِ عمومی به کد ماشین ناکارآمدتری می‌انجامد امّا عقیده داشت که این نقیصه در آیندۀ نزدیکی از بین خواهد رفت. گویی دایکسترا ظهور معماری ماشین پشته‌ای را پیش‌بینی کرده بود (ماشین پشته‌ای، رایانه‌ای است که ساختار اساسی واحد حساب و منطق (ALU) آن از پشته و عملیات پشته‌ای تشکیل شده باشد. مترجم).
پایان سخن آن که نظر دایکسترا از بسیاری جهات شبیه نظر گورن- براون- جان کار در 1954 بود. درخواست او برای ساخت‌های پویا، هر چند به دلایل متفاوت، شبیه کار نیوول، شاو و سایمون بود. افزون بر این، دایکسترا عقیده داشت که مسائل کارایی در آیندۀ نزدیک حل، یا حدّاقل قابل اغماض خواهد شد. به زعم دایکسترا، عمومیت یک زبان‌برنامه‌نویسی باعث ساده‌تر شدن ساخت برنامۀ مترجم (کامپایلر) می‌شود و این در بلند مدّت بر مسائل کوتاه مدّت مهندسی که مورد نظر افرادی چون باوئر، ساملسون، استراچی و ویلکس بود، چیره خواهد شد.

3-2-2 مقایسه‌ای بین ریاضیات و برنامه‌نویسی
دایکسترا در گزارش فنی خود در اکتبر1961[61]، مقایسه‌ای نیز بین ریاضیات و برنامه‌نویسی به عمل آورد تا توضیح دهد که چرا عقیده دارد زبان برنامه‌نویسی خوب، زبانی است حاوی تعداد اندکی مفاهیم بسیار عمومی.
دایکسترا زبان برنامه‌نویسی را «ابزاری برای خوراندن برنامه‌ها به ماشین» توصیف می‌کرد و می‌گفت که هدف زبان برنامه‌نویسی، «استفادۀ خوب از ماشین» است. همان‌گونه که در بالا گفته شد، او اظهار می‌داشت که پژوهشگران انگلیسی و آلمان غربی، استفادۀ خوب از ماشین را بر حسب کارایی ماشین تعریف می‌کنند در حالی که دیدگاه خود او این بود که زبان برنامه‌نویسی باید در وهلۀ نخست ابزاری باشد برای دستیابی به صحّت برنامه.
دایکسترا با این فرض که صحّت برنامه، بسیار مهم و ضروری است، به این فکر افتاد که چه معیاری باید در طراحی زبان برنامه‌نویسی در نظر گرفته شود تا باعث کاهش خطاهای برنامه‌نویسی گردد. پرسشی که باید بدان پاسخ داده می‌شد این بود: چه معیاری باید در تعریف (و پیاده‌سازی) یک زبان برنامه‌نویسی مورد استفاده قرار گیرد تا به برنامه‌نویس در نوشتن برنامه‌های صحیح کمک کند؟ دایکسترا در جستجوی پاسخ به این پرسش، ابتدا به تشریح مفهوم «صحّت» پرداخت و معنی آن را در حوزۀ ریاضیات در مقایسه با برنامه‌نویسی در نظر گرفت. به گفتۀ خود او:

«اثبات یک قضیۀ ریاضی به‌طور کامل امکان‌پذیر نیست، زیرا هنگامی که کسی فکر کند که چنین کاری کرده است، هنوز یک نفر باید ثابت کند که اثبات اوّلی بدون خطا بوده است و این کار تا بینهایت ادامه می‌یابد. هیچکس هرگز نمی‌تواند تضمین کند که یک اثبات صحیح است. بالاترین چیزی که می‌تواند بگوید این است که: من هیچ خطایی پیدا نکرده‌ام.»

دایکسترا در پاسخ به ملاحظۀ فوق، دو دلیل آورده است که چرا با وجود این، قضایای ریاضی از صحّت و اعتبار خیلی زیادی برخوردارند. هر دو دلیل، طبیعت‌شان جامعه‌شناختی است:

  1. افراد بسیاری، هر یک به شیوۀ خود، به این قضایا رسیده‌اند و احتمال زیادی وجود دارد که آن‌ها در واقع از اصول موضوع پیروی کنند.

 

  1. نتیجه‌گیری‌های فرضی، منوط به شرایط کاملاً تعریف شده‌ای هستند که کاربر برای نشان دادن این که قضیه را به‌طور صحیحی به کار بسته است، کار چندان دشواری ندارد.

دلیل دوم را در اینجا توضیح خواهم داد. می‌گوید که یک قضیه، تنها هنگامی مفید است که تحت تعداد کمی از شرایط مشخص به کار بسته شود. برای مثال، جمله‌ای که تمایز بین اعداد اوّل و اعداد مرکّب را مشخص می‌سازد مفید است امّا جمله‌ای که تمایز بین هفت چیز مختلف را مشخص می‌کند، فایدۀ بسیار کمتری دارد. در نتیجه، جملۀ نخست، پس از آن که اثبات شد، توسط بسیاری از ریاضی‌دانان به‌عنوان یک قضیه در نظر گرفته می‌شود در حالی که برای جملۀ دوم لزوماً چنین نیست.
حال به مقایسه می‌رسیم. دایکسترا اظهار داشته است که درست مانند ریاضی‌دانان، «برنامه‌نویسان نیز در موقعیت مشابهی قرار دارند»، و آن‌ها نیز نمی‌توانند صحّت کامل برنامه‌هایشان را اثبات کنند. ریاضی‌دانان قضیه دارند، برنامه‌نویسان زیرروال. اگر یک قضیه تنها هنگامی مفید است که تحت تعداد کمی از شرایط مشخص به کار بسته شود، در این صورت- اگر مقایسۀ ما درست باشد- چنین ملاحظه‌ای برای یک زیرروال نیز صادق است. به گفتۀ دایکسترا:

«مفیدبودن یک زیرروال (یا یک دستورالعمل دستوری در زبان) افزایش می‌یابد اگر احتمال این که نادرست استفاده شود، کاهش یابد.»

مقایسه را پیشتر می‌بریم. طراح زبان، دستورالعمل‌های دستوری در اختیار دارد و به دلایل مشابه، علاقه‌مند است که تعداد اندکی مفاهیم زبانی داشته باشد. این مفاهیم، با وجود اندک بودن تعدادشان، بسیار عمومیّت دارند. این به‌طور خلاصه، همان چیزی است که دایکسترا در سال 1961 به‌عنوان مفهوم تعالی در حوزۀ تخصصی خود یعنی برنامه‌نویسی امری و طراحی زبان، مطرح ساخت.
توضیح پیشین نشان می‌دهد که دایکسترا در همان سال 1961 بسیار طرفدار استدلال ریاضی بوده است. او در سال‌های بعد طرفدار دو آتشۀ برنامه‌نویسی صحیح‌به‌ساخت می‌شود (رجوع کنید به بخش 2-3-2). شکل 3-1 یکی از اسلایدهای سخنرانی

دایکسترا را در کنفرانس ژنو در سال 1973، به خط خودش نشان می‌دهد.
Description: D:\PUBLIC\BOOK\The Dawn of Software Engineering\figure 3.1.jpg
شکل 3-1: محدودیت‌های آزمایش برنامه، نشان داده شده به خط دایکسترا
(ترجمۀ اسلاید: آزمایش برنامه می‌تواند به نحو مؤثری برای نشان دادن وجود خطاها به کار گرفته شود امّا برای نشان دادن عدم وجود خطا کفایت نمی‌کند.)

 3-2-3 عمومیّت اصل پشته
اصرار دایکسترا برای عمومیّت، تنها در سطح تعریف زبان خلاصه نمی‌شد. او در پیاده‌سازی دایکسترا- زونِولد از الگول60 نیز در جستجوی اصول عمومی بود. برای نمونه، دایکسترا شیوه‌ای که در آن پشته استفاده می‌شد را به دو طریق اساسی عمومیّت بخشید. نخست، او نشان داد که چگونه عملکرد پشته می‌تواند در وقت مناسب عمومیّت بیشتری پیدا کند و نه تنها از آن برای محاسبۀ عبارت‌های محاسباتی، بلکه برای عبارت‌های حاوی فراخوانی رویّه نیز استفاده شود. یعنی رویّه‌ها به کمک چند ثبت اضافی، همانند عبارت‌های محاسباتی در نظر گرفته شوند. دوم آن که او نشان داد چگونه چند نوع مختلف از اقلام (عملگرها، عملوندها، وضعیت‌ها، اولویت‌ها و غیره) می‌توانند در یک پشتۀ عمومی ذخیره شوند، به جای آن که از پشته‌های مخصوص برای هر نوع استفاده شود.
عمومیّت بیشتر در وقت مناسب
تا پیش از اواخر دهۀ 1950، پشته توسط چندین پژوهشگر مستقل بارها و بارها ابداع شده بود. دایکسترا در مقالۀ معروفش در 1960 به نام «برنامه‌نویسی بازگشتی»، به «اصل پشته‌ای» باوئر و ساملسون[16] اشاره کرده و در آن توضیح داده است که چگونه از پشته به‌عنوان یک شیء زمان اجرا، یعنی شیئی در خلال اجرای برنامه، استفاده شود.
شکل 3-2 به نمایش مفاهیم زیربنایی عمومیّت دایکسترا کمک می‌کند. پیکان افقی بالایی نشان می‌دهد چگونه B در پشته قرار گرفته، با فرض این که B از پیش آماده بوده است. امّا اگر B چنین نبود و به جای آن، باید توسط فرمول B=P/Q محاسبه می‌شد، در این صورت، دنبالۀ پیکان‌های جایگزین در شکل 3-2 قابل اجراست: P و Q در پشته قرار گرفته‌اند و سپس به ترتیب از پشته خارج شده‌اند تا P/Q محاسبه شود.

 

 

 

Description: D:\PUBLIC\BOOK\The Dawn of Software Engineering\figure 3.2.jpg
شکل 3-2: عمومیّت بخشی به عملکرد پشته

عمومیّت در این واقعیت نهفته است که پشته می‌تواند برای هر دو فرانامه استفاده شود: چه B از پیش آماده باشد و چه باید محاسبه شود، با استفادۀ موقت از خانه‌های بعدی پشته، نتیجۀ نهایی همان می‌شود. به‌طور عمومی‌تر، که به‌طور صریح در شکل  3-2 نشان داده‌نشده، B ممکن است توسط فراخوانی رویّه‌ای که حاوی عبارت P/Q است نیز محاسبه شود. به گفتۀ خود دایکسترا:

«برای محیطی که در آن، مقدار B استفاده شده است، اهمیتی ندارد که B را بتوان حاضر و آماده در حافظه یافت و یا لازم باشد که از تعدادی از خانه‌های بعدی پشته موقتاً برای محاسبۀ آن استفاده کرد. هنگامی که به جای B، تابعی قرار داشته باشد و این تابع لازم باشد که توسط زیرروالی محاسبه شود، شکل بالا (شکل 3-2) دلیلی قوی برای ترتیب دادن زیرروال به نحوی که در نخستین مکان‌های خالی پشته عمل کند است، درست به همان شکل که یک عبارت مرکّب به‌طور کامل نوشته شده باشد.»[60]

دایکسترا بعداً در مقاله‌اش برای ترتیب دادن رویّه به نحوی که در نخستین مکان‌های خالی پشته عمل کند، توضیح داده است که چگونه یک پشتۀ زمان اجرا می‌تواند این کار را انجام دهد. به‌عنوان محصول جانبی عمومیّت دایکسترا، فعّال‌سازی رویّۀ بازگشتی امکان‌پذیر شد:

«زیر روال فقط باید یکبار در حافظه ظاهر شود، امّا بعد از آن، از نگاهی پویا می‌تواند بیش از یک «تجسّم» همزمان داشته باشد: درونی‌ترین فعّال‌سازی باعث می‌شود که یک تکّۀ مشابه از متن در بخش بالاتری از پشته کار کند. به این جهت، زیرروال به عنصر بنیادینی تبدیل شده است که می‌تواند به‌صورت کاملاً بازگشتی مورد استفاده قرار گیرد.»[60]

پشتۀ عمومیّت یافتۀ دایکسترا قادر به ذخیره‌سازی پارامترها و متغیرهای محلّی رویّه‌های فعّال شده بود. دایکسترا برای این که این عناصر قابل دسترسی باشند، سازوکاری را برای بررسی خانه‌های پائینی پشته‌اش تعبیه کرده بود، سازوکاری که برای محاسبۀ عبارت‌های محاسباتی ساده مورد نیاز نبود.
دایکسترا نخستین کسی نبود که فعّال ‌سازی رویّه‌های بازگشتی را پیاده‌سازی کرده بود. پیش از آن، سازوکارهای بازگشتی نسبتاً ساده‌ای در زبان‌های لیست پردازی IPL و لیسپ به کمک پشته پیاده‌سازی شده بود. روتیس هاوزر در مقاله‌اش در 1963[263]، افتخار ابداع روشی برای پیاده‌سازی بازگشت برای الگول60 را نه فقط به دایکسترا بلکه به ست‌لی و اینگرمن آمریکایی که از نزدیک با فلوید، آیرونز و فویرتسیگ کار کرده بودند نیز ارزانی داشته است. افزون بر این، تورینگ نیز در سال 1954، ایدۀ به کارگیری پشته برای فعّال‌سازی بازگشت به فکرش رسیده بود امّا آن را پیاده‌سازی نکرده بود. باوئر سهم تورینگ را مورد تأیید قرار داده و از روتیس‌هاوزر، وَن‌دِر‌پُل و هاسکی نیز به‌عنوان پژوهشگرانی که فعّال‌سازی‌های بازگشتی را پیش از سال 1960 پیاده‌سازی کرده بودند، نام برده است[14,13].
سبک عمومیّت بخشی دایکسترا، هنگامی که با کارهای هم‌عصرانش مقایسه شود، برجسته می‌گردد. برای نمونه، روتیس‌هاوزر ترتیب فعّال‌سازی‌های بازگشت را در سیستم زمان اجرایش محدود کرده بود، در حالی که دایکسترا چنین محدودیتی قرار نداده بود. کار فلوید[94] به جای یک پشتۀ عمومی، برمبنای سه لیست بالا و پائین روندۀ خاص (یعنی پشته) قرار داشت. به همین ترتیب، مترجم MAD نیز از چند جدول خاص استفاده کرده بود[4]. همچنین، و از همه مهم‌تر، برنامه‌های مترجم ALCOR محدودیت‌های زیادی داشتند و نمی‌توانستند برخی از ساخت‌های زبان الگول60، از جمله رویّۀ بازگشتی را بپذیرند. سرانجام، هر چند سیستم آیرونز- فویرتسیگ[148]، فعّال‌سازی رویّۀ بازگشتی را توسط یک پشتۀ زمان اجرای عمومی پیاده‌سازی کرده بود، امّا از نظر کارآیی، بر خلاف سیستم زمان اجرای دایکسترا- زونِولد برای پیاده‌سازی الگول60، قابلیت‌های زمان اجرایش پیچیده بود.

عمومیّت بیشتر در حافظۀ مصرفی
برای آن که درخواست مداوم دایکسترا برای عمومیّت را بیشتر نشان دهم، ایده‌های اصلی مقاله‌ای را که با عنوان «یکنواسازی مفاهیم اجرای برنامۀ ردیفی» در سال 1962 در رم ارائه کرد[62]، خلاصه می‌کنم. دایکسترا در مقاله‌اش آنچه را که ملاحظات تعمق‌های خود پس از پیاده‌سازی الگول60 خوانده، توصیف کرده است. او زبان یک ماشین پشته‌ای را ارائه کرده که بسیار ناکارآمد بود. زیرا بازهم هدف اصلی دایکسترا، «سادگی و تعالی»، از طریق تعبیۀ روشی یکنواخت برای انجام عملیات مختلف در ماشین بود. برخی از مثال‌های مقالۀ او در زیر آمده است.
برنامۀ زیر را در نظر بگیرید:
6- (3* 2+7)/39+5
شکل پسوندی عبارت فوق برابر است با:
- 6 + / + * 3  2 7   39  5 
که توسط ماشین پشته‌ای از چپ به راست به شکل زیر خوانده می‌شود. هنگامی که به یک عدد برسد، آن را در بالای پشته قرار می‌دهد. هنگامی که به یک عملگر برسد، آن عمل بر روی اعدادی که در دو خانۀ بالای پشته قرار دارند انجام می‌گیرد.
دایکسترا اظهار داشته است که بنابراین، عمل یک عملگر، دوگانه است. از یک سو، نشان می‌دهد که کپی کردن کلمات در پشته باید دچار وقفه شود. و از سوی دیگر، عملی که باید در سر پشته انجام گیرد را نیز مشخص می‌کند. دایکسترا توصیه کرده است که این دو عمل با در نظر گرفتن عملگرهای حسابی به همان صورت اعداد، از یکدیگر جدا شوند: عملگر نیز باید در پشته قرار گیرد و محاسبه‌اش باید از طریق یک حرف جداگانه و جدید E (مخفّف Evaluate) انجام شود. براساس این قرارداد جدید، شکل پسوندی به صورت زیر در می‌آید:
E -  6  E  +  E  /  E  +  E  *  3  2  7  39   5
هرگاه حرف خوانده شده E نبود، در پشته قرار داده می‌شود. و هرگاه برابر E بود، در پشته قرار نمی‌گیرد و در عوض، عملی که در سر پشته قرار دارد انجام می‌شود. چنین اجرایی نهایتاً به قرار گرفتن 2 به‌عنوان عنصر بالایی پشته می‌انجامد که همان نتیجۀ مورد نظر است.
دایکسترا در ادامۀ مقاله‌اش، متغیرهایی را که می‌توانند آن‌ها نیز در پشته قرار گیرد، معرفی کرده است. برای نمونه، عبارت

x+4 ;
معادل شکل پسوندی زیر است:
E  +  4   E  x
در زمان اجرا، x ابتدا در بالای پشته قرار داده می‌شود. پس از برخورد با نخستین رویداد E، متغیر x با مقداری که دارد جایگزین می‌شود که این به وضعیت پردازش در آن لحظه بستگی دارد. برای نمونه، عنصر بالایی پشته یعنی x می‌تواند با 3 جایگزین گردد و این باعث می‌شود که نتیجۀ نهایی در بالای پشته، مقدار 7 باشد. به‌طور خلاصه، دایکسترا متغیرها را به‌صورت عملگرها در نظر گرفته و همان‌طور که پیشتر توضیح داده شد، او عملگرها را به‌عنوان اعداد تلقّی کرده است.
عمومیّت بخشی بعدی دایکسترا به دنبال مشاهدۀ این نکته بود که عدد، فقط نوع خاصی از عبارت است. یعنی با وجودی که در مثال‌های پیشین، نتیجۀ نهایی که در پشته قرار می‌گرفت، تنها یک عدد بود امّا به‌طور عمومی‌تر، امکان دارد مثالی زده شود که در آن، نتیجۀ نهایی یک عبارت عمومی باشد. دایکسترا برای دستیابی به چنین عمومیّتی، با معرفی حرف جدید P (مخفّف Postponement)، اجازه داده است تا حرف E نیز در پشته قرار داده شود. در زمان محاسبۀ P، آن با حرف E جایگزین می‌شود. برای نمونه، متن زیر را با سه متغیر x، y و plinus در نظر بگیرید:
X  P  E  y  P  E  plinns  E  P  E
 سرِ پشته در زمان اجرا به ترتیب نشان داده شده است

 

 

 

 

 

 

x

 

 

 

 

P

x

 

 

 

 

E

x

 

 

 

y

E

x

 

 

P

y

E

x

 

 

E

y

E

x

 

Plinus

E

y

E

x

 

+

E

y

E

x

P

+

E

y

E

x

E

+

E

y

E

x

 

 

 

 




آخرین خط در این شکل حاوی رشتۀ حروفی است که هنگامی که به‌عنوان تکّه‌ای از برنامه خوانده شود، محاسبۀ عبارت x+y را موجب می‌گردد. به طریق مشابه، اگر مقدار متغیر plinus به جای + (جمع)، - (منها) بود، رشتۀ حروف حاصله با عبارت x-y مطابقت داشت. به عبارت دیگر، پیامد نهایی شکل بالا این است که عبارت x plinus y به صورت پاره‌ای محاسبه شده و عبارت دیگری را نتیجه داده است.
دایکسترا در ادامۀ مقاله‌اش نشان داده است که فرق‌گذاری بین اعداد و دستورالعمل‌ها نیز غیرضروری بوده است. افزون بر این، عمومیّت بخشی او باعث شد تا پشتۀ دومی را معرفی کند که او آن را پشتۀ فعّال‌سازی‌ها نامیده است. به گفتۀ خود او:

«ما می‌توانستیم دو پشته را در یکی ادغام کنیم. چنانچه این دو پشته هماهنگ با یکدیگر بزرگ و کوچک می‌شدند، این ادغام به شکلی کاملاً طبیعی صورت می‌گرفت. امّا به‌طور کلّی، این چنین نیست و سعی در ادغام دو پشته، ساختی بسیار غیرطبیعی را به دست می‌دهد.»[65]

به‌طور خلاصه، با وجودی که دایکسترا تنها به یک پشته برای پیاده‌سازی الگول60 نیاز داشت، امّا برای پیاده‌سازی زبان برنامه‌نویسی پشته‌ایِ عمومی‌ترش در سال 1962، به دو پشته نیاز پیدا کرد. در هر دو مورد، چیزی که چشمگیر است تلاش او برای عمومیّت بخشی است.

3-2-4 زبان مقصد مستقل از ماشین
از نظر عمومیّت بخشی، بدون شک مهم‌ترین کار دایکسترا در ارتباط با الگول60، طراحی یک زبان مقصد میانی و مستقل از ماشین بوده است. یعنی زبانی که هدفش توصیف رفتار یک ماشین پشته‌ای عمومی، و نه فقط ماشین X1 به‌طور خاص، بود. دایکسترا این زبان را بین الگول60 و دستورالعمل‌های ماشین X1 قرار داد و بدین ترتیب، آنچه را که امروز جداسازی ملاحظات می‌نامیم به وجود آورد و این امر، پیاده‌سازی الگول60 را به نحو چشمگیری ساده کرد.
جداسازی ملاحظات دو بخش داشت: مرحلۀ ترجمه و به دنبال آن مرحلۀ تفسیر. ترجمه از الگول60 به زبان مقصد به شیوه‌ای مستقل از ماشین صورت می‌گرفت و در نتیجه به کارایی ماشین وابسته نبود. موارد مناسب برای این مرحلۀ ترجمه، کارهایی بودند که می‌توانستند یکبار و برای همیشه انجام شوند. یعنی کارهایی که مستقل از اجرای برنامه و در نتیجه، ذاتاً ایستا باشند. یک نمونه از این نوع کارها، تعیین این است که کدام پرانتزها در برنامۀ الگول60، جفت تشکیل می‌دهند. در مرحلۀ دوم، یعنی مرحلۀ زمان اجرا، برنامۀ مقصدِ به دست آمده، توسط یک مفسّر نوشته شده به کد ماشین X1، پردازش می‌شد. تنها در این مرحله بود که مدیریت پویای حافظۀ فیزیکی وارد بازی می‌شد. یک مثال مهم، نگاشت پشتۀ نرم‌افزاری زمان اجرا به حافظۀ X1 بود.
دیدگاه بالا به پائین دایکسترا، از الگول60 به ماشین، بود که آن را در مقایسه با رویکردهای وابسته به ماشین باوئر، ساملسون و دیگران، متمایز و برجسته می‌ساخت. به گفتۀ خود دایکسترا:

«ما کاملاً در تعیین این که رایانه چگونه باید مورد استفاده قرار گیرد آزاد هستیم، برخلاف ماشین‌هایی که ملاحظات کارایی برای آن‌ها، شیوۀ خاصی از استفاده را در عمل به ما تحمیل می‌کند، یعنی ما را مجبور می‌کند که ویژگی‌های خاص ماشین را در نظر بگیریم.
ساخت مترجم الگول60 کار نسبتاً ساده‌ای است چنانچه مترجم بتواند برنامۀ مقصد را در قالب عملیات مناسب و درخور مسئله در آورد.»[66]

دایکسترا برای طراحی زبان مقصدش، چند انتزاع به عمل آورد. برای نمونه، او فرض کرد که فضای به قدر کافی بزرگ و همگنی وجود دارد و بدین طریق، حافظۀ ناهمگن X1 را در نظر نگرفت. به طریق مشابه، او فرض کرد که واحد حساب X1 فوق‌العاده سریع است و بدین ترتیب توانست بدون نگرانی از زمان محاسبات، از زیرروال‌ها به نحو گسترده‌ای استفاده کند.
دایکسترا همانند براون و جان‌کار در سال 1954 و همان‌طور که پیش از این گفتیم، از طولانی شدن زمان اجرا بر اثر انتزاع‌های خود کاملاً آگاهی داشت. به علاوه، او بر محدودیت‌های کوتاه مدّت راه‌حلش اذعان داشت:

«ما کاملاً از طولانی شدن زمان محاسبات آگاهیم و می‌توانیم تصوّر کنیم که این تأخیر برای برخی از رایانه‌ها که امروز مورد استفاده هستند، قابل پذیرش نباشد. دو دلیل وجود دارد که چرا با وجود این، ما این گزینه را برگزیدیم. یکی به خاطر رعایت اصول و یکی به خاطر ملاحظات عملی ... »[66]

3-2-5 پذیرش ایده‌های دایکسترا
دایکسترا و زونِولد، بسیار سریع موفق به پیاده‌سازی الگول60 شدند. آن‌گونه که رَندل، پژوهشگر انگلیسی به یاد می‌آورد، موفقیت آن‌ها مورد بی‌اعتنایی قرار نگرفت:

«یک هفته را به بحث با دایکسترا گذراندیم ... این مباحثات را در گزارشی طولانی مستند کردیم ... دایکسترا برای چند سال، کسانی را که از او وقت ملاقات می‌خواستند تا دربارۀ برنامۀ مترجم (کامپایلر) X1 اطلاعات بیشتری کسب کنند، به گزارش ما ارجاع می‌داد.»[250]

سبک عمومیّت بخشی دایکسترا تأثیر آشکاری بر پیشرفت‌های عملی بعدی در فناوری برنامه‌های مترجم در دهۀ 1960 داشت و نور نیز این مسئله را به صراحت تأیید کرده است. دایکسترا و زونِولد با رها کردن خود از دغدغۀ کارایی، موفق شدند یک برنامۀ مترجم سریع و عمومی الگول60 و سیستم زمان اجرای همخوانش را برای رایانۀ نسبتاً کوچک X1 تولید کنند.
برخلاف تیم آمستردام، چند عضو ALCOR، فناوری عملی ترجمه را پیش از ورود رویّۀ بازگشتی به تعریف الگول60، در دسترس داشتند. ALCOR با اولویت بخشی به کارایی، تصمیم گرفته بود که زمان اجرای خود را با در پیش گرفتن رویکردی ایستا، تا جایی که امکان دارد به حداقل برساند: به هر رویّه پیش از اجرای برنامه، فضای کاری ثابتی تخصیص داده می‌شد، تقریباً شبیه رویکرد فرترن که در فصل 1 توضیح داده شد. این بدان معنی بود که رویّه‌ها نمی‌توانستند در خلال اجرای برنامه، بیش از یکبار فعّال گردند و از این رو، به ویژه فعّال‌سازی رویّۀ بازگشتی کنار گذاشته شده بود. امّا در همایش 1962 رم، باوئر و ساملسون تأسف و پشیمانی خود را از انتخاب این راه‌حل ایستا ابراز داشتند:

«تصمیم گرفته شده بود که حافظۀ ایستایی به هر رویّه به‌طور جداگانه درون بلوک حاوی رویّه تخصیص داده شود که این امر البته باعث کنار گذاشتن رویّه‌های بازگشتی می‌شد. اتلاف حافظۀ ایستا، در تضاد با اصل ذخیره‌سازی اولیۀ ما (یعنی پشته)، باعث تأسف بود.»[265]

این کلمات، کلماتی طعنه‌آمیزند زیرا ALCOR طرفدار جدّی راه‌حل‌های عملیِ مهندسی‌بنیاد بود. برخی از اعضای ALCOR مانند سیگمولر آشکارا از دایکسترا، وَن‌واین‌گاردن و نور که به نظر می‌رسید دغدغۀ کارایی ماشین را ندارند و در عوض در تکاپوی زبان الگوریتمی‌تری هستند، فاصله گرفته بودند. بنابراین، این طعنه (بیان تفاوت میان واقعیت در نظر ALCOR و واقعیت حقیقی که بر پژوهشگران آشکار شده بود) گویای این بود که رویکرد ALCOR، حتی با وجودی که استفاده از زبان برنامه‌نویسی را محدود کرده بود، شکست خورده بود. در حالی که رویکرد دایکسترا چنین محدودیتی هم بر روی استفاده از زبان نگذاشته بود.
گروه نور در کپنهاگ ابتدا به ALCOR پیوسته بودند و در نتیجه، آن‌ها نیز کارایی را به‌عنوان بیشترین اولویت، مدنظر قرار داده بودند. دانمارکی‌ها حتی پس از آن که همکاری نزدیکی را با گروه آمستردام آغاز کرده بودند، همچنان در مقابل رویکرد آمستردامی‌ها مقاومت می‌کردند. به گفتۀ نور:

«در مارچ 1960، هلندی‌ها ما را با رویکرد بسیار عمومی خود تحت تأثیر قرار دادند. با وجود این، هر چند آن‌ها آماده شده بودند تا راه‌حلشان برای رویّه‌های بازگشتی را در اختیار ما بگذارند، ما تصمیم گرفتیم همچنان به رویکرد کم‌ادّعاتر خود که تا حدّی پیاده‌سازی آن را پیش برده بودیم، وفادار بمانیم. این مقاومت، دلایلی عملی داشت. در آن زمان، ما از این هراس داشتیم که با گنجاندن رویّه‌های بازگشتی، سرعت اجرای سیستم را از دست بدهیم (هراسی که اکنون می‌دانیم بی‌پایه بود).»[205]

از این‌رو، دانمارکی‌ها در ابتدا قادر نبودند رویّه‌های بازگشتی را بپذیرند. آن‌ها در راستای سیاست ALCOR، راه‌حل‌های ایستا را برگزیده بودند. افزون بر این، دانمارکی‌ها به‌طور صریح اجازه داده بودند که انتقال اطلاعات بین حافظۀ اصلی و طبله (حافظۀ پرگنجایش آن زمان، مترجم) در برنامه‌های الگول60 بیان گردد[151]. چنین برنامه‌نویسی وابسته به ماشین، در تضاد کامل با رویکرد دایکسترا- زونِولد و بسیار شبیه کارهای استراچی و ویلکس و نیز زبان اسپیدکدینگ بَکوس بود.
امّا دانمارکی‌ها در سیستم بعدی خود در سال 1962 به نام GIER، از «مکتب آمستردام» پیروی کردند و به این جهت توانستند رویّه‌های بازگشتی را نیز مدیریت کنند. گروه ALCOR به چند سال دیگر نیاز داشت تا آن‌ها نیز سرانجام خود را با رویکرد آمستردامی‌ها وفق دادند و بالاخره این رویکرد در سال 1965 توسط گریز و دیگران به‌عنوان الگو و سرمشق برنامه‌های مترجم (کامپایلر) توصیف گردید.

3-3 دوگانگی در تلاش‌های الگول60 بیشتر دوام کرد
از دایکسترا به‌عنوان پیاده‌ساز موفق الگول60 دعوت شد تا در همایش مونیخ در پائیز 1962 به‌عنوان سخنران کلیدی صحبت کند. او در سخنرانیش با عنوان «تأملاتی در برنامه‌نویسی پیشرفته»، اطمینان‌پذیری و بهینه‌سازی را در تقابل آشکار با هم قرار داد و جای تعجّب نداشت که به سود اوّلی رأی داد. به گفته خود او:

«در انتخاب بین اطمینان‌پذیری فرایند ترجمه از یک سو، و تولید برنامۀ مقصد کارآمد از سوی دیگر، معمولاً به نفع دومی رأی داده
می‌شود. امّا احساس من این است که کفۀ ترازو اینک به سمت اوّلی چربش دارد.»[64]

دایکسترا در ادامه خاطر نشان ساخت که دو روش برای استفاده از یک رایانۀ جدید و قوی‌تر وجود دارد. او گفت روش سنتی و قدیمی، استفاده از ماشین جدید با کارایی هر چه بیشتر است. امّا روش دیگر، تشخیص این نکته است که ماشین جدید سریع‌تر است و این که زمان، دیگر اهمیت چندانی ندارد. یعنی هزینۀ هر عمل در ماشین جدید کمتر از ماشین قدیمی است. از این رو، واقع‌بینانه‌تر است که مقداری از سرعت ماشین را در چیزهایی بجز کارایی صِرف، مثلاً سهولت برنامه‌نویسی، زیبائی و اطمینان‌پذیری، سرمایه‌گذاری کنیم.
دایکسترا به بهینه‌سازی و اطمینان‌پذیری به‌صورت دو هدف متضاد با یکدیگر می‌نگریست. او بهینه‌سازی را «بهر‌ه‌گیری از یک شرایط خاص» توصیف می‌کرد. به عقیدۀ او ساختن یک مترجم بهینه‌ساز در مقایسه با یک مترجم ساده امّا قابل فهم و اطمینان‌پذیر، کار نادرستی است.
پس از آن، دایکسترا الگول60 را به‌عنوان یک «شناسانگر عالی مترجم‌های غیربهینه‌ساز» توصیف کرد، گفته‌ای که به زودی به هنگام بحث دربارۀ کارهای آیرونز و فویرتسیگ به آن برخواهم گشت. او صحبت‌هایش را با مقایسۀ پیاده‌سازی دایکسترا- زونِولد با پیاده‌سازی‌های دیگر الگول60 که بر پایۀ محدویت‌های زبان بودند، ادامه داد:

«واقعیت این است که زبان، در شرایط کنونی، مطمئناً پذیرای بهینه‌سازی نیست. برای آن‌هایی که فکر می‌کنند چگونگی نوشتن مترجم‌های بهینه‌ساز را می‌دانند، این یکی از دلایل رد الگول60 به‌عنوان یک ابزار جدّی بوده است. به عقیدۀ من این افراد روی اسب اشتباهی شرط‌بندی کرده‌اند.»[64]

آخرین جمله، این تصوّر اشتباه را به وجود می‌آورد که گویی دوگانگی بین ویژه‌گرایی و عمومیّت برای دیگر پژوهشگران نیز همچون خود دایکسترا در 1959 و 1960، روشن و آشکار بوده است. امّا آن‌گونه که گالر[100]، گالی[102] و رندل در 1964 اظهار داشته‌اند، این دوگانگی در واقع پس از 1960 آشکارتر شده است.

3-3-1 رویکرد دوگانه
با وجودی که برنامۀ مترجم (کامپایلر) دایکسترا زونِولد (و سیستم زمان اجرای همخوان آن) توسط رَندل و همکارانش در لستر مورد اقتباس و تقلید قرار گرفته بود امّا شایان ذکر است که انگلیسی‌ها کاملاً از دایکسترا پیروی نکردند. زیرا گروه لستر در سال‌های بعد دو برنامۀ مترجم جداگانه برای الگول60 در اختیار داشت: یکی برنامۀ مترجم وِتستون و دیگری کیدزگرو. اوّلی خیلی شبیه برنامۀ مترجم دایکسترا- زونِولد بود و همانند آن، در ترجمۀ برنامه‌های الگول، سریع امّا در تولید برنامه‌های سریع، ضعیف بود و دومی برعکس، شباهت کمی به برنامۀ مترجم دایکسترا- زونِولد داشت و مترجم کندی بود که برنامه‌های خیلی سریع تولید می‌کرد. رویکرد عملی گروه لستر، دوگانه بود. هر برنامۀ جدید الگول60، ابتدا به سرعت توسط برنامۀ مترجم وِتستون ترجمه و آزمایش می‌شد. پس از آن که برنامه‌نویس از صحّت برنامه‌اش اطمینان می‌یافت، این بار از برنامۀ مترجم کیدزگرو برای ترجمۀ دوبارۀ برنامه‌اش استفاده می‌کرد تا کد ماشین سریعی به دست آورد. بدین ترتیب، گروه لستر به «رویکرد دوگانه‌ای» رسیده بود که در آن، نگرش دایکسترا در یک برنامۀ مترجم و نگرش کارایی-محور در دیگر برنامۀ مترجم گنجانده شده بود. بنابراین، از لحاظ عملی، دوگانگی و دودستگی در تلاش‌های الگول60 بیشتر دوام کرد و این تا اندازه‌ای با سخنرانی کلیدی دایکسترا در مونیخ در سال 1962، در تناقض است.

3-3-2 بهینه‌سازی زمان اجرا
با وجودی که دایکسترا به الگول60 به‌عنوان «شناسانگر عالی مترجم‌های غیربهینه‌ساز» می‌نگریست، ذکر این نکته جالب است که در سال 1960، یعنی همان سالی که مقالۀ دایکسترا دربارۀ بازگشت[60] به چاپ رسید، آیرونز و فویرتسیگ نیز به روشی برای پیاده‌سازی رویّه‌های بازگشتی دست یافته بودند. سیستم زمان اجرای آیرونر-فویرتسیگ بر خلاف سیستم زمان اجرای دایکسترا-زونِولد، روش‌های بهینه‌سازی را به کار بسته بود، یعنی در خلال اجرای برنامه.
سیستم آیرونز-فویرتسیگ به کمک برخی ثبت و ضبط‌های اضافی، در خلال اجرای برنامه تشخیص می‌داد که رویّۀ مورد بررسی بازگشتی است یا نه. به عبارت دیگر، سیستم در زمان اجرا با تمایز قائل شدن بین فعّال‌سازی رویّه‌های بازگشتی و غیربازگشتی و رفتار جداگانه با هر نوع از آن‌ها، ویژه‌گرا می‌شد. در نتیجه، تنها رویّه‌های کاملاً بازگشتی از لحاظ تخصیص حافظه، سربار زیادی تحمّل می‌کردند و کند می‌شدند، در حالی که در سیستم زمان اجرای دایکسترا- زونِولد، با «تمام» رویّه‌ها یکسان رفتار می‌شد.
سیستم آیرونز- فویرتسیگ را می‌توان یک سیستم دوگانه توصیف کرد که بین دو سر طیف قرار داشت: راه حل کاملاً ایستای باوئر و ساملسون از یک سو و راه‌حل کاملاً پویای دایکسترا و زونِولد از سوی دیگر. در رویکرد باوئر- ساملسون، پیش از اجرای برنامه، حافظۀ ثابتی به هر رویّه توسط برنامۀ مترجم (کامپایلر) تخصیص داده می‌شد. این کاملاً همراستا با رویکرد سنتی و به ویژه با فناوری برنامۀ مترجم فرترن بود. در رویکرد دایکسترا- زونِولد، تمام داده‌ها به‌طور پویا توسط یک پشتۀ عمومی زمان اجرا، مدیریت می‌شد. از این رو، داده‌های رویّه‌های بازگشتی و غیربازگشتی هر دو، هنگامی که در خلال اجرای برنامه فراخوانده می‌شدند، درون پشته قرار می‌گرفتند.
رویکرد آیرونز- فویرتسیگ بدین ترتیب دوگانه بود که از راهبرد ترجمۀ باوئر و ساملسون برای هر رویّه پیروی می‌کرد امّا هنگامی که در خلال اجرای برنامه، سیستم زمان اجرای آن‌ها تشخیص می‌داد که رویّه‌ای برای بار دوم فراخوانی شده است، با آن رویّه به‌طور پویا رفتار می‌شد. یعنی داده‌هایش همراستا با رویکرد دایکسترا- زونِولد، در یک پشتۀ عمومی زمان اجرا قرار داده می‌شد.
سیستم زمان اجرای دایکسترا و زونِولد در نقطۀ مقابل، در خلال اجرای برنامه هیچ بررسی برای تعیین این که رویّۀ قعّال شدۀ P برای بار دوم فراخوانی شده است یا نه، یعنی بازگشتی است یا نه، نمی‌کرد. بدین جهت، هرگاه P رویّۀ دیگری مانند Q را فراخوانی می‌کرد، فرض می‌شد P بازگشتی است و از این رو، در آینده هم دوباره فراخوانی خواهد شد. در نتیجه، تمام آرایه‌ها و متغیرهای محلّی P، پیش از فراخواندن Q باید در یک پشتۀ نرم‌افزاری قرار داده می‌شدند تا بتوانند برای حالت خاص بازگشتی که رویّه دوباره فراخوانی می‌گردید، هویّت یگانۀ خود را حفظ کنند. در سیستم زمان اجرای آیرونز و فویرتسیگ، چنین مدیریت پرهزینۀ پشته تنها پس از تعیین این که P بیش از یکبار فراخوانی می‌گردید، صورت می‌گرفت.
ویژه‌گرایی زمان اجرای آیرونز و فویرتسیگ با به کارگیری چند تمایزبخشی پیاده‌سازی شده بود. نخستین مثال البته همان چیزی است که پیش از این در مورد تمایزی که سیستم زمان اجرای آن‌ها بین رویّه‌های بازگشتی و غیربازگشتی می‌گذاشت گفته شد. مثال دوم، تمایز بین رویّه‌ها و بلوک‌ها بود. به گفتۀ خود آیرونز و فویرتسیگ:

«چون به یک بلوک نمی‌توان بیش از یکبار وارد شد بدون آن که از آن خارج شده باشیم، مگر آن که در یک رویّۀ بازگشتی قرار گرفته باشد، بنابراین کافی است که شمارنده‌ای را فقط برای هر رویّه، و نه برای تمام بلوک‌ها، نگاهداری کنیم.»[148]

اگر دایکسترا مجبور شده بود بهینه‌سازی‌های زمان اجرا را اعمال کند، در آن صورت او رویّه‌ها و بلوک‌ها را به شیوۀ یکسانی در نظر می‌گرفت و تمایزی بین آن‌ها قائل نمی‌شد، حتی اگر این کار به قیمت از دست دادن کارایی می‌بود. مثال سوم، تمایز بین رویّه‌های خودبازگشتی با رویّه‌هایی که به‌طور غیرمستقیم بازگشتی بودند، بود. آیرونز و فویرتسیگ گفته‌اند که با این تمایزبخشی، می‌توانند به بهینه‌سازی‌های بیشتری بر حسب کارایی ماشین دست یابند[148].
از دیدگاه دایکسترا، قائل شدن این تمایزها در سیستم زمان اجرای آیرونز- فویرتسیگ، پیچیدگی غیرضروری بودند. امّا از دیدگاه کارایی-محور، رویکرد آیرونز-فویرتسیگ، برجسته و جالب بود زیرا نه تنها به برنامه‌های سریع الگول60 می‌انجامید بلکه این کار را بدون محدود کردن آن زبان انجام می‌داد. بنابراین، دوگانگی بین ویژه‌گرایی و عمومیّت برای رویکرد آن‌ها مصداق نداشت. در راه‌حل آن‌ها «ویژه‌گرایی» در خلال اجرای برنامه و برای زبان الگول60 با «عمومیّت کامل»، به کار گرفته می‌شد.
با وجود این، ویژه‌گرایی زمان اجرای آیرونز و فویرتسیگ همچنان به‌طور کامل در نقطۀ مقابل روش پیاده‌سازی عمومی که دایکسترا و زونِولد در سیستم زمان اجرایشان به‌کار برده بودند قرار داشت. یعنی بخشی از سخنرانی کلیدی دایکسترا در مونیخ در سال 1962 همچنان معتبر باقی می‌ماند زیرا کارایی زمان اجرا که توسط آیرونز و فویرتسیگ دنبال شده بود هنوز در نقطۀ مقابل سادگی زمان اجرا که به نظر دایکسترا پشتیبان صحّت و اطمینان‌پذیری بود، قرار داشت.
3-4 کلام آخر
تاکنون چندین پژوهشگر دربارۀ تاریخچۀ رایانش و به‌ویژه دربارۀ تاریخچۀ زبان‌های برنامه‌نویسی نوشته‌اند. همچنین تعداد فزاینده‌ای از دانشجویان نیز به رویدادهای گذشته علاقه‌مند هستند. با وجود این، من هم با گفته‌های ماهونی موافقم که هنوز به پژوهش‌های بیشتری نیاز است:

«تاریخ‌نویسان عمدتاً دربارۀ سرچشمه‌ها و تولید فرایندهای پویا که بر روی رایانه‌ها اجرا می‌شوند، فرایندهایی که تعیین می‌کنند که ما با رایانه‌ها چکار می‌کنیم و چگونه دربارۀ آنچه انجام می‌دهیم فکر می‌کنیم، غافل مانده‌اند. تاریخچه‌های رایانش دربردارندۀ جنبه‌های مختلفی خواهند بود امّا همۀ آن‌ها در اصل، تاریخچه‌های نرم‌افزار هستند.»[181]

رویّۀ بازگشتی، مثال خوبی از چنین فرایند پویایی است. امّا تا جایی که من اطلاع دارم، در هیچیک از متون تاریخی پیشین، از لحاظ تکنیکی در نظر گرفته نشده‌اند. همچنین در هیچیک از تاریخچه‌های نوشته شدۀ نرم‌افزار، آنچنان که من در این فصل و فصل پیشین تلاش کرده‌ام، دیدگاه‌های دایکسترا در تقابل با دیدگاه‌های هم‌عصرانش قرار داده نشده است.
کارهای پژوهشی گودل، کارناپ، تورینگ و تارسکی بارها و بارها توسط خود منطق‌دانان و فلاسفه مطالعه و مستند شده است. امّا در نقطۀ مقابل، پژوهشگران حوزۀ رایانش هنوز کارهای مشابهی را دربارۀ ایده‌های پدرانشان، یعنی دایکسترا، مک‌کارتی، هور و دیگران، آغاز نکرده‌اند. این انگیزۀ من از نوشتن این کتاب بوده است.
برای درک بهتر کارهای دایکسترا، هنوز به نوشته‌های تاریخی دیگر پژوهشگران نیاز است. من براساس نسخۀ پیش‌نویس این فصل، اظهار نظرهایی دریافت کرده‌ام مبنی بر این که ایده‌های دایکسترا دربارۀ طراحی زبان برنامه‌نویسی که در بخش 3-2-1 شرح داده شد، فقط به منظورهای نظری بوده و من با ارتباط دادن افکار انتزاعی او با کارهای عملیش، تا حدودی دچار اشتباه شده‌ام. اظهار نظر مشابهی هم دربارۀ ماشین انتزاعی دایکسترا که در بخش 3-2-3 توضیح داده‌ام، دریافت کرده‌ام.
بر پایۀ درک من از دایکسترا به‌عنوان فردی که نمی‌خواست بین نظریه و عمل تمایز قائل شود و به‌عنوان کسی که آنچه را توصیه می‌کرد خود عمل می‌کرد، دو اظهار نظر پیش گفته به باور من بی‌اساس است. این اظهار نظرها مرا به یاد انتقادهای سیگمولر و استراچی از دایکسترا می‌اندازد که ادّعا می‌کردند کارهای او صرفاً نظری است. در صورتی که چنین نبوده است! ایده‌های انتزاعی دایکسترا به روشنی در کارهای عملیش انعکاس یافته است. برای نمونه، کنار نهادن موقتی کارایی توسط دایکسترا، هنگامی که دربارۀ کیفیت زبان برنامه‌نویسی بحث می‌کند، مستقیماً در طراحی دو مرحله‌ای پیاده‌سازی الگول60 توسط دایکسترا و زونِولد انعکاس پیدا کرده است. به‌طور مشابه، افکار او دربارۀ زبان‌های انتزاعی ماشین، به وضوح با زبان مقصد پشته‌ای که او برای ساده‌تر کردن پیاده‌سازی الگول 60 معرفی کرده است، ارتباط دارد. و سرانجام این که دایکسترا از یک پشتۀ عمومی برای پیاده‌سازی الگول60 استفاده کرد در حالی که بسیاری از هم‌عصرانش از چند پشتۀ مخصوص استفاده کرده بودند، و او از دو پشته در کارهای بعدیش که در سال 1962 در رم ارائه شد استفاده کرده است. آیا این تصادفی است که اغلب ماشین‌های پشته‌ای نسل اوّل که برای اجرای زبان‌های شبیه الگول طراحی شده‌اند، تنها یک پشته دارند و رایانه‌های پشته‌ای نسل دوم، محاسبات و جریان کنترل را توسط دو پشته از یکدیگر جدا کرده‌اند؟ من تعجّب نخواهم کرد اگر افکار انتزاعی دایکسترا، بار دیگر تأثیر مستقیمی بر چنین موضوعات عملی داشته باشد.
هنوز چند پرسش دیگر دربارۀ کارهای دایکسترا وجود دارد که باید مورد بررسی قرار گیرند. برای نمونه، من به پیشنهاد زیر که توسط هنریکسون به عمل آمده ارجاع می‌دهم[121]: دایکسترا ممکن است با کار تورینگ دربارۀ «حافظۀ بازگشتی» (یعنی اصل پشته‌ای تورینگ) از طریق هاسکی که وَن‌واین‌گاردن و دایکسترا را در تابستان 1959 در آمستردام ملاقات کرده بود آشنا شده باشد. در واقع، دایکسترا در پایان مقاله‌اش در سال 1960 صراحتاً از هاسکی به خاطر گفتگوهای «الهام بخشی» که با او در آمستردام داشته، قدردانی کرده است. البته یادآوری‌های 20 سال بعد دایکسترا کاملاً چیز دیگری بوده است:

«هَری هاسکی تنها چند ماه را به‌عنوان فرصت مطالعاتی در مرکز ریاضی آمستردام گذرانده بود و بر روی برنامۀ مترجم جبری کار می‌کرد امّا سبک کار او کاملاً با سبک من تفاوت داشت و من حتی نمی‌توانستم از کار او به‌عنوان یک منبع الهام‌بخش استفاده کنم. به یاد می‌آورم هنگامی که مجبور بودم این پیام نومیدکننده را به رئیسم (یعن وَن‌واین‌گاردن) منتقل کنم، بحث ناخوشایندی با هم داشتیم و یکی از موقعیت‌های نادری بود که من مشتم را بر روی میز کوبیدم.»[77]

بنابراین به پژوهش‌های بیشتری نیاز است تا روشن شود آیا هاسکی بر روی دایکسترا در پیاده‌سازی الگول60 تأثیر گذاشته است یا نه. امّا ذکر این نکته اهمیت دارد که در خلال دهۀ 1950، آمریکا و انگلستان در مقایسه با هلند از نظر فناوری پیشرفته‌تر بودند (به بخش 3-1 رجوع کنید). هاسکی آمریکایی ممکن است در دوران اقامتش در آمستردام در سال 1959، نقش مهمی در انتقال فناوری از تورینگ به دایکسترا بازی کرده باشد.
از یک سو، به نظر می‌رسد سبک هاسکی با تلاش‌های عمومیّت بخشی دایکسترا کاملاً متفاوت بوده است و این را می‌توان در اظهارنظرهای منفی هاسکی دربارۀ ساخت‌های عمومی زبان و لیست‌های مخصوص و متعددی که در NELIAC (نسخه‌ای از الگول) به کار برده، بازیافت. بدین ترتیب، نقل قول پیشین از دایکسترا چندان تعجّب برانگیز نخواهد بود.
امّا از سوی دیگر، تکنیک به کار رفته در برنامۀ مترجم کیس و هاسکی در 1962[152]، بسیار شبیه روش دایکسترا و زونِولد است. یک زبان مقصد مستقل از ماشین و میانی دارد و تخصیص پویای حافظه و رویّه‌های بازگشتی توسط همگذار (اسمبلر) پردازش شده‌اند. آیا هاسکی این تکنیک‌ها را از دایکسترا آموخته بود یا برعکس؟ یا آن که ایده‌های این دو نفر در راه‌حل مشابهی به هم رسیده بودند؟ آن‌گونه که ماهونی تاریخ‌نگار بیان داشته: «حتی هنگامی که پاسخ را نمی‌دانیم، در نظر گرفتن پرسش‌ها اهمیت دارد. آن‌ها نیز بخشی از درک ما را تشکیل می‌دهند. اگر اکنون نمی‌توانید به آن‌ها پاسخ دهید، تاریخ‌نگاران بعدی را نسبت به آن‌ها هوشیار می‌کنید.»[180]
سرانجام باید خاطر نشان ساخت که به خاطر تمرکز بر کارهای دایکسترا و الگول60، در این فصل به برخی از پژوهشگران مهم یا خیلی مختصر اشاره شده و یا اشاره‌ای نشده است. از آن جمله می‌توان سوزه، هاپر، لنینگ و زیلر را نام برد. همچنین به لحاظ ملیّت، پژوهشگران فرانسوی (مانند وُکوا)، نروژی (مانند گارویک) و انگلیسی (مانند وودگِر) مشارکت فعّالانه‌ای در تعریف الگول60 داشته‌اند. به موضوعات مهم دیگری چون ترجمۀ نحو-گرا به‌طور گذری اشاره شده که شایستۀ توجه بیشتر در کارهای آینده می‌باشد.

نتیجه‌گیری

دو پیام در دل این فصل نهفته است: (1) تاریخچۀ اولیۀ زبان‌های برنامه‌نویسی، و به ویژه تلاش‌های الگول60، را می‌توان به‌صورت یک دوگانگی بین ویژه‌گرایی و عمومیّت درک کرد و (2) پافشاری مداوم دایکسترا برای عمومیّت به پیشرفت علمی در فناوری برنامۀ مترجم (کامپایلر) انجامید. ویژه‌گرایی، آن‌گونه که توسط باوئر، ساملسون، استراچی و ویلکس ترویج می‌شد، مستلزم محدودیت‌های زبان، راه‌حل‌های ایستا و بهره‌گیری از امکانات خاص ماشین به خاطر دستیابی به کارایی بیشتر بود. عمومیّت، آن‌گونه که توسط وَن‌واین‌گاردن و دایکسترا ترویج می‌شد، مستلزم ساخت‌های عمومی زبان، راه‌حل‌های پویا، و طراحی زبان به‌صورت مستقل از ماشین به خاطر دستیابی به صحّت و اطمینان‌پذیری بود.
در اروپای غربی، استدلال‌های زبان شناختی وَن‌واین‌گاردن و دایکسترا، بیشتر استثناء بود تا قاعده. دایکسترا در سال 1961، کلّ یک گزارش[61] را به مخالفت با محدودیت‌های زبان که توسط استراچی، ویلکس و دیگران برای دستیابی به کارایی ماشین پیشنهاد شده بود، اختصاص داد. در اینجا، جنگ بین عمومیّت‌گرایان و ویژه‌گرایان در کلمات خود دایکسترا به‌صورت پرشوری نمایش داده شده است. مباحثات میزگرد همایش 1962 رم نیز نشانگر تنش‌های به‌وجود آمده بر اثر این دوگانگی و دودستگی است.
راه‌حل‌های سادۀ دایکسترا، برآمده از سبک عمومیّت بخشی او، در مقایسه با کارهای هم‌عصرانش بسیار برجسته بود و همین بود که پیاده‌سازی دایکسترا-زونِولد از الگول60 را درخشان کرده بود. افزون بر این، تلاش‌های او برای یکنواسازی بود که باعث شد او به همراه وَن‌واین‌گاردن رویّۀ بازگشتی را از ابتدا ترویج دهد و روشی برای پیاده‌سازیش بیابد. البته او نیز همانند بسیاری از هم‌عصرانش ضرورتی واقعی برای استفاده از رویّۀ بازگشتی برای حل مسائل عملی برنامه‌نویسی حس نمی‌کرد. به گفتۀ خود او در سال 1962:

«یکی از ویژگی‌های عالی برنامۀ مترجم (کامپایلر) ما این است که داشتن تابع بازگشتی در آن بسیار ساده است ... توابع بازگشتی به ندرت به کار گرفته می‌شوند ... آن‌ها امکاناتی را در اختیار می‌گذارند که می‌تواند الهام‌بخش باشد. به این جهت من کاملاً مشتاقم که رویّه‌های بازگشتی را که تاکنون هرگز استفاده نکرده‌ام، به کار گیرم.[230]
در محاسبات عملی، این امکانات (عمومی) خیلی مورد استفاده قرار نگرفته‌اند امّا این واقعیت که برنامه‌نویسان در صورتی که بخواهند می‌توانند از آن‌ها استفاده کنند، زبان را خیلی جذّاب کرده است.»[63]

با وجودی که دایکسترا به همراه زونِولد موفق به پیاده‌سازی الگول60 با رویّه‌های بازگشتی شد، بسیاری از شرکت‌کنندگان در همایش 1962 رم، نسبت به تأکیدهای دایکسترا بر ساخت‌های عمومی زبان و تکنیک‌های پیاده‌سازی پویای مرتبط، شکاک باقی ماندند. این تکنیک‌ها، به عقیدۀ بسیاری، تأثیری منفی بر زمان محاسبات داشت. در حالی که اغلب شرکت‌کنندگان در همایش بیشترین اولویت را برای کارایی قائل بودند، جای تعجّب نبود که دایکسترا به‌عنوان کسی که کاملاً غافل از مباحث کارایی است، قلمداد شود. امّا به نظر می‌رسد که دایکسترا پیشرفت‌های چشمگیری را که در فناوری الکترونیک در راه بود، پیش‌بینی کرده بود.
هنگامی که جامعۀ بین‌المللی در سال‌های 1959 و 1960 به سوی تعریف زبان الگول60 متمایل شد، گروه ALCOR برخلاف گروه آمستردام، تجربیات فنّی بسیاری با الگول58 داشت. آن‌ها با در پیش گرفتن یک سیاست کارایی‌محور، از رویّۀ بازگشتی و دیگر ساخت‌های پویای زبان پرهیز کرده بودند. از سوی دیگر، وَن‌واین‌گاردن و دایکسترا به دنبال یک زبان عمومی بودند. آن‌ها بیشتر به فکر زیبایی‌های زبان بودند تا محدودیت‌های عملی ماشین‌های رایانشی واقعی. و تنها در نتیجۀ چنین طرز فکری بود که آن‌ها  طرفدار رویّۀ بازگشتی بودند.
تلاش دایکسترا برای عمومیّت، به پیشرفت‌های عملی در فناوری برنامۀ مترجم انجامید و انگلیسی‌ها، دانمارکی‌ها، آلمان‌غربی‌ها و دیگران به کپی‌کردن بخش‌هایی از کار یکنواسازی او و به ویژه، رویکرد بالا به پایین طراحی برنامۀ مترجم و سیستم زمان اجرای او پرداختند. چنین موفقیت عظیمی باعث شد تا دایکسترا دیدگاه‌های جسورانه‌ترش را در سخنرانی کلیدی‌اش در مونیخ در سال 1962 ارائه کند. او با آگاهی کامل از دوگانگی و دو دستگی بین ویژه‌گرایی و عمومیّت، دومی را برتر دانست و به الگول60 به‌عنوان «شناسانگر عالی مترجم‌های غیربهینه‌ساز» نگریست. امّا آنچنان که کارهای رَندل، آیرونز، فویرتسیگ و دیگران نشان می‌دهد، سبک عمومیّت بخشی دایکسترا، با وجودی که تأثیرگذار بود، نتوانست سبک کارایی‌محور را کنار بزند. در واقع، از جنبۀ عملی، دوگانگی بعد از تلاش‌های الگول60 نیز ادامه یافت.