Miguel de Icaza: A Microsoft megnyitja a .NET-et

Microsoft, Windows

Miguel de Icaza szerint Scott Guthrie, a Microsoft Cloud és Enterprise divízióinak operatív ügyekért felelős alelnöke ma bejelentette, hogy megnyitják a .NET-et. Ráadásul MIT licenc alatt. Icaza szerint nem csak a kódot adja ki a Microsoft ez alatt a megengedő licenc alatt, de szabadalmi ígéretet is ad mellé.

A kód megtalálható a .NET Foundation GitHub tárolójában: github.com/dotnet

További részletek Miguel blogjában.

( beatnull | 2014. 11. 12., sze – 20:44 )

április 1 eltolódott volna?

[insert line here]
B.C. 3500 - DIY Vehicle / A.D. 30 - DIY Religion / A.D. 1991 - DIY OS

Gyakorlatilag a Microsoft a maga részéről kukázza a .NET-et és a közösségre bízza a jövőjét. Mindegy... így is értékelhető, hogy legalább kiadták a forráskódot, habár ezzel maguk is költséget takarítanak meg.
A szabadalmi ígéretet majd érdemes lesz jól átolvasni, mert a kódnyitásnak az a valódi sarokköve.

+1

A nyílt forráskód mindig jobb, kivéve, ha a Microsoft nyitja meg, értem? Ez a lépés kb. annyira jelenti a .NET kukázását, mint ahogy a Google kukázza az Androidot már évek óta. Magyarul semennyire. Attól, hogy az Android történetesen open source, érdemben ugyanúgy a Google fejleszti.

Na, megpróbáltam egy (főleg) SMTP-szerverként üzemelő gépről leszedni a .NET feature-t, a függőségi lánc miatt többek között ezek borulnának:
- maga az SMTP feature, és ennek minden grafikus admin felülete
- a Server Manager és a teljes Graphical Shell
- az IIS (ez rejtély, miért van fent az SMTP szerveren, de biztosan van oka - tehát nem, PHP-t sem futtatsz .NET nélkül)
- a PowerShell

Lehet, hogy a függőség (mint a Linuxnál) nem a legjobb szó rá, -- tény, hogy nem szakmám sem a szerverek üzemeltetése, sem az oprendszerek felépítésének vizsgálata -- de elég találó, ha azt nézzük, hogy a fenti feature-ök szükséges feltétele a .NET feature telepítése.

Értem.

Adott a Windows egy komponense (gy.k. nem 3rd party cucc, hanem egy olyan valami, amit vezérlőpultból egy checkbox bekattintásával tudsz telepíteni), ami legyen X. Ha X-et telepíted, akkor magával húz egy frameworköt/library-t/nevezd ahogy akarod, Y-t. Ha időközben Y-t megpróbálod törölni, X is menni fog vele a kukába.

A gyengébbek kedvéért még egyszer: X nem egy különálló szoftver. Nem töltheted le egy weboldalról. Nem veheted meg. Az oprendszer része, és mint olyan, az Add features and roles menüből telepíthető.

Kérlek, mesélj még arról, hogy a Windows nem épít a .NET-re. És megint, hátha most sikerül megértened: ha egy szoftverben vannak .NET-es komponensek, még nem szükségszerű, hogy 100%-ban menedzselt kódból álljon.

Eleve nem is tudom, miért vitatkozom veled már megint, mikor mindig az a forgatókönyv, hogy írok valamit, te nem tudsz érdemben belekötni, ezért bedobsz valami személyeskedő szart minden szakmai tartalom nélkül, én meg ráharapok a csalira. Ez utóbbi mondjuk tényleg az én hibám.

Felőlem folytathatjuk, de annak az a feltétele, hogy a következő kommentedben _érvekkel_alátámasztva_ _megcáfold_ azt, amit írtam. Azaz hogy a Windows komponensek jelentős része, és amúgy sok más Microsoft termék nagyon is használja a .NET-et, amit így nem igazán lehet kukázni.

Felőlem folytathatjuk, de annak az a feltétele, hogy a következő kommentedben _érvekkel_alátámasztva_ _megcáfold_ azt, amit írtam.

Amit művelsz, az csak trollkodás, amit azonnal elkezdesz, ha észreveszed egy threadben a "Microsoft" sztringet, de érdemben nem tudsz hozzászólni.

Látok ebben némi logikai bukfencet, mert egyrészt nem is igazán volt szövegkörnyezet, másrészt ott virít a URL-ben, hogy gabucino.

Na mindegy, amúgy engem nem szórakoztat ez a vita, és nem is nagyon szólnék már hozzá, ha nem muszáj, úgyhogy az utolsó posztommal szeretném megragadni az alkalmat, hogy bocsánatot kérjek, amiért az autizmusoddal viccelődtem, ez genyó dolog volt részemről, igyekszem többet nem elkövetni.

Ha gondolod, a szakmailag megalapozott ellenérveidet küldd el privátban, megígérem, nem fogok kötözködni. Jobb esetben egy köszönömöt küldök rá vissza, rosszabb esetben semmit, de nem fogok sem szarkasztikus beszólásokat, sem kritikákat megfogalmazni.

Fogyok kedvéért Windows: NT kernel + fuggvenykonyvtarak, API-k, Frameworkok + felhasználói környezet + mellékelt es/vagy opcionális szoftverek csomagja. Utobbiak szep szammal van .NET kod, ergo a Windows,reszben .NET-re épülnek. Es mivel a Windows resze...

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

( vilmos.nagy | 2014. 11. 12., sze – 20:48 )

Mintha Balássy György blogjában már olvastam volna, de nem találom most a posztot.

Ez azt jelenti, hogy desktop appok is zökkenőmentesen futtathatóak lesznek akár Linux alól?
Várható, hogy a Xamarin is enyhül?

Mennyiben „árt” ez hosszútávon a Java-nak?
--
blogom

( Turion | 2014. 11. 12., sze – 20:50 )

Ez most... akkor valami forradalmi bejelentés?

Linux Mint 17 "Qiana" x86_64 /w Cinnamon

( trey | 2014. 11. 12., sze – 21:14 )

"Microsoft is also releasing a new, full-featured version of Visual Studio 2013 that will be available at no cost to independent developers, students, small companies and others not making enterprise applications.

And the company is releasing a preview of Visual Studio 2015 and .NET 2015 with new features for building applications that run on platforms including Windows, Linux, iOS and Android."

Részletek itt.

--
trey @ gépház

( anr | 2014. 11. 12., sze – 21:23 )

Ez azg jelenti, hogy lemondtak rola, mint lehetseges penzkereseti lehetosegrol.
De teljesen kidobni nem akartak, hat kitettek a netre.

--
Live free, or I f'ing kill you.

"The shift that’s happening here is Visual Studio is basically going freemium. Microsoft has now built a set of online tools around Visual Studio Online (which is also getting a number of updates today) that it believes people will pay for. The Visual Studio IDE is now the gateway into the rest of that ecosystem and the more developers Microsoft can get onto that platform, the more will also want to use the rest of the company’s (paid) toolset through subscriptions to MSDN and other channels."

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

Ez csak annyiból tévedés, hogy a VS továbbra sincs ingyen. Öt főnél kisebb cégek (üzleti tevékenység esetén, de vannak kivételek), open source projektek, stb. használhatják csak.

Ha van egy fejlesztő céged, is nem elég a VS Express (ami elég valószínű), akkor bizony perkálni kell.

Nem éppen. Az oka az, hogy mobil platformon csöppet le vannak maradva, a fejlesztők jelentős része ezért nem is csinálja meg külön az appját ms mobilokra.
Ergo ha a keretrendszerük minden mosógépen képes lenne futni, akkor jelentős esélyük lenne arra, hogy egy fejlesztő abban írja meg a csodafingósappját, mert csak egyszer kell dolgozni vele és voálá, fut androidon, iosen, windowson (desktop és mobil), meg a mosógépen is.
Ez nem kukázás, ez egy egyszerű üzlet stratégiai lépés. Az elgondolás remek, a végeredményt majd meglátjuk, bejön-e nekik.

( dap | 2014. 11. 13., cs – 00:05 )

WAT? MS product a github-on? Egy alternatív dimenzióba kerültem?? :)

