Názory k článku Eclipse 2 - IDE na všechno

Eeeee, pehapko je na nic, Servlets/JSP ruleez:))

<FLAME>
... to samozrejme ano, ale pokud mi zalezi na rychlosti, stabilite, efektivite vyvoje a podobnych naprosto nedulezitych a podruznych vecech, jsem nucen pouzit PHP ale jinak s Vami, pane kolego, samozrejme naprosto souhlasim
</FLAME>
V0LE, o tom se tu nikdo nebavi

Zajímalo by mě, jak je to s náročností na hardware. Autor sice psal, že je to nenáročné, ale nevím, jaká má autor měřítka, javisti jsou totiž v tomto směru (aspoň vůči mně) dosti "posunutí". Běželo by to na mém Celeronu 266 MHz 96 MB RAM, kdybych měl zárověň puštěné X + KDE? Díky za případné odpovědi.

no když ono také zaleží na tom co si kdo představuje pod pojmem "běželo". Pro spoustu lidí např. NetBeans "neběhají" na 1.5GB procesorech a 500MB paměti a já je celkem spokojeně používám na CPU 500MB a RAM 256MB. Ano startuje to dlouho to je u javy negativní, ale potom už to běhá, tedy alespoň z mého pohledu. Myslím že jedinou šancí jak se dozvědět odpověď na vaši otázku bude zkusit to.

To by rozhodne nebezelo. Zdvojnasobte pamet a vykon CPU, nahradte KDE necim jednoduchym (wm, fvwm,...), zapomente na paralelne pusteny web browser ci jine bumbrlicky a jakz takz to pujde.

Oproti ostatnim javovym IDEm (a s prihlednutim k tomu, jaky HW se dnes bezne prodava) lze ale Eclipse rozhodne klasifikovat jako nenarocne

Nevim, jak autor prisel na oznaceni "gigant" pro firmy jako Borland (druha liga ve vyvojovych nastrojich) nebo Red Hat a SuSE (balici Linuxu). Zajimalo by me srovnani Eclipse s Forte/Netbeans.

Podle ročního používání obou mohu říct, že eclipse se mi zdá o hodně lepší a trochu přehlednější(velmi subjektivní :-)). Má velmi dobře udělaný plugin pro CVS a Tomcata. Navíc už teď pro něj existuje spousta pluginů a až bude mít plugin pro C/C++ a PHP tak už asi nebude co řešit.

Borland je druhá liga ? A kdo je ta první ?

Petre, podle jakeho kriteria soudite, kterou "ligu" ve vyvojovych ci jinych nastrojich hraje jaka firma ci kdo je "pouhy balic"? Vite vubec, o cem mluvite? Nebo je to tak, ze "prvni liga" je to, co pouzivate vy a "druha liga" to, co mistr nepouziva ... ?

Kupodivu vim, o cem mluvim.

Vzhledem k tomu, ze delsi dobu se zabyvam vyvojem SW pro Windows, mohu rict, ze prvni liga je zde MS se svym Visual Studiem. Zkousel jsem i C++ Builder od Borlandu a moje zkusenosti jsou takove, ze je to skutecne nastroj k rychlemu vyvoji aplikaci. Slepite k sobe par komponent (mimochodem napsanych v Pascalu) od vyrobce a jste mistr sveta. Pokud ale narazite na problemy, jste v koncich. Musite pouzit nastroj, kde mate veci vic "pod kontrolou". Proto to oznaceni - druha liga.

Firmy jako RedHat a SuSE si pouze masti kapsy na usili vyvojaru FreeSoftu. K Linuxu pridavaji jen instalator a par nastroju pro udrzbu. Slysel jsem, ze z casti penez sponzoruji nektere projekty, ale jinak jsou to opravdu jen balici.

Muahaha, hahaaaaa, hueeeee, haaaaa.

Tak vazne, vystrc hlavu z p... isku a rozhledni se,
kluku.

T.

Zkuste si sam vytvorit distribuci Linuxu. Pak vas mozna prejdou vase chytri reci o distribucich Linuxu. Ono to totiz cele neni tak jednoduche.

P. S. Mam takovy pocit, ze Red Hat ani SuSE si kapsy zatim moc nemasti :-).

Je pravda, že MS Visual C++ vyžaduje od programátora větší kus práce než Borlandský Builder a asi tam tím pádem má člověk kód víc pod kontrolou, já ale dělám
většinou provozní programy (někdy jen na jedno použití) a rychlost vývoje je pro mě dost důležitý faktor (možná vůbec nejdůležitější). Takže z mého pohledu je MS Visual C++ o patro níž, než Builder a té druhé lize se docela směju.

a jiz jsme zkouseli delat vlastni distribuci. Neuveris co to dalo prace. Ted jiz delame veci radeji jine. Linux pouzivame kolem 8smi let a ja sam paralelne i windowsy kvuli podpore zak. a penezum zni. /prece to jen tak nezahodim/ je celkem jasne ze Visual studio je na woknech lepsi nez Bordelandi Builder. Asi to bude tim ze na wokna je to vubec nejlepsi komplikator co znam a tim ze je od jejich autora a tudiz muze vyuzivat i funkce kt. jsou vyrobcum jinych sw utajeny. Memyslete ze MS zverejnil komplet cele API a vubec. Navic Borlandi kompl. pouz sve knihovny narozdil od MSVS kt. ma jiz kupu veci v systemu a jen to prilezitostne vola. Borland mozna nebyl nejlepsi kompl. ani na dosu. (pouz. sem v 3.1) ale mel nejlepsi podporu pro vyvojare a cenovou politiku. (nejlepsi byl asi watcom...10.6),,, No nic, mam ale pocit ze kdyby mel MS delat vyvojove prostredi pro linux, tedy mel stejne podminky jako Borland, nemyslim si ze by dopadl lepe(nejen u jeho produktu-:))
Jo a RH je gigant, QNX je profi spol. a mozna ze je v souc. dobe i mensi (to presne nevim) Jedno ale vim ze Linux (co mam tak rad) je oproti QNXu hodne slabej, ale wokna proti Linuxu mnohem slabsi. A koukej na tu propast mezi obema svety. (placena wokna a pl. QNX a jak sou na tom) Takze bud rad ze ti myska dobre klika, klikej si vesele dal a nech si svoje priblble uvahy a nesmyslne kecyyy.

Takze Visual C++ vklada do vysledneho kodu jine API funkce, nez jsou ve zdrojovem textu? Zajimave.

A srovnani QNX vs Linux vs Windows je taky zajimave. Hodnotite architekturu (mikrojadro QNXu je pekna vec),
flexibilitu (tady bude nejlepsi Linux) nebo neco jineho? Copak se daji takhle srovnavat jabka, hrusky a pomerance?

No neviem o com ty tu basnis, on mal celkom recht. Aj menovane spolocnosti(RH, MDk) maju daleko od stredne vacsich spolocnosti a este dalej od gigantov(nehovoriac o tom, ze su dlhodobo v cervenych cislach a MDK zobre aby neskrachoval a chrli distribucie jednu za druhov taktiez z toho isteho dovodu).

Neviem ake rozpravky si kde cital, ale zmen autora. Lebo to bluznenie, ze su MS kompilatory lepsie(a ze znatelne su) od Borlandu kvoli nejakemu nedokumentovanemu API je riadna haluz. Taktiez nema Borland problem pouzivat vsetky kniznice co pouziva MS Visual Studio, i ked on je vzhladom na jeho RAD nastroje zamerany viac na VCL, ale v praci s MFC ti ale nikto nebrani(ale potom nebudes mat ani resource manager k tomu). Ide o to, ze MFC je win32 stdandart a VCL je v pascale napisana kniznica ktoru musis retailovat alebo staticky zlinkovat. Taktiez ma Builder v helpe az priliz vela odkazov na pascal konvencie(a o source kodoch pomlcim). A navyse je MFC omnoho silnejsia a elegantnejsia kniznica ako "tahacie" VCL, ak zacnes nieco skutocne seriozne robit. Debuger v MS bol vzdy o krok lepsi ako v Borlande, o dalsich roky beznych nastrojoch ako Visual Modeler pomlcim(s tym prisiel Borland tusim teraz v Delphi 7). A kopu dalsich veci(ako 100% bezproblemova integracia s Intel C++ Compiler, co je daleko najvykonnejsi compiler pod win/linux na intel platformach)... Preto bol MS lepsi ako Borland a nie pre tajne API(linux rozpravky na dobru noc).

Ale C++ Builder je O.K., nie je nic lepsie na semestralne projekty a vychodis s tym celu vysku ako po masle =))

A taktiez som rad ze mi moja mys dobre klika, a ked ju teraz este vymenim za Logitech MX500 budem este radsej ;-P

1. Za vetu "To v Eclipse zcela odpadá, protože je vám předkládáno menu, které je z velké části napsáno v jazyku samotného systému, na kterém Eclipse běží" by jste si mel zopakovat prvni rocnik. Zajimalo by me co je to jazyk systemu ? Mate na mysli assembler ?
2. Pokud jde o podporu C/C++, pak je jiz vice nez pul roku dispozici oficialne podporovany plugin (Win, Linux, QNX, Solarix) dostupny primo na strankach projektu http://www.eclipse.org/tools/

Mozna byste mel znovu navstivit zakladni skolu. Spravne se pise BYSTE a ne BY JSTE. Zacnete nejdriv u sebe a nenapadejte ostatni.

Jo kuci, poradne se porvete, to mam rad.

Vazeny pane Davide, nechapu jakou slouvislost ma upozornovani na nedostatky jazyka ceskeho, nemyslite ze clanek je o necem jinem. Chapu pokud vam dojdou argumenty tak je potreba najit si neco jineho do ceho vidite vic. A z toho plyne nejste schopny vecne argumentovat k tematu a tak pouze napadate. Lidi jako vy se me osobne hnusy. Zdarec

Jezismarja, nechtel jsem tady vyvolavat nejakou flame-war. V pripevku jsem upozornil na odborne nedostatky clanku, kde autor popletl pojmy (1 poznamka) a uvedl nepresne informace (2 poznamka). Tim, ze jsem pouzil trochu nadsazky, jsem rozhodne nechtel nikoho urazet.

Vážený pane,

