Hat, sajnos ezt nem tudom... Mindenesetre a Java 5-ot a sebesseggel reklamozzak. Amit olvastam itt-ott (semmi reszletbe menot), az alapjan probaltak javitani a startup time-on (hogy kell ezt szepen mondani magyarul? :)), illetve a JIT eseteben az adaptivitasra helyeztek nagyobb hangsulyt a parancssori argumentumok helyett. + van a performance management-re/profiling-ra is vmi uj API. Igazabol ami tenyleg gondja a Javanak az a memory footprint, mert az bizony eleg kriminalis tud lenni (bar nemcsak nala, en pl. a Firefox-on is csodalkozom neha >:|). Erre is bevezettek egy-ket dolgot, pl. a memoriamegosztast a JVM-ek kozott. Mas kerdes, hogy ha en csak 1 Java programot futtatok, akkor ebbol nem sokat latok...
A Javahoz 1-2 megjegyzes: Eros tulzas a hellowordos dolog, eleg szep progikat lehet irni, amik siman platformfuggetlenek maradnak.
Az se igaz, hogy tetulassu lenne. Just in time forditas mar eleg regen van benne (1.4-tol biztosan, de gyanus, hogy mar 1.3.x-tol is), ami azt jelenti, hogy a VM a bytekodot nativ kodra forditja, es ugy futtatja. Ami kulonbseg, hogy ezt futasidoben teszi (legalabbis 1.4 kornyeken igy volt), ezert a program lassabban indul, de utana begyorsul. Nativra fordulas utan a kod adott esetben akar gyorsabb is lehet, mint egy C++ progi! Vannak benchmarkok, utana lehet nezni. Atlagban egy java kod 1,2-1,5-szor annyi ido alatt fut le, mint az ugyanazt a feladatot ellato C++ -- ezt azert nem neveznem hihetetlenul lassunak...
De akkor miert is el meg mindig a java lassu legenda? Fokent ket okbol. Az egyik, hogy lassan jon fel. Nyilvan be kell tolteni a JVM-et, utana programot betolteni, leforditani nativra a leggyakrabban hasznalt dolgokat (nem biztos, hogy ekkor csinal ilyet, bar szerintem igen, a konyvtari fuggvenyeket), ez pedig eltart egy ideig, es eleg szembeszoko. A masik, hogy egy naivan megirt Java kod nativan is lassabb lesz (akar 4x), mint egy naiv C++ kod. Naivot ertsd ugy, hogy behivod x-et az utcarol, tartasz neki egy hetes tanfolyamot, es megiratod vele :) Azonban normalis, a nyelv tulajdonsagait figyelembe vevo kod eseten ez a kulonbseg eltunik, es a fenti aranyok valosulnak meg.
A C-s tudas az stimmel, egyre kevesebben ertik, viszont meg mindig vannak dogivel C-s cuccok. Ezek tobbnyire joval gyorsabbak a C++-os cuccoknal, legalabbis ami a forditasi idot illeti.
A Java meg C# legyen felinterpretalt nyelv, az talan kevesbe felreertheto :-)
Ez valóban így van (C-s tudás, bár inkább C++ -t mondanék). A Microsoft ugye nagyon nyomja a .NET-et, szeretné, ha ez lenne a Windows fejlesztõk fõ eszköze. Gyakorlatilag aki nem rendszerprogramot (drivereket) ír rá, használhatja. Még játékot is lehet írni (DirectX-eset) C#-ban, és nem is lesz sokkal lassab mint egy C++-ban megírt játék, fõleg ha tekintetbe vesszük, mit nyújt még a CLR (Common Language Runtime) a programnak (milyen környezetet).
Azt írod, hogy maradsz a lefordított nyelveknél .. amikor futtatsz egy .NET programot, az is lefordított. Úgyhogy ilyen szempontból nincs különbség egy C++ és C# között, midnkettõ lefordított (amikor fut) ;-)
Az interpretációról szólva ezt már észrevettem, hogy a szó eredeti jelentése mellé egy másikat is használni szoktak. Ugye eredetileg ez azt jelentené, hogy semmilyen fordítás nincs, és a futtató rendszer sorról sorra (vagy utasításról utasításra) olvassa a forrásszöveget, és értelmezi azt. Ha valamin kétszer meg végig, akkor kétszer értelmezi. És ezek alapján a Java persze nem interpretált, mivel ugye ott bytecoda-ra fordul, és a VM futtatja a bytecode-ot (és az eredeti forrásszöveg már nincs is képben).
Csak aztán elkezdték erre a megoldásra is használni az interpretált szót. Én sem vagyok jobb, én is ezt használtam/használom rá, mégha pontatlan is. Ebben az értelemben az interpretáció azt jelentené, hogy nem natívan, a processzor által fut a kód, hanem valami másik program (pl. VM) futtatja azt.
Persze FTeR azt írta, sorról sorra megy, az persze kicsit pontatlan. ;-)
Frenzy: Ez mind szep es jo, mondtam, hogy nem szolom le a .NET-et. De a Java virtualis kod lenyege pont az volt (anno, lehet, hogy mar valtozott a helyzet), hogy maga a byte-kod is atviheto. Persze ha a .EXE is platformfuggetlen, az tenyleg dicseretes, es az is, hogy mindez szabvany. Csak azzal volt gondom, hogy FTeR alapbol leszolta a Java-t, eloszor, hogy nem interpretalt, masodszor, hogy "sorrol-sorra" interpretalt. Ez igy egyik sem igaz teljesen.
Amugy mar reg tervben van nalam is a .NET (meg a Java, ahoz csak minimalisan ertek), de mindig is zavartak az interpretalt nyelvek. En maradok a hagyomanyos, leforditott nyelveknel. Amugy ez tenyleg OFF, de szerintem az interpretalt nyelvek terjedesevel egyre ertekesebb lesz a C-s tudas pl... Velemenyek?
Ja igen, a Monoról még, hogy azért elég jól állnak az implementációval. Én nem egy kisebb C#-ban írt, Windows alatt lefordított .EXE-t másoltam fel Linuxra, és ugyanaz az ".EXE" futott.
Azért rakom idézõjelbe, mert persze valójában ami benne van, nem olyan, mint a hagyományos .EXE fileok.
A .NET köztes kódja - hivtalos nevén IL, vagyis Intermediate Language - kb ugyanazon a szinten van mint a Java bytecode. Azonban nem ez fut! (és ezért nem is bytecode)
A .NET futáskor valóban lefordítja natív kódra a programot. Vagyis futás elõtt elkészül az a bináris, gépi kódú program, ami futni fog. Nem történik semmilyen interpreter dolog, innentõl kezdve nincs bytecode vagy IL, hanem tényleges kód fut.
A folyamatot JIT-nek, Just-In-Time fordításnak hívják, mert azokat a részeket fordítja csak le, amikre szükség van - amik futni fognak. Ezért nincs virtuális gép sem, mint Javaban, ami a bytecode-ot futtatja. Ugyanis .NETben az igazi gép futtatja a programot. JIT során valóban úgy történik, ahogy itt már korábban is írta FTeR, hogy amit egyszer lefordított, többször már nem fogja.
.NET-ben megvan a lehetõség, hogy elõre legeneráljuk a natív programokat. Így pl. setupnál le lehet generálni az adott gépre a dolgokat, amiket utána már JIT fordítani sem kell, egybõl futnak.
Ennek az eljárásnak az elõnye (vagyis amit állítanak róla), hogy valóban az adott platformra lesz optimalizálva a kód, amin futni fog, mivel a tényleges és végleges fordítás a célgépen történik meg. Mivel maga a fordítás lassú is lehet, ezért történik JIT módon.
Ezért lehet a .NET nagyon gyors. Mivel ami fut, az valójában lefordított kód. .NET kódot sosem interpretálnak.
A Java korábbi verzió azt hiszem interpretálták a bytecode-ot, ezért volt lassúcska. Az új Java 1.5 (vagy Java 5, ahogy hívni szeretik) viszont már tartalmaz valami JIT szerûséget, pontosat errõl sajnos nem tudok, én a .NET oldalon ragadtam :-)
A Java kodon sem megy vegig a fordito mindig, hanem keszit egy un. byte kodot (.class vegu fileok) es a JavaVM ezt futtatja. Ezt az otletet hasznalja a C# is: eloallit egy - asszem - .obj file-t, amit mar csak linkelni kell.
Csak az a kulonbseg, hogy mig a Java byte kod atviheto a gepek kozt, addig a C#-nal ujra kell forditani pl. Linuxhoz a Windowsos kodot.
linuxosoknak egyértelmû érdeke hogy elkészüljön minden disztibre a cucc, tehát amint sok alkalmazás lesz, netán játékok, el is fog készûlni. A OSS ben (linux) pont az a szép, hogy megvan a lehetõség mindenre, erre itt egy M$ próbálkozás ami mindent megenged amit kell, erre leszólod, ejej
az M$ fajtájából adódóan soha nem fog linux alá támogatni és pl soha nem fog olyan nyelveket implementálni a VSbe amit nem szeret, de a lehetõség megven (mint írtad) és ez a lényeg. A többi nem számít. Az a lényeg, hogy ha a framework-öt rendesen elkészítik linuxra, akkor minden .Net-ben írt alkalmazás menni fog rajta, anélkûl hogy át kéne fordítani. És M$ mindent megtesz, hogy a winre fejlesztés .Net-et jelentsen.
Legnagyobb külömbség a java és C# platformfüggetlenségében, hogy még JVM a köztes kódon sorról-sorra megy és fordítja minden egyes alkalommal (többek között ezért is lassú), addig a C# köztes kódja már egy majdnem rendes .exe amit a framework úgy 'véglegesít', hogy megnézi neme volt már ez a kód egyszer lefordítva ezen a gépen, ha nem akkor lefordítja, ha igen akkor már azt futtatja. Tehát a framwork egyszer elkészít gépenként egy platform függõ kódot (pl a cd-n lévõ köztes kódból) és onnantól kezdve az bármikor futtatható, míg a JVM maga a köztes kód felé egy (mint a neve is jelzi) virtuális gépet mutat így egységes platformot létrehozva, amin keresztûl aztán futtatja az alkalmazást a valós platformnak megfelelõen. Azt hiszem könnyen belátható, hogy mennyivel jobb a .Net megoldás (szándékosan nem C#ot írtam, mert minden nyelvre igaz ami a framework-ot használja - ez olyan mint pl web lapoknál/böngiknél ismerni a DOM-ot)
En most itt a platformfuggetlenseg alatt azt ertettem, hogy az adott Java fordito es VM egy csomo rendszerhez megvan, es ott (mind a bytekod, mind a forras) ugyanugy hasznalhato marad. Ellenben pont itt mondtak, hogy a Mono nem ad teljes .NET frameworkot. Ettol meg mindket nyelvet jo dolognak tartom, de en maradok a C-nel :-)
Javíts ki ha tévedek, de asszem pont nemrégiben volt arról szó, hogy a Sun megnyissa-e a Java forráskódját vagy sem, és (bár a végsõ döntést nem tudom mi lett) azzal tiltakoztak ellene, hogy félnek a fejlesztés különbözõ irányokba megy el, amik nem lesznek kompatibilisek egymással.
Szerintem azzal, hogy valami rögzített és szabványos, ha nem is teljes mértékben, de valamilyen szinten elkerülhetõk az efféle vitás helyzetek.
Nem szerettem volna azt sugallni, hogy a Java nincs specifikálva rendesen, hanem hogy bár nincs direktben támogatás a Monohoz, azért a szabványosításnak hála az implementáció nem okoz akkora problémákat. Valamint azt, hogy mivel a Java nem szabvány, ezért a különbözõ implementációk között elképzelhetõ valamilyen szintû eltérés ... vagy ilyesmi :)
Igen, ez tenyleg igy van, de attol, hogy a Java meg nem szabvany, az nem azt jelenti, hogy a Java mint nyelv nincsen jol specifikalva. A Sun Java implementacioja szamit hivatalosnak igazabol, legalabbis szerintem. Persze ettol meg nem szabvanyos, de nem is ezt vitattam.
Lehet, hogy MS nem támogatja a Monot, de mivel az MS implementáció is a bejegyzett szabványt valósítja meg, és a Mono is, ezért 100%-ban kompatibilisek egymással (a gyakorlatban talán nem, mivel nincs a teljes framework implementálva Monoban).
Ezzel szemben a különbözõ cégek (most ne csak MSre gondoljunk) Java implementációiról ez nem feltetlenül mondható el.
A .NET Framework jelentõs része meg C#-ban van megírva, bizonyos részei (ASP.NET) gyakorlatilag teljesen. Nem is beszélve a fejlesztõeszközrõl (Visual Studio is .NET-es program).
A monot az MS nem tamogatja, OSS cucc. Tudok rola amugy, hogy van ilyen. De mig a Sun ad tamogatast a Java Windowsos, Linuxos, Solarisos, ... verzioira (x86-on, PPC-n, sparc-on, ...), addig az MS csak a Windowsos verziokra ad ilyet. De az dicseretes, hogy meghagyta a lehetoseget a platformfuggetlensegre :-)
Amugy lattal mar Java programot? Egyik haverom most irt egy swing-es, jdbc-s egyszeru alkalmazast, es azzal semmi gond nem volt egyik rendszeren sem. Az meg egy masik dolog, hogy a Java osztalyok jelentos resze Javaban van irva. Csak minimalis a nativ cucc.
Valóban, már létezik is open source alternatíva, a Mono projekt személyében, mely ha nem is nyújt teljes .NET Framework implementációt, azért meglepõen figyelemre méltó dolgokat lehet vele csinálni, pl. Linux alatt.
S mindez azért valósulhat meg, mert a C# nyelv és a .NET Framework / CLR az ECMA által szabványosítva van, ahogy te is írtad. (ellentétben a Java-val ... nem állom meg, hogy ezt hozzá ne tegyem )
Hatékonyságban a program hatékonyságára gondoltam, nem pedig a programozásbeli hatékonyságra (produktivitásra). Konkrétan VB-ben valami 3D játékot, eszközmeghajtót vagy valami matematikai számolgatót és hasonlókat nem igen szép írni (vagy nem is lehet).
Vagyis ahol számít a (számítási) teljesítmény, ott nem volt épp a legalkalmasabb nyelv.
A szakember kérdéshez annyit, hogy talán én fogalmaztam félreérthetõen. Mert valóban, az hogy képtelen fejlõdni, újat tanulni, és átállni azt mutatja, hogy nem igazi szakemberrel van dolgunk. Amit én akartam sugallni az az, hogy attól hogy valaki VB-ben dolgozott, még nem kell egybõl leírni, mint valami hozzá nem értõt.
A java nem alkalmas komolyabb batch jellegû alkalmazások futtatására, ez evidens, nem is arra van.
Már létezik .net keretrendszer unitx alá is, mono néven, úgyhogy nem nyertél.
A Java meg abban az esetben platformfüggetlen, ha csak a helóvördöt szeretnéd benne implementálni. Ha már interfész van a dologban már bukik az egész, cserébe viszont hihetetlenül lassú :)
Platformfuggetlen nalad az, hogy WinXP-n es Win98-on is fut??? Esetleg mi van azokkal a UN*Xos progikkal, amik futnak *BSDn, Linuxon, QNX-en, stb. es mondjuk x86, Itanium 2, stb. architekturakon is?
Es a Java is elegge platformfuggetlen. Hatekonysaghoz annyit, hogy a Java tetulassu...
Vannak RADok, amik kicsit komolyabbak a VB-nel, mint pl. a Delphi vagy C++Builder. Ezekkel szinte pillanatok alatt lehet egyszerubb adatbazisalkalmazasokat irni. Persze lehet, hogy a VB jobb valamiben, de ezek sem rosszak :-)
a #7#8-nak mondom, hogy ha Xp-ben sokszor kell reszetelni, akkor azon nem tud jobban segíteni az M$, júzer errorra nincs orvosság.
figyelmedbe ajánlom a #5 kommentet a kidobással kapcs. Másrészt a .Net platformfügetlen megoldás, úgyhogy mindenki csak áljon át rá. (a framework szabadon átírható bármire - ráadásúl megoldásaiban sokkal jobb mint a javaVM).
-----
Sztem a C#-é a jövõ, sok nyelvet kipróbáltam már, de még egyik sem "tetszett" ennyire. Szerencsére a szintaktika C, ami már magában jó (a VB szintaktika nem szakembernek való, az arra van, hogy ha valakit behívunk az utcáról gond nélkûl elolvassa és megérti...), plusz a C# átvett sok nyelv jó megvalósításait és tanúlt a hibáiból (van benne C, delphi és java is). Maga a .Net meg csak fokozza az elõnyeit. Tök mind1 milyen nyelven írsz meg egy komponenst, bármikor bármilyen másik nyelvbe meghívhatod (tehát nem kötelezõ 1 programot 1 nyelven írni, több emberes munkánál ez nagyon jó). M$ már eleve sok nyelvet támogat, de bárki szabadon bõvítheti a készletet (én pár hónapja tettem fel hozzá php-t [igaz még nem az igazi, de haladnak vele]). Egyébként a C# szabványosított nyelv, a java-val ellentétben.
A programozó tanszék vezetõlye mondta, hogy a VS.Net nem is VS 7, hanem legalább VS 10, akkora fejlõdésbeli különbség van benne.
Most szépen dobhatod ki a régi komponensedet és az, aki windows-alá kérte a fejlesztést, az végre átáll valami platformfüggetlen megoldásra.
C/C++ rulez, M$ C sucks.
én megtanultam rebootolni még DOS-os koromban és ennek jó hasznát veszem XP-nél is. Ennyit az elavulásról
Hát igen, ha valaki Microsoftos eszközökbe fekteti tudását, számoljon a gyors avulással. Bár ha belegondolok, aki megtanulta w98-on a reboot sokszor segít a rendetlenkedõ alkalmazásokon, az wendowsxp is jó hasznát veszi ennek tudásbázisnak. Röhejes de így van
A VB-ben nagyon sok alkalmazás és ahogyan magad is mondod üzleti komponens lett megírva és ez szimplán OK, mert a VB erre nagyon is megfelelõ volt, aki használta vállalati környezetben az tudja miröl beszélek. De viszont egyet kell értenem Zedas-al a SZAKEMBEREK jelzõvel kapcsolatban, ugyanis az akinek nem volt elég kb. 3 év (amióta a .NET produkcióssan is elterjedt, adjunk ehhez még 2 év beta meg preview kiadásokat stb.) az átálláshoz, és vegyük figyelembe, hogy már évek óta az MS egyáltalán nem foglalkozik a VB-el, lehetetlen már évek óta akármelyik szakfolyóiratban a .NET en kivüli MS technológiákról olvasni (MSDN Magazine, Code Magazine, Windows.NET Magazine stb. hogy csak a legismertebbeket említsem), azt nem igazán nevezném szakembernek, ugyanis a szakember jelzõt szerintem csak azokra lehet alkalmazni, akik fejlõdnek és akik nem félnek a kihívásoktól, nem pedig azoknak akik beragadnak és nem mozdulnak sehová, mert nekik ott ahol vannak tetszik... tehát olyan, hogy VB6 szakember szerintem nincs (volt de már nincs) azok akik szakemberek és VB-n keresik a kenyerüket azok mind egy szálig vagy VB.NET-re váltottak, de ismerek sokat akik egyenessen a C#-ra tértek át, mert ha igazat mondunk akkor a VB.NET-nek nem igen van értelme, mert 95%-ban C# (egy pici sintax különbséggel) és ezért sokan meglépték a lépést és VB to C# lett a mese. Szerintem aki maradt a VB6-nál az soha sem volt szakember még akkor sem amikor a VB6 új volt, mondom ezt mint olyan személy aki sok ezer (tizezer) sor kódot irt meg VB-ben (éppen azért mert egyszerübb és praktikusabb volt mint C++ ban ahogyan te is mondod) de még többet C/C++/C#-ban.
P.S. nem tudom mit értessz a hatékonyság alatt, de a VB6 hatékonyabb volt a C, C++, Java-tól éppen ezért is terjedt el, mert produktivitás szempontjából nem volt neki konkurenciája egésszen a .NET nyelvek megjelenéséig. Ja és egy nyelv komolyságáról beszélni butaság, nincs komoly vagy komolytalan nyelv, csak mindennek megvan a helye... ez kb. ugyanaz, mintha pl. a jármûvek világában egy biciklire azt mondanák, hogy komolytalan mert persze egy jumbo jet komoly, egyszerûen a kettõ nem hasonlítható össze, de egyikre sem lehet mondani, hogy jobb vagy komolyabb, csupán tudni kell melyikkel gyõz az ember ha az adott pillanatban használja. VB-ben sokszor megiród az alkalmazást (bug nélkül) míg pl. C++ ban még az elõkészületeknél tartanál és ekkor butaság C++ használni, viszont van alkalmazás ahol a VB-vel nem érdemes foglalkozni a C++ meg anyanyelv... de próbáltál már akermelyikkel web oldalt készíteni... mert azt hiszem ide egyik sem lenne jó, és ezért valaki buta alapon nevezhetné komolytalannak õket a HTML-t meg komoly nyelvnek.
Hát ugye a Visual Studio .NET változata 2002-ben jelent meg, és abban már új, VB.NET változat volt. Vagyis legkésõbb akkor meg lehetett tudni, hogy a VB-nek vége. Már akkor is mondták, hogy aki a klasszikus VB-t akarja, használja a 6-os verziót.
Úgyhogy hogy mostanra ilyen csapás legyen ez a dolog, elég meglepõ. Majd három év lett volna átállni, és ha az emberek jobban megnézik ezt a COM alapú dolgot, akkor azért rá lehet jönni, hogy az nem igazán jó mindenfélére, igazából egy 90-es évek elején írt technológia (OLE) foldozgatása.
Ezzel szemben az MS is elkötelezte magát a .NET-hez, és az abban megvalósított technológiák mellett, ami szerintem értelmes és jó elõrelépés a COM-mal szemben. És idõ is lett volna átállni.
Ezen felül .NET környezetbõl könnyen és egyszerûen hívhatók COM komponensek, és írhatók komponensek, amiket régi COM felületen lehet meghívni, vagyis a kompatibilitása is megmaradt, még hogyha a rendszer változott is. Így fokozatosan is át lehet rá állni, hogy kezdetben használjuk a régi komponenseket.
Ezért nem is egészen értem a felháborodást. Ilyen alapon lehetne azon is háborogni, miért nem FORTRANban programozunk még mindig ...
Te is jó sokat tudsz vállalati környezetrõl. Nagyon sok üzleti komponenst Visual Basic nyelven írtak meg, meg egyszerûen és gyorsan lehetett (a cikkben is említett) COM alapú komponenseket és programokat írni vele (vagy pl. felhasználói felületet építeni).
Az más kérdés, hogy mennyire hatékony egy VB-ben megírt program. De bizonyos célok elérése könnyebben és gyorsabban nyújtott megoldást, még hogyha más környezetekkel szemben viszonylag sok megkötést is tartalmazott.
Elég csak arra gondolni, hogy adatbázis alapú programot mennyivel nehezebb egy C++ (Win32 API, MFC) környezetben megírni, mint VB-ben. Innentõl kezdve teljesen érthetõ, hogy sokan egyszerûbb dolgokra (pl. adatbeviteli rendszerek, stb) VB-ben írtak dolgokat.
És bár hatékonyságát tekintve nyílván nem veheti fel a versenyt mondjuk a C-vel, C++-szal, Java-val vagy .NET nyelvekkel, azért megvan (megvolt) neki is a helye. És persze a megfelelõ használatlához igenis szakemberek kellenek.
Mielõtt megszólsz azért, én sosem használtam, és nem is szeretem, mert ... hmm .. nem találom elég komolynak :D
Igazából én szeretem a VB6-ot de ha valaki tényleg valami érdemleges dolgot szeretne alkotni akkor ott a C, C++, és még számos olyan nyelv ami régóta életképesebb mint a VB. A VB viszpnt nagyon 1szerû azért hiányozni fog
Kell egy kis átmeneti idõ. Mondjuk az MS megmondja, hogy még két évig lesz support, addig tessék szépen átálni. De már egy jópár éve van .net, és szerintem a fejlesztõk is tudják, hogy erre vezet az út. Meg nem hiszem, hogy az MS egyik nap kigondolta, másik nap meg megvalósította ezt. Persze megtanulni egy nyelvet nem két perc, viszont ha van egy jó alap, akkor sokkal gyorsabban megy.
Persze bele lehet magyarázni, hogy az MS kényszerít, hogy így hátha többen vesznek VS.net -et. Az tény, hogy ha nem kell VB 6-al foglalkozniuk, akkor erõforrás szabadul fel.
Az az igazság, hogy hamarosan(vagy már most) .net vagy JAVA nélkül nem megy egy programozó semmire.
"megszûntetik a Visual Basic 6 alap támogatását, rendkívül kényelmetlen helyzetbe sodorna több millió szakembert, akik nem ismerik az új programozási nyelveket"
Ezen öt percig röhögtem :D SZAKEMBER!!! Muhahahahahaaaaaaa!!!!!
Informatika és tudomány
)
