منطق صحیح بهینه سازی در برنامه نویسی

[eshpilen]

بهینه سازی فرایند اجرای موثرتر برنامهء کاربردی شماست. شما میتوانید برای چیزهای زیادی بهینه سازی کنید - سرعت، مصرف حافظه، مصرف دیسک، غیره. اما ما در اینجا بر روی بهینه سازی سرعت معطوف هستیم.

-- چه وقت بهینه سازی کنیم؟

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

مادامیکه شما برنامه تان را توسعه میدهید، به داشتن اولویت های زیر نیاز دارید:

- همه چیز مستند شده باشد
- همه چیز همانطور که مستند شده است کار کند
- کد در یک شکل ماجولار و براحتی قابل تغییر نوشته شده باشد

مستندات اساسی هستند، بخصوص هنگام کار در گروهها. عملکرد مناسب برنامه اساسی است. شما متوجه خواهید شد که سرعت برنامهء کاربردی در هرجایی در آن لیست نیست. بهینه سازی در توسعهء اولیه به علتهای زیر لازم نیست:

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

بنابراین، وقت بهینه کردن در انتهای توسعه است، وقتیکه شما مطمئن شده اید که کد صحیح شما عملا مشکلات کارایی (performance) دارد.

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

----------------------------------

م: تنگه (bottleneck) به بخشهایی از برنامه یا هر سیستمی میگویند که حاصل تمام بخشهای دیگر یا بازدهی نهایی سیستم تحت تاثیر آنست (بنوعی مجبور به گذر از آن است، و غیره) و بنابراین محدودیت اصلی کارایی برنامه در این بخش از برنامه قرار دارد که در موارد مشکل باعث افت کلی بازدهی سیستم به زیر حد مورد نیاز یا حد قابل تحمل میشود، باوجود اینکه در بخشهای دیگر برنامه/سیستم چنین محدودیتی وجود نداشته باشد یا حتی ظرفیت بالاتر از حد نیاز وجود داشته باشد.

======================

منبع:

Programming from the Ground Up
Jonathan Bartlett
Edited by
Dominick Bruno, Jr.
http://download.savannah.gnu.org/releases/pgubook/ProgrammingGroundUp-1-0-booksize.pdf

Chapter 12. Optimization

[eshpilen]

-- بزرگترین بهبود در پرفورمنس در میان تمام آنها وقتی است که یک سیستم از حالت عدم کارکرد به کارکرد میرود

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

گهگاه بخشهایی از یک برنامه وجود خواهند داشت که پرفورمنس اهمیت دارد، اما شما احتمالا قادر نخواهید بود پیشبینی کنید در کجا مسئلهء پرفورمنس رخ خواهد داد. اگر شما تلاش کنید پرفورمنس یک اپلیکیشن را در طول ساخت اولیه بهینه کنید شما پیچیدگی ای را اضافه خواهید کرد که به تحویل بموقع و کیفیت اپلیکیشن ضربه خواهد زد و احتمالا هیچ کمکی به پرفورمنس نخواهد کرد؛ درواقع، آن میتواند عملا پرفورمنس را کاهش دهد (الگوریتم های سریعتر معمولا فاکتورهای ثابت بزرگتری دارند که به معنای آنست که آنها در مقیاس کوچک کندتر هستند و فقط در مقیاس بزرگ کاراتر میشوند). من دریافته ام که در بیشتر شرایط ساده ترین کد همچنین سریعترین کد نیز هست. بنابراین، دربارهء پرفورمنس تا زمانیکه برنامه درحال اجرا نباشد نگران نباشید؛ اگر آن بقدر کافی سریع نبود، سپس بدقت ارزیابی کرده و دریابید تنگه های پرفورمنس (performance bottlenecks) در کجا قرار دارند (محتملا آنها در جاهایی هستند که شما حدس نمیزدید). تنها آن مکانهایی را تنظیم کنید که شما ارزیابی کرده اید مشکلی وجود دارد.

==========================

منبع: http://www.stanford.edu/~ouster/cgi-bin/sayings.php (http://www.stanford.edu/%7Eouster/cgi-bin/sayings.php)

[eshpilen]

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

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

طراحی ساختاری یک سیستم بصورت غالبی پرفورمنس آنرا تحت تاثیر قرار میدهد. انتخاب الگوریتم بیشتر از هر مورد دیگری از طراحی پرفورمنس را تحت تاثیر قرار میدهد و چون انتخاب الگوریتم اغلب اولین چیزی است که باید درموردش تصمیم گرفته شود، استدلال ها بر علیه «بهینه سازی زودهنگام» به سختی قابل توجیه هستند.
بهینه سازی ممکن است شامل یافتن یک تنگه (bottleneck) باشد؛ بخشی از کد که مصرف کنندهء اصلی منابع مورد نیاز است. اغلب قاعدهء Pareto اعمال میشود: 20 درصد از کد مسئول 80 درصد از نتایج است.

در علم رایانه، قاعدهء Pareto میتواند با مشاهدهء اینکه 80 درصد از منابع معمولا توسط 20 درصد از عملیات استفاده میشوند، اعمال شود. در مهندسی نرم افزار، اینکه 90 درصد از زمان اجرای یک برنامه صرف اجرای 10 درصد از کد میشود (شناخته شده بعنوان قانون 90/10) اغلب تخمین بهتری است.

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

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

چه وقت بهینه کنیم؟

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

Donald Knuth دو عبارت زیر را درمورد بهینه سازی بیان کرد:

1) ما باید افزایش کارایی های جزیی را فراموش کنیم، در 97 درصد اوقات: بهینه سازی زودهنگام ریشهء تمام چیزهای بد است.
2) در قواعد جا افتادهء مهندسی یک بهبود 12 درصدی که به سادگی بدست بیاید، هرگز ناچیز شمرده نمیشود و من باور دارم که دیدگاه یکسانی باید در مهندسی نرم افزار حاکم باشد.

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

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

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

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

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

--------------------

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

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

-------------------

نقل قولها:

گناهان کامپیوتری بیشتر بنام کارایی انجام میشوند (بدون آنکه لزوما به آن دست یابند) تا هر علت دیگری - منجمله حماقت کورکورانه. W.A. Wulf

ما باید کارایی های جزیی را فراموش کنیم، 97 درصد اوقات: بهینه سازی زودهنگام ریشهء تمام بدیهاست. اما ما نباید از فرصتهای خود در آن 3 درصد بحرانی صرفنظر کنیم. یک برنامه نویس خوب بوسیله چنان استدلالی دچار از خود راضی بودن نخواهد شد، او برای با دقت نگاه کردن به کد بحرانی عاقل خواهد بود؛ اما فقط پس از آنکه آن کد شناسایی شده است. Donald Knuth

تنگه ها در نقاط غافلگیرکننده ای رخ میدهند، پس تلاش نکنید آنها را پیشبینی کرده و یک هک سرعت در آنجا بگذارید، تا وقتی که ثابت کرده باشید آنجا جایی است که تنگه وجود دارد. Rob Pike

نخستین قاعدهء بهینه سازی برنامه: آنرا انجام ندهید. دومین قاعدهء بهینه سازی برنامه (فقط برای متخصصان): هنوز آنرا انجام ندهید. Michael A. Jackson

===============================================

منبع: http://en.wikipedia.org/wiki/Program_optimization

[eshpilen]

پیرو بحثهایی که در تاپیک بهترین راه برای پیاده سازی سایت های چند زبانه (http://barnamenevis.org/showthread.php?432765-%D8%A8%D9%87%D8%AA%D8%B1%DB%8C%D9%86-%D8%B1%D8%A7%D9%87-%D8%A8%D8%B1%D8%A7%DB%8C-%D9%BE%DB%8C%D8%A7%D8%AF%D9%87-%D8%B3%D8%A7%D8%B2%DB%8C-%D8%B3%D8%A7%DB%8C%D8%AA-%D9%87%D8%A7%DB%8C-%DA%86%D9%86%D8%AF-%D8%B2%D8%A8%D8%A7%D9%86%D9%87) داشتیم، میخوام چند مثال از بهینه سازیهایی که سرش اختلاف هست رو براتون بذارم.

یک مثال که خود همون ذخیره سازی ترجمه های سایتهای چند زبانه در آرایه بود که سرش بقدر کافی بحث کردیم.

یک مثال دیگر هم اینه:

من مثلا برنامه که مینویسم این یه مثال از چیزی که توی فایل کانفیگ خودم دارم:


$password_reset_period=24*60*60; //in seconds

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

خب این درسته که به این شکل یک بهینه سازی البته خیلی جزیی انجام میدیم، ولی آیا درسته؟ آیا صرف میکنه؟ آیا به پارامترهای دیگر صدمه نمیزنه؟
بنظر منکه روش خودم عاقلانه تره هزارتا!
چون برنامهء من عملا نیازی به چنین بهینه سازیهای جزیی نداره و تا وقتی در دنیای واقعی داره بدون مشکل کار میکنه، یعنی مشکلی هم نداره! واسه من 1 صدم ثانیه زودتر اجرا شدنش مهم نیست و اصلا متوجهش هم نمیشم.

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

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

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

[eshpilen]

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

انگار هیچکس مثل من مفهوم این گفته ها رو واقعا متوجه نمیشه؛ درحالیکه اینها متون روشن و واضحی هستن و بعید میدونم گویندگان اونا همینطور از روی حدس و تصورات و بدون تجربهء عملی و دلایل و شواهد روشن و محکم این حرفا رو زده باشن. اینا که دیگه حرف من نیست!
مقالهء ویکیپدیا بذاری، هر منبع دیگری بذاری، پاش Thanks میزنن، اما در عمل بعدا میبینی طور دیگری حرف میزنن و عمل میکنن انگار که هیچی ازش نفهمیدن!
با همونا بحث میکنی میگن ویکیپدیا اعتبار نداره!!
حالا ویکیپدیا به کنار، این نقل قولها از افراد شناخته شده و منابع دیگر پس چی؟

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

من واقعا حوصله خوندن منتهای شما رو ندارم. اگر واقعا راست میگی چند تا دلیل کوتاه معقول بیار ( اما نه از نظر خودت معقول ) در پاسخ باید بگم، عزیزم اگر شما آمادگیش رو بقدر کافی داشتی که با چندتا جملهء کوتاه منظور من و دلایلش رو به درستی متوجه بشی و مسئله برات حل بشه، تاحالا خودت باید متوجه شدی بودی؛ بطور مثال با خوندن همین گفته ها در این تاپیک یا اصلا در اینترنت. چطور من اینها رو دیدم، خوندم، فهمیدم، قانع شدم، اما شما تازه داری میگی اصلا چیزی ندیدی و نمیدونی از چی صحبت میکنم؟
من کلی توضیح میدم براتون چون با این اشاره ها و گفتارهای کوتاه ظاهرا تاحالا متوجه نشدید یا اصلا شاید واسه همینا هم وقت و حوصله ای نداشتید که جایی بخونید!
مشکل امثال شما همینه که فکر میکنید خیلی باهوش هستید و همه چیز رو بدون مطالعه و تئوری و صرفا بصورت تجربی میتونید به این راحتی یاد بگیرید و به درستی انجام بدید.
بقول یارو میگفت ایرانیها اینقدر باهوش هستن که مثلا یه وسیلهء الکترونیکی که میخرن، دفترچه راهنماش رو میندازن کنار و همون اول میرن سراغ انگولک کردن و استفاده کردن ازش و فکر میکنن که به اون شکل میشه بقدر کافی ازش سردرآورد و دیگه هیچ نیازی به مطالعهء دفترچه راهنما نیست.
البته من شخصا اینطوری نیستم! و همهء ایرانیها هم اینطور نیستن.
البته من نمیگم در تمام موارد باید تمامی دفترچه راهنمای هرچیزی رو همون اول و کامل بخونیم، اما در خیلی موارد لازمه یا حداقل مفیده که تا حدی هم که شده این روش اصولی رعایت بشه.

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

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

اونی که این مسائل رو سرسری میگیره، محکومه که اشتباهات دیگران رو مدام تکرار کنه، و بخش بزرگی از وقت و انرژی خودش در سالهای مفید عمرش رو صرف چیزهایی بکنه که اونقدری که باید بازدهی واقعی ندارن؛ یعنی میشد بجاش کارهای خیلی مفیدتری انجام داد.
و متاسفانه ها اکثریت، یا خیلی ها، اینطور هستند.
تنها معدودی انسان نخبه و روشن در جهان وجود داره در هر زمینه. یعنی نسبت به بقیه معدود هستن (وگرنه شاید صدها و هزاران و بیشتر آدم نخبه و روشن هست در هر زمینه ای).

[eshpilen]

بارها در منابع مختلف خوندیم و شنیدیم که میگن هدف از این زبان، فلان کتابخانه، فلان چیز، اینه که برنامه نویس بجای اینکه تمرکز و وقت و انرژی خودش رو روی مسائل و جزییات فنی و سطح پایین صرف کنه صرفا (هرچند در عمل صرفا مطلق نمیشه و اغلب باید گفت «بیشتر») روی منطق و کارکردهای اصلی برنامهء خودش تمرکز کنه.

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

آیا این دو گفته و هدف، حداقل مقداری با هم مغایر نیستند؟

زبانهای سطح بالا برای این هدف ساخته شدن، و در این بین میزان زیادی پرفورمنس رو هم قربانی کردن، بخاطر اینکه ارزشش رو داشته!
اینکه شما امروز در بیشتر موارد از این زبانها استفاده میکنید (ترجیح میدید)، خودش دلیل صحت این هدف و موفقیت اونهاست.

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

تمام بحث هم بر سر همینه. بر سر اینکه مشکلی وجود نداره تا زمانیکه واقعا/درعمل وجود داشته باشه.
بحث بر سر کافی بودن یا نبودن است.
بحث بر سر اینه که فقط پرفورمنس نیست که وجود و ارزش داره.
بحث بر سر این نیست که بهینه سازیهای درشت یا خیلی راحت رو انجام ندیم.
بحث بر سر بهینه سازیهای جزیی است که در عمل نیاز بهشون (کافی نبودن) ثابت نشده و خیلی راحت هم حل نمیشن و هزینه دارن و ممکنه به پارامترهای دیگر برنامه و برنامه نویسی صدمه وارد کنن.

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

[eshpilen]

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

من اسکریپت های متعددی رو که مشکل داشتن رو بهینه کردم. ولی باور کنید هیچ وقت به اینکه به جای
$password_reset_period=24*60*60; //in seconds
مقدار محاسبه شدش رو قرار بدم نرسیدم. بیشتر قسمتها سر سوتی های فاجعه امیز برنامه نویس قبلی و یا عدم استفاده از کش بوده.

[eshpilen]

حالا یه مورد خیلی مخوف تر اخیرا در پروژم داشتم.
اولا که دیگه چیزهایی مثل 24*60*60 یکی دوتا نیست و چندین و چندتاست:

$autologin_ages=array(

0,
5*60,
20*60,
60*60,
8*60*60,
24*60*60,
3*24*60*60,
7*24*60*60,
30*24*60*60,
3*30*24*60*60,
365*24*60*60,

);

$admin_autologin_ages=array(

0,
5*60,
20*60,
60*60,
8*60*60,
24*60*60,
3*24*60*60,
7*24*60*60,
30*24*60*60,
3*30*24*60*60,
365*24*60*60,

);

دوما تازه این مقدارها بعد از محاسبه، با تابعی به متن هایی مثل «5 دقیقه»، «1 سال» و این حرفا تبدیل میشه و بصورت یک منو در فرم لاگین درج میشه.
اگر میخواستم روی بهینه سازی وسواس باشم، باید میامدم اون تبدیل رو هم خودم انجام میدادم و نتیجه رو hard code میکردم که دیگه در هر درخواست نیازی نباشه تمام این محاسبات و تبدیلات انجام بشن.

واقعا بد دردی هست «وسواس در بهینه سازی» که خیلی افراد دارن. چون اینطوری بجای اینکه بدن کامپیوتر براشون جون بکنه خودشون برای آسایش کامپیوتر بیل میزنن و جون میکنن!

ما کامپیوترها را ساختیم تا بجای ما عملگی کنند، نه اینکه ما برای آنها عملگی کنیم!!

آدم نباید هدف کلی رو درمیان اهداف جزیی و راهها و کارهایی که زیرمجموعهء اون هدف کلی هستند گم و فراموش بکنه!
ممکنه آدم خیلی باهوش باشه خیلی نابغه باشه برنامه نویس خوبی باشه، ولی فلسفه و خرد کلی و جامعی نداشته باشه برای زندگی و تعیین استراتژی های کلی. اینطور میشه که افراد گرفتار افراط و تفریط و بیماریهایی مثل وسواس در بهینه سازی میشن!
ما باید توجه داشته باشیم که یک هدف اصلی از اختراع و بکارگیری رایانه ها همین بوده که کارهای تکراری و حجیم و سخت رو گردن اونا بندازیم و خودمون رو راحتتر و آزادتر برای کارهای خلاق تر و مفیدتر بکنیم یا حتی بجاش بریم تفریح کنیم، بیشتر به خودمون و خانوادمون برسیم!!
موقع برنامه نویسی هم همین قاعده برقراره.
فقط موقعی بهینه سازی های هزینه دار (هزینه منظور از راحتی و سرعت برنامه نویس هم هست) کنید که در عمل/واقعا مجبور هستید یا این کار سود بقدر کافی بزرگ و توجیه شده ای داره که بر هزینه هاش میچربه.

حالا ممکنه یکی علاقهء زیادی به خود کامپیوتر و برنامه نویسی و این حرفا داشته باشه خب قضیش مقداری فرق میکنه. واسه اون فرد حل کردن مسائل از راههای جدید و بهبود دادن چیزها هرچند بصورت جزیی شاید خودش تفریح و وقت گذرانی خوبی باشه. خب ما نمیگیم این تفریح رو نکنید و کار مفیدی نیست برای این افراد و جامعه. من خودم هم اتفاقا یک خورهء علم و عاشق و شیفتهء کامپیوتر و برنامه نویسی و اینترنت هستم، و بخاطر همین بخش اعظم عمر و برنامهء زندگیم رو روی همین چیزها صرف کردم و میکنم و احتمالا همچنان خواهم کرد، ولی به خدا اینقدر مسائل متنوع و گسترده و جذاب و در ضمن کاربردی تر و مفیدتر از نظر عملی و قدرتی که به آدم میدن هست که نمیدونم چرا آدم باید اینقدر گیر یک بحث محدود و گستردهء کوچک و نسبتا اشباع شده ای مثل بهینه سازی باشه و همهء این همه یادگیری و حیطه ها و مسائل و پارامترهای دیگر رو رها کنه یا به بحث بهینه سازی اولویت و وقت و انرژی زیادی رو اختصاص بده.
اینقدر چیزهای جذاب و پیشرفته و کاربردی و قدرتهای ناب در علم و فناوری هست که بحث بهینه سازی بینشون فقط کسر کوچکی از این دریای عظیم است.
گیر دادن روی بحث بهینه سازی های بخصوص جزیی، بدرد اونایی میخوره که اوتیسم فکری دارن :لبخند:
چون از این بابت «در خود مانده» هستن و در مسیر زندگی به یک چیز خاص برای مدتها گیر دادن و کار تکراری و نسبتا بیهوده یا کم بازدهی رو مدام انجام میدن.

[eshpilen]

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

بخاطر همین توصیه میشه برنامه نویسان از حدس و تصور و اصولا فکر کردن زیاد و انگولک کردن برنامه هاشون بابت بهینه سازی های غیرضروری (بخصوص بهینه سازیهای جزیی) خودداری کنن، مگر اینکه اطلاعات کافی و موثق و اطمینان داشته باشن از تمام فرایند و نتیجهء اون و واقعا هم در عمل بقدر کافی لازم یا حداقل مفید باشه این کار.

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

زبان سطح بالا انتظار داره شما طرز تفکر و عمل سطح بالا هم داشته باشید و تفکر و عمل سطح پایین و بهینه سازیهای جزیی رو به عهدهء زبان گذاشته باشید. اصلا این مستقیما برگرفته از علت وجودیش نیست مگه؟!

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

[eshpilen]

«برنامه نویسان مقادیر هنگفتی از وقت را صرف فکر کردن دربارهء، یا نگرانی دربارهء، سرعت بخشهای غیربحرانی از برنامه هایشان میکنند، و این تلاشها برای کارایی عملا یک تاثیر منفی قوی بر روی دیباگ و قابلیت نگهداری کد دارند. ما باید بهینه سازیهای جزیی را فراموش کنیم، در 97% اوقات: بهینه سازی زودهنگام ریشهء تمام پلیدی هاست. اما ما نباید از فرصتهای خود در آن 3% بحرانی بگذریم.»

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

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

منبع: http://c2.com/cgi/wiki?PrematureOptimization

توضیح مترجم درمورد اصطلاح فاکتورگیری: «فاکتورگیری مجدد کد (Code refactoring) یک تکنیک نظام یافته برای ساختاربندی مجدد یکسری کدهای موجود است که ساختار داخلی آنرا تغییر میدهد بدون آنکه رفتار خارجی آنرا تغییر دهد. این کار برای بهبود ویژگیهای غیرعملیاتی نرم افزار انجام میشود. فواید آن شامل بهبود خوانایی کد و کاهش پیچیدگی برای بهبود قابلیت نگهداری کد منبع، و همچنین یک ساختار داخلی گویاتر یا مدل شیء گرایی مناسب تر برای افزایش توسعه پذیری میباشد.»

منبع: http://en.wikipedia.org/wiki/Code_refactoring

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

«عبارت های مطلق ریشهء تمام پلیدی ها هستند. اگر شما پیشاپیش بیش از حد بهینه سازی کنید، ممکن است وقت را روی چیزی که غیرضروری بوده است هدر دهید. اگر پیشاپیش بهینه سازی نکنید، ممکن است بعدا وقت را برای سازماندهی مجدد مقدار زیادی کد هدر دهید یا ممکن است مشتری در سکوت رنج بکشد (بخاطر اینکه وقتی تولید محصول به پایان رسیده است اغلب برای شکایت کردن خیلی دیر است).
قاعدهء یکسانی به طراحی نیز قابل اعمال است. اگر شما پیشاپیش بیش از حد سیستمی را طراحی کنید، ممکن است وقت را برای طراحی کردن حالتهایی که هیچوقت استفاده نخواهند شد هدر دهید. اگر شما پیشاپیش هیچ طراحی ای انجام ندهید، ممکن است بعدا وقت را برای سازماندهی مجدد هدر دهید.
کلید، تعادل است. پاسخ های کلی وجود ندارند، فقط پرسشها وجود دارند.»

منبع: http://c2.com/cgi/wiki?PrematureOptimization

«هرکسی میخواهد کدش با حداکثر سرعت ممکن اجرا شود. یک وسوسهء همیشگی آن است که در هنگام کدنویسی بهینه سازی کنیم، با نوشتن چیزها در یک سطح پایین تر از چیزی که شما واقعا باید کار کنید (بطور مثال دسترسی مستقیم به داخل آرایه ها، استفاده از یک ارجاع به متغییر حاوی یک نمونه از یک شیء در یک متد قابل override شدن بجای استفاده از متد getter، و غیره)، یا اضافه کردن مقدار زیادی از میانبرهای اجرا برای حالتهای خاص.
این تقریبا هیچوقت درست کار نمیکنید.
انسانها، حتی برنامه نویسان باتجربه، در پیشبینی (حدس زدن) اینکه در کجا یک پردازش دچار مشکل خواهد شد بسیار ضعیف هستند.
بنابراین:
کد را بر اساس محدودیت هایی بجز پرفورمنس (روشنی، انعطاف، مختصر بودن) بنویسید. سپس، پس از آنکه کد واقعا نوشته شده است:
- ببینید آیا شما واقعا به بالا بردن سرعت آن احتیاج دارید.
- کد را برای آنکه ببینید آن درواقع وقت خود را در کجا صرف میکند پروفایل کنید.
- بر روی بهینه سازی چند نقطهء معدودی که بازدهی بالایی خواهند داشت تمرکز کنید و بقیه را بحال خود رها کنید.»

منبع: http://c2.com/cgi/wiki?ProfileBeforeOptimizing

[metal gear solid 4]

ببخشید خارج از تاپیکه.


گیر دادن روی بحث بهینه سازی های بخصوص جزیی، بدرد اونایی میخوره که اوتیسم فکری دارن :لبخند:
چون از این بابت «در خود مانده» هستن و در مسیر زندگی به یک چیز خاص برای مدتها گیر دادن و کار تکراری و نسبتا بیهوده یا کم بازدهی رو مدام انجام میدن.

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

[eshpilen]

چه ربطی داره؟!
انیشتین شغل و تخصصش فیزیک نظری بوده. درش هم خوب کار کرده و نتایج عملی خوبی ارائه داده و به هدف این رشته و خودش رسیده.
شما هم شغل و تخصصتون اگر برنامه نویسی باشه، بحث بهینه سازی فقط جزء کوچکی از اونه، و فقط هم وقتی توجیه میشه که به هدف و نتیجهء نهایی که نوشتن برنامه های خوب برای انجام نیازهای واقعی است، برسه.
وقتی شما وقت و انرژی زیادی رو روی بهینه سازیهای جزیی، صرفا بر اساس حدس و تصور یا عقیده و سلیقهء شخصی کورکورانه، صرف میکنید، در راستای این هدف بصورت بهینه عمل نمیکنید. چون اون بهینه سازیهای جزیی در عمل در بیشتر موارد ضرورت ندارن و به پارامترهای دیگر مهم در برنامه ها، مثل خوانایی، سادگی، کوتاهی و قابلیت نگهداری هم صدمه میزنه، و در نهایت هم شما بعنوان یک برنامه نویس برنامه های کمتری رو میتونید بنویسید (چون وقت و انرژی رو که محدوده صرف گیر دادن روی اجزاء کردید و نه کل و هدف کلی و نهایی). حتی برنامه هایی رو هم که نوشتید ممکنه باوجودی که خواستید خیلی خوب بنویسید و کاملا از نظر پرفورمنس بهینه باشن، اما بخاطر اینکه این بهینه سازیها به پارامترهای دیگری که گفتم صدمه زدن باعث شده که باگهای بیشتری در برنامه هاتون بوجود بیان، یا حداقل اینکه قابلیت نگهداری و توسعه و انعطاف اونا در آینده کم شده، بنابراین نمیشه گفت واقعا برنامه های بهتری نوشتید و در آینده و در مدت عمرشون بیشتر برای خودتون یا دیگران مفید خواهند بود.
کسانی که روی یک جنبهء محدود اینقدر وسواس دارن و افراط میکنن، و جنبه های دیگر رو رعایت نمیکنن، در نتیجه به هدف نوشتن برنامه های بیشتر نمیرسن، و حتی خیلی وقتا به هدف نوشتن برنامه های بهتر هم نمیرسن. اصولا هم حتی اگر باگی در این فرایند و وسواس تولید نشه و به پارامترهای دیگر هم صدمهء زیادی نخوره، افزایش پرفورمنس باید در عمل مشهود و موثر باشه تا بتونیم بگیم برنامهء بهتری نوشته شده نسبت به برنامه های مشابه دیگر.

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

ضمنا آدم روی هرچیزی افراط و گیر کنه معمولا مشکل پیش میاره.
حتی برنامه نویسی هم همهء زندگی و نیازهای آدم نیست.
مثلا من خیلی وقته متوجه شدم باید ورزش کنم و قدرت جسمانی و حتی توانایی رزم و زد و خورد هم داشته باشم؛ بخاطر همین هم ورزشکار شدم و باشگاه رزمی هم رفتم!
کلا وقت و انرژی و فرصتها و منابع مادی آدم محدود و خیلی ارزشمنده. باید بصورت بهینه ازش استفاده کرد. من سعی میکنم مهمترین و کلی ترین موارد رو شناسایی کنم و منابعم رو بین اونها بصورت بهینه ای تقسیم کنم. روی چیزهای جزیی کلید نمیکنم! هدفهای کلی و نهایی مهمه. هدفهای بزرگ و مهم در زندگی و در هرچیزی.
این مهم نیست که برنامهء شما با سرعت 10 برابر برنامهء من اجرا بشه، بلکه این مهمه که مال من هم با سرعت کافی اجرا میشه (زحمت پردازش بیشترش رو هم رایانه بجای من و شما تقبل میکنه تا ما راحت تر باشیم و به کارهای مهمتر و سودمندتری برسیم) و من تونستم روش وقت و انرژی کمتری صرف کنم و بجاش مثلا کد و برنامه های بیشتری بنویسم، یا حتی اینکه بیشتر ورزش کنم و به سلامتی و قدرت خودم اضافه کنم، یا حداقل روی پارامترهای دیگر مهم در برنامه بیشتر مایه گذاشته باشم و مثلا برنامم از نظر امنیت یا دقت و کمال الگوریتم ها، امکاناتش، انعطافش و غیره بهتر باشه.

[eshpilen]

یک نگاهی هم بکنیم، آدمهایی که اینقدر روی اجزاء ریز کلید میکنن، معمولا دستاوردهای بقدر کافی زیاد و بزرگی ندارن که این همه صرف وقت و انرژی رو توجیه بکنه.
مثلا اینایی که اینقدر به بهینه سازی گیر میدن تاحالا چه کارهای برجسته و بزرگی کردن که اصلا نگیم برای دنیا، حداقل برای خودشون و دو نفر دیگه خیلی مفید بوده باشه؟
حتی کارهایی میشه مثل اینکه طرف بعد از سالها تلاش میره یک الگوریتم فشرده سازی جدید درست میکنه که ضریب فشرده سازی خوب یا حتی بیشتر از الگوریتم های فعلی داره. ولی میبینی در عمل به هیچ نتیجه ای نمیرسه و حتی چیز زیادی عاید خودش هم نمیشه.
یک دلیلش اینه که در این فیلدها قبلا بقدر کافی کار شده و بقدر کافی الگوریتم های متعدد و کارا وجود دارن. بنابراین کار شما گرچه بهتر باشه، اما دیگه ضروری و حیاتی یا خیلی مهم نیست و خیلی وقتا هزینه های دیگر مثل سویچ کردن و تطابق استانداردها و غیره اجازه نمیدن که در خیلی از کاربردها بیان و الگوریتم های استاندارد و جا افتادهء قبلی رو کنار بذارن و بجاش از الگوریتم شما استفاده کنن.
البته یک دلیل این کمتر شدن نیاز هم تغییر شرایط هست. یعنی مثلا رایانه ها بارها قدرتمندتر شدن، هارددیسک ها ظرفیت خیلی بیشتری پیدا کردن، سرعت اینترنت بیشتر شده، و غیره. یعنی یه زمانی در گذشته که مثلا حجم ذخیره سازی خیلی محدودیت داشت و گران قیمت و ارزشمند بود، اهمیت الگوریتم های فشرده سازی هم خیلی بیشتر بود (بطور کلی و عمومی، نه در موارد خاص).
یه زمانی الگوریتم فشرده سازی مینوشتن که 5% بیشتر فشرده سازی داشت، چیز مهمی بود. اما الان 5% در بیشتر کاربردها تقریبا هیچ اهمیتی نداره. حالا اگر تونستی حداقل مثلا 25% بهبود ایجاد کنی یه چیزی و شاید موفق بشی که تقاضا و بازدهی کافی ازش دربیاد برای خودت و بشریت.

آدم باید در هرچیزی به دنبال حداکثر بودن بازدهی باشه.
بهینه سازی هم وقتی که مجبور باشیم یا حداقل بازدهی عملی بزرگی داشته باشه، توجیه میشه، اما نه وقتی که اون همه وقت و انرژی گرانبها رو صرفش کنی و بازدهیش درحد کمی باشه (خیلی وقتا برای انسان حتی محسوس هم نیست).
آدم در زندگی باید دنبال چیزی بره که بازدهیش روی peak باشه.
اگر الان دوران peak یه چیزی گذشته، خب چیزهای دیگر که هست که روی peak باشن! پس چرا آدم دنبال اونا نره و وقت و انرژی ارزشمند خودش رو صرف اونا نکنه؟
هدف نهایی بازدهی کلی حداکثریه.

[eshpilen]

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

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

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

کامپیوتر عملهء ماست!
طوری فکر و عمل نکنید که انگار شما عمله هستید و کامپیوتر ارباب شما که باید راحتی و آسایشش رو تامین کنید.
تازه آدم هم که نیست، موجود زنده که نیست. نهایتش داغ میکنه و میسوزه (که اینم خیلی به ندرت پیش میاد) یا عمرش کم میشه، که نهایت اونقدری هم مهم نیست و ارزشش نداره تا بجاش شما از سلامتی و عمرتون مایه بذارید.

[alireza es]

یک نگاهی هم بکنیم، آدمهایی که اینقدر روی اجزاء ریز کلید میکنن، معمولا دستاوردهای بقدر کافی زیاد و بزرگی ندارن که این همه صرف وقت و انرژی رو توجیه بکنه.
مثلا اینایی که اینقدر به بهینه سازی گیر میدن تاحالا چه کارهای برجسته و بزرگی کردن که اصلا نگیم برای دنیا، حداقل برای خودشون و دو نفر دیگه خیلی مفید بوده باشه؟
حتی کارهایی میشه مثل اینکه طرف بعد از سالها تلاش میره یک الگوریتم فشرده سازی جدید درست میکنه که ضریب فشرده سازی خوب یا حتی بیشتر از الگوریتم های فعلی داره. ولی میبینی در عمل به هیچ نتیجه ای نمیرسه و حتی چیز زیادی عاید خودش هم نمیشه.
یک دلیلش اینه که در این فیلدها قبلا بقدر کافی کار شده و بقدر کافی الگوریتم های متعدد و کارا وجود دارن. بنابراین کار شما گرچه بهتر باشه، اما دیگه ضروری و حیاتی یا خیلی مهم نیست و خیلی وقتا هزینه های دیگر مثل سویچ کردن و تطابق استانداردها و غیره اجازه نمیدن که در خیلی از کاربردها بیان و الگوریتم های استاندارد و جا افتادهء قبلی رو کنار بذارن و بجاش از الگوریتم شما استفاده کنن.
البته یک دلیل این کمتر شدن نیاز هم تغییر شرایط هست. یعنی مثلا رایانه ها بارها قدرتمندتر شدن، هارددیسک ها ظرفیت خیلی بیشتری پیدا کردن، سرعت اینترنت بیشتر شده، و غیره. یعنی یه زمانی در گذشته که مثلا حجم ذخیره سازی خیلی محدودیت داشت و گران قیمت و ارزشمند بود، اهمیت الگوریتم های فشرده سازی هم خیلی بیشتر بود (بطور کلی و عمومی، نه در موارد خاص).
یه زمانی الگوریتم فشرده سازی مینوشتن که 5% بیشتر فشرده سازی داشت، چیز مهمی بود. اما الان 5% در بیشتر کاربردها تقریبا هیچ اهمیتی نداره. حالا اگر تونستی حداقل مثلا 25% بهبود ایجاد کنی یه چیزی و شاید موفق بشی که تقاضا و بازدهی کافی ازش دربیاد برای خودت و بشریت.

آدم باید در هرچیزی به دنبال حداکثر بودن بازدهی باشه.
بهینه سازی هم وقتی که مجبور باشیم یا حداقل بازدهی عملی بزرگی داشته باشه، توجیه میشه، اما نه وقتی که اون همه وقت و انرژی گرانبها رو صرفش کنی و بازدهیش درحد کمی باشه (خیلی وقتا برای انسان حتی محسوس هم نیست).
آدم در زندگی باید دنبال چیزی بره که بازدهیش روی peak باشه.
اگر الان دوران peak یه چیزی گذشته، خب چیزهای دیگر که هست که روی peak باشن! پس چرا آدم دنبال اونا نره و وقت و انرژی ارزشمند خودش رو صرف اونا نکنه؟
هدف نهایی بازدهی کلی حداکثریه.

پس شما میگین بریم سر زبان هایی مثل C#؟
c++ که من خودمو واسش میکشم به جز پرفومنس مزیت دیگه ای نسبت به C# داره؟

[metal gear solid 4]

من گفتم خارج از تاپیکه. صرفاً به معنی سطحی و ساده ای که از اوتیسم داشتید اشاره کردم. نیمی از افرادی که اوتیسمی هستند نابغه بودند و هستند در زمینه هایی که درش استعداد و یا تخصص دارند.
این زیاد با تفاسیر شما که تکرار و زمان گذاری روی مسائل جزئی و ... میگید جور در نمیاد. همین. :)

[eshpilen]

پس شما میگین بریم سر زبان هایی مثل C#‎؟
سی شارپ؟
شاید.
بستگی داره.
من از تبلیغ کردن سی شارپ خوشم نمیاد، چون مال میکروسافته و حداقل تاحدی انحصاری یا در برابر دنیای نرم افزار آزاد و بازمتن عمل میکنه.
اگر بگی پول ندارم میخوام نون دربیارم توی این مملکت، میگم خب پس احتمالا سی شارپ برات خوبه. چون اینجا دیگه مسئلهء مرگ و زندگیه نمیخوام بچه مردم بعدا نفرین کنه :چشمک:


C++‎ که من خودمو واسش میکشم به جز پرفومنس مزیت دیگه ای نسبت به C#‎ داره؟
خب خودت رو نکش. مگه مجبوری؟
برنامه رو باید با زبانی نوشت که برنامه نویسیش راحتتر و سریعتره و یکسری پارامترهای دیگر.
سرعت حداکثری فقط جایی باید معیار انتخاب باشه که واقعا لازمه.
الان ما مثلا با PHP اینقدر راحت سایت و برنامه های وب درست میکنیم، چرا بریم با سی++ کار کنیم؟ سرعتش مسلما میتونه بیشتر از PHP باشه، ولی سختی و زمان برنامه نویسی هم بیشتر میشه، و به اون سرعت حداکثری در بیشتر کاربردهای عادی نیازی نیست.

