Már Androidra is lehet fejleszteni a Ceylon legújabb verziójával
2016-09-21T11:09:41+02:00
2016-10-28T16:17:22+02:00
2022-07-19T03:26:56+02:00
  • 09.28. 09:28

    Nagyon laza!
    (Azt inkább senki se kérdezze meg, hogy miért találtam most úgy 15 darab 1 hónapos tabot az egyik böngészőablakomban - én sem tudom)
    Mutasd a teljes hozzászólást!
  • Egy idealis vilagban nincs tobb millio haszontalan app es vagy jatek a google playen.
    Mutasd a teljes hozzászólást!
  • Semmi nem olyan király, mint egy olyan projekt ahol a kód jó része a különféle string osztályok konverziójáról szól. Ráadásul C++-nál is ugyanúgy különféle libeket húzol be, csak ott nem nugettel. De nézd meg Pl. az urho3d-t, hány külső libet használ a különféle feladatok megoldására. És ez így van jól: nem kell minden feladatnál feltalálni a melegvizet.
    Mutasd a teljes hozzászólást!
  • Kb. ugyanaz a pokol, mint ami a C++-nál van, ahol minden sarokban van egy framework saját string osztállyal, plusz ott a jó standard library a saját string osztállyal, ugyanakkor persze az egész egy jó nagy pofon a kakinak: a stringet mint olyat anno nyelvi szinten kellett volna megoldani mint minden más programnyelvnél kivéve a sima C-t, ami ha lehet még gázosabb ebből a szempontból

    Írsz egy LCString osztályt, ami azt a 2-3 másikat tudja fogadni és konvertálni. Ha ennyin elakadsz, akkor hogyan írsz meg egy bonyolultabb architektúrát? Az a baj, hogy teljesen elkényelmesedtek a mai fejlesztők, minden kis csip-csup dologhoz azonnal frameworkök tucatják kezdik letölteni, mintha attól egyszerűsödne a fejlesztés. Láttam már olyan projectet is, ahol 100-nál is több Nuget package volt a projecthez csapva, óriási élmény volt ezeket végig tanulmányozni (aminknek kb. fejenként a 10%-át se használták ki) és javítani a bugokat, ahelyett, hogy írtak volna pár saját osztályt.
    Mutasd a teljes hozzászólást!
  • En sajnos nem elek idealis vilagban. :)

    Amugy a fejlodest pont ez a diverzitas viszi elore a vilag osszes teruleten. :)
    Mutasd a teljes hozzászólást!
  • Ha így nézed, a .NET core is egy implementáció, a mono pedig egy másik. 

    De egy ideális világban felesleges a kettő, az egyiket kell jól megcsinálni. A sok párhuzamos megoldás nem tesz jót az ökoszisztémának. Ráadásul az sem baj, ha ezek egy kézben vannak összefogva. Így Pl. a Linq a .NET alatt olyan általános megoldássá tudott válni, amit ugyanúgy tudsz használni adatbázisokon mint tömbökön, xml-eken vagy bármin amire providert ír valaki. Ezzel szemben javán mindenki megcsinálja a maga picit távolról hasonlító megoldását, de egyik sem lesz általános, és egyik sem lesz kompatibilis a másikkal.
    Kb. ugyanaz a pokol, mint ami a C++-nál van, ahol minden sarokban van egy framework saját string osztállyal, plusz ott a jó standard library a saját string osztállyal, ugyanakkor persze az egész egy jó nagy pofon a kakinak: a stringet mint olyat anno nyelvi szinten kellett volna megoldani mint minden más programnyelvnél kivéve a sima C-t, ami ha lehet még gázosabb ebből a szempontból.
    Mutasd a teljes hozzászólást!
  • Mert ha használod, akkor máris függesz az adott verziótól

    most leirtad ugyanazt amit en is korabban. :)
    1, nem muszaj hasznalni, de ha hasznalod is, meg mindig kevesebb modositassal jar, mint ha nem lenne kozos resz sem. Rad van bizva, hogy adott Feature neked mennyit er.
    2, gondolhatod, h nem tok ugyanaz az implementacio, azaz vannak elonyok-hatranyok az adott implementaciokban.
    3, meg egyszer elmondom, ezek a featur-ok is segitik a fejlesztest, hisz ezekbol kerulnek be uj dolgok. Azaz lehet kesobb standardak lesznek.

    Mivel nyílt a forráskód, ugyanúgy létezik, mint maga a java ha egyszer az Oracle úgy dönt, hogy nem tesz több pénzt a fejlesztésébe.

    Ha az Oracle ugy dontene, meg evtizedekig futnanak a Java fejlesztesek. A .Net-nel meg csak most van kialakuloban ez az okoszisztema, es meg a platformfuggetlenseg is olyan amilyen.
    Mutasd a teljes hozzászólást!
  • Viszont nagyon sok feature-t is implementálnak a standard felett pluszban. Ez miért baj?

    Mert ha használod, akkor máris függesz az adott verziótól. A közös rész újra implementálása viszont felesleges.

    Míg az MS gondolt egyet, aztán már adott technológia nem is létezik. :)

    Mivel nyílt a forráskód, ugyanúgy létezik, mint maga a java ha egyszer az Oracle úgy dönt, hogy nem tesz több pénzt a fejlesztésébe.

    Tudom. Mióta is? Meg vajon miért?

    Pár éve. És ugyanazért, amiért a java is.
    Mutasd a teljes hozzászólást!
  • Elolvastad amit írtam? Megvan, hogy bizonyos java alapú technológiáknak azonos az alapja? Azaz, ha JPA-t használsz csak, akkor szinte bármelyik vendor által készített implementációt használhatod. Ugyanez igaz a JEE szerverekre, JAX-RS, JAX-WS, JSR-303, plusz sok JSR-ra... Viszont nagyon sok feature-t is implementálnak a standard felett pluszban. Ez miért baj? pont ezért találnak a cégek is megfelelő embert, mert azt mondják, hogy érts a JEE-hez. Amit az adott környezet meg felette kínál, azt megtanulod, és megkönnyítheti a munkád. Ellenben nem biztos, h trivi lesz másik app szerverre átállni, mert az meg lehet más feature-t ad.

    Aztán probléma lehet az is, hogy ha elindulsz egy adott dologgal, aztán 10 év múlva már a kutya sem foglalkozik a dologgal mert a másik 9 framework valamelyike nyert, akkor bizony kezdheted újraírni az egészet.

    Pont ezért nem lesz ezzel gond, mint amit fentebb leírtam. Pont a közös specifikáció miatt tudsz adott framework-öt/szervert lecserélni. Míg az MS gondolt egyet, aztán már adott technológia nem is létezik. :)

    A .NET forráskódja is nyílt.

    Tudom. Mióta is? Meg vajon miért?
    Mutasd a teljes hozzászólást!
  • Őszintén szólva ezzel még nem találkozam. De ahogy elnézem, megy nuget-tel is.
    Mutasd a teljes hozzászólást!
  • A .NET forráskódja is nyílt. Az pedig, hogy egy feladatra van X különféle megoldás azt jelenti, hogy valaki vagy ismeri mindegyiket (ami valószínűtlen, legalábbis kellő mélységben) vagy keresnie kell olyan céget, ami pont azt használja amit ő tud - azaz a lehetőségei jelentősen beszűkülnek. A másik oldalon ugyanez van a cégeknél is: ők is kisebb felhozatalból tudnak munkaerőt választani. Aztán probléma lehet az is, hogy ha elindulsz egy adott dologgal, aztán 10 év múlva már a kutya sem foglalkozik a dologgal mert a másik 9 framework valamelyike nyert, akkor bizony kezdheted újraírni az egészet. Márpedig a java egyik legfontosabb előnye, hogy nem kell az alkalmazást újraírni.

    Ezért nem igazán látom át, miért jó a több párhuzamos megoldás.
    Mutasd a teljes hozzászólást!
  • Miert jo ez? Ez komoly kerdes? Pont ez a jo benne szvsz.

    En javaban, androidban inkabb a kozosseg hatalmat szeretem. Barmikor irhatok androidban egy egyedi controllt, felrakom bintrayre es masnap barki tudja dependenciesbe rakni es hasznalni pl. 

    Bar igaz nem astam bele magam melyebben a c#- be, de arrol se mondanam, h s.ar.
    Mutasd a teljes hozzászólást!
  • És az miért is jó, hogy egy feladatra van 20 párhuzamos framework ?

    1, Mindegyiknek megvan az erossege/gyengesege. Feladathoz tudsz valasztani frameworkot.
    2, a legfontosabb fejlesztesek ugy szoktak tortenni Java haza tajan, hogy elobb specifikalnak, elfogadjak, keszitenek egy API-t, ref. implementaciot -> ezert is bun lassu. A spec./API meg arra jo, hogy kulonbozo vendorok implementalhatjak kvazi ugyanazt. Azaz a specnek mindegyiknek meg kell felelnie es mellette plusz feature-ket is adhatnak hozza. Ez pl. azert jo, mert mas-mas otleteket adhatnak az elore definialt funkciokhoz. Ezekbol az otletekbol meg kialakulhat a kovetkezo verzionak az API-ja, specifikacioja, mint egy uj Standard.
    3, nem unsz bele egybe

    Az MS-nel ez meg ugy van, ha a fejleszto mindent keszen kap, hasznalja. Nagyon egy kezben van. Ha javaban egy JSF/JPA vendor bedobja a torolkozot, akkor viszonylag "kis" fajdalmak aran at lehet terni egy masikra. De ugyanez igaz az alkalmazas szerverekre is. En latom elonyet ennek a modszernek es nekem jobban is tetszik, mint az MS fele centralizalt modszer. Igen, tudom, h nyitott az MS is, de meg igy is nagyon kereteken belul mozog.
    Mutasd a teljes hozzászólást!
  • Biztos nem rossz. A kérdés, h hány alternatívája van? Mert ugye a springnek, hibernatenek javan belül millió+1. És ugye én erről beszéltem.

    És az  miért is jó, hogy egy feladatra van 20 párhuzamos framework ? Lásd PHP és vidéke...
    Mutasd a teljes hozzászólást!
  • Engem személy szerint nem zavar, hogy nem kell a "választékban elveszni" 

    Vagyis az erőforrások nagy része egy irányba összpontosul (tudom a versengés is előny, de a nyilt forrás felé fordulással az egy vezér termék irány sem lehet zsákutcás, az igényeket nem figyelembe vevő megoldás).

    Pl. az EF lefedi igényeim 90-95%-át.
    Ami hiányzott nekem, arra találtam microORM-es megoldást és a még mindig megmaradó 1%-nyi spéci igényemre írtam saját megoldást. (erősen, kézzel kioptimalizált SQL select parancsból generált osztály, amiben az SQL futtatása történik, csak where szintű runtime módosítással és az eredmény PoCo-ba írása, visszaadása)
    Mutasd a teljes hozzászólást!
  • Nem csak Hibernate van. Sőt, eleve JPA implementációból van vagy 10 wikipedia szerint is (és mindnek más feature van a JPA-n felül, stb.). De ha linq-hoz hasonló megoldásokat is keresünk, vannak megoldások:
    jinq
    jooq
    stb.

    A spring-et nem ismerem, viszont az ASP.NET MVC szintén nem rossz cucc.

    Biztos nem rossz. A kérdés, h hány alternatívája van? Mert ugye a springnek, hibernatenek javan belül millió+1. És ugye én erről beszéltem.
    Mutasd a teljes hozzászólást!
  • Azért ezek is elég bátor kijelentések. Klassz dolog Pl. a Hibernate és a Criteria API, de azért az Entity Framework + Linq kombó szerintem valamivel szerencsésebb csillagzat alatt született. A spring-et nem ismerem, viszont az ASP.NET MVC szintén nem rossz cucc.
    Mutasd a teljes hozzászólást!
  • Amennyivel a nyelv fejlettebb, a rá épülő ökoszisztéma annyival nagyobb hátrányban van, nem beszélve a támogatottságról. Ill. azért vannak területek, pl. big data, ahol a .Net-es megoldások tudtommal hátrányban vannak.
    Itt köszön az első pont vissza, h a nyelvet mivel az MS fejleszti, gyorsabban fejlődik, de épp emiatt bizonyos megoldások pont emiatt később is jelennek meg rá.
    Mutasd a teljes hozzászólást!
  • Nyilvan az alap dolgokra jo ez, de mint irtam prora mar nem.

    Ez azért elég bátor kijelentés, miszerint a C# (.Net) köré ne épült volna professzionális világ 
    Mutasd a teljes hozzászólást!
  • Nyilvan az alap dolgokra jo ez, de mint irtam prora mar nem. 
    Ilyen tucatalkalmazasokra kb akarmi jo lehet...

    Unityben viszont c# ezek, holott a js t is szeretem. Jatekra kimondottad jo pl a nyelv. Es ahogy mondod is banki sw csakis java. Github libraryk, maven, jcenter, community...
    Mutasd a teljes hozzászólást!
  • A C# már most is java gyilkos, elvégre az üzleti alkalmazások területén azért elég szép területet hasított ki magának úgy is, hogy csak windows platformon létezett.
    Ezt pedig azért tudta megtenni, mert bár hivatalosan tényleg csak windows platformon létezett, de a microsoft jó sok erőforrást beletett a C# és a .NET fejlesztésébe. A javát viszont inkább a community fejlesztette, ez utóbbi viszont a nyelv szintaktikáján - ami már a tervezésekor is erősen túlhaladott volt - nemigen tudott segíteni. Ezért születtek az alternatív nyelvek, amik viszont komoly ipari támogatottság nélkül nemigen tudnak labdába rúgni. Hiába csinál Gipsz Jakabka java-gyilkos nyelvet, az a bank ami azért állt át javára hogy 10000 évig ne kelljen újraírni a programját nem fog váltani.

    Mondjuk az android platformon, ahol azért nem az örökkévalóságnak készülnek a programok, még lehetne esélye egy ilyen "java-gyilkos" nyelvnek, csak hát ott ott a C# is, és azt azért elég nehéz lenne beérni.
    Mutasd a teljes hozzászólást!
  • Reálisan a legvalószínűbb java gyilkos nyelv a C# lehet majd.
    Ha valóban megcsinálják multiplatformra (azért folyamatban van a dolog), akkor van esélye.
    A többinél nem látom ennek esélyét, a nagy elterjedtséget, a komoly hátteret.
    Mutasd a teljes hozzászólást!
  • Nincs valami kedvezmény, hogy aki telepít négy java-gyilkos nyelvet (illetve nyelvhez fordítót), az az ötödiket ingyen kapja?
    Mutasd a teljes hozzászólást!
  • +1. Egy pontig jok ezek a crossplatform f.sok, de amint pro dolgokra kell mar nem. Mellesleg a libek javaban vannak irva, a legtobb custom cucc is, ami fent van githubon pl. Neha meg azok sem 100% osak, mert azokat is at kell irni, refaktoralni... 

    Es akkor bonyolultabb dolgokrol, amihez esetleg workaround is kell, ne is almodj...
    Mutasd a teljes hozzászólást!
  • Én ismerem a Xamarin-t. Két olyan céggel is dolgoztam, akik kizárólag Xamarinnal fejlesztettek, egészen addig, amíg előjöttek a hiányosságai, amik nem a kezdő szinten jönnek el. Én személyesen nem értek a Xamarinhoz, pont azért dolgoztam ezekkel a cégekkel, mert én natív megoldásokkal foglalkozom.
    Mutasd a teljes hozzászólást!
  • A xamarinban az a szép, hogy simán elérheted vele a droidos API-kat is. Ugyanolyan bytekódot fordít mint a java bytekódból a dex. Plusz hozzácsap némi plusz API-t ami megkönnyíti az életedet, Pl. linq, illetve biztosít közös GUI-t, bár azzal állítólag tényleg vannak szívások. De semmi sem akadályoz meg abban, hogy az eredeti droidos API-t használd, sőt felülettervező is van a droidos GUI-hoz is.
    Mutasd a teljes hozzászólást!
  • Igen, aztán sz*p*s, mikor rájössz, cross-platform dolgok egy szinten megállnak. Persze az nem az x+1. kilistázom-rákattintok app lesz, de előbb utóbb minden cég, aki kizárólag cross-platform megoldásokkal kezd, szembesül ezzel a problémával.
    Mutasd a teljes hozzászólást!
  • Mi olyan van a javában amit nem tud a C# ?
    Mutasd a teljes hozzászólást!
  • Nem feltetlen, es te a Javaet?:D
    Mutasd a teljes hozzászólást!
  • Biztos, hogy a C# összes lehetőségét láttad és használtad ? Linq, var, nullable típusok, stb ?
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd