ru
Feedback
Programming ∀

Programming ∀

Открыть в Telegram

Ushbu kanalda IT va Dasturlashga aloqador mavzularda subyektiv fikrlarimni bayon qilaman.

Больше
1 217
Подписчики
Нет данных24 часа
-87 дней
-3530 день
Архив постов
Kecha side-effectlar haqida o'qib o'tirib uxlab qolibman ))

Haskellda shu narsa )) G'alatiroq ko'rinadi boshida ammo juda qiziq approach ))
Haskellda shu narsa )) G'alatiroq ko'rinadi boshida ammo juda qiziq approach ))

C++ da oddiy palindrome number. Sodda algorithm
C++ da oddiy palindrome number. Sodda algorithm

Leetcodeda haskell yo'q tasklari ham zerikarli. Codeforces masalalari ham juda qiziq. Haskellda yanayam qiziqlashadi yoki Rust )) Ko'pchilik farqiyo'q tilni deydi, bilmadim manga Cpp family tillar yoqmaydi umuman. Eng prikoli Haskellda qilayotgan solutionimda uje adashib qolyabman 😁

Bu qachon qo'shildi 🫠
Bu qachon qo'shildi 🫠

Mi phonelar fanatlari maqtanib yuradi endi, ayfon kamerani MIdan uxlatgan deb ))

Qiziq, reactjsning birinchi versiyalari Ocamlda ekan )) https://news.ycombinator.com/item?id=15209814

Shunda ham anavi nest yana birbalolardan ancha yaxshi. Balki browser sideda ham biror nimalar qilib xozir trendagi Frontend lib/frameworklarga aleternativ nimadir qilar. Shunda yana ko'pchilikda yana frontendga qiziqish uyg'onarmidi yana ))

Qiziq narsa shundaki effect-ts JS/TS ekotizimdagi eng yuqori progressiv lekin FP olamidagi ancha qoloq platforma 😁

Qiziq :)
Qiziq :)

Effect-ts ga STM qo'shilyabti ekan, nodejsda biroz bo'lsa ham yoqimliroq concurrency bo'ladi endi. Effect-ts community ancha narsalar olib kirib platformni biroz bo'lsa ham modernroq holatga keltirayotgan yagona framework deb bilaman. Umuman olganda nodejs ecosystemdagi juda kam sonli sifatliroq codebase )) Ref: https://github.com/Effect-TS/effect/tree/main/packages/effect/src/internal/stm

Solving the snake cube puzzle in Haskell. Judayam zo'r maqola ekan.

Github profileni tozalab qo’yib maqolalar va yana boshqa contentlarniyam alohilda joyga olib o’tsam kerak. Yani github static pageda yozaman. Qisqasi mani holatimda TG replace qilish oson ekan )) Shaxsiy yozishmalarga esa albatta mail yoki self hosted biror narsa. Agar programming everyone kanali aynan qayerdadir tursin desangizlar self hosted zulip qilaman :) Zerikanda call qilsak ham hullas xarbalo qilsak bo’ladi muhimi self hosted🙂

Telegramdan vos kechamiza shekilli anonimlik yoqolyabti.

Yana qiziq approachlardan biri biz biror til ichida DSL qilib olishni ham yoqtiramiz. Masalan DSL http client. Typescriptda huddi shunga o'xshagan narsani qilganman, asosiy sababi mavjud bo'lgan axios kabi liblarning ko'p qismi yoqmagan. Shu sababdan biroz boshqacharoq design bilan qilgan narsam borib borib DSL bo'lib qoldi )) Bunaqa narsalarni ancha sinab ko'rganman, platformdagi syntax noicelar bazida aynan shunaqa narsalrni qilishga ham majbur qilib qo'yadi. Magic code, odatda qandaydir optimizationlar va juda murakkablashib ketgan tricklarni shunday nomlayman bazida. Masalan Typescriptdagi turli magiclarni ham eslasak bo'ladi. Bazilar o'ziga notanish biror tilni ko'rganida aynan shunaqa magic qismini ko'rib qolib bu murakkab vaxakazolar deyishadi. Fikrimcha har qanday joyda magic code bo'ladi va bunaqa narsaga doyim ham duch kelinmaydi odatda force major xisoblanadi. Magic code quality metricsdagi birqancha parametrlarni tushirib yuborishi mumkin. Shunaqa narsalarni kamaytirish uchun ham code har tomonga tarvaqaylab ketavermasligi uchun ham aniqroq paradigma asosida ishlash kerak. Ohirigi 2-3 kunda Ocaml degan tildagi bazi narsalarni atayin ko'rib chiqdim. Ocamlchilar o'zlarini ekotizimni juda maqtaydi va boshqalarga ko'p tosh otishadi. Lekin qiziq fakt shundaki Ocaml, F# kabi tillar sizga hamma narsani vada qilib tayinli narsalar berolmaydi. Sababi bu ikkala tilni o'zi ham qaysi tomonga qarab ketayotganini bilmaydi, shu sabab hamma narsani kasha qilishgan )). Haskelldagi juda ko'p narsalar aniq bir biriga mos keladi va ko'p narsa aniq bir bir bilan intuitiv darajada chiqishadi(O'rganishlarim jarayonida deyarli biror narsaga nisbatan tanqid bo'lmayabti ham, hamma narsa aniq va bir biriga mos keladi yani o'z ideologiyasiga to'liq amal qila oladi, Haskell pure functional til deyiladi va rostdan ham shunaqa I/O hamma joyda inpure!). Eng boshida scalani o'rganayotgan edim davom qilmaganimning asosiy sababi pure functional til ko'proq qiziq bo'lgani edi, boshqacharoq aytsak hardcore learningga tayyor edim va ko'proq aynan Haskell o'ziga jalb qildi. Hullas boshida tanlov uchun variyantlar juda ko'p edi bora bora aniqlashib kegin aniq Haskell degan fikrga keldim va manga ekotizim ham community ham juda yoqdi. FPni theorydan boshlamaganimni asosiy sabablaridan biri esa tavsiyaga amal edi, @keilambda tomonidan berilgan tavsiya )) Ikkinchi masala esa boshida haskellda ish umuman yo'q deb o'ylar edim keginroq fikrim o'zgardi yani ish bor agar ishga layoqatli kandidat bo'lsa )) Umuman olganda FP joblar ham biz bilgan joblardan farqli emas uyoqda ham buyqoda ham dasturlash kerak bo'lsa bir domaindagi project bo'lishi mumkin masalan xozir fintechda ishlayman N muddatdan kegin haskellda ham fintech domaindan offer olishim mumkin.

Functional langagues are better then procedural, strong typing is better than week, static typing is better than dynamic.
© Bartosz Milewski

Bular kabi keng qamrovli bo'lmasa ham juda kichik researchlarim hulosasida. Object oriented codebaseda redabilityni yaxshilash uchun verblarsiz namming convension va immutable OO code bilan sinab ko'rganman. Ammo platform issuelar sabab bunaqa amaliyotlar doyim ham o'xshamas edi sababi pure OO tillar deyarli mavjud emas. Keyingi masala esa biror xisob kitobli codelarda Object based imperative code shakillangan, encapsulation yuqori bo'lgani bilan code redabilityga ham tasir qilgan. Hullas birqancha parametrlar asosida o'tkazilgan sinovlar hulosasida. Object oriented procedurial code hosil bo'lgan. Ammo to'liq sideffectlardan holi codebase qilolmaganman, balki skill issuelarim tufayli shunaqa bo'lgandir. Lekin code readability, maintainablity va yana boshqa parametrlardan kutilgan natijalarni olmaganman. Katta muammolardan yana bittasi esda mavjud OO tillardagi type system edi, Yegor aka ishlayotgan eolangda ham type system yo'q bu qandaydir lisp based approachlar ko'p. Bular o'rganishga oson bo'lgani bilan real hayotga tadbiq qilganda boshqa qiyinchiliklarga sabab bo'ladi. Keyinroq alternativ yechimlarni o'rgana boshladim mandagi talablarning ko'plari aynan code quality metrics mavzusiga ham aloqador edi. Code sifatli bo'lishi uchun albatta platform ham katta ahamiyatga ega ekanini tushungan edim ammo paradigm ham katta ahamiyatga ega ekan OO approachlarning hammasida paradigm ustiga patternlar qurilib rivojlangan, manga esa bu narsa yoqmas edi sababi patternlar hamma OO support qiladigan tillarga mos kelavermasligi yoki moslashtirishga ancha narsalar qilish kerakligi noqulay edi. Shu sababdan boshqa narsaga talab oshdi ya'ni paradigm manga code qanday tuzilishini o'rganishi bilan shunga mos platform ham tadbiq qila olishi kerakligini tushundim, shu o'rinda esa ushbu paradigm va uni asosida ishlaydigan platformalar doyimiy rivojlanib borayotganiga etibor qildim. Shu asosida functional programming with strong typing qiziqtirdi va Haskell yoqib qoldi. Bo'shida Haskell ko'zimga qandaydir qo'rqinchili va murakakb narsa bo'lib tuyildi va hamma kabi bu tilni o'rganishga math background kerak degan fikrda edim. Ammo turli gap-so'zlarni chetga surib tilni o'zini o'rganishga kirishganimda tushundimki bu tilni hech qanday backgroundsiz umuman hechnarsasiz boshlash mumkin ekan. Hechqanday murakkab nazariy bilimlarsiz Haskell code yozish mumkin. Umuman olganda boshida hamma narsani imperativ uslubda qilgan odam sifatida ko'nikish qiyin bo'ldi. Ammo vaqt o'tgani sari hammasi osonlashdi shunchaki alternativ fikrlashga o'rgana boshladim desayam bo'ladi, endi aniq ishonamanki Haskellni o'rganish qiyinroq bo'lishi mumkin ammo ushbu platformda va functional programmingda o'zim hohlagandan ham yuqori darajada sifatli code yoza olaman. Masalan OOda shuncha xarakat qilsam ham biror class yoki methodda juda ko'p narsalar 80-100 qatordan oshib ketgan, ularni ajrataman deb namming vaxakazo issuelarga duch kelganman. Haskell misolida esa bunday bo'lmayabti juda ko'p codebaselarda uzun qatorli scopelar kam va man uchun syntax noice ham deyarli yo'q. Xozirgacha haskellda funksiyonal dasturlash asosida biror narsa qilayotganimda compiler o'zi juda ko'p xatoliklarimni aytib turadi, xozircha unsafe code yozib ko'rmadim ammo safety code yozishda man uchun Haskelldakasi yo'q. Qisqasi man o'rganishga ko'proq energiya sarflasam ham yozgan kodim va foydalanadigan platformamga aniq ishonishni istayman bu maslada aynan Haskell keragidan ham ortiq imkoniyatlarni ochib beryabti. Shu sababdan Haskell white paper til emas balki general purpose production ready language deb ayta olaman.

Repost from @yegor256 news
An interesting study was done in 2008 by Raymond Buse et al. (Google), when they asked 120 volunteers to subjectively evaluat
An interesting study was done in 2008 by Raymond Buse et al. (Google), when they asked 120 volunteers to subjectively evaluate the readability of 100 Java code snippets each. Then, they calculated Spearman correlation between readability and certain features of the snippets. The conclusion you see on the diagram: the biggest negative impact has the number of identifiers in the code. BTW, this goes along with my 10-years old blog post: Redundant Variables Are Pure Evil (2015).

Qiziq-a Prosto random chiqib qoldi )) https://en.wikipedia.org/wiki/Domain_relational_calculus