Bir şey üretilebiliyorsa, o şey kod değil, veridir.

Buna bakıldığında, kaynak kod üretmenin bütün bu fikri bir yanlış anlama değil midir? Diğer bir deyişle, eğer bir şey için bir kod üreticisi varsa, neden gerekli parametreleri alabilen ve "oluşturulacak" kodun yapacağı doğru işlemi yapan uygun bir fonksiyon yapmıyorsunuz?

Performans nedeniyle yapılıyorsa, derleyiciden bir eksiklik gibi geliyor.

İki dilin köprülenmesi için yapılıyorsa, arayüz kütüphanesi eksikliği gibi geliyor.

Burada bir şey mi eksik?

Bu kodun veri olduğunu da biliyorum. Anlamadığım şey neden kaynak kodu ürettiğim ? Neden onu parametreleri kabul edip bunlara etki edebilecek bir fonksiyon haline getirmiyorsunuz?

Kaynak kod üretimi bir model midir?

Teknik olarak, eğer kod üretirsek, insanlar tarafından okunabilen bir metin olsa bile kaynak değildir . Kaynak Kod , bir insan veya diğer gerçek zeka tarafından üretilen, mekanik olarak çevrilmeyen ve (gerçek) kaynaktan (doğrudan veya dolaylı olarak) hemen çoğaltılamayan orijinal koddur.

Bir şey üretilebiliyorsa, o şey veridir, kod değil.

Zaten her şeyin bir veri olduğunu söyleyebilirim . Hatta kaynak kodu. Özellikle kaynak kodu! Kaynak kod sadece programlama görevlerini gerçekleştirmek için tasarlanmış bir dilde bulunan veridir. Bu veriler çevrilebilir, yorumlanabilir, derlenecek, gerektiğinde diğerlerinin veri biçimlerine dönüştürülebilir, bazıları çalıştırılabilir hale gelir.

İşlemci bellekten yönergeleri yürütür. Veriler için kullanılanla aynı hafıza. İşlemci talimatları yürütmeden önce, program veri olarak belleğe yüklenir .

Yani, her şey veridir , hatta koddur .

[Oluşturulan kod veridir] göz önüne alındığında, kod oluşturma fikri bu bir yanlış anlama değil midir?

Derleme işleminde, biri metin olarak ara kod üretme olabilen birden fazla adımın olması mükemmeldir.

Diğer bir deyişle, eğer bir şey için bir kod üreticisi varsa, neden gerekli parametreleri alabilen ve "oluşturulacak" kodun yapacağı doğru işlemi yapan uygun bir fonksiyon yapmıyorsunuz?

Bu bir yol, ama başkaları da var.

Kod üretme çıktısı, bir insan tarafından kullanılmak üzere tasarlanmış bir şey olan metindir.

Tüm metin formları insan tüketimine yönelik değildir. Özellikle, oluşturulan kod (metin olarak) tipik olarak insan tüketimini değil derleyici tüketimini amaçlar .

Kaynak kodu orijinal olarak kabul edilir: usta - düzenlediğimiz ve geliştirdiğimiz; kaynak kod kontrolü kullanarak arşivlediklerimiz. Üretilen kod, insan tarafından okunabilir metin olsa bile, genellikle orijinal kaynak kodundan yeniden üretilir . Genel olarak konuşursak, üretilen kodun derleme sırasında yenilendiğinden kaynak kontrolü altında olması gerekmez.

Pratik muhakeme

Tamam, bu kodun veri olduğunu da biliyorum. Anlamadığım şey neden kaynak kodu ürettiğim?

Bu düzenlemeden, teorik Bilgisayar Bilimi yerine oldukça pratik bir düzeyde sorduğunuzu varsayıyorum.

Java gibi statik dillerde kaynak kodu oluşturmanın klasik nedeni, bunun gibi dillerin çok dinamik şeyler yapmak için dil içi araçların kullanımı kolay bir şekilde gelmemesiydi. Örneğin, Java'nın biçimlendirici günlerinde, dinamik veri türleriyle (eşleştirme özellikleriyle) dinamik bir adla (DB'nin tablo adını eşleştirerek) ve dinamik yöntemlerin (o tablodan eşleşen özniteliklerle) kolayca bir sınıf oluşturmak mümkün değildi. bahsedilen niteliklerin tipleri). Özellikle Java, derleme zamanında yazım hatalarını yakalayabilmenin çok önemli olduğunu belirtti.

Bu nedenle, böyle bir ayarda, bir programcı yalnızca Java kodu oluşturabilir ve çok sayıda kod satırını manuel olarak yazabilir. Genellikle, programcı bir masa değiştiğinde, geri dönüp eşleşecek kodu değiştirmesi gerektiğini; ve eğer bunu unutursa, kötü şeyler olur. Bu nedenle, programcı kendisi için bazı araçlar yazdığı noktaya gelecektir. Ve böylece yol daha akıllı kod üretmeye başlar.

(Evet, anında bayt kodunu oluşturabilirsiniz, ancak Java'da böyle bir şeyi programlamak, rastgele bir programcının birkaç satırlık etki alanı kodu yazmak arasında yapabileceği bir şey olmaz.)

Bunu çok dinamik olan dillerle karşılaştırın; örneğin Ruby, çoğu zaman Java'ya karşı olan antitezi düşünürdüm (her iki yaklaşıma da değer vermeden bunu söylediğimi unutmayın; bunlar sadece farklıdır). Burada, çalışma zamanında dinamik olarak sınıflar, yöntemler vb. Üretmek için% 100 normal ve standart bir programdır ve en önemlisi, programcı, "meta" seviyesine girmeden, tam anlamıyla kodda yapabilir. Evet, Ruby on Rails gibi şeyler kod üretme ile geliyor, ancak çalışmalarımızda bunu temelde yeni programcılar için bir tür gelişmiş "eğitim modu" olarak kullandığımızı gördük, ancak bir süre sonra gereksiz hale geliyor (çok az kod olduğu için Bu ekosisteme yazmak için, ne yaptığınızı bildiğinizde, el ile yazmak, oluşturulan kodu temizlemekten daha hızlı olur).

Bunlar "gerçek dünyadan" sadece iki pratik örnektir. Kod nereye Sonra LISP gibi dilleri var olduğunu anlamıyla verileri. Öte yandan, derlenmiş dillerde (Java veya Ruby gibi bir çalışma motoru olmadan), çalışma zamanında sınıf veya yöntem adlarını tanımlayan hiçbir kavram yoktur (ya da modern C ++ özelliklerine uymadım ...), bu yüzden kod oluşturma, derleme işlemi çoğu şey için tercih edilen bir araçtır (diğer C / C ++ 'a özgü örnekler esnek, yacc vb. gibi şeyler olabilir).

neden kod oluşturmalı?

Çünkü delikli kartlarla programlama (veya not defterinde alt kodlar ) bir acıdır.

Performans nedeniyle yapılıyorsa, derleyiciden bir eksiklik gibi geliyor.

Doğru. Zorunlu olmadığım sürece performans umurumda değil.

İki dilin köprülenmesi için yapılıyorsa, arayüz kütüphanesi eksikliği gibi geliyor.

Ne demek istediğin hakkında hiçbir fikrin yok.

Şunun gibi bakın: Oluşturulan ve tutulan kaynak kodu her zaman ve sonsuza dek popoda bir acıdır. Sadece bir nedenden dolayı var. Birisi bir dilde çalışmak isterken, bir başkası başka biri üzerinde çalışmakta ısrar eder ve ikisi de aralarında nasıl birlikte çalışacağını bulmak için canını sıkmaz, onlardan biri en sevdikleri dili nasıl uyguladıkları dile nasıl dönüştürebileceklerini belirleyebilir. isterler.

Bunu sürdürmek zorunda kalana kadar bu iyi. Bu noktada hepiniz ölebilirsiniz.

Anti bir kalıp mıdır? Sigh, hayır. Daha önceki dillerin eksikliklerine elveda demeye istekli olmasaydık ve daha eski dillerin kodunu çıkarmaya bile başlamazsak, birçok dil mevcut olamazdı.

Buna dayanamayacağım yarı dönüştürülmüş Frankenstein canavarı patchwork'ünde bırakılan bir kod üssü. Oluşturulan kod dokunulmaz koddur. Dokunulmaz kodlara bakmaktan nefret ediyorum. Yine de insanlar kontrol etmeye devam ediyor. NEDEN? Yürütülebilir dosyayı kontrol ediyor olabilirsiniz.

Peki şimdi rant ediyorum. Demek istediğim hepimiz "kod üretiyoruz". Kaynak kod gibi oluşturulan kodları tedavi ederken, beni çıldırtıyorsunuz. Sadece kaynak kodun kaynak kodunu vermemesine benziyor.

neden kaynak kodu oluştur

Kariyerimde birlikte çalışmak zorunda kaldığım kod jeneratörleri için en sık kullanılan durum;

• girdi olarak bir tür veri modeli veya veritabanı şeması için üst düzey bir meta-açıklama aldı (belki ilişkisel bir şema veya bir tür XML şeması)

• ve çıktı olarak veri erişim sınıfları için kazan plakası CRUD kodu ve buna karşılık gelen SQL'ler veya belgeler gibi ilave şeyler üretti.

Buradaki fayda, kısa bir giriş spesifikasyonunun bir satırından 5 ila 10 satır hata ayıklanabilir, güvenli yazılabilir, hatasız (kod üretecinin çıktısının olgun olduğu varsayılır) edinilmesidir, aksi takdirde elle uygulamak ve korumak zorunda kalırsınız. Bunun bakım ve gelişim çabalarını ne kadar azalttığını hayal edebilirsiniz.

Ayrıca ilk sorunuza cevap vereyim

Kaynak kod üretimi bir anti patern mi

Hayır, kaynak kod üretme başlı başına değil, ama aslında bazı tuzaklar var. Pragmatik Programcı'da belirtildiği gibi, anlaşılması zor bir kod ürettiğinde kod oluşturucu kullanmaktan kaçınılmalıdır . Aksi takdirde, bu kodu kullanma veya hata ayıklama çabalarının artması, kodu manuel olarak yazmamak suretiyle kaydedilen çabadan kolayca ağır basabilir.

Ayrıca, üretilen kod bölümlerini fiziksel olarak elle yazılmış koddan fiziksel olarak ayırmanın iyi bir fikir olduğunu da eklemek isterim, yeniden oluşturma işlemi herhangi bir elle yapılan değişikliklerin üzerine yazmaz. Bununla birlikte, görevin eski dilde X ile yazılmış bazı kodları diğer dilde, daha modern bir dil Y'ye geçirmesi ve bu durumu daha sonra Y dilinde de sürdürmek niyetiyle bir kez daha ele aldım. bir kerelik kod üretimi için durum.

neden kaynak kodu üretelim?

Oluşturulan (derleme zamanında ve hiçbir zaman teslim edilmemiş) kod için iki kullanım durumuyla karşılaştım:

1. Alıcıları / ayarlayıcıları, toString, eşittir ve hashCode gibi kazan plakası kodunu, bunları belirtmek için oluşturulmuş bir dilden otomatik olarak oluşturun (örn. Java için lombok projesi)
2. Ana kodda kullanılacak bazı arayüz özelliklerinden (REST, SOAP, her neyse) otomatik olarak DTO tipi sınıflar oluşturun. Bu, dil köprüsü sorununuza benzer, ancak aynı şeyi oluşturulmuş sınıflar olmadan uygulamaya çalışmaktan daha iyi tip kullanımıyla daha temiz ve basit hale gelir.

Sussmann, klasik “Bilgisayar Programlarının Yapısı ve Yorumlanması” ndaki, özellikle de kod-veri ikiliği hakkında söylenecek çok şey hakkında ilginçti.

Benim için adhoc kod üretmenin asıl kullanımı, bazı küçük etki alanı dillerini programlarımda birleştirebileceğim bir şeye dönüştürmek için kullanılabilir bir derleyiciden yararlanmaktır. BNF'yi düşünün, ASN1'i düşünün (Aslında, yapma, çirkin), veri sözlüğünün elektronik tablolarını düşünün.

Önemsiz etki alanına özgü diller çok büyük bir zaman tasarrufu sağlayabilir ve standart dil araçlarıyla derlenebilecek bir şey çıkarmak, ne tür bir dilde olursanız olun, önemsiz olmayan bir el kesicisi gibi bu tür şeyleri oluştururken gitmenin yoludur. Yazılı mı, yoksa otomatik olarak oluşturulan biri için BNF.

Daha sonra bazı sistem derleyicilerine beslenen metni çıktırarak, bu derleyiciler optimizasyonunu ve sisteme özel konfigürasyonu düşünmek zorunda kalmadan elde ederim.

Derleyici giriş dilini başka bir aracı temsil olarak etkin kullanıyorum, sorun nedir? Metin dosyaları doğal olarak kaynak kod değildir, derleyici için bir IR olabilirler ve C veya C ++ veya Java ya da her neyse kimin umurunda olursa olsunlar.

Şimdi, eğer birilerinin giriş dili dosyalarını düzenlediğinde ve yeniden oluştururken net bir şekilde hayal kırıklığına uğratacak olan oyuncak dili ayrıştırıcısının ÇIKIŞI'nı düzenleyebileceğinizi düşünmekte zorlanıyorsanız , cevap otomatik olarak oluşturulan IR'yi depoya koymamaktır. Alet zinciriniz tarafından yaratılmıştır (ve bu tür insanların geliştirilmesinden kaçının, genellikle pazarlamada çalışmaktan daha mutlu olurlar).

Bu, bizim dilimizdeki bir ifadenin yetersizliği değildir; şartnamenin bazı kısımlarını otomatik olarak koda dönüştürülebilen bir forma sokmanın (veya masaj yapmanın) gerçeğinin bir ifadesidir ve bu genellikle çok daha az olacaktır. böcek ve bakımı çok daha kolay. Test ve konfigürasyon elemanlarımıza bir elektronik tablo verebilirsem, ince ayar yapabilirler ve daha sonra bu verileri çalıştıran ve ECU'mdaki flaş için tam bir hex dosyasını yayan bir aracı elden çevirmek için çok büyük bir zaman tasarrufu sağlarlar. Günün dilinde bir dizi sabit halinde en son kurulum (yazım hataları ile tamamlayın).

Simulink'te model oluşturma ve RTW ile C oluşturma, sonra ne araçla anlamlı olursa olsun, C hedefini derleme, orta C okunamaz durumda, ne olmuş? Yüksek seviyeli Matlab RTW malzemelerinin sadece bir C altkümesini bilmesi yeterlidir ve C derleyicisi platformun detaylarıyla ilgilenir. Bir insanın yaratılan C ile derine girmesi gereken tek zaman, RTW komut dosyalarının bir böceğine sahip olması ve bu tür bir şeyin nominal olarak insan tarafından okunabilen bir IR ile ve daha sonra sadece ikili bir ayrıştırma ağacıyla hata ayıklamak için çok daha kolaydır.

Elbette bytecode veya hatta çalıştırılabilir kod çıktısı almak için böyle şeyler yazabilirsiniz, ancak bunu neden yaptınız? Bir IR'yi bu şeylere dönüştürmek için araçlarımız var.

Pragmatik cevap: Kod üretimi gerekli ve faydalı mı? Özel kod temeli için gerçekten çok kullanışlı ve ihtiyaç duyulan bir şey sağlıyor mu, yoksa sadece alt-optimal sonuçlar için daha entelektüel ek yüke katkıda bulunacak şekilde bir şeyler yapmanın başka bir yolunu yaratıyor mu?

Tamam, bu kodun veri olduğunu da biliyorum. Anlamadığım şey neden kod ürettiğim. Neden onu parametreleri kabul edip bunlara etki edebilecek bir fonksiyon haline getirmiyorsunuz?

Bu soruyu sormanız gerekiyorsa ve net bir cevap yoksa, o zaman muhtemelen kod oluşturma gereksizdir ve yalnızca egzotizme ve kod tabanınıza büyük ölçüde bir entelektüel katkı sağlar.

Bu arada OpenShadingLanguage gibi bir şey alırsanız: https://github.com/imageworks/OpenShadingLanguage

... o zaman etkileyici sonuçların derhal cevaplandırılmasından dolayı böyle soruların cevaplanması gerekmez.

OSL, gölgelendirici ağlarını anında makine koduna (tam zamanında veya "JIT") dönüştürmek için LLVM derleyici çerçevesini kullanır ve bu işlemde, gölgelendirici parametrelerini ve yapamayan diğer çalışma zamanı değerlerini tam olarak bilen gölgelendiricileri ve ağları yoğun şekilde en iyi duruma getirir gölgelendiriciler kaynak koddan derlendiğinde bilinmektedir. Sonuç olarak, OSL gölgelendirme ağlarımızın, C'de elde edilen eşdeğer gölgelendiricilere göre% 25 daha hızlı çalıştığını görüyoruz! (Eski gölgelendiricilerimiz işleyicimizde böyle çalıştı.)

Böyle bir durumda, kod oluşturucunun varlığını sorgulamanıza gerek yoktur. Bu tür VFX alan adında çalışıyorsanız, hemen yanıtınız genellikle "sus ve paramı alın!" ya da "vay, ayrıca böyle bir şey yapmamız gerekiyor."

Hayır, ara kod üretmek bir anti-patern değildir. Sorunuzun diğer kısmına cevap, "Neden yapmalı?", Yine de bazı nedenler vermeme rağmen, çok geniş (ve ayrı) bir soru.

Hiçbir zaman insan tarafından okunabilir bir koda sahip olmamanın tarihsel sonuçları

En ünlü dillerden oldukları için C ve C ++ 'ı örnek olarak alalım.

C kodunu derlemenin mantıksal alayının makine kodundan ziyade insan tarafından okunabilen montaj kodunu çıkardığına dikkat etmelisiniz. Benzer şekilde, eski C ++ derleyicileri fiziksel olarak C ++ kodunu C koduna derlemek için kullanılır. Bu olaylar zincirinde, insan tarafından okunabilir kod 1'den insan tarafından okunabilir kod 2'den insan tarafından okunabilir kod 3'ten makine koduna derleyebilirsiniz. "Neden?" Neden olmasın?

Orta, insan tarafından okunabilir kod oluşturulur hiçbir zaman, biz bile olmayabilir sahip C veya hiç C ++. Bu kesinlikle bir olasılıktır; İnsanlar hedeflerine en az direnç gösterme yolunu izlerler ve eğer C gelişme durgunluğu nedeniyle ilk önce başka bir dil buhar kazanırsa, C hala gençken ölebilirdi. Tabii ki, “Belki o zaman belki başka bir dil kullanıyor olurduk, belki daha iyi olurdu” diyebilirsiniz. Belki, ya da belki daha kötü olurdu. Ya da belki hepimiz hala mecliste yazıyor oluruz.

Neden insan tarafından okunabilen ara kod kullanılmalı?

1. Bazen ara kod istenir, böylelikle bir sonraki adımdan önce onu değiştirebilirsiniz. Bu noktanın en zayıf olduğunu kabul edeceğim.
2. Bazen bu, orijinal çalışmanın insan tarafından okunabilen herhangi bir dilde değil, GUI modelleme aracıyla yapılmasından kaynaklanmaktadır.
3. Bazen çok tekrarlayan bir şey yapmanız gerekir ve dil ne yaptığınıza hitap etmemelidir , çünkü bu sadece çok iyi bir şekilde programlama dilinin karmaşıklığını veya dilbilgisini artıran bir işi olmayan öyle bir niş veya karmaşık bir şeydir. sen.
4. Bazen çok tekrarlanan bir şey yapmak gerekir ve orada hiçbir olası bir yoldur Eğer genel bir şekilde dile istediklerini elde etmek; ya dilin dilbilgisi ile temsil edilemez ya da çakışamaz.
5. Bilgisayarların amaçlarından biri, insan çabalarını azaltmaktır ve bazen tekrar dokunulmaması muhtemel olmayan kodlar (düşük bakım olasılığı), onda bir zamanda daha uzun kodunuzu oluşturmak için yazılmış meta kodlara sahip olabilir; eğer 2 hafta yerine 1 gün içinde yapabilirsem ve hiç korunma ihtimalim yüksek değilse, onu daha iyi üretebilirim - ve kapalı ihtimalde bundan 5 yıl sonra birisinin canımı sıkılır çünkü gerçekten de bunu sürdürmeleri gerekir, o zaman isteseler veya garip kodu sürdürmenin 1 hafta tarafından rahatsız (ama biz bu noktada 1 hafta öncesinde hala) ise tam dışarı yazma 2 hafta geçirebilirsiniz ve işte eğer o bakım hiç yapılması gereken .
6. Bakmamın daha fazla nedeni olduğundan eminim.

Örnek

Daha önce başka bir belgedeki verilere veya bilgilere dayanarak kodun üretilmesi gereken projeler üzerinde çalıştım. Örneğin, bir projenin tüm ağ mesajları ve bir elektronik çizelgede tanımlanan sabit verileri ve elektronik çizelgeden geçen ve bu iletilerle çalışmamıza izin veren birçok C ++ ve Java kodu üreten bir aracı vardı .

Bu projeyi kurmanın en iyi yolu olduğunu söylemiyorum (başlangıcının bir parçası değildim), fakat sahip olduğumuz buydu ve yüzlerce (belki de binlerce, emin değilim) yapılar, nesneler ve sabitlerdi. bu üretiliyordu; Bu noktada, muhtemelen Rhapsody gibi bir şeyle tekrar yapmak için çok geç. Fakat Rhapsody gibi bir şeyde yeniden yapıldıysa bile, yine de Rhapsody'den üretilen bir kodumuz var .

Ayrıca, tüm bu elektronik tablodaki verilerin tek bir şekilde olması iyi oldu: verileri yalnızca kaynak kod dosyalarında olsaydı sahip olamayacağımız şekilde göstermemize izin verdi.

Örnek 2

Derleyici yapımında bazı çalışmalar yaparken, lexing ve ayrıştırma işlemimi yapmak için Antlr aracını kullandım. Dil dilbilgisi belirledim, sonra aracı C ++ veya Java'da bir ton kodunu tükürmek için kullandım, daha sonra bu kodu kendi tarafında kodumda kullandım ve derlemeye dahil ettim.

Başka nasıl yapılmalıydı? Belki başka bir yolla gelebilirsin; Muhtemelen başka yolları var. Ancak bu iş için, diğer yollar sahip olduğum oluşturulan lex / ayrıştırma kodundan daha iyi olamazdı.

Kaçırdığın şey yeniden kullanım .

Kaynak kod metnini derleyiciye dönüştürmek için derleyici olarak adlandırılan harika bir aracımız var. Girdileri iyi tanımlanmıştır (genellikle!) Ve optimizasyonun nasıl yapıldığını geliştirmek için birçok çalışmadan geçti. Aslında istiyorsanız kullanmak bazı işlemleri yürütmek için derleyici, varolan derleyici kullanmak ve kendi yazmayın istiyorum.

Birçok kişi yeni programlama dilleri icat eder ve kendi derleyicilerini yazar. İstisnasız olarak, hepsi bunu yapıyor çünkü o dilin sağladığı özelliklere ihtiyaç duydukları için zorluktan zevk alıyorlar . Yaptıkları her şey başka bir dilde yapılabilirdi; onlar sadece yeni bir dil yaratıyorlar çünkü bu özellikleri seviyorlar. Onları almazsa iyi ayarlanmış, hızlı, verimli, optimize edici bir derleyici var. Onlara, metni ikilik hale getirebilecek bir şey verecek , elbette, ancak mevcut tüm derleyiciler kadar iyi olmayacak .

Metin sadece insanların okuyup yazdığı bir şey değildir. Bilgisayarlar mükemmel de evde metin ile. Aslında, XML (ve diğer ilgili formatlar) gibi formatlar başarılıdır çünkü düz metin kullanırlar. İkili dosya formatları genellikle belirsiz ve kötü bir şekilde belgelenir ve bir okuyucu nasıl çalıştıklarını kolayca bulamaz. XML nispeten kendi kendine belgelendirilerek, insanların XML biçimli dosyaları kullanan kodlar yazmasını kolaylaştırır. Ve tüm programlama dilleri metin dosyalarını okumak ve yazmak için ayarlanmıştır.

Öyleyse, hayatınızı kolaylaştırmak için yeni bir tesis eklemek istediğinizi varsayalım. Belki bir GUI düzen aracıdır. Muhtemelen Qt'un sağladığı sinyal ve slot arayüzleri . Belki de, TI'nin Kod Oluşturucu Stüdyosu , üzerinde çalıştığınız cihazı yapılandırmanıza ve doğru kitaplıkları derlemenin içine çekmenize olanak tanır. Belki de bir veri sözlüğü alıp otomatik tanımlayan typedef'leri ve global değişken tanımlarını alıyor (evet, bu hala gömülü yazılımda çok şey var). Her ne olursa olsun, mevcut derleyicinizden yararlanmanın en etkili yolu, kendi yapılandırmanıza uygun olanı seçip kendi dilinizde otomatik olarak kod üreten bir araç oluşturmaktır.

Geliştirilmesi ve test edilmesi kolaydır, çünkü neler olduğunu biliyorsunuz ve tükettiği kaynak kodunu okuyabilirsiniz. İnsan yıllarını GCC'ye rakip bir derleyici oluşturmak için harcamanıza gerek yok. Tamamen yeni bir dil öğrenmenize veya başkalarının bilmesini gerektirmenize gerek yok. Tek yapmanız gereken bu küçük alanı otomatikleştirmek ve diğer her şey aynı kalıyor. İş bitmiş.

Kaynak kodun ne olduğuna ve ne olmadığına odaklanan daha pratik bir cevap. Kaynak kodu oluşturmanın tüm bu durumlarda oluşturma işleminin bir parçası olduğunu unutmayın; bu nedenle oluşturulan dosyalar kaynak denetimine girmemelidir.

Interoprability / basitlik

Google'ın Protokol Tamponları'nı ele alalım, örnek olarak: Uygulamayı birden çok dilde oluşturmak için kullanılabilecek tek bir üst düzey protokol açıklaması yazarsınız - sistemin farklı bölümleri genellikle farklı dillerde yazılır.

Uygulama / teknik sebepler

TypeScript al - tarayıcılar yorumlayamaz, bu yüzden derleme işlemi JavaScript oluşturmak için bir transpiler (kod çeviriciyi kodlayan kod) kullanır. Aslında birçok yeni veya ezoterik derlenmiş dil, uygun bir derleyici almadan önce C'ye aktarmaya başlar.

Kullanım kolaylığı

C'ye yazılan ve sadece tek bir ikili (RTOS veya OS yok) kullanan gömülü projeler için (IoT'yi düşünün), bunları doğrudan kaynaklanmasına bağlı olarak, normal kaynak kodu gibi derlenecek verilerle bir C dizisi oluşturmak oldukça kolaydır. kaynaklar olarak.

Düzenle

Protobuf'u genişletmek: kod oluşturma, üretilen nesnelerin herhangi bir dilde birinci sınıf sınıflar olmasını sağlar. Derlenmiş bir dilde, genel bir ayrıştırıcı zorunlu olarak bir anahtar-değer yapısı döndürürdü - bu da çok sayıda kazan plakası kodu yerine getirmediğiniz anlamına gelir; bazı derleme zamanı kontrollerini kaçırırsınız (özellikle anahtarların ve değer türlerinin), daha kötü performans alırsınız ve kod tamamlanmadı. Bunların hepsini void*C veya std::variantC ++ ' da bu kadar büyük olduğunu hayal edin (C ++ 17 varsa), bazı dillerin böyle bir özelliği olmayabilir.

Kaynak kod üretimi bir model midir?

Yeterince dışavurumcu bir programlama dili için iyi bir çözüm. Yeterli yerleşik meta-programlama içeren bir dilde kod oluşturmaya gerek yoktur.

Kaynak kod üretimi her zaman bir anti-kalıp değildir. Örneğin, şu anda belirtilen spesifikasyonla iki farklı dilde kod üreten bir çerçeve yazıyorum (Javascript ve Java). Çerçeve, kullanıcının tarayıcı eylemlerini kaydetmek için oluşturulan Javascript'i kullanır ve çerçeve yeniden yürütme modundayken eylemi gerçekten yürütmek için Selenyum'daki Java kodunu kullanır. Kod oluşturma özelliğini kullanmasaydım, el ile ikisinin de her zaman senkronize olduğundan, hantal ve aynı zamanda bir şekilde mantıklı bir çoğaltma olduğundan emin olmam gerekirdi.

Bununla birlikte, biri jenerikler gibi özellikleri değiştirmek için kaynak kodu üretiyorsa, anti-paterndir.

Burada bir şey mi eksik?

Belki de ara kodun başarının nedeni olduğu ortaya çıkmış iyi bir örnek? Size HTML sunabilirim.

HTML'nin basit ve statik olmasının önemli olduğuna inanıyorum - tarayıcıları kolaylaştırdı, mobil tarayıcıları daha erken başlatmasına izin verdi. . Kullanıcıların Java uygulamaları tarafından gerçekten tehlike altında oldukları ve bu tür web sitelerini ziyaret etmenin DC ++ ile indirilen oyun çatlaklarını denemek kadar güvenli olduğu ortaya çıktı. Öte yandan, düz HTML, herhangi bir siteyi cihazımızın güvenliği konusunda makul bir inançla kontrol etmemize izin verecek kadar zararsızdır.

Ancak, HTML, bilgisayar tarafından oluşturulmuş olmasaydı, şimdi olduğu yere yakın bir yerde olmazdı. Cevabım, birileri onu veritabanından HTML dosyasına manuel olarak yeniden yazana kadar bu sayfada görünmezdi. Neyse ki hemen hemen her programlama dilinde kullanılabilir HTML yapabilirsiniz :)

Diğer bir deyişle, eğer bir şey için bir kod üreticisi varsa, neden gerekli parametreleri alabilen ve "oluşturulacak" kodun yapacağı doğru işlemi yapan uygun bir fonksiyon yapmıyorsunuz?

Soruyu ve tüm cevapları ve yorumları kullanıcıya göstermek için HTML arasında oluşturulan kod olarak kullanmaktan daha iyi bir yol hayal edebiliyor musunuz?

neden kaynak kodu üretelim?

Çünkü, özellikle sıkıcı, tekrarlayan işler için kodu manuel olarak yazmaktan daha hızlı ve daha kolay (ve daha az hata eğilimli). Tek bir kod satırı yazmadan önce tasarımınızı doğrulamak ve doğrulamak için üst düzey aracı da kullanabilirsiniz.

Yaygın kullanım durumları:

• Rose veya Visual Paradigma gibi modelleme araçları;
• High- er Gömülü SQL veya Derlenebilir şey haline Önişlenmiş gereken bir arayüz tanım dili gibi seviye diller;
• Flex / bison gibi Lexer ve ayrıştırıcı jeneratörler;

“Neden sadece bir işlev yapmıyor ve doğrudan ona parametreler iletmiyorsunuz?” Konusuna gelince, yukarıdakilerin hiçbirinin kendi içinde yürütme ortamları olmadığını unutmayın. Kodunuzu bunlara karşı bağlamanın yolu yok.

Bazen, programlama diliniz sadece istediğiniz özelliklere sahip olmayabilir, bu da istediğiniz şeyi yapmak için işlevler veya makrolar yazmayı imkansız hale getirir. Ya da belki olabilir ne istersen yap, ama kod çirkin olurdu yazmak için. Basit bir Python betiği (veya benzeri), daha sonra #includegerçek kaynak dosyaya girdiğiniz, derleme işleminizin bir parçası olarak gerekli kodu oluşturabilir .

Bunu nasıl bilebilirim? Çünkü bu, en son SourcePawn olan çeşitli farklı sistemlerle çalışırken defalarca ulaştığım bir çözüm. Basit bir kaynak kodu satırını ayrıştırıp iki veya üç satır kod ürettiğinden oluşan basit bir Python betiği, iki düzine satır yazdığınızda (tüm cvarlarımı oluştururken) oluşturulan kodu el ile oluşturmaktan çok daha iyidir.

İnsanlar isterse gösterme / örnek kaynak kodu kullanılabilir.

Metin formu insanlar tarafından kolay tüketilmesi için gereklidir. Bilgisayarlar ayrıca kodları oldukça kolay bir şekilde metin biçiminde işler. Bu nedenle, üretilen kodun üretmesi en kolay ve bilgisayarları tarafından tüketilmesi en kolay olan ve çoğunlukla okunabilen metin biçiminde üretilmesi gerekir.

