"اگر به پرتگاه خیره شوید، پرتگاه نیز به شما خیره خواهد شد." "کسی که با هیولاها می جنگد باید مراقب باشد که خود تبدیل به هیولا نشود." فردریک نیچه (ترجمه نادقیق خودم).
سال ها است که به این نتیجه رسیده ام که هنگامی که ما یک تکنولوژی را برای انجام کاری انتخاب می کنیم، فرای از ویژگی های موجود در تکنولوژی و شهرت آن باید در آن بنگریم. تکنولوژی ها شکل فلسفه سازندگانشان را می گیرند و آن را دنبال می کنند. رویکرد سازندگان نه تنها در خود تکنولوژی بلکه در اکوسیستم اطراف آن نیز اثر شگرفی می گذارد.
اگر خوب نگاه کنید، در C++, Erlang و ... ویژگی های خاصی را می یابید. سازندگان Erlang به تحمل خطا و Fault Tolerance می اندیشیدند و در نتیجه تمرکز زبان بر روی این موضوع است. CPU از Process ها به شکل خودکار گرفته می شود. سعی بالایی برای کم کردن احتمال Crash در VM شده است و همه کتابخانه های متعلق به Erlang بر روی Scalability و Fault Tolerance متمرکز هستند. در مقابل در سی پلاس پلاس تمرکز بر روی نزدیکی به سخت افزار، وجود کنترل کاملبر روی همه چیز و پرداخت هزینه فقط برای چیزهایی است که استفاده می کنید. همچنین تمرکز بالایی روی کارایی و performance وجود دارد و در نتیجه کتابخانه های بدون allocation و بسیار پیچیده و با کارایی بالا در اطراف آن زیاد یافت می شود.
این موضوع در مورد Unity, Unreal Engine, Nodejs, Orleans, F#, Linux و ... نیز صدق می کند. فقط کافی است سعی کنید از این زاویه به این تکنولوژی ها نگاه کنید تا فلسفه پشت آن ها را در یابید. گاهی هم باید کمی علوم کامپیوتر و تاریخ آن را بشناسید. به این دلیل من فکر می کنم بسیار مهم است فلسفه چیزی که شما می سازید به تکنولوژی مورد استفاده شما نزدیک باشد. این موضوع باعث می شود که چیزی که شما می سازید هم شکل درستی داشته باشد. در IBM و Google تحقیقاتی در رابطه با میزان productivity افراد هنگام کد زدن با زبان های مختلف انجام دادند که نشان داد نوشتن کد در C می تواند به اندازه نوشتن کد در Python سریع باشد. این موضوع مطلبی جدا از این است که آیا با Python هم شما می توانید برنامه ای به کارایی برنامه C بنویسید و اگر پاسخ مثبت است ، این کار چه قدر زحمت دارد. من فکر می کنم هنگام نوشتن سرور یک بازی RealTime که قرار است بسیار سریع باشد، اگر از تکنولوژی هایی استفاده کنید که با تمرکز بر روی این موضوع ساخته نشده اند و قابلیت های پایه آن ها بر این موضوع متمرکز نیست یا شما فلسفه اشتباهی را دنبال می کنید و متوجه موضوع اصلی مورد تمرکز نیستید و به تحقیق بیشتر نیاز دارید و یا کارتان با تکنولوژی مورد نظر به مشکل خواهد خورد.
مثلا شما می توانید با C کد gameplay بنویسید ، البته برای سادگی بهتر است کامپایلر یک نسخه ساده از C را طراحی کنید. می توانید با NodeJs یک برنامه بسیاری سریع scalable و distributed بنویسید در صورتی که ساختار ها و abstraction های لازم را در یک پلاگین با سی پلاس پلاس پیاده کنید. اما در این صورت شما با C و NodeJs کار نمی کنید. از خیلی از ابزار ها و دانش موجود در جامعه کاربران زبان نمی توانید استفاده کنید و باید برای خود یک سری استاندارد و ساختار و framework مخصوص داشته باشید. فیسبوک کد PHP محدود خود را که به سی پلاس پسال کامپایل می کند به این شکل تولید می کند. نوشتن این کد PHP شبیه همه کد های PHP بیرون فیسبوک نیست. چون فیسبوک شرکتی بسیار بزرگ با برنامه نویس های بسیار خوب است می تواند این کار را راحتتر از بقیه انجام دهد و عملا هم بیشتر کد خود را دیگر با PHP نمی نویسد. در مقابل وقیت شما با Erlang نرم افزار سرور و با سی پلاس پلاس Game Engine می نویسید، احساس می کنید در خانه خود هستید و همه تکنولوژی به سمت درستی جلو می رود و همه به زبان شما صحبت می کنند و همه ابزار ها قابل استفاده هستند و کار شما بسیار با کیفیتتر و بهتر و سریعتر جلو می رود. علاقه مندم نظرات شما را در این باره بدانم.
حتی در نرم افزار هایی مثل سیستم های عامل و رویکرد شرکت ها هم می توانید این موضوع را ببینید. معمولا دید و فلسفه افراد سازنده کاملا شکل دهنده اکوسیستم یک نرم افزار خواهد بود. دلیل توجه فراوان به رابط کاربری و طبیعی بودن همه چیز در OSX و سیستم عامل های قدیمی Apple دید خود استیو جابز و افراد اصلی دیگر در Apple بودند. من شک دارم استیو جابز هرگز می توانست یک برنامه خشک مهندسی با تمرکز روی performance را که قرار است کار خاص خطرناکی را انجام دهد رهبری کند و در مقابل شک ندارم او در توانایی نسل بعد نرم افزار های ارایه محتوی در دوران social network ها و یا شاید سخت افزاری خاص برای کار با آن ها و زندگی در این دوره یکی از بهترین گزینه ها بود. این موضوع در باره افراد دیگر و فلسفه هایشان هم از نظرم صادق است. فکر می کنم ما باید هنگام انتخاب تکنولوژی فلسفه و قابلیت های اصلی تکنولوژی را با چیزی که می خواهیم بسازیم مطابقت دهیم و هرگز از تکنولوژی هایی که برای کارهای متفاوت از نظر ویژگی های اصلی هستند برای کار های نا مربوط استفاده کنیم. وقتی می گویم هرگز، بدین دلیل است که همواره با سیستمی sub-optimal رو به رو خواهیم بود که دلیل ساخته شدنش به روشی خاص آشنایی ما با یک تکنولوژی یا علاقه کورکورانه بوده است.
یک بار ما در MuchDifferent به علت آشنایی اعضای شروع کننده یک پروژه سرور licensing برای تمام محصولاتمان، با PHP و Python ، این سرور را با PHP و یک بار با Python نوشتیم و برای سریع کردن آن به حد نیاز باید کارهای خاصی می کردیم و از کش استفاده می کردیم و ... اما همین سرویس با ASP.NET بر روی Owin توسط افرادی دیگر به سرعت نوشته شد و کاملا جواب گوی تعداد درخواست ها بود و لازم نبود ما برای سریع شدنش کار خاصی نیز انجام دهیم. بسیاری افراد با Django سایت های بسیار بزرگ می نویسند و حتی API می نویسند ولی به طور کلی DJango برای ساخت سایت های forms over data و line of business و ... مناسب است و برای بالا رفتن سرعت باید از cache و تکنولوژی های دیگر استفاده کرد. در مقابل کد دات نت بسیار سریعتر بوده و شما به شکل پیش فرض از یک ORM نه چندان سریع استفاده نمی کنید و راه های زیادی برای سرعت بخشیدن به پاسخ گویی سرور وجود دارد که ساخت یک web service بسیار high performance را خیلی ساده تر می کند. شاید کسی در Python با زحمت فراوان و بدون استفاده از Django بتواند همین کار را بکند، اما آن وقت دیگر از سادگی های Django استفاده نکرده است و لزوما از سادگی های Python برای پروژه های کوچک هم بهره نبرده است. این فلسفه من است و تا به حال از آن سود فراوانی برده ام و دوست دارم نظرات دیگران را نیز در کامنت ها بدانم.
