A hét (másik) képe: Társasjáték kockáknak

Fun

Hubertf blogját olvasgatva bukkantam a C-Jump névre hallgató társasjátékra, amelynek célja, hogy gyerekek számára játékos módon megismertesse a programozás alapjait:

A játék honlapja itt.

( tiger | 2007. 08. 18., szo – 16:07 )

ez nagyon beteg
---
Ketchup elementál megidézése a sajt síkra

( pinyo_villany | 2007. 08. 18., szo – 16:17 )

bazd meg ..., ez fáááááááj

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.
debian 4.0 - linux-2.6.22.3-pancs1-wifi1 - 2.6.22.1 kernel madwifivel itt

( uid_6846 | 2007. 08. 18., szo – 16:25 )

Ez zseniális! Végre megtanulok programozni! :D
__________
U-Bantu©

( Caro | 2007. 08. 18., szo – 16:32 )

Ezzel inkább ne tanítsanak semmit.
Mi az a goto? Meg az x++ a ++x helyett? Meg a kifejezések értékadás nélkül (ezekre még minden fordító warning-ot is dob)?
:)

+1
A goto val csak egy a baj, elrontja programozas kompozicionalitasat. A dolog lenyege, hogy egy feladatot fol tudj osztani kis reszekre, es ha a reszeket meg tudod kulon oldani, akkor egybe az egesz is !hopla! meg van oldva.
A strukturalis elemekre ez biz mukodik.
[flame]
Linuxs h*jje.
[/flame]
==
`Have some wine,' the March Hare said in an encouraging tone.
Alice looked all round the table, but there was nothing on it but tea.

Hala egnek csak magas szinten mozgok :)
A goto soha nem jo csak neha nem artalmas de olyankor is felesleges.
Szeretnek en (nem igazabol nem szeretnek) olyan programozas elmeletet olvasni ami egyszerre kepes megfogalmazni a kettot:
- mikor old meg egy program egy feladatot.
- mi a goto.
==
`Have some wine,' the March Hare said in an encouraging tone.
Alice looked all round the table, but there was nothing on it but tea.

goto neha olcsobb: miben? kevesebb assembly kodra fordul? Szar a fordito. Amugy
meg a helyi micro szintu optimalizalas ugy baromsag ahogy van.

