The C language (diskuse)

[mirec]

Nabudúce poprosím aj perex anglicky nech nemusím klikať. Ďakujem.

[=^..^= AmigaPower®]

+1

[Grunt]

Proč?

[=^..^= AmigaPower®]

...proč dělat věci jednoduče, když to jde složitě?

[Grunt]

Aspoň se člověk zasměje.

[____]

Co jste chtěl, máte mít. Ale netuším, co přesně jste s perexem v češtině měl za problém.

[mirec]

No ja konkrétne keď vidím tému ktorá ma zaujme a je v češtine (tj. slová vyzerajú česky, perex čítam až po kliknutí na blog) tak na ňu kliknem .. takto by mi to ušetril klik ;) Nehovoriac o tom, že mi práve vtedy vypadol prúd takže to bolo jediné čo som mohol v tej chvíli čítať.

Pôvodne som nechcel nič písať o tejto téme .. no ale predsalen niečo napíšem. C bolo vyvinuté na nízkoúrovňové programovanie. Má slúžiť hlavne ako náhrada assembleru. V niektorých prípadoch je dokonca lepšie použiť assembler. Len pre zaujímavosť sťažuje sa niekto z assembleristov, že nemajú garbage collector?

Čo sa týka vlákien - je to vecou skôr knižníc. Štandardna knižnica sa snaží byť minimalistická vzhľadom na to, že C by malo byť schopné bežať na aj dosť divokých hardwarových platformách. Neviem či by bolo moc šťastné dávať implementáciu vlákien priamo do štandardnej knižnice.

Také C++ už podporu vlákien (i keď relatívne jednoduchú) má. Je fakt, že C na prenositeľné aplikácie moc vhodné nie je i keď urobiť sa to dá aj tam (ale komu by sa chcelo písať všetky tie #ifdef a platformovo závislé veci viac-krát?).

[____]

C má v oblasti multithreadingu trochu odlišný problém než neexistence standardního API pro vlákna. Jsou to právě non-thread-safe a non-reentrant funkce, které byly navrženy v dobách, kdy multithreading byla velká neznámá a opravuje je až POSIX norma, kterou ne všechny knihovny pro jazyk C podporují (viz odlišný přístup Microsoftu a jeho "secure" funkce, které přišly spolu s Visual Studiem 2005).

 

 

[deda.jabko]

pred psanim textu by sis mel ujasnit o cem vlastne budes psat... nejdriv rikas,ze budes kritizovat jazyk C a pak nadavas na problemy ,,standardnich knihoven''.

[____]

Když pominu, že tyto dvě věci jsou velmi úzce spojeny, tak bys mohl brát v potaz, co jsem napsal do perexu, a to že jsem vůbec nechtěl, aby to bylo dokonalé pro všechny čtenáře, kteří to uvidí. Weblog je osobní deníček a ne vyhrazený prostor pro odborné články.

[Let_Me_Be]

Ano a diskuze pod nim slouzi k tomu aby ti vsichni oznamili jaky jsi pitomec

[lukve]

No podla mna ma Linus pravdu a urcite ma aj prakticke skusenosti. Jednoducho C je dobre na veci ktore su systemove.. Len tak na zamyslenie ja nemozem pochopit ako niekto moze mat rad napr. Menuet alebo Kolibrios ktory je cely v asemblery.. jednoducho je to sialenstvo.. preto vzniklo aj C jazyk ktory bol po tejto stranke -prenositelny- medzi architekturami na rozdiel od asemblera. Na druhu stranu mame tu aj operacne systemy ako Haiku ktore maju aj jadro v C++ a velmi sa mi to nepaci. ale zase na GUI je lepsie C++ nez C koli vyssej forme abstrakcie myslim objekty a tak.. len si porovnajme QT a GTK+ kedy QT ma navrch odhliadnuc od toho ze sam pouzivam xfce zase mam radsej Qt  a kod sa mi zda lepsi na tvorbu gui aplikacii. Na druhu stranu tu mame aj systemy ako Plan9 ktory sa drzia striktne nejakej zastaralej specifikacie C. a na svete je viacero kompilerov nie len MS a GNU. ale tie sa najviac pouzivaju.. napr. taky ACK ktory je v Minixe

[dad]

... ale zase na GUI je lepsie C++ nez C

ja uz bych konecne jednou krome techto legend videl nejakou studii, ktera to potvrzuje.

[Josef Kufner]

Když se podívám, jak lehce lze vyrobit vlastní widget v Qt a v Gtk, není moc co dodat. Podpora jazyka v tomhle je velmi přínosná.

C mám velice rád a považuju ho za svůj druhý rodný jazyk, ale prostě není universální -- stejně jako jakýkoliv jiný jazyk.

Myslím, že v mnoha případech nejlepší cesta (u netriviálních programů) je napsat výkonné jádro v C a k tomu naskriptovat GUI v něčem vysokoúrovňovém (výše než C++).

[jk0man]

V čem třeba?

[carray]

tak ano psat cely kernel v assembly je celkem silene ale zase snazit se ho psat objektove (ci aspektove jako napriklad Singularity) je podle mne jeste vice blaznive .. C se pro tento ukol hodi a i "objekty" se relativne daji udrzovat i v pure C .. nevidim duvod proc nepouzit pure C trebas i na CGI web app ikdyz je to trochu nezvykle .. jinak ad Qt..jeho zpusob meta object compiler mi obcas nahani husi kuzi ..

[____]

Mně osobně se přístup Singularity zas líbí :). Je to něco nového a ne zastarávající C ani C++, i když je stejně v minimálním množství přece jen určitě používají. Snaží se to navrhnout znovu a správně a kašlat v jisté oblasti na kompatibilitu a zvyklosti, které postupně přerůstají přes hlavu.

[carray]

Já jsem jen poněkud skeptický v kombinaci Microsoft a AOP. Z praxe s každým novým produktem vyrostl výkon o více procent než je únosné, doufám že se Singularity alespoň pokusí tuto "tradici" zlomit (ovšem už předem oblékám černý smuteční oblek)...

[____]

Ono se časem uvidí. Peněz na vývoj mají dost a zřejmě by ten projekt nenechali jen tak dojít k uzavřenému Midori, kdyby to bylo tak nevýhodné. Za sebe se velmi těším na to, co z toho vzejde, a mezitím budu holt používat to, co bude k dispozici.

[carray]

Když z toho nebude jen přepsaný Windows 3.11 kernel do AOP tak proč ne .. Jinak peníze jsou zavádějící a neznamenají automaticky úspěch .

[C]

Cemu rikas "objekty" v pure C?

[____]

Podívejte se třeba na tohle PDF.

[carray]

Za jakýsi druh objektů lze v C považovat:

• struct + funkce operující s danou struct
• struct + function pointer

Pozn.: Neříkám že je to OOP, nemá to spoustu OOP vlastností jako např. dědičnost (ač. jednoduchá z jedné struct se dá relativně lehce napsat), atd.

[Matlák]

Mně osobně například tento systém (struct + funkce operující s danou struct) vyhovuje občas víc než C++ přístup z množstvím věcí které vlastně nevyužiji.. Osobně mi čistý C kód přijde také mnohem čitelnější. Ovšem složitější GUI (s více okny a množství widgetů) v čistém C bych psát nechtěl..

[____]

Ad MenuetOS/KolibriOS: Okolo těch jsem prošel a vůbec nechápu, jak v tom může někdo naprogramovat tak kompletní prostředí s tak minimalistickým kódem (jinak jazyk symbolických instrukcí moc neznám). Tito programátoři mají můj obdiv. U nich, myslím, šlo čistě o to vyzkoušet si napsat v Assembleru něco zajímavého a nemá příliš smysl pokračovat v nějakém rozsáhlejším vývoji těchto operačních systémů.

C sice určitě řeší do jisté míry problém Assembleru, ale jak jsem napsal, není v tomto směru dokonalé (holt je trochu jiná doba) ani ho nemůže zcela nahradit. A ano, je tu více kompilerů, však jsem to nepopřel. Šlo mi o ty hlavní, s kterými jsem měl tu možnost se setkat.

[Ondrej 'SanTiago' Zajicek]

K prvni casti - tohle proste neni problem jazyka. Pokud chces psat portabilni program tak nekde ta abstraktni vrstva byt musi - but bude soucasti standardni knihovny, nebo jako externi knihovna. Myslim, ze je lepsi, kdyz v jazyce je primo pristupne nativni rozhrani, a abstraktni portabilni rozhrani je spis jako option, nez kdyz je to naopak.  Treba proto, ze propast mezi nativnim a abstraktnim rozhranim muze byt znacna, mapovani je dost neprirozene, nektere obskurnejsi funkce nativniho rozhrani casto nejsou v abstraktnim rozhrani dostupne a malokdy se dari napsat portabilni (napr. mezi POSIX systemy a Windows) aplikaci, ktera by dobre zapadala do obou systemu.

Zatimco projekce nativniho rozhrani do jazyka je obvykle primocara, tak tech abstraktnich portabilnich rozhrani je mozne navrhnout spousty a neni tedy jasne, ktera by v jazyce byt mela. To je tedy dalsi duvod, proc je lepsi mit v jazyce primarne nativni rozhrani a az jako volitelne (formou externi knihovny) abstraktni portabilni vrstvu (nebo nekolik, aby si programator mohl vybrat, ktera mu vic vyhovuje). A pro C existuje minimalne nekolik portabilnich vrstev.

[dad]

... Zatimco projekce nativniho rozhrani do jazyka je obvykle primocara ..

mate na tu vetu copyright, nebo se da volne pouzivat? Jestli jo, tak uz se tesim, jak to na pristim projekcnim sezeni hodim do placu. To budou kolegove koukat ...

P.S. Nijak to nezesmesnuji, priznam se, ze tomu co jste napsal vubec nerozumim. Mozna by to chtelo nejaky priklad.

[Ondrej 'SanTiago' Zajicek]

> P.S. Nijak to nezesmesnuji, priznam se, ze tomu co jste napsal vubec nerozumim. Mozna by to chtelo nejaky priklad.

Jednoduche - pokud unixovy syscall open akceptuje (na systemove urovni) pointer na string a dva integery a vraci integer, tak primocara projekce daneho rozhrani do nejakeho jazyka proste bude mit funkci open s argumenty akceptujicimi nejakou (jazykove zavislou) reprezentaci stringu a dva integery a vracet integer. O trochu mene (ale porad jeste dost) primocara reprezentace treba bude reprezentovat druhy a treti argument jako seznamy symbolu a vracet bude objekt reprezentujici file handle, ale porad ty symboly budou mit 1:1 mapovani na prislusne flagy a prace s filehandlem bude mit stejnou semantiku jako v ceckovem rozhrani.

[AHAHA]

Zatimco projekce nativniho rozhrani do jazyka je obvykle primocara, tak tech abstraktnich portabilnich rozhrani je mozne navrhnout spousty a neni tedy jasne, ktera by v jazyce byt mela. To je tedy dalsi duvod, proc je lepsi mit v jazyce primarne nativni rozhrani a az jako volitelne (formou externi knihovny) abstraktni portabilni vrstvu (nebo nekolik, aby si programator mohl vybrat, ktera mu vic vyhovuje). A pro C existuje minimalne nekolik portabilnich vrstev.

To plati samozrejme jen u "obecnych" jazyku, ktere maji aspirace na pouziti a vsude a na vsechno (jako prave ono C).

[Grunt]

First of all, C is everything but portable.

Cože?

[carray]

>>> Cože?

Napriklad vlakna jsou velice portable ze .. pokud nechci pouzit openmp a chci pouzit jen native tak musim psat jak pro wapi tak pro posix a ono to zachvili omrzi .. a prikladu by se naslo mraky ..

[Jardík]

Vlákna nejsou součástí jazyka C.

[disorder]

ja so uspesne pouzil pthreads pre win32, pomenil par riadkov kodu pre otvorenie socketu (non-blocking) a nakoniec to slo...

[disorder]

a GUI je v Gtk+

[disorder]

a nakoniec je tam este aj gthreads pouzivane z Gtk+, takze pthreads by tam nakoniec asi ani nemuselo byt, ked to ma GUI

[____]

Hyperbola.

[carray]

nn, derivace e^x podle y :P

[Ladicek]

Je fakt, že by se to dalo říct líp. Dovolte mi to zkusit.

C is everything but necessary.

[AHAHA]

A jaka je jeho nahrada? (systemove programovani, extremni prenositelnost)

[Ladicek]

Když jde o Céčko, je zvláštní, kolik se vždycky vyrojí systémových programátorů… No, já osobně jsem názoru, že obojího lze, a mnohem lépe, dosáhnout s vyššími programovacími jazyky. Už dávno jsme dosáhli stavu, kdy low-level věci mohou v naprosté většině situací plně řešit překladače. Vezměme například Adu: výborné možnosti generického programování, paralelismus zabudovaný přímo do jazyka (ale žádné usmolené zamykání), podpora garbage collectoru, na druhé straně možnost přímo v jazyce psát assembler. Stejně dobře to může fungovat s řízenými jazyky, viz třeba tu výše zmíněnou Singularitu.

Céčko má naproti tomu jen jednu věc, která je ovšem bohužel rozhodující: dávnou unixovou tradici worse is better. Toť vše.

[AHAHA]

Jazyky vyssi urovne maji urcitou rezii, coz je treba nejen u jadra OS stale relevantni.

Krome toho pro C mluvi hlavne:

- jednoduchy jazyk, jednoducha implementace. Kompilator lze udelat pro takrka kteroukoli platformu. Na nejakych embedded zarizenich s procesorem bez multitaskingu asi Ada nepochodi.

- z toho vyplyvajici velke mnozstvi existujicich implementaci

IMHO je v nekterych oblastech C proste nenahraditelne.

[Ladicek]

Mikrokernely taky mají určitou režii, a pořád se o ně někdo snaží

Implementovat Céčko jednoduché není, jeho syntaxe je vrcholem prasečkářství a udělat rozumný překladač dá pěknou práci. Tím myslím nejen spolehlivost a kvalitní optimalizace, ale například i srozumitelné chybové hlášky. V tomhle bodě je například GCC vyloženě v háji – doporučuju kouknout na web Clangu, Céčkového překladače z projektu LLVM.

Asi máte na mysli přímočaré mapování jazykových prostředků na hardware, s tím bych celkem souhlasil, ukazatelová aritmetika je z tohohle pohledu naprosto přirozená. Ale co to takhle dotáhnout do konce? V Céčku například nejde získat adresa návěští, v GCC na to mají speciální operátor &&, velice užitečná to věc. Nebo jasně definovaná velikost datových typů. Pokud to není z nějakých důvodů možné, má jazyk poskytnout prostředky pro vlastní definici.

Ada je naopak pro embedded použití vyloženě navržená. Ale ona se moc neuchytila skoro nikde. Stručně a jasně je to popsané třeba tady: http://www.embedded.com/212902632. Má samozřejmě svoje vady, o tom žádná.

[finn]

Já bych třeba Adu rád zkusil, ale: prakticky každý výrobce mikrokontrolérů nabízí céčkový překladač, ale překladač Ady jen zcela výjimečně. Což znamená volit HW platformu podle překladače, a asi nemusím vysvětlovat, jaké by to přineslo další problémy…

[pht]

GNAT by toho mohl umět cross-kompilovat docela dost.

[AHAHA]

Mikrokernely taky mají určitou režii, a pořád se o ně někdo snaží

Zatim ne moc uspesne (co do vykonu).

Implementovat Céčko jednoduché není, jeho syntaxe je vrcholem prasečkářství a udělat rozumný překladač dá pěknou práci. Tím myslím nejen spolehlivost a kvalitní optimalizace, ale například i srozumitelné chybové hlášky. V tomhle bodě je například GCC vyloženě v háji – doporučuju kouknout na web Clangu, Céčkového překladače z projektu LLVM.

Co je na syntaxi C "praseckarstvi"? V C jdou delat silene veci, ale je to spis dukaz flexibility syntaxe a rozhodne to neznamena, ze se tak ma programovat.

Jinak je IMHO daleko snazsi udelat prekladac Cecka nez prekladac treba te Ady. Generovani optimalizovaneho kodu je IMHO casto prilis velky luxus. Nesrozumitelne chybove hlasky jsou dany jednak unixovou tradici a druhak onou flexibilitou syntaxe.

[Ladicek]

Kucí od QNX na tom asi s výkonem nebudou až tak špatně

Kousek níž jsem odkazoval SPECS. Je to sice syntaxe pro C++, ale ono těch rozdílů zas tolik není. Je zřejmé, že za plného zachování sémantiky (dobře, SPECS zakazuje pár drobností jako větev switche neukončená breakem, ale jsou to detaily) lze definovat mnohem lepší syntaxi, která bude líp čitelná pro lidi i pro stroje. Že na přečtení prototypu funkce je potřeba algoritmus, který má v Heroutově učebnici asi půl stránky nebo stránku, je dost děsivé. Tomu neříkám flexibilita, tomu říkám zhovadilost. Hleďme na rozdíly:

void (*set_new_handler(void (*)(void)))(void);

versus

func set_new_handler : (^(void->void) -> ^(void->void));

Já osobně mám zcela jasno. Chápu ovšem, že pravověrní na mne budou koukat jako na blázna, neboť ve SPECSu se pro přiřazení používá :=.

Napsat překladač Ady určitě není prča, GNAT má půl milionu řádků a je to jenom frontend. Zajímavé na tom je, že backend je GCC, takže zadarmo máte všechny optimalizace, co vám udělá GCCčkový překladač Céčka. Složitost překladače tady prostě jde ruku v ruce s tím, co jazyk nabízí. A nabízí dost.

Nesrozumitelnost chybových hlášek jako součást unixové tradice je všeobecně známa, ovšem nechápu, proč akceptována.

[Martin Mareš]

Že na přečtení prototypu funkce je potřeba algoritmus, který má v Heroutově učebnici asi půl stránky nebo stránku, je dost děsivé.

To bohužel vypovídá hodně spíš o páně Heroutově učebnici než o jazyku samotném. Jména typů jsou v podstatě normální výrazy, až na to, že místo nad hodnotami operují nad typy. Takže se řídí téměř identickou gramatikou a není třeba popisovat je dalším složitým algoritmem.

[Ladicek]

On to je algoritmus pro člověka.

[Martin Mareš]

[...] srozumitelné chybové hlášky. V tomhle bodě je například GCC vyloženě v háji [...]

Například? (S rozumně novým gcc?)

[Martin Böhm]

Když se na to koukám z hlediska toho, co bych chtěl, aby se budoucí programátoři naučili, tak to bude určitě C. Přiznávám, jsem v okolí lidí milujících C (zdravím Twomiho). Co se mi však líbí, je to, že z většiny to jsou velice dobří programátoři. V Cé můžete nejen psát docela rozumně algoritmy, ale také máte jistotu, že Vám to kompilátor přeloží poměrně hezky. Občas mi příjde, že C a C++ jsou poslední rozumné (rozuměj: kompilované) jazyky. I když C++ má také své mouchy - objekty jsou hezké, ale třeba pohodlným streamům se doporučuji vyhnout, pokud chcete mít rychlé I/O.

A C#? Děs běs. Ano, čekám od oponentů kritiku, že interpretované jazyky a jejich JIT by mohly optimalizovat kód přímo na cílovou platformu a procesor, ale krutou pravdou je, že žádnou pořádnou optimalizaci nestihnou, neumí a ještě dlouho umět nebudou (ony totiž nejsou žádní magistři informatiky, pouze hloupé interpretery).

Ano, business hovoří jasně a vyžaduje čím dál rychlejší řešení. (Takže nás nakonec všechny vyhází a budou používat autogenerátory kódu, pokud to tak půjde dál.) Ale pokud jde o dobré programování a rychlé aplikace (hezký kód, atraktivní dívky, rychlé aplikace...sen každého muže), C má svůj neodolatelný půvab.

PS: Omlouvám se za svou nekoherenci, ale máme tu 00:45 (mimo tuto budovu je 01:45) a já začínám být unavený.

[____]

máte jistotu, že Vám to kompilátor přeloží poměrně hezky.

Zde optimismus končí tam, kde začíná multithreading. C nemá prakticky žádné prostředky, které by pomáhaly při vývoji threaded aplikací (a že to je dnes čím dále více nepřehlédnutelná oblast), naopak v této oblasti klade překážky.

Občas mi příjde, že C a C++ jsou poslední rozumné (rozuměj: kompilované) jazyky.

Zatímco já se obávám, že je to skutečně tak. Jako největší výhodu bych spíše než cokoliv jiného uvedl prostou všudypřítomnost těchto jazyků. Možná mohu vcelku souhlasit s tím, že v nich lze dobře psát algoritmy, ale právě s tím zbytkem aplikační logiky (a knihovnami) to už není tak růžové, pokud chce člověk věci dělat co možná nejvíce nativně bez podpory všech těch kompatibilitních vrstev typu Cygwin, pthreads-win32 apod. Jinak ani ony nejsou samospásné.

Ano, čekám od oponentů kritiku, že interpretované jazyky a jejich JIT by mohly optimalizovat kód přímo na cílovou platformu a procesor, ale krutou pravdou je, že žádnou pořádnou optimalizaci nestihnou, neumí a ještě dlouho umět nebudou (ony totiž nejsou žádní magistři informatiky, pouze hloupé interpretery).

Však ono se to dá i nechat zkompilovat rovnou, jen člověk, pokud to udělá, přijde o možnost ten program v totožné podobě spustit na více platformách. Osobně hodnotím C# i přes minimum svých zkušeností velmi kladně, sic je to v praxi jazyk na ještě vyšší úrovni než C++ a nedá se přímo srovnávat.

[Martin Böhm]

Pozor, následující řádky obsahují subjektivní názor, číst na vlastní nebezpečí.

Zde optimismus končí tam, kde začíná multithreading. C nemá prakticky žádné prostředky, které by pomáhaly při vývoji threaded aplikací (a že to je dnes čím dále více nepřehlédnutelná oblast), naopak v této oblasti klade překážky.

Spíš medializovaná než nepřehlédnutelná oblast. Asi se dožiju dne, kdy Linux na single core mašině nepůjde, ale zatím nevidím moc důvodů, proč by to mělo být zítra.

A nevím nevím, jestli paralelní aplikace v C# porazí pěknou jednovláknovku v C na výkon :o) Lidově řečeno, hezký způsob jak psát vlákna a vláknově-bezpečné aplikace by se šikl, ale nebudu kvůli tomu přesedlávat na ušmudlanou herku interpretovaných jazyků :o)

Zatímco já se obávám, že je to skutečně tak. Jako největší výhodu bych spíše než cokoliv jiného uvedl prostou všudypřítomnost těchto jazyků.

C# je populárnější - už u nás dokonce nahradil Pascal jako výukový jazyk, bohužel. Ono je to trochu analogické s tím, že omezují informatikům matematickou analýzu - ano, v programátorské práci to možná neuvidí, ale znalost analýzy je při uvažování nad problémy mnohdy velice užitečná. Zjednodušovat výuku mi příjde obecně spíš kontraproduktivní, a přechod na něco tak hodného jako C# je rozhodně zjednodušení programování. Používat pohodlné nástroje bych studentovi dovolil, až když ví, jakou cenu vlastně platí (a právě to by se měl naučit ve škole).

[AHAHA]

Vysokourovnove jazyky se umoznuji oprostit od v mnoha aplikacich nedulezitych veci a prejit k problemum vyssich radu (podobne jako tomu bylo kdysi u prechodu assembler => C)

[Martin Böhm]

Teoreticky asi ano. Já se držím pravidla - programátor (já) má právo přejít na jazyk vyšší úrovně právě tehdy když:

• Usnadní mu to práci.
• Překladač dokáže vygenerovat stejně (řekněme v rozmezí půlvteřiny, což Mono nedokáže ani omylem) efektivní kód, jako by napsal on v jazyce nižším.
• Rozumí, co přechodem výše ztratí.

O kterých problémech vlastně mluvíte? Já jen, abychom byli v obraze, já třeba většinu grafových algoritmů (má oblíbená oblast) implementuji právě v C/C++.

[AHAHA]

Na ciste algoritmicke (tedy hlavne vyukove) ulohy je C++ skoro idealni, protoze vas nuti implementovat vetsinu veci (pokud se vyhnete STL). Na realne problemy je ale casove proste zbytecne implementovat asymptoticky rychlou Fibonacciho haldu a klidne se spokojite s klasickou implementovanou ve standardni knihovne. Dostanete-li ukol implementovat program, ktery se spousti jednou denne, tak je uplne jedno, jestli bezi 1 sekundu nebo 10 sekund, ale mnohem vice prace vam da obhajit u zadavatele, ze jeho vyvoj byl dvakrat tak delsi a tedy i drazsi.

[Ladicek]

Teoreticky asi ano. Já se držím pravidla - programátor (já) má právo přejít na jazyk vyšší úrovně právě tehdy když:

Já bych to řekl právě opačně. Programátor má právo přejít na jazyk nižší úrovně právě tehdy, když dosáhne významně vyššího výkonu, a to ideálně při nejvyšším možném omezení objemu kódu v nižším jazyce.

Dotaženo do extrému by to znamenalo, že bychom všichni programovali v Lispu a svět by byl krásný , ale dá se takhle postupovat i pokud se omezíme jenom na mainstreamové jazyky.

