Soğukkanlı Yazılım
(dubroy.com)- Bazı yazılım projeleri, sürdürülebilmek için kesintisiz geliştirme faaliyetine ihtiyaç duyan sıcakkanlı projelerdir; faaliyet dursa bile yeniden devam edilebilenler ise soğukkanlı tipe daha yakındır
- Soğukkanlı projeler, uzun süre durmuş olsa bile derleme ve testlerin bozulmaması için sıkıcı teknolojiler seçer ve değişebilecek ya da ortadan kalkabilecek dış hizmet bağımlılıklarından kaçınır
- Bağımlı olunan hizmetlerin satın alınması ya da kapanması, derleyici yükseltmeleri ve paket desteğinin sona ermesi, az faaliyet gösteren projeleri yeniden başlatırken bakım maliyeti olarak geri döner
- Kişisel projelerde olduğu gibi 1, 2, 3 yıl dokunulmayan kodda sürekli bir ısı üretmek zor olduğundan, en baştan düşük değişim oranı varsayımıyla tasarlanmalıdır
- Blog için statik site oluşturucu, 2012’deki ilk commit’ten bu yana Python 2, depoya dahil edilmiş 4 üçüncü taraf modül, yerel çalıştırma ve
rsyncoversshdağıtımıyla neredeyse hiç değişiklik yapılmadan çalışmaya devam ediyor
Soğukkanlı hayvan benzetmesiyle proje bakım biçimi
- 2004’teki bir doğa tarihi dersinde profesör, dondurucudan getirdiği bir painted turtle yavrusunu kameranın altına koyarak dersi sürdürdü
- Painted turtle yavrusu, donmuş haldeyken bile hayatta kalabilen az sayıdaki türden biriydi
- Bir saat boyunca kaplumbağa neredeyse fark edilmeyen hareketlerle başladı; sonunda ise ekranın yaklaşık yarısı kadar yol aldı
- Sıcakkanlı hayvanların vücut sıcaklığını dar bir aralıkta tutması gerekir; insanlarda yaklaşık 37°C civarından sapıldığında sorunlar ortaya çıkar
- Soğukkanlı hayvanlar metabolizmalarını ortam sıcaklığına göre ayarlar; hava sıcakken aktiftir, bedenleri ve çevre soğudukça daha yavaş hareket ederler
- Yazılım projeleri de benzer şekilde ayrılır
- Sıcakkanlı yazılım, projede sürekli hareket ve ısı olduğunda iyi çalışır
- 6 ay boyunca durdurulursa, yeniden çıkarıldığında ölü bir proje gibi hale gelmiş olabilir
Soğukkanlı yazılımın koşulları ve örnekleri
- Sıcakkanlı projelerin yeniden başlamasının zorlaşmasının nedeni, dış değişimlerin birikmesidir
- CI’ın bağımlı olduğu hizmet satın alınmış ya da parası bitmiş olduğu için çalışmayabilir
- Yeni bir bağımlılık eklemeye çalışırken derleyici yükseltmesi gerekebilir
- Başka bir paketin desteği kesilmiş ve en yeni derleyiciyle çalışmıyor olabilir
- Tek başına çalışılan, yalnızca ilham geldiğinde değiştirilen ve 1 yıldan uzun süre yeniden dokunulmayan projeleri sıcakkanlı şekilde işletmek zordur
- Soğukkanlı projeler, donmuş painted turtle yavrusu gibi, 1 yıl sonra bile kaldığı noktadan yeniden başlayabilmelidir
- Bunun için boring technology kullanılır; derleme ve test betiklerinin değişebilecek, bozulabilecek ya da tamamen ortadan kalkabilecek dış hizmetlere bağımlı olmaması sağlanır
- Bağımlılıklar, vendored dependencies yaklaşımında olduğu gibi proje deposunun içine dahil edilir
- Bu blogu çalıştıran yazılım, soğukkanlı bir projenin örneğidir
- İlk commit 8 Ocak 2012’de atıldı; eski bir Wordpress kurulumunun yerini almak üzere küçük bir statik site oluşturucu idi
- Python 2 ile yazıldı, 4 üçüncü taraf modüle bağımlı ve bunların hepsi proje deposuna commit edilmiş durumda
- Tüm süreç yerelde çalıştırılıyor ve çıktılar
rsyncoversshile dağıtılıyor - Birkaç küçük iyileştirme dışında değişiklik yapılmadan çalışmaya devam etti ve 12 yıl sonra da çalışmaya devam etmesi bekleniyor
1 yorum
Hacker News görüşleri
Node ve JavaScript ekosisteminin web framework’ü Express’te şu an ana sürüm 4.x.x, 10 yılı aşkın süredir korunuyor https://www.npmjs.com/package/express?activeTab=versions
Yine de haftada 17 milyondan fazla indirilecek kadar yaygın kullanılıyor https://www.npmjs.com/package/express; özellikleri eksik olabilir veya performansı en iyisi olmayabilir https://fastify.dev/benchmarks/, ama hızlı ve kararlı geliştirmeyi ve uzun vadeli planlamayı mümkün kılması iyi
Eski sürümlerde güvenlik yamalarının kesilmesi ya da sert API değişiklikleri konusunda endişelenmek gerekmiyor; Go ise geniş standart kütüphanesi ve uyumluluk sözü sayesinde 10 yıldan eski programları bile çalıştırabildiği için daha da kararlı https://go.dev/doc/go1compat
İlk çıktığında sırf JavaScript ile yazıldığı için sahte programcıların kullandığı uyduruk bir çöp muamelesi görüyordu, ama sonrasında birçok şirkette Express ile gerçek para kazanan harika servisler oluşturmaya yardımcı oldu ve bugün muhtemelen muazzam sayıda isteği işliyordur
Bugünlerde Go ile de çok yazıyorum, ama hâlâ Express ile servis geliştirmekten yeterince memnunum ve genel olarak iyi bir yazılım olduğunu düşünüyorum
Aslında nefret ettiğimden değil, daha çok bitmeyen sürüm yükseltme çarkı yüzünden onu seçmeyecek gibiyim
Python, soğukkanlı yazılıma örnek olarak çok kötü
Hem runtime’da hem araçlarda sürekli bozan değişiklikler var ve yazar da zaten desteği çoktan sona ermiş Python 2’yi kullanmaya devam etmek zorunda
Daha iyi örnekler, 10 yıllık kodun modern araçlarda da iyi çalıştığı Go veya Java gibi diller; daha uç bir örnek olarak da 30 yıllık kodun hâlâ iyi çalıştığı Perl verilebilir
Yazılım geliştirirken, kullanıcıların bir şeyi amaçlanmayan biçimde yapabilmesine izin veren hatalar yapılabiliyor; Java dünyasında bu, daha yeni, daha güvenli ve niyeti daha açık özellikler ekleyip kullanıcıların geçiş yapmasını teşvik ederek çözülüyor
Python da benzer, ama buna “ve yakında eski özelliği kapatacağız” ekleniyor; Java bunu yapmıyor
Örneğin
java.net.URLiçindekiequalsmetodu bozuk tasarımıyla bilinir ve şiddetle önerilmez, ama 20 yılı aşkın süredir desteklenmeye devam ediyorPython Airflow’daki boş operatör bir süre
DummyOperatoradını destekledi, ancak “dummy” kelimesinin tarihsel ve kültürel olarak aşağılayıcı bir ifade olarak kullanılmış olması nedeniyle bakımcılarEmptyOperatorkullanımına geçirdi ve eski adı bozduYükseltme yapınca, referans adını değiştirene kadar kod yükleme aşamasında hata veriyordu; şahsen kullanıcıları bu şekilde bozan bir değişiklik yapmazdım
Java dünyasında olsaydı, sırf ad değişikliği metin değiştirmeyle yeterince halledilebileceği için, devam ettirilemeyecek bir neden ortaya çıkana kadar desteklenirdi
Bu yüzden genel olarak Java ve Java kütüphanesi bağımlılıklarının Python’a göre çok daha rahat yükseltilebildiğini düşünüyorum
Java LTS sürümü kullanıp iyi bağımlılıklar seçerseniz, istediğiniz zaman tekrar çalışır hâle getirebilirsiniz
Python’da, makine öğrenimi dersinde bir bağımlılığın bir gecede API’yi bozan bir değişiklik yaptığı; eğitmenin de ders hazırlığına başladığı birkaç hafta önceki en güncel sürümü kullanmaya devam ettiği için bunu fark etmediği bir olay yaşanmıştı
Python 2’den 3’e geçiş bozan bir değişiklikti, ama bu tek seferlik bir değişimdi; “sürekli bozan değişiklikler” değildi
Aynı ana sürümde kaldığınız sürece yeni alt sürümler eski kodu bozmaz; örneğin eski 2.x kodu 2.7’de iyi çalışır, eski 3.x kodu da 3.12’de iyi çalışır
Alt sürüm değişikliği yeni özellikler ekleyebilir, ama eski 3.x kodun
asyncanahtar kelimesini veya type hint’leri kullanmaması kodu bozmazMümkün olduğunca Python’dan kaçınmamın nedenlerinden biri bu
Bugün yazdığım Python kodunun birkaç yıl sonra da çalışıyor olma ihtimalinin düşük olduğunu hissediyorum ve bunun epey büyük bir sorun olduğunu düşünüyorum
Yeni SDK ile 3 yıllık Java kodunu çalıştırmaya çalışsam bile her zaman bir yerler bozuluyordu
IBM mainframe’lerinde (z/OS) çalışıyorum; geriye dönük uyumluluğu koruma konusunda IBM’e yaklaşan çok az yer gördüm.
Microsoft Windows’un ikinci, Linux çekirdek ABI’sinin de üçüncü sırada olduğunu düşünüyorum; ancak Linux ekosisteminin tamamına bakınca bu yalnızca küçük bir parça.
Geri kalanların çoğu churn’e yakın; açık kaynakta da geriye dönük uyumluluğa hobi olarak zaman harcamak isteyen pek az kişi var gibi.
Ekonomik açıdan bu, mahkûm ikilemine benziyor: herkes uyumluluğu koruma maliyetini başkalarına yıkarken, sonuçta herkes için daha fazla işe yaramaz iş üretiyor.
Örneğin retro bilişim topluluklarına bakınca, yeni donanımların eski işletim sistemlerinde çalışması için sürücü yazılması da nadir değil.
Ücret yoksa, sonunda yaptığınız platformu ne kadar sevdiğinize kalıyor; ben de ABI kararlılığına yönelik kanıtlanmış bağlılığı nedeniyle Linux çekirdeğini doğrudan sistem çağrıları üzerinden hedeflemeye karar verdim.
Öte yandan kendi yaptığım programlama dilini mümkün olduğunca “mükemmel” yapmak istediğim için sürekli düzeltme isteği duyuyorum.
Birileri çılgınca kullanmaya kalkışır diye README’ye hâlâ erken geliştirme aşamasında ve kararsız olduğuna dair bir not koydum.
Ruby ya da Python’u yapanların da benzer hissettiğini düşünüyorum; dil insana çocuğu gibi geldiği ve başarılı olmasını istediği için
print’in anahtar sözcük olması gibi hataların düzeltilmesi gerektiğini düşünebilirler.Hatta çoğu zaman geriye dönük uyumluluk için konmuş kısımlar da bozuluyor.
Önceki işimde konteynerleştirilmiş bir Node uygulaması geliştiriyorduk ve CI, Node kaynak kodundan imaj derliyordu; bir süre dokunulmayan servislerin dağıtımları birden başarısız olmaya başladı.
Meğer Dockerfile, destek süresi bitmiş bir Ubuntu imajını temel alıyormuş; güncelleme deposu arşiv deposuna taşındığı için Dockerfile düzeltilmeden imaj derlenemiyordu.
Bu, dokunulmayan yazılımın bozulmasına bir örnek; bu yüzden Go’yu ve tekil ikili dosyaları tercih ediyorum.
Release olarak paketlerseniz yeniden derlemeniz gerekmez; Distroless Docker imajında da benim ikili dosyam dışında bağımlılık yok.
Go’yu uzun süredir kullanıyorum ama yazılımın yaşlandıkça bozulması sorununu hiç yaşamadım; Node ya da PHP kullanırken hissettiğim çeşitli sorunlar ortadan kalktı.
Node tarafındaki ikinci en büyük sorun framework’lerin dolaylılık kalıpları, birincisi ise paket yönetimi.
“X sürümünü kurdum ama Y modülü Z sürümünü gerektiriyor” gibi peer dependency sorunları sürekli çıkıyor.
Birçok mühendis GitHub’da kütüphane ararken son commit zamanına bakıyor.
Daha yeni commit’lerin, kütüphanenin daha iyi desteklendiği anlamına geldiğini düşünme eğilimi var.
Ancak ihtiyaç duyulan işi tam olarak yapan, 0 hatası olan ve yıllardır kararlı kalmış arşivlenmiş bir proje, ikinci el dükkânında gizli bir mücevher bulmak gibidir.
Günümüzde birçok mühendis “sürekli” güncellenmeyen kütüphaneleri otomatik olarak eliyor; bunu iyi bir şey sanıyor gibiler.
Modern yazılım geliştirme ortamları çoğu zaman böyle değildir; web front-end’i sık değişen tipik bir örnektir.
Tamamen bağımsız bir kütüphaneyse güncelleme olmaması sorun olmayabilir; ancak bir web front-end framework’üne bağımlı kütüphane, ekosistem değişimlerine göre güncellenmezse sorun çıkarır.
Gerçek rakamları bilmiyorum ama ezici çoğunlukta yakın zamanda etkinlik olmaması “tamamlandı ve hatasız” değil, “terk edildi” anlamına gelir diye düşünüyorum.
Bazı diller 1.0 sürümünden neredeyse bambaşka bir hale gelmişti; bazılarıysa yazılmış kodun çoğunu koruyup yalnızca üzerine eklemeler yapmıştı.
Sonuçta bu eğilim topluluğa ve ekosisteme de yansıyor gibi.
Clojure’un kıran değişiklikleri neredeyse hiç yapmadığı için listenin üst sıralarında olduğunu hatırlıyorum; 5 yıl önce son kez değişmiş bir kütüphane bile mevcut dil sürümünde kusursuz çalışıyor.
Lisp ailesinden olması ve dil çekirdeğini upstream değişiklik olmadan genişletebilmesi de yardımcı oluyor gibi; ama elbette bunun da kendi kusurları var.
Yine de “tazelik” ile “mükemmellik”in aynı şey olduğu fikrinden vazgeçmemi sağlaması güzeldi.
Bu günlerde geçen yıl yeni oluşturulmuş kütüphanelerden çok, birkaç yıldır neredeyse hiç değişmemiş kütüphaneleri daha sık kullanıyorum ve büyük sorun yaşamıyorum.
Bazı diller 1-2 yılda bir sürüm çıkarır ve sık kullanılan ama hantal kalmış kalıpların yerine yeni, zarif sözdizimi ya da standart kütüphane soyut veri türleri ekler.
O dilin topluluğu yeni sözdizimini neredeyse hemen “idiomatic” kabul eder ve eski, hantal yöntemle yazılmış kodun düzeltilmesi gerektiğini düşünür.
Belirli bir kod tabanını değiştirme gerekçesi genellikle eski yöntemin yeni sözdizimine kıyasla daha kapalı olması ve bakım ile kod incelemeyi zorlaştırmasıdır.
Yeni sözdizimi baştan beri var olsaydı kimse eski yöntemi iyi kod olarak görmezdi; dolayısıyla yeni geliştiriciler için okunabilirliği ve katkı eşiğini düşürmek adına kodun güncellenmesi gerektiği savunulur.
Böyle bir dille uygulanmış bir kütüphane 3 yıldan uzun süredir güncellenmemişse bu çoğu zaman kötü bir işaret olur.
Geliştiricinin, kodu dilin güncel biçimini öğrenmiş diğer geliştiricilerin kolayca okuyabileceği idiomatic kod olarak tutacak kadar toplulukla bağlantılı olmadığı anlamına gelebilir; dış PR’ları kabul etmeye ilgisi de olmayabilir.
Proje terk edilmiş gibi göründüğü için kimse raporlamıyor olabilir; ayrıca güvenlik açıkları da bulunabilir.
Güncelleme yapmadan yaşayabilen yazılım, en baştan doğru yapılmış yazılımdan ibarettir
Yalnızca kendiniz için olan yazılımlarda bu nispeten kolaydır; çünkü 10 yıl geçse de zevklerinizin çok değişmeme olasılığı yüksektir ve
nküçük olduğundan,O(n)fonksiyonu varkenO(n^2)fonksiyonu kullanan küçük bir sorun göz ardı edilebilirAma başkalarının kullanacağı bir yazılımsa gereksinimler farklıdır; yeterince büyük
NiçinO(n)fonksiyonunun değer kazanması gibi sorunlar ortaya çıkarKendiniz için de yazsanız başkaları için de, öngörülmeyen sorunlar çıkabilir
Örneğin 1 GB’tan büyük bir dosyayı işlerken çöküyordur ama normalde 100 KB altı dosyalar kullandığınız için önemsememişsinizdir; düzeltmeye kalkınca da yarısını yeniden yazmanız gerekebilir
Değişmeyen yazılımın sık değişen yazılımdan özünde daha iyi olduğu fikrine karşı en büyük itiraz burada yatıyor
Değişmeyen yazılım en başından kusursuz yapılmış olabilir; ama derinlerde saklanan bir dehşet de olabilir ve bunu önceden ayırt etmek zordur
Bu, hızlı güncellenen yazılımın yavaş güncellenenden özünde daha iyi olduğu anlamına da gelmez; güncelleme hızının dışında pek çok unsur vardır
Gereksinimler değişirse elbette yazılım da değişmelidir
Ama 10 yıl içinde gereksinim değişiklikleriyle ilgisi olmayan pek çok şey yaşanabilir
Açık kaynak projeleri terk edilebilir veya yön değiştirebilir, ticari yazılımlar sonlandırılabilir, şirketler satın alınabilir, App Store ya da Play Store kuralları değişebilir, API’ler kaybolabilir ya da fiyatları değişip projenin ekonomik mantığını bozabilir
Araç zincirleri, framework’ler, programlama dilleri, paradigmalar ve en iyi uygulamalar da değişir
Asıl noktanın, gereksinimlerle ilgisi olmayan dış değişimlerin beni değişime zorlamasını engellemek olduğunu düşünüyorum
İyi bir ilke; ama her zaman olduğu gibi burada da ödünleşimler var
Kararlı olmak ile eskimiş olmak farklı şeylerdir ve bu fark çoğu zaman güvenlikte ortaya çıkar
Önemli yeni bir gereksinimi karşılamak kolayken, vendored bir kütüphaneyi 7 ana sürüm birden yükseltmeniz gerekiyorsa ve bunun sonucunda alakasız bir sürü kırılma oluşuyorsa ne yapacaksınız?
Zamanın durduğu bir araç setine alışkın insan sayısı artık yeterli değilse ve kimse onu öğrenmek istemiyorsa ne yapacaksınız?
Bağımlılıkları dikkatli ve muhafazakâr seçmek iyi; ama bu şekilde küçük tuttuğunuz bağımlılık değişikliklerini bile takip etmemek bence bir adım fazla
Yazının duygusuna katılıyorum
Daha sadece birkaç yıl önce yapılmış bir mobil uygulamanın bile artık yama yapıp güncelleme göndermek için onlarca saat gerektirmesinden gerçekten nefret ediyorum
Yazarın kendi statik site üretecini soğukkanlı yazılım diye adlandırıp Python 2’de çalıştığını söylediği son kısım da ilginç
Python 2’yi bugünlerde kurmak giderek zorlaşıyor ve sonunda o proje de sıcak kanlı bir projeye dönüşecek
Xcode’u her yükselttiğimde projenin temiz şekilde derlenip çalışması için ufak tefek şeyleri düzeltmem gerekiyor; bu gerçekten sinir bozucu ve aslında tamamen kabul edilemez olması gereken bir şey
Son git kayıt mesajlarının hepsi “en yeni Xcode’da çalışacak şekilde düzeltildi” ifadesinin varyasyonları
Bu alt SDK veya OS değişiklikleri güvenlik tehditleri yüzünden gerekli olsaydı bir ölçüde anlayabilirdim, ama neredeyse hiç öyle olmuyor
Çoğu, API’yi kullanımdan kaldırmak, varsayılan uyarılar eklemek ve artık şu framework yerine bu framework’ü kullan demek gibi aptalca değişiklikler
Platformlar ve framework’ler kasıtlı olarak hareketli hedef olmayı bırakmalı; özellikle de artık çok kararlı ve güvenilir işletim sistemleri söz konusuysa
10 yıllık bir projeyi dondurucudan çıkardığınızda, 10 yıl önce olduğu gibi temizce derlenip çalışabilmeli
Bu işletim sistemi tedarikçileri trilyon dolarlık şirketler; bu yüzden geriye dönük uyumluluğun çok mühendislik emeği gerektirdiği bahanesini duymak istemiyorum
Kişisel yan projemi sürdürmeye devam ediyorum
12-13 yıl önce saf PHP ile başlamıştı; sonra Laravel ile yeniden yazdım, 2017 civarında da Symfony ile bir kez daha yeniden yazdım
Freelancer olarak tam zamanlı çalıştığım için enerjim olmadığından, 6-18 ay boyunca yalnızca 2-3 çok küçük commit yaptığım dönemler de oldu; ama zaman buldukça özellik ekledim, yükseltmeler yaptım, denedim ve öğrendim
Bir projeyi uzun vadede nasıl sürdüreceğimi öğrenmek açısından çok faydalı oldu
Bağımlılık güncellemeleri, gereksiz şeyleri kaldırma, güvenlik güncellemelerini kontrol etme, sadeleştirme fırsatları arama (Vagrant’tan Docker’a, Vue + Axios + Webpack vb.’den Htmx’e) gibi şeyleri öğrendim; nelerden kaçınmam gerektiğini de öğrendim
Kişisel olarak yeni çıkmış bağımlılıklardan, mikroservislerden ve Kubernetes gibi karmaşık altyapılardan kaçınır oldum
Son dönemde birkaç özellik geliştirdim ve PHP 8.2 ile Symfony 7’ye yükselttim; ChatGPT tabanlı bir özelliği de entegre ettim, bu yüzden istersem 1-3 yıl kadar ara verebilirim gibi görünüyor
Son 4-5 yılda bu proje, ortalama bir freelancer’ın 1 yıllık gelirine yakın ciro yaptı; yani uyuyan, isimsiz bir yan proje de değil
Birkaç yıl kullanmadıktan sonra geri döndüğümde, 8 yıl önce bıraktığımdakiyle aynı korkunç görüntü işleme fonksiyonlarının hâlâ yerinde durduğunu gördüm
Yazıda söylenenlerin dışında, özünde güvenli bir tehdit modeli de önemli
Örneğin tüm bir web sitesi saldırganlar ve spam botlarıyla sürekli uğraşmak zorunda olduğundan doğası gereği sıcak kanlı olmaya yakındır
Buna karşılık TiddlyWiki gibi statik bir sayfayı web’e hiç koymayabilirsiniz ve tarayıcı son derece kararlı bir platform olduğundan çok daha iyidir
Soğukkanlı projeler ile sıcakkanlı projelere yönelik tercih farkının, https://www.cs.utexas.edu/users/EWD/transcriptions/EWD11xx/EWD1175.html adresinde geçen Buxton Index ile ilgili olabileceğini düşünüyorum
Mahalledeki küçük bir bakkal için yaklaşık 0,5 yıl, gerçek bir Hristiyan için sonsuz, yeniden seçilmeyi hedefleyen ortalama bir politikacı için yaklaşık 4 yıl, çoğu sanayi dalı için bundan biraz daha uzun; çeyrek dönem raporu yazmak zorunda olan yöneticiler içinse çok daha kısa gibi
Buxton Index’in önemli olmasının nedeni, birbirinden çok farklı Buxton Index’e sahip özneler arasındaki yakın işbirliğinin kaçınılmaz olarak başarısız olması ve ahlaki suçlamalara yol açması
Kısa vadeli taraf yüzeysel ve miyop olmakla suçlanır; uzun vadeli taraf ise görevi ihmal, sorumluluktan kaçma ya da bedavacılıkla suçlanır
Birbirlerini aptal olarak da görmeye başlarlar
Buxton Index’in iyi tarafı, basit bir sayı kavramı olduğu için ahlaken nötr olması ve farklılıkları ahlaki tartışmanın üzerine taşıması
Akademi ile sanayi işbirliğini düşünürken özellikle önemli
Bu isim gerçekten çok kötü
Soğukkanlı hayvanlar çevreye büyük ölçüde bağımlıdır; sıcakkanlı hayvanlar ise metabolizmalarıyla dış sıcaklığa bağımlılığı azaltır
Her hâlükârda gereksiz yere muğlak
Sadece “dış bağımlılığı olmayan yazılım” deseler, uzun açıklama paragrafını ortadan kaldırabilirler
Doğadan alınmış uygunsuz benzetmelerle sığ sonuçlara atlayan yazılım geliştirme yazılarından da hoşlanmıyorum; ama benzetilen doğa olayının kendisini tamamen yanlış anlayıp bunu yapan yazılardan daha da hoşlanmıyorum
Boyalı kaplumbağa da dahil bazı türlerin donduktan sonra hayatta kalması soğukkanlı olmalarından değil, özel antifriz proteinleri sayesindedir
Diğer kertenkeleler ya da soğukkanlı hayvanların dokuları çözülürken parçalanır
https://lobste.rs/s/hitos3/cold_blooded_software#c_mxjzwh