Python ssie

0

Miesiąc temu wpadłem na genialny pomysł napisania kilku skryptów w Pythonie dla pewnego banku. Ponieważ ich system posiadał natywne wsparcie dla skryptowania w Pythonie, oraz było dużo przykładów, no i oczywiście wiadomo, że "wszyscy lubią Pythona, bo Python dobrym językiem jest", a do tego projekt nie był jakiś bardzo duży, to zdecydowałem się, że zrobię to w Pythonie i że powinien być w sam raz do tego celu.

Wnioski:

  1. Brak statycznej kontroli typów ssie. Brak konieczności pisania typów: oszczędność 10 sekund. Brak walki z kompilatorem o to że typ się nie zgadza - oszczędność kolejnej minuty, oszczędność czasu kompilacji: pięć minut. Uruchamianie programu tylko po to, aby przeklikać się przez 5 formularzy i na piątym z pięciu, po kliknięciu ok, skrypt się wywalił, bo jest zła kolejność argumentów - bezcenne. Za pierwszym razem jest facepalm, spokojnie się poprawia i testuje dalej, ale jak się robi takie coś 10 razy z rzędu to ma się ochotę wyp****yć komputer za okno. Kto w swoich programach ma zawsze 100% pokrycia testami automatycznymi, może się nie zgodzić.

  2. Biblioteka standardowa ssie. Język, który ma lambdy a nie ma czegoś tak podstawowego jak fold, forall czy exists w standardzie, tylko trzeba sobie samemu napisać?

  3. Brak statycznej kontroli typów ssie nawet bardziej. Przypomniały mi się stare dobre czasy szablonów C++, kiedy dostałem gdzieś z czeluści biblioteki standardowej pythona błąd postaci "list indices must be integers, not strings". Pół godziny albo i więcej szukania, gdzie przekazałem obiekt złego typu. Oczywiście było to w zupełnie innym miejscu niż wskazany błąd.

  4. Pisałem już, że biblioteka standardowa ssie? Dlaczego jest os.listdirs, shutil.ignore_patterns i zipfile.ZipFile??

  5. Brak statycznej kontroli typów rozkłada IDE. Podpowiadanie nazw metod/funkcji dla bardziej podstawowych rzeczy nawet działa. Z wyjątkiem sytuacji kiedy nie działa, albo podpowiada jakieś głupoty.

  6. Składnia jest spoko, ogólnie język dosyć łatwy do nauczenia. Oczywiście mogło być lepiej. Np. [] służą zarówno do indeksowania tablic/stringów jak i do specyfikowania ich zawartości. Specyficzna składnia dla słowników też zalatuje trochę Perlem.

  7. A, no i bibliteka standardowa... Język ponoć zachwalany do zadań administracyjnych (jako konkurencja dla Perla), niektórzy chcieli nim powłokę zastępować, a nie można jednym poleceniem skopiować rekurencyjnnie plików z jednego katalogu do drugiego, niepustego katalogu. No dobra, można wywołując funkcję powłoki systemu, ale traci się przenośność.

  8. Nadal nie mogę dojść do tego, kiedy coś jest zwykłą funckją globalną (jak np. map, reduce, filter), a kiedy metodą - czy oni się tu kierowali jakąś zasadą czy dodawali tak jak się wylosowało. Np. czemu jest len(string), ale już string.upper()? Idzie się do tego przyzwyczaić, ale dla poczatkującego, jeszcze przy nie-do-końca-działającym podpowiadaniu w IDE takie nielogiczności są okropne.

  9. Szybkość... Eee tam, stary i oklepany argument. Akurat szybkość wykonywania kodu w tym projekcie była bardzo zadowalająca, większość czasu męczył się system przy przesyłaniu danych przez sieć.

  10. Znaczące wcięcia - mnie jakoś nie przeszkadza, dopóki ktoś nie otwiera mojego kodu w notatniku ustawionym domyślnie na taby a nie spacje.

  11. Język ma lambdy, ale sensownie programować funkcyjnie w tym się nie da. Po co to? Chyba tylko by drażnić ludzi. Czuję się jakby ktoś otworzył pudełko z czekoladkami, dał mi jedną, a sam zjadł całą resztę.

Podsumowując, nie zaczynajcie uczyć się Pythona po nauczeniu się Scali, bo się tylko niepotrzebnie poirytujecie.

0

o_O

0

W zasadzie to bardziej Ci przeszkadza jedna funkcjonalność (dynamiczne typowanie) oraz brak jednej funkcjonalności (programowanie funkcyjne) niż sam język.
A jeśli chodzi o trochę bałaganu w nazewnictwie to w każdym języku jest trochę bazjlu, lepiej w nazewnictwie niż w samym designie.

0

No, można tak powiedzieć, ale są to dwie bardzo duże i poważne rzeczy, które zabijają produktywność. Dosyć skromna liczba operacji na kolekcjach powoduje, że miejscami kod jest prawie tak rozwlekły jak w Javie (z dokładnością do deklaracji typów). Np. jak napisać w Pythonie równie krótko i zrozumiale odpowiednik tego:

val słownik = Map('ą' -> 'a', 'ć' -> 'c', 'ę' -> 'e', ...)
val tekst = "Jakiś tekst z ogonkami"
val tekstBezOgonków = tekst.map(słownik withDefault identity)   // chodzi o tę linijkę

A co do bajzlu w nazwach, to co jak co, ale właśnie chyba szczególnie w języku dynamicznym go nie powinno być. W statycznym to jeszcze przejdzie, bo IDE sobie ładnie z tym radzą. Serio, nie spodziewałem się, że Python pod względem konsekwencji w nazewnictwie jest tak podobny do PHP.

0
Krolik napisał(a)
  1. Brak statycznej kontroli typów ssie. Brak konieczności pisania typów: oszczędność 10 sekund. Brak walki z kompilatorem o to że typ się nie zgadza - oszczędność kolejnej minuty, oszczędność czasu kompilacji: pięć minut. Uruchamianie programu tylko po to, aby przeklikać się przez 5 formularzy i na piątym z pięciu, po kliknięciu ok, skrypt się wywalił, bo jest zła kolejność argumentów - bezcenne. Za pierwszym razem jest facepalm, spokojnie się poprawia i testuje dalej, ale jak się robi takie coś 10 razy z rzędu to ma się ochotę wyp****yć komputer za okno. Kto w swoich programach ma zawsze 100% pokrycia testami automatycznymi, może się nie zgodzić.

Stosuj TDD (kilka bibliotek do unittestów w bibliotece standardowej + bardzo mocny support dla nich) i jednolitą konwencję przekazywania argumentów problemów nie będzie. Zapoznaj się z PyDev jeśli potrzebujesz "javowego" stylu tworzenia kodu. Wspominałem już, że REPL to podstawa? Dynamiczne typowanie to inne podejście do programowania, ma inne wymagania i przynosi inne korzyści, nie da się tak po prostu przełączyć perspektywę z Javy na Pythona i oczekiwać tego samego.

Krolik napisał(a)
  1. Biblioteka standardowa ssie. Język, który ma lambdy a nie ma czegoś tak podstawowego jak fold, forall czy exists w standardzie, tylko trzeba sobie samemu napisać?

Język, który miał mieć usunięte lambdy ponieważ dłuższe rzeczy i tak wymagają zapisania w oddzielnej linii (wtedy pisze się zwykłą funkcję lokalną) zaś krótsze to po prostu comprehension. fold jest, nazywa się po ludzku: reduce. forall jako predykat istnieje, nazywa się all, exists to pewnie any, oba używane zazwyczaj z generatorami. Do tego dochodzi chociażby moduł itertools.

Krolik napisał(a)
  1. Brak statycznej kontroli typów ssie nawet bardziej. Przypomniały mi się stare dobre czasy szablonów C++, kiedy dostałem gdzieś z czeluści biblioteki standardowej pythona błąd postaci "list indices must be integers, not strings". Pół godziny albo i więcej szukania, gdzie przekazałem obiekt złego typu. Oczywiście było to w zupełnie innym miejscu niż wskazany błąd.

Dostajesz kompletny callstack z wkazanymi liniami kodu, jesteś poprawadzony za rączkę lepiej niż w jakimkolwiek znanym mi języku. Szukanie? Debugger.

Krolik napisał(a)
  1. Pisałem już, że biblioteka standardowa ssie? Dlaczego jest os.listdirs, shutil.ignore_patterns i zipfile.ZipFile??

Dlatego, że metody nazywa się z podkreśleniami, klasy są CamelCase. Moduł os jest dosyć ubogi w podkreślenia, z racji wzorowania się na rzeczach "uniksowych", od których bezpośrednio pochodzi.

Krolik napisał(a)
  1. Brak statycznej kontroli typów rozkłada IDE. Podpowiadanie nazw metod/funkcji dla bardziej podstawowych rzeczy nawet działa. Z wyjątkiem sytuacji kiedy nie działa, albo podpowiada jakieś głupoty.

Aptana/Eclipse z PyDev czy PyCharm radzą sobie świetnie, przynajmniej póki kod reprezentuje sensowny poziom.

Krolik napisał(a)
  1. Składnia jest spoko, ogólnie język dosyć łatwy do nauczenia. Oczywiście mogło być lepiej. Np. [] służą zarówno do indeksowania tablic/stringów jak i do specyfikowania ich zawartości.

W Scali na ten przykład funkcje wywołuje się z nawiasami wokół argumentów albo bez, metody wywołuje się na rzecz obiektu kropką albo bez kropki: obiekt.metoda(argument) vs. obiekt metoda argument. Jak się indeksuje w Scali? Tak jak wywołuje funkcje: funkcja(1) i lista(1). Mogło być gorzej, mogliście jeszcze nieobowiązkowe krzaczki z PHP wprowadzić. Możemy tak sobie dogadywać długo.

Krolik napisał(a)

Specyficzna składnia dla słowników też zalatuje trochę Perlem.

Pewnie JS też Ci Perlem zalatuje? Składnia jest prostsza i czytelniejsza od tych "strzałeczek" z Ruby i Scali, chociaż to kwestia gustu. Słownik w Pythonie: {klucz1: wartość2, klucz2: wartość2}, Ruby: {klucz1 => wartość2, klucz2 => wartość2}, Scala: Map(klucz1 -> wartość1, klucz2 -> wartość2). Do tego należy doliczyć dictionary comprehension z Pythona: {klucz: wartość for ... in ... if ...}, gdzie if jest opcjonalny. W starszych wersjach Pythona, pozbawionych dictionary comprehension, zapisywało się to generatorem: dict((klucz, wartość) for ... in ... if ...). Indeksowanie, Python słownik[klucz], Ruby tak samo, Scala: słownik(klucz), co bywa mylące.

Krolik napisał(a)
  1. A, no i bibliteka standardowa... Język ponoć zachwalany do zadań administracyjnych (jako konkurencja dla Perla), niektórzy chcieli nim powłokę zastępować, a nie można jednym poleceniem skopiować rekurencyjnnie plików z jednego katalogu do drugiego, niepustego katalogu. No dobra, można wywołując funkcję powłoki systemu, ale traci się przenośność.

Python nie jest zamiennikiem Perla, jest językiem ogólnego przeznaczenia. Jeżeli shutil.copy się nie sprawdza to trzeba napisać całe dwie linijki kodu.

Krolik napisał(a)
  1. Nadal nie mogę dojść do tego, kiedy coś jest zwykłą funckją globalną (jak np. map, reduce, filter), a kiedy metodą - czy oni się tu kierowali jakąś zasadą czy dodawali tak jak się wylosowało. Np. czemu jest len(string), ale już string.upper()? Idzie się do tego przyzwyczaić, ale dla poczatkującego, jeszcze przy nie-do-końca-działającym podpowiadaniu w IDE takie nielogiczności są okropne.

Dla zwykłego początkującego to nie problem, dla Javowca pewnie już tak. Globalne są helpery (i wrappery) dla metod specjalnych oraz ew. abstrakcja kolekcji (czyli i tak metod specjalnych), Java nie posiada metod specjalnych.

Krolik napisał(a)
  1. Język ma lambdy, ale sensownie programować funkcyjnie w tym się nie da. Po co to? Chyba tylko by drażnić ludzi. Czuję się jakby ktoś otworzył pudełko z czekoladkami, dał mi jedną, a sam zjadł całą resztę.

Da się, da się. Na lambda-wyrażeniach świat się nie kończy, są funkcje lokalne itd. bez których chociażby dekoratory byłyby trudne do zrealizowania.

Krolik napisał(a)

Podsumowując, nie zaczynajcie uczyć się Pythona po nauczeniu się Scali, bo się tylko niepotrzebnie poirytujecie.

Scala to ciekawostka, którą możesz się zajmować for fun, Python to język for profit. Cóż mogę powiedzieć, nie znasz jeszcze Pythona więc nie oceniaj pochopnie.

0
Krolik napisał(a)

Np. jak napisać w Pythonie równie krótko i zrozumiale odpowiednik tego:

val słownik = Map('ą' -> 'a', 'ć' -> 'c', 'ę' -> 'e', ...)
val tekst = "Jakiś tekst z ogonkami"
val tekstBezOgonków = tekst.map(słownik withDefault identity)   // chodzi o tę linijkę

Czytelność to kwestia znajomości języka, Scala w tym momencie może dla niektórych wyglądać jak pseudokod.

slownik = {'ą': 'a', 'ć': 'c', 'ę': 'e', ...}
tekst = "Jakiś tekst z ogonkami"
tekstBezogonkow = ''.join(slownik.get(c, c) for c in tekst)
Krolik napisał(a)

A co do bajzlu w nazwach, to co jak co, ale właśnie chyba szczególnie w języku dynamicznym go nie powinno być. W statycznym to jeszcze przejdzie, bo IDE sobie ładnie z tym radzą. Serio, nie spodziewałem się, że Python pod względem konsekwencji w nazewnictwie jest tak podobny do PHP.

Jak już pisałem: bajzlu nie ma, jest nawet dokument standaryzujący styl pisania: PEP8. Narzędzia, jak PyChecker czy PyLint (którego polecam) generują warny i obniżają ocenę kodu za odstępstwa od standardu. Dwa moduły odstają nieco od przyjętego nazewnictwa, głównie unittest, który jest lepszym odpowiednikiem bibliotek znanych z wielu innych języków *Unit.

0

Dynamiczne typowanie to inne podejście do programowania, ma inne wymagania i przynosi inne korzyści, nie da się tak po prostu przełączyć perspektywę z Javy na Pythona i oczekiwać tego samego.

Jakie są niby te korzyści? Wg mnie lokalna inferencja typów w Scali powoduje, że dynamiczne typowanie rzadko kiedy jest sensowne, jako że i tak ilości kodu produkcyjnego nie zmniejsza, a zwiększa ilość potrzebnego kodu to testowania. Poza tym w Scali jest jakaś namiastka dynamicznego typowania, ale się tym jeszcze nie bawiłem.

Scala to ciekawostka, którą możesz się zajmować for fun, Python to język for profit. Cóż mogę powiedzieć, nie znasz jeszcze Pythona więc nie oceniaj pochopnie.

http://typesafe.com/ => 100.000 programistów Scali, 20 dużych firm korzystających z niej, liczne konferencje o Scali, kilka milionów dolarów (co najmniej) zainwestowane w Typesafe to czysta zabawa?

Python to raczej zabawka, taki ulepszony PHP, oba są bardzo popularne i łatwe do nauczenia na poziomie podstawowym.

0

Tja tyle, że te "zabawki" zostały przetestowane w boju w wielu poważnych projektach, a Twojej "poważnej" Scali daleko do tego. Zejdź na ziemie Wibowit, o sile języka nie stanowi tylko składnia, paradygmaty i rodzaj typowania ale to jaki język ma support w postaci programistów, materiałów, narzędzi oraz ile kodu zostało w nim napisane w realnych zastosowaniach.
A biorąc pod uwagę powyższe kryteria to Scala jest zabawką przy PHP i Pythonie.

0
Wibowit napisał(a)

Dynamiczne typowanie to inne podejście do programowania, ma inne wymagania i przynosi inne korzyści, nie da się tak po prostu przełączyć perspektywę z Javy na Pythona i oczekiwać tego samego.

Jakie są niby te korzyści? Wg mnie lokalna inferencja typów w Scali powoduje, że dynamiczne typowanie rzadko kiedy jest sensowne, jako że i tak ilości kodu produkcyjnego nie zmniejsza, a zwiększa ilość potrzebnego kodu to testowania.

Duck typing znacznie przyspiesza tworzenie testów (które i tak musisz tworzyć) i oprogramowania w ogóle, nie musisz dodatkowych interface'ów klepać. Statyczne typowanie wiele rzeczy niestety utrudnia. Jest dobre w językach pokroju Haskella, gdzie programowanie polega na sterowaniu przepływem danych, nie tworzeniu ich "rzeczywistych abstrakcji" (jak to ma miejsce w OOP), zaś typ (znany dokładnie na etapie kompilacji) jest równie ważny co sama przenoszona wartość. Koszt testowania jest większy, koszt pisania mniejszy, zazwyczaj proporcjonalnie, nie są to ogromne różnice. Nie można mówić o XX większej produktywności jednego system typów nad innym (może z wyjątkiem tych żałosnych tworów z COBOLa i PHP).

http://typesafe.com/ => 100.000 programistów Scali, 20 dużych firm korzystających z niej, liczne konferencje o Scali, kilka milionów dolarów (co najmniej) zainwestowane w Typesafe to czysta zabawa?

Owszem, 100k "miłośników" Scali, z czego mniej niż tysiąc faktycznie w pracy Scali używa. 20 firm, dużych może dla Ciebie. Konferencje odbywają się nawet o brainfucku, nawet niszowy Haskell ma kilka naprawdę dużych konferencji corocznie. Kilka milionów to zarobiło wiele projektów w Pythonie na łeb, to naprawdę nie jest wielka suma. Naprawdę nie ma czym się ekscytować, niemal każdy w pierwszej 20-30 najpopularniejszych języków ma swoje konferencje i "bogate wdrożenia".