ramgep:
Ha a program az allapotatmentfv, baromi konnyen megfogalmazod mikor old meg egy program egy feladatot. Mi a goto?
Ha a program az az assembly szeru ize amit a ramgepekhez szoktak irni akkor mikor old meg egy program egy feladatot?
A lenyegi lepes: eljuss egy vmi nyelv szinten leirt dologtol a hatasrelaciojaig. Ez csak kompozicionalis eszkozokkel fog menni. Ez a baj a goto val.
==
`Have some wine,' the March Hare said in an encouraging tone.
Alice looked all round the table, but there was nothing on it but tea.

Igen gonosz asm szerű kódja van. Goto a feltétel nélküli ugró utasítás.

"A lenyegi lepes: eljuss egy vmi nyelv szinten leirt dologtol a hatasrelaciojaig. Ez csak kompozicionalis eszkozokkel fog menni. Ez a baj a goto val."
"There are rules for concurrency, procedures, jumps, and pointers."
Wiki Hoare Logic, ha gondolod keresed meg a szabályt.

Error Handling During Initialization részt ajánlom, goto nélkül sokkal drágább lehet.

A goto nem rossz. Csak tudni kell használni. Például kiválóan lehet vele exception kezelést csinálni C-ben (nyilván egy függvényen belül). Az általunk megtervezett és megvalósított komponens naponta többmillió példányban fut szerte a világban (mobiltelefon). A komponensünk mellesleg 1.5 hónappal hamarabb készen volt, mint a többi...például a jól átgondolt hibakezelésnek köszönhetően.

Most, hogy látjuk a hasznát, talán taníthatnánk is rá a fiatalokat...

Sokkal több zavart okoz, mikor egy rutinnak több kijárata van, mint,
ha van benne 1-2 goto. És mi is a baj az x++ - szal?

(amúgy a break is goto, csak másképp hívják, sőt a kapcsos zárójel
is vezérlésátadó utasítás, csak nem úgy néz ki.)

> Sol omnibus lucet.

Amikor egy if vagy egy else ágat lezárójelezel. Gép szinten
nem oldható meg j* nélkül. Az ugrási határokat pont a kapcsos
zárójel jelöli ki.

(Igaz, nem vezérlés átadó utasítás, de ahol kapcsos zárójel van,
ott valahol megbúvik egy vezérlésátadás.)

> Sol omnibus lucet.

Switch-case szerkezetet viszont elég nehéz elképzelni break vagy continue nélkül. Vagy te mondjuk hogyan implementálnál le egy (matematikailag teljesen korrektül megfogalmazott) állapotgépet?
Hasonló probléma a hibakezelés, amikor _azonnal_ ki _kell_ ugranod a ciklusból, nem várhatod meg, hogy körbeérjen és kiértékelődjön a ciklus feltétele, mert a ciklusmag hátralevő részén elszállna vagy veszélyes hülyeséget csinálna a program. Persze tudom, ezt ki lehet váltani mondjuk borzalmasan sok egymásbaágyazott if-el, de ilyet csak az mond, aki még nem írt komoly programot. Aki írt az tudja, hogy az egymásbaágyazott if-ek 3-4 szint fölött borzasztóan átláthatatlanná tudnak válni és akkor már sokkal áttekinthetőbb, ha break-elsz ott ahonnan nem szabad továbbmenni. Akkor első ránézésre látszik, hogy mi van.
Goto-t egyébként én sem szeretem, még nem volt példa rá, hogy ne tudtam volna megoldani egy feladatot nélküle. Csak akkor van szerintem értelme, ha valaki nagyon-nagyon hűde ki akarja optimalizálni a kódját, de valamiért mégsem akar assembly betétet. Bár nem hiszem, hogy sokat nyerne vele...
---
Sok gyerekkel ellentétben én sose akartam tűzoltó lenni. Lettem helyette informatikus. Nem találjátok ki, hogy mit csinálok nap mint nap...

Úgy látom nem foglak tudni meggyőzni, a hited nagyon erős. Pedig hidd el, hogy lényegesebb, hogy a kód átlátható legyen, azt pedig - módjával, értelmesen, megfelelő helyen használt - break/continue-val néha jobban el lehet érni. A lényeg, hogy ránézésre látszódjon, hogy mit csinál. Break/continue bigott módon való kerülése _néha_ sokkal zavarosabb és lassabban futó kódot eredményez, ráadásul a programozónak komoly agymunka, hogy kitalálja, hogy hogy kerülje meg, esetleg extra boolean változók felvételével, sokkal több elnézési, hibázási lehetőséggel, ahelyett, hogy a valódi feladattal foglalkozna.
---
Sok gyerekkel ellentétben én sose akartam tűzoltó lenni. Lettem helyette informatikus. Nem találjátok ki, hogy mit csinálok nap mint nap...

Követelem, hogy vegyék ki az összes processorborl a feltételnélküli ugrásokat, és zárjanak be mindenkit aki feltételes ugrás utasítás elé konstansul igaz/hamis dolgot ír.
Továbbá távolításk el az összes nyelvből a goto utsítást, és sújtsa halál büntetés aki csak rá gondol hogy, használja.
break,continue,throw -t szintén tícsák be, mert sokakat a goto -ra emlékeztet. Használata minimum 100 év kötél.

Továbbá tícsák be az IRQ -kat is, ill. csak ret utasításokkor lehesen taszkot váltani. Valamint adót vessenek ki CPU -t megkerülő I/O technikákra.

Sorry, ez egy meddő vita, szerintem nincs értelme folytatni.
Egy kicsit hasonlít arra, mint mikor adtam valakinek egy header file-t, ami tele volt enum típusokkal. Neki egy mikrokontrollerre kellett, úgyhogy az összes enum-ot átírta #define-ra, hogy ne foglaljanak memóriát.
Egyébként régen én is sokat goto-ztam (még BASIC-ben), de az nagyon régen volt, mikor annó elkezdtem a Pascalt, valahogy már nem is hiányzott.
C-ben sem éreztem még szükségességét. Lehet rövidebb a kód ezeknek a használatával, de így mindig meg tudom mondani, hogy hol tarthat egy program, és nem keveredek össze. Tudom, hogy egy ciklus vagy egy elágazás elé nem mehet vissza a vezérlés.

Teljesen szabványos, ez tény. A probléma ott van, hogy amennyiben csak inkrementálásra/dekrementálásra használod a ++/-- operártort, akkor az x++ alak eggyel több objektumot hoz létre (lásd: C++ kódolási szabályok, 28. szabály). Ami mind memória és művelet terén is felesleg. Amennyiben nagy méretű tömbökön (vagy akármilyen tárolókon) dolgozol, úgy ez egy elég nagy luxus.

Drága V Barátom!

Áruld el nekem, hogy hol olvastál olyat a bejegyzésemben, hogy "Tárolót inkrementálni"? Továbbá az objektum itt nem a C++ értelemben vett objektumot, hanem azt a szerencsétlen int típusú változót jelenti, amit a x++ hatására implicite létrehozol.

Baráti üdvozlettel:
-Manoe

Azért egy programozónak illik tudni tettei következményeit.
Ez kb. olyan, hogy láttam egyszer egy "benchmark"-ot, ahol az őrült két igen magas kilépési értékű számláló ciklust ágyazott egymásba, amikben nem volt semmi.
És akkor arra örült, hogy haha, ezt a java <1 sec. alatt lefuttatja, de C++-ban több mint egy hónapig fut. Hát erre no comment.

Itt csak arra akartam rámutatni, hogy jó ha tudja a programozó, hogy amit leír, annak súlya van, és nem lehet úgy hozzáállni a dolgokhoz, hogy majd a fordító úgyis kioptimalizálja.
De könyörgöm olyan nagy kérés egy önmagában álló x++ helyett ++x-et írni? Még karakterben sem kerül többe.

Drága V Barátom!
Áruld el nekem, hogy hol olvastál olyat a bejegyzésemben, hogy "Tárolót inkrementálni"? Továbbá az objektum itt nem a C++ értelemben vett objektumot, hanem azt a szerencsétlen int típusú változót jelenti, amit a x++ hatására implicite létrehozol.

Ha a tömb elemeit úgy inkrementálod, hogy nem szerepel más kifejezés jobb oldalán, akkor bármelyik általam ismert fordító pontosan ugyanazt a kódot generálja a "szerencsétlen int" növelésére, mintha prefix inkrementálást használsz, tekintve hogy az ideiglenes objektumot sehol sem használod.

Az okoskönyvből vett idézeted csak C++ objektumokra vonatkozik, mivel ott a fordító nem tudja megállapítani, hogy mi történik postfix++ esetén, sem azt hogy ez miben különbözik a ++prefix-től.

Ha pedig a barokkos "hülye vagy bazmeg"-et kihagyod a hozzászólásokból, akkor hamarabb kiderül, hogy mit is akarsz mondani.

Ugy nezd hogy kozben elfelejted a C-t, egy ilyennek az alapveto programozasi elemekt kene tanitani, nem egy nyelv tulajdonsagait.
Egyebkent nekem sem tetszik, pont amiatt amit irtam. En inkabb valami olyan jatekot csinalnek ahol a jatekosok maguk rakhatjak ossze a palyat maguk alatt alapveto -tokeletesen nyelvfuggetlenul megfogalmazott- proceduralis elemekbol: szekvenciabol, ciklusbol, es elagazasbol.
Ez ami itt van teves szemleletet alakit ki az egeszrol, nem csak a pontatlan C miatt , aztan ezutan fognak olyanokat mondani a tanulok, hogy egy program fut, meg novel egy valtozot, meg egyszer erre megy egyszer meg arra stb stb.
==
`Have some wine,' the March Hare said in an encouraging tone.
Alice looked all round the table, but there was nothing on it but tea.

