Showing posts with label computer science. Show all posts
Showing posts with label computer science. Show all posts

İspat

 

 
David Gilmour, Pompeii Konseri, 2016

Kuruyoruz. 

Semboller çoğalıyor ama uyaranlar azalıyor.
Gürültü var, duyamıyoruz. 

Yavaş yavaş da değil, son hızla kuruyoruz.

Dostu olmayana hazır sohbet, bilgisi olmayana hazır kültür, becerisi olmayana hazır marifet pazarlanıyor. Çürüyoruz.

Kablolarımızı bir fişe, fişi de en yakındaki prize sokmak ve kurtulmak istiyoruz.
Düğümleniyoruz.

Bağlanıyoruz, bağımızı bilmiyoruz. Köksüzleşiyoruz.

Propaganda yelleriyle savruluyor, köşelerde birikip öbekleşiyoruz.
Karşı köşedekine düşman diyoruz.

Sığlaşıyoruz.

Düşünmüyoruz. Soruyoruz.
Kopyalayıp yapıştırıyor, kurtulmak istiyoruz.

Yapmıyoruz, kombinliyoruz.

Kendimizle övünuyor, boşalıyoruz. 

Bilmiyor, beklentiye giriyoruz.
Bol bol şaşırıyoruz.

Beceremiyor ve küstahlaşıyoruz.

Makinenin içinden Dirac, Euler, Bukowski, Blake, Bach, Gilmour, von Neumann, Darwin, Minsky, Spinoza çıkacak mı diyoruz...
Aptallaşıyoruz.

Çıkmayacak!
İspatı burada: David Gilmour - Live at Pompeii - Comfortably Numb

Bu titreşimlerin ve sözlerin içimizde tetiklediği yüce hissin eşdeğeri o kombinatorik sistemlerden gelmeyecek.

Vasatın vesvesesi uğuldayacak.
Ve olması gereken dinginlik güneş gibi doğacak.

Kuruyoruz...

Elit, hayran bırakan, usta işi bir yazılım sistemi görmeyeli o kadar uzun zaman oldu ki.
Adına prompt denen cümlelerle, başkasına ait yazılımları yamalayarak yarım yamalak çalışan, çalışmaya çalışan yapılar kuruyor. O esnada kuruyoruz.

Amaca değil araca tutuluyoruz.

Rasyonelliğin işe yaradığı zamanlarda biri gelip "Herhangi bir işi kesin olarak yapamayan, içini tam bilemediğimiz; sadece çok spesifik, çok pahalı ve çok ender bulunan, istesek bile hemen alamayacağımız bir bilgisayar üzerinde çalışabilen bir yazılım geliştirdim" dese bu konuda nasıl bir karar verirdik? Hatırlayan var mı?

O duru, kuvvetli, akıcı, iyi tasarlanmış, çalışırken bir tatmin hissi veren makineler şimdi nerede?

Arabaları ele alalım.
Her yerine ucuz olduğu için kamera ve ekran doldurulmuş, sürücüyle bağı kopmuş, hepsi fabrikadan hatalı gelen tatsız arabalar.

Benim arabamın ortasında dev bir ekran var. Soğuk havalarda tepki süresi çok uzuyor. Tek bir hamleyle, sadece dokunarak, dikkati yoldan ayırmadan yapılabilmesi gereken havalandırma kontrolleri o ekrandaki yazılım menüsünün içinde bir yerlerde saklı.

O dev ekran telefonumu ele geçirmek istiyor. Verilerimi almak, her yere göndermek istiyor daima. Huzur vermiyor.

Bir de tam karşımda, direksiyonun arkasında dev bir dikdörtgen ekran var. Grafik arayüz tasarımı kötü. İşletimi yavaş. O dikdörtgen ekran iyi görünsün diye direksiyon da dikdörtgene evrilmiş. Bir hata bir hatayla kapatılmaya çalışılarak bir salgın hastalık başlatılmış adeta.

Bir de o kötü ekranların arkasında gizlenen boğucu sürüş kontrol yazılımı var. Sürekli bir yere çarpacağımı zannedip kendi kendine sert fren yapıyor. Daima bir sebepten sesli ve görsel alarm veriyor. O yazılımın derinliklerinde saklı klimayı ayarlamaya çalışıyorum, "dikkatin dağınık" diye beni uyarıyor. Park ederken çıldırıyor. "Çarpacaksın" diyor. Yağmur sensörlü silecek mekanizması asla doğru zamanda ve doğru hızda çalışmıyor. Bu yazılım her şeyiyle, arabaya musallat olmuş bir kötü ruh gibi, karabasan gibi sürücüyü boğuyor. Yoruyor.

...Ama böyle her şey daha az maliyetli oluyor.

Gel gör ki o arabanın üreticisi de batıyor. Çünkü önemsemiyor. Tasarlamıyor. Kopyalayarak takip ediyor.

Bazı müstesna üreticiler olması gerekeni yapmaya başladı. Örneğin Ferrari, bir süredir modernlik(!) ve maliyet nedeniyle direksiyondan kaldırmış olduğu fiziki düğmeleri geri getirdi. Hemzemin dokunaçlı düğmeleri kaldırma kararı aldı. Pazarlama başkanı Enrico Galliera fiziki düğme ve tamburaları kaldırmanın bir tasarım hatası olduğunu açık yüreklilikle beyan ediyor.

İş gören iyi bir makineyi kullanmanın zevkini, tatminini; böylesine nitelikli tasarım ve mühendislik eserleri üretmenin getirdiği doygunluk duygusunu bilen bilir. Biz mühendisleri besleyen ana damar bu olmalıdır.

Hal böyleyken, bir de sanki mühendislik ve teknoloji tarafında zaten her konu çözümlenmiş, mevzu bütçe planlama ve satın alma noktasına indirgenmişçesine bazıları "yapay zeka teknik değil, kültürel bir dönüşümdür" söylemiyle öne çıkıyor. Bu hoş bir propaganda cümlesi. Hayattaki birçok şey gibi yapay zeka da son derece teknik bir konu. Aspirin de teknik bir konu, rakı da, köprü de, uçak da, ekmek de, modem de, hatta cetvel de, kalem de teknik bir konu. Hepsi ancak uygun teknik ve beceri ile hayata alınabilecek konular. Teknik olgunluk, kullanılabilirlik ve sağlamlık ile ürünleştirme tamamlanıp da insanlar gündelik hayatlarında kullandıkça bir kültür konusu haline geliyorlar. Kültür, tekrar edebilen süreçlerin oluşturduğu bilgi birikimidir. Eşyanın doğasına bağlı kalarak söylem geliştirmek propagandadan daha sağlıklıdır.

Erişebilmek, kullanabilmek, "ödül aldım" demek istiyoruz. Tasarlamıyoruz.

Mesela, bir insan kaynakları yöneticisi övünerek "işe alımda tamamen yapay zeka kullanıyoruz" demeci veriyor. Bu sözü ve altında yatan fikri devam ettirelim...

İşe alım müdürü makine ise, işe aldıktan sonra kişiyi yönetecek müdür de makine olabilir. Dolayısıyla, o müdürün müdürü de makine olmalıdır. Makinenin makineye müdürlük yapması mantıklı olmayacağından işe alınan kişi ile patron arasındaki bütün müdür görevleri tek bir makinede etkin biçimde toplanmalıdır. Bu manzarada işe alınan kişi asla müdür olamayacaktır. Ancak kendine iş kurup patron olursa insani bir yaşam sürebilir, aksi halde makine yönetiminde bir tahakküm düzeninde köleleşir. Ta ki yerini bir makineye kaptırana dek. Bu resimdeki tek insan patrondur. Peki patron kimdir? Ya da bu düzeni dayatarak kim patron olmayı hayal etmektedir? Düşünmeye değer...

Bunun ötesinde, insanlar soysal zekaya da sahiptir. Sosyal sistemler kurarak inanılmaz bir adaptasyon sağlarlar. Hayatta belli sınırlara maruz kalınan durumlarda hep olması gereken şekli alır, verilmesi gereken tepkiyi varoluşsal bir güdüyle verirler. Arama motorlarına karşı web sitelerinin tasarımının neye dönüştüğünü, CV okuma makinelerine karşı CV biçimlerinin ve iş başvuru davranış kalıplarının neye dönüştüğünü, arabalardaki güvenlik yazılımlarına karşı sürücülerin nasıl atlatma yöntemleri geliştirdiklerini, "like" odaklı sosyal medya akış algoritmalarına karşı beğenmenin anlamının neye dönüştüğünü gözünüzün önüne getirin. Doğal olmayana, akıcı olmayana karşı geliştirilen hal ve şekiller genelde bir dejenerasyon olarak beliriyor. İnsanlık daha iyi bir yere gitmiyor.

Neticede, özenerek ve övünerek devreye alınan yapay zekalı otonom mülakat robotu derin bir düşünce, üst düzey bir tasarım unsuru taşımıyor ve uzun vadeli bir mutluluk resmine hizmet edemiyor.
Peki ne işe yarıyor?

"Ben de" dedirtiyor.

Ben de diyorum ki yapay zeka bilgisayar biliminden evvel, bilişsel mekanizmalar ve felsefeyle derinden ilgilidir. Gündelik hayat derdindeki ortalama birey ise, insanın doğası da dahil olmak üzere, üst seviye bilişsel mekanizmalara ilgi duymaz. Bu nedenle, yapay zeka arenasında popülist hevesler ve inançlar dışında net bir çözüm henüz ortaya konulamıyor. Çalışan kısımlar da yozlaşmaya neden oluyor. Esasen, benim düşünceme göre, hayattan bağımsız bir zeka tanımı olamaz. Zeka, özellikle sosyallik bağlamında hayatta kalmaya hizmet eden bir aygıttır. Dolayısıyla, yapay hayat ve vücutlaşmayı ortaya koyan bir tekniğin icrasından sonra yapay zeka o yapay bünyede gerekirse belirecektir. Bunun dışındaki denemeler bazı sınırlı otomatlar olarak kalacaktır. Özünde, "ajan ajan" denilen, yaşayandır. "Agency" 3 özellikle mümkündür: Yönelim (intention), bağımsızlık (autonomy), özgürlük (freedom). Tanıdık geliyordur: Özgün bir yaşam. Yapay ve özgün bir yaşam ile gelecek yapay zeka.

Fakat bu bir rönesans mı olacak, "kıyamet alameti" mi ancak yaşadığımızda bileceğiz.

</dur>

Silo

 
Senwes tahıl siloları (275 bin ton kapasiteli), Güney Afrika

UniCredit ile ortak çalıştığımız günlerde birçok İtalyan iş arkadaşımız vardı. Biri de Ricardo. Çok iyi bir yazılım mühendisiydi Ricardo... Eminim duymuşsunuzdur, yapısal programa dilleriyle yazılım geliştirirken programınızın yukardan aşağıya tam bir mantık duruluğu içerisinde akıp, başarıyla bitmesi istenir. GOTO komutu ile akışın bozulması çok kötü karşılanır. Bu tip "yapısı bozuk" programlara spagetti sitili programlar denir. İşte Ricardo bu benzetmeye cepheden karşı çıkardı. "Spagetti mükemmeldir ve böylesine kötü bir yazılım pratiğine spagetti denmesi saçmalık" derdi. Hatta, benzer sebeplerle, yapısı düzgün programlara lazanya stili programlama denmesine de isyan ederdi.

Gerçekten de iş hayatı birçok klişeleşmiş benzetme ve etiketlemeye boğulmuş durumda. Öyle ifadeler var ki sadece iş hayatında kullanım sahası bulabilmiş, hayatın esas zenginliği içerisinde hiçbir bağlama oturmuyor ve oldukça sığ kalıyor. "Siloları yıkmak" bu kalıplaşmış laflardan biri.

Hayatında silo görmemiş, silo inşa etmenin inceliklerinden bihaber, silonun faydalarını hiç düşünmemiş niceleri, siloları yıkmanızı öğütlemiştir eminim sizlere de... İş hayatının derin düşünmeye muhalif, her olguyu bir kapsül gibi yaygın biçimde, her tarafa tatbik etme eğilimi ve yarattığı zihinsel kısırlık mücadele etmemiz gereken bir şey bence. Ayrıca, ben genel olarak her şeyi mukayese veya benzetme ile tarif etme yöntemini çok ilkel buluyorum.

Gelin, silolara biraz yakından bakalım. 

Silolar tarım, gıda, kimya ve yapı sektörleri için son derece hayati saklama üniteleridir. Barındıracakları maddenin doğasına göre özel izolasyon, statik, havalandırma, direnç, yükleme ve boşaltma karakteristiklerine sahip olmaları gerekir. Farklı silo üniteleri arasında materyal transferini sağlayabilmek adına oldukça iyi tasarlanmış aktarım mekanizmaları ve güç üniteleri ile desteklenirler. Optimum maliyetle maksimum materyali saklama ihtiyacını karşılayabilmek için özel geometrileri olmalıdır. Üstelik, silolar sadece pasif depolama amacıyla değil, bir fabrikada üretim sürecine entegre bekletme, biriktirme veya aktarma istasyonu olarak da konumlandırılabilirler.

Uzun lafın kısası, silolar olmasa birçok endüstrinin dengesi bozulur, bazıları da yok olur. İyi bir silo ortaya koyabilmek için malzeme bilimi, kimya, iklimlendirme, inşaat ve süreç mühendisliği gibi alanlarda beceriye sahip olmak gerekir. Yani, anlamadan, bilmeden siloları yıkarsanız başınıza kötü şeyler gelebilir.

Silolara direkt savaş açan kişiler, silo derken işletmelerdeki departmanları kastediyorlar. Oysa departmanlaşma salt negatif bir anlama gelemez. Aksine, modüler tasarımın ve kontrollü otonominin bir yansımasıdır. Bir bakış açısıyla, düzeni, yapısallığı ve hiyerarşiyi temsil ederler.

Medeniyet düzen, yapısallık ve hiyerarşi üzerinde kurulmuştur. Örneğin, hayat ağacı diye betimlenen olgu insanın kaosa karşı kutsadığı yapısal hiyerarşiyi temsil eder. Kökler, ana gövde, dallar, alt dallar, yapraklar ve bu düzende yer altından göğün en yüksek mertebelerine yükselme...

Görüldüğü üzere, bir konuya yakından bakmadan ve derinlemesine akıl yürütmeden bir takım kalıp düşüncelerin izinde yol almak son derece sağlıksız bir tutum.

Bir de Conway kanunu var. Ünlü bilgisayar bilimci Melvin Conway 1960'larda ortaya koymuş bu kanunu. Conway özetle diyor ki bir organizasyonun tasarladığı sistem o organizasyonun içsel iletişim yapısının bir kopyasıdır. Bu öylesine geçerli bir içgörü ki daha ortada yazılım mühendisliği disiplini yokken böylesine bir ilişkiyi sarsılmaz bir kesinlikte tespit etmek ve devamında bu yaklaşımın empirik olarak defalarca teyit edilmiş olması inanılmaz. Bugün dahi "domain driven design" yaklaşımında anti-Conway manevraları önerilmektedir. Tabi ki Conway'in zamanında işletmeler yazılım sistemleri üretiyordu, yani tanımlayan ve baskın olan taraf organizasyon idi. Şimdilerde neredeyse işletmeler yazılım tarafından tanımlanır vaziyette. Şirketlerin yapısı bilgisayar sistemlerine o kadar bağlı ki şirkete ait yazılım sistemlerini ayakta tutabilmek adına organizasyonun orijinal yapısında yer almayan birçok departman teşkil ediliyor. Bu tersine dinamikte, Conway kanunu  nasıl ele alınmalı diye düşünmekte fayda var ama bu başka bir yazının konusu olabilecek kadar büyük bir başlık. Neticede, Conway kanununu hesaba katmadan siloları yıkarsanız, yazılım sisteminiz de yıkılabilir ve herhangi bir "anti-corruption-layer" sizi kurtaramaz.

Vasat bir var oluş için kalıplar iyi birer kılavuz olabilir. Fakat, amacınız zengin ve özgün bir yaşam sürmekse, siloları hemen yıkmayın, önce bir inceleyin.

Daha iyisini beceremeyecekseniz dokunmayın.

İkiz

 İsis ve Osiris

Geçenlerde dijital ikiz üzerine kısa bir hikaye yazmıştım, oldukça beğenilmişti. Bu konuyu bir süre rafa kaldırırım diye düşünüyordum. Fakat, hayat öyle akmadı...

Önce, ünlü fütürist Ray Kurzweil'in kızı, New Yorker karikatüristi Amy Kurzweil ve Kaliforniya Üniversitesi felsefe hocası Daniel Story tarafından kaleme alınmış olan bir makale çıktı karşıma. Okumak isterseniz burada. Makalede, Amy Kurzweil, yıllar önce hayata veda etmiş olan hiç tanımadığı dedesi Fredric Kurzweil'den geriye kalan yazılar, günlükler, notlar vb. bilgileri kullanarak geliştirilmiş bir sohbet yazılımı "Fredbot" ile olan etkileşiminden bahsediyor. Bunun ötesinde, yazarlar, genel olarak ölmüşlerin geriye kalan verileri üzerinden yapay zeka teknikleriyle dijital ikiz yaratma düşüncesinin etrafında dolanarak bir fikir cimnastiği yapıyorlar. Birçok alışılagelmiş sınırı zorlayan, bir taraftan Pinokyo, diğer taraftan Dr. Frankenstein eserlerine dokunan; modern zamanlarda da bazı dizi ve filmlerde ele alınmış olan, gayet çekici bir konu. Teknik açıdan ne kadar yapılabilir olduğunun ötesinde, işin sosyal imkanlarının belirlenmesinde ahlaki, geleneksel ve dini faktörler de devreye girecektir tabi.

