- Leslie Lamport, LaTeX'in ilk geliştiricilerinden biri ve dağıtık sistemler alanının öncülerinden biri. 2013 Turing Ödülü sahibi
- SCaLE 22x açılış konuşmasında soyutlamanın önemini vurgulayarak, çoğu programcının kodlama ve dillere odaklandığını; ancak kodlamadan önce soyut düşünme ve tasarımın asıl kritik nokta olduğunu belirtiyor
Sunum özeti
- Benden eşzamanlılık (Concurrency) hakkında konuşmamı bekleyebilirsiniz, ancak bu konuda yeni söyleyecek bir şeyim yok
- Ancak "eşzamanlı program yazma"ya dair içgörüler, genel olarak tüm programlamaya da uygulanır
- Bu konuşma genel olarak programlama üzerine
Algoritma vs. program
- Algoritma: Dilden bağımsız soyut bir fikir. Programdan daha soyut ve daha üst düzey bir kavram
- Program: Algoritmanın belirli bir dilde somutlaştırılmış hali. Programlama dilleri, algoritmaları ifade etmek için fazla karmaşık
- Algoritmalar çalıştırılmaz ve genellikle kısa ve basittir
- Özellikle eşzamanlılıkla ilgili kodlarda önce doğru algoritmanın tanımlanıp sonra uygulanması gerekir
Dizi maksimumu örneğiyle soyutlama
- Basit bir problemde bile "ne yapılacağının (What)" açıkça tanımlanması gerekir
- Örnek: "bir tamsayı dizisinin maksimumunu döndür" → "tüm elemanlardan büyük ya da eşit olan en küçük sayıyı döndür"
- Boş dizi durumu da önceden tanımlanmalıdır (ör.
-∞ kullanımı)
- Bu tür açık tanımlar sayesinde daha basit ve daha sağlam algoritmalar (How) elde edilebilir
Program çalışması bir durum akışıdır
- Programın çalışması yalnızca komutların sıralı yürütülmesi değil, durumların (state) ardışıklığıdır
- Her durum geçişi, kodun bir bölümünün yürütülmesini ifade eder
- Bu bakış açısı, algoritmanın doğruluğunu kanıtlarken önemlidir (değişmezler/invariantlar kullanımı gibi)
Karmaşık sistemler için araç: TLA+
- Soyutlamayı hassas biçimde ifade etmek için kesin bir dil gerekir
- TLA+ bu amaç için tasarlanmış bir araçtır
- Amazon Web Services, TLA+ ile ciddi tasarım hatalarını önceden tespit etti
- Rosetta uzay aracının işletim sistemi Virtuoso da TLA+ tabanlı olarak tasarlandı; ortaya çıkan kod sade ve kararlıydı
Eksik spesifikasyonlarda bile soyutlamanın rolü
- Örnek: pretty printer'da hizalama ölçütü öznel olabilir
- Buna rağmen soyut bir kural setinin önceden belirlenmesi, hata ayıklama ve bakım açısından önemlidir
Yazı ve düşünce ilişkisi
- Düşünceleri yazıya dökmek, düşünceyi netleştirir
- Soyutlama sadece zihinde yapılan bir şey değildir; yazıyla ifade edildiğinde etkili olur
- Lamport, matematik eğitiminin kendi soyutlama becerisini geliştirdiğini söylüyor
- Matematikçiler, programcılara soyutlamayı öğretebilir
Kütüphaneler ve hatalara bakış
- Konuşmanın ikinci bölümü olan "programlarda neden hata olmak zorunda" kısmında karmaşıklık sorunu ele alınıyor
- Modern yazılımlar çok sayıda kütüphaneye bağımlı, ancak bunların dil bağımsız, kesin açıklamaları çoğu zaman yetersiz
- Bu da entegrasyon sürecinde beklenmedik hatalara yol açıyor
- Örnek: Kendi TLA+ ders sitesi üzerinde yaşadığı JavaScript hata ayıklama deneyimi
- Durum temelli bakış açısı, bu karmaşıklığı anlamakta faydalı
Soru-cevapta ele alınan başlıklar
- Yapay zekanın soyutlama üzerindeki etkisi
- Açık kaynak ile akademi arasındaki kopukluk
- Geliştiricilerin biçimsel tanımı (formal definition) ihmal etmesi gerçeği
- Hâlâ en önemli şey: "kodlamadan önce düşünmek"
Sonuç: Programlamanın özü düşüncedir
- Lamport, yalnızca kodlamaya değil; soyut düşünceye ve biçimsel spesifikasyonlara öncelik verilmesi gerektiğini savunuyor
- Başlangıçtaki çaba büyük olsa da sonuçta daha sağlam ve bakımı daha kolay yazılımlar ortaya çıkıyor
- Kodlama, programlamanın yalnızca bir parçası; gerçek programlama doğru algoritma ve soyutlamayla başlar
- Sistem karmaşıklığı ve eşzamanlılığın arttığı günümüzde soyutlama vazgeçilmez bir yetenek ve programcıların düşünme ve soyutlama pratiğine ihtiyacı var
5 yorum
Ben de bu yazıya katılıyorum
Sorunu soyutlanmış durum değerleriyle tanımlamanın problemi keşfetmede faydalı olduğunu düşünüyorum ve diyagramlar gibi araçlarla durumun görselleştirilmesi ya da Unreal Blueprint veya workflow gibi görsel ve açık durum yönetimi araçları geliştirmeye çalışıyorum.
Galiba önce dili incelemem gerekecek
Hesaplama teorisi alan derslerini hatırlatan bir yazı! Programlama yapanlara bunu incelemelerini tavsiye ederim.
TLA'nın ne olduğunu merak ediyorum
Bakmam gerekecek
Ben de merak edip baktım.
TLA+ - programları ve eşzamanlı/dağıtık sistemleri modellemek için gelişmiş bir dil
Hacker News görüşü
Demo scene'in 'coder'ları kendilerini böyle adlandırır ve bundan gurur duyar; ayrıca çoğu zaman mükemmel 'programmer'lar ve 'software engineer'lar da olurlar. Coder, programmer, software engineer ya da hangi adı kullanırsanız kullanın, önemli olan bilgisayarın istediğiniz gibi çalışmasını sağlamaktır
Gelecek yılın keynote'unun "vibing kodlama değildir, programlama da değildir...; bazen biraz çalışan bir çöp piramidi" olacağını düşünüyorum. Dijkstra'nın bunu görmemiş olması neyse ki iyi. 80'lerde ailemin oturma odasında bile öfkeliydi. 'Vibe coding'i görse nasıl tepki verirdi hayal bile edemiyorum
Leslie Lamport'un SCaLE 22x keynote'u: düşün, soyutla, sonra kodla. Lamport, kodlamadan önce düşünme ve soyutlamayı vurgulayan, programlamaya yaklaşımda temel bir değişim savundu; bu da önemsiz olmayan tüm kodlar için geçerli
Programlama, dikkatli tasarımın (soyutlama) ardından uygulamanın (kodlama) geldiği bilinçli bir süreç olmalı; açık spesifikasyonlara ve durum dizileri ile değişmezler üzerinden program davranışını anlamaya odaklanmalıdır. Düşünmek her zaman daha iyidir
Matematik profesörü, kavramları daha kesin ve makine tarafından okunabilir biçimlere dönüştüren her eyleme kodlama diyor. Bu, yalnızca programlama dilinde bilgisayarın yapmasını istediğinizi yazmayı değil, veriyi encode etmeyi de içeriyor. "Encode" kelimesi bunu açıkça gösteriyor. İkili ağacı doğal sayıya dönüştüren bir kodlama yöntemini tanımlama ödevi veriyor. Kodlama kelimesi fazla muğlak olduğu için çok kullanmıyor
Lamport, "ne" ile "nasıl"ın ayrılması gerektiğini savunuyor. Ancak çoğu problemde programın "ne"si ile "nasıl"ı bir ölçüde iç içe geçmiyor mu diye merak ediyorum. Örneğin performans değerlendirmeleri "ne"nin mi, yoksa "nasıl"ın mı bir parçası?
İlginç bir özet: algoritma program değildir, programlama dilinde yazılmamalıdır ve basit olmalıdır. Buna karşılık program, potansiyel olarak büyük veri kümelerinde hızlı çalışması gerektiği için karmaşık olmalıdır. Bu özellikle birden fazla CPU üzerinde çalışan eşzamanlı programların yürütme sıralarının farklı olması nedeniyle tartışılıyor
Programı, kodlamadan önce düşünme gerektiren kod ve kodu okumak istemeyen insanların kullanacağı kod olarak tanımlıyor. Bu konuşma uzun zamandır yapılıyor. En küçük öğeyi bulmayı basitleştirme örneği, John Ousterhout'un kitabındaki "Define Errors Out of Existence" ile birebir örtüşüyor
Yorum bölümünün çoğunlukla mesajı anlamayan insanlarla dolu olması ironik bir durum. Leslie Lamport'un asıl noktası, soyut düşünme becerisini geliştirmenin daha iyi programlara yol açtığıdır. Matematiksel ve mantıksal anlamdaki soyutlama, ilgisiz tüm ayrıntıları ayıklamayı sağlar. Yapay zeka yönlendirmeli yazılım geliştirme için de aynı şey geçerli
Titizlik içeren her konuda bekleneceği gibi, birçok kişi yalnızca başlığı okuyup olumsuz tepki veriyor. Hacker News'teki hacker, problem çözebilen yetkin bir programcı olabilir. Artık bu, "You're a Hack" anlamında, beceriksiz ve düşük kaliteli sonuçlar üreten biri anlamına da gelebiliyor
Bu konuşma ve tartışma aşırı derecede ayrıntıcı
Şu anda ACM'de iyi bir makale var; soyutlamanın ne olduğu konusunda hemfikir olunmasa da yine de çok yararlı olduğunu söylüyor. Önemli noktanın nerede olduğu konusunda büyük ölçüde hemfikirim. Tam olarak ne olduğu ve neden önemli olduğu konusunda ise aynı fikirde değilim. Yine de çok ilham verici olabilir ve bu başlı başına değerlidir
Hacking, coding değildir; programming de değildir; software development da değildir; software engineering de değildir. Ancak günün sonunda birçok kişi bu terimleri neredeyse birbirinin yerine kullanıyor ve kişisel tanımlardaki farkları vurgulamak çoğu zaman üretken bir zaman kullanımı olmuyor