Hát, pedig erről szól az egész thread... akik tanultak programozni, olyanokkal állnak vitába akik megtanultak programozni.

(Az egyik nagyon szép vonalvezetéssel, többféle színű ceruzával is tud UML diagramot rajzolni, a másik meg már látott processzort, tudja hogy működik, és vezérelte is...)

Ha valaki C-ben kodol, nem art fejben tartani, hogy nagy vonalakban mire fordul az a kod. Egy break/continue/goto sokszor sokkal jobb, mint csak ezert korultoketlenkedni a problemat.
Az x++ meg a ++x meg egyarant ertelmes, es egyebkent mast csinal (preincrement/postincrement).

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Szerintem arra gondolt, hogyha simán inkrementálni akarsz, és nem kell helyettesítési érték, akkor mind1, hogy melyiket használod. Bevallom egyébként nagyjából tisztában voltam a goto/nem goto és hasonló vallásháborúkkal, de ez a x++ helyett a ++x hiedelem nekem is új. Egyébként 1000%, hogy a fordító kioptimalizálja, mert szinte mindenki az x++ formát használja, ha csak simán inkrementálni kell, tehát a fordító fejlesztők biztosan betettek erre optimalizálást (ha a használatlan visszatérési értékek eltárolását kiszűrő algoritmus eleve nem fogná meg, de szerintem pont az fogja meg).
---
Sok gyerekkel ellentétben én sose akartam tűzoltó lenni. Lettem helyette informatikus. Nem találjátok ki, hogy mit csinálok nap mint nap...

