KISS prensibi programlama dili tasarımına uygulandı mı?

KISS ("basit, aptalca tut" veya "basit aptalca tut", örneğin buraya bakın ), görünüşte mühendislikten kaynaklansa bile, yazılım geliştirmede önemli bir ilkedir. Vikipedi makalesinden alıntı:

İlke, Johnson'ın tasarım mühendislerinden oluşan bir ekibin bir avuç araç teslim etmesinin hikayesi ile örneklendiriliyor; tasarladıkları jet uçağının, sadece bu araçlarla savaş koşullarında alandaki ortalama bir tamirci tarafından onarılabilmesi zorluğu. Bu nedenle, 'aptal' şeylerin kırılma şekli ile bunları düzeltmek için mevcut olan karmaşıklık arasındaki ilişkiyi ifade eder.

Bunu yazılım geliştirme alanına uygulamak isteseydim, "jet uçağı" yerine "yazılım parçası", "ortalama mekanik" ile "ortalama geliştirici" ve "mücadele koşulları altında" ile beklenen yazılım geliştirme / bakım altında " koşulları "(son tarihler, zaman kısıtlamaları, toplantılar / kesintiler, mevcut araçlar vb.).

Bu nedenle, daha sonra üzerinde çalışmanın kolay olması için bir yazılım parçasını basit (veya virgül kullanmamanız durumunda basit aptal) tutmaya çalışması yaygın olarak kabul edilen bir fikirdir .

Peki KISS prensibi programlama dili tasarımına da uygulanabilir mi? Bu prensip göz önünde bulundurularak özel olarak tasarlanmış herhangi bir programlama dili biliyor musunuz, yani "ortalama çalışma koşullarında ortalama bir programcının en az bilişsel çaba ile mümkün olduğunca çok kod yazmasına ve bakımını yapmasına izin vermek"?

Belirli bir dili belirtirseniz, bu amacın dil tasarımcıları tarafından açıkça ifade edildiği bir belgeye bağlantı ekleyebilmeniz harika olurdu. Her durumda, belirli bir programlama dili hakkındaki kişisel görüşünüz yerine tasarımcıların (belgelenmiş) niyetleri hakkında bilgi edinmek isterim.

Minimyalizmi düşündüğümde, Lisp ve Go'yu düşünüyorum . Lisp ile sahip olduğunuz tek şey, alabileceğiniz kadar basit olan işlevler ve listelerdir (biraz daha fazlası var, ama her neyse). Ancak, Go vakasının daha ilginç olduğunu düşünüyorum.