"nativní" se v hantýrce Java programátorů označuje kód (resp. metody), který je napsán v jazyce C (resp. v jiném jazyce, kompilovaném do přirozeného (**nativního**) strojového kódu dané platformy a je napojen do Javovské třídy (resp. knihovny). "Nativní" proto, že se tyto metody označují klíčovým slovem "native".

Rád bych Vám poděkoval za nasměřování na C/C++ plugin, o kterém jsem vskutku nevěděl. Byl jsem zahnloubán do průzkumu samotného IDE.

Nejak nechapu schizofreni pristup nekterych Java projektu. Pokud pouzivam Javu tak pro prave jeji vlastnosti s tim, ze jsem schopen akceptovat pripadnou dan za tyto vlastnosti (tedy rychlost). Nechapu to kombinovani nativniho kodu a Javy. Pokud mi nevadi pouziti kodu dane platformy a zaroven mi vadi rychlost Javy tak proc to cele neni treba v GTK/QT apod?

IMHO hodne lidi pouziva Javu nejen z duvodu prenositelnosti. Ostatne hodne Java aplikaci ma cilove platformy takove, ze prenositelnosti by bylo dosazeno i pouzitim standardne kompilovaneho kodu.

Java je super pokud jeji pouziti neni jen vysledkem snahy tvurcu aplikace prenest svou neschopnost na
stranu uzivatele respektuve jeho HW.

Veci nejsou jen cerne a nebo bile - slysel jste nekdy take o kompromisu?

Co kdyz mate projekt kde je cilem maximalni prenositelnost a slusny vykon ale reseni ktere je vybrane je skvele prenositelne ale ma problemy s vykonem. Tak potom zrejmne udelate kompromis - nebo ne?

Kazde reseni je tak prenositelne jak prenositelna je jeho nejhure portovatelna cast. Pokud muzu psat cast neceho (treba menu) v GTK tak proc to v tom nenapsat cele?

Nemam nic proti kompromisum, ale pokud udelam kompromis, kterym popru nebo "jemne" nabouram zakladni vlastnost tak to pak je na nic. Existuje napriklad Java binding nad GTK (http://java-gnome.sourceforge.net/) Aplikace ktera to pouziva potrebuje GTK/GNOME jinak nebezi. Mozna mi neco uniklo, ale nechapu to...

To je asi jako instalator Oracle v Jave, Hmm..co ze to ten instalator instaluje? Oops.. kompilovane cecko ktere na cilove platforme bezi..

No, nevim jak konkretne funguje toto nativni GUI (v Eclipse). Ale obecne z pohledu programatora neni prece problem udelat to tak, ze pokud na dane platforme je nativni rychlejsi podpora pak ji pouzit a pokud neni tak pouzit prenositelnou pomalou, ktera pobezi vsude tam kde neni nativni. Avsak nevim jestli je to takto konkretne v Eclipse udelano. Toto nativni zrychleni dost vitam (sice nevim o kolik je rychlejsi, zatim jsem se nedostal k tomu Eclipse vyzkouset), protoze prave rychlost GUI v Jave je dost otresna...

Neco vam opravdu uniklo :) Okamzite me napada alespon jeden duvod, proc se hodi mit to napsane v Jave, i kdyz GUI je napsano v nativnim kodu: pluginy. Eclipse je postavene na spouste pluginu a diky Jave je trivialni pridatavat pluginy a hlavne, *plugin je v Jave a tudiz prenositelny*, neni treba distribuovat pluginy pro vice platforem.

Duvod pro pouzivani nativnich metod je ten, ze v dobe vyvoje aplikace je virtualni stroj na nektere veci prilis pomaly. Ovsem virtualni stroje Javy se s kazdou verzi o neco zrychluji, takze jednou dosahnou uspokojive rychlosti v te oblasti pro kterou jsem pouzil nativni metodu. No a potom staci nahradit nativni metodu metodou javovskou.
Cili nativni metody jsou jenom docasnym kompromisem mezi rychlosti a prenositelnosti.

Podle toho co jsem se z toho sajtu docet, nejdrive za rok to bude vypadat jak KDevelop vypada uz ted. Mozna spise meli pridat Java plugin do KDevelop. Ovsem to by potom v IBM pouzili kolo ktere vymyslel nekdo jiny.

Ale KDevelop nebezi na widlich...

Kdyz uz jste tu nakousli Kdevelop:
Podel informace na www.kdevelop.org:
"28. August 2002 - Development for KDevelop-2 fully stopped. Now activities in cvs HEAD, only. Next version will be 3.0, a totally rewritten KDevelop."
Coz pro mne jako laika, veci neznaleho znamena, ze se do verse 2.x naucili, jak by to melo byt (Kdevelop) a ted zacnou znovu a poradne (Kdevelop 3.x)
Ated jako zacatecnik premyslim, jestli a)investovat cas do Kdevelop2.x (neperspektivni) b) Eclipse (ale jak to je s C a GCC podporou ? c) pockat par mesicu na Kdevelop 3.x
A ted babo rad.

trochu me nastvala vase uvodni poznamka, laik snad nepremysli hlavou? to je prece normalni vyvoj (nejen software) ...

Videl bych to nasledovne: Pokud vam KDevelop 2 vyhovuje, neni duvod ho nepouzivat. Az bude v pouzitelnem stavu KDevelop 3, urcite nebude problem na nej prejit. Myslim, ze k ovladnuti zakladu prace s KDevelopem nebude potreba nejaka ohromna casova investice - je to na par hodin hrani. Eclipse s C/C++ pluginem jsem nezkousel, ale existuji i jine alternativy. Je mozne vyvijet i v jinych nastrojich, jako je napr. Anjuta, nekomu muze stacit Kate, vim, Emacs apod.

mozno ti to pomoze:

KDevelop je priemerne IDE pre C++(v ramci kvality IDEs na lubovolnych platformach), s RADom to nema spolocnu ani len skratku(qt designer je tak na 2 veci a semestralne projekty), pravdou sice je ze jeho instalacia/konfiguracia(az na help system) je otazkou pol hodinky, a takmer sa s tym nemusis ucit pracovat ale tuna bodka.

Ulahcuje/automatizuje kopu veci(od gmake po autoconf) ktorych vycet je velmi dlhy, ale ktore su na inych platformach roky samozrejmostou. KDevelop(pracoval som s nim iba do verzie 2.1.2), ak prichadzas z komercneho sveta, pracuje mierne horsie ako MS Visual C++ 5.0('96 ?) bez vsetkych tych(MS) bonusov(sourcesafe/modeler/tracer atp.). Co je nic moc...

Je dobre ze tento projekt existuje, vhodny pre newbies na quick qt/gtk development bez hlbsieho studia, rychle 'hello world' bez znalosti jedneho prepinaca gcc atp., ale byt tebou na to kaslem a pozriem sa po kstudiu gold(od thekompany), co tiez nie je nic moc ale imho lepsie asi o 20%(aspon tam vela veci funguje na 100% a nie na 75.3421%). Komercne ale lacne(velmi) a taktie no vies no no ;-)

KDevelop 3.0 je vo vyvoji uz dlhsie, vyvoj bezal paralelne, ti lepsi robili na HEAD a zvysni ladili 2.x.

Ale tak ci tak, z toho co som si precital o Eclipse a a z toho co som videl(kedze v tom kamos facha ako vychor pod oknami v jave a tvrdi ze best best ;-)), KDevelop posobi oproti Eclipse ako hracka...

mozno ti to pomoze:

KDevelop je priemerne IDE pre C++(v ramci kvality IDEs na lubovolnych platformach), s RADom to nema spolocnu ani len skratku(qt designer je tak na 2 veci a semestralne projekty), pravdou sice je ze jeho instalacia/konfiguracia(az na help system) je otazkou pol hodinky, a takmer sa s tym nemusis ucit pracovat ale tuna bodka.

Ulahcuje/automatizuje kopu veci(od gmake po autoconf) ktorych vycet je velmi dlhy, ale ktore su na inych platformach roky samozrejmostou. KDevelop(pracoval som s nim iba do verzie 2.1.2), ak prichadzas z komercneho sveta, pracuje mierne horsie ako MS Visual C++ 5.0('96 ?) bez vsetkych tych(MS) bonusov(sourcesafe/modeler/tracer atp.). Co je nic moc...

Je dobre ze tento projekt existuje, vhodny pre newbies na quick qt/gtk development bez hlbsieho studia, rychle 'hello world' bez znalosti jedneho prepinaca gcc atp., ale byt tebou na to kaslem a pozriem sa po kstudiu gold(od thekompany), co tiez nie je nic moc ale imho lepsie asi o 20%(aspon tam vela veci funguje na 100% a nie na 75.3421%). Komercne ale lacne(velmi) a taktie no vies no no ;-)

KDevelop 3.0 je vo vyvoji uz dlhsie, vyvoj bezal paralelne, ti lepsi robili na HEAD a zvysni ladili 2.x.

Ale tak ci tak, z toho co som si precital o Eclipse a a z toho co som videl(kedze v tom kamos facha ako vychor pod oknami v jave a tvrdi ze best best ;-)), KDevelop posobi oproti Eclipse ako hracka...

Autori (investor) projektu urcite vedeli, proc se do toho pousteli. U vyvojoveho prostredi pro Javu (ale treba i Python apod.) je podle me multiplatformnost jeden ze zakladnich pozadavku. KDevelop je primarne urcen k vyvoji programu pro KDE.

eclipse nevychadza z visual age ale z websphere application developera ... inac odporucam odskusak kazdemu, urcite jedno z najprepracovanejsich IDE

Pokud jsou me informace správné, tak výše uvedený produkt zase vychází z VisualAge. To máte ale stejnak jedno ;-)

