Który waszym zdaniem język programowania ma przyszłość jesli chodzi o mozliwosci same w sobie i mozliwosci znalezienia pracy znajac ten jezyk i dla czego? Programisci którego języka są najbardziej poszukiwani? Co wy myslicie o jezykach w ktorych piszecie? Chcialbym wiedziec co o tym wszystkim myślicie, by moc sie ewentualnie ukierunkowac w ktorąś ze stron.
0
0
Nataq napisał(a)
Programisci którego języka są najbardziej poszukiwani?
www.jobs.pl , itp
0
O, temat o językach w których piszemy mi się podoba.
Porzuciłem Delphi dla C#. Podoba mi się, ma jakąś przyszłość, ale kto wie jaką, w niedalekiej perspektywie na pewno świetlaną.
PHP w wersji 6 zapowiada wprowadzenie paru rzeczy, całkiem przyjemnych (namespace, wyrzucenie register_globals), w wersji 5 wraz z PDO, wraz z obiektowością, wraz z frameworkami, jest naprawdę świetnym językiem. Raczej konkurencji za bardzo póki co nie widzę - może Ruby wraz z Rails, ale ten na razie nie daje rady. A konkurencji ze strony ASP.NET chyba nie ma się co obawiać, może JSP po otwarciu Javy...
0
Python - ogromne możliwości, wszelakie zastosowania, wieloplatformowość, ogromna liczba modułów, wiele potężnych frameworków, szybkość działania [mimo, że to język interpretowany (choć można także skompilować do exe)], mnóstwo obsługiwanych bibliotek - jak Qt, Gtk, OpenGL, prosta składnia. Można w nim pisać zarówno rozbudowane aplikacje okienkowe, jak i różne serwisy internetowe.
Co do PHP - dysponuje dość brzydkimi nawykami - jak np. różne nazywania funkcji [raz xxx_yyy_zzz, raz xxxYyyZzz]. Co prawda to nie argument bardzo znaczący, ponadto w PHP można też pisać aplikacje okienkowe, to raczej Python przegania PHP pod prawie każdym względem. To co napiszesz w PHP powiedzmy na 1000 linii kodu, w Pythonie napiszesz na 50.
Ruby - tak, konkurent Pythona, w miare podobna składnia, jednak na dzień dzisiejszy Python przegania Ruby chociażby w powalającej różnicy w szybkości działania.
Dla przykładu, Google czy NASA korzystają z Pythona.
0
True to that...
Ale jest jedna rzecz, która nie zginie... C i C++. Odpowiedź czemu: to co właśnie widzisz (przeglądarka internetowa) została napisana w C++ (firefox na 100% machnięty w C++)
0
Johny: dokładniej w C++ i Gtk ;)
0
Gtk to nie język :P
Poza tym 90% visty to C++, reszta C. Szybko od tego nie odejdą. Szkoda tylko że tak mało pożytecznych bibliotek ma wejść do nowego standardu :(
0
DzieX: kto powiedział, że to język? :P To biblioteka do tworzenia GUI, napisałem zresztą w pierwszym poście.
0
programowanie jest jak gotowanie: masz jakies warzywa, owoce i narzedzia, za pomoca ktorych tworzysz rozne potrawy...
a ty sie pytasz, za pomoca jakiego warzywa mozna robic najlepsze dania? ;)
no wiesz, duzo zalezy od gustu, no ale tez od tego co robisz. ja do zrobienia zupy raczej bananow nie uzyje, co oczywiscie nie znaczy, ze banany sa niedobre. po prostu wole je widziec w innych potrawach :)
ciezko powiedziec, co ludzie beda chcieli jesc w przyszlosci...
i jeszcze jedno:
jezeli umiesz robic kanapki, to nie znaczy, ze jestes kucharzem. nawet jak kotlety zrobisz, to tez jeszcze o wszystkim nie swiadczy. kucharz potrafi wymyslic potrawe, jej smak, wyobrazic sobie efekt koncowy. dopiero potem zaczyna gotowac. czasem korzysta z wczesiej wymyslonych przepisow, ale lekko je modyfikuje wedlug wlasnych potrzeb.
teraz przeloz sobie to wszystko na programowanie :)
//do dryo: po prostu czulem, ze ktos da jakis przepis z zupy z bananow, czulem to ;)
0
Karolaq napisał(a)
ja do zrobienia zupy raczej bananow nie uzyje, co oczywiscie nie znaczy, ze banany sa niedobre. po prostu wole je widziec w innych potrawach :)
http://www.przepisy.org/przepis8919.html
Idąc tym tokiem rozumowania to przyprawy to gui. Można zabić smak potrawy i sprzeda się i tak :P
0
A, dodam jeszcze bardzo ciekawy, dopiero się rozwijający, język D. To swego rodzaju alternatywa dla C++ - podobny, liczne usprawnienia, różne nowe rzeczy, do tego piekielnie szybki.
W styczniu tego roku wyszła wersja 1.0, za jakiś czas ma wyjść wersja 2.0 - wróżę temu językowi naprawdę sukces. Poczekamy, zobaczymy.
Oficjalna strona: http://digitalmars.com/d/
Porównanie D z innymi językami: http://www.digitalmars.com/d/comparison.html
0
Szczerze to znałem już wcześniej ale kompletnie mi się nie podoba z powodu tego, że odeszli od wielo-dziedziczenia. Ale to tylko moja opinia :)
0
Ogólnie widzę tendecje zbliżania się wielu języków do Javy.
PHP ściąga bardzo wiele rzeczy z Javy, praktycznie cały model obiektowy jest przepisany z Javy.
Podobnie .NET to po prostu "Java reimplemented by M$".
Ruby ma parę fajnych nowości, ale prędzej zastapi PHP niż Javę (jednak co dynamiczny język skryptowy, to skryptowy - ze statycznie typowanymi językami kompilowanymi mierzyć się za bardzo nie może).
Zarąbistym językiem jest Eiffel, tylko szkoda że ma taką małą siłę przebicia. Jeśli do Javy czy .NET dorzucą takie mechanizmy statycznej weryfikacji kodu jakie są w Eiffel, to będzie to naprawdę killer.
A C/C++ oczywiście będą używane nadal, choć C jest uzasadniione już tylko rozwojem driverów i różnych niskopoziomowych części OSów, a C++ jeszcze króluje na desktopie, ale to już siła przyzwyczajenia.
Ogólnie ciężko coś powiedzieć o przyszłości języków. Na razie absolutnym kanonem jest Java i C++ z .NETem gdzieś nieco z tyłu - znając je mozna napisać 99,9% projektów i dlatego warto się ich teraz nauczyć, a później wypróbowywać nowinki takie jak Ruby, Eiffel, Scheme czy PHP 6. Wiele "rewolucyjnych" języków programowania robiło szybką furorę i równie szybko gasło, więc nie ma co się tak bardzo nimi emocjonować.
0
Hmm, C++ też nie można nie doceniać, zawsze się przyda tam gdzie ważna jest szybkość działania programów - jak dla mnie na dzień dzisiejszy jego jedynym sensownym następcą mógłby być wspomniany D (chociaż niektórych decyzji zupełnie nie rozumiem, chodzi mi głównie o wywalenie wielodziedziczenia (przeszkadzało komuś?) i wbudowany garbage-collector (to mi jakoś nieprzyjemnie javą zalatuje ;))
0
Ghostek napisał(a)
Hmm, C++ też nie można nie doceniać, zawsze się przyda tam gdzie ważna jest szybkość działania programów
Raczej tam, gdzie są wymagania na oszczędność zasobów. Szybkość działania programów w Javie czy .NET jest bardzo zblizona do C++, ale pamięciożerność jest ciągle zbyt duża. Mam kumpla, który robi analizy obrazów i ma algorytm, gdzie dane zajmują kilka GB RAMu i wymagają bardzo szybkiego dostępu swobodnego (czyli baza danych odpada). W takim zastosowaniu w zasadzie tylko C/C++ dałoby radę - języki z odśmiecaniem zarżnęłyby się na swapie, a języki skryptowe liczyłyby zbyt wolno. Niemniej to jest projekt bardzo niszowy. Takich projektów jest może 1%.
- jak dla mnie na dzień dzisiejszy jego jedynym sensownym następcą mógłby być wspomniany D (chociaż niektórych decyzji zupełnie nie rozumiem, chodzi mi głównie o wywalenie wielodziedziczenia (przeszkadzało komuś?) i wbudowany garbage-collector (to mi jakoś nieprzyjemnie javą zalatuje ;))
Garbage collector to jest DOBRA rzecz, poza 1% przypadków gdzie i tak bez C++ ani rusz.
GC jest dużo szybsze niż ręczny malloc. Np. właśnie tam gdzie Java traci na wydajności do C++ przez np. wszechobecne dynamiczne rzutowanie czy sprawdzanie zakresów tablic w runtime, odrabia na szybszym zarządzaniu pamięcią.
Natomiast co do D, to brak dynamicznego ładowania klas dyskwalifikuje go na starcie w dużych projektach. O/R mapping i IoC byłoby bardzo trudno zrobić. A wielodzeidziczenie fajnie mieć, ale większość ludzi i tak nie wie jak tego rozsądnie używać. Jednak jeśli miałbym wybierać, czy mają dodać do Javy wielodzedziczenie czy przeciążanie operatorów, wybrałbym to drugie.
A w ogóle po co czekać na twórców języka aż dodadzą coś co jest znane od dawna w innym języku? Nie lepiej stworzyć sobie swój własny, ulubiony język? Co sądzicie o SCHEME?
0
0
Krolik napisał(a)
Co sądzicie o SCHEME?
Teh Scheme co jest tez w Gimpie? Jak tak to ble. Po prostu LISP :P
Ja tam pokochałem Pythona i w miarę możliwości trzymam się go. Polubiłem Javę, pomimo, że strasznie gadatliwa, ale w pełni rozumiem przesłanki ku temu. Lubię też C - jak dla mnie jest przejrzyste, czego o C++ powiedzieć nie mogę. I na koniec, stosując taką gradację od high do low asembler.
Lubię bawić się innymi językami. Dużo można z ich filozofii wyciągnąć i nauczyć się inaczej patrzeć na problemy. Ale np. wspomnianego LISP-a wolałbym omijać.
A zamiast zajmować się wróżeniem z fusów, jaki język, zdecydowanie lepiej się zająć "jak rozwiązywać problemy". Metodologie itp.
0
Krolik napisał(a)
Raczej tam, gdzie są wymagania na oszczędność zasobów. Szybkość działania programów w Javie czy .NET jest bardzo zblizona do C++, ale pamięciożerność jest ciągle zbyt duża.
No daj spokój, nie wmówisz mi że działający w tle program nie zmniejsza szybkości działania (no chyba że prędkość pozostaje bez zmian czy nawet wzrasta kosztem większego zużycia procesora, no ale ja dziękuję za taką prędkość ;)) Napisz w Javie grę z grafiką jak HL2 i (na podobnym sprzęcie) prześcigającą ją pod względem ilości wyświetlanych klatek na sekundę, to pogadamy ;) (a gier nie można w końcu lekceważyć, bo to taki sam biznes jak programy użytkowe - dajmy na to taki John Carmack zarabia pewnie kilkakrotnie więcej niż niejeden programista 'poważnych' programów ;))
Garbage collector to jest DOBRA rzecz, poza 1% przypadków gdzie i tak bez C++ ani rusz.
GC jest dużo szybsze niż ręczny malloc. Np. właśnie tam gdzie Java traci na wydajności do C++ przez np. wszechobecne dynamiczne rzutowanie czy sprawdzanie zakresów tablic w runtime, odrabia na szybszym zarządzaniu pamięcią.
Jak pisałem wyżej, o ile nie zbudowano procesorowego odpowiednika perpetuum mobile nie wmówisz mi że działający w tle program działa bez żadnego negatywnego wpływu na prędkość wykonywania głównego programu. (mogło by być tak gdyby np. program używający jednego procesora zostałby uruchomiony ma maszynie z dwurdzeniówką, ale ja tu mówię o normalnych sytuacjach ;)) A w końcu nie każdy projekt potrzebuje garbage collectora ;)
0
Ghostek napisał(a)
No daj spokój, nie wmówisz mi że działający w tle program nie zmniejsza szybkości działania
Nie musi działać w tle. Może być przeplatany. Chociaż to akurat nic nie zmienia.
Chodzi tutaj raczej o to, że co prawda w jednym miejscu coś tracisz, w drugim zyskujesz. Całościowo może być różnie.
Przykład z klatkami na sekundę jest trochę mało sensowny. Mogę Ci napisać program nawet pythonie (który jest od javy wolniejszy), który będzie robił tylko flip i wyświetlał liczbę klatek. Wynik będzie na poziomie podobnym jak w C. A to tylko dlatego, że prawdziwe przetwarzanie znajduje się w bibliotece/sterowniku zoptymalizowanym dla danej karty.
Całkiem inna sprawa, to po co mieć 500 klatek na sekundę, jak Twoje oko różnicy przy 100 nie zauważy.
I jak już jesteśmy przy temacie gier. Pisząc grę masz dostęp do 2 procesorów CPU i GPU. Przetwarzaniem grafiki zajmuje się GPU i do niego dostajesz się przez bibliotekę - język jest bez znaczenia. CPU wykorzystujesz pisząc logikę gry. W takich sytuacjach bardziej jest istotna prostota pisania, a nie wydajność.
0
Dryobates napisał(a)
Całkiem inna sprawa, to po co mieć 500 klatek na sekundę, jak Twoje oko różnicy przy 100 nie zauważy.
Ale różnica pomiędzy 5 a dajmy na to 25 klatkami na sekundę jest już całkiem zauważalna ;)
I jak już jesteśmy przy temacie gier. Pisząc grę masz dostęp do 2 procesorów CPU i GPU. Przetwarzaniem grafiki zajmuje się GPU i do niego dostajesz się przez bibliotekę - język jest bez znaczenia. CPU wykorzystujesz pisząc logikę gry. W takich sytuacjach bardziej jest istotna prostota pisania, a nie wydajność.
A obliczenia fizyczne to pies? Przecież te wszystkie rag-dolle i inne takie efekty żrą moc CPU jak głupie, więc na żadne marnowanie mocy obliczeniowej (typu właśnie jakieś wirtualne maszyny czy wymuszony garbage collector) nie ma miejsca (było by to zwykłym chamstwem w stosunku do użytkownika ;)). Poza tym dochodzą jeszcze graficzne efekty typu HDR które również wymagają 'wsparcia' procesora. Wiem, że teoretycznie przy procesorze dwurdzeniowym dało by się zwalić te obliczenia na drugi rdzeń, no ale w takim wypadku lepiej by było spróbować wycisnąć 100% z obu rdzeni ;)
0
Ghostek napisał(a)
Dryobates napisał(a)
Całkiem inna sprawa, to po co mieć 500 klatek na sekundę, jak Twoje oko różnicy przy 100 nie zauważy.
Ale różnica pomiędzy 5 a dajmy na to 25 klatkami na sekundę jest już całkiem zauważalna ;)
hehe
Nie wiem co to za gra, albo komputer musiałby być, aby 5 klatek było :)
Ghostek napisał(a)
A obliczenia fizyczne to pies? Przecież te wszystkie rag-dolle i inne takie efekty żrą moc CPU jak głupie, więc na żadne marnowanie mocy obliczeniowej (typu właśnie jakieś wirtualne maszyny czy wymuszony garbage collector) nie ma miejsca (było by to zwykłym chamstwem w stosunku do użytkownika ;)).
Typowe obliczenia, gdzie zmieniają się praktycznie jedynie parametry. Byle jaki JIT i efekty niewiele gorsze.
Nie zrozum mnie źle. Ja również uważam, że C nie umrze, tak samo jak i asembler. Są pewne zastosowania, w których nic nie może ich zastąpić. Ale tendencja w przemyśle jest taka, by odciążać umysł programisty jak najbardziej i pozwolić mu skupić się na zadaniach, jakich automat nie jest w stanie zrobić. Zarządzanie pamięcią to jeden z takich elementów. Przy okazji powodujący wiele błędów. Odśmiecacze utrudniają popełnienie niektórych z tych błędów, chociaż też wprowadzają inne problemy (m. in. rośnie tendencja programistów do rozrzutności pamięciowej). W każdym razie całościowo uznałbym ich działanie za pozytywne. Trzeba tylko nad ich jakością popracować. No i może zacząć implementować coś lepszego niż mark and sweep...
0
Ghostek napisał(a)
wirtualne maszyny
- A co to takiego?
- Nie wiem.
Teraz sie uzywa raczej kompilatorow JIT zamiast maszyn wirtualnych :)
0
Dryobates napisał(a)
Nie wiem co to za gra, albo komputer musiałby być, aby 5 klatek było :)
Dajmy na to takie 'demko technologiczne' Lost Coast (od Valve, można za darmo ze Steama ściągnąć jak kto nie wierzy ;)) - mimo 2,4 GHz procka i geForca 6800 (wiem że być może to już nie pierwsza jakość ale bez przesady, nie będę kompa co roku wymieniał ;)) pod sam koniec dostałem pokaz slajdów, nie wiem czy to nawet 1 fpm był ;) (a co do 'normalnych' produkcji to na razie szykuje się nawalone-od-ch***-efektów Crysis czy ja-wale-ile-tu-jednostek Supreme Commander ;))
Dryobates napisał(a)
Typowe obliczenia, gdzie zmieniają się praktycznie jedynie parametry. Byle jaki JIT i efekty niewiele gorsze.
Możliwe, ja to pisałem bardziej z perspektywy gracza niż programisty bo jeśli chodzi o programowanie gier to ja dopiero zaczynam ;) Ale gdyby to było takie proste toby te gry chyba nie były tak zasobożerne ;)
0
teraz wszyscy zajmują się rozwojem języków wyższego rzędu... jakby się kto wziął za napisanie tego C od nowa to świat byłby piękniejszy. Nie wiem jak z assemblerem ale póki co wydaje się nieśmiertelny ;-)
W czasach gdy zazwyczaj jakieś 70% kosztów jakie ponosi producent na stworzenie oprogramowania to jego serwisowanie, inwestowanie w języki, które to ułatwiają jest bardzo zasadne i nie służy temu żeby programistom było łatwiej ;-)
A producenci gier to sobie w kulki lecą bez dwóch zdań - to inna bajka.
0
Wolverine napisał(a)
Ghostek napisał(a)
wirtualne maszyny
- A co to takiego?
- Nie wiem.
Teraz sie uzywa raczej kompilatorow JIT zamiast maszyn wirtualnych :)
Off-topic:
A gdzie tam, wirtualizacja to teraz temat na topie, wszystko się robi wirtualne. Wirtualne maszyny, wirtualne serwery, wirtualna rzeczywistość, wirtualne sieci ;-)
Co prawda dotyczy to głównie administracji sieciami czy innymi serwerami, ale wirtualizowanie wchodzi w grę coraz bardziej. Sam sobie obecnie do testowania wyglądu/działania aplikacji internetowych używam Virtual PC z zainstalowanym specjalnym obrazem z Internet Explorerem 6. Bo wersja standalone IE6 pod Vistą nie działa.
A ze strony programowania to faktycznie JIT obecnie rządzi, już Java się jakiś czas temu pozbyła JVM i interpretacji bytecodu (na stałe? nie wiem, wiem, że JIT jest na wzór .NET).
0
JIT może i czasem wolniejszy, ale coś za coś. Nie można brać pod uwagę tylko samej wydajności.
Główne narzuty obecnych maszyn wirtualnych są powodowane przez sprawdzanie poprawności wszelkich operacji - częstsze sprawdzanie typów w runtime - nie ma niesprawdzanego, niebezpiecznego, szybkiego rzutowania typów, sprawdzanie zakresów tablic, stringów itp. Ale dzięki temu jednak programy pisane w .NET/Java wywalają się rzadziej, a na pewno w nie tak paskudny sposób jak błędnie napisane programy w C/C++. Pamiętam, że kiedyś żeby znaleźć jeden błąd typu "off-by-one" musiałem uruchamiać program pod specjalnym programem do sprawdzania błędów pamięci, coś ala JVM dla C++, który miał jednak tę wadę, iż powodował że mój program działał 30-100 razy wolniej i cały proces debugowania trwał koszmarnie długo. Gdybym przeliczył ten czas na pieniądze, to by się okazało, że mógłbym sobie wtedy dużo lepszy komputer kupić. A bez narzędzi do sprawdzania pamięci mój program sypał się w przypadkowych miejscach, zwykle kilkaset milionów taktów procka później, niż wystąpiła przyczyna błędu.
Spróbujcie uzyskać podobny stopień zabezpieczeń przed błędami w C++ - przez dodanie sprawdzania w runtime, jako dodatkowy kod. Wątpię czy komukolwiek wtedy udałoby się wyprzedzić JVM Suna.
Pyhon też jest fajny. Kod jest zarąbiście czytelny dzięki brakowi klamerek i wymuszenie prawidłowych wcięć. I chodzi na JVM: Jython. :)
0
I chodzi na JVM: Jython. :)
I na .NET też: IronPython :-)
0
Ostatnio zainteresowałem się Pythonem - potrzebny mi był do napisania paru wtyczek do Blendera, ale jak się okazuje chyba nie poprzestanę na tym ;) O ile (prawdopodobnie) również ustępuje prędkością C++'owi, ale w przeciwieństwie do np. Javy daje coś w zamian.
Jedyne, co mi się w nim nie podoba to brak typów (wybaczcie staroświecki tok myślenia, ale dla mnie skoro do dajmy na to 'x' mogę przypisać '12', a zaraz potem do tego samego 'x' mogę przypisać 'dwanascie', to ciężko wtedy mówić o typach ;)) oraz trochę chyba zbyt swobodny sposób traktowania obiektów (i nie tylko). Nie zrozumcie mnie źle, nie mam nic przeciwko językom mającym 'zaufanie' do programisty (prawdę mówiąc, niedobrze mi się robi na widok języków które starają się trzymać programistę za rączkę coby się przypadkiem nie pokaleczył - nie będę tu wytykał palcami, ale domyślacie się jaki język mam tu głównie na myśli ;)) ale chyba jest różnica pomiędzy swobodą jaką daje np. C++, a totalną anarchią jaka panuje w Pythonie ;) O ile dodawanie metod czy składowych do obiektów jest całkiem niezłym pomysłem, to jednak ich podmienianie... No cóż, ja na przykład jak wsiadam do samochodu to jestem przyzwyczajony, że po naciśnięciu np. klaksonu samochód zatrąbi. Gdyby wystrzelił wtedy rakietę typu ziemia-ziemia w najbliższy pojazd to byłbym troszeczkę zdziwiony ;)
Ale poza tym, pod wieloma względami C++ nawet nie ma do Pythona startu. (heh, nie wiedziałem że taki fanatyczny fanboy C++ jak ja wypowie kiedyś te słowa ;)) W Pythonie cenię głównie łatwość obsługi wszelkiego rodzaju list czy słowników (C++ traci na tym, że wszystkie typy zbiorcze prócz zwykłych tablic są dostępne tylko przez bibliotekę standardową - przez to brakuje pewnych mechanizmów, obecnych w Pythonie, które znacznie ułatwiają pracę z nimi) - wszystko za pomocą pętli for...in, bez pieprzenia się z ręcznym tworzeniem iteratorów czy sprawdzaniem wielkości. Inną przydatną rzeczą jest ujednolicony sposób korzystania z funkcji systemowych czy też tworzenia programów wielowątkowych. W sumie to za dużo jest tego by wymieniać ;) Więc jak pisałem, gdyby nie zmniejszona wydajność programów to C++ mógłby by się schować. :P
0
Owszem, molestowanie wężyka to świetna sprawa, ale czasem /hehe, nie tylko czasem/ lepszy jest lisp. Jeden z najstarszych obecnie używanych języków, ale swój potencjał ma - żaden język nie oferuje takich możliwości /do tego najmocniejszy preprocesor - makra/... W sumie ma też najlepszy /chyba, najlepszy... a przynajmniej jeden z najlepszych/ przelicznik linii kodu do okpodów kodu maszynowego.
0
Ghostek napisał(a)
Jedyne, co mi się w nim nie podoba to brak typów
Kwestia przyzwyczajenia. Jak trochę więcej popiszesz, to wszelkie typy zaczynają cię denerwować :)
for obiekt in obiekty:
print obiekt
Bez tego braku rozpoznawania typów (a dokładniej to braku statycznego typowania), byłoby to trudniejsze (a przynajmniej mniej czytelne, bo np. w javie też można, ale trzeba trochę się napisać). Poczytaj sobie o programowaniu generycznym. Lubisz STL? :)
LISP też to wszystko potrafi. Ale jak dla mnie za ciężko się w tych nawiasach połapać (Lots of Irritating Superfluous Parenthesis :P). No i trzeba się zmusić do myślenia funkcyjnego, które skądinąd jest bardzo fajne, ale często łatwiej jest coś zrobić imperatywnie.