COMPΞZ 🧬

👌

if (problem == imaginary)
{
   stopOverthinking();
}

Often, the situation itself isn't the real problem; it’s the scenarios we create in our minds that cause even more anxiety and inner conflict.

سال‌هاست که کتاب‌هام رو به‌روز رسانی نکردم! یکی از ده‌ها دلیلش اینه که چند صد هزار صفحه پیش‌نویسه و محتوا در هر یک از استاندارد‌های زبان وجود داره که غیر ممکنه همشو بتونی کامل درک کنی تجربه کنی و بعد بخوای آموزشش بدی. یعنی حتی بخوای یه جلد ساده تألیف کنی باز هم سخته! برای همین من بیشتر روی آموزش خود Qt تمرکز کرده بودم. اگه هر زبان دیگه‌ای بود ساده‌تر بود اما سی‌پلاس‌پلاس یک هیولاست و به این راحتی‌ها نمی‌شه علمش رو انتقال داد و با کمال‌گرایی که من دارم نوشتن همچین کتابی بسیار زمان‌بر هست. در اصل تألیف یک کتاب نیاز به زمان و ساده‌سازی بر مبنای تجربه داره و اگه بعد از سال‌ها می‌خوام نسخه‌های جدید‌تری بنویسم یا قبلی‌ها رو به‌روز رسانی کنم کاملاً طبیعیه که عجله‌ای توش نداشته باشم. در کل سخت هست هم به‌روز نگه‌داشتن و هم پوشش دادن مباحثی که از درون پیچیدگی‌ها باید بیاد ساده‌سازی بشه. از طرفی کتاب‌های قبلی من همرو با روش سنتی تحت word نوشته بودم! از نظر نوشتاری برای من ساده بود اما از نظر نگه‌داری به شدت سخت! برای همین نسخه‌های جدید رو کامل به روش LaTex باز نویسی می‌کنم و نوشتن کتاب در ساختار همچین معماری یعنی برنامه‌نویسی کامل! در مورد لاتکس تحقیق کنید خواهید دید چقدر پیچیدست ولی در عین حال خروجیش چه خواهد بود. اینطوری نیست یعنی بشینم متن بنویسم تایپ کنم بگم تموم شد! باید ساختار صفر تا صد کتاب برنامه‌نویسی بشه که در نهایت کیفیت خروجی بسیار بالاست و برای هر نوع روش مطالعه از دیجیتالی گرفته تا نسخه‌های چاپی منعطف و سازگار خواهد بود.

بله تو فکرش هستم؛ چون این IDM از تورنت و بلاک‌چین هم پشتیبانی می‌کنه، افزونه‌ای که قراره براش ساخته بشه طبیعتاً مقداری پیچیده‌تر از انواع کلاسیک خواهد بود باید برای پروتکل‌هایی مثل فارکستر و ipfs و دیگر موارد بهینه‌سازی بشه.

بله متأسفانه به خاطر قطعی و از بین رفتن دسترسی ما به سرور، سایت iostream.ir کامل خاموش شد و بازیابی و نگه‌داریش فعلاً صرفهٔ اقتصادی نداره. اما مدتیه که در حال بازنویسی هر دو کتاب سی++ و کیوت هستم با استاندارد و نسخه‌های جدید‌تر و با کیفیت بسیار بهتر از قبل. 🫡 بعد از به‌روز رسانی کامل وب‌سایت با ساختار و تجربهٔ بهتری بازسازی خواهد شد.

