Java tanulás hogyan?

Programozás - kezdő

Sziasztok!

Fiam Pascal-t tanul magától is, meg az iskolában is. Még nem profi, de elég jól halad, és mostanában eljutott olyan problémákhoz, amiket Java-ban sokkal egyszerűbb megoldani, mint Pascal-ban.
Szerintetek Java-t meg lehet tanulni, vagy érdemes egyáltalán úgy tanulni, hogy az ember előtte nem tudott C-ben? A Pascal-t valahogy nagyon távolinak érzem a Java-tól.

  • 5029 megtekintés

( elod v | 2015. 12. 12., szo – 15:26 )

Nem biztos hogy érdemes erőltetni a Java-t, ebben a korban egyszerűbb és hasznosabb dolgokkal is foglalkozhat.
Python, C# például. Utóbbi nagyon jó lesz gyors prototípusokat gyártani ha egyetemen ilyen irányba kacsintgat.

Ha érdekli az alacsonyabb szintű dolog akkor light-os C (arduino pl.) már csak azért mert kicsit bepillanthat a hardver részbe is ami ebben a korban jó, most kell beépüljön az elméjébe.

Nálunk is Pascal-oznak, a gond alapvetően az, hogy nem viszik tovább az iskolában tanultakat. Annó nagyon jól szórakoztam pl. a SWAG-al, audió-videó perifériák programozásával.

Én Pascal után Delphiztem kicsit és utána jött a Java. Idő közben belenéztem a C#-ba is meg a Pythonba is, de a Java-nál maradtam. Szerintem mindegy, hogy C# vagy Java. Mindkettőnek megvan a saját ökörsége és szerintem egyik se jobb a másiknál(ha nem a sebesség szempontjából nézzük)

"egyik se jobb a masiknal"
persze, ahogy moricka elkepzeli...

A C# sokoldalubb, a Java meg egyszerubb.
Egy viragkotonek a Java is bonyolult, tehat a Java egyszerubbsege nem elony, ha meg viragkoto vagy, akkor inkabb ne programoljal!

A Java egyszeruen szar kezekben volt es van. A 8-asba vegre van mar lambda, es megkaptak a javasok a Stream API-t; Hallelujah!

Nem vagyok Java-ellenes, csak szeretnem felhivni a figyelmet arra az ecceru tenyre, hogy kurva lassan halad a nyelv fejlodes, ez ezzel azokat a fejlesztoket szopatjak, akik Javaval akarnak vagy kenytelenek dolgozni.

A C# egyszeruen jobb kezekben van, es a Microsoft jelenleg goz erovel halad jo iranyba, es a nyelvet _folyamatosan_ (_regota_) fejleszti; ezert is tart _joval_ elorebb, es ezert jobb/elvezetesebb fejleszteni C#-ban a Javaval szemben.

Most lehetne sorolni sok mindent, amiert jobb a C#, de ami tenyleg hianyzik a Javabol, es a C#-ban mar regen benne van:
- default parameter
- operator overloading
- property
- extension methods
- partial class
- Decimal type
- dynamic type

Es ezek nyelvi szinten vannak jelen, nem valami 3. fel altal osszehekkelt konyvtar szolgaltatasakent.

https://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Java

Bár a „kurva lassan halad a nyelv fejlodes” kijelentéseddel egyet értek, s titkon reménykedem benne, hogy egyszercsak tényleg megunja a Google, s elforkolja az egészet a francba.

De:
- default parameter: ez nekem kifejezetten nem hiányzik. Az elmúlt ~1-1,5 évben nem emlékszem 10 esetre, amikor használni szerettem volna. Ellenben, tapasztalataim szerint, ebből születnek a 10-15 paraméteres metódusok, átláthatatlan fejléccel.

- operator overloading: jajj, ne. Inkább legyen egy 

myVector.crossProduct(Myvector lhs)

, s egy 

myVector.dotProduct(MyVector lhs)

függvényem, minthogy a * az egyik, a % a másik. (ez utóbbi egyetemen jött szembe, és isten mentsen tőle, minden híváskor fel kell tekernem a dokumentációig). Leírni nem fáj a hosszabb metódusnevet (az IDE úgyis kiegészíti), ellenben borzasztóan olvashatatlan.

- property: ne. Egy szabványos 

@Getter

/

@Setter

annotációt (ala Lombok) elfogadnék (hiányzik), de ami függvényhívás, annak legyen függvényhívás szintaktikája.

- extension methods: ezt jól sejtem, hogy olyasmi, hogy meglévő osztályokhoz tudok saját metódosukat „beleinjektálni”? ne. Erre Verhás Péter blogját tudnám hozni - a megszokott, mindenki által ismert osztályokat ne bővítgesse senki, mert nagyon csúnya dolgok születhetnek belőle.

- partial class: itt amit az MSDN hoz két példát, hogy mikor érdemes használni, de egyiket sem tudom elfogadni. A több ember/forráskódot a veziókezelő oldja meg, a generált kódot pedig én kiváltanám szabványos annotációkkal. Ettől függetlenül lehet, hogy hasznos, de nem érzem a hiányát.

- Decimal type: hm? ez ez: MSDN? Ez mégis mire jó? Ebben a 0.3-0.2 tényleg 0.1?

- dynamic type: ez mire jó? ezt találtam: MSDN - de nem értem, miért jó nekem, ha kikerülöm a compile time checket. El tudom fogadni, csak nem látom a szituációt, amikor ez hasznos lehet.

Ettől függetlenül tényleg szar kezekbe van, szerintem is - lassan fejlődik, s húzza maga után az évtizedes legacy dolgokat (hello, dátum implementációk, és visszafelé kompatibilis generikusok). Továbbá vannak dolgok, amiket el tudnék fogadni (pl.: non-null reference types, vagy az említett Lombokhoz hasonló annotációk szabványosítása), de a fentiek többsége pont nem hiányzik.
--
blogom

Erről a getter/setter-ről jut eszembe a vasutas bácsi, aki a nyugdíjba vonulása alkalmából tartott búcsúztatón megkérdezte, hogy miért is kellett neki negyven éven át kalapáccsal kopogtatni a vonatok kerekeit? Ja, hogy a hangját kellett volna figyelni? Hát ezt ő nem tudta.

Vagyis ha a getter és setter metódusokat egy derék szoftver automatikusan generálja, akkor miért is van nekünk private adattagunk? A private azt jelentené, hogy a jámbor hívó korlátozottan vagy sehogy sem fér hozzá az illető adathoz. Ha ezt nem szempont, akkor nem getter/setter-t kellene generálni, hanem publikus adattagot használni.

erről egyszer már volt egy szál itt, valahol - ne haragudj, ma biztosan nem keresem meg. esetleg holnap.

a lényeg, hogy ha ma megírom a pojot, getterrel, setterrel - majd egy hónap múlva kiderül, hogy a beállításnál kéne validáció, akkor sokkal egyszerűbb a meglévő settert egy helyen átírni, mint mindenhol refaktorálni az adattag írást setterre.
--
blogom

Ebben persze igazad van, csak sajnos addigra már a hívó rákapott arra, hogy a setter-t korlátozás nélkül használhatja, nem kell ellenőrizni a hibát...

Aztán meg tipikusan több adattagot egyszerre kellene beállítani valamilyen ellenőrzéssel egybekötve; mondjuk a RendszerIdő objektumunknak nem fejlesztünk ki setÉv, setHónap, setNap, setÓra, setPerc stb metódusokat, csak egy darab setDátumIdő metódust...

Vagy, kedvenc példánkban, a komplex-számoknál ugye nem setReal és setImag metódust tákolunk, hanem setDescart meg setRphi metódusokat.

> majd egy hónap múlva kiderül, hogy a beállításnál kéne validáció, akkor sokkal egyszerűbb a meglévő settert egy helyen átírni, mint mindenhol refaktorálni az adattag írást setterre.

Na, erre jó a property. :) Az értékadás mindig értékadásnak néz ki, de lehet validációt is beépíteni, ha arra van igény.

> property
> ami függvényhívás, annak legyen függvényhívás szintaktikája

Jaj. :) A property pedig elég jól illeszkedik az OOP-modellbe, legfeljebb annak nem hiányzik, aki még sosem használta. Persze workaroundként jól el lehet bohóckodni függvényekkel, mint ahogy if-fel és goto-val is körül lehet írni a ciklusokat, valahogy mégsem szeretjük.

> partial class

Nem tudom, mik a példák az MSDN-en, de ha az jön le belőle, hogy felesleges használni, akkor baromságot ír az MSDN. Még nem láttam olyan MVC-s vagy Entity Frameworkös projektet, amiben ne használtunk volna ilyesmit.

> Nem tudom, mik a példák az MSDN-en

- ha több fejlesztő is dolgozik egyszerre az osztályon, akkor nem zavarják egymást
- mehet külön fájlba a generált kód, s az általad írt.

> Még nem láttam olyan MVC-s vagy Entity Frameworkös projektet

Ezt elhiszem, ettől függetlenül tényleg nem tudom, miért annyira nagyon kellene ez nekem.
--
blogom

> mehet külön fájlba a generált kód, s az általad írt.

Na várj, ez nem hülyeség, erről beszélek én is.

Az Entity Framework mondjuk generál egy rakás osztályt egy DB alapján. Te ezt szeretnéd mondjuk egy MVC-be belapátolni modellekként. A generált kódot annotálni kb lehetetlen, minden frissítésnél eltűnnek. Kézzel megírni wrapper osztályokat butaság. Stb.

Partial class-ként jön ki a generált kód, te egy másik fájlba csak átmásolod a property-ket, annotálod őket, működik.

- default parameter: A jávások builder patternt használnak. Az mennyivel jobb? Scalaban létezik, teht mégis van létjogosultsága.

- operator overloading: Nem egyszerűbb így feliratkozni (akár 10-szer) egy eventre: MyObject.MyLittleEvent += (sender, eventArgs) => { myCodeHere(); }? Ebben az esetben a += overloadolt.
Próbáltál már Galois testre épülő bármilyen algorutmust lekódolni csak metódus-/függvényhívással? Ajánlom így megírni egy Lagrange polinom interpolációt, nem lesz olvasható a kódod...

- property: a { get; set; } mennyivel kevésbé szabványos, mint a @Getter/@Setter? Az Ecma (ECMA-334) és az ISO (ISO/IEC 23270:2006) elég szabvány?

- extension methods: miért ne lehetne meglevő osztályokat bővíteni? Attól a meglevő funkcionalitása nem veszik el.

- partial class: tipikusan akkor használják, amikor a kód egy része kézzel készül, a másik része generált. Nem kötelező használni, de a lehetőség adott. Szerinted melyik megoldás a költséghatékonyabb? A reflectionre épülő annotációs megoldás, vagy az előre generált/fordított kód?

- Decimal type: igen, tényleg 0,1 lesz.

- dynamic type: pl. Python/Ruby/Lua interoperabilitásra jó. Beleteszed egy dynamic objectbe a dolgaidat, és meghívod az IronPython kiértékelőjét, és a python kód egy csini kis pythonos objektumot lát.

----8<-------------------------
Szerintem, ha valaki most tanul programozni, az ne a C#-pal kezdje, hanem pl. Pythonnal.
Egyszerű, mint a feék, nagyon könnyen lehet benne látványos dolgokat csinálni, és majdnem minden megvan benne, ami a Jávában/C#-ban/C++-ban, és a közösségi támogatása is elég jó.
----8<-------------------------

Fuszenecker Róbert

Map<Integer,String>dict = new TreeMap<>(){{
    dict.put(1,"egy");
    dict.put(2,"három");
    dict.put(3,"három");
}};

1. Hibás kód, a dict változóra nem lehet initializeren belül hivatkozni. s/dict.//
2. Nyilván így értette crystal88 a mutable-t, hogy a lista size-ja mutable. (add, remove)
3. A 2-t a magyar nyelvben úgy fejezzük ki, hogy "kettő", nem úgy hogy "három". Formázást elfelejtett a szerző írni;
4. Java 9-ben ennyi: List.of(1, 2, 3, 4, 5); és Map.of(entry(1, "egy"), entry(2, "kettő"), entry(3, "három"));

trololol :DD
üzenem xxx okostojásnak, hogy az Arrays.asList(...) immutable megvalósítást ad vissza, szóval ha mutable lista kell, akkor be kell csomagolni ArrayList-be.

Tehát a cikket így kéne bővíteni (láthatóan xxx szellemi képességeit meghaladta egy 3 soros komment értő elolvasása):

"Ami C# alatt így néz ki:
var list = new List<int>(){1, 2, 3, 4, 5};

Az Java-ban így:
List<Integer>list = Arrays.asList(1, 2, 3, 4, 5);

Vagy ha módosítható lista példány kell, akkor így:
List<Integer>list = new ArrayList<>(Arrays.asList(1, 2, 3, 4, 5));
"

A névtelen osztályos baromságot meg ki lehet törölni (sose láttam még, hogy bárki is használná).

Map-re egyébként ugyanilyen módszer nincs, szóval ezt el lehet könyvelni a java hátrányának, ha nagyon szeretné mélyentisztelt xxx

Mind a kettő tanulhatna a másiktól, de olyan, mintha mind a kettő write only-ban volna.

kodfodrasz kolléga nem képes megérteni, hogy crystal88 kolléga szerint erre kellene javítani a Java példáját: 

List<Integer>list = new ArrayList<>(Arrays.asList(1, 2, 3, 4, 5));

crystal88 kolléga pedig nem veszi észre, hogy hibásan használja az immutable kifejezést.
(módosítható helyett bővíthetőt kellett volna írnia, de ez a lényegen azért sokat nem változtat)

nno, erre így ebben a formában már hajlandó vagyok reagálni.

Az Arrays.asList() tényleg mutable (a set(int, E) működik rajta), szóval ezt tényleg benéztem / rosszul tudtam.

A kódfodrász kolléga névtelen alosztályos megoldása viszont nem azért ordas baromság, mert "én még nem láttam olyat", hanem mert az Arrays.asList()-hez képest:
* szintaktikailag bloated
* a plusz alosztály fölöslegesen jön létre (plusz egy class fájl), és a JIT-et is potyára dolgoztatja, ami azért a feladat trivialitásához képest (inicializáljunk egy listát fix elemekkel) elég durva overhead

"hanem mert az Arrays.asList()-hez képest:
* szintaktikailag bloated
* a plusz alosztály fölöslegesen jön létre (plusz egy class fájl), és a JIT-et is potyára dolgoztatja, ami azért a feladat trivialitásához képest (inicializáljunk egy listát fix elemekkel) elég durva overhead"

Épp ezt próbálta elmagyarázni...

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ja, csak egy ekkora bazinagy antipatternt nem kéne beírni a cikkbe "Java alatt így is lehet" körítéssel, mert ugyan lehet, csak kurvára nem kéne (az - egyébként általa is nagyjából leírt - hátrányok miatt). Főleg úgy nem, hogy a helyes megvalósítást nem írja oda (eredetileg nem volt ott).

szerk. részemről az anon. subclassos inicializálásra pontosan az vonatkozik, amit kódfrász kolléga maga írt:

1214 074638 <kódfodrász> valamint a review, ahol rábasznak a fogyi kolléga kezére
1214 074646 <kódfodrász> ha sokadszor csinálja kirúgják

:)

LINQ-s részre: JINQ?

"Szóval egy int-re senki sem akarna toString()-et hívni... " Akkor olvasd el ezt: http://cr.openjdk.java.net/~jrose/values/values-0.html

Dynamic type: Ezt megcsinálták már, de library szinten. Nyelvbe azért nem rakják bele, mert még library részét ezt sem akarta túlságosan a nép (bővebb infóért core-libs-dev listán JEP 276-ra kell keresni).

"Iszonyatos hiányok" Írjál már egy példát, hogy miért kéne most Guava-t, Apache Commonst vagy hasonlót használnom tetszőleges projekthez. (Java SE, EE-t nem ismerem)

Aztán ott van az anonimos írás: var model = new { Name = "John Doe", Age = 12 };Nekem speciel jobban tetszik az, hogy Model.byName("John Doe").age(12)

És igen, nem gyorsan fejlődik a Java, de ennek jó oka van.

U. i. a property-s bekezdéshez: Szerintem jobb, hogy írhatok point.x(5).y(1)-ot, mint hogy:
point.setX(5);

point.setY(1);

> Nekem speciel jobban tetszik az, hogy Model.byName("John Doe").age(12)

Tökre igazad van, de sajnos a legritkább esetben néz ki úgy IRL a dolog, hogy "var model = new { Name = "John Doe", Age = 12 };"

Ha valami kihullik a LINQ-ből, ember legyen a talpán, aki minden lehetséges output set-et külön definiál valahol.

> "We only add features because they add value, not because they are cool."

Ez egy baromság, ha megnézed a linkelt blogot, valaki elég jól kifejtette, hogy a felsoroltak nagy részére nem a coolság faktor miatt van csak szükség.

nekem ezzel tényleg csak annyi bajom van, hogy idejön Pistike, aki olyanokat gondol, hogy minek property, s csinál egy ilyet: 


public string Sztring;

akkor a 

inst.Sztring="pelda"

kódból nem fogom tudni, hogy micsoda is. Property van mögötte (konvenció szerint), vagy eléri az attribútumot (mert ő éppen újító kedvében volt.) És igen, a kurva anyját az ilyennek, de mindenki találkozott ilyen emberrel, és én, személy szerint örülök neki, hogy a Java nem engedi ezt.

--
blogom

Mondjuk relatíve kevés embert láttam, aki nem valami IDE-ben kódol C#-ot vagy Java-t, és ott meglehetősen egyértelműen szokta mutatni az, hogy az property vagy field.

Illetve:

1214 074628 <kódfodrász> erre még stylecop, fxcop is megolds
1214 074638 <kódfodrász> valamint a review, ahol rábasznak a fogyi kolléga kezére
1214 074646 <kódfodrász> ha sokadszor csinálja kirúgják

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

előszó: időközben olvastam, hogy nem te írtad. kedves kollégádnak címezve akkor.

pussz a személyeskedő kezdésnek, innen is. kérlek, mutass rá arra a mondatomra, ahol azt mondom, hogy „jobb a java”! Ellenben, ha tudsz figyelmesen olvasni, olyanokat írtam, hogy „szar kezekben(sicc!) van”, „lassan fejlődik”, „évtizedes legacy”, sőt gelei „jóval később keletkezett, mint a Java, így mások hibáiból is tanulhattak” mondatára is lelkesen bólogatok.

én csak annyit mondtam, hogy a fenti dolgok, nekem kifejezetten nem hiányoznak - sőt, egyes dolgoknál nagyon örülök, hogy nincsenek. Innentől fogva azt hiszem, egy „márpedig akkor is __jobb__ a c#” jellegű dologgal nem tudok, és nem is akarok veszekedni - mert elismerem, hogy bár nekem, személy szerint nem szimpatikus a nyelv, de mind a fejlődés tempójában, mind a jelenlegi fejlettségben sokat tanulhatna a Java a C# példájából.

Néhány apró megjegyzés:

> A Java mint a gondoskodó állam, megvéd a rossz döntéseidtől! Első felvonás, függöny le.
Ez így kurva demagógul hangzik, de azért én kicsit örülök ennek. Egy nagyobb csapatban, szerintem hálás, hogy mindenki rá van kényszerítve egy kicsit egy azonos gondolkodásmódra. Ha akarod, értsd félre ezt is, nem vagyok hajlandó tovább magyarázni.

> Jó ez az egységes tervezői szemlélet ami az egész Java nyelvet végigkíséri!
Idéznék magamtól: „húzza maga után az évtizedes legacy dolgokat”. Amennyire tudom, a C# alatt lazán kidobnak deprecatednek jelölt dolgokat egy idő után - irigylem is őket érte. Továbbá később keletkezett a nyelv, s ennek okán még kevesebb ilyen legacy szar van benne.

> Lombok a bytecodeot szerkesztgeti, addig a .Net 4.6 óta a fordítási folyamat gyakorlatilag pluginezhető, egyes lépcsői hookolhatóak a Roslyn segítségével.
A Lombok AST-t baszogat - ami talán még gányabb is, bizonyos szempontból, mintha bájtkódot szerkesztene. És igen, kifejezetten gány, hogy erre nincs semmilyen támogatott megoldás. A konvenciót elismerem, valószínűleg előítéletes vagyok vele szemben - én mindenesetre nem szeretném, jelenleg.

> Igaza van, tényleg ne bővítgesse senki a mindenki által ismert osztályokat! Mi van, ha a Pistike csinál egy hibás bővítményt a String-re, a libraryjét behúzom, és a stringjeim megbolondulnak!
Az extension methodos részt megint kiforgatod. Egyrészt, mint kiderült, tényleg ugyanarról beszélünk. Másrészt, kérlek idézz már, hol mondtam a fentit? Tényleg! Na?
Attól függetlenül fenttartom, hogy ez kifejezetten zavaró. Ezek után, ha egy ~300 soros osztályban látok valahol egy 

((String) null).or("Lóf*sz").toLowerCase())

sort, akkor a következőkön kell végigmennem:
- van-e Extension method használva az adott helyen.
- az .or() a String osztály függvénye, vagy mi tákoltuk bele
- ha mi tákoltuk bele, akkor mit is csinál.
És igen, ez kifezetten zavaró, hogy nem NPE-t dob, ahogy elsőre várnád.
Azt már csak halkan jegyzem meg, hogy nem átkeresztelted a blog szerzőjét. (ha személyesen ismered a hivatkozott szerzőt, s a harmadik neve Tamás, én kérek elnézést)

> generált kód csak getter/setter lehet
> egy gui designer véletlen sem generál kódot? Szerencsére az is könnyen leírható szabványos annotációkkal!
idézetet kérnék

> Onnantól úgyis kézzel kell az egészet csinálni, és az annotációkat is, meg a generált kódot is sokszor a hajunkra lehet kenni.
és akkor itt mire is jó a partial class? Mert arra, hogy a generált kódot (amit a hajamra kenhetek, meg nincs) nem fogom szétválasztani az általam írt kódtól. Itt tényleg szeretném megérteni, mire jó ez - azon kívül, hogy használni szokás.
mellesleg a GUI elrendezést nem írnám le Java/C# kódban, de ez már csak ízlés kérdése.

> decimal
Az megvan, hogy fönt ez egy példa volt, hogy ilyen nincs a Javaban. Te meg azzal jössz, hogy ez a C# alatt a Java-s BigDecimal. De, ahogy látom, te akkor is bebizonyítod, hogy én fasságot állítok, ha csak kérdezek. brafo, taps.

A dynamic typeot még mindig nem értem, de felkeltettétek az érdeklődésemet, utánaolvasok.

> Enumok
Az SWT hamarabb volt, mint az Enum, és igen, kifejezetten szar megoldás. Ellenben a 

Visibility.Fullscreen | Visibility.AlwaysOnTop

dolgot kössz, ne, egy magas szintű nyelvben felejtsük el a bitmágiát. Van rá 

EnumSet

, ami sokkal szebb megoldás. Mellesleg, szerintem itt az általa adott Javas példa nem is fordul, úgyhogy nem értem, mit akart mondani. És van egy Visibility típusunk, ami nem is egy Visibility enum érétk, hanem kettő? WUT? A C#-os var itt milyen típus ad neki?

> Bezzeg a var az hülyeség lenne
idézetet kérnék. BTW a Lombok tudja, lehet használni, nekem nem áll kézre. De amíg nem használtam a Lombokot, nagyon irigykedtem rá, elismerem.

> Persze a kvázi-szabvány OSGi helyett a Jigsaw nevű megoldással, hiszen miért is egy nyílt és piacvezető, elterjedt és bevált megoldást használnánk...
Részben +1, részben pedig értem az Oracle-t. Ha én lennék a fő embere valami 3rd party toolnak, s az Oracle közölné, hogy beemeli a standard libraryk közé, DE mostantől ők döntenek bármilyen API-t törő változtatás felett, elküldeném őket a picsába. Igen, a Java betegesen API-kompatibilis akar maradni 20 évre viszamenőleg, s ezt annyira nem komálom. Ugyanezt eljátszottak egyébként a Joda-time-mal, s a Java8-as date API-val.
A Jigsaw pedig már a Java 7 ütő feature-e lett volna, de olyan baszott lassú az egész, mint egy reumás csiga.

> hogy a clone() az Object-ben definiát.
igen, szar. húsz éves legací vacak, ki kéne dobni. De azt nem látom, hogy a C# 

Clonable<T>

interfészt megvalósító osztály deep, vagy shallow copyt csinál-e. Java alatt:
- ha implementálja, lehet clone-zni (amit megírtál, vagy a default shallow copy)
- ha nem implementálja, akkor runtime exceptiont dob.
Ha egy C#-os kód implementálja, akkor honnan látom, hogy az egyszem 

Clone()

függvény milyen mélyen másolja le az objektumot?

> Persze a valódi generikusok sem hiányoznak soha senkinek.
idézetet kérnék. én ezt találtam: „évtizedes legacy dolgokat (hello, ... visszafelé kompatibilis generikusok)”

> Maven/NuGet
Nagyon kevés dolgom volt a NuGettel. Egy őszinte kérdés: hogyan verziózol NuGet dependency leírást? megy binárisban a VCS-be? Vagy annak is van valami szöveges leírása? Mert a maven felé is fejleszthet bárki valami grafikus toolt, csak eddig senkinek nem hiányzott.

> Dependency hell
Ennyire tényleg nem ismerem a .NET rendszert, de nekünk a dependency hell-ről annyit mondtak egyetemen, hogy az OS szinten volt anno probléma. OS szinten a Java is megoldja, hiszen mellécsomagolod a függőségeit az alkalmazásodhoz.
.NET alatt meg tudom azt csinálni, hogy ha A lib a ZLogging 1.4-es vewrzióját akarja, s hozza magával, míg B lib a ZLogging 2.1-set (s ezek még csak API szinten sem kompatibilisek), akkor én használjam mindkettőt, s az A és B lib ne akadjon össze?

A többire:
Egységes típusrendszer: +1
unsigned: nekem nem fáj, de lehet, hogy valakinek tényleg hiányzik.
anonim class: +1
Diamond operátor: „évtizedes legacy dolgokat (hello, ... visszafelé kompatibilis generikusok)” (ha nem jönne le, kidobnám a g*cibe)
Verziózási problémák, modulrendszer hiánya: +1

PS.: ha a tisztelt kollégádnak nem tetszik valami, tessék idejönni, és nem valami harmadik helyszínen, kontextusból kiragadva, a szavaimat kiforgatva, és a számba adva olyanokat, amiket nem mondtam, trollkodni. És ha már ilyen kedélyesen Vilmosozik, lesz szíves legalább névvel vállalni azt.
Szerintem sehol nem mondtam azt, hogy a Java jobb - sőt, még azt sem, hogy nincs a C#-ban olyan feature, ami a Javaból nem hiányozna. Ellenben olyat igen, hogy a C# dinamikusabban fejlődik, s hogy sok tervezési fasságot sikerült elkerülniük, amit a Java megejtett, mondtam. Annyit mondtam, hogy van olyan, ami a C#-ban van, a Javaban nincs, és én nem is szeretnék. A fenti 5-6 példa pont olyan.
--
blogom

"A C#-os var itt milyen típus ad neki?"

Amilyen típusú értéket adsz neki a legelső helyen, olyan típusú lesz. Leginkább kényelmi szempontja van, pl. 