Na těch grafových algoritmech ale něco je. Když jsem se nedávno prokopal Googlem k článku o "sea of nodes" SSA, implementovali to tam v C++. Ach jo

[JS]

No, ja se sice Lisp teprve ucim, ale mam za to, ze umi byt (po kompilaci) zbesile rychly. A neni ani na tak vysoke urovni, jak by se zdalo. Kdyz to srovnam s Pythonem, tak zakladni datove struktury Lispu jsou o uroven niz nez v Pythonu.

[podlesh]

Pokud je řeč o Common Lisp (a to pravděpodobně ano, když je řeč o kompilaci), tam tam rozhodně o úroveň níže nejsou.

[JS]

Ano, rec je o Common Lisp, a hadal bych se. V Pythonu nemate zakladni stavebni blok datovych struktur, cons cell, jako v Lispu. Pythonovske seznamy jsou chytrejsi nez Lispovske, protoze nepredpisuji, jaka bude jejich implementace, kdezto v Lispu je rada funkci zavisla na tom, ze jde o consy (v Pythonu to mimochodem nejsou bezne seznamy, ale seznamy poli - proto se v nich dobre implementuje napriklad slicing). O hashtable v Lispu toho moc nevim, takze je neumim porovnat s dictionary; na druhou stranu, Lisp nema mnoziny, ktere jsou pomerne dost uzitecne. Zkratka, jevi se mi to tak, ze (defaultni) datove struktury Common Lispu v mnohem predepisuji, jak maji byt implementovane. Tim jsou o uroven niz. A vubec si nemyslim, ze by tim Lisp byl nejak horsi, nez Python - vyssi struktury muzete snadno implementovat pomoci nizsich, a v Lispu je to jeste lehci diky makrum. Naopak Python vam dava rozumne defaulty, ktere mohou byt ovsem na radu aplikaci pomale.

Na druhou stranu, mozna se pletu, a rad se necham poucit. Tohle je moje dosavadni zkusenost.

[____]

Pozor, následující řádky obsahují subjektivní názor, číst na vlastní nebezpečí.

Trefnější by možná bylo napsat "nejsem další z těch, co ti/vám chce násilím vnutit svůj pohled na věc".

ale zatím nevidím moc důvodů, proč by to mělo být zítra.

Samozřejmě ani já ne. Nicméně se přišlo na to, že frekvence nelze stále zvedat, a nyní tu tak máme systémy se stále narůstajícím počtem jader CPU, ba dokonce přichází možnost jednoduše využít jádra z grafických karet. Je docela škoda nemoci využít plný potenciál počítače, hlavně pokud jde o aplikace výpočetně náročné. Paralelní program v C# může porazit jednovláknový pěkný program v C celkem klidně a s plnou suverenitou, záleží na dalších faktorech – třeba využití kompilace přímo do nativního kódu (bez JIT překladu).

už u nás dokonce nahradil Pascal jako výukový jazyk, bohužel

No vidíte, na Smíchově se zuby nehty drží Visual Basic verze 6, podle mě jste na tom velmi dobře. Co se týče toho, jestli vyučovat jazyky na nižší nebo vyšší úrovni, to není tak jednoduché dilema. Záleží na tom, na co a jak chce škola studenty připravit. Pokud to člověk myslí s programováním opravdu vážně, baví ho to a chce v tom být dobrý, stejně dospěje ke samostudiu nebo půjde na univerzitu, kde mu to nechají pořádně sežrat.

[Ladicek]

A nevím nevím, jestli paralelní aplikace v C# porazí pěknou jednovláknovku v C na výkon :o)

Na datově paralelních úlohách určitě Třeba ten známý raytracer v LINQu, to by mohlo běžet tak úžasně paralelně, až by se procesory zelenaly.

Jinak já nejsem proti vyučování Céčka na školách. Ten jazyk je sice strašný, ale je tu s námi a asi se ho ještě dlouho nezbavíme. Ale myslím si, že by se určitě nemělo Céčko učit jako první jazyk (zlatý Pascal) a taky ne poslední.

To dilema, jestli při vyučování programovacích jazyků postupovat shora dolů nebo zdola nahoru, jsem si ovšem ještě nevyřešil. Určitě záleží na cílové skupině: u lidí, jejichž práce primárně netkví v programování, ale programovat potřebují, bych šel určitě shora (a dolů bych se nejspíš vůbec nedostal).

[petr_p]

až by se procesory zelenaly

5000 K :)

[Martin Mareš]

A proč bychom si konkrétně měli vážit možnosti spustit zkompilovaný program na více platformách, oproti možnosti zkompilovat si ho pro každou platformu, jak nejefektivněji umíme?

[Martin Mareš]

Zde optimismus končí tam, kde začíná multithreading. C nemá prakticky žádné prostředky, které by pomáhaly při vývoji threaded aplikací (a že to je dnes čím dále více nepřehlédnutelná oblast), naopak v této oblasti klade překážky.

Smutná pravda je ta, že ostatní jazyky také nemají prostředky pro tvorbu efektivních MT aplikací, přičemž rychlost (využítí více procesorů najednou) je obvykle jediný rozumný důvod pro použití MT. Podpora pro MT v těchto jazycích se v podstatě omezuje na to, že si překladač domýšlí zámky okolo všeho, co by mohlo být nebezpečné, takže program pak tráví většinu času zamykáním nesmyslně jemnozrnných zámků.

Osobně vidím budoucnost paralelního programovaní spíš v jazycích, které mají přímo zabudované konstrukce pro paralelní zpracování dat (nikoliv jen pro automatické zamykání). Zajímavé pokusy na tomto poli jsou třeba Connection Machine LISP nebo (mírně zvrhlé, ale docela dobře fungující) OpenMP.

[pht]

Řekl bych, že Ada (opět) má paralelizmus a synchronizace vyřešené celkem dobře.

[pht]

PS. chtěl jsem ještě přidat, že v Perlu 6 se mi ad toto téma celkem pozdávají junctions.

[JS]

Sdilim tento sentiment. Na druhou stranu, jsem docela dost presvedceny, ze OOP neni konec sveta a ze nas cekaji jeste dost zasadni zmeny ve filozofii programovani (a ne, nejde o patterns, AOP, TDD nebo podobne modni trendy). Zatimco staticky typovane kompilovane jazyky (jako C nebo FORTRAN) byly posun paradigmatu, ktery mel potencial dosahnout vyssi efektivity nez assembler, Java a  C# takovym posunem nejsou, protoze jednak nejsou na dostatecne vyssi urovni (kde je mozna tak Python, ale ten problemy spis pridava nez ubira), aby bylo mozne je efektivne optimalizovat, a za druhe jim chybi tajna prisada (kterou je JIT jen castecne).

