سلام در پنج تا ده سال آینده: از یک پروژه‌ی متن‌باز تا یک زیست‌بوم جهانی، و آنچه پیش از آن باید رخ دهد

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

زبان سلام در آبان ۱۴۰۵ کجا ایستاده است

هر پیش‌بینی باید از یک نقطه‌ی شروع صادقانه آغاز شود. این‌ها واقعیت‌هایی‌اند که باقی نوشته روی آن‌ها بنا شده است.

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

زبان‌ها در عمل چطور رشد کرده‌اند

تاریخ زبان‌های برنامه‌نویسی چند درس دارد که مستقیم به کار می‌آیند. این‌ها نمونه‌هایی خوب مستندشده‌اند، نه تشبیه‌هایی که برای خوشایند انتخاب شده باشند.

• پایتون در ۱۹۹۱ منتشر شد و بیش از یک دهه طول کشید تا گزینه‌ی پیش‌فرض شود. رشدش از نحوی خوانا، یک کتابخانه‌ی استاندارد «باتری همراه» و، بسیار بعدتر، محاسبات علمی و علم داده به‌عنوان حوزه‌ای که آن را بی‌رقیب کرد آمد.
• Ruby حدود یک دهه وجود داشت تا Ruby on Rails، که در ۲۰۰۴ منتشر شد، یک کاربرد بی‌رقیب به آن داد و موجی از برنامه‌نویسان وب را به سویش آورد.
• Go در ۲۰۰۹ معرفی شد و در ۲۰۱۲ نسخه‌ی Go 1 را با یک تعهد صریح سازگاری منتشر کرد: برنامه‌هایی که برای Go 1 نوشته شده‌اند همچنان کامپایل می‌شوند. همین تعهد، به‌علاوه‌ی پشتیبانی گوگل و تناسب قوی با ابزارهای ابری، آن را برای شرکت‌ها امن کرد.
• Rust سال‌ها پیش از نسخه‌ی ۱٫۰ در ۲۰۱۵ به‌صورت عمومی توسعه یافت و پذیرشش وقتی شتاب گرفت که شرکت‌های بزرگ آن را برای کد سیستمی حساس از نظر امنیتی به کار بردند. در این مسیر یک بنیاد و یک ساختار رسمی حاکمیت ساخت.
• Kotlin نقطه‌ی عطفش را در ۲۰۱۷ تجربه کرد، وقتی گوگل پشتیبانی رسمی از آن را برای اندروید اعلام کرد: صاحب یک سکو آن را برگزید.

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

نقطه‌عطف ۱: نسخه‌ی ۱٫۰ و تعهد سازگاری

مهم‌ترین گام تکی، انتشار نسخه‌ی ۱٫۰ با یک قاعده‌ی مکتوب سازگاری است. امروز انتشارهای فرعی و حتی وصله‌ای هم می‌توانند کد را بشکنند. برنامه‌ی کوچک زیر برداشت رایج از نسخه‌گذاری معنایی (Semantic Versioning) را اعمال می‌کند: پیش از ۱٫۰ با تغییر شماره‌ی فرعی هر چیزی ممکن است تغییر کند، و پس از ۱٫۰ فقط نسخه‌ی اصلی اجازه دارد کد را بشکند:

واردسازی رشته
واردسازی تبدیل

ساختار نسخه:
    همگانی اصلی: صحیح
    همگانی فرعی: صحیح
    همگانی وصله: صحیح
پایان

تابع خواندن نسخه(متن: رشته): نسخه:
    بخش‌ها := رشته.تفکیک کردن(رشته.حذف پیشوند(متن، «v»)، «.»)
    دیرکن بخش‌ها.آزادکن()
    برگشت نسخه {
        اصلی = تبدیل.رشته به عدد با پیش فرض(بخش‌ها.بگیر(۰)، ۰)،
        فرعی = تبدیل.رشته به عدد با پیش فرض(بخش‌ها.بگیر(۱)، ۰)،
        وصله = تبدیل.رشته به عدد با پیش فرض(بخش‌ها.بگیر(۲)، ۰)،
    }
پایان

تابع ارتقای ناسازگار(از نسخه: نسخه، به نسخه: نسخه): منطقی:
    اگر از نسخه.اصلی == ۰:
        برگشت به نسخه.اصلی > ۰ یا به نسخه.فرعی != از نسخه.فرعی
    پایان
    برگشت به نسخه.اصلی != از نسخه.اصلی
پایان

تابع ریشه:
    قدیمی‌ها := [«v0.6.2»، «v0.5.9»، «v1.4.0»، «v1.9.2»]
    تازه‌ها := [«v0.6.3»، «v0.6.0»، «v1.9.2»، «v2.0.0»]
    تکرار قدیمی‌ها.طول() در ای:
        الف := خواندن نسخه(قدیمی‌ها[ای])
        ب := خواندن نسخه(تازه‌ها[ای])
        نتیجه := ارتقای ناسازگار(الف، ب) ? «ممکن است کد را بشکند» : «باید سازگار باشد»
        سرچاپ قدیمی‌ها[ای]، «->»، تازه‌ها[ای]، نتیجه
    پایان
پایان

با این قاعده، رفتن از ۰٫۶٫۲ به ۰٫۶٫۳ باید بی‌خطر باشد. در واقعیت، ۰٫۶٫۳ خودانتسابی‌هایی مانند x = x + 1 را خطای کامپایل کرد. این تغییری معقول در زبان است، و دقیقاً همان نوع غافل‌گیری‌ای که سیاست نسخه‌ی ۱٫۰ برای جلوگیری از آن وجود دارد.

مخزن از همین حالا نشان می‌دهد که پیش از چنین تعهدی چه چیزهایی باید جا بیفتند. docs/design/naming-standard.md پیشنهادی برای یکدست کردن نام‌های همگانی کتابخانه‌ی استاندارد است و می‌سنجد که نام چند اعلان باید عوض شود. docs/design/OWNERSHIP.md بررسی‌های زمان کامپایل حافظه را بدون نشانه‌گذاری طول عمر توصیف می‌کند: پنج مرحله‌ی نخستش پیاده شده و مرحله‌ی ششمش، پس از یک انتشار، هشدارهای مالکیت را به‌طور پیش‌فرض به خطا تبدیل خواهد کرد. هر دو از آن نوع تغییرهای ناسازگارند که زبان باید پیش از ۱٫۰ تمامشان کند، نه پس از آن. ابزارهای یک گذار نرم وجود دارند (تابع‌های بی‌کاره با هشدار W013، فیلد salam = ">=X" در مانیفست بسته‌ها)؛ سیاستش هنوز نه.

نقطه‌عطف ۲: یک زیست‌بوم واقعی از بسته‌ها

کتابخانه‌ی استاندارد سلام قوی‌ترین دارایی آن برای کاربران نخستین است و در عین حال یک سقف. یک تیم اصلی نمی‌تواند همه‌ی راه‌اندازهای پایگاه داده، SDKهای ابری و چارچوب‌ها را تا ابد نگهداری کند. مدیر بسته برای مرحله‌ی بعد آماده است: ماژول‌های مبتنی بر گیت، فایل قفل، چکیده‌ها، فهرست بازبینی‌شده‌ی چکیده‌ها و فهرست بسته‌هایی که salam search می‌خواند. آنچه کم دارد خود بسته‌هاست. نوشته‌ی زیست‌بوم متن‌باز سلام سازوکار را شرح می‌دهد.

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

نقطه‌عطف ۳: جهان فارسی‌زبان به‌عنوان پایگاه خانگی

هر زبان موفقی یک خانه دارد: Go زیرساخت ابری را داشت، Ruby استارتاپ‌های وب را و Kotlin اندروید را. طبیعی‌ترین خانه‌ی سلام جهان فارسی‌زبان است، در دو نقش.

آموزش. یک زبان سیستمی کامل با واژه‌های کلیدی فارسی، پیام‌های خطای فارسی و یک دوره‌ی رایگان فارسی را می‌توان از نخستین درس به زبان خود دانش‌آموزان تدریس کرد و سپس با salam translate به واژه‌های کلیدی انگلیسی پل زد. مخزن از همین حالا اسلایدهای یک ارائه‌ی فارسی را دارد که برای رویداد DSTO در کاشان در اکتبر ۲۰۲۶ آماده شده بود؛ چنین پذیرشی همین‌طور شروع می‌شود: یک رویداد، یک معلم، یک دوره در هر نوبت. نوشته‌ی سلام در آموزش برنامه‌نویسی بررسی می‌کند که کلاس‌های درس هنوز به چه نیاز دارند.

نرم‌افزار محلی. کسب‌وکارهایی که به فارسی کار می‌کنند به تقویم جلالی، رقم‌های فارسی، متن راست‌به‌چپ و ابزارهای فارسی نیاز دارند. کتابخانه‌ی استاندارد از همین حالا با این‌ها مثل شهروند درجه‌یک رفتار می‌کند (calendar، bidi، arabic، i18n). نسلی از برنامه‌نویسان که با سلام یاد گرفته‌اند و نرم‌افزار محلی را با آن می‌سازند، پایگاه ماندگاری به زبان می‌دهند، همان‌طور که جامعه‌های منطقه‌ای زبان‌های دیگر را پیش از گسترششان سرپا نگه داشتند.

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

نقطه‌عطف ۴: حوزه‌ای که سلام در آن انتخاب بدیهی باشد

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

