Geniuses Group

🔗 #خوانش کتاب Learning Systems Thinking: Essential Non-Linear Skills and Practices for Software Professionals از نشر o'reilly 🤝 پس از بررسی و همفکری با همراهان همیشگی، #کتاب بعدی برای خوانش گروهی انتخاب شد. هر چند اینبار بر خلاف دفعه های قبل هنوز خوانش کتاب قبل یعنی DDIA تمام نشده است ولی به دلیل اهمیت موضوع و نیاز به مطرح شدن هر چه سریع تر موضوع خوانش را موازی شروع خواهیم کرد. در کامنت های همین پست، جزییات شرکت در جلسات و صوت ضبط شده جلسات را قرار میدیم. مثل همیشه اگر فرصت شرکت در جلسات را نداشتید می تونید در فصل 5 کانال در کست باکس هم صوت جلسات این کتاب را گوش بدید و اگر سوال، ابهام یا نقد/پیشنهادی بود همینجا مطرح کنید. 🧠 در جلسات قصد هست همانطور که کتاب در جای، جای آن هم تاکید داره با نحوه #تفکر کردن و با نگاهی عمیق تر به #تفکر_سیستمی آشنا بشیم که با توجه به اینکه #نرم_افزار در ذات در دسته #سیستم_پیچیده قرار میگیرد و در عمل در تعامل با سیستم های پیچیده دیگر مثل جوامع انسانی، اقتصاد و ... در ارتباط هست، عملا فقدان این تفکر در الگوهای ذهن #توسعه_دهنده ها مساوی با #تصمیم_گیری های با ریسک به شدت بالا در جهت تصمیم گیری های ضعیف خواهد بود. به هیچ عنوان یادگیری این مهارت تفکر کردن همراه با تمرین های مرتبط را از دست ندهید. یادمون نره صرفا خواندن سریع اینگونه منابع (مثل این کتاب) کمک چندانی به ما نمی کنه و نیاز به خوانش عمیق داریم، ما هم سعی می کنیم خوانشی کاملا عمیق ارائه بدیم. ✨ Self-awareness, also known as metacognition, is the ability to understand and adapt your thinking patterns. Practicing with your own thinking is, perhaps unsurprisingly, the foundation of thinking in systems. ✨ In a world so interconnected by software, systems thinking is an essential skill for navigating the compounding sociotechnical complexity in software development.

🧠 #تفکر_سیستمی و #تفکر_انتقادی دو رکن جدانشدنی حل مسائل (بخصوص مسائل پیچیده) هستند. 🔬در مدل سازی و تفکر بر پایه نظریه سیستم ها، یکی از موضوعات واضح و بدیهی تا جای امکان کنار گذاشتن هر نوع پیش فرض (بررسی بیشتر در #تفکر_انتزاعی) در مدل کردن است. یکی از اهداف مهم تفکر انتقادی، شناسایی پیش فرض ها می باشد، چیزی که در مدل کردن یک سیستم برای درک و احیانا تغییری در سیستم بسیار مهم هست. ⏳توی دنیای امروز که سیستم‌ها هر روز پیچیده‌تر (complex) می‌شن، توانایی مدل‌سازی دقیق و بدون #سوگیری برای درک و بهبود این سیستم‌ها، یه مهارت کلیدی برای تصمیم گیران ارشد و کساییه که می‌خوان به سطوح بالای دانش و مهارت (حل مسئله) برسند. تفکر سیستمی به ما این امکان رو می‌ده که سیستم‌ها رو به صورت یه کل یکپارچه ببینیم و تعامل بین اجزای مختلفشون رو تحلیل کنیم. اما این مدل‌سازی وقتی واقعاً اثرگذار می‌شه که بتونیم پیش‌فرض‌های ذهنی‌مون رو با تفکر انتقادی به چالش بکشیم و از واقعی بودن پایه‌های #مدل هامون مطمئن شیم. 💬 این موضوع توی توسعه نرم‌افزار خیلی ملموس‌تره. فرض کنیم توی طراحی یه سیستم، به اشتباه "اینروزا همه کاربران به اینترنت پهنای باند بالا و پایدار دسترسی دارن." اگه این پیش‌فرض رو نقد نکنین، ممکنه توسعه به نحوی پیش بره که برای بارگذاری داده‌ها بهینه نباشه و توی دنیای واقعی، عملکرد سیستم رو برای خیلی از کاربران مختل کنه. اینجا تفکر انتقادی به کمک میاد تا این فرض رو زیر سؤال ببره و با داده‌های واقعی، شما رو به سمت توسعه (طراحی یه معماری) انعطاف‌پذیرتر و مقیاس‌پذیرتر هدایت کنه، مثلاً با درک عمیق تر مفهوم Cache و مفاهیم و تکنیک های مرتبط مثل lazy loading یا حتی بازطراحی فرآیندهای نرم‌افزار برای کاهش پیچیدگی محاسباتی یا انتقال بار پردازشی به client یا edge نودها و کاهش انتقال اطلاعات در شبکه های غیر پایدار اینترنت. 💬 یا در موضوع #حکمرانی #قانون فکر کنیم که همیشه #حکومت ها نیاز هست در پیاده سازی و نظارت به اجرای قانون باید به شکل انحصاری عمل کنند تا بتوانیم مطمئن بشیم قوانین (خواسته های جمعی آحاد جامعه) پس از نگارش به شکل متون با مدل مشخص، به شکل صحیح در جامعه، جاری می شوند. بذارید مثال عینی بزنیم که بشه مبنای فکری ما برای ایجاد تمرین های مشابه. فرض بگیرید جامعه به دلایل مختلف برای شناسایی وسای

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

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

