Nejak to nechapu. Obavam se, ze lide nepouzivaji C, Java, PHP, Perl pro jejich syntax ale pro to co je v tom jazyku mozne v ramci unosne namahy napsat. Casto tak o vhodnosti jazyka nerozhoduje jazyk sam, ale to co je okolo neho. Jako je velke mnozstvi ruznych modulu (Java), trivialnost a rozsireni (PHP), duraz na nejakou oblast (text+Perl), rychlost a volnost (C). U rady hlavne iterpretovanych jazyku pak o jejich pouzitelnosti rozhoduji veci (moduly) psane v zcela jinem jakyku (vetsinou v C).
Hodne dulezita je u kazdeho noveho jazyka i "tvar" kterou nastavuje okolnimu svetu v podobe nejakeho low-level rozhrani, ktere umoznuje rozsirovat schopnosti jazyka pomoci neceho co jiz exitovalo pred nim (JNI a podobne ve vsech jinych).
Vznikaji stale nove jazyky a vetsinou se snazi neco noveho prinest -- casto v oblasti nejakych pokrocilych datovych typu (pike) nebo ve vztahu k tomu jak jsou zpracovavany (C#, mono), nebo na co a na koho jsou zamereny (PHP) apod.
V tomdle clanku nebyla predvedena jedina zajimava vlastnost a pri tom u neceho takoveho jako je programovaci jazyk by jich tam melo byt alespon deset ;-)
Jinak k autorum: o prehlednosti nerozhoduje begin/end, ale zarovnavani a prace s textem kodu jako s celkem. Viz. treba Python kde zadna zazracna sluvka nejsou, ale i tak ten kod je vzdy i kdyz je programator prase zcela prehledny.
Mluvíte o rychlosti a volnosti céčka, jenže ta volnost je někdy na překážku přehlednosti. Flex je navržený tak, aby "volnost" trochu omezil, aby programátora hlídal a nedovolil mu dělat "podivné" věci - například přiřazení signed a unsigned čísel není ve Flexu dovoleno (resp. musí se explicitně přetypovet). A není to míněno jako buzerace, ale spíš jako připomenutí, že když v programu potřebuju přiřazovat signed do unsigned, tak asi něco není v pořádku s návrhem programu. Takových věcí je ve Flexu plno (říká se tomu silná typová kontrola) a do článku se opravdu všechny nevešly. V manuálu přirozeně popsané jsou.
To ne, Flex vznikl proto, že jsme chtěli přestat dělat hloupé chyby v aplikacích. Přepínač -Wconversion skutečně neznám, ale předpokládám, že neodstraňuje principiální problém (nebo vlastnost?) céčka, že typedef pojmenuje konkrétní typ, ale nezavede typ nový, z principu nekompatibilní.
No, ten prepinac jenom varuje, kdyz posilate signed/unsigned typ jako argument, a prototyp to ceka jinak. gcc umi jeste varovat kdyz se srovnava signed a unsigned na vetsi/mensi, protoze neni jasne jaka semantika se ma pouzit. Ale mate pravdu i tak, C i C++ ma furu dalsich nedostatku *pro pouziti jako aplikacni jazyk*, a volna konverze signed/unsigned/enum je jenom vrchol ledovce.
Na C se mi snadne pretypovani velice libi. Jeste vice v Perlu.
Predstava, ze by typedef vzdy zavedl nekompatibilni typ a ja bych musel explicitne pretypovavat mezi napriklad pid_t, mode_t, loff_t, ssize_t a int me zadne dodatecne uspokojeni nedava - kdo si ma pamatovat, jak si ktera funkce pojmenovala ten int ktery vraci. Je to zbytecna prace, stejne se to vsechno prelozi na stejny datovy typ.
Taky cim je jazyk ukecanejsi, tim se v nem hur orientuje. Strukturalni prvky jazyka by nemely zabirat zbytecne misto. Je lepsi vystacit si s jednim radkem kodu a jednim komentare, nez to same psat na pet radku s tim ze je to typove koser.
Kdyz se v nejakem jazyce neda udelat nejaka chyba, tak to casto spis vypovida spis o jeho omezene pouzitelnosti. Pamatuju na "programovaci jazyk" Karel, ktery v tomto ohledu dosahl temer dokonalosti...
Jeste neco. C ma prisnejsi kontrolu typu nez by melo mit. Potreboval jsem zarovnat data na okraj stranky a napsal
(write_data + PAGE - 1) & (~PAGE)
ale AND mezi pointerem a integerem neni dovoleny, takze to budu muset napsat o dost sloziteji.
Pritom v implementaci to jsou oboje cela cisla.
Silna typova kontrola ze je nejaka vyhoda? Mozna tak v OOP, pri praci s pameti tezko.
A kdyz uz bych chtel OOP, tak asi v Jave, to je dost rozsirene a zabehane.
To souhlasí. Tedy pokud si jazyk navrhujete sám a rozumně. Pokud píšete překladač C (nebo, chraň bůh, C++), zaděláváte si automatickým generováním syntaktického analyzátoru na problémy, protože ty jazyky mají naprosto šílenou gramatiku.
IMHO je yacc/bison nástroj vhodný akorát tak pro výuku atributovaného překladu LALR jazyků, pro práci je ručně napsaný rekurzivní sestup lepší. Není důvod nenavrhovat umělé jazyky jako LL(1). S těmi už existujícími, které LL(1) nejsou, je potíž, no. Nechtěl bych psát překladač Céčka :)
Možná bych se uvolil k použití nějakého jiného nástroje pro automatizaci tvorby překladače (třeba ANTLR, dříve PCCTS, vypadá dobře), ale u rozumných jazyků k tomu v podstatě není důvod. Prohlédněte si třeba parser Ady v GNATu, skvělá ruční práce :)
V podstatě. Ono v podstatě Céčko je totéž co Pascal. Ale:
1. ANTLR generuje kód pro analýzu rekurzivním sestupem (čitelný běžným smrtelníkem).
2. Parser vygenerovaný ANTLR vytváří (může vytvářet) abstraktní syntaktický strom (nikoliv derivační strom).
3. ANTLR umí generovat kód pro průchod stromem.
4. ANTLR pracuje s predikátovými LL(k) gramatikami, díky čemuž je schopen (pochopitelně když mu příslušnou gramatiku předhodíte) vygenerovat parser i pro jazyky, které nejsou LL(k) či LR(k).
Dalo by se pokračovat, tohle jsou hlavní body, na které jsem si vzpomněl. Více informací najdete na webu.
Nechci kázat o tom, jak je ANTLR mnohem kvalitnější a uživatelsky příjemnější, protože jsem ho nezkoušel. Ale rozhodně se mi tak jeví.
<flame>
A mimochodem, ANTLR je public domain, žádná pofiderní GPL licence :)
</flame>
Mno kdyz je programator opravdu prase tak je kod neprehledny at uz je napsan v jakemkoliv jazyce. Je ale pravda ze nektere jazyky (nebudu jmenovat, ale napriklad Perl :o) kdyz je pise prase tak maji o dost vetsi tendence byt naprosto nerozlustitelne nez jine....