Yazılım soyutlaması uygarlığı yok mu ediyor? (2021)
(datagubbe.se)- Jonathan Blow’un “soyutlama, temel yazılımı sürdürmek için gerekli yeteneği zayıflatıyor” yönündeki kaygısı, bilginin kuşaktan kuşağa aktarımı açısından geçerli; ancak dayanak olarak sunduğu örneklerin önemli bir kısmı tarihi ve bağlamı yanlış ele alıyor
- “Five nines”, sağlam yazılım, teknolojik ilerlemenin durması ve üretkenlik düşüşü tartışmaları, çoğu zaman tüketici cihazları ile yüksek erişilebilirlikli sistemleri ayırmıyor ya da seçmeci örneklere dayanıyor
- Düşük seviye bilgi kaybına dair kaygılar kısmen haklı olsa da C, assembly, Rust, işletim sistemi portlama, derleyici eğitimi ve açık kaynak faaliyetleri hâlâ sistem yetkinliğini koruyan kanallar olmaya devam ediyor
- İşletim sistemi, dosya sistemi, ağ, çoklu görev ve framework gibi soyutlamalar karmaşıklığı artırsa da donanım değişimini ve kullanıcı beklentilerini karşılayarak taşınabilirliği, üretkenliği ve üretime erişimi de yükseltiyor
- Asıl daha büyük risk soyutlamanın kendisinden çok sürekli churn, kilitli platformlar, reklamlar, takipçiler, telemetri ile mahremiyet ve özgürlüğün zayıflaması; yine de kritik sistemleri sürdürecek teknik temelin korunması gerekiyor
Blow’un iddiasına dair temel yaklaşım
- Jonathan Blow’un konuşması, yazılım soyutlamalarının düşük seviye programlama bilgisinin kaybına yol açtığı ve bunun sonunda temel yazılımların sürdürülememesi nedeniyle uygarlığın çöküşüne kadar varabileceği fikrine dayanıyor
- Bilginin aktarımının önemi konusunda hemfikir olunabilir; ancak böyle bir iddiayı desteklemek için örneklerin ve tarihsel bağlamın doğru olması gerekir
- Temel karşı argüman, Blow’un örneklerinin büyük ölçüde yanlış anlama, seçmeci örnekler ve anekdot niteliğindeki kanıtlara dayanması; ayrıca bilgisayar tarihinin bazı bölümlerini gözden kaçırmasıdır
“Five nines” ve sağlamlık tartışması
- Blow, geçmişte bilgisayar sistemlerinin satışında “five nines”, yani %99,999 çalışma süresi ifadesinin bir kalite söylemi olarak kullanıldığını; ancak günümüz dizüstü bilgisayarlarının buna yaklaşamadığını öne sürüyor
- Five nines’ın yıllık yaklaşık 5 dakikalık kesinti anlamına geldiği doğru; ancak bu ölçütün tüketici dizüstüleri ya da kelime işlemci satışında kullanıldığı iddiası yanlış görünüyor
- Five nines genellikle 911 gibi acil durum santralleri, hastane sistemleri ve finansal işlem altyapıları gibi alanlarda uygulanır
- Çoğu zaman hangi durumların kesinti sayılmayacağını ayrıntılı biçimde tanımlayan uzun vadeli sözleşmelerle birlikte kullanılır
- IBM ve Amazon gibi şirketler bugün de bu tür sistem ve hizmetler satıyor
- Sağlam yazılımın onlarca yıldır ortaya çıkmadığı iddiasına karşı da örnekler var
- iPhone, yeniden başlatılmadan haftalarca hatta aylarca çalışabiliyor
- Novell dosya ve yazıcı sunucuları için 16 yıllık çalışma süresi örneği bulunuyor
- Unix, Windows, VMS sistemleri ve IBM i gibi turnkey sistemler de uzun süreli erişilebilirlik örnekleri arasında sayılıyor
Teknolojik ilerleme ve üretkenliğe itirazlar
- “Teknoloji şirketleri artık teknolojiyi ileri itmiyor” ifadesine kısmen katılınsa da parayı teknolojiye tercih eden şirketler geçmişte de vardı
- Dosya sistemleri, web sunucuları, veritabanları ve programlama dilleri gibi “sıkıcı” alanlar da gelişmeye ve iyileştirilmeye devam ediyor
- Blow’un sevmediği soyutlama, sanallaştırma ve container katmanları da ciddi emekle geliştiriliyor; bunları sevmemek, teknolojik ilerleme olmadıkları anlamına gelmiyor
- Facebook çalışanlarının üretkenliğinin sıfıra yakın olduğu iddiası, Facebook’un ürününü yalnızca sosyal platform işlevleri üzerinden değerlendiren bir varsayıma dayanıyor
- Facebook çalışanları arasında hukuk, muhasebe, grafik tasarım, sistem yönetimi, araştırma, İK ve orta kademe yönetim gibi çok farklı roller var
- Instagram, WhatsApp ve Oculus VR gibi başka iş kolları da bulunuyor
- Facebook’un asıl ürünü reklam dağıtım platformudur; kişisel verileri ve özel bilgileri toplayıp hedefli reklama dönüştürme işi, kullanıcıya görünen bir özellik olmasa da gelir olarak ortaya çıkıyor
Düşük seviye bilgi ve soyutlamanın iki yüzü
- Birçok programcının bellek ayırma ve pointer yönetmek zorunda kalmadığı ortamları tercih ettiği doğru kabul ediliyor
- Basit bir blogu gereksiz JavaScript framework’leriyle render etmek ya da paketlenmiş bir tarayıcı içinde yavaş çalışan masaüstü uygulamaları gibi aşırı soyutlama örnekleri sorunlu görülüyor
- Ancak bugün C bilen insan sayısı ve yazılan C ile assembly kod miktarı geçmişe göre daha fazla bile olabilir
- Linux ve NetBSD, CPU gibi görünen çok çeşitli hedeflere port edilmeye devam ediyor
- Rust, sağlamlığa odaklanırken pointer ve bellek yönetimi de sunuyor
- Harvard CS50, bellek yerleşimi, pointer’lar,
malloc()vefree()gibi konuları açık dersler aracılığıyla öğretiyor
- Garbage collection ve fonksiyonel programlama yeni soyutlamalar değil
- Lisp, 1950’lerin sonunda ikisini de sunuyordu
- Lisp, NASA Jet Propulsion Lab gibi “hardcore” ortamlarda da kullanıldı
- Blow’un konuşmasında COBOL yer almıyor; oysa bankacılık ve finans altyapısının temelini oluşturan bu yüksek seviyeli dil, bugünkü uygarlık düzeyinde kritik rol oynuyor
Ken Thompson’ın “3 haftalık Unix” örneği
- Ken Thompson’ın 3 haftada assembler, editör ve temel bir çekirdek yazmış olması son derece etkileyici bir başarı olarak değerlendiriliyor
- Ancak o dönemdeki yazılımın ne kadar sağlam olduğu, ne kadar kullanıcı dostu olduğu ve hangi özelliklere sahip olduğu net değil
- O günkü çalışma koşulları ile bugünün geliştirici koşulları çok farklı
- Dokümantasyon, kod incelemesi, günlük stand-up’lar, backlog düzenleme, user story’ler, birim testleri, müşteri talepleri, A/B testleri, commit mesajları ve kurumsal kodlama standartları gibi unsurlar bugünkü geliştirme sürecine eklenmiş durumda
- Açık ofiste dikkat dağıtan bir ortam ile Bell Labs tarzı bireysel çalışma ortamı da farklı olabilir
- Thompson örneği tek başına geçmişteki tüm programcıların daha üretken olduğunun kanıtı değil
- Thompson, gecikmeleriyle ünlü Multics projesinde de yer almıştı
- IBM OS/360 gibi büyük projeler de uzun süre gecikti ve Frederick P. Brooks, 1975 tarihli The Mythical Man-month kitabını bu deneyimlerden yola çıkarak yazdı
Yazılımın gelişimi ve kullanıcı beklentileri
- Bilgisayarların genel olarak onlarca yıl öncesine göre daha sağlam hale geldiği ve programcıların da en az geçmişteki kadar üretken olduğu savunuluyor
- Yine de bazı durumlarda işe başlamak daha karmaşık hale geldiği için ilk üretkenlik düşebiliyor
- Modern kullanıcılar basit aritmetik için RPN öğrenmek ya da bir broşür hazırlamak için troff yönergeleri kullanmak istemiyor
- Kullanışlı arayüzler ve gelişmiş özellikler, soyutlamadan bağımsız olarak, karmaşıklığı ve geliştirme süresini artırıyor
- Eski Amiga OS’te dosya kopyalarken çökme yaşanması ve sabit disk bölümünün bozulması gibi örnekler, geçmiş sistemlerin mutlaka daha kararlı olmadığını gösteriyor
- Modern ev bilgisayarı işletim sistemleri bellek koruması ve journaling dosya sistemleri içerdiği için aynı sorunlar çok daha seyrek yaşanıyor
- Windows 10 Home kusursuz olmasa da bu ilerlemeleri içeriyor
“Eskiden doğrudan yapılabiliyordu” iddiaları
-
Programı kopyalayıp çalıştırma
- Bir programı bir bilgisayardan diğerine kopyalayıp çalıştırmak, hedef mimari ve derleme koşulları aynıysa bugün de mümkündür
- Go ile derlenen
slack-termstatik bağlantılı binary’sinin Raspberry Pi cihazlarında çalıştığı örneği veriliyor - Ancak bağımsız çalıştırılabilir programların yaygın olduğu dönem için C64 ya da PC/XT çağlarına kadar gitmek gerekir; Amiga’daki Deluxe Paint IV bile çeşitli yardımcı dosyalara ve üçüncü taraf fonksiyon kütüphanelerine bağımlıydı
- Bazı Amiga oyunları dosya sistemini atlayan, track-loaded floppy’ler kullanıyordu; bu bir anlamda dönemin container mantığına benziyordu ama sabit disk kurulumu ile çoklu görevi engelliyordu
-
CPU aynıysa kod da çalışır iddiası
- Aynı CPU üzerinde makine kodunu belleğe yükleyip program counter’ı ona yönlendirerek çalıştırmak teorik olarak mümkündür
- Ancak grafik çıktısı, ses çalma, giriş işleme ve diske yazma gibi gerçek görevlerde donanım farkları büyük sorun yaratır
- Geçmişteki Z80 tabanlı ev bilgisayarlarında da CPU aynıydı ama çevresel donanımlar farklı olduğundan gerçek taşınabilirlik zordu
- Hatta Basic gibi daha yüksek soyutlama düzeyindeki programlar, çeşitli makineler arasında daha kolay taşınabiliyordu
- Apple’ın ARM tabanlı masaüstü serisini çıkarmasıyla birlikte, donanıma doğrudan yapışan yaklaşım yerine soyutlamaya dayanan yaklaşımın yeni CPU’lara portlama yükünü azaltabildiği görülüyor
-
İşletim sistemi ve donanım erişimi
- İşletim sistemi yalnızca CPU’nun yeteneklerini almakla kalmaz; dosya sistemi, ağ ve çoklu görev gibi ek yetenekler de sunar
- Twitch yayıncıları gibi oyunu başka programlarla birlikte çalıştırmak zorunda olan kullanıcılar, donanım kaynaklarının yönetilen ve öngörülebilir biçimde paylaştırıldığı çoklu göreve ihtiyaç duyar
- Amiga ve Atari’deki bazı yazılımlar, üreticinin sunduğu belirtim ve soyutlamalara uymayıp doğrudan donanıma ve belleğe eriştiği için bellek ya da sabit disk gibi küçük yükseltmelerde bile bozuluyordu
- Belirtimlere ve soyutlamalara uygun yazılmış yazılımlar ise donanım değişimlerinden sonra da satılmaya devam edebiliyordu
-
Grafikler, imzasız programlar, LSP
- Ekrana piksel çizmek bugün de birçok dilde mümkündür ve Mode 13h bile VGA BIOS adlı erken dönem bir donanım soyutlama katmanı üzerinden erişiliyordu
- Belirli VGA donanımına bağımlı kod taşınabilir değildi; buna karşılık Windows soyutlamasını kullanan grafik programları, Hercules’tan true-color XGA’e kadar çeşitli ortamlarda çalışabiliyordu
- İmzasız program çalıştırmak da hâlâ mümkündür; WordGrinder’ı doğrudan derleyip kullanan örnekler var
- Blow’un bazı şikâyetleri soyutlamadan çok donanım ve yazılım üreticilerinin sistemleri kilitlemesi ve kullanıcı yetkilerini azaltmasıyla ilgili görünüyor
- Language Server Protocol konusunda Blow’a genel olarak katılınsa da LSP, “bir metoda tıklayıp tanımına gitmek”ten daha fazla sorunu çözüyor
Oyunlar, performans ve çoklu görev
- Modern üretkenlik uygulamaları arasında performans düşüşü ve ciddi giriş gecikmesi gösteren birçok örnek bulunuyor
- Bunun bir kısmının sebebi soyutlama olsa da daha büyük sorun kötü kod ve işe uygun olmayan araç seçimi
- Aynı platformu ve aynı UI toolkit’ini kullanan programlar arasında bile aynı makinede hissedilen performans ciddi biçimde farklı olabiliyor
- Blow’un verdiği oyunda Alt-Tab sonrası çözünürlüğün geri gelmemesi örneği kötü bir deneyim ve kesinlikle düzeltilmeli
- Ancak geçmişteki DOS oyunları başka süreçleri hesaba katmak zorunda olmadığından daha basitti
- Windows 3.1’de Doom oynamak için işi kaydetmek, programları kapatmak, Windows’tan çıkmak ve sonra oyunu başlatmak gerekiyordu
- Amiga oyunları da çoğu zaman floppy’den boot edip makineyi tamamen ele geçiriyor, işletim sistemine temiz biçimde dönemiyordu
- Bugünkü oyun çoklu görevi kusursuz olmasa da geçmişe göre daha iyi kabul ediliyor
Bilgi kaybı ve değişim hızı
- Blow, Unity’de sprite yönetimi gibi bilgilerin derin anlayış yerine yüzeysel malumata dönüştüğünü düşünüyor
- Modern yazılım ve donanımdaki değişim hızının anlamlı biçimde takip edilemeyecek kadar yüksek olabildiği görüşüne katılınıyor
- Ancak bu durum soyutlamanın kendisinden çok zaman içinde tutarlılık ve yazılım dağıtım modelinin sorunlarıyla ilgili
- Her 4 haftada bir bir şey yayımlama anlayışı, kullanıcıların istikrarlı bir deneyim yaşamasını zorlaştırabiliyor
- Arayüz sık sık değiştiğinde kullanıcılar gerçek işlerinden çok sürekli değişen arayüz ayrıntılarıyla uğraşmak zorunda kalıyor
Karmaşıklık insan yapımı bir sorun
- Blow, karmaşıklığı azaltmaya karar verilirse gerçekten azaltılabileceğini ve insanların soyutlama ekleyerek zaman kazandıklarını sanmakla hata yaptığını savunuyor
- Doğru framework doğru amaç için kullanıldığında web geliştiricilere büyük fayda sağlayabilir
- Aynı anda hem tarayıcıyla kelime işlemden oyuna kadar her şeyi yapma çabasına hem de yeni bir framework çıkar çıkmaz hemen geçme eğilimine şüpheyle yaklaşılıyor
- Yazılım karmaşıklığını sadece programcılar yaratmıyor; piyasa ve kurumsal ortam da bunda rol oynuyor
- Şirket içi siyaset, anlamsız toplantılar, anlaşılmaz zaman raporlama yazılımları, dışarıdan dayatılan teslim tarihleri, zor müşteri talepleri, tuhaf yönetim kararları, soyut gereksinimlere süre biçme ve legacy kod hata ayıklama gibi etkenler geliştirici tercihlerini etkiliyor
- Karmaşıklık insan yapımı bir sorundur; iş yerindeki karmaşıklık azaltılırsa uzun vadede yazılım karmaşıklığı da düşebilir
Genç geliştiriciler ve motor yazma yeteneği
- Genç oyun geliştiricilerinin kendi motorlarını hiç yazmadığı ve bu yeteneğin yakında topluca unutulacağı yönündeki Blow iddiası, kaygan zemin safsatasına yakın bulunuyor
- C64, Amiga ya da 286 PC sahibi insanların çoğu düşük seviye geliştirici olmadı; hatta çoğu programcı bile olmadı
- Soyutlamalar ve hazır oyun motorları, düşük seviye bellek yönetimi, pointer ve algoritma bilgisi olmadan da üretim yapmayı mümkün kılıyor
- Bugünün çocukları mağazada satılan AAA oyunlara benzeyen şeyler yapmak istiyor ve modern oyunlara dair beklenti, C64 ya da Amiga dönemine göre çok daha yüksek
- Düşük seviye becerileri öğrenme yolları hâlâ mevcut
- Linux, açık kaynak topluluğu sayesinde genç geliştiricileri çekiyor ve Rust, C, C++ gibi sistem dillerine ilgi uyandırıyor
dwm, yapılandırması C kaynak kodunu değiştirerek yapılan bir pencere yöneticisidir- C ve Z80 assembly kullanan genç geliştiriciler, Linux dağıtımını sıfırdan kuranlar, kendi donanımını yapanlar ve araştırma amaçlı işletim sistemlerini modern donanımda çalıştıran C geliştiricileri bulunuyor
- Bilgisayar bilimi ve elektrik-elektronik mühendisliği bölümleri C, assembly ve derleyici tasarımı gibi temelleri öğretmeyi sürdürüyor
- Programlama araçlarına, kaynaklara, eğitim videolarına ve MIT OpenCourseWare gibi materyallere erişim geçmişe göre daha ucuz ve daha iyi durumda
Son değerlendirme: soyutlamadan daha büyük sorunlar
- Blow’un vardığı sonuç, teknolojiye uygulanmış bir survivalism anlayışına benziyor; elektrik kesildiğinde ateş yakmayı bilen insanlara ihtiyaç olduğu benzetisine sempati duyulabiliyor
- Toplum, bazı programları neredeyse kesintisiz çalıştırabilme kapasitesine bağımlı
- Bu başarısız olursa dünya ekonomisinin çökmesi ya da ulusal sağlık sistemlerinin işlemez hale gelmesi gibi ciddi sonuçlar doğabilir
- Tarihsel ve modern kayıtlar giderek daha fazla dijital tutulduğundan gelecekte de erişilebilir kalmaları gerekir
- Karmaşıklık kırılgan olabilir ve soyutlama zararlı bir cehalet yaratabilir; basit bir blogu render etmek için shadow DOM gerekmez, görselliği olan bir IRC istemcisi için de tarayıcı kabuğu şart değildir
- Ancak yapay biçimde sürdürülen sürekli churn de kırılganlık yaratan büyük bir etkendir
- “Agile” geliştirme, aslen tamamlanmadan ve test edilmeden bir şey yayımlanmamasını hedefler; ama pratikte sürekli yarım kalmış sürümler çıkabiliyor
- Reklam, takipçi ve telemetri sistemleri fiilen tasarım gereği arka kapı gibi çalışarak kırılganlığı ve güvensizliği artırıyor
- Dijital dünyanın daha büyük sorunu mahremiyet ve özgürlüktür
- Donanımla doğrudan arayüz kuramıyor olmamızın sebebi soyutlamayı seçmemiz değil; giderek daha fazla kilitlenen ve uzaktan kontrol edilen platformların geriye kalması olabilir
1 yorum
Hacker News görüşleri
Montana State'te transistörlerden gerçek bilişim sistemlerine kadar uzanan bir sistem dersi veriyorum; derse başladığımızda dosya sisteminin ne olduğunu doğru dürüst bilmeyen öğrenciler de oluyor
Blow ayrıntılarda bazı yerlerde yanılıyor olsa da, teknik bölümlerdeki öğrenciler için liseden itibaren NAND-to-Tetris tarzı bir eğitimi ciddi biçimde düşünmemiz gerektiğini düşünüyorum
Little Man Computer ya da basit görsel MIPS emülatörleri gibi “eski” modeller kullanıyorum; gerçekçi olmasalar da sıradan bir insanın anlayabileceği karmaşıklık düzeyinde nereden geldiğimize dair bir fikir veriyorlar
Bugünlerde önerilen 64 bit mimari ders kitaplarına bakınca sadece gülüp geçiyorum; teknolojiyi köklerine bağlamak zor bir mesele
Sorun, mobil işletim sistemleri ve yazılım şirketlerinin kullanıcı verilerini mümkün olduğunca uygulama içindeki duvarlarla çevrili bahçelere dönüştürmeye çalışmasında
Zaten dosyalarla çalışıyor olsanız bile mevcut verileri kendi depolarına “içe aktarmanızı” sağlıyorlar; düzenlenmiş sürümü ise yeni bir kopya olarak elle “dışa aktarmanız” ya da “paylaşmanız” gerekiyor
Montana State'te endüstri mühendisliği yüksek lisansı yapıyorum ve basit kısmi türev bile alamayan doktora öğrencileriyle her gün uğraşıyorum
Geçen dönem 400 seviyesinde bir matematik dersinde iki matrisi nasıl toplayacağını bilmeyen bir öğrenci de vardı
Bilgisayar bilimi son sınıf öğrencisinin dosya sistemini bilmemesi de tuhaf ama burada gördüğüm akıl almaz şeylerle kıyaslanınca daha masum görünüyor
2000'lerde ilk kez üniversiteye gittiğim zamana göre hava çok değişmiş; bu moral bozucu, ama gelecek bahardaki iş piyasası konusunda tam tersine özgüvenim artıyor
Adının aksine bilgisayar bilimi bilgisayarın kendisiyle ilgili bir bilim değildir; bilgisayar zorunlu bir araç olsa da özü, alan soyutlaması ve dil modellemesi ile bunların uygulanmasıdır
Bir astronomun teleskobu ihtiyaç duyduğu kadar kullanmayı bilmesi yeterli olduğu gibi, bir bilgisayar bilimcinin de bilgisayarı gerektiği kadar kullanmayı bilmesi yeterlidir
Bilgisayarı evrenin merkezine koyup bilgisayar biliminin çıkış noktası yapmak büyük bir hatadır ve tarihsel olarak da pek çok kafa karışıklığının kaynağıdır
“Düşük seviye” programlama bile nihayetinde soyutlama ve dildir; yalnızca tartışılan alanın soyutlamasını simüle etmek için bilişim aygıtının dilini kullanır
Boş zamanlarımda MIPS assembly'sini decompile ediyorum; küçük fonksiyonları başka araç kullanmadan elle karşılık gelen C koduna geri çevirebiliyorum
Ama seyrelme falan yok. Öğretme faaliyeti var, kitaplar ve bilgisayarlar var; bu yüzden öğretmenlere ozan dememize gerek yok
Sonuçta bu, bir blog yazısı hakkında yazılmış başka bir blog yazısı; o blog yazarlarının ne kadar “önemli” olduğunu bilmiyorum ama blog için blog kokusu alıyorum
Yaşlı bir web geliştiricisi soyutlamayı eleştirince hedefinde React geliştiricileri olur; Python geliştiricisi eleştirince yaşlı web geliştiricilerini hedef alır; C++ uygulama geliştiricisi eleştirince Python geliştiricilerini hedef alır
Firmware geliştiricisi uygulama geliştiricilerini, elektrik mühendisi de firmware geliştiricilerini hedef alır
Kendi bildiği seviyeyi ölçüt alıp aşırı soyutlama çizgisini oraya çekmek ve sonrasındaki her şeyi “medeniyeti öldürüyor” diye adlandırmak epey iddialı bir tavır
Çok iyi tespitler var ve ben de o sunumu izlediğim için eleştirinin önemli olduğunu düşünüyorum
Ancak Blow'un “ekrana öylece piksel çizemiyorsunuz” sözü doğru
Orta ölçekli bir oyun şirketinde oyun motoru programcısı olarak çalışıyorum; grafik koduyla uğraşacak birini işe almak giderek çok zorlaşıyor
DX12 ile aynı kuşaktaki API'ler, önceki kuşak DX11'e kıyasla programcıdan beklenen seviyeyi muazzam artırdı ve bu API ile bir şey yapmak başlı başına büyük bir iş
Microsoft da bir zamanlar önceki grafik API'leri deneyimi olmadan DX12 öğrenmenin son derece zor olduğunu kabul etmişti; ama şimdi dokümantasyonda o alıntıyı bulamıyorum
“Bu tür API'ler grafik kartının sınırlarını zorlamak ve çok düşük seviye optimizasyon yapmak isteyen geliştiriciler için” itirazı kısmen doğru, ama artık sektör standardı haline geldiler ve önceki deneyimi olmayan birine öğretilemeyecek düzeye yakınlar
Bir şeyler değişmezse işe alınabilir aday havuzu küçülmeye devam edecek
Yazılım uygulaması geliştirirken ekrana tek bir düğme çizmek bile o kadar zorlaştı ki çoğu kişi, mümkün olan performanstan 100 kat yavaş progressive web app'leri olduğu gibi kullanıyor
2025'te GUI uygulamalarında en iyi seçenek gerçekten Java Swing ve Qt mi diye düşünüyorum
Bütünü birbirine bağlayan büyük kavramlar var ama dokümanlarda bunlara neredeyse hiç işaret edilmiyor; bunları öğrenmek için eğitim oturumlarına katılmak ya da zaten bilen biriyle konuşmak gerekiyor
Sunucu tarafı JavaScript ve React gibi şeylerin, gerçekte yaptıkları işe kıyasla web yazılımı geliştirmeyi gerçekten berbat hale getirdiğini düşünüyorum
Bugünün gençleri arasında tarayıcıda render edilen şeyin HTML olduğunu bile bilmeyenler var. React’in kendisinin tarayıcı tarafından render edildiğini sanıyorlar
Üstelik Vercel’in CEO’su, React’i geliştirmenin Linux çekirdeği olarak gördüğünü söyleyecek kadar mutlak saçma bir laf etti
https://news.ycombinator.com/item?id=42824720
vanilla js, jQuery, Knockout, Angular 1 dönemlerini hatırlayacak kadar uzun süredir buralardayım; o zaman da temel kafa karışıklığı hep vardı
React, bazen yalnızca JSX ile bile makul biçimde kullanılabilir
Asıl Vercel, Next, Apollo, Prisma gibi girişim sermayesi destekli araçları ve para alıp web’i çöple dolduran web geliştirme influencer’larını suçluyorum
Düşününce, Notion panolarından şüpheli veritabanı seçimlerine kadar yazılım yapmanın her parçası şişti
Ama kütüphane olmadan da gayet çalışabilen biri olarak şunu eklemek isterim: DOM, insanlığın icat ettiği en kötü API’lerden biri ve “reaktif programlama” eski yöntemlere göre üstün bir model
NextJS yılların araç iyileştirmelerini geri aldı ve Vite’tan çok daha yavaş
Statik olarak derlenmiş NextJS’te hiç etkileşimi olmayan bir sayfa, hiçbir şey yapmamak için 100KB JavaScript indiriyor
Facebook, varsayılan olarak bileşenleri gereksiz yere yeniden render etmeyecek hale getirmekle çözülebilecek bir işi React için bir “derleyici” ile çözmeye çalışıyor
Neredeyse bire bir yerine geçebilen Preact ile karşılaştırıldığında React devasa ve bu da Facebook’un ne kadar umursamadığını gösteriyor
HTML bir serileştirme biçimidir; tarayıcı bunu kullanarak bellekte DOM’u oluşturur
React hiçbir şeyi HTML’e serileştirmez, doğrudan DOM’a render eder
Bunun yanlış olmasına rağmen çok oy alması, bu başlığın “bulutlara yumruk sallayan yaşlı adam” karakterini iyi gösteriyor
Benim anladığım kadarıyla HTML tarayıcının girdisidir; tarayıcı bunu DOM’a dönüştürür, ardından ekrana çizme ve girdi işleme gibi süreçler gelir
Bu fark önemli, çünkü React veya sanal DOM ailesinden JavaScript kütüphaneleri HTML üretmez; JavaScript ile yazılmış DOM manipülasyon komutları üretir
Blow’un tespitlerinde çok iyi taraflar var, ama birçok gerilemenin kuşaklar arası sürüklenmeden ya da bilgi entropisinden değil, karar veren insanların apaçık kötü niyetinden kaynaklandığını gözden kaçırdığını düşünüyorum
Blow geliştirme konusunda gerçekten harika noktalar yakaladığı zamanlar da var, tamamen ıskaladığı zamanlar da
Büyük işler başardı ve dinlemeye değer fikirleri var; ama bunlarla ayırt edilemeyecek şekilde sunulan çok fazla saçmalık da var
Medeniyetin çöküşü söyleminin bu saçmalıklardan biri olduğunu güçlü biçimde hissettim; iki kez dinledim ama çoğunu görmezden geldim
Orijinal yazının daha ilkesel bir karşı argüman sunmasına sevindim
Casey Muratori’nin Blow’u taklit ettiğini, ama iyi tarafları bile düzgün yapamadığını düşünüyorum
Muratori, 10 yıl önce başladığı oyunu bile bitiremedi
Buna karşılık modern oyun motorlarıyla, Raylib gibileri de dahil, hafta sonu game jam’lerinde bile epey makul sonuçlar üretilebiliyor; Blow’un Sokoban oyunu düzeyinde bir şey özellikle 10 kişilik bir ekiple yaklaşık 6 ayda yapılabilir
İçeriklerinin bir kısmını izledim; bildiği konularda mütevazı ama görüşleri net biri gibi görünüyordu ve Handmade Hero’yu da çok iyi yaptığını düşünüyorum
Jira’nın tek bir ticket göstermesi için geçen süre, Slack’in bir sohbet odasını değiştirme süresi, VSCode’un normal yazma hızına yetişememesi gerçekten delilik
Geniş kapsamlı eleştirel laflar edip sonra tekrar hiçbir şey yapmamaya kayboluyor gibi görünüyor
Büyük bir başarı elde ettiğini söylemek de zor; yaptığı işler bence fena olmayan düzeyde
Yalnızca iki oyun çıkardı ve bunlar oyundan çok bulmacaya yakın. Bir kez bitirince yeniden oynamaya pek gerek yok
Braid fena değil, The Witness ise sadece Flow gibi
Ondan sonra 10 yıldır bir programlama dili yapıyor ama “henüz tamamlanmadı” diye yayımlamıyor
Şans eseri para kazandıktan sonra kendini gerçekte olduğundan çok daha yetenekli biri olarak görüyor gibi
Modern yazılım ortamında kesinlikle çok sorun var ve aşırı soyutlamanın da sorun olduğunu düşünüyorum
Ama karşı uç da kötü; ayrıca geçmişi aşırı romantize etme eğilimi de var
Çökmeler ve yeniden başlatmalar da sorundu; Amiga gibi sistemlerde donanım sürümleri arasında uyumluluk sorunları vardı, uyumluluğa önem veren sistemler bile uyumsuzluktan tamamen muaf değildi
En istikrarsız modern sistem sayılabilecek Windows 11’de bile bilgisayarım, 2010’dan önce kullandığım herhangi bir bilgisayardan çok daha kararlı ve Windows 95 yazılımlarını da çalıştırabiliyor
Günlük olarak kullanılabilen bir bilgisayar, kullanılamayan bir bilgisayardan iyidir
Her basitleştirme bir soyutlama değildir; her soyutlama da basitleştirme değildir.
Ancak basitleştirme arayışında çoğu zaman soyutlamalar ortaya çıkar.
Soyutlamanın yazılımı ya da medeniyeti öldürdüğünü düşünmüyorum; ama kısa vadeli basitlik gerekçesiyle yapılmış kötü soyutlamalar esnekliği, çevikliği ve erişilebilirliği azaltır.
Neredeyse tüm dillerdeki sözdizimsel şekere baktığınızda, bir noktada bu belirli nüanstan elde edilen yerel basitleştirmenin, aracın bütünü için artan karmaşıklığı haklı çıkarmadığı bir eşik gelir.
Sözdizimi bol olan dillerde insanların hata yapmasının nedeni tek bir belirli unsur değil; karmaşık sorunları iyi çözmek için araç kullanma işinin kendisinin zorlaşmasıdır.
Kotlin’de async ve coroutine’lerin “thread benzeri” kodla uğraşırken benim deneyimime kattığı karmaşıklık ile Elixir/Erlang’de aynı tür sorunların ele alınma biçimi tamamen farklı.
İkisi de paralel/asenkron hesaplama gibi eski bir soruna soyutlama ve basitleştirme sunuyor; ama ilki basitliği katman katman çarpıp yeniden karmaşık bir şey yaratırken, ikincisi sadece çalışan, gerçekten basit bir soyutlamaya daha yakın.
Yazar daha genç bir kuşağa ait gibi görünüyor; bu yüzden Blow’un asıl noktasını anlamadan kaçırmış gibi.
İronik biçimde, yazının kendisi Blow’un bahsettiği örneklerden biri gibi görünüyor.
Figma’nın kendi kötü UX’ini, UI’ını ve ürün yönetimi biçimini normalleştirerek tasarım dünyasını benzeri görülmemiş ölçekte mahvettiğini söylediğinizde, her şeyin yolunda olduğunu sanıp şaşkına dönen genç tasarımcıların tepkisini almak gibi.
O bilgi, o ortamda büyüdüğü için onda var; onlar ise büyümedi ve kültür ile deneyime karşılık gelen şeyi bir yerden öğrenmek de kolay değil.
Böyle bir kişisel saldırı sohbete hiçbir şey katmaz.
“Yazılımın ilerlediği iddiası açıkça yanlış” sözünün aksine, hâlâ sevdiğim Amiga bilgisayarları sık sık kullanıyorum.
Birkaç hafta önce Amiga sabit diskine dosya kopyalarken bilgisayar birden çöktü; bunun nedeni benim yanlış bir şey yapmam değil, eski ev bilgisayarı işletim sistemlerinin pek de kararlı olmamasıydı.
Sonuçta sabit disk bölümü bozuldu, işletim sistemi dosya sistemini yeniden doğrulayamadı ve sonunda bölümü yeniden biçimlendirmekten başka çare kalmadı.
Tasarımdan pek anlamam, ama Figma hakkındaki iddianın Blow’un iddiası gibi tamamen yanlış olduğunu anlayabiliyorum.
Bunu söyleyen nostalji. Kullanıcı arayüzlerinde her zaman berbat şeyler vardı; yazılımda da, her şeyde de öyleydi.
Geçmişteki en üst düzey örneklerin yalnızca iyi yanları hatırlanıyor; çöp gibi olanlar ve iyi tasarlanmış olanların başarısızlıkları bile unutuluyor.
Sorun, üzerinde derin düşünülmemiş soyutlamalar.
İlk taslak ya da ilk deneme olduğu belli olduğu hâlde, teknoloji sektörünün hız kültü ve kibri yüzünden birçok soyutlama birkaç kez elden geçirilmeden olduğu gibi yayımlanıyor.
Böyle bir soyutlama popüler bir projenin parçası hâline gelince, başkaları bunu “en iyi uygulamalar” gibi bulanık bir bayrak altında taklitçilikle kopyalıyor.
Bu süreci 10–20 yıl tekrarlayınca devasa bir keşmekeş ortaya çıkıyor.
Daha da kötüsü, teknoloji yüzünden paradoksal biçimde aşırı sosyalleşmiş bir toplumda, “sahtekâr” olarak yakalanmama yönündeki toplumsal mutabakatın olgunlaşmamış çözümleri sürekli yayması.
Jonathan Blow’un o sunumunu seviyorum ve en az yılda bir kez tekrar izliyorum. Bence o tartışmalı bir şey söylemiyor; birçok geliştirici içten içe, en iyi hâliyle yayın yapmadığını ve genç kuşağa düzgün rehberlik etmediğini bildiği için öfkeleniyor ya da alınmış hissediyor.
Yenilik arayışının sıradanlaştığı, hatta bazen övüldüğü bir kültüre vardık.
Eskiden yeterince incelenmiş çözümler kültürel ölçüttü; artık gerçekten iyi olup olmamasından bağımsız olarak yeni olan ölçüt hâline geldi.
Blow’un argümanının ayrıntılarını sonsuza kadar didikleyebiliriz, ama kanıtlar her yerde apaçık ortada duruyor.
Ve yeterince uzun bir zaman ölçeğinde bu medeniyetin çöküşüne yol açabilir; dünyadaki bozuk şeylerin miktarına bakınca bunun şimdiden gerçekleştiği de söylenebilir.
Kusurlu bir tezin bu kadar ayrıntılı biçimde parçalarına ayrılması gerekmesi üzücü.
Saf deneyimci, saf teorisyen kadar gerçeklikten kopuktur; Blow kendi deneyimine uyduğu için argümanlar uyduruyor, şikâyetlerine uyan örnekleri seçip istisnaları kuralmış gibi dayatıyor.