A JavaScript lesz a GNOME fejlesztők által ajánlott elsődleges nyelv a GNOME alkalmazások írásához

Címkék

Travis Reitter, GNOME fejlesztő a napokban arról írt egy blogbejegyzésben, hogy szükségesnek érezték (a GNOME fejlesztők), hogy kiválasszanak egy nyelvet, amelyet azoknak javasolhatnak, akik felteszik a következő kérdést: "Hogyan írjak alkalmazást GNOME-ra?"

Hosszasan vizsgálták a lehetséges opciókat és végül arra jutottak, hogy a JavaScript az a nyelv, amelyet elsődleges nyelvnek neveznek ki GNOME alkalmazásfejlesztéshez. Reitter fontosnak érezte kiemelni, hogy attól, hogy a JavaScript kitüntetett figyelmet kap, a többi nyelvet sem hanyagolják teljesen. Mit jelent az, hogy a JavaScript lesz az elsődleges nyelv a GNOME alkalmazások fejlesztéséhez?

  • Továbbra is írnak majd dokumentációt más nyelvekhez, de a JavaScript-et részesítik előnyben akkor, amikor arról kell dönteni, hogy min dolgozzanak.
  • Arra bátorítanak, hogy az új alkalmazások JavaScript-ben készüljenek.
  • A JavaScript köré optimalizálják a fejlesztői munkafolyamatokat.

Mindemellett a rendszerkönyvtárakhoz továbbra is a C marad az ajánlott nyelv.

Hogy miért a JavaScript? Arról részletesen itt lehet olvasni.

Hozzászólások

Miért kell azt a foshalom nyelvet ennyire nyomni? :(

Jó tudom, web2, meg a net jövője, de akkoris :(

"Egyreszt a V8 nagyon gyors"
pontosan, rengeteg munkat oltek bele, hogy gyors legyen egy alapvetoen nem erre tervezett nyelv. A JS apro feladatok egyszeru leirasara keszult, csak tulnotte ezt a feladatot anelkul, hogy ehhez igazitottak volna.

"miert lenne 'foshalom' egy nyelv, mert 'nem lehet hatekonyan futtatni'"
mert nem arra hasznaljak amire kene

"JS is the new assembly"
Erdekes... nem emlekeztem ra, hogy az assembly nyelvek hordozhatosaguk miatt lennenek hasznalatban... jah, varj... nem is!

A js-t meg mindig scriptelesre hasznaljak az emberek, nem tudom, ezzel mi a baj. Legalabbis en meg nem lattam enterprise szoftvert js-ben.
Kerlek mondj olyan scriptnyelvet, amit inkabb hasznalnal js helyett.
Az assembly-s analogiamat szerintem felreertetted (nyilvan nem nezted meg a linket, whatev').

"A js-t meg mindig scriptelesre hasznaljak az emberek, nem tudom, ezzel mi a baj. Legalabbis en meg nem lattam enterprise szoftvert js-ben."
Rengeteg web-es APP ami JS-re epul? Jatekok? Egesz GNOME-os kezdemenyezes? node.js?

"Kerlek mondj olyan scriptnyelvet, amit inkabb hasznalnal js helyett." (!)
Miert kene grafikus alkalmazasokat scriptnyelven fejleszteni? Ha arrol szolna a dolog, hogy (QT modra) levalasszak a GUI-t a program logikarol, akkor oke, de itt nem errol van szo.

"Az assembly-s analogiamat szerintem felreertetted"
Nem, nem ertettem felre. A hordozhatosaga miatt forditanak mas nyelveket JS-re, es nem azert mert amugy jo lenne. Ha jo lenne, akkor abban irnak a programokat. Az assembly nyelvek szerepe egeszen mas.

"(nyilvan nem nezted meg a linket, whatev')"
Nyilvan...

> Rengeteg web-es APP ami JS-re epul? Jatekok? Egesz GNOME-os kezdemenyezes? node.js?
Es az neked miert faj, ha valaki gyorsan akar valamit fejleszteni, es latszolag performance problemak sincsenek? Ez meg mindig nem a tobb szazezer soros kategoria. En is hasznalok node.js-t, de csak scriptekhez futtatokornyezetnek. Egyszeruen nem ertem, miert lenne szarabb, mint egy python/ruby ebbol a szempontbol.
> Miert kene grafikus alkalmazasokat scriptnyelven fejleszteni?
Akkor megis mit kene hasznalni? Meg mindig csak kisebb gui-s toolokrol van szo. Nem szamit a performance.

Az assembly-s analogiamat el kell magyaraznom, ezek szerint nem volt tul szerencses: egy nyelvre forditjak a programokat, es ez a JS a gepi kod helyett. A link mogott rengeteg nyelv van. Ha nem tetszik a "raw" JS, hasznalj mast. Csak ennyit akartam ezzel mondani.

"Es az neked miert faj, ha valaki gyorsan akar valamit fejleszteni, es latszolag performance problemak sincsenek?"
Szakmai oldalon vagyunk. Szakmai szempontbol nem szerencses az ilyen nyelvek tamogatasa. Igy szokott az lenni, hogy a gyors prototipus proof of concept-et eladjak mint kesz termek.

"Akkor megis mit kene hasznalni? Meg mindig csak kisebb gui-s toolokrol van szo. Nem szamit a performance."
NEM, a Gnome-rol van szo es abban az ajanlott nyelvrol. Aki kisebb toolokat csinal most egy nyelven, az kesobb nagyobbakat fog ugyanazon a nyelven.

"Az assembly-s analogiamat el kell magyaraznom, ezek szerint nem volt tul szerencses: egy nyelvre forditjak a programokat, es ez a JS a gepi kod helyett."
Neeeeeeeeeeee... komolyaaaaan? Akkor most olvass mar vissza egy picit es vedd eszre, hogy hibas az analogiad, mert egeszen mas okbol forditjak JS-re a kodot, mint amiert gepi kodra a tobbi nyelvet.

"A link mogott rengeteg nyelv van. Ha nem tetszik a "raw" JS, hasznalj mast. Csak ennyit akartam ezzel mondani."
nem ezt mondtad

"Szakmai szempontbol nem szerencses az ilyen nyelvek tamogatasa."
Milyen nyelvek? A type system a problema? Legyel egy kicsit konkretabb.

"Gnome-rol van szo es abban az ajanlott nyelvrol."
En nem gondolom ugy, hogy gnome userlandben lennenek komolyabb gui-s szoftverek akar most is, amikhez alkalmatlan lenne egy scriptnyelv.

"hibas az analogiad, mert egeszen mas okbol forditjak JS-re a kodot, mint amiert gepi kodra a tobbi nyelvet."
Nyilvan akkor nem vagy tisztaban az analogia definiciojaval. Valamilyen szempontbol egyezo. Es ez a szempont a sok nyelv, ami js-re (vo. gepi kodra) fordul. Sajnalom, hogy nem voltam eleg egyertelmu elsore, es hogy meg mindig ezen kell rugoznod.

"Milyen nyelvek? A type system a problema? Legyel egy kicsit konkretabb."(!)
Igen, alapvetoen az vele a baj, hogy dinamikus. Igen, ez egy nagyon hasznos dolog ha kicsi programokat kell irni amik igy is gyorsan lefutnak, azonban a GUI-s eszkozok altalanosan NEM ebbe a kategoriaba tartoznak. Itt jon elo a legjobban, hogy ha egy kicsit kesik valami akkor az egesz rendszer lassunak fog hatni.

"En nem gondolom ugy, hogy gnome userlandben lennenek komolyabb gui-s szoftverek akar most is, amikhez alkalmatlan lenne egy scriptnyelv."
En meg nem gondolom ugy, hogy ezeknek az eszkozoknek a fejlesztesehez szukseg lenne dinamikus nyelvre. A rendszerrel szallitott programoknak amugy is peldat kell allitaniuk a tobbi fejleszto ele.

"Nyilvan akkor nem vagy tisztaban az analogia definiciojaval."
Nyilvan.

"Valamilyen szempontbol egyezo."
A JavaScript az uj Common Lisp. Elvegre mind a ketto programnyelv...

"Sajnalom, hogy nem voltam eleg egyertelmu elsore, es hogy meg mindig ezen kell rugoznod."
De, nagyon is egyertelmu volt a szandekod elsore is, azonban meg mindig nem latod, hogy miert hibas a hasonlatod. JavaScript-re azert forditanak, hogy mukodjon azokon a platformokon amiken mar van JavaScript. Gepi kodra meg azert, hogy mukodjon azon az egy platformon. Ha a JavaScript feladata amolyan hordozhato assembly lenne, akkor egyszerubb lenne a nyelv is, es leginkabb nem ember szamara olvashato. Azonban nem ez a celja. Egy egyszeru, konnyen olvashato, interpretalt nyelv amire most rahuztak ezt a szerepet is az elterjedtsege miatt. Szokasos webes problema: nem akarnak ujat kitalalni, mert nem fog elterjedni ezert inkabb a regit hackelik olyan celokra amikre az nem valo.
szerk. amugy egeszen erdekes kritizalni mas "rugozasat" amikor te hoztal fel valamit amit meg mindig vedened kell...

"Itt jon elo a legjobban, hogy ha egy kicsit kesik valami akkor az egesz rendszer lassunak fog hatni."
Ket gui-s szoftvert hasznalok. Az egyik (emacs) nagyobb reszet (>1M LOC) elisp-ben irtak, ami tortenetesen egy dinamikus nyelv. Az en szememben ezek utan megbukott a teoriad, miszerint hasznalhatatlan egy dinamikus nyelv gui-s szoftver fejlesztesere.
(szerk: sot, az ablakkezelomet is egy dinamikus nyelvben irtak)

Es a hasonlatom igenis helyes egy bizonyos aspektusbol. Abban teljesen igazad van, hogy mas a szandek es a megvalositas is, soha nem allitottam az ellenkezojet. Reszemrol befejeztem a beszelgetesunk ezen reszet, mert folosleges koroket jarunk.

Te, szerintem nezz utana az analogia szo jelentesenek.

A "JavaScript is the new assembly" egy tokeletes analogia. Teljesen mindegy es lenyegtelen, hogy *miert* forditanak JS-re. Annak a tenye, hogy kismillio cucc van, ami JS-re fordul, kielegiti az analogiat. Ez az egy dolog. Minden mas amirol beszelsz, teljesen irrelevans.

--
|8]

Jó kérdés, hogy mit értünk performance alatt. Egy átlag GUI-s programnál pl. sokkal fontosabb, hogy ne fagyjon
le a GUI (idióta módra gui thread-ből indított hosszú ideig tartó művelet), és jó legyen a válaszidő, ha valami
hosszú ideig tart, attól függetlenül tovább is lehessen dolgozni, illetve hogy az egész alkalmazás atomstabilan
fusson. Inkább várok egy kicsit a programra, de az csinálja meg a dolgát rendesen, mint legyen egy program, ami
minden 2. műveletnél összef@ssa magát, és szétakasztja a rendszert.

van ahol számít a performance, van ahol nem. Csomó gui alkalmazásban a runtime nagyrésze várakozás user interakcióra, akkor meg nem mindegy? Nyilván hülyeség lenne nagy számításigényű feladatokat js-ben írni, de az is hülyeség ha nem használjuk ki a dinamikus nyelvek adta előnyöket csak mert...

"Kerlek mondj olyan scriptnyelvet, amit inkabb hasznalnal js helyett."

Ott kezdodik a problema, hogy egyaltalan mi a halalert kellene scriptnyelvet hasznalni?

(Masik, hogy miert pont egy gyengen tipusos szart... Nem veletlen az sem, hogy az Unity3D tartalmaz tipusossagra vonatkozo bovitmenyt majd a legvegen az egeszet mono-ra forditja...)

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

"miert pont egy gyengen tipusos szart"
Ha statically typed language-re van szukseged, akkor valaszthatsz pl. Haxe-ot (szinten type inference-t hasznal, mint a felhozott UnityScript vagy Boo), ami JS-re is fordul. Raadasul a mono/V8 kozotti performance kulonbseg elhanyagolhato szerintem (http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang…), ha a peldadnal maradunk.
szerk: sot, a memory footprint is egy szempont desktop-nal, ami alapjan a JS jobb valasztasnak tunik.

Szerintem nem számít, hogy milyen prognyelven írnak valamit, úgy is ott dől el minden, hogy a compiler/interpreter mit csinál belőle. Vajon a gnome-ban a js-t mi fogja futtatni/fordítani? Ha hatékony compilert/interpretert csináltak hozzá, akkor miért ne használhatnák?
De lehetne akár object pascal is, perl, sh, vagy akármi... gondolom azért döntöttek a js mellett, mert a legtöbb gnome fejlesztő ezt a nyelvet ismeri a legjobban.
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

"Ha hatékony compilert/interpretert csináltak hozzá, akkor miért ne használhatnák?"

Ha kellene hozzá compiler, akkor minek a high level nyelv ha ugysem használják programozni, csupán köztes rétegnek? Akkor már miért ne fordítanánk egy másik nyelvről inkább C-re, majd arról gépikódra (vagy egyből gépikódra)? Ha ez lenne a feltétele a használhatóságának, akkor saját célját hazudtolná meg.

"Szerintem nem számít, hogy milyen prognyelven írnak valamit, úgy is ott dől el minden, hogy a compiler/interpreter mit csinál belőle."

Az viszont, hogy a compiler/interpreter mit képes csinálni belőle az erősen függ a nyelvtől.

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

Vala? Python?

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

A vala nem dinamikus nyelv, hanem C kodot generalo ize. Tok jo az meg minden, de ha valami scriptelhetoseget akarsz az alkalmazasba, akkor nem a legjobb valasztas.

A python nem lenne rossz, de a platform egy jelentos resze (pl gnome-shell) mar js. A js nagy elonye meg pythonnal szemben, hogy van jopar olyan cucc, ami js-re fordul (coffeescript, clojurescript, stb), igy a nyelv otrombasagait jol el lehet rejteni. Cserebe ott van alatta a V8, ami egy igen jo kis cucc.

--
|8]

Püff neki! Kezdhetek JS-t tanulni.
Már kezdtem megszokni a Python-t, amit pont azért választottam, mert szkriptelni is jó, meg GUI-t is könnyű benne összarakni, ráadásul a GUI-k több platformon is ugyanúgy néznek ki (pl. wxPython).

Használ itt valaki JS-hez valami cross-platform GUI-t?

Rosszabb nyelvet nem tudtak választani? :-/

És azt se felejtsük el, ha azt akarták, hogy minél többen foglalkozzanak ilyen jellegő fejlesztéssel célszerű volt olyan nyelvet választani, amit már most is tömegek ismernek (a tömeg átlagos nyelvismeretéről most ne nyissunk vitát) mondjuk egy Vala vagy Lips-hez képest.
-
Reflection - a bajkeverő csodagyerek

Mondjuk ez nem csak ide, de tök mindegy milyen nyelvet választanak, nem fog mindenkinek megfelelni. Valaki szerint szar, valaki szerint jó, valaki szerint inkább fordítós nyelv, valaki szerint inkább interpretált nyelv kellene. Bár ha jól látom elsődlegesnek lett kinevezve, tehát mindenki olyan nyelven éli ki perverzióit amilyenen akarja. Meg persze amit támogatnak...

"Belépés díjtalan, kilépés bizonytalan."

Persze, olyan nyelven éli ki, amin akarja. Aztán meg majd jön a kérdés, hogy miért foglal 4x annyi ramot egy szimpla printer applet, mint amennyit régen egy egész operációs rendszer.

http://hup.hu/node/101236

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

Amikor a Qt előjött a Qt Declarative, QML ötleteivel, akkor estem gondolkodóba nagyon, hogy hmm.... Végre vége, nem azon kell maszturbálkodni, hogy GUI C++-ban húdejó, hanem deklaratív módon lehet GUI-t építeni, gyorsan megszkinezni, az alacsonyszintű (de nem az ismétlődő!*) műveletekhez pedig villámgyorsan C++ kódot bindelni. Egyszerűbb, GUI logikát meg lehet JS-ben kódolni. Nagyszerű, arra fordíthatod az idődet, hogy a célod elérd, nem pedig az ahhoz vezető út építgetésével,karbantartásával.

Örülök, hogy végül a Gnome-nál is erre mozdultak el; Maga a nyelv amúgy nem annyira rossz, mint amennyire úgy használják a phppistikékkel versenyző jspistikék.

*: Pl. egy fájldialógus feldobása egyéb, esetleg rendszer-libekbe történő hívást jelent, mégis kb. minden alkalmazásban van, tehát azt is el lehet absztrahálni, feljebbnyomni.

Maga a nyelv amúgy nem annyira rossz, mint amennyire úgy használják a phppistikékkel versenyző jspistikék.

Ezzel nagyon nem értek egyet, a JavaScript sajnos egy vacak nyelv. Nincsenek konstansok, nincs modulkezelés, sem statikus adattagok, és lehetne még sorolni a hiányosságait.

Amúgy a Microsoft összehozott egy használható JS-kompatibilis nyelvet TypeScript néven, amely lefordítható egyszerű JS-re. De ha ilyen módszerekkel kell elfedni a nyelv hiányosságait, az elég rossz.

> Ezzel nagyon nem értek egyet, a JavaScript sajnos egy vacak nyelv. Nincsenek konstansok, nincs modulkezelés, sem statikus adattagok, és lehetne még sorolni a hiányosságait.
Semmi baj, azért vagyunk itt HUP-on egymásnak, hogy bővítsük és frissen tartsuk a tudásunkat :-)
Szóval majdnem igaz, amit írsz, viszont a Gnome nem a browserekben megszokott elavult, kompatibilitást biztosító JS runtime-ot használ, hanem (asszem) GJS-t/rhino-t/v8-at.

Szóval vannak konstansok és modulkezelés, lásd itt: https://live.gnome.org/GnomeShell/Gjs_StyleGuide
(Ugyanitt látható, hogy van a nem teljes scope-ra érvényes változó deklaráció is, let kulcsszóval (végre))

Szerk: Statikus adattagok... Igen, ez az OO-ban megszokott, egy prototípus-alapú nyelvben mégis megkérdezném, pontosan mit értünk statikus adattag alatt? Ha egy függvénydefiníciót osztálydefiníciónak tekintünk, akkor a Fv. objektumhoz lehet adattagot rendelni, amit "statikus"-nak érzékelhetünk. Itt egy válaszoló nagyjából azt írja le, amire én is gondoltam: http://stackoverflow.com/a/1535687

Amúgymeg: https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Statement…

TypeScriptet néztem a bevezetésénél, akkor tetszett. Van még CoffeScript, stb. amik natív js-t generálnak; igen, tényleg nem a legszebb megoldás, picit emlékeztet a Qt-féle qmake-es játékra, hogy a Signal-Slot-ozás menjen.

Szóval vannak konstansok és modulkezelés, lásd itt: https://live.gnome.org/GnomeShell/Gjs_StyleGuide

Ez jó, de lehetséges mondjuk egy függvény vagy változó láthatóságát az adott modul szintjére korlátozni?

A másik dolog ami érdekelne: ha van egy osztályom (függvényem, ami lényegében egy osztályt reprezentál) el tudom érni azt hogy az adott osztály ne legyen módosítható? Tehát ne lehessen hozzáadni új metódusokat, a régieket felülírni, ...

A modul szintre korlátozásra konvenció a pl. jQueryben is alkalmazott scope-ing: (function(){ /* ... */ }) és ami a zárójelen belül van, azt nem fogja látni az az entitás, amely a modult importálja/include-olja.

A másik kérdésre a válasz: ... Hm... eleve a kérdésben levő állítással van a gond: JS-ben a függvényed nem reprezentál osztályt, az egy fv. objektumot, prototípust reprezentál. Sok OO-t használó programozó (ahogy eleinte én is) ilyenkor nem tud elszakadni az osztályok,memberek,öröklődés,láthatóság absztrakciójától.

Szóval a fv objektumról nem mondhatod meg, hogy ne legyen módosítható, mindig fogsz tudni egy kulcshoz (másik) objektumot rendelni, és így "tagfüggvényt" is felülírhatsz. És igen, finalitás sem létezik. Mint ahogyan pl. C++-ban sem.

A JS prototípus-alapú OO-t tesz lehetővé. Szóval igen, más ez a nyelv. Pure FP nyelvekben meg egyáltalán nincs állapot. Akkor azok a nyelvek rosszak?

Nem. Csak mások.

Az, hogy néhányan nem tudnak elvonatkoztatni az addigi tudásuktól, az nem egy nyelvet minősít.
Viszont az, hogy egy alapvetően C-s beállítottságú fejlesztői rétegnek azt mondani, hogy mostantól JS-ben érdemes fejleszteni, na az sem a nyelvet, hanem a döntéshozókat minősíti :-) Én még nem döntöttem el magamban, hogy ez jó-e vagy rossz, a menedzselt nyelvek irányát alapvetően jónak tartom.

"sem statikus adattagok"
Mivel alapvetően nem OOP nyelv, hanem inkább funkcionális.
Nincs is értelme annak a fogalomnak, hogy adattag, pláne nem annak, hogy statikus adattag.

Ha objektumorientált nyelven akarsz webalkalmazást írni, akkor GWT vagy dash. Micsoda véletlen, mind a kettő Google találmány :)

Hát, legalábbis ActionScriptnél lehetett látni, hogy ami anno scriptelgetésre, pár soros animáció vezérlésekre/interaktivitásra még oké volt, az már nagyon nem felelt meg az alkalmazásfejlesztés egészen másfajta követelményeinek. Ezért aztán jött az ActionScript3 és lett boldogság és átlátható, konzisztens kódbázis, alaposztályok, stb, amivel már öröm fejleszteni.

Azt megértem, hogy van egy bizonyos szint (kódsor és fejlesztőszám) ami felett pl egy típusos nyelv vagy egységbezárás nélkül elképzelhetetlen a fejlesztést normális keretek között tartani, de egyfelöl itt kis mütyűrökről beszélünk, a DE-be épülő mindenféle cuccról, amik lehet, hogy csak egy funkciót látnak el, másfelöl nem kötelező, csak ajánlott alternatíva. Szóval aki nem csak egy email fiók ellenőrzőt akar fejleszteni hanem valami komolyabb cuccot, még minden választhat olyan nyelvet, ami alkalmas(abb) rá. Persze nem lesz annyi doksi meg tutorial meg példa hozá, mivel a JS-re öszpontosítják ezeket a dolgokat, de arra meg ott lesz a közösség.
-
Reflection - a bajkeverő csodagyerek

" egyfelöl itt kis mütyűrökről beszélünk, a DE-be épülő mindenféle cuccról"
Nem, hanem _minden_ GNOME alkalmazásról, legyen az képnézegető, zenelejátszó vagy bármi. A GNOME alkalmazásokat _ajánlott_ JS-ben írni, nem a Metacity plugineket vagy a Nautilus kiegészítőit. Minden GNOME alkalmazást.

Akkor már csak egy használható, összeszedett referenciát kéne írni, ledokumentálni az API-t. Pár hónapja a poén kedvéért kigondoltam, hogy csinálok egy plugint (már nem emlékszem, mi volt a funkció, valahol a HUP-on tetten érhető). Aztán olvasgattam a doksit és arra jutottam, hogy az alapján összerakni egy alkalmazást nem lehet. Vannak a neten különböző tutorialok, azokban elejtett hívásokat a doksiban nem lehet megtalálni, mert nincs leírva.
Tök jó, hogy a nyelvben végre megállapodtak, így talán lesz is valami "papír" és nem csak a fejlesztéseket közelebbről követők tudnak majd hasznos kiegészítőket készíteni.

Ezek a gnome fejlesztők egyre jobban erőlködnek, hogy hülyének nézzék őket. Elolvastam a kommentek egy jó részét, és nem sikerült meggyőző érveket sorakoztatni a js mellett.
----
India delenda est.
Hülye pelikán

Akkor olvasd el az eredeti cikket, es probalj talalni megegy nyelvet ami teljesiti a kovetelmenyeket, vagy mondj jo okot, hogy miert hulyeseg az adott kovetelmeny.

(En nem talaltam mas nyelvet, ami megfelelt volna a kovetelmenyeknek, es a kovetelmenyek is mind olyanok, amikkel egyet tudok erteni, megvan mogottuk a racio)

--
|8]

"Our language of choice needs to be dynamic and high level."
A dinamikusság követelménye szerintem hülyeség.

Statikus nyelveken sokkal stabilabb programok készíthetők.

Ha azt írják, hogy az egyes gnome-os programokat lehessen bővíteni javascript-es pluginokkal, és annak kialakítják a módját, akár támogatást is adnak az alapkönyvtárakban hozzá, akkor azt elfogadom, mert arra megfelelhet.

> A dinamikusság követelménye szerintem hülyeség.
> Statikus nyelveken sokkal stabilabb programok készíthetők.

Ellenben a statikus nyelvekben irt programok tipikusan nehezen bovithetoek.

> Ha azt írják, hogy az egyes gnome-os programokat lehessen bővíteni javascript-es pluginokkal, és annak kialakítják a módját, akár támogatást is adnak az alapkönyvtárakban hozzá, akkor azt elfogadom, mert arra megfelelhet.

gnome-shell eseteben ez megtortent, nem latom be, hogy miert tennenek maskepp barmi mas JS alkalmazas eseteben. Tamogatas egyebkent nagyjabol a teljes GNOME platformhoz letezik, a Gjs altal, stb.

--
|8]

Akkor a követelményekhez ezt kellett volna írni, hogy könnyen bővíthető legyen.
Sok olyan statikus programnyelv van, amelyen írt programok könnyen bővíthetők, pl. a kedvencem a Scala.

Alább írod a Firefox-ot. Pont ilyenre gondolok én is. Erősen típusos nyelven van írva a magja (C++) és arra épül rá a XUL.
Számomra a Vala, C++ (Qt) is sokkal elfogadhatóbb lenne javasolt alap nyelvnek.

Majd az élet eldönti, hogy mi lesz a JS megközelítéssel. :)

A GNOME is hasonlo: GTK+, glib, dbus, mindenfele egyeb lib, a core egy jelentos resze: C. Es erre epul a JS-ben irt dolog. Picit tobb a JS-ben epitett resz, mint FireFox eseten talan, de az elkepzeles nagyon hasonlo.

Ugyanilyen elkepzeles volt az Emacs mogott, es ott csodalatosan bevalt.

--
|8]

> Kérdés, a kívánt követelmények valóban szükségesek-e

Igen, ez egy jobb kerdes, mint az, hogy a JS megfelel-e (nyilvan igen). En tobbszor rakerdeztem mar e szalban, hogy valaki ra tud-e cafolni barmelyik kovetelmenyre, eleddig nem sok ervet lattam egyik ellen sem, amely megallta volna a helyet. (Mas forumon sem, egyebkent.)

Vannak jo ervek a JS ellen, nem is keves, de egyik sem relevans ebben a helyzetben.

--
|8]

Én örülök a hírnek, azt gondolom, hogy a JS már kinőtte a korlátait, és kezd átalakulni, minden átalakulás nehéz, macerás, és természetesen sokaknak nem tetszik, de a dolog terjed, és működik. Használják és egyre több helyen bukkan fel, egyre több területen. Nyilván már rég más szempontok irányítják ezeket a dolgokat, mint amiket régen fontosnak tartottak. Ettől ez az egész még nem biztos, hogy bukásra van ítélve, sőt! :)

________________________________
blog: http://horvathjanos.wordpress.com

Nem tudom, hogy mi bajotok, és miért ilyen rosszindulatú itt mindenki mostanában.
Az, hogy szubjektív véleményeteket leírjátok és szidtok egy egy nyelvet, attól még az nem lesz egyszerűen "sz@r".
Ha olyan sz@r lenne, akkor nem lenne ennyire népszerű és jól működő. Mindennek megvan a helye a PHP-nek a szerveroldalon a helye és a Web területén, oda való nem máshová, de oda nagyon is jó.

A JS már más tészta, már túlnőtte magát a böngészőn! Lehet morogni, fujjolni de ez van, fejlődik és átalakul, és egyre jobb. Nem C nyelv, és nem is C++ de nem is Java, nem is Python, de nem is kell hogy az legyen. Én értem és érzem, hogy mi történik a JS világgal és hogy hová tart, te is érted és érzed, vagy átgondoltad, vagy csak elzárkózol, mert neked szubjektíve anno nem jött be mikor használnod kellett!?

________________________________
blog: http://horvathjanos.wordpress.com

Ha szubjektivitás helyett érvelés és példákkal való alátámasztás kell a PHP következetlenségére, ellentmondásosságára, a fejlesztői inkompetenciájára, akkor fusd végig ezt:

http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

Akár pontról pontra is végigolvasatód, vagy csak szúrópróbaszerűen beleolvashatsz, hogy lásd, miből is adódik az átgondolatlansága.

Ilyen hasonló listát bármely programnyelvre lehet írni, ezt beláthatod. Ráadásul a PHP inkább szkriptnyelv mint programnyelv. Tisztában vagyok vele, hogy vannak hibái, de nem lehet rá mondani, hogy simán "sz@r". Különben is, mi van helyette? .NET? Nem igazán terjedt el, és erősen MS kötődésű, sosem lesz vezető Webes szerveroldali nyelv. Van más helyette? Jobb? .... nincs.
Ezt használjuk és örülünk, ha jön egy egy új verzió, és javítások, és újítások, ennyi erővel minden nyelv sz@r, mert vannak hibái.

