abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 03:00 | Komunita

Bylo spuštěno hlasování o přednáškách a workshopech pro letošní InstallFest, jenž proběhne o víkendu 3. a 4. března 2018 v Praze na Karlově náměstí 13. Hlasovat lze do pondělí 29. ledna 2018.

Ladislav Hagara | Komentářů: 0
dnes 02:00 | Zajímavý software

Projekt Document Liberation, jehož cílem je vývoj knihoven pro zpřístupnění (osvobození) dokumentů vytvořených v proprietárních nebo již nepodporovaných formátech, oznámil vydání 5 nových nebo vylepšených knihoven. Jedná se o knihovnu libe-book pro export dokumentů ve formátu EPUB3 a knihovny libabw, libmspub, libpagemaker a libqxp pro import dokumentů ve formátech AbiWord, MS Publisher, PageMaker a QuarkXPress.

Ladislav Hagara | Komentářů: 0
dnes 01:00 | Komunita

LWN.net, původně Linux Weekly News, slaví 20 let. První číslo vyšlo 22. ledna 1998. Psalo se o devfs, o 2 GB omezení velikosti souborů na souborovém systému ext2 nebo o renderování scén ve filmu Titanic na Linuxu na procesorech Alpha. Aktuální vývojové linuxové jádro bylo 2.1.79. LWN.net je zcela závislé na předplatitelích. Předplatné na měsíc stojí 7 dolarů. Články na LWN.net jsou týden od vydání k dispozici pouze předplatitelům. Následně jsou uvolněny všem pod licencí CC-BY-SA.

Ladislav Hagara | Komentářů: 0
včera 15:22 | Pozvánky

V sobotu 24. 2. se uskuteční již 5. ročník největší české WordPress konference – WordCamp Praha 2018. Pražský WordCamp bude rozdělen na dva proudy – pro uživatele a pro vývojáře. Je naplánováno 10 přednášek, 6 workshopů, 6 případových studií, Happines Bar a spousty příležitostí pro networking. V neděli se bude dále konat Contributing Day, kde se každý bude moci aktivně zapojit do překladu, či plánování dalších meetupů. Je připraveno 450

… více »
smíťa | Komentářů: 0
včera 05:55 | Komunita

Linus Torvalds oznámil vydání Linuxu 4.15-rc9. Po vydání stabilní verze Linuxu se přibližně na 2 týdny otevře začleňovací okno. To se uzavře vydáním verze rc1. Po týdnech následují další rc verze. Obvykle týden po vydání verze rc7 nebo rc8 následuje vydání nové stabilní verze Linuxu. Verze rc9 byla naposledy vydána před více než 6 lety, 4. října 2011. Jednalo se o Linux 3.1. Tenkrát následovala ještě verze rc10.

Ladislav Hagara | Komentářů: 13
21.1. 21:55 | Zajímavý článek

Greg Kroah-Hartman se v příspěvku na svém blogu věnuje aktuálnímu stavu řešení bezpečnostních chyb Meltdown a Spectre v Linuxu. Jak je na tom Váš Linux? Stačí spustit příkaz "grep . /sys/devices/system/cpu/vulnerabilities/*". Pro více informací lze doporučit Spectre & Meltdown Checker.

Ladislav Hagara | Komentářů: 46
19.1. 18:55 | Komunita

NHSbuntu (Joinup, prezentace) měla být z Ubuntu vycházející linuxová distribuce přizpůsobená pro potřeby britské Národní zdravotní služby (NHS). NHS se název nelíbil, nejednalo se o oficiální projekt NHS, a proto bylo NHSbuntu v září loňského roku přejmenováno na NHoS. Vývojáři NHoS tento týden oznámili, že NHS se nelíbí ani název NHoS a už nemají sílu na další přejmenování a pokračování v projektu. Dodávají, že několik jednání s vedením

… více »
Ladislav Hagara | Komentářů: 7
19.1. 18:44 | Pozvánky

Koncem ledna, 29. 1. 2018 od 17 do 20 hodin se v Akademii CZ.NIC uskuteční večer s Turrisem.

Co bude na programu?… více »
Miška | Komentářů: 19
19.1. 18:33 | Pozvánky

Na tri dni sa hlavné mesto Slovenska po tretíkrát zmení na miesto s najväčšou koncentráciou profesionálnych programátorov, systémových administrátorov, učiteľov informatiky aj technologických nadšencov. Hlavným lákadlom bude konferencia PyCon SK 2018, určená záujemcom o Python, jeden z najpopulárnejších programovacích jazykov na svete.

… více »
RicCo386 | Komentářů: 1
19.1. 18:22 | Pozvánky

Letošní ročník konference Prague PostgreSQL Developer Day se koná ve dnech 14. 2. a 15. 2. 2018. Zveřejněn byl program s přednáškami a školeními. Otevřena byla také registrace na konferenci.

TomasVondra | Komentářů: 0
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (7%)
 (1%)
 (1%)
 (1%)
 (77%)
 (13%)
Celkem 1373 hlasů
 Komentářů: 53, poslední 17.1. 16:55
    Rozcestník

    Rychlost CogVM

    29.3.2012 09:24 | Přečteno: 1516× | Výběrový blog

    Před léty se říkalo, že VisualWorks Smalltalk je přibližně 10x pomalejší než C a Squeak je 10x pomalejší než VisualWorks. To dnes již zdaleka neplatí. Od příchodu CogVM se na těchto poměrech hodně změnilo.

    CogVM je nový virtuální stroj pro otevřené implementace Smalltalku Squeak, Pharo a odvozené, který implementuje JIT, mapování kontextů na zásobník a podobné optimalizační funkce. Navíc přinesl například plnohodnotné uzávěry. Chtěl jsem si ověřit, jak si tedy dnes vlastně stojí v porovnání s ostatními virtuálními stroji pro Smalltalk i dalšími programovacími jazyky. Proto jsem provedl pár testů vycházejících z klasické Computer Language Benchmarks Game.

    Do žádného velkého propracovaného testování jsem se ale nepouštěl, takže jen shrnu výsledky, které, prosím, berte s jistou rezervou. Pharo na CogVM v testech vycházelo cca 1,4 - 2 krát pomalejší než VisualWorks 7.8, přičemž horších výsledků dosahovalo v testech zaměřených na aritmetiku.

    Provedl jsem i krátké srovnání se Smalltalk/X, z něhož plyne, že dnes jsou Squeak/Pharo a Smalltalk/X rychlostně srovnatelné. Přesněji řečeno, v aritmetických testech CogVM cca o 15% zaostává, v jiných je zase o 30% rychlejší. Je to zajímavý výsledek, když uvážíme, že díky optimalizacím Smalltalk/X například nepodporuje kontinuace. Když jsem se Smalltalkem/X porovnával před drahně měsíci první verze CogVM, vycházel Cog ještě asi 3x pomalejší.

    Jak si současné implementace Smalltalku vedou v porovnání s ostatními programovacími jazyky? Že Smalltalk není žádný kvapník, je obecně známo. Na druhou stranu jeho výsledky tragické určitě také nejsou. Ve zmiňované Computer Language Benchmarks Game vychází VisualWorks přibližně 15x pomalejší než C. Squeak v testech nefiguruje, přestože tam kdysi byl, ale autor této "hry" se snaží omezovat množství porovnávaných jazyků a implementací, takže případná měření je nutné provést na vlastní pěst. Z výše zmíněného vyplývá, že by CogVM měl být přibližně 20x-30x pomalejší než C, čemuž odpovídají i experimentální výsledky. V pro Smalltalk nejpřívětivějším testu binary-trees byl Cog 13x pomalejší než céčkovská verze kompilovaná na O3. Testoval jsem na 64 bitech.

    Samozřejmě porovnávané programy v C/C++ a Smalltalku nejsou zcela ekvivalentní. Aby byly, musel by program v Céčku hlídat přerušení programu uživatelským vstupem z klávesnice, shromažďovat ladící informace, aby byl schopen zobrazit v debuggeru aktuální stav výpočtu v kontextu zdrojových kódů, umožnit ladícímu programu upravovat hodnoty proměnných, vyjmenovávat všechny instance libovolné třídy, serializovat aktuální stav výpočtu a být schopen v něm pokračovat i na jiné platformě atd. To vše něco stojí. V tomto světle nevypadají výsledky Smalltalku vůbec špatně. Ale ve Smalltalku je to pevná složka ceny.

           

    Hodnocení: 100 %

            špatnédobré        

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    Bystroushaak avatar 29.3.2012 10:21 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Rychlost CogVM
    Hm. Smalltalk se mi docela líbí jako jazyk, projížděl jsem si i nějaké ty tutoriály. Čeho jsem se však nemohl zbavit je dojem totální nepraktičnosti/nepoužitelnosti. Prostě si neumím představit, že bych v něm něco napsal a pak to distribuoval, nebo to nějak prakticky používal. Ten koncept image paměti je divný až moc a přijde mi, že zabíjí využitelnost.
    oryctolagus avatar 29.3.2012 18:16 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Rychlost CogVM
    No, kvůli tomu vzniklo Objective-C, ne? ;-)
    There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
    Bystroushaak avatar 29.3.2012 19:39 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Rychlost CogVM
    Vzniklo? :) Přiznám se že netuším, znám trochu historii smalltalku, ale o objC vím tak leda to, že ho používá apple.
    30.3.2012 02:07 Miloslav Ponkrác
    Rozbalit Rozbalit vše Re: Rychlost CogVM
    Když vznikl programovací jazyk C, několik týmů ho chtělo doplnit o objekty.

    Vznikly v zásadě dvě větve. Jedna doplnila C o něco jako smalltalkovské pojetí objektů a nazvalo se to Objective C. Druhá doplnila o simulovské pojetí objektů a nazvalo se to C++.

    U Objective C se toho asi o 8 let později chytil Jobs a od té doby je to plné proprietárního vývoje, různých proprietárních licencí, atd. Dodnes ten jazyk nemá normu, některé jeho knihovny mají copyright, atd.

    U C++ se naopak vše dalo volně k dispozici, vznikla postupně ISO norma, a nikdo nebyl omezován v tom udělat vlastní kompilátor.

    Objective C je zabitý jazyk a Apple only. Sice existuje jeho implementace v gcc kompilátoru. Některé další kompilátory Objective C se dokonce přiblížily Smalltalku víc, než Applovské Objective C. Z důvodů licence a toho, že je závislý na Applovských manýrech není Objective C nic, do čeho bych investoval čas, pokud nechci vyvíjet pouze pro Apple.

    Přijde mi jako lepší varianta Ruby, ve které je Smalltalk taky dost cítit. I když to není kompilátor.
    30.3.2012 10:26 Vskutečnosti Saýc | skóre: 7
    Rozbalit Rozbalit vše Re: Rychlost CogVM
    To je smutne, hlavne proto, ze mi (pri zbeznem proletnuti) prislo ObjC mnohem pratelstejsi nez C++.
    30.3.2012 11:37 Miloslav Ponkrác
    Rozbalit Rozbalit vše Re: Rychlost CogVM
    Smalltalk je jazyk, který většina lidí co v něm dělala miluje. Ovšem neujal se v první řadě proto, že licence byla drahá. Druhak proto, že Smalltalk je opravdu pomalý a na starším hw to hrálo velkou roli. A třeťjak proto, že Smalltalk nikdy neměl být programovací jazyk, ale operační systém. A když jako operační systém nedosáhl úspěchu (na rozdíl třeba od LISP mašin), tak se z něj narychlo udělal programovací jazyk.

    Proto také Smalltalk funguje tak jak funguje, na svém image a dělá si vše sám. To je dědictví toho být operačním systémem.

    Ale mimochodem, před 20 lety jsem měl takovou disketu 1,44 MB, která obsahovala Smalltalk i s bootem – a skutečně to jako operančí systém fungovalo. Všechno se tam vešlo včetně GUI a bylo to velmi luxusní. Požadovalo to 286.

    Ale zpět – cílem Objective C bylo NĚJAK do C doplnit objekty a pokud možno ho co nejmíň zasáhnout do C. Cílem C++ bylo doplnit do C objekty a udělat z něj rychlostního marathona pro rychlý vývoj a maximálně rychlé binárky.

    Smalltalk zasáhl do mnoha jazyků a pokud se Vám koncept Smalltalku líbí, nebude pro Vás velký rozdíl, zda děláte v Ruby, Pythonu apod. I když pravda, Smalltalk byl jednoduchý a čistý koncept, asi nejčistější OOP a přitom jednoduché a lidské.

    Škoda, že ty licence na začátku.

    30.3.2012 12:10 luky
    Rozbalit Rozbalit vše Re: Rychlost CogVM
    Smalltalk je jazyk, který většina lidí co v něm dělala miluje.
    Ja bych to videl tak, ze vetsinu lidi to zprudi a pouze par lidi si to zamiluje. Jako jazyk tak spatny neni, ale vsechno ostatni je hruza - nastroje pro kolaborativni vyvoj jsou naprosto tragicke, vyvojova prostredi jsou zaostala a mizerne se to ovlada klavesnici (alespon squeek a to prostredi pro stx).
    30.3.2012 17:57 Miloslav Ponkrác
    Rozbalit Rozbalit vše Re: Rychlost CogVM
    Smalltalk frčel v době, kdy dnešní kolaborativní vývoj neexistoval ani ve sci-fi.

    Tehdy prostě dva lidi si sedli a za chvíli napsali unix. Nebo si jeden na pár měsíců sedl a napsal kompilátor Céčka.

    Smalltalk na splupráci moc není. Je to jazyk, který dovoluje klidně i přehodit význam false a true, když mu budete chtít škodit. Nemá absolutně žádnou ochranu před programátorem.

    Dnešní kolaborativní spolupráce je o tom, že co dřív udělal jeden člověk za měsíc, dnes udělá tým lidí za dva roky. To jen jako poznámka. Jednak proto, že tehdy každý programátor byl teoreticky nabušený způsobem, že to prudce urychlovalo vývoj. A druhak proto, že jednoduše tvořil a taky proto, že neexistovalo OOP – zejména ne impotentní OOP v Java stylu a návrhové vzory šité na Javu.

    Squeak jsem moc v ruce neměl, takže nevím.

    Nicméně vývoj v týmu a Smalltalk to nejde moc dohromady. Ten jazyk je napsán sám v sobě. Kromě velmi jednoduchého engine je i základ Smalltalku psát sám ve Smalltalku a je tedy libovolně přístupný i programátorovi.

    Smalltalk nemůžete chápat jako programovací jazyk, Smalltalk je v podstatě permanentní objektová databáze, nad kterou máte jazyk zvaný Smalltalk pro operaci s databází. To je ve skutečnosti Smalltalk. Když si řeknete, že Smalltalk je nejlepší objektová databáze, která existuje (pokud nechcete rychlost) nad kterou můžete psát aplikace – je to přesnější definice toho co je Smalltalk.

    Ohledně nástrojů – podívejte se jaké nástroje dostanete s PHP. Kulové, nedostanete ani ten debugger – a to ani řádkový. Nulové IDE, nic. A přesto to nikomu v masovém užívání nevadí.

    Smalltalk je především do důsledku dotažené OOP. Nejjednodušší a nejčistější, které existuje. Doporučuji minimálně jako zkušenost.

    Jinak Squeak bohužel dojíždí na svou nenávist k C. Nejsou schopní napsat ani slušný engine, protože nenávidí C, a tak to píšou v nějaké Smalltalkové podobě a podle toho to vypadá.
    oryctolagus avatar 30.3.2012 18:55 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Rychlost CogVM
    Jednak proto, že tehdy každý programátor byl teoreticky nabušený způsobem, že to prudce urychlovalo vývoj. A druhak proto, že jednoduše tvořil a taky proto, že neexistovalo OOP – zejména ne impotentní OOP v Java stylu a návrhové vzory šité na Javu.
    Imho to je hlavně proto, že dneska jsou ty systémy řádově složitější... Způsob, jakým se interaguje s OS, s uživatelem, se sítí, se vším možným, multithreading, přenositelnost,... Je toho opravdu hodně... Jinak nabušení programátoři určitě existují i dnes a Javovské OOP se taky necpe všude, naštěstí.
    There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
    30.3.2012 20:40 Miloslav Ponkrác
    Rozbalit Rozbalit vše Re: Rychlost CogVM
    „Imho to je hlavně proto, že dneska jsou ty systémy řádově složitější...“

    To jsou.

    ---

    „Způsob, jakým se interaguje s OS, s uživatelem, se sítí, se vším možným, multithreading, přenositelnost,... Je toho opravdu hodně...“

    Možná Vás to překvapí, ale už jsem tu na abclinuxu několikrát psal, že před 20 lety byly programovací jazyky složitější. Oproti dnešním vykuchancům, které pokud možno neumí nic a vše dohánějí knihovnami – bylo poměrně standardem, že jazyk hodně věcí uměl sám o sobě. Často to byl multithreading, daleko vymakanější, než dnes, který byl součástí řady jazyků. Přenositelnost byla obecně větší rovněž – tak heterogenní operační systémy i různé počítačové sítě, jako byly tehdy už dnes nejsou.

    Já programuji cca 25 let. Moc si dnešní dobu idealizujete. Dříve se dělaly praktické věci, dnes se dělají ideologicky přípustné věci – v mnoha programovacích jazycích, či způsobech práce systémového inženýrství se dnes spíše hodnotí, zda je to politicky a ideologicky vhodné, než praktické.

    Ono je to spíše tak, že se svět vrací k tomu, co bylo před 20 lety – a já jsem od té doby nepoznal moc nového v sw světě. V pohodě si vystačím jen s tím, že „aha to už jsem zažil před 15-20 lety, teď to jenom někdo znovu objevil“.

    I proto dělám astrologii, i proto studuji psychologii – protože to jsou na rozdíl od IT progresívní obory, kde se aspoň objevuje něco nového a nějaká progrese. A můžete si o mě myslet co chcete, třeba že jsem blbec.

    ---

    „Jinak nabušení programátoři určitě existují i dnes a Javovské OOP se taky necpe všude, naštěstí.“

    Ale pořád si všimněte, že komunitně dělaný Linux dlouhou dobu dohání v zásadě více individuálněji dělané BSD. Ještě zajímavější by bylo důsledně porovnat počet člověkoroků vražených do vývoje BSD a do vývoje Linuxu – zde se ukáže daleko jasněji, jak to s efektivitou jedinec versus tým je.

    Nebo jednoho Knutha, který napsal TeX – a kolik lidí týmově vedle něj napsali podobně kvalitních sázecích systémů a kolik takových systémů bylo?

    Javovské OOP se cpe všude, protože Java ovlivnila velmi mnoho moderních dogmat o OOP, která nejsou vždy úplně pravdivá. A tato dogmata se používají i tam, kde Java není a kde jsou možnosti větší. Ale to je jedno. Na tom nesejde.

    ---

    Principem jsem chtěl jenom říct, že Smalltalk je prostě originál, protože to je jiný koncept. Není to C-like (jako C/C++/Java/C#/...). Stejně tak jako je třeba originál LISP, nebo je originál Ada, nebo je originálem leccos dalšího. Zrovna tu Adu doporučuji jako studiem, jak vysoce může být jazyk přenositelný, včetně jeho podpory multithreadingu přímo v jazyce (a dost netradičně pojatého, ale účinného). Mimochodem, třeba LISP svého času byl koncept pro paralení mašiny, protože byl na to fakt dobrej a je dobrej. Atd.

    Dnes se všude prosadil tandem C-like jazyky + unix-like operační systémy. A je to leckde i na škodu, protože je mnoho velmi dobrých konceptů. A je inspiratvní si je zkusit.
    30.3.2012 21:00 Pavel Křivánek | skóre: 24 | blog: Kvičet nezávaznou konverzaci
    Rozbalit Rozbalit vše Re: Rychlost CogVM
    nastroje pro kolaborativni vyvoj jsou naprosto tragicke, vyvojova prostredi jsou zaostala a mizerne se to ovlada klavesnici (alespon squeek a to prostredi pro stx).

    Ovládat to bez myši skutečně bohužel prakticky nejde. Kreslítek UI a všemožných wizzardů si také člověk mnoho neužije, ale jinak bych si dovolil nesouhlasit. Monticello je jako verzovací systém solidně použitelné a nic nikomu nebrání použít třeba Git, chce-li. Unit testing, refaktorovací nástroje, kontrola kvality kódů... to vše je vysoké úrovni. Jako build server se používá klasika - Jenkins (viz https://ci.lille.inria.fr/pharo/). Osobně si často říkám, že bych dal za vděk spíše stařičkému původnímu xeroxáckému Smalltalku-80 než mnohým dneším IDE.

    A pokud člověku něco přece jen chybí, je většinou velice snadné si to dopsat. Tuhle jsem například chtěl zjistit pokrytí určité třídy unit testem. To se ve Smalltalku napíše třeba takto:

    | class test trace classTrace result  |
    
    class := Time.
    test := TimeTest.
    
    trace := Dictionary new.
    
    thisContext runSimulated: [test suite run]  contextAtEachStep: [ :current |
           | cls sel methods bytecodes |
           cls := current method methodClass.
           sel := current method selector.
           methods := trace at: cls ifAbsentPut: Dictionary new.
           bytecodes := methods at: sel ifAbsentPut: Set new.
           bytecodes add: current pc.].
    
    result := String streamContents: [:s |
    
    classTrace := trace at: class ifAbsent: nil.
    classTrace
           ifNil: [
                   s nextPutAll: 'Class ', class name, ' not called'; cr. ]
           ifNotNil: [
                   s nextPutAll: class name; cr.
                   class selectorsDo: [:sel |
                           | m usedBytecodes allBytecodes |
                           m := class >> sel.
                           usedBytecodes := (classTrace at: sel ifAbsent: Set new) size.
                           allBytecodes := 0.
                           m symbolicLinesDo: [:pc :lineForPC | allBytecodes := allBytecodes + 1 ]..
                           s tab; nextPutAll: sel; nextPutAll: ' - '; nextPutAll:
    (usedBytecodes  /  allBytecodes * 100) asFloat asString; nextPutAll:
    '%'; cr. ]].
    ].
    result.

    Zobrazit zdrojový kód metody se zvýrazněním nepokrytých částí také není nic složitého

    class := Time.
    selector := #print24:showSeconds:on:.
    m := class >> selector.
    usedBytecodes := ((trace at: class) at: selector ifAbsent: Set new).
    allBytecodes := Set new.
    m symbolicLinesDo: [:pc :lineForPC | allBytecodes add: pc ].
    unusedBytecodes := allBytecodes copyWithoutAll: usedBytecodes.
    
    dm := m debuggerMap.
    source := (class sourceCodeAt: selector) asText.
    unusedBytecodes do: [:pc |
           range := dm rangeForPC: pc contextIsActiveContext: false.
           source makeBoldFrom: range first to: range last.].
    source asMorph openInWindow.
    Mír je, když se střílí jinde.
    30.3.2012 09:17 Pavel Křivánek | skóre: 24 | blog: Kvičet nezávaznou konverzaci
    Rozbalit Rozbalit vše Re: Rychlost CogVM

    Můžete brát image jen jako bonus. Pokud použijete malou image bez GUI a nástrojů, jen s překladačem a základními knihovnami, pak se Smalltalk v používání nijak neliší od Ruby nebo Pythonu.

    Smalltalk nechápe program jako soubor zdrojových kódů, ale jako systém vzájemně komunikujích objektů.

    Mír je, když se střílí jinde.
    Bystroushaak avatar 30.3.2012 12:15 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Rychlost CogVM
    Smalltalk nechápe program jako soubor zdrojových kódů, ale jako systém vzájemně komunikujích objektů.
    To je to co se mi na něm právě líbí a proč mi přijde, že má budoucnost.
    30.3.2012 18:32 Miloslav Ponkrác
    Rozbalit Rozbalit vše Re: Rychlost CogVM
    Pokud chápete objektové paradigma jako jedině správné a jediné, které by mělo existovat, pak ano.

    Ale myslím si, že je to jinak.
    Bystroushaak avatar 30.3.2012 21:21 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Rychlost CogVM
    :). To jsem přeci nepsal. Osobně vnímám objektové paradigma jako dost životaschopné, ale není to žádné náboženství a nedělá mi problémy zabřednout do jiných konceptů, jako je třeba rebol, jenž studuji poslední dobou..

    Jde o to, že jednoho dne budou počítače s lidmi provázané o hodně více, než jak je to dneska. Stále ještě interagujem s HW, což jednou zmizí a bude probíhat interakce prakticky jen se SW. Jsem zvědavý, co budeme používat za jazyky v době, kdy padne 2D omezení monitoru, nebude rozdíl mezi pevným diskem a RAM pamětí, internetové připojení bude všudypřítomné a programovací jazyky budou od HW vzdáleny jak čistá matematika. V té době imho bude smalltalk stále užitečný.
    oryctolagus avatar 30.3.2012 18:48 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Rychlost CogVM
    To je to co se mi na něm právě líbí a proč mi přijde, že má budoucnost.
    Je to hezké, ale pro budoucnost jazyka to určitě není podmínka postačující...
    There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
    29.3.2012 15:21 Miloslav Ponkrác
    Rozbalit Rozbalit vše Re: Rychlost CogVM
    Děkuji za článek. Také je vidět vzácná snaha o serióznost a je v něm plno užitečných informací.

    Smalltalk mám jako jazyk rád.

    Jediné co je slabší je poslední odstavec.
    31.3.2012 02:45 blizzz | blog: Filmy
    Rozbalit Rozbalit vše Re: Rychlost CogVM
    chcel by som si skusit nejaky pure objektovy jazyk message passingom najlepsie na vyvoj web apps. tak som si stiahol Seaside, to IDE alebo co to je vyzera, uplne inak ako bezne vyvojove nastroje na ktore som zvyknuty, absolutne som v tom strateny neviete niekto poradit nejake screencasty / tutorialy?
    31.3.2012 07:53 Pavel Křivánek | skóre: 24 | blog: Kvičet nezávaznou konverzaci
    Rozbalit Rozbalit vše Re: Rychlost CogVM
    Mír je, když se střílí jinde.
    1.4.2012 07:36 Ales Hakl
    Rozbalit Rozbalit vše Re: Rychlost CogVM
    Ze ST/X neumi kontinuace neni ani tak o optimalizacich, ktere provadi JIT, ale o celkove implementacni strategii toho VM. Velka cast toho systemu je kompilovana pomoci stc, coz je ahead of time kompilator z ST do C, ktery produkuje temer normalni (a prekvapive vcelku citelny) C kod a tak je potreba, aby volaci konvence pouzivana uvnitr VM byla alespon trochu obdobna C, coz vede na pouzivani Cckoveho stacku primo, coz by v pripade implementace kontinuaci vedlo na kopirovani obrovskych bloku pameti sem a tam (coz je mimochodem zpusob, jak kontinuace implementuje MRI, takze to neni uplne mimo misu, ale stejne me to prijde jako vcelku spatny napad).

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.