Власний висновок, який я хочу продемонструвати багато в чому покладається на ідею з UI/UX про те, що складні функції мають бути приховані від звичайного користувача.
Об’єктно-орієнтоване програмування – це досить складна концепція на прикладі якої ми розглянемо ідею про простоту мови. В цій публікації мені доведеться послатися на приклад з іншої публікації про моє розуміння об’єктної орієнтованості, в якому дуже просто реалізуються конкурентно безпечні Golang об’єкти без жодних класів і спадкування.
Поняттева складність
Якщо людина не має за звичку мислити й не володіє логікою й взагалі здатністю до філософії, то й розмовляє не послідовно і логічно, а імітуючи думку. Людина яка мислить, буде дуже ретельно відноситися до власної мови та слів які використовує.
Розглянемо приклад з ООП. Людині, що розуміє, що таке об’єкт, об’єкти не потрібні в семантиці і синтаксисі мови, бо вона їх легко може реалізувати використовуючи наявні, більш прості синтаксис та семантику.
Люди, які не розуміють, що таке об’єкт, не здатні правильно користуватися об’єктними синтаксисом та семантикою. При цьому, наявні об’єктні синтаксис та семантика провокують малодосвідчених розробників користуватися ними, що призводить до занадто складного й погано організованого коду (виразу сплутаних думок).
Крім того, аби дійсно щось зрозуміти, необхідно не просто прочитати пояснення, а прийти до нього через власний досвід, перевинайти його самостійно. В такі моменти відбувається трансценденція – перехід на інший рівень. Аби трансценденція відбулась – необхідно постійно мати сумніви й задаватися питаннями. Якщо людина задовільняється поясненнями з Вікіпедії, то трансценденції не відбудеться, оскільки її практика не провокує питань.
Синтаксис 🫀 семантика
Синтаксис відноситься до семантики як тіло до душі. Складна семантика зазвичай буде мати складний синтаксис, а складний синтаксис – складну семантику. Якщо в мову додається нова семантика, то й додається новий синтаксис. Нова семантика не може бути додана до мови без нового синтаксису. Синтаксис – це тіло семантики, її матеріальне втілення.
В своїй реалізації об’єктів в Golang я демонструю приклад того, що нам не треба складних синтаксису та семантики для об’єктно-орієнтованого програмування. Такий підхід надає наступні значні переваги:
- Ми можемо створювати не лише об’єкти з певною поведінкою, закладеною мовою програмування, а довільні об’єкти, як би ми їх не розуміли.
- Відсутність спеціальніх синтаксису і семантики для ООП дозволяє нам не орієнтуватися на розуміння ООП авторами тієї чи іншої мови програмування, а користуватися власним чітким розумінням, тобто таким, яке ми можемо самостійно описати в тих синтаксисі та семантиці, що вже є в мові.
- Відсутність спокуси до використання концепцій, яких не розумієш. Читай: “Захист від дурня”. ООП не повинно мати окремого синтаксису, оскільки воно провокує багатьох людей до написання поганого коду. Люди, які не мають чіткого розуміння ООП, не можуть його правильно використовувати. Крім того, розуміння, що таке ООП в людей різниться.
Наприклад, моя реалізація об’єктів включає в себе безпеку конкурентного використання (чого не має у більшості т.з. “ООП” мов) та семантику методів (що є майже в усіх т.з. “ООП” мовах). Я можу створити реалізацію об’єкта без першої, або без другої особливостей. Я можу створити зовсім іншу реалізацію об’єктів з декларацію і перевіркою деякого інваріанту, аби об’єкт не міг увійти в невалідний стан. Я можу поєднати усі ці особливості. Я можу додати логування в об’єкт. Я можу вигадати ще купу корисних функцій і використовувати їх вже зараз без того, аби очікувати ускладнення синтаксису мови програмування та релізів нових версій.
Простота мови
Google розробляли Golang для тисяч чи десятків тисяч поседерніх розробників, аби ті могли писати достатньо безпечний та надійний конкурентний код. Певно, саме через таку заявлену ціль Golang позбавлений майже повністю об’єктної семантики.
Єдине, що є в Golang умовно об’єктного, то це семантика методів, яка синтаксично реалізується просто як передача окремого, спеціального аргументу до типу якого прив’язується функція, цим самим стаючи методом типу, а значення цього типу стають отримувачами (receiver) викликів методів. Ця семантика дозволяє в Golang створювати “об’єкти для бідних”, які, якщо придивитися, скоріше схожі на абстрактні типи.
Golang підкупає цією своєю простотою, але дещо розчаровує своєю обмеженістю в низькорівнемому програмуванні, метапрограмуванні та системі типів. Через це я спостерігаю останнім часом за мовою Zig.
Мені здається, що дизайн мов програмування має бути дуже простим, без спеціальних підходів, до програмування, але таким, що враховує їх усі і дозволяє розробнику реалізувати самостійно.
Залишити відповідь