Dotaz: vývojové prostředí

[Dominik]

Ahoj, měl bych dotaz ohledně toho jak funguje jakékoliv vývojové prostředí na C/C++. Zkoušel jsem pár věcí v pythonu a tam jsme byl zvyklý na ">>>" tedy, že cokoliv jsem napsal, tak mi okamžitě po stistnutí Enter ukázalo, zdali jsem zadal příkaz správně a vyhodilo to nějaký výsledek a nebo špatně a chybu. Jednuduše nevím jak si v C zkontrolovat to co napíši. Zatím pracuji v Dev-C++ a budu vděčný za každou radu. Předem děkuji za odpověd.

Odpovědi

[MadCatX]

C je kompilovaný jazyk, tudíž pro kontrolu, že je program zapsán správně je potřeba ho přeložit. Python je jazyk interpretovaný, takže programy v něm napsané je možné okamžitě zpracovávat řádek po řádku.

[pavlix]

Python je jazyk interpretovaný

Kompilovaný do bajtkódu. To jen pro detailisty :).

[l4m4]

Raději transformován než kompilován. Používáním slova kompilace se akorát vyrábějí zmatky, protože transformace do bytekódu nemění na rozdílech mezi C a Pythonem zhola nic.

[pavlix]

Může být.

[l0gik]

A jaký je prosím rozdíl mezi transformací do bytekódu a transformací do strojového kódu?

[Franta]

Bajtkód se dále interpretuje (běhovým prostředím) tzn. neběží přímo na procesoru. A zároveň není čitelný pro člověka, takže to není normální zdroják. Takové jazyky/platformy jsou něco mezi kompilovanými a interpretovanými.

[pavlix]

Nedej bože, aby někdo napsal interpret strojového kódu, to by v tom byl totální bordel. Nebo stroj, který (částečne) interpretuje bajtkód.

A sakra, vždyť oni už to dávno udělali! Obojí! A v několika implementacích. No jo, to jsou ti, co podle povrchní praxe budují novou teorii.

[l4m4]

Tvar výsledku transformace není pro můj komentář podstatný. Podstatné je, jak vypadá (standardní) cílové runtime prostředí. U REPL a běhu na železe úplně jinak.

I blbé změny v časování znamenají, že adaptivní volba algoritmů ve FFTW znamená spuštění úplně jiného kódu v různých prostředích. A pak porovnávej...

[l0gik]

A co je standardní runtime prostředí u jazyků, u kterých existují obě varianty (jak železo, tak virtuálka) a kdo to určuje? IGCLIC? (international group for classification of languages to interpreted and compiled)???

A mohl by si prosím zatřídit např. takový jazyk cython, který se dá přímo (dle dokumentace autorů) používat dvěma způsoby: buďto pomocí cimport načíst přímo do (podle Tebe jistě interpretovaného) pythonu a klasicky interpretovat, nebo zkompilovat do .so pomocí transformace přes C, což je evidetně kompilovaný jazyk, takže evidentně kompilovat? A žádná z těch možností není preferovaná, každá se hodí někdy.

A to víš, že na JAVU existuje i spousta neoriginálních JVM které se v některých detailech odlišují od normy? Znamená to, že je JAVA kompilovaná? Nebo to znamená, že Tvůj druhý odstavec při debatě, zdali se nějak liší interpretované jazyky od kompilovaných nemá význam?

PS: On ani mít význam nemůže, protože třeba taková moderní AMD64 architektura je vždy založena na mikrokódu a tedy to není nic jiného, než REPL smyčka.

[rADOn]

Dokud nezačala tahle zkryplená móda buzzwordismu tak se běžně používal všeliký preprocesing kódu (flex, yacc etc…) ale prostě se tomu neříkalo kompilování. To co můzu nacpat do stroje je poctivý stroják. To s čím si stroj bez cizí pomoci neporadí je bajtkód. Kulička z hovna nad kterou se tu hádáte je ponejvíce produkt marketrotlismu "kompilování" bajtkódu v Javě aby mohli javisti dělat ramena že mají něco víc než vyhoněný interpretr Pokud si uvědomíš že javovský "bajtkód" není schopný běžet bez JVMka a přestaneš takovému jazyku říkat "kompilovaný" tak je hranice jasně daná.

