ELTE vs EKE Programtervező BSc

Sziasztok!

A 2019/2020-as tanévben kezdeném el a Programtervező BSc-t levelezőn, viszont még nincs eldöntve, hogy mely intézmény lenne a legjobb döntés.

Az ELTE és az EKE között vacilálok, viszont nincs túl sok információm arról, hogy melyiknél mik a követelmények és miket tanítanak.

Jelenleg tanulók, frissen végzettek véleményét szeretném kérdezni, hogy szerintük melyik lenne jobb, milyen tárgyak vannak, milyen programozási nyelvek, stb.

A válaszokat előre is köszönöm!

Hozzászólások

ELTE-ről nem tudok nyilatkozni. EKE-n végzett egy ismerősöm, sok (nagyobb) helyen miután kiderült, hogy ott végzett már érezhető volt, hogy nem fogják felvenni, már ahol előbb volt a motivációs beszélgetés mint a CV begyűjtése.. az elmondása szerint. Bár az tény, hogy nem hülye gyerek mégse tudott értelmesen elhelyezkedni azóta se, pár éve végzett.
Igaz egyszeri eset és lehet nincs köze az intézményhez. Ellenben ha műszaki dolgot tanul az ember akkor BME/Miskolc a top 2 meglátásom és elmondások szerint. Na meg én alapból átgondolnám a PTI-t a helyedben.

return signResponse.getSignForUser("zeletrik").map(SignResolvable::getSign).orElse(StringUtils.EMPTY);

(Nem konkrétan e két esetről, de általában igaz:)
Azt kell tudnod, hogy tudás vagy papír kell. Megúszni akarod vagy rendesen megcsinálni.

Esti és levelező kategóriában bpi-ként:
OE-NIK (nincs katalógus) szerintem azonnal használható tudást ad bőven elégséges elméleti háttérrel. Papírra a Dunaújvárosi egyetemet szokták mostanában mondani.
ELTE-IK: van katalógus, erősebb az elmélet, ami már inkább tudományos, mintsem gyakorlatias így talán sok mindent, nem is BSC-n kellene erőltetni, hanem később. Nagyon kevés a 7 félév ahhoz, hogy felkészítsen a munkára, ha az idő nagy részében nem azzal foglalkozunk, hogy mivel mit lehet csinálni, hanem azzal, hogy mit lehet tudni a témáról. Minél magasabb szinten van valaki tudása annál inkább cselekvésképtelenebb lesz, mert egyre több szempont jut eszébe, ami a legtöbb esetben kontra produktív.

Szent István egyetem több kurzusát végignéztem online, az is egy lightosabb hely lehet, hasznos tudással, de én egy egyetemtől többet várnék. Több kurzusok konkrét (termék, létező technológia) tudást ad és nem általánosított absztraktot.

Itt megemlíteném, hogy az OE-NIK-en a C# csak laboron van, amit arra használnak, hogy az elméletet bemutassák. A laborbeadandók az elméletben tanult pszeudo kódok implementációja. Ezt hasznosnak tartom nagyon, mert itt az absztrakt szint termékké változik.

Egy dolgot kifelejtettem:

Jelenleg elsődlegesen csak papír miatt kell a Programtervező BSc, mert középsuliban tanítok, de csak egy OKJ Rendszergazda papírom van. Azért kell most egy szakmai, illetve utána tanárit akarok tenni.

Viszont mivel csak papír kell, akkor miért kérdezem? Egyszerű! Ha már elvégzek egyet, akkor legalább olyat akarok ahol normálisat tanulok és bővíthetem a tudásomat. (Illetve mellék álláshoz jobban mutat, hogy megvan papír is :D )

Jelenleg C#, HTML/CSS, JavaScript, SQL programozást mondom ami jobban megy és tanítom (JS-t már nem). Mellette elkezdtem Python-t tanulni. Már régóta érdekel a C++ (régebben bele is kezdtem azt is tanulni), mostanság még a Rust-on vacilálok a C++ helyett. Még régebben PIC programozást tanultam C-ben, de ez már megkopott tudás.

Ezért érdekel, hogy melyik helyen mit tanítanak, mert akkor el tudom dönteni, hogy melyik áll hozzám közelebb.

---
"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

Ha a fő cél a papír, de szeretnél sokat tanulni is, akkor azt válaszd, ahova rövidebb idő alatt odaérsz. Levelezőként nagyon gyorsan fog fogyni a motivációd, ha órákat kell utazni. Az az előadás meg nem nagyon hasznos amin nem vagy ott - bár még mindig hasznosabb, mint az, amitől elmegy az egésztől a kedved :-)
A tanárság miatt, meg azért mert azt tartod célnak minden tiszteletem a tiéd. Rendszergazdának lenni könnyebb lenne.

Bárhová is mész, ha a matek tudásod megkopott vagy soha nem is volt csúcson, akkor azt nagyon húzd fel. Az estin a hallgatók 80%-ka ezen és/vagy a programozás/algoritmuselméleten elvész, majd feladja.

Kis segítség ahhoz mit érdemes tudnod:

Matek tudás teszt (TTK-hoz kevés, a többihez elég lehet):
https://alfa.bme.hu/