Sonra, ünlü bir danışmanlık firmasında görev yapan kıdemli analistlerden birinin konuştuğu bir seminere katıldım. Geleceğin kurumsal yazılım ekosistemi üzerine olasılıklardan, bazı senaryolardan bahsedildi. Ve bu seminerde de otonom yapay zeka unsurlarının (agentic AI) birer müşteri olarak insanların namına alışveriş, yatırım, ödeme, sipariş planlama vb. yapacağı söylendi. Konu yine şahsi dijital ikizlere bağlandı.

Sonra, Satya Nadella'nın Dwarkesh Patel ile yaptığı söyleşiyi izledim. Uzun bir video ve çok farklı konularda hem Microsoft'un, hem de kendisinin duruşunu ve yaklaşımını ifade ediyor Nadella. Benim en çok ilgimi çeken kısmı ise "beyaz yaka" diye tabir edilen, "bilgi işçisi" de dediğimiz, Nadella'nın da videoda "cognitive labor" olarak dile getirdiği sınıfın ne olduğu ve üretken yapay zeka çağında neye dönüşeceği. Bu noktada da bilgi işçilerinin mesaj okuma, toplantı notu alma, rapor okuma, yazma, özetleme, zaman planlama gibi görevleri dijital asistanlarına devredeceklerinden bahsediliyor. Tabi ki bu asistanlar giderek şahsileşecek, asıl çalışanın verileri üzerinden onun bir tür dijital uzantısı veya ikizi haline gelecektir ki yapılan bilgi işleme ve üretimlerinde kişisel kalite faktörleri ortaya konabilsin. Microsoft, tarihinin başından beri bilgi işçilerinin tanımını, sağladığı araçlarla, yapmış bir kuruluş. Belli ki şimdilerde de bizler için bir kader biçiyor... Ama bu başka bir yazı konusu. Şimdilik şahsi dijital ikiz tarafında kalalım.    

Ben, işletmlerin operasyon verileri üzerinden eş anlı simülasyon yazılımlarıyla alternatif planlama, öngörü, arıza tespiti, üretim optimizasyonu gibi işlemlerin yapılması ve bunun adına dijital ikiz denmesi fikrine hem alışığım, hem de bu yaklaşımla barışığım. Fakat, konu insanın dijital ikizine gelince aklım karışıyor. Beni bu mevzuda şüpheye iten düşünceler ahlaki veya sosyal etkilerle ilgili de değil. Tamamen veriyle ilgili.

Benim nazarımda, varoluş demek var olanın evrene yaydığı bilgi ile mümkün olan ve bu bilgi üzerinden kendini belli eden bir kavram. Bu yaklaşımım canlı ve cansız her varlığı kapsıyor. Fakat, burada sadece insanlara yöneleceğim. Çevreye fiziken yaydığımız bilgileri düşünelim: Boyumuz, ağırlığımız, görünüşümüz, yüzümüzün ifadesi, saçlarımız, sesimiz, kokumuz, hareket tarzımız, ısımız, parmak izimiz vb. akla ilk gelenler. Bütün bu vücutsal varoluş evrenimizin içinde, zihinsel süreçlerimiz de organik biçimde çalışarak hem çevreden bilgi toplayıp işlemekte, hem de bilişsel süreçlerimizin bir çıktısı olarak sembolik bilgiler üretmekte: Dil, işaretleşme ve matematiksel ifadeler de dahil her türlü sembolik bilgi kategorisini en kapsayıcı haliyle düşünelim. İşte biz, bütün bu bilgi deryası sayesinde varız.

Kişisel bilgilerin mahremiyeti ve işlenmesi hakkında bu bakış açısıyla düşündüğümüzde ufkumuz da olduka genişliyor. Bugün sadece insani algı yetenekleri çerçevesinde ses, görüntü ve sembolik kimlik bilgileri üzerinden bir yargı oluşturma anlayışı hakim. Bir kurum rızanız olmadan siz yolda yürürken güvenlik kamerasıyla video kaydınızı alırsa, o kuruma başvurarak ilgili kaydın silinmesini talep edebilirsiniz. Ve bu talebinizde haklı olursunuz. Bu örnek, yaydığınız optik bilgilerle sınırlı. Oysa, kokunuzu bilen bir köpek, siz o sokaktan geçtikten saatler sonra sokağı koklayıp sizin oradan geçmiş olduğunuzu anlayabilir. Yani, varoluşunuzdan kaynaklı evrene yayılan kişisel kimyasal bilgileriniz sanki bulaşıcı bir yapıymışçasına ortamda kalır. Eğer bir önceki örnekte güvenlik kamerasıyla sizi kaydetmiş olan kurumun bir köpeğin burnu gibi çalışan güvenlik amaçlı kimyasal sensörleri de varsa ve siz ortamda yokken dahi bir süre önce oradan geçtğinizi tespit edebiliyorsa, kişisel bilgilerin mahremiyeti ve işlenmesi konusunu nasıl ele alacağız? Dedim ya, oldukça ufuk açıcı ama bu da başka bir yazının konusu :)

