Beszélgetés Budapesten David Intersimone-nal

forrás Prim Online, 2003. október 3. 14:19

A Borland 20 éves fennállásának évében rendezett, október 1-2-i eseményen nyílt lehetőség beszélgetni a jubileumi eseményre Budapestre látogató és a Borlandnál 18 éve dolgozó, mára a Borland-eszközök kialakulása terén szinte fogalomnak számító David Intersimone-nal.
A CeBIT-et követő időszakban némi bizonytalanság volt tapasztalható a Delphi, a Borland egyik legsikeresebb és a pascalos hagyományokat folytató fejlesztőeszközét illetően. Annyira, hogy a Borland szükségesnek tartotta egy nyílt levélben megnyugtatni a fejlesztőket, hogy ennek az eszköznek a fejlesztése is folyamatos. Ugyanakkor ennek alkalmazkodnia kellett a Windows újdonságaihoz éppen úgy, mint a Borland megváltozott fejlesztési stratégiájához, a teljes életciklus-kezeléshez. Így a kérdéseket ezzel a termékkel kezdeném, különösen, mivel az itt és Frankfurtban is bemutatkozott, valamint a tervek szerint a BorCon-nak is egyik főszereplője lesz. De egyik főszereplője volt a Borland Magyarország által 2003. október 1-2-án szervezett budapesti fejlesztői napoknak is. A Borland 20 éves fennállásának évében rendezett eseményen nyílt lehetőség erről is beszélgetni a jubileumi eseményre Budapestre látogató és Borlandnál 18 éve dolgozó, mára a Borland-eszközök kialakulása terén szinte fogalomnak számító David Intersimone-nal.

Adódik a kérdés, hogy a Delphi mennyire illeszkedik ez utóbbihoz és mennyire lesz a jövőben a fejlesztés központjában?

David I. A Delphi jelentős fejlesztőeszköze volt a Borlandnak, és marad a jövőben is. Ugyanakkor a Borland, mint továbbra is független fejlesztőeszközgyártó, igyekszik a fejlesztők minél szélesebb rétegeinek csúcsminőségű fejlesztőeszközt kínálni. Így, ellentétben az operációs rendszert is gyártó műhelyekkel, alkalmazkodnia kell az operációs rendszerek változásaihoz, miközben élhet a keresztplatformos fejlesztések nyújtotta előnyökkel is.

A Microsoft új koncepciójával kapcsolatban sokat hallani a fejlesztőeszközök .NET-támogatásáról. Ez mennyiben fog hasonlítani a C#Builder-hez?

David I. A két fejlesztőeszköz két különböző programnyelvet támogat. Így értelemszerűen lesznek a nyelvekhez kötődő különbségek. De sok tekintetben, elsősorban a Microsoft Framework-re visszavezethetően hasonlóságok is lesznek. Ám a kódok átírása természetesen igényel majd némi munkát.

A Delphi 8 .NET-támogatása, az FCL mellett mit várhatnak a korábbi, VCL-rendszerben dolgozó fejlesztők? Fogja-e támogatni a VCL, illetve CLX alapú támogatást?

David I. A jelenleg tesztfázisban, Octane néven ismert új Delphiben teljes támogatást adunk a VCL-rendszerben dolgozó programozóknak. Így azoknak a fejlesztőknek sem kell lemondaniuk tapasztalatuk és kódjaik további használatáról, akik eddig jelentős munkát fektettek ezekbe. Az új rendszer nem is annyira az ő átcsábításukra van kiélezve, hanem más .NET-es fejlesztők, illetve a Windows-környezetben más programnyelveken dolgozók meghódítására. De annak sincs akadálya, hogy a VCL-rendszerről térjen át valaki. A források kompatibilisen tartását beépített segédosztály is segíti. A CLX helyzete másként alakul, ez tulajdonképpen egyfajta keresztplatformos fejlesztési lehetőség megteremtését szolgálta. Átjárást a Delphi 7 és a Kylix között. Ennek megfelelően a jelenlegi tervek szerint az Octane nem fogja támogatni a CLX-rendszert.

