Modern ana programlama dillerinde lambda fonksiyonlarının popülerliğini ne tetikledi?


112

Son birkaç yılda, anonim işlevler (AKA lambda işlevleri) çok popüler bir dil yapısı haline geldi ve hemen hemen her ana / ana programlama dili bunları tanıttı ya da standartın yaklaşmakta olan bir gözden geçirmesinde bunları tanıtmak için planlandı.

Ancak anonim fonksiyonlar Matematik ve Bilgisayar Bilimleri alanında çok eski ve çok iyi bilinen bir kavramdır (bakınız örneğin 1936 civarında matematikçi Alonzo Church tarafından icat ve 1958'den beri Lisp programlama dili tarafından kullanılan vardır burada ).

Öyleyse neden bugünün ana programlama dilleri (çoğu 15 ila 20 yıl önce gelen) lambda işlevlerini en baştan desteklememiş ve daha sonra tanıtmıştır?

Ve son birkaç yıl içinde anonim işlevlerin büyük ölçüde benimsenmesini ne tetikledi? Bu fenomeni başlatan belirli bir olay, yeni gereksinim veya programlama tekniği var mı?

ÖNEMLİ NOT

Bu sorunun odağı, anonim işlevlerin modern, ana yayın (ve dolayısıyla birkaç istisna dışında, işlevsel olmayan) dillerde tanıtılmasıdır . Ayrıca, isimsiz işlevlerin (bloklar) işlevsel bir dil olmayan Smalltalk'te bulunduğunu ve normal adlandırılmış işlevlerin C ve Pascal gibi yordamsal dillerde bile uzun süredir bulunduğunu unutmayın.

Lütfen “işlevsel paradigmanın benimsenmesi ve faydaları” hakkında konuşarak cevaplarınızı aşırı kestirmeyin, çünkü bu sorunun konusu değil.


7
15-20 yıl önce insanlar OO hakkında aynı soruyu soruyorlardı ... yeni bir kavram değildi ama popülerliği patladı.
MattDavey

7
@MattDavey Most kesinlikle aynı fikirde değil, ama onlara "çoğu Smalltalk geliştiricisinin" pek de fazla insan olmadığını hatırlatmak zorunda kalacağım; P
yannis

30
Bence daha ilginç olan soru onların ölümünü tetikleyen şey ! En modern diller zaman Sonuçta, bir zamanlar yaptığımız lambdas sahip sonra Java ve C ++ gibi diller popüler oldu. (Ben tam bir "modern" dil Java demem rağmen. Java en modern kavram geç 60s / erken 70s kadar uzanan Jenerik vardır. Hatta kombinasyonu Java, sunduğu özelliklere, işaretçi güvenlik, bellek güvenliği, tipi güvenlik, GC, statik olarak yazılmış OO, Jeneriklerin hepsi 1985'te Eyfel'de vardı… ve çok daha iyi, IMHO.)
Jörg W Mittag

31
Java 1.0 çıkmadan önce bile, henüz tasarımın ilk aşamalarındayken, hemen hemen herkes Java'nın lambdalara ihtiyaç duyduğuna dikkat çekti. Java üzerinde çalışan tasarımcılardan bazıları Guy Steele (Lisp proponent, Scheme'nin ortak tasarımcısı, Fortress tasarımcısı Common Lisp'in ortak yazarı), James Gosling (PC'ler için ilk Emacs Lisp tercümanı), Gilad Bracha (Smalltalk) Animorphic Smalltalk'in ortak tasarımcısı, Newspeak'in tasarımcısı), Phil Wadler (Haskell'in ortak tasarımcısı), Martin Odersky (Scala'nın tasarımcısı). Java'nın lambdas olmadan nasıl sonuçlandığı gerçekten çok ötesinde.
Jörg W Mittag

8
"Küçük bir bit" genellikle% 50 işlev,% 50 gürültü anlamına gelir.
kevin cl

Yanıtlar:


86

İşlevsel programlamaya veya en azından belirli yönlerine doğru dikkat çekici bir eğilim var. Bir noktada anonim fonksiyonları benimsenen popüler dillerin Bazı C ++ (vardır C ++ 11 ), PHP ( PHP 5.3.0 ), C # ( C # v2.0 (2009 yılından bu yana)), Delphi, Objective C ( blok ) ise Java 8 lambda dilini destekleyecektir . Ve genellikle işlevsel olarak kabul edilmeyen, ancak başlangıçta veya en azından erken dönemlerde, örneğin JavaScript olan anonim işlevleri destekleyen popüler diller vardır.

Tüm trendlerde olduğu gibi, onları başlatan tek bir olayı aramaya çalışmak muhtemelen zaman kaybıdır, genellikle çoğu ölçülemez olan faktörlerin bir birleşimidir. Pratik Common Lisp 2005 yılında yayınlanan bir şekilde Lisp yeni dikkat getiren önemli bir rol oynamış olabilir pratik oldukça zaman Lisp oldu gelince, dil çoğunlukla bir akademik ortamda veya çok spesifik niş pazarlarda tanışmak istiyorum bir dil. JavaScript’in popülerliği, adli fonksiyonlara yeni dikkat getirilmesinde de önemli bir rol oynamış olabilir, çünkü cevabında cevabı açıklanmıştır .

İşlevsel kavramların çok amaçlı dillerden benimsenmesinden başka, işlevsel (veya çoğunlukla işlevsel) dillere doğru gözle görülür bir değişim var. Erlang (1986), Haskell (1990), OCaml (1996), Scala (2003), F # (2005), Clojure (2007) ve hatta R (1993) gibi etki alanına özgü diller gibi dillerin güçlü bir şekilde takip edildiğini görüyoruz. Onlar tanıtıldıktan sonra. Genel eğilim, Scheme (1975) ve açıkça Common Lisp gibi eski fonksiyonel dillere yeni bir dikkat çekti.

Sanıyorum daha önemli olan tek şey, sektörde işlevsel programlamanın benimsenmesi. Bunun neden böyle kullanılmadığı konusunda hiçbir fikrim yok, ama 90'ların başında ve ortalarında bir noktada fonksiyonel programlama endüstrideki yerini bulmaya başladı, (belki de) Erlang'ın çoğalmasıyla başladı. telekomünikasyon ve Haskell'in havacılık ve donanım tasarımında benimsenmesi .

Joel Spolsky çok ilginç bir blog yazısı yazdı: o zaman üniversitelerin Java'yı diğerlerinden daha çok tercih etmesi, belki de dillerini öğrenmesi daha zor olan üniversiteler eğilimine karşı savundu . Blog postasının işlevsel programlama ile ilgisi olmasa da, önemli bir sorunu tespit ediyor:

Tartışma yatıyor. Benim gibi tembel CS öğrencileri tarafından yıllarca sürüp giden, Amerikan üniversitelerinden kaç tane CS ana dalının mezun olduğu, bir kaç para harcadığı ve son on yılda çok fazla sayıda mükemmel okulun% 100 Java'ya gittiği yönündeki şikayetleri ile birlikte. Kalça, özgeçmişlerini değerlendirmek için "grep" i kullanan çalışanlar hoşuna gidiyor gibi görünüyor ve hepsinden önemlisi, Java ile beynin işaretçiler veya özyinelemeyi yapan kısmı olmadan programcıları gerçekten dışlamak için yeterince zor bir şey yok. okulu bırakma oranları daha düşük ve bilgisayar bilimleri bölümlerinin daha fazla öğrencisi ve daha büyük bütçeleri var ve her şey yolunda.

Üniversite yıllarında onunla ilk tanıştığımda Lisp'ten ne kadar nefret ettiğimi hala hatırlıyorum. Kesinlikle sert bir metres ve derhal üretken olabileceğiniz bir dil değil (en azından ben yapamam). Lisp'e kıyasla Haskell (örneğin) çok daha dostça, bu kadar çaba göstermeden ve tam bir salak gibi hissetmeden üretken olabilirsiniz ve bu da işlevsel programlamaya geçişte önemli bir faktör olabilir.

Sonuçta, bu iyi bir şey. Çok amaçlı birçok dil, daha önce kullanıcılarının çoğuna karşı gizli görünebilecek paradigma kavramlarını benimsemektedir ve ana paradigmalar arasındaki boşluk daralmaktadır.

İlgili sorular:

Daha fazla okuma:


Cevabınız için teşekkürler (ve birçok ilginç fikir). +1 Yine de, (sadece) lambdaları bir programlama diline sokmanın, FP için çok küçük bir adım olduğunu ve hatta birçok kişi için kafa karıştırıcı olabileceğini savunuyorum (lambdalar zorunlu bir dilde tek başına ne yapıyor?). Bazı Haskell, Scala ve SML'yi öğrendikten sonra, sadece lambdaları destekleyen zorunlu bir dille gerçek bir FP yapabildiğime dair bir fikrim yok (peki ya körleme ve desen eşleştirmesi, değişmezlik?).
Giorgio


2
@YannisRizos: Perl 5'in (1994) ilk çıkışından bu yana isimsiz bir fonksiyona sahipti, ancak 5.004 (1997) tarihine kadar tamamen "doğru" değildi.
Blrfl

1
@penartur Ben de öyle düşündüm, ama dostça bir editör beni burada işaret ederek düzeltti: msdn.microsoft.com/en-us/library/0yw3tz5k%28v=vs.80%29.aspx
yannis

İşlevsel dillerin popülaritesini artıran ana "olayın" web olduğunu düşünüyorum. Daha spesifik olarak, masaüstü programlarından sunucu tarafına geçiş. Bu, geliştiriciye herhangi bir programlama dilini seçme özgürlüğü verir. 90'lı yıllarda Paul Graham ve Lisp dikkate değer bir örnek.
Gilad Naor

32

İşlevsel programlamanın popülaritesinin Javascript'in büyümesine ve çoğalmasına paralel olmasının ilginç olduğunu düşünüyorum. Javascript, işlevsel programlama yelpazesi boyunca, yaratıldığı sırada (1995) ana programlama dilleri (C ++ / Java) arasında pek popüler olmayan birçok radikal özelliğe sahiptir. Müşterinin tek web programlama dili olarak ana sunucuya aniden enjekte edildi. Birdenbire birçok programcının Javascript'i bilmesi gerekiyordu ve bu nedenle işlevsel programlama dili özellikleri hakkında bir şeyler biliyordunuz.

Javascript'in ani yükselişinde olmasaydı, işlevsel dillerin / özelliklerin ne kadar popüler olacağını merak ediyorum.


5
Javascript kesinlikle önemli bir dildir, ancak Javascript'in tanıtılmasının işlevsel programlamanın popülaritesini kendi başına hesaba kattığından emin değilim: Yannis'in cevabında gösterildiği gibi, son yıllarda birçok başka işlevsel programlama dili de ortaya çıktı. .
Giorgio

8
@Giorgio - birçok başka işlevsel programlama dili olabilir, ancak (nispeten) kimse bunları kullanmaz. JS kullanımı ve daha fazla akademik dil nasıl uygulanmaları gerektiğine karar vermiş olsalar bile, C ++ / Java'nın functor yapma tarzının acı verici ve sinir bozucu olduğu gerçeği, ana akıma itici güçlerdir.
Telastyn

1
Genel olarak dinamik dillerin popülaritesi, Haskell'in popülaritesi için bir açıklama olarak gösteriliyor: book.realworldhaskell.org/read/…
yannis

Ayrıca, sorunun odak noktası genel olarak FP'nin popülerliği değil, genel amaçlı, işlevsel olmayan dillerde anonim işlevlerin geç tanıtılması ile ilgilidir. Büyük halk (çoğu programcı) onları tanımıyor olsa bile, dil tasarımcıları onları çok iyi tanıyordu. Onları başlangıçta dışarıda bırakmak için bir sebep olmalıydı. Belki 90-bağlarının geliştiricileri için sezgisel olmadığı düşünülüyordu.
Giorgio

@giorgio - Java tarzı işlevcilerin aksine uygulamak çok daha zordur. Bunu bilgi / benimseme eksikliği ile birleştirin ve bu oldukça açık bir tasarım tercihi.
Telastyn

27

JavaScript ve DOM olay işleyicileri programcılar milyonlarca anlamına geliyordu vardı yapmak için en az birinci sınıf işlevleri hakkında biraz bilgi için herhangi web üzerinde etkileşim.

Oradan, adsız işlevlere nispeten kısa bir adım . JavaScript kapanmadığından this, kapanışlar hakkında da bilgi edinmenizi kuvvetle tavsiye eder. Ve sonra altınsınız: sözcüksel kapsamları çevreleyen yakın birinci sınıf işlevleri anlıyorsunuz.

Bir kez rahat edersen, kullandığın her dilde istersin.


