Příspěvky

46

Vývoj / Re:čisté OP smalltalk, objective C

« kdy: 05. 09. 2018, 19:33:17 »

Kód: [Vybrat]

Právě C++, které objektové paradigma nevynucuje to _částečně_ řeší. Ten zmiňovaný operátor+ se tam dá udělat jako funkce...

Řeší to tím, že rezignuje na objektové paradigma. Řeší to útěkem do strukturovaného neobjektového programování.

V C++ se to pak zamotává. Neobjektová funkce není součástí třídy. Implicitně proto neobjektová funkce operator+() v C++ nemá přístup do vnitřního stavu objektů, se kterými manipuluje. Musíte pak pomocí friend říci třídám, že nějaká vnější funkce bude šmátrat do jejího vnitřního stavu. A zapouzdření a ochrana stavu objektů před okolím dostává na zadek.

Zkrátka v objektovém paradigmatu není daný problém řešitelný. Dá se řešit jen zprasením.

To nebylo myšleno jako jediné, co můžu vytknout. To byl příklad pro mně hodně překvapivé a neintuitivní vlastnosti smalltalku.

Ale ono je to intuitivní. Je to prostě zaslání zprávy objektu. Je to konzistentní.

Jiné jazyky mají seznam věcí, které se dělají opravdu objektivně špatně, mnohem delší.

a) Mně se třeba také nelíbí, že C/C++ neumí ani tak naprosto základní věc, jako je práce s polem. Tedy něco, co uměl už první existující programovací jazyk na světě Fortran v 50. letech 20. století.

b) Ba dokonce C neumí ani rozumnou a efektivní práci s textovým řetězcem. To co v jiném jazyce je (jako operace s textovým řetězcem) na jeden srozumitelný řádek, to je v C kryptický kód na 1-2 obrazovky plné strlen(), strcmp(), strcpy(), ...

c) PHP dodnes nemá ani datový typ textový řetězec! Namísto toho se musíte tlouct se sekvencí bajtů, dávat tomu nějaký význam a charset. Myslel jsem si, že ve 21. století si takovou nesmyslnost nedovolí žádný programovací jazyk na světě.

Jinak řečeno, za obskurní, nedomyšlené a neintuitivní - a plné ošklivých kompromisů co dnes a denně vadí každému programátorovi - považuji dnešní mainstreamové jazyky. Smalltalk je velice čistý, a pokud dokážete říci, že vám vadí jen jedna konkrétní věc - pak je to plus pro Smalltalk. Zbytek je omezení plynoucí z objektového paradigmatu.

47

Vývoj / PHP má jediný vstupní bod do objektu

« kdy: 05. 09. 2018, 19:20:59 »

Měl jsem na mysli, že bych měl v objektu jen jednu metodu, kterou bych měl jako vstupní bod pro volání všech metod.

A také to tak v PHP máte. Protože objekt je v PHP pouze hašovací tabulka se seznamem identifikátorů, tedy i metod objektu. Jen proto vám PHP umožňuje věci jako magické metody __call() a __callStatic(), která se zavolají, pokud není příslušný název metody přístupný. Je to důsledek toho, že PHP má v zásadě jediný vstupní bod do objektu.

V tom se Smalltalk od PHP moc neliší. Rozdíl je v tom, že PHP se to snažilo, ne moc podařeně, zamaskovat "java-like" syntaxí.

Jestli si myslíte, že Smalltalk má jednu metodu na objekt, tak se mýlíte. Ve zdrojovém kódu Smalltalku také píšete haldu metod pro objekt, stejně jako v PHP. Ale vnitřně - jak v PHP, tak ve Smalltalku je jediný vstup do objektu. Smalltalk to má jen oproti PHP udělané čistěji, univerzálněji a lépe.

48

Vývoj / Re:čisté OP smalltalk, objective C

« kdy: 05. 09. 2018, 18:37:40 »

PHP tohle umí také, ale když to někde použiji, tak mě budou mít za čuně.

Vy to ale použijete v každém případě, ať chcete nebo nechcete. Vy nemůžete v PHP nepoužít v objektech předávání zpráv. Jestli myslíte, že PHP či Python to vnitřně dělá jinak než Smalltalk, tak se mýlíte.