Kod oluşturduğunuzda, kod oluşturma işleminin kendisinin sıklıkla hata ayıklanması gerekir - insanlar tarafından. Eğer üretilen kod insan tarafından okunabilir ise, insanlar kod oluşturma sürecindeki sorunları tespit edebiliyorsa, çok, çok faydalıdır. Sonuçta, birinin kodu oluşturmak için kodu yazması gerekiyor. İnce havadan olmaz.

Kod Oluşturma, yalnızca bir kez

Tüm kaynak kod üretme, bazı kod üretme durumu değildir ve ardından hiçbir zaman ona dokunmaz; daha sonra, güncellemesi gerektiğinde, orijinal kaynaktan yeniden üretir.

Bazen yalnızca bir kez kod üretirsiniz, sonra orijinal kaynağı atarsınız ve ileriye doğru ilerlemek yeni kaynağı korur.

Bu bazen kodu bir dilden diğerine taşırken olur. Özellikle, bir kişi orijinal belgede yeni değişiklikler yapmak için daha sonra bağlantı kurmak istemezse (örneğin, eski dil kodu korunmayacak veya aslında tamamlandı (örneğin, bazı matematik işlevleri söz konusu olduğunda)).

Yaygın bir durum, bunun için bir kod üreticisi yazmanın, kodun yalnızca% 90'ını doğru bir şekilde çevirebilmesidir. ve sonra son% 10'un elle düzeltilmesi gerekiyor. Bu,% 100'ü elle çevirmekten çok daha hızlıdır.

Bu tür kod üreteçleri, genellikle tam dil çevirmenlerinin (Cython veya benzeri f2c) ürettiği kod üreteçlerinden çok farklıdır . Amaç bir kez kodunu korumaktır çünkü. Tam olarak yapmaları gerekeni yapmak için genellikle 1 kapalı olarak yapılırlar. Birçok yönden, port koduna bir regex / find-replace kullanmanın bir sonraki seviye sürümüdür. "Takım destekli taşıma" diyebilirsiniz.

Örneğin bir web sitesi sıyırıcısından yalnızca bir kez Kod Oluşturma.

Yakından ilgili olan, kodu bir kaynaktan oluşturursanız tekrar erişmek istemezsiniz. Örn: kodu oluşturmak için gereken eylemler tekrarlanabilir, tutarlı değilse veya bunları gerçekleştirmek pahalı ise. Şu anda bir çift proje üzerinde çalışıyorum: DataDeps.jl ve DataDepsGenerators.jl .

DataDeps.jl, kullanıcıların veri indirmesine yardımcı olur (standart ML veri kümeleri gibi). Bunu yapmak için, RegistrationBlock dediğimiz şeye ihtiyacı var. Bu, dosyaların nereden yükleneceği ve bir sağlama toplamı gibi bazı meta verileri belirten bir kod ve kullanıcıya herhangi bir terim / birleşim / verilerdeki lisanslama durumunun ne olduğunu açıklayan bir mesajdır.

