Derlenmiş ve Yorumlanan Diller


284

Farkı daha iyi anlamaya çalışıyorum. Çevrimiçi olarak birçok açıklama buldum, ancak pratik çıkarımlardan ziyade soyut farklılıklara yöneliyorlar.

Programlama deneyimlerimin çoğu CPython (dinamik, yorumlanmış) ve Java (statik, derlenmiş) ile olmuştur. Ancak, başka türden yorumlanmış ve derlenmiş diller olduğunu anlıyorum. Yürütülebilir dosyaların derlenmiş dillerde yazılmış programlardan dağıtılabilmesinin yanı sıra, her türün avantajları / dezavantajları var mı? Çoğu zaman, yorumlanmış dillerin etkileşimli olarak kullanılabileceğini savunan insanlar duyuyorum, ancak derlenmiş dillerin de etkileşimli uygulamaları olabileceğine inanıyorum, doğru mu?


32
Bu karşılaştırma için tam olarak en kötü dilleri seçtiniz. Her ikisi de bytecompiled. Aralarındaki tek gerçek fark JITer'dir ve Python'un bile kısmi bir (psyco) vardır.
Ignacio Vazquez-Abrams

1
Etkileşimli derlenmiş dilin iyi bir örneği Clojure'dur - her şey tamamen derlenmiştir (önce JVM'ye sonra JIT aracılığıyla yerel koda). Bununla birlikte, yeniden derlemenin çoğu dinamik olarak gerçekleşir ve geliştirme, çalışan ortamda istediğiniz herhangi bir işlevi değerlendirebileceğiniz etkileşimli bir REPL kabuğunda yapılır.
mikera

Standart ML, başka bir etkileşimli derlenmiş dildir; yerleşik derleyici de gerçek yerel makine kodu verir.
Donal Fellows


Yanıtlar:


460

Derlenen dil, programın derlendikten sonra hedef makinenin talimatlarında ifade edildiği dildir. Örneğin, kaynak kodunuzdaki bir ek "+" işlemi doğrudan makine kodundaki "EKLE" komutuna çevrilebilir.

Bir yorumlanmış dil talimatları doğrudan (normalde başka bir program tarafından hedef makine tarafından yürütülen, ancak bunun yerine okuyup yürütülmez biridir edilir yerli makine dilinde yazılmış). Örneğin, aynı "+" işlemi, yorumlayıcı tarafından çalışma zamanında tanınır ve daha sonra kendi "add (a, b)" işlevini uygun bağımsız değişkenlerle çağırır ve bu da makine kodu "EKLE" komutunu yürütür .

Derlenmiş bir dilde ve tam tersi olarak, yorumlanmış bir dilde yapabileceğiniz her şeyi yapabilirsiniz - her ikisi de Turing tamamlandı. Ancak her ikisinin de uygulama ve kullanım için avantajları ve dezavantajları vardır.

Tamamen genelleştireceğim (puristler beni affedecek!) Ama kabaca derlenmiş dillerin avantajları:

  • Doğrudan hedef makinenin yerel kodunu kullanarak daha hızlı performans
  • Derleme aşamasında oldukça güçlü optimizasyonlar yapma fırsatı

Ve burada yorumlanmış dillerin avantajları:

  • Uygulaması daha kolay (iyi derleyiciler yazmak çok zor !!)
  • Bir derleme aşaması çalıştırmaya gerek yok: kodu doğrudan "anında" yürütebilir
  • Dinamik diller için daha uygun olabilir

Baytkod derlemesi gibi modern tekniklerin ekstra bir karmaşıklık getirdiğine dikkat edin - burada olan şey, derleyicinin temel donanım ile aynı olmayan bir "sanal makineyi" hedeflemesidir. Bu sanal makine talimatları daha sonra yerel kodu almak için daha sonraki bir aşamada derlenebilir (örneğin, Java JVM JIT derleyicisi tarafından yapıldığı gibi).


