59 odpowiedzi na „Eclipse Indigo”

1. 

   aix_Wolna_Głupota

   23 czerwca 2011

   "W tym roku do pociągu załapały się 62 projekty rozwijane przez 408 deweloperów, składające się z 46 milionów linijek kodu."

   Licząc, że kodowali 220 dni w roku to na dniówkę wychodzi ponad 500 linijek kodu.

   Odpowiedz
   1. 

      abcman

      23 czerwca 2011

      Tylko jeśli od zera kodowali. Ale i tak wynik jest imponujący np. na tle Windowsa 2000 (o którym wiem), który składa się z 60 mln linii kodu. Oczywiście MS zatrudniał wtedy dużo więcej niż 408 osób.

      Odpowiedz
      1. 

         kSlmScetA

         23 czerwca 2011

         po 1. złożoność jest jednak większa w systemach operacyjnych a już na pewno funkcjonalność w win2k

         po 2. liczba linii kodu o niczym nie mówi, ani o jakości, przydatności, ani o włożonej pracy

         Odpowiedz
         1. 

            jarek

            24 czerwca 2011

            "po 2. liczba linii kodu o niczym nie mówi, ani o jakości, przydatności, ani o włożonej pracy"

            Otoz to, zalezy od kodera no i mocno zalezy od jezyka.
            Mozna klepac jak glupek w C setki linii, a mozna to samo elegancko opedzic 10-ma linijkami Pythona.

            Srednia na projekt wychodzi prawie milion linii kodu – jak dla mnie to porazka.

            Odpowiedz
            1. 

               pijaczek

               24 czerwca 2011

               Python jest językiem, właśnie rozlazłym ze względu na to, że wręcz wymusza pisanie wszystkiego w osobnych linijkach z głębokimi wcięciami i przez to mało czytelnym. Kod tych projektów był pisany w Javie, co i tak wielu uważa za błąd ze względu na wydajność (Python tylko by pogorszył sprawę, bo w przeciwieństwie do naturalnie wielordzeniowej Javy, Python działa na jednym wątku (nawet jak użyjesz wielowątkowości to będzie się wykonywać jedna instrukcja na raz dzięki GIL w oficjalnej implementacji Pythona), jest jeszcze bardziej pamięciożerny i jest w dodatku językiem skryptowym przez co wydajność byłaby nie do przyjęcia).
               Język praktycznie nie ma żadnego znaczenia jeśli chodzi o ilość linii (a jeśli już to C jest tu najmniejszy, bo dosłownie wszystko jeśli chcesz możesz mieć w jednej linii (mało czytelne, ale można) – jeśli chcesz wydajność, krótki czytelny kod to wybierz C++ (poza zaletami, samego języka w C++0x i bibliotece Boost masz wszystko to co znasz z Pythona (poza jego wadami))).

               W ilości linii kodu ważny jest sam programista i dany problem – zależnie od programisty w danym języku można coś napisać na kilka/kilkadziesiąt lini lub setki/tysiące. Jednak ilość kodu też zależy od problemu, a IDE to bardzo skomplikowany program i kodu do napisania jest mnóstwo nawet pisząc bardzo zwięźle.

            2. 

               jarek

               24 czerwca 2011

               "Python jest językiem, właśnie rozlazłym ze względu na to, że wręcz wymusza pisanie wszystkiego w osobnych linijkach z głębokimi wcięciami i przez to mało czytelnym."

               I wlasnie dzieki wymuszeniu spojnych wciec (ktorych glebokosc mozesz sobie
               dowolnie wybrac) jezyk ten jest bardzo czytelny. Sam pare lat temu (jako zatwardzialy
               C-owiec i Perlowiec) krzywilem sie na takie podejscie Pythona, bylem w grubym bledzie.
               To sie zaskakujaco dobrze sprawdza na dluzsza mete.

               "Kod tych projektów był pisany w Javie, co i tak wielu uważa za błąd ze względu na wydajność"

               Wydajnosc standardowego JVMa jest bardzo dobra, ktos kto marudzi,
               ze soft na tym odpalany jest wolny, nie bardzo wie o czym mowi. FUD.

               "naturalnie wielordzeniowej Javy, Python działa na jednym wątku (nawet jak użyjesz
               wielowątkowości to będzie się wykonywać jedna instrukcja na raz dzięki GIL w oficjalnej
               implementacji Pythona)"

               Java nie jest "naturalnie wielordzeniowa", zasadniczo to w Javie slabo sie pisze
               concurrent programming. W Pythonie nie lepiej, ale w Pythonie to implementacja
               jest skopana przede wszystkim.

               "Język praktycznie nie ma żadnego znaczenia jeśli chodzi o ilość linii"

               Niektorzy maja inne zdanie na ten temat:
               http://page.mi.fu-berlin.de/prechelt/Biblio/jccpp…

               "Designing and writing the program in Perl, Python, Rexx, or Tcl takes no more than
               half as much time as writing it in C, C++, or Java and the resulting program is only half as long."

               "(a jeśli już to C jest tu najmniejszy, bo dosłownie wszystko jeśli chcesz możesz mieć w jednej linii"

               To zart, czy naprawde merytoryczny argument?

               "krótki czytelny kod to wybierz C++ (poza zaletami, samego języka w C++0x i bibliotece Boost masz wszystko to co znasz z Pythona (poza jego wadami)))."

               Z ciekawosci, jak ponizsze wyklepiesz zwiezle w C++?
               (podaje plik int/linijka i jako argument "funkcje(x)", dostaje liste wynikow).

               #!/usr/bin/python
               from sys import stdin, argv
               for line in stdin:
               x = int(line)
               print eval(argv[1])

               "W ilości linii kodu ważny jest sam programista"

               To napisalem w poscie powyzej.

               "Jednak ilość kodu też zależy od problemu"

               Tu sie zgodze, generalnie dobrze jest znac pare jezykow z roznych polek.
               C++ i Java takimi raczej nie sa (choc widze, sporo ludzi tutaj tak wlasnie mysli).
               Szersza perspektywa zwieksza szanse siegniecia po lepsze narzedzie.

            3. 

               jarek

               24 czerwca 2011

               Eh, poszatkowalo kod oczywiscie. Jeszcze raz, przeformatowane, z przykladem uzycia:

               $ cat blah.py
               #!/usr/bin/python
               from sys import stdin, argv
               for line in stdin: x = int(line); print eval(argv[1])
               $ cat y
               3
               5
               6
               $ ./blah.py 'x*x' < y
               9
               25
               36

               Jak to opedzasz w C++?

            4. 

               mikolajs

               24 czerwca 2011

               "wlasnie dzieki wymuszeniu spojnych wciec (ktorych glebokosc mozesz sobie
               dowolnie wybrac) jezyk ten jest bardzo czytelny. Sam pare lat temu (jako zatwardzialy
               C-owiec i Perlowiec) krzywilem sie na takie podejscie Pythona, bylem w grubym bledzie.
               To sie zaskakujaco dobrze sprawdza na dluzsza mete. "
               A zdarza Ci się kopiować kod? Edycja kodu w pytonie nie jest tak prosta jak w językach z klamrami. Tam gdzie używa się klamr samo IDE wyrównuje Ci linie i tak samo łatwo się czyta, ale bez wysiłku z twojej strony 😉 Brakuje mi znaku końca bloku.

            5. 

               Krystian

               25 czerwca 2011

               "A zdarza Ci się kopiować kod?"

               Jaki jest problem z kopiowaniem kodu? Wklejasz fragment i ewentualnie wyrównujesz go (cały fragment) przy pomocy Tab, Shift+Tab.

               Jeśli chodzi o wcięcia to każdy edytor/IDE wspierający Pythona prowadzi za rękę i automatycznie stosuje właściwe. Zasady dotyczące wcięć (i ogólnie stylu) w Pythonie są bardzo proste (w porównaniu np. do Haskella).
               http://google-styleguide.googlecode.com/svn/trunk… http://urchin.earth.li/~ian/style/haskell.html

               Guido van Rossum napisał kiedyś:

               "If it uses two-space indents, it's corporate code; if it uses four-space indents, it's open source. (If it uses tabs, I didn't write it! :-)"

               Poza tym edytory posiadają funkcje pozwalające na korektę (błędów osób, które biorą się za pisanie w Pythonie, a nie znają podstawowych zasad), takie jak: fix indentation, rectangular selection, remove trailing white space, expand tabs etc.

            6. 

               pijaczek

               25 czerwca 2011

               "I wlasnie dzieki wymuszeniu spojnych wciec (ktorych glebokosc mozesz sobie
               dowolnie wybrac) jezyk ten jest bardzo czytelny. Sam pare lat temu (jako zatwardzialy
               C-owiec i Perlowiec) krzywilem sie na takie podejscie Pythona, bylem w grubym bledzie.
               To sie zaskakujaco dobrze sprawdza na dluzsza mete. "
               Ja mam inne doświadczenia – bardzo lubiłem pythona dopuki nie zabrałem się do większego projektu (gdzie python odgrywał ważną rolę języka skryptowego). Męki z czytaniem kodu, z problemami typu spacja/tab za mało i zmienia się zupełnie działanie programu czy brak mocnego typowania doprowadzają do szaleństwa na dłuższą metę.
               Wymuszanie spójnych wcięć jak to nazwałeś tylko niepotrzebnie rozwala kod – każdy w miarę inteligentny programista i w C++ będzie takie stosował (nawet jak nie chce bo IDE będzie to robić za niego), ale są sytuację kiedy czytelniej jest ich nie stosować i dobrze kiedy język nie utrudnia Ci wtedy napisania tak kodu jak chcesz.

               "Wydajnosc standardowego JVMa jest bardzo dobra, ktos kto marudzi,
               ze soft na tym odpalany jest wolny, nie bardzo wie o czym mowi. FUD. "
               Wydajność JVM jest przyzwoita, ale nie bardzo dobra (no w porównaniu z pythonem może i tak, ale daleko mu do kodu wypluwanego przez kompilatory C/C++). Dodatkowym problemem jest GC, który spowalnia działanie aplikacji (ale też jest atutem ze względu, na braki wycieków pamięci i szybsze alokowanie danych (prealokuje dużą ilość pamięci na starcie, zamiast tak jak standardowo w C/C++ alokować na wszystko osobno dane (mniej marnowania pamięci, ale wolniej))).

               "Java nie jest "naturalnie wielordzeniowa", zasadniczo to w Javie slabo sie pisze
               concurrent programming."
               W javie, żeby wykonywać jakieś zadanie wielowątkowo wystarczy dopisać klasie implementacje Runnable i w innej klasie utworzyć wątek (new Thread(klasa)). Jest to wręcz naturalne w tym języku – co do równoległego programowania to od Java SE5 wsparcie jest świetne (jedyne programowanie wielowątkowe na CPU, które bardziej mi się podoba to OpenMP dla C/C++)

               "Niektorzy maja inne zdanie na ten temat: http://page.mi.fu-berlin.de/prechelt/Biblio/jccpp…
               I co to niby dowodzi? Hitler też miał inne zdanie na wiele tematów niż ja i niekoniecznie słuszne.

               "To zart, czy naprawde merytoryczny argument?"
               Żart, tak jak pisanie, że w pythonie zajmuje mniej linii kod.

               "Z ciekawosci, jak ponizsze wyklepiesz zwiezle w C++?
               (podaje plik int/linijka i jako argument "funkcje(x)", dostaje liste wynikow). "
               Akurat tu (eval) minimalną przewagę mają języki skryptowe, bo dla języka skryptowego nie ważne, czy to tekst podajesz do obliczeń (analiza składniowa nie jest robiona na etapie kompilacji tylko w czasie wykonywania programu) – z pomocą przychodzi ofc Boost, ale faktycznie wymaga to trochę kodu, jednak bibliotek do robienia tego typu zadań masz wiele i najczęściej sprowadzają się do #include "naglowek" i eval(string) lub co najwyżej zamiast samego, eval rozdzielone jest to na dwie linie (np. Parse(); i Eval();)… a dobrze wiesz, że tu jest akurat wielka przewaga języka skryptowego (bo zadanie tego programu to wykonać string… czyli skrypt).

            7. 

               Krystian

               25 czerwca 2011

               "Ja mam inne doświadczenia – bardzo lubiłem pythona dopuki nie zabrałem się do większego projektu (gdzie python odgrywał ważną rolę języka skryptowego). Męki z czytaniem kodu, z problemami typu spacja/tab za mało i zmienia się zupełnie działanie programu czy brak mocnego typowania doprowadzają do szaleństwa na dłuższą metę. "

               1) dopóki, a nie "dopuki"
               2) Tak to jest jak się zaczyna kodować, nie znając podstaw, w tym wypadku PEP 8 http://www.python.org/dev/peps/pep-0008/

               Indentation: Use 4 spaces per indentation level.
               Tabs or Spaces? Never mix tabs and spaces.
               Maximum Line Length: Limit all lines to a maximum of 79 characters.

               "Żart, tak jak pisanie, że w pythonie zajmuje mniej linii kod."

               Bo zajmuje, jeśli pisze się w "pytonistycznym" stylu. Jak będziesz przenosił "dosłownie" kod napisany w C czy Javie do Pythona to nie dziw się, że nie wygląda to tak jak powinno. No ale to jest to o czym pisałem powyżej… Klepiemy kod nie znając języka.

            8. 

               mikolajs

               25 czerwca 2011

               "Limit all lines to a maximum of 79 characters. "
               A jak potrzebujesz dłuższego kodu w linii, czasem lepiej jest umieścić określoną funkcjonalność w jednej linii bo łatwiej się potem czyta.

            9. 

               Krystian

               25 czerwca 2011

               To zalecenie akurat można bez problemu pominąć, jeśli jest taka konieczność. Jednak zdecydowanie lepiej się przewija kod bez korzystania z poziomego paska;)

               Mimo wszystko w większości przypadków można elegancko złamać linię:
               http://google-styleguide.googlecode.com/svn/trunk…

            10. 

                Krystian

                25 czerwca 2011

                Ps Jeśli chcesz pisać w Pythonie z możliwością deklarowania typów to korzystaj z http://cython.org/. W rezultacie otrzymasz wydajny kod C.

            11. 

                pijaczek

                25 czerwca 2011

                "Tak to jest jak się zaczyna kodować, nie znając podstaw, w tym wypadku PEP 8 http://www.python.org/dev/peps/pep-0008/ "
                1. To nie są żadne podstawy co zalecenia, do których akurat się stosowałem co jednak nie zmienia, że cechy języka python w większych projektach są zabójcze.
                2. Ja akurat używałem 4 spacji na poziom, co nie zmieniło problemów z tym językiem.

                "Bo zajmuje, jeśli pisze się w "pytonistycznym" stylu. Jak będziesz przenosił "dosłownie" kod napisany w C czy Javie do Pythona to nie dziw się, że nie wygląda to tak jak powinno. No ale to jest to o czym pisałem powyżej… Klepiemy kod nie znając języka. "
                Tylko i wyłącznie wtedy, kiedy piszesz rozlazły kod w C/C++ (np. styl GNU, który zajmuje dużo więcej linii niż K&R), oraz nie znasz języka i jego bibliotek jak Boost przez co wymyślasz koło na nowo, i piszesz to co już jest napisane i wystarczy użyć.

            12. 

                Krystian

                25 czerwca 2011

                Ale to samo odnosi się do Pythona, a nawet przede wszystkim. Stosowanie bibliotek nie dość, że znacznie ułatwia zadanie to jeszcze często wpływa korzystanie na wydajność.

                Przykład:

                Pure Python560sec
                NumPy2.24 sec
                Cython1.28 sec

                Powtarzam się z tym NumPy/SciPy tak jak ty z Boost;) Ale to mój ulubiony przykład i ulubione biblioteki, dla których nie bardzo widzę alternatywę (na wolnej licencji) wśród innych języków programowania. Biorąc pod uwagę kryteria: możliwości / łatwość użycia / integracja z innymi bibliotekami / wydajność są moim faworytem w tej dziedzinie.

            13. 

                pijaczek

                25 czerwca 2011

                Zgadza się – to samo odnosi się do Pythona, dlatego też nie mówię, że w C++ szybciej coś napiszesz (no poza wielowątkowością, bo nie ma w pythonie alternatywy dla OpenMP), bo czas i narzędzia są podobne (różnicą jest tylko sam język który wiele różnicy nie robi poza tym, że języki skryptowe, jak i kompilowane mają swoje wady i zalety). Co do NumPy to dobrze, że zauważyłeś podobieństwo do Boost, bo funkcjonalnie to Boost::MultiArray + Boost::uBLAS – SciPy to po prostu LAPACK.

            14. 

                Krystian

                25 czerwca 2011

                Dałem plusa z tym, że:

                Boost::MultiArray + Boost::uBLAS ma funkcjonalność NumPy, a nie SciPy (jeśli się mylę to mnie popraw).

                SciPy rozszerza możliwości NumPy o specjalistyczne funkcje, np. całkowanie numeryczne, fft itd. itp., których zdaje się Boost nie posiada. To też jest ogromna zaleta Pythona, że całość/większość "obliczeń" zorientowana jest wokół jednej świetnej biblioteki i nie ma problemów z wymianą danych pomiędzy innymi (SciPy, matplotlib, SciKits, PIL itd), a dodatkowo PyLab i IPython łączą je wspólną przestrzenią nazw.

                "SciPy to po prostu LAPACK"

                Tak. Ja nazywam SciPy następcą LAPACK-a. Nie wyparł on oczywiście LAPACK-a całkowicie z wiadomych względów, ale oferuje podobne możliwości, świetne narzędzia (w tym IDE), wystarczającą wydajność, wygodę MATLAB-a (np. dynamiczne typowanie), co w połączeniu z językiem programowania ogólnego przeznaczenia i licencją BSD daje ogromne możliwości.

                Każdy kto próbował zainstalować pod Windowsem kompilator Fortrana z LAPACK-iem nie korzystając z komercyjnych rozwiązań (np. kompilatora Intel i MKL) chyba wie co mam na myśli pisząc o wygodzie;)

            15. 

                pijaczek

                25 czerwca 2011

                "Boost::MultiArray + Boost::uBLAS ma funkcjonalność NumPy, a nie SciPy (jeśli się mylę to mnie popraw). "
                Tak.

                "Każdy kto próbował zainstalować pod Windowsem kompilator Fortrana z LAPACK-iem nie korzystając z komercyjnych rozwiązań (np. kompilatora Intel i MKL) chyba wie co mam na myśli pisząc o wygodzie;) "
                Tylko po co kompilator Fortrana (no chyba, że chcesz w tym języku pisać)? Do C++ masz LAPACK++ który się bez problemów kompuluje pod Microsoft Visual Studio czy Mingw32 (ofc pod darmowy mingw32 (GCC na windowsa) skompilujesz bez problemu zwykły LAPACK Fortranowy) http://lapackpp.sourceforge.net i ofc możesz współpracować z Boost za pomocą numeric_bindings.

            16. 

                Krystian

                25 czerwca 2011

                " Do C++ masz LAPACK++ który się bez problemów kompuluje pod Microsoft Visual Studio czy Mingw32 (ofc pod darmowy mingw32 (GCC na windowsa) skompilujesz bez problemu zwykły LAPACK Fortranowy)"

                Próbowałeś przy użyciu gfortran? Ja próbowałem. Bez sukcesu. Zwyczajnie się poddałem po kilku próbach.

            17. 

                pijaczek

                25 czerwca 2011

                Nie próbowałem, bo nie miałem powodu – używam LAPACK++ i nie mam powodu bawić się z fortranem – powiedziałem, że bez problemu, bo kompilator oficjalnie jest wspierany i nie powinno być większych problemów.

            18. 

                Krystian

                26 czerwca 2011

                Trudno tu mówić o oficjalnym wsparciu. W internecie można znaleźć głównie problemy z tym związane i kilka rozwiązań, które teoretycznie działają, a w praktyce "hack na hacku hackiem pogania". Od tego czasu mam uraz do MinGW i tych jego kompilatorów g**.

            19. 

                Krystian

                25 czerwca 2011

                O GIL można przeczytać tutaj http://www.rwdev.eu/articles/gil

                "Około roku 1999 znalazł się śmiałek (Greg Stein), który rzucił wyzwanie GIL-owi [2]. Po ciężkich bojach zastąpił globalny muteks dużą ilością mniejszych muteksów, którymi chronił wewnętrzne struktury interpretera. To pozwoliło na bezpieczne uruchamianie wielu wątków w interpreterze, gdyż nie istniało już zagrożenie uszkodzenia owych wewnętrznych struktur. Guido nawet zaakceptował łatki (ang. patch), które dokonywały tych rewolucyjnych zmian.

                I co się później okazało? W testach wydajnościowych wyszło czarno na białym, iż kod jednowątkowy działający na wersji bez GIL-a okazał się być dwukrotnie wolniejszy. Już słyszę ten krzyk "No dobrze, ale na wieloprocesorowych maszynach wydajność wersji wielowątkowej zwróci się z nawiązką!". Takie testy również wykonano (tak z tym problem zmagało się wielu) [3] i niestety okazało się, że wzrost wydajności w żadnym razie nie jest linearny (wraz z liczbą procesorów), a poza tym jest na tyle mały, iż cała gra okazała się niewarta świeczki. Pragmatyzm jak na razie wychodzi zwycięsko w starciu z niechęcią do GIL-a."

                A co do IDE… Spyder jest napisany w całości w Pythonie. Od dłuższego czasu zastępuje __mi__ z powodzeniem Eclipse (PyDev). Działa równie szybko (lub równie wolno — jak kto woli), zużywa podobną ilość pamięci, posiada zbliżoną funkcjonalność i kilka funkcji __mi__ szczególnie przydatnych. Instalator i spakowane źródła zajmują ~1.8 MB! No i stosunkowo szybko się rozwija.

            20. 

                pijaczek

                25 czerwca 2011

                @Krystian: GIL jest złe, a to, że nie potrafią zaimplementować tego lepiej niż jest nie jest wcale dobre (bo gdyby chcieć zaimplementować dobrze, to trzeba by dzisiejszy kod wyrzucić do kosza i wszystkie jego usprawnienia).

                Co do Spyder to jest to dużo mniejsze IDE z dużo mniejszymi możliwościami (prawdę mówiąc bliżej mu do Kate niż Eclipse), a działa równie wolno co Eclipse (nie ukrywajmy, Eclipse działa powoli i wymaga dużo ramu… ale możliwości te wady przyćmiewają). Niestety prawda jest taka, ale jeśli Eclipse przepisać do Pythona to wydajność spadłaby jeszcze o jakieś 5-50x (a sama Java nie jest szybka, bo w zależności od zadania wydajność to średnio 2-10x wolniejsza niż C++ (ofc w większych programach, bo w mikrotestach można wykazać nawet, że jest wydajniejsza niż C++)).

            21. 

                Krystian

                25 czerwca 2011

                Jython i IronPython są pozbawione problemu GIL, ale wydajnościowo wypadają słabiej od CPythona. W bibliotece standardowej Pythona znajdują się moduły Multiprocessing, Threading, Subprocess, które pozwalają wykorzystać moc procesorów wielordzeniowych.

                Niektóre biblioteki poza tym, że znacznie poprawiają wydajność [1], przy okazji rozwiązują [2] problem Globalnej Blokady Interpretera (przynajmniej częściowo).

                [1] http://technicaldiscovery.blogspot.com/2011/06/sp…
                [2] http://www.scipy.org/ParallelProgramming

                Warto przeczytać:

                [3] http://www.dabeaz.com/python/GIL.pdf
                [4] http://www.dabeaz.com/python/NewGIL.pdf

                "Co do Spyder to jest to dużo mniejsze IDE z dużo mniejszymi możliwościami"

                Eclipse (PyDev):

                Django integration
                Code completion
                Code completion with auto import
                Syntax highlighting
                Code analysis
                Go to definition
                Refactoring
                Mark occurrences
                Debugger
                Remote debugger
                Tokens browser
                Interactive console
                Unittest integration
                Code coverage

                Prawie wszystkie te opcje Pydev Spyder posiada.
                http://code.google.com/p/spyderlib/wiki/Features

                Prawie (i vice-versa), bo skierowany jest do trochę innej grupy odbiorców. Co nie zmienia faktu, że jest to pełnoprawne IDE, a nie "zwykły" edytor.

            22. 

                pijaczek

                25 czerwca 2011

                Dobrze, że napisałeś, że częściowo, bo daleko do wykorzystania mocy dzisiejszych procesorów nie mówiąc o innych urządzeniach jak karty graficzne (tzn można wykorzystać ich moc w pythonie, tak samo jak i procesorów (mówię o pełnej mocy wszystkich rdzeni i ich rozszerzeń wektorowych SSE/AVX bez męki… są to bindingi do OpenCL – czyli piszesz w języku C + dodatkowe typy wektorowe (na których działania automatycznie i bez problemu są optymalizowane do posiadanego sprzętu i rozszerzeń wektorowych))).

                Jeśli rozpatrywać IDE jako tylko plugin PyDev to masz rację, ale PyDev to tylko plugin rozszerzający możliwości, a nie będący nimi.
                Zapominasz o tym, że z Eclipse dostajesz masę zintegrowanych narzedzi ułatwiających programowanie, ale nie związanych z samym językiem – i właśnie przez te dodatki jest takim potężnym IDE (i dzięki nim też takim powolnym ;p)

            23. 

                Krystian

                25 czerwca 2011

                A bindingi do OpenGL, OpenCL, CUDA dla Pythona noszą odpowiednio nazwy PyOpenGL, PyOpenCL, PyCUDA;) Przetestuj sobie kiedyś wykresy 3D w Mayavi2 (wchodzi w skład Enthought). Mayavi2 jest napisane w większości z Pythonie i korzysta z OpenGL. Wydajnością na fullscreenie miażdzy Gnuploty i inne "Matlaby".

                Ps Funkcje PyDev wymienione powyżej to nic innego jak funkcje Eclipse, tyle że dzięki PyDev można zastosować je dla danego języka. Oczywiście nie wyczerpują one możliwości Eclipse, ale są to zdecydowanie najczęściej używane opcje. Spyder pod tym względem nie ustępuje za bardzo, a jest to stosunkowo młody projekt.

            24. 

                pijaczek

                25 czerwca 2011

                "A bindingi do OpenGL, OpenCL, CUDA dla Pythona noszą odpowiednio nazwy PyOpenGL, PyOpenCL, PyCUDA;)"
                Nie tylko bo są też inne np. CLyther dlatego napisałem bez nazw własnych, żeby nie faworyzować żadnego ;p

                "Przetestuj sobie kiedyś wykresy 3D w Mayavi2 (wchodzi w skład Enthought). Mayavi2 jest napisane w większości z Pythonie i korzysta z OpenGL. Wydajnością na fullscreenie miażdzy Gnuploty i inne "Matlaby"."
                Ciekawi mnie tylko co ma do rzeczy? Chyba nie chcesz w oparciu o to powiedzieć, że Python jest szybszy (to jak powiedzieć, że python jest szybszy bo na najnowszych i7 działa szybciej niż podobny kod w C na 386). Różnica wydajności tu jest spowodowana dlatego bo jeden program rysuje na karcie graficznej (i nie ma tu, żadnej zalety Pythona, bo po prostu przekazuje dane bibliotece napisanej w C, która dopiero obrabia te dane i przekazuje do karty graficznej), a inne jak gnuplot rysuje wszystko na CPU przez co jest wolniejsze wyświetlanie 3d (ale działa nawet jeśli twoja karta graficzna nie ma sterowników 3d, czy jest odpalane na dziwnych urządzeniach (np. gnuplot na telefonie odpalałem, gdzie system gość linuks nie miał dostępu do grafiki 3d), więc tu jest wybrana po prostu uniwersalność, zamiast wydajności).

                "Ps Funkcje PyDev wymienione powyżej to nic innego jak funkcje Eclipse, tyle że dzięki PyDev można zastosować je dla danego języka. Oczywiście nie wyczerpują one możliwości Eclipse, ale są to zdecydowanie najczęściej używane opcje. Spyder pod tym względem nie ustępuje za bardzo, a jest to stosunkowo młody projekt. "
                Nie – to co tam napisane jest to nie są cechy Eclipse – każdy język ma pisane to wszystko od zera. To co wspólne to to co jest niezależne od języka np. taski, automatyczna dokumentacja kodu w oparciu o komentarze (doxygen), obsługa systemów kontroli wersji, praca grupowa, planowanie, zarządzanie projektem (Mylyn), obsługa baz danych SQL (bardzo przydatne jeśli wykorzystujesz takie w programie), projektowanie w UML i cała masa innych rzeczy, które tworzą IDE. Bez tego w IDE masz po prostu edytor z podpiętym debuggerem i 50 różnych programów do innych zadań – co już ciężko nazwać ZINTEGROWANYM Środowiskiem Programistycznym (IDE)… tzn jeśli używasz tylko tego co ma Spyder i niczego więcej to możesz nazwać je IDE, ale nie mów, że ma podobną funkcjonalność, bo podobną ma tylko do samej edycji kodu, a to tylko mały aspekt całego IDE.

            25. 

                Krystian

                25 czerwca 2011

                "Ciekawi mnie tylko co ma do rzeczy? Chyba nie chcesz w oparciu o to powiedzieć, że Python jest szybszy"

                Nie, nic takiego nie sugeruję. Mam na myśli jedynie to, że często przesadnie mówi się o wydajności Pythona, a można w nim w prosty sposób realizować rzeczy, które w innych językach programowania wymagają więcej wysiłku.

                Dlaczego Gnuplot nie korzysta z karty graficznej? Dlaczego nie ma podobnych narzędzi na wolnych licencjach napisanych w super wydajnych językach programowania? (może ich po prostu nie znam) Może za dużo wysiłku to wymaga? No ale przecież kodu jest tyle samo co w innych językach, a Python jest wyjątkowo "rozlazły";)

            26. 

                pijaczek

                25 czerwca 2011

                Po prostu nie ma takiej potrzeby – to co generuje Gnuplot jest wystarczająco wydajne w 3d (dla nich liczy się czas obliczania, a nie rysowania) i pozwala to na działanie na każdej maszynie.

                Osobiście używam Scilab (program pisany w javie i korzystający z OpenGL).

                Co do za dużo wysiłku to wymaga, to troszkę nie trafiłeś, bo napisanie własnego rasteryzatora jest trudniejsze niż skorzystanie z istniejącego (OpenGL). Co więcej korzystanie z OpenGL może być frustrujące dla osób programujących w wysokopoziomowych językach, bo API OpenGL jest bardzo związane z językiem C i jest stosunkowo specyficzne (oparte o maszynę stanów, bindowanie itd) – chociaż mimo wszystko API jest stosunkowo proste i przyjemne (przynajmniej dla mnie, bo programuję grafikę OpenGL od ponad dekady i może się po prostu przyzwyczaiłem).

                PS. właśnie dla testu poszukałem benchmarka i zrobiłem sobie test http://www.mathkb.com/Uwe/Forum.aspx/scilab/3724/… i GL_CANVAS FPS= 599. więc przy ~600FPS ciężko narzekać.

            27. 

                Krystian

                26 czerwca 2011

                Znam trochę Scilaba. Używałem go przez jakiś czas… do momentu gdy trafiłem na Python(x,y). Scilab miał niestety sporo błędów, archaiczne GUI (elementy pozostały do dziś), był pamięciożerny, a co chyba najgorsze… składnia zmieniała się z każdym wydaniem. Wiele funkcji wyrzucano, dodawano kilka nowych, zmieniano nazwy jeszcze kilku. Tak było jakieś dwa lata temu.

                Informacji o Scilabie za dużo nie ma, literatura jest uboga, dokumentacja jeszcze wtedy była kiepska (w porównaniu np. z dokumentacją Pythona, NumPy, SciPy itd).

                Przepisałem też kilka moich plików .sci i .sce do Pythona i porównywałem wydajność jednego i drugiego. Python okazał się szybszy z tego co pamiętam, ale nie dam sobie ręki uciąć. Może w wolnej chwili zrobię małe porównanie.

   2. 

      Paweł

      23 czerwca 2011

      500, to według Ciebie, mało czy dużo?

      Odpowiedz
      1. 

         aix_Wolna_Głupota

         23 czerwca 2011

         Astronomicznie dużo :).

         Odpowiedz
         1. 

            maxx

            24 czerwca 2011

            Zgadzam się. To jest za dużo. Ale twoja metoda obliczania, kto ile napisał, jest zupełnie z d…
            To projekty mają 48MLOC a nie ostatnie patche. Tak więc z pewnością żaden deweloper nie pisał 500 linii kodu dziennie.

            Odpowiedz
      2. 

         szymon_g

         24 czerwca 2011

         … a jakiej dlugosci owe linie maja byc ;)?

         Odpowiedz
         1. 

            norbert_ramzes

            24 czerwca 2011

            I czy puste linie/komentarze są liczone? I ile ich jest?

            Odpowiedz
            1. 

               norbert_ramzes

               24 czerwca 2011

               PS. Jak ktoś kodzi astronomicznie długie linijki w PHP to Eclipse trochę odpada 😉

   3. 

      mikolajs

      23 czerwca 2011

      Dobrze, że nie płaci się za ilość napisanych linijek kodu, bo byśmy mieli potworki 😉

      Odpowiedz
   4. 

      Trinollan

      23 czerwca 2011

      No tak, bo każdy projekt to w 100% klepanie kodu. Już dawno odeszło się od prawideł mówiących, że najpierw się planuje, potem projektuje, gdzieś później jeszcze testuje…

      Odpowiedz
      1. 

         wladca_kodu

         24 czerwca 2011

         Odeszło się, bo to nie działało i prowadziło do przerośniętych projektów oddawanych 3 lata po terminie.
         Lepiej jest tak:
         1. zaplanować co ma być zrobione w najbliższym czasie (tydzień, dwa, maks. miesiąc)
         2. napisać testy
         3. zakodować na szybko, byle tylko działało
         4. poprawiać aż testy zaczną przechodzić
         5. zrefaktoryzować aby było ładnie, jeśli się zepsuło, goto 4.
         6. goto 1

         Odpowiedz
2. 

   generator_hejtów

   23 czerwca 2011

   Eclipse to i tak gówno. Czego by nie zrobili to będzie to strasznie wolne i brzydkie. Tutaj MS pokazuje jak się robi IDE z prawdziwego zdarzenia (choć nie posiadające wsparcia dla tylu języków). Ale who cares? 😉

   Odpowiedz
   1. 

      Druedain

      23 czerwca 2011

      Nie karmić trolla…

      Odpowiedz
      1. 

         Marek

         23 czerwca 2011

         Ma racje niestety. W funkcjonalności Eclipse ściga się z CodeBlocks, NetBeans, ale Xcode i Visual to zupełnie inna klasa. Testy jednostkowe nie działają tak jak powinny, oprócz javy do niczego innego się nie spisuje. Brakuje na prawde dobrego IDE OpenSource.

         Odpowiedz
         1. 

            Druedain

            23 czerwca 2011

            Nikt nie mówi, że @generator_hejterów nie krąży wokół prawdy – tutaj chodzi o sposób wypowiedzi.

            Ja sam nie jestem specem, tylko początkującym studentem, ale Visuala zamieniłem na NetBeans i nie było to spowodowane żadnymi kaprysami moimi związanymi z wolnym oprogramowaniem. Po prostu wybrałem narzędzie, które bardziej mi odpowiada (w tym wypadku narzędzie, które w ogóle działa – czyli nie wysypuje się przy próbie włączenia, daje się bezproblemowo zainstalować i jest mimo wszystko lżejsze w odczuciu (wiem doskonale, że moje problemy mogą być serią niefortunnych zdarzeń i za czwartym podejściem wszystko byłoby okej, ale skoro obecnie i tak nie korzystam już z Windowsa, to czwartego podejście póki co nie planuję)).

            Odpowiedz
         2. 

            _mc_

            23 czerwca 2011

            IMHO Eclipse jest duzo lepsze do kodowania w C++ niz Visual Studio (i o 4 klasy lepsze od CodeBlocks – choc tego ostatniego dawno nie uzywalem).

            Odpowiedz
3. 

   PiotrR

   23 czerwca 2011

   A ja już myślałem, że zmienili tego splasha na ładniejszego (takiego jak w tym newsie). Uruchamiam i….widzę starego brzydkiego splasha zrobionego w GIMP-ie w 5 minut Oo

   Odpowiedz
   1. 

      sirmacik

      23 czerwca 2011

      Grafika jest twórczością @caniszczyk, który chciał pomóc innym poczuć świeżość wydania Indigo.

      Odpowiedz
4. 

   Krystian

   25 czerwca 2011

   Gdyby nie było dobrych IDE kod z nawiasami klamrowymi (bez wcięć lub z wcięciami wg inwencji twórczej autora) czytałoby się fatalnie;) Ciekawe kiedy pojawią się narzędzia ukrywające klamry? 😉

   A tak na poważnie… Nie róbmy problemu z czegoś co problemem nie jest, tym bardziej, że mamy dostęp do odpowiednich narzędzi, z których warto korzystać. Mnie się zwyczajnie podoba kod Pythona (ze względu na wcięcia i brak zbędnego "szumu").

   Odpowiedz
   1. 

      mikolajs

      25 czerwca 2011

      "ze względu na wcięcia" – wcięcia masz w każdym języku 🙂

      Odpowiedz
      1. 

         Krystian

         25 czerwca 2011

         Ale nie każdy je właściwie stosuje, albo nie stosuje wcale. IDE sobie radzi, ale przykłady na stronach internetowych, w prezentacjach itd. czasami wyglądają tak, że nie da się na to patrzeć. Ktoś wkleja na forum kod i prosi o pomoc, a kod wygląda tak, że odechciewa się czytać.

         Odpowiedz
         1. 

            mikolajs

            26 czerwca 2011

            To już kwestia niechlujności. Tyle, że w przypadku języka z klamrami utracenie białych znaków przy wklejaniu nie uniemożliwi zrozumienia kodu

            Odpowiedz
5. 

   Krystian

   25 czerwca 2011

   Co do przypadkowej zmiany zasięgu… http://i.imgur.com/ybnZj.png Wystarczy włączyć pomocnicze kreski.

   Odpowiedz
   1. 

      pijaczek

      25 czerwca 2011

      "Ciekawe kiedy pojawią się narzędzia ukrywające klamry? ;)"
      Do C/C++ pewnie nigdy, bo klamry tylko poprawiają czytelność i to gdzie blok się zaczyna i gdzie kończy.

      "Co do przypadkowej zmiany zasięgu… http://i.imgur.com/ybnZj.png Wystarczy włączyć pomocnicze kreski. "
      Niestety, ale to pokazuje tylko początki bloków, ale końców nie masz zaznaczonych, tak jak "nd = x.ndim" czy return po wyjątkach nie są oznaczone i pomyłka z białymi znakami zmieniają zachowanie programu, bez żadnej zmiany w tych znacznikach.

      Odpowiedz
      1. 

         Krystian

         25 czerwca 2011

         Nadal nie widzę problemu. Gdzie jest pułapka przy `nd = x.ndim`? Domyślam się, że jeśli chodzi o ostatni return po wyjątkach to masz na myśli głębokość jego wcięcia?

         1) spójrz jak masz return przy if-ach powyżej… tu musi być tak samo, musi być zachowana logika
         2) jeśli po linii `raise ValueError` wciśniesz Enter to edytor/IDE rozpocznie nową linię dobierając prawidłowe wcięcie http://i.imgur.com/VbpJd.png

         Odpowiedz
         1. 

            pijaczek

            25 czerwca 2011

            W nd… pułapka jest taka sama jak przy ostatnim returnie – czyli białe znaki (które często są połykane przy kopiowaniu, czy przesyłaniu przez sieć) mogą zmienić działanie programu.
            To co, że IDE Ci dobrze ustawi jak wciśniesz enter, jeśli np nie wciskasz enter tylko przechodzisz do linii już powstałej, lub później modyfikujesz kod (przypadkowe zniknięcia białych znaków przy edycji nie należą do rzadkości i IDE tu nie pomoże). Podobnie sprawa się ma jeśli chcesz kilka instrukcji w bloku, a IDE przerzuci Cie poza tak jak napisałeś też zmienia działanie programu – ogólnie to przy białych znakach w pythonie zawsze musisz mieć oczy szeroko otwarte, bo łatwo o błędy, które dodatkowo później w dużym programie ciężko zidentyfikować, a debuggowanie pythona nie należy do najprzyjemniejszych (tym bardziej, że wystarczająco wiele atrakcji zapewnia dynamiczne typowanie ;p ).

            Odpowiedz
6. 

   mikolajs

   25 czerwca 2011

   "wystarczy minimum uwagi przy zaznaczeniu początku i końca fragmentu,"
   Przy klamrach nie musisz uważać.
   Różnica między klamrami a wcięciami polega tylko na tym, że w pythonie nie ma końca zasięgu, bo znak początku jest.
   Dużo pisałem w pythonie i zgodzę się, że to całkiem fajny język (poza tym, że nie przepadam za językami dynamicznie typowanymi), ale znak końca zasięgu nie zepsułby tego języka, a jedynie ułatwił edycję.

   Odpowiedz
7. 

   pijaczek

   25 czerwca 2011

   "Przesadzasz. Strony o tematyce programistycznej pozwalają na wklejenie kodu i nie wycinają spacji, tak jak tu w komentarzu."
   Tylko i wyłącznie jeśli nie zapomnisz umieścić w znaczniku code ;p

   "Spyder w locie analizuje kod i zaznacza miejsca zawierające błędy: http://i.imgur.com/5J3cd.png "
   "Jak kto jak? Zgodnie z obowiązującą konwencją. "
   To powiedz mi w jaki sposób konwencja czy IDE pozwoli Ci się dowiedzieć gdzie był printf (w pętli czy poza).

   Odpowiedz
   1. 

      Krystian

      25 czerwca 2011

      "Tylko i wyłącznie jeśli nie zapomnisz umieścić w znaczniku code ;p "

      code z BBCODE? To też działa różnie. Znam strony na których code wycina spacje na początku linii. Korzystając z Markdown za to nigdy nie napotkałem problemów. Wystarczy spojrzeć na StackOverflow. Tam źle wklejonego kodu nikt nawet nie czyta.

      "To powiedz mi w jaki sposób konwencja czy IDE pozwoli Ci się dowiedzieć gdzie był printf (w pętli czy poza)."

      A to już nie wynika z konwencji tylko "treści" samego kodu;)

      Odpowiedz
      1. 

         pijaczek

         25 czerwca 2011

         "A to już nie wynika z konwencji tylko "treści" samego kodu;) "
         A gdy kodu już nie pamiętasz lub nie znasz, to siedzisz i rozmyślasz jak to powinno być, zamiast mieć jednoznaczne klamry ;p

         Odpowiedz