( kohinoor | 2014. 11. 13., cs – 06:32 )

like :) bash helyett powershell xD

( nevergone v | 2014. 11. 13., cs – 08:25 )

És a Mono?

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
Szerinted…

"We have a project underway that already does this. We are replacing chunks of Mono code that was either incomplete, buggy, or not as fully featured as it should be with Microsoft's code."

Remélem, lesz végre Monoban rendes WCF támogatás.

"Like we did in the past with .NET code that Microsoft open sourced, and like we did with Roslyn, we are going to be integrating this code into Mono and Xamarin's products."

Fuszenecker_Róbert

( Som-Som | 2014. 11. 13., cs – 08:27 )

Bevallom, a .Nethez nem (/sem) értek. Miben jobb ez, mint JVM-re Scalaban fejleszteni?

Szándékosan mostam össze őket, de teljesen jogos. Szóval ha jól értem, a .NET megnyitásával vannak olyan platformfüggetlenül és szabadon elérhető dolgok, amiket a Scala nyelvi szinten nyújt? Pl. a .NET Parallel LINQ vs. Scala Parallel Collections. De mi van a Scala üzenetküldéssel?

A scala is sok mindent a scala standard libraryn keresztül nyújt, ami használhatatlan lenne a scala nyelv nélkül. Ugyanez a helyzet a linq-kel is, nyelvi támogatás nélkül nem sokat ér. Ugyanígy, a ssl a jvm-re épül, a linq a .net-re, így ahol ezek a frameworkök elérhetőek, ott használhatóak. Attól, hogy megnyitották a .net forrását, még nem érhető el a mostaninál több platformon, illetve a scala feature-jei is csak ott, ahol van jvm.

Pár hónapja ezt mondtam volna, hogy ugyanaz a cég ad oprendszert, adatbáziskezelőt, fejlesztőeszközöket, webszervert, stb. és ezek teljesen jól együttműködnek egymással. Ha nem szereted az oroszrulettet, könnyen összeválogathatod a szoftvereidet.

A Xamarin egy kicsit tovább árnyalja a képet, de ők a mobil technológia profijai.

Nehéz megmondani, hogy az MS mostani döntése hogyan befolyásolja a platformot. Az is lehet, hogy a BSD-khez hasonló katedrális modellhez vezet majd az út. Talán ez lenne a legjobb.
De az is lehet, hogy a mostani termékeit leváltja majd sok-sok opensource megoldás, és ugyanaz az őskáosz jellemzi majd, mint... inkább nem írom le :-)

Fuszenecker_Róbert

A C# (és bizonyos feladatok esetében a Managed C++), mint nyelv két érdekes előnnyel rendelkezik szerintem, nem a Scala-val szemben, hanem úgy általában. Az egyik, hogy nincs túl nagy múltja, ami lehetővé teszi, hogy ne foglalkozzon bizonyos archaikus és idegesítő dolgokkal. Ettől kompaktabb, áttekinthetőbb lesz, mint a többiek. A másik, hogy vannak olyan feature-ök, amelyek más nyelvekben nem, vagy bonyolultabban, bénábban implementáltak. Ilyen pl. a LINQ.

A CLR vs. JVM esetében is hasonló a helyzet, de itt én úgy látom, hogy a JVM némi előnyben van, éppen a kora, kiforrottsága miatt.

Meg van még egy szempont, amit nem említettél, és az a rendszereket körülvevő "ecosystem" - ebben a Java és környéke fényévekkel vezet a .NET és környéke előtt. Szerintem a mostani lépés a nyitás irányába pont ezen a hátrányon fog javítani.

Mérsékelt izgatottsággal várom a fejleményeket :-)

C++/CLR az nekem inkább amolyan ragasztónyelvnek tűnik, hasonlóan, mint ahogy az Applenál is volt Objective-C++. Jól lehet vele összetaknyolni a natív C, C++ és a menedzselt kódot, illetve wrapperekre, adapterekre a natív cuccok fölé sokkal kényelmesebb tud lenni, mint a C#.

- Szerintem -

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

Van F#. Illetve innentol "konnyeden" lehet majd portolni akar a Scalat is .net-re (volt ilyen projekt, de meghalt).

A CLR bizonyos szempontbol fejlettebb, mint a JVM, mivel kevesbe volt szempont a backward compatibility, illetve sokkal mereszebben adtak hozza uj feature-oket (pl. tail call optimizalas).

Nem tudom, stabilitasban es sebessegben mennyire allja meg a helyet a CLR/Mono a JVM-mel osszehasonlitva, de az biztos, hogy ezt a lepest nagyon-nagyon regen meg kellett volna mar lepni (kabe akkor, amikor mindenki szamara egyertelmu lett, hogy a win32 platform egyeduralkodasanak vege - legkesobb 10 evvel ezelott?), kivancsi leszek, jelent-e barmit is ez a lepes most mar.

Bar az Oracle is nagyon lassan mozog, szoval a ket orias kuzdelmet tekintve tulajdonkeppen nincs is lemaradva a MS.

"a JVM-mel osszehasonlitva"

Melyik JVM-el, van egy csomo proprietary implementacio (pl. Zing), amely HotSpot-hoz kepest jobb teljesitmenyt iger.

Szerk: "Bar az Oracle is nagyon lassan mozog" - a java vilagban nem egyetlen ceg fejleszti a platformot, nincs vendor lock-in, ez oriasi elony volt .net-el szemben.

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

A jvm nem tud tail call optimization muveletet - a scala fordito az self-recursive hivasokat tail pozicioban goto-ra csereli, de ezen goto javaban limitalva van az aktualis function body-ra. A trampoline-ra vagy continuation-ra torteno atalakitas legalabb egy nagysagrenddel lassabb...

Tegyuk hozza, ez a legtobb tenyleges kodot nem igazan erinti, mert a fontos higher-order functionok (map, filter, reduce stb. (a "stb." nem a lista resze!)) mind egyszeru while-cikluskent vannak implementalva a Scala collection libraryben, igy nincs szukseg JVM szintu @tailrec supportra. Hack, de mukodik :)

epp ezaz, hogy hack, es csak ritkan, joforman specialis esetekben mukodik, aztan lehet nezegetni a stack overflow hibakat - nem hiszem, hogy megsertodnenek a mukodo jvm tail call opt miatt (eleg regen napirenden van jvmhez)

de legalabb bolcs dontest hoztak, hogy nem eroszakoltak bele a collection libraryba

"mint JVM-re Scalaban fejleszteni?"

Scala nagyon kiforratlan, meg mindig nincs hozza normalis IDE tamogatas, fordito nagyon lassu. C#-hoz nem (/sem ^^) ertek, de az olvasottak alapjan Java nyelvnel sokkal fejlettebb es legalabb annyira kiforrott. Scala-t a .netes vilagban F#-hoz lehet viszonyitani.

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

A valoban komoly avionika sosem irodik LISP-ben, DO-178B vagy DO-178C eloirasokkal szemben certifikalt esetben.
Altalaban Ada, sok esetben HAL/S (pl. Shuttle) vagy JOVIAL (B-2-es bombazo, B-52-esek, UH-60 Black Hawk stb.).

Muholdak eseteben az on-board software nehezen lehet LISP, a NASA JPL eloirja, hogy tilos a futasideju dinamikus memoriafoglalas. Minden memorianal elore lefoglaltnak kell lennie a stacken + minden ciklus futasideje korlatos kell legyen.

Egy esetrol tudok, hogy LISP ment volna ureszkozon: a Deep Space 1.
http://www.flownet.com/gat/jpl-lisp.html
Ezutan a LISP hivatalosan is kiserleti eszkoz lett a JPL-nel, foleg mivel talaltak egy race condition hibat, ami nem jott elo tesztelesnel.

Melyik muholdakra, repulokre es raketarendszerekre gondolsz?

Ezek egyike sem avionika vagy más vezérlés, ezek elemző és egyéb mérnöki és hasonló ground-use programok. Olyan példát adj, ami on-board vezérlés, mert erről volt szó. Ilyen erővel Python, Java, JS is jöhetne, rengteg userspace ground-use programot használ a NASA.
Pár napja volt a redditen egy AMA az Orion mérnökeivel, volt kérdés a szoftverekről. Az Orion Guidance & Navigation például Matlab és Simulink valamint Stateflow segítségével készül, majd ebből generálnak C++ kódot. Lásd: http://www.reddit.com/r/IAmA/comments/2li4jx illetve http://www.reddit.com/r/IAmA/comments/2li4jx/were_the_team_that_designe…

Érdekes így olvasni a LISP-ről. Főleg azért, mert ugye manapság egy nagy rendszert nem úgy rakunk össze, hogy 0-ról megírunk mindent, hanem
jórészt rendszerintegráció van. Nyilván egy rakéta/stb. más kategória, de ez a sw fejlesztés egy marginális része. Ami ott van és kell az
nem az, ami egy "enterprise" jellegű fejlesztésnél szükséges.

A kovetelmenyek kozul a scoped memory, wcet csak a jeghegy csucsa, sok mas kovetelmenyt is teljesiteni (garantalni) kell. Garantalni pedig rettento nehez tud lenni. Nem olyan egyszeru bizonyitani, hogy a forditoprogram altal vegzett muvelet utan a program ekvivalens a muvelet elottivel...

pl. (ez meg nem DO178 kategoria):
"The CompCert project investigates the formal verification of realistic compilers usable for critical embedded software. Such verified compilers come with a mathematical, machine-checked proof that the generated executable code behaves exactly as prescribed by the semantics of the source program. By ruling out the possibility of compiler-introduced bugs, verified compilers strengthen the guarantees that can be obtained by applying formal methods to source programs."
http://compcert.inria.fr/publi.html

Ez mar inkabb:

"The French company Esterel Technologies decided in 2006 to base its new SCADE SUITE 6 TM certifiable code generator on Objective Caml."

"The new KCG, developed with OCaml, is certified with respect to the IEC 61508 and EN 50128 norms. It is used in several civil avionics DO-178B projects (such as the A380 Airbus plane, for instance) and will be qualified simultaneously to the project qualifications (with the DO-178B, the tools are not qualified by themselves, but by their usage in a project). The project has been accomplished with the expected delays and costs. The software consists in 65k lines of OCaml code, including a lexer and a parser, plus 4k lines of C code for the runtime library. The development team was composed of 6 software engineers and 8 test engineers during almost 2 years. It is a real DO-178B project, yet with only one singularity compared to other tool development in this certification framework: the use of OCaml as the main programming language."

http://synchron2008.lri.fr/slides/fornari.pdf
http://users.eecs.northwestern.edu/~clk800/rand-test-study/_eruoctdseti…

Szerintem nem olyan rossz a helyzet, ha már rááll az agyad. A scala tudatosan úgy konstruált nyelv, hogy a java boilerplate kódjait lehetőleg eliminálja. Ez természetesen tömör szintaxist eredményez, ami elsőre nyilván nehezen átlátható. Ha már megszoktad, és a kérdéses kód szerzője igényes volt, akkor teljesen jól olvasható. Egy egyszerű példa:

Van egy orders listánk, amiben 3-as tupleben tároljuk a termék id-jét, árát és a rendelt mennyiséget. (Tegyük fel hogy ezt a listát runtime állítottuk elő, azért nincs hozzá minimum egy case class.) Ebből akarjuk kiszámolni a teljes rendelés összegét. 


val orders = List((1, 2, 3), (4, 5, 6))

val totalPrice1 = (0 /: (orders map (o => o._2 * o._3)))(_ + _)

val totalPrice2 = orders map {
  case (_, price, quantity) => price * quantity
} reduce {
  (priceOfProduct1, priceOfProduct2) => priceOfProduct1 + priceOfProduct2
}

val pricesByProducts = for((_, price, quantity) <- orders) yield price * quantity
val totalPrice3 = pricesByProducts.reduce((price1, price2) => price1 + price2)

Az első megoldás a legtömörebb, de hogy ezt fogod a legtovább értelmezni az is biztos (mellesleg hozzáteszem, hogy megírni is ezt tartott a legtovább, nem tudom fejből a foldok "operátorait"). A második és harmadik megoldás viszonylag könnyen értelmezhető szerintem, mivel itt a tuple elemeit nevesítve használom. A második előnye, hogy nincs temp változó, cserébe a reduce lépésben a paramétereknek egyértelműbb nevet kellett adnom. A harmadik megoldásban muszáj volt bevezetni a temp változót, mivel a for comprehension-nel csak a map, flatMap és filter vagy a foreach váltható ki. Viszont emiatt szerintem az a legolvashatóbb, egyértelmű hogy mit csinálok a két lépésben, a változónevek baromi sokat segítenek, és a for comprehension is teljesen egyértelmű ha már ismered (márpedig abból indultam ki, hogy ismered).

na, pontosan ez a bajom vele: egy hanyinger a kod. a tomorseg NEM elony mindig, szerintem a java kod sokkal jobban olvashatobb. ezt _csak_ egy scala fejleszto fogja rendesen olvasni (vagy olyan, aki ismeri a szintaxist), mig egy Java kodot barki tud _ertelmezni_ elsore, aki mar programozott masban.

pythonban a for comprehension sokkal olvashatobb, mint scalaban, es ugyanez igaz a lambdakra is, szerintem.

problema es mentalis modell (mind a programozasi nyelvi eszkozokrol, mind magarol a problemarol) kerdese - matematikai jellegu problemahoz kifejezetten hatrany lehet a nem tomor kod

Az apl szeru nyelveknek is megvan a helye, de nem feltetlen minden problemara:
https://github.com/kevinlawler/kona/wiki/Project-Euler-Code-Golf

"APL (named after the book A Programming Language)[6] is a programming language developed in the 1960s by Kenneth E. Iverson."

https://en.wikipedia.org/wiki/APL_%28programming_language%29

"K is a proprietary array processing language developed by Arthur Whitney and commercialized by Kx Systems. Since then, an open-source implementation known as Kona has also been developed.[1] The language serves as the foundation for kdb, an in-memory, column-based database, and other related financial products. The language, originally developed in 1993, is a variant of APL and contains elements of Scheme. Advocates of the language emphasize its speed, facility in handling arrays, and expressive syntax."

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

Bizonyos teruleteken rettento nehezen fogsz versenyezni vele...

Nagyon szép tömör, teljességgel olvashatatlan valamit látok... mégis, milyen terület az, ahol egy ilyen programozási nyelvvel kell büntetni a fejlesztőket?

Közben találtam egy variánst, ez már így kóser:

http://www.smartarrays.com/whitepapers/working%20with%20smartarrays.pdf

Gyakorlatilag nekem az APL-el, mint nyelvvel az a bajom, hogy teljességgel olvashatatlan. Mint konstrukció, most már látom, hogy
mire jó, a smartarrays-nél ezt viszont sikerült úgy megcsinálniuk, hogy olvasható is maradt, és funkcionalitásban legalább annyit tud,
cserébe úgy látom, hogy az ő megoldásuk skálázódik is minden irányba...

Inkább azt mondanám, hogy aki programozott már funkcionális nyelvben. Scala előtt én csak az erlangot ismertem mint funkcionális nyelvet, és pár óra alatt az összes fontosabb scala feature-ről kiderült, hogy már ismerem erlangból, csak ott egy picit máshogy néz ki (részben azért mert az erlang nem oop). Pl. for comprehension <-> list comprehension, pattern matching, lambda expressions.

Ugyanez C#földén: 

// IEnumerable<Tupple<int, int, int>> orders 

var totalPrice1 = (from x in orders select x.Item2 * x.Item3).Sum();
var totalPrice2 = orders.Select(x => x.Item2 * x.Item3).Sum();

És mindenki érti anélkül, hogy tovább kellene képezni.

Mondjuk tény, hogy pattern matching _néha_ jól jönne C#-ban is, viszont valaki javítson már ki, ha tévednék, de sokszor Erlangban is pl. Exception helyett használják arra, hogy ilyen Maybe X esetén eldöntsék, hogy valóban X jött-e (ergó, rendesen ment minden) vagy valami más és akkor gebasz van.

Szerk.: kacsacsőr fix, mert a Drupal nyomi.

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