Cython sice obsahuje nějaké běhové prostředí podobné pythonu, ale je zakompilované přímo do binárky. Výsledek je hrouda strojáku nezávislá na nějakém dalším virtuálním stroji, ovšem jak si rač všimnout ne úplně kompatibilní s cpythonem.

[l0gik]

Souhlasím, máš uplně a zcela bez výjimky pravdu.... teda až na ten drobný detail. Víš vůbec, že některé ARM procesory umí nativně běžet Javovský bytekód? Protože tendle fakt jaksi staví Tvoji argumentaci na hlavu. Z pohledu tědle ARMU se Java nikterak neliší od strojáku (see Jazelle) - stejně jako je podle Tvojí interpretace je C interpretovanej jazyk, protože nativně zkompilovaný Cčkový binárky pro motorolu běhal Apple na intelech ve virtuálním stroji.

Stejnětak cython není nyní 100% kompatibilní s pythonem, ale je to vývojový cíl (verze 1.0 být má). Co až kompatibilitu dokončí, co se stane? Bude python kompilovaný nebo interpretovaný? Nebo se zhroutí svět?

[rADOn]

Víš vůbec, že některé ARM procesory umí nativně běžet Javovský bytekód?

Nejenom že to velice dobře vím, ale přímo jsme čekal jestli vypálíš tuhle blbost aniž bys přečetl co jsem vlastně psal. Javovský bytekód je (teoreticky) strojovým kódem takové architektury, moje argumentace platí stejně. Prakticky to nijak zázračně nefungovalo a proto se to nikdy neujalo. Jako argument je to spíš odstrašující příklad proč se java bez JVMka provozovat nedá.

Stejnětak cython není nyní 100% kompatibilní s pythonem, ale je to vývojový cíl (verze 1.0 být má).

Jasně, přístí verze bude dokonalá. Kde já jsem to jen slyšel… Opravdu věříš tomu že existuje nějaky zázračný všelék a že všichni ostatní tvůrci interpretovaných jazyků jsou blbci nebo spiklenci?

Co až kompatibilitu dokončí, co se stane? Bude python kompilovaný nebo interpretovaný? Nebo se zhroutí svět?

Pokud věříš na rozbití celosvětového spiknutí tvůrců interpretovaných jazyků, tak se ti asi opravdu zhroutí svět. Jinak bude záležet jak se autoři cythonu postaví k omezením které klade statická kompilace – buď to bude zase jen omezená podmnožina funkčnosti pythonu nebo to bude obsahovat funkční ekvivalent interpretru včetně mizerného výkonu. Python prostě dovoluje dělat operace které předem zkompilovat nejdou. Nicméně takový zakompilovaný interpret je podle mojí filozofie spustitelný stroják a není na tom nic špatného. Naopak, přesně to ilustruje proč je "kompilování" nezkompilovatelného kódu kokotina. (Pomíjím že zakompilený interpret se hodí z jiných důvodů než honění si kompilačního trika.)

[l0gik]

>> proč se java bez JVMka provozovat nedá..... viz GCJ, který spousta lidí úspěšně používá, protože programy jím kompilované běží často značně lépe, než na JVM

>> Prakticky to nijak zázračně nefungovalo... protože architektura JAVY je pomalá (stack based) a tedy její interpretování může být stejném hardware někdy rychlejší, než nativní běh. Což jen dokazuje, že být "nativní" samo o sobě ještě nezaručuje rychlost (ani nic jiného).

>> aniž bys přečetl co jsem vlastně psal ale já to čet, jen prostě tvrdím, že sis udělal umělou kategorii: kód přímo spustitelný procesorem (což ale pravda, je k tomu potřeba někdo kdo rozumí ELF, linker dynamických knihoven, služby OS atd... a i nativní kód se před spuštěním upravuje: např. mapování dynamických knihoven atd...) a kód, kterej potřebuje před spuštěním nějakou další úpravu. Todle kritérium je ale naprosto umělé, protože nic neříká ani o tom, jak se chová aplikace z pohledu vývojáře, ani jak se chová z pohledu uživatele.