Bu blokları yazmak can sıkıcı olabilir. Ve bu bilgiler genellikle verilerin yapılandırıldığı web sitelerinde (yapılandırılmış veya yapılandırılmamış) bulunur. Bu nedenle DataDepsGenerators.jl, çok sayıda veri barındıran bazı siteler için RegistrationBlockCode oluşturmak için bir web kodlayıcı kullanır.

Onları doğru şekilde üretmeyebilir. Böylece oluşturulan kodu kullanan dev, onu kontrol edebilir ve düzeltmelidir. Örneğin, örneğin lisanslama bilgilerini kaçırmamış olduğundan emin olmak istiyorlar.

Önemli olarak, DataDeps.jl ile çalışan kullanıcılar / dev'lerin, oluşturulan RegistrationBlock kodunu kullanmak için web sayfasını kurmaları veya kullanmaları gerekmez. (Ve bir web sıyırıcısını indirip kurmaya gerek duymamak, özellikle CI çalışmaları için oldukça zaman kazandırır)

Kaynak kodunu bir kez üretmek bir antipattern değildir. ve normalde metaprogramming ile değiştirilemez.

"Kaynak" kodunun üretilmesi, oluşturulan dilin bir eksikliğinin bir göstergesidir. Bunun bir modelini aşmak için araçlar kullanmak mı? Kesinlikle hayır - açıklamama izin verin.

Tipik olarak, kod oluşturma kullanılır, çünkü elde edilen kodu, düşük seviye dilden çok daha az ayrıntılı olarak tanımlayabilen daha yüksek düzeyde bir tanım vardır. Böylece kod oluşturma, verimliliği ve netliği kolaylaştırır.

C ++ yazdığımda, kod yazımını veya makine kodunu kullanmaktan daha verimli kod yazmamı sağladığı için yapıyorum. Makine kodu hala derleyici tarafından üretilir. Başlangıçta, c ++ C kodunu üreten ön işlemciydi. Genel amaçlı diller, genel amaçlı davranış oluşturmak için mükemmeldir.

Aynı şekilde, bir DSL (etki alanına özgü dil) kullanarak kısa bir yazı yazmak mümkündür, ancak belirli bir göreve sınırlı kod yazabilirsiniz. Bu, kodun doğru davranışını oluşturmayı daha az karmaşık hale getirecektir. Unutmayın ki bu kod demek ve bitirmek demektir . Bir geliştiricinin aradığı şey davranış oluşturmanın etkili bir yoludur.

İdeal olarak jeneratör, kullanımı ve anlaşılması daha kolay olan bir girdiden hızlı kod oluşturabilir. Bu yerine getirilirse , bir jeneratör kullanılmaması bir anti-paterndir . Bu anti-desen genellikle "saf" kod ahşap işçisi veya diğer esnaf iş parçalarını "üretmek" için elektrikli aletler veya CNC kullanımının kullanıldığına bakıp olabilir aynı şekilde çok "temiz", (düşünmek olduğu anlayışına gelen altın çekiç ).

Öte yandan, oluşturulan kodun kaynağının yeteri kadar verimli olmayan kodun korunması veya üretilmesi daha zor ise, kullanıcı yanlış araçları kullanma tuzağına düşüyor (bazen aynı altın çekiç nedeniyle ).

Kaynak kod üretimi kesinlikle oluşturulan kodun veri olduğu anlamına gelir. Ancak, birinci sınıf veri, programın geri kalanının manipüle edebileceği veridir.

Farkında olduğum en yaygın iki veri kaynağı, kaynak koduna entegre edilmiştir, pencereler (çeşitli kontrollerin sayısı ve yerleşimi) ve ORM'ler hakkında grafiksel bilgidir. Her iki durumda da, kod oluşturma yoluyla entegrasyon, verilerin kullanımını kolaylaştırır, çünkü bunları kullanmak için ekstra "özel" adımlar atmanız gerekmez.

Orijinal (1984) Mac'lerle çalışırken, verileri ikili biçimde tutan bir resouce editörü kullanılarak diyalog ve pencere tanımları oluşturuldu. Bu kaynakları uygulamanızda kullanmak, "ikili format" Pascal olsaydı, olması gerekenden daha zordu.

Böylece, hayır, kaynak kodu üretimi bir anti-kalıp değildir, verinin uygulamanın bir parçası olmasını sağlar ve bu da kullanımını kolaylaştırır.

Kod oluşturma, başardığından daha pahalı olduğu zaman bir kalıptır. Bu durum, A'dan B'ye, A'nın neredeyse B ile aynı dil olduğu A'dan B'ye gerçekleştiğinde, ancak A'ya B'nin tüm özel kalıplama ve A'dan B'ye evreleme için daha az çabayla kodlanmasıyla yapılabilecek bazı küçük uzantılarda meydana gelir. .

Dış metin işleme aşamalarında metaprogramlamayı gerçekleştirmenin komplikasyonları ve yetersizlikleri nedeniyle meta-programlama olanakları olmayan (yapısal makrolar) olmayan dillerde kod üretimine karşı daha yasaklıdır.

Zayıf ticaret, kullanım miktarıyla da ilgili olabilir. Dil A, B'den önemli ölçüde farklı olabilir, ancak özel kod oluşturucusuyla tüm proje yalnızca bir veya iki küçük yerde A kullanır, böylece toplam karmaşıklık miktarı (küçük A bitleri, artı A -> B kod üreteci, artı çevreleyen yapı evrelemesi) B'de yapılan bir çözümün karmaşıklığını aşıyor.

Temel olarak, eğer kod üretmeyi taahhüt edersek, büyük olasılıkla “büyük veya eve gitmeliyiz”: önemli bir anlambilimine sahip olmasını sağlamalı ve çok kullanmalı ya da rahatsız etmemeliyiz.

Bunu açıkça görmedim (bir ya da iki cevabın dokunduğunu gördüm, ama çok net görünmüyordu)

Kod üretmek (dediğiniz gibi, veriymiş gibi) bir sorun değil - derleyiciyi ikincil bir amaç için yeniden kullanmak için bir yol.

Oluşturulan kodu düzenlemek, şimdiye kadar karşılaşacağınız en sinsi, kötü, korkunç anti-paternlerden biridir. Bunu yapma.

En iyi ihtimalle, oluşturulan kodun düzenlenmesi projenize bir sürü zayıf kodu çeker (ENTIRE kod kümesi şimdi gerçekten KAYNAK KODU - artık veri değil). En kötüsü, programınıza çektiğiniz kodun fazlasıyla gereksiz olduğu, neredeyse tamamen anlaşılamayan, kötü adlandırılmış bir çöp.

Sanırım üçüncü bir kategori bir kez kullandığınız koddur (gui generator?) Ve başlamanıza / öğrenmenize yardımcı olacak şekilde düzenleyin. Bu, her ikisinden de biraz - başlamak için iyi bir yol olabilir, ancak GUI jeneratörünüz, bir programcı olarak sizin için iyi bir başlangıç ​​olmayacak "Generatable" kodunu kullanarak hedeflenecektir - Ayrıca, ikinci bir GUI için tekrar kullanmaya istekli, bu da sisteminize yedek SOURCE kodunu çekmek anlamına gelir.

Takımınız, oluşturulan kodun herhangi bir düzenlemesine izin vermeyecek kadar akıllıysa, bunun için gidin. Olmazsa, oradaki en kötü anti-paternlerden biri diyebilirim.

Hem kod hem de veri: Bilgi.

Veri, tam olarak ihtiyaç duyduğunuz (ve değer) formdaki bilgidir. Kod aynı zamanda bilgidir, ancak dolaylı veya ara formda. Temelde, kod aynı zamanda bir veri biçimidir.

Daha spesifik olarak, kod, makinelerin insanları işlem bilgisinden tamamen kendiliğinden çıkarmaları için olan bilgidir.

İnsanları bilgi işlemden boşaltmak en önemli sebep. Orta adımlar, hayatı kolaylaştırdığı sürece kabul edilebilir. Bu nedenle ara bilgi haritalama araçları mevcuttur. Kod üreteçleri, derleyiciler, aktarıcılar vb.

neden kaynak kodu üretelim? Neden onu parametreleri kabul edip bunlara etki edebilecek bir fonksiyon haline getirmiyorsunuz?

Diyelim ki birileri size uygulaması sizin için karanlık olan bir haritalama işlevi sunuyor. İşlev vaat edildiği gibi çalıştığı sürece, dahili olarak kaynak kodu üretip üretmemesine dikkat eder misiniz?

Bir şey üretilebiliyorsa, o şey kod değil, veridir.

Daha sonra koyduğunuzda bu kod veridir, teklifiniz “Bir şey üretilebiliyorsa, o şey kod değildir” dür. Öyleyse, bir C derleyicisi tarafından oluşturulan montaj kodunun kod olmadığını söyler misiniz? El ile yazdığım montaj koduyla tam olarak çakışırsa ne olur? İstersen oraya gidebilirsin, ama seninle gelmeyeceğim.

Bunun yerine "kod" tanımıyla başlayalım. Çok teknik olmadan, bu tartışmanın amaçları için oldukça iyi bir tanım "bir hesaplama yapmak için makinede işlem yapılabilir talimatlar" olacaktır.

Buna bakıldığında, kaynak kod üretmenin bütün bu fikri bir yanlış anlama değil midir?

Evet, başlangıç ​​teklifiniz bu kodun üretilememesidir, ancak ben bu teklifi reddediyorum. Eğer "kod" tanımımı kabul ediyorsanız, genel olarak kod oluşturmada kavramsal bir problem olmamalıdır.

Diğer bir deyişle, eğer bir şey için bir kod üreticisi varsa, neden gerekli parametreleri alabilen ve "oluşturulacak" kodun yapacağı doğru işlemi yapan uygun bir fonksiyon yapmıyorsunuz?

Eh, bu tamamen farklı bir soru, doğası hakkında değil, kod üretme nedenleriyle ilgili. Alternatif bir kod üreteci yazmak veya kullanmak yerine, sonucu doğrudan hesaplayan bir işlev yazıyorsunuz. Ama hangi dilde? Birisinin doğrudan makine kodunda yazdığı günler geride kaldı ve kodunuzu başka bir dilde yazdığınızda, gerçekten çalışan bir program üretmek için bir derleyici ve / veya assembler biçimindeki bir kod oluşturucusuna güveniyorsunuz.

Neden öyleyse, Java ya da C ya da Lisp ya da her neyse yazmayı tercih edersiniz? Montajcı bile mi? En azından kısmen bu dillerin, yapmak istediğiniz hesaplamanın ayrıntılarını açıklamayı kolaylaştıran veri ve işlemler için soyutlamalar sağladığını iddia ediyorum.

Aynısı, çoğu üst seviye kod üreticisi için de geçerlidir. Prototipi vakalar gibi tarayıcı ve ayrıştırıcı jeneratör muhtemelen lexve yacc. Evet, bir tarayıcı ve ayrıştırıcıyı doğrudan C'ye veya istediğiniz başka bir programlama dilinde (hatta ham makine kodu) yazabilirsiniz ve bazen bir tane yazabilir. Ancak, herhangi bir önemli karmaşıklık sorunu için, lex veya yacc'ler gibi daha üst düzey, özel amaçlı bir dil kullanmak, elle yazılmış kodun yazılmasını, okunmasını ve korunmasını kolaylaştırır. Genellikle çok daha küçük.

"Kod üreteci" ile tam olarak ne demek istediğinizi de düşünmelisiniz. C ön işleme ve C ++ şablonlarının başlatılmasının kod oluşturma alıştırması olduğunu düşünürdüm; bunlara itiraz ediyor musunuz? Değilse, o zaman bence bunları kabul etmeyi rasyonelleştirmek, ancak diğer kod üretme lezzetlerini reddetmek için bazı zihinsel jimnastik yapmanız gerekecek.

Performans nedeniyle yapılıyorsa, derleyiciden bir eksiklik gibi geliyor.

Neden? Temel olarak, kullanıcının verileri beslediği, bazıları "talimatlar" ve diğerleri "girdi" olarak sınıflandırılan ve hesaplamayı gerçekleştirip "çıktı" olarak adlandırdığımız daha fazla veri yayan bir evrensel programa sahip olmalısınız. (Belli bir bakış açısına göre, böyle bir evrensel programa "işletim sistemi" denebilir.) Fakat neden bir derleyicinin daha genel bir programı optimize etmek gibi genel amaçlı bir programı optimize etmede daha etkili olması gerektiğini düşünüyorsunuz? Program? İki program farklı özelliklere ve farklı yeteneklere sahiptir.

İki dilin köprülenmesi için yapılıyorsa, arayüz kütüphanesi eksikliği gibi geliyor.

Bir dereceye kadar evrensel bir arayüz kütüphanesine sahip olmanın mutlaka iyi bir şey olacağını söylüyorsunuz. Belki öyle olurdu, ama çoğu durumda böyle bir kütüphane yazmak büyük ve zor, hatta belki de yavaş olabilir. Ve eğer böyle bir canavar eldeki belirli soruna hizmet etmek için mevcut değilse, o zaman bir kod oluşturma yaklaşımı sorunu daha kolay ve daha çabuk çözdüğünde, bunun yaratılmasında kim ısrar edersiniz?

Burada bir şey mi eksik?

Sanırım birkaç şey var.

Bu kodun veri olduğunu da biliyorum. Anlamadığım şey neden kaynak kodu ürettiğim? Neden onu parametreleri kabul edip bunlara etki edebilecek bir fonksiyon haline getirmiyorsunuz?

Kod üreteçleri, bir dilde yazılmış kodu farklı, genellikle daha düşük bir dilde kodlamaya dönüştürür. O zaman, neden insanların çoklu dil kullanarak programlar yazmak istediklerini ve özellikle neden farklı seviyelerde dilleri karıştırmak isteyebileceklerini soruyorsunuz.

Ama ben buna çoktan dokundum. Biri, kısmen o görevin netliği ve açıklığına dayanan belirli bir görev için bir dil seçer. Daha küçük kodlar ortalama olarak daha az hataya sahip olduklarından ve bakımı daha kolay olduğu için, en azından büyük ölçekli işler için daha yüksek seviyeli dillere yönelik bir önyargı da vardır. Ancak, karmaşık bir program birçok görevi içerir ve çoğu zaman bir dilde daha etkili bir şekilde ele alınabilirken, diğerleri başka bir dilde daha etkili veya daha kapsamlı olarak ele alınabilir. İş için doğru aracı kullanmak, bazen kod oluşturma anlamına gelir.

