چرا #c اینقدر خاطر خواه پیدا کرده؟

[آبجی]

در واقع #C یک زبان Pure Object-Oriented هست، یعنی فقط از برنامه نویسی شی گرا پشتیبانی میکنه. این “فقط” لزوما یک حسن محسوب نمیشه. البته درباره اش بحث هست، بعضی ها میگن چون برنامه نویس مجبور هست که شی گرا کار کنه، خوب هست. بعضی ها هم میگن عملا فرق چندانی نداره، چون همین الانش هم توی #C و جاوا برنامه نویسان به شکل گسترده ایی از Class function ها و Static Property ها استفاده می کنند، که میشه همون برنامه نویسی Structural سابق با یک روکش Object-Oriented. در واقع اجبار برنامه نویس به اینکه حتما همه چیز را در کلاس ها تعریف کنه، میتونه انگیزه خوبی باشه که برنامه نویس OOP یاد بگیره، ولی نمیتونه اون فرد را لزوما برنامه نویس شی گرا کنه، مثلا همین الان میتونید بین کاربران ایرانی #C یک آزمون برگزاری کنید و ببینید چند نفرشون واقعا با مفاهیم شی گرایی آشنا هستند، چند نفرشون همینطوری یک چیزهایی یاد گرفتند و هنوز هم تعریف دقیق از کلاس، Interface، وراثت، و… بلد نیستند.

[آبجی]

اون چیزی که باعث محبوبیت #C شد، در وهله اول خود شرکت مایکروسافت بود. ببین قبل از اینکه دات نت بیاد، اوضاع جامعه برنامه نویسی در سکوی ویندوز به چه شکل بود؟ تعداد بسیار بسیار زیادی برنامه نویس VB وجود داشت، در کنار آنها هم تعداد زیادی برنامه نویس ++Visual C. محیط توسعه ایی مثل دلفی با اینکه پرطرفدار بود، ولی به نسبت این دو زبان که در قالب محیط توسعه ایی بنام Visual Studio عرضه میشند، اقلیت محسوب میشد. این زبان ها در برابر دلفی حرفی برای گفتن نداشتند، چون دلفی تمام قابلیت های Visual C++ بجز درایور نویسی سطح کرنل داشت، یک محیط توسعه کاملا RAD بود، و برنامه نویسانش نیاز نداشتند مثل برنامه نویسان VC++ برای ایجاد رابط کاربر مشقت بکشند، یا از تلفیق VB و ++VC استفاده کنند. دلفی یک کتابخانه کاملا شی گرا داشت که بسیاری از توابع API ویندوز را در قالب کلاس های مختلف ارائه می کرد، در کنار آن، به برنامه نویس اجازه می داد که در صورت تمایل این کتابخانه را دور بزند، و مستقیما با توابع API کار کند، دلفی از COM و Corba پشتیبانی می کرد، کدهای تولید شده توسط کامپایلر آن فوق العاده Optimized بودند و کارایی در حد کدهای VC++ ارائه می کردند. اما دو نکته درباره دلفی وجود داشت که مانع از این می شد که بسیاری از برنامه نویسان ++VC به آن گرایش پیدا کنند:
۱- Syntax پاسکال: سالها بود که برنامه نویسان حرفه ایی عادت کرده بودند که هر زبان برنامه نویسی جدیی را با Syntax زبان C ببینند. اصولا پاسکال همیشه یک زبان دانشگاهی بود، نه یک زبان حرفه ایی. این آندرس هلزبرگ بود که با ارائه Turbo Pascal توانسته بود پاسکال را احیا کند، اما آن زمان فرصتی برای ترغیب برنامه نویسان حرفه ایی به استفاده از Syntax پاسکال وجود نداشت. دلفی هم از همان Syntax استفاده می کرد، و این برای بسیاری از برنامه نویسان C و VC++ غیرقابل قبول بود. این افراد دچار نوعی تعصب شدید روی Syntax زبان C بودند و هر چیزی که Syntax مشابهی نداشت را با VB مقایسه می کردند! کار بجایی کشید که حتی بورلند مجبور شد نسخه ایی از دلفی با Syntax زبان ++C عرضه کند، اما این نسخه چندان موفق نبود، چون عملا برای هر کاری به دلفی وابسته بود.
۲- قیمت: کل مجموعه Visual Studio بسیار ارزانتر از دلفی بود، در نتیجه امکان اینکه افرادی بتوانند محیط آن و قابلیت هایش را تجربه کنند، و سپس به خرید آن بپردازند، چندان مهیا نبود.
علاوه بر این دو عامل اصلی، پشتیبانی های مایکروسافت از دو زبان ساخت خودش هم قابل توجه بود، مثلا در اغلب موارد برنامه نویسان VC++ دغدغه نصب Runtime زبان برنامه نویسی خودشان در سیستم عامل مقصد را نداشتند، چون مایکروسافت آن را خود به خود به سیستم عامل های خود اضافه می کرد. بسیاری از قابلیت های مورد نیاز آنها به همین شکل در ویندوز تعبیه میشد.
اما در اواخر دهه نود قرن بیستم دلفی به یک خطر واقعی تبدیل شده بود؛ IDE ارائه شده توسط مایکروسافت حرفی برای گفتن در برابر IDE دلفی نداشت، دلفی معماری یکپارچه ایی برای کار با بانک های اطلاعاتی در کتابخانه خود داشت که به آن امکان می داد با هر نوع بانک اطلاعاتی کار کند، بدون آنکه برنامه نویس درگیر جزئیات متفاوت این بانک ها شود. از طرفی دلفی امکانات بسیار زیادی برای توسعه سیستم های Enterprise عرضه می کرد. برنامه نویسان می توانستند به راحتی از چارچوب ارائه شده برای ساخت نرم افزارهای n-tier استفاده کنند، پشتیبانی از XML، و Transform کردن داده های XML به قالب های مختلف، پشتیبانی از ساخت انواع Web Application، امکانات وسیع در زمینه توسعه کامپوننت های جدید، همگی از مزایای بودند که برنامه نویسان ++VC غالبا از آنها بی بهره بودند. در واقع برنامه نویسان ++VC برای داشتن همچین قابلیت هایی یا باید کتابخانه های گرانقیمتی را خریداری می کردند، یا خودشان سالها به توسعه کتابخانه هایشان می پرداختند. در همچین شرایطی، تنها عاملی که موجب فروش بیشتر مایکروسافت میشد، عدم آشنایی بسیاری از مشتریان مایکروسافت با دلفی بود.
در همچین شرایطی مایکروسافت بخوبی متوجه جهت گیری درست دلفی شد، پس سعی کرد در همان سمت قدمهای اساسی بردارد. برای این کار در اولین قدم برنامه نویسان اصلی دلفی، و از جمله اندرس هلزبرگ با قیمت های بسیار بالا خریداری شدند. کار بجایی کشید که بورلند به دادگاه شکایت کرد، ولی مایکروسافت در یک توافق محرمانه که هیچ وقت افشاء نشد، نه تنها بورلند را از شکایت منصرف کرد، بلکه پروژه های موجود در لابراتورهای بورلند را نیز خریداری کرد!
اندرس هلزبرگ مامور ساخت نسخه ایی مایکروسافتی از جاوا شد. محصول مربوطه ساخته شد، ولی هیچ وقت محبوبیت گسترده ایی پیدا نکرد. بالافاصله اندرس هلزبرگ به عنوان یکی از برجسته ترین طراحان محصول جدید مایکروسافت مشغول به کار شد. محصولی که شباهت های بسیار زیادی به دو کار قبلی هلزبرگ شباهت داشت؛ دلفی، و جاوا. کتابخانه ایی مشابه VCL دلفی طراحی شد، ولی با توجه به اینکه تقریبا یک دهه از طرح اولیه VCL می گذشت، طرح جدید فقط از نکات مثبت آن بهره برداری کرد، البته کتابخانه جدید بسیار گسترده تر از VCL طراحی شد. زبانی هم مشابه زبان جاوا ایجاد شد که بسیاری از نکات مثبت جاوا و دلفی را با هم ادغام می کرد. سکویی هم برای افزایش نفوذ ویندوز، و مقابله با نفوذ گسترده جاوا طراحی شد که دقیقا نقطه مقابل پلت فرم جاوا (نه فقط زبان جاوا) قرار می گرفت.
محصول جدید عرضه شد، ولی باید برای آن مشتریانی فراهم میشد. VB دارای کاربران بسیاری بود که باید کاربرانش قربانی محصول جدید می شدند. نرم افزاری که به اصطلاح نسخه جدید VB بود، چنان متفاوت از نسخه های پیشین بود که برنامه نویسان VB برای یادگیری آن باید تقریبا تمام دانش فعلی خود در زمینه زبان VB را دور می ریختند. این امر باعث شد که عمده ترین مشتریان محصولات برنامه نویسی مایکروسافت در یک بزرخ واقعی بگیرند. سالها بود که مایکروسافت در VB بسیاری از امور را برای آنها ساده کرده بود، و برنامه نویسان VB با بسیاری از مفاهیم موجود در سایر زبان های برنامه نویسی آشنا نبودند. این افراد یا باید سراغ یک محیط توسعه جدید می رفتند، یا مسیری که مایکروسافت پیش روی آنها گذاشته بود را قبول می کردند. اکثرا راه حل دوم را انتخاب کردند، چون هر چند VB.Net خیلی با VB متفاوت بود، ولی شباهت های آن با VB بیشتر از دلفی یا ++C بود.
گروه دوم برنامه نویسان ++VC بودند. راضی کردن این گروه کار آسانی نبود، این افراد میلیون ها خط کد در ++VC داشتند، و تعداد بسیاری کتابخانه برای کارهایمختلف خود تهیه کرده بودند. مایکروسافت سعی کرد از یک طرف برای مدتی سرنوشت ++VC را در هاله ایی از ابهام قرار بده. برای مدتی برنامه نویسان ++VC از اینکه نسخه جدیدی تحت Win32 عرضه شود، نا امید شده بودند؛ از طرف دیگه مایکروسافت امکانات بسیار بهتری برای مهاجرت برنامه نویسان ++VC مهیا کرده بود، پس بالاخره تعداد بسیاری از برنامه نویسان ++VC تصمیم به مهاجرت به دات نت گرفتند.
بحث جایگزین شدن دات نت با Win32 هم توانست عده ایی را که هنوز مطمئن نبودند، به سمت دات نت بکشاند.
ولی یک دلیل عمده دیگه هم دخیل بود، افزایش روز افزون برنامه های تحت وب، و قابلیت های ASP.Net. نیاز به توسعه نرم افزارهای تحت وب از جمله عوامل اصلی بود که برنامه نویسان سکوی ویندوز را به سمت ASP.Net و خودِ سکوی دات نت می کشاند. در واقع بسیاری از افرادی که حاضر نبودند دات نت را به عنوان جایگزینی برای Win32 در عرصه دسکتاپ قبول کنند، فقط بخاطر ASP.Net به سمت دات نت گرایش پیدا کردند.
به تدریج با عرضه نسخه های بعدی دات نت فریم ورک امکانات بیشتری به دات نت اضافه شد. در کتابخانه کلاس ها عملا برای هر کاری کلاسی پیدا میشد، JIT کارایی بهتری پیدا کرد، و سخت افزارها سرعتشان بیشتر شد، بطوری که تفاوت سرعت کدهای دات نت با کدهای Native در نرم افزارهای مختلف (بخصوص Enterprise) هر روز کمتر و کمتر شد. مایکروسافت هم از یک طرف سرمایه گزاری عظیمی روی مستندات و منابع دات نت کرد، و از طرف دیگه به هر بهانه ایی و با هر نرم افزاری دات نت فریم ورک را روی سیستم کاربران نصب کرد تا دغدغه لزوم نصب فریم ورک بر روی سیستم مقصد هم تا حدودی کاهش پیدا کند. IDE مربوطه (Visual Studio) هم پیشرفت قابل ملاحظه ایی کرد، چه از نظر امکانات، و چه از نظر کارایی. سیاست های مایکروسافت هم تضمین می کرد که در عرصه داد نت نرم افزاری نخواهد توانست روی دست Visual Studio بلند شود. سیاست هایی مثل گره زدن کدهای Designer مربوط به Compact Editon به IDE، یا ممنوعیت استفاده سایر IDEها از نسخه های بتای فریم ورک در شرایطی که Visual Studio امکان این کار را داشت.
در نسخه های ۳/۰ و ۳/۵ مایکروسافت عملا کاربران را با قابلیت های جدید بمباران کرد، حتی قابلیت هایی که بعضا به نوعی رقیب سایرین محسوب میشدند مثل WFC دربرابر WinForms، یا Indigo دربرابر .Net Remoting. اگر تا قبل از این بسیاری از قابلیت های دات نت به شکل های دیگه در سایر سکوها هم پیدا میشد، با عرضه این نسخه قابلیت هایی ارائه شد که رقبایی در سایر سکوها نداشتند.
با تکامل دات نت #C و تکامل پیدا کرد. توسعه #C تاثیر مستقیمی روی سایر زبان های دات نتی و توسعه خودِ دات نت داره، چون وقتی قابلیتی به #C اضافه میشه، یعنی در اغلب موارد اون قابلیت برای سایر زبان ها هم قابل استفاده خواهد بود. “در اغلب موارد” چون مایکروسافت برای حفظ پیشتازی #C اجازه استفاده از بعضی از قابلیت ها را با تاخیر میده، یا برخی را فقط منحصر به #C میکنه.
امروزه هنوز برنامه نویسی Win32 کاربردهای خودش را داره، و خیلی زود هست که بخوایم آن را بازنشته بدانیم، چون هنوز ویندوز و بسیاری از نرم افزارهای نوشته شده برای ویندوز به آن وابسته هستند، و شاید تا یک دهه آینده هم همچنان وابسته باقی بمانند. ولی نقش دات نت در توسعه نرم افزار در سکوی دات نت هر روز پر رنگ تر میشه، و هر روز هو قابلیت های بیشتری به آن اضافه میشه تا برنامه نویسان بیشتری جذب آن شوند.
با این تفاسیر، این دات نت هست #C را زبان مهمی کرده. #C یک زبان مدرن هست، ویژگی های زبانی خوبی هم داره، ولی بسیاری از این ویژگی ها در سایر زبان های دات نتی و غیر دات نتی هم وجود داره، اما قابلیت های دات نت باعث تمایز #C از زبان های غیر دات نتی میشه، و در عرصه زبان های دات نتی هم حمایت بی دریغ صاحب سکوی دات نت از آن باعث میشه که حرف اول را بزنه. هر چقدر هم که به نظرت Syntax زبانی مثل دلفی در دات نت بهتر از #C به نظر برسه، باز هم مجبوری برای مطالعه سورس کدهای منتشر شده دات نت فریم ورک، و مستندات مایکروسافت، و بررسی قابلیت های جدید دات نتی که هنوز در مرحله بتا هستند، با #C آشنا باشی. زمانی اگر برنامه نویس C نبودی، و می خواستی برای ویندوز برنامه نویسی کنی، باید حداقل با Data-Typeهای C و فایل های Header آن آشنا می بودی، اما در دات نت بیش از اینها باید با #C آشنا باشی تا بتونی گلیمت را از آب بیرون بکشی.
البته یادگیری دات نت و #C برای تو که با دلفی آشنا هستی، کار سختی نیست. فعلا دات نت را بورلندی ها در مایکروسافت می چرخانند، پس در آن ایده های آشنای زیادی خواهی دید. اندرس هلزبرگ روی #C کار میکنه، استیو تیشیرا هم روی Visual C++.net کار میکنه؛ همون استیو تیشیرایی که سال ها کتاب Delphi 6 Developer’s Guide اش را به عنوان مرجع دلفی در کنار کتاب Mastering Delphi مارکو کانتو استفاده می کردی. Chuck Jazdzewski هم که بعد از اندرس هلزبرگ به عنوان Chief Architect دلفی مشغول به کار بود، همون سال ها به مایکروسافت پیوست، ولی نمیدونم دقیقا روی چه محصولی کار میکنه. بعید نیست که این هم روی بخشی از دات نت مشغول باشه، سایر بورلندی ها هم در مسئولیت های جزئی تر مشغول هستند.
نکته ایی که مهم هست اینه که خیلی به سابقه ۳-۵ ساله برای استخدام توجه نکن! دات نت یک تیغ دولبه داره، اون هم سادگی و گستردگی کتابخانه کلاس هاش هست. برنامه نویس مبتدی جذب دات نت میشه، چون میبینه با چند خط کد ساده میتونه کارهای عجیب غریبی بکنه که قبلا یک برنامه نویس مجرب به سادگی از عهده اش برنمیامد. برنامه نویس مجرب هم جذب دات نت میشه، چون میینه خیلی از اموری که باید برایشان مدتها وقت میگذاشت، برایش از قبل آماده شدند، و او باید فقط روی منطق برنامه قابلیت های جدیدی که باید اضافه کند، متمرکز شود. برنامه نویس مجرب استفاده خودش را می کند، اما برنامه نویس مبتدی چون آشنایی مناسبی با اشیاء استفاده شده نداره، بعد از مدتی یا خودش دچار مشکل میشه، یا برای دیگران مشکلات بزرگی تولید میکنه. در حوزه دات نت هم از این مدل برنامه نویسان مبتدی بسیار زیاد هستند، افرادی که چندین سال در کار با دات نت سابقه دارند، ولی هنوز حتی اطلاع دقیقی از چگونگی کارکرد کدی که خودشان نوشتند ندارند! برنامه نویس مجربی که به تازگی قصد کار در دات نت را داشته باشد، هر چند سابقه کمی در دات نت دارد، ولی به راحتی می تواند همچین برنامه نویسانی را کنار بزند، و پست مورد نظر را به خودش اختصاص دهد، البته اگر معیار گرفتن آن پست مهارت های فنی فرد باشد، نه چیزهای دیگه!
به عنوان نمونه، در دات نت مثل دلفی کلاسی برای کپسوله کردن مفهوم Thread و کار کردن با آن در نظر گرفته شده. کار کردن با کلاس مربوطه در دات نت آسانتر از کلاس TThread دلفی هست. از طرفی چون کامپایل نهایی در دات نت توسط JIT و روی سیستم کاربر انجام میشه، دات نت این امکان را هم داره که کدهای نوشته شده را بدون دخالت برنامه نویس، برای Multi-threading بهینه کنه. خب، خیلی ها را هم می بینی که در عرصه دات نت از این قابلیت استفاده می کنند. در Win32 هر کسی جرات نوشتن برنامه های Multi-threaded نداشت، و سعی میشد اگر بهش در برنامه نیازی نیست، بیخودی توسعه پروژه بخاطر استفاده از Threadهای مختلف و مشکلات استفاده از آنها، پیچیده نشه. ولی در دات نت خیلی ها همینطوری ازش استفاده می کنند، البته برنامه نویس خوب و مجرب هم هستند، ولی غالبا اطلاع دقیقی از Threading ندارند، فقط میدونند که چیزی هست که موجب افزایش سرعت برنامه هاشون میشه. تو با توجه به پس زمینه ایی که از Win32 داری، وقتی وارد عرصه دات نت میشی، روی بحث Threading وقت زیادی صرف میکنی، و در استفاده کردن ازش دقت میکنی، ولی مبینی فرد دیگری که چند سال از تو سابقه بیشتری داره، از Thread در برنامه اش استفاده کرده، ولی هنوز نمیدونه که وقتی کنترلی در یک Thread ساخته میشه، باید فقط توسط همون Thread تغییر کنه، و Threadهای دیگه نباید مستقیما اونو تغییر بدند. این برنامه نویس ببخاطر کم اطلاعی اش با خطای کامپایلر #C مواجه میشه که بهش میگه این کار خطرناکه و نباید این کار را بکنه. اما مبینی یک برنامه نویس دیگه که با سابقه تر از برنامه نویس اولی هست، میاد و بجای اینکه بهش بگه چرا نباید این کار را بکنه، بهش یاد میده که چطوری یک خصوصیت خاص را تنظیم بکنه، تا دیگه کامپایلر #C برای همچین موضوع بیخودی (!!) بهش گیر نده و کدش کامپایل بشه. خب معلوم هست که این برنامه چند وقت بعد با مشکلات عجیب و غریبی روبرو میشه که دیباگ کردنشون کار حضرت فیل هست! با دیدن همچین صحنه هایی در دات نت، به خودت امیدواری میشی، و احساس نمیکنی که خیلی از عموم کاربران فعلی دات نت عقب هستی.