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 - Miloslav Ponkrác

Stran: 1 2 [3] 4 5 ... 8
31
Studium a uplatnění / Znalosti a cos(pi/2)
« kdy: 07. 09. 2018, 16:52:49 »
Citace
Kde tvrdím, že je izolovaná? Pouze odpovídám k tomu, že "znalosti samy o sobě" jsou k ničemu bez pochopení jejich významu a souvislostí. Na co je "znalost sama o sobě" biflování se hodnot goniom. fcí ve škole, pokud nebudu chápat, co daná funkce je? Já taky z hlavy nevím hodnotu cos(pi/2), k čemu... Ale vím, co ta funkce znamená a umím hodnotu si někde najít. A o tom to je - práce s informacemi, jejich hledání a ne učení se znalostí nazpaměť.

Já přesně vím, že cos(pi/2) je 0. A nemusím si to pamatovat, ale snadno to odvodím z toho, že vím co funkce cosinus znamená. A pokud vím, co funkce cosinus znamená, tak si to jedné vteřiny v hlavě dovodím, že cos 90 ° = 0.

Takže kdybyste skutečně ty znalosti měl, a skutečně věděl co funkce kosínus znamená, nemusel byste: 1) ani hledat hodnotu cos(pi/2), 2) ani si pamatovat hodnotu cos(pi/2). A to jsou ty skutečné znalosti, nic jiného.

Je úplně jedno, jestli si kosínus představíte na jednotkové kružnici, nebo na Gaussově rovině komplexních čísel, nebo na jakémkoli jiném případu, kde se kosínus používá.


32
Studium a uplatnění / PHP si s typy dělá co chce
« kdy: 07. 09. 2018, 16:45:01 »
Citace
PHP si s typy prostě dělá co sám chce podobně jako JS a je na to potřeba si dávat pozor - pokud si nejsem jistý, doplním před výpočtem nebo porovnáváním konverzi na stejný typ.

PHP má jasně definováno, co se děje s typy. Dělá tedy přesně to, co má předepsáno.

Ochotnější automatické přetypování v PHP je důsledkem toho, že PHP vychází z Perlu.

33
Studium a uplatnění / PHP výjimka v kontrolleru
« kdy: 07. 09. 2018, 16:39:36 »
Citace
c) Používať try/catch v kotrolleri alebo nie? Podľa PHP delusions https://phpdelusions.net/delusion/try-catch treba použiť try/catch len v zriedkavých prípadoch, inak to treba nechať doplávať do systémového kódu, ktorý by mal vygenerovať error page.

Pro výjimky platí to co všude.

a) Pokud víte, jak výjimku ošetřit, a dostat se do rozumného stavu - použijte try/catch, a výjimku chyťte a ošetřete.

b) Pokud nevíte, jak výjimku ošetřit, ale je třeba změnit typ/zprávu výjimky na něco jiného, pro volající vrstvy vhodnějšího - použijte try/catch, výjimku chytněte a vyhoďte namísto ní vhodnější výjimku.

c) Pokud nevíte co s výjimkou, nechte jí proplavat výše.

Citace
Ja som primárne Javista. V Java sa viem obvykle dopátrať ku best practices, v PHP sa mi to zdá viac zamotané.

Best practices jsou na 99 % společné mezi všemi jazyky.

V PHP je pouze více možností. A také se v PHP pohybují méně zkušení programátoři - takže se často dělají věci, které nejsou příliš dobré.

34
Studium a uplatnění / Zavírání DB připojení
« kdy: 07. 09. 2018, 16:33:37 »
Citace
[a) Máme Symfony controller a v ňom sa pripájame cez DBAL na databázu. Je potrebné nejako explicitne
uzatvoriť objekt connection?
Vraj netreba, lebo PHP má všetko na konci cyklu request/response uzavrieť, ale nejako sa mi to nezdá. V Jave poctivo voláme na objekte connection close metódu.

Kód: [Vybrat]
/**
 * @Route("/getdata", name="getdata")
 */
public function data(Connection $conn)
{
    $data = $conn->fetchAll("SELECT * FROM countries LIMIT 5");

    return $this->json([
        'data' => $data
    ]);
}

Já se ve všech programovacích jazycích a frameworcích řídím tím, že kdo objekt vytvořil, ten ho má zavřít. Je to takové nepsané pravidlo. Pokud je nutné zrušit objekt někým jiným - bývá to popsáno a zdůrazněno.

35
Citace
Operátor === sa odporúča používať, má odstraňovať problémy ==. Pritom prináša ďalšie problémy, trebárs:

Kód: [Vybrat]
$x = 100;
$y = $x + 0.0e0;
echo ($x ==  $y) ? 'equal' : 'not equal';
echo ($x === $y) ? 'equal' : 'not equal';

Pri pripočítaní nuly s desatinnou čiarkou dôjde k situácii, kde operátor === vráti 'not equal'.

V každém programovacím jazyce platí, že:

a) Celá čísla jsou čísla přesná, tudíž jejich porovnávání dopadne vždy správně.
b) Reálná čísla (v plovoucí čárce) jsou čísla nepřesná, tudíž jejich porovnávání nemusí dopadnout správně.

V každém programovacím jazyce platí, že porovnávání dvou stejných reálných čísel může nebo nemusí ukázat rovnost. Je to proto, že reálná čísla nejsou přesná.

Právě tento fakt je jediným důvodem, proč se zavedla celá čísla v programovacích jazycích. Protože celá čísla se chovají předvídatelně, reálná čísla nikoli. Reálná čísla se nikdy, zdůrazňuji nikdy, neporovnávají přímo - protože nelze zaručit jak to dopadne.

Pokud už je nutné porovnávat reálná čísla, dává se tomu tolerance.

Namísto

if ($x == $y) echo "Reálná čísla jsou stejná";

se píše něco jako

if (\abs($x - $y) < 1e-5) echo "Reálná čísla jsou stejná";

36
Studium a uplatnění / PHP operátory == a ===
« kdy: 07. 09. 2018, 16:17:20 »
Citace
Ďalšia vec, ktorú som si včera všimol. PHP má podobne ako JavaScript dva operátory na porovnanie, == a ===.
Operátor == má množstvo problémov, napr:

Oba operátory pracují tak jak mají.

1) Operátor === a !== vyžadují pro rovnost 1) oba operandy musí být stejného typu, 2) oba oerandy musejí mít stejnou hodnotu. V případě objektů se za stejnou hodnotu považuje pouze to, že se jedná o stejné objekty.

2) Operátory == a != se naproti tomu snaží nejdříve provést typové konverze.

a) Všechny null operandy převede na prázdný string.
b) Pokud je alespoň jeden operand boolean, převede i druhý operand na boolean.
c) Pokud je alespoň jeden operand číslo, převede i druhý operand na číslo.

A pak teprve porovnává. S tím, že:

a) Při porovnávání objektů se porovnává rovnost typu objektů a rovnost všech astributů (proměnných) třídy.
b) Porovnávání pole s jakýmkoli jiným typem dopadne tak, že pole je vždy větší než to druhé.
c) Porovnávání objektu s čímkoli jiným - objekt je vždy větší.
d) Řetězce a čísla se porovnávají očekávaně (po typové konverzi).

Citace
Číslo 12 a string '12b' sú podľa tohoto operátora == rovnaké.

Protože jeden z operandů je číslo. Takže PHP převede i druhý operand "12b" na číslo. PHP bohužel řetězce na čísla převádí velkoryse, bere zepředu všechny číslice, dále to ignoruje. \intval("12b") je tedy 12.

Po typové konverzi pak PHP porovná 12 == 12, a to je "rovnaké".

37
Studium a uplatnění / PHP include/require versus Python import
« kdy: 07. 09. 2018, 16:03:44 »
Citace
Tomu chápem, akurát to pozajtra zabudnem. Python má jeden import, PHP má na výber štyri možnosti, a teraz programátor musí uvažovať, ktorú si má zvoliť. Je to čo mu sa tuším hovorí zbytočný mental burden.

Programátor uvažovat nemusí. Na include může rovnou zapomenout. Pro vkládání knihoven může používat pouze require_once, a dál uvažovat nemusí.

Python používá import v podobném duchu jako require_once. Python řeší moduly, PHP pouze vkládá soubory - i když to ve výsledku dopadne podobně.

38
Studium a uplatnění / PHP
« kdy: 06. 09. 2018, 23:30:00 »
Citace
Pretrvávajú však početné nedostatky. Väčšina vznikla preto, lebo sa jazyk vyvíjal hurá štýlom, bez akéhokoľvek plánovania. Veď PHP pôvodne vzniklo ako súbor Perl scriptov, čož teda rozhodne nie je dobrý začiatok.

Ty nedostatky jsou tu proto, že PHP nemá psaný standard jazyka.

Programovací jazyk C byl nic moc, dokud nepřišel jeho psaný ANSI standard. Programovací jazyk C++ byl nic moc, dokud se neustanovil standard C++98. Atd. Java/Python má také své standardy, jinak se nic v jazyce neděje.

Citace
Spomeniem zopár PHP podivností: FALSE, false, true, TRUE. FALSE a TRUE sa dajú predefinovať (!?),
echo true vypíše 1, echo false nevypíše nič.

To je historická záležitost. Byly doby, kdy neexistoval v PHP ani datový typ "boolean" ani "null". Z historických důvodů byl false prázdný řetězec a true celé číslo s hodnotou 1. Echo tuto věc dodnes emuluje.

Pamatuji si doby, kdy null hodnota v MySQL tabulce se vracela v PHP jako false.

Citace
Väčšina jazykov má rôzne typy kolekcií, trebárs zoznamy, slovníky, množiny a pod. PHP má všetko v jednej kolekcii array.

V PHP je všechno řízeno jako "array". Autoři si to prostě zjednodušili ad absurdum.

1) Datový typ "array" je asociativní pole, kde klíč je int/string.

2) Objekt je to samé asociativní pole.

3) Funkce je zase asociativní pole, které nese proměnné.

Citace
Nikdy som nepochopil rozdiely medzi require, require_once, include, include_once.
PHP má nekonzistentné názvoslovie funkcií (Laravel kvôli tomu vytvára špeciálne svoje knižnice), nekonzistentné poradie argumentov funkcií.

Require udělá fatální chybu, když vkládaný soubor neexistuje - a zastaví celý program. Include při neexistenci souboru vyvolá jen warning a program pokračuje.

Cokoli s _once ignoruje vložení, pokud už byl soubor někdy předtím vložen.

Citace
Je to veľká škoda, lebo inak by to bol omnoho lepší jazyk.

Chybí mu málo k dokonalosti. Ale zřejmě jim chybí vývojáři.

39
Studium a uplatnění / PHP, nekompatibilní změny
« kdy: 06. 09. 2018, 22:00:04 »
Citace
Já v přechodu mezi PHP 5 a PHP 7 neměl nějaký zvláštní problém, PHP 7 jsem nasazoval celkem brzo a dle statistik jsem nebyl sám. A nevzpomínám si, že bych nějak výrazně předělával projekty. O zpětné kompatibilitě bychom mohli polemizovat roky, já měl například větší problémy mezi Pythonem 2 a 3 než mezi PHP 5 a PHP 7. Zpětná komatibilita, to rozhodně není u PHP tak výrazný problém (v porovnání s ostatními projekty).

Python provedl za posledních 10-15 let provedl jednu jedinou nekompatibilní změnu, z Pythonu 2 na 3. Nutno říci, že jazyk byl značně pročištěn a vylepšen, byť změna nebyla zcela nutná. Já sám jsem to komentoval nelibě.

K PHP jsem se dostal někde na rozhraní PHP/FI, PHP 3. Od té doby je to jedna nekompatibilní změna za druhou. Největší průšvih byl asi přechod PHP 4 na PHP 5. To byl takový průšvih i pro autory PHP, že sami ztratili odvahu. Přechod trval obrovskou spoustu let.

Aby ospravedlnili další změny, slíbili že v příští verzi PHP 6 bude konečně ten datový typ "textový řetězec" (věc, kterou má Python či Java od samého začátku, ale PHP dodnes chybí). Dopadlo to tak, že žádný "textový řetězec" není dodnes. A verze PHP 6 byla přeskočena, protože autoři jazyka dali k dispozici tuny a tuny materiálů, jak bude vypadat PHP 6 - že vyšlo tisíce knih na téma PHP 6.

V každé verzi mizí řada knihoven, takže přepisům zdrojového kódu se nejde vyhnout.

Citace
... hateři PHP se do toho vlákna vtírají a otravují ostatní tím, že vytrubují do světa nesmysly o PHP. Sám moc dobře víte, že každý jazyk má své slabiny a že pro každý se dá udělat seznam věcí, které prostě nefungují dobře.

Já hlavně nemám rád nálepkování "hateři" a "nesmysly", aniž by byly věcné argumenty.

Tazatel se ptal, jaký webový framework zvolit, že dělá PHP a láká ho Python. Pak je naprosto přirozené, že mu lidi radí přechod od PHP k tomu Pythonu. Protože po všech stránkách je to lepší řešení - na web i jinam.

PHP jazyk těžce zaspal. Python nabízí zcela základní a samozřejmé věci, které na web potřebujete:

1) Má textový řetězec jako datový typ, a propracovanou práci s textovými řetězci přímo v jazyce. Web je o práci s texty.

2) Python se překládá do binární podoby jen jednou, nikoli při každém spuštění. Nesnižuje se tedy drasticky výkon webového serveru jen proto, že každý request znamená nový překlad zdrojáků.

3) Python má ladící nástroje už v základním balíčku. Zato PHP v základním balíčku vypadá spíše jako standard IT roku 1950 podle své vybavenosti.

4) Python může běžet tak, že nemusí nutně končit všechny objekty s requestem. U PHP kromě persistentního database connection a serializovaného ukládání bajtového řetězce někam nic takového.

Atd. atd. atd.

PHP ani ve verzi 7 neřeší základní problémy webového vývoje, tedy toho, na co je určen. Ono je hrozně fajn, že každá další verze je rychlejší než předchozí, když to zároveň PHP výkonově zatluče překladem zdrojových kódů při každém requestu, a nutností budovat všechny objekty znovu od začátku při každém requestu. V roce 2018 už je to výsměch do očí programátorům, to se na mě nezlobte.

Ve své podstatě PHP frameworky do značné míry řeší nedostatečnosti PHP jazyka.

Citace
Zuckerberg napsal něco v PHP a výsledek je takový, že je 5. nejbohatší muž na světě. Jeho projekt v PHP byl a je výdělečný. Tečka.

Protože v roce 2004 byla PHP verze 4 docela dobrá volba. Dnes by zvolil něco jiného. To je to základní umění, zvolit dobré nástroje vhodné pro daný cíl a danou dobu.

Zuckerberg nakonec musel svou nevhodnou volbu řešit. Takže si buďte jist, že žádný facebook na současném PHP interpretru, který si stáhnete z www.php.net neběží.

-- PHP je tak nevhodný, že každý větší projekt, který PHP použil musel řešit těžké a drastické problémy zejména s výkonností.

1) Facebook je řešil tak, že si napsal vlastní překladač ze své verze PHP do C++. Takže nakonec přeložil zdrojáky kompilátorem C++, a tak to dnes běží. Tím mimo jiné vyřešil i to, že mu autoři PHP neustále přepisují PHP jazyk pod rukama, což už Zuckerberga nemusí trápit.

2) Wikipedii si nakonec napsala vlastní optimalizovaný PHP interpretr. Ale i tak potřebuje mnohonásobek serverů, než kdyby wikipedii běžela v rozumnějším nástroji než PHP.





40
Studium a uplatnění / Re:Jaký webový framework zvolit?
« kdy: 06. 09. 2018, 19:41:17 »
Citace
c) protože použil PHP a napsal v něm revoluční aplikaci/službu, kterou používá přes 2 miliardy uživatelů (a samozřejmě hateři, co nikdy nic nedokázali vám budou tvrdit, že použití čehokoliv jiného je lepší, něco jako když Franta Pepa příjde na pracák a paní úřednici tam tvrdí, jak ten Facebook je špatně napsanej a on by ten Facebook napsal v něčem jiném a jak by to úplně jinak šlapalo, ...)

Existuje firma, která v historických začátcích vydělala velké jmění na technologiích děrných štítků a věcí kolem toho. Podle stejné logiky by se to mělo následovat. Kdo chce vydělat, měl by používat děrné štítky.




41
Vývoj / Frameworky nejsou zlo
« kdy: 06. 09. 2018, 16:39:30 »
Citace
Frameworky jsou obecne zlo. Jejich reklama spociva v ukazani ze na trivialnim pripade usetris 90% kodu, ale pak kdyz chces udelat neco mimo oblast trivialnich aplikaci toho frameworku, tak zacnes vynakladat vetsi usili jak ze zajeti frameworku uniknout nez kdyby sis to napsal zpocatku sam.

To záleží na 1) kvalitě toho frameworku, 2) oblasti, pro kterou je framework určen.

Univerzální kvalitní framework je požehnání. V zásadě není důvod, proč vše psát od nuly.

Jinou věcí je, že si někdo představuje, že použije framework aniž by věděl, co ten framework dělá. To v případě netriviálních aplikací není možné.

Citace
Doporucuju pouzit knihovnu nebo sadu knihoven co poskytuje casto se opakujici problemy v dane domene. Holt si to budes muset poslepovat sam ale odmenou ti bude ze to 1. pochopis 2. budes mit sanci to dokoncit, protoze mas netrivialni pripad uziti.