( Caro | 2007. 08. 18., szo – 18:29 )

Egyébként meg amúgy is, ha _programozást_ akarnának tanítani (és nem hogyan barkácsoljunk helloworld-öt C-bent), akkor nem programkódot kellene leírni a papírra, hanem valamiféle algoritmust.

( hnsz2002 v | 2007. 08. 18., szo – 19:30 )

Nehogy azt higgyétek, hogy nem töltöttem le egyből... :D
Nagyon állat! :)

[szerk] Még most nézem, ez mind EXE! Csak windowsra van? :(( :_(

[szerk2] De a wine viszi! :D

OpenSuSE 10.2, Celeron 2,4Ghz, 768MB, 2*160GB IDE Raid0, FX5200, SBLive! E400
OpenSuSE 10.2, Acer Aspire 5020, AMD Turion 64bit @ 1,8Ghz, 1GB, 80GB Toshiba, Mobility Radeon X700 PCI-E 128MB/128bit

( meditor | 2007. 08. 18., szo – 19:41 )

Én írtam egyszer egy headert a fiamnak, hogy tanulhasson C-ül.
Kicseréltem az utasítások és néhány könyvtári fv nevét. Állati mókás
kinézetű programokat lehetett írni vele. Íme egy kis izelítő:

//////////////////////////////
elojel_nelkuli egesz i;
egy_sor("HUNCUTKA megjött!");
i=0;
amig(i<24)
{
egy_sor("hahó");
i++;
}
//////////////////////////////

A program kiírja, hogy "HUNCUTKA megjött", majd 24x azt, hogy "hahó".

(-::

> Sol omnibus lucet.

( mocsi | 2007. 08. 18., szo – 20:54 )

Anno vagy 20 eve volt egy magyar kartyajatek, ami BASIC utasitasokat tartalmazott.
Megvettuk de nem sokaig jatszottam vele.

( Replaced | 2007. 08. 18., szo – 20:55 )

A ceg a jatek nagy sikeren felbuzdulva ujabb jatekokat tervez kiadni:

- Rendszergazdalkodj okosan
- mono-poly
- Ki .net a vegen?
- Ruby kocka

--
I think the major good idea in Unix was its clean and simple interface: open, close, read, and write.

( bigwig | 2007. 08. 19., v – 12:50 )

3 megjegyzés:

1. goto:
bigwig@bigwig:/usr/src/linux-2.6.19.2$ find . -name '*.c' -exec grep 'goto [[:alnum:]_]*;' '{}' \; | wc -l
41945

2. x++:
bigwig@bigwig:/usr/src/linux-2.6.19.2$ find . -name '*.c' -exec grep '[[:alnum:]_]*++;' '{}' \; | wc -l
18364

3. btw:
Van, aki tud programozni, és van, aki nem. Aki tud, goto-val is tud, aki nem, spagettikódot gyárt a legmakulátlanabb objektum-orientált környezetben is.

( bitvadasz | 2007. 08. 20., h – 11:44 )

Kinek, mi a beteg: ez relatív.

penguinsurf == snowboard