Programiści Enterprise nie gęsi i swój język mają

Zastanawialiście się kiedyś nad alternatywną składnią języka waszej matki? Na przykład taką, w której nie ma słowa być?

Jak to nie ma być? Przecież to podstawa? Da się w ogóle coś w nim powiedzieć? I po co się wydurniać? Przecież jestem w stanie się dogadać w sklepie i kupić sobie bułki więc jest git! I telewizor też jestem w stanie zrozumieć mogę też!

Jeżeli ktoś zdołał w sobie stłumić reakcję obronną przed dysonansem kognitywnym i temat wydał mu się intrygujący to warto zapoznać się z ideą języka E-Prime (ciekawe wprowadzenie tu: "Język E-Prime (English Prime) powstał jako swoisty dodatek do teorii niearystotelesowskiego systemu semantyki ogólnej autorstwa Alfreda Korzybskiego..."). Języka, który wręcz zachęca do formułowania subiektywnych wypowiedzi zależnych od kontekstu.

Znowu okazuje się, że to co wydaje się być naturalne, oczywiste i bezdyskusyjne jednak takie nie jest - niektórzy filozują nawet na takie, jak by się wydawać mogło, dawno zamknięte tematy. Oczywiście nie chodzi mi o to by od razu przestawiać się na nowy sposób mówienia i myślenia - po prostu nowe spojrzenie może otworzyć nową furtkę, przez którą ma szansę wedrzeć się struga świeżego powietrza rozrzedzając nieco stęchliznę.

Tyle tytułem wstępu - czas na mięcho...

Języki programowania ogólnego przeznaczenia wywodzą się z języków tworzonych na potrzeby matematyków. Przecież każdy "dinozaur" kodujący w szalonych latach 60 jest w stanie rozczytać kod klasy Javy, C# czy czegokolwiek co jest podobne do C.
Bo cóż takiego mamy do wyboru? Parę konstrukcji iteracji, parę konstrukcji selekcji, sekwencję oraz zestaw operatorów arytmetycznych. W starszych językach mogą być jeszcze technikalia związane z niskopoziomowymi szczegółami takimi jak zarządzanie pamięcią;)

/*
Żeby nie było, że należę lub sympatyzuję z nielicznymi (ale jednak) bezrefleksyjnymi i nieświadomymi niczego koderami, którzy twierdzą, że wszystkie języki programowania są takie same i są w stanie nauczyć się w ciągu paru dni dowolnego języka. Nie; chodzi mi po prostu o możliwość przeczytania kodu a nie o świadome jego tworzenie.
*/

Zatem praktycznie nie istnieje wsparcie dla logiki biznesowej w mainstreamowych językach (w niszowych nie wiem bo nie inwestygowałem). Jedyne co mamy to klasy, interfejsy, metody, pola i rozszerzanie (specjalnie nie piszę dziedziczenie, bo bez cech regresywnych nie ma co mówić o dziedziczeniu). Do tego instrukcje sterujące, operatory i radź sobie.



Od jakiegoś czasu przyglądam się Czi (przy okazji warto nadmienić, że Ojcem Założycielem jest nie byle kto, bo jeden z założycieli JBossa Rickard Öberg). Pora wrzeszczcie napisać coś bardziej konkretnego - najlepiej co nowego i dobrego to wnosi.

Qi ma szansę wypłynąć na fali rosnącej popularności Domain Driven Design. Widać, że swego rodzaju prąd myślowy DDD elektryzuje coraz większą grupę developerów. Będą oni w wkrótce potrzebować nowego frameworka wspierającego DDD aby wyżyć się w nowej przestrzeni.

No dobra, jak Qi wspiera DDD?
Przede wszystkim w Qi zachowanie (odpowiedzialność) zależy od kontekstu. Czyli idziemy bardziej w stronę świata rzeczywistego, w którym ta sama osoba może być w zależności od sytuacji programistą, mężem, motocyklistą...

Qi rozszerza standardowe "figury składniowe" o:

• Mixins: Containing state, e.g. Name, Person, Adress
  
• Concerns: Statelessm e.g. TransactionWrapper, Security
  
• Constraints: Checking parameters, e.g. NotNullConstraint
  
• SideEffects: Managing side effects, e.g. sending Mail
  

Oczywiście jest to rozszerzenie nieingerujące w składnię Javy 5 ponieważ opiera się na adnotacjach.

Jednym z głównych założeń Qi jest maksymalna reużywalność kodu. Jak wiadomo prawdopodobieństwo ponownego użycia rośnie gdy kod jest odpowiedzialny za jedną maksymalnie koherentną rzecz. Zatem w Qi składamy (komponujemy) wymienione powyżej fragmenty w większe części - kompozyty. Składanie kompozytów z części pozwala na zmianę ich zachowania - możemy zawsze spojrzeć na kompozyt z perspektywy jednej z części. Przykładowo możemy pozbyć się niezręczności wynikającej z "podczepienia" encji zawierającej metody biznesowe pod GUI. Po prostu w kontekście GUI encja jest np "prezenterem".

Qi zgodnie z DDD zakłada, że logika biznesowa jest aspektem, na który należy położyć największy nacisk, zatem zadaniem frameworka jest automagiczne przejęcie odpowiedzialności za technikalia takie jak persystencja czy transakcje. Pozwala to skupić uwagę na prawdziwym problemie stanowiącym rzeczywistą wartość systemu podczas gdy inne frameworki skupiają się jedynie na rozwiązywaniu problemów technicznych (zwykle przykrywając je kolejną warstwą abstrakcji zgodnie z zasadą Davida Wheelera "Any problem in computer science can be solved with one additional layer of indirection.").

Od strony technicznej QI zasadza się na AOP i IoC (DI w szczególności).


//====================


W sumie to sprytne stosowanie składni "subiektynej" (bez być) i "obiektywnej" (z być) jest jednym z głównych trików NLP czy w szczególności technik perswazji.

Przeglądając fora natknąłem się na krytykę Qi. Krytycy twierdzili jakoby twórcy Qi wzięli się za implementację swego pomysłu w nieodpowiednim języku. W skrócie: Java śmierdzi, Ruby jest sexi (heh żenada, język programowania jest sexi). Twórcy jednak ripostują:
- Composite Oriented Programming jest ideą, którą można zaimplementować w dowolnym języku
- Java jest standardem przemysłowym, posiada ugruntowaną pozycję i ogromne wsparcie społeczności.

I jeszcze jedno... kiedyś gdy miałem trochę zbyt dużo wolnego czasu zaczynałem nieśmiało zabawę z Pythonem i Ruby. O ile kojarzę to Ruby szczególnie charakteryzował się składnią, która jak teraz widzę mocno sprzyja COP. Szkoda, że autorzy tutoriali ograniczyli się do pokazania bzdurnych przykładzików prezentujących udziwnioną składnię nie pokazując, że nadaje się ona do implementacji idei szerszej niż tylko "hurra mój kod jest prawie tak paskudny jak bym go pisał w Perlu". A może sami wtedy jeszcze nie wiedzieli, że stworzyli potworka, który wspiera COP ;P