Temat: Rynek IT z C C++

Marcin B.:
Myśle, że jak zapoznasz się z tym linkiem: http://kariera.pl/czytaj/920/dlaczego-firmy-w-polsce-n... to będziesz wiedziała jak pozyskać odpowiednie jednostki pracownicze ;)

Pozdrawiam

Miałam okazję już trafić na ten artykuł. Niestety niektóre rzeczy są nie do przeskoczenia dla nas pracowników firm doradczych. Ja nie mam nic przeciwko ujawnianiu różnych informacji. Często jednak nie możemy tego robić ze względu na taki wymóg klienta. Ale wszystkie takie informację są przekazywane szczegółowo na spotkaniu.
Natomiast bardzo cenię sobie kiedy kandydat bardzo jasno precyzuje swoje oczekiwania i wtedy szczerze mogę mu odpowiedzieć czy to mieści się czy też nie w budżecie założonym przez klienta.
Tak więc artykuł pokazuje oczywiście dużo rzeczy ale nie można uogólniać i trzeba pamiętać, ze czasami po prostu nie wolno nam wpisać w ogłoszenie nazwy klienta czy też wysokości wynagrodzenia.

Temat: Rynek IT z C C++

Tomasz K.:

Piotr Pszczolkowski:
ha ha ha..... ogolnie mozna powiedziec, ze kazda praca jest uciazliwa.

Ale jedna mniej, druga bardziej.

Zalezy czy lubisz to co robisz.
To co lubisz nie jest uciazliwe.
Jak nie lubisz programowania to nawet uruchomienie edytora bedzie Ci "ciazylo".

i niebezpieczne,

jak ktos nie umie programowac to niech sie wezmie za zamiatanie ulic (co zreszta tez moze byc "niebezpieczne").

Moim zdaniem w C/C++ jest wiecej rzeczy, na ktorych mozna sie naciac wiec prawdopodobienstwo popelnienia bledu jest wieksze.

Kwestia doswiadczenia.

Nawet jezeli umiesz programowac.

To zalezy co rozumiesz przez "umiesz" programowac.
Jak "umiesz" to popelnienie bledu jest male.

Bo oczywiscie nie ma programow bez bledow. Takze w innych jezyka.

proces tworzenia oprogramowania stosunkowo dlugi.

Kwestia wiedzy i doswiadczenia.

Wiedza i doswiadczeniem mozesz skrocic proces tworzenia oprogramowania, ale sam jezyk w pewnym sensie Cie ogranicza.

Jezyk c/c++ naklada akurat najmniejsze ograniczenia.
Im jezyk wyzszego poziomu tym wieksze ograniczenia.

Pisanie na wyzszym poziomie abstrakcji jest najczesciej szybsze.

Co nie znaczy skuteczniejsze.

Przesad ludzi nie znajacych jezyka

Jezyk C nie wspiera nawet programowania obiektowego przez co nie pisze sie w nim tak wygodnie. Po co sie wiec meczyc?

No fakt. Jesli to kogos meczy, to niech zajmie sie czyms innym.

i dostepnych bibliotek.

...ktore sa porozrzucane gdzie popadnie.

Hmmmm.... Trudno mi to skomentowac.
Ci co sie tym ineteresuja, wiedza gdzie co jest.
Ta wiedza swiadczy o ich profesjonalizmie i zaangazowaniu.
Inni wola dostac wszystko na tacce.

Jaki "spec", taki kod.
Mysle, ze "spece" od javy pisza nie mniej smieszne perelki.

Byc moze, ale pradopodobienstwo wysypania sie aplikacji jest mniejsze :)

Prawdopodobienstwo "wysypania" sie aplikacji zalezy nie od jezyka, tylko od wiedy, umiejetnosci i profesjonalizmu programisty go uzywajacego.
Dupa-programista wysypie najprostrzy nawet programik.

Temat: Rynek IT z C C++

Tomasz K.:

Moim zdaniem w C/C++ jest wiecej rzeczy, na ktorych mozna sie naciac wiec prawdopodobienstwo popelnienia bledu jest wieksze. Nawet jezeli umiesz programowac.

Generalnie jeśli ktoś ma wyrobioną systematykę to pewne błędy może ograniczyć do minimum. Natomiast myślenie rodem z QBasic raczej nie pomgaga w programowaniu...