Wibowit napisał(a)

Python to raczej zabawka, taki ulepszony PHP, oba są bardzo popularne i łatwe do nauczenia na poziomie podstawowym.

Wytłumacz mi, jak to jest, że nie widziałem ani jednego Twojego postu, w którym byś nie mieszał innych języków programowania z błotem (nawet tych, w których nie pisałeś bądź ich zwyczajnie nie rozumiesz) i nie wywyższał Scali? Python ma całkowicie inny model typowania, jest zdecydowanie bliższy Twojej Scali niż PHP.

PHP może w ogóle w to nie mieszajmy, pierwotnie to nawet nie był język programowania.W drugiej wersji komuś odbiło i z zachowaniem dawnych szablonowych ficzerów oraz "brakiem" typowania dodał typowe elementy programowania.

0

Zarówno w Scali jak i w Pythonie mam podobne doświadczenie (w obu komercyjne). Nie zauważyłem, też, abym gdzieś mieszał jakieś języki z błotem - w sumie to chyba mój pierwszy większy post w dziale flame ;). Obu języków uczyłem się od zera i to dosyć niedawno, więc mam na świeżo - zdecydowanie Scala jest prostsza do nauki - mniej lukru składniowego, więcej funkcjonalności w bibliotekach. Sorry, może i w Pythonie wszystko ma głębszy sens, ale przez ten pierwszy miesiąc sprawia wrażenie bardzo bałaganiarskiego języka - własnie ze względu na nazewnictwo, na to że pewne rzeczy są klasami/obiektami z nie wiadomo jakich przyczyn, pewne metodami, a pewne zwykłymi funkcjami globalnymi itp. Np. czemu to "any" i "reduce" nie są metodami kolekcji? Ale już np. get jest metodą słownika? Bez sensu. Stąd nasuwają się porównania do PHP. Utrudnia to też poszukiwanie odpowiednich funkcji i w efekcie można się złapać na tym, że się napisało niepotrzebnie kod, nie wiedząc, że coś już istnieje (jak ja z tym get).

Co do deklaracji słowników, to akurat w Scali te strzałeczki nie są elementem składni, tylko wywołaniem metody (operatora - w Scali metody i operatory są jednym i tym samym). Dzięki temu można stworzyć sobie własny rodzaj słownika i używać tej samej składni, co domyślne - w Pythonie już tak się nie da. Ale to jest i tak drobiazg, dla mnie nie ma tak wielkiego znaczenia jak właśnie brak statycznego systemu typów.

Co do stacktrace'ów to raczysz żartować - stacktrace pokazuje punkt w którym się wywaliło, a nie punkt, w którym wystąpiła niezgodność typów. Faktycznie, w większości sytuacji to jest ten sam punkt. Ale czasem nie jest. I wtedfy boli tak samo jak szukanie przyczyny segfaultów w C (bez valgrinda).
Obiekt złego typu mogłem przekazać gdzieś daleko, daleko wcześniej, mógł zostać zapisany w kolekcji i później jest dochodzenie, co i w którym momencie wstawiło zły obiekt. Zdaje się, że z tego powodu Twitter stopniowo rezygnuje z Rubyego - opisywali gdzieś, że koniec końców niemal na wejściu każdej funkcji mieli asercje dotyczące typów, aby łapać takie błędy tam gdzie występują.

No i jakie to niby rzeczy dobry statyczny system typów utrudnia, bo nie zauważyłem?
Zawsze w ostateczności mogę programować wszystko jako Any/Dynamic - mówiąc tym samym kompilatorowi "spadaj". Tylko jakoś nie miałem jeszcze okazji.

Owszem, 100k "miłośników" Scali, z czego mniej niż tysiąc faktycznie w pracy Scali używa. 20 firm, dużych może dla Ciebie. Konferencje odbywają się nawet o brainfucku, nawet niszowy Haskell ma kilka naprawdę dużych konferencji corocznie. Kilka milionów to zarobiło wiele projektów w Pythonie

Chciałbym zauważyć, że ostatnio Googiel zrobił testy kilku języków programowania i... o zgrozo były tam tylko: C++, Java, Scala i Google Go. Zapomnieli o Pythonie? Dziwne, bo przecież podobno używają... Poza tym wszelkie porównania popularności w liczbach bezwzględnych są zresztą nie na miejscu - bo Python ma niemal o 15 lat więcej niż Scala, czyli istnieje na rynku ok. 4x dłużej. Na razie niektórzy twierdzą, że Scala jest mniej więcej w tym miejscu co Python był w 2004 r (pod względem popularności).

Tja tyle, że te "zabawki" zostały przetestowane w boju w wielu poważnych projektach, a Twojej "poważnej" Scali daleko do tego.

Foursquare, Twitter i LinkedIn nazywasz niepoważnymi projektami? Ja tam nie widzę nic porównywalnej wielkości i o porównywalnej "mocy przerobowej" napisanego w Pythonie. Owszem, w Polsce mamy Grono, ale to jest nic w porównaniu z Twitterem. No i jest na pewno cała masa serwisów gdzieś wykorzystujących Pythona w niekluczowych komponentach (niewymagających przetwarzania dużej ilości danych), jak np. Google Help czy YouTube.

0

ofdiyl:
A czy na Pythona od razu wszyscy się rzucili? Python ma 21 lat, Scala 8 lat, z czego przez pierwsze parę lat język nie jest od razu wykorzystywany w biznesie. Różnica jest jednak taka, że Scala bardzo dobrze współpracuje z Javą, na którą to jest dostępne chyba dużo więcej oprogramowania niż na Pythona. Komercyjne wsparcie dla Scali (Typesafe) już jest, więc nie ma niebezpieczeństwa, że jeśli coś w Scali będzie zwalone to twórcy to oleją. Gdyby jeszcze było więcej programistów Scali (przynajmniej tak z 1/ 3 tych od Pythona) to nie byłoby przeszkód by wprowadzać Scalę w biznesie gdziekolwiek.