[eshpilen]

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

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

[abolfazl-z]

eshpilen جان میگم یکم واضح تر (ترجیحا کمتر) و با مثال برای بچه ها توضیح بدهید بهتر هست. خیلی از ما ها سنی کمی داریم.

راه های تشخیص اینکه برنامه ما چقدر بهینه سازی شده وجود داره ؟ (یک نرم افزار ، سایت و یا ... که رسمی باشه)

چند تا مثال از بهینه سازی می زنید ؟ (حالا به غیر از بالا)

[metal gear solid 4]

بله میدونم که بعضی نابغه بودن.
ولی به گمانم در زمینه های خیلی محدودی، و در ضمن چکار کردن از این نبوغ و استعداد چه خیر بزرگی به خودشون و/یا دیگران رسیده؟
آیا بیشتر اختراعات و اکتشافات علمی کار اوتیست ها بوده؟ درصدش بین اوتیست ها بالاتر بوده؟
بهرحال کسی دلش نمیخواد اوتیست باشه. چون درکل خوب نیست؛ گرچه در زمینهء خاصی آدم نابغه بشه. منتها یک آدم تک بعدی میشه! اصلا بخاطر همون که فقط روی یک نقطه میتونن راحت تمرکز کنن و به چیزهای دیگه توجه ندارن لابد میتونن نبوغ نشون بدن.
خوب که نیست؟ هست؟ حتی اگر نابغهء فلان چیز هم بشه آدم.
اگر تمام بشریت اوتیست بودن فکر میکنی الان دنیا چه شکلی بود؟
اوتیست درست نیست. اوتیسم. خیر تک بعدی نیستند. اتفاقاً درک بسیار کاملی از محیط دارند. حتی گاهاً بیشتر از سایرین اما توانایی برقراری ارتباط ندارند( درست مثل انیشتین که در ارتباط برقرار کردن خیلی خوب نبودن، هفته ها میرفتن آزمایشگاهشون و با هیچ کسی هم ارتباطی برقرار نمیکردن، اما همین تمرکز کارشون رو به شدت بالا میبرد). اصولاً این افراد از جمله افرادی هستند که از سمت چپ مغز هم به خوبی بهره میبرند و به همین دلیل ضریب هوشی بالایی هم دارند ( البته نیمی از این افراد که تونسته باشن استعدادهای خودشون رو کشف کنند ). و صد البته که اوتیسمی بودن اصلاً خوب نیست. هرگز. البته شاید علتش درک نکردن ما غیر اوتیسمی ها از دنیای اونا باشه.
اما این تعریف که یک انسان اوتیسمی تک بعدیه درست نیست.
--- بحث من کاملاً خارج از اصل مطلب این تاپیکه. دوستان دیگر ایراد نگیرید :)

