Python ssie

Odpowiedz Nowy wątek
2011-07-08 11:10
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.

Java ssie :P - Dr Zielu 2011-07-25 21:47

Pozostało 580 znaków

2011-07-08 11:27
O_o
0

o_O

Pozostało 580 znaków

2011-07-08 11:42
0x200x20
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.

Pozostało 580 znaków

2011-07-08 12:31
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.

Pozostało 580 znaków

2011-07-08 12:43
ofidyfil
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.

Pozostało 580 znaków

2011-07-08 12:54
ofidyfil
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.

Pozostało 580 znaków

2011-07-08 13:09
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.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 1x, ostatnio: Wibowit, 2011-07-08 13:10

Pozostało 580 znaków

2011-07-08 13:48
0x200x20
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.

Pozostało 580 znaków

2011-07-08 13:53
ofidyfil
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.

Pozostało 580 znaków

2011-07-08 14:13
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.

edytowany 7x, ostatnio: Krolik, 2011-07-08 14:32

Pozostało 580 znaków

2011-07-08 14:31
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ł.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 2x, ostatnio: Wibowit, 2011-07-08 14:33

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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