Átlagos BME hallgató (nem TTK) ezt az előadást hallgatja az első fél évben. Érdemes belenézned, ha vérzel már a megértésnél, akkor az alábbi könyvek segíthetnek.
https://www.youtube.com/watch?v=QxTwuU0BBLw&list=PLqHY9XaXF06PcjGxWqbaM…
https://www.scolar.hu/ismeretterjesztes_tankonyv_318/matematika_381/mat…
https://www.scolar.hu/ismeretterjesztes_tankonyv_318/matematika_381/fel…
(8 részes sorozat első két könyve)

Programozás OE-NIK első félév (elmélet):
http://users.nik.uni-obuda.hu/sergyan/Programozas1Jegyzet.pdf

BME-n szerintem irreálisan szigorúan kezelik a kiegészítő gazdasági tárgyakat, főleg a közgázt. A hallgatók szivatásán kívül sok értelme ennek nincs.
Az ELTE-IK képzésének megközelítése nekem szimpatikusabb, bár nyilván elfogult vagyok mert ott végeztem. Szürke ló az Óbudai egyetem NIK, ismerőseim akik oda jártak azt mondják az egyik legjobb gyakorlatorientált programozó képzés megy ott.
A vidéki egyetemeket nem ismerem eléggé. De az EKE biztosan nem tartozik az erős egyetemek közé prog képzésben. Debrecen, Miskolc talán jó.

Most az OE-NIK-re járok, kell tanulni rendesen elméletet, de a gyakorlat az tényleg jó (bár sajnálatomra Windows C#, ami amúgy könnyedsége miatt igazából előny). Programozásból jók a beadandók, mert sokat kell rajtuk agyalni, egyik sem triviális. Maga a féléves programozás beadandó szerintem több mint 30 munkaóra.

Úgy vélem egyetemeknél sohasem a hallgatói bemenetet kell nézni, hanem a kimenetet. Ugyanis a pontszám az csak indexszálja a népszerűséget. A "rosszabb" bement csak több kibukást eredményez(het).

Bar tobb, mint husz eve volt, egyet kell ertenem. A BME kozgaz (mikro es makro ekonomia, vagy mi volt a cime) kb nulla.

Azonban nemhogy elhagyni, hanem erositeni kene a teruletet. Foleg akkor, ha mernoknek tekintjuk a programozot (legalabb egy csoportjukat), es nem C-majomnak. Persze szakmunkas szintu programozokra is nagy kereslet van (3 honapos gyorstalpalo, indiai "2 diplomas" kollega stb), de az nem a BME master kepzese...

Bocsi, de nem értek egyet. Nincs szükség rá, se a mikróra, se a makróra. Akit érdekel, csináljon egy közgazdász másoddiplomát, azért van.
Ennek az égadta világon semmi köze a mérnökképzéshez. Ugyanez a véleményem a fizikáról is. Ahova a két fenti tudás kell, oda nem mérnök-informatikus
kell, hanem fizikus és/vagy közgazdász.

Egy mérnök-informatikus képzésnek szerintem nem feladata a közgazdász, fizikus, bánya és vegyészmérnök képzés, csak azért,
mert ilyen tanár van a fizetési listán. Főleg úgy, hogy lenne bőven mit tanítani, csak éppen azt meg nem tanítják, mert nincs
rá idő. Ha egy cégnél munkát adok, akkor nem az mérnök-infóssal akarok fizikai problémákat megoldatni, meg gazdasági elemzéseket
készíttetni, sőt, fémet se velük akarok olvasztatni. Tehát teljesen felesleges a képzésbe ilyeneket bevenni. Ettől nem lesz belőle
egy trükkös póni, hanem a szakmájához értő szakember lesz. Aztán ha majd érdekli a többi terület (igen, ott van a fizika kultúrtörénete
a polcomon), akkor majd szépen továbbképzi magát.

Az a mikró/makró, amit a BME-n leadnak (2x1 félév, heti 2 óra), az kb. az a szint, ami az érettségihez kötelező kellene legyen. Az, hogy jelenleg nincs benne a gimnáziumi tananyagban, elég indok arra, hogy addig is minden mérnöki képzésbe belerakják.

Az már más tészta, hogy nem tanítják jól, emiatt az emberek le is szarják.

Mostanában azért jobb, viszonylag értelmesnek mondható mind a mik-mak, mind a memvál tárgy. A kötválok se rosszak, pl. számvitel, pénzügyek. Viszonylag értelmes gyakorlati példák vannak, maga a tárgy meg nagyjából jól van belőve nehézség szempontjából. Ezeknél mérfödekkel értelmetlenebb és szarabbul oktatott tárgyak vannak.

+1, egyetértek. Dettó megvolt, 99-ben kezdtem a BME infót, semmi értelme nem volt se a fizikának, se a közgáznak. Ennek ellenére pl.
a fizika kultúrtörténete itt van a polcomon. Közgáz helyett meg üzleti ismereteket kellett volna tanítani, gyakorlati módon. Aztán
akit érdekel, az majd szépen elmegy, és elvégez egy közgázt.

Ha minden jól megy, jövő nyáron végzek EKE-n. Minden megvan, csak a szakdoli csúszik sok meló miatt. Én 43 évesen a papír miatt járok (hátha kell valahová a jövőben szakmai felső fokú végzettség, messze még a nyugdíj :-), így mindegy volt az iskola. És van valamennyi rálátásom a szakmára és a hasznosságára is.

Röviden: ha kevés időd van vele foglalkozni/tanulni, akkor EKE. Jó pár csoporttársam itt írta élete első "Hello World" progiját, és mindenből levizsgáztak. Mondjuk nem engedékenyek vizsgán, csak a kötelező anyag ennyire alacsony szintű (mondjuk ez az ELTE-re is igaz kell legyen, mert ott is ugyan az az állami tananyag elvileg). Ha nevesebb papír kellene a fent említett negatív diszkrimináció miatt, akkor nyilván ELTE.
Egyébként az ELTE-n már van levelező? Mert amikor én kezdtem, csak esti volt, heti 4x kellett volna ott lenni 14-21 óra között (katalógusosan, mert ugye nem fakultatív, mint a levelezős konzultáció), ami munka mellett még pestiként is lehetetlen lenne, nem még vidékiként (nekem Eger van közelebb egyébként).

Hasznossága: egyik helyen sem tanítanak semmi értelmeset, de azt kell mondjam, még csak érdeklődés felkeltő se sok van. EKE-n első kézből tudom, ELTE-ről meg onnan, hogy egy céggel szerettünk volna indítani egy gyakornoki programot tanulóknak, és az ELTE-ről jelentkező 2.-3. éveseknek semmi értelmes gyakorlati tudásuk nem volt, a legtöbbnek a házi feladatok sem voltak elkészítve (nem is értettük, hogyan jutottak így el a 3. évig), hogy saját kódot tudjanak mutatni... De mind le tudta vezetni az üres halmazt a semmiből indulva... ami szép, csak semennyire sem hasznos.

EKE-n C# van fő nyelvként, és C++, HTML/CSS, Assembly, funkcionális 1-1 félévig. ELTE-n a fő nyelv a Java, és ott sem tanítanak érdemben modern technológiákat, nyelveket (JS/NODE, stb) amennyire én tudom (ez utóbbi 2 éves infó, nem friss).

EKE-n a tanárok bő fele fiatal vagy korombéli, kevés idősebb (főleg elméleti tárgyak). A legtöbbjük jó fej és ért ahhoz amit csinál (de nem jobban, mint amit a tanítás megkövetel), kisebb részük nem tanárnak való és/vagy nem ért hozzá. A felszereltség jó, új épületben, aránylag modern eszközökkel tanítanak, tisztaság és rend van. Sőt, már kajálni is lehet (az első két évemben még csak egy büfé sem volt egy épületrész átépítés miatt, a belváros meg gyalog 40 perc oda-vissza a TTK-tól).

De ha tanárit is szeretnél, akkor miért nem kezdesz mindjárt informatika tanárival az EKE-n osztatlanban? Mert az EKE tanár vonalon viszont elismert.
A tanári mindenképp 5 év már, ha előbb PTI-zel, akkor 8 év múlva lehetsz papíron tanár. Sok csoporttársam volt 2 éves posztgrad. infótanár képzésen, hogy az addigi tanárija jó legyen középiskolai infó tanárnak is (régi 3 évessel max általános 6.-ig taníthatnak már csak infót). De menet közbe ez is megszűnt. már csak az 5 éves elvégzésével lehet ilyen, ha van 3 éves tanárija, akkor is.

Ha specifikusabb kérdésed is van EKE-ről, írj nyugodtan e-mail-ben.

A technológiá(ka)t előre vinni valóban nem "szakmunkás" kell, de minden másra igen, és az arány a valós életben 99% szakmunkásra van igény, mert 1% elég a technológiát
fejleszteni. Az arányszám lehet vitatható, de a lényegen nem változtat hogy nagyságrenddel több szakmunkásra van szükség a technológia(ák) alkalmazására, mint azok
kidolgozására. És jó szakmunkások kellenek, mert ahogyan nem örülne az ember ha a szívátültetést végző orvosa kettessel csinálta volna végig az orvosit, ugyanúgy
nem örül annak sem ha a biztonsági rendszerét, banki rendszerét,... kritikus rendszert olyan "programozó" készítené el aki végig a legjobb jeggyel végezte el a tanulmányait.

--
www.autosys.hu

Igen, közben megkérdeztem őket is.

De azért remélem, hogy más iskola indítani fog jövő tanévre levelezőben. A Felvi-n most ugye a keresztfélévesek vannak és a szerint a Gábor Dénes indít most nappaliban. Remélem januárban, amikor kiadják a szeptemberieket, akkor lesz máshol is.

---
"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

Hogy ennek mennyire nincs semmi köze a mai magyar "hétköznapi" (pl. ipari irányítástechnikai) megoldandó programozási feladatokhoz, azt el sem tudom mondani...
De ha valaki nem ért egyet vagy ... kíváncsi vagyok az érveire

Mondjuk a neve alapján ez "csak" bevezetés a programozásba, szóval ez az elrettentés és aki veszi az akadályt az beléphet a következő szintre ahol, talán
hasonló kalandok várják míg valami gyakorlati tudásra nem tesz szert ?!

--
www.autosys.hu

Amikor először találkoztam ezzel akkor én is meglepődtem mert nekem is teljesen más elképzelésem volt a "program tervezésről". Sokan (sajnos korábban én is) összekeverik a program tervezését a program kódolással.

- A program tervezője megalkotja az elméletet és azt matematikai módszerekkel igazolja. Pl. kiszámítja az algoritmus költségét, hatékonyságát, stb.

- A program elkészítője (kóder) egy adott programozási nyelven egy adott rendszerre megírja a programkódot a tervező által korábban elkészített programleírás alapján.

Tehát aki azt hiszi, hogy az eltén a prog.terv. szakon majd win10 előtt ülve fog C# programokat írni az téved. Papíron, ceruzával fog programot írni matematikai (pl. halmazelméleti) eszközökkel :)

Tehát azokat a matematikai elméleti alapokat és módszereket tanítják amelyek felhasználásával lehet a programot tervezni. Egy konkrét programozási nyelv csak egy leíró eszköz, egy termék amit a feladat során használsz. De elmélet nélkül fabatkát sem ér.

Persze mert olyan különálló szakma, hogy kóder már nincs. Nincs rá szükség mert idő közben olyan fejlett és egyszerű lett sok minden, hogy a kódoláshoz nem kell különösebben nagy szaktudás, elég egy megfelelő termék ismeret.

Tehát hiába van valakinek gyakorlata pl. C#-ban, ha az adott feladatra nincs kész függvény, osztály, stb. akkor neki kell megalkotni a program elméleti alapjait. De megfelelő matematikai tudás nélkül nem fogja tudni elkészíteni a programot, vagy rossz minőségű (pl. lassú, bugos, stb.) programot fog készíteni.

"rossz minőségű (pl. lassú, bugos, stb.) programot fog készíteni" - valamiért mikor megnézem,találkozom a nagynevű multi cégek kódjaival elképedve tapasztalom, hogy mennyire igaz az idézet rájuk...
és valahogy egyenes arányban van a programkód minősége a kommentek mennyiségével... miért ?
--
www.autosys.hu

egy adott programozási nyelven egy adott rendszerre megírja a programkódot a tervező által korábban elkészített programleírás alapján

Normális rendszerben először a feladathoz hardver választunk, a hardver után lehet szoftver architektúrát tervezni.

Papíron, ceruzával fog programot írni matematikai (pl. halmazelméleti) eszközökkel :)

Erről már Kernighan-ék megmondták, hogy mekkora marhaság.

> Normális rendszerben először a feladathoz hardver választunk, a hardver után lehet szoftver architektúrát tervezni.

Valószínűleg nem értetted a mondandóm lényegét. Amikor pl. kifejlesztették az arcfelismerő algoritmust, akkor szerinted azzal kezdték, hogy hardvert választottak? Mihez választanának ha még nem tudják, _hogyan_ (milyen elméleti számítások, összefüggések, stb. alapján) lesz megoldva a feladat?

> Erről már Kernighan-ék megmondták, hogy mekkora marhaság.

Akkor biztos úgy van.

Egyébként a Fóthi féle paradigma lényege az lenne, hogy matematikai módszerekkel bebizonyítod a programod helyességét. Tehát nem érzésre jól működik, hanem levezethető és garantáltan helyes a működése.

Hardver limitációd mindig van és azt a kezdetektől figyelembe kell venni. Lehet, hogy az alapján választasz, hogy mire van pénz, vagy mi van kéznél, de ez mindig egy alapvetés. Cseszheted az algoritmust, ha neked egy mobilra kéne, de közben egy mainframe kell, hogy fusson.

Akkor biztos úgy van.

Azért Kernighan vagy Ritchie kicsit nagyobb név a szakmában, mint bárki az eltén.

Tehát nem érzésre jól működik, hanem levezethető és garantáltan helyes a működése.

Egy normális kód nem érzésre működik, hanem átmegy a teszteken.

> Hardver limitációd mindig van és azt a kezdetektől figyelembe kell venni. Lehet, hogy az alapján választasz, hogy mire van pénz, vagy mi van kéznél, de ez mindig egy alapvetés. Cseszheted az algoritmust, ha neked egy mobilra kéne, de közben egy mainframe kell, hogy fusson.

Nem érted, hogy mi a különbség az elmélet és a gyakorlat között. Amikor egy feladatra kidolgoznak egy elméletet akkor nem számít a hardver, a pénz, stb. mert akkor még nem tart ott a dolog. Az algoritmusok "költségszámítása" egy külön "tudomány" ahol szintén nincsen hardver meg pénz. Mert ezeket a számításokat absztrakt módon a mindenkori hardvertől függetlenül végzik. Az algoritmusok és adatszerkezetek tantárgy többek között ezt tárgyalja. http://aszt.inf.elte.hu/~asvanyi/ad/ad1jegyzet.pdf

> Azért Kernighan vagy Ritchie kicsit nagyobb név a szakmában, mint bárki az eltén.

Nem tudod miről beszélsz. Olvasd el a jegyzet bevezetőjét. A jegyzetben Fóthi megemlíti azokat a matematikusokat amelyek munkái (kutatásai) alapján a jegyzetet készítette. Tehát értelmetlen "Kernighan-éket" összemérni bárkivel is az eltéről. :)

> Egy normális kód nem érzésre működik, hanem átmegy a teszteken.

Nem érted, hogy mi a különbség az elmélet és a gyakorlat között. pl. Ha a program bemenetének számossága végtelen, akkor nem tudod letesztelni az összes bemenetre. Ha matematikai levezetéssel igazoltad a program működését akkor a végtelen számú bemenetre is igazoltad a garantált helyes működést.

"Nem érted, hogy mi a különbség az elmélet és a gyakorlat között. pl. Ha a program bemenetének számossága végtelen, akkor nem tudod letesztelni az összes bemenetre. Ha matematikai levezetéssel igazoltad a program működését akkor a végtelen számú bemenetre is igazoltad a garantált helyes működést."

Aztán a matematikailag garantáltan helyes függvény méter helyett lábban kapja a bemenetet, és a szonda elég a Mars légkörében.

"Amikor egy feladatra kidolgoznak egy elméletet akkor nem számít a hardver, a pénz, stb. mert akkor még nem tart ott a dolog."

Érdekes módon a többi mérnöki tudomány eljutott arra a szintre, hogy például nem az örökkévalóságnak akar tökéletes hidat építeni, hanem számításba veszi a reálgazdasági összefüggéseket is. Az informatika oktatás is kibújhatna lassan az elefántcsont tornyából. Ne érts félre, arra is van igény, amiről te beszélsz, de nem hiszem, hogy egy tucatnál sokkal több, évente.

> Aztán a matematikailag garantáltan helyes függvény méter helyett lábban kapja a bemenetet, és a szonda elég a Mars légkörében.

"garbage in, garbage out"

> Érdekes módon a többi mérnöki tudomány eljutott arra a szintre, hogy például nem az örökkévalóságnak akar tökéletes hidat építeni, hanem számításba veszi a reálgazdasági összefüggéseket is. Az informatika oktatás is kibújhatna lassan az elefántcsont tornyából. Ne érts félre, arra is van igény, amiről te beszélsz, de nem hiszem, hogy egy tucatnál sokkal több, évente.

Ez a szak (programtervező matematikus) a programtervezés elméletével (matematikájával) foglalkozik. Ha ez nem tetszik akkor ott a sok másik, ahol termékismertetés van. Megmutatják, hogy a visual bármiben (mert jelenleg az az elterjedt a reálgazdaságban) pl. milyen szintaxisa van egy elágazásnak, hová kell tenni a kapcsos zárójelet és mire kell rákattintani és akkor jó "programozó" leszel. :)

Az elmélet és a gyakorlat közötti vita érdekes módon, ha olyanok között zajlik ahol az egyik fél inkább elméleti a másik gyakorlati tapasztalattal rendelkezik akkor a hasznosság aránya 50% körüli, míg ha a valóságot nézzük akkor ott nagyobb részt gyakorlati tudásra van szükség, mivel a valóság, mint olyan gyakorlati (igaz ezt is vitatják egyesek...) inkább, mint elméleti. Ezért is van inkább szükség tapasztalatom szerint több olyan emberre akik megkeresik a bug-ot és kijavítják (valahogy, úgy hogy a teszteken átmenjen), mint olyanokra akik levezetik matematikailag, hogy hát ez xar...és akkor lehet mellette hümmögni, de szépen írta lambdát...és a program továbbra is túltölti a tárolóedényt sósavval, hogy még portást is oldja fel az üzem területén kívül :)

--
www.autosys.hu

Az egész szál onnan indult, hogy felhívtam a kérdező figyelmét arra, hogy nem biztos, hogy a programozó matematikus az a szak amire ő gondol és megpróbáltam elmagyarázni, hogy miért.

Most ott tartunk, hogy "Kernighan-ék" megmondták, hogy az eltén hülyék vannak, minden algoritmus (elmélet kidolgozása) megalkotása előtt hardvert kell vásárolni, én láttam-e már projektet és kiömlik a sav mert négyzetgyök kettő irracionális... :-D

Igen, ez a két szint van, matematikai bizonyítás, meg kapcsos zárójelek pakolgatása. Jóhiszeműen abból indulok ki, hogy olyan területen vagy, ahol így működik, csak épp az ipar 95%-a nem erről szól. Ez olyan mintha én fizikusként kimenék egy építkezésre nagy pofával, hogy csak ki kell számolni mi merre hány méter, utána a terveket elkészíteni, engedélyeztetni, meghatározni, hogy hova milyen anyag kell már csak szakmunkás meló.

Amúgy milyen másik szakra gondolsz? Mert ezen kívül van a mérnökinfó, ahol még mindig abból indulnak ki, mint 40 éve, hogy a lopott COCOM-listás gép lemásolásával kezdődik a programozás. 20 éve el lett baszva alaposan, hogy új szak indítása helyett ezt a kettőt hízlalták fel. Aztán 10 éve csak súlyosbították azzal az elbaszást, hogy nyakatekert módon vették át a bolognai rendszert, és a bsc alkalmazó informatikus képzés helyett elméleti alapozó lett msc-re.

> Jóhiszeműen abból indulok ki, hogy olyan területen vagy, ahol így működik, csak épp az ipar 95%-a nem erről szól.

Most kérdezhetném, hogy honnan jön a 95%, de nem érdekel.

> Ez olyan mintha én fizikusként kimenék egy építkezésre nagy pofával, hogy csak ki kell számolni mi merre hány méter, utána a terveket elkészíteni, engedélyeztetni, meghatározni, hogy hova milyen anyag kell már csak szakmunkás meló.

Az épületeket nem a fizikus hanem az építész tervezi és a kivitelező építi fel. A kivitelező nem tervez(het) épületet a tervező nem épít épületet.

> Amúgy milyen másik szakra gondolsz?

Nem tudom, nem néztem utána. De biztos van más oktatási intézményben olyan szak ami nem foglalkozik ilyen alaposan az elmélettel és több hangsúlyt fektet valamilyen manapság divatos programnyelv és fejlesztői eszköz bemutatására.

Nagyrészt egyetértve az általad írottakkal azért ne hallgasd el, hogy programtervező matematikus mellett van egy programtervező informatikus szak is az ELTE-ik-n. Ez utóbbin belül is van három szakirány, modellező, szoftvertervező, szoftverfejlesztő/alkalmazó, azaz A B C szakirányok. Itt pedig, pláne C szakirányon az van, hogy ülsz a PC monitor előtt és Code:Blocks-ba meg NetBeans-be stb. kódolsz. Az itt is elmaradhatatlan elméleti tárgyak mellett.
Egyébként ez a nagyobb létszámú szak az ELTE-n, a programtervező informatikus. Ezen a szakon belül mi úgy tapasztaltuk, hogy a B szakirány igen nagy szopás. C-n sokan időben végeztünk, amikor B-n a velünk együtt kezdett csoporttársak még keményen koptatták a padokat. A végén mindenki ugyanazt a diplomát kapta.

Pehsa az elején valóban csak annyit írt Programtervező, szóval nem egyértelmű de inkább informatikus folytatás következik abból szerintem amire ő gondol. Riogatni én FONyA-val riogatnék, ami egyből második félévben jön :)

Manapság nagyon ritkán kell csak elméletet alkotni, egy csak papíron létező rendszer eladhatatlan. Egy csak elméleti fejtegetésnél mindig szebb, ha van legalább valami proof of concept szintű kód.

Az algoritmusok és adatszerkezetek tantárgy többek között ezt tárgyalja. http://aszt.inf.elte.hu/~asvanyi/ad/ad1jegyzet.pdf
Ezt nyugodtan lehetne például új jelölés mód kitalálása helyett C-ben tárgyalni. Máris több értelme lenne. Akkor legalább a hallgató egyből ki is tudná próbálni a tanult adatszerkezeteket. Illetve a C nyelv legalább szabványos ezért annál egyértelmű a kód jelentése.

Ha a program bemenetének számossága végtelen
Ha majd látunk olyan hardvert ami ezt kezeli akkor érdekelni fog, addig nem túlságosan.

Azért a Nassi-Shneiderman diagramot 1972-ből új jelölésmódnak titulálni kissé erős.

Ha a program bemenetének számossága végtelen, azt a mai hardware-ek is kezelik. Az csak annyit jelent, hogy a halmaz, amiből a konkrét bememetet választjuk végtelen sok elemet tartalmaz.

Valamit bele kell írni a struktogramba. Ez nem jelenti, hogy keveri vele. Írhatna barokkos körmondatokat is. Ehelyett felhasznál némi C-szerű pszeudokódot (~10%) a diagramokban a matematikai jelölések mellett, ami tömör és egyértelmű leírást tesz lehetővé. Pont nem talál ki új jelölést ezzel. Az hogy ez kinek tetszik, ízlés kérdése, nyilván ezerféleképpen lehetne. Szerintem elsőre is érthető simán.

> Manapság nagyon ritkán kell csak elméletet alkotni, egy csak papíron létező rendszer eladhatatlan.

Egy rakás olyan probléma van manapság is aminek még elméleti megoldása sincsen és milliárdokat fizetnének érte ha lenne elméleti megoldás.

> Egy csak elméleti fejtegetésnél mindig szebb, ha van legalább valami proof of concept szintű kód.

Egy általános értelemben vett programkód nem működik úgy mint pl. a matematikai formulák. Nem lehet bizonyításokat elvégezni velük. A programkód egy eszköz ami arra való, hogy a számítógép számára leírd mi a feladata.

> Ezt nyugodtan lehetne például új jelölés mód kitalálása helyett C-ben tárgyalni. Máris több értelme lenne. Akkor legalább a hallgató egyből ki is tudná próbálni a tanult adatszerkezeteket. Illetve a C nyelv legalább szabványos ezért annál egyértelmű a kód jelentése.

Sajnos így is sokan képtelenek elvonatkoztatni egy "programnyelvtől" amikor a programozásról van szó.

> Ha majd látunk olyan hardvert ami ezt kezeli akkor érdekelni fog, addig nem túlságosan.

