15 lat - uczyc sie dalej programowania czy zająć czyms innym? Opcje

[tab]

czesc, to moze od poczatku. z programowaniem zetknalem sie w 6. kl podstawowki gdzie wzialem udzial w konkursie na programowanie w Logo (taki pseudo jezyk-programowanie, bardziej do nauki niz do rzeczywistych programow) i zdobylem laureata. zainteresowalem sie tym bo dawalo to punkty do gimnazjum,i tylko dlatego wiec potem przez rok nie myslalem wgl o programowaniu. gdzies w srodku 1 gim. znowu zaczalem hobbystycznie pisac programy, uczylem sie c++. konsolowe szlo mie calkiem fajnie, problem zaczal sie w winAPI gdzie poleglem na... tworzeniu okna. tak wiec zostawilem c++ i zajalem sie nauka. potem znowu w 2 gim. wrocilem do c++. udalo mi sie w koncu stworzyc swoje 1. okno, napisalem kalkulator i potem znowu zostawilem c++ bo zaczely sie dla mnie rzeczy ktorych nie łapałem. no i w koncu wakacje ostatnie tak nie wiem nawet czemu ale zaczalem sie uczyc php. w sensie nie wiem czemu akurat php ale zdecydowanie byl to dobry wybor bo z jezykow ktore probowalem (c++,python,java) ten zdecydowanie najbrdziej mi sie podoba. no i uczylem sie uczylem i obecnie potrafie w nim calkiem sporo w porownaniu do poprzednich. napisalem od podstaw swoje forum, taki jakby sklep internetowy i ksiegarnie. zaczalem tez pisac gre (obecnie jest mocno niedokonczona bo skupilem sie na nauce AJAXA zeby to w nim generowac mape i wgl ozywic strone). ogolnie to wydaje mi sie ze poszedlem troche z motyka na slonce, gra to juz nie jest takie hop-siup jak forum wiec poki co ja zostawilem i zaczalem sie dalej uczyc (m.in OOP w php). no wiec tak to jest, teraz 3 gim i stad moje moze nietypowe pytanie ale potrzebuje Waszej porady. czy waszym zdaniem jezeli umiem w swoim wieku to co umiem to warto uczyc sie dalej czy pojsc myslec o jakims zawodzie typu lekarz, ksiegowy..? ja nie jestem jakis swietny z matmy (wiem ze do programowania nie tyle trzeba byc dobrym z matmy (zwlaszcza ze jezyki skrytpowe to 95% operacje na stringach a nie liczbach) tylko miec otwarty umysl, ale w sumie ja tez jakiegos tego umyslu otwartego nie mam). sporo zadań z matmy 'na myslenie' sprawia mi problemy. a no i jeszcze pytanie, czy myslicie ze jak nie lapie teraz pewnych rzeczy to np za rok moze mi sie to troche rozjasnic? siedze teraz nad tym OOP'em i troche mnie to zdemotywowalo bo niby widze jak to sie robi ale jak probowalem cos napisac to nie wychodzi, i ogolnie troche wciaz nie łapie idei obiektowki. myslicie ze jak za jakis czas wroce do php to tak jak z tym c++ moze mi sie to rozjasnic i bede sie dziwil jak moglem tego wczesniej nie rozumiec? nie chcialbym sie zasłaniac wiekiem, ale pewnych rzeczy sie chyba po prostu w nizszym wieku nie lapie tak łatwo. no to co myslicie? m.in. czy myslicie ze warto uczyc sie dalej, w jakim wieku Wy zaczeliscie sie uczyc, czy webmasterka moze dac mi wieksze szanse na jakies sensowne pieniadze w zyciu? pozdrawiam..

[xdev]

Widzę, że zeromq awansowało na pozycję antidotum na wszelkie bolączki.

Jak masz jakiś wyjątkowo zasobożerny algorytm to możesz to napisać w C a połączyć przy użyciu 0mq. Z resztą w większości aplikacji i tak baza danych to wąskie gardło.

Trochę w inny sposób podobne. PHP tak jak RDBMS świetnie nadaje się do nudnych, robionych po raz tysięczny aplikacji.

Jeśli masz na myśli użyteczne aplikacje na których można zarobić to tak. Rozwiązania które kreuje się na "Nowoczesne"... starsze niż samo php czy mysql są po prostu nieelastyczne. Nierelacyjne bazy danych się nie nadają do projektu który trzeba po napisaniu rozwijać (w SQL robisz ALTER czy zmieniasz element relacji i w wygodny sposób możesz modyfikować całą bazę danych ... w mongo musisz pisać kod ręcznie i przerabiać cały dataset do tego sama baza jest koszmarnie napisana, nie zapewnia bezpieczeństwa danych i jest wysoce niewydajna).

Bo nie dość że dataset w mongo zajmuje 5-10x tyle HDD/pamięci co baza mySQL to jeśli trzeba będzie inaczej wykonać kwerendy (na przykład projektujesz aplikację rezerwacji biletów gdzie masz dane rozproszone po dacie i chcesz dodać do tego profilowanie klientów gdzie musisz analizować dataset po ID albo nazwisku to albo musisz duplikować wszystkie dane, albo całe rozwiązanie jest niewydajne do tego stopnia, że musisz czytać wszystkie dane rozproszone np. po 50 node-ach).

node... duplikujesz dane, dodajesz to samo drugi raz i zmieniasz kod zapisu tak, że część operacji wykonywana jest 1-szej kopii danych a część na drugiej. To koszmar, tylko kwestia czasu kiedy to się rozsynchronizuje.
sql... robisz alter table, żeby dodać index i tyle.

No nie ma, bo JavaScript nie ma. Bycie tablicą w js jest tylko potencjalną optymalizacją w dostępie do danych, gdzie masz dziesiąt innych rzeczy do wzięcia pod uwagę i to tylko wtedy gdy piszesz na jeden silnik.

Ale dostępne iteratory to kpina i przez takie "nieznaczące" niegogodności kod zamienia się w kupę shitu. for to anachronizm, strasznie niewygodny... for... in, jak wyżej... forEach z mongo nie obsługuje ani break ani continue (jest return, jednak nie ma break, w żadnej formie). Proponowaną formą sprawdzania "czy tablica" jest test na właściwość .length, czyli praktycznie jeśli dodasz ją do dowolnego swojego obiektu to kod się wykrzaczy.

Archaiczny C++ z STL jest... wygodniejszy i wymaga mniej bezsensownego powtarzania tych samych konstrukcji.

Nie ma isArray i jednego iteratora który to obsługuje, musisz wszystko pisać ręcznie przy każdej pętli. Może za pół roku coś wymyślą i będzie to działać normalnie? A ty będziesz przerabiał sieczkę na "normalny" kod... stosunek szumu do kodu to jakieś nieporozumienie, bo jak można pisać dobry kod w języku który ma skopane pętle? Jeśli nie da się sprawdzić z 100% pewnością, czy coś jest tablicą to z specyfikacji powinna wylecieć cała pętla for a zostać jeden standardowy iterator po kluczach, jeden po wartościach i jeden na wzór $k=>$v w php. Albo powinno się usunąć właściwość .length, skoro i tak nie wiadomo czy obiekt jest tablicą a ludzie piszą przez to pętle for które się mogą wysypać.

Rozumiem, że JS nie ma zdefiniowanego pojęcia tablicy bo obiekt może być na bieżąco modyfikowany... spoko ale iterator powinien być, na fakt że pętle są aż tak koszmarnie zaprojektowane nie ma żadnego wytłumaczenia. Jedna prosta funkcja do iteracji i jedna do sprawdzania, czy zmienna to obiekt/string/numer/wartość logiczna. Właśnie o tym mówię, coś co w PHP czy mySQL to jedna linijka i 5 sekund myślenia w mongo czy node urasta do rangi poważnego problemu który może zająć dni albo tygodnie.

można rozwijać się również na platformie .NET równocześnie pracując i rozwijając się w PHP, po pewnym czasie da nam to możliwość zmiany pracy na być może lepiej płatną

Jakie są różnice w zarobkach? Praktycznie ich nie ma. Średni programista PHP który się przesiądzie na .NET ... 4000 => 4500, bardzo dobry programista PHP => 7-10k PLN (za granicą 4-5x tyle).

