Zor şeyleri kolaylaştırmanın yolları

• Julia Evans’ın Strange Loop açılış konuşması, DNS, Bash, HTTP, SQL gibi “temel” görünüp öğrenmesi uzun süren teknolojilerin neden zor olduğunu ve öğrenme bariyerini düşürmenin yollarını ele alıyor
• Bash’in zorluğu, set -e’nin || koşulu içindeki fonksiyon çağrılarında devre dışı kalması gibi küçük istisna ve tuzakların çok olmasından ve birçok kişinin Bash’i yalnızca ara sıra kullanması nedeniyle ayrıntıları doğru hatırlamanın zor olmasından kaynaklanıyor
• HTTP ve SQL’de basit görünen yüzeyin altında tarayıcıların 20 milyon satırlık uygulamaları, çok sayıda header ve flag, SQL’in yazım sırası ile yürütme sırası arasındaki fark gizli; bu da öğrenme yükünü artırıyor
• DNS’te kütüphaneler, cache’ler ve yetkili name server’larla iletişim kullanıcıya pek görünmez; dig çıktısı da karmaşıktır. Bu yüzden gizli davranışları görünür kılan araçlar ve demolar önemlidir
• İyi öğrenme desteği; araçları ve referansları paylaşmak, büyük listeleri pratikte kullanılan küçük listelere indirmek, bilgisayarın yaptıklarını zaman sırasıyla anlatmak, başarısızlık hikâyelerini ve bug kayıtlarını da birlikte paylaşmaktır

---

“Temel” gibi görünen teknolojilerin neden uzun sürdüğü

• Strange Loop açılış konuşması Making Hard Things Easy, öğrenmesi zor teknolojileri daha kolay hale getirmenin yollarını ele alıyor
• Çıkış noktası DNS’ti
  • Bir alan adının IP adresini bulmak basit görünür; ancak konuşmacı, DNS’i öğrenmeye başladıktan 7 yıl sonra bile bir web sitesi yapılandırırken sorun yaşadığını ve genel olarak bunun yaklaşık 10 yıl sürdüğünü söylüyor
  • Arkadaşları da aynı sorunları tekrar tekrar yaşadı ve birçok kişinin bunu “zaten anlamış olmam gerekirdi” diyerek kişisel bir sorun gibi gördüğü bir durum sürdü
• Konuşmacı, bu tür konuları kolay anlaşılır biçimde anlatmak için Wizard Zines adlı küçük bir yayınevi kurdu ve Bash, HTTP, SQL, DNS’i örnek olarak kullandı

Bash: Hatırlaması zor istisnaları araçlar üstlenmeli

• Bash bir programlama dilidir, ancak konuşmacının kullandığı diller arasında tuhaf davranışları oldukça fazla olanlardan biridir
• Örnek betikte mv ./*.txt /tmmpp başarısız olsa bile Bash varsayılan olarak durmaz ve echo "success!" komutunu çalıştırır
  • set -e kullanırsanız hata durumunda durmasını sağlayabilirsiniz
  • Ancak fonksiyonu f || echo "failed!" gibi bir || koşulu içinde çağırırsanız, fonksiyonun içinde set -e global olarak devre dışı kalır ve yine success yazdırılır
  • Bu davranış bir Bash bug’ı değil, belgelenmiş bir davranıştır
• Bash’in zor olmasının nedenlerinden biri, birçok kişinin Bash betiğini yaklaşık 6 ayda bir yazıp sonra tekrar bakmamasıdır
  • Seyrek kullanılan bir sistem çok sayıda dağınık bilgi ve tuzakla doluysa, onu doğru kullanmak zordur
• “Bash’i kimse kullanamaz” tepkisi gerçeği yansıtmaz
  • Birçok kişi Bash kullanıyor ve kusursuz olmasa da sık sık işlerini çözüyor
  • Hedef, ezici bir tuzak yığınının karşısındaki kişiyi “genel olarak doğru kullanabilir” hale getirmektir
• ShellCheck, insanların ezberlemesi zor Bash tuzaklarını onların yerine hatırlayıp uyarı veren bir araçtır
  • shellcheck -o all bad-again.sh, SC2310 uyarısıyla || koşulunda çağrılan fonksiyonun set -e davranışını devre dışı bıraktığını bildirir
  • Bu kontrolün görünmesi için -o all ile çalıştırmak gerekir
  • Bu tür araçlar, dağınık bilgiyi bilgisayara devrederek bilişsel yükü azaltır

Başarısızlık hikâyeleri “best practice”lerden daha çok karar vermeye yardımcı olur

• Bir aracı bizzat yapmasanız bile, hâlihazırda kullandığınız faydalı araçları arkadaşlarınıza veya iş arkadaşlarınıza anlatmak önemlidir
  • Konuşmacı da ShellCheck’i geç öğrendiğini ve o zamana kadar her şeyi zihninde tutmak zorunda olmadığını fark edince sinirlendiğini söylüyor
• Tuzakları ve başarısızlık hikâyelerini paylaşmak neredeyse bir topluluk hizmetidir
  • Bash’te set -e’nin devre dışı kalması örneğini birkaç hafta önce arkadaşı Jesse’den duyduğu bir deneyimden öğrendi
  • Başkalarının başarısızlık hikâyelerini bilirseniz, aynı sorunu kendiniz yaşamadan önleyebilirsiniz
• “Kimse Bash kullanmamalı” gibi güçlü görüşler yerine, Bash’in pratikte ne tür sorunlara yol açtığına dair hikâyeler daha faydalıdır
  • Aynı hikâyeyi duyan bir kişi ShellCheck kullanıp basit Bash betiklerini sürdürmeye karar verebilir
  • Bir başkası Bash’i hiç kullanmak istemediğine karar verebilir
  • Aynı örneğe verilen tepkilerin farklı olması sorun değildir

HTTP: 20 milyon satırlık bir tarayıcıyı varsayarak anlamak gerekir

• HTTP yanıtı durum kodu, header’lar ve gövdeden oluşan basit bir yapı gibi görünebilir
• Ancak “header’ı neden ayarlamam gerekiyor?” sorusu hızla tarayıcı davranışına bağlanır
  • Firefox yaklaşık 20 milyon satır koddan oluşur
  • Tarayıcılar 1990’lardan bu yana evrilmiştir; güvenlik modeli de web’deki saldırılara ve değişimlere uyum sağlayarak sürekli değişmiştir
• Bir konunun neden zor olduğunu anlamak için arkasında çok büyük bir codebase olup olmadığına bakmak gerekir
  • Bu yalnızca HTTP’nin kendisini değil CSS, JS gibi şeyleri de kapsar; ancak modern tarayıcıların karmaşıklığı HTTP’nin öğrenme bariyerini açıklamaya yardımcı olur
• Büyük listeleri küçük listelere indirmek, anlamayı kolaylaştırır
  • HTTP request header listesinde 43’ten fazla öğe vardır ve gayriresmî header’lar da bulunur
  • Konuşmacı HTTP request headers çizgi romanında bildiği ve kullandığı 15 header’ı ele alıyor
  • “En önemli header’lar” nesnel bir liste değil, kişinin bildiği ve kullandığı öznel bir listedir
  • Örneğin Accept-Encoding değerini gzip olarak ayarlarsanız sıkıştırılmış yanıt alabileceğinizi bilmek genellikle yeterlidir
• Komut satırı araçlarına da aynı şekilde yaklaşılabilir
  • grep’in man page’inde çok sayıda flag vardır, ancak konuşmacı grep’i 20 yıldır kullanmasına rağmen hepsini bilmez
  • Deneyimli birinin “Ben bu sistemde yalnızca şu 7 şeyi biliyorum ve bunlar şunlar” demesi yeni başlayanlara yardımcı olur
  • Başka bir deneyimli kişi farklı 7 şeyi biliyor olabilir

Referanslar gerçekten kullandığınız biçimde dürüstçe paylaşılmalı

• İnsan zihnine sığmayan bilgiler için iyi referanslar gerekir
• Konuşmacı, CSS’i 20 yıl boyunca aralıklı olarak öğrenmesine rağmen CSS-Tricks sitesini ancak son yaklaşık 2 yılda öğrendiğini ve daha önce bilseydi faydalı olacağını söylüyor
  • CSS-Tricks’in satın alınmasından sonra nisan ayından beri yeni yazı yayımlamayı durdurmuş göründüğünü, ancak mevcut yazıların hâlâ faydalı olduğunu düşünüyor
• HTTP’de Mozilla Developer Network’ü çok kullanıyor
• HTTP’nin resmî referansları arasında 2022’de yazılan RFC 9110, 9111, 9112, 9113, 9114 bulunur
  • Connection header’ının tam davranışı gibi ayrıntılara bakılabilir
  • Konuşmacının ana referansı genellikle MDN’dir, ancak resmî RFC’lerin iyi düzenlenmiş olmasını değerli buluyor
• Referans paylaşırken havalı göründüğü için paylaşılan şeylerle gerçek işte kullanılan şeyleri ayırmak gerekir
  • Pratikte w3schools gibi “daha az havalı görünen” referanslar kullanılıyor olsa bile, gerçekten kullanılıp kullanılmadığını dürüstçe söylemek önemlidir

SQL: Bilgisayarın yaptıklarını zaman sırasıyla anlatmak

• SQL’de sorguyu yazma sırası ile gerçek kavramsal yürütme sırası farklı olduğundan, yeni öğrenenler için kafa karıştırıcı olabilir
• Konuşmacının kullandığı SQL zihinsel modeli şu sıradadır
  • FROM
  • WHERE
  • GROUP BY
  • HAVING
  • SELECT
  • ORDER BY
  • LIMIT
• Gerçek veritabanlarında optimizasyon olduğu için iş daha karmaşıktır; ancak bu zaman sıralı model çoğu durumda faydalıdır
  • Sorguda yazılan sıraya neredeyse aynıdır; fark, SELECT’in beşinci sırada olmasıdır
• “Bilgisayar gerçekte önce ne yapıyor?” diye sorma yöntemi başka konulara da uygulanabilir
  • CORS’ta tarayıcı ile sunucu arasındaki tüm iletişim zaman sırasıyla yazılarak anlaşılabilir
  • Konuşmacı CORS çizgi romanını bu yönteme örnek gösteriyor
• Zaman sıralı açıklama basit görünür ama aslında zordur; bu yüzden iş birliğinde faydalıdır
  • Behind Hello World on Linux, Linux’ta “hello world” çalıştırıldığında neler olduğunu ele alır
  • Konuşmacı 10 yıl önce de benzer bir yazı yazmıştı; ancak 2023 yazısı yaklaşık 6 kat daha uzundu
  • Bunun Linux’un daha karmaşık hale gelmesinden çok, 2013’te zaman sırasıyla neler olduğunu daha az biliyor olmasından kaynaklandığını düşünüyor
• Ekiplerde de bir API endpoint’ine istek geldiğinde neler olduğunu zaman sıralı bir timeline olarak birlikte çıkarmak, herkesin bildiği parçaları birleştirmeye yardımcı olur

DNS: Gizli sistemler görünür olunca sezgi gelişir

• DNS, tarayıcı, DNS isteği gönderen kütüphane fonksiyonları, cache’ler ve yetkili name server’ların birlikte çalıştığı bir yapıdır
• Sorun, bunların büyük kısmının kullanıcıya gizli olmasıdır
  • Hangi kütüphane kodunun DNS isteği gönderdiğini bulmak kolay değildir
  • Cache’lerin içinde tutulan verileri kolayca incelemek zordur ve kullanıcı bunları kontrol edemez
  • Cache ile yetkili name server arasındaki iletişim de görünmez
• Konuşmacı, arkadaşı Marie ile birlikte Mess With DNS adlı küçük bir DNS sunucusu yaptı
  • Kullanıcılar bir domaine DNS kayıtları oluşturabilir
  • Resolver’dan her istek geldiğinde hangi mesajın geldiğini gösterir
  • Strange Loop demosunda strangeloop adlı kayıt için orange.jvns.ca adresini gösteren bir CNAME kaydı oluşturuldu ve tarayıcının kullandığı Kanada DNS resolver’ının A ve AAAA kayıtlarını istediği görüldü
• Gizli olanı gösteren başka bir örnek float.exposed’dır
  • 32 bit floating-point sayıda significand ve exponent değiştirilerek bir sonraki floating-point sayı ve aralık değişimleri görülebilir
• DNS’in zor olmasının bir başka nedeni de devasa bir dağıtık sistem olmasıdır
  • Konuşmacı, “5 milyondan fazla bilgisayar işin içine girebilir” gibi bir ifadeyle, bunların çoğunu kullanıcının kontrol edemediğini ve bazılarının beklenenden farklı davranabileceğini söylüyor

dig çıktısı gibi araçlar öğrenme bariyerine dönüştüğünde

• DNS araçlarının çıktısı da kafa karışıklığını artırabilir
• dig’de +norecurse flag’i vardır
  • Resolver’dan yalnızca cache’inde zaten bulunan sonucu döndürmesini isteyebilirsiniz
  • dig +norecurse jvns.ca, ilgili resolver’ın son 5 dakika içinde bu domain’i cache’leyip cache’lemediğini kontrol etmek için kullanılabilir
• dig çıktısı yeni başlayanlara DNS’in kendisinin daha karmaşık olduğu izlenimini verebilir
  • Konuşmacı bunun, 1990’larda belirlenmiş görece keyfî bir çıktı formatının uzun süre korunmasının sonucu olduğunu düşünüyor
• “eraser eyes”, karmaşık bir çıktıda gerçekten bakılan kısımlar dışındaki yerleri siler gibi yok sayma yöntemidir
  • Örnekte yalnızca SERVFAIL response code’una odaklanılıyor
  • Konuşmacının anlayışına göre bu bağlamda SERVFAIL yaklaşık olarak “cache’te yok” anlamına gelir
• Bir aracı gösterirken hangi çıktıya veya UI’a bakıldığını ve hangi kısımların yok sayıldığını anlatmak öğrenmeye yardımcı olur
  • dig’in çıktısı kaba olsa da çok işlevli olması, +norecurse desteklemesi, her yerde bulunması ve uzun süredir değişmemiş olmasının getirdiği istikrar avantajdır

Birlikte kolaylaştıran roller

• Teknolojiyi kolaylaştırma pratikleri, blogunuz olmasa bile çevrenizdeki insanlarla paylaşılabilir
• Konuşmacının özetlediği yöntemler şunlardır
  • Faydalı araçları paylaşmak
  • Gerçekte kullanılan referansları paylaşmak
  • Bilgisayarda olanları zaman sırasıyla anlatmak
  • Büyük listeleri kişinin pratikte kullandığı küçük listelere indirmek
  • Gizli davranışları göstermek
  • Kafa karıştıran araçları demo ederken hangi kısma bakıldığını anlatmak
• Yardım eden insan türleri de çeşitlidir
  • “Huysuz eski kullanıcı”, geçmişte neyin yanlış gittiğini anlatarak zahmeti azaltır
  • “Gürültücü acemi”, “Bu nasıl çalışıyor?” diye sorarak başkalarını da rahatlatır
  • Kıdemli bir geliştirici bilmediği şeyi açıkça sorarsa, bilmediği için yargılanmaktan endişe eden kişiler de birlikte öğrenebilir
  • “Bug kayıtçısı”, aynı bug’ın tekrar yaşanmaması için ne olduğunu belgeler
  • “Araç geliştirici”, tekrar tekrar açıklamak yerine kod yazarak sorunu kalıcı olarak kolaylaştırır
  • “Bugün öğrendiğini paylaşan kişi”, yeni aracı, yaşadığı bug’ı veya yeni öğrendiği kütüphane özelliğini paylaşır
  • “700 sekme açmış kişi”, bilginin nerede bulunacağını zaten biliyor olabilir
  • “Soruları yanıtlayan kişi” ve “daha sonra bulunabilsin diye not alan kişi” de gereklidir
• Temel gibi görünen şeylerde zorlanmak yalnızca kişisel bir sorun değildir
  • Birçok kişi aynı nedenlerle aynı noktalarda zorlanır
  • Zorluğun nedenlerini anlarsak, bir bilgisayar programındaki bug’ı düzeltir gibi daha iyi düzeltebiliriz
• Zorluğu yaratan etkenler arasında devasa dağınık bilgi ve tuzaklar, 20 milyon satırlık kod, gizli sistemler ve iyileştirilmemiş kafa karıştırıcı araç çıktıları vardır
• Konuşmacı Git’in neden zor olduğunu hâlâ iyi anlamadığını, ancak düşünmeye ve anlamaya devam etmek istediği bir konu olarak bıraktığını belirtiyor

[GN⁺]

Hacker News yorumları

• Bana en çok dokunan kısım, normalde gizli olanı gösterin sözüydü.
  Bu tür araçlar durumu neredeyse anında daha anlaşılır hale getiriyor. Web tarayıcısındaki geliştirici araçlarını düşünün; bunların olmadığı “karanlık çağlarda” neler olup bittiğini göremeyip tahmin etmek zorunda kalmak berbattı.
  Wireshark gibi erişilebilir ağ paketlerinin baytlarını gösteren ve yapısını da ayrıştıran bir araç, yalnızca ağ hata ayıklaması için değil, hiçbir şeyi gizlemediği için ağ kavramlarını öğretmekte de çok faydalı.
  Açık kaynak yazılımları da bu yüzden seviyorum. Bir hatanın nedenini anlamak, dokümantasyonun bıraktığı bilgi boşluklarını doldurmak ya da programlama kavramlarını daha iyi öğrenmek için kaynağa bakabiliyorsunuz; yani hiçbir şey gizli değil.

  • Oyun geliştirme tarafında bunun karşılığı olan araç renderDoc. Varlığını ilk öğrendiğimde gerçekten çok şaşırmıştım.
  • Wireshark harika ama ağın taşıdığı her baytı göstermez.
    Örneğin Ethernet preamble’ını asla göstermez, Ethernet frame checksum’unu yalnızca bazen gösterir ve Ethernet protokolünün zorunlu bir unsuru olan frame’ler arası boşluğu da asla göstermez.
    Neredeyse çok yaklaşır, ama bir yerlerde her zaman daha fazla ayrıntının saklı olduğunu gösterir.
  • Hayalim, runtime’da her şeyi görselleştirilebilir hale getirmek. Bunu yapabilirsek tüm bilişimin çok basit ve çok daha az karmaşık hale geleceğini düşünüyorum.
    Zaten kafamızın içinde görselleştiriyoruz ve bilişimle ilgili herhangi bir açıklama eninde sonunda bir diyagrama dönüşüyor. Ama kod yazarken hiç diyagram yok.
    Tüm kodu dinamik olarak enstrümante edip GUI’ye mesaj göndermek yeterli.
  • “Normalde gizli olanı gösterin”, “bu tür araçlar durumu neredeyse anında netleştirir” sözlerinin aksine, günümüz DevOps araçları giderek daha fazla şeyi gizliyor gibi görünüyor.
    O bilgiye sahip olup öğretebilecek uzmanlar da artık kurumların içinde değil, bu araç şirketlerinde toplanmış durumda.
  • Emacs için Magit’te sevdiğim şey tam da bu. UI gerçekten zekice ve akıcı; kullandığım Git frontend’leri arasında en iyisi bile olabilir. Ama UI ile etkileşim biçiminiz, içerideki gerçek Git komut satırı argümanlarına eşlenen flag ve option’ları açıp kapatmak şeklinde.
    Bu yüzden komut satırına doğal biçimde geçtiğinizde, doğrudan kullanmaya hemen aşina oluyorsunuz.

• Julia, teknoloji sektöründeki en sempatik insanlardan biri gibi görünüyor.
  Yazılarını her okuduğumda, çocukken küçük deneylerle gerçekliğin sırlarını yeni yeni çözmeye başladığım zamanki heyecan yeniden kabarıyor. Gerçekten çok sevimli.

  • Derin teknik bilgi ile üstün öğretme ve iletişim becerisini aynı anda taşıyan insan azdır. Aklıma gelen bir diğer kişi Andrej Karpathy.
    Neyse ki son zamanlarda bu tipe uyan daha fazla insan keşfetmeye başladım.
  • Bir an Julia dili hakkında konuşuluyor sandım :)
  • Çok katılıyorum. Genelde “omg awesomesauce” tarzı aşırı coşkulu blog yazılarını ya da tutorial’ları pek sevmem; Landau&Lifschitz tarzı kuru, sinyal-gürültü oranı yüksek, özlü ve güzel yazıları çok daha fazla tercih ederim.
    Ama Julia’nın yazılarının hepsi, yukarıda bahsedilen o heyecanı hissettiriyor.
  • Yüz yüze de gerçekten çok sevimliydi. How DNS Works kitabımı imzalatmıştım.

• “Yeni başlayan biri ‘bu zor’ dediğinde deneyimli biri ‘evet, bash kullanılamaz; kimse onu düzgün bilmiyor’ der” sözü bence kelimesi kelimesine alınacak bir şey değil.
  Anlamı daha çok “yazdığımız bash kodunu ne kadar anladığımız ya da test etmediğimiz durumlarda bile beklediğimiz gibi çalışacağına dair güvenimiz çok güçlü değil”e yakın.
  Biraz bile sıradan olmayan bir şey olduğunda bir şeylerin bozulacağını ve bash hakkında yeni öğrendiğimiz bir gerçek yüzünden ürpereceğimizi ya da yakındaki bir şeye zarar verecek kadar sert vuracağımızı bir ölçüde bekliyoruz demek.
  Bash karmaşık bir dil ve çoğu programcı için günlükte kullandığı diğer dillerden tamamen farklı. Çoğu şirkette bir yerlerde production’da bir miktar bash vardır ama onu yeterince çok kullanıp iyi bilen tek bir kişi bile çoğu zaman yoktur.
  Build araçlarının, CI araçlarının ve cloud orchestration araçlarının shell scripting ihtiyacını azaltacak yönde evrilmesi bence tesadüf değil.

  • Bash gibi araçların karmaşıklığının evrim eksikliğinden geldiğini düşünüyorum.
    Bir düşünce deneyi olarak, bash’e daha iyi bir atama ifadesi eklenemez mi? Örneğin set --goodass gibi bir modda a = string1 + '.' + string2 yazılabilse, shell quoting işlemlerinin önemli bir kısmı kesilip atılabilir.
    make gibi araçlar da bundan fayda görür. makee 6 ay harcayıp kullanılabilir değişkenler, path ve dosya adı manipülasyonu için net yöntemler ve daha kullanılabilir target’lar yapmak, 6 ay boyunca karmaşık bir Makefile yapmaktan daha iyi olabilir.
  • Sorun, yeni başlayan kişinin bu örtük anlamı anlayıp anlamayacağı ya da niyet edilenden daha kelimesi kelimesine alıp almayacağı.
    Özellikle “çoğu programcı için bash, günlükte kullandığı herhangi bir dilden farklıdır” hissi, yeni başlayan birinin mutlaka çıkarabileceği bir şey değil. Çünkü “alışılmadık” ile “aşırı anlaşılmaz” arasındaki farkı bilecek kadar deneyim gerekiyor.

• Bununla bağlantılı olarak, çoğu yazılım aşırı tasarlanmış durumda.
  Bunda sektörün merkezileşmesinin de payı olduğunu düşünüyorum. Az sayıda aracı kontrol eden az sayıdaki kişinin çıkarına olacak şekilde herkesi o araçlara itiyorlar; sonuçta birçok araç “her şeyin aracı” haline gelip kapsaması gereken kullanım senaryolarının çok ötesini kaplıyor.
  Şirketler geliştiricilerin hepsinin aynı araçları bilmesini istiyor. Böylece projeler ve şirketler arasında kolayca ikame edilebilir oluyorlar ve sektörde pazarlık güçleri zayıflıyor.
  Bu yüzden yazılımda tek bir ana akım dal kalıyor, alternatif yaklaşımlar ise iş alanı bulamadan dışlanıyor. Sektör doğal olarak dağılmak istese de bunu başaramıyor.
  Olumlu bakarsak, bir gün çok daha üstün ana akım dışı yaklaşımlar ortaya çıkıp ana akım yaklaşımı kemirecek. Teknoloji matematik de değil, bilimden de farklı; aynı problemi farklı şekillerde çözen pek çok dalı rahatça taşıyabilir.

  • Katılıyorum. Bazı açılardan web geliştirme, erken dönem ASP.NET ya da Rails zamanlarına göre gerilemiş gibi bile geliyor.
    O zamanlar tarayıcı savaşları bizi meşgul ediyordu; şimdi ise tarayıcılar genel olarak uyumlu olmasına rağmen, çoğu zaman gereksiz olan web app frontend karmaşıklığını yığınla ürettik.
    DNS, IP, HTTPS gibi şeyler geriye dönük uyumluluk ve politik unsurların iç içe geçtiği temel teknolojiler olduğu için kaçınılmaz.
    Yine de bunları iyi öğrenmenin framework öğrenmekten daha iyi bir yatırım olduğunu hissediyorum. Daha fazla söylersem konu innovation token’lara kadar gider gibi.

• Zor şeyleri kolaylaştırmak için uygun bir soyutlama bulmak gerekir. Zor konunun bir kısmını ve sık kullanılan ayrıntıları akılda tutup, geri kalanını ihtiyaç olduğunda bakmak şeklinde
  Sorun, insanların gerçekten ihtiyaç duymadan büyük bir konu için bilişsel sıkıştırma oluşturmaya pek yanaşmamasında. Zaten başka büyük bilişsel yükler taşıdıkları için yeni bir yük eklemeye direniyorlar
  X adlı bir konuyu iyi bilen başka birine güvenebiliyorsanız, öyle yapar ve X'i yeterince öğrenmek için çaba göstermeyebilirsiniz. X'i iyi bilen birinin yardım taleplerini azaltmasının en iyi yolu, başkalarının X'in asgari kısmını anlamasına yardımcı olmaktır
  set -e bozuk; her şeyi tırnak içine alma zorunluluğu da bozuk, globbing de açıkça istenmesi gereken bir özellik olmalı. Komut satırında zahmetli olurdu ama script'lerde durum farklı; şu anda globbing'i global olarak kapatırsanız, istediğiniz yerlerde globbing yapmak zorlaşıyor
  Bu kötü varsayılanlar yalnızca Bash'te değil, Ksh ve Bourne shell soyundaki shell'lerin genelinde var
  SQL'de de clause sırasını değiştirmek isteyen çok kişi var. Yapılamaması için bir neden yok; mevcut SQL parser'larının farklı sıradaki clause'lara izin vermesini sağlayacak görece küçük bir değişiklik gibi görünüyor
  Ancak kişisel olarak bende bu bilişsel sorun yok; muhtemelen önce tablo kaynağına bakmam gerektiğini bildiğim için

  • set -e'nin bozuk olması, her şeyi tırnak içine almak gerekmesi ve globbing'in açık olması gerektiği şeklindeki üç tuzağı OSH, mevcut shell script'lerini çalıştırırken bile düzeltiyor
    Script'in en üstüne shopt --set ysh:upgrade eklerseniz bu üç sorun ortadan kalkıyor
    Projeye yardımcı olmak isterseniz tarball'ı indirip iddiayı doğrulamanız ve bir blog yazısı yazmanız iyi olur
    Ayrıntılar https://www.oilshell.org/release/latest/doc/error-handling.h... ve https://www.oilshell.org/release/latest/doc/simple-word-eval... adreslerinde
    Belgeler kapsamlı, ancak çoğu kişi bu kadar ayrıntı istemediğinden birinin test edip kısa bir yazı yazması faydalı olur
    Oils'i bir süredir aktif biçimde öne çıkarmamamın nedeni Python bağımlılığı olmasıydı; artık saf C++ ve bu hafta itibarıyla bazı hesaplama ağırlıklı benchmark'larda bash'i geçiyor
    Girdi/çıktı ağırlıklı script'ler, çoğu shell script'inde olduğu gibi her zaman aynı hızdaydı. Belgelerde Oil'in hâlâ YSH olarak değiştirilmesi gerekiyor; bu yüzden bir süre karışıklık olabilir: https://www.oilshell.org/blog/2023/03/rename.html
  • Daha iyi shell'ler varken bu antik shell'leri kullanmaya devam etmek sorun. Kullanıcılar set -e gibi ezoterik bilgileri ezberlemek için zaman harcamamalı. Yine de artık arama motorları var
  • SQL clause sırasını düzeltmenin biraz radikal bir yolu, select gibi davranan ama doğru yere konabilen project'i getirmek olabilir
  • Açıklamada gereksiz ayrıntılar olunca çok kafa karıştırıcı oluyor. Çehov'un silahı gibi sürekli olay örgüsüne uydurmaya çalışıyorsunuz ama uymuyor
    Benim süper gücüm berbat hafızam. Bu yüzden bir şeyi hatırlamak için mutlaka anlamam gerekiyor; yani bilişsel sıkıştırmaya ihtiyacım var. Normal insanlar gibi sadece öğrenemiyorum
  • SQL'i soyup alt katmana erişebilmek gerekir

• Bugünkü öğrendiğim: && veya || listesinde çalıştırılan komutlar arasında, son && ya da || sonrasındaki komut hariç, başarısız olan komutlar olsa bile shell sonlanmıyor
  Referans: https://www.gnu.org/software/bash/manual/bash.html#index-set

  • “Başarısızlık”, shell’in umursadığından daha üst düzey bir kavram. Başarısızlık koşulu ve buna verilecek tepki tamamen programcının takdirinde; shell’e varsayım olarak gömülü değil
    /bin/false’un yaptığı tek şey 1 döndürmek. Bu başarısızlık mı? Hayır. Öyle çalışmak üzere tasarlanmış ve kelimenin tam anlamıyla amacı bu olan bir araç
    Yüzlerce shell betiği yazdım; bunlardaki pek çok komut, bir dizgenin belirli bir desene sahip olup olmadığını kontrol etmek gibi kendi işini yapmak için son derece normal biçimde 0 olmayan değerler döndürüyor
    Bir program herhangi bir durumda istediği çıkış kodunu döndürebilir; geleneksel olarak başarı 0, başarısızlık ise 0 olmayan değerdir. Ama shell dilinin umursadığı tek şey 0’ın “doğru”, 0 olmayan değerin “yanlış” olarak değerlendirilmesidir
    Herhangi bir program 0 olmayan bir değer döndürdüğünde shell sonlansaydı, if ifadeleri ve döngüler imkânsız hale gelir, bu da çok kullanışsız olurdu
    Belirli bir programın dönüş kodunu önemli bulan bir betikse, bunu açıkça kontrol edip ele almalı. Bağlantıda olduğu gibi, içteki bir komut 0 olmayan değer döndürürse shell’in sonlanmasını sağlayan seçenekler var ve birçok başlangıç-orta seviye shell betiği yazarı bunların tüm betiklerde kullanılması gerektiğini dogmatik biçimde savunuyor
    Ancak karmaşık betiklerde bunun biraz hacky ve başa çıkması zor çok sayıda uç durumu olduğunu düşünüyorum. Her seferinde böyle seçeneklere ihtiyaç duyuyorsanız, belki de Makefile kullanmak daha iyi olabilir
  • Çünkü && ve || koşul ifadeleri gibi sık kullanılır
    [ -e README ] && cat README, README dosyası yokken hatadan kaçınır; [ -e README ] || echo "You should write a README!" ise bunun tersini yapar
    Daha sinsi sorun şu: set -e varsaysanız bile, pipeline’da son komut başarısız olmazsa shell sonlanmaz
    set -o pipefail da kullanmadığınız sürece grep foo README | sort, README olmasa bile başarısız sayılmaz
  • Bence bu, shell dili tasarımının en büyük kusurlarından biri. Çünkü bir fonksiyon, argümanlarından bağımsız olarak, çağrıldığı bağlama göre farklı sonuçlara yol açabiliyor
    Hatta fonksiyon içinde açıkça set -e ayarlasanız bile bunun üzerine yazılıyor
    Daha önce bir örnek vermiştim: https://news.ycombinator.com/item?id=22213830
  • Shell’de öğrenilmesi gereken çok fazla ezoterik bilgi var. Bir noktada omuz silkip, hızlı sonuç almak için fena olmayan ama sağlam programlar yazmaya uygun olmayan bir araç olduğunu kabul etmek gerekiyor

• Zor olmaması gerekiyormuş gibi görünen ama gerçekte çok fazla karmaşıklık barındıran şeyleri iyi anlatan bir yazı
  Ancak SQL kısmı, gizemi çözmekten çok kavramsal hatayı daha da ileri götürüyor gibi görünüyor
  Sorgunun mantığı deklaratiftir ve çıktıyı tanımlar. Çalıştırma sırası ya da prosedürel nitelik taşıyan şey sorgu planıdır. Önce bunun öğrenilmesi gerekir
  Sonrasında bağımlı alt sorgular gibi muğlak alanlar öğrenilebilir. not exists ile anti join’in eşdeğer olduğunu görebiliyorsanız, anlayıp akıl yürütebilirsiniz
  Yazılmış sorguyu prosedürel olarak anlamaya yönelik benzetmeler sorunu sadece erteler; daha karmaşık bir şeye takıldığınızda iyi niyetli yalanı çözmenin yolu kalmaz

  • SQL bölümü, sorguyu anlamaya yardımcı olan bir zihinsel modelden bahsediyordu; gerçek veritabanının bunu muhtemelen böyle işlemediğini de belirtmişti
  • Postgres hakkında yakın tarihli ilgili bir bölüm, ancak çoğu durumda diğer veritabanlarına da genişletilerek düşünülebilir: https://www.se-radio.net/2023/09/se-radio-583-lukas-fittl-on...

• Harika bir sunumdu. Bash’in “tuzaklar” ve ansiklopedik küçük bilgilerle dolu olduğu ve bunların hepsini ezberlemenin zor olduğu doğru; ama bazı küçük bilgileri ezberlemekte de fayda olduğunu düşünüyorum
  Örneğin find komutunun argüman sırasını sık sık unutuyordum; internete hemen bağlanamayan bir makinenin başında sözdizimini hatırlamaya çalışırken zaman kaybediyordum
  Bu yüzden en yaygın komut satırı araçlarını ve bunların bazı tuzaklarını öğrenip ezberlemeye karar verdim; Anki ve birkaç hafıza tekniği kullandım. Yatırımın getirisine kesinlikle değdiğini düşünüyorum

  • Anki, DNS gibi zor şeyleri anlamakta benim can simidim
    Aslında jvns.ca’daki kitap önerisini görüp Michael W. Lucas’ın Networking for System Administrators kitabını okudum ve teknik bilgiyle azımsanmayacak sistem yöneticiliği bilgeliğini Anki kartlarına çıkardım
    Şimdi taşıma katmanı sorunlarını debug ederken netcat ve tcpdump gibi araçları anında nasıl kullanmam gerektiğini hatırlıyorum; bu yüzden okuduğum kitaplar arasında yatırım getirisi en yüksek olanlardan biri olabilir
  • Sık kullanmadığım komutları topladığım bir dosya tutuyorum. Örneğin ffmpeg ile sesi yükseltmek ya da convert ile bir görsele kenarlık eklemek gibi komutlar
    Son çalıştırdığım komutu bu dosyaya ekleyen bir kısayol ve bu dosyada arama yapan bir kısayol da hazırladım
  • man sayfaları hemen kullanılabilir durumda
    bash man sayfası devasa ve karmaşık ama kapsamlı. Ana bölümlere ve metnin görsel yapısına aşinaysanız, hızlıca göz gezdirip ihtiyacınız olan kesin bilgiyi bulabiliyorsunuz; bu oldukça faydalı oldu
    Bu yöntem çoğu zaman internet arama motoru kullanmaktan daha hızlı olabiliyor
  • İnternete bağımlı kalmadan ve kötü tasarımı ezberlemek zorunda olmadan, daha genel dokümantasyon/cheatsheetlere yatırım yapmak daha iyi olabilir
    Eski man sayfalarını metin editörlerine daha uygun bir biçime dönüştürmek ya da tldr, Dash gibi daha iyi araçlar kullanmak gibi. Çünkü sorun yalnızca find ile sınırlı değil
  • Bash kullanmayı bırakıp yerine TypeScript kullanmak gerekiyor. Bash berbat

• Nedenini bilmiyorum ama bu yazıdan hoşlanmak istemiştim. Sanırım jvns HN’de çok sık karşıma çıkıyordu ya da keyfim yoktu.
  Ama gerçekten iyi bir yazı ve 20 yıllık geliştirme deneyimi olan biri olarak, programlama üzerine meta düzeydeki tartışmalar içinde gerçeğe epey yakın olduğunu düşünüyorum.
  Seçici görüş meselesi hem dig hem de man sayfalarına gerçekten çok uyuyor. man’i açıp sonsuz yapılandırma seçenekleri ve komut satırı bayrakları karşısında bunaldığım sayısız kez oldu.
  man için kullandığım ipucu, Vim tarzı arama özelliği olan / kullanmak. Örneğin grep’te her eşleşmenin satır numarasını nasıl yazdıracağımı bulmak istiyor ama hatırlamıyorsam man grep açıp /line yazar ve Enter’a basarak man sayfasındaki “line” geçişlerini ararım. Sonraki eşleşme için sadece / yeter.
  Strange Loop’un bittiği haberi de biraz üzdü. Ancak geçen yıl civarında haberdar olmuştum; birçok sunumun olağanüstü kaliteli olduğu görünüyordu.

  • Alex Miller’ın yakın zamanda yayımlanan sunumuna bakmak iyi olabilir: https://www.youtube.com/watch?v=suv76aL0NrA
    Bitmiş olması üzücü ama bazen bir şeyin sona ermesinin de iyi olabileceğini oldukça ikna edici biçimde gösteriyor. Sunumun tamamını izlerseniz anlaşılıyor.
  • https://cheat.sh hayat kurtarıcı.
    Ayrıca https://github.com/kristopolous/mansnip de yaptım.
  • Sonraki eşleşme için n tuşuna da basabilirsiniz.

• Bash hakkındaki bakış açısına kesinlikle katılmıyorum. En iyi çözüm bash’in üzerine araçlar koymak ya da tuhaflıklarını ezberlemek değil, bash kullanmamak.
  Tuzaklardan kaçınmanın tek yolu bu.

  • Bash’in hâlâ doğru düzgün bir alternatifini bulamadım. Özellikle betiklerde durum daha da böyle.
    En yaygın alternatifler 1) Oil shell [0] gibi yeni bir shell kullanmak ya da 2) Python, JavaScript, PHP gibi programlama dilleri kullanmak.
    Yeni shell’lerin sorunu, betiği çalıştırmak istediğiniz her yere o shell’i kurmak zorunda olmanız. Buna karşılık bash her yerde var. Tek başınıza bakımını yaptığınız bir betik değilse, başkalarından da o shell’i öğrenip bakım yapmalarını istemiş oluyorsunuz.
    Diğer programlama dillerinin sorunu ise bash’in iyi yaptığı şeylerde, yani komutları birbirine bağlamak ve komut girdi/çıktılarıyla dosyaları yönetmekte kullanılabilirliğinin nadiren yakalanması.
    Bunu başka dillerle yapmaya çalışınca birden çok daha karmaşık ya da en azından daha laf kalabalığı olan bir hâle geliyor.
    Bu yüzden hâlâ bash kullanıyorum, ama gücünün başka komutları çalıştırmak ve giriş/çıkışı yönetmekte olduğunu kabul ediyorum. Bunlarla ilgili olmayan karmaşık bir mantık varsa başka bir dile devrediyorum. Bazen bu, bash’ten tamamen kaçınmak değil de bash içinden bir Python betiği çağırmak oluyor.
    Başka bir yaklaşım sizde daha iyi çalıştıysa paylaşırsanız iyi olur.
    [0] https://www.oilshell.org
  • Geçerli bir nokta. Bash zaten aşırı karmaşık bir araç; bash’i daha az karmaşık yapmak için üstüne başka bir araç yazmak tuhaf.
    Üstelik o yeni araç, bash’in geçtiği onlarca yıllık hata ayıklamadan da geçmemiş olacak. Sorun bash’in kendisinde.
    Kullanım kolaylığını küçümseyip “zekice” olmayı abartma eğilimindeyiz.
    Bunun tipik örneği Git. Çok zekice bir araç ama kullanım kolaylığı berbat. Yine de Linus yaptı ve Linus zeki, dolayısıyla sorun bizdeymiş gibi görülüyor.
    Değer verdiğimiz şeyleri elde ederiz. Kullanım kolaylığına daha çok değer vermeliyiz.
  • shellcheck’in büyük hayranıyım ve bash’i gerçekten derinlemesine kullandım, ama hiçbir linter ya da bash’in üstündeki araç bunu düzeltemez.
    En iyi çözüm ondan uzak durmak. Gerçekten durmamız gerekiyor. Maço gibi davranmaya çalışmamalıyız.
    Dilin bütün modeli temelden bozuk. String merkezli tipler, global mod anahtarları, temel karşılaştırma operatörlerinde tek harflik bayraklar, hataların birçok yerde varsayılan olarak yok sayılması ve özellikle de fonksiyonlar.
    Bu tuhaflıklardan tek biri bile bir dili elemek için yeterliyken bash’te bunların hepsi ve daha fazlası var.
  • Bash’in tuhaf olmasının nedeni genel amaçlı bir dil olmaması. Yazıda bahsedilen şeylerin de kendince iyi nedenleri var. Örneğin set -x’in || ve && için beklenen davranışı bozabilmesi gibi.
    Zaten bir fonksiyon false döndürdü diye çakışan kaç dil var? İstisna fırlatan diller var, ama “false” döndürülmesi geçerli bir değer değil mi?
    Makefile’da da aynı şeyi görüyoruz. İnsanlar ne yaptıklarını anlamıyor, build sistemleri üzerine derin düşünmemiş oluyor ve belli bir şekilde davranmasını bekliyor.
    Örneğin Make’in özyinelemeli ataması neredeyse herkesi tökezletir.
    FLAGS=-b, COMPILE=compile $(FLAGS), $(info compile command=$(COMPILE)), FLAGS=-a, myfile:, echo $(COMPILE) $? -o $@ ilk bilgi çıktısında compile -b gösterir ama gerçek çalıştırma compile -a -o myfile olur.
    Buna rağmen tüm atamaları başka programlama dilleriyle uyumlu olsun diye anında değerlendirilen hâle getirirseniz, çok kullanışlı bir aracı elinizden almış olursunuz. Bu tür araçları ne kadar iyi anlarsanız, nerede kullanacağınızı ve ne kadar emek harcayacağınızı da o kadar iyi bilirsiniz.
  • Söylendiği kadar kolay değil ve bash’i tamamen ortadan kaldırmak zaman ve emek açısından her zaman değmeyebilir.
    Yine de genel olarak katılıyorum. Biraz olsun karmaşık olan şeyleri daha az tuhaf bir dilde yazılmış betiklere devretmeye çalışıyorum.
    O durumda bash olarak kalan son %5’te hata yapmaktan kaçınmaya yardımcı olan araçlar çok kullanışlı.