Lenyomta a Python a Java-t és a C/C++-t is az egyetemi oktatásban

Lenyomta a Python a Java-t és a C/C++-t is az egyetemi oktatásban
2014-07-11T13:05:01+02:00
2014-08-28T19:15:06+02:00
2022-10-22T08:15:31+02:00
  • No de ebben a témában megint túltengtem, szóval kiszállok...

    [ezerszer túltárgyalt, számomra érdektelen téma, csak hát az "igazság"...]
    Mutasd a teljes hozzászólást!
  • "teljesen téves meglátás és terminológia, de ő így képzeli"

    Szokás szerint beképzeltnek hangzik amit írtál.

    Természetesen mindenki tudja, hogy "típustalan" nyelv, mint olyan nem létezik, hiszem amint egy változó tartalmát használni kívánod, azonnal valamilyen típust tulajdonítasz neki.
    Még az olyan script nyelvek is, amik technikailag egyszerűen stringben tartalmaznak változó tartalmakat, azok is a rajtuk végzett művelettel típus értelmezést kapnak (pl. a 'for' ezzel 'típust' ad (kívánt/elvárt tartalmat definiál, így a 'típusmeghatározás mentes' adatot valódi típussá kell konvertálni).
    De millió megvalósítás van, a tartalom típusa kód + memória terület megoldásig.
    Egészen a típusos nyelvek reflection megoldásáig.


    Maradjunk abban, hogy öreg róka vagyok én már, láttam sokmindent... egy ilyen "ósdi" témában nem hiszem hogy megfoghatnál
    [nem ma találták ki a dinamikus típusos(típusdeklarációt nélkülöző)/script nyelveket és írtam én is pár százezer programsort ilyesmiben, meg jó kis asm/C betéteket is, amivel a memória tartalommal kellett szórakozni... szóval valamelyes értem én amit írok, csak nem fetisizálom ezt a (szerintem) kényszerpályát, ami ráadásul teljesen megfoghatatlan, mert a statikus típusdefiníciót használó fordító programok elméletével szemben egy 'képlékeny' terület (nincs olyan mélyen tudományosan feldolgozva, mivel a megoldások is számtalan variánsban léteznek)]
    Mutasd a teljes hozzászólást!
  • "nem igaz, hogy mindennek a mélyén C++ lenne, mint emelhu mondta, mert bizony sokminden alatt továbbra is C van"

    Azért tisztázzuk... ne ragadjátok ki a szöveget a kontextusából.
    Nem azt írtam, hogy már nem is létezik C, annak is megvan még a szerepe. [*]

    Azt írtam, hogy mindeenminden dinamikus/típusdefiníció nélküli nyelv mélyén van egy típusos kód, ami mára tipikusan C++.
    Illetve minden komoly alapot (oprendszer, adatbázis, grafikai motor stb, mire egy script nyelv támaszkodik ugyanígy (tipikusan(!)) C++-ban írják.
    Még a mái napig...
    Ennek meg számos oka van. [**]

    Ennyi, nem több.


    [*]: Olyannyira, hogy írtam én már egyszerű/kis utility-t, ami bár kiterjesztésében CPP, de tulajdonképpen (a kód 95%-ában) C.

    [**] Hofi szavaival élve:
    Ennek két oka is van. Mert ez van, és mert nincs más.
    Mutasd a teljes hozzászólást!
  • De lehet, hogy csak nem konzekvensen használod a típusos nyelv definícióját.

    Vagy lehet, hogy csak nem olvastál elég alaposan, vagy egyszerűen csak nem értetted meg amit írtam.

    A jövőben jön egy új típus nélküli nyelv, vagy visszatérünk az assembly-re?

    Nem tudom mi jön, csak azt, hogy idővel minden technológia túlhalodottá válik és leváltja valami újabb. Így értelmetlen azt mondani, hogy egy technológia, sőt, egy sokelemű technológiacsoport elemei "soha nem fognak eltűnni". Mert persze, hogy el fognak (annyira, hogy már csak múzeumokban meg hobbicélokra fogják használni őket, mint ahogy a C64-et is említettem). A kérdés csak az lehet, hogy ez az idő mikor fog eljönni.

    Ez volt az amit a múzeumos bekezdésben leírtam, csak nem ennyire szájbarágósan.

    Másik témában ehhez kötötted a "laikus" jelzőt, ehhez képest egy hozzászóláson belül valószínűleg két külön értelemben használod a "típusos nyelv" fogalmát.

    Én csak egy értelemben használtam. A helyesben. A másik használat amit beidéztél nem tőlem származik, hanem emel-től, aki sajnos annak ellenére még mindig nincs tisztában ennek a fogalomnak a jelentésével (illetve, hogy milyen fogalommal kell illetni azt, amire ő valójában gondolt), hogy már évek óta minden egyes alkalommal belefut ebbe a hibába és hogy minden egyes alkalommal újra és újra el lesz magyarázva neki, hogy az, hogy egy nyelv úgymond típusos, nem azt jelenti, amit nyilvánvalóan ő gondol róla, hogy jelent.

    Nála a típusos nyelvek a C, C++, C#, Java, stb. A PHP, JavaScript, Python, stb. meg szerinte nem ebbe a körbe (ti. a "típusos nyelvek" körébe) tartoznak. Ami persze teljesen téves meglátás és terminológia, de ő így képzeli és így használja ezt a fogalmat. Ennek tévességére utaltam a másik idézett bekezdésben.

    Csak azért írtam, mert egy másik témában kicsit személyeskedőnek éreztem az ottani megfogalmazásod, bár lehet, hogy nem az itteni hozzászólásra utaltál vissza, számomra mégis ez érződött.

    És? A fentiek tükrében nem volt igazam? De.
    Mutasd a teljes hozzászólást!
  • Szerintem itt önellentmondás van, vagy nagyon furcsa a jövőképed :)
    De lehet, hogy csak nem konzekvensen használod a típusos nyelv definícióját. pár sor eltéréssel.

    "Soha nem fognak eltűnni a típusos nyelvek."
    emelhu
    "Nem hát. Hiszen múzeumokban továbbra is megtekinthetők lesznek. Meg nosztalgiából emulátorokban lehet majd programozni bennük - mint pl. ahogy a C64.."
    Sting
    ...
    "Nyilván. Hiszen az egyetlen mai úgymond típus nélküli mainstream nyelv az assembly. A C, C++, C#, Java, JavaScript, PHP, Python, stb. viszont mind típusos nyelvek."
    Sting

    A jövőben jön egy új típus nélküli nyelv, vagy visszatérünk az assembly-re?
    Sejtem, hogy mit akartál írni, de ez így elég szerencsétlen megfogalmazás.
    Másik témában ehhez kötötted a "laikus" jelzőt, ehhez képest egy hozzászóláson belül valószínűleg két külön értelemben használod a "típusos nyelv" fogalmát.

    Csak azért írtam, mert egy másik témában kicsit személyeskedőnek éreztem az ottani megfogalmazásod, bár lehet, hogy nem az itteni hozzászólásra utaltál vissza, számomra mégis ez érződött.

    Is JavaScript an untyped language?
    "So the problem is that there's a few different definitions of untyped."
    Mutasd a teljes hozzászólást!
  • Hmm, jogos.

    A lényegben azért szerintem egyetértünk: nem igaz, hogy mindennek a mélyén C++ lenne, mint emelhu mondta, mert bizony sokminden alatt továbbra is C van. De az se azért, mert olyan biztonságos lenne (a standard könyvtár bizonyos részei csak remélik, hogy elegendő puffert kaptak), vagy mert annyira alkalmas lenne komplex projectek fejlesztésére (névtér támogatás nincs benne, adatrejtés is csak nagyon kezdetleges formában).
    Mutasd a teljes hozzászólást!
  • C64-re vagy 8 bites mikrovezérlőkre nem feltétlenül van C++ fordító, csak C de azokon nem is hiszem hogy bárki PHP-zne vagy pythonozna.

    Az említett platformok memóriakapacitása és CPU sebessége nem igazán "viseli el" azt az overheadet, amit az OOP igényel. Meg egy valamire való komplexitású virtuális gépet sem. Pláne nem egy virtuális gépen futó OOP-t (php, js, python, stb.).
    Mutasd a teljes hozzászólást!
  • Az assembly kb. annyira típusos mint a C. Csak az ő változói a regiszterek. És van a memória ami lényegében egy nagy változótömb, amibe beírhatod illetve kiolvashatod a változóid értékét.
    Mutasd a teljes hozzászólást!
  • Őszintén szólva kétlem, hogy létezne olyan környezet amire nincs gcc és elfut rajta a Python vagy a PHP. C64-re vagy 8 bites mikrovezérlőkre nem feltétlenül van C++ fordító, csak C de azokon nem is hiszem hogy bárki PHP-zne vagy pythonozna. Az ok inkább a projektek kora lehet. Akkoriban amikor ezek keletkeztek, a C++ még nem volt annyira elterjedve.
    Mutasd a teljes hozzászólást!
  • Valójában tehát nincs semmiféle alá- és felérendeltségi viszony (még függőségi, architekturális értelemben sem) a statikus és a dinamikus nyelvek között.

    Nyilván, mivel az összes eddig említett nyelv Turing-teljes, emellett mindegyik fordítása és futtatása algoritmizálható (különben most sem léteznének), tehát megvalósítható Turing-teljes nyelvvel. Ebből következik, hogy bármelyikben írható bármelyiknek a fordítója/futtatója. Így hát természetesen el lehet készíteni az aktuális C++ fordítót az előző C++ fordító segítségével, meg JavaScript interpretert JavaScriptben, meg Assemblyben C fordítót és C-ben Assembly fordítót.

    Hiszen az egyetlen mai úgymond típus nélküli mainstream nyelv az assembly.

    Ez így félrevezető, mert bizonyos szempontból az assembly is típusos, hiszen explicit módon minden pillanatban tudod, hogy egy adott memóriatartalmat milyen típusként értelmezel. Az már más kérdés, hogy ugyanazt az adatot nyersen, bitre pontosan különböző típusúként is értelmezheted, mindenféle ellenőrzés és konvertálás nélkül. Az is igaz, hogy csak primitív típusú adatokat kezelhetsz, minden bonyolultabbat már neked kell összeraknod és kezelned úgy, hogy becímzel a megfelelő memóriacellába. Azért, hogy ezt a fordító megtehesse neked, típusos az összes olyan nyelv, ami leginkább gépi kódra való fordításra lett létrehozva.

    Tehát mivel mindennek az alján a processzor által futtatott gépi kód áll (a processzor vezérlőjében működő mikroprogramot nem nézve), ezért a gépi kódot vagy assembly-ből kell fordítani, vagy valamilyen típusos nyelvből. Ezután, ha már van assembly+assembler, vagy az előbbi nyelved+fordítód, már tetszőleges számú interpretert és fordítót implementálhatsz és onnantól valóban nincs függőség. Viszont miután meg assemblyben nem túlságosan kényelmes nagy programokat írni és a legtöbb esetben teljesen fölösleges, ezért legalább a C szintjére jó felugrani absztrakciós szintben, de lehet még tovább is, C++-ra (lehetne más is, de a C++ népszerű). Gondolom emelhu így értette, hogy C++ van mindennek a mélyén. Mert JavaScript interpretert készíthetsz Pythonban, ami utóbbi is egy Java-ban írt interpreteren fut, de a sor legvégén csak a processzor dolgozik, tehát gépi kód fut, tehát "fordított" (és nem interpretált) kód, ami utóbbit igen csak nagy valószínűséggel típusos magasabb szintű, vagy kevésbé valószínűen assembly nyelven írtak.

    A történet végső csavarja azonban kétségtelenül az, hogy abban neked van igazad, hogy a nyelvek között ettől még nincs alá- és felérendeltség, maximum arról beszélhetünk, hogy mennyire feature gazdag egy adott nyelv, vagy mennyire esztétikus, kompakt, következetes, stb.
    Mutasd a teljes hozzászólást!
  • Ez egy buta elképzelés.
    Soha nem fognak eltűnni a típusos nyelvek.

    Nem hát. Hiszen múzeumokban továbbra is megtekinthetők lesznek. Meg nosztalgiából emulátorokban lehet majd programozni bennük - mint pl. ahogy a C64-et is a mai napig hekkelgetik, írogatnak új demókat rá, stb. De, mint mindennapi munkaeszközök, azokban a formáikban ahogy ma ismerjük őket, előbb-utóbb biztosan túlhaladottá fognak válni, és új dolgok fogják leváltani őket. Ez minden technológia sorsa az informatikában.

    Az "igazán komoly" alkalmazások típusos nyelvekkel készülnek

    Nyilván. Hiszen az egyetlen mai úgymond típus nélküli mainstream nyelv az assembly. A C, C++, C#, Java, JavaScript, PHP, Python, stb. viszont mind típusos nyelvek. Így hiába kezdenek egyre több valamirevaló programot utóbbiak közül is az utolsó párban írni, továbbra is igaz marad az állítás, hogy azokat mind típusos nyelvekkel készülnek. Szóval ebben az egyben igazad van - de csak azért, mert gőzöd se volt mit írtál le valójában.

    Mint most a C++.
    Akárki akármit is mond, mindennek a "mélyén" ez van!

    Nem. Mindennek a mélyén a típus nélküliség: az assembly, a gépi kód van. Meg a numerikus és a Boole algebra, a halmazelmélet, stb.

    A Python, a PHP és a JS környezete is C++-ban (típusos!) nyelven készül.

    Ez persze megint nem igaz. A dolog úgy igaz, vannak Python-, PHP- és JS-implementációk amik C++-ban készültek, és vannak amik nem. Pl. létezik JavaScript-ben írt PHP futtatómotor és PHP-ban írt JavaScript futtatómotor is. Sőt, van JavaScript-ben írt C fordító, és CoffeeScript-ben írt assembler is. Valójában tehát nincs semmiféle alá- és felérendeltségi viszony (még függőségi, architekturális értelemben sem) a statikus és a dinamikus nyelvek között.

    Milyen érdekes.

    Ugye? Ma is sok új és érdekes dolgot tanulhattál.
    Mutasd a teljes hozzászólást!
  • Ez egy buta elképzelés.
    Soha nem fognak eltűnni a típusos nyelvek.

    Szerintem olvasd el még egyszer, amit írtam, mert pont arra hoztam föl érvet, hogy miért nem fognak eltűnni.

    Szvsz abban, hogy ezek a projectek a C-t választották, sokkal nagyobb szerepe van annak, hogy a villanyborotván kívül minden elektromos kütyüre van C fordító, mint annak, hogy a nyelv statikus típuskezelésű.

    A C-t azért választották és azért maradt népszerű, mert gyakorlatilag minimális háttér/glue/infrastrukturális kódot készít a fordító. A forrásba leírtakból nagyjából ki lehet következtetni, hogy mely assembly kódot készíti el belőle. A C valahol az assembly felett van nem sokkal és kompakt szintaxisa van. Ezért használják (kb. mindenhol valamire). Tulajdonképp assembly "helyett". Ezért is statikusan típusos. Amikor pl. egy operátort írsz a forrásba, akkor a fordító a típusdeklaráció nélkül nem tudná, hogy melyik opkódot/opkódokat válassza. Minden strukturált típusinformáció csak fordítási időben van, futási időben se objektumok, se típusdefiníciók nincsenek (tehát reflectionről szó sem lehet), csak a gépi kód, ami memóriacímekkel és az ott lévő adatokkal dolgozik. Az adott művelet tárgyadatának típusa pedig bele van kódolva az adott gépi utasításba. Ráadásul a típusok kb. a 8-16-32-64 bites egészek és a 32-64 bites lebegőpontos értékek lehetnek.

    C++-ban is meg tudod csinálni az előbbieket, ha nem használsz OOP-t. Az OOP-nek van infrastrukturális overheadje (ld. pl. virtuális függvénytábla). A Python és a Java pedig már teljesen más világ. Ott már eleve van egy szoftver (pl. JVM), ami implementálja egy másik szoftver (pl. Java-ban írt program) futtató környezetét.
    Mutasd a teljes hozzászólást!
  • Vannak eszközök, amikkel elég jól kilehet szűrni az ilyen hibákat!

    Igen, és vannak módszerek, amikkel ezek az eszközök nem tudnak mit kezdeni. Konkrétan az OpenSSL-nél a drága fejlesztők újraimplementálták a malloc egy részét, ami hazavágott mindenféle analizátort. Az indok ráadásul egy állítólagos teljesítményprobléma volt, ami csak bizonyos platformokon jelentkezett, tehát egy biztonsági szempontból kritikus kódban a teljesítményt preferálták a biztonsággal szemben.

    Amikor úgymond profi fejlesztők ilyen komoly következménnyel járó hibákat vétenek, érdemes meggondolni, hogy ne vegyük-e ki mégis a kezükből a pisztolyt, amivel lábönlövik magukat...

    Pl. C++ használata C helyett -> std::array, std::vector stb.. tud range checket. Debug fordításba tökéletesen kilehet szűrni ha túlfutnánk, releasebe meg mehet check nélkül :)

    Igen, a támadók pedig majd lesznek olyan kedvesek, hogy csak a debug buildet támadják, a release verzió puffertúlcsordulását meg udvariasan figyelmen kívül hagyják... Komolyan annyira nincs számítási kapacitásunk így a 21. század hajnalán, hogy alapértelmezésben nem tudjuk megkövetelni a tömbindex-ellenőrzést? (Mondjuk a C-n ez se segítene, mert sokszor csak pucér mutatód van, a fordítónak esélye sincs az indexeket ellenőrizni. Ezért is kétszer meg kell gondolni, hogy olyan célra akarod-e használni, ahol értékes adataid vannak.)

    A C++ valóban jobb annyiban, hogy ott legalább lehet kérni az ellenőrzést, aztán reménykedhetsz, hogy az összes általad hívott third-party kód is kérni fogja. (Vagy ők is a teljesítményt tartják szem előtt a biztonság helyett, és csak túl fogsz menni a pufferen...)

    (Szabvány C kódok igen nagy része fordul szabvány C++ fordítóval :) Szóval attól, hogy validC kód, attól még lehet valid C++-kód is. Csak C++-ban rendelkezésünkre állnak kifinomultabb megoldások is :)

    Inkább úgy mondanám, hogy ha az adott C kód írója direkt odafigyel olyanokra, hogy pl. explicit cast-olja a malloc visszatérési értékét, akkor tud poliglót C/C++ kódot írni. Persze ettől még ugyanúgy nem fogja elérni pl. a C++ konténereket (mert onnantól már C-ként nem fordulna a kód), szóval a C++ előnyeit nem fogja tudni kihasználni.
    Mutasd a teljes hozzászólást!
  • Nekem erről az oktató nyelvről az jut eszembe, hogy a műegyetemisták meg tésztából készítenek hidat.
    Mutasd a teljes hozzászólást!
  • Vannak eszközök, amikkel elég jól kilehet szűrni az ilyen hibákat!

    Pl. C++ használata C helyett -> std::array, std::vector stb.. tud range checket. Debug fordításba tökéletesen kilehet szűrni ha túlfutnánk, releasebe meg mehet check nélkül :)

    3rd party tools: Valgrind és még sok hasonló

    Megfelelő fordító beállítások:
    GCC esetén pl:
    stack-protector, AddressSanitizer

    Fejlődik a világ:)

    (Szabvány C kódok igen nagy része fordul szabvány C++ fordítóval :) Szóval attól, hogy validC kód, attól még lehet valid C++-kód is. Csak C++-ban rendelkezésünkre állnak kifinomultabb megoldások is :)

    Stroustrup: FAQ
    Mutasd a teljes hozzászólást!
  • Mint most a C++.
    Akárki akármit is mond, mindennek a "mélyén" ez van!

    A Python, a PHP és a JS környezete is C++-ban (típusos!) nyelven készül.

    A Python referencia implementációja speciel C-ben készül, nem C++-ban. A Wikipédia szerint a PHP interpreter is C-ben készült.

    Szvsz abban, hogy ezek a projectek a C-t választották, sokkal nagyobb szerepe van annak, hogy a villanyborotván kívül minden elektromos kütyüre van C fordító, mint annak, hogy a nyelv statikus típuskezelésű. Hiába őskövület a nyelv, és hiába enged meg "epic fail" kategóriás programozási hibákat, egyszerűen túl elterjedt ahhoz, hogy ki tudjon pusztulni.

    (OFF: Találós kérdés: melyik a biztonságosabb? Egy "típusos" C kód, ami szó nélkül túlolvas a pufferen, vagy egy "típus nélküli" Python kód, ami elszáll hibával hasonló esetben?)
    Mutasd a teljes hozzászólást!
  • "A típusos nyelvek eltűnése esetén..."


    Ez egy buta elképzelés.
    Soha nem fognak eltűnni a típusos nyelvek.

    Az "igazán komoly" alkalmazások típusos nyelvekkel készülnek és egy "lazább" réteg kerülhet csak efölé script/dinamikusan típusos nyelvekkel.

    Mint most a C++.
    Akárki akármit is mond, mindennek a "mélyén" ez van!

    A Python, a PHP és a JS környezete is C++-ban (típusos!) nyelven készül.
    Milyen érdekes.
    Mutasd a teljes hozzászólást!
  • A gosubnak pedig nem tudtál címkét adni

    ZX81-em nekem is volt, ott a gyári BASIC ismerte a "GOSUB xxx" utasítást, ami az xxx "címkéjű" (azaz sorszámú) sorra ugrott. Másképp nem is értem mi értelme lett volna. A paramétereket valóban csak globális változóban (másféle nem is volt) lehetett átadni. 

    Ciklus csak for volt

    Meg IF és GOTO...
    Mutasd a teljes hozzászólást!
  • Anno én gimiben kezdtem basic-ezni, ZX81-en, HT-n, majd a saját Commodore VC20-on. Voltak adattípusok, de csak lebegőpontos, string és int. A gosubnak pedig nem tudtál címkét adni, sem paramétert. Ciklus csak for volt, Pl. while csak a 4.0-tól (Commodore 16, Plus4).
    Mutasd a teljes hozzászólást!
  •  Anno én is basic-cel kezdtem

    Én is. Öt évesen C64-en. Ott bizony voltak adattípusok (a szintaxis kódolta az adattípust... a string ha jól emlékszem $ az egész % a lebegő pontos meg már nem is tudom milyen változónév-suffixet kapott), és hat éves koromra már a GOSUB - RETURN utasításoknak is komoly hasznát vettem. BASIC-ben is lehet strukturált kódot írni, csak nem szorítja rá az embert.
    Mutasd a teljes hozzászólást!
  • Én sem hiszem, hogy ne lehetne később elsajátítani dolgokat. Anno én is basic-cel kezdtem, és akkoriban mindenki amiatt sírt, hogy de aki így kezdi, az soha nem fog tudni strukturált programokat írni, soha nem fogja elsajátítani a normális típuskezelést. Pedig dehogynem. Az algoritmizálást alapvetően ugyanúgy el lehet sajátítani minden procedurális nyelvben, és alapvetően ez a lényeg. Az más kérdés, hogy aztán később nem árt, ha az ember hozzászokik a statikus típusrendszerben programozáshoz, az OOP-hez, stb, de ezt utólag is lehet.
    Mutasd a teljes hozzászólást!
  • Alapvetően a scriptnyelveknek is megvan a saját helye, ahogy a programnyelveknek is. Scriptnyelvek alatt értsd dinamikus típuskezelésű, nem előre fordított nyelvek. Az előbbieket eredetileg is arra találták ki, hogy gyorsan lehessen valamit összeütni. Eredetileg ezek leginkább a rendszergazdák életét könnyítették meg, de kísérletezgetésre, prototípusok gyártására is kiválóak. A másik oldalon a programnyelveknél a statikus típusosság jóval több tervezést, előre gondolkodást igényel. A dolog előnye viszont az, hogy egy rakás hibát ki tudsz így védeni, másrészt a dolog sokkal inkább karbantartható lesz. Persze szemetet lehet gyártani programnyelvekkel is, és scriptnyelvekkel is lehet szép, átlátható kódot produkálni, de ehhez mindkét oldalon meg kell erőszakolni a nyelvek mögötti filozófiát. Pl. simán írhatok C#-ban olyan programot amiben csak dinamikus változók vannak, vagy minden változó Object, csak ez kb. kimeríti a mit csinálnék ha hülye lennék fogalmát.
    Mutasd a teljes hozzászólást!
  • Én amellett, hogy nem tudom eldönteni, hogy mi lenne a legjobb első nyelv, nem szeretem ezt a fajta hozzáállást, hogy "ha ezzel kezdi, akkor nem fogja ezt vagy azt...", mert ezek a dolgok nem így működnek. Abból, hogy Phytonban sok mindent meg lehet csinálni, nem következik, hogy aki azzal kezdi, az nem fog más nyelvet megtanulni, sőt az sem, hogy nem fog típusos nyelveket megismerni később. Ha mégis így történik, az nem a nyelv hibája, hanem az illetőé, mert szűk látókörű.

    Anno mikor egyetemista voltam, az én egyik tanáromnak a szövege az volt, hogy azért kezdünk Pascal-al, mert a C-ben elveszik a lényeg a pointerek és a nyelvspecifikus megoldások miatt, és így nem tanuljuk meg jól az algoritmizálást. Ez is hasonló marhaság, a hallgató nem 6 éves gyerek, akinek nem mindegy hogyan tanítják meg az olvasást, mert rossz módszertannal bajok lehetnek később az alapokkal. A hallgató nem hülye, megtalálja az utat, ha mégsem, akkor az ilyenfajta igazgatás sem segít.
    Mutasd a teljes hozzászólást!
  • A típusos nyelvek eltűnése esetén inkább az a kérdés, hogy valaha el fog-e tűnni a fordítási idejű validáció, mivel annak egy adott területen való inkarnációja a statikus típusvizsgálat. Elképzelhető és valószínű, hogy az utóbbi mellett számos más aspektus is előtérbe kerül olyan problémáknál, ahol az ember által a programba táplált "intrinsic" információmennyiség egy adott küszöbértéket meghalad. Ha a programozást úgy tekintjük, mint modellekre vonatkozó információ betáplálását egy szoftverbe (egész pontosan egy szoftveren keresztül egy másik modell más reprezentációjának beviteleként), akkor a statikus-dinamikus "hitvita" többé nem hitvita (és nem is az). Egyszerűen arról van szó, hogy bizonyos esetekben a probléma mérete és jellege nem igényli az explicit típusreferenciát, más esetekben pedig a statikus modellvizsgálat - köztük a statikus típusvizsgálat - annyi hozzáadott, fejlesztési idejű segítség egy szoftver részéről, amit úgyis igényelnénk az adott esetben (fejlesztési idő, költség, minőség, stb. miatt), ezért is jöttek létre az ilyen rendszerek.

    Nem mindenki osztja a véleményem, de a mai "modern" programozás valójában visszanyúlik egészen a klasszikus filozófiáig, az abban felvetett paradoxonokig, aporiákig, azok feloldásáig, kezeléséig (pl. Tézeusz hajója). Számos olyan terület van ma már, ahol a matematikai tudás nem hangsúlyosan szükséges, ellentétben az előbb említett területen lévő alapokkal.
    Mutasd a teljes hozzászólást!
  • Utána lehet esetleg valahol nézni, hogy ez az index miből "merít", mi alapján "számol"?

    Nyilván utána lehet nézni. Írni kellene nekik és biztos megmondják, én nem tudok semmit a részletekről.
    Mutasd a teljes hozzászólást!
  • Én gyakorlatvezetőként tartottam első és másodéveseknek programozásból gyakorlatot (C++ és Java nyelven), hadd mondjam el a tapasztalataimat.

    Először is az én egyetememen a programozástanítás az alábbiak szerint történik:
    * 1.-2. hónap : Egy helyileg kifejlesztett, semmire sem jó, cserébe szemléletes scriptnyelv, amin a hallgatók megtanulják az alapvető vezérlőszerkezetek használatát és a programozási tételeket. A tapasztalataink szerint nagyon hatékony.
    * 1. félév : C++ alapjain keresztül tömbök, pointerek, referenciák és egyéb alapdolgok, amik szinte mindenhol előjönnek. (Ezen kívül az egyetem jellege miatt előkerül a Matlab és a Bash is, de ez nem kötődik szigorúan a programozáshoz.)
    * 2. félév : C++ OOP és grafikus programozás. (A grafikát egy SDL-re épülő, oktatásra kifejlesztett grafikus könyvtárral tanítjuk)
    * 3. félév : Adatszerkezetek és algoritmusok C++ alatt. Itt olyan tudás átadása a cél, ami bármilyen programozási nyelven használható
    * 4. félév : Java alapjai. Itt a Java-n keresztül a szálkezelés, GUI, hálózatkezelés és OOP kerül előtérbe.
    Innentől szabadon lehet választani, hogy ki mit akar tanulni. Ez lehet FPGA-programozás, scriptnyelvek (Lua, Python), webprogramozás (Ruby, PHP, JavaScript), C#, Java, akármi.

    Látszik, hogy az első évben nem cél, hogy a hallgatók olyan tudást kapjanak, amivel közvetlenül elhelyezkedhetnek az iparban. Erre a későbbi évek szolgálnak. Az első év célja az, hogy meglegyenek azok a masszív elméleti alapok, amikre a későbbiekben lehet építeni, és amitől nem csak jó szakemberekké válnak, hanem egyszerűen képezik át magukat, ha arra van szükség. (Agilitás.)
    Innentől a bevezetőnyelv kiválasztása során teljesen irreleváns, hogy azzal mennyire lehet elhelyezkedni. Senkinek sem célja, hogy a hallgató az első évben tanultak után el tudjon helyezkedni. A cél az, hogy a diplomával el tudjon helyezkedni, amihez nem véletlenül kell minimum 3.5 év.

    Én személy szerint nem értek egyet azzal, hogy valakit a Python segítségével kell megtanítani programozni. Nagyon hatékony és erős nyelv, olyan, mint egy svájci bicska és éppen ebben rejlik a veszélye. Ha egy, a programozásról semmit sem tudó hallgató megtanulj a Python-t, utána úgy fogja érezni, hogy ő mindent meg tud csinálni. Tud webszervert írni, hálózatot kezelni, dinamikus weblapokat csinálni, grafikázni, 3D-zni, telefonra programozni, stb...
    Ebben igaza is van, csak azt nem látja, hogy a specifikus feladatokra vannak jobb, specifikus nyelvek. Ezeket már nem fogja megtanulni, mert nem érez rá motivációt, ráadásul az első nyelvvel annyit szenvedett (mert annak során sajátította el a programozás alapjait is), hogy a második nyelvhez aztán tényleg óriási motiváció kellene neki.
    Ezen kívül a Python nem fogja a fejébe verni az adattípus jelentését, az öröklődés erejét, meg egy sor olyan fogalmat, amikre egy másik nyelvben szüksége lehet. (Aki csak egy nyelven tud programozni, az azért egy elég szűk látókörő kódfabrikáló. Ha ebben nem értünk egyet, akkor ennek a vitának részemről nincs értelme.)

    Szóval összefoglalva, szerintem a C++ jó kezdőnyelv, a Python nem, ennek pedig semmi köze ahhoz, hogy melyikkel mennyire lehet elhelyezkedni.

    Érdekes, hogy miért állnak át mégis a vezető egyetemek a Python-ra. Az tény, hogy tanítani és elsajátítani könnyebb, de ez nem elég érv. Lehet, hogy úgy látják, hogy teljesen a Python-szerű, dinamikus nyelveké a jövő és az abból hiányzó (vagy inkább nem olyan nyilvánvaló) fogalmak már nem olyan fontosak. Ezen meglepődnék, mert nem hiszem, hogy a típusos nyelvek az elkövetkezendő 10-20 évben eltűnnének.
    (Tudom, hogy ilyen időtávokra bátor dolog jósolni. Ezt most azért merem megtenni, mert vannak ma is olyan programok, amiket évtizedekkel ezelőtt írtak, ebből sejthető, hogy a most megírt programok egy része  működni fog 20 év múlva.)

    A felmérés is lehet torz, mert az átállás olyan szakokon történt meg, ahol nem programozók képzése a cél, hanem mondjuk matematikusoké, fizikusoké vagy egyéb olyan szakembereké, akiknek a programozás csak egy szükséges rossz. Ezek a szakemberek az életben nem fognak C++-ban programozni és nekik bőven elég, ha a Matlab és társai mellett még egy, általános célú nyelvet tudnak.
    Az is lehet, hogy anyaglilag rosszul érinti őket, hogy első években nagyon sokan kihullanak, ezért lejebb eresztették a lécet legalább az első évben. Ezzek a hallgatók nem sokat nyernek, mert aki első évben nem tud átmenni C++-ból, annak ez később sem fog menni.

    Abban viszont biztos vagyok, hogy a piaci kereslet semmiben nem befolyásolja az első év menetét, mert ott a cél az elméleti alapok átadása.
    Mutasd a teljes hozzászólást!
  • Uraim ! Ne csináljunk már mindenből  hitvitát :) 
    A világ másik felén nagyon sok kutató, matematikus, biokémikus, molekuláris biológus ,fizikus stb. ír a saját kutatásaihoz szükséges programokat. Mire elmagyarázná valamelyikük a megoldandó problémát egy programozónak, és az  esetleg meg is érti ( ez azt feltételezi hogy ismeri az adott területet valamilyen szinten) annyi idő alatt meg is tudja oldani pl Pythonban. Ezt onnan tudom hogy pár éve kapcsolatba kerültem a Pythonnal, és elkezdtem én is utánanézni annak, hogy mire használják. Nagyon,nagyon sok dolgot kódoltak már le benne ami a kutatásokhoz jól jöhet. Csak pár példa:Scientific Computing Tools for Python - SciPy.orghttp://www.scientificpython.net/The homogenization of scientific computing, or why Python is steadily eating other languages' lunchNa, ezek után nekem sem jutna eszembe C# ot meg Java-t tanítani egy egyetemen ,amikor utána  a való életben több esélye van a mérnök úrnak/úrhölgynek hogy Pythonnal fog dolgozni. Ez egy  praktikus döntés szerintem.  (Ez természetesen nem vonatkozik egy kifejezetten szoftverfejlesztést oktató egyetemre )

    Üdv
    ZeRo
    Mutasd a teljes hozzászólást!
  • Az a hasszám viszonylag pontos, azt már nem kell szorozgatni. Hogy ki mennyit keres, és mennyit talál végül, néha nem ugyan az. Statisztikából is jobb szeretem, amit én hamisítok, bár elismerem, a többiek is értik a dolgukat. Részemről linkek nélkül is tudom, hogy már évek óta így van, de köszönöm a megerősítést. Még mielőtt neked kellene felírnod, az én érvelésem hibája, hogy nem szeret engem a nyomdafesték. Semmi vész, az internet mindent kibír
    Mutasd a teljes hozzászólást!
  • Hali!

    Náluk a c/c++ torony magasan vezet ...

    Na, éppen ezért lenne érdekes, hogy milyen mintán, milyen "szabályok" alapján hozzák ki, hogy egyik vagy másik nyelv/eszköz milyen pozícióban van.

    Az itpeople "kimutatása" semmit nem ér, ugyanis -- valószínűleg -- az alapján számol, hogy a hirdetők milyen kategóriába sorolják be (saját maguk) a hirdetésüket. Úgy lazán vezethet a c/c++ toronymagasan, hogy ha -- a kategóriára kattintva láthatóan -- az első 30 felsorolt c/c++ állás közül 18-19-nek semmi köze (vagy alig van köze) a c-hez/c++-hoz (csak a hirdetők azt is megadták a kategóriák között).

    Mutasd a teljes hozzászólást!
  • Eléggé szobjektívnek tartom a Mimox indexet. (Sosem  tartottam mérvadónak az ilyen listákat) Most megnéztem az itpeople-t.  Náluk a c/c++ torony magasan vezet a java, sql, php, ruby és a python előtt. Az aktuális álláshirdetéseik szerint.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd