Напоследък почвам да се чудя дали всъщност оопето не е най-лъжливата посока в която се е лашнало програмирането.
Функционалният стил със стремежът към преобладаващо side effect free функции изглежда в крайна сметка дава възможност за доста по-чист и безпроблемен 'външен' полиморфизъм с ясни генерични и лесно композируеми функции опериращи върху глупави структури торби с данни които пък когато са именно само глупави торби за данни също са лесни за разбиране.
Обектната парадигма с класовете и сладката отрова на this/self 'магията' и 'умните обекти дето знаят какво да се правят' изглежда благоприятства множество ужким локални обаче по-същество анклави с мазаляк същия като този дето се получава при програмиране с глобални променливи които всяка част на кода може да маже, примерно в един раздут клас прайвит методите дето пипат стейт без да им го дават публичните през аргументи и вече те да го модифицират на практика са лош глобалоиден мазаляк в достатъчно голям проект
Ако дадеш примерен код ще е добре. Функционалното програмиране има и своите мазаляци.
Според мен OOP-то много добре пасва за reusable структури от данни като списъци, речници и прочие. Това дето карантиите са затворени вътре позволява да се expose–нат само смислени алгоритми и да са лесни за откриване като натиснеш точка. Друг пример дето много добре се поддава на OOP са визуалните компоненти. ФП много добре пасва на неща като парсери и други неща дето разчекваш данни и взимаш решение на базата на типа.
Страничният ефект от мутирането на операндите е кашер оопе обаче визията е предателско функционална :)
Така би било перфектно:
fp.inPlacePreDecrementButBewareTheSequencePoints()
`
oop.inPlacePreIncrementButBewareTheSequencePoints()
При мене, мястото, където действително с ООП се получава по-добре, това са графичните интерфейси.
Навсякъде другаде отлично си работи императивното програмиране и нямам намерение да го заменям с нещо друго.
Всяко програмиране НЕИЗБЕЖНО има мазаляци, пойнтът е че илюзията за 'умни обекти' централна за ооп е възможно да не е по-добрият компромис какъвто фп също разбира се е понеже всяка парадигма е именно парадигма а не анархия заради ограниченията които налага с цел структура с идея в една по-голяма картинка да е на далавера
This/self е просто конвенция в крайна сметка, обектът е скрит първи параметър (в питон даже не е скрит което е добър баланс и не ме кефеше спрямо руби което е пропито от OOP отровата :) а параметрите на методите поддържани от обекта са конфигурация на ефекта от извикването им.
Във функционалния стил е с хастара наопъки (data last), параметрите са конфигурация на извикването а 'обектът' (глупавата торба с данни) е последен параметър. Това че е експлицитен на практика не се различава от OOP - obj.method(42, 43) носи същата информация като func(42, 43, data) само че е композируемо (посредством currying), ако се направи func1 = func(44, 45) имаме domain specific сгода без каквато и да било нужда от наследяваници с всичките там особености и си я ползваме и си щракаме - func1(data).
Вече въпрос на мета информация (типове, интерфейси, протоколи) е кои функции какви данни доколко могат да пипат и оттам всички сгоди на енкапсулацията на ниво език и удобствата на ниво среди за програмиране
Императивното програмиране е предтечата и на OOP и на функционалното, в днешно време като се каже функционално са едни стари но доскоро повече теоретични извращения доста отвъд хубавото каубойско императивно програмиране на бъзик, це без плюсове и асемблер което каубойско императивно програмиране според мен всъщност е зарибявката в програмирането щото кара човек да се чувства практически айде не господ ама поне некво малко господченце поне за малко.
Но после почваме да се усещаме - трудно е да бъдеш бог, и вече се почва с парадигмите и прочие по същество религиозни щуротии
Това всички го знаем, не разбирам как опровергава което и да е от нещата които казах. Дреме ми че вътрешно предавало this като параметър, въпросът е че като имам обект натискам точка и гледам какво може да прави. Също знам, че като напиша обект мога да му контролирам инвариантите и някакъв селяндур не може да ги прецака с дебилните функции които наплющи върху тях.
Номерът с парадигмите е, че те се опитват да намалят грешките на програмистите, налагайки им ограничения.
И ако целта беше постигната по този начин, то всичко би било отлично. Но лошото е, че всичките тези парадигми решават едни проблеми, но създават други.
Накрая резултата е, че възможностите на програмистите са ограничени, но бъговете както ги е имало, така си ги има. Просто други бъгове, не като първоначалните.
И на парадигмите им остава само да плашат – "То сега с нашето велико безбъгово ООП/ФП вижте колко бъгове допускате, а представете си, ако трябваше да пишете на Ц без плюсове или не дай си боже на асемблер!"
А истината е, че и на Ц и на асемблер, бъговете щяха да са пак толкова. Нито повече, нито по-малко. И производителността на програмистите също е приблизително еднаква.
Даже за най-хардкор асемблерното програмиране, лично моята преценка е за около двойни срокове за решаване на една и съща задача. Което е практически нищо в сравнение със представите на надъханите от религии джунове, които си мислят, че на асемблер се пише функция в продължение на месеци едва ли не.
В игрите също се ползва доста ООП нищо, че ДооМ единичката си беше на чисто C. Ползва се не защото и там има доста GUI, ами сцените се моделират основно от комбинация на оопета, структури от данни и алгоси въру тях. Това е обект, това е 3дОбект:обект, това е 3дАниматед:3дОбект и т.н. Надгражда добре и върху рендиращи, чисто C-апита, стейт машини, като OpenGL Нали имаше и една архитектурна патерна за entity component system, дето навързваш едни неща динамично и с composition over inheritance биеш старото ООП у земята. След пика на лудостта на ООП-ето в С++ и множествените наследявания и диамантения деадлок, нещата взеха малко да се поотдръпват дори C#, еле па при F# дето ООП-ето стои, като необходима прирурка.
Поне визуално страда от method chain отровата (нищо че се води zero cost abstraction) която се атрибутва на jquery вместо на истински гадния вредител в това отношение, руби :)
И има дразнещата неортогоналност да ползва :: за неймспейсове и точка за методи.
Но е нещо дето следя с интерес. Ужасно трудно е да се балансира между концептуална чистота (orthogonality, homoiconicity), ефективност (дев тайм И рънтайм), верифицируемост (церберски експлицитни типове/borrow checker), безцеремонност за лесно прототипване/рисърч, гъвкавост за адекватно домейн моделиране и разбира се мръсните но кефещи занаятчиски пинизи като пре/пост плюс минусването.
И по канон е четири спейса за индентация, анатема :)
Реба Създадено на 03.08.2020, видяно: 2470 пъти. #2384
няма достатъчно мур в аванс за да се залага на нови чекии
OOP е на пръв поглед по- близко до акъла и е идеално за бизнеса, защото им обещава програмиране на поточна линия. В реалния свят има актьори, които действат/правят нещо, както и е по- лесно да се фокусираш върху енкапсулирана логика. На пръв поглед е по- лесно смилаемо, но всъщност не е. Да се направи правилна абстракция е нещо, което изисква мислене и време, което обикновено не ни се дава. На много пъти съм си мислил "this just doesn't feel right". Опитите да измисля по- добра абстракция обикновено са ми стрували време след 8-те часа работа.
Но в края на краищата, правейки OOP получавам необходимите ми пари, за да поддържам живота, който живея. По- добре е, отколкото да мажа гипс и цимент на строежа. Още по- добре е от копането на къра. Ние се движим от бизнеса. Теоритично-идеален свят има само в университетите. Те могат да си research-ват колкото искат, защото се издържат от такси, грантове и спонсори, а не директоно от research-a им. Там може човек да прави глупави проекти, като да автоматизира кафе машината, it's fun! Аз мога да си пиша колкото искам код на erlang, но като няма кой да ми плати, това може да ми е само хоби.
В унивеситета правехме UML. Кой вече прави UML? Заданието ми идва с user story. Не че описва behavior-a по- добре, но отнема по- малко време да се направи. А някой мениджъри злоупотребяват и ги мързи дори това да направят. Копай по една лопата от тук до 6 часа на зигзаг, на всяка трета копка, копай една лопата повече.
Между другото, може би трябва да обвинявате Java за популярността на OOP. Има толкова много написано на Java с толкова много Java програмисти. Други езици впоследствие допринесоха. Сега има повече OOP програмисти от каквото и да е друго. Ruby е било само началото. Навярно тежките абстракции са това, което яде доста хардуер, but who cares. Макар, че почнах с php 4, в университета ми представиха Java като най-якото нещо създадено на света досега, направо нирвана. Java e лесна, мога да направя всичко с нея, даже да си бърша гъза. После ни показаха C++ за Windows и с всичките макроси и системни dll-и, memory management, just what the fuck?! Go Java! После ни показаха и C#, много харесах Visual Studio, it just feels right (2010, 2008 е по- боза). Побачках малко Java, но тогава Sun беше в стагнация и в крайна сметка минах на C#, защото Visual Studio vs Eclipse 
А и имаше lambda, което ми се стори cool. А и Java-та беше с CORBA, което е извращение само по себе си. Може би най- гадното нещо, което съм поддържал, с изключение на онзи път, когато имах един C++ TCP Socket сървър, в който обработвах някакви гадни фиксирани стрингове и се видях в зор, докато науча коя цифра с коя буква на коя позиция какво значи.
Functional не съм писал професионално, гледам да не се изказвам. Трудно е да кажеш кое е правилно, когато не знаеш какво е правилно, по- лесно е да забележиш, когато нещо е неправилно.
Кой ви оставя да копате цели 6 чАса?
1. Сутрешен Скум. Може да не е еднокраков и да е по Скайп, ама целия екип кибичи насила да слуша излиянията на 1-2 натегачи. От половин до един час не ни е стигало, ако и по стандарт да са 15 мин. макс. 2. Земаш си таск, независимо от JIRA или квото там модерно. 4. Пишеш квото пишеш, повечето на copy-paste. 5. Код ревю, с още някой отегчен колега, дето му се занимава колкото и на мене, ама Гана каза. Тъй пишело у книгите за овча мисъл. 6. Брутална мъка да си мържна файловете в Гит-а, щото на една жена като й дадеш 9 мъже и ще роди дете за месец. Гана каза. 7. Пушвам в Гит. 8. Описвам си работата в един документ за сървисите, за наша си лична девелоперска употреба. 9. Описвам същия таск у ена таблица, да е удобно на Гана да планира. 10. Връщам таска у Жира за тестване, и земам нов. 11. Попълвам таймшийта колко часа съм местил папки по кой проект. 12. Чеквам се на изхода да може системата да провери дали не си отивам с минута по-рано.
Имал съм случай на 2 места едновременно да пълня таймшийт, картите за достъп отделно. Ако случайно си забравиш картата у къщи глобавяха по някво 30 кинта ли беше, бесна Гана много държи да сме картографирани. Бизнесът на това се крепял.
Отказвал съм работа на място на интервю в чужбина, само щото ползват TDD. Веднъж ми изтропаха че ще бачкаме модерно по двама на един комп. Заминах си от вратата още.
Кога по дяволите ви остава време да кодите?
Жаварниците имат едно колосално предимство, което никой С# не може да компенсира. Се ено да ми фалиш златен кафез пред собствен избор, какъвто и да е той, вкл. златния кафез. Функционално съм писал години наред. Сяко нещо с предназначението си.
Ако развиваш екип Long term, това е много добро за knowledge sharing и knowledge retaining. Така и обучаваш хората практически, когато джуниърът не вдява, сядам с него и му казвам дай да помислим, мислим, после дай да пишем, пишем, казвам му тук е неправилно, защо, мисли, понякога му казвам, после осъзнава. Но е бавен процес. Мениджъра вика да сме по- оперативно. Добре, тогава ставаме по- оперативни, джуниъра пише нещо, което не знае какво прави, връщат му го 3 пъти за оправяне, отива в Production, излизат нови бъгове, hot fixes и накрая е изгубил повече време, но така мениджъра има по- добро оправдание защо се е забавил таска, което е пълна глупост и такива фирми трябва да си преосмислят процесите.
Това говори за много лош мениджмънт. Може да се каже имам проблем, но какъв се дискутира след това отделно от целия тийм, защото им губиш времето. Това зло трябва да се изкоренява. Не че не ми се е случвало да го виждам в няколко фирми. Не че и хората сега не се отпускат в детайли. Трябва да има някой да ги бие с пръчката, за да придобият дисциплината, да не занимават хората, които не могат да им помогнат с проблемите им. Това се нарича оплакване и е признак на много лош мениджмънт, като най- конкретно е неразбиране каква е целта на daily-то.
Аз си ходя когато искам и in return, когато трябва стоя повече до някаква граница, след това искам overtime. Ако някой ме накара да спазвам стриктно работното време, не бих работил за такива. Напускал съм такава компания след 3 месеца разговори по темата. Моето време за мен е по- важно от моето време за тях.
Това също е признак на лош мениджмънт и такива хора не трябва да са мениджъри, но е по- често срещано и то и в други сфери. Специално с agile трябва да допускаш, че има вариация. Особено със story points, крайният срок е проекция, а не е ултимат. Ако тимът прави 20 стори пойнта средно, а имаме 100 стори поийнта останали, то мога да предвидя, че след 5 спринта ще сме готови. Но това е проекция, защото по пътя могат да се ударят 100 мотики. Мониджърите трябва да започнат да работят с тази идея. В строителството също е така. На теория за 2 седмици ще излеем 3 плочи бетон, обаче 5 дена валя и изляхме само 2. Да иде миниджъра на врачка ли, прогнозната за времето ли ще гледа, майсторът каза, че ще стане, когато стане. Е, реалността е... Щото сега на мода е бързоликвидното, което се чупи бързо, консуматорското общество. Правим едни боклуци, продаваме ги, да му мисли, който си ги е взел. Евтиното излиза скъпо.