“Nedeni kolay” - bu ne anlama geliyor? [kapalı]

Diğer geliştiricilerin bu ifadeyi bazı kalıpları "tanıtmak" veya en iyi uygulamaları geliştirmek için kullandıklarını çok fazla duydum. Çoğu zaman bu cümle, işlevsel programlamanın yararlarından bahsederken kullanılır.

"Kolayca anlaşılması kolay" ibaresi, herhangi bir açıklama veya kod örneği olmadan olduğu gibi kullanılmıştır. Bu yüzden benim için, daha "deneyimli" geliştiricilerin konuşmalarında kullandıkları bir sonraki "vızıltı" kelimesi gibi oluyor.

Soru: "Sebep etmesi kolay değil" gibi bazı örnekler verebilir misiniz? Bu nedenle, "Sebep etmesi kolay" örnekleri ile karşılaştırılabilir mi?

Aklıma, "hakkında akla kolay" ifadesi, "kafanızda çalıştırması" kolay olan kodu ifade eder.

Bir kod parçasına bakılırsa, kısa, açık bir şekilde yazılmış, iyi isimler ve minimum değer mutasyonu ile yazılmışsa, kodun yaptığı işi (göreceli olarak) kolay bir iştir.

Zayıf isimlerden oluşan uzun bir kod parçası, değeri sürekli değiştiren ve kıvrımlı dallanma değişkenleri normalde örneğin mevcut durumu izlemeye yardımcı olmak için bir kalem ve kağıt parçası gerektirecektir. Bu nedenle, bu tür kodlar sadece kafanızın içinden kolayca işlenemez, Bu nedenle böyle bir kodun anlaşılması kolay değildir.

Bir mekanizmanın veya bir kod parçasının ne yapacağını tahmin etmek için ne zaman hesaba katmanız gerektiğine dair kolay olması ve hesaba katmanız gereken şeylerin kolayca bulunabileceği konusunda anlaşılması kolaydır.

Yan etkisi olmayan ve durumu olmayan gerçek fonksiyonların kolay anlaşılması kolaydır, çünkü çıktı tam olarak parametrelerde bulunan girdi tarafından belirlenir.

Tersine, durumu olan bir nesnenin akla gelmesi çok daha zordur, çünkü bir yöntem çağrıldığında nesnenin hangi durumda olduğunu hesaba katmak zorundasınız; bu, nesnenin hangi durumlarda başka nesnelerin içinde olabileceğini düşünmeniz gerektiği anlamına gelir. özel durum.

Daha da kötüsü, genel değişkenler: genel bir değişken okuyan kodla ilgili olarak, kodunuzda bu değişkeni nerede ayarlayabileceğinizi ve neden - ve tüm bu yerleri bulmak kolay olmayabilir.

Akılda tutulması en zor olan şey, paylaşılan durumlu çok iş parçacıklı programlamadır, çünkü yalnızca sizin durumunuz olmaz, aynı anda birden fazla iş parçacığınız vardır, böylece bir iş parçacığı tarafından çalıştırıldığında ne gibi bir kod parçasının yapılması gerektiğine dair bir neden Her bir çalıştırma noktasında, başka bir iş parçacığının (veya birçoğunun!) kodun hemen hemen herhangi bir bölümünde çalıştırılıyor olması ve üzerinde çalıştığınız verileri gözünüzün altında değiştirmesi olasılığına izin vermeniz gerekir. Teorik olarak, bu, mutekslerle / monitörlerle / kritik bölümlerle / ne olursa olsun, ne olursa olsun, her şeyle yönetilebilir, ancak pratikte hiçbir insan, paylaşılan durumu ve / veya paralelliğini çok küçük bir şekilde sert bir şekilde sınırlandırmadıkça, güvenilir bir şekilde yapamaz. kodun bölümleri.

İşlevsel programlama durumunda, “Kolayca düşünülmesi kolay”, çoğunlukla belirleyici olduğu anlamına gelir. Bununla, belirli bir girişin daima aynı çıkışa yol açacağını kastediyordum. Programa ne istersen yapabilirsin, o kod parçasına dokunmadığın sürece, kırılmaz.

Öte yandan, OO'nun neden olduğu daha zordur, çünkü üretilen "çıktı", dahil olan her nesnenin iç durumuna bağlıdır. Gösterdiği tipik yol beklenmedik yan etkilerdir : kodun bir kısmını değiştirirken, görünüşte ilgisiz bir parça kopar.

... işlevsel programlamanın dezavantajı elbette ki pratikte, yapmak istediklerinizin çoğu IO ve durum yönetimi.

Ancak, üzerinde düşünülmesi daha zor olan pek çok şey var ve @Kilian ile aynı anda eşzamanlılığın en iyi örnek olduğunu kabul ediyorum. Dağıtılmış sistemler de.

Daha geniş tartışmalardan kaçınmak ve belirli bir soruyu ele almak:

Bazı nedenlerle "Nedeniyle kolay değil" örnekleri sunabilir, bu nedenle "Nedeniyle kolay" örnekleri ile karşılaştırılabilir mi?

Sana başvurmak için "Mel Öyküsü, Gerçek Programcı" , 1983 kadar uzanır ve bu nedenle meslek, 'efsane' olarak sayılır programcı folklor bir parça.

Kendinden referanslı ve kendi kendini değiştiren kod ve makine hatalarının kasıtlı bir şekilde kullanılması dahil olmak üzere, mümkün olan her yerde, yaylı tekniği tercih eden bir programcı yazma kodunun hikayesini anlatır:

apaçık bir sonsuz döngü aslında bir taşma hatasından faydalanacak şekilde kodlanmıştı. "X adresinden yükle" olarak kodu çözülmüş bir talimata 1 eklenmesi normalde "X adresinden yükle" değerini verdi. Ancak, x zaten mümkün olan en yüksek adres olduğunda, adres sadece sıfıra çevrilmemekle kalmadı, aynı zamanda opcode'un okunacağı bitlerin içine bir de 1 taşındı ve opcode "load" den "atla" a değiştirildi. Tam komutun "son adresden yükle" den "sıfıra atla" olarak değiştirildiğini

Bu 'mantıklı olması zor' bir kod örneğidir.

Elbette, Mel aynı fikirde olmazdı ...

Bir örnek ve çok yaygın bir örnek verebilirim.

Aşağıdaki C # kodunu göz önünde bulundurun.

// items is List<Item>
var names = new List<string>();
for (var i = 0; i < items.Count; i++)
{
    var item = items[i];
    var mangled = MyMangleFunction(item.Name);
    if (mangled.StartsWith("foo"))
    {
        names.Add(mangled);
    }
}

Şimdi bu alternatifi düşünün.

// items is List<Item>
var names = items
    .Select(item => MyMangleFunction(item.Name))
    .Where(s => s.StartsWith("foo"))
    .ToList();

İkinci örnekte, bu kodun bir bakışta ne yaptığını tam olarak biliyorum. Gördüğümde Select, öğelerin bir listesinin başka bir şeyin listesine dönüştüğünü biliyorum. Gördüğümde Where, bazı öğelerin filtrelendiğini biliyorum. Bir bakışta, ne namesolduğunu anlayabilir ve etkili bir şekilde kullanabilirim.

Bir fordöngü gördüğümde, kodu gerçekten okuyana kadar neler olup bittiğini bilmiyorum. Ve bazen tüm yan etkileri hesaba kattığımdan emin olmak için izlemem gerekiyor. İsimlerin ne olduğunu (tür tanımının ötesinde) ve etkili bir şekilde nasıl kullanılacağını anlamak için biraz çalışmam gerekiyor. Bu nedenle, ilk örnek, ikinciden yaklaşık olarak nedene göre daha zordur.

Nihayetinde, burada mantıklı olması kolay olması aynı zamanda LINQ yöntemlerini Selectve Where. Onları tanımıyorsanız, ikinci kodun başlangıçta nedenini düşünmek daha zordur. Ama onları bir kez anlamanın maliyetini ödersin. forHer kullanımda bir döngü tekrar ve her değiştiğinde tekrar maliyetini ödersiniz . Bazen maliyet ödemeye değerdir, ancak genellikle "nedenini düşünmesi daha kolay" olmak çok daha önemlidir.