Edit:
Krolik mnie ubiegł.

0
Krolik napisał(a)

Nie zauważyłem, też, abym gdzieś mieszał jakieś języki z błotem

O Tobie tego nie napisałem, podajesz argumenty z głową, po prostu zwyczajnie się gubisz w niektórych sprawach.

Krolik napisał(a)

Np. czemu to "any" i "reduce" nie są metodami kolekcji?

Bo nie pracują na konkretnym rodzaju obiektu, raczej na czymś co obiecuje mieć pewne metody specjalne (właściwie to jedną). Ma to ten sens, że używają identycznego mechanizmu co zwykły for ... in czy comprehension. Kolekcje nie mają wspólnej klasy bazowej, implementują wyłącznie tworzenie iteratora. Poza tym to też zaszłość z dosyć wczesnych wersji Pythona, który był bardziej 'pure' a mniej elastyczny, przynajmniej trzymają się tego konsekwentnie i z jasno określonymi zasadami - ściśle generyczne helpery, które zakładają wyłacznie istnienie metod specjalnych, są funkcjami.

Krolik napisał(a)

Ale już np. get jest metodą słownika?

Jest metodą specyficzną dla słownika, normalnie indeksowanie zakłada, że podajesz istniejący indeks, w innym wypadku zostaje rzucony wyjątek, wszystkie kolekcje mają z założenia tę własność spełniać. dict.get nie rzuca wyjątku nigdy, zwraca wartość domyślną, która zresztą ma wartość domyślną None. Np. dla stringa odpowiednik get nie ma najmniejszego sensu. Jedna z kilku ważnych zasad tego języka, spotykana niemal na każdym kroku - "proste" operacje rzucają wyjątkami w wypadku niepowodzenia, prawie zawsze istnieje "złożona" operacja pozwalająca błąd obsłużyć lub przeczekać.

Krolik napisał(a)

Co do deklaracji słowników, to akurat w Scali te strzałeczki nie są elementem składni, tylko wywołaniem metody (operatora - w Scali metody i operatory są jednym i tym samym). Dzięki temu można stworzyć sobie własny rodzaj słownika i używać tej samej składni, co domyślne - w Pythonie już tak się nie da.

Konkretnie to te strzałeczki tworzą krotki, które konsumuje słownik, to nadal jest tylko lista argumentów dla apply obiektu towarzyszącego, coś jak kolekcja par w Pythonie tylko w minimalnie ładniejszej składni, a -> b zamiast (a, b).

Krolik napisał(a)

Co do stacktrace'ów to raczysz żartować - stacktrace pokazuje punkt w którym się wywaliło, a nie punkt, w którym wystąpiła niezgodność typów. Faktycznie, w większości sytuacji to jest ten sam punkt. Ale czasem nie jest. I wtedfy boli tak samo jak szukanie przyczyny segfaultów w C (bez valgrinda).

Bez przesady, dysponując debuggerem możesz obejrzeć, co spowodowało rzucenie wyjątku, argumenty kolejnych wywołań i zmienne, osobiście nigdy nie miałem problemów ze zlokalizowaniem tego rodzaju błędów.

Krolik napisał(a)

No i jakie to niby rzeczy dobry statyczny system typów utrudnia, bo nie zauważyłem?
Zawsze w ostateczności mogę programować wszystko jako Any/Dynamic - mówiąc tym samym kompilatorowi "spadaj". Tylko jakoś nie miałem jeszcze okazji.

Utrudnia manipulowanie obiektami bez znajomości konkretnego typu, trzeba się bawić w Any, AnyRef i instanceOf w konkretnych punktach, w Pythonie/Ruby co najwyżej odpytuje się o posiadanie atrybutu. Oczywiście zależy to od designu aplikacji, czy stosuje się "ciężkie" testy i agresywny duck typing, (mocno) redukując dziedziczenie, czy też klepie drugie tyle i robi ładną hierarchię typów. Poza tym statyczne typowanie nie eliminuje w 100% błedów wynikających z niewłaściwie dobranych typów nawet w Haskellu.

Przewagi na jednym polu są równoważone na innym. OOP ssie, obecne programowanie logiczne i czysto funkcyjne też ssie, Scala ssie nie mniej, nie istnieje ani język, ani paradygmat będący panaceum na wszystkie problemy inżynierii oprogramowania.

0
Krolik napisał(a)

Chciałbym zauważyć, że ostatnio Googiel zrobił testy kilku języków programowania i... o zgrozo były tam tylko: C++, Java, Scala i Google Go.

Czyli chyba to, co potrafią obecnie na kod natywny przemielić. Nie wiem, nie widziałem tego porównania.

Krolik napisał(a)

Foursquare, Twitter i LinkedIn nazywasz niepoważnymi projektami? Ja tam nie widzę nic porównywalnej wielkości i o porównywalnej "mocy przerobowej" napisanego w Pythonie. Owszem, w Polsce mamy Grono, ale to jest nic w porównaniu z Twitterem.

Spora część crawlerów i silnika wyszukiwania Google jest stworzona w Pythonie, NASA używa Pythona do czegoś więcej niż robienie backupów, część infrastruktury Yahoo to Python, Reddit kilka lat temu został na niego przepisany z Common Lispu.

Wibowit napisał(a)

Różnica jest jednak taka, że Scala bardzo dobrze współpracuje z Javą, na którą to jest dostępne chyba dużo więcej oprogramowania niż na Pythona.

Jako przeciwwaga: (Iron)Python świetnie współpracuje z .NET, z błogosławieństwem i wsparciem Microsoftu. Scala dla .NET to tak samo żałosna porażka co Jython.

Tak się zastanawiam, o czym my tu dyskutujemy? To dwa różne języki o różnych zastosowaniach, dla różnych środowisk.

0

Jak to o czym ta dyskusja? O wyższości jabłka nad gruszką :)
Więc powtórzę mój komentarz: o_O

0

No to może jakieś porównanie refaktoryzacji kodu w Javie/ Scali i w Pythonie? Refaktoring w Javie jest banalny, np wyciągnięcie interfejsu z klasy to kilka kliknięć w NetBeansie, Eclipse itd podobnie wyciągnięcie abstrakcyjnej klasy, wydelegowanie metod, zmiana nazw packages, metod, pól czy klas, itp itd hierarchię klas można stworzyć praktycznie automatycznie. W Scali są case classes i pattern matching do nich co pozwala bardzo łatwo i zwięźle operować na hierarchiach klas.

0

Foursquare, Twitter i LinkedIn nazywasz niepoważnymi projektami? Ja tam nie widzę nic porównywalnej wielkości i o porównywalnej "mocy przerobowej" napisanego w Pythonie. Owszem, w Polsce mamy Grono, ale to jest nic w porównaniu z Twitterem. No i jest na pewno cała masa serwisów gdzieś wykorzystujących Pythona w niekluczowych komponentach (niewymagających przetwarzania dużej ilości danych), jak np. Google Help czy YouTube.

Cały Tweeter i LinkedIn jest napisany w Scali czy jak? Proszę o link gdzie jest napisane jaka konkretna część Tweetera/Linkedin została napisana w Scalii. Bo równie dobrze to może być mały kawałek, np. wstępny preprocessing plików z danymi.

0

@Wibowit, z jednej strony refaktoryzacja w takim stopniu jest niemożliwa w języku dynamicznie typowanym. Z drugiej strony duck typing (czasem także znienawidzony monkey patching) znacznie redukują konieczność tworzenia nowych hierarchii klas, rozluźniają zależności w sposób niedostępny dla statycznego typowania. Więcej sposobów uniknięcia szerszej refaktoryzacji vs. większe możliwości automatycznej refaktoryzacji.

0

@0x200x20, proszę cię bardzo http://www.artima.com/scalazine/articles/twitter_on_scala.html , http://www.scala-lang.org/node/6436 :)

Co do Pythona to fajny język. Mam jednak ostatnio trochę do czynienia ze Scalą i powiem tak. Te dwa języki pozwalają na wybór bardziej przyjaznego interfejsu. Lubisz wcięcia i całkowity brak typowania weź Pythona. A może jednak możliwość statycznego typowania i dużą bibliotekę standardową + od cholery dodatków? To Scala jest dla ciebie. A jak chcesz język funkcyjny wybierasz Clojre i po problemie.

@Wibowit, z refaktoringiem w Scali jest ten problem, że IDE nie są jeszcze na tyle dobre by sobie z tym radzić na takim poziomie jak w czystej Javie. Zresztą zobacz ile pamięci pożera plugin Scala do Eclipse. W życiu ie sądziłem, że będę podawał max memory dla IDE w gigabajtach.

0

ofidyfil:
Z drugiej strony hierarchia klas i powiązane z tym UMLe (i podobne do UMLa rzeczy) znacznie ułatwiają wdrożenie w projekt czy wspólne zaprojektowanie systemu. Scala to skrót od SCAlable LAnguage, jest to język który ma się skalować od niewielkich projektów do wielkich krów. Akurat w małych projektach użycie Scali może mieć mało sensu to jednak wiele dużych projektów wystartowało jako małe.

Jeśli ukryjesz hierarchię klas to jak ktoś nowy ma się w tym połapać? Np ukryjesz ogólny interfejs kolekcji, a ktoś będzie chciał np dodać implementację drzewa rozchylanego będącą kolekcją. I co wtedy? Gdzieś ten interfejs musi być opisany tak czy siak. A jeśli jest na miejscu w kodzie to wg mnie tym lepiej.

Języki dynamicznie typowane jak ten Python z założenia nie są projektowane z nastawieniem na jak największą wydajność, więc generalnie twórcy nie bawią się w wiele implementacji listy, zbioru, mapy, etc Jest jedna wbudowana implementacja i na tym się jedzie non-stop.

Koziołek:
Dokupienie 2 GiB RAMu (nawet DDR2) to koszt max 100 zł. Natomiast zysk na produktywności wielokrotnie większy. Owszem wtyczki do IDE jak i systemy do budowania aplikacji (tzn kompilacji, pakowania, etc) są jeszcze niedojrzałe, ale wtyczki do Eclipse czy IDEI są raczej szybko rozwijane (niestety nie można tego powiedzieć o wtyczce do NetBeans jako że pisze ją tylko jedna osoba).

0

Język, który ma lambdy a nie ma czegoś tak podstawowego jak fold, forall czy exists w standardzie, tylko trzeba sobie samemu napisać?