Gelelim insanların dijital ikizlerini yaratmakta ortaya çıkacak olan bilgi problemlerine. Eğer ikiz yaratmaktaki amaç kişinin tam bir simülasyounu ortaya koymaksa, bu iş çok zor diyebilirim. Çünkü, insanın varoluşundan kaynaklı ortama yaydığı bilgiler, az evvel bahsettiğim gibi, çok çeşitli. İşin kötüsü, bu bilgiler hayat boyu kayıt altına alınmıyor, fragmanlar halinde kaydedilmiş oluyor. Yani mükemmel simülasonu engelleyen temel bir bilgi eksikliği problemi var ortada. Bu sorun doğumdan başlayan çok boyutlu, kesintisiz veri kaydıyla aşılabilir belki uzak bir gelecekte. Tabi, böyle bir gelecek bence çok gayrı insani olacaktır. Asıl problem daha büyük: Biz insanlar, sadece ortama yaydığımız bilgilerden ibaret değiliz. Bizi biz yapan, karakterimizin nüvesini oluşturan birçok bilgiyi sessizliğimizde muhafaza ederiz. Eylemlerimiz ve açıkça ortaya koyduğumuz mesajlarımız kadar eylemsizliklerimiz ve sessizliğimiz de varoluşumuzun formülünde büyük yer tutar. Bugünün bilgi kaydeden teknolojileri bahsettiğim bu sessizlik veya eylemsizlik hallerini kaydedemiyor. Dolayısıyla, bilgi temsili ve bilgi işleme açısından dramatik bir tanımsızlık durumu var. Hiçbir yapay zeka modeli ortaya koymadığınız ama koyabilme potansiyeli taşıdığınız bilgiler üzerinden eğitilemez. Modeller sembolik bilgiye muhtaçtır. Data Science Days 2024 etkinliğinde Akan Abdula, pazarlama yazılımlarından bahsederken "biz artık yapay zeka ile insanların bilinç altına ve derindeki motivasyonlarına ulaşmaya çalışıyoruz" demişti. Bence ortaya koyduğum sessizliğin modellenememesi sorunu nedeniyle bu da çok zor bir uğraş. Sessizliğin derinliğine dair yıllar önce bir yazı yazmıştım, merak edenler buradan ulaşabilir. Söylenmeyenler dünyasında yatar asıl insani zenginlik, bütün sürprizler, icatlar, devrimler oradan alır mayasını. Söylenenler ise ya geçmişi anlatır ki insan hep yanlış hatırlar maziyi, ya şimdiyi anlatır ki şimdinin bilincini ıskalarız çoğu zaman, ya da gelecekten bahseder ki kimse bilemez geleceği. Söylenenler lafta kalır. Bilgi tanımlama ve sunma tekniği açısından sessizliğin sembolizmi ortaya konana dek kişisel dijital ikiz, gerçekleşmesi çok çok zor bir hayaldir diyorum.

Üstelik, ünlü düşünür René Girard'ın mimetik teorisine göre ikiz uğursuzluk kabul ediliyor. Bunu da akılda tutmakta fayda var. 

How I became a computer engineer

 

Ege University Computer Engineering Department, July 2021

I enrolled in Ege University in 1995 and graduated from Computer Engineering Department in 2000 with bachelor's degree. During that period, my dear professors worked really hard to create a computer engineer from me :) 

I must salute Prof. Erden Başar, Prof. Mehmet Özel Ergen, Prof. Sinan Yılmaz (R.I.P.), Prof. Ahmet Kaşlı, Prof. Fikret İkiz, Prof. Halil Şengonca, Prof. Levent Toker, Prof. Oğuz Dikenelli, Prof. Yasemin Topaloğlu, Prof. Aylin Kantarcı, Prof. Mustafa Türksever, Prof. Ata Önal, Prof Şaban Eren, Prof. Serdar Korukoğlu; and of course the teaching assistants of that time: Osman Ünalır, Güzin Şeker, Cenk Erdur, Selçuk Kaptan, Muhammet Cinsdikici, Nur Zincir, Aziz Can Yücetürk, Aybars Uğur, Ahmet Koltuksuz, Özgür Gümüş and Tuğkan Tuğlular.

What a crew!

Thank you, thank all of you a thousand times!

Today's story is about Tuğkan Tuğlular. The course was Microcomputers. Fifth semestre. We were following the great textbook "Structured Computer Organization" by Andrew Tanenbaum. Thanks to Tuğkan's enthusiasm, every assignment of the course was forcing us to use x8086 Assembly programming language. To be honest, Tuğkan was always giving us the freedom of using any applicable programming language but somehow all of us were using Assembly :) Here is the famous assignment:


The task was clear. Connect 2 computers through serial port (nowadays there are no serial ports on computers) and let those computers simultanously send files, chat messages, mouse pointer locations to each other. During all those operations, current system state must be reflected on the screen online. Of course, it was said that "The program can be written in any programming language..." as the last sentence of the assignment :))

During my undergraduate education, I have submitted many computer programs that were designed to solve many different problems. Those were developed by using Pascal, Quick Basic, C, Parallel C, Visual Basic, Delphi, PL/1, Java, even GPSS and of course, Assembly. However, I was sensing that the assignment above was a bit harder than others. First of all, you must be programming the Intel 8251 chip in a perfect way to meet the criteria of simultaneous communication. Keeping the integrity of the transferred data was another challenge: Which bit is beloging to mouse position data, which one is carrying the information of the file transfer or chat data? Data packages must be encapsulated well. Data loss must be avoided so you need a robust communication protocol... 

Actually, in the Microcomputers course, it was an obligation for students to understand what is going on under the many layers of the abstractions of microcomputer systems. What bare metal is capable of. How it is possible to come up with unversal solutions given a very limited hardware capacity. By assigning such difficult term projects, Tuğkan was knowing that the classroom was developing a sort of computational mastery. His project management philosophy was also astonishing :) He was saying "Guys, if I give you 1 month, you'll deliver after 30 days; if I give you 1 week, you will deliver on 7th day; if I say 3 days, you will deliver on the 3rd day. So why should I wait?". It was valid :)) And it still is valid.

Anyways, challenge was accepted in 1998 and we built the project team of three: I, Yılmaz and Volkan. In the old days, only available microcomputers to us were in the department building. In the dormitories or homes there were no computers. Therefore, we had to design the software on paper firstly. Then, we should have reserved a computer in the microcomputers lab of the department, and complete coding/compiling etc. there, in that given time slot. 