A linq tökjó, aki írt már sql queryt az érti, de aki eddig _csak_ java kódot látott annak ezt se könnyebb megérteni. Scala a funkcionális programozás "terminológiáját" vette át, aki programozott már más funcprog nyelvben az pontosan ugyanolyan könnyen megérti ezt is. Amit ebből ki akarok hozni az az, hogy a szintaktika nem minden, valójában ha tudatosan olvasható kódot írsz és aki olvassa a kódot annak van némi funcprog alapismerete, annak nem lesz problémája a kód megértésével.

Ez igaz lehet a kettő közül az első szintaxisra, amit én pl. kerülök amennyire lehet, mert szerintem nem illik bele egy c# kód közepébe. (amúgy sem értem, hogy miért kellett az sqlhez képest megfordítani a szórendet...)
De a másik szintaxis, ahogy láthatod is entpassant példáján, inkább egy funkcionális kifejezésre hasonlít, amiben ugye az a legjobb, hogy nem kell hozzá másik nyelv, gyak. a c#-ba pakoltak olyan dolgokat, ami inkább a funkcionális paradigmához van közel.

> (amúgy sem értem, hogy miért kellett az sqlhez képest megfordítani a szórendet...)

Ha belegondolsz, egészen logikus. Ha másért nem, hát azért, mert így tudod használni az IntelliSense-t. (Mert mire az érdemi kódot kezded írni, már tudni fogja, hogy melyik táblában kell keresnie.)

Pedig itt nagyon igaza van a C# dev csapatnak: leírom az from, join, stb. részt és a végén tudom az összes adatforrásom, mikor a select részt írom.

Ezzel szemben SQL-ben mi van? Leírom, hogy SELECT * FROM ..., aztán visszamegyek az elejére és elkezdem kitöltögetni a SELECT részt, mert akkorra már a PgAdmin/SSMS/HeidiSQL (jobb esetben) tudja, hogy mi jöhet a SELECT után. Semmi logika nincs benne, csupán a sokéves megszokás.

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

De amikor tudom, hogy az id kell, de nem tudom fejből hogy az adott táblában táblanévId vagy Id van, vagy hogy múlt időben van-e használva egy ige vagy sem, akkor ne kelljen már ehhez a sémát nézegetnem. Másrészt ha hosszú oszlopnevek vannak akkor nem kell az egészet begépelni, számos elgépelést kockáztatva. Az is jó amikor inkonzisztens oszlopnevek vannak, pl. ugyanaz a fogalom egyszer quantity, egyszer limit.

Na ez az, azt tudom, hogy mit akarok, de hogy honnan fog az nekem összejönni, az nem mindig egyértelmű. Jobbik eset, mikor kollega adatbázisa, rosszabbik, mikor egy kulso fel 8-900 adattablas ERP rendszeréből kell kimazsolazni valamit.

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

Bocsánat, de most nem értem, ezt mire mondod. Én csak annyit állítottam, hogy a DB engineerek sem egyformák: láttam olyat, akinek papírja volt róla, hogy ő az, mégis sikerült Oracle-adatbázisban (tehát nem saját rendszerrel) létrehozni egy táblát, amiben volt 99 darab varchar2(4000) mező freetext inputoknak. Szerintem, és a világ normálisabb fele szerint ez rossz tervezés.

Oracle db + barmilyen tipusu user interakciot igénylő program, hibaüzenet, input, parser, stb. = hányás.

Lehet, hogy sokat tud, meg gyors es jol skalazodik meg ki tudja meg mire kepes, de ha matatni kell, akkormassziv broaf.

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

"Tegyük fel hogy ezt a listát runtime állítottuk elő, azért nincs hozzá minimum egy case class."

Ezt nem igazán értem, runtime is be tudjuk az adatokat case class-ba tenni.
Jobban is fest a példa úgy, ráadásul még jobban kihozza a Scala előnyét a Java-val szemben.

Ráadásul a megoldások sem a legszebbek. 


case class Item(id: Int, amount: Int, price: Int)

val orders = List(Item(1,2,3), Item(4,5,6))

val totalPrice = orders.map(item => item.amount * item.price).sum

