Uploaded avatar of xavdid

تأملی بر #12in23 از زبان کسی که آن را به پایان رساند

@xavdid
بیش از 2 سال پیش

این مطلب در ابتدا در وب‌سایت David منتشر شد و با اجازه در اینجا بازنشر می‌شود

ژانویه‌ی گذشته، Exercism برنامه‌ی جدیدی به اسم 12in23 معرفی کرد که در آن از شرکت‌کنندگان می‌خواست ۱۲ زبان برنامه‌نویسی جدید را در سال ۲۰۲۳ امتحان کنند. هر ماه یک تم داشت (مثل «آوریل تحلیلی» یا «اکتبر شیءگرا») و زبان‌های مشخصی را برای امتحان کردن برجسته می‌کرد. من عاشق یادگیری چیزهای تازه‌ام و کم‌کم به یک خوره‌ی زبان (برنامه‌نویسی) تبدیل شده‌ام، پس تصمیم گرفتم امتحانش کنم. ۱۲ زبان، ۱۲ ماه!

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

انتخاب زبان‌ها

چند اصل کلی برای آن سال تعیین کردم تا بیشترین بهره را از این تجربه ببرم:

۱. زبان‌ها باید یا کاملاً جدید برایم می‌بودند یا دست‌کم به‌قدری ناآشنا که حس کنم دارم چیزهای زیادی یاد می‌گیرم. ۲. زبان‌های انتخاب‌شده باید (احتمالاً) برای ادامه‌ی یادگیری‌شان در آینده به کارم بیایند. این پروژه فقط برای سرگرمی بود، اما می‌خواهم زمانم را صرف یادگیری مواردی کنم که دست‌کم تا حدی به کارم می‌آید. ۳. برای هر زبانی که استفاده می‌کردم، همه‌ی ابزارهای محلی و افزونه‌ی VSCode را نصب می‌کردم. می‌خواستم زبان‌ها را تقریباً هم‌تراز با هم مقایسه کنم، با بیشترین راهنمای نوع و تکمیل هوشمندی که ممکن بود. در دانشگاه همه‌ی تمرین‌های برنامه‌نویسی‌ام را در Sublime Text و بدون هیچ ابزار بررسی کد یا تکمیل خودکاری انجام می‌دادم. نگران بودم که اگر برنامه‌نویسی را همراه با همه‌ی آن ابزارها یاد بگیرم، بیش از حد به آن‌ها تکیه کنم و برنامه‌نویس خوبی نشوم. اما برعکسش اتفاق افتاد. هرچه بیشتر بتوانم بار ذهنی را به ابزارهایم بسپارم، بیشتر می‌توانم به خود مسئله‌ی پیش رو فکر کنم. چیزها را به خاطر نسپارید، یاد بگیرید چطور پیدایشان کنید.

برویم سراغش!

ژانویه (بدون تم)

وقتی ژانویه شروع شد، تیم Exercism هنوز در حال انتخاب تم‌های ماهانه بود، بنابراین زبان آن ماه به انتخاب خودمان بود. بی‌هدف، سال را با Go شروع کردم. اواسط ۲۰۲۲ یک دوره‌ی فشرده برای این زبان گذرانده بودم، اما از آن زمان زیاد ازش استفاده نکرده بودم و اصلاً حس تسلط نداشتم.

Go زبان جالبی است. کامپایلر سخت‌گیرش یعنی برنامه‌تان درست خواهد بود و تا وقتی فکر نکند می‌توانید امن جلو بروید، یک قدم هم تکان نمی‌خورید.1 رویکرد پرحرفش به مدیریت خطا یعنی هیچ‌وقت غافلگیر نمی‌شوید (به قیمت نوشتن if err != nil { return err } آن‌قدر آن‌قدر زیاد). کار سختی مثل موازی‌سازی با کانال‌ها را خوب ساده می‌کند، اما بعضی کارهای ساده مثل کار با رشته‌ها را سخت می‌کند. کتابخانه‌ی استاندارد قدرتمندی دارد، یعنی می‌توانید بیشتر کارها را بدون ماژول‌های شخص ثالث انجام دهید. خوشم می‌آید که بخش زیادی از اکوسیستم (قالب‌بندی، نصب، ساخت و غیره) رسمی است و داخل خود دستور go ساخته شده. این زبان منتقدانی هم دارد، اما فکر می‌کنم در اهدافش یعنی درستی و نگهداشت‌پذیری تا حد زیادی موفق است.

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

فوریه‌ی تابعی

فوریه مستقیم شیرجه زد به زبان‌های تابعی، که شاخه‌ای ریاضی‌وار از زبان‌های برنامه‌نویسی دستوری رایج‌ترند. زبان‌های تابعی به خاطر توابع «خالص»شان (بدون اثرات جانبی) شناخته می‌شوند. من Elixir را انتخاب کردم، بیشتر به این خاطر که دوستم Caleb ازش برای Advent of Code استفاده کرده و ازش تعریف می‌کند.

از وقتی که با Elixir گذراندم خیلی لذت بردم. از Ruby الهام گرفته (که منطقی است؛ سازنده‌اش، José Valim، از مشارکت‌کنندگان اصلی Rails بود). بیان مفاهیم تابعی مثل زنجیره‌سازی متد به نظرم ساده بود. عاشق همه‌ی شکر نحوی‌ای بودم که این کار را ساده می‌کرد، مثل عملگر لوله (|>):

foo(bar(baz(new_function(other_function()))))
# becomes
other_function() |> new_function() |> baz() |> bar() |> foo()

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

defmodule TuplePrinter do
  def print({a}) do
	IO.puts("single")
	IO.puts(a)
  end

  def print({a, b}) do
	IO.puts("double")
	IO.puts(a)
	IO.puts(b)
  end
end

TuplePrinter.print({1})
TuplePrinter.print({2, 2})

# single
# 1
# double
# 2
# 2

به نظر می‌رسد از آن ویژگی‌هایی است که یا عالی است یا کدتان را کاملاً به هم می‌ریزد. در هر صورت، مفهوم جالبی بود!

Elixir از این هم سود می‌برد که داخل ماشین مجازی BEAM ارلنگ اجرا می‌شود، که اکوسیستم بزرگی برای تعامل در اختیارش می‌گذارد. در همروندی عالی است و هسته‌ی چارچوب وب Phoenix محبوب است.

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

مارس مکانیکی

مارس روی زبان‌های «سیستمی» تمرکز داشت، که تا کد ماشین کامپایل می‌شوند.

از میان گزینه‌ها، Go تنها زبانی بود که به آن علاقه داشتم.2 حالا، خوانندگان زیرک متوجه می‌شوند که من قبلاً یک ماه Go کار کرده بودم، پس تکرارش جزو آن ۱۲ تا حساب نمی‌شد. خب، وقتی آن را برای ژانویه انتخاب کردم، هنوز اعلام نکرده بودند که تم‌ها را اجرا می‌کنند، پس متوجه نشدم که دارم خودم را در گوشه‌ای گیر می‌اندازم.

اگر می‌دانستم که Bun دارد می‌آید، احتمالاً Zig را امتحان می‌کردم، اما متأسفانه (هنوز) نمی‌توانستم آینده را ببینم. پس، در نبود گزینه‌ای جذاب‌تر، یک ماه اضافه‌ی Go را انتخاب کردم و می‌دانستم که باید بعداً در همان سال یک ماه را دو بار بردارم.

آوریل تحلیلی

آوریل تمامش درباره‌ی زبان‌های محبوب در علم داده بود. با Python بیش از حد آشنا بودم و R را در دانشگاه در یک کلاس آمار کار کرده بودم (و خوشم نیامده بود)، پس Julia!

از کار با آن لذت بردم، اما بیشتر چون خیلی شبیه Python بود. کمی آشفته‌کننده بود، مثل آمریکایی بودن در کانادا. همه‌چیز خیلی آشناست اما فقط یک کم فرق دارد، طوری که سخت می‌توانید دقیقاً بگویید چه چیزی. ناگهان کسی به شما یک سکه‌ی ۲ دلاری تعارف می‌کند (یا تابعی که واقعاً برای محاسبات ماتریسی مناسب است) و می‌فهمید که دیگر در کانزاس نیستید.

چیزی که بیش از همه توجهم را جلب کرد، سیستم نوع Julia بود. مثل سیستم نوع Python (به‌صورت اختیاری) نشانه‌گذاری می‌شد، اما بررسی‌های زمان اجرا داشت تا مطمئن شود آرگومان‌ها با نوع‌های اعلام‌شده‌شان مطابقت دارند. فکر می‌کنم سیستم Python تعادل درستی بین اتصال به ابزارها و جلوی راه را نگرفتن برقرار می‌کند، اما قبول دارم خطاهای زمان اجرای Julia برای توابع با نوع اشتباه هم مفید بودند.

در نهایت Julia جالب بود، اما انتظار ندارم در آینده به آن نیاز پیدا کنم.

مه، ماهِ تغییر ذهن

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

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

cargo، مدیر بسته‌ی Rust، هم لایق ذکر ویژه است. هرچند هیچ بسته‌ی شخص ثالثی نصب نکردم، عملکرد ساخت، تست و قالب‌بندی‌اش عالی بود. همین درباره‌ی افزونه‌ی VSCodeاش هم صادق است، که همه‌ی امکانات خوبی را داشت که از یک زبان نوع‌دار ایستا مثل Rust انتظار دارم. تجربه‌ی خوب توسعه‌دهنده واقعاً همه‌چیز را تغییر می‌دهد.

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

تابستان S-expressionها (ژوئن)

ژوئن ماهِ S-expressionها بود، شکل نحوی رایجی در زبان‌های Lisp. Clojure را انتخاب کردم، زبانی تابعی که روی JVM اجرا می‌شود.

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

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

خودم را در حال استفاده از Clojure برای چیزی نمی‌بینم وقتی گزینه‌های دیگری موجودند، اما تجربه‌ی کاملاً ناخوشایندی نبود.

مأموریت فرعی: Universal Test Runner!

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

وقتی منطق لازم از حد راحتی من با bash فراتر رفت، در ژوئن وقتی گذاشتم و پروژه را به یک چیز مستقل تبدیل کردم: Universal Test Runner.

آن را در انجمن Exercism به اشتراک گذاشتم و بازخورد خوبی گرفتم. آن‌قدر دوستش داشتند که تصمیم گرفتیم قابلیت مشابهی را داخل خود Exercism CLI بسازیم (که با Go نوشته شده، موضوعی که خوشبختانه تازه مرورش کرده بودم). پس برای نیمه‌ی دوم سال می‌توانستم exercism test را اجرا کنم تا مجموعه‌تست زبان آن ماه را اجرا کنم (دستوری که به‌صورت بومی در Universal Test Runner پشتیبانی می‌شود).

اگر می‌خواهید درباره‌ی این فرایند بیشتر بدانید، وقتی راه افتاد با جزئیات خیلی بیشتری نوشتم.

به‌هرحال، برویم جلو!

ژوئیه‌ی ژوراسیک

ژوئیه زبان‌های قدیمی را به نمایش گذاشت. از نظر کاربردی بودن، این ماه گزینه‌های خیلی کمی داشت. با COBOL محترم شروع کردم، چون شنیده بودم هنوز زیرساخت‌های حیاتی زیادی را می‌گرداند. اما با نزدیک شدن عروسی‌ام در اوایل اوت، ظرفیت آن را نداشتم که بنشینم و چنین زبانی را که برایم این‌قدر متفاوت بود یاد بگیرم. پس در عوض، به Visual Basic روی آوردم چون کم‌بدترین گزینه به نظر می‌رسید.

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

اوتِ اپ‌ها

اوت پر بود از زبان‌هایی که اپ می‌سازند. جای تعجب نیست که این ماه گزینه‌های زیادی بود. Swift را انتخاب کردم. به‌عنوان کسی که از محصولات زیاد اپل استفاده می‌کند، زبان سفارشی‌ساخته‌ی خودشان برایم خیلی مرتبط است. کاملاً تازه‌وارد نبودم: در سال ۲۰۱۶ یک اپ iOS منتشر کرده بودم که کاملاً با Swift نوشته شده بود. اما از آن زمان به زبان دست نزده بودم و خیلی تکامل یافته بود، پس فکر کردم هنوز به حساب می‌آید.

خوشحال شدم دیدم چقدر کار با آن ساده است. برخلاف بسیاری از زبان‌های دیگر اینجا، Swift خیلی جدید است. اولین بار در ۲۰۱۴ منتشر شد و واضح است که از درس‌های طراحی زبان مدرن سود برده. مدیر بسته‌ی رسمی، زنجیره‌سازی اختیاری، توابع درجه‌اول و درج رشته‌ای معقول دارد. خواندن و نوشتنش ارگونومیک بود، حتی بدون استفاده از Xcode.

با همه‌ی این حرف‌ها، Swift بیشتر در بستر اپ‌های پلتفرم‌های اپل مفید است، که فعلاً نمی‌نویسم. هرچند برای تمرین‌ها خوب کار کرد، پیش‌بینی نمی‌کنم به‌زودی دوباره سراغش بروم. اما واقعاً دوست دارم که می‌توانم روی آیپدم بنویسمش!

