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.
Jean-Baptiste Mardelle se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 25.04.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
TmuxAI (GitHub) je AI asistent pro práci v terminálu. Vyžaduje účet na OpenRouter.
Byla vydána nová verze R14.1.4 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek i s náhledy v poznámkách k vydání. Podrobný přehled v Changelogu.
Bylo vydáno OpenBSD 7.7. Opět bez písničky.
Testy na papír nemám rád, ale řekl bych, že to je jedna z mála možností jak poznat kdo jazyk zná a požívá a kdo jen tak nějak lepí kusy kódu a za pomoci IDE je doopravuje aby fungovaly. Takže nějakou vypovídací hodnotu má.
for
a cosi zmáčknu, tak Eclipse to doplní na for(int _; i = _; i++)
, nebo tak něco
deb http://ftp.cz.debian.org/debian jessie main contrib non-free
za zmatenost se omlouvam, pricinu toho jak pisu mozna osvetlim nekdy v pristim zapisku.neomlouvej se, tou zmatenosti jsem myslel zadani te pisemky
co se tyce vymysleni reseni, tady by prece melo jit o vymysleni algoritmu ne?to rozhodne...
nezastavam se opisovani manualu do pisemky to ne, ale z hlavy vedet syntaxi funkci, ktere sme obcas videli jen jednou? nez manual staci jednoradkovy popis funkce(vstup, vystup, bla, ble);no zrovna funkci
atoi
tam mas i se syntaxi deb http://ftp.cz.debian.org/debian jessie main contrib non-free
int
tam mate napsanou, takze zbyva jenom printf
(pripadne std::cout << ...
v c++) vsechno ostatni jsou zakladni konstrukce. Pokud z hlavy nezvladnete v c vytisknout cislo ani retezec, tak cecko neumite a zakonite z nej nemuzete dostat zapocet. A rikal jste ze slo o zapocet z jazyka c a ne z nejake algoritmizace.
deb http://ftp.cz.debian.org/debian jessie main contrib non-free
Stačí dva pointery
Skutecne? Vsechno pisete z hlavy? Stale dokola vymyslite kolo?Stále dokola ne, ale překvapivě často v praxi zjistíte, že všechna kola, která na daný typ trakaře někdo vymyslel, jsou taková, inu, hranatá
Asi tezko napr. budu psat vlastni Hibernate.Co tím Hibernate přesně myslíte? Kernelovou hibernaci?
Psát takovou knihovnu znova a tak, aby to „relační“ nebylo v názvu jenom na ozdobu, by zase nebyl tak špatný nápadTak s tím stoprocentně souhlasím
Programovat vubec neznamena, ze musim bezpodminecne umet z hlavy psat kod, ze musim perfektne ovladat celou syntaxi.Jednoznačně nesouhlasím! Syntax je prostě základ! Je to jako kdybyste chtěl řídit auto a numěl to. Taky byste se vyboural, protože místo dopravní situace byste řešil řazení, spojku a já nevím co všechno. Efektivně, kvalitně a rychle programovat můžete jen tehdy, když v syntaxi jazyka přímo myslíte a nemusíte přemýšlet nad každou konstrukcí zda je či není možná. Já třeba používám NetBeans a doplňování kódu je super věc. Ale umět napsat Javí kód v "obyčejném" editoru bez podpory doplňování kódu a balíků – to je prostě základ. Zvlášť, když potřebujete rychle opravit chybu na produkčním serveru, kde NetBeans nejsou. Co se testů na papír týče, jsem jednoznačně pro. Sám si spoustu úvah píšu na papír. Možná je to tím, že jsem papírem odchován...
if
y, jak se ohraničují složené příkazy, jaký (jestli) je rozdíl mezi jednoduchými a dvojitými uvozovkami atd.
Jinak jedno takove pozorovani: obcas jsme dostavali vybrat, jestli chcem u zkousky v pisemnce casti jednodussi priklady a nesmi se pouzivat zadna literatura nebo jestli chceme tezsi priklady, s tim, ze si muzeme donest co chceme. Prekvapive byl vysledek hlasovani, co si pamatuju, vicemen vzdy temer 100% pro jednodussi variantu a umet vse z hlavy, protoze vetsine lidi bylo jasne, ze je snadnejší naucit se teorii (kterou jsme k ustni stejne museli umet) zpameti, pripadne si odvodit to co potrebuju z toho, co znam a resit nejaky lehčí problém, který aspon trochu pripomina neco, co uz nekde (treba na cvicenich) videli, nez si nemuset pamatovat nic a resit problem, ktery pro vetsinu byl neresitelny i s veskerou dostupnou literaturou. Ve vyssich rocnicich pak byla uz obykle automaticky ta druha (tezsi) varianta. (nikdy se tedy nejednalo o predmet, ktery by jen vzdalene pripominal programovani, ale to na veci asi nic nemeni).
A jeste jedno pozorovani (i kdyz z valne casti jen z doslechu, ale z duveryhodnych zdroju: hodne studentu, patrne navyknutych tak ze stredni skoly, ma dojem, ze nemusi nic umet a kdyz po nich ve skole chcou nejake znalosti, tak to povazuji za zcela nelegitimni pozadavek, coz v kombinaci s tim, ze skoly jsou placene podle poctu studentu ma dosti neblahy vliv na naroky, ktere se kladou na studenty a tim obvykle i na kvality vyuky celkove (v tom smyslu, ze obtiznejsi partie se preskoci a pod.)
Já jsem na matfyzu napsala testů na papír fůru. Nevím, jestli to změřilo, jak umím programovat, ale s naprostou jistotou vím, že mě to naučilo líp programovat.Ano, o tom přesně mluvím tady
ZČU v Plzni? Tam bohužel strhávali hodnocení i za středníček.Psal jsem zkouškovou písemku z Céčka u kolegy Herouta na papír a na nic takového si nepamatuju.
Další si zas myslí, že to jde lineárně...Treba chteli pouzivat counting sort
Stejně tak celý počítač je vlastně jeden obrovský konečný automatKdyž půjdete touto cestou dál, zjistíte, že celý Vesmír možná také
deb http://ftp.cz.debian.org/debian jessie main contrib non-free
Kompromisním řešením by bylo psát test v C na počítači s textovým editorem a kompilátorem assembleru.Jiná možnost, která také dobře otestuje, jak kdo umí programovat, je dát k dispozici počítač se vším všudy, ale jen 10 minut času. Ale to předpokládá, že každý může použít prostředí, na který je zvyklý.
potreba prestavit si cely "problem" nez zacnu neco psat...Právě zvládnutí této představy vypovídá o schopnosti programovat daleko víc než všechno ostatní.
Jazyk C nepredpisuje, ktoré funkcie sú definovanéISO norma predepisuje, jake funkce maji byt dostupne. Proc myslite, ze se v manech v sekci CONFORMING TO uvadi C89, C99 atd...
Mimochodom nikdy mi nešlo do hlavy prečo ľudia považujú pointre za nejakú čiernu mágiu. Mám pocit, že je to len "self-fulfilling prophecy". Toľkí to tvrdia, až sa toho tí ostatní zľaknú a strach im nedovolí považovať ich za normálnu vec. A reťazová reakcia pokračuje.Podle meho nazoru jsou ukazatele problemem pro ty, kteri nemaji predstavu o tom, jak hardware funguje. Pro ty, co maji predstavu jak funguje procesor, pripadne uz maji za sebou programovani assembleru, tem proste staci vysvetleni, ze ukazatel je adresa a nanejvys se popisou zaludnosti ponterove aritnmetiky, ekvivalence s poli a pretypovavani.
Test bych tipoval nanejvýš tak na septimu na gymplu, případně na výstupní test týdenního rychlokurzu. O programování v tom testu není ani slovo.
Cíle předmětu: Naučit studenty základním programovacím návykům a algoritmizaci.
Ale k tomu je C zoufale nevhodné! Tohle nemůže skončit jinak, než že se místo umění vyučuje řemeslo. Kdo zvládne umění, zvládne pak snadno i řemeslo. Opačně to nedává smysl.
Vysvětlit základní vlastnosti a struktury jazyka C a jejich využití.
A tohle je v zásadním rozporu s minulou citací.
Připravit studenty na práci v prostředí Borland C++ Builder.
A co takhle rovnou připravit studenty na smrt? To je totiž přibližně totéž.
Kdybych vygooglil tu anotaci, asi bych našel i ústav, protože studijní informační systémy bývají veřejné... Ale nechce se mi. Tipoval bych to na nějaký obor typu chemie nebo biologie, kde se studenti jednou či dvakrát dotknou informačních technologií, jen tak pro formu, aby měli tušení, co vlastně používají.
Ale k tomu je C zoufale nevhodné! Tohle nemůže skončit jinak, než že se místo umění vyučuje řemeslo. Kdo zvládne umění, zvládne pak snadno i řemeslo. Opačně to nedává smysl.Já jsem přesvědčen o opaku: nejdříve je potřeba zvládnout řemeslo, než se pustíte do umění (to platí třeba i v hudbě). Jinak vychováte lidi, kteří jsou schopni hlubokých abstraktních myšlenkových konstrukcí, jejichž jedinou chybou bude, že nebudou mít nic společného s realitou – viz Aniččin příklad s tříděním
Řemeslo (konkrétní jazyk) se dá často naučit za odpoledne. S uměním to tak rychle nejde. K čemu někomu bude, že ovládá syntaxi (a možná i sémantiku) jazyka C, když netuší, co má vlastně napsat? Výsledkem jsou pak jedině spousty nefunkčního (resp. nekvalitního) kódu.
V jazyce, kde člověk musí zvládnout spoustu technických detailů a kde začátečník neustále ukazuje někam neplatným pointerem, nelze pochopit základy programování. Mým nejoblíbenějším jazykem je C++, ale začátečníka bych něčím takovým opravdu nezatěžoval.
Jen aby bylo jasno, rozhodně nehájím Packal (IMHO nejhnusnější a nejneschopnější jazyk všech dob, který umí všechno jen napůl (například neumožňuje pointerovou aritmetiku, ale zároveň klidně dopustí vytvoření neplatného pointeru!)) nebo Javu (která je tak provázaná s OOP, že to pro začátečníka opět nemusí být správnou volbou).
Je mnoho škol, kde se učí Haskell, případně Lisp. V těchto jazycích člověk výborně pochopí princip „toku dat“ a programuje pak i v procedurálních jazycích lépe a úsporněji. Jinde zase začínají s procedurálně orientovaným skriptovacím jazykem, který se hodí pro vysvětlení všech základních zásad a algoritmů, aniž by student musel vědět, proč mu to neustále padá, i když program na první pohled vypadá správně. Že se někde přepisují struktury alokátoru haldy, to přece začátečník není schopen odhalit. Zpočátku ani nechce vědět, kde se co alokuje a proč.
Možná není zcela správné o umění a řemesle tvrdit, které z nich má přijít „napřed“ a které „až pak“. Faktem ovšem je, že bez toho umění si člověk nevyzkouší ani řemeslo, protože prostě „neví, co by“. Strom nebo hashovací tabulku si bez patřičných znalostí nenaprogramuje. Řemeslo oddělené od umění tedy nikdo nemůže pořádně zvládnout, protože prostě nemá jak získat zkušenosti.
Řemeslo (konkrétní jazyk) se dá často naučit za odpoledne.Pokud už jste v nějakém podobném programoval, pak bezpochyby ano. Ale naučit se slušně programovat napoprvé je pro většinu lidí přeci jen o něco náročnější. Co se technických detailů týče, ty nutně pro zvládnutí umění musíte pochopit, protože jinak nebudete mít představu o tom, jak je která operace náročná, a tedy ani porovnat, který algoritmus je lepší.
Pokud už jste v nějakém podobném programoval, pak bezpochyby ano. Ale naučit se slušně programovat napoprvé je pro většinu lidí přeci jen o něco náročnější.
Ano, to je pravda. Je spousta věcí, které je třeba správně pochopit, a pro úplného začátečníka to je jistě obtížné. Koneckonců, proto tvrdím, že C není vhodný začátek. Je spousta jazyků, které se lze naučit snadněji a rychleji. Přechod k C/C++ pak může být méně bolestivý.
Co se technických detailů týče, ty nutně pro zvládnutí umění musíte pochopit, protože jinak nebudete mít představu o tom, jak je která operace náročná, a tedy ani porovnat, který algoritmus je lepší.
Na toto je těžké reagovat. Záleží na tom, co rozumíte pod pojmem operace a zda se bavíme o asymptotické složitosti nebo o nějakých multiplikativních konstantách. U produkčního software, který musí obstát v konkurenci, jsou i multiplikativní konstanty podstatné. Pro úplného začátečníka, který si schce vyzkoušet několik algoritmů, je ovšem zajímavá pouze asymptotická složitost.
Vaše poznámka mě ovšem přivedla k úvaze, že pojem umění, o kterém tu pořád mluvím, může být chápán různě. Jiné je umění à la Donald Knuth a jiné je umění à la kernel OpenSolaris. Já jsem zde za umění označoval vlastně pouze to první, tedy pochopení algoritmů a principů práce s daty. Ve druhém případě jde bezesporu taktéž o umění, ve smyslu mistrného zvládnutí možností dané platformy a využití všech známých (existujících) možností optimalizace.
Mám za to, že první zmiňovaný druh umění by měl předcházet tomu druhému. Opačným postupem by to asi nešlo. Umění prvního druhu technické znalosti bezprostředně nevyžaduje. Druhý typ umění je na nich naopak založen.
Myslím tím asymptotickou složitost – pro tu je rozhodující mít přesnou představu o tom, kterou operaci lze považovat za konstantní a kterou nikoliv. Právě to vyšší jazyky (tím myslím vyšší než Céčko) znatelně zkreslují, spousta lidí si pak dlouho myslí, že přiřazení stringů je stejně drahé jako přiřazení čísel, o třídění nemluvěTo ale znamená znát spíš použitou knihovnu, než programovací jazyk. Tipuju, že třeba pro C++ existují knihovny, které práci se stringy implementují různě, a v některé bude přiřazení stringu opravdu stejně drahé jako přiřazení čísel (protože se přiřadí jen pointer), někde bude samotné přiřazení stejně drahé jako přiřazení čísel, ale následná úprava stringu bude dražší (copy on write), a někde to bude znamenat okopírovat celý řetězec hned při přiřazení.![]()
Ale k tomu je C zoufale nevhodné! Tohle nemůže skončit jinak, než že se místo umění vyučuje řemeslo. Kdo zvládne umění, zvládne pak snadno i řemeslo. Opačně to nedává smysl.Prave naopak, ale musi se zaroven s tim i ucit, jak pocitac pracuje uvnitr. Videl jsem uz dost lidi, kteri si mysleli, ze float znamena realne cislo a vesele je mezi sebou porovnavaly. Vetsina z nich se ucila programovat v jave.
Smím se zeptat, jaký je rozdíl mezi porovnáním floatu v Javě a v C? Není to náhodou v obou jazycích stejný nesmysl? Tohle je naprosto špatný příklad. Porovnání floatů je vždy (potenciální) problém a C v tomto není nijak výjimečné.
C nikoho neučí, jak počítač funguje uvnitř. To je nesmyslný mýtus! O fungování počítače ví pouze ten, kdo navrhuje backend pro kompilátor pro konkrétní platformu, případně přispívá do nějakého kernelu. (Zdaleka o tom ale nemá (resp. nepotřebuje mít) všechny informace.)
Když budu vědět, jak počítač funguje uvnitř, jak mi tahle znalost pomůže k vytvoření kódu, který je snadno čitelný, snadno rozšiřitelný, snadno testovatelný a bez podezřelých míst kropících paměť?
Nebo snad s (pouhou) perfektní znalostí C budu schopen naimplementovat AVL strom? Neberte mě prosím nikdo za slovo — dosaďte si tam za AVL třeba algoritmus, který není v STL... (No, v STL jsou vlastně R&B stromy, ale to na mé pointě nic nemění.)
Když přijde žák do autoškoly, nebude se učit, jak rozmontovat motor. Napřed se naučí auto řídit. Po autoškole asi bude potřebovat ještě spoustu kilometrů zkušeností. No a teprve později, třeba až bude mít vlastní auto, se začne podrobněji zajímat, co je uvnitř. Ve většině případů ovšem tohle přenechá odbornému servisu. Řidič je programátor, odborný servis je jazyk a kompilátor.
Když budu vědět, jak počítač funguje uvnitř, jak mi tahle znalost pomůže k vytvoření kódu, který je snadno čitelný, snadno rozšiřitelný, snadno testovatelný a bez podezřelých míst kropících paměť?Rozhodně vám pomuže k napsání kódu, který je efektivní, na což jste ve výčtu nutných pozitiv trochu zapomněl
Nebo snad s (pouhou) perfektní znalostí C budu schopen naimplementovat AVL strom?Pokud budete vědět, jak má fungovat, pak bezpochyby ano.
Rozhodně vám pomuže k napsání kódu, který je efektivní, na což jste ve výčtu nutných pozitiv trochu zapomněl
Řeči o efektivitě jsou většinou vágní fráze, proto jsem se jim raději vyhnul. Kód by měl být jistě efektivní z pohledu vyčíslitelnosti, aby se vůbec někdy mohl zastavit. Také by měl být efektivní z pohledu složitosti, protože... (No nic, jen ať někdo zkusí setřídit 4 GB dat kvadratickým algoritmem...) Potud je to jistě pravda.
Mám ovšem pocit, že většina lidí dnes pod pojmem efektivita jaksi implicitně rozumí nějaké multiplikativní, ne-li aditivní konstanty. Tento druh efektivity je až na nejposlednějším místě a do mého výčtu se tudíž nevešel. Efektivita v tomto smyslu patří mezi žádaná, nikoliv však nutná pozitiva. (Jinak byste musel předem odmítnout každý software v Javě a Erlangu... (Třeba Openfire a Ejabberd.))
Samozřejmě souhlasím s tím, že programátor by se měl starat o efektivitu v každém smyslu toho slova. Pouze jde o správné setřídění priorit.
Pokud budete vědět, jak má fungovat, pak bezpochyby ano.
Naprostý souhlas. (Zkoušel jsem to před pár lety sám na sobě a byl jsem úspěšný.) Ale já jsem výše napsal „s pouhou perfektní znalostí C“, tedy bez potřebné teorie kolem stromových algoritmů. S pouhou perfektní znalostí C bych AVL strom nikdy nenaprogramoval.
Asi jsem trochu neopatrně smíchal dohromady dvě myšlenky:
Začátečník, který nemá teoretické základy, se těžko může učit programovat v C (případně v jiném jazyce), protože zkrátka nemá co programovat. Neví, jak (a proč) by měl vytvořit složitější program, který by mu přinesl zkušenosti.
Začátečník, který má teoretické základy, ale začne se učit C jako první jazyk, narazí na obrovskou spoustu technických potíží, na které v této fázi není připraven. Nemůže se pak plně soustředit na podstatu implementace, totiž jaké má datové struktury a co se děje s daty. Místo toho řeší, proč mu to zase odletělo a kde se tam vzal další double free.
Začátečník, který má teoretické základy, ale začne se učit C jako první jazyk, narazí na obrovskou spoustu technických potíží, na které v této fázi není připraven. Nemůže se pak plně soustředit na podstatu implementace, totiž jaké má datové struktury a co se děje s daty. Místo toho řeší, proč mu to zase odletělo a kde se tam vzal další double free.S tím souhlasím. (Ale na druhou stranu, vždycky když se tohle někomu snažím vysvětlit, vzpomenu si také na své dávné začátky, převážně v různých assemblerech, které mi podle všeho v naučení se programování nijak nepřekážely
V názoru na použitelnost C pro výuku základů programování se asi neshodneme. Pravdou jistě je, že C poskytuje mnohem lepší vhled do fungování počítače (z pohledu programátora) než nějaký interpretovaný jazyk. Já však tvrdím, že začáteční nebude mít v první fázi o detaily kolem fungování počítače zájem. Až napíše několik programů, které (úspěšně) používají pole, pak se třeba začne ptát, kde vlastně ta pole jsou. V úplných začátcích tohle ovšem řešit nechce, že ano...
Jako školní úkol jsem kdysi dělal takový jednoduchý kompilátor jednoduchého jazyka... Když to porovnám s GCC, připadá mi GCC jako zázrak. (Nemluvě o kompilátoru Intel, který je ale bohužel closed-source.) Když programuji v C++, mám k autorům překladače hluboký respekt a připadám si jako pouhý uživatel, případně jako řidič, který má navíc autopilota. Přiznám se, že opravdu nevím, jak (opravdový produkční) kompilátor pracuje uvnitř. Přitom si nemyslím, že bych nerozuměl tomu, jak funguje počítač. (Jiný školní úkol byl třeba dummy kernel pro MIPS, sice v tříčlenném týmu, ale přece...) Takže asi takhle jsem to myslel s tím řidičem a uživatelem.
Tak to jo. To C je tam pak vlastně spíš pro zajímavost, než aby na něj něco navazovalo, že jo.
Tiskni
Sdílej: