Programming ∀

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.

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

Bu namming issuemi ? Yoki Skill issue ))

Turli tashkilot va public personlar twitterlarini buzish juda avjiga chiqibtimi 🤔

Kodingizda coupling va cohesioni intuitiv detect qilishni hohlaysizmi ? Unda eng birinchi ma'lum modulni alohida olib chiqib ko'ringchi )) DDD yana birbalolarda aniq bilaman bitta functional uchun kamida 3-5 ta filedan copy paste qilib olib kelasiz dependencylarni. Buyoqda sizga DI ham boshqasiyam yordam bermaydi. Undan yomoni o'sha objectlarni ham olib o'tish kerak. Agar siz DI qilgan bo'lsangiz va uniyam auto qilgan bo'lsangiz demak packageni ham olib o'tish kerak. Codebasedagi aynan biror kichik qism kerak bo'lib qolganida bunaqa dependencylar bilan ovora bo'lish ezvoradi ))

Agar bizda applicationi huddi database kabi sharding qivorish imkoni mavjud bo'lsa hech qanaqa k8s kabi muhitlar kerak bo'lmaydi(Imkoni ham mavjud aslida lekin keng tarqalmagan). Container systemlar o'rniga bitta mashinada ishga tushiramiz va bizga fiberlar, sparklar kabi yengil threadlar kerak bo'ladi. Ammo app ichiga o'z o'zini update qila olish funksiyasini ham qo'shish kerak, aynan pull strategy bilan. Nimalar yutyabmiz ? 1. Less overheads(Network, Storage, Memory) 2. Less dependencies(Kubernetes components like runtime, network proxy, balancer etc...) 3. Freedom Nimalar kerak ? 1. Yaxshigina bilim, bunaqa mechanismlarni bir platformga yeg'ish uchun. 2. Yaxshigina platform aynan shunaqa narsalarni bir korobkaga tiqsa bo'ladigan. 3. Alternativ fikrlash Nimalar yutkazamiz ? 1. Muammoni fix qilish uchun oldin biz foydalanishimiz mumkin bo'lgan infrani ham ancha kavlash kerak. Masalan systemD bilan bunday narsaga erishishimiz mumkin ammo uning o'zida memory issuelar bor. Demak OS levelda ham nimadirlar qilishimiz kerak. Albatta bunga juda mos keladigan OSlardan biri NixOs nazarimda. 2. Integratsiyalar, hamma narsani bir biriga yopishtirishga yaxshiroq integratsiya qilish mumkin bo'lgan protocol va interfacelar kerak. 3. R&D curve, yuqoridagi yechimlarni juda ko'plari turli patformlarda qilib bo'lingan va bazi joylarda yetarlidan ko'p abstractionlar bera oladi. Ammo xozirgi Agilega o'xshamagan OSS konveyrlariga o'xshashroq development model kerak. Hulosa: Yuqorida nazarda tutilgan platfomda ortiqcha layerlar yo'qligi uchun muammolar ham kam bo'ladi tizim ham tezroq ishlaydi. Bu bizga distrubuted computing perfomance oshishiga sabab bo'ladi va shu o'rinda infra quladi degan muammo bo'lmaydi faqat App quladi degan muammo bo'ladi. Demak tizim anchagina tashqi bog'liqliklardan qutiladi(Etcd, Kube proxy, kube scheduler. etc... componentlarda footgun qilganlar buni tushunyabti xozir). Microserivcelar va katta projectdagi juda ko'p responsibilitylardan qutilib yagona engineer degan masuliyatni olamiz holos, bu ortiqcha buyrokratik jarayonlarni chetga surib yaxshilab ishlash kerakligini anglatadi, shu o'rinda skill issuesi ko'plarga ham o'z ustilarida ishlashlari uchun yaxshi turtki beradi, shu orqali texnologik rivojlanish koffitsenti ham oshadi. Bu ideyalar silver bullet qidirish emas !

Ha qanday qilinganini taxmin qilish mumkin bo'lsa ham bu juda ham qiziq narsa. Bu web3 nimalarga qodirligi haqidagi gap emas lekin aloqa evalyutsiyasi qanday bo'layotgani haqidagi qissa ))

