- Gerald Sussman, 1962’den bu yana IBM 7094, PDP-6, Mac Hack 6 ve Maxima gibi erken dönem bilişim ortamlarından geçerken programlamanın kendisinden alınan keyfi hep koruduğunu söylüyor
- Programlama, bir şartnameyi mekanik biçimde koda aktarmak değil; eksik tanımlanmış hedefler altında olası şartname ve uygulamayı birlikte arayan soyut bir mühendislik tasarımına daha yakın
- Lisp’in eval/apply yapısı ile Maxwell denklemlerinin etkileşimini yan yana ele alarak programlamayı, fizik, matematik ve felsefe gibi derin kavramsal sorunlarla uğraşan yaratıcı bir etkinlik olarak görüyor
- Hata, basit bir başarısızlık değil; sonlu kapasitedeki insanın basitleştirilmiş planlarla problem çözerken ortaya çıkan bir öğrenme fırsatı ve “neredeyse doğru bir planı debug ederek problem çözme” sürecinin parçası
- Otomatik türev alma, Scheme’in jenerik işlem genişletmeleri ve klasik mekaniği çalıştırılabilir programlar olarak ifade etme deneyimi, programlamanın başka disiplinleri daha açık hâle getirebileceğini gösteriyor; bu keyfin free/libre software olarak paylaşıldığında tamamlandığını vurguluyor
Kodlamanın ötesinde tasarım ve keşif
- Sussman, 1962’de lise öğrencisiyken bilgisayar kullanmaya başladı ve Columbia Science Honors Program’da bilişimle tanıştı
- İlk bilgisayarlar, IBM 7094 serisi gibi milyonlarca dolara mal olan, yalnızca 2^15 adet 36 bitlik sözcüğü adresleyebilen ve yaklaşık 2 mikrosaniyelik çevrimle çalışan makinelerdi
- MIT’ye girdikten sonra DEC PDP-6 gibi bilgisayarlarla tanıştı; bu sistem 2^18 adet 36 bitlik sözcüğü adresleyebiliyordu
- Büyük bellek, Maxima gibi erken dönem sembolik işleme sistemleri için gerekliydi
- MIT, Fabritek’e büyük bir bellek siparişi verdi; üretimi 1 yıl sürdü ve kayıtlara göre yaklaşık 380 bin dolara mal oldu
- Bu bellek o döneme göre çok büyük olduğu için bir balina adından esinlenilerek Moby diye anıldı
- Yapay zeka, yeni bilgisayar tasarımı, programlama dili icadı, gök mekaniği için sayısal simülasyonlar ve büyük sembolik sistemlerin yazımıyla ilgilendi; ancak merkezde programlamaya duyduğu sevgi hep vardı
- Programlama, iyi tanımlanmış bir şartnameyi çalıştırılabilir koda dönüştüren mekanik bir iş değildir
- İyi şartnameler genellikle yukarıdan hazır gelmez
- Önce neyin uygulanabilir olduğu keşfedilir, sonra gerçekten başarılabilecek şeye uygun şartname yazılır
- Bu yüzden programlama, kısmen tanımlanmış bir hedefe doğru olası şartname ve uygulamayı birlikte arayan ortak bir keşiftir
- Fiziksel mühendisliğin aksine programlama; tolerans, kesme eğriliği, direnç hatası gibi fiziksel kısıtlardan çok düşünceyi düzenleme becerisiyle sınırlanır
- Programcı, gösterimleri, algoritmaları ve soyutlama düzeylerini seçerek devasa bir sanal makineyle çalışır
Yaratıcı bir sanat olarak programlama
- Sussman, programlamanın hissini açıklamak için Edgar Allan Poe’nun “The Raven”ı nasıl yazdığını anlattığı yazıdan alıntı yapıyor
- Poe, eserin tesadüf ya da sezgiyle değil, bir matematik problemi gibi adım adım tamamlandığını söyler; seçim, çıkarma, ekleme ve düzeltmeden oluşan karmaşık süreci ortaya koyar
- Bu süreç, bir şartnameyi koda dönüştürmekten çok gerçek programlama deneyimine daha yakındır
- Programlama; mimarlık, müzik, matematik ve teorik fizik gibi yaratıcı bir sanata daha yakındır
- Matematik, güzel teoremler icat etmeye yönelik bir etkinliktir
- Teorik fizik, fiziksel dünyanın açıklamalarını icat etmeye yönelik bir etkinliktir
- Programlama da fikirler ve yapılar icat edip onları rafine etme etkinliğidir
eval/apply ve Maxwell denklemlerinin gösterdiği yapı
- MIT’de birinci sınıftayken Lisp 1.5 ve eval/apply yorumlayıcısını öğrenmesi, Sussman’ın hayatını değiştiren bir deneyimdi
- eval, bir ifade ve ortam alıp operatör ile operandları değerlendirerek prosedür ve argümanları oluşturur; apply ise prosedür ve argümanları alıp argümanları biçimsel parametrelere bağladıktan sonra gövdenin değerlendirilmesine geri döner
- Sussman, bu yapının tüm bilgisayar dilleri ve bilgisayarların kendi çalışma biçimi için de geçerli olduğunu düşünür
- Aynı dönemde elektromanyetizma dersinde Maxwell denklemlerini öğrenirken başka bir güçlü izlenim edinir
- Maxwell, yük korunumu ile mevcut denklemler arasındaki tutarsızlığı çözmek için yer değiştirme akımı terimini ekledi
- Bunun sonucunda elektromanyetik dalga denklemi ortaya çıktı ve ışığın elektromanyetik dalga olduğu bağlantısı kuruldu
- eval/apply etkileşimi ile Maxwell denklemlerinde elektrik alan ve manyetik alanın birbirinde değişim yaratması arasında derin bir benzerlik vardır
- Bu benzerlik, konum ve momentum, enerji ve zaman gibi eşlenik değişkenler arasındaki ilişkiyle de bağlantılıdır
- Programlama günlük olarak felsefi sorunlarla karşılaşır
- Bir programdaki
Chicagoadının gerçek şehri nasıl işaret ettiği basit bir mesele değildir - İki nesnenin aynı olup olmadığı, biri değiştirildiğinde diğerinin de değişip değişmediğiyle ortaya çıkar; değiştirme (mutation) kimlik problemiyle bağlantılıdır
- Saf fonksiyonel programlarda değiştirme olmadığı için kimliği başka bir biçimde ele almak gerekir
- Alıntılanmış ifadeler içinde “aynı olan aynı olanla değiştirilebilir” ilkesi bozulabilir
- “Bütün kuzgunlar siyahtır” gibi önermeler, Hempel’in Raven Paradox’unda olduğu gibi kanıtın anlamını zorlaştırır
- Bir programdaki
Hatalarla başa çıkma biçimi
- Sussman, hatayı utanılacak bir başarısızlık değil, öğrenme fırsatı olarak görür
- İyi araçlarla debug yapmak macera gibi keyifli olabilir; hataların da fencepost error veya reader-writer bug gibi adları olması gerektiğini söyler
- Hatalar aynı zamanda güçlü bir tasarım stratejisinin sonucudur
- İnsan her şeyi aynı anda düşünemediği için plan yapar
- Planlar basitleştirme gerektirir; basitleştirme de atlanan kısımlar yaratır
- Bunun sonucunda hatalar ortaya çıkar ve debug, neredeyse doğru bir planı istenen yönde düzeltme sürecine dönüşür
- Sussman bu yöntemi “neredeyse doğru bir planı debug ederek problem çözme” diye adlandırır
- Elektrik filtresi tasarımı örneği bu stratejiyi gösterir
- 30Hz ile 3kHz arasında tepkiye sahip bir filtre yapmak için sistem fonksiyonu çarpanlarına ayrılır
- Direnç ve kapasitörler birleştirilerek gerekli alt devreler kurulur
- Ancak her alt devrenin “akım çıkmaz” varsayımı olduğundan, birlikte bağlandıklarında loading bug oluşur
- Amplifikatör yaması bazı durumlarda bu sorunu çözebilir
- Her hata eğlenceli değildir
- Sussman, C ve C++’ın tuzaklarla dolu olduğunu söyleyerek eleştirir
- Bellek yönetimi hataları yüzünden sık sık yeni kernel gerekmesi durumunu da C ile yazılmış kodlarla ilişkilendirir
- Python’da da
{}’nin sözlük olmasına karşın{1}’in set olması, tuple’ın parantezle değil virgülle tanımlanması gibi tutarsızlık örnekleri verir
Otomatik türev alma ve çalıştırılabilir fizik
- 1992’de Sussman, Caltech’te Kip Thorne’un grubuyla zaman geçirerek genel görelilik öğrendiğini ve programları bilgiyi saklama ortamı olarak kullandığını söylüyor
- Hewlett-Packard’ın kayan nokta çipi tasarımcısı Dan ile fonksiyonların türevlerini düşünürken ileri kip otomatik türev almayı (forward-mode automatic differentiation) bağımsız olarak yeniden keşfetti
- Amaç, fonksiyonun içine bakan sembolik türev ya da sayısal yaklaştırma olmayan bir yöntemdi
- Temel nokta chain rule idi
- Sayılar, sonlu bir kısım ve sonsuz küçük bir kısım içeren differential object’lere genişletildiğinde, fonksiyon bileşiminde chain rule otomatik olarak işler
- Scheme kullandığı için ilkel aritmetik operatörlerini differential object’lere uyacak şekilde yeniden tanımlayabildi; Sussman bunu bir “hack attack” olarak bir gecede uyguladı
- Sonrasında birçok kişi yüksek mertebeden fonksiyonların türevleri, çoklu türevler ve Scheme’in ilkel işlemlerinin dinamik olarak genişletilmesini iyileştirmeye katkıda bulundu
- Abelson, çoklu türevlerin doğru teorisini düzenlemeye yardımcı oldu
- Jeff Siskind, Barak Pearlmutter ve Alexey Radul, yüksek mertebeden fonksiyon türevlerindeki incelikli hataları debug etti
- Hansen, Scheme’in ilkel işlemlerini verimli biçimde dinamik olarak genişletmenin yolunu tasarladı
- Bu çalışma, Jack Wisdom ile birlikte kullandığı Scmutils sistemine uzandı; klasik mekanik ve diferansiyel geometriyi öğretmek ve araştırmak için kullanıldı
- Sussman ve Wisdom’ın 『Structure and Interpretation of Classical Mechanics』 kitabı, hesaplamalı tekniklerle klasik mekaniğin anlaşılmasını netleştirmeyi amaçlar
- Geleneksel Lagrange denklemi gösterimi, kültürel bilgi olmadan belirsizdir ve fonksiyonların tipleri açısından da sorunludur
- Fonksiyonel gösterim ve Scheme koduyla yazıldığında matematiksel fikirler açık ve çalıştırılabilir programlara dönüşür
- Harmonik osilatör örneğinde kütle, yay sabiti ve konum için doğru hareket denklemleri ile açısal frekans ilişkisi hesaplanır
Paylaşıldığında tamamlanan keyif
- Sussman programlamanın keyfini birkaç başlıkta özetler
- Farklı dünyalar arasındaki derin benzerlikleri keşfetme keyfi
- Filozofların uzun süredir düşündüğü sorunlarla gerçek çalışma içinde karşılaşma keyfi
- Hataların izini sürme avının keyfi
- İyi fikirler ve soyutlamalar keşfetme keyfi
- Programlarla başka disiplinleri açık hâle getirme keyfi
- Programlamanın eğlencesi, yapılan iş başkalarıyla paylaşıldığında tamamlanır; free/libre software kullanmayı ve yazmayı önerir
- Sussman, Zoom üzerinden kayıt yapmak zorunda kalmış olmasından üzüntü duyduğunu, okunabilen, değiştirilebilen ve yeniden paylaşılabilen yazılımlar istediğini söyler
- Özgür yazılım ve yazılım özgürlüğü konusunda GNU’nun özgür yazılım felsefesine bakılmasını önerir; Free Software Foundation’a katılım ve bağış çağrısı yapar
1 yorum
Hacker News görüşleri
Şu kısım gerçekten çok iyiydi: “Programları bir şeyi hatırlama biçimi olarak yazıyorum. Benim hafızam, yazdığım programlardır. Matematik, fizik, biyoloji gibi şeyleri öğrenip bunları ifade eden programlar yazarsam, sonra dönüp okuduğumda belirsiz olmaz ve anlaması kolay olur; yani bilgiyi bu şekilde saklamış olurum.”
https://www.infoq.com/presentations/Expression-of-Ideas/
Yukarıdaki alıntıyla çok yakın bir tema taşıyor ve programlamanın matematik, fizik gibi alanları daha derinlemesine anlamaya nasıl yardımcı olduğunu ele alıyor.
Örneğin ağrı kesicilerin nasıl çalıştığını anlamak, keylogger veya man-in-the-middle saldırılarını anlamaya yardımcı olabilir; mitoz sırasında DNA’nın “dilbilgisi denetimi”ni görmek de derleme süreçleri hakkında genel bir kavrayış sağlayabilir.
Yavru köpeklerin gördüğü her şeyi yutma eğilimi, bağışıklık sistemine çevre hakkında bol miktarda test verisi sağlamak gibidir; bu da makine öğrenmesine benzer ve siber güvenlikteki pek çok kavram da biyoloji üzerinden anlaşılabilir.
Görsel düşünen biri olduğum için matematiği gerçekten anlamakta zorlanıyordum ama kod yazmak, zihnimde resimler ve ilişkiler kurmamı sağladı.
Bunu küçük yaşta keşfetmiş olmam büyük şanstı; yoksa yolumu kaybederdim diye düşünüyorum.
Problem, karar, gerekçe, dayanak olan olgular ve değerlendirilen alternatiflerin hepsi bilgidir; programlama diline yazılan her komut da bir karardır.
Yazılım tasarımı o kadar uzun sürebilir ki önceki kararlar ve bağlam unutulur; insanlar ayrılır, bilgi kaybolur ve yeni gelenler bilgi eksiğiyle başlamak zorunda kalır.
Bilgisayarın kaynak kodu anlamasını sağlamak zor kısım değildir; asıl zor olan, başka insanların ne yapıldığını anlayabilmesi ve daha iyi, daha hızlı çalışabilmesidir.
Yalnızca kafa ve hafıza yetmediğinde, yazı, baskı ve yazılım gibi teknolojilerin yardımıyla daha büyük bilgi kümelerini hatırlayıp düzenlemek gerekir.
Matematikte en büyük sorun da, hata yapmayacağıma güvenememem ve hata bulacağıma da güvenemememdi.
Derleyici ya da yorumlayıcı ise bunu fark etmemi sağlıyor.
Yıllar önce NYU’nun bodrum katında yaklaşık 20 nörobilim doktora öğrencisiyle birlikte bir Sussman konuşmasına katılmıştım.
Yapay zeka yorumlanabilirliği moda olmadan çok önce bu konudan söz ediyordu.
Bir soru sormuştum; odada elektrik mühendisi kökenli biri olduğunu anında sezdi, yan tahtaya gidip bir işlemsel yükseltecin nasıl çalıştığının ilk ilkelerden çıkarılabileceğini gösterdi.
Adamda inanılmaz bir enerji ve zeka vardı; kesinlikle derin bir izlenim bıraktı.
Videoyu henüz izlemedim ama SICP’nin ithafındaki, Sussman ve Abelson’ın kullandığı Alan J. Perlis alıntısı hemen aklıma geldi.
Bilgisayar biliminde hesaplamanın eğlencesini korumanın çok önemli olduğundan ve ilk zamanlarda işin gerçekten eğlenceli olduğundan bahsediyor.
Müşteriler bazen zarar gördü ve bu şikayetleri ciddiye almaya başladık, ama makinenin başarılı, hatasız ve kusursuz kullanımından yalnızca bizim sorumlu olduğumuz görüşünü kabul etmiyor.
Asıl sorumluluğumuzun makineyi zorlamak, onu yeni yönlere itmek ve eğlenceyi canlı tutmak olduğunu; bilgisayar biliminin eğlence duygusunu kaybetmemesini umduğunu ve misyoner ya da İncil satıcısı gibi davranmamamız gerektiğini söylüyor.
Başarılı hesaplamanın anahtarının sadece bizim elimizde olduğunu sanmamak gerektiğini, elimizdeki şeyin zeka olduğunu; yani makineyi ilk gördüğümüz andan daha fazlası olarak görebilme ve onu daha büyük bir şeye dönüştürebilme yeteneği olduğunu vurguluyor.
Çoğunlukla fasulye sayma programları yazan geri kalan herkes için, maaşı ödeyenlerin gözünde tek bir fasulyenin bile kaybolmaması, bizim ne kadar eğlendiğimizden ya da sınırları ne kadar genişlettiğimizden çok daha önemlidir.
Yani bu bir bug değil, küçük bir eğlence paketi /s
Daha iyi bir başlık muhtemelen “Akademik bilgisayar bilimi eğlencelidir, ya da eğlenceli olmalıdır” olurdu.
Asıl fikir; benzetmeler bulmanın, felsefi düşünmenin, hata ayıklamanın, iyi fikirler üretmenin ve açıklık kazanmanın eğlenceli olduğu. Ama bu daha çok, böyle şeyler yapmak için maaş alan bir profesörün lüksü gibi duruyor; “müşteri bunu hafta sonuna kadar istiyor” dünyasına ise, hata ayıklamanın tartışmalı keyfi dışında pek uymuyor.
“Programlama”nın çoğu muhtemelen kaynakçılık gibi, meslek okulunda okutulan bir alan olarak görülmeli.
Yeni kaynak teknikleri geliştirmek yüksek lisans seviyesi bir araştırma konusu olabilir ama kaynakçıların ve programcıların çoğu, iyi bilinen araçlarla ve görece basit sistemlerle çalışır.
Meslek okulu öğrencisi, MIT/GNU Scheme öğrenip meslek hayatında bir daha hiç kullanmayacağı bir şeye zaman harcamak istemeyebilir; ama akademik bir öğrenci için bu, bir dilbilim öğrencisinin Linear B okumayı ve yazmayı öğrenmesi kadar tatmin edici olabilir.
Her iş eğlenceli olabilir ama sonunda daha belirleyici olan şeyler; iş arkadaşlarının ve yöneticilerin yetkinliği ile duygusal dengesi, çalışma alanının tasarımı ve güvenliği, yaşanabilir bir ücret ve özensiz işlerin görmezden gelinip gelinmediğine dair kurum kültürü gibi koşullardı. Endüstriyel kontrol sistemleri programlama gibi diğer uzmanlık alanlarında da durum benzer.
Meraklı, düşünceli ve eğitimli insanların, kendi kendine öğrenmiş olsalar da olmasalar da, her meslekte bu özelliklere sahip olmayanlardan daha iyi iş çıkardığını fark edersiniz.
Çok uzun zaman önce kaynakçı olarak çalıştığım dönemde de zeki, motive ve meraklı insanlar, sadece zamanı dolduranlardan daha iyiydi.
Bu yüzden programlamanın kaynakçılığa benzemesine katılıyorum ama kastedilen anlamda değil.
SICP, Pascal ya da C ile hackleyen akranlarımın yanında; kod, soyutlama ve modülerlik hakkında düşünme biçimimi tamamen değiştirdi
Lisp/Scheme ile problemin zihinsel modelini kurabiliyordum; buna karşılık akranlarım soyutlamayı kafalarında yapıp ardından düşük seviyeye odaklanmayı gerektiren bir dilde bunu gerçekleştirmek zorunda kalıyordu
Bu yüzden SICP ile erken yaşta tanışmış olmaya sonsuza dek minnettarım
Hangi dilde programlama yaptığınıza bağlı olarak bu iş daha eğlenceli ya da daha rahat olabilir
C++ ile muhtemelen hiçbir zaman gerçekten rahat hissedemeyeceğim
SICP yazarlarından birinin programlamaya bakışını dinlemek güzel; ilk birkaç dakikadaki anekdotlar da hoş
Ertesi gün Sussman'la görüşeceğimi ve kitabın mutlaka gerektiğini söyleyince çalışan Harvard co-op'u aradı; orada stokta bir kopya olduğu söylenince Uber'e atlayıp Harvard kitapçısına giderek SICP'yi satın aldım
Ertesi gün MIT'deki Sussman ofisine gittiğimde tesadüfen Abelson da oradaydı ve tam çıkmak üzereydi; böylece ikisi de SICP nüshamı imzaladı
Sussman ayrıca, “15 dakika daha erken gelseydin eşim de imzalardı!” dedi; o ana kadar eşinin SICP'nin düzeltmeni olduğunu bilmiyordum
Bu iki büyücüyle ve az önce imzalatılmış mor kitabımla çekilmiş harika bir fotoğrafım da var
Bu videoyu bir an önce izlemek istiyorum
SICP'yi henüz gerçekten çalışmış değilim ama kitabı ödünç aldım ve ev tadilatı yaparken dersleri dinledim
SICP derslerindeki, karmaşık şeyleri anlamaya dair Sussman alıntısını mimarlıkla ilgili sunumlarıma sık sık koyuyorum; insanların her zaman çılgınca not aldığı slayt bu oluyor
Dürüst olmak gerekirse yıllarca programlamayı sevdim; bir dönem en büyük hobimdi de
Yeni diller veya yazılımlar dener, programlama kitapları okur, libera/freenode gibi çeşitli sohbetlere katılırdım
Ama freelancer olduktan ve daha dar bağlamlarda hızla yeterince iyi kod teslim etmeye odaklandıktan sonra bu tutku azaldı
Bir mühendis olarak bu genel olarak iyi bir şey olabilir ama günlük işimdeki eğlence ve öğrenmenin büyük kısmı kayboldu
Freelance işler ve danışmanlık genelde sorun çözme, hatta sorun giderme gibi; mesele problemi mümkün olduğunca çabuk ortadan kaldırmak ve zarafet şart değil
Eğer araçlar üreten bir yapıcı olmak istiyorsanız bunun freelance işlerde pek gerçekleşeceğini sanmıyorum; ama danışman rolüne geçerseniz mümkün olabilir
Danışmanlığı daha uzun vadeli ilişkilere yakın görüyorum; bu yüzden bir sonraki adım olarak düşünmeye değer