przejscie z C++/PHP do Pythona
Arson
Od dawna siedze w C++. Od jakiegos czasu zajmuje sie tylko PHP5.
Naszla mnie ochota nauczyc sie pythona.
Moze ktos moglby sie podzielic wlasnym doswiadczeniem z podobnej przesiadki?
Pozdrawiam,
Arek
Rob Wolfe
Arson napisał(a):
Jesli pytasz o wyjscie na wolnosc z krainy wiecznych segfaultow
i wszechwladnego, wiecznie niezadowolonego kompilatora,
to uczucie jest znakomite.
Co do reszty szczegolowych pytan, to odpowiadam po kolei:
1. tak, dynamiczne typowanie to "feature" a nie "bug"
2. tak, garbage collector to dobry pomysl
3. nie, nie wiem jak mozna zyc bez funkcji pierwszego rzedu
;)
RW
Tupteq
> Od dawna siedze w C++. Od jakiegos czasu zajmuje sie tylko PHP5.
> Naszla mnie ochota nauczyc sie pythona.
> Moze ktos moglby sie podzielic wlasnym doswiadczeniem z podobnej
> przesiadki?
Ja parę lat temu przechodziłem z C++ (znałem też PHP i kilka innych
języków). Wrażenie przy przejściu jest bardzo pozytywne i w moim
przypadku do dziś się utrzymuje. Trzeba oduczyć się trochę niedobrych
rzeczy (np. używania liczników w pętlach), nauczyć kilku nowych (np.
życia wśród wszędobylskich referencji), ale po C++ czy PHP w Pythonie
pisze się świetnie. Może wrócą Ci (niektóre) stare dobre nawyki z
czystego C, bo ktoś wyliczył (Alex Martelli?), że Python jest
najbardziej podobny (w 83% bodaj) w założeniach do języka C.
Początkowo dziwnym może się okazać, że czasem najlepszą dokumentacją do
biblioteki będzie jej kod źródłowy w Pythonie, choć jeszcze bardziej
może Cię zdziwić, że po tygodniu nauki języka już rozumiesz ten kod :)
Później dojdziesz do wniosku, że vector i map wypadają blado na tle
listy i dicta pod względem wygody użycia, a naturalny dla człowieka
format pętli "for" to "for item in sequence" :)
Później poznasz generatory i okaże się, że czasem dużo rzeczy można
zrobić bardzo prosto, a słówko "yield" to coś bardzo fajnego.
Jest jeszcze trochę fajnych rzeczy, jak wyrażenia tworzace listy i
generatory, lambda, złożone porównania ("3 < a < 5"), fajne biblioteki
(dzięki którym stworzysz serwer http w 3 linijkach, a XMLa sparsujesz w
dwóch) i wiele innych.
Tyle tak na szybko. Ale reszta grupy na pewno doda coś od siebie.
--
Pozdro... Tupteq
Bart Ogryczak
W tę stronę, to bezproblemowo. W drugą gorzej. Po dwóch latach robienia w Pythonie
przyszło mi pisać w Javie i PHP. Dżizas, toż w PHP jest sobie np. głupia
funkcja gdinfo() zwracająca słownik. Ze słownika interesuje mnie jedno pole,
ale w PHP nie da się zrobić $ver = gdinfo()['GD Version'], trzeba zrobić
$gdInfo = gdinfo(); $ver = $gdInfo['GD Version']
O generatorach można zapomnieć, OOP prawie nie ma. OKDR.
bart
--
"Chopin w 1839 roku przebywał na Majorce wraz ze swoim przyjacielem,
znanym pisarzem George'em Sandem" (c) PAP & Gazeta Wyborcza
http://candajon.azorragarse.info/ http://azorragarse.candajon.info/
Tupteq
> W tę stronę, to bezproblemowo. W drugą gorzej. Po dwóch latach robienia w Pythonie
> przyszło mi pisać w Javie i PHP. Dżizas, toż w PHP jest sobie np. głupia
> funkcja gdinfo() zwracająca słownik. Ze słownika interesuje mnie jedno pole,
> ale w PHP nie da się zrobić $ver = gdinfo()['GD Version'], trzeba zrobić
> $gdInfo = gdinfo(); $ver = $gdInfo['GD Version']
> O generatorach można zapomnieć, OOP prawie nie ma. OKDR.
To ja też coś powiem o wędrówce w drugą stronę - ku C++. Myślałem, że to
bedzie tragedia, ale tragedią nie było - C++ jest dla mnie teraz takim
fajnym językiem "łamigłówkowym" (jak chcę trochę pogłówkować i
poutrudniać sobie życie, to piszę coś w C++ w ramach treningu). Dużo
nawyków z Pythona można łatwo przenieść do C++ i to z korzyścią dla tego
drugiego. Na pewno chętniej używam referencji w C++ niż moi znajomi
"nieskażeni" Pythonem. Wydaje mi się, że w pisaniu pomaga też bardziej
abstrakcyjne podejście, którego człowiek uczy się obcując z Pythonem.
Natomiast powrót do PHP to była porażka - ta fatalna składnia mnie po
prostu dobija, nie mówiąc już o tych dziwnych funkcjach i topornym
kodzie (mówię raczej o PHP w okolicach 4, nie o 5).
--
Pozdro... Tupteq
Arson
musialbym odpisac na kazdego z osobna to samo :)
Dziekuje wszystkim za opinie. Przy okazji jest to pozytywne odczucie, ze
jest aktywna spolecznosc wokol pythona.
Na razie lece poprzez podstawy pythona i staram sie wylapywac roznice
miedzy C++/PHP5 zeby potem nie okazalo sie ze cos prostego robi sie
innaczej niz mi sie zdaje ;) Niestety jest to proces dosc nudny i na
razie z fajniejszych rzeczy wylapalem tylko wciecia w kodzie i ogolnie
czytelnosc. Reszty roznic nie jestem jeszcze w stanie ocenic
pozytywnie/negatywnie.
Na pewno fajna sprawa w pythonie jest to ze w jednym jezyku mozna robic
stronki i aplikacje, chociaz w PHP tez jest to mozliwe dzieki GTK i QT.
Pytanko: Czy do pythona tez sa takie frameworki jak np. Codeigniter,
CakePHP czy ZendFramework do PHP ? Jesli tak to prosze o pare nazw.
Jeszcze raz dzieki za odpowiedzi :)
Pozdrawiam,
Arek
Arson
oddzielnym watku.
Mozecie jeszcze polecic jakies narzedzia do pythona? Taki podstawowy
"must have" :)
Pozdrawiam,
Arek
Piotr Keplicz
> Pytanko: Czy do pythona tez sa takie frameworki jak np. Codeigniter,
> CakePHP czy ZendFramework do PHP ? Jesli tak to prosze o pare nazw.
Tak postawione pytanie mogłoby sugerować, że frameworki PHP można uznać za
wzorcowe dla tego typu zastosowań ;-)
Słowa kluczowe do sprawdzenia: Pylons, Django, Turbogears :)
.pk.
Radomir 'The Sheep' Dopieralski
Arson wrote:
Vim. Serio.
--
Radomir `The Sheep' Dopieralski <http://sheep.art.pl>
Rafał Zawadzki
> At Fri, 04 Apr 2008 20:37:40 +0200,
> Arson wrote:
>
>> Sory, ze troche smiece na grupie ale w sumie to i tak powinno isc w
>> oddzielnym watku.
>>
>> Mozecie jeszcze polecic jakies narzedzia do pythona? Taki podstawowy
>> "must have" :)
>
> Vim. Serio.
>
Ponieważ?
Dużo przydatniejszy będzie ipython..
--
bluszcz
"Don't criticise yourself, it's my privilige." - Bitter Moon
http://web-dev.pl - Dynamiczny świat internetowych aplikacji od środka
Jarek Zgoda
> Mozecie jeszcze polecic jakies narzedzia do pythona? Taki podstawowy
> "must have" :)
dobry edytor, z którym nie trzeba walczyć
ipython
pyflakes
--
Jarek Zgoda
http://zgodowie.org/
"We read Knuth so you don't have to" - Tim Peters
Daniel Podlejski
> > Vim. Serio.
> >
>
> Ponieważ?
Jest lekki, wygodny, elastyczny, bardzo konfigurowalny,
działa zdalnie w terminalu i lokalnie pod wszystkimi
liczącymi się systemami operacyjnymi. Ma wszystko co
trzeba i łatwo go dostosować do swoich potrzeb.
> Dużo przydatniejszy będzie ipython..
Chyba nie zamiast edytora? ;)
--
Daniel Podlejski
Adam Mikuta
>> > Vim. Serio.
>> Ponieważ?
> Jest lekki, wygodny, elastyczny, bardzo konfigurowalny,
> działa zdalnie w terminalu i lokalnie pod wszystkimi
> liczącymi się systemami operacyjnymi. Ma wszystko co
> trzeba i łatwo go dostosować do swoich potrzeb.
I użytkownik będzie się męczył z trybami vima zamiast skupić na tym na
czym chciał się skupić - na pythonie.
(Napisane przy pomocy vima ;) )
--
Adam "Prawda jest prosta - gdyby było inaczej
każdy głupiec mógłby ją zrozumieć".
Daniel Podlejski
> I użytkownik będzie się męczył z trybami vima zamiast skupić na tym na
> czym chciał się skupić - na pythonie.
Męczył? Kwestia opanowania narzędzia.
Używam vima ponad 10 lat. Tylko przez pierwszy tydzień było trudno.
W tym czasie "przerobiłem" różne języki programowania, kilku używam
nadal do różnych zastosowań, o kilku zapomniałem, za to vim ciągle
ten sam. Miałem kilka podejść do tych wszyskich Eclipsów, NetBeansów
i innych ZendStudiów - zawsze stwierdzałem, że to jednak nie to.
Pewnie dlatego, że nie ma w nich rozróżnienia na różne tryby pracy
jak w vimie. ;)
Dla mnie vim + mc + screen + svn lub odpowiednik jest w przypadku
programowania server side i okolic w dowolnym języku niezastąpionym
zestawem narzędzi.
--
Daniel Podlejski
i0cus
Łatwiejsze iterowanie, nie obchodzi Cię sprawdzanie gdzie co się
zaczyna, a gdzie kończy. Do tego typy kontenerowe wiedzą co to
polimorfizm i nie mają z nim żadnych problemów. Pełna wirtualizacja
metod jest bardzo intuicyjna, otwarte klasy są banalne, wielokrotne
dziedziczenie bywa fikuśne. Trochę boli brak prawdziwych destruktorów.
Obsługa wyjątków to, dla odmiany, czysta przyjemność. Do tego dużo
świetnych bibliotek = kompletny skrypt po imporcie i kilku wywołaniach
interfejsu. Wiele naleciałości z powłok uniksowych i z C, więc po
doświadczeniu z C++ (biblioteki <c*>) powinno się trochę czuć klimat.
Przesiadka z PHP to świetna sprawa -- wreszcie dostajesz dopracowany
język z dynamicznym typowaniem. Do tego ładny i zgrabny, a średnia
wieku userów wydaje się być trochę bardziej oddalona od 15.
--
pozdrawiam,
Sławek Gwizdowski
Kacper Perschke
>> Pytanko: Czy do pythona tez sa takie frameworki [...]
> [...]
> Słowa kluczowe do sprawdzenia: Pylons, Django, Turbogears :)
Jeszcze 'python web framework' oraz zope.
KAcper
--
Mail => www.rot13.com
Szymon
> On 4 Kwi, 13:59, Arson <areks...@gmail.com> wrote:
>> Witam serdecznie,
>>
>> Od dawna siedze w C++. Od jakiegos czasu zajmuje sie tylko PHP5.
>> Naszla mnie ochota nauczyc sie pythona.
>> Moze ktos moglby sie podzielic wlasnym doswiadczeniem z podobnej przesiadki?
>
> Łatwiejsze iterowanie, nie obchodzi Cię sprawdzanie gdzie co się
> zaczyna, a gdzie kończy.
Czy to jest porównanie pythona do C++? Przecież w C++ też nie trzeba
sprawdzać co gdzie się kończy i gdzie zaczyna, a iterowanie (np
for_each) to przecież jedna instrukcja.
--
i0cus
1) Miałem na myśli (for (T i=v.begin(); i!=v.end(); i++) {}), ale
przecież wspomniany przez Ciebie
2) for_each (odpowiednik map) nadal wymaga podania głowy i tyłka
iteratora, prawda? A to dlatego, że ta funkcja to sprawdza
wewnętrznie. I to jest programowanie niskopoziomowe w porównaniu z
Pythonem, Ruby czy nawet Prologiem i Haskellem.
Ja nie napadam na C++, po prostu zauważam różnice. Można sobie w C++
iterować forem, można sobie też pomóc whilem -- co kto lubi. Jednak za
każdym razem musisz pamiętać o początku, końcu i przewinięciu
(boundaries). Kod Pythonowy jest pod tym względem prostszy i
przyjemniejszy -- kontener w pętli zwraca iterator implicite -> pętla
przechodzi po nim ,,w tle'' -> spoglądasz na kod i nie zastanawiasz
się nad Oroborosem. Moja definicja ,,wyższego poziomu''.
--
pozdrawiam,
SG
Szymon
> On 6 Kwi, 09:28, Szymon <_news_@_mabateus_._pl_WITHOUT_> wrote:
>> i0cus pisze:
>>
>>> On 4 Kwi, 13:59, Arson <areks...@gmail.com> wrote:
>>>> Witam serdecznie,
>>>> Od dawna siedze w C++. Od jakiegos czasu zajmuje sie tylko PHP5.
>>>> Naszla mnie ochota nauczyc sie pythona.
>>>> Moze ktos moglby sie podzielic wlasnym doswiadczeniem z podobnej przesiadki?
>>> Łatwiejsze iterowanie, nie obchodzi Cię sprawdzanie gdzie co się
>>> zaczyna, a gdzie kończy.
>> Czy to jest porównanie pythona do C++? Przecież w C++ też nie trzeba
>> sprawdzać co gdzie się kończy i gdzie zaczyna, a iterowanie (np
>> for_each) to przecież jedna instrukcja.
>
> 1) Miałem na myśli (for (T i=v.begin(); i!=v.end(); i++) {}), ale
> przecież wspomniany przez Ciebie
> 2) for_each (odpowiednik map) nadal wymaga podania głowy i tyłka
> iteratora, prawda? A to dlatego, że ta funkcja to sprawdza
> wewnętrznie. I to jest programowanie niskopoziomowe w porównaniu z
> Pythonem, Ruby czy nawet Prologiem i Haskellem.
>
To 'moje' for_each wymaga podania początku i końca tylko dlatego, że
może służyć np. do przelecenia się tylko po pierwszych 5 elementach,
natomiast jak chcesz wszystkie to robisz foreach od begin() do end().
Jak chcesz iść dalej to zrób sobie my_for_each, który będzie leciał
automatycznie od begin() do end() i też nie masz konieczności dokładnego
pamiętania gdzie początek a gdzie koniec.
Grzegorz Staniak
> To 'moje' for_each wymaga podania początku i końca tylko dlatego, że
> może służyć np. do przelecenia się tylko po pierwszych 5 elementach,
> natomiast jak chcesz wszystkie to robisz foreach od begin() do end().
> Jak chcesz iść dalej to zrób sobie my_for_each, który będzie leciał
> automatycznie od begin() do end() i też nie masz konieczności dokładnego
> pamiętania gdzie początek a gdzie koniec.
To jest nadal wyraźnie nadmiarowe w stosunku do pythonowego "for ... in ...".
GS
--
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Szymon
Nadmiarowe bo daje większe możliwości? Za to średnio zrobisz za pomocą
tego for in w pythonie iterację w elementach od końca kontenera :)
Marcin Sztolcman
> Nadmiarowe bo daje większe możliwości? Za to średnio zrobisz za pomocą
> tego for in w pythonie iterację w elementach od końca kontenera :)
Mówisz może o:
l = [1,2,3,4,5]
for i in reversed (l):
print i
lub może o:
for i in l[::-1]:
print i
?
MySZ
--
Marcin Sztolcman :: http://urzenia.net/ :: http://sztolcman.eu/
Grzegorz Staniak
>>> To 'moje' for_each wymaga podania początku i końca tylko dlatego, że
>>> może służyć np. do przelecenia się tylko po pierwszych 5 elementach,
>>> natomiast jak chcesz wszystkie to robisz foreach od begin() do end().
>>> Jak chcesz iść dalej to zrób sobie my_for_each, który będzie leciał
>>> automatycznie od begin() do end() i też nie masz konieczności dokładnego
>>> pamiętania gdzie początek a gdzie koniec.
>>
>> To jest nadal wyraźnie nadmiarowe w stosunku do pythonowego "for ... in ...".
>
> Nadmiarowe bo daje większe możliwości?
Jakie konkretnie?
> Za to średnio zrobisz za pomocą
> tego for in w pythonie iterację w elementach od końca kontenera :)
Dostałeś już przykłady: reversed() lub [::-1].
Sulsa
Szymon <_news_@_mabateus_._pl_WITHOUT_> wrote:
> Jak chcesz iść dalej to zrób sobie my_for_each...
i to jest typowa odpowiedz na grupie c++, w bibliotece standardowej c++
jest nie wiele rzeczy, a na wiekszosc pytan czy cos jest mozna uslyszec
odpowiedz: nie, ale przeciez mozesz sobie to zrobic sam w 10 linijkach
i tak po 20 zupelnie podstawowych operacjach program, ktory powinien
miec kilkadziesiat linijek ma ich prawie tysiac.
--
Szymon
To nieco inaczej. Po prostu bawi mnie jak słyszę, że w C++ nie ma tego
czy tamtego, że np. nie można sobie iterować itd. Iterować można, ale
oczywiście źle, że trzeba podać początek i koniec iteracji. Cóż, nawet
tego nie trzeba wyznaczać/wyliczać/obliczać bo to zawsze begin()-end().
Poza tym jeśli chodzi o długość linii to też nie jest tak, bo przecież
samo for in w pythonie zajmuje tyle samo linii co for_each w C++, więc
ten argument też jest taki sobie.
A co do tego, że program ma więcej linii to cóż.. liczba linii nie jest
wykładnikiem czytelności programu, co najwyżej wyznacznikiem tego czy
coś można napisać szybko czy wolno. A szybkie pisanie nie ma nic
wspólnego z porządnie napisanym programem. Jak dla mnie to program ma
być czytelny i łatwy w zarządzaniu kodem czy modyfikacjami.
Grzegorz Staniak
>> i to jest typowa odpowiedz na grupie c++, w bibliotece standardowej c++
>> jest nie wiele rzeczy, a na wiekszosc pytan czy cos jest mozna uslyszec
>> odpowiedz: nie, ale przeciez mozesz sobie to zrobic sam w 10 linijkach
>> i tak po 20 zupelnie podstawowych operacjach program, ktory powinien
>> miec kilkadziesiat linijek ma ich prawie tysiac.
>
> To nieco inaczej. Po prostu bawi mnie jak słyszę, że w C++ nie ma tego
> czy tamtego, że np. nie można sobie iterować itd. Iterować można, ale
> oczywiście źle, że trzeba podać początek i koniec iteracji. Cóż, nawet
> tego nie trzeba wyznaczać/wyliczać/obliczać bo to zawsze begin()-end().
> Poza tym jeśli chodzi o długość linii to też nie jest tak, bo przecież
> samo for in w pythonie zajmuje tyle samo linii co for_each w C++, więc
> ten argument też jest taki sobie.
> A co do tego, że program ma więcej linii to cóż.. liczba linii nie jest
> wykładnikiem czytelności programu, co najwyżej wyznacznikiem tego czy
> coś można napisać szybko czy wolno. A szybkie pisanie nie ma nic
> wspólnego z porządnie napisanym programem. Jak dla mnie to program ma
> być czytelny i łatwy w zarządzaniu kodem czy modyfikacjami.
I uważasz, że Pythom taki nie jest? To wobec tego chyba jesteś na tej grupie
w wyraźnej mniejszości.
Python nie jest "lepszy" od C++, jest po prostu językiem wyższego poziomu.
Stąd krótkie, zwarte i treściwe "programy wyższego poziomu" tam, gdzie C++
wymaga dłuższych i bardziej rozgadanych. Dodatkowo, standardowa biblioteka
Pythona jest bardzo bogata, co ułatwia pisanie parolinijkowców którym w C++
odpowiadają paroekranowce.
Sulsa
Szymon <_news_@_mabateus_._pl_WITHOUT_> wrote:
> A co do tego, że program ma więcej linii to cóż.. liczba linii nie jest
> wykładnikiem czytelności programu, ...
to napisz równie czytelnie w c++ instrukcje "ala ma kota".split('a')
>... co najwyżej wyznacznikiem tego czy
> coś można napisać szybko czy wolno.
zauważ że często trzeba zakodować mniej logiki(ukazuje to przykład
który podałem), a to przekłada się na mniej błędów, więc troche nie
trafiles z argumentem :P
--
Artur M. Piwko
Arson <arek...@gmail.com> screamed:
Z okienkowych - Komodo Edit.
--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:219B ]
[ 08:43:10 user up 11670 days, 20:38, 1 user, load average: 0.81, 0.01, 0.12 ]
Last one out, turn off the computer!
Arson
Natomiast dyskusje na temat wyzszosci ktoregokolwiek z jezykow osobiscie
uwazam za zbedna :)
Pozdrawiam,
Arek
William
Użytkownik "Tupteq" <tupte...@CIACHtlen.pl> napisał w wiadomości
news:ft5es2$lor$1...@news.onet.pl...
> Później poznasz generatory i okaże się, że czasem dużo rzeczy można zrobić
> bardzo prosto, a słówko "yield" to coś bardzo fajnego.
> Jest jeszcze trochę fajnych rzeczy, jak wyrażenia tworzace listy i
> generatory, lambda, złożone porównania ("3 < a < 5"), fajne biblioteki
> (dzięki którym stworzysz serwer http w 3 linijkach, a XMLa sparsujesz w
> dwóch) i wiele innych.
>
> Tyle tak na szybko. Ale reszta grupy na pewno doda coś od siebie.
>
Metaklasy są najfajniejsze
Krzysztof Stachlewski
> In the darkest hour on Fri, 04 Apr 2008 20:37:40 +0200,
> Arson <arek...@gmail.com> screamed:
>> Sory, ze troche smiece na grupie ale w sumie to i tak powinno isc w
>> oddzielnym watku.
>>
>> Mozecie jeszcze polecic jakies narzedzia do pythona? Taki podstawowy
>> "must have" :)
>
> Z okienkowych - Komodo Edit.
Chyba na sprzęcie z bardzo dobrym procesorem.
I może pełna, płatna wersja. Może wtedy działa żwawiej.
Czekanie po sekundę na rozwinięcie listy plików
w drzewie katalogów to nie dla mnie.
No, z drugiej strony, taki vim to pewnie i tego nie ma?
PSPad się też nadaje, jeśli pracuje się pod Windowsem.
Stach
i0cus
Więc _za każdym razem_ gdy chcę _wszystkie elementy_ i tak muszę podać
początek i koniec, albo napisać sobie raz własną protezę?
Programowanie niskopoziomowe btd. Jak chcę pierwszych pięć elementów
to robię sobie wycinek (slice, islice), a jak chcę filtrować/brać z
warunkiem/nie brać z warunkiem to używam itertools -- pojedyncze
wywołanie. Kod jest czytelniejszy, pętla ta sama i nadal piszę mniej.
To jest różnica w poziomie abstrakcji.
Jeszcze raz: nie napadam na C++, bo nic do niego nie mam. Różnice są i
Twoja ich interpretacja jest różna od interpretacji ogółu (bo pisząc
za każdym razem więcej nie piszesz mniej). Moje porównanie było mniej
więcej jak porównanie młotka i śrubokręta: jedno służy do wbijania
gwoździ, drugie do obsługi manualnej elementów gwintowanych. Niby
podobne cele, a jednak do zupełnie różna filozofia. (Hint: co jest
młotkiem a co śrubokrętem w tym porównaniu nie ma znaczenia, k? ;-)
--
pozdrawiam
SG
Adam Mikuta
>> I użytkownik będzie się męczył z trybami vima zamiast skupić na tym na
>> czym chciał się skupić - na pythonie.
> Męczył? Kwestia opanowania narzędzia.
No właśnie. Na początku (jeśli się nie zna jeszcze vima) łatwiej będzie
poznać język przy pomocy jakiegoś nie stwarzającego większych problemów
edytora. Bo tak to nowy język, dziwny edytor, może jeszcze zmiana
systemu operacyjnego...
> Używam vima ponad 10 lat. Tylko przez pierwszy tydzień było trudno.
> W tym czasie "przerobiłem" różne języki programowania, kilku używam
> nadal do różnych zastosowań, o kilku zapomniałem, za to vim ciągle
> ten sam. Miałem kilka podejść do tych wszyskich Eclipsów, NetBeansów
> i innych ZendStudiów - zawsze stwierdzałem, że to jednak nie to.
> Pewnie dlatego, że nie ma w nich rozróżnienia na różne tryby pracy
> jak w vimie. ;)
Ja nie pamiętam ile używam ale będzie z połowę krócej. Mimo że w pracy
wszystkie narzędzia sa pointegrowane z eclipse i tak wolę pisać w vimie.
Mimo wszystko jak ktoś mnie pyta jak tu zaczać z pythonem nie wciskam mu
od razu vima na starcie. Niech jednak te początki będa w miarę łagodne.
;)
Mikolaj Machowski
> Czekanie po sekundę na rozwinięcie listy plików
> w drzewie katalogów to nie dla mnie.
> No, z drugiej strony, taki vim to pewnie i tego nie ma?
Trzeba odpowiednią wtyczkę dociągnąć.
m.
--
LaTeX + Vim = http://vim-latex.sourceforge.net/
Vim Universal Templates: http://vim.sf.net/script.php?script_id=1078
vim.pl - http://skawina.eu.org/mikolaj
CLEWN - http://clewn.sf.net
Artur Lew
> czy tamtego, że np. nie można sobie iterować itd. Iterować można, ale
Mimo ze to potezne narzedzie to zostalo stworzone przez jakiegos chorego
matematyka ktory nie widzial programowania w praktyce. Nie sposob
pominac zajebista biblioteke do stringow w ktorej masz mnostwo metod do
ich obslugi pod warunkiem ze je sobie sam napiszesz. Nie wspomne ze
pozorna szybkosc jest okupiona brakiem wiekszosci walidacji przed
wykroczeniem poza zakres, itp. Nie sposob nie wspomniec ze STL-i jest
kilka i kazdy lepszy od drugiego ;) Wiem jak to wyglada w praktyce - ta
sama implementacja inaczej dziala np w VC6/2003 a inaczej na AIX.
> samo for in w pythonie zajmuje tyle samo linii co for_each w C++, więc
Pokaz mi ludzi uzywajacych algorytmu for_each w C++.
Wielu zapewne nawet nie wie ze jest taka mozliwosc albo mysla ze to
cecha managed C++ w VC ;)
> A co do tego, że program ma więcej linii to cóż..
Przepisywalem juz kilkanascie projektow z C++ na Pythona.
Legendarny przelicznik 15:1 nie jest wyssany z palca.
I to mowie tutaj o prostych projektach po kilka tysiecy lini kodu w
Pythonie do zaawansowanego srodowiska medycznego RAD.
Nie wspomne ze zamiast spedzac czas na codeproject czy codesearch ;)
i szukac jak obsluzyc np base64 czy md5 tylko siedzie i klepie uzywajac
tylko chm-a ;)
> wykładnikiem czytelności programu,
Czytelnosc programu to prosta i przejrzysta skladnia ulatwiajaca
znalezienie potencjalnych bledow. Niestety w C++ jest tyle coding
standardow ilu programistow.
Natomiast wg standardow przemyslowych istnieje inny bardzo prosty
wyznacznik - mniej kodu - mniej bledow.
Jezeli cos zapiszesz w kilkunastokrotnie mniejszej ilosci kodu i
zachowasz przejrzystosc (w Pythonie to nietrudne dzieki skladni)
to odpowiedz klaruje sie sama.
> wspólnego z porządnie napisanym programem.
To fakt.
> być czytelny i łatwy w zarządzaniu kodem czy modyfikacjami.
To fakt.
--
Pozdrawiam
Artur Lew
arturdotlewatgmaildotcom
Szymon
> Szymon wrote:
>> czy tamtego, że np. nie można sobie iterować itd. Iterować można, ale
> W tym sek ze nie ma. Co z tego ze jest STL ?
> Mimo ze to potezne narzedzie to zostalo stworzone przez jakiegos chorego
> matematyka ktory nie widzial programowania w praktyce. Nie sposob
> pominac zajebista biblioteke do stringow w ktorej masz mnostwo metod do
> ich obslugi pod warunkiem ze je sobie sam napiszesz. Nie wspomne ze
> pozorna szybkosc jest okupiona brakiem wiekszosci walidacji przed
> wykroczeniem poza zakres, itp. Nie sposob nie wspomniec ze STL-i jest
> kilka i kazdy lepszy od drugiego ;) Wiem jak to wyglada w praktyce - ta
> sama implementacja inaczej dziala np w VC6/2003 a inaczej na AIX.
>
No niestety, ale samo C++ też ma swoje odmiany i nie jest w pełni
przenośne pomiędzy platformami.
>> samo for in w pythonie zajmuje tyle samo linii co for_each w C++, więc
> Pokaz mi ludzi uzywajacych algorytmu for_each w C++.
> Wielu zapewne nawet nie wie ze jest taka mozliwosc albo mysla ze to
> cecha managed C++ w VC ;)
>
To mnie raczej średnio interesuje. To jest taki sam poziom znajomości
jakim się wykazał ostatnio jeden pan co to mnie egzaminował, w sprawie
pracy, z C++. Na moją odpowiedź na pytanie o rodzaje dziedziczenia,
zaczął mi wmawiać, że takiego wirtualnego to raczej nie ma. Tak samo jak
większość znanych mi ludzi, którzy mają jakieś pojęcie o C++ nie wie nic
o STLu, chociaż uważają, że znają C++ świetnie :)
>> A co do tego, że program ma więcej linii to cóż..
> Przepisywalem juz kilkanascie projektow z C++ na Pythona.
> Legendarny przelicznik 15:1 nie jest wyssany z palca.
> I to mowie tutaj o prostych projektach po kilka tysiecy lini kodu w
> Pythonie do zaawansowanego srodowiska medycznego RAD.
> Nie wspomne ze zamiast spedzac czas na codeproject czy codesearch ;)
> i szukac jak obsluzyc np base64 czy md5 tylko siedzie i klepie uzywajac
> tylko chm-a ;)
>
hm...
>> wykładnikiem czytelności programu,
> Czytelnosc programu to prosta i przejrzysta skladnia ulatwiajaca
> znalezienie potencjalnych bledow. Niestety w C++ jest tyle coding
> standardow ilu programistow.
A to, że niby w Pythonie jest jeden standard?
Jak chcesz mieć jeden przyjęty standard kodowania to najlepiej zrobić to
tak jak np. w Adzie:
-gnatr
Normally, GNAT permits any source layout consistent with the Ada 95
reference manual requirements. This switch (`r' is for "reference
manual") enforces the layout conventions suggested by the examples and
syntax rules of the Ada 95 Language Reference Manual. For example, an
else must line up with an if and code in the then and else parts must be
indented. The compiler treats violations of the layout rules as syntax
errors if you specify this switch.
I wtedy jak layout kodu jest inny niż zalecany to program się nie
skompiluje.
Nie znam na tyle pythona, może tam jest coś takiego, jakby było to
fajnie, jak nie, to nie można pisać o jedynie słusznej składni, bo same
wcięcia to nie wszystko.
Artur Lew
> A to, że niby w Pythonie jest jeden standard?
A tak na powaznie to skladnia tego jezyka wymusza pisanie programow w
dosc charakterystyczny sposob. Zwiazane jest to z strosunkowo prostym
wachlarzem konstrukcji ktore tutaj mozesz uzyc.
Ten charakterystyczny sposob pisania kodu to blogoslawienstwo.
Docenia to osoby wdrazajace i nadzorujace coding standards w firmie :)
W firmie zajmuje sie od ladnych paru lat m in, zarzadzaniem kodu ktory
ma juz cos ponad 15 lat... Uwierz mi prosta skladnia i minimalizm w
kwesti wyboru tej czy innej konstrukcji przez programiste to
blogoslawienstwo.
> I wtedy jak layout kodu jest inny niż zalecany to program się nie
> skompiluje.
:)
Tutaj jak sie rabniesz we wzieciu to masz szanse dostal ladny wyjatek ;)
> wcięcia to nie wszystko.
Na ile sposobow mozesz zapisac ?
if not val:
print 'txt'
w przeciwienstwie:
if (!val){
printf("txt");
}
lub
if (!val)
{
printf("txt");
}
lub
if (!val)
{
printf("txt");
}
Dodam ze w 300 osobowej firmie robilem sonde i do samych ifow bylo jak
pamietam cos kolo 8 propozycji ;)
Powyzszy przyklad moze niezbyt pokazowy ale wez pod uwage mnogosc petli,
czy innych konstrukcji w C/C++. Od podstawowki wmawiaja Ci kiedy i jak
zapisach while ,do... while, for, for_each, etc...
Tutaj masz jedna petle w zwiazku z tym nikt na sile nie wymysla czegos
nowego...
Sprawe dodatkowo komplikuja szablony.
To nic ze spedzisz 2 dni na szukaniu buga w "> >", to nic ze byle jaki
problem kompilacji generuje dziesiatki KB ostrzezen ktore niewiele mowia
(chociazby slynny ";" na koncu deklaracji klasy).
To nic ze wmawiaja Ci ze Spirit jest napisany przez geniusza chociaz za
cholere nie mozesz do konca spamietac skladni :D
Pamietam jak ostatnio kolega cieszyl sie jak dziecko jak zobaczyl
pythonowy slownik. Cale zycie jakos udalo mu sie bez niego obejsc,
konstrukcja z STL-a pomijajac wiele bugow pod VC nie kusi prostota
zapisu z pair value.
--
Pozdrawiam
Artur Lew
http://republika.pl/artee
arturdotlewatgmaildotcom
Szymon
> Szymon wrote:
>> A to, że niby w Pythonie jest jeden standard?
> Biorac pod uwage Guido - tak jeden ;)
> A tak na powaznie to skladnia tego jezyka wymusza pisanie programow w
> dosc charakterystyczny sposob. Zwiazane jest to z strosunkowo prostym
> wachlarzem konstrukcji ktore tutaj mozesz uzyc.
> Ten charakterystyczny sposob pisania kodu to blogoslawienstwo.
> Docenia to osoby wdrazajace i nadzorujace coding standards w firmie :)
> W firmie zajmuje sie od ladnych paru lat m in, zarzadzaniem kodu ktory
> ma juz cos ponad 15 lat... Uwierz mi prosta skladnia i minimalizm w
> kwesti wyboru tej czy innej konstrukcji przez programiste to
> blogoslawienstwo.
>
Niby tak, ale sama możliwość używania tabów, 2 spacji, 4 spacji, 8
spacji itd... powoduje, że kod wcale nie musi być łatwy w zarządzaniu
jeśli się nie wymusi na siłę jakichkolwiek zasad. I to się tyczy każdego
języka, zgodnie z zasadą, której hołduję, że zawsze jakikolwiek standard
jest lepszy niż jego brak, to nawet w C++ można ustalić sobie w zespole
jak się to pisze i tego pilnować.
>> I wtedy jak layout kodu jest inny niż zalecany to program się nie
>> skompiluje.
> :)
> Tutaj jak sie rabniesz we wzieciu to masz szanse dostal ladny wyjatek ;)
>
Albo i nie...
if costam:
terefere
costam
blebleble
I teraz zonk, te dwie ostatnie linie wkleiłem sobie do pliku i mi edytor
źle wciął. Poza tym mogę to wkleić z pliku, w którym miałem 2 spacje, do
pliku, w którym stosuję 4 spacje... i program się kompiluje, ale źle
działa, najgorszy rodzaj błędu jaki może być.
Tak sobie piszę ostatnio sporo w pythonie, a przynajmniej się staram i
jakoś mnie to wkurza, to już wolę begin/end albo klamerki.
>> wcięcia to nie wszystko.
> Na ile sposobow mozesz zapisac ?
> if not val:
> print 'txt'
> [CUT]
Mogę mieć taby i n-spacji. Problemu nie będzie jak sobie ustalisz
jakikolwiek standard.
> Dodam ze w 300 osobowej firmie robilem sonde i do samych ifow bylo jak
> pamietam cos kolo 8 propozycji ;)
fajne
> Powyzszy przyklad moze niezbyt pokazowy ale wez pod uwage mnogosc petli,
> czy innych konstrukcji w C/C++. Od podstawowki wmawiaja Ci kiedy i jak
> zapisach while ,do... while, for, for_each, etc...
> Tutaj masz jedna petle w zwiazku z tym nikt na sile nie wymysla czegos
> nowego...
> Sprawe dodatkowo komplikuja szablony.
> To nic ze spedzisz 2 dni na szukaniu buga w "> >", to nic ze byle jaki
owszem, 2 dni spędziłem, i kolejne 2 dni na tym:
for ( int i = 0 ; i < costam.size(); i++) :))))
> problem kompilacji generuje dziesiatki KB ostrzezen ktore niewiele mowia
> (chociazby slynny ";" na koncu deklaracji klasy).
Ale to może kwestia czegoś innego, 99% programistów olewa/wyłącza
ostrzeżenia, a potem płączą
> Pamietam jak ostatnio kolega cieszyl sie jak dziecko jak zobaczyl
> pythonowy slownik. Cale zycie jakos udalo mu sie bez niego obejsc,
> konstrukcja z STL-a pomijajac wiele bugow pod VC nie kusi prostota
> zapisu z pair value.
>
Mi tam jakoś to nie przeszkadzało :) Ale nie ukrywam, że w pythonie
część rzeczy jest lepsza, fajniejsza, ale to jak wszędzie, w C++ też
część rzeczy jest fajniejsza niż w pythonie.
Grzegorz Staniak
>> A tak na powaznie to skladnia tego jezyka wymusza pisanie programow w
>> dosc charakterystyczny sposob. Zwiazane jest to z strosunkowo prostym
>> wachlarzem konstrukcji ktore tutaj mozesz uzyc.
>> Ten charakterystyczny sposob pisania kodu to blogoslawienstwo.
>> Docenia to osoby wdrazajace i nadzorujace coding standards w firmie :)
>> W firmie zajmuje sie od ladnych paru lat m in, zarzadzaniem kodu ktory
>> ma juz cos ponad 15 lat... Uwierz mi prosta skladnia i minimalizm w
>> kwesti wyboru tej czy innej konstrukcji przez programiste to
>> blogoslawienstwo.
>
> Niby tak, ale sama możliwość używania tabów, 2 spacji, 4 spacji, 8
> spacji itd... powoduje, że kod wcale nie musi być łatwy w zarządzaniu
> jeśli się nie wymusi na siłę jakichkolwiek zasad.
Eee. Jeśli masz oddzielne pliki, to możesz w nich mieć i 10 konwencji
a całość będzie działała poprawnie, spójność musisz zachować tylko
w obrębie pojedynczego pliku. A konwersja jest trywialna.
> I to się tyczy każdego
> języka, zgodnie z zasadą, której hołduję, że zawsze jakikolwiek standard
> jest lepszy niż jego brak, to nawet w C++ można ustalić sobie w zespole
> jak się to pisze i tego pilnować.
Oczywiście. Niemniej sama składnia Pythona współpracuje w tym względzie
z menedżerem projektu, a i PEP8 jest dość znany i popularny.
Sulsa
Szymon <_news_@_mabateus_._pl_WITHOUT_> wrote:
>
> if costam:
> terefere
> costam
> blebleble
>
> I teraz zonk, te dwie ostatnie linie wkleiłem sobie do pliku i mi edytor
> źle wciął.i program się kompiluje, ale źle
> działa, najgorszy rodzaj błędu jaki może być.
no prosze a ile razy programisci zrobili blad ze napisali
if (warunek)
cout<<"fuck"<<endl;
a pozniej pomysleli... a moze dodalbym cos jeszcze i zaraz dopisywali:
if(warunek)
cout<<"fuck"<<endl;
nowa_linia_w_stylu_stl(TAK_TO_JEST_OBIEKT);
strtok(saf) /* a tu nowa lini w stylu c ni w ząb nie podobna do
tej wyzej */
i zgadnij co.... powrot do twojego komentarza
> I teraz zonk, te dwie ostatnie linie wkleiłem sobie do pliku i mi edytor
> źle wciął( = rypnąłem się) i program się kompiluje, ale źle
> działa, najgorszy rodzaj błędu jaki może być.
masz racje!
Szymon
> On Mon, 07 Apr 2008 21:43:59 +0200
> Szymon <_news_@_mabateus_._pl_WITHOUT_> wrote:
>
>> if costam:
>> terefere
>> costam
>> blebleble
>>
>> I teraz zonk, te dwie ostatnie linie wkleiłem sobie do pliku i mi edytor
>> źle wciął.i program się kompiluje, ale źle
>> działa, najgorszy rodzaj błędu jaki może być.
>
> no prosze a ile razy programisci zrobili blad ze napisali
> if (warunek)
> cout<<"fuck"<<endl;
> a pozniej pomysleli... a moze dodalbym cos jeszcze i zaraz dopisywali:
> if(warunek)
> cout<<"fuck"<<endl;
> nowa_linia_w_stylu_stl(TAK_TO_JEST_OBIEKT);
> strtok(saf) /* a tu nowa lini w stylu c ni w ząb nie podobna do
> tej wyzej */
>
> i zgadnij co.... powrot do twojego komentarza
>
hehe, dobre