Petíció a Visual Basic 6 támogatása érdekében
2005. március 16. 12:47, szerda
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.

Hirdetés

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ó linkek
Laptopok

Már 49 900 Ft-tól!

E-book olvasók

Már 17 043 Ft-tól!

Tablet PC-k

Már 23 140 Ft-tól!

LCD monitorok

Már 19 800 Ft-tól!

részletek » részletek » részletek » részletek »
Megosztás
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
 

IT/Tech, Hardver
Tudomány, Mobil, Film, Játék
Hirdetés



Hozzászólások
A témához csak regisztrált és bejelentkezett látogatók szólhatnak hozzá!
Bejelentkezéshez klikk ide
(Regisztráció a fórum nyitóoldalán)
JeD  
2005. márc. 18. 21:30 | válasz | #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...
Frenzy  
2005. márc. 18. 15:25 | válasz | #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?
JeD  
2005. márc. 18. 14:30 | válasz | #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.
h4x0r  
2005. márc. 18. 13:00 | galéria | válasz | #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 :-)
Frenzy  
2005. márc. 18. 07:31 | válasz | #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. ;-)
h4x0r  
2005. márc. 17. 23:52 | galéria | válasz | #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?
Frenzy  
2005. márc. 17. 16:46 | válasz | #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.
Frenzy  
2005. márc. 17. 16:43 | válasz | #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 :-)
h4x0r  
2005. márc. 17. 16:33 | galéria | válasz | #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.
h4x0r  
2005. márc. 17. 16:30 | galéria | válasz | #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.
FTeR   "Rest in Peace FTeR" 
2005. márc. 17. 15:32 | válasz | #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
FTeR   "Rest in Peace FTeR" 
2005. márc. 17. 15:27 | válasz | #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)
h4x0r  
2005. márc. 17. 15:15 | galéria | válasz | #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 :-)
Frenzy  
2005. márc. 17. 14:15 | válasz | #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 :)
h4x0r  
2005. márc. 17. 13:34 | galéria | válasz | #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.
Frenzy  
2005. márc. 17. 13:02 | válasz | #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).
h4x0r  
2005. márc. 17. 12:40 | galéria | válasz | #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.
Frenzy  
2005. márc. 17. 12:35 | válasz | #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 )
Frenzy  
2005. márc. 17. 12:31 | válasz | #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.
2005. márc. 17. 11:06 | galéria | válasz | #15
A java nem alkalmas komolyabb batch jellegű alkalmazások futtatására, ez evidens, nem is arra van.
Zedas  
2005. márc. 17. 07:16 | válasz | #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ú :)
h4x0r  
2005. márc. 17. 01:31 | galéria | válasz | #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...
h4x0r  
2005. márc. 17. 01:28 | galéria | válasz | #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 :-)
FTeR   "Rest in Peace FTeR" 
2005. márc. 16. 20:45 | válasz | #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.
FTeR   "Rest in Peace FTeR" 
2005. márc. 16. 20:41 | válasz | #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 [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.
2005. márc. 16. 17:21 | válasz | #9
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.
2005. márc. 16. 17:20 | válasz | #8
én megtanultam rebootolni még DOS-os koromban és ennek jó hasznát veszem XP-nél is. Ennyit az elavulásról
lmisi  
2005. márc. 16. 17:07 | válasz | #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
2005. márc. 16. 17:06 | válasz | #6
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.
Frenzy  
2005. márc. 16. 16:40 | válasz | #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 ...
Frenzy  
2005. márc. 16. 16:35 | válasz | #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 :D
2005. márc. 16. 15:29 | válasz | #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
2005. márc. 16. 14:28 | válasz | #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.

Zedas  
2005. márc. 16. 14:20 | válasz | #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 :D
SZAKEMBER!!! Muhahahahahaaaaaaa!!!!!