Minimális tudású IDE C tanuláshoz ?

Kedves HUP-osok!

Nagyobbik fiam viszonylag jól tud Logoban programozni. Most rágja a fülem, hogy a szünetben tanítsak neki valami komolyat. Sajnos, én komolyan csak C-ben tudok programozni, ezért a szokásos tanácsok, amik keringenek a neten, hogy "Először xxx nyelven kell a gyereket tanítani.", nálam nem jönnek be, mert adott, hogy én C-hez értek olyan szinten, hogy tanítani merjem.

Szóval: tudtok-e igen egyszerű IDE-ről, mely egy kezdőnek jó lehet?

Én TurboC-ben tanultam, annak a felülete tökéletes lenne, de az már elérhetetlen a mai Linux rendszerek alatt.

Jómagam Eclipse-t használok mostanában, de az Anjuta és a KDevelop sem ismeretlen -- sajnos mindegyikben projekteket kell definiálni, odanyomnak egy csomó autoconf-os meg ilyesmi fájt a könyvtárba, stb, ami egy kezdő, 12 éves gyereket csak összezavar.

Az általam régen használt vi+gcc+(make) kombináció fapadosnak tűnik.

Nincs valami egyszerű, kis tudású, de átlátható IDE C-hez?

Előre is köszi!

András

Hozzászólások

Távol álljon tőlem a kioktatás, valamint nem tudom, milyen szinten van a fiad programozásban, de nem tartom jó ötletnek 12 évesen C-t tanítani. Ha van hozzá érzéke, kedve és sikerélménye is már logo-val, nem merném megkockáztatni, hogy kedvét szegje a C. Python-t vagy Ruby-t adnék a kezébe, nagyon jól dokumentáltak, jól használhatóak, viszonylag segítik a kezdőket és Windows-on és Linuxon is elérhető mindkettő. Ha jó programozó vagy, szánj két hetet a Pythonra, hogy megismerd, utána már értékes tudást tudsz neki átadni, sikerélménye is lesz, ami pedig nem utolsó, használható tudása. C-vel ráér később foglalkozni, ha szüksége van rá.

Nem kell fordítani, ami kezdőként sokat segít. Ajánlom a KDE Kate-t, mint szerkesztő.

--
Keep it simple, stupid.

C kisebb nyelv --> egyszerubb megerteni,megtanulni.
Lehet, hogy neked egyszerubnek tunik ruby,python valojaban nem az, mivel nem trivilis megerteni mi tortenik a hatterben.

Szerintem sokan vagyunk itt akik 12 evesen mar programoztunk valami C szeru nyelven, esetleg asm kodot is irtunk mar akkoriban.

Ez egy nagyon érdekes kérdés, mi Turbo Pascalban csináltunk játékokat, stb-t. Volt egy remekül használható IDE, de a legfontosabb, hogy az akkori szinten (DOS) ezzel az eszközzel igen színvonalas munkákat lehetett készíteni, csak a programozásra koncentrálva. Gőzöm sincs, hogy mit adnék egy mai gyerek kezébe!

Valami komolyabb Linuxos IDE-t? Olyan dolgokkal kellene foglalkoznia, amiknek semmi köze a programozáshoz. Valami Visual Studio Express-t? Talán, de mit készítsen benne? Valami grafikus játékot? Manapság ezt se lehet csak úgy; komoly háttértudás szükséges az API-hoz.

Scriptnyelvek? Mellékvágány. Haladni fog, de háttértudás nélkül nem fog tudni igazán látványosat alkotni, ami kell a sikerélményhez. Ugye, minden ilyen dolog, mint SQL, GTK, Curses, akármi, komoly háttértudást igényel, ezek nélkül max. valami text parsert írhatsz script nyelven.

IDE még talán lenne C-hez, de nincs olyan library készleted, mint amivel anno a Borland rendelkezett. Persze, ez együtt jár a hardver és az OS képességeinek növekedésével és az elvárásokkal. De míg régen egy Turbo C/Turbo Pascal-ban a többi programhoz hasonló színvonalúakat lehetett készíteni, ma ez nem megy.

Talán a Java-val lehetne ma elindulni, a NetBeans egy remek IDE kezdőknek és a sallangokat (Swing, JDBC, stb minden) elfelejtve is nagyon látványos dolgok programozhatók. Könyv is van rengeteg és tele van a net példával. (A script nyelvekkel a fő problémám az _értelmes_ irodalom hiányából fakadó frusztráció.)

Úgy érzem hatalmasra nőtt a szakadék, amit egy kezdő programozónak át kell lépnie. Rengetegen programoznak PHP-ban, talán ez lett az új Pascal, de messzebb vannak a valódi programozástól (és a valódi programozói munkaerőpiactól), mint valaha.

Scriptnyelvek? Mellékvágány. Haladni fog, de háttértudás nélkül nem fog tudni igazán látványosat alkotni, ami kell a sikerélményhez. Ugye, minden ilyen dolog, mint SQL, GTK, Curses, akármi, komoly háttértudást igényel, ezek nélkül max. valami text parsert írhatsz script nyelven.

Ezt a véleményt osztják is sokan. Aki ma azt mondja, 2008-ban, hogy a scriptnyelvek nem alkalmasak komoly feladatra, az van mellékvágányon, elég rendesen.

Talán a Java-val lehetne ma elindulni

Mert az nem interpreteres nyelv, mi? :)

--
Keep it simple, stupid.

egy csomó installer úgy műkszik, hogy benne van tömörített adat, az elején meg az, hogy tömörítsed mán' ki a következő hárommilió sorban jövő bináris adatot valahova. Ezért lehet, hogy mondjuk az első száz sora olvasható, mert egy bash, vagy perl program az egész.

Batch processzek készítésére többször gyorsabb, mint a C. És a gépidő senkit nem érdekel. Egyébként egyre több Linux alkalmazás, beállító felület és egyéb frontend készül python vagy perl + gtk-ban. Ha az én fiam tizenkettő lesz, akkor biztosan ez lesz az első. A sikerélmény miatt legjobb valami grafikus feladat.

Hahó!
>>Talán a Java-val lehetne ma elindulni

>Mert az nem interpreteres nyelv, mi? :)

A ,,klasszikus'' értelemben: nem az.

Az ,,interpreter'' a forráskódot pl. soronként értelmezi, és úgy hajtja végre (nem fordít!!!).

Ezzel szemben a Java a javac fordítóval bájtkódot készít, s a java (JVM + objektumkönyvtár) azt hajtja végre, mint egy ,,szoftveres processzor''. Itt azt is lehetne mondani, hogy a bájtkód a JVM-en natív módon hajtódik végre.

Ebből a nézőpontból a Java környezet inkább talán hibridnek fogható fel...

G.
============================================
"Share what you know. Learn what you don't."

Igen, eléggé elmosódnak ma már a határok. Ha azt nézzük, a PHP-t és a Perl-t is már egy virtuális gép futtatja (Zend vm, Parrot, stb). A byte kód meg ugye nem játszik nagy szerepet a kérdésben, mert bármelyikből lehet készíteni (szokás is).

--
Keep it simple, stupid.

Mert az nem interpreteres nyelv, mi? :)

NEM!
A JVM JIT compileres, futasidoben forditja gepi kodra a bytecode-ot. De mar vagy 6-8 eve am.

Javaslom, nezd meg a

http://shootout.alioth.debian.org/

site-ot, es vesd ossze a kulonbozo platformokat. Java C/C++-al van kozel egy szinten, perl/python/ruby sehol sincs hozzajuk kepest sebessegben.

Ez egy nagyon érdekes kérdés, mi Turbo Pascalban csináltunk játékokat, stb-t. Volt egy remekül használható IDE, de a legfontosabb, hogy az akkori szinten (DOS) ezzel az eszközzel igen színvonalas munkákat lehetett készíteni, csak a programozásra koncentrálva. Gőzöm sincs, hogy mit adnék egy mai gyerek kezébe!

Ezzel viszont teljes mértékben egyetértek. Azok a Turbo C és Pascal szoftverek nagyon jók voltak megtanítani a diákokat programozni és szemléletmódot kialakítani. Sok helyen ma is nyomják sulikban, általában 14-18 éveseknek. Kérdés, hogy megockáztatható-e a régi módszerek berögzülése és olyan felesleges dolgokkal, mint a Borland Graphics Interface-szel (ami egyébként a maga nemében nagyszerű) foglalkozni, vagy a Dos kínjaival bajlódni. Merthogy haszna nem lesz belőle senkinek már. Az egyetlen ami mellette szól, hogy kerek egész és könnyen tanulható, kiforrott IDE van hozzá és valóban nem vonja el semmi a figyelmedeta a programozásról.

--
Keep it simple, stupid.

Szerencsére nincs igazad, bár ma már tényleg nem triviális egyszerűen programozni C/C++ -ban. :-)

Kapásból tudok két grafikus library-t, ami kezdő - vagy közel kezdő - szinten is könnyen használható:

http://cimg.sourceforge.net/
http://www.libsdl.org/

Főleg a cimg egyszerű.