vagy, ha valamilyen csoda folytán tuple-ben van az eredmény és át akarjuk rakni case class-ba (, de ezt a listába rakáskor is megtehettük volna): 


val orders = List((1,2,3), (4,5,6))

case class Item(id: Int, amount: Int, price: Int)

val itemOrders = orders.map(x => Item(x._1, x._2, x._3))

val totalPrice = itemOrders.map(item => item.amount * item.price).sum

Tuple-t én olyankor szoktam használni ha egymáshoz tartozó adatokat több különböző forrásból kell összeszedni de csak ideiglenesen (pl. metóduson belül) van rájuk együtt szükség, ezt értettem alatta.

A sum teljesen jogos, eddig valahogy sose volt rá szükség és bennem fel se merült hogy van ilyen alapból.

( lovas | 2014. 11. 13., cs – 09:24 )

Már látom a java fejlesztők seregeit, ahogy lázasan migrálnak .net-re. Már várom a nagy küzdelmet az oracle és a ms közt, miközben oda-vissza perelgetik a guglit a java és a vFAT miatt.

+1

Amennyit egyetemen szembe jött a .NET, sokkal kényelmesebb, mint a Java (ezt viszont kicsit többet nyúztam, mint egyetem), de ha ma valami hatalmas ötletem lenne, s Startupot indítanék, sokkal inkább a Java-ra alapoznék, mint a .NET-re :-\

Remélem verseny lesz, meg jóság.
--
blogom

( carlcolt | 2014. 11. 13., cs – 23:56 )

En akkor is meg akarom verni a Microsoftot, mert van rajta sapka!!!111!!!11

Azert nem ugyanaz, mint szimplan frissiteni a craftbukkitet (foleg, ha opcionalisan meg is volt patchelve, mert valaki meginnovalta a hopperek elott azt, hogy a vizen uszo dolgokat elnyelje a lada, ha van mar belole egy benne vagy egyeb dolgokkal meg lett okositva).

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

Igen, de a Sponge miatt úgy is minden plugint újra kell írni jóformán, mert a Bukkit API... DMCA - halott. Lehet csak a Minecraft 2.0-ra készülnek átírni, de a Mojangosok a Valve-nál is jártak állítólag, úgyhogy akár még Steam-en is megjelenhet.

---
www.digitalocean.com/?refcode=12a4854c714a

( LLZoli | 2014. 11. 14., p – 14:52 )

Jól láttam a bejelentésben és a sok cikkben, hogy maga a GUI részt tartalmazó rész viszont nem lesz nyílt (értek itt mindenféle grafikus controlt és társait)?

Igen, de azt is olvastam, hogy a Mono-s dolgok beolvadnak az MS community dolgaiba, akkor azért biztos könnyebb lesz közös kódbázissal GUI programot írni, mint most. Persze itt le kell mondani WPF-ről és hasonlókról. Úgy gondolm itt az ASP.NET a lényeg, mint szerver oldali megoldás, ami megjelenik Linux és Mac OS X alatt is! Másként a szerver oldal sok esetben lehet C#, Java és/vagy PHP helyett. De javítsatok ki ha nem ez a lényeg.

( szz v | 2014. 11. 14., p – 18:54 )

Hol találom pl. az EntityFramework forrását?

A nyílt forrású dolgok azért valamilyen formában előbb-utóbb begyűrűznek a Linux holdudvarába.

Végül is sikerrel jártam; a fenti néhány lépés után a(z Ubuntu 14.04-re) "telepített" NuGet szépen működött:

mono --runtime=v4.0 NuGet.exe install EntityFramework -Version 6.1.1
Installing 'EntityFramework 6.1.1'.
Successfully installed 'EntityFramework 6.1.1'.

(Később rájöttem, hogy a(z Ubuntu 14.04-ben nem alapértelmezett) monodevelop-5 telepítésével (pl. innen) már nem is kell parancssori NuGet-tel küzdeni, mert az beépített része a fejlesztői környezetnek.)

( nikin v | 2014. 11. 15., szo – 20:59 )

Én örülök neki.
Szóval piros gamótya részemről.

### ()__))____________)~~~ #################
# "Ha én veletek, ki ellenetek?" # E130/Arch