[HWSW]

Elkészült a LibreOffice új, 4.0-s verziója, a fõverzió váltását azonban kevés dolog indokolja, inkább finomításokra, csiszolásra helyezték a fejlesztõk a hangsúlyt, látványos újdonságok, felület most nincs.
https://www.hwsw.hu/hirek/49778/libreoffice-4-0-librelogo-office-nyilt-forras.html

[attila9988]

Az érdekesség ebben, a python -ozás. Miért lenne az jobb egy fokkal is mint a java? Még lassabb is.

[SkyNet74]

Elvi oka van legjobb tudomásom szerint, az hogy a java csak részlegesen szabad szoftver.

[Yv@n]

Idézet: attila9988 - Dátum: 2013. 02. 07. 19:23

Az érdekesség ebben, a python -ozás. Miért lenne az jobb egy fokkal is mint a java? Még lassabb is.

Lehet csak Oracle felé középső ujj.

[Petesejt]

Na meg elég necces a biztonsági hibák frissítésének sebessége is a java-nál.

[Raynes]

Alig várom, hogy ne kelljen Java a LibreOffice-hoz. Ha nem kéne még 1-2 weboldalhoz, amit látogatok meg Abevhez, fel sem tenném azt a szart.

Szerkesztette: Raynes 2013. 02. 08. 09:02 -kor

[sikoly_mester]

@Raynes: Na ja, csak sajna az eclipse is java. Amúgy én is törölném. Mondjuk az abev elfut egyszer egy évben egy VM-ben, amiben van java.

[attila9988]

@Raynes: Nem tudom miért utáljátok ennyire. A rails -ben is mostanában találnak mindenféle súlyos hibákat, ott talán még komolyabb a gond mint itt. Egy fokkal sem jobb. A python -ban is bizonyára lehet elég. Ezek mind ilyenek. A natív nyelveken te követhetsz el hibát. Az ilyen vm -es, illetve ezeken túl még a script -elõs nyelveken meg a futtató környezet lehet lukas mint az ementáli sajt.

Ha azt mondjuk hogy szar a java mert vm -es, akkor szar a többi hasonló is.

Másik dolog, hogy a libreoffice -hoz csak a base esetében kell a java, tehát ha ez tart vissza, akkor nyugodtan letörölheted. De ha pl kell neked az eclipse, vagy a netbeans, akkor kell neked a java is.

[attila9988]

Amúgy mi a véleményetek errõl a python -ról, mint nyelvrõl? Annyira még nem ismerem, de nem igazán tetszik. Kissé keszekusza.

[Atko]

@attila9988: mihez képest?

[attila9988]

@Atko: Mihez képest keszekusza? Hát mondjuk egy java -hoz képest. Nem a szívem csücske az se, de ha szigorúan mint nyelvet vizsgáljuk, akkor el lehet mondani hogy beszédes nyelv.
Sokan elõnyként fogják fel, ha két sornyi krikszkraksz csinál valami komolyat, csak az a baj ezzel, hogy késõbb mikor azt el kellene olvasni, akkor már nem igazán élvezetes a dolog, fõleg ha kommentek sincsenek. Tehát ami rövid, viszonylag egyszerû feladatoknál jó dolog, az pl hosszabb, kissé komolyabbaknál kifejezetten hátrányos lehet. Persze ez csak az én véleményem.

[zZsOlTi]

Idézet: attila9988 - Dátum: 2013. 02. 08. 13:50

Sokan elõnyként fogják fel, ha két sornyi krikszkraksz csinál valami komolyat, csak az a baj ezzel, hogy késõbb mikor azt el kellene olvasni, akkor már nem igazán élvezetes a dolog, fõleg ha kommentek sincsenek. Tehát ami rövid, viszonylag egyszerû feladatoknál jó dolog, az pl hosszabb, kissé komolyabbaknál kifejezetten hátrányos lehet. Persze ez csak az én véleményem.