Ahhoz, hogy programozni tanitsd a gyereket, meg nincs szukseg IDE-re. Kezdjetek el a teljesen alapoknal. 16 bites szamrendszer szamolasa, szamitogep memoria mukodese, proci mukodese, mi a kulonbseg a Logo es a tobbi nyelv kozott. Ha ezt mind megertette, akkor kezdjetek neki egy nyelvnek. Foleg ha tenyleg kitartotok a C mellett, ezeket kell elobb megtanitani neki.

En sem ajanlanam a C-t, mert tenyleg nagyon bonyolult egy, a programozasrol semmit nem tudo embernek. Probaljatok meg inkabb a Java-t vagy a C#-ot (amelyiket ismered). Nem kell teljesen profinak lenned egy nyelvbol ahhoz, hogy a fiadnak elkezdhesd az alapokat tanitani. Tanitsd meg ot a neten keresni informaciokat, tanitsd meg neki, hogy hogyan dolgozzon fel egyszeru peldakat barmilyen programozasi nyelven. Fejlesszetek kozosen az angol nyelv ismeretet, a matematikai ismereteket, hogy megertse amit csinal.

Nem tartom rossz otletnek a scriptnyelveket sem, mert a logikajuk egy picit hasonlo a Logo-hoz, megis kozelebb all a rendes programozasi nyelvekhez. Perl-hez, PHP-hoz vannak olyan konyvek, amik (ha a fiad ismeri a programozas alapjait) egesz jol bemutatnak egy nyelvet. Ilyenek pl. a '21 nap alatt mesteri szinten' sorozat. Java-ra pl. Glenn Rowe: JAVA programozas c. konyvet ajanlom. Ha pedig mindenaron C, akkor a Kerningham-Ritchie konyv szerint menjetek (ez utobbi amennyire tudom fenn van a neten valahol, mert nekem is onnan van meg, de ha kell, elkuldom). Ne kozvetlen ebbol tanitsd, de tematikaban e szerint menjetek.

IDE helyett pedig egy rendes syntax highlighteres editor kell neki, mint linux alatt a gedit/kwrite, windows alatt esetleg a notepad+ vagy a scite, mely multiplatform. Mondjuk az nem baj, ha megismerkedik a gvim-mel.

nem akarok kötekedni, de szerintem egy gyerek addig boldog, amíg nemtudja, hogy mi az az ojjektum. javában és c#-ben (előbbiben biztos) csak nehezen lehet strukturált programokat összepakolni, és az is igen rondán néz ki.

szerintem pont jó a sima C! ott is lehet szívni a kezdetek kezdetén, de legalább nem a neten kell keresni, hogy ez a konstruktor most miért így működött, és mit szúrhattam el, mikor látszólag minden tökéletes.
strukturált nyelvvel kell kezdeni szerintem.

ez hulyeseg.
ki a fraszkarikat erdekli a 16 bites szamrendszer, meg az ilyen "marhasagok"? (12 evesrol beszelunk!)

a scriptnyelvek felejtosen, Mico jol leirta miert, meg amugyis..

meg mindig turbo pascal a jo kezdonyelv. :) mar cask azert, mert lehet benne grafikaval szenvedni. C#hoz azert sokkal tobb hattertudas kell. Swing meg egy vicc:)

Ember, 12 éves gyerekről beszélünk, nem software architect-ről. Menjetek már ezzel a memóriabasztatással, a nélkül, hogy minden egyes nyomorék bitet leellenőriztem, anélkül is el lehet játszadozni egy nyelvvel.

Én is tizennemsok éves koromban kezdtem basiccal meg pascallal, mégse haltam bele, hogy később tudtam meg, hogy hogyan is megy a mai memóriakezelés.

A BGI-t szidóknak meg annyit, hogy jó dolog, hogy _egyszerűen_ lehessen rajzolni valamit. Majd ha a srác érzi lassúnak, akkor ráérnek valami egyebet keresni.

----------------
Lvl86 Troll, duálkasztban "M$ bér€n¢™" és "NagyZ sleppje™". Mimás? ;)[
Aki elhiszi, az meg hülye.

szerintem meg c++
sok minden egyszerűbb, tisztább benne, mint sima c-ben és lehet programozni eljárásközpontúlag is, ha nem akar objektumokkal vacakolni (ami szerintem a legjobb dolog, csak annó kellett vagy fél év 16 éves fejemnek mire felfogtam)

szerkesztőnek meg gedit, esetleg valami gombot hozzá lehetne hekkelni (ópenszósz), ami meghívja a gcc-t

Kwrite + gcc meg make sem kell az elejen.
Szerintem eleg egy syntax highlightos szerkeszto.

mcedit + gcc

esetleg

RHIDE
--
unix -- több, mint kód. filozófia.
Life is feudal

code::blocks

De nam art, ha megtanitod gyereknek mi fan terem forditas, linkeles.

gvim is eleg minimalis :) , forditas futatas gombot meg lehet hozzza adni :)

szerintem python, ebben a konyvben latvanyos programok(tk modul) is vannak pl a bang bang! nevu jatek vagy a logohoz hasonlo program ahol meg lehet adni, hogy a "teknos" milyen iranyba menjen ezenkivul szerintem jo csaladi program egyutt megtanulni programozni:)
-----
kit erdekel milyen kernel?

Kösz az eddigi tippeket! Kötegelve válaszolok:

a) python, ruby, ...: Nem akarok script kiddiet nevelni a fiamból. ;-)
Komolyra fordítva: 1000-nél több soros programot Basic-ben (C64), Pascalban és C-ben írtam. Oktatási tapasztalatom szerint csak azt szabad tanítani, amit nagyságrenddel jobban értek, mint a hallgatóság. Ráadásul én a C-re úgy tekintek, hogy lehet, hogy az első lépések nehezebbek vele, mint mondjuk pytonban, de komolyabb szintre könnyebb eljutni. És a fiam is azt kérte, hogy olyat tanuljon, amivel az igazán komoly dolgok megoldhatók.

b) RHIDE: valamikor 4-5 évvel ezelőtt próbálkoztam vele, akkor RedHat akárhányon elég fagyizós volt. Fejlesztik még? Stabil?

c) Ha nem jön be az RHIDE, akkor lehet, hogy szövegszerk. + gcc-vel próbálkozom. Melyikhez van jól integrálva a C fejlesztés? Tehát mondjuk klikkre fordítson, a fordítási hibák sorait legalábbis bejelölje.

d) Azt hallottam, a Turbo C 3.0-t ingyenessé (zárt kód maradt) tették. Igaz ez? Ha igen, Dosemu-ból biztos elfut....

Ha kde-t használsz akkor pillananyilag a kate (ami inkább szövegszerkesztő, de van integrált konzol emulátora )ott lehet gcc-vel fordítani. A RHIDE eléggé kihalóban van szerintem hagyjad. A Geany amo Gtk-s azt még megééri megnézni. Én is ilyen fapad őrült vagyok a nagy IDE-k zavarnak. Valószínülg, mert azok grafikára oo-ra vannak kihegyezve, én meg hardvert programoz(gat)ok.

Kate+gcc-t ajánlom én is nagyobb dologra, illetve Kwrite+gcc, ha csak egy fájlból áll a dolog (hello world-re elég). Jómagam is ezt használom, mert egyes nyelvek esetén szeretem a nagy IDE-ket (pl.: Java), de a C-hez hozzátartozik a fapad :)

A Turbo C-vel az a gond, hogy sok helyen eltér az ANSI C-től, ami nem jó (az ANSI C standard, szóval azt érdemes tanulni).

Még felettem írták, hogy ahhoz, hogy valaki jó C programozó legyen, elengedhetetlen némi architekturális ismeret is. Ezzel teljesen egyetértek, ajánlani tudom 'Tannenbaum - Számítógép Architektúrák' c. könyvét. Esti mesének elég húzós, nem is kell mindent megérteni belőle elsőre, sokkal inkább egy szemléletet ad, ami később nagy mértékben segít abban, hogy már úgy áljon hozzá egy kód írásához, hogy azt hatékonyan működjön.

Néhány korai Turbo C/Pascal fordító szabaddá lett anno. A néhai Új Alaplap lemezmellékleteként is megjelent.
A fordításhoz tty1 - kódolni, tty2 fordítani és kész.
TTY1-en mehet mondjuk az mcedit, nyomsz egy F2-t, erre elmenti a változtatásokat, majd ALT-F2 -re átváltasz TTY2-re és a "felnyíl" visszaadja azt a parancssort, amivel fordítgatod a programot.
--
unix -- több, mint kód. filozófia.
Life is feudal

Kösz a tippeket!

A geany-t először "gány"-nak olvastam, de aztán rájöttem, hogy miről van szó. ;-) Ki is próbáltam: eddig ez a legjobb tipp. Persze, hosszú távon dől el a dolog (pl.: stabil-e), de most jónak látom. Csak az egyszerű debug-ot hiányolom, de lehet, hogy sokat akarok.

Közben eszembe jutott valami: régen én vi+gcc-s voltam, aztán Anjuta, majd Eclipse-s, de vi-os időszakomban az Emacs nagyon nyomult, mint IDE. Aki ismeri az Emacs-ot, mint C-hez való IDE-t, attól kérdezem: érdemes megpróbálnom a topicban vázolt célra használni?

A módszertani problémákat (kis gyerek, compileres nyelv, stb.) érzékelem, de eltökélt vagyok a C mellett. Majd lehet, hogy megszívom. Családon belül marad. Ha érdekel valakit, majd beszámolok. Egyenlőre IDE-t vadászok.

