Czy Biblioteka zbiorów Scala 2.8 to przypadek "najdłuższego listu samobójczego w historii"? [zamknięte]

Nie mam doktoratu, ani żadnego innego stopnia ani z CS, ani z matematyki, ani z żadnej innej dziedziny. Nie mam doświadczenia ze scalą ani z żadnym innym podobnym językiem. Nie mam doświadczenia z nawet zdalnie porównywalnymi systemami typu. W rzeczywistości jedynym językiem, który mam więcej niż tylko powierzchowną wiedzę o którym nawet mA system typów, jest Pascal, nie do końca znany ze swojego wyrafinowanego systemu typów. (Chociaż mA typy zasięgu, które AFAIK dość wiele inny język nie ma, ale to nie jest tak naprawdę istotne tutaj.) Pozostałe trzy języki, które znam to BASIC, Smalltalk i Ruby, z których żaden nie ma nawet systemu typów.

A jednak, nie mam żadnych problemów ze zrozumieniem podpisu map funkcji, którą napisałeś. Wydaje mi się, że to prawie ten sam podpis, który map ma w każdym innym języku, jaki kiedykolwiek widziałem. Różnica polega na tym, że ta wersja jest bardziej ogólna. Wygląda bardziej jak C++ stl niż, powiedzmy, Haskell. W w szczególności, abstrahuje od konkretnego typu zbioru, wymagając tylko, aby argument był IterableLike, a także abstrahuje od konkretnego typu powrotu, wymagając tylko, aby istnieje ukryta funkcja konwersji, która może zbudować coś z tego zbioru wartości wynikowych. Tak, jest to dość złożone, ale tak naprawdę jest to tylko wyraz ogólnego paradygmatu programowania ogólnego: nie zakładaj niczego, czego nie musisz.

W tym case, map w rzeczywistości nie potrzebuje, aby zbiór był listą, porządkowaniem lub sortowaniem, czy czymś takim. Jedyną rzeczą, na której {6]} dba, jest to, że może uzyskać dostęp do wszystkich elementów kolekcji, jeden po drugim, ale w żadnej konkretnej kolejności. I nie musi wiedzieć, czym jest wynikowa kolekcja, musi tylko wiedzieć, jak ją zbudować. Tak więc, to jest to, czego wymaga jego podpis typu.

Więc zamiast

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

Który jest w przeciwieństwie do innych typów, Typ ten nie jest używany w systemach klasycznych, ale w systemach klasycznych.]}

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

, które następnie jest dodatkowo uogólniane przez wymaganie tylko, że istnieje funkcja, która może przekształcić wynik do dowolnej struktury danych, jakiej chce użytkownik:

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

Przyznaję, że składnia jest nieco bardziej skomplikowana, ale semantyka jest taka sama. W zasadzie zaczyna się od

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

Który jest tradycyjnym podpisem map. (Zauważ, jak ze względu na obiektowy charakter Scali, parametr listy wejściowej znika, ponieważ jest to teraz ukryty parametr odbiornika, który ma każda metoda w systemie OO z pojedynczą wysyłką.) Następnie uogólnił się z konkretnego List na bardziej ogólny IterableLike

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

Teraz zastępuje IterableLike zbiór wyników funkcją, która wytwarza , cóż, tak naprawdę prawie wszystko.

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

Co naprawdę wierzę, że nie jest że {24]} trudno zrozumieć. Jest tak naprawdę tylko kilka intelektualnych narzędzi, których potrzebujesz:

1. musisz wiedzieć (z grubsza) co to jest map. Jeśli podasz tylko podpis typu Bez nazwy metody, przyznaję, byłoby o wiele trudniej dowiedzieć się, co się dzieje. Ale ponieważ już wiesz co map ma robić, i wiesz, jaka ma być jego sygnatura typu, możesz szybko zeskanować sygnaturę i skupić się na anomaliach, np. kłótnie, nie jedna?"
2. musisz być w stanie rzeczywiście odczytać podpis typu. Ale nawet jeśli nigdy wcześniej nie widziałeś Scali, powinno to być dość łatwe, ponieważ tak naprawdę jest to tylko mieszanka składni typu, które znasz już z innych języków: VB.NET używa nawiasów kwadratowych do parametrycznego polimorfizmu, a użycie strzałki do oznaczenia typu zwracanego i dwukropka do oddzielenia nazwy i typu jest w rzeczywistości normą.
3. musisz z grubsza wiedzieć, czym jest ogólne programowanie około. (Co nie jest , że trudno zrozumieć, ponieważ w zasadzie wszystko jest napisane w nazwie: to dosłownie tylko programowanie w sposób ogólny).

Żaden z tych trzech nie powinien przyprawiać żadnego profesjonalnego lub nawet hobbystycznego programisty o poważny ból głowy. map jest standardową funkcją w prawie każdym języku zaprojektowanym w ciągu ostatnich 50 lat, fakt, że różne języki mają inną składnię powinien być oczywisty dla każdego, kto zaprojektował stronę internetową z HTML i CSS i nie można subskrybować nawet zdalnie związanej z programowaniem listy mailingowej bez jakiegoś irytującego fanboya C++ z kościoła św.

Tak, Scala jest złożona. Tak, Scala ma jeden z najbardziej wyrafinowanych systemów typu znanych człowiekowi, rywalizujący, a nawet przewyższający języki takie jak Haskell, Miranda, Clean czy Cyclone. Ale gdyby złożoność była argumentem przeciwko sukcesowi języka programowania, C++ umarłoby dawno temu i wszyscy będziemy pisać Schematy. Istnieje wiele powodów, dla których Scala prawdopodobnie nie odniesie sukcesu, ale fakt, że programiści nie mogą zadawać sobie trudu, aby włączyć swoje mózgi przed siedzeniem przed klawiaturą, prawdopodobnie nie będzie głównym.

To samo w C++:

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;
}

Cóż, rozumiem twój ból, ale, szczerze mówiąc, ludzie tacy jak ty i ja -- lub prawie każdy zwykły użytkownik przepełnienia stosu -- nie są regułą.

To co mam na myśli to to... większość programistów nie będzie dbać o ten typ podpisu, ponieważ nigdy ich nie zobaczą ! Nie czytają dokumentacji.

Dopóki zobaczyli jakiś przykład działania kodu, a kod nie zawiedzie ich w tworzeniu wyniku, którego oczekują , nigdy nie spojrzą na dokumentacja. Gdy to się nie powiedzie, spojrzą na dokumentację i spodziewają się zobaczyć przykłady użycia u góry.

Mając na uwadze te rzeczy, myślę, że:

1. Każdy (jak większość ludzi), kto kiedykolwiek natknie się na ten typ podpisu, będzie drwił ze Scali bez końca, jeśli są predysponowani przeciwko niemu, i będzie uważał go za symbol mocy Scali, jeśli lubi Scalę.

2. Jeśli dokumentacja nie jest rozszerzona, aby dostarczyć przykłady użycia i wyjaśnić oczywiście, do czego służy metoda i jak jej używać, może ona nieco zniechęcić do adopcji Scali.

3. Na dłuższą metę to bez znaczenia. To, że Scala potrafi robić takie rzeczy, sprawi, że biblioteki napisane dla Scali będą o wiele wydajniejsze i bezpieczniejsze w użyciu. Te biblioteki i frameworki przyciągną programistów do potężnych narzędzi.

4. Programiści, którzy lubią prostotę i bezpośredniość, będą nadal używać PHP lub podobnych języków.

Niestety, Programiści Javy bardzo lubią elektronarzędzia, więc odpowiadając na to, właśnie zmieniłem moje oczekiwania dotyczące głównego nurtu Scali. Nie mam żadnych wątpliwości, że Scala stanie się głównym językiem. Nie c-mainstream, ale być może Perl-mainstream lub PHP-mainstream.

Mówiąc o Javie, czy kiedykolwiek wymieniłeś class loader? Zastanawiałeś się kiedyś, co to oznacza? Java może być przerażająca, jeśli spojrzysz na miejsca, które robią Framework writers. Po prostu większość ludzi tego nie robi. dotyczy Scali, IMHO, ale początkujący mają tendencję do zaglądania pod każdą napotkaną skałę, aby sprawdzić, czy coś tam się ukrywa.

Czy to odstraszy ludzi przychodzących do Scali?

[1]}Czy to da Scali złą reputację w komercyjnym świecie jako akademickiej zabawce, która poświęca tylko Doktorat uczniowie rozumieją? Czy ctOS i szefowie oprogramowania się wystraszą?

Czy przebudowa biblioteki była sensownym pomysłem?

Jeśli używasz Scali komercyjnie, martwisz się o to? Czy planujesz przyjąć 2.8 od razu, czy czekasz, aby zobaczyć, co się stanie?

Jeden z bardziej ogólnych tematów "czy Scala jest zbyt skomplikowana dla mainstreamowych programistów?"...

Większość programistów, mainstreamowych lub innych, utrzymuje lub rozbudowuje istniejące systemy. Oznacza to, że większość tego, czego używają, jest podyktowana decyzjami podjętymi dawno temu. Wciąż jest mnóstwo ludzi piszących COBOL.

Jutrzejszy główny programista będzie pracował nad utrzymaniem i Rozszerzanie aplikacji, które są obecnie budowane. Wiele z tych aplikacji nie jest budowanych przez głównych programistów. Jutrzejsi główni programiści będą używać języka, który jest używany przez dzisiejszych najbardziej udanych twórców nowych aplikacji.

Jednym ze sposobów, w jaki społeczność Scali może pomóc złagodzić strach przed programistami, którzy są nowi w Scali, jest skupienie się na praktyce i nauczenie przez przykład--wiele przykładów, które zaczynają być małe i stopniowo rosną. Oto kilka stron, które przyjmują takie podejście:

• Daily Scala
• Nauka Scali w małych kęsach
• Simply Scala

Po spędzeniu trochę czasu na tych stronach, szybko orientuje się, że Scala i jej biblioteki, choć być może trudne do zaprojektowania i wdrożenia, nie są tak trudne w użyciu, zwłaszcza w typowych przypadkach.

Mam licencjat z taniego" rynku masowego " Uniwersytetu w USA, więc powiedziałbym, że wpadam w środek skali inteligencji użytkownika (a przynajmniej edukacji):) zajmuję się scalą od zaledwie kilku miesięcy i pracowałem nad dwoma lub trzema nietrywialnymi aplikacjami.

Szczególnie teraz, gdy IntelliJ wydał swoje dobre IDE z tym, co IMHO jest obecnie najlepszą wtyczką Scala, rozwój Scali jest stosunkowo bezbolesny: {]}

• Uważam, że mogę używać Scali jako " Java bez średników", tzn. piszę kod podobny do tego, co robiłbym w Javie, i korzystam trochę z zwięzłości składniowej, takiej jak ta uzyskana przez wnioskowanie typu. Obsługa wyjątków, gdy w ogóle to robię, jest wygodniejsza. Definicja klasy jest znacznie mniej słowna bez kotła getter/setter.

• Raz na jakiś czas udaje mi się napisać jedną linię, aby osiągnąć odpowiednik wielu linii Javy. W stosownych przypadkach łańcuchy metod funkcjonalnych, takich jak map, fold, collect, filtr itp. są zabawne do komponowania i eleganckie do obejrzenia.

• Rzadko zdarza mi się korzystać z bardziej zaawansowanych funkcji Scali: zamykania i częściowych (lub zwiniętych) funkcji, dopasowywania wzorców... tego typu rzeczy.

Jako początkujący, nadal zmagam się z zwięzłą i idiomatyczną składnią. Wywołania metod bez parametrów nie wymagają nawiasów, poza tym gdzie są; przypadki w instrukcji match wymagają strzałki fat (=>), ale są też miejsca gdzie potrzebna jest cienka strzałka (->). Wiele metod ma krótkie, ale raczej tajemnicze nazwy, takie jak /: lub \: - mogę zrobić swoje rzeczy, jeśli przewrócę wystarczającą liczbę stron podręcznika, ale część mojego kodu kończy się wyglądem jak Perl lub szum linii. Jak na ironię, brakuje jednego z najpopularniejszych skrótów składniowych w akcji: ciągle gryzie mnie fakt, że Int nie definiuje metody ++.

To tylko moje zdanie: czuję, że Scala ma moc C++ połączoną ze złożonością i czytelność C++. Złożoność składniowa języka sprawia, że dokumentacja API jest trudna do odczytania.

Myślę, że głównym problemem tej metody jest to, że (implicit bf : CanBuildFrom[Repr, B, That]) idzie bez wyjaśnienia. Chociaż wiem, jakie są ukryte argumenty, nic nie wskazuje na to, jak to wpływa na połączenie. Ganianie przez scaladoc pozostawia mnie bardziej zdezorientowanym (kilka klas związanych z CanBuildFrom ma nawet dokumentację).

Myślę, że proste "there must be an implicit object in scope for bf that provides a builder for objects of type B into the return type That" pomogłoby trochę, ale jest to rodzaj mocnej koncepcji, kiedy wszystko, co naprawdę chcesz zrobić, to mapować A do B. w rzeczywistości, nie jestem pewien, czy to prawda, ponieważ Nie wiem, co oznacza typ Repr, a dokumentacja Traversable z pewnością nie daje żadnego pojęcia.

Więc zostały mi dwie opcje, żadna z nich nie jest przyjemna:

• Załóżmy, że będzie działać tak, jak działa stara mapa i jak działa mapa w większości innych języków
• KOP w kod źródłowy trochę więcej

I get że Scala w zasadzie ujawnia, jak te rzeczy działają i że ostatecznie jest to sposób na to, co opisuje oxbow_lakes. Ale to odwrócenie uwagi w podpisie.

Jestem początkujący w Scali i szczerze mówiąc nie widzę problemu z tym podpisem typu. Parametr jest funkcją mapowania i domyślnym parametrem, który budowniczy zwraca poprawną kolekcję. Jasne i czytelne.

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")

To polimorfizm zrobiony racja.

Niestety podpis dla mapy, który podałeś, jest niepoprawny dla mapy i rzeczywiście jest uzasadniona krytyka.

Pierwsza krytyka polega na tym, że obalając podpis mapy, mamy coś bardziej ogólnego. Powszechnym błędem jest przekonanie, że jest to cnotą domyślnie. Nie jest. funkcja mapy jest bardzo dobrze zdefiniowana jako kowariantny funktor Fx - >(x -> y) - > Fy z przestrzeganiem dwóch praw kompozycji i tożsamości. Wszystko inne przypisane do "mapy" to parodia.

Podany podpis jest czymś innym, ale nie mapą. Podejrzewam, że próbuje to być wyspecjalizowana i nieco zmieniona wersja podpisu "trawersu" z papieru, esencja wzoru iteratora. Oto jego podpis:

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

Zamienię na Scala:

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

Oczywiście, że nie-to nie jest wystarczająco ogólne! Jest też nieco inaczej (należy pamiętać, że mapę można uzyskać, uruchamiając traverse przez funktor tożsamości). Jednak Ja podejrzewamy, że gdyby autorzy bibliotek byli bardziej świadomi uogólnień bibliotek, które są dobrze udokumentowane (Programowanie aplikacyjne z efektami poprzedza wyżej wymienione), to nie zauważylibyśmy tego błędu.

Po drugie, funkcja map jest szczególnym przypadkiem w Scali ze względu na jej użycie w składaniu for. Oznacza to niestety, że projektant Bibliotek, który jest lepiej wyposażony, nie może zignorować tego błędu bez poświęcania cukru składniowego składni. Innymi słowy, jeśli Projektanci biblioteki Scala mieli zniszczyć metodę, to jest łatwo ignorowane, ale proszę nie map!

Mam nadzieję, że ktoś się o tym wypowie, bo tak jak jest, trudniej będzie obejść błędy, na które nalega Scala, najwyraźniej z powodów, do których mam silne zastrzeżenia. Czyli rozwiązanie " nieodpowiedzialnych obiekcji ze strony przeciętnego programisty (tj. zbyt twardych!) "nie jest" zadowalać ich, aby ułatwić im" , ale zamiast tego zapewnić wskazówki i pomoc dla stać się lepszymi programistami. Ja i Scala jesteśmy w sporze w tej sprawie, ale wracając do twojego punktu widzenia.

Prawdopodobnie miałeś rację, przewidując konkretne odpowiedzi od " przeciętnego programisty."To jest ludzie, którzy będą twierdzić", ale to jest zbyt skomplikowane!"albo coś takiego. To są Yegges lub Blochs, do których się odnosisz. Moja reakcja na tych ludzi z ruchu antyintelektualizm / pragmatyzm jest dość ostra i już czekam na zaporę odpowiedzi, więc Pominę to.

Naprawdę mam nadzieję, że biblioteki Scali poprawią, a przynajmniej błędy można bezpiecznie schować w kącie. Java jest językiem, w którym" próba zrobienia czegoś użytecznego " jest tak niewiarygodnie kosztowna, że często nie jest tego warta, ponieważ przytłaczającej ilości błędów po prostu nie da się uniknąć. Błagam Scalę, by nie szła tą samą ścieżką.

Całkowicie zgadzam się zarówno z pytaniem, jak i z odpowiedzią Marcina :). Nawet w Javie odczyt javadoc z generics jest znacznie trudniejszy niż powinien być ze względu na dodatkowy szum. Jest to potęgowane w Scali, gdzie parametry niejawne są używane jak w przykładowym kodzie pytań(podczas gdy wartości niejawne robią bardzo przydatne rzeczy do morfowania kolekcji).

Nie sądzę, że to problem z językiem jako takim - myślę, że to bardziej problem z narzędziami. I chociaż zgadzam się z tym, co mówi Jörg W Mittag, myślę, że patrząc w scaladoc ( lub dokumentacji typu w IDE) - powinno to wymagać jak najmniejszej mocy mózgu, aby grok co to jest Metoda, co bierze i zwraca. Nie powinno być potrzeby siekać trochę algebry na trochę papieru, aby to dostać:)

Na pewno IDE potrzebują ładnego sposobu, aby pokazać wszystkie metody dla dowolnej zmiennej / wyrażenia/typu (które, jak w przykładzie Martina, mogą mieć wszystkie generyki inline, więc jest łatwe do grokowania). Podoba mi się pomysł Martina ukrywania przez domyślne też.

Aby wziąć przykład w scaladoc...

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

Patrząc na to w scaladoc chciałbym, aby ogólny Blok [B, That] był domyślnie ukryty, a także ukryty parametr (może pokazują się, jeśli najedziesz myszką małą ikonkę) - jako dodatkowe rzeczy do czytania grok, które zwykle nie są takie istotne. np. wyobraź sobie, że tak to wygląda...

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

Może mała ikona mogłaby być użyta do deklaracji [] i (implicit...) block więc jest jasne, że są małe fragmenty Oświadczenia upadł? Trudno użyć żetonu, ale użyję . na razie...

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

Więc domyślnie 'szum' systemu typów jest ukryty przed głównym 80% tego, na co ludzie muszą patrzeć - nazwa metody, jej typy parametrów i jej typ powrotu w prosty, zwięzły sposób - z niewielkimi rozszerzalnymi linkami do szczegółów, jeśli naprawdę ci tak zależy.

Większość ludzi czyta scaladoc, aby dowiedzieć się, jakie metody mogą wywoływać na typie i jakie parametry mogą przekazać. Trochę przeciążamy użytkowników zbyt dużą ilością szczegółów, jak IMHO.

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

Teraz, jeśli ukryliśmy deklarację generyczną, łatwiej ją odczytać

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

Następnie, jeśli ludzie najeżdżają na, powiedzmy, A1, możemy pokazać deklarację A1 będącą A1 <:>

Nie wiem jak ci to powiedzieć, ale mam doktorat z Cambridge i używam 2.8 w sam raz.

Bardziej poważnie, prawie nie spędziłem czasu z 2.7 (nie będzie współgrać z biblioteką Javy, której używam) i zacząłem używać Scali nieco ponad miesiąc temu. Mam pewne doświadczenie z Haskell (niewiele), ale po prostu zignorował rzeczy, które się martwisz i szukał metod, które pasują do mojego doświadczenia z Java (które używam do życia).

Więc: jestem "nowym użytkownikiem" i mnie nie postawiono off-fakt, że działa jak Java dał mi wystarczająco dużo pewności siebie, aby zignorować bity, których nie rozumiem.

(jednak powodem, dla którego patrzyłem na Scalę, było po części to, aby zobaczyć, czy go popchnąć w pracy, a ja jeszcze tego nie zrobię. Uczynienie dokumentacji mniej onieśmielającą z pewnością pomogłoby, ale to, co mnie zaskoczyło, to to, jak bardzo wciąż się zmienia i jest rozwijane(szczerze mówiąc, najbardziej zaskoczyło mnie to, jak jest niesamowita, ale zmiany przyszły blisko sekundy). Więc chyba kim jestem mówiąc to, wolałbym raczej, aby ograniczone środki zostały wprowadzone do doprowadzenia go do stanu końcowego - nie sądzę, że spodziewali się być tak popularne, że tak szybko.)

W ogóle nie znam Scali, jednak kilka tygodni temu nie mogłem czytać Clojure. Teraz mogę przeczytać większość z nich, ale nie mogę jeszcze napisać niczego poza najbardziej uproszczonymi przykładami . Podejrzewam, że Scala nie jest inna. Potrzebujesz dobrej książki lub kursu w zależności od tego, jak się uczysz. Czytając powyższą deklarację map , dostałem może 1/3.

Uważam, że większym problemem nie jest składnia tych języków, ale przyjęcie i internalizacja paradygmatów które czynią je użytecznymi w codziennym kodzie produkcyjnym. Dla mnie Java nie była wielkim skokiem od C++, który nie był wielkim skokiem od C, który wcale nie był skokiem od Pascala, ani Basic ' A itp... Ale kodowanie w języku funkcjonalnym, takim jak Clojure jest wielkim skokiem (jak dla mnie). Myślę, że w Scali można kodować w stylu Java lub Scala. Ale w Clojure stworzysz niezły bałagan starając się zachować swoje imperatywne nawyki z Javy.

Scala ma wiele szalonych funkcji (szczególnie tam, gdzie chodzi o Ukryte parametry), które wyglądają na bardzo skomplikowane i akademickie, ale są zaprojektowane tak, aby rzeczy były łatwe w użyciu. Najbardziej przydatne z nich otrzymują cukier składniowy (jak [A <% B], co oznacza, że obiekt typu A ma ukrytą konwersję na obiekt typu B) i dobrze udokumentowane wyjaśnienie tego, co robią. Ale przez większość czasu, jako klient tych bibliotek, możesz ignorować domyślne parametry i ufać im, że zrobią to dobrze rzecz.

Czy to odstraszy ludzi przychodzących do Scali?

Nie sÄ ... dzÄ™, Ĺźe jest to gĹ 'Ăłwny czynnik, ktĂłry wpĹ' ywa na jakÄ ... popularnoĹ "Ä ‡ bÄ ™ dzie Scala, poniewaĹź Scala ma duĹźÄ ... moc, a jej skĹ' adnia nie jest tak obca programistom Java/C++/PHP jak Haskell, OCaml, SML, Lisp, itp..

Ale myślę, że popularność Scali spadnie poniżej poziomu Javy, ponieważ uważam również, że następny mainstreamowy język musi być znacznie uproszczony i jedynym sposobem, aby uzyskać istnieje czysta niezmienność, tzn. deklaratywna jak HTML, ale Turing kompletna. Jednak jestem stronniczy, ponieważ rozwijam taki język, ale zrobiłem to dopiero po wykluczeniu z kilkumiesięcznych badań, że Scala nie może wystarczyć na to, czego potrzebowałem.

Czy to da Scali złą reputację w komercyjnym świecie jako akademickiej zabawy, którą tylko oddani doktoranci mogą zrozumieć? Czy ctOS i szefowie oprogramowania się wystraszą?

I don ' t think Reputacja Scali ucierpi z powodu kompleksu Haskell. Ale myślę, że niektórzy odłożą naukę, ponieważ dla większości programistów, nie widzę jeszcze przypadku użycia, który zmusi ich do korzystania ze Scali, a oni zwlekają z nauką o tym. Być może wysoce skalowalna strona serwera jest najbardziej przekonującym przypadkiem użycia.

I, dla głównego nurtu rynku, pierwsze uczenie się Scali nie jest "powiewem świeżego powietrza", gdzie pisze się programy natychmiast, na przykład używając HTML lub Pythona. Scala ma tendencję do wzrostu na Tobie, po tym, jak poznasz wszystkie szczegóły, które potykasz się od początku. Może jednak gdybym od początku czytał Programowanie w Scali, moje doświadczenie i opinia na temat krzywej uczenia się byłyby inne.

Czy przebudowa biblioteki była sensownym pomysłem?

Jeśli używasz Scali komercyjnie, martwisz się o to? Czy planujesz przyjąć 2.8 od razu, czy czekasz, aby zobaczyć, co się stanie?

I używam Scali jako początkowej platformy mojego nowego języka. Prawdopodobnie nie budowałbym kodu w bibliotece kolekcji Scali, gdybym używał Scali komercyjnie w inny sposób. Chciałbym stworzyć własną bibliotekę opartą na teorii kategorii, ponieważ raz spojrzałem, znalazłem sygnatury typu Scalaza jeszcze bardziej gadatliwe i nieporęczne niż Biblioteka kolekcji Scali. Częścią tego problemu może być sposób implementacji klas typu przez Scalę, i to jest niewielki powód, dla którego tworzę własne język.

Postanowiłem napisać tę odpowiedź, ponieważ chciałem zmusić się do zbadania i porównania projektu klasy kolekcji Scali do tego, który robię dla mojego języka. Równie dobrze mogę podzielić się moim procesem myślowym.

Zbiory 2.8 Scala wykorzystanie abstrakcji konstruktora jest zasadą projektowania dźwięku. Poniżej przedstawiam dwa rozwiązania konstrukcyjne.

1. WRITE-ONLY CODE: po napisaniu tej sekcji przeczytałem komentarz Carla Smotricza , który zgadza się z tym, czego oczekuję. Komentarze Jamesa Strachana i davetron5000 zgadzają się, że znaczenie tego (nie jest nawet to[B]) i mechanizm implicit nie jest łatwy do uchwycenia intuicyjnie. Zobacz moje użycie monoid w numerze #2 poniżej, co moim zdaniem jest znacznie bardziej wyraźne. Komentarz Dereka Mahara dotyczy pisania Scali, ale co z czytaniem Scali innych, co nie jest "w powszechnych przypadkach".

   Jedna krytyka, którą czytałem o Scali, Jest to, że łatwiej jest ją napisać, niż przeczytaj kod, który napisali inni. I uważam, że czasami jest to prawdą z różnych powodów (np. wiele sposobów na napisanie funkcji, Automatyczne zamykanie, jednostka dla DSLs itp.), Ale jestem niezdecydowany, jeśli jest to główny czynnik. Tutaj użycie ukrytych parametrów funkcji ma plusy i minusy. Z drugiej strony zmniejsza szczegółowość i automatyzuje wybór obiektu builder. W przykładzie Odersky ' ego konwersja z zestawu bitów, tj. Set[Int], do zestawu[String] jest niejawna. Na nieznajomy czytelnik kodu może nie wiedzieć, jaki jest typ kolekcji, chyba że potrafi dobrze zrozumieć wszystkich potencjalnych niewidocznych ukrytych kandydatów do budowania, które mogą istnieć w bieżącym zakresie pakietu. Oczywiście, doświadczony programista i autor kodu będzie wiedział, że BitSet jest ograniczony do Int, więc mapa na ciąg musi zostać przekonwertowana na inny typ kolekcji. Ale jaki rodzaj kolekcji? Nie jest to wyraźnie określone.

