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 - BoneFlute

Stran: [1] 2 3 ... 133
1
Věřte, pud sebezáchovy mám, proto to řeším. Ale jsem v práci, tu si nevybírám, nepřihlašuji se k ní, prostě je mi přidělena. A když prostě obchodník podepsal Word, já protestoval, vedení rozhodlo že mám držet pusu a Word, tak prostě Word.
A co bude vedení dělat, když nedodržíte termín, nebo když budete vedení informovat, že to nejde?

2
Vývoj / Re:Michání jazyků v práci
« kdy: 26. 06. 2023, 12:45:59 »
Jak psali předřečníci.

Má zkušenost: míchám/přepínám C#, PHP, JS, Lua, Rust, Bash, etc. Celkem bez problémů. Horší je přepínat projekty. Pár desítek minut mi trvá, než najedu. Takže jak popisuješ dopoledne odpoledne by možná šlo, ač je to hraniční. Stejně budeš strašně vyšťavenej, protože sis toho nakrkal hodně.

3
Vývoj / Re:Využíváte umělé inteligence běžně?
« kdy: 21. 06. 2023, 13:30:19 »
I za předpokladu, že by ChatGPT nezvládal vůbec nic jiného než dohledávat řešení na diskusních fórech (zřejmě je aspoň zčásti využívá), čekal bych spíše omezení duplicitních dotazů. Což může být fajn, lidé budou mít více času na řešení nových dotazů.
Cítím benefity hlavně ve vyfiltrování trollů. V tom, že GPT jde rovnou k věci, snaží se konkrétně a smysluplně odpovědět. A v tom, že je to instantní. Dostanu odpověď v řádu minut, ne dní.


4
Vývoj / Re:Využíváte umělé inteligence běžně?
« kdy: 21. 06. 2023, 13:26:52 »
Když bych to zkusil demonstrovat, tak od doby, co jsem začal používt GPT, tak jsem přestal chodit s dotazy na fóra.
Jinak receno, vyuzivas toho, ze stejny dotaz nekdo nekde nekdy polozil, a nekdo mu odpovedel. Za 10 let ti chatgpt uz neodpovi, protoze kdyz to takhle zacnou delat vsichni, nebude mit kde ty odpovedi brat. A sam je vymyslet neumi.
Což jednak není pravda a druhak, i kdyby byla, tak je mi to jedno. GPT je nástroj. A mám v plánu z toho nástroje týt.

5
Vývoj / Re:Využíváte umělé inteligence běžně?
« kdy: 20. 06. 2023, 23:24:20 »
Ano. Intenzivně. V různých oblastech. Pokud budu mluvit v kontextu programování tak využívám ve věcech, kde mám více teoretické vzdělání, a potřebuji zjistit, jak přesně to napsat. Nebo naopak vysvětlování různých věcí, teoretických konceptů, a podobně. Prohledávání dokumentace. Rutinní konstrukce, které ještě nemám v hlavě. Transformace. A nacházím další. Hodně mi to zefektivnilo práci. Odhadem o řád (u věcí, na které GPT lze použít).

Když bych to zkusil demonstrovat, tak od doby, co jsem začal používt GPT, tak jsem přestal chodit s dotazy na fóra.

6
Software / Re:Textové editory vhodné pro programátory
« kdy: 16. 06. 2023, 18:06:33 »
Omg proč mcedit, nemáte už lepší rovnou vim?
protoze na to clovek nepotrebuje dva doktoraty, aby ten program dokazal aspon ukoncit?
Na :q člověk potřebuje dva doktoráty, to pak potřebuje ještě třetí na ovládání myši.

Nelžete, :q nefunguje vždycky. Někdy vám to místo ukončení napíše :q do textu. Aby se v tom prase vyznalo... Na to aby v tom člověk napsal jeden hash potřebujete hledat manuál na netu jen kvůli tomu, aby to vůbec něco začalo psát a pak taky, aby se to dalo uložit a nakonec, aby se z toho dalo vůbec vylýzt.   Tenhle archaickej bazmek by měli vymazat z povrchu zemského, páč s tim může pracovat leda masochista.

Tak to se mi ještě nikdy nestalo, že by mi nešel :q ve vimu. Používám ho nicméně jen jako nouzovku, na remote serverech, nebo s ním taky píšu commity v gitu.

Jsou dva důvody proč :q nejde:
1/ jsi v editačním módu. řešení  -> ESC
2/ udělal si změnu, a chce to po tobě potvrzení, zda to máš uložit. řešení -> zapsat ":w", nebo nezapsat ":q!", nebo zapsat a ukončit "ZZ" (btw: Píše to tam. Jasně červeně. Stačí číst.)

Nepíšu to tobě (předpokládám, že ty vim znáš), ale píšu to @Karmelos.
Souhlasím, že je to velice těžké, a není každému dáno, aby pochopil že vim má editační a příkazový mód, a ne každý se naučí čtyři příkazy.

Já teda vim používám na serveru, protože je všude a nedělá chyby a dá se v něm označovat do bloku myší (na rozdíl od mcedit). Dokonce si v mc nastavuji jako editor právě vim namísto mcedit.

Jinak vim nepoužívám.

7
Software / Re:Textové editory vhodné pro programátory
« kdy: 14. 06. 2023, 20:08:38 »
geany, v terminálu vim

8
Vývoj / Re:PHP: knihovna pro prezentační stránku
« kdy: 08. 05. 2023, 18:10:00 »
V tom případě bys to měl dělat čistým PHP a netahat tam x mega PHP sraček, to je pak bloatware úplně stejně. Líbí se mi, jak je moderní vývoj (obecně) založený na tom, že potřebuju formulář, co má odeslat data na mail a tudíž k tomu potřebuju desítky knihoven :)

Ved o to sa snazim, preto hladam nejaky mikro-framework - kvoli tym dvom REST endpointom a tiez by som chcel MVC aby som rozumne renderoval obsah.

A tym blotware som ani nemyslel velkost kniznic, ale skor tym, co musi clovek napisat v Reakte v skutocnej aplikcii (nie helo world) aby to vobec fungovalo. Pricom ostatne SPA frameworky su na tom v tomto o dost lepsie. A samozrejme nepotrebuju samostatnu kniznicu na pracu s formularom.

Nette je micro-framework.

9
Vývoj / Re:PHP: knihovna pro prezentační stránku
« kdy: 03. 05. 2023, 12:43:02 »
https://github.com/tacoberu/nette-slidee

Používá Nette a Latte.

10
Studium a uplatnění / Re:Plat Java vývojáře na živnost
« kdy: 22. 04. 2023, 23:04:23 »
A ano, zkouma to "na dalku" = dokola se pta na veci, ktere mu uz byly 10x zodpovezeny, nepta se na veci, na ktere by se ptat mel, a strasne se divi vecem, ktere jsou naprostou samozrejmosti. Ale neni se co divit, nikdo mu nic nerek, nikdy to nevidel.
A když by byl on-site, tak by to bylo lepší? Jakto?

11
Vývoj / Re:Převod List<a> na Vect<a,n>
« kdy: 19. 02. 2023, 21:55:56 »
No, a moje pointa mého původní příspěvku je, že nevím, proč bych to měl drátovat do typů. Prostě si vytvořím kolekci [Foo] a nechám kompilátor odvodit podle užití, jak moc v kódu používám přístup k počtu prvků (-> přidá count do interní struktury pro Foo), jak často přidávám/odebírám prvky uvnitř seznamu (-> zvolí zda použít vektor, nebo spojový seznam). To mě, jako uživatele typů nezajímá, a kompilátor to dokáže rozhodnout lépe.

A jak to pozná?
Jak to píšu. Pozná to na základě znalosti kódu. Koukne a vidí, že ta kolekce se používá tady a tady a tady a tady, způsobem tak a tak a tak. Tudíž nejoptimálnější by bylo mít tu strukturu takto.

A jak z toho (obecně) pozná, jaká je frekvence kterých operací? To přece musí záviset mimo jiné na vstupních datech.

To píšu výše, ne?