Reduce, apply i map twoim przyjacielem. Tylko z niewiadomych powodów miały zostać (oprócz map) usunięte z pythona 3.0 (nie one jedyne, zgodność wsteczna między wersjami pythona jest traktowana dość lekko). Czy tak się stało - nie wiem, ale ideone twierdzi że tak (http://ideone.com/T64QE)

czemu jest len(string), ale już string.upper()

Myślę że to dlatego że len jest dość śmieszną funkcją - w pythonie istnieje operator (?) __len__ służący do wyciągania 'długości' dowolnego obiektu. funkcja len tylko go zwraca. Ofidyfil wygląda na dobrze znającego pythona, może potwierdzi albo zaprzeczy.

>>> len("asdf")
4
>>> "asdf".__len__()
4
>>> class q:
...     def __len__(self):
...         return 8
...
>>> w = q()
>>> len(w)
8
0
Wibowit napisał(a)

Jeśli ukryjesz hierarchię klas to jak ktoś nowy ma się w tym połapać? Np ukryjesz ogólny interfejs kolekcji, a ktoś będzie chciał np dodać implementację drzewa rozchylanego będącą kolekcją. I co wtedy? Gdzieś ten interfejs musi być opisany tak czy siak. A jeśli jest na miejscu w kodzie to wg mnie tym lepiej.

Wspomniałeś o UML, czy to nie jest dokumentacja? Duck typing wymaga dokumentacji, nie wymaga tworzenia jawnej hierarchii. Zresztą co za problem, Python ma metody abstrakcyjne (dzięki metaklasie), można "interface'y" z powodzeniem tworzyć. Od 3.0 istnieją adnotacje funkcji, nie są walidowane, to rozszerzenie składni na potrzeby dekoratorów etc. Dzięki nim i/lub dekoratorom oraz metaklasom można pełne statyczne typowanie funkcji, składowych i metod osiągnąć, zmienne lokalne wymagają nieco więcej zachodu. Dla przykładu Zope bardzo ciasno się z typami obchodzi, ma nawet elementy design by contract.

Wibowit napisał(a)

Języki dynamicznie typowane jak ten Python z założenia nie są projektowane z nastawieniem na jak największą wydajność

To coś jak Scala, gdzie grube tony hacków na JVM potrafiły być kilkanaście-kilkadziesiąt razy wolniejsze od normalnego rozwiązania w Javie. Przynajmniej za czasów 2.6 czy tam 2.7 było kilka wąskich gardeł, "to się zoptymalizuje", jak to wyszło to nie mam pojęcia, od tamtego czasu nie miałem potrzeby niczego na JVM płodzić. Jython taki poziom reprezentował, że wolałem się Scali poduczyć. Ile procent oprogramowania naprawdę potrzebuje gigantycznych mocy przerobowych, jak często wydajność implementacji języka jest zauważalnym problemem w porównaniu do ogólnej wydajności systemu i bazy danych?

MSM napisał(a)

Reduce, apply i map twoim przyjacielem. Tylko z niewiadomych powodów miały zostać (oprócz map) usunięte z pythona 3.0 (nie one jedyne, zgodność wsteczna między wersjami pythona jest traktowana dość lekko). Czy tak się stało - nie wiem, ale ideone twierdzi że tak (http://ideone.com/T64QE)

Najpierw Guido chciał usunąć wszystko razem z lambdami, potem lambdy zostały. Nic z języka nie usunięto całkowicie, w 3.0 przeniesiono do modułu itertools. W praktyce są to odpowiedniki izip, imap i ifilter z 2.x, są generatorami. map i filter są względnie bezużyteczne od czasu wprowadzenia generatorów i list comprehension, efektywniejszych i czytelniejszych rozwiązań. Jedynie na "generatorowe" reduce nikt pomysłu nie ma.

MSM napisał(a)

w pythonie istnieje operator (?) __len__ służący do wyciągania 'długości' dowolnego obiektu. funkcja len tylko go zwraca.

Zgodnie z "tradycją" metody specjalne pozostawia się samemu Pythonowi, są dla niego, dla użytkownika końcowego są wrappery czy operatory (ew. obiekty z modułu operator). Z jednej strony to zaszłość, z drugiej konsekwentnie jest to kontynuowane, jeżeli coś funkcjonuje wyłącznie "kaczo" poprzez metody specjalne (coś w rodzaju niejawnego interface'u), jak tworzenie iteratorów czy krok generatora/coroutine, to dostaje swojego helpera (ten np. obsługuje pewne klasy wyjątków, czy robi dodatkową inicjalizację lub zapewnia optymalizację). Podział na publiczne "generyczne" API i wewnętrzne metody nie wszystkim musi się podobać, ale służył ujednoliceniu mechaniki przy jednoczesnym unikaniu tworzenia zbędnych hierarchii. Użytkownik korzysta z wbudowanych funkcji, nie obchodzi go, co pod maską siedzi. Dla przykładu forma with korzysta z metod __enter__ i __exit__, które z przyczyn oczywistych nie powinny być używane bezpośrednio.

0

Duck typing wymaga dokumentacji, nie wymaga tworzenia jawnej hierarchii.

W przypadku OOP dokumentacja się "sama tworzy" z kodu. Javadoc/ scaladoc/ itd jest wiele generatorów dokumentacji czy UMLa z kodu OOP.

To coś jak Scala, gdzie grube tony hacków na JVM potrafiły być kilkanaście-kilkadziesiąt razy wolniejsze od normalnego rozwiązania w Javie. Przynajmniej za czasów 2.6 czy tam 2.7 było kilka wąskich gardeł, "to się zoptymalizuje", jak to wyszło to nie mam pojęcia, od tamtego czasu nie miałem potrzeby niczego na JVM płodzić. Jython taki poziom reprezentował, że wolałem się Scali poduczyć.

Generalnie czasem nadal wydajność kuleje, ale często kod Scalowy jest szybszy od Javowego (czasem/ często to pojęcia względne ;) ). Ponadto nowsze JVMy mają optymalizacje typu Escape Analysis, które redukują miejscami narzut obliczeniowy spowodowany tworzeniem lokalnych obiektów niemal do zera.

http://shootout.alioth.debian.org/u64/which-programming-languages-are-fastest.php

0

Ja moze tylko dodam o module abc w pythonie, ktory definiuje pare 'interfejsow' dla kolekcji i typow numerycznych, dekoratory @abstract, @abstractproperty i podobne, oraz metaklasy ktore narzucaja 'sprawdzanie typow'. Jak sie chce to mozna tego uzywac, z automatu, jak sie nie chce to nie. Piszac metody mozna sprawdzac czy dane obiekty 'implementuja' dany interfejs lub dana klase abstrakcyjna, mozna to zrobic rowniez z automatu dekoratorem.
Ogolnie ciekawie sie czyta rant krolika ktory sie okazuje nijak ma sie do rzeczywistosci. Jak to moj kolega opisal kod scali ktory zobaczyl u mnie w IDE i w kilku postach ktore opisywaly jakies tam costam ktore mu tlumaczylem: 'executable ASCII art, ktore przypomina mi czasy jak pisalem w perlu'. O wypocinach wibowita typu "Scala to Scalable Language wiec jest skalowalny" pozostawie bez komentarza, a czytam to juz i tak w ktoryms kolejnym poscie. Panie, czas zmienic plyte.

0

Mam strasznie słabą pamięć, więc wolę polegać na podpowiedziach w IDE i podkreślaniu błędów niż ciągle zerkać do dokumentacji czy odpalać program tylko po to, aby się dowiedzieć że zastosowałem złą konstrukcję. Inaczej mówiąc, mam awersję na wszelkie języki, które mają kiepskie podpowiedzi w IDE czy kiepską kontrolę typów w czasie kompilacji.

0

Python moim zdaniem jest dobrym językiem skryptowym. Mógłby być alternatywą dla JavaSciptu w HTML5. Obiektówka w JS mi się bardzo nie podoba.
Python jako język programowania całych aplikacji: zależy. Widziałem kilka aplikacji napisanych w całości w Pythonie, złe nie były. Działały lepiej od flasha (czy coś może chodzić gorzej?)

Blender jest przecież też w dużym stopniu oskryptowany w Pythonie, ale sam program jest napisany w C. I to moim zdaniem jest dobre wykorzystanie Pythona.

Co do nauki: podstawy są proste, a sam język uczy dobrych nawyków estetycznych (wymusza je).

BTW. da się Scalę użyć jako ScriptEngine w Javie, czy w jakimkolwiek innym języku, tak jak Jython? Bo nigdzie nie widziałem takiego zastosowania.

Podsumowując NIE MA żadnego najlepszego języka programowania. Każdy ma swoje zalety i wady. Zdaniem maniaków sprzed 20 lat najlepszy jest assembler, ale życzę im powodzenia przy szybkim kodzeniu na zamówienie na kilka platform jednocześnie.

0

http://www.artima.com/scalazine/articles/twitter_on_scala.html/

Z tego artykułu akurat wynika, że tylko web-front jest pisany w Scali (wcześniej mieli go w Ruby więc w sumie nie dziwie się, że odczuli poprawę). Dalej tylko pisze, że "mają w planach" przepisać reszte na Scale (a w planach to sobie mogą mieć, oceniam co na razie jest zrobione).

http://www.scala-lang.org/node/6436

Tutaj z kolei wygląda poważniej bo piszą, że używają Scali do analizowania grafów połączeń między znajomymi. Piszą również, że stworzyli do tego framework, który nazywa się Norbert. Szybkie googlowanie o tym frameowrku daje w rezultacie taką stronę:
http://sna-projects.com/norbert/
na której piszę, że Norbert jest nakładką na ZooKeepera, który z kolei służy do zarządzania rozproszonymi frameworkami, takimi jak Hadoop (dokładniej to przechowuje metadane o różnych serwisach). Czyli tak jak mówiłem, pierdoła, która co najwyżej leży obok algorytmów przetwarzających sieci społecznych.

0

jeśli ktoś woli szybko nauczyć się języka programowania to niech wybierze Pythona ale na nim nie zaprzestanie. Python jest dość prosty i dla "krótkich" programów przy większych czasami można gubić się przy tych wcięciach (jednak wolę klamerki no ale cóż ;D) natomiast dalej po Pythonie to Java / C++ / C# /whatever*

*- nie asm !

0

BTW. da się Scalę użyć jako ScriptEngine w Javie, czy w jakimkolwiek innym języku, tak jak Jython? Bo nigdzie nie widziałem takiego zastosowania.

Była dyskusja o tym na 4p niedawno i wtedy się nie dało, albo wymagało to jakichś hacków. Być może dałoby się skorzystać z tego: http://lotrepls.appspot.com/

Tutaj z kolei wygląda poważniej bo piszą, że używają Scali do analizowania grafów połączeń między znajomymi. Piszą również, że stworzyli do tego framework, który nazywa się Norbert. Szybkie googlowanie o tym frameowrku daje w rezultacie taką stronę:
http://sna-projects.com/norbert/
na której piszę, że Norbert jest nakładką na ZooKeepera, który z kolei służy do zarządzania rozproszonymi frameworkami, takimi jak Hadoop (dokładniej to przechowuje metadane o różnych serwisach). Czyli tak jak mówiłem, pierdoła, która co najwyżej leży obok algorytmów przetwarzających sieci społecznych.

A ZooKeeper i Hadoop są napisane w Javie. Po co je przepisywać do Scali, skoro Scala idealnie współpracuje z Javą? W Scali piszą swój, nowy kod i to jest rozsądne rozwiązanie. Przepisanie Hadoopa do Scali byłoby bardzo drogie, a nie wniosło by raczej wielu zalet. Poza tym to nie Twitter utrzymuje Hadoopa, więc powinno im wisieć w czym jest napisany o ile dobrze się integruje ze Scalą.

0

A ZooKeeper i Hadoop są napisane w Javie. Po co je przepisywać do Scali, skoro Scala idealnie współpracuje z Javą? W Scali piszą swój, nowy kod i to jest rozsądne rozwiązanie. Przepisanie Hadoopa do Scali byłoby bardzo drogie, a nie wniosło by raczej wielu zalet. Poza tym to nie Twitter utrzymuje Hadoopa, więc powinno im wisieć w czym jest napisany o ile dobrze się integruje ze Scalą.

Zgadzam się z tym co napisałeś. Tyle że po co gadać jak to LinkedIn jest w Scalii pisany, bo napisany to jest jeden komponent, który tak na prawdę klei funkcjonalność innych serwisów. Czysta propaganda na tej scalowej stronce jak i w wypowiedziach Królika (nie wiem czy świadomie czy po prostu nie przyjrzał się zbytnio sprawie). Tak samo można pisać jaki to Python jest zajebisty bo go google używa, a przecież google stworzył najlepiej skalowalny system (szczegół że core tego systemu jest pisany w C++).

0

Z codziennego uzytku, pythonowych appsow to uzywam Calibre (konwersja dokumentow na rozne formaty, zebym mogl czytac np epub na kindle) oraz Mercurial.
W Javie dla mnie killerem jest Serviio, serwer DLNA ktory sle mi na kino domowe filmy avi, matroska i cokolwiek innego mi sie zachce, dodatkowo bez kabli.
W scali nie ma nic dla mnie poki co ;d Nie mam kont na FB, Twitterze czy innych Linkedinach, jestem aspoleczny.

A teraz czekam na bashing.

1 użytkowników online, w tym zalogowanych: 0, gości: 1