Zen programowania

Od mojego ostat­niego wpisu upły­nęło wiele wier­szy kodu. Przez ten czas opa­no­wa­łem kilka nowych tech­no­lo­gii i języ­ków pro­gra­mo­wa­nia. Prze­ko­na­łem się też, że warto pisać testy do źródła nie tylko dla samego spraw­dze­nia pro­gramu. Ale po kolei …

Mniej wię­cej w poło­wie ferii zimo­wych, w trak­cie trekking’ów nar­ciar­skich (na bie­gów­kach rzecz jasna) odkry­łem w sobie potrzebę opa­no­wa­nia jakie­goś języka para­dyg­matu funk­cyj­nego. Padło na Haskell, ponie­waż naj­le­piej speł­niał moją zachciankę, dążąc w swo­ich zało­że­niach do mini­ma­li­za­cji kodu posia­da­ją­cego tzw. „Efekty uboczne”. Dzięki temu kod już na początku swo­jego ist­nie­nia zawiera o wiele mniej błę­dów, niż jego impe­ra­tywna wer­sja. Czas prze­zna­czony przeze mnie na opa­no­wa­nie idio­ma­tycz­nej składni i nie­ty­po­wego spo­sobu myśle­nia nie był cza­sem stra­co­nym, a pro­gra­mo­wa­nie znów stało się wielką przy­jem­no­ścią. Każ­demu chęt­nemu do pój­ścia w moje ślady pole­cam książki „Learn you a Haskell for great good”, „Real World Haskell”, „Haskell Road to Logic, Math and Pro­gram­ming” oraz kanał IRC #haskell ist­nie­jący w sieci fre­enode. Każda z sied­miu­set obec­nych tam non stop osób, stara się pomóc każ­demu, kto tylko o to poprosi.

Doświad­cze­nie mówi, że każde narzę­dzie powinno zostać dokład­nie spraw­dzone w prak­tyce, więc i mój nowy naby­tek inte­lek­tu­alny musiał przejść sze­reg prób w warun­kach bojo­wych. Zaczą­łem dla­tego pisać webowy fron­tend ser­wisu inter­ne­to­wego, wspo­ma­ga­jąc się fra­me­wor­kiem Hap­p­stack. Nie jest to biblio­teka stwo­rzona do wiel­kich pro­jek­tów, więc szybko oka­zało się, że wyczer­pa­łem jej moż­li­wo­ści. Będzie ona nato­miast naj­od­po­wied­niej­szym wybo­rem dla osób chcą­cych stwo­rzyć mały ser­wis na wła­sny uży­tek. W cha­rak­te­rze bazy danych świet­nie spraw­dza się acid-state, reko­men­do­wany przez auto­rów happstack’a. Jeśli z jakiś przy­czyn jego uży­cie jest nie­moż­liwe, wtedy konieczne może oka­zać się uży­cie Haskel­lDB i HDBC. Po tym roz­cza­ro­wu­ją­cym doświad­cze­niu spró­bo­wa­łem cze­goś innego — Yeso­dWeb. Zapo­wia­dał się świet­nie, jed­nak dość szybko poka­zał swoje praw­dziwe obli­cze — 100% zuży­cia pro­ce­sora i czas kom­pi­la­cji cią­gnący się w nie­skoń­czo­ność. Znie­cier­pli­wieni współ­uczest­ni­czący w pro­jek­cie nijako wymu­sili na mnie uży­cie jakie­goś spraw­dzo­nego i nie­za­wod­nego („nor­mal­nego”) roz­wią­za­nia. W ten spo­sób dzieło mie­siąca pracy z Haskell’em zostało zni­we­czone z uży­ciem Django w nie­całe 2 dni.
Roz­wa­ża­łem rów­nież uży­cie Ruby on Rails, jed­nak wtedy jesz­cze nic nie wie­dzia­łem o tej tech­no­lo­gii. Obec­nie uwa­żam, że ruby to zna­ko­mity i upo­rząd­ko­wany język, a popu­lar­ność rails’ów jest wysoce uzasadniona.

TBC

18 kwietnia 2012

Wstęp do paradygmatu obiektowego

Stwo­rze­nie pro­gramu kom­pu­te­ro­wego naj­czę­ściej spro­wa­dza się to do wyra­że­nia jakie­goś algo­rytmu w postaci kodu źródło­wego. Ta forma zapisu nie jest jed­no­znaczna, co ozna­cza, że ten sam algo­rytm można zapi­sać na wiele róż­nych spo­so­bów. Kiedy pomi­niemy detale takie jak skład­nia kon­kret­nego języka pro­gra­mo­wa­nia, poszcze­gólne imple­men­ta­cje będą róż­nić się tylko abs­trak­cyj­nym spo­so­bem opisu pro­blemu — para­dyg­ma­tem. Idee, które nie­sie ze sobą para­dyg­mat obiek­towy są dla nas bar­dzo natu­ralne o czym świad­czy nasze odwieczne dąże­nie do skla­sy­fi­ko­wa­nia i zde­fi­nio­wa­nia ota­cza­ją­cego nas świata. Każda popraw­nie sfor­mu­ło­wana defi­ni­cja jest pew­nym sza­blo­nem, który z ogółu wybiera tylko speł­nia­jące ją ele­menty — „instan­cje defi­ni­cji”. Dodat­kowo defi­ni­cje czę­sto skła­dają się ze słowa klu­czo­wego i  zestawu cech odróż­nia­ją­cego je od defi­ni­cji słowa klu­cza. Prze­no­sząc powyż­sze fakty na język pro­gra­mo­wa­nia obiektowego:

  1. defi­ni­cja to klasa
  2. ‘instan­cja defi­ni­cji’ to obiekt
  3. słowo klu­czowe to klasa bazowa
  4. cecha obiektu to pole

Wyróż­niamy jesz­cze metody — pola, które zawie­rają funk­cje (dla uprosz­cze­nia można przy­jąć, że metody to funk­cje wpły­wa­jące na stan obiektu). Pozo­stało już tylko wspo­mnieć o czte­rech pod­sta­wo­wych fila­rach pro­gra­mo­wa­nia obiektowego:

  • Abs­trak­cja — dzia­ła­nie obiektu nie wymaga od niego ujaw­nia­nia implementacji,
  • Her­me­ty­za­cja — zmian w środo­wi­sku obiektu mogą doko­ny­wać tylko jego wła­sne metody,
  • Poli­mor­fizm — zacho­wa­nie obiektu może zale­żeć od kon­tek­stu jego użycia,
  • Dzie­dzi­cze­nie — klasy mogą być defi­nio­wane z uży­ciem innych — bar­dziej ogólnych.

I ot cała filozofia …

9 stycznia 2012

Wraca nowe

Od zawsze moja strona była poli­go­nem doświad­czal­nym, uży­wa­nym przeze mnie do testo­wa­nia róż­no­ra­kich roz­wią­zań webo­wych. Jej formę zmie­nia­łem już sie­dem razy, jed­nak nigdy nie mia­łem czasu dodać tre­ści. Tak więc po raz siódmy obie­cuje sobie i innym „poprawę”. Co z tego wyj­dzie — czas pokaże …

9 stycznia 2012