1956 Ocak Ayı sayısından "Otomatik Kodlama Teknikleri" isimli bir yazıdan, günümüz, "Kodlama bitti. Yazılım öğrenmeye gerek yok çünkü yapay zeka ile her şeyi yapabiliriz" diyenlere cevap olacak cinsten bir pasaj ;-)
Yazarlar: Charles W. Adams (Pittsburgh, Pa.) ve Bruse Moncreiff (Santa Monica, Calif.)
I. Charles W. Adams'tan Editöre Mektup
Geçenlerde, ticari veri işleme için otomatik kodlama tekniklerinin geliştirilmesinde hangi yolların izlenmesi gerektiği konusunda güncel görüşleri kapsayan gayriresmî bir anket yaptım. Aldığım yanıtlardan biri, RAND Corporation'daki eski bir dostum olan Bruse Moncreiff'ten geldi. Hatırlayacağınız üzere Bruse, Prudential Sigorta Şirketi'ndeki ilk araştırmalardan bu yana ticari veri işleme süreçlerinin içinde yer alan bir isimdir.
Onun bu uzun ve samimi mektubu, bence ilgi çekici gözlemler ile birçok parlak fikri ve tartışmalı görüşü bir araya getiriyor. Bu nedenle, mektubu okurlarınızla paylaşmak isteyeceğiniz umuduyla kendisinden yayınlama izni aldım.
Bu izni verirken bana şöyle yazdı: "Önceki mektubumun ciddi bir değeri olması pek mümkün görünmediğinden, içinde muhtemelen benim bile fark etmediğim mizahi bir yan olduğu sonucuna varıyorum."
Ayrıca, "Otomatik Denetleyici" (Automatic Supervisor) için hazırladığı taslak akış şemasının, bağlayıcılar dahil 329 kutuya ulaştığını, rutin kodlamayı IBM 702 için tamamladığını ve bu konuda muhtemelen Batı Ortak Bilgisayar Konferansı'nda bir tebliğ sunmayı umduğunu belirtti.
II. Bruse Moncreiff'ten Charles W. Adams'a Mektup
Ticari prosedürlerin otomatik bilgi işleme ekipmanlarına uygun hale getirilmesi konusundaki görüşlerim, kuşkusuz gereksiz yere felsefi ve dolayısıyla anlaşılması güçtür. Tartışmanın nedenini görebilmeniz için önce ana tezimi sunmak faydalı olabilir:
Bu planlama sürecinin en zor ve en önemli kısmı kodlamadan ziyade problemin mantığıdır.
Bunu muhtemelen mide bulandıracak kadar çok duymuşsunuzdur; ancak asıl aydınlanma, tezin ifadesinde değil, savunulmasındadır. Bu savunma şu maddeleri içermelidir:
- Mantık ve matematiğin eşdeğerliği.
- Arazi ölçümü ve astrofiziğin (ticari operasyonlara kıyasla) göreceli basitliği.
- Önermeler hesabı ve basit sınıflar teorisinin ötesindeki mantık alanlarında karşılaşılan teorik zorluklar.
- Ticari işlemlerin tarihsel olarak erkenden "servet birikimi" ile ilişkilendirilmiş olmasının oluşturduğu talihsizlik; bu durum, "bağıntılar teorisi" yerine "sınıflar teorisinin" (aritmetik bunun bir dalıdır) gelişmesine yol açmıştır.
- İnsanlığın geri kalan kısmının (para kazanacak kadar zeki olmayanların), deneyimin daha zorlayıcı olan "ayrık süreçleri" yerine, "sürekli süreçler" gibi basit yönleriyle meşgul olması.
- İnsanların sorunları için çaba göstererek etkileyebilecekleri nedenler yerine, kontrolleri dışındaki nedenleri suçlamaya yönelik nevrotik eğilimi. (Bu nedenle toplumsal ilişkiler hesabı yerine astrolojiye ilgi duyulması.)
Ara Not: Bunu ilk bakışta okununca anlaşılması zor maddeler gibi görünebilir ama arkadaş esasen şunu diyor: Coding zor değil, asıl zor olan mantık.
Konudan biraz uzaklaşmış gibi görünsek de en azından görüşlerimin gereksiz yere karmaşık olduğunu kanıtlamış oldum.
Özetlemek gerekirse (elmalarla armutları toplama pahasına): Ticari operasyonların mantığı, fiziksel olaylarınkinden daha karmaşıktır. Ancak ticari alanda, doğa bilimlerinde sahip olduğumuz standart gösterim sistemlerine ve işlem tekniklerine sahip değiliz. Kapatmamız gereken birkaç yüzyıllık bir açık var; ticari operasyonların bilimsel hesaplamalardan daha karmaşık olduğu yönündeki klişeyi destekleme sebebim de budur.
Kodlama mı, Mantık mı?
Esas itibarıyla ihtiyacımız olan şey, idari ve ticari kontrol süreçleri için tutarlı ve verimli mantıksal tasarımlar üretecek yöntemlerdir. Yakın zamanda katıldığım bir kodlama dersinde yaşanan basit bir örnek bu noktayı güçlendiriyor:
Öğrencilerin dikkatini üzerinde çalışılan makinede tutmak için, problem çok detaylı bir akış şeması şeklinde sunulmuştu.
Bu şema birkaç sınıfta kullanılmış ve üç kez revize edilmişti. Dört sayfa tutuyordu ve kodlanması yaklaşık 500 komut gerektiriyordu. Sınıfın daha "dikkatli" üyeleri, mantıkta dört ciddi hata tespit etti; bunlardan biri problemin çalışmasını tamamen engelleyecek nitelikteydi. Diğer hatalar ise verimlilik ya da istenen sonuçlara ulaşma ile ilgiliydi. Öte yandan, sınıfın daha az deneyimli üyeleri akış şemasını takip edebilmiş ve neredeyse hiç sorun yaşamadan kod yazmışlardı.
Bu örnek neyi kanıtlar? Belki hiçbir şeyi; ancak deneyimli insanların bir problemin mantığıyla, deneyimsiz birinin kodlamayla yaşadığından daha fazla sorun yaşadığı inancını destekliyor. Tabii makinenin ne yapacağını ve hangi sonuçların istendiğini belirleme meselesi ise bambaşka ve daha acıklı bir hikaye.
Kişisel Not: 1956'da yazılmış bu pasaj, bugün "Yapay zeka her şeyi halleder, kodlama öğrenmeye gerek yok" söyleminin tam karşısında duruyor. Araçlar değişiyor — assembly'den COBOL'a, program generator'lardan Copilot'a — ama temel gerilim hep aynı kalmış: Asıl güçlük, makineye ne yapması gerektiğini doğru anlatabilmekte. Kodlamayı bilmemenin sizi kurtaramayacağı şey tam da bu: problemi anlamak, mantığını kurmak ve hataları görebilmek. Yetmiş yıl önceki bu gözlem, bugün hâlâ tazeliğini koruyor.