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

clojure
learning_clojure
clojurescript
tutorial

#21

اقا این شیوه رفتار با یه هویچ درست نیست اصلا: D
اولا

اشتباهه…اینجا هیچ آبجکتی نیست … تا وقتی New نشده … و اشاره گر به null اشاره خواهد کرد … و اون final صرفا جنبه نمادین بازی میکنه …

ثانیا دارید x رو تغییر میدید… درسته که رفرنس havij تغییری نمیکنه… اما x بصورت گلوبال و نه immutable قابلیت دسترسی پیدا کرده … یعنی صرفا ۱دونه Havij وجود داره … ک دارید با دوتا ترد باهاش بازی میکنید …و بلای اصلی رو سر x میارید… فاینال کردن یه ابجکت باعث نمیشه تمام پراپرتی های داخلش immutable بشن …

من ide جاوا ندارم … با یه کامپایلر انلاین … یاد گذشته ها کردم : ))


#22

اون متغییر اصلی نیست. متغیر اصلی اونی هست که توی HavijKade تعریق شده. بعنی:

دقیقا به چیزی اشاره کردی که من تا الان گفتم. فایتال بدون یه متغیر فقط و فقط یعنی رفرنس دیگه عوض نمی شه اما این به مقدار ( هر چیزی که در اون ادرس مموری ) ربطی نداره . عملا پروپرتی های یه ابجکت هم جز اون مقداری هستند که در مموری وجود دارند و h بهشون اشاره می کنه.

همیچین مشکلی هیچ وقت در زبان هایی که دیتا immutable بوجود نمی آد چون شما عملا نمی تونی مقدار چیزی رو عوض کنی.

برای دوستان دیگه هم که می خوان کد رو امتحان کنن. کافیه این کد رو با اسم Race.java تو یه دایرکتوری به اسم race ذخیره کنین و به این شکل عمل کنین:

javac race/Race.java
java race.Race

#23

اولا این درگیر شدن با جبر نیست این فقط اعمال یک قانون کلی که باعث میشه راحت در باره کد فکر کرد
دوما وجود مفسر در این خطا کمکی نمیکنه مگر مفسر مجبور کنه آدم immutable کد کنه یعنی اگه این جزوی از خوده زبان نباشه مفسر و compiler کمکی نمیکنه
کما اینکه در جاوا میتونی هزار جور ازین خطا های منطقی داشته باشی و به راحتی compile بشه کد

در FP کد stateless و خالص هست یعنی dependency به دنیای خارجی نیست و هر تابع با دادن ارگمنت های یکسان همیشه جواب یکسان میدن و محدوده کد value ها هستند
در کد غیر FP با وجود state و immutable نبودن داده ها زمان و ترتیبه فراخوانی توابع بسیار نتیجه متفاوتی میده که در پروژه های بزرگ فکر کردن درمودش بسیاردشوار میکنه
rich hickey به این نوع برنامه نویسی میگه Place Oriented Programming


#24

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

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


#25

شما از یه فرض اشتباه… نتیجه دلخواه گرفتین …
الان یه print توی سازنده کلاس استوپید ترد بزارید و h رو چاپ کنید… جفت رفرنس ها یکی هستن … این شیوه جاوا نیست که شما بصورت call by refrence کار کنید …باید بصورت call by value باشه …تا دچار این خطاها نشه … یعنی این یه خطای عمدی هست …
اینجا یک آبجکت هست … ک داره وارد میشه … و بخاطر new نشدن … تو کلاس ترد … جفتشون دارن روی ۱ ابجکت و پراپرتی کار میکنن … درسته که ثبات رفرنس خود ابجکت حفظ شده … اما هنوز اجرا نشده که روی x هم اعمال بشه…

final public Havij h = new Havij();
final public Havij h2 = new Havij();

StupidThread t1 = new StupidThread(this.h, 4, 1000);
 StupidThread t2 = new StupidThread(this.h2, 4, 1500);

الان کافیه یه print بزاریم … تو سازنده کلاس ترد

StupidThread(final Havij h, int x, int i) {
 System.out.println(h);
        this.h = h;
        this.i = i;
        this.x = x;
    }

میبینید ک رفرنس های هرکدوم جدا هستن … و نتیجه هم درست


#26