A jediným výsledkem je, že si na základě té knihovny napíše vlastní framework, oblepí si tu funkci main. :-)

Citace
Druhy rozdil je, ze framework = implicitni magie a knihovna = explicitni abstrakce.

Jestli si myslíte, že ve špatné knihovně/frameworku se nelze zamotat do imiplicitní magie, tak se mýlíte.

42
Studium a uplatnění / Re:Jaký webový framework zvolit?
« kdy: 06. 09. 2018, 16:23:26 »
Citace
Poradím vám, pokud o PHP a programování nic nevíte, pak se nechoďte do zdejší diskuze ztrapňovat. Každé malé děcko ví, že PHP je napsané v C a vychází z C a Javy.

PHP vychází především z Perlu. A pak PHP jako když pejsek s kočičkou vařili dort - neustále vycházelo a inspirovalo se něčím jiným. Tu C, tu Javou.

Mimochodem, Python je také napsaný v C. Jak ví každé malé dítě. To, v čem je jazyk napsaný je irelevantní věc.

Problém PHP je, že je to naprosto nekonzistentní jazyk typu každý pes jiná ves. Má četné problémy a nedostatky. PHP se drží spíše z historických důvodů - kdysi to byla jediná rozumná a open source konkurence ASP. Tím se rozšířila. Nicméně nelze než souhlasit, že pokud je to možné, je lépe z PHP utéct.

