Nokia nie chce Androida

To co za problem podczepić do pod obecne markety i dac lepsze warunki finansowe developerom.

Gdyby przerzucili się na Androida to musieli by się przyznać, ze zakup Symbiana i rozwój Qt był błędem i zmarnowali gigadolary, dlatego będą brnąć dalej…

Symbian is dead, Qt jest potężne (bardzo mi się podoba) ale ciężkie nawet na desktopach a co dopiero na mobilne urządzenia, na rynku jest kilka popularnych mobilnych systemów: iPhone, BB, Android, WM, z dwóch ostatnich każdy producent może skorzystać.

Jeżeli zmienią Symbiana w coś co jest używalne na nowych smartfonach to będzie to zupełnie nowy system z zerową pulą aplikacji. MeeGo to też zupełnie nowy system. Mam duuuże wątpliwości czy uda im się wypromować nowy system operacyjny, zwłaszcza że go jeszcze nie ma a udziały Nokii spadają.

Nokii marzy się model biznesowy iPhona – są zafascynowani kasą którą zarabia Apple na komórkach ale taki model jest nierealny dla nich. Nokia zarabia na masowej sprzedaży tanich komórek (dość drogich ale przeważnie solidnych).

Z QT na telefonie mam tylko do czynienia z Operą Mobile – i wierz mi – jest leciutka i szybciutka.

Kwant – pieprzysz kompletne bzdury aby przeportować jakikolwiek język programowania , biblioteki czy nowe funkcjonalności na symbiana wystarczy dodać odpowiedni moduł do serwerów w userspace .

Do dziś architektura Symbiana jest wzorem dla innych systemów jak minix3 . Problemem było tylko brak dobrych narzędzi programistycznych ale przeniesienie QT4 , pythona , ulepszenie javy i dodanie nowych funkcjonalności wspomoże system , zwłaszcza że on obecnie otwarty (licencja EPL) i społeczność stopniowo przeportowuje nowe programy i dodaje nowe funkcjonalności jak dostęp do Ext3 czy NTFS , port na x86 . Ba nawet uruchamiają Aplikacje z KDE4

@krzabr: a ty jak widzę ciągle z tą swoją mantrą, że im więcej kodu tym gorzej

Nie powiem, mikrokernele są fajne, Symbian jest tego przykładem… Ale nie zawsze i nie do wszystkiego.

> Symbian is dead, Qt jest potężne (bardzo mi się podoba) ale ciężkie

Tak, bo Android jest leciutki jak piorko…

(a juz zwlaszcza w wersji bez JIT). Pewnie dlatego w specs

do nowych wersji Androida jest cos w okolicach

CPU 1GHz i 512MB – jak myslisz, jak Qt na tym pojedzie?

Fakt, Android jest ciężki jak diabli z JITem jest równie ciężki tyle że szybszy Mi się osobiście takie podejście do programowania mobilnych urządzeń nie podoba a w Androidzie Java i Dalvik broni się jedynie możliwością zapewnienia większej ochrony i łatwością tworzenia aplikacji (Javę większość developerów zna, środowiska są dostępne vide Eclipse).

Jak mi ktoś powie, że Qt jest lekkie to mu na buty napluję Qt4+ jest fantastyczne, można szybko i łatwo napisać aplikacyjkę wykorzystującą sieć, dźwięk z aklceleracją 3D, przepiękną graficzne. Dla developera to raj bo środowisko jest spójne i dostarcza wiele ulepszeń jak własne stringi, kontenery, obsługę plików, sieci, wątków, lokalizację, etc… W dodatku wszystko prawdziwie wieloplatformowo a wygenerowany kod jest naprawdę zwarty. Ale patrząc na setki megabajtów bibliotek w których siedzą te zabawki to słowo ,,lekkie'' nijak nie przeciśnie mi się przez krtań. No chyba, że mówimy o jakimś oberżniętym i dostosowanym do aplikacji embeded Qt, ale to już nie jest Qt .

Anyway jestem mocno sceptyczny co do Qt na Smartfonach, na tabletach przejdzie, na netbookach również ale nie na 4 calowych handheldach. Stary symbian to zabytek, nowego jeszcze nie ma a już 2 lata spóźniony – czy Nokię będzie stać tak jak Samsunga na wydanie megadolarów developerom, żeby zechcieli napisać kilka aplikacji dla nowej platformy??? MeeGo to świetna platforma (jest ich zresztą wiele) ale kto napisze na tą platformę aplikację (patrz wyżej)?

