چرا Common Lisp اکنون بهترین زبان برنامه نویسی است

آیا موافقید که برخی از زبان های برنامه نویسی بهتر از بقیه هستند؟ اگر چنین است پس یکی از آنها باید بهترین باشد. و در واقع Common Lisp است به خصوص اکنون که LLM ها می توانند کد بنویسند.

LLM ها خیلی سریع کد می نویسند، و این خیلی تغییر می کند، زیرا نوشتن کد قبلا بخش آهسته بود. اکنون بخش آهسته این است که بفهمید آیا برنامه شما واقعا کار می کند یا نه، و قبل از اینکه بتوانید این کار را انجام دهید، باید آن را بازسازی کنید، که ممکن است چند دقیقه طول بکشد.

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

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

همچنین در اکثر زبان ها یک خطا برنامه شما را از کار می اندازد. بنابراین اگر در حال نوشتن کد با یک LLM هستید، باید گزارش های خرابی خود را بخواند تا تغییراتی ایجاد کند و دوباره برنامه خود را اجرا کنید. در Common Lisp برنامه شما خراب نمی شود، متوقف می شود و یک دیباگر را با کل پشته و همه متغیرها باز می کند. شما فقط می توانید LLM خود را به سمت دیباگر بگیرید و آن را رفع کرده و برنامه را از سر می گیرد.

طبق اطلاعات من، Common Lisp تنها زبان رایجی است که همه این کارها را انجام می دهد.

Lisp مخفف "List Processing" است. در Common Lisp کد به صورت لیست نوشته می شود. به عنوان مثال، (+ 1 2) برنامه ای است که دو عدد را اضافه می کند، اما همچنین فقط لیستی از سه چیز است: نماد + و اعداد 1 و 2.

نکته جالب این است که این همان لیستی است که Common Lisp برای ذخیره داده ها استفاده می کند، و از آنجایی که این زبان حول لیست های پردازش ساخته شده است، همه ابزارهای آن برای کار با داده ها نیز روی کد کار می کنند. بنابراین یک برنامه می تواند برنامه دیگری را بگیرد و آن را تغییر دهد، برای مثال می تواند (+ 1 2) را به (* 1 2) تبدیل کند و بلافاصله نتیجه را اجرا کند.

این همان چیزی است که ماکروها را ممکن می کند. ماکرو تابعی است که کد شما را می گیرد و کد جدید را به جای خود برمی گرداند، یعنی می توانید ساختارهای جدیدی را به خود زبان اضافه کنید.

هنگامی که می توانید به زبان اضافه کنید، می توانید آن را به سمت مشکل خود بسازید. بنابراین در Lisp شما فقط یک برنامه نمی نویسید، بلکه یک زبان برای دامنه خود می نویسید و سپس برنامه را در آن می نویسید.

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

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

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

برای LLM ها، کد کمتر به معنای توکن های کمتر است، و توکن ها همان چیزی است که برای آن هزینه می کنید، بنابراین هزینه کمتری برای توسعه می کنید.

همچنین به این معنی است که بخش بزرگتری از برنامه شما می تواند در پنجره زمینه LLM قرار گیرد. اگر LLM شما کل برنامه شما را در پنجره زمینه خود دارد، دید کاملی از قصد شما دارد که منجر به تصمیم گیری بهتر می شود. در تجربه من، بسیاری از اشکالات LLM از تغییر یک قسمت از برنامه من بدون دیدن بقیه ناشی می شوند. بنابراین با Common Lisp که کمتر اتفاق می افتد.

Common Lisp یک استاندارد ANSI است و از سال 1994 به روز نشده است. من این ویژگی را دوست دارم. و به مثال ERP ما برگردیم، اگر کاربران شما خودشان محصول را تغییر دهند، این دقیقا همان چیزی است که شما می‌خواهید زیرا زبان زیر هرگز حرکت نمی‌کند و هیچ چیزی که روی آن می‌سازند هرگز خراب نمی‌شود.

وقتی برنامه ای را در Common Lisp می نویسید، اغلب نمی توانید کتابخانه مورد نیاز خود را پیدا کنید. Quicklisp، مدیر اصلی بسته Common Lisp، چند هزار پروژه دارد در حالی که npm میلیون ها پروژه دارد.

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

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

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

در پایان، دفعه بعد که می خواهید برنامه ای بنویسید از Common Lisp استفاده کنید.

گراهام، پل. "چه چیزی لیسپ را متفاوت کرد." پل گراهام، می 2002، paulgraham.com/diff.html. بازدید در 5 اکتبر 2026.