Dijkstra’nın “Doğal Dil Programlamanın Ahmaklığı” Üzerine
(cs.utexas.edu)- Programlamanın zorluğunu biçimsel sembollere bağlayan bakış açısı, makinenin doğal dili anlaması hâlinde insanın yükünün azalacağı yönünde yanlış bir beklenti doğurur
- İlk makine dillerinin tehlikesi yüksek seviyeli programlama dilleri ile kısmen hafifletildi, ancak yanlış sonucun hata mesajına dönüşmesinden ibaret olan bu değişime rağmen kesin talimat gerekliliği özde varlığını sürdürdü
- Doğal dil arayüzleri emeği paylaşan bir çözüm değil; insan ile makine arasındaki işbirliği ve iletişim maliyetini artırarak her iki tarafın yükünü de büyütebilir
- Matematiğin gelişimi, Vieta, Descartes, Leibniz ve Boole gibi isimlerin kurduğu biçimsel sembol sistemlerinin karmaşık düşünceyi ele almanın temel araçları olduğunu gösterir
- Doğal dil programlama temel girdi/çıktı biçimi olarak benimsenmiş olsaydı, bilgisayar bilimi muhtemelen sonunda kullanılabilir bir biçimsel sisteme geri dönmek için dolambaçlı ve uzun bir yola dönüşürdü
Doğal Dil Programlamaya Yönelik Beklentiler ve Yanılgılar
- Otomatik hesaplamanın ilk dönemlerinden beri bazı insanlar, programlamanın biçimsel sembollerin gerektirdiği dikkat ve kesinliği istemesini bir kusur olarak gördü
- Makinenin yanlış komutları bile katı biçimde uygulamasını sorun saydılar ve küçük bürokratik hataları reddeden daha “sağduyulu” bir makine beklediler
- Makine dili, neredeyse hiç artıklık içermediği için insan ile makine arasında tehlikeli bir arayüzdü
- Buna karşılık yüksek seviyeli programlama dilleri geliştirildi
- Zamanla birçok küçük hata, yanlış sonuç üretmek yerine hata mesajıyla sonuçlanacak şekilde iyileştirildi
- Ancak programlama dillerine karşılık gelen soyut makine hâlâ kendisine verilen komutları sadakatle yerine getiren bir otomattır ve anlamsız komutları da çalıştırabilir
- Makineye doğal dille talimat verme önerisi, makineyi daha karmaşık hâle getirse bile insanın yükünü azaltabileceği düşüncesine dayanır
- Bu düşünce ancak “biçimsel sembol kullanma zorunluluğunu” zorluğun asıl nedeni saydığınızda makul görünür
- Arayüz değişikliği emeği yalnızca paylaştırmak değildir; arayüzün üzerinden geçen işbirliği ve iletişim maliyetini de ekler
- Deneyimsel olarak arayüz değişikliği iki tarafın da iş yükünü ciddi biçimde artırabilir; bu yüzden “dar arayüz” tercihi güçlenir
Biçimsel Sembollerin Düşünceyi Genişletme Biçimi
- Matematik tarihinde doğal dile ve şekillere dayalı yaklaşımlar tekrar tekrar sınırlarına çarpmıştır
- Yunan matematiği dilsel ve şekil-merkezli etkinlik içinde kalarak durakladı
- Moslem “algebra”, sembol kullanımını kısa süre denedikten sonra tekrar retorik yönteme dönerek ortadan kayboldu
- Batı Avrupa, Vieta, Descartes, Leibniz ve daha sonra Boole gibi isimlerin bilinçli olarak tasarlanmış biçimsel sembolleri sayesinde Orta Çağ skolastisizminin dilsel kesinlik denemelerinden uzaklaştı
- Biçimsel metinlerin avantajı, geçerli işlemlerin yalnızca birkaç basit kuralı sağlamasının yeterli olmasıdır
- Bu düzenlilik, doğal dilde kaçınılması zor olan çeşitli anlamsızlık türlerini dışlayan bir araç hâline gelir
- Biçimsel sembol kullanımı bir yük değil, neredeyse bir ayrıcalıktır
- Biçimsel semboller sayesinde eskiden yalnızca dahilerin yapabildiği şeyleri öğrenciler de öğrenebilir
- 1977 tarihli bir teknik raporun önsözündeki “açıklık adına mantıksal bağlaçların standart sembollerinden bile kaçındık” cümlesi, bu yanlış anlamanın tek bir kişiyle sınırlı olmadığını gösterir
- Doğal dilin “doğallığı”, anlamsızlığı açıkça belli olmayan cümleleri kolayca üretmeye elverişli olması anlamına da gelir
Yalnızca Doğal Dile İzin Verilen Bir Dünyada Bilgisayar Bilimi
- Eğer bilgi işleme aygıtlarının girdi/çıktısı en başından beri yalnızca ana dil üzerinden gerçekleşseydi, bilgisayar bilimi yeterince tanımlanmış biçimsel sistemlere ulaşmak için bir tür “black art”a daha yakın olurdu
- Arayüzü kullanılabilir bir düzeye kadar daraltmak için dünyanın dört bir yanındaki zekâ birikimi gerekirdi
- İnsanlık tarihi dikkate alındığında bunun yeniden binlerce yıl sürmesi bile mümkün olabilirdi
- Batı’daki eğitim akışının zihinsel disiplinden uzaklaşmasıyla insanların kendi dillerini kullanma becerisinin büyük ölçüde düştüğüne dair bir kaygı da eklenir
- Bilimsel makalelerde, teknik raporlarda, devlet yayınlarında bile dikkatle okunduğunda çok sayıda anlamsız ifade bulunduğu örnek verilir
- Bu olgu “The New Illiteracy” olarak adlandırılır ve doğal dil programlamasının başarısızlığını öngörecek teknik kavrayıştan yoksun destekçilere de bir uyarı olur
- Sonuç, Dutch, English, American, French, German ya da Swahili fark etmeksizin doğal dille programlanan bir makinenin, yapılması kadar kullanılması da zor olacağı yönündeki kuşkuyla biter
1 yorum
Hacker News yorumları
Burada LLM’leri savunmak güzel, ama tersini denemek nasıl olur diye düşünüyorum. Orta karmaşıklıkta bir proje alıp sevdiğiniz LLM ile kodu tekrar doğal dile dönüştürmek.
Kaynak koddaki davranışları ve gereksinimleri, programı yeniden üretebilecek kadar ayrıntı kaybetmeden makul biçimde açıklayabilir mi? O doğal dil açıklaması üzerinde akıl yürütmek daha kolay olur mu?
İnsanların gösterdiği vibe coding uygulamalarının genelde basit olmasının bir nedeni olduğunu düşünüyorum. Karmaşıklığı ve kesinliği yönetmenin zorlaştığı bir seviye var; düz İngilizceyle tanımlanabilir olsa bile, bu açıklamanın ölçeklenebilir, anlaşılabilir ve kesin bir dilden daha açıklayıcı olup olmadığı şüpheli.
Hukuk metinlerinin düz İngilizce olmamasının da yalnızca giriş bariyeri yaratmaktan öte nedenleri olduğunu düşünüyorum.
METAR YSSY 031000Z 08005KT CAVOK 22/13 Q1012 RMK RF00.0/000.0gibi bir şeydir.Yeni pilotlar neredeyse istisnasız “Neden bunu kelimelerle yazmıyorlar?” diye sorar; gerçekten de çoğu uçuş planlama uygulaması bu kodu düzyazıya çevirir.
Ama profesyonel pilotlar ve kontrolörler kod biçimini çok daha fazla tercih eder. Tek satır olduğu için yoğundur; formatı iyi tanımlanmıştır, bu yüzden gereken öğeyi nerede arayacağınızı tam olarak bilirsiniz; muğlak değildir, açıktır.
Matematik ve kodlama da benzer şekilde, belli bir uzmanlık seviyesinin üstüne çıkınca doğal dilin karmaşıklığı ve tekrarı, sağladığı faydadan daha pahalı hâle gelir. Bu her uzmanlık alanına uygulanıyor gibi görünüyor.
Düzyazıdan bilgiyi yeniden çağırmak çok zaman alır; uzun metinleri okuyanlar altını çizmeye, not almaya ve kendi kısaltmalarını üretmeye başlar.
Sıkıştırılmış formatlar ve soyutlamalar, çalışma belleği ve bilgi arama yükünü azaltır. Bu yüzden mesele yalnızca dilin kesinliği olmayabilir.
O cümleden gerçekten çalışan bir uygulamaya gitmek için sayısız uygulama ayrıntısı gerektiğini düşünebilirsiniz; ama yalnızca bu kadar bilgiyle bile ihtiyacımı çözen çalışan bir uygulamaya ulaşmak mümkün olabilir.
Ve bunu yeterince yapabiliyorsa, “bunu cornflower blue yapabilir misin?” gibi istekler de kolaylaşır ve kullanıcı oradan yineleyerek iyileştirebilir.
LLM’ye yalnızca ISA ve ekran sürücüsü verip assembly ile grafik uygulaması yapmasını söylerseniz hiçbir şey elde edemezsiniz.
Ama dağ gibi soyutlama yığını varsa muhtemelen mümkün hâle gelir.
LLM’leri savunmaya çalışmıyorum; doğru soyutlamalar ve yeniden kullanılabilir bileşenler sağlanırsa çok daha yakına gelebileceğimizi düşünüyorum.
Hal Abelson’ın eski bir alıntısı aklıma geliyor.
“Bu konuya yaklaşımımızın altında, ‘bilgisayar bilimi’nin bir bilim olmadığı ve öneminin bilgisayarlarla pek az ilgisi olduğu inancı yatar. Bilgisayar devrimi, düşünme biçimimizde ve düşüncelerimizi ifade etme biçimimizde bir devrimdir. Bu değişimin özü, en uygun adla prosedürel epistemoloji denebilecek bir şeyin ortaya çıkışıdır. Bu, klasik matematik alanlarının benimsediği daha bildirime dayalı bakış açısından farklı olarak, bilginin yapısını emir kipi bakış açısından incelemektir. Matematik, ‘ne olduğu’ kavramıyla kesin biçimde ilgilenmek için bir çerçeve sağlar. Hesaplama ise ‘nasıl yapılacağı’ kavramıyla kesin biçimde ilgilenmek için bir çerçeve sağlar.”
Ne kadar çok etkileyici demo ve “AI yüzünden kodlama öldü” bildirisi olursa olsun, gerçek işin büyük kısmı AI etrafındaki ön işleme, son işleme ve değerlendirmeye kayar.
Programlamayı daha erişilebilir kılması açısından iyi, ama programlamanın gerçekten yerini alamaz.
Sonunda biri bunu böyle ifade etti. Doğal dilin, insan zihninin sınırlarından kaynaklanan içsel sınırları var. İnsan zihni bazen fazla soyut ya da fazla somut düşünür; önemli ayrıntıları veya genellemeleri kaçırır.
Bir programcı olarak bizzat hissettiğim şu: Bir görevin sorunları, hatta saçmalıkları, çoğu zaman kodu kod olarak, yani katı bir sembol sistemiyle uygulamaya başladıktan sonra ortaya çıkar.
Üstelik bir şeyi doğal dille doğru biçimde açıklamak için gereken süre, çoğu zaman basitçe algoritmayı kod olarak yazma süresinden daha uzun olabilir.
Cümleleri ne kadar sık yeniden yazarız, “Aslında söylemek istediğim…” deriz ya da göndermeden önce e-postayı yeniden ifade ederiz? İnsanıyız ve ilk denemede kusursuz olmamız nadirdir.
Şimdi bu kusurlu iletişim biçimi olan doğal dili, amaçlandığı gibi değil söylendiği gibi uygulamasıyla kötü şöhretli makinelerin dili olan koda dönüştürüyoruz.
Doğal dil işleme, uygulama veya betik yazımına doğru yönde başlamak için muazzam derecede yararlıdır. Ama sonunda çeşitli yerlerde refactoring gerekebilir.
LLM’den değer elde etmek için kod ustası olmanız gerekmez; yine de kodlama becerisi hâlâ yardımcıdır ve bazen gereklidir.
/s: Çünkü henüz yeterince ileri gitmedik. İnsanlar bilgisayar programlarını doğal dille oluşturuyor, ama bunun yerine istemleri doğrudan çalıştırmaları gerekir
“Sen bir grafik sistemisin. Ekranda ne olduğunu yöneten varlıksın. Tüm programlardan ‘pencere’ oluşturma ve kaldırma istekleri alabilirsin; ayrıca daha önce oluşturduğun pencerelere metin, çizgi, daire vb. çizmen için ek istekler de alabilirsin. Öğeler herhangi bir renkte olabilir.
Ayrıca kullanıcının fareyle tıkladığı pencereyi oluşturan tarafa daha fazla tıklama bilgisi göndermelisin.
Pencere yöneticisi özel bir programdır ve sisteme bağlı tüm monitörlerde hangi pencerenin nerede gösterildiğini sana söyleyebilir”
Ve “Sen bir tic-tac-toe programısın. Ekranda ne olduğunu yöneten bir grafik sistemi var. O sisteme ‘pencere’ oluşturmasını ve kaldırmasını emredebilirsin; daha önce oluşturduğun pencerelere metin, çizgi, daire vb. çizmesini söyleyebilirsin. Öğeler herhangi bir renkte olabilir.
Çizdiğin grafikler, kullanıcının fareyle tıklayarak hamle yaptığı bir tic-tac-toe oyununu göstermeli. Kullanıcı kazanırsa…
Kullanıcının tıklama başına ücretlendirilen bir aboneliği yoksa oyuna reklam ekle”
Bu kadarı oyunun çalışması için yeterli olacaktır
Kaydetmek için başka bir istem gerekir. “Sen bir dosya sistemisin. Diskte verileri kalıcı hale getiren varlıksın…”
Ve “Sen çok görevli bir işletim sistemisin. Birden fazla LLM’e sistemin CPU ve belleği üzerinde tam denetime sahip oldukları fikrini veriyorsun. Sen…” de gerekir
Bunu gelecek yıl Nisan başında görmeyi bekliyorum
“Makine dili, neredeyse tüm fazlalık biçimlerinden yoksun olduğu için, insan ile makine arasında gereksiz derecede tehlikeli bir arayüz olarak kısa sürede tanındı. Bu farkındalığa kısmen yanıt olarak, sözde ‘yüksek seviyeli programlama dilleri’ geliştirildi ve zamanla aptalca hatalara karşı korumayı bir ölçüde güçlendirmeyi öğrendik. Artık birçok aptalca hatanın yanlış cevap yerine hata mesajıyla sonuçlanması önemli bir ilerlemeydi.”
Bana, kolektif olarak LLM programlamasına fazla hızlı atlamışız gibi geliyor. Rust’ın aptalca hataları yakalayıp nasıl düzeltileceğini çok daha net hale getirecek şekilde gelişmiş olmasını gerçekten seviyorum
Bir geliştirici olarak üzerinde çalıştığım kodun bağlamı ve kavrayışı hâlâ bende; derleyici de bariz hataları ve düzeltme yollarını söylüyor. Buna karşılık LLM kullanmak yarı zeki bir tahmin oyunu gibi geliyor
Rust derleyicisi çırağını eğiten bir usta, LLM ise ustayı düzelten kendinden emin bir mezun gibi. Rust’ın yaklaşımını çok daha fazla tercih ediyorum ve mümkünse daha da gelişmesini isterim
Doğal dil, kuralları ve komutları aktarmak için zayıf bir ortam. ABD’nin mevcut durumu buna iyi bir örnek
Hâlâ hangi yasaların ve anayasa değişikliklerinin ne anlama geldiğini tartışıyoruz. Sözcüklerin anlamı zamanla değişiyor, tarihsel bağlam da eksiliyor
Makineleri doğal dille kullanabilmek güzel olurdu, ama 80’lerin ortasından beri programlama yapan biri olarak, BASIC’ten Go’ya uzanan bilgisayar dillerinin inatçılığının iyi bir denge kurduğunu düşünüyorum. Komut veren tarafa, makinenin ne yapması gerektiğini tam olarak ifade etme konusunda yeterli sorumluluk yüklüyor
Bu iddiaya bir ölçüde katılmıyorum. Gerçek şirketlerde yeni özellik fikirleri çoğu zaman bir iş birimi sorumlusunun kafasında başlar. Bu kişi herhangi bir biçimsel dil konuşmayacaktır
Dolayısıyla nasıl bakarsanız bakın, özelliği hayata geçirmek için doğal dilden makine diline çeviri gerekir
Genelde ilk aşama olan doğal dilden biçimsel dile çeviriyi iş analistleri ve programcılar üstlenir. Öyleyse bu süreçte bilgisayardan yardım almamak için bir neden var mı?
Bu yüzden yalnızca programların doğal dille belirtilmesi gerektiği fikrine değil, biçimsel dili anlama ihtiyacımızı ortadan kaldırmanın karmaşık sistemler kurma yeteneğimizi artıracağı fikrine de karşı çıkar
Birçok “çeviri” aslında çeviri değil; mantıksal belirsizlikleri, tutarsızlıkları ve hatalı varsayımları düzeltme işidir. Dijkstra’yı ciddiye alırsak, bunların önemli bir kısmı doğal dil içinde de yapılabilir. Çünkü orada, yaşamları boyunca biçimselleştirme yapmış programcılar vardır
Matematik gibi kayda değer biçimsel düşünme gerektiren başka meslekler de var. Ayrıca eski kanıtlar bilgisayar kanıtlarına dönüştürülürken, geniş kabul görmüş birçok kanıtta delikler ve boşluklar da bulunmuştur
Tersine çevrilen çok şey yok, ama Fermat’nın Son Teoremi için hâlâ tam bir kanıtımız da yok https://xenaproject.wordpress.com/2024/12/11/fermats-last-th...
Biçimsel bir sistem içinde düşünmezseniz fikirleriniz kötüleşir. Çünkü kendi düşüncelerinizi biçimsel bir şey olarak ele almazsınız
Örnekteki “iş birimi sorumlusu” fikrinin nasıl çevrileceği konusunda muhtemelen pek bir görüşü olmazdı. Onun bakış açısından, iş birimi sorumlusunun fikri zaten biçimciliği izlemediği için sığ ve kötüdür; çevirmeye değmez
“Bilgisayarın arada yardım etmesine” izin verirseniz, makineden yeterince iyi sonuç almak için giderek daha biçimsel bir doğal dile ihtiyaç duyma sorunuyla hemen karşılaşırsınız
Programlama dilleri kadar biçimselleştirilmiş olmasa da kesinlikle vardır
Herhangi bir süreci tanımlamaya çalıştığınızda, kendiniz fark etmeseniz bile sonunda biçimselleştirme yönüne eğilirsiniz
“Pek çok aptalca hatanın yanlış cevaplar yerine hata mesajlarına yol açması önemli bir iyileştirmeydi. Bu iyileştirmeyi bile herkes sevmedi. Bazıları yok sayılamayan hata mesajlarını yanlış sonuçlardan daha sinir bozucu buldu; programlama dillerinin göreli üstünlüklerini değerlendirirken hâlâ ‘programlamanın kolaylığı’nı, fark edilmeyen hataları kolayca yapabilmekle özdeşleştiriyor gibiler.”
Kimin yazdığını bilmeseydim, bunun Rust'tan nefret edenleri tam hedef alan bir söz olduğunu düşünürdüm
Rust'tan daha güçlü değişmez koşulları tiplerle ifade edebilen Scala'yı bir süre kullandıktan sonra, bu özelliği her durumda açık bir zafer olarak görmemeye başladım. Artık “daha güçlü tipler == koşulsuz daha iyi” diye düşünmüyorum
“Hatalara izin vermemenin” bir bedeli var. Tip sistemi gerçekten katıysa keşif amaçlı çalışma epey zorlaşıyor. Hızlı yineleme imkânsız hâle bile gelebilir
Küçük bir değişiklik yüzünden tip sistemini yeniden tatmin etmek için programın yarısını baştan tasarlamak zorunda kalabilirsiniz
Bu bir ödünleşim. Diğer her şey gibi. Sağlam bir nihai ürün için iyi, ama hızlı deneylerin önünde engel
Birisi bu sorunu Rust ve oyun geliştirme bağlamında iyi açıklamış: https://loglog.games/blog/leaving-rust-gamedev/
Ama sorun yalnızca Rust'a ya da oyun geliştirmeye özgü değil
Bazı aptallık türleri zamandan bağımsız gibi görünüyor
Burada onun bahsettiği şey yorumlanan diller
Ayrıca kendisi, bugün bilgisayar bilimci denen matematikçilerden biri; “algoritmaları” matematiğin basitçe yeniden ifade edilmesine daha yakın ve bir aygıta ihtiyaç duymuyor. Gerçek bilgisayarları programlama gibi utanç verici bir faaliyete mizacı gereği düşman biri
Uygulamaları doğal dille belirtmek ve oluşturmak, bir oyun prototipine başlamadan önce oyun tasarım dokümanına sahip olmaya oldukça benziyor
Ama istediğiniz şeylerin çoğunu uyguladıktan sonra uygulamanın kendisi ölçüt hâline geliyor; GDD gerçek oyunla uyuşmadığı için genellikle çöpe atılıyor
Her değişiklikte GDD'yi okuyup özelliği uyguladıktan sonra GDD'yi tekrar senkronize etmekte ısrar etmek zahmetli ve pratikte pek iyi işlemiyor. Bunun gerçekleştiğini hiç görmedim
Bir gün yapay zeka/LLM yalnızca bir dizi prompt ile Linux'un ya da Windows'un bir sonraki sürümünü sıfırdan kodlayabilir hâle gelirse bütün varsayımlar değişir; ama şu anda kesinlikle orada değiliz ve ileride olup olmayacağını da bilmiyoruz
Doğal dil, karmaşık sistemlerin teknik gereksinimlerini açıklamakta oldukça iyi. Yani mevcut kod uygulamasının kendisini değil, neden diğer olası uygulamalar yerine mevcut uygulamanın seçildiğini anlatmakta iyi
Kodun ne yaptığını değil ne yapması gerektiğini; başka bir deyişle depoda değil Jira gibi yerlerde bulunan eksik parçaları barındırmaya uygun
Ayrıca sistemin tamamı dış kurallarla açıklanabiliyor ve bu kurallar tüm kod tabanına dayatılabiliyorsa, daha iyi refaktörleme becerisi de sağlayabilir
Otomasyon ve bilgisayar bağlamında kullanımı kolay olduğu için programlama dillerini kullandık; açıkçası LLM'lerden önce bu aynı zamanda tek yoldu
Programlama dilleri yerel ölçekte belirsizliği ortadan kaldırır, ama biri kodun bir kısmını kopyalayıp yapıştırdığı anda küresel ölçekte bu işlememeye başlar
O parçanın uyması gereken tüm üst düzey kısıtları koruyan doğru bir program olduğundan emin olabilir misiniz? Derleniyorsa çalışan bir programdır, ama “çalışma”nın tanımı epey gevşek. C++'ta tüm belleği mahveden bir program da çalıştırılabilir