Vy si pane strašně pletete pojmy a dojmy. Smalltalk používá vnitřně posílání zpráv. Stejně jako PHP. Stejně jako Python. To je vnitřní implementace, ne to co píšete ve zdrojovém kódu.

49

Vývoj / Re:čisté OP smalltalk, objective C

« kdy: 05. 09. 2018, 18:32:17 »

Ono se to neprosadilo taky proto, že to konzistentní posílání zpráv objektům je ve spoustě případů nekonzistentní se zbytkem světa (nejen programátorského).

Ono se to neprosadilo pouze proto, že v době kdy byl Smalltalk byly pomalé počítače. Vývoj proto šel směrem k jazykům, které vyždímají z počítače maximální výkon. Nic více a nic méně.

Smalltalk je jazyk pomalejší než C/C++, a to byl tehdy zásek. O ni cjiného nejde.

A díky tomu je IMHO Smalltalk ze začátku dost neintuitivní.

Smalltalk je rozhodně intuitivnější než většina dnešních jazyků. Znovu říkám, že Smalltalk naučím bez problémů neprogramátora. U Javy a C# tak úspěšný nebudu.

Stačí součet dvou čísel. Prvnímu sčítanci pošlu zprávu. To totálně neodpovídá tomu, jak se učíme o číslech přemýšlet v matice.

Což ovšem není vlastnost Smalltalku, ale vlastnost naprosto všech existujících objektových programovacích jazyků na světě, co existovaly, existují a existovat budou. Tedy i té Javy, C# a další.

O tom je celé objektové programování, že pracujete s objekty. OOP je přirozené pro unární operátory. OOP nemá možnost řešit binární a n-nární operátory jinak, než tak jak jste popsal.

Jak myslíte, že bude fungovat metoda add() v Javě či C#? Jak myslíte, že bude fungovat operator+() v C++?

No a co? Myslíte, že běžný člověk bude mít problém s konstrukcí [:x | a + b]?

Už jen to, že v součtu řady čísel není žádné ničím výjímečné. Že o to žádáme jedno z nich je jen omezení jazyka. OOP celkově moc nevyhovuje v situacích, kdy pracujeme s více rovnocennýma entitama, protože se zpráva zasílá vždycky jenom jedné.

Právě jste popsal obecné chování všech objektově orientovaných jazyků. Právě jste popsal základní vlastnosti objektového paradigmatu.

A pak třeba takový for cyklus. Ten se řeší taky posláním zprávy číslu (počátečnímu indexu).

Pokud je to jediné, co můžete Smalltalku vytknout, tak je na tom Smalltalk velice dobře. Navíc je to dost obvyklé řešení funkcionálního světa.

50

Vývoj / Re:čisté OP smalltalk, objective C

« kdy: 05. 09. 2018, 18:05:53 »

Pokud mám například volit mezi tím, jestli dám parametru typ Path, nebo popíšu v dokumentaci, že funkce očekává cestu k souboru, tak volím jednoznačně první možnost. Škála věcí, které můžu takovéhle funkci předhodit, je hodně omezená.

A nebo budete ve funkci konstrolovat, jestli jste v parametru dostal cestu k souboru. A hle: Najednou i v dynamickém jazyce máte škálu věcí, které můžete funkci předhodit hodně omezenou.

A znovupoužitelnost je IMHO takový yetti, o kterém každý mluví, ale různí lidé si ho představují různě. Aplikačně specifický kód není znovupoužitelný už z principu. A pomocné věci jsou s rozumným typovým systémem (minimálně nějaká generika) znovupoužitelné dost.

Zkuste ten Smalltalk. Tam uvidíte znovupoužitelnost v úplně jiných dimenzích.

Většina OOP jazyků zprasila objekty dědičností. Chudák dědičnost má vyřešit to, co autoři programovacích jazyků (včetně Javy) nedomysleli. Dědičnost má řešit: 1) znovupoužitelnost, 2) typovou informaci, 3) informaci o interface objektu. Je jasné, že jedna věc nemůže uspokojivě řešit tři odlišné věci - a proto to drhne kam se podíváte.

Smalltalk jako dědičnost má pouze znovupoužitelnost. Na rozdíl od Javy/C#, které se do dědičnosti plete miliarda věcí naráz.

51

Vývoj / Typový systém v OOP

« kdy: 05. 09. 2018, 17:50:55 »

No tak ty problémy, které jsou cenou za tu flexibilitu, nejsou vůbec malé a to člověk ani nemusí být typový onanista.

Obecně ovšem jen málokterý programovací jazyk má rozumný typový systém. To platí pro objektové jazyky i jazyky jiných paradigmat.

Ale především: Zavést typový systém na objektovém programování znamená zmrvit a pokřivit OOP. Vždyť se s tím programovací jazyky perou. Právě proto každý OOP jazyk zkouší trochu jinou koncepci.

Dodnes je to s typy na OOP takové vachrlaté. Každý OOP jazyk na to jde jinak. Někde typy spražují s dědičností. Jinde se stejným rozhraním ("duck typing"). Další zase jinak.

52

Vývoj / Re:NIMH Arduino nabijecka

« kdy: 05. 09. 2018, 17:38:08 »

Ted neresim jak spravne nabijet, jakym proudem atd.. ale zajima me jak realizovat spravne to mereni napeti. Jak zmerit napeti baterie tak, aby pri pripojene nabijecce nemeril napeti nabijeciho zdroje?

Právě proto nabíječky nabíjí pulsně. Chvíli nabíjí, pak odpojí napětí aby změřili napětí článku, pak zase nabíjí, pak zase měří - a tak to velice rychle střídají. Tedy tak se chovají, pokud potřebují měřit napětí článků naprázdno.

53

Vývoj / Re:čisté OP smalltalk, objective C

« kdy: 05. 09. 2018, 17:27:32 »

1. V čom je OP v jazyku smalltalk čistejšie ako v C# a Jave? A prečo keď je lepšie tak sa nepresadilo?

Smalltalk je čisté, jednoduché objektové programování. Vše je objekt - proměnná, blok kódu, podrpogram, zpráva objektu, cokoli. Neexistuje nic co by nebylo objektem. Díky tomu je to jazyk čistý a velice jednoduchý.

Java ani C# de facto objektové nejsou. Mnoho věcí nejsou v Javě ani C# objekty. Například proměnné typů char, int, a další, které nejsou objekty. Blok kódu není objektem. Metoda třídy není objektem. Podmínkový příkaz není objektem. Cyklus není objektem. Atd. atd. atd. Ve Smalltalku je objektem naprosto všechno - a proto je to logičtější.

De facto při porovnání těchto jazyků je Smalltalk mnohonásobně objektovější než Java/C#. Díky tomu je Smalltalk jednodušší, konzistentnější a mocnější v řadě operací.

Neprosadilo se to proto, že do prosazení Smalltalku nikdo nenalil miliardy dolarů jako v případě Javy Sun nebo C# Microsoft. Představa, že se prosadí lepší, nikoli to čeho se lijí astrnomické sumy - je naivní.

2. Neni to jedno či zavolám metódu, alebo pošlem správu? Akú mi dáva message passing výhodu oproti volaniu metód?

Obojí jsou různé věci, mají různé chování.

a) Poslání zprávy je poslání zprávy - tak jak to v OOP má být. Objektu pošlete zprávu nějakého názvu a parametry. Je na objektu, co s tím udělá.

Objekt u posílání zprávy má jediný vstup/podprogram - kam zaslat zprávu. Je to velice flexibilní a jdou s tím velké kusy. Snadno se tak dělá zasílání zpráv třeba přes počítačovou síť, nebo program může běžet distribuovaně na několika počítačích.

b) Volání metody je pouhé low level volání podprogramu pomocí pointeru. Je to úroveň strojového kódu procesoru. Voláte podprogram (a jen pouhou náhodou ten podprogram má první parameter pointer na data objektu).

Objekt je v tomto případě obrovská kupa vstupů/podprogramů (metod). Každá metoda nezávisle mění objekt a jeho stav. Hůře se nad tím získává kontrola.

Volání metod je úlitba a krok směrem k assembleru a strojovému kódu.

Má zmysel učiť sa smalltalk? čo mi to prinesie oproti bežným objektovým jazykom. Je vývoj v Smalltalku rýchlejší alebo kde je jeho hlavná výhoda.

Zkus to a uvidíš. :-)

