Waydroid (Wikipedie, GitHub) byl vydán v nové verzi 1.6.0. Waydroid umožňuje spouštět aplikace pro Android na běžných linuxových distribucích. Běhové prostředí vychází z LineageOS.
Příspěvek na blogu Raspberry Pi představuje novou kompletně přepracovanou verzi 2.0 aplikace Raspberry Pi Imager (YouTube) pro stažení, nakonfigurování a zapsání obrazu operačního systému pro Raspberry Pi na SD kartu. Z novinek lze vypíchnout volitelnou konfiguraci Raspberry Pi Connect.
Memtest86+ (Wikipedie), svobodný nástroj pro kontrolu operační paměti, byl vydán ve verzi 8.00. Přináší podporu nejnovějších procesorů Intel a AMD nebo také tmavý režim.
Programovací jazyk Racket (Wikipedie), tj. jazyk z rodiny jazyků Lisp a potomek jazyka Scheme, byl vydán v nové major verzi 9.0. Hlavní novinku jsou paralelní vlákna (Parallel Threads).
Před šesti týdny bylo oznámeno, že Qualcomm kupuje Arduino. Minulý týden byly na stránkách Arduina aktualizovány podmínky používání a zásady ochrany osobních údajů. Objevily se obavy, že by otevřená povaha Arduina mohla být ohrožena. Arduino ubezpečuje, že se nic nemění a například omezení reverzního inženýrství v podmínkách používání se týká pouze SaaS cloudové aplikace.
Knihovna libpng, tj. oficiální referenční knihovna grafického formátu PNG (Portable Network Graphics), byla vydána ve verzi 1.6.51. Opraveny jsou 4 bezpečnostní chyby obsaženy ve verzích 1.6.0 (vydána 14. února 2013) až 1.6.50. Nejvážnější z chyb CVE-2025-65018 může vést ke spuštění libovolného kódu.
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 159 (pdf).
Hru Warhammer: Vermintide 2 (ProtonDB) lze na Steamu získat zdarma napořád, když aktivaci provedete do pondělí 24. listopadu.
Virtualizační software Xen (Wikipedie) byl vydán v nové verzi 4.21. Podrobnosti v poznámkách k vydání a přehledu nových vlastností.
Evropská komise schválila český plán na poskytnutí státní pomoci v objemu 450 milionů eur (téměř 11 miliard Kč) na rozšíření výroby amerického producenta polovodičů onsemi v Rožnově pod Radhoštěm. Komise o tom informovala v dnešní tiskové zprávě. Společnost onsemi by podle ní do nového závodu v Rožnově pod Radhoštěm měla investovat 1,64 miliardy eur (téměř 40 miliard Kč).
Řekli byste o sobě, že umíte programovat?
| ano |
|
32% (614) |
| tak trochu/učím se |
|
38% (734) |
| ne, ale budu se učit |
|
7% (128) |
| ne |
|
23% (442) |
Celkem 1918 hlasů
Vytvořeno: 26.10.2008 21:53
Tiskni
Sdílej:
(z toho plyne: znám málo lidí 
)
To já mám kolem sebe tolik lidí, co to umějí nesrovnatelně líp, že jestli o tom budu ještě chvilku přemýšlet, popadne mě strašlivý pocit méněcennosti a nezbude mi, než nasednout do výtahu a jít si depresit k BlueBearovi
26.10.2008 22:26
kozzi | skóre: 55
| blog: vse_o_vsem
| Pacman (Bratrušov)
26.10.2008 22:31
David Watzke | skóre: 74
| blog: Blog...
| Praha
26.10.2008 22:41
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
(to byla ironie - neni)
28.10.2008 14:58
vencour | skóre: 56
| blog: Tady je Vencourovo
| Praha+západní Čechy
Jéé, někdo má rád Morgensterna? Meč šaršoun, Pentlochňap, prostě nádhernajs
28.10.2008 15:22
vencour | skóre: 56
| blog: Tady je Vencourovo
| Praha+západní Čechy
Joj, Alenka, tak tu jsem nečet, zatim. Dík za opravení.
28.10.2008 18:59
stybla | skóre: 29
| Praha
A co se tyce tech penez (take nemam tolik, ale vim, ze to mozne je, pokud mate spravne CV) je to podobne - mam nekdy pocit, ze cim mene uzitecnejsi praci clovek dela, tim lepe je za to placen (pritom, laik by rekl, ze ta prace musi byt opravdu hodne slozita, kdyz za ni nekdo dostava tolik penez).Souhlasim. Ale myslim si, ze na to brzo prijdeme a treba se ty platy otoci nebo vyrovnaji, a nebo treba ne. Levne pracovni sily je zatim dost. Co se nekvalifikovane prace tyce, tak bych rekl, ze lide dost zpohodlneli. Take casove naroky v zamestnani jsou trochu jine nez byvaly. No, asi to hraje jedno s druhym.
28.10.2008 19:26
stybla | skóre: 29
| Praha
Otazkou je, proc by nekdo studoval 5 let (optimisticky) nejakou VS, a pak delal zamecnika nebo klempire. Bohatstvi tam ocividne nehrozi.Někde jsem nedávno četl (nebylo to tady?), že pražské hotely mají problémy obsadit místa cukrářů a to i když nabízí plat ve výši sto tisíc korun.
29.10.2008 22:57
egg | skóre: 20
| Praha
30.10.2008 16:00
robotics | skóre: 29
| blog: o_vsem_moznem
30.10.2008 16:13
stybla | skóre: 29
| Praha
Nejsu učitel ale je to špatný jak je to placený. Stačí se podívat kolik mají placeno sekretářky ve státní správě.Platy ve statni sprave jsou afaik tabulkove a odvozene od dosazeneho vzdelani a praxe.
27.10.2008 01:22
hankey | skóre: 16
30.10.2008 20:46
regine | skóre: 22
| blog: regine
Navíc dnes, pokud se jedná o profesionální přístup s analytickými nástroji atd., se spíše jedná o generování kódů - jinak nejste konkurence schopní a okolní konkurence vás smete.
31.10.2008 20:37
xkucf03 | skóre: 49
| blog: xkucf03
Když už se tyhle nástroje používají, tak proto, aby tě zbavily tupé stereotypní práce, opisování stále stejných konstrukcí kódu (které by do texťáku dokázala bušit i opice), a zbylo ti víc práce na vymyšlení hierarchie tříd nebo datového modelu, případně psaní geniálních algoritmů (místo abys zabíjel čas opisováním koster tříd z modelu do zdrojáku).
29.10.2008 10:24
vain | skóre: 16
nebo ještě lépe považujete za programátora toho, kdo dělá v PHP?
Takhle se dost dobře ptát nejde. Řada lidí, kteří píší (ať už také nebo výhradně) v PHP bezesporu programátoři jsou. Na druhou stranu je řada lidí, kteří sice píší v "plnohodnotném" jazyce, ale označit je za programátory bych se zdráhal.
HTML budiž, ale PHP není o nic méně programovací jazyk než třeba céčko.Tak to prrrr. V php už chvíli nedělám, ale co vím, tak php se tvůrce vůbec nemusí starat o pamět, pointery atd. A mám dojem, že většina php 'programátorů' si jen matně vybavuje význam slova optimalizace.
29.10.2008 20:25
stybla | skóre: 29
| Praha
A mám dojem, že většina php 'programátorů' si jen matně vybavuje význam slova optimalizace.Ja bych rekl, ze vetsina lidi tento pojem ani nezna. Nicmene jak to souvisi s PHP, to netusim - krom netypovosti. Ale to je "featura" jazyka, kterou jen tezko nekdo zmeni.
Tak to prrrr. V php už chvíli nedělám, ale co vím, tak php se tvůrce vůbec nemusí starat o pamět, pointery atd.A kvůli tomu to není programovací jazyk a jeho uživatel není programátor? Nenechte se vysmát
A to jestli se jazyk překládá, nebo ne do nativního kódu přece vůbec nezáleží na jazyku, ale na tom jestli si někdo dá tu práci a ten interpretr pro ten jazyk napíše.
(...) ono jaksi z podstaty věci všechno skončí jako ta příslovečná nudle nul a jedniček, ale podstatné je, že to programátora nemusí zajímat.Koho tohle nezajímá, není u mě programátor. To si jako myslíš, že se naprogramuje pár hostovejch aplikací pro který budou všichni psát skripty? To je teda pěkne blbej nápad...
Skripty, skripty… jaké pořád skripty? Považujete třeba software v Javě za skripty a JVM za hostitelskou aplikaci? Existují jazyky, které nemají vlastnosti, které jsem o kousek výše zatratil, a kupodivu jsou taky dost blízko k hardwaru (ne, Javu nemyslím(...) ono jaksi z podstaty věci všechno skončí jako ta příslovečná nudle nul a jedniček, ale podstatné je, že to programátora nemusí zajímat.Koho tohle nezajímá, není u mě programátor. To si jako myslíš, že se naprogramuje pár hostovejch aplikací pro který budou všichni psát skripty? To je teda pěkne blbej nápad...
, ale to je jiná pohádka). Je to všechno o dostatečné úrovni abstrakce. A třeba tu ruční správa paměti, tu vážně potřebuje jenom minimum programátorů.
Že to lidi nezajímá je samozřejmě škoda. Ale je velmi důležité, aby je to nemuselo zajímat. Třeba já jsem si s chutí přečetl něco o technikách automatické správy paměti, moc zajímavé téma, ale podstatné je, že při programování na to můžu s klidem zapomenout a nic se nestane. V hlavě potřebuju udržet jiné věci než ty, o které se za mne může postarat stroj.
Obecně si troufám tvrdit, že implementace programovacích jazyků jsou, díky mohutnému teoretickému aparátu (zase ty techniky GC, ty např. existují a vyvíjejí se od nějakých 50. nebo 60. let!), velice imunní vůči fenoménu prosakující abstrakce, takže výhody jasně převažují nad problémy, které se přece jen občas objevují.
Skripty, skripty… jaké pořád skripty? Považujete třeba software v Javě za skripty a JVM za hostitelskou aplikaci?Jo.
Existují jazyky, které nemají vlastnosti, které jsem o kousek výše zatratil, a kupodivu jsou taky dost blízko k hardwaru (ne, Javu nemyslímHm, které máte na mysli? Jen by mě to zajímalo...
Je to všechno o dostatečné úrovni abstrakce. A třeba tu ruční správa paměti, tu vážně potřebuje jenom minimum programátorů. Že to lidi nezajímá je samozřejmě škoda. Ale je velmi důležité, aby je to nemuselo zajímat. Třeba já jsem si s chutí přečetl něco o technikách automatické správy paměti, moc zajímavé téma, ale podstatné je, že při programování na to můžu s klidem zapomenout a nic se nestane. V hlavě potřebuju udržet jiné věci než ty, o které se za mne může postarat stroj.Ale v čem je ten benefit? Co z automatický správy paměti budu mít a jak to prospěje mému výtvoru? Vždyť když si pamět budu spravovat sám, můžu to přizpůsobit mýmu programu na míru...
Obecně si troufám tvrdit, že implementace programovacích jazyků jsou, díky mohutnému teoretickému aparátu (zase ty techniky GC, ty např. existují a vyvíjejí se od nějakých 50. nebo 60. let!), velice imunní vůči fenoménu prosakující abstrakce, takže výhody jasně převažují nad problémy, které se přece jen občas objevují.Ale jo, ale je potřeba použít správné řešení na správném místě. Jistěžě skriptovací jazyky maji spoustu důležitých uplatnění, kde se jejich výhody projeví, ale neměly by nahradit nativní programování - 'běžné programy' pro PC, a to hlavně ty větší, kde je potřeba výkon.
Dost radikální. Hlavně vzhledem tomu, co moderní JVM dělají za kouzla. Třeba takové zrušení zámku, pokud lze dokázat, že není potřeba, to asi v Céčkovém programu s POSIXovými vlákny nenajdeteSkripty, skripty… jaké pořád skripty? Považujete třeba software v Javě za skripty a JVM za hostitelskou aplikaci?Jo.
Ále, takové ty funkcionální mrchyExistují jazyky, které nemají vlastnosti, které jsem o kousek výše zatratil, a kupodivu jsou taky dost blízko k hardwaru (ne, Javu nemyslímHm, které máte na mysli? Jen by mě to zajímalo...
Erlang třeba.
V tom, že z myšlenky bude výtvor dříve, že prakticky odpadne určitá třída problémů (třeba tolik oblíbené memory leaky – ne že by v jazycích, nebo spíš platformách, s automatickou správou paměti neexistovaly, ale tam už je to o něčem trochu jiném), a vůbec takové ty buzynes argumenty, na které geekové neradi slyší. Já na ně občas taky nerad slyším, ale taková je holt realita.Je to všechno o dostatečné úrovni abstrakce. A třeba tu ruční správa paměti, tu vážně potřebuje jenom minimum programátorů. Že to lidi nezajímá je samozřejmě škoda. Ale je velmi důležité, aby je to nemuselo zajímat. Třeba já jsem si s chutí přečetl něco o technikách automatické správy paměti, moc zajímavé téma, ale podstatné je, že při programování na to můžu s klidem zapomenout a nic se nestane. V hlavě potřebuju udržet jiné věci než ty, o které se za mne může postarat stroj.Ale v čem je ten benefit? Co z automatický správy paměti budu mít a jak to prospěje mému výtvoru? Vždyť když si pamět budu spravovat sám, můžu to přizpůsobit mýmu programu na míru...
Výkon je z velké části věcí použitých algoritmů a kvalitní architektury řešení, což je obvykle věc na jazyku nezávisláObecně si troufám tvrdit, že implementace programovacích jazyků jsou, díky mohutnému teoretickému aparátu (zase ty techniky GC, ty např. existují a vyvíjejí se od nějakých 50. nebo 60. let!), velice imunní vůči fenoménu prosakující abstrakce, takže výhody jasně převažují nad problémy, které se přece jen občas objevují.Ale jo, ale je potřeba použít správné řešení na správném místě. Jistěžě skriptovací jazyky maji spoustu důležitých uplatnění, kde se jejich výhody projeví, ale neměly by nahradit nativní programování - 'běžné programy' pro PC, a to hlavně ty větší, kde je potřeba výkon.
Tak třeba problémy se škálováním Ruby on Rails? No, když globálním zámkem efektivně serializujete zpracování požadavků, které by se klidně mohly zpracovávat paralelně, tak vám nepomůže ani vysoce optimalizovaný kód v assembleru. A tak podobně.
)...
31.10.2008 11:42
default | skóre: 22
| Madrid
… z hlediska spolehlivosti … Windows nepočítám …
Nestojí? GUI kód volá toolkit, ten volá OS, ten zas hardware.Což je až po ten OS všechno nějakej ten jump v kodu z místa na místo, příp. do vedlejšího modulu, pokud nelinkuju staticky. Předem vim kam to skáče a proč. U interpretovaných jazyků do tohohle tak dobře nevidim, páč interpreter si to zchroustá buhví jak...
31.10.2008 21:33
xkucf03 | skóre: 49
| blog: xkucf03
Problém je, že musíte přidat další vrstvu.I počítač je takovou vrstvou mezi uživatelem a zbytkem světa*. Zbavme se tedy počítačů a dělejme si všechno sami → a ubude nám spousta problémů s nimi spojených
Nebo ne?
*) jiní uživatelé, soustruh, atomová elektrárna…
) se bude snažit kód rozdělovat do více vláken. Když se totiž podívám na výkon procesorů, mám pocit, že se přestává zvyšovat takovým tempem, jako tomu bylo doposud (a je to celkem logické).
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
xvid_encraw nebo x264 je na vícejádrech krása. Samozřejmě je potřeba nastavit dostatečnej počet threadů. To de pak oproti starším procíkům neuvěřitelně rychle...
Osobne si myslim, ze JIT nemaji dlouhou budoucnost. Nakonec budou totiz nahrazeny statickou optimalizaci na zaklade statisticke analyzy chovani programu na testovacich nebo realnych datech. Tato metoda totiz spojuje vyhody obou dvou metod - jak klasicke staticke kompilace, tak JITu. Je to jen otazka casu, kdy k tomu dojde (davam tomu tak 20-30 let).To je možné, profile-driven kompilace se celkem rozmáhá. Ale některé optimalizace, které dnešní JIT překladače dělají, prostě lze udělat jenom za běhu, a bude jich přibývat. Zvlášť když bude přibývat "vyšších" jazyků: můžete staticky zoptimalizovat kritickou cestu nebo kritická místa v programu, ale ten zbytek s sebou potáhne nějakou infrastrukturu, která může být s JIT překladačem nakrásně zbytečná (třeba javovský JIT nahrazuje volání virtuálních metod přímým skokem, pokud ví, že neexistuje žádný potomek, který by metodu překrýval, a podobně). Já bych to viděl na nějaký hybrid.
Krome toho si myslim, ze ani Java nema dlouhou budoucnost. Je na prilis nizke urovni abstrakce, a bude casem nahrazena jazyky mnohem vyssi urovne (prinejmensim na urovni Pythonu), ktere bude schopen kompilator zoptimalizovat podstatne lepe nez nizkourovnovou Javu.S tím bych celkem souhlasil. Java IMHO skončí jako Cobol: moc existujícího softwaru a málo lidí, kteří by ho zvládli udržovat. Pokud se toho dožiju, asi pak budu pracovat jako Java konzultant, lepší přilepšení do důchodu si nemůžu přát
Osobne si myslim, ze JIT nemaji dlouhou budoucnost. Nakonec budou totiz nahrazeny statickou optimalizaci na zaklade statisticke analyzy chovani programu na testovacich nebo realnych datech. Tato metoda totiz spojuje vyhody obou dvou metod - jak klasicke staticke kompilace, tak JITu.U statické analýzy chování programu vidím pouze nevýhody: musíte do vývojového cyklu zakomponovat tuto analýzu, udržovat nějaká trénovací data, distribuovat různé přeložené verze programů pro nejrůznější hardwarové (nebo VM) architektury a pro různé případy použití. Koncový uživatel pak musí správně vybrat optimalizovano verzi. Výhoda je jediná -- optimalizací se neztrácí čas při ostrém běhu. To ale jako moc velkou výhodu nevidím, protože málokterý proces vytíží systém natolik, aby na optimalizace nebyl čas.
31.10.2008 21:45
xkucf03 | skóre: 49
| blog: xkucf03
Tím by odpadlo i prodloužení vývojového cyklu a další nevýhody.
Na druhou stranu, kdyby chtěl takový Google pro své účely používat tyhle vymoženosti, hádám, že nejspíš by brzy skončil na huntě...
Přijde mi ta debata taková uhozená. Vždyť přece určitě všichni dobře víme, že některé věci se bez starého dobrého céčka (Fortranu, Ady...) skoro dělat nedají, jiné by naopak v céčku dělal jen výjimečný masochista se spoustou volného času. A asi jsme si také všichni vyzkoušeli, že někdy je nejlepší udělat kompromis - například, mé haskellové prográmky obvykle bývají tak dvakrát pomalejší a desetkrát kratší než jejich céčkové ekvivalenty.
A jak je to s těmi, co používají céčko namísto skriptovacích jazyků, už nám přece dávno vysvětlil Master Foo.
Netvrdím, že byl žhavou novinkou. Ale tehdy (před těmi zhruba dvaceti lety) bylo dost lidí, kteří šířili víru, že to je je ta Jediná Správná Cesta (TM).
Definitivně ale mou důvěrou v užitečnost Prologu otřáslo až přímé srovnání. To kamarádi dělali za domácí úkol v Prologu program na řešení algebrogramů, což by teoreticky měl být typ úlohy, která by mu měla skvěle sednout. Problém byl, že když jsem si to cvičně zkusil v céčku, měl jsem ten program napsaný výrazně rychleji (OK, tohle je nefér, měl jsem samozřejmě s céčkem výrazně víc zkušeností než oni s Prologem), zdroják byl kratší (to mne překvapilo asi nejvíc) a program řádově rychlejší (což jsem čekal)…
Na druhou stranu, kdyby chtěl takový Google pro své účely používat tyhle vymoženosti, hádám, že nejspíš by brzy skončil na huntě...On výkon Googlu přece jenom stojí na něčem trochu jiném, než nízkoúrovňových optimalizacích
Tomu, že programy slušně napsané v céčku ještě pořád obvykle běhávají řádově rychleji než rozličné novější výdobytky, bych se zdráhala říkat nízkoúrovňové optimalizace
Když se pořádně rozjedeš, bude docela rozdíl, jestli těch mašin potřebuješ deset tisíc nebo sto tisíc...
Trochu jsem se původně nechal unést, souhlasím, že infrastrukturní věci pro extrémně vysoké zátěže je nejspíš dobré psát v nějakém nízkoúrovňovém jazyce, ale pročpak se asi v Googlu píšou MapReduce úlohy kromě C++ třeba i v tom Pythonu?
- mplayer/libpostproc/postprocess_template.c - mplayer/libavcodec/* - imlib2/src/lib/amd64blend*Toto jsou zdrojáky, které vyždímají z CPU opravdu maximum
Když je něco nutné implementovat v assembleru, tak to nejspíš nezachrání vůbec žádný jazyk vyšší úrovně, ať je vyšší o kolik chce.
- xvidcore/src/*
Jojo. Ale pokaždé, když mi nabízejí práci, ptají se na prvním místě na to C++
Ale pokaždé, když mi nabízejí práci, ptají se na prvním místě na to C++A ty jim odpovídáš Haskell, ne?
Možná by se ti líbilo víc v Microsoft Research
No jo. C++ má v Googlu určitě nezastupitelnou roli, v těch jejich nepředstavitelných škálách. Ale jak jsem říkal, když slezeme o pár řádů níž, třeba na úroveň toho Yahoo, tak tam už se s Javou vystačit dá.
V Microsoft Research se dějí zajímavé věci, ale zas je to tady od nás poměrně obtížně dostupné.
31.10.2008 21:48
xkucf03 | skóre: 49
| blog: xkucf03
Na druhou stranu, kdyby chtěl takový Google pro své účely používat tyhle vymoženosti, hádám, že nejspíš by brzy skončil na huntě...Myslíš třeba Google Web Toolkit?
může být (v rámci určitých mezí) Googlu celkem fuk, jak efektivní to jePřekladač z GWT provádí poměrně drsné optimalizace, aby ten JavaScript běžel co nejrychleji, dokonce pro každý prohlížeč generuje kód trochu jiný. Udržovat něco podobného přímo v JS by byla programátorská sebevražda. Dokonce, jak říkal Andrew Bowers, GWT upřednostňuje výkon nad snadností použití – což můžu potvrdit, nepíše se v tom nijak zvlášť snadno
co je levnější, jestli to pásmo, nebo čas Googlích vývojářůNo, jeden javascriptový soubor (pro jeden prohlížeč), který mívá velikost v řádu stovek kilobajtů a který lze bez problémů cachovat navždy, to není zas takový průšvih. S tím časem na vývoj je to zajímavější – na vývoj s GWT je potřeba programátor, zato webař se prakticky neuplatní, což může být docela killer. Chtělo by to nad GWT jako toolkitem ještě nějaký aplikační framework s HTML šablonováním
Jo - jeste jsem zapomnel - ani databazovym serverum nevestim dlouhou budoucnost. Kompilatory budoucnosti budou patrne schopne vygenerovat embedded databazi primo na miru prislusne aplikaci (neco jako Datadraw). To ze dnes pouzivame SQL je jakysi mezistav, protoze zatim nemame v jazycich dostatecne vyjadrovaci schopnosti (vyjimkou je mozna LINQ, ale to zatim stale jen abstrakce).
Proste - IMHO - cekaji nas za naseho zivota zajimave zmeny.
Historie je vubec zvlastni - v praci jsem delal na programu, ktery ma vlastni (relativne malou a primitivni) databazi (je to napsane v mainframe assembleru). Rikal jsem jim - proboha, proc to nenapsali s SQL databazi! A oni na to - no, vis, v roce 1983, kdy to zacali psat, se jeste SQL jaksi moc nenosilo.
Někteří už jsme ale potkali relační databáze na místech, kde by byly zdravější úplně jiné přístupy a děsíme se toho, že by je někdo chtěl cpát někam, kde budou darmo překážet.
Mám třeba kamaráda, co v jednom člověku vyrobil systém pro nemocnice, který je daleko výkonnější než software od konkurence, vyráběný rozsáhlými týmy. Teď to koupila nějaká ta konkurence a představuje si, že tu obskurní technologii, na které to běží, předělá na Oracle, kde běží konkurence... zatím si nechce nechat vysvětlit, že celá jeho konkurenční výhoda je v tom, že nepoužívá relační databázi... a takhle bohužel přemýšlí kdekdo.
Přitom to fakt není věc, která by měla spasit svět.
31.10.2008 21:57
xkucf03 | skóre: 49
| blog: xkucf03
že celá jeho konkurenční výhoda je v tom, že nepoužívá relační databáziV čem spočívá konkurenční výhoda nepoužití relační databáze? Jaký je, konkrétně v tomhle případě, přínos pro zákazníka?
Ale tohle není otázka, na kterou by sis odpověď nemohl snadno vymyslet, pokud nejsi manažer
2.11.2008 23:41
xkucf03 | skóre: 49
| blog: xkucf03
Ono je totiž dost ošemetné předpokládat, že v rámci jednoho projektu zvládnu napsat program, který lépe pracuje s daty, než SŘBD, který desítky let vyvíjejí ti nejlepší programátoři (ať už na universitách nebo třeba v Oraclu, IBM atd.).
Zase tak ošemetné to není. Stačí si totiž uvědomit, že nechám-li data v lokálních paměťových strukturách a budu tam s nimi pracovat, ušetřím overhead na jejich přeformátování, přeuspořádání, odeslání někomu jinému přes socket, čekání na výsledek a zpětné zpracování toho, co mi dotyčný vrátí. A ten nemusí být malý. Navíc se znalostí toho, jak se s daty pracuje, mohu efektivněji řešit zamykání, použít vhodnější datové struktury apod.
Tím samozřejmě nechci tvrdit, že je a priori špatné používat SQL servery. Sám je rád a často používám. Jen tvrdím, že to není automatický všelék a že je špatné se alibisticky vymlouvat prohlášeními typu "však on to ten Oracle (Firebird, …) s těmi daty stejně umí lépe, než bych to já kdy napsal".
, ale moje pointa je, ze ja si ten horizont dokazu predstavit. A tesim se (proto to sem take pisu, nechci delat chytreho, proste se mi doopravdy libi ta myslenka).
Až já si jedno najdu čas na napsání toho fuse_mysql :D
31.10.2008 22:04
xkucf03 | skóre: 49
| blog: xkucf03
Až já si jedno najdu čas na napsání toho fuse_mysqlNejsi první, koho to napadlo.
Já zase jednu dobu chtěl nad databází psát systém na správu verzí (naštěstí jsem si to nechal rozmluvit ) Ale v Perforcu na to šli z druhé strany: mají verzovací systém a k němu udělali SQL rozhraní (ODBC), to je hezká věc.
Posledně jsme řešili jak hrát a vyhrát různé kombinatorické hříčky.
31.10.2008 21:06
xkucf03 | skóre: 49
| blog: xkucf03
1.11.2008 22:12
xkucf03 | skóre: 49
| blog: xkucf03
1.11.2008 22:41
xkucf03 | skóre: 49
| blog: xkucf03
Ono se ukazuje, i když to taky není obecně platná skutečnost, že v některých (vysokoúrovňových) jazycích se některé (nízkoúrovňové) věci hlavně psát vůbec nemusí.Mám dojem, že to je důvod vzniku vyšších jazyků ne?
V8 je mimochodem adaptivní překladač, který musí překládat až za běhu, jinak by nebylo možné provádět optimalizace, které provádí. To jen pro tvou informaciJá vím co je V8 zač. To ty si začal psát hlouposti.
31.10.2008 20:50
xkucf03 | skóre: 49
| blog: xkucf03
PHP je hrozný bastlBastl to je o tom žádná. Ale lidi, kteří v něm dobrovolně či nedobrovolně píší a nezdrhli k něčemu jinému si, pokud jejich výtvory fungují, zaslouží obdiv – psát v něm a udržet svůj program při životě i přes změny ve verzích PHP a další nepřízně tohoto jazyka je celkem řehole. Sám jsem od PHP právě z těchto důvodů odešel za lepším a dnes v PHP maximálně napíšu sem tam nějaký jednoúčelový skriptík.
31.10.2008 18:26
frEon | skóre: 40
| Praha
31.10.2008 20:43
xkucf03 | skóre: 49
| blog: xkucf03
27.10.2008 08:19
pushkin | skóre: 43
| blog: FluxBlog
u hodne lidi je prvni reakce na cizi praci: "Ktere prase to delalo?"
Nejen na cizí, občas i na vlastní, je-li pár let stará… :-)
29.10.2008 17:20
Pavel Čejka | skóre: 28
| blog: tosinezaslouzijmeno
Zrovna přepisuju pro zábavu jeden asi 13 let starý projekt v Z80 assembleru pro ZX Spectrum po známém, který ho nechal volně k dispozici pro případné dokončení. Dělám na tom s velmi dlouhými přestávkami možná rok a postupně jsem se propracoval do fáze, že to "už skoro dělá to, co dřív" ... jen s tím rozdílem, že se mi to líbí, vyznám se v tom, je to lépe strukturované a hlavně lze pokračovat v dokončení, což předtím skoro nešlo.
Ačkoli to, co jsem popsal je dost extrém Nicméně programů, které jsem byl nucen přepsat zcela od začátku v různých jazycích jsem zažil několik. Často je to lepší, jen to je časově náročné a tudíž drahé.
27.10.2008 11:08
Max | skóre: 72
| blog: Max_Devaine
27.10.2008 13:40
stybla | skóre: 29
| Praha
Neumím programovat, pasuji se mezi mizerné slepovače kodu :-/Dulezity je vysledek a jeho kvalita. Kdyz si porovnam produktivitu "slepovacu kodu" a lidi, kteri na programu pilne pracuji - pouze tise zavidim. Kdo by nechtel sekat programy jako Bata cvicky? :)
Zdar Max
Programovat umi kdo umi pouzivat: - alespon html - interpretery (java/basic) - kompilovane jazyky (pascal,c...) - assembler - instrukcni kody a deruje to na stitky. - totez co predchozi ale vse z pameti bez prekladovych tabulek.
... a pak jeste nejakou definici "umi" protoze sebevedomy pubertak to slovo pouzije uz u druhe strany obsahu "zaciname s pc"....
(red dwarf)
- jinak o tom ze prasici existujou v kazdym jazyku se nehadam...
Kdoví. Možná můžeš nadefinovat programátora jako toho, kdo ví třeba, jak rychle se třídí. (Už jsem měla na pohovorech lidi, co se tvářili, že to snad umějí v konstantním čase...)
No... pak tu jeste mame klasicke deleni na opravdove programatory a pojidace kolacu... .
tridi se - cim vic dat, tim pomaleji... staci to? Ondyno jsem odmitl delat trideni nazvu souboru, protoze by to bylo slozite a zbytecne. (ATmega32, Fat16 na MMC karte...2kB RAM,32kB ROM) Divili se. Vysvetlil jsem. Divili se a dotirali. Vysvetlil jsem znovu a lepe. Pochopili (asi) ... nutno podotknout, ze zobrazovani souboru nebylo hlavni naplni toho neboheho cpu
... takze ne, neumim programovat. Odmitl jsem tridit.
A mám takový pocit, že to říkal někdo od tebe z kanclu.
Kdyby ses zeptal, řekla bych Ti, že u toho co třídíš, budeš rád, když to zvládneš tím bucketsortem lineárně
(normalka bubblesortem)
31.10.2008 22:12
xkucf03 | skóre: 49
| blog: xkucf03
v konstantním časeTo nic není, můj programovací jazyk třídí tím rychleji, čím víc je prvků, učí se za chodu!
27.10.2008 13:34
stybla | skóre: 29
| Praha
IMHO umí určitě spíš programovat ten, kdo vyřeší problém implementací pěkného algoritmu v PHP než někdo, kdo prasí v assembleru...V PHP jde neco naimplementovat pekne? Smim se zeptat 'jak'?
V PHP jde neco naimplementovat pekne? Smim se zeptat 'jak'?
Proč by to nemělo jít? Syntaxe základních řídících konstrukcí je stejná jako v céčku. To, že vám jazyk umožňuje psát jako prase, ještě neznamená, že této možnosti musíte využívat.
28.10.2008 08:18
stybla | skóre: 29
| Praha
Dovolim si nesouhlasit. Drive bych asi neodporoval, ale dnes uz ano. PHP nejde psat jinak nez jako prase. Nezlob se na me, ale jak mam smyslet o jazyku, ktery nedovoli napsat vetsi kus kodu bez pouziti '@'. A jsou i jine spekovky jako napr. nedavno schvaleny oddelovac namespace, mixed return values, funkce se chovaji jinak nez je v dokumentaci popsano (a vyvojarum je to ocividne fuk), atd. To vse shrnout do jedne proste vety: "Ja jsem se snazil".V PHP jde neco naimplementovat pekne? Smim se zeptat 'jak'?To, že vám jazyk umožňuje psát jako prase, ještě neznamená, že této možnosti musíte využívat.
jak mam smyslet o jazyku, ktery nedovoli napsat vetsi kus kodu bez pouziti '@'
Zajímavé, že jsem si toho nikdy nevšiml…
Ostatní "důvody" jsou hodně uměle vymyšlené.
28.10.2008 12:19
stybla | skóre: 29
| Praha
Když se na školách k výuce programování používal Pascal, tak to bylo/je podobné. Starší programátor přijde do styku s C a pochopí víc věcí a najednou se za to, co dělal v Pascalu, stydí. A tak začne Pascalem opovrhovat.Nevim, ale s Paskalem jsem zacinal a nestydel jsem se a nestydim se za nej, ani jim neopovrhuji. Pouze nema uplatneni a to beru jako fakt. Stejny fakt jako ten, ze by se nad sebou vyvojari PHPcka meli hluboce zamyslet a nestydet se poucit se z chyb druhych popr. z uspesnych reseni druhych.
Je ho plný web a je snadné s PHP začít.Naprosto souhlasim. Napisete "Hello world" a umite PHP. Spousta freehostingu, spousta frameworku, spousta napsaneho kodu (takze staci pouze C&P a mate aplikaci). Ano, PHP je vhodny zacatek.
Pouze nema uplatneni a to beru jako fakt.Ale? Pro vývoj už se přestalo používat Delphi?
28.10.2008 14:16
stybla | skóre: 29
| Praha
Ale? Pro vývoj už se přestalo používat Delphi?Priznam se, ze takove nabidky prace uz beru jako raritu. Ok, skrtneme fakt.
28.10.2008 14:19
stybla | skóre: 29
| Praha
Ale? Pro vývoj už se přestalo používat Delphi?btw Delphi uz ma i nejaky port na Linux?
28.10.2008 14:28
stybla | skóre: 29
| Praha
IMHO by v té otázce mělo místo "už" být "ještě". :-)I to je mozne. Nikdy me to nezajimalo natolik (ani jsem nemel potrebu), abych se po takove informaci pidil, proto ono prekvapeni. Otazka byla polozena ciste z duvodu rozsireni informovanosti, i kdyz by to (jiste) zvladl i google.
31.10.2008 22:18
xkucf03 | skóre: 49
| blog: xkucf03
28.10.2008 12:13
stybla | skóre: 29
| Praha
Verim, ze pri pouzitijak mam smyslet o jazyku, ktery nedovoli napsat vetsi kus kodu bez pouziti '@'Zajímavé, že jsem si toho nikdy nevšiml…
if a for si toho clovek nevsimne. Take jsem si toho az do nedavne doby nevsimnul.
Jakym zpusobem jsou vymyslene?Ostatní "důvody" jsou hodně uměle vymyšlené.
Jakym zpusobem jsou vymyslene?
Způsobem "kdo chce psa být, hůl si najde". Obávám se, že Jiří Pagáč vás vystihl naprosto přesně. Jste prostě "velký kluk", který se naučil "opravdové jazyky", a protože "velcí kluci" PHP opovrhují, hlasitě jím opovrhujete.
28.10.2008 12:33
stybla | skóre: 29
| Praha
Souhlasim. Nad zbytkem jsem se zasmalZpůsobem "kdo chce psa být, hůl si najde".
31.10.2008 22:21
xkucf03 | skóre: 49
| blog: xkucf03
1.11.2008 22:30
Jakub Lucký | skóre: 40
| Praha
1.11.2008 22:39
xkucf03 | skóre: 49
| blog: xkucf03
1.11.2008 22:45
Jakub Lucký | skóre: 40
| Praha
2.11.2008 23:28
xkucf03 | skóre: 49
| blog: xkucf03
2.11.2008 23:59
Jakub Lucký | skóre: 40
| Praha
Řekl bych, že v každém jazyce platí, že programátor bez zkušeností má tendenci podlehnout pokušení používat prvky jazyka jen proto, že existují, a bez ohledu na to, jestli je to rozumné (což bez zkušeností nedokáže posoudit). Když jsem se poprvé potkal s C++, měl jsem s trochou nadsázky pocit, že když nebudu usilovně overloadovat operátory a používat pointery na metody, budu naprostý břídil. Když se dneska podívám na některé výtvory z té doby, ježí se mi chlupy po celém těle a říkám si, jaké štěstí, že jsem měl respekt aspoň z těch templatů. Jazyky s bohatším rejstříkem technik k tomu samozřejmě svádějí víc, ale to vidím právě spíš jako problém té sebekázně než jazyka.
Když to shrnu: vezmu-li céčkový zdroják bez věcí jako makro-gymnastika, inline assembler a komplikovanější pointerové aritmetiky (které ale těžko považovat za ukázku čistoty a přehlednosti), můžu ho v podstatě tupě přepsat do PHP. Jen musím před jména proměnných nadělat ty nešťastné dolary a opravit řetězcové operace (které jsou ale v PHP jednodušší a přehlednější). A co je asi největší problém, zapomenout na to, že za mne překladač pohlídá typy a že za mne něco zoptimalizuje.
.
1.11.2008 22:17
xkucf03 | skóre: 49
| blog: xkucf03
(protože už nemá potřebu si něco dokazovat)
Když bude pěkný, přidám si Tě do seznamu...
(Poslední týden se hrabu v perlovém zdrojáku, který je tak naprosto šílený, že si ráda spravím chuť...)
28.10.2008 19:28
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
můžeme začít třeba už od proměnných s dolary, u kterých je dolar úplně na ozdobu...Dolary jsou problém?
LET, dolary a proměnná o jednom znaku z BASICu jsou ještě zlaté(o luxusu v PHP se nemá cenu vůbec bavit).Že já někde vyhrabu program pro CNCčka.
27.10.2008 20:53
carnero
| Praha
. Tohle je velmi dulezita vec, ktera (krome jineho) odlisuje dobreho programatora od spatneho.
a jak efektivneTo ma nedávn dorazil jeden preborník asi takýmto kódom:
POLYLINE ReadPolyline(char *filename)
{
POLYLINE result;
FILE *f=fopen(filename,"r");
/* parsovanie */
fclose(f);
return result;
}
for (i=0;i<ReadPolyline(filename).numberOfPoints;i++)
printf("%d %d\n",ReadPolyline(filename).point[i].x,ReadPolyline(filename).point[i].y);
27.10.2008 15:08
Dalibor Smolík | skóre: 54
| blog: Postrehy_ze_zivota
| 50°5'31.93"N,14°19'35.51"E
27.10.2008 20:52
elenril | skóre: 21
| blog: Raziel
Hlasoval jsem pro tak trochu a učím se. Můj problém je, že umím od každého trochu, ale žádný pořádně. Teď na vejšce bych se chtěl specializovat. Oproti jaderným hackerům či softwarovým vývojářům jsem teda ořezávátko
31.10.2008 22:30
xkucf03 | skóre: 49
| blog: xkucf03
Hlasoval jsem pro tak trochu a učím se.Takhle by pak mohl hlasovat každý – protože kdo se neučí není programátor. Celý život se člověk učí…
.
29.10.2008 11:49
stybla | skóre: 29
| Praha
29.10.2008 12:00
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
29.10.2008 15:04
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Alespoň já mám tu zkušenost, že chyby tohoto typu nelze běžnými programátorskými metodami (ladicí výpisy, debugger) najít. Jediná možnost je pochopit chování programu a pak uhodnout, kde ta chyba je. A pak už běžnými programátorskými metodami tu chybu dokázat Debugger se pak hodí maximálně k tomu, že je možné v něm jednotlivá vlákna pozastavovat a navodit tak to správné pořadí přepínání vláken (což je přeci jen o fous jednodušší, než to přepínání pro ladění programovat pomocí nějakých synchronizačních nástrojů)...
29.10.2008 21:33
Bluebear | skóre: 30
| blog: Bluebearův samožerblog
| Praha
Zkusil jsi valgrind? On vždycky vybleje strašné množství keců, ale už se mi s jeho pomocí podařilo problém najít, resp. zachytit stopu.
A zacinam uz o svych programovacich schopnostech silne pochybovat. Ach jo, posledni pilir drzici integritu me osobnosti pohromade se borti.
Ale houby. Důležité je se nevzdávat. Nějak na to přijdeš - v kernelu se takové věci stávají taky, ladí se ještě hůř, protože často srazí celou mašinu, a nakonec se na ně taky přijde. V nejhorším to můžeš vždycky celé přepsat (resp. ty relevantní části).
Zkusil jsi valgrind+1 Doporučuju tento nástroj.
Ale hlavně kvalitní nástroj.
30.10.2008 14:57
Mintaka | skóre: 13
30.10.2008 15:37
default | skóre: 22
| Madrid
. Jak to vůbec fungovalo?
30.10.2008 18:59
Mintaka | skóre: 13
. Pokud se ty baťáky po použití i mazaly, tak zase bylo nebezpečí výmazu disku.
30.10.2008 20:14
Mintaka | skóre: 13
3.11.2008 09:56
default | skóre: 22
| Madrid
3.11.2008 16:59
xkucf03 | skóre: 49
| blog: xkucf03
.
28.10.2008 09:38
