A fiam 15 éves és kevés számítógépes alappal, de annál nagyobb lelkesedéssel szeretne saját programokat, játékokat fejleszteni. Készített már kisebb animációkat, sprite-okat, saját zenéket, képeket, de szeretne a játékprogram készítésbe belevágni. Kiválóan olvas és beszél angolul, az angol nyelvű tartalom jobb lenne mint a magyar.
Kérdéseim:
- kell-e bármilyen megelőző alapismeret mielőtt elkezd egy nyelvet tanulni?
- milyen nyelvet lenne érdemes tanulnia?
- milyen tananyagot, tematikát találunk ehhez és hol?
Ha lehet olyan anyagot ajánljatok amivel önállóan is tud tanulni, gyakorolni. Ez lehet könyv, webkurzus, youtube tartalom, stb. Olyat szeretnék ami egy komplex összeállítás, nem csak innen-onna összeollózott DIY dolog. Ha fizetős, az sem baj. Én szívesen segítek neki, de mivel jómagam üzemeltetés területen mozgolódok, a programozás nálam kimerül a scriptírásban, kódolvasásban. A játékprogramokat maximum csak kikapcsolódásra használom. Szeretnék ennél jobb alapot adni neki a tanuláshoz. Jöhetnek az ötletek és a gyakorlati tapasztalatok. Hasonló cipőben előrébb járó szülők, szaktársak előnyben. :) Köszönöm.
Hozzászólások
Könyvben ezt a kezdő és akár érdeklődő középiskolás számára is emészthető szintet képviselték a "Tanuljuk meg 24 óra alatt..." sorozat tagjai.
Amennyire láttam, egyes könyvesboltokban már a "Számítástechnika" feliratú polc is megszűnt, de talán itt-ott még akadnak példányok.
Ha a srác megfelelő szinten tud angolul, akkor persze sokkal könnyebb a dolog, de ebben az esetben is ezt a sorozatot érdemes megcélozni.
Science for fun...
Megnézem, köszönöm.
Semmi egyebet nem tudok elmondani, kérem kapcsolja ki!
Ez de magas labda! De nem ütöm le! :D
trey @ gépház
Esküszöm nem értem...
Megdöbbentél, hogy járok könyvesboltba?
Vagy ahova te jársz, ott van még ilyen polc? (Én általában Libri boltokba nézek be.)
Szóval vagy leütöd azt a labdát, vagy hülyén halok meg.
Science for fun...
Bizonyára arra gondol, hogy a polcokra könyvek is kellenek, azokat meg valakinek meg kellene írnia (vagy lefordítania) :)
Francokat. Az osszes szakkonyvet befoliazta a duro dora kisbetus konyvegeto szakosztaly, mert szerepelt benne, hogy modem, no, karrier, es busy. :-)
Egyébként most, hogy mondod, eszembe jutott, hogy a múltkor a Libriben tényleg láttam egy lefóliázott "Lineáris algebra" című könyvet... ;-)
Science for fun...
Biztos félreolvasták, Liberális algebra.
Tele van olyannal, hogy homomorfizmus.
Te akartad .... :)
Mert kellett a hely az LMBTQ+ könyveknek!
trey @ gépház
Bizonyára ott vannak az infós könyvek is, csak Dúró Dóra nem értette, hogy mik azok, ezért lefóliáztatta az összeset!
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox
Ááá! Rossz helyen kereste!!!
trey @ gépház
Biztos már csak ők járnak könyvesboltba, vagy lassan már ők se :D
Én 20 éve könyvtárbajáró voltam, amíg be nem robbant otthon is a net, valamint az egyetemi könyvtár se volt túl ügyfélbarát, úgyhogy ők is gondoskodtak az átszokásról. Körmölni kellett a hülye igénylőlapokat, ha előtte épp hozzá tudtam férni a terminálhoz (és még működött is), amin rákereshettem a könyvre.
Értem.
Tehát neked a középiskolás gyerekeknek szóló számítástechnikai irodalomról a homoszexualitás jutott eszedbe mint "magas labda".
Nézd Gábor, ahogy én tapasztaltam, a HUP alapvetően egy befogadó közeg.
Ideje lenne felvállalni a másságodat!
Science for fun...
#include <PopCorn>
Én a C++/Qt vonalat ajánlanám. Eléggé stabil és performant nyelv, amivel rengeteget lehet hibázni. Hibák nélkül viszont nem érti meg az alapokat és egyebeket.
A Qt-nak nagyon jó dokumentációja van, további vannak benne játék alapok, amikkel közel lehet kerülni a nagy játékmotorok koncepcióihoz. (Ha ilyen 3D FPS-ben is gondlkodoik).
Pl egy sima "ágyús" játék, szájbarágósan:
http://techdoc.kvindesland.no/linux/qt2/tutorial.html
Köszönöm, valami ilyesmire gondoltam kezdésnek. Úgy látom a kódot sorról sorra magyarázza hogy mit miért, ez szimpatikus. A Qt mellett a C++-hoz is van ilyen szinten használható doksi? Illetve miért C++, C vagy C# az miben más? Azokat érdemes tanulni?
Semmi egyebet nem tudok elmondani, kérem kapcsolja ki!
C++-hoz eszméletlen mennyiségű könyv, doksi, videó van, mint ahogyan a Qt-nak is nagy a háttéridodalma. A C-t elsőnek nem ajánlanám tanulásra, mert hiányzik belőle az objektum orientáltság, amit később nehezebb hozzávenni. A C# MS, ami eléggé behatárolja a környezetet és a használhatóságot. Ha C++/Qt-nál marad a gyerek, akkor egyszerre tud Linux, Windows, WebAssembly, Android, iOS -re fejleszteni.
A többit meg személyesen, írj vissza!
Tanítottál már középiskolásokat programozásra? Az OOP elvektől leseggelnek. A C++ mint első nyelv... hát az halálos.
Én tanítottam, 7 évet. Nagyon jól lehet kezdeni OOP-vel, nincs benne nehezen érthető komplexitás.
https://iotguru.cloud
+1
A plázapicsák lehet leseggelnek az OOP-től, de ha helyesen értelmezem, most nem ez a célcsoport.
Tanítottam már és semmi különleges nincs az OOP-ben. Sőt, inkább az a probléma, amikor valaki nekikezd C-vel vagy mással, megszokja és utána kell az OOP-re átvinni. Ott akkor nagyon nehezen tágul a horizont!
Ezt aláírom, nekem a mai napig rejtély az oop. Az persze látszik, hogy nem csak egy kype, de ettől meg nekem nem szimpi. Mondjuk megtehetem, nem vagyok fejlsztő (érdekes, Pécsen még C ment 2004-ben, azt szerettem - Budapestre költözve és újrakezdve a BMF-en (ma OE), Pascal-Dephi és következő évben C#
Pécsen még mondta tanár, hoyg nappalisoknak C++ is belefér, nekünk csak C marad, de nem bántam.
http://www.micros~1
Rekurzió: lásd rekurzió.
Az OOP egy modszertan, egy megkozelitese a problemanak, ha ugy tetszik, egy eszkoz.
Nem az szamit, hogy szimpi vagy nem szimpi, hanem, hogy az aktualis problema megoldasa egyszerubb, konnyebb, atlathatobb-e OOP-t hasznalva. Ha sok adattal dolgozol, emberek, targyak, atribbutumok, amelyekre C-ben struct -ot hasznaltal, akkor ott kenyelmesebb lehet objektumokban gondolkodni. Henger terfogat szamitast felesleges OOP-vel bonyolitani.
Épp kérdezni akartam, hogy OOP-ben vannak-e struktúrák, unionok, pointerek, mert ha nincsenek, akkor az nem lehet jó nyelv. :P
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Nekem elég a referencia, meg vagyok buzergálható pointer nélkül is.
A referencia is csak egy kőbunkó egy mezítlábas pointer, csak ügyfélbarátsági okokból mellé raktak egy szmokingos ügyintézőt, hogy a kezdők ne riadjanak meg tőle. :-)
:D Az ugye megvan, hogy ennek semmi köze az OOP-hez :D
Az OOP -ből sajnos kihagyták a pointereket, de állítólag a Clean Code -ban már vannak. :-)
Viszont GOTO (asm jmp) van benne, úgyhogy nem teljesen használhatatlan. :-P
Egyebkent miert lenne ez bonyolitas? A geometriat pont, hogy gyakran szoktak OOP-peldanak hozni. Van egy henger objektumod, annak van egy sugara meg magassaga. Ebbol meg tudja mondani a sajat terfogatat. De lehet olyan hengered, ahol alapterulet van megadva es magassag - ebbol is meg tudja mondani a sajat terfogatat, elrejtve eloled a ket objektum kozti kulonbseget.
Azért írtam pont ezt a példát, mert számomra az OOP/nem OOP döntést az határozza meg, hogy az objektumot várhatóan hány példányban fogom példányosítani.
Ha csak egy példány létezik belőle, akkor semmit nem nyerek, hiszen egyszer úgyis oda kell neki adnom az összes adatot, vagyis vagy sima függvényben számolom ki amit akarok, vagy köré húzok (feleslegesen) egy osztályt, amiben aztán ott van az a függvény, ami a lényeg.
Ha viszont sok példány lesz belőle, például ember adatok, akkor ott átláthatóbb lesz a használat, ha objektumokban gondolkozok, és nem függvényekben, valamint akkor a hibakezelést is bent tudom tartani a példányban, és nem kell kívül trükközni, hogy mit tegyek amikor N ember kezelésekor M darab (egymástól eltérő) hiba lép fel.
Én szeretem az OOP -t, mert lényegre törő kódot lehet vele alkotni, de tény, hogy sok feladat nem igényli az OOP megközelítést.
Mondjuk ha a grep parancsot kellene újraimplementálnom, akkor valószínűleg nem szarakodnék class CGrep aztán class CFile meg class Cline osztályokkal. Lehetni lehet, csak minek?
Szerintem az OOP-ben nem maga az OOP a nehez, hanem olyan peldat talalni, ami eletszeru is, es ertheto is a celkozonsegnek. A class Dog : Animal jellegu peldakon keresztul bemutatva en sem ertenem meg, hogy mire is jo ez. :)
Bennem még mindig vannak kétségek egy-egy OOP megoldással kapcsolatban pro és kontra, ilyen pl a bennfoglalás vs DI.
nemcsak benned... rust pl. mar dobta az oroklodest, es miota java/kotlin -ban elsoranguak lettek a lambdak, ott is igazabol nem sok ertelme van az OOP-nek.
Az egesz OOP ugy hibas, ahogy van. Miert? Mert nagyon sok logika tobb objektumot is igenyel, illetve helyzetfuggo. Igy lesz peldaul a Basket.priceForCheckout(), Basket.priceForPayment(), Basket.priceForXXX(). Ez aztan minden, csak enkapszulalt nem.
Ami a gyakorlatban bevalt, az az adat es kod *teljes* szeparacioja. Van data class, es van kulon-kulon business class-ek. DI persze mindenhol. Kotlin ebben amugy kulon partner, mert ezt a workflow-t 120% tamogatja (a +20% az extension function es a delegation miatt).
Nade ez ugye nem OOP... ha valami, akkor inkabb SOLID.
> Ami a gyakorlatban bevalt, az az adat es kod *teljes* szeparacioja.
Pont ez okozza a problémát. Van egy osztályod ami csak belül használna egy adatmodellt, ekkor:
a) belső osztályt készítesz => na én ezt soha, mert nagyon rondának és zagyvának tartom, pedig ez lenne a probléma megoldása
b) külső osztályt készítesz és belül példányosítasz (!DI)
c) DI
:DDD
Én sörrel, sörösüveggel, pohárral, sörgyárral, kocsmával tanítottam.Volt szállítószalag, sörörekesz, állapotok, egyebek. Teljesen jól vették, hogy a sörösüveg egy objektum, vannak tulajdonságai, a sör szintén egy objektum, vannak tulajdonságai, a sörösüvegbe töltjük a sört, bezárjuk, kinyitjuk, áttöltjük pohárba, szállítjuk, egyebek.
Ha most tanítanék, akkor a reaktív programozással kezdenék.
Szerintem a fő probléma az, hogy aki nem OOP-vel vagy reaktív programozással tanult meg programozni, annak kurva nehéz később az OOP és/vagy a reaktív programozás. És nem tud jó OOP vagy reaktív programot írni.
https://iotguru.cloud
reaktiv mar reg elavult az async/await es a java-fele project loom ota.
Elavult... :D
https://iotguru.cloud
igen, elavult.
ott van pl. youtube-on komplett devoxx konferencia: https://www.youtube.com/@DevoxxForever
erdemes raszanni azt az 1-2 napot es atnyalazni evente 1x a legujabb dolgokat, nagyon szemnyitogato.
Én speciel anno DOS-os ANSI C-t tanultam első nyelvnek, imádtam, szerintem logikus és könnyen tanulható, persze csak ha jó a tanár és lehet tőle kérdezni, ha elakadsz.
Utána fősulin pascal-al próbálkoztak, na nekem az ért fel egy fejlövéssel: nekem C után macerás volt de már csa arra emlékszem, hogy egy csomó C-ben megszokott dolgot egyszerűen hiányzik belőle. Később a delphi már tetszett, de a pascal mély nyomot hagyott bennem :D
A Linux, Windows, WebAssembly, Android, iOS nem elég? Ráadásul mindez MIT licenccel…
Szerintem a C/C++ akkor kerul elo, ha az ember alacsonyabb szinten akar programozni, mert fontos a vas, a hardver, vagy a memoria optimalizacio. Mindent is tud, de cserebe jobban is kell erteni azt, hogy hogyan mukodik a gep belulrol.
En Atari BASIC es QBASIC utan kezdtem C++ nyelven irni mindent is, imadtam, de most ha kell valami akkor nem szivatom magam, bash, python nyelveken gyorsabban lehet haladni.
Igazabol oda kell eljutni, hogy az adott feladathoz passzolo nyelvet valasszuk ki, igy nalad a nyelv attol fog fuggeni, hogy milyen feladatot fog latni a fiad szivesen, mi az a kihivas ami megragadja a szivet.
En a novell admin jelszot akartam megtudni a suliban, amihez DOS interrupt fuggvenyt kellett irni, es az QBASIC alatt nem ment. C alatt megvolt a sikerelmeny. Szoval feladat fuggo a nyelv valasztas. :-)
Volt ennek egyszerűbb módja is. :)
Saját login.exe az aktuális könyvtárba -> gond van ->supervisor jön -> login -> a saját login.exe-d kiírja egy .txt-be a jelszót, majd logout -> supervisor azt hiszi, rosszul írta be -> login újra (logout után már az igazi bejelentkezés indul el) -> supervisor nézeget, majd örül, hogy semmi gond...
3.x-es Netware-hez létezett egy knock.exe az mindenféle login hülyeség helyett helyből bement supervisorként :)
Ez is igaz. :)
De ennél egyszerűbb volt (BASIC, Clipper akkoriban volt mindenhol):
Ezt a knock.exe -t nem ismertem. :-)
Oke, de a "baj van" resznel bele kellett volna hazudni a tanar szemebe, akit pedig kedveltem.
A programozás tanulásának legjobb módja, ha az ember kiválaszt egy projektet, nekiáll megvalósítani és elfogadja, hogy elbukik. Az első programokat C64 BASIC nyelven írtam olyan 11 évesen - úgy éreztem a Colony nevű stratégiai játék túl kicsi pályákat használ. Gondoltam, egy 256*256-os pályával bíró saját verziót írok - ami egy C64-esen... hát valamiért nem megvalósítható :D
A mai napig meghatároznak ezek a tapasztalatok, az első mindig annak ellenőrzése, van-e elegendő erőforrás.
Szóval válasszon ki valamit - mondjuk a Tetrist - válasszon nyelvet - mondjuk Javascript vagy Python, álljon neki,gyűjtsön róla videókat/ github kódokat, és ha még 2 hónap múlva is akarja, akkor lehet továbbmenni.
Nézzen szét a https://sulipy.hu oldalon. Nem csak Python van ott. Érdemes a menü alatti ikonokra/logókra is rákattintani!
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox
Én a saját gyerekemet ennél kisebb korban a https://inventwithpython.com könyveivel oktattam, alapvetően az Invent Your Own Computer Games with Python könyvön rágtuk át magunkat. Ez a végén belekap a pygame programkörnyzetbe, mellyel színes-szagos játékokat lehet írni. Viszont ezen az oldalon vannak más könyvek, más nyelvekre alapozottan is.
Ha jól tudom Szegeden a középiskolásokat a JavaScript segítségével oktatják. Mivel ekkor a böngészőben fordítás nélkül megjelenik az eredmény, másrészt lehet kliens és szerveroldalon is használni, talán nem rossz ez az irány sem. Esetleg rá lehet nézni a https://www.youtube.com/watch?v=GFO_txvwK_c kurzusra.
Az első programnyelv kiválasztása rendszerint vallásvitákat eredményez, még egyetemi szinten is. Én úgy gondolom, hogy első nyelvként egy egyszerű nyelvet kellene kiválasztani, melyben gyorsan lehet haladni, hamar van sikerélménye az érintettnek, s megérti az alapokat. Ezek után már bármelyik programnyelv megismerése könnyebben megy.
AL
Én jelenleg többnyire Pythont használok mindenre (is), de jó szívvel nem tudnék ajánlani kezdőnek olyan nyelvet, ahol nincs kötelező változódeklaráció. Igen, könnyebb vele elindulni (én BASIC-kel indultam >40 éve), de nem tartom jó iránynak. Később persze jó lehet, ha az ember ismeri a korlátait. A szigorú típusdeklaráció mellett azért szerettem régen a Pascalt, mert majdnem az volt a helyzet, hogy ha már lefordult, akkor már majdnem jól is csinálta, amit kellett. De sajnos a Pascal már 'kiment a divatból'.
+1
A technikumi tananyag (informatika szak) a html és css-el kezd és aztán python. Ezeket meg az ennél bonyolultabb agyrémeket (c++ facepalm) null kilométeres gyerekkel felejtsd el. Annak is eljön az ideje - ha játékfejlesztés vonalon marad-, de kezdetnek teljesen kontraproduktív. :)
A játék készítésen keresztüli programozás tanulás legjobb kiinduló pontja szerintem a Scratch (ehhez jobban értők arra találták ki). Magyarul nem tudom milyen minőségű anyagok vannak hozzá, de vannak. Az angolt informatikában, meg középiskolásként amúgy is eléggé "kenni" kéne, szóval...
Scratch: kezdésnek jó, illetve algoritmizálni fantasztikus, de az eseménykezelést eléggé elrejti, amitől lesz sikerélmény, de a"miért?"-re nem jön válasz.
A HTML meg CSS az egyáltalán nem programozási nyelv.
A Python meg a C++ más területekre van, de itt jobban leírják: https://www.ionos.com/digitalguide/websites/web-development/python-vs-c/
Android és Gog vagy Unity.
Erre szokták mondani, hogy Python, viszont azt fogja hinni két nap után, hogy már mindent is tud, pedig lófaszt se, mert csak innen-onnan összeollózott DIY dolgokat.
https://iotguru.cloud
Tökmindegy, csak csinálja. A játék programozásnak van egy szép tulajdonsága: igen gyorsan szembesül vele, hogy a kulcs a matematika. És ezen a ponton válik igen élesen kétfelé a mezőny.
(Szülőként és lelkes amatőrként írom) Ha teljesen kezdő, akkor ez a könyv jó lehet az induláshoz: https://moly.hu/konyvek/carol-vorderman-scratch-jatekok-lepesrol-lepesre
Ezzel alap játékokat készíthet scratchben, ami ugyan nem "igazi" programnyelv, de a gondolkodásmódot és a játékok készítésével kapcsolatban felmerülő alap problémákat szerintem jól bemutatja (pl. hogyan programozzam le a gravitációt? hogyan érzékeli a figurám a falat?) 15 évesen, hozzáértő apukával egy hétvége alatt végigcsinálható. Biztosan lesznek kérdései, de azokra akár együtt is megkereshetitek a választ :-)
A "milyen nyelv"re majd biztos jön, hogy "csak a C!", de kezdésnek lehet, hogy egy könnyebb nyelvet érdemes választani, mint pl. a python.
Alap dolgok elsajátításához, 15 évesen, angol tudással ez is jó lehet: https://codecombat.com
Vagy egy (kicsit) komolyabb feladatokhoz: https://www.codingame.com, https://www.codewars.com
Nézd meg ezt: https://bztsrc.gitlab.io/meg4/
Programozható C, BASIC valamint Lua nyelveken, választhatsz. A nehézség itt nem is a nyelv, hanem a környezet (függvénykönyvtár, támogatás, miegymás). Játékfejlesztésnél különösen, ezért is csinátam meg a MEG-4-et, amiben minden benne vagy egy helyen, amire szükség lehet. Az API-ja kényelmes, és mindent biztosít egy helyen, nem kell semmit vadászni hozzá. Jól dokumentált, példák is vannak.
Könyvet nem ajánlanék, mert azok úgyis elavultak, neten érdemes tutorialokat keresgélni inkább.
Ha érdeklik a játékok, szerintem érdemes ezen az úton elindulni, mert érdekesebb egy ugribugri lövöldözőst implementálni, mint valami absztrakt algoritmust, ami a végén talán kiír egy számot.
Godot Engine -- Python-szerű, de C++ szellemiségű scriptnyelve van. Az editor open source, egyetlen exe, nem kell telepíteni, nem kell regisztrálni, és mindent tartalmaz, ami a gyors játékfejlesztéshez kell. C#-ban is lehet programozni. Szuper népszerű, rengeteg angol oktatóanyag van hozzá, akár írott, akár videó formában, amatőr is, professzionális is. Már a 3.x változat is alkalmas volt, hogy teljes értékű játékot lehessen fejleszteni vele, de a 4-es vonal újításai még kényelmesebbé tették. Komplexebb feladatokhoz már kevésbé alkalmas (most még), és főleg nagyobb refaktorálásoknál követhet el önszabotázst, de így legalább a tanuló megismeri a verziókezelő rendszerek előnyeit.
A Godot-t itt kezdeném: https://kidscancode.org/godot_recipes/4.x/
Kicsit nehézsúlyúbb, de szintén jó választás a Unity, ami csak C#. Voltak vele kisebb botrányok (az akkori vezetőség nevetséges és ostoba előfizetési és bevétel-megkaparintási modellt akart a felhasználókra erőltetni, de a népharag elsodorta -- ez esetben gyakorlatilag szó szerint). Ez régi motoros a szakmában, így elképesztő mennyiségű anyag található hozzá.
Mi évek óta elég komplex dolgokat csinálunk Godottal, már a 3.x korszakban is, és nem látom ezeket a korlátokat (tudom, más szemüvegen át nézzük :) ).
A GDScriptet még nem hallottam C++ szellemiségűnek hirdetni, nehogy megijedjenek tőle. :) Sokkal inkább a Python jut eszembe róla (ahogy írod is), beleértve az opcionális típusmegadást - ami viszont a Pythonnal ellentétben tényleg gyorsítja a szkriptek futását.
Az viszont tényleg igaz, hogy a Godot C++ API-ja nagyon könnyen olvasható és szinte 1 az 1-ben megfeleltethető GDScriptnek. Többször csináltuk, hogy GDScriptben megcsináltuk a prototípust, és utána simán átírtuk C++-ra, ahol kellett a sebesség.
Én már desktop app fejlesztést sem kezdenék Qt-val, inkább Godotot választanék - ha tényleg natív app kell, és nem elég pl. egy webes megoldás.
Még azt tenném hozzá, hogy érdemes már a 4.2rc1-et leszedni, 1-2 héten belül itt a végleges release, rengeteg fejlesztéssel (tőlünk is :) ), nem érdemes már 4.1-el nekiindulni: https://godotengine.org/article/release-candidate-godot-4-2-rc-1/
Szerintem elsore ne feltetlenul "nyelvet" tanuljon, hanem olyan eszkozt keressen ami gyorsan ad sikerelmenyt es akar komolyabb dolgokat is csinalhat vele kesobb, pl. a Godot engine tok jo lehet ehhez.
szerk.: Kiegészíteném kicsit!
Adatszerkezetek és algoritmusok. De ezt menet közben fel lehet szedni.
A nyelv teljesen mindegy. Olyat célszerű választani, aminek egyszerű a szintaxisa, nem zavarja össze a sok nyelvi elemmel.
Magyar/külföldi egyetemek kurzusai például. Nagyon sok elérhető online és ingyenesen. Coursera, Edx, stb.
Ha nem ijed meg az angoltól és a Lisp-től, amit fentebb is emlegettek, nekem ez a két oldal nagyon tetszett:
Brave Clojure - become a better programmer
Practical Common Lisp
Racket
Ezt is ajánlotta más is, többféle nyelv is választható:
CodeinGame
Hobbiból elég sokat foglalkozok mindenféle programozási nyelvvel. Elég sok nyelv alap szintaxisát ismerem ill. a hozzá tartozó eszközöket. Személy szerint a Lisp család jött be leginkább. Minimális szintaxis, nincs útban, nincs telerakva mindenféle nyelvi szerkezetekkel és bonyolult kifejezésekkel. Elsőre fura, de könnyen rá lehet érezni.
Én is hasonló cipőben jártam / járok. Nem egyszerű egy tizenévesnek elmagyarázni, hogy informatika != programozás.
Bocsánat, hosszú leszek.
Többfelé szedném a bejárandó utat - nem feltétlenül egymásra épülnek, inkább egymással párhuzamosan kell őket bejárni:
- Sikerélmény. Igen, ez fontos az ifjú padavánoknak. Programnyelv alapvetően mindegy, csak lássa, hogy miket lehet alkotni. Megmutatható, hogy egy jó programozó bármely nyelven képes jó programot alkot. Egy rossz pedig még a legbiztonságosabbnak tartott nyelven írt programot is képes telerakni sechole-lal.
- "Min működik az IT". Ezt is gyakorlati szempontból megközelítve. Lásson processzort, memóriát, hardvert. Igen, akár szétszedve is és bemutatva neki, hogy miért úgy kell a CPU-t beletenni az alaplapba, ahogy. Ez fejleszti a logikai érzékét, gondolkodását. Ez egyfajta "számítógép szerelői" szint.
- Száraz elméleti alapok. Hogy működik a CPU, mire való a memória, miért úgy működik, ahogy. Ez egyfajta "elméleti szgp architektúrák" szint.
- Elektronikai alapok. Esetleg tanuljon meg forrasztani - legalább 2 kábelt vagy egy elektrolitos (elko) kondenzátor, lássa a nehézségeket, a munkabiztonsági kockázatokat (pl: nem hadonászunk forrasztópákával, mindig úgy tesszük le / nyúlunk hozzá, hogy feltételezzük, hogy forró a páka stb.) Ez nettó elektronikai alapismeretek. Beágyazott rendszerek fejlesztéséhez ez kötelező.
- Nyers matek, algebra. Egy 15 éves is simán megérti pl: a komplex számok lényegét, miért van rá szükség.
- Algoritmusok, matematikai logika. Bármennyire is mateknek állítják be, ez csak egy részterülete a matematikának és nem összekeverendő a középsulis matekkel. Legalább az alap algoritmusokkal, azok megvalósításával, előnyeivel és hibáival kerüljön képbe. Ez belekarcolhat picit az egyetemi tananyagba, de fontos, hogy megértse az ifjú padaván: algoritmuselméleti, logikai ismeretek nélkül nem fog tudni jó programot írni. Direkt nem a helyes kifejezést használom, mert az egy perverz részterülete a programtervezésnek (jó program vs. helyes program vs. bizonyíthatóan helyes program). Ez lényegében egyfajta "elméleti programtervező" irány.
- Általános problémamegoldás, józan paraszti ész. Sok-sok problémát kell megoldania (megoldatni vele), amelyekkel fejlesztheti ezen képességeit. Pl: sorba rendezés, prioritások kezelése, optimális megoldás keresése, mindezt persze prezentálni is, hogy miért úgy gondolkodott, ahogy. Egyáltalán nem IT problémákra gondolok. Az így megszerzett tudást és tapasztalatot később felhasználhatja nem csak IT-ben. Ez egyfajta "hibakereső, probléma megoldó" irány.
Olyanokról direkt nem írtam, hogy projektmenedzsment, csoportmunka, agile és egyebek. Nem célom egyből elijeszteni a fiatalokat teljes IT-től. :)
Az IT (beleértve a programozást is) nem csend, béke és nyugalom. Ha csak a játékokat, szórakozást szereti belőle, akkor 20-25 évesen könnyen kiábrándulhat az IT-ból. Csak a pénz miatt meg ne legyen IT-s.
Szerintem.
+1
Nem is kell. Remelhetoleg majd rajon magatol, hogy tovabb kell tanulnia, ha jot akar maganak.
Kezdetnek olyat aminek gyorsan van eredménye., látványos, beszippantja. Ezután a nehéz részeknél is motivált marad.
A sima C-t mondtam volna, de mivel a játékkészítés lesz a fő cél, akkor jobb a C++-ra rámenni mindjárt, az a játékfejlesztés non plus ultrája, akár mennyire is utálják sokan. Könyvből ajánlani nem tudok, amit írtak, az a tanuljunk 24 óra alatt nem rossz, de ha jó az angol nyelvű, akkor bármilyen netes oldal, YouTube tutorial alapján neki lehet menni, esetleg Library Genesis-ről (ehhez a library genesis proxy szavakra kell rákeresőzni) is lehet egy csomót tölteni, teljesen ingyen, rákeres, hogy learn C++, stb.. Letölti, amit tetszik neki, tanulgat belőle, ha valamelyik nem jó, megy rá a következőre. Elég lehetetlen akármit is ajánlani, mivel mindenkinek más könyv vagy leírás lesz hasznos, érthető, nem vagyunk egyformák. Anno én is mindenféle netes oldalról, példakódokból tanulgattam ezeket.
A Godot, Unity lehet több sikerélményt adna neki, de azzal nem progamozni fog megtanulni, hanem kötött lesz ezekhez a frameworkökhöz, engine-ekhez, az velük a baj. Végső esetben viszont bepróbálhatók, hátha lelkesíti, és nem adja fel azonnal, ha száraznak érzi a témát.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Ez nem igaz. A Godottal a GDScript könnyű sikerélménye után természetes módon tud továbblépni C# és C++ felé (mindkét nyelv hivatalosan támogatott a projektben), de ezer más nyelvhez is tud kapcsolódni (Python, Swift, Rust, ... ). Innentől organikusan tud váltani más platformokra. Ha mélyebben érdekelni kezdi, hogy hogy működik az engine maga, a Godot C++ kódja nagyon jól olvasható, jó tanulópálya, mielőtt átmegy más kódbázisokba ahol azon versenyeznek, hogy ki tud több C++20 feature-t használni és ki tud bonyolultabb template-et írni.
Én arra szavaznék, hogy 15 évesen a sikerélmény sokkal-sokkal-sokkal-sokkal... fontosabb, mint hogy proper iszonyú pöpecül tanuljon meg programozni. Találja meg benne az alkotás örömét, ha az megvan, akkor majd kiderül, mikor szembejön valahol, hogy mi értelme van a többi cuccnak mögé, aztán vagy meglátja abban is a szépséget, vagy nem. És bizony simán lehet, hogy kiderül, hogy majd mondjuk a rajzolásban, vagy a hang csinálásban, vagy a történet írásban, vagy a pályatervezésben, vagy a szabálykitalálásban, vagy valamelyik másik aspektusában fogja megtalálni a szépséget. Alapvető personal bias miatti félreértés már egy kicsit az egész topic, hogy hogyan kell megtanulni programozni, olvasd csak el a nyitót, még apu is úgy fogalmaz, hogy a gyerek játékokat akar csinálni. Akkor ahhoz kell neki egy eszköz a kezébe, nem megdobálni C-s pointer aritmetikával.
Flash-t mondanám, de sajnos kinyírtátok.
Steve Jobs haverod nyirta ki. :)
Es HTML5-ot es open source web tech-eket javasolt helyette.
(Amugy sajnos nem vagyok ma mar benne biztos, hogy a Javascript (vanilla) rossz kezdo nyelv lenne :( En se orulok, hogy ez lett a velemenyem, de ez lett. :( )
Ha webre, egyszerű appokra akar rámenni, akkor a JS sem hülyeség. Ha meg egyszerű toolokra, akkor a Python se rossz, nem haszontalan. De a gyerek a topikindítás szerint grafikát, játékokat akar írni, ahhoz ezek szuboptimálisak.
Nekem még a Lua szokott lenni kezdők felé az egyik ajánlásom. Semmi extrát nem tud, de egyszerű, könnyen tanulható nyelv, lehet retró Basic-stílusban, kvázi basic-es szintaxissal is programot írni benne, nem sok szutykot kell feltenni hozzá, futási teljesítménye is elég jó a JIT miatt. Nem nagy szám, nem világmegváltó nyelv, de kezdőnek elég könnyen megugorható, emészthető. Nincs benne túl sok bonyodalom, túl sok opció, túl sok paradigma, amibe bele lehetne zavarodni, vagy túl absztrakt lenne, meg kevésbé bloat, mint egy Python, gyorsabb, mint egy JS, stb.. Nem kell benne kötött mértékű behúzásokkal és kötelező pontosvesszős lezárásokkal szívni, ami egy kezdőnek külön segítség. Persze inkább csak annak szoktam ajánlani, aki nem akar később komolyan programozni, csak bele akar kóstolni egy kis alap programozásba, algoritmusokba, és valami olyan egyszerűt, puritánt akar, mint régen a Commodore/MS/Visual Basic volt. Játékfejlesztésre felejtős erősen, tényleg csak programozási alapokhoz jó, arra a szintre, amit anno alap programozási könyvekből, újságokból gépelgetett be magának az ember.
Ami viszont a C++-nak előnye, hogy univerzális, nem köti meg merre fejlődhetsz. Tényleg abszolút mindenes, akár még kernelt is lehet benne írni, rendszerkomponenseket, GUI-kat, játékokat, Android fejlesztésre is jó, ha valaki nagyon szadomazó, még CGI webre is simán elmegy PHP vagy akármi helyett. Iszonyat sok lib elérhető hozzá. Használható .NET-tel is, ha valaki MS fetisiszta (bár nekik a C# való erre ugyebár). Persze a kritika is jogos a C++ ellenében, hogy minden próbál lenni, mindent támogatni, minden van benne, mint a Fradi levesben, de egyik paradigmában sem a legjobb, középszer, stb.. Meg ugye régi, a nyikhajok szerint mindent Rust-ban kell most már írni, minden másnak a használata illegális, nem memory safe, tiltsuk be.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Ez a mondat tobbfele kerdest is felvet.
"A java halott" Raynes prof szakért programozási kérdésekben, érdemes helyén kezelni.
s/sajnos/szerencsére
Előbb nézd meg mihez tudja kötni amivel amúgy is játszik. Én próbáltam mindent, minimális sikerrel, mert amiből nem lesz pár nap alatt működő open world 3d játék az nem is jó semmire. Ezért magától elkezdte a unity-t (c#). Na, az gyorsabban fejlődik mint a könyv hozzá = a hello world sem fut le. Sikerélmény (hiánya) garantált. Viszont a közben összeszedett scratch, c#, python morzsák egyszer csak összeálltak, logika ugyanaz. Elkezdett Minecraft-ot szkriptelni. Mikor kinőtte, az aktuális kedvenc játék a GTA volt, annak multiplayer változata (fivem) az lua-ban szkriptelhető. Itt volt robbanás, rájött, hogy ugyanaz az alap struktúra, de baromi gyorsan tanulható, így azonnal volt sikerélmény. Ma már VR mod-ot fejleszt hozzá, kontroller vezérléssel (python), 3d menükkel (javascript, CSS, html), az engine maradt lua. 16 éves.
Hogy mennyire nincs ultimate megoldás: a másik 3 némi scratch után abbahagyta, bár értik, hogy bármilyen szakmában előny ha meg tudják fogalmazni a gép számára mit szeretnének.
Kb. mindegy, csak ne Pascal.
Amiatt azt hittem, hogy sose leszek programozo, annyira utaltam.
Én ugyan sose lettem programozó, viszont szerettem. Teljesen logikus nyelv, nem értem, mi vele a bajod.
A mai napig élő nyelv, készülnek benne egészen jó dolgok, csak divat szidni :)
https://wiki.freepascal.org/Projects_using_Free_Pascal
Ma már ritkábban írok PC-re programot, de amikor kell valami, ezt használom, ez áll a leginkább kézre (Lazarus/FPC Linux alatt).
Érthető.
Komoly megfontolandó érvelés. Tőled mondjuk nem is várok mást.
Nincs vele semmi baj. Csak el kell fogadni, hogy Pascalban programot irunk, C-ben pedig szoftvert keszitunk. :-P
Realm of Racket; Picturing Programs stb. (Innen: https://racket-lang.org/books.html )
Ez is lehet egy jó irány, csak örökre "elromlik" az ember és minden mást látva csodálkozni fog, hogy azok miért annyira bénák. :D
(Előbújt belőlem a lisp, dinamikus nyelv imádó.)
Fentebb nem mertem Lisp/Scheme nyelveket ajánlani :-)
Hogy mutassak is valamit: ezt évekkel ezelőtt csináltam. Egy nagyon egyszerű "dobókocka-szimulátor". Nem egy nagy szám, ha csak kipróbálja az ember, másodpercek alatt megunja, de megmutatja, milyen egyszerűen lehet összerakni valami egyszerű, de működő dolgot. Ráadásul nekem az alkotás örömével is szolgált. :D (DrRacket-ben futtatható, `(main n)` parancssal indítható, ahol n az egy egész 1-től 6-ig. Egy billentyű lenyomására új számot dob; ha látszólag nem, akkor ugyanazt a számot adta, mint előtte. :) )
Kezdésnek én Python-t ajánlanám, hozzá a fent említetteken túl a PyGame-et.
Illetve még inkább a Scala-t.
Kezdésnek nagyon jó a ScalaFx könyvtár, pl. Snake játék készítése.
Később pedig a libGDX vagy az Indigo is segítségül hívható.
scala-t, a kotlin koraban, kezdonek ajanlani? lol^2.
Egyszerűbb, könnyebben tanulhatók az alapok.
Szinte minden megtanulható, ami csak előjöhet a programozásnál a procedurális vezérlőszerkezetektől az OOP-n át az FP-ig.
Köztük még ilyeneket is, hogy miként működnek a persistent adat típusok, mire jó a tailcall recoursion, az algebraic data type, ...
Egyébként nem értem ezt a gyerekes hozzáállást, lol ;-)
Hasonlitsd ossze a python-nal, ahol tenylegesen kb. 2-3 ora alatt megtanitanak neked mindent, ami egy alapszintu programhoz kell.
Ertem a scala-t, csak szerintem ahhoz kepest, hogy mennyi eszkozt ad a kezedbe, bonyolult es nehezkes. Anno, meg ugy 10 eve megcsekkoltam, es a kovetkeztetes az, hogy bar elmeletileg tok jo, a gyakorlatban viszont bejatszanak ilyenek, hogy mennyire nehez egy jo dev-et talalni a team-be, es mennyiert. Ebben a 'jatekban' a scala sehol sincs: nehez jo devet talalni, es az is sokat ker, ehhez kepest igazabol nem produktivabb, mint egy kotlin dev.
Amugy ha figyelmesen elolvasod, amit irtal, te is ugyanebbe a hibaba estel. tail recursion, mint feature? egy kezemen megszamolnam, hanyszor hasznaltam egyaltalan recursion-t az iparban, es ott se szamitott semennyit se, hogy ki van-e optimalizalva egy loop-ba vagy se. algebraic data type? marha jol hangzik, iparban kb. senkit se erdekel, interface+class teljesen jo mindenre (+kotlinban van delegation).
Itt bejatszik az is, hogy *egyszeru* kodot kell irni, mert dev koltsegek 80%-a bizony a kod olvasasa, megertese, modositasa; itt pedig az egyszeru kod sokkal sokkal jobb. Sajnos sokan szeretik bonyolultan megirni azt, amit lehet egyszeruen is; tudod, hanyszor optimalizaltam felere/harmadara a mas altal megirt kodot? Azt hiszik sokan, hogy akkor okosak, ha bonyolult kodot tudnak irni. Pedig nem. Az igazi jo dev onnan ismerszik meg, hogy a kodja pelda lehetne barmelyik 'java 101' konyvben, annyira primitiven es egyszeruen oldja meg a feladatot.
Szoval amit akartam mondani, a scala igazabol se kezdonek, se haladonak nem jo valasztas; igazabol nagyon szuk azon projektek kore, ahol jo dontes.
BTW most nem a scala-t akarom bash-elni, ugyanugy vagyok a rust-tal is, amolyan love-hate relationship :), elvileg az is tok jo, csak mikor hasznalni kell, egyszeruen toredek annyira produktiv, mint egy kotlin. hogy napokat kell pepecselni az ownership-pel egy sima linked list -ben, meg hasonlok, nagyon kijonazonito. :/ Mondjuk rust-hoz legalabb dev-et talalni lehet (most meg, eleg uj+hip), scala-nal ez kevesbe jatszik, az se nem uj, se nem hip.
Ne a Python alap tudását hasonlítsuk össze a Scala összes tudásával. Ugyanazt, ami az alapszintű programozáshoz kell, azt ugyanúgy 2-3 óra alatt megtanítanák neked Scala-ban is. Ráadásul most már választható a Python féle indent alapú struktúra definíció is a kapcsos zárójeles helyett.
Pontosan Te esel abba a hibába, hogy amit használsz az a jó, de más nem lehet jó. Sajnos szomorúan tapasztalom én is itt a fórumokban, hogy sokan még a rekurziót sem értik, pedig az elég alap dolog, ráadásul a legtöbb esetben még sokkal érthetőbb is, mert nincs semmi plusz sallang, pl. a ciklus, meg a státuszok kezelése.
OOP világban igen, de az pont nem az egyszerű, amit később hirdetsz. Gondolom az egyszerű alatt sem ugyanazt értjük, lásd pl. rekurzió vs. ciklus + állapotok kezelése.
Scala-ban kb. mindent legalább olyan egyszerűen lehet megírni, mint pl. Kotlin, C++, C#, Java, Dart, Go, ... nyelveken. Ráadásul ugyanolyan paradigmában, mint más nyelven. Ha akarod lehet teljesen procedurális, ha akarod lehet teljesen OOP, ha akarod lehet teljesen FP, ha akarod, akkor keverheted ezeket kedved szerint.
Nem ertunk egyet, de ez a tapasztalataink kulonbozosegebol fakad.
En ket dolgot biztosan tudok, akar egyetertesz, akar nem:
- kotlinnak van a legeslegjobb IDE-je. a jetbrains a sajat nyelvehez nyilvan a legjobb IDEA supportot csinalta, emiatt aztan tenyleg megirja helyetted az osszes boilerplate kodot, es a tobbiben is kivaloan segit.
- minel tobb feature van egy nyelvben, annal nehezebb megtanulni. es mivel minden dev maskepp kozelit ugyanahhoz a problemahoz, nehezkesse valik a teamwork, nehezkes a masik kodjanak megertese, modositasa. a kevesebb tobb: konnyebb megtanulni, kevesebb a variancia a code style-ban, ami mind konnyebbe teszi a developer pozicio feltolteset, mind a team-munkat konnyiti. marpedig ez utobbi ketto lenyegesen fontosabb es nehezebb a gyakorlatban.
Egyetértek, különösen Scalahoz képest, de még Scalahoz is elég jó van.
Scalaban meg nem kell boilerplate kódot írni, generálni, olvasni.
Bizonyos fokig egyetértek, de nem feltétlen nehezebb, hanem tovább tart esetleg mindent megtanulni.
Szerintem abban van a legnagyobb különbség a mostani beszélgetésünkben, hogy nem egy kezdő programozó tanulására helyezed a hangsúlyt, ami itt a fő kérdés. Egy nagy projektben, irányítatlanul, megkötések nélkül használni bármilyen nyelvet, nyilván problémákat okozhat. Hasonlóan ahogy önmagában a formázások is. Mégsem mondjuk, hogy sokkal jobb nyelv a Python, mint ..., mert ott kötött a formázás, máshol meg nem. Más nyelvnél is le lehet kötni egy-egy projekt esetén, így máris elveszti ezt az előnyét. Ha valami sokkal többet tud, az semmiképp sem hátrány, legfeljebb megtiltjuk bizonyos feature-eit, máris nem tud annyit ;-)
Boilerplate kod mindenben van. Gondolj csak a dependency mgmt-re, vagy arra, hogy mit is csinal egy 'project init' (javaban maven archetype/spring initializr); az mind-mind boilerplate.
Boilerplate alapvetoen nem rossz, csak amikor feleslegesen hosszu, es csak copy-pasteli minden dev, na AZ gaz, onnan mar nem boilerplate, hanem cruft. :)
A sok feature egy nyelvben azert gaz, mert nincs ilyen, hogy akkor valamit nem hasznalunk. Pl. meg akarod nezni, mit csinal egy dependency lib belul: tudni kell mindent. Segitseget google-zol a neten: tudni kell mindent. Akar csak jelentkezel egy allashirdetesre, jon a technikai teszt: tudni kell mindent. Sajnos egyszeruen nem tudod kikerulni. A java-ban ezt szeretem, hogy ellenalltak a feature creep-nek, es terveztek, gondolkodtak (ugyanezt imadom a go-ban is, de ott meg tultoltak ezt, meg egy vacak exception sincs, ugyhogy tolhatod keresztul a kodon az osszes hibat is, na koszi).
Java-ban tudtak, hogy egy uj feature minden tovabbi munkat megnehezit. Miert? Kepzeld el, hogy van a nyelvedben mondjuk 100 feature. Amikor valtoztatni akarsz valamit, akkor mind a 100 feature elleneben vegig kell gondolni, hogy jo-e, nem utik-e egymast, illetve modositani kell, ha igen, doksit update-elni, stb... Ha nem 100, hanem 200 feature-od van, akkor nemes egyszeruseggel ez ketszer annyi munka. Tehat a sok feature pont, hogy lelassitja egy nyelv fejlodeset is, illetve tobb hibalehetoseget ad minden valtoztatasnal.
En ezert preferalom az egyszeru megoldasokat. Egyszeruen minden, de minden tekintetben elonyei vannak csak. Gondolj bele, mi az a problema, amit java-ban nem tudsz megoldani? Vagy hany olyan problema van, aminek a megoldasa scala-ban pofonegyszeru, java-ban meg ronda es bonyi? Biztosan van ilyen, de a gyakorlatban olyan ritkan jon elo, hogy a bonyolultabb nyelv hatranyai sokkal nagyobb problema.
Lazán kapcsolódik, mert nem nyelvekről szól, de azért itt hagyom: Features are faults, és Features are faults - Redux.
De, rossz. Minél több van annál rosszabb.
Megállapodás kérdése, review-n nem megy át, ilyen egyszerű.
Ez elég rossz példa, mert a Java-ban is van kb. ugyanannyi feature, csak teljesen átgondolatlanul kerülnek bele, illetve pofozgatják a régi rossz struktúrákat, emiatt jó bonyolult (csinálhatod a régi rossz szerint és az új, már kicsit jobb szerint is) és továbbra is sok a boilerplate emiatt.
Továbbra is azt gondolom, hogy nem az egyszerűeket preferálod, hanem a megszokottakat. Javaslom ezt a videót: The Art of Simplicity - Venkat Subramaniam
Boilerplate alapvetoen szukseges, mert manapsag egy platformnak millio feature-e van, es jo dolog a sane default, de van par dolog, amit jo explicit megmondani, mert a kezdo csak kattint harmat, aztan nem erti, miert ez a "foglalt a 8080-as port" hibauzenet... :) a sane default hozzaallasnak az a hatulutoje, hogy nagyon konnyen atfordul a "black magic" - erzesbe sok dev-nel.
Ez nem ennyire egyszeru. :) ha van egy OSS project, es rendre elutasitjak az amugy tokjo MR-eket, azzal egyreszt elidegenitik a sajat community-juket, masreszt nagy az eselye egy fork-nak, az meg aztan senkinek se lesz jo.
Ezert szokott nagyobb projekteknel committee, ami elore velemenyezi a terveket RFC-szeruen.
Ez is egy velemeny :) A teljes kephez hozzatartozik, hogy a java-t '94-ben talaltak ki, nagyon mas vilagban. Az, hogy azota egy (mindenkori dev standardnak nagyjabol megfelelo) minimum feature-set -et fenntartva mai napig relevansak, az nem semmi. Meg az se, hogy a jvm mai napig rendre a leggyorsabb JIT compiler a vilagon.
venkat-ot ismerem, tobbszor is szemelyesen ultem az eloadasan az antwerpeni kinepolis-ban (devoxx belgium). Nem, nem a megszokott megoldasokat preferalom, ezt nem tudom, honnan vetted. En vagyok az, aki a POJO-knal siman public-ra tette a field-eket es kihagyta a getter/setter-t, mert hulyeseg, csak feleslegesen nehezebben olvashatova teszi a kodot. Tudod, mit osszeszenvedtem azzal, hogy atverjem a kollega dev-ek fejebe, hogy nem, ez igy jo, es a standard java a hulyeseg - nem ment am at. Meg volt meg jopar hasonlo egyszerusitesem, de standard java dev sajnos borzalmasan szokasok rabja, egyszeruen nem latja felulnezetbol a rendszert, nem erti igazan, mit is csinal.
Na mindegy, megyek alkotni.
Nem szükséges, a boilerplate magyarul a felesleges körítést jelenti. Ami nem szükséges, azt miért jó megadni? Csak többet kell gépelni vagy generáltatni és többet is kell olvasni és nehezebb megérteni is. Ha nincs boilerplate az azt jelenti, hogy ugyanazt a működést meg tudod adni tömören. Csak az van ott, ami szükséges, hogy ott legyen, semmi több.
vs
Jobban kellett volna figyelni az előadásaira. Semmivel sem nehezebben olvasható a
mint az
Semmivel sem nehezebben érthető az egyik, mint a másik, miközben nem ugyanaz a funkcionalitása. Ahol van get/set, ott úgy tudod megváltoztatni az objektumodat, hogy ne kelljen a program más részeibe belenyúlni.
Ez is jó példa egyébként a boilerplate-re.
Azért hagyod el, mert felesleges körítés, de Javaban nem hagyhatod el anélkül, hogy ne változna meg a funkcionalitás. Jó volna egy olyan nyelv, ahol nem kell megadni, de mégis ugyanaz marad a funkcionalitás! ;-)
Ez ugyanazt a funkcionalitást nyújtja, mint egy sima class, ahol meg vannak adva a get/set, hashCode, equals, toString metódusok. Így át is tudod írni ezeket később, ha akarod. Viszont ebben nincsenek benne a fenti körítések. Azokat csak akkor kell megadni, ha át akarod írni azokat.
Abból is látszik, hogy nem figyeltél Venkatra eléggé, mert a rövidebb kód az nem (feltétlen) egyszerűbb, ahogy a fenti sem, a get/set-ek elhagyása. Javaban pl. a final megadása egyszerűsít a kódon, miközben egy felesleges boilerplate, annak kellene lennie a defaultnak.
Egyébként a POJO osztályod immutable-re alakítása viszont egyszerűbb lesz.
Ez nem attol fugg, hogy letezik-e explicit getValami()/setValami() method, meg lehet oldani ertelmesebben is, lasd pl. a C#-ban.
Nem írtam, hogy explicit vagy implicit. Ahol létezik get/set és azt használod elkérésre és beállításra, ott úgy tudod megváltoztatni az objektumodat, hogy ne kelljen a program más részeibe belenyúlni.
(Egyébként C#-ban is explicit meg kell adni a get, set -et, ha jól tudom. Csak ott, ha nem adod meg, akkor nem is tudod módosítani azon értékeket.)
Igen, meg lehet oldani, hoztam is rá Scala példát, de már a Java is tudja a record konstrukcióval.
ha programozni tanulni akar, akkor codingame.com
ott a grafikai reszt nem kell lekodolni, az mar kesz van, csak az algoritmust.
hogy ez miert jo? mert kezdokent az a tapasztalat, hogy 90% idot elbibelodik a boilerplate-el, aztan mire az megvan, mar el is ment a kedve a tenyleges implementaciotol, es ottmarad a 'felkesz' (epp csak elkezdett) boilerplate projekt a fomenuvel, jatek meg sehol :( Abbol meg csak pont, hogy programozni nem tanult meg, csak a szivas reszeben sikerult elmelyednie.
Szoval: codingame, aztan ha ott megyeget a dolog, akkor johet egy tetszoleges game engine (godot/unity a flavor of the month, de a haxe es kismillio egyeb is van, google)
Imadom, ahogy ezekben a threadekben mindenki leirja merlegeles nelkul azt a programnyelvet, amivel o dolgozik, hogy az jo lesz az erdeklodo iskolasoknak.
Ugyhogy en is.
C#
Az oktatás külön műfaj, szóval nem csoda. Amíg ki nem próbálta valaki, addig elég torz elképzelései lehetnek róla. A könyves vitákban az én kedvencem az volt, amikor valaki szemmel láthatólag képtelen volt különbséget tenni tankönyv és dokumentáció között és szilárdan hitte, hogy utóbbiból nemcsak lehet, de célszerű is tanulni.
Tanár ismerősöm egyébként oktatott középiskolában C#-ot használva, szóval a javaslat életszerű.
Science for fun...
mer' a legtobben 1 nyelvet/platformot ismernek.
ennek amugy sok mas hatulutoje is van, pl. nem ismeri, vagy nem tudja ertelmezni egy nyelv/platform pro es con feature-jeit, mert azok ugye mindig a tobbivel osszevetve ertelmezhetoek.
avagy mindent (is) kalapaccsal oldunk meg, mert azt ismerjuk.
de hogy csatlakozzak, kooootliiiiiin! (volt rust is, de elfogyott - szivatas a kobon igazabol, marhara nem produktiv)
Godot Engine-t csak 1x írták eddig, de nem lehet elégszer :).
Én a Dart/Flutter-t ajánlanám.
Már az Ubuntu csomagkezelője is abban készül.:)
Eléggé hasonlít a Java-ra, Kotlin-ra. Meg persze azonnali sikerélményt is ad.
A python azért szerencsés választás, mert viszonylag könnyű, és rákényszeríti a korrekt identálásra.
Valamint - és ez sem elhanyagolható szempont - a NAT szerint 11. évfolyamon pythonnal indul a programozás tananyag, ami két év múlva neki helyzeti előnyt jelenthet.
Az most mindegy, hogy helyesnek tartom-e tananyagként a programozás tanítását egy középiskolásnak (akit pont nem érdekel, de természetesen az érdeklődő ifjút tanítani kell arra amit tudni szeretne), ahogy az adtbáziskezelést sem tartom helyesnek érettségi előtt. Pláne Access-el. Miközben hálózati ismeretek nincsenek a NAT-ban. Pedig életszerűbb az, hogy bárkinek kellhet a home routert configolni kicsit, mint az, hogy bárkinek kellhet programozni. (Bocs a kitérőért... :) )
"A megoldásra kell koncentrálni nem a problémára."
Python, Javascript hogy gyors sikerelemeny erje es elkezdjen algoritmusokban gondolkodni. Aztan petsze mehetnek a "komolyabb" nyelvek, mint a C/C++. De a lenyeg tenyleg az hogy legyen egy projekt amihez research kell meg jo sok ujraimplementalas. :D
A gitlab/github oldalakon altalaban vannak ilyen kezdo projektek, amiknek a megoldasa is ott van meg magyarazatok meg minden. En egy ilyenen mennek vegig vele. Masik fontos talan hogy technologiakat/protokollokat tanuljon. Pl. lehet inri egy monolitikus alkalmazast, aminek van UI-ja vastagkiensben, de en inkabb lehet arrafele mennek, hogy frontend/backend, a frontend webes javascript, ami a backenc-el API-n beszelet, a backend meg egy python flask vagy akarmi ami swagger-es, mogotte meg van mondjuk egy minimal DB (akar rdbms akar noSQL). Aztan jo ha nem o talalja fel a spanyolviaszt es probal mindent maga implementalni, hanem hasznalja az adott library-kat stb.
js, python.
Ha azt akarod hogy kozmetikus legyen, akkor mindenkepp c++ amit keverhetsz rusttal, hogy meg nagyobb legyen a sikertelenseg faktor.
Egyetértve az előttem hozzászólókkal, Python-t tudnám javasolni. Egyszerű, gyorsan tanulható, hamar a problémára tud koncentrálni és sikerélményt elérni. A C, C++-t egyáltalán nem ajánlanám, egyik sem egy beugró nyelv.
A programozáshoz (mint nyelvhez) nem nagyon van olyan, hogy beugró, mert az első tapasztalatok eléggé behatárolják a későbbi megértési lehetőségeket.
Azert ne Scala-val kezdjen a gyerek ha mar muszaj programozast tanulnia :D (amugy Scala rulez :D)
Arra kell radobbenni, hogy minden tobb gyerekes anyuka programozova valik amikor vasarol, mert fejben optimalizalja a sorok kozotti bejarasi utvonalat a listan szereplo elemek viszonylataban, mikozben kezeli a nyavajgos interruptokat, es neha aszinkron fuggvenyeket indit, amikor szol a nagyobb gyereknek, hogy hozza vissza a kicsit, amig o elmegy a csemegepulthoz. :-)
Nos, nézzük csak, én a következő nyelvekben programozgattam (lassan 30 éve), időrendi sorrendben így tanultam őket: Clipper, Pascal, Delphi, Assembly, C, BAPC, Java, C++, SML, Prolog, Javascript, C#, LUA, Python, Groovy, Haskell, Go, TLA+
Nem állítom, hogy minden benne van, de a nagyja azért igen. Ebből látszik, hogy igazából tök mindegy a nyelv, de valójában még a módszertan is. Problémák vannak, amiket adott eszköz segítségével old meg az ember.
Ja meg az en idomben ugy tanultuk szintaktika es szemantika. Ha igy nezed minden nyelv megtanulhato, akarcsak mondjuk a gorog vagy a lengyel az angol mellett. A kerdes ahogy te is irtad hogy mire hasznaljuk oket.
Azt szoktam mondani, hogy az algoritmikus gondolkodas es a nagyobb problemak kisebbekre bontasa a legfontosabb. A tobbi meg majd jon a tapasztalattal es azzal hogy mit mire. Egy kis scriptet nem fogok pythonban megirni, de egy kisebb API-t lehet inkabb abban, de ha meg mar mogotte komoly dolgokat kell csinalni, akkor meg lehet spring es java. De ki tudja. Adja magat.
C nekem nagyon könnyen ment, mert előtte nagyon sokat programoztam assembly-ben. Ha az ember érti a hátteret, a gépi reprezentációt, akkor a C könnyű. :)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Nekem is konnyu volt a C, mert nekem sem beugro nyelv volt. (hanem ha jol szamolom, 6.)
OP belepo nyelvet keres, errol folyik a diskurzus.
A strange game. The only winning move is not to play. How about a nice game of chess?
Én most C#-ot (minimum a 9-eset) tanítom a családon belül egy 9.-es középiskolás srácnak és szerintem nagyon ügyesen halad vele és látszólag érti is.
Szerintem jól lehet benne fokozatosan bevezetni bonyolultabb dolgokat.
Mi a VS Code-ot használjuk és a stack gyakorlatilag elfut "bármelyik" platformon. Konkrétan futtattuk ugyan azt a konzolos programot már Windows-on és Linux-on is.
A Top level statements-et (v9-től) kihasználva még class/main boilerplate-et sem kell eleinte használni.
https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/program-structure/top-level-statements
Én magam Pascal-on tanultam első nyelvnek. Majd kis C-t és azt követően C#-ot és abból is érettségiztem 2000-es évek közepe felé.
Mondjuk ennek ellenére én Java fejlesztő vagyok. :D
Apróbb érdekesség, hogy a Pascal-t és a C#-ot is Anders Hejlsberg alkotta meg.
Ez melyik Pascal? Amit én ismerek, azt Niklaus Wirth alkotta. ;-)
Turbo Pascal. Link: https://en.wikipedia.org/wiki/Turbo_Pascal
Igen, ez egy Pascal fordító.
:)
Niklaus Wirth írt az egyik könyvében részletesen egy fordítóprogramról, az adta az ötletet Hejlsbergnek, hogy írjon egy compilert ahhoz a Pascal nyelvhez, amit szintén Niklaus Wirth alkotott meg. Erről a könyvről (pontosabban annak egy fejezetéről) van szó: http://pascal.hansotten.com/uploads/books/Algorithms%20chapter%205%20pl…
Hejlsberg először azon az egyetemen írt egy Pascal fordítót az egyik ottani mikroszámítógépre, ahol tanult, később ezt portolta CP/M-re és DOS-ra is, majd a Borland is licencelte, egy idő után pedig Hejlsberg a Borland alkalmazottja lett, ahol a Turbo Pascal fejlesztését vezette. A Borland után átment a Microsofthoz, ahol vezető fejlesztője lett a C#-nak.
Szóval a Pascalt nem Hejlsberg alkotta meg.
Szépen összefoglaltad, pont ezt akartam írni. Csak nagyon vigyázz, két bekezdést írtál, ez több embernek rengeteg itt, annyit nincs idejük elolvasni, nekik életük van, amit sírással töltenek el, hogy túl hosszút írtál, grafomán vagy, stb..
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Csak az maradt ki, hogy az MS számára nem a Pascal volt az érdekes, hanem a Delphi, amivel a Pascalt új szintre emelte. Ha megnézitek igen sok Delphi / Object Pascal feature van a C#-ban.
ASM. ARM, x86 vagy valamilyen mikrovezérlő ASM-je. Természetesen. Mi más? Ha érteni akarja a gépet, akkor először a gép nyelvét kell megtanulnia! És ez csak félig vicc, érdemes elgondolkodni rajta, illetve ha a gyereknek van affinitása hozzá, akkor tényleg ASM-ezzen!
A játékkal mint motivációval annyi a baj, hogy nagyon nehéz olyat csinálni, ami elfogulatlan harmadik félnek is tetszeni fog. Láttam már példát rá, hogy gimis gyerek csinált ilyet, de azért az esetek többségében nem sikerül. Vigyázni kell, hogy megmaradjon akkor is a motiváció!
Egyébként meg én vennék könyveket a gyereknek. Lehet, hogy könyvesboltban már nincsen, de biztosan nem szűntek meg a könyvek. Az én időmben még adtak ki könyveket, ezeknek az antikvár példányai jók lehetnek. Például Szirmay-Kalos László grafika könyve szerintem kitűnő alapmű. Ezen kívül kell egy algoritmusos könyv legalább.
A net arra jó, amikor tudod, hogy nagyjából mit akarsz, de valami nem jut eszedbe, akkor arra rá tudj keresni. Ha fogalmad sincsen, hogy mit akarsz, akkor sokkal jobb egy könyv, aminek van eleje vége meg célja. Ha még a programkódok nem is működnek ma már, akkor is jobb egy könyv, mint online részleteket bogarászni. Kivéve, ha találsz olyat online ami tényleg az elejétől eljut valameddig.
Bezzeg assemblyben! Ha ügyes, pár hét alatt eljuthat akár egy fényreklám szerű izéig is a terminálban! Az lesz a motiváció csúcsa! És a barátai is le fogják tenni a kalapjukat, hogy mekkora királyság!
Nem tudom, tini korban hogy lesz, a kisebb gyerekemen most azt látom, hogy
És azért visszagondolva, én is kb így működtem még tinédzser korban.
Mondjuk az is szempont lehet, hogy mennyire haragszol eppen a kolyokre, mert ha nem rak rendet a szobajaban, akkor johet a Brainfuck, vagy a Whitespace... :-)
+1 a Pythonra.
A jelenleg hasznalt nyelvek kozul a legjobban tanulhato, es nagyon sok dologra jo, raadasul jellemzoen ugy neveli a hasznalojat, hogy szep kodot irjon, kulonben le sem fut (menyi ide-oda huzott, furan kapcsoszarojelezett kodot lattam mar..). Akkor is, ha a vegen a jatekot nem ebben irja (bar pygame-mel eleg sokaig el tud jutni). Tobb eles projectem volt mar pyqt5-tel is, ez tud 3D-t, de azt pont nem hasznaltam ujjgyakorlaton tul.
A C++ talan a legnehezebben tanulhato, mert annyi szintje van. Egy sima printelest meg tudsz irni vagy 5 kulobozo absztrakcios szinten. Lehet open+write, printf, cout-os stilusu, es meg par masik. Memoriakezeles? Ott a new, hasznalhatsz pointereket, smart pointert, vannak iteratorok az std adatszerkezeteihez, de visszanyulhatsz a C-s malloc/calloc/realloc szintre is. Ennek ellenere az a masik kedvencem, nagyon hatekony tud lenni, de kezdore elso nyelvkent lehet, hogy nem zuditanam ra.
Ha megis a C++ mellett dontesz, akkor viszont ajanlom a Colobot nevu jatekot. Linuxra is van.
Pythonhoz nagyon jol sikerultek az MIT Open Courseware programozashoz bevezeto eloadasai (2 felev, nem kell megijedni, hogy "egyetemi szint"). Angol persze kell hozza.
A strange game. The only winning move is not to play. How about a nice game of chess?
Érdemes elsőnek az algoritmusokkal foglalkozni. Ezek nem kötődnek programnyelvekhez, pszeudó kódban van maximum a legtöbb.
Másodsorban ami meghatározza a nyelvet, hogy milyen irányban lenne az amiben szívesen dolgoznál? (játékfejlesztés, telefonos alkalmazások, üzleti irányvonal, frontend és/vagy backend? stb.)
A válaszoktól függ a nyelv és az keretrendszer amiben érdemes elindulni. Ez adhat egy irányt, de ilyen kevés infóból pontos tanácsot nehéz adni:
https://www.simplilearn.com/best-programming-languages-start-learning-t…
Szijártó Zoltán
Aki tud az alkot, aki nem tud az csak szövegel.
15 éves. Szerinted?
Ebben a korban már arról beszélünk hogy válasszon pályát, mi iránt érdeklődik stb. Ezt a szakmát is kiválasztotta, programozo akar lenni.
Nézzen körbe , tud és van miből választani.
Szijártó Zoltán
Aki tud az alkot, aki nem tud az csak szövegel.
Dehogy választotta.
"A fiam 15 éves és kevés számítógépes alappal, de annál nagyobb lelkesedéssel szeretne saját programokat, játékokat fejleszteni. Készített már kisebb animációkat, sprite-okat, saját zenéket, képeket, de szeretne a játékprogram készítésbe belevágni. Kiválóan olvas és beszél angolul, az angol nyelvű tartalom jobb lenne mint a magyar."
Nekem ez alapján úgy tűnik választotta. Persze lehet kőműves tanonc is aki hobbynak ezt választja, de az irány ugyanaz amit írtam.
Típus (alkalmazás, játék, egyéb) majd a plattform (console, telefon, pc, egyéb) és nyelv kiválasztás. Ez optimális, persze egyéb esetek is működnek.
Szijártó Zoltán
Aki tud az alkot, aki nem tud az csak szövegel.
Szerintem az, hogy szeretne ezzel foglalkozni, nem jelenti az, hogy ezt a szakmát akarja csinálni. Szóval nem biztos, hogy érdemes azzal kezdeni, hogy papíron csinálja meg algoritmusok és adatszerkezetek 1-2-t. Ha játékot akar csinálni, akkor kell alá tenni valamit, amiben játékot lehet csinálni, lehetőleg minél gyorsabban.
Egyeteretek. En peldaul nem vagyok programozo meg jatekfejleszto sem, de jo sokat bohockodok a Godot-val sajat oromomre :D
A szakmam meg nem kapcsolodik a fentiekhez.
Jah tortakat is sutok de nem vagyok cukrasz (jo, monjuk 5-tol 17 eves koromig az akartam lenni...eleg messze sodrodtam :D)
Sokszor elkövetik azt a hibát egyesek, hogy azt mondják: "Nem kell valami komoly nyelv, "CSAK JÁTÉKOT" akarok programozni.
Pontosan nagyon sok játékhoz kell a nagyon feszített belső időzítés és egyéb, egyébként az UX nagyon csorbul.
Míg egy dokumentumgenerálásnál csúszik valami 100ms-ot, akkor jó esetben semmi sem történik, viszont játékoknál egy ekkora lag már kikezdi a játékélményt.
Persze ha tetris a cél, az más ...
Nem érted a fókuszt.
És igen, nagyot tud csorbulni az UX, majd amikor már elkezdi feszegetni a határait annak, amit elkezdett, és akkor majd kiderül, hogy van-e értelme, hajlandó-e mélyebbre menni. Ettől még kezdeni nem baj egyáltalán, ha olyat kap, amivel tud számára kézzel fogható eredményt kapni. Ha beveri a fejét, majd lehet tovább haladni. Ha elkezded száraz szarral etetni, el se fog jutni odáig, hogy beverje a fejét.
Nekem a memória foglalás és az operációs rendszer eseményeinek megismeréséhez a PureBasic segített a leg többet.
Python , java, go, rubi, OOP nyelvek ezt a részt mind másként dolgozza fel. Elrejti az OS alap működését.
A PureBasic IDE rendszerében adott a leg gyorsabb siker élmény:
- Az elgépelésekre figyelmesztet. Ha nem fordul, segítő üzeneteket dob. Sose vitt hibás irányba. Ez egy megbízható rendszer.
- Az F1-re felugró beépített help tömör, hatékony leírás.
- Kivállóan megtervezték a help gyökér rendjét.
- Az ágak kicsi mintái az alapok próbálására a leg hatékonyabb tanuló hely: Mouse, GUI, 3D ...
- Itt a leg gyorsabb a fordítás és popup -al vizsgálható a költemény változói az adott töréspontban.
- Foruma lelkes közösség. Gyorsan segítenek ha elakadtál a mintával, vagy terveidet nem tudod hogy lehet megoldani.
- A codeArchiv alapot adhat saját alkotásra:
- http://www.purearea.net/pb/english/index.htm
- Itt könyvek is vannak, de nekem jobban tetszett a beépített help tömör segítsége.
Voltak akik tovább léptek golang vagy cpp felé, és vissza jöttek, mert gyorsabban tudják megoldani PB -vel.
Nem adott többet a github goLang szemfényvesztése.
Sokaktól hallottam hogy OOP kell kezdeni az oktatást, mert különben az agyad vissza tér a funkcionalis kódolásra.
Szerintem az OOP bölcsészeknek valók, akik nem akarják megoldani a felhasználónál a hibátlan működést.
Minden OOP megoldás kicsit más. Jó lenne ha felismernék, hogy a 20év OOP fejlesztés munkáját ki kell dobni, mert a való életben, több munkát ad, mint amit megold.
Dícséretes hozzáállás!
Azt hiszem alapvetően innen származnak az ops vs. dev ellentétek.
Munkám során ops és dev közötti hatékony együttműködés csak akkor sikerül (mert sikerülhet!), ha sem a dev, sem az ops nem zárkózott be a kis világába, és (ha nem is szakértő szemmel) de mindegyik értette mi történik a másik oldalon. Legalább nagyvonalakban.
Ha a dev csak a kódot látja, az ops meg csak az OS-t, akkor kibékíthetetlen lesz az ellentét. Mert erőforrás és idő szempontjából alapvetően ellenérdekelt felek.
"A megoldásra kell koncentrálni nem a problémára."
[facepalm] Amikor valaki az OOP kidobásáról fantáziál egy olyan rendszert használva, aminek kb 85% oop (desktop, böngésző, telefon, stb.)...
:DDD
lol, szeretem az ilyen vilagmegvalto kijelenteseket
Hogyne, tudsz egyetlen kozismertebb szoftvert mondani, amit ebben a csodalatos programnyelvben irtak?
pl: a PB IDE önmaga is PB.
A v5 -nél a tervező a bolgján bemutatta a modul rendszert. Nem több emberes nagy projektekre tervezte.
Nincs optimalizáció, nincs fordításkor codbase előfeldolgozás. Manuálisan kell figyelni, hogy a header file előre kerüljenek. A gyors egyszerű fordítás volt a cél.
Régebben lassabb volt a cpp fordítása, és neki ez volt a verseny előnye.
Tehát ezért nincs nagy játék projekt PB-ben.
v6 nál már nem assemlire fordít, ha nem c köztes rétegre. Lett optimalizáció és M1 ARM -ra is fordít.
:D
Komolytalan ez igy.
Jol elbeszelgetunk, csupancsak a kerdeseidre nem valaszoltunk.
"kell-e bármilyen megelőző alapismeret mielőtt elkezd egy nyelvet tanulni?"
Nyelvtol fugg, assemblyben nem lehet ugy programozni, hogy nem ismered a vasat, hogy mik azok a regiszterek, hogyan mukodik a memoria, stb. Magas nyelveknel, pl. Pythonban a jozan esz tobbnyire eleg, a nyel nagy resze adja magat, hogy mire valo.
"milyen nyelvet lenne érdemes tanulnia?"
Rossz a kerdes, mert a hasznalando nyelv feladatfuggo. Ha a gyerek nem szereti a l' art pour l' art dolgokat, akkor eloszor tuzzon ki maga ele valamilyen celt. Peldaul Anya irodai munkafolyamatainak tamogatasara egy python+tcl/tk script ami nehany bemenet alapjan megnyit egy excelt es atir benne dolgokat. Nagyobb boldogsag hasznos dolgot letrehozni, mint csinalni egy oncelu hello wordot.
"milyen tananyagot, tematikát találunk ehhez és hol? "
Ha mar adott a cel es ez alapjan a programnyelv, akkor mutasd meg a fiadnak a chatGPT -t, jelenleg ennel hasznosabb informacio forras nem nagyon van, es ennek a hasznalatabam szerzett rutin pont olyan hasznos es szukseges tudas lesz szamara, mint nekunk a google hasznalat.
Szerencse kell hozzá, hogy a ChatGPT ne hazudozzon meg hallucináljon. Abszolút megbízhatatlan.
+100 a legnagyobb hülyeségeket is képes a legnagyobb magabiztossággal előadni. De a legrosszabb, hogy jónak tűnő outputot gyárt sokszor, de közben fontos részletekben mond hülyeséget, ami miatt az egész kód használhatatlan.
Helyesbíteni, kijavítani szoktátok? Lehet, hogy tanul belőle. :)
Majd pont egy kibaszott gépet fogok tanítani, nincs jobb dolgom :-)
Egyik kedvenc előadom (programozással kapcsolatos) mondta ezt nagyjából:
;-)
Megkérdeztem, nem tud tanulni. Azt mondta, valami ilyesmin dolgoznak a fejlesztői, de még csak tervezgetik. Persze azt hiszem, értem, elvégre százmilliárd légy egyetért abban, hogy a lócitrom ízletesebb a bagolyfőzeléknél, szóval óvatosnak kell lenni abban, hogy kitől mit tanuljon... :)
Megbizhatatlan, de nagyon hasznos ennek ellenere. Nem art megtanulni hasznalni. Nalam is meg megy a tanulasi folyamat. Azt vettem eszre, hogy ha adok neki egy feladatot, neha a legnehezebb reszet hibatlanul es hatekonyan megoldja (mert ahhoz hasonlo kodot latott a neten), de a legtrivialisabb reszen ejt hibat. Amikor mondjuk juniort code review-zol, akkor pont a nehez reszleteket nezed at tobbszor, az egyszerubb meg "kb. jo".
A strange game. The only winning move is not to play. How about a nice game of chess?
A hozzászólásomból úgy tűnhetetett, hogy lebecsülöm a technológiát, pedig nem. :) Azt gondolom, hogy egy megfelelően betanított generatív AI nagyon jó segítség lehet a szoftverfejlesztésben. Itt az egyik fő kérdés, hogy milyen tanító adatbázist használjunk.
Ez szerintem nem szerencsén múlik, hanem a kérdés és a válasz összetettségén.
A kritikus hozzáállás a válaszokhoz pont ugyanúgy kell, mint minden más válasz esetén, a válasz forrásától függetlenül. A google -tól kérdezve csak az elsőt olvaso el, vagy válogatsz, és gondolkozol? A google megbízhatatlan... A stackoverflow találatok egyből adják amit kérsz, vagy van, hogy egy kicsit másra válaszol, vagy több válasz is van, ami mind másképpen nem teljesen stimmel? A stackoverflow megbízhatatlan... Kérdezel a HUP -on, például, hogy milyen programnyelv lenne jó a gyereknek, és erre ezek a barmok elkezdenek egymással veszekedni, ahelyett, hogy leírnák, hogy megírnák az egzakt választ? A HUP lakói megbízhatatlanok... :-)
A ChatGPT egy rohadt jó eszköz. Én rengeteget kérdezek tőle, gyakran olyat is, amit ismerek, (vagy ismerni vélek) mert kíváncsi vagyok, hogy mekkorát téved a témában. Gyakran nem téved. És jó párszor van, hogy megemlít egy olyan dolgot is a témával kapcsolatban, amit nem ismertem.
A ChatGPT nem arra való, hogy a válaszát copy-paste betegye az ember a kódbázisba. Mint ahogy a Stackoverflow sem alkalmas erre a célra, pedig voltak akik így "programoztak". A józan észt nem lehet kihagyni abból a folyamatból ami a feladat megértésével kezdődik és a produktum leadásával végződik. Ennek igenis hasznos része a ChatGPT, ergo a gyereknek igenis tanulni kell a használatát, és meg kell ismernie a hiányosságait, hogy később ezzel felvértezve érvényesülhessen az életben!
Alphacademy:)
Reklámnak jó volt, másra nem nagyon.
Középiskolás kezdő(dő) programozó milyen programnyelvvel kezdjen
... Kiválóan olvas és beszél angolul, az angol nyelvű tartalom jobb lenne mint a magyar
OPA?