Java - największy obecnie standard programowania?

1

Witajcie,

Od pewnego czasu zastanawiam się, czy nie zainwestować w naukę czegoś innego, niż Java, a co dobrze się zapowiada. Rozglądam się już wiele miesięcy, obserwuję co się dzieje i analizuję za i przeciw. Wiadomo, programista może mieć pewne preferencje. Moją jest oczywiście Java, którą stosuję wszędzie gdzie i kiedy się da, czyli wszędzie, jeśli tylko producent sprzętu/platformy daje taką możliwość.

Z mojego doświadczenia wynika, że producentem, który nie daje takiej możliwości, będzie w większości przypadków Microsoft. Jest to tym ciekawsze, że od kiedy Oracle przejął firmę Sun, Microsoft prezentuje się jako "wielki przyjaciel" Suna i Javy, którą rzekomo wspiera od momentu zakończenia niesnasek między obiema firmami (tj. 2004). Co do polityki biznesowej, to zamiary Ballmera są wyraźne jak na dłoni, podobnie zresztą jak wahania to w jedną to w drugą stronę Microsoftu. Jest oczywiste, że pomimo agresywnej promocji, działania na wielu torach jednocześnie i - co tu dużo nie mówić - bardzo dobrych rozwiązaniach technologicznych w wielu przypadkach, Microsoft nadal ewidentnie przegrywa z Google - bo o tą walkę chodzi ostatnio przede wszystkim. Zaryzykowałbym stwierdzenie, że miliony poszły w błoto.

Wracając do wyboru języka, ma on bardzo dużo wspólnego z polityką. A ta z kolei z tym, co się dzieje na rynku. Ostatecznie, jak pokazuje praktyka (np. MP3 vs lepsze formaty), ludzie są leniwi i wybierają niekoniecznie najlepsze rozwiązania; zresztą "najlepsze" można definiować bardzo, bardzo różnie.

Moje wnioski są następujące.

C# + .NET jest uznawany za świetną platformę, a język C#, po początkowym sceptycyzmie (np. dotyczącym nadmiernej obiektowości) został uznany za narzędzie - wespół z .NET - pozwalające w szybki i niskim nakładem zasobów uzyskiwać rezultaty, których brakuje w innych językach. Można powiedzieć, że ideał. Prawie... Nie wiem jak ze wsparciem bibliotek, jednak jest jeden duży minus tej platformy: poza Microsoftem nie jest właściwie niemal w ogóle wspierana, podczas gdy inne rozwiązania to albo open source albo są wspierane przez wiele organizacji non-profit lub firm. To oznacza, że bez względu na to, jak .NET będzie super, zawsze będzie ryzykownym rozwiązaniem, a Microsoft w ostatnim czasie ma coraz więcej problemów na różnych polach, co dodatkowo budzi wątpliwości przy decydowaniu się na tak "hermetyczne" rozwiązanie.

PHP jest dobrym, darmowym rozwiązaniem ze świetnym serwerem Apache. Ma wiele dobrych bibliotek dodatkowych, dających świetną funkcjonalność. Jest szybki w użyciu, przynajmniej przy małych projektach. Ma świetne wsparcie hostingowe, które w dodatku jest tanie.
Minusy: w praktyce jest wykorzystywany wyłącznie do www. Jest językiem "starej daty" jeśli chodzi o rozwiązania i ewidentnie cierpi na syndrom "przyklejonej obiektowości" jak C. Przy bardziej wymagających i złożonych projektach wychodzi trudność w utrzymaniu i "opiekowaniu" się kodem. Z tych względów wydaje mi się, że PHP, mimo że nadal bardzo popularny, powoli oddaje pola innym językom. Można rzec, że PHP jest nadal na pierwszym miejscu, jednak jego szczytowy okres już należy do przeszłości.

Python ma wielu entuzjastów. Jest prosty w użyciu i pozwala wiele osiągnąć niższym kosztem. Ale wsparcie i ilość bibliotek w porównaniu do PHP czy Javy jest znacznie gorsza. A to w praktyce niestety nie wróży mu zbyt dobrze. Python istnieje długo na rynku, zdobył wielu zwolenników, a mimo to nie rozwinął się aż tak bardzo, choć ostatnio przeżywa swój wzlot.

Ruby (a dokładniej - Ruby on Rails) jest prawdopodobnie największym konkurentem Pythona i przyznaję, że ciągle bacznie obserwuję jego rozwój. Bo na razie to, o czym możemy mówić w jego przypadku, to rzeczywiście dynamiczny rozwój, który być może zaowocuje dużą ilością bibliotek i silnym wsparcie, być może okaże się tymczasową modą. Jakkolwiek będzie, zaryzykuję stwierdzenie, że w najlepszym przypadku może zdetronizować PHP, bo na razie nie zapowiada się na to, by miał w praktyce być używany do innych zastosowań niż www (choć nigdy nie wiadomo).

C/C++ - jest jasne, że ten język praktycznie nie istnieje w nowoczesnym programowaniu www, czyli tym, które w ostatnich latach zaczęło dominować. Wystarczy spojrzeć na projekty, które tworzy się: albo są to aplikacje sieciowe przez HTTP, albo bardziej "hardcorowe" do obsługi pojedynczych urządzeń, jak systemy wbudowane czy aplikacje na specyficzne urządzenia, z których "najmniej specyficzne" są chyba telefony.