و یک چیز دیگه … کافیه x رو بصورت final در بیارید … و توی سازنده اش مقدار دهی کنید … میبینید ک اصلا h.x +1 رو ایراد میگیره … حتی داده خودشم قابل تغییر نیست … اما x اینجا mutable هست و هیچ ربطی به ابجکتش نداره ک فاینال باشه یا نه… x درهرصورت تغییر پذیره …


#27

خطاهای انسانی با تجربیات و عمیق شدن پوشش داده میشن … بالاخره یا باید با repeat و WET ا (FP) جلوگیری کرد . .یا با کدنویسای متخصص OOP :rofl:


#28

فرض اشتباه نیست. این برنامه نوشته شد که نشون بده :

۱. final مقدار رو immutable نمی کنه. و با final کردن یه متغییر فقط رفرنس ثابت می مونه و مقدار رو می شه عوض کرد.

۲. اون تک ابجکتی که به دو ترد پاس داده می شه share state هست و کل نکته این مثال این بود که final باعث نمی شه دوتا ترد نتون share state رو تغییر بدن.

۳. برنامه بالا یه مثلا واضح و ساختگی از race condition بود.

شما اومدی با درست کردن چند تا ابجکت سعی در درست کردن مشکل داشتی . یعنی اومدی دوتا ایچکت مختلف در مموری رو به دوتا ترد پاس دادی. برای اینکه از تغییر بدون اطلاعش خود داری کنی. دیتا immutable از همین چیزا اومده. بعدشم فرض کن شما ۲۰ تا ترد داشته باشی می خوای از یه دیتا ۲۰ بار تو مموری کپی بگیری ؟

بعد اینجوری که شما می گی همه چیز رو باید با final تعربف کنی. خیلی دوست دارم بدونم تو این روش state رو چه جوری کنترل می کنین جاوا امکاناتی از این دست رو در زبان نداره چون دیتا immutable نداره.

شما همچین مشکلی رو هیچ وقت تو زبانی مثل clojure با دیتا immutable اتفاق نمی افته کاربر تو این زمینه هیچ وقت نمی تونه دچار اشتباه بشه.

در مورد repeat و این داستان ها. شما تو مثالی که زدین با ساختن دوتا ابجکت دیتا رو repeat نکردین ؟

دوست عزیزم شما از روی تعصبت روی OOP و دید بدی که به FP داری یه قضیه نگاه می کنی. شاید بهتر باشه در این زمینه مطالعه داشته باشی و با FP بیشتر اشنا شی.


#29

این کلیپ ها خیلی خوبن : )


از مزایای هسکل میگه و از مشکلاتش ک باعث میشه برای پروداکشن مناسبت نداشته باشه(بجز کمپانی های بزرگ و متبحر هاش)

این یکی رسما یه Scala Sucks هست :rofl: درباره tails call

اینم خالی از لطف نیست

#30

این همون شیوه FP هست . .

نه نیاز نیست ۲۰بار ابجکت new کنیم . .یه آرایه از آبجکت ها میسازیم و هرجا نیاز شد New میکنیم ک خیلی هم کوتاه تر میشه کد

خب من تو پست دوم گفتم . صرف والد ک فاینال باشه … باعث نمیشه متغییر هایی ک بهش وصلن final باشن …
این final با چیزی ک شما فک میکنید در تضاده … و باید به شیوه خود جاوا اینو هندل کنید …تا از مزایای immutable ک مد نظرتونه بهرمند بشید …x رو فاینال کنید و تو کانستراکتور مقدار دهی کنید … تا immutable باشه . .بعد چطور تغییرش میدید؟؟


#31

من کل قصدم اینه ک بگم این جو FP و ضد OOP ک عمدتا با buzz wordهایی تیتر میشن و همه رفرنس میدن … برای همه صدق نمیکنه … و درست نیست …
FPمزایایی داره ک از اون جمله میشه به پاراللیسم و کانکارنسی سادش اشاره کرد
OOPمزایای دیگه ک هدفش DRYبوده و هست … و هرکسی ک با زبان OOP کد میزنه لزوما OOPبلد نیست … چون OOPباعث سادگی میشه نه پیچیدگی… تا وقتی ک این پیچیدگی بصورت عمدی یا حال نداشتن ایجاد بشه : )
من شیوه Creativity رو ترجیح میدم … بنابرین OOPمیزنم … اما از FP هم کنارش برای منظور های خاص استفاده میکنم


#32

image


#33

تعصب داشتن بزرگترین دشمن یک متخصص و پژوهشگره


#34

؟؟؟؟ :confused:

این شیوه FP نیست . دیتا تو FP کپی نمی شه واسه حل این مشکل یه binding رو می تونی بین همه شیر کنی. شما اومدی کپی گرفتی از دیتا.

۲۰ ابجکتی که تو یه آرایه باشن با ۲۰ تا ابجکتی که تو آرایه نباشن یکی هست. شما دیتا رو داری کپی می کنی و گذاشتنش تو آرایه نه فضای مموری رو کم می کنه نه این حقیقت رو پنهان.

همون جور که عرض کردم فاینال != immutable .
شما فرمودید فاینال تو جاوا برای immutable کردن دیتا هست که این طور نیست .شما x رو هم اگه فاینال کنی دیگه نمی تونی تغییرش بدی چون int هست. سوال منم همینه شما همه چیز رو تو جاوا با فاینال بنویس اون موقع state رو چجوری منیج میکنی برنامت چچوری یه مقدار رو عوض می کنه ؟

buzz word نیست اینا FP رو من اختراع نکردم و هدفم دفاع از چیزی نیست. شما دوست داری OOP کار کنی کار کن. بسیار هم عالی. اما FP مدرن جواب کلی ادم با هوش و شناخته شده هست که برای مشکلات OOP ساختنه شده.

من حدود ۱۶ سال هست که برنامه می نویسم و با خیلی از زبان های OOP هم به خوبی کار کردم ۴ ۵ سال هم هست که FP کار می کنم . بنابراین فکر نمی کنم جزء اون دسته ای باشن که OOP رو درست بلد نیسن. oop مشکلات خیلی زیادی داره اما شما به خاطر تعصبی که بهش دارین سعی می کنین انکارش کنین.

در مورد FP هم نمی دونم با چه زبانی کار می کنید. اما مشخصه که تو مفاهیم FP عمیق نشدین. خیلی پیشنهاد می کنم در مورد تئوری FP بیشتر مطالعه بفرمائید


#36

شما همین رو توی FP بنویسید …
صورت مسئله ای ک نوشتین گویا نیست اصلا … اصلا این شیوه ک نوشتین توی FPقابل قبول نیست ک ۱دیتا رو توی دوتا فانکشن تغییر بدید … ا

شیر میکنید اما تغییر ک نمیدید … میدید؟؟ یا اگر تغییر کنه … قبلی از بین میره و جدید ساخته میشه . .

چیزی رو انکار نکردم … و گفتم ک بر عهده برنامه نویسه ک اینو هندل کنه .


#37

همه کسانی در این بحث شرکت کردند از جمله @samdvr و @lxsameer در سطح بالایی و به صورت کاملا حرفه ای در زمینه مهندسی نرم افزار تخصص دارند، با وجودی که یادآوری موارد خیلی پیش افتاده مثل DRY و WET همیشه خوبه اما این معنیش این نیست که یک روز از خواب پا شدیم و تصمیم گرفتیم دیدمون رو نسبت به ‌پارادایم ها تغییر بدیم و به همه بگیم ما cool هستیم چون FP میکنیم.
سالها تجربه، تحقیق، شکست و موفقیت پشتشه


#38

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


#39

منم همچین قصدی نداشتم . یک بحثی بود و طبیعیه یک عده مخالف و یک عده موافق باشن .


#40

صورت مساله ای وچود نداره. یه مثال بود واسه اینه نشود بدم یک final != immutable و دو اینکه داشتن متغیر و تغییر اونها تو دوتا ترد چجوری می تونه باعث ایجاد خطا شه.

تغییر هم می دیم. بدون تغییر که برنامه پیش نمی ره.

من تعصبی رو این قضیه ندارم. همه چی از اینجا شروع شد که شما گفتی جاوا هم final داره برای immutability.
که خوب اشتباه هست.


#41

درسته، قبول دارم، منظور من اینه که موافقت و یا مخالفت کردن باید مبنای علمی داشته باشه