[alireza es]

eshpilenیه سوال.تو خودت از چه زبانی استفاده میکنی؟چون چند تا تایپک در تالار کیوت زدی.
نظر من اینه که شما یکم از برنامه نویسی خسته شدین(شایدم نه ولی منم به همچین حالتی دچار شده بودم)
وقتی شما گفتین زبان برنامه نویسی باید راحت باشه یاد دلفی افتادم:ناراحت:در عرض 1 ساعت برناممو درست میکردم

اینکه من اومدم زبان فوق العاده راحت و شیرین سینتکس و البته قدرتمند مثل دلفی رو ول کردم دلیلش به خاطر این نبود که چون چند جا نوشته بود C++‎‎ پرفومنس بالایی داره منم جوگیر
ولش کردم.خدایی داشتم تو دلفی حرفه ای میشدم هنوز هم برخی کارا هارو که میتونستم تو دلفی انجام بدم نمیتونم تو C++‎‎ انجام بدم(دلم برای دلفی تنگ شده کجایی که منو ازت جدا کردند:گریه:)
چون یکم خواستم واقع بینانه نگاه کنم
با دلفی نمیشه برای لینوکس برنامه نوشت(خدا بکشتت embarcadero با اون برنامت)
با دلفی نمیشه کرنل مود و البته برای سخت افزار برنامه نوشت(شاید با پاسکال)
با دلفی نمیشه ......
-----------------------------------------------------
چیزی که هست اینه که الان بازار رقابت خیلی داغ شده واگه شما پرفومنس رو بالا نبرید رقیبتان این کارو میکنه.دلفی پرفومنس فوق العاده و شاید در حد C++‎‎ داره اما تو بعضی چیزا از C++‎‎ عقبه.

الان تصور کنید adobe photoshop رو با C#‎‎ بنویسن.یا بیان after efectرو با visualbasic.net بنویسن.چون راحته؟

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


الان ما مثلا با PHP اینقدر راحت سایت و برنامه های وب درست میکنیم، چرا بریم با سی++ کار کنیم؟ سرعتش مسلما میتونه بیشتر از PHP باشه، ولی سختی و زمان برنامه نویسی هم بیشتر میشه، و به اون سرعت حداکثری در بیشتر کاربردهای عادی نیازی نیست.
حالا اگه شرکتی که آمار بازدیدش داره سربه فلک میکشه بخواد هزینه هارو کم کنه باید چیکار کنه؟اونوقته که شما و c++ یا perl لازم میشی.

یه دلیل دیگه که این وسواسو به خرج میدم(البته تو بعضی برنامه ها) و برای برنامم thread ایجاد میکنم،الگوریتممو بهتر میکنم و ..... عشقه:قلب:
چون با این کارا هم تجربم تو برنامه نویسی زیاد میشه هم وقتی میبینم یه برنامه درستو حسابی از کار دراومده واقعا حال میکنم

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

(اگه یه کم ضریب هوشیم بالا بود و مغز درستو حسابی داشتم همزمان که دارم کیوت یاد میگیرم میرفتم دلفی هم یاد میگرفتم اما همین C++‎‎ رو به زور صلوات و نذری دارم یاد میگیرم:لبخند:)

[eshpilen]

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

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

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

[eshpilen]

eshpilenیه سوال.تو خودت از چه زبانی استفاده میکنی؟
من شغلم برنامه نویسی نیست و تاحالا زیاد برنامه ننوشتم، ولی برنامه نویسی و برنامه نویسان را دوست دارم :قهقهه:
چندتا زبان یاد گرفتم که بدونم همه جا چه خبره. در دنیای بازمتن، لینوکس.
بعدم اینکه بتونم تقریبا هرجایی هرکاری بکنم.
یک زبان کافی نیست.
آدم باید چند زبان بلد باشه.
حالا بعدا اگر نیازش پیش اومد هرکجا ممکنه از یک زبانی استفاده کنم. بستگی داره کدوم زبان برای اون برنامه و پلتفرم اجراش مناسب تر باشه.
وب میخوام بنویسیم با PHP.
یوقت روی وب شاید خواستم یه برنامهء high performance بنویسم، اونوقت میتونم با سی یا سی++ بنویسم.
یوقتا خواستم برنامه های تست و سردستی بنویسم هرچی دم دست تر و راحتتر و سریعتر بوده برای این هدف استفاده کردم؛ مثلا پایتون.
فرقی نمیکرد ممکن بود از cli در php استفاده کنم بجاش.
اصلا من محدودیت خاصی نمی بینم. زبانه دیگه. واسه من اینا همش مثل آچار و دریل و پیچ گوشتی و این چیزا میمونه که یجا دارم کار میکنم هرکدوم میشد کار رو باهاش انجام داد و دم دست افتاده بود برمیدارم استفاده میکنم. یوقت میبینی آچار فرانسه دم دسته، یوقت آچار معمولی، یوقت پیچ گوشتی، یوقت دیلم، یوقت دریل دستی، یه وقت دریل برقی.


نظر من اینه که شما یکم از برنامه نویسی خسته شدین(شایدم نه ولی منم به همچین حالتی دچار شده بودم)نخیر.


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


اینکه من اومدم زبان فوق العاده راحت و شیرین سینتکس و البته قدرتمند مثل دلفی رو ول کردم دلیلش به خاطر این نبود که چون چند جا نوشته بود C++‎‎‎‎‎ پرفومنس بالایی داره منم جوگیر
ولش کردم.خدایی داشتم تو دلفی حرفه ای میشدم هنوز هم برخی کارا هارو که میتونستم تو دلفی انجام بدم نمیتونم تو C++‎‎‎‎‎ انجام بدم(دلم برای دلفی تنگ شده کجایی که منو ازت جدا کردند:گریه:)
چون یکم خواستم واقع بینانه نگاه کنم
با دلفی نمیشه برای لینوکس برنامه نوشت(خدا بکشتت embarcadero با اون برنامت)
با دلفی نمیشه کرنل مود و البته برای سخت افزار برنامه نوشت(شاید با پاسکال)
با دلفی نمیشه ......اینکه رفتی یاد گرفتی مشکلی نداره، ولی دلیلی نداره واسه همه برنامه و همه جا از سی++ بخوای استفاده کنی. اگر برای یادگیری و تسلط این کار رو میکنی مشکلی نداره، ولی غیر از این ضرورتی نداره. مثلا من سی هم بلدم، آیا میرم برنامه های وب رو با سی بنویسم؟! باید این کار رو بکنم؟ بنده علاوه بر اینکه به سی تسلط خوبی دارم یه دوتا تست ساده زدم در ارتباط با برنامه نویسی وب با سی، و دیگه رهاش کردم، چون فقط میخواستم بدونم داستانش چطوریه و آمادگی و پایهء حداقلی قبلیش رو داشته باشم.


