آموزش کلوژر ۲ - یه مقدار تئوری

clojure
learning_clojure
clojurescript
tutorial

#42

تغییر FP خب فرق میکنه با تغییری ک توی OOP داریم … شما یک ابجکت رو فاینال کردید و از اون با رفرنسش به دیتایی ک هیچ ربطی به فاینال بودن نداشت دستکاری کردید …

توی FP … بقول اقای سام x = x +1 زیاد مفهوم نداره … و باید به اینصورت y = x+1 اتفاق بیفته …


#43

عرض کردم . شما فرمودید final تو جاوا immutability می ده با اون مثال دیدیم که نمی ده ، فقط رفرنس رو نمی شه عوض کرد.


#44
class Mutable{
  private int value;

  public Mutable(int value) {
     this.value = value;
  }

  //getter and setter for value
}

class Immutable {
  private final int value;

  public Immutable(int value) {
     this.value = value;
  }

  //only getter
}

من بازم میگم … مثالی ک زدید یه فرض اشتباه بود …


#45

ایا شما گفتید که final تو جاوا immutability می ده یا نه ؟ مثلا فرضی نداشت. صرفا جهت نشون دادن چندا نکنه ساده بود. تو پست های قبلی اشاره کردم به نکات.

در مورد کدی هم که دادین هم باید بگم فرض بگیریم با این روش هم دیتا immutable داشته باشیم تو جاوا آیا این ترد سیف هست ؟


#46

فاینال + پرایویت . ترد سیف هستن … خود فاینال هم تا وقتی assign نکنید ترد سیف هست …
توی کد خودتون … x رو فاینال کنید اما مقدار 0 رو ندید بهش. .به همین شیوه کد من . توی کانستراکتور مقدار بدید . .
میبینید ک سایرین نمیتونن تغییرش بدن … و برای تغییرش x +1 = y باید استفاده کنید اونوقت …


#47

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

شما این سوال بنده رو بی پاسخ گذاشتید.


#48

این رو هم یادم رفت بگم که با کلاس immutable ی که ساختین دیتا رو با هر ابجکت به قول خودتون دارید repeat می کنین و مموری مصرف می کنید


#49

من تایید کردم اینو …

دیگه خود کلاس یه چیز stateless حساب میشه … مثل اینه ک بگیم داخل فانکشن … توی همون اسکوپ … میشه بازم متغییرا رو تغییر داد! … مهم اینه ک از بیرون و توسط سایر ترد ها تغییر نکنه …

اقا من استاپ دادم واقعا :sweat_smile::pray: من گفتم تا وقتی x فاینال نیست و پابلیکه … قابلیت تغییر داره .و صرف ابجکت ک فاینال باشه کافی نیست . .باید بصورت ذاتی … فاینال باشه تا immutable بشه .
شما با این امتحان کنید

class Havij {
    public final int x;
    public  Havij(int x){
         this.x = x
     }
}

#50

من رو موبایلم و دیگه نمی تونم quote کنم. اما کلاس خودش استیت هست مهم نیست پروپرتی پرایوت باشه. تا زمانی که جایی تغییر می کنه اون جا می شه رو چند تا ترد ران شه و همه چیز رو خراب کنه. حتی اگر همون کلاس immutable رو در نظر بگیریم باز مشکل repeat کردن دیتا رو حل نمی شه.
وقتی برگردم یه مثال هم پروپرتی های پرایویت می زنم که تغییرشون تو خود کلاس چجوری می تونه به سادگس ترد سیف نباشه.


#51

ساده ک نیست … گفتم . .اصلا برای به قول معروف real world apps … باید با locks ها کار کنیم …

اما درباره repeat ,.

تو ظاهر قضیه مثل همینه … اما در باطن اینکه چه اتفاقی میفته و واقعا share میشه یا یه چیز جداگانه ساخته میشه … کمتر حائز اهمیته …

و نکته ای ک میخاستم بگم و فراموشم میشد این بود ک … تو کل برنامه ما نیاز به مالتی تردینگ نداریم … ک کلا بیاییم همه چیز رو با تاپل(پایتون) . یا فاینال(جاوا) انجام بدیم … و یه مشکل هم به مشکلات اضافه کنیم …

اینکه مثلا تو پایتون … C API قادر هست که GIL رو ریلیز کنه … و ما میتونیم قسمتی از کد رو با Py_ALLOW_BEGIN / Py_ALLOW_END (همون اسکوپ لاک و ریلیز) با C بنویسیم . .کفایته و همه لایبرری هایی ک به پردازش موازی نیاز دارن (چه روی cpu , چه gpu) دارن از این قدرت بهره میبرن … و بقیه ی برنامه رو بصورت خیلی ساده و قابل فهم … بصورت سینگل ترد مینویسن … .


#52

Runar که شما کلیپ شو کپی میکنی اول راجعبش تحقیق کن و خودتان کلیپ و یک بارببین حداقل
اولا Runar نویسنده کتابFunctional Programming in Scala هستش بهترین کتاب سکالا در این زمینه

دوما اینtalk اگه گوش بدی متوجه میشه در آخر نتیجه گیری برعکس میکنه بخاطر اینکه با همه ایراد ها از OOP بهتره
این کلیپی Haskell هم ندیدی چون تیترش میشه هسکل برای پروداکشن نیست و افسانه های دیگر


#53

نتیجه گیری برعکس نمیکنه .مرحله به مرحله توضیحش میده.
اگر قرار بر توجیه یا ارائه راهکار برای رفع مشکلات باشه … خیلی کلیپ ها برای رفع مشکلات OOPهستن …

اتفاقا اینو با دقت بیشتری دیدم بخاطر همینم نوشتم از مزایاش میگه … و یکی از چیزهایی ک روش تاکید میکنه haskell difficalcy بود … و بیشتر هم راجبه haxl صحبت میکنه .


#54

از دقیقه ۲۰ به بعد talk
runar ببین چی میگه


#55

ــــــــــــــــــــــــــــــــــــــ

من فک نمیکنم این نتیجه گیری باشه … مواردی هم ک برای awesome اسم برد . اوکین … توی پارادایم های مختلفی اوکی هستن … یعنی با شکستن اپ حتی با OOP … و تیم گسترده میشه از هرچیزی استفاده مطلوب رو برد … همونطور ک کمپانی های بزرگ اینکارو میکنن …چ با OOP / چ FP…

تو 33:15 درباره جاوا هم میگه ک باید بهتر بشه … و کل هدف درباره نرم افزار هست …

نکته حائز اهمیت دیگه اینه ک … کل scaliblity توی مالتی ترد خلاصه نمیشه … همه مشکلات دنیا هم با پاراللیسم حل نمیشن … (گاهی نیازی نیست بهش اصلا) … و انواع روش ها و ابزار ها هستن برای اسکیل … پایتون هم اسکیلیبل هست … پرل هم هست … روبی هم هست … همه هستن … اما اگر از نگاه مخصوصشون بهشون نگاه کنید …

اپ سینگل ترد/OOP هم میتونه اسکیلیبل و ماژولار و reuseable و ایمن باشه …


#56

دوست عزیز بسیار معلوم که شما حتی وقتی کلیپ که همه میتونن ببینن هم حاضر نیستید گوش بدید اینا کلا یک سری ایرادهاست که به fp در سکالا فقط گرفته که خیلی هاش هم تا حالا بر طرف شده بعد تو دقیقه ۲۰ به بعد میگه آیا ما حالا باید بریم shared state نه چون این الترنتیو به مراتب بدتر و FP با همه بدی هاش modular و خیلی عالیه
من اصلا به پرللیسم کاری ندارم من تمام بحثم همیشه از modularity composability و سادگی فکر کردن راجع به برنامه بوده


#57

:neutral_face: ؟؟؟


#58

گفتم این ایراد از سکالا گرفته که به هسکل می‌خواد نزدیک تر بشه ولی اینکه شما بیای بگی این منظورش اینکه oop کارکنیم اصلا درست نیست چون runar بکی از بزرگ ترین برنامه نویس های FP هست و معلم بنده بوده و اگر میخواهی من ازخود ایشون هم سوال میکنم


#59

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

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

من کلا درباره این موضوع نه صحبتی کردم نه همچین منظوری داشتم … و تا الان صرفا ایرادات شما رو به OOP پاسخ دادم … و کلیپ هایی هم ک دادم بخاطر این بوده ک دیدی ک شاید تو سایرین ایجاد بشه اینطور نباشه ک از این ب بعد همه چیز تو FPخلاصه خواهد شد … یا OOPمشکل داره و همیشه خواهد داشت …


#60

کسی نمیگه oop هیچ فایده ای نداره یا همه باید fp کار کنند بحث بیشتر وقتی برای من حداقل میشه که شما یکسری صحبت راجع به fp میکنی که اگر یک ماه کد fp بنویسی میبینی غلط هست هرکسی میتونه نظر خودشو داشته باشه ولی نمیتونه حقیقت خودشو داشته باشه من راجع این موضوع دیگه بحث نمیکنم


#61

@samdvr @salvador @lxsameer @toomaj @pouya-abbassi
خیلی خیلی ممنون واقعا بحث خوبی بود برای بار سوم دارم پاسخ هارو میخونم خیلی چیز یادگرفتم