Myślę, że najważniejsze na rynku wymieniłem. Jak widać, właściwie wszystkie z nich są w jakiś sposób związane z programowaniem usług internetowych/intranetowych, odstaje tu tylko nieco C/C++, bo się nie przyjął w tej roli. Teraz chciałbym obiektywnym okiem rzucić na pozycję Javy, od której już od dobrych kilku lat mówi się, że być może jej pozycja zostanie zachwiana. Czy tak faktycznie jest
? Bez względu na preferencje, lepiej znać smutną prawdę, niż łudzić się, że jest inaczej - to moja dewiza.

Java nie jest nowym językiem, jeśli liczyć od daty upowszechnienia. Właściwie, to z pośród powyższych, tylko C/C++ jest starszy - rozpatrując pod tym kątem. Na szczęście twórcy Javy od razu szczęśliwie określili dobry kierunek i pomimo pewnych zaszłości z C++, które są czasami wymieniane jako wady, nie spoczęli na laurach i nowe wersje Javy może już nie tyle wyznaczają trendy, co obecnie gonią konkurencję. Właściwie to bardzo dobrze, bo przez to zyskuje ona na stabilności, która jest jedną z jej największych zalet.

Microsoft zbadał co w Javie jest plusem, a co powoduje problemy, i na tej bazie osiągnął sukces. Skoro tak, to teraz deweloperzy pracujący dla Suna mogą robić dokładnie to samo (i to robią): patrzą, co na rynku się sprawdza w innych językach, i włączają to do Javy. Ponadto robią tak również inni, dzięki czemu Java ma obecnie prawdopodobnie największą ilość dodatkowych bibliotek i rozwiązań - niektórych lepszych, niektórych mniej - ale zawsze. Znalazły się także odpowiedzi na rozwiązania znane z Ruby'ego - nie wiem, jak się sprawdzają w praktyce, bo nie testowałem tego, jednak faktem jest, że nie trzeba angażować Ruby on Rails, by skorzystać z jego zalet (przynajmniej teoretycznie).

Minusy Javy to wspomniane zaszłości (mówi się, że C# został lepiej zaprojektowany) + czasami duże nakłady pracy by uzyskać pewne efekty. Rozwiązaniami proponowanymi przez zwolenników Javy są kolejne frameworki, biblioteki, rozwiązania, czy jak to tam sobie oni nazywają, ale nie zmienia to faktu, że każde nowe rozwiązanie wymaga dodatkowych nakładów. I właściwie słusznie: ile można mnożyć tych nakładek na Javę? Nie lepiej zrobić coś raz, a porządnie?

Nie licząc PHP, Java dzieli jeszcze inny problem z pozostałymi językami: hosting, zwłaszcza w Polsce, to ciężka sprawa. Co więcej, nie ma w Javie takiego standardu, jak w PHP: jest Apache i właściwie z niczego innego się nie korzysta. Dlatego PHP zostanie jeszcze długo na pierwszym miejscu pod względem popularności. (Jak napisałem, standardem zostają niekoniecznie najlepsze rozwiązania, bo istnieje też zjawisko inercji, która zresztą - paradoksalnie - dobrze wróży również Javie).

A teraz spójrzmy na wykorzystanie Javy:

  • międzyplatformowość w środowisku desktop; łatwość konwersji do zależnych od platformy plików wykonywalnych
    (w praktyce nie jest to jednak aż tak duża zaleta, bo większość oprogramowania i tak jest pisana pod konkretny system operacyjny, a większość programów obecnie instalowanych na HDD wymaga wykorzystania zasobów, do których potrzebny jest język natywny bądź te zasoby są uzależnione i tak od rodzaju OS, np. rejestr przy Windows)

  • www po stronie klienta, tj. przeglądarki (czyli aplety oraz Web Start, właściwie niemal niewykorzystywane w praktyce)

  • J2ME (jeden z największych sukcesów Javy, mimo, że wiele krytyki jest na tym polu; ale wystarczy spojrzeć co jest na rynku: trudno znaleźć aplikację lub grę, która działa na telefonie - i nie jest nim iPhone - a nie została napisana w Javie; wspomnianą siłą inercji teraz trudno producentom odejść od Javy, nawet, jeśli promowany jest C/C++/Objective-C czy inne rozwiązania)

  • J2EE (obok J2ME prawdopodobnie największy sukces Suna; wady i zalety J2EE w porównaniu do innych platform przejrzałem wyżej)

  • promocja przez większość najbardziej liczących się na rynku graczy, czyli Google (GWT!!!, Android!!!), Oracle, IBM, większość producentów telefonów jak Nokia, Samsung, LG i inni

Podsumowując. Po tej analizie doszedłem do wniosku, że nie ma bardziej wspieranego języka i mającego więcej zastosowań, niż Java. Aktualnie najbardziej przyglądam się Ruby'emu, który może stanowić dobrą alternatywę dla Javy, a dzięki takim rzeczom, jak JRuby można łączyć oba. Na razie jednak nie inwestuję w niego czasu, bo prawdę mówiąc nie widziałem wielu projektów z użyciem go. Fakt, dla których Google wybrał właśnie Javę na GWT i Androida jest bardzo zastanawiający. Google oczywiście również wspierał Pythona i (chyba) Ruby'ego, jednak ostatecznie to GWT jest uznawane za platformę nr 1, którą zresztą wykorzystuje jako podstawę do kolejnych swoich internetowych projektów.

Na razie zostaję przy Javie. Jeśli ktoś ma inne zdanie lub chciałby coś dodać, gorąco zachęcam, bo myślę, że korzystniej będzie dla nas, by obraz tego, jak wygląda przyszłość na rynku IT, był jak najbliższy rzeczywistości, a nie iluzji preferencji.</b>

0

ee panie, napisz jakies streszczenie :P

anyway nie ma czegos takiego jak standard oprogramowania, java sie do wszystkiego nie nadaje, c++ sie do wszystkiego nie nadaje, php sie do wszystkiego nie nadaje, a jak sie cos do wszystkiego nadaje to znaczy ze jest do d**y albo *uja wiesz o tej technologi [diabel]

0

@forsberg, co do javy SE to nie jest tak do końca. Po pierwsze aplikacje SE to przede wszystkim narzędzia developerskie.
Co do GWT, to choć piszę w nim dość dużo ostatnimi czasy to uważam go za średnią platformę. Wsparcie ze strony Google jest, ale jedyną zaletą jest tu darmowy hosting w ramach google apps. Zobaczymy co będzie z Androidem 2.0 i Chrome OS.
Co do samej Javy... Cóż też się nie zgodzę, że platforma JEE będzie przyszłością i w ogóle kuul. JEE jest niezłą bazą, ale tak naprawdę przyszłość należy do języków takich jak Groovy, Scala czy Clojure. Mówiąc najogólniej programowanie funkcyjne, DSLe i coraz to większe upraszczanie tworzenia procedur biznesowych.

0

@cepa Zauważ, że specjalnie wklepywałem ten bb-code, by pogrubiać języki i podsumowanie.

Podsumowanie podsumowania. Napisałem to wszystko, by ocenić, które języki są obecnie wykorzystywane do czego, a także to, czego prawdopodobnie możemy spodziewać się w najbliższej przyszłości. Jeśli nie będzie żadnej nowej rewolucji na miarę Google (tzn. nowej firmy tego kalibru na rynku), wygląda na to, że Java nie zostanie tak łatwo zdetronizowana. To jest mój najważniejszy wniosek (bo było ich oczywiście więcej).

Nie myślę więc o technologii, która jest do wszystkiego, ale o języku, który jest wykorzystywany w najbardziej powszechnych zastosowaniach.

C/C++ w wielu systemowych ("hardocorowych") zastosowaniach jest niezastąpiony i wygląda na to, że chyba nic tego nie zmieni (niedużymi wyjątkami są J2ME czy JavaCard).

W najpopularniejszym obecnie programowaniu www konkurencja jest spora, którą wymieniłem i pogrubiłem.

W programowaniu "małych" urządzeń (małych pod kątem możliwości, niekoniecznie rozmiarów fizyczny ch), jak telefony, właściwie mamy niemal wyłącznie C/C++ i Javę.

Tyle jeśli chodzi o najpopularniejsze zastosowania programowania "komputerowego" - 3 rodzaje: www, systemowe i a'la desktop.

@Koziołek - narzędzia developerskie JSE, jeśli wziąć pod uwagę popularność, ograniczają się właściwie do Eclipse, z tego co zaobserwowałem. Właściwie, to można już powoli zacząć uważać Eclipse za niemal monopolistę, który być może walczy jeszcze nieco z NetBeans (po przejęciu Oracle-Sun być może jeszcze mocniej Eclipse na tym skorzysta); Visual Studio to razem z całym MS osobna parafia oczywiście ;)

