Delphi - érdemes vagy nem ?
2004-04-23T10:22:46+02:00
2004-05-03T16:03:47+02:00
2022-07-27T12:44:00+02:00
  • Ebben van valami. Ennek ellenére Delphi coder és Delphi coder közt is jelentős különbségek tudnak lenni... Persze a környezetismeret is sokat számít de egy rendszer megtervezéséhez és megvalósításához ennél jóval több kell. Az adatstruktúrában, algoritmusban, objektumszerkezetben, folyamatokban való gondolkodást nem lehet két hét alatt elsajátítani és nem is mindenkinek sikerül egyformán...
    Mutasd a teljes hozzászólást!
  • Java bytecode specifikáció tudtommal csak egy van. Más kérdés hogy vannak verziói mint mindennek. A java-val szvsz nem is ez a fő baj, hanem hogy egyrészt a desktop alkalmazások (swing) rettentően lusta jószágok és elég ocsmányul is néznek ki, másrészt pedig maga a nyelv hagy maga után némi kivánnivalót (nincs operator overloading, property és még pár olyan nyelvi elem aminek azért mostanra már illenék egy új nyelvben lennie. A legnagyobb gond hogy ezek a dolgok már akkor voltak amikor a java megszületett, csak elvi (vagy nem tudom milyen) okokból nem került bele. De nem baj, jön a C# (pontosabban már itt is van) a java meg szvsz nagy léptekkel indul a múzeum felé. Más kérdés hogy egy rakás cég erre tette fel az informatikáját, ezek egy ideig biztosan jó piacai lesznek a java codereknek, kérdés az hogy mennyi kell belőlük...
    Mutasd a teljes hozzászólást!
  • A Java jövőjéről szólnék: Köztudottan, a Java úgy oldja meg a hordozhatóságot, hogy a fordító byte-kódot állít elő, melyet a megkívánt platformra készített JVM futtat (inkább csak értelmez és végrehajt. Ezért lassú mint a tetű)
    DE: Nem csak egy JVM specifikáció létezik. Úgy-hogy a hordozhatóságról ennyit. Akkor hát, hogy beszélhetünk jövőről?
    Mutasd a teljes hozzászólást!
  • Tény hogy Deplhi/SQL programozoként nem fogok 200000Ft nál többet keresni...mivel sokan vagyunk...


    Hát ez igazán elég meggyőző. Egy kezdőnek esetleg lehet hogy nem baj, de ha valaki hosszú távon akar Delphizni, akkor ez nem túl jó alternatíva, hogy elég nehéz efelé az összeg felé menni. Mert azt többen mondták alattam (meg lehet nézni nyugodtan ) hogy Java programozók drágák. De ha megvesznek, akkor ...

    Szóval programozni lehet mindenben, csak a lényeg az, hogy mit akar az ember, mert ha rosszul választ, akkor lehet sokat keres, de csak egy pár cég foglalkozik vele, eléggé be lehet vele szívni, ha az tönkremegy. Mert akkor lehet hogy tanulhatsz be valami újat, ha nagyon ráálltál, és nem foglalkoztál mással.(És ez nem csak a Delphire vonatkozik.)
    Mutasd a teljes hozzászólást!
  • Igaz, de ez már inkább nem megfelelő módszerválasztás mint a környezet hibája.

    Mutasd a teljes hozzászólást!
  • Olyankor számíthat, ha webről letöltődő, browserben futó ActiveX-et fejlesztesz, vagy pár száz példányban aktiválódó COM objektumokat. De ilyenkor meg nem kell belefordítani az egész VCL-t, és kisebb lesz.
    Mutasd a teljes hozzászólást!
  • Sokszor nem értem ezeket a "Delphi nagyobb kódot generál" kifogásokat.

    Itt van pl. az általam írt egyik program: 5 nagyobb és vagy 5-6 kisebb EXE van benne. Az egész úgy 15 MB-nyi.

    És kit érdekel, hogy ez mennyi???

    Az adatbázis mérete, amin dolgozik, ugyanis ennek ezerszerese...
    Mutasd a teljes hozzászólást!
  • Azt hiszem, ez most már hitvita, kis technológiai zsargonnal fűszerezve. Te úgy hiszed, hogy elhal a Java platform, én meg úgy, hogy nem - majd az idő eldönti, melyikünknek volt igaza (mert hitvitákban észérvekkel úgyse lehet meggyőzni a feleket).

    És egyrészt ez már végérvényesen nem ebbe a topicba tartozik, másrészt meg rengeteg munkám van, úgyhogy a hozzászólásodra érdemben nem reagálok. Két hét múlva több időm lesz, akkor talán visszatérhetünk rá.
    Mutasd a teljes hozzászólást!
  • Azért az nem ilyen egyszerű. Míg a windowsok esetén létezik többé-kevésbé a kompatiblitás visszafelé, linux esetén néha még forráskód szinten sem. Annak az esélye hogy egy RedHat 4.0 alá írt bináris RPM-et fel tudj tenni --force nélkül egy Fedora Core1-re, vagy hogy ez az rpm --force-os telepítés után működjön - nos nem kimondottan túl nagy. Pláne ha nem C-ben hanem C++-ban írták. De még forráskód szinten sem biztos hogy jó a helyzet, a linuxos libek erősen változnak, ráadásul amit a gcc 2.x még leforgatott azt a 3.x már nem biztos hogy le fogja. És a java-nak bizony van egy szép nagy C-s (vagy C++-os) forráskódja is, amit ha senki nem aktualizál a windows/linux aktuális változatához akkor a jávás programodat a hajadra kenheted... Windowson ráadásul kérdéses lehet az is, hogy az N+1 verziójú longhorn meddig támogatja az unmanaged programok (Pl. a java VM) futtatását. És hogy meddig lesz a dolog mögött win32 API. Plusz, mára már fellépett olyan igény is hogy a techológiákat követni kell. Azaz a 20 éve mainframe-re írt cobol probramok sokáig el tudnak futkározni egy zárt rendszerben, de programok többségének szüksége van a kommunikációra a külvilággal, azaz egyre újabb protokollok, API-k támogatására. Azaz ma már egy platform csak addig él amíg fejlődik. Azaz a dolog úgy néz ki, hogy a Java is addig él amíg a SUN, hacsak az utolsó erejükkel nem teszik open source-ossá (amit egyébként is erősen ajánlanak neki jobbról-balról, de szvsz a Netscape története fog megismétlődni - mire a Mozilla használhatóvá lett és konkurrenciája lehetett volna az IE-nek addigra már az IE akkora fölényre tett szert hogy a Mozilla részesedése mára elhanyagolható). És ami azt illeti szvsz hosszú távon a M$ egész biztos hogy működni fog /abból a pozícióból nehéz veszíteni/, míg a SUN esetén erről egyáltalán nem vagyok meggyőződve. És arról sem hogy megszűnés után a SUN meg fogja nyitni a javát. A harmadik dolog a fejlesztői bázis. A M$ szvsz elég jó eséllyel megtartja a VB, Visual C++ fejlesztőket és megszerzi a Delphi-sek nagy részét is. Plusz még néhány javást a J# segítségével. A linuxos C/C++ fejlesztők meg vagy marandak a C/C++ mellett, esetleg monozni kezdenek, egy részük eseteleg elkezd javázni de linux alatt a java soha nem volt igazán népszerű. A SUN sem igazán kedveli a linuxot mivel a Solaris konkurrenciája (a java is elég sokára jött ki, először a blackdown.org portolta, majd a Borland is besegített). Végül a negyedik a fejlesztés sebessége/iránya. A M$-nak van pénze beletenni szinte bármennyi pénzt a .NET-be, és megszerezni a legjobb fejlesztőket a C# és a .NET osztályok fejlesztésére. A SUN lehetőségei e téren kissé korlátozottak, ráadásul a java nyelv már a kitalálásakor sem volt igazán szerencsés dolog (elvi okokból kihagytak egy csomó jó dolgot, Pl. operator overloading, properties, stb). Ezek a C# mind benne vannak, azaz maga a nyelv már most is szerencsésebb. Ráadásul a SUN-ék a .NET-es konkurrencia megjelenéséig nem igazán foglalkoztak az architektúrával, Pl. az 1.5 előtti (azaz a stabil) JRE-k minden swing-es alkalmazás indításakor gyakorlatilag teljesen új JRE-t indítottak, azaz egy 'Helló világ' is elindított egy teljes JRE-t akkor is ha már futott egy másik is. Ez az architektúra desktop oldalon tökéletesen használhatatlan. Az 1.5-ben ezt állítólag megoldották, jobb későn mint soha...
    Mutasd a teljes hozzászólást!
  • A Delphi-ben a BDE volt a legrosszabb, csak a baj volt vele. Szerencsére már elég rég megjelent a dbExpress ami viszont már egy elég kellemes kis eszköz és nem kellett azt az undorító BDE-t telepítgetni. Ehhez ott van az Open Interbase, most pedig már a Firebird is, úgy hogy a BDE-nek tényleg vége. Viszont az hogy megjelent a .NET szvsz a Delphi-t meglehetősen kinyírta. A D8 alatt már szvsz jobb ötlet windows.forms és egyéb .NET alapú dolgokat használni mint a borlandos osztályokat, ez esetben viszont már felmerül hogy a C# mennyivel kellemesebb nyelv mint az Object Pascal és hogy a Visual Studio sem kimondottan rossz kis fejlesztőkörnyezet...
    Mutasd a teljes hozzászólást!
  • Szerintem az egyedi fejlesztésű progik legtöbbje adatbáziskezelő. Ezeket nem hiszem, hogy érdemes lenne C vagy C++ nyelven írni, ugyanis a sebességet általában az adatbázis sebessége határozza meg, mint leglassabb tényező. Hiába hasít a program, ha várni kell a lekérdezés eredményére.
    Ezen a vonalon elindulva viszont szinte mindegy melyik nyelvet választja az ember. A Delphinek eddig megvolt az az előnye, hogy volt BDE, mára szerintem ez is odavan az MSDE-vel. Gyakorlatilag mindegy, hogy D8-ban VB.NET-ben fejleszt az ember. A Megrendelőt csak az érdekli, hogy minnél rövidebb idő alatt, minnél olcsóbban meglegyen a progi. Az árat és a fejlesztési időt pedig csak magasabb szintű nyelvekkel lehet megspórolni (no meg tapasztalt fejlesztőkkel).
    Mutasd a teljes hozzászólást!
  • Delphi: igenis érdemes. Az egyik legjobb vizuális fejlesztőezköz, ne mondjátok má, hogy nem jó! 1ébként érdekes, hogy most azt mondják, hogy a Javaé a jövő, ezt mondták 1997-ben is.... szal éljen a delphi, jó a c is, de oly mindegy, mit használsz, ha profin tudsz mindkettőben, akkor bármit elérsz, nem? Jaj, most nagyobb EXE-t fordit a delphi, egyrészt le lehet faragni a kódból (mint azt leirták), másrészt.... most nézzetek meg egy átlag programot, hány CD-s, mennyi a gépigénye.... stb. Most szerintetek azért nem ad ki egy cég egy programot, mert delphiben van megirva, ott 500K, Cben meg 200? Ez hülyeség!
    Mutasd a teljes hozzászólást!
  • A Delphinek nincs olyan jó optimalizálója, mint pl. a C-nek.


    Ez nem összehasonlítás, mert a C egy nyelv, a Delphi pedig egy termék. Tessék konkrét fordítókat felsorolni, azután pedig konkrét példákon keresztül igazolni az állítást! Ráadásul itt inkább a C++ képes fordítók az érdekesek. Továbbá a Borland készít C++ fejlesztői környezetet is...

    (A Delphi) Hátránya a nagy kód.


    Nos, ha nem fordítod bele a default unitokat (uses), akkor csak a Delphi memória-kezelőt (és még néhány más függvényt, mint ahogy más nyelveknél is) fordítja a programod mellé a Delphi, a mérete pedig 8-16kbytera összemehet. Ez ugye nem sok?

    ha egy komponens nem tetszik, akkor át is írhatod, de akkor az már lehet annyi erőlködés, hogy akkor jobban megéri C-ben


    Átírhatod, hiszen objektum-orientált. Vagy megírhatod magad is, mint ahogy C++-ban tennéd.

    Szerintem tényleg csak az dönt, mihez értesz, és mire van szükség a munkahelyeden. Én speciel előbb kezdtem C/C++-ban, és csak sokkal később kerültem össze a Delphivel. Mindegyiknek megvan a maga előnye/hátránya. De mire kiismered őket, már mindegyikben tudsz programozni... :)

    Mutasd a teljes hozzászólást!
  • A "meg lehet írni", meg a "megírták" között éktelen nagy ám a különbség. Az meg nem minőségi tanúsítvány, hogy benne van-e az XP-ben...

    Az idézetet meg ha megnézed, az álmairól szól. Hogy milyen klassz lenne, ha a .NET-tel is működne. A Java-val meg már most is működik.
    Mutasd a teljes hozzászólást!
  • Nem, a kérdés az, hogy 10 év múlva csak Microsoft lesz-e. Mert Java-t lehet futtatni a tetszőleges más platformon (MS-en is).

    És igen, a .NET is nagyon jó ezekre a rendszerekre, meg a J2EE is. Viszont többé-kevésbé fej-fej mellett haladnak, azaz általános esetben egyik sem jobb, mint a másik, csak speciális feladatokra tudunk választani közülük.

    Valóban, a komoly fejlesztéseknél nagyon fontos látni, hogy 10 év múlva használható-e az adott program, és a MS ezen a téren nem igazán jó. Nem nagyon szereti az XP a DOS-os (10 éve fejlesztett) Clipperes miegymást. Az AS-400-asok meg a VAX-ok viszont meglepően kompatibilisek önmagukkal.

    Szóval nagyon kétesélyes a dolog...
    Mutasd a teljes hozzászólást!

  • Nem értelek, ha csak ezt vesszük, akkor máris 90% az előnye a Java-val szemben, CLR-t meg szerintem ugyanúgy meg lehet irni bármilyen platformra, mint a JVM-et, hiszen van, ahol nincs is grafikus felület. (as400)
    A Java GUI-t és a Windows GUI-t meg nem is érdemes összevetni.

    Még mindig az az érzésem, hogy a Java napjai meg vannak számlálva, a Netscape mellett fog landolni.
    A Java gépet nem alaptalanul hagyták ki az XP-ből.

    Any vendor can now make a CLR implementation for its environment. Imagine if IBM chose to implement CLR on the AS/400, I could be writing VB objects that run on both Windows boxes and the AS/400. Now that would be really cool. Never mind cross- platform, I want cross-language!

    Neki van igaza! Miért kellene megtanulni a Javat ahhoz, hogy AS400 alatt futtasson egy progit, ha ő a VB-t szereti?
    Mutasd a teljes hozzászólást!
  • Nos, amennyire én látom a .NET pont ezekre a rendszerekre nagyon jó. A visual studióval ráadásul a legalsó azaz az adatbázis tárolt eljárásainak szintjétől, az adatkapcsolati, üzleti logikai, user interface rétegeken át mindent meg tudsz csinálni. És szvsz úgy igazából egy-két dologtól eltekintve nincs platformhoz kötve (erre is jó példa egyébként a mono), egy-két osztálytól eltekintve (Pl. windows.forms) szvsz elég jól megvalósítható minden platformon ahol el tud ketyegni egy virtuális gép. Mindenesetre kíváncsi vagyok hova fog vezetni ez a dolog. A java szvsz pár évig még biztos hogy előtérben lesz, de szvsz kérdéses a jövője. Egy ilyen méretű fejlesztésnél szvsz már az is szempont lehet hogy lesz-e 10 év múlva SUN és java. Microsoft biztosan lesz... Persze az is igaz hogy a java is műxik .NET alatt is...
    Mutasd a teljes hozzászólást!
  • A példáim nem az "egy gomb aztán klikk" rendszerekről szóltak, azoknak örülünk, de a gyakorlati életben nem ilyen problémák lesznek. A nagyvállalati fejlesztésekkor meg arra gondolj, hogy a rendszer bejárata (publikus interfész) egy (több) XML Web Service, amögött piszok sok üzleti komponens dolgozik. Ezeket szokják perzisztálni, néha tranzakcionálisan kell működniük, stb. És lehet valami primitív webes monitorozó felülete, de valószínűbb, hogy valami vastag klienssel etetik távolról. Vagy más rendszerek automatiksuan töltik adatokkal, pl. SOAP-pal.

    Számok? Mondjuk pár tízezer üzleti folyamat párhuzamos kezelése, napi pár millió üzleti tranzakció, rendelkezésre állás: 7x24, stb. 2-3 szerverre van szétosztva, ezek között kommunikálni kell, de általában van még pár szerver tartaléknak.

    Na ilyeneket már érdemes lehet Java-ban fejleszteni, az UI-t meg akár csinálhatják Delphiben is.
    Mutasd a teljes hozzászólást!
  • Az 1.0-ás mono még június-július környékén ki fog jönni és 1.1 kompatiblis lesz (a ximian igérete szerint). XMLDataAdapter még tényleg nincs (pontosabban jó kis NotImplementedException-okat dobál) de az alap ADO.NET és ASP.NET megvan. Én legalábbis amikor egy pici Firebird .NET providert használó kis ASP.NET-es tesztprogimat átettem mono alá az csont nélkül működött, persze ez nem volt sokkal több mint egy click-re label szöveg változtatás és egy datagrid. Amúgy ha nem GUI-s fejlesztésekre használják, akkor mire? Mert a webes user interface per pillanat még ocsmányabb mint a swing (pedig az azért nem kis dolog). Ráadásul a JSP készítése, hát finoman szólva is kissé macerás művelet (mondjuk egy webforms-hoz képest).
    Mutasd a teljes hozzászólást!
  • Tudom, meg van Rotor is, nagyjából addigra lesz használhatóan kész az 1.0-s keretrendszer, mire a MS kiadja a 2.0-t. Érdemes céget alapítani rá.

    Ráadásul open fejlesztés, tehát ha nincs kedvük belerakni - neadjisten - az XmlDataAdapter osztályt, akkor nem teszik bele. Van pár ilyen uncsi része a frameworknek, ami kimarad belőlük.

    És végül érdemes megnézni, hogy azért a J2EE-t használják, kevés nagyvállalati rendszert írnak c-ben. Ja, a desktop gépre a ls-t nyilván nem javában fogják írni, de komoly rendszerekre azért egész sok helyen használják. Nem GUI-s fejlesztésekre, mert az tényleg ocsmány.

    Az Avalont ha jól gyanítom, 2006-ra ígérik, amiből simán lesz 2008 is, mire stabilan kijön. Tehát 2010 körül lesz stabil fejlesztési módszertana, addigra nagyjából kihalhat a mostani komponens-szervíz-orientált megközelítés, vagy menet közben kitalálnak még az Avalonnál is jobbat, és akkor arra esküszik majd mindenki. Úgyhogy még van ideje a Linuxnak / Sunnak kitalálni valamit.
    Mutasd a teljes hozzászólást!
  • Egyrészt van mono, másrészt a java olyan dolog ami úgy igazából egyik platformon sem az igazi. Nem véletlen hogy linuxon is inkább C++-ban vagy C-ben megy a fejlesztés vagy Kylix alatt, esetleg Python, PHP de java csak egész ritkán. Én legalábbis még az eddig használt disztribjeimben (Mandrake, SuSE, Debian, UHU, RedHat) nem nagyon találkoztam jávás progival. Külön lehet letölteni, Pl. Poseidon UML, de annyira lassú szegény hogy inkább umbrello-t használok annak minden bajával együtt... Nagyjából kétfajta java progi létezik: van amelyik szép (viszonylag) de rohadt lassú (ilyen a Poseidon) vagy van ami gyors de ocsmány (ilyen Pl. az ArgoUML). Van ami a kettő kombinációja, Pl. az Eclipse, az elég lassacska is (egy KDevelop-hoz képest legalábbis) de legalább ronda is. Érdekes módon a MonoDevelop viszont aránylag gyors (gyors gépen legalábbis, P900-on az sem egy élmény, és érdekes módon semmivel sem lassabb mint a szinte azonos kódbázison lévő SharpDevelop windows/.NET alatt) és nem is annyira ocsmány mint a szintén GTK alapú Eclipse. De a legnagyobb szívás szvsz az Avalon lesz a linuxnak, ha ez az alkalmazásmodell tényleg elterjed (és nem igazán látom miért ne tenné) akkor a desktop linux finoman szólva kissé nehéz helyzetbe fog kerülni, és igazán a szerver oldalnak sem jósolok nagy jövőt.
    Mutasd a teljes hozzászólást!
  • Erre van egy fogadásom :)
    A .net-nek éktelen nagy hátránya (előnye), hogy windows platformon megy. Ha másra akarsz programozni, akkor Java. És - bár talán nem köztudott - a Microsoft Windowson kívül is van még programozási platform amire fejlesztenek...
    Mutasd a teljes hozzászólást!
  • Egyetértek LC válaszával, nekem is az az érzésem, hogy a Java 5 éven belül nagymértékben visszaszorul és egyre jobban bejön a .NET. Ezt kb. a IE vs. Netscape csatájához hasonlitanám. Netscape még létezik, használják is, de már nem jelentős.
    Ha jól tudom a .NET-ben mindegy miben programozol, ha az adott nyelv fel van készitve rá, tehát nem Java-t kell tanulnod, hogy platformfüggetlen légy, hanem a kedvenc nyelvedet használhatod, akár teamben is.
    Szóval a M$ mindig későn indul, de annál nagyobbat üt a végén...


    Mutasd a teljes hozzászólást!

  • Hi!

    Szerintem mindenképp érdemes Delphi-ben elmélyedni. Főleg a CLX-es platformfüggetlenség miatt. Persze még a CLX nem forrt ki teljesen, de majd idővel. :)

    A Java és C/C++ is fontos ugyanúgy, de a Java erőfőrrásigénye nem tetszik. A Java nálam a "ha nagyon múszály" kategória. :)

    A PHP-t se felejtsük ki a webes fejlesztésekből! :)

    G.

    Mutasd a teljes hozzászólást!
  • Sziasztok!

    25 éves vagyok Kb. 2 éve fejlesztek delphiben/SQL (szerintem még mindig kezdő vagyok), és bátran kijelentem
    meglehet élni belőle (140000Ft ot keresek).Rengeteg programot fejlesztettek delphiben és nem véletlenül:
    gyorsan "kevés" anyagi ráforditással(liszensz + programozot megfizetni stb.) piacképes programot lehet fejleszteni.
    A JAVA fejlesztök még mindig nagyon drágák a magyar piac(a kis és középvállalkozokról gondolok)
    képtelen megfizetni őket.Persze kérdés kinek milyen ambiciói vannak...a lényeg a specializálodás mindegy c java delphi
    csak legyél nagyon jó abban amit csinálsz...

    Tény hogy Deplhi/SQL programozoként nem fogok 200000Ft nál többet keresni...mivel sokan vagyunk...
    Mutasd a teljes hozzászólást!
  • A C nyelvből szvsz ma már elég nehéz lenne megélni. Egy-két beágyazott rendszeren és esetleg driver fejlesztéseken kívül nemigen használnak ma már C-t sehol. C++-t igen, de az egy más tészta. És persze a C igen sok mindenhez jó alap, Pl. Java, C#, PHP és persze a C++-hoz sem árt de önmagában nem sok mindenre jó. A java pedig szvsz úgy 5 éven belül kb. a COBOL kategóriájába fog kerülni, azaz azok a cégek akik erre álltak rá még használják de az újabb projecteket már egyre inkább .NET-ben fogják csinálni. Ez egyébként szvsz a Delphire is igaz, sajnos.
    Mutasd a teljes hozzászólást!
  • De keresünk!
    Kezdő és gyakorlott Delphi fejlesztőket is!
    További infó: www.inforatio.hu

    Egyébként - mint munkaadó, és mint a piacból élő cég - a véleményem az, hogy a Delphi egy meglehetősen robusztus és e mellé rugalmas eszköz.
    (Minap látogatott minket a Java atyja (nem személyesen, hanem cég formájában), és azt ígérte, hogy a Java újracsomagolva már olyan
    rugalmas és robusztus lesz mint a VB vagy a Delphi
    . Ennyit erről...)

    Mindenesetre az alapelv: megfelelő eszközt a megfelelő feladatra!
    Mutasd a teljes hozzászólást!
  • Üdv!

    hátránya a nagy kód, ezt gondolom te is elismered !


    Nem ismerem el. Lehet delphiben kis kódot csinálni. Azt vedd figyelembe, hogy a Delphi alapbeállítással olyan kódot állít elő, mely bármely gépen elfut (BDE kivétel)

    De ha valaki ért hozzá, a 400KB-s alapot, le tudja redukálni 8KB-ra!
    Ha meg valaki nem ért hozzá, az lecseréli a Delphi VCL-jét KOL-ra...

    Ivn
    Mutasd a teljes hozzászólást!
  • Én azért azokat a shareware programokat amikről már telepítés előtt tudni lehet hogy vb-ben írták eleve fel sem teszem. De volt már olyan is hogy feltettem, nagyjából csinálta is amire ki lett találva de a vizuálbézik miatt dobtam a programot, nekem ne szennyezze a winchesteremet egy vizuálbézikben írt program. De persze a legtöbb user nem tudja mi az a vizuálbézik így nem ennyire válogatós. És az is igaz hogy a .NET kissé megváltoztatja a dolgokat, ott már elég nehéz megmondani hogy mit miben írtak...
    Mutasd a teljes hozzászólást!
  • Az én véleményem:
    1. : csatlakozom startmenu hozzászólásához.
    2. : Szerintem itt nem arról van szó, hogy mibe írsz programot (VB, Delphi, C, Java....), sokkal inkább a kész termék stabilitása a lényeg (C-ben is lehet fagyós programot írni, és VB-ben is atombiztosat). Ha nem közvetlenül rendszergazdának, vagy kimondottan céges programozonak megy az ember, hanem kisseb szoftver-megbízásiokat teljesít, senkit sem érdekel, hogy ez miben íródott.
    Sztem mindenki olyan nyelven programozzon amilyenben szeret, tud, vagy akar, vagy kell.
    Tisztelettel:
    Hron György, VisBasic elkötelezett
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd