Proses Hesaplamaları ve PL Teorisinin modern programlama dili gelişimi için kullanımı

Bir süredir dil teorisi ve süreç hesaplarını programlamakla çok ilgileniyorum ve bunları incelemeye başladım. Dürüst olmak gerekirse, kariyer için aklıma gelmeyecek bir şey. Teoriyi inanılmaz büyüleyici buluyorum. Sürekli devam ettiğim bir soru, PL Teorisi veya Proses Hesaplarının modern programlama dili gelişiminde hiç önemi olup olmadığıdır. Pi-matematikte çok fazla varyant görüyorum ve çok fazla aktif araştırma var, ancak bunlara ihtiyaç duyulacak mı veya önemli uygulamalar olacak mı? Sormamın nedeni, programlama dilleri geliştirmeyi sevmem ve gerçek son hedef, teoriyi aslında bir PL oluşturmak için kullanmak olacaktır. Yazdıklarım için, gerçekten teori ile hiçbir korelasyon yoktu.

Cevabım gerçekten sadece Gilles'in, benim yazmadan önce okumadığım bir ayrıntı. Belki de yardımcı olur.

Genelde programlama dili teorisi ve özellikle süreç hesabı ile ilgili olarak programlama dilleri çalışmasının iki boyutu arasında bir ayrım ile sorunuzu cevaplamaya çalışmama izin verin.

• Saf araştırma.

• Ürün odaklı araştırma ve geliştirme.

İkincisi tipik olarak, programlama dillerini bir ürün olarak sunmak amacıyla endüstride gerçekleşir. Oracle'da Java ve Microsoft'ta C # geliştiren takımlar buna örnektir. Aksine, saf araştırma ürünlere bağlı değildir. Amacı, programlama dillerini gerçek ilgi konusu olan nesneler olarak anlamak ve tüm programlama dillerinin altında yatan matematiksel yapıları araştırmaktır.

Farklı hedefler nedeniyle, programlama dili teorisinin farklı yönleri saf araştırma ve ürün odaklı Ar-Ge ile ilgilidir Aşağıdaki resim nerede önemli olduğunu gösterebilir.

Bu noktada iki boyutun neden bu kadar farklı göründüklerini ve yine de birbirleriyle nasıl ilişkili olduklarını sorabilirsiniz.

Kilit öngörü, dil araştırma ve geliştirmenin programlanmasının çeşitli boyutlara sahip olduğudur: teknik, sosyal ve ekonomik. Endüstri neredeyse tanım gereği, programlama dillerinin ekonomik getirisiyle ilgilenmektedir. Microsoft ve arkadaşları yüreklerinin iyiliğinden dil geliştirmezler, çünkü programlama dillerinin onlara ekonomik bir avantaj sağladığına inanırlar. Ve bazı programlama dillerinin neden başarılı olduğunu derinlemesine araştırdılar ve diğerleri, görünüşte benzer veya daha gelişmiş özelliklere sahip değil. Ve tek bir neden olmadığını buldular. Programlama dilleri ve ortamları karmaşıktır ve belirli bir dili benimsemenin veya görmezden gelmenin nedenleri de öyle. Ancak, bir programlama dilinin başarısı için en büyük faktör, programcıların zaten yaygın olarak kullanılan dillere tercihli olarak bağlanmasıdır: ne kadar çok insan bir dili kullanırsa, daha fazla kütüphane, araç, öğretim materyali bulunur ve bir programcı o kadar verimli olur bu dili kullanıyor olabilir. Buna ağ etkisi de denir. Diğer bir neden, bireyler ve kuruluşlar için yüksek maliyetli anahtarlama dillerinin olmasıdır: özellikle deneyimli olmayan bir programcıya dil hakim olmak ve tanıdık dillere semantik mesafe büyük olduğunda, ciddi, zaman alıcı bir çabadır. Bu gerçekler göz önüne alındığında, yeni diller neden hiç çekilmez? Şirketler neden yeni diller geliştiriyor? Neden sadece Java veya Cobol ile kalmıyoruz? Sanırım bir dilin başarılı olmasının birkaç önemli nedeni var,

• Yerinden edilecek herhangi bir görevi olmayan yeni bir programlama alanı açılır. Birincil örnek, Javascript'i eşzamanlı yükselişi olan web'dir.

• Dil yapışkanlığı. Bununla dil değiştirmenin yüksek bedeli demek istiyorum. Ancak bazen programcılar farklı alanlara geçer, onlarla bir programlama dili alır ve yeni alandaki eski dilde başarılı olurlar.

• Bir dil, ciddi finansal ateş gücüne sahip büyük bir şirket tarafından itilir. Bu destek benimseme riskini azaltır, çünkü erken benimseyenler dilin birkaç yıl içinde hala destekleneceğinden makul bir şekilde emin olabilirler. Buna iyi bir örnek C #.

• Bir dil, zorlayıcı araçlar ve eko-sistemle gelebilir. Burada da C # ve .Net ve Visual Studio eko-sistemi örnek olarak verilebilir.

• Eski diller yeni özellikler kazanır. Java, her bir yinelemede fonksiyonel programlama geleneğinden daha iyi fikirler alan akla geliyor.

• Son olarak, yeni bir dilin kendine özgü teknik avantajları olabilir, örneğin daha anlamlı, daha iyi sözdizimi, daha fazla hata yakalayan yazım sistemleri vb.

Bu arka plan göz önüne alındığında, saf programlama dili araştırması ile ticari programlama dili gelişimi arasında bir miktar kopukluk olması şaşırtıcı olmamalıdır. Her ikisi de, özellikle büyük ölçekli yazılımlar için yazılım inşasını ve evrimini daha verimli hale getirmeyi amaçlasa da, endüstriyel programlama dili çalışmaları, kritik bir kitleye ulaşmak ve ağ etkisini elde etmek için hızlı benimsenmeyi kolaylaştırmakla daha fazla ilgilenmelidir. Bu, çalışan programcıların önem verdiği şeylere yönelik bir araştırma odağına yol açar. Bu kütüphane kullanılabilirliği, derleyici hızı, derlenmiş kod kalitesi, taşınabilirlik vb. Bugün uyguladığımız gibi süreç hesabı, ana akım projelerde çalışan programcılar için çok az işe yarar (her ne kadar gelecekte değişeceğine inanıyorum).

$\lambda$$\pi$$\beta$- fonksiyonel programlama için azaltma, mantık programlama için çözünürlük / birleştirme, eşzamanlı hesaplama için ad geçirme). Scala gibi bir dilin tam yazımsal çıkarsamaya sahip olup olmadığını anlamak için JVM hakkında endişelenmemize gerek yoktur. Gerçekten de JVM hakkında düşünmek, türden çıkarımın daha iyi anlaşılmasını engelleyecektir. Bu nedenle, hesaplamanın küçük çekirdek taşlara soyutlanması hayati ve güçlüdür.

Bu nedenle, dil araştırmasını, insanların oyuncaklarla oynadığı büyük bir sanal alan olarak düşünebilirsiniz ve belirli bir oyuncakla oynarken ilginç bir şey bulurlar ve oyuncağı iyice araştırırlarsa, ilginç oyuncak ana akım endüstriyel kabulüne doğru uzun yürüyüşe başlar. . Uzun yürüyüş diyorum çünkü programlama dili araştırmacısı tarafından icat edilen dil özellikleri geniş çapta kabul görmeden on yıllar sürüyor. Örneğin, çöp toplama 1950'lerde tasarlandı ve 1990'larda Java ile yaygın olarak kullanılabilir hale geldi. Desen eşleme 1970'e kadar uzanır ve sadece Scala'dan beri yaygın olarak kullanılmaktadır.

Proses hesabı özellikle ilginç bir oyuncaktır. Ancak ayrıntılı bir şekilde araştırılamayacak kadar yeni. Bu on yıl daha saf araştırma gerektirecek. Şu anda süreç teorisi araştırmalarına devam eden şey, programlama dili araştırması, (sıralı) türler teorisi ve başarı ileten eşzamanlılık için türler teorisini geliştirmektir. Hindley-Milner, sıralı programlama için orta düzeyde anlamlı ifade sistemleri, şimdi iyi anlaşılır, her yerde bulunur ve çalışan programcılar tarafından kabul edilir. Eşzamanlı programlama için orta derecede etkileyici türlere sahip olmak istiyoruz. Bununla ilgili araştırmalar 1980'lerde Milner, Sangiorgi, Turner, Kobayashi, Honda ve diğerleri gibi çoğunlukla öncü veya dolaylı olarak doğrusal mantıktan gelen doğrusallık fikrine dayanan öncüler tarafından başladı. Son birkaç yılda faaliyette büyük bir artış görüldü ve bu yukarı yönlü yörüngenin öngörülebilir gelecek için devam etmesini bekliyorum. Ayrıca, bu çalışmanın, süreç hesabı konusunda eğitim almış genç araştırmacıların endüstriyel Ar-Ge laboratuvarlarında çalışacakları pragmatik bir nedenden ötürü, ürün odaklı Ar-Ge'ye sızmaya başlamasını bekliyorum, aynı zamanda CPU ve bilgisayar mimarisinin evrimi nedeniyle ardışık hesaplama biçimlerinden.

Özetle, süreç hesabı gibi en son programlama dili teorisini kendi dil oluşturma çalışmalarınızda yararlı bulamadığınızdan endişe etmem. Bunun nedeni, en ileri teorinin mevcut programlama dillerinin endişelerini gidermemesi. Gelecekteki dillerle ilgilidir. 'Gerçek dünyanın' yetişmesi biraz zaman alacaktır. Bugün için dil oluşturmak için kullandığınız bilgi, geçmişin programlama dili teorisidir. Proses hesabı hakkında daha fazla bilgi edinmenizi öneririm, çünkü bu teorik bilgisayar biliminin en mevcut alanlarından biridir.

Programlama dili tasarım bilimi, emekleme döneminde çok fazladır. Teori (programların ne anlama geldiğinin ve bir dilin ifade edilebilirliğinin araştırılması) ve ampirizm (programcıların ne yapmayı başardığı veya yapmayı başaramadığı), bir dil tasarlarken şu veya bu şekilde tartmak için birçok nitel argüman verir. Ancak nadiren karar vermek için nicel bir nedenimiz var.

Bazı teorilerin bir inovasyonun pratik bir programlama dilinde kullanılabilmesi için yeterince stabilize olduğu zaman ile bu inovasyonun “ana akım” dillerde ortaya çıkmaya başladığı zaman arasında bir gecikme vardır. Örneğin, çöp toplama ile otomatik bellek yönetiminin 1960'ların ortalarında endüstriyel kullanım için olgun olduğu, ancak 1995'te Java ile sadece ana akımına ulaştığı söylenebilir. Parametrik polimorfizm 1970'lerin sonunda iyi anlaşıldı ve yapıldı 200'lerin ortalarında Java'ya. Bir araştırmacının kariyeri açısından, 30 yıl uzun bir süre.

Bir dilin geniş çapta endüstriyel olarak benimsenmesi sosyologların incelemesi gereken bir konudur ve bilimin bebeklik döneminde daha da fazla olduğu görülmektedir. Pazarla ilgili düşünceler önemli bir faktördür - Sun, Microsoft veya Apple bir dili zorluyorsa, bunun herhangi bir sayıda POPL ve PLDI belgesinden çok daha fazla etkisi vardır. Seçimi olan bir programcı için bile, kitaplık kullanılabilirliği genellikle dil tasarımından çok daha önemlidir. Bu dil tasarımının önemli olmadığı anlamına gelmez: iyi tasarlanmış bir dile sahip olmak bir rahatlamadır! Bu genellikle belirleyici faktör değildir.

