پنج سوال در مورد طراحی زبان برنامه نویسی

فلسفه هدایت

1. زبان های برنامه نویسی برای مردم

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

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

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

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

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

2. برای خود و دوستانتان طراحی کنید

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

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

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

بحث طراحی زبان برای برنامه نویسان بد این است که تعداد برنامه نویسان بد بیشتر از برنامه نویسان خوب است. شاید اینطور باشد. اما این تعداد کمی از برنامه نویسان خوب به طور نامتناسبی نرم افزارهای بیشتری می نویسند.

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

3. تا حد امکان به برنامه نویس کنترل بدهید

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

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

4. ایجاز خواهر استعداد است

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

من معتقدم که تقریباً هر چیزی که برنامه ها را کوتاهتر کند چیز خوبی است. باید بسیاری از توابع کتابخانه وجود داشته باشد، هر چیزی که می تواند ضمنی باشد باید چنین باشد. نحو باید مختصرتر باشد. حتی نام نهادها باید کوتاه باشد.

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

5. تشخیص هک چیست

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

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

مسائل را باز کنید

1. چگونه کتابخانه های بزرگ را سازماندهی کنیم؟

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

2. آیا مردم واقعا از نحو پیشوند می ترسند؟

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

3. برای نرم افزار سرور به چه چیزی نیاز دارید؟

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

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

آیا می دانید چگونه برنامه هایی را طراحی کنید که قابل نگهداری باشند؟ نرم افزار سرور باید طوری طراحی شود که قابل تغییر باشد. شما باید بتوانید آن را به راحتی تغییر دهید یا حداقل بدانید که تغییر جزئی به چه معناست و چه چیزی مهم است.

یکی دیگر از مواردی که می تواند در نرم افزار سرور مفید باشد، به طور ناگهانی تداوم تحویل است. در یک برنامه وب می توانید از چیزی شبیه به این استفاده کنید CPSبرای دریافت تأثیر روتین ها در دنیای بدون حالت جلسات وب. اگر این ویژگی خیلی گران نباشد، تداوم عرضه ممکن است ارزشش را داشته باشد.

4. چه انتزاعات جدیدی باقی مانده است که باید کشف شوند؟

من مطمئن نیستم که این امید چقدر معقول است، اما شخصاً من واقعاً دوست دارم یک انتزاع جدید کشف کنم - چیزی که می تواند به اندازه توابع کلاس اول یا بازگشت یا حداقل پارامترهای پیش فرض معنادار باشد. شاید این یک رویای غیرممکن باشد. چنین چیزهایی اغلب کشف نمی شوند. اما امیدم را از دست نمی دهم.

رازهای کمی شناخته شده

1. می توانید از هر زبانی که می خواهید استفاده کنید

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

نرم افزار سرور این مدل را به کلی از بین می برد. با نرم افزار سرور می توانید از هر زبانی که می خواهید استفاده کنید. تقریباً هیچ کس هنوز این را درک نکرده است (مخصوصاً مدیران و سرمایه گذاران خطرپذیر). اما برخی از هکرها این را درک می کنند، به همین دلیل است که ما در مورد زبان های ایندی مانند Perl و Python می شنویم. ما در مورد Perl و Python چیزی نمی شنویم زیرا مردم از آنها برای نوشتن برنامه های کاربردی ویندوز استفاده می کنند.

این برای ما، علاقه مندان به طراحی زبان برنامه نویسی چه معنایی دارد که مخاطبان بالقوه ای برای کار ما وجود دارد.

2. سرعت از پروفایلرها می آید

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

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

3. به اپلیکیشنی نیاز دارید که زبان شما را تکامل دهد

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

این به ویژه اگر برنامه شما برخی از مشکلات جدید را حل کند خوب است. این زبان شما را وادار می کند تا ویژگی های جدیدی داشته باشد که برنامه نویسان می خواهند. من شخصاً علاقه مند به نوشتن زبانی هستم که برای برنامه های سرور مناسب باشد.

[در طول بحث، گای استیل نیز به این نکته اشاره کرد و افزود که برنامه نباید شامل نوشتن یک کامپایلر برای زبان شما باشد، مگر اینکه زبان شما برای نوشتن کامپایلر طراحی شده باشد.]

4. زبان باید برای نوشتن برنامه های یکبار مصرف مناسب باشد.

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

5. نحو مربوط به معناشناسی است

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

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

ایده هایی که به مرور زمان برمی گردند

1. زبان های برنامه نویسی جدید

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

2. به اشتراک گذاری زمان

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

3. کارایی

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

من فکر می‌کنم کارایی، حداقل در تنگناهای محاسباتی، مهم خواهد بود. این امر به ویژه برای عملیات I/O مهم خواهد بود، زیرا برنامه های کاربردی سرور بسیاری از این عملیات را انجام می دهند.

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

تله و تله

1. مشتریان

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

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

2. برنامه نویسی شی گرا

می دانم که این یک بیانیه بحث برانگیز است، اما فکر نمی کنم OOP آنقدر مهم باشد. من فکر می کنم این یک پارادایم مناسب برای برنامه های کاربردی خاص است که به ساختارهای داده خاصی نیاز دارند، مانند سیستم های پنجره، شبیه سازی، سیستم های CAD. اما من نمی فهمم چرا باید برای همه برنامه ها مناسب باشد.

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

یکی دیگر از ویژگی های جذاب OOP این است که روش ها بخشی از تأثیر توابع درجه یک را به شما می دهند. اما این خبر برای برنامه نویسان Lisp نیست. هنگامی که عملکردهای درجه یک واقعی دارید، می توانید به سادگی از آنها به هر شکلی که مناسب کار در دستتان است استفاده کنید، به جای اینکه همه چیز را در ظرفی از کلاس ها و روش ها قرار دهید.

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

3. طراحی توسط کمیته

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

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

منبع: www.habr.com