Geniuses Group

🧠 تعارض خالص جنگ است، همکاری خالص عشق است، سیاست آمیزه‌ای از هر دو است.

🔬 نوشته بالا منتسب به Michael Laver #دانش_مند حوزه سیاست (Political scientist)، که به قشنگی تحریف کلمه سیاست و ظرایف آن را به نمایش در می‌آورد. شاید سیاست را بیش از حد دور دیده‌ایم. وقتی کلمهٔ «سیاست» را می‌شنویم، معمولاً ذهنمان به سمت دولت، انتخابات، احزاب، مجلس، قدرت و رقابت برای حکومت می‌رود.

🧐 اما سیاست، پیش از آنکه نامِ یک میدان سیاسی در سطح جامعه باشد، نامِ چیزی است که میان انسان‌ها اتفاق می‌افتد.
- جایی که خواسته‌ها کاملاً یکی نیستند، اما قرار هم نیست برای هر اختلافی بجنگیم.
- جایی که باید تصمیمی گرفته شود؛ تصمیمی که بر بیش از یک نفر اثر می‌گذارد،
و آدم‌ها باید بطریقی با وجود تفاوت‌هایشان به آن برسند.
- چه کسی چه چیزی را داشته باشد؟
- چه زمانی؟
- با چه ترتیبی؟
- چه کسی تصمیم بگیرد؟
- چه کسی اثر بیشتری داشته باشد؟
- و اصلاً چه چیزی برای همه قابل قبول باشد؟

⏳ #اندیشمند Harold Lasswell ، سیاست را با پرسش معروف «چه کسی چه چیزی را، چه زمانی و چگونه به دست می‌آورد؟» صورت‌بندی کرد. در برداشت گسترده‌ای از سیاست، چنین پرسش‌هایی فقط به حکومت محدود نیستند؛ هرجا افراد یا گروه‌ها دربارهٔ یک انتخاب جمعی، منابع، قواعد یا منافع متفاوت با یکدیگر سروکار دارند، می‌توان از سیاست سخن گفت.

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

⏳ شاید نکتهٔ عجیب‌تر این باشد که برای دیدن سیاست، لازم نیست به یک کشور نگاه کنیم.
- گاهی کافی است دو نفر را کنار هم بگذاریم.
- دو دوست که می‌خواهند برای یک سفر تصمیم بگیرند.
- دو همکار که دربارهٔ اولویت یک کار اختلاف دارند.
- دو عضو خانواده که هرکدام تصور متفاوتی از یک تصمیم مشترک دارند.

در مقیاس بزرگ‌تر، همین مسئله می‌تواند به سازمان، جامعه یا دولت برسد؛ فقط تعداد بازیگران، قواعد، منابع و پیامدها پیچیده‌تر می‌شود.
به همین دلیل، Politics را نباید بی‌درنگ با Government یکی گرفت؛ و Governance هم مفهوم دیگری است که بر چگونگی هدایت، تصمیم‌گیری و تنظیم امور یک جمع یا سازمان تمرکز دارد. حتی در ادبیات علمی، دامنهٔ Politics از تعریف‌های محدودِ دولت‌محور تا تعریف‌های بسیار گسترده‌تر، مورد بحث است.

🤔 شاید مسئله این نباشد که
«چطور سیاست را از زندگی‌مان حذف کنیم؟»
شاید سؤال عمیق‌تر این باشد:
چطور سیاست را آن‌قدر درست بفهمیم که بتوانیم آن را، پیش از آنکه در اخبار ببینیم، در روابط انسانی ببینیم؟

🧠 داده، اطلاعات، دانش و خرد؛ یک هرم نیستند!

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

🧐 احتمالاً نمودار معروف DIKW Pyramid (اشتباها در فارسی هرم دانش یا هرم داده نامیده میشود) را دیده‌اید:
Data → Information → Knowledge → Wisdom
یک تصویر ساده که خیلی سریع به ما می‌گوید:
- #داده تبدیل به اطلاعات می‌شود،
- #اطلاعات تبدیل به دانش،
- و #دانش تبدیل به خرد.
اما شاید همین سادگی، ما را گمراه کرده باشد.

⏳ این چهار مفهوم بیشتر از آنکه چهار مرحله پشت سر هم باشند، به هم وابسته‌اند و دائماً روی یکدیگر اثر می‌گذارند.
- یک Input وارد سیستم می‌شود.
- سیستم با توجه به آنچه از قبل می‌داند، آن را تفسیر می‌کند.
- اگر این تفسیر بتواند عدم‌قطعیت یا ابهام را کاهش دهد، برای آن سیستم به Information تبدیل شده است.
- این Information می‌تواند در مدل درونی سیستم جای بگیرد و بخشی از Knowledge آن شود.
- و Knowledge دوباره تعیین می‌کند که Inputهای بعدی چگونه تفسیر شوند.

⏳ پس مسیر فقط این نیست:
Data → Information → Knowledge
بلکه می‌تواند این‌طور باشد:
Input ↔️ Data|Information ↔️ Knowledge
و شاید Wisdom هم اصلاً «طبقه بالاتر» این هرم نباشد.
اگر #خرد را توانایی استفاده از دانش برای تشخیص اهمیت، انتخاب و عمل بدانیم، دیگر با یک مرحله جدید از انباشته‌شدن چیزها روبه‌رو نیستیم؛ با نحوه استفاده از آنچه می‌دانیم روبه‌رو هستیم و به نوعی خرد، خودش بخشی از دانش درونی سیستم هست.

