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.AlwaysOnTopdolgot 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