روزهای پایانی قانون مور و نیاز به رویکردهای تازه در برنامه‌نویسی

آی‌تی‌من- قانون مور در طول سال‌ها برای صنعت کامپیوتر، همان نقشی را داشت که قوانین نیوتون برای مهندسان مکانیک؛ با این تفاوت که قانون مور حاصل برآوردی تجربی بود که در یک دوره خاص زمانی از تاریخ به دست آمد و ما رفته رفته به مرزهای کاربرد این قانون نزدیک شده‌ایم.
 
خود مور در سال 2010 پیش‌بینی کرد که قوانین فیزیک می‌تواند این رشد نمایی را با محدودیت مواجه کند. وی گفت: ترانزیستورها از نظر ابعاد دارند به اندازه یک اتم نزدیک می‌شوند. این اندازه یک محدودیت اساسی است. اما تا پیش از رسیدن به این محدودیت، 10 تا 20 سال دیگر زمان مانده است.
 
اکنون به سال 2020 رسیده‌ایم و این اعتقاد که ما همیشه سخت‌افزارهای رایانشی قدرتمند متناسب با نیازهای رو به گسترش خود خواهیم داشت، در حال رنگ باختن است. البته این وضعیت، چند دهه است که برای متخصصان صنعت رایانش قابل پیش‌بینی بوده و تحقیقات بسیاری برای یافتن راه‌های تازه افزایش قدرت پردازشی ماشین‌ها در جریان بوده است؛ معماری چند هسته‌ای نیز که در آن  یک CPU دارای دو یا چند واحد پردازش مجزا با نام هسته‌ است، با هدف به تعویق انداختن روزی طراحی شد که تراشه‌های سیلیکونی بالاخره به پایان راه برسند. برای مثال کامپیوتر مک‌پرو جدید اپل دارای پردازشگر اینتل زئون 28 هسته‌ای است. از سوی دیگر، تحقیقات جدی در زمینه رایانش کوانتومی نیز درجریان است که می‌تواند به یک پیشرفت چشمگیر در توان پردازشی منجر شود.
 
اما توان سخت‌افزاری، تنها عامل مهم در رایانش نیست و در این زمینه نرم‌افزارها هم نقش مهمی بازی می‌کنند. این در حالی است که قانون مور در طول زمان به نوعی موجب تنبل‌تر شدن برنامه نویسان شده است.
 
واقعیت این است که برنامه نویسی، فعالیتی هنرمندانه و ظریف است که برخی افراد در این زمینه، تواناتر از دیگران هستند و می‌توانند کدهای بهتر و از آن مهم‌تر، کم حجم (لاغر) بنویسند که سریع‌تر هم اجرا شود.
 
در سال‌هایی که سخت‌افزارها چندان پیشرفته و پیچیده نبودند، این هنرمندی واقعا اهمیت داشت. وقتی بیل گیتس پسربچه‌ای بیش نبود، برای کامپیوتر TRS-80 یک مفسر بیسیک نوشت و از آنجا که این میکروکامپیوتر حافظه بسیار کم حجمی داشت، گیتس مجبور بود این مفسر را در حجم 16 کیلوبایت بنویسد. او این مفسر را به زبان اسمبلی نوشت تا کارایی آن را افزایش دهد و در عین حال فضای کمی هم اشغال کند. گفته می‌شود که تا سال‌ها بعد، بیل گیتس کل این برنامه را خط به خط از بر بود.
 
هزاران داستان مانند این از روزهای اولیه رایانش می‌توان مثال زد. اما به لطف قانون مور، نیاز به نوشتن برنامه‌های کم حجم به تدریج از بین رفت و اولویت‌ها تغییر کرد. برنامه نویسی که روزی مانند صنایع دستی، به استادکارهای خلاق و زبردست وابسته بود، رفته رفته در قالب مهندسی نرم‌افزار، صنعتی شد. ساخت اکوسیستم‌های نرم‌افزاری گسترده، مانند سیستم‌عامل‌‌ها و اپلیکیشن‌های تجاری به تیم‌های بزرگی از توسعه دهندگان نیاز داشت. سپس فرایندهای بوروکراتیک به ماجرا وارد شد و به این ترتیب مدیرپروژه‌ها و مدیران اجرایی پا به میدان گذاشتند. پروژه‌های بزرگ نرم‌افزاری به چیزی تبدیل شدند که در کتاب پرفروش فرد بروکس از آن با نام «راهپیمایی مرگ» نام برده شده است. در این فرایند، نرم افزار تبدیل به چیزی متورم و پر حجم و اغلب ناکارآ تبدیل شد. کتاب بروکس با نام «نفر-ماه اسطوره‌ای» در سال 1975 منتشر شد و پس از آن مرتب تجدید چاپ شده است، زیرا هنوز هم مرجعیت دارد.
 
اما از آنجا که سخت‌افزار همیشه قدرت پردازشی زیادی ارایه می‌کرد که موجب پنهان ماندن نقاط ضعف نرم‌افزارهای متورم می‌شد، این مساله چندان اهمیتی نداشت. اما برنامه‌نویسان با وجدان همواره از این وضعیت ناراضی و ناراحت بوده‌اند. یکی از این برنامه‌نویسان روزی نوشت: تنها نتیجه سخت‌افزارهای قدرتمند این بوده که برنامه نویسان، روز به روز نرم‌افزارهای چاق‌تری روی آن سوار کرده‌اند. آنها تنبل‌تر شده‌اند، زیرا سخت‌افزارهای آنقدر سریع‌اند که دیگر لازم نیست برنامه نویسان برای یادگیری الگوریتم‌ها یا برای بهینه‌سازی کدهای‌شان تلاش کنند. این مسخره است.
 
ناتان میرولد (Nathan Myhrvold) که روزی مدیر ارشد فناوری بیل گیتس بود، در سال 1997 در یک سخنرانی، چهار قانون نرم‌افزار را به این شرح ارایه کرد: 1- نرم‌افزار مانند گاز است و برای پر کردن ظرف خود گسترش می‌یابد. 2- نرم‌افزار تا جایی که با قانون مور محدود شود، بزرگ می‌شود. 3- رشد نرم‌افزار موجب تحقق قانون مور می‌شود؛ مردم سخت‌افزار جدید می‌خرند چون برای اجرای نرم افزارها به آن نیاز دارند. و در نهایت 4- تنها مرز نرم‌افزار فقط جاه طلبی و انتظارات بشر است.

حالا که قانون مور به پایان دوره فرمانروایی‌اش نزدیک می‌شود، بر اساس قوانین میرولد ما فقط دو گزینه داریم. یا جاه‌طلبی‌مان را کنترل کنیم یا به روزهای برنامه‌نویسی کم حجم و کارآتر بازگردیم. به بیان دیگر، باید بازگشت به آینده بکنیم.