Autor Wątek: Kilka pytań dotyczących javy  (Przeczytany 10011 razy)

Offline JCoder

  • Użytkownik

# Wrzesień 02, 2010, 11:26:49
JavaME raczej zdycha. Ale za to Android ma się dobrze i pretenduje do najpopularniejszego OSa na rynku Smartphone'ów. Liczba sprzedanych telefonów z Androidem przekroczyła liczbę sprzedanych IPhone'ów w USA niedawno. Dlatego Java: tak, JavaME: zdecydowanie nie. Zresztą w ogóle JavaME to dla mnie od początku był niewypał. To co udało się Sunowi z desktopową Javą, kompletnie nie udało się w przypadku ME - producenci dostarczali niekompatybilne JVMy, z bugami, głupimi ograniczeniami. W ogóle programowanie telefonów to był straszny syf (nie ważne czy w ME, bo np. Symbian - syf jeszcze większy).

A o to że Oracle ubije Google'a za Dalvika, to bym się nie martwił. Raczej będzie ugoda i pewnie skończy się na tym, że zmuszą Googla do zapewnienia pełnej zgodności swojego toolchaina ze specyfikacją Javy, co tylko wyjdzie developerom na dobre.

@JasonVoorhees: przerostu formy nad treścią nie ma w Scali, która też działa na GoogleAppEngine i Androidzie. No i ma znacznie lepsze przeciążanie operatorów niż C++ (a zarazem o wiele prostsze koncepcyjnie), a o szablonach / genericsach już kiedyś dyskutowaliśmy (co kto lubi, ale uważam, że możliwości biblioteki standardowej Scali świadczą o sile właśnie genericsów i przemyślanego systemu typów - na pewno jest to jeden z najlepiej zaprojektowanych statycznych systemów typów, godny naśladowania).
« Ostatnia zmiana: Wrzesień 02, 2010, 11:33:09 wysłana przez JCoder »

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline vashpan

  • Użytkownik
    • Strona

# Wrzesień 02, 2010, 12:11:00
Android powinien miec przyszlosc, tylko czy ta przyszlosc bedzie dobra dla deweloperow i userow to w sumie niewiadomo :) To ze przescignal iPhone'a to raczej oczywiste i dziwne ze tak pozno, przeciez iPhone to jeden telefon, od jednego producenta, wiec nie rozumiem tej calej radosci Androidowcow :) Poza tym iOS i jego AppStore nie smiga tylko  na iPhonach, ale do tego trzeba doliczyc tez iPady i iPody touch... ( Na wczorajszej konferencji Apple cos wspominal ze do tej pory zarejestrowano ~120 mln urzadzen z iOS na pokladzie ) Do tego problemy z wersjami Androida - producenci robia sobie w zasadzie co chca, nie ma supportu na uaktualnienia do nowszych wersji od wielu producentow... Z iOS to w ogole nie jest problem - uaktualnienia sa dostepne dla wszystkich supportowanych urzadzen - od razu, lifecycle produktow jest w miare krotki - bolesne moze dla niektorych, ale powoduje ze platforma rozwija sie stabilnie, bez specjalnej koniecznosci "kompatybilnosci wstecznej" - Android moze przescignac iOS w ilosci, ale z jakoscia moze byc roznie. Dzis zobaczylem techdemo portu Unreal Engine 3 dla iOS ( kazdy moze sobie sciagnac za darmo i zobaczyc, ale potrzebuje OpenGL ES 2.0, a wiec >=3gen ) , wczesniej podobna prezentacje zrobil Carmack ze swoim Rage... Czy cos takiego w ogole moze zaistniec na Androidzie ?

Owszem istnieje NDK ( przeciez nie napisza UE3 od poczatku w Javie... ) ale nie bardzo rozumiem jak ma wygladac programowanie w tym, tam jest dostep do OpenGL, bibliotek systemowych ? Bo z tego co rozumiem, NDK sluzy do kompilowania bibliotek potrzebujacych wyciagnac maks ze sprzetu, a wiec np. silniki fizyczne, kodeki etc. Jak to z tym jest ?