🧠 اگر مفهوم #عامل را درست بفهمیم، احتمالاً مجبور شویم دوباره به #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 به سیستم

🧠 بیایید کمی کمتر از هوشواره کمک بگیریم! 🔬 در دنیایی که هر روز بیشتر از قبل داریم کارهای خودمان را به هوشواره‌ها (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 اگر دو موجودیت تمام ویژگی‌های فعلی یکسانی داشته باشند، چه چی

🧠 برای گفتن چیزی، درباره چیزی که نمی‌خواهی بگویی حرف نزن! تا حالا دقت کرده‌اید گاهی برای توضیح یک مفهوم، آن‌قدر درباره چیزهایی که نمی‌خواهیم بگوییم صحبت می‌کنیم که در نهایت خودِ مفهوم اصلی گم می‌شود؟ مثلاً می‌گوییم: ❌ «ما از X استفاده نمی‌کنیم، چون X این مشکل را دارد، آن مشکل را دارد و در شرایط Y هم مناسب نیست...» از نظر ما کاملاً واضح است که نتیجه چیست: گزاره X انتخاب ما نیست. اما در متن، چه چیزی واقعاً اتفاق افتاده؟ ما X را وارد بحث کرده‌ایم، درباره‌اش توضیح داده‌ایم، ویژگی‌هایش را گفته‌ایم، رابطه‌اش را با چند مفهوم دیگر ساخته‌ایم و چندین بار آن را در ذهن مخاطب فعال کرده‌ایم. بعد انتظار داریم مخاطب همه اینها را به خاطر بسپارد و در انتها فقط یک NOT روی X بگذارد! 🤔 این مسئله فقط مشکل هوشواره‌ها نیست. انسان هم وقتی یک مفهوم در میان توضیح‌های طولانی، استثناءها، مقایسه‌ها و گزاره‌های منفی قرار می‌گیرد، ممکن است ارتباط میان مفاهیم را گم کند. اصلاً یکی از بخش‌های مهم نگارش همین است: چگونه یک مفهوم را با کمترین ابهام و با حفظ رابطه‌اش با مفاهیم دیگر منتقل کنیم؟ ما فکر می‌کنیم وقتی کلمات را درست انتخاب کرده‌ایم، مفهوم را هم درست منتقل کرده‌ایم؛ در حالی که بین این دو فاصله زیادی وجود دارد. — یک نفر چیزی را در ذهن دارد. — آن را به مفهوم تبدیل می‌کند. — برای آن مفهوم کلمه انتخاب می‌کند. — کلمه را داخل جمله قرار می‌دهد. — جمله را داخل پاراگراف قرار می‌دهد. و در هر کدام از این مراحل ممکن است چیزی از مفهوم اولیه تغییر کند یا ابهامی به آن اضافه شود. پس 📌 نوشتن صرفاً کنار هم گذاشتن کلمات نیست؛ طراحی مسیر انتقال یک مفهوم است. ⏳ شاید به همین دلیل، برای بیان وضعیت فعلی یک سیستم، بهتر باشد به جای: ❌ «از X استفاده نمی‌کنیم، چون...» بگوییم: ✅ «سیستم از Y استفاده می‌کند، زیرا...» یعنی تا جای ممکن: آنچه را حقیقت دارد، مستقیم بگوییم؛ نه اینکه برای توضیح آن، مسیر ذهنی را از میان چیزهایی که حقیقت ندارند عبور دهیم. این اصل در کتاب، مقاله، قانون، استاندارد، مستندات فنی و آموزش همیشه مهم بوده است. ⏳اما ظهور هوشواره‌ها یک چیز را خیلی واضح‌تر کرده است: 📌 متنی که می‌نویسیم فقط خوانده نمی‌شود؛ ممکن است از روی آن یک مدل ذهنی ساخته شود. اگر آن متن پر از گزینه‌های ردشده، فرضیه‌های منسوخ، احتمال

🧠 بنیان، از نتیجه‌هایش تعریف نمی‌شود! در فاز #مدل_سازی در ساختن هر نظام دانشی (#معمار)، از یک کتاب و نظریه علمی گرفته تا مستندات یک سیستم، روش یک سازمان یا حتی مجموعه‌ای از باورهای شخصی، یک اصل ساده وجود دارد: 📌 چیزی که قرار است پایه باشد، نباید برای تعریف خودش به چیزی وابسته باشد که روی همان پایه بنا شده است. اما گاهی این وابستگی آن‌قدر آرام شکل می‌گیرد که اصلاً متوجه آن نمی‌شویم: — لایه‌ای را می‌سازیم که قرار است بنیادی باشد؛ — بعد برای توضیح بخشی از آن، از مفهومی در لایه بالاتر کمک می‌گیریم؛ — و آن لایه بالاتر هم در نهایت بر همان لایه پایه بنا شده است. — در ظاهر فقط یک ارجاع ساده ساخته‌ایم. — اما در واقع، جهت وابستگی را برعکس کرده‌ایم. اگر A پایه B باشد، B می‌تواند بر اساس A مفهوم جدیدی بسازد؛ اما تعریف بنیادی A نباید برای فهم خودش به B نیاز داشته باشد. وگرنه دیگر با یک بنیان مستقل روبه‌رو نیستیم؛ با یک دور مفهومی روبه‌رو هستیم. ⏳ راه‌حل ظاهری شاید این باشد که ارجاع‌ها را حذف کنیم. اما آن‌وقت مشکل دیگری ایجاد می‌شود، هر لایه شروع می‌کند به توضیح دادن همان مفهوم با زبان خودش. پنج سند، پنج روایت. و هر بار که یکی از آنها تغییر می‌کند، احتمال فاصله گرفتن روایت‌ها بیشتر می‌شود. 📌 پس مسئله حذف وابستگی نیست؛ پیدا کردن محل درست تعریف است. یک مفهوم بنیادی باید یک‌بار، در جای درست، دقیق تعریف شود و لایه‌های بالاتر از آن استفاده کنند؛ نه اینکه هر کدام نسخه‌ای از آن برای خودشان بسازند. اما اینجا یک دام دیگر هم وجود دارد: 📌 واژه‌ها بی‌صاحب نیستند. وقتی واژه‌ای را برای یک مفهوم تعریف کردیم، دیگر نمی‌توانیم در جای دیگری معنای متفاوتی به آن بدهیم و همچنان همان واژه را با خیال راحت استفاده کنیم. یک تعریف خوب باید جامع و مانع باشد؛ یعنی همه نمونه‌هایی را که واقعاً متعلق به مفهوم‌اند دربر بگیرد و چیزهایی را که متعلق به آن نیستند، بیرون نگه دارد. برای همین، گاهی مشکل یک نظام دانشی نه کمبود مفهوم است و نه کمبود سند؛ 📌فقط یک واژه دارد که همه از آن استفاده می‌کنند، اما هنوز کسی دقیقاً ننوشته است که یعنی چه. ⏳ این موضوع فقط به مستندات فنی مربوط نیست. همین سؤال را می‌توان در #فلسفه_علم، طراحی سیستم، معماری، سازمان، نظریه‌های علمی و حتی باورهای شخصی دنبال کرد: 🔹 کدام اصل، واقعاً اصل ا

🧠 روز برنامه‌نویس را به همه #اندیشمند‌ان تبریک می‌گوییم! اما بیایید این روز را بهانه کنیم و یک سؤال ساده بپرسیم: 📌واقعاً چه کسی 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 را بلدیم بسازیم؟ 🤔

🧠 چرا رسیدن به هوشمندی (خرد) برای انسان و AGI برای هوشواره این‌قدر سخت است؟ 🔬این روزها تقریباً هر بار که صحبت از پیشرفت هوش مصنوعی می‌شود، یک پاسخ تکراری می‌شنویم: مدل بزرگ‌تر، داده بیشتر، پارامتر بیشتر، محاسبات بیشتر. و طبیعی هم هست؛ مدل‌های بزرگ‌تر معمولاً توانایی‌های بیشتری نشان می‌دهند. اما آیا مسیر رسیدن به #AGI واقعاً همین است؟ یا شاید مسئله جای دیگری است؟ 🧐 اول باید بپرسیم AGI دقیقاً چیست؟ اگر بخواهیم خیلی ساده تعریف کنیم: سیستمی که بتواند در طیف گسترده‌ای از مسائل شناختی، بدون نیاز به آموزش اختصاصی برای هر مسئله، یک مدل قابل اتکا از واقعیت بسازد، آن را با شواهد جدید اصلاح کند و برای رسیدن به هدف، به‌صورت مستقل استدلال و تصمیم‌گیری کند. اگر این تعریف را بپذیریم، ناگهان مسئله خیلی سخت‌تر از «پیش‌بینی Token بعدی» به نظر می‌رسد. 📌 مسئله از کجا شروع می‌شود؟ ما انسان‌ها واقعیت را مستقیماً به ماشین منتقل نمی‌کنیم. حتی به یکدیگر هم منتقل نمی‌کنیم. یک زنجیره تقریباً شبیه این داریم: Reality → Perception → Thought → Concept → Language → Text → Model و در هر مرحله ممکن است ابهام وارد شود. یک انسان چیزی را در ذهن دارد. آن را به یک مفهوم تبدیل می‌کند. برای رساندن آن مفهوم، یک کلمه انتخاب می‌کند. ممکن است کلمه دقیق نباشد. ممکن است جمله مبهم باشد. ممکن است مخاطب برداشت دیگری داشته باشد. و تازه در اینجا است که ماشین با متن مواجه می‌شود. بنابراین Language خودِ Reality نیست؛ یک واسط برای انتقال بخشی از برداشت ما از Reality است. و این واسط ذاتاً می‌تواند مبهم باشد. 📌 پس LLM دقیقاً چه چیزی را یاد می‌گیرد؟ مدل زبانی از حجم عظیمی از این واسط‌های انسانی یاد می‌گیرد: متن، جمله، کلمه، ارتباط میان کلمات، الگوهای تکرارشونده و روابط موجود در داده‌ها. و با افزایش ظرفیت مدل، می‌تواند ساختارهای پیچیده‌تری از این داده‌ها استخراج کند. اما یک سؤال اساسی باقی می‌ماند: آیا یادگیری ساختار زبان، الزاماً به معنای ساختن یک مدل قابل اتکا از واقعیت پشت زبان است؟ به نظر می‌رسد این دو مسئله یکی نیستند. مدل ممکن است بداند که دو مفهوم معمولاً در کنار هم ظاهر می‌شوند؛ بدون اینکه الزاماً بداند چرا. ممکن است یک رابطه را از هزاران نمونه یاد گرفته باشد؛ اما وقتی با شرایطی مواجه شود که در داده‌های قبلی وج

🧠 داده، اطلاعات، دانش و خرد؛ یک هرم نیستند! 🔬 اگر پست قبلی را خوانده باشید، احتمالا کلی سوال باز براتون ایجاد شد و شاید حتی درک عمیقی از آن بدست نیاوردید. بیایید از زاویه دیگر به موضوع بپردازیم و پس از مطالعه این پست و کامنت‌ها، برگردیم و دوباره آن پست را بخوانیم تا درک عمیق تری از اهمیت آن بدست بیاوریم. 🧐 احتمالاً نمودار معروف DIKW Pyramid (اشتباها در فارسی هرم دانش یا هرم داده نامیده میشود) را دیده‌اید: Data → Information → Knowledge → Wisdom یک تصویر ساده که خیلی سریع به ما می‌گوید: - #داده تبدیل به اطلاعات می‌شود، - #اطلاعات تبدیل به دانش، - و #دانش تبدیل به خرد. اما شاید همین سادگی، ما را گمراه کرده باشد. ⏳ این چهار مفهوم بیشتر از آنکه چهار مرحله پشت سر هم باشند، به هم وابسته‌اند و دائماً روی یکدیگر اثر می‌گذارند. - یک Input وارد سیستم می‌شود. - سیستم با توجه به آنچه از قبل می‌داند، آن را تفسیر می‌کند. - اگر این تفسیر بتواند عدم‌قطعیت یا ابهام را کاهش دهد، برای آن سیستم به Information تبدیل شده است. - این Information می‌تواند در مدل درونی سیستم جای بگیرد و بخشی از Knowledge آن شود. - و Knowledge دوباره تعیین می‌کند که Inputهای بعدی چگونه تفسیر شوند. ⏳ پس مسیر فقط این نیست: Data → Information → Knowledge بلکه می‌تواند این‌طور باشد: Input ↔️ Data|Information ↔️ Knowledge و شاید Wisdom هم اصلاً «طبقه بالاتر» این هرم نباشد. اگر #خرد را توانایی استفاده از دانش برای تشخیص اهمیت، انتخاب و عمل بدانیم، دیگر با یک مرحله جدید از انباشته‌شدن چیزها روبه‌رو نیستیم؛ با نحوه استفاده از آنچه می‌دانیم روبه‌رو هستیم و به نوعی خرد، خودش بخشی از دانش درونی سیستم هست. 🧠 شاید به جای هرم، بهتر باشد این مفاهیم را بخشی از یک سیستم شناختی (#علوم_شناختی) ببینیم. در کامنت‌ها کمی دقیق‌تر به این رابطه نگاه می‌کنیم.

🧠 تعارض خالص جنگ است، همکاری خالص عشق است، سیاست آمیزه‌ای از هر دو است. 🔬 نوشته بالا منتسب به Michael Laver #دانش_مند حوزه سیاست (Political scientist)، که به قشنگی تحریف کلمه سیاست و ظرایف آن را به نمایش در می‌آورد. شاید سیاست را بیش از حد دور دیده‌ایم. وقتی کلمهٔ «سیاست» را می‌شنویم، معمولاً ذهنمان به سمت دولت، انتخابات، احزاب، مجلس، قدرت و رقابت برای حکومت می‌رود. 🧐 اما سیاست، پیش از آنکه نامِ یک میدان سیاسی در سطح جامعه باشد، نامِ چیزی است که میان انسان‌ها اتفاق می‌افتد. - جایی که خواسته‌ها کاملاً یکی نیستند، اما قرار هم نیست برای هر اختلافی بجنگیم. - جایی که باید تصمیمی گرفته شود؛ تصمیمی که بر بیش از یک نفر اثر می‌گذارد، و آدم‌ها باید بطریقی با وجود تفاوت‌هایشان به آن برسند. - چه کسی چه چیزی را داشته باشد؟ - چه زمانی؟ - با چه ترتیبی؟ - چه کسی تصمیم بگیرد؟ - چه کسی اثر بیشتری داشته باشد؟ - و اصلاً چه چیزی برای همه قابل قبول باشد؟ ⏳ #اندیشمند Harold Lasswell ، سیاست را با پرسش معروف «چه کسی چه چیزی را، چه زمانی و چگونه به دست می‌آورد؟» صورت‌بندی کرد. در برداشت گسترده‌ای از سیاست، چنین پرسش‌هایی فقط به حکومت محدود نیستند؛ هرجا افراد یا گروه‌ها دربارهٔ یک انتخاب جمعی، منابع، قواعد یا منافع متفاوت با یکدیگر سروکار دارند، می‌توان از سیاست سخن گفت. ⏳ پس سیاست لزوماً به معنای فریب، توطئه یا قدرت‌طلبی نیست. سیاست - می‌تواند گفت‌وگو باشد. - می‌تواند مذاکره باشد. - می‌تواند ائتلاف باشد. - می‌تواند رقابت باشد. - می‌تواند سازش باشد. - و حتی می‌تواند تلاش برای پیدا کردن راهی باشد که هیچ‌کس انتخاب اولش را به دست نمی‌آورد، اما همگی می‌توانند با آن زندگی کنند. ⏳ شاید نکتهٔ عجیب‌تر این باشد که برای دیدن سیاست، لازم نیست به یک کشور نگاه کنیم. - گاهی کافی است دو نفر را کنار هم بگذاریم. - دو دوست که می‌خواهند برای یک سفر تصمیم بگیرند. - دو همکار که دربارهٔ اولویت یک کار اختلاف دارند. - دو عضو خانواده که هرکدام تصور متفاوتی از یک تصمیم مشترک دارند. در مقیاس بزرگ‌تر، همین مسئله می‌تواند به سازمان، جامعه یا دولت برسد؛ فقط تعداد بازیگران، قواعد، منابع و پیامدها پیچیده‌تر می‌شود. به همین دلیل، Politics را نباید بی‌درنگ با Government یکی گرفت؛ و Governance هم مفهوم دیگری است که بر چ