Dictionary<string, List<Kutyafule>> kutyafulek = new Dictionary<string, List<Kutyafule>>();

helyett egyszerűbb egy 

var kutyafulek = new Dictionary<string, List<Kutyafule>>();

".NET alatt meg tudom azt csinálni, hogy ha A lib a ZLogging 1.4-es vewrzióját akarja, s hozza magával, míg B lib a ZLogging 2.1-set (s ezek még csak API szinten sem kompatibilisek), akkor én használjam mindkettőt, s az A és B lib ne akadjon össze?"

Meg, az sem probléma, ha ugyanabban az assemblyben kell használni, lehet aliasolni a névtereket.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

„"A C#-os var itt milyen típus ad neki?" Amilyen típusú értéket adsz neki a legelső helyen”

Igen, ezt tudom - Javahoz is van, meg ennyi közöm volt C#-hoz is. A kérdésem, hogy a cikkben szereplő, 

var v = Visibility.Fullscreen | Visibility.AlwaysOnTop;

-nál mi lesz a v típusa.
Mert a mellé írt Java kód még csak nem is fordul, ezért halvány lila gőzöm nincs, hogy mire gondolt a költő.

„Meg, az sem probléma, ha ugyanabban az assemblyben kell használni, lehet aliasolni a névtereket.”
Jah ezt olvastam közben - de tegyük fel, hogy sem az A libbe, sem a B libbe nem tudok/nem akarok belenyúlni - a fenti aliasolással, ha jól sejtem, bele kéne nyúlnom a forráskódba.
--
blogom

1). Visibility. Értelem szerűen.

2). Nem kell. Amikor behúzol egy assemblyt reference-nek, akkor lehet ott adni neki aliast, különben alapból minden a global: alá kerül. De ez a saját projektedben fogja a behúzott assembly névterét "elhelyezni" valami alias alá.

Hasonló, mikor mondjuk van egy A.Foo és egy B.Foo osztályod, és az A és B névtér is usingolva van, tudsz ilyet csinálni, hogy 

using A;
using B;
using AFoo = A.Foo;
using BFoo = B.Foo;

class Bar 
{
  public AFoo A { get; set; }
  public BFoo B { get; set; }
}

(Itt ugye lehetne 

public A.Foo A { get; set; }

is, de ha sokat kell használni, nem túl kényelmes.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Jól értem, hogy C# alatt akkor ez a két sor teljesen valid: 


Visibility oneEnum = Visibility.Fullscreen;
Visibility moreEnum = Visibility.Fullscreen | Visibility.AlwaysOnTop;

Tehát, ha több enum értéket tárolok egy változóban, vagy egyet, annak ugyanaz a típusa?
Huhh, ez nekem már nagyon bitmágia.
--
blogom

Nos igen, ilyen formában az Enum valóban bitmágia, de legalább ad rá egy szép köntöst. :)

Komolyra fordítva, C#-ban az Enum-ok eleve int-ek alapból, bár kézzel meg tudod adni, hogy [s]byte, [u]short, [u]int vagy [u]long legyen. Flags tag igazából csak a ToString-et érinti.

Lehet ezt szivárgó absztrakciónak nevezni de lehet úgy is felfogni, mint egy kényelmes lehetőség.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"- property: ne. Egy szabványos @Getter/@Setter annotációt (ala Lombok) elfogadnék (hiányzik), de ami függvényhívás, annak legyen függvényhívás szintaktikája."

Ezzazzzzzz, írjunk még több kódot, mert attól karbantarthatóbb lesz minden! (Nem).

"- extension methods: ezt jól sejtem, hogy olyasmi, hogy meglévő osztályokhoz tudok saját metódosukat „beleinjektálni”? ne. Erre Verhás Péter blogját tudnám hozni - a megszokott, mindenki által ismert osztályokat ne bővítgesse senki, mert nagyon csúnya dolgok születhetnek belőle."

Szóval nem érted, hogy mire jó, de azért vérhányás. Alapvetően syntactic sugar, lehetne egy sima static class static methodja is (tulajdonképp az), viszont nézd meg a LinQ-t, hogy mit hoztak vele össze. És nem beleinjectálsz, hanem "hozzácsapod", tehát ugyanúgy nem fogsz egy megszokott osztály privát dolgait átbarmolni, mert ugyanúgy csak azt fogod látni belőle, amit egyébként is látnál.

"- dynamic type: ez mire jó? ezt találtam: MSDN - de nem értem, miért jó nekem, ha kikerülöm a compile time checket. El tudom fogadni, csak nem látom a szituációt, amikor ez hasznos lehet."

Hát... Ezt konkrétan én sem tartom a világ leghasznosabb dolgának a C#-ban, alapvetően a COM Interop miatt került bele (szerintem), viszont néha jól tud jönni, amikor amúgy is csak Reflection hegyeken keresztül dolgozna az ember. Akkor sokkal kényelmesebb lehet néha egy-egy dynamic.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

„Szóval nem érted, hogy mire jó, de azért vérhányás.”

Lombokból ismerős, és ha csak kicsit is érteni akarná bármelyikőtök, akkor rájönnétek, hogy ugyanarról beszélünk. Továbbra is tartom, hogy a linkelt blogban adott ellenpélda mögé teljes mellszélességgel be tudok állni, s szerintem inkább káros, mint hasznos. 

((String) null).or("Lóf*sz").toLowerCase())

vagy 

MyUtils.replaceIfNull(null, "Lóf*sz").toLowerCase()

Az első minden konvenciót, amit eddig használtunk, megtör - és lehet, hogy Pityuka olyan kódot írt, hogy ez mégis valid.

(igen, a két metódosnév más - de a Stringnél az utóbbi szerintem csak még kevésbé kifejező)
--
blogom

"- property: ne. Egy szabványos @Getter/@Setter annotációt (ala Lombok) elfogadnék (hiányzik), de ami függvényhívás, annak legyen függvényhívás szintaktikája."

Apropó, property és lombok és hasonlók. Lombok esetén mi van, ha refactorálni kell egy mezőt és át kell nevezni? Amennyire utánanéztem, nincs igazán neki tooltámogatása. C#-ban ez ugye elég egyértelmű.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

> Amennyire utánanéztem, nincs igazán neki tooltámogatása.