>> ostatní tvůrci interpretovaných jazyků. Hlavním smyslem Cythonu není začít jazyk kompilovat (podobné rychlosti by šlo dosáhnout s dobrým JIT kompilerem), ale zavést typovost a snadné propojení s jazykem C, obojí převážně proto, aby vznikl nástroj vhodný na numerické výpočty. Ostatní tvůrci interpretovaných jazyků mají jaksi jiné cíle a proto volí i jiné prostředky. Holt když se koukáš na problém s předporozuměním, že interpretovanost je zlo, docházíš ke špatným závěrům.

>> interpreteru mizerného výkonu. říká Ti něco JIT? K dispozici jsou papery a dokonce i testy, které prokazují, že některé techniky v JIT mohou vést k rychlejšímu kódu, než statická kompilace. (pomalost Javy je daná něčím jiným, než jen interpretací, což je vidět mj. v tom, že existují i javové knihovny pro HPC).

>> Pokud věříš na rozbití celosvětového spiknutí tvůrců interpretovaných jazyků, Ne, já narozdíl od Tebe nevidím na interpretovaných jazycích nic divného (a když se koukneš na procenta zastoupení, tak se se mnou shoduje většina vývojářů) a nevím, proč by to, že někdo z určitých důvodů udělá kompilátor jednoho jazyka do té doby interpretovaného mělo něco znamenat. Právě proto, že to, zdali je jazyk interpretován nebo kompilován o jazyku nikterak nic nevypovídá.

>> Nicméně takový zakompilovaný interpret... A jak řeší člověk např. v C, když má vykonávat nějaké příkazy vzniklé až za běhu? Úplně stejně: přibalí k programu nějaký interpreter, který umožňí kompilovat věci za běhu. Stává se tím z C interpretovaný jazyk? A vadí něčemu, že v některých jazycích je takový interpret standardně k dispozici a náhodou umí totéž, co samotný jazyk? Např. takový Visual Basic EVAL měl todle uměl a přitom byl kompilovaný. Totéž platí o některých implementacích LISPU. Z toho je jasně vidět, že vlastnost "míti eval" není nikterak omezená na interpretované jazyky.

[JS]

protože architektura JAVY je pomalá (stack based) a tedy její interpretování může být stejném hardware někdy rychlejší, než nativní běh.

Neni to co rikal Radon?

Což jen dokazuje, že být "nativní" samo o sobě ještě nezaručuje rychlost (ani nic jiného).

Nedokazuje. To ze je JVM bajtkod nativni na nejake obskurni HW architekture jeste neznamena, ze pobezi rychleji nez nativni kod na nejake jine architekture. Nativni kod je rychlejsi uz z definice. (A JIT preklada do nativniho kodu, takze to jde opravdu mimo ten argument.)

Zbytek nema cenu komentovat - ty se proste chces hadat.

[rADOn]

Hlavním smyslem Cythonu není začít jazyk kompilovat…

Čili se dostáváš k tomu co jsem říkal na začátku, že taková "kompilace" jen pro fantazii většího výkonu je pikačovina. Nic jiného jsem netvrdil ani o cythonu (potažmoy PyPy a PsyCo) ani o interpretovaných jazycích vůbec.

[l4m4]

Výborně, vhodným kouzlením s pojmy sis dokázal, že černé je bílé, svoboda je otroctví a mezi C a Javou a Pythonem není z hlediska cesty od zdrojového kódu k vykonání žádný rozdíl. Poplácej se po rameni a na základě onoho závěru čiň praktická rozhodnutí. Přeji ti mnoho úspěchů.

[l0gik]

Jasně, argumenty došly, nasadíme jízlivost.