[Martin Böhm]

S tím souhlasím. Trochu čekám na podobného spasitele, jako byl Don Knuth s TeXem nebo Linus s Linuxem. Nějakého akademika vizionáře, který s tím zamává o hodně více, než .NET 3.0.

[Ladicek]

O půvabu bych byl ochoten mluvit možná v případě SPECSu, než tohle prohlásí za ISO standard, je pro mě Céčko nepoužitelné

[Martin Mareš]

No jo, jenže Ada je také jeden z nejukecanějších jazyků na světě, takže programy v ní jsou tak trochu jako romány od Jiráska, a to dneska málokoho baví

[Ladicek]

Ovšem, dnes je v módě málo psát, což je v pořádku, a ještě méně číst, což v pořádku není

Ale ty generické typy v Adě mi sice přišly trochu roztahané, ale na první pohled pochopitelné. To o šablonách v C++ říct nemůžu

[Martin Mareš]

Já také šablony v C++ vůbec nepovažuji za rozumnou alternativu. Spíš pokukuji po generikách v Haskellu nebo v Perlu6.

[pht]

To je proto, že pak ty programy čtou odborníci na jiné věci, než na šum na lince.

[pht]

A jaka je jeho nahrada? (systemove programovani, extremni prenositelnost)

Např. Ada.

[AHAHA]

Kolik existuje kompilatoru pro Adu a kolik pro C?

[pht]

Hodně.

[carray]

Je sice pravda, že se dá nahradit assembly, ale nevím jestli je to zrovna "necessary"...

[AHAHA]

Kanal se nekope uzickou a IRC bot se neprogramuje v Cecku. Muzes to sice udelat i tak, ale pak si nemuzes stezovat na nasledky sveho vyberu.

C je velmi dobre prenositelny jazyk uz prave proto, ze obsahuje jen velmi malou standardni knihovnu, kterou je snadne a mozne (!) implementovat prakticky kdekoliv.

[carray]

C je velmi prenositelny jazyk to je fakt, ale chybi mu nejaka dalsi prenositelna layer nad C SL implementujici napriklad jiz zminene vlakna ..

[AHAHA]

V C jsem vlakna moc nepouzival (a kdyz uz, tak me byla prenositelnost ukradena), ale docela se divim, ze zadny prenositelny layer neexistuje (byt vyssi urovne s urcitou rezii).

Pokud to myslite tak, ze ten layer existuje, ale neni soucasti standardu ... pak je to jina vec. Jsou procesory, ktere multitasking nezvladaji (nejake embedded zarizeni?), ale system, nad kterem by se nedal postavit C prekladac (i s knihovnou) by byla asi rarita (turing-neuplny).

[carray]

Myslel jsem uceleny layer. Ono existuje napriklad OpenMP, ktere se da aplikovat multiplatfomne ale jsou to porad jen vlakna...

[____]

Kanal se nekope uzickou a IRC bot se neprogramuje v Cecku.

...řekl bagr a spadl do potoka. Proč ne? Řeším při tom podobné problémy jako bych řešil u jiných typů aplikací.

C je velmi dobre prenositelny jazyk uz prave proto, ze obsahuje jen velmi malou standardni knihovnu, kterou je snadne a mozne (!) implementovat prakticky kdekoliv.

Přesně na to jsem čekal, že někdo napíše, abych psal striktně podle ANSI. Ale zkusil v tom někdo psát větší projekt? Už jen taková v dnešní době nevyhnutelná věc, jakou je multithreading, je neuvěřitelně problematická a každý projekt si to musí nějak řešit po svojem.

[AHAHA]

...řekl bagr a spadl do potoka. Proč ne? Řeším při tom podobné problémy jako bych řešil u jiných typů aplikací.

U jazyku vyssi urovne byste urcite nemusel tolikrat znovuvynalezat kolo (implementace fronty ve standardni knihovne C? kdeze ...) a nemel byste tolik problemu s neprenositelnymi API (treba Java a C# maji standardni i okenkove API).

Přesně na to jsem čekal, že někdo napíše, abych psal striktně podle ANSI. Ale zkusil v tom někdo psát větší projekt? Už jen taková v dnešní době nevyhnutelná věc, jakou je multithreading, je neuvěřitelně problematická a každý projekt si to musí nějak řešit po svojem.

Dyt to jsem nerekl :) Ja netvrdim, ze C je snadny jazyk (a proto jej nedoporucuji na psani programu, kde se jeho vyhody neprojevi), ale kdyz budete psat v ANSI C (tzn. C89), tak mate maximalne prenositelny kod, vic uz to nepujde.

[____]

To je pravda, avšak nechce se mi schválně vymýšlet další projekt, pro který bych mohl zvolit C, ani to přepisovat, když už jsem jednou ten jazyk zvolil (začal jsem to přerušovaně matlat asi před dvěma roky). Sice ty problémy přecházím často špatně, ale v podstatě mě to do jisté míry baví. Jen už budu velmi rozvážný, kdy budu chtít opět psát v tomto jazyce.

Dyt to jsem nerekl :) Ja netvrdim, ze C je snadny jazyk (a proto jej nedoporucuji na psani programu, kde se jeho vyhody neprojevi), ale kdyz budete psat v ANSI C (tzn. C89), tak mate maximalne prenositelny kod, vic uz to nepujde.

No, ale s tím toho moc dohromady nedám. K čemu je mi C ve své původní formě, když ho ve většině programů nemohu použít (případně by to znamenalo velmi neoptimální kód)? Jinak musím souhlasit až na

(a proto jej nedoporucuji na psani programu, kde se jeho vyhody neprojevi)

kde předpokládám, že jste nechtěně použil dvojitý zápor.

[AHAHA]

No, ale s tím toho moc dohromady nedám. K čemu je mi C ve své původní formě, když ho ve většině programů nemohu použít (případně by to znamenalo velmi neoptimální kód)? Jinak musím souhlasit až na

Furt rikam, ze proto na tento projekt Cecko moc vhodne neni :) Potrebujete sice portabilitu, ale ne znova tak extremni, jak C nabizi (SoC, 12345 operacnich systemu). Bude vam asi stacit prenositelnost mezi nejakymi 10 OS, ale za to pozadujete nejake vyssi rozhrani. A na to jsou jine jazyky (Java, Python ...).

kde předpokládám, že jste nechtěně použil dvojitý zápor.

Mne ta veta jinak nedava smysl. C ma sve vyhody (rychlost, pristup k systemovym zdrojum prip. extremni portabilita), ale tyto ve svem IRC botu nevyuzijete, naopak narazite na problemy, ktere u jinych jazyku nemusite potkat. Same minusy a zadne plusy (u tohoto typu projektu) a proto bych jej pro toto pouziti nedoporucil.

(Mozna to ale byla narazka na nejakou cestinarskou zalezitost ... :)

[____]

Furt rikam, ze proto na tento projekt Cecko moc vhodne neni :)

To pak znamená, že se C v početní většině používá na projekty, kde nemá příliš smysl či není vhodné... Zřejmě smutná realita. Naštěstí snad doba spěje k trendu, kdy jsou v módě především moderní objektově orientované jazyky a C upadá do ústraní.

Mne ta veta jinak nedava smysl.

Mně také ne, špatně jsem to přečetl (výhody/zápory). Blíží se noc :).

[AHAHA]

To pak znamená, že se C v početní většině používá na projekty, kde nemá příliš smysl či není vhodné... Zřejmě smutná realita. Naštěstí snad doba spěje k trendu, kdy jsou v módě především moderní objektově orientované jazyky a C upadá do ústraní.

Presne tak. IMHO je to jedna z velkych brzd napriklad v Gnome.

[lukve]

no ja viem programovat len v C a v C++ a to C viem lepsie... a písat aplikaciu v gtk je dost tazke.. ale paci sa mi myslienka Objective-C ktoru pouziva Mac alebo GNUstep ci etoile aj ked kod je dost roztahany ale zase su tam pluginy a moznost pouzivat smaltalk a jeho syntax

[Jardík]

"amongst" ... bože, to je asi taková novinka jako "thy"

[____]

Ani nevím, kde jsem to pochytil.

[rastos]

Especially the Microsoft libraries are hard to port code to, since you discover e.g. "secure" functions that are incompatible with POSIX reentrant/thread-safe variants and the compiler nearly doesn't support the C99 stardard.

Presne. Portabilita je v háji

[kozzi]

Tak je portabilni. Muzes pouzivat gcc snad vsude, takze v tom nevidim problem. Jiank assembler je prekladac ne jazyk . Jinak az na tu hyperbolu (neprijde mi to moc srozumitelne) mi to prijde docela anglicky . Jinak mám taky raději C++.

[Let_Me_Be]

+1

Nemluve o tom ze kazdy kdo ma trochu rozumu pouziva pod Win Intelacky kompilator.

[____]

Až na to, že je to čistě komerční produkt, zatímco Visual Studio je v Express edici zdarma. Ještě se dá použít MinGW (GCC port), ale jeho libc (původní msvcrt.dll pro Windows) je spíše něco jako pokus o vtip.

[____]

Muzes pouzivat gcc snad vsude

Již už ale ne glibc. Právě v knihovnách a rozhraních je zakopaný pes. Překladač většinou problémy tolik nepůsobí (ale když už, tak pořádné).

Jiank assembler je prekladac ne jazyk.

Aneb co bych si nerýpl, i když to všichni za každých okolností píšou špatně.

[Grunt]

Již už ale ne glibc. Právě v knihovnách a rozhraních je zakopaný pes. Překladač většinou problémy tolik nepůsobí (ale když už, tak pořádné).

Hele, nechci zase blbě rýpat, ale čí je to zase vina? Já bych řekl, že určitě ne jazyku.

[Grunt]

Zdá se mi to a nebo tady prostě obviňuješ jazyk z něčeho za co on sám nemůže?

[____]

Pravděpodobně se ti to zdá ;). No samozřejmě že samotné C (syntax atp.) v podstatě za nic nemůže. Nicméně myslím, že ho mohu se zcela klidným svědomím spojit s jeho standardní knihovnou, jež je také součástí standardu a tvoří spolu celek. A já nevím o žádných kvalitních alternativních univerzálních knihovnách pro tento jazyk.

 

[Grunt]

A já nevím o žádných kvalitních alternativních univerzálních knihovnách pro tento jazyk.

Eh? Glibc, uClibc, dietlibc, newlib, klibc - ani jedna nevyhovuje?

[Grunt]

A teď je tu jakási novinka.

[____]

Ne. Víte proč? Je to kompatibilní se standardní knihovnou C.

[Grunt]

To něčemu vadí?

[____]

Ano, napsal jsem alternativní.

[Grunt]

Abych pravdu řekl, tak o alternativní knihovně slyším poprvé. Mohl bych dostat nějaký příklad nějaké alternativní knihovny či alespoň malé vysvětlení oč jde?

[____]

Příklad vám dát nemohu, protože jsem žádnou takovou knihovnu, jakou hledám, zatím nenašel. Co má splňovat? Nesmí být navržena na základu standardní ANSI knihovny a musí zbourat tuto odpornou kompatibilitu. Tu totiž právě vidím jako silně problematickou. Důvody, proč zatím neexistuje, se bohužel nachází samy.

[Grunt]

Co má splňovat? Nesmí být navržena na základu standardní ANSI knihovny a musí zbourat tuto odpornou kompatibilitu.

A ta nenávist k ANSI C zase proč? Neříkám, že všechno v ní je navrženo zrovna geniálně, ale snad taková hrůza to zas není, ne? A nebo je v té normě opravdu něco co nejde překousnout? A o jaké kompatibilitě je řeč? Já mám totiž furt pocit, že problém leží někde jinde. A to soudím z:

Especially the Microsoft libraries are hard to port code to, since you discover e.g. "secure" functions that are incompatible with POSIX reentrant/thread-safe variants and the compiler nearly doesn't support the C99 stardard.

A nebo by už bylo vhodné říct konkrétně v čem je problém.

[____]

To není nenávist. Kdybych ji přímo nenáviděl, už bych se na psaní v C jistě vybodl a neučil bych se ji do čím dále tím více. Ta standardní knihovna je jen zastaralá a problematická a já tu prostě nevidím žádný revoluční pokrok. Nikde nic, jen evoluční změny, které působí často problémy. Nelíbí se mi to, chci vidět něco zcela nového. Toť vše.