Shu sabab biror narsa qog'ozlarda degan gaplar aytilishi noto'g'ri deb bilaman. Agar faqat ortga qarasak rivojlanmaymiz. Rostdan ham xozir business talabi deb qilinayotgan axmoqona yechimlar sabab resurslarni ko'paytiraverishimiz kerak. Oddiy todo app bo'lsa ham birpastda microserivce qilaman cluster qilaman deyiladi )) Ammo salgina traffic katta bo'lsa boshni qashib o'tirishadi. Biz zamonaviy dasturlarni juda katta eskilik sarqiti ustiga quryabmiz mana shu narsa katta xato. Ekilik sarqiti esa aynan eng quyi pog'onalardan boshlanyabti...

Kernel kabi projectlarga alternativ prototiplar Rustda yozilganida yoki shunday urinishlar bo’lganida atayin ularni obrosizlantirib chetga chiqarishlar bo’lgan katta kompaniyalar tomonidan. Mana endi kernelda ham shu axvol sal oldinroq Sohibjon kanallarida ham shu mavzu ko’tarilgan edi. Shu sababdan aytdim qari takalar halal beryabti deb )) Ko’p yaxshi projectlar shunaqa o’yinlar qurboni bo’lib ko’milib ketyabti. Bunaqa narsalardan kimlar manfatdor ekaniniyam bilamiz albatta.

Qari takalar halal beryabti 😏

Команда Rust для Linux терпит поражение в сражении с разработчиками на С, её лидер ушёл из-за «нетехнической ерунды» В начале сентября 2024 года команда разработчиков проекта по внедрению Rust для ядра Linux потерпела поражение в сражении с разработчиками на С. Лидер Rust для Linux объявил, что уходит из проекта из-за «нетехнической ерунды» (nontechnical nonsense). Читать полностью #habr @linux_potok

Endi aniq miyya siqdi. Code darslikdan olingan. Bu yerda boolean tipini custom yasalyabti va buni haskell boolean tipi o'rnida deb tushunyabti. Lekin man tushunmayabman qanaqa qilib haskell buni tushunayotganini 😁

Lambda calculus haqida ajoyib contentlar share qilishdi, Kamron va Shakzod akalarga Rahamt ! Hullas hammasini bir joyga yeg'ib qo'yabman: https://www.youtube.com/watch?v=eis11j_iGMs https://www.youtube.com/watch?v=ViPNHMSUcog https://youtube.com/playlist?list=PLNwzBl6BGLwOKBFVbvp-GFjAA_ESZ--q4 https://www.youtube.com/watch?v=9syvZr-9xwk&list=PLidiQIHRzpXIFFbyGrWkqXXVj0BztDcTF https://www.youtube.com/watch?v=7BPQ-gpXKt4

Yuqoridagi post commentlarida yana qiziq narsa muhokama qilindi, hullas CS darslarida asosan Imperativ tillar, low levelga C high levelga esa Python deyilyabti. Mani fikrimcha aynan qaysidir etapda umuman computation theoryga kirib ko'rish kerak. Masalan man yaqinda bu mavzularni o'qishni boshladim, lekin kech boshladim deb o'ylayman. Ertarot boshlashim ham mumkin edi. Turing machine bilan Churchning lambda calculsi haqida o'rgansangiz ikki alternativ dunyoga duch kelasiz. Bizga mashhur bo'lgan digital computing ideyasi asosan statefull computinga asoslangan. Lekin boshqa alternativ ham bor bu aynan Alonzo Church tomonidan o'ylab topilgan funksiyalar orqali xisoblash modeli. Shu sababdan xisoblash nazariyasini o'rganish ancha foydali ha lekin ikkisidan ham chuqurlashish qiyin masala. Lekin tanishib chiqish kerak. Lekin bu mavzuni qachon va qayerda boshlash kerak ekanini bilmayman. Manda ikkisi bilan tanishuv ham deyarli bir vaqtda bo'ldi, turing machine hali ohiriga yetgani yo'q 8-bitlik computer ustida ishlar ketyabti. Lambda calculus bilan xozircha faqat tanishuv bo'ldi holos.