Yazılım krizi
(wryl.tech)- 1968’deki NATO Software Engineering conference’da ortaya çıkan “software crisis” ifadesi artık daha az kullanılıyor, ancak yazılım karmaşıklığının ve soyutlamanın yarattığı yük hâlâ sürüyor
- Edsger Dijkstra, 1972’deki Turing Award konuşmasında donanım performansı ve karmaşıklığı hızla artarken, bunlarla başa çıkacak örgütsel yöntemlerin buna ayak uyduramadığını savundu
- Kişisel bilişimin ticarileşmesi ve hızlı çıkış döngüleri, kullanıcıların araçları yeterince öğrenmeden daha büyük kapasite istemesine yol açtı; “abstract it away” varsayılan tepki hâline geldi
- İç içe geçmiş soyutlama katmanları performans maliyeti ve çarpık zihinsel modeller yaratır; grafik ve ses gibi makinenin temel işlevlerine erişimi zorlaştırır
- Çözüm, geçmişin kısıtlı platformlarına dönmek değil; soyutlama katmanlarını azaltmak ve katmanlar arasındaki bilgiyi koruyarak araç kullanıcılarına inisiyatifi geri vermektir
1968’deki sorun bilinci hâlâ sona ermedi
- “software crisis” terimi, 1968’deki ilk NATO Software Engineering conference’da ortaya atıldı
- Bu konferanslar, otomatik hesaplama makinelerinin programlama pratiklerini düzenlemeye ve sistematikleştirmeye yönelik ilk girişimlerden biriydi
- Apollo 11 görevi 16 Temmuz 1969’da fırlatıldı; aynı yılın ekim ayında son NATO Software Engineering conference düzenlendi
- Edsger Dijkstra, 1972’deki Turing Award konuşmasında krizin nedenini güçlenen makinelerde ve bunları kaldırabilecek örgütsel yöntemlerin yokluğunda gördü
- “Makineler yokken programlama sorun değildi; birkaç zayıf bilgisayar varken hafif bir sorundu; devasa bilgisayarlar ortaya çıkınca programlama da devasa bir sorun hâline geldi” anlamına gelen bir söz söyledi
- Günümüz programlama pratiklerinde “software crisis” ifadesi sık geçmez
- Yeni dillerin ve örgütsel yöntemlerin gelişmesi, ayrıca geçmişteki sorunlarla araya giren zaman mesafesi, sektöre bunu bir ölçüde çözdüğü yönünde bir rahatlama hissi verdi
- Ancak bu rahatlama, gerçek bir huzurdan çok yenilgi ve kabullenme durumuna yakın kalıyor
Soyutlama, kullanıcı inisiyatifini uzaklaştırıyor
- Erken dönem bilişimin ve yakın alanların gelişimi, soyutlama kulesi inşa etmenin makine ve ortam açısından doğrudan maliyetli olduğu koşullarda gerçekleşti
- Kısıtların etrafından dolaşılamadığında donanım yükseltmelerinin izlediği bir büyüme döngüsü vardı
- Pratikte ise mevcut kısıtları yeterince anlamadan daha büyük kapasite istenir hâle geldi
- Kişisel bilişimin ticarileşmesinden sonra ekipman satan şirketler, kullanıcıların ürünü tamamen öğrenmesini beklemedi ve büyüme döngüsü giderek hızlandı
- Hızlı donanım çıkış döngüsüyle birlikte “abstract it away” varsayılan düşünme biçimi oldu
- Hoşa gitmeyen ayrıntıları kontrol edilebilir bir yapının içine itmek bir ölçüde bağımsızlık sağlar, ancak beraberinde performans maliyeti getirir
- Çok katmanlı soyutlama ve bilgi gizleme, yazılım inşa etme sorununu daha üst katmanlara taşır
- Bu katmanlar, bilgisayar kullanmak için gereken yazılımların ve hayatı yöneten yazılımların içine entegre olur
- Daha geniş yazılım endüstrisi, çıkış döngülerini ve sermayenin etkisini hızlandırdı; bireysel geliştiricilerin kolayca erişebileceği alan zayıfladı
- Yazılım krizi yalnızca geliştiricilerin sorunu değildir; yazılım kullanıcılarına da uzanır
- Kullanıcıların, yazarı tarafından izin verilen işlevlerin dışında neredeyse hiç kontrolü yoktur
- Yazılım yapmanın ve kullanmanın bütünüyle insan faaliyeti olduğu gerçeği bulanıklaşır
Geri dönülecek yer geçmiş değil, sığ katmanlardır
- Önerilen çözüm, daha kısıtlayıcı platformlara dönmek değildir
- İzin verilen soyutlama katmanı sayısı sınırlandırılmalıdır
- Katmanlar arasında bilginin korunması gerekir
- Programlama modeli, kullanıcı arayüzü ve temel donanım sığ ve birleştirilebilir olmalıdır
- Handmade, Permacomputing ve retrocomputing toplulukları gibi hareketler, yazılım krizine dair farkındalığı artıran akımlara dönüşüyor
1 yorum
Hacker News görüşleri
Merhaba, yazının yazarıyım. Bu yazıda sıkça yanlış anlaşılan noktaları netleştirmenin önemli olduğunu düşündüğüm için özetliyorum. Soyutlamanın kendisine karşı değilim; sınırsız uygulanmasına karşıyım
Çözüm olarak daha kısıtlayıcı platformlara dönmeyi de savunmuyorum, kullanıcılara “katlanın ve daha teknik olun” demiyorum. Yazılım krizini anlamanın anahtarı, “platform yetkinliği” ile “büyüme/sürüm döngüsü” eğrileridir. Son 40 yılı aşkın sürede, birkaç alan dışında bu eğriler birbirinden uzaklaştı; birbirlerine yakınken çözememiş olsak da ikinci en iyi zaman şimdi
Bu yazının tık tuzağı olduğu yönünde tepkiler de var; ancak bu, günlüğümdeki ilk yazı ve bir geliştirici olarak içinde bulunduğum duruma dair düşüncelerimi içeriyor. Benzer duygular birçok toplulukta, özellikle de bazı karşı-kültür temelli topluluklarda farklı biçimlerde görülüyor. Çözümün bir kısmını göstermek istediğim için “nasıl yapılacağını göstereceğim” türünde bir devam yazısı da yazmayı düşünüyorum. Bunu tek başıma yapıyorum; lütfen bana zaman ve alan tanıyın
Yazılım üreten milyonlarca insan olduğu sürece bu sorunu tamamen düzeltmek mümkün değil. Bunların bir kısmıyla kaçınılmaz olarak fikir ayrılığı yaşayacağız ve herkes yazar kadar yetkin hâle gelemez. Bu yüzden yazı, nihayetinde “kabul edilebilir soyutlama” çıtasının bugünkünden daha yükseğe konması gerektiği iddiası gibi okunuyor
Büyük konuşmak kolaydır; ama gerçekten “fazla soyutlanmış” olduğunu düşündüğünüz belirli bir alana baktığınızda muhtemelen daha mütevazı olursunuz. Böyle “aşırı soyutlamaların” bile çoğu zaman oldukça iyi gerekçeleri vardır; o alandaki mühendisler de soyutlama durumunun dağınık olduğunu hisseder, ancak bunun gerekli olduğunu veya düzeltmenin pratik olmadığını düşünür
Örneğin birçok yazılım, yaygın kullanılan ara soyutlamaların üzerine iyi soyutlamalar eklenerek inşa edilir. Kubernetes’in Linux, container runtime, geleneksel denetim düzlemi/yapılandırma katmanı/veri düzlemi yapısı üzerine oturması gibi. Tüm bu mantığı yeni bir işletim sistemine doğrudan da uygulayabilirsiniz; ancak bu kez kullanıcıların uyumluluk sorunları ortaya çıkar. Yapabilirsiniz ama kullanıcınız olmayabilir; o zaman da kaçınmaya çalıştığınız kötü soyutlamaları yeniden uygulamak zorunda kalırsınız. Üstelik böyle bir çözümün uygulanması çok daha zordur. Kubernetes tasarımını sevmediğim için bu sorunu çözmek isterdim; ama “doğru şekilde” yapmak çok zor veya pahalı olduğundan değmeyecek bir sonuca varıyorum
Bu alana ne zaman ve hangi geçmişle girdiğinize bağlı olarak, önceki neslin soyutlamaları çoktan kabul gören uygulamalara dönüşmüş olabilir. Örneğin bir zamanlar genel amaçlı dosya sistemine sahip bir işletim sistemi kullanmak doğal bir varsayım hâline gelmişti
Burada söz konusu olan sorunun, bugün bu alana girerken yaşanan zorluklara daha yakın olduğunu düşünüyorum. Katkı yapabilmek için kullanılan tüm soyutlamaları ayrıntısıyla anlamak gerektiğini varsayarsanız, gereken ön bilgi oldukça fazladır. Bunaltıcı olabilir; ama daha derin anlayabilecek seviyeye gelene kadar soyutlamaları kabul etmek de bir yoldur
0 - https://en.wikipedia.org/wiki/Clarke's_three_laws
Ancak bu durumun neden değişmediği bence açıkça ekonomik. Kötü yazılımın daha ucuz olduğu anlamında değil. Fakat köşeleri kesince bireyler veya kuruluşlar bugün maliyetten tasarruf edebiliyor; daha büyük maliyetler ise daha sonra kuruluşun kendisine, müşterilere ve toplumun tamamına yüklendiği için ucuz ve kötü uygulamalara güçlü bir teşvik var. Üstelik yazılıma diğer mühendislik alanlarının standartlarını uygulamak zor olduğundan, belirli standartta veya kalitede yazılım talep eden sözleşmeler ya da düzenlemeler oluşturmak da zor
Hayal edilebilecek tek çözüm, aynı teknolojiyle daha ucuz ve daha iyi yazılım üretmeyi mümkün kılarken, aynı zamanda daha ucuz ve daha kötü yazılım üretmeyi imkânsız kılacak bir teknolojik devrim olabilir
Çok fazla platformda çok fazla yazılım var ve manzara o kadar parçalı ki genelleme yapmak zor. Bazı projeler sallanıp çökerken bazıları gayet iyi çalışıyor
Kullanıcıya düşman yazılımlar da var; ama bu tasarım gereği. Arkasında sinizm ve açgözlülük var. Programcıların ne yaptığını bilmemesinden değil, onlara söyleneni yapmalarından kaynaklanıyor
Kullanıcıların kendisi de bunu körüklüyor. İyi yazılım yapsanız da ilgilenmiyorlar; kullanıcılar iyi yazılım değil, başka şeyler talep ediyor. İyi yazılım isteyen tek bir kullanıcı, istemeyen elli kullanıcının kurbanı hâline geliyor. Kitlesel pazar yazılımı artık popüler kültürdür
O zamanki Word’ün bugünkü sürüme kıyasla çok eksik olduğu da söylenemez. Buna karşılık günümüzde Windows ve Office’in sadece çalışması için bile 50–100 GB disk gerekiyor. 1000 kat büyüyerek ne elde ettik?
Tamamen delice bir durum ama biz bunu normal karşılıyoruz. Modern sistemlerde disk, RAM ve CPU yaklaşık 5000–10000 kat arttı; ev interneti ise ilk modemlerden kelimenin tam anlamıyla bir milyon kat daha hızlı
Bu yazı, yazılım krizinin gerçekten var olduğu ya da ciddi bir sorun olduğu varsayımına dayanıyor. Krizin unsurları olarak bütçe aşımı, takvim aşımı, verimsizlik, düşük kalite, gereksinimlerin karşılanmaması, yönetilemeyen projeler, bakımı zor kodlar, teslim edilememe gibi şeyleri sayıyor
Ama buradan “yazılım” kelimesini çıkarırsak, bu sorunlardan en az birini yaşamayan kaç insan faaliyeti vardır? Tersinden bakarsak, gerçekten oldukça harika pek çok yazılım da var. Biz yalnızca başarısızlıkları ve kusurları görmeye eğilimliyiz; başarılar sürekli daha iyiye gitse bile onları olağan bir taban çizgisiymiş gibi görmezden geliyoruz
Bilgisayarın güç düğmesine basıp masaüstüne ulaşana kadar zaten yüzlerce soyutlama katmanından geçiyoruz. Sadece o masaüstü bile gün boyunca etkileşime gireceğimiz makineler arasında en karmaşık nesne. Bu, tüm dünyada günde onlarca milyar kez gerçekleşiyor ve çoğunlukla sorunsuz oluyor. Bu da yalnızca çok küçük bir örnek
Ancak bu tür yazıların asıl motivasyonunun bu maddeler değil, her şeyin başa çıkılamazmış gibi hissedilmesi olduğunu düşünüyorum. Deneyimli bir programcı, bu ezicilik duygusunu yapılması gereken işlerle dengelemelidir. Buraya gelmem zaman aldı ama bunun önemli olduğuna inanıyorum. Her şeyin tamamen düzene girdiği bir an olmayacak; bunu kabul etmek gerekiyor
Yazılımda ise performans ve bellek kısıtları dışında bu tür sınırlar neredeyse yoktur. Üstelik ikisi de bol olduğundan, çöpün üzerine sonsuza kadar ekleme yaparak idare edebilirsiniz. Hepimizin “Bu şey nasıl çalışıyor ki?” diye düşündüğü ya da söylediği anlar olmuştur. Kullanıcı yanlış bir sınır koşuluna basana kadar alttaki kodun ne kadar kırılgan olduğunu bilemezsiniz
“Kapatıp açmayı denediniz mi?” bunun kanıtıdır. Yazılım sistemleri sık sık öyle incelikli ve anlaşılmaz kötü durumlara girer ki, tek çözüm her şeyi silip baştan kaldırmaktır. Bir telefon aramasından sonra bir sonraki arama ya da mesaj gelene kadar telefonun titremeye devam etmesi, bir web uygulamasında bazı bölümlerin %100 yüklenmeyip seçeneklerin kaybolması, Bluetooth eşleştirmenin tutarsız çalışması gibi
İletişim, anlayışı yaymanın ve eksikliğini gidermenin yoludur; anlama ise her türlü başarının temelidir. Anlama yoksa yukarıdaki belirtilerden biri veya daha fazlası ortaya çıkar. Anlama olsa da ortaya çıkabilirler, ama en azından başarıya giden bir yol oluşur
Benim deneyimime göre yazılım mühendisliği sektöründeki sorunların çoğu insan sorunudur. Teknoloji de değil, teknolojinin kendisi de değil, süreç de değil. Bu yüzden iletişim ve anlama başarı için vazgeçilmezdir
Mühendislik ya da otomotiv şirketlerinin lider kadrolarının geçmişlerine baktığınızda, parça, bileşen ve ürün tasarımı ya da üretim tesislerinin işletilmesinde giderek daha büyük sorumluluklar üstlendikleri aşamalar görürsünüz. CEO hâlâ teknik bilgiyi vurgular; teknik olmayan çalışanlar bile en azından öyleymiş gibi yapar
Buna karşılık çevik yazılım geliştirmede teknik yetkinlik genellikle en alt katmanda sona erer. Scrum ekiplerinde yazılımı yapan insanlar vardır, hepsi bu. Scrum master’ların ve birçok iş analistinin çok fazla kod yazmamış olma ihtimali yüksektir; hiyerarşideki ilk gerçek amir de çoğunlukla sekreterlik/idari işlerle uğraştığı için koda neredeyse hiç bakmaz
Mesele yalnızca yazılım geliştirmenin ticket boyutundaki birimler hâlinde yapılması ve bu yüzden insanın oluşturup bakımını yaptığı soyutlama katmanlarının sayısı üzerine felsefi olarak düşünmesinin zorlaşması değildir. Yazılım geliştiricinin karar masasında bir yeri bile yoktur. Scrum master tarafından kollanır, code review’da uzlaşmaya zorlanır, ticket’ın dışını düşünmemesi için baskı görür ve teknik yetkinliği liderliğe taşıyacak bir terfi yolu da çoğu zaman yoktur
Bu yüzden “yazılım krizi”ni duyurmaya çalışan hareketin, yazının sonundaki ifadeyle Handmade, Permacomputing, retro computing gibi hobi alanlarında kalma ihtimali yüksek görünüyor. Hollywood’un yazılım/IT insanlarını sürekli aşağılayıcı biçimde tasvir ederken, doktorlara ve avukatlara durmadan başrol verip karmaşık uzmanlık jargonunu ilgi çekici hikâyelere dönüştürmesinin de bunda bir miktar payı olduğunu düşünüyorum. Bizim taraf için bu gerçekten imkânsız mı? Belki yakında senaryo yazan yapay zeka bir şeyler başarır
Yazılım geliştirme, bütün gün bilgisayarla kesin ve katı biçimde konuşma işidir. Ya zaten çözülmüş sıradan bir işi yeni bir uygulamada çözersiniz ya da teknik arka plan olmadan kavraması bile zor sorunlarla uğraşırsınız. 20 yılı aşkın süredir eğlence için programlama yapan bir geliştirici olmama rağmen, işlerin çoğu insanı çileden çıkaracak kadar sıkıcıdır. Bunu geliştirici olmayanlara anlatmaya çalışmam bile. Muhasebe kadar sıkıcıdır; pek çok kişi muhtemelen başka bir hikâyeden daha faydalı bilgiler edinir
Çalıştığım, çevikliğe en fazla kapılmış şirket; junior ve senior geliştiricileri birbirinin yerine geçebilir dişliler gibi görüyordu. Tek fark, senior’ların sprint başına daha fazla point işlemesi gerektiğiydi. Ticket kapsamının dışını düşünmeye karşı aktif bir caydırma vardı; başını eğip ağzını kapatma havası hâkimdi
Ancak iki sorun var. Uygulama ayrıntılarına derinlemesine inemezler ve karmaşıklık yarattıklarında ödüllendirildikleri çarpık teşviklere de bağlıdırlar. Elbette buna karşı çıkanlar da vardır, ama böyle kişilerin terfi etme ihtimali düşüktür. Kendi altındaki kişi sayısını azaltmak ya da kendi rolünü ortadan kaldırmak karşılığında kimse ödüllendirilmez
Geliştiricilerin gerçek gereksinimlerin yalnızca ticket boyutundaki parçalarıyla uğraşmasının kısa nedeni şu: fazla aptal olmaları. Bütün resmi kafalarında tutamıyorlar, anlayamıyorlar. Kulağa sinir bozucu mu geliyor? Evet. Anlaması gerçekten zor. Üzgünüm
Bu yazı soyutlamayı kötü bir şey gibi resmediyor, ancak belirli bir seviyenin üzerinde insan yapımı yazılım üretebilmek için kaçınılmaz bir araçtır
Rich Hickey bir keresinde şu minvalde bir şey söylemişti: “Acemi bir jonglör iki üç top çevirebilir; dünyanın en iyi jonglörü bile muhtemelen dokuz civarında bir sınırda kalır. İnsan yeteneğinde basamak farkı yoktur ve çok çabuk tavana çarpar.” Bu sınırı aşmak için soyutlama yapmaktan başka çare yoktur
Elbette belirli örneklerde kötü soyutlama ya da fazla soyutlama olabilir; yazarın öfkelendiği kısmın da burası olduğunu düşünüyorum. Ama bu ayrım önemlidir
“Artık yazılım yapmak kolay değil ve hiçbir şey kılavuzla gelmiyor” kısmı açıkça yanlış. Yazılım üretmek hiç olmadığı kadar kolaylaştı ve dokümantasyon da daha iyi durumda
Karmaşık bir bütünü anlamak için dolaylama şart değildir. Karmaşıklıkla başa çıkmak için birbirine dolanmış şeyleri çözerek her parçayı bağımsız olarak anlayabilmek gerekir. Karmaşıklığı dolaylamayla gizlediğimizde, akıl yürütmemiz gereken şeyle aramıza mesafe koymuş oluruz
Soyutlama kullanıcılar için iyidir. Geliştirici olsun ya da olmasın, ayrıntılarla ilgilenmeleri gerekmez. Ama onu inşa etme işini bizim için daha kolay hâle getirmez
“Artık yazılım geliştirmek kolay değil” denmesinin aksine, doğru iş için doğru araçları bilirseniz bu çok kolaydır. Sadece bu araçlara dair bilgi bastırıldığı için neredeyse hiç duymazsınız
Çoğunluğun düşündüğü teknik araç ekosistemiyle gerçekte olan arasında büyük fark var. Bildiğimiz araçların çoğu berbat. Her derde deva gibi görünmeye çalışıyorlar ama gerçekte hiçbir işte pek iyi değiller. Buna rağmen en popüler araçlar bunlar. Yazının ima ettiği gibi, bunun sermayenin etkisi yüzünden olduğunu düşünüyorum
Örneğin şu anda kullandığım araçla; oturum açma, erişim denetimi, şema doğrulama ve karmaşık filtre görünümleri olan nispeten karmaşık bir pazar yeri uygulamasını yalnızca tarayıcıyla, hiçbir yazılım indirmeden, sunucusuz olarak 3 saatte sıfırdan yaptığım bir video çektim. Uygulamanın tamamı 700 satırdan az HTML işaretlemesi ve 12 satır JavaScript’ten oluşuyor. Yaklaşık 10 görüntülenme aldı
Komplo teorisi tadındaki twist’in aksine, modern araçlar hiç olmadığı kadar esnek ve kullanımı kolay. Kusurları var, ama onlarca yıl önce geliştiricilerin katlanmak zorunda kaldıklarıyla kıyaslandığında bunlar hiçbir şey. Aracınızı bastırmaya çalışan dev bir komplo yok
Ben no-code/low-code’a ve her yerde çalıştırılabilen araçlara çok inanıyorum. Ancak benim kastettiğim şey sizin düşündüğünüzden farklı olabilir. Her hâlükârda bunu yapmış olmanızı takdir ediyorum
Videoyu izlemeye başlarken aklıma gelen ilk soru şuydu: Codespaces nedir? Güvenlik nasıl sağlanıyor? Nihai uygulama nerede çalışıyor? Kendi donanımımda çalıştırabilir miyim? Buluta erişim olmadan çalıştırabilir miyim? Hangi bulut? Gelecek hafta, gelecek ay, gelecek yıl, 10 yıl sonra hâlâ var olacak mı? Elbette tek bir örneğe fazla takılmayın
No-code/low-code durumu masaüstü yayıncılığa benzetilebilir. DTP’de CI/CD pipeline’ı yoktur. Yazdır’a basarsınız, olur. Tamamen bütünleşik bir ortamdır. Buna karşılık kelimenin tam anlamıyla her “sürekli entegrasyon” ortamı, fazla çabalayıp bağırırken kendini yiyip bitiriyor gibi görünüyor. Bir yerlerde renk ayrımı, kenar boşluğu ayarları, font içe aktarma, PostScript başlık kitaplıkları ya da LaTeX üretimi için araçlar vardır elbette; ama çoğu kişi bunları ne görür ne de kullanır. Bir yerlerde CMYK’den çok daha çeşitli pigmentlerle, yalnızca doğal ışıkta canlı görünen çok plakalı baskılar yapan insanlar da vardır; ama çoğunluk telefonlarındaki berbat anlık görüntülere baktığı için bunun anlamını hissetmez
Bu yalnızca üreticilerin sorunu değil. Tüketiciler neyin mümkün olduğunu bilmiyor ve olasılıkların tüm yelpazesini ortaya çıkaracak cihazlara da sahip değiller. Tüketici cihazları, sayısız kapalı ekosistem nedeni ve sıradan özensizlik/cehalet yüzünden bu yelpazeye aktif olarak zarar veriyor
Birkaç yıl önce kiralık araç olarak bir Cadillac verilmişti; modern bir Cadillac’ı asla satın almam ve mümkünse kullanmaktan da kaçınırım. Silecekleri kontrol edemedim, konsol ekranı ise yola bakmadığımı söyleyerek en göze batan uyarıyı defalarca gösterdi. Muhtemelen gözlük taktığımı anlayamamıştı. Bilmediğim bir yolda, hızlı akan trafikte olduğum için ekrana gerçekten bakmadım ve yolcuma “Şu yanıp sönen ekranda ne diyor Allah aşkına?” diye sordum. Aferin, Cadillac
Sığ ve birleştirilebilir yapı, UNIX araçlarını kullanırken herkesin deneyimlediği bir şeydir
GUI burada çöküyor. GUI’ler, birbiriyle birleştirilebilir biçimde iletişim kurmayan, kelimenin tam anlamıyla adalar
GUI ile shell pipeline fikrini karıştıran deneyleri guish adlı bir araçla yapıyorum
https://github.com/williamcotton/guish
Benzer araçları ya da birleştirilebilir GUI yaklaşımlarını bilen var mı merak ediyorum
https://hisham.hm/userland/
https://arcan-fe.com/2021/04/12/introducing-pipeworld/
http://conal.net/papers/Eros/
Ben de bununla ilgili fikirler üzerinde çalışıyorum; dışarıdan bakınca sizinkiyle benzer görünüyor olabilir. Yine de bunun emacs’te nasıl çalıştığına bakmanızı öneririm. Derinlemesine incelemedim ama yaklaşımınız pek “birleştirilebilir” görünmüyor
Bilmiyorsanız bu da ilham verebilir: https://gtoolkit.com/ Smalltalk ortamı; emacs gibi kelimenin tam anlamıyla her şey programlanabilir, ama neredeyse ters yönde. GUI, komutların sonucu değil, dilin kendisidir
Ama daha büyük sorun GUI değil. GUI de sorun, fakat soyutlama yığınının en üstünde olmak zorunda olduğu için sorun daha fazla devam edip birleşmiyor. İlginç biçimde, o kadar büyük bir sorun ki artık sorun olmaktan çıkıyor
Günümüzün dev fili dağıtık sistemlerdir
Yine de GUI uzun zamandır zayıf noktaydı. UI’ın iyi olup olmamasında çok fazla “küresel” değerlendirme olduğu için, bunun modüler bir özellik olmamasından kaynaklanıyor gibi
Şahsen daha fazla UI olmasını ama otomasyonun korunmasını isterim. Shell’de yazdığınız şeyi bir dosyaya kaydedip daha sonra yeniden çalıştırabilme, değiştirip tekrar çalıştırabilme, komutu kopyalayıp bir arkadaşınıza e-postayla gönderebilme özelliğinden bahsediyorum
Bağlam eklemek gerekirse, yıllardır sıfırdan bir shell geliştiriyorum ve GUI için headless mode var. Başkalarının yazdığı gerçek demolar da var ama şu anda kimse üzerinde çalışmıyor
Ekran görüntüleri:
https://www.oilshell.org/blog/2023/12/screencasts.html#headl...
https://www.oilshell.org/blog/tags.html?tag=headless#headles...
Daha fazla bağlantı burada - https://github.com/oilshell/oil/wiki/Interactive-Shell - Xiki gibi ilginç, artık aktif olmayan projeler de var
Terminalden ayrılmış uyumlu bir shell’e ya da böyle yeni bir shell’e ihtiyacınız varsa e-posta veya https://oilshell.zulipchat.com üzerinden bana haber verin
Temelde headless protokolünü test edip iyileştirme önerileri verecek insanlara ihtiyacım var. Terminali “barındıran” ama terminalin “kendisi olmayan” bir shell GUI’si yapılması gerektiğini düşünüyorum. Yaptığınız şeyle de ilgili görünüyor
Şimdilik ağırlıklı olarak yeni YSH dili üzerinde çalışıyorum, ama GUI çalışmalarını da canlandırmak isterim. UI programcısı olarak çok deneyimim yok; bu yüzden başka bakış açıları iyi olurdu
Ayrıca ggplot’u sevdiğim için onu dahil etmiş olmanız hoşuma gitti. Aslında ggplot, shell’de grafik olsaydı diye hayıflandığım yerin ta kendisi
Sondaki “Daha iyi olabilir. Nasıl yapılacağını göstereceğim” cümlesi bana sadece clickbait amaçlı bir giriş gibi görünüyor
“Bu modellerin gerçekliği yansıtması çok nadirdir. Yansıtırlarsa hoş bir tesadüf, yansıtmazlarsa felakettir” sözü benim deneyimimle örtüşmüyor
Genel olarak piyasadaki yazılımların çoğu ölümcül değildir. Bir sürü şişkin, berbat web uygulaması gün boyu gereksiz yere çok fazla kaynak emip, şurada burada düzensiz hatalar gösterirken kullanıcının beklediği işi berbat şekilde yerine getirebilir. Bunların hepsi doğru
Ama kalp pili ya da uzay roketi yöneten yazılımlar kadar ölümcül değiller. Yazılımların çoğunun berbat olmasında sakınca yok. Çünkü projelerin çoğu insanların kaprisleriyle ilgilidir; kalite eksikliğinin en kötü sonucu da felaket ya da ölüm değil, biraz hayal kırıklığıdır
Üstelik yazılım geliştiricilerin çoğu Silicon Valley tarzı para motivasyonuyla çalışmıyor, tutkuyla yapmak istedikleri projelerden geçimini sağlıyor da değil muhtemelen. Piyasaya çıkan yazılımların çoğu dışsal, berbat ödül yapıları aracılığıyla üretiliyor. Böyle bir sürecin ürününden çöp dışında ne bekliyorsunuz?
Eksik basamaklardan gerçekten nefret ediyorum
Ürettiğimiz yazılımın gerçek kullanımından çok uzağız ve geliştirme sürecini bilgilendiren kısa biçimli, çalıştırılabilir sinyalleri deneyimliyoruz. Yeni bir kullanıcıyla beden değiştiremediğimiz sürece, bu “bin kesikle ölüm”ün gerçek acısını doğru dürüst hissetmek zor
Programlamayı bir meslek alanı olarak görüyorum ve yazılım kalitesini yönetme gücümüz olduğuna inanıyorum. Sadece finansal olsun ya da olmasın, bizi gözlerimizi kaçırmaya iten teşvikler var
Bence bir yazılım krizi yok. Dünyadaki milyonlarca programcı bir ölçüde yararlı programlar yapıyor ve tost makineleri dahil neredeyse her şey yazılımı yeterince başarılı şekilde çalıştırıyor. Topluluk, 5 yaşındaki çocuklardan büyükanne ve büyükbabalara kadar herkesin erişebileceği programlar da yaptı. Burada ne krizi var?
Ama bir proje yönetimi krizi var. Bu yalnızca yazılımla sınırlı değil; planlayan insanlarla teslim eden insanların birbirinden uzaklaşması sorunu. Ve biz bu boşluğu kapatamıyor gibiyiz. Agile, Scrum vb., “guruların” hepimize aptal muamelesi yaptığı bu boşluğun göstergeleri ve biz de daha iyisini ortaya koyamıyoruz
Yazılım geliştirmenin metalaşması da bu karmaşaya katkıda bulunuyor. Girişi kolay bir alan olmasının doğası gereği, her seviyeden insan değişen başarı oranlarıyla katılabiliyor. Bu iyi-kötü meselesi değil, olgunun doğası. Gıda sektöründe Michelin yıldızlı restoranlar da MacDonalds da var ve ikisinin de tüketicisi var; bundan çok farklı değil. Buna restoran krizi demiyoruz
Bu da tost makinesinin ömrünü kısaltıyor. Eskiden 10 yıl giden tost makineleri olmuş olabilir. Artık kötü yazılım ve belki de zorunlu WiFi ya da Bluetooth bağlantısı yüzünden, tedarikçi güncellemeleri durdurduğunda 2 yıl sonra çöpe dönüşüyor. Belki hiç güncelleme almamış da olabilir. Kriz sadece doğrudan görünmediği ya da bugünkü aşırı tüketim ve durmadan yeni ürün alma alışkanlığı yüzünden her zaman göze çarpmadığı için fark edilmiyor
Tost makinesi 2 yıl sonra çalışmayı bıraksa bunu sorun etmeyebiliriz; nedenini umursamayabilir ya da bilmeyebiliriz. Ama Mirai botnet'inin bir parçası olmuş olabilir https://www.cloudflare.com/learning/ddos/glossary/mirai-botn...
Tost makineleri daha basit çipler kullandığından muhtemelen öyle değildi, ama kim bilir
Bu arada benim Dualit tost makinem yazılım çalıştırmıyor
“İç içe geçmiş soyutlama katmanları kurmanın ve bilgiyi birden çok düzeyde gizlemenin yolunu geliştirdik. Yazılım inşa etme sorununu yükselen katmanlar hâline getirdik” kısmı bana sızdıran soyutlamaları ve Babil Kulesi'ni hatırlatıyor
https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
https://en.wikipedia.org/wiki/Tower_of_Babel
https://en.wikipedia.org/wiki/Hierarchy
https://en.wikipedia.org/wiki/Abstraction
https://en.wikipedia.org/wiki/Abstraction_(computer_science)
Birbirleriyle karşılaştırmaya değer