Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Ink

Stran: 1 ... 24 25 [26] 27
376
Vývoj / Re:Ideálny programovací jazyk
« kdy: 16. 05. 2019, 10:06:37 »
Každé jedno špatné rozhodnutí, na kterém se trvá, vede k sérii marných snah o nápravu a pak je jako "řešení" nabídnuto vysvětlení, proč to je vlastně v pořádku.

Jistě, ale vzhledem k tomu, kdy Java vznikla, je její návrh ještě poměrně snesitelný.

Tohle je subjektivní, určitě to mohlo být horší a určitě i výrazně lepší (například dodnes kroutím hlavou nad hloupým původním návrhem kolekcí před zavedením generik). Spíš mi vadí ale ta zabedněnost, s jakou se u ní na některých zjevných chybách lpí.

377
Vývoj / Re:Ideálny programovací jazyk
« kdy: 16. 05. 2019, 10:01:06 »
Pokud jste to nepochopil, argumenty vám ještě zopakuju. Problém vašeho teoretického řešení je v tom, že neexistuje jednoznačná hranice mezi tím, co je a není číslo, stejně jako často neexistuje jednoznačná definice toho, co znamená porovnání hodnot.

Obecně sdílená představa o tom, co je číslo, je prokazatelně větší, než to, co Java milostivě umožňuje sčítat pomocí operátoru +. A nemusíme zacházet ani do nějakých specialit, stačí BigInteger, to je číslo z definice.

Přípustné a legitimní jsou samozřejmě oba dva způsoby. Jak ten, který používá třeba C++ – zavedeme do jazyka novou kategorii „číslo“, přesněji „cokoli, co se dá sčítat“ (aniž by ta kategorie nutně musela být ve specifikaci), a umožníme každému programátorovi, aby si do této kategorie zařadil své typy. Výhodou je, že se pak opravdu dá zajistit, že všechna „čísla“ se sčítají pomocí +. Nevýhoda je ta, že se lidé neshodnou na tom, co vše patří pod čísla, takže se pak programátor musí učit další věc, která navíc platí jenom v daném projektu – co jsou a co nejsou čísla. To, že si v C++ vlastně můžu vytvořit svůj vlastní jazyk, který velice stručně popisuje mou třídu problému, je velice silná vlastnost C++ – proto je také tak oblíbené. Zároveň ta vlastně nepřeberná šíře možností, která způsobuje, že už snad nikdo nemůže znát celý jazyk, je silným negativem, pro které se spousta lidí C++ vyhýbá.

Problém Tvého argumentu je, že ty způsoby nejsou dva, ale minimálně tři. Lisp, Haskell a další jazyky už desítky let ukazují, že "operátor" není nic jiného, než (typicky infixová) funkce (jejíž název není alfanumerický/slovní, nýbrž složený ze symbolů) se dvěma argumenty (no, ještě jsou unární a ternární, ale to už je detail). Že je vhodné nechat "operátoru" + význam sčítání, na tom se všichni asi shodnou. V tomto kontextu je zajímavé, že operuješ zrovna C++ a ne alespoň C#, což je jazyk bližší Javě a "přetěžování operátorů" má taky.

Mimochodem, je pozoruhodné, že se to chování, že + sčítá jen primitivní typy a == porovnává primitivní typy podle hodnot a objekty podle referencí, se tu vytýká zrovna Javě, která má tuhle základní sadu pravidel nejmenší z podobných často používaných jazyků. Přitom stejná pravidla platí v C, C++, JavaScriptu nebo Pythonu. V C++ nebo Pythonu ty operátory můžete (ale nemusíte) přetížit. Ale klidně si dál myslete, že C, C++, Javu, JavaScript i Python navrhovali hlupáci, kteří chování operátorů navrhli špatně, a měli se s vámi nejdřív poradit.

Tohle je straw man fallacy. Nikde jsem netvrdil, že nějaký jazyk navrhovali hlupáci. Ale třeba na C++ i Pythonu je vidět, že některá rozhodnutí tvůrci časem přehodnotili, Python se ve verzi 3 vydal dokonce cestou rozbití kompatibility (unicode vs string, zahození "klasických tříd", je toho hodně). Jak jsem psal v předchozím příspěvku - trvat na správnosti nějakého rozhodnutí poté, co se ukáže, že to byla chyba, je prostě kontraproduktivní. Mezitím na javovské platformě vznikly minimálně 4 další jazyky, které se snaží být lepší Javou a to přesto, že se (neochotně a pomalu) Java také vyvíjela.

Navíc by mě zajímalo, v čem podle Tebe dělá Python == jako Java. Dělá to stejně jenom u "hloupých" objektů, chytrý objekt si umí říct, jestli jeho vnitřek odpovídá druhému objektu.

378
Vývoj / Re:Ideálny programovací jazyk
« kdy: 16. 05. 2019, 06:10:11 »
Každé jedno špatné rozhodnutí, na kterém se trvá, vede k sérii marných snah o nápravu a pak je jako "řešení" nabídnuto vysvětlení, proč to je vlastně v pořádku.

Každý programátor, pokud mu někdo v rané fázi vývoje nevymyje hlavičku, očekává a chce, aby se čísla sčítala pomocí + a odčítala pomocí -. Jelikož se někdo, kdo rozhodoval o tom, co v Javě smí být a co nesmí, bál "přetěžování operátorů", má Java čísla, která se sčítají normálně přes + a pak čísla, která používají "add()", protože to "jinak nejde".

Úplně stejné to je s tím == a .equals(). Samozřejmě, že "každý" chce porovnávat dvě hodnoty a ne "identitu", když sáhne po ==. Jenže Řád zlatého šálku si na to vymyslí equals() a když děcko řekne, že císař je nahý, v poklidu děcko obviní z hlouposti nebo neznalosti a odkáže ho k četbě posvátných svitků, kde je jasně uvedeno, že císař je oděn vznešeností, což, jak jistě uznáte, není totéž co nahota.

379
Vývoj / Re:Ideálny programovací jazyk
« kdy: 08. 05. 2019, 09:50:02 »
Každý jazyk má omezenou "ideální oblast", kde bude excelovat, čím dále od ní bude, tím to více dře. Na jedné straně je vysokoúrovňový (v zásadě deklarativní, lidsky srozumitelný) popis problému a na druhé optimalizovaný výpočet blízko konkrétnímu železu. Různé chytré kompilátory a "bezplatné abstrakce" se snaží tu vzdálenost překlenout, ale zatím se nezdá, že by to šlo dokonale.

Ideální programovací prostředí je podle mě takové, které umožní ponechat ten deklarativní popis problému co nejširší a chytře vkládat konkrétní kousky, které řeší tu nízkoúrovňovou optimalizaci, aniž by ohrozily bezpečnost a správnost výpočtu. Z konkrétních jazyků bych řekl, že má správným směrem nakročeno třeba Rust, ale uvidíme, kam se to bude vyvíjet.

380
Odkladiště / Re:Je swapu třeba?
« kdy: 13. 04. 2019, 14:50:33 »
Swap se hodí, jelikož nikdy nevíš, který program se "zblázní" a začne žrát paměť jak zjednaný - typicky to dělají browsery, sice záleží na tom, jak je používáš, ale stejně... Já jsem si kdysi myslel, že když není swap a paměť dochází, přijde OOM killer a sejme Chrome, ale ne, systém chroupá dlouhé minuty a pak člověk raději dá restart. 16 GB RAM je rozumné minimum, žádný velký luxus.

381
Software / Re:Nahradenie hex stringu
« kdy: 10. 03. 2019, 18:45:01 »
OK, tohle mi smysl dává, dík.

382
Software / Re:Nahradenie hex stringu
« kdy: 10. 03. 2019, 17:15:13 »
Jo, a jak poznám, kdy mi to odswapuje a kolik to skutečně sežere paměti? Co jsi mi chtěl vlastně sdělit konkrétního?

to nepotrebujete vedet. Ani pri tom "sekvencnim" cteni neznate velikost bufferu.

OK, řešení Kamila P. funguje, 16 GB  soubor to prohrabalo, sežralo cca 4,5 GB RAM a nespadlo to.

383
Software / Re:Nahradenie hex stringu
« kdy: 10. 03. 2019, 16:50:19 »
3. Dovedu si samozřejmě představit, že je OS "chytrý" a dokáže podle potřeby uvolňovat kusy paměti, ale přijde mi to celé proti filosofii a smyslu toho mechanismu. Jednak on nemůže vědět, kam si budu chtít sáhnout hned v další operaci (tudíž se to celé může dost prodražit) a vůbec asi pro rychlou práci nechci takto nedeterministické chování systému.
Smysl mmapu je právě v tom, že k datům přistupujete jako k souvislému bloku paměti, a OS se na pozadí stará o nahrávání příslušných bloků z disku do paměti a opačně o zápis na disk. Je to vlastně podobný mechanismus, jako swap, akorát se na disk zapisují jen změněná data a zapisují se do toho původního souboru.

Jo, a jak poznám, kdy mi to odswapuje a kolik to skutečně sežere paměti? Co jsi mi chtěl vlastně sdělit konkrétního?

384
Software / Re:Nahradenie hex stringu
« kdy: 10. 03. 2019, 14:11:15 »
https://en.wikipedia.org/wiki/Demand_paging

Cele nacitanie suboru vznika len v pripade ak robis "read all" operacie. Cize bezne sa subory prechadzaju riadok za riadkom, pripadne v blokoch, len malokedy sa nacitaju cele do pamete. Je jedno o aky jazyk ide.

To mi nedává moc smysl:

1. Jestli si načtu do paměti obsah celého souboru najednou, nebo po kouskách, do toho mmapu nic není. To je věc aplikace.

2. Hledání podřetězce v souboru přece je v nejhorším případě opravdu "read all".

