C prognyelv ertelme
2005-03-26T20:34:09+01:00
2005-03-31T17:36:18+02:00
2022-07-27T04:13:55+02:00
  • Valami oka csak van annak ,hogy a PHP a Flash és még sokan mások a C++ -t vették alapul.

    Ja és az lehet ,hogy a pascalt gyorsabban lehet lefordítani, de lassabban lehet begépelni.

    Ivn: Ahogy mondod: Ez a Topic a gumiszobába illene
    Mutasd a teljes hozzászólást!
  • Számomra pl. az a legnagyobb hátránya, hogy az objektumok nem zártak.


    Számomra meg az hogy a CLX nem más mint egy igen méretes bogárgyűjtemény. Máig nem értem hogy sikerült ennyi bugot bezsúfolni egy könyvtárba, különösen a Delphi7-es verziója érdekes jószág. És persze az hogy leállították az egész CLX-es vonalat, így aki hozzám hasonlóan D7/Kylix3/CLX vonalon fejleszt jól mexívja...

    Ps. Mázli hogy anno nem kattantam rá a Kylix C++ vonalára, a Delphi IDE-t még csak-csak életben lehet tartani az újabb linuxok alatt (bár lassan ehhez is fekete kakast kell áldozni), de a K3 C++ IDE jóval keményebb dió.
    Mutasd a teljes hozzászólást!
  • -off-
    Mázlista, nekünk még fél év szintiszta occam, és külön fél év prolog volt:P
    -off-
    Mutasd a teljes hozzászólást!
  • Mégpedig az ami a hátránya is, hogy pascal nyelvű


    Megint egy tartalmas és konstruktív hozzászólást kaphattunk tőled, ó nagy mester...

    De ebből még nem derült ki, hogy mi a hátrány. Legalábbis, aki nem ismeri a mélyen a dolgokat (és ahhoz már nagyon jól kell ismerni a Delphit, hogy ismerd a hibáit)
    Delphiben van hátrány, ezt senki nem vitatja (mint ahogy más nyelveknek is megvannak a maguk hátrányai), csak kérdés hogy kinek, mikor és miért hátrány.
    Számomra pl. az a legnagyobb hátránya, hogy az objektumok nem zártak.
    De azt hogy típuskényszer alá vagyok zárva, és nem tudok jobbra-balra pointerezni, engem nem zavar, mivel nincs is rá szükségem. De mellesleg akár tudnék is pointerekkel játszadozni, ha nagyon muszáj.

    De szerintem inkábba a pascallal kell "szenvedni" és a c++ a pörgősebb nyelv


    Nem tudom hogy neked mi a szenvedés. Én végigjártam a görönyös útat: a Z80-as processzor gépi kód, BASIC, PASCAL, C, majd az OOP (C++, Object Pascal), majd jöttek a 4GL-ek (Delphi, BCB), belekóstoltam, és aktívan használom az API-kat (WinAPI, ShellAPI és tsa) és végezetül, de nem utolsósorban a .NET (C#)

    Egyik se szenvedés. Hozzáállás kérdése az egész. És ahogy LC is említette, mindig a feladat szabja meg, hogy milyen nyelvi környezetben állok hozzá a feladathoz.

    Szerintem C++ Builderrel lehet a leggyorsabban összerakni egy alkalmazást,

    Szerintem meg Delphiben még gyorsabb, hiszen a fordítója, mint ahogy LC is említette nagyságrendekkel gyorsabb.


    De ez megint csak szubjektív vélemény, mert abban a leggyorsabb összerakni egy rendszert, amit jól ismersz.
    Ha te kétszer gyorsabban tervezel/kódolsz/tesztelsz BCB-ben, mint én Delphiben, akkor cseszhetem azt, hogy nekem kétszer gyorsabb a compiler-em.

    Rövid beszólesok: Szeretem a rövid ,tömör megfogalmazást


    Lehet, hogy szereted őket, de ez inkább a gumiszobába illene, nem egy szakmai társalgóban...
    Mutasd a teljes hozzászólást!
  • Tessék aki használja a progikat az tudja is hogy miről van szó .

    De szerintem inkábba a pascallal kell "szenvedni" és a c++ a pörgősebb nyelv. Igaz .Net-tel még nem foglalkoztam.

    Szerintem C++ Builderrel lehet a leggyorsabban összerakni egy alkalmazást, de komplexebb nem ablakos programoknál mint egy játék bizonyára van jobb eszköz.

    Fikázni?: Na de ki kezdte?!...

    A Delphinek amúgy van előnye. Mégpedig az ami a hátránya is, hogy pascal nyelvű. Akinek ez kell, használja!

    Rövid beszólesok: Szeretem a rövid ,tömör megfogalmazást
    Mutasd a teljes hozzászólást!
  • Valahogy ez lehet a szemlelet az SZTE-n. Egy felev Pascal + C, egy felev assembly, egy felev Java, egy felev C++ a felallas /a .NET meg csak a specialkollegiumokon hodit/. Ez mellett meg van egy felev Smalltalk + Haskell + Prolog + Occam. Az opcionaliskent megemlitett nyelvekbol egyet sem okitanak.
    Mutasd a teljes hozzászólást!
  • Ezzel együtt szvsz ha valaki ma felsőoktatásban programfejlesztést tanul annak minimum a C++-t, a C#-ot vagy a javát és legalább alapszinten az assemblyt illik ismernie. A Delphi, Visual basic, Php, Python, Perl, stb. már opcionális, de a fentiek nélkül én legalábbis senkinek nem adnék ilyen jellegű diplomát.
    Mutasd a teljes hozzászólást!
  • OFF

    Én mindkét nyelven leprogramoztam már pár tízezer sort, hidd el nekem hogy az hogy valamire milyen nyelvet célszerű használni alapvetően a feladattól függ. Van amire a C++ jó, van amire az Object Pascal. A C++ olyan feladatokra az igazi ahol a C++ erősségeit (többszörös öröklés, template, operator overloading, stb) ki tudot használni. Ezek pedig leginkább a nagy, általános célú rendszerek. Ezeknek egyik jellemzője hogy vagy minimális a user interakció (Pl. webszerver) vagy pedig le van választva egy külön rétegbe, vagy teljesen egyéni user interface van (Pl. játékprogram). Azaz ahol C++-t használsz, ott általában a RAD-os képességekre nem nagyon van szükség, inkább az IDE és a fordító minősége a fontos - ez pedig inkább Visual C++ mintsem BCB6.

    Ha nem ez a cél, hanem mondjuk egy ügyviteli program akkor célszerűbb a Delphi, C#, Java vagy Visual basic nyelvet választani. A C# és a Java azért jó mert elég kellemes a szintaxis (főleg a C#) és mivel virtuális gépen futnak elég jól hordozhatók különböző procik, sőt esetleg oprendszerek között is. Hátrányuk hogy kell hozzájuk egy elég méretes runtime csomag ami nem feltétlenül van fenn a user gépén. Ezért célszerű lehet az Object Pascal vagy a VB használata is, mivel ezek még tudnak natív kódot is csinálni. Ráadásul a Delphi forrás még hordozható is az oprendszerek közt, lásd Kylix, csak sajnos úgy néz ki hogy a Borland pont ezt a vonalat állította le. Ráadásul mindkét nyelv továbbvihető .NET felé, bár a VB és a VB.NET nagy kettő.

    Ami a lényeg: a feladathoz kell eszközt választani és nem mindent ugyanazzal próbálni megoldani. Ráadásul a BCB pont olyan mint a kacsa: repül mint a sólyom, úszik mint a hal és fut mint a gepárd. Azaz legalábbis szvsz C++ fejlesztőkörnyezetnek nem a legjobb (maga az IDE), RAD-nak meg felesleges a C++-szal szenvedni ha ott az Object Pascal, különösen annak fényében hogy ez utóbbi továbbvihető .NET felé, és hogy a Delphi egy nagyságrenddel gyorsabban fordít mint az általam ismert C++ fordítók (MSVC6, BCB, gcc), valamint hogy a VCL/CLX eleve Object Pascal-ban készült, így ha Pl. egy saját komponenst csinálsz és valami zűr van, akkor jó eséllyel debuggolhatsz vegyesen Object Pascal és C++ kódot.

    Azaz ha ügyviteli szofot akarsz csinálni akkor szvsz jobb választás - bár ha ma kezdenék ilyenbe akkor nagy valószínűséggel inkább a C#-ot választanám.

    ON
    Mutasd a teljes hozzászólást!
  • "a programozó azt hiszi, a tervező csak cseszi az időt, a tervező pedig hogy a tervéből már egy ló is le tudná kódolni a rendszert. "

    En inkabb olyanokkal talakozom, amikor a "programozo" (aki raadasul hirdeti is magarol, hogy o bizony nem tud tervezni, es hogy o inkabb koder) ugy gondol a tervezore, hogy ez nem tud tervezni, meg koze sincs hozza.

    A masik, mikor a tervezo elmeletben tudja, de a gyakorlati reszerol meg halvany fingja sincs.

    Egyik se jo.
    Valamennyi ralatasa mind a kettonek kell lennie a masik teruletre.

    Igazabol egyet nem kepesek felfogni, - mind a 2 oldal -, amit mar nagyon sok okos meg mondott:
    "Keep it simple! Stupid"

    Na jo ejt, holnap folyt. kov.
    Mutasd a teljes hozzászólást!
  • De a szakma nem ilyen koherens, hogy ezt így ki lehessen jelenteni. Persze, hogy fontos a gyakorlat elmélettel és fordítva. Ebből nem következik azonban szerintem, hogy ne lehetne iszonyatos eltérés az arányokban.

    Más példánát citálva: soha nem kedveltem, amikor arról panaszkodnak x cégnél, hogy ők bezzeg szét dolgozzák magukat miközben a főnökök csak láblógatnak vagy forditva. Hol látna bele egy cég stratégia döntéseibe egy raktáros, vagy a pénzügyi osztály vezetője az árúelhelyezés fizikai problémáiba?

    Az alá-fölé rendeltségi viszonyt itt a _folymatba_ átültetve: a programozó azt hiszi, a tervező csak cseszi az időt, a tervező pedig hogy a tervéből már egy ló is le tudná kódolni a rendszert.

    Szal alapvetően egyetértek, de ezt nem tartom feltétlen hibának.
    Mutasd a teljes hozzászólást!
  • "Egy tanfolyam pedig csupán statikus megoldást ad problémákra."
    Ezzel abszolut egyet ertek. De! A gyakorlat is van olyan fontos mint az elmelet. Es ha az egyik a masik rovasara megy, vagy valaki el van szallva valamelyik iranyban magatol az is van olyan rossz.
    Pl:
    - fejbol vagom az a linearis algebrat, vagy x hardcore matek reszt, es a BME-n vegeztem, mit nekem te kis koder...
    - vagy a hu de uber koder vagyok, es a mindent lekodolok meg morzezve is.

    Kell szerintem az embernek egy egeszseges (ahogy talan te mondtad) arany erzese. Ha tudom hogy nem vagyok jo fizikailag, valoszinu nem indulok neki a La Manche-nak. Illetve nagypofaval nekivaghatok, de csunya bukas lesz. Ja meg valami: mindenkitol van jobb. (legalabbis bizti van olyan terulet, amibe bele se tud szagolni)
    Mutasd a teljes hozzászólást!

  • A butaság az, amit te teszel. Nem volt még egyetlen értelmes, konstruktív hozzászólásod, viszont azt már mindannyian tudjuk, hogy a Delphit imádod fikázni. Próbáld meg észérvekkel alátámasztani is a mondandóvalódat, de 1 soros mondatokat, melynek a tartalmi információja nulla, az nem nyerő egy szakmai fórumon.
    Mutasd a teljes hozzászólást!
  • Hú de sok butaságot olvastam itt.
    Egy szó mint száz:

    Próbáljátok ki a C++ Builder 6 -ot és higgyétek el lecserélitek a Delphit!
    Miért?: Mert ugyanaz csak c++ nyelven.

    Ezt a Topicot meg zárjátok le mert már a címe is butaság.
    Mutasd a teljes hozzászólást!
  • 'Hogy a sql mikor hal meg az meg megint egy mas kerdes, de szerintem nem csak elmeleti. '


    Amúg az is elméleti:) De értem felvetésed, de nem is állitottam, hogy kizárólag rossz lekérdezés akaszthatja ki az SQL-t. Overheadeztem elég táblát mySQL-ben kiskoromban:)

    'hogy egy jo alapot adjon, utana meg szinte soha nem hasznalja az ember.'


    :) Azért valld be, rosszul esne, ha az adatbáziskezelő nem értelmezné helyesen a parancsaidat, ha a fordító vacak kódot fordítana vagy a .NET minden órában megpusztula...

    'Kicsit jobban kell adatbázis tervezni'


    Erről van szó. Nem kéne azt gondolnod, hogy a formális módszer ettől olyan messzire esik. Az intelligensebb tervezést támogató eszközök is erre épülnek. Egy tanfolyam pedig csupán statikus megoldást ad problémákra.

    Az pedig igencsak meglepne, ha komoly rendszereknél nem lenne formális leirás és ellenőrzés a tesztüzem mellett.


    Nah én most megyek Jóbarátokat nézni:)
    Mutasd a teljes hozzászólást!
  • Meg annyit akartam hozzafuzni, csak mar nem tudtam szerkeszteni, hogy

    "A gond ott van, ha bár van rá automata, de nem adható meg egyértelmúen a megoldás. "
    Time-out az eletben.
    Mutasd a teljes hozzászólást!
  • NP: ja ja ja valami ilyesmi volt.
    Mondom az eletbe nem kellett meg ilyen szinten elmeletben gondolkoznom.

    Hogy a sql mikor hal meg az meg megint egy mas kerdes, de szerintem nem csak elmeleti. Van azert meg ott nagyon sok
    befolyasolo tenyezo, amit szinten csak gyakorlattal egyutt tanulod meg.

    Remelem ez most nem vita, mert ugyis tudjuk hogy persze hogy kell az elmelet, hogy egy jo alapot adjon, utana meg szinte soha nem hasznalja az ember.

    "Hasonlóan, gond akkor jön be a te életedbe, ha egy lekérdezésed exponenciális idejű: 100 teszrekordon fasza, de üzleti környezetben 100000 rekordon meghal"
    Meg akkor inkabb egy kicsit jobban kene az adatbazist megtervezni. Netan egy egy napos SQL tuning tanfolyam, stb. De nem hiszem, hogy pl egy Intershopnal, ami kb vagy 100 tablabol all, vagy egy Siebel-nel, ami all kb 2000 tablabol ilyen elmeleti kerdesek jottek elo. Mar csak abbol kiindulva, hogy elvilag nalunk jobb a kepzes, mint mondjuk Nemetorszagban.
    Mutasd a teljes hozzászólást!
  • A világ nem NASA-ra és kis/közepes céges fejlesztésekre oszlik. Tehát, ha mondjuk meguntad a (bocs a pure példáért) pgSQL + php párost, akkor messze nem az űrkutatás a következő lépés.

    Egy ideig valóban egyszerűbb 'utcában' és 'városban' gondolkodni. De egy formális bizonyitást igy levezetni? Hát nem egyszerűbb a-t, b-t irni? És kihasználni a már meglevő tételeket? Tudom, sokan nem szeretik - no, ez a képzés venné többek között (elvileg:/) ezt a terhet a vállukról.

    NP: nem egészen. Irtál Turing gépet, megpróbálom innen megvilágitani, egészen pontosan automatától.

    Örülünk egy problémának, ha polinom időben megoldható determinisztikus (egyértelmű) automatával, mert az fain futási idő. A gond ott van, ha bár van rá automata, de nem adható meg egyértelmúen a megoldás. Tehát: létezik folyamat az automatában, ami nekünk jó, de ezt előre nem tudjuk megmondnai. Klasszikus példa az utazóügynök (TSP). Jó lenne a legrövidebb úton mennie, de úgy tünik, ezt egyelőre nem tudjuk neki előre megmondani.

    Nos, ilyesmi a NP. Hasonlóan, gond akkor jön be a te életedbe, ha egy lekérdezésed exponenciális idejű: 100 teszrekordon fasza, de üzleti környezetben 100000 rekordon meghal.

    Ezeket a problémákat formálisan kell kezelni és megoldani. Ez megint egy más tudományág, engem se vont speciel olyan nagyon:)
    Mutasd a teljes hozzászólást!
  • "Ehhez matematikai (halmaz, relációk stb.), számitástudományi (ne fussunk pl. NP-teljes problémába lekéréskor), és IT (melyik SQL megoldás a legjobb?) tudás szükséges. A fő feladata e háromból szerintem az első kettő, minden bizonnyal van nála profibb, tapasztaltabb ember aki lekódolja és az SQL motorhoz optimalizálja. Lehet, ez egy naiv cél sokszor, de a képzésünk célja ilyesmi. "

    Ez mind szep es jo. Lenne, ha a gyakorlatban igy mukodne.
    Nem tudom, en valahogy sokkal logikusabbnak tartom mar csak megfogalmazni is, hogy
    "azokat az varosokat, melyek....."
    nem pedig
    "azon elemek halmaza, ahol ez es ez teljesul"

    Egy valos problemaban nekem inkabb a hatarido ami erdekes, mint hogy most azon tokoljek, hogy is mondtad?
    "ne fussunk pl. NP-teljes problémába lekéréskor"
    Most ide a bokot, hogy halvany f.om mi az NP teljes problema. De valami ugy remlik, mintha nem lenne megoldasa?
    Vagyis a gyakorlatban: ha az adott DB Null-t ad vissza. (Valhogy ez szamomra tisztabb, mint a te altalad felvazolt megfogalmazas) Egyelore nem a NASA-nal vagyunk, hanem tenyleg csak egyszeruen legozunk.

    Viszont a Jackson kepzessel egyetertek.
    (Es megis azt mondom hogy jo a goto :P )
    Mutasd a teljes hozzászólást!
  • Halmazelmélet, relációs algebra, SQL...

    Erről próbálom meggyőzni a népet, hogy az ilyen felhasználási területre való egy programtervező matematikus. Van egy bazi nagy adathalmaz, és nem nekiül a város, utca, név, kontó mezőket elemezni, hanem formalizálja és a megfelelő relációs vagy halmazműveletekkel megoldja.

    Ehhez matematikai (halmaz, relációk stb.), számitástudományi (ne fussunk pl. NP-teljes problémába lekéréskor), és IT (melyik SQL megoldás a legjobb?) tudás szükséges. A fő feladata e háromból szerintem az első kettő, minden bizonnyal van nála profibb, tapasztaltabb ember aki
    lekódolja
    és az SQL motorhoz optimalizálja. Lehet, ez egy naiv cél sokszor, de a képzésünk célja ilyesmi.
    Mutasd a teljes hozzászólást!
  • gejza:

    Ezzel is egyetertek, es hogy hasznos a szeles latokor. Igazabol amit kifogasolok, hogy miert tartanak nagyobbra egy prog-mat-ost egy normalis felkeszult programozotol? Tudjuk mindenhol vannak peldak, ellenpeldak. A hetkoznapi programozoi munkaban az esetek nagy reszeben SQL tekergetes van. Ehhez minek az egyetemi matek?



    En ezt hirtelen ket dologra tudnam visszavezetni:

    1. nagyon kevesen vannak progmatosok, "jolfelkeszult programozokkal" szemben (elmult 30 evben kb 2000 programozo matematikus, ebbol kb 600-800 programtervezo matematikus vegzett ELTE-n... a szegedi + debreceni egyetemrol nincs adatom, de ha a felvettek alapjan tekitnjuk, akkor kb ennek fele a masik ketton)

    2. erre ugyan nem vennek merget, de en ugy latom, hogy hallgato tarsaim akik ugy gondoljak, hogy el szeretnek vegezni az egyetemet, es dolgozni is szeretnenek a szakmaban meglehetosen felkeszultek

    Azt hiszem meg lenne par dolog itt, de hirtelen ennyit tudtam osszeszedni...


    Hat nem tudom en valahogy az egeszet inkabb informatikanak es nem matematikanak erzem.


    En szinte minden egyes vizsgaidoszak utan gyakorlatilag (kis tulzassal) szemleletbeli forradalmat erzek - amelyet foleg a algoritmusokhoz kapcsolhato, szamitastudomany, matematika stb. jellegu targyak valtanak ki. De ez persze rendkivul szubjektiv.


    boj:

    Másrészt az SQL halmazelmélet, tehát bonyolultabb lekérdezések megirása formális módszerekkel könnyebbé válik. És, mint irtam, nem a kis fejlesztésekhez van szükség ilyen képzésre.



    Ezt talan azzal egeszitenem ki, hogy: es relacios algebra. Ez viccesen fog hangazni, de anno elso gepi Adatbazis zh-ra nagy segitseg volt nekem, hogy relacios algebraval elotte leirtam amit majd "leforditottam" sqlre... persze ez csak egy pelda volt, az SQL kifejezoereje nagyobb mint a relacios algebraje (ha emlekeim nem csalnak).
    Mutasd a teljes hozzászólást!
  • Igen megertem... talan egyszer meg is tesszuk valamilyen formaban, ugy is itt a tavasz
    Mutasd a teljes hozzászólást!
  • Most mar csak egyet lenne jo elerni, hogy a HR-es emberek is felfogjak ezt.
    Mutasd a teljes hozzászólást!
  • Ha marxista módon érvelnénk, most jutottunk volna el tézis-antitézis-szintézis utolsó lépéséhez:)
    Mutasd a teljes hozzászólást!
  • Abszolut egyetertek veled.

    "De lásd be, egyre komolyabb alkalmazásokat kell fejleszteni. Ezekben nem kizárólag a csudaszép kód, hanem az elmélet a fontos." Ez bizony igy van.

    Idezek egy konyvbol:
    Steve McConnell - Code complete

    What is Software Construction?
    -Problem definition
    -Requirements development
    -Construction planning
    -Software architecture, or high-level design
    -Detailed design
    -Coding and debugging
    -Unit testing
    -Integration testing
    -Integration
    -System testing
    -Corrective maintenance

    De mint ahogy a GDF-es topicban is mondta valaki, igazabol mind az elmeleti, mind a gyakorlati tudas egyutt hasznos. Persze legjobb lenne ha mindenkinek mind a 2 lenne, de ez alt. nem igy van. Es mind kettore szukseg van.

    Peace
    Mutasd a teljes hozzászólást!
  • 'A hetkoznapi adatbazispiszkalo projectekben? Persze vannak ilyen teruletek is.'


    Túltermelés van, valóban. De lásd be, egyre komolyabb alkalmazásokat kell fejleszteni. Ezekben nem kizárólag a csudaszép kód, hanem az elmélet a fontos. Könyvvizsgáló rendszertől a magszimulációig. Kis rész, de számszerűen nagy - itt lenne ránk (is) szükség.

    El tudod képzelni, milyen nehéz egy komplex matematikai vagy közgazdaságtani problémát modellezni úgy, hogy azt már egy kóder érteni tudja? Én igen, és félek is tőle:)

    'A hetkoznapi programozoi munkaban az esetek nagy reszeben SQL tekergetes van. Ehhez minek az egyetemi matek?'


    Nem feltétlen kell. De egyrészt minden problémát csak minimum egy szintel feljebbről lehet megoldani (by Einstein), másrészt nem egyszerű SQL utasitások megirásáról van szó. Másrészt az SQL halmazelmélet, tehát bonyolultabb lekérdezések megirása formális módszerekkel könnyebbé válik. És, mint irtam, nem a kis fejlesztésekhez van szükség ilyen képzésre.

    'Itt Turing geppel kellett dolgozni, vagy netan differencial egyenletekkel? (Csak vicc)'


    Numerikus matematikával:)
    Mutasd a teljes hozzászólást!
  • Nem ellene vagyok.

    "A példa is arról szólt, hogy a programtervező-matematikus focizza le a témát a matematikussal, majd passzolja át a kódernek."
    A hetkoznapi adatbazispiszkalo projectekben? Persze vannak ilyen teruletek is.

    "De, az eszközöket a kezedbe adják. Grafika tárgyak - akár szakirányban is - és a szükséges számitástudományi, IT és matematikai alapok."
    Ezzel is egyetertek, es hogy hasznos a szeles latokor. Igazabol amit kifogasolok, hogy miert tartanak nagyobbra egy prog-mat-ost egy normalis felkeszult programozotol? Tudjuk mindenhol vannak peldak, ellenpeldak. A hetkoznapi programozoi munkaban az esetek nagy reszeben SQL tekergetes van. Ehhez minek az egyetemi matek?

    "Egyrészt azt a gondolkodást, amit kicsiszolt: mindennap."
    Hat nem tudom en valahogy az egeszet inkabb informatikanak es nem matematikanak erzem.

    Ez itt nem kotozkodes:
    "biztositónál vagy egy cég költségvetési részlegének vittem projektet," Itt Turing geppel kellett dolgozni, vagy netan differencial egyenletekkel? (Csak vicc)
    Mutasd a teljes hozzászólást!
  • 'Viszont a programozas meg szinten nem csak matematika, vagy csak kodolas.'


    Persze, hogy nem. A példa is arról szólt, hogy a programtervező-matematikus focizza le a témát a matematikussal, majd passzolja át a kódernek.

    'De ezt valoszinu a prog-mat szakon sem tanitjak.'


    Mármint mit?
    Jah, közben bekerült:)

    De, az eszközöket a kezedbe adják. Grafika tárgyak - akár szakirányban is - és a szükséges számitástudományi, IT és matematikai alapok.

    'Te mikor alkalmaztad utoljara az egyetemi mateket?'


    Egyrészt azt a gondolkodást, amit kicsiszolt: mindennap. Másrészt a matematikus képzés konkrét előnye az volt, amikor biztositónál vagy egy cég költségvetési részlegének vittem projektet, könnyen szótértettünk egymással.
    Mutasd a teljes hozzászólást!
  • "a szak célja elvileg olyan szakemberek képzése, akik a programozásban és mellett tudják alkalmazni matematikai ismereteiket. "
    Te mikor alkalmaztad utoljara az egyetemi mateket?
    En amit az eddigi tobb mint 10 eveben max alt.iskolai,kozepiskolai matekkal talalkoztam. Persze nem is vagyok fejleszto az ATI-nal.

    Bocs amugy a sok uzenetert.
    Mutasd a teljes hozzászólást!
  • "hogyan modellezd le a saját projektedet hatékonyan"

    De ezt valoszinu a prog-mat szakon sem tanitjak.
    Mutasd a teljes hozzászólást!
  • "El tudod képzelni, hogy egy mezei kóder szót értsen egy különféle tételeket és bizonyitásokat az orra alá toló matematikussal?"
    Nem. Ezt nem is vitattam.

    Viszont a programozas meg szinten nem csak matematika, vagy csak kodolas.
    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