________________________________
blog: http://horvathjanos.wordpress.com

"Van más helyette? Jobb? .... nincs."

Java, Python, Ruby és még csillió másik nyelv, amivel lehet webre fejleszteni. (Bár utóbbi kettőt én sem használnám).

Van egy kb. 4,5 éve fejlesztett PHP-s rendszer (átlagosan 500kloc, totálban szerintem belement már 1-1,3M is. Időnként azért kerülnek ki is belőle dolgok), ha most kezdeném vagy Java vagy .NET lenne. Windows licenc elenyésző tétel lenne a teljes költségre nézve.

"Ilyen hasonló listát bármely programnyelvre lehet írni,"

Nono... azért a legtöbb nyelvben nincs ennyi ordenáré gyökérség, pl. hogy az == sem tranziens. Egy C++ esetén elhiszem, hogy mennyiségre összedobol egy ennél hosszabb listát, de ott inkább azért, mert maga a C++ nyelv is sokkal-sokkal többet nyújt.

"Ráadásul a PHP inkább szkriptnyelv mint programnyelv. "

Egy picit túlnőtte magát azóta, hogy lekoppintotta a Java OOP-ját szinte teljesen és bővítette még ezzel azzal. (Closure, trait, stb.)

".NET? Nem igazán terjedt el"

Publik neten itthon valóban, üzleti világban viszont találkozok bőven ASP.NET-es webserviceal.

"Ezt használjuk és örülünk, ha jön egy egy új verzió, és javítások, és újítások"

Csak a régi mocsok naaaaaaaagyon lassan tűnik el.

PHP-ban az egyetlen jó, hogy könnyű benne elindulni. PHP-ban ugyanez a rossz.

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

"Van más helyette? Jobb? .... nincs."

"Java, Python, Ruby és még csillió másik nyelv, amivel lehet webre fejleszteni. (Bár utóbbi kettőt én sem használnám)."

Igen értem, de Java webre olyan mint ágyúval verébre, ha nem nagyvállalati kritikus és óriásrendszerről van szó, hanem csak egy webshopról, vagy mezei honlapról, átlagos usernek alkalmazásról.

"Van egy kb. 4,5 éve fejlesztett PHP-s rendszer (átlagosan 500kloc, totálban szerintem belement már 1-1,3M is. Időnként azért kerülnek ki is belőle dolgok), ha most kezdeném vagy Java vagy .NET lenne. Windows licenc elenyésző tétel lenne a teljes költségre nézve."

Ez egy adott példa, és egy adott rendszer, gondolom nem volt tervezés, hanem nőtt mint a gomba, ez nem a PHP hibája, de nem akarom a munkádat megítélni, mert nem tudom, hogy hogy történt anno a kezdete.

"Ilyen hasonló listát bármely programnyelvre lehet írni,"

"Nono... azért a legtöbb nyelvben nincs ennyi ordenáré gyökérség, pl. hogy az == sem tranziens. Egy C++ esetén elhiszem, hogy mennyiségre összedobol egy ennél hosszabb listát, de ott inkább azért, mert maga a C++ nyelv is sokkal-sokkal többet nyújt."

A PHP mint már mondtam eléggé szkriptelésre szánt nyelvként indult, még mindig gyerek cipőben jár ahhoz, hogy "rendes programnyelvenk nyelvnek" hívjuk, és vannak olyan gyerekbetegségei/hibái mint az, "hogy az == sem tranziens". Számos ilyen van igen, de majd kijavítják (remélem), általában javulást mutat a projekt.
Ahogy mondtam más egy szkriptnyelv fejlődése és más egy robusztus alacsonyabb szintű nyelv fejlődése, más a célja az egésznek, így más más hiba számít kritikusnak, és más ütemben is javítják azt.

"Ráadásul a PHP inkább szkriptnyelv mint programnyelv. "

"Egy picit túlnőtte magát azóta, hogy lekoppintotta a Java OOP-ját szinte teljesen és bővítette még ezzel azzal. (Closure, trait, stb.)"

Túlnőtte magát, de ez nem baj, attól még senki nem állítja róla, hogy nem szkript nyelv. Az Action Script is hogy átalakult és milyen fejlődésen ment át, megcsinálták benne rendesen az objektumorientáltságot és az osztályokat mindent, nem úgy mint pl. sima JS-ben van "objektum orientáltság", de ettől még az AS is csak szkriptnyelv maradt.
A lekoppintás meg ebben a szakmában értelmetlen szó, ezt te is jól tudod.

".NET? Nem igazán terjedt el"

"Publik neten itthon valóban, üzleti világban viszont találkozok bőven ASP.NET-es webserviceal."

Publik neten sem itthon sem külföldön nem a legelterjedtebb, nem a leginkább használt.
Üzleti világban van ASP .NET igen, de ettől még azt is lehet rosszul használni meg a PHP-t is.
Külföldön weben inkább Rails-t lát az ember PHP alternatívaként.

"Ezt használjuk és örülünk, ha jön egy egy új verzió, és javítások, és újítások"

"Csak a régi mocsok naaaaaaaagyon lassan tűnik el."

+1 lassan de azért most talán van remény gyorsulásra! :)

"PHP-ban az egyetlen jó, hogy könnyű benne elindulni. PHP-ban ugyanez a rossz."

+1 ez így van! :)

________________________________
blog: http://horvathjanos.wordpress.com

- Erős típusosság hiánya
- PHP bugok közül nem egyszer több napos szívás
- Háttérfolyamatok esetén (amelyből nálunk nem kevés) multithreading hiánya.
- Egyes feladatokra lassú. (Van kb. 4000 sor C++ és néhányezer sor .NET/mono kód mögötte.
- SOAP támogatás a PHP-ben finoman szólva fos.
- Régi időkben nem keveset kellett nagy excel táblákat feldolgozni (szerencsére ez az időszak elmúlt), erre a PHP alkalmatlan csak ordenálé trükkökkel. (Volt olyan folyamat, amely 10 percig futott, részekre kellett bontani és ajax poolinggal szívni.
- Csomószor kell plusz kódot tenni olyan ellenőrzések miatt, amelyekre Java/C# esetén semmi szükség nem lenne, hiszen maga a fordító kiszűrné a felét.
- Alkalmazásszerver hiánya. Van egy valag memóriánk szabadon, simán berántanék oda egy valagnyi adatot ahelyett, hogy adatbázisból húznám ki folyton.

Csak néhány nagyobb témakör. Természetesen a nagyját megoldottuk így vagy úgy de nem mondom, hogy minden megoldással elégedett vagyok.

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

- Erős típusosság hiánya

Ez nem hiány/hiba ez feature! :) Na de tényleg, nem típusos, nem típusos, ennek megfelelően kell írni benne a kódot, van akinek ez jó és van akinek nem.

- PHP bugok közül nem egyszer több napos szívás

Ezt csak általában 1x kell végigcsinálnia minden PHP fejlesztőnek, utána köv. projektnél már tudja mit lehet mit nem és hogyan. Azért nem jönnek a bugok verzióváltásonként, hanem inkább mennek.

- Háttérfolyamatok esetén (amelyből nálunk nem kevés) multithreading hiánya.

Jó, hát többszálúságot nem tud, de nem is várhatjuk el egy szkriptnyelvtől, majd egyszer vagy bele teszik vagy nem.
Nyilván ilyen problémára más nyelv való, vagy más megoldás.

- Egyes feladatokra lassú. (Van kb. 4000 sor C++ és néhányezer sor .NET/mono kód mögötte.

Világos, itt is ugyanaz, nem ultimate programnyelv, mindent nem lehet, valamit valamiért. Ha lassú kell más ami gyorsabb, ez minden esetben így van, nem csak itt.

- SOAP támogatás a PHP-ben finoman szólva fos.

Ezt elismerem, de ez csak egy módja a kommunikációnak, nyilván elég elterjedt módja sok helyen, és biztos sokaknak hiányzik egy jó SOAP támogatás (nekem speciel nem), vagy lesz vagy nem, ha SOAP kell, akkor ott a Java erre.

- Régi időkben nem keveset kellett nagy excel táblákat feldolgozni (szerencsére ez az időszak elmúlt), erre a PHP alkalmatlan csak ordenálé trükkökkel. (Volt olyan folyamat, amely 10 percig futott, részekre kellett bontani és ajax poolinggal szívni.

Ez is problémafüggő, ráadásul excel tábla != CSV, nem tudom pontosan most mire gondoltál. Ha tényleg olyan méretűek azok a táblák akkor ahhoz megint valami nagyon alacsony szintű megoldás kell és csak aztán PHP, mert mindent a PHP sem tudhat.
Nem értem amúgy a problémát, szerveroldalról érkezett a nagy excel tábla adat a kliensoldalra és belökted HTML-ként a DOM-ba? Na de gondolom nem egy az egyben, hanem volt lapozás miegymás, akkor meg mi volt a lassú? Ajax mindenképpen kell, ha nem akarunk oldalfrissítést de ezen kívül semmi köze a PHP sebességéhez... vagy én értek félre valamit.

- Csomószor kell plusz kódot tenni olyan ellenőrzések miatt, amelyekre Java/C# esetén semmi szükség nem lenne, hiszen maga a fordító kiszűrné a felét.

Ez is olyan dolog, hogy használj egy framework-ot ami elvégez helyetted dolgokat, és ne írj natív kódot mert a végén felvágod az ereidet. Nem értem pontosan milyen ellenőrzések hiánya volt a gond, de majd elmeséled ha szeretnéd.

- Alkalmazásszerver hiánya. Van egy valag memóriánk szabadon, simán berántanék oda egy valagnyi adatot ahelyett, hogy adatbázisból húznám ki folyton.

Erre most mit mondjak? Biztos van ilyen problémakör az életben, én még ilyennel nem találkoztam, de elhiszem, hogy lehetne ezzel optimalizálni és nem DB kéréseket indítani.

Csak néhány nagyobb témakör. Természetesen a nagyját megoldottuk így vagy úgy de nem mondom, hogy minden megoldással elégedett vagyok.

Ezt csak te/ti tudod/tudjátok én nem nagyon szívtam még PHP-vel pedig voltak elég változatos problémakörök és alkalmazások amiket meg kellett valósítani.
Eleve FW-el indul minden projekt, anélkül nem dolgoztam csak nagyon régen.
Nativ PHP kódot nem írok, és DB-t sem buzerálok valamilyen ORM nélkül.

Na de ízlések és pofonok. :)

________________________________
blog: http://horvathjanos.wordpress.com

"Ez nem hiány/hiba ez feature! :) "

Na ne. Amikor egy valag ellenőrzést kell tenni az inputra ahelyett, hogy dolgoznék végig egyértelmű típusokkal... KTHXNOT.

"Ezt csak általában 1x kell végigcsinálnia minden PHP fejlesztőnek"

Na de olyan szopás egy normális nyelven nem fordul elő, hogy egyik platformon 32 bites signed intet, másik platformon 64 bites signed intet ad vissza a crc32() függvény. 7 éves bug, aztán lezárják egy "not a bug" felkiáltással. Nonszensz.

"Jó, hát többszálúságot nem tud, de nem is várhatjuk el egy szkriptnyelvtől, majd egyszer vagy bele teszik vagy nem."

Máshol érdekes módon meg tudták oldani.

"Ezt elismerem, de ez csak egy módja a kommunikációnak"

Finoman fogalmazva baszhatom, hogy nem csak egy módja, ha ipari standard és csillió helyen használják, amely rendszerekkel nekem kommunikálnom kell. Arról nem is beszélve, hogy jól használva kb. pikk-pakk lehet használni egy normális nyelvben, ami elkészíti a proxy osztályokat.

"Nem értem amúgy a problémát, szerveroldalról érkezett a nagy excel tábla adat a kliensoldalra és belökted HTML-ként a DOM-ba? "

Userek töltögettek fel több, hosszabb-rövidebb 1K..20K elemes listákat, amelyeket be kellett dolgozni majd ezeket az adatokat feldolgozni adatbázisba.

"én még ilyennel nem találkoztam,"

Pedig ez is "csak egy webshop". Csak egy picit nagyobb itthoni viszonylatban.

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

Na igen, viszont úgy nem lehet fejleszteni, hogy az int típus adott architektúrán 32 bit,
máson 16, a negyediken 64. Vagy hát lehet, de a vége úgyis az lesz, hogy inkább megmondod,
hogy te most x bites int-tel akarsz dolgozni, innentől kezdve a compiler majd jól kioptimalizálja
nem tűnik akkora nyereségnek, mint a hibás kód miatti veszteség.

Vagyis itt egy rakás probléma, amiket többé-kevésbé elismersz, némelyikre azt mondva, hogy ilyen feladatot nem php-val kell megoldani. Kérdem én, ezek után mi szól a php mellett? Miért használjak php-t, ha tökéletesen kiváltható más nyelvekkel, és megkímélem magamat a php-s problémáktól?

"Eleve FW-el indul minden projekt, anélkül nem dolgoztam csak nagyon régen."

Frameworköknek egyik feladata, hogy elfedjék a php hiányosságait, hibáit. Nyilván nem fogsz belefutni azokba a hibákba, amiket egy réteggel lejjebb fednek el előled.

"Vagyis itt egy rakás probléma, amiket többé-kevésbé elismersz, némelyikre azt mondva, hogy ilyen feladatot nem php-val kell megoldani. Kérdem én, ezek után mi szól a php mellett? Miért használjak php-t, ha tökéletesen kiváltható más nyelvekkel, és megkímélem magamat a php-s problémáktól?"

Nem kell használnod, jobb is ha nem használod, mert csak szidod, akkor meg minek? Nekem jó és kismillió más PHP fejlesztőnek és ügyfeleinek jó, és remek dolgokat készítünk benne. Neked nem kell, te írhatsz másban is kódot, van elég nyelv, senki nem tart vissza.

Ha kicsit népszerűbb lenne a Ruby (on Rails) itt az országban és Európában, vagy kicsit nagyobb támogatottsága lenne, és csakis rajtam múlna a döntés, akkor én sem PHP-ben írnám a szerveroldali kódjaimat, de most ez van, és nem gondolom fosnak, szerintem jól használható, csak oda kell figyelni, nem vakon megbízni a nyelvben (más nyelvekben sem) és tesztelni a kódot, minden eshetőségre, minél több szempontból, és kész.

"Eleve FW-el indul minden projekt, anélkül nem dolgoztam csak nagyon régen."

"Frameworköknek egyik feladata, hogy elfedjék a php hiányosságait, hibáit. Nyilván nem fogsz belefutni azokba a hibákba, amiket egy réteggel lejjebb fednek el előled."

Igen egyik feladatuk ez, de a fő feladatuk mégsem ez, hanem hogy kiterjesszék az adott nyelvet és az eszközkészletét (pl. MVC, DB ORM-ek, stb.), könnyítsék a munkát, és az áttekinthetőbb logikusabb kódírást támogassák.

pl. Java alá is írnak kismillió lib-et mert állandóan kell valami új vagy más hozzá. Ettől még nem mondom, hogy hiányos és sz@r nyelv.

Na de nem akarok én meggyőzni senkit! Mindenki használja azt amit szeretne, és amiben jól tud dolgozni.
Azt senkinek nem kívánom, hogy olyan nyelvben kódoljon amit utál, vagy nem tetszik neki.

Ami meg a fő témát illeti, mármint a Gnome JS dolgot, ne felejtsük el, hogy megmarad a lehetőség mindenre ahogy eddig volt, és különben is...

For system libraries the language of choice is still C.

________________________________
blog: http://horvathjanos.wordpress.com

A probléma szerintem alapvetően nem a nyelvben van (ettől még a PHP tele van szeméttel), hanem hogy egy adott feladatot milyen nyelvben
érdemes/optimális megoldani. Kis weboldalakhoz, átlag 27. webshop-hoz tökéletesen alkalmas php framework + custom kód. Java/python/ruby-t akkor sem
lehetne használni, ha akarnánk, mert a legtöbb cég csak olcsótárhely-en hajlandó futtatni a kódjait, ott meg php+mysql van, azt annyi.

Van aztán egy csomó eset, amikor php-ban nekiállni teljesen értelmetlen és butaság, ilyenkor jön elő a java/dotnet környezet. A mérnök feladata
az, hogy meg tudja határozni, hogy egy adott feladat megoldásához milyen eszközt vet be.

"Ami meg a fő témát illeti, mármint a Gnome JS dolgot, ne felejtsük el, hogy megmarad a lehetőség mindenre ahogy eddig volt, és különben is..."

Az a baj, hogy nagyon fájdalmas tapasztalataim vannak az ilyen "meg van a lehetőség" című sztorikra, mivel anélkül, hogy egy csomó erőforrást elpazarolnánk és csillió réteggel elfednénk az egyes nyelvek közötti különbséget nem kivitelezhető.

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

"Nem kell használnod, jobb is ha nem használod, mert csak szidod, akkor meg minek?"

Nem szidtam a php-t, legalábbis szerintem valós, konkrét projektben felmerült problémákat a php problémáinak nevezni nem az. (Ha már itt tartunk, te viszont szidtál más nyelveket, mindeközben pedig objektívnek tartod magad, hogy is van ez?)

Továbbra sem kaptam tőled választ arra a kérdésre, hogy mik az előnyei a php-nak a többi alternatívával szemben. Sz332 hozott 1 érvet, a tárhelyek a php-t támogatják. Ilyesmiket szerettem volna olvasni.

> Igen értem, de Java webre olyan mint ágyúval verébre, ha nem nagyvállalati kritikus és óriásrendszerről van szó, hanem csak egy webshopról, vagy mezei honlapról, átlagos usernek alkalmazásról.

Kerem lepjen hatrebb a szamitogeptol, es soha tobbet ne fogjon billentyuzetet a kezebe. Koszonjuk.

--
|8]

Miért, mert PHP-ben is meg tudom írni jól működően és biztonságosan azt amit te csak Java-ban?
Nem értem miért kell olyasmit szidni, amit eszméletlen sokan használnak megelégedéssel és ami működik, és bevált?

Én sem szidom a Java-t és a többi nyelvet, pedig mondhatnám, hogy fos mind, mert speciel én XY személy szerint nem szeretem...

Inkább objektív maradnák, annak több értelme van.

________________________________
blog: http://horvathjanos.wordpress.com

Olvastam a véleményed igen, de ha minden nyelv elmeroggyanást okoz a fejlesztőnek a felsoroltak közül, akkor mégis miben fejlesszünk Gnome-ra GUI-s appokat, és miven írjunk szerever oldali kódot a weben, és miben kernelt szerinted?
Azzal kell dolgozni ami van, nyilván sem én sem te nem fogunk új nyelvet megalkotni..., én legalábbis biztos nem! :)

