Najłatwiejszy język programowania na początek

[beluosus]

Jeśli tak to spójrz na ten przykład i powiedz sobie szczerze, który kod wydaje ci się czytelniejszy: Pythona czy prawie 2 razy dł. C++?

Kod pythona: 140 linii, kod c++: 191. Więc nie mów, że prawie 2x dłuższy, bo jedynie o 26%. Żeby nie było niejasności, przy liczeniu ominąłem:
W cpp:
^\s*//.*
^\s*}\s*$
^\s*$
W py:
^\s*#+.*
^\s*$

Jeśli chodzi o wcięcia to nie mam z nimi problemu w pythonie, bo edytor pokazuje mi strzałki w miejscach w których jest użyty tabulator, poza tym jak wyżej wspomniano interpretator wskazuje błędy bez problemu. Aczkolwiek uważam, że styl pisania nie powinien być narzucany. Czy to zwiększa czytelność czy nie, kwestia subiektywna i raczej nie ma się co nad nią rozwodzić.

[rack]

Poleganie na typach zmiennych to nie jest dobra praktyka. W językach z dynamicznym typowaniem to woła o pomstę do nieba. One zostały napisane w taki sposób aby tego uniknąć. Jak ktoś jest przyzwyczajony przez 10 lat do statycznie typowanych zmiennych, to nie ma bata, będzie musiał mieć w sobie dużo samozaparcia aby to zmienić i nauczyć się nowego podejścia ...

Dynamiczne typwowanie w języku nie stanowi żadnej przeszkody ani utrudnienia. Wręcz przeciwnie. Piszecie testy do swojego kodu? Jeżeli tak to wszytsko powinno iść bez najmniejszych problemów, jeżeli nie to taki kod i tak jest g... wart. Niezależnie od geniuszu jaki został w niego włożony ...

Ja wolę zrobić wcięcie lub spacje niż wklepywać nawiasy i średniki. Raczej nie jestem w tym względzie odosobniony.

Zgadzam się z tym ze większośc wybiera statycznie typowane języki, tylko co to zmienia ... Jak zawsze trzeba rewolucji aby coś się wydarzyło, w tym przypadku ta rewolucja juz zachodzi. G. van Rossum, czy Matz nie stworzyli swoich języków jako zabawki, były one wynikiem frustracji wynikłym z ułomności statycznie typowanych języków czy ich braku przejrzystości. Ruby czy Python to jest następny krok dziedzinie prgramowania ... Ludzie niechętnie się do tego przyznają, zwłaszcza Ci, którzy od lat uzywają c czy javy, ale one robią ich o wiele bardziej produktywnymi, dając znacznie więcej swobody zwłaszcza w kontekście metaprogramowania ...

Ludzie odpowiedzialni za Pythona, Ryby, PHP itd. tez wyrośli w kulturze C, na szczęście jednak wyrwali się z niej i jej oganiczeń ... cała masa tych którzy nauczyli się raz C lub C++ nie potrafi tego zrobić i pewnie już tak pozostanie, bo z wiekiem co raz trudniej zmienić swoje przyzwyczajenia. Stają się one drugą naturą.

Języki wysokiego poziomu, to kolejny krok w rozwoju programowania, nie ma już powrotu ... one zostały wymyślone i sprawdziły się w tysiącach projektów, oszczędziły ludziom czasu, błędów, kosztów i frustracji ... Dobrych narzędzi nie wyrzuca się na śmietnik.

Kwestia czytelności, jest bardzo subiektywna i zależy mocno od doświadczenia w pracy z językiem. Nie powinna ona być argumentem w dyskusji. Podobnie wcięcia, załóżmy, że każdy kto napisał choć 1000 linii kodu w czymkolwiek robi to dla własnego dobra.


26% prcent w kontekście 10000 linijek kodu daje 2600 linii więcej , przelicz sobie to na czas pisania, debugowania, testowania ... ogólnie koszty ... właśnie straciłeś co najmniej kilka dni życia kolego ... !!!

pozdrawiam
S.Wojnowski

[kklimonda]

@rack Nie można porównywać Pythona czy Rubiego do C++ czy Javy - to zupełnie różne języki służące do rozwiązywania różnych problemów i do pracy w innych warunkach.

[rack]

Zarówno C, Java, Ruby i Python to języki ogólnego zastosowania ... Biblioteki dla C powstają latami ... napisanie biblioteki dla ruby czy pythona zabiera znacznie mniej czasu ... Dynamiczne języki mają juz biblioteki do niemal wszystkiego co zwykły śmiertelnik mógłby chcieć ... Biblioteki dla C powstają latami, binding dla statycznego języka to jedynie ułamek tego czasu ... To co napisane dla ruby nikt do C już nie tłumaczy ... tam gdzie ruby jest jeszcze zbyt wolny, spokojnie można dopisać kawałek kodu w C ... Nawet to zawsze zajmie mniej czasu i będzie wymagać mniej kodu od tej samej implementacji w C++ czy Javie ... Czas jest jedynym obiektywnym kryterium, wszystko inne jest relatywne ...

To co powstało dla Ruby lub Pythona (nie sa to same binidingi )) nie znajdzie już swojej drogi w tył do C ... Ten język jest zbyt drewniany, czasy się zmieniają, krajobraz też się zmienia, człowiek nie zatrzymuje się w miejscu ... ruby i python to krok do przodu a nie w tył ... krok do przodu w stosunku do C, mimo iż z jego wykorzystaniem ... Ktoś musiał wymyślić automobil abysmy dziś mogli patrzeć na ferrari w formule 1.

Cała ta dyskusja jest moim zdanie zupełnie jałowa ... każdy optuje za językiem, który zna, lubi i używa najczęściej ... to sa relatywne rzeczy, względne dla kazdego z nas ... nigdy nie dojdziemy w nich do porozumienia ... Dla mnie najistotniejszy w życiu jest czas i dlatego uważam,że ani java ani perl ani C, czy C++ nie będą wystarczająco dobre ... Prędzej czy później także innych ludzi nie będzie stać na poświęcanie takiej ilości czasu jakiej wymaga C++ czy java ... (nie wszyscy tez pewnie będą chcieli płacić za nadmiar roboczogodzin). Czasu nie da się zawrócić .. no chyba że jakaś mądra głowa wreszcie napisze jakiś program, który pozwoli nam go odzyskiwać ... przy czym będzie to zapewne zrobione w C bo tylko ten języki jest na to wystarczająco szybki ))

pozdrawiam
S.Wojnowski

[kklimonda]

Sprowadzasz programowanie do klepania kodu i na podstawie tego w którym języku kodu wyklepać musisz mniej piszesz który jest lepszy - taka dyskusja nie ma faktycznie sensu. By nie powtarzać tego co piszą inni po prostu dam ci linkę do ciekawego artykułu na podobny temat: http://www.netsplit.com/2009/03/26/the- ... languages/

[wojt03]

Jak już wspominałem jedynie pisanie w Pythonie jest dla mnie przyjemnością, nie dziwne więc, że starałem się przedstawić jego mocne strony. Muszę się w 100% zgodzić z użytkownikiem rack, gdyż uważam, że jednym z najważniejszych wyznaczników podczas wyboru języka programowania jest czas jaki przeznaczamy na napisanie w nim danego kodu. Długo by się rozwodzić nad wyższością konkretnego języka nad innym. Współczesnie jak już wspomniano programowanie powoli wkracza w wyższy poziom abstrakcji, niezależności od sprzętu. Śmiem twierdzić, że wysokopoziomowy Python ze swą przyjemniejszą dla człowieka, aniżeli "dla komputera" składnią jest w stanie nadal utrzymywać swą pozycję na rynku. Niemniej jednak języki takie jak C/C++ a nawet Asembler muszą nadal istnieć ze względu na swą wysoką wydajność i niezastąpione zastosowania (jądro systemu, sterowniki, moduły itp.).

[rack]

Sprowadzasz programowanie do klepania kodu ...

Pewnie że do tego to sprowadzam ... myślisz, że kodowanie to jakieś Zen ? Bez jaj )
Ja to robię tylko i wyłącznie dla kasy. Kiedyś było inaczej ... ale życie jest jakie jest, nie ma sentymentów ... a jak są to na nich się przegrywa ... Dlatego bez sentymentu pożegnałem C i powitałem ruby ... mam po prostu mniej klepania ))

Nie ma lepszego języka, jest tylko doświadczenie i oczekiwania człowieka ...

Wpis, który podlinkowałeś to subiektywna wizja i doświadzczenia autora ... temu ufam a temu nie, to lubię a tego nie ...
Co ja jemu poradze, że on nie potrafi określić, które własności i metody należą do którego obiektu. Skostniały mózg, który nie potrafi już myśleć w inny niż funkcjonalny sposób ... Czas na emeryturę iść ) Za dużo witaminy C, w tym przypadku nie jest ona usuwana z moczem z automatu jak podana w nadmiarze ))

pozdrawiam
S.Wojnowski

[luzakwielki]

Dynamiczne typwowanie w języku nie stanowi żadnej przeszkody ani utrudnienia. Wręcz przeciwnie.

Dynamiczne typowanie samo w sobie nie stanowi przeszkody - stanowi przeszkodę nie stosowanie kontroli typów jak w python czy php. W języku, którego sam używasz (ruby) jest silne typowanie tak samo jak w C++ (typ auto) i w razie problemu z typami wyrzuci runtime error (w C++ błąd kompilacji).

Ja wolę zrobić wcięcie lub spacje niż wklepywać nawiasy i średniki. Raczej nie jestem w tym względzie odosobniony.

Ale jesteś w znacznej mniejszości (niektórzy lubią być bici i też nie są odosobnieni, ale to nie oznacza, że jest to fajne dla większości).

Zgadzam się z tym ze większośc wybiera statycznie typowane języki, tylko co to zmienia ... Jak zawsze trzeba rewolucji aby coś się wydarzyło, w tym przypadku ta rewolucja juz zachodzi. G. van Rossum, czy Matz nie stworzyli swoich języków jako zabawki, były one wynikiem frustracji wynikłym z ułomności statycznie typowanych języków czy ich braku przejrzystości. Ruby czy Python to jest następny krok dziedzinie prgramowania ... Ludzie niechętnie się do tego przyznają, zwłaszcza Ci, którzy od lat uzywają c czy javy, ale one robią ich o wiele bardziej produktywnymi, dając znacznie więcej swobody zwłaszcza w kontekście metaprogramowania ...

Żadna rewolucja nie zachodzi tylko się języki skryptowe zmieniają - wcześniej od lat 70/80 popularnym językiem dynamicznym były bash i Smalltalk, w latach 90 traciły on popularność na rzecz perla - też była wtedy masa osób którzy mówili, że perl będzie zawsze, że jest rewolucja i języki takie jak C++ przestaną istnieć (było nawet jeszcze niedawno silne lobby, żeby w jądrze linuksa stosować perla)... a teraz perla wszyscy opuszczają i przechodzą na pythona/ruby - to żadna rewolucja, a ewolucja i tylko w ramach języków skryptowych, a z pewnością nie w dziedzinie programowania.
Metaprogramowania dla C++ są dodane (C++0x)... z tym, że mówiąc o metaprogramowaniu zdajesz sobie sprawę, że bardzo utrudnia to debuggowanie? Przez co programuje się dużo wolniej (czas programowania to nie tylko klepanie kodu, ale też wyszukiwanie błędów i testowanie).

Ludzie odpowiedzialni za Pythona, Ryby, PHP itd. tez wyrośli w kulturze C, na szczęście jednak wyrwali się z niej i jej oganiczeń ... cała masa tych którzy nauczyli się raz C lub C++ nie potrafi tego zrobić i pewnie już tak pozostanie, bo z wiekiem co raz trudniej zmienić swoje przyzwyczajenia. Stają się one drugą naturą.

Większość z tych osób, które nauczyli się programować w C znają dobrze języki dynamiczne - tylko po prostu łatwiej znaleźć doświadczonego programistę piszącego w C/C++, znającego np. pythona, niż doświadczonego programistę piszącego w pythonie znającego C/C++ - po prostu wybierają wygodniejsze rozwiązanie w którym się szybciej pisze i w którym się lepiej debugguje/profiluje.

Języki wysokiego poziomu, to kolejny krok w rozwoju programowania, nie ma już powrotu ... one zostały wymyślone i sprawdziły się w tysiącach projektów, oszczędziły ludziom czasu, błędów, kosztów i frustracji ... Dobrych narzędzi nie wyrzuca się na śmietnik.

A milionom zabrały zafundowały dodaktowy czas pracy, błędy, flustracji i kosztów... dlatego dobrych narzędzi jak C/C++ się nie wyrzuca i jeszcze przez długi czas się nie wyrzuci.

26% prcent w kontekście 10000 linijek kodu daje 2600 linii więcej , przelicz sobie to na czas pisania, debugowania, testowania ... ogólnie koszty ... właśnie straciłeś co najmniej kilka dni życia kolego ... !!!

Popatrz na kod, który ja dałem i widzisz, że nie jest 26%, a jest mniej kodu niż w pythonie... odejmij jeszcze linijki z '}' bo to jest tylko dla czytelności, a debugger i profiler nie będzie na nich nic robił więc nie tracisz na nie kilku dni... tracisz kilka dni za to na pythona/ruby gdzie dużo mniej wygodnie się debuguje i profiluje.

To co powstało dla Ruby lub Pythona (nie sa to same binidingi )) nie znajdzie już swojej drogi w tył do C ...

Przeważnie są to bindingi, a to co powstaje dla Ruby czy pythona nie jest przepisywane na C/C++ bo nie ma sensu - są tam już po prostu lepsze odpowiedniki i nikt piszący w C nie potrzebuje takich bibliotek (w drugą stronę się nie da i musi się robić bindingi, do popularniejszych bibliotek, żeby można było osiągnąć to co w C++ - czasami się nie da (biblioteki są w C++, a nie w C) i powstają nowe biblioteki).

[beluosus]

26% prcent w kontekście 10000 linijek kodu daje 2600 linii więcej , przelicz sobie to na czas pisania, debugowania, testowania ... ogólnie koszty ... właśnie straciłeś co najmniej kilka dni życia kolego ... !!!

Zakładając, że zaczynasz pisać projekt, który będzie zajmował 10k+ linii kodu raczej nie wywnioskujesz w jakim języku będzie zajmował on więcej/mniej. Poza tym mniej kodu nie musi oznaczać mniej czasu spędzonego nad nim. Np siadam do kodu, jest 300 linii, odchodzę po kilku godzinach i jest 250... Co jest? Cofnąłem się w czasie?

[kabanek]

wg mnie jak się wybiera język programowanie to powinno się wziąć kilka kryteria:
* jaki język programowania już znamy
* czy zależ nam na szybkości kodu, czy bardziej na wygodzie programowania
* czy interesuje nas przenośność (tutaj jest trochę płynne)
* jakie on ma możliwości (biblioteki itp)
* co w tym języku chcemy pisać
* czy jest do niego dobre wsparcie
* co w ogóle będziemy chcieli w nim pisać
* czy ten język nam się przyda po 10 latach, czy będziemy musieli go odłożyć, bo np na studiach czy w pracy zamiast pythona, perla itp będzie np c++ czy java
* sugestie innych programistów

