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] 2 3 ... 46
1
Vývoj / Re:If bez curly brackets?
« kdy: 23. 06. 2025, 10:39:31 »
tie zatvorky pri if, to sa este da. Ale ak ma niekto vzorec a neda tam zatvorky, tak to je uz na nervy. Strasne zle sa to cita a ked mas nejaky algoritmus prepisat, tak ta moze aj porazit.

Není na to nějaký formátovač, který je přidá?

2
Vývoj / Re:If bez curly brackets?
« kdy: 22. 06. 2025, 10:11:48 »
Pripravte sa na budúcnosť!  https://github.com/stereobooster/wisp
Last commit: 5 years ago :-)
Ale souhlas, rozhodně se mi to čte líp (a dokonce jsem to i znal z dřívějška). Ale i tak je to furt Lisp a čte si mi to ve srovnání s "normálním" jazykem blbě...

Slepá ulička zůstane slepou, i když ji nově vydláždíme.

3
Vývoj / Re:Je jazyk C skutočne ťažký?
« kdy: 16. 06. 2025, 07:56:18 »
Mé tvrzení se týká jen toho B-stromu, konkrétně jen node.rs (nechci se pouštět do obecných tvrzení). Implementace Rustu má kvůli borrow checkeru spoustu zbytečných funkcí, které v C nepotřebuji - např. tyhle

Kód: [Vybrat]
impl<K, V, Type> NodeRef<marker::Owned, K, V, Type> {
    /// Mutably borrows the owned root node. Unlike `reborrow_mut`, this is safe
    /// because the return value cannot be used to destroy the root, and there
    /// cannot be other references to the tree.
    pub(super) fn borrow_mut(&mut self) -> NodeRef<marker::Mut<'_>, K, V, Type> {
        NodeRef { height: self.height, node: self.node, _marker: PhantomData }
    }

    /// Slightly mutably borrows the owned root node.
    pub(super) fn borrow_valmut(&mut self) -> NodeRef<marker::ValMut<'_>, K, V, Type> {
        NodeRef { height: self.height, node: self.node, _marker: PhantomData }
    }

    /// Irreversibly transitions to a reference that permits traversal and offers
    /// destructive methods and little else.
    pub(super) fn into_dying(self) -> NodeRef<marker::Dying, K, V, Type> {
        NodeRef { height: self.height, node: self.node, _marker: PhantomData }
    }
}

To jsou funkce, které se samotným B-stromem nijak nesouvisí, takže je v jiných jazycích nepotřebuji.

Troufám si tvrdit, že něco podobného běžný programátor v Rustu neimplementuje. Je jistě možné se točit na jedné okrajové situaci, ale pak se dostáváme k banálnímu přístupu obhájců C - můžeme si to všechno udělat jednoduše a tady to zrovna vypadá, že se to vyplatí.

4
Vývoj / Re:Je jazyk C skutočne ťažký?
« kdy: 15. 06. 2025, 13:17:03 »
Na rozdíl třeba od C, které má jenom režim "pras jak umíš".
Při práci v C taky fungujou příčetnějí režimy, které krotí ty nejprasáčtějí praktiky. Jen nejsou nijak vynucené jazykem, takže to hlídají lintery, code review a podobně.

Code review je ultimátní řešení, jenže má dvě nevýhody:

1. Není podpořené jazykem
2. Je opět závislé na lidském faktoru

Všechny ty bezpečnostní problémy v OpenSSL a jinde existovaly i přes možnost review člověkem a existenci linterů.

5
Vývoj / Re:Je jazyk C skutočne ťažký?
« kdy: 14. 06. 2025, 13:04:09 »
Např. mnohými tolik opěvovaný Rust. Na mě působí dojmem, že přechodníky nemá, protože v nich spousta lidí dělá chyby, tak mě nutí místo nich použít nějaký krkolomný konstrukt.

Naopak. Rust má spoustu možností, jak cokoli naprasit jakkoli - počínaje inline asm, přes "normální" unsafe Rust až po FFI.  Kromě toho nabízí spoustu abstrakcí a pohodlných způsobů, jak se v normálním kódu vyvarovat různých problémů s pomocí jazyka. Na rozdíl třeba od C, které má jenom režim "pras jak umíš".

6
Vývoj / Re:Je jazyk C skutočne ťažký?
« kdy: 11. 06. 2025, 08:53:32 »
...Rust Vás jen donutí je explicitně pojmenovat a vyřešit.
Jo tak proto to pri kompilaci sebe sama hlasi kazdej jeden radek kodu ze je vadnej ... teda nez ta kompilace zbuchne, protoze to samosebe zkopilovat neumi.

Zjevne kvalitka ....

Kam chceš tímto příspěvkem posunout debatu?

