Příspěvky

2446

Vývoj / Re:Jak mam programovat v Node.js?

« kdy: 25. 05. 2019, 08:31:28 »

javascript má typy hodnot.

Přesně. V Javascriptu není typ atributem proměnné, ale hodnoty, která je v ní uložena.

Jistě. Říkal jsem si, zda tam mám pro některé doplňovat poznámku pod čarou, nebo zda mám odpověď formulovat pro původního tazatele a nekomplikovat ji pro něj zavádějícími odbočkami. Zvolil jsem druhou variantu.

Napadlo me toto, co kdybych udelal design tak, ze nebudu definovat domenovy model v aplikaci, ale budu ho mit definovan jen v databazi a v aplikaci budu mit jen DAO vrstvu?

To je rozumné řešení pro všechny jednoduché CRUD aplikaci – i pro ty psané v Javě. Akorát je potřeba si dávat pozor na to, že někdy přeci jen alespoň torzo doménového modelu potřebujete – aplikace by přeci jen neměla zapisovat do databáze cokoli, co si uživatel vymyslí, ale měla by dělat doménově specifické validace.

Me se TypeScript vubec nelibi, ja radeji budu delat v tom JS.

To moc nechápu, TypeScript je prakticky JavaScript rozšířený o typy. S doplňováním typů do JavaScriptu pomocí JSDoc nemám moc dobré zkušenosti, podle mne se to hodí jen pro velmi jednoduché typy.

2447

Vývoj / Re:Jak mam programovat v Node.js?

« kdy: 24. 05. 2019, 20:13:23 »

Pokud chcete používat typy, nemůžete psát v jazyce, který typy nemá. Pokud chcete používat JavaScriptové prostředí a  Node.js a zároveň chcete používat typy, pište v TypeScriptu.

2448

Software / Re:Problém se stahováním xml dokumentu

« kdy: 21. 05. 2019, 08:57:58 »

Nemyslím si, že by to bylo kabelem, TCP/IP má kontrolní součty a pakety na sebe musí navazovat, to by vadný kabel těžko zařídil. V tom serveru klidně chyba být může – záleží na časování, velikosti paketů, takže tu chybu může vyvolat specifické (ale správné) chování klienta.

2449

Software / Re:Problém se stahováním xml dokumentu

« kdy: 20. 05. 2019, 20:24:06 »

Ověřte si, že ten soubor stáhnete opravdu takhle – nechtě ho wgetem nebo curl uložit přímo do souboru, a pak zkontrolujte, že tam nejsou žádné podivné znaky. Taky by pomohlo nechat si vypsat i HTTP hlavičky. Pokud ten soubor bude opravdu vypadat takhle, je to s největší pravděpodobností chyba toho HTTP serveru. Když si porovnám pravděpodobnost, že je chyba ve wgetu, která se u vás projevuje systematicky, ale nikdo jiný na ni zatím nepřišel; a pravděpodobnost, že ta chyba je v nějakém obskurním HTTP serveru implementovaném na PLC, sázel bych na ten server.

2450

Vývoj / Re:Ideálny programovací jazyk

« kdy: 16. 05. 2019, 22:02:41 »

Když jsem to četl, tak ve mně hrklo, protože co nejmenší počet boxování a unboxování mi přijde jako další neintuitivní past. Naštěstí to není pravda. Když jsem to zkoušel tak mě překladač seřval vždycky. Aspoň v něčem se teda Java chová tak, jak bych čekal.

Aha, ono se rozlišuje jenom žádné (un)boxování, nějaké (un)boxování. Vždyť jsem říkal, že se s tím v praxi nikdo nikdy nepotká.

2451

Vývoj / Re:Ideálny programovací jazyk

« kdy: 16. 05. 2019, 21:58:44 »

Mně by se spíš líbilo to nahradit pěkným, stručným skládáním. Je dost škoda, když je v některých jazycích potřeba celé API vloženého objektu znovu zopakovat na tom vnějším (mám matný pocit, že to tak má někde Rust, ale přesně si to teď nevybavím).

Takže nakonec to přece jenom bude JavaScript? ;-) (Spread operátor na objektových literálech v ECMAScript 2018.)

2452

Vývoj / Re:Ideálny programovací jazyk

« kdy: 16. 05. 2019, 21:52:42 »

No, nevychází, že 
Přesně tak. Čitelnější to být nemůže.

Jasně, v prvním případě hodnota pro pravdivý výrok, v druhém případě hodnota pro pravdivý výrok. V tom je takový rozdíl… Já už vážně nevím, co tam vidíte za rozdíl. Jako ano, jednou je tam true a po druhé True, jednou malé „t“ a podruhé velké „T“. Ale důvod, proč se liší velikost toho T snad chápete, ne?

Ano, přesně jak jsem předpovídal, následuje nářek, že jsem sice celou dobu psal o operátoru ==, ale to jsem určitě udělal naschvál, aby si BoneFlute myslel, že píšu o ekvivalenci nebo identitě. Zákeřně jsem tam čtyřikrát napsal slovo „operátor, dvakrát == a jednou __eq__, a ještě zákeřnější bylo, že jsem tam slovo „identita“ neuvedl ani jednou. Přeci mi muselo být nad slunce jasné, že si BoneFlute bude myslet, že celou dobu píšu o identitě. Teda ale fuj, že se nestydím.

Java, int: ekvivalence, použije se ==. Porovnání identity, zde popravdě netuším.
Java, objekt: ekvivalence, použije se operátor/metoda equals(). Porovnání identity, použije se operátor ==
Python, int: ekvivalence, použije se operátor ==. Porovnání identity, použije se operátor is.
Python, objekt: ekvivalence, použije se operátor ==, který se interně převede na __eq__. Porovnání identity, použije se operátor is.

Flamewar je sice divná zábava, ale zábava je to jenom dokud ho vedete s chytrými lidmi. Takže BoneFlute, mějte se dobře, naše konverzace tímto končí.

2453

Vývoj / Re:Ideálny programovací jazyk

« kdy: 16. 05. 2019, 21:40:01 »

Takže je to speciální ad-hoc pravidlo jak porovnávat boxované a neboxované věci? Nevyplývá to z nějakého obecnějšího pravidla pro řešení podobných neurčitých situací? Dávalo by mi to smysl i pro výběr přetížených metod, ale tam to evidentně funguje jinak. Čím dál tím lepší...

Ve specifikaci je to speciální pravidlo, když ho budu parafrázovat „pokud jsou oba operandy číslo nebo je jeden operand číslo a druhý je převoditelný na číslo (unboxováním), nejprve se převoditelný typ převede na číslo“. U booleovských hodnot je to podobné.

U metod se vybírá co nejmenší počet boxování/unboxování, a pokud by z toho vyšlo víc metod, je to kompilační chyba (např. dvě metody se dvěma parametry, jedna s malými inty a druhá s velkými Integery a volalo by se to s jedním malým a druhým velkým).

Zkrátka se to chová tak, jak by člověk intuitivně očekával. A na tyhle nuance člověk narazí velmi výjimečně, a pokud by se to náhodou stalo, tak nebude spoléhat na automatiku a udělá ten un/boxing ručně. Teoreticky by z toho posloupností špatných událostí mohla vzniknout chyba, ale až tyhle chyby budou ty nejčastější chyby v softwaru, budeme mít bezchybný software.

2454

Vývoj / Re:Ideálny programovací jazyk

« kdy: 16. 05. 2019, 20:54:57 »

Co mě tu hlavně mate je, že v tomhle případě by se mohlo jak automaticky boxovat tak unboxovat. A ani přečtení dokumentace mi neobjasnilo, co by mělo mít přednost. Jak boxování tak unboxování se má dělat v případě, že se předává parametr nebo přiřazuje do proměnné. Na základě čeho se rozhodne, že se tady má zrovna unboxovat?

U aritmetických operátorů boxování nepřichází v úvahu, dostali bychom zase jen nepřeložitelný kód. No a u komparačních operátorů je za prvé rozumné dělat to stejně, za druhé by boxování bylo s prominutím padlé na hlavu, protože je čistě věcí kompilátoru, jakou referenci vám tam vrátí – a když ta reference mohla právě teď vzniknout, nedává smysl ji porovnávat na rovnost s jinou referencí. Porovnávat reference má smysl tam, kde už je máte z dřívějška uložené (třeba klasická zarážka při hledání v poli).

2455

Vývoj / Re:Ideálny programovací jazyk

« kdy: 16. 05. 2019, 20:48:51 »

Hezkej pokus. Ale uvědomujete si, že si to každý nyní může prohlídnout a bude jim to jasné? 

Mně to jasné je. Bavili jsme se o chování operátoru ==, takže jsem porovnal dva následující příklady (v historii diskuse to lze najít):

Kód: [Vybrat]

public class HelloWorld
{
  public static void main(String[] args)
  {
    Integer a = 1024;
    Integer b = 1024;
    System.out.print(a == b); // false
  }
}

Kód: [Vybrat]

class Integer:
    def __init__(self, value):
        self.value = value

a = Integer(1024)
b = Integer(1024)
print(a == b) #False

Vy jste si v Javě vyrobil vlastní typ Cislo a vyšlo vám to (jaké překvapení) stejně. Pro Python jste tenhle příklad vůbec nenapsal.

Dále jsem psal, že v Pythonu můžete přetížit operátor ==, Java přetěžování operátorů záměrně nepodporuje, ale pro porovnání hodnot objektů používá metodu equals(), kterou přetížit můžete. Psal jsem, že když to přetížení naimplementujete stejně v Pythonu i Javě, opět dostanete stejný výsledek. Kód pro Javu jsem tedy neuvedl, stačilo použít stávající implementaci v java.lang.Integer.equals()…

Tuhle variantu už jste vy naimplementoval pro oba jazyky, a – světe div se – je to jak jsem psal, vychází to v obou jazycích stejně. Dovolte, abych z vašeho kódu ty dva řádky vypíchl:

