Bir programlama dili için detaylandırma neden kötüdür? [kapalı]

Pek çok insanı programlama dillerinde ayrıntılandırma konusunda şikayetçi olduklarını gördüm. Bazı sınırlar içinde bir programlama dili ne kadar ayrıntılı olursa, o kadar iyi anlamaktır. Ayrıca, ayrıntıların APIo dil için daha net yazımları güçlendirdiğini düşünüyorum .

Aklıma gelen tek dezavantajı sizi daha çok yazmanızdır, ama demek istediğim, çoğu insan sizin için tüm işleri yapan IDE'leri kullanır.

Peki, ayrıntılı bir programlama dilinin olası olumsuz yönleri nelerdir?

Amaç hızlı anlamadır

"Ayrıntılı", "çok fazla kelime kullandığı" anlamına gelir. Asıl soru, "çok fazla" dır.

İyi kodun bir bakışta anlaşılması kolay olmalıdır. Karakterlerin çoğu doğrudan kodun amacına hizmet ediyorsa, bu daha kolaydır .

Sinyal vs Gürültü

Bir ederse dil ayrıntılı olduğunu, kodunuzun daha gürültüdür. Karşılaştırma Java'nın "Hello World" :

class HelloWorldApp {
    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}

... Ruby'ninkiyle:

print "Hello World!"

Gürültü zihinsel enerjiyi boşa harcar.

Cryptic vs Clear

Öte yandan, bir dilde aşırı durgunluk da zihinsel enerjiye mal olmaktadır. Bu iki örneği Common Lisp'ten karşılaştırın :

(car '(1 2 3))   # 3 characters whose meaning must be memorized
# vs
(first '(1 2 3)) # 5 characters whose meaning is obvious

Tek bakışta ne kadar kod görebileceğinizi ve ayrıştırdığınızı etkiler

x++ ziyade set(x,Integeradd(get(x),1))

ps. Bu sadece bir kod okuma meselesi değil. 40x25 ekran günlerinde APL dilleri veya Perl, Cobol veya Fortran üzerinde okuyabileceğiniz / kodlayabileceğiniz kod miktarı için kullanışlıdır. Ama şimdi, kendi dahili önbelleğiniz hakkında daha fazla şey - bir ifadenin tek bir operatörü varsa, yaşlanan beynimin 3 sembol ve 4 işlev çağrısıyla birinden daha fazla ayrıştırması daha kolay.

Dil ayrıntılarını kod okunabilirliğinden saptarsa, o zaman kötü olur.

Bazı dillerde kodun anlamını kavramak daha uzun sözlü sözdizimine sahiptir (VB.NET'i C # 'ya karşı düşünüyorum):

If something Then
End If

if(something)
{}

Gerçekten bir kodlayıcının aşina ve rahat olduğu şeyle kaynaşıyor.

Bakmak git AppleScript , bunu düşünülebilir kapalı aklınıza gelebilecek en ayrıntılı dillerinden birinde akım , denemek trival şeyler yazmak o ve geri gelmek ve denemek ve bu ayrıntı bir dilde iyi bir özelliktir savunuyorlar.

Her gün yapmazsanız, anahtar kelimelerin nereye gittiğinin ve ne olduklarının anlamının önemsiz olduğunu hatırlamaya çalışmak.

Bu önemsiz örnekteki tüm anahtar kelime gürültüsüne bakın:

tell application "Finder"
    if folder "Applications" of startup disk exists then
        return count files in folder "Applications" of startup disk
    else
        return 0
    end if
end tell

bashGeleneksel Unix araçları ile aynı şeyi verdiğimizde çoğu OSX kullanıcısı için kısa ama kriptik olur, bu nedenle atılması gereken bir denge vardır.

Sanırım soruyu kafasına açıp sormaya ihtiyacınız var: Bazı insanlar niçin kısa kodun iyi olduğunu düşünüyor?

Cevabım, iki temel sebep olacağı yönünde olurdu:

Neden Terse Daha İyi Olabilir?

Bunlar, kısa bir cümlenin çiçekli, ayrıntılı bir cümleye göre daha anlaşılabilir olabileceği şekilde daha okunabilir olmayı içerir. Genellikle, İngilizce dilinin gramerini deneyen ve taklit eden programlama dilleri, en basit eylemleri gerçekleştirmek için muazzam kod genişlemesi gerektiren korkunç derecede uzun sarılı kalır. Genellikle bir dilin ne kadar çok bir yazı dilini öykündüğünü, o zaman zorlaşan mantıksal olarak karmaşık işlemleri gerçekleştirmeye zorlamaktır.

Neden Terse Daha Kötü Olabilir?

Bazı diller (ve Perl'i düşünüyorum) sözdizimlerinin bir parçası olarak neredeyse keyfi olarak seçilmiş gibi görünen bir dizi garip semboller kullanırlar. Bu hiyeroglifleri tanımayan herkes için o zaman dil aşılamaz hale gelir. Ayrıca kolayca görülmeyen yazım hatası yapmak da kolaylaşır. Düzenli ifadeler, belki de bu tür bir zıtlığı özetler.

Ayrıca, bazı insanlar kısa ve öz kod yazarak gösteriş yapmaktan hoşlanırlar, çünkü açıkçası onların zeki görünmelerini sağlar. Bunu bazen insanların okunabilirlik pahasına son derece kompakt cevaplar göndereceği StackOverflow'ta görebilirsiniz. Bu, felsefeyi ne kadar bildiğinizle ilgili olarak "akranlarınızı etkileyin" bir türdür, ancak iyi programcılar " kod golf " un bakım yazılımı oluşturmanın bir yolu olmadığını fark eder .

Frowing, ayrıntılı konuya bakmanın bir yolunun, programlamanın her zaman bir çözümü bulmanın ve ifade etmenin oldukça farklı iki stilinin bir karışımı olduğunu fark etmesini öneririm.

İlk ve daha ayrıntılı stil, dil odaklı (dilsel) programlamadır. Bu stil, isim benzeri kelimeleri ve fiil benzeri kelimeleri cümle benzeri yapılarda birleştirir ve iyi yazılmış bir paragrafla aynı şekilde okunması ve anlaşılması amaçlanmıştır. Dil programlama evrenseldir, çünkü dil evrenseldir, çünkü programlama evrenseldir. Aynı nedenle, uzun vadeli program desteği her zaman güçlü bir dilsel bileşene ihtiyaç duyar, çünkü yeni bir programcının arayacağı ilk şey ne yapıldığının kavramsal olarak anlaşılmasıdır. Genel bir kural olarak, bir programı oluşturduğunuz bağlamdan uzaklaştıkça, dilbilimsel bir programlama tarzı ne kadar önemlidir, varsayımlarınızın ve kavramlarınızın kodunuzu anlamaya çalışan bir sonraki kişi tarafından yanlış anlaşılmamasını sağlamak için olacaktır. .

İkinci ve daha özlü stil matematik odaklı (matematiksel) programlamadır. Bu akıl yürütme tarzı aynı zamanda dile de dayanır, çünkü değişkenler isimlere ve operatörlerin fiillere benzerdir. Bununla birlikte, matematiksel akıl yürütme, beyinlerimizin, görüş çizgimizdeki nesneler üzerinde karmaşık uzamsal dönüşümler yapma şaşırtıcı ve son derece paralel yeteneğinden yararlanır. İsimleri ve fiilleri iyi yapılandırılmış hayali nesnelere yerleştirilebilecek kompakt, ayırt edici semboller olarak temsil ederek - denklemler - daha sonra bu hayali üzerinde rotasyonlar, değiştirmeler, hareketler, çevrimler ve diğer dönüşümler yapmak için son derece paralel görsel yeteneklerimizi kullanabiliriz nesneler. Sonuç, her seferinde yakından ilişkili nesnelerin tüm sınıflarını temsil edebileceği için bir seferde ele alabileceğimiz vaka sayısının muazzam bir artmasıdır.

Görsel işlemeyi etkili bir şekilde uygulamak için hayali nesneyi boyut ve özellik olarak gerçek bir nesneye mümkün olduğunca benzer tutmanız gerekir. İhtiyaç duyulan görüş alanı çok genişlerse veya semboller bir nesnenin üzerindeki hareketli işaretler gibi kullanılamazsa veya “harfleri okumak” ve bunları kelimelere dönüştürmek zorunda kalırsanız, karmaşık dönüşümleri güvenilir bir şekilde gerçekleştirme yeteneği düşecektir. çok iyi bir matematikçi için bile çabucak.

Bu yüzden, matematiksel programlama stiline derinlemesine dalmış insanlar, bir denklemin “ayrıntılı” dilsel stil dedikleri şekilde ifade edilip ifade edilmeleri durumunda ciddi şekilde mutsuz olabilirler. Denklemin önemli ölçüde değiştiğinden değil, bunun böyle bir şekilde yayılması, ona görsel bir anlayış tarzı uygulamanın neredeyse imkansız hale gelmesidir. Yine de, kısa sembollere hiç aşina olmayan yeni bir programcının, başlangıçta kodun ne yaptığını anlamak için daha fazla dil bilgisi sağlayan daha ayrıntılı bir sürümü tercih etmesi muhtemeldir.

Peki ne öneririm?

Her iki stili de kullanın, ancak her bir stili neden kullandığınıza dikkat edin .

Örneğin, dış dünyayla etkileşime girme şansı olan herhangi bir şey, yalnızca kodla karıştırılan satır içi yorumlar biçiminde olsa bile, bir düzeyde yoğun şekilde açıklanmalı ve ayrıca doğru kullanım için otomatik kontroller içermelidir. Kriptik ve özellikle tam olarak tanımlanmamış notasyonların bu gibi arayüzlerde işi yoktur, çünkü bir noktada yanlış anlaşılmaları neredeyse garanti edilmektedir. Mars İklim obiter 1999 kayıp nedeniyle yazılım arayüzü birimleri pound veya Newton cinsinden ifade edildi olmadığını tanımak için bir başarısızlığa yazılım veya donanım arayüzleri de çiğ sayılar üzerinde çok raslantı güvenerek tehlikeleri özellikle sivri örnektir.

Tersine, doğası gereği derinlemesine algoritmik ve matematiksel olan herhangi bir programlama biçimi, matematiksel akıl yürütme tarzını destekleyen iyi bir aday özlü programlamadır. Yeni birinin bu tür bir kodu tutması gerekiyorsa, kodu daha ayrıntılı formlara dönüştürmeye çalışmak yerine matematiksel gösterimleri öğrenmeleri daha iyi olur. Elbette her zaman, bu tür geliştiricilere verilen kodun matematiksel bölümlerini açıklamak için kolay bir şekilde dokümantasyon sağlanmalıdır, ancak bu ayrı bir konudur.

Bu uç noktalar arasında, programcının takdir yetkisi olduğu birçok durum vardır. Kodun uzun vadede nasıl korunacağına bakmayı ve kodu uzun vadede sürdürmesi en muhtemel insanların ihtiyaçlarını karşılamaya çalışmayı önerebilirim.

Bazı insanlar muhtemelen açıkça belirtilmesi gerektiğini düşündüğüm bir şeye işaret ediyor.

Ayrıntı, mikroskobik düzeyde anlayışı destekleme eğilimindedir - genellikle bireysel ifadelerin okunması ve anlaşılması kolay olur. Ayrıntı, aynı zamanda onu anlamak için gerekli dilin aşina olma derecesini azaltma eğilimindedir (en azından bir dereceye kadar). En ayrıntılı diller (örneğin, COBOL), programlayıcı olmayanlar tarafından bile okunabilir.

Sarsıntı tam tersi bir eğilim gösterir: makroskopik düzeyde, özellikle de o dille en yakın aşina olan programcılar tarafından anlaşılmasına yardımcı olur. Aynı zamanda, bu özel dile aşinalık eksikliği, aksi halde oldukça deneyimli olan programcılardan bile ilkel anlayışı bile önleyebilir.

Bu nedenle, okunabilirlik, hedef kitleye bağlı olarak geniş ölçüde değişir. Bir yandan, neredeyse tamamen bu projede çalışan insanlar tarafından yazılan ve sürdürülen büyük bir karmaşık projenin, çoğu önemli programlama geçmişine ve eğitimine sahip (örneğin, doktora) düşünün. Bu daha özlü bir dil lehine olacaktır.

Neredeyse tam tersi bir uçta, esasen yazılımın kendisinden ziyade yazılımla ilişkili iş konusunda gerçekten uzman kişilerce yürütülen, oldukça basit (muhtemelen oldukça büyük) bir proje düşünün. Bu neredeyse kesinlikle çok daha ayrıntılı bir dil lehine olacaktır.

Teknik bir kitaba gitmekten ziyade, Strunk and White'dan Elements of Style * a geri dönüyorum. Temel konsept "Kesin ol" ve "İhtiyaçtan fazlasını söyleme" dır. Geriye kalan her şey yorumdur.

Programlamaya uygulandığında, bu çok kesin olmakla birlikte, gereksiz bir kabartmaya sahip olmamakla ilgilidir. Ekstra tüy, sözdizimi olabilir, ancak anlam ifade etmek için gerekenden daha fazla kelime de olabilir. (Tabii ki belirsizliğe izin vermek için çok az değil)

• Özgün versiyonundan alıntı yapıyorum, çünkü en özlü olanı. :-)

Günün sonunda, 'farklı' olan her şey insanların ulumalarına neden olur. C tarzı sözdizimi konusunda rahatım ve bu nedenle benzer sözdizimini paylaşan diğer dillerle (C ++, Java, C #) tamam. Bu yüzden bu belirli tarzı tercih etme eğilimindeyim.

Diller yeterince açıklayıcı ve ayrıntılı değil arasında bir denge kurma eğilimindedir.

Perl, özlü kod yazabileceğiniz bir örnek. Başlatılmamış bir Perl ninja tarafından yazılmış kod sihirden başka bir şey değil.

COBOL çok ayrıntılı bir örnektir.

Bir zamanlar bir yerde okudum, ayrıntılı tartışmaların büyük bir kısmı eski eller ve yeni programcılardan geliyor. Kullanılan analoji, yeni bir şey öğrendiğimizde, kendimizi geçmesi için kendimize bir "hikaye" anlattığımız (HS'de cebir öğrendiğiniz zamanları düşünmemiz) idi. Tecrübe kazandıkça, bireysel bileşenleri açıklayan bir hikayeye duyulan ihtiyacın ötesine geçiyoruz ve daha büyük bir miktar olduğunu kavrıyoruz. Kodumuz daha yoğun ve daha titiz hale gelir; yorumlarda, kodun ne söylediğini tekrarlamak yerine yalnızca gerekli öğeleri açıklar.

Bunu bir iş arkadaşı ile aramızda doğru buldum. Kod satırlarının ne olduğunu açıklayan birçok yorum ve birçok boşluk bırakıyor. Eğer okuyorsam, bu yüzden bir ekranda sadece birkaç satır kod sığabileceğimi biliyorum. Bu, her bir çizgiyi anlamayı çok daha kolay hale getirir, ancak tüm işlevi gizlemek çok daha zor hale gelir.

Ekstra boşluk veya yorum olmadan kod yazma eğilimindedir. Bu, tüm görmeyi çok daha kolaylaştırır, ancak basitçe "bireysel kod" kelimeleri "alabilmeniz gerekir. Bu cevabı, her kelimenin kendi satırında olmasına rağmen, çok fazla boşluk / yorum / ekstra kelime bilgisi ile okumaya çalıştıysanız, her bir kelimeyi anlamak çok daha kolay olacaktır, ancak bütünü anlamak çok daha zor olacaktır.

Einstein doğru buldu: "Mümkün olduğunca basit, ama daha basit olmayan şeyler yapın."

Bu aynı zamanda kod için de geçerlidir. Tekrarlayan ve gereksiz yere ayrıntılı öğeleri kaldırarak kodu basitleştirebilirsiniz, bu iyi bir şey.

Ayrıca, bazı vaka çalışmaları kod satırlarıyla ölçülen programcı verimliliğinin sabit ya da az olduğunu göstermektedir. Öyle ki LOC başına böcek sayısıdır. Bu nedenle, diğer tüm şeylerin eşit kalması durumunda, kod satırı başına daha fazlasını yapmanıza izin veren bir dile geçmek, verimlilik artışı olarak kabul edilebilir.

Olduğu söyleniyor, bu sektörde basit şeylerin ne olması gerektiği konusunda mühendisliği ve karmaşıklığı arttırma eğilimi var. İlişkisel bir veritabanında iletişim bilgilerini doldurmak gibi basit şeyler. Bu özel problem için gülünç derecede karmaşık ve yanlış yönlendirilmiş çözümler ( öksürük MDA) gördüm . Scala ve Ruby gibi diller, belli kişilerin ellerinde anlaşılmaz, aşırı karmaşık ve bakımsız kodlara neden olan güçlü araçlara iyi bir örnektir. Sırf birkaç tuş vuruşuyla birden fazla dolaylı seviye kullanabilmeniz, her çiviyi görerek o çekiçle vurmanız gerektiği anlamına gelmez.

Doğru kullanıldığında hem kısa hem de anlaşılması kolay temiz bir kod alırsınız. Zayıf kullanıldığında, daha fazla hasarı önlemek için söz konusu kişiyi görsel temel veya benzer şekilde sınırlı bir dil kullanarak sınırlandırmakta daha iyi olursunuz.

Gerçek beceri, karmaşık şeyleri karmaşık bir şekilde yapmaktan ziyade karmaşık şeyleri basit bir şekilde yapmaktır.

Kimsenin çarpmadığı bir şey, bir ekrana sığdırabileceğiniz kod miktarıdır. Birkaç nedenden dolayı yardımcı olur:

• Tek bir dosyada birden fazla işlev üzerinde çalışırken (veya okurken) ileri geri kaydırma daha az olur.
• Daha az yatay kaydırma (okumayı durdurun, kaydırma çubuğunu tıklayıp sürükleyin, okumayı durdurun, kaydırma çubuğunu tıklayıp sürükleyin ...).
• Daha hızlı tarama, ne istediğinizi bulma yolunda işe yaramaz daha az sözdizimi olduğundan.

Çünkü daha fazla kod daha fazla geliştirme zamanı ve daha fazla hata anlamına gelir.

Eğer 300 satırlık kod yerine 100 satırlık kod yazarsanız. Bu, ihtiyacınız olan neredeyse 1/3 gelişme süresinin ve karşılayabileceğiniz 1/3 potansiyel hatanın anlamına gelir.

Çoğu durumda verimi ve özlüğü dengelemeniz gerekir, çünkü daha az kod yazmanız makinenin daha fazla iş yapması gerektiği anlamına gelir ve verimliliği düşürür.

Genellikle insanlar şifreli / kısa dilleri yerine okunabilir / ayrıntılı dilleri tercih eder. Bununla birlikte, çoğu insanın aynı şey olmayan "dağınıklığı" "dağınıklık" ile özümsemiş olduğunu düşünüyorum.

Örneğin: while(<>){print if($.==2 || $& && !$x++); $.=0 if (/^--+$/)}

çok özlü bir ifadedir. Bilmek istediğiniz her şeyi içerir. Ancak, netliği nedeniyle anlaşılması zor. Öte yandan, aynı programın biraz daha ayrıntılı bir versiyonunun anlaşılması oldukça kolay olacaktır çünkü daha okunaklıdır. Bu elbette kendi başına bir dil değildir, ancak bazı diller daha fazla ayrıntılandırma eğilimindeyken, diğerleri programlama şekillerinde daha özlü olma eğilimindedir.

Diğer ayrıntılara göre, oldukça ilginç bir kavram olduğunu düşündüğüm http://en.wikipedia.org/wiki/Literate_programming .

Diğer bir yönü de "dağınıklığı" olarak da adlandırılan "istenmeyen ayrıntı" dır. Teknik nedenlerden, sözdizimsel şeker eksikliği, şişirilmiş API'ler vb. İçin eklemeniz gereken şeyler.

Açık ve sezgisel bir sözdiziminin çok önemli olduğunu düşünüyorum. Ayrıca kolay bir okumayı kolaylaştıracak kadar ayrıntılı olmak zorundadır. Çok fazla mantıkla dolu çok kısa ifadeler genellikle biraz daha uzun olan benzerlerinden daha çok deşifre edilmesine neden olabilir. Öte yandan, son derece basit bir şey yapmak için kazan levhalarıyla dolu işe yaramaz şişirilmiş kod da aynı derecede sıkıntı vericidir.

Ayrıntıları çok miktarda metin kullanma eğilimi, ve çok az metin kullanmanın tersliği ...

Ayrıntı kötüdür çünkü:

1. yazım hatası için daha fazla fırsat sunar
2. Ekranda veya kağıda kod okumayı ve / veya delikli kartı girmeyi zorlaştırır
   1. bu hata ayıklama sürelerini artırır
   2. bu yükseltme / bakım için kodun anlaşılmasını zorlaştırır
   3. bu istenmeyen kod çoğaltmasına neden olabilir
3. biraz sözdizimi hatası olasılığını artırır
4. kodlama esnekliğini azaltır, bu nedenle, çoğu ayrıntılı diller yüksek düzeyde yapılandırılmıştır ve aynı şeyi söylemenin birden fazla yolu yoktur.
5. kodlama ve derleme sürelerini arttırır
6. daha fazla depolama alanı alabilir.

Belli bir ayrıntı seviyesi açıklık için şarttır, ancak ...

asgari düzeyde bir Verbosity seviyesi iyidir çünkü:

1. insanlar için semantik değer okumak ve eklemek sadece sembolik kodlardan daha kolaydır.
2. Değişken ve işlev adlandırmada, hata ayıklamayı, bağlantı kurmayı ve kodu korumayı kolaylaştırır
3. temel düzeyde dil işlemlerinde ve karmaşık dillerin anahtar kelimelerinde, daha az hatalı işlem / anahtar kelime atamasıyla sonuçlanır.

Birçok insan için aşırı kısa ve öz komutların güzel örnekleri eski TEMEL standbys içerir val(x$), str$(x)ve chr$(x)..., dize gösterimine bir sayı döndürür bir dizi için bir dize döndürür ve bir dize olarak tek bir karakter olan ASCII değeri x dönün.

Veya C / C ++ işaretçisi ve başvuru işleçleri &ile *BASIC byrefanahtar sözcüğü. C / C ++ 'da X değişkenine sahip olabilirim ve bu değişkene bir işaretçi geçiririm, ama hangisinin işaretçi olduğunu ve "işaretçi değişkeni olarak gösterici kullan" dır; temelde referansı fonksiyon çağrısında bir byref anahtar kelimesi ile iletiyorum, bu daha net fakat daha az esnek:

def fn Foo(x byref as float) foo= (x += x+1)
...
Foo(x)

Bu kodda, x'in içeriği bayrağın bayrağından dolayı değiştirilir. Bazı tatlar, bazıları açıkta, bazıları tanımda, çağrıda bulunmalarına izin verir.

Ayrıntı programcıların sembolizmi daha kolay kullanabilmeleri için ayrıntı vermesi önemlidir; BASIC veya python, insan tarafından okunabilir ve C / C ++ 'dan daha ayrıntılı ve bu nedenle sıradan programcılar için çok daha kullanışlı; C / C ++ 'ın netliği, bir ekranda daha fazla kod ve daha karmaşık kod görmesi gereken ancak çeşitli sembolik yapı kurallarını öğrenmek zorunda olan daha deneyimli programcılar için çok daha iyi hale getirir. En sonunda, neredeyse tamamen insan tarafından okunamayan bir APL var.

Çok yakından ilişkili bir konu netliktir - kısa kod genellikle belirsizdir ve aşırı ayrıntılı kod (AppleScript'te olduğu gibi) eşit derecede açık olabilir. Belirli bir dile aşinalık, bu dilde kısa kodun açıklığını arttırır - ham bir başlangıç, C ++ koduyla karşı karşıya kalmanın yalnızca formülleri ayrıştırması olasıdır ve çok işlevsel bir BASIC veya Python kodu anlama için çok kısa Genelde dil sözlüklerine başvurmadan şaşırmamak. Kasıtlı şaşırtmaca olmadan karşılaştığım en az açık olan Bilgilendir 7 ...

Eski günlerde

Geçmişte bir başka önemli husus, ancak hobi kodlayıcı için artık önemli olmayan bir şey, işletme ve depolama alanıdır. (En sonda hala hayati önem taşıyor.) Birçok dilin yorumlandığını, özellikle de BASIC lezzetlerinin ve birçoğunun çalışma zamanı derlendiğini, özellikle de yalnızca 128KiB diskler ve tek tek zımba kartlarının yalnızca 80B olduğu durumlarda, kod alanının önem arz ettiğini unutmayın.

Birkaç çözüm mevcuttu - tokenizasyon, BASIC'de oldukça yaygındı; Tek tek dilli anahtar kelimeler, üst 128 veya kontrol karakteri boşluğunda 1 veya 2 bayt kelimeye düşürüldü. Tokenizasyon ayrıca bytecode derlemesine de yol açar (Inform ve Z-Machine'de olduğu gibi).

Alan kısıtlamalarını aşmak için birden fazla nesne dosyası derleme ve bağlama da kullanılmıştır. Bir 100KiB Pascal kodu bölümü yalnızca 5KiB'ye derlenebilir; Birden fazla derlenmiş dosyayı birbirine bağlayarak, büyük formatlı sürücülere erişimi olmayan büyük uygulamalar geliştirilebilir (10MiB'nin şaşırtıcı derecede büyük olduğunu ve pahalı bir yeni araba satın aldığını unutmayın).

Bununla birlikte, daha kısa diller, hem disk hem de ram için belirli bir yığın halinde daha fazla kod aldı ve böylece bir seferde daha büyük parçaları derledi. Akılda tutulması: 1970'lerin başındaki "mini bilgisayarlar" yalnızca 64KiB koç olabilir (Honeywell 800, her biri 8B olan 2048 kelimeden oluşan 4 bankanın temel kurulumuna sahipti). APL ve benzeri sembolik diller, talimat başına 1B artı işlenenlerine, talimat başına daha büyük 3B-10B artı işlenenlere yaklaştı. (Özellikle semboller yazım topunda bir font olduğundan ve çoğu kartın tuşlarında sembollerin bulunmadığı için, delikli kartların üzerine yazmak kabusdu.)

Ayrıca, kartların silinemediğini ve kartlara birçok program girildiğini unutmayın. Bireysel olarak pahalı olmasa da, kodunuz kartta ne kadar sıkıştırılmış olursa, ne kadar az ihtiyaç duyarsanız ve programlar ne kadar büyükse veya o kadar az pahalı olabilir. Bu BASIC'in çoğu aromada satır başına çoklu komutların bir araya getirilmesinin nedeninin bir parçasıdır - delikli kartlardan tasarruf etmek için getirilmiştir. (Ya da Vax Basic programlama metnimi yazıyor.) Kart okuyucusu için programlamadığım halde, FORTRAN, BASIC, APL ve diğer birçok sembolik dilde bir Honeywell 800 için zımbalama kartı yaptım.

Pek çok şeyde olduğu gibi, cevap da "ayrıntı" nın somut tanımına bağlıdır. Tanım, ayrıntı vermenin artıklık anlamına gelmesi durumunda, o zaman her zaman kötü olduğunu savunurum. Böyle bir tanım ile sık sık anılan Java merhaba dünya programı olacağını unutmayın değil gereksiz içinde hiçbir şey yoktur, çünkü "ayrıntılı" olarak nitelendirilir.

Programcılar, sık sık yapılması gereken basit şeyleri küçük kod parçalarında kodlamalarına izin verdiği için, ifade gücü olan dilleri sevme eğilimindedir. Ayrıntılı diller, aynı şeyi tekrar tekrar yapmak için çok sayıda kod satırının kullanılması gerektiği anlamına gelir. Bununla birlikte, daha basit yüksek seviyeli dil dilleri kadar hızlı uygulanamayacakları için, ifade edici dillerle ödenmesi gereken bir bedel olabilir. C ve C ++ arasındaki kontrastta bir örnek verebilirsem. C ++, yazarları kodlamak için daha etkileyici bir güç verir - sınıflardaki gerçek dünya nesneleri fikrini kapsülebilirler. C programcıları aynı şeyleri başarabilirler ancak kendilerine yardımcı olmak için sınıf yapısının ifade gücüne sahiptirler - bu yüzden sık sık daha uzun, daha karmaşık (anlamak için) kod yazmaları gerekir. Ancak bu kod daha hızlı çalışabilir (bu, derleyici kalitesine ve benzeri şeylere oldukça bağımlı olmasına rağmen), çünkü kodu çalıştırmak için C ++ 'ın "geç bağlama" (örn. Çalışma zamanını yeniden düzenleme) kullanmaz. C sadece derlenmiş ve bağlanmış kodu çalıştırır, C ++ hangi zamanda kodun çalıştırılacağına dair (belirli durumlarda) karar vermek zorundadır.

Okunabilirlikten daha temel ve teorik bir konuya dayanan sorunun cevabının olduğuna ve bu cevabın Gregory Chaitin tarafından kurulan algoritmik bilgi teorisi ile ilgili olduğuna inanıyorum: http://en.wikipedia.org/wiki/Algorithmic_information_theory . Birkaç kelime ile ifade edilen "bir dizgenin bilgi içeriği, o dizginin mümkün olan en kısa temsilini temsil eden uzunluğa eşdeğerdir", Bu, en kısa programın (yani sözlükbilimsel uzunluk anlamında) verilen bir sorunu yakından çözdüğü anlamına gelir. Çözdüğü problemin kendine özgü karmaşıklığıyla eşleşir ve bu nedenle problemin niteliğine ve sorunun temsiline daha az dayanır.