Já zas nechápu vás. Céčko je hnusný starý jazyk, který byl v době pármegaherzových procesorů vhodný k napsání jádra OS.
Taky nevím, co pořád máte všichni s tím Open Source? Každý nemá potřebu si dvakrát týdně překládat jádro OS. To, zda je k dispozici zdroják, není IMHO hlavní měřítko kvality produktu.
Asi si koleduju o flame war, ale o příspěvky bez rozumných argumentů zájem nemám.
A ještě něco: Flex _není_ Pascal! (Podobně Ada není Pascal! Stejně tak jako Java není Céčko!)
Linux [ http://en.wikipedia.org/wiki/Linux ], open source [ http://en.wikipedia.org/wiki/Open_source ] a free software [ http://en.wikipedia.org/wiki/Free_software ] bez tajemstvi. S tim ze free software je mysleno ve vyznamu free as in "Free Speech" (vzhledem k tomu ze se v tom titulku vyskytuje vedle pojmu open source je to snad jasne). CO konkretne nechapete?
Céčko bylo zastaralé už v okamžiku kdy ho K&R vymysleli. Kdyby jen trochu studovali literaturu, nemohli něco takového vypustit z klávesnice. To si jen tak udělali pár šikovných maker co jim zrovna assembler dovolil a prohlásili to za jazyk. Že několik let před tím dali Wijngaarden a spol. dohromady jazyk, ze kterého těží konstruktéři jazyků doteď jim asi uniklo.
TO je ta potiz. Hurd je dobre navrzeny system (z jisteho teoretickeho hlediska), ktery ovsem bohuzel velice spatne funguje (protoze ta teorie opominula nekolik "detailu").
Stejne tak spousta jazyku je "dobre" teoreticky navrzena, bohuzel se v nich prakticky neda moc programovat, na rozdil od C....
A proč ne, tam přece není žádný principiální problém. Spíš nechápu, proč je tak rozšířená myšlenka, že operační systém nejde naprogramovat v jiném jazyce než nějakém céčku. Pro vybrané technické detaily stejně budu muset použít vložený nebo přilinkovaný assembler ve Flexu stejně jako v céčku.
Pointer je naprosto trivialni zalezitost a co se tyce poli, tak C zadne nema - ma jen syntakticky cukr okolo pointeru, ktery za pole vydava. Podobne PHP nema pole, ale jenom hashove tabulky, ktere se za pole vydavaji. Myslim ze v C++ nejake pole uz maji, ale radeji pouziju C pointer, protoze delat kontrolu mezi jen tam kde je zapotrebi zrychluje program (a zpomaluje vyvoj ... nikdy bych netvrdil, ze C je idealni jazyk z hlediska rychlosti vyvoje).
Nejvetsi sranda je, ze kdyz jsem se ucil Pascal, pripadalo mi, ze pointery jsou neco magickeho. S Pascalem jsem si nejakou dobu hral. Pak jsem se dostal k Cecku a ucebnici od pana Herouta. Hned byl videt rozdil mezi akademiky a praktikem. Jak bylo najednou vsechno pochopitelne a snadne - prestoze C obsahuje pointerovou aritmetiku a spol.
Ale to je jedno, vysokourovnove jazyky prece pointery nepotrebuji...
Každý procedurální jazyk potřebuje pointery. Zjevné nebo více či méně zamaskované, ale pointer (nebo přesněji řečeno nepřímé adresování) je v téhle kategorii jazyků nenahraditelný. A když je náhodou nemá (Fortran, někdo ho tu zmiňoval) tak se to všelijak obchází třeba nepřímým indexováním polí.
Tak z teto odpovedi jsem vazne jelen. Az dotedka jsem slovem pointer oznacoval adresu na konkretniho mista v pameti, kterou ziskame napriklad zavolanim funkce typu *alloc. Takovou adresu podle me proceduralni jazyky nepotrebuji a pokud se pouziva nekde na urovni, ktera neni pristupna programatorovi v danem jazyce, tak se o pointerech nema smysl bavit.
Bohuzel, autori silne typovanych jazyku obvykle zapominaji na podstatnou vec, totiz ze kdyz necemu jazyk brani, musi poskytovat take prostredky, jak to realizovat v pripade, ze jde o zamer, tyto prostredky museji byt dostupne, standartizovane, efektivni, a dobre zdokumentovane.
Pascal treba dojel na to, ze blbosti jako konverze shortu na dva chary sla sice udelat v TurboPascalu, ale jinde ne, pripadne uplne jinak, a to ani kdybyste se stavel na hlavu. Naprosto priserne IO byla pak druha vec, proc jsem Cecko bral po Pascalu jako pozehnani..
A proc vyzadujete nizkourovnove vlastnosti po vysokourovnovem jazyku?
Podporuje vase cecko nejakou syntaxi cojavimtreba pro atomicky compare&exchange? Ne? Proc ne? Pri psani nizkourovnovych zalezitosti docela uzitecna vlastnost. Ze mam tohle napsat v assembleru nebo pomoci systemovych fci/knihoven? To mate teda pravdu!
A mmch, skladani dvou bajtu do shortu ve flexu delat muzete, kdyz vam to dela dobre. ;-)
1) Atomický compare and exchange IMHO nelze na všech architekturách rozumně implementovat takže do jazyka nepatří.
2) Zařazení -- || -- do jazyka nepřináší nic užitečného a proto patří do knihovny (resp. kvůli efektivitě je vhodné implementovat jako makro ale to je implementační detail).
BTW jak ve Flexu rozumně napsat toto:
#ifdef DEBUG
#define DbgPrint(Message) Print(Message);
#else
#define DbgPrint(Message)
#endif
Síla a genialita návrhu Cčka je v malém množství vhodně zvolených výrazových prostředků které ale umožňují implementovat vpodstatě cokoliv. Je sice vhodné pro lowlevel věci ale vcelku bez problémů umožňuje psát i highlevel věci (i když méně optimálně a člověk si musí hlídat více věcí - garbage collector se občas hodí :-). Problém vysokoúrovňových jazyků je v tom, že dost projektů má svoji lowlevel část a tam tem hl jazyk vysloveně překáží a nebo se tato část napíše v jiném jazyce ale mít projekt ve více jazycích je ehm nepraktické.
Mno chybi mi treba to, ze o tom nevim :o)
Zkousel jsem hledat v googlu, ale zminky o takove builtin funkci jsem nenasel. Je to tam uz dlouho, nebo je to neco pomerne noveho?
A taky je to gcc-specific (i kdyz pravda, gcc je vsude, takze to zas tak nevadi, ale do standardu C to dat mohli ... :o)
A precejen konstrukce typu "a ROL n" je prehlednejsi nez (a << n)|(a >> (32-n))
mno v C s makry asi tak max. rol(a,n) ....
Velky, nejvetsi asi ten ze to proste v C nemusi fungovat. Podle definice je short vetsi nebo roven charu a mensi nebo roven intu. Kdyz uz tak tam musis minimalne dat podminku na sizeof(short) >= 2 * sizeof(char) (pripadne jen na rovnost, protoze pokud to bude vic tak zbyly bajtiky budou nahodny). Proste C umi spoustu veci ale chce to o nem neco vedet :)
S charem ti nic neuniklo, ale protoze short <= int tak je mozne ze short == char. A pak priradit dva chary do jednoho shortu pujde docela tezko :)
A ten tvuj priklad moc nebude fungovat pokud c1 nebo c2 bude mit nstavenej horni bit, protoze pak se sign extenduje na short, coz ti udela docela bordel ve vysledku, musis ty hodnoty pretypovat na unsigned typy aby se ti nezvetsovaly se znaminkem, ale s nulama. U c1 to bude problem pokud je short vetsi nez 2 chary, u c2 to bude problem vzdycky kdyz bude short vetsi nez char.
Ano, samozrejme mas pravdu. Ja jsem predpokladal unsigned char jako uloziste pro 8 bitu dat bez dalsi interpretace, co ktery bit znamena, jestli se pouziva primy, inverzni a ja nevim jaky zpusob kodovani cisel atd. A protoze predpokladam, ze sizeof(short) >= 2, zadne dalsi zaludnosti jsem neresil.
Cecko zastarale?
to vravia vsetci co to C neovladaju.
moj nazor je, ze kritizovat moze clovek len to, co ovlada.
ja povazujem za zaklad programovacieho jazyka vyjadrit akukolvek moju myslienku. to, ze pod slovom akukolvek si K&R predstavovali akukolvek zverinu a oplzlosti (forek) ... to je ich problem. dolezite je, ze jazyk ma neobmedzuje.
ak sa autor jazyka snazi kompenzovat nedostatok vlastnej discipliny a strasidenlne priklady z knih povazuje za beznu prax v programovani, potom je to skor drevorubac ako programator.
priklad: citam v tlaci: je statisticky dokazane, ze najviac smrtelnych urazov sa stane na povedzme prednom sedadle spolujazdca.
hmm, tak prva genialna vec, akozto autora aut ma napadne, ze nebudem predne sedadlo montovat do svojich novych bezpecnych aut..
o rok prijde nova statistika ... o dva dalsia ...
oj oj ... a zrazu montujem auta bez sedadiel.
No vidite. A muj nazor zase je, ze tohle si casto mysli ti, kteri ovladaji _jenom_ C.
Ja v C programuju docela rad (z cehoz nevyplyva, ze to je muj nejoblibenejsi jazyk, kterym je mmch Delphi), nemam s tim zadny problem a myslim, ze na jistou skupinu aplikaci je proste nejvhodnejsi. Stejne tak je na jinou skupinu aplikaci vhodna Java, na jinou skupinu aplikaci vhodny cojavim Smalltalk atd. atd. A mam dojem, ze prave tohle uvazovani dela mnohym (ted nemam na mysli nikoho konkretne, natoz primo vas) ceckarum potize. Proste jazyku existuje mnoho, protoze kazdy je vhodny na trochu neco jineho. Co je na tom spatneho?
To, ze vam jazyk (ne)dovoli vsechno, je proste jedna z vlastnosti jazyka. Obecne ani dobra, ani spatna, jde o to, proc a nac to chcete.
Ad "dulezite je, ze me jazyk neomezuje": co tim chcete rict? Jakto ze vas neomezuje? Vy snad muzete napsat treba
"abc" 123 . : cecko je super jazyk? tralala.
? Dobre, tak o neco mene extremni priklad, co treba
char *s = 3.4;
Taky ne? Jaktoze vas omezuje? To je prece spatne! Anebo ne? Ze by slo o miru omezovani? A kde je ta posvatna hranice?
A jeste zaverecna k tomu prirovnani: vite o tom, ze se do mnohych aut montuje omezovac rychlosti? Proc to delaji? Je prece dulezite, aby me auto neomezovalo.
S prvnim odstavcem souhlasim. Na neco je vhodne C, na neco PHP, na neco C++, na neco bash+awk+sed. Mozna ze casem narazim i na problem ktery me presvedci naucit se jiny jazyk, protoze jazyky ktere znam pro nej nebudou vhodne.
Jazyk neomezuje = v jazyce jde zapsat libovolny algoritmus. To je ta posvatna hranice. V praxi se hodi i kdyz muzete napsat libovolny algoritmus aniz by vas jazyk nutil delat konstrukce pripominajici drbani se levou rukou za pravym uchem.
Vite ze s montovanim omezovacu rychlosti do autobusu se prestalo, kdyz se zjistilo, ze vynucene omezeni rychlosti prinasi vyssi nehodovost ?
Mno tak ty omezovace rychlosti v autech ... montuji se treba do Mercedesu, ale tam jsou nastaveny na 250 Km/h, coz zas tak moc neomezuje (mozna nejaky dalnicni silence ....) a u ostatnich aut to bude mozna podobne - vykon motoru mercedesu by asi dokazal vymacknout u silnejsich motoru vic nez tech 250, ale uz by tu rychlost nezvladlo treba rizeni, pneumatiky, nebo ja nevim co ... tak je tam ten omezovac.
Libovolny algoritmus? Takze vam staci treba Turing-complete jazyk? V tom pripade doporucuju treba Brainfuck. (http://www.muppetlabs.com/~breadbox/bf/) :o)
Ve Flexu samozrejme muzete zapsat stejne algoritmy jako v jakemkoli jinem normalnim imperativnim jazyce, jenom je nekdy zapisujete o malinkaty chloupecek jinak. O zadne zasadni omezovani se samozrejme nejedna. To, _jak_ je tam zapisete, a jestli se vam ten styl libi, je samozrejme veci vkusu a tezko se tady muzeme shodnout na objektivni pravde.
Víte co se stalo se sondou Mars Polar Lander? Jeden programátor (asi žádný vypatlanec, když směl dělat pro Boeing) napsal obslužnou rutinu pro výškoměr, která vracela údaj ve stopách. Jiný z NASA ji volal, ale myslel si, že to dostává v metrech. Není to žádný vymyšlený příklad, přes všechny testy se to fakt stalo a NASA přišla tuším o 120 mil. dolarů. Kdyby to nepsali v C++ ale v Adě, "omezující" jazyk by jim nikdy nedovolil přiřadit metry do stop a na chybu by přišli a opravili ji během vteřiny, ani by je nenapadlo, že mohla být fatální.
Stopa je (celo)číselný datový typ. Metr je (celo)číselný datový typ. Ty dva typy spolu nejsou kompatibilní a aby bylo možné uložit hodnotu jednoho typu do proměnné druhého typu, je nutné provést přetypování. Není-li provedeno (což je v případě stop a metrů více než pravděpodobné), překladač hlásí chybu a odmítne program přeložit. V silně typovém jazyce, pochopitelně. Tedy třeba v Adě nebo ve Flexu.
Ty typy je samozřejmě nutno deklarovat, samy od sebe neexistují. Tedy ve většině jazyků, v níže zmíněném Rebolu možná ano :)
Když programujete v jazyce se silnou typovou kontrolou, narážíte na ně naopak všude. Deklarovat proměnnou dejme tomu jako "holý" int se tam považuje za nečisté programování. Vždycky by měla mít nějaký typ, aby za vás mohl překladač hlídat, jestli ji omylem někde nepoužíváte špatně. Viz ten příklad s družicí, co otevřela padák místo v 1000 metrech v 1000 stopách.
Jenze ty udaje se zpravidla musi CIST z cidel - a tam je naprosto suma fuk jaky mate jazyk, protoze to musite precist znacne nizkourovnove zpravidla po sbernici (a muzete byt rad pokud to budete mit pararelne, protoze seriovy v techto extremich podminkach je sice narocnejsi a pomaly, ale na druhou stranu vice odolny)... Vite, Vas prikald byl hezky, ja mohu dokumentovat uz od Fortranu (spaleni druzic), nic to vsak emeni na tom, ze na Zemi skoro nikdo nema predstavu o jakem programovani se vubec mluvi, jake jsou prostredky a co to obnasi... - zapomente proboha na dnesni CPU, mega ci spise giga pameti... - mate malinky clanek, ktery nelze moc zatizit, malo pameti a jeste vse musite kontrolovat alespon dva a z trikrat, protoze se Vam to muze menit pod rukama (ano mluvim o atomicite a o integrite)
a) Muzes mi rict co te vede k zaveru ze ten kdo kritizuje C, tak ho neovlada ? Nepochopitelna ceckarska namyslenost, ale velmi typicka.
b) Proc neprogramujes v assembleru ? Vzdyt to cecko je vlastne strasne nepruhledne, dela si co chce a nemuzes v nem vsechno ridit !
c) Vis ze i ten Pascal umi snad vsechny low level zalezitosti co cecko ? Ada. Flex. .....
d) Zakladem prg jazyka je schopnost vyjadrit jakoukoliv myslenku ? Je snad schopnost (dokonce nutnost) prasit primo pamet vyjadrovani nejake myslenky ? Naopak, ve vyjadrovani pokrocilejsich myslenek maji nad nejakym ceckem samozrejme navrch vyssi prg jazyky, ale o tom ty asi moc nevis.
:-)) Nechtel jsem se do tohoto flame poustet, ale tady jste presne vystihl ten problem.
Ccko je skotecne ze softwerove-inzenyrskeho hlediska hrozne, jenze v praxi se v nem da dobre a efektivne psat (no priznavam, ze nektera pouziti jsou masochismus).
Vas jazyk mozna te softwerove-inzenyrske literature vyhovuje, jenze nejste prvni, kdo se o neco takoveho pokousi. Jedno proste nezmenite, programator musi programovat umet a zadny seberobustnejsi jazyk na tom nic nezmeni.
Proc jste nevzali nejaky uz existujici jazyk (ja mam nejradeji Python)? Protoze kazdy z nich ma sve nedostatky? Copak si myslite, ze ten vas nema?
Jo a abych nezapomel, cely Linux ma taky uplne hrozny design ;-) A vlada je uplne blba. Vlastne cely svet nejak spatny design. Kdyby si Buh nedriv poradne precet literaturu...