"Programy v Javě mají totiž díky architektuře jazyka Java (musí být snadno přenositelný) pomalejší odezvy, a tak na pomalejších počítačích trvá déle, než se například rozvine menu apod. To v Eclipse zcela odpadá, protože je vám předkládáno menu, které je z velké části napsáno v jazyku samotného systému, na kterém Eclipse běží."

Nemyslite si ze dnesni JVM ciste interpretuji bytecode, ze ne ...


"Nabízí všechno, na co si jenom vzpomenete a o čem si programátoři neinterpretovaných jazyků mohou nechat jen zdát."

O cem si programatori "neinterpretovaných jazyků" mohou nechat zdat ? Btw "interpretovanost" neni vlastnost samotneho jazyka, cehoz je Java nejlepsim dukazem.

Jazyk samotneho systemu je asi assemler, ono to bylo mozna mysleno tak ze to menu je prelozeno do nativniho kodu dane platformy. Dyt na Linux i wokna sou javovske "komplikatory" (nevim zda mel na 100% v hlave zrovna jazyk java...), ktere kdyz se pouziji pro preklad do nativniho kodu, potom program v jave bezi 10x - 100x rychleji (ikdyz uz v ni psany jen primarne a pak je to skutku assembler ne???) Mam pocit ze kvuli tomu sun s ms vedli soud. Ze to postrada smysl tohoto jazyka a duvod (prenositelnost) kvuli kt. byl developen. Vsichni vite jak to myslel, aspon doufam. Je ve 2hem rocniku a docela se snazi. Tohle neni prvni clanek a je celkem dobrej, tak proc do nej sijete. Jo fajn, vam se nestava ze neco reknete jinak nez to myslite, ale ti skym mluvite vedi o cem mluvite (vetsinou, jinak to nema smysl) a tak to pochopi tak jak maji ikdyz to nebylo receno zrovna dobre. To je to same jako ti pitomci co tady votravujou s pravopisnejma chybama (ti jsou jeste horsi)
Chapu ze je to vecna pripominka, ale proc to musi psat nekolik lidi dokola to nechapu.
Tenhle produkt neni delany pro beh ve webbrowseru. Tak dyz ho cpu na wokna inst. se kod komplikovany pro wokna, kdyz na linux tak na linux atd. Ono by se to dalo i v Cecku, ale prece jen java je ponekud lepsi pro preklad do nativniho kodu ruznych platforem. Kuprikladu nove Delphi pro wokna sou taky v jave. (z vetsi casti) a proc? KYLIX se potom dela snaze kdyz je pul hotovo.
nebo ne?

me to neda, jak si prisel na to, ze novy delphi pro wokna jsou taky v jave ?

Vážený pane,
o interpretaci jsem vzhledem k odezvě GUI nepsal ani slovo. GUI v Javě je zkrátka na pomalejších počítačích líné. To se příliš netýká interpretace, ale spíše toho, kolik Java konzumuje paměti. Pokud jsou tlačítka či menu vytvořena pomocí systémové funkce, pak jsou odezvy okamžité. Pokud to stále ještě nechápete, pak navštivte http://dev.eclipse.org/viewcvs/index.cgi/platform-swt-home.

Dle mého názoru je intepretovanost vlastnost jazyka. Intepretované jazyky (a jejich debuggery) nabízejí RTI, možnost vyhodnocovat výrazy za běhu atd. atp.

O JIT kompilátorech Javy samozřejmě vím, programuji v Javě již řadu let. Ten druhý ročník je trochu zavádějící -- je mi 23 let a pracuji jako programátor (Perl/C++/Java/Apache/Linux).

ps - ještě informace pro člověka, který shání PHP plugin: na portálu http://www.eclipse-workbench.com v sekci resources jsou odkazy snad na všechny pluginy do Eclipse. Zahlédl jsem tam i PHP.

Vazeny pane ;-)

> o interpretaci jsem vzhledem k odezvě GUI
> nepsal ani slovo. GUI v Javě je zkrátka
> na pomalejších počítačích líné. To se
> příliš netýká interpretace, ale spíše
> toho, kolik Java konzumuje paměti.

