Elkezdenék programozást tanulni

Fejlesztés

Sziasztok!

Mint kezdő rendszergazda (4 hónapja) arra jutottam, hogy nagy hiba, hogy nem tudok programozni és nem ismerek egyetlen nyelvet sem. (a HTML, css, Linux shell programozás, úgy tudom nem számít egyik sem programozási nyelvnek, mert jelenleg csak ezeket ismerem)

Arra jutottam, hogy 2 nagy hiányosságom van.
1. Angol, ezen ár dolgozom, most keresek angol tanárt
2. programozás, ezt itt szeretném a helyes útra vezérelni.

Első körben elkezdtem keresgélni itt a fúrumban is fejlesztői környezek után, majd kaptam egy tippet egy jóbarátomtól, hogy amíg nem összetett és nem nagy programokat írok (egyenlőre a Hello World lesz :)) addig elég ha egy szerkesztőben megírom a forrást és lefordítom, majd kipróbálom. Természetesen mindezt Linux (pontosabban SUSE 9.3) alatt tenném.
Szerintetek is kezdetben járható ez az út? Azt tudom, hogy ha valami.php fájlban szerkesztek egy php oldalt azt még frankón színezi is. Nekem meg több nem kell.
Mert ha igen akkor már csak oktatási segédletet kell találnom ami sajnos úgylátom könyvvásárlást von maga után.

Ja persze nem montam, "C"-vel szeretném kezdeni az ismerkedést.
Ha ár muszály könyvet vennem legyetek szívesek abban segíteni, hogy milyet!

Minden segítséget előre is köszönök.

budacsik

( uid_1526 | 2006. 10. 11., sze – 09:46 )

C programozáshoz az alapművet tudom ajánlani: Kernighan-Ritchie: A C Programozási Nyelv, Műszaki Könyvkiadó

Érdemes szétnézni az egyetemek és főiskolák honlapján!
Néha egészen jó jegyzeteket lehet találni.
Bauer Péter - C Programozás http://rs1.szif.hu/~bauer/CProg.pdf

Itt a "Hello!" program forrása: 


/* PELDA1.C */
#include <stdio.h>
void main(void){
printf(”Ez egy C program!\n”); }

:-{)E

Mondjuk ott, hogy:

1. szabvany szerint a main () fv-nek int a visszateresi erteke. Az mas kerdes, hogy valaki kitalalta, hogy "ugyan mi ertelme annak, hogy a foprogram visszaterjen valamilyen ertekkel?", es azota nem lehet kiverni ezt a dolgot a koztudatbol

2. nem hagyta le az include-olt header file nevet, csak (mivel az kisebb, nagyobb jelek kozott van -> tag?) a drupal kiszurte

3. jo lenne, ha az egyetemeken talalhato segedanyagokat legalabb egy picit probalnak szabvanyos modon elkesziteni, es akkor talan nem lepodne meg a tisztelt hallgato, hogy esetleg egy forditoprogram nem eszi meg a forrasat, ami pedig "a jegyzetben is ugy van, mennie kellene" -> kevesebb lama kerulne ki az egyetemekol (mert hogy abbol sok van, az biztos - hidd el, tudom)

Mindent osszevetve (hogy en is irjak mar forrast:)): 


#include <stdio.h>

int main (void) {
    printf ("Hello World!\n");
    return 0;
}

zarojelet kihagytad :-)
es EXIT_SUCCESS jobb, mint nulla, soha nem lehet tudni.

mutatok valami gusztustalant, ha mar hello world: 


#include <sys/syscall.h>
#include <unistd.h>

int
main(){
        char buf[] = "Hello World!\n";
        syscall(4, 2, buf, sizeof(buf));
        _exit(0);
}

--
Segmentation violation -- Core dumped blues

Nem olyan vészes az a C++, nem kell rögtön kihasználni minden funkcióját. Viszont van sok olyan is, ami már az elején, egyszerű feladatoknál is hasznos, ha más nem, pl. az operator overloading.
Egy numerikus számolásnál már marhára nem mindegy, hogy két mátriz szorzatát úgy számolod ki, hogy 


for(i=0; i<meret; i++) for(j=0; i<meret; j++) { c[i][j]=0 ; for(k=0;k<meret; k++) c[i][j] += a[i][k]*c[k][j] ; }

(most nem is beszélve a mátrixok lefoglalásáról, felszabadításáról, stb), vagy 


matrix product = a*b;

és itt már a memóriakezelést is végezheti a konstruktor és a destruktor.
A baj inkább abból származik, hogy mindenki úgy akar C++-t tanulni, hogy először hozzászokik a C-s szemlélethez, és utána akar hirtelen váltani C++-ra. Pedig inkább előről kell kezdeni, az gyorsabb, könnyebb. Van is jó könyv, ami ezzel a szemlélettel halad, csak sajnos nem tudom, hogy van-e magyar fordítása. A címe: Koenig - Moo: Accelerated C++, Addison-Wesley kiadó.

Hi!

Asszem az összehasonlítás nem jogos. Lehet hogy C-ben nincs eleve implementálva ilyen, C++-ban meg van (mittudomén), de nem ezen múlik. C-ben is meg lehet írni egy fv-t erre, vagy szerezni libet amiben már van ilyen. És C++-ban is valakinek egyszer meg kellett írnia, és neked is bármikor szükséged lehet arra hogy valami ilyesmit írj.

Személy szerint egyébként nagyon nem csípem a C++-t, bár nem is nagyon ismerem. Ha pontosan tudni akarod, hogy mi történik a gépben, akkor jó a C. Abban is lehet szépen, OO-közeli szemlélettel dolgozni, C++-ban is lehet gányul. Nem a nyelven múlik, hanem az elméleti alapokon, a szemléleten és a sok-sok gyakorláson.

Ha pedig valami dögöset (magas szintűt) akarok, akkor számomra ott kezdődik a kényelmes programozási nyelv, ahol a memóriakezelést nem holmi konstruktor-destruktor végzi, hanem maga a programozási nyelv (értsd persze: fordító vagy futtató környezet). Tehát ahol akkor sem kell egyetlen pillanatig sem memóriakezeléssel bajlódnom, amikor konstruktor-destruktort vagy egyéb kacifántos dolgot készítek.

Neked találták ki a Java-t!
:-{)E
Mármint, hogy ott nem kell memória foglalással és felszabadítással bajlódni, még annyira sem mint a sima C-ban.
Ráadásul a Java szintaktikája is nagyon hasonlít a C-re és a C++ -ra.
Egy előadáson azt mondták róla, hogy C++-- (ejtsd: cé-plusplus-minusz-minusz)

"C-ben is meg lehet írni egy fv-t erre"
Persze.
Csak mi a kényelmesebb?
Ez:
Matrix* t;
matrix_copy(t,a);
matrix_mul(t,b);
matrix_add(t,c);

Vagy ez:
Matrix t=a*b+c;

A válasz egyértelmű.
Arról nem is beszélve, hogy a C kód tipikusan nem túl hatékony ilyen esetben. Van egy másolás, majd még kétszer értékadás.
Egy ügyes programozó ezt megoldja egy értékadással.
Csak ilyenkor jönnek a:
matrix_copy_mul_add(t,a,b,c);
Jellegű fv-ek.

A figyelmes ember felkapja a fejét: Hé a C++ program nem ezt csinálja?
De, a naív operator-overloadingos megoldás ezt.
Ámde az expression-template-es megoldás nem, hanem lényegében azt, amit az ügyes programozó. De úgy, hogy nem kell minden eshetőségre új fv-t írni.
Az eredmény: kényelmes kezelés, fortran teljesítmény.
(Google: Blitz++)

"Személy szerint egyébként nagyon nem csípem a C++-t, bár nem is nagyon ismerem."
A legtöbb embernek ez a gondja. Elég flusztráló dolog, mikor egy 25 soros program 45 sor hibaüzenetet generál. Pedig kezdetben ez megszokott, főleg ha az ember C-ről áll át.

"Ha pontosan tudni akarod, hogy mi történik a gépben, akkor jó a C."
C++-ban is lehet pontosan tudni, mi történik a gépben. Csak a nyelv lényegesen bonyorultabb, többet kell hozzá foglalkozni vele.
Pontosan lehet tudni, mikor fut le egy destruktor, stb. Azért ez pl Javaban nem így van. (Azon persze lehet vitatkozni, hogy kell-e tudnom mikor fut le...)

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

"C++-ban is lehet pontosan tudni, mi történik a gépben."

Na, akkor itt a kedvenc C++-os szivattyúm:

Csinálnék egy osztályt, ami egy thread-et zár be, azaz van pl. egy run() virtuális metódusa, amit külön threadben futtat. Konstruktor-időben indul, leállnia pedig akkor kell, amikor a) törlik a példányt ill. b) a run() kilép.
Az a) eset szép tiszta: destruktorból lelőni a thread-et, aztán kész is vagyunk. No de a b) eset már macerásabb, ugyanis bár a thread kilép, de olyan, hogy 'delete this', olyan ugye nincs.

Lehet csinálni külső friend függvényt, aki indul thread-ben, hívja a run()-t, aztán törli a példányt, majd kilép. Törölheti a példányt, merthogy a destruktor threadestől vágja haza, így az a) esetben már nem jön vissza a run()-ból.
A gond ott van, ha a szegény run() azonnal kilép, a külső fgv. törli a példányt, miközben a konstruktor épp fejeződne befelé. Kiszinkronizálhatatlan, mert lehetséges, hogy a destruktor akkor hívódik, mikor a konstruktor az utolsó utasítása után jár éppen. És igencsak okoz gondot, mert _általánosságban nem tudni_, hogy mi történik a konstruktor és a destruktor elő- és utó-kódjában.

Várom a tippeket :) !

Nem tudom, milyen C++ toolkit-et láttál, ami ezt nem tudja lekezelni, de pl. Ultimate++-ban a szálak simán tudnak egymásnak szinkronizáltan eseményeket küldeni. Innentől kezdve semmi probléma nincsen. Mondjuk ehhez persze szükséges, hogy az eseményt kapó szál mainloop-ban legyen.

Nem világos, hogy ez miért cáfolata az idézett mondatnak.
Mert mikor hívódik a destructor?
Mikor a lokális változót tartalmazó blokk lefut.
Vagy, mikor egy dinamikus objektumot törölsz.
A dolog tehát egyértelmű.

"de olyan, hogy 'delete this', olyan ugye nincs."
De olyan, hogy 'this->~T();' olyan van. Csak lokális változóra meghívva a destruktor összesen 2x fut le. Lehet használni, csak nagyon át kell gondolni.

A példánál maradva:
A konkrét feladat ismerete nélkül nehéz bármit mondani, de szerintem itt az a megoldás, hogy másképp próbálod megközelíteni a feladatot.

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

Hack megoldás, de mi lenne, ha a classba beleraknál még egy logikai változót, mondjuk egy 

konstruktor_lefutott

nevűt, és a friend függvény várna addig, amig ez true nem lesz. A konstruktor persze a legvégén billentené át.
Vagy esetleg a threadindítást teszed a konstruktor végére.
(Persze el kell ismerni, hogy ez tényleg olyan dolog, ahol sérül a magas szintű nyelvek absztraktsága, és a programozónak bele kell gondolnia, hogy a háttérben mi is zajlik, pedig pont az lenne a cél, hogy ne kelljen ilyen részletekre koncentrálnia, csak a megoldandó feladatra.)

A válasz egyértelmű:
Persze hogy kényelmes a t=a*b+c;, de az ember nézheti át az egész kódot, hogy vajon mit is jelenthet most a '+' operátor. Sőt, nem csak ebben az esetben, hanem ha találkozol egy operátorral a kódban, soha semmit nem feltételezhetsz a működéséről. Ez eléggé inproduktív, ha mondjuk más kódját kell megértened, és az illetőnek nagyon tetszett az operator-overloading.

s/operátor/függvényhívás/g

"ha találkozol egy fügvényhívással a kódban, soha semmit nem feltételezhetsz a működéséről. Ez eléggé inproduktív, ha mondjuk más kódját kell megértened."
Ha adok neked egy kódot, és rendszeresen mul-nak hívom az összeadást, és add-nak a négyzetreemelést, akkor miért vagy beljebb?
Bármilyen nyelven lehet érthetetlen kódot produkálni.

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

Semmi rejtett fv hívásról nincs szó.
A beépített típusok operátorait nem lehet felülírni, a saját típusnak meg egyértelmű, hogy saját művelete kell legyen. Mi ezen a rejtett?

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

Igen, ez szokott lenni a C programozók egyik érve a C++ ellen. Ez bullshit. Csak a magam nevében nyilatkozok, de biztos lehetsz benne, hogy az operátorokat egyértelmű esetben szokás túlterhelni; pl. két dátum különbsége lehet int, egy dátum és egy int / int és dátum összege lehet dátum, dátum és int különbsége lehet dátum. Minden egyéb misztikus dologra lehet függvényt használni, kész, jószerencsét. Nem muszáj gondolkodás nélkül fikázni a c++-t..
Ha meg "az illetőnek nagyon tetszett az operator-overloading" azt jelenti, hogy az illető balfasz volt, és esetleg a saját magát is megszopatta időnként. Ha abból indulsz ki, hogy xy nem tud profi módon programozni, akkor igazad lehet, sajnos.
Az inproduktivitásról: C-ben talán nem lehet (az előszeretettel használt) #define-okkal értelmezhetetlenné tenni a kódot? A profik például így csinálják: IOCCC :)

Már ha tudom, hogy mátrixról van szó. Nem beszélve még a szorzásról, ahol nagyon nem mindegy, hogy A*B, vagy B*A, ha már mátrixoknál tartunk. Tehát ha jön valaki, aki valamilyen új funkciót akar beépíteni, vagy optimalizálni szeretné az 1000 éves kódot, akkor ki kell derítenie, hogy ha egy '*' operátort lát, akkor milyen típusuak az operandusok, netán milyen konverziók fognak végrehajtódni, mit csinál a művelet, illetve milyen szabályok vonatkoznak a műveletre. Ez nem feltétlenül egyszerű.

Nem egyszerű, de használni sem kötelező. Ha alapelvnek tekintjük, hogy nem szabad bennhagyni olyasmit, amit az 'alapértelmezett' módtól másképp is lehet használni, akkor a teljes unix rendszercsalád egy kész csőd, hiszen pl. 'felül lehet definiálni' a /etc/inittab-ot, és onnan minden totál másképp működik, és egy odaülő új adminnak sorról sorra át kell néznie az egészet. Nem is szokás teljesen átírni a rendszerindulási mechanizmust, pedig ugye lehetne.
Vagy pl. szintén komplett marhaság kiadni a linux kernel forrását, mert 'felül lehet benne definiálni' pl. az ide vinyók 'hd' prefixét, fel lehet cserélni a loopback-ek 'lo'-jával, és akkor mi lesz szegény új adminnal, nézheti a forrást. Persze nagy mocsokság lenne, nem is tipikus az eset :), de amiatt még senki sem háborodott fel, hogy lehetséges, nemde?

Természetesen, de a másik két példával ellentétben az operátor-túlterhelésnél mégis az a gyakoribb, hogy eltérnek az alapértelmezett módtól. Arra van ugyanis kitalálva az egész.
Persze, leírva marha elegánsan néz ki, hogy a=(b+c)*d, mégha fogalma sincs az olvasónak, hogy mit is művel a fenti részlet. Ha valamilyen saját típusokkal dolgozik, akkor a programozó döntheti el, hogy ő mit nevez összeadásnak, meg szorzásnak. Néha ez triviális, máskor meg nem.
Ezt az eszközt túl erősnek tartom, nagyon könnyű rosszul használni. Ez nem nem jelenti azt, hogy akkor senki se használhatja, csak nagyon körültekintően kell eljárni, ha az ember esetleg egy könnyen karbantartható, és megérthető kódot akar produkálni.

"Ezt az eszközt túl erősnek tartom, nagyon könnyű rosszul használni."

Mit nem?
Ugyanilyen probléma, ha valaki x1,x2,x3-nak nevezgeti el a változóit.
Ha valaki hülye, bármilyen nyelven tud érthetetlen kódot írni.

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

A mátrix szorzás valóban nem kommutatív, de az operator+ sem az.

Normális ember úgy írja meg a mátrix libet, hogy működik a vektorral szorzás, a mátrixszal szorzás, és a skalárral szorzás is, méghozzá úgy, ahogy azt elvárja az ember. Ettől nevezheti a libjét mátrix libnek.

Abban igazad van, hogy pl az operator<< szinte soha nem a bitenkénti balra tolás, kivéve, ha beépített típusra alkalmazod.
Minden ilyen nem egyértelmű operátornál az ember megnézi a dokumentációt és kész.
(Más kérdés, hogy pl az operator<< a legtöbb esetben valamilyen streammel kapcsolatos dolog szokott lenni. Minden operátornak van egy(két) megszokott jelentése, és normális ember úgy írja a programját, hogy konzisztens maradjon.)

"Ez nem feltétlenül egyszerű."
Senki nem mondta, hogy a C++ egyszerű nyelv. Sőt...

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

Egyébként az összehasonlítás tényleg nem korrekt, mert C++-ban sincs alapból implementálva a mátrix-szorzás, tehát egyszer ott is meg kell írni (ha nem használsz külső lib-et, de ezt C-ben is megteheted).

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

Nem is azt mondtam, hogy nem kell egyszer megírni (bár van jó pár kész numerikus toolkit C++-hoz), hanem hogy utána szép, áttekinthető képleteket írhatsz. Ha nem áttekinthető képeteket írsz, akkor nagyon nehéz megtalálni, hogy hol is maradt ki az a 2-es, ami miatt most nem konvergál az egész.

Válasszuk szét a nyelv ismeretét, és az algoritmusok, és adatstruktúrák ismeretét. A könyvből a C nyelv szintaxisát, használatának szabályait lehet megtanulni.
Ahhoz tudnám hasonlítani, hogy ha veszek egy finn nyelvkönyvet, akkor abban benne vannak a szavak, a nyelvtan, ha tanulok a könyvből, akkor nyelvtanilag helyes mondatokat tudok összeállítani. De a nyelvkönyből nem fogom megtudni, hogy például hogyan írjak finn nyelven egy verset.
Almákról és körtékről beszélünk.

"És ebből hogy tanulja meg az alapvető keresési, rendezési, kiválogatási, halmazműveleti, string, verem, lista, fa, stb... algoritmusokat, amik a programozáshoz elengedhetetlenek?"
Manapság elég ezeket egyszerűen használni. Aki meg egy fejlesztési project-ben alkalmazottként ilyen algoritmusokat kezd el lekódolni, az nem sokáig teszi, mert elzavarják...

Viszont, ha azt sem tudja, hogy mik ezek, akkor hogyan tudná a beépítetteket használni? Hogyan döntsd el pl, hogy java-ban hash-elt ArrayListet fogsz éppen használni, ha nem vagy tisztában azzal, hogy mi a tömb, mit a lista, és mit jelent az, hogy hashalés? Vagy szerinted viccből kezdik ezekkel a programozás oktatását?

Morzel

Ez körübelül olyan, mintha azt mondanád, hogy nem kell tudni, hogyan kell alapszinten asm-ben programozni, kb hogyan működik egy processzor, vagy, hogy hogyan működik egy fordítóprogram nagyvonalakban.
Egy hello wordhöz ez valóban nem kell, de egy komoly projekthez elengedhetetlen.

Arról nem is beszélve, hogy egy ezek az alapvető algoritmusok tartalmaznak rengeteg ötletet, és módszert, amit tudni kell.

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

Én csak azt mondom, hogy ezeknek az algoritmusoknak a mélyebb ismerete egyáltalán nem elengedhetetlen ahhoz, hogy valaki elkezdjen programozni tanulni. Ez csak néhány tanár fixa ideája.
Sokkal célszerűbb, ha elkezd végigmenni pl. a Kernighan & Ritchie féle C könyvön, ahol megismeri a nyelv alapjait, logikáját. Eközben már ALKALMAZZA a programnyelvet a példákat bepötyögve, kipróbálva, változtatgatva, így jutva a kezdeti sikerélményekhez. Aztán a nyelv használatára felhozott példákon keresztül fokozatosan ismerkedhet meg algoritmusokkal, mikor már helyére tudja tenni, hogy mire valók.
Amúgy pl. ha már C++-szal folytatja, pl. az STL doksijában vlágosan dokumentálva van az összes megvalósított algoritmus, mi mire való stb.

Ha szabad egy kérdést feltennem:
Milyen lépésidejű pl. a glib-ben szereplő g_list_sort() egy N elemű listán? (Ha más lib-et használsz, akkor az abbéli lista-rendező, ha nincs olyan, akkor pedig hogyan rendezel listát?) Ez pl. a doksiban nincs leírva, viszont az adatszerkezet megtervezésénél igencsak számíthat ugye.

Történetesen amúgy O(N*log(N))-es, merthogy összefésüléses rendezést használ, amit két perc alatt meg lehet nézni a forrásban, mármint ha az ember _tudja_, hogy hogy néz ki egy ilyen, azaz ha tudja, hogy milyen rendezések vannak. No meg persze ha tudja, hogy mi az az O(N*log(N)), valamint az, hogy ez jónak számít-e vagy sem, azaz ha már azért tanult némi algoritmuselméletet.

Másik példának említhetem a hash-táblákat. Szépek, jók, hatékonyak, mármint ha az ember jól választja meg a kulcs-függvényt, ugye. Mi is az a kulcs-függvény? Mennyit számít, hogyan kell megválasztani? Ezt mind csak akkor tudja megválaszolni, ha _tudja_, hogy mi az a hash és hogy működik. Ha rosszul választja meg, akkor O(N)-es lesz a keresése, ha jól, akkor akár O(1) is lehet. Nem mindegy...

Dinamikus pufferek. A GString pl. 2-hatványosan (duplázva) nyújtja a foglalt területet, ami várhatóan 75%-os tárkihasználást (50..100%) jelent, ami memória-korlátos helyzetben akár megengedhetetlen is lehet, viszont legalább azt tudhatjuk, hogy mivel a hozzáírkálás nem jelent műveletenkénti realloc-ot, nem eszi fel a procit. Mármint tudhatjuk, ha _tudjuk_, hogy mi az a dinamikus puffer és hogy a realloc az drága.

Mennyire és miért is drága a realloc? Rossz esetben a libc malloc-jára fut, az pedig az eddig foglalt blokkok listáján megy végig, hogy van-e X db folytonos szabad blokk, aztán kér még az oprendszertől, ha nem volt. Azaz rossz esetben eddigi_foglalás/blokkméret lépés, plusz ameddig a kernel kerít szabad lapokat és odaadja a processznek. Ehhez persze tudni kell, hogy mi az a lista, fel kell ismerni a kódban egy lista-bejárást, stb.

Na, ha már itt vagyunk: tehát a malloc listán megy végig, azaz drága. De hát akkor a new is az! Jé, mennyi átmeneti objektum is keletkezik egy magas szintű nyelv libjeiben... Még ha csak a c++-os stl-t nézem is, és nem mondjuk a java-t... Szerencsétlen programozó meghív egy ártatlan metódust, és nem is tudja, hogy közben az égig túráztatja a szerencsétlen procit, csak mert 'hát ez olyan egyszerű'. Az, csak ára van, amit jó tudni...

No de vissza egy kicsit: vannak még olyan adatmennyiség- és teljesítménykritikus feladatok, ahol a szimpla hash-táblák is túl lassúak, annál specifikusabbakat pedig nem szokás külső lib-ekben 'eleve adni', ezeket írja meg az ember a maga céljaira. Ilyesmi pl. a többszörös hash-ek, a tárolófák (pl. kevés írás és sok keresés esetén egy splay-tree csodákat művelhet), gráf-ábrázolások, stb. Mindnek megvannak a maga erős és gyenge oldalai, amit ugye figyelembe kell venni, márpedig ahhoz magát az adatszerkezetet is _ismerni_ kell.

Összefoglalva: ha csak helloworld-szintű dolgokat akar írni, vagy olyan ótvaros batár memória- és procizabáló monstrumokat, mint a mostani programok túlnyomó része, akkor nem kell algoritmusokat és adatszerkezeteket ismernie, ha viszont normálisakat is szeretne, akkor pedig egyenesen kötelező.

Sajnos a világban épp eléggé elharapózott az általad vázolt felfogás, ezért van aztán az, hogy a gépek kapacitásának igazából az 1-2%-a megy el a feladatra, a többi a program belső töketlenkedésére. De hát olcsó az energia, fűthetjük vele a bolygót, meg aztán még nem is okoz gondot a 2-3 évente lecserélt számítógépek képezte hulladék...

És persze mindezt, amit itt leírtál, tudnia kell egy kezdőnek, mielőtt tudná mi az a változó és a for ciklus.
Gondolom egy 1 éves gyereket is úgy tanítanál beszélni, hogy az alanyi és a tárgyas ragozás használatáról tartanál neki előadást.

Amúgy tökéletesen egyetértek veled abban, hogy az általad leírt dolgokkal (legalább elvi szinten) tisztában kell lennie valakinek, mielőtt programozónak mondja magát, azt viszont nem hiszem, hogy ezzel kell kezdenie a tanulást.

Igen, de szerintem elég nehéz megtanulni sebességet váltani, amíg nem tudsz szépen, egyesben lefulladás nélkül elindulni.
Hasonlatok nélkül: bele lehet hülyülni, ha az ember algoritmusokat akar megtanulni, lépésszámokat kitaláni úgy, hogy nem tudja a programot megvalósítani. Szerintem a helyes út: párhuzamosan tanulni. Azaz fogni egy könyvet, alapszinten elsajátítani egy nyelvet, majd elkezdeni használni, lehetőleg arra, hogy értelmes feladatokat, átgondolt algoritmusokkal, jó adatstruktúrákat használva lekódolj.
Erre szerintem elég jó a C esetében a Kernighan-Ritchie-könyv (C), akár a Koenig-Moo-könyv (C++, ld. az előző hsz-emben) (+valami algoritmusgyűjtemény, Pl. Gács-Lovász, Knuth, Cormen-Leiserson-Rivest).
Ha először akarsz egy áldozattal algoritmusokat elemeztetni, akkor tuti elmegy a kedve az egésztől. Az kell, hogy az ember gyakorlatban lássa, hogy "tyű az áldóját, tényleg mennyivel gyorsabb lett".

Szeretném kihangsúlyozni, hogy az nem sebességváltó, hanem nyomatékváltó! :)

De hogy ontopic legyek, a programozók nagy része megtanulja, hogy miket takarnak ezek a kifejezések. Vagy megtanítják egyetemen, vagy ha jó programozó az illető, akkor elgondolkodik azon, hogy vajon miért fut olyan cefet lassan a programja. Méricskél, azonosít, aztán google, fórumok és megvilágosodás...

"programozók nagy része megtanulja"

Azt hiszem mi nem ugyanazokat a "programozókat" ismerjük.
Illetve nem ugyanazokat a programokat használjuk.

Egy olyan világban, ahol egy webkamera feltelepítésével olyan taskbarba épülő kis vezérlőprogram költözik a gépünkbe, ami lefogalal 5-10 Mb memóriát, és 2-3% processzoridőt, én nem tudok olyan optimista lenni, mint te.
Persze legyinthetsz, hogy szar windows, de ez nem a rendszer hibája, hanem a programozóké. Leszenk ezekből még linux "guruk" ha terjed egy kicsit desktopon...

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

Véleményem szerint ez összetettebb kérdés ennél. Olyan, mint a csúszka a JPEG tömörítésen. Vagy kicsi a fájl, vagy sokkal részletesebb a kép. Mindig az adott feladat dönti el, hogy merre csúsztassuk a csúszkát. Nem nagyon hiszem, hogy igazán lehet olyan programot írni, ami : maximálisan optimalizált, kevés memóriát foglal, alig használ CPU-t, mindent megcsinál ami kell, és belefér a projekt idő- és költségkeretébe. Ezek közül valamelyik nem teljesül. S általában a projekt költségvetése erősebb prrioritású.

A Te kamerás példádat nézve: van egy cég, aki többek között kamerákat fejleszt. (Mellette még billentyűzeteket, audio, videó meg minden más perifériát.) Egy ilyen kamerának a modellfrissítési életciklusa nagyjából egy év. Ennyi idő alatt készül el belőle a következő generáció. Egy év alatt meg kell tervezni, le kell gyártani, meg kell írni az alkalmazásokat hozzá. Azért, hogy ne mindig nulláról kezdjék, felhasználják a régi hardver és szoftver komponenseket. Valószínű emiatt van valamilyen belső kamera framework, ami ugyancsak valamilyen szabványos framework-re vagy toolkitre épül, ami támogatja a cég által támogatott összes kamerát. A lényeg az, hogy az új eszköz fejlesztésére nem szánnak annyi időt és energiát, ezzel együtt nem kerül optimalizálásra, illetve a többszörös frameworkok miatt megnő a kompatibilitás, de több memóriát és CPUt fogyaszthat. Egyszerűen nem éri meg optimalizálni. 10MB memóriát eszik? Mi van akkor? Ha kell még egy kis memória, veszel. Van erősebb CPU is a piacon. Ma már a memória és a CPU, ebben a szegmensben nem érdekes tényező.

Természetesen vannak olyan alkalmazások és területek, ahol az optimalizáció megkövetelt: képfeldolgozások, CAD-CAM rendszerek, játékok és nagyobb adatbázis rendszerek. Ezeken a területeken fejlődő projektekbe bele van terveze a kód optimalizáció. Hiszen anélkül eladhatatlan terméket hoznának létre.

Úgy vélem, hogy nem elsősorban programozói hiba, ha egy alkalmazás nem olyan, amilyen. Bár a programozó tudásbeli hiányosságai is sokat vetnek a latba, de gyakran a projektvezető vagy e cég vezetője dönti el, hogy a keretbe fér-e a program tisztítása, optimalizálása.

Lehet olyan alkalmazásokat írni, amelyek az összes optimalizációs lehetőséget tartalmazzák, azonban egy cégnél ezt semki sem szereti. Sem a cég, sem az ügyfeleik. Miért is nem? Van egy spíler programozó, aki hatszor jobb kódot ír, mint ami eddig volt. A kódja nagy része assembly, teljesen elrugaszkodik a cég által eddig használt és ismert fejlesztési környezetétől. A kódjával, amit senki sem ért, vagy csak alapos tanulmányozás után érthetne meg, az emberke pótolhatatlanná válik, mihelyst a kódja a publikum számára elérhetővé válik. A cég szempontjából ez kínos, mert egyrészt ezzel zsarolhatja a céget, másrészt meg ha átmegy rajta a villamos, akkor lehet, hogy egyes, ezt a komponenst használó alkalmazásaik fejlesztése visszavetődik, s ezzel az ezekkel kapcsolatos szerződések kötbér opcióját guríthatják el. A Webalix-es threadbanbeszéltünk arról, hogy általában egy személyre szabott alkalmazásrendszer elkészítésekor a szállítónak garantálnia kell, hogy az adott rendszerhez évek múltán is tud javításokat, komponenseket, "know-how"-t stabilan és megbízhatóan szállítani. Így a fentebb említett programozó kockázatot jelent a rendszerre és a cégre egyaránt, ezért nem engedik az optimalizációját.

Mindent egybe vetve, igen, vannak programozók, akiket nem érdekel, hogy egy program jól működjön. De egy program minősége nem csak a programozón múlik.

( wlaszi | 2006. 10. 11., sze – 09:58 )

"Azt tudom, hogy ha valami.php fájlban szerkesztek egy php oldalt azt még frankón színezi is. Nekem meg több nem kell. "

Ha ez most a "highlight"-képességet jelenti, akkor a válaszom:
EditPad Pro-t használok, win/linux alatt is megy (2 külön "csomag" szóval nemtudom, hogy a crossplatform elnevezés mennyire illik rá). Nem free, ellenben olcsó és nekem nagyon kézre áll. Az eclipse és társai nekem nagyon ágyuval verébre kategória....

Lehet, hogy kisseb összegekre beruházok majd, de amíg tanulok az mcedit sztm elég lesz.

Viszont kérdésem, aki már programozott így, hogy kell aztán a forráskódot lefordítani és milyen kiterjesztéssel kell elmenteni a fájlt? Gondolom valami parancs lenne (pl.: gcc filename, vagy hasonló).

( golgota | 2006. 10. 11., sze – 10:25 )

PHP-hez elég a vim a syntax on bekapcsolásával és a www.php.net jobb felső sarkában a function kereső.
pl beírod, hogy mysql és kijön minden ami ahhoz kell, hogy mysql-t használj. ugyanígy ldap, xml, stb.

C-hez szerintem(!!!) az egyik legjobb induló(!)
http://www.cs.cf.ac.uk/Dave/C/

( budacsik | 2006. 10. 11., sze – 10:55 )

Köszönöm a segítségeteket, sok jó linket és könyvajánlót kaptam ami segít elindulni. Mostmár csak rajtam a sor!! :)

( Morzel | 2006. 10. 11., sze – 13:09 )