سپتامبر سبک

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

هرچند همیشه آن را فقط ابزاری برای کار با JSON می‌دانستم، نه یک زبان برنامه‌نویسی همه‌منظوره. خوشحال شدم دیدم همه‌ی متعلقات معمول را دارد، یعنی توابع، متغیرها، حلقه‌ها و غیره، پس می‌توانستم برنامه‌های نسبتاً پیچیده‌ای بنویسم:

# input: { "series": "1", "sliceLength": 1 }
. as {series: $series, sliceLength: $sliceLength} |
if
  $series == "" then
	"series cannot be empty" | halt_error
  elif $sliceLength > ($series | length) then
	"slice length cannot be greater than series length" | halt_error
  elif $sliceLength == 0 then
	"slice length cannot be zero" | halt_error
  elif $sliceLength < 0 then
	"slice length cannot be negative" | halt_error
  else
	.
end
| [range(0; $series | length)]
| map($series[. : . + $sliceLength])
| map(select(. | length == $sliceLength))

امتحان کردن همه‌ی قابلیت‌های jq که هرگز برای تبدیل‌های ساده‌ی داده لازم نشده بودم بامزه بود. هرچند ابزارهای اینجا تا حدی کم بودند (بدون یکپارچگی با ویرایشگر و غیره)، درک عمیق‌تر از گستره‌ی عملکرد jq ارزشمند بود.

ویرایش: DJ Adams در Mastodon پروژه‌ی jq-lsp و افزونه‌ی VSCode مربوطش را به توجهم رساند. این بار فرصتش را از دست دادم، اما در آینده بررسی‌اش می‌کنم.

اکتبر شیءگرا

اکتبر در زبان‌های شیءگرا کاوید. به طراحی‌های شیءگرا علاقه‌ی خاصی دارم، چون خیلی نزدیک به تصویری است که در ذهنم از برنامه‌ها دارم. Ruby را انتخاب کردم، که شاید انتخاب عجیبی به نظر برسد.

در Stripe کار می‌کنم، خانه‌ی بزرگ‌ترین پایگاه کد Ruby در جهان. مطمئناً به‌عنوان زبانی «ناآشنا» به حساب نمی‌آمد؟ هرچند همه‌ی اینها درست است، مونولیت Ruby ما خیلی از Ruby «استاندارد» دور به نظر می‌رسد: همه‌چیز با Sorbet بررسی نوع می‌شود، تولید کد بسیار زیادی داریم، و برای اینکه همه‌چیز با هم کار کند و مقیاس بگیرد، جادوی زیادی می‌کنیم. هرچند Ruby درون و بیرون Stripe در نهایت یک زبان است، کار در مقیاس‌های این‌قدر متفاوت تجربه‌های بسیار متفاوتی می‌دهد؛ می‌خواستم بدانم زندگی در بیرون چه شکلی است (در سال‌هایی که از استفاده‌ی سنگین از Ruby گذشته بود).

در مجموع، خوب بود! خود Ruby عالی است و «شادی برنامه‌نویس» را به‌عنوان هدف اصلی‌اش ذکر می‌کند، که با من هم‌آوا بود. دوست دارم که اغلب می‌توانم اسم توابع کتابخانه‌ی استاندارد را که هرگز استفاده نکرده‌ام حدس بزنم. دوست دارم که ساختن کد تابعی چقدر ساده است و نحوه‌ی نگارش چقدر ارگونومیک و رساست.

با این حال، تعجب کردم که ابزارهای توسعه چقدر از Python عقب‌تر بودند. شاید لوس شده‌ام، اما داشتن راهنمای نوع داخل ویرایشگر و بررسی و قالب‌بندی فوق‌سریع برایم مهم‌تر از آنی است که فکر می‌کردم. برای زبانی که در اوج محبوبیتش به اندازه‌ی Ruby بود، تعجب کردم که در این زمینه چقدر عقب به نظر می‌رسید.3 همچنین هرگز کاملاً به پرانتز اختیاری در فراخوانی توابع عادت نکردم، که گذراندن توابع به‌عنوان آرگومان را کم‌روان‌تر می‌کرد.

Ruby هنوز زبان عالی‌ای است و در محل کار همچنان استفاده‌اش می‌کنم، اما کاری برایم نمی‌کند که Python نمی‌کند، دست‌کم در حال حاضر.

نوامبر نیم‌بایتی

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

برای این ماه به‌طور غیرمنتظره‌ای آماده بودم. نحوه‌ی نگارشش شبیه Clojure بود و ساختار زبان شبیه TIS-100 از Zachtronics. به شکل عجیبی لذت بردم که برای هر عملیات باید از صفر شروع می‌کردم؛ حس قدیمی و دلپذیری داشت. اگر واقعاً می‌خواستم کاری را این‌طور به سرانجام برسانم ازش متنفر می‌شدم، اما در این فاصله چیز عجیب و بامزه‌ای بود. با کامنت‌های فراوان توانستم چیزی بنویسم که تقریباً خواناست:

(module
  (func (export "eggCount") (param $number i32) (result i32)
	(local $res i32) ;; result
	(local $remainder i32) ;; loop counter

	(loop $loop

  	;; $res =
  	(local.set $res
    	;; $res +
    	(i32.add
      	(local.get $res)
      	;; $number % 2
      	(i32.rem_u
        	(local.get $number)
        	(i32.const 2)
      	)
    	)
  	)

  	;; $number //= 2
  	;; (keep on stack)
  	(local.tee $number
    	(i32.div_u
      	(local.get $number)
      	(i32.const 2)
    	)
  	)

  	;; this will keep looping until remainder is 0
  	br_if $loop
	)

	local.get $res
  )
)

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

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

با Wren شروع کردم. ساخته‌ی Bob Nystrom که از جمله به خاطر Crafting Interpreters مشهور است. دقتش به جزئیات، ردپای کوچک و طراحی از بالا به پایینش مرا مجذوب کرد؛ همه‌چیز خیلی سنجیده به نظر می‌رسد. این سطح از توجه در جزئیات حوزه‌ی متغیر و قواعد خصوصی‌بودن نمایان است. کامپایلرش کوچک است و کامنت‌های زیادی دارد، پس اگر به پیاده‌سازی زبان‌ها علاقه دارید منبع یادگیری عالی‌ای است.

Wren کمی ناهموار است و به نظر می‌رسد بیشتر رها شده، اما فکر می‌کنم برای یک زبان اسباب‌بازی اشکالی ندارد. هیچ‌کس با این انتظار سراغش نمی‌آید که آماده‌ی محیط عملیاتی باشد. قطعاً در دنیا جا برای زبان‌های غیرتولیدی هست.

همچنین: Lua

انتخاب دومم این ماه Lua بود. برخلاف Wren، فوق‌العاده کاربردی است. قابلیت جاسازی آسانش یعنی در جاهای زیادی ظاهر می‌شود، مثل اسکریپت‌نویسی Redis و مودهای Factorio. مدل شیءگرایش کمی زمان برد تا عادت کنم، اما می‌بینم که چطور می‌توانم به‌سرعت پربار باشم. سریع به جدول‌ها به‌عنوان ساختاری که همه‌کار می‌کند دل بستم. ابزارها خوب بودند: مدیر بسته بدون هیچ تنظیمی کار می‌کرد و افزونه‌ی VSCode بدون دردسر از حاشیه‌نویسی نوع مبتنی بر کامنت پشتیبانی می‌کرد.

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

جمع‌بندی

از این تور زبان بیشتر از آنی که انتظار داشتم لذت بردم. نه فقط چند مهارت کاربردی تازه یاد گرفتم، افق‌هایم هم کاملاً گسترده‌تر شده است.

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

هدف مشخصی در ذهن ندارم، اما کل کتاب Rust را برای خواندن دارم، یک دوره‌ی Rust برای توسعه‌دهندگان JS که یک سال هزینه‌اش را دریافت کردم، و یک مسیر کامل Exercism برای تمام کردن. دوست دارم به دست‌کم یک پروژه‌ی متن‌باز مشارکت کنم (احتمالاً Just، که تازه به برنامه‌های محبوبم اضافه شده)، اما ببینیم سال ما را به کجا می‌برد.

تا آن موقع، تعطیلات خوش و بقیه‌ی ۲۰۲۳ خوبی داشته باشید!

  1. متغیرهای استفاده‌نشده خطای کامپایلر هستند؟؟ خب یه کم انصاف داشته باشید دیگر ↩

  2. در واقع اول C++ را امتحان کردم (که از دانشگاه به بعد ننوشته بودم). اصلاً بامزه نبود، پس رهایش کردم ↩

  3. این یکی از راه‌های دیگری است که Ruby «واقعی» با تجربه‌ی من در Stripe فرق دارد، پس خوشحالم که توانستم هر دو حالت را امتحان کنم ↩

5 ژانویه 2024 · برایتان مفید بود؟