Vazeny pane, napsal jste:

"Eclipse je univerzální vývojové prostředí. Je napsané v jazyku Java, ovšem díky tomu, že byly pro tento produkt vyvinuty knihovny SWT/JFace, které jsou napsané zčásti v nativním kódu dané platformy, je program velmi svižný a odpadla tak nejvíce diskutovaná část u programů psaných v Javě - rychlost odezvy na uživatelské rozhraní. Programy v Javě mají totiž díky architektuře jazyka Java (musí být snadno přenositelný) pomalejší odezvy, a tak na pomalejších počítačích trvá déle, než se například rozvine menu apod. To v Eclipse zcela odpadá, protože je vám předkládáno menu, které je z velké části napsáno v jazyku samotného systému, na kterém Eclipse běží."

Slovo "interpretace" se tu sice primo nevyskytuje, ale pokud nekdo mluvi o tom ze nejaky "nativni kod" nebo "jazyk systemu" bezi rychleji nez Java nebo mluvi o "pomalejsich pocitacich", jak jinak si to mam vylozit ze samotna Java nativni kod neni a tudiz se interpretuje ? Nic o konzumaci pameti tam nebylo.


> Pokud to stále ještě nechápete, pak navštivte
> http://dev.eclipse.org/viewcvs/index.cgi/platform-swt-home

Vazeny pane, pokud z Vaseho textu vzniklo nejake nedorozumeni, je to spis Vase chyba.

Co dela SWT vim.


> Dle mého názoru je intepretovanost vlastnost jazyka.
> Intepretované jazyky (a jejich debuggery) nabízejí
> RTI, možnost vyhodnocovat výrazy za běhu atd. atp.

Vazeny pane, podle me si pletete dohromady pojem jazyk s pojmem runtime ci debugger. Jazyk pouze vyjadruje co ma pocitac delat.
Interpretovat je mozne _jakykoliv_ jazyk, i treba strojak.

priklad: http://www.softintegration.com/ (==interpret C/C++)

Stejne tak je mozne jakykoliv jazyk prelozit do strojaku.

Pokud pojmem "RTI" myslite run-time type info, potom
je C++ (poskytujicic RTTI) interpretovany jazyk ?

Vyhodnocovat urcite omezene vyrazy za behu umi kazdy C debugger,
pricemz neschopnost vyhodnotit jakykoliv C vyraz
je dana pouze tim ze si s tim autori nedali praci.


> je mi 23 let

A me uz brzo bude 24, hec ;-)

haha, takze ty napises kompilator na eval v perlu... takze funkce, ktera bude generovat nejakou funkci ci uzaver bude zkompilovana... no tak to si teda borec

:-)))))))0

pro zacatek zkus tohle (to jsem zvedav ;) :

while (<>) {eval $_;};

intepretovanost jazyka je jeho vlastnosti, o tom neni sporu, ale co se tyka Javy, ta se skutecne nyni neintepretuje. 'intepret' javy preklada do strojoveho kodu a diky tomu, ze je java nizkourovnovy jazyk (napr. nema zadny eval), tak neumoznuje takova kouzla jako perl nebo scheme

perl sice ma JIT kompilator, ovsem NECO INTERPRETUJE a neco PREKLADA, eval je jeho soucast a nabizi super veci

ondrej tady predhodil, zda si autor neco nemysli a na tom vzikl tehnle flamewar, pritom ta jeho poznamka byla uplne zcesty, autor skutecne psal o uzivatelskem rozhrani a o zadne intepretaci

standartizovane RTTI v C++ je uplne na h***o, neprenositelne a nenabizi ani 20% toho, co RTTI v jave. v jave muzes extrahovat metody, provadet bezpecne pretypovani apod. v C++ tohle vsechno neni - muzes si ovsem neco z toho udelat sam

trosku jste se spatne pochopili :-))))))) jeden mele o koze a druhy o voze, heheh, kazdopadne Eclipse je super, Java taky, Perl je nejlepsi...

Ahoj, jsem rad ze mi taky chladne nerikas "Vazeny pane" :-)
a rad to s tebou prodiskutuju.


> takze ty napises kompilator na eval v perlu...
> takze funkce, ktera bude generovat nejakou
> funkci ci uzaver bude zkompilovana...

Nerozumim co jsi chtel rict, proste soucasti VM (JIT) Perlu
by byl i prekladac Perl -> bytecode, pricemz VM by ten bytecode
prelozila do strojaku, stejne jako jine metody.

Nevim jak v Jave, ale v .NET muzes vytvaret bytekod (MSIL) za chodu
programu a tento kod se nasledne kompiluje do strojaku.


> pro zacatek zkus tohle (to jsem zvedav ;) :
> while (<>) {eval $_;};

Zkusil bych to rad, jenze Perl skoro vubec neznam, zkus mi
cesky vysvetlit co to dela a odpovim ti.


> diky tomu, ze je java nizkourovnovy jazyk
> (napr. nema zadny eval), tak neumoznuje takova kouzla
> jako perl nebo scheme

Java nema eval zabudovany, ale teoreticky muzes mit kompilator
Java -> bytecode ve forme classy, pristupny tvemu programu.
Tomu predas text Javy, on ho prevede
na bytecode a ulozi na disk jako class.

(Mozna to neni potreba a muzes tu classu vytvorit nak jenom v pameti,
nevim jestli to Java umoznuje, ale na tom nezalezi.)

No a pak proste tu vytvorenou class normalne nahrajes do pameti,
JITne se to a bezi ve strojaku.

Muzes namitnout ze je to prilis tezkopadne a proces generovani pomaly, ale:
1) Pouha neefektivnost neznamena principialni nemoznost.
2) Pokud je rychlost provadeni toho evalu dulezita, muze se to sakra vyplatit.
Nejlepsi je prelozit jen evaly vyznamne z hlediska rychlosti.
3) Muzes si vymyslet hypotetickou VM kde se s touto funkci pocita
a je resena mnohem efektivneji.

(off-topic: Java ze je nizkourovnovy jazyk ?)


> perl sice ma JIT kompilator, ovsem NECO INTERPRETUJE
> a neco PREKLADA, eval je jeho soucast a nabizi super veci

Z cehoz ale nejde usoudit ze neni mozne vytvorit jinou implementaci
VM Perlu prekladajich uplne vsechno, at uz je to efektivni nebo ne.


> autor skutecne psal o uzivatelskem rozhrani
> a o zadne intepretaci

Jak jsem rek, slovo "interpretace" se v textu primo nevyskytovalo,
ale ja text pochopil tak, ze UI je pomale kvuli interpretaci bytecodu.
(Kdyz jsem videl pojmy jako "jazyk systemu").
A nebyl jsem sam.


> standartizovane RTTI v C++ je uplne na h***o,
> neprenositelne a nenabizi ani 20% toho, co RTTI v jave.
> v jave muzes extrahovat metody, provadet bezpecne pretypovani
> apod. v C++ tohle vsechno neni - muzes si ovsem neco z toho
> udelat sam

Mozna, ale to ma byt argument pro tvrzeni ze se jazyky deli
na interpretovane a prekladane, nebo to rikas jen tak mimo hlavni
diskusi ?

Jinak schopnost extrahovat metody (jestli chapu co tim myslis) neni
zalezitosti RTTI, jako spis reflexivity. Navic v C++ prece
bezpecne pretypovavat z predka na potomka muzes, ne ? Ale to nesouvisi
s tematem.



Podle me pojmy jako "intepretovany jazyk" vznikly jako zjednodusene
oznaceni jazyku, ke kterym existuji jen interprety a ne kompilery
nebo runtimy schopne kompilovat za chodu.

ono v c++ je toho dost(niekedy skus :)), bezpecne pretypovanie je samozrejmostou, RTTI v c++ je taktiez uplne v pohode(updatni kompilator alebo zmen programovacie techniky ak ti nestaci).

jj, Eclipse vyzera super, ale najlepsie je C++ :-P