Wiedza i doswiadczeniem mozesz skrocic proces tworzenia oprogramowania, ale sam jezyk w pewnym sensie Cie ogranicza. Pisanie na wyzszym poziomie abstrakcji jest najczesciej szybsze.

To akurat zależy. Od problemu.

Jezyk C nie wspiera nawet programowania obiektowego przez co nie pisze sie w nim tak wygodnie.

Naucz się jak program się wykonuje "sekwencyjnie" i będziesz wiedział dlaczego "obiektowy" VB jest doskonały do prostych aplikacji. I tylko takich.
Zaczynając naukę od "obiektowych" języków bardzo poważnie zubażasz i ograniczasz swoje możliwości. Owszem, jest to szybsze i wygodniejsze... ale paru rzeczy nie zobaczysz.

Po co sie wiec meczyc?

Po to by się czegoś nauczyć.

...ktore sa porozrzucane gdzie popadnie.

Przyjrzyj się obiektowej Javie i porozmawiamy o "porozrzucaniu" bibliotek gdzie popadnie...

Byc moze, ale pradopodobienstwo wysypania sie aplikacji jest mniejsze :)

Mitologia stosowana.

Ogolnie mowiac, to "spece" (w cudzyslowiu) wszystko spieprza.

Zgoda

Zgoda. :)

Temat: Rynek IT z C C++

Piotr Pszczolkowski:
Zalezy czy lubisz to co robisz.
To co lubisz nie jest uciazliwe.

Wiesz, wbrew pozorom ja lubie takie jezyki jak C. Nie odwazylbym sie jednak pisac w nim wiekszej aplikacji komercyjnej, jezeli moglbym ja zrobic w jezyku wyzszego poziomu. Wlasnie dlatego, ze rozwijanie takiej aplikcji jest bardziej problematyczne i czasochlonne - przynajmniej dla mnie.

Zbyt dlugie sleczenie nad aplikacja, moze pociagac za soba szereg innych problemow, wiec mozesz lubiec cos, co jest dla Ciebie uciazliwe - niekoniczenie bezposrednio.

Moim zdaniem w C/C++ jest wiecej rzeczy, na ktorych mozna sie naciac wiec prawdopodobienstwo popelnienia bledu jest wieksze.

Kwestia doswiadczenia.
To zalezy co rozumiesz przez "umiesz" programowac.
Jak "umiesz" to popelnienie bledu jest male.

Coz, Twoim zdaniem male - moim zdaniem tez, ale prawdopodobienstwo popelnienia bledu jest MOIM ZDANIEM wieksze w przypadku programowania na nizszym poziomie abstrakcji. Po drugie wykrycie takiego bledu moze okazac sie trudniejsze. Jak w C# wyjedziesz poza zakres tablicy to dostaniesz wyjatek i wiesz, ze popelniles blad. Jak Ci sie to samo zdarzy(a zdarzyc sie moze) w C to do konca nie wiadomo co sie stanie. To typowe uciazliwosci C.

Widac tutaj mamy dosc odmienne zdanie i chyba nie damy sie nawzajem przekonac :)

Jezyk c/c++ naklada akurat najmniejsze ograniczenia.
Im jezyk wyzszego poziomu tym wieksze ograniczenia.

Pisalem o ograniczeniach w kontekscie szybkiego tworzenia aplikacji, a w tej kwestii jest dokladnie na odwrot.

Pisanie na wyzszym poziomie abstrakcji jest najczesciej szybsze.

Co nie znaczy skuteczniejsze.

Oczywiscie masz racje, ale to juz zalezy od tego, co rozumiesz przez slowo "skuteczniejsze". Napisalem wczesniej, ze jezyk C bardzo dobrze sprawdza sie tam, gdzie chcemy pisac na niskim poziomie abstrakcji. Biorac pod uwage takie kryteria, mozna wyjsc z zalozenia, ze C jest jezykiem bardzo skutecznym.

Prawdopodobienstwo "wysypania" sie aplikacji zalezy nie od jezyka, tylko od wiedy, umiejetnosci i profesjonalizmu programisty go uzywajacego.

Od wiedzy przede wszystkim, ale od jezyka rowniez. To oczywiscie moje zdanie i zdaje sobie sprawe z tego, ze masz inne.

