Scala 2.8 koleksiyon kütüphanesi “tarihteki en uzun intihar notu” mudur? [kapalı]

Yakın zamanda çıkacak olan 2.8 sürümüyle birlikte gelen Scala koleksiyonları kütüphanesinin yeniden uygulanmasına bakmaya başladım . Kütüphaneden 2.7'ye aşina olanlar, kullanım açısından bakıldığında kütüphanenin çok az değiştiğini fark edeceklerdir. Örneğin...

> List("Paris", "London").map(_.length)
res0: List[Int] List(5, 6)

... her iki versiyonda da çalışır. Kütüphane son derece kullanışlı : Aslında harika. Bununla birlikte, daha önce Scala'ya aşina olmayan ve dil hakkında bir fikir edinmek için etrafta dolaşanların şimdi aşağıdaki yöntem imzalarını anlamaları gerekir:

def map[B, That](f: A => B)(implicit bf: CanBuildFrom[Repr, B, That]): That

Böylesine basit bir işlevsellik için, bu göz korkutucu bir imza ve kendimi anlamakta zorlandığım bir imza. Scala'nın bir sonraki Java (veya / C / C ++ / C #) olduğunu düşünmüyorum - yaratıcılarının bu pazara hedeflediğine inanmıyorum - ama Scala'nın olması kesinlikle mümkün / mümkün Bir sonraki Ruby veya Python (yani önemli bir ticari kullanıcı tabanı kazanmak için)

• Bu insanları Scala'ya gelmesini engelleyecek mi?
• Bu, Scala'ya ticari dünyada sadece kendini adamış doktora öğrencilerinin anlayabileceği akademik bir oyun olarak kötü bir isim verecek mi? Are CTO ler ve yazılım kafaları turisler olacak?
• Kütüphane yeniden tasarlamak mantıklı bir fikir miydi?
• Scala'yı ticari olarak kullanıyorsanız, bundan endişe duyuyor musunuz? Hemen 2.8'i almayı mı planlıyorsunuz yoksa ne olduğunu görmek için mi bekliyorsunuz?

Steve Yegge, bir zamanlar aşırı karmaşık tip sistemi olarak gördüğü için Scala'ya (yanlışlıkla bence) saldırdı . Birisi bu API ile FUD yayılan bir alan gün olacak endişe (Josh Bloch Java kapatmaları ekleyerek JCP nasıl korkuttu gibi ).

Not - Joshua Bloch'un BGGA kapanış teklifinin reddedilmesinde etkili olduğuna inansam da, bunu teklifin bir hatayı temsil ettiği dürüstçe tutulan inançlarından başka bir şeye atlamıyorum.

Eşim ve iş arkadaşlarım bana söylediklerine rağmen, aptal olduğumu düşünmüyorum: Oxford Üniversitesi'nden matematik alanında iyi bir derecem var ve yaklaşık 12 yıldır ticari olarak ve yaklaşık Scala'da programlıyorum bir yıl (ticari olarak da).

İltihaplı konu başlığı, 1980'lerin başında bir İngiltere siyasi partisinin manifestosu hakkında yapılan bir alıntıdır . Bu soru öznel ama gerçek bir soru, bunu CW yaptım ve bu konuda bazı görüşler istiyorum.

Umarım bu bir "intihar notu" değildir, ama görüşünüzü görebiliyorum. Aynı zamanda Scala'nın hem gücü hem de problemi olan şeye çarptınız: genişletilebilirliği . Bu, kütüphanelerde en büyük işlevselliği uygulamamızı sağlar. Diğer bazı dillerde, benzer bir şey içeren mapveya oluşturulacak diziler collectve hiç kimse derleyicinin sorunsuz çalışması için geçmesi gereken tüm çemberleri görmemelidir. Scala'da her şey bir kütüphanede ve bu nedenle açıkta.

Aslında mapbunun karmaşık türü tarafından desteklenen işlevselliği oldukça ileridir. Bunu düşün:

scala> import collection.immutable.BitSet
import collection.immutable.BitSet

scala> val bits = BitSet(1, 2, 3)
bits: scala.collection.immutable.BitSet = BitSet(1, 2, 3)

scala> val shifted = bits map { _ + 1 }
shifted: scala.collection.immutable.BitSet = BitSet(2, 3, 4)

scala> val displayed = bits map { _.toString + "!" }
displayed: scala.collection.immutable.Set[java.lang.String] = Set(1!, 2!, 3!)

Mümkün olan en iyi türü nasıl elde ettiğinizi görün. Eğer Ints'yi s ile Inteşlerseniz BitSet, tekrar a alırsınız , ancak Ints ile Strings arasında eş yaparsanız, bir general alırsınız Set. Haritanın sonucunun hem statik türü hem de çalışma zamanı gösterimi, kendisine iletilen işlevin sonuç türüne bağlıdır. Ve bu, küme boş olsa bile çalışır, bu nedenle işlev asla uygulanmaz! Bildiğim kadarıyla, eşdeğer işlevselliğe sahip başka bir koleksiyon çerçevesi yok. Ancak kullanıcı açısından bakıldığında işlerin böyle çalışması gerekiyordu .

Sahip olduğumuz sorun, bunu gerçekleştiren tüm akıllı teknolojilerin, büyük ve korkutucu hale gelen tür imzalarına sızmasıdır. Ama belki bir kullanıcı varsayılan olarak tam tip imzasını göstermemelidir map? O nasıl bakmaktan yaklaşık mapiçinde BitSetshe got:

map(f: Int => Int): BitSet     (click here for more general type)

Bu durumda dokümanlar yalan söylemez, çünkü kullanıcı açısından gerçekten harita türü vardır (Int => Int) => BitSet. Ancak map, başka bir bağlantıya tıklayarak incelenebilen daha genel bir türü de vardır.

Araçlarımızda henüz böyle bir işlevsellik uygulamadık. Ancak, insanları korkutmaktan kaçınmak ve daha faydalı bilgiler vermek için bunu yapmamız gerektiğine inanıyorum. Bunun gibi araçlarla, umarım akıllı çerçeveler ve kütüphaneler intihar notları olmaz.

Ne doktora ne de CS'de ne matematikte ne de başka bir alanda derecem yok. Scala ve benzeri diller hakkında daha önce hiç deneyimim yok. Uzaktan karşılaştırılabilir tip sistemlerde bile deneyimim yok. Aslında, ben bile bunların sadece yüzeysel bilgiden daha olduğunu tek dil vardır bir tip sistemi tam olarak sofistike tip sistem için bilinmemektedir Pascal vardır. (Bu olsa yapar AFAIK hemen hemen başka hiçbir dil vardır aralığı türleri, var, ama burada gerçekten alakalı değildir.) Biliyorum diğer üç dil bile bir tür sistemine sahip hiçbiri TEMEL, Smalltalk ve Yakut vardır.

Yine de, mapgönderdiğiniz işlevin imzasını anlamakta hiç sorun yaşamıyorum. Bana mapşimdiye kadar gördüğüm diğer dillerdeki imzanın aynısı gibi geliyor . Aradaki fark, bu sürümün daha genel olması. Haskell'den çok C ++ STL'ye benziyor. Özellikle, yalnızca argümanın bulunmasını gerektirerek somut toplama türünden IterableLikeuzaklaşır ve aynı zamanda sadece sonuç değerlerinin koleksiyonundan bir şeyler oluşturabilen örtük bir dönüştürme fonksiyonunun mevcut olmasını gerektirerek somut geri dönüş türünden uzaklaşır . Evet, bu oldukça karmaşık, ama gerçekten sadece genel programlama genel paradigmasının bir ifadesidir: aslında yapmak zorunda olmadığınız hiçbir şeyi varsaymayın.

Bu durumda, mapgerçekte olmayan ihtiyaç listesi gibi toplama, ya da böyle bir sıralanabilir ya da bir şey olmak sipariş veya varlık. mapİlgilenen tek şey , koleksiyonun tüm öğelerine birbiri ardına, ancak belirli bir sırayla erişememesidir. Ve ortaya çıkan koleksiyonun ne olduğunu bilmesine gerek yok, sadece nasıl yapılacağını bilmek gerekiyor. Yani, tip imzasının gerektirdiği şey budur.

Yani, yerine

map :: (a → b) → [a] → [b]

geleneksel tip imzasıdır map, somut Listdeğil, sadece bir IterableLikeveri yapısı gerektirir.

map :: (IterableLike i, IterableLike j) ⇒ (a → b) → i → j

daha sonra, yalnızca sonucu kullanıcının istediği veri yapısına dönüştürebilen bir işlev olmasını gerektirerek daha da genelleştirilir :

map :: IterableLike i ⇒ (a → b) → i → ([b] → c) → c

Sözdiziminin biraz daha karmaşık olduğunu itiraf ediyorum, ancak anlambilim aynı. Temel olarak,

def map[B](f: (A) ⇒ B): List[B]