Igen, de te le is akartad beszélni a C-ről, még ha a C++ irányába is.

Én 12 éves koromban, még csak elméletet _és_ basic-et tudtam, mert csak ezek felé tudtam tájékozódni. Pascalozni is csak 14-15 évesen volt lehetőségem (Turbo), majd utána saját döntés mentén kezdtem C-vel foglalkozni. És azóta se bántam meg!

A C-t ha vki. tudja, akkor utána már mindent tud, és meg lehet sitty-sutty ilyeneket tanulni, mint perl, php, ...
Na jó, persze mindnek vannak sajátosságai is amiket még utána majd a gyakorlat hoz meg, de ez már egy "alap" ahhoz, hogy a többi nyelv alapjait pár óra alatt elsajátítsd. Maximum!

Kedves horvatha,

10 eve kodolok c es c++ nyelveken, 2-3 eve emacs-ot hasznalok.

Ha valakinek a c nyelvet kezdenem el tanitani, biztos nem "szakitanam ra" az emacs-ot, ugyanis mar ahhoz is, hogy egy nagyon egyszeru C kornyezetet alakithass ki benne rengeteg egyeb tudasra van szukseged!

Udv,
Kristof

Mi is a baj az eclipse-sel?

Azt te is ismered. Indíthatsz Makefile-os C projectet. Ami makefile ismeret a kezdetben kell, az bőven tanulható (gyak az OBJS változót kell kitölteni). Van debug, színes, szagos szélesvásznú...

Ami az IDE-nél sokkal fontosabb, hogy mit is tanítasz a gyereknek. Vélhetően túl sokáig nem fogják lekötni konzolos programok.

Valószínűleg itt sokan azzal kezdtük, hogy Pascalban svga256.bgi-val vonalakat huzogattunk, pattogtattunk, stb.
Ezen a vonalon indúlj el, azaz keress egy egyszerű grafikus lib-et.
Hirtelen az allegro jutott eszembe, esetleg az SDL. (Egyiket se használtam, de belenézve a lehetőségekbe annak idején a fél karomat odaadtam volna ezért. :) )

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

"Mi is a baj az eclipse-sel?
Azt te is ismered. Indíthatsz Makefile-os C projectet."

Igen. Én indíthatok. És a gyerek? Azt szeretném, ha mielőbb önállóan tudna dolgozni és az elején ne a környezet beállítása kösse le, hanem a C tanulásra tudjon koncentrálni.

De egy próbát megér, letesztelem, mennyivel lehet megúszni egy egyszerű Makefile-os projekt indítást, ha eleve egy egyfájlos "projekt" van a fejemben.

Te, a Midnight Commander a legegyszerűbb. Nincs debuggere, viszont egy egyfájlos, kezdő appot menűbül lefordíít és lehet nézegetni. Majd ha a "Hello word" -ön túl jut lehet tovább lépni.
Én a problémát inkább a feladatokban látom - mi mindíg úgy programoztunk hogy volt egy komoly cél, komoly határidőkkel, valyon mi köthet le egy gyereket? Milyen feladatot lehet neki adni, hogy végig vigye?
Azért kérdezek ilyen hülyeségeket, mert ez határozza meg az die -vel szemben támasztott igényeket.
UI: Én általában C -ben kis konzolos, de leginkább daemon jellegű szolgáltatásokat irogatok. Keresgéltem valami jó kis IDE után, de valójában NINCS. Mindegyik elment valami egészen bonyolult, csoportos fejlesztés és ráerőszakolós filozófiába (Anjuta - CVS - automake ...).
Ráadásul mire belövöd addig kihhullik a hajad. Amennyiben nem kell a hálózat kezelés, gyereknek, előkapnám a Turbo C talán 1.2 verzióját, esetleg a Quick C valamelyik DOS alapú variját. Gyorsabb egy kis 500 M partíción egy DOS -t felcsapni, mint a Linux X -es verziójihoz tervezet/készített monstre IDE -jével az időt b'szni. Ráadsául az említett cuccokhoz hatalmas irodalom gyűjtemény tartozik, qamivel nagyon komoly dolgokat meg lehet tanulni.

* Én egy indián vagyok. Minden indián hazudik.

+1

Aztán ha így megvannak az alapok, bele lehet kóstolni az objektumokba, aztán átnyargalni egy "automatiksabb" IDE -re.

(Mondjuk személyesen első nyelvenk inkább a Pascal -t ajánlanám, egy kezdő számára talán valahogy "olvashatóbb", könnyedebb. Nomeg ahhoz is rengeteg irodalom létezik.
És akkor már Pascalban bele lehet kóstolni az objektumokba, és az ObjectPascal jóval egyszerűbb, mint a C++. Viszont, ha már az ObjectPascal -ban megértette az objektumok működését, filozófiáját, akkor onnantól más sokkal könnyebb dolga van áttérni C és C++ -ra.
Persze ehhez 1-2 év biztosan kell, de nem is lehet egy nyár alatt megtanulni programozni...)

-1
Úgy tesztek, mintha nem lehetne "Hello World" appot csinálni az un. "projektes ráerőszakolós" Anjuta/KDevelop alatt. Magyar nyelvű, kettő katt az egész, egyszer kell megmutatni, elmagyarázni, és pötyöghet a gyerek, egy gombnyomás a fordítás, egy másik a futtatás. Ennyi. Egy 12 éves egyáltalán nem kicsi már az ilyenhez szerintem. Ehelyett ősrégi, nem szabványos dolgokkal akarjátok traktálni, amit már "senki" nem használ.

Turbo, Quick C-t nagyon gyorsan le kell torolni, meg a maradvanyait is, mert hulyeseget tanul meg a gyerek, aminek mar semmi koze nincs a mai C cuccokhoz. Nekunk Borland C-t kellett hasznalni OKJ tanfolyason, hat ne tudd meg. Mai eszemmel tudom, hogy en tobbet tanultam KR konyvebol, mint amit ott oran el tudtam sajatitani (mellesleg inkabb feldobtam egy debiant vmware ala, csak hogy ne kelljen azzal a szornyuseggel dolgozni).
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

A Borland fordítók nem voltak igazán szabványosak, de a kezelői felületük (IDE) nagyon kezes volt. Emiatt érdemes kisebb programokhoz RHIDE-t vagy XWPE-t használni, ezek a GCC-t noszogatják, tehát semmi Borland féle hülyeség!
Ha egy szimpla text-editorral írt program esetleg furcsán viselkedik, akkor a legegyszerűbb módja a hibakeresésnek, ha ráengedjük az RHIDE-t. Az RHIDE progit gyakorlatilag már nem fejlesztik, de amire eddig is jó volt, ahhoz nem is kell.

Na, pont most írtam volna, de már itt van. Ez tényleg hasonlít a régi Borland környezetre. Más kérdés, hogy egy ilyennel inkább csak algoritmusok tanulmányozására lehet egyszerű programokat írogatni, mert ma már túl sokat kell tudni ahhoz, hogy az ember átverekedje magát az op. rendszeren, ahogy fentebb írták. De tanulni pont jó lehet, ha a gyerek tanulni akar, és nem azt várja, hogy két képernyőnyi hosszúságú program quake3 szintű eredményt nyújtson.

(lehet hogy hülyeég amit írok, csak óvatossan oltsatok :P )
Én csak 1.5 éve kezdtem foglalkozni a "programozással", de még komoly dolgokat nem alkottam :). Pascalban megtudom csinálni az érettségi feladatokat aztán annyi, de egy 12 éves gyereknek simán megtudnám tanítani azokat a dolgokat amit én tudok, sőt szerintem így hogy nincs akkora tudásom még sokkal könnyebben és hétköznapibb nyelven tudnám elmagyarázni a dolgokat. A pascal ugyebár egy magas szintű nyelv és sokkal távolabb áll a számítógép valódi működésétől ezért is lehet hamarabb megtanulni :).
A C és az assembly alacsony szintű nyelvek(a C-t egyáltalán nem ismerem még) és sokkal közvetlenebb a számítógép hardverével. Én csak a PIC programozáshoz használom az assembly-t (majd később nagyon szeretném megtanulni a C-t is), de egyszerűen nemtudom elképzelni, hogy ezt egy kisgyerek hogy fogja megérteni :S
De látom, hogy te mindenképpen C-t akarsz tanítani neki, hát sok sikert :). Könyvek olvasgatását egyelőre hülyeségnek tartom, mert nem gyerekeknek írták őket és eléggé érthetetlen lehet számára, talán még a kedvét is elvenné az egésztől. Egyszerű célprogramokkal könnyen megtaníthatóak az algoritmusok sztem ... A hexa és a bináris számrendszert jó ha ismeri de kétlem, hogy szüksége lenne rá egyelőre.
Sajnos segíteni nemtudok az eredeti problémádon , de nagyon kiváncsi lennék majd hogy hogyan haladsz ezzel a C tanítással :) .

"A C és az assembly alacsony szintű nyelvek"

Upsz, azért ez így meredek. Nézz meg kérlek egy C forrást akárhol, és döntsd el, hogy ismereteid alapján mihez hasonlít jobban, pascal-hoz, vagy asm-hez. :)

A C nyelv nem attól hardware közeli, hogy asm utasításokat kell irogatnod, hanem, hogy a változók, illetve a velük végzett műveletek gyakran közvetlenül fordíthatóak asm utasításra. De ettől ez még egy normális struktúrált programozási nyelv.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Szigorúan véve, a klasszikus - Kernighan & Ritchie - által leírott alapok igenis "alacsonyszintről" kell beszélni - én gyakran mondom, hogy szimbolikus, univerzális assembler. De mint ahogy assemblerben is lehet, olyan struktúrákat és kódot írni, hogy a "tetején" őgy tűnik mint egy magasszintű programnyelv.
Én inkább visszautalnék a "születési idejükre" és módjukra. A C tulajdonképpen az első UNIX jellegű operációs rendszer létrhozásával párhuzamosan a 60 -as években jött létre, alapvetően renbdszerprogramozásra. A Pascal asszem a 70 -es évekhez kötődik és matiemetikusok hozták létre, matematikai problémák megoldásához - pl. kiválóan kezeli a sok dimenziós mátrixokat. A C mátrix eszköztára nagyon szegényes. A C attól válik "magas szintű" programnyelvé hogy hatalmas előregyártott könyvtárak állnak rendelkezésre. A PAscal pedig azért alkalmas bizonyos rendszerszintű programozásra mert it-ott bele lehet túrni a rendszerbe is. (azért megnézném amikor atomikus test and set utasítást kreálnak vele, vagy task schedulert)
Persze az elvetemültségnek nincs határa, van aki assemblerben akar windows programozni és aki basch scriptből akarja a lebegőpontos CPU -t piszkálni.
"Cipőt a cipőboltból"

* Én egy indián vagyok. Minden indián hazudik.

Sztem ennyi idős korban az a legfontosabb, hogy az elméletet tanulja meg és tudja készség szinten alkalmazni. Aztán később ezt a tudást olyan nyelvre viszi át, viszonylag kevés energiabefektetéssel amire csak akarja.

Én pascalban kezdtem, de igazi felüdülés volt amikor tudtunk szerezni egy TurboC fordítót (megjegyzem nem kis energiabefektetéssel :-) ). Szerintem a C lényegesen probléma-közelibb, és jó nyelvnek tartom az induláshoz.

Szerintem kezdjetek egy mcedit (vi, gedit, kate, stb.) és gcc terminálból párossal, legalább így megtanulja a fordítás és a linkelés folyamatát is, aztán később már jöhet a bonyolultabb ide, az automake stb.

a legfontosabb, hogy az elméletet tanulja meg és tudja készség szinten alkalmazni.

[objektiv]
Ezt szeretném én is kihangsúlyozni a C mellé és a scriptnyelvek ellen - én is C-vel kezdtem; és bár elsőre megérteni bonyolultabb volt, mint most egy pythont vagy perlt, nagyon örülök hogy 12-13 évesen (ami nem volt rég) nem scriptekkel kezdtem: scripteket írni sokkal könnyebb mint C kódokat (legalábbis alapszinten), de ha valaki megtanul egy scriptnyelvet kezdésnek, szerintem nehéz átszokni utána a fordításra - márpedig a C-re még mindig nagyon sokszor lehet szüksége. Ha tud C-ben (de lehet az pascal, basic, tényleg tök mindegy mi) maradandót alkotni, akkor pillanatok alatt megszokja az interpreteres gondolkodást is, fordítva pedig sokkal nehezebb mindez.
[/objektiv]