چیزی که هست اینه که الان بازار رقابت خیلی داغ شده واگه شما پرفومنس رو بالا نبرید رقیبتان این کارو میکنه.دلفی پرفومنس فوق العاده و شاید در حد C++‎‎‎‎‎ داره اما تو بعضی چیزا از C++‎‎‎‎‎ عقبه.
شعار الکی نده افسانه سرهم نکن.
الان سرعت تنها در کاربردهایی که سرعت به علتی توشون اهمیت بیشتره داره میتونه تعیین کننده باشه.
سرعت دوتا نرم افزار هردو اگر در حد «کافی» باشه، اونی که از نظرهای دیگه برتری داره انتخاب میشه (مثلا امکانات، انعطاف، دقت، پشتیبانی). بطور معمول نمیان فقط بخاطر اینکه یکی سرعتش بیشتر از دیگری هست اون رو ترجیح بدن، مگر اینکه اختلاف سرعت واقعا فاحش باشه و توی کارشون ضروری باشه یا حداقل منافع زیادی داشته باشه.


الان تصور کنید adobe photoshop رو با C#‎‎‎‎‎ بنویسن.یا بیان after efectرو با visualbasic.net بنویسن.چون راحته؟شاید هم یه زمانی نوشتن. همچین بعید بعید هم نیست.
سرعت سی شارپ به مرور بالاتر میره. اینکه سرعتش برای این کاربردها بقدر کافی بالا بره غیرممکن هم نیست از نظر علمی و فنی.
اما در اینکه فعلا اینطور نیست (و شاید هیچوقت هم نشه)، و بعضی برنامه ها رو نمیشه با سی شارپ نوشت، جدلی نیست. ولی خب که چی؟ حالا نتیجه؟ اینکه پس شما نیازی نیست سی شارپ یاد بگیرید و باهاش کار کنید؟ اینکه برید همیشه همه جا هر جور برنامه ای رو با سی++ بنویسید؟
من میگم چند زبان بلد باشید و هرجا هرکدام که درکل بازدهی بالاتری داره استفاده کنید. بازدهی هم فقط شامل پرفورمنس برنامه نمیشه، بلکه وقت و انرژی برنامه نویس و خیلی مسائل دیگر رو هم شامل میشه.

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


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


حالا اگه شرکتی که آمار بازدیدش داره سربه فلک میکشه بخواد هزینه هارو کم کنه باید چیکار کنه؟اونوقته که شما و C++‎‎‎ یا perl لازم میشی.من هرچی بخوام میتونم بنویسم با هر زبانی. شک نکن :لبخند:
ضمنا کی گفته پرل سرعتش خیلی بالاست؟
پرل هم یک زبان اسکریپتی است.


یه دلیل دیگه که این وسواسو به خرج میدم(البته تو بعضی برنامه ها) و برای برنامم thread ایجاد میکنم،الگوریتممو بهتر میکنم و ..... عشقه:قلب:
چون با این کارا هم تجربم تو برنامه نویسی زیاد میشه هم وقتی میبینم یه برنامه درستو حسابی از کار دراومده واقعا حال میکنمهمیشه گفتم یادگیری و تمرین خوبه و اشکال نداره، ولی درحد عاقلانه.
بجز پرفورمنس خیلی مسائل و دانش و توانایی های دیگر هم در برنامه نویسی هست.
مثلا برای برنامه های وب و شبکه ای و کاربردهای خاص دیگری، بحث امنیت و رمزنگاری اهمیت زیادی داره.
همینطور شما فتوشاپ و اتوکد و خیلی ساده تر و کوچکتر از اونا رو هم نمیتونید فقط با دانش و مهارت در زبان سی++ و پرفورمنس/بهینه سازی درست کنید؛ باید خیلی سواد و مهارت در زمینه های دیگر هم داشته باشید. باید بتونی مثلا رفرنسهای کاملا تخصصی و خشک و بدون مثالهای کامل و روشن در زمینه هایی مثل استانداردها، الگوریتم ها، فرمتها، کدک ها و غیره رو بخونی و بفهمی؛ واسه این به سواد پایه ای و قدرت تئوریک بالایی نیاز هست که کمتر کسی داره. حتی ریاضیات هم خیلی جاهاش ممکنه نیاز بشه. ریاضیاتی که فراتر از نیاز به ریاضیات در برنامه های معمولیه. همون چند قدم اول رو که بردارید متوجه میشید به چه دریایی از دانش و توانایی نیاز داره که بحث زبان و پرفورمنس توش فقط یک جزء کوچک میشه. خیلی چیزها هست که به ذهنتون نمیرسه اما در واقعیت و عمل نیاز هستن. فقط هم با این کد زدن ها و آزمون و خطا و کار عملی نمیشه به خیلی از این موارد مسلط شد؛ چی دارم میگم! حتی نمیتونید چیز خاصی از خیلی موارد بفهمید، چه برسه به اینکه مسلط بشید!!


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

[eshpilen]

من خودم یجا کار میکنم بعد از ظهر ها، چندتا نرم افزار داره واسه کارش، اکثرشون دات نت هستن.
با اینکه نرم افزارهاش یه مقدار قابل توجهی کند هستن و حتی از نظر کیفیت هم باگ و اذیت دارن ولی استفاده میکنن.
خب پس چرا نرم افزار سی++ نبوده که جای این نرم افزارها رو بگیره؟
یا نبوده ننوشتن، یا اینقدر خوب نبوده از نظر امکانات و مسائل دیگر، یا شناخته شده نبوده و تبلیغات خوبی نداشته، یا گران بوده و غیره. بهرحال چیزی که هست اینکه الان این نرم افزارهای دات نت جای نرم افزارهای سی++ و دلفی رو گرفتن. و این نشون میده که فقط پرفورمنس و سرعت بهتر داشتن، باعث انتخاب شدن نمیشه. خیلی پارامترها و مسائل هست. حتی اینکه شرکت و پشتیبانیش چطور باشه، اینکه رابطه و پارتی و نفوذ داشته باشی و غیره. بعد خب شما وقتی نرم افزارت کدش ساده تر و عمومی تر باشه (افراد بیشتری باشن که بتونن از پسش بربیان)، خب برای بقا و کمتر شدن هزینه های شرکت و پشتیبانی و تغییرات هم بهتره خب. نه؟ پس میبینی که قضایا در واقعیت گسترده تر و پیچیده تر از این حرفا هستن که فکر کنیم فقط بخاطر اینکه یک نرم افزار سرعتش بیشتره پس در بازار موفق میشه.

[alireza es]

من شغلم برنامه نویسی نیست و تاحالا زیاد برنامه ننوشتم، ولی برنامه نویسی و برنامه نویسان را دوست دارم :قهقهه:
:لبخند:

یوقت روی وب شاید خواستم یه برنامهء high performance بنویسم، اونوقت میتونم با سی یا سی++ بنویسم.
یوقتا خواستم برنامه های تست و سردستی بنویسم هرچی دم دست تر و راحتتر و سریعتر بوده برای این هدف استفاده کردم؛ مثلا پایتون.
فرقی نمیکرد ممکن بود از cli در php استفاده کنم بجاش.

اینکه رفتی یاد گرفتی مشکلی نداره، ولی دلیلی نداره واسه همه برنامه و همه جا از سی++ بخوای استفاده کنی. اگر برای یادگیری و تسلط این کار رو میکنی مشکلی نداره، ولی غیر از این ضرورتی نداره. مثلا من سی هم بلدم، آیا میرم برنامه های وب رو با سی بنویسم؟! باید این کار رو بکنم؟ بنده علاوه بر اینکه به سی تسلط خوبی دارم یه دوتا تست ساده زدم در ارتباط با برنامه نویسی وب با سی، و دیگه رهاش کردم، چون فقط میخواستم بدونم داستانش چطوریه و آمادگی و پایهء حداقلی قبلیش رو داشته باشم.
این دقیقا مخالف با اصول منه.شما میگین عادم باید چند بعدی باشه ولی تعریفتون از چند بعدی بودن اینه که زبون های بسیاری بلد باشه.
اما به نظر من چند بعدی بودن یعنی گاهی شی گرا بنویسیم گاهی ساخت یافته
گاهی سطح بالا بنویسیم گاهی سطح پایین
گاهی از صد تا فریم ورک و library و کامپوننت و .... استفاده کنیم گاهی همشه چیزشو از اول بنویسیم.
البته نه اینکه سکه بندازیم ببینیم باید چطور بنویسیم بلکه بنا به نیازمون.شما رفتین پایتون یاد گرفتین؟به نظر من رفتین وقتتونو هدر دادین چون تقریبا مثل php عمل میکنه و خیلی سطح بالاست
بعدش رفتین C یاد گرفتین؟همون کاری که میتونید با php بکنید رو هم میتونید با C انجام بدین؟پس بازم هیچی یاد نگرفتین البته منم مثل شما بودم تو این سه سالی که روی برنامه نویسی فعالیت میکنم
زبون های java ,C#,delphi(:گریه:),C,perl,python,Qt,php کار کردم ولی تو هرکدوم تا حدی حرفه ای شدم اما حالا میفهمم کارم اشتباه بوده و اگه از اول توی یه زبان تمرکز میکردم و به ابعاد و منطق های مختلف اون پرداخته بودم بهتر بود
البته تا حدی هم درست میفرمایید متاسفانه تو کشور های ما شرکت ها به دنبال برنامه نویس یه زبون خاص میگردن آخه یکی نیست به تو چه من با چه زبونی کار میکنم

شعار الکی نده افسانه سرهم نکن.
الان سرعت تنها در کاربردهایی که سرعت به علتی توشون اهمیت بیشتره داره میتونه تعیین کننده باشه.
سرعت دوتا نرم افزار هردو اگر در حد «کافی» باشه، اونی که از نظرهای دیگه برتری داره انتخاب میشه (مثلا امکانات، انعطاف، دقت، پشتیبانی). بطور معمول نمیان فقط بخاطر اینکه یکی سرعتش بیشتر از دیگری هست اون رو ترجیح بدن، مگر اینکه اختلاف سرعت واقعا فاحش باشه و توی کارشون ضروری باشه یا حداقل منافع زیادی داشته باشه.
وقتی ویندوز ویستا اومد مردم هنوز هم از ویندوز XP استفاده میکردن.چرا؟؟چون اگه شما تو خونتون رم و پردازنده بالایی دارین دلیل بر این نیست که من هم دارم.و این سطح فکری سطح فکریه شرکت هایی مثل گوگل هست چرا؟چون گول کروم 31 هنوز روی ویندوز 98 اجرا میشن.شاید در نظر شما امکان اضافه ای باشه انا الان تو مدرسه ما من دارم ویندوز 95 تجربه میکنم و یک حالی میده!!!شما میگین سرعت نرم افزار باید در حد معقولی باشه و نباید زیاد باشه.خوب رسوندن به این حد معقول خیلی سخته پایین تر میگم منظورم چیه

شاید هم یه زمانی نوشتن. همچین بعید بعید هم نیست.
سرعت سی شارپ به مرور بالاتر میره. اینکه سرعتش برای این کاربردها بقدر کافی بالا بره غیرممکن هم نیست از نظر علمی و فنی.
:قهقهه: من نمیدونم شما از فتوشاپ چه استفاده هایی میکنید.اما استفاده هایی از فتوشاپ وجود داره که با وجود یک رم 8 گیگ خیلی کند پیش میره
افتر افکت رو که اصلا ول که در فیلم های هالیوودی از بهترین کامپیوتر ها استفاده میشه و 2 الی 3 روز طول میکشه
نرم افزار هایی مثل آنتی ویروس ها(در سطح شرکتی و بیزینسی) و شبیه ساز ها و .... رو اگه با C# بنویسن میشه هزینه ای که برای گرفتن یک سخت افزار خوب نیاز هست 10 برابر یک برنامه نویسه

همیشه گفتم یادگیری و تمرین خوبه و اشکال نداره، ولی درحد عاقلانه.
بجز پرفورمنس خیلی مسائل و دانش و توانایی های دیگر هم در برنامه نویسی هست.
بالاخره حرف دل منو زدین.اما در کنار اون کلمه پرفمنس باید راحتی رو هم اضافه کنیم.طوری که شما از سختی c++ میگین طرف فکر میکنه باید 0 و 1 بزنه !
برخی از افراد از همین سختی c++ خوششون میاد از این کنترلی که رو برنامشون دارن از این همه چیزش دستشونه و نمیخوان این قدرت و این آزادی و حتی این پرفومنس رو به خاطر راحتی C# بفروشن
الان qml سرعت تولید نرم افزار خیلی زیادی حتی گاهی در سطح C# و دلفی داره

-----------------------------------------------------------------------------------------
و در آخر دلیل اینکه نرم افزار های دات نت جای دلفی رو گرفتن 100% راحتی نیست چون مطمئننا راحتی دلفی بیشتر از C# است.شک نکن الان هم شما گفتی آدم باید چند بعدی باشه منو تجریک کردی دارم rad studio رو دانلود میکنم(خدا ازت نگذره:لبخند:)تا بازم دلفی رو از اول شروع کنم

[eshpilen]

:لبخند:
تعریفتون از چند بعدی بودن اینه که زبون های بسیاری بلد باشه.
البته تاکید بر لزوم چند زبان بلد بودن بیشتر مختص هکرها/خوره هاست.
اینم فقط حرف من نیست و در این جوامع خیلی معروفه و رواج داره.
قبلا یک مقاله ای درمورد اینکه هکرها چه خصوصیاتی دارن و چطور میشه یک هکر واقعی شد رو خونده بودم. طرف تمام خصوصیات هکرها رو سعی کرده بود جمع آوری کنه بر اساس شواهد و نمونه ها و استدلالها. یکیش هم همین بود که خیلی هم مهم بود اینکه یک هکر نمیتونه فقط یک زبان بلد باشه!
و اما منظور از هکر هم افراد علاقمند/خوره و خیلی فنی و ماهر (فراتر از نیاز و انتظارهای کاری عادی) در زمینهء رایانه و برنامه نویسی هستن که خیلی هاشون بصورت انفرادی کار میکنن یا میتونن انفرادی هم کار کنن. بخاطر همین این افراد باید مجموعهء وسیعتری از دانش و توانایی رو داشته باشن نسبت به افرادی که مثلا فقط برای شغل و درآمد دنبال این مباحث میرن و میتونن مثل در یک تیم برنامه نویسی نقش مشخص خودشون رو داشته باشن.
اگر شما هکر باشید و بخواید مسئله ای رو حل کنید و کاری رو انجام بدید، خودتون باید بتونید نهایت با کمی کمک و راهنمایی از جانب دیگران از پسش بربیاید.


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


البته نه اینکه سکه بندازیم ببینیم باید چطور بنویسیم بلکه بنا به نیازمون.شما رفتین پایتون یاد گرفتین؟به نظر من رفتین وقتتونو هدر دادین چون تقریبا مثل php عمل میکنه و خیلی سطح بالاستدلیل اینکه رفتم پایتون یاد گرفتم این بود که اون زمان عدهء زیادی از بروبچ پایتون کار و طرفداران پایتون بدجور تبلیغش رو میکردن، میگفتن یه زبان جدید برگرفته از تجربیات و خصوصیات مثبت بقیهء زبانهاست و آخر تکامل زبانهای برنامه نویسی و از همشون بهتر و این حرفا. و ادعا میکردن که باهاش تقریبا همه جور برنامه ای هم میشه نوشت. خلاصه این حرفا زیاد بود و منم یک مقدار مطالعه و تحقیق کردم دیدم نه برای اینکه واقعا کامل و دقیق و مطمئن بتونم بفهمم جریان چیه باید خود زبان رو کامل بررسی کنم ببینم داستانش چیه و چی داره و واقعا در چه حدی است. خلاصه این شد که رفتم رفرنس و تشکیلاتش رو خوندم، و البته فهمیدم که طرفدارانش بیش از حد شلوغ و اغراق میکنن! حداقل این چیزی بود که برای خود من اینطور بود. یعنی دیدم خیلی معجزه ای هم نیست و نمیشه گفت واقعا در همه جا و واسه همه کار از زبانهای دیگر بهتره یا حتی زبان واقعا مناسبی است. البته زبان واقعا خوب و جالبی بود که ویژگیهای جدیدی داشت در نظر بنده، ولی دیگه در اون حد که سروصدا و ادعا میکردن مثل یه موجود فضایی و خیلی برتر از انسانها نبود!
آره داداش خلاصه اینطوری بود که ما پایتون یاد گرفتیم :چشمک:
یعنی دیدم اگر ته و توش رو درنیارم و ازش سردرنیارم، یه عمری میخوام توی این شک و تردید بمونم و توی دلم با حرفهای مبلغان پایتون خالی بشه و احساس ضعف و عدم اعتمادبنفس کنم در این زمینه.
میدونی فرق یه خوره با آدمهای دیگه همینه که خوره نمیتونه براحتی بی تفاوت بمونه در برابر اینطور چیزها و اهمیتی نده. خوره میخواد همه چیز رو بدونه و بتونه!
البته خب بخاطر بازار کار احتمالیش هم بود. چون طرفها طوری تبلیغ و ادعاهایی میکردن که آدم خیال میکرد الان چند سال دیگه بازار کار و لزوم بلد بودن پایتون با سرعت خیره کننده ای در دنیا رشد میکنه.


بعدش رفتین C یاد گرفتین؟همون کاری که میتونید با php بکنید رو هم میتونید با C انجام بدین؟پس بازم هیچی یاد نگرفتینخیر سی رو که توی دانشگاه تدریس میکردن. من از اون موقع از سی خوشم اومد بعنوان دومین زبان برنامه نویسی ای که دیدم (قبلیش بیسیک بود روی کمودور 64).
خلاصه اول سی رو خوب یاد گرفتم و باهاش خوب ور رفتم. تسلط خوبی توش بدست آوردم.
بنظر خودم بعدها این احاطه به سی باعث شد که زبانهای دیگر و خیلی مسائل فنی کامپیوتر رو راحتتر و سریعتر یاد بگیرم و بتونم درک کنم. سی یه زبان پایه ایه. مفاهیم و سطح پایین بودن و سختیش باعث میشن که آدم پایهء خوبی برای رفتن به سطوح بالاتر پیدا کنه.
باید سی رو بلد باشی تا بتونی بگی واقعا از تمام آنچه در دنیای رایانه و برنامه نویسی میگذره و تاریخش، یک درک و دید کلی داری.