A platformfüggetlen fejlesztések támogatása kapcsán a Borland most jelentett be egy új fejlesztőeszközt. Elsősorban a C/C++ nyelveken dolgozóknak.

David I. Igen. Ez a C++BuilderX, mely jelenleg lehetővé teszi, hogy egyenértékű fejlesztőkörnyezet álljon rendelkezésére a Windows, Linux vagy Solaris környezetben dolgozó fejlesztőknek. Ennek megfelelően számos C-nyelvű fordítóprogrammal képes együttműködni. Függetlenül attól, hogy azt a Microsoft, a Sun vagy a GNU-közösség készítette-e. Alapja a JBuilder-ben is megismert fejlesztőkörnyezet, és éppen úgy Java-s környezet a C++BuilderX biztosította környezet is.

Ez esetben adódik a kérdés, hogy fog-e más operációs platformokat is támogatni?

David I. Természetesen semmi akadálya nincs annak, hogy a Javát futtatni képes környezetekben használható legyen a rendszer. Amennyiben az adott környezethez C-nyelvű fordítórendszer és integrálható könyvtárak rendelkezésre állnak. A különböző UNIX-változatokon éppen úgy, mint Macintoshon.

A C++BuilderX jelenleg a mobileszközök közül beépítve csak a Symbiant támogatja. A mobiltelefonok közül sok kétségtelenül ezt a rendszert használja, de bővülni fog-e a paletta?

David I. A Symbian valóban az egyik legelterjedtebb mobiltelefonos operációs rendszer, mely több más hordozható eszközben is használható. De azt is látjuk, hogy szintén széles körű azoknak az eszközöknek a sora, melyek PalmOS-sel futnak. Így már korábban megkezdődtek a tárgyalások az ennek beépítési lehetőségeit illetően. A tárgyalásokat tett és az utóbbi hetekben szerződés követte, tehát a következőkben a PalmOS támogatása előtt sincs akadály.

Szintén ezzel a fejlesztőeszközzel kapcsolatos kérdés, hogy hasonló eszközök megjelennek-e más programnyelvek támogatására? Akár a Wine kiváltására a Kylix esetében.

David I. Erről még nem tudok konkrétan nyilatkozni, de a jövőben bármi előfordulhat :)

Szintén felmerülhet az a kérdés, hogy mi lesz a JBuilder sorsa?

David I. Ennek a minden tekintetben javás fejlesztőeszköznek a fejlesztése is folyamatos. Minden olyan programozónak, aki különböző szintű Java-alapú alkalmazást kíván fejleszteni. Az ő számuk meg folyamatosan növekszik. És maga a Java is fejlődik.

A különböző fejlesztői munkák támogatása kapcsán mostanában sokat hallani a felvásárlások révén a Borlandhoz került alkalmazásokról. Jelenleg milyen mértékű ezek integrálódása a termékekhez?

David I. Ha ezek előéletét megnézzük, nem egy esetben már a felvásárlás előtt, sokszor évekkel előtte is jelentős mértékű volt a fejlesztők együttműködése. Az új ALM kiteljesítéséhez pedig értelemszerűen szorosabbá válik ez az integráció. A programozók számára ugyanakkor egy független gyártó készítheti el azt a teljes csomagot, mellyel a használat logikájának megfelelően tervezhető meg és készíthető el az adott alkalmazás. Folyamatosan figyelemmel kísérve és felügyelve az egyes projektek teljes megvalósulását, a forrásrészletek dokumentált tárolását, és szolgálva egyben a kód optimalizálását is. Az utóbbi esetben pedig nem csak azt mondjuk meg, hogy itt vagy ott gond van a kód hatékonyságával, hanem azt is, hogy mi a probléma oka.

Köszönöm a beszélgetést.

Simay Endre István