az IDEA-hoz van plugin, ami tudja - többnyire. Amit nem nevez át (és találkoztam eddig vele), azok a generált builderekben lévő metódusok.
És a val-t (C#-os var) nem kezeli mindig tökéletesen, de ez olyan ~fél éve volt. (Azóta leszoktam a valról, nem állt kézre). Néha a becachelt információk nem voltak tökéletesek, Ha kitöröltem egy karaktert, majd visszaírtam (val -> va -> val), akkor újraépítette a cache megfelelő részét, s működött tovább.

Maga a Lombok meg az AST-t taknyolja, ezért a generált bájtkódban vannak rendesen sorszámok az utasítások mellett - lehet benne debuggolni, minden egyéb nélkül. Ha a @Getter-re rakok egy breakpointot, akkor
--
blogom

Alapvetően egyetértek mindennel, én is jobbnak tartom a C#-ot a Java-nál ,de.

"Nem vagyok Java-ellenes, csak szeretnem felhivni a figyelmet arra az ecceru tenyre, hogy kurva lassan halad a nyelv fejlodes, ez ezzel azokat a fejlesztoket szopatjak, akik Javaval akarnak vagy kenytelenek dolgozni."

Igaz, bár lassan azért csak az Oracle-nél is elindult a fejlődés.
A másik, hogy Java-nál nem csak a Java nyelv fejlődésével lehet előre lépni, hanem esetleg egy másik nyelvre való átállással is. Ha pl. valaki elkezd Scala-ban programozni, akkor a Java-s library-k teljes tárházát tudja használni egy C#-nál jobb nyelven.

> a Java-s library-k teljes tárházát tudja használni egy C#-nál jobb nyelven.

Ez egyébként a Java-ökoszisztémában mennyire jellemző? Mert ilyen .NET-nél is van, de a többség akkor is C#-ozik.

A Scala mivel tud többet, mint a Java azon kívül, hogy sokkal nagyobb a hype, és az EPFL-t sokkal kevesebben tartják gonosznak, mint az Oracle-t?

"A Scala mivel tud többet, mint a Java azon kívül, hogy sokkal nagyobb a hype"

Egyáltalán nem nagyobb a hype, mint C#-nál.
Rengeteg dologban tud többet. Olvashatóbb kódok írhatók az OO esetén, mivel kevesebb boilerplate kód kell ugyanahhoz.
Az FP részéről nem is beszélve.

Szerintem kihagytad a történetből azt az "apró" tényt, hogy még mindig nincs full, gyártó által támogatott C# megoldás Windowson kívül semmire se. (Igazából másmilyen sincs.) Figyelembe véve a gyártó zsebében levő pénzmennyiséget, ennek nyilván nem technikai akadályai vannak... (gyk: csak akarni kellett volna, és lenne)

Úgyhogy a "jobb/élvezetesebb fejleszteni C#-ra" nyilván azokra vonatkozik, akik nem tartják a Windows-használatot önmagában élvezetet akadályozó tényezőnek.

Tévedés.
Az ASP.NET 5 (MVC és konzol applikáció, aminek persze nem tilos belehívnia olyan librarykbe, mint a GTK) az RC1 megjelenáse óta hivatalosan támogatott (=felhívod őket, és segítenek, nyilván pénzért) Windowson, Linuxon és MacOS-en.

Ha az úri becsületszavam nem lenne elég: Release notes README és a bejelentés

Fuszenecker Róbert

És ez elfuttat bármilyen Windows-ra készített .NET GUI vastagklienses alkalmazást, ha az csak C# kódot tartalmaz? Azaz minden .NET framework-beli lib benne van? Én nem így hallottam, de nyugodtan javíts ki. Már csak azért gyanús a dolog, mert a nevében szerepel a Core szó, ami nálam azt jelenti, hogy abban azért minden nincs benne.

Nem, a teljes framework modularizált lett (kb. mint amit a Java9-ben is terveznek), az aktuális programod tartalmazza, hogy milyen függőségei vannak. A WPF stack nem része a .NET 5-nek Linuxon/MacOS-en (talán éppen a DirectX függősége miatt). A GTK# .NET Core portjára még várni kell, amint ez meglesz, kész a cross-platform GUI framework.

Aki C#-ban szeretne desktop alkalmazást írni, használjon Windowst WPF-fel, Linuxot GTK#-pal és Monoval vagy Xamarint Androidra/MacOS-re/Windows10-re.

Egy kezdőnek szerintem teljesen mindegy, hogy WPF-ezik vagy Mono-zik GTK#-pal.
Legtöbbször egy konzol alkalmazás is elegendő.

A Monot már csak azért is tudom ajánlani, mert egy csomó dolgot átvett a MS-féle implementációból, és az elmúlt 9 évben egyetlen komoly hibát találtam benne, de azt is meg tudtam oldani.
Minden ellenkező híresztelés ellenére a Mono egy nagyon jó framework, egy kereskedelni termék is épül rá (Xamarin), de ha jobban végiggondolom, kettő az az egy...

Fuszenecker Róbert

Szerintem tökéletesen alátámasztottad azt, amit fentebb írtam: nincs teljes .NET framework gyártói támogatással Linuxra/OSX-re.
A felsorolt technológiák vagy zéró gyártói támogatással rendelkeznek, vagy nem futnak egyformán minden platformon (értsd: nem ugyanarra az API-ra kell programozni -> ebből a büdös életben nem lesz automatikusan multiplatform alkalmazás).

Hasonlóan gondolom én is.
Sokan a Scala-t is nagyon nehéznek tartják megtanulni, mert iszonyatosan sokrétű és nagy tudású.
Ha mindent meg akar valaki tanulni, akkor tényleg nem könnyű, de az alapok elsajátítás szerintem itt az egyik legkönnyebb mind az OO, mind az FP területén.

Teljesen laikusként szóltam hozzá (iskolai kemény 4 év alapozás megvan utána az egyetemen programozgattam egy keveset). Volt itt annó egy Java kurzus. Ez volt az egyedüli amin örvendtem hogy megszabadultam tőle s nem kívánkoztam jegyemelésre menni, pedig belefért volna.

Az utóbbi években találkoztam két egyszerűbb project margóján C#-al és ettől határozottan nem rázott a hideg, egész jól haladtam vele.

Van egy helyzeti előnye: jóval később keletkezett, mint a Java, így mások hibáiból is tanulhattak.

Amit a gyakorlatban tapasztaltam, hogy a learning curve sokkal barátságosabb, mint a Javáé - igaz, hogy a Java-t előbb tanultam, mint a C#-ot. Hogy maga a nyelv jobb-e, azt nem tudom. Szintakszisra majdnem ugyanaz, a Java-féle ökoszisztémát pedig jóval kevésbé ismerem, mint a .NET-est.

Szigorúan a language levelen a C# magasan veri a Java-t: https://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Java
De ez simán betudható annak hogy a Java ~10 évvel korábban született, a tudomány akkori állása szerint, és bár fejlesztik, és sokat javult, a visszafelé kompatibilitás miatt még mindig hátrányban van.
Ugyanakkor egy csomó más dolog is számít a napi munkában, amit nehéz felsorolni.

--
arch,debian,openelec,android

Ezzel a lendülettel meg lehetett volna állni az assemblynél is. Javanal meg azért nem 3 sornyi különbség van, még úgy sem, hogy a Java coding style alapvetően tömörebb, mint a C#-é.

Illetve vannak esetek, amikor kifejezetten sok, ld. delegate/eseménykezelők vs. inline implementált interfacek, mint Java alternatíva.

Nem állítom egyébként, hogy határfos a Java (hotswapra pl. még mindig írigy vagyok, edit&continue hozzá képest kényelmetlen), csak ha Javaban kell kódolnom, mindig azt érzem, hogy többet kell a "hogyan?"-nal foglalkoznom, mint a "mit kell megcsinálni?"-val.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Javanal meg azért nem 3 sornyi különbség van

Nem tudom, hogy te konkrétan milyen java kódokkal dolgoztál eddig, de nekem az az érzésem, hogy az ilyen jellegű hitviták általában az adott ökoszisztéma keretrendszereinek és library-jeinek problémáira hegyeződnek ki. A kisebb nyelvi különbségek nem gondolnám, hogy lényegesen befolyásolnák a fejlesztési időt.

vannak esetek, amikor kifejezetten sok, ld. delegate/eseménykezelők vs. inline implementált interfacek, mint Java alternatíva.

Egyrészt igazad van, másrészt a java8 sokat segített a helyzeten.

> hogy többet kell a "hogyan?"-nal foglalkoznom, mint a "mit kell megcsinálni?"-val.

Ehhez rogton tegyuk is hozza, hogy ez nem feltetlen a Java hibaja, hanem aze, hogy nem a Java az elsodlegesen hasznalt programozasi nyelved, hanem a C#. Ha a Java lenne, akkor a C#-ban foglalkoznal tobbet a "hogyan?"-nal. Nem lehetsz ket-harom-tiz programnyelven profi, megvannak a hatarok, amedddig el lehet menni.
--
Blog | @hron84
Üzemeltető macik

Azért váltogatok annyit programnyelveket, hogy fel tudjam mérni azt, hogy ha 4 féle típus van a DateTime reprezentálására, az inkább hátráltat, mintsem, hogy segít. Meg talán van annyi rutinom, hogy rákeressek/utánakérdezzek, hogy más mit szokott csinálni/mi a bevett pattern/módszer/kismacska.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

https://docs.oracle.com/javase/8/docs/api/java/time/LocalDate.html (és java8 datetime api)
https://docs.oracle.com/javase/7/docs/api/java/util/Calendar.html
https://docs.oracle.com/javase/8/docs/api/java/util/Date.html
ez kapásból három, és akkor a java.sql.*-ot ne is keverjük ide.

btw: http://hup.hu/node/134505
--
blogom

Na jó, nem az okoz lelki traumát, hogy nincs property meg a többi cucc, amit felsoroltatok, enélkül is teljesen jól lehet fejleszteni.
A lelki traumát inkább mindenféle szedett-vedett jóképességű kódjában való turkálás fogja okozni, akik jól előadva magukat összegányoltak,
mi meg lapátolhatjuk a sz@rt... na, ezt kell megfizetni :D

( h040091 | 2015. 12. 12., szo – 15:36 )

A kérdésre válaszolva: szerintem meg lehet tanulni úgy a Java-t, hogy előtte nem tudott valaki C-ben programozni. Mi olyan van C-ben, ami szükséges lenne a Java tanuláshoz? A Java alapvetően objektumorientált és a memória menedzselése automatikus, szemben a C-vel. Hogy érdemes-e Java-t tanulni, az nem függ attól, hogy előtte programozott-e valaki C-ben, vagy sem.

Nekem, így utólag visszagondolva, sokat segített előtte a fél-fél év c, c++. Mindezt egyetemen. Előtte még általános iskolában, magamtól tanultam Pascalt, de a C ott megakasztott - 14 évesen nem értettem meg a pointereket egyedül, könyvből. Valahogy a C közelebb állt a Pascalban (általam) megszokott formához, s a C-s szopások révén sikerült felfognom, hogy miért van nekünk OOP-k.

És őszintén, gőzöm nincs, hogyan lehetne másképp bevezetni az OOP-t rendesen.
--
blogom

> És őszintén, gőzöm nincs, hogyan lehetne másképp bevezetni az OOP-t rendesen.

A programozástanuláskor nem a nyelvet kell megtanulni, hanem a gondolkodásmódot, technikákat, stb.

Hogy lehet megtanulni az OOP-t? Életszerű példákon keresztül. Aztán amikor érted mi az az OOP, és érted a többi fontos fogalmat és módszert is, akkor ki lehet nyitni a "Tanuljuk meg az XY nyelvet 24 óra alatt" jellegű könyveket, és lehet kezdeni gyakorolni.

Én az OOP alapjait flipchart-tal tanítottam a hallgatóknak, nem C-vel. :)

Igazából egyszerűbb úgy megtanulni Java-ban (vagy bármely OOP nyelvben) programozni, hogy előtte nem tanul C-ül, mert csak félreviszi az embert és elkezd object[]-eket használni arra, amire értelmes ember készítene rendes osztályokat.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( Wabbitseason v | 2015. 12. 12., szo – 15:44 )

Miért kell a Javát "meg"tanulni? Kezdjen el vele kísérletezni, és majd kiderül, mennyire tetszik neki. Ártani nem fog semmiképp, sőt, nyilván annál jobb, minél több nyelvet, frameworköt és gondolkodásmódot ismer meg, mert annál kevésbé akarja majd egy kaptafára megoldani a feladatait anélkül, hogy igazán tudná, értené (grokkolná), hogy mit akar megvalósítani.

( norbertkiss | 2015. 12. 12., szo – 15:49 )

Nekem az első programnyelv a Java volt. A C-t csak később tanultam, úgyhogy lehet c nélkül javat tanulni.

( Replaced | 2015. 12. 12., szo – 17:02 )

mivel a java nyelvnek semmi koze nincs a c-hez, ezert mindegy :-)

--
NetBSD - Simplicity is prerequisite for reliability

( digger86 | 2015. 12. 12., szo – 17:29 )

... és mostanában eljutott olyan problémákhoz, amiket Java-ban sokkal egyszerűbb megoldani, mint Pascal-ban.

Mint például?

( flimo | 2015. 12. 12., szo – 19:52 )

Ha a cel az, hogy java-t megtanulja, akkor a c felesleges idopazarlas, mitobb az "agyi atallas" miatt a raforditott idonel is nagyobb hatraltato tenyezo lesz, amikor vegul elkezd javazni.

( crystal88 | 2015. 12. 12., szo – 19:54 )

Mennyi idős a srác?
Én amúgy 17 évesen (2006ban) kezdtem java-ban programozni, egy - így utólag visszatekintve - borzasztóan felületes 24órás könyvből, előtte pascal meg vb6 "tapasztalatom" volt. Végülis boldogultam vele egyedül, szűk 1 évvel később már egész jól ment a beadandóírás-biznisz egyetemistáknak :)

( zsoltt | 2015. 12. 12., szo – 23:09 )

Kotlin! https://kotlinlang.org

A Java rengeteg elvi hibája ki van küszöbölve (értsd: teljesen fölösleges szenvedéstől kímélheti meg magát). Másrészről viszont nagyon hasonlít Javara, alkalmazhatósága is ugyanaz.

Bár ha még nem lett "elrontva" OOP-vel, és kísérletező kedvű, valamint szeret elmélyedni, akkor a Haskell -en is erősen elgondolkoznék... https://www.haskell.org

( xclusiv v | 2015. 12. 12., szo – 23:14 )

"Még nem profi, de elég jól halad, és mostanában eljutott olyan problémákhoz, amiket Java-ban sokkal egyszerűbb megoldani, mint Pascal-ban."

És?
A programozás meegtanulása a cél, az algoritmusok megértéséhez pedig szerintem jó a Pascal, talán még jobb is mint a java. Egy láncolt listát vagy egy bináris keresést szerintem még jobb is ha Pascal-ban (vagy más, földhözragadtabb) nyelven tanul meg, mint ha csak annyit csinálna, hogy 

LinkedList l = new LinkedList();
ll.add("alma");
ll.remove("alma");
ll.add("sör");

Háát.
Nekem a (C=+4) BASIC után a Pascal volt az első nyelvem. Csupa rossz emlék fűz hozzá. Nem hiszem, hogy megérte.
A C a Pascalhoz képest örömmámor volt. Igazából a Pascalhoz képest a PHP -t leszámítva bármi más örömmámor volt.
Értem amit mondasz, értsük meg az alapokat, ez jogos, én ennek ellenére sem gondolnám hogy Pascalnál kéne maradni.

Amúgy meg csinálja azt ami leginkább fun :)

Én is plus4 basic után kezdtem a pascal-t, és azóta sincs vele semmi bajom. Sőt, kifejezetten kellemesnek tartom a mai napig is, már persze a maga módján, mert eléggé elszállt fölötte az idő. Ebben bevallottan a "régen minden jobb volt" is benne van. A PHP-val sincs sok bajom, csak annál is tudni kell, hogy mire is célszerű használni és mik a hülyeségei.

Én azért mondom, hogy maradjon a pascal-nál, mert abban van benne, azt ismeri. És ez pont megfelelő arra, hogy algoritmusokat tanuljon meg, értsen meg, és legyen sikerélménye a programozásban.
Ha most "félúton" átáll egy másik nyelvre, mondjuk a C-re, akkor sokáig csak a szopófaktor jön majd neki. Mert nyilván a hello world-től kell majd azt kezdenie, szóval érdemben jó ideig nem fog haladni, még ha gyorsabban is tud a pascal-os múltjával haladni mint egy kezdő programozó. Viszont szembejönnek majd az sprintf típusú szépségek, amik lehet hogy elveszik a kedvét az egésztől.

> talán még jobb is mint a java

erre +1, bár lehet, én C-t erőltetnék helyette.
De a másik oldal meg, hogy ez lehet, keményen elveszi valaki motivációját, hogy újra feltalálja a kereket. Rövid távon nem hiszem, hogy bárki élvezné a programozást, ha nagyon egyszerű feladatokat old meg, nagyon bonyolultan (láncolt listában lévő számokat rendez, például) - de hosszútávon mindenféleképpen hasznos, s kihagyhatatlan ez a tudás, szerintem.
--
blogom

Ez a kommentem válasz Neked is, hogy én miért nem erőltetnék más nyelvet.

Persze kérdés az, hogy hol tart a programozásban. Ha az add meg az "első számot / add meg a második számot / add meg a matematikai műveletet / íme az eredmény" szinten, akkor viszonylag fájdalommentes is lehet a váltás.
Ha mondjuk láncolt listás "adatbáziskezelőt" saját formátumú file-ban, akkor szerintem inkább nem. Akkor menjen amíg tart az út, aztán váltson.

És érdemes megnézni azt is, hogy mit érdemes pascal-ban kihagyni, mert pl. a konzolos 80x25-ös "gui-s" dolgok teljesen fölöslegesek. (Amikor én tanultam még nem volt az.)

( dejo v | 2015. 12. 13., v – 09:51 )

Nincs fölösleges tudás. Tehát ebből a szempontból bármilyen nyelv megtanulása hasznos.
A Java azért is jó, mert egy alap a C++ tanuláshoz. Ugyanis ez kétirányú út. A szerkezeti és logikai hasonlóság miatt az egyik ismerete segíti a máik megtanulását. Szóval így mindegy melyik az első.
A Python pedig bár részben más logika mentén épül fel, elég sokoldalú és rugalmas nyelv. Ráadásul szerintem könnyebben tanulható.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

( sigellef | 2015. 12. 13., v – 17:58 )

Szerintem jó, ha a lehető legtöbb nyelven megtanulja az alapvető dolgokat.
pl. elágazás, ciklusok, eljáráshívás, I/O, ... stb...
Továbbá megtanítani vele, hogy melyik nyelv mire jó.
Ha a srác "veszi a lapot", én a C, C++-ra irányítanám a figyelmét.
Ügyelni rá, hogy nagyon ne menjen mélyen a Pascal-ba, mert annál nehezebben lesz képes új nyelvet megtanulni.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

Jó volna, ha minél több nyelv lenne a listán, ezért is kezdtem rákeresni, hogy mi az a sok, pl. nem-e került be véletlenül a Scala :)
Ha igazad van (egyáltalán nem kételkedem ebben), és korábban tényleg több nyelv volt, akkor viszont szomorú, hogy egyre szűkül a lista, ahelyett, hogy bővülne.

6 vs 25 között azért van egy pár lehetőség. Vegyük mondjuk a HUP 10 legnépszerűbbjét.

Ha pl. csak Linuxon lenne elérhető több nyelv, akkor egy iso előállítása nem több 1 óránál, mindenféle tesztekkel is 1-2 nap alatt megvan.

Egyedül az automata tesztelő programokat kell egy-egy nyelvhez egyszer megcsinálni.

Automata tesztek vannak, miért tartana tovább, mint most?

Milyen tanárokat kellene pluszban oktatni?

"Ügyelni rá, hogy nagyon ne menjen mélyen a Pascal-ba, mert annál nehezebben lesz képes új nyelvet megtanulni."

Ez jó! :)
Ismerek pár embert, aki vagy nem volt képes megtanulni más nyelvet, vagy kénytelen volt ugyan, de azóta is szidja a többit (pl. C/C++), és nosztalgiázva isteníti a Pascal-t. Természetesen emiatt nem is kódol jól más nyelven.

( ssikiss | 2015. 12. 14., h – 08:49 )

Mik a célok a prog.nyelv tanulással? "Profivá" szeretne válni?

Szerintem azt az általános célú programozási nyelvet kellene elsőre tanulnia, amiben a legtöbbet tudsz te, haverok, szakkör vagy tanár segíteni neki.

( hrgy84 | 2015. 12. 14., h – 14:12 )

Meg lehet tanulni. Bar az en programozashoz valo hozzaertesemet sokan fogjak itt megkerdojelezni, de azt bizton allithatom, hogy eligazodok Java-ban C-ben, C++-ban, barmiben, ha profin kodolni nem is tudok ezeken a nyelveken. A Java az nekem VisualBasic/VisualBasic.NET utan jott, mindenfele C-szintaxisu nyelvet a Java utan kezdtem el megtanulni. Ha erdekel, van jo konyvem, emlekeim szeritn vallalhato allapotban van, el tudom kuldeni.
--
Blog | @hron84
Üzemeltető macik