Nem kevered valamivel a pythont? Mitől krikszkraksz? A python egyik fő tervezési szempontja volt az olvashatóság. A szigorú szintaxis is az olvashatóságot segíti. A blokkok és utasítások határait a sortörések adják, ezért nem lehet összevissza tetszőleges stílusban kódolni, megfelelően _kell_ tördelni, indentálni, és nincs tele a kód felesleges nyitó-záró karakterekkel. Nézd meg itt ezt az egyszerű példát, melyik olvashatóbb? Ésakkor a C-t még átformázhatjuk 5 féle képpen, ahogy tetszik, akár írhatom egy sorba az egész if-else blokkot.

"fõleg ha kommentek sincsenek"
Ha nincsenek kommentek, az nem a nyelv, hanem a programozó hibája.

[geleim]

Idézet: zZsOlTi - Dátum: 2013. 02. 08. 15:14

Nézd meg itt ezt az egyszerű példát, melyik olvashatóbb?

Őszintén? Nekem nincs bajom a Pythonnal, de szerintem a C-stílusú kód (nekem legalábbis) sokkal olvashatóbb. Ja, hogy a programozó okádék kódot ír? Akkor meg kell rugdosni, de ez nem a nyelv hibája. Mint ahogy a "misleading indentation in C" példakód a linkelt oldalon: ez sem a nyelv hibája, hanem az anyaszomorító, trehány programozóé, aki nemhogy a kódot nem írta meg rendesen, de az automatikus kódformázást is direkt kikapcsolta az IDE-ben.

[wolfgaber]

A pythonból hogy bírták kihagyni a hátultesztelõs ciklust? Tudom, hogy van rá trükk, de azért elég alap dolog szerintem.

[Sanyix]

@attila9988: Ez a 90-es évekre vezethetõ vissza részben. Akkor az volt a mondás hogy a java szar lassú (mert az akkori gépek nem voltak elegendõek hozzá na meg sok volt rá a gány program), és azért mert telepíteni kell. Ez úgy megmaradt. Fingjuk sincs igazából róla. Ahogy meg lett mondva hogy a vista márpedig szar úgy a java is.
Annyira nem tudják mirõl van szó, hogy a böngészõs applet bugoknál azt hiszik az egész java szar, na meg a javascriptet sem tudják megkülönböztetni a javatól, még ha 2 tök különbözõ dolog is.
Emellett ugye az is egy begyepesedett szokás, hogy az 1 bites user szerint a VM szar, mert ezt hallotta. A .net-et csak azért nem szarozza, mert arról nem köztudott hogy VM, na meg manapság mivel nem kell telepíteni, azt sem tudja a user ha éppen azt használja.
A scriptnyelvekrõl is azt hiszik hogy az nem VM-ben fut, pedig de pedig azok többsége tényleg szar, vagy legalább is biztos hogy szarabb mint a java.

[attila9988]

@Sanyix: "Ez a 90-es évekre vezethetõ vissza részben. Akkor az volt a mondás hogy a java szar lassú (mert az akkori gépek nem voltak elegendõek hozzá na meg sok volt rá a gány program)"

Hát... tulajdonképpen a java akkoriban tényleg szar is volt, meg lassú is volt minden tekintetben. Eleve interpretált nyelvnek lett tervezve, sehol sem volt még a hotspot. Tulajdonképpen ma is van ellne bõven érv, de azért történt egy két változás. Pl elkezdtek jit -elni, ami gyorsít. Igaz hogy közben meg elvesz máshonnan, hiszen az eredeti kód, és a jit -elt is a heap -ben van, tehát helyet foglal, valamint a kódellenõrizgetés, és fordítgatás is erõforrás igényes. Akik meg azt mondják hogy mindig lehet olyan gyors mint egy c++, azoknak nem árt figyelembe venni, hogy maga a vm is egy c++ program, és külön process -ként fut az os -en. Mivel ennek a folyamatnak a feladata a mi kódunk egyengetése, értelemszerûen nem valószínû hogy lehet nagyobb sebességet kicsikarni belõle. (annak tükrében hogy a java eredetileg szórakoztatóelektronikai, kicsi, gyenge eszközökre lett kifejlesztve, elég érdekes hogy végül mi lett belõle)
Ezen kívül pedig ugye gyorsabbak is lettek a gépek, és több a ram is, ami elfedett bizonyos problémákat. Én azért továbbra sem vagyok nagy rajongója ezeknek a cuccoknak, csak arra akartam felhívni a figyelmet, hogy ha eldobjuk a java -t, és python -ozunk helyette, az a szarnak pofon kategória. Már csak azért is, mert a python alapjában véve lassabb megoldás, és nincs neki akkora ipari támogatása, mint a java -nak, nem figyeli annyi mérnök hogy hogyan lehetne rajta javítani. Az openjdk óta meg igazából az opensource világ is adoptálta a kicsit, így nem tudom milyen kifogás lehet ellene.
Nem értem továbbá azt sem, hogy pontosan miket akarnak kicserélni python -ra, hiszen a hivatalos weboldal szerint is csak a base -hez kellett a java, és leginkább azért, mert az alapértermezett adatbázismotor java -s. Ha meg azt lecserélik, akkor se java, se más nem kellene elvileg a libre -hez.

