Létezik olyan programozás amit matek nélkül oktatnak és lehet is keresni vele?

persze.

:D

ez kb olyan mint orvosi munka latin tudás nélkül :D:D

Alapvetően annak a rengeteg mateknak, amit egyetemen megtanulsz, kb. az 5-10%-át fogod használni a munkád során, szakterülettől függően. Nem is azért tanulod, mert anélkül nem lehet programozni. A programozó szakokon a matektanításnak - legalábbis az én meglátásom szerint - az az értelme és célja, hogy a logikus gondolkodást, az absztrakciós képességet, és a komplex problémák/rendszerek/logikai felépítmények átlátásának és megértésének a képességét [ki|tovább]fejlessze.

Enélkül is megtanulhatod egy nyelv szintaktikáját, és lehetsz koder, de én úgy vettem észre eddigi szakmabeli ténykedésem során, hogy az ilyen autodidakta/OKJ-s programozók többségénél gyengék/hiányoznak a fentebb leírt képességek, amik viszont kellenek ahhoz, hogy igazi profi legyen valakiből.

Akire rá lehet bízni azt, hogy ne csak egy megoldást találjon egy problémára mindenáron, és azt adott nyelven implementálja is le(ez kb. az indiai programozó szint: ) ), hanem a legoptimálisabb megoldást találja meg, értsünk optimális alatt akármit.

Leginkább persze a performanciát értjük optimális alatt, és ehhez már elengedhetetlen némi elméleti matematikai tudás.

Pl. az egyetemet/fősulit végzett koma kis gondolkodás után meg tudja mondani egy adott problémáról:

1. hogy itt a legoptimálisabb megoldás is O(n^2) futási időt igényel

2. nagy bemenetre elképesztően lassú lesz

3. szól a vezető fejlesztőnek és/vagy architect-nek

4. Vezető fejlesztő és/vagy architect jó esetben az adott komponensben/egész rendszerben végzett újratervezéssel kiküszöböli a problémát

5. A klienshez egy normális rendszer megy ki

6. Fele annyi support feladat sem lesz.

Ugyanez indiai megoldással: Eszébe sem jutnak ilyesmik, hogy futási idő, meg hasonló jelentéktelen dolgok, vagy ha igen, akkor sem fogja tudni megbecsülni.

1. Lekódolja a sz*ar algoritmust

2. leszállítják a rendszert

3. A kliens rinyál, hogy lassú, nyit egy support ticket-et

4. Indiai programozó elolvas egy cikket a neten, hogy : "XY language performance optimization", és akkor pl. c++ esetében fogja, és minden függvényt átír inline-ra. Adott nagyságú bemenetre ezzel a 60 sec futási időt lenyomja mondjuk 58-ra

5. Kimegy a bugfix

6. Kliens szemszögéből a 60 sec és 58 sec között kb. semmi különbség, ticket re-open

7. Megy vissza az egész probléma indiai programozónak -> 8. Indiai programozó megint elkezd guglizni ->Kiírtja a virtuális függvényeit az egész kódból(emiatt persze öröklődésnek lőttek, copy-paste minden osztályba a hajdani ős tartalmát), futási idő : 56 sec

9. Kimegy a bugfix

10. GOTO 6-os pont :)

És ez így megy, kivéve, hogy a kliens a 6-os pontban minden egyes ciklus után egyre növekvő valószínűséggel azt mondja, hogy break;, és viszi a rendszerét valami értelmes céghez, ahol lehet, hogy 2x az órabér, de tudnak is fejleszteni.

És ilyenkor nagyon rábaszott az, aki annál a cégnél dolgozik, mert egy ilyen össze-vissza gányolt indiai fosrakást rendbetenni nem fehér embernek való munka :D

Igen, az elég valószínű, hogy indiánok munkája is van benne, a multik szeretnek Indiában dolgoztatni, mer' olcsó :D

Mondjuk nekem alapvetően nincs semmi különösebb bajom a windózzal.

"4. Indiai programozó elolvas egy cikket a neten, hogy : "XY language performance optimization", és akkor pl. c++ esetében fogja, és minden függvényt átír inline-ra. Adott nagyságú bemenetre ezzel a 60 sec futási időt lenyomja mondjuk 58-ra

5. Kimegy a bugfix

6. Kliens szemszögéből a 60 sec és 58 sec között kb. semmi különbség,"

Jól írtad de had tegyek hozzá még néhány mondatot.

Vagy az is lehet, hogy milisecundumokat gyorsít csak. Még az is lehet hogy lassít vele. Ha minden függvény inline akkor sok helyet foglal a memóriába ha sokszor előfordul ennek a függvénynek a kódja és eleve nagy függvény vagy ez a függvény is sok inline függvényt tartalmaz. Előállhat az az extrém eset is hogy a különböző szintű gyorsítótárak, nem gyorsítanak hanem jó ha nem lassítanak.

Vagy ha "kézzel" akar optimalizálni c kódot nem hozzáértő (alacsony szinten), akkor még ronthat rajta, a c fordítóba alapból optimalizál alacsony szinten, ezt jobb ha a fordítóra bízza az ember.

Az "indiai" programozó O(n^2) futási idejő algoritmust próbál optimalizálni assembly-be ez egy nagy inputra nagyságrendekkel lassabb lesz mint, ha egy hozzáértő talál rá O(n*log n) futási idejű algoritmust és implementálja akár java-ban.

Szumma szummárum valamelyik OKJ-s képzés lehet olyan, de meglátszik a szoftver minőségen. Össze vissza gányolnak az ilyen programozók, aztán bugába dőlhet a projekt előbb utóbb.

Azt kell mondanom hogy lehet keresni is vele, de kevesebbet.

Persze, hogy előfordulhat, hogy lassít. Most nem is a fordító optimalizációja a lényeg, meg hogy épp egy c++ példát írtam. A lényege az volt az egésznek, hogy elméleti matematikai felkészültség nélkül a koder-ek nagy része csak gondolkodás nélkül gányolni fog, mert az életben nem hallott ilyenekről, hogy időigény szerint az algoritmusok osztályozása, ezért pl. simán nekiáll két listával/tömbbel(mondjuk A és B) A különbség B-t kiszámolni for ciklusokkal. Kipróbálja néhány 100 elemre, semmi gond. De aztán használat közben több 100000 elemre fog futni az algoritmusa.

És csak pislog, hogy miért ilyen lassú.

És ha van is elég esze ahhoz, hogy timer-ekkel kimérje, hogy melyik függvény mennyi ideig fut, akkor sem tud majd mit kezdeni vele, mert nem fog eszébe jutni, hogy bináris keresőfával mondjuk fel tudja gyorsítani a cuccot.

Viszont egy "tanult" programozónak, aki még oda is figyelt az előadáson, ilyen esetben feldereng majd valami mindenféle futási időkről, meg adatszerkezetekről, és utánanéz, hogy is volt az az AVL-fa, és hopp, a*b lépésszám helyett meg is oldja a feladatot log2(b) + a*log2(b) lépésben.

"Pl. az egyetemet/fősulit végzett koma kis gondolkodás után meg tudja mondani egy adott problémáról:

1. hogy itt a legoptimálisabb megoldás is O(n^2) futási időt igényel "

Kivancsi volnek ki az a PhD-vel rendelkezo, aki megmondja hogy egy regex konyvtar mennyi futasi idot igenyel.

Ezek szep elmeletek futasi ido szamolas qsort()-ra meg egyszeru algoritmusokra, de bonyolultabb algoritmuson nem fogsz leulni szamolgatni.

En szoktam googlezni, megpedig azert mert tudom, hogy az oriasi internetben mar valaki megoldotta a problemamat sokkal jobban mint ahogy en azt terveztem. Es ha megertem a mas altal irt kodot mar elegedett vagyok. Nem szegyen a googlizas, mert inkabb kigooglizek egy jol bevalt algoritmust amit mar tobb ezren kiteszteltek, minthogy nullarol feltalaljam a kereket ujra es ne adj isten sikeruljon belecsempesznem egy-ket bug-ot is.