Jestli jsi nepochopil, já nikterak nezapírám, že v x86 procesoru se s C-zkompilovaným kódem zachází jinak, než s Java bytekódem. Já jen tvrdím, že to ale není vlastnost jazyka jako takového, ale maximálně běhového prostředí a architektury, kde se spouští (viz 1) a o vlastnostech jazyka včetně rychlosti to neříká v podstatě nic (2)

1) Protože jaksi existují architektury, které např. JAVU vykonávají nativně, existují prostředí, kde se provádějí C binárky jako bytekód na virtuálním stroji atd... Existuje dokonce "kompilátor" PHP do C# bytekódu a kompilátor C# bytekódu do nativního kódu. Takže když budu chtít, můžu si zkompilovat i PHP. A takový BASIC, typický "interpret" .... začal jako kompilátor a spousta jeho vezí byla kompilována

2) což je vidět na tom, že výkonnostní rozdíl mezi PHP a javou je řádově větší, než mezi C a Javou (v některých případech je java i rychlejší), nebo na tom, že existují kompilované jazyky značně pomalejší než Java (např. forth nebo Visual Basic 5)

[Voty]

Dle IGCLIC jest od této chvíle zapovězeno říkat "XYZ je interpretovaný jazyk", resp. "XYZ je kompilovaný jazyk" a připouští se pouze korektní formulace "Na platformě ABC je jazyk XYZ interpretovaný, neboť je vykonáván interpretrem KLM", resp. "Na platformě ABC je jazyk XYZ kompilovaný, neboť překladač KLM jej překládá do strojového kódu" :)

(Jedná se pouze na draft, návrhy a připomínky posílejte do /dev/null)

[pavlix]

Jedná se pouze na draft, návrhy a připomínky posílejte do /dev/null

Poslal jsem ti hromadu připomínek, tak se snaž :).

[Kit]

Kdysi jsem pracoval s kompilátorem, jehož výstupem byl spustitelný soubor. Když jsem se však do toho souboru podíval, našel jsem v něm běhové prostředí a za ním přilepený bytecode mé aplikace. Byl to tedy kompilovaný nebo interpretovaný jazyk? A není to jedno?

Podle mne nejúspěšnější aplikace vznikly tak, že autor nejprve navrhl vlastní vysokoúrovňový programovací jazyk, ve kterém chtěl aplikaci napsat. Potom v nízkoúrovňovém jazyku napsal jeho interpretr. Pokud mu nestačila rychlost, vložil ještě třetí vrstvu mezi ně - bytecode jako výsledek převodu z vysokoúrovňového jazyka.

Kompilátory do bytekódu a jeho běhové prostředí jsou jen pokusy o více či méně povedenou unifikaci.

[l0gik]

Hmmm, problém je, žes pořád nepochopil, co tvrdím

- jednak nezáleží jen na platformě: na libovolné platformě mohu napsat libovolný překladač či interpret libovolného jazyka. Takže výraz na platformě ABC je jazyk XYZ kompilovaný je furt blbina. Posílám do /dev/null formulaci, která to zohledňuje.

- jednak je důležitý závěr z tohoto pozorování: to, zdali daný zpracovátor jazyka je kompilátor či interpret nevypovídá o jazyku naprosto a vůbec nic, protože to vůbec NENÍ VLASTNOST TOHO JAZYKA ale čistě toho zpracovátoru. Např. k javě dávno existuje čistý kompilátor: změnilo to snad jazyk nějak?

A to je hlavní podstatou mých příspěvků, silně se ohrazujících proti tomu, že "kdosi" tady někdo psal, že to, že pro python zrovna nejpoužívanější implementace je bytecode interpreter, zatímco pro C kompilátor, nějak definuje vlastnosti toho jazyka. Přitom existují jak pro C interpretery, tak pro Python kompilátory a to, že je mezi těmi jazykt rozdíl je dané úplně něčím jiným.

- Z tohodle pohledu je také bazírování na rozdílu mezi trasformací a kompilací naprosto zbytečné honění trika, protože "transformace" je prostě kompilace, akorát do jiného strojového jazyka, než zrovna umí vykonávat ten kus křemíku, kterej je v tomdle počítači. Nebo snad crosskompilace také není kompilace?