We shared the tasks in a way that I and Yılmaz were to develop the communication module and Volkan was going to develop the graphical user interface. In the dormitory, we designed the Assembly program on paper. A sample piece of note is below:


After the designs had been completed, we got to the lab and coded the program by following our notes on papers. Then, the miracle happened. 
We compiled the code. 
No errors. 
Okay. 
We linked the program. 
No anomalies. 
We started the executable file. It just worked well! 

For a third year computer engineering student, in such a challenging project, and the given complexities of Assembly programming language, it was just a miracle. I am still remembering my feelings of satisfaction and how we celebrated the moment. A couple of pages of the program listing is as follows:



At the end, it was just another assignment. But the meaning of this assignment to me is tremendous. The time we ran this program in our first attempt with no errors was the time I evolved into a computer engineer.

After that moment, I have developed millions of lines of code in many years. Even today, I know that some of my programs are running on some servers, in a confident way. It just gives me a warm feeling. I loved computer engineering. I am still in love with my profession and all the underlying science. In the last years of my active software development, I was setting such challenges to myself: "Tester will never find a single bug after I deliver my program" or "The developer who will be examining my program after me will adore me and my level of engineering" :) Fun times...

I am a very lucky guy because even today, I am so privileged to be a colleague of Yılmaz and Volkan in Yapı Kredi. And again, thank you Tuğkan for transforming me from a student into a professional.

Respect!

My Data, Your Algorithm

 

Vacheron Constantin Calibre 3750, the most complicated watch in the world. 

I was skimming the future of jobs report by WEF which was released in October 2020. Like most of the WEF reports, it is lucid and comprehensive. I strongly recommend you to have a look if you have not done yet. 

My key take aways from the report are: 
  1. Data & AI jobs are increasing
  2. Cloud computing jobs are rising as well
  3. Information technology super cluster is being splitted to more specialized sub clusters such as Data & AI, Cloud Computing, Engineering etc. 
  4. For popular jobs in Data & AI family, there is a very big skill gap
  5. Critical thinking, problem solving and self management are the top desired professional skills 
If your professional activity is around software, cloud technology, data and AI; and if you are a good problem solver, you are going to have good news at least until 2025. Even under pandemic measures... However, notice the huge skill gaps emphasized in the report. Nothing is going to be so easy, you need to learn, develop, adapt new professional skills faster and faster, in a continuous manner.

Being a person who started programming computers by using Commodore 64 in early 90s and living on computers for more than 20 years, I am lucky enough to watch how software related industry has been evolving. So in this post, I am planning to touch a topic which is very important for me in terms of being aware of what data & AI professionals should consider.

In the good old days, when a software engineer was requried to build a system, the steps we all were following could be roughly listed as follows:
  1. Define the required outputs of the system
  2. Design the interaction model and process flow
  3. Design the data flow
  4. Design data structures
  5. Build the algorithms
  6. Integrate
When we were followig such a discipline, the systems developed and all the sub components were authentic entities in most of the times. The main difference in software development and data business is that nowadays, no one is developing authentic algorithms any more. The tendency is using the algorithms of others as much as possible. Software reuse, remote procedure call and fostering frameworks were always popular topics, even in the ancient times but today, through shared libraries and APIs, literally no one is developing algorithms. Therefore, no one is designing decent data structures. Flat data in, flat data out. And I find this strange.

Especially in analytical model development process, companies are only configuring the algorithms of others by using native company data. At the and of the process, the model developed is just another instance of the foreign function which was originated from the algorithms of some other company. It is like you impose your memories into the brain of somebody else.

In the traditional software development process, the meta equation is like below

Equation 1: INPUT + INTERACTION + ALGORITHM = OUTPUT

In analytical model development, more or less, the equation becomes the one below

Equation 2: INPUT + OUTPUT = ALGORITHM

Please remember that, ALGORITHM of equation 2 is just a re-configured form of the algorithm of others.

Let's analyze this a bit more. Chronologically thinking, all the company data we are to use for developing machine learning models were generated by the software systems, which were developed traditionally, for years. That means INPUT + OUTPUT part of equation 2 is coming from equation 1. Therefore, data have been shaped by the authentic algorithms and interaction models for many many years. Today, you are trying to have a look at the company data to extract a version of some one other's algorithmic function. Isn't it strange too? I think it is.

Moreover, the notion of algorithm itself is not sufficient enough to model real world because an algorithm is a closed symbolic system. It takes inputs, processes finite steps and produces outputs. However, life is composed of interactions. Many interactive computer systems, which contain different algorithms, are running simultaneously, generating many events, getting feedbacks, triggering other systems etc. This bigger interactive picture is not reducible to algorithms.

On the other hand, in most of the cases, analytical models are developed by using non-inteactive, low dimensional, batch, historic data. By using that form of historic data, some one other's algorithm is tried to be configured to handle real life situations. Where is the effect of interactions there? Of course, some analytical models are formed to analyze streaming data. There is a proximity in this area but even such models are trained by following the batch data load practices. The scope of the problems to be solved by using analytical models can be narrowed down to fit into the nature of real life situations. This may handle the shortcomings of non-interactive, pure algorithmic approach. But it deserves another discussion...    
  
To sum up, I have 2 questions:
  1. Can we survive unless we create our authectic algorithms?
  2. How can we add the interaction notion better to the analytical model develoment process?
One of my bosses, whom I respect a lot, were saying "build the clock". I think we should follow the advice.   

Data, Big or Not

The contents page of Database Management book by Esen Ozkarahan: Databases were never merely relational ones.

Nowadays, technology vendors of various sizes are knocking the doors of the enterprises and offering them to use their "big data" solutions. These solutions are mostly appliance systems comprise a noSQL database, a data integration tool, a data analysis application and a data presentation application. People are bringing you boxes that are supposed to help you understand your business better so that you can react in a more proper way.

Beyond that aim, I think the industry has a strong tendency for locating big data concept which raises on pales of unstructured data such as voice, image, letters, e-mail, video, social media content etc. It's becoming a sort of fetishism. I know technology leaders and managers who may excrete considerable amount of adrenalin, that you can smell, while talking on big data solutions and the opportunities these solutions can bring.

However, what's the theory?
What do you mean by saying "unstructured"?
What questions would you like to answer for your instutition by using big data?
What are the theoretical limits?

The list of such questions may get longer easily and most of the questions are open ended usually.

My thoughts are...

I think, for the time being, it is not possible to extract a supreme meaning from the stored data flowing through different sources in an insane speed. It's like trying to reach the meaning of life. It's like uploading all Franz Kafka bibliography into a noSQL database and asking: "what is he talking about?". It does not make any sense to me.

I have a few words to say about the non existent "structure" of the data being mentioned. Actually, by naming data "unstructured", we're referring to the fact that data groups have got no known attributes to be stored in classified database entities and because of that, we cannot navigate and process the data easily. I think, in reality, all those data groups have special structures but we cannot apply a "one fits all" data pattern to the whole set. For instance, think of an e-mail you sent to your bank, it, of course, has a structure described by yourself intrinsically. Any one reading your e-mail can point which paragraph is the introduction, in which section you expressed your intention etc. On the other hand, it can be interpreted differently by various readers. Actually, nature and the essence of the text is a very deep phenomenon studied by a large number of philosophers such as Roland Barthes, Jacques Derrida, Claude Lévi-Strauss, Louis Althusser and Michel Foucault. There is no easy equation in this realm.

As meaning distillation from the non structured data sets is a complex process, most of the tools in the market are offering to get not the meanings but the sentiments out of the large chunks of the data gathered. It sounds good but there is a question here for the enterprises to answer: "do you wonder the sentiments of the people interacting with your institution?". If the answer is "yes", your corporations have been expected to save the sentiments of the people your companies are communicating thousands of times an hour through various channels and enrich the structured databases with their state of the feelings already. Moreover, your organizations are expected to analyze the sentiments collected and generate reports about them; and take some actions on the results of the sentiment analysis in practice. If your corporation is not taking these steps and expects to get the feelings of the customers after locating a big data solution, there is an ambiguity there. In addition, we have to keep in mind that sentiments are usually temporary oscillations. Therefore, if you are interested in sensing and processing them, you've got to do it in a timely manner which is another serious problem to solve.

Methods and the traditons of taking care of the data, defining the data and converting them into information and knowledge consecutively is transforming. We are not living in a world of black and white any more. Actually, the world has never been a black and white arena but we were living in an illusion after we have reduced the complexity of life by sacrifying some tastes of it. But the illusion ended. It's no more sufficient. The concept of the data has a weak point that data are very static when you store them in your databases. In contradiction, data usually flow in their natural habitat. The reflection of this natural flow to your database is the "model" you develop while you're defining the data. You can bring the dynamics of real world by using creative data modelling techniques. Models may be used to close the gap between your database and real life, where data generation happens constantly, but unfortunatelly, the models are static either. I'm sure that most of you have heard about the term of "slowly changing dimensions". In a similar approach, we have to devise slowly changing data models for chaging the form of the data in our databases for reflecting the life better in an automated way. To make the story short, I can say that storing the raw data in a noSQL database by omitting the model, that is a very powerful way to inject dynamism to your database, is a very weak approach. You can derive nothing from this pale.

What would be the proper approach?

To me, gathering the facts from a million data sources and putting them in a box for analyzing them later is an already dead method. You have to make your move in the right time, for the right people and you have to come with a meaningful message which is capable of showing the intellectual level of your company.

Simplicity is the key.

Sense the simple events properly and analyze them in a real-time fashion. Use easy to understant and "to the point" scenarios for evalution. Complexity of life is composed of simple but divergent transactions. Therefore, try to define the key transactions of your domain firstly. Then, try to inject the value to the transactions by assessing your institutional processes which are to distinguish you from your rivals.

Your process is your identity.

Data and the tools used for collecting and processing data are mostly the same but the processes of the organizations differ significantly. Let your customers be the actors of your authentic scenarios. People are irrational, but you always try to develop rational and mathematically consistent models for assessing your customers' behaviours, data etc. Try to be humane. Use human beings (your personnel) for communication, sales, giving meaning to the transactions. Some scalability problems may occur; use crowd sourcing or some other creative solutions when it happens.

No magic box can bring your organization money.

Think.

The Story of Mel

Provided from http://ed-thelen.org/

In this post, I just want to refer to great Jargon File of ancient times :) I am not going to explain what it is but if you are in the computer business, and it is your first time you heard about the Jargon File, please follow the link above and start reading before you read my post... Ted Nelson's great book would be a good choice, if you want to have a retrospective look at computer world, as well.
Okay. I am stopping to be a smart-ass and am leaving you with the story of Mel from Jargon File:
This was posted to Usenet by its author, Ed Nather (), on May 21, 1983.

A recent article devoted to the macho side of programming
made the bald and unvarnished statement:
    Real Programmers write in FORTRAN.