Co do upraszczania języków, o których piszesz, podejrzewam, że masz rację. Jednak obecnie jeszcze królują ciągle Spring/Hibernate/Struts. Może tak być, że w przyszłości Java będzie instalowana na serwerze tylko po to, by stanowić warstwę pośrednią, niewykorzystywaną w praktyce przez programistów front-end (czyli najistotniejszej dla klienta warstwy prezentacyjno-funkcjonalnej), którzy mają np. Groovy czy inny JRuby.

Propo GWT, to nie tyle myślałem o jego przyszłości, co ustanowieniu po raz kolejny Javy jako podstawy dla tej platformy. Jakby nie patrzeć, w GWT pisze się jak w J2SE. Jeśli możesz wybrać pomiędzy Rubym a Javą+Rubym, to większość ludzi tworzących złożone projekty zapewne wybierze ten drugi, bo (cytat z książki, gdzie porównuje się GWT z Rubym): "It is not designed, though, for complex interactions between the client and server" - chodzi o Ruby'ego właśnie.

0

Po pierwsze - kilka miesiecy rozpoznajesz temat a nie widzisz roznicy miedzy Ruby a Ruby On Rails, czy PHP a Apachem. Po drugie, powiem krotko i zwiezle: jezyk jest narzedziem, a narzedzie dobiera sie do zadania, nie na odwrot. Specjalizowane narzedzie do wlasciwego zadania nadaje sie zawsze lepiej niz ogolne i tzw. "uniwersalne" rozwiazanie.

0

Przede wszystkim nie zamierzam toczyć wojny który język jest lepszy, bo wiem, że takiego nie ma. Wydaje mi się, że niektórzy mogli tak to odebrać. Jeśli tak, to jasno piszę, że nigdzie nie twierdzę, że Java jest najlepszym językiem (popatrzcie zresztą co napisałem o C#).

johny_bravo napisał(a)

nie widzisz roznicy miedzy Ruby a Ruby On Rails, czy PHP a Apachem

Można też ując to inaczej: johny bravo nie widzi różnicy między teorią a praktyką - poniżej ją wyjaśniam.
PHP to język, a Apache to serwer i w teorii oba nie mają ze sobą nic wspólnego.
W praktyce, mają ze sobą bardzo wiele wspólnego. Tak jak język bez dobrego IDE nie ma wielkich szans się przyjąć (do czasu, kiedy ktoś to IDE stworzy), tak samo platforma www bez dobrego serwera będzie martwa, bo nie można jej wykorzystać w praktyce.
Może dla kogoś przyzwyczajonego do C czy Basica jedyne co ma znaczenie, to wybór języka programowania, ale przy www nie jest to już tak oczywista sprawa. Dlatego wskazywałem na duże znaczenie (ciągle) PHP i Javy: mamy tutaj dobre serwery, świetne wsparcie i mnóstwo bibliotek.
"Comprehensive approach" (jeśli nie znasz angielskiego - podejście do problemu bazujące na całościowym spojrzeniu na używane technologie, od serwera po język w praktyce) to to, o czym właśnie myślę.

johny_bravo napisał(a)

Po drugie, powiem krotko i zwiezle: jezyk jest narzedziem, a narzedzie dobiera sie do zadania, nie na odwrot. Specjalizowane narzedzie do wlasciwego zadania nadaje sie zawsze lepiej niz ogolne i tzw. "uniwersalne" rozwiazanie.

To stwierdzenie słyszałem już wiele razy, ale znowu - w praktyce wygląda to jednak inaczej niż w teorii.
Jeśli masz firmę i tworzysz oprogramowanie w Javie, masz stworzone mnóstwo kodu pomocniczego (tzw. klocków), z którego szybko budujesz już kolejne aplikacje, to zmiana technologii na jakąkolwiek inną musi być naprawdę solidnie przemyślana.

Albo inaczej: ile w praktyce znasz firm, które oferują wybór języka programowania klientowi? Np. PHP, Java albo Ruby? Bo jeśli Twoje twierdzenie jest poprawne, to firmy powinny właśnie zmieniać języki jak rękawiczki, w zależności od problemu.

PS A tak nawiasem ciekawy jestem, czemu przyszłość programowania to jest tuzinkowy off-top, a nie nietuzinkowy temat? ;)

0

@up - o tym ze jezyk wybiera sie do zadania to jest bardzo popularne stwierdzenie, ktore wielu lubi powtarzac jak mantre. Ciekawi mnie ilu programistow tak naprawde tak robi, ilu ma taka mozliwosc (polityka firmy itp), ilu sie chce, ilu ma umiejetnosci i checi i czas by chlonac nowe... Wiadomo, sa tacy ktorzy tak robia, na pewno na tym forum rowniez, moze nawet Ty, a pewnie czesc powie ze ci ktorzy tak nie robia to nie programisci i takie tam.
No wiec jak to jest?

Napisawszy to, calkowicie sie zgadzam z tym stwierdzeniem i praktykuje w miare mozliwosci :d Mam akurat taka sytuacje ze mamy projekt w poczatkowej fazie, mozemy troche eskperymentowac (co prawda mamy narzucone ze runtime ro JVM, ale i w obrebie tego srodowiska jest pare ciekawych opcji), i caly zespol jest wzglednie otwarty i lubi sie uczyc.

Ten @up byl do Jhnego_bravo.

0

Po kolei:

  • Interpreter php, pojdzie na kazdy serwerze www, ktory zechce przekazac mu poprawnie parametry. To, ze najczesciej jest to Apache wynika z zaszlosci historycznej - byl zdaje sie pierwszy. I nie zgodze sie - w praktyce to nie jest to samo, jak bardzo bys nie czarowal. Php moze dzialac samodzielnie jako interpreter, serwer www jest tylko opakowaniem interfejsu.

  • Zeby klocki byly przenosne nie musza byc w tej samej technologii. Sa przeciez dllki, uslugi, webserwisy i pewnie milion innych interfejsow programowych do przekazania parametrow i odebrania odpowiedzi modulow. Jasne, ze lepiej wspoldzielic kod, ale czasem tez lepiej oddzielic moduly od siebie wlasnie po to, by nie zespolily sie ze soba w jeden wielki worek o przestrzeni nazw Firma.Common.Utils.*

  • Tak, mam przyjemnosc wybierac jezyk do zadania lub zgadzac sie z moim pracodawca, ze jezyk jest odpowiedni. I nie, nie musi to byc zmienianie jezykow jak rekawiczek. Wystarczy jeden do okienkowych, jeden do www, jeden do bibliotek i pewnie tyle. Oczywiscie moze to byc ten sam, moze to byc inny.

  • Klienta zwykle nie interesuje technologia wykonania, chyba ze moze na tym zaoszczedzic. Interesuja go koszty, czas, spelnienie wymagan i pozniejsze koszty utrzymania. Jesli wybor technologii wplywa na ktorykolwiek z tych kryteriow to tak, wtedy klienta interesuje.

0

Nie ma to jak rzeczowa dyskusja :)

johny_bravo napisał(a)

Po kolei:

  • Interpreter php, pojdzie na kazdy serwerze www, ktory zechce przekazac mu poprawnie parametry. To, ze najczesciej jest to Apache wynika z zaszlosci historycznej - byl zdaje sie pierwszy. I nie zgodze sie - w praktyce to nie jest to samo, jak bardzo bys nie czarowal. Php moze dzialac samodzielnie jako interpreter, serwer www jest tylko opakowaniem interfejsu.

Wiem wiem :) Ale po prostu - w praktyce - nie jest wykorzystywany. I mogę się z Tobą założyć, że nie będzie, jeśli sam na siłę tego nie zrobisz. Na siłę, bo PHP nie posiada takiego wsparcia w programowaniu desktop, jak C/C++ czy Java.

Co do Apache'a - skoro tak wszyscy stosują, to znaczy, że jest to sprawdzone rozwiązanie w praktyce. Możesz na siłę próbować innych serwerów - tylko po co marnować na to czas i pieniądze, hm?

Ja wiem, że w teorii to wszystko da się zrobić i że PHP i Apache nie mają ze sobą nic wspólnego. Ale w praktyce (w rzeczywistości) mają, bo gdyby było inaczej, to byłoby inaczej (= Apache nie byłby monopolistą w serwerach PHP). Rozmawiamy tutaj o akademickim podejściu vs biznesowym. W tym drugim nikt nie zaprząta sobie głowy tworzeniem nowych, abstrakcyjnych języków programowania, jeśli nie ma po temu konkretnego powodu.

W teorii możemy tworzyć nowy super-Basico-Asemblero-Pythono-Ruby-Java-C-i-co-jeszcze-ci-tam-wpadnie, ale zwykle robi się to na studiach, kiedy takie eksperymenty nie wiążą się z finansami. Dlatego Torvalds eksperymentował z Linuxem na studiach, a nie w pracy. W rzeczywistym życiu powstają hybrydy sprawdzonych rozwiązań, jak JRuby czy GWT (Ruby+Java czy Java+JavaScript).

Nie wiem jak to inaczej wyjaśnić, chyba wyczerpałem swoje możliwości.

johny_bravo napisał(a)
  • Zeby klocki byly przenosne nie musza byc w tej samej technologii. Sa przeciez dllki, uslugi, webserwisy i pewnie milion innych interfejsow programowych do przekazania parametrow i odebrania odpowiedzi modulow. Jasne, ze lepiej wspoldzielic kod, ale czasem tez lepiej oddzielic moduly od siebie wlasnie po to, by nie zespolily sie ze soba w jeden wielki worek o przestrzeni nazw Firma.Common.Utils.*

Oczywiście. Tylko wybór języka programowania niesie za sobą szereg konsekwencji czysto biznesowych, jak poniższy:
Masz nową firmę, zatrudniłeś kilku programistów PHP do 3 poprzednich aplikacji www, a teraz okazuje się, że nowy projekt najlepiej będzie stworzyć w Rubym. Zatrudniasz nowych ludzi? Każesz uczyć się Ruby'ego "starym"? Czy jednak wolisz stworzyć nieco "gorszy" kod w PHP?
A może będziesz od początku rekrutować wyłącznie ekspertów od wszystkiego, na wszelki wypadek?

Nadal jestem zdania, ze wybór języka do problemu to czysta teoria, ale widzę, że moje doświadczenie różni się od Twojego.

johny_bravo napisał(a)
  • Tak, mam przyjemnosc wybierac jezyk do zadania lub zgadzac sie z moim pracodawca, ze jezyk jest odpowiedni. I nie, nie musi to byc zmienianie jezykow jak rekawiczek. Wystarczy jeden do okienkowych, jeden do www, jeden do bibliotek i pewnie tyle. Oczywiscie moze to byc ten sam, moze to byc inny.

A więc jednak: jeden do www. A przecież różnice pomiędzy technologiami są duże. Więc wybrać optymalny język do danego serwisu i mieć przez to biznesowe problemy, czy też wybrać nieoptymalny język?

Do okienek to nie ma w cale takiego dużego wyboru: jeśli używasz C/C++, to przechodzisz do innego problemu: wybór API, które jednak zwykle ogranicza się do tych Microsoftowych, chyba, że piszecie dla Linuxa.

Ale jeśli masz w firmie programistów od Javy, którzy średnio stoją ze (zwykle) niskopoziomowym C/C++, to chyba lepiej już wykorzystać J2SE dla klienta, chyba, że ten ma opory przed instalowaniem JRE na komputerach (z reguły nie ma, jeśli przekłada się to dla niego na niższy koszt zakupu).

johny_bravo napisał(a)
  • Klienta zwykle nie interesuje technologia wykonania, chyba ze moze na tym zaoszczedzic. Interesuja go koszty, czas, spelnienie wymagan i pozniejsze koszty utrzymania. Jesli wybor technologii wplywa na ktorykolwiek z tych kryteriow to tak, wtedy klienta interesuje.

Koszty są po obu stronach - nie tylko klienta. Ale masz rację: tutaj dochodzimy do problemu prowadzenia działalności gospodarczej IT - koncentrować się na jednej technologii, czy też ryzykować tymczasowy brak zajęć dla specjalistów od określonej technologii?

Są firmy, które znalazły pośrednie rozwiązanie: podpisują z programistą kontrakt na kilka m-cy na czas stworzenia projektu, zatem nie muszą zatrudniać go na stałe. Są też duże firmy outsourcingowe, które robią mnóstwo projektów w różnych językach i muszą zatrudniać ludzi od różnych technologii.

