SG.hu·2005. március 16.

Petíció a Visual Basic 6 támogatása érdekében

Több mint száz, a Microsoft fejlesztői csomagját használó fejlesztő írta alá a szoftveróriásnak átadott petíciót, amelyben a Visual Basic 6 támogatásának meghosszabbítására kérik a vállalatot.

A fejlesztők - akik szinte kivétel nélkül a Microsoft Most Valuable Professional program tagjai - azt állítják, hogy a vállalat döntése, miszerint 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. A Microsoft nemrég jelentette be, hogy megszűnik a fejlesztői csomag alap, díjmentes támogatása, ami magában foglalja a kritikus biztonsági hibák javítását is. A tervek szerint a támogatás - a megfelelő díj befizetése ellenében - további három éven át lesz elérhető.

A fejlesztők nagy része azonban arra igyekszik rávenni a vállalatot, hogy hosszabbítsa meg az ingyenes támogatást, mi több, a Visual Basic.Net mellett folytassa a régebbi verzió fejlesztését. "Egy újabb, COM-alapú Visual Basic megjelenése egyértelmű bizonyítéka lenne annak, hogy a Microsoft továbbra is elkötelezett az alap Visual Basic iránt, és egyben jelentős segítséget nyújtana azoknak, akik már tervbe vették a .Net rendszerre történő átállást. Az átállás időpontjának meghatározása a vásárló saját döntése kell hogy legyen" - áll a petícióban.

Sokak szerint azonban ez az átállás korántsem lesz ilyen könnyű, mivel a .Net rendszer elsajátítása ugyanolyan vesződséggel jár, mintha egy teljesen új programozása nyelvet szeretnénk megtanulni. "A .Net verzió csak nevében Visual Basic. Minden egyes vállalat, vagy egyéb szervezet kénytelen befagyasztani eddigi fejlesztését, és az alapoktól kezdve újra fel kell építeniük a kódot" - áll Rich Levin nemrég közzétett blogjában.

Az átállás lassúságát jelzi, hogy a felmérések szerint az észak-amerikai fejlesztők csaknem fele - mintegy 45 százalékuk - továbbra is ragaszkodik a Visual Basic 6-os, vagy még annál is korábbi verziójához, és mindössze 34 százalékuk használja a Visual Basic.Net csomagot. Ez meglehetősen nagy számot takar, mivel az észak-amerikai fejlesztők 54 százaléka használta már életében a Visual Basic valamely verzióját.

Kapcsolódó cikkek és linkek

Elkészült a Visual Studio 2005 második bétája Új Visual Studio eszközök Office-hoz Új Borland fejlesztőeszköz célozza a Visual Studio.Net helyét Megjelent a Visual J#.Net Visual Basic.Net: megéri a váltás?A fejlesztők zúgolodnak az új MS Visual Basic miatt Microsoft ↗

Hozzászólások

Jelentkezz be a hozzászóláshoz.

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...

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?

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.

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.

További bejegyzések a fórumban...