Süreç hesabı hala teorinin stabilize olmadığı aşamadadır. Sıralı hesaplamaları anladığımıza inanıyoruz - sıralı hesaplamayı çağırmak istediğimiz şeylerin tüm modelleri eşdeğerdir (bu Kilise Turing tezidir). Bu eşzamanlılık için geçerli değildir: farklı süreç hesaplamaları anlamlılıkta küçük farklılıklar gösterir.

Süreç hesabının pratik sonuçları vardır. Çok sayıda hesaplama dağıtılıyor - sunucularla konuşan müşteriler, diğer sunucularla konuşan sunucular vb. ve kullanıcı ile).

Daha iyi bir yazılım oluşturmak için araştırma ilerlemelerine ihtiyaç var mı? Sonuçta, gökyüzünde bir pastadan pi hesaplamasını söyleyemeyen milyar dolarlık bir endüstri var. Sonra tekrar, bu endüstri milyarlarca dolar hata gidermek için harcıyor.

“Hiç ihtiyaç duyulacaklar mı?” Araştırmada asla değerli bir soru değildir. Neyin uzun vadeli sonuçları olacağını önceden tahmin etmek imkansızdır. Daha da ileri gidebilirim ve herhangi bir araştırmanın bir gün sonuçlanmasının güvenli bir varsayım olduğunu söyleyebilirim - o günün gelecek yıl mı yoksa gelecek milenyumda gelip gelmeyeceğini bilmiyoruz.

Pi-matematikte çok fazla varyant görüyorum ve çok fazla aktif araştırma var, ancak bunlara ihtiyaç duyulacak mı veya önemli uygulamalar olacak mı?

Sormamın nedeni, programlama dilleri geliştirmeyi sevmem ve gerçek son hedef, teoriyi aslında bir PL oluşturmak için kullanmak olacaktır. Yazdıklarım için, gerçekten teori ile hiçbir korelasyon yoktu.

Bu aldatıcı bir soru! Size kişisel fikrimi söyleyeceğim ve bunun benim fikrim olduğunu vurguluyorum .

Pi-kalkülüsün eşzamanlı programlama için bir gösterim olarak doğrudan uygun olduğunu düşünmüyorum. Ancak, aynı anda bir programlama dili tasarlamadan önce mutlaka çalışmanız gerektiğini düşünüyorum . Bunun nedeni pi-kalkülüsün düşük bir seviyeye --- ama daha önemlisi kompozisyona sahip olmasıdır! --- eşzamanlılık hesabı. Sonuç olarak, istediğiniz her şeyi ifade edebilir, ancak her zaman uygun değildir.

Bu yorumu açıklamak, türler hakkında biraz düşünmeyi gerektirir. İlk olarak, yararlı programlama dilleri, soyutlamalar oluşturmak için genellikle bir tür tip disipline ihtiyaç duyarlar. Özellikle, yazılım oluştururken prosedürel soyutlamalardan yararlanmak için bir tür fonksiyon tipine ihtiyacınız vardır.

Şimdi, pi-kalkülüsün doğal tip disiplini klasik doğrusal mantığın bir çeşididir. Örneğin bkz. Abramsky'nin basit eşzamanlı programları doğrusal mantığın önermelerinin kanıtı olarak nasıl yorumladığınızı gösteren Proses Gerçekleşebilirliği makalesi . (Literatür, pi-matematik programlarının yazılması için oturum türleri üzerinde çok fazla çalışma içermektedir , ancak oturum türleri ve doğrusal tipler çok yakından ilişkilidir.)

$A \multimap B$$A^\bot ⅋ B$

Bu, POV tipi teorisinden iyidir, ancak programlama sırasında gariptir. Bunun nedeni, programcıların yalnızca işlev çağrılarını değil, aynı zamanda çağrı yığınını da yönetmesidir. (Gerçekten de, lambda kalkülüsünün pi kalkülüsüne kodlanması tipik olarak CPS dönüşümleri gibi görünmektedir.) Şimdi, yazmak asla bunu batırmamalarını sağlar, ancak yine de programcıya çok fazla defter tutma yapılır.

Bu, eşzamanlılık teorisine özgü bir sorun değildir --- mu-hesabı call / cc gibi sıralı kontrol operatörlerinin iyi bir kanıt-teorik hesabını verir, ancak yığının açık hale getirilmesi pahasına, bu onu garip bir programlama dili yapar.

Bu nedenle, eşzamanlı bir programlama dili tasarlarken, benim düşüncem, dilinizi ham pi-hesabından daha yüksek seviyeli soyutlamalarla tasarlamanız gerektiğidir, ancak bunun mantıklı bir yazılı işlem hesabına temiz bir şekilde tercüme edildiğinden emin olmalısınız. (Bunun yakın zamanda güzel bir örneği Tonhino, Caires ve Pfenning'in Yüksek Dereceli Süreçleri, İşlevleri ve Oturumları: Monadik Bir Bütünleşme .)

" Gerçek son hedef , teoriyi aslında bir PL oluşturmak için kullanmak olacaktır." Öyleyse, muhtemelen başka hedeflerin olduğunu kabul ediyor musunuz?

Benim bakış açımdan, teorinin 1 numaralı amacı, mevcut programlama dilleri ve bunların içinde yazılmış programlar hakkında mantıklı olabilecek anlayış sağlamaktır. Boş zamanlarımda, yıllar önce Lisp'te yazılmış büyük bir yazılım parçası, bir e-posta istemcisi tutuyorum. Hoare mantığı, Ayırma Mantığı, veri soyutlaması, ilişkisel parametriklik ve bağlamsal eşdeğerlik gibi bildiğim tüm PL teorileri günlük işlerde işe yarar. Örneğin, yazılımı yeni bir özellik ile genişletiyorsam, orijinal işlevselliğini korumak zorunda olduğunu biliyorum, bu da yeni bir şey yapacak olsa bile tüm eski bağlamlarda aynı şekilde davranması gerektiği anlamına geliyor. yeni bağlamlar. Bağlamsal denklik hakkında hiçbir şey bilmeseydim, konuyu muhtemelen bu şekilde çerçeveleyemezdim.

Pi-kalkülüs ile ilgili sorunuza gelince, pi-kalkülüs dil tasarımında uygulama bulmak için hala biraz yeni. Pi-calculus'a wikipedia sayfası pi-analizi kullanılarak dil tasarımları olarak söz BPML ve Occam-pi yapar. Ancak selefi CCS'nin sayfalarına ve CSP, kalkülüs ve diğer programlama dilleri gibi diğer birçok programlama dili tasarımında kullanılan diğer işlem hesaplarına da bakabilirsiniz. Pi-hesabın mevcut programlama dilleriyle ilişkisini görmek için Sangiorgi ve Walker kitabının "Nesneler ve pi-kalkülüs" bölümüne de bakabilirsiniz .

Süreç hesabının vahşi doğada pratik uygulamalarını aramayı seviyorum :) (teori hakkında okuma yapmanın yanı sıra).

1. Clojure async kanalları CSP'ye dayanmaktadır: http://clojure.com/blog/2013/06/28/clojure-core-async-channels.html
2. Golang ayrıca CSP'ye dayalı kanallara da sahip (sanırım clojure için bu ilham veren Rich Hickey): http://www.informit.com/articles/printerfriendly/1768317
3. Scala (Abonelik) için ACP tabanlı bir uzantı yapan bir adam var ama bağlantıyı göndermek için yeterli üne sahip değilim ...

vb.