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 ... 14 15 [16] 17 18 ... 44
226
Já měl Pascal jen dávno v prváku, u zkoušky jsem ho viděl naposled. Ale minimálně výrazně ovlivnil jiné jazyky a napravil některé divnosti Algolu.

Tak jsem si pročetl srovnání Algolu a Pascalu od Tanenbauma (je to online v pdf) a musím říct, že v něčem ten Algol měl dost výrazně navrch. Bezpečnější práce s recordy, definice proměnných uvnitř bloku, výrazová orientace jazyka, náhodný přístup k souborům, dokonce printf... Původní Pascal byl dost omezující, byť teda ten kompilátor (jednoprůchodový) byl celkem jednoduchý a pekelně rychlý. Ale jasně, něco měl Pascal lepší.

227
To Ruby mě tedy zaráží - to je někde ve Švýcarsku, ne?
BTW proč zrovna Švýcarsko? Tamní IT trh neznám, ale v čem by se měli lišit?

Z nějakého důvodu jsem měl zafixováno, že tam působíš...

228
Co je “zjednodušené OOP”?
Daleko od Smalltalku a blízko k Pascalu.
Tak Pascal byl na svou dobu celkem fajn. Stejně jako Algol. Kdyby měl rozhraní/traity, tak je slušně použitelný i dnes. Smalltalk nemá typovou kontrolu, co je cesta do pekel (na rozdíl od ObjC, které typy přísně kontroluje — včetně typových parametrů a jejich variance, ovšem můžu explicitně říct, že typovou kontrolu nechci + nemá tracing GC). Ale jo, to už to historie, teď v inzerátech na backend (jiné nesleduju) vládnou Go, čím dál více Rust a z nějakého divného důvodu Ruby.

U mě to (Turbo) Pascal prohrál v momentě, kdy jsem zkusil Turbo C s jeho bohatou knihovnou. A taky jsem si prošel Učebnici jazyka C od Herouta a srovnal s akademicky zaměřenou učebnicí Pascalu, kterou jsem měl. To Ruby mě tedy zaráží - to je někde ve Švýcarsku, ne?

229
Co je “zjednodušené OOP”?

Používá se třída spíše v roli namespace, než aby architektura byla nějak propracovaná a "čistá". Daleko od Smalltalku a blízko k Pascalu. Což o to, já jsem taky příznivcem post-OO programování.

230
Tohle má jednoduché řešení — brát jen seniory. U nás se to náramně osvědčilo.

Jakkoliv se s tím dá souhlasit a pro spoustu situací je to jediné ekonomicky zvládnutelné řešení, pokud by se tak chovali plošně všichni, seniory by nebylo kde brát, aby se jím člověk stal, musí si projít juniorní i mediorní fází. Což ale nejde, když junior nedostane šanci...

Zásadní problém není, že junioři neumějí. Problém je, když jsou hloupí a líní, případně ke všemu i namyšlení a asociální. Nábor seniorů je v tomto snazší, ti mají historii, ze které se dá leccos odvodit.

231
Rust - když v něm nenapíšeš dostatek kódu a nevracíš se k tomu, budeš s ním (zas) bojovat. […] Aby Tě začal "odměňovat", musíš mu dost věnovat a možná na to musíš mít i specifický mozek, abys netrpěl jako pes.
Hehe, asi mám “specifický mozek”, páč mi Rust přijde snadný a většina jeho “netypických” vlastností má svou vnitřní logiku. Ale na druhou stranu mě nijak zvlášť “neodměňuje”, v C++ bych to napsal stejně dobře (a ne o moc nečitelněji) :)

V C++ určitě můžeš napsat stejně dobrý program jako v Rustu, ale v Rustu máš slušnou jistotu, že i všichni ostatní píšou "rozumně", jelikož si to kompilátor hlídá a návrháři jazyka se moc nerozšoupli. K tomu bezvadný tooling včetně řízení závislostí - tohle myslím C++ pořád nemá. K tomu absence obskurního vynálezu zvaného preprocesor. Já se vracet nechci, Ty si to klidně užij.

Že to Tvůj mozek ale pobírá, je vzhledem k Tvé znalosti FP a podobných legrací, zcela pochopitelné. Tam většina programátorů není - mnozí končí zhruba u cyklů a "vylepšují" to zjednodušeným OOP.  :D

232
Nejlepší je umět (aspoň trochu) C++, Go i Rust, širší kontext se vždy hodí.

To nepopírám. Když ale pominu Go, které má za cíl vzít začátečníka, rychle ho zaškolit a nechat ho chrlit kód, který tak nějak funguje, tak:

1. C++ - ani nevím, co znamená trochu umět C++. Je to C s pár vylepšeními? Je to C se smart pointery? Je to OOP jazyk se třemi různými druhy definice typu objektu? S virtuálními a nevirtuálními metodami (členskými funkcemi)? Je to šablonové metaprogramování? Dá se v takovém jazyku psát idiomaticky, co to znamená pro začátečníka? Fakt nevím. V době, kdy frčely raw pointery a člověk si vystačil třeba s MFC, to bylo ještě vcelku snadné, byť už docela drsné.

2. Rust - když v něm nenapíšeš dostatek kódu a nevracíš se k tomu, budeš s ním (zas) bojovat. Spousta věcí, které se tam používají, jsou neintuitivní pro programátory ze "starých imperativních jazyků". Spoustu "zkratek" Ti borrow checker vůbec nedovolí, věci jako spojové seznamy (které se moc v praxi nepotřebují, ale jiné "self referencing structures" docela jo) jsou zásadní problém. Aby Tě začal "odměňovat", musíš mu dost věnovat a možná na to musíš mít i specifický mozek, abys netrpěl jako pes.

Pokud si člověk tohle uvědomí a do Rustu, C++ apod. zlehounka ponoří dlaň a pokusí se trochu nabrat, super, nic proti. Pokud se do toho ponoří opravdu seriózně, super. Ale zadarmo to nebude. A pro rychlý profesní start to není.

233
Python se uč. Pokud pokukuješ po klientu, tak JS a TypeScript. Doufám, že si uvědomuješ, co znamená umět C++, jelikož i jeho hlavní autor řekl, že ho neumí na 100% nebo něco tak. To už fakt radši Go.

234
Odkladiště / Re:Je mozne vytvorit pravu kryptomenu?
« kdy: 23. 12. 2021, 15:32:46 »
Prevadet digitalni penize v offline rezimu mezi penezenkama nepujde, prinejmensim by to zaviselo na nejakem HSM (at uz per user, nebo nejake detasovane pracoviste vasi centraly), a to uz pak neni skutecne krypto.

Btw to co jste popsal, je spis burza, nez mena :-)

Ako som spominal, penazenku by vydala iba "centralna banka" a kazda penazenka by bola doveryhodna. A kazda penazenka iba sama vie ake "peniaze" v sebe ma. Nikto iny. Tzn. cely system sa predpoklada ze je bezpecny a doveryhodny.

Plus, skor tu riesim ako by sa to dalo, nie ako by to neslo. To vie kazdy :)

Aha, já už tuším, co asi hledáš, něco jako https://en.wikipedia.org/wiki/Trusted_Computing - uzavřený systém, který by si uživatel nemohl modifikovat a pak by se dalo mluvit o "nezávislosti" a "ověřenosti" peněženky. To je ale hrozná dystopie.

235
Odkladiště / Re:Je mozne vytvorit pravu kryptomenu?
« kdy: 23. 12. 2021, 10:27:27 »
V zásadě by to myslím možné bylo. Musel bys mít "centrální autoritu", která by autorizovala (vydávala) nové "peníze" a transakční síť, která by řešila jejich pohyb. Základem "nezávislosti peněženek" by musela být nějaká síť s "fungible" coiny - něco jako Monero nebo Zcash. "Malý problém" je "pouze" to, že současný finanční systém směřuje naopak k tomu, že banky, potažmo vlády, budou vědět úplně o každém pohybu peněz a ideálně i rozhodovat o tom, za co je smíš utratit nebo je zablokovat či zabavit. Ale jo, rády k tomu využijou kryptoměny, pokud budou tohle splňovat.

236
Vývoj / Re:Rust - serde/bincode serializacia/deserializacia dat
« kdy: 21. 12. 2021, 12:34:06 »
OP: Došel jsi prosímtě k něčemu? Zafungoval Ti ten "untagged"?

237
Vývoj / Re:Rust - serde/bincode serializacia/deserializacia dat
« kdy: 18. 12. 2021, 20:34:41 »
Hele a nedá se prostě ten enum přes serde serializovat s pomocí "untagged"? Něco jako

Kód: [Vybrat]
use bincode;
use serde::{Serialize, Deserialize};

type Version = u8;
type BatteryHealth = u8;

#[derive(Debug, Serialize)]
#[serde(untagged)]
pub enum MessageBodyType {
    Version(Version),
    BatteryHealth(BatteryHealth),
}

fn main() {
    let body = MessageBodyType::BatteryHealth(1);
    let encoded: Vec<u8> = bincode::serialize(&body).unwrap();
    println!("Result {:?}", encoded);
}


238
Vývoj / Re:Rust - serde/bincode serializacia/deserializacia dat
« kdy: 18. 12. 2021, 10:11:45 »
Dekuji za potvrzeni, ze rust neni neco co by melo hardcore/lowlevel C programatory zajimat :)

Tolik s**ni s tim, a jeste si to dela co chce, a ne co chci ja mi za to fakt nestoji.

Ukaž, jak bys to udělal v C a že v Rustu to nejde. Rust má i normální "hloupý" union (untagged). OP použil tagged union a vadí mu, že vysokoúrovňový serializační mechanismus ho zachová v pořádku se vším všudy. Ale jinak jasně, pokud Ti to za to nestojí, nezabývej se tím.

239
Hardware / Re:Tichá desktop zostava (do 30-35dB)
« kdy: 03. 12. 2021, 12:27:08 »
ani mají i air se stejným HW, pokud to chceš přenášet. Ano, desktop pod stolem, ale ve firmách a domácnostech je ale běžný zavřený notebook na stole s externím monitorem, klávesnicí a myší, přesně tak to i vypadá v kancelářích kam se jen podívám. Mac mini suchým zipem přilepíš ze zadu na monitor a máš prázdný pracovní stůl.

pasivně chlazená M1 od Applu je zatím dost unikát, záleží na jaký use case, ale dá ti dost zabrat postavit něco obdobného za podobnou cenu. V rychlosti se asi vyrovnáš, jen hluk a velikost bude nesrovnatelná. Zase tam máš vazbu na MacOS, teda ikdyž to vypadá, že Arch už tam pomalu funguje se vším potřebným.

Každopádně to je asi jedno, nechtěl jsem rozpoutat náboženskou diskuzi, přišlo mi to jako vhodná alternativa, tak jsem jí zmínil mezi ostatními. Kvas chce něco s Ubuntu, to tady nepůjde.

U nás v práci zase mají skoro všichni desktop, aspoň tedy vývojáři. Já doma taky a hodlám to tak nechat, dokud to půjde. Taky jsem neměl zájem se hádat - ten M1 je zajímavé vodítko, tam někam jsem se chtěl dostat.

240
Hardware / Re:Tichá desktop zostava (do 30-35dB)
« kdy: 03. 12. 2021, 11:25:59 »
Mac mini má ty parametry poměrně fixní, 8 GB ram, 512 GB disk. Dříve měli klasické firemní notebooky v cenách 40 - 60 tis, např. Dell Precision 5540 (intel i7-9850H, 16GB RAM, 512GB SSD) nebo teď aktuální, které jsou vedle Mac mini, Precision 7550 (intel i7-10850H, 16GB RAM, 512GB SSD). Ten rozdíl v rychlosti je značný. Notebooky stejně stojí na stole a nikdo s nimi nehejbe, takže malý mac mini je vlastně evoluce a způsob jak uvolnit místo na stole.

Nejsem nějaký velký fanoušek Macu, pracuji primárně s linuxem a BSD, jen také nejsem tvrdým odpůrcem a vidím, že to kolegům funguje dobře a jsou s tím spokojení.

Dík za odpověď, každopádně alternativou Macu Mini, pokud ho nenosíš v tašce tam a zpět, je normální desktop pod stolem, ne? Docela bych se divil, kdyby za ty prachy nešlo postavit něco minimálně stejně rychlého, ale chtělo by to změřit v praxi.

Stran: 1 ... 14 15 [16] 17 18 ... 44