البته منم مثل شما بودم تو این سه سالی که روی برنامه نویسی فعالیت میکنم زبون های java ,C#‎‎‎‎‎‎‎,delphi(:گریه:),C,perl ,python,Qt,php کار کردم ولی تو هرکدوم تا حدی حرفه ای شدم اما حالا میفهمم کارم اشتباه بوده و اگه از اول توی یه زبان تمرکز میکردم و به ابعاد و منطق های مختلف اون پرداخته بودم بهتر بودفکر نکنم شما دقیقا مثل من باشی.
تنها شباهت شما همینه که دنبال چند زبان مختلف رفتی.
بنده در سطح خیلی علمی تر و قویتر و گسترده تری از اینکه فقط چند زبان رو یاد بگیرم کار کردم.
توان علمی بنده بالاست.
کارهایی کردم که گاهی خودم هم خودم رو تحسین میکنم میبینم اونم چند سال پیش فلان کار رو کردم.
کارهایی که سواد و توانش رو هرکسی نداره.
مثلا یک RFC رو خوندم و بدون نمونه های مشابه و راهنمایی و کمک خاصی، تونستم بفهمم و از روش یه چیزی رو پیاده سازی کنم. واقعا فکر میکنی میتونی مشابه یک چنین کاری رو انجام بدی؟ افراد کمی هستن در این سطح که بتونن از پس چنین چیزهایی بربیان. اول باید زبان انگلیسیت برای خوندن متون فنی تقریبا بی نقص باشه، بعد باید با زبان و اصول این متون خشک و فوق تخصصی کاملا آشنا باشی، بتونی فقط از روی نوشته و توضیحات بفهمی دقیقا منظورش چیه و چرا و چطوری باید پیاده سازیش کنی، ... . خلاصه کار راحتی نیست. هر جوجه ای از پسش برنمیاد. حتی برنامه نویسان واقعا حرفه ای که سالها تجربه دارن هم نمیتونن فقط به همین خاطر از پس این کارها بربیان. باید سطح علمی داشته باشی.
شما دوتا زبان یاد گرفتی فقط. من انبوهی از متون و مقالات و کتابهای فوق تخصصی و حجیم و پیچیده رو خوندم. بطور مثال در زمینهء امنیت و رمزنگاری. تونستی فقط چند صفحه از اون کتابهایی رو که بنده خوندم خودت تنهایی با خوندن بفهمی، اونوقت میتونی خودت رو مقایسه کنی. کتابهایی خوندم که پر از ریاضیات بودن و چیزهایی که حتی در تمام دوران تحصیلم هم تا اون حد در ریاضیات حرفه ای کار نکرده بودن و به گمانم بعضی مواردش اصلا تازه بود و در دوره های درسی چیز زیادی راجع بهش نبود. منم با اینکه زیاد آدم اهل ریاضیات نبودم و برام راحت نبود اما سعی کردم و زور خودم رو زدم و هرچی میتونستم همه رو خوندم و تاجاییکه تونستم فهمیدم. گاهی روی یک صفحه یا حتی چند خط توضیح و ریاضی ممکنه چند ساعت گیر کنی چند ده بار بخونیش، و حتی چند روز! هرکسی این حوصله و اراده رو نداره. مردم اکثرا میخوان زودی فقط کد زدن و برنامه درست کردن رو یاد بگیرن میگن اینا به ما چه مربوط و به چه دردی میخورن!
خب خوره اندر خوره همینه دیگه!! طرف راضی نمیشه که چیزی رو ندونه و جایی گیر کنه و از پس چیزی برنیاد.
شما پروتکل HTTP رو خوندی بلدی؟
من قبلا به یکی معرفیش کردم بعنوان مرجع. چند بار طرف سوال کرد منم اون رو بهش معرفی کردم و لینکش رو بهش دادم. دست آخر فهمیدم که ظاهرا طرف اصلا نفهمیده ماجرا چیه اینقدر RFC ای که بهش معرفی کردم براش ناآشنا و غیرقابل درک و باور بوده که متوجه نشده اصلا چه ربطی داره و چیه!!
آخه نگاه کنی میبینی یک فایل txt خیلی طولانیه که انگار کتاب داستان یا یکسری مشخصه های فنی و متون عجیب و رمزآلود توش هست. طرف باورش نمیشه که تمام این پروتکل HTTP که اساس وب هست تقریبا همه چیزش توی همون اومده و از روی همون درست شده.
بله دوست عزیز، همه چیز زبان برنامه نویسی و کدزنی نیست!
و فکر میکنی چرا اینطوریه؟
چرا آدم با آدم اینقدر فرق میکنه؟
چرا بعضیا چیزی رو میبینن اصلا نمیفهمن قضیه چیه و اون چیز چقدر و چرا و کجاها اهمیت داره، ولی یکی مثل من بر اساس همونا کار میکنه و پروتکل implement میکنه؟
افراد و برنامه نویسان معدودی هستن که بتونن وارد این مسائل بشن.
قصدم تعریف از خودم و خودنمایی و ادعا نیست، ولی میخوام برای همگان روشن بشه که رایانه و برنامه نویسی خیلی فراتر از این حرفهاست و چیزهای زیاد و اساسی ای وجود دارن که بیشتر افراد عادی حتی ازشون اطلاعی ندارن و قدرت درک ماهیت و اهمیت اونا رو هم ندارن. یک برنامه نویس هم فقط بخاطر اینکه برنامه نویسی میکنه و موفق هم هست، دلیل نمیشه جزو این افراد معمولی نباشه.


وقتی ویندوز ویستا اومد مردم هنوز هم از ویندوز XP استفاده میکردن.چرا؟؟چون اگه شما تو خونتون رم و پردازنده بالایی دارین دلیل بر این نیست که من هم دارم.و این سطح فکری سطح فکریه شرکت هایی مثل گوگل هست چرا؟چون گول کروم 31 هنوز روی ویندوز 98 اجرا میشن.شاید در نظر شما امکان اضافه ای باشه انا الان تو مدرسه ما من دارم ویندوز 95 تجربه میکنم و یک حالی میده!!!شما میگین سرعت نرم افزار باید در حد معقولی باشه و نباید زیاد باشه.خوب رسوندن به این حد معقول خیلی سخته پایین تر میگم منظورم چیه

:قهقهه: من نمیدونم شما از فتوشاپ چه استفاده هایی میکنید.اما استفاده هایی از فتوشاپ وجود داره که با وجود یک رم 8 گیگ خیلی کند پیش میره
افتر افکت رو که اصلا ول که در فیلم های هالیوودی از بهترین کامپیوتر ها استفاده میشه و 2 الی 3 روز طول میکشه
نرم افزار هایی مثل آنتی ویروس ها(در سطح شرکتی و بیزینسی) و شبیه ساز ها و .... رو اگه با C#‎‎‎‎‎‎‎ بنویسن میشه هزینه ای که برای گرفتن یک سخت افزار خوب نیاز هست 10 برابر یک برنامه نویسهزیاد ربطی نداشت.
همه اینا که گفتی موارد خاص بودن که بنده درمورد اونا صحبت نکردم.
ضمنا همش هم باز مواردی که فقط برنامه نویسان معدودی در اون سطح از دانش و توانایی برای درک و انجام واقعیشون هستن. اینا چیزهایی نیست که به شما جیغیلی ها ربط خاصی پیدا کنه :لبخند:
دوتا برنامهء کلیشه ای و تجاری عادی نوشتن که این حرفا رو نداره.
نه نیاز هست روی ویندوز 95 و 98 اجرا بشه نه پردازشهای عظیم و سنگین خاصی محسوب میشه.



شبیه ساز ها و .... رو اگه با C#‎‎‎‎‎‎‎ بنویسن میشه هزینه ای که برای گرفتن یک سخت افزار خوب نیاز هست 10 برابر یک برنامه نویسهجدا شک دارم :متفکر:
فکر کردی شبیه ساز رو هر آدمی میتونه بنویسه و اونایی که میتونن چقدر کار و زمان میبره و چقدر دستمزد داره؟
تازه اگر یک نفری بشه و تیم نخواد.


بالاخره حرف دل منو زدین.اما در کنار اون کلمه پرفمنس باید راحتی رو هم اضافه کنیم.طوری که شما از سختی C++‎‎‎‎‎‎‎ میگین طرف فکر میکنه باید 0 و 1 بزنه !
برخی از افراد از همین سختی C++‎‎‎‎‎‎‎ خوششون میاد از این کنترلی که رو برنامشون دارن از این همه چیزش دستشونه و نمیخوان این قدرت و این آزادی و حتی این پرفومنس رو به خاطر راحتی C#‎‎‎‎‎‎‎ بفروشن
الان qml سرعت تولید نرم افزار خیلی زیادی حتی گاهی در سطح C#‎‎‎‎‎‎‎ و دلفی دارهنه خیلی هم سخت نیست، اما وقت و انرژی برنامه نویس خیلی ارزشمنده.
واسه من یاد گرفتن چیزهای جدید خیلی ارزشمندتره.
مجبور نیستم تمام برنامه ها رو با سی و سی++ بنویسم که.
بحث همونه که برای بیشتر افراد، زبان برنامه نویسی و کدزدن و برنامه درست کردن همه چیز یا بیشتر چیزهاست، ولی واسه من اینطور نبوده حداقل تاحالا.
بنظر من اینکه بری مثلا علم رمزنگاری مدرن رو یاد بگیری، اهمیتش خیلی زیاده و خیلی کاربردیه. شاید برای شما و دیگران و در کاربردهای عادی مهم نباشه و حتی تقاضای تجاری و درآمدی هم نداشته باشه در کشور شما، اما خب خوره خورست دیگه!! گفتم که! یعنی من حتی با دانشمندان بزرگ علم رمزنگاری و متخصصان NSA هم احساس رقابت دارم و رنج میبرم اگر اونا چیزی بتونن و از پس چیزی بربیان و من ندانم/نتوانم!