Szukaj
Logowanie
Nawigacja
Wersja RSS
Kto jest online
Aktualnie online 0 users i 13 guests.
Śr, 2006-02-01 14:32 — climbus
Ostatnio na pl.comp.lang.python nawiązała się dyskusja, która w dużej mierze zeszła na tematykę Agile Programming. Wg jednego dyskutanta Java nie jest Agile i mniej nadaje się do metodologii takich jak Extreme Programing niż Python lub Ruby.
Często cytowaną książką w wątku jest Beyond Java, Bruce Tate'a.
Jak z tym jest waszym zdaniem? Czy języki dynamiczne wyprą statyczne? Czy Java jest agile?
Szczególnie interesują mnie opinie ludzi, którzy pracują (pracowali) w obu obszarach (Java i Python lub Ruby).
- climbus's blog
- Login or register to post comments
- 7226 odsłon
Comments
zreszta podoba mnie sie to po
zreszta podoba mnie sie to podejscie do sprawy - kolejny frazes zaslyszany lub przeczytany w sieci i odrazu 500000000000 znaczen - zupelnie jak w naszej polityce - All different - All equal ...
co ma jezyk do agile? agile t
co ma jezyk do agile? agile to metodologia:
Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
gdzie tu miejsce na jezyk?
Do tworzenia w danej metodolo
Do tworzenia w danej metodologii potrzebne są narzędzia. Język programowania jest takim narzędziem. Jedne narzędzia lepiej się sprawdzają inne gorzej. Co w tym dziwnego?
to moze wytlumacz na jakiej p
to moze wytlumacz na jakiej podstawie mozna stwierdzic ze narzedzie jest bardziej lub mniej agile. konkrety nie przypuszczenia czy puste hasla ... daj przyklad dlaczego!
To np: Agile opiera się na
To np:
Agile opiera się na reagowaniu na zmiany, więc potrzebne jest narzędzie które na to pozwoli. Jaki język jest bardziej elastyczny? Niewiem, dlatego zadałem to pytanie.
Zastanawiam się czy Java jako język kompilowany, w którym przetwarza się dużo kodu jest na tyle elastyczna aby szybko reagować na zmianę wymagań.
Z drugiej strony czy w językach dynamicznych jest możliwy zaawansowany refaktoring?
Cechy języka i dostępność narzędzi mają tu bardzo dużo do powiedzenia.
to raczej nie elastycznosc je
to raczej nie elastycznosc jezyka tylko elastycznosc implementacji - nie ma znaczenia czy piszesz w javie, pythonie, c czy perlu - jak kod jest gniot to niewazne czy jest to kompilat czy skrypt
uzywajac np. vi - i piszac w kod w javie i pythonie - szybciej pisze sie w pythonie - nie trzba javac -cp balh bla .... ale tak zaawansowanego IDE jak netbeans idea czy eclipse dla pythonga nie widzalem - tylko jakies proste wtyczki czy podswietlacze skladni
ludzie to jakosc kodu odpowiada za szybkosc reagowania na zmiany, sposob w jaki zostalo zaimplementowane dane rozwiazanie ma znaczenie a nie to czy po wklepaniu kodu do uruchomienia potrzeba 2 czy 15 komend bo to da sie zautomatyzowac, uproscic (make, ant, maven czy inne srodowisko)
Java jest mniej agile do Rubiego
Od jakiegoś czasu bardzo często używam języka Ruby i jeśli chodzi o takie na przykład pisanie testów jednostkowych to muszę przyznać, że w Rubym dopiero zaczyna to mieć większy sens. Testy w nim naprawdę pisze sie szybko, podobnie jak implementuje rozwiązanie. Jako, iż jest to język dynamiczny to bardzo łatwo można w nim pisać własne mocki, bez których tak naprawdę większości testów się nie napisze.
To co zawsze nie podobało mi się w Javie to to, że zanim coś się w niej uruchomi to trzeba naklepać mnóstwo kodu. Chodzi mi tu o to, że bardzo mało klas w "czystej" Javie nadaje się tak naprawdę do użytku. Mało tego, wiele klas nie czytając dokumentacji odnośnie ich nie wiadomo do czego służy - to jest właśnie największa wada Javy - zanim zrobisz, przeczytaj 5 stron javadoca, z którego i tak niewiele się dowiesz. Dlatego też nie wyobrażam sobie w ogóle pracy bez użycia Jakarta Commons.
Mówię tu także o 30 rodzajach list/tablic, czy 50 strumieniach :) To niepotrzebnie wymusza na programiście zastanawianie się co wybrać, podczas gdy on chce tylko zaimplementować problem, a nie od razu robić super szybki program. Dlatego wg mnie w ogóle nie powinno być typów prostych - wiem, wiem... przez to Java jest szybsza... ale trzeba pamiętać ze również programista jest znacznie wolniejszy;)
Podsumowując Java jest świetnym językiem programowania, jednak nie nadaje się (i nigdy nie nadawała) do małych a nawet średnich projektów. Jest jednak idealnym językiem dla molochów - korporacji, które tworzą duże systemy i zatrudniają dziesiątki programistów. Jednak jak to bywa w korporacjach tam się raczej nie podchodzi do problemu poprzez XP :)
---
Pozdrawiam
Jacek Olszak
http://jacekolszak.blogspot.com
jesli chodzi o molochy - kazd
jesli chodzi o molochy - kazdy ma wtedy wypracowana wlasna metodologie - cykl zycia aplikacji - taka, by w przypadku awari dalo rade szybko to wszystko naprawic - to w czym sie pisze to tylko kwestia decyzji, piszesz, ze podoba sie ruby bo szybko mozna w tym cos wlasnego napisac - tak jak w perlu pythonie beanshellu ash bsh php czy innych skrypciakach - rownie dobrze mozna szybko pisac i w javie, c czy c++ - to kwestia API dostepnego dla programisty w srodowisku - jak czegos nie masz w rubym to piszesz czy szukasz gotowego? modul (code reuse) czy piszesz od nowa - podstawowe cechy korporacji to tanio, szybko i skutecznie
a podchodzac do watku o 30 rodzajach tablic czy 50 strumieniach - jak nie masz w jezyku podzialu typow danych - to po co do tego 20 roznych sposobow odczytu? zawsze sam decydujesz (albo i nie) co czytasz ze strumienia - binarke czy tekst
w javie jest 30 rodzajow tablic bo 15 jest synchronizowanych (do uzycia bezposrednio przez wiele watkow) a 15 nie jest synchronizowanych, nie wiem jak w rubym uzywa sie watkow - ale np w perlu to jakas masakra - jezyk fajny szybki tez mozna mocki szybko dziergac tylko jak przychodzi co do czego to wlasnie samemu musisz przyimplementowac te 15 rodzajow tablic albo mechanizm wymiany danych (ewentualnie szukac tego po cpanie) i okazuje sie ze taki perl pod wzgledem ilosci modulow itp nie odbiega wcale od javy, wrecz przeciwnie nawet ja przerasta - bo kazdy pisze wlasna implementacje - lepsza lub gorsza - i potem masz do wyboru co uzyc, tracisz cenny czas na szukanie opracowywanie itp
50 rodzajow strumieni - buforowane nie buforowane itp jedne wejsciowe drugie wyjsciowe - znow perl - tu jest zawsze jeden handler - jak go wczesniej otworzysz tak go uzywasz (wejscie , wyjscie , oba na raz ) - bufor ? jaki #%%%#% bufor? co w systemie ustawione to masz , masz coprawda magiczne $| i takie tam autoflusze i rozmiar bufora przed zapisem - ale ale - @%#$%@ globalnie - co ustawisz to wszystko tak ma, chcesz miec lepsza kontrole - no to szukasz albo piszesz
sorry to o czym wspomniales ma znaczenie jako preferencja osobista (mniej lub bardziej) programisty
tym razem inny wyciag :
Principles behind the Agile Manifesto
We follow these principles:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Continuous attention to technical excellence
and good design enhances agility.
Simplicity--the art of maximizing the amount
of work not done--is essential.
The best architectures, requirements, and designs
emerge from self-organizing teams.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
wybierz WLASCIWE narzedzie by cel osiagnac - jak masz obrabiac raporty tekstowe to uzyjesz do tego fortrana?, a jak liczyc sile wybuchu bomby jadrowej to wezmiesz perla? w kazdym jezyku da sie osiagnac cel - tylko - jakim kosztem ? jakim nakladem ? jak efektywnie ?
Working software is the primary measure of progress - a w jakim jezyku? wlasciwym do danego zadania ...
Agile
fajna dyskusja (kolejna do miliona), ino tylko jaki jest bezposredni tego zwiazek z agile? po kilku drinkach moge napisac w javie taki kod (ale prosta funkcjonalnosc), ktory jest w stanie pojac jedynie chuck norris. to nie jest agile.
zatem zapewniam Was, ze rowniez w Ruby moge zrobic zupelnego bochomaza. to tylko kwestia umiejetnosci (braku), ew. wiekszej ilosci alkoholu.
liznalem na razie tylko troche ruby, wiec ciagle pozostaje w niewiedzy, jak wygladaja narzedzia wspomagaja agile - dobre IDE, dokumentacje, framework do testow, etc. czyli to, co naprawde jest wazne.
google jest agile: wpisuje bohomaz: 1080 wynikow. wpisuje bochomaz: 6,850. walic spellchecker.
Dlaczego Java?
Niedawno zacząłem pasjonujące studia z Java. Postanowiłem zrezygnować z technologii w której pracuje obecnie, dla czegoś lepszego. Rozważałem Python (Zope), Rubby (on Rails), Perl - wszystko pod kątem aplikacji WWW. Wybrałem Jave. Dlatego:
1. Enterprise Java, EJB3, JSP2,
2. szybkość działania, skalowalność,
3. dostępność certyfikowania, (certyfikowanie jednej osoby jest bez sensu, ale certyfikowanie zespolu jest bardzo na miejscu)
4. znakomite książki wprowadzające, np.: z serii HeadFirst.
Nie wybrała bym Javy, ze zwględu na składnie tego języka. Składniowo to od Javy lepsze jest PHP5 (mozna napisac krotszy kod ktory robi HelloWorld). Pisanie programu to tylko ułamek czasu potrzebny na stworzenie programu. Najwięcej czasu potrzeba na myślenie.
Hello world i wydajność
Ehh, Hello world jako wyznacznik jakości języka. Ta dzisiejsza młodzież.
Argumenty, które podajesz za Javą są bardzo ważne, chociaż większość z nich ma znaczenie bardziej biznesowe, niż ściśle technologiczne (co nie znaczy, że to złe argumenty, wręcz przeciwnie; skądś na chleb trza mieć $). Skalowalność i wydajność oczywiście to konrety, które dla wielu ludzi po prostu zmuszają do pisania w Javie - i dobrze. Zawsze twierdziłem i twierdzę, że im szybsze narzędzie (język+kompilator), tym cykl developerski szybszy, bo szybsze testowanie.
HelloWorld
Jako "HelloWorld" rozumiem aplikacje ponizej 150godzin pracy.
Zealous Zack
BTW zobaczcie http://www.hacknot.info/hacknot/action/showEntry?eid=81, Zealous Zack: "He ... worships at the church of Agile". W ogóle cały ten Zealous Zack mi się z kimś kojarzy, ale to już inna historia ;)
Istnieje sporo edytorów wsp
Istnieje sporo edytorów wspomagających pisanie w Ruby i Rails. Za najlepszy uchodzi TextMate na OS-X (są nawet tacy co kupują minimaki aby go używać). Moim faworytem pod win32 jest Arachno IDE, potem RadRails. B. dobry jest też RDE. Więcej: http://wiki.rubyonrails.pl/rails/show/faq-ide.
Dokumentacja jest b. dobra. Na stronie domowej Railsów znajdziesz wszystko co potrzeba. Jest pełne API, manuale, recepty, FAQ, kupa świetnych filmów, które chyba najlepiej pokazują jak co używać.
Rails automatycznie generując kontroler czy model generuje też wszystkie pliki do unit testów i testów funkcjonalnych. Spod Arachno IDE masz wbudowaną kolorową przeglądarkę klas i modułów zainstalowanych w systemie. Automatycznie też potrafi generować dokumentację z kodu (RDoc). To b. potężne narzędzie. Cała strona z API Railsów została automatycznie wygenerowana przez RDoc: http://api.rubyonrails.org/.
Beyond Java
..ostatnio czytałem komentarz Eckela, wielkiego zresztą zwolennika języków skryptowych, w którym stwierdził, że książka Tate'a to chłam, a autor stawia tezy na podstawie własnych sympatii, a nie z posiadanej wiedzy.
Tak mi się przypomniało :)
a wracając do tematu okropnie nie lubię języków dynamicznych. ja po prostu lubię jak wszystko sprawdza kompilator. Moim zdaniem weryfikacja w czasie kompilacji powinna posunąć się znacznie, znacznie dalej.
Oczywiście języki dynamiczne mają bardzo dużo fajnych zastosowań, ale nie wyobrażam sobie pisanie w nich aplikacji typu enterprise ;)
Cheers!
art.
>ja po prostu lubię jak wszy
>ja po prostu lubię jak wszystko sprawdza kompilator.
Kompilator sprawdza tylko trywialne bledy. Nawet blednego rzutowania typow nie umie wylapac. Skoro zaprojektowano wyjatek ClassCastException to znaczy, ze zalozono iz nie jest mozliwe stworzenie naprawde scislej kontroli typow. "Scisla kontrola typow", wielkie mi co. Wychodzi na to samo co w Pythonie, tylko ze wiecej z tym utrudnien, no i w Pythonie bledy podczas pracy programu sa znacznie latwiej wylapywane. A jak ktos uzyje sobe dodatkowo biblioteki pylinta (Eclipse + pydev to ma zalaczone) to sie nagle okazuje ze kod Pythona potrafi byc poddany dosc drobiazgowej analizie. Pylint wylapuje nawet nie uzyte zmienne i nie trzymanie sie konwencji wygladu kodu zgodnie z PEP8.
Zacznę tu bo nie lubie tych
Zacznę tu bo nie lubie tych wąskich komentarzy.
Musze chyba troche tu porzadku wprowadzić. jzabiell nie zapominaj że jesteś na forum poświęconym Javie, więc głoszenie herzji :), że coś może być lepsze od Javy jest co najmniej nie na miejscu :), a napewno grozi powszechnym obużeniem i ignorancją względem twojej osoby.
Wracjąc do meritum. Każde narzędzie o ile działa, znajdzie swoje zastosowanie, zarówno języki statyczne jak i dynamiczne mają swoją niszę w której mają zastosowanie.
Przykładowo, nie ma narazie możliwośći aby stystemy operacyjne czy wysokowydajne aplikacje (takie np. jak gry) pisać w innych językach niż natywne (przynajmniej częściowo). Co prawda zainstalowałem system operacyjny napisany w Javie (JNode) ale spora część tego projektu napisana jest w asamblerze. Swoją drogą nie słyszałem o systemie operacyjnym napisanym w Pythonie czy Ruby :).
Python powstał na początku lat 90, czyli jest juz nastolatkiem, to dość dużo, zwarzywszy że Java jest w podobnym wieku, można zaryzykować stwierdzenie że Python rozwija się co najmniej wolno (ja bym powiedział w żułwim tempie). Java ma swoje zastosowanie nie tylko w aplikacjach enterprisse (gdzie chyba ma największy udział), ale tworzy się aplikacje desktopowe (choć to trudno zauważyć :)), nie wspominając o tysiącu rużnych innych urządzeń mających w sobie JVM. Świat wielkich korporacji jakoś nkie zachwycił się Pythonem czy Ruby. Wiecęj brnie jeszcze bardziej w statyczne języki, choćby przykład C#. Nie mówiąc już o wsponianym wczesniej przykładzie ActionScripta. Zaryzykuje stwierdzenie że komercyjne instytucje 'olały' Pythona. A zchodząc z korporacji na ziemię, powiedzcie mi ile w ostatnim tygodniu widzieliscie ofery pracy dla programisty Pythona.
Te 'wspaniałe' narzędzia nie są chyba jednak bez użyteczne. Ba osobiscie widzę dla nich zastosowania :). Podobnie jak PHP, myśle że znajdą swoją niszę w podobnych jak on zastosowaniach, czyli niewielkie, robione szybko, pod jednego klienta, aplikacje typu napisz i zapomnij.
Jeśli chodzi o aplikacje średnie i duże np. takie tworzone przez kilkudziesięcio osobowe zespoły. To narazie zwolennicy Pythona czy Ruby'ego mogą nie martwić się nagłym wielkim obciążeniem pracą. Nie ma ani woli anie argumentów przemawiających do firm (np. mojej :)) które miały by je skłonić do przejścia na te technologie, a i w najbliższej przyszłości się na to nie zanosi.
A o popularności narzędzia jednak decyduje rynek. Javowcy spijcie spokojnie. Wielki brat czówa :)
P.S.
jzabiell widze ze wygżebałeś wątek z przd pół roku, to już wygląda na jawną prowokację :)
Co do systemu operacyjnego, t
Co do systemu operacyjnego, to kilka chyba nawet napisano w Pythonie. Nie pamiętam wszystkich, ale tak na szybkiego znalazłem googlami to: http://freshmeat.net/projects/lsystem/
Co do firm, to optyka zmienia się wraz ze zmianą kraju. Rośnie ilość ofert dla programistów Pythona i Ruby. A i w PL Python pełnił b. ważną rolę w mojej poprzedniej firmie.
Nic nie wygrzebywałem. Dziś dostałem link do tego wątku.
os w pythonie
http://freshmeat.net/projects/lsystem/
To nie jest OS w Pythonie, tylko implementacja L-systemów :D :D :D
Jeśli kogoś interesuje prawdziwy OS w Pythonie (w co wątpię), zobaczcie uuu:
http://unununium.org/
Jest tam chyba nawet jakiś działający (bootujący się?) kod.
OS w pythonie
OS w Pythonie. Beka.
Nawet blednego rzutowania typow nie umie wylapac???
Chyba nie obalisz wszystkich zalet statycznego typowania stwierdzeniem, że jest ono nic nie warte, bo jak rzutujesz to robisz to w ciemno, bądźmy poważni...
A jak sobie w ogóle wyobrażasz statyczne sprawdzenie rzutowania? Po to właśnie wymyślono rzutowanie, żeby można było podmienić typ tam, gdzie się nie da go wywnioskować. Dość żadko się to rzutowanie stosuje, a od Javy w wersji 5 to już BARDZO BARDZO żadko w stosunku do miejsc, gdzie zachodzi statyczna kontrola.
Nic nie chcę obalać. Po pro
Nic nie chcę obalać. Po prostu, statyczna weryfikacja typów jest wg mnie przereklamowana. Ma ona oczywiście pewne zalety, ale także i wady. Więc nie ma co się egzaltować. BTW, paradoks, ale uczenie się Javy wybił mi z głowy sam Bruce Eckel książką "Thinking in Java". To przez niego dowiedziałem się o Pythonie. Ostatnio zgłębiam jednak Rubiego. :)
Jak pisałem poniżej nawet j
Jak pisałem poniżej nawet języki interpretowane skłaniają się ku statycznemu weryfikowaniu typów. Np. Taki JavaScript 2.0 opiera się również na ECMAScript 4. Inna sprawa żę narazie nie ma przeglądarki obsługującej ten standard.
A jeśli chodzi o Jave to rzutowania praktycznie nie trzeba wogóle uzywać programując w 5'tce, kwestja stworzenia dobrego kodu.
Ja sobie niewyobrażam napisania dużej aplikacji w języku typu Python czy Ruby, nie mówiąc juz o utrzymaniu takiej aplikacji i powrocie do kodu po roku albo dwóch.
Pozatym sprawdzanie błędów nie odnosi się tylko do trywialnych sytuacji. Biorąc pod uwagę najlepszy obecnie edytor dla Javy (IDEA) to wykrywanie nie używanych zmiennych czy metod to pikuś, zajżyj tutaj, a to i tak nie wszystko. Generacja kodu, czy sama pomoc w edycji od najprostrzego CTRL+SPaCE podpowiadającego metody, pola itp., do generacja pętli dla zadeklarowanych pól i zmiennych będących Iterable. Pozatym trzeba wspomnieć że te dobrodziejstwa nie dotyczą już tylko kodu javy, ale także związanych z nią technologji jak resoursy, jsp (np. podpowiadanie składowych scope'a), itp. Nikt mi nie powie że warto z tego zrezygnować, na korzyść skrócenia kodu.
Wspominasz wady statycznej weryfikacji typów. Przytocz je.
Wspominasz wady statycznej weryfikacji typów.
> A jeśli chodzi o Jave to rzutowania praktycznie nie trzeba wogóle
> uzywać programując w 5'tce
Nie da się jednak go zupełnie wyeliminować.
> Ja sobie niewyobrażam napisania dużej aplikacji w języku typu
> Python czy Ruby, nie mówiąc juz o utrzymaniu takiej aplikacji
> i powrocie do kodu po roku albo dwóch.
Co jak co, ale nie popełnię błędu twierdzą, że czytelność Pythona jest większa od Javy. Python był projektowany (jako chyba jedyny) na bazie naukowej analizy ergonomii. Jesli miałbym po roku wrócić do Pythona to żaden inny język nie pozwala na pisanie tak czytelnego i krótkiego kodu. No może tylko Ruby.
Co do podpowiedzi, to wiem że taki IDEA nie ma sobie równych i wiadomo że statyczne typowanie ułatwia stworzenie zaawansowanego systemu podpowiedzi. Jednak problem w tym, że w praktyce, Python czy Ruby rzadko potrzebuje aż takie narzędzia. Wystarczy to, co może Wing IDE czy SPE czy pydev. Duck typing + ogromna dynamika, doskonała introspekcja, możliwość podglądania obiektów z konsoli, docstringi na każdym miejscu są wystarczające.
> Wspominasz wady statycznej weryfikacji typów
Główna wada (nie jest to nic nowego) to większe koszty jakie statyczne typowanie wprowadza odnośnie procesu tworzenia oprogramowania. Dłużej trwa nauka takiego języka. Więcej trzeba się naklepać. Kod jest znacznie dłuższy. W większym kodzie łatwiej o błąd. Trudniej też go odszukać i poprawić. Co ciekawe, programiści Javy zwykle mówią, że i tak trzeba zapłacić koszty, prędzej czy później. (wg nich, oni płacą prędziej dzięki kompilatorowi który wyłapuje błędy w składni i literówki) To dziwne, ale w praktyce programiści Pythonam, czy Rubiego rzadko zostawiają błędy w kodzie z powodu pomyłki w pisaniu. Poza tym unit testy łatwo wyłapują sporo błędów których i tak kompilator nie wychwyci.
nie do końca się zgodzę z tym zdaniem:
Co ciekawe, programiści Javy zwykle mówią, że i tak trzeba zapłacić koszty, prędzej czy później. (wg nich, oni płacą prędziej dzięki kompilatorowi który wyłapuje błędy w składni i literówki)
Uważam, że pomyliłeś się w tym, co napisałeś w nawiasie.
Nie chodzi o to, że w takiej Javie prędzej się płaci dzięki kompilatorowi, chodzi o to, że aplikacja jest bardziej podatna na modyfikacje, nawet gruntowne. Powtórzę - pomoc kompilatora polega na tym, żeby szybciej napisać sam kod i wyeliminować trywialne błędy, ale to o czym się mówi, że pisząc aplikację w Javie płaci się na początku więcej dotyczy faktu, że łatwiej jest później prowadzić refakoring + bierzące modyfikacje bez narażanie się na przypadkowe rozbicia innych części kodu.
pomoc kompilatora polega na tym, żeby szybciej napisać sam kod
No tu to ty się pomyliłeś. Kompilator nie pomoże ci szybciej napisać kod, ale IDE. Wręcz przeciwnie, konieczność kompilowania kodu po każdej zmianie znaaaaacznie spowalnia kodowanie. Jak masz duży projekt, to każda taka rekompilacja to np. pół godziny wyrwane z życiorysu.
rekompilacja
Rekompilacja (java->bajtkod) jest robiona dokładnie tak samo, jak w pajtonie (i we wszystkich innych układach developerskich, np. C/C++ z mejkfajlami), czyli rekompilowane jest tylko to, co się zmienia.
Poza tym ze względu na wyższą wydajność kodu w Javie czy innych językach ze stat. typowaniem, cykl rekompilacja-testowanie przy pewnej skali projektu jest w gruncie rzeczy szybszy, niż np. w Pythonie, ponieważ po prostu błąd, jeśli jest, znajdziesz szybciej, bo aplikacja szybciej działa.
błąd, jeśli jest, znajdziesz szybciej, bo aplikacja szybciej
Nonsens. Szybkość nic tu nie zmienia. Jeśli błąd tkwi w jakimś elemencie kodu który jest używany dopiero jak klikniesz na jakąś opcję, to go tak długo nie zobaczysz, aż tam nie klikniesz. Robert, może by tak jednak wskoczyć na pl.comp.lang.python? Bardzo niewygodnie się tu klepie w tych okienkach.
szybkość a debugging
Oczywiście że zmienia. Jeśli masz kod przetwarzający kilka giga danych w kilku złożonych fazach (a taki nie tak dawno pisałem) i błąd pojawia się w drugiej fazie ze względu na nieprzewidziany wcześniej format danych wejść., to program napisany w C++ zdebugujesz dużo szybciej, niż taki sam w pythonie, dokładnie dlatego, że ten w C++ będzie 5-10 razy szybszy.
Programowanie to nie tylko klikanie w okienkach i stronki łebowe.
szybkość a debugging
To szczególny przypadek wielostopniowego przetwarzania danych. I jęz. statyczny czy dynamiczny nie ma tu nic do rzeczy. Po prostu tu kluczowa jest szybkość dojścia do kolejnego etapu mielenia logów. Programowanie to nie tylko przetwarzanie logów.
szybkość a debugging
Od tego, jaki wybierzesz język, zależy wydajność... A od tego dalej zależy w wielu przypadkach prędkość testowania. Dotyczy to w równym stopniu apl. standalone typu przetwarzanie logów, aplikacji GUI, jak i sajtów www. Kwestia skali po prostu.
+1
W zupełnosci popieram.
Kiedyś za 'namową' Eckela (W Thinking in Java namawia) postanowiłem spróbować Pythona "przed którym jest przyszłość". Nie przekonał mnie w zupełności. Podobnie było dość niedawno gdy zrobiło się głośno o Ruby. Przygody skończyły się szybko. Ja poprostu nie potrafię zrezygnować z CTRL + Space. :)
Pomysł z powrotem do notatnika nie jest dla mnie, a chyba nie tylko dla mnie. Macromedia we Flash'u MX 2004 wprowadziła drugą wersję języka ActionScript (podobnie jak JavaScript wywodzi się z ECMA Srcript), co zmienili, ano to że mozna (podkreślam "można") opkreślać typ pól, zmiennych i typ zwracany przez funkcje. Cytuje książkę "FLASH MX 2004 ActionScript, oficjalny podręcznik" :
Jak już wspomnieliśmy podpowiedzi podczas wprowadzania kodu to nie jedyny plus stosowania jawnych deklaracji. Wskazując typ danych przechowywanych w zmiennej, zaoszczędzasz mnóstwo czasu, który Flash musi poświęcić na jego samodzielne rozpoznanie. ... pozwala na zaoszczędzenie mocy obliczeniowej ... Jesli chcesz zwiększyć efektywność, stosuj jawne deklaracje typów. Wreszcie, jawna deklaracja typu ułatwia odnalezienie błędów w programie.
Chyba nie tylko ja widzę pozytywy w wpisywaniu odrobiny niepotrzebnego kodu który jednak bardzo ułatwia kodowanie. Jestem dysgrafem i często zdażają mi się literówki i nie wyobrażam sobie kodować bez CTRL + Space.
Pomysł z powrotem do notatnika nie jest dla mnie
Jakiego znowu notatnika?? Ty chyba nie widziałeś wysypu świetnych IDE do Pythona. Zobacz np. napisany w Pythonie SPE
(http://pythonide.stani.be/)
Albo świetny Eclipse+pydev, albo Eric3 (http://www.die-offenbachs.de/detlev/eric3.html) albo WingIDE (http://wingware.com/wingide). W życiu nie używałbym Notatnika. No już prędzej SciTe. Więcej tu: http://wiki.python.org/moin/IntegratedDevelopmentEnvironments i tuhttp://wiki.rubyonrails.pl/rails/show/faq-ide
Notatnik to tylko przenośnia
Notatnik to tylko przenośnia na określenie tychże właśnie narzędzi :). Jeśli mi zaprezentujesz narzędzie które ma porównywalną funkcjonalność do np. IntelliJ IDEA, to może przyznam ci rację. Ale zdania i tak nie zmienię, "JAVA i długo długo nic" :)
Pozdrawiam
Notatnik to tylko przenośnia
Bardzo kiepska przenośnia. Porównywanie do WingIDE czy SPE jest śmieszne. Tam masz wszystko co trzeba. Po prostu Java potrzebuje mocniejszych narzędzi, bo jest mniej dynamiczna, bardziej toporna, poza tym wynika to z innej filozofii. Np. tworzy się "na wszelki wypadek" niepotrzebny w danym momencie kod. Takich praktyk nie ma w jęz. dyn. bo nie mają one aż takich ograniczeń. Np. nieśmiertelne settery i gettery które zwykle wszyscy dorzucają do klas.
gettery i settery
nie mają NIC wspólnego z dynamicznym czy statycznym typowaniem.
To jest pewna konwencja (wg mnie raczej słuszna), ale tak samo możesz ich nie stosowac w Javie jak stosować w dowolnym innym obiektowym języku.
tak samo możesz ich nie stosowac w Javie
No tu się różnimy. Dla mnie tworzenie kodu który nie jest potrzebny (ale może kiedyś będzie), jest złą praktyką. Prowadzi do nadmiernego rozdmuchania kodu o nieużywane elementy. Ale to wynika z ograniczeń Javy, bo w jęz. dyn. możesz sobie to zmienić w dowolnym momencie (nawet na żywym obiekcie).
settery/gettery
Settery i gettery robi za Ciebie eklips/idea.
Tylko po co? Wiele osób z k
Tylko po co?
Wiele osób z kręgów Javy przyznaje, że używanie setterów i getterów w Javie jest po prostu złą praktyką.
akcesory
Po pierwsze, połowa argumentów tam podanych (refaktoring 1000 klas np) pada jeśli uwzględnić użycie nowoczesnego IDE. Dlaczego, o tym dalej.
Po drugie, autor najwyraźniej nie zdaje sobie sprawy, że settery/gettery nie są cukrem syntaktycznym (często zrównuje je z polami public), ale częściami kontraktu klasy, a jako takie mają ustalone typy, więc trudno narzekać, że jak zmieniamy kontrakt klasy, to nam się efektem domina wszystko sypie. Jeśli już, to jest to przytyk ogólnie do programowania OO. Zauważ też, że ten sam problem jest w każdym języku OO, w jednych powoduje wysyp na etapie kompilacji/IDE (co jest IMHO good), w innych żmudne losowe bugi w runtimie (w jęz. bez stat. kontroli typów, co jest w tym przypadku IMHO evil).
Tak samo można zbyć argument, że akcesory łamią enkapsulację danych. Akcesory są konwencją do tego, żeby ją łamać, ponieważ całkowicie hermetyczna klasa jest po prostu idempotenta i do niczego nie przydatna. Na tej samej zasadzie możnaby krytykować np. samochód, że nie jest bezpieczny, bo można nim wyjechać na drogę a tam są wypadki.
Propozycja autora ("Don't ask for the information you need to do the work; ask the object that has the information to do the work for you" - czyli w zasadzie Hollywood Principle) jest w tym kontekście niepoważna, bo stosowana konsekwentnie prowadzi do niezwykle skomplikowanego przepływu kontroli w kodzie, mimo że upraszcza oczywiście, zgodnie z jego intencją, przepływ danych. Takie podejście to jednak jakiś przesądny strach przed danymi i typami. Przepływ danych jest z reguły dużo łatwiej opanować (dokładnie dzięki statycznemu typowaniu, które głównie do tego służy), co daje efekty w postacji możliwości refaktoringu w IDE etc. Przepływ kontroli (w perwersyjnym języku OO "message flow") w kodzie jest dużo trudniejszy do analizy przez człowieka, nie mówiąc o maszynie (wchodzimy tu na grzązki grunt, bo własności kodu mogą bardzo łatwo przestać być rozstrzygalne, w przeciwieństwie do własności typów).
Fakt, że część problemów, o których on pisze - pomijając ich realną powagę - można rozwiązać, stosując aliasy typów, których Java, jako język o prostym bądź co bądź, systemie typów, nie ma. Nie wie ktoś tutaj ze speców czy Java 6 nie zamierza czasami ich wprowadzić?
Ostatnia sprawa jest taka, że settery/gettery są w bardzo wielu przypadkach po prostu częścią zewnętrznego API (beans np.), w której to sytuacji sprawdzają się bardzo dobrze.
Smutne to, że ten artykuł taki mało głęboki (np. jako alternatywa do akcesorów jest tam dużo machania rękami, mało konkretów), bo to ciekawy temat i możnaby go rozwinąć. Do tego komentarze o dodawaniu akcesorów "na wyrost" są po prostu jakieś niedorzeczne; żeby takich rzeczy nie robić, uczą na pierwszym roku informatyki, a jak ktoś tego nie rozumie to w ogóle nie powinien zaczynać programowania. Taka praktyka nie ma żadnego uzasadnienia ani teoretycznego, ani pragmatycznego.
dodawanie akcesorów "na wyrost"
Problem w tym, że jak ich nie dodasz "na wyrost" i tak sobie beztrosko będziesz tworzył duży kod, to co potem zrobisz jak trzeba będzie (załóżmy) np. logować każdą operację pobrania atrybutu? Musisz dodać getter. Ale z kolei jak dodasz, to załamie ci się kod w milionach innych miejsc gdzie ten atrybut jest odczytywany. Stąd developerzy javy profilaktycznie dodają te gettery aby potem nie mieć tego typu problemów.
A to prowadzi z kolei o innego problemu. Bo jak z def. zawsze dodajesz te gettery/settery a potem chcesz cokolwiek zmienić w klasie (np. ich nazwę) to lądujesz znowu w śmietniku milionów błędnych getterów i setterów, które musisz wyszukiwać i poprawiać w milionach miejsc. Takie zakładanie, że jak raz klasę zbuduję to potem jej nie będę ruszać, poza tym że jest sytuacją czysto teoretyczną i mało praktyczną, jest także dowodem na to, że Java słabo nadaje się do agile. Java jest mniej zwrotna, zakłada filozofię: "raz, dobrze zaprojektuj a potem nie ruszaj". Tylko kto tak tworzy kod, że nigdy nic nie musi w nim, poprawiać? Może jakiś geniusz. W praktyce zatem Java okazuje się dużą krową, która jak dobrze ją nakarmić, to daje zawsze mleko i mozna na niej polegać, ale jak trzeba ją przesunąć na bok, albo zmienić jej nawyki, to wykazuje bezwładność słonia i upór osła.
W zupełnie innej sytuacji jest np. Ruby. Tam po prostu nie masz żadnej możliwości dostania się do atrybutu klasy bez gettera/settera. Jest to wymuszone na poziomie języka. Cała operacja dodania gettera jest jednak b. uproszczona i nazwy getterów/setterów też są wymuszone na poziomie języka. Nie ma więc możliwości aby stworzyć metodę pobierającą atrybut "napis" o nazwie getNapis, get_napis czy pobierz_ten_ChoLerMny_NAPIS itp (na co zezwala Java). Setter oraz getter ma nazwę taką identyczną jak atrybut. :) To, plus opcjonalne używanie nawiasów dla metod, powoduje, że składniowo wygląda to tak, jakby ktoś bezpośrednio grzebał w atrybucie. Cała implementacja settera jest jednak ukryta i przezroczysta dla reszty kodu. Właściwie to mogę sobie nawet wyobrazić że jakas Java6 mogłaby przyjąć coś podobnego. Poniżej przykład jak to mniej więcej wygląda w Ruby:
class Remember attr_reader :msg def msg=(txt) @msg = txt end end x = Remember.new x.msg = "Ruby is cool;)" print x.msgPython podchodzi jeszcze inaczej. Tam możesz dobrać się do atrybutów klasy bezpośrednio lub przez gettera (czyli jak w Javie). Różnica jednak jest taka, że w Pythonie w ogóle nie musisz tworzyć bez sensu nic na wyrost. Jak chcesz coś więcej niż tylko prosty odczyt/zapis atrybutu to w klasie dodajesz gettera/settera który jest przezroczysty dla pozostałego kodu. Nic na zewnątrz się nie zmienia! Programiści Javy, którzy sięgają do Pythona tworzą zwykle koszmarki w Pythonie z powodu swych nawyków, które tu nie mają sensu. Python pozwala dodać settera tylko wtedy kiedy to jest potrzebne. I taka operacja jest całkowicie przezroczysta dla reszty kodu.
akcesory / atrybuty publ.
Poza tym można też argumentować, że w Rubym składnia akcesorów jest nie za bardzo czytelna, a konieczność dodawania ich dla każdej publicznie widzialnej własności to nadmiar, którego unikają np. Java, C++, ale też i Python.
Nieczytelna skladnia akcesorow w Ruby? :)
Ty w ogóle nie czytasz ze zrozumieniem. W Pythonie w ogóle nie trzeba dodawać "na zapas" żadnych akcesorów. Dodajesz je wtedy, i tylko wtedy, kiedy chcesz coś specjalnego robić w momencie operacji na atrybucie. I (uwaga, nie śpij) taka operacja jest przezroczysta dla reszty kodu! W przeciwieństwie do Javy, nie musisz nigdzie więcej nic poprawiać.
Zaś co do rzekomo skomplikowanej i nieczytelnej składni Rubiego odnośnie akcesorów, to ty się lepiej nie ośmieszaj. Dodanie obu akcesorów (gettera i settera) w Ruby sprowadza się do 1 linijki:
akcesory
A ile składni akcesorów jest w Rubym, może się pochwal?
Na załamanie się kodu w wielu miejscach masz zawsze IDE i automatyczny refaktoring i może być to nawet trylion miejsc (jeśli masz duży dysk hah), a nakład pracy człowieka jest i tak ten sam i bliski zera. Wszystkie zalety, o których piszesz w kontekście jęz. dyn. są też w Javie, tylko że kodu boilerplate nie klepie/refaktoryzuje człowiek, tylko automat.
Wprowadzanie natomiast akcesorów w jęz. dyn. to podpórki, a podpórki takie, jeśli się ich dostatecznie dobrze nie zdebaguje/przetestuje, po pewnym czasie się łamią. Łamliwość jest oczywiście większa, bo na etapie zmiany nie masz żadnych gwarancji statycznych.
Poza tym nikt nigdy nie twierdził, że akcesory w Javie służą do dodawania funkcjonalnośći aspektowej (takiej, jak logowanie); do tego są osobne narzędzia i rozszerzenia języka. No i są jeszcze adnotacje. Głównym zastosowaniem akcesorów są właśnie beansy.
Skomplikowana składnia Rubiego?
Składnia Rubiego odnosnie akcesorów jest bardzo prosta i czytelna. Możesz pisać normalnie tworząc metody
class X def msg @msg end def msg=(txt) @msg = txt end endMożesz też to skrócić, jak nie chce ci się klepać (i słusznie) do
Jest też skrót attr_reader i attr_writer który definiuje automatycznie gettery i settery dla atrybutów (możesz podać ich całą listę po przecinku) Cała reszta nie będzie dostępna. W Javie *musisz* wklepać settera, aby zablokować nadpisanie atrybutu. Przypominam że Ruby ma też zasięgi private, protected i public :)
Co do gwarancji statycznych to nie rozśmieszaj mnie. Kompilator przepuszcza niektóre błędne rzutowania który ci sypną wyjątkiem dopiero po odpaleniu krowy. A poleganie na IDE aby mi miliony miejsc poprawił jest śmieszne. Ja to zrobię w 1 miejscu w 10 sekund za pomocą vi :)