Ale w praktyce programowanie www i wybór technologii (bo programowanie www mam tu przede wszystkim na myśli) nie jest tak nieograniczone, jak to mawiają profesorowie na uniwersytetach. Biznesowa rzeczywistość potrafi każdy ideał sprowadzić na ziemię i sprawdzić co wówczas z niego zostanie. ;)

0

No dobrze, widze, ze rozbijamy sie tutaj o troche inny problem. Podsumuje go krotkim troche niesprawiedliwym uogolnieniem (bez obrazy) - programista jednego jezyka to nie programista. Dla programisty nauczenie sie w tzw. miedzyczasie nowego jezyka to nie powinien byc problem. Ja bez problemu posluguje sie phpem, c#, c/c++, java (choc tutaj malo komercyjnego doswiadczenia, wiec nie cwaniakuje) + otoczkowe jezyki www jak javascript, czy actionscript. Nauczylem sie ich, bo potrzebowalem swego czasu. Stad tak oczywisty dla mnie, a stanowiacy luksus dla innych, wybor jezyka do zadania. Byc moze dlatego sie nie zgadzamy.
Jako pracodawca tez celowalbym w tym, ze albo programista byl co najmniej dwujezyczny albo wykazywal potencjal nauczenia sie jezyka/technologii przed projektem. Wtedy wystarczy 10%-20% specjalistow i reszta, ktora beda prowadzic.

0

Ja odnose sie do mantry i ogolnie do wyboru co do zadania.

Z pewnoscia nie jest tak rozowo, malo osob specjalnie uczy sie jezyka pod zadanie raczej programista powinien badac rynek wybierac sobie jakies jezyki i tak (przykladzik)

Znam
O-Pascal
C++
Ruby (+ROR)

Ucze sie
PHP

i mam do napisania strone www na serwerze wspierajacym PHP i Ruby. Mimo, ze (zalozenie)w Ruby pewnie wyszlo by lepiej wybieram PHP bo znam ten jezyk lepiej i nie chce ryzykowac.

Mam do napisania strone www na platformie jakiegos malego uP, wybieram C++ (w stylu cos co znane jako CGI, zreszta pozostale to tez to)

Za rok jak bedzie
Znam
O-Pascal
C++
Ruby (+ROR)
PHP

Ucze sie
C#
Java

bedzie juz inaczej. Naturalnie tez nie ma szans poznac wszytskiego w 100%. Ja np. nie mam czasu na Jave (nie chodzi tu juz o jezyk) a bardzo bym chcial ... po prostu, moze gdyby byl to wymog grupy i moja nauka byla by finansowana ...

Pojawil sie tu drugi aspekt, nie samym jezykiem czlowiek zyje a jeszcze bibliotekami do tego jezyka i dobra znajomoscia systemow.

0

Ale nie przesadzajmy, ze zeby napisac cos dobrze to albo trzeba znac wysmienicie jeden uniwersalny jezyk (czyt. Java) albo znac miliony superspecjalizowanych jezykow jak c++. Z takim podejsciem to wypadaloby znac Fortran, zeby pisac operacje matematyczne, asm zeby "optymalizowac", c, zeby samemu zarzadzac pamiecia, c++, bo obiektowy, itp, itd. Dlatego podzielilem wczesniej wybor na cale 3 kategorie. Mi do tej pory takie 3 kategorie wystarczaly i tez nie musze zawsze wybierac wysmienitej technologii, wystarczy mi po prostu odpowiednia. Ta, w ktorej nie uzywam armaty do zabicia muchy (np. c++ do serwowania strony www).

Oczywiscie, ze znajomosc bibliotek, frameworkow, IDE pomaga w zyciu. Ale biblioteki zwykle nie sa potrzebne do napisania krotkiej funkcjonalnosci w malo znanym nam jezyku, ktory wybralismy, bo jest ku temu powazny powod. Jesli uzywamy frameworka to tez zwykle jest to obszerniejsza sprawa, itp. Jesli mamy napisac cala duza aplikacje i brac za to odpowiedzialnosc, to z czystym sercem wybiore to co znam dobrze i moge pozniej potwierdzic, ze rozwiazanie jest poprawne, czyste, utrzymywalne i skalowalne. Chyba, ze nic co znam nie nadaje sie za bardzo do takiego rozwiazania. Wtedy pozostaje zrezygnowac albo nauczyc sie nowego.

0

No to powiem jak to wygląda w mojej pracy:
Do głównego projeku C, C++ i Java. Do pomocniczych narzędzi Bash, Python, AWK, czasem Perl. Do małych webowych tooli PHP. Do większych tooli i strony firmy: JSP. Do logik biznesowych stworzyli interpreter specjalnego języka.

Jaka przyszłość tego wszystkiego będzie? Mam nadzieje, że będzie tak jak koziołek mówi czyli przyszłością będą języki obiektowo-fukcyjne ale wcale nie jestem przekonany że tak się stanie.
A Java stanie siędrugim COBOLem, będą pisane w niej systemy typu legacy więc zapotrzebowanie pewnie nigdy nie zniknie.

1

Jaka przyszłość tego wszystkiego będzie? Mam nadzieje, że będzie tak jak koziołek mówi czyli przyszłością będą języki obiektowo-fukcyjne ale wcale nie jestem przekonany że tak się stanie.