زمانی Simula 67 نخستین زبان برنامه‌نویسی شیءگرای جهان بود. اگرچه این زبان اغلب زیر سایهٔ Smalltalk قرار می‌گیرد؛ زبانی که برنامه‌نویسی شیءگرا را فراگیر کرد و حتی اصطلاح «برنامه‌نویسی شیءگرا» را رواج داد، اما بسیاری از پایه‌های زبان‌های شیءگرای امروزی نخستین‌بار در Simula شکل گرفتند. مفاهیمی مانند کلاس، شیء، وراثت و فراخوانی پویا را معرفی کرد؛ مفاهیمی که همچنان از ارکان اصلی برنامه‌نویسی شیءگرا محسوب می‌شوند. بیارنه استراستروپ نخستین‌بار زمانی که دانشجوی دانشگاه آرهوس بود با Simula آشنا شد. او برنامه‌نویسی شیءگرا را مستقیماً از کریستن نیگارد آموخت؛ یکی از سازندگان Simula که این زبان را همراه با اوله-یوهان دال طراحی کرده بود. استراستروپ بارها توضیح داده است که این تجربه تأثیر عمیقی بر دیدگاه او نسبت به طراحی زبان‌های برنامه‌نویسی گذاشت. زمانی که او بعدها «C with Classes» و در نهایت ++C را توسعه داد، هدفش این بود که قدرت Simula در ایجاد انتزاع‌های سطح‌بالا را با کارایی، انعطاف‌پذیری و کنترل سطح‌پایین زبان C ترکیب کند. کمتر زبانی به‌اندازهٔ Simula بر طراحی ++C تأثیر گذاشته است. هر زمان دربارهٔ زبان‌های برنامه‌نویسی فراموش‌شده صحبت می‌کنم، مردم معمولاً می‌پرسند این زبان‌ها واقعاً برای چه کاری استفاده می‌شدند و چرا اهمیت داشتند. پاسخ‌دادن به این پرسش همیشه آسان نیست، زیرا منابع تاریخی معمولاً کمیاب، پراکنده یا دسترسی به آن‌ها دشوار است. اما دربارهٔ Simula 67، ژرار لو لان اخیراً نمونه‌ای قابل‌توجه از تأثیر تاریخی آن را با من به اشتراک گذاشت: نقشی که این زبان در پژوهش‌های منتهی به شکل‌گیری پایه‌های اینترنت ایفا کرد. در سال ۱۹۷۲، ژرار لو لان در حال بررسی محدودیت‌های پروتکل ارتباطی میزبان‌به‌میزبان NCP در شبکهٔ ARPANET بود. او در فرانسه حضور داشت و نمی‌توانست مستقیماً روی شبکه آزمایش انجام دهد. خوشبختانه، مرکز رایانش دانشگاه رن یک رایانهٔ CII 10070 در اختیار داشت؛ نسخهٔ فرانسوی رایانهٔ XDS Sigma 7 که به کامپایلر Simula 67 مجهز بود. او با استفاده از Simula 67 یک شبیه‌سازی بزرگ‌مقیاس از پروتکل‌های ارتباطی ساخت. در این شبیه‌سازی، رویدادها دارای زمان‌بندی و شناسه‌های منحصربه‌فرد بودند. این قابلیت به او اجازه می‌داد وابستگی‌های علّی میان رویدادها را مشاهده کند و دقیقاً بفهمد وضعیت‌های نامطلوب چه زمانی و به چه دلیلی رخ می‌دهند. این شبیه‌سازی‌ها مشکلاتی مشابه مشکلات مشاهده‌شده در NCP را آشکار کردند و به لو لان کمک کردند سازوکار پنجرهٔ لغزان یا Sliding Window را توسعه دهد. پنجرهٔ لغزان یک تکنیک بنیادی است که بعدها در TCP و سامانه‌های ارتباطی قابل‌اعتماد امروزی به کار گرفته شد. وینت سرف، که در سال‌های ۱۹۷۳ تا ۱۹۷۴ ژرار لو لان را برای پیوستن به تیم خود در دانشگاه استنفورد دعوت کرده بود، بعدها نقش او را تأیید کرد و نوشت: «ما آن را از تو قرض گرفتیم.» او همچنین اصرار داشت نام ژرار لو لان روی لوح «تولد اینترنت» که در سال ۲۰۰۵ در دانشگاه استنفورد نصب شد، درج شود. این داستان یادآوری می‌کند که تاریخ زبان‌های برنامه‌نویسی فقط تاریخ زبان‌های مشهوری نیست که باقی ماندند؛ بلکه تاریخ ابزارهای فراموش‌شده‌ای نیز هست که زمینه‌ساز دستاوردهای بزرگ علمی و فناوری شدند. #cpp #oop #simula #تاریخچه

📌GenyDL v1.2.200 is now available! 🎉 Key improvements: ✔️ Full support for nine interface languages ✔️ Locale-aware numbers, dates, times, and units ✔️ Redesigned Release Center and GitHub asset picker ✔️ Improved download lists, menus, dialogs, and controls ✔️ Safer updates and improved file verification ✔️ Numerous performance, usability, and reliability improvements GenyDL is a free, open-source, and cross-platform download manager for macOS, Windows, and Linux. 🔗 Download GenyDL v1.2.200: 💻 macOS arm64 💻 macOS Intel 💻 Windows arm64 💻 Windows x86_64 💻 Linux arm64 💻 Linux x64_86 https://github.com/genyleap/genydl/releases/tag/v1.2.200

