نمیدونم کی ستاره اهدا کرد. فقط خواستم بگم این اولین باره توی کانال هایی که داشتم کسی ستاره داده. کار هرکی بوده خیلی خیلی دمش گرم😁❤️

راجب زبونای Functional در مقایسه با زبونای Imperative.
و تفاوت دیدگاه زبان OCaml برای حل مسائل.

https://www.youtube.com/watch?v=v1CmGbOGb2I

ویدیو ساخت خودم. میخواستم برا Cyrus بیام Foreach بسازم که. کار کشید به نوشتن runtime inbounds check😂🤌🏿

https://www.youtube.com/watch?v=667xXQbBELs

ادامه ش اینجاس

https://www.youtube.com/watch?v=1P36cFccQn8

فردا نوشتن Foreach رو ادامه میدیم.

اگر این مدل ویدیو (Daily Coding) رو دوس داشتین میتونیم بیشتر رو این قضیه تمرکز کنیم. اگر نه هم که هیچی.

پ.ن: این ویدیو ها برای اشنایی با کلیت پروژه مفیده. اگر کسی بخواد میتونه سورس کد پروژه رو بخونه و با دیدن ویدیو ها بیشتر متوجه شیوه کار کامپایلر مون میشه و موقعیت مشارکت راحت تر میشه خلاصه.

یه چیت شیت ۱۰ صفحه ای برای اسمبلی x64

https://cs.brown.edu/courses/cs033/docs/guides/x64_cheatsheet.pdf

اینم یک زبان برنامه نویسی اسوتریک دیگه که من ساختم :)

این یک زبان برنامه نویسی اسوتریک (esoteric) است که محض تفنن و ایجاد انگیزه ساخته شده است. داستان به اونجایی برمیگرده که یکروز اونقدری کامپایلر دیزاین فشار آورد که مجبور شدم صداهای ناهنجاری مث بععععع از خودم روانه کنم :) این زبان رو به عشق برنامه نویس های سیستمی ساختم که فشار روانی زیادی رو تحمل میکنن تا بتونن مکانیزمی رو پیاده سازی و نتیجتا مشکلی رو حل کنند. این زبان رمزی از Brainfuck الهام گرفته شده و همان شیوه instruction هارو شامل میشه. امیدوارم بععععع بععععع کردن موقع کار به بهبود سلامت روان تون کمک کنه و یادتون نره که زندگی هنوزم سرزندگی و خوشحالی رو از دست نداده :)

https://github.com/tahadostifam/Babaism

شما هم به ببئیسم بپیوندید
با ساختن ایشیو در همین ریپازیتوری و با روانه کردن بعععع بععععع میتونین بدون اخذ هیچ هزینه ای در ببئیسم عضو بشید.

زیگ برای async و event loop یه rewrite داشتن چون سازنده ش Andrew Kelley فکر میکرد که به اون خوبی ای نشده که فکرشو میکرد و اومدن آپگرید ش کردن :)

میتونم بگم فوق العاده ست پیاده سازیش. ولی خدایی "async"@ قطعا چیزی نیستش که بهش بتونی بگی سیمپل :) زیگ از simplicity فاصله گرفته.

https://www.youtube.com/watch?v=hEIBsqP63Pg

مثال هایی از error polymorphism در زبان های مختلف Java, C#, Rust, Zig, Koka

https://www.youtube.com/watch?v=OcyijYJq18s

‌آیا async/await همیشه مفیده؟ نه دقیقاً!
توی یکی از پروژه‌های ما با ترافیک بالا، همه‌ی endpointها به‌صورت async نوشته شده بودن.
ولی با وجود کد تمیز و async بودن کامل، سیستم دچار ThreadPool starvation شده بود و latency به‌شدت بالا رفته بود.
بررسی کردیم و دیدیم:‌ async به‌صورت blanket روی همه مسیرها اجرا شده، حتی روی عملیات‌های CPU-bound یا توی حلقه‌های ریز و پرتکرار.
حالا async ابزار خیلی خوبیه، ولی:
- روی CPU-bound = بدتر شدن عملکرد
- توی حلقه‌های tight = هزینه context switching اضافی

توصیه:
فقط عملیات‌های I/O واقعی (مثل DB, HTTP, File IO) ارزش async دارن
چی‌کار کردیم؟
؛ endpointهایی که واقعاً I/O-bound بودن، async موندن

بقیه‌ی مسیرها برگشتن به sync
و با این تغییر ساده، latency تقریباً نصف شد (بر اساس لاگ‌های واقعی)
ابزار:
من برای این تحلیل از ابزارهایی مثل MiniProfiler و لاگ‌های دقیق Serilog کمک گرفتم.
جمع‌بندی:
تجربه نشون می‌ده async فقط یه keyword نیست.
یه تصمیم مهندسیه، که اگه بی‌دلیل و همه‌جا استفاده بشه، می‌تونه قاتل performance باشه.

@DevTwitter | <Bahare Zarei/>

عجب کتابخونه ایه. از دستش ندین

https://magicui.design

خب Carbon تا یه حدی نسخه experimental ش تکمیل شده و آماده تست و مشارکت هستش، اگر ++C دوس دارین یه نگاهی بهش بندازین؛ گرچه قبلا هم معرفی ش کرده بودم :)

https://docs.carbon-lang.dev

عجب چیزی ساخته طرف

https://www.youtube.com/watch?v=8-B6ryuBkCM

Programming Abstractions in C++

اون کتاب قبلیه زیادی مقدماتی بود. این یکی یکم بهتره =)
فصل ۶ و ۷ و ۸ راجب انتزاعات در الگوریتم ها هستش و خوندنش رو پیشنهاد میکنم.

مزایا و معایب ساخت انتزاع

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

1. ساده‌سازی منطق و کاهش پیچیدگی ذهنی
2. قابلیت استفاده مجدد (Reusability)
3. افزایش قابلیت نگهداری (Maintainability) (همچنین اشاره میشود به اصل Separation of Concerns)
4. تمرکز بر روی مسئله اصلی

معایب و هزینه‌های انتزاع

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

2. پنهان کردن بیش‌ازحد جزئیات حیاتی
برخی سیستم‌ها (مانند سیستم‌های Real-Time یا Embedded) نیازمند کنترل دقیق بر منابع و رفتار هستند. انتزاع بیش‌ازحد می‌تواند این دید و کنترل را محدود کند و اشکال‌زدایی را دشوار نماید.

3. هزینه عملکرد (Performance Overhead)
هر لایه‌ی انتزاع می‌تواند منجر به سربار زمانی و حافظه‌ای شود. مثلاً استفاده از یک ORM ممکن است در مقایسه با اجرای مستقیم SQL، چندین برابر کندتر باشد. در سیستم‌های High-Performance، این موضوع باید به‌دقت سنجیده شود.

4. افزایش وابستگی
انتزاعی که به کتابخانه‌ها یا فریم‌ورک‌های خاص متکی باشد، می‌تواند باعث قفل‌شدگی تکنولوژیک (Vendor Lock-In) شود. در این حالت، تغییر زیرساخت یا ابزار، نیازمند بازنویسی گسترده خواهد بود.

توصیه‌های طراحی انتزاع

1. اصل KISS (Keep It Simple, Stupid): لایه‌ها را تا حد ممکن ساده طراحی کنید.
2. اصل YAGNI (You Aren’t Gonna Need It): انتزاعی نسازید که فعلاً نیاز ندارید.
3. مستندسازی: هرچه جزئیات پنهان می‌کنید، باید به‌خوبی داکیومنت شود.
4. قابل تست بودن: انتزاع باید به شکلی باشد که بتوان آن را به‌صورت مستقل تست کرد.

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