Citace
Kombinace znalostí C (C++, C#), Java a PHP je logická a velmi použitelná (na něco se hodí to a na něco jiného zase ono)

Programovacích jazyků se naučíte kolik chcete. Protože programovací jazyk je jen nástroj, nic jiného. To podstatné, co programátor umí je algoritmizace a řešení problémů - a to je málo závislé na programovacím jazyku.

Stejně jako si vybíráte při práci dobrý šroubovák, tak se snažíte si vybral dobrý programovací jazyk.

Citace
Nechápu, proč mají zamindrákovaní lidé problém s PHP. Protože je populární? Protože ho například používá jeden z nejúspěšnějích a nejvýdělečnějších projektů poslední doby Facebook? Nechápu, kde se v lidech diskutujících na root.cz bere ten dar diskutovat na úrovni de..ntích Novnikářů z Novinky.cz?

Protože PHP je objektivně zamotaný a špatný jazyk z mnoha důvodů. Na to člověk nemusí mít mindráky aby k tomuto závěru došel.

Navíc neexistuje ani žádný standard PHP. Existuje jedna implementace, a co je v ní je de facto standard. V každé verzi PHP se provedou nekompatibilní změny, které nutí všechny opravovat zdrojové kódy, pokud chtějí přejít. Proto také při změně major verze PHP trvá 3-4 roky než se nová verze rozšíří. Protože to autoři a vývojáři jazyka/interpretru PHP vedou velice špatně.

Dodnes jazyk PHP - po 23 letech - nedotáhl ani do toho, aby měl datový typ "textový řetězec".

Protože PHP nenabízí ani kompilaci do binárního/p-kódu, při každém HTTP requestu se znovu a znovu kompiluje jako u pitomců. Protože základní PHP balíček nenabízí ani tak samozřejmou věc, jako je debugging. Srovnejte to s tím, co dostanete u většiny balíčků jiných jazyků za nástroje už v základu.

Citace
Zkuste si někdy práci s PHP7 (včetně typové kontroly, skalárních datových typů, návratových hodnot, atd.)

Že by už měla datový typ "textový řetězec"? Bylo by to záhodno, protože web je hodně o práci s textovými řetězci. Ne, to stále nemá - možná ve 28. století bude mít PHP tak záklandí věc, jako je typ "textový řetězec". Po 23 letech se v PHP 7 zmohli jen na to, že umožnili vyrobit bajtovou sekvenci s UTF-8 pomocí hexadecimálních konstant kódových pozic.

Že by už konečně umožňovala přeložit zdrojáky do binární podoby, aby se konečně zvýšil výkon PHP aplikací?

Že by už konečně byl v základě rozumný debugging?

Ne, PHP 7 se rozhodla změnit tak záklandí věci, jako jsou výjimky. Už výjimky nevycházejí z \Exception, ale z \Throwable. Když vznikne chyba, už to není PHP error, ale výjimka.

Citace
Pokud jste někdy pracovali s PHP 3/PHP 4, budete překvapeni, o čem dnes PHP je. I když u vás pochybuji, že jste kdy v životě programovací (speciálně pro vás skriptovací) jazyky viděli.

O tom, že v Javě, Pythonu a dalších jazycích jsem schopen na stejném serveru udělat mnohonásobně vyšší výkon webového sídla než v PHP. O tom to je.

PHP neexceluje ani v té množině problémů, pro které je určeno.

43
Vývoj / Re:čisté OP smalltalk, objective C
« kdy: 05. 09. 2018, 20:07:35 »
Citace
No právě. Fundamentální nedostatek jakéhokoliv paradigmatu se dá řešit jedině tak, že se nepoužije.

Vy to nezýváte nedostakem, ale ona je to vlastnost. Nebo máte pocit, že v objektovém programování nelze sčítat čísla? Což byl příklad, který jste uvedl. Není třeba nic prasit. Jen se vám objektový způsob nelíbí, což je ale jen váš subjektivní dojem - nic jiného.

Na světě není nic zadarmo. Vy se snažíte vyvolat klamný dojem, že zprasením/opuštěním paradigmatu získáte jen plusy. Vy můžete zprasit paradigma, ale získáte tím nekonzistenci jazyka, složitost jazyka, a řadu dalších problémů.

Citace
Jak jinak by to mělo jít řešit?

Vy jste slušný manipulátor a demagog. Vyvoláváte tu dojem, že Smalltalk neumí sčítat čísla. A že ke sčítání čísel nelze použít objektové paradigma. Co na to říci?

Řešíte problém, který neexistuje. Chováte se jako politik, který vymyslel umělý neexistující problém. A teď ho chce řešit.

Citace
Proto se taky Stroustrup tak urputně brání vynucování nějakého paradigmatu. Pro každé existují situace, kam se ani trochu nehodí.

Ach jo. C++ je jazyk, jehož paradigma je být rychlý a vyrábět rychlé binárky.

Nebojte se, Stroustrup kvůlu tomu paradigmatu, tedy "rychlá binárka" toho v C++ zprasil opravdu hodně.

Tedy i Stroustrup v C++ vynucuje.

Citace
No ano. Moje kritika Smalltalku spočívá v tom, že tlačí objektové paradigma tak důsledně, že jeho problémy vyniknou víc než kdekoliv jinde.

Já ale ten dojem nemám. Mám dojem, že toto vaše tvrzení je stejná demagogie, jako že pro sčítání čísel potřebujete nutně opustit objektové paradigma - jinak skončí vesmír a galaxie se hroutí do černé díry.

44
Vývoj / Re:čisté OP smalltalk, objective C
« kdy: 05. 09. 2018, 19:57:02 »
Citace
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.

Na mysli jste to mít mohl, nicméně je to irelevantní.

To, jestli programovací jazyk obsluhuje objekty ve svém implementaci zasíláním zpráv nebo voláním metod - je něco, co je rozhodnutí autora jazyka, nikoli programátora. Je to tedy vnitřní vlastnost jazyka. A o tom se tu bavíme.

Jazyk, který obsluhuje objekty zasíláním zpráv má jednu vstupní metodu do objektu - což platí někde uvnitř implementace. To, že navenek ve zdrojovém kódu PHP i Smalltalk nabízejí psaní metod je jen emulace navenek.

45
Vývoj / Re:čisté OP smalltalk, objective C
« kdy: 05. 09. 2018, 19:53:03 »
Citace
Pozor, neplatí to absolutně - viz CLOS. Rozhodně doporučuji pro rozšíření obzorů, protože ukazuje že to jde dělat i zcela jinak (Smalltalk jen ukazuje že to jde dělat elegantně).

Jistě, ve funkcionálním jazyku jde obejít omezení objektového jazyka. Překvapuje to někoho?

Schválně, kolik lidí, pokud si bude moci vybrat, bude raději programovat ve Smalltalku než v LISPu? Já se obávám, že LISP by dopadl dost špatně.

Stejně tak zdrojový kód Smalltlaku bude srozumitelnější a udržovatelnější než v LISPu.

***

Celá ta sranda je v tom, že objektové jazyky to nějak šmudlají - ale programování v nich, stejně jako čitelnost a udržovatelnost je o moc tříd výše než ve funkcionálních jazycích.

Snaha vytvořit dobrý funkcionální jazyk a vylepšít ho - nad běžnou míru LISPu - vede přečasto jen k tomu, že k jeho zvládnutí potřebujete doktorát z matematiky a jaderné fyziky. Tedy nic, v čem by běžný smrtelník chtěl programovat.

Stran: 1 2 [3] 4 5 ... 8