IMHO Android wstrzelił się rewelacyjnie w rynek co widać po statystykach. iPhone będzie nadal popularny dzięki genialnej polityce Apple, która stworzyła wręcz ideologię wokół siebie. RIM to dla mnie zagadka – jest popularny głównie w USA, ludzie są z niego średnio zadowoleni i chętnie zmienią na coś innego (pamiętajmy, że iPhone sprzedawany jest tylko u jednego operatora!). Samsung gra na dwa fronty – Androida i Bada, ma kupę kasy więc może na siłę wypromować Bada ale jakiegoś entuzjazmu wokół tej platformy nie ma, z drugiej strony Samsung Galaxy S z Androidem sprzedaje się rewelacyjnie. Mobilny Microsoft traci pozycję i chyba czasy swojej świetności ma już za sobą: tu panie jest konkurencja na noże a nie ciepły monopol

Może jeszcze ktoś wyskoczy z kapelusza w najbliższym czasie. Rynek jest bardzo lukratywny, w USA 25% komórek to smartfony, które żyją średnio nie dłużej niż 2 lata więc co 2 lata ludziska będą kupować sprzęt za 500$ To więcej niż na komputery/laptopy bo czas życia tych urządzeń ostatnio bardzo się wydłuża a komórki się po prostu zużywają…

> W dodatku wszystko prawdziwie wieloplatformowo a wygenerowany kod

> jest naprawdę zwarty. Ale patrząc na setki megabajtów bibliotek w

> których siedzą te zabawki to słowo ,,lekkie” nijak nie przeciśnie

> mi się przez krtań.

Przepraszam, setki czego??

$ du -sc /usr/lib/libQt* /usr/lib/qt4 | sort -n | tail -5

7124 /usr/lib/libQtDesigner.so.4.6.2

10740 /usr/lib/libQtGui.so.4.6.2

16296 /usr/lib/qt4

16464 /usr/lib/libQtWebKit.so.4.6.2

66732 total

Przypominam, mamy rok 2010, smartfon ma dzis minimum 256MB,

i to bardzo zachowawczo mowiac.

@Jarek : To że niedługo miniaturyzacja krzemu niedługo się skończy i nie będzie można w nieskończoność upychać ramu w kości wielkości groszówki – to się skończy a kości grafenowe i nanorurki węglowe to wizja przyszłości za minimum półtorej dekady . Efekt tego będzie taki że niebawem wszystcy obudzą się z ręką w nocniku bo aplikacje i bibloteki będą tak zblootowane że ledwo co je uruchomi .

@Reddie – obiektowy mikrokernel RT to idealne wręcz rozwiązanie na takie urządzenia , symbian jest świeżym systemem nowocześnie zaprojektowanym i przeprojektowanym w 2008 roku . Ma wszystkie techniczne atuty aby być systemem numer 1 dla takich rozwiązań . Aż dziw w tym wszystkim bierze że mozolny zblootowany android zabiera mu rynek , ale cóż widać że wykorzystanie reklamy ze strony wielkiej marki + lenistwo deweloperów potrafią czynić cuda .

@krzabr: kiedy ostatnio patrzyłem, to Nokia miała w planach 1 (słownie: jeden) model z nowym Symbianem. Coś się zmieniło?

Widocznie MeeGo im się bardziej opłaca . Albo czekają na dopracowanie symbiana^4

@jarek, ok przesadziłem z setkami megabajtów Qt4, same biblioteki w /usr/lib mają ~70MB ale one też mają swoje zależności. Z prostego projektu GUI z mojego repozytorium zrobiłem ldd. Poniżej wynik (nie wiem czy cały się zmieści ale tam jest podlinkowane kilkadziesiąt bibliotek) ile to zajmuje pamięci? nie wiem dokładnie ale na pewno mnóstwo. Qt to nie jest lekkie, jest uniwersalne!

ldd bin/kicker

linux-vdso.so.1 => (0x00007fff20c86000)

libgdcmDICT.so.2.0 => /usr/lib/libgdcmDICT.so.2.0 (0x00007f8f1870f000)

libQtWebKit.so.4 => /usr/lib/qt4/libQtWebKit.so.4 (0x00007f8f17301000)

libgdcmMSFF.so.2.0 => /usr/lib/libgdcmMSFF.so.2.0 (0x00007f8f1701e000)

libgdcmIOD.so.2.0 => /usr/lib/libgdcmIOD.so.2.0 (0x00007f8f16e11000)

