Apple představil nový MacBook Pro s čipy M4, M4 Pro a M4 Max.
Na GOG.com běží Halloween Sale 2024. Při té příležitosti lze získat zdarma počítačovou hru Return of the Phantom.
Společnost OpenAI spustila internetový vyhledávač ChatGPT search.
Konference OpenAlt 2024 proběhne již tento víkend 2. a 3. listopadu v prostorách FIT VUT v Brně. Začíná ale už v pátek na warm-up party ve Studentském klubu u Kachničky v 17:00. Pokud jste ještě areál FITu nenavštívili, k dispozici jsou pokyny k orientaci. Na programu je 54 přednášek a workshopů. Témata jsou od silně technických témat jako je třeba GCC nebo PostgreSQL po méně technické témata jako eGovernment, nebo třeba detailní analýzu … více »
Byla vydána nová verze 6.9 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 14.0.1. Tor client na verzi 0.4.8.13. Thunderbird na verzi 115.16.0.
Vývojáři free a open source synchronizačního nástroje (a p2p náhrady Dropboxu) Syncthing oznámili, že z důvodu odporu ze strany Google Play ukončují podporu OS Android. Bohužel v rámci toho zmizí i vydání Syncthing na F-Droid, který má slabší uživatelskou základnu. Syncthing je na Androidu implementován formou wrapper aplikace, která spustí Syncthing démon, vyžádá potřebná oprávnění a zpřístupní webové rozhraní démona. Ve srovnání se
… více »V červnu 2022 bylo oznámeno, že z K-9 Mailu se stane Thunderbird pro Android. Trvalo to poněkud déle, než vývojáři předpokládali, ale včera byl první stabilní Thunderbird pro Android 8.0 vydán.
Projekt microDMG Racer na Kickstarteru nevyšel, tak se autor rozhodl uvolnit na ESP32 postavené autíčko i ovladač jako open source.
Byl vydán TrueNAS SCALE 24.10 „Electric Eel“. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Byla vydána nová verze 24.10.29 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Nově s podporou AI (whisper.cpp) pro generování titulků. Nejnovější Shotcut je již vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Rychlost LibreOffice pak nemusí být v některých případech plně ekvivalentní.Bohužel, některé dokumenty např. z Wordu nejde v LibreOffice otevřít nebo se otevírají třeba půl hodiny. Problémy mi dělala třeba specifikace jazyka C# 5.
LibreOffice 4.4.0.3, otevření a spočítání slov za cca 10 vteřin, vypadalo to ok. Ale stačí posunout posuvník do půlky dokumentu a text bude několik minut utíkat kamsi pryč. Alespoň že se viník podepsal tučným písmem v rohu stránky.
Outlook vnímám opravdu jako jednoho z nejlepších emailových klientů (HTML editor...)HTML EDITOR!? To HTML maily jeste neumrely?
Taky používám textové e-maily. Citace pomocí: > odrážky: - a odkazy do: <…>.
Však já taky používám e-mail z valné většiny pracovně. E-mail mám rád, ale jeho nadužívání je kontraproduktivní – některé věci prostě patří do verzovacího systému, etherpadu, ethercalcu nebo třeba na síťový disk.
Jsme firma, kde šíleně věcí běží přes maily a musím říci, že txt je silně nedostačující. V rámci mailů běhají tabulky, které jsou součástí mailu, člověk rychle doplní do tabulky info a odpoví.Třeba termíny zakázek, úhledně srovnané do tabulek že? Šaška (většinou takové rokotiny vymýšlejí šašci) který vymyslel využití e-mailu jako firemního-výměnného-přenosového-komunikačního protokolu bych umlátil Outlookem. Přitom by to šlo vyřešit o tolik elegantněji.
Nejlepší to prý je na ukládání hesel a citlivých dat o zákaznících…
které mají všechny firmy
Ne, všichni tenhle software nemají.
a žádná by neměla problémy s tebou takto komunikovat?
Že s tím nejsou problémy? V zápisu, pod kterým diskutujeme, čtu něco jiného.
Reagoval jsem na tvůj komentář, kde píšeš o Excelu, nečetl jsem všechno nad tím.
Myslím, že jsem nastínil, co se u nás v excelu dělá.Kde?
Nehledě na to, jak duplicitní obsah v text/plain a text/html plýtvá diskovým prostorem.
Tohle už dneska asi nikoho moc netrápí – v době, kdy uživatel klikne na nějakou ptákovinu (třeba „zábavné“ video) a přes síť proletí desítky nebo stovky MB, už nemá moc cenu řešit duplikaci textového obsahu. Spíš je to výhoda, když je ta textová alternativní část dobře udělaná (tzn. ne jako v případě Microsoftu)
HTML e-mail je svinstvo, které nikdy nemělo vzniknout. Na formátované a strukturované dokumenty máme jiné a vhodnější technologie než HTML
Pro e-mail by se hodil nový formát, mohla by to být podmnožina XHTML + atributy v nějakém jmenném prostoru, které by tomu dodávaly sémantiku. Nebo lépe úplně nový formát postavený na XML – který by popisoval právě tu sémantiku zprávy – odstavce, odrážky, citace (včetně strojově čitelné identifikace, z jaké zprávy a data/času ta citace pochází), odkazy. A hlavně žádné formátování – barvy, písma a další vizuální věci by se měly řídit nastavením e-mailového klienta příjemce.
Pro e-mail by se hodil nový formát, mohla by to být podmnožina XHTMLTak určitě... to bysme si fuckt děěěsně pomohli.
Já včera konečně zkusil Icedove (Thunderbird) s doplňkem Thunderbird Conversations a nemůžu si to vynachválit. Vypadá to opravdu jak Gmail a funguje to hezky.
Není zač
Tak pro firemni pouziti uz vsichni zmizeli do cloudu...Změna backendu ti jaksi furt neřeší problém s výběrem klienta.
A emaily bez notifikací, to je nepoužitelné. To tak šíleně znepříjemňuje práci, že to ani nejde.To se možná týká jenom lidí co si pletou e-mail a IM.
Tak pokud ten cloud ma jen webovy ksicht.No ale to je taky klient který se musí vybrat.
Spousta lidí tu má v excelu fakt šílenosti s desítkama tisíc řádků, bez kterých to nejde (upravují si různé ceníky, které následně importují do db a používají různé fce a vzorce tak, že to nejde moc lehce nahradit).Jak to řešíte při upgradu na novou verzi MS Office? Tyhle věci mají tendenci se rozpadat jenom když se na ně člověk ošklivě podívá, natož při přechodu mezi verzemi MS Office.
To je jak u nás v práci:
- z informačního systému se otevře excelovská tabulka s několika listy
- vybere se list s tím, co je potřeba, ostatní se smažou
- list se nakopíruje kolikrát je potřeba a očísluje. V listu je hromada výpočtů a maker, jedno tlačítko dokonce (pokud jsem viděl dobře) spustí MS Word, vyplní část stránky textem, vytvoří tabulku, nasype do ní hodnoty, doplní zbytek textu...a uživatel jen klikne na tisk, zavře Word a pokračuje na další list tabulky.
- u tabulky víme jen že se "nesmí překročit cca 150 listů" - ono to sice funguje a jde to uložit, ale Office už to nedokáže otevřít a spadne. Na to samozřejmě zaměstnanci nadávají, protože před rokem se přece vyměnily letité počítače za nové stroje a tohle se nijak nezlepšilo.
Proslýchalo se něco o plánech na automatizaci, ale nejspíš by to fungovalo podobně jako naše čtečka čárových kódů. Ta se chová jako bezdrátová klávesnice, kód "napíše" a odentruje. To by znamenalo, že třeba na dvou-třech PC by obsluha nesměla pracovat a mohla jen přepínat listy ve správnou chvíli, svojí práci by potom museli dělat na dalších počítačích nezapojených do procesu.
Srdce linuxáka pláče
Tomu by se dalo říkat klidně i orgie
Ale mohl by pro zápis používat rozumný jazyk (např. Python) a nevynucovat tabulkovou strukturu.Python je relativně komplikovaný jazyk a rozhodně není moc navržený na psaní vzorců, takže tím většinu potenciálních uživatelů odradíš. Ale to je úplně jedno, protože pokud nebudeš prezentovat tabulkovou strukturu aspoň tak jako v Excelu, odradíš jich většinu tak jako tak.
Určitě by to muselo poskytnout koleje, které by udržely uživatele v architektonicky použitelném uspořádání, ale dal bych mu mocnější GUI toolkit na hraní.Obávám se, že to je zásadní nepochopení, proč mají Excel-style programy takový úspěch.
Já kdysi napsal intranetovou aplikaci ještě v PHP pro jednu firmu – a po letech jsem žasnul, že to stále používají.
Ty neznáš excel?Ne. Nikdy jsem ho nepotřeboval. Že to umí tabulku se vzorečkama, seřadit, obarvit, profiltrovat a nakreslit graf, to vím taky. Ale co s tím vyvádí uživatelé, kteří jiné nástroje neznají?
Ty neznáš excel?
Já taky neznám.
U nás se běžně používají fce jako součty, třídění, matematické operace, logické funkce, slučování, kontingenční tabulky, grafy + ještě pár základních věcí. Některé vzorce jsou i šíleně veliké, ale jde to.
Nikdy jsem pořádně nepochopil, proč lidé, kteří jsou schopni se naučit tento moloch nepoužívají něco jednoduššího a eventuelně i opensource. Co jsem viděl lidi bastlit v Excelu nebo v Calcu, tak ti by neměli problém se naučit SQL, Python, GNUPlot, Rko apod. (Ne nutně všechno.) A místo neustálého placení licencí a problémů mezi verzemi by měli jedno prostředí a ještě k tomu zdarma a mnohem výkonnější. (V době, kdy jsem běžně v SQL počítal statistiku nad miliony záznamů jsem byl šokován, že excel končí u 65535.) A klidně by to mohlo být přímo součástí toho vašeho IS.
65535 bejvávalo, teď už je to nějak přes milion.
Jako já fakt nechci rýpat. Wau, sláva, přes milion. Kolik že to umí běžné DB dneska? Miliardy?
Excel je prostě komplexní nástroj, ve kterém jde hodně rychle udělat pěkný věci a naučí se to i dítě.
Já nevím no, asi nejsem dítě. Kdykoliv si sednu k něčemu jako je tabulkový procesor tak mi z toho lezou hausnumera. Aby z toho lezlo to co má tak se musím fakt soustředit a kontrolovat každý krok. Nedělám si iluze, že to někdo dělá. (Ve skutečnosti vím, že nedělá, protože vím co mi chodí a viděl jsem na vlastní oči, jak Excel někomu podle autooprav změnil cosi na něco jiného a dotyčný si toho ani nevšiml.)
Pro mě je prostě mnohem jednodušší udělat si graf v GNU Plotu (třeba z toho CSV, které předtím vypadlo z nějakého příkazu COPY (SELECT ...); z DB).
Navíc, když se ten SQL dotaz osvědčí tak se dá tak jak je použít přímo v nějakém automatickém skriptu a ty grafy to bude tvořit vlastně zadarmo automaticky. Nechci vidět, jak někdo propojuje excel s nějakým IS a generoval z toho výstup.
Pro mě je prostě mnohem jednodušší...Pro mě zrovnatak, ale nedělám si iluze ohledně drtivé většiny lidí ve firmách...
Lidé ve firmách si nechají zaplatit „školení ekcelu“, kde ten školitel přijde, udělá za ně jejich práci a oni pak zase jen bouchají čísla do připravených formulářů. Takže asi takhle je Excel pružný, přívětivý a použitelný pro běžné uživatele.
Viz #106 – možná je to výhodné pro těch pár konkrétních zaměstnanců a proto takový přístup budou chtít udržet – což ale neznamená, že by to bylo dobré řešení (pro tu firmu nebo obecně).
Nerozporuji, že to tak často funguje – ale to neznamená, že je to tak správně, že je to efektivní a že to podporuje cíle firmy.
Je to asi jako kdyby sis sám poškodil sluch a pak si pochvaloval, jak je to naslouchátko bezva věc a doporučoval ho ostatním. Přitom stačí si ten sluch prostě nepoškodit a žádné naslouchátko nepotřebuješ. Ty firmy/instituce se samy zmrzačily přebujelou byrokracií, nepružností, špatnými procesy, špatnou organizační strukturou…
Mně to spíš přijde, jako přístup: nejdřív dělat, potom myslet. Hned po startu programu vidí uživatel nějakou tabulku do které může bouchat nějaké hodnoty. Pro neznalé je to asi lákavá představa, ale končí to špatně… Ono i u toho krájení nožem se říká: dvakrát měř, jednou řež.
robis analyzu predaja novinky - polozky, lebo sa neocakavane ohlasil dodavatel, ze chce stretnutie a ides ho pritlacit k muru pre nakupku, ides mu ukazat, ako sa na testovacich obchodoch zmenil predaj vzhladom na zmenenu plochu vystavenia. mas 15 min, ides to riesit, cez sql, python a gnuplot? kolko uzivatelov ich pozna?
Pokud to má být rychle upravitelné a pro koncové zákazníky, jsou tu nástroje typu Pentaho, BIRT, Jaspersoft, procesy řízené BPEL atd. Ale hlavně, to že je něco naprogramované, neznamená, že to musí fungovat pořád stejně a jakákoli další změna vyžaduje opět programování – koncový uživatel může upravit konfiguraci nebo ji dokonce naklikat.
Jak už jsem tu psal, tabulkové kalkulátory nějaké využití mají, není to úplně software, který by měl zmizet ze světa, nicméně to použití je dost omezené. A co je vidět často ve firmách/institucích, je nadužívání/zneužívání těchto programů a jejich nasazení k nevhodným účelům.
tu sa rozporujes sam: "nicméně to použití je dost omezené. A co je vidět často ve firmách/institucích, je nadužívání"
Měl jsem na mysli smysluplné využívání. O tom, proč se to nadužívá/zneužívá jsem tu taky někde psal.
plus uzivatel sa nauci iba jeden program a postupne sa v nom zdokonaluje
To rozhodně není plus. Naopak je to mínus a je tu super vendor lock-in. Takový uživatel totiž vůbec neví co dělá, jen ví, na co má kliknout. V případě, že se mu ten jeden nástroj sebere (třeba proto, že vedení úřadu už nechce platit bakšišné Microsoftu), tak je ten uživatel víme kde (resp spíš to vedení, protože úředníků je většinou víc). Naopak, kdyby věděl co dělá, tak to může dělat v čemkoliv.
neriesim vendor lock in, cistotu formatov a pod. biznis je pragmaticka vec. ak by bolo lahsie naucit kancelarsky plankton ine, efektivnejsie, univerzalnejsie nastroje za mensi peniaz a menej casu, firmy by to daly
Zdaleka ne vždy – a ne proto, že by to byla špatná cesta – těch důvodů je hodně: od nekompetentního vedení, přes zaměstnance, jejichž osobní cíle se neshodují s cíli firmy (přesto ji tito zaměstnanci fakticky řídí) nebo uvíznutí v lokálním minimu/maximu (neschopnost/strach ten nejbližší kopec překročit a dostat se někam dál). Na druhé straně mají firmy zkušenost i s tím, že si nějaký zaměstnanec vymyslel projekt, řeklo se, že teď do toho investujeme, bude to nějaký čas trvat a pak se nám to bohatě vrátí… ale nakonec se to nevrátilo a ten zaměstnanec si udělal jen půlroční prázdniny, předstíral činnost a nakonec odešel dřív než se přišlo na to, že jeho výtvor je k ničemu. A k tomu taková ta běžná zkostnatělost a neochota ke změnám. Často se proto spíš stane, že jedna firma zkrachuje a jiná ji nahradí, než aby se firma sama výrazně změnila (procesy, nástroje).
Nevím jak ostatní, ale já excel znám. Vím, co v něm lidi dělají za prasárny (opakuji: za prasárny), znám z toho výstupy apod. To, že ho neznám je spíše jen zbožné přání. Vyhýbám se mu jak to jen jde (a jde to celkem dobře).
A rozhodně není pravda, že excel je jakýsi univerzální komunikační formát pro komunikaci mezi firmami. Za poslední rok jsme rozjeli další bussines, na komunikaci mezi námi a vzdálenou stranou prošlo řádově stovky giga a excel 0. Jakákoliv důležitá komunikace musí mít totiž předem stanovený protokol, který je nutné kontrolovat (xsd apod.). Možná, že ten prokol lze vynutit i v případě excelu, tohle skutečně nevím, ale současně si nemyslím, že by to byl nejvhodnější nástroj pro tuto činnost.
zvládne průměrný uživatel
Já prostě tvrdím, že tentýž uživatel buď zvládne i mnohem lepší nástroje na danou práci a pokud je nezvládne, tak by tu činnost neměl dělat. Protože tu práci i v tom Excelu udělá blbě. Příklady jsem viděl na vlastní oči. Naštěstí se to používá jen u markeťáků, takže na nic důležitého. (Rád bych si tuto iluzi udržel, takže se kroťte s příklady, kdy opravdu na výstupu z excelu záleží. )
Nikdy jsem pořádně nepochopil, proč lidé, kteří jsou schopni se naučit tento moloch nepoužívají něco jednoduššího a eventuelně i opensource. Co jsem viděl lidi bastlit v Excelu nebo v Calcu, tak ti by neměli problém se naučit SQL, Python, GNUPlot, Rko apod. (Ne nutně všechno.) A místo neustálého placení licencí a problémů mezi verzemi by měli jedno prostředí a ještě k tomu zdarma a mnohem výkonnější.
+1
Co jsem viděl lidi bastlit v Excelu nebo v Calcu, tak ti by neměli problém se naučit SQL, Python, GNUPlot, Rko apod.Python nebo R rozhodně nejsou jednoduché. Jaké SQL? SQL pro nějakou konkrétní databázi nebo SQL ze standardu? Na rozdíl od těchto jazyků je Excel jednoduchý čistě funkcionální jazyk (když do toho nepočítáte přiložený Visual Basic for Applications, v němž se píší makra).
A místo neustálého placení licencí a problémů mezi verzemi by měli jedno prostředí a ještě k tomu zdarma a mnohem výkonnější.Problémy mezi verzemi by měli. Např. Python 3 není zpětně kompatibilní s Pythonem 2 nebo konkrétní databáze většinou nedrží zpětnou kompatibilitu.
Jaké SQL? SQL pro nějakou konkrétní databázi nebo SQL ze standardu?
Obojí – nad PostgreSQL. Navíc ten základ je společný napříč všemi relačními SŘBD.
A ten MS Excel je snad nějaký standard? Je to jedna konkrétní aplikace, navíc proprietární.
Na rozdíl od těchto jazyků je Excel jednoduchý čistě funkcionální jazyk
SQL je krásný deklarativní jazyk – uživatel jen řekne, co chce, nemusí řešit, jak toho dosáhnout – o to se postará počítač. Navíc SQL důsledně odděluje data a jejich prezentaci, takže vede k čistějšímu návrhu.
Problémy mezi verzemi by měli. Např. Python 3 není zpětně kompatibilní s Pythonem 2
Tak si místo Pythonu dosaď Javu – program psaný pro 5 ti bude fungovat na 8. Dokonce i programy pro starší verze ti budou fungovat na 8, pokud nemáš tu smůlu, že jsi použil enum
pro název proměnné (v 5 se z něj stalo klíčové slovo).
A ani u toho Pythonu to není tak horké – z 2 na 3 nebude nikdo přecházet jen tak mimochodem nebo omylem, aby z toho byl pak překvapený. Nejsem pythonista, ale pro usnadnění přechodu nějaké nástroje jsou…
nebo konkrétní databáze většinou nedrží zpětnou kompatibilitu.
Tohle je už vůbec blud – dobré relační databáze si na zpětné kompatibilitě zakládají asi jako ta Java.
Navíc ten základ je společný napříč všemi relačními SŘBD.To není pravda. Například prázdný řetězec se v Oracle považuje za NULL a v ostatních databázích nikoliv.
Tohle je už vůbec blud – dobré relační databáze si na zpětné kompatibilitě zakládají asi jako ta Java.Mám tomu rozumět tak, že PostgreSQL není dobrá relační databáze? Vždyť i tam některé věci zastarají a jsou odstraněny. Například operátor
=>
pro hstore byl odstraněn ve verzi 9.2.
SQL je krásný deklarativní jazyk – uživatel jen řekne, co chce, nemusí řešit, jak toho dosáhnout – o to se postará počítač.I
INSERT
a UPDATE
jsou deklarativní?
Nebo, když napíši
x := 3; x := x + 1; writeln(x);tak vlastně říkám jen, co chci, a nemusím řešit, jak toho dosáhnout (např. nemusím vědět, jak ve skutečnosti funguje vypisování na terminál nebo řešit, aby se na zásobníku alokovalo
x
). Takže to vypadá, že Turbo Pascal je deklarativní.
x := x + 1
Můžeš mi vysvětlit, jak bys toto interpretoval jako deklarativní?
Můžeš mi vysvětlit, jak bys toto interpretoval jako deklarativní?Používám definici deklarativního jazyka, co dal xkucf03:
uživatel jen řekne, co chce, nemusí řešit, jak toho dosáhnoutPříkaz
x := x + 1vyjadřuje, že chci do proměnné
x
přiřadit o jedna vyšší hodnotu (v modulární aritmetice), než tam byla. Podle definice jsem tedy řekl, co chci, a neřešil jsem, jak toho dosáhnout. Tj. neřeším, na jaké architektuře program běží, jaké instrukce se k tomu musí použít, zda program potřebuje nějakou paměť.
Problém je ve vágnosti té definice.
Lepší definice je, že v deklarativním jazyce nejde přiřazovat do proměnných – není tam přiřazovací příkaz. Cituji ze zápisku Roberta Harpera There Is Such A Thing As A Declarative Language, and It’s The World’s Best DSL:
My contention is that variables, properly so-called, are what distinguish “declarative” languages from “imperative” languages. Although the imperative languages, including all popular object-oriented languages, are based on a concept that is called a variable, they lack anything that actually is a variable. And this is where the trouble begins, and the need for the problematic distinction arises. The declarative concept of a variable is the mathematical concept of an unknown that is given meaning by substitution. The imperative concept of a variable, arising from low-level machine models, is instead given meaning by assignment (mutation), and, by a kind of a notational pun, allowed to appear in expressions in a way that resembles that of a proper variable. But the concepts are so fundamentally different, that I argue in PFPL that the imperative concept be called an “assignable”, which is more descriptive, rather than “variable”, whose privileged status should be emphasized, not obscured.
Pleteš si PL*/SQL a SQL. To jsou úplně jiné jazyky. A ano, takové PL v Oraclu je fakt něco na úrovni Pascalu nebo Cobolu.
DECLARE
i SET
.
Stále myslíte, že SQL je deklarativní?
To je rozšíření (deklarativního) SQL o procedurální jazyk.
INSERT
, UPDATE
a DELETE
, tyto jsou podle vaší definice deklarativní? Je změna proměnné deklarativní? Jaký je rozdíl mezi změnnou proměnné a změnou tabulky?
Dobře, můžeme tedy uvažovat pouze Core SQL. Tam patří mj. INSERT, UPDATE a DELETE, tyto jsou podle vaší definice deklarativní?
Tím říkám, že chci upravit množinu dat a deklaruji jakou změnu chci (z byznys pohledu), nikoli, jak této změny dosáhnout (z technického pohledu – iterace, IFy, pomocné proměnné atd.). Tzn. např. řeknu, že chci změnit stav objednávky 1234 na „doručeno“, ale neříkám: projdi v cyklu všechny objednávky (postupně načti z disku do paměti) a pokud se atribut ID = 1234, tak záznam uprav v paměti a pak zapiš na disk.
Je změna proměnné deklarativní? Jaký je rozdíl mezi změnnou proměnné a změnou tabulky?
Pokud by v tom rozdíl nebyl, tak by asi žádný deklarativní jazyk nemohl existovat a tenhle pojem by nedával smysl.
Tabulky obsahují čistá data, patří uživateli a jsou vlastně důvodem, proč ten systém používá. Je to vstup případně výstup programu. Kdežto proměnná je součástí programu, je kdesi uvnitř a uživatele nezajímá, proměnná je implementační detail.
Obecně to „deklarativní“ vidím takhle:
[deklarativní předpis] ↓ [vstup] → [běhové prostředí] → [výstup]
Tzn. uživatel řekne, co chce dostat na výstupu, a o zbytek se postará běhové prostředí (uvnitř něj se samozřejmě nějaké proměnné, cykly, IFy a další věci používají, ale uživatel je od toho odstíněn).
Musíš si ho spustit v hlavě během jeho čtení.
SELECT 1 + 3 * 7 - 8 / (7 / 2) * 3 - -7si nespustíte v hlavě, abyste zjistil, co dělá? Nebo nějaký delší SQL dotaz?
projdi v cyklu všechny objednávky (postupně načti z disku do paměti) a pokud se atribut ID = 1234, tak záznam uprav v paměti a pak zapiš na diskProč myslíte, že neříkáte projdi v cyklu všechny objednávky (postupně načti z disku do paměti) a pokud se atribut ID = 1234, tak záznam uprav v paměti a pak zapiš na disk? Já si myslím, že to říkáte. To, že se to ve skutečnosti může odehrát jinak, je pouze implementační detail. Podobně jako v C++, když napíšete cyklus a kompilátor vygeneruje kód, který dává stejné výsledky, ale uvnitř pracuje jinak. Ve skutečnosti tedy ani v C++ neříkáte, jak se to má dělat, jak přesně toho dosáhnout. Pro každý jazyk můžeme vytvořit operační i denotační sémantiku. Například SQL mohu přiřadit operační sémantiku, kde
SELECT ... FROM ... WHERE ...
přeložím na cyklus s vnořeným ifem. Naopak C++ mohu přiřadit denotační sémantiku, která neřeší, jak se co spočítá, ale řeší pouze to, jaké výstupy program přiřazuje daným vstupům.
Tabulky obsahují čistá data, patří uživateli a jsou vlastně důvodem, proč ten systém používá. Je to vstup případně výstup programu. Kdežto proměnná je součástí programu, je kdesi uvnitř a uživatele nezajímá, proměnná je implementační detail.I tabulky mohou být pomocné. Program
x := 0; x := x + 1; writeln(x);mohu přepsat do SQL takto
CREATE TABLE Vars( Name VARCHAR(8) NOT NULL, Val INT NOT NULL, ); INSERT INTO Vars (Name, Val) VALUES ('x', 0); UPDATE Vars SET Val = Val + 1 WHERE Name = 'x'; SELECT Val FROM Vars WHERE Name = 'x'; DROP TABLE Vars;
Tzn. uživatel řekne, co chce dostat na výstupu, a o zbytek se postará běhové prostředíTakto funguje většina programovacích jazyků. Nějak popíšete, co chcete na výstupu a o zbytek se postará kompilátor nebo běhové prostředí.
Proč myslíte, že neříkáte projdi v cyklu všechny objednávky (postupně načti z disku do paměti) a pokud se atribut ID = 1234, tak záznam uprav v paměti a pak zapiš na disk? Já si myslím, že to říkáte.Protože u deklarativních jazyků (nebo, raději se držme SQL, nejsem teoretik informatiky) nikdy nevíte jak konkrétně se ten daný dotaz vykoná. Záleží to na mnoha faktorech. Kolik je tam dat. Jaká jsou to data (statistiky). Jsou k disposici indexy a jaké. Co je momentálně v cache. Jaké další dotazy běží. Slušný DB systém si vypracuje možné prováděcí plány a na základě aktuálních podmínek vybere ten nejlepší (nebo se o to alespoň snaží ). To znamená, že stejný dotaz může být realizován mnoha různými způsoby a ty způsoby se mění v čase. To má hodně daleko od toho, jestli zrovna kompilátor rozbalí smyčku nebo ne. Ten kompilovaný kód už se potom nemění v závislosti na datech. A to ani u JIT nebo interpretů.
Záleží to na mnoha faktorech. Kolik je tam dat. Jaká jsou to data (statistiky). Jsou k disposici indexy a jaké. Co je momentálně v cache. Jaké další dotazy běží. Slušný DB systém si vypracuje možné prováděcí plány a na základě aktuálních podmínek vybere ten nejlepší (nebo se o to alespoň snaží ).Některé kompilátory umí profilováním řízené optimalizace. V profileru si vypracujete statistiky, čím program tráví nejvíce času, a podle toho se provedou optimalizace.
To má hodně daleko od toho, jestli zrovna kompilátor rozbalí smyčku nebo ne.Nejenom.
Ten kompilovaný kód už se potom nemění v závislosti na datech. A to ani u JIT nebo interpretů.HotSpot to dělá, říká se tomu deoptimalizace:
Deoptimization is the process of changing an optimized stack frame to an unoptimized one. With respect to compiled methods, it is also the process of throwing away code with invalid optimistic optimizations, and replacing it by less-optimized, more robust code. A method may in principle be deoptimized dozens of times.
Deklarativnost by měla jít poznat ze specifikace jazyka.
To u SQL podle mě platí. V dotazu popíšu jak vypadají data která chci vrátit. Nepopisuji jakým způsobem. Nemám nástroj na to, jak říct otevři soubor ten a ten a vrať mi data z nějakého offsetu (i když třeba vím, že to ta DB tak stejně udělá, protože ta data jsou větší než cache v ram). To, jakým způsobem to proběhne uvnitř mě vlastně nezajímá (pokud zrovna nedělám optimalizaci schématu).
Některé kompilátory umí profilováním řízené optimalizace.
Ano, ale to je stále optimalizace statická, kdy na nějakém vzorku dat nechám ten program běžet a podle toho se optimalizuje. DB dělá dva různé prováděcí plány pro tentýž dotaz. Jen se liší data. Pokud se ptám na data, která mají selektivitu 50% (každý druhý řádek spadne do result setu), tak je mnohem lepší full table scan. Pokud se ptám data data stejným dotazem na stejnou tabulku se selektivitou menší než nějaký práh, tak je výhodnější použít index. Toto pokud vím žádný optimalizátor imperativního jazyka neumí.
HotSpot to dělá, říká se tomu deoptimalizace:
Pokud jsem to správně pochopil, tak ten to dělá až zpětně, pokud zjistí, že vykonává nějakého kódu je méně optimální. Výběr plánu u DB se provádí dopředu na základě statistik dat. (Ano, teď asi přijde odpověď že ten plánovač to taky dělá na základě rychlosti jednotlivých metod, které se musely dopředu nějak zjistit. Ale opět mi přijde že je to mimo možnosti výrových prostředků SQL.)
V dotazu popíšu jak vypadají data která chci vrátit.To děláte v každém jazyce, když uvažujete jeho denotační sémantiku. Tohle tedy není specifické pro dotaz v SQL nebo "čistý" Prolog. Tohle tvrzení můžete prohlásit i o C++, pro jednoduchost však nabízím učebnicový imperativní jazyk zvaný IMP a jeho denotační sémantiku. Mj. hned v prvním odstavci je
As opposed to operational models, which tell us how programs execute, the denotational model shows us what programs compute.
Nemám nástroj na to, jak říct otevři soubor ten a ten a vrať mi data z nějakého offsetuAno, v programovacích jazycích obvykle nemáte nástroje k řízení všeho. Někde máte těch nástrojů více (např. C) někde o něco méně (např. Java, C#, OCaml) a někde ještě méně (např. různé doménově specifické jazyky – třeba SQL, Minitab, IMP). Ale to přeci neznamená, že ten jazyk je deklarativní? Nebo, kdybych do SQL přidal funkce pro čtení dat ze souborů, tak už by SQL přestalo být deklarativní?
Tak si místo Pythonu dosaď Javu – program psaný pro 5 ti bude fungovat na 8. Dokonce i programy pro starší verze ti budou fungovat na 8, pokud nemáš tu smůlu, že jsi použil enum pro název proměnné (v 5 se z něj stalo klíčové slovo).Myslíte tedy, že Java je adekvátní náhrada Excelu?
A ani u toho Pythonu to není tak horké – z 2 na 3 nebude nikdo přecházet jen tak mimochodem nebo omylem, aby z toho byl pak překvapený.Python 2 bude podporován navěky?
Python 2 bude podporován navěky?
Evidentně je podporován déle než jedna konkrétní verze Excelu. Navěky není nic.
SQL je krásný deklarativní jazykNo tak to teda není ani blbou náhodou. Copak snad nezačíná skoro každý příkaz slovesem? (
SELECT
, INSERT
, ...). SQL mi přijde těžce imperativní. To by musela být hodně zvláštní definice deklarativního jazyka, aby se do něj nahečmal jazyk, který se v podstatě výlučně skládá z příkazů, co se má v dané chvíli udělat.
Jde o to, že mu nemusíš říkat věci typu:
Jenže tady to není funkce, ale součást jazyka, princip, na kterém jeho syntaxe stojí.
WHERE
clauses a další prvky SQL deklarativní (asi) jsou, ale celkově je práce s SQL databází IMHO téměř úplně imperativní záležitost. Když chceš, aby byla data persistentní, nestačí deklarovat vlastnosti persistence, musíš procedurálně zadávat SQL příkazy.
Další věcí jsou vztahy mezi tabulkami - jediné, co SQL v tomhle ohledu poskytuje, je cizí klíč, všechny vztahy (one-to-many, many-to-many, stromy, atd. atd.) si nad tím musíš udržovat nějak sám, což často vyžaduje triggery (tj. procedurální kód) a/nebo obslužnou vrstvu (tj. procedurální kód).
one-to-many, many-to-many, stromy, atd. atd.
1:n a m:n jsou normální cizí klíče. Strom v zásadě taky, jde jen o to, jak dobře je daný databázový systém umí indexovat (po tom, co nějak deklaruješ, že to je strom).
což často vyžaduje triggery (tj. procedurální kód) a/nebo obslužnou vrstvu (tj. procedurální kód).
A často je nevyžaduje. Pak tu jsou i CHECK omezení, kterými se dá ledasco nadeklarovat.
a/nebo obslužnou vrstvu (tj. procedurální kód).
Z vlastní zkušenosti můžu říct, že tohle „procedurálno“ v databázi je lepší minimalizovat. Ne úplně odbourat, někdy je to fakt užitečné, ale není dobré to přehánět a všechno obalovat do procedur. Přeci jen tabulka, ze které se dá SELECTovat a do které jde INSERTovat, je jedno z nejlepších API vůbec.
P.S. 100% deklarativnost je asi nedosažitelná, ale svět relačních databází v tomhle celkem vyniká nad ostatními prostředími a já to beru velice pozitivně.
1:n a m:n jsou normální cizí klíčeCizí klíč je spíš primitivum, pomocí kterého se těhle vztahů dá dosáhnout, ale realizovat ten vztah musíš víceméně ručně - tj. vytvořit příslušné sloupce nebo pomocné tabulky, příslušná omezení, atd.
Přeci jen tabulka, ze které se dá SELECTovat a do které jde INSERTovat, je jedno z nejlepších API vůbec.Hm, já tohle moc nemam rád. Například Android šel v některých částech tímhle směrem (příklad) a nijak odvařenej jsem z toho nebyl, kód pak šíleně bobtná a musíš řešit věci, které bys s 'normálním' API řešit nemusel - tj. přístup do DB, psaní queries, používání více tabulek je PITA, apod...
Pokud máš ORM nebo mapovač řádek (to si nastavíš/napíšeš jednou a pak jen používáš), tak je to fajn – máš silný dotazovací jazyk a výsledek už dostáváš jako objekty. Psát si ručně a pokaždé znova mapování mezi relacemi a objekty je opruz, to souhlas, ale to už se moc často nedělá, ne?
Je to prototypovací nástroj pro analytiky a silně neefektivní pro "programování" sofistikovaných aplikací. Asi jako kdybych si byl línejjít do obchodu koupit pračku a pral v neckách.Nebo bychom si alespoň moc přáli, aby to tak bylo.
Tak tak, excel je někdy nenahraditelný.Osobně bych neřekl, že je technicky nenahraditelný. Ani si nejsem jistý, zda ten software plní danou úlohu úplně dobře. Ale rozhodně je zavedený a víceméně splňuje základní předpoklady pro takové nasazení. Já osobně bych si uměl představit mnohem lepší software, který by víc vyhovoval nejen mně, ale podle mého skromného názoru i velké části těch méně technických lidí. Když se dívám, jak se software pracují lidé, kteří si v něm nejsou úplně jistí, tak mám pocit, že k nim mám často daleko blíž než pokročilý uživatel. Vysvětluju si to tím, že moje specializace se s pokročilým užíváním Windows/Office příliš nepřekrývá.
Jejich problém spočívá třeba v tom, že přijdou o práci, protože v současnosti vykonávají naprosto zbytečnou činnost. To mi připomíná jednu úřednici, která mi vysvětlovala, co dělá, byla do toho strašně zažraná a měla tu evidenci dost zmáknutou… ale celé to bylo na nic, nebylo to k ničemu užitečné.
Jejich problém spočívá třeba v tom, že přijdou o práci, protože v současnosti vykonávají naprosto zbytečnou činnost.Nevím, proč prozrazuješ pointu bez jakékoli přidané hodnoty.
Je to specifické pro MS Excel nebo obecně platné pro tabulkové kalkulátory?
Upřímně, neznám schopnosti našeho IT člověka. Všichni mají naloženo tolik práce, že sotva stíhají dělat svoji práci. A někdo nový...i kdyby prošel sítem, tak ho zarazí plat a radši půjde sedět na úřad práce a dělat open source projekty. Možná by na tom vydělal víc, než kdyby chodil do práce a ne malou část výplaty utratil za dopravu.
To jsme v práci taky měli, ale alespoň se někteří kolegové naučili dokumenty průběžně ukládat
S big excelama většinou dělají zkušení lidé, ale tam snad žádná nekompatibilita nehrozí, resp. né taková, která by zapříčinila nějaký problém.Vyrobil jsem jednoduchou tabulku, kde je pár výpočtů a podmíněného formátování, a s verzí 2010 vše funguje správně, ale kolega s verzí 2007 s tím nemůže pracovat (tabulka se zobrazí, ale něco je tam špatně, nepamatuji si přesně co). Takže i takovéhle nekompatibility existují. A to je ta tabulka opravdu dost jednoduchá.
Na to se dá říct jediné: uživatelé MS produktů jsou masochisti a trestají sami sebe.
je mi úplně putna, zda dělám pod win7, nebo win8
Já taky nejsem žádný rasista, pro mě cikán jak černoch :-)
...znám lidi, kteří takové změny nesnášejí. To platí i třeba pro nové rozhraní Firefoxu bez horní nabídky,...Jsem jeden z nich. Kvůli tomu jsem přešel na IceApe a mohu normálně fungovat.
Ne, šlo mi o tu onanii s aktivací po síti a obecně licencemi a zotročování uživatelů. Zobecnit by to šlo leda na proprietární software.
Zda dávají smysl kancelářské aplikace, to je zase na jinou diskusi. Nejsem jejich příznivcem, ale obecně bych je nezavrhoval – dávají smysl pro ad-hoc činnosti, např. když potřebuji napsat jeden dopis, vytisknout jednu ceduli, sečíst deset čísel pod sebou… Ale jakmile se stanou součástí procesu, opakovanou činností, tak je něco špatně.a
Ale jakmile se stanou součástí procesu, opakovanou činností, tak je něco špatně.To ale nedává smysl. Někdy člověk používá různé nástroje podle náročnosti úlohy. Ale většinou se snaží pracovat v tom, co zná, případně se učit to, co mu bude nejužitečnější.
ale právě v univerzalitě.
To dává smysl, pokud to jsou ty ad-hoc činnosti, pokaždé něco jiného. Ale když je to proces, opakovaná posloupnost činností, tak je lepší to podchytit nějakým jiným softwarem, informačním systémem, automatizovat to.
a vyžaduje to součinnost dalších lidí
To vyžadují i mnohem přízemnější činnosti jako třeba uklízení, pokud ti zaměstnanci nemají sami utírat prach, luxovat a mýt podlahu na záchodě. Totéž vaření oběda, doprava, výroba oblečení, nábytku… Dělba práce je celkem normální věc (jasně, jsou tu DIY nadšenci, ale jejich motivace je obvykle jiná).
Software má výhodu v tom, že ho napíšeš jednou a jeho následné opakované spouštění tě už nic nestojí. Jsou tam nějaké fixní náklady, ale ty varibialní se blíží nule. Proto to pro opakované činnosti bývá lepší cesta.
To vyžadují i mnohem přízemnější činnosti jako třeba uklízení, pokud ti zaměstnanci nemají sami utírat prach, luxovat a mýt podlahu na záchodě.1) Úklid firmy je odlišný v tom, že je to dlouhodobý plán, nikoli adaptace konkrétní situaci, v tom je podobný spíše nákupu jednotného software a vytvoření jednotného plánu školení pro celou firmu, tedy tomu nenáviděnému Excelu. 2) Co vím, tak se dnešní trochu větší firmy úklidem kanceláří často nezabývají, stejně jako se nezabývají obsazením vrátnice a zajištěním bezpečnosti. To všechno dostanou jako službu společně se smlouvou na užívání prostor. Zbytek tvého příspěvku ani nesouvisí s tím, co jsem psal.
Ne, nepřestaneme MS Office používat. Spousta lidí tu má v excelu fakt šílenosti s desítkama tisíc řádků, bez kterých to nejde (upravují si různé ceníky, které následně importují do db a používají různé fce a vzorce tak, že to nejde moc lehce nahradit).Jsi mi připoměl diskuzi na redditu, ze které se mi pořád ještě ježí vlasy hrůzou.
Pořád jde ale o chybu uživatele, nikoli outlooku.Tady bych to viděl padesát na padesát. Outlook by na to mohl nějakým způsobem umět upozornit, když to umí i Thunderbird, stačilo by to okoukat.
Osobně mám pocit, že spousta lidí stále řeší opravu dat místo toho, aby řešili obnovu zálohy.Ano, je to tak. Jsou firmy, které šetří na své infrastruktuře a pak brečí, když se dostanou do průšvihu. Mne osobně je to jedno, já si ty jejich průsery nechám zaplatit. Někde jsem to tu i psal. Třeba přecházejí k bezplatnému Avastu pro podnikání. A nevysvětlíš, že šetří na špatném místě. Když to zdůrazníš razantněji, tak se ještě urazí.
Po zkušenostech s několika placenými "enterprise" mrdkami  Tomu říkám nevhodně zvolené řešení. Zřejmě to volil nějaký manager, který s tím nemusel nikdy pracovat a neměl s tím žádné problémy.
Chápu lidi, co na to skočí, leč nemají potom v ruce vůbec nic. Protože u free verze se pochopitelně vzdají veškeré odpovědnosti, takže když přes tu jejich free verzi odtečou nějaká důležitá data a následně někdo připraví firmu o pěknou zakázku, jak to asi skončí?Pobavils. Prosímtě, přečti si EULA k těm komerčním produktům. Zejm. pak ty mnohastránkové disclaimery. S řešením za desítky tisíc dolarů budeš mít v ruce stejný hovno, jako s Avastem za 0Kč.
Můžeš si vyjednat i vlastní podmínky.Tak určitě... a pak se v USA soudit. To bude rozhodně nadějné a vyplatí se to.
Myslím, že na to byla reklama v metru…
Tiskni Sdílej: