System MeeGo był ciekawą koncepcją. Z jednej strony intuicyjna obsługa chwalona przez każdego recenzenta który miał okazję testować Nokię N9. Z drugiej całkowity brak szans na długofalowy sukces z uwagi na brak wsparcia wśród programistów oraz ekosystemu usług. Rok temu wydawało się że system zostanie zapomniany. Nic bardziej mylnego. Prawdopodobnie trafi on na setki milionów telefonów.
Pierwszym problemem MeeGo był brak społeczności deweloperskiej. Google projektując swój system od początku założyło że wykorzysta do jego promocji silną społeczność skupioną wokół języka Java oraz rewelacyjne narzędzia Eclipse. Microsoft ma miliony programistów znających technologie .NET oraz C# nie wspominając już o doskonałych narzędziach programistycznych z pakietu Visual Studio. Apple także ma niezliczone zastępy programistów. w końcu stworzyło cały nowoczesny rynek smartfonów i ciągle gwarantuje największe zyski dla twórców aplikacji. Nokia w przypadku MeeGo nie mogła liczyć na równie duże wsparcie. Zasadniczo nie bardzo wiadomo kto miałby pisać pod ten system aplikacje.
Drugim równie ważnym problemem był brak ekosystemu usług. Google, Microsoft i Apple mają dziesiątki usług które integrują ze swoimi systemami, integrują nawet całe systemy na różnych urządzeniach. MeeGo nie miało szans na własny ekosystem. Google ma swoje konto internetowe które skupia dziesiątki usług takich jak GMail, GDocs, Picasa, Search, Maps itd. Microsoft stara się zbudować jeszcze większy ekosystem bo oprócz odpowiedników praktycznie wszystkich usług Google pojawia się rewelacyjny SkyDrive (dysk 25GB), dziesiątki usług biznesowych oraz zapowiadana jest pełna integracja systemu Windows 8 z jego odpowiednikiem mobilnym oraz konsolą do gier XBOX. Także Apple nie ma się czego wstydzić, w końcu iTunes z roku na rok wzbogaca się o coraz większą liczbę funkcji. Apple stara się także zintegrować wszystkie swoje urządzenia razem MacOSX, iOS, AppleTV.
Nokia wiedziała że nie jest w stanie konkurować z trójką wielkich firm przy pomocy MeeGo. Każdy z konkurentów posiada nieograniczone wręcz środki finansowe oraz spójny plan rozwoju swoich systemów na kolejne 5-10 lat. Nawet jeżeli byłaby w stanie zabłysnąć czymś w jednej bitwie i skupić na sobie chwilową uwagę to nie miałaby szans na wygranie całej wojny. Dobry system na telefon pozbawiony wsparcia deweloperów oraz bez własnego wielkiego ekosystemu to za mało. Dlatego na swoich smartfonach zdecydowała się wykorzystać system Windows Phone.
MeeGo jednak nie zostanie zapomniany. Nokia znalazła dla niego idealne zastosowanie. Rynek na którym ważniejsza jest wygodna obsługa oraz zintegrowane możliwości niż wielkie ekosystemy z milionami programistów. Zgodnie z przeciekami MeeGo trafi do projektu „kolejny miliard telefonów”. Co to za projekt? To projekt w ramach którego Nokia tworzy tanie telefony Asha kosztujące poniżej 100 dolarów. Telefony te mają za zadanie być tańszym odpowiednikiem smartfonów. Pozwalać na wykonanie wszystkich typowych czynności takich jak przeglądanie internetu, komunikacja, dostęp do sieci społecznościowych, obsługa multimediów, nawigacja itp. Zasadniczo wszystko to co realizuje smartfon za wyjątkiem dostępu do setek tysięcy aplikacji dodatkowych. To rynek na którym MeeGo może naprawdę zabłysnąć. Co więcej zdobyć sporą popularność. Nie bez powodu projekt ten nazywa się „następny miliard”. Niska cena poniżej 100 dolarów spowoduje że telefony MeeGo mogą stać się szybko bardzo popularne. W końcu nie każdy w telefonie potrzebuje 100 dodatkowych aplikacji.
Zgodnie z przeciekami aktualnie projektowane są dwa tanie modele z MeeGo. Na wrzesień Nokia zapowiedziała konferencję Nokia World wiec pewnie już za niecałe 6 miesięcy dowiemy się jaka przyszłość czeka MeeGo.
To MeeGo jeszcze żyje?
Wg Elopa, ceo-okupanta Nokii z ramienia microsoftu, Maemo/MeeGo i N900 to były "pomyłki, które już nigdy nie powinny się powtórzyć".
A sprzedaż Lumii w Polsce okazała się podobną klapą jak na zachodzie. Czy Nokia niedługo na prawdę pójdzie z torbami i zostaną z niej tylko patenty, które wraz z firmą za bezcen wykupi microsoft?
"A sprzedaż Lumii w Polsce okazała się podobną klapą jak na zachodzie."
jakie jest źródło tej informacji ?
a ktoś znajomy wybrał nokie z Windowsem? Ja nie znam nikogo
Ja pytam o jakieś statystyki sprzedaży – wg. mnie a wcześnie oceniać czy windowsowe telefony chwycą – dopiero teraz mamy jakąś tam ofertę u operatorów z tymi telefonami.
Ja znam, nawet dwoch. Jeden z nich sprzedal telefon dnia nastepnego ze wzgledu na brak mozliwosci przesylania plikow po bluetooth, drugi jeszcze walczy ;P
Ogolnie, WP w Nokiach dziala calkiem sprawnie, ale ograniczenia samego systemu potrafia momentami dobic.
Kiedyś znajomy kupił telefon z Androidem. To była dopiero masakra.
Przyszedł do pracy i nam się chwali. No a akurat była ta afera ze telefony z Androidem wysyłają SMS-y pod losowe numery. Więc chłopaka podpuściliśmy. Mówimy mu żeby wysłał 5 razy SMS na jeden z naszych telefonów. Co się okazało? Doszły tylko 4. Telefon pokazywał że wysłał 5 SMS-ów ale jeden z nich wysłał pod losowy numer z książki adresowej. Znajomy już nigdy więcej nie chwalił się swoim nowym telefonem. Żartowaliśmy sobie z jego telefonu przez kolejnych kilka miesięcy. Bo jak na złość jego operator nie udostępniał aktualizacji z poprawką 🙂
Androida się rootuje, myślałem że to oczywiste.
…tworząc sobie kolejne problemy, jak z każdym niewspieranym oprogramowaniem. Dziękuję, postoję – płacę to wymagam.
… płacisz i dostajesz buble: "operator nie udostępniał aktualizacji z poprawką". Instalowanie oprogramowania tworzonego przez społeczność (np. CM) jest w takim wypadku naturalnym odruchem.
Dla mnie bardziej oczywiste jest wybranie innej platformy… (sprzedałem swoją pierwszą i ostatnią komórkę z Androidem po 3 miesiącach używania, od pół roku mam iPhone'a 4).
Na czym to wsparcie ze strony Apple, jako producenta oprogramowania dla ciebie jako użytkownika polega? Masz może jakiś kontrakt, albo gwarantowany poziom usług, lub przynajmniej przebrnąłeś przez zapisy licencji określające co Apple ci gwarantuje?
Gdybym miał telefon z Androidem wyprodukowany w tym samym czasie, to już niedługo przestałby otrzymywać jakiekolwiek update'y, a te, które bym w ogóle otrzymywał, docierałyby ze znacznym opóźnieniem. Każda wersja iOS za to dociera na mój telefon w dzień premiery. Nie potrzebuję "gwarantowanego poziomu usług", by dostrzegać takie rzeczy…
A co to ma wspólnego ze wsparciem, w sensie funkcjonalnym? Fakt dostarczania nowych wersji OS dla starych urządzeń jest gadżetem, który ciebie przekonał od strony marketingowej. To nie ma zbyt dużo wspólnego z analizą funkcjonalności i niewiele ze wsparciem, za to na pewno daje _poczucie_ bezpieczeństwa i dbałości ze strony producenta.
I to mu wystarcza – to poczucie, bo nigdy do poczucie nie zostalo zawiedzione najwyrazniej. Wie ze jego telefon bedzie dzialal przez lata o ile mu nie spadnie na ziemie. Wie, ze jesli wyjdzie problem ze sms'y sie wysylaja na losowe numery, to dostanie aktualizacje.
/zeby nie bylo, mam nokie na symbianie – dopoki nie zdechnie to nie zmieniam, zywcem nie ma co kupic/
Jesteś pierwszą osobą, od jakiej słyszę, że dostarczanie nowych wersji OS-u na starsze urządzenia to "gadżet" i zagrania marketingowe. 🙂
Kolega pitt66 już odpowiedział w zasadzie na Twe pytania. Ale jeśli chodzi o konkrety, to rok po wyprodukowaniu telefonu przyszedł iOS 5.0, a z nim m.in. iCloud, system powiadomień lepszy niż w Androidzie (przynajmniej 2.3, "czwórki" na żywo nie widziałem – ale i większość właścicieli telefonów z Androidem jej długo nie zobaczy, o ile w ogóle), inkrementacyjne aktualizacje over-the-air itd. Plus mnóstwo drobiazgów upraszczających życie, jak aparat fotograficzny dostępny bezpośrednio z ekranu blokady.
Oczywiście, że gadżet, bo w przypadku apple nowe funkcje systemu na starym telefonie i tak najczęściej nie są włączane, więc czasem nie opłaca się aktualizować, bo system wolniej działa, a nie oferuje nic nowego.
Najczesciej? No to podaj z piec takich funkcji ktore nie byly uruchamiane na starszym sprzecie z powodow innych niz fizyczne ograniczenia (np brak kamery w ipad1).
Gruba przesada. Z bardzo nielicznymi wyjątkami (I'm looking at you, Siri) Apple nie backportuje tylko tych funkcji, które są zbyt zaawansowane na hardware urządzenia (jak multi-tasking w iPhonie 3G, Game Center na starych urządzeniach itp.).
Zabawne, że piszesz o niewłączaniu nowych funkcji na starych urządzeniach akurat w odpowiedzi na post, w którym parę takich istotnych funkcji Ci podaję!
iIOS 5, który przyniósł problemy z caldav, z baterią, z niemożnością odebrania połączeń w niektórych przypadkach. To tylko te, których doświadczyłem osobiście. Do tej pory kontakty można wysyłać tylko jako MMS, a nie SMS, co powoduje problemy u niektórych odbiorców. Taka lub inna forma powiadomień to naprawdę gadżet. Z punktu widzenia analizy funkcjonalnej w momencie decyzji o zakupie, aktualizacje oferowane przez apple to naprawdę gadżet.
@m_gol: być może w twoim otoczeniu nie ma osób odpowiedzialnych za zakupy dla firm, albo nie robią one analiz :). W perspektywie 1/2 roku naprawdę ciężko znaleźć jakiekolwiek argumenty na rzecz zakupu komórek apple do firmy, w porównaniu do rozwiązań opartych na androidzie i być może na windowsie.
Osobiście nie zauważyłem problemów z baterią. Ale też nie włączam powiadomień we wszystkich możliwych aplikacjach, bo to oczywiste, że to będzie jeździć po baterii.
Jakie problemy z CalDAV? Jakie problemy z niemożnością odebrania połączeń? Pytam z ciekawości.
Wizytówki wysyłane SMS-ami są okrojone, ucinają wiele istotnych informacji. Osobiście byłbym szczęśliwszy, gdyby żadna komórka takich nie pozwalała wysłać, bo nawet gdyby mój iPhone je odczytał, to i tak nie byłoby tam tego, o co mi chodzi. I tak, doświadczyłem tego osobiście.
Co do zakupów do firmy, to tam przecież nie ma aż takiego znaczenia, czy ma się aktualną wersję oprogramowania. Aktualizacje to strach na wróble dla korporacji. 😉 Ja mówię z perspektywy użytkownika końcowego.
Na 5.0 nagle przestał czytać kalendarz – nie pamiętam, czy musiałem coś zrobić na serwerze, czy 5.01 rozwiązało problem. Z połączeniami jest tak, że ktoś dzwoni i nie można w żaden sposób odebrać połączenia przesuwając suwak; natychmiast po tym jak ktoś przestaje dzwonić można telefon odblokować i oddzwonić. Co do kontaktów: za pomocą sms do się obsłużyć wystarczającą część standardu carddav ( jak dla mnie – wolę mieć mniej, niż nie mieć nic).
Myślę, że dotarliśmy do wspólnej konkluzji: Dla zastosowań biznesowych aktualizacje to gadżet ( nie są niezbędne, ani nawet podstawowe o ile urządzenie funkcjonuje poprawnie), dla użytkownika końcowego to coś co daje sporo radości, jak większość fajnych gadżetów. 🙂
No tak, chyba się zgadzamy. Dodam jeszcze, że w korporacyjnym środowisku ważna może być możliwość instalacji własnych aplikacji bez zewnętrznej kontroli, co wyklucza iOS. No i fragmentacja systemu nie ma tam takiego znaczenia, bo do firmy kupuje się i tak maksymalnie kilka modeli, a resztą się nie trzeba przejmować.
Nokia cały czas jest jednym z gigantów rynku mobilnego i chociażbyś skakał i płakał, to nie zbankrutuje, bo nie wychodzi jej na rynku najdroższych urządzeń. Sprzedają od groma tańszych telefonów, na których nie zarabia się może aż takich dużych kwot, ale to zawsze pieniądz. Są też inne działy, które zajmują się szeroko pojętą telekomunikacją… Krótko mówiąc – skończ waść, bo głupoty prawisz.
Ja wcale nie chcę, by zbankrutowała.
Tyle, że od 2 lat mogła zarabiać krocie na Androidzie i może nawet równać się z Samsungiem.
A dzięki okupacji microsoftu jest w szarej dupie i może co najwyżej produkować te tanie telefony, a z drogich sprzedaje z wielkim opóźnieniem wielki bubel z badziewnym windowsem, za którego jeszcze płaci microsoftowi! Chociaż "sprzedaje" to niewłaściwe słowo, bo pomimo agresywnej kampanii reklamowej i tak nikt tego nie chce.
Do tego ubicie przez Elopa takich dobrych telefonów jak N900, który prawie bez reklamy sprzedawał się w większych ilościach niż Lumia. I to ubicie słowami pokazującymi dobitnie jaki jedyny właściwy kierunek teraz ma obrać Nokia i jak Elop traktuje osiągnięcia tej firmy.
Pomijając Twoje brednie o "okupacji Microsoftu" Nokia weszła na ścieżkę innych producentów telefonów (np. Siemensa) na długo, zanim Apple wypuściło pierwszego iPhone'a a Microsoft traktował inne systemy niż desktopowe jako eksperyment.
Apple, Samsung i HTC zrobiły ze starą ligą (Motorolą, Siemensem, Alcatelem) to samo, co producenci elektroniki lotniczej kilkadziesiąt lat wcześniej zrobili z producentami elektroniki samochodowej – kiedy jedno nie różniło się od drugiego, stara gwardia olała nowy rynek. Rynek potem olał ich.
Symbian i S40 to co innego.
Co mają środowiska programistyczne do popularności platformy!?
Chodzi o ilość potencjalnych programistów. Dziś praktycznie każdy programista zna Javę, większość także zna C#. To dwa podstawowe języki. Dla takiego programisty nauczenie się kilku bibliotek i stworzenie aplikacji na telefon jest stosunkowo proste. Nie musi się on uczyć nowych narzędzi. Może on w poświęcając kilka dni wykorzystać posiadaną już wiedzę by napisać aplikację.
Dlatego Google wybrało Javę jako język programowania dla Androida zamiast przykładowo rozwijanego od lat języka 'Google Go'. Gdyby wybrano 'Go' lub inny język to prawdopodobnie nikomu nie chciałoby się go uczyć. Nie byłoby więc setek tysięcy aplikacji a same telefony sprzedawałyby się znacznie gorzej. Dlatego wybór Javy był tu kluczowy dla sukcesu Androida.
Java oraz C# mają aktualnie najlepsze narzędzia deweloperskie oraz zna je każdy.
Zna Javę i co? W Javie inaczej piszę się aplikację w środowiska EE, SE i JE i na Androida, praktycznie mógłbyś znać również tylko C++ i miałbyś takie same szanse na zrobienie dobrej aplikacji. 😉
Apple wybrało Objective-C i jakoś nie narzeka.
'Gdyby wybrano 'Go' lub inny język to prawdopodobnie nikomu nie chciałoby się go uczyć. Nie byłoby więc setek tysięcy aplikacji a same telefony sprzedawałyby się znacznie gorzej"
…czego przykładem jest np. iOS i Objective-C
Smiem twierdzic ze learning curve miedzy C a ObjC jest znacznie mniejszy niz do Go. Poza tym spora ilosc ludu znala ObjC z MacOsX, wiec zaplecze programistow z marszu wieksze. No i wreszcie w ObjC po prostu uzywasz kodu C ktorego masz od groma.
Z podobnych powodow Google wybralo Jave a nie jakies glupotki typu Go.
Gdyby to się opłacało to pewnie nauczyłbym się brainf*ka 🙂
Akurat Go powstał jako zastępca C/C++ a nie Javy, a Google nie mogło wybrać Go zanim nie powstał 🙂
Go ma tę zaletę, że się bardzo szybko kompiluje, choć sam nie jest tak wydajny jak C. Wygląda też, że Go ma częściowo zastąpić powolnego Pythona. Jak na razie język ten ma być wykorzystywany głównie wewnątrz firmy.
"Gdyby to się opłacało to pewnie nauczyłbym się brainf*ka 🙂 "
A zeby sie oplacalo, musi byc rynek / zapotrzebowanie.
"Akurat Go powstał jako zastępca C/C++ a nie Javy, a Google nie mogło wybrać Go zanim nie powstał :)"
Nigdzie nie napisalem, ze Go istnial lub nie, napisalem "glupotki typu Go".
"Go ma tę zaletę, że się bardzo szybko kompiluje"
Tak, tak, to zajebiscie wazna cecha. Na pewno wazniejsza niz
kompatybilnosc czy megatony dostepnych z marszu bibliotek w C.
"glupotki typu Go"
Dla Ciebie to głupotki, dla Google raczej nie. Chodzi o to że nie jest to zamiennik Javy, ale raczej C++ i Pythona. Język ten ma główne zastosowanie wewnątrz firmy.
"Tak, tak, to zajebiscie wazna cecha. Na pewno wazniejsza niz
kompatybilnosc czy megatony dostepnych z marszu bibliotek w C"
Niefortunnie sypnąłeś przykładem Google we wcześniejszym poście. Gdybyś odnosił się do każdego programisty spoza Googla to ma 100% racji. Jednak w tym przypadku niekoniecznie. Twórcy Go chcieli wyeliminować długotrwałą kompilację. Zdajesz sobie chyba sprawę ile czasu zajmuje ponowne skompilowanie większego kodu. Pracownicy Google narzekali że muszą czekać ponad pół godziny na kompilację, a czasami należało wprowadzić tylko niewielką poprawkę i samo kompilowanie trwało dłużej niż poprawianie kodu. Nie zawsze da się stosować kompilację przyrostową. Kompatybilność z bibliotekami zapewnia się wraperem i nie jest najważniejsza, bo korzystają z niewielkiej ich ilości.
"Gdybyś odnosił się do każdego programisty spoza Googla to ma 100% racji."
Ciesze sie, ze wreszcie zaczynasz dostrzegac o czym w ogole mowie.
Przypominam, mowie O PROGRAMOWANIU W ANDROIDZIE, a konkretniej,
odnioslem sie do:
"'Gdyby wybrano 'Go' lub inny język to prawdopodobnie nikomu nie chciałoby się go uczyć. Nie byłoby więc setek tysięcy aplikacji a same telefony sprzedawałyby się znacznie gorzej"
…czego przykładem jest np. iOS i Objective-C "
Nie wiem wiec, po co mi tu wyjezdzasz z tym po co i dlaczego wewnatrz google
jest uzywane Go skoro w ogole o tym nie mowilem?
"Z podobnych powodow Google wybralo Jave a nie jakies glupotki typu Go. "
Z Twojej wypowiedzi nie wynika, że piszesz tylko o Androidzie, z kontekstu już tak, moja wina.
Natomiast z wypowiedzi mogłoby wynikać, że Google mógł się zdecydować na Go, a przecież ten język wtedy nie istniał. Po drugie nazywanie języka Go "głupotką" ma się nijak ze znaczeniem tego języka dla Google.
Odnoszę wrażenie, że cały Twój post jest nie o programistach, a o "klepaczach kodu"…
Rozwiniesz ?
Tak samo PALM gadało o HTML/JS
Wiele akapitów tego artykułu wygląda jak tłumaczenie lutowego Elop Memo… nie wiem nawet dlaczego taka droga została wybrana bo artykuł miał o być chyba o meltemi.
Brak programistów C++/Qt/QtWebKit/Quick to ryzykowne założenie nie poparte szacunkami nawet. Ostanio o WinPhone czytałem od samego MS, że programistów mają więcej niż aplikacji… Angry Birds zostały w końcu "wyproszone na klęczkach" bo przepisywać niemal od zera trzeba było na wspaniały język którego nikt na komórce wcześniej nie uzywał – wszystko – włącznie z biblioteką fizyki box2d…
Wiadomo z http://www.tiobe.com/index.php/content/paperinfo/… choćby (lepsze źródło niż gdybanie) że C++ jest ponad 2x bardziej 'popularny'
niż podobno wszechobecny javascript. Ten ostatni zresztą może być stosowany z QtWebKit, Qt i Quick. Qt jest na większej liczbie urządzeń niż – to daje opłacalność programistom którzy rozwarzają i pozwala szacować wielkość ekosystemu. Jak spojrzy się na rozdział ECOSYSTEMS na nowej analizie Ahonena, który niedawno przebił się do mediów kolorowych krytyką Elopa, zobaczyć można liczbę 1.4 MLD urządzeń obsługujących Qt. Masa ich to Symbiany, które dostały aktualizację. Nietrudno się domyśleć dlaczego tak w aktualizację zainwestowano nawet dla starszych modeli: jeden ekosystem dla twórców…
Liczba ta się bierze stąd, że o urządzeń obsługujących Qt out of the box należy wliczyć urządzenia androidowe (z wyjątkiem low-endowych smartfonów gdzie i tak trudno wbudowaną przeglądarkę używać).
Jeśli nie wliczać Androida to roczny przyrost liczby urządzeń tylko od Nokii to 450 MLN (a iPhone z 200-250 MLN).
http://communities-dominate.blogs.com/brands/2012…
Brak ekosystemu usług? MS nie ma przecież map nie ma i je od Nokii pożyczył (tylko na Lumie – w komórkach LG przecież się ich nie dostanie), ostatnio zaś sięga po openstreetmap nie dla miłości do open source tylko by walczyć z google m.in. o niezależność a w dłuższej perspektywie o rynek reklam (w OSM przecież mozna wtłaczać reklamy bez opłat za mapy).
Do tego Ovi ma muzykę. Były elektroniczne płatności ale Nokia się tego pozbyła w tym roku (to jest niezrozumiałe póki co).
"Za niecałe 6 miesięcy dowiemy się jaka przyszłość czeka MeeGo" – maemo, nie meego.
"że C++ jest ponad 2x bardziej 'popularny'
niż podobno wszechobecny javascript."
I tu widać jak nie do końca wiarygodny jest indeks Tiobe. Być może tylu jest programistów dla których jest to język podstawowy, ale raczej znacznie więcej jest ludzi którzy go znają i używają na co dzień jako drugi z języków.
Można zauważyć, że ilość chętnych do pisania w C++ ciągle spada. Większość jeśli ma możliwość wybierze szybszy w pisaniu język Java niż C++. Jedynie możliwość dobrych zarobków może przeważyć przy wyborze tak jak dzieje się to w przypadku Objective-C.
Osobiście chętnie zobaczyłbym telefony z MeGoo, może bym sobie kupił, a może nawet coś bym tam napisał 🙂
Wydaje mi się, że Java była na takiej samej straconej pozycji jak C++. Jednak rynek mobilny przywraca Javę i C/C++ do świetności. Java na desktopach żyje chyba tylko u użytkowników Minecrafta i Eclipse.
W dużych firmach na desktopach znajdziesz znacznie więcej Javy, dla masowego odbiorcy lepiej sprawdzają się kompilowane języki. Jeśli dwa programy mają podobne funkcje,ale jeden z nich zużywa więcej zasobów to wybór chyba jest oczywisty. Inaczej wygląda sprawa bardziej rozbudowanych programów których napisanie w języku kompilowanym jest zbyt pracochłonne i raczej się nie zwróci.
Pytanie kto płaci za sprzęt do obsłużenia tego.
Jeśli taniej kupić lepszy serwer albo dołożyć drugi, niż optymalizować oprogramowanie, to ok. Chociaż jak ma się dobrych programistów, to w C++ też można wydajnie i tanio utrzymywać kod.
Ale użytkownikowi na desktopie raczej nie powinno się mówić, żeby kupił sobie lepszy komputer i więcej ramu, bo "dzisiaj dual core 2.0 GHz i 2 GB ramu to już za mało" (do odpalenia nieskomplikowanej aplikacji desktopowej w Javie).
Tak samo .net na desktopie to nieporozumienie. Wolny start, wolne działanie i zasobożerność. I rozwiązanie tłuków z microsoftu: wszechobecny preload w windows, który zapycha ram. Trochę za mało ramu, preload wysiada i nagle "szybkość" .neta ukazuje się oczom użytkownika w całej okazałości.
Dual core 2.0 GHz i 2GB RAMu to za mało aby płynnie chodził Windows 7 i *natywne aplikacje*. Problemem nie jest język programowania, a podejście programistów i firm, którym zwyczajnie nie chce się pisać wydajnego softu. Ot, taki developer ma mocną maszynę, to u niego byle gównianie napisany soft będzie chodził szybko.
Mój soft w Javie chodzi jakoś płynnie na kilku-letnich kompach. A jak dla kogoś JVM jest problemem, może Javę sobie natywnie skompilować, nikt mu nie broni. Excelsiors JET produkuje tak samo wydajny kod *natywny* Javy jak GCC czy VS dla C++.
Natywne aplikacje w Windows 7 to w większości .net. Stąd też i "szybkość" ich działania oraz działania całego tego systemu 🙂
Nie zrozumiałeś. Nie chodzi o to, czy .NET, czy Java, czy C++. Chodzi o to, że programiści leją na wydajność i zajętość pamięci. Nie powiesz mi, że jądro Windowsa i usługi systemowe są napisane w .NET. A goły Windows zjada kilkaset MB RAMu na dzień dobry, jeszcze zanim się odpali jakąkolwiek aplikację kliencką. Większość tego kodu jest w C i C++.
Wcale temu nie zaprzeczam. Dzisiaj utarło się takie podejście, że zawsze można dołożyć RAMu, poza tym i tak jest go dużo, więc po co ma się marnować. Głupie i durne, ale niestety powszechnie stosowane.
Jeśli to jest na serwerze, to ok, bo i za platformę i za aplikację płaci ta sama osoba, więc niech sobie sama wyliczy czy bardziej opłaca się mieć zoptymalizowaną aplikację na tańszym sprzęcie, czy aplikację stworzoną na szybko na drogim sprzęcie.
Ale jeśli soft trafia do userów to powinien być zawsze optymalny. Bo tu nie producent płaci za sprzęt.
Świetnym przykładem mogą być nowe gry. Żeby odpalić je na nieco starszym sprzęcie trzeba ustawić niskie detale i wtedy grafika wygląda znacznie gorzej niż w starszych grach. Przy czym ta nowa gra na niskich detalach wyrabia 20-30 fps, a te stare śmigały na 60 fps. Wniosek: regresja w wydajności.
DirectX 8 był szybki (to chyba najlepsza wersja tej biblioteki), 9 już znacznie wolniejszy, a 10 i 11 to powolne katastrofy programistyczne.
Oczywiście jak się wymieni kartę graficzną to wszystko da się uciągnąć. Tylko trzeba za ten sprzęt zapłacić. I płaci użytkownik, a producent gry ma to w czterech literach.
Chociaż raz się za tobą wstawię 🙂
Sublime Text 2 – Bardzo fajny wydajny edytor dla programistów napisany w OpenGL/C++ z plugin-ami w Pythonie. Zajętość RAM-u 12 MB
Arduino IDE – Środowisko do programowania płytek Arduino oparte na prostym, spartańskim edytorze napisane w Javie. Zajętość RAM-u 50 MB
Osobiście nie jestem zwolennikiem zmuszania programistów do pisania niezwykle zoptymalizowanych rozwiązań (bo potem nikt tego kodu nie rozumie). Jak dla mnie programowanie ma być proste i wydajne, a programista musi to robić poprawnie.
W końcu GG było pisane tyle lat w Qt i co? Teraz jest podobno w XUL. Może następne napiszą w Javie ;-).
Istotne jest raczej to że np. Sublime jest komercyjny (mam używam i polecam) to najlepszy edytor na Linuksa bo JEST PŁATNY!
Czekam z utęsknieniem aż doczekamy się komercyjnego rynku oprogramowania z prawdziwego zdarzenia na Linuksie (na razie jedynym marketem na klik jest chyba Centrum Oprogramowania w Ubuntu)
To samo można powiedzieć o Visual Basicu i Delphi :>
Ostatnio byłem w sklepie z tonerami do drukarek i gościu mi fakturę wystawił za pomocą… aplikacji desktopowej napisanej w Swingu (Java).
Co do dostępności programistów C++, to się nie zgodzę. Na pewno dużo trudniej znaleźć dobrych programistów C++ niż dobrych programistów Javy, ale jednak kilku dobrych ceplusplusowców znam, więc tacy na pewno w przyrodzie występują 😉
Java na desktop się nie nadaje, tak samo jak .net.
Pozostaje praktycznie wyłącznie C++ z jakąś porządną biblioteką, np. Qt.
Qt ma przecież podobne wymagania co Java. Podstawowa prosta aplikacja z jednym okienkiem na starcie wciąga ponad 20 MB, to tyle samo co JVM ze Swingiem. QtCreator napisany zapewne w Qt wciąga na starcie niewiele mniej niż co lżejsze IDE Javowe (po wyłączeniu funkcjonalności, której QtCreator i tak nie ma).
A, no dość często zdarzają się wycieki pamięci: http://qt-project.org/forums/viewthread/9084
A jeśli nie wycieki pamięci, to notorycznie aplikacje w Qt nie oddają zwolnionej pamięci do systemu, w przeciwieństwie do Javy: http://stackoverflow.com/questions/848169/memory-…
W Gnome większość aplikacji jest w C, pojawił się też nowy język Vala. C++ nie jest więc jedynym wydajnym rozwiązaniem.
"Vala's memory management is based on automatic reference counting instead of tracing garbage collection."
A już myślałem, że goście zrobili coś fajnego a tu zonk. Wybrali najłatwiejsze, ale najgorsze z możliwych rozwiązań.
Jakby zrobili z GC to lepiej byłoby wziąć od razu Javę lub .NET
Nie, myślałem raczej, że zrobią coś real-time opartego np. na regionach.
Albo jeśli GC, to coś ala Javowe G1 lub Azulowe C4.
O Pythonie nikt nie pamięta? Jak się ma do zasobożerności?
python jest powolny. Java w porównaniu do niego to istna rakieta.
Do obliczeń – być może.
Na desktop – ani trochę.
PyQt jest prawie tak szybkie jak natywne Qt na C++ i zostawia daleko w tyle GUI tworzone w Javie czy .net.
Tiaa, bo w Javie to nie można robić GUI w Qt. Jedyna zaleta Pythona, że się nieco szybciej uruchamia, no jej, pół sekundy szybciej niż Java. Ale jak aplikacja ma cokolwiek nietrywialnego robić, to Python jest wielokrotnie powolniejszy.
Python ma biblioteki w c/c++ i je laduje, wiec newralgiczne elementy maja wydajnosc c++.
wiem bo pisze w pythonie od dlugiego czasu, python + sdl ma identyczna wydajnosc jak sdl + c++.
poczytaj troche zanim zaczniesz sie wymadrzac
A sama logika aplikacji nie spowalnia jej działania przez użycie niezbyt szybkiego języka?
Dla typowych aplikacji z GUI Python jest OK, bo i tak najwięcej czasu spędzają one czekając na reakcję użytkownika. Gorzej gdy mamy do wykonania jakieś większe obliczenia.
zgadza sie, najwolniejszym elementem komputera jest czlowiek i jego reakcja.
swojego czasu kilka gier 2d napisalem w pythonie + sdl, wszystko ładnie i szybko chodzi. pisanie kodu tez dlugo nie trwa, wiec dlaczego wymyslac kolo od nowa i pisac wszystko w c++ skoro tutaj mam wszystko jak trzeba, kilka obliczen wykona sie tez w takim tempie, ze czlowiek nie zauwazy. swoja droga, logika mowisz, jesli biblioteka sama liczy "sobie logike" to jest super szybko, wszystkie wolne fragmenty zrzucamy na c++ lub piszemy wstawki w c++ no nie mow mi ze "print" w konsoli[terminalu] wymaga mega mocy obliczeniowych, czy otworzenie/zapisanie pliku.
wszystko zalezy co piszemy i co jest wazne, jesli liczy sie kazdy FLOPS to dlaczego nie uzyjecie assemblera? jest najwydajniejszy przeciez.
w pythonie kazde waskie gardlo mozna zniwelowac do gardla ktore by w tym samym zastosowaniu dalo c++ [a c++ podobno jeden z najszybszych] wiec nie wiem skad placz i lament ze "slimaczny"
Skoro mowa o wstawkach w C++ to łączenie dwóch języków nie jest prostą sprawą, szczególnie w większym projekcie, chociaż da się.
Są tacy co robią wstawki z assemblera gdy zachodzi konieczność. Wybiera się zawsze takie rozwiązanie które jest w danej sytuacji wystarczające. Przykładowo program MyPaint z GUI napisanym w Pythonie chodzi tak samo jakby był napisany w natywnym języku, ale Minecraft byłby raczej zbyt wolny 🙂
Gdyby Python jest wystarczająco szybki to po co powstał Cython? 😉
Cython czy Cpython?
python sie ciagle rozwija, probuja wycisnac z niego JESZCZE wiecej, z samego pythona [nie z wstawek c++] bo da sie przyspieszyc.
a skoro sie da, jezyk jest fajny, latwy i super przejrzysty, to dlaczego nie pokombinowac nad przyspieszeniem?
Tak Cython, a nie CPython, ciekawy projekt, wykorzystywany chyba głównie do obliczeń naukowych.
Osobiście nie przepadam za językami dynamicznymi. A co do szybkości to patrząc na wydajność JavaScriptu z V8 to pewnie Pythona dałoby się przyspieszyć jeszcze z 10 razy. Nie wiem dlaczego jeszcze Google tego nie zrobiło, byłoby to dla nich opłacalne i nawet przecież zatrudnili twórce Pythona. Może jeszcze coś z tego wyniknie.
To dokładnie to samo co Java: Java ma niektóre biblioteki w C/C++ i je ładuje, więc newralgiczne elementy mają wydajność C++. Jeśli mówimy o Qt czy SWT, to właśnie tak to jest zrobione.
To podejście może działać tylko do takich rzeczy jak np. toolkit do okienek (Qt, SWT), gdzie wywołania są rzadkie, a kod natywny ma dużo do roboty. Natomiast do podstawowych elementów języka, takich jak np. kolekcje standardowe (listy, mapy, tablice itp) to nie działa z dwóch powodów:
1. narzut wywołania kodu natywnego
2. niemożliwość optymalizacji kodu natywnego w zależności od kontekstu wywołania
W Javie, dzięki temu że kolekcje są napisane w Javie, JVM inline'uje i optymalizuje ten kod i wydajność jest identyczna z tym co miałbyś w C++. W Pythonie jest nadal 10x wolniej.
Inne miejsce, gdzie Python nadal ustępuje wydajnością z Javą jest zrównoleglanie kodu – Python na razie tego nie potrafi, więc na starcie na moim sprzęcie jest już prawie 8x do tyłu.
mowisz, ze nie ma multithreat? czy ze od razu sam sie nie rozklada na rdzenie?
jesli to drugie, to tak, jesli 1, to nie
Standardowy Python ma Global Interpreter Lock. Co z tego, że masz multithreading, jak wydajnościowo nic to nie daje.
standardowy tak, ale stackless juz nie ma GIL
jesli Ci za wolny zwykly, to uzywaj stackless 🙂
dlatego mozna miec kilka interpreterów na kompie, ironpython Jpython i inne.
Do obliczeń akurat python nadaje się świetnie. Może śmiało konkurować z matlabem…
Pod względem powolności na pewno. MatLab to straszny żółw. Mam kumpla, który w ramach doktoratu robił w matlabie symulacje układów elektronicznych (musiał korzystać z własnych modeli) i sam przyznał, że chodziło to 100x wolniej niż jakikolwiek Spice.
Oczywiście. Ale przecież trzeba porównywać do innego języka który jest choć nieco podobny 😉
Wliczanie Androida do QT uważam za nadużycie (równie dobrze mógłbyś wliczać użytkowników chrome z NaCl), ale z resztą mogę się zgodzić.
czy takie nadużycie? Necessitas pozwala na pisanie aplikacji na Androida i działają one bardzo dobrze.
Używałeś tego na coś więcej niż "hello world"? Wydaje mi się, że wynalazki Miguela są o wiele lepiej zintegrowane z platformą Android.
przeglądarka chromatogramów, sterowana gestami, pozwalająca na podgląd przebiegu procesu na komputerze zbierającym dane. Rzeczywiście, nic wielkiego.
Ja testowałem i każdy program napisany w Qt ruszał bez żadnych modyfikacji. Byłem (mile) zaskoczony.
Tylko trzeba pamiętać o niskiej rozdzielczości jeśli chce się coś stworzyć dla telefonów z Androidem. Choć z tym też jest coraz lepiej, a na tabletach nie ma tego problemu w ogóle .
to sporo czasu musiałes to testowac skoro KAZDY program qt działał
Ovi już nie ma
Gdyby podeszli inaczej do sprawy programiści prędzej czy później by się znaleźli, tylko niby po co mają robić aplikacje na system, który producent skazał na śmierć. Samsung swojego Wave'a ciągnie mozolnie ale chyba nawet skutecznie, a Nokia chciałaby zyskać to co Apple i Google w rok bez żadnej pracy i nakładów?
Nokia nie jest w stanie nawet wydać działającego debuggera. Po wywaleniu nawet własnej aplikacji system mówi "screw you", a jak dostaniesz stack trace nawet podczas krokowego debugowania to się możesz cieszyć … Oni nawet na Meego spieprzyli debugger – to już trzeba mieć talent.
Ehhh, za dużo "nawet" 😛
Każdy z "wielkich" "wygryza sobie" część rynku. No może po za zniewieściałą Nokią! Trzeba wiedzieć czego się chce i jakimi narzędziami można cel osiągnąć. Dlatego Nokia musi się przestać miotać i rzucać co chwila nowe pomysły a wziąć się do konkretnej pracy nad czymś czego nie porzuci za pół roku by wyskoczyć z czymś nowym.
Tani telefon z maszyną wirtualną Javy?! Do Javy trzeba wydajniejszego procesora i znacznie więcej pamięci jak do systemu stworzonego w C/C++. A to oznacza skok ceny za hardware. Na argumentację, że procesory/pamięci są coraz tańsze odpowiem. Czyżby! Warto prześledzić te "obniżki". Do tego jeszcze dochodzi problem akumulatora. Jak procesor będzie non stop "mielił" dane to nawet 100 trybów oszczędzania energii w nim zaimplementowanych niec nie da bo nie będzie w nie przechodził. A przecież telefon ma być elegancki i cieniutki a nie jak radiostacja czekisty. Bez właściwego doboru tych komponentów będziemy mieli bardzo ślamazarny telefon, którego nikt nie będzie chciał używać/kupić.
C/C++ ma się dobrze. Zapewne za sprawą bardzo przyziemnych i niespektakularnych aplikacji jak ABS, ESP, Fly-by-wire, falowniki silników elektrycznych, programatory pralek,… czyli całkiem sporo otaczającego nas i co tu kryć odpowiedzialnego sprzętu. Dlatego byłbym dosyć ostrożny co do ferowania wyroków, że Java jest wszędzie i musi znać każdy bo jest niezbędna.
"Tani telefon z maszyną wirtualną Javy?!"
A jak deweloperzy C++ aplikacji dla telefonów radzą sobie z wieloma urządzeniami, mają przygotowane wersje dla każdego bardziej popularnego telefonu?
W Javie łatwiej jest umożliwić działanie aplikacji na różnorodnym sprzęcie, więc taniej nie wychodzi sam sprzęt tylko dostarczanie telefonów. Android gdyby nie miał Dalvika nie byłby taki popularny.
Być może jest rynek na telefony bez milionów aplikacji, z których większość nie robi niczego nadzwyczajnego. A poza tym, samą JVM można dodać do telefonu, tak jak robiono to do tej pory.
"że Java jest wszędzie i musi znać każdy bo jest niezbędna. "
Nie musi znać, każdy wystarczy. że zna kilkanaście procent programistów 😉
Tego tak się nie robi. Google to trochę skwasił. Niektóre stare telefony miały takie fajne maszyny wirtualne JME, które działały dwuetapowo – kompilowały kod do kodu maszynowego w chwili *instalacji* aplikacji, a później wykonywały kod natywny. Wtedy naprawdę nie ma takiego dużego narzutu. Nie mówiąc o tym, że są procki ARM z natywnym wykonywaniem kodu Javy.
Kiedyś gdy dawno temu pisaliśmy kod w JME na komórki, czasem bardzo słabe, zwykle największym problemem była niska wydajność grafiki zakodowanej natywnie. Natomiast kod, który liczył np. kolizje, napisany był w Javie i nigdy nie mieliśmy większego problemu aby osiągnąć sensowną wydajność.
A, i jeszcze taka ciekawostka – te appki mieściły się ładnie w kilkuset *** kB *** RAM, włączając pamięć tekstur i rezerwę na GC. Więc da się.
Mechanizm Jazelle czyli transkrypcja kodu JVM na kod rdzenia/rdzeni ARM ma kilka istotnych ograniczeń. Pierwszym jest to, że nie wszystkie instrukcje Javy są zaimplementowane. Wpradzie to tylko 5% instrukcji nie mniej są one na tyle złożone, że trzeba je emulować programowo. Ważniejszym ograniczeniem jest ilość cykli zegara potrzebnych do wykonania instrukcji JVM względem Thumb czy ARM.
Transkrypcja kodu "w locie" w starych telefonach ma dwa ograniczenia. Kod po transkrypcji na instrukcje dla rdzenia trzeba gdzieś umieścić a to wymaga pamięci. Druga sprawa to czas oczekiwania w czasie uruchamiania JME, który do najkrótszych nie należy.
Ciekawe porównanie stanowi zestawienie w uruchamianiu środowiska IDE Eclipse (Java) z np. CodeBlock (wxGTK). Można spradzić jak się oba zachowują na zwykłym komputerze x86.
Poza tym, że jeden u mnie startuje w jedną sekundę, a drugi w 2 sekundy i praktycznie nie robi mi różnicy (i tak odpalam może raz, dwa razy na dzień) to takie porównanie jest zupełnie bez sensu ponieważ code blocks nie ma nawet 1/10 funkcjonalności Eclipse. Kodu też ma znacznie mniej. Mniej kodu do załadowania = szybszy start, to jest prawdziwe dla każdego języka. I nie jest tak modularny. Monolityczny program łatwiej zrobić aby startował się szybciej.
Skoro Eclipse startuje w 2s. to wnioskuję, że nie jest to 1.5GHz procesor i 512MB RAM.
Co do "funkcjonalności" Eclipse vs. CodeBlock to bym polemizował. Używam cross-kompilatora na ARMy wraz z debugerem, profilerem i programatorem/JTAGiem a to wszystko pod CodeBlock. Jak dla mnie wystarczy i nie bardzo potrzebuję czegoś więcej tak więc "nadfunkcjonalność" Eclipse jest mi zupełnie zbędna.
Intel i7 2.4 GHz i 8 GB RAM. Ale to nie ma dużego znaczenia. Najważniejszą różnicę robi dysk SSD. Większość czasu ładowania Eclipse'a to ładowanie kodu z dysku do pamięci, rozpakowywanie tych gigantycznych jarów pluginów itp.
No to mamy syndrom programisty na high-endowym kompie i nierozumiejącego utyskiwań użytkowników 😉
Na szczęście Eclipse nie jest dla zwykłego użytkownika.
A programista na słabszym sprzęcie ma zawsze w dyspozycji Vim 😉
Tak się spodziewałem w kwestii komputera 🙂 . Jedyne czego nie wziąłem pod uwagę to SSD. Obstawiałem raczej dysk 10K obrotów. To napisz jeszcze jaki masz zasilacz?
Problem w tym, że tego typu jednostki nie będa jeszcze bardzo dłgo dostepne w wersji tableta czy telefonu komórkowego. A ARM nawet wspomagany dla wzmocnienia przez procesor sygnałowy jak w OMAPach to tylko jednostka o skromnych możliwościach w stosunku do i7.
Eclipse na tablecie? Raczysz żartować? 😉