"A .net-et csak azért nem szarozza, mert arról nem köztudott hogy VM, na meg manapság mivel nem kell telepíteni, azt sem tudja a user ha éppen azt használja."

Ebben van valami. Nem mellesleg a .net eleve egy java koppintás, ami azért született, mert a sun beperelte az ms -t amiért az saját java kiterjesztésekkel tette inkompatibilissá (ms -tõl mit lehet várni?) a windows -os java variánst.


"A scriptnyelvekrõl is azt hiszik hogy az nem VM-ben fut, pedig de"

Igazából nem, de majdnem. Azok egy értelmezõ programnak adnak utasítást - ami jellemzõen szintén c++ program - ami majd végrehajtja azt. Ezek rendszerint még lassabbak mint a vm -ezõsök, mert a kódértelmezés, és fordítás is röptében történik. A script nyelv eleve nem arra való, amire a rendes programnyelvek, bár sokan arra akarják használni.

Összefoglalva. Nem vagyok valami nagy java rajongó, de nem értem milyen racionális döntés vihet - ora gyûlöleten túl - arra, hogy python -al váltsam ki azt.

[bogdan]

Idézet: attila9988 - Dátum: 2013. 02. 10. 10:15

Akik meg azt mondják hogy mindig lehet olyan gyors mint egy c++, azoknak nem árt figyelembe venni, hogy maga a vm is egy c++ program, és külön process -ként fut az os -en. Mivel ennek a folyamatnak a feladata a mi kódunk egyengetése, értelemszerûen nem valószínû hogy lehet nagyobb sebességet kicsikarni belõle.

szep logikai eszmefuttatas, kar, hogy hibas!
a c++ programodbol forditott gepi kodot ugyanis futas kozbe nem optimalizalhatja semmi, az olyan lesz, ahogy leforditod. (na jo, az OOO beleszol processzorszinten egy picit.) a java kodot, viszont a jit elkezdheti optimalizalni, amihez egyfelol felhasznalhatja a processzor tulajdonsagait, masfelol a futas kozben kinyert informaciokat (melyik ciklusban mennyi idot toltott a program.)

a processzor tulajdonsagait persze elvben a c++ programforditas is kihasznalhatja, ha konkret gepre fordit az ember. ha nem (pl. kereskedelmi program), akkor nem tud vele olyan jol elni.

Idézet

"A scriptnyelvekrõl is azt hiszik hogy az nem VM-ben fut, pedig de"

Igazából nem, de majdnem.

maradjunk inkabb a "semennyire" fordulatnal. mi koze lenne peldaul egy bash scriptnek a virtualis gepekhez?

[MisterY]

Idézet: bogdan - Dátum: 2013. 02. 10. 10:47

maradjunk inkabb a "semennyire" fordulatnal. mi koze lenne peldaul egy bash scriptnek a virtualis gepekhez?

Gondolom, arra próbált utalni, hogy ha csak az abev vagy libre office miatt kellett volna a java a gépre, akkor ha már az office-nak nem kell, akkor az abev-et "bezárja" egy virtuális gépbe, és akkor a java sérülékenysége miatt max évi 5-10 percig van nyitott ablak a gépen.

