Petíció a Visual Basic 6 támogatása érdekében
Jelentkezz be a hozzászóláshoz.
#34
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...
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...
#33
En ugy tudom ezt a JIT dolgot valahogy megturboztak a Java 1.5-ben, pont a .NET hatasara ... tudsz errol (vagy valaki tud errol) valami bovebbet?
\"The oldest and strongest emotion of mankind is fear. And the oldest and strongest kind of fear is fear of the unknown.\" /Howard Phillips Lovecraft/
#32
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.
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.
#31
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 :-)
A Java meg C# legyen felinterpretalt nyelv, az talan kevesbe felreertheto :-)
\"No boom today. Boom tomorrow. There\'s always a boom tomorrow. What? Look, somebody\'s got to have some damn perspective around here. Boom, sooner or later. BOOM!\" -- Lt. Cmd. Ivanova
#30
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. ;-)
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. ;-)
\"The oldest and strongest emotion of mankind is fear. And the oldest and strongest kind of fear is fear of the unknown.\" /Howard Phillips Lovecraft/
#29
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?
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?
\"No boom today. Boom tomorrow. There\'s always a boom tomorrow. What? Look, somebody\'s got to have some damn perspective around here. Boom, sooner or later. BOOM!\" -- Lt. Cmd. Ivanova
#28
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.
Azért rakom idézõjelbe, mert persze valójában ami benne van, nem olyan, mint a hagyományos .EXE fileok.
\"The oldest and strongest emotion of mankind is fear. And the oldest and strongest kind of fear is fear of the unknown.\" /Howard Phillips Lovecraft/
#27
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 .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 :-)
\"The oldest and strongest emotion of mankind is fear. And the oldest and strongest kind of fear is fear of the unknown.\" /Howard Phillips Lovecraft/
#26
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.
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.
\"No boom today. Boom tomorrow. There\'s always a boom tomorrow. What? Look, somebody\'s got to have some damn perspective around here. Boom, sooner or later. BOOM!\" -- Lt. Cmd. Ivanova
#25
Nem szolom le. Tenyleg jo dolog az egesz .NET. De ezt iram is. Csak nem eppen platformfuggetlen, de tenyleg, megvan ra a lehetoseg. Ezt mondtam.
\"No boom today. Boom tomorrow. There\'s always a boom tomorrow. What? Look, somebody\'s got to have some damn perspective around here. Boom, sooner or later. BOOM!\" -- Lt. Cmd. Ivanova
#24
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 <#ejnye1><#banplz><#vigyor3>
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 <#ejnye1><#banplz><#vigyor3>
#23
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)
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)
#22
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 :-)
\"No boom today. Boom tomorrow. There\'s always a boom tomorrow. What? Look, somebody\'s got to have some damn perspective around here. Boom, sooner or later. BOOM!\" -- Lt. Cmd. Ivanova
#21
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 😊
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 😊
\"The oldest and strongest emotion of mankind is fear. And the oldest and strongest kind of fear is fear of the unknown.\" /Howard Phillips Lovecraft/
#20
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.
\"No boom today. Boom tomorrow. There\'s always a boom tomorrow. What? Look, somebody\'s got to have some damn perspective around here. Boom, sooner or later. BOOM!\" -- Lt. Cmd. Ivanova
#19
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).
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).
\"The oldest and strongest emotion of mankind is fear. And the oldest and strongest kind of fear is fear of the unknown.\" /Howard Phillips Lovecraft/
#18
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.
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.
\"No boom today. Boom tomorrow. There\'s always a boom tomorrow. What? Look, somebody\'s got to have some damn perspective around here. Boom, sooner or later. BOOM!\" -- Lt. Cmd. Ivanova
#17
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 <#hehe>)
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 <#hehe>)
\"The oldest and strongest emotion of mankind is fear. And the oldest and strongest kind of fear is fear of the unknown.\" /Howard Phillips Lovecraft/
#16
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.
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.
\"The oldest and strongest emotion of mankind is fear. And the oldest and strongest kind of fear is fear of the unknown.\" /Howard Phillips Lovecraft/
#15
A java nem alkalmas komolyabb batch jellegû alkalmazások futtatására, ez evidens, nem is arra van.
I7-4790K, ASUS SABERTOOTH Z97 MARK2, 16GB DDR3, ASUS STRIX GTX970 4GB 2xSLI, Samsung 256GB SSD 840 Pro MLC, 10.5TB HDD, Dell U2711H (2560x1440), CM Stryker, Scythe Mugen 3
#14
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ú 😊
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ú 😊
#13
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...
Es a Java is elegge platformfuggetlen. Hatekonysaghoz annyit, hogy a Java tetulassu...
\"No boom today. Boom tomorrow. There\'s always a boom tomorrow. What? Look, somebody\'s got to have some damn perspective around here. Boom, sooner or later. BOOM!\" -- Lt. Cmd. Ivanova
#12
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 :-)
\"No boom today. Boom tomorrow. There\'s always a boom tomorrow. What? Look, somebody\'s got to have some damn perspective around here. Boom, sooner or later. BOOM!\" -- Lt. Cmd. Ivanova
#11
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.
#10
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
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.
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
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.
Amúgy meg OBJEKTUM ORIENTÁLT DESIGN LOL
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.
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.
Ha már kivan a faszod az idióta szignókkal csinálj te is egyet.
én megtanultam rebootolni még DOS-os koromban és ennek jó hasznát veszem XP-nél is. Ennyit az elavulásról<#vigyor3>
Ha már kivan a faszod az idióta szignókkal csinálj te is egyet.
#7
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<#vigyor2>
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.
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.
Intel.DZ77RE-75K.Core.i7-3770K.32GB.RAM.360GB.RAID.SDD.8TB.RAID.HDD.GTX660Ti.Dual.NEC.Windows.10.Enterprise Apple.Mac.mini.Core.i7-3615QM.16GB.RAM.1TB.HDD.OS.X.El.Capitan
#5
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 ...
Ú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 ...
\"The oldest and strongest emotion of mankind is fear. And the oldest and strongest kind of fear is fear of the unknown.\" /Howard Phillips Lovecraft/
#4
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 😄
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 😄
\"The oldest and strongest emotion of mankind is fear. And the oldest and strongest kind of fear is fear of the unknown.\" /Howard Phillips Lovecraft/
#3
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
#2
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.
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.
#1
"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 😄
SZAKEMBER!!! Muhahahahahaaaaaaa!!!!!
Ezen öt percig röhögtem 😄
SZAKEMBER!!! Muhahahahahaaaaaaa!!!!!