چرا ما همواره به زبان برنامه نویسی جدید نیاز داریم؟

جمعه ۰۴ آبان ۹۷ توسط فاطمه بهاروند

کتاب ساختار و تفسیر برنامه های کامپیوتری که توسط هارولد آبلسون(Harold Abelson) و جرالد جی سسمن(Gerald Jay Sussman) نوشته شده است یکی از بهترین کتاب ها در زمینه ی برنامه نویسی است و نسبت به زمان خودش پیشرفته بود.

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

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

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

زبان برنامه نویسی چیست؟

تابع زیر را مشاهده کنید:

fun square(a: Int) = a * a
// Usage
print(square(10) + square(20))

آیا این به معنای تعریف square(مربع) است؟

از لحاظ فنی این تنها یک ساده سازی است و قسمت body تابع می تواند تمام فراخوانی ها را اینچنین جایگزین کند:

// Kotlin
print(10 * 10 + 20 * 20)

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

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

تکامل زبان برنامه نویسی

صنعت برنامه نویسی تکامل یافته است و زبان های برنامه نویسی نیز از این قائله مستثنی نیستند. به حلقه ی for فکر کنید. در ابتدا تنها حلقه ی when وجود داشت.

برنامه نویسان خیلی زود متوجه یک الگوی مشترک شدند:

// C
int i = 0;
while(i < n) {
    i++;
    // ...
} 

عبارت while بارها و بارها برای تکرار بعضی موارد به خصوص بیشتر برای اعداد، آدرس ها یا تکرار شونده ها مورد استفاده قرار گرفته است.

بنابراین ما حلقه های for را معرفی می کنیم:

// C++
for (int i = 0; i < n; i++) {
    // ...
}

صنعت برنامه نویسی مشاهده کرد که از حلقه ی for بیشتر به منظور تکرار بر روی لیست استفاده می شود.

به همین علت زبان ها یک نوع جدیدی از حلقه ی for را ارائه دادند که برای تکرار بر روی list است:

// Kotlin
for(e in list) {
    // ...
}

بنابراین ما به ویژگی های جدیدی نیاز داریم.

اما حال که زبان تکامل یافته است چرا ما با آنان همراه نشویم؟

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

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

زبان برنامه نویسی scala را در نظر بگیرید. بزرگترین ایرادی که scala دارد تعداد زیاد ویژگی های آن است که درک ادامه ی کار را برای یک توسعه دهنده با خلاقیت اندک به شدت سخت می کند.

زبان برنامه نویسی Go به علت سادگی خود محبوب شده است. این موضوع به تعداد ویژگی های یک زبان مرتبط نیست بلکه به داشتن یک مجموعه ی کامل از ویژگی ها وابسته است.

به نظر من کاتلین نیز به همین علت مورد پسند توسعه دهندگان است. من این زبان را بهترین زبان از لحاظ طراحی می دانم.

در ادامه دلایل محکمی که برای این ادعا وجود دارد را ذکر می کنم:

  • این زبان 6 سال در نسخه ی بتا خود بود و در طی آن زمان مرتبا رشد کرد.
  • این زبان توسط JetBrains طراحی شده است کسانی که بر کار خود مسلط بوده، درک کاملی از زبان های برنامه نویسی دارند و از همچنین نحوه ی استفاده ی مردم در طی سال ها مطلع هستند.

در طول دوره ی بتا برخی از ویژگی های مهم به طور کامل اجرا شدند اما پیش از ارائه ی نسخه 1.0 از آن حذف شدند. از جمله آن موارد می توان به tupleها اشاره نمود. کاتلین به طور کامل از tupleها پشتیبانی می کرد اما پیش از کاتلین 1.0 با توجه به تحلیل ها و تجربیات آن مشخص شد ضررهایش بیش از فواید آن بوده و به همین دلیل تیم کاتلین پشتیبانی خود از tuple را برداشت، توسعه دهندگان نیز می بایست از کلاس های داده به جای آن استفاده کنند. این امر نشان می دهد که JetBrains از اهمیت طراحی عالی به خوبی آگاه است.

از جمله دیگر زبان هایی که از طراحی خوبی برخوردارند می توان به Swift اشاره کرد. Swift سریعتر توسعه می یابد و توسعه دهندگانی که آن را طراحی نموده اند اشتباهات زیادی داشته اند. با این حال اپل طراحی را با انتشار هر نسخه اصلی تغییر داد. آن ها علاقه ای به ارث بری ندارند.

 توسعه دهندگان لب به شکایت گشوده اند اما از دیدگاه طراحی همه چیز عالی است. اگرچه آن ها نمی توانند مدت زیادی به این شرایط ادامه دهند. موارد بیشتری که در Swift وجود دارد سبب شده است که هزینه ی تغییر طراحی افزایش یابد. از این گذشته من فکر نمی کنم آن ها بتوانند ویژگی های اصلی را تغییر دهند.

بنابر مطالب مطرح شده اگر زبان های جدیدی با طراحی های خوب داشته باشیم. آن ها می توانند آخرین زبان های برنامه نویسی باشند؟

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

اولین مورد این است که ویژگی های جدید و راه های تفکر نو به وجود می آیند واز این رو حتی زبان هایی که به بهترین نحو ممکن تکامل یافته اند نیز دیگر کامل نخواهد بود.

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

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

سومین مورد نیز تغییر الگوها است. من در الگوهای برنامه نویسی رکود و انحطاط می بینم اما ما هنوز هم در عمل هر روزه ی خود آن ها را نشان می دهیم.

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

در نهایت تکنولوژی های جدید به وجود آمده و طرز فکر قدیمی که در زمان های گذشته قابل بیان بود ممکن است دیگر به کار نیاید.

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

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

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

مانند نام گذاری ماشین با نام "اسب فولادی" و تلاش برای تعمیر آن با کمک دامپزشکان است.

جمع بندی

اعمال ریاضی را در نظر بگیرید. تساوی می تواند به روش توصیفی بیان شود:

دو به علاوه سه می شود پنج

بیان این عبارت با نشان های ریاضی کاملا متفاوت است.

2 + 3 = 5

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

اگر مهم نبود ما به جای جاوا، جاوا اسکریپت، پایتون یا کاتلین با Assembler کار می کردیم. اما این موضوع مهم بوده و از این رو ما نیاز به بیانی به مراتب بهتر داریم و به همین ترتیب به زبان برنامه نویسی جدید نیز نیازمندیم.

 


کلیدواژه: برنامه نویسی language programming

منابع: medium.freecodecamp.org

ارسال دیدگاه:
برای ارسال دیگاه باید به سیستم وارد شوید و یا ثبت نام کنید. ثبت نام چند لحظه بیشتر زمان شما را نمیگیرد.
مولف:
فاطمه بهاروند
عضو تیم تولید محتوای آرکادمی
مشاهده‌ی پروفایل
آمار و مشخصات:
event
چهارشنبه ۲۵ مهر ۹۷
public
arcademy.ir/+a341
favorite
۲ پسند
comment
۰ دیدگاه
group
۹۸ بازدیدکننده
visibility
۱۲۰ بازدید
رده های این مقاله: