Başarılabilir (2003)
(multicians.org)- Honeywell Cambridge’deki Multics dosya sistemi yenileme sürecinde André Bensoussan, çekirdek alt sistemlerden VTOC manager’ı üstlenerek tasarımdan teste kadar yürüttü
- Bu modülün dosya tanımlama bilgilerini disk ile bellek arasında taşıması, tampon havuzunu ve disk alanını yönetmesi gerekiyordu; bu yüzden fiilen küçük bir sanal bellek yöneticisine yakındı
- André, terminal başında doğrudan kod yazmak yerine kalemle diyagramları ve kodu rafine ediyor, durum bilgisini barındırırken aynı zamanda simetrik bir tasarım oluşturmaya çalışıyordu
- Son taslağı girdikten sonra ilk derlemede çıkan sorunlar yalnızca 3 yazım hatasıydı; sisteme bağlayıp çalıştırması da ilk denemede başarılı oldu
- Daha sonra bulunan tek hata, Tom Van Vleck’in hata işleme yordamlarının çağrı sırasını yanlış söylemesinden kaynaklanıyordu; bu da programın kendi tamamlanmışlık düzeyinin çok yüksek olduğunu gösteriyordu
Multics VTOC manager çalışması
- André Bensoussan, Tom Van Vleck ile birlikte Honeywell Cambridge’de Multics işletim sistemi üzerinde çalıştı
- Dosya sistemindeki büyük değişiklik için VTOC manager adlı bir alt sistem gerekiyordu
- Dosya tanımlama bilgilerini disk ile bellek arasında taşıma
- Paylaşımlı bellek tampon havuzunu yönetme
- Dosya bilgileri için disk alanını yönetme
- Bu roller nedeniyle VTOC manager’ın küçük bir sanal bellek yöneticisi gibi çalışması gerekiyordu
- André bu modülün tasarımını, uygulamasını ve testini üstlendi
Kalemle tamamlanan program
- André önce masasına oturup çok sayıda diyagram çizdi
- Tüm durum bilgisini barındırırken aynı zamanda göze hoş gelen ve simetrik bir biçim istiyordu
- Takvim nedeniyle kod yazmanın gecikmesinden çevresindekiler endişelenecek kadar oldu
- Kodlamayı da terminalde değil kalemle yaptı
- Yazım konusunda yardım teklifini reddetti
- Bazı kısımları yeniden yazdı, temize çekti, sildi ve düzelterek son taslağı oluşturdu
- Son kalem taslağını terminale tamamen girdikten sonra ilk derleme başarısız oldu, ancak 3 yazım hatasını düzelttikten sonra derleme başarılı oldu
- Sisteme bağlayıp çalıştırdığında ilk denemede çalıştı ve ardından VTOC manager sürekli kusursuz biçimde çalıştı
- Bulunan tek hata, André’nin sorduğu hata işleme yordamlarının çağrı sırasını Tom Van Vleck’in kontrol etmeden tahmin ederek söylemesinden kaynaklandı
- Bu hata yolu ilk kez izlendiğinde çökme meydana geldi
- Bunun dışında programda hiçbir sorun yoktu
1 yorum
Hacker News yorumları
Bunu yapabilmesinin başlıca nedeninin gereksinimlerin çok net tanımlanmış olması olduğunu düşünüyorum.
Günümüzde yazılımların bu kadar hatalı ve yavaş olmasının büyük nedeni, kimsenin aslında ne inşa ettiğini bilmemesi ya da bilse bile “Agile” yüzünden bunun sürekli değişmesi.
Geliştiriciye net bir API ve iyi tanımlanmış ölçütler verirseniz, çoğu gayet iyi çalışan kod yazar.
Gereksinimler, Kanban panosuna listeler ve ticket’lar dizmek değil; inşa edilecek şeyin alanını gerçekten öğrenmektir.
Anlamadığınız bir alanda da bir şeyler yapabilirsiniz ama ortaya çıkan ürünün çöp olma ihtimali yüksektir; o çöpü yazma sürecini alan problemlerini ve olası çözümleri öğrenmek için bir taslak çıkarma olarak görüyorsanız sorun değil.
Kaliteye kestirme yol yoktur.
Bir paydaşsanız, uygulamayı yapan kişilere erişebilmelisiniz ve onların alanı anladığından emin olmalısınız. Bunu sürekli başlarının etini yemeden yapmak mümkündür.
Moda terimleri sıralayan palavracılara dikkat etmek gerekir.
Tasarımcı ve programcıysanız, paydaşların ve alan uzmanlarının aktif ve sürece dahil olduğundan emin olmalısınız. Aksi halde gereksinimleri ve anlayışı ortaya çıkarmak diş çekmek kadar zorlaşır.
Bazı paydaşlar problemi çözmek bile istemiyor olabilir; tamamen farklı bir yön istemiş ya da siyasi nedenlerle gücenmiş olabilirler. Bir projeyi batıran şeyler arasında tembel ya da ilgisiz paydaşlar kadar etkilisi yoktur.
Paydaşlar ne istediklerini bilmez ama rastgeleymiş gibi ek özellikler ya da büyük değişiklikler talep ederler.
Bu araçla yapılmaması gereken işleri zorla yaptırmaya çalıştığınız için sayısız istisna işleme gerekir.
Tasarımcılar çoğu zaman gerekli işlevlerle, mevcut sistem davranışıyla ve paydaşın talepleriyle çelişen tasarımlar yapar; sistemin farklı parçalarını geliştiren ekipler de doğru düzgün iletişim kurmadan silo içinde üretir.
Kötü tasarlanmış bir “Agile” süreç, şüpheli puanlamalara göre her şeyi belirli bir süreye sıkıştırmaya çalışır.
Sonunda bu sorunlar sistemin amaçlandığı gibi çalışmamasına ya da bir hata yumağına dönüşmesine neden olur.
Gereksinimlerin net ve değişmez olduğu, proje üyelerinin iyi iletişim kurduğu ve süreci tamamen kontrol edebildiği bir ortam yaratırsanız işler yoluna girer. Orijinal örnekte de durum böyle görünüyor.
Çoğunlukla büyük şirketlerde çalışıyorum; gelen işlerin %90–99’u ortalama durumlara karşılık geliyor.
Ama üç yılda bir, o da ay tutulmasıyla güneş tutulması aynı anda olup ormanda cadılar büyü okurken ortaya çıkan tek boynuzlu at misali sayısız özel durum var.
Bu durumları elle ele almak yerine koda uygulamak zorunda kalınca hatalar oluşuyor; incelenecek ve bakımı yapılacak kod miktarı da çok daha fazla oluyor.
Bakımdan hiç söz etmeyelim. Acı bir konu.
Gereksinimler her zaman değişir. Bu, doğanın bir gücü gibidir; herkesin en baştan ne yapılacağını bildiği, tamamen belirtilmiş bir API alıp mağaraya çekilerek yalnızca uygulama yaptığı bir dünya yok.
Gerçeklik asla böyle işlemez ve böyle koşullara ihtiyaç duyuyorsanız yazılım mühendisliği size uygun meslek değildir.
Kullanıcılar olmasa yazılımım kusursuz olurdu ;)
Sovyetler Birliği’nden iltica etmiş biriyle çalışmıştım. Sovyet programcılarının bu kadar iyi olmasının nedeninin bilgisayara erişimin çok kısıtlı olması olduğunu söylemişti.
Kalem ve kâğıtla programlama yapmak zorundaysanız, ilk çalıştırmada çalışmasını istersiniz.
Tesadüf eseri Honeywell’de çalışıyorduk.
O halde bu iyi bir eğitim yöntemi miydi, yoksa motivasyonu daha düşük olanları elemek için iyi bir filtre miydi?
Okulda ders sırasında bilgisayar kullanamadığımız için kâğıt üzerinde programlamaya, hatta hata ayıklamaya alışmıştık.
Eve gidip yazdım ve çalıştırdım; daha önce okuduğum Multics anekdotunu yeniden yaşayıp yaşayamayacağımı merak ediyordum.
İlk derleme başarısız oldu ama bir değişken adını düzelttikten sonra kusursuz çalıştı.
Birkaç yıl boyunca düzenle→derle→çıktı döngüsünde liste çıktısının terminalden çok daha iyi olduğunu hatırlıyorum. Çünkü kodu verimli biçimde görmek, içinde gezinmek ve düzeltmek zordu.
Daha iyi görsel editörler, daha büyük terminaller, daha hızlı derleme ve çalıştırma gelince sonunda iyileşti.
Benzetme yapmak gerekirse, erken dönem ateşli silahlara benziyor. Islak barut, güvenilmez çakmaklı ateşleme ve her şeyi namluya itmek zorunda kalma yüzünden uzun yaydan geçiş döneminin verimsiz olması gibi.
Bu yazının önceki HN başlığında, André ile çalışmış jrd259 hesabının iyi bir yorumu var: https://news.ycombinator.com/item?id=18415231
Geniş bir masa ve bildirimsiz kişisel çalışma alanının ne kadar önemli olduğuyla ilgili.
Hayatımda kâğıt üzerinde programlama yaptığım iki kez aklıma geliyor
İlki 10-12 yaşlarım civarındaydı. Bilgisayarın da akıllı telefonun da olmadığı büyükannemlerle büyükbabamların evine gitmiştim; orada siyah ve kırmızı renkleri bir anahtarla değiştirerek basabilen mekanik bir daktilo vardı
O zamanlar başlıca hobim Turbo Pascal olduğu için, sonra eve dönüp PC’ye girerek çalıştıracağım Pascal programını daktiloyla yazdım
Büyükannemlerle büyükbabamların evinde bir hafta kaldığım için yeterince düşünmeye, elle hata ayıklamaya ve hatalı kısımları yeniden daktilo etmeye vaktim vardı
İkincisi, yaptığım ezoterik programlama dili Ziim(https://esolangs.org/wiki/Ziim) ve o sayfadaki ikili toplama fonksiyonuyla ilgili
O fonksiyon devasa ve karmaşıktı, ayrıca hatalıydı. Yorumlayıcıda çalıştırdığım için hata olduğunu biliyordum ama sorunun nerede olduğunu ya da nasıl düzelteceğimi bilmiyordum
Tam o sırada yaklaşık 6 saatlik uzun mesafe otobüs yolculuğuna çıkmam gerekti ve bu hata ayıklamak için kusursuz bir fırsattı
Ziim toplama fonksiyonunu kurşun kalemle kareli kâğıda aktardım, sonra otobüste adım adım elle çalıştırdım. Hatayı bulup düzeltebildim ve fonksiyonun yerleşimini tamamen yeniden yapmam gerekti
Kolay yoldan yapma becerisini bilinçli olarak sınırlamanın bazen iyi düşünülmüş koda yol açabileceğine dair bir ders gibi
Yine de normalde böyle yapmıyorum. Kabaca bir snippet yazıp yinelemek ya da debugger ile satır satır çalıştırmak da hemen yaptığım şeyler. Belki yeniden düşünmem gerekir
Ama her işi kâğıt üzerinde yaparsanız, sonunda bilgisayarda doğrudan yapmaktan pek de farklı olmaz. Her şeyi yazmaya başlarsınız ve o soyutlamayı ve özeni kaybedersiniz
Ben başladığımda “büyük bilgisayarlar” çağının son demleriydi
Eskiden “programcı” çoğu zaman veri giriş memuruna yakın bir şeydi ve sık sık kadındı
Yazılım yazan insanlar, sigara dumanıyla dolu ofislerde programlarını kâğıda yazıyordu
Bilgi işlem süresi pahalı ve kıttı. Çalıştırma sırasında hata çıkarsa, yeniden veri giriş zamanı ve bir de CPU çalışma zamanı almadan önce düzeltme şansınız olmazdı
Bu yüzden iki kez ölç, bir kez kes yaklaşımını teşvik ediyordu
O dönem çoğu yazılım, bugün doğal kabul edilenlerle karşılaştırıldığında epey mütevazıydı; bu da bunu yapmayı kolaylaştırıyordu. Ayrıca yazılımın girdi/çıktısı son derece sınırlıydı, UI diye bir ifade bile yoktu ve çevre birimi bağlamak büyük işti
Günümüzde yazılım yazarken çoğu zaman “duvara atıp neyin yapıştığını görme” tarzında çalışıyoruz. Yarım yamalak kod yazıp IDE’de debug etmek daha kolay
Benim yazılım geliştirmem yinelemeli olma eğiliminde; bunu burada yazmıştım: https://littlegreenviper.com/miscellany/evolutionary-design-...
Üniversite ödevinde basit bir işletim sistemi çekirdeği yazmam gerektiğini hatırlıyorum
C’yi de pek bilmiyordum, çekirdeğin ne yaptığını da teorinin ötesinde bilmiyordum ama görev yönetimi için birkaç yüz satır C kodu yazmam gerekiyordu
Bu program çalışmazsa paralel kod olduğu için hata ayıklamanın neredeyse hiç yolu olmayacağını, hataların da anlaşılmaz yarış durumları olarak ortaya çıkacağını düşünmüştüm
Tüm sistemi akıl yürüterek ele aldım ve birkaç gün boyunca küçük, bağımsız fonksiyonlar üzerinde çok düşünerek yazdım
Sonra derleyip çalıştırdım; doğal olarak çıkan “eksik noktalı virgül” derleme hatasını düzelttikten sonra ilk çalıştırmada çalıştı
Etkileyici bir başarı paylaşıldığında yorumlar genelde kusur buluyor. Artık bıraksalar keşke
Yeni bir işletim sistemi için sanal bellek yöneticisi tasarlayan kişi değil; çocuklara ve yaşlılara reklam göstermek için SQL sorgularını HTML’ye çeviren makinenin içindeki bir dişliden ibaretler
Alaycı ve buruk olmaktan başka çare yok
Aslında bırakmamalıyız. Tartışma tam da böyle olmalı
Bir ölçüde haklısın ama bunu olumlu yöne çevirecek daha iyi soru şu: Günümüz şirket ortamında benzer bir başarının mümkün olduğu noktaya nasıl gelebiliriz?
Böyle tepkileri her gördüğümde genelde durum bu oluyor. Kullanıcı moderasyonunun eleği, daha iyi yorumları yukarı taşımak için sadece biraz zaman alıyor
Bu kişi benim yaşadığım meydan okumayla karşılaşsaydı olduğu yere çöker kalırdı
O dönemde yazılımlar çok daha küçüktü
Bugün oyuncak programlardan biraz daha büyük olduğunda çoğu proje megabaytlar düzeyinde oluyor ve tek bir dosya olarak “yazıp geçmek” imkânsız
Bu, bugün çoğumuzun üzerinde çalıştığı şeylerden daha büyük ve karmaşık. Günümüzde pek çok iş, CRUD/REST gibi şeyleri birbirine bağlayan abartılmış yapıştırıcı koda daha yakın
Tüm projenin kod satırı sayısından küçük olabilir, ama insanların uğraştığı birimlerden daha büyük. Üstelik bu da tüm işletim sistemi kodunun yalnızca bir parçası
Bu, “dosya açıklama bilgilerini yöneten yönetici”nin tamamı. Dosya bilgisini disk ile bellek arasında taşıması, paylaşımlı bellek tampon havuzunu yönetmesi ve bu bilgi için disk alanını da yönetmesi gerekiyordu
Bugün çoğu programcıya aynı gereksinimlere ve semantiğe sahip bir şeyi, seçtikleri dilde yazmalarını istesek ne olurdu?
Çoğu daha hayal etme aşamasında yolunu kaybederdi. Kâğıda yazıp sonra girerek çalışır hâle getirmek ise çok daha zor
Bunun küçük bir kısmı elektronik bileşen URL’leri, ama neredeyse %90’ı yalnızca İngilizce metin. Ayrıca %10’u da başkalarının yazılarından, web sayfalarından, üretici uygulama notlarından, kitaplardan vb. alıntılar
Tek bir dosya ve muhtemelen yılın geri kalanında da, hatta daha sonrasında da tek dosya olarak kalacak. Aynı hızla devam ederse 12 megabayt olur. Hiç de imkânsız değil
İlgileniyorsanız git clone http://canonical.org/~kragen/sw/leatherdrink.git yapabilirsiniz
Şu anda avr araç zincirini commit’lediğim için neredeyse 200 megabayt ve fotoğraflar, videolar, devre şemaları gibi şeyler de var
Bir programlama dili olsaydı aylık bayt artışı daha az olurdu, ama muhtemelen yaklaşık beş kat fark ederdi
André Bensoussan’ın yazdığı kod burada: https://multicians.org/vtoc_man.html
İşe başlamak için masama oturup kaçındığım işi bitirmeye niyetlendiğim anda, doğal olarak aklım dağıldı ve reddit ya da HN’de haberlere bakmak istedim
HN’yi açtım, ilk başlık buydu
“Yapabilirsin”
Motive oldum
Not: Elbette yazıyı da okudum :)
“André bunu kalem dışında hiçbir araç kullanmadan nasıl yaptı?”
14 yaşında liseye gittiğimde, programlama dersinde kodların çoğunu kâğıda yazardık
Yoksul bir ülkede yoksul bir çocuktum; evde PC’m yoktu, üstelik okulun bilgisayar laboratuvarındaki az sayıdaki “bilgisayar” da o dönemde kullandığımız programlama dili olan Turbo Pascal’ı çalıştıramayan ZX Spectrum klonlarıydı