تا پیش از استاندارد CPP26، برای استفاده از پردازش برداری در CPP عملاً سه مسیر اصلی پیش رو داشتیم: ۱. حلقه‌های معمولی بنویسیم و به بهینه‌سازی خودکار کامپایلر امیدوار باشیم تا در صورت امکان، آن‌ها را به کد برداری تبدیل کند. ۲. مستقیماً از توابع و انواع ذاتیِ شناخته‌شده برای کامپایلر، مانند SSE، AVX یا NEON استفاده کنیم؛ روشی قدرتمند اما وابسته به معماری پردازنده و جزئیات سخت‌افزار. ۳. از افزونه‌های کامپایلر یا کتابخانه‌های جانبی برای ایجاد یک لایهٔ قابل‌حمل‌تر روی قابلیت‌های SIMD بهره بگیریم. مزیت اصلی std::simd این است که SIMD را از یک تکنیک وابسته به پردازنده، کامپایلر و کتابخانه‌های شخص ثالث، به یک مفهوم رسمی در کتابخانهٔ استاندارد CPP تبدیل می‌کند.

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

خب ویژگی SIMD رو هم روی GCC آزمایش کردم! در یک کلام فوق‌العادست!!! چه چیز‌هایی که به ذهنم رسید که می‌تونیم باهاش پیاده‌سازی کنیم. یعنی چنان بنچ‌مارک‌هایی می‌شه گرفت که پناه بر خدا! برای مثال، فرض بگیریم اگه بخوایم از std::simd در پروژهٔ CMS خودمون استفاده کنیم؛ چه مزیتی می‌تونه داشته باشه؟ مزیت اصلی یک CMS مبتنی بر SIMD این است که خواهد توانست با همان سخت‌افزار، دادهٔ بیشتری را سریع‌تر، با مصرف CPU کمتر و تأخیر پایدارتر پردازش کند. چنین چیزی در هیچ یک از سیستم‌های مدیریت وب نه وجود داشته، نه وجود داره و نه می‌تونه وجود داشته باشه! چون زبان اینجا بسیار مهمه که اجازه به شما بده با سخت‌افزار ارتباط مستقیم‌تری برقرار کنی. مزیت رقابتی واقعی اینطوریه: فرض کن دو CMS روی VPS یکسان اجرا می‌شه! یک سیستم مدیریت معمولی مثل ورد‌پرس: هر بار یک مقدار یا یک بایت را پردازش می‌کند. دوم تگرا: چند مقدار یا چندین بایت را به صورت بلوک‌های موازی و هم‌زمان پردازش می‌کند. نتیجهٔ بالقوه: ۱) درخواست بیشتر به ازای هر هستهٔ CPU ۲) زمان پاسخ کمتر در عملیات CPU-bound ۳) کاهش هزینهٔ سرور در مقیاس بالا ۴) پایداری بهتر زیر بار سنگین ۵) توانایی اجرای مناسب‌تر روی سرورهای کوچک، Edge و دستگاه‌های ARM و معماری‌های دیگر به‌طور خلاصه، مهم‌ترین مزیت استفاده از SIMD در CPP26 این است که نرم‌افزار بتواند با سخت‌افزار کمتر، حجم بیشتری از داده و عملیات را در زمان کوتاه‌تری پردازش کند. اگر معماری نرم‌افزار در کنار SIMD از پردازش موازی، اجرای هم‌زمان و غیرهم‌زمان، ورودی و خروجی غیرمسدودکننده و مدیریت بهینهٔ حافظه نیز بهره ببرد، نتیجه صرفاً یک برنامهٔ سریع‌تر نخواهد بود؛ بلکه محصولی با توان عملیاتی بالاتر، تأخیر کمتر، مصرف منابع پایین‌تر و پایداری بیشتر زیر بار سنگین خواهیم داشت. درواقع SIMD در چنین معماری‌ای به پردازنده اجازه می‌دهد یک عملیات یکسان را به‌جای اجرای جداگانه روی هر داده، به‌صورت هم‌زمان روی چندین داده انجام دهد. این قابلیت در پردازش تصویر، جست‌وجو، تحلیل داده، اعتبارسنجی متن، فشرده‌سازی، رمزنگاری و پردازش محتوای حجیم می‌تواند راندمان اجرای نرم‌افزار را به‌طور محسوسی افزایش دهد.

