جستجو در تالارهای گفتگو
در حال نمایش نتایج برای برچسب های 'مزایا'.
2 نتیجه پیدا شد
-
هر آنچه که باید در مورد تفاوت‌‌‌های ناگفتهٔ سی‌پلاس‌پلاس و راست بدانیم
کامبیز اسدزاده نوشته وبلاگ را ارسال کرد در ابزار‌ها
توضیحاتی که در این پست ارائه میکنم، به منظور این نیست که بگم چیزی بد هست یا چیزی خوب! یکی بهتر است و دیگری بدتر! اما دوست دارم بیشتر با جو تبلیغاتی غالب روی چیزی نظر ندیم و در برنامه‌نویسی هم شخصاً تمایل دارم به بالاترین سطح ممکن از آزادی عمل در یک ابزار برسم که همه چیز رو برای یک برنامه‌نویس فراهم می‌کنه. مثالی که قبلاً زده بودم همون بحث باغ‌وحش و حیاط وحش بهترین مثال ممکن هست که می‌تونستم بزنم ولی خب اهل تفکر باید باشی تا بفهمی چی گفتم. بذار یه چیزهایی در مورد Rust و C و ++C بهتون بگم تا دیگه نیازی برای ادامهٔ بحث‌های پیش پا افتاده نباشه (این بحث‌ها مسخرست و صرفاً وقت شما رو می‌گیره، اما آگاهی داشتن در موردش می‌تونه دیدگاه بهتری برای پیشروی بهتون بده) اما موضوعاتی که بهش اشاره میکنم رو اگه کمی عمیق‌تر بهش دقت کنی، خواهی دید که چرا چیزی مثل سی‌پلاس‌پلاس واقعاً بی‌رقیبه. قبل از هر چیز بهتره مروری از به وجود اومدن این زبان‌ها رو داشته باشیم: وقتی در دههٔ ۷۰ میلادی زبان C به وجود اومد، به عنوان یک ابزار به شدت قابل تحسین با ۱۰۰٪ آزادگی عمل معرفی شد، شما هر سیستم و هر ساختاری رو که می‌خواستی می‌تونستی باهاش بسازی! به هر حال کامپیوتر یک جهان جدیدی بود و هر چیزی در اون می‌تونست یک فرصت باشه؛ همین الآن بعد از گذشت ۵۲ سال خیلی‌ها فکر می‌کنن این زبان منسوخ شده! در حالی که طبق آخرین مستندات N3096 استاندارد C23 در ۲ آوریل ۲۰۲۳ به صورت پیش‌نمایش منتشر شده و هنوز هم در حال توسعه و پیشرفته! یادتونه گفتم هیچ ابزار و فناوری‌ای تا زمانی که در حال توسعه باشه، غلطه که بهش بگیم منسوخ شد! تقریباً ۳۹ سال پیش، وقتی سی‌پلاس‌پلاس به وجود اومد کاملاً ویژگی‌های C رو به ارث برد، در واقع هر چیزی که C داره، هم مشکلات و هم مزایا در ++C هم وجود داره اما خیلی فراتر از مباحثی که فکرش رو می‌کردند به یک باره توسعه‌پذیر شد. خیلی خب باید بپذیریم مشکلاتی که C داشته را هم در بعضی جاها ++C خواهد داشت، اما نه به صورت یک مانع! چون برای همشون راهکار وجود داره، هیچ چیز بی دلیل ساخته نمیشه، این رو مطمئن باش به‌روز رسانی‌ها بی دلیل نیستند. در مورد Rust، که ۸ سال پیش وقتی به وجود اومد که حتی به ۱۰ سال هم عمر و پختگیش نمیرسه صرفاً تمرکزش به ادامهٔ مسیر‌های مشابه زبان‌های مدیریت شده بود اما در حوزه‌ها و منظور‌های متنوع‌تر که این موضوع جذابش می‌کنه. راست یک زبان سیستمی هست اما با دارا بودن خاصیت Ownership که به همراه یک سری قوانین مثل Transfer Rules و Borrowing خیال شما رو از بحث ایمنی راحت می‌کنه. همین موضوع مسیر Rust رو با C و ++C جدا می‌کنه و قابل قیاس نیستند که در ادامه می‌گم چرا. موضوع مدیریت خودکار حافظه این بحث برتری حساب نمیشه چون توی سی++ مدرن ما راهکار‌های مشخصی برای مدیریت این مسائل داریم. خب یعنی چی یه ابزار داشته باشیم که بیاد امکان برنامه‌نویسی سیستمی رو بده اما مطمئن؟! قطعاً یه جای کار داره می‌لنگه! عین اینه که بگی من اینترنت دارم ولی فیلترینگ شدیدی روش هست، بله نمی‌ذاره من آزادانه و اونطور که می‌خوام پیش برم، هرجا ریسکی بود به عهدهٔ خودمه هرجا خیری بود باز به نفع خودمه. زور و فشار هیچ‌وقت موجب پیشرفت عمیق نمیشه حتی در فناوری! چون شما اختیار عمل ندارید و محبورید با محدودیت‌هایی که اعمال می‌شه پیشروی کنید. ساختار مهمی که راست داره بحث موضوع Ownership یا همون مالکیت هست، این یعنی چی؟ یعنی مالک خودش شیء‌ای هست که مسئولیت مدیریت حافظهٔ اختصاص داده شده به یک شیء رو به عهده می‌گیره. در کنار این موضوع قانون انتقال یا همون Transfer می‌گه که هر شیء‌ای فقط یک مالک داره و مالکیت اون‌ها تنها می‌تونه به یک شیء دیگر منتقل بشه! این یک قانون اصلی و مهم در راست هست که برای تضمین این موضوع قانون امانت یا همون Borrowing می‌گه که اگه می‌خوای از یک شیء به عنوان مالک نهایی استفاده کنی، می‌تونی مالکیت به شکل امانت رو به شیء دیگری انتقال بدی که در حالت قرضی یا موقتی ممکن هست اما اجازه نداری هرطور که دلت خواست ازش استفاده کنی. خب این قانون محدودیت‌های شدیدی رو ایجاد می‌کنه، اما در عوض بله تضمین می‌کنه که مدیریت حافظه مطمئن هست. این باعث می‌شه خطاهای حافظه به خاطر وجود مالکیت اختصاصی، که در زمان کامپایل، کامپایلر تعیین می‌کنه که چه زمانی باید حافظه آزاد بشه رو جلوگیری می‌کنه. شما نمی‌تونید به صورت آزاد روی مدیریت حافظه حرفی برای گفتن داشته باشید چون شما آزادی عمل ندارید. در مقابل در سی‌پلاس‌پلاس بدون هیچ محدودیتی از این موضوع بهره می‌برید. دسترسی به لایه‌های سخت‌افزاری عمیق و پشتیبانی از abiهای سیستم‌عامل‌ها به صورت کامل تحت راست ممکن نیست مگر اینکه به صورت اختصاصی نسبت به هر abi در اختیار شما خارج از استاندارد‌ها قرار بگیره، چیزی که در سی‌پلاس‌پلاس همه چیز به صورت استاندارد در اختیار توسعه‌دهنده قرار می‌گیره. کتابخانه‌های استاندارد Rust قابلیت کنترل مستقیم روی ترد (نخ)ها رو ارائه نمی‌کنه هرچند مدعی هستن که از روش‌های crate در کامپایلر راست در زمان اجرا با استفاده از thread_priorityها قابل پیاده‌سازی هست اما با این حال، هیچ‌وقت در سطح فوریتی به اندازهٔ APIهای استاندارد ++C قابل استفاده نیست، حتی C هم در این حد و اندازه امکان مدیریت سخت‌افزار رو برای شما نمیده. در صورتی که در Rust لایهٔ امنیتی رو فعال هست (چیزی که به صورت پیش‌فرض در راست فعال هست) دیگه امکان دسترسی به لایه‌های سخت‌افزاری رو از دست خواهید داد. در حالی که سی++ این امکان رو به صورت کاملاً آزاد در اختیار شما قرار میده و شما با پذیرش خطر اون اگر تسلط خوبی داشته باشید می‌تونید به بهترین شکل ممکن دسترسی نامحدود به این موضوع رو در اختیار بگیرید. شما در راست فقط حق انتخاب بر مبنای قوائد از پیش تعریف شده رو دارید، یا ایمن باش و محدود باش، یا ایمن نباش و باز هم محدود باش! این در سی++ برعکسه! شما یا باید کد ایمن بنویسی و در عین حال به بالاترین کارآیی دسترسی داشته باشی، یا باید به خاطر عدم داشتن تسلط بالا خطر‌هاش رو بپذیری که صد البته برای کاهش مسائل راهکار‌های استاندارد‌های جدید بهترین گزینست. تمام چیزی که راست ادعا کرده کلاً بر مبنای محدودیت‌های اعمال شده هست، برای مثال شما هیچ راه استاندارد و بومی شده‌ای برای دسترسی APIهای سیستمی به شیوهٔ مستقل از سکو رو ندارید مگر مواردی چون windows-rs و مشابهش که کاملاً خارج از بحث استاندارد و به نوع سوم در دسترس توسعه‌دهنده‌ها قرار می‌گیرند و مناسب چند-سکویی واقعی نیست. جامعهٔ پخته و اکو‌سیستم راست هیچ‌وقت به اندازهٔ زبان‌های C و ++C گسترده نیست و کتابخانه‌های استانداردِ بی‌شماری از این بابت در اختیار توسعه‌دهنده‌ها قرار نگرفته و این قابلیت مقایسه با عمق مستنداتی که طی چندین دهه برای زبان‌های دیگه موجود هست رو نداره. راست به معنای واقعی کلمه یک زبان ایمن هست اما با فعال بودن لایهٔ ایمنی، قدرتمند نیست و زیرساخت‌های سنگین که قدرت مانور کامل روی سخت‌افزار رو به شما بده. راست به هیچ عنوان بهینگی لازم رو به خاطر قوائد ایمنی در زمان اجرا (Run-Time) رو نداره در حالی که در ++C شما بهینگی به شدت بالایی رو برای زمان اجرا می‌تونید اعمال کنید. در راست که مدعیه یک زبان سطح‌پایین هست، ما مفهومی به عنوان Placement new نداریم، حتی معنا هم براش نداره چون دیگه محدودیت مالکیت (Onwership) با این موضوع هم خونی نداره و چنین ادعاهایی رو راحت رد می‌کنه. در سطوح پیشرفته، توسعه‌دهنده در ++C با استفاده از Placement new، می‌تونه یک شیء رو در یک مکان خاص از حافظه ایجاد کنه، بدون اینکه حافظه جدیدی بهش اختصاص بده! این امکان به شما اجازه میده که به طور دقیق مشخص کنید کجا باید یک شیء ایجاد بشه! چیزی که حتی در C هم به اندازهٔ ++C در مورد کنترل، سازگاری و انعطاف‌پذیری در مدیریت حافظه رو به ارائه نمی‌کنه. و اما در مورد بحث مسائل زمان اجرا و کامپایل، بله راست به دلیل ویژگی‌هایی که داره در زمان کامپایل مشکلات قابل بروز در زمان اجرا رو کنترل می‌کنه، در مقابل استاندارد‌های جدید از سی‌پلاس‌پلاس نیز ویژگی‌هایی مثل Contractsها و Conceptsها رو برای این منظور در نظر گرفته که اگه با استاندارد جدید آشنا نباشید طبیعتاً کد‌های شما در زمان اجرا ممکنه ایمن نباشه. خلاصهٔ کلام اینه که هر زبانی در جای خودش مزایا و معایب خودش رو داره که معمولاً برای تبلیغات و حمایت شدن توسط جامعه، طبیعیه که باید بعضی از مسائل رو نادیده بگیره و بعضی از مزایا رو بیشتر مطرح کنه. در مورد راست هم همینطور، در مورد سی‌پلاس‌پلاس هم همینطور! نا نمی‌تونیم بگیم همه چیز بده یا همه چیز خوبه! قطعاً در مقابل امنیت شک نکنید باید یک سری چیز‌ها رو در نظر بگیرید و در مورد آزادی توسعه توسط یک زبان هم همچنین. به‌روز رسانی‌های اخیر سی‌پلاس‌پلاس طوری پیش رفته که وقتی بخوای به عنوان یک زبان مدرن ازش استفاده کنی، اصولاً دیگه جای بحثی از نظر ترس و وحشت یا مشکلات حافظه یا چنین مسائلی باقی نمی‌مونه. این بر می‌گرده به توسعه‌دهنده که واقعاً از چه نسل و استانداردی تبعیت می‌کنه. -
مقدمه گاهی اوقات ارزش این را دارد که چند قدم به عقب برداریم و از دید یک تازه‌کار دنیای توسعه را نگاهی بی‌اندازیم. امروزه که استقبال زیادی از فریم‌ورک (framework) انگولار می‌شود، پرسش‌های زیادی در مورد انگولار در ذهن توسعه دهنده‌ها به وجود آمده پرسش‌هایی مانند: انگولار چیست؟ چرا باید انگولار را استفاده کنیم؟ چه موقع نباید از انگولار استفاده کنیم؟ در این مقاله من پاسخ این پرسش‌ها و مطالب بیشتری را می‌دهم. نگاهی خواهیم انداخت به این که انگولار چیست، چگونه راه‌اندازی شد و چه زمانی استفاده از انگولار ایده‌ی خوبی است. بگذارید از ابتدا شروع کنیم و ببینیم چگونه فریم‌ورک انگولار راه اندازی شد؟ انگولار چگونه راه‌اندازی شد؟ انگولار به عنوان یک پروژه‌ی جانبی شروع شد. در سال 2009، میسکو هِوِری (Miško Hevery) و آدام ابرونز (Adam Abrons) پروژه‌ای را تحت عنوان <angular/> منتشر کردند که به توسعه دهنده‌ها و طراحان کمک می‌کرد تا با استفاده از تگ (tag) های ساده HTML وب اپلیکیشن‌هایی (Web application) بسازند. نام "Angular" از براکت های زاویه‌دار یا <> می‌آید، که تمام تگ‌های HTML را احاطه می‌کنند. میسکو ایده‌ی پشت این فریم‌ورک را در مصاحبه‌ای که در سال 2013 انجام شد شرح داد: چون دامین angular.com گرفته شده بود - که هنوز هم گرفته شده - حامی‌ها نام کتابخانه را به GetAngular تغییر دادند و سایت کوچکی را قرار دادند که درباره‌ی امکانات فریم‌ورک صحبت می‌کرد. تصویر زیر وبسایت انگولار در سال 2009 را نشان می‌دهد: پس از مدت کوتایی میسکو شروع به کار برای گوگل کرد، و در 2010 در حال کار کردن روی پروژه ای به نام google feedback بود. میسکو برد گرین (Brad Green) مدیر خود را قانع کرد تا پروژه را با استفاده از پروژه جانبی انگولار او باز نویسی کند و مقدار زمان و کدی که تیم توانست ذخیره کند کمک کرد تا گوگل را برای قدرتی که انگولار ارائه می‌داد متقاعد کند. کمی بعد از موفقیت در بازنویسی Google Feedback، همان تیم کتابخانه را متن‌باز کردند و سرانجام نسخه 1.0 از انگولار در ماه می سال 2011 منتشر شد. طی چند سال آمار استفاده از انگولار صعود کرد، و امروز گوگل استفاده‌ی نیم میلیون توسعه دهنده از انگولار را به رخ می‌کشد. انگولار چه میکند؟ انگولار یک فریم‌ورک جاوا اسکریپت است که به توسعه دهنده‌ها در ساختن برنامه کمک میکند. این کتابخانه تعدادی امکانات را ارائه میکند که پیاده سازی نیازمندی‌های پیچیده‌ی برنامه‌های مدرن را بدیهی و آسان میکند. مانند پیوند داده (data binding)، مسیریابی (routing) و انیمیشن‌ها (animations). همچنین انگولار قرارداد‌هایی را برای چگونگی توسعه برنامه (application) فراهم میکند، که می‌تواند برای تیم‌های بزرگی که نیاز دارند با هم روی یک کد پایه کار کنند بسیار مفید باشد. انگولار تنها کتابخانه جاوا اسکریپت است که راهنمای استایل (style) جامع را با تعدادی دستورالعمل محتاطانه درباره چگونگی نوشتن کد با فریم‌ورک ارائه می‌دهد. چه زمانی باید انگولار را استفاده کرد؟ از دید تکنیکی شما می‌توانید هر چیزی با انگولار بسازید، اما انگولار در پروژه های پیچیده که شامل داده می‌شوند به بهترین شکل عمل میکند. اگر شما نگاهی به برنامه‌های متنوع ساخته شده توسط انگولار که در اینجا لیست شده بی‌اندازید، خواهید دید عموما برنامه‌هایی هستند که داده‌ها را از فرم (form) ها جمع‌آوری کرده و با آن کاری می‌کنند. این به این معنی نیست که شما باید برای استفاده از انگولار در پروژه‌ی خود فرم داشته باشید. توسعه دهنده‌ها تعداد تعجب برانگیزی از بازی با انگولار به خوبی چیزهایی مثل برنامه‌های واقعیت مجازی ساخته‌اند! با این حال اکثر آموزش‌هایی که خواهید یافت درباره‌ی برنامه‌هایی از نوع فرم‌دار خواهد بود. برای مثال مستندات انگولار آموزشی درباره‌ی ساخت برنامه‌ای است که شما با استفاده از فرم، قهرمان هایی را می‌سازید و آنها را در لیستی مشاهده می‌کنید. انگولار در برنامه‌های با پایه فرم خوب عمل میکند، همچنین برای برنامه‌های بزرگ و پیچیده بسیار مناسب است. همچنین انگولار نه آسان‌ترین فریم‌ورک جاوا اسکریپ است و نه کوچک‌ترین؛ بنابراین اگر در حال ساخت چیز کوچکی هستید کتابخانه‌های ساده‌تری مثل جی‌کوئری خواهید یافت که مناسب‌تر هستند. مشابهاً انگولار بسیار مناسب برنامه‌هایی است که توسط تیم‌های متوسط الی بزرگ ساخته شده‌اند. اگر شما خودتان در حال کار بر روی برنامه‌ای هستید، ممکن است قرارداد های انگولار را بیشتر از نیاز خود ببینید. انگولار همچنین برای برنامه‌هایی مناسب است که نیاز دارند در محیط‌های توسعه مختلفی اجرا شوند. اگر شما برنامه‌ای دارید که باید به خوبی یک برنامه‌ی ویندوزی یا مک اجرا شود، می‌توانید یکی از آموزش‌های آنلاین برای اجرای برنامه‌ی انگولار خود با پروژه معروف الکترون را دنبال کنید. اگر شما برنامه‌ای دارید که باید به خوبی برنامه اندروید و ios اجرا شود، می‌توانید با استفاده از NativeScript برنامه‌ی خود را در یک محیط بومی واقعی موبایل رندر (Render) کنید. در بعضی موارد حتی می‌توانید این کد را بین پلتفرم‌های مختلف به اشتراک بگذارید. چه کسی پشتیبان انگولار است؟ تیم هسته‌ی انگولار آرایه‌ای عظیم از افراد و جامعه‌ی (community) انگولار را شامل می‌شود که در دنیا گسترده شده‌اند. که می‌شود گفت بیشتر توسعه‌های روز به روز انگولار توسط کارمندان گوگل انجام شده است. صفحه درباره‌ی انگولار تقریباً 20 کارمند گوگل را در تیم هسته انگولار لیست کرده است و تمام برترین مشارکت کننده‌ها در پروژه انگولار در گوگل کار می‌کنند. که می‌شود گفت گوگل انگولار را کنترل میکند، خود کتابخانه هنوز تا مقدار زیادی تلاش جامعه است. بیشتر از 2000 فرد در یکی از مخزن‌های (repositories) متن‌باز انگولار مشارکت داشته‌اند. راهنما و آموزش‌های بی‌شمار نوشته شده توسط جامعه در دسترس هستند، و شرکت‌های مختلفی به توسعه دهنده‌ها برای قدرت بیشتر پیشنهاد آموزش و تجهیز شدن به انگولار را می‌دهند. چه نسخه ای از انگولار را استفاده کنم؟ در زمان نوشتن این مقاله دو نسخه مشهور انگولار موجود هستند. نسخه یک در وبسایت https://angularjs.org در دسترس است و نسخه ی آپدیت شده‌ی همان کتاب‌خانه‌ای است که میسکو و تیم در سال 2011 منتشر کردند. نسخه ی مشهور دیگر انگولار اکنون به سادگی "Angular"خوانده می‌شود و در وبسایت https://angular.io در دسترس است. انگولار مدرن کاملا شکل دوباره طراحی شده‌ی نسخه یک برای مرورگرها، جریان‌های کار و پلتفرم‌های توسعه جدیدتر است.