[JS]

Ja bych rekl, ze vlastnosti jazyka definuji, jestli se kompilator nebo interpret hodi lip. Napriklad Java pouziva .class soubory. Muzes napsat cisty kompilator pro Javu, ale vezmi si treba pripad, kdy distribuujes nejaky plugin do programu. Pro Javovy program ho distribuujes jako .class, pro C program jako .so. Tedy, tvoje rozhodnuti pouzit kompilator je ovlivnene tim, o jaky programovaci jazyk se jedna, neni na nem nezavisle.

[l0gik]

No vlastnosti jazyka ovlivňují, zdali se líp píše kompilátor, nebo interpret. To s tím pluginem myslím moc na jazyku nezávísí: so soubor napíšeš skoro v čemkoli - a může to být klidně kousíček kompilovaného kódu volající něco interpretovaného. .class soubor také není zdaleka vázán na jeden jazyk.

Tady jde IMHO čistě o to, že když píšeš něco pro nějaké prostředí (architektura, typ procesoru, OS, okolí), tak musíš použít jazyk, ke kterému existuje kompilátor (interpreter) schopný vytvářet kód vhodný pro to prostředí. To, jestli je to kompilátor či interpreter na tom až tak nezávisí: např. do interpretovaného pythonu jdou dělat "pluginy" v interpretovaném pythonu, anebo také v kompilovaném C, Fortranu, Cythonu...

[l4m4]

A já zase tvrdím, že oddělovat běhové prostředí od jazyka je akademické teoretizování, protože úplný popis ho musí zahrnout (a tedy není C jako C).

Ale dobře, když si myslíš, že se jazyky vůbec něčím liší, fajn. Jelikož jsou všechny turingovsky kompletní, jmenuj nějaký podstatný rozdíl mezi nimi na této abstraktní úrovni.

[l0gik]

Ehm.... a já myslel, že jsem tady zrovna na serveru o linuxu, kterej právě žije čistě z toho, že ač je mnoho běhových prostředí, tak existuje jen jedna norma C a proto může být např. jedno linuxové jádro společné pro všechny...

btw. pokud používáš "nedefinovaná chování", tak si to jednak užij, jednak Ti garantuju, že se budou lišit nejen architektury, ale i jednotlivé kompilátory i jejich verze. Právě jeden z hlavních smyslů vyšších programovacích jazyků je právě ODSTÍNIT programátora od konkrétních implementačních detailů jednotlivých procesorů a nabídnout prostředí jednotné.

[l4m4]

Prosím citaci na to, kde jsem psal o používání nedefinovaného chování.

Cílové prostředí je vždy defnováno: například konkrétní jednočip. A ne, nespustíš na něm Linux.

[l0gik]

No pokud nepoužíváš chování nedefinované normou, pak se C, pokud je správně naimplementováno, chová všude stejně, a tedy na běhovém prostředí opravdu nezáleží.

Ano - jsou platformy, na kterých jazyk C neexistuje, nebo existuje jeho proprietální zmršenina. A jsou i platformy, kde třeba nejsou v C potřebné drivery. Ale, mám za to, žes zrovna Ty tady psal o nesmyslnosti akademických debat...

PS: Samozřejmě, platformy se občas dosti liší dostupnými knihovnami. Ale jak to souvisí s jazykem? Knihovny jsou linkovatelné z libovolného jazyka.

[l4m4]

Freestanding C implementace, kde není ani libc, je normálně podle standardu.

V realitě se nepíše pouze pro nějaký standard, ale vždy pro definované cílové prostředí, které bude mít určité vlastnosti nedefinované standardem (i hello-world.c předpokládá hosted C), do čehož patří všechno od knihoven, přes vlastnosti dynamického linkeru až po konkrétní hadrware. Co je na tom akademického?

[l0gik]

Ano - a hosted C je ovšem také standard jazyka. Otázka je, který standard, když srovnáváme C s dalšími jazyky je asi ten relevantní, o kterém se bavíme. Jelikož u ostatních jazyků také ke standardu patří i implementace standardní knihovny, tak normální člověk předpokládá hosted C.

Máš pravdu, že argumentace freestanding C není akademická debata - je to křečovitá snaha obhájit si svůj názor tím, že běžnému významu slova "C" tak, jak mu bude bez bližší specifikace rozumět 99% lidí, dáváš jiný význam (zeptej se kohokoli, kdo umí C, jak vytisknout řetězec: kolik z nich ti neodpoví puts popř. printf, ale začne řešit freestanding C?).

[l4m4]

Já jsem nezačal s tím, že navzdory tomu, že jazyk X v drtivém počtu případů vykazuje vlastnost Y a běžně se bere za pro něj charakteristickou, tak to není inherentní vlastnost a existují situace, kdy se něco dělá jinak. Kdo si co navařil, ať si to taky sní ;)

[l0gik]

Furts to nepochopil: jazyk X žádnou v drtivé většině případů nevykazuje vlastnost Y, býti kompilovaný prostě není vlastnost jazyka jako takového, ale jeho kompilátoru. O jazyce to neříká vůbec ale vůbec nic. Schválně se podívej např. do normy ANSI C, kolikrát se tam mluví o kompilaci (výskyt toho slova je tam asi pětkrát). Nebo se koukni na JAVU: ta pravda standardizuje svůj bytekód, ale co má spolu společného java, javascript, closure jako jazyky? Nic. a přesto jdou kompilovat do stejného bytekódu.

Ta distinkce není žádné slovíčkaření, ale podstatné pozorování, které ukazuje, že soudy: "jazyk X je kompilovaný, tedy je pomalý" jsou ve skutečnosti špatné, protže ta pomalost je daná nikoli tím jazykem, ale použitým kompilátorem. Což má i praktický dopad: protože není třeba měnit jazyk, stačí měnit kompilátor (iterpret). S tím, na jakém kompilátoru/interpreteru je ten jazyk běhán nejčastěji to nikterak nezávisí. Naopak Ty jsi v diskusi smísil dva naprosto rozdílné jazyky (pro vývojáře je daleko větší rozdíl mezi freestanding C a hosted C: jak v komfortu psaní, tak v tom, kde se tyto jazyky užívají, než např. mezi hosted C a Javou) a na základě toho zmatení pojmů jsi se snažil argumentovat.

A furt tady zůstává ten Tvůj obrovský rozdíl mezi kompilovanými a interpretovanými jazyky, který spočívá čistě v tom, který virtuální stroj umí či neumí výsledný bytekód vykonat (btw. ani exáč/ELF není spustitelný sám o sobě, vyžaduje nějaký runtime). Pro normálního člověka to prostě žádný rozdíl není, např. s Javou je vývojový cyklus naprosto stejný jako s C, v dobře zkonfigurovaném OS se neliší ani spouštění (a v špatně nemusíš spustit ani ten ELF). Kde je ten obrovský rozdíl, který je třeba řešit? V tom, že když přenesu daný kód na jiný stroj (arm s jazelle), tak je to najednou naopak?

[l4m4]

Áha, takže jsme zpět u akademických kydů ;)

Je podle tebe to, že jazyk C vznikl okolo roku 1972, jeho vlastnost, nebo není?

Pokud to je jeho vlastnost, tak existují vlastnosti jazyka, které nejsou předepsány standardem, ale jeho původem, užitím, etc.

Pokud to není jeho vlastnost, tak co to tedy je? A ať už zde použiješ jakýkoli termín, tak já v tomto smyslu zde užívám slovo vlastnost, a užívati budu nadále.

[l4m4]

s/ale jeho původem/ale dány jeho původem/

[pavlix]

Áha, takže jsme zpět u akademických kydů ;)

Já myslel, že ty tu vedete celou dobu :D.

[l4m4]

Nj, nj, jdu klečet do kouta :D

[l0gik]

