• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    XCHAOSANSI C/C99 (specifikace), GNU C (gcc, glibc), Tiny C (tcc) a POSIX - ne nutně C++,g++,libstdc++ nebo Win32 API
    XCHAOS
    XCHAOS --- ---
    JS C Compiler - A C compiler written in client side javascript
    https://www.youtube.com/watch?v=fzHvFn-46NM

    XCHAOS
    XCHAOS --- ---
    REDGUY: dobře - i když jsme si vyjasnili, že "naprostá většina programátorů dnes už nechápe, co jejich program přesně dělá", tak pořád existuje část programátorů, kterým dělá dobře iluze deterministického prostředí a tu jim jazyk C poskytuje.

    kromě toho, některé "objekty v paměti", typu null-terminated stringy, jsou natolik základní či primitivní konstrukce, že prakticky každá civilizace je objeví krátce poté, co se naučí vykopat díru, do které spade mamut (či napsat román o životě v pravěku) a někdy krátce předtím, než přistane na Munu. tzn. prostě se vyplatí uvažovat o jazyce, který s tím pracuje, i kdyby to byl čistě teoretický konstrukt, jehož simulace zabere kvantovým umělým inteligencím spoustu bolení hlavy (možná i právě proto :-)
    REDGUY
    REDGUY --- ---
    XCHAOS: jak by se vlastně mělo v 21.století programovat v čistém C - ona hlavne otazka je, _proc_ by se v 21. stoleti vubec melo programovat v cistem C. Samozrejme, existuji situace kdy je to zcela na miste. Je jich ale zcela minimum a v naprosty vetsine pripadu existujou nastroje, s kterejma stejnou praci udelas kvalitnejc a za kratsi dobu.
    REDGUY
    REDGUY --- ---
    XCHAOS: To neni odpoved na moji otazku. A druhej odstavec uz je uplny dada.
    XCHAOS
    XCHAOS --- ---
    jinak já se občas (některému, když pochopím, že jsem součástí cílové skupiny) vtipy zasměju. pokud někdo ze vtipu "vyvozuje závěry", tak je to, obávám se, součást problému, nikoliv součást řešení.

    nicméně, to, že se jste ochotný hádat skoro o cokoliv, jen ne o to, jak by se vlastně mělo v 21.století programovat v čistém C (a ne C++), to v podstatě o téhle debatě vypovídá hodně (v podstatě jakýkoliv C kód, který když by řídil vaší raketu/kosmickou loď, tak jste ochotní si do toho pak sami sednout, je asi napsaný dobře)
    XCHAOS
    XCHAOS --- ---
    REDGUY: no tak operátorů (v původním smyslu, tzn. podle mě typicky operace s registry či pamětí, nevyžadující alokaci další paměti pro výsledek) si lze představit spoustu. Např. kultovní jazyk http://en.wikipedia.org/wiki/INTERCAL měl operátor interleave/mingle který vypadá jako vtip, ale jeden z ruských počítačů dané éry prý tento (nebo téměř podobný) operátor měl.

    opravdu nevím, co můžeme čekat od CPU, která bude navrhovat generace smartphone hipsterů (nebo jejich umělých inteligencí, které si vytisknou na 3D tiskárnách). jsem pro jistotu připravený na všechno.
    FLEGMA
    FLEGMA --- ---
    JANFROG: Pokud ten jazyk nema nic jako atributy/fieldy, tak se nic nedeje, stale jde o ten samy princip, totiz pokusy o zapouzdreni byly i mimo OOP - napr. moduly v proceduralnich jazycich atd. Ale zas argumentovat nejakym ciste akademickym, byt historicky dulezitym (vyvoj JIT) jazykem pro psani hricek nekde v kavarne... hmm....
    FLEGMA
    FLEGMA --- ---
    JANFROG: Mas pravdu, ale ne kazdy je takovy polyglot jako ty :-) Kolik jazyku znas, tolikrat ... (vice stravenych noci u PC :-) Ano, je to jiny mechanismus, vsak jsem to psal. A prijde mi to jako docela nebezpecny mechanismus tohle dynamicke prototypovani na prvni pohled...
    JANFROG
    JANFROG --- ---
    FLEGMA: :-) Je uzitecne se povznest na Javu. S tim zapouzdrenim je to slozite. Co kdyz ten jazyk nema nic jako atributy (fieldy) a metody? :-)
    A s tou dedicnosti mi to prijde stejne jako s celerem (celery root) a celerem (celery sticks) - oboji je to celer, akorat to spolu nema skoro nic spolecneho :-)
    FLEGMA
    FLEGMA --- ---
    JANFROG:
    Zapouzdreni jak ho chapu ja je podmnozinou loose coupling, tedy maximalni nezavislosti software komponent na sobe.
    Zaroven je take podminkou izolace komponent - kdyz budu mit vsechny atributy public a tak k nim pristupovat z ostatnich trid, tezko muzu vubec zacit uvazovat loose coupling a modularni architekture. Lisi se granularitou - zapouzdreni na urovni objektu, loose coupling je obecnejsi a muze byt na ruznych urovnich architektury.

    Bez dedeni se v celku bez vetsich problemu obejdes
    Nejdriv jsem ti chtel napsat, ze substituce dedeni kompozici a delegovanim povede ke spouste zbytecneho kodu navic (kopirovaci konstruktory + delegujici metody) + priklady, kdy se v jave bez dedeni urcite neobejdu, ale ted koukam, ze ten tvuj Self ma pro kopirovani vlastnosti objektu primo zabudovanou podporu diky prototypovani, zajimave.

    Takze slevuju: nektere jazyky mimo mainstream (krome Javascriptu, ten je rozsireny dost) splnuji kriteria OOP jazyka i bez klasickeho dedeni trid (class inheritance), protoze maji jine mechanismy na sdileni spolecne funkcionality :-) Zaroven mam ale pravdu, protoze pojem dedicnosti, resp. prototypove dedicnosti (prototype inheritance) se pouziva i pro Self...
    REDGUY
    REDGUY --- ---
    XCHAOS: dobře [bla bla bla] apod. - a jako obvykle, reagujes na neco co jsem vubec nerekl - a navic dost nesmyslne. "assembler je spatny"? WTF? "mapuje instrukci jazyka"? WTF? Co je prosim "instrukce" jazyka C? "Filosofie C je spatna na platforme s novymy operatory"? WTF?

    tady je z toho celodenní debata. protoze z toho v podstate vtipu vyvozujes nesmyslny zavery. A kdyz ti nekdo rekne, ze je to nesmysl, tak zacnes mluvit o nejakym bizarnich irelevantnostech.
    XCHAOS
    XCHAOS --- ---
    KEYMASTER: mno, většinou lidi přijmou nějaký programátorský styl (viz např. ten JS) předtím, než si vůbec uvědomí, že k nějakému přetěžování dochází. každopádně je to hezký příklad rozdíly mezi diskuzními fóry a sociálními sítěmi, protože to má z Twitteru - a tam to prostě retweetli ti, kterým se to líbilo a já byl jeden z nich a pak to zase další retweetli pro mě. tady je z toho celodenní debata.

    mno aspoň oceňuju, že si skoro jako jediný odpověděl na vtip vtipem a ne mínusem :-) (i když to jistě ještě můžeš dohnat)

    REDGUY: dobře - C je assembler původně optimalizovaný pro platformu, která dnes už neexistuje. původní C pro PDP-11 (nebo co to bylo) mapovalo každou instrukci jazyka na tuším právě jednu instrukci assembleru (nebo později dvě nebo něco - četl jsem něco v tomhle smyslu).

    to ale nutně neznamená, že ten assembler na který se to mapovalo, byl nutně špatný, nebo že filosofie C je špatná na platformě, která by přidala třeba pět nových aritmetických operátorů a k tomu několik na dané platformě nativních implementací funkcí typu memcpy() pomocí jediné ASM instrukce, apod.

    UETOYO: eh? to je snad samozřejmé, ne? otázka je, jestli něčemu pomůže, že '+' je v jiných jazycích jednou aritmetika a jednou řetězení. ať už se mi přetěžování líbí nebo ne (mě se když už líbí 3 * '-' == '---', ale přežiju bez toho), tak je z řady hledisek dobré, že věci, které nejsou aritmetická operace se tak netváří. nějaký fuzzy operátor by se mi líbil - ale jen když chci, aby to bylo fuzzy. Kdyby javascript psali Češi, pravděpodobně zahrne porovnávání stringů s diakritikou bez diakritiky (což je SUPER funkce, mimochodem - ale prostě hned v prvním examplu bych vysvětlil rozdíl mezi identitou objektu - tedy druhý objekt je pointerem/referencí na druhou, přesnou podobností (stejná sekvence bytů na různých adresách v paměti) a přibližnou rovností (která je sice dost možná nejžádanější funkcí, ale potřebuju předem vědět, do čeho jdu)

    např. skvělá věc C je, že vím, že operátor prostě nealokuje paměť (jestli se nic nezměnilo :-) což je dobrý důvod neřetězit stringy operátorem. to ten vtip ani neřešil.

    FLEGMA:
    JANFROG: heleďte, já tomu zas tolik nerozumím :-) ale pokud se obloukem vrátíme k tématu - teda jaký styl programování v C se dá dnes pokládat za korektní, bezpečný a všeobecně srozumitelný - tak nebudu proti.

    celkem i uznávám, že ANSI C objekty nejsou "opravdové objekty", ať už se kolem toho vymyslí jakýkoli syntaktický cukr navíc. otázka je, jestli to nakonec nejsou lepší objekty, než opravdové :-) každopádně poptávka po "něčem mezi C a C++" rozhodně existuje: spousta projektů v C++ využívá rozšíření velmi opatrně a umírněně, a je spousta pokusů vydat se od C jiným směrem, než k C++ (např. http://dlang.org/ - viptné je, že kde já si ve svém diaklektu C - t.č. u ledu - z Pascalu vypůjčil konstrukci program {}, tam oni si vypůjčili funkci writeln() :-) )

    mě by se v C líbilo několik věcí, na které jsem si zvykl v Pythonu. díky tomu, že tuším něco málo o tom "jak to funguje uvnitř" (jakkoliv je ta představa na dnes běžných HW platformách nepřesná) tak je mi jasné, co z toho by bylo zcela proti filosofii C a co by naopak šlo implementovat jednoduše. C je např. prakticky připravné na Python style immutable stringy - viz funkce asprintf(). Některé věci by to zpomalilo, ale tvrdím, že jediné bezpečné null-terminated stringy jsou právě immutable stringy, a že pokud se neprogramují nějaké hyper-super-optimalizace stringů (databázový engine, kernel), tak by v nějaké "učebnici C pro 21.století" měly být immutable stringy asi uvedené jako řešení pro začátečníky (místo nešťastné srtcpy()/strcat() rodiny funkcí)
    JANFROG
    JANFROG --- ---
    Uplne nejzakladnejsi principy OO jsou: dedeni,zapouzdreni, polymorfie a tyhle fundamenty nejsou navzajem zamenitelne.
    To je pomerne silne tvrzeni a - dle meho nazoru - nespravne.
    Zapouzdreni je dusledek pozadavku polymorfismu.
    Bez dedeni se v celku bez vetsich problemu obejdes - napriklad (muj oblibeny a v mnoha smerech prukopnicky :-) Self ma pouze delegovani a jen velmi tezko lze zpochybnit, ze to je OO jazyk.
    FLEGMA
    FLEGMA --- ---
    XCHAOS: Mno tvuj popis zapouzdreni je docela nepresny. Predevsim je dulezite zapouzdreni implementace (tj. metody/funkce), zapouzdreni atributu beru jako samozrejmost.

    "pokud striktně dodržíš tohle tzv. "zapouzdření" a s objektem pracuješ jen pomocí API, tak je ti úplně fuk, že jazyk nemá k dispozici dědění" Ne ! Uplne nejzakladnejsi principy OO jsou: dedeni,zapouzdreni, polymorfie a tyhle fundamenty nejsou navzajem zamenitelne. Takze nevim, jak jsi prisel na to, ze si vystacis se zapouzdrenim (a pripadne delegaci).
    KEYMASTER
    KEYMASTER --- ---
    on někdo zase používá JS jako straw man argument proti slabýmu typování?

    No musím uznat že je to osvěžující změna proti klasickýmu "přetěžování operátorů by se mělo zakázat protože ~ jde přetížit na insert_anal_probe(LPANUSW recipient, LONGLONG _IN_ probe)" ;)
    REDGUY
    REDGUY --- ---
    XCHAOS: použiju C, když pokládám za důležité přesně chápat, co můj program udělá - coz je mylna predstava a ani nemusim delat vtipy o tvejch schopnostech. V dobe L1, L2 a L3 cachi, samostatnejch cache pro instrukce a data, prefetchingu, branch predikce, hyperthreadingu, virtualizace, vyraznejch rozdilu mezi jednotlivejma generace procesoru, superoptimalizujicich prekladacu, multiprocesoru s NUMA pameti a kdovi cim jeste jen naprosty minimum programamtoru "presne chape" co jejich program dela. A pokud ti nejde o low-level performancni detaily (ktery navic skoro urcite nepotrebujes) ale o funkci, tak "presne chapat co program dela" ti umozni jakejkoliv pricetnej jazyk. A nektery ti v tom dokonce budou velmi napomocne, misto aby ti hazely klacky pod nohy tak jako C.


    XCHAOS: jako ilustrace, proč se v C pomocí + neřetězí stringy, to bylo myslím výmluvné - ne, nebylo, protoze s tim to vubec nesouvisi. Ilustruje to, ze operator plus v javascriptu ma mizernej design. Dokonce to neni ani obecna ilustrace problemu s polymorfismem, protoze takovej python pouziva '+' pro retezeni stringu taky. A co myslis, ma podobny problemy?
    XCHAOS
    XCHAOS --- ---
    UETOYO: hmm, u operací počítajících s bitovou logikou.. možná. ale jako ilustrace, proč se v C pomocí + neřetězí stringy, to bylo myslím výmluvné...
    XCHAOS
    XCHAOS --- ---
    UETOYO: ne, napsal jsem "použiju C, když pokládám za důležité přesně chápat, co můj program udělá". nic víc, nic míň.
    XCHAOS
    XCHAOS --- ---
    UETOYO: podívej, to máš asi jako debatu o systemd (BTW, je napsaný v C, BTW, sám ho už na dvou desktopech používám a BTW ... chápu vyděšenou reakci jeho odpůrců)

    tenhle klub není - kupodivu o hateování C++ (proto jsem ostatně uvedl příklad s JavaScriptem...který spíš napovídá, jak je tam vyhodnocování výrazů implementováno a jaké triky používá) - ale měl by být o tom, že si lidi programující v C budou nějak vyměňovat zkušenosti o tom, jaké programátorské styly (či možná "dialekty") C jsou ještě vzájemně srozumitelné a jaké už ne (protože i mě samotného při procházení C zdrojáků FOSS překvapilo, co všechno je vlastně občas možné napsat!). a co je případně v dnešní éře "best practice" (což nebyla ještě před pár lety, v éře epických buffer overunů různých microsoftích serverových aplikací, apod., za tak hloupá otázka... asi jsme dnes už jinde, než když tenhle klub vznikl)

    věřím, že abstrakce, kterou nabízí C++, je úžasná... na mě je ale její velká část prostě moc složitá. Sorry. možná, kdybych s tím přišel do styku už na základce, tak bych si zvykl. nevím, těžké říct...
    XCHAOS
    XCHAOS --- ---
    UETOYO: tak to nebylo myšlené. já se zabývám spíše konkrétními, ehm... alkorytmy (tím chci říct, že smyslem tohoto klubu mělo, aby spolu pražští codeři v C občas zašli na pivo, a ne nekončící trolling)
    Kliknutím sem můžete změnit nastavení reklam