1
Software / Re:jak zachránit historii z existující bash (gdb)
« kdy: 06. 11. 2025, 06:54:11 »
Je to off topic, ale lidi, používejte konečně fish, kde to jde...
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.
2
Windows a jiné systémy / Re:Vlastnosti macOS pro linuxáka
« kdy: 04. 11. 2025, 12:50:02 »
Byl jsem tam, už tam nechci. MacOS X je divný a ten jejich HW (touchpad a myš) mě taky nějak zásadně nebaví. Pokud chceš vysloveně dělat věci pro Mac, zvážil bych možná Mac Mini jako kompromis. Ale je to, jako všechno, individuální.
3
Vývoj / Re:Prečo nie je Lisp populárnejší?
« kdy: 03. 11. 2025, 21:10:41 »Samozrejme, se sekvencnim algoritmem to nepomuze ale to nezavisle poradi vyhodnocovani zanorenych vyrazu je primo navod. Podobne od pocatku jsou tam konstrukce jako aplikuj na vsechny prvky seznamu nejakou operaci misto casto zavislem prochazeni pres cyklus.
Věci typu map/reduce jsou dnes úplně běžné ve spoustě jazyků. Stejně jako jiné techniky z FP (líné vyhodnocování atd.). Problém paralelizace vidím právě v tom, že to dnes musí být programátor, který tuší, jak se má mezi jádra práce rozdělit a kdy je paralelizace - třeba díky zvýšené režii - už moc.
Rekl bych ze je to jazyk vhodny pro zapis grafovych struktur a efektivne s nimi pracovat, coz je vhodne pro matematiku a odvozene vedy.
Tohle zpochybnit neumím, ale zajímal by mě příklad.
Rekl bych ze je to jazyk vhodny pro zapis grafovych struktur a efektivne s nimi pracovat, coz je vhodne pro matematiku a odvozene vedy. Vetsinou jde rychle zmenit implementaci kdyz zmenim nazor a chci to udelat jinak. Moznost neopakovat dlouhy vypocet a menit jen kod za nim ktery snim pracuje je velmi cenna - hlavne kdyz nemate udelanou predtim udelanou serializaci.
Jenže serializace je dnes laciná. Jak z pohledu implementace, tak z pohledu kapacity a rychlosti záznamových médií. V Pythonu je na to třeba pickle/unpickle, často stačí jednoduchý JSON. Uložit si mezivýpočet je dnes zcela minimální problém.
Lisp se da urcite nahradit ale vetsinou za cenu vetsi prace, a clovek marne hleda ekvivalentni silu. Moderni jazyky se zameruji jinym smerem.
"Moderní jazyky" problémy, které řešil kdysi Lisp, buďto vyřešily podobně jako on (převzaly principy z Lispu a dalších jazyků, zejména funkcionálních) nebo jinak. Máme (hygienická) makra, máme pluginy (s nástupem WebAssembly je lze v pohodě kompilovat za běhu a bezpečně), máme dynamické jazyky, které umí udělat reload modulu. Máme serializaci. Já úplně chápu, že Lisp byl v lecčems první, dodnes asi může lidi inspirovat a v něčem můžebýt šikovnější. Ale stojí ten opruz za to?
4
Vývoj / Re:Prečo nie je Lisp populárnejší?
« kdy: 03. 11. 2025, 19:09:05 »Kód: [Vybrat]pkg install racket -y
racket -e '(require plot) (plot-file (function sin (- pi) pi #:label "y = sin(x)") #:out-file "sine.png" #:out-kind '"'"'png")'
convert sine.png sine.gif
Díky, že jsi ukázal, proč je Python populární a Lisp (Scheme) není.
5
Vývoj / Re:Prečo nie je Lisp populárnejší?
« kdy: 03. 11. 2025, 07:12:07 »Lisp, tedy common lisp, je stale dobre pouzitelny jazyk ktery v nekterych aspektech nema moc alternativ - vymena kodu za behu se zachovanim dat, prirozene datove struktury schopne uchovavat slozite grafove struktury nebo xml s moznosti modifikaci beznymi funkcemi jazyka a mnoho dalsich. Je to vhodne hlavne pro nejaky vyzkum nebo slozitou analyzu, a neni to ani pomale.
Jsou to skutečně věci, které jsou v praxi těžce nahraditelné? Nebo je to spíš taková ta obecná představa typu "Lisp je jazyk vhodný pro umělou inteligenci"?
Zapis prirozene ukazuje kompilatoru/interpretu jak by se mohl vypocet paralelizovat coz by mohlo ladit se soucasnym vyvojem hardwaru - moc jader, casto nevyuzitych.
Tohle je podle mě úplná nepravda. Pokud napíšu sekvenční algoritmus v Lispu, žádný zápis mi nepomůže. Když budu psát paralelizovatelný kód v libovolném jazyce, kompilátor má šanci se s tím vypořádat úplně stejně.
6
Vývoj / Re:Prečo nie je Lisp populárnejší?
« kdy: 02. 11. 2025, 07:04:08 »Není to taková sláva, jak se někteří tváří. Nepřináší nic moc navíc, jen problémy.
Problémy s Lispem nebo s Pythonem? Jaké problémy?
Nevlídná syntaxe, horší infrastruktura, méně knihoven. Tu první otázku nechám bez odpovědi, bylo by to nedůstojné řešit.
Tak pokud ti Python nevyhovuje, používej jiný jazyk. Je jich dost.
O nevlídnosti syntaxe Lispu se nedá mluvit. Je totiž až směšně jednoduchá, jednodušší to snad už nejde. Knihovny jsou, ale programátor si zpravidla navrhne svůj jazyk nad Lispem, ve kterém si pak napíše zbytek aplikace. Pokud nevíš, co je CAR a CDR, tak asi netušíš, o čem je řeč.
Ne, Kite, myslel jsem Lisp a domníval jsem se, že trollíš. Python je populární, takže tyhle věci má dobře. Lisp jsem zažil na škole, s Common Lispem i Scheme jsem se snažil sžít a nešlo nám to. Stejně tak v době, kdy jsem začínal s Linuxem, objevil jsem v distribuci Perl a Python (verze 1.5 nebo kolik). Z Perlu jsem se osypal, Python byl divný (pro člověka, který v té době drtil C a C++), ale cestu jsem si k němu našel. Programování je osobní věc a Lisp je a zůstane jazykem menšiny, zatímco Python je většinově akceptovatelný.
7
Vývoj / Re:Prečo nie je Lisp populárnejší?
« kdy: 01. 11. 2025, 18:12:55 »Není to taková sláva, jak se někteří tváří. Nepřináší nic moc navíc, jen problémy.
Problémy s Lispem nebo s Pythonem? Jaké problémy?
Nevlídná syntaxe, horší infrastruktura, méně knihoven. Tu první otázku nechám bez odpovědi, bylo by to nedůstojné řešit.
8
Vývoj / Re:Prečo nie je Lisp populárnejší?
« kdy: 01. 11. 2025, 17:42:11 »
Není to taková sláva, jak se někteří tváří. Nepřináší nic moc navíc, jen problémy.
9
Studium a uplatnění / Re:je programatoru moc, nebo malo.
« kdy: 29. 10. 2025, 06:23:28 »za me teda: a,1, bet
Hlasuju úplně stejně. Některé ty možnosti jsou tak praštěné schválně? Jde Ti o rozumnou diskusi, nebo trolling?
10
Server / Re:PostgreSQL 18 neinicializuje databázi při instalaci
« kdy: 11. 10. 2025, 15:25:08 »V každém DB serveru bylo mnoho clusterů v jedné DB...
Spíš naopak, ne?
11
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« kdy: 26. 09. 2025, 13:26:26 »Přitom by v některých případech udělali lépe, kdyby „vynalézali kolo“ a „trpěli NIH syndromem“, protože by jejich software (jako celek) byl jednodušší a ještě by se při tom naučili programovat (a ne jen lepit).
Ano, někdy. Problém nezřídka je, že z prostého kola se časem stane celý NIH-syndrom kombajn, protože když už umíme tak hezky programovat, proč si k tomu kolu ještě nevynalézt hřídel atd.
12
Hardware / Re:Ochrana koženky na sluchátkách
« kdy: 24. 09. 2025, 15:54:07 »Ak stoja sluchadla, ktore su po HW stranke uplne super, napriklad 70€, tak davat 15€ za nahradu sa proste nevyplati.
Proč ne?
13
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á?
14
Vývoj / Re:If bez curly brackets?
« kdy: 22. 06. 2025, 10:11:48 »Pripravte sa na budúcnosť! https://github.com/stereobooster/wispLast 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.
15
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ř. tyhleKó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í.
