Ideálny programovací jazyk

[Ink]

No ale to je rozdíl. Na identitu má "is", což sémanticky přesně sedí a porovnávání operátorem == (pokud to jenom trošku jde) skutečně dělá co má. Zrovna tak tomu je i u < apod. Žádné compareTo() a podobná zvěrstva se nekonají.

defaultne == dela to stejne co is.

A v čem se mnou nesouhlasíš?

[Reklama]

[Tomas-T]

operátor == se z definice nechová špatně. Špatně je, když jazyk dovolí napsat:

Integer a;
Integer b;

.... hodně kódu...

a = 1024;
b = 1024;
if(a == b){
    ...
}

Programátor vidící poslední 3 řádky na první pohled považuje proměnné a a b za primitivní číselné typy a očekává porovnávání hdnot a tedy shodu. Nemá šanci na pohled poznat, že jsou to ve skutečnosti objekty a že bude porovnávat reference a ne hodnoty.
Upozornění v IDE, že porovnává objekty ho může zachránit, ale ne každý editor kódu to umí.

[Mirek Prýmek]

Upozornění v IDE, že porovnává objekty ho může zachránit, ale ne každý editor kódu to umí.

Hlavně IDE by neměl být narovnávák na vohýbáky v jazyce.

[Jiří Havel]

To máš podloženo nějakým průzkumem? Klidně to může být tak, že běžný programátor od jednoduchého jazyka očekává, že == vezme to co má nejvíc po ruce a porovná to a nebude dělat žádnou magii. Když si uvědomíš, že reference je hodnota pointeru, tak to v obou případech dělá to samé - porovnává hodnoty. A možná je to přesně to, co od toho očekává běžný programátor.

"to co má nejvíc po ruce" je hodně neurčitý pojem. Může záviset na implementačních detailech o kterých by běžný programátor neměl ani vědět. Nebo by o nich minimálně neměl být nucený přemýšlet.
Má ten jazyk být jednoduchý na použití, nebo na implementaci? Tyhle dva požadavky jdou trochu proti sobě.

[Filip Jirsák]

Takdy ale vůbec nejde o to, co preferuje Filip Jirsák nebo někdo jiný. Důležité je, co očekává běžný Franta programátor od operátoru ==. Bežný Franta programátor očekává, že to bude porovnávat hodnoty a ne reference a už vůbec neočekává, že se to bude chovat pokaždé jinak podle kontextu.

Pokud běžný Franta programátor očekává něco, co nesplňuje snad žádný programovací jazyk, není programátor. Nebo mi ukažte jazyk, který (alespoň ve výchozím nastavení, tj. bez přetěžování operátorů) porovnává vše podle hodnoty.

běžný Franta programátor je z toho zmatený

Nikoli, programátoři z toho zmatení nejsou a chyby v tom nedělají. Programováním se živím už spoustu let, a že se někdo pokusil v Javě porovnat Stringy pomocí == jsem viděl jednou, v kódu, který ještě ani nebyl commitnutý.

V oborech, kde se pracuje s vážně s bezpečností, existuje pojem lidský činitel. Člověk je totiž ten nejslabší článek řetězu, který způsobuje nejvíce chyb. Když chceme chyby minimalizovat, musíme přizpůsobit design okolních systémů tak, aby s nimi člověk dokázal co nejlépe a nejintuitivněji pracovat. Chování operátoru == v Javě je podobné, jako kdyby někdo vyrobil letadlo, kde bude výškoměr v první polovině stupnice cejchovaný v metrech a v druhé polovině ve stopách. Samozřejmě by s tím šlo létat (a jsem si jistý, že Filip Jirsák bych to bravurně zvládal), ale u normálních pilotů by to způsobovalo zmatek a zbytečné chyby.

Tady docela hezké počtení k zamyšlení, proč by se měl design systému (programovacího jazyka) přizpůsobit člověku a ne opačně: http://projekt150.ha-vel.cz/node/117

S tím, že se má design systému přizpůsobovat člověku a ne opačně, mi mluvíte z duše, propaguju to kudy chodím. Java se k tomu principu postavila tak, že vychází z několika málo jednoduchých principů, které programátor snadno pochopí. Rozdíl mezi primitivními typy a objekty programátor pochopí snadno, a že == u primitivních typů porovnává hodnotu (protože není co jiného porovnávat) a u objektů porovnává referenci, zatímco pro porovnání hodnot slouží metoda equals(), se naučí asi tak v druhé lekci.

Že neprogramátorům vadí chování operátoru == je mi celkem jedno, moc nechápu, proč to řeší. Že to kritizují jenom u Javy, i když úplně stejně to má C, C++, JavaScript, Python a mnoho dalších jazyků (přičemž jen některé umožňují operátor přetížit), to jenom ilustruje úroveň znalostí.

Programátor vidící poslední 3 řádky na první pohled považuje proměnné a a b za primitivní číselné typy a očekává porovnávání hdnot a tedy shodu. Nemá šanci na pohled poznat, že jsou to ve skutečnosti objekty a že bude porovnávat reference a ne hodnoty.
Upozornění v IDE, že porovnává objekty ho může zachránit, ale ne každý editor kódu to umí.

Ano, lze napsat kód prasácky, a když to pak jiné prase čte a očekává něco, co si neověří, skončí to nejspíš chybným kódem. IDE v tomto případě nepomůže, protože programátoři, kteří vyrábí takovýhle kód, varování ignorují.

Mimochodem, představte si, že v tom vašem příkladu a bude float a b bude double. A teď si ještě představte, že ten kód bude C. Nebo C++. To máme ale na světě nepoužitelných jazyků, že? A co je v nich napsáno aplikací…

[Reklama]

[Ink]

Že neprogramátorům vadí chování operátoru == je mi celkem jedno, moc nechápu, proč to řeší. Že to kritizují jenom u Javy, i když úplně stejně to má C, C++, JavaScript, Python a mnoho dalších jazyků (přičemž jen některé umožňují operátor přetížit), to jenom ilustruje úroveň znalostí.

Teď jsem to celé pochopil, naše nedorozumění spočívalo v tom, že já jsem pojem programátor chápal v nějakém smyslu a Ty v jiném (programátor = spokojený javista). Tudíž nemá smysl se o to dál hádat, neb coby člověk, kterého živí hlavně Python (a předtím C++ a C), nemůžu účinně argumentovat.

Akorát bazíruju na tom, že s tím Pythonem jsi nadále mimo. Rozvádět spor do dalších jazyků nemá smysl, akorát dodám, že JavaScriptem bych se fakt neoháněl, protože to je bastl z definice (už jenom ta jejich vnitřní reprezentace čísel - tfuj!).

[linuxak]

Nebo mi ukažte jazyk, který (alespoň ve výchozím nastavení, tj. bez přetěžování operátorů) porovnává vše podle hodnoty.

Rust. Reference porovnávat nelze, vždy se porovnávájí hodnoty. Pokud chci porovnat reference, musím je explicitně přetypovat na raw pointer.

Nikoli, programátoři z toho zmatení nejsou a chyby v tom nedělají. Programováním se živím už spoustu let, a že se někdo pokusil v Javě porovnat Stringy pomocí == jsem viděl jednou, v kódu, který ještě ani nebyl commitnutý.

Tak to jsi toho asi ještě viděl málo. Namátkou: https://github.com/swagger-api/swagger-codegen/commit/0d14496bd6fbdbd763844f239b34e198459fe4d9

Že neprogramátorům vadí chování operátoru == je mi celkem jedno, moc nechápu, proč to řeší. Že to kritizují jenom u Javy, i když úplně stejně to má C, C++, JavaScript, Python a mnoho dalších jazyků (přičemž jen některé umožňují operátor přetížit), to jenom ilustruje úroveň znalostí.

I to zastaralé C++, které má k dokonalosti hodně daleko, to má udělané líp než Java. Reference porovnávají hodnoty, pointery taky porovnávají hodnoty pointerů. Takový zmatečný kód, jako v Javě:

Kód: [Vybrat]

Integer a;
Integer b;

.... hodně kódu...

a = 1024;
b = 1024;
if(a == b){
    ...
}
nejde v C++ vyrobit, přiřazení konstanty do pointeru skončí chybou při kompilaci.

[Jiří Havel]

Takdy ale vůbec nejde o to, co preferuje Filip Jirsák nebo někdo jiný. Důležité je, co očekává běžný Franta programátor od operátoru ==. Bežný Franta programátor očekává, že to bude porovnávat hodnoty a ne reference a už vůbec neočekává, že se to bude chovat pokaždé jinak podle kontextu.

Pokud běžný Franta programátor očekává něco, co nesplňuje snad žádný programovací jazyk, není programátor. Nebo mi ukažte jazyk, který (alespoň ve výchozím nastavení, tj. bez přetěžování operátorů) porovnává vše podle hodnoty.

Žádný? Třeba takový Haskell to umí porovnávání podle hodnoty generovat hodně pěkně. A i to pitomé C++ kód nezkompiluje, pokud autor knihovny ten operátor porovnání nevytvoří. Ano, mluvím o porovnávání podle hodnoty psaném programátorem. O porovnávání podle hodnoty ve vychozím nastavení tu totiž kromě vás nemluví vůbec nikdo.

Že neprogramátorům vadí chování operátoru == je mi celkem jedno, moc nechápu, proč to řeší. Že to kritizují jenom u Javy, i když úplně stejně to má C, C++, JavaScript, Python a mnoho dalších jazyků (přičemž jen některé umožňují operátor přetížit), to jenom ilustruje úroveň znalostí.

Už jsem to tu minimálně jednou psal, ale C++ to tak vážně nemá. Automaticky žádné operátory porovnávání negeneruje. Ten operátor porovnávání musí vždycky vytvořit autor knihovny.
Aby se v C++ vůbec dala porovnat identita objektů, musím na ně získat ukazatele a porovnat hodnoty těch ukazatelů. Tohle funguje úplně jinak než v Javě, kde objekt nemůže existovat bez ukazatele na něj. V C++ na spoustu objektů ukazatele nemám a nepotřebuju.
Slovo ukazatel místo slova reference jsem použil záměrně. Reference v C++ fungují o dost jinak než reference v Javě. Ty jazyky se liší dost fundamentálně.

[BoneFlute]

Třeba ty zmíněné atomy v Erlangu jsou taky vnitřně uložené jako integery (takže obdoba ukazatelů), ale je jasně zadefinované, že když vytvářím atom třeba ze stringu, tak buďto v "cachi"/"poolu" už je, potom se ten integer zaručeně použije, nebo tam není, tak se vytvoří a pro příští volání se stejnou hodnotou bude platit první varianta.

Nebo jednou větou: podle mě by to singleton buď měl nebo neměl být z definice.

Já si soukromě myslím, že číslo by singleton být měla. A nejenom číslo.

Mám číslo nebo objekt. Obvykle s ním pracuju jako s hodnotou. (To, že neustálé kopírování je drahé je mi jasné. Ale to je technickej detail, a dá se to řešit.) Ale někdy chci někam poslat objekt (nebo číslo), a chci, aby mi ho dotyčný změnil. Takže tam pošlu referenci. Referenci na to číslo nebo objekt.

Ano, takto to u ideální jazyka chci.

Hezky to má Rust. Použitelně to má Python (== versus is). V případě Javy je to pochybení, ale tak je to historie, nemusíme je v tom máchat.

[nula]

každý operátor rovnosti, který podporuje i něco jiného, než primitivní typy, je kontraintuitivní, protože u složitějších typů vždy narazíme na to, že prostě není jasné, co je to rovnost.

Nemohu souhlasit. Stačí se na to dívat tak, že porovnáváte hodnotu versus identitu, a není problém.

Co naopak problém je, jsou technické/výkonnostní potíže. Ostatně proto, se soukromě domnívám, ty objekty jsou řešené jako reference.

No a problem je, ze v jave operator == neporovnava ani identitu ani hodnotu. On teda se snazi porovnavat identitu, ale z navrhu jinych casti jazyka (napr cachovani hodnot Integeru) zpusobuje, ze neresi ani identitu, takze ten operator ma v podstate nedeterministicke chovani(protoze specka rika jen minimalni pocet cachovanych hodnot).

[Mirek Prýmek]

co nesplňuje snad žádný programovací jazyk, není programátor. Nebo mi ukažte jazyk, který (alespoň ve výchozím nastavení, tj. bez přetěžování operátorů) porovnává vše podle hodnoty.

Prakticky kazdy funkcionalni jazyk? Prakticky kazdy jazyk se strukturalnim typovanim?

Samozrejme bez "neceho jako pretypovani" to nejde, respektive by to nebylo uplne prakticke - sam jste psal, ze relaci ekvivalence je hodne, takze pri definici typu se proste dost hodi rict, kterou z nich chci Jak psal kolega: obvykle to ani nemusim psat, nejtypictejsi pripad si umi prekladac snadno odvodit (porovnani po slozkach).

Nikoli, programátoři z toho zmatení nejsou a chyby v tom nedělají. Programováním se živím už spoustu let, a že se někdo pokusil v Javě porovnat Stringy pomocí == jsem viděl jednou, v kódu, který ještě ani nebyl commitnutý.

Pekna. A mate rad i tu o Budulinkovi?

Že neprogramátorům vadí chování operátoru ==

Konecne jsem to pochopil, vy jste tady jediny programator a vsichni ostatni jsou...

asi lopaty, co?

, moc nechápu, proč to řeší.

Jo, to je videt, protoze porad melete ty same veci dokola a vubec nereflektujete, co vam tady lidi rikaji.

úplně stejně to má C, C++, JavaScript, Python a mnoho dalších jazyků (přičemž jen některé umožňují operátor přetížit)

To je jako byste napsal, ze ze Lojza ma jednu ruku a uplne vsichni ostatni lidi jsou na tom stejne, akorat nekteri z nich maji dve.

OMG!

, to jenom ilustruje úroveň znalostí.

Uz chapu, proc se za Javu tolik plati. Odpovida to urovni ega.

Ano, lze napsat kód prasácky, a když to pak jiné prase čte a očekává něco, co si neověří,

Nedej matko prirodo, aby si to ten ubohy nedouk dokonce vyzkousel - akorat na tzv. "malych cislech"

Mimochodem, představte si, že v tom vašem příkladu a bude float a b bude double.

Predstavoval jsem si to tak silne, az se mi to zhmotnilo: https://play.golang.org/p/Jw9NlBT_VC_1

[Mirek Prýmek]

V případě Javy je to pochybení, ale tak je to historie, nemusíme je v tom máchat.

Jedinej, kdo se tady v tom macha, je Filip. Urcite to neni jediny zdejsi javista. Kdyby neobhajoval neobhajitelne pruhlednymi demagogiemi a rekl "jasny hosi, tohle muze nekoho zmast, ale jinak je ta Java stejne docela fajn, ne?", nerekl by nikdo ani popel.

[nula]

Nemá vliv na návratové hodnoty operátoru. Operátor == v Javě při použití na objekty porovnává reference. Integer ani String nejsou definovány jako singletony, takže v běžící aplikaci může existovat víc instancí, které shodou okolností obsahují stejnou hodnotu. Pokud tedy operátorem == porovnávám reference ukazující na stejnou hodnotu, je věcí náhody, zda dostanu true nebo false. Pool opakovaně používaných instancí akorát zvyšuje pravděpodobnost, že se pro stejnou hodnotu použijí stejné instance, ale nikdo nemůže zaručit, že nevznikne jiná instance se stejnou hodnotou.

Ne, tohle neni nemusi byt zadna hruba chyba a doufam, ze tyhle nesmysly nevykladate juniorum. Je presne definovano, kdy se to rovnat musi a je to i zduvodnene. Naopak idealne by se chtelo, aby se to rovnalo, ale z performance duvodu to neni vyzadovane v celem oboru platnosti danych typu. Rikate to presne opacne nez to je.

If the value p being boxed is an integer literal of type int between -128 and 127 inclusive (§3.10.1), or the boolean literal true or false (§3.10.3), or a character literal between '\u0000' and '\u007f' inclusive (§3.10.4), then let a and b be the results of any two boxing conversions of p. It is always the case that a == b.

Ideally, boxing a primitive value would always yield an identical reference. In practice, this may not be feasible using existing implementation techniques. The rule above is a pragmatic compromise, requiring that certain common values always be boxed into indistinguishable objects. The implementation may cache these, lazily or eagerly. For other values, the rule disallows any assumptions about the identity of the boxed values on the programmer's part. This allows (but does not require) sharing of some or all of these references. Notice that integer literals of type long are allowed, but not required, to be shared.

This ensures that in most common cases, the behavior will be the desired one, without imposing an undue performance penalty, especially on small devices. Less memory-limited implementations might, for example, cache all char and short values, as well as int and long values in the range of -32K to +32K.

https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.7

A to je pekny priklad neintuitivnosti jazyka.

[BoneFlute]

V případě Javy je to pochybení, ale tak je to historie, nemusíme je v tom máchat.

Jedinej, kdo se tady v tom macha, je Filip. Urcite to neni jediny zdejsi javista. Kdyby neobhajoval neobhajitelne pruhlednymi demagogiemi a rekl "jasny hosi, tohle muze nekoho zmast, ale jinak je ta Java stejne docela fajn, ne?", nerekl by nikdo ani popel.

Já vím 

[BoneFlute]

Mimochodem, představte si, že v tom vašem příkladu a bude float a b bude double.

Predstavoval jsem si to tak silne, az se mi to zhmotnilo: https://play.golang.org/p/Jw9NlBT_VC_1

+1