________________________________
blog: http://horvathjanos.wordpress.com

Teljesen mindegy, miben fejlesztenek, mert egy nagy rakas ember ugyis kiabalni fog. Errol a kiabalasrol kene inkabb leszokni, mert teljesen mindegy, hogy az ember milyen nyelvet hasznalna $X helyett, amit o valaszt, az se jobb semmivel.

Igy az egesz vitatkozas meg dobalozas teljesen ertelmetlen.

--
|8]

+1 :)

A vita jó, mert vannak emberek (pl. Te) akikkel érdemes és jól lehet vitatkozni, mert nem szektaként kezeli az általa preferált nyelvet, hanem nyitott mindenre, és nem sárdobálással reagál, ha nem az van ami neki tetszene.
Szóval köszönöm a kellemes "vitát"! :)

________________________________
blog: http://horvathjanos.wordpress.com

"Ez egy adott példa, és egy adott rendszer, gondolom nem volt tervezés"

De volt tervezés. Aztán jöttek új igények.

"hanem csak egy webshopról"

Ahaaaaaaaaaam.... csak egy sima webshop kb. 14000 munkaórával a háta mögött. Oké, ebben benne vannak a háttér-informatikai munkák is. Az, amit egy sima látogató lát a felszínen, az kb. a funkciók 5%-a.

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

Biztos nagy munka volt, nem is firtattam ezt, és biztosan sokat is tettetek bele. Persze utólag mindig másként csinálná az ember, de lehet PHP-ben maradva is tudtátok volna utólag okosabban megoldani a dolgot, ezt gondolom nem tagadod. Legfeljebb már emiatt a munka miatt megutáltad a PHP-t.

________________________________
blog: http://horvathjanos.wordpress.com

Ja, ezek az "FB PHP-t használ" meg a "Google MySQL-t használ" érvek mindig aranyosak.

A valóság meg az, hogy az FB _SEM_ PHP alatt fut, hanem C++ (hiphop) és csak a frontendnek az összekötő része, ami mögött egy csomó C++, Java, Erlang, akármi kód fut. És már ott is mondták nem egyszer, hogy hiba volt PHP-t használni erre.

De az FB (mint ahogy a Google is a MySQL-lel) egy egészen más szinten mozog, mint egy bagyobb, átlagos magyar rendszer. (Docler + Livejasmin most nem játszik :) Nem véletlen, hogy 1-2 nagyságrendenként változik az optimális módszer.

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

Off, de ha már nagy siteokról, php-ról meg pornóról van szó, találtam egy érdekes cikket.

"On the software-side of things, YouPorn’s primary data store is 100% Redis, with MySQL used as an admin tool to manage and add data to the Redis cluster. The site used to be primarily programmed in Perl with a MySQL backend, but in 2011 Perl was switched out for PHP and MySQL replaced with Redis. Nginx acts as the HTTP server, with both HAProxy and Varnish both used to load balance."

Sajnos hardware porn nincs a cikkben. :)

Azon túl, hogy BÁRMILYEN nyelven lehet a webre fejleszteni, szinte minden használt nyelv jobb, mint a PHP, és itt a jobb szót abszolút értelemben használom. A hátrányuk ott van, hogy nincs kialakult keretrendszer hozzá, hiszen nem elsődlegesen webfejlesztésre készültek a nyelvek. De ettől még a PHP nem lesz egy jó nyelv, sőt, nagyon szépen kiemelték, mi a rossz benne. Az, hogy a Rails szar (vagy nem), vagy a Django vagy akármelyik nem-PHP alapú framework, ettől teljesen független.
----
India delenda est.
Hülye pelikán

Egyetértek, én is utálom az átgondolatlanságait, de ettől nem lesz szar. Van csomó jó dolog benne amiért öröm használni. Van olyan is ami szerintem jó dolog, de hibaként van felsorolva. A Python meg van dícsérve (igaz említi hogy nem tökéletes) de arról is lehetne ugyanilyen cikket írni. Szubjektív ez is, igaz érvel, de a saját szemszögéből.

Amúgy meg, nekem bejön PHP is JS is, webre nagyon jó, máshol én sem használtam még, vagyis WebGL-nél igen, de az is Web, de itt a lényeg az már nem az a JS amire te asszociálsz, csak JS-re épített JS szintaktikájú "nyelv", és ez a lényeg, nem az, hogy valójában mi fordítja mivé, meg hogyan, hanem az, hogy nem idegen az embernek, mert írt már elég JS kódot, és hozzászokott.
________________________________
blog: http://horvathjanos.wordpress.com

Használtam: Java, VisualBasic, Ruby, Python.
Viszont egy percre sem állítom, hogy Java, Ruby vagy Python programozó lennék, csak azért, mert valamikor írtam benne valamit, egyszerűen csak volt, hogy ez kellett, és használtam, de napi szinten nem használom ezeket. Tudom, hogy ezer érv van ami a PHP-n és a JS-en kívűl más nyelveket dicsérhet, de ahogy írtam, nem feltétlenül rossz egy nyelv valamire, csak mert nem erősen típusos meg nem enterprise stb... Web-re "tökéletes" a PHP.

Azt sem értem miért baj az, ha GNOME alatt egy egyszerű GUI-s app-ot mondjuk egy naptárprogramot, jegyzettömböt, számológépet, stb. JS-ben írnak meg és nem C-ben vagy C++-ban vagy akármilyen más nyelven, kinek fáj ez, ha nem lassabb és nem okoz gondot legfeljebb annyit, hogy JS-t kell tanulgatni hozzá?

________________________________
blog: http://horvathjanos.wordpress.com

"Web-re \"tökéletes\" a PHP" Szerintem te még nem olvastad végig figyelmesen kmARC postolt cikkét, hogy mondhatja ember azután, hogy elolvasta azt, hogy bármire is tökéletes. Őszintén rábíznád, hogy kezelje a pénzügyeidet? A weben a fórum/blog/hírek/social dolgok után a webshopok a legelterjedtebbek. Azt nem vitatom, hogy kellő odafigyeléssel, az összes buktató alapos ismeretével, alapos teszteléssel nem lehet elfogadható szintre hozni az adatbiztonságot, de azért tökéletesnek nem mondanám.

-
Reflection - a bajkeverő csodagyerek

"Azt nem vitatom, hogy kellő odafigyeléssel, az összes buktató alapos ismeretével, alapos teszteléssel nem lehet elfogadható szintre hozni az adatbiztonságot"

Tesztelni kell, ennyi. Biztos vagyok benne, hogy minden PHP hiba áthidalható ha ismeri a fejlesztő a tipikus hibákat. Nem mondom, hogy örülni kell ennek, vagy a PHP-t isteníteni ezért, de ismétlem, ettől még nem lesz a nyelv egy rakás "sz@r", mert ilyen megközelítésben bármit lehetne annak hívni, Linux-ot,BSD-t, Windows-t, MySQL-t akármit amiben találunk valami vérlázító hibát/hibákat/hiányosságokat.
________________________________
blog: http://horvathjanos.wordpress.com

Ha lesz időd, tényleg olvasd el a cikket.

Nem azért rossz a php, mert vannak pl. security problémák, vagy mert vannak nehezen megvalósítható gyakori programozási feladatok. Hanem mert inkonzisztens, ami ennél is rosszabb: ellentmondásos, továbbá alultervezett, és mindezek mellett ami nem meglepő, teljesítmény-problémákkal is küszködik.

Nagyszerű dologkat is véghezvittek PHP-ben, de ha >2005 évben valaki komoly webes infrastruktúrát és webalakmazást áll neki készíteni, akkor jobban teszi, ha egy kiforrottab, konzisztens nyelvet és ecosystemet használ.

Bár én meg azt nem ismerem mélyrehatóan, az az érzésem, hogy a rails vagy a django messze alkalmasabb lenne a feladatra (nem beszélve a .netes/java-s frameworkökről). Ez utóbbiak alatt egy-egy jól tervezett nyelv van.

Ez a jó hozzáállás, ha találkozol polival, győzd meg őt is :-)

Én csak tapasztaltam, hallomásból tudtam, sejtettem, hogy a php-s világ nem egy átdondolt valami. Miután végigolvastam a cikket, megingathatatlanul megerősödött a hitem ebben. Néha jól esik végigolvasni, tanul mindenből az ember.

,,Hogy miért a JavaScript? Arról részletesen itt lehet olvasni."

hát ez azért elég meggyőzőtlen

Ha egy GNOME szintu projectnel ket napnal tovabb tart eldonteni, hogy mi legyen az ajanlott nyelv, akkor valami el van szurva, mert nem ismerik a sajat platformjukat, es a lehetosegeiket.

Alapbol elegge limitalt a valasztek: C, C++, Vala, Python, JavaScript, C#/Mono, mert ezek azok a nyelvek, amik mar hasznalva vannak a GNOME platformon belul, olyan nyelvet ajanlani ami teljesen uj, buta dolog lenne. Ezek kozul a C helybol kiesik, mert se nem dinamikus, se nem high-level. A C++, a Vala es a C#/Mono hasonlo okok miatt bukik. Marad a Python es a JavaScript.

A Python nem kifejezetten embeddable. Lehet embeddalni, persze, de ez nem kifejezetten fokusz, es a nyelvnek elegge kozponti reszet kepezi a standard library, amit GNOME-osok el akartak kerulni. Olyan nyelvet kerestek, ami self contained. A Python nem az.

Maradt a JavaScript.

Lehet vitatkozni, hogy a tamasztott kovetelmenyek mennyire ertelmesek, de eddig meg nem olvastam vedheto ellenervet, hogy miert ne lennenek azok.

--
|8]

Valahoz nemigazán értek, de amennyire tudom, nagyjából egy C# nyelvet vettek alapul amelyet C-re fordítanak.

C# alapvetően egy kellően dinamikus nyelv. És igen, kell VM és standard library mögé. Utóbbit inkább pozitívumnak nevezném, mint hátránynak. Nem tudom mennyire jó az, hogy egy standard library helyett össze-vissza használ mindenki mindent.

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

A Vala C-re fordul, kell hozza egy C fordito. A C# szinten forditando, es a standard library irgalmatlan nagy hatrany akkor, amikor embeddalni akarod.

Az, hogy nincs standard library, nem jelenti azt, hogy mindenki ossze-vissza hasznal mindent: a standard library a nyelv resze is lehet.

--
|8]

De ember, most alkalmazasfejlesztesrol van szo, nem beagyazott figyfaszokrol, negyed byte rammal... Tudod mit jelent a fogalom?

Standard lib meg sosem a nyelv resze. A .NET framework a .NET keretrendszer resze, a C# csupan egy nyelv a kozel 50 kozul, amellyel CLI kodot tudsz produkalni.

Meg lehet nezni az Unity3D-t, mit csinal: libmono, az mscorlib.dll-bol meg ki van hagyva egy halom felesleges dolog. Maga a fajlok, amelyeket letrehoz altalaban ugy indul, hogy using System, UnityEngine; oszt' csokolom. Kb. a legalapabb dolgokat hasznalja csak, minden mas az unity playerbol jon.

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

És most hogyan jön a beágyazhatóság az alkalmazásfejlesztéshez?

"BZZT. Melle."

Már miért ne lehetne leválasztani a nyelvet a standard libjétől? Mi akadályoz meg abban, hogy kicseréld? A runtime lib már neccesebb témakör az tény.

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

>> De ember, most alkalmazasfejlesztesrol van szo, nem beagyazott figyfaszokrol, negyed byte rammal... Tudod mit jelent a fogalom?

> És most hogyan jön a beágyazhatóság az alkalmazásfejlesztéshez?

Fuss neki megegyszer, esetleg az elozmenyeket elolvasva.

> Már miért ne lehetne leválasztani a nyelvet a standard libjétől? Mi akadályoz meg abban, hogy kicseréld? A runtime lib már neccesebb témakör az tény.

Le lehet, de minek? Sokkal praktikusabb, ha ezen nem kell erolkodni.

--
|8]

Nekem lenne néhány tippem, amit pl. megnézhettek - innen a P betű: Perl, Ruby. Bár, ha jól látom, nem igazán tetszik nekik a Python a modularitási képessége miatt (?), így ezen két tippem is áteshetett a rostájukon. Csak azt nem értem, hogy a JS takony-kódú leíró nyelv, miért lett a haverjuk...
A Ruby-Gnome tényleg lehett volna cimborájuk...

Kíváncsi vagyok, hogy mikor írnak hozzá NoScript kiegészítőt, meg AdBlock Plus-t. :3

Ezek teljesen megbolondultak.

Néhány évet kellett fejlesztenem erősen JavaScript-elős webes környezetben és azokat még az ellenségeimnek sem kívánom, nemhogy a saját fejlesztőimnek.

A JavaScript-nél nagyobb fost nem ismerek a programnyelvek között.

En hosszu evek ota fejlesztek C-ben, sokat fejlesztettem Pythonban, PHP-hoz, Perlhez is kellett nyulnom. Egyik nagyobb fos mint a masik, el nem tudom kepzelni mi vitt embereket arra, hogy C-ben irjanak kernelt, Pythonban barmifele GUI-t, PHP-ban webappot, Perlben meg nagyjabol barmit.

Ellensegemnek sem kivanom (najo, de, mert gonosz vagyok), hogy ezen nyelvek barmelyiken fejlesztenie kelljen hosszabb ideig, mert nagyon meredek lesz az epelme-pont esest abrazolo gorbe.

&;lt/felig-troll>

Az, hogy a JS fos, nem teszi rosszabba barmely mas nyelvnel. Minden nyelv fos, mert minden nyelvhez talalsz olyan hozzaerto embert, aki fel tud neked hozni kismillio dolgot, amiert a nyelv rossznak lenne tekintheto. Nincsen ez alol kivetel, legfeljebb az olyan nyelv amit 2 ember ismer, es az egyik az iro anyukaja, es o is tegnap hallott rola, hogy a nyelv egyatalan letezik. :P

--
|8]

"el nem tudom kepzelni mi vitt embereket arra, hogy C-ben irjanak kernelt"
Megis, miben kellett volna?
Eleve erre keszult a nyelv. Nagyon hatekony normalis meretu kernelek karbantartasara. Minden nyelvi elem biztonsagosan hasznalhato kernel modban. Jol leirhatok benne az alacsonyszintu vezerlesek is. Megis mi vele a gond?

-1

Az, hogy neked ez nehezen ment és szenvedést okozott, még nem jelenti azt, hogy másnak is nehezen megy, és nem okoz élvezetet.
Lehet, hogy csak simán nem értesz hozzá elég jól, szerintem nem fos, hanem egy nagyon jó és nagyon alkalmazkodó nyelv, és jó irányba halad, és fejlődik!

Sokan szeretnek JS alapú rendszeeket készíteni és JS-el dolgozni. Nem a honlapok jobb oldalán villogó js analóg órákra gondolok, meg múltszázadi dátumszkriptekre, hanem komoly alkalmazásokra kell gondolni, okosan és praktikusan kitalált megoldásokra, framework-ökre, függvénykönyvtárakra stb
Backbone, node.js, requirejs, jQuery, underscorejs. ExtJS, Dojo, Kendo UI, stb stb. nem is beszélve a WebGL-ről és más kezdeményezésekről.

Én személy szerint szeretem a JS-t és nem alkotok szubjektiv véleményt más nyelvekről, amik meg szerintem sz@rok!

________________________________
blog: http://horvathjanos.wordpress.com

Megerősített benne, hogy jó döntés volt áttérni XFCE-re és LXDE-re. Most gondolkoztam el azon, hogy hogyan tudom függőségeivel együtt teljesen kigyomlálni a rendszeremből az összes GNOME komponenst.
JavaScript? Te jó ég!

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Végül is valamire csak ki kell használni a négy magos, 3GHz-es procikat. Szánalmas lenne, ha olyan hatékony lenne az OS felülete, hogy mindig 3% alatt lenne a proci terhelése. Így biztosan nem lesz ilyen probléma. Ha minden jól megy, egy-két rosszul megírt progammal akár az egész rendszer válaszidejét le lehet majd lassítani. Végre valami jó hír.

És ne feledjük el a régi vicces (állítólag Strostroup) ínterjút se arról, hogy miért jó a C++! A JavaScript programok még a C++ programoknál is átláthatatlanabbak egy méret felett! Így a rengeteg éhező programozónak - akik most kiszorulnak a piacról mert mindenki tud Javában programozni - újra lehet munkája! Lehet majd háromféle elfedő nyelvből javascriptre fordított gigaszörnyön véletlenül bennfelejtett dinamikus alulról felülpatkolást debuggolni.

Találtam egy benchmarkot, ahol több nyelvet is össze lehet hasonlítani, példáúl python vs. javascript vagy ruby vs. javascript, ami alapján én nem törnék egyértelműen pálcát a javascript felett. Nyílván egy c++ban írt kóddal nem veszi fel a versenyt. Rossz/vacak programot bármiben lehet írni nem csak javascriptben. Azt tudom még elképzelni, hogy a sok javascriptkiddie miatt, akik most hirtelen felindultságból nekiesnek a dolognak mert az milyen fenszi, elszaporodhatnak a silány minőségű cuccok.

-
Reflection - a bajkeverő csodagyerek

A múlt héten csináltam teszteket. Egyszerű prímkeresés és vektorban való eltárolás volt a legegyszerűbb módszerrel. Azaz osztó = 2...sqrt(szám) -ig és ha (szám % osztó) sehol sem adott 0 maradékot, akkor prím.

CPU i5-480m 1 szálon 10 millióig (amiből 664578 prím) az alábbit futási időket mértem:

# C
time ./prim-c 7.392s

# Python
time python ./prim.py: 131.220s
time pypy ./prim.py 24.670s

# Lua
time lua prim.lua 57.876s
time luajit-2.0.0-beta9 prim.lua 14.721s

# PHP - zend és a többi nélkül, parancssorból futtatva.
time php prim.php 114.523s

Tanulság#1: lassú szkriptnyelvet másik lassú szkriptnyelvvel hasonlítgatni, hogy melyik a gyorsabb, hát enyhén szólva vicces.
Tanulság#2: JIT sokat segít a szkriptnyelven.

Mellékesen jegyzem meg, hogy a Python-jellegű objektumos szemléletű szkriptnyelvek ügyesebbnek tűnnek számomra. Kérdés, hogy csak én kedvelem, vagy tényleg praktikus megoldás (mármint az objektumos szintaktikája)?

Gondolok erre (akik nem ismerik a Pythont, azoknak: python< enter > és ki lehet próbálni):

s = "almakompot korte banan"
s.split()[0].upper()[4:-2]

s string osztály split metódusát meghívom.
az így kapott listából kiválasztom a nulladik elemet.
majd az így kapott stringet nagybetűssé teszem.
és végül az így kapott string 4. betűtől a vége előtt 2-vel levő betű előttig kiszedem.

"Mellékesen jegyzem meg, hogy a Python-jellegű objektumos szemléletű szkriptnyelvek ügyesebbnek tűnnek számomra.
[...]
s.split()[0].upper()[4:-2]"

Funkcionalis megoldasok is vannak, amikkel hasonloan lehet chain-elni a fuggvenyeket. Ilyen pl. livescript-ben a pipe operator, vagy clojure-ben a threading macro. A peldad clojure-ben nagyon hasonloan nez ki:

(-> s (split #" ") first upper-case (slice 4 -2))

(megjegyeznem, hogy python slicing szeru fuggveny nincs clojure core-ban tudomasom szerint, nekem kellett megirni)

Akkor álljon itt scala-ban is:
var s = "almakompot korte banan"
s.split(" ")(0).toUpperCase.substring(4).dropRight(2)

A fenti példa arra is jó, hogy megmutassa, hogy bár a scala erősen típusolt, mégsem kell mindenhová kiírni a típust (a fenti esetben a String-et), azt kitalálja magától.

AMD Phenom(tm) II X4 955

C++:
time ./prime 28.246s

Scala:
time scala prime.scala 37.946s

Források:
C++:


#include <stdio.h>
#include <math.h>

int main() {
    int* primeArr = new int[1000000];
    int count = 0;
    for (int i = 2; i<=10000000; i++) {
        int k = int( sqrt(i) );
        bool isPrime = true;
        for (int j = 2; j <= k; j++) {
            if (i % j == 0) {
                isPrime = false;
                break;
            }
        }
        if (isPrime) {
            primeArr[count] = i;
            count += 1;
        }
    }
    printf("%d\n", count);
    return 0;
}

Scala 2.9.2:


import scala.util.control.Breaks._

var primeArr = new Array[Int](1000000)
var count = 0;
for (i <- 2 to 10000000) {
    var k = scala.math.sqrt(i).toInt
    var isPrime = true
    breakable { for (j <- 2 to k) {
        if (i % j == 0) {
            isPrime = false
            break
        }
    } }
    if (isPrime) {
        primeArr(count) = i
        count += 1
    }
}
println(count)

Java verzió, de meglepő, hogy gyorsabb volt, mint a c++... lehet, hogy valamit elírtam?

public class Prime {

public static final int COUNT = 1000000;

public static void main(String[] args) {

int[] primeArr = new int[COUNT];
int count = 0;
for (int i = 2; i<=COUNT; i++) {
int k = (int) Math.sqrt(i);
boolean isPrime = true;
for (int j = 2; j <= k; j++) {
if (i % j == 0) {
isPrime = false;
break;
}
}
if (isPrime) {
primeArr[count] = i;
count += 1;
}
}

System.out.println(count);
}

}

Én valami ilyesmivel próbálkoztam, de mindig megakad, mert túl sokáig fut...

Kipróbálnám latest google chrome-mal, meg firefox-szal is. IE-t nem erőltetném :)

var start = new Date().getTime();

var primeArr = new Array(1000000);
var count = 0;

for (var i = 2; i<=10000000; i++) {

var k = Math.sqrt(i);
var isPrime = true;

for (var j = 2; j <= k; j++) {
if (i % j === 0) {
isPrime = false;
break;
}
}

if (isPrime) {
primeArr[count] = i;
count += 1;
}

}

var end = new Date().getTime();
var time = end - start;
alert('Execution time: ' + time);

JS:
time gjs prime.js 41.655s (1,5x)

Tehát alapvetően a sebességével nem lesz nagy gond, főleg, ha a gjs-en még tudnak javítani.

prime.js:


var primeArr = new Array(1000000);
var count = 0;
for (var i = 2; i<=10000000; i++) {
    var k = Math.sqrt(i);
    var isPrime = true;
    for (var j = 2; j <= k; j++) {
        if (i % j == 0) {
            isPrime = false;
            break;
        }
    }
    if (isPrime) {
        primeArr[count] = i;
        count += 1;
    }
}
print(count);

Szerinted az 50% lassulás az nem gond? Mondjuk mit szólnál, ha a monitorra dugott laptopod nem hat órát tudna menni aksiról, hanem csak négyet? És ha beleszámoljuk, hogy például egy nyomtatási sor kezelő applet plusz három-négy könyvtár réteget használ, amiből legalább az egyik a JS miatt szintén 50%-kal lassabb, mint amilyen lehetne... Szerintem ez nagyon gáz. Inkább csinálnák meg ugyanazt a funkcionalitást, de dolgozzanak még egy évet az optimalizáláson. Valljuk be, hogy a mai desktop felület alig ad valami használható plusz funkciót az egy évtizeddel ezelőttihez képest, csak szebben forog-pörög-ugrál. Én inkább a hosszabb aksi időt választanám, ha lehet.

Akkor gondoljuk ezt egy kicsit végig. Vajon mennyire használja ki az átlag user
a desktopját? Ahogy én néztem, egy gép az idő igen jelentős részét idle állapotban tölti,
amikor a programok várnak az input-ra. Emiatt pont nem igazán fog semmit sem változni
a laptop üzemideje. Az 50% akkor lenne igaz, ha csontra kiterhelnénk a procit, folyamatosan
futna a progi teljes kapacitással, pl. 3d-s képet renderelne. Amíg a legtöbb guis program
peak-ekben dolgozik, a fogyasztásban esélyesen nem túl jelentős különbség lesz.

BTW én még nem láttam embert, aki laptop-ot monitorra dugott volna úgy, hogy aztán a laptopot
nem dugja be a hálózatba a monitor mellé. :)

"Inkább csinálnák meg ugyanazt a funkcionalitást, de dolgozzanak még egy évet az optimalizáláson. Valljuk be, hogy a mai desktop felület alig ad valami használható plusz funkciót az egy évtizeddel ezelőttihez képest, csak szebben forog-pörög-ugrál."

Nem a desktop a lényeg (az marad úgy, ahogy van), hanem hogy alkalmazást milyen gyorsan lehet rá fejleszteni. Ha meg lehet csinálni, hogy a teljesítménykritikus részek (amiből általában nagyon kevés van) valami fordított nyelven íródhassanak, akkor az alkalmazás teljesen használható lesz.

Ha gyorsabb desktop kell, akkor meg a videókártyával kell gyorsítani a képernyőre rajzolást, mert ettől lesz igazán smooth a felhasználói élmény, és még a procit sem zabáljuk.

"BTW én még nem láttam embert, aki laptop-ot monitorra dugott volna úgy, hogy aztán a laptopot
nem dugja be a hálózatba a monitor mellé. :)"

Én láttam. :) Egyetemen, géptermi gyakorlaton illető hozta a laptopját, rádugta az előtte elhelyezkedő monitort, de a laptopját nem rakta töltőre (gondolom nem is volt nála töltő, 2h-ra minek).

"Az 50% akkor lenne igaz, ha csontra kiterhelnénk a procit, folyamatosanfutna a progi teljes kapacitással, pl. 3d-s képet renderelne. Amíg a legtöbb guis program peak-ekben dolgozik, a fogyasztásban esélyesen nem túl jelentős különbség lesz."
Ez igy egyaltalan nem igaz. Latom, nem kellett meg olyan szoftveren dolgoznod ahol a fogyaszta a kritikus. A valosag az, hogy a procit minel tovabb idle-ben kell tartani. Hiaba csak rovid peak-ek vannak, ha azok ketszer annyi ideig tartanak akkor a fogyasztas is jelentosen novekszik. Szerencsere nem duplara, de 25%-40% siman lehet rovid feldolgozasnal is. Ezert telefonoknal - ahol ez nagyon sokat jelent - nem is szerencses nativ kodon kivul barmit allandoan futtatni. Egy extra kernel hivas egy ismetlodo feladatnal is rengeteget jelenthet.

OFF: Ne nyomj entert a sor vegen!

Ezzel egyetértek, viszont megint eltértünk a céliránytól, ami pedig a gnome alatt futó desktop alkalmazások. A példáddal azért nem értek egyet, mert az Android-os telefonokon is managelt programok futnak, dalvik vm-ben, aminek nyilván sosem lesz olyan sebessége, mint egy adott arm platformra kézzel szétoptimalizált assembly kódnak. Tehát az, hogy a fogyasztás kritikus, csak egy paramétere egy embedded platformnak - mint egy telefonnak, legalább olyan fontos, ha nem fontosabb, hogy gyorsan és hatékonyan lehessen rá alkalmazást fejleszteni - ez egy alacsony absztrakciós szintű nyelvnél milyen sok effortot jelentene, mennyivel megdrágítaná a programokat -, hogy jó válaszideje legyen, hogy ne fagyjon széjjel, stb. Értem én, hogy vannak olyan platformok, ahol kénytelen az ember bizonyos korlátokat nagyon szűkösen betartani (én is programoztam olyanra, ahol összesen 64k memória volt elérhető) de itt most gnome desktop alkalmazásokról van szó. Tehát a kérdés az, hogy ebben a konstellációban mennyivel csökkenne az üzemidő egy laptop esetén átlag felhasználásnál. Ezt a kérdést kellett volna feltenni, és mondjuk utána méréseket végezni.

Szerintem az egyes platformok lassan összemosódnak. A napokban jelent meg a hír, hogy a hónap végén elérhető lesz az Ubuntus okostelefon a fejlesztők számára. A részleteket nem ismerem, de ha ez is a gnome-ra fog épülni, akkor az előny lenne, ha a desktopra fejlesztett programok a telefonon is módosítás nélkül futnának. Viszont a telefonon már az akkuidő nem elhanyagolható tényező.

-----
A kockás zakók és a mellészabások tekintetében kérdezze meg úri szabóját.

Bizonyára kétszer kell megírni a GUI-t így is. Lesz az app-nak egy desktop GUI-ja és egy mobil GUI-ja, ezt nem lehet megkerülni, a GUI elemek működése, helye, alakja struktúrája mindene más, és ezt sosem lehetett máshogy megoldani, ha csak nem akarsz használhatatlan desktop GUI-t telefonon, vagy ocsmány mobil GUI-t desktopon vagy egy ocsmány és használhatatlan GUI-t mindkét platformon.
A fejlesztő megírja majd az app logikáját és működését, és ír hozzá két GUI-t, Mobilra egyet és Tablet-re + Desktop-ra egy másikat.

________________________________
blog: http://horvathjanos.wordpress.com

,,Lesz az app-nak egy desktop GUI-ja és egy mobil GUI-ja, ezt nem lehet megkerülni, a GUI elemek működése, helye, alakja struktúrája mindene más, és ezt sosem lehetett máshogy megoldani, ha csak nem akarsz használhatatlan desktop GUI-t telefonon, vagy ocsmány mobil GUI-t desktopon vagy egy ocsmány és használhatatlan GUI-t mindkét platformon."

Ki tudja.. Lehet, hogy csak jó dizájnerek kérdése az egész. (meg ha valaki feltalál valamit a kattint/lenyíl/csúsztat/etc bevett gomb/szöveg interakciókon kívül)

Puppy linux felhasználó

Egy ideje már benne élek a felbontás/készülék/platform különbségek miatt felmerülő GUI tervezés problémakörében.
Persze mindenre van megoldás, de mindig az a cél, hogy az adott készüléken a felhasználónak a legegyszerűbb, legletisztultabb legátláthatóbb interfészt biztosítsuk.
Tipikus példa, mikor egy egységsugarú júzernek kiraksz a képernyőre gombokat, ha kettőnél több van kinn egyszerre akkor már elkezd gondolkodni, hezitálni, problémázni és utálni fogja azt az app-ot amit nem tud ösztönösen természetesen hazsnálni.
Ott van példának az ellenállás a Win 8 esetén, de ide hozhatnám példának a Gnomoe-ot az új felültével, vagy mondhatnánk azt is (bár már nem tudom a mai készülékeken hogy van, csak a régieken), hogy a Motorolla telefonjain és a Nokia vagy az Ericsson telefonjain fordítva voltak az OK és CANCEL gombok, ami márka váltás esetén egy jó darabig kényelmetlenséget okozott az adott vásárlónak stb...

Gondolj bele, hogy miért tesznek botkormányt egy repülőbe és miért tesznek kormánykereket egy autóba, és miért nem egységesen használnak kormánykereket mindkettőben. Jó lehet hülye példa volt, de mindkettő más környezetben, más külső feltételek közt használatos. Egy mobil készülék méretéből és a hazsnálati szokásokból adódóan más GUI-t igényel, mint egy asztali készülék, ahol ülsz, van íróasztal, van billentyűzet, egér, miegymás... és főleg, hogy van nagy megjelenítő felület, míg mobilon folyamatosan takarékoskodni kell a hellyel, és mindig csak a legrelevánsabb információt lehet megjeleníteni.

Amit te mondasz, vagy próbálsz elmondani, az biztosan valami távoli célja mindenkinek, de ahhoz olyan nagy technikai és szemléleti váltás kell még, ami nem 1-2 éven belül fog bekövetkezni. Ki tudja hová fejlődik a megjelenítők/képernyők piaca.... lesz hologram? vagy lesz más? Én nem tudom, és jelen pillanatban nem is tudhatjuk, ahogy azt sem tudták pl. a szüleink, hogy majd lesz touch screen, vagy egyáltalán olyan cigis doboz méretű készülék, ami egyszerre zenelejátszó, video, játékkonzol, telefon, számítógép, fényképező, stb. stb... ez szinte hihetetlen lett volna abban az időben.

Ha most azt mondom neked, hogy 30 év múlva nem álatkertbe megyünk az egyik hétvégén kikapcsolódni, hanem a Sirius melletti Alpha XY123-as bolygót megyünk megnézni űrbusszal, meg az ottani földönkívüli élővilágot, akkor nagy valószínűséggel kinevetsz, sőt én is nevetek magamon, miközben fogalmunk sincs róla, hogy mi lesz velünk 30 év múlva. Vagy odáig fejlődünk, hogy tényleg űrbuszozunk potom 30.000-ért oda vissza, fapados űrbusszal, és áttörések lesznek a technika és tudomány minden területén, vagy annyira szétcsesszük a világunkat, hogy újra íjjal és parittyával vadászunk az erdőben. Ha engem kérdezel, az utóbbi esélyesebb, de nem tudhatom! :D

________________________________
blog: http://horvathjanos.wordpress.com

> Tehát az, hogy a fogyasztás kritikus, csak egy paramétere egy embedded platformnak - mint egy telefonnak, legalább olyan fontos, ha nem fontosabb, hogy gyorsan és hatékonyan lehessen rá alkalmazást fejleszteni - ez egy alacsony absztrakciós szintű nyelvnél milyen sok effortot jelentene, mennyivel megdrágítaná a programokat -, hogy jó válaszideje legyen, hogy ne fagyjon széjjel, stb.

1. Például Qt-ben, Qt Creator használatával nem kevésbé hatékony fejleszteni, mint JS-ben. Nem kizárt, hogy hatékonyabb.

2. Sajnos nagyon sokan osztják a véleményed a hatékony programozásról, amit én nagyon fájlalok. Igenis figyelembe kell venni, hogy te egyszer gyorsan megírod, és utána több csilliárd alkalommal fut le 2-4x annyi idő alatt (visszafogott becslés), mint ami indokolt lenne. Nekem van olyan programom, amit négyszer írtam újra nulláról, és a végére _nagyon_ sokkal hatékonyabb lett. Kellett hozzá majd tíz év (sok más meló mellett), de megérte. Még tudnék rajta javítani, lehet, hogy majd fogok is. Szerintem a szabad szoftver fejlesztőknek, akiknek nem ül a nyakán a sales és marketing osztály, így kellene hozzáállni.

1. Teljesen egyetértek. Szerintem pl. Scala-ban még sokkal hatékonyabb, de Vala-ban vagy C++-ban sem hiszem, hogy kevésbé hatékony, mint JS-ben, ha valaki jól ismeri.

2. Itt azokról a részekről írtam, amik rendszerint milliszekundum nagyságrendben futnak. Persze, ahogy később is írod, ha JS-ben elkezdenek fejleszteni, akkor nagy a kísértés, hogy mindent abban írjanak, a teljesítmény kritikus részeket is. Többek között ezért sem szerencsés szerintem sem alap nyelvnek ajánlani.

Bónusz :)
Átírtam a prímszámolót scala-sra.
Ami megdöbbentő, sokkal rövidebb és átláthatóbb, mégis gyorsabb, mint az eredeti scalas (1,34x -> 1,09x)


object Prime {
    def isPrime(number: Int) : Boolean = {
        for (j <- 2 to scala.math.sqrt(number).toInt) if (number % j == 0) return false
        return true
    }
    def main(args:Array[String]) {
        var primeArr = (2 to 10000000).filter(isPrime)
        println(primeArr.length)
    }
}

Még egy utolsó kis érdekesség. Párhuzamosítottam a fenti kódot. Így 10 másodperc alatt lefut a 4 magos gépemen (0,35x).
Aki megtalálja a különbséget az előző kódhoz képest az kap egy piros pontot! :)


object Prime {
    def isPrime(number: Int) : Boolean = {
        for (j <- 2 to scala.math.sqrt(number).toInt) if (number % j == 0) return false
        return true
    }
    def main(args:Array[String]) {
        var primeArr = (2 to 10000000).par.filter(isPrime)
        println(primeArr.length)
    }
}

Szerintem nem gond, mivel ez csak a legfelső szint lesz, ami a vezérléseket végzi.
A teljesítmény kritikus részek pedig a Gnome alaprendszer könyvtárai közé kerül, illetve az egyedi teljesítmény kritikus részeket továbbra is meg lehet oldani Vala-ban illetve C-ben.
A prim számítás kb. így működne:
var primeArr = calcPrime(10000000);
ahol a calcPrime mondjuk C-ben van megírva.
A kisebb programok nagy részéhez nem szükséges C kiegészítést írni (hajrá Pistiék), a nagyobb programoknál pedig megoldható kiegészítő könyvtárakkal, illetve egyéb nyelven is meg lehet írni (ahogy szerintem ez történni is fog).
Nekem sem tetszik a JS választás, de nem a sebesség szempontjából, mert az itt nem igazán játszik.

Szelektálni kell. Amit sz@r alkalmazásnak gondolsz, nem használod és kész. A Gnome-ba annál sz@rabb alkalmazások nem kerülnek be hivatalosan, amik most is benne vannak, akár JS-ben íródnak majd akár nem JS-ben. Persze ne érts félre, szerintem most sem sz@rok a Gnome alkalmazások, csak arra akarok rávilágítani, hogy nem lesz rosszabb annál semmi mint ami most van, véleményem szerint inkább jobb lesz, de ez csak szubjektív vélemény.

________________________________
blog: http://horvathjanos.wordpress.com

Persze, szelektálni. A vacakabbnál vacakabb megoldások közül, amikre most ajtót nyitottak. Durván fogalmazok: hülyéknek adunk fegyvert a kezükbe. Olyan nyelvet adsz nekik, amivel gyorsan lehet eredményre jutni, de ez szerintem megtévesztő. Mert az eredmény minőségéről nincs említés...

(Off: Szerintem azzal, hogy "@"-t írsz "a" helyett, nem lesz jobb. Akkor már írd ki, vagy ha szégyenlős vagy, használj enyhébb kifejezést. :-) )

Androidra is fejleszt minden Pistike, és okádják rá a szarabbnál szarabb alkalmazásokat, ömlik a market-ből a fos, mégsem lesz minden Androidos app fos, csak kerül közéjük olyan is. Ott nincsenek olyan szigorú szabályok, elég könnyen felkerül a market-be a fos is.
Egy Gnome esetén a kiadáskor nyilván megnézik mit tesznek bele, valamennyi tesztelés biztosan van, nem csak az történik, hogy:

"Jé, de szép ikonja van ennek a naptár programnak, de jó csini GUI-ja van, legyen ez a hivatalos gCalendar vagy Gnome Calendar, vagy ilyesmi... né má' ott meg egy tök jó csili vili contact kezelő, Gyuszinak is tetszett, oké ez lesz a gContact vagy Gnome Contact, ok pakoljuk össze és délután toljuk ki a repóba a Gnome X.X-et hadd tőccsék a népek" :)

Szóval itt is lesz egy hivatalos app lista ami tesztelt és jól működö remek alkalmazások listája, és lesznek a letölthető egyébb app-ok amikből válogathatsz. A szelektálást segíti majd a felhasználói értékelés, másra nem hagyatkozhatsz, de mit várunk mást egy open-source területen? Garanciát? Az nincs, nem volt soha nem is lesz, nem is lehet, nem is kellhet...

________________________________
blog: http://horvathjanos.wordpress.com

Nem akartalak meggyőzni semmiről, csak elmondtam, hogy hogy működnek a dolgok. Ez van Android alatt is az ingyenes app-okkal és ez lesz itt is.
Hogy a Gnome csapatban a hivatalos alkalmazáslistát összeállító emberek mennyire lesznek körültekintőek vagy sem, és mennyire válogatnak össze fos app-okat, azt nem tudom, nem tudhatom, csak remélem, hogy ahogy eddig is, most is olyan jók lesznek mind, vagy legalábbis nem rosszabbak.

Fogalmam sincs mi lesz a jövő ennek a döntésnek a nyomán... újraírják az Evolution-t JS-ben, esetleg a Nautilust, a Eye of GNOME-ot, a Gedit-et, F-Spot-ot, Banshee-t, Totem-et???
Te tudod mi lesz ezekkel? Újraírják JS-ben és szarok lesznek szerinted? Vagy ezeket kukázzák, és kapunk új app-okat helyettük?
Tényleg nem tudom mi lesz, de nem fog megbukni a Gnome, hanem személyes véleményem szerint jobb lesz. Lehet, hogy változnak még a dolgok, és ez a JS dolog is kiegészül mással, vagy átalakul még, kitudja, de egetrengető, a Gnome prjekt totális bukását eredményező döntést nem hoznának csak így, ebből pedig az következik, hogy a JS-re váltás sem lehet oltári nagy ökörség? Vagy már csak én egyedül gondolom ezt így itt a HUP-on, ebben a topic-ban?

Persze lehet én és a teljes Gnome projekt tévedésben van, lehet... az is lehet, hogy holnap elüt egy autó... lehet..

________________________________
blog: http://horvathjanos.wordpress.com

s/működnek/vannak/

A működés (legalábbis számomra) azt jelenti, hogy az jó is nekünk :-)

Ez lesz itt is: bátor kijelentés, tudsz valamiről?

Szerintem nem fogunk ebben egyetérteni.

Azt díjaztam volna, ha a JS mellett lenne egy elsődleges nem scriptnyelv is, pl. a Vala, amit ilyesmire kezdtek el (és mivel az C-C# jellegű, talán elég sokan elsajátíthatják). Így lenne opciójuk azoknak is, akik valami komolyabb szoftvert szeretnének írni.

Nem hiszem, hogy korlátozva lesznek azok, akik C-ben akarnak alkalmazást írni Gnome-ra, más úton módon ugyanúgy megtehetik majd, persze nem látok én sem a jövőbe, de ez az egész biztosan kiforrja majd még magát. Ráadásul én eddig csak egy ilyen JS-ben írt app-ról hallottam a jelenlegi Gnome-ban, nem hiszem, hogy a köv. kiadásban már JS app halmokkal fogunk találkozni, de persze ez is előfordulhat, bár szerintem itt a tempó nem mérhető a profitorientált szektor tempójához, szóval én semmit nem várok, majd vagy jön vagy nem jön... kitudja mikor..

________________________________
blog: http://horvathjanos.wordpress.com

Ettől még csodálatosan gusztustalan és készüléket taccsra vágó fostömlő app-ot tud és fog is írni rá a gonosz felvágós kocka Pistike! :)
A Java sem szűri ki a hülyeséget, sőt talán még támogatja is azzal, hogy olyasmit is megírhat benne Pistike ami nagyobb gondot okoz mint csak az adott alkalmazás összeomlása.

________________________________
blog: http://horvathjanos.wordpress.com

"hülyéknek adunk fegyvert a kezükbe"

Az én meglátásom, hogy hülyék eddig is voltak, és fegyver is volt eddig. Készültek szar memóriazabáló python kódok, elrontott memleakes, segfaultoló C kódok, olyan mindegy, hogy jsben lehet-e programozni vagy nem...

Úgy gondolom, JS fejlesztésbe hamarabb (kisebb tudással) beszáll az ember mint egy C alapúba (=>több lesz a szemét). Ha a Python lenne az elsődleges, kicsit azon is csóválnám a fejem. Nem tartom jó iránynak a túlegyszerűsítést (amíg nincs rendesen oktatva az ember).

Lássuk be, hogy egy ilyen open-source projekt mint a Gnome vagy bármelyik más os. projekt folyamatosan ki van téve annak a veszélynek, hogy jön Pistike és beleszarik a forráskódba.
Persze tudom, hisz én magam mondtam, feltételzzük, hogy okos Gnome-os programozók és projektvezetők kiszűrik a szemetet valamennyire, de ez nem egy zárt rendszer, nem egy Windows vagy OS X, ez egy minden irányból nyitott homokozó és akármikor beleszarhat a ronda pattanásos Ödönke a homokvárunkba, és le is pisálhatja kedve szerint, mi nem tehetünk ellene semmit, mert ebben az opernszóóósz óvodában nincsen óvónéni! :D

________________________________
blog: http://horvathjanos.wordpress.com

Értem, hát kinek baj, kinek meg kellemes tény, de hát úgysem rajtunk múlik mi lesz...

Igazából arra is kíváncsi lennék, hogy az itt negatívan hozzászólók közül kik azok akiket érint is ez az egész, kik azok, akik tényleg írnak vagy írni fognak alkalmazásokat Gnome-ra.
Értem én, hogy felhasználóként és mellette programozóként mérnökként zavaró ez a tudat, de amíg nem látjuk, hogy mégis mi hogyan lesz addig minek háborog olyan akinek nem kell/nem akar/nem fog fejleszteni ezen a platformon? Persze lehet itt csak potenciális Gnome fejlesztők vannak, nem feltételezem azt hogy nem így van.
Persze az is lehet, hogy akiknek ez nem tetszik azok képesek a tudásuk alapján már most kijelenteni, hogy ez az egész rosszul fog működni és esély sincs rá, hogy valami jó süljön ki belőle. Én nem tudom ezt előre megjósolni kikalkulálni, biztosan mert nem vagyok elég kompetens a témába, ezt el is ismerem, én nem tudok hozzászólni C, C++, Vala programozóként mert nem vagyok az. JS-ben, PHP-ban programozok napi szinten. Java-ban csak tanultam, komoly munkára nem használtam, csak hobbi szinten, meg Androidra kicsit.
Én kíváncsian várom mi sül ki ebből az egészből, és ha lesz időm meg is próbálok valami Gnome app-ot kreálni... persze just for fun.. :)

________________________________
blog: http://horvathjanos.wordpress.com

"Igazából arra is kíváncsi lennék, hogy az itt negatívan hozzászólók közül kik azok akiket érint is ez az egész, kik azok, akik tényleg írnak vagy írni fognak alkalmazásokat Gnome-ra."

Aki komolyan írni akar, annak ez nem probléma, hiszen ugyanúgy lesz C, C++, Python binding. Ami probléma az a várható appminőség drasztikus romlása.
----
India delenda est.
Hülye pelikán

- szoktam GTK/GNOME alá alkalmazást írni
- a bajom igazából azzal van a hozzászólásaiddal, hogy az érved a JS (és egy másik szálban a PHP) mellett lebutítva az, hogy ezeket ismered.
Ezt kisarkítom: napi szinten használom a Verilog nyelvet (és tegyük fel, hogy kb. csak azt), írjunk rajta asztali alkalmazást (amúgy szerintem lehetne. Az eseményvezérlés meg piszok kényelmes volna. Meg a többszálúság. Kéne egy erre kihegyezett szimulátort írni...)!
- főleg a PHP-s kijelentéseid alapján (~"jó nyelv") azt látom, hogy egyelőre még nincs meg benned a kellő tudás ahhoz, hogy igényesen gondolkodj a kérdésben. Minden nyelvnek van hibája, de vannak dolgok, amiket eleve rossz, ha egy nyelv támogat.
- > just for fun: csak azért írni alkalmazást, hogy alkalmazást írjak, az a "szemétgyártás" veszélyével jár.

Összegezve: azt, hogy sokan ismerik, azt nem tartom érvnek a választás során.

Más oldalról is aggályaim vannak: nem hiszem, hogy te egyszerre egy alkalmazást fogsz futtatni, hanem jó sokat. Szerintem ilyen helyzetben sokkal jobban kiéleződnek a teljesítménykülönbségek.

"azt látom, hogy egyelőre még nincs meg benned a kellő tudás ahhoz, hogy igényesen gondolkodj a kérdésben"

Oh, mester, bocsáss meg, hogy nagyságod és tudásod beárnyékolta az én tudatlan és butuska hozzászólásom a topicban, ígérem többé nem fordul elő, és életem hátralévő részét annak fogom szentelni, hogy a Te végtelen tudásodnak parányi morzsáit felcsipegessem szánalmas kis tudatlan elmém táplálására.
Hiszen nem vagy Te tökéletes, hiányzik belőled a hiba! :)

________________________________
blog: http://horvathjanos.wordpress.com

Nehogy részrehajlással vádoljatok, legyen itt a C# mono verzió is (0,93x):


using System;

public class Prime {
    public static int COUNT = 10000000;

    public static void Main(string[] args) {
        int[] primeArr = new int[COUNT];
        int count = 0;
        for (int i = 2; i<=COUNT; i++) {
            int k = (int) Math.Sqrt(i);
            bool isPrime = true;
            for (int j = 2; j <= k; j++) {
                if (i % j == 0) {
                    isPrime = false;
                    break;
                }
            }
            if (isPrime) {
                primeArr[count] = i;
                count += 1;
            }
        }

        Console.WriteLine(count);
    }
}

gmcs prime.cs
time mono prime.exe

Na ugyanez (valóban) C#-ul:

using System;
using System.Collections.Concurrent;
using System.Diagnostics;
using System.Threading.Tasks;

namespace Prime
{
    class Program
    {
        private const int Count = 10000000;

        public static void Main(string[] args)
        {
            var sw = Stopwatch.StartNew();            
            var queue = new ConcurrentQueue<int>();

            Parallel.For(2, Count, (i) => {
                int k = (int)Math.Sqrt(i);
                bool isPrime = true;
                for (int j = 2; j <= k; j++)
                {
                    if (i % j == 0)
                    {
                        isPrime = false;
                        break;
                    }
                }
                if (isPrime)
                {
                    queue.Enqueue(i);
                }
            });

            sw.Stop();

            Console.WriteLine(queue.Count);
            Console.WriteLine("Time = {0}", sw.Elapsed);
            Console.ReadLine();
        }
    }
}

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

Benchmarkok. Mindkét esetben a MS Visual Studio 2012-t használtam. A méréseket kb. 3x futtattam, átlagoltam. Vas: Xeon E5-1620 (4 core, 8 thread, 10M cache), 32G ram (Quad channel, 51 Gb/s), sima mezei 64 bites W7. Csak a számolási részt mértem.

C++ "Debug profil" (O0): 7.400 sec (clock() fv-vel mértem)
C++ "Release profil" (O2): 6.902 sec

C# "Debug": 1,808 sec
C# "Release": 1,734 sec

Érdekesség: For() helyett ForEach() + tömb használata kb. plusz 50 ms-t okoz.

ConcurrentQueue-t Queue -re és a Parallels.For() -t sima for-ra cserélve:

C# "Debug": 7,207 sec
C# "Release": 6.916 sec

Érdekes. Debug módban ráver, Release módban egy hajszálnyival (0,2%) lassabb a menedzselt .NET, mint a natív C++.

Queue helyett int[]:

C# "Debug": 7,221 sec
C# "Release": 6,912 sec

Na ez még érdekesebb: debug módban még lassabb a tömb, mint a Queue (wtf?), release módban egy elhanyagolható mértékkel gyorsabb.

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

Mókás vagy inkább tragikus lenne kiszámolni, hogy a programozó nyeresége, hogy valami hatékony szkript nyelvet használ (ti. rövidebb fejlesztési idő /bár ezt pl. a C++ & Qt használata esetén még akár meg is kérdőjelezném/) mennyi felesleges energiafelhasználás és pénzkidobás az emberiségnek. Aki szerver programokat ír, ott ez csak halványan jelentkezik. Ha háromszor annyi ideig fut egy cronjob... Mindegy. Nincs különösebb jelentősége. (Bár itt is igaz, ha sok szerveren fut, és naponta több százezerszer az már szintén a következő kategória.) Ha ez milliók gépein fogyasztja folyamatosan az áramot? Teljesen mindegy, hogy Python, Perl vagy JS. Akkor a verdikt: PÉKLAPÁT a tarkóba!

A programozó nyeresége a lényegesen gyorsabb fejlesztési idő, a stabilabb program, vagy más oldalról: ugyanannyi munkaidő alatt több feature-t
kap a felhasználó.

Ha megnézzük, egy átlag GUI-s program nem igazán használja a CPU-t, inkább csak peak-ekben dolgozik. Innentől kezdve nagyjából lényegtelen,
hogy mennyivel lassabb (ha ez egyáltalán igaz) egy python,js,etc-ben megírt GUI, mint egy c++-ban, amíg a felhasználó számára elfogadható
teljesítményt ad.

Gondolom a meglévő lehetőségek közül választva annak látták értelmét, hogy legyen
egy köztes nyelv, amire implementálják a könyvtárakat - bár belegondolt már valaki,
hogy ez mekkora effort?? - aztán hogy efölött ki hogy használja, az már legyen a
fejlesztők dolga.

JS-sé forduló nyelvek: GWT (java -> javascript), Coffescript, Pyjamas (python->javascript), clojurescript, etc.

Es miert nem volt jo az eddigi C API?
Most miert lesz mindenbol JS API?

Amugy remelem tudod, hogy GWT-ben is csak JSNI-vel lehet tetszoleges JS kodot meghivni, masreszt az egesz DOM alapu, az EcmaScriptnek (sokaknak a JS ezt jelenti) pedig nem feltetele a W3C DOM API meglete, lasd Rhino es javax.script.

A trükk nem az, hogy van egy Widget/Canvas API mondjuk C nyelven, és e fölé húzzuk a saját
dolgainkat. A kérdés, hogy a Widget API fölött milyen egyéb, fejlesztést segítő megoldások
vannak.

Gondolok mindenféle layout managerre, speckó widget-re, adatbázis hozzáférési rétegre, XML kezelő rétegre, térkép megjelenítő könyvtárra, kép megjelenítőre, stb, stb.. a kérdés inkább az, hogy
ezt mennyire lehet a GTK-hoz kapcsolni, egyáltalán, 2013-ban van-e létjogosultsága egy GTK-n
alapuló GUI felületnek, nem kellene-e az egészet kihajítani, és újraírni 0-ról.

Teljesen egyetértek. Aki programozott már Gtk-t és Qt-t is, az szerintem egyetért velem: az egész miskulanciát újra kellene írni from scratch Qt alapon. Abban a fejlesztés újra öröm lenne, nem kínszenvedés, mint a Gtk fejlesztés C-ben, forráskódból felületet impementálva vagy Glade-del bénázva. A Gnome irányelvek jók (szerintem a KDE oltári bonyolult, túlzottan testre szabható, de nem szólok bele, virágozzék ezer virág), csak a programnyelv és a fejlesztői eszközkészlet tíz évvel ezelőtti. Sajnos.

Közben felvilágosítottak, hogy rossz szemüvegen át olvastam a topicot :$, és a JS-t _minden_ GNOME-os alkalmazásra, és nem a GNOME DE-t bővítő (remélem sikerült megfogalmaznom) alkalmazásokra választották, és így egyet kell értsek a nyitó hozzászólásoddal.
-
Reflection - a bajkeverő csodagyerek