Már amikor elolvastam a topic címét, már akkor tudtam, hogy sok marhaság lesz, és igazam volt. A programozás NEM azt jelenti, hogy tudok C-ben programozni, és király vagyok. A programozás egy gondolkodásmódot jelent elsősorban, hogy hogyan álljunk neki egy problémának, és hogyan juthatunk el a probléma automatizált megoldásához. Ezért is nem értem azt, hogy miért is ajánlanak itt az emberkék konkrét programozási nyelveket, értelmetlen, már olyanoknak szóló leírásokat, amik már az alapokra épülnek, ha egyszer egyértelmű, hogy nincs meg az alap.
Az én tanácsom:
Elsősorban a programozási módszerekre, módszertanokra kell összpontosítani. Ha nincsen tanárod, akkor melegen tudom ajánlani Angster Erzsébet könyvét, ha jól tudom, az a címe, hogy Programozás tankönyv. Ez két kötetes, és nagyjából magába foglalja a struktúrált programozás alapjait. Hátránya, hogy a nyelv, amit konkrétan tárgyal, az egy Turbo Pascal verzió, így Turbo Pascal fordítót kell hozzá beszerezni, ami nem lehetetlen. Előnye, hogy tudtommal a mai napig kapható kereskedelmi forgalomban, jól magyaráz, benne vannak az alap algoritmusok, és vannak benne feladatok is rendesen.
Továbbá tudom tanácsolni, hogy azért keress olyan ismerőst, aki azért legalább minimum szinten tud programozni (pl. pár év fősuli, egyetem prog szakon), és aki hajlandó segíteni neked, ha elakadsz valamiben. Ebben a szakmában elengedhetetlen a személyes segítség, főleg az elején.
Aztán persze a legfontosabb tanács: NEM FELADNI!!!

Morzel

Szerencsére jelenleg 3 ember van aki tud személyesen is segíteni ha kell.

"Aztán persze a legfontosabb tanács: NEM FELADNI!!!"
Hát igen, biztos vagyok benne, hogy sok olyan lesz, hogy "én ezt nem értem"
"ezt nem tudom megérteni ...".
De aztán rájön az ember, hogy mégis, csak sook-sook türelem kell.
Remélem sikerülni fog.

Egyébként az egész azon múlik, hogy érdekel-e a téma. Ha nem érdekel, akkor megette a fene az egészet, megvehetsz száz könyvet, kifizethetsz ezer tanfolyamot, a büdös életben nem fogsz rendes programot írni. Ezt szerintem nem tudja olyan csinálni, akinek az agyát nem mozgatja meg az a dolog, amit talán programozói gondolkodásnak lehetne nevezni.

Morzel

Pontosan ezért nem ragadt meg bennem semmi a suliban, akkor nem kötött le a prog. Mostmár más a helyzet.

"Álltalában akkor megyünk el fogorvoshoz amikor már elmúltunk 18!" :)
Mennyivel könnyebb lenne most nekem ha az alapokat elsajátítottam volna még a suliban... hát sokkal!

hmmm... akkor sorstárs vagy:) annyi a különbség, hogy én még mindig tökéletesen hobbiprogramozó vagyok... a suliban nekem is keveset tanítottak, még kevesebb maradt meg belőle, és azt is pascalul tanították, amit meg szeretnek szidni:)
most egyetemen (közgéz, gazdtud. kar) viszont Visual Basicet akarnak a t. hallgatóságba implementálni, emiatt elkezdtem most basicelni... abból is a Gambast, nekem tetszik, mert nagyon gyorsan el tudtam érni vele kisebb sikereket...
hozzá kell még tennem a dologhoz, hogy _nem_ írtam sose komoly programot, éppen mivel hobbyból csinálom: egy nagyobb project nem kötne már le, gyors sikereket szeretek elérni, és általában nincs is másra szükségem.
_________________________________________
Valódi paraszt vagyok. Csak előre tudok lépni, nem azt ütöm le, aki velem szembenáll, és ha nincs tovább, megváltozom.

( atommokus | 2006. 10. 12., cs – 00:52 )

szerintem is az "algoritmikus" gondolkodasmod a legfontosabb,
amihez ugye meg hozzajon az adott nyelv utasitaskeszletenek,
lehetosegeinek ismerete /pl c++-ban az oparator overloading,
pythonban a lambda cuccos, es a perl se maradjon ki:
print 'ez ketto' if ($a == 2) :)/
plusz a felhasznalhato fgv.-k imerete

/* bocs az esetleges helyesirasi hidakert */

( Replaced | 2006. 10. 12., cs – 13:45 )

"Ha ár muszály könyvet vennem legyetek szívesek abban segíteni, hogy milyet!"

A magyar helyesírás szabályai? ;)

--
TheReplaced - С Кем Ты?

( sz332 v | 2006. 10. 12., cs – 18:46 )

Akkor rögtön a témához kapcsolódóan egy kérdés.

Barátnőmnek meg kellene tanulnia programozni (humán beállítottságú).
Kb. 1 éve van rá.

A cél az lenne, hogy az általunk java-ban fejlesztett programhoz (mely
igazából csak egy keretrendszer) kapcsolódóan tudjon írni
1-2 modult valamilyen script nyelven.

Ne gondoljatok komoly dologra, kb. ilyen "akasztófa játék" nehézségű modulra.

A kulcsszavak: felhasználói interakciók, grafikus elemek, egyszerűbb játékok
(kártya, akasztófa), esetleg slideshow megirása

A kérdés az, hogy milyen nyelvet ajánlanátok, amivel java objektumokhoz
lehet kapcsolódni. A következőkre gondoltam:

- Java: talán túl komoly lenne
- Jython: gyakorlatilag python, talán jó lehet
- Groovy: jónak tűnik, de nem biztos hogy ehhez a feladathoz
- JRuby: mint ruby
- Beanshell

Talán Jython illetve Beanshell játszik, nem tudom.. szerintetek?

ezek közül a groovy és a jython a legnormálisabb. a jruby pl. amennyire hype-olva van, annyira használhatatlan.

ha egy olyan nyelvet keresel, amiben modulokat szeretnél írni egy java programhoz, java classokat felhasználva, akkor groovy, ez nem is kérdés. nézd meg pl. a swingbuilder-t. nem hozzáértőnek viszont talán nem ez a legjobb, nem tudom.

( lzrd | 2006. 10. 12., cs – 21:03 )

A shell scriptelés igenis programozás!
Van benne elágazás, iteráció szekvencia. Objektum nincs, de van regexp. Ráadásul a UNIX parancsok olyan szintre jutottak mára, hogy a számtalan kapcsolóikkal hihetetlen hatékonnyá váltak.
A C++ "nagykönyvet" nem ajánlanám kezdőnek. Meg fogja feküdni a gyomrodat. De van C programozós tankönyve a kiskapunak. Magyar alkotás Linuxra való C-t tanít. Tök jó kezdőnek is. Az lesz a barátod!

--
unix -- több, mint kód. filozófia.

( budacsik | 2006. 10. 12., cs – 21:12 )

Megmondom őszintén, hogy annyi tanácsot kaptam, hogy azt sem tudom hová nyúljak :)
Közben fenntemm eszmei vita alakult ki, hogy a gyakorlati részével kezdjem vagy az elméleti részével. Ha ez lezárja a vitát, elárulom, hogy azért valamenyire az alapfogalmakkal tisztában vagyok, nem kell átvennem újta mi az a változó, konstans ...

( york | 2006. 10. 12., cs – 21:35 )

Szia

Elore bocsatom, nem olvastam vegig a topicot, ha volt mar akkor bocsi...

Rendszergazdakent en nem a C-vel kezdenem, mert kb. ez a legutolso amit hasznalni fogsz a gyakorlatba.
Amit jo ismerni valamilyen shell pl.: bash ezt ki lehet egesziteni sed es awk ismeretekkel, igy mar nagyon sok mindent meg tudsz csinalni.
Ha webes dolgokat akarsz csinalni akkor jo a PHP konnyen es gyorsan lehet vele haladni, van hasznalhato magyar dokumentacio. Svajci bicskanak es kezdo nyelvnek tudom ajanlani a Pythont, van jo magyar konyv hozza itt: http://learnpython.openproject.hu

Bocs ha kicsit zagyva, epp betegallomanyban vagyok :).

York.

------
"Nyugi! Minden a legnagyobb rendben csúszik ki a kezeim közül..."

Valóban igazad van abban, hogy rendszergazdaként nem sokat fogom használni a C-t, de mi van akkor ha "egyszer" jó rendszergazda leszek és kevés gondom lesz a munkahelyement, kitudja, még + munkát is bevállalhatok mellé.

A Shell szkript prog-al maximálisan gyetértek, ezügyben már 2 hónapja tettem lépést, megvettem a "UNIX/Linux Héjprogramozás" c. könyvet és elég sok hazsnát vettem, főként logok szűrésében vagy olyan szkriptet dobtam össze ami pár alkalommal nagyon hasznos volt.

Pyton-t abszolút nem ismerem, miért lenne jobb ezzel kezdeni mint pl C-vel?

Szerintem olvass bele a az ajánlott linken a könyvekbe és akkor valamilyen képet kapsz arról, hogy milyen a Python illetve mire jó. Bár én egy kissé megtévesztőnek tartom, amikor azt írják, hogy adatfeldolgozásra nem való. Ezt annyival kiegészíteném, hogy közvetlen fájl szintű adatfeldolgozásra valóban nem, de ha az adatbázist egy SQL szerveren lévő adatbázisban tároljuk, akkor már igen.
Amúgy meg OO nyelv, a mai elterjedt adat típusokkal. Rengeteg könyvtár van hozzá, de ez ma már szinte minden nyelvre elmondható. Ja a legfontosabb különbség, a C-hez képest, hogy interpreter nyelv, de a betöltéskor van egy "előfordítás", így a futás eléggé gyors. (Na bumm fél másodperc helyett másfél alatt töltődik be.)

Azért, mert a pointer, pointerre mutató pointer, memória allokáció
és felszabadítás, * - os vackok:) megértése nem triviális, egy abszolut
kezdőnek nem biztos, hogy az "apró" nyelvi hülyeségekkel kell
szívni, amikor éppen arra lenne szükség, hogy gyors sikerélménye legyen.
Ezt a könyvet egyébként én is csak ajánlani tudom:

http://learnpython.openproject.hu/

mert a C és C++ olyan eszközök, amelyek ultra hatékonyak, néha "portolható assembly" nyelvnek is emlegetik őket (na jó, ez inkább a C-re igaz).
Ezért viszont azt az árad kell fizetned: az így elkészített program gondatlan /kezdő/ programozás esetén viszonylag könnyen rejtélyes elszállásokat produkálhat.

Egy kezdő programozónak inkább azt kell elsajátítani, hogy szigorúan logikusan gondolkozzon: hogyan kell egy valós életbeli problémát visszavezetni valamilyen nevezetes problémára, az algoritmusban milyen eseteket kell lekezelni és hogyan, mik a kivételek és azok hogyan kezelendők.

Ennek begyakorlásához inkább valamilyen biztonságosabb nyelvet, pl egy script nyelvet, Pascal-t javaslok, hogy ne egyszerre kelljen megküzdeni az algoritmusokkal és a nyelvvel.

Tökéletesen egyetértek.

Annyi hozzáfűzni valóval, hogy pl python (és a legtöbb script nyelv) nem túl típusos nyelv, és ha ez beidegződik az emberbe, akkor késöbb egy típusos nyelvnél nagy szívások lesznek.
Illetve tapasztalatom szerint pythonban elég érdekes a hatókör és láthatóság kérdése...

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

Hát, én BASIC-kel kezdtem (ZX Spectrumon), és utána tanultam C-t, úgyhogy saját tapasztalatból mondom: nem szabad típusok és szigorú hatókörkezelés nélküli nyelvvel kezdeni.
Az implicit változódeklaráció is csak arra jó, hogy megkíméljen egy-két sor gépeléstől, és cserébe 10 percenként lábonlődd magad.
Rendes, igazi programnyelvvel kell kezdeni. Ez lehet C, C++, Fortran (90-esben letiltható az implicit deklaráció), Pascal, bármi, csak típusos legyen.
A C-t azért is javasolnám (az előttem szólókkal ellentétben), mert igaz, hogy egy kicsit nehezebb, cserébe rákényszerít, hogy tudd, mi is történik. A rejtélyes elszállások nagy részét ma már elég könnyen fel lehet deríteni (egy jó malloc debuggerrel)

Szerintem a manualokat olvasgasd, ha a héjprogramozás könyvet átrágtad, mert nagyon sok olyan kapcsolója van a parancsoknak, amelyek igen hasznosak és nincsenek benne könyvben, ráadásul a reguláris kifejezésekkel kapcsolatban is sok információ van a manokban.

--
unix -- több, mint kód. filozófia.

( budacsik | 2006. 10. 13., p – 09:33 )

Most kipróbálom ezt a Python-t, elkezdtem olvasni a könyvet (pdf-et) is és végülis tényleg úgy tűnik, hogy ezt könnyebb megtanulni mint a C-t, könnyebb nyelv, de ha most ráállok a Python-ra akkor azzal nem csak a Python tudásom fog gyarapodni, ill. (bocsi, nehezen tudom megfogalamzni amit kérdezni szeretnék) szóval ha meg is tanulok Python-nyelven programozni azzal például már könnyebben nekivághatnék a C tanulásának? Ez lenne az egyik fő kérdésem.
A másik, meg, hogy a Python tudásom érni is fog valamit, vagy csak a C előtti "bemelegítésre" jó?

A python népszerű. Egyre népszerűbb. Akik használták már, azt mondják, hogy logikus és hatékony nyelv. Az objektumkezelése állítólag nagyon jól ki van találva. Nekem egy kicsit furcsának tűnik a szintaktikája. Ha C-ben akarsz programozni, akkor kezd C-vel. De ha gyorsan akarsz fejleszteni és a sebesség annyira nem számít, akkor a python is tök jó.

--
unix -- több, mint kód. filozófia.

Átmeneti megoldás lehet arra az esetre, ha mégis a C a végső cél, hohy ha Java-t tanulsz.
Nagyon hasonlít a C-hez, majdnem megegyezik a nyelvezete és a szintatktikáj is, de szabadabb pl. a memóriakezelésben, amivel csak speciális esetekben kell foglalkozni. Javaban az OO stílusú programozást is gyakorolhatod.

Elkövettem azt a hibát, hogy perl után futottam bele a pythonba, így aztán ha muszáj azt használnom, tépem a hajamat, hogy "hogy a .*-ba lehet ilyen bonyolultan megcsinálni a legegyszerűbb dolgokat is", mintha a viszkető bal fülemet a bal kézzel a tápcsatornán alulról felfelé átnyúlva, nyak körül kétszer körbetekerve, kisujj második percének belső oldalával kellene megvakarnom.
Nem mondom, a php-nél még mindig szimpatikusabb, de nem igazán lopta be magát a szívembe, bár az is lehet, hogy csak nem a megfelelő feladatra próbáltam alkalmazni, bár akkor viszont felmerül, hogy milyen feladatra is a legalkalmasabb...

Bocs, ha valakinek a kedvence a nyelv, nem sértésnek szánom, úgyhogy maradnék annyiban, hogy nekem nem tetszik, én nem ajánlanám kezdésnek (sem).

Igazad van perl utan nem ajanlott a python. De o nem tud programozni:)
Es elso nyelvnek meg en nem ajanlanam a perlt, szerintem nagyon konnyu elveszni a forraskodban, ha az ember nem ismeri jol a nyelvet, a python inkabb ranevel a normalis kodolasra mint a perl/php ott azert eleg konnyu gany kodot irni.

York.

------
"Nyugi! Minden a legnagyobb rendben csúszik ki a kezeim közül..."

A Python alkalmas arra is, hogy akár nagy alkalmazásokat (még rafikus felhasználói felületüeket, vagy egyszerűbb rajzoló, garfikus programokat) is tisztán Pythonban készíts el. Csak a kifejezetten sebesség szempontjából kritikus programokat vagy program részeket kell más (pl. C) nyelven megírnod. Erre (kapcsolat más programnyelvekkel) is van támogatás a Pythonba, ha érdekel nézz utány a A python COM (Componen Object Model) rendszerének.
Ha komolyan gondolod a Python tanulást, akkor Rashi Gupta: Mindentudó Python c. könyvet nagyon tudom ajánlani.
http://www.kiskapu.hu/index.php?BODY=BookInfo&OP=details&ID=51076&VISIT…

Ha sokat használod, akkor megragad egy bizonyos szemlélet.
Megtanulsz algoritmizálni.

Ez után a C-ben már "csak" a típusokkal, deklarációkkal, mutatókkal kell megbarátkozni.
Nem tudom mennyire járható út ez így.

Tegye fel a kezét aki nem Pascallal kezdte!

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

Én a Spectrumot átugrottam, C64-el kezdtem és "relativ adatbázissal" egy mezőgazdasági erőgép, norma és költségelszámoló program volt a legnagyobb amit véghez vittem benne. Ehhez (konkrétan a képernyőkezeléshez) felhasználtam egy MaskTool nevű nyelvi kiterjesztést, ami egy kubai programozó műve.
Volt C és Pascal is a C64-re, de azokban akkor nem mélyedtem el.

Pontosítok:
Tegye fel a kezét, aki egy Hello word-nél komolyabb programot (fájlkezelés, grafika) nem pascalban írt először.

Tehát C64 Basic, vagy Simon's Basic (vagy mi volt a neve?) nem ér, csak ha tényleg nem Hello Word meg pattogó vonal szint volt.
Egye fene QBasicet elfogadom. :)

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

A C64 BASIC igenis ér!!!
Lásd amit feljebb írtam. Az egy komoly program volt. Egy Tsz-ben használták, ahol vagy 30-40 mezőgazdasági erőgép normálhektár teljesítményét, üzem- és kenőanyag felhasználását, önköltségét és a termelési ágazatokban (búza, árap, kukorica, napraforgó, stb termesztés és sertés, marha, juh, pulya, stb tenyésztés ) végzett munkák felosztását végezték. A program az adatokat floppylemezen relatív adatbázisban tárolta.
Ha ez neked, komolytalan program, akkor... (most egy hatalmasat legyintettem)

Akkor még PC nem nagyon volt Magyarországon. A C64 ára nyomtatóval Floppyval 200 eFt küröl volt. Egy PC-XT ára 10-20 MB-os!!! HDD-vel 640 KB vagy 1 MB RAM-mal ennek a 4-5 szörösébe került. 1987-88-ig a C64 volt a legelterjedtebb irodai gép.

Amúgy nem olyan kínhalál volt az. Az eljárásokat gosub-bal hívtuk, a paramétereket globálisan adtuk át. Egy kis fegyelemme egészen áttekinthetően lehetett programozni. A Floppy meghajtó saját CPU-val rendelkezett, így azt is lehetett programozni, igaz csak assemblerben. A Novotrade és a Databecker jóvoltából egy csomó jó könyv is volt hozzá.

Még így is fent van.
C64-hez írtam basic-ben (nagyon) egyszerű játékot. Ha meg komolyabb projectről van szó, akkor C++-ban ( + wxWindows) írtam a szakdolgozatom.
Pascalt minden egyes iskolában, meg tanfolyamon megtanították, ha mindent összeszámolok, akkor eddig összesen ötször magyarázták el az alapjait, ebből háromszor pedig teljes mélységében tanították. Ez nem kis mértékben járult hozzá ahhoz, hogy ne szeressem a nyelvet.

hehe, felteszem a kezem:P
suliban pascalt tanítottak, akkor nem voltam rá fogékony, szóval azt nem számolom, ráadásul olyan komolyat nemis írtunk suliban sem:D
szóval: grafikus programot írtam mIRC scriptnyelven, az volt az első scriptnyelv, amit úgy-ahogy megtanultam.. de valami miatt senki sem vett komolyan... :D

_________________________________________
Valódi paraszt vagyok. Csak előre tudok lépni, nem azt ütöm le, aki velem szembenáll, és ha nincs tovább, megváltozom.

Na pont erre akartam kijukadni, hogy majd mindenkit pascalban kezdtek tanítani, ami nem biztos, hogy rossz.
Miért?
Mert típusos nyelv, így megszokja az ember, hogy a változókat deklarálni kell, hogy van érték, és címszerinti paraméterátadás, stb.

Ha valaki pythonban kezd, akkor ezeket nem tanulja meg, és később lehet, hogy egy C-t visszalépésként fog megélni.

C-ben kezdeni meg azért nem jó, mert nehezen befogadható a bűvészkedés a mutatókkal, arról már nem is beszélve, hogy egy int ki tudja hány bites, stb.

Tehát hiába fintorgok én is, a pascal nem rossz első nyelvnek.

(Pl Eltén Ada-t tanítanak ilyen állatorvosi lónak, ami ránézésre hasonlít a Pascalra, de lényegesen fejlettebb nyelv (viszont a kutya sem használja (csak régen a Nasa))

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

Az első komolyabb programomat (egy Tetrist :) Z80 asm-ban írtam Spectrumra. (Aztán átírtam HT1080Z-re :)
Az első "fizetős" programomat C64 Basic-ben írtam: egy tagnyilvántartó programot. Igaz, az adatbáziskezelés asm volt, mert az adatbázis nem fért el a memóriában, csak az index, és a sebesség érdekében blokkosan kellett a floppy-t kezelnem. (De szép is volt a telefonszámokat BCD-be kódolva tárolni :)
A másodikat Clipperben (már nem emlékszem mi volt, valami könyvelőrendszerhez egy modul).
A harmadikat már Pascal-ban, mert Win alá kellett, de a bináris fele asm-ból jött össze a sebesség érdekében.
Ha belegondolok, igazán komoly cuccot soha nem raktam össze tisztán Pascal-ban. És most már nem is fogok, maradok a C#-nál ;)

PRIMO A64(BASIC) alatt num integrálás, grafikus UI, kémiai analitikai eredmények számolása (anno domini 1985(?))
---------------------------------------------------------------------------
Környezetvédelmi nyilatkozat: Ez a hozzászólás kizárólag reciklált elektronok felhasználásával íródott.

Bocsánat: CP/M alatt Fortran (Obádovics tanár úr előadásában)
---------------------------------------------------------------------------
Környezetvédelmi nyilatkozat: Ez a hozzászólás kizárólag reciklált elektronok felhasználásával íródott.

jha, én is azzal kezdtem az egész IT-t, számitógépem akkor még nem is volt, mindez egy nintendo (!) beépitett "játéka" volt, alap basic parancsokat bevett, sorokat beszámozva futtatható volt az egész. Ejj, régi szép idők:D

--
Desktop: 2.6.21-gentoo-r4 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
Laptop: 2.6.22-gentoo-r5 Mobile Intel(R) Pentium(R) 4 - M CPU 2.00GHz

( rigidus | 2006. 10. 14., szo – 11:28 )

Nem olvastam vegig a topikot mert nagyon hosszu, de ha C-vel eljutottal egy bizonyos szintre, hogy onalloan tudsz programozni, erdemes lenne mellette valamilyen OO nyelvet is elkezdened. Lehetoleg olyat ami hasznositja a korabban C-ben megtanult ismereteidet. Pl: C++, C#, Java

Ezek kozul en a C#-pal probalkoznek mivel a nyelv termeszetebol eredoen nagy valoszinuseggel ebbe az iranyba fog elmozdulni az IT. Maga a nyelv leginkabb a Java-ra hasonlit, csak nyiltabb, kevesebb megkotessel rendelkezik, ill. kepes leszel mas nyelveket is vegyesen hasznalni vele, stb. Felsorolni is nehez. :-)

Ja, ha a C-vel ugy erzed, hogy nehezen baratkozol meg, tul nyersnek tunik, akkor en valasztanek egy kisebb lepcsofokot elotte, pl pascal. A pascal kimondottan oktatasi celokra lett tervezve, kesobb viszont eterjedt es eleg szeles korben hasznalt nyev lett az uzleti eletben is. Mas nyelvek elotti "kissamlinak" viszont mindig is tokeletes lesz. :-)

---------------------
Minél korszakalkotóbb ötlettel állsz elő, annál több hülyén kell átverekedned magadat.

En most C-ben kezdtem el programozni. Szerinted akkor ezekszerint erdemes ezekutan, ha mar hasznalhato lesz a tudasom C-bol atallni C#-re? Ok, az meg szerintem legalabb 0,5-1 ev, hogy kijelenthessem, hogy tudok valamit (de nem mindent), csak kivancsi vagyok, hogy azert megis merre fele kacsintgassak ugy kbra. Lenne egy kerdesem: A C# ugye M$ szabvany ha jol tudom. Tudom, hogy van a mono, de ha C# nyelven irsz programot, nincsen valami korlatozas arra, hogy hogyan hasznalhatod a programot? Ill. az M$ nem fogja idovel megakadalyozni azt, hogy lehessen nem M$ termekre fejleszteni ezzel a programnyelvvel?

"A C# ugye M$ szabvany ha jol tudom."
Igen.

"nincsen valami korlatozas arra, hogy hogyan hasznalhatod a programot?"
Tudtommal nincs. A nyelvre biztos nincs.
A futtatókörnyezetre (.NET Framework) sincs tudtommal, az egyetlen megkötés, hogy nem publikálhatsz benchmark eredményeket ami összehasonlítja más környezetekkel (pl mono).

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

>A pascal kimondottan oktatasi celokra lett tervezve, kesobb viszont eterjedt es eleg
> szeles korben hasznalt nyev lett az uzleti eletben is. Mas nyelvek elotti "kissamlinak"
>viszont mindig is tokeletes lesz. :-)

