Why Java Rocks More Than Ever

Egy írás sorozat arról, hogy miért jobb a Java, mint valaha is volt. Java programozóknak, kétkedőknek ajánlott :-)

A sorozat részei:

  1. The Java Compiler
  2. The Core API
  3. Open-Source
  4. The Java Memory Model
  5. High-Performance VM
  6. Bytecode
  7. Intelligent IDEs
  8. Profiling Tools
  9. Backwards Compatibility
  10. Maturity With Innovation

Hozzászólások

Várj, segítek:

  1. a Java lassú, a C++ meg gyors
  2. a Java memóriazabáló, a C++ meg nem
  3. a Java mégsem platformfüggetlen, mert a C++...izé.
  4. a Java OOP, az OOP meg szar, mert csak a funkcionális a jó
  5. a Java nem jó, mert ma már mindenki webre fejleszt
  6. a Java nem jó, mert a múltkor is láttam egy programot az mekkora fos volt már, meg különben is AbevJava! meg applet.
  7. a Java nem jó, mert ha valami nincs összekonfigurálva, rengeteg exception-t dob, rengeteget logol, az meg milyen zavaró.
  8. aki szerint a Java jó az javahuszár és broáf

A listát persicsb jegyzi, gejzir és jence kiegészítésével

Az úgy nem lehet, hogy feladathoz az eszközt? Teszem azt, kernelt Java-ban? Vagy mikrokontrollerre, amelyben van néhány tíz byte RAM, Java-ban programozni? Ezek jó ötletnek tűnnek?

Szóval én azt mondanám, van a feladat, vannak eszközök, és a feladathoz választunk eszközt. Rosszabb esetben az eszközhöz feladatot. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

"To the best of our knowledge, the presented embedded Java system is the smallest Java system available. The Leros processor consumes less than 5% of the logic cells of the smallest FPGA from Altera and the Muvium compiler produces a JVM, including the Java application, that can execute in a few KB ROM and less than 1 KB RAM. The Leros processor is available in open-source and the Leros port of Muvium is freely available."

http://www.jopdesign.com/doc/lerosjvm.pdf
http://www.jopdesign.com/publications.html

Szerintem vannak dolgok, amire nem való a magas szintű programozás. PIC12F510-ben még megszakítás sincs, van 38 byte RAM-ja, a stack 2 mélységű. Szoftveresen generáltam hangot, miközben integrálva dolgoztam fel egy kapcsoló állapotát és állítottam elő egy triac vezérlését. Nem nehéz, csak az a gond, hogy úgy kell megírni, bármerre ágazik el a program, annak futásideje pontosan ugyanakkora és ismert legyen. Tehát egyes ágakba kellenek NOP-ok azért, hogy a kiadott hang frekvenciája, kitöltési tényezője ne függjön attól, ha egy feltétel teljesülésének következtében más ágon fut a program, mint addig.

Az ilyesmit szerintem assembly-ben kell írni. Ettől még lehet jó a Java, csak nem mindenre.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A blog címében korábbi önmagához van hasonlítva. Az amúgy a legtöbb dologról elmondható, hogy jobb, mint valaha, hiszen azért fejlődik.

Ugyanakkor a hozzászólások már inkább abból a megközelítésből születtek, hogy jobb, mint valamilyen másik nyelv, ami meg nyilván nem igaz, mert a feladat nélkül értelmezhetetlen kijelentés.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Megfelelni ilyen kovetelmenyeknek nem egyszeru, garantalni, hogy minden esetben meg fog felelni, az ennel is nehezebb.
Van, amit magasabb szintu nyelvekben egyszerubb kifejezni.

http://www.algo-prog.info/ocaml_for_pic/web/index.php?id=ocapic
https://forge.ocamlcore.org/docman/view.php/77/138/ocapic-ocamlmeeting-…

Engem nem kicsit zavarna hardware-közeli programozásnál, ha nem látnám, mi mivé fordul. Az assembly nem ördögtől való, nem érzem, hogy nehéz lenne benne programozni. Az persze más kérdés, hogy olyan helyre, ahol van operációs rendszer, magas szinten érdemes programozni, nyilván képtelenség assembly-ben megírni egy libreoffice-t például.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Veheted trollkodásnak felőlem, de ezek szerint nem nagyon érintett meg amit írtam. Épp azt mondom, hogy feladatfüggő, tehát általában már ne mondjuk, hogy jó, rossz, akármilyen.

