Příspěvky

2491

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

« kdy: 15. 05. 2019, 19:54:51 »

No ale tohle je přesně to, na co narážím. Funkce equals nebo operátor== můžou být úplně stejně neintuitivní a matoucí. Zákaz přetěžování operátorů nevyřeší vůbec nic. Když autor knihovny pojmenuje funkci blbě, tak je vlastně úplně jedno jaké přesné ascii znaky to jsou.

V Javě právě úplně stejně neintuitivní a matoucí být nemohou. Protože operátor == je definován specifikací Javy a žádný uživatel nemůže udělat matoucí variantu operátoru ==. Jediné, co je na operátoru == v Javě matoucí, je to, že ho lze použít i na porovnání objektových typů a pak porovnává reference. Na druhou stranu, když se podíváte na okolní jazyky, má to tak i C, C++, JavaScript – a pro někoho by zase bylo matoucí, kdyby Java operátor == pro objekty měla zakázaný.

2492

Server / Re:Email z cronu přes vzdálený SMTP server

« kdy: 15. 05. 2019, 16:30:51 »

to SSMTP bu de zrejme presne to co hladam.

Na vašem místě bych se podíval aspoň na msmtp a OpenSMTPD. U toho SSMTP bych se fakt bál, že to za rok za dva budete stejně měnit za něco z předchozích.

2493

Server / Re:Email z cronu přes vzdálený SMTP server

« kdy: 15. 05. 2019, 16:28:22 »

Pletes si unmaintained a unsupported, SSMTP je jen nespravovany, hlavne ale ta zminka je na ArchWiku, tedy rolovacim diatru, tazatel se pta na Ubuntu 16.04 kde je samizrejme stejne starsi verze a podporovana/spravovana... pouzivam SSMTP v Ubuntu 18.04.

Odkaz na web SSMTP vede na Debian, a v Debianu je také unmaintained. Já si to vykládám tak, že už se ten projekt dál nevyvíjí, takže když to instaluju nově a existují alternativy, použiju raději tu alternativu, která před sebou má jistější budoucnost. Že je to ve staré verzi Ubuntu je hezké, ale proč teď instalovat něco, co třeba už v příští verzi Ubuntu nebude, když existují minimálně rovnocenné alternativy? Na wiki Archu jsem odkázal proto, že jsou tam nějaké alternativy vyjmenované a je tam popsané, co to SSMTP je – takže tazatel případně sám může hledat alternativy, protože už ví, co vlastně hledá.

2494

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

« kdy: 15. 05. 2019, 16:13:12 »

JS pretezovani operatoru take neumoznuje.

Sice ne, ale zrovna pro JavaScriptové == existuje spousta takových těch příkladů–chytáků, kdy se máte snažit uhodnout, jak se ten kód vyhodnotí – a málokdo to trefí.

2495

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

« kdy: 15. 05. 2019, 16:11:48 »

Tak tady bych silně nesouhlasil. Jsem C++ programátor a od operátorů očekávám, že čertoviny dělat nebudou. A taky ve všech knihovnách, které používám, žádné čertoviny nedělají.

Třeba to, že se operátor > používal pro zápis do streamu (což je blokující operace, navíc může vyhodit výjimku), tu už se v C++ nedělá?

Úplně stejně očekávám od metod, že budou dělat to, co vyplývá z jejich jména.

To já také. Jenže u spousty typů je tolik různých variant, co může dělat add() nebo equals()… Třeba máte dvě instance reprezentující v DOM následující dva XML elementy:

Kód: [Vybrat]

<f:element xmlns:f="http://example.com/namespace" />
<x:element xmlns:x="http://example.com/namespace" />

Má equals() vracet true nebo false?

Opravdu Javisti automaticky počítají s tím, že uživatelsky implementovaný kód může dělat cokoliv? Na takovéhle prasení vážně nejsem zvyklý a celkem mě překvapuje.

S tím počítají všichni dobří programátoři. Nejde o to, že by ten kód dělal něco nepředvídatelného (i když i to se stává). Ale když mám třeba kolekci, za kterou mám lokální nebo dokonce síťovou databázi, počítám s tím, že volání add() může trvat dlouho nebo může skončit třeba síťovou výjimkou. Když volám equals() na databázové entitě, ověřím si, zda se identita zjišťuje podle primárního klíče, podle hodnot nebo podle čeho. A tak dále. U operátoru ale čekám, že budou jednoduché, nebudou blokovat, nebudou vyhazovat výjimky, budou mít jednoznačný význam. V tom je operátor == v Javě opravdu trochu nešťastný, protože tam je potřeba vědět, že porovnává reference. Ale zrovna C++ to má stejně, nemýlím-li se.

2496

Server / Re:Email z cronu přes vzdálený SMTP server

« kdy: 15. 05. 2019, 15:31:55 »

Best practice je rozchodit na tom serveru hloupého SMTP klienta, který neumí nic jiného, než předávat e-mail chytrému poštovnímu serveru k rozesílání. Dříve se používal SSMTP, který už je nepodporovaný, ale v odkazované stránce máte odkazy na náhradu.

2497

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

« kdy: 15. 05. 2019, 15:26:42 »

Tenhle problém ale není omezený jenom na operátory. V jazyce, který umožňuje přetěžovat operátory, může prase napsat třeba operátor +, který nic nesčítá. V jazyce bez přetěžování napíše stejné prase funkci nebo metodu "add", která bude matoucí úplně stejně. Zákaz přetěžování operátorů tu nepomůže.

Operátory programátor vnímá jako součást jazyka a očekává od nich, že budou dělat to, co se od nich intuitivně čeká, a že se budou chovat slušně. I když C++ programátoři pravděpodobně čekají čertoviny i od operátorů. U metod naopak každý počítá s tím, že je to uživatelsky implementovaný kód a může dělat cokoli.

2498

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

« kdy: 15. 05. 2019, 15:24:12 »

Rozhodně je to nekonzistentní. že budou vestavěné typy a objekty podporovat jiné operace bych bral, že ale stejná operace funguje na obou jinak mi přijde jako past na nováčky.

To je jedna z těch variant, o které jsem psal – nepovolit operátor == pro reference. Ano, dávalo by to smysl, ovšem těžko to mohlo projít v době vzniku Javy. Tenkrát mnohým připadalo jako přílišné zjednodušení i to, že Java nepodporuje přetěžování operátorů. A kdybyste jim vzal i == (pro reference)…

Jinak nejde o vestavěné typy ale o primitivní typy. String je také vestavěný typ, ale je to objekt.

Intuitivní by mi přišlo mít dvě porovnání, jedno na identitu a jedno na hodnotu, a nechat je chovat se konzistentně pro všechno. Samotná syntaxe těch dvou porovnání už je vlastně detail.

Pro primitivní typy není rozdíl mezi identitou a hodnotou.

Ve skutečnosti je problémem Javy existence primitivních typů, všechno ostatní, o čem píšeme, jsou až důsledky. Jenže to víme dnes – v době vzniku Javy byly primitivní typy považované za nezbytné, aby aplikace vůbec mohla mít nějaký výkon. Taky se tenkrát nepočítalo s tím, že JVM bude provádět nějaké velké optimalizace – takže to, že by JVM interně objektový integer nahradila jednoduchým typem bylo z říše snů. Primitivní typy v Javě byly už tenkrát vnímány jako ústupek, ale byl to ústupek tomu, aby (tehdy) Java byla vůbec nějak použitelná.

2499

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

« kdy: 15. 05. 2019, 15:16:05 »

Lepší by pochopitelně bylo přetížení operátoru ==.

Bylo by to lepší jen při pohledu z rychlíku. Myslím, že programátor například neočekává, že mu při použití operátoru vypadne výjimka.

Některé jazyky umožňují přetěžovat operátory, což pak vede k tomu, že programátor nikdy neví, co se při použití operátoru stane. Java byla navržena jako jednoduchá, takže tohle záměrně neumožnila – a jediné přetížené (ve smyslu „implementované kódem v metodách“) operátory v Javě jsou ty pracující se Stringy. Přičemž samotný objekt String je v Javě final a má speciální podporu kompilátoru. Nebo-li autoři specifikace mohli zaručit, že se metody Stringu implementující operátory budou chovat slušně a operátory nebudou mít žádné nečekané efekty. Pokud byste operátor == přetížil jako volání equals() (a třeba i ošetřil null hodnoty), pořád bude použití toho operátoru volat uživatelský kód, který může vyhazovat výjimky, dělat dotaz do databáze, equals() ani nemusí být komutativní.

Přetížený operátor == by teprve byl pořádně kontraintuitivní.

2500

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

« kdy: 15. 05. 2019, 15:06:17 »

Porovnani dvou cisel mi neprijde nijak okrajove. A jestli chape nebo nechape podstatu, 1. neumim z niceho odvodit, 2. je to irelevantni - porad je ta vec kontraintuitivni.

Jenže on neporovnává dvě čísla, ale dvě reference.

Je to kontraintuitivni - jestlize o Jave nic nevim, muzu si rict tak leda "WTF" - vubec me nenapadne, proc by se to jednou melo chovat tak a jindy jinak.

Ano, můžeme navrhnout jazyk, který nebude mít žádné operátory, protože operátory jsou vždy v nějakém případě kontraintuitivní. Nejsem si úplně jistý, jestli by takový jazyk byl přijat s nadšením.

Uz to samotne vase "jenom pro větší čísla" ukazuje na neco, co vypada divne. "Vetsi cisla"? To je co? Vime to? Je to nekde v dokumentaci? Nebo se to chova "nahodne" (podle toho, jak velky je zrovna ten pool)?

Je to v dokumentaci. Ale je to implementační detail. Programátor klidně může zavolat new Integer(1) a vytvoří se nová instance. Pokud chci porovnávat hodnoty, musím použít metodu equals(). Je to úplně stejné, jako u Stringů. Prostě se programátor nemůže spoléhat na to, že někdy na stejnou hodnotu ukazují stejné reference.

Tak dalsi mozne reseni by bylo (pokud jsem spravne pochopil princip) nemit ten pool pro "mensi cisla"?

Nebylo. Pořád to jsou reference.

Jinak existuje urcite aspon pet, ne-li vic moznych jinych reseni, ale nektere z nich by vyzadovaly nejake featury, ktere aktualne Java asi nema.

Pět lepších řešení? Napište alespoň jedno.

2501

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

« kdy: 15. 05. 2019, 14:36:20 »

Já nejsem ten, který tady ze sebe dělá hlupáka. Jednou se to rovná, a podruhé ne. Právě ten, kdo chápe ten rozdíl, by nad tím měl kroutit hlavou...

Vážně byste si měl nastudovat rozdíl mezi hodnotou a referencí. Představte si, že máte na tabuli napsaná čísla, a pak tam přidáváte šipky, které na ta čísla ukazují. Na jedno číslo může ukazovat víc šipek. To, že máte v ruce dvě různé šipky, neznamená, že obě šipky nemohou ukazovat na stejné číslo. Pokud chcete porovnávat čísla, musíte se dívat, kam šipka ukazuje, ne na šipku samotnou.

2502

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

« kdy: 15. 05. 2019, 14:31:35 »

Vysvětlil by mi někdo, co se tam děje? Kdyby to bylo něco mimo rozsah 32b intu, tak bych to pochopil. Ale 1024 je furt zatraceně málo.

Integer v Javě je objekt, operátor == v Javě porovnává reference. Takže si v tom kódu vytvoří objekt(y), reference na ně jsou uložené do dvou proměnných – a pak zjišťuje, zda ty dvě reference ukazují na stejný objekt.

To, že ty reference někdy mohou ukazovat na stejný objekt je dané tím, že v kódu převádí primitivní typ int (zapsaný literálem 1024) na objektový Integer. Javovský kompilátor má vestavěný mechanismus (nazývaný boxing), který ten převod dělá automaticky. A nepoužívá se při tom konstruktor, ale statická metoda – a ta statická metoda vytváří nové objekty jenom pro větší čísla. U menších čísel má pool instancí a vrací ty instance – aby v paměti neexistovalo tisíc objektů, které v sobě ponesou hodnotu „1“.

Skoro stejně to funguje se Stringy, a v případě Stringů se to učí asi tak ve druhé lekci, že se neporovnávají pomocí == ale pomocí equals(), protože == porovnává reference a mohou existovat dva různé objekty, které obsahují ten samý řetězec.

Na upozornění na kontrainutitivnost nějakého prvku jazyka není nic hloupého.

Hloupé je to, že uvádí jeden okrajový příklad, a zdá se, že vůbec nechápe podstatu. To, že operátor == v Javě porovnává hodnoty primitivních typů a reference u objektů mi nijak neintuitivní nepřipadá. Napadají mne jen dvě srovnatelně dobrá řešení a žádné lepší. Jedno řešení by bylo pro objekty == udělat jako alias pro equals() a ošetřit null hodnoty. Druhé řešení by bylo == pro objekty úplně zakázat. V obou případech by na porovnání referencí musel existovat nějaká systémová metoda.

2503

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

« kdy: 15. 05. 2019, 12:26:52 »

No jenže pokud ale mají oba pouze 50 Kč, pak opravdu jo:

V jazyce, který umožňuje používat hodnoty i reference, musí programátor znát rozdíl mezi hodnotou a referencí. To je celé, nic dalšího k tomu není potřeba dodávat, kdo ten rozdíl chápe, chápe i hloupost vašich příspěvků.

2504

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

« kdy: 15. 05. 2019, 10:36:58 »

"Idealni" znamena "idealni pro programatory"? To je podle me malo. Videl jsem uz spoustu java projektu, ale nevzpomenu si ani na jeden kde by jazyk byl vybran programatory.
Rozsirenost javy je podle me zpusobena tim, ze je zdanlive jednoducha a proto lze na trhu najit dostupne vyvojare a dostatek klientu, kteri si nechaji nabulikovat, ze je to dobry napad.

PS: Se sterkou na Johnyho souhlasim, protoze to byl fakt debilni argument.

Souhlasím, že o výběru programovacího jazyka nerozhodují jen programátoři. Ale vzhledem k tomu, na co jsem reagoval, mi připadalo zbytečné zabíhat do detailů…

2505

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

« kdy: 15. 05. 2019, 07:09:15 »

Java také nebude ten ideální jazyk... 

Kód: (Java) [Vybrat]

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

Vzhledem k tomu, že programovací jazyk je nástroj pro programátory, asi by ideální programovací jazyk neměli vybírat neprogramátoři.