من یادم نمیره شاید ۷..۸ سالم بود، یه روز از میدان انقلاب شهر خودمون رد می‌شدیم وسط فلکه یه طناب دار دیدم داشتن آمادش می‌کردن واسهٔ اجرای حکم... اون موقع مامانم چشامو گرفت که نبینم... هنوز هم که هنوزه وقتی یادم می‌افته وحشت می‌کنم! یعنی تا بوده تجربیات تلخ توی جامعه دیدم. توی زندگی هم که بدترین نوعش رو تجربه کردم! همین چند سال پیش پدر مادر بزرگم رو به قتل رسوندن و حتی آتیششون زدن :) بعد ۵ سال هنوز نتونستیم رضایت برای اجرای حکم اعدامش بدیم! خشم و نفرت تو دل و ذهنمون وجود داره اما تصمیم گیری به این راحتی نیست! شماها چطور به این راحتی عین آب خوردن دارید اجراش می‌کنید؟ بابا این چه قانونیه... چه وضعیه؟ چه استدلالیه؟! یعنی هیچ تقصیری گردن شماها نیست دیگه نه؟ همینطوری یهو یکی از دل سیری و خوشی میاد جنایت می‌کنه؟ طرف اومد جنایت کرد، دلایلی که اعتراف کرده رو صد بار من شخصاً خوندم... تهش برگشته به اقتصاد، به نداری، به بدبختی! کینه و نفرت و حسادت! اینا باعث می‌شن یکی از شدت خشم دست به کاری بزنه که بهش می‌گن جنایت! مگر اینکه روانی باشه با سوابق بلند مدت که تکلیف همچین جانی‌هایی مشخصه! اما وقتی طرف به خاطر دو قرون پول افتاده دزدی کرده زده دو نفر بی‌گناه رو هم کشته! هرطور حساب می‌کنیم می‌بینیم عامل این جنایات همشون شرایط شخمی مملکته! شوخی میاد براتون واقعاً؟ یا چون نشستین اون بالا شکمتون سیره نمی‌فهمید ملت چی دارن می‌کشن؟! هیچ انسانی از شکم مادرش جنایت‌کار به دنیا نمیاد این شرایط جامعست که به این روز وادارش می‌کنه. چطور ممکنه اینهمه فساد کنی عامل همهٔ این رفتار‌های عجیب غریب توی مملکت باشی بعد به جای حل عامل فساد با شادی آدمارو دار بزنی بگی حقش بود! خیلی خب حقش بود مجرم باید مجازات بشه! اما اگه طرف روانی شده، اگه طرف قاتل درجه یک شده مسببش شرایطی هست که شما به بار آوردی! به این هم فکر می‌کنی یا گوش و چشمت کره؟ تا کی قراره جامعه به همین روش انتظار اصلاح داشته باشه؟ چطور ممکنه یه آدم ۲۰ ساله بشه جنایت‌کار؟ اون باید بشینه پلی‌استیشنشو بزنه چرا باید سیاسی بشه؟ من ۲۰ سالم بود نمی‌فهمیدم خبر چیه سیاست چیه... چون وضعیت مملکت نسبت به الآن اینهمه درب داغون نبود! من شخصاً کلی برای خودم آرزو و اهداف نوشته بودم که به همشون برسم و براشون تلاش کنم! اما الآن چی؟ چرا باید اینهمه خشم و نفرت توی یه جوون ۲۰ ساله شکل بگیره؟ چرا دنبال دلیلش نیستید؟ همچین کسی چی می‌فهمه از دنیا؟ مگه چی می‌خواد؟ تا کی می‌خوای دار بزنی؟ مشکلات مملکت با دار زدن حل خواهد شد؟ اصلاً همه رو بیا دار بزن ببینم چیرو می‌خوای حل کنی با این منطق؟! بابا شماها دیگه کی هستین خدایی من کلاً مغزم قیر پاچ کرده! آخر عاقبت هیچ‌کس جالب نخواهد بود با این شرایط...

هیچ مادری فرزندش رو برای بدرقه کردن تا چوبهٔ دار بزرگ نمی‌کنه! مسبب همهٔ این شرایط شمایید.