7
+1 sadece isimsiz fonksiyonlarla ilgili değil. Kapanışlar sadece geçici bir fonksiyon satır içi tanımlamaktan çok daha geniş bir konsepttir.
phkahler

@phkahler: Haklısın, ve bu anlamda, Java'nın zaten bir kapanışları var (ve bir değişmez fonksiyonla ne elde ettiğinizden daha güçlü) ama tek bir yöntemle anonim sınıfın ortak durumu için kısa bir açıklamadan yoksun.
Giorgio,

17

Bu kesinlikle tek faktör değil , ama Ruby'nin popülerliğine dikkat çekeceğim. Bunun zaten tahtadaki altı cevabın herhangi birinden daha önemli olduğunu söylememek, ama bir kerede birçok şeyin olduğunu ve hepsini sıralamanın yararlı olduğunu düşünüyorum.

Ruby, işlevsel bir dil değildir ve ML gibi bir şey kullandığınızda kuzuları, aşamaları ve blokları tıknaz görünmektedir, ancak gerçek şu ki, hiper için Java ve PHP'den kaçan genç nesillerin haritalanması ve düşürülmesi kavramını popüler hale getirmiştir. otlaklar. Birçok dilde Lambda'ların savunmacı hamle gibi göründüğünden daha fazla hareket ettiği görülüyor.

Fakat blok sözdizimi ve .each, .map, .reduce vb. İle bütünleşme biçimi, gerçekten bir korotein gibi davranan sözdizimsel bir yapı olsa bile, isimsiz bir işlev fikrini arttırdı. Ve bir proc ile & proc işlevine kolayca dönüştürülmesi, işlevsel programlama için bir ağ geçidi ilacı haline getirir.

Ruby on Rails'in JavaScript yazan programcıların zaten hafif ve işlevsel bir tarzda şeyler yapmaya açık olduğunu savunuyorum. Programcı bloglamasıyla Reddit, hacker News ve Stack Overflow'un aynı anda etrafta dolaştığını ve fikirlerin İnternet üzerinden Newsgroups günlerinden daha hızlı yayıldığını bir araya getirin.

TL; DR: Ruby, Rails, JavaScript, blog ve Reddit / Hacker News / Yığın Taşması, işlevsel fikirleri toplu pazarlara itti, bu yüzden herkes daha fazla kusurdan kaçınmak için mevcut dillerden istediklerini istedi.


2
+1 İyi bir cevap için ve (eğer yapabilirsem, çünkü sadece bir oyum var) +1, “Birkaç dilde Lambdas savunmacı görünüyor, her şeyden daha çok hareket ediyor gibi görünüyor” diyerek !!) ". Bunun da bir faktör olduğunu düşünüyorum. Bazı diller için lambdalar, bir bütün olarak dile çok az anlamlı güç katsa da, dile bir popülerlik kazandıran, olması gereken güzel bir özelliktir. programcı sayısı anonim fonksiyonlar için desteğin tam) işlevsel programlama destekleyen eşdeğerdir düşünüyor.
Giorgio

2
Son yıllarda çoğu dilin blok sözdizimini uygulamasının nedeni bu olduğunu düşünüyorum. Ancak emin olmanın tek yolu, dil geliştiricilere amaçlarının ne olduğunu sormak. Sadece imoyu tahminde bulunabiliriz.
SpoBo

Benim için, Ruby ilk blokları rock yapan ve çok çekici olan dil , yani +1. Haskell de bir etkisi olmuş olabilir.
rogerdpack

13

Yannis'in belirttiği gibi , daha önce olmayan dillerdeki üst düzey işlevlerin benimsenmesini etkileyen bir dizi faktör var. Sadece hafifçe dokunduğu önemli maddelerden biri çok çekirdekli işlemcilerin çoğalması ve bununla birlikte daha paralel ve eşzamanlı işlem yapma isteğidir.

Harita / filtre / azaltma işlevsel programlama tarzı, paralel bir programlamaya son derece uygundur, bu sayede programcının açık bir iş parçacığı kodu yazmadan çoklu çekirdeklerden kolayca yararlanmasını sağlar.

Giorgio'nun belirttiği gibi, işlevsel programlamanın sadece üst düzey işlevlerden daha fazlası vardır. İşlevler, artı bir harita / filtre / programlama düzenini azaltır ve değişmezlik, işlevsel programlamanın özüdür. Bunlar birlikte paralel ve eşzamanlı programlamanın güçlü araçlarını oluşturur. Neyse ki, birçok dil zaten bazı değişkenlik kavramını desteklemektedir ve programcılar, kitaplıkların ve derleyicinin eşzamanlı olmayan veya paralel işlemler oluşturmalarına ve yönetmelerine olanak tanıyan şeyleri değişmez olarak değerlendirebilirler.

Bir dile yüksek dereceli işlevler eklemek, eşzamanlı programlamayı basitleştirmede önemli bir adımdır.

Güncelleme

Loki'nin belirttiği endişeleri gidermek için daha ayrıntılı örnekler ekleyeceğim.

Bir widget koleksiyonundan geçen ve yeni bir widget fiyatları listesi oluşturan aşağıdaki C # kodunu göz önünde bulundurun.

List<float> widgetPrices;
    float salesTax = RetrieveLocalSalesTax();
foreach( Widget w in widgets ) {
    widgetPrices.Add( CalculateWidgetPrice( w, salesTax ) );
}

Geniş bir widget koleksiyonu veya hesaplama açısından yoğun bir CalculateWidgetPrice (Widget) yöntemi için bu döngü kullanılabilir çekirdeklerden hiçbirini iyi kullanmaz. Farklı çekirdekler üzerinde fiyat hesaplamaları yapmak, programcının açıkça iş parçacığı oluşturmasını ve yönetmesini, etrafta dolaşmasını ve sonuçları toplamasını gerektirir.

C #'ya yüksek dereceli fonksiyonlar eklendiğinde bir çözüm düşünün:

var widgetPrices = widgets.Select( w=> CalculateWidgetPrice( w, salesTax ) );

Foreach döngüsü, uygulama detaylarını gizleyerek Select yöntemine taşındı. Programcıya kalan tek şey, her bir elemana hangi işlevi uygulayacağınızı seçmektir. Bu, Seçim uygulamasının hesaplamaları parselel olarak gerçekleştirmesine ve programlayıcı katılımı olmadan tüm senkronizasyon ve iş parçacığı yönetimi kaygılarını ele almasına izin verir.

Ancak, elbette, Seç bu işi paralel olarak yapmaz. Değişmezliğin geldiği yer burasıdır. Select'in uygulanması, sağlanan işlevin (yukarıdaki CalculateWidgets) yan etkileri olmadığını bilmez. Bu fonksiyon, programın durumunu Seçim ve senkronizasyon görünümünün dışında değiştirerek her şeyi kırabilir. Örneğin, bu durumda salesTax'ın değeri hatalı olarak değiştirilebilir. Saf işlevsel diller değişmezlik sağlar, böylece Select (harita) işlevi hiçbir durumun değişmediğinden emin olabilir.

C #, PLINQ'u Linq'e alternatif olarak sağlayarak gider. Şunun gibi olurdu:

var widgetPrices = widgets.AsParallel().Select(w => CalculateWidgetPrice( w, salesTax) );

Bu, bu çekirdeklerin açık yönetimi olmadan, sisteminizin tüm çekirdeklerini tam olarak kullanır.


Daha fazla paralel ve eşzamanlı işlem yapma isteğine dikkat çekiyorum, dördüncü fıkrada bağladığım "Erlang'ın Tarihi" ACM makalesinde tartışılıyor. Ama bu çok iyi bir nokta ve muhtemelen biraz daha genişlemeliydim. +1 çünkü şimdi yapmak zorunda değilim; P
yannis

Haklısın, yeterince dikkat etmedim. Yorumumu değiştirdim.
Ben

Oh, gerçekten yapmak zorunda değildin, ben şikayet etmedim;)
yannis

4
Yukarıda tarif ettiğiniz hiçbiri lambda gerektirmez. Aynı işlevler, adlandırılmış işlevlerle de kolayca gerçekleştirilir. Burada sadece causeve bir perceived affectaçıklanmadan belgeliyorsun correlation. IMO'nun son satırı, sorunun ne olduğu ile ilgilidir; ama cevap vermedin. Eşzamanlı programlamayı neden kolaylaştırıyor?
Martin York

@Ben: Örneğinizin, anonim işlevler gerektirmeyen, üst düzey işlevlerle ilgili olmasına dikkat edin. Cevabınız ilginç fikirler içeriyor (başka bir soru için) ancak şu anda konu dışı.
Giorgio