[teny]
Amiben viszont biztos vagyok, az az, hogy apám kb. ugyanebben a helyzetben volt kb 5 éve. Akkor még tényleg kevesebb lehetőség volt az oktatásra, de mivel a két nyelv amihez profi szinten ért az a C (,C++, C#) és az ASM, nem volt nehéz számára a választás.
Komolyra fordítva a szót, az már elhangzott itt, hogy az a fontos hogy mit tanul, nem azt hogy milyen nyelven - ehhez csak annyit, hogy ha a srác azt mondta, hogy ő valami komoly dolgot szeretne tanulni, akkor nem lesz probléma, ha az elején egy kicsit nehezebb - nyilván megérti, ha azt mondod neki, mint szülő, hogy a komolyabb dolgokat nem lehet csak úgy játékból megtanulni (hiszen a komoly dolgok egyik legfontosabb ismérve a komolyság).
[/teny]

Miért is nehéz átszokni a fordításra? Ezt nagyon nem értem... Jól és szépen kódolni Perl-ben semmmivel sem könnyebb (lásd még TIMTOWTDI), mint C-ben, bár egy adatbekérés/kiíratás relative egyszerűbb bír lenni, hogy pl. a fájlkezelésről ne is beszéljünk (egyszerű esetek, nem a mutatóra mutató mutatót módosító függvényre mutató mutató értékét matató függvény hívásának mi lesz az eredménye).

A C vs. Perl vs. Python vs. brainfu.k vs. akármi tényleg csak hitvita -- egy bizonyos szintig. Itt viszont ezen a szinten túl kell lépni, és megnézni, mivel lehet hosszabb távon lekötni egy felső tagozatos gyerek figyelmét, mi az, amiben a kudarcok és a sikerek aránya az elejétől kezdve ez utóbbi javára billen?

Algoritmusokat, feladatmegoldást kell tanítani, az iskolai tananyaghoz használható(!) feladatokat kitalálni, és azt megoldani -- sok-sok sikerélménnyel. Erre a célra egy egyszerű, gyors fejlesztésre alkalmas nyelvet célszerű használni, és bár a szigorú szintakszis fontos lehet (egy apró elírás ne másként működö, hanem nemműködő programot eredményezzen), de nem az az elsődleges szerintem, hanem a sikerélmény, amit a tanulás nyújt.

"Miért is nehéz átszokni a fordításra?"
Azért mert nincs pár dolog a scriptnyelvekben ami pl a C-ben van.
Példáúl a script nyelvekben háttérbe szorul a változó típúsának/láthatóságának/életciklusának fogalma. A mutató, a referencia fogalma. És még sorolhatnám.
Pont emiatt könnyebb script nyelven programozni egy szintig. (Mert komolyabb dolgokhoz azért már tudnod kell, hogy ezek az adott nyelvben hogy jelennek meg a háttérben.)
Amint az ember áttér, ez mind a nyakába zuhan. C++-ban iszonyú erővel már fordítási időben, C-ben lassan csordogálva futási időben...

Persze ezeket megtanulja az ember akkor is, ha C-vel kezd, csak nem mindegy, hogy úgy tanul C-t, hogy semmit nem tud, és rákészült a nehézségekre, vagy úgy, hogy írt már pár komolyabb dolgot más nyelven, és halálba idegesíti, hogy még a hello world sem fut rendesen...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

javaban sincs tulsagosan eloterben a pointerezes meg a direkt memoriakezeles, akkor mar az is gagyi?
Es ha nem valami kritikus alkalmazast irsz (pl device driver, amibol az utolso cseppig is ki kell hajtani amit lehet) akkor miert erdekes hogy az adott nyelv mit hogy csinala hatterben?

Mellesleg ez az egesz szal kicsit eltert a tematol, es programnyelv-flame lett belole.
Visszaterve az eredeti kerdesre, szerintem valami nagyon egyszeruvel kell kezdeni, akar mc+gcc is megteszi es nagyon egyszeru programok kzdetben (grafika majd kesobb ha eljut odaig). ne felejtsuk el hogy egy 12 evesrol van szo, a logo jo volt arra hogy amolyan keszseg szinten logikat/algoritizalast lehessen benne gyakorloni, de a c az egy nagy lepes ehhez kepest, plane ha elso korben mar memoriat meg pointereket akarsz kezeltetni szerencsetlen gyerekkel

Van még olyan nemzet, ahol 12 évesen a népesség jelentős része nem él nemi életet? Az a nemzetiség, amelyikre gondoltál, 12 évesen szül. Én nem mentem ilyen messzire, csak annyit tippeltem, hogy nemi életet él. Ez a kijelentés sokkal több nemzetre igaz szerintem.
--
unix -- több, mint kód. filozófia.
Life is feudal

Kate+gcc

A felulete hasonlit a legtobb IDEhez, van beepitett terminalja, es minden nyalanksag ami kell hozza. Ismeri a legtobb script es metanyelvet is.
Be lehet allitani, mikepp forditsa a kodot gombnyomasra (gcc vagy makefile).

Amugy a makefile-t az elso egy-ket program utan meg lehet magyarazni. Ha a gcc-t megerti, akkor azt is fogja.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Azon elgondolkoztal mar, egeszen pontosan milyen programokat akarsz tanitani a gyereknek?

Ertem en, hogy a 90-es evek elejen a kepernyo szoveges volt (C64-en kezdtem, elso PC-s rendszerem DOS 5.x, nem kell bemutatni), de a gyerek ilyet legfeljebb a muzeumban, ha latott (meg amikor apuka linuxa bebootol, ha nem hasznalsz valamilyen splash-modult).

A mai programok tobbsege esemenyvezerelt, mi tobb, grafikus (ki gondolta volna). Szemben a programvezerelt rendszerekkel, meg szoveges konzolokkal, amikre minket tanitottak anno.

Namost esemenyvezerelt programot, plane GUI programot irni C-ben szerintem kinszenvedes (GTK+, WinAPI tapasztalat mondatja ezt velem), olyannyira, hogy ezt egesz sokan eszrevettek, es elkezdtek az objektumorientalt paradigmat,ami aztan a 90-es evek vegere meghatarozo is lett...

Sokkal egyszerubb szerintem a gyereknek azt mondani, hogy nezd, ez az urhajo, urhajo->utkozz(), meg urhajo->sebesseg=10, mint azt mondani, hogy UrhajoUtkozz(melyikurhajo) es hasonlok.. De ez lehet csak az en velemenyem. Semmikeppen nem iratnek programvezerelt szoveges kodot a gyerekkel, hisz az tavolrol se kelti azt az illuziot, hogy ezzel a nagy feladatok is megoldhatoak, mint ahogy tenyleg nem is.

C-ben, Pascal-ban, sőt asm -ben is lehet objektum-orientált _szemléletű_ programot írni.
Az objektum-orientáltság inkább függ a szemlélettől, mint a nyelvtől.
Az a nyelv, mely külön absztrakciókat nyújt az objektum-orientált programokhoz, csak egy plusz eszköz, plusz segítség a programozónak.

Az objektum-orientáltság szerintem elsődlegesen tervezési, és nem kódolási oldalon hasznos. Oop-szemléletű, de nem teljesen oop nyelvek használatából csak kavarodás lesz (most akkor ez miért lehet így, mikor azt mondtad, hogy nem...). Ezért volt jó kezdő nyelvnek a "szigorú" Pascal: ott nem igazán lehetett C-s, netán Perl-jellegű förmedvényeket (pontosabban ötletes megoldásokat) látni...

Egyébként meg az ojjektumokban is egyszerű algoritmusok vannak leprogramozva, amiket kintről (másik ojjektum) lehet büködni, hogy csináljanak valamit valamivel. Ebben a korban én mindenképp arra öszpontosítanék, hogy legyen minimum 30-40 ötletem, amit egyszerű módon meg lehet valósítani, csinál valamit, a gyerek tanul belőle szemléletet, módszereket, aztán lehet apró elemekből várat építeni.

Az objektumorientált, eseményvezérelt irány sem rossz, csak jó környezet kell hozzá, anno C/C++ a suliban SGI-ken ment, és ott a GL-ben elég egyszerűen lehetett szép és jópofa grafikus dolgokat összerakni húsz-ötven sorban, kommentekkel együtt.

C IDE érdekli a kérdezőt. Kapott tippeket.

Most vagy adjunk neki időt, hogy megnézegesse ezeket és döntsön, vagy szavazzuk meg, hogy a gyereke mit használjon...
--
unix -- több, mint kód. filozófia.
Life is feudal

Ugyan nemnagyon értek hozzá, de ha -viszonylag- egyszerű grafikát akarsz tanítani, akkor OpenGL (2D -s módban) lehet vele vonalat húzogatni, *szöget rajzolni stb...
Van egy Lazarus nevű (free)pascal IDE, ami eléggé hasonlít a Delphi-hez.
http://wiki.lazarus.freepascal.org/OpenGL

szerk: ha nem jó az OpenGL, akkor szerintem Qt, amivel szerintem sokkal gyorsabban/könnyebben lehet kezdeni.

szerk2: esetleg eredeti Delphi kezdeni nagyon egyszű, akár szöveges, akár grafikus programot könnyű vele írni.

+1
Szerintem a GLUT ma egy nagyon barátságos és használható grafikus eszköz. Nem sokkal bonyolultabb mint régen a Borland graphics unitjai. Szerintem a gyerek egy-kettőre megérti, és gyorsan lehet vele látványos dolgokat csinálni. Könnyen írhatsz is egy ilyen graphics.h-szerűséget, ami elrejti előle a bonyolultabb részeket. Később majd piszkálhatja azt is.
-
J

DOSBox alatt teljesen jol fut a Turbo/Borland C.
Linux alatt Kate szerintem teljesen eleg. DE-tol fuggoen csinalhatsz egy ikont a forditashoz, ha nem akarod, hogy parancssort lasson (egyszeruen kilinkelsz egy shell scriptet).
Win alatt meg Devcpp.

Ha van hozza kedved, mutasd meg neki a Colobot nevu jatekot, nagyon jopofa, robotokat kell benne programozni (szinten win alatt, C++-szeru szintaxissal).

----
Sooner or later you had to talk, even if it was only because you'd run out of things to throw. - Pratchett
honlap készítés

Ahogy mar tobben is leirtak egy egyszeru szovegszerkezto es gcc eleg lesz. Azt a tanacsot viszont kerulnem hogy memoria mukodese meg szamabrazolas. Ugy kitekintes szintjen meg lehet emliteni hogy miert csak ilyen nagy szamokat lehet a valtozoba tarolni, de a tobbi szaraz es unalmas, elveszi az ember kedvet szerintem.
Nem kell pointerekkel foglalkozni az elejen, csak par egyszeru ciklus meg valtozo varialasa, nagyon jol el lehet vele jatszani. En tudom mert korulbelul en is while meg for ciklus tudtam akkoriban irni pascalban es nagy elmeny volt, szerintem meghatarozo elmeny (most programozo vagyok/leszek).
A C meg tokeletes elso nyelvnek, ne hallgass a tobbiekre.

Ha kifejezetten raunt a Logo ra akkor esetleg lehet kb ugyanazt csinalni C-ben, de oszinten csak akkor ha tenyleg raunt. A 12 eves altal irt programokra a C pont olyan jo mint a logo es forditva, csak nehezebb olvasni. En inkabb egyre nehezebb - komolyabb - feladatokat probalnek kitalani neki akar logo ban is, elvegre az a programozas nem pedig a nyelv.
Primtesztet ha mar tudja hozza a fogalmakat akar, de lnko, lkkt, maxker, feltmaxker, elsofoku egyenletmegoldo, buborek rendezes, "kitalalom a szamot amire gondoltal kerdezgetve kozelitve" stb biztos mehet.
==
`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.

Sokan lehordtak már engem mindenfélének amiatt, mert nem értek egyet azokkal akik az angolt akarják ráerőltetni minden felhasználóra, mondván, hogy az angol "a számítástechnika nyelve".

Ellenben én állítom, hogy "a C a számítástechnika nyelve". A C, az bizony "A" programnyelv! Amely programozó nem ismeri a C nyelvet, nos az a szememben gyanús, hogy nem is igazán programozó. Legfeljebb valami hobbi-izémizé, jobb esetben talán unatkozó "szkript-kiddi". (Nem mintha lebecsülném a szkript-nyelveket. Szó sincs róla. De azért az igazán komoly dolgokhoz a C való).

Valójában persze nem is amiatt, mintha mindent C-ben kéne megoldani. De aki alapvetően másban progranyozik, annak is illik tudnia "C-ül", egyszerűen mert ezáltal egyfajta _gondolkodásmódot_ tanul meg. Egészen másként látja a memóriát, rutinokat, stb, mintha csak más nyelvet ismerne, mert bár a C tényleg nem "igazán magas szintű" nyelv, de épp ez a jó, mert a nála "magasabb" szintű nyelvek belegebednek, hogy elrejtsék a program igaz belső felépítését a programozó elől.

Aztán ha tovább akar lépni C után "magasabb szintek" felé, semmi vész: ott a C++, a C teljesen logikus továbbfejlesztése.

Én teljes mértékben híve vagyok annak, hogy egy 12 éves valaki C-t tanuljon, s hozzá akár első programnyelvként. Kérem szépen, a 12 évesek már nem hülyék!

De ehhez nem kell valami hülye IDE. Pont úgy, ahogy valaki javasolta: egy virtuális terminál, a forrást írja meg VIM-ben vagy mcedit-tel, aztán lefordítani egy paarancsssoros utasítással és jóccakát'!
-------------
Regényeim:
http://adlibrum.hu/Poliverzum/
http://www.novumverlag.hu/novitaeten/8/?product_id=22&detail=1
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó

Nem programkódot írni kell megtanulni, hanem programozni. A feladatot egyrészt a tervezési kritériumoknak, környezetnek megfelelően megfogalmazni, majd az így megfogalmazott elemeket lekódolni. Elsőzör nem nyelveket kell tanulni, hanem gondolkodni, majd megismerni több nyelv előnyeit, hátrányait, legfontosabb lehetőságeit. Ez alapján ki kell választani az adott feladathoz meg magunkhoz az optimálisat, és abban lekódolni a korábban megtervezett dolgokat.

- Mindenképpen tanítsd meg az információ önálló összevadászására
- Kerüld el a régi dolgokat (Borland IDE és társai), mert csak neked tűnik egyszerűbbnek neki csak teher lesz később
- Szerintem is elég a gedit+makefile.
- Debuggert az elején akár ne is adj a kezébe. Egyrészt óriási élménye lesz mikor rátalál magától, másrészt megtanul nagyobb részeket a fejébe tölteni a saját programjából amivel tornáztatja az agyát és magasabb szintű absztrakcióra kényszerül.
- Szerintem igenis érdekesek a számrendszer átváltások a prímszámkeresés és a hasonló matematikai dolgok. Ha ezek nem izgatják a fantáziáját nem fogja lekötni a grafika sem mert látványos dolgokat azért nem egyszerű létrehozni, lássuk be.
- Grafikai könyvtárnak én is az SDL-t vagy a Glut-ot javasolnám, mert modernek, platformfüggetlenek és neten simán találhatsz róla doksit. Nem mellesleg könnyen elindulhat róluk 3D irányba, ami úgyis izgatni fogja a fantáziáját.
- Szerintem hihetetlen hasznos és nagy élmény a gépközeli dologok megértése. Csak ezért támogatom a C-t egyébként inkább Javát javasolnék. Viszont amíg van türelme nem baj ha ASM-ezik is egy kicsit. Bár ma nehéz olyan feladatot elképzelni amihez megérné használni.
- Ha már hekkert akarsz nevelni belőle akkor felejtsd el a zárt kódú vacakokat és nyílt platformon nyílt eszközökkel tanítsd! Csakis a saját érdekében! :-) Én kb 14 évesen találkoztam a GNU-val először és nagyon érdekesnek találtam annak ellenére hogy eredetileg csak az érdekelt hogy működjön valami és azért kezdtem túrni a netet. Aztán az lett a vége hogy órákig bújtam a cikkeket és meglepődtem hogy létezik egy ilyen közösség.

Esetleg nézd meg az LCC-t. Viszonylag egszerű a felülete, bár hátránya, hogy projektet itt is létre kell hozni és csak Win32 alatt megy.

Ha maradsz a C-nél, akkor szerintem érdemes lehet két menetben megtanítani. Elsőre szerintem teljesen kihagyhatnád a pointereket, elég, ha a strukturált programozással, meg a C alapvető csalafintaságaival tisztába jön, aztán ha már minden más jól megy, akkor jöhet az agyszikkasztó pointerezés ezerrel. :-)

A C# szerintem azért nem alkalmas a feladatra, mert alapvetően mégiscsak OOP nyelv. Ha csak strukturáltan dolgoztok benne, akkor is egy csomó "felesleges", zavaró tanulnivalót jelent. Ráadásul a végén csak egy kis darabkáját fogja tudni használni, míg a C-nél jóval nagyobb az esélye, hogy belátható időn belül teljesen elsajátítsa a nyelvet. Ez szerintem nem csak pedagógiai, hanem gyakorlati szempontból is hasznosabb lehet.

Én annak idején Pascalban tanultam meg strukturáltan programozni, aztán az OOP-t is azon kezdtem megérteni. A strukturált programozás tanulására szerintem tényleg sokkal jobb, mint bármelyik másik nyelv. De ez csak egy gondolat volt.... :-)

-------------------------------------------------
" - Amerikanische Infanterie! Angriff! Angriff! "

Ha már feladat, akkor (prímszámkeresés után) "akasztófa" prím tényezőkre bontás. (Ezt nagyon jó megírni, mert mi egy csomó olyan leckét kaptunk, ahol fel kellet bontani.)

Esetleg egy titkosító programot nem RSA-ra gondolok, hanem olyan kis egyszerűre, hogy pl.: minden betű karakterkódjához hozzáad 42-őt vagy XOR -olja 42-vel. Bár kicsit utánaolvasva, az RSA sem olyan ördögi bonyolult, ha csak kicsi kulcsot használsz.
http://hu.wikipedia.org/wiki/RSA

12 evesen en is pascalt tanultam, de tul mely szintre nem jutottam. :) De kesobb nem volt igazan nagy gond a pascalos tudasom C-re konvertalni. Szoval en erre szavazok!

akkor inkább apt-get vagy yum. De ha freepascal, akkor ott a Lazarus mint IDE.

Másik ötlet feladatra: (linux alatt) frekvencia generátor. (csak különböző értékeket kell írni a /dev/audio fájlba.)

szerk.: szerintem is jó a pascal, én is azzal kezdtem (Delphi) és egész jó dolgokat lehet vele csinálni.

IDE: szerintem ilyeneket kellene tudnia:
-Színezés
-ha ott van egy függvény neve, és nyitok egy zárójelet, akkor jelenítse meg, hogy milyen paraméterei vannak, azuoknak a típusait stb...
-ha ott egy objektum, és lenyomom a "."-ot, akkor írja ki az objektum változóit, függvényeit.
-Debugger, pl. ha léptetem, akkor lehessen látni a forrásban, vagy ha változó fölé viszem az egeret, akkor jelenítse meg a tartalmát.
-Még az is jó ha gombnyomásra fordít.

Namost, ha van egy ilyen IDE-d, akkor ellustulsz és nem akarsz kwrite+gcc -vel dolgozni, és mindig azzal töltöd az idődet, hogy egy nyelvez egy "jó" IDE-t keress. (Saját tapasztalat)
Viszont egy ilyen IDE-vel sokkal könnyebben lehet fejleszteni.

dobsz neki egy emacs-et, hadd szokja :)

--
“A well placed underscore makes the difference between a s_exchange and a sex_change”
— 8048 Users Manual, Intel 1977.

TIPP (ezért ne hurrogjatok le): ha nem feltétlen szükséges a linux támogatottság, akkor nézz rá a Pelles C-re. http://www.smorgasbordet.com/pellesc/
Még pár éve, mikor Windows-om volt, egész szépen eljátszadoztam vele.
Akkor még elég egyszerű volt (most sem látszik nagyon bonyolultnak). Elvileg szabvány C.

Egyébként linux alatt én is gedit-re szavaznék.

gedit+gcc
VAGY
Geany, sztem ez lesz, amit keresel.:)
___________________________
http://lorem.hu
Az emberi tudás mindenkié!

Ha egy mini IDE kell, akkor a Qt-hez járó QDevelop szerintem nem rossz választás. Egy nagy gondja van, hogy nem tudom, hogyan lehet átállítani gcc-re g++ -ról. Ha egyáltalán át lehet állítani!
Én is viszonylag kezdő vagyok a C++ területén, éppen ezért nekem nagyon bevált. Kezdetben a KDevelop-val próbálkoztam, de én is annyira bonyolultnak találtam, hogy feladtam. Ekkor ajánlották a QDevelop-ot. Természetesen alkalmas nemcsak Qt projektek, hanem egyéb C++ projektek megalkotására. Ha nem lehet átállítani gcc-re, akkor sem hiszem, hogy nagy gond lenne pl. a math header helyett a cmath headert beírni a fájlba. Egyébként meg teljesen C stílusban, objektumok nélkül, tudtok vele programozni.
A projekt fájl nagyon egyszerű felépítésű. semmi gondotok nem lesz vele. Hamar megtanuljátok. Az egész IDE felépítése szerintem nagyon jó, könnyen használható. Olyan apróságok teszik számomra nagyon kedvelté a szövegszerkesztőjét, mint pl.:
1, Az általában nem látható space és tab karakterek itt halványan (nem zavaró módon) látszanak
2, ENTER leütése esetén ugyanannyi space és tab karaktert automatikusan beszúr a következő sorba, mint az előzőben volt.
3, Ha egy if utasítás végén leütöd a nyitó kapcsos zárójelet "{", automatikusan megcsinálja a bezárást is, és új sort is nyit a blokk részére egy tabulátorral beljebb pozicionálva.
stb.

Szerintem a Geany pont ilyen, még csak a szintaktikai kiemeléses szövegszerkesztő kategória, de van hotkey a fordításhoz...

qdevelop

Ez C++, de az ugye C-vel kompatibilis.

Egyszeru, kb. annyit tud, mint a regi Borland kornyezetek.

Szia!

Úgy látom a téma újra felkerült és senkinek nem tűnik fel, hogy nyár elején kérdezted amit kérdeztél :-). Tehát jó eséllyel már túl van a fiad a tanfolyamon...

Ha véletlenül olvasod ezt a kommentet, leírhatnád, hogy végül milyen eszközöket adtál a kezébe, tetszett-e neki, vagy inkább mással foglalkozott a nyáron?

A geany nagyon jó választás volt. Tudom másnak is ajánlani.

Sajnos, a kitartás azonban hiányzott a fiúkból, én meg nyáron nem akartam
őket gyötörni, hisz ők kérték. (Ja, a másik fiam is csatlakozott.)

Amíg eljutottunk (változók, tömb, ciklus, egyszerű scanf / printf )
könnyen fogták az adást. Ehhez a geany igen jó felület volt. Sajnos
tovább nem jutottunk, de ez a fiúkon múlt.

Az a baj a java-val, a php-vel, meg az összes többi magasszintű nyelvvel, hogy mivel kvázi célszerszámok, sokmindent eltakarnak a user szeme elől, ami a munka során nyilván jól jön, hogy pl, nem kell malloccal és a barátaival szívni, vagy épp a nyelv elvégzi a szükséges típuskonverziókat. Ez tök jó, ha gyorsan kell haladni, de inkább legyen egy pöppet nehezebb az elején és szívjon ezzel-azzal a gyerek, hogy aztán később jobban átlássa azt, hogy mi is történik a háttérben.
Én pl örülök, hogy anno Pascallal aztán C-vel kezdtem. Elsőre nem volt könnyű, de most jól szokott jönni a kicsit erőforrás-tudatosabb, hw-barátabb gondolkodásmód. Nem baj az, ha nem ír elsőre aknakeresőt, de később sok haszna lesz a kezdeti nagyobb szívásból. Szerintem.

"de inkább legyen egy pöppet nehezebb az elején és szívjon ezzel-azzal a gyerek, hogy aztán később jobban átlássa azt, hogy mi is történik a háttérben"

Egy 12 éves gyerek lelkesedését így lehet jól lohasztani. Szerintem a gyerekek oktatásának a lényege az érdeklődés folyamatos fenntartása és a gyakori sikerélmény. Valószínűleg ezt a Pythonnal könnyebb megvalósítani.

Ha barkácsolni kezdenétek, valószínűleg akkor is inkább az egyszerűbb szerszámok használatával kezdenéd nem? Kalapács, véső, fúró, nem pedig esztergagép.

Persze, hogy a sikerélmény és az érdeklődés folyamatos fenntartása a lényeg, de sztem nem azzal éred el, ha a kezébe adsz egy olyan eszközt, amivel gyorsan tud összecsapni csillivilli dolgokat, közben meg nem ért meg semmit a lényegből. El lehet dönteni, hogy gyorsan akarsz felszínes tudást átadni, vagy inkább mélyebb, alaposabb ismereteket akarsz közölni.

A hasonlatod pedig pont fordítva logikus szerintem. Az egyszerű eszközök, mint pl. kalapács, véső, fúró azok, amikkel sokkal több szívás van, de sokkal közelebb engednek a fához. Az esztergagép a profik játéka, és ahogy egy kezdő asztalost sem engednek még a közelébe sem, még meg nem tanulta rendesen az alap szerszámok használatát és jelentősségét. Ugyanúgy a Java is egy modern célszerszám, amit viszont csak azok tudnak jól használni, akik értenek ahhoz is, hogy mi történik a háttérben. Nemde?

Ugyanígy kéne oktatni a programozást is, és akkor talán nem jönne ki az egyetemekről annyi ortopéd arc, aki tud webalkalmazást összedobálni ugyan, de az a filozófiája, hogy (szó szerinti idézet egy ilyen példánytól, és sajnos hemzsegnek): "ugyan már, a P4-esek korában ne szőrőzzünk már azon, hogy egy [akármi] reprezentálásakor 2x3 byteot elpazarlunk" és mivel nem is érti és nem is érdekli, hogy igazából mi is történik a gépház alatt, így aztán meg is lehet nézni az eredményét a munkájának. Biztos mindenki látott már "kiválóan megírt alkalmazást"...

Ne érts félre. Nyilván nem memória-allokációval és szálkezeléssel kell kezdeni, sőt, nem feltétlenül ennyire alacsony szinten, de jó erős alapok nélkül nem lesz belőle jó kóder sosem. Oké, ne legyen C, de mindenképp alacsony(abb) szintű, eljárás-orientált nyelv legyen, mert az a gép fiolzófiája, nem pedig az OO. Hülyén gondolom?

"ugyan már, a P4-esek korában ne szőrőzzünk már azon, hogy egy [akármi] reprezentálásakor 2x3 byteot elpazarlunk"

Attól függ, hogy mi a cél: pl. a gyorsaság néha fordítottt arányban van a memóriafelhasználással.

Illetve lehet cél könnyen karbantartható kód írása is...

Soroljak példákat, amikor kifejezetten célszerű hat byte-ot elpazarolni egy struktúrában?

Természetesen van olyan eset, ahol az általad említett megfontolások alapján a programozó dönthet a "memóriapazarlásról", ebben igazad is van. Az említett eset tipikusan nem olyan eset volt, sokkal inkább a leszarom-nemérdekel-nemértekhozzá-megkülönbenis hozzáállás szép példája... Azóta az említett kollega már szerencsére más cégnél erősíti a csapatszellemet...

Mondok akkor egy másik hasonlatot :) A repülés oktatását szerinted mivel kezdik? Vitorlázó repülővel! Az erős alapokat nem az eszköz bonyolultsága biztosítja. Az algoritmusokat és adatstruktúrákat Python-ban sokkal egyszerűbben, de ugyanolyan alaposan meg lehet tanítani. Aztán ha tényleg megfogja a dolog, akkor majd tanulhat "vadászpilótának", és folytathatja C/Java/Lisp/akármi-vel is :)

Valóban, viszont ahogy a vitorlás repülőn sincs sok kallantyű meg bizgentyű, és sokkal inkább oda kell figyelni a szélre, a levegőre, a közegre, amiben létezik, úgy az alacsonyabb szintű nyelveknél sincs sok lehetőséged (mármint, nincs instrumentális támogatottság) és ugyanúgy sokkal jobban ki vagy téve a hardware kénye-kedvének. A példa itt is jó, csak pont fordítva :)

És a Python szintaktikus szigorúsága sem jöhet rosszul később, ha már a tanulóidőben hozzászokott valaki a rendezett kód írásához.
(De ennyi erővel a C "régies" és néha idegesítő korrekt memóriakezelést kikényszerítő kötöttségei is jelenthetnek komoly előnyt majd, ha pl. összetett adatszerkezeteket vagy más magasszintű készen kapott dolgot kell optimálisan használni/máshogy megírni.)

Szerintem magadnak mondasz ellent. A te peldadat felhasznalva a Python, PHP pont az egyszerubb szerszam, amivel meg lehet tanulni a programozas alapjait, a C pedig az esztergagep, annak a kozelebe csak olyant szabad engedni, aki mar ismeri az alapokat, mert egyfelol sokkal konnyebben fogja megtanulni a C-t mas (egyszerubb) programnyelv ismereteben, a masik meg az, hogy C-ben eleg sokmindennel kell egyszerre foglalkozni, es az elvonja a figyelmet a programozas alapjairol (malloc, stringkezeles, etc.).

Nem tudom, de aki 0-rol tanul programozni, az elobb jobb, ha ossze tud rakni normalisan egy for ciklust, es csak kesobb tudja meg, hogy pontosan mi tortenik a hatterben, ugyanis egy program keszitesekor sutheted a hatter tokeletes ismeretet, ha a for ciklus szintaxisaval nem vagy tisztaban egyaltalan. A gcc-nek nem tudod elmagyarazni, hogy hat ize, ezt meg ezt szeretnem - le kell irni a for utasitast.
Majd ha tudja, hogy mit hogy kell irni, es kepes lesz egy 20-40 ertekes sorral rendelkezo fajlt max 3 szintaxishibaval megirni, akkor azt mondom, hogy igen, lehet neki elkezdeni magyarazni, hogy hogyan mukodik az adott program, meg milyen memoriakezeles jar hozza.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Lehet C kódot írni C++ nyelven is. A különbség csupán annyi lesz, hogy a fordító segít és nem gátol. Egy csomó olyan hiba esetén leáll, amit a C fordító megenged, és a program rosszabb esetben hibásan működik, jobb esetben pedig elszáll.

A magas szintű nyelv pont azért jobb választás, mert közelebb van az ember gondolkodásához, amilyen például az osztályfogalom is. A való világ tárgyakból (és élőlényekből) épül fel, meg lehet találni a közös tulajdonságokat, és így tovább. Ámde az kissé fura megközelítés, hogy vannak műveleteim, azt megtámogatom valamilyen adatszerkezettel, és lesz belőle valami. Pfuj.

"A magas szintű nyelv pont azért jobb választás, mert közelebb van az ember gondolkodásához, amilyen például az osztályfogalom is. A való világ tárgyakból (és élőlényekből) épül fel, meg lehet találni a közös tulajdonságokat, és így tovább. Ámde az kissé fura megközelítés, hogy vannak műveleteim, azt megtámogatom valamilyen adatszerkezettel, és lesz belőle valami. Pfuj."

Valóban közelebb van az emberi gondolkodásmódhoz, és modellezésre nyilvánvalóan sokkal jobban is használható, mint az eljárásorientált látásmód, de elfogadod, vagy sem - természetesen lehet pfujjolni az emberi gondolkodásmódtól oly távol álló, kicsavart, nyakatekert, ósdi eljárásorientált szemlélet miatt - a gép nem objektumorientáltan működik. Ha ezt nem érted meg már rögtön az elején és nem veszed figyelembe, sosem fogsz igazán érteni ahhoz, amit csinálsz.

Ja, csak hogy egy kicsit irritatív legyek, megkérdezném, hogy akkor az objektumok mik is? Mert szerintem adatszerkezetek, amik műveletekkel vannak megtámogatva, plusz még rájuk rakódik egy csomó plusz, mint objektumhierarchia, öröklődés, stb. Oké, így más, így kicsit könnyebb, de nem sok extra van bennük, ráadásul egyes nyelvekben az OO felesleges erőltetése sokszor csak bonyolít a helyzeten. Szerintem.

Amúgy nem azt mondom, hogy akkor eljárás-orientált gondolkodás, C, C, C! Úgy! Kussolszkisfiam ezt kell szeretned. Azt mondom, hogy az alapokat ebben kell megszereznie. Aztán mehet feljebb, ha van hozzá kedve, hisz valószínűleg nyilván jobban fogja érdekelni a mobilprogramozás mint a kernelmodul-írás. Ez így van rendjén. De el kell dönteni, hogy tanulás és megértés szempontjából mi a jobb, és felfelé vezet út, lefelé már - és ez tapasztalat - sokkal nehezebb, főleg mert az ember hajlamos ellustulni a jól megszokott kis technológiájában.

Alapvetően az a gond itt, hogy erre a kérdésre más választ fog adni egy IT-vel foglalkozó ember, meg egy olyan, aki drivereket ír mindenféle hardware-hez, és a maga részéről mindkettőnek igaza is lesz valamilyen szinten, hisz amíg az IT-s feneke alatt ott van egy szerverfarm, amin fut az alkalmazásszerver, amire fejleszt, és tényleg nem arra van szüksége elsősorban, hogy bitszinten optimalizált kódot írjon, hanem arra, hogy a kapott specifikációnak a megadott határidőn belül helyesen működő alkalmazást építsen, addig egy olyan emberke, aki pl. 64kbyte RAM-mal és egy 200 MHz-s ARM processzorral gazdálkodva kell, hogy működtessen ezt meg azt, nyilván máshogy fogja látni ezt a problémát.
Mindenesetre én még ennek tükrében is azt tudom mondani, hogy mivel bárhogy is nem akarnak ezzel sokan szembenézni, mindennek az 1 meg a 0 az alapja, jó, ha a kedves leendő kollegák is hozzászoknak, hogy bizony van olyan, hogy memóriakezelés, bittologatás, adatszerkezetek, stb.

"Alapvetően az a gond itt, hogy erre a kérdésre más választ fog adni egy IT-vel foglalkozó ember, meg egy olyan, aki drivereket ír mindenféle hardware-hez,"

Hát, ha drivert nem is írok, Linux kernelhez modulokat, stb. igen. Sőt, alkalmazásszintű tűzfalat (és proxy-t) is, az előbbinél a C-vel semmi bajom sincs. Csak ez nem befolyásolja az általános véleményemet, hogy alapvetően (pár kivételtől eltekintve) a C nem jó választás.

Én VisualBasic-vel kezdtem és utána a suliban a Pascal rém rettenetes volt a sok kötöttsége miatt.
Most már látom ,hogy először kell egy nehezebb szigorúbb nyelvel kezdeni, és akkor később lehet örülni. Fordítva mindig csak az forog az ember fejében ,hogy minek ez a sok maszlag miért kell 10 sorban megírni amit 2 sorban el lehet intézni.

Nezopont kerdese. Szerintem a Pascal/C pont a sok kotottsege miatt eleg nehez egy olyan ember szamara, aki most ismerkedik a programozassal. A VB ilyen szempontbol jobb, mert a kotottsegek nem vonjak el a figyelmet a lenyegrol: az utasitasokrol, azok mukodeserol es a program logikai felepiteserol.

En C64 Basic-cel kezdtem, VB-vel folytattam, es elmentem VB.Net iranyba is, es azt mondom, sokkal konnyebb volt utana Java/PHP-t tanulni, mert akkor mar ertettem a programozas lenyeget, volt egy elkepzelesem arrol, hogy mit hogy kell csinalni. Persze, ehhez a jo tanar/konyv is elengedhetetlenul fontos.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Geany +1
Egyszerü, letisztult felület,
nem kötelező projektben dolgozni,
ugyan nincs benne valami jó kódkiegészítés, de megszokható,
szubjektív érv: Én is ezt használom, egy apróbb problémától eltekintve tökéltes...

Nézd meg, próbáld ki, add tovább!:)

Esetleg Quincy? Csak Windows-ra írták meg tudtommal, pedig nyílt forrású, de elfut wine alatt.

Elég érdekes, bár felesleges érvelés megy egy ideje a különböző nyelvek és módszerek körül. Sztem most az a kérdés, hogy a srácok egyáltalán akarnak-e programozni, vagy elment a kedvük tőle.
--
unix -- több, mint kód. filozófia.
Life is feudal

Majd megkérdezem őket! ;-)

Ha már érdekel valakit:

12 éves fiam a logot már elég jól ismeri. Szeretett volna valami használhatót tanulni. A C-re azért esett a választás, mert:
a) Azt a célt vette a fejébe, hogy TORCS-hoz akar robotot írni. Mondtam neki, hogy ahhoz sokat kell tanulni, de elvileg benne volt. Mindenesetre ez a távoli cél motiválta. Ja, és ahhoz C kell.
b) Jómagam C-ben tudok a legjobban. Hiába jobb választás elvileg a Python, stb., ha azokat csak kezdő szinten ismerem. Egy tanár akkor tud jól tanítani, ha egy nagyságrenddel többet tud a tananyagnál. Legjobban C-ben tudok, aztán Pascal, Fortran, BASIC :-) és C64 assembly :-)) az, amiben valaha komolyabb dolgot csináltam.

9 éves fiam csak kibicnek ült be, bár őt is érdekelte és jól állt hozzá.

Kin/min múlt, hogy egyenlőre megszakadt? Semmiképp nem a nyelv választáson. Elsőszülöttem kifejezetten élvezte, hogy a logo rajzolgatása helyett most érdekes számolásokat csinálhat. De nyáron inkább minden kötöttségtől igyekeztek szabadulni és ez győzött. Erőltetni meg nem akartam, főleg úgy, hogy tudtunk értelmes dologgal foglalkozni e helyett.

Ha lesz folytatás, beszámolok.

Sajnos a fiúk valamiért nem akarták megérteni, mit jelent az

int ***p;

:-)

Végülis miket használtál? gcc/geany volt az utolsó amire utaltál.
Én megmondom őszintén, hogy gcc-t ajánlottam volna mc editorjával karakteresre, aztán MS Visual C++-t a grafikára (valószínűleg ennek a hiánya miatt ment el a kedv, de nem tudhatom).
És még valami: szerintem az alapok után nagyon jó választás lett volna Linuxon az OpenGL, gondolj bele.

Én ezt javasolnám:
http://www.activestate.com/Products/komodo_ide/index.mhtml

Bár a teljes változat pénzes, a szerkesztő ingyenes, és pár kattintással tudsz fordító makrókat csinálni benne, a gyereknek meg csak annyit kell mondani, hogy nyomj F9-et, ha látni akarod, mit csináltál. Van benne minden szokásos: syntaxhighlight (userfgv-re is), kódblokk összehúzás, fordító kimenet értelmezés stb, elérhető Linux, Win és MacOSX alatt is.

Hogy őszinte legyek, még sose jutott eszembe megnézni, mivel tud többet a pénzes változat, mert a szerkesztő kicsit konfolva bőven elég mindenre.

Ha ragaszkodsz a C-hez:

apt-cache show gnat-gps

https://libre.adacore.com/gps/main.html
http://en.wikipedia.org/wiki/GNAT_Programming_Studio

Ha belátod, hogy Pascal-lal jobb indulni, mert (1) eleve oktatási nyelvnek indult, (2) azért csak vannak benne pointer-ek, (3) a nyelv fele nem "undefined behavior"-ról szól (*), akkor

apt-cache show fp-ide

http://www.freepascal.org/
http://en.wikipedia.org/wiki/Free_Pascal
Lazarus

(*) példa:


{
  char *a, *b;
  
  a = malloc(1);
  if (0 != a) {
    free(a);
    b = a; /* undefined behavior */
  }
}

Mielőtt bárki megkérdezné: az utolsó sorba nem

*a

-t akartam írni. http://www.faqs.org/faqs/C-faq/faq/ 7.21
http://www.open-std.org/jtc1/sc22/wg14/www/docs/C99RationaleV5.10.pdf 6.3.2.3 49. oldal 25-ös sortól

Határozottan a Pascal-t javaslom.

Szerintem a java sokkal jobb tanulasra, a Pascal elegge kotott nyelv. De az az igazsag, hogy ugyis mindenki a sajat lovat biztatja. Szvsz hasznaljon Eclipse-t vagy NetBeans-t, es akkor tobb nyelv kiprobalasara is van lehetoseg.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

De mi bajod van ezzel?
Nem 1 féle C fordító van, hanem c*100, Pascalból meg 1, a Borlandé (persze a FreePascal is, dehát ők Borland mintára).
A szabvány nem írja elő, hogy a hülyeség után hogy viselkedjen a fordító, ezért implementáció függő. Nem véletlenszerű, hanem implementáció függő. És még ennek is oka van. Durván 40 (!) éves a nyelv. Korábban: kompatibilis legyen az új fordító a régebbi programokkal.


while (p) {
free (p);
p = p->next;
}

Hibás logikájú, de működik (bizonyos fordítókon pl régebbi gcc) és határozottan gyorsabb.
(Hogy a fenébe kell itt behúzni a sorokat??)

Szerintem ez is jó példa (és nem tartalaz furcsa dolgokat, csak szabványos C forrást):

//valami kepletet tartalmazo define
#define A(a,b) ((a<<4)+(b&15))
int funkcio()
{
return A(i++,2);
}

találtam már olyan gcc fordítót, ami az egyik architektúrán a növelés előtti értéket adta vissza, de egy másikon a növeltet. (Ugye a C annyit definiál, hogy postfixnél az utasítás végén kell növelni, de hol a vége? A define után, vagy a return is beleértendő?)

Vagy egy másik:

a=a/++a;

Az a return utasítás így néz ki:

return ((i++ << 4 ) + ( 2 & 15 ));

vagyis ide elvileg az i növelés előtti értéke kell, hogy kerüljön, majd pedig megnöveli az i-t.
Egyazon utasításban viszont tudtommal nem definiált, hogy a kétszer szereplő változó megnövelt, vagy növeletlen értéke kerül oda ( a/++a ).