[attila9988]

@bogdan: "szep logikai eszmefuttatas, kar, hogy hibas!
a c++ programodbol forditott gepi kodot ugyanis futas kozbe nem optimalizalhatja semmi, az olyan lesz, ahogy leforditod."

Ez elméletben jól hangzik, de ennyire azért nem hatékony a dolog. Eleve ott a gond, hogy tulajdonképpen a cpu is optimalizál. A nagyobb cache, vagy pl az elágazásbecslés a cpu feladata. (fõleg ma, maikor micro kóddal megy a cpu is, részben a kompatibilitás fenntartása végett) Amit külön kódból kell támogatni, mint mondjuk az sse különbözõ fajtái, azokat valóban alkalmazhatja a java jittere, ha ismeri a vm az adott processort, ÉS képes felmérni hogy mely kódrészletek esetében segítheti a futási sebességet.

De akkor görgessük tovább a dolgokat. Vagy egy vm -em, ami c++ -ban van megírva. Ennek a vm -nek a teljesítménye függ attól, hogy pl milyen fordítóval fordítottam le. Pl a jitter mûködési sebessége is függ ettõl. A heap -ben a bytekódból létrehozott gépi kód minõsége persze nem, de a létrehozásának sebessége igen. Mint ahogyan az egész ellenõrzési, kódelemzési folyamat is. Ezeket is a cpu -nak kell elvégeznie. Tehát elindítok egy java programot. Akkor bemászik a ramba a vm, lefoglal egy bizonyos memóriaterületet ahova betölti a kódomat, feltérképezi az osztályhierarchia -t, létrehozza az alap változókat amik kellenek, majd elkezdi futtatni a kódot. Közben ha valamit különösen gyakran használok, akkor rájön hogy azon érdemes lehet gyorsítani, tehát elkezdi jit -el leforgatni a heap -en belül, és ha kész, akkor azt a kódrészletet onnantól kezdve a gépi kódú változatban futtatja. De ez nem a teljes program, csak annak egy része. Mondjuk egy jó hosszú ideig folyó matekos objektum -on belüli loop vagy hasonló. De ha ez a kódrészlet rettentõ optimális is lenne, a teljes program futási sebességén akkor is ott van ballasztként a vm, ami folyamatosan melózik, elemez, értelmez, fordít stb...

Összességében véve, pont ezért lehet benchmarkokkal üres loop -okkal, meg pár matek példával bebizonyítani hogy haj de gyors a java program, de valós alkalmazások esetén mindig az van, hogy lassan indul, sok ramot zabál, és alapjában véve kevésbé is válaszképes minden amit java -ban ír az ember. Persze ettõl még ügyviteli programokhoz nem rossz, meg a programozóknak tök kényelmes, és ha portolva van valahova a java vm, akkor ott is menni fognak a programok, ami megint csak kényelmes.
De egy gépi kódra forgatott program mindig optimális sebességet tud biztosítani, ráadásul tényleg bármilyen eszközön. Itt van a kis routerem mellettem, van rajta elég sok minden 8 mb -ban. 32mb rammal van szerelve. Ezen nem tudna semmilyen vm elfutni, kódot optimalizálni, stb... (mondjuk egy vuze nem menne el rajta, de az pl a rendes gépeken is mindig erõforrásigényesebb, mint akár egy utorrent, akár egy transmission) a ráforgatott gépi kódú progik viszont remek munkát végeznek.

Tehát miért jó a java? Azért mert hordozható? Igen. Azért mert kényelmes? Igen. Azért mert gyors és optimális lenne? Nem...
Valahol a script nyelvek, és a "rendes" nyelvek között lavírozik ügyesen.

[attila9988]

@bogdan: Na erre nem válaszoltam:
"maradjunk inkabb a "semennyire" fordulatnal. mi koze lenne peldaul egy bash scriptnek a virtualis gepekhez?"

Semmi. Teljesen igazad van. A beszélgetésben a vm -ek, és a script értelmezõk közti pár hasonlóságot próbáltam elmagyarázni. Hiszen van köztük. A vm több, jobb, de hasonló elvek alapján jött létre.