Vlákno názorů k článku Začněte s Céčkem v Linuxu od Transcendent - Pánové, v roce 2006 už byste se na...
-
Transcendent (neregistrovaný)Pánové, v roce 2006 už byste se na to Céčko měli fakt vysrat. Kromě psaní driverů apod. nemá smysl se céčkem dále zabývat. A už vůbec ne cpát do další generace imperativní jazyk na úrovni assembleru...
....
Probuďte se! Do kdy chcete stahovat další a další aktualizace, které pořád dokola opravují buffer overflow a ostatní pitomosti?
....
Proč? Proč? Proč?
Viděli jste někdy Huskell? Prolog?
....
Nebo aby to bylo pěkné - Smalltalk?
....
Třikrát fuj céčku!
....
P.S. K céčku už bych se vrátil pouze v případě, že bych si chtěl přeprogramovat vysavač!
...For Gods Sake!... -
Biktop (neregistrovaný)Smalltalk je pěkný objektový jazyk, C++ je proti tomu dětská koloběžka, to je fakt. Ale porovnávat Smalltalk s C...
C je velmi jednoduchý jazyk, na nějž lze rychle udělat poměrně jednoduchý kompilátor, přičemž výsledný kód zůstává velmi efektivní a zdrojový text dobře přenositelný. V podstatě je to "univerzální algebraický assembler". V tomto ohledu je role C dodnes nenahraditelná. Nepočítám-li věci jako PL/1 (používá to ještě někdo? :-) -
Transcendent :-p (neregistrovaný)I když v titulku článku stojí "Programovali jste v jiném operačním systému a teď chcete začít programovat pod Linuxem?", a nezdá se mi tedy, že by se v článku jednalo o psaní operačního systému, odpovím:
1) Většina lidí, kteří programují (programovali) v jazyce C, NEPÍŠE operační systémy, zato píše aplikace, ke kterým je potřeba neustále stahovat aktualizace opravující buffer overflow atd.. (tj. například já je musím neustále stahovat, což mě příšerně obtěžuje)
2) Pokud vím, tak např. Mac OS je napsán v Object C, což je ale jiná káva než Céčko! :-)
3) Napsat operační systém v některém z vyšších programovacích jazyků je naprosto zřejmě možné a nanejvýš vhodné (verifikace správnosti atd).
Málo čtete, nebo málo hledáte, zkuste například http://www.cse.ogi.edu/~hallgren/House/, doporučuji zejména odkaz http://www.cse.ogi.edu/~hallgren/ICFP2005/,
"...The interface has been implemented on bare IA32 hardware using the Glasgow Haskell Compiler (GHC) runtime system. We show how a variety of simple O/S kernels can be constructed on top of the interface, including a simple separation kernel and a demonstration system in which the kernel, window system, and all device drivers are written in Haskell..."
... a variety ...
4) Mohli bychom se dále bavit o mém názoru, že používání primitivních imperativních jazyků, jako je Céčko, koreluje s tím, že dnešní procesory jsou stále jen Turbokalkulačky (čím dál rychlejší, samozřejmě), které z hlediska algoritmizace podporují jedinou vyšší abstrakci - zásobník. Aspoň rekurzi že máme, zaplať Bůh!
Samozřejmě je to jen můj názor, že imperativní programování (takový ten assembler ala céčko) svedlo na scestí celou informatiku, a pozdrželo její vývoj o 30 let, nicméně takový Smalltalk, stále nedoceněný, nabízí již od roku 72 (80?) prostředky pro čisté, objektové programování - navíc v něm nevzniká nic jako segmentation fault..
5) Když vidím kód jako:
nova_funkce() {
char *a;
a=(char *) malloc(1);
a=500; /* Hrubá chyba! */
*a='!'; free((void *) a);
}
Říkám si jenom: Že to céčkaře pořád baví... Ty hvězdičky a šipečky ... :-D
Asi mají více času než já a budou tu na rozdíl ode me aspoň 300 let...
6) Zvídavým bych ještě doporučil například Singularity, http://research.microsoft.com/os/singularity/, moc hezká věc od výrobce _nejlepšího_ _současného_ _operačního_ _systému_ _na_ _světě_ :-p.
Tak jak je popsáno na uvedených stránkách, by měl vypadat operační systém, a ne jako céčkové šílenství ala linux nebo nakonec i ty současné windowsy - tímto směrem se asi bude ubírat vývoj, a to pro Céčko, ani pro céčkaře není dobré znamení :-D
7) Uff to bylo ale dlouhý... -
Biktop (neregistrovaný)Já souhlasím a plně se podepisuji jen pod jedno - že Smalltalk je neprávem stále nedoceněný jazyk. To je fakt a je velká škoda, že tento skvělý objektový jazyk není minimálně tak rozšířený, jako Java. Už jsem tu kdysi na toto téma diskutoval.
Ovšem C se Smalltalkem prostě nahradit nedá. Je to prostředek jiné třídy.
Jak by měl vypadat operační systém, o tom už bylo napsáno spousta článků a knih. Pokud jde o mě, jsem toho názoru, že především musí být malý a efektivní. Pokud je to možné, použít Assembler (drobné OS pro embedded aplikace), jinak C, které pokryje obrovskou škálu možných nasazení. Pokud C přestává stačit, je samozřejmě na místě debata o použití jiného prostředku, ovšem vyvstává jiná otázka, totiž, zda realizovaná koncepce OS je správná, vyžaduje-li použití takových prostředků. Znovu však opakuji, že na 1. místě musí stát efektivita výsledného kódu a jeho minimální rozměry.
Objective C je skutečně něco jiného než C++, ale nechápu proč stále srovnáváte objektové a neobjektové jazyky. 1) Když už bych se chtěl vyvarovat C++ a přesto použít OOP, sáhl bych bez váhání nejspíše po Smalltalku, 2) výsledný kód OOP programu je PROKAZATELNĚ méně efektivní, než kód přeložený z neobjektového prostředí. Je to zkrátka daň za programátorovo pohodlí.
Jestli tvrdíte, že C zdrželo vývoj o 30 let, pak jsem tedy za těch 30 let vděčný, jinak bychom tu už dávno měli neefektivní monstra napsaná s využitím OOP.
A ještě jedno rýpnutí - bývá módou říkat, že programovat v Assembleru je dnes naprostý anachronismus a že optimalizovaný kód generovaný překladačem je efektivnější, než ručně psaný. K tomu dodávám, že to může říct jen člověk, který Assembler v životě doopravdy nezvládl! Zkrátka využijme toho, že si můžeme vybrat jazyk, který se nám nejvíce hodí. Není důvod jakýkoliv z programovacích jazyků zavrhovat. Univerzální programovací jazyk totiž neexistuje. -
Transcendent XY (neregistrovaný)Smalltalk je super, to je fakt!
Dále se musím opravit - u Mac OS nejde o "Object C", ale o "Objective C". Jak píší na wikipedii,
"Objective-C, often referred to as ObjC or more seldom as Objective C or Obj-C, is a reflective, object oriented programming language which adds Smalltalk-style messaging to C."
Zdá se tedy, že Smalltalk přece jen ovlivnil něco k lepšímu.
Tvrdíte, že srovnávám objektové a neobjektové jazyky, to ale není přesné - když už, tak srovnávám jazyky imperativní a deklarativní a dále rozděluji jazyky na ty, které mi umožňují zapsat myšlenku (algoritmus) jednoduše, ve kterých se můžu vyjadřovat k věci a specifikovat vše alespoň trochu na takové úrovni, na jaké probíhá mé myšlení, a na ty ostatní... (probíhat mentálně po hvězdičkách a šipečkách v céčku nemá pro mě nic společného s myšlenkou, kterou chci zapsat)
Zajímalo by mě, jak přesně byste vyjádřil to zpomalení u objektových jazyků (které jsou také imperativní:).
Trošku obecněji k tomu srovnávání - např. když se srovnává C++ a Java, lidé říkají - Java je 30x pomalejší... To je ale přece úplně putna! (Nebavme se o tom, že ani toto tvrzení není správné, zkompilovaný kód v Javě spustíme na novém virtuálním stroji na novém typu procesoru, a rázem je, bez kompilace samozřejmě, 30x rychlejší, než zkompilovaný kód v céčku) Jde o stejnou složitostní třídu (rychlost se liší o konstantu krát), takže pokud se mi nelíbí, že můj podnik zpracovává data 30x pomaleji, než mi někdo řekl, že by to šlo, koupím 30 strojů a jedu dál! Stále jsou porovnávány nevhodné parametry - započítáváte do rychlosti programů v céčku všechny ty nešvary, které jsou v céčku produkovány?
Divím se vám, že jste za těch 30 let zdržení vděčný, protože mě můj počítač co chvíli rozčílí - nic neumí - je úplně hloupý - ničemu nerozumí - neumí ani katalogizovat moje data - neumí se mi přizpůsobit - musím se mu neustále přizpůsobovat já.
Možná jsme dnes mohli být už úplně jinde, např. zpracování řeči - pokud by se úsilí věnované grafickým akcelerátorům, věnovalo kartám na zpracování řeči, mohli jsme už dávno s počítačem mluvit, což by nebylo k zahození..
Stejně tak pokud by se úsilí směřovalo k něčemu jinému, než je rychlost, mohla tu být třeba nějaká ta inteligence..
V assembleru jsem programoval 10 let, takže celkem vím, o co jde, ale tvrdit, že dnes napíšete slušný kód ručně je opravdu naivní - viděl jste např. architekturu VLIW procesorů? To už by se mi dnes také nechtělo.
Jinak se samozřejmě nikdo nezlobte, že si rýpnu do céčka, prostě jak píšu výše, můj počítač je hloupý, a já myslím, že to souvisí s tím céčkem.... </neberte to tak vážně :-)
Možná jsem nepochopil, že tady všichni chtějí programovat vlastní operační systém. Pokud je to tak, hodně zdaru! (Já jsem si chtěl kdysi taky jeden napsat, v assembleru, ale nemělo to smysl, tak jsem dělal něco užitečnějšího).
Zatím se mějte, pěkná debata!
P.S. Mrzí mě, že jste se nikdo nevyjádřili k Singularity, tak rád bych si trochu zdrbnul, a vy pořád o céčku :-) -
disorder (neregistrovaný)aha, cize keby sa 30 rokov (ci kolko) programovalo v niecom inom nez C, tak by sme mali rychlejsie procesory? asi ano, keby uz vedeli v real-time rozmyslat a rozpravat, ach jaj...
> zkompilovaný kód v Javě spustíme na novém virtuálním stroji na novém typu procesoru,
> a rázem je, bez kompilace samozřejmě, 30x rychlejší, než zkompilovaný kód v céčku
ale ten kod nie je rychlejsi, len je rychlejsie vykonavany. toto sa da vyuzit az pri procesoroch kde je rezia takych programov naozaj zanedbatelna, pretoze skompilovany C program bude zase rychlejsi - a cas su peniaze... -
Transcendent (neregistrovaný)Ano, rozumíte tomu (skoro) správně, měli bychom procesory, které by hardwarově podporovaly vyšší programovací jazyky (představte si procesory, které zpracovávají nativně java-bajtkód. Dokonce to i existovalo - jmenovalo se to myslím pico. Samozřejmě nejde pouze o nativní procesory pro javu - jde o podporu vyšší abstrakce přímo v hardwaru).
Pak by bylo přirozené programovat v těchto (vyšších) jazycích, kde se nepopiratelně člověk může soustředit na problém samotný, a ne na ošetřování indexace polí a všechny ty nepříjemnosti, se kterými se potýká v céčku.
Následně by se tedy úsilí programátorstva mohlo ubírat jiným směrem, než hledáním cesty, jak nezpůsobit buffer overflow. Software by byl verifikovatelnější, tudíž spolehlivější. Výhody jasné :-)
BTW - opravdu mě fascinuje, že si, zdá se, nikdo nepřečetl něco z odkazu na Singularity... Škoda, že každý reaguje jen na něco, vypadá to, že se ty příspěvky snad ani nečtou celé... Ušetřil bych si spoustu psaní ohledně výhod/nevýhod různých technologií pro různé účely.
Ad rychleji vykonaný kód - prosím, co je to rychleji vykonaný kód, který není rychlejší? To porovnání kódu javy s kódem céčka - šlo o to, ukázat, že rychlost (jako absolutní číslo) není prostě to nejdůležitější, nevykopíraval jste to celé, byl to příměr. Bavíme-li se o celém průmyslu - započítejme i čas vývoje, čas oprav, atd.
Navíc c bude, dejme tomu na architektuře Intel (to je podstatné pro váš příspěvek), zase rychlejší, a zase hloupější..
Jde o rozdíl mezi kvalitou a kvantitou.
Ano, můj pohled je trochu "idealistický", to ale neznamená, že nereálný. Už teď se dají sehnat práce v neimperativních jazycích a vesměs jsou to zajímavé věcičky :-)
Zdravím všechny céčkaře!!! -
disorder (neregistrovaný)hardwarovo by podporovali vyssie jazyky. ano to ma napadlo, ale taky procesor by nevedel vykonat viac "obycajnych" instrukcii nez tie dnesne. alebo sa mylim?
> Pak by bylo přirozené programovat v těchto (vyšších) jazycích, kde se nepopiratelně člověk může soustředit
> na problém samotný, a ne na ošetřování indexace polí a všechny ty nepříjemnosti, se kterými se potýká v céčku.
nie som ziaden superclovek, alebo co, ale nerobi mi problem sustredit sa v C na riesenie. cize to popieram a tvrdim ze pre MNA nie je indexacia a adresacia neprijemnost. ved v podstate je to velmi primitivne, mala nasobilka :) samozrejme netvrdim, ze na vsetko je to najvyhodnejsie - napr. ked su potrebne asociatinvne polia.
vyssie jazyky? mam pocit, ze mate na mysli hlavne OP. tak napr.:
http://www.catb.org/~esr/writings/taoup/html/unix_and_oo.html
je tam pekne napisane, preco OP nie je samospasitelne.
> prosím, co je to rychleji vykonaný kód, který není rychlejší?
to je ako 2 algoritmy - minsort a quicksort. kod quick sortu je rychlejsi. ale argumentujete tym, ze na ovela rychlejsom procesore by bol minsort rychlejsi nez quicksort na povodnom, ale bol by len rychlejsie vykonavany...
> Navíc c bude, dejme tomu na architektuře Intel (to je podstatné pro váš příspěvek), zase rychlejší, a zase
> hloupější..
to je strasne zla formulacia. ako moze byt hlupejsi? moze byt rovnako hlupy, pretoze je to stale ten isty jazyk. na nejakej architekture bytecodu nebude rychlejsi, to je pravda. pretoze ak by sa do bytecode skompiloval, vyhoda optimalizacie by prestala existovat. ale o tejto idei mozete IMHO snivat naveky. jedina moznost je taky narast vykonu procesorov, ze by bol rozdiel zanedbatelny. -
Transcendent (neregistrovaný)>>hardwarovo by podporovali vyssie jazyky. ano to ma napadlo, ale taky procesor by nevedel vykonat viac "obycajnych" instrukcii nez tie dnesne. alebo sa mylim?
Nevím, jestli říct, že se mýlíte, jde zkrátka o to, co jsou to "obyčejné" instrukce (a nejen instrukce - dovedu si představit například hardwarový garbage collector, proč ne).
Řekněme na současným turbokalkulačkách typu intel je obyčejná instrukce add, sub, mul a div.
Na vektorových procesorech to vše jde dělat nejen se skaláry, ale také s vektory. Proto jsou vektorové procesory lepší na zpracování problémů, ve kterých bude řeč o vektorech.
To je ale jen určitá specializace, čím se dosahuje lepších výkonů. (Mimochodem MMX instrukce jsou vlastně takové malé vektorové instrukce, nepletu se? - také byly přidány později).
Když půjdeme opačným směrem, můžeme abstrahovat až k představě, že hardware počítače má paměť, která si pamatuje jednotlivé datové typy (třebas nějak velmi jednoduše:). Dále má správu ochrany paměti, která ohlídá, kdo k čemu přistupuje, a nakonec třeba i ten garbage collector.
Jaké druhy chyb se na takovém stroji budou u programů vyskytovat?
Resp. jaké druhy chyb bude muset programátor v jazyce přiměřeném této architektuře ošetřovat?
Bude se ve srovnání s jazykem c na architektuře intel muset více, nebo méně zabývat implementačními detaily?
Pokud se bude méně zabývat impl. detaily, na co mu zbude čas?
No je to trochu utopistické, proč ale ne?
>...nie je indexacia a adresacia neprijemnost. ved v podstate je to velmi primitivne, mala nasobilka :)
To máte pravdu, pro mě to taky není zase takový problém, proč ale co týden stahuji aktualizaci typu: V aplikaci Firefox bylo zjištěno slabé místo: speciálně upravenou adresou může útočník... blabla
>..vyssie jazyky? mam pocit, ze mate na mysli hlavne OP.
Tak to tedy nemám, resp. považuji je za menší zlo, než céčko, ale mluvím spíš o Huskellu nebo Prologu. Ty jsou tedy bohužel zatím asi příliš daleko od mainstreamu.
>..to je ako 2 algoritmy - minsort a quicksort...
Tady to neříkáte přesně. Proč je kód v javě pomalejší než kód v céčku? Protože céčko je blíž hardwaru než java. Pokud ale vezmete quicksort v javě na javovém procesoru a v quicksort v c na "céčkovém" procesoru, taktováno přibližně stejně, budou stejně rychlé, to je dokázané! Algoritmus je prostě stejný.
V příměru s 30 počítači jsem se snažil naznačit, že hrubý výkon je nicneříkající ukazatel, resp. že u softwaru jsou i jiná kriteria než rychlost, například spolehlivost (víte asi o těch raketách, které vybuchly kvůli softwaru, nebo o pendolinu atd.).
Dalším kritériem je cena vývoje, cena údržby atd.
Pokud se vysloveně nebavíme o realtime věcech, nízkoúrovňovém softwaru typu ovladač nebo program na obsluhu lisu či co, tak všude jinde všechno mluví proti céčku!
Schválně, až se podle tohoto seriálu bezvadně naučíte céčko, zkuste si sehnat práci - neříkám že neexistuje, a modlete se , aby nespočívala v přepsání něčeho většího v céčku, co psali chlapci před vámi. Nejlépe nedokumentovaného...
>...to je strasne zla formulacia...
No je to moje formulace - samozřejmě, že bude pořád stejně hloupý, a ne hloupější. Ale pořad bude hloupější než ty vyšší jazyky, podle mně..
>...jedina moznost je taky narast vykonu procesorov, ze by bol rozdiel zanedbatelny.
V tom nevidím velký problém. Moorův zákon říká něco jako: Každých 18 měsíců se výkon zdvojnásobí. Čili 32=2^5. 5*18 měsíců = 90. 90/12 = 8. Za 8 let budou 32 kráte rychlejší procesory.
Samozřejmě vše brát s rezervou, ale třeba to bude takhle: Nebudou 32 krát rychlejší, ale jenom 10 krát, zato budou kvalitnější, bezpečnější a budou podporovat pokročilejší featury než dneska..
Ty featury budou lépe využívány jinými jazyky...
8 let není zase taková doba, abych si mezitím piloval céčko kvůli tomu, že je dnes (ale klidně i zítra) o trochu rychlejší. -
disorder (neregistrovaný)> Řekněme na současným turbokalkulačkách typu intel je obyčejná instrukce add, sub, mul a div.
no, este tie sa skladaju z nejakeho mikrokodu, a tie vase by boli vykonavane tiez takto. ale neviem, ci by bytecode mohol byt optimalizovany hardwarovo tak dobre ako sucasne instrukcie.
> No je to trochu utopistické, proč ale ne?
ano, presne to - utopia. ale v technickych odboroch je vselico mozne, takze niekdy sa to moze naplnit.
> Huskellu nebo Prologu
ano, nieco som o tom uz zacul. funkcionalne programovanie?
ale zoberme si, ze by sa stala nejaka revolucia, aky procesor by sa vyrobil? vedel by len 1 bytecode a na scene je tolko moznosti. takyto prevrad v HW IMHO nie je mozny. a navyse existuje mnozstvo SW, ktory by musel byt nahradeny a prepisany.
> Proč je kód v javě pomalejší než kód v céčku? Protože céčko je blíž hardwaru než java. Pokud ale vezmete
> quicksort v javě na javovém procesoru a v quicksort v c na "céčkovém" procesoru
cecko je blizsie HW preto, ze pouziva jednoduchsie instrukcie,vysledny kod kompilator optimalizuje a navyse vykonavanie je optimalizovane procesorom. je naozaj zaujimave, ze java procesor by to vykonal rovnako rychlo, len to IMHO postrada logiku. ale ja nie som odbornik a ked je to dokazane, tak to bude pravda.
> Pokud se vysloveně nebavíme o realtime věcech, nízkoúrovňovém softwaru typu ovladač nebo program na obsluhu
> lisu či co, tak všude jinde všechno mluví proti céčku!
v inom prispevku spominam, ze na kniznice je velmi vhodny - pouzitelne s inymi jazykmi, optimalizovane a ich obsah nahraditelny inou kompatibilnou kniznicou.
> abych si mezitím piloval céčko
C je tak jednoduchy jazyk, ze sa staci raz naucit zakladne spravne navyky. neplati len pre C, ale celkovo pre proceduralne programovanie. -
Transcendent (neregistrovaný)>ci by bytecode mohol byt optimalizovany hardwarovo tak dobre ako sucasne instrukcie.
Proč ne?
>ano, presne to - utopia.
Zase tak velká utopie to není. Donekonečna nelze pouze zvyšovat taktovací frekvenci. Jakým směrem se podle vás bude ubírat vývoj procesorů?
> Huskellu nebo Prologu
Haskell je funkcionální, Prolog logický.
> cecko je blizsie HW preto, ze pouziva jednoduchsie instrukcie...
Céčko je vylepšený assembler, proboha nemá to ani stringy... o seznamech nebo jiných stukturách si můžeme nechat zdát. Doporučuji opravdu se seznámit s jinými programovacími paradigmaty, než je imperativní..
> v inom prispevku spominam, ze na kniznice je velmi vhodny - pouzitelne s inymi jazykmi, optimalizovane a ich obsah nahraditelny inou kompatibilnou kniznicou.
Knihovny jdou přece vytvářet ve všech dnešních jazycích...
> vedel by len 1 bytecode a na scene
1) už by se nejednalo o bytecode, ale o nativní instrukce
2) například pro potřeby logického programování existuje WAM, určitě je implementován i hardwarově
3) nejde tu o konkrétní bytecode, jen říkám, že procesor, který umí například javu jako nativní, existuje. Dále jde o určité konstrukce, a v těch se moderní jazyky určitě protínají. Nemusí to být procesor nativně zpracovávající celý programovací jazyk, stačí když bude podporovat i jiný druh instrukcí než add, cmp, jmp atd., tedy umožní nativně využívat širší možnosti, než jsou bajt, word nebo rekurze.
4) někde v příspěvcích bylo uvedeno, že existovaly lispové procesory, určitě se ještě vrátí :-) -
disorder (neregistrovaný)> Proč ne?
neviem.
> Zase tak velká utopie to není. Donekonečna nelze pouze zvyšovat taktovací frekvenci. Jakým směrem se podle vás
> bude ubírat vývoj procesorů?
frekvenciu zvysuje intel, AMD ich ma podstatne nizsie. tzn. ze vykon ziskavaju na niecom inom?
ale vy si asi mysliste, ze v dohladnej dobe vsetku pracu zahodia a spravia procesor na bytecode? este mozu kludne zvysovat...
> Céčko je vylepšený assembler, proboha nemá to ani stringy... o seznamech nebo jiných stukturách si můžeme
> nechat zdát.
aha. a napriek tomu, ze to je (usudzujuc z tonu vam vlozim slovo do ust) "podradny vylepseny assembler" sa stale hojne pouziva. podla vas sa, zjavne, v nom ma prestat robit vsetko okrem OS. pisal som, ze C nie je na vsetko. tie vase jazyky nie su samospasitelne. btw v com boli napisane kompilatory pre ne?
> Doporučuji opravdu se seznámit s jinými programovacími paradigmaty, než je imperativní..
a tym by som zabudol dovody preco sa pouziva C? to je nejaky druh vymytia mozgu? tato poznamka je uplne mimo.
> Knihovny jdou přece vytvářet ve všech dnešních jazycích...
ale v akom pomere sa vytveraju v inych jazykoch? kniznice su najlepsie miesto, kde mozu vyssie jazyky usetrit procesorovy cas. -
No jo, takové procesory byly. Ale průser je ten, že lispovské stroje komerčně od poloviny 80. let prostě začaly zapadat. A ani to, že byly schopny verifikovat typy operandů s nulovou režií (protože paralelně s prováděním operací), měly hardwarovou podporu GC a software, který o patnáct nebo dvacet let předběhl dobu, jim bohužel nepomohlo... :-( Třeba se to jednou povede, ale zatím světu vládnou Okna a x86... -
rezna (neregistrovaný)nejenom LISP mel hardwarovou podporu. Java treba bezi primo hardwarove na vetsine mobilu (tech bez Symbianu).
Jinak u LISPu jeste porad plati ona znama veta: "Neni otazka jestli, ale kdy se zacne pouzivat v komercni sfere". Je fakt ale, ze ackoliv v LISPu umim, komercne bych ho nepouzil, protoze mam zatim po ruce IMHO lepsi technologie. Sice mi nedovoluji takova kouzla jako LISP, ale zase mi (ale hlavne tupym spolupracovnikum) hlidaji datove typy, ... -
A můžete to nějak podložit? Tohle slyším prvně, že by Java na mobilech byla implementovaná v železe.
Jinak ale chápu, nejlepší dnes použitelný lisp, ke kterým mám přístup, je Ruby :-D (Chápu, odvážné tvrzení... ;-)). Poněvadž má všechno, co momentálně potřebuju, a stačí mi. Je ale pravda, že Sussmanů a Abelsonův SICP mě neustále láká k zamyšlení nad kompilací evaluátoru vylepšeného Scheme přímo do FPGA... -
Že Jazelle existuje, to vím. Netušil jsem ale, že ho mám v telefonu – právě jsem si to zjistil. :-) Jen si nejsem jistý, do jaké míry je to důsledné, ten design mi přišel takový kombinovaný. Ale samozřejmě je to krok dopředu.
Osobně mi ale přijde mnohem lepší nápad udělat smalltalkovský procesor, nemůžu si pomoct. ;-) -
Transcendent (neregistrovaný)Když už jsem se do toho tak pustil, posílám aspoň pár odkazů, které se můžou hodit:
http://lambda-the-ultimate.org/
http://www.scienceblogs.com/goodmath/
http://wesnerm.blogs.com/net_undocumented/
http://www.defmacro.org/ramblings/fp.html
http://www.defmacro.org/ramblings/lisp.html -
Biktop (neregistrovaný)Javovský procesor, smalltalkovský procesor, forthovský procesor... Pokud si myslíte, že dělat z mikroprocesoru takový menší počítač uvnitř většího počítače je ta správná cesta kupředu... Je to váš názor, já ho nesdílím. Nepřináší to ani jednoduchost, ani efektivitu. Akorát hračka pro procesorácké vývojové týmy, kvalitativně nepřinášející nic nového, jen další, zbytečná, mezivrstva.
-
rezna (neregistrovaný)neni - ma to obrovske vyuziti v embedded platformach. proc si myslite ze prave takhle spousta mobilu zpracovava javu. protoze maji relativne slabe procesory na kterych kdyby se spustila cista emulace jak ji zname z PC, tak to neutahnou. a nebo by zrali prilis vykonu. takhle se vykon/spotreba drzi na rozumne mire a navic je to i vykonne.
a to ze je dneska embedded zarizeni kde co, je temer bez debat - (cti kdejaka picovinka ma dneska v sobe procesor a ve valne vetsine i nejakej ten OS) -
disorder (neregistrovaný)ked sa nad tym zamyslim, tak ma napada, ze mobily nemozu spustat javu na ich procesore, pretoze potrebuju mat real-time vysielanie/prijem. java by si zabrala cely procesor pre seba a kvoli tomu tam nebudu davat zbytocne silne procesory - preto je to oddelene hardwarovo. ohladne vykonu, tym si nie som isty - urcite by nespustili normalne desktopove java aplikacie (aspon nie mobily pre obycajnych ludi).
opravte ma ak sa mylim. -
Biktop (neregistrovaný)Je to otázkou zvyku. Mě například "mentálně probíhat šipečky a hvězdičky" vůbec nijak neomezuje. Tohle mi připadá, jako byste kritizoval latinku, protože přeci ty čínské obrázky na tak malé ploše zachytí tolik informace, tak proč tedy používat tak neefektivní latinku... To je prostě jen prostředek, pokud je někdo zvyklý zapisovat své myšlenky obrázkovým písmem, něchť ho má, mě latinka neomezuje, i když musím vypsat každé písmenko samostatně. A to je IMHO i případ "hvězdiček a šipeček" v C. Proti tomu by se mj. dalo snadno argumentovat např. obligátními závorkami Lispu.
Zpomalení kódu získaného z objektového jazyka je způsobeno pozdní vazbou. OOP způsobuje, že vazby, jež by při použití neobjektového přístupu byly v době kompilace známy, z principu OOP známy být nemohou. Dá se namítnout, že takové věci vyřeší optimalizace generovaného kódu, což by principiálně šlo, jenže tato optimalizace je algoritmicky velice náročná a proto odstraňování nepotřebných pozdních vazeb z kódu je spíše zbožné přání, než realita.
Které nešvary v C máte na mysli konkrétně?
Představa, že za "hloupost" vašeho počítače může použití určitých programovacích jazyků, se mi zdá poněkud naivní.
Mluvit s počítačem sice vypadá hezky, ale na druhou stranu - nynější přístup s pomocí klávesnice, myši a touchscreenu mi připadá přeci jen o poznání praktičtější. Navíc - uživatelské rozhraní je opět jen prostředek, jak počítači ukládat úkoly. Osobně nevidím důvod, proč by za dané technické situace měl být tento prostředek náročnější, než zadávané úkoly.
Jak byste si představoval, že programovací jazyk mohl ovlivnit to, nač si stěžujete? Zkuste tu rozvést svou vizi bez C a hlasem ovládaných počítačích...
Nemyslím si, že by to nějak pomohlo "rozvoji inteligence". Ještě tak před 10 lety SW ze železa ždímal co šlo. Dnes je situaci jiná v tom směru, že HW je silně naddimenzován a bez efektivního využití. Žádné nové funkce v podstatě nepřibývají, ale HW je stále "využit" na maximum. Za posledních 10 let žádné zásadní funkce do OS nepřibyly, ovšem HW se zásadně modernizoval.
Já v Assembleru programuji od konce 80. let dodnes a stále mám s efektivitou programů navrch. Optimalizace na velikost a rychlost se daří skloubit narozdíl od optimalizátorů vyšších jazyků. Samozřejmě nutnou podmínkou je dokonalé zžití se s architekturou - je skutečně naivní myslet si, že přejdu na jiný procesor, otevřu příručku k Assembleru a co napíšu bude efektivnější než výsledek kompilátoru.
Snad tu nikdo netvrdí, že všichni chtěji programovat OS. Jen tu někteří tvrdí, že používat C dnes nemá smysl. Tak tu jen jiní poukazují na oblasti, které dokazují, že používání C je stále opodstatněné :-) -
Transcendent (neregistrovaný)Právě jsem vám ohledně té vize častečně odpověděl v reakci na disorder 18.01. Doufám, že jsem se trochu vysvětlil - já vlastně většinou nijak nereaguji na žádné články, ale céčko je něco jako můj antifavorit, sorry..
Samozřejmě máte pravdu, když říkáte, že jde pouze o různé prostředky, ať už se to týká jazyků nebo komunikace počítač - člověk. To ale můžeme říct, že bez myši to ještě před nedávnem také nebylo tak špatné, a skončit u toho, že děrná páska je vynikajicí a efektivní prostředek ke komunikaci s počítačem.
Můj názor je, že budoucnost = počítače komunikující s lidmi, počítače programované zadáním problému, atd..
Co se týký psaní o OS, reagoval jsem hlavně na břitké: ... Zkuste v libovolném z vámi uvedených příkladů napsat jednoduchý operační systém a pak se znovu ozvěte.
Věřím, že jsem nenapsal žádnou nepravdu ohledně ne-c OS, a přikládám: OS není jenom jádro! Debata přes diskusní fórum je příšerně zkreslující, každou chvíli se vyjadřuje někdo jiný k jinému aspektu záležitosti a jádro uniká :-)
Samozřejmě nepopírám, a to jsem neudělal v žádném z příspěvků, že jsou oblasti, kde je céčko, potažmo assembler potřeba. To ale neznamená, že potřebujeme tolik céčkařů na ty "obyčejné" aplikace! Ať mladá generace píše ty inteligentní záležitosti ve vyšších jazycích a třeba nás do důchodu počítače ještě nějak překvapí -> nevzal jste si svou tabletku..., z důvodu vaší nadváhy o 13,5 % bylo z vašeho (automatického) nákupu vyškrtnuto pivo... :-)
Jsem asi určitě mladší než vy, ročník 81, a teď už bych se bál trumfovat se s vámi v assembleru:), přesto se mi s vámi docela dobře debatuje... Líbí se mi hutnější, obsažnější komentáře, a ne jen úsečné "Podle standardu c99 nemusí být main(void), stačí main()."
P.S. Čínština a čínské písmo jsou moc pěkné záležitosti - dokonce věřím i tomu, že právě kvůli svému písmu (japonská maturita z japonštiny = 6000 kanji znaků nazpaměť, prý) jsou asiati takoví... jiní :-) Kdo ví, za jak dlouho se budeme muset začít učit čínsky všichni :-? -
disorder (neregistrovaný)dufam, ze moji prispevkom neunikne jadro :)
> OS není jenom jádro!
ano, to je urcite pravda. teraz budem brat do uvahy len moj oblubeny typ systemu - ale vsetky tie veci okolo sa tiez lepsie pisu v C. je to tradicia malych funkcnych nastrojov. ako by sa dala napisat libc, libm, ls, cp, ... a kopec inych malych nastrojov?
ale nie len v OS je vyuzitelne - kopec kniznic sa da krasne efektivne napisat v C a pouzit v inom jazyku. alebo aj nieco take, na co sa teoretiicky hodi prave OP - GTK. -
Biktop (neregistrovaný)Myslím, že rozdíl mezi námi dvěma je v tom, že já mám blíže k železu - odtud má láska k Assembleru a C, zatímco vy zase k čisté softwarařině a algoritmizaci - odtud vaše láska k funkcionálním jazykům a Prologu.
Vaše vize o procesoru zpracovávajícím vyšší jazyk je sice zajímavá, ale zároveň na úrovni představ o počítači HAL-9000 :-) Základem dnešních procesorů jsou klopné obvody, booleovská algebra. Pro tuto technologii jsou opravdu nejpřirozenější operace typu CMP, LOAD, STORE, ADD, ROL,... Je to jen konkrétní podoba algebraické struktury, z níž konstrukce těchto obvodů vychází. Vše ostatní byste stejně musel na tyto elementární operace přeložit v rámci mikrokódu. Neboli - je samozřejmě možné vyrobit procesor nativně zpracovávající Java bytekód a takové procesory existují, ale uvnitř se ten kód stejně převádí na výše zmíněné elementární operace. Že je to rychlejší je logické, všechno co je v železe je rychlejší, než když je to v SW :-)
Závěr - dokud budou procesory založeny na logických obvodech, které znáte z elektroniky, do té doby budou mít C s Assemblerem jak ho známe desítky let navrch.
Nenadávejte Céčku, nadávejte pánům jako von Neumann a Svoboda, že pro nás vymysleli počítače tak, jak je známe :-)
S tou děrnou páskou poněkud přeháníte. Narážel jsem jen na to, že raději s počítačem komunikuji s klávesnicí a myší, než abych na něj po večerech hulákal.
Vaše počítače budoucnosti ovšem nemohou být založeny na současných technologiích. To skutečně není problém jazyka.
K těm Huskellům a jim podobným věcem ve funkci systémových jazyků... Řekl bych, že je to ještě větší zhůvěřilost, než dělat v C umělou inteligenci. Kleštěmi také nejspíš dokážete zatlouci hřebík, ale primárně jsou určeny k jiným účelům.
To je pravda - OS není jen jádro. Ale to jádro je takový nárazník mezi železem a vyšší vrstvou abstrakce. A abyste mohl používat vámi zmiňované vyšší jazyky na železe, pro nějž je přirozeným jazykem strojový kód, je C k naprogramování tohoto nárazníku ideálním jazykem.
"třeba nás do důchodu počítače ještě nějak překvapí -> nevzal jste si svou tabletku..., z důvodu vaší nadváhy o 13,5 % bylo z vašeho (automatického) nákupu vyškrtnuto pivo... :-)"
Proboha, jen to ne! :-) K myšlení a rozhodování mám mozek, počítač je jen jeho neúnavný pilný pomocník. -
petrxh (neregistrovaný)Mel jsem moznost kdysi zkouset nejake hlasove ovladani pocitace. Po 30 minutach me z toho pekne bolelo v krku. Jsem rad, ze nemusim ovladat PC hlasem a jsem vdecny za klavesnici - i kdyz i ta ma svoje mouchy a urcite by se dal vymyslet lepsi zpusob, jak ty pismenka do PC zadat.
-
disorder (neregistrovaný)no, ja nemam velmi problem si ustrazit spravnu adresaciu. samozrejme, stane sa - ale segfault sa prehliadnut neda.
a C je dnes v mnohych pripadoch nenahraditelne (a v dohladnej dobe tiez). zoberme si napr. systemove nastroje. ake vyhody by malo ls napisane v Smalltalku (ci v com :))? pre styl programovania malych a funkcnych nastrojov a pre vykonovo kriticke aplikacie este velmi dlho nebude nahrada. je to proste najlepsi kompromis medzi nizkou a vysokou urovnou - je to dobre navrhnuty jazyk, poskytuje efektivitu a umoznuje dobru prenositelnost. -
Pavel Píša (neregistrovaný)
2) Pokud vím, tak např. Mac OS je napsán v Object C, což je ale jiná káva než Céčko! :-)
Nemohu si pomoct, a musím reagovat. MacOs X je postavený nad mikrojádrem XNU (MACH 2.5 + BSD + I/O Kit). Základní dva prvky jsou, pokud se nemýlím, čisté C. I/O Kit využívá embedded subset C++. Jinak plně s předchozím nepodloženým výkřikem souhlasím v tom, že vyšší vrstvy GUI, práci s databázemi a aplikace je rozumné psát v něčem objektovějším než je C. Ale na kvalitně optimalizovaná jádra je zatím asi C nejlepší. Nakonec i ty pisatelem tak propagované Windows jsou napsané objektově v čistém C. Stejně jako Linux, HURD, BSD a mnoho dalších systémů. Je pravda, že některé verze L4 (myslím že Fiasco a Pistacio) jsou v C++, ale jejich rozšíření je mizivé a kombinování C++ a assembleru není nejpřirozenější. Obecně psaní spodních vrstev knihoven, grafiky a komunikací také vychází v C celkem rozumně.
Haskell sice neumím, konceptem se mi líbí a několikrát jsem ho boostrapoval kvůli kompilaci programu Darcs. GHC dokonce ne jen využívá knihovny jazyka C, ale i veškerý překlad přes C ve výsledku provádí. Opět je tedy pro vývoj tohoto prostředí nutné, aby existovali kvalitní programátoři v jazyce C. Stejně jako pro Python, Javu atd. Přesto, že podle mého názoru patří Darcs k nejlépe promyšleným konceptům zprávy verzí, tak i částečně díky vlastnostem prostředí Haskell má někdy problémy s nároky na paměť. Proti tomu GIT, který začal opravdu jen jako bastl nad C, chodí mnoha řádově rychleji. Není to jen jazykem, je to i stylem uvažování lidí, pracujících v C. Takže každé řešení má své klady a zápory.
Pokud se jedná o operační systémy, tak si myslím, že koncep plně verifikovatelného systému CoyotOS se syscally definovanými přes IDL, který je psaný v nadstavbě BitC by byl opravdu převratný
Asi tady ovšem jen takovýmto rozborem marním čas, protože většina křiklounů nikdy nechtěla o věcech uvažovat a diskutovat, jim pouze stačí ke štěstí zhusit ostatním jejich snažení. Sami žádnou hodnotu nepřináší a kritiku tedy neriskují.
-
Transcendent (neregistrovaný)Nejhorší je, že jsem původně vůbec nechtěl mluvit o operačních systémech, přece titulek zněl "Programovali jste v jiném operačním systému a teď chcete začít programovat pod Linuxem?"
A nakonec jsme u mikrojader :-)
Mac OS není jen mikrojádro, ale taky cocoa, objective-c atd. Prý se pro to moc hezky programuje...
A Windows jsem zase tak moc nepropagoval...
Že "Darcs k nejlépe promyšleným konceptům zprávy verzí", by mohlo být způsobeno tím, že je v Haskellu :-) -
Pavel Píša (neregistrovaný)Já se nepřu, že alternativy k C nejsou užitečné a na mnoho věcí lepší. Jen prostě poukazuji na to, že každé řešení má své potíže. Haskell určitě vede k matematickému uvažování o problému. Přesto je postaven nad C a má i své zápory. GIT se svojí cestou v C vyvinul a v mnoha ohledech možnosti DARCSu překonává. Bohužel sloučení obou výhod konceptů se zatím nepodařilo úspěšně vyřešit. Třeba to někdo zkusí v nějakém novém jazyce. Třeba se to podaří v C, třeba v Haskellu, jak se o to autor DARCSe již jednou pokusil.
Pokud se bavíme o systémech (ne toolkitech), tak je jednoznačné, v čem je jádro napsané - u Linuxu i Windows je to C a minimum ASM.(TEČKA) Pokud se bavíme o toolkitech, tak v Linuxu můžete použít Qt, wxWindows, ... v C++, Swing (Java), NexStep (Objective C), Mono (C#) atd. Pokud Vám vadí, že jsou nad LibC, tak lze i základní knihovny nad syscally napsat v jiném jazyku (myslím, že Pascal/FPC to tak částěčně dělá). Takže, pokud se bavíme o toolkitech, nevidím jediný důvod, pro ostouzení systému (jádra). Přesto neprohlašuji, že nemůže být lepší alternativa. -
Pavel Píša (neregistrovaný)
Pane ukažte mi, prosím, to C++ v NT DDK či WDF. A pak mi ukažte zdrojáky Vašich driverů pro Widows, ať vím, na jaké úrovni se s Vámi mohu bavit. Jeden zmých driverů, co lze skompilovat pro Linux, Windows KMD (to jsou pro neznalé NT) a WDM (Win98/2000/XP) model je tady. Je pravda, že existují nějaké komerční neoficiální frameworky, které dovolí psát i drivery v C++, ale DDK a Microsoft s tím nikdy nepočítal a žádnou podporu pro to nenabízí.
Přesto souhlasím, že základ jádra NT je napsán dokonale objektově a nad konceptem IRP. Je to tak čisté, že se základ od uvedení v NT nemusel měnit. Je zatím vidět, že MS cvíli dalo na lidi schopné vytvořit třeba VMS. Rozšíření o PnP a PM je však již pěkná zrůdnost. Proti Linuxu se IRP koncept jen trochu špatně používá. Vede to k duplikaci kódu a k takovým komplikacím jako je například IoSetCancelRoutine. Data může driver přijímat v IRP třemi nekompatabilními mechanizmy a je tedy nutné vědět, do jakého IRP stacku se má driver zapojit již v době vývoje. Aby toho OOP nebylo příliš, tak většina částí driverů mezi sebou komunikuje přes interní IOCTL, kterých jsou stovky a z toho mnoho nedokumentovaných.
Čekal jsem, že se na Rootu dá vést i odborná debata na úrovni. Přesto že Linux a C používám, tak se rád dozvím něco o alternativách, které klidně mohou být i technicky lepší a rád to i uznám. Sledoval jsem například i vývoj HURDu nad L4 a autorům nabízel pár vylepšení jak L4, tak správy paměti v HURDu. Nakonec dospěli k názoru, že koncepce L4 má zásadní potíže a hledají jiný základ.
Závěřem, vzhedem k prokázaným fatálním neznalostem mě již komentáře pánů "who cares" a "Biktop" nezajímají, je to jen ztráta času. Snad jejich neznalost odhalí časem i ostatní a budou jejich výkřiky ignorovat.
-
who cares (neregistrovaný)<http://www.microsoft.com/technet/archive/winntas/training/ntarchitectoview/ntarc_2.mspx?mfr=true>
"Most of the source code for Windows NT is written in C or C++." (TECKA) -
Luke (neregistrovaný)> Do kdy chcete stahovat další a další aktualizace, které pořád dokola opravují buffer overflow a
> ostatní pitomosti?
To ale neni chyba jazyka, ze. To je cena za to, ze programuji pojidaci kolacu a za to, ze zakaznika nezajima kvalita, ale cena.
Zasadne jsem proti tomu, aby SW vyrabeli vetsi a vetsi diletanti pomoci RAD nastroju, jez maji za nasledek silne nekvalitni kod vyzadujici silnejsi a silnejsi procesor a zerouci vice a vice pameti. (K Moorovu zakonu existuje taky jeste obdobny zakon: Rychlost SW klesa pomaleji nez stoupa rychlost HW.)
Kdyz zadavam diplomove nebo bakalarske prace, vyzaduji, aby implementace byla v C. Bohuzel se ukazuje, ze min a min lidi je schopno v C neco rozumne naprogramovat. Takze se voli cesta, ze i temto diletantum programovat umoznime pomoci tech "modernich jazyku". Ptam se proc? Kdyz neumi programovat, at zametaji ulice. -
jasomsef (neregistrovaný)Ak mas k dispozicii >128MB RAM tak je mozno implementacia vyssich jazykov vhodna. Ale ked sa budes (teda ty asi nie) musiet vtesnat do 128B, tak si rozmyslis co pouzijes. A pouzit v kazdom zariadeni x86 procesor je zvratenost sama o sebe. Mimochodom je vcelku lahke rozlisit programatora x86 a mikroprocesorov, pretoze ten druhy si uz pri pouziti int dvakrat premysli ci je to potrebne a o float ani nehovorim.
