Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »Richard Stallman přednáší ve středu 7. května od 16:30 na Technické univerzitě v Liberci o vlivu technologií na svobodu. Přednáška je určená jak odborné tak laické veřejnosti.
29.3.2009 18:40
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
29.3.2009 22:10
=^..^= AmigaPower® | skóre: 30
| blog: BLB
| Praha
29.3.2009 22:31
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Proč?
29.3.2009 22:58
=^..^= AmigaPower® | skóre: 30
| blog: BLB
| Praha
...proč dělat věci jednoduče, když to jde složitě?
30.3.2009 09:34
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
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).
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
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)...
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 
.
Za jakýsi druh objektů lze v C považovat:
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.
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.
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.
> 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.
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).
29.3.2009 18:57
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
First of all, C is everything but portable.
Cože?
A jaka je jeho nahrada? (systemove programovani, extremni prenositelnost)
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.
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 
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
29.3.2009 18:46
29.3.2009 20:43
29.3.2009 20:07
29.3.2009 20:34
&&, 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á.
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.
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.
Ž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.
[...] srozumitelné chybové hlášky. V tomhle bodě je například GCC vyloženě v háji [...]Například? (S rozumně novým gcc?)
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.
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).
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)
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.
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
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.
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.
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).
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.
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).
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
A jaka je jeho nahrada? (systemove programovani, extremni prenositelnost)Např. Ada.
Je sice pravda, že se dá nahradit assembly, ale nevím jestli je to zrovna "necessary"...
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.
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).
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.
...ř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.
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 :).
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.
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
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
30.3.2009 00:23
kozzi | skóre: 55
| blog: vse_o_vsem
| Pacman (Bratrušov)
. Jinak az na tu hyperbolu (neprijde mi to moc srozumitelne) mi to prijde docela anglicky . Jinak mám taky raději C++.
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ě.
30.3.2009 14:00
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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.
30.3.2009 14:01
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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.
30.3.2009 15:07
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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?
30.3.2009 15:09
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
A teď je tu jakási novinka.
30.3.2009 18:19
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
To něčemu vadí?
30.3.2009 18:32
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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?
30.3.2009 19:32
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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 :).
30.3.2009 11:07
kozzi | skóre: 55
| blog: vse_o_vsem
| Pacman (Bratrušov)
Spis je to oznaceni pro tridu jazyku.
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).
30.3.2009 18:45
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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ů.
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.
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?
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
Tiskni
Sdílej:
