Anlaşılabilir yazılıma doğru
(gracefulliberty.com)- Programlama okumak, test etmek ve bakımını yapmak zordur; ayrıca proje anlayışı az sayıda kişide yoğunlaştığı için, LLM ile kod yazımını otomatikleştirmekten ziyade kod gerektiren alanın kendisini azaltan soyutlamalara ihtiyaç vardır
- LLM'ler hem geliştiriciler hem de geliştirici olmayanlar arasında yaygınlaştı, ancak çevresel yıkıcılık, çalıntı koda dayanma, tutarsız sonuçlar üretme ve bağımlılık yaratma gibi sorunlar hâlâ büyüktür
- Başlangıç noktası, önce kod yazıp sonra belge ekleme alışkanlığını tersine çevirerek önce dokümantasyon yazmak ve kodun onu takip ettiği edebi programlamaya geçmektir
- GUI tabanlı görsel programlama ve deterministik doğal dil programlama, kodu birçok gösterimden yalnızca biri hâline getirebilir; ancak görsel ortamlar için ekran okuyucu entegrasyonu gibi erişilebilirlik tasarımı zorunludur
- Eve ve Inform gibi önceki girişimler ile Entangled ve ReTangled gibi araçlar, hem yeni başlayanların hem de uzmanların anlayabileceği biçimde yazılım üretmenin mümkün olduğunu gösteriyor
LLM hedef model değil
- LLM'ler endüstriyel yazılım geliştirmede önemli araçlar hâline geldi ve deneyimli uzmanlar da test, hata ayıklama ve kod yazımı için LLM ajanlarını kullanıyor
- Geliştirici olmayanlar da LLM'lerle kişisel betiklerden bilimsel veri işleme araçlarına kadar çeşitli şeyler üretiyor
- Programlamada nereden başlanacağı belirsizdir ve belirli bir dilin sözdizimini ve kütüphane ayrıntılarını öğrenmek istemeyen kişiler için erişilebilirliği düşüktür
- LLM'lerin yayılması, LLM'lerin programlamayı çok iyi yapmasından çok, programlamanın kendisinin karmaşık ve nahoş bir iş olduğuna dair bir işarettir
- Birbiriyle çakışan yazılım yığınları, bitmeyen boilerplate'ler ve zahmetli kütüphaneler vardır
- Ortalama bir yazılım geliştiricisinin işi, ilginç kod geliştirmekten çok kütüphaneleri birbirine bağlama işine indirgenmiştir
- LLM'lerde hâlâ büyük sorunlar var
- Çevresel açıdan yıkıcıdır
- Temelde çalıntı koda dayanır
- Tutarsız kod üretir
- Bağımlılık aşılar
- Mevcut programlama paradigması da yetersizdir, ancak LLM'lerin yerine de daha iyi bir alternatife ihtiyaç vardır
Otomasyon yerine soyutlama
- LLM'lerden vazgeçmek, otomasyondan, yüksek seviyeli soyutlamalardan ve insan dostu arayüzlerden de vazgeçmek anlamına gelmez
- Hedef, kod yazmayı kolaylaştırmakla sınırlı kalmayıp, kodun altındaki yazılım yığınını ele almak ve kod yazma ihtiyacını azaltmaktır
- Belirli bir soyutlama katmanını tekrar tekrar otomatikleştirme isteği duyuluyorsa, o katmanı otomatikleştirmek yerine soyutlayıp ortadan kaldırmak daha uygun bir yöndür
- LLM'lerin programlamada yaygın biçimde kullanılması, kod yazma sürecini otomatikleştirme arzusunu gösterir; bu da kod yazma ihtiyacının kendisinin soyutlanması gerektiğine işaret eder
- İnsanları bilgisayar gibi düşünmeye zorlamak yerine, insanların doğal düşünme biçimine daha yakın yeni soyutlama katmanlarına ihtiyaç vardır
Dokümantasyonun önce geldiği programlama
- Anlaşılabilir yazılımın ilk adımı dokümantasyondur
- Başkalarının bir yazılımı anlamasını istiyorsanız, o yazılımı açıklamanız gerekir
- Yaygın yaklaşım, önce kod yazmak ve sonra doc-comment ya da kullanım örnekleri eklemektir
- Önerilen yaklaşım, sırayı tersine çevirip önce dokümantasyonu yazmak, ardından kodu eklemektir
- Önce insanlara programın ne yaptığını anlatır, sonra bilgisayara ne yapması gerektiğini söylersiniz
- Bu kavram edebi programlama olarak bilinir
- Bu yaklaşımda, başkasının kodunu doğrudan okuyup niyetini çıkarsamak yerine önce dokümantasyonu okuyup amacı anlar, ardından koda bakarsınız
- Entangled bu yaklaşımın iyi bir uygulamasıdır
- Dokümandan kod çıkarıp uygun kaynak kod dosyalarına yerleştiren çift yönlü bir tangler'dır
- Dokümandaki kod blokları düzenlenebilir ve normal kod dosyalarında yapılan değişiklikler de dokümandaki kod bloklarına yansır
- Test, refactoring ve kod biçimlendirme gibi mevcut araçlar, özel bir edebi programlama desteği olmadan kullanılmaya devam edebilir
- Tangler, build sistemine az miktarda ek yük getirir; özellikle derleyiciyle kıyaslandığında bu yük küçüktür
- Bu yaklaşım kodun karmaşıklığını ortadan kaldırmaz, ancak başkasının kodunu anlama alanında LLM'lerin yerini alabilir
Kodu ortadan kaldırmak: GUI ve çoklu gösterimler
- Kod, eski bir çağın kavramıdır ve bilgisayarlarla terminal üzerinden etkileşim kurmak gerektiği için kullanılan bir yöntemdir
- Bilgi işlem son 40 yılda değişmişken, bilgisayarlarla yalnızca belirsiz semboller ve anahtar sözcüklerden oluşan tek boyutlu dizelerle iletişim kurmakta ısrar etmek için bir neden yoktur
- GUI, metin tabanlı arayüzlere kıyasla karmaşık kavramları ele almayı kolaylaştırır ve çoğu zaman yeni kullanıcılar için daha erişilebilirdir
- IDE'ler yalnızca kod düzenlemek için uygun yerler olmanın ötesine geçip, yazılım geliştirmeyle etkileşime girmenin yeni bir yolu olabilir
- Bazı IDE'ler zaten bu tür işlevler sunuyor
- Daha da ileri gidilerek görsel programlama, herkesin kod öğrenmeden istediğini üretebileceği kadar yaygın ve basit hâle gelebilir
- Kodun kendisinden tamamen vazgeçmek gerekmez
- GUI gösterimi, insanların düzenleyebildiği birçok gösterimden biri olabilir
- Metin tabanlı işletim sistemi arayüzlerini tercih edenler olduğu gibi, kod tabanlı yazılım düzenlemeyi tercih edenler de var olmaya devam edebilir
- Ancak kodun varsayılan ya da tek seçenek olması gerekmez
- Görsel programlama daha erişilebilir olacak şekilde tasarlanabilir, ancak görsel merkezli ortamlar görme engellileri dışlama sonucunu doğurabilir
- Güçlü ekran okuyucu entegrasyonu gerekir
- İşitsel veya dokunsal olarak zengin biçimde anlaşılabilecek alternatif gösterimlere de ihtiyaç vardır
Doğal dili deterministik bir soyutlamaya dönüştürmek
- LLM'lerin bir soyutlama katmanı yukarı çıktığı söylense de, LLM'ler soyutlamadan çok bir otomasyon katmanına yakındır
- Bir soyutlama katmanı öngörülebilir ve güvenilir olmalıdır; üst düzey niyet, alt düzeyde doğru ve tutarlı biçimde ifade edilebilmelidir
- LLM'ler prompt'ları olasılıksal olarak yorumlayıp niyeti tahmin ettiği için öngörülemez davranır
- İş sonuçlarını rastlantısal biçimde yaklaşıklayan bir süreci otomatikleştirir
- Eğer bir soyutlamaysa, son derece kayıplı bir soyutlamadır
- Doğal dil işleme (NLP) alanındaki ilerleme, doğal dilden makine diline giden öngörülebilir bir boru hattı kurma olanağı sunar
- Hedef, LLM prompt'u yazıyormuş gibi girdi verip her seferinde öngörülebilir ve sağlam programlar üretmektir
- Başkalarının çalışmalarını çalıntı kodun ortalaması gibi damıtmak yerine, tanımlar üzerinden doğrudan inşa etmek gerekir
- Bu yaklaşım, dokümantasyon ile kodu daha sıkı bağlayabilir
- Edebi programlamada kod bölümünü doğal dille değiştirirseniz, geriye yalnızca doküman kalabilir
- İnsanlara programın nasıl çalıştığını anlatan metin, aynı anda makineyle iletişim kuran metin de olabilir
- Bu doğal dil programlaması deterministik olmalıdır
- NLP, transformer modellerinin üretim yeteneği olmadan da sözdiziminden anlam çıkarmak için kullanılabilir
- Ayrıştırılmış dilbilgisi, diğer programlama dillerinde olduğu gibi platform gereksinimlerine göre derlenen bir ara gösterime doğrudan dönüştürülebilir
- Inform'a benzer, ancak daha yüksek düzeyde sözdizimsel farkındalığa ve daha geniş bir tanım ağına bağlı bir yapı öngörülüyor
- Deterministik niteliği sayesinde prompt'lar güvenilir ve tutarlı biçimde koda dönüşür; bu da LLM'lerden temelden farklı, gerçek bir soyutlama katmanıdır
Önceki girişimler: Eve ve Inform
- Bu fikirler yeni değil ve daha önce de uygulanmaya çalışıldı
- Eve, programlamayı insanlar için daha erişilebilir kılmayı amaçlayan bir programlama dili ve IDE idi
- Edebi programlama yaklaşımını kullanıyordu
- Alan odaklı, veri yönelimli bir programlama dilini yazılımın davranışını açıklayan dokümanın içine gömüyordu
- Kod, dokümana bağlıydı ve tüm programlama ortamı da bunu yansıtıyordu
- Eve, bu fikri daha da genişletip kendi dilini NLP sorgularıyla değiştirmeye de çalıştı
- Doğal dil işlemenin karmaşıklığını üstlenmeye hazır değildi
- 2016'da daha gelişmiş NLP, makine öğrenmesi merkezli olmayan şirketler için kolay erişilebilir değildi
- GUI odaklı yaklaşımı da denedi
- Eski bir Eve katkıcısı da projenin karmaşıklığı ve LLM sınırları konusunda benzer kaygılar dile getiriyor
- Eve, gelir modeline ulaşamayan iddialı bir VC yatırımı projesi olduğu için sona erdi ve fikirlerin olgunlaşmasını görme fırsatı olmadı
- Inform, etkileşimli kurgu üretmek için kullanılan bildirimsel bir dil olarak bu kavramların daha geniş şekilde uygulanabileceğini gösteriyor
- Doğal dil temelde sızdıran bir soyutlama olabilir, ancak ortalama bir insanın kendi bilgisayarını doğrudan kontrol edebilmesini sağlama potansiyeli daha fazla ilgi görmeyi hak ediyor
Sonraki adımlar ve önerilen çalışmalar
- Anlaşılabilir yazılım üretmeye yönelik bir proje olarak ReTangled geliştiriliyor
- Rust ile yazılmış, Entangled uyumlu çift yönlü bir tangler'dır
- Amaç, edebi programlamayı mümkün olduğunca genişletmek ve mevcut toolchain'lerle makul düzeyde sıkı entegrasyon kurmaktır
- Şu anda erken geliştirme aşamasındadır ve katkılar memnuniyetle karşılanır
- Görsel programlama, edebi programlama ve doğal dil programlamasının her biri için daha kapsamlı yazılar yazılması planlanıyor
- Topluluk düzeyinde, Eve'in izinden gidip biraz farklı bir yaklaşım benimsemek öneriliyor
- Hedef, yeni başlayanlardan uzmanlara kadar herkesin yararlı biçimde kullanabileceği, iyi dokümante edilmiş ve erişilebilir bir görsel veya doğal dil programlama ortamı oluşturmaktır
- Başlangıç noktası yazılımı daha iyi dokümante etmektir; nihai hedef ise programlama kavramının kendisini tersyüz etmektir
1 yorum
Lobste.rs yorumları
Kodu bir kenara atmanın ya da doğal dilde yazılmış düzyazıya tabi kılmanın, programlamanın erişilebilirlik sorununu çözmek için etkili bir yol olduğundan emin değilim.
Programlama dilleri, bilgisayarın ve insanın ihtiyaçları arasında denge kuran bir kullanıcı arayüzüdür. İyi tasarlanmış, anlaşılır biçimsel gösterimler; bireyin anlamasına ve insan ile makine arasında fikirlerin aktarılmasına yardımcı olan bir düşünme aracı olabilir.
APL ailesi dilleri öğrenmek beni çok etkiledi; öğrenmesi zaman aldı ama bir kez öğrendikten sonra daha büyük problemleri zihnimde tutup daha kesin düşünebilir hâle geldim. K, karmaşık bir IDE olmadan; zihinde, kâğıt üzerinde ve basit bir REPL ile bile problem çözmeyi mümkün kılıyor.
İyi belgelenmiş projeler ve literate programming değerli, ama belgeleri okumak, yazmak ve düzeltmek de zaman alıyor. Testlerde olduğu gibi, belgenin çok olması her zaman iyi değildir; ben kısa ve yapılandırılmış açıklamaları ve açıklaması kolay, özlü programları tercih ederim. Kod şiir olabilir, ama çoğu şiir program değildir.
Çoğu insan bu iç işleyişi öğrenmeyecek; bu yüzden daha fazla kişinin katılabilmesi için giriş engelini düşürmek istiyorum.
LLM’lerin popüler olmasının nedeni de bence bu. Programcı olmayanların işlerini halletmek için LLM ile kod yazdığını sık görüyorum, ama yazıda da söylendiği gibi LLM’lerde kaçınmak istediğim büyük kusurlar var. İnsanlar doğal dille ya da rahat bir kullanıcı arayüzüyle oyunları modifiye edebilmeli, betikler yazabilmeli, programları genişletebilmeli.
“Kodu ortadan kaldıralım” ifadesi biraz abartılı olmuş olabilir, ama birçok insan kod hakkında düşünmek istemiyor ve buna ihtiyaç duymamaları da gerekir.
Programcılar programcı olmayanları bir anlamda kendi hâline bıraktı.
Visual Basic öldü, framework’süz PHP de pek canlı görünmüyor, Access de fiilen öldü. Notion veya Airtable gibi veritabanı benzeri araçlar kaldı.
Programcılar kod yazmayı o kadar seviyor ki, çoğu kişi basit sorunlara basit çözümlerden uzaklaştı.
Python’ın bir dönem programcı olmayanların dünyasını kasıp kavurmasının nedeni basit görünmesi ve Pandas gibi araçların da kullanımı kolay görünmesiydi. İlginç şekilde, birçok programcı Python’ı ya da Pandas’ı pek beğenmez. Örneğin standart kütüphaneyle kolayca yapılabilecek bir işi Pandas ile yapan kod görünce insan epey soğuyor.
Eskiden programcı olmayanlar da HTML sayfaları yapar, renkler ve görseller eklerdi. Bugün bir programcıdan statik web sitesi yapmasını isteseniz, beraberinde akıl almaz bir karmaşıklık gelir. Bir kısmı gerekli olabilir, ama çoğu tamamen gereksizdir. Programcıların basit bir web sitesi yapmak için kullandığı süreci programcı olmayanlara verseniz, 20 yıl önce HTML düzenlemekten keyif alacak insanlar bile çığlık atarak kaçar.
Bugün bazı şeylerin aksine çok daha zorlaşmış olması derin bir ironi ve huzursuzluk verici.
CSS güçlendi, tarayıcılar daha az sorunlu ve her konuda yardımcı olacak kişisel kodlama asistanları var. Saf Python da aynı şekilde; sadece kullanırsınız. Programlama hiç olmadığı kadar kolaylaştı.
Modern teknoloji yığınlarının karmaşıklığının çoğu zaman bir nedeni vardır, ama ancak o neden ortaya çıktıktan sonra kullanılmalıdır; yeni başlayanların kullanmasına hiç gerek yok.
İnsanlar HTML web sitesi ya da temel programlar yapmıyorsa, bunun nedeni yapmak istememeleridir. Gelecekte herkesin temel programlama bileceğini düşünürdük, ama gerçekte insanların bunu sadece istemediği ortaya çıktı. Arabalar veya bisikletler için de temel bakım bilmeleri gerektiği savunulabilir, ama insanlar bunu reddeder. Bu, işin zor ya da imkânsız olduğu anlamına değil, daha çok bunu yapma isteğinin olmadığı anlamına gelir.
Genel halkın bilgisayar okuryazarlığının neredeyse hiç gelişmediğini düşünüyorum; bunun programlamanın karmaşıklığıyla ilgisi yok. Eğitim alanında bilgisayar okuryazarlığının gerilediği bile söyleniyor, ama bunun karmaşık frontend framework’lerinden kaynaklandığını düşünmek zor.
Yazının birçok kısmına katılıyorum. Örneğin literate programming’i seviyorum, ama programlamanın kendisinin kötü olduğunu düşünmüyorum.
Bazı programlamalar kötü; BigTech şirketlerinde yapılan programlama da çoğu zaman genel olarak kötü oluyor. Ama kendim ya da sevdiğim insanlar için program yazmak hâlâ keyifli.
Entangled’ı bilmiyordum; iyi bir fikir gibi görünüyor ve literate programming’deki en büyük acı noktası olan LSP ile mevcut araçların farkında olmaması sorununu ele alıyor. Bu yüzden şimdiye kadar literate programming’i çoğunlukla NixOS yapılandırması gibi deklaratif dillerde kullandım.
Çift yönlü literate programming, deklaratif olmayan diller kullanırken hayatı daha rahat hâle getirebilir. ReTangled’ı denemeyi düşünüyorum.
GUI’ler çoğunlukla, üst düzey yöneticilerin ve daha yukarıdakilerin, çalışanların kendi anlayabildikleri ve yapabildikleri işleri yaptıklarına inanmalarını sağlamak için varmış gibi görünüyor.
Görsel sürükle-bırak ETL aracı dersi almıştım; aklımda kalan tek şey, ilk sistemle neredeyse aynı şeyi yeniden yapmanın zor olacağı ve tamamını sürüm kontrolüne almanın da zor göründüğüydü. 2010’da o zamanki şirketin kullandığı görsel sürükle-bırak cron alternatifi sistem de benzerdi.
Yönetici için sürükleyip bırakmak kolaydır, ama işi yapan kişi için hata bulmak, sürüm ve yedekleri korumak, yeniden kullanım zorlaşır.
Eğlenceli bir prototipi üretimde çalışacak bir şeye dönüştürmek için çokça hata işleme, serileştirme, ters serileştirme, tür projeksiyonu vb. gerekir. Benim kurallarımdan biri şu: Harika kullanıcı deneyimi neredeyse her zaman dağınık bir iç yapı gerektirir.
Kişisel olarak bunun çoğundan keyif almıyorum; geçmişte kestirme yollar seçtiğim ya da o işi hiç yapmadığım da oldu.
Oldukça güçlü biçimde katılıyorum. WYSIWYG editörlerine bakınca, web geliştirmeyi tamamen ikame etmediler ama yalnızca temel bir web sitesi ya da basit ürün satışı isteyen insanların hatırı sayılır bir nişini azalttılar.
Hâlâ iyi bir GUI arayüzü ile daha da basitleştirilebilecek büyük yazılım alanları var.
Şu anda kodu sadece birbirine yapıştırıyor ya da LLM’leri rastgele döndürüyorsanız, aslında GUI programlama daha iyi olabilir. Benim sık kullandığım kodlar da çoğu zaman REST sunucusu oluyor; bunun için bir şey yapılamaması için hiçbir neden yok.
Aynı hedefi paylaşıyorum ve kullanmak istediğim tam çözümü sağlayacak teknoloji yığınını yıllardır düşünüyorum.
Curv adlı bir projeyi yayımladım ama bu, kafamda olan çok daha güzel bir sistemin yalnızca küçük bir parçası.
Binlerce başka insan da bu problemle uğraştı. Problemin büyüklüğü nedeniyle ekip çalışması gerekiyor gibi görünüyor, ama gerçekte çoğu küçük tek kişilik projeler. En güçlü vizyona sahip kişiler çoğu zaman ekip hedefleri uğruna kendi vizyonlarından taviz vermek istemiyor. Bunu nasıl çözmek gerekir bilmiyorum.
İlham veren projeler arasında Alan Kay’in Dynabook vizyonu, buradan doğan Smalltalk, Alan Kay’in sonraki projesi STEPS Toward the Reinvention of Programming, Bret Victor’ın çalışmaları ve özellikle onun şaşırtıcı başarısı olan Dynamicland var.
Bu konuyla ilgilenen topluluklardan biri, eskiden Future of Coding olarak anılan Feeling of Computing. Eklenebilecek başka şeyler varsa söylerseniz sevinirim.
“LLM prompt’una yazar gibi talimat girip eksiksiz bir program oluşturalım, ama her seferinde öngörülebilir ve sağlam çalışsın” fikri, doğal dilden deterministik ve tutarlı semantik ayrıştırılabileceği gibi devasa bir varsayıma dayanıyor.
Ama en başta bunun doğru olduğunu düşünmüyorum. Bunu henüz düzgün çalıştırmayı başaramamış olmamız bir yana, mümkün olup olmadığından bile şüpheliyim.
Dilde çok fazla bağlam var. Aynı cümleyi on iki kez söyleseniz bile tonlama, dinleyici kitlesi, fiziksel konum, ifade ortamı ve zaman dilimine göre her seferinde ince farklı anlamlar doğar. Geleneksel doğal dil işleme teknikleri bu esnekliği temelden ele alamıyor.
LLM’lerin var olmasının nedeni de tam olarak bu. Muhtemelen var olmayan katı bağlam kuralları koymaya çalışmak yerine, bağlam algısını ağırlıklara kodlayabilen bir model eğitme yaklaşımı. Bunun şaşırtıcı derecede etkili olduğu görüldü.
İnsanların LLM kullanmasının nedeni de bu. Çünkü şimdiye kadar yapılan herhangi bir doğal dil arayüzünden çok daha iyi biçimde bağlamı hesaba katıp beklenen yanıtı üretebiliyorlar. Bu açıdan gerçekten çalışıyor. LLM dışındaki doğal dil işleme aynı düzeyde başarı gösteremedi.
Zengin görsel programlama ortamları ilginizi çekiyorsa Glamorous Toolkit olası yönü gösteren iyi bir örnek: https://gtoolkit.com/
Henüz tamamlanmış bir biçim olarak görmüyorum, ama şimdiye kadar yapılmış şeyleri daha ileri taşıyan bir araç. LLM tarafından üretilen kod çağında imaj tabanlı ortamlar hakkında da konuşmaya değer.
Eksik olan şey, programcıların bugün yaygın olarak kullandığı ilkel öğelerin, yani fonksiyonlar ve modüller halinde düzenlenmiş kod satırlarının ötesine geçen öngörülebilir soyutlamalar.
Özellikle basit veri dönüşümü değil de karmaşık dış sistemleri modelleme gereksinimlerini yalnızca bu öğelerle aktardığınızda, insan programcılar yapsa bile giderek büyüyen bir çamur yığınına dönüşüyor. LLM’ler de bunun görünümünü taklit ediyor.