7
Vývoj / Re:Je jazyk C skutočne ťažký?
« kdy: 07. 06. 2025, 07:57:11 »
V CVE databázích je těch příkladů je spousta. Pokud to ani projekty jako Linux Kernel nebo GNU Coreutils nedokážou nedělat chyby při práci s pamětí, tak tím hůř se tomu ubrání někdo bez spousty praxe a citu.

Mnohdy používají jen zbytečně komplikovaný přístup, kdy alokace spravují jednotlivě místo toho, aby to dělali hromadně.

Kdyby ten kód napsali jednodušeji, tak by měli méně problémů.

Existuje na to nějaký dokument, který by popisoval "best practice" v takových případech? Ideálně s poukázáním na konkrétní historické incidenty?

8
Vývoj / Re:Budoucnost Rust v embedded světě
« kdy: 06. 06. 2025, 10:32:21 »
Přesně tak. Někdo, kdo dokáže napsat dobrý kód v C, nebo C++ je bez pochyby velmi dobrý programátor.

U Rustu je problém v tom, že v něm dokáže napsat dobrý kód každý, kdo ho v Rustu dokáže napsat.

Trošku bych to zmírnil - naprasit špatně udržovatelný kód se dá prakticky všude. Jsou ale jazyky, které hodně ztěžují vytvoření některých chyb v návrhu. C je těsto nebo hlína, ze které(ho) se dá uplácat prakticky cokoli a je mu to jedno. Rust je partner, který klade nepříjemné otázky a brání se (ale zase na druhou stranu v mnoha věcech pomáhá - od vrstev abstrakce až po build system).

9
Vývoj / Re:Je jazyk C skutočne ťažký?
« kdy: 03. 06. 2025, 14:56:24 »
Podle me tvoje "normalni jazyky" toho jsou schopny jenom proto, ze se omezujou na architektury pouzivajici dvojkovy doplnek - cili nejsou prenositelne vsude. A nebo i v nich to musi byt implementation defined, akorat se o tom nemluvi...

Sice dvojkovy doplnek je univerzalni v tom smyslu ze kazdy procesor ktery umi unsigned aritmetiku umi i signed aritmetiku v dvojkovem doplnku - to je prave jeho vyhoda, ze pro procesor se nic nemeni oproti normalu. Ale je to SW reseni a nemusi byt treba tak optimalni jako HW reseni na dane platforme a proto C umoznuje oboji - umoznuje implementovat takovy, i onaky prekladac.

Upozorňuju na to, že v "normálních" jazycích (pokud jimi myslíme Rust a spol.) existuje často nějaký způsob, jak tyto speciální věci udělat, byť to nemusí nutně přes operátor:

https://doc.rust-lang.org/stable/std/primitive.isize.html

10
Vývoj / Re:Je jazyk C skutočne ťažký?
« kdy: 03. 06. 2025, 09:11:53 »
Ani ne tak těžký, jako čím dál víc zbytečný.

Zatial neviem o jazyku, ktory by ho nahradil.

Vždy a všude? Zatím možná není. Ale že čím dál víc projektů, které nahrazují původní věci psané v C. A je tu Zig a někdo nedávno vzpomínal nějaké C3 - to by mohly být přímé náhrady, když už někomu nesedí třeba Rust ani C++. Že C bude čím dál víc legacy, považuju za nevyhnutelné.

11
Vývoj / Re:Je jazyk C skutočne ťažký?
« kdy: 02. 06. 2025, 18:20:56 »
Ani ne tak těžký, jako čím dál víc zbytečný.

12
/dev/null / Cookie lišty v EU
« kdy: 30. 05. 2025, 12:24:19 »
Je třeba vypnout doplňky proti cookie lištám případně blokátory reklam. Pak stačí dát souhlas s cookies a začne to fungovat. Taky jsem nad tím dnes dumal...

Nelze než znovu poděkovat EU, která nám ve své neskonalé moudrosti přináší tyto dary!

13
Server / Re:Zvažuji přechod z Linuxu na FreeBSD
« kdy: 15. 04. 2025, 15:49:34 »
A na druhou stranu nechci jeden router, který by se mohl polámat a celou farmu odstavit. Také být úzkým hrdlem přístupu.

Hm, takže ty servery se připojují bez routeru?

14
Vývoj / Re:Framework Bottle pro Python
« kdy: 14. 04. 2025, 20:23:00 »
Používat is na porovnávání čísel je dost hloupý nápad. Viděl jsem to v kódu jenom jenom jednou a code review to zatrhlo.

15
O serveru Root.cz / Příspěvky podléhající schválení
« kdy: 01. 02. 2025, 09:03:06 »
Milá redakce, mám takový návrh - nešlo by do redakčního systém přidat možnost smazat vlastní příspěvek, který čeká na schválení? Nebo pokud možno hned avizovat, než ho začnu psát, že to schválení bude třeba? Nemám zájem psát něco, co zveřejníte nebo ne a ani se neví kdy. Děkuji.

Stran: [1] 2 3 ... 46