Języki obiektowo-funkcyjne są w obiegu dosyć długo. Python jest starszy niż Java, Ruby jest chyba niewiele młodszy, Scala jest dosyć nowa, ale nie widać, żeby się wszyscy na nią jakoś rzucali. IMHO, żeby jakiś kolejny język programowania stał się KOLEJNĄ DUŻĄ RZECZĄ (jak C++ po C i Java po C++) to musi co najmniej:

  1. Integrować się łatwo i dobrze z istniejącymi bibliotekami Java / C. Większość nie przerzuci się na język, w którym nie da się prawie nic zrobić, bo "jeszcze nie napisano bibliotek".
    2a. Mieć prostą i minimalistyczną składnię narzucającą konwencje kodowania. Scala jest przekombinowana. C# miejscami też (np. structy - z punktu widzenia programisty zupełnie zbędne - dodane tylko dlatego, że obecne kompilatory są zbyt głupie by robić inlining obiektów i pełną specjalizację kodu). Prosta składnia i minimalizm wpływa na szybkość uczenia się nowego języka. Wszelkie języki, które oferują możliwość programowania na tysiąc sposobów w tysiącu dialektów sprawiają kłopoty w programowaniu zespołowym (np. C++).
    2b. Opierać się na programowaniu imperatywnym/obiektowym, jako głównym paradygmacie. Chyba, że wymyślą jakiś zupełnie nowy paradygmat programowania. Języki czysto funkcyjne lub 90% funkcyjne z domieszką obiektowości nie mają szans, choćby tysiąc profesorów je promowało - są zbyt trudne do pojęcia przez większość ludzi wychowanych na programowaniu imperatywnym.
  2. Redukować koszty tworzenia oprogramowania bardziej niż obecne rozwiązania mainstreamowe. C++ oferował obiektowość ponad C. Java oferowała GC i wyeliminowanie większości trudnych do wyłapania błędów w C++. Nowy język musi oferować coś tego typu, żeby mógł się przebić.
  3. Być wspieranym przez więcej niż jeden podmiot/korporację, nie być przywiązanym do jednej platformy.

Na razie nie widzę żadnego języka, który w świetle tych punktów mógłby zagrozić Javie. Wszystkie języki, które weszły do nurtu głównego - spełniały te kryteria.

0

Języki czysto funkcyjne lub 90% funkcyjne z domieszką obiektowości nie mają szans, choćby tysiąc profesorów je promowało - są zbyt trudne do pojęcia przez większość ludzi wychowanych na programowaniu imperatywnym.

IMHO funkcyjne na pierwszy raz mogą być prostsze niż te imperatywne. To raczej kwestia przyzwyczajenia do imperatywnego stylu.

0

Spróbuj nieprogramiście wytłumaczyć rekurencję i iterację. Jak myślisz, z czym pójdzie łatwiej?
Spróbuj wytłumaczyć jak programować w języku, w którym program nie ma globalnego stanu, podczas gdy niemal wszystko w otaczającym świecie ów stan posiada.

Języki imperatywne/obiektowe są mocno zbliżone do modelu, którym ludzie operują na codzień. Wystarczy spojrzeć na konstrukcje języka naturalnego - zdania mają podmiot (obiekt), orzeczenie (wywołanie metody), dopełnienie (argumenty).
Zagnieżdżanie wywołań metod -> zdania podrzędnie złożone. Od dziecka również uczymy się dzielić obiekty na klasy np. moja 1,5 roczna córka doskonale odróżnia już kilkadziesiąt klas obiektów, mimo że umie mówić raptem kilka słów (swoją drogą rozpoznaje obrazy lepiej niż najlepsze SVMy strojone algorytmami genetycznymi odpalane na wieloteraflopowych klastrach :-P ).

0

Języki imperatywne/obiektowe są mocno zbliżone do modelu, którym ludzie operują na codzień.

Języki funkcyjne są mocno zbliżone do modelu matematycznego, którego ludzie uczą się przez kilka-kilkanaście lat w życiu :>.

0

Kiedyś widziałem wytłumaczenie nieprogramiście co to rekurencja: była podana definicja chodzenia.
Zrób krok i idź dalej, nieprawdaż że genialnie i proste? W tym przypadku bardziej naturalne niż definicja iteracjyjna

Spróbuj wytłumaczyć jak programować w języku, w którym program nie ma globalnego stanu, podczas gdy niemal wszystko w otaczającym świecie ów stan posiada.

Komuś kto nie miał do czynienia z programowaniem imperatywnym, bez problemu da się to wytłumaczyć. Znałem gościa, którego ojciec był programistą Prologa i który nauczył go w tym programować. Gość poszedł na studia i nie mógł zrozumieć C. Tak więc naprawde wiele zależy od jakiego języka się zaczyna.

Poza tym jeżeli programowanie funkcyjne jest zbliżone do modelu matematycznego to jest też bardzo ograniczone, gdyż świat trudno opisać matematyką (co innego jeśli chpdzo o problemy matematyczne).

0

Tak, bo funkcyjność wyklucza skorzystanie z OOP...

0

@rnd, wszystko można opisać matematyką. Tyle tylko, że czasami ten opis jest bardzo skomplikowany.

@..., niekoniecznie wyklucza. Programy funkcyjne nadal operują na danych, które najłatwiej opisywać w sposób obiektowy, a zależności pomiędzy danymi przechowywać w modelu relacyjnym.

0

Bardziej mówiłem o pure functional.
Mieszanka funkcjonalności z obiektowością bardzo mi odpowiada.

0

Widzę, że znaleźliście w tym temacie większy potencjał, niż z początku założyłem. Dzięki temu dyskusja jest jeszcze ciekawsza. A matematyką to pewnie nawet "jakość" zachodu słońca da się zmierzyć ;)

Ze wszystkim co piszecie zgadzam się, jedynie zastanawia mnie ustalenie odpowiednich proporcji pomiędzy tym wszystkim. Są tu jakby dwie sprzeczne kwestie: z jednej strony pewna inercja, z drugiej - chęć obniżania kosztów.

Przede wszystkim rozbiłbym problem na kilka pod-problemów, które nie zawsze idą w parze, często wręcz trzeba wybierać pomiędzy różnymi opcjami.

  1. Open-Source vs Rozwiązanie firmowane przez jedną korporację.
    Do drugiej grupy myślę, że poza Microsoftem, możemy zaliczyć np. oprogramowanie Apple i po części usługi Google.
    Oba mają plusy i minusy. Pewnym wyjściem alternatywnym są ostatnio modne, firmowane rozwiązania przez konsorcjum różnych korporacji, w dodatku traktowane jako open-source.

  2. Dostępne wsparcie i biblioteki.

  3. Stabilność, pewność i bezpieczeństwo, że system nie rozsypie się tylko dlatego, że wersja frameworku 4.942-night-build była na szybkiego skompilowana po dwudziestej kawie na 3 godziny przed pójściem rano do pracy.

  4. Szybkość tworzenia.

  5. Łatwość znalezienia na rynku programistów od technologii vs gotowość do ich szkolenia (koszty).

  6. Przeciętne wynagrodzenie programisty dla danej technologii (chociaż generalnie nie jest tutaj tak źle, bo wiadomo, że tworzenie oprogramowania kosztuje i klient i tak musi którejś firmie za to zapłacić, czy będzie to średniej wielkości polska firma, czy też np. IBM)

  7. I prawdopodobnie jeszcze inne.

poza tym tak jak pisze johny_bravo, nie przesadzajmy. Co więcej, tu nie liczy się wyłącznie interes firm, ale również prywatne życie człowieka.

Ponadto zgadzam się też, że nie ma sensu dla jednej biblioteki przerzucać się na inną platformę. Jeśli np. w jakimś języku brakuje biblioteki do chociażby tworzenia zaawansowanych wykresów na www, można zastanowić się nad kosztem stworzenia samemu lub wespół z innymi od podstaw takiego rozwiązania. Ostatecznie, trzeba zdecydować, co się bardziej opłaca.

2

JEE jest niezłą bazą, ale tak naprawdę przyszłość należy do języków takich jak Groovy, Scala czy Clojure. Mówiąc najogólniej programowanie funkcyjne, DSLe i coraz to większe upraszczanie tworzenia procedur biznesowych.

Oj @Koziołek chyba ktoś się tu mylił ;]

0
scibi92 napisał(a):

JEE jest niezłą bazą, ale tak naprawdę przyszłość należy do języków takich jak Groovy, Scala czy Clojure. Mówiąc najogólniej programowanie funkcyjne, DSLe i coraz to większe upraszczanie tworzenia procedur biznesowych.

Oj @Koziołek chyba ktoś się tu mylił ;]

Akurat można teraz programować funkcyjnie w Javie. Natomiast Groovy jest używany w ramach DSL do Gradle, który jest obecnie domyślnym build systemem dla nowych projektów w Javie i Kotlinie, więc trochę się pomylił, ale nie do końca.

Swoją drogą, niezłe odkopanie wątku sprzed 11 lat @scibi92 ;-)

1

No masz rację, ale jeszcze nie jest to aż tak popularne wszystko, choć FP staje się popularniejszy. Sam znalazłem temat szukając postów z "Clojure" xD

6

screenshot-20200123000821.png

And the winner is scibi92. Odgrzebanie wątku po 11 latach, szacun :D

0

@cerrato: po prostu zobaczyłem post o przyszłości Scalii/Clojure/Grooviego i po prostu nie mogłem się powstrzymać. Swoją drogą zabawnie czyta się pzewidywania sprzed 10 lat xD

1

Akurat Scala ma się (na razie) dobrze. W bardzo dużych korpo jest używana do analityki dużych danych. Z naszych ankiet wynika, że używa jej prawie tyle samo naszych klientów co używa Pythona. Spark najlepiej działa z poziomu Scali, a Spark stał sie de-facto standardem w BigData.

Z drugiej strony niestety Scala dużo straciła natomiast przez pofragmentowane community i pewną głośną grupkę, która chciała ze Scali zrobić drugiego Haskella na JVM strasząc ludzi, wbrew zamierzeniom twórcy, a twórcy z kolei zbyt rzadko mówili NIE. I zrobił się taki trochę mega-wielopardygmatowy potworek. Gdyby całe community położyło nacisk na poprawienie usability i tooling o kilka lat wcześniej, zamiast wymyślać akademickie cuda na kiju w samym języku i bibliotekach, to Kotlin nie byłby potrzebny. Scala nadal ma fajny potencjał, ale nie do końca jestem przekonany, czy pójdzie to w jakimś sensownym kierunku, czy nie padnie totalnie, bo IMHO próbują upiec zbyt wiele pieczeni na jednym ogniu. Pisałem chyba z 10 lat temu, że wydaje mi się przekombinowana i chyba miałem rację :)

IMHO Rust robi to znacznie lepiej. Wiadomo do czego jest. I robi to dobrze.

1 użytkowników online, w tym zalogowanych: 0, gości: 1