Go basit olacak şekilde tasarlandı (iyi bir okuma). Kullandıkları terim "özellik dikeyliği" dir, yani herhangi bir özelliğin yalnızca gerçekten benzersiz bir şey sağlıyorsa eklenmesi gerekir. Bu, yazarların ( Russ Cox ve Rob Pike akla gelen) Plan9'a katılımıyla , UNIX'in akılda basitlikle yeniden canlandırılmasıyla sonuçlanıyor gibi görünüyor. (Minimal tasarıma ilgi duyuyorsanız, Rob Pike'ın basit bir pencere sistemindeki makalesi iyi bir okuma.)

İşte sözdiziminin bazı basit örnekleri:

Sadece bir döngü yapısı

Bir döngü aşağıdakilerden birine benzeyebilir:

Sonsuz döngü

for {
}

Döngü sırasında

for <conditional> {
}

Döngü için geleneksel

for i := 0; i < 10; i++ {
}

Foreach döngüsü

// works for maps or arrays
for k, v := range arr {
}

Çok amaçlı anahtar

switch {
    // cases must be evaluate to a boolean
}

switch <value> {
}

switch t := <value>; t {
    // can use t inside
}

Çoklu dönüş

return val1, val2, ...

• Atma ihtiyacını ortadan kaldırır (hatayı son dönüş değeri olarak ilet)
• Out parametrelerine olan ihtiyacı ortadan kaldırır
• Tuples ihtiyacını ortadan kaldırır

Arayüzler

type X interface {
    DoSomething()
    String() string
}

• Jeneriklerle benzer problemleri çözer
• Soyutlamaya izin verir

Gömme

type A struct {
    Thing string
}

type B struct {
    A // embeds A in B, so B.Thing refers to A.Thing
}

• Kalıtım ile aynı sorunu çözer
• Sınıflara olan ihtiyacı ortadan kaldırır

Kanallar

Semaforları uygulamak için kullanılabilir

var c = make(chan bool, 1)
c<-true // semaphore lock
<-c // semaphore free

İleti dizileri arasında geçiş yapmak için kullanılır

func produce(c chan<- bool) {
    for {
        c <- true
    }
}
func consume(c <-chan bool) {
    for {
        <-c
    }
}

var c = make(chan bool)
go produce(c)
go consume(c)

Eşzamansız olayları işlemek için kullanılabilir

func async() chan bool {
    var c = make(chan bool)
    go doSomethingAsync(c)
    return c
}

// wait for long async process to finish
c := async()
select {
    case _ = <-c:
}

Sonuç

Sözdiziminin her yerine girmeyeceğim, ama umarım minimalizmin neler yapabileceğini görebilirsiniz. Dil, bir sürü yeni özellik eklediği için değil, başka bir dilden en iyi özellikleri ekstra bir şey kullanmadan kullandığı için ilgi çekicidir.

Bir sorunu çözmenin genellikle bir "en iyi" yolu vardır. Örneğin, posta listesinde birçok kullanıcı jenerik olmamasından şikayet ediyor. Tartışmadan sonra, yapmak istedikleri her şeyin arayüzlerle yapılabileceğini fark ederler. Deyimsel sözdizimi ile ilgili örnekler için etkili bir şekilde okuyun .

KISS dillerinin yararı, deyimsel kod yazmak mümkündür, çünkü kod stili dil tarafından kısıtlanmıştır. Örneğin, Go'da böyle bir şey yazamazsınız:

if <condition>
    statement;

Kıvırcık parantez kullanmanız gerekir:

if <condition> {
    statement;
}

Sözdiziminde bunun diğer birçok örneği vardır, bu da diğer insanların kodlarını okumayı kolaylaştırır.

KISS dilinin özellikli dillere göre avantajları:

• başkalarının kodlarını anlamak daha kolay
• tüm dili kavramak daha kolay (C ++ anlaşılması zor olduğu için ünlüdür)
• sözdizimine değil algoritmaya odaklan

Bence Python Zen neden Python neden basit bir dil olduğunu benden daha iyi:

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

@Giorgio'ya yanıt olarak düzenleyin

Sorunuzun belirttiği gibi,

"Bu prensip göz önünde bulundurularak özel olarak tasarlanmış herhangi bir programlama dili biliyor musunuz, yani 'ortalama çalışma koşullarında ortalama bir programcının en az bilişsel çaba ile mümkün olduğunca çok kod yazmasına ve korumasına izin vermek"

Python benim için hemen akla gelen şey. Python'un tasarımı, Perl'in ünlü "Bunu yapmanın birden fazla yolu var" metodolojisine doğrudan yanıt veriyor. Bu harika olsa da, programcıların kolayca kod yazmasına izin verir, bakımda yardımcı olmaz. Daha önce Perl'de yazılmış (çok kötü yazılmış, kabul edeceğim) bir programı yönettikten sonra, Python'un hem iyi kodlama uygulamalarını hem de boğazı boğuşan dilini zorladığını takdir ediyorum.

Python, program yazarken sizi belirli bir metodolojiyi izlemeye zorlamaz. Sıkı Nesne Tabanlı programlama stilini takip etmeyi seçebilir veya sırayla yürütmek için basit bir komut dosyası yazabilirim. Bir sınıfı başlatmak zorunda kalmadan main(), Java'da yapmak zorunda olduğunuz yöntemi çağırmak çok güzel. (Ayrıca, Python'da stdout'a yazdırmak harika, ancak bu oldukça boş bir nokta).

Son olarak, dil ile geniş bir standart kütüphane dahil etmek "Piller Dahil" yöntemi harika. Paketler için bazı harici depolardan avlanmak yerine, ihtiyacım olanların çoğu zaten dilde yer alıyor. Bu harici repoya sahip olmak güzel, ancak temel bir işlem yapmak için onu kazmak zorunda değilsiniz.

"Basitliği" korumanın en önemli anahtarı, karmaşıklığın ne zaman gerekli olacağını anlamak ve sistemin bununla en iyi başa çıkabilen kısımlarına sahip olmaktır. Değişmez değerler, değişken değerler ve varlıklar arasında hiçbir ayrım yapmayan tek bir tür nesne referansına sahip olmak, Java'yı "basit" kılan, değerler ve varlıklar arasında ayrım yapma ihtiyacını ortadan kaldırmaz; sadece programcılara yardımcı olmak için araçlardan mahrum kalır.

Daha genel olarak, bir programlama dili veya çerçeve özelliği birden fazla kullanım durumunu desteklemeye çalışıyorsa, farklı kullanım durumlarında farklı davranışların uygun olacağı hiçbir durum olmayacağından emin olunmalıdır, ancak derleyici bunu söyleyemez. Onları ayırın. Bir dile veya çerçeveye daha fazla tür eklemek bir komplikasyon gibi görünebilir, ancak çoğu durumda işleri daha kolay hale getirebilir.

Örneğin, C'de imzalı ve imzasız türleri çevreleyen kuralların karışıklığını düşünün. Bu kuralların karmaşıklığı, bazı kodların sayıları temsil etmek için imzasız tamsayı türleri kullanmasından kaynaklanırken, diğer kodlar bir sarma cebir halkasının üyelerini temsil etmek için kullanır. (özellikle, tamsayı uyumlu mod 2ⁿ seti). Tür dönüştürme kuralları bazen bir kullanıma uygun, bazen diğerine uygun şekilde davranır. Ayrı sarma ve sarma olmayan türlere sahip olmak, tamsayı türlerinin sayısını iki katına çıkarır, ancak bunlarla ilişkili kuralları basitleştirebilir:

• Herhangi bir boyutta halka olmayan tamsayı tipi, herhangi bir boyutta bir halkaya atanabilir; bir halka sadece eşit veya daha küçük boyutlu bir halkaya atanabilir .

• Halka olmayan bir tam sayı ve bir halka içeren ilişkisel işleçler dışındaki işlemler, tamsayıyı dolaylı olarak halka türüne dönüştürür.

• Halkalar açıkça sayılara veya daha büyük halkalara dökülebilir; imzasız bir halkanın değeri, halkanın sıfıra eklendiğinde halka değerini verecek olan en küçük negatif olmayan tamsayıdır. İşaretli bir halkanın değeri, halkanın sıfıra eklendiğinde halka değerini verecek en küçük büyüklükte tamsayıdır ve bir bağlanma durumunda negatif değer tercih edilir.

• Yukarıda belirtilenler dışında, halkalar aynı boyutta veya daha küçük halkalara sahip operasyonlarla sınırlıdır.

• Farklı türdeki halka olmayan tamsayılar üzerindeki işlemler, sayıları, işlenenin tüm değerlerini barındırabilecek bir türe çevirmeli veya uygun bir tür yoksa derleyici tarafından reddedilmelidir.

Halka türlerini tanımlamak, tamsayı türlerinin sayısını iki katına çıkarmış gibi görünebilir, ancak taşınabilir kod yazmayı büyük ölçüde basitleştirecektir. Sayılar ve halkalar için aynı işaretsiz türleri kullanmak tür sayısını azaltır, ancak verimli taşınabilir kod yazmayı neredeyse imkansız hale getiren karmaşık kurallara yol açar.

Muhtemelen, Tcl bu hatlar boyunca geliştirildi. Bütün dil tek bir sayfada sadece 12 kuralla açıklanabilir . Oldukça basit ve tutarlıdır.

Tcl'nin yaratıcısı asıl hedefler olarak şunları iddia etti:

• Dil genişletilebilir olmalıdır: her uygulamanın dilin temel özelliklerine kendi özelliklerini eklemesi çok kolay olmalı ve uygulamaya özgü özellikler, sanki başlangıçtan itibaren dilde tasarlanmış gibi doğal görünmelidir.
• Dil çok basit ve genel olmalıdır, böylece birçok farklı uygulama ile kolayca çalışabilir ve böylece uygulamaların sağlayabileceği özellikleri kısıtlamaz.
• İlginç işlevselliklerin çoğu uygulamadan geleceğinden, dilin birincil amacı uzantıları entegre etmek veya "yapıştırmak" tır. Bu nedenle dilin entegrasyon için iyi olanakları olmalıdır.

" Tcl'nin Tarihçesi" nden - http://www.tcl.tk/about/history.html

Bir dil, KISS nedeniyle tasarımında sabitlenirse, büyüyemez. Büyüyemeyen bir dil ölecektir.

Aşağıdaki videoda Guy Steele akıllıca bir programlama dilinin büyümesine izin verilmesi gerektiğini ve nedenini açıklıyor. KISS uygularsanız, bir dil nasıl büyüyebilir, çünkü bir kez bırakıldığında, bir dizi araç sabittir ve asla değişmesine izin verilmez.

Guy Steele'nin 1998'de " Dilin Büyümesi " konulu ACM OOPSLA konferansındaki açılış konuşması , kullanıcıları tarafından yetiştirilebilecek bir programlama dili tasarlamanın önemini ve sorunlarını tartışıyor.

Bu bir saatlik bir video ama izlemeye değer. Guy Steele'nin kim olduğunu bilmiyorsanız, dil tasarımı hakkında konuşurken gerçekten yapmalısınız.

Bu videoyu cevap olarak seçiyorum, çünkü genel olarak dil tasarımına KISS uygulamasının yanlış olduğuna inanıyorum ve dil tasarımında dikkat çeken bir kişiden bir konuşma görmenin dil tasarımının geleceği konusundaki anlayışınızı genişletmeye yardımcı olacağını umuyorum.

Buraya dil tasarımı hakkında bilgi edinmek için geldiğinizden ve size KISS'i kullanmamanız için bir neden sunduğumdan beri, dil tasarımında yardım bulduğum bir şeyi işaret etmem adil olur. Gösterimlerin bilişsel boyutları

DÜZENLE

Yukarıdaki cevabı yazdığımda, bunun gerekçesine dayanıyordu: eğer bir motor sadece sabit bir araç seti ile korunabiliyorsa, o zaman dil tasarımına göre bu anlamı yeniden biçimlendirmem, bir dilin serbest bırakıldıktan sonra değiştirilemeyeceğidir. Yorumlar, bunun kastedilen şey olmadığını gösteriyor. Gözden geçirilmiş anlayışla daha uyumlu olacak bu değiştirilmiş cevabı ortaya koyalım.

Eğer gösterimlerin bilişsel boyutlarına bakarsanız, dil tasarımıyla ilişkili olan basitlikten çok sayıda rakip boyutun olduğunu öğrenir ve birine çok fazla odaklanırsanız, başkalarında acı çekersiniz. Basit bir şekilde (KISS) iyi odaklanılması ve dil tasarımında dikkat çeken insanlar tarafından desteklenmesi sorusuyla, bir tasarımı basit tutmaya çalışmanın diğer boyutları etkileyeceğini göstermek için Guy Steele tarafından yapılan konuşmayı gönderdim . Daha da önemlisi, sadece basitlik değil, birçok boyuta bakmanız ve bunların artılarını ve eksilerini tartmanız gerektiğini aktarmaya çalışıyorum.

Bruce McKinney'in BASIC, Kemeny ve Kurtz tasarımcılarının ağzına kelimeler koyan Hardcore Visual Basic'ten büyük bir alıntı . Benimkini vurgular.

Her bilgisayar dilinin kendi hissi, kendi atmosferi, kendi ruhu vardır. Bu ruhu gerçekten tanımlayamazsınız, ama gördüğünüzde ne olduğunu bilirsiniz. Basic'i Albert Einstein'a atfedilen bir ifadenin antitezi olarak düşünüyorum:

İşleri olabildiğince basitleştirin, ancak daha basit değil.

Bu alıntı Basic, John Kemeny ve Thomas Kurtz'un orijinal tasarımcıları tarafından yazılmış olsaydı, daha da basitleştirilecekti:

İşleri mümkün olduğunca basitleştirin.

Bu hardcore Visual Basic programcılarının yaşadığı çelişkidir. İşlerin basit, zarif ve sezgisel olmasını istiyoruz - ama değil. Programlarımızın gerçeği modellenmesini istiyoruz, ama istemiyorlar. Bilgisayar veya işletim sistemlerinin düşünmemizi istediği şekilde değil, dilimizin düşündüğümüz gibi çalışmasını istiyoruz - ancak bedelini ödemeye hazır değiliz .

Peki KISS prensibi programlama dili tasarımına da uygulanabilir mi? Bu prensip göz önünde bulundurularak özel olarak tasarlanmış herhangi bir programlama dili biliyor musunuz, yani "ortalama çalışma koşullarında ortalama bir programcının en az bilişsel çaba ile mümkün olduğunca çok kod yazmasına ve bakımını yapmasına izin vermek"?

"Basit" ile ne demek istediğinizi açıklığa kavuşturmak iyi bir şeydir, çünkü bence basit bir programlama dili, tanımınıza doğrudan tercüme etmeyen minimal sözdizimi ve birkaç özelliğe (Scheme, Forth, ML) sahip bir dildir. Gerçekten RAD (hızlı uygulama geliştirme) göz önünde bulundurularak dil tasarımı arıyorsanız ve bunlardan birkaçı var. Bu StackOverflow iş parçacığına bakın, örneğin: /programming/66227/what-is-the-best-multi-platform-rad-language

Henüz kimsenin C'den bahsetmediğine şaşırıyorum, basitliği birkaç önemli şekilde ilk sıraya koysa da, çoğu zaman programcılar basitliği takdir edemeyen radikal bir şekilde:

• Gizli bir sihir yok. Eğer yazarsanız a + bC, bunu en fazla tek montajcı talimatına derlemek edeceği garantisi var.

  Java gibi nispeten basit dillerde bile, gibi basit bir ifade a + bbirkaç mikrosaniye sürebilir (değişkenler dizeyse). Diğer diller, a + bpembe fillerin görünmesi için aşırı yüklenebilecek aşırı C ++ örneğiyle buna çok daha fazlasını ekler . C'de öyle değil: Bir işlev çağrısı değilse, birkaç nanosaniyeden fazla sürmez. Performansın bu öngörülebilirliği C'nin temel özelliklerinden biridir ve kesinlikle bir basitlik biçimidir.

• Veri türleri, bellekte oluşturmak isteyebileceğiniz tüm ilginç veri yapılarını açıklarken olabildiğince basittir: Yalnızca bir CPU'nun + toplama ( struct) + tekrarlama (diziler) + referansları (işaretçiler) işleyebileceği temel türler vardır ).

  Lisp tabanlı çeşitli dillerin bu bakımdan C'den çok daha basit olduğu doğrudur. Bununla birlikte, programcının belleği C'nin yaptığı gibi serbestçe değiştirmesine izin vermeye çalışmazlar.

• Özelliklerin dikliği: Özellikleri serbestçe birleştirebilirsiniz ve beklendiği gibi birlikte çalışacaktır. Birçok dil, belirli yapıların yalnızca tanımlı bağlamlarda görünmesine izin vererek bunu başarısız kılar.

  Örneğin C ve C ++ 'da değişken uzunluklu dizileri ele alalım: C, her yerde çalışma zamanı uzunluklarına izin verirken, C ++ standardını genişletmek için en liberal istekler yalnızca otomatik diziler gibi belirli bağlamlarda ve hatta yalnızca ilk boyutta onlara izin verir. Bu, C'nin yalnızca çalışma zamanında bilinen boyutlara sahip gerçek çok boyutlu dizileri işlemesine izin verirken, C ++ programcıları data[k + (j + i*lineLength)*lineCount]tekrar tekrar yazmak için azaltılır .

  Bunun başka bir örneği işaretçi: C'deki bir veri işaretçisi, bu gerçekten diğer bazı değişkenlerin bellek adresini tutan bir değişkenden başka bir şey değildir. İşaretçinin kendisi bir değişken olduğundan, çift işaretçi iyi tanımlanmış bir şeydir. Ne olduğunu intve ne int*olduğunu söyledim, ne int**olması gerektiği açık . Ne kesinlikle hiçbir ipucu var nerede C ++ başvuruları ile karşılaştırın int&&anlamını verilir intve int&!)

C'nin bu kadar nefretini kazanmasının tam olarak bu basitlik olduğu doğrudur: Dilin basitliği, programcıların kendileri için iyi olandan daha fazla özgürlüğe izin vererek tanımlanmamış davranış ve yanlış muamele işaretçileri ile birçok soruna yol açar. Özellikle, bir programcının bir değişkeni int (*array[m])(struct foo* (*arg)[n])okuyucuların baş ağrısı verme eğiliminde olan tipte olduğu gibi tanımlayan ortogonalitenin basitliği, çünkü gerçekten karmaşık şeyler, birkaç basit özelliğin liberal kombinasyonu ile çok özlü bir şekilde ifade edilebilir . Bu, C'nin üstün olduğu ve ona kullanımı zor bir dil olma ününü veren basitlik türüdür.

Ayrıca, dilin sadeliği, programcıyı zengin özellikli dillerden çok daha fazla kod yazmaya zorlayarak, hataların gelişmesi için daha verimli bir zemin sağlar. Bununla birlikte, birincil hedefiniz sanal bir makine değil gerçek bir bilgisayar programlamak ise mümkün olan en basit üst düzey dil olmaya devam etmektedir.

Java Wikipedia - Vikipedi'de açıkça belirtilmemesine rağmen, basitleştirmeden birkaç kez bahsedildi ve o günlerde tek ciddi OO yeteneğine sahip (terim gevşek kullanıldı) dil C ++, çünkü hepimizin bildiği gibi güçlü ama ihtiyatsız birkaç tuzak var.

JVM, çapraz platform geliştirmeyi basitleştirmenin bir yolu olarak tasarlandı ve "Bir kez yaz Her yerde çalıştır" birkaç yıl boyunca bir Java mantra haline geldi - yine, çerçevenin uygulanması basitti.

C # 'nın dilin basitleştirme kategorisine girdiğine inanıyorum.

Hm ... bu aslında 'olumlu' cevaplamak için zor bir soru, çünkü programlama dili tasarımında basitliği düşündüğümde (ve bununla çalışmak 'daha kolay'), hemen düşünüyorum:

1. Kodun "okunabilirliği" - dilin nesneleri, yöntemleri vb. Ne kadar iyi kapsadığı.
2. Dil API'lerinin ve arayüzlerinin tutarlılığı.

Orada iyi bunları yapmak dillerin bir dizi - ama ne zaman aklına bir dildir gelmez 'bir programlama dili olarak' iyi şeyler yapmak: PHP.

[Feragat - PHP yazdım ve PHP hala basit web projeleri için benim 'dile git'. Bu bir aşk eleştirisidir ...]

İlk olarak, PHP tipik olarak web sunucularında çalıştığı ortam için iyi sonuç verir. Kurulumu kolay, bakımı kolay vb.

Ben PHP ile mücadele nerede: "alışılmadık" bir şey yapmak istediğinizde - normalde düzenli olarak yapmadığınız bir şey (düşündüğümde bir SOAP web hizmeti tüketiyordu - ben bir şey değil PHP ile çok şey yaptıysanız) iki seçenekle karşılaşırsınız:

1) PHP için çeşitli açık kaynak uzantıları. PHP nesne modeli, arayüz tasarımının kütüphaneden kütüphaneye, geliştiriciden geliştiriciye çok tutarlı olmadığı yerlerde yeterince gevşek. Birinin daha önce hiç duymadığınız bir kitaplık kullandığı bir dizi kodla karşı karşıya kaldığınızda, dilin gevşek API / kitaplık oluşturulmasına izin verdiği için 'bunun ne halt ettiğini' anlamak için çok zaman harcıyorsunuz.

2) "Yerleşik" fonksiyonlar - çok şey var . Başka bir kütüphane bulmak ya da bir şekilde daha sonra üzerine tökezlemek için biraz işlevsellik uygulamak birkaç tavşan deliğinden geçtimimpossiblyfound_basefunction()

Bence basitlik tutarlılıktır.

Programlama dillerine yönelik KISS yaklaşımı, en azından programlama dillerini bir CPU'nun talimat seti, vb. İçin bir soyutlama katmanı olarak görüyorsanız, komik bir kavramdır. "KISS" i daha yakından tanımlamazsanız. Sadece burada söylüyorum, bir kağnı KISS bir arabaya sonuna kadar uygulandı.

Şimdi KISS'in başka bir yorumu, "gereksiz süslemeler olmadan akıllıca yapıldı ve aşırı karmaşık değil" gibi bir şey olabilir. Özellikle, benzer şeyler için çok fazla özel durum olmaması gerektiği, vb. İddia edilebilir. Genellikle matematik, şeyleri özüne kaynatmak için oldukça iyidir ve - o merak ediyorum - matematikçiler de programlama ve bilgisayarları düşünmek için biraz zaman harcadı. .

Programlama için oldukça ünlü 2 soyut model mevcuttur:

• Birincisi, bir makineyi tanımlayan turing makinesi ve bir bilgisayarın yapabileceği her şeyi hesaplayabilen basit bir öğretim modeli.
• Diğeri ise Church ve ark. ark. bu güçte eşdeğerdir

Eğlenceli olan şey: Turing makinesi düzeninde oldukça basit olsa da, kullanımı kolay bir sistem değildir ve "akıllı ÖPÜCÜK" için uygun olduğunu düşünmüyorum. Ancak Lambda Matematik bildiğimiz programlama dilleri ile daha çok ilgilidir - ve lambda hesabının öncü özellikleri Lisp ve Scheme ile birçok dile dönüşmüştür.

Lisp ve Scheme GERÇEKTEN basittir, en azından sözdizimi bakımından. Sözdizimi programlama dillerinde büyük bir sorundur (muhtemelen bu yüzden sürekli yeniden keşfedilirler). C ++ durumunda, insan beyninin bazı kaynak hatlarının derleyici tarafından nasıl yorumlandığını tahmin etmesi neredeyse hiç değişmezdir.)

Lisps, komutlar için ortak bir form getirerek sözdizimsel karmaşıklığı tamamen azaltır:

(command param1 param2 ...)

Bu, aşağıdaki gibi bir yöntem çağrısı olabilir:

(max 1 2 3 4)

yanı sıra bir if şube, döngü vb.

(if (< 1 2) 
    (write 4)
    (write 5))

(buradaki tüm kod sözde Lisp / Dialect agnostic'tir)

Form

(command param1 param2 ...)

liste olarak da yorumlanabilir

(item1 item2 item3)

Ve bu Lisps basitliği ve güzelliğinin temeli. Çünkü iç içe listeler ( ififade örneğinde olduğu gibi) ağaçlar oluşturur ve bunlar hem makine hem de makine önünde bulunan insanlar tarafından kolayca anlaşılabilir.

Lisps'in bir başka özelliği de, buradaki kirli ayrıntıya girmeyeceğim makrolardır , ancak normal işlev çağrıları ile "Sözdizimi (döngüler için yumurta, değişken bildirimi, vb.) Arasında sözdizimsel bir fark olmadığından, ayrıştırıcının diğerlerinde işlemesi gereken her şey programlama dilleri) kendi sözdiziminizi oluşturabilirsiniz Makrolar özünde programınızı oluşturan Ağacın Manipülasyonlarıdır .

Bence Lisp'in programlamaya bir öpücük var. Sözdizimini makroları kullanarak değiştirebileceğiniz, Lisp'in oldukça dinamik bir şekilde evrimleştiği bir fenomene yol açtı. Nesne yönelim diyelim - yeni bir Dil özelliğine ihtiyacınız var - makrolarla bir OOP sistemi yazmanız yeterli!

C, OOP özellikleri (C ++, Obj. C) ile dolambaçlı yaklaşık 2 kez genişletilirken, Lisp birden fazla kez genişletildi, sonunda bir kazanan vardı.

Bu Lisp ile ilgili başka bir tuhaflıktır, gelişir (ilginç yeni Lisp Mutasyonu için bkz. Clojure ve Clojurescript).

KISS özellikleri nedeniyle Lisps, bazıları tarafından dil öğretimi olarak tercih edilir. Fogus'un bir eğitim dili taslağındaki ana hatları gibi ( http://blog.fogus.me/2013/01/21/enfield-a-programming-language-designed-for-pedagogy/ )

Başlamak için, yeni öğrenirken ve bazen karmaşık konuları öğrenirken anlamsız sözdizimi kuralları olan öğrencileri aşırı yüklemenin zararlı olduğuna inanıyorum. Bu nedenle, Enfield en az sözdizimi kuralları ve Lisp benzeri bir sözdiziminden daha az olanıyla tasarlanmıştır.