Arra lennek kivancsi milyen fejlesztokornyezetet terveznek hasznalni a JS-hez (es abban mondjuk egy refactoring hogy mukodik).

Akik szerint pedig a teljesitmeny nem szamit kuldenem ezt a szamot. :)

Primitív ON:

- Úgy tudom a JAVA egy afféle runtime értelmező micsoda. Szerintem remek dolog. Kis, apró vacakságokra, afféle modulszerű izémizékre, amikből hol ezt, hol azt kell betölteni. Effélének megfelelő alkalmazási környezet lehet szerintem éppen például a Firefox. Vagy más böngésző. (Bár néha már az ide írt modulok is túlnőnek az illendő méreten...)

Na de egy egész olyasmi mint a Gnome?! Könyörgöm, ez majdnem olyan a szememben mintha a kernelt írnák JAVA-ban! Szerintem minden normális ember előtt nyilvánvaló kell legyen, hogy ilyesmit kifejezetten az "ősi", a "régi jó" C nyelven kell írni, semmi másban, mert azt épp erre találták ki. Pontosabban C++ -ban, de úgy, hogy ez nem igazi C++, csak "kevert nyelv", tehát alapvetően C, mindössze felhasznál néhány feature-ot a C++ lehetőségeiből. Azért ebben kell megírni, mert ez közvetlenül "gépi kódra" fordul. Nem valami "köztes nyelvre". Jó hogy már nem BASIC-ben akarják megírni a gnómot! De még ha C/C++ -ban írják is a gnómot, még ott is elvárom, hogy a sebességkritikus részeket kifejezetten assembly modulban írják meg közvetlenül. A C legnagyobb előnye épp az, hogy remekül össze lehet építeni vele efféle modulokat. Írtam efféléket még régebben anno...

A C, az "a programnyelvek angolja". MINDEN programozónak ILLIK tudnia, és a szememben egyszerűen szentségtörés, ha bármi kicsit is komoly dolgot nem C-ben (esetleg C++-ban, de már ez is meggondolandó...) programoznak le. Minden egyéb a szememben csak afféle játék, ami jó lehet valamely rendkívül speciális területre, de azért ne akarjunk már fogkefével kimeszelni egy egész házat...

Én nem azért óhajtok egyre nagyobb számítógépekbe beruházni, hogy a Progranyozó Uraknak könnyebb legyen a dolguk, és mert kevesebb idő alatt fejlesztenek le valami akármit valamely nekik kényelmesebb nyelven, emiatt a megírt kód oly szar lesz, hogy bár működik, de ötször erősebb processzor és tízszer annyi memória kell hozzá, hogy az alkalmazás 10 %-kal gyorsabban fusson, mintha a régi gépemen maradtam volna, de normálisan írják meg, tipikusan C-ben! Ne az én zsebem terhére legyen nekik könnyű munkájuk!

A C kifejezetten erre van kitalálva, tessék azt alkalmazni. Lehet hogy más nyelv könnyebb, de nem tud meghatni, a programozónak az a dolga hogy értsen ehhez, tanulja hát meg! Ha nem képes rá, menjen vagontakarítónak valami pályaudvarra. Mellesleg a C igazán nem nehéz, fogalmam sincs miért terjesztik ezt róla minden alap nélkül, én is megtanultam. Nagyonis remek nyelv.

Errefelé a HUP-on sokan megvetnek engem, mert nem tudok jól angolul. Mit szóljak akkor én, ha valami magát programozónak nevezni merészelő épp a C nyelvet nem ismeri, a "programnyelvek angolját"?! Ez messze nagyobb bűn a szememben. Szerintem kifejezetten tiltani kéne, hogy bármi más programnyelvet is első programnyelvként oktassanak, mint a C-t. Aki valami "könnyebbel" kezdi, az lehet hogy tényleg nehéznek találja majd, s fanyalog majd tőle. Nekem szerencsém volt, mert jóval a C előtt C-64-et programoztam gépi kódban. Ehhez képest a C nekem kifejezetten felüdülés volt, egy rém "magas szintű" nyelv.
A C után elkezdtem ismerkedni a Pascallal, csak úgy hobbiból, mert sokan ajánlották, de abbahagytam, mert a C nyelvet igenis SOKKAL KELLEMESEBBNEK, kényelmesebbnek találtam, könnyebbnek, még átláthatóbbnak is, a Pascal-nál úgy éreztem mintha kesztyűben mosnék kezet...

-------------
Blogom: http://violazoli.blogspot.com
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#

Te jó ég. Hogy ennyire fogalmad ne legyen...

A Java és a JavaScript két teljesen különböző nyelv, a Gnome-nak jelenleg semmi köze a virtuális gépen futó erősen statikusan típusos Java-hoz; a bejelentés arról szól, hogy a gyengén, dinamikusan típusos JavaScriptet akarják erőltetni.

> Na de egy egész olyasmi mint a Gnome?! Könyörgöm, ez majdnem olyan a szememben mintha a kernelt írnák JAVA-ban!
Szóval ha fogalmad sincs a típusosságról és úgy egyáltalán a programozási nyelvekről, az még nem akkora baj, pl. édesanyámnak sincs. Mindenesetre jegyezd meg: a Gnome-nak jelenleg nem sok köze van a Java-hoz, a JavaScripten gondolkodnak. Ez a mondat egy egész jó kiindulás ahhoz, hogy egy kis tudást felszedj. Ne szégyellj olvasni.

Legalább ennyi tudást próbálj összegyűjteni, mielőtt hozzászólsz! /o\

Szerk: bár a Java ~ JavaScript asszociáció felfedezése némi intelligenciát feltételez, a két nyelv nem szétvált, az egyikből fejlődött a másik, vagy ilyesmi, nem. Kb. semmi közük egymáshoz. Curly brace-es, C-szerű szintaktikával rendelkező nyelv mindkettő, ennyi. (Azért ez sem teljesen fekete fehéren így van, de ezen a szinten maradhatunk ennyiben)

Külön hozzászólásban pedig azt fejteném ki, hogy a lényeget sem sikerült elkapnod; Nem azért vezetik be a JS-t, mert nem tudnak C-ben programozni, hanem azért, mert akarnak egy olyan nyelvet, amelyen - megítélésük szerint - gyorsabban tudnak fejleszteni (pl. legyen menedzselt, ne a memóriafoglaláson kelljen vacakolni, hanem inkább a probléma megoldásán, stb.)

Amúgy abban van igazság, hogy sokan mivel tudnak (tudnak?) programozni valami magasabb szintű nyelven, rögtön szakértőnek hiszik magukat, holott az alattuk levő architektúráról, más módszerekről, nyelvi paradigmákról semmit nem tudnak. Na ők valószínű nem jó fejlesztők. Szerintem valahol egy kategória lehetnek a fórumokon sületlenségeket beszélőkkel.

Ennyi butaságot összeírva már régen láttam.

- A Java-ban (és java származékokban) készült kód egy köztes nyelvre fordul, amit aztán nem egy interpreter hajt végre, hanem a JIT compiler valós időben fordít
át gépi kódra. Sőt, manapság már a Javascript (aminek nagyjából semmi köze a java-hoz) is JIT-tel hajtódik végre, IONMonkey néven.

- Nem a GUI-t akarják átírni más nyelvre (bár ráférne), hanem az adott GUI-ra történő fejlesztéshez akarnak EGY programozási nyelvet használni. Gondolj arra, hogy
a notepad-et nem C-ben írják meg, hanem javascript-ben. Hát őszintén, nem teljesen mindegy? Az idő nagy részét azzal tölti, hogy arra vár, hogy az ember beüssön egy
karaktert.

- Ha már átírásnál tartunk: felejtsük már el ezeket a jó kis assembly-ben megkódoljuk dolgokat. Itt egy általános desktop-ról beszélünk, amit több különböző processzorra is le kell forgatni. Ha megirod x86 assembly-ben (és mégis melyik processzorcsalád melyik utasításkészletét használod, sse2 mehet??) az arm-on nem fog futni. A desktopon az tud normálisan gyorsítani, ha szépen fogjuk, és a videókártyával rendereltetünk le mindent, amit csak lehet, lévén az azért van. Nem terheljük a processzort, cserébe jó gyors lesz.
Érdemes elolvasni a windows 8-nál milyen komoly sebességnövekedést értek el ezzel a technológiával. A másik: a Gnome alapvetően a mai gépekhez készül. Baromira nem cél az, hogy egy 10 évvel ezelőtti gépen jól menjen. Ha valakinek az kell, használjon XFCE-t, vagy bármi hasonlót.

- A programozóknak igenis fontos az, hogy gyorsan tudjanak fejleszteni, hogy tényleg a problémával küzdjenek, és ne a környezettel. Egy átlag desktop alkalmazásánál
ne arra kelljen figyelni, hogy túlcímzek-e egy memóriatartományt, vagy hogy mikor szabadítottam fel egy pointert, vagy hogy hogyan kell összehegeszteni az idióta fejlesztők
idióta GUI engine-jében egy dialógust, hanem azzal, hogy a program logikája, amiért az egész program van, jól működjön. Érdemes megnézni, hogy mondjuk a QT-s QML-ben
(http://doc.qt.digia.com/stable/qdeclarativeintroduction.html) vagy egy JavaFX 2.0-ban FXML-ben (http://docs.oracle.com/javafx/2/api/javafx/fxml/doc-files/introduction_…) mennyire egyszerű és természetes egy GUI-t összerakni, aztán pedig style-olni. Ezután már tényleg csak a program logikájával
kell törődni.

"Érdemes elolvasni a windows 8-nál milyen komoly sebességnövekedést értek el ezzel a technológiával."

A probléma ott kezdődik, hogy poliverzum leragadt a w98-as világban és elképzelhetetlen számára, hogy bármi is változott.

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

DFM is sima textfile volt nagyjából hasonló szintaxissal. Igaz, ott kb. mindenki a kattintgatós módszert használta, mert azt korához képest jól összerakták. Bár az is igaz, hogy volt bináris formája, de azt AFAIK csak a fordító igényelte, és azt pakolta bele a végleges verzióba. (De azt a Delphi IDE amúgy is készítette magától.)

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

Jó indulatú leszek és feltételezem, hogy csak hülyéskedésnek és jó mókának szántad ezt a kommentet, és jót nevetsz majd, ha itt páraknak erre felszökik a vérnyomása.

Ha nem vagyok jóindulatú, és komolyan veszem amiket összehordtál ide, akkor csak simán meg kell állapítanom, hogy:
1. nagyon hülye vagy! :)
2. totál inkompetens vagy a témában!
3. szerintem nem hogy C-ben nem tudsz programozni, hanem még egy mosógép programját sem tudod megírni pszeudokódként, a hozzászólásodból és a leírtakból ez jön le!

LOL!

________________________________
blog: http://horvathjanos.wordpress.com

1) Ez JavaScript, az ég világon _SEMMI_ köze nincs a Java-hoz. a JS még csak nem is a Java OOP-ját hozza, hanem prototípus alapút némi funkcionális nyelvi beütéssel.

2) Írtak már kernelt Java-ban és C#-ban is. (Oké, Sing#) Jellemzően kutatási projektek, de az, hogy foglalkoznak a témával, azt jelenti, hogy van igény a menedzselt nyelvekre alacsonyabb szinten is.

3) A C nyelvet rendszerprogramozásra fejlesztették ki, *nem* alkalmazásfejlesztésre. Utóbbira alacsonyabb szinten a C++, magasabb szinten a Java, .NET nyelvek lennének alkalmasabbak.

4) A C-ről alkotott véleményed ugye a nagy C tapasztalatod mondatja veled.

5) C-ben semmiféle nyelvi szerkezet nincs arra, hogy de definiáljál egy modult. Tudsz structokkal bűvészkedni, hogy készíts valami interface jellegűt, de az a max.

6) Jó duma ez az X-szer annyi ramot eszik a program, mint 15 éve, csak azóta nem kell karaktertáblákkal szívni, van 32 bites kép, nem 8-16 bittel játszadozunk, elsimítás, képernyők nagyobb felbontásúak lettek, szoftverek meg integráltabbak, több mindenhez kapcsolódnak és nagyobb tudásúak is.

7) Miután egy árva vasat sem fizetsz a szoftverért, szerintem pont leszarom, hogy neked mibe kerül. Az, hogy hamarabb megvan, az ebbe kerül.

8) C-ben sokkal-sokkal egyszerűbb memleakes programot írni, mint Java-ban, C#-ban. Na meg azért fizetik a legtöbb progarmozót, hogy problémákat oldjon meg időre, nem azért, hogy a 486-osodra ráoptimalizáljanak mindent.

9) Ismétlem, a C nem kifejezetten erre lett kitalálva.

10) Látjuk milyen jól megtanultál programozni, szerintem ne te akard megmondani, hogyan kellene.

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

Dehogynem, van indok bőven.
Itt van néhány:

[ironia]
- A JavaScript az nem Java, C, C++, C#, Python, Vala, Scala, stb stb.
- Mert hogy fordítani kell, nem elég közvetlen és alacsony szintű nyelv
- Mert egy fos
- Mert nem szeretem
- Mert nem ismerem
- Mert most már nem tudom verni a mellem, hogy én tudok írni app-ot C-ben C++-ban Java-ban stb, mert Pistike is tud csinálni egy saját Gnome Todo listát JS-ben, hogy rohadna ki a bele!
[/ironia]

Sima hiszti van és sértődés, ezért pattog mindenki, nem annyira ökörbarom a Gnome csapat, hogy totális hülyeségből JS-t válasszon.

Én ennyire nem nézem le a Gnome csapatát, nem tartom hülyének Őket ahogy itt a többség teszi!

________________________________
blog: http://horvathjanos.wordpress.com

Biztos írják valahol, csak én nem vettem észre, vagy nem olvastam el mindent, de....

... mégis mikor és hol (verzió/kiadás/év-hónap-nap vagy valami) lesz lehetőség arra, hogy ezt a JS fejlesztési lehetőséget használjuk ha nem is élesben de legalább tesztelésre vagy ilyesmi. Valami Béta csomagot majd kilöknek 201*.**.**- án? Van erről pontos menetrend?

________________________________
blog: http://horvathjanos.wordpress.com

Mai gépeken úgy érzem van létjogosultsága a menedzselt nyelveknek, főleg ha a praktikusságot nézem. Gyors fejlesztés, könnyű bővíthetőség, nem is sokkal lassabb, rugalmas.

Eddig arról szólt a fáma, hogy az új GNOME kiadásokban sorra tűnnek el a Nautilus eddig meglévő funkciói kódtisztítás címén. Egyszerűen butább lett az egész. Ha a jövőben ezt elkerüljük akkor már megérte.