1. pl. semmilyen masik nyelvvel sem kompatibilis meg ranezesre sem! Tehat ha megtanulod, jo sok munkaba kerul atszokni egy masikra. :) ld. procedure,function, deklaraciok, szintaxis stb. Raadasul nagypapas programozasra szoktat, nem eleg tomor. Az oo implementacioja (Borland) nem szoktatja ra a felhasznalot a helyes programozasra, holott a nyelv tudna. (kivetelkezeles kieroszakolasa mint a Java-ban, interface-ek hasznalatanak hianya, stb.)

2.Azert terjedt el, mert a Delphi-ben lehetett klikkelgetve programozni. Mivel a draga jo Borland behalt, mar nem lesz olyan nepszeru. Tudom, ott a Lazarus, de azt csak azok hasznaljak, akik ragaszkodnak a pacal-hoz es mivel nyiltforrasu es free, sohasem lesz akkora reklamja mint a Delphi-nek, ezert az ujoncok nem fogjak megtalalni. (teszem hozza hal'isten)

Igazabol el kellene dontenie a kolleganak, hogy mire szeretne hasznalni a programozas tudasat. Eretnekseg, de szerintem a C olyan helyekre valo, ahol nincs user interakcio, viszont kicsinek es gyorsnak kell lennie. pl. kernel, mikrogepek, stb.
Ha felhasznaloi programokat szeretne irni, akkor Java es C++. Akar ebben a sorrendben.

Nalunk is minden programozasrol szolo tantargy rovid programja igy kezdodik:
1. felev C programozas...
2. felev C++... "A C++ szarmaztatasa a C-bol"

Egy idiota valahol leirta, a tobbi meg masolgatja. Annyi kozos van bennuk, mint a gozmozdonynak es a F1 versenyautonak: energia befektetessel tomeget kereken elmozditani.

Az egesz C++ referencia konyv es a C++ kodolasi szabalyok tele vannak azzal, hogy ezt meg azt ne a C megszokott gyakorlattal csinaljuk, mert akkor ez es ez a hiba lesz. Meg a macro-kat is tiltjak.

Aztan ott vannak a koklerek, akik C++ tantargyban Borland TurboC-ben Pascal programokat oktatnak!
Pointer nem kell, az az ordogtol valo! A TurboC Dos alapu, legalabb 20 eves cucc! Ebben az iparban ez mar a kőkor!

Tudomasul kell venni, hogy a programozas is szakososdik, regen nincsenek mar univerzalis programozok. Raadasul minden nyelvben megvannak a sajat kidolgozott metodusok, amelyek a masikban nincsenek meg, vagy mashogy vannak implementalva. Ha meg mindent akarsz, akkor eljutsz az igazi programozo szintjere:

"az igazi programozo mindnen nyelven tud fortran programot irni" :)

A kovetkezo szempont a platform fuggetlenseg. Hal'istennek a M$ mar nem egyeduralkodo, tehat erdemes meggondolni, hogy pl. C#-t tanulj. Persze van Mono, de az mindig is M$ fuggo lesz, nem beszelve a licenceleserol. Ebben a temaban valahol mar olvastam egy cikket, aminek az volt a konkluzioja, hogy nem art ovakodni tole. A feltetles forditas hianya nekem nem volt olyan kinos, ezt leginkabb a Java-hoz nem kello mertekben erto egyeb nyelvet preferealo ocsarolok szoktak hangoztatni. A m$-nak mindig is voltak olyan hajlamai, hogy mindent atalakitson a sajat szajaize szerint. Ezert is kellett a C#, mert a Sun letiltotta a java megeroszakolasi torekveseit.
Tudtommal csak a M$ visual C++ implementacioban van try finally, a "szabvanyos" C++-ban nincs.

Megintcsak a Java es a C++ maradt. A Java eleg gyors lett es _nagyon_ sok free library van hozza, nem is beszelve az ingyenes fejleszto eszkozok garmadajara es itt nem csak az ide eszkozokre gondolok, hanem pl. az ant, maven, junit es egyeb segedeszkozokre.

A C++ kisse mar veszelyesebb viz elsore, mert nagyon nehezen kapsz kepet a teljes rendszerrol, ill. a lehetosegek teljes tarhazarol. Talan jobbnak tunik a Javarol atnyergelni.

( budacsik | 2006. 10. 19., cs – 13:20 )

Srácok!

El van döntve. A C ill. C++ -t tanulom.
A C -t már elkezdtem :)

( cashy_hu | 2008. 03. 15., szo – 16:14 )

Ha javasolhatok, rendszergazdaként inkább scriptelj: bash, ksh, stb. aztán go perl, python, stb. Ezeknek NAGYON nagy hasznát fogod venni.
A C-t meg majd közben vmikor.

cashy

( lorinczi v | 2008. 03. 15., szo – 21:12 )

cashy-hu +1. Az első: döntsd el milyen programot akarsz írni. A rendszergazdai munkádat akarod fejleszteni, vagy egyéb. A munkahelyeden szinte biztos van valami adattömeg, lehet hogy SQL is kell.
---------------------------------------------------------------------------
Környezetvédelmi nyilatkozat: Ez a hozzászólás kizárólag reciklált elektronok felhasználásával íródott.

( imp | 2008. 03. 15., szo – 21:25 )

ez egy másfél éves topik, akinek nem tűnt fel...

( mhmxs v | 2008. 03. 15., szo – 22:55 )

ha már rendszergazda vagy én inkább a pythont javasolnám megtanulni, mert abban tudsz elegáns scripteket írni, másrészt pedig egy kezdő programozónak lehet könnyebb elsajátítani az alapokat. Nincs túldokumentálva magyarul, de az alapokat el lehet sajátítani és aztán lehet lépni tovább.

( rpsoft v | 2008. 03. 16., v – 18:45 )

Hamár feléledt egy ilyen régi topik, akkor, ha esetleg olvassa az eredeti topiknyitó, érdekes lenne ha megírná, hogy végül mire jutott: milyen programnyelvet tanult, milyen könyvből, milyen sikerrel?

Oké, hát rosszul haladok. A mindennapi munkám során a szkriptírás fejlődött a legtöbbet, valamint a PHP amiben tovább haladtam. A C-t elkezdtem, de most stand by van.

Holnap megírom melyik C könyvből kezdtem a tanulást, valami alap könyv amit szinte mindenki ismer, de nem jut eszembe az írója.

PHP-t a php.net dokumentációjából, és ha valamit nem találtam akkor google, de nincs másik site amit feljegyeztem. Ez is szükségszerű volt. Amit csak "úgy" szeretnék (C nyelv) nem nagyon van rá időm :(

-
budacsik

( lorinczi v | 2008. 03. 20., cs – 11:25 )

Csatlakoznék a topic nyitójához. Foglalkozik-e valaki Ruby-val, különösen az ő GUI-jával az FXRuby-val?
(Lenne néhány száz kérdésem.)
Vagy mit tudtok javasolni: VB6/SQL7 alatt programoztam, helyette keresek valamit.
---------------------------------------------------------------------------
Környezetvédelmi nyilatkozat: Ez a hozzászólás kizárólag reciklált elektronok felhasználásával íródott.

Nem open source, de ha már úgyis ismerős a nyelv: VB2008/SQL2005. Az express ingyen van, mindkettőből, az elkészült programra nincs licensz megkötés (mint anno a Delphi Personalnál).
Elég gyorsan, produktívan lehet benne fejleszteni -főleg adatbázisos programot-, és jó gépeken (mondjuk 1.6GHz és 256MB RAM fölött) gyorsak a kész programok. Fejlesztő gépnek viszont erősnek kell lennie (2GHz+, 768-1024MB RAM).
Persze ha a nyelvtől (és a környezettől) akarsz szabadulni, akkor nem szóltam.
De tényleg elég produktív a fejlesztés.

OpenSource irányban a MonoDevelop-ot érdemes kipróbálni, bár nekem annyira nem jön be.

Az alap az, hogy fusson Linuxon és Windowson egyaránt. Most a Python-wxPython tásasággal kezdek barátkozni. Mindkét op. rendszeren első próbára fut. Még irodalmat is találtam hozzá.
---------------------------------------------------------------------------
Környezetvédelmi nyilatkozat: Ez a hozzászólás kizárólag reciklált elektronok felhasználásával íródott.

A Python-wx jó választás.
Csak az érdekesség kedvéért: Linuxra is létezik VB és .NET méghozzá a Novell gondozásában:
http://mono-project.hu/
http://www.novell.com/hungary/news/070227_mono_visual_basic_h.html
http://www.hwsw.hu/hirek/32973/mono_visual_basic_compiler_windows_linux…