Bohužel konkrétně se moc rozpovídat nemohu, nedělal jsem žádné velké rozbory toho, co všechno mi vlastně vadí (nebo může vadit), a co se s tím dá dělat. Nejsem ani moc zběhlý programátor v jazyce C. Napsal jsem blogpost, že se mi něco nelíbí, a snažím se odpovídat na reakce. Částečně proto, abych si přečetl názory druhých lidí. Momentálně už ztrácím duševní energii hájit svůj negativní postoj, takže si dávám pauzu :).

[Ladicek]

Slovo assembler se pro označení jazyka symbolických adres používá úplně běžně, jak ostatně všichni víme, takže ten pokus o rejpnutí je leda tak úsměvný

[kozzi]

jj vim, mam dokoce pocitze v cestine se jazyk primo oznacuje pojmem assembler. Ja do nej rejpl jen kvuli tomu ze to cele psal v Aj, tak mohl i toto

[AHAHA]

Spis je to oznaceni pro tridu jazyku.

[Miloslav Ponkrác]

Tak je portabilni. Muzes pouzivat gcc snad vsude, takze v tom nevidim problem.

Ani pokud bude používat gcc všude, tak portability nedosáhne. Protože už to, že na jedné platfromě je int 32 bitů, na jiné 64 už je překážka pro kompatibilitu. Kdyby chtěl snad někdo namítnout, že existuje třeba int32_t, tak jsem si ještě nevšiml, že by standardní knihovny C pracovaly s portabilními typy.

Jen nechápu, proč si někdo stěžuje na neportabilitu C, když to portabilní jazyk není a nikdy nebyl. C je pouze tak primitivní jazyk, že ho lze s určitým úsilím celkem snadno pro portabilitu použít, to je celé.

A také bych znovu apeloval, aby na serveru, kde se obvykle píše česky, se psalo česky. Zvláště exhibice v primitivní angličtině na úrovni slabikáře jako je tento článek bych zvážil.

[____]

A také bych znovu apeloval, aby na serveru, kde se obvykle píše česky, se psalo česky. Zvláště exhibice v primitivní angličtině na úrovni slabikáře jako je tento článek bych zvážil.

Zaprvé – toto nikdy nemělo být na úrovni článku. Toto měl být jednoduchý zápisek, čemuž může napovídat i fakt, že není v článcích ale v blozích. V perexu jsem ještě schválně kvůli tomu, že znám místní situaci, napsal, v jakém duchu se zápisek nese, včetně připomínky o tom, že je v angličtině. Dále i když hodnotím svoji angličtinu relativně špatně, rozhodně není na úrovni slabikáře. Omluvte mě, ale tohle zvládnou na prvním stupni základní školy, kamž slabikář patří, tak možná děti, které jsou s jazykem denodenně ve styku v rámci svého prostředí. Přivítejte úroveň angličtiny na současných českých středních průmyslových školách (a to jsem ten z těch lepších).

[Grunt]

A také bych znovu apeloval, aby na serveru, kde se obvykle píše česky, se psalo česky. Zvláště exhibice v primitivní angličtině na úrovni slabikáře jako je tento článek bych zvážil.

Na druhou stranu to Google Translate přeloží líp než většinu angličtinářem psaných anglických textů.

[Ladicek]

Do češtiny nebo do angličtiny?

[Miloslav Ponkrác]

Příště prosím napsat první odstavec, abych věděl, že tu někdo hodlá exhibovat v angličtině a abych na to zbytečně neklikal. Zase někdo ze sebe dělá světáka, když na český server píše v angličtině.

Za druhé je třeba si uvědomit, jak vzniknul jazyk C. Byl to NARYCHLO SPÍCHNUTÝ jazyk, který byl udělán pro přenos Unixu na jiný procesor. Posloužil tedy jako prostředek nahrazující nepřenostitelný assembler. Při jeho návrhu tedy je vyloučena jakákoli větší promyšlenost. Ohledně knihoven se jeho autor řídil především nenávistí k rozsáhlému jazyku PL/I, tedy hlavní koncepcí v knihovnách bylo mít co nejméně knihoven, pokud možno naprosto minimální počet funkcí. Spoustu práce při návrhu jazyka C bylo vlastně stejně převzato z jazyka B.

Později byly největší nedomyšlenosti jazyka trochu zakryty malými změnami k lepšímu při standardizaci ANSI verze C.

Vůbec počáteční historie Unixu byla řízena především nenávistí k něčemu a zejména složitým věcem. Výsledkem byly jednoduché, primitivní, s nadšením vytvořené věci. C jako opozice k rozsáhlému PL/I, Unix jako opozici k rozsáhlému Multics.

C není vůbec přenositelný jazyk. Nemá ani přenositelné typy, a ani přenositelnou knihovnu. Ale není zase tak moc práce (byť zase ne tak málo), aby šlo C použít pro přenositelné programy.

 

[____]

Příště prosím napsat první odstavec, abych věděl, že tu někdo hodlá exhibovat v angličtině a abych na to zbytečně neklikal.

Toto vůbec nechápu. Co jste tím myslel? Do perexu jsem schválně napsal, v jakém stylu se článek nese. A pak ho ještě přepsal do angličtiny (viz první comment).

 

Zase někdo ze sebe dělá světáka, když na český server píše v angličtině.

To je jen vaše domněnka, já ze sebe žádného světáka dělat nechtěl. Jen jsem se nudil, tak jsem to spravil tím, že jsem něco volně napsal na svůj blog. Jinak děkuji za věcný příspěvek.

[AHAHA]

Za druhé je třeba si uvědomit, jak vzniknul jazyk C. Byl to NARYCHLO SPÍCHNUTÝ jazyk, který byl udělán pro přenos Unixu na jiný procesor.

CPL => BCPL => B => C

Az zas tak narychlo spichnuty nebyl ...

Vůbec počáteční historie Unixu byla řízena především nenávistí k něčemu a zejména složitým věcem. Výsledkem byly jednoduché, primitivní, s nadšením vytvořené věci. C jako opozice k rozsáhlému PL/I, Unix jako opozici k rozsáhlému Multics.

Proc hned nenavist? Spis to pekne ilustruje vitezstvi jednoduchosti nad extremni komplexitou.

Nemá ani přenositelné typy, a ani přenositelnou knihovnu.

V cem je standardni knihovna C neprenositelna?

[Martin Mareš]

C není vůbec přenositelný jazyk. Nemá ani přenositelné typy, a ani přenositelnou knihovnu.

Velmi doporučuji přečíst si někdy aktuální normu Céčka, dozvíte se ledacos nového

[____]

Ono jde hlavně o: aktuální norma.