libQtGui.so.4 => /usr/lib/qt4/libQtGui.so.4 (0x00007f8f1617e000)

libmysqlclient.so.15 => /usr/lib/libmysqlclient.so.15 (0x00007f8f15e09000)

libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/libstdc++.so.6 (0x00007f8f15aff000)

libm.so.6 => /lib/libm.so.6 (0x00007f8f1587c000)

libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f8f15665000)

libc.so.6 => /lib/libc.so.6 (0x00007f8f15309000)

libgdcmDSED.so.2.0 => /usr/lib/libgdcmDSED.so.2.0 (0x00007f8f150b4000)

libQtNetwork.so.4 => /usr/lib/qt4/libQtNetwork.so.4 (0x00007f8f14d86000)

libQtCore.so.4 => /usr/lib/qt4/libQtCore.so.4 (0x00007f8f14905000)

libgdcmCommon.so.2.0 => /usr/lib/libgdcmCommon.so.2.0 (0x00007f8f146f4000)

libz.so.1 => /lib/libz.so.1 (0x00007f8f18b5a000)

libdl.so.2 => /lib/libdl.so.2 (0x00007f8f144f0000)

libgdcmexpat.so.2.0 => /usr/lib/libgdcmexpat.so.2.0 (0x00007f8f142ca000)

libphonon.so.4 => /usr/lib/libphonon.so.4 (0x00007f8f1405d000)

libQtXmlPatterns.so.4 => /usr/lib64/qt4/libQtXmlPatterns.so.4 (0x00007f8f139e0000)

libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x00007f8f137db000)

librt.so.1 => /lib/librt.so.1 (0x00007f8f135d2000)

libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007f8f132d8000)

libpthread.so.0 => /lib/libpthread.so.0 (0x00007f8f130bc000)

libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007f8f12eb2000)

libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00007f8f12c7d000)

libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007f8f129e6000)

libXext.so.6 => /usr/lib/libXext.so.6 (0x00007f8f127d4000)

libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f8f1249b000)

libgdcmjpeg8.so.62.1 => /usr/lib/libgdcmjpeg8.so.62.1 (0x00007f8f12268000)

libgdcmjpeg12.so.62.1 => /usr/lib/libgdcmjpeg12.so.62.1 (0x00007f8f12035000)

libgdcmjpeg16.so.62.1 => /usr/lib/libgdcmjpeg16.so.62.1 (0x00007f8f11e02000)

libopenjpeg.so.2 => /usr/lib/libopenjpeg.so.2 (0x00007f8f11be5000)

libuuid.so.1 => /lib/libuuid.so.1 (0x00007f8f119e0000)

libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00007f8f117ba000)

libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007f8f11574000)

libSM.so.6 => /usr/lib/libSM.so.6 (0x00007f8f1136b000)

libICE.so.6 => /usr/lib/libICE.so.6 (0x00007f8f1114f000)

libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x00007f8f10f46000)

libcrypt.so.1 => /lib/libcrypt.so.1 (0x00007f8f10d0e000)

libnsl.so.1 => /lib/libnsl.so.1 (0x00007f8f10af6000)

libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0x00007f8f108a3000)

libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0x00007f8f1051a000)

/lib64/ld-linux-x86-64.so.2 (0x00007f8f18aa6000)

libpulse.so.0 => /usr/lib64/libpulse.so.0 (0x00007f8f102d7000)

libpulse-mainloop-glib.so.0 => /usr/lib64/libpulse-mainloop-glib.so.0 (0x00007f8f100d2000)

libQtDBus.so.4 => /usr/lib64/qt4/libQtDBus.so.4 (0x00007f8f0fe5b000)

libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f8f0fc32000)

libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f8f0fa14000)

libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f8f0f810000)

libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f8f0f60a000)

libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007f8f0f3b2000)

libpulsecommon-0.9.21.so => /usr/lib/libpulsecommon-0.9.21.so (0x00007f8f0f162000)

libXtst.so.6 => /usr/lib/libXtst.so.6 (0x00007f8f0ef5b000)

libwrap.so.0 => /lib/libwrap.so.0 (0x00007f8f0ee52000)

libsndfile.so.1 => /usr/lib/libsndfile.so.1 (0x00007f8f0ebef000)

libFLAC.so.8 => /usr/lib/libFLAC.so.8 (0x00007f8f0e9b6000)

libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0x00007f8f0e4e7000)

libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0x00007f8f0e2bb000)