Mondok egy egyszerű példát. Két tetszőleges egész szám összeadása. Hogyan bizonyítod be kétséget kizáróan, hogy a programod biztosan jól működik bármelyik tetszőlegesen kiválasztott két egész szám esetén? Mindet nem próbálhatod végig mert végtelen sok egész szám van. Tehát mindig lesz olyan számpár amit nem próbáltál ki ezért nem biztos, hogy a program kétséget kizáróan jól működik.

"Sajnos így is sokan képtelenek elvonatkoztatni egy "programnyelvtől" amikor a programozásról van szó."

Sokkal inkább probléma, hogy az egyetemeken azt hidetik, hogy ha megtanulsz programozni, utána pár nap-hét alatt megtanulsz bármilyen nyelven, miközben ez helyesen úgy lenne, hogy pár nap alatt megtanulsz bármilyen nyelven beadandót írni, de az élet egy kicsit többről szól.

"Hogyan bizonyítod be kétséget kizáróan, hogy a programod biztosan jól működik bármelyik tetszőlegesen kiválasztott két egész szám esetén?"

Ezt a végzősők 99,9%-ától soha senki nem fogja kérni.

> Sokkal inkább probléma, hogy az egyetemeken azt hidetik, hogy ha megtanulsz programozni, utána pár nap-hét alatt megtanulsz bármilyen nyelven, miközben ez helyesen úgy lenne, hogy pár nap alatt megtanulsz bármilyen nyelven beadandót írni, de az élet egy kicsit többről szól.

Megpróbálom elmagyarázni egy egyszerű példán, remélem megérted.

- Ha az iskolában megtanulod és megérted a bináris fa pre-order bejárásának elméletét akkor akármilyen módon le tudod azt írni. Például magyar mondatokkal, struktogrammal, basic nyelven, assemblyben, pascalban, C#-ban, bármiben. (bubble sort)

- Ha fogalmad nincs a bináris fa pre-orde bejárásáról akkor mit írsz le a jól ismert programozási nyelven? (tegyük fel, hogy az ismert nyelvben nincs bináris fa típus/objektum és nincs definiálva rajta a pre-ored iterátor sem)

Remélem így már érted, hogy az elmélet az alapja mindennek és a programnyelv az egy eszköz.

> Ezt a végzősők 99,9%-ától soha senki nem fogja kérni.

Általános iskolában is megtanítják a pitagorasz tételt, de minek?... :)

Pont erről beszélek, hogy beadandót tud írni bármilyen nyelven. De ha már nem ilyen elemi feladatot kell megoldani, akkor jönnek a nyelvi elemek, konvenciók, frameworkök ismerete, amit már hónapokig tart összeszedni. Nem az a kunszt, hogy olyan programot írj, ami lefordul, hanem hogy olyat, amin nem sírja el magát egy évek óta a nyelvvel dolgozó ember. Vagyis hogy tudj adott nyelven egy fejlesztőcsapat részeként dolgozni.

"Általános iskolában is megtanítják a pitagorasz tételt, de minek?... :)"

Ne tereld el a szálat, az egész abból indult, hogy kelleni fog, mert így kell elkezdeni programozni, nem arról, hogy miért tanítják.

> Pont erről beszélek, hogy beadandót tud írni bármilyen nyelven. De ha már nem ilyen elemi feladatot kell megoldani, akkor jönnek a nyelvi elemek, konvenciók, frameworkök ismerete, amit már hónapokig tart összeszedni. Nem az a kunszt, hogy olyan programot írj, ami lefordul, hanem hogy olyat, amin nem sírja el magát egy évek óta a nyelvvel dolgozó ember. Vagyis hogy tudj adott nyelven egy fejlesztőcsapat részeként dolgozni.

Direkt egyszerű példát írtam, hogy könnyen érthető legyen. Nem értetted meg. Még egyszer utoljára megpróbálom elmagyarázni de most más szempontból.

Szerinted az oktatási intézménynek mely programozási nyelvet, melyik framework-öt, milyen konvenciókat kellene tanítania? Amikor szinte évente változnak ezek a divatirányzatok szerint, továbbá az iskola honnan tudja, hogy a végzős leendő munkáltatójának csapatában milyen elvárások lesznek?

> Ne tereld el a szálat, az egész abból indult, hogy kelleni fog, mert így kell elkezdeni programozni, nem arról, hogy miért tanítják.

A pitagorasz tétel is egy olyan dolog mint a program helyesség bizonyítása. Pl. egy pék nem számol a pitagorasz tétellel és nem minden program készítése során használják a bizonyítást sem.

Nézd meg a BME képzését, és meglátod. Még azon is lenne mit bőven kalapálni, de az irány nagyjából jó.