1
Derlenen tüm dillerin yavaş bir derleme aşamasına ihtiyacı yoktur. Ciddi Common Lisp uygulamaları derleyicilerdir ve genellikle bir çevirmenle uğraşmazlar, sadece hızlı bir şekilde gerçek hızlı bir şekilde derlemeyi tercih ederler. Öte yandan, Java'nın bir derleme adımına ihtiyacı vardır ve genellikle görülebilir.
David Thornley

2
@Kareem: JIT derleyicisi yalnızca 1) ve 2) bir kez yapar - bundan sonra yerel kod tüm yol boyunca. Kodun her çağrıldığında (1) ve 2) yorumlayıcıların her ikisini de yapması gerekir (bu birçok, birçok kez olabilir ...). Böylece zamanla JIT derleyicisi uzun bir farkla kazanır.
mikera

3
Evet bayt kodu , genel program yürütme sırasında bir noktada makine koduna çevrilir (geleneksel bir derleyicide olduğu gibi, program yürütmeden önce olduğu gibi). Ancak belirli bir kod parçası, programın tamamı yürütülürken 10 milyondan fazla kez yürütülebilir. (Büyük olasılıkla) bayt kodundan makine koduna sadece bir kez derlenir . Bu nedenle, JIT'in çalışma zamanı yükü küçüktür ve uzun süren programlar için göz ardı edilebilir. JIT derleyicisi işini bitirdikten sonra, saf makine kodunu etkili bir şekilde çalıştıracaksınız.
mikera

2
Bu aslında yanlış bir ikilik. Bir dile özgü, bizim yorumlanmış derlememizi sağlayan hiçbir şey yoktur. Yaygın olarak yapılan bir yanlış anlamadan başka bir şey değildir. Birçok dilde her iki uygulama da vardır ve tüm diller de olabilir.
mmachenry

2
@mmachenry bu yanlış bir ikilik değildir. "programlama dili" hem tasarım hem de uygulamayı içerir. Bir iken teorik anlamda belirli bir dil tanımı hem derlenmiş ve yorumlanabilir, içinde gerçek dünya pratikte uygulanmasında önemli farklılıklar vardır. Kimse henüz belirli dil yapılarını nasıl etkili bir şekilde derleyeceğini çözemedi, örneğin - bu açık bir araştırma problemidir.
mikera

99

Bir dilin kendisi ne derlenir ne de yorumlanır, yalnızca bir dilin belirli bir uygulamasıdır. Java mükemmel bir örnektir. Bayt kodu tabanlı bir platform (JVM), yerel bir derleyici (gcj) ve Java'nın üst kümesi (bsh) için bir yorumlayıcı vardır. Peki şimdi Java nedir? Bayt kodu derlendi, yerel derlendi veya yorumlandı mı?

Derlenen ve yorumlanan diğer diller Scala, Haskell veya Ocaml'dir. Bu dillerin her birinde etkileşimli bir yorumlayıcı ve bayt kodu veya yerel makine kodu için bir derleyici vardır.

Dolayısıyla, dilleri genellikle "derlenmiş" ve "yorumlanmış" olarak kategorilere ayırmak pek mantıklı değildir.


3
Katılıyorum. Veya diyelim ki, yerel derleyiciler (CPU'nun yemek için makine kodu oluşturma) ve yerel olmayan derleyiciler (bazı tam zamanında derleyicilerin daha önce makine koduna derlediği tokenize şeyler, yani ara kod oluşturma ( veya çalışma zamanı sırasında), ve makine kodu üretmeyen ve CPU'nun kodu çalıştırmasına asla izin vermeyen "gerçek" derleyiciler yoktur. İkincisi tercümanlardır. Bugün, derleme zamanında doğrudan makine (CPU) kodu üreten yerel derleyiciler gittikçe daha nadir hale gelmektedir. Delphi / Codegear en iyi kurtulanlardan biridir.
TheBlastOne

57

Şu açıdan düşünmeye başlayın: geçmişten gelen patlama

Bir zamanlar, uzun zaman önce, bilgisayar tercümanları ve derleyiciler ülkesinde yaşadı. Birbirinin esası üzerinden diğerine yayılan her türlü yaygara. O zamanki genel görüş şu çizgilerden ibaretti:

  • Tercüman: Hızlı geliştirme (düzenleme ve çalıştırma). Her ifadenin her yürütüldüğünde makine koduna yorumlanması gerektiğinden yürütmek yavaştır (bunun binlerce kez yürütülen bir döngü için ne anlama geldiğini düşünün).
  • Derleyici: Geliştirilmesi yavaş (düzenleme, derleme, bağlantı ve çalıştırma. Derleme / bağlantı adımları ciddi zaman alabilir). Hızlı yürütme. Tüm program zaten yerel makine kodundaydı.

Yorumlanan bir program ile derlenmiş bir program arasında çalışma zamanı performansında bir veya iki büyüklük farkı vardı. Örneğin, kodun çalışma zamanı değiştirilebilirliği gibi diğer ayırt edici noktalar da ilgi çekiciydi, ancak ana ayrım çalışma zamanı performans sorunları etrafında dönüyordu.

Bugün manzara o kadar gelişti ki, derlenmiş / yorumlanmış ayrım neredeyse hiç alakasız. Birçok derlenmiş dil, tamamen makine kodu tabanlı olmayan çalışma zamanı hizmetlerini çağırır. Ayrıca, yorumlanan çoğu dil yürütmeden önce bayt koduna "derlenir". Bayt kodu yorumlayıcıları çok verimli olabilir ve derleyici tarafından üretilen bazı kodları yürütme hızı açısından rakip olabilir.

Klasik fark, derleyicilerin yerel makine kodunu, yorumlayıcıların bir çeşit çalışma zamanı sistemi kullanarak kaynak kodunu ve üretilen makine kodunu anında okumasıdır. Bugün çok az klasik tercüman var - neredeyse hepsi byte koduna (veya başka bir yarı derlenmiş duruma) derleniyor ve bu da sanal bir "makinede" çalışıyor.


1
Güzel - son paragrafta büyük özet - teşekkürler!
ckib16

26

Aşırı ve basit durumlar:

  • Derleyici, hedef makinenin yerel yürütülebilir biçiminde bir ikili yürütülebilir dosya oluşturur. Bu ikili dosya, sistem kitaplıkları dışında gerekli tüm kaynakları içerir; daha fazla hazırlık ve işleme gerek kalmadan çalışmaya hazırdır ve şimşek gibi çalışır, çünkü kod hedef makinedeki CPU için yerel koddur.

  • Bir tercüman kullanıcıya bir döngüde ifadeler veya kod girebileceği bir komut istemi sunar ve isabet RUNya da eşdeğeri üzerine , program bir durma noktasına ya da hataya kadar her satırı inceleyecek, tarayacak, ayrıştıracak ve yorumlayacaktır. . Her satır kendi başına işlendiğinden ve yorumlayıcı daha önce satırı görmekten "bir şey" öğrenmediği için, insan tarafından okunabilir dili makine yönergelerine dönüştürme çabası her satır için her zaman gerçekleşir, bu yüzden köpek yavaştır. Parlak tarafta, kullanıcı programını her türlü şekilde inceleyebilir ve başka türlü etkileşime girebilir: Değişkenleri değiştirmek, kodu değiştirmek, izleme veya hata ayıklama modlarında çalışmak ... her neyse.

Yoldan çekilince, hayatın artık o kadar basit olmadığını açıklayayım. Örneğin,

  • Birçok tercüman verdikleri kodu önceden derleyecektir, böylece çeviri adımının tekrar tekrar tekrarlanması gerekmez.
  • Bazı derleyiciler, CPU'ya özgü makine talimatlarını değil, hayali bir makine için bir tür yapay makine kodu olan bayt kodunu derler. Bu, derlenen programı biraz daha taşınabilir hale getirir, ancak her hedef sistemde bir bayt kodu yorumlayıcısı gerektirir.
  • Bayt kodu yorumlayıcıları (burada Java'ya bakıyorum) son zamanlarda, hedef bölümün CPU'su için aldıkları bayt kodunu derlemeden önce derleme eğilimindedir (JIT). Zaman kazanmak için, bu genellikle sadece sık çalışan kodlar (sıcak noktalar) için yapılır.
  • Tercüman gibi görünen ve hareket eden bazı sistemler (örneğin Clojure) aldıkları kodu derhal derler, ancak programın ortamına etkileşimli erişime izin verir. Temelde bu, ikili derleme hızı ile tercümanların rahatlığıdır.
  • Bazı derleyiciler gerçekten derlenmez, sadece kodları önceden sindirir ve sıkıştırırlar. Bir süre önce Perl'in işleyişini duydum. Bu yüzden bazen derleyici sadece biraz iş yapıyor ve çoğu hala yorumlama yapıyor.

Sonunda, bu günlerde yorumlama ve derleme bir değiş tokuştur, harcanan zaman (bir kez) daha iyi çalışma zamanı performansı ile ödüllendirilir, ancak etkileşim için daha fazla fırsat veren yorumlayıcı bir ortam. Derleme ve yorumlama, çoğunlukla programın "anlama" çalışmasının farklı süreçler arasında nasıl bölündüğü meselesidir ve bu günlerde diller ve ürünler her iki dünyanın en iyisini sunmaya çalıştıkça çizgi biraz bulanıktır.


23

Gönderen http://www.quora.com/What-is-the-difference-between-compiled-and-interpreted-programming-languages

Hiçbir fark yoktur, çünkü “derlenmiş programlama dili” ve “yorumlanmış programlama dili” anlamlı kavramlar değildir. Herhangi bir programlama dili ve gerçekten herhangi bir şey demek, yorumlanabilir veya derlenebilir. Dolayısıyla, yorumlama ve derleme dillerin nitelikleri değil uygulama teknikleridir.

Yorumlama, başka bir program olan tercümanın, programın yürütülmesi için yorumlandığı program adına işlem gerçekleştirdiği bir tekniktir. Bir programı okuduğunuzu ve adım adım yapmak için söylediklerini yaptığınızı hayal edebiliyorsanız, karalama kağıdına söyleyin, bir tercüman da bunu yapar. Bir programı yorumlamanın yaygın bir nedeni, tercümanların yazılmasının nispeten kolay olmasıdır. Bir başka neden de, bir tercümanın, örneğin bir güvenlik için bir politika uygulamak amacıyla, bir program çalışırken ne yapmaya çalıştığını izleyebilmesidir.

Derleme, bir dilde yazılmış bir programın (“kaynak dil”) başka bir dilde (“nesne dili”) bir programa çevrildiği ve umarım orijinal programla aynı anlama geldiği bir tekniktir. Çeviri yaparken, derleyicinin programı nesne programını daha hızlı hale getirecek şekilde (anlamını değiştirmeden) dönüştürmeye çalışması yaygındır. Bir programı derlemenin yaygın bir nedeni, nesneleri hızlı bir şekilde ve kaynak dili yol boyunca yorumlama yükü olmadan nesne dilinde çalıştırmak için iyi bir yol olmasıdır.

Yukarıdaki tanımlara dayanarak, bu iki uygulama tekniğinin birbirini dışlamadığını ve hatta tamamlayıcı olabileceğini tahmin etmiş olabilirsiniz. Geleneksel olarak, bir derleyicinin nesne dili, belirli bilgisayar CPU'ları tarafından anlaşılan herhangi bir sayıda programlama diline atıfta bulunan makine kodu veya benzer bir şeydi. Makine kodu daha sonra “metal üzerinde” çalışacaktır (biri yeterince yakından bakarsa “metal” in bir tercüman gibi çalıştığını görebilir). Ancak bugün, yorumlanması gereken nesne kodunu oluşturmak için bir derleyici kullanmak çok yaygındır - örneğin, Java bu eskiden (ve bazen de çalışır) böyle çalışır. Diğer dilleri JavaScript'e çeviren derleyiciler vardır, bunlar daha sonra bir web tarayıcısında çalışır ve JavaScript'i yorumlayabilir, veya sanal bir makine veya yerel kod derleyin. Ayrıca, bir tür donanımı diğerine taklit etmek için kullanılabilen makine kodu için tercümanlarımız da vardır. Ya da bir derleyici, başka bir derleyicinin kaynak kodu olan nesne kodunu oluşturmak için bir derleyici kullanabilir; bu da, çalışması için tam zamanında bellekte kod derleyebilir. . . kaptın bu işi. Bu kavramları birleştirmenin birçok yolu vardır.


Bu cümleyi düzeltebilir misiniz: "Diğer dilleri JavaScript'e çeviren, daha sonra JavaScript'i yorumlayabilen veya bir sanal makine veya yerel kod derleyebilen bir web tarayıcısında çalışan derleyiciler vardır."
Koray Tugay

Başarmak. Bir başka yaygın hata, bir dilin kullanışlılığını mevcut API'larına atfetmektir.
Küçük Endian

10

Yorumlanan kaynak kodunun derlenmiş kaynak koduna göre en büyük avantajı PORTABİLİTE'dir .

Kaynak kodunuz derlenmişse, programınızın çalışmasını istediğiniz her işlemci ve / veya platform türü için farklı bir yürütülebilir dosya derlemeniz gerekir (örneğin, Windows x86 için bir, Windows x64 için bir, Linux x64 için bir ve benzeri) ) üzerinde. Ayrıca, kodunuz tamamen standartlara uygun değilse ve platforma özgü herhangi bir işlev / kitaplık kullanmıyorsa, aslında birden çok kod tabanı yazmanız ve bakımını yapmanız gerekir!

Kaynak kodunuz yorumlanırsa, yalnızca bir kez yazmanız gerekir ve herhangi bir platformda uygun bir tercüman tarafından yorumlanabilir ve yürütülebilir! Bu var taşınabilir ! Tercüman kendisi yürütülebilir bir program olduğunu Not olan belirli bir platform için yazılı ve derlenmiş.

Derlenmiş kodun bir avantajı , kaynak kodu son kullanıcıdan ( fikri mülkiyet olabilir ) gizler, çünkü orijinal insan tarafından okunabilir kaynak kodunu dağıtmak yerine, belirsiz bir ikili yürütülebilir dosya dağıtırsınız.


1
bu terimlerle java "derlenmiş bir dil" olarak kabul edilemez, ancak derleme aşaması derleme (tip denetimi, erken hata tespiti, vb.) avantajları verir ve Java ile her işletim sisteminde çalıştırılabilecek bayt kodu üretir. sanal makine sağlanmıştır.
Rogelio Triviño

7

Bir derleyici ve yorumlayıcı aynı işi yapar: bir programlama dilini, genellikle donanıma daha yakın olan, genellikle doğrudan çalıştırılabilir makine kodu olan başka bir pgoraming diline çevirmek.

Geleneksel olarak, "derlenmiş", bu çevirinin bir seferde gerçekleştiği, bir geliştirici tarafından yapıldığı ve sonuçta ortaya çıkan yürütülebilir dosyanın kullanıcılara dağıtıldığı anlamına gelir. Saf örnek: C ++. Derleme genellikle oldukça uzun sürer ve elde edilen yürütülebilir dosyanın daha hızlı çalışabilmesi için çok pahalı optimizasyon yapmaya çalışır. Son kullanıcılar, kendileri derlemek için araçlara ve bilgiye sahip değildir ve yürütülebilir programın çeşitli donanımlarda çalışması gerekir, bu nedenle donanıma özgü birçok optimizasyon yapamazsınız. Geliştirme sırasında, ayrı derleme adımı daha uzun bir geri besleme döngüsü anlamına gelir.

Geleneksel olarak, "yorumlanmış", kullanıcı programı çalıştırmak istediğinde çevirinin "anında" gerçekleştiği anlamına gelir. Saf örnek: vanilya PHP. Saf bir tercüman her kod parçasını her çalıştığında ayrıştırmalı ve çevirmelidir; Karmaşık, maliyetli optimizasyonlar yapamaz çünkü yürütmede tasarruf edilen süreden daha uzun sürer. Ancak üzerinde çalıştığı donanımın özelliklerini tam olarak kullanabilir. Ayrı bir derleme adımı olmaması, geliştirme sırasında geri bildirim süresini azaltır.

Ancak günümüzde "derlenmiş ve yorumlanmış" siyah-beyaz bir sorun değil, aralarında gölgeler var. Saf, basit tercümanlar hemen hemen soyu tükenmiş durumda. Birçok dil, üst düzey kodun platformdan bağımsız bir bayt koduna (yorumlanması çok daha hızlı olan) çevrildiği iki adımlı bir işlem kullanır. Daha sonra, program başına en fazla bir kez kod derleyen, bazen önbellek sonuçları veren ve hatta nadiren çalışan kodu yorumlamaya karar veren ve çok çalışan kod için güçlü optimizasyonlar yapan "tam zamanında derleyiciler" var. Geliştirme sırasında, hata ayıklayıcılar geleneksel olarak derlenmiş diller için bile çalışan bir programın içindeki kodu değiştirebilir.


1
Ancak, C ++ 'ın derleme modeli C'den miras alınır ve şablonlar gibi özellikler dikkate alınmadan tasarlanmıştır. Bu gariplik, C ++ 'ın uzun derleme sürelerine diğer tüm faktörlerden çok daha fazla katkıda bulunur ve bunu kötü bir örnek yapar.

4

İlk olarak, bir açıklama, Java tamamen statik olarak derlenmemiş ve C ++ yolunda bağlı değildir. Bayt koduna derlenir ve bu kod daha sonra bir JVM tarafından yorumlanır. JVM gidip yerel makine diline tam zamanında derleme yapabilir, ancak bunu yapmak zorunda değildir.

Daha da önemlisi: Etkileşimin temel pratik fark olduğunu düşünüyorum. Her şey yorumlandığından, küçük bir kod alıntısı alabilir, ayrıştırıp ortamın mevcut durumuna göre çalıştırabilirsiniz. Bu nedenle, bir değişkeni başlatan bir kod yürüttüyseniz, o değişkene vb. Erişebileceksiniz. Gerçekten de işlevsel stil gibi şeylere yol açar.

Bununla birlikte, yorumlama, özellikle çok fazla referans ve bağlam içeren büyük bir sisteminiz olduğunda çok maliyetlidir. Tanım olarak, israftır, çünkü özdeş kodun iki kez yorumlanması ve optimize edilmesi gerekebilir (çoğu çalışma zamanının bunun için bazı önbellekleme ve optimizasyonları olmasına rağmen). Yine de, bir çalışma zamanı maliyeti ödersiniz ve genellikle bir çalışma zamanı ortamına ihtiyacınız vardır. Aynı zamanda karmaşık süreçler arası optimizasyonları görme olasılığınız daha düşüktür, çünkü şu anda performansları yeterince etkileşimli değildir.

Bu nedenle, çok fazla değişmeyecek büyük sistemler ve belirli diller için, her şeyi önceden derlemek ve önceden bağlamak daha mantıklıdır, yapabileceğiniz tüm optimizasyonları yapın. Bu, hedef makine için zaten optimize edilmiş çok zayıf bir çalışma süresiyle sonuçlanır.

Yürütülebilir dosyalar üretmeye gelince, bunun onunla çok az ilgisi var IMHO. Genellikle derlenmiş bir dilde yürütülebilir dosya oluşturabilirsiniz. Ancak, yorumlayıcı ve çalışma zamanının zaten exectuable'da paketlenmiş ve sizden gizlenmiş olması dışında, yorumlanmış bir dilde bir yürütülebilir dosya da oluşturabilirsiniz. Bu, genellikle çalışma zamanı maliyetlerini ödediğiniz anlamına gelir (her ne kadar bazı diller için her şeyi bir ağaç yürütülebilir dosyasına çevirmenin yolları olduğundan eminim).

Tüm dillerin interaktif hale getirilebileceğine katılmıyorum. C gibi bazı diller, makineye ve tüm bağlantı yapısına o kadar bağlıdır ki, anlamlı bir tam teşekküllü etkileşimli sürüm oluşturabileceğinizden emin değilim


C gerçekten bir "makineye" bağlı değildir. C'nin sözdizimi ve semantiği oldukça basittir. Bir C tercümanı uygulamak özellikle zor olmamalı, sadece çok zaman alıcıdır (çünkü standart kütüphane de uygulanmalıdır). Ve btw, Java yerel makine koduna (gcj kullanarak) derlenebilir.
lunaryorn

@lunaryorn: GCJ'ye katılmıyorum. GCJ size yalnızca çalıştırılabilir bir ortam sağlar. "Derlenmiş uygulamalar çekirdek sınıf kütüphaneleri, bir çöp toplayıcı ve bir bytecode yorumlayıcı sağlayan GCJ çalışma zamanı libgcj ile bağlantılıdır"
Uri

2
GCJ , yalnızca yerleşik yorumlayıcı ve bayt kodlu yürütülebilir bir ortam değil, yerel makine kodu üretir. libgcj, derlenmiş programı yorumlamak için değil, yerel koddan Java bayt koduna yapılan çağrıları desteklemek için bir bayt kodu yorumlayıcısı sağlar. Libgcj bir bayt kodu yorumlayıcısı sağlamadıysa, GCJ Java özelliklerine uymaz.
lunaryorn

@lunaryorn: Ah. Tamam, açıklamayı takdir ediyorum ve düzeltilmiş duruyorum. Öncelikle Java'yı bir Windows ortamında kullanıyoruz, bu yüzden yıllardır gcj'yi denemedim.
Uri


2

Pratik bir cevap vermek oldukça zor çünkü fark dil tanımının kendisiyle ilgili. Derlenen her dil için bir tercüman oluşturmak mümkündür, ancak her tercüme edilen dil için bir derleyici oluşturmak mümkün değildir. Bu, bir dilin biçimsel tanımıyla ilgilidir. Bu teorik bilişim üniversitede hiç kimseyi sevmiyor.


1
Şüphesiz, yorumlanmış bir dil için bir derleyici oluşturabilirsiniz, ancak derlenmiş makine kodunun kendisi çalışma zamanının bir aynasıdır.
Aiden Bell

2

Python Kitabı © 2015 Imagine Publishing Ltd, farkı sayfa 10'da belirtilen aşağıdaki ipucu ile ayırt eder:

Python gibi yorumlanmış bir dil, kaynak kodunun makine koduna dönüştürüldüğü ve daha sonra programın her çalıştırılışında çalıştırıldığı bir dildir. Bu, C gibi derlenmiş bir dilden farklıdır, burada kaynak kodu yalnızca bir kez makine koduna dönüştürülür - sonuçta ortaya çıkan makine kodu program her çalıştığında yürütülür.


1

Derleme, derlenmiş bir programlama dilinde yazılmış koddan yürütülebilir bir program oluşturma işlemidir. Derleme, bilgisayarın programı oluşturmak için kullanılan programlama yazılımına ihtiyaç duymadan çalışmasını ve anlamasını sağlar. Bir program derlendiğinde, IBM uyumlu bilgisayarlarla çalışan ancak diğer platformlarla (örneğin Apple platformu) çalışan belirli bir platform (örneğin IBM platformu) için derlenir. İlk derleyici, Harvard Mark I bilgisayarında çalışırken Grace Hopper tarafından geliştirildi. Bugün, üst düzey dillerin çoğu kendi derleyicilerini içerecek veya programı derlemek için kullanılabilecek araç takımlarına sahip olacaktır. Java ile kullanılan bir derleyiciye iyi bir örnek Eclipse ve C ve C ++ ile kullanılan bir derleyiciye örnek olarak gcc komutu verilebilir.


0

Kısa (kesin olmayan) tanım:

Derlenmiş dil: Tüm program bir kerede makine koduna çevrilir, ardından makine kodu CPU tarafından çalıştırılır.

Yorumlanan dil: Program satır satır okunur ve satır okunduğu anda bu satır için makine talimatları CPU tarafından yürütülür.

Ama gerçekten, bu günlerde birkaç dil tamamen derlendi veya tamamen yorumlandı, genellikle bir karışım. Resimlerle daha ayrıntılı bir açıklama için şu konuya bakın:

Derleme ve yorumlama arasındaki fark nedir?

Ya da sonraki blog yazım:

https://orangejuiceliberationfront.com/the-difference-between-compiler-and-interpreter/

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.