libogg.so.0 => /usr/lib/libogg.so.0 (0x00007f8f0e0b4000)

libasyncns.so.0 => /usr/lib/libasyncns.so.0 (0x00007f8f0deaf000)

libresolv.so.2 => /lib/libresolv.so.2 (0x00007f8f0dc98000)

libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0x00007f8f0da24000)

libgdbm.so.3 => /usr/lib/libgdbm.so.3 (0x00007f8f0d81e000)

libcap.so.2 => /lib/libcap.so.2 (0x00007f8f0d618000)

libQtXml.so.4 => /usr/lib64/qt4/libQtXml.so.4 (0x00007f8f0d3d0000)

libXi.so.6 => /usr/lib/libXi.so.6 (0x00007f8f0d1c0000)

libattr.so.1 => /lib/libattr.so.1 (0x00007f8f0cfba000)

Kwant, a tak powaznie, to odrozniasz ilosc

zaleznosci od ich sumarycznej wagi, nie?

$ ldd /usr/bin/gnome-terminal | wc -l

61

$ du -Lshc $(ldd /usr/bin/gnome-terminal | sed 's/.*=>//' | awk '{print $1}' | grep '^/' | sort -u) | tail -1

15M total

@krzabr skończy a kości grafenowe i nanorurki węglowe to wizja przyszłości za minimum półtorej dekady

No dobrze, ale troche bardziej przyziemnie, takie Qt miesci sie ponizej

100MB, 1GB dzis to jest lekki standard. Po co wiec te nanorurki i kosmoloty?

Przyznaje się że przeszacowałem wagę QT , jednak problem blootu w kodzie pozostaje .

czy slyszeliscie kiedys o Qt Embedded? Ma to footprint ponizej 9MB i nie wymaga X'ow

A o –as-needed Kwant słyszał?

@no4b – ciekawe ile kompilacja z tą flagą zajmie miejsca .

Przyznaje się że przeszacowałem wagę QT , jednak problem blootu w kodzie pozostaje.

Hmmm, pamięć jest tania. Programiści są drodzy. Użytkownikom „bloot” nie przeszkadza. Podsumowując, użytkownik woli 100 wystarczająco dobrych aplikacji niż 10 idealnych.

Co do potentatów na rynku smartfonów to zapomniałeś chyba o RIM, a Samsung przekroczył już 2% ?

Powinieneś dodać, że chodzi o Stany Zjednoczone, bo stamtąd pochodzi większość zestawień smartfonów. Jest to dosyć specyficzny rynek, gdzie Nokia praktycznie się nie liczby – nawet w kategorii zwykłych telefonów.

Natomiast Samsung z Wavem celował bardziej w Rosję i Azję – tak przynajmniej wynikało z informacji prasowych przed premierą.

Nie, nie chodziło o rynek USA.

Czy ja gdzieś zakwestionowałem dominację Nokii ? Nokia z Samsungiem faktycznie sprzedają najwięcej telefonów, ale jeśli chodzi o smartfony to sytuacja dla Samsunga już nie jest tak różowa.

Nokia, RIM, Apple … HTC,Motorola,Samsung.

@rybirek : Nie rozumiesz że samsung ma już absolutnie wszystko aby stopniowo zdobywać rynek ?

@krzabr : Ja tego nie kwestionuję, wręcz potwierdzam, że jest drugim pod względem sprzedaży producentem telefonów, ale na dzień dzisiejszy to procentowy udział smartfonów w tej produkcji jest niewiele. Inna sprawa do zaliczanie do smartfonów wszystkich produktów Nokii z symbianem.

Co ty chcesz portować z Linuxa na smartfony? OpenOffica???

Basha, Pythona, Ruby, Perla i całą masę bibliotek.

Nie chodzi przecież o wygląd, a o możliwość uruchamiania aplikacji działających pod Linuksem.. Widziałeś MeeGo? Jest specjalne miejsce na desktopowe aplikacje, można tam uruchomić np. google chrome.

Po co nadmiar bibliotek ? W przypadku androida styknał tylko dalvik i libc .

W przypadku symbiana styknie python i qt4

@krzabr: żeby programiści innych języków też mogli pisać na daną platformę. Im Python nie "styknie".

Co to jest "nadmiar bibliotek"?

@Kwant

Zdecydowanie łatwiej przeportować desktopową aplikację z długa historią zmieniając jedynie GUI i wycinając kilka niepotrzebnych ficzerów niż napisać ją od nowa. Poza tym można czerpać z linuksowej drogi rozwoju oprogramowania i portować pierdoły z której nie będą korzystać użytkownicy, a aplikacje- takich jak np. biblioteki.

Swoją drogą na pewno na większość telefonów z MeeGo pojawią się nieoficjalne porty androida- na n900 już jest. Jakby tylko google objęło je patronatem to nie byłoby najmniejszego problemu ze zmianą systemu.

@All, no to poproszę listę aplikacji (nie bibliotek/języków!), których brakuje na smartfonach (nie tabletach, netbookach) a są na desktopach i warto byłoby je przeportować… Jak będzie lista to się zastanowimy jakie są potrzebne do tego biblioteki i języki programowania.

No to wyliczamy:

1. Eeeee…

2. ????

3. !@#$%

@Kwant: poproszę listę aplikacji których brakuje na Win95, a potem się zastanowimy po co te nowe systemy, biblioteki i języki programowania.

> Po co nadmiar bibliotek ? W przypadku androida styknał tylko dalvik i libc.

Chyba nie sadzisz, ze Google przepisalo cala te funkcjonalnosc

"pod Dalvikiem"? To by sie zawalilo po wlasnym ciezarem.

Pod spodem jest zestaw standardowych bibliotek ktore znajdziesz

w kazdym distro. Poczynajac od libjpeg, poprzez openssl na webkit

konczac. Odpal sobie kosole na Androidzie i zrob pare ls'ow

zanim znow cos takiego palniesz.

Aplikacji żadnych, tylko system na obecne czasy jest przestarzały: słabe bezpieczeństwo, brak prawdziwego multi-user, obsługuje tylko jeden rdzeń – brak SMP/NUMA, mało obsługiwanej pamięci RAM, proteza stosu TCP/IP, brak supportu producenta, brak sterowników do nowego sprzętu a stary sprzęt już nieprodukowany, etc… To taki Symbian – oba system zaprojektowano dawno temu i wtedy były ok, ale w dzisiejszych realiach zupełnie się nie sprawdzają.

Aplikacje na PC i komórki to dwa różne światy. Nadal twierdzę, że nie bardzo jest co poprtować w obie strony a biblioteki i języki są dla developerów a nie userów – to środowisko pracy pomagające efektywniej pisać aplikacje a nie umożliwiające (wszystko można napisać od zera w asemblerze czy innej maszynie Turinga).

Skrajne przykłady: OpenOffica nie ma co portować na Komórki choć chciałbym mieć tam możliwość prostej edycji tekstu… Klient pocztowy jest na obu platformach ale zupełnie inny i nigdy Evolution/Outlook nie zagości na Smartfonie z 4 calowym ekranem. Z drugiej strony na komórce mam ,,aplikację'' (widżet) latarkę włączającą diodę LED, funkcjonalność prawdziwie użyteczna przy zaglądaniu do skrzynki na listy albo szukaniu kluczy upuszczonych koło samochodu w nocy a jednak bezsensowna do portowania na PC. To są dwa różne światy.

@Reddie – wpychanie takiej ilości bibliotek od każdego języka znacznie zwiększa rozmiar base systemu + robi jeszcze większy śmietnik w językach programowania .

Android w tym wszystkim ma ten wielki + że posiada jednolite API oparte na VM dalvika (javopodobne) .

Co do win95 . Prosty przykład Office 97 uruchamiał się i działał nawet przy 32 mb ramu . A dziś open office muli przy 1gb ramu 800 mhz . A jak wzrosła funkcjonalność między oboma ? Niewiele .

Więc dla mnie jest jasne – że devom zamiast pisać dobry soft wolą tworzyć klikające IDE ze zblootowanymi biblioteczkami po to aby mieć szybki sosik do kieszeni .

@Kwant: ale to ty zacząłeś o portowaniu aplikacji z desktopów. Ja pisałem o portowaniu środowiska w celu łatwiejszego pisania nowych aplikacji mobilnych.

@krzabr

wpychanie takiej ilości bibliotek od każdego języka znacznie zwiększa rozmiar base systemu

So what? Żyjemy w czasach, gdy gigabajty pamięci w smartfonach są już na porządku dziennym.

robi jeszcze większy śmietnik w językach programowania

A konkretniej?

Co do win95 . Prosty przykład Office 97 uruchamiał się i działał nawet przy 32 mb ramu . A dziś open office muli przy 1gb ramu 800 mhz . A jak wzrosła funkcjonalność między oboma ? Niewiele .

Nie zrozumiałeś pytania.