Smalltalk je jeden z mála jazyků, který naučím i svou mámu, která o programování nemá moc ponětí. Je to tak jednoduchý a konzistentní jazyk, jak se to málokde jinde povedlo.

Ve Smalltalku se programuje velice rychle, až expresně. Určitě násobně rychleji než v Javě či C#.

Smalltalk je ovšem odlišný. Data a stav dat si ukládá mezi spuštěními. Smalltalk je v podstatě objektová databáze (úložiště), a nad tím luxusní grafické prostředí. Smalltalk mění objekty v této databázi pomocí programovacího jazyka. Jinak řečeno, nezapomíná změny a data. Je to jiný přístup.

Dnes už je Smalltalk dost v pozadí. Pokud očekáváš uplatnění ve firmách, tak to vzdej. Mimochodem:

1) programovací jazyk Ruby není nic jiného než zpackaná a trochu nedomyšlená kopie Smalltalku

2) Programovací jazyk Objective C je kříženec C a Smalltalku

54

Hardware / Re:Výběr domácího 16portového switche

« kdy: 05. 09. 2018, 12:02:52 »

Zatím co jsem viděl tak levné 5-8portové SoHo switche bez managementu zá pár set Kč a stejně tak levné "websmart" switche (16-24 portů pod 4000 Kč) mají společnou jednu achillovu patu: vodnaté elyty.

Musím pochválit ten web, je skvělý. Asi na pár dní vynechám root i fórum a pročtu si ho.

55

Hardware / Re:Výběr domácího 16portového switche

« kdy: 05. 09. 2018, 11:42:03 »

Miloslav, kazdy mame jine potreby a predstavy o vyuziti technologii. Ja treba upgraduji z gigabit na 10gbit, mam rack, obrovsky storage, nekolik 24port switchu a v dohledne dobe mi v ramci jednoho proof of concept pribude dalsich 100 portu. Vse v baraku.

Ano, ale zajisté také chápeš, že nejsi běžný domácí uživatel. Jsi značný extrém na hranici statické chyby v domácích požadavcích na sítě. Jinak řečeno, kopírování tvé domácí sítě není pro většinu domácností příliš dobrý nápad.

Stejně tak věřím, že někde na světě se našel člověk, který si místo tiskárny pořídil velkoobjemový tiskový stroj. A možná dva lidi ze 7 miliard na světě to i využijí. Ale je to extrém, nikoli běžný use case.

56

Software / Re:Google chce zabít URL

« kdy: 05. 09. 2018, 11:39:08 »

Hej, Ponkrác, ktoré sú to tie "gigantické JavaScriptové frameworky"? Daj nejaký ten príklad, nepoznám totiž ani jeden gigantický framework v JS. Skôr mám pocit, že sa vyjadruje školy ku všetkému preto, že si grafoman, nie preto, že vieš o čom hovoríš. Takže? Ktoré sú gigantické a prečo?

Navzdory tvým výkřikům je dnes web zapráskaný zbytečným JavaScriptem. Je to moderní trend, a ve většině případů je to zbytečné. To ví každý, kdo neslezl právě ze stromu. Kolik se toho stáhne z browseru na hlavní stránce webů:

idnes.cz – 107 requestů na JavaScript, 899 KB ve skriptech

csfd.cz – 60 requestů na JavaScript, 649 KB

alza.cz – 23 requestů na JavaScript, 827 KB

heureka.cz – 41 requestů na JavaScript, 379 KB

super.cz – 21 requestů na JavaScript, 390 KB

centrum.cz – 56 requestů na JavaScript, 734 KB

aktualne.cz – 75 requestů na JavaScript, 805 KB – btw hlavní stránka má celkem 373 requestů (z toho 15 chyb) a velikost 13,6 MB. Tam vyčerpáte mobilní data celkem rychle.

https://404m.com/2018/01/04/rychlost-webu-neni-jen-tom-za-rychle-se-stranka-stahne-hostingu/

57

Vývoj / Re:Framework Nette pro dynamický web

« kdy: 05. 09. 2018, 11:29:00 »

Už jen tím, že jsi se na tuhle otázku zeptal nebudeš asi moc programování znalý, jinak by jsi se zeptal, jestli si ovšem senior tak pardón, ale nevypadá to tak.