Maybe they do now,
in this decadent era of
Lite beer, hand calculators, and “user-friendly” software
but back in the Good Old Days,
when the term “software” sounded funny
and Real Computers were made out of drums and vacuum tubes,
Real Programmers wrote in machine code.
Not FORTRAN.  Not RATFOR.  Not, even, assembly language.
Machine Code.
Raw, unadorned, inscrutable hexadecimal numbers.
Directly.
Lest a whole new generation of programmers
grow up in ignorance of this glorious past,
I feel duty-bound to describe,
as best I can through the generation gap,
how a Real Programmer wrote code.
I'll call him Mel,
because that was his name.
I first met Mel when I went to work for Royal McBee Computer Corp.,
a now-defunct subsidiary of the typewriter company.
The firm manufactured the LGP-30,
a small, cheap (by the standards of the day)
drum-memory computer,
and had just started to manufacture
the RPC-4000, a much-improved,
bigger, better, faster — drum-memory computer.
Cores cost too much,
and weren't here to stay, anyway.
(That's why you haven't heard of the company,
or the computer.)
I had been hired to write a FORTRAN compiler
for this new marvel and Mel was my guide to its wonders.
Mel didn't approve of compilers.
“If a program can't rewrite its own code”,
he asked, “what good is it?”
Mel had written,
in hexadecimal,
the most popular computer program the company owned.
It ran on the LGP-30
and played blackjack with potential customers
at computer shows.
Its effect was always dramatic.
The LGP-30 booth was packed at every show,
and the IBM salesmen stood around
talking to each other.
Whether or not this actually sold computers
was a question we never discussed.
Mel's job was to re-write
the blackjack program for the RPC-4000.
(Port?  What does that mean?)
The new computer had a one-plus-one
addressing scheme,
in which each machine instruction,
in addition to the operation code
and the address of the needed operand,
had a second address that indicated where, on the revolving drum,
the next instruction was located.
In modern parlance,
every single instruction was followed by a GO TO!
Put that in Pascal's pipe and smoke it.
Mel loved the RPC-4000
because he could optimize his code:
that is, locate instructions on the drum
so that just as one finished its job,
the next would be just arriving at the “read head”
and available for immediate execution.
There was a program to do that job,
an “optimizing assembler”,
but Mel refused to use it.
“You never know where it's going to put things”,
he explained, “so you'd have to use separate constants”.
It was a long time before I understood that remark.
Since Mel knew the numerical value
of every operation code,
and assigned his own drum addresses,
every instruction he wrote could also be considered
a numerical constant.
He could pick up an earlier “add” instruction, say,
and multiply by it,
if it had the right numeric value.
His code was not easy for someone else to modify.
I compared Mel's hand-optimized programs
with the same code massaged by the optimizing assembler program,
and Mel's always ran faster.
That was because the “top-down” method of program design
hadn't been invented yet,
and Mel wouldn't have used it anyway.
He wrote the innermost parts of his program loops first,
so they would get first choice
of the optimum address locations on the drum.
The optimizing assembler wasn't smart enough to do it that way.
Mel never wrote time-delay loops, either,
even when the balky Flexowriter
required a delay between output characters to work right.
He just located instructions on the drum
so each successive one was just past the read head
when it was needed;
the drum had to execute another complete revolution
to find the next instruction.
He coined an unforgettable term for this procedure.
Although “optimum” is an absolute term,
like “unique”, it became common verbal practice
to make it relative:
“not quite optimum” or “less optimum”
or “not very optimum”.
Mel called the maximum time-delay locations
the “most pessimum”.
After he finished the blackjack program
and got it to run
(“Even the initializer is optimized”,
he said proudly),
he got a Change Request from the sales department.
The program used an elegant (optimized)
random number generator
to shuffle the “cards” and deal from the “deck”,
and some of the salesmen felt it was too fair,
since sometimes the customers lost.
They wanted Mel to modify the program
so, at the setting of a sense switch on the console,
they could change the odds and let the customer win.
Mel balked.
He felt this was patently dishonest,
which it was,
and that it impinged on his personal integrity as a programmer,
which it did,
so he refused to do it.
The Head Salesman talked to Mel,
as did the Big Boss and, at the boss's urging,
a few Fellow Programmers.
Mel finally gave in and wrote the code,
but he got the test backwards,
and, when the sense switch was turned on,
the program would cheat, winning every time.
Mel was delighted with this,
claiming his subconscious was uncontrollably ethical,
and adamantly refused to fix it.
After Mel had left the company for greener pa$ture$,
the Big Boss asked me to look at the code
and see if I could find the test and reverse it.
Somewhat reluctantly, I agreed to look.
Tracking Mel's code was a real adventure.
I have often felt that programming is an art form,
whose real value can only be appreciated
by another versed in the same arcane art;
there are lovely gems and brilliant coups
hidden from human view and admiration, sometimes forever,
by the very nature of the process.
You can learn a lot about an individual
just by reading through his code,
even in hexadecimal.
Mel was, I think, an unsung genius.
Perhaps my greatest shock came
when I found an innocent loop that had no test in it.
No test.  None.
Common sense said it had to be a closed loop,
where the program would circle, forever, endlessly.
Program control passed right through it, however,
and safely out the other side.
It took me two weeks to figure it out.
The RPC-4000 computer had a really modern facility
called an index register.
It allowed the programmer to write a program loop
that used an indexed instruction inside;
each time through,
the number in the index register
was added to the address of that instruction,
so it would refer
to the next datum in a series.
He had only to increment the index register
each time through.
Mel never used it.
Instead, he would pull the instruction into a machine register,
add one to its address,
and store it back.
He would then execute the modified instruction
right from the register.
The loop was written so this additional execution time
was taken into account —
just as this instruction finished,
the next one was right under the drum's read head,
ready to go.
But the loop had no test in it.
The vital clue came when I noticed
the index register bit,
the bit that lay between the address
and the operation code in the instruction word,
was turned on —
yet Mel never used the index register,
leaving it zero all the time.
When the light went on it nearly blinded me.
He had located the data he was working on
near the top of memory —
the largest locations the instructions could address —
so, after the last datum was handled,
incrementing the instruction address
would make it overflow.
The carry would add one to the
operation code, changing it to the next one in the instruction set:
a jump instruction.
Sure enough, the next program instruction was
in address location zero,
and the program went happily on its way.
I haven't kept in touch with Mel,
so I don't know if he ever gave in to the flood of
change that has washed over programming techniques
since those long-gone days.
I like to think he didn't.
In any event,
I was impressed enough that I quit looking for the
offending test,
telling the Big Boss I couldn't find it.
He didn't seem surprised.
When I left the company,
the blackjack program would still cheat
if you turned on the right sense switch,
and I think that's how it should be.
I didn't feel comfortable
hacking up the code of a Real Programmer.
Provided from http://ed-thelen.org/