Sorunuzu yorumunuz bağlamında yanıtlama:

Derleyicinin görevi, insan tarafından okunabilir biçimde yazılmış bir kod almak ve onu makinede okunabilen forma dönüştürmektir. Dolayısıyla, derleyici verimli bir kod oluşturamazsa, derleyici işini düzgün yapmıyor demektir. Yanlış mı?

Bir derleyici göreviniz için asla optimize edilmeyecek. Bunun nedeni basittir: birçok görevi yapmak için optimize edilmiştir . Birçok insan tarafından birçok farklı görev için kullanılan genel amaçlı bir araçtır. Görevinizin ne olduğunu öğrendikten sonra, derleyiciye özel bir şekilde koda yaklaşabilir, derleyicilerin yapamayacağı travmalar yapabilirsiniz.

Örnek olarak, bir analistin kod yazması gereken yazılım üzerinde çalıştım. Algoritmalarını C ++ 'da yazabilirler ve bağlı oldukları tüm sınır kontrollerini ve notlama numaralarını ekleyebilirlerdi, ancak bu kodun içsel çalışmaları hakkında çok şey bilmeyi gerektirir . Basit bir şey yazmayı tercih ederler ve son C ++ kodunu oluşturmak için ona bir algoritma atayım. Sonra, analistlerimin asla dayanmasını beklemeyeceğim statik analiz gibi performansı en üst düzeye çıkarmak için egzotik hileler yapabilirim. Kod oluşturma, ürünü kapıdan çıkarmasını sağlayan herhangi bir genel amaçlı araçtan daha kolay hale getiren, alana özgü bir şekilde yazmalarını sağlar.

Ben de tam tersini yaptım. Yapmış olduğum ve "kod üretmeyen" bir görevi olan başka bir işim var. Yazılımı kullananlar için hayatı kolaylaştırmak istedik, bu yüzden derleyicinin anında kodu oluşturması için büyük miktarlarda şablon metaprogramlama kullandık. Bu yüzden, işimi yapabilmek için sadece genel C ++ diline ihtiyacım vardı.

Ancak, bir yakalama var. O was müthiş hatalar okunabilir olduğunu garanti etmek zor. Daha önce şablon meta programlanmış kodunu kullandıysanız, tek bir masum hatanın, neyin yanlış gittiğini anlamak için 100 satır anlaşılmaz sınıf adı ve şablon argümanı alan bir hata üretebileceğini biliyorsunuzdur. Bu etki, sözdizimi hataları için önerilen hata ayıklama işleminin "Kendi dosyalarınızdan birinin ilk kez hata verdiğini görene kadar hata günlüğünü kaydırın." Şeklinde olduğunu belirtti. yanlış yaptın."

Kod oluşturmayı kullanmış olsaydık, insan tarafından okunabilen hatalarla çok daha güçlü hata işleme yeteneklerimiz olabilirdi. C'est la vie.

Kod oluşturmanın birkaç farklı yolu vardır. Üç ana gruba ayrılabilirler:

• Derleme işlemindeki bir adımdan çıktı olarak farklı bir dilde kod üretmek. Tipik derleyici için bu daha düşük seviyeli bir dil olabilir, ancak JavaScript'i derleyen dillerde olduğu gibi başka bir üst seviye diline olabilir.
• Derleme işleminde bir adım olarak kaynak kod dilinde kod üretmek veya dönüştürmek . Bu ne makrolar yapar.
• Düzenli derleme işleminden ayrı bir araçla kod üretmek. Bunun çıktısı, normal kaynak kodla birlikte dosya halinde yaşayan ve beraberce derlenen koddur. Örneğin, bir ORM için varlık sınıfları bir veritabanı şemasından otomatik olarak oluşturulabilir veya veri aktarım nesneleri ve servis arayüzleri SOAP için bir WSDL dosyası gibi bir arayüz belirtiminden oluşturulabilir.

Sanırım üçüncü tür oluşturulan koddan bahsediyorsunuzdur, çünkü bu en tartışmalı biçimdir. İlk iki formda üretilen kod, kaynak koddan çok net bir şekilde ayrılmış olan bir ara adımdır. Ancak üçüncü formda, kaynak kod ile üretilen kod arasında resmi bir ayrım yoktur, ancak üretilen kodun muhtemelen "bu kodu düzenleme" diyen bir yorumu vardır. Yine de, geliştiricilerin, gerçekten çirkin olacak üretilen kodu düzenleme riskini açar. Derleyicinin bakış açısından, oluşturulan kod kaynak koddur.

Bununla birlikte, bu tür oluşturulan kod biçimleri statik olarak yazılmış bir dilde gerçekten yararlı olabilir. Örneğin, ORM varlıklarıyla entegrasyon olduğunda, veritabanı tabloları için güçlü şekilde yazılmış sarmalayıcılara sahip olmak gerçekten yararlıdır. Entegrasyonu çalışma zamanında dinamik olarak idare edebileceğinizden emin olabilirsiniz , ancak tip güvenliği ve araç desteğini (kod tamamlama) kaybedeceksiniz. Statik olarak yazılan dilin en büyük yararı, yazı tipinin çalışma zamanında değil yazı tipinde desteklenmesidir. (Buna karşılık, bu tür kod oluşturma, dinamik olarak yazılmış dillerde çok yaygın değildir, çünkü böyle bir dilde çalışma zamanı dönüşümlerine kıyasla hiçbir fayda sağlamaz.)

Diğer bir deyişle, eğer bir şey için bir kod üreticisi varsa, neden gerekli parametreleri alabilen ve "oluşturulacak" kodun yapacağı doğru işlemi yapan uygun bir fonksiyon yapmıyorsunuz?

Güvenlik ve kod tamamlama türü, derleme zamanında (ve bir IDE kodu yazarken) istediğiniz özellikler olduğundan, normal işlevler yalnızca çalışma zamanında yürütülür.

Yine de bir orta yol olabilir: F #, derleme zamanında programlı olarak oluşturulan temelde güçlü şekilde yazılan arayüzler olan tip sağlayıcıları kavramını destekler. Bu kavram muhtemelen birçok kod üretme kullanımının yerini alabilir ve endişelerin daha net ayrılmasını sağlayabilir.

İşlemci komut setleri temel olarak zorunludur , ancak programlama dilleri bildirimsel olabilir . Bilgilendirici bir dilde yazılmış bir programı çalıştırmak kaçınılmaz olarak bir tür kod oluşturma gerektirir. Bu cevapta ve diğerlerinde de belirtildiği gibi , insan tarafından okunabilir bir dilde kaynak kodu oluşturmanın ana nedeni, derleyiciler tarafından gerçekleştirilen karmaşık optimizasyonlardan yararlanmaktır.

Bir şey üretilebiliyorsa, o şey kod değil, veridir.

Yanlış yoldan anladın. Okumalı

Bir şey yorumlanabilirler için bir jeneratöre beslenebilirse , o şey veri değil, koddur.

Bu derleme aşaması için kaynak formatıdır ve evye formatı hala koddur.