Stal se obětí nestálého spamu, který se line od Davida Grudla a Nette, že je to nejlepší věc ve vesmíru. Že to vyřeší světový mír, že to vyřeší válku v Afghánistánu, že to vyřeší i nepravidelnou stolici, a nedostatek sexu. Prostě Nette je všelék, a všude už je to slyšet.

Jen chybí střízlivé hodnocení Nette. Není to všelék na všechno - je to framework, který některé problémy vyřeší, a jiné - jako je třeba problém tazatele - téměř nikoli.

Nelze než doporučit každému, aby se seznámil s více frameworky. Pak pochopí, že všudypřítomná reklama na "dobrou dokumentaci" a řadu báječných vlastností Nette je v realitě mnohem smutnější a šedší. To neznamená, že Nette je špatný, ale chybí střízlivý pohled na Nette jako sůl.

JavaScript a JavaScriptový framework je to hlavní, co by mělo teď pracovat.

58

Vývoj / Re:Framework Nette pro dynamický web

« kdy: 05. 09. 2018, 11:25:55 »

Už jen tím, že jsi se na tuhle otázku zeptal nebudeš asi moc programování znalý, jinak by jsi se zeptal, jestli si ovšem senior tak pardón, ale nevypadá to tak.

Stal se obětí nestálého spamu, který se line od Davida Grudla a Nette, že je to nejlepší věc ve vesmíru. Že to vyřeší světový mír, že to vyřeší válku v Afghánistánu, že to vyřeší i nepravidelnou stolici, a nedostatek sexu. Prostě Nette je všelék, a všude už je to slyšet.

Jen chybí střízlivé hodnocení Nette. Není to všelék na všechno - je to framework, který některé problémy vyřeší, a jiné - jako je třeba problém tazatele - téměř nikoli.

Nelze než doporučit každému, aby se seznámil s více frameworky. Pak pochopí, že všudypřítomná reklama na "dobrou dokumentaci" a řadu báječných vlastností Nette je poněkud jinak.

JavaScript a JavaScriptový framework je to hlavní, co by mělo teď pracovat.

59

Hardware / Re:16-ti portový switch

« kdy: 05. 09. 2018, 11:19:02 »

To bych taky rád věděl. Jako že střecha pro domácnost může být z prasklých zmetkových křidlic, cihly na doma není potřeba vypálit, auto pro soukromou osobu může mít brzdu jenom na jednom kole,... ?

Asi dělám něco blbě. Mám domácí síť. Nemám doma ani rack, ani problémy PetraM. Nezasíťovávám Silicon Valley, ale byt či dům.

Takže nekupuji ke každému switchi polici do racku.

Každá síť má určitou potřebu rychlostí a počtu linek na různá místa bytu/domu. Rozdělením síťě do několika segmentů ušetřím dráty a o nic nepřijdu, když budu respektovat potřeby.

Celou síť jsem postavil s jedním routerem a dvěma 8portovými switchi 1Gbps - to je hrozné drama ve spotřebě a počtu zásuvek. Přímo armageddon, asi nastane konec světa a skončí rovnou celý vesmír, protože to žere celkově asi 15-20 W. Nejspíše vyhoří rovnou elektrárna, protože to nezvládne. UPSku 700 VA to zcela určitě nepřetíží.

***

Doufám, že stejně kvalitně blbnete doma i jinde.

Proč mít blbou laserovou tiskárnu za pár tisíc Kč? Věřím, že PetrM netroškaří a rovnou si domů pořídil celý tiskový ofsetový stroj pro velkoobjemové nakladatelství i s řezačkou!

Proč mít obyčejný počítač? PetrM zcela jistě obětoval celý obývák a postavil si rovnou celou serverovnu i s dvojím zálohováním zdrojů a provozuje v něm pár stovek počítačů.

60

Software / Re:Google chce zabít URL

« kdy: 05. 09. 2018, 11:07:04 »

Problem je, ze jsou znaky, ktere vypadaji v podstate stejne, ale co se tyce kodovani, lisi se - takze pak se da velmi snadno URL podvrhnout.

Stejně jako vypadají v podstatě stejně znaky malé L a velké I. Omezení na anglickoi abecedu má stejný problém. Nic to neřeší.