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. قابل تست بودن: انتزاع باید به شکلی باشد که بتوان آن را به‌صورت مستقل تست کرد.

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

Common Rust Lifetime Misconceptions

https://github.com/pretzelhammer/rust-blog/blob/master/posts/common-rust-lifetime-misconceptions.md#2-if-t-static-then-t-must-be-valid-for-the-entire-program

پ.ن: اینو بخونید تا دیگه borrow checker راست کفری تون نکنه =)

صحبت های سازندگان زبان Odin یعنی Ginger Bill و سازنده زبان Elixir (که اصلا نمیشناسمش) رو داریم می‌بینیم و باید بگم عجب جنجالی راه افتاده حقیقتا =) تقریبا ازشون خبر های داغ راجب زبان های برنامه‌نویسی رو پرسیدن.

مثلا اینکه چرا Python کارا میرن سمت Go.
یا چرا Ruby کار ها میرن سمت Rust.
و سرگذشت Erlang و Elixir و Ruby.
و حتی سازنده الکسیر راجب open بودن کامیونیتی روبی توضیح میده.
و صحبت کلی دعوای بین پارادایم های زبان های برنامه نویسی ست (OOP vs Functional).

و ازشون opinion شون رو راجب Rust هم پرسیدن که...😂 خودتون بشنوید بهتره.

درکل به هیچ عنوان این ویدیو رو از دست ندید. زیاد جالب است :)

https://youtu.be/tXJfS6jI9Z0?si=UAvBmX5Tmj_S7s44

این گنج را دریابید و متحول شوید.
کتابی برای درک برنامه نویسی Data Oriented در مقابل Object Oriented.

جامعه Geek Engineers یک فضای باز، پویا و دوستانه برای همه علاقه‌مندان به دنیای برنامه‌نویسی و مهندسی کامپیوتر است. ما باور داریم که یادگیری و پیشرفت، زمانی بهترین نتیجه را می‌دهد که افراد در کنار هم و با هم‌فکری، ایده‌ها و تجربیات خود را به اشتراک بگذارند.

هدف ما ایجاد محیطی است که در آن برنامه‌نویسان، از مبتدی تا حرفه‌ای، بتوانند با یکدیگر ارتباط برقرار کنند، پروژه‌های متن‌باز بسازند، مشکلات فنی را حل کنند و مهارت‌های خود را گسترش دهند. ما به ویژه به زبان‌های Rust، Go، OCaml و C علاقه‌مندیم و در پروژه‌ها و بحث‌های فنی از آن‌ها استفاده می‌کنیم. همچنین به الگوریتم‌ها و حل مسأله اهمیت می‌دهیم تا مهارت‌های تحلیلی و منطقی اعضای جامعه تقویت شود. در وب‌سایت ما می‌توانید کتاب‌ها و مقالات کاربردی مرتبط با برنامه‌نویسی و مهندسی نرم‌افزار را پیدا کنید تا یادگیری شما هدفمندتر و عمیق‌تر شود.

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

@geek_engineers

https://geekengineers.netlify.app

کتاب ها و مقاله های کوچک داخل کانال به مرور به وبسایت انتقال داده میشود و پروژه های اوپن سورس دیگری اضافه خواهد شد.

شما هم اگر تمایل داشتید میتونید پروژه هاتون رو به سمت کامیونیتی بیارید و از دوستانی که تمایل به مشارکت دارند کمک بگیرید.

> به امید ساختن جامعه ای با سواد و مجرب🤌🏿

توی TempleOS کتابخانه داخلی‌ شبیه OpenGL و glm وجود داشت =) دارم وسوسه میشم امتحانش کنم روی VM.

https://youtu.be/d3eFHyryopQ?si=Ry5_LFrZh9Bowga8

سندرم ایمپاستر (Impostor Syndrome)

این یک اختلال رسمی روان‌شناسی مثل افسردگی یا اضطراب نیست، بلکه بیشتر یک الگوی فکری و احساسی است. کسی که این حالت را تجربه می‌کند، با وجود شواهد واقعی از موفقیت‌ها و توانایی‌هایش، خودش را یک «حقّه‌باز» یا «جعلی» می‌بیند.

ویژگی‌های اصلی‌اش:

- فرد موفقیت‌هایش را به شانس، روابط یا اتفاق نسبت می‌دهد، نه توانایی خودش.

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

- دستاوردها برایش واقعی یا ارزشمند به نظر نمی‌رسند.

- حتی وقتی موفقیتی کسب می‌کند، احساس رضایت موقتی دارد و سریعاً دوباره وارد همان چرخه شک و تردید می‌شود.


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

اینجا راجبش بحث شده :

https://www.reddit.com/r/webdev/s/Q4TPMWy0zH

منتها راه حل شفاف و واضحی ندارد.
فقط میتونم بگم آگاهی و شناخت کمک به کنترلش میکند.

Stack Frames (Trynna understand the concept by using a debugger)

https://www.youtube.com/watch?v=0t_QewtSbXo (The most nice one)

https://www.youtube.com/watch?v=7dMTCdFM2ss

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

کتاب Effective C (سطح مقدماتی)

