Jonathan Thomas oznámil vydání nové verze 3.4.0 video editoru OpenShot (Wikipedie). Představení novinek také na YouTube. Zdrojové kódy OpenShotu jsou k dispozici na GitHubu. Ke stažení je i balíček ve formátu AppImage. Stačí jej stáhnout, nastavit právo na spouštění a spustit.
Byla vydána nová verze 1.6 otevřeného, licenčními poplatky nezatíženého, univerzálního ztrátového formátu komprese zvuku Opus (Wikipedie) a jeho referenční implementace libopus. Podrobnosti na demo stránce.
Vojtěch Polášek představil Vojtux, tj. linuxovou distribuci pro zrakově postižené uživatele. Vychází ze spinu Fedory 43 s desktopovým prostředím MATE. Konečným cílem je, aby žádný Vojtux nebyl potřeba a požadovaná vylepšení se dostala do upstreamu.
Byla vydána (Mastodon, 𝕏) druhá RC verze GIMPu 3.2. Přehled novinek v oznámení o vydání. Podrobně v souboru NEWS na GitLabu.
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 160 (pdf).
Izrael od února zakáže dětem používat v prostorách základních škol mobilní telefony. Podle agentury AFP to uvedlo izraelské ministerstvo školství, které zdůraznilo negativní dopady, které na žactvo používání telefonů má. Izrael se tímto krokem přidává k rostoucímu počtu zemí, které dětem ve vzdělávacích zařízeních přístup k telefonům omezují.
Internetová společnost Google ze skupiny Alphabet pravděpodobně dostane příští rok pokutu od Evropské komise za nedostatečné dodržování pravidel proti upřednostňování vlastních služeb a produktů ve výsledcích vyhledávání. V březnu EK obvinila Google, že ve výsledcích vyhledávání upřednostňuje na úkor konkurence vlastní služby, například Google Shopping, Google Hotels a Google Flights. Případ staví Google proti specializovaným
… více »Byl oznámen program a spuštěna registrace na konferenci Prague PostgreSQL Developer Day 2026. Konference se koná 27. a 28. ledna a bude mít tři tracky s 18 přednáškami a jeden den workshopů.
Na webu československého síťařského setkání CSNOG 2026 je vyvěšený program, registrace a další informace k akci. CSNOG 2026 se uskuteční 21. a 22. ledna příštího roku a bude se i tentokrát konat ve Zlíně. Přednášky, kterých bude více než 30, budou opět rozdělené do tří bloků - správa sítí, legislativa a regulace a akademické projekty. Počet míst je omezený, proto kdo má zájem, měl by se registrovat co nejdříve.
Máirín Duffy a Brian Smith v článku pro Fedora Magazine ukazují použití LLM pro diagnostiku systému (Fedora Linuxu) přes Model Context Protocol od firmy Anthropic. I ukázkové výstupy v samotném článku obsahují AI vygenerované nesmysly, např. doporučení přeinstalovat balíček pomocí správce balíčků APT z Debianu místo DNF nativního na Fedoře.
Tuhle jsme s vedlebydlou rozjímali nad C# a jeho novou verzí 3.0. V této verzi je spousta zajímavých novinek. K anonymním funkcím přibyly anonymní struktury (struct), lambda-výrazy, implicitně typované proměnné, rozšiřující metody (extension methods) atd. Většina těchto nových vlastností byla přidána kvůli zázraku jménem LINQ (Language INtegrated Query). LINQ by měl zlepšit integraci s externími daty (databáze, XML). Vypadá to docela zajímavě. Tento LINQ výraz:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
from c in customers, o in c.Orders
where o.OrderDate.Year == 2005
orderby o.Total descending
select new { c.Name, o.OrderID, o.Total }
se vlastně převede na něco takového:
customers.
SelectMany(c =>
c.Orders.
Where(o => o.OrderDate.Year == 2005).
Select(o => new { k1 = o.Total, v = new { c.Name, o.OrderID, o.Total } })
).
OrderByDescending(x => x.k1).
Select(x => x.v)
Což je mix všelijakých anonymních implicitně typovaných lambda-udělátek 
. Ještě pro zajímavost, tato rozšiřující metoda:
public static T[] Slice<T>(this T[] source, int index, int count)
{
T[] result = new T[count];
Array.Copy(source, index, result, 0, count);
return result;
}
umožní dělat plátky ze všech typů s indexerem, tedy například:
int[] digits = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9};
int[] a = digits.Slice(4, 3); // Same as Extensions.Slice(digits, 4, 3)
A teď to přijde: skoro si myslím, že je to celé blbě
Ty fíčury jsou mocné a asi i užitečné. O tom nemíním polemizovat, to ukáže čas. Problém je, že tenhle nános dělá z C# úplně jiný jazyk.
Myslím, že je krásné a dokonce důležité mít mocný ale zároveň jednoduchý "minimalistický" jazyk. Jazyk, kde jsou konstrukce ortogonální, kde nejsou žádné temné kouty. Takové jazyky mají šanci být nadčasové, neskončí se svým hype.
Dobrým příkladem takových jazyků je Lisp a SmallTalk. Ale taková Java se tomu hodně blíží (nebo spíše blížila, taková konstrukce pro výčtový typ z jazyka trochu "čouhá"). A C# ve verzi 1.0 byl prostě skvělý - jednoduchý, řešil některé problémy Javy a to obvykle velmi elegantně, zkrátka dílo génia.
Jenže toto nabalování fíčur z něj dělá míň uspořádanů hromádku vlastností (jako Object Pascal v posledních verzích), nemůžu si pomoct.
Podle mne jedna z nejlepších vlastností platformy .net je možnost efektivně kombinovat různé jazyky. Kdysi před mnoha zimami jsem psal pod Win32 program, kde různé moduly byly v C++ ala Borland, C++ ala Microsoft a Delphi. Dosažení kompatibility nebylo jednoduché. Když se tehdy objevily první informace o .netu, byl jsem z možného mixování jazyků nadšen. (Pozn: Java bytecode je dost natvrdo navržen pro Javu, překládat do něho jiné jazyky není jednoduché.) CLR rocks!
Jak už jsem naznačil, proti LINQ a funkcionálním udělátkům nic nemám, ba právě naopak. Jenže proč přidávat tyto věci do "dokonalého" jazyka a tím ho destabilizovat. Není lepší udělat nad dotnetem nové dotazovací/funkcionální jazyky? Když je platforma pro absobci nových jazyků dobře naladěna? Takové nějaké jazyky už jsou, třeba Python, F# a Boo.
Více jazyků v jednom projektu je sice možné, ale ne vždy úplně pohodlné. Ale to se dá vyřešit velmi elegantně, v C# je konstrukce #region, která slouží k oddělování úseků kódu. Stačí ji doplnit o popis syntaxe a rázem je možnost mít v jedné třídě každou metodu v jiném jazyce. Třeba:
class Pokus
{
// C# je takové "lepidlo", jeho syntaxe je implicitní
public static void Main()
{
System.Console.WriteLine(pow(10));
}
#region syntax("Ada")
function pow(a : integer) returns integer is
begin
return a*a;
end;
#endregion
}
Samozřejmě to není úplně bez problémů, spolupráce jazyků je sice CLR teoreticky zajištěna, ale "Devil is in the details". Každopádně využívat různé jazyky dle potřeby (vlastně jako dnes lepíme na projekty knihovny) by nemuselo být špatné. Pamětníci z časů DOSu zavzpomínají na oblíbenou kombinaci Turbo Pascal + vkládaný assembler.
Tiskni
Sdílej:
pre mňa sú java aj c# obmedzené deriváty inak skvelého, no nepochopeného, jazyka. Okrem toho ešte uznávam aj perl (ktorý, uznávam, je takisto ťažký na pochopenie).
nevraviac napr okrem spomínaných Lisp a Smalltalk o Objective C, Prolog, ... 1000 ľudí 1000 chutí (resp, ako sa nás isté trendy snažia presvedčiť 1000 ľudí, len jedna správna chuť)
Koncepce oddělených jazyků má jeden dost podstatný problém, a to je ten, že mezi jazyky se pak musí komunikovat pomocí "interface", který zvyšuje režii a složitost programu. Je to tentýž problém, který řešil Linus při návrhu Linuxu. Proč Linus nedělal Linux jako mikrojádro s oddělenými moduly, ale zvolil makrojádro? Protože prostě koncepce "vše v jednom" (systému, programovacím jazyce) vede k vyšší efektivitě a omezuje režii "interfaců". Ve svém důsledku je i zvládnutí jednoho složitého programovacího jazyka jednodušší a efektivnější, než několika oddělených. Takže s Vaším názorem, že je levnější mít několik oddělených jazyků s danými koncepcemi musím silně nesouhlasit. V praxi totiž vidím, že právě tento koncept je výrazně dražší a mnohdy vede k manažerským rozhodnutím jazyky sjednotit, případně omezit jejich počet na minimální. Takové velmi známé rozhodnutí je rozhodnutí NASA, která se po ekonomické analýze rozhodla vyvinout vlastní univerzální programovací jazyk, který a jen tento bude používat. Tak se zrodila Ada. A rozhodně zapomeňte na to, že by Ada trpěla nějakou minimalistickou koncepcí. Podle mého časem (i když třeba za hodně let) se ukáže, že právě koncepty minimalistických a ořezaných programovacích jazyků jsou příčinou značných ztrát a manažeři postupně přejdou k jazykům komplexnějším.
IL je sice zásobníkový assembler, který se dá ohnout různě, ale trpí závislostí na určitém formátu metadat a dalších věcí. A je tu plno předpokladů, které možnosti ohnutí velmi shazují. Ale to je na jinou debatu.
.
Jinak s tou mezijazykovou režijí máte samozřemě pravdu. Ve svém příspěvku píšu, jak nepříjemné bylo kombinovat kód ze dvou překladačů C++ a Delphi. Jenže mé návrhy vycházejí z předpokladu, že kooperace mezi jazyky je na dotnetu mnohem (řádově!) lepší.
Můžem diskutovat nakolik je tento předpoklad podložený...
Něco se už přeci jen zlepšilo, o Jave 1.5 jsem osobně schopný i uvažovat... 
Je ale pravda, že s těmi operátory jsou trošku paličatí.
...pochopí to každý středoškolák...Nepochopí. Nechápou to ani vysokoškoláci na elektrofakultě. (A pro rejpaly jde i o absolventy průmyslovek)
Ale Graham razí Lisp, jak to sedne ke stoupenci C++? Že by pragmatismus používání v dnešním prosíťovaném, proknihovnovaném, prowindowsovaném světě?
za "úspechom" javy je princíp návrharov "čo neviem používať ja, to nevie používať nikto iný", resp, "tomuto by idiot porozumieť nemusel, toto by mohol zle zapísať, toto vyhodíme"
)
while (...) {
Integer i = hashtable.get (key);
int ii = i.intValue ();
ii++;
hashtable.put (key, new Integer (ii));
}
toto bol posledný klinec vo vzťahu java a ja. jednoducho mi vadilo, že základné datové typy (int, double, ...) nie sú objekty, ale reťazec už ano
BTW, funkce jako data...dejte mi vědět, až v C++ bude lambda... Ta anonymní třída aspoň simuluje uzávěr, jak se v C++ dělají uzávěry?
class Phone; class FMRadio; class MP3Player; class PhoneWithFMRadio extends Phone, FMRadio;samozrejme, dá sa to napísať aj ako:
class PhoneWithFMRadio {
Phone phone;
FMRadio radio;
}
ale tým stratím možnosť
PhoneWithFMRadio my_nokia = new ...; t_mobile.registry (my_nokia); cz_republic."zaplat koncesionarske poplatky" (my_nokia);
Mám pocit, že právě kvůli jeho existenci se v Javě na vícenásobnou dědičnost implementace (nikoli rozhraní) vykašlali. A zdá se, že jsou i stoupenci mixinů pro C++.
"Functional Style in C++: Closures, Late Binding, and Lambda Abstractions"
http://okmij.org/ftp/cpp-digest/Functional-Cpp.html
Ani tak bych ji nepovažoval za ideální, ale takhle je to celkem bída. Myslím, že kdybychom odřízli prostředí, knihovny a podporu dodavatelů a ponechali jen jazyky a jejich kvality, byla by na tom o dost hůř.
Osobně mám pocit, že zastánci Pythonu a Javy se tak chovají, zatímco C++kaři a rubisté jsou příjemnější lidi...
BTW, ten odkaz už mám docela dlouho na seznamu k přečtení...
)
Že někteří railsaři mohou být fanatici, to bude ten "poturčenec horší turka"-syndrom. (To ale nemění nic na tom, že koleje jsou jako prostředí podstatně lepší než PHP... ) To se stává.
Jinak s kolegy pythonisty v okolí vycházíme bez problémů, koukáme tak nějak všichni na oboje a bereme si ponaučení. A ještě si navzájem pomáháme. (On má Raymond s tím přínosem znalosti více jazyků, i kdyby je člověk aktivně nepoužíval, doclea pravdu.)
Nechápu, co má Turingův stroj společného s "rekurzivními jazyky", ať už ten termín znamená cokoliv...to je trida jazyku v Chomskeho hierarchii ( http://en.wikipedia.org/wiki/Chomsky_hierarchy ), jsou to prave ty jazyky, ktere turinguv stroj prijima, rekursivne spocetne jsou ty, u kterych je navic schopen ( v polynomialnim case ) rozhodnout, ze je neprijme... ;) v praxi (ehm... teorii ;) ) to funguje tak, ze nejaky problem zakodujes nejakou abecedou (pro jednoduchost vem 0 a 1 jako celou abecedu ;) ) a pak zkoumas, pomoci turingova stroje, jestli dane slovo (mnozina znaku) odpovida tvym predstavam (definovanymi pomoci gramatik). Jestli je turinguv stroj po precteni vstupniho slova ve vystupnim stavu, slovo prijima a odpovida tedy programu turingova stroje (resp. gramatice podle ktere vznikl). doporucuji: http://ktiml.mff.cuni.cz/~bartak/automaty/prednaska.html btw. taky se mi zda, ze Ruby-isti jsou mnohem militantnejsi nez python-isti - osobni zkusenost (viz take http://www.artima.com/weblogs/viewpost.jsp?thread=141312 )
). Snad téměř v každé diskuzi o Ruby či Pythonu sem narazil na rubysty kteří bezdůvodně začali na Python házet špínu a hnůj. Asi se Pythonu bojí, tak jsou proti němu tak vyhrazení
Možná sem se s tím setkal hlavně díky tomu, že jsem se rozhodoval mezi Ruby a Pythonem, takže sem četl hlavně články kde byly vlastnosti těchto jazyků srovnávány. Ale prostě ten zealotismus rubystů byl naprosto očividný... a možná to trošku i přispělo k tomu, že sem se rozhodl tradši pro Python (ale je to jen podružná věc, ty důvody byly racionální, né tohle ).
24.3.2006 14:09
Mikos | skóre: 34
| blog: Jaderný blog
| Praha
I generování přes XML má své meze
preto pri návrhu používam práve tento spôsob, núti ma premýšľať multiplatformovo. samozrejme, že mám možnosť obchádzať svoje vlastné mantinely. no a implementačným obmedzením je to, že generujem medzivrstvu (v mojom prípade Class::DBI). z xml navyše generujem len limitované featuresky, ak sa dajú (napr view). je to zošívané na mieru mojej súčastnej práce.
ale z-do ste kľudne mohol spomenúť
24.3.2006 14:10
Pavel Stárek | skóre: 43
| blog: Tady bloguju já :-)
| Kolín