Ano, jazyk C vznikl 1972. Takže je to jeho vlastnost. Ovšem je to veskrze nepodstatná vlastnost, která nemá žádný vliv na to, jaký ten jazyk je, jak se v něm co dobře vyvíjí atd.... To ovlivňuje pouze standard jazyka a dostupné nástroje k tomu jazyku (které už ovšem vlastností jazyka samotného nejsou: může existovat kvalitní programovací jazyk, ovšem na dané architektuře např. bez debuggeru a tedy těžko v praxi použitelný).

Totéž platí o původu - opět je to sice vlastnost jazyka, ale nic o něm neříkající. Užití jazyka pak už vůbec není vlastnost jazyka, ale někdy fakt vyplývající z jeho vlastností a někdy fakt vyplývající z něčeho úplně jiného.

[l4m4]

Opravdu si myslíš, že to, jak se jazyk vyvíjí, je určeno pouze standardem? To asi žijeme v různých vesmírech. V tom mém se to, jak se jazyk vyvíjí, promítá do dalších verzí standardu.

Existence nástrojů je vlastnost jazyka, protože je to něco, co k jazyku inherentně patří. A ano, může se s časem měnit, stejně jako se s časem mění i ,akademické` vlastnosti, tedy specifikace.

Řekne-li se Python, představím si nejen specifikace, ale i standardní knihovnu, šíři různých implementací, bindingy pro knihovny, ... až po zvýrazňování syntaxe ve vimu. I všechny tyto externality k němu patří. Chceme-li se bavit o formálních specifikacích, bavme se o nich, ale v tom případě se bavíme o vybraném aspektu jazyka: jeho formální specifikaci, nikoli o celku.

[pavlix]

Opravdu si myslíš, že to, jak se jazyk vyvíjí, je určeno pouze standardem

Nějak takové tvrzení nemůžu najít v jeho příspěvcích. Že by sis to vycucal z prstu?

[l0gik]

Kdo mluví o vývoji jazyka? Jazyk ať se vyvíjí jak chce. V jeden konrkétní čas má ale jeden standard (ať už psaný, nebo nepsaný) a ten určuje jeho vlastnosti.

Mezi změnou nástrojů umožňující snažší vývoj v daném jazyce a změnou specifikace jazyka samotného je ohromný rozdíl. Když si upravím nástroje, pořád můj kód splňuje standard jazyka a tedy je použitelný i bez těch mých nástrojů. Mohu je tedy bez jakýchkoli problémů rozšiřovat, měnit, použít najednou úplně jiné nástroje. Kód to ovšem nechá zcela netknutý a kdokoli mající kompilátor jazyka daného standardu může můj kód zkompilovat a podílet se na vývoji.

Pokud si upravím standard jazyka jako takový, vytvořil jsem nový jazyk, protože můj kód už nadále není zpracovatelný ničím jiným, než pouze tím mým upraveným kompilátorem.

Standardní knihovny samozřejmě k standardu jazyka patří a je to dokonce pro vývojáře jedna z nejdůležitějších vlastností jazyka (možná nejdůležitější): proto také tvrdím, že freestanding C a hosted C jsou zcela jiné jazyky, defakto od sebe vzdálenější než např. C a Java.

PS: Samozřejmě, při zvažování jaký jazyk užít je třeba zvážit i dostupnost vhodných nástrojů pro vývoj. To ale není věc samotného jazyka, stejně tak člověk musí např. zvážit cílovou platformu (OS atd...) a také to přitom není záležitost jazyka, byť některé platformy člověka ve volbě jazyka omezují.

[chochi]

Ahoj, to co hledas se jmenuje REPL. V tom clanku na wikipedii je odkaz na nejake projekty v C/C++, ale netusim, neb me nikdy nic takoveho v C/C++ nenapadlo.

[l4m4]

REPL pro kompilované jazyky může být užitečná hračka pro blbnutí s výrazy nebo jednoduché zkoušení knihovních funkcí, avšak je zapotřebí si vždy uvědomovat, že nereprodukuje binární kód, který vygeneruje reálný kompilátor + linker, ani podmínky, za kterých poběží, pouze se to pokouší emulovat.

Ineraktivní interpret interpretovaných jazyků je naproti tomu stejný jako neinteraktivní, byť může volitelně poskytovat různé vychytávky pro interaktivní mód.

[Kit]

Považuji za hloupost snažit se interpretovat jazyk C. Daleko užitečnější bude, když si navrhneš vlastní jazyk, který bude splňovat požadavky pro interaktivní práci a v C/C++ si napíšeš jeho interpretr.

Není vždy nutné používat sílu Pythonu či Javy. Někdy jen stačí nechat se inspirovat třeba jazykem Waduzitdo, i když tak primitivní (neúplný) jazyk bude jen stěží hledat uplatnění.

[l4m4]

A poté, co navrhneš vlastní jazyk, nezapomeň ještě navrhnout vlastního package managera, nebo rovnou celé linuxové distro, zdokumentuj to ve vlastním formátu dokumentace, který popíšeš na stránkách vytvořených pomocí vlastního webového frameworku...

Navrhnout vlastní jazyk je samozřejmě zajímavé intelektuální cvičení. Ale jako cvičení by to taky mělo zůstat. TriINTERCAL na tebe...

[Kit]

Však tady jde hlavně o intelektuální cvičení. Pokud specifikuji, co by daný jazyk měl umět, snáze vyberu nejvhodnější. A pokud si nevyberu, tak většinou ten požadovaný jazyk je mnohem jednodušší, než všechny nabízené a dá se slepit za pár hodin.

Zapomeň na package managera a další popsané "závislosti". To přece není nutné.

TriINTERCAL vypadá zajímavě, ale nepoužitelně. Sám jsem si kdysi vyrobil vlastní interpretr na 120 řádcích, který mi slouží dodnes.

[Radek Miček]

Ale jako cvičení by to taky mělo zůstat.

Když by se tím řídil každý , tak by nedocházelo k žádnému pokroku.

[Kit]

Díky za zastání. Ostatně jsem neměl na mysli žádný univerzální jazyk, ale jazyk určený k řešení konkrétní úlohy. Dnes se tomu honosně říká "interface". Teprve ve chvíli, kdy se budu snažit z toho udělat univerzální jazyk, vznikne ten správný paskvil, viz třeba ORM.

[JS]

Super! Autor je zjevne zacatecnik a ty mu doporucis, at si navrhne vlastni jazyk...

[Kit]

Však to je úloha pro začátečníka. Ty jsi snad začínal na něčem složitějším?

[JS]

Podotykam, ze mluvime o navrhu, ne implementaci jazyka.

[Kit]

Správně vedený začátečník zvládne obojí během velmi krátké doby.

[Ivan]

Tahle cela debata uhnula kousek vedle. Bud si stahni MSVC Express od Microsoftu, anebo pouzij Eclipse CDT. Obe prostredi se snazi o alespon castecnou syntaktickou kontrolu toho co pises. Takze nemusis porad dokola kompilovat, abys nasel nejakej preklep.

C++ bohuzel neni jazyk, kde by bylo neco takoveho udelat na 100% bez kompilatoru, takze stejne musis cas od casu kompilovat.

[Roman DAVID]

Pripadne zkusit Code::Blocks (http://www.codeblocks.org).

To je IDE pro C++

[iwtu]

Ahoj, Ultimatne IDE pre C a C++ sa povazuje KDevelop, ale pre zaciatocnika to moze byt vopruz. Na Windowse je najlepsie Visual Studio. Je to trochu moloch, ale vyjde z neho aj zaciatocnik. Na uvod je pekne, jednoduche a multiplatformove IDE Qt Creator (s nim by mozno bolo aj najlepsie zacat).

Ale kazdopadne odporucam aj napisat program v nejakom textovom editore a potom ho skopirovat rucne, aby si mal predstavu, ze co vlastne deje.

Good Luck. (sakra, preco ma vzdy pri tej fraze napadne Taken)