Hasonlat: a konyhakés jó? Kenyeret szelni remek, csavarhúzónak csapnivaló.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nézd, az, hogy _NAGYON_ sokadszor jössz Java, .NET vagy más egyéb olyan témakörbe mikrokontrollerrel, hogy "jaj, hát ezzel is meg lehet csinálni", azt nem tudom másképp értelmezni, mint
- trollkodsz,
- halvány lila fingod nincs a témáról.

A mikrokontroller egy céleszköz, ezek meg általános célú programnyelvek, *felhasználói* programok gyors fejlesztésére. Ha képtelen vagy különbséget tenni a kettő között, akkor komoly bajok vannak.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Akkor világosabban fogalmazok. Valami hihetetlen mód irritál az a fajta pongyolaság, igénytelenség, amit itt egyesek elkövetnek. Semmi bajom ezzel, ha valaki picit pontosabban leírja, miről beszél. Viszont nem tette, akkor én kiterjesztő módon értelmezem az írottakat, és igyekszem megmutatni, mi a baj azzal, amit írt. Az, hogy hülyeség. Vagy szűkítse le a kört arra, hogy alkalmazásfejlesztésről beszél valamilyen oprendszer fölött, vagy ne mondjon olyasmit, hogy a Java jó, mert nem az. Mindenre nem az.

Ami a mikrokontrollereket illeti, a szívügyem, közel áll hozzám, s megpróbáltam elképzelni, mennyivel lenne „egyszerűbb” magas szinten programozni ott, ahol pontosan tudni szeretném, mi hány órajel, milyen stack mélység, mennyi RAM és hol, továbbá a felépítésből adódik, hogy nem 32 biten ábrázolok boolean-t, hanem 1 biten, de az is lehet, hogy ciklust úgy szervezek, hogy vizsgálom, a pointerem 5. bitje 1 lett-e, s ha igen, kilépek. Hardware közelében az absztrakció szerintem inkább nehezítés, mintsem könnyítés volna. Egy assembly utasítás leírásakor szinte látod flip-flop, logikai kapu, multiplexer szinten, mit is csinálsz, s miért.

Ezek olyan dolgok, amik nagyon nem valók magas szintű programnyelvhez. Tudom én ezt, de nem lehet a problémát felvetőben annyi minimális igényesség, hogy nem általánosan beszél, hanem esetleg elmondja, mi a fészkes fenét akar mondani?

Ugyanígy marhára irritál, amikor valaki ábrázol egy függvényt, csak „elfelejti” világossá tenni, mi van az abszcisszán és az ordinátán, valamint vagdalkozik számokkal, nagyvonalúan lehagyva a mértékegységeket. És ilyenkor nagyon nem értem, hogy miért nem vágta ki az ilyent vizsgáról az oktatója...

Na! :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem sok kedvem van belefolyni a dologba. De pont te jöttél a szál kezdéseként a mikrokontrollerekkel, holott a Java a szálban is említett módon, nem mikrokontroller programozásra való. Mint az közismert.

("Attól tartok, Safranek, hogy maga gúnyolódik velem. Jöjjön közelebb.")

Hát, ha a topicindítóra gondolsz, akkor szerintem a Java-t hasonlította a Java-hoz ("Egy írás sorozat arról, hogy miért jobb a Java, mint valaha is volt"), nem úgy általánosságban jelentette ki, hogy mindennél jobb.

Pl. "Boldogabb vagyok, mint valaha", az azt jelenti, hogy most vagyok magamhoz képest a legboldogabb az eddigi életem során, nem azt, hogy bárkinél / mindenkinél boldogabb lennék.

"Mindenre nem az."

De nem beszélünk mindenről. Te jössz itt egyedül minden egyes alkalommal a nyomorék PIC-jeiddel meg a bitbaszásaiddal, amire nyilvánvalóan nem tervezték se a Java-t se az összes többi magas szintű programnyelvet.

És hiába mondjuk el neked ezerszer, hogy édesmindegy, hogy egy weboldalnál most a válaszidő 10 vagy 100 ms, ha a 100 ms is belül van a követelményen és az, hogy 400E vagy 800E-ért kell venni gépet, ha közben mondjuk n millió(!) forintot spórolsz a fejlesztési költségeken. Arról nem beszélve, hogy az esetek 95%-ában sokkal fontosabb az, hogy meglegyen a funkció.

Mert nem 38 byte RAM-om van, hanem 4..64G és van egy normális compilerem, ami odarakja a NOP-okat, ahova kell. És egyébként is szeretek valós problémákat megoldani, nem azon maszturbálni, hogy meg tudok csinálni valami olyat, amit értelmes ember már rég egy géppel csináltat.

Értem én, hogy neked szívügyed a PIC, de vedd már észre, hogy amit te igénytelenségnek, lustaságnak gondolsz, az sok esetben optimalizálás. Fejlesztési időre. Breaking news: arra is kell, valós életben nagyon is.

(Konkrét példa: marketing kitalált valamit, hogy nagyon kell, ráadásul marha későn - utolsó lehetséges release után, amibe belefért volna, hurrá... - kérdem kollégám, akinek átadtam a taskot, hogy hogy áll. Mondja, egy queryt próbál optimalizálni, hogy ne kelljen kétszer futtatni - egy SELECT COUNT(*) és egy rendes. Kérdem milyen gyorsan fut le, elfogadható volt, mondtam, hogy ne ezzel húzza az időt, haladjon a feladattal, úgy is kb. 3-4 hétig lesz rá szükség, gép elbírja röhögve, és van más sokkal fontosabb feladat is, amire kell az idő. Szimplán gazdasági racionalitás.

De amennyire hallom, ugyanilyen okok miatt szokták okos közgazdászok mondani időnként, hogy az ezerszer egyszerűbben használható AVR-ek helyett valami ótvar PIC-et használjon az ember, mert "x mennyiség felett olcsóbb!".)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nagyon nem értjük egymást. Én mindezt értem. A gondom mindösszesen annyi, hogy ha teszünk egy kijelentést, biggyesszük már oda a peremfeltételeket is.

Az nem igaz, hogy a Java, vagy akármelyik programnyelv jó. Önmagában ugyanis nem értelmezhető a jósági tényező. Azt ugyanakkor mondhatod, hogy a Java olyan esetben, amikor van gépi erőforrás bőven, a mérnökóra a drága, akkor alkalmazás fejlesztésre oprendszer fölött jó.

A 1.5 V-os ceruzaelem jó? Sok dologba igen, de teszem azt, pacemakerbe, hallókészülékbe nem igazán.

nyomorék PIC-jeiddel

Nem én vagyok a Microchip. Ezen felül megnézem, hogyan oldod meg egy 64 GB-tal szerelt géppel azt a feladatot, amikor néhány cm3 térfogatban, néhány mW teljesítményfelvétel mellett kell megoldani dolgokat.

Még mindig azt mondom, feladathoz az eszközt, nem pedig univerzálisan kinyilatkoztatjuk, hogy valami jó vagy rossz.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

"Nagyon nem értjük egymást."

Te nem akarod érteni: Java az jó, alkalmazásfejlesztősre. És alkalmazásfejlesztés a téma. Erre idejössz a PIC-jeiddel erősködni, hogy az mekkora faszaság. Ismét. Sokadszorra.

Ha nem érted, mit jelent az, hogy alkalmazásfejlesztés, akkor talán nem kellene hozzászólnod a témához.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ja értem, szóval ha valaki elkezd a teszem azt a borászatról beszélni, akkor teljesen rendben van az, hogy valaki odatrollkodik az autószereléssel. Mert nyilvánvaló, hogy ha szőlőről van szó, akkor autót is szerelünk.

Érdekes, hogy mindig csak pont neked nem tűnik fel, hogy nem a PIC-ek a téma.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Khmm, amig meg kulturalt a szal, szerintem hagyd. Nem ket malomban oroltok, hanem ket orszagban. Biztos hogy eroltetni kellene ezt? Inkabb irj awesome Java/C# kodokat, vagy amit szeretsz. :-)
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

1. The Java Compiler:

class A { }
class B<E> { }
class C<D> extends B<B<? super C<C<D>>>> {
B<? super C<A>> cast(C<A> c) { return c; }
}

Miert nem mukodik (a fordito) ?

Régi javac bug, végtelen ciklusba kerül, nem is valószínű, hogy valaha javítva lesz. Ilyet amúgy se akar az ember írni.
Btw. ennyi elég már neki:

interface A<T> {}

class B<T> implements A<A<? super B<B<T>>>> {
    static void c() {
        A<? super B<String>> a = new B<String>();
    }
}

Ettől még a java nem rossz :)