🧠 شاید به جای هرم، بهتر باشد این مفاهیم را بخشی از یک سیستم شناختی (#علوم_شناختی) ببینیم.

در کامنت‌ها کمی دقیق‌تر به این رابطه نگاه می‌کنیم.

🧠 چرا رسیدن به هوشمندی (خرد) برای انسان و AGI برای هوشواره این‌قدر سخت است؟

🔬این روزها تقریباً هر بار که صحبت از پیشرفت هوش مصنوعی می‌شود، یک پاسخ تکراری می‌شنویم:
مدل بزرگ‌تر، داده بیشتر، پارامتر بیشتر، محاسبات بیشتر.
و طبیعی هم هست؛ مدل‌های بزرگ‌تر معمولاً توانایی‌های بیشتری نشان می‌دهند. اما آیا مسیر رسیدن به #AGI واقعاً همین است؟ یا شاید مسئله جای دیگری است؟

🧐 اول باید بپرسیم AGI دقیقاً چیست؟ اگر بخواهیم خیلی ساده تعریف کنیم:

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

اگر این تعریف را بپذیریم، ناگهان مسئله خیلی سخت‌تر از «پیش‌بینی Token بعدی» به نظر می‌رسد.

📌 مسئله از کجا شروع می‌شود؟ ما انسان‌ها واقعیت را مستقیماً به ماشین منتقل نمی‌کنیم. حتی به یکدیگر هم منتقل نمی‌کنیم. یک زنجیره تقریباً شبیه این داریم:
Reality → Perception → Thought → Concept → Language → Text → Model
و در هر مرحله ممکن است ابهام وارد شود. یک انسان چیزی را در ذهن دارد. آن را به یک مفهوم تبدیل می‌کند. برای رساندن آن مفهوم، یک کلمه انتخاب می‌کند. ممکن است کلمه دقیق نباشد. ممکن است جمله مبهم باشد. ممکن است مخاطب برداشت دیگری داشته باشد. و تازه در اینجا است که ماشین با متن مواجه می‌شود. بنابراین Language خودِ Reality نیست؛ یک واسط برای انتقال بخشی از برداشت ما از Reality است. و این واسط ذاتاً می‌تواند مبهم باشد.

📌 پس LLM دقیقاً چه چیزی را یاد می‌گیرد؟ مدل زبانی از حجم عظیمی از این واسط‌های انسانی یاد می‌گیرد: متن، جمله، کلمه، ارتباط میان کلمات، الگوهای تکرارشونده و روابط موجود در داده‌ها. و با افزایش ظرفیت مدل، می‌تواند ساختارهای پیچیده‌تری از این داده‌ها استخراج کند. اما یک سؤال اساسی باقی می‌ماند:

آیا یادگیری ساختار زبان، الزاماً به معنای ساختن یک مدل قابل اتکا از واقعیت پشت زبان است؟

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

⏳اینجا شاید مسیر دیگری برای AGI لازم باشد.
شاید مسئله اصلی این نباشد که:
چند پارامتر دیگر به مدل اضافه کنیم؟
بلکه:
چگونه می‌توانیم با ظرفیت کمتر، representation دقیق‌تری از واقعیت بسازیم؟
به جای اینکه ابهام را با افزایش ظرفیت مدل جبران کنیم:
More Parameters → More Capacity
شاید باید به سمت چیزی شبیه این برویم:
Better Representation → Better Relations → Better World Model → Better Reasoning
یعنی به جای اینکه مدل برای هرچه چیزهای بیشتری را در خود جای دهد، بتواند ارتباط دقیق‌تری میان چیزهایی که می‌داند برقرار کند.
در این نگاه، هوشمندی الزاماً به معنای «دانستن بیشتر» نیست.
گاهی ممکن است به معنای دانستن کمتر، اما دقیق‌تر و ساختاریافته‌تر باشد.

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

«چگونه یک LLM بزرگ‌تر بسازیم؟»

بلکه:

چگونه سیستمی بسازیم که از یک واسط مبهم، یعنی زبان، به مدلی قابل اتکا از واقعیت برسد؛ آن مدل را از شواهد یاد بگیرد و اصلاح کند؛ و سپس بتواند بدون آموزش اختصاصی، درباره وضعیت‌هایی که قبلاً ندیده است استدلال کند؟

و شاید سخت‌ترین قسمت همین باشد. کاری که ما در #معمار در Geniuses.Group با ایجاد روش شناختی منسجم، سعی در حل کردنش را داریم ولی قطعا پاسخ قطعی و نهایی براش نداریم.

🤔 حالا یک سؤال برای شما:
اگر دو مدل را داشته باشیم:
مدل A:
۱۰۰۰ میلیارد پارامتر دارد و می‌تواند درباره تقریباً هر چیزی صحبت کند.
مدل B:
۱۰۰ میلیارد پارامتر دارد، اما یک مدل بسیار دقیق‌تر و ساختاریافته‌تر از واقعیت دارد و می‌تواند با شواهد جدید خودش را اصلاح کند.
کدام‌یک به AGI نزدیک‌تر است؟
و سؤال سخت‌تر:

آیا اصلاً می‌توان با افزایش پارامترهای یک مدل زبانی، از «مدل زبان» به «مدل واقعیت» رسید؟

🧠 این بار قبل از پرسیدن از هوشواره (#AI #ArtificialIntelligence)، کمی خودمان فکر (#تفکر) کنیم.
راستی یادمون نره که صرفا در مورد هوشمندی ماشین صحبت نمیکنیم 😉

🧠 روز برنامه‌نویس را به همه #اندیشمند‌ان تبریک می‌گوییم!

اما بیایید این روز را بهانه کنیم و یک سؤال ساده بپرسیم:
📌واقعاً چه کسی Programmer است؟
تعریف جالبی در فرهنگ واژه‌های حوزه کامپیوتر وجود دارد:

a person who designs, writes and tests computer programs

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

🤔 اگر یک هوشواره بتواند بخشی از Code را از چیزی که ما توصیف کرده‌ایم تولید کند، آیا آنچه انجام شده دیگر Programming نیست؟
شاید مسئله را باید کمی عقب‌تر ببریم.
— قبل از Code، چیزی باید طراحی شود.
— قبل از طراحی، باید بدانیم چه رفتاری می‌خواهیم.
— قبل از آن، باید بدانیم چه مسئله‌ای داریم.
— و قبل از آن، باید واقعیت، محدودیت‌ها و هدف را بفهمیم.
پس شاید زنجیره چیزی شبیه این باشد:
📌 Reality → Need → Model → Behavior → Program → Code
و Code فقط انتهای این زنجیره است.

⏳ حالا #هوشواره‌ها به‌سرعت دارند بخش‌هایی از انتهای این زنجیره را ارزان و خودکار می‌کنند.
تولید Code، بازنویسی Code، تست، رفع خطا و حتی بخشی از طراحی را می‌توان به آنها سپرد.
پس شاید سؤال اصلی این نباشد که:

«آیا هوشواره‌ها Programmerها را جایگزین می‌کنند؟»

بلکه:

اگر نوشتن Code دیگر کار اصلی Programmer نباشد، Programmer دقیقاً چه چیزی باید بداند و چه چیزی باید بسازد؟

شاید پاسخ، بیشتر از همیشه به #تفکر نزدیک باشد.
چون هرچه تولید Code آسان‌تر شود، ارزشِ دانستن اینکه چه چیزی باید ساخته شود، چرا باید ساخته شود و رفتار درست آن چیست بیشتر می‌شود.

📌 شاید Programmer کسی نباشد که بیشترین Code را می‌نویسد.
شاید Programmer کسی باشد که بتواند یک رفتار دقیق را از یک مسئله واقعی استخراج کند و آن را به برنامه‌ای قابل اجرا تبدیل کند.
و اگر این تعریف درست باشد، هوشواره‌ها پایان Programming نیستند؛
شاید فقط ما را مجبور کرده‌اند دوباره بفهمیم Programming واقعاً چیست.

🧠 امروز، روز برنامه‌نویس است.
به عنوان #تلنگر_ذهنی به‌جای شمردن خطوط Code، شاید بد نباشد از خودمان بپرسیم:
ما واقعاً کدام بخش از یک Program را بلدیم بسازیم؟ 🤔

🧠 بنیان، از نتیجه‌هایش تعریف نمی‌شود!

در فاز #مدل_سازی در ساختن هر نظام دانشی (#معمار)، از یک کتاب و نظریه علمی گرفته تا مستندات یک سیستم، روش یک سازمان یا حتی مجموعه‌ای از باورهای شخصی، یک اصل ساده وجود دارد:
📌 چیزی که قرار است پایه باشد، نباید برای تعریف خودش به چیزی وابسته باشد که روی همان پایه بنا شده است.

اما گاهی این وابستگی آن‌قدر آرام شکل می‌گیرد که اصلاً متوجه آن نمی‌شویم:
— لایه‌ای را می‌سازیم که قرار است بنیادی باشد؛
— بعد برای توضیح بخشی از آن، از مفهومی در لایه بالاتر کمک می‌گیریم؛
— و آن لایه بالاتر هم در نهایت بر همان لایه پایه بنا شده است.
— در ظاهر فقط یک ارجاع ساده ساخته‌ایم.
— اما در واقع، جهت وابستگی را برعکس کرده‌ایم.
اگر A پایه B باشد، B می‌تواند بر اساس A مفهوم جدیدی بسازد؛ اما تعریف بنیادی A نباید برای فهم خودش به B نیاز داشته باشد. وگرنه دیگر با یک بنیان مستقل روبه‌رو نیستیم؛ با یک دور مفهومی روبه‌رو هستیم.

⏳ راه‌حل ظاهری شاید این باشد که ارجاع‌ها را حذف کنیم. اما آن‌وقت مشکل دیگری ایجاد می‌شود، هر لایه شروع می‌کند به توضیح دادن همان مفهوم با زبان خودش. پنج سند، پنج روایت. و هر بار که یکی از آنها تغییر می‌کند، احتمال فاصله گرفتن روایت‌ها بیشتر می‌شود.
📌 پس مسئله حذف وابستگی نیست؛ پیدا کردن محل درست تعریف است.
یک مفهوم بنیادی باید یک‌بار، در جای درست، دقیق تعریف شود و لایه‌های بالاتر از آن استفاده کنند؛ نه اینکه هر کدام نسخه‌ای از آن برای خودشان بسازند. اما اینجا یک دام دیگر هم وجود دارد:
📌 واژه‌ها بی‌صاحب نیستند.
وقتی واژه‌ای را برای یک مفهوم تعریف کردیم، دیگر نمی‌توانیم در جای دیگری معنای متفاوتی به آن بدهیم و همچنان همان واژه را با خیال راحت استفاده کنیم. یک تعریف خوب باید جامع و مانع باشد؛ یعنی همه نمونه‌هایی را که واقعاً متعلق به مفهوم‌اند دربر بگیرد و چیزهایی را که متعلق به آن نیستند، بیرون نگه دارد.
برای همین، گاهی مشکل یک نظام دانشی نه کمبود مفهوم است و نه کمبود سند؛
📌فقط یک واژه دارد که همه از آن استفاده می‌کنند، اما هنوز کسی دقیقاً ننوشته است که یعنی چه.

⏳ این موضوع فقط به مستندات فنی مربوط نیست.
همین سؤال را می‌توان در #فلسفه_علم، طراحی سیستم، معماری، سازمان، نظریه‌های علمی و حتی باورهای شخصی دنبال کرد:
🔹 کدام اصل، واقعاً اصل است و کدام‌یک فقط توضیحی است که از نتایج به عقب برگشته؟
🔹 کدام تعریف، واقعاً مستقل است و کدام تعریف بدون استفاده از مفاهیم بالاتر قابل بیان نیست؟
🔹 کدام واژه را دقیقاً می‌دانیم و کدام واژه فقط به دلیل استفاده مکرر، آشنا به نظر می‌رسد؟
و شاید مهم‌تر از همه:

چند درصد از چیزهایی که فکر می‌کنیم «اصول» هستند، در واقع فقط نتیجه‌هایی هستند که بعداً به شکل اصل بازنویسی شده‌اند؟

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

🧠 برای گفتن چیزی، درباره چیزی که نمی‌خواهی بگویی حرف نزن!

تا حالا دقت کرده‌اید گاهی برای توضیح یک مفهوم، آن‌قدر درباره چیزهایی که نمی‌خواهیم بگوییم صحبت می‌کنیم که در نهایت خودِ مفهوم اصلی گم می‌شود؟ مثلاً می‌گوییم:

❌ «ما از X استفاده نمی‌کنیم، چون X این مشکل را دارد، آن مشکل را دارد و در شرایط Y هم مناسب نیست...»

از نظر ما کاملاً واضح است که نتیجه چیست:

گزاره X انتخاب ما نیست.

اما در متن، چه چیزی واقعاً اتفاق افتاده؟
ما X را وارد بحث کرده‌ایم، درباره‌اش توضیح داده‌ایم، ویژگی‌هایش را گفته‌ایم، رابطه‌اش را با چند مفهوم دیگر ساخته‌ایم و چندین بار آن را در ذهن مخاطب فعال کرده‌ایم.
بعد انتظار داریم مخاطب همه اینها را به خاطر بسپارد و در انتها فقط یک NOT روی X بگذارد!


🤔 این مسئله فقط مشکل هوشواره‌ها نیست.
انسان هم وقتی یک مفهوم در میان توضیح‌های طولانی، استثناءها، مقایسه‌ها و گزاره‌های منفی قرار می‌گیرد، ممکن است ارتباط میان مفاهیم را گم کند.
اصلاً یکی از بخش‌های مهم نگارش همین است:

چگونه یک مفهوم را با کمترین ابهام و با حفظ رابطه‌اش با مفاهیم دیگر منتقل کنیم؟

ما فکر می‌کنیم وقتی کلمات را درست انتخاب کرده‌ایم، مفهوم را هم درست منتقل کرده‌ایم؛ در حالی که بین این دو فاصله زیادی وجود دارد.
— یک نفر چیزی را در ذهن دارد.
— آن را به مفهوم تبدیل می‌کند.
— برای آن مفهوم کلمه انتخاب می‌کند.
— کلمه را داخل جمله قرار می‌دهد.
— جمله را داخل پاراگراف قرار می‌دهد.
و در هر کدام از این مراحل ممکن است چیزی از مفهوم اولیه تغییر کند یا ابهامی به آن اضافه شود. پس
📌 نوشتن صرفاً کنار هم گذاشتن کلمات نیست؛ طراحی مسیر انتقال یک مفهوم است.


⏳ شاید به همین دلیل، برای بیان وضعیت فعلی یک سیستم، بهتر باشد به جای:

❌ «از X استفاده نمی‌کنیم، چون...»

بگوییم:

✅ «سیستم از Y استفاده می‌کند، زیرا...»

یعنی تا جای ممکن:
آنچه را حقیقت دارد، مستقیم بگوییم؛ نه اینکه برای توضیح آن، مسیر ذهنی را از میان چیزهایی که حقیقت ندارند عبور دهیم.
این اصل در کتاب، مقاله، قانون، استاندارد، مستندات فنی و آموزش همیشه مهم بوده است.


⏳اما ظهور هوشواره‌ها یک چیز را خیلی واضح‌تر کرده است:
📌 متنی که می‌نویسیم فقط خوانده نمی‌شود؛ ممکن است از روی آن یک مدل ذهنی ساخته شود.
اگر آن متن پر از گزینه‌های ردشده، فرضیه‌های منسوخ، احتمالات آینده و مفاهیم رقیب باشد، شاید داریم ناخواسته context را از چیزهایی پر می‌کنیم که قرار نبوده بخشی از مدل نهایی باشند.


📍برای همین در مستندات #معمار (پست مرتبط) هم داریم به یک تفکیک ساده فکر می‌کنیم:
📄 Document
آنچه اکنون درست است.
📜 Changelog
آنچه تغییر کرده و چرا.
🤝 Handoff
آنچه ممکن است بعداً اتفاق بیفتد.
چون شاید بهترین مستند، مستندی نباشد که همه چیز را درباره همه چیز گفته باشد؛
بلکه مستندی باشد که چیز درست را، دقیقاً همان‌جایی که باید، گفته باشد.


🧠 حالا سؤال:
آیا همیشه برای توضیح یک مفهوم، لازم است درباره چیزهایی که آن مفهوم نیست هم صحبت کنیم؟
یا گاهی بهترین راه انتقال یک اندیشه این است که فقط بگوییم:

این است آنچه می‌دانیم.

🧠 بیایید کمی کمتر از هوشواره کمک بگیریم!

🔬 در دنیایی که هر روز بیشتر از قبل داریم کارهای خودمان را به هوشواره‌ها (AI Agent) می‌سپاریم، یک نگرانی کوچک دارم:
نکند در کنار برون‌سپاری کارها، کم‌کم خودِ فکر کردن را هم برون‌سپاری کنیم؟ 🤔
قرار نیست استفاده از هوشواره را کنار بگذاریم؛ اتفاقاً یکی از موضوعات اصلی بحث‌های ما همین استفاده درست از آن است. اما شاید بد نباشد گاهی قبل از اینکه سؤال را از هوشواره بپرسیم، خودمان چند دقیقه با آن کلنجار برویم.
از این به بعد می‌خواهم هر از گاهی چند سؤال کوتاه و باز از دل موضوعات مختلفی که در #معمار و Geniuses.Group روی آن‌ها فکر می‌کنیم مطرح کنم.

📌 قانون خاصی هم نداریم:
می‌توانید از هوشواره کمک بگیرید، سرچ کنید، با دوستانتان بحث کنید یا اصلاً جواب ندهید!
فقط یک پیشنهاد:
اول خودتان فکر کنید، بعد سراغ هوشواره بروید. 😉
اگر هم به جواب یا زاویه جالبی رسیدید، خوشحال می‌شویم آن را زیر همین پست با بقیه به اشتراک بگذارید؛ شاید ارزشمندترین بخش این تمرین، خودِ پاسخ نباشد، بلکه مسیر رسیدن به پاسخ باشد.

⏳خب، برای شروع این ۱۰ سؤال را امتحان کنیم:
🔹 ۱. Transaction
اگر یک Transaction هیچ پولی جابه‌جا نکند، آیا هنوز یک Transaction است؟
آیا اصلا واحد شمارش، داده‌ای وابسته به Transaction است؟ یا پیش فرض واحد پول تراکنش یک فرض میراثی گمراه کننده است؟
🔹 ۲. State
اگر چیزی را بتوانیم از دست بدهیم و سیستم همچنان دقیقاً همان رفتار درست را داشته باشد، آیا واقعاً بخشی از State سیستم بوده است؟
🔹 ۳. Agent یا عامل
آیا هر چیزی که بتواند از طرف یک موجودیت دیگر مسئولیتی را بر عهده بگیرد، یک Agent است؟
🔹 ۴. Attribute یا Edge؟
اگر یک ویژگی بتواند به‌صورت مستقل تغییر کند و روی رفتار سیستم اثر بگذارد، چه زمانی باید آن را Attribute بدانیم و چه زمانی یک Edge؟
🔹 ۵. Process یا فرآیند
آیا هر دنباله‌ای از Activityها یک Process است؟ اگر نه، چه چیزی یک دنباله را به Process تبدیل می‌کند؟
🔹 ۶. Service
اگر یک Service هیچ کار مستقیمی برای کاربر انجام ندهد، اما مسئول ایجاد یک تغییر در سیستم باشد، آیا هنوز Service است؟
🔹 ۷. Ownership
آیا مالکیت یک Attribute از یک موجودیت است یا رابطه‌ای مستقل میان دو موجودیت؟
🔹 ۸. Identity
اگر دو موجودیت تمام ویژگی‌های فعلی یکسانی داشته باشند، چه چیزی باعث می‌شود بگوییم هنوز دو موجودیت متفاوت‌اند؟
🔹 ۹. Architecture
آیا می‌توان معماری یک سیستم را بدون دانستن اینکه سیستم با چه زبان، دیتابیس یا سیستم‌عاملی پیاده‌سازی خواهد شد، به‌درستی تعریف کرد؟
🔹 ۱۰. Problem
اگر چیزی را بتوانیم به‌سادگی با یک راه‌حل فنی حل کنیم، آیا حتماً از ابتدا یک Problem فنی داشته‌ایم؟

🧐 قرار نیست جواب درست را سریع پیدا کنیم.
قرار است کمی تمرین کنیم که قبل از پرسیدن از دیگران، خودمان سؤال را زندگی کنیم. مثلا پیش فرض سوالات بالا را متوجه شویم و خود پیش فرض ها را هم در صورت لزوم بهشون فکر کنیم. مثلا با خوانده سوالات آیا متوجه شدید که پیش فرض خیلی از سوالات، نظریه گراف در ریاضی ولی برای فاز مدل کردن در علوم کامپیوتر هست؟
#تلنگر_ذهنی #تفکر #تفکر_انتقادی #معمار #هوشواره

🧠 اگر مفهوم #عامل را درست بفهمیم، احتمالاً مجبور شویم دوباره به #Process و #Concurrency هم نگاه کنیم
🔬 در پست قبلی درباره این صحبت کردم که چرا نباید با شنیدن #AI_Agent، مفهوم #Agent را از صفر و صرفاً در چارچوب هوش مصنوعی تعریف کنیم. اما این نگاه یک نتیجه جالب‌تر هم دارد.
اگر Agent یک مفهوم عمومی باشد، آن‌وقت عاملیت (Agency) فقط دربارهٔ هوشواره‌ها نیست؛ درباره نحوه‌ای است که یک موجودیت می‌تواند مسئولیت انجام چیزی را بر عهده بگیرد، تصمیم بگیرد و در چارچوب توانمندی و اختیار خود عمل کند. و وقتی این مفهوم را وارد #مدل_سازی کنیم، بعضی مفاهیم بسیار آشنای نرم‌افزار هم ناگهان شکل دیگری پیدا می‌کنند.

⏳ مثلاً #Process. ما معمولاً Process را از روی چیزهایی که برای اجرای آن ساخته‌ایم تصور می‌کنیم: Thread، Coroutine، Queue، Lock، Transaction، Scheduler و... در حالی که هیچ‌کدام از این‌ها ذات Process نیستند. Process ابتدا باید از خود progression، فعالیت‌ها، مشارکت‌کنندگان، مسئولیت‌ها، وابستگی‌ها، محدودیت‌ها و نتایجش فهمیده شود؛ بعد تازه می‌توانیم درباره مکانیزم اجرای آن تصمیم بگیریم.
همین نگاه، برداشت ما از #Concurrency را هم تغییر می‌دهد.
آیا واقعاً هر جا چند فعالیت هم‌زمان یا درهم‌تنیده داریم باید به سراغ Lock برویم؟
آیا مسئله این است که چند Thread داریم؟ یا شاید مسئله واقعی این باشد که چه کسی مسئول انجام یک فعالیت است و در هر لحظه چه عاملی مسئول وضعیت مورد نظر است؟
اگر بتوانیم مسئولیت را درست میان عامل‌های پردازشی تقسیم کنیم، شاید اصلاً نیازی به بسیاری از مکانیزم‌های هماهنگی که بعداً برای جلوگیری از تعارض ایجاد می‌کنیم نباشد. حتی ممکن است دو فعالیت روی یک CPU Core اجرا شوند و همچنان مسئلهٔ Concurrency داشته باشیم؛ بنابراین Core فیزیکی و Agent یا Worker منطقی را هم نباید یکی فرض کنیم.
اینجاست که به نظرم مفهوم Agent واقعاً ارزش خودش را نشان می‌دهد.

🚨 اگر به جای اینکه از مکانیزم شروع کنیم، از عاملیت، مسئولیت، اختیار، قابلیت و ارتباط میان عامل‌ها شروع کنیم، ممکن است بسیاری از راه‌حل‌هایی که امروز به‌عنوان «راه‌حل‌های استاندارد» می‌شناسیم، دیگر تنها گزینه‌های ممکن به نظر نرسند.
حتی ممکن است بفهمیم بعضی از پیچیدگی‌هایی که سال‌ها با Queue و Lock و Synchronization و Scheduler به سیستم اضافه کرده‌ایم، در واقع حاصل این بوده که خود مسئله را به‌درستی مدل (Modeling) نکرده‌ایم. این دقیقاً همان چیزی است که در #معماری برای ما اهمیت دارد:

از مکانیزم شروع نکنیم؛ ابتدا واقعیت را مدل کنیم.

🤔 حالا یک سؤال جدی‌تر:
چه کسی بدون اینکه از ابتدا به دنبال ساختن Actor، Worker، Coroutine، Thread Pool، Lock یا یک Scheduler باشد، به این نتیجه رسیده که می‌توان Process را ابتدا از منظر Agency، Responsibility و Ownership مدل کرد و سپس Actor یا Worker را به‌عنوان یکی از نمودهای اجرایی آن مدل به دست آورد؟
یعنی ابتدا بپرسیم:
چه عامل‌هایی داریم؟ هر عامل چه مسئولیتی دارد؟ چه چیزی را می‌داند؟ چه چیزی را می‌تواند تغییر دهد؟ در هر لحظه چه چیزی تحت مسئولیت کدام عامل است؟ و چه ارتباطی واقعاً میان عامل‌ها لازم است؟
شاید آن‌وقت #Concurrency دیگر مسئله‌ای نباشد که بعد از طراحی سیستم مجبور شویم برایش Lock بسازیم؛ بلکه تا حد زیادی نتیجهٔ طبیعی مدلی باشد که از ابتدا عاملیت و مسئولیت را درست فهمیده است.

🔗 اگر موضوع براتون جذاب هست میتونید پروژه #معمار (پست مربوطه) را دنبال کنید. یک مثال و یک شاهد عینی هم در کامنت‌ها برای همین پست می‌گذارم که درک بهتری از این ایده ایجاد بشه.

🧩 قطعه‌ی گمشده‌ی پازل موفقیت | بازخوانی متفاوت مهارت نرم

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

توی این دورهمی قراره با نگاهی متفاوت، نقش مهارت‌های نرم رو در شیوه‌ی فکر‌ کردن، ارتباط، همکاری، تصمیم‌گیری، رشد شغلی و تجربه‌ی کار حرفه‌ای بررسی کنیم.

🎙 مهمان این نشست: امید حکایتی
مدیر ارشد تکنولوژی Geniuses.Group، پژوهشگر و معمار نرم‌افزار. امید با تمرکز بر فلسفه‌ی علم، علوم شناختی و مدل‌سازی، سال‌هاست روی بازتعریف مفاهیم بنیادی مهندسی نرم‌افزار کار می‌کنه.

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

📍ثبت‌نام:
https://jameeno.com/events/019ff111-8db9-70de-ac50-69ae8f123d0b

🔗 پروفایل لینکدین امید حکایتی:
https://www.linkedin.com/in/omidhekayati?utm_source=share_via&utm_content=profile&utm_medium=member_ios

یک باگ عجیب خورد تلگرام، من پستی را در کانال Geniuses Group گذاشتم ولی در گروه چت وابسته به کانال نیومد! خودم دستی هم فرستادم، ببینم درست میشه کامنت گذاشتن ولی نشد. فکر می‌کردم تلگرام باگ خیلی کم داره که دیده نمیشه، ولی مثل اینکه باگ‌ها همه جا هستند 😂😂

پ.ن: البته من نقد خیلی جدی به نحوه مدل کردن TimeLine و Content به عنوان دو جز اصلی همه سیستم‌هایی محتوایی در تلگرام و دیگر شبکه‌های احتماعی دارم که در جلسات #خوانش کتاب‌ها بهشون اشاره‌هایی داشتم، پس جوری القا نشه که من گفتم تلگرام خیلی خوبه و جای بهتر شدن نداره 😉

🧠 اهمیت درک عمیق از مفهوم کلمه عامل (Agent) برای حل مشکلات کار کردن با #هوشواره ها (AI)
🔬این روزها تقریباً همه دربارهٔ AI Agentها صحبت می‌کنند؛ ابزارهای جدید معرفی می‌شوند، دوره‌های آموزشی برگزار می‌شود و هر روز اصطلاحات تازه‌ای وارد اکوسیستم می‌شوند. اما احساس می‌کنم قبل از اینکه بخواهیم یاد بگیریم چگونه با AI Agentها کار کنیم، لازم است یک قدم به عقب برگردیم. شاید مسئله اصلاً هوشواره نباشد. شاید مسئله این باشد که ما هنوز مفهوم Agent (#عامل) را به‌درستی #مدل نکرده‌ایم.

🚨وقتی کلمهٔ Agent را می‌شنویم، ذهنمان مستقیم به سمت #هوش_مصنوعی می‌رود، در حالی که Agent مفهومی بسیار قدیمی‌تر و عمومی‌تر است. هر موجودیتی که از طرف یک سیستم (شخص، سازمان، ...)، مسئولیتی را بر عهده می‌گیرد، یک Agent است. اگر این تعریف را بپذیریم، آن وقت AI Agent فقط یکی از انواع Agentها خواهد بود؛ همان‌طور که یک کارمند، یک پیمانکار، یک نرم‌افزار، یک سرویس یا حتی یک سازمان نیز می‌تواند نقش یک Agent را ایفا کند. و دقیقاً همین‌جا است که نگاه ما به #مسئله تغییر می‌کند. یک #تلنگر_ذهنی و سوال باز #فلسفه_ذهن را هم مطرح کنیم که حتی میشه بدن انسان را هم به نوعی عامل هویت اون فرد در نظر بگیریم.
اگر AI Agent را مفهومی کاملاً جدید تصور کنیم، ناخواسته بخش بزرگی از دانش انباشتهٔ گذشته دربارهٔ تعامل با Agentها را کنار می‌گذاریم و دوباره همان اشتباهات را با نام‌های جدید تکرار می‌کنیم.

⏳بخش بزرگی از مشکلاتی که امروز به هوشواره نسبت می‌دهیم، در واقع سال‌ها قبل از ظهور هوشواره هم وجود داشته‌اند.
- وقتی مسئولیت را مبهم واگذار می‌کنیم...
- وقتی انتظار خروجی را شفاف تعریف نمی‌کنیم...
- وقتی زمینهٔ لازم را منتقل نمی‌کنیم...
- وقتی دانش سازمان در ذهن افراد باقی می‌ماند و به دانش مشترک تبدیل نمی‌شود...
نتیجه معمولاً قابل پیش‌بینی نیست؛ چه طرف مقابل یک انسان باشد، چه یک هوشواره. دقت کنیم هوشواره مشکل جدیدی ایجاد نکرده است؛ فقط کیفیت #مدل_ذهنی و کیفیت #مدیریت_دانش ما را با وضوح بیشتری نمایان کرده است.

⏳به همین دلیل، شاید بهتر باشد به جای اینکه فقط دربارهٔ نقش‌های کاذب (False Classification) منتسب به مهندسی مثل Prompt Engineering یا Harness Engineering صحبت کنیم، دربارهٔ اصول تعامل با هر Agent صحبت کنیم؛ اصولی که سال‌ها قبل از ظهور هوشواره نیز وجود داشته‌اند و احتمالاً سال‌ها بعد از تغییر فناوری‌های امروز نیز معتبر خواهند ماند. در چند کامنت زیر همین پست، سعی می‌کنم دربارهٔ همین اصول صحبت کنم؛ از #تفویض_اختیار و نحوهٔ #مستندسازی از نگارش درخواست‌ها گرفته تا انتقال زمینه، مرزهای مسئولیت، معیارهای پذیرش و نقش #مدیریت_دانش در تعامل با عامل‌ها.

⏳شاید هنگام خواندن این متن با خودتان گفته باشید:
- ما هم مدام خروجی‌هایی می‌گیریم که با انتظارمان فاصله دارند.
- هر بار باید دوباره همه چیز را توضیح بدهیم.
- افراد مختلف برداشت‌های متفاوتی از یک درخواست دارند.
- دانش پروژه بیشتر در ذهن افراد است تا در مستندات.
- با وجود استفاده از هوشواره، کیفیت خروجی تیم بهتر نشده، فقط سرعت تولید بیشتر شده است.
اگر چنین نشانه‌هایی را در #سازمان خود می‌بینید، احتمال دارد مسئلهٔ اصلی نه هوشواره باشد و نه حتی افراد تیم. این‌ها معمولاً نشانه‌هایی از ضعف در #مدیریت_دانش، نبود یک #چارچوب_توسعه مشترک، ابهام در تعریف مسئولیت‌ها یا ضعف در مدل‌سازی مسائل سازمان هستند. این‌ها با تعویض ابزار حل نمی‌شوند؛ نیازمند اصلاح شیوهٔ فکر کردن، انتقال دانش و طراحی فرآیندهای توسعه هستند.

🔗 در Geniuses.Group نیز دقیقاً همین دغدغه را دنبال می‌کنیم؛ کمک به سازمان‌ها برای ساختن سیستم‌هایی که پایداری آن‌ها تنها به فناوری وابسته نباشد، بلکه بر پایهٔ مدل‌های ذهنی دقیق‌تر، مدیریت دانش بهتر و تعامل مؤثرتر میان عامل‌ها شکل بگیرد.

اگر به بازاندیشی بنیادین در نحوه ساخت نرم‌افزار علاقه دارید، پروژه #معمار ارزش دنبال کردن داره 🧐

اکثر پروژه‌های نرم‌افزاری بر پایه یک زبان یا یک سیستم‌عامل خاص طراحی می‌شن؛ یعنی اون زبان یا OS هست که قواعد بازی رو تعیین می‌کنه. Memar (معمار) این رابطه رو برعکس می‌کنه: در این چارچوب، فریم‌ورک مرجع اصلی تصمیم‌گیری معماری‌ست و زبان برنامه‌نویسی (Khayyam)، سیستم‌عامل (PersiaOS) و پروتکل‌های شبکه (Chapar، GP، sRPC) صرفاً کامپوننت‌هایی هستن که در دل همون معماری تعریف می‌شن، نه برعکس.
یکی از دلایل مهم وجود چنین چارچوبی، توسعه در کنار #هوش_مصنوعی هست. وقتی قواعد معماری به‌صورت صریح و از پیش مشخص تعریف شده باشن، هوش مصنوعی برای پر کردن جاهای مبهم مجبور نیست خودش پیش‌فرض بسازه؛ پیش‌فرضی که می‌تونه مسیر توسعه رو دچار خطا کنه. ساختار مشخص یعنی مسیر تصمیم‌گیری هم برای انسان و هم برای ابزارهای هوش مصنوعی روشن‌تره.
این پروژه چند سال هست به‌صورت مستقل در حال طراحی و توسعه‌ست. هدف ساختن یک محصول با عجله نیست؛ ساختن زیرساختی پایدار و چندنسلی هست. تصمیمات معماری مستندسازی و نقد می‌شن.

جزئیات بیشتر در کامنت‌ها

#خشم ما از #جنایت های بیشمار حکومتی جنایتکار که به هیچ یک از اصول #حقوق_بشر پایبند نیست، در کلمات گنجانده نمی‌شود.
چون نگارنده اعتقاد شدیدی به چرخه خشونت فزاینده داره، به هیچ عنوان قصد افزایش حس خشم خود و دیگران را نداره ولی واقعا اتفاق‌های این چند هفته خارج از ظرفیت فکری و تحملی هر انسان آزادی هست. از طرفی قطعی #اینترنت و #فیلترینگ هیچ تاثیری بر هیچ اتفاق تروریستی و امنیتی مورد ادعای این حکومت بی‌خرد نداره، صرفا برگ زرین دیگری از رفتار غیر عقلانی این حکومت فشل می‌باشد که نشان میده ذره‌ای #خرد دیگر در بدنه تصمیم‌گیر آن وجود ندارد که صرفا بحران تولید میکند نه ظرفیت #توسعه و رشد جامعه.
امیدوارم هر چه سریعتر این روزهای دردآور به پایان برسه و روزهایی سراسر از زیبایی همراه با امید به زندگی بهتر برای همه پیشرو باشه.

#علم اگر اشتباه کند اشتباهش را خواهد پذیرفت.
اما مذهبی تو را می‌کشند
تا ثابت کنند #دین هرگز اشتباه نمی‌کند.

“#Science may be wrong. #Religion never is.”
So they kill you to prove it.
— Bertrand Russell

سقوط، تثبیت کیفیت پایین زندگی یا نجات جامعه در قلمروی جغرافیای ایران
در جایگاه #نقد که نوعی انتقال #دانش و #بینش می‌باشد، اگر گوش شنوایی باشد، منتقد قصد ایجاد #تلنگر_ذهنی در مخاطب (های) خود را دارد، نه اجبار به تغییر در مواضع. متاسفانه در خیلی از جایگاه‌ها، نقد حتی با رعایت اصول (علمی، شفاف، ...) شنوایی ندارد ولی در هر حال، وظیفه ما اطلاع‌رسانی پیش‌بینی‌های دقیق مطابق #مدل های #عملی می‌باشد.
از دید نگارنده، نیاز به نگارش متن زیاد نیست، دو جدول پیوست (منبع جدول یک و جدول دو از این مقاله) به خوبی #کیفیت_حکمرانی، #حکومت فعلی این قلمرو را نشان میدهد که حتی در شرایط خوشبینانه و ثبات وضعیت اقتصادی، #ذهن مردم عادی با اعداد بزرگ که اصولا برای این کار ساخته نشدند تا آخر عمر آنها مخدوش خواهد بود. شما را نمی‌دانم ولی بنده به هیچ عنوان آماده استفاده از اعداد میلیونی برای خرج‌کرد روزانه نیستم، اصولا ذهنم همیشه در حال تلاش برای مبارزه با این اعداد هست چون هوییت این اعداد بسیار بزرگ برای کار دیگری ساخته شده است. راهکارهایی مثل حذف صفر از پول رسمی هم نوش‌دارو بعد از مرگ سهراب خواهد بود، تغییر ذهنیت کار آسانی نخواهد بود.

گاهی وقت ها #رها_کن
رها کردن، فضایی برای فرصت‌های بهتر ایجاد می‌کنه. ولی باید یادمون باشه مقاومت در برابر رها کردن، غریزه بقا (#فرگشت) است. پس نیاز به #یادگیری و تمرین کردن داریم، ولی ارزششو داره، رها کردن می‌تونه یکی از قدرتمندترین مهارت‌هایی باشه که می‌تونیم بدست بیاریم.
آژان چاه (Ajahn Chah) راهب بودایی می‌گوید: «اگر کمی رها کنی، کمی آرامش خواهی یافت. اگر زیاد رها کنی، آرامش زیادی خواهی یافت. اگر کاملاً رها کنی، آرامش و آسایش مطلق خواهی یافت.»

ویدئو پیوست، اجرای مشترک سینا ساعی و سروین ضابطیان در مرحله فینال رئالیتی شوی کارناوال با اجرای قطعه با مضمون رها کردن هست، پیشنهاد می کنم تماشا کنید و لذت ببرید.

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

یک چیزی که موقع حل کردن، فکر کردن به موضوعی فراموشش میکنم اینکه من ممکنه اون المان/ویژگی را از یک #سیستم کلی جدا کنم (ساده سازی می کنم). بعد اینکه متوجه اش شدم، همون مدلی که جدا کردم و ساده کردم برای یادگیری را می‌خوام که efficient کنم. یادم میره که این المان جدا و ساده شده و هر بهبودی توی این بخش باعث بهبود در کل سیستم نمیشه.

شما هم اگر از هر زاویه ای، موضوعی مرتبط با ارتقا #تفکر (قطعا انواع تفکر مثل #تفکر_سیستمی، #تفکر_انتقادی و ...) و #اندیشیدن برخورد کردید با ما به اشتراک بگذارید. مشتاقانه منتظر نقطه نظرات شما هستیم.

🧠چرا تقابل کاذب (سندروم "VS") گفتمان در اکوسیستم های توسعه رو مسموم می‌کنه؟

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

🔬اخیراً در جاهای مختلف دست نوشته هایی را دیدم که اصلا انتظار این مدل نگارش‌ها را نداشتم و نگارنده ها دنبال مقایسه سیب و پرتقال هستند، شاید در ذات بگید میشه مقایسه کرد، منم میگم باشه میشه ولی هدف چی هست؟ مثلا جایی تیتر زدن که آیا مایکروسرویس و DDD برای تیم‌های کوچک مناسبه؟ (تقابل DDD با تیم های کوچک) یا رحیم فیروزی عزیز در کانالش نوشته "سادگی یا اسکیلبیلیتی؟" و جایی نوشته شد بیاین در مورد "FP vs OOP" صحبت کنیم. اما چرا همیشه این سندروم "VS" اینقدر جذاب مطرح میشه در صورتی که ترکیبی از مغالطه‌هایی مثل false dichotomy (#دوگانه_کاذب) و confirmation bias، بحث‌ها رو ساده‌انگارانه می‌کنه و راه گفتمان واقعی رو می‌بنده.
⏳در پست DDD مثل همیشه قصد اینه بگن DDD تقریبا همیشه برای توسعه در سازمان های large scale هست! حتی برای اینکه جلوی بعضی ایرادات را از همان ابتدا بگیرند، تعریف های عجیبی از مدل سازمان مورد نظر میدن که بزرگی سازمان یا تعداد کارمند را صرفا قبول ندارند! انتخاب اشتباه موضوع باعث شده همش دنبال توجیح باشند. اینجا قصد نداریم بگیم DDD بدرد چه نوع توسعه ای می خوره چون اعتقاد راسخ دارم که این رویکرد توسعه بدرد هر نوع توسعه نرم افزاری می خوره و اصلا ارتباطی به سایز پروژه یا سازمان نداره. این موضوع را به شکل عمیق در آینده ای نزدیک در جلسات #خوانش کتاب DDD اریک ایوان مطرح خواهیم کرد.
⏳در مقاله رحیم عزیز واقعیت اینه سادگی و اسکیلبیلیتی دو موضوع کاملا مجزا و حتی کاملا بی ربط به هم هستند. هر چند نیاز بود رحیم عزیز مشخص کنه منظورش از "سادگی" دقیقا چی هست؟ چون وقتی در مقابل مقیاس پذیری قرارش میدیم چندین برداشت میشه ازش داشت، مثلا من احساس کردم منظورش اینه در ابتدای توسعه هر مدلی دوست داری برو جلو، بعدا که نیاز شد تغییرش میدی! ولی این تفکر آیا با اصول #علمی در یکسو هست؟ اگر همه مهندسان دنیا اینو بگن چه بلایی سر #پایداری جامعه ها میاد؟ فکر کنید یک تیم توسعه ساختمان بگن فعلا یک طبقه ساختمان بسازیم، اگر استقبال خوب بود بعدا 20 طبقه دیگه روی این ساختمان میسازیم! این نوع نگاه ممکنه نشان از کمبود دانش موثر در توسعه بخصوص #توسعه_پایدار باشه.
⏳در موضوع FP و OOP هم همین‌طوره مثلا FP از اصول OOP مثل encapsulation عملا استفاده می کنه و اونا تکمیل‌کننده‌ن همدیگن نه چیزی در تقابل!

💬 اوضاع وقتی بدتر میشه که گوینده یا نگارنده در مقام توجیح بازم بخواد موضوعات بی ربط دیگر را به مسیر گفتمان بیاره، مثلا با آوردن صفت هایی مثل over-engineering (پیچیدگی بی‌جا) یا micro-optimization (بهینه‌سازی‌های جزئی بی‌فایده) فاجعه‌ای تمام عیار رقم می خوره. کسی دانش و بینش ضعیفی داره به طور مثال نمی تونه تفاوت complicated و complex (همان‌طور که در تئوری سیستم‌ها می‌گن، پیچیدگی ذاتی نیست، بلکه از تعاملات می‌آد) را تشخیص بده و حتی ظرافت #سوال_باز بودن این حوزه ها را درک کنه و اصولا با مفهوم خود کلمه #سیستم آشنایی کافی را ندارد و حرف از سیستم (محصول) پیچیده میزنه. یا جزییات و تفاوت های ساده‌سازی واقعی (simplification) رو از ساده‌انگاری (oversimplification) تشخیص نمیده ولی با ابهام کامل قصد داره مسیر روشنی را به دیگران هدیه بده! 😉
وای به روزی که این شخص تصمیم‌گیر باشد! سازمان (جامعه، شرکت، تیم، ...) رو به مسیر اشتباه می‌بره و هیچ‌کس جرات نمی‌کنه بگه "شاه لخته!" 😅

🔗 بیاید بحث‌هامون رو بر اساس مکمل بودن و واقعیت بسازیم، نه تقابل‌های کاذب و ساختگی.
🌟 نظر شما چیه؟ 🌟
🌟 شما کدوم "VS" بی‌ربط دیگه دیدید؟ کامنت بذارید! 🌟

🔗 در پست بعد موضوع مهم و خیلی مرتبط با این حوزه یعنی #یادگیری_تطبیقی (Adaptive Learning) را کمی بیشتر مطرح می کنیم که یادمون باشه یادگیری، اصول خیلی مهمی داره و نباید دنبال مقایسه های اشتباه باشیم و هر موضوعی و هر فردی نیاز به بررسی و توسعه یکتایی داره.

🧠 #تکنولوژی (#فناوری) چیست؟

🔬از دید نگارنده بهترین تعریف برای فناوری میشه "دانش (تکنیک‌ها، مهارت‌ها، روش‌ها و فرایندها، ...) توسعه (ایجاد یا تغییر) سیستم ها (ابزارها، دانش ها، ...) برای تحقق اهداف مورد نظر". جالب شد، بازم کلمه سیستم رخ نمایی کرد! کلمه دانش در تعریف را هم میشه به #علم در تعریف #مهندس و #مهندسی (در این نشست در مورد تعریف مهندس صحبت کردیم) ارتباط داد و اگر متخصص های حوزه فناوری از علم در توسعه فناوری استفاده کنند، قطعا سیستم های با کیفیت تری توسعه داده می شود.
🪄از این به بعد هر جا با کلمه تکنولوژی (تک، ...) برخورد کردید با نگاهی دقیق تر موضوع را بررسی و مورد نقد و کنکاش قرار بدید. مثلا بهتر می توانیم درک کنیم که چرا در یک سازمان CTO (Chief Technology Officer) بایستی حتما دانش به شدت موثر و نسبتا عمیقی از مفاهیم مرتبط با سیستم های در حال توسعه داشته باشد، رفع مسئولیت از خود با عنوان "کمبود دانش موثر" قابل پذیرش نیست و کسی باید قبول مسئولیت کند که توانایی کسب یا نقد دانش منتقل شده از متخصص حوزه مرتبط را داشته باشد. اینجا قبلا عمیق توضیح دادیم.
🪄یادمون باشه فناوری محدود به موجودیت های عینی (موبایل، کامپیوتر، تلسکوپ، ...) نمیشه و موضوعات ذهنی (سازمان، گفتمان، ...) هم در این دسته می توانند قرار بگیرند.
🪄 در #فلسفه_علم هم تاکید می شود که مرز بین علم و فناوری برای هر اندیشمندی باید مشخص شود. یادمون باشه فناوری ارتباط عمیقی (سیستم، ...) با #تفکر_سیستمی و #تفکر_انتقادی که در گروه هم بهشون زیاد میپردازیم، دارد.

⏳راستش این پست را خیلی وقت بود می خواستم نگارش کنم ولی جنگ نالازم و پیش بینی پذیر (توییت بنده چندین ماه قبل از جنگ) گذشته، حوصله نگارش را گرفته بود، اتفاقاتی که به راحتی میشد از وقوع آنها جلوگیری کرد فقط و فقط اگر اراده و عواقب تصمیمات و صحبت های هر فرد در هر جایگاهی در #حکومت جمهوری اسلامی مشخص و گریبان گیر آنها بود. ولی بیایید #جنگ را به همین موضوع فناوری ارتباط بدیم. در ذات جنگ هم مانند هزاران موضوع دیگر یک فناوری محسوب می شود. شاید شنیدید که میگن اگر جمهوری اسلامی مثلا به فلان رادار یا هواپیما دسترسی داشت، قطعا برنده جنگ بود و ... این مدل گزاره ها صرفا از یکسری مغزهای کوچک زنگ زده تراوش می کنه! آیا درست تر این نیست که یادمون باشه تکنولوژی در خدمت کیفیت زندگی انسان ها همیشه باید باشه؟ یعنی آیا فناوری دیگه مثل #گفتمان را از ما گرفتند که که به بدترین فناوری ها متوسل بشویم؟ باز نکته مهم این هست که یادمون باشه هر تکنولوژی آداب و رسوم خودش برای استفاده را دارد، یعنی نمی شود حرف از گفتمان زد ولی در عمل به دنبال وقت خریدن و گذر زمان باشیم!
⏳یا بحث #سیاست گذاری جدید در بعضی از شهرهای ایران مبنی بر ممنوعیت غیر مستقیم داشتن حیوان خانگی! واقعا چرا اینقدر سطحی نگر؟؟ واقعا نمی دانند:

سبک زندگی خود نوعی تکنولوژی می باشد

شاید در نگاه اول این گزاره به شدت عجیب باشد. تکنولوژی شاید در ذهن خیلی از ما ارتباط غیر مستقیم با سبک زندگی داشته باشه ولی ارتباط مستقیم بهش دادن برای خیلی ها ممکنه عجیب باشه! ولی بیایید برای روشن تر شدن موضوع بر اساس تعریف بالا که نسبتا جامع و مانع می باشد موضوع را بیشتر بررسی کنیم. یادمون باشه سبک زندگی اگر به عنوان یک سیستم بهش نگاه کنیم، در تفکر سیستمی گوشزد میشه که باید به ابعاد مختلف ماجرا دقت بشه و نمیشه به فناوری های دیگر مانند خانواده، حریم خصوصی، ... را نادیده بگیریم و به شکل ساده انگارانه سعی در تغییر صرفا سبک زندگی داشته باشیم.
⏳ #تجربه_زیسته خود حکومت در قلمروی جغرافیای ایران و حتی جهان ثابت کرده منع انسان ها از چیزی به شکل #قانون با #ضمانت_اجرایی پلیس اصولا با شکست مواجه می شود ولی همانطور که همیشه می گوییم تا وقتی روی #تجربه_زیسته بیش از اندازه خودش حساب باز کنیم، همین آثار مخرب را خواهد داشت. یعنی درس نگرفتن بدلیل عدم وجود خروجی مناسب به شکل و اصولی که در #علم بهشون دست یافته ایم. در #تجربه_علمی ما سعی در ایجاد چندین خروجی به عنوان گزاره ها و در ادامه تبدیل به ترجیحا یک خروجی موثر به نام #فرضیه و در ادامه تبدیل آن به #نظریه داریم که به شکل خیلی موثر و راحت قابلیت انتقال بین انسان ها را دارا باشد بدون نیاز به مطالعه در مورد چیستی (#تفکر_انتزاعی) برای همه انسان های درگیر در موضوع. پس در خصوص این موضوع علوم مختلف مثل علوم اجتماعی، علم حقوق، حکمرانی، سیاست و ... به شکل کاملا دقیق موضوعات مرتبط را مطرح کرده اند و نیاز به مراجعه به تجربه زیسته آن هم در سیستم در حال کار نیست! دوستان توسعه نرم افزار می دانند که چقدر کار بدی هست در کدهای یک نرم افزار در حال اجرا بخواهیم تغییری ایجاد کنیم!


🔗 شما تا حالا به فناوری به چه شکلی نگاه میکردید؟ آیا نگاه مشترکی با نگارنده داشتید؟