1. یک زبان برای یک محصول وب. زبان صفحه به HTML، CSS و جاوااسکریپت کامپایل می‌شود و net.http آن را از همان برنامه سرویس می‌دهد، با پشته‌ی HTTP که در سنجه‌ی مسیریاب پروژه در رده‌ی چارچوب‌های سریع Go اندازه‌گیری شد. یک تیم کوچک می‌تواند کل یک محصول وب، سرور و صفحه‌ها، را با یک زبان کامپایلی بسازد. نوشته‌ی توسعه‌ی فول‌استک با سلام را ببینید.
2. برنامه‌های بومی از یک توصیف واحد. همان زبان صفحه از همین حالا می‌تواند با salam run page.salam --ui=native در یک پنجره‌ی رومیزی بومی اجرا شود و سند طراحی آن مرحله‌های بعدی را برنامه‌ریزی کرده است. اگر این کار پخته شود و به موبایل برسد، «رابط کاربری را یک بار با زبان صفحه بنویس و برای وب، رومیزی و موبایل عرضه کن» پیشنهادی متمایز خواهد بود.
3. ابزارهایی برای عصر هوش مصنوعی. کامپایلر سخت‌گیر سلام، کدهای خطای ثابت و پیام‌های خطای ماشین‌خوان آن را هدف خوبی برای دستیارهای کدنویس می‌کنند، و پروژه از همین حالا دستیار، عامل (Agent) و سرور MCP خودش را اجرا می‌کند که سمت سرورش با سلام نوشته شده است. نوشته‌های برنامه‌نویسی با کمک هوش مصنوعی و دستیار هوشمند سلام این را پوشش می‌دهند.

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

نقطه‌عطف ۵: حاکمیت، امنیت و پایداری پروژه

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

آنچه این وضع را تغییر می‌دهد، تقریباً به ترتیب هزینه:

• یک سیاست امنیتی با نشانی‌ای برای گزارش و تعهد به انتشار اطلاعیه‌های امنیتی؛
• یک روند مکتوب تصمیم‌گیری و آدم‌های بیشتری با اختیار ادغام و انتشار، تا پروژه از غیبت هر فردی جان سالم به در ببرد؛
• یک خط انتشار پشتیبانی‌شده کنار خط پرشتاب کنونی؛
• پاسخی روشن درباره‌ی پروانه برای استفاده‌ی انحصاری، چون کتابخانه‌ی استاندارد GPL-3.0 بدون استثنای پیوند امروز بسیاری از محصولات تجاری را کنار می‌گذارد؛
• و در نهایت یک خانه‌ی حقوقی، مانند یک بنیاد یا حامی مالی، که بتواند نام را نگه دارد، بودجه بپذیرد و هزینه‌ی ممیزی‌ها را بپردازد.

هیچ‌کدام از این‌ها اعلام نشده است. این‌ها همان چیزهایی‌اند که هر زبانی که به کاربرد سازمانی رسید سرانجام لازم داشت.

موفقیت چه شکلی خواهد داشت، و خطرها

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

در پنج سال (۲۰۳۱): نسخه‌ی ۱٫۰ای که دست‌کم دو سه سال به تعهد سازگاری‌اش پایبند مانده؛ فهرستی با صدها بسته و نگهدارندگانی از بیرون پروژه؛ تدریس سلام در دوره‌های واقعی در مدرسه‌ها یا دانشگاه‌های فارسی‌زبان، با گزارش‌های تجربه‌ی منتشرشده؛ و یک سیاست امنیتی و یک سند حاکمیت.

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

خطرها هم به همان اندازه ملموس‌اند. پروژه ممکن است کاری یک‌نفره بماند و متوقف شود. تغییرهای ناسازگار ممکن است کاربران نخستین را پیش از رسیدن ۱٫۰ خسته کنند. انتخاب پروانه‌ی GPL ممکن است پذیرندگان تجاری را دور نگه دارد. گستردگی ممکن است همچنان بر عمق پیروز شود، طوری که بسیاری از ویژگی‌ها در ۸۰ درصد بمانند. و جامعه ممکن است کوچک‌تر از آن بماند که یک زیست‌بوم بسته‌ها شکل بگیرد. هر زبان جوانی با برخی از این‌ها روبه‌روست؛ آن‌هایی که می‌مانند آگاهانه به آن‌ها می‌پردازند.

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

پرسش‌های متداول درباره‌ی آینده‌ی زبان سلام

نسخه‌ی ۱٫۰ زبان سلام چه زمانی منتشر می‌شود؟

هیچ تاریخی اعلام نشده است. خط کنونی ۰٫۶ است و اسناد طراحی پروژه هنوز تغییرهای ناسازگاری را توصیف می‌کنند (مانند قاعده‌های سخت‌گیرانه‌تر مالکیت و نام‌گذاری کتابخانه‌ی استاندارد) که معمولاً پیش از تعهد سازگاری نسخه‌ی ۱٫۰ انجام می‌شوند.

آیا شرکت یا بنیادی پشت زبان سلام است؟

نه. سلام یک پروژه‌ی متن‌باز در گیت‌هاب است که سید علی محمدیه طراحی کرده و با مشارکت‌کنندگان بیرونی و زیر پروانه‌ی GPL-3.0 توسعه می‌یابد. امروز هیچ شرکت، بنیاد یا پشتیبانی تجاری‌ای پشت آن نیست.

آیا سلام فقط روی فارسی تمرکز خواهد داشت؟

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

چطور می‌توانم به رشد زبان برنامه‌نویسی سلام کمک کنم؟

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