Dupa-programista wysypie najprostrzy nawet programik.

Nie popadajmy w skrajnosci.

Temat: Rynek IT z C C++

Katarzyna Zieleniewska:
hmm zastanówmy się jakby to brzmiało, na przykład:

"szukam programisty C/C++ za 8k"

myślicie, że taka oferta bardziej by przekonywała do spotkania?

Moim zdaniem zdecydowanie tak.

Temat: Rynek IT z C C++

Tomasz K.:
Moim zdaniem w C/C++ jest wiecej rzeczy, na ktorych mozna sie naciac wiec prawdopodobienstwo popelnienia bledu jest wieksze. Nawet jezeli umiesz programowac.

Wykorzystasz C, jeśli potrzebujesz napisać biblioteki do wykorzystania w językach X, Y, Z itd.

Ja nacinam się przy goleniu :)
W trakcie programowania popełniam błedy ale od tego są Unit Testy żeby je szybko wychwycić.

Jezyk C nie wspiera nawet programowania obiektowego przez co nie pisze sie w nim tak wygodnie.

http://en.wikipedia.org/wiki/GObject

Po co sie wiec meczyc?

Jak wyżej.
Po to żeby napisac jeden kod i wykorzystać jako "language bindings" w 10 innych językach.

Zresztą... po co dyskusja na ten temat skoro bez C nie byłoby żadnego języka wyższego poziomu. I żaden z tych języków by się nie rozwijał.

Kolesie dajmy na to w firmie Microsoft siedzą i dłubią .NETa w Visual Basicu bo nacięli się na C? A w SUN-ie, Jave piszą w asemblerze bo im wygodniej?

Temat: Rynek IT z C C++

Karol Z.:
Generalnie jeśli ktoś ma wyrobioną systematykę to pewne błędy może ograniczyć do minimum.

Oczywiscie, ale minimum dla jezyka nizszego poziomu jest inne niz dla wyzszego poziomu - moim zdaniem.

To akurat zależy. Od problemu.

Zgadza sie.

Jezyk C nie wspiera nawet programowania obiektowego przez co nie pisze sie w nim tak wygodnie.

Naucz się jak program się wykonuje "sekwencyjnie"

Zaczalem od jezykow proceduralnych wiec nie musze tego robic.

VB jest doskonały do prostych aplikacji.

Ale nie dlatego, ze jest obiektowy.

Zaczynając naukę od "obiektowych" języków bardzo poważnie zubażasz i ograniczasz swoje możliwości. Owszem, jest to szybsze i wygodniejsze... ale paru rzeczy nie zobaczysz.

Np. jakich? :)

Po to by się czegoś nauczyć.

OK :)

Przyjrzyj się obiektowej Javie i porozmawiamy o "porozrzucaniu" bibliotek gdzie popadnie...

Nie znam sie na Javie, ale nie sadze zeby programowanie w tym jezyku bylo tak mocno "porozrzucane" jak w przypadku C.

Ogolnie mowiac, to "spece" (w cudzyslowiu) wszystko spieprza.

Zgoda

Zgoda. :)

heh :)

Temat: Rynek IT z C C++

Tomasz K.:
Oczywiscie, ale minimum dla jezyka nizszego poziomu jest inne niz dla wyzszego poziomu - moim zdaniem.

Po raz kolejny powtarzam: jeśli masz bałagan to i w Javie, VB się pogubisz przy czterech prostych obiektach, a metodyka projektowania/programowania w językach uchodzących za "ciężkostrawne" (C/C++/assembler) procentuje później. Także przy projektowaniu obiektowym.

Naucz się jak program się wykonuje "sekwencyjnie"

Zaczalem od jezykow proceduralnych wiec nie musze tego robic.

Ja tam Cię nie znam, ale w tym miejscu to mi ignorancją powiało...

VB jest doskonały do prostych aplikacji.

Ale nie dlatego, ze jest obiektowy.

Nie, dlatego że jest BASIC. A jako BASIC to raczej i taki poziom programów ogarniesz.

Zaczynając naukę od "obiektowych" języków bardzo poważnie zubażasz i ograniczasz swoje możliwości. Owszem, jest to szybsze i wygodniejsze... ale paru rzeczy nie zobaczysz.

Np. jakich? :)

Nie nauczysz się organizować sobie warsztatu. (bo język zrobi to "za Ciebie" albo Cię do tego zmusi) Poza tym zastanawiałeś się dlaczego pewne programy realizują operację wejścia klawiaturowego szybciej niż te pochodzące od myszy? :) Nie zobaczysz tego z poziomu VB.

Przyjrzyj się obiektowej Javie i porozmawiamy o "porozrzucaniu" bibliotek gdzie popadnie...

Nie znam sie na Javie, ale nie sadze zeby programowanie w tym jezyku bylo tak mocno "porozrzucane" jak w przypadku C.

To czuję, średnio zagłębiłeś się w C/C++.

Temat: Rynek IT z C C++

Ja tam Cię nie znam, ale w tym miejscu to mi ignorancją powiało...

Dlaczego?

VB jest doskonały do prostych aplikacji.

Ale nie dlatego, ze jest obiektowy.

Nie, dlatego że jest BASIC. A jako BASIC to raczej i taki poziom programów ogarniesz.

Przyznam, ze nie rozumiem tej wypowiedzi. Mozesz napisac troche jasniej?

Nie nauczysz się organizować sobie warsztatu. (bo język zrobi to "za Ciebie" albo Cię do tego zmusi)

Czy moglbys rozwinac mysl? Nie rozumiem dlaczego uwazasz, ze programowanie obiektowe wplywa negatywnie na organizacje warsztatu. Co wg. Ciebie zrobi za mnie jezyk? Czy mozesz oprzec sie o konkretny przyklad?

Poza tym zastanawiałeś się dlaczego pewne programy realizują operację wejścia klawiaturowego szybciej niż te pochodzące od myszy? :)

Nie, ale jak mi to wyjasnisz to bede wdzieczny :)

Temat: Rynek IT z C C++

Wykorzystasz C, jeśli potrzebujesz napisać biblioteki do wykorzystania w językach X, Y, Z itd.

Sensowny argument :)

Ja nacinam się przy goleniu :)

:)

Jezyk C nie wspiera nawet programowania obiektowego przez co nie pisze sie w nim tak wygodnie.

http://en.wikipedia.org/wiki/GObject

Kiedys o tym czytalem, ale nie uzywalem. Trudno jest mi ocenic to cos. Ale moze powiesz cos od siebie?

Zresztą... po co dyskusja na ten temat skoro bez C nie byłoby żadnego języka wyższego poziomu.

To malo istotny fakt w tej dyskusji.

Temat: Rynek IT z C C++

Tomasz K.:

Ja tam Cię nie znam, ale w tym miejscu to mi ignorancją powiało...

Dlaczego?

To mój osobisty odbiór.

Nie, dlatego że jest BASIC. A jako BASIC to raczej i taki poziom programów ogarniesz.

Przyznam, ze nie rozumiem tej wypowiedzi. Mozesz napisac troche jasniej?

Tak.
O ile w VB umieścisz na formie kilka kontrolek i nawet uda Ci się je oprogramować zgodnie z życzeniem pewne rzeczy są dla programisty ukryte gdzieś w "czarnej skrzynce". Głęboko, gdzie wzrok nie sięga. ;)Jeśli nie widzisz, nie masz możliwości dostać się głębiej to naturalne jest to, że tam nie trafisz. A to w bardzo poważny sposób Cię ogranicza.

Co innego w C/C++.
Dostajesz wszystkie biblioteki jakich Ci będzie trzeba. Źródła także.

I gdzie są ograniczenia C/C++ którymi straszyłeś wcześniej?

Nie nauczysz się organizować sobie warsztatu. (bo język zrobi to "za Ciebie" albo Cię do tego zmusi)

Czy moglbys rozwinac mysl? Nie rozumiem dlaczego uwazasz, ze programowanie obiektowe wplywa negatywnie na organizacje warsztatu. Co wg. Ciebie zrobi za mnie jezyk? Czy mozesz oprzec sie o konkretny przyklad?

Jeśli masz framework to on na siłę wymusi na Tobie umieszczenie określonych funkcji i oprogramowanie poszczególnych metod w taki sposób, w jaki życzy sobie ów szablon. Jeśli zrobisz inaczej to bierzesz odpowiedzialność na siebie (w C/C++ ta odpowiedzialność przesuwa się w stronę programisty), zyskujesz ograniczone wsparcie ze strony edytora, chociażby.

Mylę się?
Jeśli tak - popraw.

Poza tym zastanawiałeś się dlaczego pewne programy realizują operację wejścia klawiaturowego szybciej niż te pochodzące od myszy? :)

Nie, ale jak mi to wyjasnisz to bede wdzieczny :)

Pętla komunikatów, którą możesz znać z C/C++ a której nie widuje się w programach napisanych w VB.

Temat: Rynek IT z C C++

Tomasz K.:

Jezyk C nie wspiera nawet programowania obiektowego przez co nie pisze sie w nim tak wygodnie.

http://en.wikipedia.org/wiki/GObject

Kiedys o tym czytalem, ale nie uzywalem. Trudno jest mi ocenic to cos. Ale moze powiesz cos od siebie?

Obiektowość przez konwencję. Definijuesz konsktruktory, destruktory i metody klass. Możesz zdefiniować metody wirtualne i nie wirtualne. Interfejsy, itp itd.

Kilka makr aby zapewnić introspekcje i kilka metod:
http://trac.midgard-project.org/browser/trunk/midgard/...

GObject ma znaczny udział w implementacji mono na przykład :)
http://www.mono-project.com/Main_Page

Temat: Rynek IT z C C++

Karol Z.:
Tak.
O ile w VB umieścisz na formie kilka kontrolek i nawet uda Ci się je oprogramować zgodnie z życzeniem pewne rzeczy są dla programisty ukryte gdzieś w "czarnej skrzynce".

To zrozumiale, ale chcialem sie dowiedziec, dlaczego programowanie obiektowe negatywnie wplywa na "warsztat". Przeciez nie o to chodzi w programowaniu obiektowym, zeby przeciagac kontrolki na forme.

Głęboko, gdzie

wzrok nie sięga. ;)Jeśli nie widzisz, nie masz możliwości dostać się głębiej to naturalne jest to, że tam nie trafisz.

Zgoda, ale programowanie obiektowe nie ogranicza Cie w tym zakresie. Bez problemu mozesz napisac jakis sterownik obiektowo. To chyba dosc glebokie spojrzenie? :)

Dostajesz wszystkie biblioteki jakich Ci będzie trzeba. Źródła także.

Problem jest taki, ze zaczynamy skakac od tematu do tematu. Skupmy sie moze na tym programowaniu obiektowym, bo zaraz sie wszystko pomiesza.

I gdzie są ograniczenia C/C++ którymi straszyłeś wcześniej?

Tam gdzie byly zawsze. Nizszy poziom abstrakcji sprawia, ze masz wiecej na glowie. Im wiecej masz na glowie tym duzej tworzysz aplikacje(wiem, ze sa wyjatki). Chodzilo o ograniczenia w sensie czasu, ktory musisz poswiecic na rozwoj oprogramowania. Nie mialem na mysli ograniczen jezyka pod wzgledem jego mozliwosci.

Dodam, ze pod tym wzgledem patrze bardziej krytycznie na jezyk C niz na C++.

Jeśli masz framework

No wlasnie... zapomnijmy o frameworku. Pytalem o negatywny wplyw programowania obiektowego na warsztat programistyczny. Dla mnie, sztuka programowania obiektowego wiaze sie z pewnym sposobem myslenia, a nie z frameworkami. Dlatego wlasnie nie potrafie zrozumiec w czym te programowanie obiektowe przeszkadza?

to on na siłę wymusi na Tobie umieszczenie

określonych funkcji i oprogramowanie poszczególnych metod w taki sposób, w jaki życzy sobie ów szablon.

Ten "problem" na szczescie dotyczy rowniez C++ :)

Poza tym zastanawiałeś się dlaczego pewne programy realizują operację wejścia klawiaturowego szybciej niż te pochodzące od myszy? :)

Nie, ale jak mi to wyjasnisz to bede wdzieczny :)

Pętla komunikatów, którą możesz znać z C/C++ a której nie widuje się w programach napisanych w VB.

Tu musze sie przyznac, ze zle przeczytalem Twoja wypowiedz. Przeoczylem wyraz "pochodzace" i zdanie zmienilo sens :)Tomasz K. edytował(a) ten post dnia 12.09.08 o godzinie 11:59

Temat: Rynek IT z C C++

Piotr P.:
Obiektowość przez konwencję. Definijuesz konsktruktory, destruktory i metody klass. Możesz zdefiniować metody wirtualne i nie wirtualne. Interfejsy, itp itd.

Kilka makr aby zapewnić introspekcje i kilka metod:
http://trac.midgard-project.org/browser/trunk/midgard/...

GObject ma znaczny udział w implementacji mono na przykład :)
http://www.mono-project.com/Main_Page

Dziekuje za wypowiedz :)

Temat: Rynek IT z C C++

Witam, ja również poszukuję programistów C++ dla dwóch Firm, do Wrocławia i w okolice Bydgoszczy. Więc to zapotrzebowanie chyba nie jest złe. Choć przyznam, że Java wypiera chyba dziś C++.
Zainteresowane osoby proszę o kontakt
malgorzata.pacholska@manpower.pl
pozdrawiam

Temat: Rynek IT z C C++

Tomasz K.:

Zgoda, ale programowanie obiektowe nie ogranicza Cie w tym zakresie. Bez problemu mozesz napisac jakis sterownik obiektowo. To chyba dosc glebokie spojrzenie? :)

Oczywiście, interpretowany QBasic także umożliwiał odczyt i zapis plików, to znaczy że można napisać za jego pomocą translator z jęz. mnemonicznego do postaci maszynowej.
Pytanie jak bardzo trzeba być zdesperowanym... ;)

A co do "obiektowego": nawet kod w asemblerze może być "obiektowy". I to raczej nie zależy od języka a od sposobu myślenia programisty.

Dostajesz wszystkie biblioteki jakich Ci będzie trzeba. Źródła także.

Problem jest taki, ze zaczynamy skakac od tematu do tematu. Skupmy sie moze na tym programowaniu obiektowym, bo zaraz sie wszystko pomiesza.

Wyjaśniłem powyżej.

I gdzie są ograniczenia C/C++ którymi straszyłeś wcześniej?

Tam gdzie byly zawsze. Nizszy poziom abstrakcji sprawia, ze masz wiecej na glowie. Im wiecej masz na glowie tym duzej tworzysz aplikacje(wiem, ze sa wyjatki). Chodzilo o ograniczenia w sensie czasu, ktory musisz poswiecic na rozwoj oprogramowania.

Patrząc z tego punktu widzenia to się zgodzę. Program w VB to 30 sekund klepania, w C, szczególnie strukturalnym, podobny program pod windę to już wyższa szkoła jazdy.

Poza tym są pewne fragmenty kodu, które raz zrobisz i się do nich nie dotykasz. Nawet się nad nimi nie zastanawiasz.

Nie mialem na mysli ograniczen jezyka pod wzgledem jego mozliwosci.

Dodam, ze pod tym wzgledem patrze bardziej krytycznie na jezyk C niz na C++.

No, wiesz... tam gdzie większe możliwości tam znajdzie się możliwość popełnienia błędu.

Jeśli masz framework

No wlasnie... zapomnijmy o frameworku. Pytalem o negatywny wplyw programowania obiektowego na warsztat programistyczny. Dla mnie, sztuka programowania obiektowego wiaze sie z pewnym sposobem myslenia, a nie z frameworkami. Dlatego wlasnie nie potrafie zrozumiec w czym te programowanie obiektowe przeszkadza?

Inaczej: moim zdaniem (wyrobionym na podst. własnych doświadczeń i doświadczeń "wcześniejszych pokoleń", których przedstawiciele zechcieli się nim podzielić) jeśli nie potrafisz dobrze programować strukturalnie to języki obiektowe doraźnie pomogą Ci rozwiązać problem, ale w przypadku problemu znacznie trudniej będzie Ci znaleźć błąd tkwiący gdzieś indziej.

Jeśli dobrze potrafisz pisać strukturalnie to obudowanie pewnych fragmentów "nawiasami" (enkapsulacja) nie będzie stanowiła dla Ciebie większego problemu.

to on na siłę wymusi na Tobie umieszczenie

określonych funkcji i oprogramowanie poszczególnych metod w taki sposób, w jaki życzy sobie ów szablon.

