Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Lojza 22. 12. 2018, 21:53:41
-
tak nejak jsem prochazel bezne programovaaci jazyky a je to proste brainfuck
ma to nejake sve fundamentalni duvody nebo proc nejde udelat syntaxi "jednoduchou"tj. prirozenou lidskemu mysleni (psani) ?
treba smalltalk, ms small basic ale i python to maji aspon trochu normalni
chapu ze jazyk musi mit nejake vyrazove prostredky pro pouziti svych nastroju ale stejne ...
-
Pokud tě zaráží syntaxe, tak počkej na to, až se potkáš se sémantikou ;-),
-
co konkretne ti vadi na syntaxi?
ja jsem spise uvazoval zavest [], (), {} do psaneho jazyka, akorat jeste nevim jak by se to vyslovovalo.
veta: vcera jsem se svou manzelkou obedval svickovou s knedlikem.
{[ja+manzelka <moje>] (obedvat) [svickova + knedlik] <vcera>}
pro zajemce, kteri chteji naprosto pravidelny (lidsky mluvici) jazyk, ktery je vytvoren pro to, aby sel pocitacove parsovat i zpracovat: lojban
-
proste ta kombinace vsech moznych zavorek, slozenych zavorek, hranatych zavorek, odsazeni, stredniku, dvojtecek, rovna se, dvojite rovna, plusek, dvojitych plusek, minusek, tecek, ˜, ', ", @ # $ % & * ? atd .. mi prijde ze by to snad mohlo jit zjednodusit aby se to lip pamatovalo ?
treba by stacilo rozsirit seznam vyhrazenych slov nejlepe odpovidajicich beznemu lidskemu mysleni (v anglictine)
-
co konkretne ti vadi na syntaxi?
ja jsem spise uvazoval zavest [], (), {} do psaneho jazyka, akorat jeste nevim jak by se to vyslovovalo.
veta: vcera jsem se svou manzelkou obedval svickovou s knedlikem.
{[ja+manzelka <moje>] (obedvat) [svickova + knedlik] <vcera>}
pro zajemce, kteri chteji naprosto pravidelny (lidsky mluvici) jazyk, ktery je vytvoren pro to, aby sel pocitacove parsovat i zpracovat: lojban
Někteří spíše přemýšlejí o opačném postupu...
http://users.monash.edu/~damian/papers/HTML/Perligata.html
-
Syntaxe přirozených jazyků je výrazně složitější než syntaxe programovacích jazyků.
-
jeste jsem zapomnel na !, /, \, -, --, ++, _, __ atd ... kdo si to ma pamatovat kdy jak se ktery znak pouziva k obvyklemu vyjadreni instrukci ktere vice mene pouziva kazdy programovaci jazyk ... je to furt dokola prirazeni promenne, cykly, podminky, pole, datove typy, OOP atd ...
-
jeste jsem zapomnel na !, /, \, -, --, ++, _, __ atd ... kdo si to ma pamatovat kdy jak se ktery znak pouziva k obvyklemu vyjadreni instrukci ktere vice mene pouziva kazdy programovaci jazyk ... je to furt dokola prirazeni promenne, cykly, podminky, pole, datove typy, OOP atd ...
Vím, že trollové se nekrmí, ale je pro případ že jsi opravdu hloupý tak dodám, že prostě na programování musíš mít mozeček. když ho nemáš tak smůla.
-
Zřejmě se ti stýská po Cobolu, ale i Pascal používá více klíčových slov namísto symbolů. Méně znaků by však mělo znamenat snadnější čtení, viz vývoj matematického zápisu, ve kterém se používá různých řezů písma, řecké znaky, indexy apod. Při programování však nelze využívat typografii v takové míře - zpravidla jsme omezeni na ASCII. Schopnější editory umí barvit podle syntaxe, ale to je asi tak vše. Současný stav je dílem kompromisu, z mého pohledu je nejkomplikovanější asi zápis v C++.
Smalltalk má sice jednoduchý zápis, ale jen do doby, než si začneš definovat vlastní třídy, ve kterých je těch symbolů také docela dost. Basic bych raději nevzpomínal, ale s tím Pythonem docela souhlasím.
Ohledně jednoduchého a přehledného zápisu se mi líbí Lisp. I těch závorek je v něm méně než třeba v Javě, ale je univerzální a lépe navržený.
-
Doporucuju lisp. ten v podstate syntaxi nema. Staci vedet jak udelat list.
-
treba by stacilo rozsirit seznam vyhrazenych slov nejlepe odpovidajicich beznemu lidskemu mysleni (v anglictine)
Říká ti něco COBOL? ;D
V některých jazycích je begin a end, v jiných složené závorky. Jsou to prostě zkratky pro rychlejší psaní, něco jako těsnopis.
-
Vím, že trollové se nekrmí, ale je pro případ že jsi opravdu hloupý tak dodám, že prostě na programování musíš mít mozeček. když ho nemáš tak smůla.
Proč mozeček? Ten se přece stará o pohybový aparát a do programování nekecá.
Některé programovací jazyky se čtou snáze a jiné hůře. Například C++ se mi čte docela blbě. Na PHP mnohým programátorům vadí "$" nebo "$this->". Na Lispu zase závorky. Zatím nemáme programovací jazyk, který by vyhovoval všem.
-
tak nejak jsem prochazel bezne programovaaci jazyky a je to proste brainfuck
Brainfuck mi nepřijde jako běžný programovací jazyk. (https://en.wikipedia.org/wiki/Brainfuck)
-
V některých jazycích je begin a end, v jiných složené závorky. Jsou to prostě zkratky pro rychlejší psaní, něco jako těsnopis.
Rychlejší psaní není až tak podstatné - mnohem důležitější je rychlejší čtení. Na přechod od begin a end ke složeným závorkám jsem si těžko zvykal, ale teď mi už vyhovují. Python je odstranil úplně a také jsme spokojení.
-
treba by stacilo rozsirit seznam vyhrazenych slov nejlepe odpovidajicich beznemu lidskemu mysleni (v anglictine)
To tu uz vzniklo pred skoro 60 rokmi, stale to pouzivame a vola sa to COBOL (https://cs.wikipedia.org/wiki/COBOL). Je to genialny programovaci jazyk, doporucujem sa ho naucit :)
-
Pokud tě zaráží syntaxe, tak počkej na to, až se potkáš se sémantikou ;-),
+100 :)
(zvlast pokud tim nemyslime neformalni "co to dela", ale formalni "semantiku programovacich jazyku" - to je teprve brainfuck :) )
mi prijde ze by to snad mohlo jit zjednodusit aby se to lip pamatovalo ?
treba by stacilo rozsirit seznam vyhrazenych slov nejlepe odpovidajicich beznemu lidskemu mysleni (v anglictine)
To je nahodou moc hezky tema. Minimalne proto, ze kdyz ty jazyky a zpusob jejich konstrukce zacne clovek reflektovat, dozvi se spoustu zajimavych veci nejenom o nich, ale i o sobe ;)
Hele, umel bys vymyslet ciste hypoteticky priklad, jak by takovy jazyk mel zhruba vypadat? Vylozene vyfabulovat kus kodu? Ale z nejake realne domeny - treba zkus ukazat, jak by mohl vypadat treba takovy autentizacni handler pro http request (tj. v normalnim jazyce funkce, ktera se zavola, kdyz prijde http request, zkontroluje nejake autentizacni udaje a povoli nebo zamitne dalsi zpracovani).
-
Pane, videli uz kod v Perl ? 8)
-
jeste jsem zapomnel na !, /, \, -, --, ++, _, __ atd ... kdo si to ma pamatovat kdy jak se ktery znak pouziva k obvyklemu vyjadreni instrukci ktere vice mene pouziva kazdy programovaci jazyk
Protože pamatovat si (a psát!), že ++ je inc (nebo incr? nebo increment?), / je float_division (nebo real_division?), \ je escape atd. je ještě horší?
Srsly, zrovna tohle jsou věci, které při potkání nového programovacího jazyku typicky řeším tak prvních pět minut…
-
COBOL, to bol! Terazky som javistou!
-
proste ta kombinace vsech moznych zavorek, slozenych zavorek, hranatych zavorek, odsazeni, stredniku, dvojtecek, rovna se, dvojite rovna, plusek, dvojitych plusek, minusek, tecek, ˜, ', ", @ # $ % & * ? atd .. mi prijde ze by to snad mohlo jit zjednodusit aby se to lip pamatovalo ?
Syntaxe většiny smysluplných jazyků je podle mě dosti minimalistiská. Jednoduše se pamatuje, kontroluje a překládá do strojově stravitelné podoby.
treba by stacilo rozsirit seznam vyhrazenych slov nejlepe odpovidajicich beznemu lidskemu mysleni (v anglictine)
Napadá mě hned několik důvodů, proč by to nejspíš dopadlo úplně jinak, než si myslíš. Lidský mozek je schopný chápat instrukce na výrazně vyšší úrovni než stroj. Dokud nedojde k výraznému posunu v této oblasti, Star-Trekoidí programovací jazyk operující ve stylu "Počítači, zobraz předpokládaný stav asteroidového pole 39 sekund po explozi fotonového torpéda" jen tak nepůjde. Pouhé nahrazení symbolických operátorů slovy mnoho nepomůže, něco jako:
moje_pole = nové pole celých čísel o velikosti 65
proveď pro x v rozsahu 0 až velikost(moje_pole) - 1:
nastav prvek x z moje_pole na (x + 1) * 2
mi fakt nepřijde čitelnější než toto
auto vec = std::vector<int>(65);
for (int idx = 0; idx < vec.size(); idx++)
vec[idx] = (idx + 1) * 2;
Čím více klíčových slov bude jazyk používat, tím méně jich zbyde programátorovi a pojmenovávání vlastních objektů. Největší problém začínajících programátorů je naučit se přemýšlet jako stroj a s tím sebelidštější syntaxe nepomůže.
-
Pokud tě zaráží syntaxe, tak počkej na to, až se potkáš se sémantikou ;-),
+100 :)
(zvlast pokud tim nemyslime neformalni "co to dela", ale formalni "semantiku programovacich jazyku" - to je teprve brainfuck :) )
mi prijde ze by to snad mohlo jit zjednodusit aby se to lip pamatovalo ?
treba by stacilo rozsirit seznam vyhrazenych slov nejlepe odpovidajicich beznemu lidskemu mysleni (v anglictine)
Hele, umel bys vymyslet ciste hypoteticky priklad, jak by takovy jazyk mel zhruba vypadat? Vylozene vyfabulovat kus kodu? Ale z nejake realne domeny - treba zkus ukazat, jak by mohl vypadat treba takovy autentizacni handler pro http request (tj. v normalnim jazyce funkce, ktera se zavola, kdyz prijde http request, zkontroluje nejake autentizacni udaje a povoli nebo zamitne dalsi zpracovani).
mne se treba libi co pise Neviditelny nizeji
moje_pole = nové pole celých čísel o velikosti 65
proveď pro x v rozsahu 0 až velikost(moje_pole) - 1:
nastav prvek x z moje_pole na (x + 1) * 2
akorat bych to nechal v anglictine a ta vyhrazena slova by byla nejspis zkracena
je to jen takovy povzdech proletl jsem par jazyku ale asi to jinak nejde, to srovnani s formalnim zapisem v matematice ma neco do sebe, i kdyz tam tech znaku se nepouziva na jednom miste tolik
-
Syntaxe většiny smysluplných jazyků je podle mě dosti minimalistiská. Jednoduše se pamatuje, kontroluje a překládá do strojově stravitelné podoby.
Tohle je podle me dulezite, drive programatori znali i streva a assembler, byli bliz stroji a nestezovali si na syntaxi.
Dneska chce programovat leckdo i ten kdo ma problem se syntaxi.
-
moje_pole = nové pole celých čísel o velikosti 65
proveď pro x v rozsahu 0 až velikost(moje_pole) - 1:
nastav prvek x z moje_pole na (x + 1) * 2
akorat bych to nechal v anglictine a ta vyhrazena slova by byla nejspis zkracena
COBOL: https://www.root.cz/clanky/programovani-mainframu-cobol/ (https://www.root.cz/clanky/programovani-mainframu-cobol/)
DATA DIVISION.
WORKING-STORAGE SECTION.
01 Num1 PIC 9 VALUE ZEROS.
01 Num2 PIC 9 VALUE ZEROS.
01 Result PIC 99 VALUE ZEROS.
PROCEDURE DIVISION.
DISPLAY "Enter first number (1 digit) : " WITH NO ADVANCING.
ACCEPT Num1.
DISPLAY "Enter second number (1 digit) : " WITH NO ADVANCING.
ACCEPT Num2.
MULTIPLY Num1 BY Num2 GIVING Result.
DISPLAY "Result is = ", Result.
A když ta vyhrazená slova začneš zkracovat, dojdeš nakonec ke zkratkovité syntaxi dnešních programovacích jazyků ;)
-
Jedna stará programátorská pravda hovorí, že ak umožníš programátorom programovať v slovenčine (češtine, angličtine, ...), zistíš, že nevedia po slovensky (česky, anglicky, ...).
-
akorat bych to nechal v anglictine a ta vyhrazena slova by byla nejspis zkracena
Zkracování slov rozhodně nevede k čitelnějšímu kódu. Co třeba SQL, vyhovuje?
-
Ja tedy mel na diplomku praci "Semanticke programovani", kde jsem resil ze syntaxe programovacich jazyku je vlastne zcela zbytecna, protoze programy se skladaji z tech samych zakladnich bloku, jako univerzalni transport jsem mel XML, resp. svoji xml databazi, jez mela alternativni automaticky generovane roviny podle vystupniho jazyka (C, PHP, JS a Pascal). Bylo to omezeno z casovych/praktickych duvodu na funkcionalni programovani.
K praktickemu uzitku ve styku s lidma tomu jen chybi interface do hlavy, at se ty myslenky ctou rovnou do xml, kdyz jse nekdo linej se vyjadrit v nektere z bezne uzivanych syntaxi (aka programovacich jazyku) :)
-
moje_pole = nové pole celých čísel o velikosti 65
proveď pro x v rozsahu 0 až velikost(moje_pole) - 1:
nastav prvek x z moje_pole na (x + 1) * 2
akorat bych to nechal v anglictine a ta vyhrazena slova by byla nejspis zkracena
Rozhodne je lepsie naucit sa skratene vyrazy. V takejto podobe (aj v anglictine) je to zle citatelne a zdlhavejsie na pisanie.
A kamo logicke chyby su daleko horsie ako syntakticke, navyse mozu byt dobre skryte a prejavia sa az v ostrej prevadzke po nejakom case. Jeden prepocet co som robil prestal fungovat po 1,5 roku pouzivania. Spoliehal sa totiz na jednu vec, ktora v drvivej vacsine pripadov bola splnena, ale vtedy nie.
-
sql syntaxe vypada jednoduseji, ale ta slozitost je skryta za tou syntaxi ? (semantika ?), navic sql byl neradil k plnotucnym programovacim jazykum, dela jen cast - prace s databazemi ?
ale treba ten small basic
http://download.microsoft.com/download/9/0/6/90616372-C4BF-4628-BC82-BD709635220D/Introducing%20Small%20Basic.pdf
vim je to osekana verze basicu ale stejne pripada mi ze nekdo se snazil tu syntaxi zjednodusit
to same mi pripada u smalltalku
LISP si nejsem jistej jestli bych se neuzavorkoval (musel bych mit neco co mi bude hlidat spravny pocet ()
-
mne se treba libi co pise Neviditelny nizeji
moje_pole = nové pole celých čísel o velikosti 65
proveď pro x v rozsahu 0 až velikost(moje_pole) - 1:
nastav prvek x z moje_pole na (x + 1) * 2
Mno myslím, že to začíná být podobně vágní jako běžný jazyk. Jaké celé číslo? Jaký má mít rozsah nebo kolik bitů? Jak tam přibudou tyhle věci, tak to bude chtít typedef na nějaké lepší jméno ( třeba int32 :) ) jinak se důležitá informace ztratí v hromadě textu.
A myslím že si dokážu představit první zpětnou vazbu. "Nešlo by to přistupování k prvkům pole nějak zkrátit? Tohle děláme furt dokola a psát to je strašný opruz. Co třeba hranaté závorky, když to takhle dělá kdekdo? To přece pochopí každý." :D
akorat bych to nechal v anglictine a ta vyhrazena slova by byla nejspis zkracena
Takže to špatné z obou světů. Univerzálně používaných zkratek až tolik není. Takže se v tom bez učení nováček stejně nevyzná. Akorát budou ty zkratky splývat se jmény proměnných a metod.
je to jen takovy povzdech proletl jsem par jazyku ale asi to jinak nejde, to srovnani s formalnim zapisem v matematice ma neco do sebe, i kdyz tam tech znaku se nepouziva na jednom miste tolik
Tak samo, všichni si chceme ušetřit práci. Akorát to občas není až tak jednoduché. :)
-
Nevím jak vy, ale syntaxe jazyka mi nedělá zas az takový problém, vždycky se dá vytisknout cheatsheet, ale kde se bezpečné ztracim je chaos v rozlišení vlastních funkci, proměnných, tříd a procedur. A to zejména když luštim cizí kód...
-
ja myslim ze nad touto otazkou se zamyslely a zamysleji mnohem vetsi mozky nez ja, a vysledek je jaky je takze to nejspis lepe nejde, takze OK presvedcili jste mne ze ten brainfuck musim dat (aspon v tom pythonu kterymu bych se chtel venovat)
-
LISP si nejsem jistej jestli bych se neuzavorkoval (musel bych mit neco co mi bude hlidat spravny pocet ()
Paredit. O zavorkach skoro nevim.
-
Jestli se ti zdá syntaxe programovacích jazyků složitá, nikdo ti nebrání používat jen nuly a jedničky. Pak si stačí pamatovat jen dva znaky: 0 a 1. Až zlvádneš napsat něco jen v 0 a 1, pak ti bude připadat syntaxe každého programovacího jazyka jako zázračně jednoduchá a zapamatovatelná.
-
sql syntaxe vypada jednoduseji, ale ta slozitost je skryta za tou syntaxi ? (semantika ?), navic sql byl neradil k plnotucnym programovacim jazykum, dela jen cast - prace s databazemi ?
Složitost tam bude vždycky, pokud se řeší nejaký netriviální problém. Buď může být schovaná za nějakýma mocnýma konstrukcema jazyka nebo může být rozplizlá na spoustě stránek zdánlivě jednoduchého kódu. V jednom případě bude náročné se naučit ty mocné konstrukce, v druhém případě bude náročné pročíst a pochopit ty stránky a stránky kódu.
ale treba ten small basic
http://download.microsoft.com/download/9/0/6/90616372-C4BF-4628-BC82-BD709635220D/Introducing%20Small%20Basic.pdf
vim je to osekana verze basicu ale stejne pripada mi ze nekdo se snazil tu syntaxi zjednodusit
Nemůžu si pomoct ale ten smallbasic mi příjde jako ukázkový protiklad tvého textového kódu. Jsou tam všechny běžné obraty (for, [], =), které jsi nahradil textem. Ani mi nepřijde, že se tam záměrně snažil někdo něco zjednodušovat. Podobnou syntaxi má hromada jazyků (třeba Pascal nebo Lua). Narvali tam osvědčené prvky a tím to zhaslo.
to same mi pripada u smalltalku
Smalltalk mi přijde jako příklad jazyka, který je pod jednoduchou fasádou hodně složitý. Pokud na to nekoukáš jako na kouzelnou skříňku tak se po odealání zprávy děje docela dost věcí, než se nakonec najde kód k vykonání. A že ta složitost není vidět může být dvojsečné.
-
[/size]
Nemůžu si pomoct ale ten smallbasic mi příjde jako ukázkový protiklad tvého textového kódu. Jsou tam všechny běžné obraty (for, [], =), které jsi nahradil textem. Ani mi nepřijde, že se tam záměrně snažil někdo něco zjednodušovat. Podobnou syntaxi má hromada jazyků (třeba Pascal nebo Lua). Narvali tam osvědčené prvky a tím to zhaslo.
ja jsem si proste procetl ten 80 strankovy manual small basicu a furt jsem se nejak chytal a byl v obraze (zrejme tam chybeji ty slozitejsi "vetne stavby", resp. pouzivaji se jiz zabudovane funkce do jazyka resp. standardni knihovny - to by mi vyhovovalo
coz se treba u Cecka, php, javascriptu ... se mi nikdy nepovedlo okamzite jsem se po par strankacj ztratil v syntaxi, jedine co mi doslo ze kazdy ? opravdovy programovaci jazyk v podstate se sklada z velmi podobnych stavenich bloku (promenne, cykly, podminky, oop..) akorat kazdy jazyk se k nim stavi ruzne, nektery z meho pohledu jednoduseji a jiny sloziteji (syntaxe)
-
Ja tedy mel na diplomku praci "Semanticke programovani", kde jsem resil ze syntaxe programovacich jazyku je vlastne zcela zbytecna, protoze programy se skladaji z tech samych zakladnich bloku, jako univerzalni transport jsem mel XML, resp. svoji xml databazi, jez mela alternativni automaticky generovane roviny podle vystupniho jazyka (C, PHP, JS a Pascal). Bylo to omezeno z casovych/praktickych duvodu na funkcionalni programovani.
Ten popis univerzálního transportu v XML mě zajímá. Dá se to někde najít?
-
sql syntaxe vypada jednoduseji, ale ta slozitost je skryta za tou syntaxi ? (semantika ?), navic sql byl neradil k plnotucnym programovacim jazykum, dela jen cast - prace s databazemi ?
Když se podíváš na PL/SQL, tak ten už je plnotučným programovacím jazykem. Navíc má hodně vlastností z těch, které vyžaduješ a dá se použít i bez databáze.
LISP si nejsem jistej jestli bych se neuzavorkoval (musel bych mit neco co mi bude hlidat spravny pocet ()
Program v Lispu nemá víc závorek než v ostatních jazycích. To jen zbývajícího kódu je podstatně méně a proto jsou ty závorky víc vidět.
-
Nevím jak vy, ale syntaxe jazyka mi nedělá zas az takový problém, vždycky se dá vytisknout cheatsheet, ale kde se bezpečné ztracim je chaos v rozlišení vlastních funkci, proměnných, tříd a procedur. A to zejména když luštim cizí kód...
V tom by mělo významně pomáhat barvení syntaxe, kterým dnes už běžné editory disponují. V Notepadu se už moc neprogramuje.
-
Jedna stará programátorská pravda hovorí, že ak umožníš programátorom programovať v slovenčine (češtine, angličtine, ...), zistíš, že nevedia po slovensky (česky, anglicky, ...).
Programovat slovensky ... fakt dobrej vtip.
-
Vím, že trollové se nekrmí, ale je pro případ že jsi opravdu hloupý tak dodám, že prostě na programování musíš mít mozeček. když ho nemáš tak smůla.
Proč mozeček? Ten se přece stará o pohybový aparát a do programování nekecá. ...
Je pravda, ze vetsina mistnich php opic opravdu mozek k mysleni nepouziva ...
-
jedine co mi doslo ze kazdy ? opravdovy programovaci jazyk v podstate se sklada z velmi podobnych stavenich bloku (promenne, cykly, podminky, oop..) akorat kazdy jazyk se k nim stavi ruzne, nektery z meho pohledu jednoduseji a jiny sloziteji (syntaxe)
Každý programovací jazyk tyto stavební bloky používat nemusí. Například v XSLT se obejdeš bez proměnných, cyklů a podmínek, i když v jeho syntaxi jsou.
-
nejhorsi je ze mi prijde slozite i "programovani" ve VBA for Applications pro Excel ... ale to se jeste budu pokouset zvladnout casem
-
Pravda je, co píše RDa výš. Ten textový zápis programu je takový "sjednotitel" několika činností a u žádné z nich se s ním nepracuje úplně ideálně.
Při vzniku programu je postup: myšlenka -> bloky kódu v hlavě -> text programu -> AST -> stroják
V tomhle procesu je tam ten text z pohledu stroje vyloženě přebytečná věc vyžadující zbytečně složitý parser (výjímkou je Lisp, který ho vyrušil ;) )
Ještě horší je to v případě verzování kódu, které by principielně mělo pracovat na úrovni bloků kódu, ale nemá je k dispozici, takže uměle a nešikovně pracuje na úrovni řádků a lokálního kontextu. Vzniká tak vlastně krkolomné
Programátor: myšlenka -> bloky kódu v hlavě -> text programu
CVS: text programu -> [jakýsi kostrbatý proces bez znalosti významu a za použití úplně jiných struktur než bloků kódu] -> [občas naprosto nepřehledné a nečitelné] změny textu programu
Programátor: změny textu programu -> změny bloků kódu -> změny myšlenky
Tohle je vyloženě suboptimální proces, který by třeba na úrovni AST mohl být daleko přímočařejší.
(tohle bylo jenom tak pro ilustraci, podobně suboptimální je i generování stubů IDEčkem)
Takže vlastně jediný, o co v celé věci jde, je mít něco, z čeho se dá strojově generovat AST a zároveň se s tím bude dobře pracovat programátorovi. A to nutně ani nemusí být text. Může to být klidně nějaká vizuální reprezentace. Třeba takové ty pomůcky pro děcka typu Blockly vlastně slouží k manipulaci s vizuální reprezentací AST, takže převod do textu by tam vůbec nemusel být.
Problém ale je, že vizuální reprezentace je sice super pro začátečníka/dítě, ale ne-začátečníkovi práci spíš zpomaluje. IMHO to ale hodně záleží na paradigmatu. Některá paradigmata jsou natolik spojená se strukturami (typicky grafy), že tam začíná být vizuální reprezentace celkem efektivní, alespoň na nejvyšší úrovni.
Například paradigma "streamové zpracování dat pomocí grafu výpočetních uzlů" si o to vyloženě říká - tam je text výrazně nepřehlednější než vizuální reprezentace. Skvělým příkladem je NodeRed (https://youtu.be/f5o4tIz2Zzc?t=148) Podobně zajímavé by to mohlo být i v některých případech event-driven programování.
Každopádně ale nevím o žádném kompletním ekosystému (editor, VCS, překladač, debugger,...), který by byl pro tenhle způsob fungování vyloženě navržený od začátku, takže by tam všechno do sebe perfektně zapadalo. Systémy, o kterých vím, vždycky řeší jenom jednu část a ten "společný sjednotitel" je vždycky text (který se třeba generuje z té vizuální reprezentace) a třeba to vizuální VCS jsem ještě neviděl. Možná nejblíž jsou tomu věci typu Squeak.
Tady by možná nějaký prostor pro výzkum byl. Bylo by to strašně moc práce s nejistým výsledkem a muselo by se to udělat extrémně promyšleně, aby z toho nevznikl paskvil typu VisualBasic, ale tak už to u vymýšlení hodně inovativních věcí bývá :)
-
Každý programovací jazyk tyto stavební bloky používat nemusí. Například v XSLT se obejdeš bez proměnných, cyklů a podmínek, i když v jeho syntaxi jsou.
jestli jsem to dobre pochopil https://cs.wikipedia.org/wiki/Extensible_Stylesheet_Language_Transformations
tak v xslt se nepise primo zdrojovy kod ale pouze transformace na jiny kod ? da se zjednodusene rici ze html, xml, xslt apod. jsou proste rodina "znackovacich jazyku" ?
-
nejhorsi je ze mi prijde slozite i "programovani" ve VBA for Applications pro Excel ... ale to se jeste budu pokouset zvladnout casem
Skripty pro Excel jsem dělával tak, že jsem zapnul režim učení, provedl požadované operace a nakonec jsem ten stub upravil do finální podoby. Nemusel jsem tedy psát tu syntaktickou omáčku a šlo to vcelku rychle.
-
Každý programovací jazyk tyto stavební bloky používat nemusí. Například v XSLT se obejdeš bez proměnných, cyklů a podmínek, i když v jeho syntaxi jsou.
jestli jsem to dobre pochopil https://cs.wikipedia.org/wiki/Extensible_Stylesheet_Language_Transformations
tak v xslt se nepise primo zdrojovy kod ale pouze transformace na jiny kod ? da se zjednodusene rici ze html, xml, xslt apod. jsou proste rodina "znackovacich jazyku" ?
XSLT je zdrojovým kódem. Vstupní data jsou v XML. Výstupní data už mohou být v jakémkoli formátu - XML, HTML, TXT, CSV, CSS, Javascript, Lisp, SQL, XSL-FO,...
-
jeste jsem zapomnel na !, /, \, -, --, ++, _, __ atd ... kdo si to ma pamatovat kdy jak se ktery znak pouziva k obvyklemu vyjadreni instrukci ktere vice mene pouziva kazdy programovaci jazyk ... je to furt dokola prirazeni promenne, cykly, podminky, pole, datove typy, OOP atd ...
Odpovědí byl kdysi COBOL - taky si mysleli, že to dají jen s angličtinou, ale bylo z toho peklo.
-
coz se treba u Cecka, php, javascriptu ... se mi nikdy nepovedlo okamzite jsem se po par strankacj ztratil v syntaxi, jedine co mi doslo ze kazdy ? opravdovy programovaci jazyk v podstate se sklada z velmi podobnych stavenich bloku (promenne, cykly, podminky, oop..) akorat kazdy jazyk se k nim stavi ruzne, nektery z meho pohledu jednoduseji a jiny sloziteji (syntaxe)
Tady je těžké hádat. Cčko má své hodně těžké věci ale ty se neobevují na prvních stránkách. V začátcích je ta syntaxe Cčkoidních jazyků těm pascaloidním hodně podobná. Možná je trochu víc hustá, takže se pomaleji čte.
Jinak manuály nejsou obecně dobré pro začátečníky. Nejsou strukturované tak, aby se podle nich dalo učit. Ten tvůj odkaz na smallbasic byl spíš učebnice, než manuál. I když k učebnici, která na začátečníka vytáhne goto ještě před cykly, mám své výhrady. :)
nejhorsi je ze mi prijde slozite i "programovani" ve VBA for Applications pro Excel ... ale to se jeste budu pokouset zvladnout casem
Mám trochu dojem, že jsi ve fázi kdy ti dělá problém přejít od popisu problému v neformální "lidštině" do něčeho, co už připomíná algoritmus. Tahle fáze je těžká a navíc je dost nezávislá na jazyce. A jazyk, který ti nesedí, jen přidává další věci, na které musíš myslet. Ono se to poddá. Jen počítej s tím, že to chce čas a trénink. Přece jenom se snažíš přemýšlet hodně neintuitivním a nepřirozeným způsobem.
-
Ja tedy mel na diplomku praci "Semanticke programovani", kde jsem resil ze syntaxe programovacich jazyku je vlastne zcela zbytecna, protoze programy se skladaji z tech samych zakladnich bloku, jako univerzalni transport jsem mel XML, resp. svoji xml databazi, jez mela alternativni automaticky generovane roviny podle vystupniho jazyka (C, PHP, JS a Pascal). Bylo to omezeno z casovych/praktickych duvodu na funkcionalni programovani.
Ten popis univerzálního transportu v XML mě zajímá. Dá se to někde najít?
Muzu ti poslat mailem, kdyz se ozves skrze tu obalku vlevo (PM). Ale necekej od toho nic primo pouzitelneho, jak na to koukam nektere konstrukce me prijdou ted hodne naivni :) V podstate to vzniklo v dobe kdy me bavili prekladace a ta forma programu ktera vznikne po rozparsovani zdrojaku.
-
Mám trochu dojem, že jsi ve fázi kdy ti dělá problém přejít od popisu problému v neformální "lidštině" do něčeho, co už připomíná algoritmus. Tahle fáze je těžká a navíc je dost nezávislá na jazyce. A jazyk, který ti nesedí, jen přidává další věci, na které musíš myslet. Ono se to poddá. Jen počítej s tím, že to chce čas a trénink. Přece jenom se snažíš přemýšlet hodně neintuitivním a nepřirozeným způsobem.
mne prave stve ze se pri psani nemuzu soustredit na podstatu daneho stavebniho kamene (treba budovani zanorenych cyklu) ale moji pozornost odvadi to, abych to napsal syntakticky spravne
-
Mám trochu dojem, že jsi ve fázi kdy ti dělá problém přejít od popisu problému v neformální "lidštině" do něčeho, co už připomíná algoritmus. Tahle fáze je těžká a navíc je dost nezávislá na jazyce. A jazyk, který ti nesedí, jen přidává další věci, na které musíš myslet. Ono se to poddá. Jen počítej s tím, že to chce čas a trénink. Přece jenom se snažíš přemýšlet hodně neintuitivním a nepřirozeným způsobem.
mne prave stve ze se pri psani nemuzu soustredit na podstatu daneho stavebniho kamene (treba budovani zanorenych cyklu) ale moji pozornost odvadi to, abych to napsal syntakticky spravne
A proc si nevypomuzes preprocesorem? Typicky priklad je #define FORC3, FORC4 v kodu dcraw.c (zpracovani raw souboru z fotoaparatu), jez provedou cyklus na barevnyma kanalama.
Stejne tak muzes nahradit neprehledne kusy kodu jejich zkracenou variantou kvuli prehlednosti algoritmu - at uz na urovni vyrazu nebo celych bloku.
-
A proc si nevypomuzes preprocesorem? Typicky priklad je #define FORC3, FORC4 v kodu dcraw.c (zpracovani raw souboru z fotoaparatu), jez provedou cyklus na barevnyma kanalama.
Stejne tak muzes nahradit neprehledne kusy kodu jejich zkracenou variantou kvuli prehlednosti algoritmu - at uz na urovni vyrazu nebo celych bloku.
to je na mne momentalne asi moc slozity, jsem momentalne rad ze to nejak splacam dohromady, zatim stejne vetsinou delam jen priklady a cviceni z ruznych ebooku
navic tomu moc nerozumim co myslis tim preprocesorem
https://cs.wikipedia.org/wiki/Preprocesor
jinak zjednoduseni bloku kodu je samozrejme hezke, ale ja jsem rad ze vubec neco dam dohromady (python)
-
mne prave stve ze se pri psani nemuzu soustredit na podstatu daneho stavebniho kamene (treba budovani zanorenych cyklu) ale moji pozornost odvadi to, abych to napsal syntakticky spravne
Zanořeným cyklům se snažím vyhýbat, většinou úspěšně. Syntaktickou správnost by v dnešní době měl řešit editor. Program píši pořád stejně, ale editor mi to pod rukama mění na zápis podle typu souboru, který právě edituji.
-
no tak to budu muset vymenit IDLE (python) za neco lepsiho co by mi hlidalo a opravovalo syntaxi abych se mohl soustredit na podstatu problemu
-
A proc si nevypomuzes preprocesorem?
to je na mne momentalne asi moc slozity, jsem momentalne rad ze to nejak splacam dohromady, zatim stejne vetsinou delam jen priklady a cviceni z ruznych ebooku. navic tomu moc nerozumim co myslis tim preprocesorem
https://cs.wikipedia.org/wiki/Preprocesor
jinak zjednoduseni bloku kodu je samozrejme hezke, ale ja jsem rad ze vubec neco dam dohromady (python)
Můžeš zkusit stránku https://linux.die.net/man/1/cpp (https://linux.die.net/man/1/cpp) nebo https://linux.die.net/man/1/m4 (https://linux.die.net/man/1/m4), ale je jich více druhů. Pro Python bych však asi nic nehledal, neboť ten už je dostatečně hutný a preprocesor by mohl být jen zbytečnou komplikací. Raději bych místo toho napsal metodu, funkci nebo dekorátor.
-
no tak to budu muset vymenit IDLE (python) za neco lepsiho co by mi hlidalo a opravovalo syntaxi abych se mohl soustredit na podstatu problemu
IDLE jsem zkoušel. Jako kalkulačka na různé ad-hoc výpočty je skvělým nástrojem, ale pro vývoj aplikace bych ho nepoužil.
-
Stejne jako se preslo od xml k jsonu potazmo yamlu stejne tak i syntaxe jazyku se zmenila/vyvinula. Muj favorit je v tomhle ruby a rozhodne doporucuju precist si zaklady jejich filozofie, casti toho jsem napriklad vyuzil napr. v Ansiblu a pracuje se mi s tim velmi dobre (https://rubyonrails.org/doctrine/). Ty zakladni filozoficke pristupy lze implementovat vsude (napr. Laravel stavi hodne na RoR).
Ruby ma i "lidstejsi moznosti zapisu", napr.:
puts "Greater than 5" if i > 5
Co je dulezitejsi, ze "na to domaci bastleni" moc premyslet nemusite, ale ve chvili, kdy chcete mit neco udrzitelneho tak musite mit dost rozdilny pristup nez "one man show a one liner", jinak skoncite jak "wordpress".
Muzu ti Lojzo namitat, ze napriklad prikaz: "cd" by ve skutecnosti mel by "chd" ale aby sis to nemusel pamatovat, nejlepsi by ti asi bylo "change_directory". Premejslim, jak by se dalo v matematice zbavit zavorek, jsou otravne a kdo si to ma pamatovat :)
Je treba si uvedomit, ze vyssi programovaci jazyky jsou abstraktni, aby se nam mozecky nezavarili, protoze psat rovnou v ASM by bylo "nelidske" :) Predstavte si, ze byste delal treba revizi bytecode :D
Jeden z vydobytku programovacich jazyku je napriklad "teckova notace": Objekt.funkce nebo Objekt.funkce()
v php to nahradili Objekt->funkce(); hmmmm dobre. Zapis namespace v PHP je taky pekne obskurni a osklivy, dve lomitka? Vazne?
Pripustme ze kazdy programovaci jazyk se hodi na neco jineho, takze pokud chcete programovat ovladac na hardware asi nezvolite PHP, stejne jako webove stranky asi nebudete vyvijet v C nebo ASM (to neznamena, ze to nejde).
Teoreticky pokacite strom i priborem, ale moc efektivni to nebude.
Kazdopadne jestli mate problem se syntaxi jazyka a obtezuje vas to, tak se na to radsi vykaslete a zadejte to nekomu kdo to udela za vas, usetrite si nervy a cas ;)
-
jsem jen domaci hobik co by si rad nekdy neco zkusil, prinejhorsim nejake jednoucelove malinke aplikace nebo dokonce jen skripty, nebude mne to nikdy zivit, co bych se rad naucil je schopnost vyuzivat knihoven Pypi kterych je pro python pres 100.000 a vyuzivat "jiz hotove" k dosazeni sveho ucelu
muj programovaci jazyk snu je jazyk ktery uz ma na vsechno podstatne vestavene funkce atd... (nebo staci dat import standardni knihovny) a staci ty zabudovane ci importovane funkce atd.. jen volat (cili krome zakladni znalosti pythonu by mi stacilo si vzdy nastudovat standardni knihovnu a dalsi co chci pouzit abych to "jiz hotove" umel spravne pouzit (napr. upravit datove typy, jmena funkci atd..) event. jen lehce upravit aby to plnilo mnou pozadovany cil
-
Jeden z vydobytku programovacich jazyku je napriklad "teckova notace": Objekt.funkce nebo Objekt.funkce()
v php to nahradili Objekt->funkce(); hmmmm dobre. Zapis namespace v PHP je taky pekne obskurni a osklivy, dve lomitka? Vazne?
Jaká dvě lomítka v namespace? Je to jen jedno zpětné lomítko. Netvrdím, že se mi to líbí, ale zvykl jsem si.
Smalltalk místo tečky používá mezeru. Aspoň se nedávají dvě tečky (resp. dvě šipky) do jednoho výrazu, což by se určitě dělat nemělo.
-
muj programovaci jazyk snu je jazyk ktery uz ma na vsechno podstatne vestavene funkce atd... (nebo staci dat import standardni knihovny) a staci ty zabudovane ci importovane funkce atd.. jen volat (cili krome zakladni znalosti pythonu by mi stacilo si vzdy nastudovat standardni knihovnu a dalsi co chci pouzit abych to "jiz hotove" umel spravne pouzit (napr. upravit datove typy, jmena funkci atd..) event. jen lehce upravit aby to plnilo mnou pozadovany cil
Řekl bych, že pro tvé účely nic lepšího než Python asi nenajdeš. Užívej ho ve zdraví.
-
jeste bych se rad zeptal pro naprosto zakladni ucely povazujete za lepsi scriptovani v shellu s vyuzivanim vsech jednoucelovych unix (linux) commands, nejen tech co jsou napr. v bashi nebo je pro takove skriptovani vhodnejsi treba python
s ohledem na shora uvedene mi jde predevsim o to, ktera syntaxe je jednodussi pro bezneho neprogramatora jako ja resp. mnozstvi commands jez muzu rovnou volat z terminalu je proste mnohem vyssi a tim padem mene pracnejsi nez si to psat sam v pythonu ?
-
s ohledem na shora uvedene mi jde predevsim o to, ktera syntaxe je jednodussi pro bezneho neprogramatora
Programování v shellu je paradoxně ve finále hodně složité, protože můsíš vědět o spoustě různých edge cases a musíš je nějak ošetřit (což je typicky netriviální a krkolomné). Stupidní příklad: nemůžeš jenom tak napsat "for file in $(ls)", protože to nebude fungovat pro soubory s mezerou v názvu.
Shell je prostě to svou podstatou (předávání jenom textu) hodně omezený/komplikovaný.
-
jeste bych se rad zeptal pro naprosto zakladni ucely povazujete za lepsi scriptovani v shellu s vyuzivanim vsech jednoucelovych unix (linux) commands, nejen tech co jsou napr. v bashi nebo je pro takove skriptovani vhodnejsi treba python
Záleží na tom, co chceš skriptovat. Pro práci se soubory mi například vyhovuje shell. Jak jeho název napovídá, je to jen obálka, která toho moc neumí a na spoustu akcí je třeba zavolat externí příkaz. Pokud potřebuji něco spočítat, tak je vhodné zavolat třeba bc nebo zmíněný Python. Jenže pokud už ten Python voláš, tak v něm často můžeš zpracovat celou úlohu, obvykle s menší režií.
Jako výchozí tedy používám shell, ale při jakékoli komplikaci neváhám sáhnout po nějakém externím nástroji, například bc, awk, jq, xmllint, xqilla, xsltproc apod.
-
Na cokoliv netriviálního beru Python raději než shell. Oproti shellu má daleko méně zákeřnou syntaxi a jakoukoliv chybu lze z backtracu vyčíst během pár okamžiků. Pokud se člověk trochu snaží, může pythoní skript jednoduše přenést i tam, kde UNIXový shell není.
-
Pre mna absolutne dokonala je syntax zalozena na C, teda C++, C#, Java, čiastočne JScript. Úplne opačný extrém napríklad dnes už raritný Progress ABL. Napríklad deklarácia premennej typu integer:
C: int ix;
Progress ABL: DEFINE VARIABLE ix AS INTEGER NO-UNDO.
-
Pre mna absolutne dokonala je syntax zalozena na C, teda C++, C#, Java, čiastočne JScript. Úplne opačný extrém napríklad dnes už raritný Progress ABL. Napríklad deklarácia premennej typu integer:
C: int ix;
Progress ABL: DEFINE VARIABLE ix AS INTEGER NO-UNDO.
Zvlášť NO-UNDO lidi docela udivuje :D Vzhledem k provázanosti ABL s databází Progress totiž podléhají rollbacku při vrácení databázové transakce i proměnné, které byly v rámci transakce změněny.
Doteď nechápu, proč neurčili jako default NO-UNDO a nedali možnost měnit to naopak keywordem UNDO :)
Navíc se dá proměnné přiřadit i formátování, název sloupce pokud ji chci zobrazit v tabulce…
-
jsem jen domaci hobik co by si rad nekdy neco zkusil, prinejhorsim nejake jednoucelove malinke aplikace nebo dokonce jen skripty, nebude mne to nikdy zivit, co bych se rad naucil je schopnost vyuzivat knihoven Pypi kterych je pro python pres 100.000 a vyuzivat "jiz hotove" k dosazeni sveho ucelu
muj programovaci jazyk snu je jazyk ktery uz ma na vsechno podstatne vestavene funkce atd... (nebo staci dat import standardni knihovny) a staci ty zabudovane ci importovane funkce atd.. jen volat (cili krome zakladni znalosti pythonu by mi stacilo si vzdy nastudovat standardni knihovnu a dalsi co chci pouzit abych to "jiz hotove" umel spravne pouzit (napr. upravit datove typy, jmena funkci atd..) event. jen lehce upravit aby to plnilo mnou pozadovany cil
Poradím Ti - pokud chceš něco dělat dobře, budeš se to muset nějakou dobu učit. Problém není v nástroji, ale v Tobě. Buď se tomu věnuj pořádně, nebo jdi od toho. Syntaxe Pythonu je až směšně jednoduchá, u spousty dalších jazyků platí totéž. Ale naučit se myslet jako programátor a tu syntaxi si do toho myšlení dosadit, to chce práci.
-
to mas pravdu mam problem s trpelivosti, jak to nepochopim hned tak mam tendenci to preskocit .. budu muset byt mnohem vic trpelivy a jit pomaleji ..
-
to mas pravdu mam problem s trpelivosti, jak to nepochopim hned tak mam tendenci to preskocit .. budu muset byt mnohem vic trpelivy a jit pomaleji ..
V tomhle nejsi sám, leckdo začínal programovat tak, že napsal řádek a s napětím čekal, jestli se to zkompiluje a jak to pak bude fungovat. Ale to bylo (u mě) v Céčku (když nepočítám Basic a trochu Pascalu). Pak se z toho stane rutina, člověk má ty věci v krvi a samozřejmě se naučí větší kázni a promýšlení, než začne kódovat.
-
Nevím přesně jak daleko jsi ve schopnosti algoritmizace problému, ale pokud tě trápí syntaxe příkazů, můžeš zkusit programovat algoritmy ve Scratchi, tam to neřešíš. :)
Ale je to nástroj především pro výuku, žádný zkompilovaný výsledek ti z něj nevypadne.
-
Concatenative jazyky (Forth, 4th, 8th, Factor...) take maji minimalni syntaxi. Pozpatku uvazovat naucit se akorat.
-
Shell je prostě to svou podstatou (předávání jenom textu) hodně omezený/komplikovaný.
Naprosty souhlas. Nicméně pokud člověk přejde ze světa windows a jeho bat/cmd, je shell neskutečně mocný a jednoduchý. Holt, záleží na úhlu pohledu a kontextu. Sorry za offtopic, ale nedalo mi to.
-
Concatenative jazyky (Forth, 4th, 8th, Factor...) take maji minimalni syntaxi. Pozpatku uvazovat naucit se akorat.
12 5 6 * + .
-
Concatenative jazyky (Forth, 4th, 8th, Factor...) take maji minimalni syntaxi. Pozpatku uvazovat naucit se akorat.
12 5 6 * + .
Má to své kouzlo...
: FACTORIAL ( n - n! ) ?DUP IF 1- RECURSE * ELSE 1 THEN ;
-
za IF ještě DUP
-
Pozpatku uvazovat naucit se akorat.
Mistře Yodo?
-
https://cs.wikipedia.org/wiki/Brainfuck
-
Pozpatku uvazovat naucit se akorat.
Mistře Yodo?
On ten dabing nerespektoval mistrův způsob vyjadřování v anglickém originále? Tam ty věty byly gramaticky správně.
-
Pozpatku uvazovat naucit se akorat.
Mistře Yodo?
On ten dabing nerespektoval mistrův způsob vyjadřování v anglickém originále? Tam ty věty byly gramaticky správně.
V češtině jsou ty věty také gramaticky správně.
-
Pozpatku uvazovat naucit se akorat.
Mistře Yodo?
On ten dabing nerespektoval mistrův způsob vyjadřování v anglickém originále? Tam ty věty byly gramaticky správně.
V češtině jsou ty věty také gramaticky správně.
“Pozpatku uvazovat naucit se akorat.”
Aha.
-
Jeden z vydobytku programovacich jazyku je napriklad "teckova notace": Objekt.funkce nebo Objekt.funkce()
v php to nahradili Objekt->funkce(); hmmmm dobre. Zapis namespace v PHP je taky pekne obskurni a osklivy, dve lomitka? Vazne?
C++ a C používa aj bodku aj arrow operátor. Bodka sa v PHP používa na sčítanie reťazcov, asi preto zvolili arrow operátor.
PHP nepoužíva dva, len jedno lomítko. Najprv mi to klalo oči, ale zvykol som si a dokonca sa mi to páči. Lomítko (normálne aj spätné) sa predsa používa v adresárovej a doménovej oblasti, preto normálne lomítka v PHP namespace mi prídu prirodzené.
-
Pozpatku uvazovat naucit se akorat.
Mistře Yodo?
On ten dabing nerespektoval mistrův způsob vyjadřování v anglickém originále? Tam ty věty byly gramaticky správně.
V češtině jsou ty věty také gramaticky správně.
“Pozpatku uvazovat naucit se akorat.”
Aha.
Vidíš tam nějakou gramatickou chybu?
-
Jeden z vydobytku programovacich jazyku je napriklad "teckova notace": Objekt.funkce nebo Objekt.funkce()
v php to nahradili Objekt->funkce(); hmmmm dobre. Zapis namespace v PHP je taky pekne obskurni a osklivy, dve lomitka? Vazne?
C++ a C používa aj bodku aj arrow operátor. Bodka sa v PHP používa na sčítanie reťazcov, asi preto zvolili arrow operátor.
Sipka mi dava v PHP vetsi smysl, protoze to co je v $objekt je vzdy jen reference (napr. pri predavani jako argument funkce, nebo pri prirazezeni jako $tenSamy = $objekt). Pro explicitni kopii je treba udelat $kopie = clone $objekt;
Oproti tomu v C++ mas jak objekty tak referenci na objekty a stava se z toho prisernej gulas... takze jsem si C++ vubec neoblibil a kdyz chci vykon jedu v cistem C (C99), kde je velice jednoduche pochopit co dela . (pristup k pod-polozce) a co -> (to same, jen s dereferenci ukazatele).
Prakticky uzitek C++ a namespaces v PHP me nejak obchazi - dokazu napsat slusny program I bez techto rozsireni.
-
Prakticky uzitek C++ a namespaces v PHP me nejak obchazi - dokazu napsat slusny program I bez techto rozsireni.
Před namespaces se v PHP používaly prefixy a byl to (vlastně stále je) docela guláš. Pokud je v názvu třídy více než jedno slovo, tak stojí za zvážení, zda z některého z nich neudělat namespace. Z toho vyplývá, že bez namespace mají dnes smysl jen poměrně jednoduché aplikace s malým počtem tříd.
-
Prakticky uzitek C++ a namespaces v PHP me nejak obchazi - dokazu napsat slusny program I bez techto rozsireni.
Před namespaces se v PHP používaly prefixy
To zní jako Objective-C, tam je to taky dost bordel.
-
Jedna stará programátorská pravda hovorí, že ak umožníš programátorom programovať v slovenčine (češtine, angličtine, ...), zistíš, že nevedia po slovensky (česky, anglicky, ...).
Programovat slovensky ... fakt dobrej vtip.
Ne nejlepší je použít nejaké nárečí. Co šarišsky (východ slovenska)?
https://www.trsek.com/pascal/%C5%A0aral_-_nov%C3%BD_programovac%C3%AD_jazyk
-
Mám trochu dojem, že jsi ve fázi kdy ti dělá problém přejít od popisu problému v neformální "lidštině" do něčeho, co už připomíná algoritmus. Tahle fáze je těžká a navíc je dost nezávislá na jazyce. A jazyk, který ti nesedí, jen přidává další věci, na které musíš myslet. Ono se to poddá. Jen počítej s tím, že to chce čas a trénink. Přece jenom se snažíš přemýšlet hodně neintuitivním a nepřirozeným způsobem.
mne prave stve ze se pri psani nemuzu soustredit na podstatu daneho stavebniho kamene (treba budovani zanorenych cyklu) ale moji pozornost odvadi to, abych to napsal syntakticky spravne
V tom je umeni programovani. Myslet na algoritmus a zapisovat ho tak aby to pochopil pocitac. Jako skuseny programator ti povim ze programovani ma vic urovni. Je uroven kdy placas algoritmus. Tedy pises funkce a volas jine funkce (ktere casto ani neexistuji) a davas dohromady co porebujes. Je to program ktery dokazes cist jako nejakou povidku. Pak se zanoris o uroven nize a resis ty funkce ktere si pouzil a ktere maji neco delat. Postupne je dodelavas. Nakonec ses u veci ktere primo souvis s HW nebo OS. Resis rychlost, flexibilitu a optimalizujes. V techto rekneme 3 krocich oscilujes. Az mas neco co vypada jako kod, da se to prelozit a ...
pak prijde nekdo a rekne ze nemas unit testy.
-
k původnímu dozatu... ten Python ma stve práve pre ten syntax bez zátvoriek atd. Pak když píšeš funkce, a nemáš je oddelené blokovými zátvorkami tak sa ti kód zleje dokopy a je chaos. Najviac sa mi paci syntaxe jazykov JS, Scala, Golang, C,... inak syntaxe takychto jazykov má výhody v tucte vecí. Bodka je to že nad nejakým objektom/prvkom voláš trebárs funkci. typický príklad: nejakyzoznam.polozka.funkce(); a arrow operator je v podstate to že dereferencuješ "nejakyzoznam" abys nezískal pointer k nemu, ktorý funkce() používa, ale hodnoty. Presne tak ako to má C a Golang považujem za najrozumnejšie. I když Golang má tie pointre trocha v inom význame. Popravde viacerý hovoria fuj na pointre... Ja hovorím na céčkovské pointre fuj taky, na golang pointre nikoliv.
-
k arrow operator skvele napsané zde https://stackoverflow.com/questions/2575048/arrow-operator-usage-in-c
-
k původnímu dozatu... ten Python ma stve práve pre ten syntax bez zátvoriek atd. Pak když píšeš funkce, a nemáš je oddelené blokovými zátvorkami tak sa ti kód zleje dokopy a je chaos.
Není důvod k tomu, aby se ti to slilo - funkce snadno oddělíš prázdnými řádky a odsazení také napoví. Python má krásně čitelný zápis - akorát v něm nesmíš psát špagety, jinak se ti to vymstí. 3 úrovně odsazení musí stačit.
-
stejnak radši tam prcnu {}... bez tych zatvorek v pythonu je pak stejnak potreba psát stovku krát slovíčko "end"... čož považujem za blbší řešení.
-
stejnak radši tam prcnu {}... bez tych zatvorek v pythonu je pak stejnak potreba psát stovku krát slovíčko "end"... čož považujem za blbší řešení.
Nikdy jsem v Pythonu nepsal {} ani "end". K čemu by to bylo dobré?
-
a jak sa teda ví že kde končí telo cyklu napríklad? jako Python moc neumím.
-
a jak sa teda ví že kde končí telo cyklu napríklad? jako Python moc neumím.
Ukončíš odsazení.
-
No a to je ešte horšie než end... pretože si pak nemôžem uživateľsky prispôsobiť formátovanie kódu. A okrem toho čo je odsadenie? pojem jasnej, ale z pohladu súboru to niekde sú 2 medzery, niekde 4 medzery, niekde tab, niekde inde zas neco jiného. A najmä miešať kombinácie odsadenia je niečo čo si koleduje o problém, a zas ak by sa nemiešali, no neviem jak by sis zarovnal pod sebe zložitejšie kódy, trebárs už u parametrov funkcií musí to byť docela problém, mať tie parametre rozpísané na viac riadkov. Ak to i samotný jazyk / kompilér vie zhltnúť ok, ale čo uživateľ. Jak rozozná čo je odsadenie/zarovnanie a čo ukončenie nejakého bloku kódu.... proste to je chaos.
-
príklad z wikipedie:
def qsort(L):
if L == []:
return []
pivot = L[0]
return (qsort([x for x in L[1:] if x < pivot]) +
[pivot] +
qsort([x for x in L[1:] if x >= pivot]))
len pár riadkov kódu a už mi trvá dobrú sekundu zistiť ťo posledné 3 riadky vlastne predstavujú, a čo všetko pod return patrí. A když by za tím pokračoval kód (teda kdby to nebyl return), a kdyby toho kódu bolo 100 riadkov, tak som totálne z toho... by mi proste trvalo niekoľko sekúnd len pochopiť čo pod čo patrí.
from itertools import count
def generate_primes(stop_at=0):
primes = []
for n in count(2):
if 0 < stop_at < n:
return # raises the StopIteration exception
composite = False
for p in primes:
if not n % p:
composite = True
break
elif p ** 2 > n:
break
if not composite:
primes.append(n)
yield n
no a skombinuj si formatovanie prvého a druhého kódu... a sme v koncích.
-
No a to je ešte horšie než end... pretože si pak nemôžem uživateľsky prispôsobiť formátovanie kódu. A okrem toho čo je odsadenie? pojem jasnej, ale z pohladu súboru to niekde sú 2 medzery, niekde 4 medzery, niekde tab, niekde inde zas neco jiného. A najmä miešať kombinácie odsadenia je niečo čo si koleduje o problém, a zas ak by sa nemiešali, no neviem jak by sis zarovnal pod sebe zložitejšie kódy, trebárs už u parametrov funkcií musí to byť docela problém, mať tie parametre rozpísané na viac riadkov. Ak to i samotný jazyk / kompilér vie zhltnúť ok, ale čo uživateľ. Jak rozozná čo je odsadenie/zarovnanie a čo ukončenie nejakého bloku kódu.... proste to je chaos.
Není. Což bys věděl, kdybys věděl.
-
príklad z wikipedie:
def qsort(L):
if L == []:
return []
pivot = L[0]
return (qsort([x for x in L[1:] if x < pivot]) +
[pivot] +
qsort([x for x in L[1:] if x >= pivot]))
len pár riadkov kódu a už mi trvá dobrú sekundu zistiť ťo posledné 3 riadky vlastne predstavujú, a čo všetko pod return patrí. A když by za tím pokračoval kód (teda kdby to nebyl return), a kdyby toho kódu bolo 100 riadkov, tak som totálne z toho... by mi proste trvalo niekoľko sekúnd len pochopiť čo pod čo patrí.
Nepruď.
Když uděláš 100 řádků metodu tak budeš po zásluze trpět jako zvířete i s {} nebo begin end.
-
ani ne... príklad takého pomerne syntakticky prehľadného kódu je:
unsigned char* b_e(const char* text) {
if (text == NULL) {
return NULL;
}
if (text[0] == '\0') {
return '\0';
}
size_t k = strlen(text);
unsigned char* t = (unsigned char*)calloc((k+1), sizeof(char));
int b[k][8];
for (size_t i = 0; i < k; i++) {
for (size_t j = 8, m = 0; j > 0; j--, m++) {
b[i][m] = (text[i] & (1 << (j-1))? 1 : 0);
}
}
for (size_t i = 0; i < k; i++) {
for (size_t j = 0; j < 4; j = (j+2)) {
int d;
d = b[i][j];
b[i][j] = b[i][j+1];
b[i][j+1] = d;
}
}
for (size_t i = 0; i < k; i++) {
for (size_t j = 4; j < 8; j++) {
b[i][j] = (b[i][j]^b[i][j-4]);
}
}
int x[k];
for (size_t i = 0; i < k; i++) {
int d = 0;
for (size_t j = 0; j < 8; j++) {
if (b[i][j] == 1) {
d = d * 2 + 1;
} else if (b[i][j] == 0) {
d *= 2;
}
}
x[i] = d;
}
for (size_t i = 0; i < k; i++) {
t[i] = (unsigned char)x[i];
}
t[k] = '\0';
return t;
};
čož mi prijde v pohode čitelné, snaď jediná nečitatelnosť je pomenovanie premenných, i když i to je pre mňa v pohode čitelné. p.s. je to môj vlastný kód
-
a okrem toho 100+ znakové metódy môžu mať zmysel... na čo je deliť na 2, když samostatne tie 2 metódy nikdy volať nebudeš, ale budeš je chcieť vždy vykonať za sebou? Nehovoriac že sa medzi metódami bude musieť prenášať "medzivýsledok", čož je zbytočne navyše.
-
No a to je ešte horšie než end... pretože si pak nemôžem uživateľsky prispôsobiť formátovanie kódu. A okrem toho čo je odsadenie? pojem jasnej, ale z pohladu súboru to niekde sú 2 medzery, niekde 4 medzery, niekde tab, niekde inde zas neco jiného. A najmä miešať kombinácie odsadenia je niečo čo si koleduje o problém, a zas ak by sa nemiešali, no neviem jak by sis zarovnal pod sebe zložitejšie kódy, trebárs už u parametrov funkcií musí to byť docela problém, mať tie parametre rozpísané na viac riadkov. Ak to i samotný jazyk / kompilér vie zhltnúť ok, ale čo uživateľ. Jak rozozná čo je odsadenie/zarovnanie a čo ukončenie nejakého bloku kódu.... proste to je chaos.
Kdybys Python aspoň trochu znal, věděl bys, jak to tam funguje. Odsazení tam musí být konzistentní, jestli budeš konzistentně používat tři tabulátory nebo jednu mezeru je fuk, dokud to bude všude stejně. Free-form jazyky jako třeba C vedou k tomu, že šest kousků kódu od šesti programátorů vypadají každý úplně jinak, což se ve finále čte ještě mnohem hůře. Nikam nevedoucí dohady o tom, kam při deklaraci proměnných patří "*", zda uvozující "{" patří na nový řádek nebo na konec stávajícího atp. budiž důkazem.
Způsob zápisu kódu v Pythonu žádný chaos není, naopak je to vymyšlené docela chytře.
ani ne... príklad takého pomerne syntakticky prehľadného kódu je:
unsigned char* b_e(const char* text) {
if (text == NULL) {
return NULL;
}
if (text[0] == '\0') {
return '\0';
}
size_t k = strlen(text);
unsigned char* t = (unsigned char*)calloc((k+1), sizeof(char));
int b[k][8];
for (size_t i = 0; i < k; i++) {
for (size_t j = 8, m = 0; j > 0; j--, m++) {
b[i][m] = (text[i] & (1 << (j-1))? 1 : 0);
}
}
for (size_t i = 0; i < k; i++) {
for (size_t j = 0; j < 4; j = (j+2)) {
int d;
d = b[i][j];
b[i][j] = b[i][j+1];
b[i][j+1] = d;
}
}
for (size_t i = 0; i < k; i++) {
for (size_t j = 4; j < 8; j++) {
b[i][j] = (b[i][j]^b[i][j-4]);
}
}
int x[k];
for (size_t i = 0; i < k; i++) {
int d = 0;
for (size_t j = 0; j < 8; j++) {
if (b[i][j] == 1) {
d = d * 2 + 1;
} else if (b[i][j] == 0) {
d *= 2;
}
}
x[i] = d;
}
for (size_t i = 0; i < k; i++) {
t[i] = (unsigned char)x[i];
}
t[k] = '\0';
return t;
};
čož mi prijde v pohode čitelné, snaď jediná nečitatelnosť je pomenovanie premenných, i když i to je pre mňa v pohode čitelné. p.s. je to môj vlastný kód
Mně teda spíš než pojmenování proměnných vadí ten dvojí způsob zápisu return NULL;, který musí druhý programátor rozluštit a zamyslet se, zda je to bug nebo zamýšlené chování.
-
rozhodne nesúhlasím.
Mně teda spíš než pojmenování proměnných vadí ten dvojí způsob zápisu return NULL;, který musí druhý programátor rozluštit a zamyslet se, zda je to bug nebo zamýšlené chování.
čože? ja tam nikde nevidím dvojí způsob zápisu return NULL; Druhý if nieje kontrola na NULL ale na prázdnu hodnotu,... rozdiel:
(https://josjong.files.wordpress.com/2017/10/toilet-rolls.jpg?w=1400)
-
a okrem toho 100+ znakové metódy môžu mať zmysel... na čo je deliť na 2, když samostatne tie 2 metódy nikdy volať nebudeš, ale budeš je chcieť vždy vykonať za sebou? Nehovoriac že sa medzi metódami bude musieť prenášať "medzivýsledok", čož je zbytočne navyše.
Protoze ti to umozni veci pojmenovat.
-
rozhodne nesúhlasím.
Mně teda spíš než pojmenování proměnných vadí ten dvojí způsob zápisu return NULL;, který musí druhý programátor rozluštit a zamyslet se, zda je to bug nebo zamýšlené chování.
čože? ja tam nikde nevidím dvojí způsob zápisu return NULL; Druhý if nieje kontrola na NULL ale na prázdnu hodnotu,... rozdiel:
(https://josjong.files.wordpress.com/2017/10/toilet-rolls.jpg?w=1400)
Aha, takže je to tedy bug. '\0' má numerickou hodnotu nula, takže výsledek return NULL a return '\0' je stejný - vyzkoušej si to. (Pro hnidopichy: je stejný za předpokladu, že makro NULL je definováno jako nula.) Předpokládám, že spíš než return '\0' bylo myšleno return "". Vzhedem k tomu, že ten kód jinak vrací pointer na dynamicky alokovanou paměť by ale i to bylo špatně.
-
rozhodne nesúhlasím.
Mně teda spíš než pojmenování proměnných vadí ten dvojí způsob zápisu return NULL;, který musí druhý programátor rozluštit a zamyslet se, zda je to bug nebo zamýšlené chování.
čože? ja tam nikde nevidím dvojí způsob zápisu return NULL; Druhý if nieje kontrola na NULL ale na prázdnu hodnotu,... rozdiel:
(https://josjong.files.wordpress.com/2017/10/toilet-rolls.jpg?w=1400)
Aha, takže je to tedy bug. '\0' má numerickou hodnotu nula, takže výsledek return NULL a return '\0' je stejný - vyzkoušej si to. (Pro hnidopichy: je stejný za předpokladu, že makro NULL je definováno jako nula.) Předpokládám, že spíš než return '\0' bylo myšleno return "". Vzhedem k tomu, že ten kód jinak vrací pointer na dynamicky alokovanou paměť by ale i to bylo špatně.
ne neni to stejný.... ani zdaleka. skus odstraniť overenie na NULL, a predaj ten metóde parameter NULL, nepôjde to.
Zatiaľ čo NULL znamená NULL teda nič. Tak prázdna hodnota znamená že je niekde v pamäti miesto, kde je premenná s prázdnou hodnotou. A '\0' je v podstate zakončenie stringu, ktorá je v C reprezentovaná poľom znakov.
Protoze ti to umozni veci pojmenovat.
a čo z toho pomenovania mám? to je jak kdybych si prišiel do mcdonaldu a pomenoval by som každú časť hamburgera ktorý si chem kúpiť... namiesto teda "chcem kurací hamburger" by som povedal "chcem dolnú časť žemle hamburgeru na ňom kurací rezeň, a na ňom hornú časť žemle hamburgeru". Abstrakce k hovnu.
-
rozhodne nesúhlasím.
Mně teda spíš než pojmenování proměnných vadí ten dvojí způsob zápisu return NULL;, který musí druhý programátor rozluštit a zamyslet se, zda je to bug nebo zamýšlené chování.
čože? ja tam nikde nevidím dvojí způsob zápisu return NULL; Druhý if nieje kontrola na NULL ale na prázdnu hodnotu,... rozdiel:
(https://josjong.files.wordpress.com/2017/10/toilet-rolls.jpg?w=1400)
Aha, takže je to tedy bug. '\0' má numerickou hodnotu nula, takže výsledek return NULL a return '\0' je stejný - vyzkoušej si to. (Pro hnidopichy: je stejný za předpokladu, že makro NULL je definováno jako nula.) Předpokládám, že spíš než return '\0' bylo myšleno return "". Vzhedem k tomu, že ten kód jinak vrací pointer na dynamicky alokovanou paměť by ale i to bylo špatně.
ne neni to stejný.... ani zdaleka. skus odstraniť overenie na NULL, a predaj ten metóde parameter NULL, nepôjde to.
Zatiaľ čo NULL znamená NULL teda nič. Tak prázdna hodnota znamená že je niekde v pamäti miesto, kde je premenná s prázdnou hodnotou. A '\0' je v podstate zakončenie stringu, ktorá je v C reprezentovaná poľom znakov.
Protoze ti to umozni veci pojmenovat.
a čo z toho pomenovania mám? to je jak kdybych si prišiel do mcdonaldu a pomenoval by som každú časť hamburgera ktorý si chem kúpiť... namiesto teda "chcem kurací hamburger" by som povedal "chcem dolnú časť žemle hamburgeru na ňom kurací rezeň, a na ňom hornú časť žemle hamburgeru". Abstrakce k hovnu.
Protoze pak neni ta metoda ten chliv, co jsi poslal, ale neco, co se da precist a pochopit.
-
prečítaj si https://stackoverflow.com/questions/1296843/what-is-the-difference-between-null-0-and-0
-
Protoze pak neni ta metoda ten chliv, co jsi poslal, ale neco, co se da precist a pochopit.
naopak... môj kód je omnoho prehladnejší než 99% zdrojákov v Pythone nejakých zmysluplnejších projektov.
-
rozhodne nesúhlasím.
Mně teda spíš než pojmenování proměnných vadí ten dvojí způsob zápisu return NULL;, který musí druhý programátor rozluštit a zamyslet se, zda je to bug nebo zamýšlené chování.
čože? ja tam nikde nevidím dvojí způsob zápisu return NULL; Druhý if nieje kontrola na NULL ale na prázdnu hodnotu,... rozdiel:
(https://josjong.files.wordpress.com/2017/10/toilet-rolls.jpg?w=1400)
Aha, takže je to tedy bug. '\0' má numerickou hodnotu nula, takže výsledek return NULL a return '\0' je stejný - vyzkoušej si to. (Pro hnidopichy: je stejný za předpokladu, že makro NULL je definováno jako nula.) Předpokládám, že spíš než return '\0' bylo myšleno return "". Vzhedem k tomu, že ten kód jinak vrací pointer na dynamicky alokovanou paměť by ale i to bylo špatně.
ne neni to stejný.... ani zdaleka. skus odstraniť overenie na NULL, a predaj ten metóde parameter NULL, nepôjde to.
Zatiaľ čo NULL znamená NULL teda nič. Tak prázdna hodnota znamená že je niekde v pamäti miesto, kde je premenná s prázdnou hodnotou. A '\0' je v podstate zakončenie stringu, ktorá je v C reprezentovaná poľom znakov.
Aha, zřejmě jsme se nepochopili. Pokud odstraním NULL kontrolu a předám funkci NULL pointer, samozřejmě to spadne. Pokud té funkci ale předám řetězec nulové délky (ta druhá kontrola), funkce b_e taky vrátí NULL. Z kódu není zřejmé, zda jsi to tak chtěl je to typický Cčkový bug.
-
Aha, zřejmě jsme se nepochopili. Pokud odstraním NULL kontrolu a předám funkci NULL pointer, samozřejmě to spadne. Pokud té funkci ale předám řetězec nulové délky (ta druhá kontrola), funkce b_e taky vrátí NULL. Z kódu není zřejmé, zda jsi to tak chtěl je to typický Cčkový bug.
nerozumíš tomu... prečítaj si toto PDF... NULL vs '\0' je ako když ti dá niekto do ruky prázdnu krabicu a v druhej ruke by si nič nemal, a niekto ti povedal, porovnaj to... samozrejme že v rukách nedržíš to isté "akože nič (jak bys to pojmenoval)". A skus si výsledok b_e nekde vypsať... týmto kódom:
int main(int argc, char const *argv[]) {
unsigned char* b_ev = b_e(argv[1]);
if (b_ev != NULL) {
size_t k = strlen((char*)b_ev);
for (size_t i = 0; i < k; i++) {
printf("%x", (unsigned int)b_ev);
}
printf("\n");
} else {
printf("NULL\n");
}
free(b_ev);
b_ev = NULL;
}
v jednom prípade ti do konzole vypíše NULL v druhom zas prázdny riadok. p.s. to je taky môj kód. Rozdiel je teda
./aa
./a ""
-
Pokud odstraním NULL kontrolu a předám funkci NULL pointer, samozřejmě to spadne. Pokud té funkci ale předám řetězec nulové délky (ta druhá kontrola), funkce b_e taky vrátí NULL. Z kódu není zřejmé, zda jsi to tak chtěl je to typický Cčkový bug.
Proč bys měl předávat funkci NULL pointer, když vyžaduje instanci třídy? Proč by nějaká funkce měla vracet NULL, když má vracet instanci třídy?
-
Protoze pak neni ta metoda ten chliv, co jsi poslal, ale neco, co se da precist a pochopit.
takže podľa tebe je jednoduchšie povedať "chcem dolnú časť žemle hamburgeru na ňom kurací rezeň, a na ňom hornú časť žemle hamburgeru" než "chcem kurací hamburger", to je teda fajn logika. Čitatelnejšie to o nič nieje, a ani to nepotrebuješ. Predsa si hamburger kupuješ ako celok. Obsah hamburgeru zaujíma len zamestnanca mcdonalda, ktorý ale vytvára celistvý "produkt" teda hamburger.
-
Aha, zřejmě jsme se nepochopili. Pokud odstraním NULL kontrolu a předám funkci NULL pointer, samozřejmě to spadne. Pokud té funkci ale předám řetězec nulové délky (ta druhá kontrola), funkce b_e taky vrátí NULL. Z kódu není zřejmé, zda jsi to tak chtěl je to typický Cčkový bug.
nerozumíš tomu... prečítaj si toto PDF... NULL vs '\0' je ako když ti dá niekto do ruky prázdnu krabicu a v druhej ruke by si nič nemal, a niekto ti povedal, porovnaj to... samozrejme že v rukách nedržíš to isté "akože nič (jak bys to pojmenoval)". A skus si výsledok b_e nekde vypsať... týmto kódom:
int main(int argc, char const *argv[]) {
unsigned char* b_ev = b_e(argv[1]);
if (b_ev != NULL) {
size_t k = strlen((char*)b_ev);
for (size_t i = 0; i < k; i++) {
printf("%x", (unsigned int)b_ev);
}
printf("\n");
} else {
printf("NULL\n");
}
free(b_ev);
b_ev = NULL;
}
v jednom prípade ti do konzole vypíše NULL v druhom zas prázdny riadok. p.s. to je taky môj kód. Rozdiel je teda
./aa
./a ""
Mně ten kód vypíše NULL pro oba případy, což by podle mě měl.
Pokud odstraním NULL kontrolu a předám funkci NULL pointer, samozřejmě to spadne. Pokud té funkci ale předám řetězec nulové délky (ta druhá kontrola), funkce b_e taky vrátí NULL. Z kódu není zřejmé, zda jsi to tak chtěl je to typický Cčkový bug.
Proč bys měl předávat funkci NULL pointer, když vyžaduje instanci třídy? Proč by nějaká funkce měla vracet NULL, když má vracet instanci třídy?
V Cčku žádné třídy nejsou, NULL jako indikace neexistující či neplatné hodnoty se tam běžně používá a v kódu se s tím má počítat.
-
Neviditelný, prečítaj si http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf sekci 6.3.2.3, §3
resp. aký je rozdiel medzi
a
00000000
-
Neviditelný, prečítaj si http://c-faq.com/null/ptrtest.html a http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf sekci 6.3.2.3, §3
Ach jo, já vím, jak to funguje. Zkompiluj si kód níže a podívej se na výsledek. Pokud to nekompiluješ nějakým prazvláštním kompilátorem, musí to fungovat tak, jak říkám:
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
unsigned char* b_e(const char* text) {
if (text == NULL) {
return NULL;
}
if (text[0] == '\0') {
return '\0';
}
size_t k = strlen(text);
unsigned char* t = (unsigned char*)calloc((k+1), sizeof(char));
int b[k][8];
for (size_t i = 0; i < k; i++) {
for (size_t j = 8, m = 0; j > 0; j--, m++) {
b[i][m] = (text[i] & (1 << (j-1))? 1 : 0);
}
}
for (size_t i = 0; i < k; i++) {
for (size_t j = 0; j < 4; j = (j+2)) {
int d;
d = b[i][j];
b[i][j] = b[i][j+1];
b[i][j+1] = d;
}
}
for (size_t i = 0; i < k; i++) {
for (size_t j = 4; j < 8; j++) {
b[i][j] = (b[i][j]^b[i][j-4]);
}
}
int x[k];
for (size_t i = 0; i < k; i++) {
int d = 0;
for (size_t j = 0; j < 8; j++) {
if (b[i][j] == 1) {
d = d * 2 + 1;
} else if (b[i][j] == 0) {
d *= 2;
}
}
x[i] = d;
}
for (size_t i = 0; i < k; i++) {
t[i] = (unsigned char)x[i];
}
t[k] = '\0';
return t;
};
void prn(const char *in)
{
unsigned char *ret = b_e(in);
printf("Input ptr: %p\n", (void *)in);
if (ret == NULL)
printf("NULL INPUT\n");
else {
printf("%p\n", (void *)ret);
free(ret);
}
}
int main(int argc, char const* argv[]) {
(void)argc; (void)argv;
const char* none = NULL;
const char *empty = "";
const char empty2[] = { '\0' };
const char *valid = "abcde";
prn(none);
prn(empty);
prn(empty2);
prn(valid);
return 0;
}
Mně to vrátí
Input ptr: (nil)
NULL INPUT
Input ptr: 0x5582cd85901e
NULL INPUT
Input ptr: 0x7ffd5eff2417
NULL INPUT
Input ptr: 0x5582cd85901f
0x5582ce11d670
-
nerozumieš tomu.... konec debaty. Když nedokážeš porozumieť ani tomuto:
https://stackoverflow.com/questions/1296843/what-is-the-difference-between-null-0-and-0
tak je to tragické.
-
No a to je ešte horšie než end... pretože si pak nemôžem uživateľsky prispôsobiť formátovanie kódu. A okrem toho čo je odsadenie? pojem jasnej, ale z pohladu súboru to niekde sú 2 medzery, niekde 4 medzery, niekde tab, niekde inde zas neco jiného. A najmä miešať kombinácie odsadenia je niečo čo si koleduje o problém, a zas ak by sa nemiešali, no neviem jak by sis zarovnal pod sebe zložitejšie kódy, trebárs už u parametrov funkcií musí to byť docela problém, mať tie parametre rozpísané na viac riadkov. Ak to i samotný jazyk / kompilér vie zhltnúť ok, ale čo uživateľ. Jak rozozná čo je odsadenie/zarovnanie a čo ukončenie nejakého bloku kódu.... proste to je chaos.
V Pythonu je formátování kódu součástí syntaxe, stejně jako u formátu YAML. Prostě si na to zvykni nebo používej jiný jazyk. V rámci jednoho bloku smí být odsazení jen jednoho typu - doporučuje se však používat důsledně 4 mezery. Nebudeš mít problémy při práci v týmu. U formálních parametrů si odsazování hlídat nemusíš, tam jsou podstatné čárky a uzavírací závorka.
príklad z wikipedie:
def qsort(L):
if L == []:
return []
pivot = L[0]
return (qsort([x for x in L[1:] if x < pivot]) +
[pivot] +
qsort([x for x in L[1:] if x >= pivot]))
len pár riadkov kódu a už mi trvá dobrú sekundu zistiť ťo posledné 3 riadky vlastne predstavujú, a čo všetko pod return patrí. A když by za tím pokračoval kód (teda kdby to nebyl return), a kdyby toho kódu bolo 100 riadkov, tak som totálne z toho... by mi proste trvalo niekoľko sekúnd len pochopiť čo pod čo patrí.
Quicksort asi programovat nebudeš - nemá to praktický význam. Kromě toho je ten příklad blbě. Po troše zkušeností zjistíš, že binární operátor na konci bude znamenat na následujícím řádku, podobně jako neuzavřená závorka. Nejsem však příznivcem zalamování, totéž se dá zapsat i bez něho:
def qsort(L):
if L == []:
return []
pivot = L[0]
left = qsort([x for x in L[1:] if x < pivot])
right = qsort([x for x in L[1:] if x >= pivot])
return left + [pivot] + right
Sice je to stále blbě, ale už je to bez zalamování.
-
nerozumíš tomu... prečítaj si toto PDF... NULL vs '\0' je ako když ti dá niekto do ruky prázdnu krabicu a v druhej ruke by si nič nemal,
Bohužel tomu nerozumíš ty, Mlociku. V C je NULL typicky to stejné jako '\0'. Mimochodem máš tam typovou chybu, vracet char tam, kde se očekává pointer, v modernějších jazycích než je C z dobrých důvodů nelze. V C to projde jen díky tomu, že provádí implicitní konverze. Začni raději s Pythonem, tam se ti nepodaří střelit se takhle snadno do vlastní nohy.
-
nerozumieš tomu.... konec debaty. Když nedokážeš porozumieť ani tomuto:
https://stackoverflow.com/questions/1296843/what-is-the-difference-between-null-0-and-0
tak je to tragické.
Tvůj kód přeložený dvěma překladači (Clang 7 a GCC 8.2) vrací výstup, který odporuje tvému tvrzení a já tomu nerozumím? Co vypíše ten můj zkušební kód tobě?
Např. v C++14 by se ta funkce b_e, jak je napsána teď nepřeložila vůbec.
-
ja když predám funkci b_e prázdny string, tak to vráti prázdny string a teda aj vypíše prázdny riadok... v prípade že mu predám NULL tak vypíše NULL.
-
vy ste schopný i autorov jazyka C prehovoriť že v ich jazyku je NULL to isté čo '\0' ... smutné, hlavne že oni sami píšu že to to isté nieje.
-
ja když predám funkci b_e prázdny string, tak to vráti prázdny string a teda aj vypíše prázdny riadok... v prípade že mu predám NULL tak vypíše NULL.
V tom případě děláš něco blbě, protože tvůj vlastní kód dělá něco jiného, pro prázdný string vrací '\0' alias 0 alias NULL.
-
ja když predám funkci b_e prázdny string, tak to vráti prázdny string a teda aj vypíše prázdny riadok... v prípade že mu predám NULL tak vypíše NULL.
V tom případě děláš něco blbě, protože tvůj vlastní kód dělá něco jiného, pro prázdný string vrací '\0' alias 0 alias NULL.
'\0' nieje žiadna alias NULL!!!!!!!!!!!!!
-
vy ste schopný i autorov jazyka C prehovoriť že v ich jazyku je NULL to isté čo '\0' ... smutné, hlavne že oni sami píšu že to to isté nieje.
Fakt?
madcat@The-Raza ~/Devel/zzz # cat n.c
#include <stdio.h>
int main()
{
printf("Equals? %s\n", (NULL == '\0') ? "Yes" : "No");
return 0;
}
madcat@The-Raza ~/Devel/zzz # clang -Wall -Wextra -pedantic n.c -o n
madcat@The-Raza ~/Devel/zzz # ./n
Equals? Yes
No nic, mír s vámi...
-
No nic, mír s vámi...
+1
Napr string.h obsahuje
#define NULL 0
-
vy ste schopný i autorov jazyka C prehovoriť že v ich jazyku je NULL to isté čo '\0' ... smutné, hlavne že oni sami píšu že to to isté nieje.
Hodnota NULL je stejná jako '\0', prostě 0. Typ je jiný, C pro NULL nespecifikuje typ, může to být (int) nebo třeba ((void*) 0). Ty vracíš returnem (char) 0, což se automaticky zkonvertuje na (int) 0, respektive ((void*) 0), neboli NULL.
-
vy ste schopný i autorov jazyka C prehovoriť že v ich jazyku je NULL to isté čo '\0' ... smutné, hlavne že oni sami píšu že to to isté nieje.
Hodnota NULL je stejná jako '\0', prostě 0. Typ je jiný, C pro NULL nespecifikuje typ, může to být (int) nebo třeba ((void*) 0). Ty vracíš returnem (char) 0, což se automaticky zkonvertuje na (int) 0, respektive ((void*) 0), neboli NULL.
NULL je NULL. Spolehat ze to je typove shodne s \0, 0 nebo "" je znak nevyzratosti programatora.
-
'\0' nieje žiadna alias NULL!!!!!!!!!!!!!
Však proto ti píšu, že je ten tvůj program blbě a máš tam typovou chybu. '\0' má stejnou hodnotu jako NULL, ale jiný typ. Něco to dělá jen z toho důvodu, že C pomocí implicitních konverzí vyrobí z '\0' NULL a to z té funkce taky vracíš. Nedělá to ovšem to, co bys předpokládal, proto jsi z toho tak zmatený.
-
madcat@The-Raza ~/Devel/zzz # cat n.c
#include <stdio.h>
int main() {
printf("Equals? %s\n", (NULL == '\0') ? "Yes" : "No");
return 0;
}
madcat@The-Raza ~/Devel/zzz # clang -Wall -Wextra -pedantic n.c -o n
madcat@The-Raza ~/Devel/zzz # ./n
Equals? Yes
No nic, mír s vámi...
Fakt, že tvůj program podporuje tvé tvrzení, ještě neznamená, že není špatně. Kompilátor ho sice zbaští, ale je to dáno tím, že principy jazyka C jsou již zastaralé a nevyhovují dnešním požadavkům. Assembler se sice stále dá používat, ale vývojáři se mu vyhýbají, protože se v něm dá snadno střelit do nohy a nebude mu to vadit. Totéž platí i pro C, které je vlastně jen lepším assemblerem. Na dnešní potřeby už nestačí.
-
vy ste schopný i autorov jazyka C prehovoriť že v ich jazyku je NULL to isté čo '\0' ... smutné, hlavne že oni sami píšu že to to isté nieje.
Hodnota NULL je stejná jako '\0', prostě 0. Typ je jiný, C pro NULL nespecifikuje typ, může to být (int) nebo třeba ((void*) 0). Ty vracíš returnem (char) 0, což se automaticky zkonvertuje na (int) 0, respektive ((void*) 0), neboli NULL.
NULL je NULL. Spolehat ze to je typove shodne s \0, 0 nebo "" je znak nevyzratosti programatora.
presne
-
vy ste schopný i autorov jazyka C prehovoriť že v ich jazyku je NULL to isté čo '\0' ... smutné, hlavne že oni sami píšu že to to isté nieje.
Fakt?
madcat@The-Raza ~/Devel/zzz # cat n.c
#include <stdio.h>
int main()
{
printf("Equals? %s\n", (NULL == '\0') ? "Yes" : "No");
return 0;
}
madcat@The-Raza ~/Devel/zzz # clang -Wall -Wextra -pedantic n.c -o n
madcat@The-Raza ~/Devel/zzz # ./n
Equals? Yes
No nic, mír s vámi...
Chtelo by to pouzit vyzralejsi prekladac a ne nejaky trapny pokus o nej :)
$ gcc -Wall -Wextra -pedantic n.c -o n
n.c: In function ‘main’:
n.c:4:38: warning: comparison between pointer and zero character constant [-Wpointer-compare]
printf("Equals? %s\n", (NULL == '\0') ? "Yes" : "No");
^~
In file included from /usr/include/_G_config.h:15:0,
from /usr/include/libio.h:31,
from /usr/include/stdio.h:41,
from n.c:1:
n.c:4:33: note: did you mean to dereference the pointer?
printf("Equals? %s\n", (NULL == '\0') ? "Yes" : "No");
-
takže podľa tebe je jednoduchšie povedať "chcem dolnú časť žemle hamburgeru na ňom kurací rezeň, a na ňom hornú časť žemle hamburgeru" než "chcem kurací hamburger", to je teda fajn logika. Čitatelnejšie to o nič nieje, a ani to nepotrebuješ. Predsa si hamburger kupuješ ako celok. Obsah hamburgeru zaujíma len zamestnanca mcdonalda, ktorý ale vytvára celistvý "produkt" teda hamburger.
Protože chceš hamburger, zavoláš funkci dejHamburger(), která bude obsahovat něco jako:
function dejHamburger() {
var hamburger = dolniPulkaHousky() + salat() + rajce() + maso() + okurka() + horniPulkaHousky();
return hamburger;
}A ty jednotlivé funkce už nebudou mít každá 100 řádků.
Ano, jsou situace kdy těch 100 řádků v jedné funkci/proceduře/metodě smysl má, ale zrovna u hamburgeru to určitě potřeba není.
-
vy ste schopný i autorov jazyka C prehovoriť že v ich jazyku je NULL to isté čo '\0' ... smutné, hlavne že oni sami píšu že to to isté nieje.
Fakt?
madcat@The-Raza ~/Devel/zzz # cat n.c
#include <stdio.h>
int main()
{
printf("Equals? %s\n", (NULL == '\0') ? "Yes" : "No");
return 0;
}
madcat@The-Raza ~/Devel/zzz # clang -Wall -Wextra -pedantic n.c -o n
madcat@The-Raza ~/Devel/zzz # ./n
Equals? Yes
No nic, mír s vámi...
Chtelo by to pouzit vyzralejsi prekladac a ne nejaky trapny pokus o nej :)
$ gcc -Wall -Wextra -pedantic n.c -o n
n.c: In function ‘main’:
n.c:4:38: warning: comparison between pointer and zero character constant [-Wpointer-compare]
printf("Equals? %s\n", (NULL == '\0') ? "Yes" : "No");
^~
In file included from /usr/include/_G_config.h:15:0,
from /usr/include/libio.h:31,
from /usr/include/stdio.h:41,
from n.c:1:
n.c:4:33: note: did you mean to dereference the pointer?
printf("Equals? %s\n", (NULL == '\0') ? "Yes" : "No");
Clang - na rozdíl od GCC - zase správně varuje, že return '\0' z funkce, která vrací char * je potenciální chyba; GCC v tomto případě mlčí. To ale nemá žádný vliv na to, jak takový kód bude fungovat. NULL a '\0' se budou efektivně lišit jen tehdy, pokud bude NULL definováno na něco jiného než (void *)0, což jsem chtěl ukázat.
-
Clang - na rozdíl od GCC - zase správně varuje, že return '\0' z funkce, která vrací char * je potenciální chyba; GCC v tomto případě mlčí. To ale nemá žádný vliv na to, jak takový kód bude fungovat. NULL a '\0' se budou efektivně lišit jen tehdy, pokud bude NULL definováno na něco jiného než (void *)0, což jsem chtěl ukázat.
Ukazuješ jen programátorské porno, ze kterého jsme už docela otrávení.
-
...
Ukazuješ jen programátorské porno, ze kterého jsme už docela otrávení.
Kdybys tak jen měl možnost tohle vlákno, které zdechlo tak po desátém příspěvku, prostě dál nečíst...
-
No nic, mír s vámi...
+1
Napr string.h obsahuje
#define NULL 0
A můžeš zaručit, že totéž bude ve všech možných kompilátorech na veškerých platformách, exitujících v minulosti i budoucnosti? Oni tvůrci jazyka C byli poněkud zkušenější, proto je norma v některých věcech až příliš volná...
Pokud funkce vrací NULL, předpokládám že dostanu něco jako 0x00000000, aspoň u části dnes používaných procesorů.
Ale pokud vrací '\0', může to být klidně 0x00FAB059, nebo něco ještě šílenějšího, v závislosti na šířce slova a endianitě!
O čísle 0 ani nemluvě.
Ten toaletní obrázek to vystihuje naprosto dokonale, a zároveň poslouží jako test nedostatku abstrakce u těch, kteří ho okamžitě nepochopili ::)
-
No nic, mír s vámi...
+1
Napr string.h obsahuje
#define NULL 0
A můžeš zaručit, že totéž bude ve všech možných kompilátorech na veškerých platformách, exitujících v minulosti i budoucnosti? Oni tvůrci jazyka C byli poněkud zkušenější, proto je norma v některých věcech až příliš volná...
Můžu, protože nulový ukazatel je standardem jazyka C definován jako ukazatel s číselnou hodnotou nula. Podivné platformy, na kterých to tak není musí ošetřit kompilátor. Na takových platformách by se totiž rozbilo víc věcí, než jen porovnání vůči NULL.
Pokud funkce vrací NULL, předpokládám že dostanu něco jako 0x00000000, aspoň u části dnes používaných procesorů.
Ale pokud vrací '\0', může to být klidně 0x00FAB059, nebo něco ještě šílenějšího, v závislosti na šířce slova a endianitě!
O čísle 0 ani nemluvě.
WTF? Nula je prostě nula bez ohledu na to, jak ji zapíšu.
A dost, sorry, soudruzi, ale už mě to fakt nebaví... :)
-
nulový ukazatel je standardem jazyka C definován jako ukazatel s číselnou hodnotou nula.
Proč?
-
nulový ukazatel je standardem jazyka C definován jako ukazatel s číselnou hodnotou nula.
Proč?
protože on to tvrdí... NULL a '\0' nie je to iste a nikdy ani nebolo...
-
protože on to tvrdí... NULL a '\0' nie je to iste a nikdy ani nebolo...
Už ti to vysvětlovalo několik lidí a stále jsi to nepochopil... Zkusím to polopatě:
#include <stdio.h>
char* foo() {
return NULL;
}
char* bar() {
return '\0';
}
int main() {
printf("foo: %p\n", foo());
printf("bar: %p\n", bar());
return 0;
}
C standard ZARUČUJE, že funkce foo a bar se chovají naprosto identicky, obě vrací ukazatel s hodnotou 0. Nejenom, že ten program dává pro foo i bar stejný výstup, ty funkce se i identicky přeloží, stačí se podívat do assembleru:
.type foo, @function
foo:
.LFB11:
.cfi_startproc
xorl %eax, %eax
ret
.cfi_endproc
.type bar, @function
bar:
.LFB12:
.cfi_startproc
xorl %eax, %eax
ret
.cfi_endproc
Při takovém použítí NULL a '\0', přesně jak jsi to udělal ve svém programu, není rozdíl mezi NULL a '\0'.
-
nulový ukazatel je standardem jazyka C definován jako ukazatel s číselnou hodnotou nula.
Proč?
protože on to tvrdí... NULL a '\0' nie je to iste a nikdy ani nebolo...
Céčkařům prostě nevysvětlíš, co je to sémantické programování. Stejně obtížně bys jim vysvětloval, že posun o jeden bit vlevo není násobení dvěma. Jsou zvyklí přemýšlet nad tím, jak to zpracuje stroj a to je pro ně podstatné.
-
Céčkařům prostě nevysvětlíš, co je to sémantické programování. Stejně obtížně bys jim vysvětloval, že posun o jeden bit vlevo není násobení dvěma. Jsou zvyklí přemýšlet nad tím, jak to zpracuje stroj a to je pro ně podstatné.
PHP lopatám nevysvětlíš, že existuje něco jako standard jazyka C, který jasně definuje, jak se co chová. Jsou schopni blábolit něco o třídách v C, škoda mluvit... Dneska fakt může psát na net každý pologramota.
-
nulový ukazatel je standardem jazyka C definován jako ukazatel s číselnou hodnotou nula.
Proč?
To by ses musel zeptat Dennise Ritchieho. Osobně předpokládám, že je to proto, abys mohl s ukazatelem zacházet úplně stejně jako s integerem, což se v dobách, kdy bylo C nejvíce relevantní jazyk dost hodilo. Navíc přiřadit speciální význam právě nule dává tak nějak intuitivně smysl.
NULL je makro definované jako (void*)0, '\0' je znakový literál reprezentující číselnou nulu. Oboje je víceméně syntaxtický cukr, aby nebylo nutné explicitně psát ptr != (void*)0 a str[N-1] = (char)0. Je nanejvýš děsivé, že ač je C staré šestačtyřicet let a leckde se vyučuje v základech algoritmizace jako první jazyk to chápe jediný lopata...
-
nulový ukazatel je standardem jazyka C definován jako ukazatel s číselnou hodnotou nula.
Proč?
To by ses musel zeptat Dennise Ritchieho. Osobně předpokládám, že je to proto, abys mohl s ukazatelem zacházet úplně stejně jako s integerem, což se v dobách, kdy bylo C nejvíce relevantní jazyk dost hodilo. Navíc přiřadit speciální význam právě nule dává tak nějak intuitivně smysl.
NULL je makro definované jako (void*)0, '\0' je znakový literál reprezentující číselnou nulu. Oboje je víceméně syntaxtický cukr, aby nebylo nutné explicitně psát ptr != (void*)0 a str[N-1] = (char)0. Je nanejvýš děsivé, že ač je C staré šestačtyřicet let a leckde se vyučuje v základech algoritmizace jako první jazyk to chápe jediný lopata...
díky za pochvalu.. ;D nebo koho si tu lopatu myslel?
-
nulový ukazatel je standardem jazyka C definován jako ukazatel s číselnou hodnotou nula.
Proč?
To by ses musel zeptat Dennise Ritchieho.
Jenže ten to nevymyslel, vzniklo to roky před Unixem i C: https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare (https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare) ;)
Ve skutečnosti je to prasecká ojebávka, související s fungováním procesorů, která má zaručit, že když se chybně napsaný program pokusí číst nebo dokonce zapisovat tam, kde kromě operačního systému nemá nikdo co pohledávat, tak dojde k přerušení, a OS ho bez milosti odstřelí jak rudoarmějec nácka. Takže jako vyjádření chyby se prostě vrací adresa úplného počátku operační paměti -> 0.
-
nulový ukazatel je standardem jazyka C definován jako ukazatel s číselnou hodnotou nula.
Proč?
To by ses musel zeptat Dennise Ritchieho.
Jenže ten to nevymyslel, vzniklo to roky před Unixem i C: https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare (https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare) ;)
Ve skutečnosti je to prasecká ojebávka, související s fungováním procesorů, která má zaručit, že když se chybně napsaný program pokusí číst nebo dokonce zapisovat tam, kde kromě operačního systému nemá nikdo co pohledávat, tak dojde k přerušení, a OS ho bez milosti odstřelí jak rudoarmějec nácka. Takže jako vyjádření chyby se prostě vrací adresa úplného počátku operační paměti -> 0.
konečne niekto, kto tomu rozumie,... :-)
-
Ve skutečnosti je to prasecká ojebávka, související s fungováním procesorů, která má zaručit, že když se chybně napsaný program pokusí číst nebo dokonce zapisovat tam, kde kromě operačního systému nemá nikdo co pohledávat, tak dojde k přerušení, a OS ho bez milosti odstřelí
Mýlíš se. Dereference NULL v C nezaručuje, že program spadne. Existuje spousta architektur, na kterých se C používá, kde čtení/zápis adresy 0 nezpůsobí pád programu. Standard C jasně definuje, že dereference NULL je undefined behavior. To znamená, že program nemusí spadnout, může se stát cokoliv. Na architekturách bez MMU nespadne, poběží normálně dál, co to ale bude dělat, to je undefined...
Koncept NULL není v C kvůli odstřelení chybných programů, je to jedna z možností, jak implementovat maybe typy (empty values). Praxe ukázala, že implementace maybe pomocí NULL nebyl úplně šťastný nápad, je to prostě historické dědictví.
-
Na architekturách bez MMU nespadne, poběží normálně dál, co to ale bude dělat, to je undefined...
No, třeba na ZX Spectru to po zavolání adresy 0x0000 poběží normálně dál, akorát s maličkým "resetem" ;D
-
No, třeba na ZX Spectru to po zavolání adresy 0x0000 poběží normálně dál, akorát s maličkým "resetem" ;D
Dobře, stále ti nedochází důsledky, takže ti to vysvětlím víc polopatě. Na architekturách s MMU dereference NULL nezaručuje, že program spadne. Protože je dereference NULL podle standardu undefined behavior, může překladač s takovou konstrukcí udělat cokoliv, klidně ji úplně vyhodit pryč a v běžícím programu vůbec neprovést. To totiž stále spadá pod definici undefined behavior a překladač to v rámci optimalizací rád udělá.
https://stackoverflow.com/questions/22847539/does-dereference-a-null-pointer-guarantee-to-crash-a-program-in-c-c
-
Protoze pak neni ta metoda ten chliv, co jsi poslal, ale neco, co se da precist a pochopit.
takže podľa tebe je jednoduchšie povedať "chcem dolnú časť žemle hamburgeru na ňom kurací rezeň, a na ňom hornú časť žemle hamburgeru" než "chcem kurací hamburger", to je teda fajn logika. Čitatelnejšie to o nič nieje, a ani to nepotrebuješ. Predsa si hamburger kupuješ ako celok. Obsah hamburgeru zaujíma len zamestnanca mcdonalda, ktorý ale vytvára celistvý "produkt" teda hamburger.
Ne, konzument API samozrejme rika "chci burger".
Ale ta implementace musi byt rozdelena na male kusy, kazdy citelny a kazdy spravne pojmenovany. Aby to pak vypadalo zhruba
burger =
(horni, dolni) <- houskaNaPul
return Burger(horni, okurka, maso, dolni)
private okurka = ...
private maso = ...
To tvoje je spis
burger =
police <- najdiPolici
housky <- police.prihradky.findFirst(\p -> p.maObrazekHousty)
houstka <- houstky.vemJednu()
if (houstka == NULL) ....
...
...
Pojmenovani jednotlivych casti ma smysl, prestoze nejsou znovupouzitelne. Kdyz to udelas, tak se stane jasne, co se deje (burger je z pulek houstky, okurky a masa), aniz by se musel nekdo prehrabovat v nejakem storadkovem bordelu.
Nemluve o tom, ze ty male pojmenovatelne casti mohou byt napr. samostatne testovatelne (coz muze i nemusi byt dobry napad vyuzit).
-
No, třeba na ZX Spectru to po zavolání adresy 0x0000 poběží normálně dál, akorát s maličkým "resetem" ;D
Dobře, stále ti nedochází důsledky, takže ti to vysvětlím víc polopatě.
To mi připomíná jak tu kdysi Jehovista prohlásil, že na to má svědky :o
Jasně, vrácení NULL ještě samo o sobě nic neudělá, je to číslo jako každé jiné. Až jeho nevhodné použití může vést k nežádoucím efektům, někdy i pyrotechnickým. Zvlášť když si někdo plete NULL a NUL :-X
Spíš si přečti tohle: https://www.lucidchart.com/techblog/2015/08/31/the-worst-mistake-of-computer-science/ (https://www.lucidchart.com/techblog/2015/08/31/the-worst-mistake-of-computer-science/)
-
Protoze pak neni ta metoda ten chliv, co jsi poslal, ale neco, co se da precist a pochopit.
takže podľa tebe je jednoduchšie povedať "chcem dolnú časť žemle hamburgeru na ňom kurací rezeň, a na ňom hornú časť žemle hamburgeru" než "chcem kurací hamburger", to je teda fajn logika. Čitatelnejšie to o nič nieje, a ani to nepotrebuješ. Predsa si hamburger kupuješ ako celok. Obsah hamburgeru zaujíma len zamestnanca mcdonalda, ktorý ale vytvára celistvý "produkt" teda hamburger.
Ne, konzument API samozrejme rika "chci burger".
Ale ta implementace musi byt rozdelena na male kusy, kazdy citelny a kazdy spravne pojmenovany. Aby to pak vypadalo zhruba
burger =
(horni, dolni) <- houskaNaPul
return Burger(horni, okurka, maso, dolni)
private okurka = ...
private maso = ...
To tvoje je spis
burger =
police <- najdiPolici
housky <- police.prihradky.findFirst(\p -> p.maObrazekHousty)
houstka <- houstky.vemJednu()
if (houstka == NULL) ....
...
...
Pojmenovani jednotlivych casti ma smysl, prestoze nejsou znovupouzitelne. Kdyz to udelas, tak se stane jasne, co se deje (burger je z pulek houstky, okurky a masa), aniz by se musel nekdo prehrabovat v nejakem storadkovem bordelu.
Nemluve o tom, ze ty male pojmenovatelne casti mohou byt napr. samostatne testovatelne (coz muze i nemusi byt dobry napad vyuzit).
i tak je to zbytočné, pretože kód máš zdokumentovaný a máš v ňom komentáre (teda vo vývojovej vetve), samozrejme do produkcie ide čistý kód... takže čitelný je i bez zbytočných "sekaní" metod/funkcií.
-
Pojmenovani jednotlivych casti ma smysl, prestoze nejsou znovupouzitelne. Kdyz to udelas, tak se stane jasne, co se deje (burger je z pulek houstky, okurky a masa), aniz by se musel nekdo prehrabovat v nejakem storadkovem bordelu.
Nemluve o tom, ze ty male pojmenovatelne casti mohou byt napr. samostatne testovatelne (coz muze i nemusi byt dobry napad vyuzit).
To si jen myslíš že to pojmenování není znovupoužitelné. Podstatné je, že identifikátory dodávají programu sémantiku, která je důležitá pro jeho pochopení.
-
To mi připomíná jak tu kdysi Jehovista prohlásil, že na to má svědky :
Ono by stačilo, kdybys znal C standard, když se vyjadřuješ (chybně) k jazyku C.
Jasně, vrácení NULL ještě samo o sobě nic neudělá, je to číslo jako každé jiné. Až jeho nevhodné použití může vést k nežádoucím efektům, někdy i pyrotechnickým. Zvlášť když si někdo plete NULL a NUL :-X
Standard C jasně definuje, co se při dereferenci NULL pointeru stane, je to UNDEFINED. Ty jsi začal valit nějaké nesmysly o tom, že NULL je v jazyce C kvůli detekci chybných programů, aby spadly. Promiň, ale to je naprostá blbost a nepochopení, proč je v C NULL. Zaprvé programy v C při dereferenci NULL spadnout nemusí (můžou dělat cokoliv), zadruhé důvod existence NULL v C je úplně jiný, je to implementace maybe typů (empty values). Že je to implementace historická a ne úplně vyhovující současným požadavkům na bezpečnost kódu, to všichni vědí.
-
Protoze pak neni ta metoda ten chliv, co jsi poslal, ale neco, co se da precist a pochopit.
takže podľa tebe je jednoduchšie povedať "chcem dolnú časť žemle hamburgeru na ňom kurací rezeň, a na ňom hornú časť žemle hamburgeru" než "chcem kurací hamburger", to je teda fajn logika. Čitatelnejšie to o nič nieje, a ani to nepotrebuješ. Predsa si hamburger kupuješ ako celok. Obsah hamburgeru zaujíma len zamestnanca mcdonalda, ktorý ale vytvára celistvý "produkt" teda hamburger.
Ne, konzument API samozrejme rika "chci burger".
Ale ta implementace musi byt rozdelena na male kusy, kazdy citelny a kazdy spravne pojmenovany. Aby to pak vypadalo zhruba
burger =
(horni, dolni) <- houskaNaPul
return Burger(horni, okurka, maso, dolni)
private okurka = ...
private maso = ...
To tvoje je spis
burger =
police <- najdiPolici
housky <- police.prihradky.findFirst(\p -> p.maObrazekHousty)
houstka <- houstky.vemJednu()
if (houstka == NULL) ....
...
...
Pojmenovani jednotlivych casti ma smysl, prestoze nejsou znovupouzitelne. Kdyz to udelas, tak se stane jasne, co se deje (burger je z pulek houstky, okurky a masa), aniz by se musel nekdo prehrabovat v nejakem storadkovem bordelu.
Nemluve o tom, ze ty male pojmenovatelne casti mohou byt napr. samostatne testovatelne (coz muze i nemusi byt dobry napad vyuzit).
i tak je to zbytočné, pretože kód máš zdokumentovaný a máš v ňom komentáre (teda vo vývojovej vetve), samozrejme do produkcie ide čistý kód... takže čitelný je i bez zbytočných "sekaní" metod/funkcií.
A I tak máš v ideálních podmínkách (ty komentáře někdo updateoval s kódem...) metrák čtení i tam, kde tě zajímá jenom základ (třebas musíš zjistit zda je v tom burgeru rajče nebo paprika).
O tom, že pak musíš skákat mezi různými úrovněmi abstrakce nemluvě.
-
... polopatě.
Nepochopils'.
Standard C jasně definuje ... UNDEFINED.
Aha.
Není jenom C. Není jenom NULL. Viz výše.
-
... polopatě.
Nepochopils'
Standard C jasně definuje ... UNDEFINED.
Aha.
Není jenom C. Není jenom NULL. Viz výše.
Aha. Takže ty píšeš nesmysly o chování NULL v C a teď to budeš obhajovat tak, že v jiných jazycích se NULL chová jinak? No to je ale překvapení, kdo by to byl čekal...
-
Taaak, hezky Vanoce vam vsem, jelikoz tomu nerozumim, tak jsem ten pravy, abych vam to vysvetlil.
Mlociku bohuzel nemas pravdu, tva funkce unsigned char* b_e vraci ukazatel na unsigned char, coz '\0' rozhodne neni. Jak tady poznamenal Neviditelny, mas stesti ze se z toho udela 0 stejne jako z NULL. Pokud neveris, zkus si zkompilovat kod, co ti posilal Neviditelny, funguje to, jak pise. Pokuds chtel v pripade, ze dostanes prazdny retezec take prazdny retezec vratit, musis to udelat jinak nez vracet nulu.
Co se tyce hamburgeru, samozrejme psat funkce (metody) co maji prilis mnoho radku je _OBVYKLE_ spatne. Pokud to jde rozdrobit, je vhodne to udelat, a to i v pripade, ze tyto rozdrobene metody budou pouzity jen jednou. Duvodem je zejmena lepsi citelnost.
-
Pokud si to dobře pamatuju, za NULL pointer se v c považuje pointer, který ukazuje "nikam" (ve smyslu není za ním skovaný žádný datový typ), jako konvence se bere, že takový pointer má hodnotu 0 (nula), tj. ukazuje na adresu 0.
(bacha, neinicializovaný pointer může ukazovat kamkoli, klidně i do existující paměti)
A zřejmě proto, aby byl jazyk c co nejjednodušší, tak jeho návrh (a pak implementace) žádné explicitní klíčové slovo pro takový pointer nedeklaruje, pak se to ojebává těmi "ex post" deklaracemi (viz v kolika hlavičkáčích je ten NULL deklarován (a jak)).
A ani papež nikomu nezabrání, aby si ve svým zdrojáku nenadeklaroval hodnotu NULL třeba na deadbeaf.
c++ (od verze 11) to řeší (systémově) novým klíčovým slovem nullptr.
'\0' je znak s hodnotou 0 (nikoli znak 0), používá se jako ukončovač c stringů.
Smutné je, že tento znak má označení ASCI NUL, nicméně pro tyto stringy se používá označení "null-terminated" string.
Velikost toho znaku '\0' je 1 znak (jeden char (8 bitů)), velikost NULL pointeru (pokud si to nikdo nepředeklaroval) je roven velikosti datového typu ukazatel (na daném železe).
(číselně mají tento znak i NULL pointer stejnou hodnotu)
PS: Že v *nixech končí pokus o dereferenci NULL pointeru segfaultem je dáno jen tím, že (tuším, že záměrně) většinou první (a tedy i s adresou 0) virtuální stránka paměti nemá namapovanou fyzickou paměť, anebo k ní user nemá přístup.
-
PS: Že v *nixech končí pokus o dereferenci NULL pointeru segfaultem je dáno jen tím, že (tuším, že záměrně) většinou první (a tedy i s adresou 0) virtuální stránka paměti nemá namapovanou fyzickou paměť, anebo k ní user nemá přístup.
To je schválně udělané proto, aby programy, které tam šáhnou, spadly...
Jinak k původní otázce: jsou jazyky, které mají syntaxi strašně jednoduchou (lisp), a pak jazyky, který ji mají docela rozvětvenou (C++). A pak je tu Java, která dlouho odolávala, ale nakonec na ni taky došlo a přibylo tam pár "složitějších" věcí (lambda funkce apod.), ale i python s chováním "yield", comprehensionama apod. se taky trošku zesložiťuje. Problém je, že jazyky postupně bobtnají s tím, jak se přidávají vlastnosti a některé vlastnosti prostě nejde přidat jinak než rozšířením syntaxe.
Jazyky, které se blíží přirozeným jazykům (COBOL?) jsou IMO ve stejné kategorii jako to C++; ono je hezké, že člověk rozumí tomu, co tam je napsané, ale bohužel to je taky většinou jediný způsob, jak to napsat. Který vás samozřejmě nenapadne, když to zrovna potřebujete a pak je to, jako když se člověku, který neumí česky, snažíte 10 různými způsoby sdělit totéž a doufáte, že alespoň někdy porozumí.
BTW: proti Perlu mi ostatní jazyky přijdou úplně v pohodě. Asi měsíc jsem se snažil zapamtovat si, jaký znak v kterém kontextu znamená co a pak jsem to vzdal....
-
Podle mne je u naprosté většiny programovacích jazyků syntaxe naopak velice jednoduchá! Mám spíše dojem, že programovací jazyky, které se snaží podobat mluvenému lidskému slovu jsou mnohem méně přehledné a tudíž hůře čitelné.
-
Podle mne je u naprosté většiny programovacích jazyků syntaxe naopak velice jednoduchá! Mám spíše dojem, že programovací jazyky, které se snaží podobat mluvenému lidskému slovu jsou mnohem méně přehledné a tudíž hůře čitelné.
Syntaxe je složitá například u Cobolu. Stovky klíčových slov jsou z dnešního pohledu zvráceností. Ani nevím, kolik jich má Visual Basic, ale asi také dost. Když jsem se učil Pascal, tak jich bylo cca 40. To už se celkem dalo. Jazyk C je v tomto ohledu minimalistický, ale z velké části toho dosahuje používáním symbolů. Stále však nedosahuje jednoduchosti Lispu, jehož syntaxe vlastně obsahuje jen závorky. Dodnes lituji, že jsem se ho nezačal učit dříve, protože mi poskytl nový pohled na programování v ostatních jazycích.
-
Mne syntaxe prog. jazyků přijde jednoduchá.
-
Podle mne je u naprosté většiny programovacích jazyků syntaxe naopak velice jednoduchá! Mám spíše dojem, že programovací jazyky, které se snaží podobat mluvenému lidskému slovu jsou mnohem méně přehledné a tudíž hůře čitelné.
moje slová
-
vy ste schopný i autorov jazyka C prehovoriť že v ich jazyku je NULL to isté čo '\0' ... smutné, hlavne že oni sami píšu že to to isté nieje.
Fakt?
madcat@The-Raza ~/Devel/zzz # cat n.c
#include <stdio.h>
int main()
{
printf("Equals? %s\n", (NULL == '\0') ? "Yes" : "No");
return 0;
}
madcat@The-Raza ~/Devel/zzz # clang -Wall -Wextra -pedantic n.c -o n
madcat@The-Raza ~/Devel/zzz # ./n
Equals? Yes
No nic, mír s vámi...
Chtelo by to pouzit vyzralejsi prekladac a ne nejaky trapny pokus o nej :)
$ gcc -Wall -Wextra -pedantic n.c -o n
n.c: In function ‘main’:
n.c:4:38: warning: comparison between pointer and zero character constant [-Wpointer-compare]
printf("Equals? %s\n", (NULL == '\0') ? "Yes" : "No");
^~
In file included from /usr/include/_G_config.h:15:0,
from /usr/include/libio.h:31,
from /usr/include/stdio.h:41,
from n.c:1:
n.c:4:33: note: did you mean to dereference the pointer?
printf("Equals? %s\n", (NULL == '\0') ? "Yes" : "No");
Clang - na rozdíl od GCC - zase správně varuje, že return '\0' z funkce, která vrací char * je potenciální chyba; GCC v tomto případě mlčí. To ale nemá žádný vliv na to, jak takový kód bude fungovat. NULL a '\0' se budou efektivně lišit jen tehdy, pokud bude NULL definováno na něco jiného než (void *)0, což jsem chtěl ukázat.
To je ale pravda jenom pro porovnani, '\0' a NULL budou mit hodne pravdepodobne jinou delku, pokud bude napr. funkce s promennym poctem argumentu zakoncena NULL (hojne pouzivano), nebude to pri zavolani s '\0' fungovat, protoze bude mit pravdepodobne kratsi delku.
-
...
To je ale pravda jenom pro porovnani, '\0' a NULL budou mit hodne pravdepodobne jinou delku, pokud bude napr. funkce s promennym poctem argumentu zakoncena NULL (hojne pouzivano), nebude to pri zavolani s '\0' fungovat, protoze bude mit pravdepodobne kratsi delku.
Do mufloních vemen, vy tomu dáváte... '\0' má velikost charu, NULL má velikost ukazatele; to tu nikdo nerozporoval. Pokud je přetypuješ na stejný typ - což ten Mlocikův kód, který tuhle dávící soutěž odstartoval implicitně dělá, protože je napsán v C - bude mít výsledek pro oba přesně stejnou hodnotu i velikost. To je, oč tu celou dobu šlo. Jasné, soudruzi?
-
No dobre, na tom se muzeme urcite shodnout (ze '\0' == NULL == 0), alespon pro C99 a vsechny dnes pouzivane architektury, ja jenom reagoval na to
NULL a '\0' se budou efektivně lišit jen tehdy, pokud bude NULL definováno na něco jiného než (void *)0, což jsem chtěl ukázat.
kdo se ma vyznat v tom co se tady puvodne resilo, kdyz to ma 10 stranek.
-
... '\0' má velikost charu, NULL má velikost ukazatele; to tu nikdo nerozporoval. Pokud je přetypuješ na stejný typ - což ten Mlocikův kód, který tuhle dávící soutěž odstartoval implicitně dělá, protože je napsán v C - bude mít výsledek pro oba přesně stejnou hodnotu i velikost. To je, oč tu celou dobu šlo. Jasné, -censored-?
Takže se celou dobu bavíme o implicitní přetypování, které je tolik vyčítáno např. PHP, ale v C je tak nějak tolerováno. Nízkoúrovňovým jazykům (mezi něž patří i C) je toho tolerováno docela dost a zřejmě je to tak správně.
-
... '\0' má velikost charu, NULL má velikost ukazatele; to tu nikdo nerozporoval. Pokud je přetypuješ na stejný typ - což ten Mlocikův kód, který tuhle dávící soutěž odstartoval implicitně dělá, protože je napsán v C - bude mít výsledek pro oba přesně stejnou hodnotu i velikost. To je, oč tu celou dobu šlo. Jasné, -censored-?
Takže se celou dobu bavíme o implicitní přetypování, které je tolik vyčítáno např. PHP, ale v C je tak nějak tolerováno. Nízkoúrovňovým jazykům (mezi něž patří i C) je toho tolerováno docela dost a zřejmě je to tak správně.
Pokud vím, implicitní konverze v c tu nikdo nepopíral, jsou v popisu jazyka popsány a kdo s nimi počítá, neměl by mít problémy...
-
(Ale není. (Složitá. (Ta syntaxe. (Těch jazyků. (Programovacích.)))))
-
(Ale není. (Složitá. (Ta syntaxe. (Těch jazyků. (Programovacích.)))))
V Lispu je vlastně jen jedno syntaktické pravidlo - závorky musí být párové. Ovšem z toho tvého zápisu by zřejmě byl zmatený i Mistr Yoda.
-
(Ale není. (Složitá. (Ta syntaxe. (Těch jazyků. (Programovacích.)))))
a to jako píšeš tie zátvorky náhodne? toto nemá logiku... zato zátvorky v Céčku, JS, Scale, Go, atd, zmysel majú.
-
(Ale není. (Složitá. (Ta syntaxe. (Těch jazyků. (Programovacích.)))))
a to jako píšeš tie zátvorky náhodne? toto nemá logiku... zato zátvorky v Céčku, JS, Scale, Go, atd, zmysel majú.
Tohle jsou lispové závorky. Lisp to normálně akceptuje jako platný výraz. Vyzkoušeno.
-
(Ale není. (Složitá. (Ta syntaxe. (Těch jazyků. (Programovacích.)))))
a to jako píšeš tie zátvorky náhodne? toto nemá logiku... zato zátvorky v Céčku, JS, Scale, Go, atd, zmysel majú.
Tohle jsou lispové závorky. Lisp to normálně akceptuje jako platný výraz. Vyzkoušeno.
Díky za varovanie, zapisujem si ďalší jazyk na čierny papier.
-
(Ale není. (Složitá. (Ta syntaxe. (Těch jazyků. (Programovacích.)))))
a to jako píšeš tie zátvorky náhodne? toto nemá logiku... zato zátvorky v Céčku, JS, Scale, Go, atd, zmysel majú.
Tohle jsou lispové závorky. Lisp to normálně akceptuje jako platný výraz. Vyzkoušeno.
Díky za varovanie, zapisujem si ďalší jazyk na čierny papier.
...černou propiskou ::)
-
(Ale není. (Složitá. (Ta syntaxe. (Těch jazyků. (Programovacích.)))))
a to jako píšeš tie zátvorky náhodne? toto nemá logiku... zato zátvorky v Céčku, JS, Scale, Go, atd, zmysel majú.
Tohle jsou lispové závorky. Lisp to normálně akceptuje jako platný výraz. Vyzkoušeno.
Díky za varovanie, zapisujem si ďalší jazyk na čierny papier.
V jiném jazyce, například v Javascriptu, bys ten výraz zapsal takto:
Ale(není_, Složitá_(Ta(syntaxe_, Těch(jazyků_, Programovacích_()))))Nemohu za to, že tam Lama napsal tečky, při přepisu jsem je nahradil podtržítky, aby to bylo i v Javascriptu syntakticky správně. Takhle blbě se však neprogramuje ani v Javascriptu, ani v Lispu - sémantiku oba zápisy zcela postrádají.
Když porovnám tyto dva zápisy, tak ten lispový mi připadá mnohem přehlednější. V zápisu nepoužívá čárky a závorka se píše před názvem funkce. Elegance sama. Navíc je ten lispový zápis tak univerzální, že s ním můžeš definovat nejen program, ale i data. Program může za běhu sám sebe modifikovat.
-
Vsichni sardel. Kule.
Tyhle zavorky jsou peklo at uz to jsou S expressions v lispu nebo M expressions nebo obdobnej zapis v algol derivatech (tj. 90% toho co znate).
Kolikrat se vam stalo ze napisete nejakou funkci praveJsemNecoSpocital(x) a chcete to poslat do druhy funkce. Jako debil musim psat druhaFunkce(praveJsemNecoSpocital(x)). Musim hloupe psat kus funkce pred tim puboenim kodem a zavirat zavorku za kodem. Pitomost. Obzvlast kdyz pracuju v REPL modu.
Alespon to muzu v tech algolech ulozit do promenny.
velkyHovno = druhaFunkce(praveJsemNecoSpocital(x))
Peklo je to v SQL, kde aspon v tech novych existuje ochcavka na promenny jmenem CTE, jinak je to absolutne nepouzitelnej pekac.
Idealni zapis je konkatenativni, tj. skladani programu za nebo pred sebe. Tim se vyhnu vsem temhke blbym promennym a psani zavorek jak debo.
Napr. v shellu
cat x | praveJsemNecoSpocital | druhaFunkce > velkyHovno.txt
Nebo jq
x | praveJsemNecoSpocital | druhaFunkce | . as $velkyHovno
Nebo forth
x praveJsemNecoSpocital druhaFunkce velkyHovno !
Nebo APL a derivaty, kde se pise prefixe. misto postfixem
velkyHovno: druhaFunkce praveJsemNecoSpocital x
-
Vsichni sardel. Kule.
Tyhle zavorky jsou peklo at uz to jsou S expressions v lispu nebo M expressions nebo obdobnej zapis v algol derivatech (tj. 90% toho co znate).
Kolikrat se vam stalo ze napisete nejakou funkci praveJsemNecoSpocital(x) a chcete to poslat do druhy funkce. Jako debil musim psat druhaFunkce(praveJsemNecoSpocital(x)). Musim hloupe psat kus funkce pred tim puboenim kodem a zavirat zavorku za kodem. Pitomost. Obzvlast kdyz pracuju v REPL modu.
Alespon to muzu v tech algolech ulozit do promenny.
velkyHovno = druhaFunkce(praveJsemNecoSpocital(x))
Peklo je to v SQL, kde aspon v tech novych existuje ochcavka na promenny jmenem CTE, jinak je to absolutne nepouzitelnej pekac.
Idealni zapis je konkatenativni, tj. skladani programu za nebo pred sebe. Tim se vyhnu vsem temhke blbym promennym a psani zavorek jak debo.
Napr. v shellu
cat x | praveJsemNecoSpocital | druhaFunkce > velkyHovno.txt
Nebo jq
x | praveJsemNecoSpocital | druhaFunkce | . as $velkyHovno
Nebo forth
x praveJsemNecoSpocital druhaFunkce velkyHovno !
Nebo APL a derivaty, kde se pise prefixe. misto postfixem
velkyHovno: druhaFunkce praveJsemNecoSpocital x
Ty jsi kokot.
cat x jsou 4 znaky a dlasi 2 znaky jsou svislice, v tvem prikladu jsou 4 zavorky.
zavorky jsou opravdu zlo, ty hnupe.
-
Vsichni sardel. Kule.
Tyhle zavorky jsou peklo at uz to jsou S expressions v lispu nebo M expressions nebo obdobnej zapis v algol derivatech (tj. 90% toho co znate).
Kolikrat se vam stalo ze napisete nejakou funkci praveJsemNecoSpocital(x) a chcete to poslat do druhy funkce. Jako debil musim psat druhaFunkce(praveJsemNecoSpocital(x)). Musim hloupe psat kus funkce pred tim puboenim kodem a zavirat zavorku za kodem. Pitomost. Obzvlast kdyz pracuju v REPL modu.
Alespon to muzu v tech algolech ulozit do promenny.
velkyHovno = druhaFunkce(praveJsemNecoSpocital(x))
Peklo je to v SQL, kde aspon v tech novych existuje ochcavka na promenny jmenem CTE, jinak je to absolutne nepouzitelnej pekac.
Idealni zapis je konkatenativni, tj. skladani programu za nebo pred sebe. Tim se vyhnu vsem temhke blbym promennym a psani zavorek jak debo.
Napr. v shellu
cat x | praveJsemNecoSpocital | druhaFunkce > velkyHovno.txt
Nebo jq
x | praveJsemNecoSpocital | druhaFunkce | . as $velkyHovno
Nebo forth
x praveJsemNecoSpocital druhaFunkce velkyHovno !
Nebo APL a derivaty, kde se pise prefixe. misto postfixem
velkyHovno: druhaFunkce praveJsemNecoSpocital x
Všichni kolem jsou debilové, ale s funkcemi víc argumentů tě počítat nenapadlo...
-
Napr. v shellu
cat x | praveJsemNecoSpocital | druhaFunkce > velkyHovno.txt
Všichni kolem jsou debilové, ale s funkcemi víc argumentů tě počítat nenapadlo...
Tak zrovna u shellu těch závorek obvykle není moc potřeba, ani když je těch parametrů víc. Akorát všichni víme, jak je v něm snadné střelit se do nohy.
-
Napr. v shellu
cat x | praveJsemNecoSpocital | druhaFunkce > velkyHovno.txt
Všichni kolem jsou debilové, ale s funkcemi víc argumentů tě počítat nenapadlo...
Tak zrovna u shellu těch závorek obvykle není moc potřeba, ani když je těch parametrů víc. Akorát všichni víme, jak je v něm snadné střelit se do nohy.
Bacha, nemichat parametry prikazu a jejich a STDIN/STDOUT.
-
Všichni kolem jsou debilové, ale s funkcemi víc argumentů tě počítat nenapadlo...
Já se k tomu náhodou přidávám. Pipe operátor ("|>"), který mívají funkcionální jazyky (např. F#, Elixir. Haskell má podobné "$") je neuvěřitelně návykový. Hlavně proto, že se kód čte zleva doprava a ne obráceně. Funkce více argumentů nejsou větší problém. Osobně jsem si na to hodně zvykl a přijde mi to daleko čitenější než haskellovské skládání využívající curryfikace (YMMV).
list = ["a", "b", "c", "d"]
list |> Enum.reverse() |> Enum.join("/")
# vysledek: "d/c/b/a"
versus
list = ["a", "b", "c", "d"]
Enum.join(Enum.reverse(list), "/")
# vysledek: "d/c/b/a"
(obojí Elixir)
-
Pro porovnání totéž ve Smalltalku:
list := #( 'a' 'b' 'c' 'd' ).
list reversed joinUsing: '/'.
myslím, že tam je to takhle ještě krapet jednodušší
-
Pridam pro porovnani clojure:
(def letters `("a" "b" "c" "d"))
(->> letters reverse (join "/"))
-
Všichni kolem jsou debilové, ale s funkcemi víc argumentů tě počítat nenapadlo...
Já se k tomu náhodou přidávám. Pipe operátor ("|>"), který mívají funkcionální jazyky (např. F#, Elixir. Haskell má podobné "$") je neuvěřitelně návykový. Hlavně proto, že se kód čte zleva doprava a ne obráceně. Funkce více argumentů nejsou větší problém. Osobně jsem si na to hodně zvykl a přijde mi to daleko čitenější než haskellovské skládání využívající curryfikace (YMMV).
list = ["a", "b", "c", "d"]
list |> Enum.reverse() |> Enum.join("/")
# vysledek: "d/c/b/a"
versus
list = ["a", "b", "c", "d"]
Enum.join(Enum.reverse(list), "/")
# vysledek: "d/c/b/a"
(obojí Elixir)
Mne $ docela prirostl k srdci, ale vzdy jsem ho chapal jen jako mnohdy sikovnou pomucku a jsem rad, ze "default" je jinak.
Btw - ono je docela zajimave uvazovat o tom, ktere poradi je "vhodnejsi". S vnejsi aplikaci vlevo je zase nejvic po ruce "nejdulezitejsi" operace.
-
Všichni kolem jsou debilové, ale s funkcemi víc argumentů tě počítat nenapadlo...
Já se k tomu náhodou přidávám. Pipe operátor ("|>"), který mívají funkcionální jazyky (např. F#, Elixir. Haskell má podobné "$") je neuvěřitelně návykový. Hlavně proto, že se kód čte zleva doprava a ne obráceně. Funkce více argumentů nejsou větší problém. Osobně jsem si na to hodně zvykl a přijde mi to daleko čitenější než haskellovské skládání využívající curryfikace (YMMV).
list = ["a", "b", "c", "d"]
list |> Enum.reverse() |> Enum.join("/")
# vysledek: "d/c/b/a"
versus
list = ["a", "b", "c", "d"]
Enum.join(Enum.reverse(list), "/")
# vysledek: "d/c/b/a"
(obojí Elixir)
Mne $ docela prirostl k srdci, ale vzdy jsem ho chapal jen jako mnohdy sikovnou pomucku a jsem rad, ze "default" je jinak.
Btw - ono je docela zajimave uvazovat o tom, ktere poradi je "vhodnejsi". S vnejsi aplikaci vlevo je zase nejvic po ruce "nejdulezitejsi" operace.
IMO pro čisté výrazy klasický zápis tak jak se učí na ZŠ a "podle pořadí vyhodnocení" pro výrazy s vedlejšíma účinkama
-
Všichni kolem jsou debilové, ale s funkcemi víc argumentů tě počítat nenapadlo...
Já se k tomu náhodou přidávám. Pipe operátor ("|>"), který mívají funkcionální jazyky (např. F#, Elixir. Haskell má podobné "$") je neuvěřitelně návykový. Hlavně proto, že se kód čte zleva doprava a ne obráceně. Funkce více argumentů nejsou větší problém. Osobně jsem si na to hodně zvykl a přijde mi to daleko čitenější než haskellovské skládání využívající curryfikace (YMMV).
list = ["a", "b", "c", "d"]
list |> Enum.reverse() |> Enum.join("/")
# vysledek: "d/c/b/a"
versus
list = ["a", "b", "c", "d"]
Enum.join(Enum.reverse(list), "/")
# vysledek: "d/c/b/a"
(obojí Elixir)
A takto to má Python (list je klicove slovo):
lst = ['a', 'b', 'c', 'd']
'/'.join(reversed(lst))
-
'\0' je znak s hodnotou 0 (nikoli znak 0), používá se jako ukončovač c stringů.
Smutné je, že tento znak má označení ASCI NUL, nicméně pro tyto stringy se používá označení "null-terminated" string.
Velikost toho znaku '\0' je 1 znak (jeden char (8 bitů)), velikost NULL pointeru (pokud si to nikdo nepředeklaroval) je roven velikosti datového typu ukazatel (na daném železe)
(číselně mají tento znak i NULL pointer stejnou hodnotu)
Velkost jedneho charu 1 jeden bajt, jeden bajt nemusi mat 8 bitov. ;-)
-
'\0' je znak s hodnotou 0 (nikoli znak 0), používá se jako ukončovač c stringů.
Smutné je, že tento znak má označení ASCI NUL, nicméně pro tyto stringy se používá označení "null-terminated" string.
Velikost toho znaku '\0' je 1 znak (jeden char (8 bitů)), velikost NULL pointeru (pokud si to nikdo nepředeklaroval) je roven velikosti datového typu ukazatel (na daném železe)
(číselně mají tento znak i NULL pointer stejnou hodnotu)
Velkost jedneho charu 1 jeden bajt, jeden bajt nemusi mat 8 bitov. ;-)
Ze char nemusi byt byte, tomu bych veril, ale ze byte neni 8 bitu, to bych rad vedel kde.
-
Všichni kolem jsou debilové, ale s funkcemi víc argumentů tě počítat nenapadlo...
Já se k tomu náhodou přidávám. Pipe operátor ("|>"), který mívají funkcionální jazyky (např. F#, Elixir. Haskell má podobné "$") je neuvěřitelně návykový. Hlavně proto, že se kód čte zleva doprava a ne obráceně. Funkce více argumentů nejsou větší problém. Osobně jsem si na to hodně zvykl a přijde mi to daleko čitenější než haskellovské skládání využívající curryfikace (YMMV).
list = ["a", "b", "c", "d"]
list |> Enum.reverse() |> Enum.join("/")
# vysledek: "d/c/b/a"
versus
list = ["a", "b", "c", "d"]
Enum.join(Enum.reverse(list), "/")
# vysledek: "d/c/b/a"
(obojí Elixir)
Mne $ docela prirostl k srdci, ale vzdy jsem ho chapal jen jako mnohdy sikovnou pomucku a jsem rad, ze "default" je jinak.
Btw - ono je docela zajimave uvazovat o tom, ktere poradi je "vhodnejsi". S vnejsi aplikaci vlevo je zase nejvic po ruce "nejdulezitejsi" operace.
IMO pro čisté výrazy klasický zápis tak jak se učí na ZŠ a "podle pořadí vyhodnocení" pro výrazy s vedlejšíma účinkama
Zbytecna komplikace. V APL jazycich neexistuje precedence operatoru, coz masivne zjednodusuje jazyk. Napr.
5 * 4 + 3
Vyhodnoti zprava doleva (5 * (4 + (3))). Otazka jestli lepsi zprava doleva nebo naopak je podle me vec preference.
V APL je to zprava protoze dava smysl prirazovat do promennych zapsanych vlevo.
X: 5 * 4 + 3
Misto
3 + 4 * 5 as X
Tomuhke se rika 'konkatenativni' jazyk. Skladas programy vedle sebe. Muses upravovat precedenci zavorkama dle libosti.
Vice argumetu resis bezne v techto jazycich. V shellu, haskellu nebo forthu to neni problem. V jazyce na kterym pracuju ja se to resi tak ze kazda funkce ma prave dva argumenty. Levej a pravej. Jako scitani a nasobeni napr.
Vychozi precedence operatoru je pouze ucebni pomucka pro prvnacky aby je nematly zavorky.
-
'\0' je znak s hodnotou 0 (nikoli znak 0), používá se jako ukončovač c stringů.
Smutné je, že tento znak má označení ASCI NUL, nicméně pro tyto stringy se používá označení "null-terminated" string.
Velikost toho znaku '\0' je 1 znak (jeden char (8 bitů)), velikost NULL pointeru (pokud si to nikdo nepředeklaroval) je roven velikosti datového typu ukazatel (na daném železe)
(číselně mají tento znak i NULL pointer stejnou hodnotu)
Velkost jedneho charu 1 jeden bajt, jeden bajt nemusi mat 8 bitov. ;-)
Ze char nemusi byt byte, tomu bych veril, ale ze byte neni 8 bitu, to bych rad vedel kde.
DSP, pozrite sa na makro CHAR_BIT ;-)
-
'\0' je znak s hodnotou 0 (nikoli znak 0), používá se jako ukončovač c stringů.
Smutné je, že tento znak má označení ASCI NUL, nicméně pro tyto stringy se používá označení "null-terminated" string.
Velikost toho znaku '\0' je 1 znak (jeden char (8 bitů)), velikost NULL pointeru (pokud si to nikdo nepředeklaroval) je roven velikosti datového typu ukazatel (na daném železe)
(číselně mají tento znak i NULL pointer stejnou hodnotu)
Velkost jedneho charu 1 jeden bajt, jeden bajt nemusi mat 8 bitov. ;-)
Ze char nemusi byt byte, tomu bych veril, ale ze byte neni 8 bitu, to bych rad vedel kde.
DSP, pozrite sa na makro CHAR_BIT ;-)
Tam se nikde nehovori, ze byte neni 8 bitu.
-
'\0' je znak s hodnotou 0 (nikoli znak 0), používá se jako ukončovač c stringů.
Smutné je, že tento znak má označení ASCI NUL, nicméně pro tyto stringy se používá označení "null-terminated" string.
Velikost toho znaku '\0' je 1 znak (jeden char (8 bitů)), velikost NULL pointeru (pokud si to nikdo nepředeklaroval) je roven velikosti datového typu ukazatel (na daném železe)
(číselně mají tento znak i NULL pointer stejnou hodnotu)
Velkost jedneho charu 1 jeden bajt, jeden bajt nemusi mat 8 bitov. ;-)
Ze char nemusi byt byte, tomu bych veril, ale ze byte neni 8 bitu, to bych rad vedel kde.
DSP, pozrite sa na makro CHAR_BIT ;-)
Tam se nikde nehovori, ze byte neni 8 bitu.
https://en.cppreference.com/w/cpp/types/climits
pozrite sa na DSP ak viete co to je. A veci, o ktorej vy rozpravate sa spravne nazyva oktet. https://en.wikipedia.org/wiki/Octet_(computing)
-
...
Velkost jedneho charu 1 jeden bajt, jeden bajt nemusi mat 8 bitov. ;-)
:o
Šmarjá.
-
...
https://en.cppreference.com/w/cpp/types/climits
pozrite sa na DSP ak viete co to je. A veci, o ktorej vy rozpravate sa spravne nazyva oktet. https://en.wikipedia.org/wiki/Octet_(computing)
;D
To by mne zajímalo, co si tím kompenzuješ...
-
pozrite sa na DSP ak viete co to je. A veci, o ktorej vy rozpravate sa spravne nazyva oktet. https://en.wikipedia.org/wiki/Octet_(computing)
Bajt sice na speciálních procesorech může mít jinou velikost než 8 bitů, ale obecně je vnímáno, že bajt a oktet jsou synonyma.
-
pozrite sa na DSP ak viete co to je. A veci, o ktorej vy rozpravate sa spravne nazyva oktet. https://en.wikipedia.org/wiki/Octet_(computing)
Bajt sice na speciálních procesorech může mít jinou velikost než 8 bitů, ale obecně je vnímáno, že bajt a oktet jsou synonyma.
Napisali ste prave oxymoron...
-
...
https://en.cppreference.com/w/cpp/types/climits
pozrite sa na DSP ak viete co to je. A veci, o ktorej vy rozpravate sa spravne nazyva oktet. https://en.wikipedia.org/wiki/Octet_(computing)
;D
To by mne zajímalo, co si tím kompenzuješ...
Tvoju nevedomost ;-)
-
Ehm: https://en.wikipedia.org/wiki/Byte (https://en.wikipedia.org/wiki/Byte)
The size of the byte has historically been hardware dependent and no definitive standards existed that mandated the size – byte-sizes from 1 to 48 bits are known to have been used in the past. Early character encoding systems often used six bits, and machines using six-bit and nine-bit bytes were common into the 1960s.
Osmibitový bajt přišel až s IBM System/360, což by pravidelní čtenáři rootu měli vědět.
-
Syntaxe přirozených jazyků je výrazně složitější než syntaxe programovacích jazyků.
V jakem smyslu? Že není bezkontextová?
-
Všichni kolem jsou debilové, ale s funkcemi víc argumentů tě počítat nenapadlo...
Já se k tomu náhodou přidávám. Pipe operátor ("|>"), který mívají funkcionální jazyky (např. F#, Elixir. Haskell má podobné "$") je neuvěřitelně návykový. Hlavně proto, že se kód čte zleva doprava a ne obráceně. Funkce více argumentů nejsou větší problém. Osobně jsem si na to hodně zvykl a přijde mi to daleko čitenější než haskellovské skládání využívající curryfikace (YMMV).
list = ["a", "b", "c", "d"]
list |> Enum.reverse() |> Enum.join("/")
# vysledek: "d/c/b/a"
versus
list = ["a", "b", "c", "d"]
Enum.join(Enum.reverse(list), "/")
# vysledek: "d/c/b/a"
(obojí Elixir)
A takto to má Python (list je klicove slovo):
lst = ['a', 'b', 'c', 'd']
'/'.join(reversed(lst))
Ruby
vals = ['a', 'b', 'c', 'd']
joined = vals.reverse.join("/")
p joined
JavaScript
let vals= ['a', 'b', 'c', 'd'];
let joined = vals.reverse().join('/');
console.log(joined);
Groovy
def vals = ['a', 'b', 'c', 'd']
def joined = vals.reverse().join('/')
println(joined)
Java
var vals = List.of("a", "b", "c", "d");
var joined = vals.stream().sorted(Collections.reverseOrder())
.collect(Collectors.joining("/"));
System.out.println(joined);
Kotlin
val nums = listOf('a', 'b', 'c', 'd')
val joined = nums.reversed().joinToString("/")
println(joined)
PHP
$list = ["a", "b", "c", "d"];
$joined = implode("/", array_reverse($list));
print_r($joined);
Tcl
set vals {a b c d}
set joined [join [lreverse $vals] "/"]
puts $joined
Perl 6
my $vals = <a b c d>;
my $joined = join('/', reverse($vals));
say $joined;
C#
Vie niekto pre C# lepšie riešenie? Ja som sa domotal
len k takémuto škaredému:
var vals = new List<char> {'a', 'b', 'c', 'd'};
vals.Reverse();
Console.WriteLine(string.Join('/'));
Najkomplikovanejšie to má klasicky Java :), najbohatšie možnosti som postrehol pri Kotline. Viaceré jazyky to majú elegantné.
-
skoda ze Wirth nedotahnul PL/O do stavu plnohodnotneho jazyka, kompletni ucebnice na 17 strankach je uzasna ale k nicemu (je to hodne osekana verze pascalu)
https://www.dropbox.com/s/iy1xm8bhd38x8r0/PL0%20User%27s%20Manual.pdf?dl=0
-
skoda ze Wirth nedotahnul PL/O do stavu plnohodnotneho jazyka, kompletni ucebnice na 17 strankach je uzasna ale k nicemu (je to hodne osekana verze pascalu)
https://www.dropbox.com/s/iy1xm8bhd38x8r0/PL0%20User%27s%20Manual.pdf?dl=0
Tím dotaženým jazykem je Oberon nebo Oberon/0
-
Do mufloních vemen, vy tomu dáváte... '\0' má velikost charu, NULL má velikost ukazatele; to tu nikdo nerozporoval. Pokud je přetypuješ na stejný typ - což ten Mlocikův kód, který tuhle dávící soutěž odstartoval implicitně dělá, protože je napsán v C - bude mít výsledek pro oba přesně stejnou hodnotu i velikost. To je, oč tu celou dobu šlo. Jasné, soudruzi?
Ty jsi někde na mufloním vemenu měl neviditelně natisknutý ANCI S standard, že tak mudruješ?
1) Víš, jak funguje v C standardní string? Je to pole znaků v paměti, kde jsou za sebou ASCII znaky a poslední je NUL* (hodnota 0). Pokud je string prázdný, tak znak[0] == 0.
2) Víš, jak dostaneš string do funkce? Dáš mu odkaz na znak[0], konec si najde tak, že prostě narazí na 0. Hotovo.
3) NULL má hodnotu 0 proto, že v podmínce se jednoduše pozná, jestli je pointer platný**
No a teď příklad. Něco jednoduchýho, C na Z80. Program zaříná na adrese 0, skočí třeba na adresu 0x200. Takže od adresy 0x0 máš C3-00-20-... Pak máme třeba v RAMce (adresa řekněme 0x9876) pole pro string, který je prázdný ( byte s adresou 0x9876 == 0).
Pokud chci vrátit prázdný string, vrátím 0x9876. Funkce dereferuje pointer, vidí 0 a nic nedělá.
Pokud mu vrátím nulu (jako pointer), funkce vidí pole 0xC3-0x00 - zpracuje nesmyslný znak nebo nepozná, že jde o prázdný string a spustí nějakou akci.
Takže je úplně šumák, jestli NULL == NUL == 0. Jde o to, kdo, kde a jak to použije. char* str = 0 není prázdný string, ale nepatný string!!!***
-------
* Je to NUL proto, že ASCII používá tři znaky pro označení, například zvonek u dálnopisu - bell - má označení BEL. Stejně tak první znak je null, ale autoři ASCII to stáhli na NUL.
** C nemá booleovský typ, kontroluje jenom je/není 0 - mrknout na zero flag CPU je jednoduchý a efektivní
*** takže třeba já osobně ho používám jenom jako indikaci selhání - v debugu neprojde asercí
-
Syntaxe přirozených jazyků je výrazně složitější než syntaxe programovacích jazyků.
V jakem smyslu? Že není bezkontextová?
To samozřejmě taky, ale reálně jsou přirozené jazyky složitější v jakémkoli smyslu, na který si vzpomeneš, protože to nejsou formální jazyky. Zkus si vzít třeba českou syntaxi a formálně ji popsat tak, aby podle toho popisu bylo možné strojově jednoznačně posoudit syntaktickou správnost libovolného textu a určit syntaktický význam každého prvku textu. To prakticky nejde. Ve srovnání s tím je jakýkoli programovací jazyk naprosto triviální matematická konstrukce.
-
Syntaxe přirozených jazyků je výrazně složitější než syntaxe programovacích jazyků.
V jakem smyslu? Že není bezkontextová?
To samozřejmě taky, ale reálně jsou přirozené jazyky složitější v jakémkoli smyslu, na který si vzpomeneš, protože to nejsou formální jazyky. Zkus si vzít třeba českou syntaxi a formálně ji popsat tak, aby podle toho popisu bylo možné strojově jednoznačně posoudit syntaktickou správnost libovolného textu a určit syntaktický význam každého prvku textu. To prakticky nejde. Ve srovnání s tím je jakýkoli programovací jazyk naprosto triviální matematická konstrukce.
Ono to jde, ale složitějšími prostředky. Třeba Watson od IBM to umí (pro angličtinu) pomocí slot grammars. Čeština má debilně volný slovosled, možná až na shluky příklonek, ale zase bohatší tvarosloví, což se navzájem vykompenzuje.
-
Ono to jde, ale složitějšími prostředky. Třeba Watson od IBM to umí (pro angličtinu) pomocí slot grammars. Čeština má debilně volný slovosled, možná až na shluky příklonek, ale zase bohatší tvarosloví, což se navzájem vykompenzuje.
Proč debilně? Chápu to spíš jako výhodu. Zas tak volný není - ty možné kombinace mají trochu jiné významové zabarvení.
-
Ono to jde, ale složitějšími prostředky. Třeba Watson od IBM to umí (pro angličtinu) pomocí slot grammars. Čeština má debilně volný slovosled, možná až na shluky příklonek, ale zase bohatší tvarosloví, což se navzájem vykompenzuje.
Ten Watson si v anglictine poradi i s Frazovymi slovesy pode kontextu vety/odstavce ?
-
Ono to jde, ale složitějšími prostředky. Třeba Watson od IBM to umí (pro angličtinu) pomocí slot grammars. Čeština má debilně volný slovosled, možná až na shluky příklonek, ale zase bohatší tvarosloví, což se navzájem vykompenzuje.
Ten Watson si v anglictine poradi i s Frazovymi slovesy pode kontextu vety/odstavce ?
Ano, poradí. Watson analyzuje sémantiku podle aktuálního větného členění. S frázovými slovesy to nesouvisí, všechna slovesa a jejich doplnění se interpretují podle kontextu. Mimochodem je to napsané v Prologu.
-
Ono to jde, ale složitějšími prostředky. Třeba Watson od IBM to umí (pro angličtinu) pomocí slot grammars. Čeština má debilně volný slovosled, možná až na shluky příklonek, ale zase bohatší tvarosloví, což se navzájem vykompenzuje.
Zas tak volný není - ty možné kombinace mají trochu jiné významové zabarvení.
Je syntakticky zcela volný kromě shluků příklonek. Sémantiku slovosled nijak neovlivňuje, vliv má jen na interpretaci v kontextu (podle aktuálního větného členění a kontextové vázanosti slov). Vzájemné ovlivňování slovosledu a kontextuální interpretace je rozsáhlá věda, píšou se o tom dizertace, ovšem bez znalosti několika typologicky odlišných jazyků si v tom člověk neškrtne. Například japonština vyjadřuje aktuální větné členění místo slovosledu příklonnými částicemi. I ta vysmívaná angličtina má ovšem příslušné slovosledné prostředky, viz například přesmyčka v “In the garden was a fountain”.