Wracajac do tematu, czy warto uczyc sie Javy ? Oczywiscie ze warto, Java to najpopularniejszy jezyk programowania, z multum zastosowan w biznesie, w gamedevie o wiele mniejszy, ale warto go znac. Mi osobiscie Java nie przypada do gustu za bardzo ( po prostu sa IMO lepiej rozwiazane jezyki - np. C# ) ale jest dosc wygodna, ma doskonaly support i narzedzia. Jave po prostu wypada znac ;)
« Ostatnia zmiana: Wrzesień 02, 2010, 14:58:49 wysłana przez vashpan »

Offline Dab

  • Redaktor
    • blog

# Wrzesień 02, 2010, 13:21:31
Cytuj
Prawdę mówiąc jak kodzi się w grupie, to najlepiej, żeby nie było żadnych wskaźników, template'ów, a cały kod był wykonywany sekwencyjnie

I pod żadnym pozorem interakcji z użytkownikiem. Oni wszystko psują!

:D

Cytuj
aktualnienia sa dostepne dla wszystkich urzadzen - od razu

Nie do końca, iPhone 2G nie jest już supportowane przez iOS4.
iPhone 3G jest co prawda obsługiwany, ale bez paru istotnych zmian (np. "massive single-taskingu" ;) )
Dopiero 3GS i 4G mają pełną obsługę.

(w przypadku iPodów analogicznie)
« Ostatnia zmiana: Wrzesień 02, 2010, 13:23:20 wysłana przez Dab »

Offline vashpan

  • Użytkownik
    • Strona

# Wrzesień 02, 2010, 14:58:02
Cytuj
aktualnienia sa dostepne dla wszystkich urzadzen - od razu

Nie do końca, iPhone 2G nie jest już supportowane przez iOS4.
iPhone 3G jest co prawda obsługiwany, ale bez paru istotnych zmian (np. "massive single-taskingu" ;) )
Dopiero 3GS i 4G mają pełną obsługę.

(w przypadku iPodów analogicznie)

Wiedzialem ze tutaj niedokladnie sie wyrazilem ;) Ale napisalem pozniej ze lifecycle produktu jest dosc krotki, co implikuje brak supportu dla starszego sprzetu. To tez jest dobre - brak 'wiekszych' problemow z "wsteczna kompatybilnoscia" Np. pewnie za ~2 lata rozdzialka 480x320 odejdzie juz w iOS do lamusa...

Co do braku "massive single-taskingu" w urzadzeniach 2gen, mysle ze to dosc dobre posuniecie, w moim zjailbreakowanym ipodzie 2gen odblokowalem sobie multitasking i musze przyznac ze w sumie to dosc srednio to dziala ( choc dziala ) Za to nie bardzo rozumiem czemu zablokowali tez tapety ;) ( wystarczy wyrzucic cienie spod ikon i smiga wszystko normalnie ) a co gorsza takie dosc pozyteczne funkcje jak blokada orientacji czy dostep do odtwarzacza muzyki ( co siedzi w nowym taskbarze; bez odblokowania multitaskingu jakos specjalnie nie znalazlem opcji by to miec )

No ale to nie forum o urzadzeniach Apple'a ;)
« Ostatnia zmiana: Wrzesień 02, 2010, 15:00:02 wysłana przez vashpan »

Offline JCoder

  • Użytkownik

# Wrzesień 02, 2010, 17:09:23
Cytuj
Cytuj
Prawdę mówiąc jak kodzi się w grupie, to najlepiej, żeby nie było żadnych wskaźników, template'ów, a cały kod był wykonywany sekwencyjnie

I pod żadnym pozorem interakcji z użytkownikiem. Oni wszystko psują!

Eee tam od razu psują. Błędy są w każdym sofcie (z wyjątkiem TeXa i HelloWorld).

Jednak błędy różnią się kalibrem. Są takie, które się poprawia 5 minut i takie na które potrzeba tygodnia. Lepiej mieć dużo tych na 5 minut niż tych na tydzień, zwłaszcza że w przypadku tych drugich w ogóle ciężko cokolwiek powiedzieć o terminie ich poprawienia. Mechanizmy, które uniemożliwiają błędy tego drugiego rodzaju, to duża zaleta, właśnie w dużym projekcie zespołowym, gdzie jest deadline i gdzie niespodzianki się nie powinny zdarzać. W językach, w których dopuszcza się, że każdy moduł może sobie niejawnie grzebać w prywatnych bebechach innego modułu, i nie ma twardej enkapsulacji, prawdopodobnieństwo walnięcia takiego trudnego błędu rośnie wykładniczo ze wzrostem wielkości projektu.
« Ostatnia zmiana: Wrzesień 02, 2010, 17:16:14 wysłana przez JCoder »

Offline Dab

  • Redaktor
    • blog

# Wrzesień 02, 2010, 17:15:38
Cytuj
W językach, w których dopuszcza się, że każdy moduł może sobie niejawnie grzebać w prywatnych bebechach innego modułu, i nie ma twardej enkapsulacji, prawdopodobnieństwo walnięcia takiego trudnego błędu rośnie wykładniczo ze wzrostem wielkości projektu.

A co ma do tego język? Pomijam już sensowność "problemu" (w gamedevie), ale równie dobrze możesz zrobić relację "każdy z każdym" w C++, Javie, Pythonie czy Brainfucku. Nie wiem jaki język by tu pomógł -- chyba tylko HQ9+ ma wystarczający poziom enkapsulacji :)

Offline JCoder

  • Użytkownik

# Wrzesień 02, 2010, 17:20:51
No właśnie ma bardzo dużo, bo język może dostarczać mechanizmy kontroli tego syfu, albo nie, oraz może promować pewien styl programowania, w którym ten syf zależności robi się łatwiej, albo i nie.

Offline Liosan

  • Redaktor

# Wrzesień 02, 2010, 17:24:42
W językach, w których dopuszcza się, że każdy moduł może sobie niejawnie grzebać w prywatnych bebechach innego modułu...

Właśnie, w Javie jest to wyjątkowo proste dzięki użyciu refleksji!
            Method getMethodResolverMethod = this.getClass().getSuperclass().
                    getDeclaredMethod("getMethodResolver", Object.class);
            getMethodResolverMethod.setAccessible(true);
::)

Liosan

Offline siso

  • Użytkownik

# Wrzesień 02, 2010, 17:28:04
Ale przecież każdy gentelmen wie, że używanie refleksji w ten sposób jest... nieeleganckie ;)

Offline JCoder

  • Użytkownik

# Wrzesień 02, 2010, 17:59:22
Takie coś w kodzie łapie się odpowiednim skryptem, a autora killuje, aby nie przeszkadzał innym kodować. :D

A nawet jeśli się prześliźnie to i tak ryzyko wprowadzenia w ten sposób trudnego do złapania błędu jest o wiele niższe niż np. wykonanie delete w złym momencie w C++. Programiści są leniwi. Dla 90% koderów Javy jakich miałem okazje egzaminować, używanie refleksji to czarna magia - nie wiedzą jak używać, bo nie potrzebują. Refleksja jest potrzebna do pisania frameworków, więc spokojnie można jej zabronić w projekcie całkowicie i problem z głowy.

Z kolei w C++ jest na odwrót: 90% programistów nie wie jak **nie** używać wskaźników. Zabroń zespołowi całkowicie wskaźników, dynamicznej alokacji, rzutowania, dostępu do tablic i paru innych rzeczy, które w sposób niejawny potrafią doprowadzić do naruszenia systemu typów, i powiedz czy będą Cię lubić.
« Ostatnia zmiana: Wrzesień 02, 2010, 18:07:06 wysłana przez JCoder »

Offline Dab

  • Redaktor
    • blog

# Wrzesień 02, 2010, 18:11:53
Cytuj
Dla 90% koderów Javy jakich miałem okazje egzaminować, używanie refleksji to czarna magia

To faktycznie wybitnych programistów miałeś okazję egzaminować :)

Offline Liosan

  • Redaktor

# Wrzesień 02, 2010, 18:14:21
Cytuj
Dla 90% koderów Javy jakich miałem okazje egzaminować, używanie refleksji to czarna magia

To faktycznie wybitnych programistów miałeś okazję egzaminować :)
Ta, bo w C++ to każdy egzaminowany zna standard na wyrywki... :D

Liosan

Offline Dab

  • Redaktor
    • blog

# Wrzesień 02, 2010, 18:16:40
Ci którzy nie znają pracują jako programiści Javy ;)

Offline JCoder

  • Użytkownik

# Wrzesień 02, 2010, 20:01:46
Oj, zdziwiłbyś się. Akurat na programistę C++ też miałem okazję rekrutować i było b. podobnie.
Zresztą poziom projektów studenckich pisanych w C++ sam mówi za siebie.

Chcesz jakiś kawałek kodu, by się popastwić?
« Ostatnia zmiana: Wrzesień 02, 2010, 20:03:33 wysłana przez JCoder »

Offline siso

  • Użytkownik

# Wrzesień 02, 2010, 20:22:37
@Dab
Javowy świat wcale nie musi nagminnie używać refleksji, by dobrze radzić sobie z typowymi problemami. Nietypowe faktycznie rozwiązuje się czasami nietypowymi metodami. Gdy trzymasz się zasad OOP i używasz narzędzi w sposób właściwy, refleksja jest postrzegana jako błąd projektowy. Po co miałbyś grzebać w bebechach, hę? To dlatego w większości programiści Javy nie muszą się w tym babrać i często nie znają tego tematu.

Gdy natomiast zaistnieje konieczność jej użycia, bo już nie ma innego wyjścia, każdy jest w stanie szybko się tego nauczyć, bo, jak wszystko inne, także i to jest w Javie dziecinnie proste.
Java to ekstremalnie prosty język. To stanowi wprost o jego sile.