Kód: [Vybrat]

System.out.println(a.equals(b)); // true
print (a == b) # True – používá se zde přetížený operátor ==

Předpokládám, že teď budou následovat vaše klasické nářky, že jsem sice psal operátor ==, ale určitě jsem tím myslel identitu…

2456

Vývoj / Re:Ideálny programovací jazyk

« kdy: 16. 05. 2019, 20:34:47 »

Už zase nevím, která bije. Tohle bude nějaké další pravidlo toho jednoduchého a předvídatelného jazyka, které tu ještě nezaznělo.

Není to žádné další pravidlo. První porovnání – pokud jsou operandy operátoru == objektové typy, porovnávají se reference (ukazatele). Toto pravidlo už tu bylo zmíněné asi milionkrát. Druhé pravidlo, které už tu také bylo zmíněno, že když kompilátor narazí na aritmetický nebo porovnávací operátor který má takové operandy, že kód bez unboxingu nelze přeložit, zkusí provést unboxing. Opět je to velmi jednoduché pravidlo, zpětně kompatibilní změna – nová funkce (autounboxing) se použije pouze u kódu, který by dříve nebylo možné přeložit.

Mimochodem, řeší se tu pořád umělý příklad – myslím, že tahle diskuse zněkolikanásobila počet výskytů takovéhleho kódu v nám známém vesmíru.

No auto-unboxing... to je podle me opravdu kontraintuitivni. To == mi nevadi, ale to krabickovani me fakt obcas rozciluje.

Ano, někdy je otravný, ale lid si to žádal, prý v zájmu pokroku. Já to používám jedině u parametrů metod nebo při přiřazení návratové hodnoty metody do proměnné. Jakmile by k tomu auto- mělo dojít někde jinde, než přímo u deklarace proměnné nebo předání parametru do metody, dělám tam un/boxing ručně, aby to bylo na první pohled vidět a bylo zřejmé, že to dělám záměrně.

2457

Vývoj / Re:Ideálny programovací jazyk

« kdy: 16. 05. 2019, 20:21:18 »

Tak to mám asi nějaký zkažený vzduch já.

Buď zkažený vzduch a nebo používáte jiný nástroj. Já málokdy překládám Javu z příkazového řádku, použil jsem to, co pro výpis varování používám normálně – IntelliJ Idea.

2458

Vývoj / Re:Ideálny programovací jazyk

« kdy: 16. 05. 2019, 19:39:10 »

Zase špatně: Výsledek není stejný. Python se nechová jako Java. https://gist.github.com/BoneFlute/6c9f56a6b4c164b2fc2f246662daa7a8

Je fajn, že jste si to sám vyzkoušel, a zjistil jste, že je to přesně tak, jak jsem napsal. Akorát pak svůj komentář nezačínejte „zase špatně“, vypadá to, jako když jsem to napsal špatně já. Málokdo pochopí, jak jste to doopravdy myslel – že jste se zase mýlil vy.

2459

Vývoj / Re:Ideálny programovací jazyk

« kdy: 16. 05. 2019, 19:36:21 »

Když dostane pointer a hodnotu, tak ti vynadá kompilátor.

Nikoli.

Jak by řekl klasik: Tak to tady asi máte nějaký zkažený vzduch!

„Vynadá“ jsem chápal tak, že to vůbec nepůjde přeložit. Protože když v Javě porovnáváte reference pomocí ==, také dostanete varování. Takže v tom rozdíl nevidím.

2460

Vývoj / Re:Ideálny programovací jazyk

« kdy: 16. 05. 2019, 19:34:39 »

Ne ty tady od začátku píšeš, jak je porovnání v Javě udělané skvěle, jednoduše, každý to hned pochopí a chyby se v tom nedělají. To je prostě demagogie, obhajuješ špatný design, pravděpodobně z neznalosti.

Demagogie je vkládat mi do úst něco, co jsem nikdy nenapsal. Nikdy jsem nepsal, že je to skvělé. Napsal jsem, že je to jednoduché, a na tom trvám. Že to každý hned pochopí jsem nepsal – psal jsem, že je to jedna z prvních věcí, které se programátor v Javě musí naučit. Že se v tom chyby dělají málokdy jsem napsal a také na tom trvám.

Váš názor, že je to špatný design, vám neberu, ale nesdílím ho. Když vyjdu z předpokladů, že Java má primitivní typy (což je dané historicky a není reálné to v dohledné době změnit) a zároveň nemá přetěžování operátorů (což je záměr, přispívá to k tomu, aby jazyk jako takový byl jednoduchý a předvídatelný), vychází mi z toho, že o dost lepší řešení neexistuje. O něco lepší by bylo operátor == pro objekty úplně zakázat, ale to opět bylo v době vzniku Javy nemyslitelné.

Pokud máte lepší řešení, které splňuje výše uvedené předpoklady, sem s ním. Pokud si myslíte, že některý z těch předpokladů není nutné dodržet, můžete k tomu předložit nějaké argumenty.