geleneksel imzasıdır map. (Scala'nın nesne yönelimli doğası nedeniyle, giriş listesi parametresinin nasıl kaybolduğuna dikkat edin, çünkü şimdi tek bir dağıtım OO sistemindeki her yöntemin sahip olduğu örtük alıcı parametresidir.) Daha sonra bir betondan Listdaha genel birIterableLike

def map[B](f: (A) ⇒ B): IterableLike[B]

Şimdi, IterableLikesonuç koleksiyonunu , hemen hemen her şeyi üreten bir işlevle değiştirir .

def map[B, That](f: A ⇒ B)(implicit bf: CanBuildFrom[Repr, B, That]): That

Gerçekten inandığım o kadar da zor değil . Gerçekten ihtiyacınız olan sadece birkaç entelektüel araç var:

1. Ne olduğunu (kabaca) bilmeniz gerekir map. Metodun adı olmadan sadece tip imzası verdiyseniz , kabul ediyorum, neler olup bittiğini anlamak çok daha zor olurdu. Ama zaten bu yana biliyorum neyi maphızlı, anomaliler üzerinde imza ve odak tarayabilir, yapmak gerekiyordu ve onun tür imzası olması gerekiyordu biliyorum gibi "neden bunu yapar mapargümanlar olarak iki işlev, değil birini almak?"
2. Tip imzasını gerçekten okuyabilmeniz gerekir. Ama daha önce Scala'yı hiç görmemiş olsanız bile, bu oldukça kolay olmalı, çünkü gerçekten sadece diğer dillerden bildiğiniz tip sözdizimlerinin bir karışımı: VB.NET parametrik polimorfizm için köşeli parantez kullanıyor ve dönüş türü ve adı ve türü ayırmak için iki nokta üst üste, aslında norm.
3. Kabaca genel programlamanın ne hakkında olduğunu bilmeniz gerekir. (Anlaşılması o kadar da zor değil , çünkü temelde her şey adında belirtildi: kelimenin tam anlamıyla sadece genel bir şekilde programlama).

Bu üçünün hiçbiri profesyonel veya hobi programcılarına ciddi bir baş ağrısı vermemelidir. mapson 50 yılda tasarlanan her dilde standart bir işlev olmuştur, farklı dillerin farklı sözdizimine sahip olması, HTML ve CSS içeren bir web sitesi tasarlayan herkes için açık olmalıdır ve hatta uzaktan programlamaya abone olamamanız gerekir. Stepanov kilisesinden bazı can sıkıcı C ++ fanboy olmadan genel programlama erdemlerini açıklayan ilgili posta listesi.

Evet, Scala olduğunu kompleksi. Evet, Scala, Haskell, Miranda, Clean veya Cyclone gibi dillere rakip ve hatta aşan, bilinen en karmaşık tip sistemlerden birine sahiptir. Ancak karmaşıklık bir programlama dilinin başarısına karşı bir argüman olsaydı, C ++ çok önce ölecekti ve hepimiz Şema yazıyorduk. Scala'nın muhtemelen başarılı olamamasının birçok nedeni var, ancak programcıların klavyenin önünde oturmadan önce beyinlerini açmaktan rahatsız olmamaları büyük olasılıkla ana olan olmayacak.

C ++ 'da aynı şey :

template <template <class, class> class C,
          class T,
          class A,
          class T_return,
          class T_arg
              >
C<T_return, typename A::rebind<T_return>::other>
map(C<T, A> &c,T_return(*func)(T_arg) )
{
    C<T_return, typename A::rebind<T_return>::other> res;
    for ( C<T,A>::iterator it=c.begin() ; it != c.end(); it++ ){
        res.push_back(func(*it));
    }
    return res;
}

Acınızı anlayabiliyorum, ama, açıkçası, sizin ve benim gibi insanlar - ya da neredeyse herhangi bir Yığın Taşması kullanıcısı - kural değil.

Demek istediğim şu ki ... çoğu programcı bu tip imzayı umursamıyor, çünkü onları asla görmeyecekler ! Belgeleri okumuyorlar.

Kodun nasıl çalıştığına dair bir örnek gördükleri ve kod bekledikleri sonucu üretmede başarısız olmadıkları sürece, belgelere hiç bakmazlar. Bu başarısız olduğunda, belgelere bakarlar ve üstte kullanım örneklerini görmeyi beklerler .

Bunları göz önünde bulundurarak şunu düşünüyorum:

1. Bu tip imzayla karşılaşan herkes (çoğu insan gibi), ona karşı önceden atılmışlarsa Scala'yı alay edecek ve Scala'yı seviyorlarsa Scala'nın gücünün sembolü olarak kabul edecek.

2. Belgeler, kullanım örnekleri sağlamak ve bir yöntemin ne için olduğunu ve nasıl kullanılacağını net bir şekilde açıklamak için geliştirilmezse, Scala'nın benimsenmesini biraz düşürebilir.

3. Uzun vadede önemli değil. Scala O olabilir o Scala çok daha güçlü ve kullanımı daha güvenli için yazılmış kütüphaneler yapacak gibi şeyler. Bu kütüphaneler ve çerçeveler güçlü araçlara bağlanmış programcıları çekecektir.

4. Basitlik ve doğrudanlıktan hoşlanan programcılar PHP veya benzeri dilleri kullanmaya devam edecekler.

Ne yazık ki, Java programcıları güç araçlarına çok fazla girdi, bu yüzden cevaplarken, ana akım Scala benimseme beklentimi gözden geçirdim. Scala'nın ana akım bir dil olacağından hiç şüphem yok. C-ana akım değil, belki de Perl-ana akım veya PHP-ana akım.

Java'dan bahsetmişken, hiç sınıf yükleyiciyi değiştirdiniz mi? Bunun neleri içerdiğine hiç baktınız mı? Çerçeve yazarlarının yaptığı yerlere bakarsanız Java korkutucu olabilir. Çoğu insan bunu yapmaz. Aynı şey Scala, IMHO için de geçerlidir, ancak erken benimseyenlerin karşılaştıkları her kayanın altına bakma, orada saklanan bir şey olup olmadığını görme eğilimi vardır.

Bu insanları Scala'ya gelmesini engelleyecek mi?

Evet, ama aynı zamanda insanların ertelenmesini de önleyecektir. Scala daha yüksek türlere destek kazandığından beri daha yüksek tür türlerini kullanan koleksiyonların eksikliğini büyük bir zayıflık olarak değerlendirdim. API belgelerini daha karmaşık hale getirir, ancak kullanımı daha doğal hale getirir.

Bu, sadece özel doktora öğrencilerinin anlayabileceği akademik bir oyun olarak scala'ya ticari dünyada kötü bir isim verecek mi? CTO'lar ve yazılım başkanları korkacak mı?

Bazıları muhtemelen. Scala'nın bir çok "profesyonel" geliştirici tarafından erişilebilir olduğunu düşünmüyorum, kısmen Scala'nın karmaşıklığından ve kısmen de birçok geliştiricinin öğrenmeye isteksizliğinden dolayı. Bu tür geliştiricileri istihdam eden CTO'lar haklı olarak korkacaktır.

Kütüphane yeniden tasarlamak mantıklı bir fikir miydi?

Kesinlikle. Hala pürüzlü kenarları olsa bile, koleksiyonların dilin geri kalanı ve tür sistemi ile çok daha iyi uymasını sağlar.

Scala'yı ticari olarak kullanıyorsanız, bundan endişe duyuyor musunuz? Hemen 2.8'i almayı mı planlıyorsunuz yoksa ne olduğunu görmek için mi bekliyorsunuz?

Ticari olarak kullanmıyorum. Muhtemelen hataların temizlenebilmesi için tanıtmaya çalışmadan önce 2.8.x serisine en az birkaç devir kadar bekleyeceğim. Ayrıca, EPFL'nin bir sürüm geliştirme sürecini geliştirmede ne kadar başarılı olduğunu görmeyi bekleyeceğim. Gördüğüm şey umutlu görünüyor, ama muhafazakar bir şirkette çalışıyorum.

"Scala ana akım geliştiriciler için çok mu karmaşık?"

Çoğu geliştirici, ana akım veya başka bir şekilde, mevcut sistemleri korur veya genişletir. Bu, kullandıkları şeylerin çoğunun uzun zaman önce alınan kararlarla belirlendiği anlamına gelir. Hala COBOL yazan birçok insan var.

Yarının ana geliştiricisi, bugün inşa edilen uygulamaların bakımı ve genişletilmesi için çalışacaktır. Bu uygulamaların çoğu ana akım geliştiriciler tarafından oluşturulmamaktadır. Yarının ana geliştiricileri, günümüzün en başarılı yeni uygulama geliştiricileri tarafından kullanılan dili kullanacak.

Scala topluluğunun Scala için yeni programcıların korkusunu azaltmaya yardımcı olabilmesinin bir yolu, uygulamaya odaklanmak ve örnek olarak öğretmektir - küçük başlayan ve yavaş yavaş büyüyen birçok örnek. İşte bu yaklaşımı benimseyen birkaç site:

• Günlük Scala
• Küçük ısırıklarda Scala öğrenmek
• Sadece Scala

Bu sitelerde biraz zaman geçirdikten sonra, Scala ve kütüphanelerinin, belki de tasarlanması ve uygulanması zor olsa da, özellikle yaygın durumlarda kullanımı çok zor olmadığını hemen fark eder.

Ucuz bir "kitlesel pazar" ABD üniversitesinden lisans derecem var, bu yüzden kullanıcı zekası (veya en azından eğitim) ölçeğinin içine düştüğümü söyleyebilirim :) Sadece birkaç aydır Scala ile uğraşıyorum ve önemsiz olmayan iki veya üç uygulama üzerinde çalıştı.

Özellikle IntelliJ, IMHO'nun şu anda en iyi Scala eklentisi olan ince IDE'lerini yayınladığında, Scala gelişimi nispeten ağrısızdır:

• Scala'yı "noktalı virgül içermeyen Java" olarak kullanabileceğimi fark ettim, yani Java'da yaptığım şeye benzer görünümlü bir kod yazıyorum ve tür çıkarımıyla elde edilenler gibi sözdizimsel kısalıktan biraz faydalanıyorum. İstisna işleme, bunu yaptığımda daha uygun. Sınıf tanımı, alıcı / ayarlayıcı kazan plakası olmadan çok daha az ayrıntılıdır.

• Arada sırada, Java'nın birden çok satırının eşdeğerini gerçekleştirmek için tek bir satır yazmayı başardım. Uygulanabilir olduğunda, harita, katlama, toplama, filtre vb. Gibi fonksiyonel yöntem zincirleri oluşturmak eğlencelidir ve görülmesi zariftir.

• Kendimi Scala'nın daha yüksek güçlü özelliklerinden yararlandığımı nadiren görüyorum: Kapaklar ve kısmi (veya curried) fonksiyonlar, desen eşleme ... bu tür bir şey.

Bir acemi olarak, kısa ve deyimsel sözdizimi ile mücadele etmeye devam ediyorum. Parametresiz yöntem çağrıları, yaptıkları yerler dışında parantez gerektirmez; maç ifadesindeki vakaların şişman bir ok ( =>) olması gerekir, ancak ince bir ok ( ->) gerektiren yerler de vardır . Birçok yöntem kısa ama oldukça şifreli isimler /:veya gibi \:- - Ben yeterli manuel sayfalar çevirirseniz işimi halledebilirim, ancak kodumun bazıları Perl veya hat gürültüsü gibi görünüyor. İronik olarak, sözdizimsel stenografın en popüler parçalarından biri eylemde eksik: IntBir ++yöntemi tanımlamayan gerçeği ile ısırılmaya devam ediyorum .

Bu sadece benim görüşüm: Scala, C ++ 'ın karmaşıklığı ve okunabilirliği ile birlikte C ++ gücüne sahip gibi hissediyorum. Dilin sözdizimsel karmaşıklığı, API belgelerinin okunmasını da zorlaştırır.

Scala pek çok açıdan çok iyi düşünülmüş ve parlaktır. Bir akademisyenin programlamaktan hoşlanacağından şüpheleniyorum. Bununla birlikte, aynı zamanda akıllılık ve gotchas ile doludur, Java'dan çok daha yüksek bir öğrenme eğrisine sahiptir ve okunması daha zordur. Eğer forumları tarayabilir ve Java'nın daha ince noktalarıyla hala kaç geliştiricinin mücadele ettiğini görürsem , Scala'nın ana akım bir dil olduğunu düşünemiyorum . Hiçbir şirket, daha önce sadece 1 haftalık bir Java kursuna ihtiyaç duyduklarında geliştiricilerini 3 haftalık Scala kursuna göndermeyi haklı çıkaramaz.

Bence bu yöntemle ilgili temel sorun, (implicit bf : CanBuildFrom[Repr, B, That])hiçbir açıklama yapmadan gider. Ne kadar örtük argüman olduğunu bilsem de, bunun çağrıyı nasıl etkilediğini gösteren hiçbir şey yok. Skalladok boyunca takip etmek beni sadece daha karışık hissettiriyor ( CanBuildFromhatta belgelere sahip sınıfların birkaçı ).

Bence basit bir " dönüş türü içine bir bfnesne için bir oluşturucu sağlayan kapsamı örtük bir nesne olmalı " biraz yardımcı olacağını düşünüyorum, ama gerçekten yapmak istediğiniz tek şey harita 's 's. Aslında, bunun doğru olduğundan emin değilim, çünkü türün ne anlama geldiğini bilmiyorum ve dokümantasyon kesinlikle hiçbir ipucu vermiyor .BThatABReprTraversable

Bu yüzden, ikisi de hoş olmayan iki seçenekle kaldım:

• Eski haritanın nasıl çalıştığını ve haritanın diğer dillerde nasıl çalıştığını varsayalım
• Kaynak kodunu biraz daha araştırın

Scala'nın aslında bu şeylerin nasıl çalıştığına dair cesaretlerini ortaya çıkardığını ve sonuçta bunun oxbow_lakes'in tanımladığı şeyi yapmanın bir yolunu sağladığını anlıyorum. Ama imzada dikkat dağıtıcı.

Ben bir Scala acemisiyim ve dürüst olmak gerekirse bu tip imzayla ilgili bir sorun görmüyorum. Parametre, eşlenecek işlevdir ve oluşturucunun doğru koleksiyonu döndürmesi için örtük parametredir. Açık ve okunabilir.

Aslında her şey oldukça zarif. Oluşturucu türü parametreleri derleyicinin doğru dönüş tipini seçmesine izin verirken örtük parametre mekanizması bu ekstra parametreyi sınıf kullanıcısından gizler. Bunu denedim:

Map(1 -> "a", 2 -> "b").map((t) => (t._2) -> (t._1)) // returns Map("a" -> 1, "b" -> 2)
Map(1 -> "a", 2 -> "b").map((t) =>  t._2)            // returns List("a", "b")

Bu doğru yapılmış polimorfizm.

Şimdi, bu ana akım bir paradigma değil ve birçok insanı korkutuyor. Ancak, ifade ve zarafetine değer veren birçok kişiyi de çekecektir.

Maalesef verdiğiniz haritanın imzası, harita için yanlıştır ve gerçekten meşru bir eleştiri vardır.

İlk eleştiri, haritanın imzasını alt üst ederek daha genel bir şeye sahip olduğumuzdur. Bunun varsayılan olarak bir erdem olduğuna inanmak yaygın bir hatadır. Öyle değil. Harita işlevi, iki bileşim ve kimlik yasasına bağlı olarak kovaryant fonksiyon Fx -> (x -> y) -> Fy olarak çok iyi tanımlanmıştır. "Harita" ile ilişkilendirilen herhangi bir şey bir travestidir.

Verilen imza başka bir şeydir, ancak harita değildir. Olmaya çalıştığından şüphelendiğim şey, makaleden "çapraz" imzanın özel ve biraz değiştirilmiş bir versiyonu, Yineleyici Desenin Özü. İşte imzası:

traverse :: (Traversable t, Applicative f) => (a -> f b) -> t a -> f (t b)

Scala'ya çevireceğim:

def traverse[A, B](f: A => F[B], a: T[A])(implicit t: Traversable[T], ap: Applicative[F]): F[T[B]

Tabii ki başarısız oluyor - yeterince genel değil! Ayrıca, biraz farklıdır (Kimlik işlevinden geçerek haritayı alabileceğinizi unutmayın). Ancak, eğer kütüphane yazarları iyi belgelenmiş kütüphane genellemelerinden daha fazla haberdar olsaydı (yukarıda belirtilen Etkilerden Uygulamalı Programlama), bu hatayı görmeyeceğimizden şüpheleniyorum.

İkincisi, harita işlevi Scala'da kavrayışta kullanılması nedeniyle özel bir durum. Bu ne yazık ki, daha donanımlı bir kütüphane tasarımcısı, anlamaların sözdizimsel şekerinden ödün vermeden bu hatayı görmezden gelemeyeceği anlamına gelir. Başka bir deyişle, Scala kütüphane tasarımcıları bir yöntemi yok edeceklerse, bu kolayca göz ardı edilir, ancak lütfen harita oluşturmayın!

Umarım birisi bu konuda konuşur, çünkü olduğu gibi, görünüşe göre güçlü itirazlarımın olduğu nedenlerle Scala'nın yapmakta ısrar ettiği hataları çözmek zorlaşacaktır. Yani, "ortalama programcıdan sorumsuz itirazların (yani çok zor!)" Çözümü "onlar için kolaylaştırmak için onları yatıştırmak" değil, bunun yerine daha iyi programcılar olmak için işaretçiler ve yardım sağlamaktır. Ben ve Scala'nın hedefleri bu konuda tartışmaya açık, ama sizin açınızdan.

Muhtemelen, "ortalama programcı" dan belirli yanıtları tahmin ederek noktaya değiniyordunuz. Yani, "ama bu çok karmaşık!" veya bazıları. Bunlar, bahsettiğiniz Yegges veya Bloch'lardır. Bu entelektüelizm / pragmatizm hareketinin bu insanlarına cevabım oldukça sert ve zaten bir cevap barajı bekliyorum, bu yüzden onu atlayacağım.

Umarım Scala kütüphaneleri iyileşir, ya da en azından hatalar bir köşede güvenle saklanabilir. Java, "yararlı bir şey yapmaya çalışmanın" inanılmaz derecede maliyetli olduğu, genellikle buna değmediği, çünkü ezici hata sayısının önlenemeyeceği bir dildir. Scala'ya aynı yoldan gitmemesi için yalvarıyorum.

Hem soruya hem de Martin'in cevabına tamamen katılıyorum :). Java'da bile, javadoc'u jeneriklerle okumak, ekstra gürültü nedeniyle olması gerekenden çok daha zordur. Bu, örnek örnek kodunda olduğu gibi örtük parametrelerin kullanıldığı Scala'da birleştirilir (bunun etkileri çok faydalı toplama dönüştürme işleri yapar).

Kendi başına bir sorun olduğunu düşünmüyorum - bence daha çok bir araç sorunu. Ve Jörg W Mittag'ın söylediklerine katılıyorum, sanırım scaladoc'a (veya IDE'nizdeki bir türün dokümantasyonuna) bakıyorum - bir yöntemin ne olduğunu, ne aldığını ve geri döndüğünü anlamak için mümkün olduğunca az beyin gücü gerektirmelidir. Bunu elde etmek için biraz kağıt üzerinde biraz cebir kesmeye gerek olmamalı :)

Herhalde IDE'lerin herhangi bir değişken / ifade / tip için tüm yöntemleri göstermenin güzel bir yoluna ihtiyacı vardır (Martin örneğinde olduğu gibi tüm jenerikler inline edilmiş olabilir, bu yüzden güzel ve kolay bir şekilde çizilebilir). Martin'in etkilerini varsayılan olarak gizleme fikrini seviyorum.

Skalladoc'ta örnek almak için ...

def map[B, That](f: A => B)(implicit bf: CanBuildFrom[Repr, B, That]): That

Buna scaladoc'da bakarken, genel bloğun [B, That] varsayılan olarak ve örtük parametrenin (belki de fare ile küçük bir simgenin üzerine gelip gelmediğini gösterirler) gizlenmesini istiyorum - grok için ekstra şeyler olarak genellikle o kadar da önemli olmayan onu okumak. örneğin bunun nasıl göründüğünü hayal edin ...

def map(f: A => B): That

güzel ve net ve ne yaptığı belli. 'O'nun ne olduğunu merak edebilirsiniz, fareyi üzerine getirirseniz veya tıklarsanız, örneğin' O'yu vurgulayan [B, O] metnini genişletebilir.

Belki [] bildirimi ve (örtük ...) blok için küçük bir simge kullanılabilir, bu yüzden ifadenin daraltılmış küçük parçaları olduğu açıktır? Bunun için bir jeton kullanmak zor, ama ben a kullanacağım. şimdilik...

def map.(f: A => B).: That

Bu nedenle, varsayılan olarak, yazı sisteminin 'gürültüsü', milletlerin bakması gereken ana% 80'den gizlidir - yöntem adı, parametre türleri ve geri dönüş tipi, ayrıntılara çok az genişletilebilir bağlantılarla eğer gerçekten bu kadar önemsiyorsan.

Genellikle insanlar bir tipte hangi yöntemleri arayabileceklerini ve hangi parametreleri geçebileceklerini öğrenmek için scaladoc okuyorlar. IMHO'nun nasıl olduğu hakkında çok fazla ayrıntıya sahip kullanıcıları aşırı yüklüyoruz.

İşte başka bir örnek ...

def orElse[A1 <: A, B1 >: B](that: PartialFunction[A1, B1]): PartialFunction[A1, B1]

Eğer jenerik bildirimi saklarsak, okuması daha kolay

def orElse(that: PartialFunction[A1, B1]): PartialFunction[A1, B1]

Daha sonra insanlar üzerinde dururlarsa, diyelim ki A1, A1'in A1 <: A olduğunu beyan edebiliriz.

Bunu nasıl kıracağımı bilmiyorum, ama Cambridge'den bir doktora sahibim ve 2.8'i gayet iyi kullanıyorum.

Daha da ciddisi, 2.7 ile neredeyse hiç zaman harcamadım (kullandığım bir Java kütüphanesiyle birlikte çalışmayacak) ve Scala'yı bir aydan fazla bir süre önce kullanmaya başladım. Haskell (fazla değil) ile biraz deneyimim var, ama sadece endişelendiğiniz şeyleri görmezden geldim ve Java ile deneyimimi eşleştiren yöntemleri aradım (ki yaşamak için kullanıyorum).

Yani: Ben "yeni bir kullanıcıyım" ve ertelenmedim - Java gibi çalıştığı gerçeği, anlamadığım bitleri görmezden gelmem için bana yeterince güven verdi.

(Ancak, Scala'ya bakmamın nedeni kısmen işyerinde zorlayıp zorlayamayacağımı görmekti ve henüz yapmayacağım. Belgeleri daha az korkutucu yapmak kesinlikle yardımcı olacaktır, ancak beni şaşırtan şey hala ne kadar Değişen ve gelişmekte olan (beni en çok şaşırtan şey adil olmak ne kadar harikaydı, ama değişiklikler bir saniye sonra geldi) Sanırım söylediğim şey, sınırlı kaynakların içine girmeyi tercih etmem Son bir devlet - yakında bu kadar popüler olmayı beklediklerini sanmıyorum.)

Scala'yı hiç bilmiyorum, ancak birkaç hafta önce Clojure'u okuyamadım. Şimdi çoğunu okuyabiliyorum, ancak henüz en basit örneklerin ötesinde bir şey yazamıyorum . Sanırım Scala farklı değil. Nasıl öğrendiğinize bağlı olarak iyi bir kitaba veya kursa ihtiyacınız var. Sadece yukarıdaki harita bildirimini okudum, belki de 1/3 tanesini aldım .

Daha büyük sorunların bu dillerin sözdizimi değil, onları günlük üretim kodunda kullanılabilir hale getiren paradigmaları benimsemeleri ve içselleştirmeleri olduğuna inanıyorum . Benim için Java vb Pascal gelen hiç bir sıçrama değildi C, ne de Basic çok büyük bir sıçrama değildi C ++, çok büyük bir sıçrama değildi ... Ama Clojure gibi işlevsel bir dilde kodlama olduğu (için büyük bir sıçrama Bana herhangi bir şekilde). Sanırım Scala'da Java veya Scala tarzında kod yazabilirsiniz. Ancak Clojure'da zorunlu alışkanlıklarınızı Java'dan korumaya çalışarak oldukça karışıklık yaratacaksınız.

Scala, çok karmaşık ve akademik görünen, ancak işleri kolaylaştırmak için tasarlanmış birçok çılgın özelliğe sahiptir (özellikle örtük parametreler söz konusu olduğunda). En yararlı olanlar sözdizimsel şeker ( [A <% B]A tipi bir nesnenin B tipi bir nesneye örtük bir dönüşümü olduğu anlamına gelir) ve yaptıklarının iyi belgelenmiş bir açıklamasıdır. Ancak çoğu zaman, bu kütüphanelerin bir müşterisi olarak, örtük parametreleri göz ardı edebilir ve doğru şeyi yapmalarına güvenebilirsiniz.

Bu insanları Scala'ya gelmesini engelleyecek mi?

Scala'nın ne kadar popüler olacağını etkileyecek ana faktör olduğunu düşünmüyorum, çünkü Scala'nın çok fazla gücü var ve sözdizimi Haskell, OCaml, SML, Lisps gibi bir Java / C ++ / PHP programcısına yabancı değil. vb..

Ama sanırım Scala'nın popülaritesi, Java'nın bugün olduğu yerden daha az yayılmış olacak, çünkü bir sonraki ana akım dilinin çok basitleştirilmiş olması gerektiğini düşünüyorum ve oraya ulaşmanın tek yolu saf değişmezlik, yani HTML gibi açıklayıcı, ancak Turing tamamlandı . Ancak, böyle bir dil geliştirdiğim için önyargılıyım, ancak bunu ancak birkaç aylık bir çalışmadan sonra Scala'nın ihtiyacım olan şey için yeterli olamayacağını belirledikten sonra yaptım.

Bu, Scala'ya sadece özel doktora öğrencilerinin anlayabileceği akademik bir oyun olarak ticari dünyada kötü bir isim verecek mi? CTO'lar ve yazılım başkanları korkacak mı?

Scala'nın itibarının Haskell kompleksinden muzdarip olacağını sanmıyorum. Ancak bazılarının bunu öğrenmeyi bırakacağını düşünüyorum, çünkü çoğu programcı için onları Scala'yı kullanmaya zorlayan bir kullanım durumu görmüyorum ve bu konuda öğrenmeyi erteleyecekler. Belki de son derece ölçeklenebilir sunucu tarafı en cazip kullanım durumudur.

Ve anaakım pazar için, ilk olarak Scala'yı öğrenmek, birisinin hemen HTML veya Python kullanmak gibi programları yazdığı bir "temiz nefes" değildir. Scala, başından beri tökezlediği tüm ayrıntıları öğrendikten sonra, sizin üzerinizde büyüme eğilimindedir. Bununla birlikte, belki de Scala'da Programlama'yı en başından beri okumuş olsaydım, öğrenme eğrisi hakkındaki deneyimim ve düşüncem farklı olurdu.

Kütüphane yeniden tasarlamak mantıklı bir fikir miydi?

Kesinlikle.

Scala'yı ticari olarak kullanıyorsanız, bundan endişe duyuyor musunuz? Hemen 2.8'i almayı mı planlıyorsunuz yoksa ne olduğunu görmek için mi bekliyorsunuz?

Scala'yı yeni dilimin ilk platformu olarak kullanıyorum. Ticari olarak başka türlü Scala kullanıyor olsaydım muhtemelen Scala'nın koleksiyon kütüphanesinde kod oluşturmazdım. Kendi kategori teorisi temelli kütüphanemi yaratırdım, baktığımdan beri Scalaz'ın tip imzalarını Scala'nın koleksiyon kütüphanesinden daha ayrıntılı ve kullanışsız buldum. Bu sorunun bir kısmı belki de Scala'nın tip dersleri uygulama şeklidir ve bu benim kendi dilimi yaratmamın küçük bir sebebidir.

Bu cevabı yazmaya karar verdim, çünkü kendimi Scala'nın koleksiyon sınıfı tasarımını kendi dilim için yaptığım ile araştırmaya ve karşılaştırmaya zorlamak istedim. Düşünce sürecimi de paylaşabilir.

2.8 Scala koleksiyonunun bir yapımcı soyutlamasının kullanımı sağlam bir tasarım prensibidir. Aşağıda iki tasarım dengesini keşfetmek istiyorum.

1. YALNIZCA YAZIN KODU: Bu bölümü yazdıktan sonra, Carl Smotricz'in dengesiz olmasını beklediğim şeye katıldığı yorumu okudum . James Strachan ve davetron5000'in yorumları, O'nun (hatta O [B] değil) anlamının ve örtük mekanizmanın sezgisel olarak kavranmasının kolay olmadığı konusunda hemfikirdir. Aşağıdaki # 2 numaralı monoid kullanımımı çok daha açık olduğunu düşünüyorum. Derek Mahar'ın yorumu Scala yazmakla ilgili, ama başkalarının Scala'sını okumaya ne dersiniz?

   Scala hakkında okuduğum bir eleştiri, onu yazmanın, başkalarının yazdığı kodu okumaktan daha kolay olduğudur. Ve bunu çeşitli nedenlerle (örneğin, bir işlev yazmanın birçok yolu, otomatik kapanmalar, DSL'ler için Ünite vb.) Bazen doğru buluyorum, ancak bu önemli bir faktörse kararsızım. Burada örtük fonksiyon parametrelerinin kullanımının artıları ve eksileri vardır. Artı tarafta, ayrıntı düzeyini azaltır ve oluşturucu nesnesinin seçimini otomatikleştirir. Odersky'nin örneğindebir BitSet'ten, yani Set [Int] 'den bir Set [String]' e dönüşüm örtüktür. Mevcut paket kapsamında mevcut olabilecek tüm görünmez örtük oluşturucu adayları hakkında iyi bir mantık göstermedikçe, kodun bilinmeyen okuyucusu koleksiyon türünün ne olduğunu kolayca bilemeyebilir. Tabii ki, deneyimli programcı ve kod yazarı BitSet'in Int ile sınırlı olduğunu bilecektir, bu nedenle String'e bir harita farklı bir toplama türüne dönüştürülmelidir. Ama hangi koleksiyon türü? Açıkça belirtilmemiştir.

2. AD-HOC KOLEKSİYON TASARIMI: Bu bölümü yazdıktan sonra Tony Morris'in yorumunu okudum ve neredeyse aynı noktayı yaptığımı fark ettim. Belki de daha ayrıntılı sergim bu noktayı daha açık hale getirecektir.

   "Bit Rotlarıyla Türlerle Mücadele" Odersky & Moors'ta iki kullanım durumu sunulmaktadır. Bunlar, BitSet'in Int öğelerine kısıtlanmasıdır ve demet öğelerini eşleştirmek için Eşlemdir ve genel öğe eşleme işlevi A => B'nin alternatif hedef toplama türleri oluşturabilmesi için sağlanır. Ancak, afaik bu bir kategori teorisi bakış açısından kusurludur. Kategori teorisinde tutarlı olmak ve böylece köşe vakalarından kaçınmak için, bu toplama türleri, her bir morfizmin (A => B), aynı işlev kategorisindeki nesneler arasında eşleşmesi gereken, Liste [A] => Liste [B], BitSet olan işlevlerdir. [A] => BitSet [B]. Örneğin, bir Seçenek, bir Bazı (nesne) ve Yok öğelerinden oluşan bir grup koleksiyonu olarak görüntülenebilen bir işlevcidir. Opsiyonun Yok'u veya List'in Nil'i gibi diğer işlevlere genel bir harita yoktur.

   Burada yapılan bir tasarım seçimi var. Yeni dilimin koleksiyon kitaplığı tasarımında, her şeyi bir functor yapmayı seçtim, yani bir BitSet uygularsam, olmayan bir alanla sunulduğunda bit olmayan bir alan iç gösterimini kullanarak tüm öğe türlerini desteklemesi gerekir. integer type parametresi ve bu işlevsellik zaten Scala'da devralındığı Set'te. Ve tasarımımdaki Harita'nın sadece değerlerini eşlemesi gerekiyor ve (anahtar, değer) çift gruplarını eşlemek için ayrı bir işlevsiz yöntem sağlayabilir. Bir avantaj, her bir işlevin genellikle aynı zamanda uygulanabilir ve belki de bir monad olmasıdır. Böylece eleman tipleri arasındaki tüm fonksiyonlar, örneğin A => B => C => D => ..., kaldırılmış uygulanabilir tipler arasındaki fonksiyonlara otomatik olarak kaldırılır, örneğin Liste [A] => Liste [B] => Liste [ C] => Liste [D] => .... Bir functor'dan başka bir toplama sınıfına eşleme için, bir monoid alan bir harita aşırı yükü sunuyorum, örneğin Nil, None, 0, "", Array (), vb. Yani oluşturucu soyutlama işlevi bir monoid ekleme yöntemidir ve açıkça gerekli bir girdi parametresi olarak sağlanır, böylece görünmez örtük dönüşüm yoktur. (Teğet: bu giriş parametresi, Scala'nın harita tasarımının yapamayacağı boş olmayan monoidlere eklenmesini de sağlar.) Bu tür dönüşümler, bir harita ve aynı yineleme geçişindeki bir katlamadır. Ayrıca, kategori anlamında, her efekt sınıfının çoğunun ikisinin de bulunduğu herhangi bir uygulanabilir olandan tek bir yineleme geçişinde harita + katlama sağlayan "Efektli uygulamalı programlama" McBride & Patterson'ı değiştirebilirim.

   Bu yüzden afaikler, Scala koleksiyonları kategori teorisine dayandırılmadığı anlamında "ad-hoc" ve kategori teorisi, üst düzey anlamsal anlambilimin özüdür. Scala'nın örtük inşaatçıları ilk bakışta bir functor model + monoid oluşturucu + sürülebilir -> uygulanabilir olmaktan ziyade "daha genelleştirilmiş" olsalar da, herhangi bir kategoriyle tutarlı oldukları kanıtlanmamış afaiklerdir ve bu nedenle hangi kurallara uyduklarını bilmiyoruz en genel anlamda ve köşe vakalarına ne verileceği, herhangi bir kategori modeline uymayabilir. Daha fazla değişken eklemenin bir şeyi daha genel hale getirdiği doğru değildir ve bu, kategori teorisinin büyük faydalarından biriydi, daha yüksek seviyeli semantiğe yükselirken genelliği korumak için kurallar sağlamasıdır. Koleksiyon bir kategoridir.

   Bir yerde okudum, kütüphane tasarımı için başka bir gerekçe olarak Odersky olduğunu düşünüyorum, saf fonksiyonel bir tarzda programlama, kuyruk özyinelemesinin kullanılmadığı yerlerde sınırlı özyineleme ve hız maliyetine sahip. Şimdiye kadar karşılaştığım her durumda kuyruk özyineleme yapmakta zorlanmadım.

Ayrıca, aklımda, Scala'nın bazı ödünç verilerinin, örneğin Haskell veya geliştirdiğim dilin aksine, hem değişebilir hem de değişmez bir dil olmaya çalıştığı konusunda eksik bir fikir taşıyorum. Bu, Tony Morris'in kavrayış hakkındaki yorumu ile aynı fikirde. Benim dilimde, döngüler ve değişebilir yapılar yok. Dilim (şimdilik) Scala'nın tepesine oturacak ve çok şey borçlu olacak ve Scala genel tip sistemine ve değişebilirliğe sahip olmasaydı bu mümkün olmazdı. Bu doğru olmayabilir, çünkü Odersky & Moors ("Tiplerle Bit Rotu ile Mücadele"), Scala'nın daha yüksek türlere sahip tek OOP dili olduğunu belirtmek için yanlış olduğunu düşünüyorum, çünkü bu standardı (kendim ve Bob Harper aracılığıyla) doğruladım ML onlara sahiptir. Ayrıca SML'nin tip sistemi aynı derecede esnek olabilir (1980'lerden beri), bu sözdizimi Scala kadar Java'ya (ve C ++ / PHP) çok benzemediğinden kolayca anlaşılamayabilir. Her halükarda, bu Scala'nın bir eleştirisi değil, daha ziyade eksikliklerin eksik bir analizini sunma girişimi, umarım bu soruya alman. Scala ve SML Haskell'in yapamamasından muzdarip değilelmas çoklu kalıtım , bu kritik ve anlıyorum neden Haskell Prelude birçok fonksiyonlar farklı türleri için tekrar edilir.

Burada lisans derecesi belirtmek gerekir: Siyaset Bilimi BA ve Bilgisayar Bilimi B.ed.

Diyeceğim şey şu ki:

Bu insanları Scala'ya gelmesini engelleyecek mi?

Scala zordur, çünkü altında yatan programlama paradigması zordur. Fonksiyonel programlama birçok insanı korkutur. PHP'de kapanış yapmak mümkündür ancak insanlar nadiren yapar. Yani hayır, bu imza değil, gerisi, altta yatan paradigmanın gücüne değer verecek özel bir eğitimleri yoksa, insanları erteleyecektir.

Bu eğitim mevcutsa herkes bunu yapabilir. Geçen yıl SCALA'da bir grup okul çocuğu olan bir satranç bilgisayarı inşa ediyorum! Sorunları vardı ama sonunda iyiydiler.

Scala'yı ticari olarak kullanıyorsanız, bundan endişe duyuyor musunuz? Hemen 2.8'i almayı mı planlıyorsunuz yoksa ne olduğunu görmek için mi bekliyorsunuz?

Endişelenmezdim.

Oxford'dan da matematik diplomam var! Yeni koleksiyonları 'almak' biraz zaman aldı. Ama şimdi çok sevdim. Aslında, 'harita' yazmak beni 2.7'de uyandıran ilk büyük şeylerden biriydi (belki de ilk yaptığımdan beri koleksiyon sınıflarından biri alt sınıftı).

Martin'in yeni 2.8 koleksiyonları hakkındaki makalesini okumak gerçekten çıkarımların kullanımının açıklanmasına yardımcı oldu, ancak evet belgelerin kendisi, temel API'lerin yöntem imzalarında farklı tür çıkarımların rolünü açıklamak için kesinlikle daha iyi bir iş yapmalıdır.

Temel kaygım bu: 2.8 ne zaman piyasaya sürülecek? Hata raporları ne zaman gelmeyi bırakacak? scala ekibi 2.8 ile çiğneyebileceğinden daha fazla ısırdı mı / aynı anda çok fazla değişmeye çalıştı mı?

Gerçekten yeni bir şey eklemeden önce 2.8 sürümünün öncelikli olarak kararlı hale getirilmesini görmek istiyorum ve (kenarlardan izlerken) scala derleyicisinin geliştirme yol haritasının yönetilme yolunda bazı iyileştirmeler yapıp yapamayacağını merak ediyorum.

Kullanım sitesindeki hata iletileri ne olacak?

Ve kullanım durumu ne zaman geldiğinde, mevcut türleri bir DSL'e uyan özel bir türle entegre etmek gerekir. Kişi dernek, öncelik, örtük dönüşümler, örtük parametreler, daha yüksek türler ve belki de varoluşçu türler konusunda iyi eğitilmelidir.

Çoğunlukla basit olduğunu bilmek çok iyi ama mutlaka yeterli değil. En azından yaygın kütüphane tasarlanacaksa, bu şeyleri bilen bir adam olmalıdır.