Nie ma lepszego języka, jest tylko doświadczenie i oczekiwania człowieka ...

zgadzam się w 100%

[el.pescado]

Coś czuję, że nie znajdziecie porozumienia;)

@rack: patrzysz na wszystko przez pryzmat utylitarności, natomiast niektórzy po prostu lubią programować. Odwoływanie się do efektywności w takim wypadku to trochę tak, jakby zapalonemu wędkarzowi tłumaczyć że powinien kupić sobie trawler, którym może łowić setki ryb na godzinę, a on czasem siedzi pół dnia i nic nie złapie.

[luzakwielki]

zgadzam się w 100%

To dziwne, że się zgadzasz z nieprawdą - są lepsze języki programowania i nie zależy to od doświadczenia czy oczekiwań - zależy do czego ma być użyty:
Python/php/ruby etc. są gorszym wyborem do tworzenia gier/baz danych/aplikacji okienkowych niż C++ (w językach skryptowych wolniej działa, wolniej się pisze, trudniej debugować), w zastosowaniach komercyjnych o zamkniętym kodzie z oczywistych względów skryptowe odpadają (no chyba, że chcesz sobie osadzić interpreter w kodzie C/C++ i wpakować skrypty do szyfrowanego VFS'a ;p - ale odczytanie kodu źródłowego w tym przypadku też nie jest trudne - sprawdzasz co jest w pamięci po rozkodowaniu, a przed wrzuceniem do interpretera), w przypadku stron internetowych C++ jest zupełnie nietrafionym pomysłem (CGI i FastCGI są bardzo powolne, a inne języki są lepiej do tego celu dostosowane).

Język powinien być dostosowany do zadania, a nie do widzimisię programisty - a w przeciwieństwie do tego co próbują tu niektórzy wmówić ruby czy python nadają się jedynie do zastosowań typu: strona internetowa czy język osadzony w aplikacji C++ (czyli tam gdzie najczęściej kod nie przekracza paruset linijek)... w większych projektach (a nawet takich poniżej, dlatego nie stosuje się ich za często jako język osadzony, jeśli ma służyć on programistą z firmy, ale jeśli dla klientów to już może być) te języki pokazują swoje wady.

@rack: patrzysz na wszystko przez pryzmat utylitarności, natomiast niektórzy po prostu lubią programować. Odwoływanie się do efektywności w takim wypadku to trochę tak, jakby zapalonemu wędkarzowi tłumaczyć że powinien kupić sobie trawler, którym może łowić setki ryb na godzinę, a on czasem siedzi pół dnia i nic nie złapie.

Niektórzy lubią programować, a nie męczyć się z językiem w którym, każdy program powyżej 1k linii to spory problem przy szukaniu błędów. W pythonie/ruby pisze się podobnie szybko jak w c++... z tym, że narzędzia wspomagające programowanie w C++ znacznie przyspieszają pracę... ruby czy python nie dorobiły się nawet dobrego debuggera.

[kabanek]

Niektórzy lubią programować, a nie męczyć się z językiem w którym, każdy program powyżej 1k linii to spory problem przy szukaniu błędów.

ja lubię programować i sprawia mi to przyjemność. Mi w czerpaniu przyjemności c++ wcale nie przeszkadza.

To dziwne, że się zgadzasz z nieprawdą - są lepsze języki programowania i nie zależy to od doświadczenia czy oczekiwań - zależy do czego ma być użyty

nie ma lepszego czy gorszego języka programowania tylko jest lepszy w tym konkretnym zastosowaniu.

[el.pescado]

Nie ma lepszego czy gorszego języka programowania jest tylko lepszy i gorszy programista;)

[wojt03]

Nie ma lepszego czy gorszego języka programowania jest tylko lepszy i gorszy programista;)

Polemizowałbym kolego, ale lepiej zostawię to dla siebie...

[leon1313]

Nie ma lepszego czy gorszego języka programowania jest tylko lepszy i gorszy programista;)

Cała wasza polemika sprowadza się do "lepszego i gorszego programisty".
Już był tu podobny temat o systemie na serwer....

[rack]

(w językach skryptowych wolniej działa, wolniej się pisze, trudniej debugować)

Oczywistym jest, że nie wszystko do wszystkiego nadaje się w równie dobrym stopniu, nie mniej jednak ruby i python to jezyki ogólnego zastosowanie. Mozna w nich napisac 99% wszystkiego co w C ...
To że języki skryptowe działaja wolniej jest oczywiste bo jadą na grzbiecie C, nie ma sensu tego powtarzać 10 raz w tym wątku...
Bzdura jest, że w nich się wolniej pisze oprogramowanie. To jest twoja subiektywna opinia wynikła z niedostatecznej ich znajomości ... Ja mogę powiedzieć coś zupełnie odwrotnego ... Mnie się w C++ piesze dużo wolniej. Takie argumenty nie są warte funta kłaków ))
Dokładnie to samo moge powiedzieć o debugowaniu ... to, że Tobie debuguje się trudniej dla mnie nic nie znaczy, mnie debuguje się łatwiej ... Kolejna subiektywna wizja jak te o lepszych bibliotekach ... Biblioteki sa dla mnie bardzo dobre jeżeli sa wystarczająco dobre aby pomóc mi w tym co robię ... Jak dla ciebie sa zbyt słabe ... to twój problem ... poświęc kilka dni i napisz lepsze jak brakuje ci funkcjonalności ... ruby i python to otwarte projekty, każdy może dorzucic swoje 5 groszy ...

Język powinien być dostosowany do zadania, a nie do widzimisię programisty - a w przeciwieństwie do tego co próbują tu niektórzy wmówić ruby czy python nadają się jedynie do zastosowań typu: strona internetowa czy język osadzony w aplikacji C++ (czyli tam gdzie najczęściej kod nie przekracza paruset linijek)

Oczywista bzdura ... stary, dzis mówimy a aplikacjach internetowych, kilkaset linijek to może mieć jedna biblioteka, jeden zestaw testów, lub jeden kontroler ... Średniej wielkości aplikacja ma 10 tys+ linii kodu ... Rails ma dziesiątki tysięcy linii kodu podobnie jak kilka innych projektów czy same biblioteki, które są domyślnie z ruby czy pythonem ... coś się zawaliło? Nie sądze. Operujesz stereotypami kolego! Testy sa tu kluczem do stabilności.

... w większych projektach (a nawet takich poniżej, dlatego nie stosuje się ich za często jako język osadzony, jeśli ma służyć on programistą z firmy, ale jeśli dla klientów to już może być) te języki pokazują swoje wady.

Stary, ty ich nie stosujesz ... inni stosują z powodzeniem .. ja stosuję od 2004 roku. Nie pracuję dla żadnej firmy, wszystko robię na własy rachunek, odpowiedzialnośc i na tyle skutecznie ze spokojnie się z tego utrzymuje ...
Każdy jezyk ma swoje wady,twój ulubiony też. Cóz dla każdego wadą często jest co innego. Zrozum to zanim spróbujesz narzucić swoje wady poprzez subiektywizm swoich ocen.

Niektórzy lubią programować, a nie męczyć się z językiem w którym, każdy program powyżej 1k linii to spory problem przy szukaniu błędów. W pythonie/ruby pisze się podobnie szybko jak w c++...

Kolejna bzdura ... Nie wiem jak Ty, ale ja błedów szukam ręcznie bardzo sporadycznie. Pisze bardzo, krótkie metody, czemu spójnośc ruby bardzo sprzyja. Mój kod ma 100% pokrycia w testach ... Komputer jest od szukania błędów.

z tym, że narzędzia wspomagające programowanie w C++ znacznie przyspieszają pracę... ruby czy python nie dorobiły się nawet dobrego debuggera.

Stary, programowanie w c rózni się od programowania w pythonie czy ruby. Nie wiem jak ty piszesz swój kod, ale moj jest na tyle spójny, że debugger który jest domyślnie instalowany w ruby spokojnie wystarcza ... Dla ciebie on może nie być dobry, to już twój problem, mnie on wystarcza w 100 % ... Zrozum, że to co dobre jest rzeczą względną... Póki do Ciebie to nie dotrze będziesz zachowywał się jak dyktator , który każe słuchac bo tylko on wie najlepiej co jest dobre a co nie... Dla jednych dobry jest Lech dla innych Warka ... Nie ma rzeczy dobrych i złych, sa tylko osobiste preferencje, przekonania i wymagania poszczególnych ludzi ...

Zanim znów napiszesz coś o debuggerach, poniżej pierwszy z brzegu wpis na temat debugowania w pythonie
http://aymanh.com/python-debugging-techniques
a tu coś o ruby ...
http://www.infoq.com/articles/ruby-debuggers-survey
Jeżeli trzeba Ci czegoś więcej będziesz musiał sam napisać ... tysiące ludzi spokojnie radzą sobie z tym co jest ...

----------------------------------------------

Mówię to 5 raz w tej dyskusji, ale powtórzę to jeszcze ... Ta dyskusja nie ma sensu, bo każdy z nas robi co innego, czego innego oczekuje od języka, ma inne przyzwyczajenia i preferencje ... 80% opinii jest subiektywne i podszyte emocjami co tylko zaciemnia cały obraz tym którzy chcą coś z tego wątku wynieść dla siebie... Ja chyba juz swoje powiedziałem, powtarzać sie nie mam ochoty stąd też jest to mój ostatni wpis w tym wątku ...

pozdrawiam
S.Wojnowski

[luzakwielki]

To że języki skryptowe działaja wolniej jest oczywiste bo jadą na grzbiecie C, nie ma sensu tego powtarzać 10 raz w tym wątku...

Nic nie stoi na przeszkodzie, żeby działały szybciej - wystarczy tylko zrobić tak dobry kompilator jak te znane z C++ ;p.

Bzdura jest, że w nich się wolniej pisze oprogramowanie. To jest twoja subiektywna opinia wynikła z niedostatecznej ich znajomości ... Ja mogę powiedzieć coś zupełnie odwrotnego ... Mnie się w C++ piesze dużo wolniej. Takie argumenty nie są warte funta kłaków ))

Chciałem Ci przypomnieć, że to właśnie Ty przytaczałeś takie argumenty - moim zdaniem pisze się dokładnie tak samo szybko kod (jak się zna języki), tylko problem jest z debugowaniem gdzie musisz zrobić wielokrotnie to samo.

Oczywista bzdura ... stary, dzis mówimy a aplikacjach internetowych, kilkaset linijek to może mieć jedna biblioteka, jeden zestaw testów, lub jeden kontroler ... Średniej wielkości aplikacja ma 10 tys+ linii kodu ... Rails ma dziesiątki tysięcy linii kodu podobnie jak kilka innych projektów czy same biblioteki, które są domyślnie z ruby czy pythonem ... coś się zawaliło? Nie sądze. Operujesz stereotypami kolego! Testy sa tu kluczem do stabilności.

Ja nie pisałem o aplikacjach internetowych tylko o stronach internetowych (części z aplikacji która akurat odpowiada za wygenerowanie jakiejś części strony) - na jedną stronę internetową składa się przeważnie tylko kilkaset lini kodu w kilku plikach, i łatwo je zlokalizować i debugować.

Stary, ty ich nie stosujesz ... inni stosują z powodzeniem .. ja stosuję od 2004 roku. Nie pracuję dla żadnej firmy, wszystko robię na własy rachunek, odpowiedzialnośc i na tyle skutecznie ze spokojnie się z tego utrzymuje ...
Każdy jezyk ma swoje wady,twój ulubiony też. Cóz dla każdego wadą często jest co innego. Zrozum to zanim spróbujesz narzucić swoje wady poprzez subiektywizm swoich ocen.

Ja stosowałem w 2001 roku i w 2003 zrezygnowałem, na rzecz lepszych języków skryptowych.
Cieszę się, że zarabiasz na pisaniu, ale ja znam wiele firm/grup developerskich (nie tylko moja), które się na pythonie się ostro przejechały.

Dla ciebie on może nie być dobry, to już twój problem, mnie on wystarcza w 100 % ... Zrozum, że to co dobre jest rzeczą względną...

Słyszałem wielokrotnie takie tłumaczenia korzystania ze złych narzędzi - najczęściej kończyły się wyklinaniem tych rozwiązań jak ktoś poznał alternatywę (np. hardcore - ludzie chwalący sobie DevC++ - taki notatnik, ze starym gcc, słabą integracją z debuggerem (w praktyce nie działa... ale im też to nie przeszkadzało - debuggowali ręcznie (wrzucali to co ich interesowało do logów) i mówili że im to wystarcza) i niczym więcej, a nazywający dumnie się IDE). Dobre, jest rzeczą względną - przy debuggerach i innych narzędziach dla C++, te z python/ruby przyprawiają o śmiech... przy kartce papieru już są dosyć poważnymi narzędziami.

Zanim znów napiszesz coś o debuggerach, poniżej pierwszy z brzegu wpis na temat debugowania w pythonie
http://aymanh.com/python-debugging-techniques
a tu coś o ruby ...
http://www.infoq.com/articles/ruby-debuggers-survey
Jeżeli trzeba Ci czegoś więcej będziesz musiał sam napisać ... tysiące ludzi spokojnie radzą sobie z tym co jest ...

Pytania do debuggerów:
- posiadają reverse debugging? (możesz nagrywać to co robiłeś i puszczać jeszcze raz automatycznie, cofać się w tył etc.)
- posiadają wsparcie dla debugowania wielowątkowego? (możesz zatrzymywać, puszczać, debuggować wątki niezależnie)
- posiadają możliwość pisania skryptów? (gdb o zgrozo w pythonie ;p).
- posiadają opcję edit&continue? (w czasie debuggowania edytujesz kod, kompilujesz, a debugger po koleji robi to co we wcześniej debuggowanym kodzie i zatrzymuje się w tym samym miejscu z tak samo ustawionymi zmiennymi, i możesz kontynuować debuggowanie bez straty czasu na ustawianie wszystkiego ręcznie (gdzie często jest praktycznie nie możliwe ustawienie dokładnie takich samych danych wejściowych bez tego)).

Można by jeszcze tak długo tylko o narzędziach przyspieszających debuggowanie... tylko po co skoro skwitujesz, że Ci wystarczy taki debugger jaki jest (gdyby go nie było wystarczyła by Ci pewnie kartka papieru i ołówek i mówiłbyś, że 100% wystarcza - no i co że wystarcza jak spowalnia pracę?). O profilerach szkoda gadać, bo byłoby to już uderzanie języków skryptowych poniżej pasa.

[grymek3]

najłatwiejszy to python ale najlepiej zacząć od jakiegoś c++ czy c.

[mikolajs]

Nikt nie podważy znaczenia języków takich jak C++, ale mimo wielu zalet, popularność języka C++ spada i będzie spadać dalej. I nie pomoże zachwalanie, bo ucząc się języka skryptowego po miesiącu można napisać coś sensownego i użytecznego, podczas gdy C++ wymaga znacznie dłużej nauki i większej wiedzy. Co do zachwalanych zmian w nowym standardzie to może się okazać, że zmiany raczej zniechęcą nowych adeptów programowania niż zachęcą bo co prawda dają nowe możliwości ale znowu wymagają większej wiedzy.