9

Buradaki cevapların çoğuyla aynı fikirdeyim, ancak ilginç olan, lambdaları öğrendiğim ve üzerlerine atladığımda, başkalarının bahsettiği nedenlerden biri değildi.

Çoğu durumda, lambda fonksiyonları basitçe kodunuzun okunabilirliğini arttırır. Bir fonksiyon göstergesini (veya işlevi veya temsilci) kabul eden bir yöntemi çağırdığınızda, lambdalardan önce, bu işlevin gövdesini başka bir yerde tanımlamanız gerekiyordu, bu nedenle "foreach" yapınız olduğunda, okuyucunuz farklı bir yere atlamak zorunda kalacaktı. Her öğeyle tam olarak ne yapmayı planladığınızı görmek için kodun bir parçası.

Elemanları işleyen fonksiyonun gövdesi sadece birkaç satır ise, isimsiz bir fonksiyon kullanacağım çünkü şimdi kodu okurken işlevsellik değişmeden kalıyor, fakat okuyucunun ileri geri atlama yapması gerekmiyor. Tam orada onun önünde.

İşlevsel programlama tekniklerinin ve paralelleştirmelerin birçoğu isimsiz işlevler olmadan gerçekleştirilebilir; Sadece normal bir tane ilan ve ihtiyaç duyduğunuzda bir başvuru iletin. Ancak lambda ile kod yazma kolaylığı ve kod okuma kolaylığı büyük ölçüde geliştirilmiştir.


1
Çok iyi açıklama (+1). Lisp programcıları 1958'den beri tüm bunların farkındalar. ;-)
Giorgio

4
@Giorgio: Elbette, ancak lisp programcıları güçlendirilmiş açma / kapama parantez tuşları ile özel klavyeler satın almak zorunda kaldılar :)
DXM

@DXM: klavyeler değil, parantez açma ve kapama için bir tür piyano pedalı gibi ek bir giriş aygıtı
alırlar

@DXM, vartec: Son zamanlarda bazı Şemalar yapıyorum ve parantezleri yolunda buluyorum. Bazı C ++ kodları şifreli olabilir (ve C ++ ile Scheme'den çok daha fazla deneyime sahibim). :-)
Giorgio

9

Buradaki yakın tarihte biraz yer aldığına göre, bir faktörün jeneriklerin Java ve .NET'e eklenmesi olduğuna inanıyorum. Bu, doğal olarak Func < , > ve diğer güçlü şekilde yazılmış hesaplama soyutlamalarına (Görev < >, Async < > vb.) Yol açar .

.NET dünyasında, FP'yi desteklemek için bu özellikleri tam olarak ekledik. İşlevsel programlama ile ilgili basamaklı bir dil çalışması seti, özellikle de C # 3.0, LINQ, Rx ve F #. Bu ilerleme diğer ekosistemleri de etkiledi ve bugün hala C #, F # ve TypeScript'te devam ediyor.

Haskell'in MSR'de de çalışmasına yardımcı oluyor elbette :)

Tabii ki birçok başka etkisi de vardı (JS kesinlikle) ve bu adımlar sırayla diğer birçok şeyden etkilendi - ancak bu dillere jenerikler eklemek, yazılım dünyasının büyük bölümlerinde 90'ların sonundaki katı OO ortodoksisinin kırılmasına yardımcı oldu ve açılmasına yardımcı oldu. FP için kapı.

Don Syme

ps F # 2005’ti, 2005 değil - 2005’e kadar 1.0’a ulaşamadığını söylesek de.


Hoşgeldiniz! 2005'i F # için kullandım, F # 'nın Wikipedia makalesinde ilk kararlı sürümün yılı olarak bildirilen yıl. 2003 olarak değiştirmemi ister misiniz?
yannis


4

Gördüğüm kadarıyla cevapların çoğu, genel olarak işlevsel programlamanın neden geri dönüş yaptığını ve ana yol haline getirdiğini açıklamaya odaklanıyor. Bununla birlikte, özellikle anonim işlevlerle ilgili soruyu gerçekten yanıtlamadığını ve neden aniden bu kadar popüler olduklarını hissettim.

Popülerliği gerçekten kazanmış olan şey, kapanışlar . Çoğu durumda, kapaklar atılan fonksiyonlar değişken olduğundan, bunlar için adsız fonksiyon sözdizimini kullanmak açık bir anlam ifade eder. Ve aslında bazı dillerde kapatma oluşturmanın tek yolu bu.

Kapanışlar neden popülerlik kazanmıştır? Çünkü bunlar geri çağırma işlevleri oluştururken olaya dayalı programlamada kullanışlıdırlar . Şu anda JavaScript istemci kodunu yazma yöntemidir (aslında herhangi bir GUI kodu yazma yöntemidir). Aynı zamanda olay odaklı paradigmada yazılan kod genellikle asenkron ve engelleyici olmadığı için yüksek verimli back-end kodunun yanı sıra sistem kodu da yazmanın yoludur . Arka uç için bu C10K probleminin çözümü olarak popüler hale geldi .


Bu sorunun işlevsel programlama ile ilgili olmadığını vurguladığınız için teşekkür ederiz (+1), çünkü (1) bir argüman olarak iletilen bir kod bloğu fikri, Smalltalk gibi işlevsel olmayan dillerde ve (2) mutasyona uğramış durumda da kullanılır. Bir kapanışın sözcük bağlamından ele geçirilen (birçok lambda uygulamasında mümkün olduğu gibi) kesinlikle işlevsel değildir . Ve evet, kapanışlara sahip olmak, anonim kapanışlara adım kısa. İlginç olan, kapakların uzun süredir iyi biliniyor olması ve seksenli yıllardan beri olaya dayalı programlama (bildiğim kadarıyla) kullanılması.
Giorgio

Ancak belki de son birkaç yıl içinde, kapakların önceden düşünülenden daha sık kullanılabileceği netleşti.
Giorgio

@ Giorgio: evet, şu anda kullanılan kavramların çoğu çok, çok uzun zamandır buralardaydı. Oysa onlar henüz kullanılmamış, şimdi kullanılıyorlar.
vartec

1

Bunun nedeni, nesne yönelimli programlamanın özünün (değişmekte olan durumu nesnelerle kapsıyor) artık uygulanmadığı eşzamanlı ve dağıtılmış programlamanın artan yaygınlığı olduğunu düşünüyorum. Dağıtık bir sistem söz konusu olduğunda , paylaşılan bir durum olmadığından (ve bu kavramın yazılım soyutlamaları sızıntı yapıyorsa) ve eşzamanlı bir sistem söz konusu olduğunda, paylaşılan duruma uygun şekilde senkronize edilmenin hantal olduğu ve hataya eğilimli olduğu kanıtlanmıştır. Yani, nesne yönelimli programlamanın temel faydalarından biri artık birçok program için geçerli değildir, nesne yönelimli paradigmasını eskisinden daha az faydalı kılmaktadır.

Buna karşılık, işlevsel paradigma değişken durumu kullanmaz. Bu nedenle, işlevsel paradigmalar ve kalıplarla edindiğimiz herhangi bir deneyim, eşzamanlı ve dağıtılmış hesaplamaya daha hızlı aktarılabilir. Ve tekerleği yeniden icat etmek yerine, endüstri artık bu kalıpları ve dil özelliklerini ihtiyacını karşılamak için ödünç alıyor.


4
Bazı ana akış dillerinde (örneğin C ++ 11) anonim işlevler değişken duruma izin verir (tanımlayıcı ortamdan değişkenleri yakalayabilir ve yürütme sırasında bunları değiştirebilirler). Bu nedenle, genel olarak işlevsel paradigma hakkında ve özel olarak değişmezlik hakkında konuşmanın, sorulanın kapsamı dışında olduğunu düşünüyorum.
Giorgio

Java 8 için bazı özellik notlarını okuduktan sonra, lambda projesinin ana hedeflerinden biri eşzamanlılığı desteklemektir. Ve bu hemen bizi bizi, bu harika java'ların yaşayacağı değişken küme bombasına götürür. Java bir kez lambdalar aldığında (gerçekten sürüm 8'in son sürümünde olduğu varsayılırsa), daha sonra varsayılan olarak değiştirilemeyen sorunu ele almaları gerekir, bir şekilde (dili Lisp'i yok eder, Lisp yan etkisi serbest işlevlerini düşünerek yerine) in COBOL - VERİ BESLEME / KOPYALAMA üzerine vurma)
Roboprog

İyi dedi. Değişken durumdan uzaklaşmak eşzamanlılığı kolaylaştırır ve cascalog ve spark gibi teknolojiler, işlevsel programlamayı bir bilgisayar kümesinde kolayca dağıtır. Nasıl ve neden olarak daha ayrıntılı bilgi için glennengstrand.info/analytics/distributed/functional/… adresine bakın .
Glenn

1

0.02 Avro'umu ekleyebilirsem, JavaScript'i kavramı tanıtmanın önemine katılıyor olsam da, eşzamanlı programlamanın ötesinde asenkron programlamanın şu anki tarzını suçlayacağımı düşünüyorum. Zaman uyumsuz çağrılar yaparken (web sayfalarında gerekli), basit anonim işlevler o kadar faydalıdır ki, her web programcısı (yani, her programcı) bu konsepti çok yakından tanımak zorunda kaldı.


1

İsimsiz fonksiyonlara / lambdalara benzeyen bir başka eski örnek, Algol 60'da isme göre çağrıdır. Ancak isme göre çağrıya geçmenin, makroları gerçek işlevleri geçmekten ziyade parametreler olarak geçirmeye daha yakın olduğunu ve bunun daha kırılgan / daha zor olduğunu unutmayın. sonucu olarak anlamak.


0

İşte bilgimin en iyisi olan soy.

  • 2005: Javascript, en son zamanlarda lambdas ile yüksek dereceli programlamayı tekrar ana akıma getirdi. Özellikle underscore.js ve jquery gibi kütüphaneler . Bu kütüphanelerden ilki, yaklaşık bir yıl önce jquery'yi önleyen prototip.js'dir . Prototip, Ruby'nin Numaralandırılabilir modülüne dayanıyor ve bu bizi…
  • 1996: Ruby'nin Numaralandırılabilir modülü çok açık bir şekilde Smalltalk'ın koleksiyon çerçevesinden ilham aldı. Matz tarafından birçok röportajda da belirtildiği gibi, bizi ...
  • 1980: Smalltalk, birçok yüksek dereceli programlamayı kullanır ve daha yüksek dereceli programlamayı yoğun şekilde kullanan bir koleksiyon API'si sağlar (örneğin, GNU Smalltalk'ın Yinelenebilir sınıfı ). Deyimsel Smalltalk kodunda, döngüler için hiçbirini bulamazsınız, ancak yalnızca yüksek dereceli numaralandırmaları bulamazsınız. Ne yazık ki, 1998 yılında Smalltalk'in koleksiyon çerçevesi Java’ya taşınırken Java, üst sıradaki sayımlar dışlandı. Gelecek on yıl boyunca üst düzey programlamanın ana akımın dışına çıkması işte böyle oldu! Smalltalk'ın birçok ataları var, ancak OP'nin sorusuyla ilgili olan LISP, bizi…
  • 1958: LISP, belli ki, özünde yüksek dereceli bir programlamaya sahip.

Elbette Amiss, tüm ML atalarıdır. ML, SML, OCaml, Haskell, F #. Bu bir şey saymak lazım ..
Muhammad Alkarouri

-1

Anonim işlevler güzeldir çünkü işleri adlandırmak zordur ve bir işlevi yalnızca bir kez kullanırsanız, bir ada ihtiyaç duymaz.

Lambda işlevleri sadece son zamanlarda yaygınlaştı çünkü son zamanlara kadar çoğu dil kapanmayı desteklemedi.

Javascript’in bu ana akımı ittiğini söyleyebilirim. Paralellik ifade etmenin bir yolu olmayan evrensel bir dildir ve adsız işlevler geri arama modellerinin kullanımını kolaylaştırır. Ek olarak, Ruby ve Haskell gibi popüler diller katkıda bulunmuştur.


1
“Lambda işlevleri daha yeni ana akım oldu, çünkü yakın zamana kadar çoğu dil kapanmayı desteklemedi.”: Bu akıl yürütme bana biraz dairesel geliyor: ana akım olmak çoğu dilin desteklediği anlamına geliyor. Biri derhal “Modern programlama dillerinde kapakların popülerliğini ne tetikledi?” Diye sorabilirdi.
Giorgio

Python'un lambdaların en iyi uygulamalarına sahip olmadığını biliyorum. Ancak popülerlik açısından, muhtemelen Haskell'den daha fazla katkıda bulunmuştur.
Muhammad Alkarouri,
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.