2. AD-HOC COLLECTION DESIGN: po napisaniu tej sekcji przeczytałemkomentarz Tony ' ego Morrisa i zdałem sobie sprawę, że robię prawie to samo. Może moja bardziej gadatliwa wypowiedź wyjaśni sprawę.

   W "Fighting Bit Rot with Types" Odersky & Moors przedstawiono dwa przypadki użycia. Są one ograniczeniem zestawu bitów do elementów Int i mapowaniem do parowania elementów krotki i są dostarczane jako powód, dla którego ogólna funkcja mapowania elementów, A = > B, musi być w stanie zbudować alternatywę typy kolekcji docelowej. Jednak afaik jest to wadliwe z punktu widzenia teorii kategorii. Aby być spójnym w teorii kategorii, a tym samym uniknąć przypadków narożnych, te typy zbiorów są funktorami, w których każdy morfizm, A => B, musi mapować między obiektami w tej samej kategorii funktora, List[a] = > List[B], BitSet[a] = > BitSet[B]. Na przykład, opcja jest funktorem, który może być postrzegany jako zbiór zbiorów jednego Some (obiektu ) i None. Nie ma mapy ogólnej z opcji Brak, lub listy Nil, do innych funkcji, które nie mają stanu "pustego".

   Dokonujemy wyboru projektu. W bibliotece design for collections mojego nowego języka zdecydowałem się uczynić wszystko funktorem, co oznacza, że jeśli zaimplementuję BitSet, musi on obsługiwać wszystkie typy elementów, używając Nie-bitowej reprezentacji wewnętrznej pola, gdy jest przedstawiony z parametrem typu nie-integer, a ta funkcjonalność jest już w zestawie, który dziedziczy w Scali. A mapa w moim projekcie musi mapować tylko jego wartości i może dostarczyć oddzielną metodę niefunktorową do mapowania jego pary krotek (klucz, wartość). Jedną z zalet jest to, że każdy funktor jest wtedy zwykle również aplikatorem, a być może także monadą. Tak więc wszystkie funkcje pomiędzy typami elementów, np. A = > B = > C = > D=>..., są automatycznie podnoszone do funkcji pomiędzy podnoszonymi typami aplikacji, np. List[A] => List[B] => List[C] => List[D] => .... Do mapowania z functora do innej klasy kolekcji, oferuję przeciążenie mapy, które zajmuje monoid, np. Nil, None, 0,"", Array (), itd.. Tak więc funkcja abstrakcji konstruktora jest metodą dodawania monoidu i jest dostarczana jawnie jako niezbędny parametr wejściowy, więc bez niewidocznych konwersji ukrytych. (Tangent: ten parametr wejściowy umożliwia również dołączanie do niepustych monoidów, czego nie może wykonać projekt mapy Scali.) Takie konwersje to mapa i fałd w tym samym przejściu iteracji. Zamieszczam również w kategorii "Programowanie aplikacyjne z efektami" & Patterson, który umożliwia również map + fold w jednym przejściu iteracyjnym z dowolnego przejścia do dowolnego zastosowania, gdzie najczęściej każda klasa kolekcji jest jednocześnie. Również monada stanowa jest aplikatywna, a więc jest w pełni uogólnioną abstrakcją konstruktorską z dowolnego przejazdu.

   Zatem zbiory Scali są "ad-hoc" w tym sensie, że nie są zakorzenione w teorii kategorii, a teoria kategorii jest esencją semantyki denotacyjnej wyższego poziomu. Mimo, że budowniczowie Scali są na pierwszy wygląd "bardziej uogólniony" niż model functora + monoid builder + traversable -> applicative, nie są one udowodnione, że są zgodne z jakąkolwiek kategorią, a zatem nie wiemy, jakie reguły stosują w najbardziej ogólnym sensie i jakie przypadki narożne zostaną podane, mogą nie być zgodne z żadnym modelem kategorii. Po prostu nie jest prawdą, że dodanie większej liczby zmiennych czyni coś bardziej ogólnego, a to było jedną z ogromnych zalet teorii kategorii jest to, że zapewnia reguły, według których można utrzymać ogólność podczas podnoszenia do semantyki wyższego poziomu. Kolekcja to kategoria.

   Czytałem gdzieś, myślę, że to był Odersky, jako kolejne uzasadnienie dla projektu biblioteki, jest to, że programowanie w czystym funkcjonalnym stylu ma koszt ograniczonej rekurencji i prędkości, gdzie rekurencja ogonowa nie jest używana. Nie było mi trudno zastosować rekursję ogonową w każdym przypadku, z którym do tej pory się spotkałem.

Dodatkowo noszę w głowie niekompletny pomysł, że niektóre z kompromisów Scali wynikają z prób bycia zarówno mutowalnym, jak i niezmiennym językiem, w przeciwieństwie na przykład do Haskella czy języka, który rozwijam. Zgadza się to z komentarzem Tony ' ego Morrisa na temat forsowania. W moim języku nie ma pętli ani mutowalnych konstrukcji. Mój język będzie siedział na szczycie Scali (na razie) i wiele mu zawdzięcza, a to nie byłoby możliwe, gdyby Scala nie miała ogólnego systemu typów i zmienności. To może nie być prawda, bo myślę, że Odersky & Moors ("Fighting Bit Rot with Types") jest błędnym stwierdzeniem, że Scala jest jedynym językiem OOP z wyższymi rodzajami, ponieważ zweryfikowałem (ja i poprzez Boba Harpera), że Standard ML je ma. Wydaje się również, że system typów SML może być równoważnie elastyczny (od lat 80.), co może nie być łatwo doceniane, ponieważ składnia nie jest tak bardzo podobna do Javy (i C++ / PHP) jak Scala. W każdym razie nie jest to krytyka Scali, a raczej próba przedstawienia niekompletnej analizy kompromisów, które czy mam nadzieję, że germane do pytania. Scala i SML nie cierpią z powodu niemożności Haskella do wykonaniadiamentowego dziedziczenia wielokrotnego , co jest krytyczne i rozumiem, dlaczego tak wiele funkcji w Haskell Prelude jest powtarzanych dla różnych typów.

Wydaje się konieczne, aby podać jeden stopień tutaj: B. A. w naukach politycznych i B. ed w informatyce.

Do punktu:

Czy to odstraszy ludzi przychodzących do Scali?

Scala jest trudna, ponieważ jej podstawowy paradygmat programowania jest trudny. Programowanie funkcjonalne przeraża wielu ludzi. Możliwe jest budowanie zamknięć w PHP, ale ludzie rzadko to robią. Więc nie, nie ten podpis, ale cała reszta zniechęci ludzi, jeśli nie mają specyficznej edukacji, aby doceniały siłę leżącego u podstaw paradygmatu.

Jeśli ta edukacja jest dostępna, każdy może to zrobić. W zeszłym roku zbudowałem komputer Szachowy z grupą uczniów w Scali! Mieli swoje problemy, ale w końcu poradzili sobie dobrze.

Jeśli używasz Scali komercyjnie, martwisz się o to? Czy planujesz przyjąć 2.8 od razu, czy czekasz, aby zobaczyć, co się stanie?

Nie martwiłbym się.

Ja też mam matmę z Oxfordu! Trochę mi zajęło "zdobycie" nowych kolekcji. Ale teraz bardzo mi się podoba. W rzeczywistości wpisanie 'map' było jedną z pierwszych dużych rzeczy, które mnie wkurzyły w 2.7 (być może od pierwszej rzeczy, którą zrobiłem, to podklasa jednej z klas kolekcji).

Przeczytanie artykułu Martina na temat nowych zbiorów 2.8 naprawdę pomogło wyjaśnić użycie niejawnych wartości, ale tak, sama dokumentacja zdecydowanie musi lepiej wyjaśnić rolę różnego rodzaju wywołania wewnątrz sygnatur metod Core API.

Moim głównym zmartwieniem jest to, że: kiedy 2.8 zostanie wydany? Kiedy przestaną pojawiać się raporty o błędach? czy zespół Scali odgryzł więcej, niż może przeżuć z 2.8 / próbował zmienić za dużo na raz?

Naprawdę chciałbym zobaczyć 2.8 stabilizowany do wydania jako priorytet przed dodaniem czegoś nowego w ogóle, i zastanawiam się (patrząc z boku), czy można wprowadzić jakieś ulepszenia w sposób zarządzany jest plan rozwoju kompilatora scala.

A co z komunikatami o błędach w use site?

A co z przypadkiem użycia trzeba zintegrować istniejące typy z niestandardowym, który pasuje do DSL. Trzeba być dobrze wykształconym w sprawach asocjacji, pierwszeństwa, ukrytych konwersji, ukrytych parametrów, wyższych rodzajów i być może typów egzystencjalnych.

Dobrze jest wiedzieć, że w większości jest to proste, ale niekoniecznie wystarczy. Przynajmniej musi być jeden facet, który zna te rzeczy, jeśli powszechna Biblioteka ma być zaprojektowany.