Więc dla mnie jest jasne – że devom zamiast pisać dobry soft wolą tworzyć klikające IDE ze zblootowanymi biblioteczkami po to aby mieć szybki sosik do kieszeni .

Skoro to takie proste, czemu sam się tym nie zajmiesz?

Mamy obecnie dziesiątki języków programowania a na smartfonach ile się ich liczy 5 ? 6 ? (Java , ObjC , C++ , Python , Elua)

To po co portować więcej bibliotek języków ? Wyjaśnij mi ?

To pokaż jak bardzo się różnią funkcjonalnością aplikacje użytkowe (nie licząc gier i przeglądarek internetowych) . Bo jak dla mnie nowości nie jest tak wiele , aby smartfony musiały mieć tyle gigabajtów ramu co netbook .

Zgadzam się z krzabr, za dużo tworzymy abstrakcji. Do napisania prostej aplikacji na telefon komórkowy używanie wszystko-mogacych bibliotek jest mocnym nieporozumieniem.

Dla mnie nazwanie języka ,,C” językiem niskopoziomowym jest punktem zwrotnym, ja tak nazywałem asembler a o czymś takim obecni studenci chyba w ogóle nie słyszeli… Nie twierdzę, że należy pisać aplikacje użytkowe w asemblerze bo to zboczenie ale jak pomyślę ile tygodni mogła by działać komórka gdyby miała 100x słabszy procesor w topowej technologii to zastanawiam się czy nie warto jednak optymalizować aplikacji pod kątem szybkości wykonywania a nie szybkości pisania.

Chyba jednak trzeba się pogodzić z programami-mamutami, userzy chcą mieć nową aplikację co 5 minut, oni płacą, oni wymagają…

@krzabr

To po co portować więcej bibliotek języków ? Wyjaśnij mi ?

A po co w ogóle języki programowania? Wszystko da się napisać w asemblerze

To pokaż jak bardzo się różnią funkcjonalnością aplikacje użytkowe

Do czego odnosi się owo "To"?

@Kwant

Zgadzam się z krzabr, za dużo tworzymy abstrakcji. Do napisania prostej aplikacji na telefon komórkowy używanie wszystko-mogacych bibliotek jest mocnym nieporozumieniem.

To nie używaj, też mi problem. Nikt cię nie zmusza. Na razie to ty uważasz, że reszta świata powinna przyjąć twój pogląd na programowanie.

Nie twierdzę, że należy pisać aplikacje użytkowe w asemblerze bo to zboczenie

Dlaczegóż to, przecież się da ;> Za dużo tworzysz abstrakcji!

W assemblerze to głupota , jednak c , java , python naprawde wystarczą do napisania 90++ procent programów , po co ładować dziesiątki języków , jak jest kilka które do wszystkiego wystarczają .

@krzabr: ale dlaczego głupota? Możesz mi na to odpowiedzieć, czy po prostu "głupota, bo tak"?

@Reddie: Bo nie daje kompletnie żadnych korzyści, a przynosi wiele szkody.

Jak to żadnych? Śmiga jak struś pędziwiatr ;>

Hahah, przypomniała mi się Amiga 500 i ile rzeczy można było zrobić przy 512 *kilobajtach* RAMu, procesorku Motoroli i dedykowanych kontrolerach. A przy dwóch megabajtach… hohoho…

Nie karzę nikomu wracać do tamtych czasów, jednakże dzisiejszy soft poszedł na straszną łatwiznę.

No tłumacze kolejny raz że duża ilość języków sieje tylko zamieszanie i rozbicie , jeśli nie potrafisz tego zrozumieć to prościej nie potrafie ci wyjaśnić xD

@krzabr: no ale przecież zapytałem, że dlaczego w takim razie nie zostawić samego asemblera? A odpowiedziałeś tylko „głupota”. Faktycznie, taki argument zupełnie do mnie nie przemawia.

Sam assembler jest za trudny dla wielu programistów i nieprzenośny w zupełności może być zastąpiony c/c++ , do tego dorzucić kilka języków przenośny – jvm , dynamiczny – python , skryptowy embeed – elua i wystarczy .

Nie wiem po co pisać wszystko w samym aśmie , albo w dziesiątkach języków . No chyba że udowodnisz że jest sens inaczej .

@krzabr: a jak ktoś nie lubi Pythona tylko na przykład Perla, to ma pisać w Pythonie bo ty uznałeś ten język za właściwy?

Nie wiem, jak można mieć tak ograniczony światopogląd.

No można bo to jest praktyczne i efektywne .