Apollo 11 source code:

https://github.com/chrislgarry/Apollo-11

اینی که میبینید مربوط به یکی از فایل‌های سورس کد کامپیوتر راهنمای آپولو (AGC) هست؛ همون کامپیوتری که در ماژول ماه‌نشین (LM) آپولو 11 کار می‌کرد و باعث شد فضانوردها بتونن روی ماه فرود بیان.

https://github.com/chrislgarry/Apollo-11/blob/master/Luminary099/BURN_BABY_BURN--MASTER_IGNITION_ROUTINE.agc

این فایل مربوط به یک روتین روشن کردن موتور اصلی توی نرم‌افزار LM بوده. یعنی یکی از بخش‌های خیلی حساس که باید موتور رو برای مانور یا فرود روشن می‌کرد.

ساخته شده با: یه اسمبلی مخصوص AGC به اسم yaYUL (امیدوارم راجب اسم اسمبلی ش اشتباه نکرده باشم...).

این کد از روی عکس‌های نسخه چاپی که توی موزه MIT نگه‌داری می‌شد، دوباره تایپ (دیجیتال) شده. نسخه‌ای که استفاده شد (LMY99) دقیقاً چند روز قبل از فرود آپولو 11 روی ماه مونتاژ شده بود، یعنی 14 جولای 1969 (آپولو 11 در 20 جولای روی ماه نشست). سال 2009 رون برکی (Ron Burkey) و تیمش این کدها رو بازسازی کردن و چندتا اشتباه تایپی رو هم درست کردن.

💀 حالا چرا اسمش "BURN_BABY_BURN" ؟

این بخش قشنگ ماجراست.
یکی از برنامه‌نویس‌های این روتین، Don Eyles، سال‌ها بعد توی جشن 40 سالگی فرود روی ماه توضیح داد که اسم این روتین از کجا اومده:

در دهه 60 یه دی‌جی معروف به اسم Magnificent Montague توی رادیوهای نیویورک و لس‌آنجلس کار می‌کرد و وقتی آهنگ‌های داغ پخش می‌کرد همیشه می‌گفت:
"Burn, baby! BURN!"

این جمله هم نماد شور و حال موسیقی سول (Soul) بود و هم بعدها در شورش‌های لس‌آنجلس (1965) استفاده شد. برنامه‌نویس‌ها توی لابراتوار MIT، وقتی داشتن روتین روشن کردن موتور LM رو می‌نوشتن، با شوخی و خلاقیت گفتن: خب اینجا هم موتوری می‌خوایم که بسوزه و روشن بشه، پس بذار اسمش باشه BURN_BABY_BURN.

https://github.com/chrislgarry/Apollo-11/blob/master/Luminary099/STABLE_ORBIT.agc

برنامه‌های P38 و P78 که توی این فایل مستند شدن، مربوط به رِندِوو (Rendezvous) بودن، یعنی مرحله‌ای که دو فضاپیما باید همدیگه رو در مدار ماه پیدا کنن و به هم نزدیک بشن.

یه "وسیله فعال" (Active Vehicle) وجود داره، همون که قراره مانور بده.
یه "وسیله منفعل" (Passive Vehicle) وجود داره، که توی مدار خودش حرکت می‌کنه.

هدف این برنامه‌ها این بوده که محاسبه کنن چه مقدار تغییر سرعت (ΔV = Delta V) لازمه تا وسیله فعال روی مداری بیفته که بتونه به مدار وسیله منفعل برسه. وقتی رسید، وسیله فعال دقیقاً هم‌مدار با وسیله منفعل باشه، ولی با یک فاصله مشخص (Delta R) جلو یا عقب اون قرار بگیره. این‌ها برای عملیات مثل برگشت LM به CM (ماژول فرماندهی) بعد از فرود روی ماه حیاتی بودن.

توی کامنت نوشته... فضانورد از طریق DSKY (کنسول کامپیوتر AGC که دکمه داشت) این برنامه رو فراخوانی می‌کنه.

دستورها مثل این بودن:

V37E38E وقتی این وسیله فعال هست. V37E78E وقتی وسیله دیگه فعال هست.
(V37 یک فرمان برای اجرای برنامه، E مثل Enter بود، و عدد بعدی شماره برنامه مثل P38 یا P78 رو مشخص می‌کرد.)

حالا پس ΔV چیست؟

ΔV یا "تغییر سرعت" در فضاپیمای آپولو به تغییر سرعت فضاپیما برای رسیدن به یک مسیر جدید اطلاق می‌شود. این تغییر سرعت معمولاً از طریق استفاده از موتور فضاپیما محقق می‌شود.

برای محاسبه ΔV، معمولاً باید شرایط زیر را در نظر بگیریم:

جرم فضاپیما (m): شامل جرم فضاپیما و سوخت آن.
نیروی محرکه (Thrust): قدرت موتور برای تولید نیروی حرکت.
زمان اعمال نیرو: مدت زمانی که موتور فعال است.
مسیر و شتاب: به خصوص در مأموریت‌های ملاقات مداری (Rendezvous).

منتها شیوه محاسبه دقیقش وارد مبحث تخصصی علم مقدس فیزیک میشه که بنده دانشش را ندارم😂🤌🏿
رفرنسش اینجاست :

https://en.wikipedia.org/wiki/Tsiolkovsky_rocket_equation

Clean Architecture: A Craftsman's Guide to Software Structure and Design (2017)

- Robert Martin (Uncle Bob)

All in all, Kernighan had a bad experience. “When I tried to figure out what was going on, the language had changed since the last time somebody had posted a description! And so it took days to write a program which in other languages would take maybe five minutes…”

اسکیل ایشیو را هم defect حساب کردی مشتی؟ :))

https://thenewstack.io/unix-co-creator-brian-kernighan-on-rust-distros-and-nixos

این هم از زبان برنامه نویسی Cyrus که ما موفق به ساختش شدیم.

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

در حال حاضر داریم type system رو تست میکنیم تا اینکه تا حدی stable بشه. هر موقع استیبل بشه به ادامه دولوپ فیچر های high level مثل error handling و macro ها و generic type ها خواهیم پرداخت انشالله.

#cyrus
@cyrus_lang
https://github.com/cyrus-lang/Cyrus

Let’s Go: Learn to build professional web applications with Go, 2nd Edition (2025)

پ.ن: لول مقدماتی

Anyone Can Code: Algorithmic Thinking (2023)

پ.ن: برا درک الگوریتم کتاب خوبیه. ولی زیاد تخصصی نیستش.

📝 عنوان مقاله: کاهش پیچیدگی در سیستم‌های برنامه‌نویسی شیءگرا (OOP)

چکیده: این مقاله بررسی می‌کند که چگونه روش‌های منضبط در برنامه‌نویسی شیءگرا، مانند ترجیح ترکیب بر وراثت و کوچک نگه داشتن کلاس‌ها، می‌توانند به مدیریت پیچیدگی کمک کنند. همچنین، برنامه‌نویسی داده‌محور (DOP) را به عنوان یک پارادایم جایگزین معرفی می‌کند که به طور بنیادین با جدا کردن کد از داده، پذیرش تغییرناپذیری (immutability) و استفاده از ساختارهای داده‌ی عمومی به حل پیچیدگی می‌پردازد. این متن توضیح می‌دهد که چرا سیستم‌های OOP ممکن است پیچیده شوند و اصول اصلی DOP را به عنوان یک رویکرد مکمل یا جایگزین برای ساخت نرم‌افزارهای قوی‌تر و قابل نگهداری‌تر ارائه می‌دهد.

زمان مطالعه: ۴ دقیقه
برچسب‌ها: OOP, DOP, طراحی نرم‌افزار, پارادایم‌های برنامه‌نویسی, TypeScript

https://geekengineers.netlify.app/blog/alleviating-complexity-in-oop-systems

🔺 برنامه‌نویسی کوانتومی (Quantum Programming)

برنامه‌نویسی کوانتومی بر پایه قوانین مکانیک کوانتوم ساخته شده. به جای بیت‌های کلاسیک (۰ و ۱)، در اینجا با کیوبیت سروکار داریم؛ کیوبیت می‌تونه همزمان در چند حالت باشه (به این می‌گن Superposition) و حتی با کیوبیت‌های دیگه Entanglement پیدا کنه. همین ویژگی‌ها باعث می‌شه بعضی محاسبات خیلی سریع‌تر از کامپیوترهای معمولی انجام بشه.

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

🔺 برای نوشتن برنامه‌های کوانتومی، زبان‌ها و فریم‌ورک‌های مخصوصی وجود داره:

- Qiskit (مبتنی بر پایتون)
- Quipper (مبتنی بر Haskell)
- Cirq (از گوگل)

و این برنامه‌ها روی پردازنده‌های کوانتومی مثل IBM Quantum یا Google Sycamore اجرا می‌شن.

تو این دنیا به جای دستورهای کلاسیک، از گیت‌های کوانتومی (مثل Hadamard, CNOT, Pauli-X و...) استفاده می‌کنیم. همین ابزارها پایه‌ی کاربردهای بزرگی مثل رمزنگاری نسل بعدی، بهینه‌سازی، شبیه‌سازی سیستم‌های فیزیکی و شیمیایی هستن. البته تکنولوژی هنوز در مراحل اولیه رشدشه.

🔺 برنامه‌نویسی کوانتومی در خانه: واقعاً ممکنه؟

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

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

🔺 زبان‌های برنامه‌نویسی کوانتومی

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

برخلاف زبان‌های کلاسیک، این زبان‌ها از مفاهیم ویژه کوانتوم مثل Superposition (هم‌زمان بودن در چند حالت)، Entanglement (درهم‌تنیدگی) و Quantum Parallelism (محاسبات موازی کوانتومی) پشتیبانی می‌کنن.

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

https://www.bluequbit.io/quantum-programming-languages

https://learn.microsoft.com/en-us/azure/quantum/qsharp-overview

اینجا quickstart با #Q وجود داره و پیشنهاد میکنم حتمی یک نگاهی بهش بندازید‌:

https://learn.microsoft.com/en-us/azure/quantum/qsharp-quickstart