بر اساس تعاریف جدید برنامهنویسی سطح پائین و برنامهنویسی سیستم یکی نیستند و این دو مفهوم به اشتباه یکسان فرض شدهاند.
ترکیب دو ایدهی برنامهنویسی سطح پائین (کار با جزئیات سختافزاری و پیادهسازی ماشین) و طراحی سیستم (ساخت و مدیریت یک مجموعهی پیچیده از مؤلفههای مرتبط) به نظر غیرضروری میرسد؛ اما این قضیه تا چه اندازه صحیح است؟ و از تعریف مجدد سیستمها به چه نتیجهای میتوان رسید؟
برای درک تکامل اصطلاح برنامهنویسی سیستم بازگشت به منشأ سیستمهای کامپیوتری مدرن ضروری است. دقیقا مشخص نیست چه کسی این عبارت را اختراع کرده است اما بر اساس پژوهشها تلاشهای جدی برای تعریف سیستمهای کامپیوتری تقریبا از اوایل دههی ۷۰ آغاز شده است. در مقالهای با نام زبانهای برنامهنویسی سیستم به این تعریف اشاره شده است:
یک برنامهی سیستمی مجموعهای یکپارچه از برنامههای فرعی یا زیربرنامه است، زیربرنامهها یک مجموعهی یکپارچه و بزرگتر از مجموعه اجزا را تشکیل میدهند که اندازه و پیچیدگی آن فراتر از یک حد مشخص است. از نمونههای متداول میتوان به سیستمهایی برای برنامهنویسی چندگانه، ترجمه، شبیهسازی، مدیریت اطلاعات و اشتراکگذاری زمانی اشاره کرد. فهرست زیر مشخصات برنامههای سیستمی را ارائه میدهد که بعضی از آنها را میتوان در برنامههای غیرسیستمی هم پیدا کرد و البته ممکن است یک سیستم مشخص تمام این ویژگیها را به صورت یکجا نداشته باشد:
۱. مسئلهی قابل حل ماهیت گستردهای دارد و شامل تعداد زیادی مسائل فرعی و متنوع است.
۲. از برنامهی سیستمی برای پشتیبانی از برنامههای کاربردی و نرمافزاری دیگر استفاده میشود اما درعینحال میتواند بستهی کاملی از برنامهها هم باشد.
۳. برنامهی سیستمی برای تولید پیوسته طراحی شده است نه به عنوان راهحلی یک جا برای حل یک مشکل در برنامهها
۴. برنامهی سیستمی از نظر تعداد و انواع ویژگیهای تحت پشتیبانی به صورت پیوسته در حال تکامل است.
۵. یک برنامهی سیستمی به یک ساختار یا برنامهی مشخص داخل و میان ماژولها (برای مثال برقراری ارتباط) نیاز دارد و معمولا توسط بیش از یک شخص یا گروهی از اشخاص طراحی و پیادهسازی میشود.
این تعریف تا حدودی قابل قبول است. سیستمهای کامپیوتری معمولا دارای مقیاس گسترده و کاربرد طولانی هستند و به مرور زمان تغییر میکنند. البته با این که این تعریف بیشتر توصیفی است اما چشمانداز اصلی آن جداسازی زبانهای سطح پائین از زبانهای سیستمی است (برای مثال مقایسهی اسمبلی با فرترن).
هدف از زبان برنامهنویسی سیستم فراهم کردن زبانی است که بتوان بدون نگرانی در مورد دستکاری بیتها از آن استفاده کرد و درعینحال به کدی دست یافت که عملکرد آن از کدهای دستی بهتر باشد. چنین زبانی باید اختصار و خوانایی زبانهای سطح بالا را با بازدهی فضا و زمان و دسترسی به امکانات سیستمعامل و ماشین زبان اسمبلر را ترکیب کند. زمان طراحی، نوشتن و اشکالزدایی باید بدون تحمیل سربار بر منابع سیستمی به حداقل برسند. پژوهشگرهای CMU زبانی به نام BLISS (زبانی برای برنامهنویسی سیستم) را منتشر کردهاند که به این صورت تعریف میشود:
BLISS یک زبان پیادهسازی است، البته با توجه به این که هدف تمام زبانهای کامپیوتری پیادهسازی است، این تعریف کمی مبهم است. اما در واقع مفهوم عمومی این اصطلاح مدنظر است یعنی زبانهای سطح بالایی که بیشتر بر یک برنامهی مشخص مثل نوشتن سیستمهای بزرگ نرمافزاری تولیدی برای یک ماشین مشخص تأکید میکنند.
مؤلفان، زبان پیاده سازی را بالاتر از اسمبلی و پائینتر از زبان طراحی میدانند
زبانهای هدفمند مثل کامپایلر، کامپایلرها در این دسته قرار نمیگیرند و البته وما مستقل از ماشین هم نیستند. در این تعریف بر اصطلاح پیادهسازی تأکید میشود و از کلماتی مثل طراحی و مستندسازی استفاده نشده است؛ بنابراین از یک زبان پیادهسازی انتظار نمیرود که طراحی یک سیستم بزرگ یا مستندسازی آن را توصیف کند. مفاهیمی مثل استقلال ماشین، توصیف مشابهی از طراحی و پیادهسازی، خودمستندسازی و مفاهیم دیگر دارند و معیارهایی برای ارزیابی زبانهای مختلف هستند.
در اینجا مؤلفان، زبان پیادهسازی را بالاتر از اسمبلی و پائینتر زبان طراحی میدانند. بر اساس پژوهشهای قبلی، طراحی و پیاده سازی سیستم هرکدام زبان مجزایی دارند. آخرین مدخل مربوط به برنامهنویسی سیستم را میتوان در یک متن آموزشی در مورد یادگیری برنامهنویسی سیستم مشاهده کرد که در ۱۹۷۲ نوشته شده است.
میتوان کامپیوتر را مثل جانداری درنظر گرفت که از تمام دستورات اطاعت میکند. بر اساس یک تصور دیگر، کامپیوترها انسانهایی هستند که از ف ساخته شدهاند یا برعکس، انسانها کامپیوترهایی هستند که از گوشت و خون تشکیل شدهاند. با این حال، با نگاهی دقیقتر به کامپیوترها میتوان به این نتیجه رسید که اساسا کامپیوترها ماشینهایی تابع دستورالعملهای مشخص و ابتدایی هستند.
در اولین روزهای اختراع کامپیوتر، مردم با دستورالعملهای ابتدایی بین دو حالت On و Off با کامپیوتر ارتباط برقرار میکردند. خیلی زود مردم به دنبال دستورالعملهای پیچیدهتر رفتند. برای مثال میخواستند خروجی این مسأله را در کامپیوتر ببینند: X=30*Y؛ با توجه به این که Y=10 در نتیجه X کدام است؟ کامپیوترهای کنونی بدون برنامههای سیستمی قادر به درک چنین زبانی نیستند.
مبانی برنامهنویسی سیستم
برنامههای سیستمی (برای مثال کامپایلرها، لودرها، پردازندههای ماکرو، سیستمهای عامل) برای تطبیق بهتر کامپیوترها با نیازهای کاربران توسعه یافتند. علاوه بر این مردم به دنبال کمک یا دستیارهایی برای آمادهسازی برنامههای خود بودند. این تعریف یادآوری میکند سیستمها در خدمت مردم هستند حتی اگر صرفا زیرساختهایی باشند که ارتباط مستقیمی با کاربرها ندارند.
در دههی ۷۰ و ۸۰ اغلب پژوهشگرها برنامهنویسی سیستم را نقطهی مقابل برنامهنویسی اسمبلی میدانستند. در آن دوره ابزار خوبی برای ساخت سیستمها وجود نداشت (البته هیچ اطمینانی از وجود Lisp در میان این زبانها وجود ندارد هیچ کدام از منابع به Lisp اشاره نکردهاند، با این حال ماشینهای Lisp وجود داشتند).
در اواسط دههی ۹۰، با ظهور زبانهای اسکریپتنویسی داینامیک تغییرات عمدهای در زبانهای برنامهنویسی رخ داد. بهبود سیستمهای اسکریپتنویسی مثل Bash، زبانهایی مثل پرل (۱۹۸۷)، Tcl ، پایتون (۱۹۹۰)، Ruby ، PHP و جاوا اسکریپت (۱۹۹۵) به توسعهی برنامهنویسی کمک کرد. این تغییرات در مقالهی تأثیرگذار اوسترهاوت با عنوان اسکریپت نویسی: برنامهنویسی سطح بالای قرن بیستویک (۱۹۹۸) به اوج خود رسیدند. به موج حاصل از این تغییرات دوگانگی اوسترهاوت بین زبانهای برنامهنویسی سیستمی و زبانهای اسکریپتنویسی گفته میشود.
زبانهای اسکریپتنویسی برای وظایفی متفاوت با زبانهای برنامهنویسی سیستمی طراحی شدهاند و همین مسأله ریشهی تفاوتهای بنیادی این دو زبان است. زبانهای برنامهنویسی سیستمی برای تولید ساختارهای دادهای و الگوریتمها از ابتداییترین عناصر کامپیوتری مثل کلمات حافظه طراحی شدهاند.
در مقابل، زبانهای اسکریپتنویسی برای چسباندن طراحی شدهاند: مجموعهای از مؤلفههای قدرتمند دارند و در اصل برای اتصال این مؤلفهها با یکدیگر در نظر گرفته شدهاند. زبانهای برنامهنویسی برای کمک به مدیریت پیچیدگی، Strongly Typed یا وابستهی زیاد به نوع هستند؛ مفهومی که در مقابل Weakly Typed یا وابسته کم به نوع قرار میگیرد. به این معنی که باید نوع متغیرها، ورودیها و خروجیها توابع و. دقیقا تعیین شوند و کامپایلر پیش از اجرای کدها و رسیدن به مرحلهی اجرای Runtime و بیلد، این مورد را بررسی میکند. در حالیکه زبانهای اسکریپتنویسی Typeless (بدون نوع) هستند. برای مثال میتوان از تعریف متغیر بدون نوع در آنها استفاده کرد و کامپایلر تمام کارها را برعهده دارد. از اینرو برای سادهسازی روابط بین مؤلفهها و توسعهی سریع برنامهها از آنها استفاده میشود. گرایشهای جدید از جمله ماشینهای سریعتر، زبانهای اسکریپتنویسی بهتر، اهمیت فزایندهی واسطههای کاربری گرافیکی و معماریهای مؤلفهای و رشد اینترنت به شدت کاربرد زبانهای اسکریپتنویسی را بالابردهاند.
در سطح تخصصی اوسترهاوت اسکریپتنویسی و سیستم را در راستای محورهای Type Safety (ایمنی نوع) و دستورالعمل به ازای هر عبارت مقایسه کرده است. Type Safety یا ایمنی نوع به قابلیت یا ویژگی یک زبان برنامهنویسی برای جلوگیری یا کاهش رخ دادن Type Errors یا خطاهای ناشی از عدم تطابق نوع گفته میشود. برای مثال تعریف متغیری از نوع اعشاری و به کارگیری آن به جای اعداد صحیح، منجر به وقوع یک Type Error میشود. اوسترهاوت در سطح طراحی بر نقشهای جدید هر کلاس زبانی تأکید میکند: برنامهنویسی سیستم برای ساخت مؤلفهها و اسکریپتنویسی برای چسباندن آنها به یکدیگر درنظر گرفته میشوند.
مقایسهی زبانهای برنامهنویسی بر اساس سطح و درجهی Typing آنها (زبانهای سطح بالاتر دستورالعملهای ماشین بیشتری را برای هر عبارت زبانی اجرای میکنند) زبانهای برنامهنویسی سیستم مثل C از نوع قوی و سطح متوسط هستند (۵ تا ۱۰ دستورالعمل به ازای هر عبارت). زبانهای اسکریپتنویسی مثل Tcl از نوع ضعیف و سطح بالا هستند (۱۰۰ تا ۱۰۰۰ دستورالعمل به ازای هر عبارت).
تقریبا در همین زمان بود که زبانهای موسوم به Garbage Collected به محبوبیت رسیدند. Garbage Collection، زبالهروبی یا بازیافت حافظه، نوعی مدیریت حافظهی خودکار است. در طی این فرآیند فضایی از حافظهی کامپیوتر که قبلا درگیر نگهداری دادهی موردنیاز یک برنامهی کامپیوتری بوده است و اکنون آن برنامه دیگر نیازی به این داده ندارد، آزاد میشود و برای ذخیره و نگهداری دادهی جدید مورد استفاده قرار میگیرد.
در این دهه جاوا و #C به غولهای برنامهنویسی که امروزه میشناسیم تبدیل شدند. با این حال این دو زبان از ابتدا در گروه زبانهای برنامهنویسی سیستمی قرار نگرفتند و از آنها برای طراحی تعداد زیادی از بزرگترین سیستمهای نرمافزاری دنیا استفاده شده است. اوسترهاوت به طور آشکار توضیح میدهد که در دنیای اینترنت کنونی از جاوا برای برنامهنویسی سیستم استفاده میشود.
از دههی گذشته مرز بین زبانهای اسکریپتنویسی و زبانهای برنامهنویسی سیستمی در حال محو شدن است. شرکتهایی مثل Dropbox توانستند سیستمهای مقیاسپذیر و بزرگی را روی پایتون توسعه دهند. از جاوا اسکریپت برای تبدیل UI-های پیچیده و بلادرنگ (Real-Time) در میلیاردها صفحهی وب استفاده شده است. طبقهبندی تدریجی در پایتون، جاوا اسکریپت و دیگر زبانهای اسکریپتنویسی شدت پیدا کرد و به این صورت گذار از کد اولیه به کد تولید تنها با اضافه کردن اطلاعات نوع ایستا امکانپذیر شد.
درعینحال منابع انبوه مهندسی برای زبانهای ایستا (مثل جاوا اسکریپت) و زبانهای پویا (مثل LuaJIT از Lua یا V8 جاوا اسکریپت و PyPy پایتون) وارد کامپایلرهای JIT شدند و آنها را به رقیب عملکردی سیستمهای زبانهای برنامهنویسی سیستمی (C++، C) تبدیل کردند. سیستمهای توزیعشده و بزرگی مثل اسپارک در اسکالا نوشته شدند. زبانهای برنامهنویسی جدید مثل جولیا و سویفت هم محدودیتهایی را برای زبانهای زبالهروب (Garbage Collector) به وجود آوردند.
هیئتی به نام برنامهنویسی سیستم در سال ۲۰۱۴ و بعد از آن، شامل بزرگترین مغزهای زبانهای برنامهنویسی کنونی از جمله بیجارن استروستراپ (خالق ++C)، روب پایک (خالق Go)، آندری آلکساندرسکو (توسعهدهندهی D) و نیکو ماتساکیس (توسعهدهندهی Rust). زبان برنامهنویسی سیستم در سال ۲۰۱۴ را این گونه توصیف میکنند:
رابطهی برنامهنویسی سیستم با عملکرد بالا چیست؟ با محدودیتهای منابع و کنترل سختافزاری چطور؟ یا زیرساخت ابری؟ بهطورکلی به نظر میرسد زبانهایی مثل C ،C++ ،Rust و D از نظر سطح انتزاع و خلاصه بودن از ماشین متمایز میشوند. این زبانها جزئیات سختافزار مثل تخصیص حافظه یا قالب و مدیریت دقیق منابع را نمایش میدهند.
یک تعریف دیگر هم برای آن وجود دارد: در صورت روبهرو شدن با مشکل بازدهی یا بهینهسازی چه مقدار آزادی برای حل آن دارید؟ در زبانهای برنامهنویسی سطح پائین با کنترل دقیق جزئیات ماشین میتوانید هر مشکلی را حل کنید. میتوانید دستورالعمل را بر کل آرایهها اعمال کنید و ساختار دادهای بهدستآمده را در کش (Cache) ذخیره کنید. همانطور که انواع ایستا مثل جمع اعداد صحیح با اطمینان بیشتری اجرا میشوند زبانهای برنامهنویسی سطح پائین هم اجرای مطمئنتر دارند بهطوریکه کدها همانطور که تعریف میشوند اجرا میشوند.
در مقابل، بهینهسازی زبانهای تفسیر شده بسیار پیچیده است. بهراحتی نمیتوان از اجرای قابلانتظار کد توسط Runtime اطمینان حاصل کرد. همین مسئله در کامپایلرهای موازی خودکار هم وجود دارد (Vectorizaiton یا برنامهنویسی آرایهای یک مدل برنامهنویسی نیست. بلکه مانند نوشتن یک واسطه در پایتون است، برای مثال انتظار دارید یک تابع در صورت فراخوانی خروجی int (صحیح) تولید کند).
اغلب به برنامهنویسی سطح پائین، برنامهنویسی سیستم میگویند (با اشاره به جزئیات ماشین)؛ اما معنی سیستم چیست؟ با بازگشت به تعریف ۱۹۷۲ میتوان گفت:
۱.مسئلهی قابل حل، ماهیت گستردهای دارد و شامل تعداد زیادی مسائل فرعی و متنوع است.
۲. از برنامهی سیستمی برای پشتیبانی از برنامههای کاربردی و نرمافزاری دیگر استفاده میشود اما درعینحال میتواند بستهی کاملی از برنامهها هم باشد.
۳. برنامهی سیستمی برای تولید پیوسته طراحی شده است نه به عنوان راهحلی یک جا برای حل مشکلی در برنامهها.
۴. برنامهی سیستمی از نظر تعداد و انواع ویژگیهای تحت پشتیبانی به صورت پیوسته در حال تکامل است.
۵. یک برنامهی سیستمی به یک ساختار یا برنامهی مشخص داخل و میان ماژولها (برای مثال برقراری ارتباط) نیاز دارد و معمولا توسط بیش از یک شخص یا گروهی از اشخاص طراحی و پیادهسازی میشود.
به نظر میرسد این گزینهها بیشتر به مشکلات مهندسی نرمافزار اشاره دارند (پیمانهای بودن، قابلیت استفادهی مجدد، تکامل کد) تا مشکلات عملکردی سطح پائین. این یعنی هر زبان برنامهنویسی که حل این مشکلات را در اولویت قرار دهد یک زبان برنامهنویسی سیستمی است! البته این گزینهها برای تعریف یک زبان برنامهنویسی سیستمی کافی نیستند؛ بنابراین میتوان گفت زبانهای برنامهنویسی پویا یا داینامیک از زبانهای سیستمی دور هستند.
اما مفهوم دقیق این تعریف چیست: زبانهای تابعی مثل Ocaml و Haskell بیشتر از زبانهای سطح پائین مثل C یا ++C به سیستم وابسته هستند. هنگام آموزش برنامهنویسی باید اصول برنامهنویسی تابعی مثل ارزش ثبات، تأثیر سیستمهای نوع غنی در بهبود طراحی واسطه و استفاده از توابع مرتبه بالاتر را درنظر گرفت. مدارس باید برنامهنویسی سیستم و سطح پائین را آموزش دهند.
بنابراین آیا تفاوتی بین برنامهنویسی سیستم و مهندسی نرمافزار وجود دارد؟ پاسخ منفی است اما مشکل اینجاست که مهندسی نرمافزار و برنامهنویسی سطح پائین اغلب اوقات به صورت مجزا تدریس میشوند. با این حال اغلب کلاسهای مهندسی نرمافزار معمولا بر شعار نوشتن واسطهها و تستهای مناسب جاوا متمرکز هستند، به همین دلیل لازم است روش طراحی سیستم با توجه به محدودیتهای زیاد منابع آموزش داده شود.
بهتر است به جای عبارت برنامهنویسی سیستم از برنامهنویسی سطح پائین استفاده شود
شاید به این دلیل برنامهنویسی سطح پائین را سیستم مینامند که جذابترین سیستمهای نرمافزاری از نوع سطح پائین هستند (برای مثال، پایگاه دادهها، شبکهها، سیستمهای عامل و.). از آنجا که سیستمهای سطح پائین محدودیتهای زیادی دارند، برای طراحی آنها نیاز به تفکر خلاق است.
در قدم بعدی، برنامهنویس زبان سطح پائین باید به این سؤال پاسخ دهد که کدام ایدههای طراحی سیستم را میتوان برای کار با سختافزار مدرن تطبیق داد. انجمن Rust در این رابطه عملکرد نوآورانهای داشته است، این انجمن چگونگی پیادهسازی اصول برنامهنویسی تابعی یا طراحی نرمافزاری بر مسائل سطح پائین را بررسی میکند (برای مثال مسائلی مثل قراردادها، کنترل خطا یا امنیت حافظه).
به طور خلاصه بهتر است بهجای عبارت برنامهنویسی سیستم از برنامهنویسی سطح پائین استفاده کرد. اهمیت طراحی سیستمهای کامپیوتری به عنوان یک رشته یا زمینه به خاطر نام آن نیست؛ بنابراین جداسازی این دو مفهوم، طراحی زبان برنامهنویسی را شفاف میکند و دیدگاههای مشترکی را نسبت به این دو حوزه به وجود میآورد: چگونه میتوان سیستمی را حول محور ماشین یا برعکس طراحی کرد؟
۸ رویکرد اوبونتو که باعث تغییر و بهبود لینوکس شدند
زبان برنامهنویسی جاوا 13؛ ابزاری برای بهرهوری بیشتر برنامهنویسان
پایتون محبوبترین زبان برنامهنویسی ۲۰۱۹ لقب گرفت
میت 30 و میت 30 پرو هواوی با سیستم عامل اندروید معرفی میشوند
امکان مشاهده دمای پردازنده گرافیکی به ویندوز 10 اضافه خواهد شد
منبع WILLCRICHTON
آیا محبوبترین زبانهای برنامهنویسی، براساس شاخصها و مولفههای درستی انتخاب میشوند؟ آیا روشهای سنجش محبوبترین زبانهای برنامهنویسی قابل اعتماد هستند؟
معمولا متخصصان نرمافزار، برای اطلاع از محبوبترین زبانهای برنامهنویسی، به سراغ نمودارهای معتبر TIOBE میروند. از طریق این نمودارها، میتوانند متوجه شوند که محبوبترین زبانهای برنامه نویسی در جهان کدام موارد هستند.
نمودارهای معتبر و مفید TIOBE و اطلاعات ارائهشده در مورد محبوبیت زبانهای برنامهنویسی در این نمودارها، نشان میدهد که در طول زمان، و از زمانهای پیشتر، زبانهای برنامهنویسی جاوا و زبان برنامهنویسی C، پادشاهان زبانهای برنامهنویسی و محبوبترین زبانها بودهاند.
اما لحظهای صبر کنید و خیلی سریع نتیجهگیری نکنید. نمودارها و شاخصهای ارائهشدهی PYPL، بهعنوان رقیب نمودارهای TIOBE، نتایج دیگری را نشان میدهد. براساس نمودارهای PYPL، زبانهای برنامهنویسی Python و Java، جزو محبوبترین زبانهای برنامهنویسی و در اصل پادشاهان اصلی زبانهای برنامهنویسی هستند. براساس نمودارهای PYPL، زبان C، که بهشکل شگفتانگیزی با زبان برنامهنویسی C ++ توسعه یافته است، از محبوبیت کمتری برخوردار است و در قسمتهای پایینتر فهرست رتبهبندی محبوبیت زبانهای برنامهنویسی قرار دارد. شاید برای شما هم این سوال پیش بیاید؛ واقعا کدام نتایج درست هستند و کدام نمودار، اطلاعات درستی را ارائه میدهد؟
یکی از موضوعات مهمی که باید به آن توجه داشته باشیم آن است که هر کدام از نمودارها، برای انتخاب محبوبترین زبانهای برنامه نویسی، شاخصها و مولفههای متفاوتی را در نظر میگیرند. البته، یکی از نقاط مشترک در متدولوژی هر دو نمودار این است که عملکرد هر دو در اندازهگیری کثرت زبانهای برنامهنویسی بحثبرانگیز است. TIOBE، کمیت جستجوهای انجامشده در موتور جستجو را بهعنوان مقیاسی برای سنجش درنظر میگیرد. در حالیکه PYPL، به فراوانی جستجوها، و اینکه چند وقت یکبار جستجو شدهاند، اهمیت نشان میدهد و آن را در سنجش خود مورد توجه قرار میدهد.
باید بگوییم که هر دو شاخص اندازهگیری، مولفههای خوبی را برای سنجش در نظر نمیگیرند. بیشک باتوجه به در دسترس بودن منابع آنلاین، میزان جستجو در موتورهای جستجو، نمیتواند بهعنوان یکی از شاخصهای مهم درنظر گرفته شود و روشی قدیمی بهحساب میآید. ممکن است همچنان میلیونها صفحهی وب در مورد یک زبان محبوب ولی قدیمی و شاید مرده، اطلاعاتی را ارائه دهند؛ همانطور که سایتهای زامبی (سایتهایی که به دلایلی، موفق به بهروزرسانی محتوای خود نمیشوند) بسیاری وجود دارد و یا پستهای بلاگهایی که سالها خوانده نشدهاند.
میزان فراوانی جستجوی محتوای آموزشی بهعنوان شاخصی مهم برای محبوبیت یک زبان برنامهنویسی، معیار درستی محسوب نمیشود. زبانهای برنامهنویسی در محیطهای آموزشی، بهوفور به دانشجویان تدریس میشود، و لذا میزان فراوانی جستجوها برای فایلهای آموزشی شاخص درستی برای ارزیابی نیست، و میتواند اطلاعات بسیار متناقضی ارائه بدهد. این مقیاس اندازهگیری، در اصل شاخص معنیداری نیست که بتوان واقعا، میزان محبوبیت زبانهای برنامهنویسی را از روی آن مشخص کرد. در نهایت نمیتوان با این اطلاعات معلوم کرد که کدام زبانهای برنامهنویسی واقعا توسط فراگیران زبانهای برنامهنویسی در عمل مورد استفاده قرار میگیرند.
هنگامی که با دقت بیشتری به اعداد توجه کنید، با مسائل عجیبتری نیز مواجه خواهید شد. با توجه به نمودارهای TIOBE، زبان برنامهنویسی C، در عرض ۵ ماه، از کمترین امتیاز خود، به جایگاه زبان برنامهنویسی سال (Programming Language Of The Year) رسید. بهنظر میرسد که زبان C در سیستمهای نهفته (امبدد)، دوباره ظهور کرده است. اما، علت بروز چنین نتایجی در اندازهگیریها، میتواند مربوط به روشهای ناقص و مصنوعی سنجش باشد.
بیشترین آمار متناقض، مربوط به زبانهای برنامهنویسی Objective-C و Swift است، که برای نوشتن اپلیکیشنهای محلی در سیستم عامل iOS بهکار برده میشوند. بهنظر میرسد که در مجموع، اخیرا محبوبیت زبانهای برنامهنویسی برای پلتفرمهای چندسکویی (cross-platform) مانند Xamarin و React Native کاهش یافته است. اپل در حدود چهار سال، به سمت استفاده از زبان برنامهنویسی Swift متمایل بود، و بهنظر میرسد زبان برنامهنویسی فوقالعادهای است. با این حال، زبان Objective-C هنوز بسیار محبوبتر است و بهصورت گستردهای مورد استفاده قرار میگیرد. وقتی نگاهی به افرادی میاندازیم که با اپلیکیشنهای IOS/tvOS/watchOS سروکار دارند یا با بسیاری از توسعهدهندگان iOS صحبت میکنیم؛ متوجه میشویم بعید است که برنامهنویسی، از زبان Objective-C به زبان Swift تغییر وضعیت نداده باشند.
اما همهی این حکایتها و قصهها، نمیتوانند جای آمار و دادهها را بگیرند. اگر میبینیم که شاخصهای سنجش محبوبیت، نتایجی متفاوت با تجارب شخصی برنامهنویسان اراده میدهند، میتوانیم اینطور نتیجهگیری کنیم که تعصبات شخصی و سوگیریهای فردی هم میتواند باعث ارائهی نتایج نادرست شود. البته یک مقیاس اندازهگیری دیگری نیز برای سنجش محبوبیت زبانهای برنامهنویسی وجود دارد. اگر به گزارش سالانهی GitHub در مورد ۱۵ زبان برنامهنویسی محبوب در پلتفرم توجه کنید؛ متوجه میشوید که نتایج این گزارش، به نتایج ارائهشده توسط تجربهی فردی برنامهنویسان بازار بسیار نزدیک است، و با نتایج ارائهشده از نمودارهای TIOBE و PYPL تفاوتهایی دارد.
طبق گزارش GitHub، در سالهای ۲۰۱۶ و ۲۰۱۷، محبوبترین زبان برنامهنویسی در جهان، با فاصله قابل توجهی از بقیهی زبانها، زبان Javascript بوده است. پایتون در مقام دوم، جاوا در مقام سوم و Ruby در مقام چهارم نمودار قرار دارند. این نتایج، در مقایسه با نمودار TIOBE، تفاوت فاحشی را نشان میدهد. در نمودار TIOBE، ابتدا زبانهای برنامهنویسی جاوا و C محبوبترین زبانها معرفی شدند؛ و سپس با فاصلهی زیاد پایتون و C ++ قرار دارند، جاوا اسکریپت در رتبهی هشتم ایستاده است. همچنین با توجه به نمودارهای PYPL، محبوبیت زبانهای برنامهنویسی بهترتیب بدین صورت گزارش شده است: پایتون، جاوا در ابتدای نمودار و با فاصلهی زیاد، جاوا اسکریپت و PHP قرار دارند.
روشن است که آمار و ارقام گیتهاب، نمایانگر کل این حوزه نیست؛ اندازهی نمونه بسیار بزرگ است و تنها به پروژه های متن باز میپردازد. اما بهنظر میرسد که GitHub، تنها سیستم سنجشی است که زبان Swift را محبوبتر از Objective-C میداند. همین مساله باعث میشود که نتایج آن متقاعدکننده بهنظر برسد؛ اما باز هم بهدلیل متن باز بودن آن، نتایج ارائهشدهی از طریق این سیستم را نمیتوان قطعی در نظر گرفت.
آمار ارائهشده، بسیار مهم هستند. فراتر از بحث کنجکاوی و سرگرمکننده بودن آنها، اطلاعات مهمی را در اختیار قرار میدهند. با اینکه موضوع محبوبیت زبانهای برنامهنویسی، در کل موضوعی چندان مهم و خاص نیست، ولی بیاهمیت هم نیست. بررسی محبوبیت زبانهای برنامهنویسی، تعیین میکنند که چه زبانهایی بیشتر مورد توجه قرار دارند. این موضوع برای افرادی که تمایل دارند زبان برنامهنویسی را دنبال کنند، اهمیت پیدا میکند و در نتیجه افرادی که وارد حوزههای آموزش زبانهای برنامهنویسی میشوند، میتوانند زبانی را آموزش ببینند که محبوبتر است و میتواند زمینهی اشتغال را برای آنها فراهم کند. بنابراین وقتی سه روش مختلف، نتایج متفاوتی را ارائه میدهند، شرایط زیاد جالب نیست و کمی ناراحتکننده بهنظر میرسد.
زبان برنامهنویسی جاوا 13؛ ابزاری برای بهرهوری بیشتر برنامهنویسان
جاوا با عرضهی Jakarta EE 8 بهصورت کامل متنباز شد
پایتون محبوبترین زبان برنامهنویسی ۲۰۱۹ لقب گرفت
گیت هاب دسترسی کاربران ایرانی را مسدود میکند [بهروزرسانی]
اکانت توسعهدهنده اوبونتو در گیت هاب هک شد
منبع TECHCRUNCH
برای مقاصد و کاربردهای گوناگون کاربران و متخصصان، زبانهای برنامهنویسی مختلفی وجود دارد که در زمینههای گوناگون و حتی مصرف برق، با هم تفاوت دارند.
کیفیت خروجی زبانهای برنامهنویسی، بسته به نوع آنها و حتی مهارت برنامهنویس، با هم تفاوت دارد. مصرف برق، یکی دیگر از فاکتورهای دخیل در کارایی سیستمعاملها است که برخی اوقات، دستکم گرفته میشود. اکنون این سؤال ایجاد میشود که آیا مصرف انرژی، نشاندهندهی کیفیت یک زبان برنامهنویسی هست یا خیر؟
گروهی متشکل از محققان ۳ دانشگاه مختلف در پرتقال، سال گذشتهی میلادی تحقیقی را برای پاسخ به سؤال فوق انجام دادند که منجر به مقالهای بهنام Energy Efficiency Across Programming Languages شد. آنها آزمایش خود را روی ۱۰ مسئلهی نرمافزاری بین ۲۷ زبان برنامهنویسی انجام دادند و در حین اجرای نرمافزار حاصل، مقدار مصرف برق هریک از آنها را بررسی کردند. بهعلاوه، سرعت و مقدار اشغال حافظهی رم نیز مورد بررسی قرار گرفت.
محققان پروژهی تحقیقاتی، ۱۰ مسئلهی آزمایشی را در سرویس Computer Language Benchmark Game اجرا کردند. آن سرویس، یک پروژهی نرمافزاری آزاد است که برای مقایسهی کارایی زبانهای برنامهنویسی استفاده میشود و تعدادی مسئلههای الگوریتمی در خود دارد. بهعلاوه، فریمورکی برای اجرای آزمایشها نیز به کاربر عرضه میشود.
سرویس مورد استفاده، قبلا بهنام The Great Computer Language Shootout شناخته میشد. محققان اعتقاد دارند استفاده از سرویس بنچمارک، به آنها امکان داد تا تعدادی برنامهی قابل مقایسه و توسعهیافته را در دسترس داشته باشند. بهعلاوه، سرویس، نسخههای مختلف کامپایلر و راهکارهای متعدد اجرا را نیز در اختیار آنها قرار میداد.
پیادهسازی انواع مختلف بنچمارک، برای آزمایش کارایی و مصرف برق، حیاتی بود. درواقع، نتایج آزمایشها بسته به نوع تست، تغییر میکرد و باید گسترهای جامع مورد آزمایش قرار میگرفت. بهعنوان مثال، زبان برنامهنویسی C از لحاظ کلی، سریعترین زبان با مصرف بهینهی برق بود، اما در آزمایشی شامل اسکن پایگاه دادهی DNA برای یافتن ژنتیک خاص، زبان Rust نتایج بهتری داشت و C در رتبهی سوم مصرف انرژی قرار گرفت.
در همان آزمایش DNA، انتخاب بهترین زبان، به معیارهای آزمایش نیز بستگی داشت. در معیار سرعت، C پس از Rust در رتبهی دوم قرار گرفت، اما در معیار اشغال حافظهی رم، Rust سقوطی ۹ پلهای داشت. زبان فورترن، در بررسی براساس معیار مصرف انرژی، رتبهی دوم را داشت، اما با مرتب کردن نتایج براساس زمان مورد نیاز برای اجرای فرایند،۶ پله سقوط کرد.
جدول کامل مقایسهی زبانهای برنامهنویسی براساس زمان، انرژی و اشغال حافظهی رم
محققان در مقالهی خود تأکید کردند که با دقت از راهنمای استاندارد سرویس CLBG در انتخاب نسخهی کامپایلر برنامهها و روندهای بهینهسازی، پیروی کردند. مصرف برق هر آزمایش نیز توسط ابزاری از اینتل بهنام Running Average Power Limit استفاده شد. برای بهینهسازی نتایج و محاسبهی بهتر میانگین، همچنین خارج کردن فاکتورهایی همچون کش یا سریعتر بودن در اجرای اولیه، هر آزمایش ۱۰ بار تکرار شد. بههمین دلیل، محققان ادعا میکنند که نتایج، قابل اعتماد هستند.
سختافزار و سیستمعامل همهی زبانها در آزمایش، یکسان بود
فاکتور دیگری که برای بهینهسازی نتایج تنظیم شد، سیستمعامل و سختافزار مورد استفاده بود. همهی آزمایشها روی دستگاهی با ۱۶ گیگابایت رم، پردازندهی اینتل Core i5 3.20 GHz Haswell و سیستمعامل لینوکس اوبونتو سرور با کرنل نسخهی 4.8.0 انجام شد. درنهایت، نتایج تحقیقات، موارد قابل توجهی را روشن کرد. بهعنوان مثال:
زبان Lisp، بهطور میانگین ۲.۲۷ برابر C انرژی مصرف میکند (۱۳۱.۳۴ ژول). بهعلاوه، در مقایسه با پاسکال، ۲.۴۴ برابر برای اجرای یک برنامه، زمان نیاز دارد (۴۹۲۶.۹۹ میلی ثانیه) و همچنین، ۱.۹۲ برابر حافظهی رم نیاز دارد (۱۲۶.۶۴ مگابیت).
محققان، نتایج را بین زبانهای کامپایل شده و تفسیر شده هم بررسی کردند. بهعلاوه، دستهبندی مجزایی هم برای زبانهای اجرا شده در ماشینهای مجازی، در مقاله افزوده شد. دستهبندیهای دیگر در مقاله، شامل مقایسهی پاردایمهای مختلف برنامهنویسی همچون انواع شیٔگرا و اسکریپتی میشود.
مقایسهی زمان و انرژی مصرفی
مقالهی منتشر شده، بهطور جدی با نظریهی تأثیر سرعت بر کاهش مصرف انرژی مخالفت کرد. در متن مقاله آمده بود که محاسبهی انرژی مصرفی، فرمولی فیزیکی شبیه به E=T*P نیست که انرژی را به زمان وابسته کند. بخشی از دلیل تناقض نیز، مصرف انرژی بهصورت غیرمنظم است. درواقع، نرخ ثابتی برای مصرف انرژی یک زبان برنامهنویسی، وجود ندارد. درنتیحه، نتایج تحقیق مذکور میتواند یافتههای محققان پیشین و نظریههای آنها پیرامون تأثیر سرعت بر مصرف انرژی را تحت تأثیر قرار دهد.
در یکی از آزمایشهای صورت گرفته، برنامهی نوشته شده در زبان Chapel، نسبت به برنامهای به زبان پاسکال، ۵۵ درصد زمان کمتری برای اجرا نیاز داشت. درحالیکه برنامهی زبان پاسکال، انرژی کمتری (به میزان ۱۰ درصد) مصرف کرد. درنهایت با وجود آن که بسیاری، هنوز سرعت را با مصرف انرژی مرتبط میدانند، محققان مذکور در مقالهی خود بهروشنی اعلام کردند که یک زبان برنامهنویسی سریعتر، وما مصرف انرژی کمتری ندارد».
سرعت بیشتر وما بهمعنای مصرف پایینتر انرژی نیست
پاسخ دادن به سؤال این بخش، دشواریهای زیادی دارد، چرا که مصرف انرژی، به فاکتورهای بسیار متعددی وابسته میشود که از آن میان میتوان به کامپایلر و حتی کتابخانههای مورد استفاده اشاره کرد. محققان در بخش مهم دیگری از مقالهی خود، منبع مصرف انرژی برنامهها را نیز بررسی کردند. آنها میگویند که اکثر برق مصرفی (حدود ۸۸ درصد) توسط CPU مصرف میشود و ارتباطی هم به کامپایل شدن، تفسیر شدن یا اجرا روی ماشینهای مجازی ندارد. البته، برنامههای تفسیر شده، نتایج متفاوتی را در شرایط مختلف نشان دادند و بازهی تنوع آنها از ۸۱.۵۷ درصد تا ۹۲.۹ درصد، تفاوت داشت.
مقایسه براساس اشغال حافظهی رم
نتیجهی مهم دیگر در تحقیقات مذکور، وابستگی اوج استفاده از DRAM را به انرژی مصرفی، نقض کرد. بههرحال، با وجود تمامی یافتههای بالا، پاسخی تقریبا مثبت به سؤال این بخش داده میشود. در مقالهی منتشر شده برای این تحقیق میخوانیم:
۵ زبان برنامهنویسی اول براساس مصرف انرژی، در دستهبندی براساس زمان اجرای برنامهها نیز با تفاوتهایی جزئی در همان رتبهها قرار میگیرند.
از میان ۱۰ مسئلهی آزمایشی انجام شده، در ۹ عدد از آنها، بالاترین امتیاز از لحاظ سرعت و بازدهی، از زبانهایی بهدست آمد که بین ۳ مورد برتر از لحاظ مصرف انرژی قرار داشتند. در بخش دیگری از مقاله گفته شد:
باور عمومی بر آن است که ۳ زبان برتر برنامهنویسی یعنی C و ++C و Rust، بهبهترین نحو بهینهسازی شده و بازدهی بالایی دارند. دادههای ما در تحقیقات نیز همین باور عمومی را تصدیق میکنند.
با وجود گفتههای بالا، وقتی زبانهای برنامهنویسی دیگر را طبق فاکتورهای سرعت و مصرف انرژی مرتب کنیم، نتایج برابری مشاهده نمیشود. تنها ۴ زبان، رتبهبندی برابری در فهرست زمان و مصرف انرژی داشتند (OCaml، Haskel، Racket و Python).
دستهبندی براساس پارادایمهای برنامهنویسی
یکی از نتایج جالب و مهم آزمایشها، دربارهی زبانهای برنامهنویسی کامپایل شده بود. آن زبانها، همیشه در بازدهی انرژی و سرعت، بالاتر از سایر تصور میشوند. نتایج مقاله نیز تاحدودی آن تصورات را تأیید کرد. بهطور میانگین، زبانهای کامپایل شده، ۱۲۰ ژول انرژی برای اجرای راهکارهای نرمافزاری مصرف کردند، درحالیکه زبانهای اجرا شده روی ماشین مجازی یا تفسیری، بهترتیب ۵۷۶ و ۲۳۶۵ ژول انرژی نیاز داشتند.
در مقایسهی زمانهای اجرای برنامهها، زبانهای کامپایل شده باز هم نتایج مثبتی نشان دادند. در نتایج آن بخش گفته شد که زبانهای کامپایل شده بهصورت میانگین ۵۱۰۳ میلیثانیه زمان نیاز داشتند. درحالیکه، زبانهای اجرا شده روی ماشین های مجازی عدد ۲۰۶۲۳ میلیثانیه را برای زمان نشان دادند و همین مقدار، برای زبانهای تفسیری به ۸۷۶۱۴ میلیثانیه رسید. درنهایت، ۴ عدد از ۵ زبان برتر هر ۲ دستهبندی زبانهای کامپایل شده بودند و تنها جاوا، مثال نقض فهرستها بود.
زبانهای کامپایل شده هم از لحاظ زمان و هم انرژی، بازدهی بیشتری داشتند
در میان زبانهای برنامهنویسی با کمترین سرعت، ۵ زبان کند فهرست، نمونههای تفسیری یعنی Lua، Python، Perl، Ruby و Typexcript بودند. بهعلاوه، زبانهای با بیشترین نرخ مصرف انرژی نیز از همان نوع بودند: Perl، Python، Ruby، JRuby و Lua. البته، در نوعی از برنامهنویسی که عبارتها بهصورت سادهسازی شده در زبانهای تفسیری استفاده شدند، ۳ عدد از آنها، Typescript، JavaScript و PHP در میان برترین زبانهای با بازدهی انرژی بالا قرار داشتند.
زبانهای کامپایل شده، در مقایسهی میزان اشغال فضای رم، مانند زمان و مصرف انرژی، بالاترین رتبهها را به خود اختصاص دادند. بهصورت میانگین، آن زبانها به ۱۲۵ مگابیت حافظه نیاز داشتند و زبانهای اجرا شده در ماشینهای محازی، ۲۸۵ مگابیت حافظه اشغال میکردند. زبانهای تفسیری در این بخش نیز امتیاز پایینی داشته و به ۴۲۶ مگابیت حافظهی رم نیاز داشتند. آن زبانها، در رتبهبندی اشغال فضای رم، پایینترین رتبهها را به خود اختصاص دادند که بهعنوان مثال میتوان JRuby، Dart، Lua و Perl را مثال زد. زبان دیگر در میان پایینترین نمونهها از لحاظ اشغال فضای رم، Erlang بود که البته، زبانی تفسیری نیست.
از لحاظ پارادایمهای برنامهنویسی، زبانهای دستوری (Imperative) به ۱۱۶ مگابیت حافظهی رم نیاز دارند. زبانهای شیٔگرا همان آزمایشها را با ۲۴۹ مگابیت، زبانهای تابعی با ۲۵۱ مگابیت و زبانهای اسکریپتی با ۴۲۱ مگابیت حافظهی رم، انجام میدهند. درواقع، زبانهای دستوری در دستهبندیهای دیگر همچون سرعت و مصرف انرژی نیز رتبههای بهتری را بهخود اختصاص دادند.
در مقایسهی پارادایمهای برنامهنویسی، فاکتورهای متعددی باید مورد بررسی قرار گیرند. کاملا مشخص است که پارادایمها و حتی زبانهای هر پاردایم، تأثیرات متفاوتی روی مصرف انرژی، زمان و حافظهی مورد نیاز دارند. بههمین دلیل، اینکه کدام فاکتور برای نتیجه مهمتر باشد، به برنامهنویس و پروژهی در دست اجرای او بستگی دارد.
برخی از پروژههای نرمافزاری، نیازمند درنظرگرفتن همزمان ۲ یا چند فاکتور هستند. بهعنوان مثال، شاید انرژی و زمان اجرا، در پروژهای اهمیت بالا داشته باشد. در چنان موردی، C بهترین گزینه خواهد بود چون در هر ۲ بخش، در صدر جدل قرار دارد. در نمونهای دیگر که زمان درکنار مصرف کمتر حافظهی رم، هدف شما باشد، زبانهای C، Pascal و Go انتخابهای مناسبی هستند. اگر هر ۳ مورد بالا یعنی زمان، انرژی و حافظهی رم برای شما اهمیت دارند، باز هم محققان همان ۳ زبان فوق را پیشنهاد میدهند.
در پایان مقاله، محققان اعلام کردند که در بررسیهای آتی، تأثیر گذر زمان بر اشغال حافظهی رم را بررسی خواهند کرد. نتایج کامل تحقیقات انجام شده، در لینک منبع موجود است و علاقهمندان میتوانند برای بررسیهای عمیقتر، از آن استفاده کنند. بهعنوان مثال، توسعهدهندههای حوزهی اینترنت اشیاء یا زمینههای مشابه، میتوانند با بررسی نتایج، زبانهایی با مصرف انرژی پایینتر را انتخاب کنند.
درنهایت، مقالهی منتشر شده هم برنامهنویسان را با ابهام رها میکند. محققان میگویند که اگر بهدنبال یک پاسخ ثابت و نسخهای نهایی برای انتخاب زبان برنامهنویسی هستید، به پاسخ نخواهید رسید. آنها میگویند با وجود اینکه نتایح، برخی زبانها را از لحاظ سرعت و مصرف انرژی بالاتر از سایر قرار میدهند، هیچگاه نمیتوان زبانی را کاملا بهتر از زبان دیگر دانست. درنهایت باید بدانیم که موقعیت و شرایطی که زبان در آن استفاده میشود، جنبهای حیاتی در بازدهی مصرف انرژی آن دارد.
تلاش باستانشناسان دیجیتالی برای رمزگشایی از یک بازی ویدیویی اسرارآمیز
آموزش رایگان پایتون، راهکار مایکروسافت برای تربیت نسل بعدی برنامه نویسان
زبان برنامهنویسی جاوا 13؛ ابزاری برای بهرهوری بیشتر برنامهنویسان
تغییرات اقلیمی؛ راز صنعت برق که موجب تسریع روند گرمایش زمین میشود
منبع THENEWSTACK
پایتون امسال نیز مانند دو سال اخیر، محبوبترین زبان برنامهنویسی سال لقب گرفت. جاوا، سی، سی پلاس پلاس و R به ترتیب جایگاههای بعدی را کسب کردند.
پایتون در آخرین رتبهبندی سالانه محبوبترین زبانهای برنامهنویسی از سوی IEEE (مؤسسه مهندسان برق و الکترونیک) مجددا به رتبه اول دست پیدا کرده است.
نظرسنجی و رتبهبندیهایی از این قبیل به کاربران و توسعهدهندگان کمک کرده تا متوجه محبوبیت زبانهای برنامهنویسی و ترندهای آن شده و بهدنبال یادگیری یا کار در حوزههای محبوبتر روند.
IEEE Spectrum (مجلهای از مؤسسه IEEE) پایتون را از سال ۲۰۱۷ در صدر فهرست خود قرار داده و سال گذشته این زبان بالاتر از C++ به این مقام دست یافت. در این رتبهدهی به زبان اول نمره ۱۰۰ اعطا شده و تمام زبانهای دیگر به نسبت آن نمره دریافت میکنند. سال گذشته سیپلاسپلاس نمره ۹۹.۷، جاوا ۹۷.۵ و سی ۹۶.۷ را کسب کردند.
انتشار نتایج ششمین رتبهبندی سالانه IEEE نشان از افزایش فاصله پایتون با سایر رقبا دارد. امسال پایتون نمره ۱۰۰، جاوا ۹۶.۳ و سی ۹۴.۴ را کسب کردهاند. سیپلاسپلاس شاهد لغزش بوده و با امتیاز ۸۷.۵ در رتبه چهارم قرار گرفته و رتبه پنجم هم به زبان محاسبات آماری R با امتیاز ۸۱.۵ تعلق گرفتهاست.
طبق اعلام IEEE، پایتون به دلیل داشتن تعداد زیادی کتابخانه تخصصی مخصوصا برای توسعهدهندگان فعال در حوزه هوش مصنوعی، توانسته به این جایگاه دست یابد.
برای مثال میتوان به کتابخانه Keras پایتون اشاره کرد که رابطهایی برای TensorFlow (توسعهدادهشده از سوی گوگل)، جعبه ابزار شناختی مایکروسافت (CNTK) و یادگیری عمیق Theano دارد.
حوزه دیگری که از زمان ظهور پایتون در سال ۱۹۹۱ به وجود آمده، میکروکنترلرهای رایانههای کوچک ارزانقیمت مانند رزبریپای و آدافروت است.
رتبه خوب متلب نشاندهنده اهمیت این زبان در مهندسی سختافزار است. تصویر: Spectrum IEEE
پنج زبان بعدی این رتبهبندی به ترتیب جاوااسکریپت، سیشارپ مایکروسافت، متلب، سوییفت اپل و گو گوگل هستند.
طبق اعلام مجله IEEE Spectrum این رتبهبندی براساس یازده آمار از هشت منبع شامل CareerBuilder، گوگل، گیتهاب، هکر نیوز، IEEE، ردیت، Stack Overflow و توییتر است.
Tiobe، که شاخص رتبهبندی زبانهای برنامهنویسی مخصوص به خودش را دارد، نتایج مربوط به شهریور ۹۸ (سپتامبر ۲۰۱۹) خود را منتشر کرد. ده زبان برتر این سیستم رتبهبندی که براساس چندین موتور جستوجو کار میکند، از این قرار است: جاوا، سی، پایتون، سیپلاسپلاس، سیشارپ، ویژوال بیسیک داتنت، جاوااسکریپت، SQL، PHP و آبجکتیو سی.
نکته مهم این رتبهبندی تغییر رتبه PHP و خارج شدن آن از لیست ده زبان برتر است که PHP از سال ۲۰۰۱ در آن حضور داشتهاست.
تحلیلگران Tiobe میگویند:
زبان php از ابتدا ویژوال بیسیک طراحی وب بود: یادگیری آسان، اجرای آسان. اما غالبا از سوی طراحان وب با پیشزمینه کمی از مهندسی نرمافزار مورد استفاده قرار میگرفت. افول php به دلیل حفرههای امنیتی راحتالاستفاده آن است.
این تحلیلگران همچنین اشاره کردند که فیسبوک، که ابتدا با زبان PHP ساخته شده بود، جایگزین PHP یعنی Hack را در سال ۲۰۱۴ معرفی کرد و از آن پس استفاده از جاوااسکریپت، تایپاسکریپت و پایتون رونق بسیار فراوانی یافت.
شهریور ۹۸ | شهریور ۹۷ | تغییر رتبه | زبان برنامهنویسی | محبوبیت | تغییر |
---|---|---|---|---|---|
۱ | ۱ | بدون تغییر |
Java | ۱۶.۶۶۱% | -۰.۷۸% |
۲ | ۲ | بدون تغییر |
C | ۱۵.۲۰۵% | -۰.۲۴% |
۳ | ۳ | بدون تغییر |
Python | ۹.۸۷۴% | +۲.۲۲% |
۴ | ۴ | بدون تغییر |
C++ | ۵.۶۳۵% | -۱.۷۶% |
۵ | ۶ | + | C# | ۳.۳۹۹% | +۰.۱۰% |
۶ | ۵ | - | Visual Basic .NET | ۳.۲۹۱% | -۲.۰۲% |
۷ | ۸ | + | JavaScript | ۲.۱۲۸% | -۰.۰۰% |
۸ | ۹ | + | SQL | ۱.۹۴۴% | -۰.۱۲% |
۹ | ۷ | - | PHP | ۱.۸۶۳% | -۰.۹۱% |
۱۰ | ۱۰ | بدون تغییر |
Objective-C | ۱.۸۴۰% | +۰.۳۳% |
۱۱ | ۳۴ | + | Groovy | ۱.۵۰۲% | +۱.۲۰% |
۱۲ | ۱۴ | + | Assembly language | ۱.۳۷۸% | +۰.۱۵% |
۱۳ | ۱۱ | - | Delphi/Object Pascal | ۱.۳۳۵% | +۰.۰۴% |
۱۴ | ۱۶ | + | Go | ۱.۲۲۰% | +۰.۱۴% |
۱۵ | ۱۲ | - | Ruby | ۱.۲۱۱% | -۰.۰۸% |
۱۶ | ۱۵ | - | Swift | ۱.۱۰۰% | -۰.۱۲% |
۱۷ | ۲۰ | + | Visual Basic | ۱.۰۸۴% | +۰.۴۰% |
۱۸ | ۱۳ | - | MATLAB | ۱.۰۶۲% | -۰.۲۱% |
۱۹ | ۱۸ | - | R | ۱.۰۴۹% | +۰.۰۳% |
۲۰ | ۱۷ | - | Perl | ۱.۰۴۹% | -۰.۰۲% |
جدول: Tiobe
نظر شما درباره این رتبهبندیها چیست؟ شما از کدام یک از زبانهای معرفی شده در این دو رتبهبندی استفاده میکنید؟ چه زبانهایی میتوانند در آینده محبوبتر و مطرحتر شوند؟ نظرات خود را با ما و سایر کاربران زومیت به اشتراک بگذارید.
تلاش باستانشناسان دیجیتالی برای رمزگشایی از یک بازی ویدیویی اسرارآمیز
آموزش رایگان پایتون، راهکار مایکروسافت برای تربیت نسل بعدی برنامه نویسان
زبان برنامهنویسی جاوا 13؛ ابزاری برای بهرهوری بیشتر برنامهنویسان
هفتمین ماراتون برنامهنویسی تلفنهمراه کشور
منبع ZDNET
زبان برنامهنویسی پایتون کاربردهای گستردهای دارد و برنامهنویسان حرفهای در سازمانهای بزرگی مانند گوگل، اسپاتیفای، پیکسار و حتی آژانس اطلاعات مرکزی از آن استفاده میکنند.
خیدو فانروسوم، دانشمند علوم رایانه هلندی تصمیم گرفت در دسامبر ۱۹۸۹ در تعطیلات کریسمس روی پروژهای شخصی کار کند. او که از کموکاستیهای دیگر زبانهای برنامهنویسی رایانه خسته شده بود، دست به کار شد و زبان برنامهنویسی خودش را ساخت. فانروسوم برای ساخت زبان برنامهنویسیاش سه اصل ساده و ابتدایی داشت:
فانروسوم برای انتخاب نام زبان برنامهنویسی خود از گروه کمدی انگلیسی بهنام مونتی پایتون (Monty Python) الهام گرفت و نام آن را پایتون گذاشت. همچنین نام package repository این زبان برنامهنویسی از نام یکی از قسمتهای کمدی محبوب فانروسوم، یعنی چیزشاپ (Cheese Shop)، انتخاب شده است.
تقریبا سی سال بعد از اختراع فانروسوم، این زبان برنامهنویسی محبوب شد و تعداد جستوجوهای پایتون در گوگل از تعداد جستوجوهای کیم کارداشیان، ستارهی هالیوودی پیشی گرفت. تعداد پرسوجوها دربارهی زبان برنامهنویسی پایتون تا سال ۲۰۱۰ بیش از سه برابر شده بود؛ درحالیکه نمودار تعداد پرسوجوی دیگر زبان برنامههای نویسی معمولا با گذشت زمان، یکنواخت یا حتی نزولی است.
براساس گزارش انجمن برنامهنویسی اِستَک اُوِرفِلو (Stack Overflow)، زبان پایتون نهتنها میان توسعهدهندگان حرفهای محبوبیت پیدا کرده؛ بلکه مردم عادی نیز به آن علاقهمند شده بودند. وبگاه کُدِکادِمی (Codecademy)، یکی از وبگاههای شناختهشده در زمینهی آموزش زبانهای برنامهنویسی نیز اعلام کرده پایتون یکی از زبانهای محبوبی است که کاربران برای یادگرفتن آن به این وبگاه مراجعه میکنند.
زبان برنامهنویسی پایتون باعث شده بسیاری از افراد سردرگم در دنیای برنامهنویسی راه خود را پیدا کنند. پایتونیستها (طرفداران پایتون) با کمک یکدیگر بیش از ۱۴۵هزار بستهی نرمافزاری به Cheese Shop پایتون اضافه کردهاند که موضوعات مختلفی از نجوم تا توسعهی بازی را پوشش میدهد.
فانروسوم، مخترع زبان برنامهنویسی پایتون، از محبوبیت نرمافزار خود لذت میبُرد؛ اما فشار نظارتی و لقبی که به او داده بودند، یعنی دیکتاتور خیرخواه جاویدان» باعث شد از مدیریت زبانی که اختراع کرده کنار بکشد. او از این موضوع وحشت داشت که به بُت زندگی مردم تبدیل شود و دراینباره گفت:
من مشهوربودن را دوست ندارم و احساس راحتی نمیکنم؛ حتی گاهی اوقات احساس میکنم هر حرفی که میزنم یا هر کاری که انجام میدهم، بیشازاندازه به آن توجه میشود.
درنهایت، او در ۱۲جولای سال جاری، پایتونیستها را در مدیریت پایتون تنها گذاشت.
پایتون زبان کاملی نیست و درمقایسهبا سایر زبانهای برنامهنویسی بهرهوری و قابلیتهای تخصصی کمتری دارد. بهعنوان مثال، C و ++C زبانهای سطح پایینتری هستند که به کاربر کنترل بیشتری روی پردازندهی رایانه میدهند. زبان برنامهنویسی جاوا در ساخت اپلیکشینهای بزرگ و پیچیده بهکار گرفته میشود و جاوا اسکریپت برای ساخت اپلیکیشنهای تحت وب مناسب است. زبانهای برنامهنویسی دیگری نیز وجود دارند که هرکدام برای هدفی خاص استفاده میشوند.
بااینحال، سینتکس پایتون یا نحوهی نوشتن آن بهاندازهای ساده است که یادگیری آن را آسان میکند. همچنین، وجود بستههای نرمافزاری شخص ثالث، پایتون را به زبانی همهمنظوره تبدیل کرده که تطبیقپذیری آن با استفادهی گستردهی و کاربران زیاد آن ثابت شده است. برای نمونه، آژانس اطلاعات مرکزی از زبان برنامهنویسی پایتون برای هککردن، شرکت فیلمسازی پیکسار از آن برای ساخت فیلم، گوگل برای کرالکردن صفحات وبسایت و اسپاتیفای در سیستم پیشنهاد آهنگ به کاربران خود از پایتون بهره گرفته است.
یکی از بستههای نرمافزاری کاربردی و جذاب پایتون برای پایتونیستها در Cheese Shop، هوش مصنوعی است. کاربران به کمک این زبان میتوانند شبکههایی عصبی بسازند که از ارتباطات مغز برای پیداکردن الگوی بین دادههای حجیم استفاده میکند. فانروسوم میگوید پایتون به زبان برنامهنویسی محبوب محققان هوش مصنوعی تبدیل و بستههای نرمافزاری زیادی برای آن ساخته شده است.
البته همهی پایتونیستها تا این اندازه جاهطلب نیستند. زک سیمز، رئیس وبگاه Codecademy معتقد است بسیاری از بازدیدکنندگان وبسایت دنبال مهارتهایی هستند که در کارهای غیرفنی به آنها کمک کند. بهعنوان مثال، بازاریابان از پایتون برای ساخت مدلهای آماری استفاده میکنند که میزان تأثیرگذاری پویش تبلیغاتی را اندازهگیری میکند. دانشجویان برای بررسی درستی توزیع نمرهها از پایتون بهره میگیرند و حتی رومهنگاران بهمنظور جمعآوری دادههای مدنظرشان با پایتون برنامهنویسی میکنند. پایتون همچنین برای کاربران حرفهای صفحهگسترده (Spreadsheets) دردسترس است.
استفاده از این زبان برنامهنویسی بسیار گسترده شده است؛ بهطوریکه حتی سیتیگروپ (Citigroup)، یکی از بانکهای آمریکایی، دورهی پایتون برای تحلیلگران کارآموز برگزار میکند. وبسایت کاریابی eFinancialCareers نیز گزارش داده تعداد متقاضیان مربی پایتون در سالهای ۲۰۱۵ تا ۲۰۱۸ بیش از چهار برابر شده است. بااینحال، برخی تحلیلگران از افزایش محبوبیت این زبان ابراز نگرانی کردهاند. سیزر برا، مشاور شرکت Bain & Company، دربارهی محبوبیت زبان پایتون هشدار داده و گفته است:
ترسناکترین موضوع در فراگیرشدن یک ابزار این است که شخصی نحوهی استفاده از آن را یاد گرفته؛ اما نمیداند از درون چگونه کار میکند. شخصی که کار با پایتون را به تازگی یاد گرفته است، بدون نظارت فردی حرفهای به نتایج دقیقی دست پیدا نخواهد کرد.
یکی از راهحلها برای ازبینبردن مشکل کاربران تقریبا تازهکار این است که تمام جوانب زبان برنامهنویسی به آنها آموزش داده شود. پایتون محبوبترین زبان مقدماتی در دانشگاههای آمریکا در سال ۲۰۱۴ بوده است؛ اما فقط در رشتههای علوم، فناوری، مهندسی و ریاضی آموزش داده میشود. یکی از راهحلهای کاربردی این است که علوم رایانه از دوران ابتدایی مدرسه به دانشآموزان آموزش داده شود. هادی پرتوی، رئیس بنیاد Code.org میگوید:
۴۰درصد مدارس آمریکا درحالحاضر چنین درسهایی برای دانشآموزان دارند؛ درحالیکه در سال ۲۰۱۳، تنها ۱۰درصد آنها برنامهنویسی را به دانشآموزان یاد میدادند. حدود دوسوم کودکان ده تا دوازدهساله در وبگاه Code.org حساب کاربری دارند. اگر پیشرفتکردن و خودکارشدن کارها بههمین ترتیب ادامه پیدا کند، شاید ۹۰درصد والدین آمریکایی خواستار آموزش علوم یارانه به فرزندانشان شوند.
اینکه پایتون تا چه اندازه رشد میکند، هنوز معلوم نیست. زبانهای برنامهنویسی بسیار محبوبی در گذشته وجود داشتهاند که امروزه چندان طرفدار ندارند و به حاشیه رفتهاند. در سال ۱۹۶۰، زبان برنامهنویسی فورترن (Fortran) در کل دنیا محبوب شده بود و به کارآموزان آموزش داده میشد. بیسیک (Basic) و پاسکال (Pascal) نیز از دیگر زبانهایی هستند که روزگاری در اوج محبوبیت بودهاند. هادی پرتوی نیز زبان جاوا اسکریپت را بهعنوان زبان اصلی سایت Code.org انتخاب کرده است؛ زیرا انتخاب استاندارد برای انیمیشنسازی صفحات وب است.
هیچ زبان برنامهنویسی نمیتواند به شکل همهمنظوره استفاده شود و تعیین محدوده و تخصص برای هرکدام از آنها ضروری است. بااینحال، نمیتوان این حقیقت را انکار کرد که خیدو فانروسوم زبانی را اختراع کرد که همیشه در یاد برنامهنویسان خواهد ماند.
تلاش باستانشناسان دیجیتالی برای رمزگشایی از یک بازی ویدیویی اسرارآمیز
آموزش رایگان پایتون، راهکار مایکروسافت برای تربیت نسل بعدی برنامه نویسان
زبان برنامهنویسی جاوا 13؛ ابزاری برای بهرهوری بیشتر برنامهنویسان
پایتون محبوبترین زبان برنامهنویسی ۲۰۱۹ لقب گرفت
منبع ECONOMIST
غولفناوری در یک سری ویدئو آموزشی که در سایت یوتیوب قرار داده است قصد آموزش رایگان زبان برنامهنویسی پایتون به علاقهمندان برنامهنویسی را دارد.
مایکروسافت قصد دارد برنامهنویسی به زبان پایتون را بهصورت رایگان به افراد علاقهمند آموزش بدهد. دورههای جدید آموزشی مایکروسافت قصد دارد به برنامهنویسان برای یادگیری زبان پایتون کمک کند و سپس توسط خدمات ابری آژور برنامهنویسان بتوانند اپلیکیشنهای هوشمصنوعی خود را طراحی کنند.
مایکروسافت یک دوره آموزشی ۴۴ قسمتی بهنام پایتون برای تازهواردها (Python for Beginners) در یوتیوب منتشر کرده است که هر قسمت در حدود ۳ الی ۴ دقیقه آموزش است. این دوره بهوسیلهی دو مربی که اشتیاق زیادی به برنامهنویسی دارند آموزش داده میشود.
البته باید گفته شود این دوره کاملا مناسب برای تازهواردها نیست و بهعنوان پیشنیاز ممکن است لازم باشد پیش از شروع کمی با برنامهنویسی به زبانهای دیگر مانند JavaScript آشنایی داشته باشید؛ یا حداقل با زبان برنامهنویسی دیداری اسکرچ (Scratch) که توسط ام آیتی عرضه شده است و مناسب کودکان و نوجوانان است آشنا شده باشید.
ممکن است بهعنوان پیشنیاز، احتیاج به آشنایی مختصری با زبانهای برنامهنویسی دیگر مانند JavaScript داشته باشید
با این حال این دوره ممکن است مشوق خوبی برای ایدههای کوچک و بزرگ ساخت اپلیکیشنهای یادگیری ماشین، وب یا خودکار سازی بعضی فرایندهای کامپیوترتان باشد.
تمرکز این دوره آموزشی روی نسخهی ۳ و بالاتر پایتون است؛ ولی طبق گفتههای مایکروسافت این دوره با این حال مناسب کاربران نسخههای ۲ به بالاتر پایتون نیز هست.
مایکروسافت برای این دورهی آموزشی خود صفحهای در گیتهاب راهاندازی کرده که دارای منابع اضافه آموزشی برای دوره است. این صفحه شامل اسلایدها و نمونه کد است که میتواند به دانشآموزان در یادگیری بهتر پایتون کمک کند.
دورهی آموزشی پایتون برای تازهواردها توسط کریستفر هریسون (Christopher Harrison) یکی از مدیران برنامه ارشد مایکروسافت و سوزان ایباخ (Susan Ibach) یکی از مدیران توسعهدهندهی تجاری مایکروسافت در واحد هوشمصنوعی بازیها ارائه میشود.
دلایل بسیار زیادی وجود دارد که مایکروسافت قصد دارد افراد بیشتری با پایتون کار کنند. البته همین حالا نیز به دلیل سادگی این زبان برنامهنویسی، افراد زیادی مشغول به استفاده از آن هستند. در کنار این موضوع وجود کتابخانههای زیاد این زبان به توسعهدهندگان کمک میکند که بتوانند بهطور مثال بهوسیلهی فریمورکهایی مانند تنسرفلو (TensorFlow) شرکت گوگل یا جعبهابزار شناختی مایکروسافت (CNTK) با مباحثی مانند یادگیری ماشین ارتباط برقرار کنند.
در کنار این موضوع مایکروسافت در حال ارائهی پشتیبانی بهتر برای زبان پایتون در ویرایشگر محبوب خود یعنی ویژوال استودیو کد (Visual Studio Code) یا با اختصار VS Code است؛ تا به توسعهدهندگان اجازه دهد که کد خود را بهکمک ویژوال استودیو کد بهصورتهای مختلفی مانند روی کامپیوتر محلی خود، ماشین از راهدور، فناوری کنتینرها یا توسط سیستمعامل زیرسیستم لینوکس برای ویندوز (WSL) ذخیره و ویرایش کنند.
مایکروسافت صاحب افزونهی پایتون برای ویژوال استودیو کد است که یکی از محبوبترین افزونهها در کل فروشگاه افزونه برای توسعهدهندگان ویژوال استودیو کد بهشمار میرود. خود ویرایشگر ویژوال استودیو کد توانسته است یکی از محبوبترین ویرایشگرهای متن در بین توسعهدهندگان شود و بهدلیل اینکه بخشی از تمرکز این ویرایشگر روی هوشمصنوعی قرار دارد، مایکروسافت ویرایشگر خود را در توزیع محبوب پایتون آنادا قرار داده است.
با این حال مزیت اصلی این است که مایکروسافت میتواند جامعه توسعهدهندگان پایتون را بهکمک سیستم خدمات ابری خود یعنی آژور برای ساخت اپلیکیشنهای هوشمصنوعی گسترش دهد. هماکنون نیز در سیستم خدمات ابری آژور مایکروسافت قسمتی بهعنوان Azure Machine Learning Studio وجود دارد که از زبان پایتون نیز پشتیبانی میکند. مایکروسافت در شهریور ماه در بیانهای اعلام کرد که قرار است پشتیبانی کامل از فریمورک PyTorch 1.2 در بخش یادگیری ماشین آژور صورت گیرد. PyTorch یک فریمورک یادگیری ماشین برای زبان برنامهنویسی پایتون است که توسط تیم تحقیقاتی هوشمصنوعی فیسبوک عرضه شده است.
از مزیتهای دورهی جدید ارائه شده توسط مایکروسافت میتوان به بخشهای شروع سریع اشاره کرد که بهعنوان مثال در یکی از این بخشها نحوهی تشخیص چهره انسان در تصاویر بهکمک API چهره آژور برای پایتون آموزش داده میشود.
یکی دیگر از بخشهای آموزش این دوره بهشما نحوه استفاده از REST API دید کامپیوتر را آموزش خواهد داد. هردو این موارد جزو خدمات شناختی مایکروسافت است.
تصاویر پتنت سرفیس ایرباد مایکروسافت با سَری تنظیمشدنی منتشر شدند
مایکروسافت با واقعیت مجازی DreamWalker، مسیر پیادهروی را شخصیسازی میکند
جزئیات جدید از سیستمعامل ویندوز 10X فاش شد
مایکروسافت در پروژهی ۱۰ میلیارد دلاری خدمات ابری پنتاگون، آمازون را شکست داد
منبع ZDNET
باستانشناسان با بیلهای دیجیتالی بهدنبال حفر کدهای اولین بازیهای ویدیویی هستند. هدف آنها افشای رازهای فراموششدهای است که ممکن است با امروز در ارتباط باشند.
شما و تیمی از باستانشناسها در گورستانی از زامبیها گرفتار شدهاید.» موقعیتی رقتانگیز. این سناریوی بازی Entombed یکی از بازیهای Atari 2600 است. گوردخمهها مکانهای خشنی هستند؛ یک هزارتوی دوبعدی و نزولی که بازیکنان برای فرار از زامبیها در آن حرکت میکنند. اما این بازی به کابوس باستانشناسان دیجیتالی تبدیل شده است.
Entombed که در سال ۱۹۸۲ منتشر شد، بازی چندان پرفروشی نبود و امروزه هم به دست فراموشی سپرده شده است؛ اما بهتازگی دانشمندان کامپیوتر و باستانشناسی دیجیتالی تصمیم به تفکیک کد بازی و بررسی ساختار آن گرفتهاند.
بهگفتهی جان آیکوک از دانشگاه کالگاری آلبرتای کانادا، Entombed همیشه جذاب و اسرارآمیز بوده؛ اما از آنجا که در گذشته به شهرت بالایی نرسیده، سوژهی تحلیل و بررسی عمیق هم قرار نگرفته است. به همین دلیل، آیکوک و همکار او، تارا کوپلستون در دانشگاه یولک بریتانیا Enombed را به ۵۰۰ عنوان دیگر کنسول بازی Atari 2600 ترجیح دادند و آن را به سوژهی پژوهش خود تبدیل کردند.
کوپلستون و آیکوک از باستانشناسان بازیهای ویدیویی هستند که به بررسی بخشهای فراموششدهی نرمافزاری و تفکیک آنها میپردازند؛ از میان این بخشها به سرنخهایی دربارهی اولین روزهای بازی ویدیویی میرسند. پردهبرداری از راز این بازیها میتواند به برنامهنویسهای امروزی کمک کند.
بسیاری از بازیهای ویدئویی امروزه به کالای مجموعهدارها تبدیل شدهاند و در ازای صدها و حتی هزاران دلار میتوان به آنها دسترسی پیدا کرد
آیکوک و کوپلستون هم مانند کاوشگرهای شجاع گوردخمهها بهدنبال آثار باستانی در Entombed بودند. نتایج آنها فراتر از انتظار بود: آنها موفق به یافتن یک بیت کد اسرارآمیز شدند که قادر به توصیف آن نبودند. به نظر میرسد منطق پشت این بیت برای همیشه گم شده است.
بازی به سبک هزارتو در اواخر دههی ۱۹۷۰ و اوایل دههی ۱۹۸۰ رواج پیدا کرد اما هر برنامهنویس روش خود را برای ساخت هزارتو داشت. در عصر آتاری ساخت بازی نیاز به مهارت بالایی داشت زیرا سیستمهای کامپیوتری که قادر به اجرای چنین بازیهایی بودند، محدودیت بالایی داشتند.
اگرچه هزارتوهای دوبعدی و مانعدار بازی entombed در مقایسه با استانداردهای کنونی گرافیک کامپیوتری ساده بهنظر میرسند؛ اما در سال ۱۹۸۲ به دلیل حافظهی محدود کارتریجهای بازی، امکان طراحی یک مجموعه هزارتو، ذخیرهسازی آنها در بازی و سپس نمایش آنها روی صفحهی نمایش وجود نداشت. در بسیاری از بازیها، هزارتوها بهصورت رویهای» ساخته میشدند یا به بیان دیگر، خود بازی آنها را بهصورت تصادفی میساخت؛ بنابراین بازیکنها هرگز یک هزارتو را دو بار طی نمیکردند.
اما چگونه میتوان برنامهای کامپیوتری برای جلوگیری از تولید بیرویهی هزارتو یا به بیان دیگر پلانی نفوذناپذیر ساخت؟ آیکوک به دشواری مسئله کاملا آگاه بود و تصور میکرد در اعماق Entombed به فرآیندهای هوشمندانهای رسیده است. او میگوید:
الگوریتم هزارتوی این بازی درست مانند یک لانهی خرگوش بود. هرچقدر بیشتر به آن نفوذ میکردم، به نظر میرسید نکتهی منحصربهفردی در مورد این بازی وجود دارد.
آیکوک متوجه شد، هزارتو براساس یک توالی ترتیبی ایجاد شده است. بازی با ترسیم هر مربع جدید هزارتو تصمیم میگیرد دیوار یا فضایی برای حرکت کاراکترهای بازی بسازد؛ بنابراین هر مربع باید مقدار wall» (دیوار) یا no wall» (فاقد دیوار) یا به عبارت دیگر بیتهای ۰ یا ۱ را بگیرد. الگوریتم بازی با تحلیل یکی از بخشهای هزارتو بهصورت خودکار تصمیمگیری میکند. این الگوریتم از یک کاشی پنج مربعی استفاده میکند که مشابه آجرهای بازی تتریس است. این کاشی ماهیت مربع بعدی در هر سطر را مشخص میکند.
اما بخش جذاب ماجرا چگونگی این فرایند است. منطق اصلی تعیینکنندهی مربع بعدی در جدول مقادیر احتمالی نوشتهشده در کد بازی قفل شده است. جدول براساس مقدار کاشی پنجمربعی به بازی میگوید، هر کدام از مقادیر wall، no wall یا تصادفی یکی از این دو را انتخاب کند.
شاید روش ساخت جدول به نظر ساده برسد اما در واقعیت کسی تاکنون موفق به محاسبهی آن نشده است. آیکوک و کوپلستون تلاش کردند جدول را مهندسی مع کنند. آنها برای پی بردن به نوع طراحی جدولها بهدنبال الگوهایی در مقادیر رفتند اما هیچ نکتهی سودمندی پیدا نکردند؛ بنابراین میتوان پیچیدگی بالای این طراحی را نشانهای برای نبوغ برنامهنویسهای آن دوران دانست. با هر بار اجرای بازی یک هزارتو استخراج میشود. صرفنظر از اینکه مقادیر جدول تصادفی یا اندکی متفاوت باشند، ممکن است ترسیم هزارتو با شکست روبهرو شود. به همین دلیل توصیف ساختار الگوریتم به نظر پیچیده میرسد.
هزارتوها در اولین بازیهای کامپیوتری رایج بودند، اما برنامهنویسها ترجیح میدادند بهجای ذخیرهسازی آنها داخل بازی به تولید تصادفی آنها بپردازند
بهگفتهی کوپلستون، این بازی تنها یک نمونه از مسائل پیچیده در باستانشناسی بازیهای ویدئویی است. او میافزاید:
این جدول کاملا غیرعادی است. براساس یک فرضیه، وقتی چیزی را پیدا میکنیم، تازه میتوانیم به ماهیت آن پی ببریم؛ اما اغلب اوقات هیچ ایدهای از اتفاقات نداریم.
برای آیکوک راز حلنشدهی جدول به تأخیر افتاده است. او میگوید: بهعنوان یک دانشمند معتقدم روشهایی منطقی برای درک این مسئله وجود دارد و همهچیز آنطور که به نظر میرسد، نیست.» هر دو دانشمند حدس میزنند برنامهنویس الگوریتم هزارتو باید مقادیر جدول را آنقدر تغییر داده باشد که به نتیجهی دلخواه برسد اما باز هم نمیتوان منطق این کدها را توضیح داد.
برنامهنویس بازی در زمان نوشتن جدول هشیاری کافی را نداشته است
آیکوک و کوپلستون در طول پژوهش خود توانستند با اسیو سیدلی، یکی از افراد درگیر در تولید بازی Entombed مصاحبه کنند. سیدلی به یاد میآورد که جدول در آن زمان برایش گیجکننده بوده و قادر به حل آن نبوده است. او مدعی است، برنامهنویس جدول هنگام نوشتن آن هشیار نبوده: او به من گفت، این ایده وقتی به ذهنش رسید که تحت تأثیر الکل بود و هشیاری نداشته است.» آیکوک برای تماس با برنامهنویس تلاش کرد اما پاسخی دریافت نکرد. شاید هرگز نتوان به منطق این الگوریتم پی برد و منطق این بازی آتاری برای همیشه بهصورت یک راز باقی بماند.
آندرو رینهارد از دانشگاه یورک در مورد باستانشناسی بازیهای ویدیویی مقاله نوشته است. به اعتقاد او پروژهی آیکوک و کوپلستون روی Entombed نشاندهندهی الماسها و گنجینههای زیادی هستند که در اعماق بازیها و بهطور کلی نرمافزارهای قدیمی در انتظار کشف شدن هستند. رینهارد میافزاید: من احساس میکنم آنچه در Entombed رخ داده، اتفاق نادری است که تاکنون موفق به کشف آن نشده بودیم.»
جذابیت بازیهای چند دهه پیش برای باستانشناسان امروزی به نظر عجیب میرسد. آنها میخواهند با حفاری بازیهای گذشته به گنجینههای مدفون در اعماق آنها برسند. به عقیدهی رینهارد، بازیهای ویدیویی به یکی از بخشهای عمدهی تجاری و مهم از فرهنگ جامعه تبدیل شدهاند. بازیها بخشی از تاریخچهی انسان را شکل میدهند.
باستانشناسان دیجیتالی با بررسی بازیهای قدیمی میتوانند به سرنخهایی دربارهی تکامل برنامهنویسی برسند، به عملکرد فناوریهای قدیمی پی ببرند و دیدگاههایی دربارهی فرهنگ روبه نابودی قرن بیستم به دست بیاورد. برنامهنویس دیگری به نام الکسی پپرز از شرکت Improbable کانادا، بازیهای قدیمی را به چشم آثار باستانی میبیند.
Atari در سال ۱۹۸۳ صدها هزار کارتریج بازی را در نزدیکی آلاموگوردو در نیومکزیکو دفن کرد؛ ۳۰ سال بعد کارتریجها استخراج شدند
پپرز معتقد است، برخی از برنامهنویسان اوایل دههی ۱۹۸۰ ممکن است کد خود را برای اجرای Entombed دستکاری کرده باشند؛ این کار نوعی آزمون و خطا بوده که در برنامهنویسی کنونی هم رایج است. پی بردن به روشهای برنامهنویسی در اولین بازیها و غلبه بر محدودیتهای دستگاههای آن زمان تنها جذابیت آکادمیک ندارد.؛بلکه از نتایج این پژوهشها میتوان در پروژههای کنونی هم استفاده کرد. برای مثال برنامهنویسی بازیها و تجربیات واقعیت مجازی را در نظر بگیرید؛ شاید از نظر بصری تفاوتهای زیادی با بازیهای دوبعدی آتاری داشته باشد، اما مسئله و تقاضایی که از برنامهنویس میشود یکسان است. پپرز میگوید:
از کد بازیهای قدیمی میتوان برای طراحی بازیهای جدید استفاده کرد
از نظر تکنیکی محدودیت بالایی وجود دارد، زیرا بازی VR با نرخ فریم بسیار بالایی اجرا میشود و از نظر حرکت و عملکرد بازیکن با محدودیت روبهرو هستید.
برنامهنویسهای قرن بیستویک با بررسی ترفندها و راهحلهای عصر پیش از خود و کنار زدن محدودیتهای فناوری میتوانند به یافتههای سودمندی برسند. آیکوک معتقد است، حل الگوریتم هزارتوی بازی Entombed یک نمونهی خوب از خلاقیت در برنامهنویسی بازی محسوب میشود. او میافزاید: از دیدگاه مدرن روش حل این مسئله در زمان و فضایی محدود، مطالعهی موردی جالبی است.»
باستانشناسهای دیجیتال تنها به بررسی کدها نمیپردازند. آتاری در سال ۱۹۸۳ تقریبا ۷۰۰ هزار کارتریج بازیهای ویدیویی را در زبالهدان آلاموگوردوی نیومکزیکو دفن کرد. این کار رویدادی تاریخی در تاریخچهی بازیهای ویدیویی است و به سوژهی حدس و گمان بسیاری از افراد تبدیل شده است.
بازیهایی که این سازمان برای دفن انتخاب کرده بود، محبوبیت زیادی نداشتند و فروش آنها غیرممکن بود. برای مثال ET یا فرازمینی بهعنوان بدترین بازی ویدیویی تاریخ شناخته میشود. بیش از سه دهه کارتریجها زیر زمین دفن بودند؛ اما در سال ۲۰۱۴ آندرو رینهارد و همکاران او به حفاری این منطقه پرداختند. رینهارد موفق به استخراج ۱۳۰۰ کارتریج شد. صدها بازی ویدیویی ET هم با رقم ۱۰۸ هزار دلار در Ebay به فروش رفتند.
از کد سیستمهای دارای توان رایانشی محدود میتوان برای کمک به ساخت بازیهای امروزی و سیستمهای واقعیت مجازی استفاده کرد
در ابتدا به نظر میرسید هیچکدام از بازیها قابل اجرا نیستند، اما یک گیمر با خرید یک کپی از بازی Asteroids و پاکسازی و اتصال مجدد برخی وسایل الکترونیکی، موفق به اجرای مجدد آن شد. شاید اگر کارتریجها چند دهه دیگر در گورستان نیومکزیکو میماندند، بهطور کامل از کار میافتادند و اجرای آنها غیرممکن بود؛ اما چالش اصلی باستانشناسهای دیجیتالی زمان است.
باستانشناسی بازیهای ویدیویی تقریبا کاری فوری است زیرا شکل فیزیکی بازیها مرتب در حال تغییر است؛ بنابراین منطق و مهارت برنامهنویسی چنین بازیهایی خیلی زود از بین خواهد رفت. به همین دلیل است که هدف پروژههای آرشیوسازی کامپیوتری، ذخیرهسازی دیجیتالی بازیهای قدیمی و تلاش برای حفظ طولانیمدت آنها است.
اما محافظت از بازیهای ویدیویی تنها قدم اول است. جدول هزارتوی اسرارآمیز در Entombed نشان میدهد، حتی با وجود سوابق خوب، درک کامل یک بازی چالش دیگری است که شاید دستیابی به آن هرگز ممکن نباشد. به عبارتی Entombed میتواند نوعی بنبست باشد؛ همانطور که دستورالعمل بازی هشدار میدهد: قبل از دانستن هرچیزی، دفن خواهید شد.»
باتریهای کوانتوم اساسا مبنیبر قواعد اصول کوانتومی کار میکنند. دانشمندان موفق شدهاند طرحی از این نوع باتری ارائه دهند که شارژ آن تمام نمیشود.
دانشمندان دانشگاه آلبرتا و تورنتو موفق شدند طرح باتری کوانتوم جدیدی ارائه کنند که شارژ آن تمام نمیشود. گابریل هانا، شیمیدان دانشگاه آلبرتا و مسئول این مطالعه گفت:
باتری کوانتومی باتری کوچکی در ابعاد نانو است که برای عملیاتهایی در سطح نانو طراحی میشود.
وی همچنین اظهار کرد این مطالعه اثبات میکند بهلحاظ تئوری امکان ساخت باتری کوانتوم وجود دارد که شارژ آن خالی نمیشود. این امر امتیازی برای این باتریهای کوانتوم جدید درمقابل باتریهای کوانتوم پیشین بهشمار میرود.
هانا خاطرنشان کرد:
باتریهایی که با آنها آشنایی بیشتری داریم، ازجمله باتریهای لیتیومیون که منبع تأمین انرژی گوشیهای هوشمند هستند، براساس اصول الکتروشیمیایی کلاسیک کار میکنند؛ درحالیکه باتریهای کوانتوم صرفا به مکانیک کوانتوم متکی هستند.
وی افزود این باتریهای کوانتومی ممکن است به عنصر مهمی در بسیاری از دستگاههای کوانتومی تبدیل شوند؛ مثلا ممکن است بتوانند انرژی کامپیوترهای کوانتومی را تأمین کنند یا با استفاده از فناوریهای حالت جامد فعلی ساخته شوند.
برای راستیآزمایی این ایده، گروه تحقیقاتی مدل شبکهی کوانتومی باز با تقارن ساختاری فراوان را بهعنوان بستری برای ذخیرهی انرژی اکسیتون در نظر گرفتند. انرژیای که در الکترون هنگام دریافت فوتونهایی از نور ذخیره میشود که بهاندازهی کافی انرژی دارند، انرژی اکسیتون نامیده میشود. این مطالعه نشان داد با وجود قرارگیری در محیط، امکان ذخیرهی انرژی بدون ازدسترفتن آن وجود دارد. هانا دراینزمینه اینچنین توضیح میدهد:
نکته اصلی اینجا است که باید این شبکهی کوانتومی را مطابق با شرایطی بسازیم که به آن حالت تاریک گفته میشود. در حالت تاریک» شبکه نمیتواند با محیط تبادل انرژی کند. به زبان سادهتر، در چنین حالتی سیستم درمقابل تمام اثرهای محیطی مصونیت پیدا میکند.
این بدانمعنا است که باتری انرژی خود را از دست نمیدهد و توانایی بسیار زیادی در حفظ انرژی خود پیدا میکند. همچنین، محققان با استفاده از این مدل، روش کلی برای تخلیهی انرژی ذخیرهشده در این باتریها را مطرح میکنند که میتوان درصورت نیاز از آن بهره برد. این روش شامل شکستن تقارن ساختاری شبکه بهشکلی کنترلشده است.
تحقیقات آینده روشهای مناسبی برای شارژ و تخلیهی باتری را ارائه خواهد کرد. همچنین، انتظار میرود دانشمندان راههایی برای تولید باتریهایی بیابند که در طرحهای کاربردی استفادهشدنی هستند. این تحقیق، با عنوان باتریهای کوانتومی که شارژ خود را از دست نمیدهند» در مجلهی Physical Chemistry C منتشر شده است.
ساندار پیچای در مصاحبهای با MIT، درباره برتری کوانتومی گوگل توضیح داد
IBM برتری کوانتومی گوگل را غیرواقعی میداند
آیا با افزایش گاز کربندیاکسید، گیاهان با سرعت بیشتری رشد میکنند؟
تم تیره iOS 13 تأثیر شگفتانگیزی بر بهبود عملکرد باتری آیفون میگذارد
هوش بشر: آیا انسان به مرزهای نهایی دانش رسیده است؟
منبع PHYS
درباره این سایت