Ten "problem" na szczescie dotyczy rowniez C++ :)

BTW: "Zgubiłem" gdzieś sens dalszej dyskusji. ;)

Temat: Rynek IT z C C++

Tomasz K.:

Jezyk C nie wspiera nawet programowania obiektowego przez co nie pisze sie w nim tak wygodnie. Po co sie wiec meczyc?

Tu się całkowicie nie zgodzę. Windows od 20 lat jest obiektowy - w czystym C. Z drugiej strony znam masę programistów którzy po "class" piszą "static" i już mają "obiektowy" kod.

Obiektowość to stan umysłu i język nie ma tu nic do rzeczy.Szymon Kubisiak edytował(a) ten post dnia 14.09.08 o godzinie 12:48

Temat: Rynek IT z C C++

Szymon Kubisiak:
Tu się całkowicie nie zgodzę. Windows od 20 lat jest obiektowy - w czystym C.

Sam tez tak robilem.

Obiektowość to stan umysłu i język nie ma tu nic do rzeczy.

Zgadza sie :)

Temat: Rynek IT z C C++

Szymon Kubisiak:

Obiektowość to stan umysłu i język nie ma tu nic do rzeczy.

Może nie tak precyzyjnie, ale lepiej sam bym tego nie ujął.
Choć nie... sam napisałem, że asm też może być obiektowy. ;)

Temat: Rynek IT z C C++

Karol Z.:
Oczywiście, interpretowany QBasic także umożliwiał odczyt i zapis plików, to znaczy że można napisać za jego pomocą translator z jęz. mnemonicznego do postaci maszynowej.
Pytanie jak bardzo trzeba być zdesperowanym... ;)

Bardzo :) Ale jezeli chodzi o programowanie sterownikow, to pisanie ich obiektowo nie utrudnia sprawy :) Trudno wiec mowic o desperacji :)

I to raczej nie zależy od języka a od sposobu myślenia programisty.

Dlatego nie moglem zrozumiec, dlaczego obiektowosc psuje organizacje warsztatu programistycznego.

No, wiesz... tam gdzie większe możliwości tam znajdzie się możliwość popełnienia błędu.

Oczywiscie, ale mozliwosci jezyka C nie zawsze sa potrzebne w danym projekcie . Warto byloby wiec skorzystac z dobrodziejstw jezykow wyzszego poziomu, ograniczajac przy tym liczbe potencjalnych bledow i zyskujac na czasie(nie tylko z powodu bledow).

Jezyk C ma duze mozliwosci, ale prawdopodobienstwo popelnienia bledu jest wieksze w stosunku do nowszych, wysokopoziomowych jezykow. Sam kod jest tez trudniejszy w utrzymaniu i rozwijaniu. Oczywiscie, mozna wyjsc z zalozenia, ze "programista-dupa" i tak wszystko zepsuje, ale nie chodzi o to, zeby popadac w jakies skrajnosci.

Opierajac sie o powyzsze argumenty staralem sie wytlumaczyc, dlaczego jezyki takie jak C czy C++ sa wypierane przez jezyki wyzszego poziomu - niekoniecznie mowa tu o VB bo to akurat slaby konkurent. Od tego sie zaczela ta dyskuja - skonczyla sie na niewiadomo czym :)

To co napisalem wyzszej jest moim wlasnym zdaniem i rozumiem, ze nie kazdy musi sie ze mna zgadzac.

Jeśli dobrze potrafisz pisać strukturalnie to obudowanie pewnych fragmentów "nawiasami" (enkapsulacja) nie będzie stanowiła dla Ciebie większego problemu.

To juz zalezy od konkretnego programisty. Niektorym programistom zmiana sposobu myslenia sprawia niemialy problem. Pozniej jest tak, jak napisal Szymon - klasy zaczynaja pelnic taka funkcje, jaka pelnia przestrzenie nazw. Wszystko przez to, ze kazda metoda w klasie jest statyczna.

BTW: "Zgubiłem" gdzieś sens dalszej dyskusji. ;)

Dyskusja zjechala na niewlasciwie tory :) Proponuje EOT.

PS.
Pisalem na szybko. Mam nadzieje, ze moje wypowiedzi beda zrozumiale - w razie czego wszystko wyjasnie jeszcze raz.