İlgili bir cümle:

Bu kod "olması için yeterli değil hiçbir bariz hatalar ': bunun yerine,' olması gereken belli ki hiçbir hata ".

Nispeten "kolay anlaşılması kolay" bir örnek RAII olabilir .

Başka bir örnek ölümcül kucaklamadan kaçınıyor olabilir : eğer bir kilit tutabilir ve başka bir kilit alabilirseniz ve çok sayıda kilit varsa, ölümcül kucaklamanın oluşabileceği bir senaryo olmadığından emin olmak zordur. "Yalnızca bir (genel) kilit var" veya "ilk kilidi tutarken ikinci bir kilit alma izniniz yoktur" gibi bir kural eklemek, sistemin nedenini kolayca görmenizi sağlar.

Programlamanın temel noktası, vaka analizidir. Alan Perlis, bu konuyu Epigram # 32'de belirtti: Programcılar, yaratıcılıkları ve mantıkları ile değil, vaka analizlerinin eksiksizliği ile ölçülecek.

Vaka analizinin kolay olup olmadığıyla ilgili olarak bir durum kolayca anlaşılabilir. Bu, ya dikkate alınacak az sayıda vaka olduğu ya da birkaç özel durumun başarısız olacağı anlamına gelir; bazı büyük vaka alanları olabilir, ancak bazı düzenlemeler nedeniyle çökebilir ya da indüksiyon gibi bir muhakeme tekniğine yenik düşebilir.

Bir algoritmanın özyinelemeli bir versiyonunun, örneğin, zorunlu bir versiyona nazaran genellikle nedene göre daha kolaydır, çünkü özyinelemeli verisonda görünmeyen destekleyici durum değişkenlerinin mutasyonu yoluyla ortaya çıkan gereksiz durumlara katkıda bulunmaz. Ayrıca, özyinelemenin yapısı matematiksel bir indüksiyon kanıtı düzenine uyacak şekildedir. Döngü varyantları ve en zayıf katı önkoşullar gibi karmaşıklıkları dikkate almak zorunda değiliz.

Bunun bir başka yönü, durum alanının yapısıdır. Hiyerarşik bir duruma göre durumlara göre düz veya çoğunlukla düz bir şekilde bölünen bir durum hakkında düşünmek daha kolaydır: alt davalar ve alt davalar vb.

Akıl yürütmeyi basitleştiren bir sistem mülkiyeti dikliktir : bu, alt sistemler birleştirildiğinde alt sistemleri yöneten davaların bağımsız kalmasıdır. Hiçbir kombinasyon "özel durumlara" yol açmaz. Dört durumda bir şey üç durumda bir şey ortogonal olarak birleştirilirse, on iki durumda vardır, ancak ideal olarakher durum bağımsız kalan iki durumun birleşimidir. Bir anlamda, gerçekten on iki vaka yok; kombinasyonlar endişelenmemiz gereken sadece “yeni ortaya çıkan vaka benzeri fenomenler” dir. Bunun anlamı, diğer alt sistemdeki diğer üçünü göz önünde bulundurmadan düşünebileceğimiz dört vakamız olduğunu ve bunun tersidir. Bazı kombinasyonların özel olarak tanımlanması ve ek mantıkla donatılması gerekiyorsa, mantık yürütme daha zordur. En kötü durumda, her kombinasyonun özel bir kullanımı vardır ve orijinal dört ve üçe ek olarak on iki yeni durum vardır.

Elbette. Eşzamanlılık al:

Muteksler tarafından zorlanan kritik bölümler: anlaşılması kolaydır çünkü sadece bir prensip vardır (iki yürütme sırası aynı anda kritik bölüme giremez), fakat hem verimsizliğe hem de kilitlenmeye eğilimlidir.

Örneğin, kilitsiz programlama veya aktörler gibi alternatif modeller: potansiyel olarak çok daha zarif ve güçlü, ama cidden çok zor, çünkü artık "görünüşte o yere bu değeri yaz" gibi temel kavramlara güvenemezsiniz.

Sebep etmesi kolay olmak bir yöntemin bir yönüdür. Ancak, hangi yöntemin kullanılacağını seçmek, bütün yönleri bir arada ele almayı gerektirir .

Görevi resmi muhakeme ile sınırlayalım. Çünkü mizahçı, icat edici veya şiirsel akıl yürütmenin farklı yasaları vardır.

Öyle olsa bile, ifade kısaca tanımlanmıştır ve kesin bir şekilde ayarlanamaz. Ancak bu bizim için çok loş kalması gerektiği anlamına gelmiyor. Bir yapının bazı testlerden geçtiğini ve farklı noktalar için puanlar aldığını düşünelim. HER nokta için iyi işaretler, yapının her yönüyle uygun olduğu ve böylece "Hakkında kolay" olduğu anlamına gelir.

"Kolayca anlaşılması kolay" yapısı aşağıdakiler için iyi notlar almalıdır:

• İç terimler makul, kolay ayırt edilebilir ve tanımlanmış isimlere sahiptir. Elemanların bazı hiyerarşileri varsa, ebeveyn ve çocuk adları arasındaki fark kardeşlerin adları arasındaki farktan farklı olmalıdır.
• Yapısal elemanların tiplerinin sayısı düşük
• Kullanılan yapısal eleman tipleri alışkın olduğumuz kolay şeylerdir.
• Neredeyse anlaşılır elemanlar (özyinelemeler, meta adımlar, 4+ boyutlu geometri ...) yalıtılır - doğrudan birbirleriyle birleştirilmez. (örneğin, 1,2,3,4..n. boyutlu küpler için değişen bazı özyinelemeli kurallar üzerinde düşünmeye çalışırsanız, çok karmaşık olacaktır. Fakat bu kuralların her birini bir formüle aktarırsanız, n'ye bağlı olarak, her n küp için ayrı ayrı bir formüle ve ayrı ayrı böyle bir formül için bir özyineleme kuralına sahip olacaksınız.
• Yapısal elemanların tipleri açıkça farklıdır (örneğin, 0 ve 1'den başlayarak karışık diziler kullanmamak)

Test öznel mi? Evet, doğal olarak öyle. Fakat ifadenin kendisi de özneldir. Bir kişi için kolay olan, başka biri için kolay değildir. Bu nedenle, testler farklı alanlar için farklı olmalıdır.

Fonksiyonel diller mantığa mümkün olma fikri hakkında spesifik olarak, kendi geçmişinden gelen ML yapılara benzer bir programlama dili olarak geliştirildi hesaplanabilir fonksiyonlar için Mantık muhakeme kullanılır. Çoğu işlevsel dil, biçimsel programlama bilgisine zorunlu olanlardan daha yakındır, bu nedenle koddan bir muhakeme sisteminin girişine çevrilmesi daha az zordur.

Akıl yürütme sistemine bir örnek olarak, pi-hesapta, zorunlu bir dilde her bir değişken hafıza yerinin ayrı bir paralel işlem olarak gösterilmesi gerekirken, işlevsel işlemlerin bir dizisi tek bir işlemdir. LFC teoreminin kırk yıldan beri, GB RAM ile çalışıyoruz, bu yüzden yüzlerce işlemden daha az sorun var - yüzlerce C satırından olası kilitlenmeleri kaldırmak için pi-matematiği kullandım, yüzlerce C satırına sahip olmasına rağmen muhakemin durum alanını yaklaşık 3GB'ta tükettiğini ve aralıklı bir hatayı iyileştirdiğini işler. Bu, 70'lerde imkansız olurdu veya 1990'ların başında bir süper bilgisayar gerektiriyordu; oysa ki, benzer büyüklükteki bir işlevsel dil programının durum alanı, o zamanlar için düşünecek kadar küçüktü.

Diğer cevaplardan, zorunluluk dilleri hakkında düşünmeyi zorlaştıran zorluğun çoğu Moore yasası tarafından aşınmış olsa bile, ifade bir vızıltı-ötesi hale geliyor.

Sebep etmesi kolay, kültürel olarak özel bir terimdir, bu yüzden somut örnekler bulmak çok zor. Akıl yürütmeyi yapan insanlara bağlanan bir terimdir.

"Kolayca anlaşılması kolay" aslında çok açıklayıcı bir ifadedir. Eğer biri koda bakıyorsa ve ne yaptığını düşünmek istiyorsa, bu kolay =)

Tamam, kırılıyor. Koduna bakıyorsanız, genellikle bir şey yapmasını istersiniz. Yapması gerektiğini düşündüğün şeyi yaptığından emin olmak istiyorsun. Böylece, kodun ne yapılması gerektiğine dair teoriler geliştiriyorsunuz ve sonra neden kodun gerçekten işe yaradığını tartışmaya çalışmak için nedeniniz var. Kod gibi bir insan gibi (bir bilgisayar gibi değil) düşünmeye çalışın ve kodun yapabilecekleri hakkındaki argümanları rasyonelleştirmeye çalışın.

“Mantıklı sebep” için en kötü durum, kodun ne yaptığını anlamanın tek yolunun, tüm girişler için bir Turing makinesi gibi kod boyunca satır satır gitmesidir. Bu durumda, kodla ilgili herhangi bir şeye neden olmanın tek yolu, kendinizi bir bilgisayara dönüştürmek ve kafanızda çalıştırmaktır. Bu en kötü durum örnekleri RSA'nın şifresini çözen bu 3 PERL satırı gibi engelli programlama yarışmalarında kolayca görülebilir:

#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

Akla kolay gelince, yine terimi çok kültürel. Düşünmeniz gerekir:

• Muhasebecinin hangi becerileri var? Ne kadar tecrübe?
• Muhasebecinin kodla ilgili ne gibi soruları olabilir?
• muhabir ne kadar kesin olmalıdır?

Bunların her biri farklı "mantıklı olması kolay" ı etkiler. Muhakemin becerilerini örnek olarak alın. Şirketime başladığımda senaryolarımı MATLAB'da geliştirmem önerildi, çünkü “mantıklı olması kolay”. Neden? Şirketteki herkes MATLAB'ı tanıyordu. Farklı bir dil seçersem, birinin beni anlaması daha zor olur. Boşuna MATLAB'ın okunabilirliğinin bazı görevler için acımasız olduğu , çünkü onlar için tasarlanmadı. Daha sonra kariyerim ilerledikçe Python gittikçe daha popüler hale geldi. Birden MATLAB kodu "mantıklı olması zor" oldu ve Python, kolay anlaşılması kolay kod yazmayı tercih etti.

Ayrıca okuyucunun hangi adlara sahip olduğunu da düşünün. Belirli bir sözdiziminde bir FFT'yi tanımak için okuyucunuza güveniyorsanız, sözdizimine sadık kalırsanız, kod hakkında "mantıklı olması daha kolaydır". Nitty kumlu detaylarına girmek yerine metin dosyasına FFT çizdiğiniz kanvas olarak bakmalarını sağlar. C ++ kullanıyorsanız, okuyucularınızın stdkitaplıkta ne kadar rahat olduğunu öğrenin . İşlevsel programlamayı ne kadar seviyorlar? Konteynır kütüphanelerinden çıkan deyimlerin bazıları, tercih ettiğiniz idomatik stile bağlıdır.

Ayrıca okuyucunun cevaplamakla ne kadar soru ile ilgilenebileceğini anlamak da önemlidir. Okuyucularınız çoğunlukla kodun yüzeysel anlayışıyla mı ilgileniyor veya bağırsakların derinliklerinde böcek mi arıyorlar?

Okuyucunun ne kadar kesin olması gerektiği aslında ilginçtir. Pek çok durumda, puslu mantık, ürünü kapıdan çıkarmak için aslında yeterlidir. FAA uçuş yazılımı gibi diğer durumlarda, okuyucunun ironclad gerekçesine sahip olmak isteyecek. RAII'yi belirli bir görev için kullanmayı tartıştığım bir olaya karıştım, çünkü "Sadece kurabilir ve unutabilirsin ... doğru olanı yapacak." Bu konuda yanıldığımı söylediler. Bu yasaya gerek duyacak olanlar, "sadece detayları unutmak isteyen" insanlar değildi. Onlar için, RAII daha çok bir asma çağı gibiydi, onları kapsamdan ayrıldığınızda olabilecekler hakkında düşünmeye zorladı.