- Kell alap matek, nem matematikusra van szükség általában az IT-ben
- Kell algoritmuselmélet (alapvető algoritmusok, gráfelmélet, fordítók, stb.)
- Kell modellezés (általános modellezési ismeretek, és ezen belül tömegkiszolgálás, szabtech, stb. de ebből sokkal kevesebb kellene, inkább arra rámutatni, hogy a különböző modellekkel hogyan oldunk meg feladatokat, és ezt begyakoroltatni)
- Kell OO tudás (mitől oo, solid elvek, refactoring, stb.)
- Kell funkcionális programozás tudás (vs oo)
- Kell programtervezési ismeretek
- Kell projektvezetés/management (waterfall, rup, scrum, kanban, stb.)
- Kell soft skill oktatás (pl. elolvasni a 12 Essential Skills for Software Architects)
- És ezek után jöhet az alap szakismeret, mint például:
- hálózati ismeretek
- linux/unix ismeret
- pár keretrendszer ismerete
- pár programozási nyelvvel való ismerkedés (alacsony szintűtől magas szintűig)
- stb.

Ez a jegyzet egész jó, de vannak benne konkrét baromságok is, például egyből a 8-ik oldalon:
"A és Z való jában pointerek, amik a megfelelő vektor-objektum memóriacímét tartalmazzák"
Ilyennek nincs helye egy absztrakt, matematikai tárgyalásban, és teljesen implementációfüggő, hogy a tömbök a memóriában hogyan helyezkednek el - attól, hogy egy tároló fix méretű és indexelhető (erről szól a definíció), tömb lesz, de ennek semmi, de semmi köze a memory layouthoz, ne keverjük ide.

Baromira nem jó ez a jegyzet, keveri az absztrakt adatstruktúrákat egy olyan memória modellel, ami nem szükséges az adatstruktúrák tárgyalásához. Egy absztrakt tárgyalásnál feleslegesek azok a dolgok, mint referencia meg érték szerinti paraméterátadás - az absztrakt jelölés mindent elbír, nem köti gép és futtatókörnyezeti sajátosság.

Ugyanígy call stackezik, mintha az valójában fontos lenne az adatszerkezetek tárolásánál. Nem fontos.

Emiatt nehéz ebből a jegyzetből tanulni.

Nem sok, hanem a legtöbb esetben erre semmi szükség. Ez persze nem azt jelenti, hogy nincs szükség matekra, de azt nem a kódon, hanem
egy modellen alkalmazzuk. Pl. kell csinálni egy szabályzót (embedded fejlesztés teljesen alap példa). No, itt az adott feladatra
alkalmazzuk a matekot és oldjuk meg a feladatot. Aztán az egészet körberakjuk tesztekkel. Vagy azt kell megnézni, hogy hogyan skálázódik
egy adott rendszer. Erre is vannak szép modelljeink, amikből tudunk valami becsléseket csinálni, utána mérünk, utána a modellt finomítjuk, stb.
Vagy mondjuk ott van egy üzleti folyamat. Tudni akarjuk a tulajdonságait. No, elővesszük a petri gráfokat, és szépen lemodellezzük vele.
BPMN-be van leírva? Tök jó, mert arra már megvan a megoldás, hogyan lehet belőle petri gráfot építeni. Vagy tetszőleges útvonalkeresés, stb.
Akkor ott a gráfelmélet illetve hálózatelmélet, és rögtön alkalmazom a feladatra. De nem a kódom helyességét akarom bizonyítani, mert azt
senki az égadta világon nem fogja nekem kifizetni.

Amennyire én megértettem, ez nem algoritmus matematikai helyesség bizonyítás, hanem szimpla "fuzzing": addig generálnak bemenetet, amíg hibás kimenetet nem kapnak. A kézi teszt-eset írás gépi automatizálása, némi redukcióval. Nem azt mondta meg h. hibás ez az algoritmus, csak vaktában bombázta teszt esetekkel.
--

A vaktában lövöldözés az első fázis, a másodikban a megtalált ellenpéldákat minimalizálja, hogy a beszállító tudjon vele mit kezdeni.

Azért a munka-megtérülés a szoftveriparban is létezik, ahogy a hardver esetén is. A SAT solver-eknek nem véletlenül van újra reneszánsza, fontos, hogy az áramkör tényleg azt csinálja, amit elvárnak tőle. A sztochasztikus keresés csak az egyik irányzat.

Ahogy az olajkútnál is teljesen mindegy, hogy Eötvös-ingával akadtak rá a területre, vagy varázspálcával; a fejlesztőnek (vagy a főnökének) is az a fontos, hogy ha hiba van a termékben, az mihamarabb kiderüljön, és lehetőleg minél olcsóbban.

Biztos van olyan terület, ahol megéri a helyesség-bizonyítás, míg máshol a 99.9999%-os helyesség is megfelelő lehet.

Én még a kéziratból tanultam amit akkor készített az öreg és fejezetenként osztott szét a diákok között. Azóta nyilván rengeteg javítás és módosítás került bele. Volt egy másik jegyzet is amit a párhuzamos programozás tárgyat tanító tanár (nem jut eszembe a tanár neve) készített. Abban több volt a magyarázat és kevésbé volt száraz.

Az ELTE-re csak akkor menj ha szereted a matematikát, és hajlandó vagy komoly, sok féléven keresztül tartó felsőbb matematikai élményekben részt venni. A másikat nem ismerem, az ELTE-re sem jártam, csak számos odajáró ismerős osztotta meg.

--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene

subs
--
"Csak webfejlesztést ne..." -ismeretlen eredetű szállóige-