Ale jaki jest sens bycia ekspertem Javy albo PHP? Będziesz jednym z wielu, łatwo wymienialnym.

To pewnie będziesz miał lepszą pozycję w firmie, kiedy będziesz umiał 15 rzeczy a nic dobrze? (IMG:style_emoticons/default/smile.gif) Ekspertów od czegokolwiek się nie wymienia, kiedy na stanowiska junior w dzisiejszych czasach jest problem, żeby kogoś znaleźć i to nie jest kwestia zarobków ale dostępności kadry która cokolwiek potrafi zrobić sama (no chyba, że ekspert to ktoś taki kto potrafi skonfigurować 25 frameworków i nie zrobi nic sam, tacy ludzie faktycznie nie mają lekko na rynku).

Ten post edytował xdev 29.10.2012, 12:36:09

[solificati]

Jak masz jakiś wyjątkowo zasobożerny algorytm to możesz to napisać w C a połączyć przy użyciu 0mq. Z resztą w większości aplikacji i tak baza danych to wąskie gardło.

Owszem, tylko 0mq to trochę overkill. Zeromq jest jak stare dobre C, tylko zamiast wiedzy z programowania wymaga wiedzy z devopsów, bycia sysadminem i architektem systemów. Widziałem zeromq w dużym systemie i było świetne. Widziałem też kilka katastrof z jego powodu - po prostu wybrałbym coś z większym fault tolerance out of the box (kolejki w RDBMS albo RabbitMQ).


Co do noSQL - ja się zgadzam, że noSQL nie zastępuje RDBMS. Ale replikacja w CouchDB, stare dobre Berkeley lub nowy Redis, Cassandra dla write-loadów ... NoSQL ma zastosowania w których RDBMS nie da rady. Trzeba tylko wiedzieć kiedy co użyć.

Rozumiem, że JS nie ma zdefiniowanego pojęcia tablicy bo obiekt może być na bieżąco modyfikowany... spoko ale iterator powinien być, na fakt że pętle są aż tak koszmarnie zaprojektowane nie ma żadnego wytłumaczenia. Jedna prosta funkcja do iteracji i jedna do sprawdzania, czy zmienna to obiekt/string/numer/wartość logiczna. Właśnie o tym mówię, coś co w PHP czy mySQL to jedna linijka i 5 sekund myślenia w mongo czy node urasta do rangi poważnego problemu który może zająć dni albo tygodnie.

To jest wynik decyzji odnośnie budowy języka z jednoczesnym pójściem na ustępstwa. Ja piszę na ogół w językach funkcyjnych/deklaratywnych, więc dla mnie iterator/for to nieintuicyjne podejście. Dla mnie to jak zwykle problem braku systemu typów.

To pewnie będziesz miał lepszą pozycję w firmie, kiedy będziesz umiał 15 rzeczy a nic dobrze? (IMG:style_emoticons/default/smile.gif) Ekspertów od czegokolwiek się nie wymienia, kiedy na stanowiska junior w dzisiejszych czasach jest problem, żeby kogoś znaleźć i to nie jest kwestia zarobków ale dostępności kadry która cokolwiek potrafi zrobić sama (no chyba, że ekspert to ktoś taki kto potrafi skonfigurować 25 frameworków i nie zrobi nic sam, tacy ludzie faktycznie nie mają lekko na rynku).

Heh, ja wyszedłem z uczelni wiedząc co to przestrzeń Hilberta - tak na prawdę, jako jeden z nielicznych na roku. Rozumiałem prawdopodobieństwo w opisie teorii miary. Byłem jednym z tych co wieszczyli upadek języków pochodnych od Algola i na praktykach jako jeden z niewielu wiedziałem co to domknięcie. Każdą wolną chwilę od nauki spędzałem na ... nauce rynków finansowych. Przez dwa lata nie pasowałem do żadnego ogłoszenia o pracę - ale ani razu nie myślałem, że mógłbym się wtedy uczyć C i DB2. Po co celować w średnią - jak przyjdzie kryzys to się usiądzie na dupie i nauczy robić "strony" albo remontować mieszkania.