3. Dovedu si samozřejmě představit, že je OS "chytrý" a dokáže podle potřeby uvolňovat kusy paměti, ale přijde mi to celé proti filosofii a smyslu toho mechanismu. Jednak on nemůže vědět, kam si budu chtít sáhnout hned v další operaci (tudíž se to celé může dost prodražit) a vůbec asi pro rychlou práci nechci takto nedeterministické chování systému.

385
Software / Re:Nahradenie hex stringu
« kdy: 10. 03. 2019, 13:32:53 »
Hm, nevadí vám, že se soubor při takto jednoduchém použití mmap musí celý vejít do RAM? Nebo mi něco uniká?

386
Software / Re:Nahradenie hex stringu
« kdy: 10. 03. 2019, 10:59:53 »
Tohle je výrazně optimálnější, i bez mmap()...

#!/usr/bin/env python3

import sys


def regions(f):
    chunkLength = 50000000
    offset = 0
    c1 = f.read(chunkLength)
    while (len(c1) == chunkLength):
        c2 = f.read(chunkLength)
        yield offset, c1 + c2
        c1 = c2
        offset += chunkLength
    yield offset, c1


def findIndex(f, s):
    for offset, chunk in regions(f):
        index = chunk.find(s)
        if (index >= 0):
            return offset + index

    return -1


def write(f, index, s):
    f.seek(index)
    f.write(s)


def replace(fn, ih, oh):
    f = open(fn, "rb+")
    index = findIndex(f, bytes.fromhex(ih))
    if (index == -1):
        print("Not found")
    else:
        write(f, index, bytes.fromhex(oh))
    f.close()


if __name__ == '__main__':
    if (len(sys.argv) != 4):
        print("Usage: %s filename inhex outhex", sys.argv[0])
    else:
        replace(sys.argv[1], sys.argv[2], sys.argv[3])

387
Software / Re:Nahradenie hex stringu
« kdy: 10. 03. 2019, 10:29:16 »
to je hodne neefektivni. Pouzijte radeji mmap.

Tohle mě zajímá. Soubor se čte sekvenčně, pravděpodobně s bufferováním. Zapisuje se stejně dlouhý řetězec, tudíž se v souboru nic neposouvá. Co na tom vylepší mmap?

Asi bude rychlejší použít find(), o tom žádná. Ale pak člověk musí řešit přesahy apod. Já jsem napsal rychlořešení za dvě minuty, ani jsem netvrdil, že to je dokonalé řešení.

388
Software / Re:Nahradenie hex stringu
« kdy: 10. 03. 2019, 10:18:19 »
to je hodne neefektivni. Pouzijte radeji mmap.

Tohle mě zajímá. Soubor se čte sekvenčně, pravděpodobně s bufferováním. Zapisuje se stejně dlouhý řetězec, tudíž se v souboru nic neposouvá. Co na tom vylepší mmap?

389
Software / Re:Nahradenie hex stringu
« kdy: 09. 03. 2019, 08:45:25 »
Bez zaruky a bez krasy:

#!/usr/bin/env python3

import sys

def findIndex(f, sa):
    ri = 0
    ra = []
    sl = len(sa)
    while True:
        try:
            b = f.read(1)
            if (len(b) == 0):
                raise EOFError()
            ra.append(b[0])
        except EOFError:
            return -1
        ri += 1
        if (len(ra) > len(sa)):
            ra.pop(0)
        if (ra == sa):
            return ri - sl


def write(f, index, s):
    f.seek(index)
    f.write(s)


def replace(fn, ih, oh):
    f = open(fn, "rb+")
    index = findIndex(f, list(bytes.fromhex(ih)))
    if (index == -1):
        print("Not found")
    else:
        write(f, index, bytes.fromhex(oh))
    f.close()


if __name__ == '__main__':
    if (len(sys.argv) != 4):
        print("Usage: %s filename inhex outhex", sys.argv[0])
    else:
        replace(sys.argv[1], sys.argv[2], sys.argv[3])

390
Vývoj / Re:Čo sa stalo s WebAssembly?
« kdy: 06. 02. 2019, 07:25:52 »
Podle čeho usuzuješ? Třeba Rust & WASM je můj denní chléb. Používáme ho na knihovny kde chceme sdílet kód, který má ve výsledku běžet nativně, v NodeJS a v prohlížeči. Dřív bylo všechno v JS, ale to nám už na IoT zařízeních nevyhovuje, proto tahle cesta. Jeden zdroják a z něho generuju Rust crates (knihovny) a NPM balíčky pro použití v JS.

Ještě to není tak rozšířené, i když už je to lepší, protože nástroje jsou stále nedokonalé. Ve smyslu balení NPM balíčků (wasm-pack, ...), generování JS wrapperu (wasm-bindgen, ...), atd. Funguje to, ale má to své mouchy. A zároveň ještě nedávno nebylo úplně jednoduché napsat něco co běží všude - např. když jsi používal náhodné generátory, ... Teď už je to celkem pohoda.

A nechceš se pochlubit víc? Firma, nějaké technologické zajímavosti ohledně wasm targetu, jak dlouho používáte Rust, jestli jedete na stable verzi apod.? Díky předem.

Stran: 1 ... 24 25 [26] 27