با توجه به بررسی‌هایی که انجام شد؛ در حال حاضر GCC جدید یعنی نسخهٔ ۱۶ از بالاترین پوشش پشتیبانی از ویژگی‌های استاندارد جدید بهره می‌بره. 👌 با این نسخه به یک‌باره به طرز عجیبی از Clang پیشی گرفت. https://gcc.gnu.org/gcc-16/ https://gcc.gnu.org/gcc-16/changes.html هم ماژول‌ها الآن در دسترس هستند، هم قرارداد‌ها و حتی رفلکشن‌ها. 🫡 و این یعنی نسخه‌های بعدی محصولات احتمالاً با GCC کامپایل بشن.

ویژگی قرارداد‌ها (Contracts)، بعد از Reflection یکی از قدرتمندترین قابلیت‌های استاندارد CPP26 است. 👌🔝 به زبان ساده، قراردادها باعث می‌شوند کد فقط «اجرا نشود»، بلکه قوانین خودش را هم به‌صورت رسمی بیان کند. و چه چیزی بهتر از این؟! یعنی یک تابع می‌تواند دقیقاً مشخص کند: ۱) با چه ورودی‌هایی اجازهٔ اجرا دارد؛ ۲) فراخواننده چه تعهدی در برابر آن دارد؛ ۳) تابع بعد از اجرا چه نتیجه‌ای را تضمین می‌کند؛ ۴) و چه شرایطی در منطق داخلی آن نباید هیچ‌وقت شکسته شود. برای مثال:

auto apply_discount(
    const int price,
    const int discount
) -> int
    pre(price >= 0)
    pre(discount >= 0)
    pre(discount <= 100)
    post(result: result >= 0)
    post(result: result <= price)
{
    return price - (price * discount / 100);
}

اینجا pre می‌گوید تابع فقط زمانی معتبر است که قیمت منفی نباشد و درصد تخفیف نیز بین صفر تا صد قرار داشته باشد. سپس post نیز تضمین می‌کند نتیجهٔ نهایی نه منفی شود و نه از قیمت اولیه بیشتر باشد. بنابراین قانون تابع دیگر فقط داخل توضیحات، مستندات یا ذهن برنامه‌نویس نیست؛ بلکه به بخشی رسمی از خود زبان تبدیل می‌شود. در واقع تابع به فراخواننده می‌گوید:

اگر تو پیش‌شرط‌های من را رعایت کنی، من نیز پس‌شرط‌های خودم را تضمین می‌کنم.

در اصل قرارداد‌ها، کد، محدودیت‌ها، انتظارات و تضمین‌های خودش را به شکلی قابل‌فهم برای برنامه‌نویس، کامپایلر، ابزارهای تحلیل و حتی عامل‌های هوش مصنوعی بیان می‌کند. #CPP26 #Contracts #Reflection #ModernCPP #SoftwareEngineering #Programming

چرا باید اطرافیانتو با اینستا بشناسی؟ اصلا مهم نیست این موضوع! چرا باید به خاطر تایید‌های دیگران زندگی کنی!؟ چه انتظاریه! اعتماد به نفس چیز خوبیه… روی اهدافت متمرکز شو بذار هرکی خوشحال می‌شه بشه هرکی ناراحت می‌شه بشه!😉

پیش از مقایسهٔ زبان‌های برنامه‌نویسی، کمی درنگ کنید دست نگه دارید. این پرسش‌ها معمولاً بیش از آنکه روشنگر باشند، بحث، تعصب و هیاهو ایجاد می‌کنند. پیش از آنکه نسخهٔ دیگری از پرسش «کدام زبان برنامه‌نویسی بهتر است؟» را مطرح کنید، بهتر است نکات زیر را در نظر بگیرید. در ۹۹ درصد موارد، انتخاب زبان برنامه‌نویسی بیش از آنکه زیر تأثیر ملاحظات فنی باشد، از نیازها و محدودیت‌های کسب‌وکار پیروی می‌کند. در عمل، موضوعاتی از این دست اهمیت بیشتری پیدا می‌کنند: ۱) آیا ابزارها و محیط توسعهٔ مناسب برای رایانه‌های برنامه‌نویسان در دسترس است؟ ۲) آیا محیط اجرای موردنیاز روی سامانه‌های مقصد وجود دارد؟ ۳) شرایط مجوز، مالکیت فکری و مسائل حقوقی ابزارها و محیط اجرا چیست؟ ۴) آیا برنامه‌نویسان آموزش‌دیده و باتجربه برای آن زبان در دسترس هستند؟ ۵) آیا خدمات آموزشی، پشتیبانی و مشاوره‌ای مناسبی برای آن وجود دارد؟ ۶) فرهنگ سازمانی، سیاست‌های داخلی و ساختار تصمیم‌گیری شرکت چگونه است؟ این ملاحظات معمولاً بسیار بیشتر از موضوعاتی مانند سرعت ترجمهٔ برنامه، کارایی هنگام اجرا، نوع‌دهی ایستا یا پویا و پیونددهی ایستا یا پویا بر تصمیم نهایی اثر می‌گذارند. کسانی که هنگام ارزیابی زبان‌های برنامه‌نویسی، معیارهای اصلی کسب‌وکار را نادیده می‌گیرند، ممکن است به‌درستی به ضعف در داوری و تصمیم‌گیری متهم شوند. فنی باشید، اما گرفتار فنی‌زدگی نشوید. در دنیای واقعی، مسائل اقتصادی، سازمانی و تجاری اغلب بر مسائل فنی برتری دارند. کسی که این واقعیت را درک نکند، ممکن است تصمیم‌هایی بگیرد که پیامدهای سنگینی برای سازمان داشته باشند. چنین تصمیم‌گیرنده‌ای حتی می‌تواند برای کارفرمای خود خطرآفرین باشد. چرا بیشتر مقایسه‌های زبان‌ها قابل اعتماد نیستند؟ بسیاری از مقایسه‌هایی که به‌طور گسترده منتشر می‌شوند، توسط هواداران یک زبان خاص نوشته شده‌اند. فرض کنیم نام آن زبان «Z» باشد. نویسندگان چنین مطالبی معمولاً می‌کوشند ثابت کنند که زبان Z از زبان‌های دیگر بهتر است. از آنجا که CPP کاربرد گسترده‌ای دارد، اغلب نخستین زبانی است که طرفداران Z تلاش می‌کنند آن را ضعیف‌تر، قدیمی‌تر یا ناکارآمدتر نشان دهند. در بسیاری از موارد، این مقاله‌ها توسط شرکتی منتشر یا پخش می‌شوند که زبان Z، ابزارهای آن یا خدمات وابسته به آن را می‌فروشد. چنین مطالبی در واقع بخشی از یک برنامهٔ بازاریابی هستند. با این حال، شگفت‌آور است که بسیاری از افراد، مقاله‌ای داوری‌نشده را که کارکنان یک شرکت فروشندهٔ Z نوشته‌اند و در آن «اثبات کرده‌اند» که Z بهترین زبان است، کاملاً جدی می‌گیرند. مشکل اینجاست که در چنین مقایسه‌هایی معمولاً بخش‌هایی از حقیقت نیز وجود دارد. هیچ زبانی از همهٔ زبان‌های دیگر، در تمام زمینه‌ها و از هر نظر بهتر نیست. CPP نیز بی‌نقص نیست. اما بیان گزینشی حقیقت می‌تواند بسیار فریبنده باشد و گاهی تصویری کاملاً نادرست ایجاد کند. بنابراین هنگام مطالعهٔ یک مقایسهٔ زبانی، باید چند پرسش اساسی مطرح کنید: ۱) نویسندهٔ این مقایسه چه کسی است؟ ۲) آیا نویسنده یا سازمان منتشرکننده از نتیجهٔ آن سود می‌برد؟ ۳) آیا ویژگی‌های زبان‌ها به‌صورت دقیق، واقعی و منصفانه توصیف شده‌اند؟ ۴) آیا معیارهای مقایسه برای تمام زبان‌های بررسی‌شده مناسب و یکسان هستند؟ ۵) آیا نسخه‌های هم‌دوره و هم‌سطح زبان‌ها با یکدیگر مقایسه شده‌اند؟ ۶) آیا نویسنده در همهٔ زبان‌های مورد بررسی تجربهٔ عملی کافی دارد؟ پاسخ‌دادن درست به این پرسش‌ها آسان نیست. بیارنه استروستروپ، طراح CPP، در کتاب «طراحی و فرگشت CPP» توضیح می‌دهد که چرا از مقایسهٔ مستقیم CPP با زبان‌های دیگر خودداری می‌کند:

چندین بازبین از من خواستند CPP را با زبان‌های دیگر مقایسه کنم. تصمیم گرفتم این کار را انجام ندهم. با این تصمیم، بار دیگر بر دیدگاهی قدیمی و ریشه‌دار تأکید می‌کنم: مقایسهٔ زبان‌ها به‌ندرت معنادار است و حتی کمتر از آن، منصفانه انجام می‌شود.

انجام یک مقایسهٔ درست میان زبان‌های مهم برنامه‌نویسی به تلاشی بسیار بیشتر از چیزی نیاز دارد که بیشتر افراد حاضرند صرف کنند. چنین کاری به تجربه در زمینه‌های کاربردی گوناگون، حفظ دیدگاهی مستقل و بی‌طرف و برخورداری از حس انصاف نیازمند است.

من زمان کافی برای انجام چنین کاری ندارم و به‌عنوان طراح CPP، بی‌طرفی من هرگز به‌طور کامل باورپذیر نخواهد بود.

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

مشکل بزرگ‌تر زمانی رخ می‌دهد که نویسنده یکی از زبان‌ها را بسیار بهتر از زبان‌های دیگر می‌شناسد. در این حالت، تغییر ظریفی در زاویهٔ نگاه ایجاد می‌شود: ایرادهای زبان آشنا کوچک و کم‌اهمیت شمرده می‌شوند و برای آن‌ها راه‌حل‌های ساده ارائه می‌شود؛ اما ایرادهای مشابه در زبان‌های دیگر، مشکلاتی بنیادی معرفی می‌شوند.

اغلب کسانی که مقایسه را انجام می‌دهند، راه‌حل‌های رایج در زبان‌های کمتر شناخته‌شده را نمی‌شناسند. گاهی نیز آن راه‌حل‌ها را نامناسب می‌دانند، زیرا همان روش‌ها در زبان مورد علاقه و آشنای خودشان کارآمد نیستند.

به همین شکل، اطلاعات مربوط به زبان شناخته‌شده معمولاً کاملاً تازه و به‌روز است، اما برای زبان کمتر شناخته‌شده از اطلاعات چند سال پیش استفاده می‌شود.

در مورد زبان‌هایی که ارزش مقایسه دارند، مقایسهٔ زبان X بر پایهٔ تعریف سه سال پیش آن با زبان Y بر پایهٔ تازه‌ترین پیاده‌سازی آزمایشی، نه منصفانه است و نه آموزنده.

به همین دلیل، دیدگاه‌های خود دربارهٔ زبان‌های دیگر را به نکات کلی یا موارد بسیار مشخص محدود می‌کنم.

نتیجه‌گیری انتخاب زبان برنامه‌نویسی نباید به مسابقهٔ هواداری، تعصب شخصی یا تکرار شعارهای تبلیغاتی تبدیل شود. پرسش درست این نیست که: «بهترین زبان برنامه‌نویسی جهان کدام است؟» پرسش درست این است: «برای این مسئله، این گروه، این سازمان، این زیرساخت، این بودجه و این آیندهٔ کاری، کدام زبان انتخاب مناسب‌تری است؟» با وجود همهٔ این ملاحظات، CPP همچنان برای طیف بسیار گسترده‌ای از برنامه‌نویسان، سامانه‌ها و زمینه‌های کاربردی، یکی از بهترین و توانمندترین انتخاب‌های موجود به‌شمار می‌آید.

چیز‌های با اصالت واقعاً نیازی به تبلیغات ندارن نیازی به ثابت کردن چیزی هم ندارند. https://isocpp.org/wiki/faq/big-picture این فرق بزرگ دنیای ++C با دیگر زبان‌هاست.

منظورش پرامپتلی هست؛ اندکی زمان نیاز دارم تا به یک نسخهٔ قابل استفاده برسونمش. حتماً منتشرش خواهم کرد برای عموم هنوز کار داره دل و رودهٔ پروژه بیرونه. 😝

نصب و راه‌اندازی یک افزونه یا ماژول روی تگرا چنین مراحلی رو در پس زمینه داره. در واقع نقشه‌ای از کل زیرسیستم افزونه هستش: ماژول‌ها و افزونه‌ها، مرزهای مالکیت آنها، جهت وابستگی و مدل‌ها (چرخه عمر، نصب، میزبان زمان اجرا، پایداری) رو نشون میده. معاری همین موضوع ۱ هفته فقط در موردش فکر کردم تحلیلش کردم که بخواد خیلی راحت از هر ماژول و ساختاری پشتیبانی کنه.

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