12
Vývoj / Re:Převod List<a> na Vect<a,n>
« kdy: 19. 02. 2023, 21:28:38 »
No, a moje pointa mého původní příspěvku je, že nevím, proč bych to měl drátovat do typů. Prostě si vytvořím kolekci [Foo] a nechám kompilátor odvodit podle užití, jak moc v kódu používám přístup k počtu prvků (-> přidá count do interní struktury pro Foo), jak často přidávám/odebírám prvky uvnitř seznamu (-> zvolí zda použít vektor, nebo spojový seznam). To mě, jako uživatele typů nezajímá, a kompilátor to dokáže rozhodnout lépe.

A jak to pozná?
Jak to píšu. Pozná to na základě znalosti kódu. Koukne a vidí, že ta kolekce se používá tady a tady a tady a tady, způsobem tak a tak a tak. Tudíž nejoptimálnější by bylo mít tu strukturu takto.

Pokud to nedělá runtimovou analýzu v konkrétním běhu nebo nějakou dlouhodobou statistiku, tak bych na to nespoléhal...
JIT je dobrý na něco jiného. Na zohlednění reálných dat a reálného chování.

Ani v jednom případě bych k tomu programátora nepouštěl.

13
Vývoj / Re:Převod List<a> na Vect<a,n>
« kdy: 19. 02. 2023, 16:03:59 »
Spíš je tam nadbytečný ten spojový seznam, většinou chceš jenom vektor. A když ho spojíš s vektorem, výhody listu zabiješ úplně.
To se takhle nedá říct. Pokud tu kolekci používáš tak, že tam často přidáváš a odebíráš prvky na různá místa, bude spojový seznam lepší volba.

Ano, pro tento velmi specifický případ se spojový seznam celkem hodí (za předpokladu, že moc nepotřebuješ náhodný přístup), sice jsem to v praxi neviděl, ale nezpochybňuju to. Ale když tam přidáš vektor - a to je základ mého příspěvku - už můžeš spojový seznam zahodit, protože režii přidávání a odebírání na vektoru se nevyhneš.

No, a moje pointa mého původní příspěvku je, že nevím, proč bych to měl drátovat do typů. Prostě si vytvořím kolekci [Foo] a nechám kompilátor odvodit podle užití, jak moc v kódu používám přístup k počtu prvků (-> přidá count do interní struktury pro Foo), jak často přidávám/odebírám prvky uvnitř seznamu (-> zvolí zda použít vektor, nebo spojový seznam). To mě, jako uživatele typů nezajímá, a kompilátor to dokáže rozhodnout lépe.

14
Vývoj / Re:Převod List<a> na Vect<a,n>
« kdy: 19. 02. 2023, 13:12:01 »
Jsem myslel, že dneska se to dělá tak, že si vytvořím třídu ve který bude ten list i jeho délka jako vlastnost. V okamžiku převodu na vektor budu délku pak vědět. No vlastně v tý třídě může být rovnou i ten vektor...
Nebo ne?

deka listu ve tride listu muze byt, ale michat tam i vektor je nadbytecne.

Spíš je tam nadbytečný ten spojový seznam, většinou chceš jenom vektor. A když ho spojíš s vektorem, výhody listu zabiješ úplně.
To se takhle nedá říct. Pokud tu kolekci používáš tak, že tam často přidáváš a odebíráš prvky na různá místa, bude spojový seznam lepší volba.

15
Vývoj / Re:Převod List<a> na Vect<a,n>
« kdy: 17. 02. 2023, 19:03:46 »
kdyz mas delku kolekce primo v typu/objektu tak pri kazdem add/delete automaticky upravujes hodnotu delky. jinak si musis udelat (nekonecnou) smycku a delku spocitat.
Takže cheš říct, že když mám:
Kód: [Vybrat]
parseList : String -> [Int]
tak ten kompilátor si nemůže vytvořit paměťovou buňku ve které bude jednak ta kolekce čísel ale i informace o počtu?

proto se mi libi Go a dalsi jazyky, ktere delku vektoru schovavaji v typu a je to pro bezpecnost; proto se mi libi C a assembler kde to nikdo nehlida a inteligent musi hlidat sam.

Asi nerozumím. Kde v tom mám hledat odpověď na mou námitku?

Já chci, aby mi kompilátor hlídal. Čím víc, tím lépe. Tady se ale bavíme o tom, proč dávat do typu něco co nepotřebuji a nejedná se o nic, co by měl kompilátor hlídat.

Stran: [1] 2 3 ... 133