Een crossplatform service schrijven: is Mono geschikt?

[NMe]

Ik heb het idee opgevat om iets als Sickbeard te maken. Voor wie het niet kent: Sickbeard haalt informatie van tv-series op via de API's van sites die die info hebben en zoekt nieuwsgroepen en eventueel torrents af om ontbrekende afleveringen te downloaden. Ik heb echter een aantal problemen met SB die niet op te lossen zijn zonder zelf in de source te gaan hacken, en daar heb ik nou een paar avonden geklooi noch het geduld voor noch zin in omdat ik Python domweg geen mooie taal vind.

Nou heb ik het idee opgevat om gewoon vanaf scratch te beginnen, maar Python ligt daarbij dus al per definitie niet op tafel. Ik heb zelf verreweg de meeste kennis van PHP maar dat is dan weer geen geschikte taal om tooltjes in te schrijven die 24/7 moeten blijven draaien. Wat betreft de talen die ik voldoende ken en waardeer om dit in te kunnen doen blijven C# en Java over. Om C# ook op Linux te laten werken zou dat dus uiteraard Mono worden, al heb ik dáár dan weer geen ervaring mee. Toch heb ik wel een voorkeur voor C# omdat ik wel gecharmeerd ben door .NET en ik alles net iets beter in elkaar vind zitten dan in Java. Daarbij heb ik de voorkeur voor een applicatie die native kan draaien zonder dat ik eerst andere software (Python, Java) moet installeren.

Goed, nu ben ik een beetje op verkenning gegaan. Het blijft dat het relatief simpel is om een Mono-applicatie als service te draaien. Ook een mini-webservertje opnemen voor de webinterface is makkelijk te doen.

Goed, na drie lange alinea's dan eindelijk mijn vraag: ik ben bang dat ik iets over het hoofd zie. Zoals ik het nu zie is zowel zo'n service als de basis voor de webinterface binnen no time geschreven, en de rest is gewoon programmalogica die ik in elke andere taal ook nodig zou hebben. Is het echt zo simpel als ik nu denk, of mis ik iets?

[Dark_f]

Interessant project! Ik heb hetzelfde idee al gehad, pok omdat ik vind dat sickbeard vaak tekort komt.

Heb zelf al wat geschreven in php. Dit omdat ik hierin het meest ervaring heb. Het is inderdaad misschien niet de beste oplossing om 24/7 te draaien. Het gebruikt alleszins pakker minder resources dan sickbeard. (handig op een raspberry pi).

Moest je hulp kunnen gebruiken bij het ontwerpen/testen, ik wil mij gerust kandidaat stellen. Ik kan je echter niet helpen met je vraag omtrent mono, dus deze reactie is volledig offtopic

[Caelorum]

Volgens mij mis je niet veel hoor. Mono is best volwassen geworden.

[Sebazzz]

Zorg er gewoon voor dat je host agnostisch je code schrijft. Eventueel kan je ervoor kiezen om een OWIN implementatie als server te gebruiken. Je hebt dan het voordeel dat je ook OWIN-based libraries, zoals ASP.NET Identity, kan gebruiken.

[NMe]

Sebazzz schreef op zaterdag 14 juni 2014 @ 15:17:
Zorg er gewoon voor dat je host agnostisch je code schrijft. Eventueel kan je ervoor kiezen om een OWIN implementatie als server te gebruiken. Je hebt dan het voordeel dat je ook OWIN-based libraries, zoals ASP.NET Identity, kan gebruiken.

Ik kende OWIN niet, maar als ik zo in hun documentatie kijk ben ik niet echt onder de indruk. Ze hebben zo te zien moeite met unicode. Is het project zélf wel in orde?

[Kwastie]

NMe schreef op zaterdag 14 juni 2014 @ 14:21:
Ik heb echter een aantal problemen met SB die niet op te lossen zijn zonder zelf in de source te gaan hacken, en daar heb ik nou een paar avonden geklooi noch het geduld voor noch zin in omdat ik Python domweg geen mooie taal vind.

Nou heb ik het idee opgevat om gewoon vanaf scratch te beginnen, maar Python ligt daarbij dus al per definitie niet op tafel.

Een nieuwe taal leren kost nou eenmaal tijd. Een complete applicatie van scratch schrijven kost nog veeeeel meer tijd.

Tenzij je iets fundamenteels anders wilt maken dan Sickbeard kan ik mij niet voorstellen dat je sneller iets nieuws kunt maken. Sickbeard heeft een redelijke community die jou mogelijk kan helpen.

Het argument "Python domweg geen mooie taal vind." vind ik nogal kort door de bocht. Het klinkt alsof je zegt "Ik snap het niet, dus het is slecht". Als je geen gebruikt heb gemaakt van een IDE, raad ik je aan eens te kijken naar Pycharm (Community editon is gratis). Dit maakt ontwikkelen van Python zoveel eenvoudiger, helemaal voor een beginnende Python ontwikkelaar.

Daarbij heb ik de voorkeur voor een applicatie die native kan draaien zonder dat ik eerst andere software (Python, Java) moet installeren.

Mono of .NET moet je ook installeren en dus ook niet native.

Als toch besluit iets compleet nieuws te maken zou ik ook nog even kijken naar de Go taal.

[Gomez12]

Mono is niet zo beroerd hoor, mits je maar van te voren goede keuzes maakt en je aan die keuzes vast blijft houden. (Maar als jij geen GUI en geen windows components gebruikt zit je goed)

Het enige nadeel aan Mono vind ik dat ik er geen lekkere IDE voor ken. VS is ideaal voor windows development, maar als je een windows only componentje pakt dan geeft VS afaik geen melding en loop je er pas bij testen tegenaan dat je een component mag vervangen / herschrijven.

Een kleiner nadeel vind ik dat als je iets zoekt op inet je overspoelt wordt .net antwoorden en daar moet je dan zelf uitvissen wat niet 100% windows oriented is

[Anoniem: 144479]

Python heb je in een dag geleerd. Ik zou voor Ruby gaan: easy to learn, hard to master. Daarnaast vind ik het nogal opmerkelijk van een PHP developer die Python niet mooi vind...

[NMe]

Kwastie schreef op zaterdag 14 juni 2014 @ 15:42:
[...]

Een nieuwe taal leren kost nou eenmaal tijd. Een complete applicatie van scratch schrijven kost nog veeeeel meer tijd.

Soms is het sneller om iets nieuws te schrijven dan proberen een grote en slecht gedocumenteerde applicatie te begrijpen.

Tenzij je iets fundamenteels anders wilt maken dan Sickbeard kan ik mij niet voorstellen dat je sneller iets nieuws kunt maken. Sickbeard heeft een redelijke community die jou mogelijk kan helpen.

Fundamenteel anders...nee. Maar ik wil wel een aantal dingen beter oppakken en dat zijn zo veel dingen dat ik onderhand alles aan het herschrijven ben voordat ik daadwerkelijk aan nieuwe features toekom. Komt bij dat ik vervolgens ook steeds moet blijven meepatchen met het originele project omdat ik anders op een gegeven moment dermate achterloop dat mijn project niet meer interessant is... Ik heb liever een eigen project waar ik uiteindelijk final say heb in wat er wel en niet in komt en waarbij ik niet van anderen afhankelijk ben wat betreft het up to date blijven.

Het argument "Python domweg geen mooie taal vind." vind ik nogal kort door de bocht. Het klinkt alsof je zegt "Ik snap het niet, dus het is slecht". Als je geen gebruikt heb gemaakt van IDE, raad ik je aan eens te kijken naar Pycharm (Community editon is gratis). Dit maakt ontwikkelen van Python zoveel eenvoudiger, helemaal voor een beginnende Python ontwikkelaar.

Ik heb pyCharm gebruikt. Het is ook niet dat ik het niet kan doorgronden, het is gewoon dat ik het geen fijne taal vind om mee te werken. En ja, dat is persoonlijk. Kort door de bocht is het niet, maar het is wel een mening en voor mij is het een belangrijk argument. Dat niet iedereen het daarmee eens zal zijn is niet relevant voor mijn keuze om het anders te doen.

Mono of .NET moet je ook installeren en dus ook niet native.

Je kan het framework toch meecompilen in de executable? Of heb ik daar iets verkeerd begrepen?

Gomez12 schreef op zaterdag 14 juni 2014 @ 15:53:
Mono is niet zo beroerd hoor, mits je maar van te voren goede keuzes maakt en je aan die keuzes vast blijft houden. (Maar als jij geen GUI en geen windows components gebruikt zit je goed)

Het enige nadeel aan Mono vind ik dat ik er geen lekkere IDE voor ken. VS is ideaal voor windows development, maar als je een windows only componentje pakt dan geeft VS afaik geen melding en loop je er pas bij testen tegenaan dat je een component mag vervangen / herschrijven.

Een kleiner nadeel vind ik dat als je iets zoekt op inet je overspoelt wordt .net antwoorden en daar moet je dan zelf uitvissen wat niet 100% windows oriented is

Kwestie van elke dag minimaal een keer compilen voor Linux en testen of er niks stuk is lijkt me.

Anoniem: 144479 schreef op zaterdag 14 juni 2014 @ 15:53:
Python heb je in een dag geleerd. Ik zou voor Ruby gaan: easy to learn, hard to master. Daarnaast vind ik het nogal opmerkelijk van een PHP developer die Python niet mooi vind...

Dat ik veel met PHP werk wil niet zeggen dat ik het een mooie taal vind. Al hou ik wel van talen die op C lijken en dat doet PHP meer dan Python.

Ruby...tsja. Nee. Ik heb alleen maar gezeik gehad met RoR draaiend krijgen op mijn NAS en dat is toch wel mijn doelplatform. Het moet makkelijk te installeren zijn en zonder gezeik draaien, en dat lukt me met Ruby voor leken nooit.

[Ramon]

Even iets totaal anders: Is node.js misschien een optie? In mijn ervaring is het een goed cross-platform systeem. Ik gebruik het zelf om een interface te tonen van mijn films met data opgehaald van tmdb op mijn Windows 8 HTPC en dat gaat uitstekend. Je kan er zelf met een paar regels een webserver mee schrijven en met node-webkit heb je een manier om een mooie interface te bouwen http://code.tutsplus.com/...th-node-webkit--net-36296

[NLChris]

Misschien is NzbDrone (http://nzbdrone.com/ ; https://github.com/NzbDrone/NzbDrone ) leuk om mee te spelen. Het beschrijft ongeveer wat jij zoekt, Sickbeard maar dan geschreven in C#. Werkt prima op Win / Linux / OS X.

Je hoeft dan iig niet helemaal van scratch te beginnen. En mocht je het graag zelf doen, dan het bewijst in ieder geval dat Mono geschikt is om dit soort dingen mee te maken.

[Voor 29% gewijzigd door NLChris op 14-06-2014 16:30]

[NMe]

Ramon schreef op zaterdag 14 juni 2014 @ 16:26:
Even iets totaal anders: Is node.js misschien een optie? In mijn ervaring is het een goed cross-platform systeem. Ik gebruik het zelf om een interface te tonen van mijn films met data opgehaald van tmdb op mijn Windows 8 HTPC en dat gaat uitstekend. Je kan er zelf met een paar regels een webserver mee schrijven en met node-webkit heb je een manier om een mooie interface te bouwen http://code.tutsplus.com/...th-node-webkit--net-36296

Hmm, hoewel het een optie is zou het niet mijn eerste keus zijn. Maar ik hou het in mijn achterhoofd.

NLChris schreef op zaterdag 14 juni 2014 @ 16:28:
Misschien is NzbDrone (http://nzbdrone.com/ ; https://github.com/NzbDrone/NzbDrone ) leuk om mee te spelen. Het beschrijft ongeveer wat jij zoekt, Sickbeard maar dan geschreven in C#. Werkt prima op Win / Linux / OS X.

Ziet er gaaf uit, al vermoed weet ik dat het hetzelfde probleem heeft dat Sickbeard voor mij ook heeft: anime wordt gereleased met absolute episode numbers en niet in seizoenen. Aangezien ik veel anime kijk is het heel belangrijk dat absolute numbering ook werkt. Vandaar dat ik maar aan mijn eigen project wilde beginnen.

Je hoeft dan iig niet helemaal van scratch te beginnen. En mocht je het graag zelf doen, dan het bewijst in ieder geval dat Mono geschikt is om dit soort dingen mee te maken.

True, en dat is fijn om te weten.

[UltraSub]

NLChris schreef op zaterdag 14 juni 2014 @ 16:28:
En mocht je het graag zelf doen, dan het bewijst in ieder geval dat Mono geschikt is om dit soort dingen mee te maken.

Ik heb NZBdrone een paar keer bekeken, maar niet "makkelijk" aan de gang gekregen onder Linux.
Lijkt mij de omgedraaide wereld. Cross platform ontwikkelen is niet met dot net imho. Hier is NZBdrone en de mono troep weer verdwenen, met zijn shitload aan dependencies, en mono komt er ook niet meer op.
Maar goed, daar denken anderen vast anders over.

[Megamind]

Ik heb mono op een server geïnstalleerd (CentOS) en heb daar een MVC site op draaien, was niet meer dan een package installeren met yum, je kan hetzelde zeggen over Java, Python, Ruby etc.

[azerty]

Let wel op, als je een GUI wilt voor je programma, ben je aangewezen op GTK, welke niet zo "gemakkelijk" is als de standaard winforms en aanverwanten.

[Janoz]

GUI is sowieso geen issue aangezien dat gewoon via html en de (embedded) webserver gaat. De keuze voor .NET komt op mij wat vreemd over. Het heeft in deze situatie geen enkel voordeel boven Java (behalve dan je gevoel misschien). De JVM is veel volwassener dan Mono en is op veel meer platformen beschikbaar (zelfs op je synology).

Ikzelf heb een dergelijke tool gemaakt (nog eerder dan Sickbeard trouwens, maar dat wist je wel). Ik heb hem in Java gemaakt, maar achteraf gezien zou Python de betere keuze zijn geweest. Zeker op een NAS is het aan gebruikers lasstig uit te leggen hoe ze een JVM installeren (maar goed, voor Mono is dit in het geheel onmogelijk lijkt me).

Wat ik je zou aanraden is, als je het ooit nog wil ditribueren, om python te gebruiken. Anders zou ik toch echt gewoon voor Java gaan (al was het alleen maar omdat ik nog wel een pracht api voor je heb voor het ophalen van een hele boel TV metadata)

[NMe]

Janoz schreef op zaterdag 14 juni 2014 @ 17:44:
Ikzelf heb een dergelijke tool gemaakt (nog eerder dan Sickbeard trouwens, maar dat wist je wel). Ik heb hem in Java gemaakt, maar achteraf gezien zou Python de betere keuze zijn geweest. Zeker op een NAS is het aan gebruikers lasstig uit te leggen hoe ze een JVM installeren (maar goed, voor Mono is dit in het geheel onmogelijk lijkt me).

Naar nu blijkt valt dat wel mee. Ik heb de Mono eens geïnstalleerd op mijn NAS (was twee klikken ) en daarna de anime-branch van NzbDrone geïnstalleerd. Blijkbaar wordt die wél up to date gehouden. Vooralsnog ben ik onder de indruk van dat stuk software en als het bevalt hoef ik zelf geen letter te coden.

[Texamicz]

Node-Webkit is denk ik wat je zoekt. Ingebouwde webserver en is volledig crossplatform voor OSX/Windows en Linux.

Is volledig gebaseerd op webtechnologie. Javascript/HTML5/CSS.

Applicaties zoals Brackets/PopcornTime/Spotify en nog veel meer. Hier wat voorbeelden:
https://github.com/rogerw...mpanies-using-node-webkit

Of gewoon sowieso NodeJS als server gebruiken.

[Voor 6% gewijzigd door Texamicz op 14-06-2014 20:07]

[Caelorum]

NMe schreef op zaterdag 14 juni 2014 @ 16:57:
[...]
Ziet er gaaf uit, al vermoed weet ik dat het hetzelfde probleem heeft dat Sickbeard voor mij ook heeft: anime wordt gereleased met absolute episode numbers en niet in seizoenen. Aangezien ik veel anime kijk is het heel belangrijk dat absolute numbering ook werkt. Vandaar dat ik maar aan mijn eigen project wilde beginnen. :P[...]

Gelukkig is Anime support met absolute numbers "in progress" -> https://trello.com/c/EiWE18fE/139-anime-support
*edit* maar dat had je zelf ook al gevonden blijkbaar http://forums.nzbdrone.co...on-make-the-renamer-crash

UltraSub schreef op zaterdag 14 juni 2014 @ 17:01:
[...]

Ik heb NZBdrone een paar keer bekeken, maar niet "makkelijk" aan de gang gekregen onder Linux.[...]

Mja juiste repository toevoegen en dan sudo apt-get install nzbdrone
Makkelijker kan bijna niet ^^ -> https://github.com/NzbDrone/NzbDrone/wiki/Installation#linux

[Voor 7% gewijzigd door Caelorum op 15-06-2014 00:44]

[NMe]

Caelorum schreef op zondag 15 juni 2014 @ 00:40:
[...]

Gelukkig is Anime support met absolute numbers "in progress" -> https://trello.com/c/EiWE18fE/139-anime-support
*edit* maar dat had je zelf ook al gevonden blijkbaar http://forums.nzbdrone.co...on-make-the-renamer-crash

Ze hebben toevallig vorige week anime-support gereleased inderdaad. Ik ga mijn eigen projectje dus maar vast in de koelkast zetten.

Mja juiste repository toevoegen en dan sudo apt-get install nzbdrone
Makkelijker kan bijna niet ^^ -> https://github.com/NzbDrone/NzbDrone/wiki/Installation#linux

Zelfs op een Synology NAS was het simpel. Even twee packages van SynoCommunity installeren (Mono en NzbDrone) en gaan.

[Lethalis]

HttpListener gebruiken om zelf een web server te bouwen in .NET is zwaar achterhaald.

Daar hebben we al jaren WCF voor (dat veel meer kan dan alleen web services ) en daar is sinds kort de nieuwe System.Web.Http.SelfHost API bij gekomen. Voorlopig werkt de laatste alleen met Web API, maar deze komt dus naar de volledige ASP.Net stack in de volgende versie.

Een HTTP servertje draaien wordt dan een kwestie van een paar regels code:

C#:

var config = new HttpSelfHostConfiguration("http://localhost:8080");

config.Routes.MapHttpRoute(
    "API Default", "api/{controller}/{id}", 
    new { id = RouteParameter.Optional });

using (HttpSelfHostServer server = new HttpSelfHostServer(config))
{
    server.OpenAsync().Wait();
    Console.WriteLine("Press Enter to quit.");
    Console.ReadLine();
}

Kortom een HttpSelfHostServer draaien, wat controllers toevoegen en klaar is kees.

Maar goed, dat is nu nog in ontwikkeling dus

Microsoft wil dat ASP.Net dezelfde flexibiliteit krijgt als NodeJS. In die zin dat je binnenkort dus ook een HTTP servertje kan draaien zonder code, dus gewoon met het kvm commando:

http://www.hanselman.com/blog/IntroducingASPNETVNext.aspx

http://channel9.msdn.com/...erica/2014/DEV-B385#fbid=

.NET is op zich prima geschikt, maar je moet wel begrijpen dat het nog in ontwikkeling is momenteel voordat het goed gaat werken.

Mocht je heel avontuurlijk zijn:

http://graemechristie.git...t-vnext-on-osx-and-linux/

[Voor 6% gewijzigd door Lethalis op 15-06-2014 09:08]

[NMe]

Lethalis schreef op zondag 15 juni 2014 @ 08:15:
HttpListener gebruiken om zelf een web server te bouwen in .NET is zwaar achterhaald.

Daar hebben we al jaren WCF voor (dat veel meer kan dan alleen web services ) en daar is sinds kort de nieuwe System.Web.Http.SelfHost API bij gekomen. Voorlopig werkt de laatste alleen met Web API, maar deze komt dus naar de volledige ASP.Net stack in de volgende versie.

Een HTTP servertje draaien wordt dan een kwestie van een paar regels code:

Ziet er best interessant uit. Maar als het nog niet eens in de volledige .NET-stack zit, dan zit het vast ook nog niet in Mono.

[Anoniem: 26306]

Houd er wel rekening mee dat Linux en BSD mensen over het algemeen helemaal niets van Mono moeten hebben.

[Caelorum]

Valt ook wel mee. Vooral de puristen, maar toch behoorlijk wat applicaties gebruiken al mono. Zelfs bij fedora hebben ze zooi die gebruikt maakt van mono en die zijn toch echt best anaal wat betreft licenties enz.

[BikkelZ]

Als je mono wil targeten zou ik wel direct gewoon beginnen met alles direct te gaan draaien onder Linux dan heb je het altijd cross-platform werkend. Eerst iets moois bouwen onder Windows en er dan achter komen dat je dingen niet kunt gebruiken is echt frustrerend. Dus devven onder Windows en dan pushen naar een Linux bak op het moment dat je gaat runnen.

[Voor 19% gewijzigd door BikkelZ op 15-06-2014 17:44]

[Caelorum]

Of gewoon mono gebruiken op Windows?

[UltraSub]

Caelorum schreef op zondag 15 juni 2014 @ 00:40:

[...]

Mja juiste repository toevoegen en dan sudo apt-get install nzbdrone
Makkelijker kan bijna niet ^^ -> https://github.com/NzbDrone/NzbDrone/wiki/Installation#linux

Weet ik. Dat bedoelde ik ook niet met "niet makkelijk". Maar het feit dat ik er een shitload aan dependencies bij kreeg stemde mij niet vrolijk. Niet out of the box is misschien meer de juiste omschrijving. En dan denk ik, waarom? Om 1 tooltje te draaien zo'n gedrocht er bij?

[Gomez12]

Caelorum schreef op zondag 15 juni 2014 @ 19:59:
Of gewoon mono gebruiken op Windows?

Kan dat uberhaupt wel? Krijg je niet altijd .Net mee (of heb je die niet vanwege andere apps op je pc staan)?

[Anoniem: 26306]

Op zich is .NET niet native, het is gewoon een runtime environment, net als Java. Wat dat betreft is het alleen maar goede marketing van Microsoft. Je kunt met .NET wel veel makkelijker de voor Windows gebruikers gebruikelijke user interface maken, maar met Mono zul je waarschijnlijk GTK gaan gebruiken en is dat dus eigenlijk een net zo grote afwijking als Java. Wat dat betreft zie ik Java meer zitten voor cross platform software, maar eigenlijk is het allemaal maar matig.

[NMe]

Anoniem: 26306 schreef op zondag 15 juni 2014 @ 21:48:
Op zich is .NET niet native, het is gewoon een runtime environment, net als Java. Wat dat betreft is het alleen maar goede marketing van Microsoft. Je kunt met .NET wel veel makkelijker de voor Windows gebruikers gebruikelijke user interface maken, maar met Mono zul je waarschijnlijk GTK gaan gebruiken en is dat dus eigenlijk een net zo grote afwijking als Java. Wat dat betreft zie ik Java meer zitten voor cross platform software, maar eigenlijk is het allemaal maar matig.

Dat laatste ben ik wel met je eens, maar eigenlijk alleen voor software met een GUI. Dit zou een stukje software worden met een service zonder verdere UI en een simpele webinterface. Dat kun je in principe in elke taal klaarspelen zonder dat je aan de buitenkant echt kan zien waarmee het gemaakt is.

[ThunderNet]

Zelf gebruik ik trouwens de Monohelper plugin in visual studio: MSDN: MonoHelper extension
Kun je ook vanuit visual studio de mono-compiler gebruiken.

[ZaZ]

Je kan ook in .net je backend in mono maken en exposen via stdcall of cdecl en, hoewel het niet gebruikelijk is in Linux, die aanspreken via een native frontend in bijv qt ofzo. Ik heb het nooit gebruikt, maar wil er binnenkort eens een testje mee doen. Volgens mij kan het wel gaan werken

[Cilph]

Waarom niet gewoon Java? Genoeg open source libraries beschikbaar voor web services en je zit niet aan Microsoft vast.

[Caelorum]

Omdat je dus met c# ook niet aan Microsoft vastzit. En waarom java gebruiken als je c# kan gebruiken?

UltraSub schreef op zondag 15 juni 2014 @ 20:26:
[...]

Weet ik. Dat bedoelde ik ook niet met "niet makkelijk". Maar het feit dat ik er een shitload aan dependencies bij kreeg stemde mij niet vrolijk. Niet out of the box is misschien meer de juiste omschrijving. En dan denk ik, waarom? Om 1 tooltje te draaien zo'n gedrocht er bij?

Mja, de keest distro's zullen al mono standaard geïnstalleerd staan en anders heb je die dependency zo te pakken. Ik iig wel, want heb meerdere programma's die mono gebruiken. Kan je denken aan banshee, f-spot, tomboy, pinta (paint.net remake), beagle, docky, etc.

[Cilph]

Met C# zit je wel degelijk vast aan Microsoft. Het aanbod libraries is vele malen minder als bij Java, en Mono is een niet officieel ondersteund project dat ook nog eens ver achterloopt op de officiële .NET CLR.

Nu geef ik wel graag toe dat C# als taaltje wel wat fijner werkt door de syntactic sugar.

[Voor 19% gewijzigd door Cilph op 16-06-2014 09:13]

[WernerL]

Caelorum schreef op maandag 16 juni 2014 @ 00:27:
En waarom java gebruiken als je c# kan gebruiken?


[...]

Waarom C# gebruiken als je Java kunt gebruiken.
Met C# zul je het moeten doen met Monodevelop en hoewel het niet superslecht is zijn er voor Java veel meer en betere ontwikkeltools beschikbaar op Linux.

Windows gebruikers kunnen natuurlijk gewoon Visual studio gebruiken maar dan moet je wel zorgen dat je niet perongelijk windows-only libs gaat gebruiken. Iets waar je met Java geen last van hebt.

//edit
Als je voor het Java platform gaat ontwikkelen kun je er natuurlijk ook voor kiezen gewoon in Scala te ontwikkelen, die taal is veel cooler dan Java

[Voor 13% gewijzigd door WernerL op 16-06-2014 09:16]

[Woy]

NMe schreef op zaterdag 14 juni 2014 @ 16:09:
[...]
Je kan het framework toch meecompilen in de executable? Of heb ik daar iets verkeerd begrepen?

Er zijn volgens mij wel tools, maar ik heb nog nooit wat betrouwbaars/gangbaars tegen zien komen. Het is wel mogelijk om je assembly's naar native te compileren d.m.v. NGen, maar dan heb je nog steeds de runtime nodig.

Al met al zal je toch wel de .NET of Mono runtime op het systeem moeten hebben. Nou is dat in het geval van windows natuurlijk niet zo'n probleem, want die komt bijna standaard met windows mee.

Verder is Mono best volwassen, alleen qua GUI gedeelte werkt het IMHO minder fijn, maar zoals je zelf ook al aangeeft is dat in jouw geval niet echt een probleem.

Ik heb ook het idee dat Mono steed volwassener wordt, want MS is aardig op de tour om dingen open uit te brengen, en ze ondersteunen Mono ondertussen ook zelf. Ondertussen zijn ze ook bezig met Roslyn en hebben ze samen met Xamarin de .NET foundation opgericht.

Al met al denk ik dat je voor dit project prima .NET kan gebruiken, maar controleer voordat je een library gebruikt van te voren even of deze ook voor Mono beschikbaar zijn ( De meeste assembly's zouden gewoon moeten werken, maar soms zijn ze nog dependant op windows componenten zoals IIS ).

Voor jouw doeleinden kun je bijvoorbeeld eens naar deze blogpost kijken: http://www.piotrwalat.net...ces-under-linux-and-os-x/

Op windows kan je dan dezelfde service in IIS hosten, of een applicatie/service de service laten hosten: http://www.asp.net/web-ap...b-api/self-host-a-web-api

Je zult dus hooguit wat platform specifieke code moeten hebben voor het hosten van de service, maar dat is maar een heel klein gedeelte.

[Voor 14% gewijzigd door Woy op 16-06-2014 09:27]

[Cilph]

WernerL schreef op maandag 16 juni 2014 @ 09:14:
[...]
//edit
Als je voor het Java platform gaat ontwikkelen kun je er natuurlijk ook voor kiezen gewoon in Scala te ontwikkelen, die taal is veel cooler dan Java

Uitstekend punt. Scala is veel beter dan C# en Java bij elkaar. Nou ja, minus de Type Erasure, maar daar kun je rond heen werken. En omdat je op de JVM draait, nog altijd dezelfde libraries beschikbaar als met Java.

[Voor 9% gewijzigd door Cilph op 16-06-2014 09:29]

[Caelorum]

Woy schreef op maandag 16 juni 2014 @ 09:21:
[...]
Ik heb ook het idee dat Mono steed volwassener wordt, want MS is aardig op de tour om dingen open uit te brengen, en ze ondersteunen Mono ondertussen ook zelf. Ondertussen zijn ze ook bezig met Roslyn en hebben ze samen met Xamarin de .NET foundation opgericht.
[...]

Roslyn is sowieso een leuke. Microsoft is momenteel bezig met een project waarbij je wel de gebruikte delen van de .net VM kan meecompileren. Kom alleen even niet op de naam van het project

[HMS]

Caelorum schreef op maandag 16 juni 2014 @ 09:44:
[...]

Roslyn is sowieso een leuke. Microsoft is momenteel bezig met een project waarbij je wel de gebruikte delen van de .net VM kan meecompileren. Kom alleen even niet op de naam van het project

Bedoel je .NET Native? http://blogs.msdn.com/b/d...etnative-performance.aspx

Cilph schreef op maandag 16 juni 2014 @ 09:29:
[...]


Uitstekend punt. Scala is veel beter dan C# en Java bij elkaar. Nou ja, minus de Type Erasure, maar daar kun je rond heen werken. En omdat je op de JVM draait, nog altijd dezelfde libraries beschikbaar als met Java.

Als je functioneel wil programmeren met .NET kan je natuurlijk ook F# gebruiken.

Zelf vind ik dat Xamarin goede dingen aan het doen is met Mono, maar dat het nog lang niet ingeburgerd is bij Linux gebruikers. Gelukkig is Microsoft zich aan het realiseren dat ze niet meer 100% kunnen inzetten op Windows, en dat multi platform support een steeds belangrijkere feature wordt (is). Vandaar natuurlijk ook hun samenwerking met Xamarin.

Toch is het zo dat Mono veel minder ingeburgerd is bij Linux gebruikers dan Java, dat zal voornamelijk met de (voorheen) vijandige houding van Microsoft te maken hebben. In mijn ogen is .NET in potentie superieur aan Java (omdat Sun / Oracle heeft zitten slapen de afgelopen jaren), maar het verminderd cross platform zijn van .NET blijft een heikel punt.

Ik voorzie dat Mono mogelijk geadopteerd gaat worden door Microsoft, en dat er op termijn een .NET for Linux gaat komen met officiele support van Microsoft. Maar dit zal waarschijnlijk nog wel wat jaren duren. Tot die tijd zul je dus aan Mono vastzitten wil je .NET draaien op een ander systeem als Windows.

[Texamicz]

Anoniem: 26306 schreef op zondag 15 juni 2014 @ 21:48:
Op zich is .NET niet native, het is gewoon een runtime environment, net als Java. Wat dat betreft is het alleen maar goede marketing van Microsoft. Je kunt met .NET wel veel makkelijker de voor Windows gebruikers gebruikelijke user interface maken, maar met Mono zul je waarschijnlijk GTK gaan gebruiken en is dat dus eigenlijk een net zo grote afwijking als Java. Wat dat betreft zie ik Java meer zitten voor cross platform software, maar eigenlijk is het allemaal maar matig.

Bij zaken zoals Node-Webkit heb je altijd dezelfde user interface. Namelijk je CSS. Op Windows / OSX / Linux. Zijn mensen hier bang voor Javascript ofzo omdat ze perse in C# moeten proggen?

Mono is mooi, maar het zou nog mooier zijn als Microsoft het overneemt en volledig support geeft en ook uitbrengt voor OSX. Dat zou het hele .NET gebeuren veel groter kunnen maken. Ze hebben er vast zelf ook al over gepraat intern en er niet de behoefte voor hebben gehad om het uit te rollen naar Linux / OSX.

Terwijl iedereen weet dat Crossplatform zeker wel de toekomst is. Ongeacht welke platform je liefhebber van bent.

[Caelorum]

Mono gaat niet worden overgenomen. In plaats daarvan heeft Microsoft samenwerking met Xamarin aangekondigd. Dat moet ook wel, omdat ze anders niet kunnen waarmaken wat ze met ASP.NET vNext hebben beloofd: 100% ondersteuning in mono.

[Gomez12]

Caelorum schreef op woensdag 18 juni 2014 @ 19:04:
Mono gaat niet worden overgenomen. In plaats daarvan heeft Microsoft samenwerking met Xamarin aangekondigd. Dat moet ook wel, omdat ze anders niet kunnen waarmaken wat ze met ASP.NET vNext hebben beloofd: 100% ondersteuning in mono.

Je beseft hoe tegenstrijdig het is wat je hier zegt?

100% ondersteuning in mono, maar het MS core-team gaat het niet verzorgen, nee een extern bedrijfje gaat het wel even doen (oftewel Xamarin/mono zal altijd achter .Net aan blijven hobbelen)

Wellicht dat als Xamarin/Mono een goede kapitaalinjectie krijgt dat die .Net 2.0 100% kunnen ondersteunen terwijl MS op .Net 5.0 zit te programmeren, maar het nieuwste zal dus altijd MS blijven (totdat Xamarin bijgehobbeld is, maar in die tijd staat MS ook niet stil en werkt weer aan nieuwere functies)

[ZaZ]

100% ondersteuning is nieuw voor mij.
Van wat ik heb begrepen is dat Microsoft mono in hun unit-tests meeneemt, dus de focus ligt wel op eigen ontwikkeling, maar de oude dingen die vroeger in mono werkten moeten blijven werken, dat is dus heel wat anders.
Desondanks een hele mooie vooruitgang.

[Caelorum]

Gomez12 schreef op donderdag 19 juni 2014 @ 00:38:
[...]
Je beseft hoe tegenstrijdig het is wat je hier zegt?[...]

Nee, want een actieve samenwerking tussen Xamarin en Microsoft is precies dat.

[...] 100% ondersteuning in mono, maar het MS core-team gaat het niet verzorgen, nee een extern bedrijfje gaat het wel even doen (oftewel Xamarin/mono zal altijd achter .Net aan blijven hobbelen)

Wellicht dat als Xamarin/Mono een goede kapitaalinjectie krijgt dat die .Net 2.0 100% kunnen ondersteunen terwijl MS op .Net 5.0 zit te programmeren,[...]

Je bedoelt zoals Mono dat nu al doet op wat obvious uitzonderingen? http://www.mono-project.com/Compatibility Zoveel hobbelen ze er ook weer niet achteraan hoor. En dit hebben ze allemaal voor elkaar gekregen ondanks de houding van Microsoft. Nu Microsoft heeft aangekondigd actief te gaan samenwerken met Xamarin zal het alleen maar sneller gaan.

ZaZ schreef op donderdag 19 juni 2014 @ 02:12:
100% ondersteuning is nieuw voor mij.
Van wat ik heb begrepen is dat Microsoft mono in hun unit-tests meeneemt, dus de focus ligt wel op eigen ontwikkeling, maar de oude dingen die vroeger in mono werkten moeten blijven werken, dat is dus heel wat anders.
Desondanks een hele mooie vooruitgang.

100% is hoe ik het lees in ieder geval. ASP.NET vNext zal gewoon normaal draaien op mono, dat is wat ze hebben gezegd.

[Gomez12]

Caelorum schreef op donderdag 19 juni 2014 @ 09:53:
[...]
Je bedoelt zoals Mono dat nu al doet op wat obvious uitzonderingen? http://www.mono-project.com/Compatibility Zoveel hobbelen ze er ook weer niet achteraan hoor. En dit hebben ze allemaal voor elkaar gekregen ondanks de houding van Microsoft. Nu Microsoft heeft aangekondigd actief te gaan samenwerken met Xamarin zal het alleen maar sneller gaan.

Yep, zo bedoel ik het exact.

Mooi groen blokje bij het volgende punt :
- LINQ to SQL - Mostly done, but a few features missing

Maar ook als je inhoudelijk gaat kijken bij iets als : http://go-mono.com/status/
Dan zie je bijna overal in elke class (ik heb er tenminste geen een kunnen vinden die het niet bevatte) wel iets staan van :
- Missing: we need it
- The method just throws a NotImplementedException
- TODO: some functionality might be missing

En in wezen betekent dat concreet dat als jij in mono iets maakt dat het waarschijnlijk wel in .Net gaat werken, maar als jij iets uitgebreiders in .Net gaat maken dan heb je opeens een grote uitdaging om het multi-platform te krijgen.

[Lethalis]

1 grote wijziging van vNext is dat je bij elke applicatie een eigen versie van het .NET framework kunt deployen. Als ze vNext in Mono willen ondersteunen, dan lijkt me dat deze functie er ook op moet werken.

De core CLR zal dan wel Mono zijn, maar waarschijnlijk betekent dit dan ook dat voor de rest gewoon Microsoft assemblies er op zullen draaien. En waarom ook niet? Het is immers open source geworden.

Ik vermoed dus dat Mono steeds minder zelf gaat doen.

Uberhaupt vind ik de rol van Mono een beetje apart. Kijk maar naar Silverlight voor de Mac. Heeft Mono niks mee te maken, toch heeft Microsoft daar stiekem een deel van .NET draaien op een ander platform.

Kortom, weer een vermoeden van mij, maar Microsoft heeft zelf al aardig wat in huis dat het gewoon op andere platformen doet. Waarschijnlijk is een .NET voor de Mac en Linux helemaal niet zo ver weg als dat sommigen hier denken en zou het nog zomaar eens kunnen dat Mono daar niet eens een vereiste voor is.

[Caelorum]

Lethalis schreef op vrijdag 20 juni 2014 @ 11:40:
[...] Waarschijnlijk is een .NET voor de Mac en Linux helemaal niet zo ver weg als dat sommigen hier denken en zou het nog zomaar eens kunnen dat Mono daar niet eens een vereiste voor is.

Ik denk dat Microsoft gewoon bij gaat dragen aan mono mocht het ooit zover komen dat ze echt direct andere platformen gaan ondersteunen. Silverlight is toch een slap aftreksel van .Net 3.5 ^^ Daarnaast is er al zoveel gesleuteld aan mono dat de performance daar al behoorlijk goed is, dus waarom niet wat developers daar aan toewijzen en samen met de community alles implementeren?

[Lethalis]

Caelorum schreef op vrijdag 20 juni 2014 @ 11:44:
[...]

Ik denk dat Microsoft gewoon bij gaat dragen aan mono mocht het ooit zover komen dat ze echt direct andere platformen gaan ondersteunen. Silverlight is toch een slap aftreksel van .Net 3.5 ^^ Daarnaast is er al zoveel gesleuteld aan mono dat de performance daar al behoorlijk goed is, dus waarom niet wat developers daar aan toewijzen en samen met de community alles implementeren?

Om het project in eigen beheer te hebben.

Dat lijkt technisch gezien niet logisch op dit moment, maar als Microsoft echt naar voren wil komen met een .NET voor de Mac / Linux / whatever dan is het veel handiger om dat onder eigen beheer te doen en ervoor te zorgen dat op alle platformen tegelijkertijd dezelfde functies beschikbaar zijn.

Ik zie hun flirt met Mono meer als een eerste stap

Maar goed, misschien gaan ze Xamarin ook gewoon kopen. Dan valt Mono ineens onder hun eigen beheer

[Gomez12]

Lethalis schreef op vrijdag 20 juni 2014 @ 11:40:
Kortom, weer een vermoeden van mij, maar Microsoft heeft zelf al aardig wat in huis dat het gewoon op andere platformen doet. Waarschijnlijk is een .NET voor de Mac en Linux helemaal niet zo ver weg als dat sommigen hier denken en zou het nog zomaar eens kunnen dat Mono daar niet eens een vereiste voor is.

Dat lijkt me niet, dat is echt ongeveer een vuistslag in het gezicht van een heleboel developers die nu voor / met Mono werken als MS opeens met de melding komt : Leuk dat gehobby met Mono, maar wij hebben in het geheim een eigen versie gemaakt dus jullie kunnen stoppen.

MS kan meewerken aan Mono of Mono zijn eigen ding laten doen, maar niet ruim van te voren aangekondigd een .Net multiplatform lanceren kost ze gewoon een zooitje goodwill.

[NMe]

Gomez12 schreef op vrijdag 20 juni 2014 @ 16:05:
[...]

Dat lijkt me niet, dat is echt ongeveer een vuistslag in het gezicht van een heleboel developers die nu voor / met Mono werken als MS opeens met de melding komt : Leuk dat gehobby met Mono, maar wij hebben in het geheim een eigen versie gemaakt dus jullie kunnen stoppen.

De developers die voor Mono werken vinden het misschien vervelend, maar de developers die mét Mono werken zouden er geen bezwaar tegen moeten hebben. Als iets in Mono werkt dan werkt het toch ook in .NET? Andersom niet per se, dat begrijp ik.

[Lethalis]

Het zou alleen de mensen raken die aan Mono werken.

Ik doe zelf niks met mono omdat ik er weinig vertrouwen in heb tot nu toe. Zou Microsoft het officieel ondersteunen of zelf met iets komen dan zou ik serieus overwegen om het ook te gaan gebruiken.

Dat geeft gewoon meer vertrouwen.

Op mijn werk doe ik al 10 jaar .NET maar als ik iets ontwikkel dat op Linux moet werken dan kies ik toch echt voor Java op dit moment.

[Voor 18% gewijzigd door Lethalis op 20-06-2014 16:56]

[Caelorum]

Mja, weinig vertrouwen.. Het project loopt alweer 9 jaar en wordt gebacked door een (door door de developers opgericht) commercieel bedrijf. Het is echt niet alsof het over twee jaar ineens niet meer bestaat ofzo...
Dat bedrijf doet overigens ook goede zaken en de core van het bedrijf is mono. Lijkt me sterkt dat Xamarin ineens mono laat vallen.

[Voor 31% gewijzigd door Caelorum op 20-06-2014 17:02]

[Janoz]

Je zou natuurlijk ook voor een oplossing gaan die door wat meer bedrijven ondersteund wordt. Bedrijven als Oracle, IBM, RedHat of Apache. Maar Xamarin is vast een stuk stabieler

[Megamind]

Janoz schreef op vrijdag 20 juni 2014 @ 17:42:
Je zou natuurlijk ook voor een oplossing gaan die door wat meer bedrijven ondersteund wordt. Bedrijven als Oracle, IBM, RedHat of Apache. Maar Xamarin is vast een stuk stabieler

Nu heb je het sowieso over MS in algemeen en niet persé de mono tak.

[Lethalis]

Caelorum schreef op vrijdag 20 juni 2014 @ 17:00:
Mja, weinig vertrouwen.. Het project loopt alweer 9 jaar en wordt gebacked door een (door door de developers opgericht) commercieel bedrijf. Het is echt niet alsof het over twee jaar ineens niet meer bestaat ofzo...
Dat bedrijf doet overigens ook goede zaken en de core van het bedrijf is mono. Lijkt me sterkt dat Xamarin ineens mono laat vallen.

Vertrouwen bestaat uit meer dan alleen geloof hebben in de continuiteit.

Ik wil ook het gevoel hebben dat ik niet tegen beperkingen aan ga lopen als ik al midden in het project zit.

Stel ik begin aan project X dat een doorlooptijd van 6 maanden heeft dan kijk ik ook of andere mensen soortgelijke projecten met succes hebben afgerond op hetzelfde platform met dezelfde tools.

Correct me if I'm wrong, maar ik zie nog geen serieuze Asp.net sites op mono draaien. Dat gaat met vNext vast wel veranderen, maar voorlopig is het niet zover.

[Caelorum]

Ah zo. Ja. Niet echt recente voorbeelden. Jaar of 4-5 geleden draaide MDN van Mozilla nog op mono, maar die zijn ondertussen al overgestapt naar python en django. Wikipedia deed vroeger (en doet volgens mij nog steeds) het indexeren en zoeken via lucene.net (zoek maar op wikipedia en dotlucene) op mono. Voor die tijd deden ze het met java, maar dat was blijkbaar in 2005 niet goed genoeg
Er zullen nog wel meer sites zijn, maar de grote sites zullen inderdaad bijna allemaal op MS eigen stack zitten.

[NMe]

Janoz schreef op vrijdag 20 juni 2014 @ 17:42:
Je zou natuurlijk ook voor een oplossing gaan die door wat meer bedrijven ondersteund wordt. Bedrijven als Oracle, IBM, RedHat of Apache. Maar Xamarin is vast een stuk stabieler

Want Java is van onbesproken reputatie.

[Fuzzillogic]

Ik heb inmiddels meer ervaring met C#/.NET dan met Java, toch zou ik nog steeds Java kiezen. In .NET lekt het onderliggend platform (Windows in mijn geval) me nog veel te vaak door naar de bovengelegen .NET-laag. In Java is de platform-abstactie verder doorgevoerd. Maar als je een non-GUI backend server schrijft is dat wellicht veel minder relevant.

C# en .NET zijn dan wel open standaarden, ik heb zo mijn twijfels over de toekomst. De System.* namespace is gestandaardiseerd, maar Microsoft heeft inmiddels de Windows.* namespace veel dingen gedupliceerd en nieuwe ontwikkelingen ook daarin gedaan. En ja, Windows.* valt niet onder de standaard... Misschien dat de hernieuwde interesse van MS in .NET, Mono en Xamarin daar wel weer verbetering in brengt. Vooralsnog blijft MS naar mijn idee een grotere vinger in de .NET-pap hebben dan Oracle in de Java-pap. De OpenJDK is ook zonder Oracle een blijvertje.

C# als taal... Meh. namespace { } en partial classes maakt het weer rommelig, properties blijven m.i. hybride Frankenstein-dingen, het niet verplicht opvangen/rethrowen van excepties vind ik vreemd voor een static typed taal. De fancy dingen als lambdaexpressies zijn er ook in Java 8.

Maar mijn voornaamste pet peeve is toch wel de IDE. Visual Studio vind ik ronduit teleurstellend, inclusief VS2013. Gelukkig hebben we ReSharper. Maar toch ben ik ben blij als ik thuis weer Netbeans kan starten. Git-integratie in VS is om te huilen. (overigens, TFS voor source control vind ik schandalig slecht). Of je met Xamarin studio gelukkig gaat worden voor service code betwijfel ik. Java-IDE's zoals Netbeans bieden toch al meer comfort en support voor het schrijven van dat soort dingen.

Voor mij valt Mono al af omdat ik zelf niet voor C# / .NET zou kiezen.

[Caelorum]

Fuzzillogic schreef op zaterdag 21 juni 2014 @ 00:04:
Ik heb inmiddels meer ervaring met C#/.NET dan met Java, toch zou ik nog steeds Java kiezen. In .NET lekt het onderliggend platform (Windows in mijn geval) me nog veel te vaak door naar de bovengelegen .NET-laag. [...]

Kan je hier een voorbeeld van geven? Heb er zelf nog nooit wat van gemerkt, dus ben wel nieuwsgierig nu

[...]C# en .NET zijn dan wel open standaarden, ik heb zo mijn twijfels over de toekomst. De System.* namespace is gestandaardiseerd, maar Microsoft heeft inmiddels de Windows.* namespace veel dingen gedupliceerd en nieuwe ontwikkelingen ook daarin gedaan. En ja, Windows.* valt niet onder de standaard... [...]

Die hele namespace is voor Windows Runtime apps en niet zozeer voor desktop of server applicaties. Wat ze in dat hele gebeuren doen is wellicht niet zo interessant als je aan een applicatie werkt dat gaat draaien op mono. Maar zelfs al is de toekomst anders, mono is in de basis een project dat de standaard implementeert. Dat ze toevallig ook de niet standaard dingen implementeren is mooi meegenomen, maar zo zetten ze zichzelf niet weg op de website. De apps die je nu gaat maken voor mono zullen over 10 jaar nog steeds op mono draaien, zolang als de mono VM wordt onderhouden.

[...] Vooralsnog blijft MS naar mijn idee een grotere vinger in de .NET-pap hebben dan Oracle in de Java-pap. De OpenJDK is ook zonder Oracle een blijvertje.[...]

Dat MS een grote vinger in de pap heeft wil niet zeggen dat als zij er mee stoppen het allemaal meteen ophoudt. Ook zonder MS is mono een blijvertje...

[...]het niet verplicht opvangen/rethrowen van excepties vind ik vreemd voor een static typed taal. [...]

Vind het juist vreemd dat je verplicht bent er iets mee te doen in java. Java is de enige taal die *ik* ken waarbij je verplicht bent de exceptions op te vangen.

[...] Maar mijn voornaamste pet peeve is toch wel de IDE. Visual Studio vind ik ronduit teleurstellend, inclusief VS2013. Gelukkig hebben we ReSharper. Maar toch ben ik ben blij als ik thuis weer Netbeans kan starten. Git-integratie in VS is om te huilen. [...]

Netbeans beter dan Visual Studio? Het is niet dat ik Netbeans een slechte IDE vind, maar het is echt niets vergeleken met VS2013, zelfs zonder R#... Wel grappig hoe daar blijkbaar de meningen zo anders over kunnen zijn...

[Lethalis]

Fuzzillogic schreef op zaterdag 21 juni 2014 @ 00:04:
C# als taal... Meh. namespace { } en partial classes maakt het weer rommelig, properties blijven m.i. hybride Frankenstein-dingen, het niet verplicht opvangen/rethrowen van excepties vind ik vreemd voor een static typed taal. De fancy dingen als lambdaexpressies zijn er ook in Java 8.

Maar mijn voornaamste pet peeve is toch wel de IDE. Visual Studio vind ik ronduit teleurstellend, inclusief VS2013. Gelukkig hebben we ReSharper. Maar toch ben ik ben blij als ik thuis weer Netbeans kan starten. Git-integratie in VS is om te huilen. (overigens, TFS voor source control vind ik schandalig slecht). Of je met Xamarin studio gelukkig gaat worden voor service code betwijfel ik. Java-IDE's zoals Netbeans bieden toch al meer comfort en support voor het schrijven van dat soort dingen.

Het grappige is dat ik ook in .NET werk op kantoor en thuis met Java en Netbeans, maar het alsnog niet met jou eens ben

Mijn grootste probleem met Java is de verbosity. Het is denk ik het verschil of iemand graag iets wil programmeren dat degelijk is (Java), of dat je snel iets voor elkaar wilt krijgen (C#). En ik wil graag beide

Ik kies thuis voor Java vanwege portability en open source, maar niet omdat ik de taal zo handig vind.

Neem een simpele Person class. In Java heb ik veel meer code nodig om hetzelfde te bereiken:

C#:

using System;

namespace Test
{
  public class Person
  {
    public Guid PersonID { get; set; }
    public String Name { get; set; }
    public int Age { get; set; }
  }
}

Java:

package test;

import java.util.UUID;

public class Person {
  private UUID personID;
  private String name;
  private int age;
  
  public UUID getPersonID() { return personID; }
  public void setPersonID(UUID personID) { this.personID = personID; }

  public String getName() { return name; }
  public void setName(String name) { this.name = name; }
  
  public int getAge() { return age; }
  public void setAge(int age) { this.age = age; }
}

Nu weet ik ook wel dat ik in Netbeans simpelweg de private fields declareer en de rest laat genereren (refactor, encapsulate fields), maar alsnog voelt C# in dit geval cleaner aan.

Wat heb jij precies tegen properties? Het is juist 1 van die dingen die ik mis bij Java.

Het verplicht opvangen en rethrowen van exceptions heb ik een soort haat/liefde verhouding mee. Aan de ene kant schrijf ik er nettere code door, omdat ik gedwongen word om erover na te denken, aan de andere kant is het soms heel irritant als ik even snel een testproject maak om iets uit te proberen. Dan ben ik al snel geneigd om alles in 1 grote try catch te gooien en alle warnings van Netbeans te negeren.

Mijn grootste probleem met Visual Studio 2013, zeker bij grotere projecten, is dat het ontzettend vaak ermee kapt. Op mijn werk hebben we bijvoorbeeld een solution met 20 projecten met allerlei afhankelijkheden van elkaar, controls die geladen moeten worden, enzovoorts.. en dan is het vrijwel dagelijks "Visual Studio has encountered a problem and needs to close"

Maar voor de rest vind ik het wel een fijne IDE

[Janoz]

NMe schreef op vrijdag 20 juni 2014 @ 23:38:
[...]

Want Java is van onbesproken reputatie.

tut tut, nu niet over applets beginnen he. Ik ga .net ook net ActiveX aanrekenen .

[Caelorum]

Janoz schreef op zaterdag 21 juni 2014 @ 11:02:
[...]

tut tut, nu niet over applets beginnen he. Ik ga .net ook net ActiveX aanrekenen .

Dat mag ik hopen, want ActiveX is 4 jaar voor .NET uitgebracht

[NMe]

Janoz schreef op zaterdag 21 juni 2014 @ 11:02:
[...]

tut tut, nu niet over applets beginnen he. Ik ga .net ook net ActiveX aanrekenen .

Ik doelde meer op de verschillende ernstige lekken die er door de jaren heen in Java gezeten hebben, wat maakt dat de bedrijven die het backen weliswaar continuïteit garanderen, maar niet per se kwaliteit. Al lijkt het de laatste tijd een stuk beter te gaan dan pak 'm beet drie jaar geleden.

[Janoz]

Al die ernstige lekken hadden enkel met de browser plugin (dus applets) te maken.

[Wolfboy]

Mocht NzbDrone op een of andere manier toch niet 100% fijn werken is Sickrage misschien nog een optie. Een fork van Sickbeard met een veel snellere development cycle en wel ondersteuning voor van alles en nog wat (waaronder Anime support en absolute numbering)

https://sickrage.tv/forums/

[Fuzzillogic]

Vaak lijken .NET classes, zoals Bitmap, niet veel meer dan vrij dunne wrappers rondom de Win32 API. Vanuit Microsoft gezien best begrijpelijk. Maar nog kom je dan in aanraking met handles, DIBs, expliciet Dispose() moeten aanroepen, etc. Platformonafhankelijk wordt het daar niet van. Dat is ook niet het doel geweest van MS; .NET is (was?) een Windows-techniek, the rest be damned.

Ter vergelijk: git is puur gericht op Linux. Git op Windows is een gedoe met cygwin. Ja het werkt wel, maar het is duidelijk niet cross platform bedoeld. Mercurial is m.i. voor Windows / OS X eigenlijk de betere kandidaat, want het is veel meer cross platform opgezet.

Voor development met VS mis ik features die ik eigenlijk als vanzelfsprekend vind in een IDE: highlighten van voorkomens van de identifier waar je cursor op staat. Refactormogelijkheden. Fatsoenlijk overzicht met "find usages" van methods e.d. Goede source control - git support in VS2013 is ook nog om te janken. En ffs, een live diff t.o.v. je source repository in de margin/gutter bar. Ja er zijn gratis extensies om e.e.a. te fixen, maar kom op, dit soort dingen moeten standaard zijn. Daarnaast mis ik de mogelijkheid van Netbeans om met shift+alt+cursor geselecteerde regels te verplaatsen.

Maar goed, het ging om Mono, en VS zelf is niet bijster cross platform MonoDevelop lijkt me dan de aangewezen tool, maar ik heb daar geen enkele ervaring mee. Soms heb je geen do-it-all-IDE nodig, en wellicht dat MonoDevelop precies past voor dit soort kleinere projectjes. Hoe dan ook, een goede IDE is m.i. een must, afwezigheid ervan zou voor mij een sterk minpunt zijn om met een platform aan de slag te gaan.

[Caelorum]

Fuzzillogic schreef op zondag 22 juni 2014 @ 15:34:
Vaak lijken .NET classes, zoals Bitmap, niet veel meer dan vrij dunne wrappers rondom de Win32 API. Vanuit Microsoft gezien best begrijpelijk. Maar nog kom je dan in aanraking met handles, DIBs, expliciet Dispose() moeten aanroepen, etc.[...]

Valt ook wel mee. Gewoon in een using statement opnemen. Is niet veel anders dan wat je in java moet doen.
Overigens zal je hetzelfde moeten doen op linux of welk ander OS dan ook. Dit is gewoon een designkeuze van het platform. Er is ooit besloten dat unmanaged resources niet automatisch worden vrijgegeven wanneer een managed object wordt gedeconstruct. Dat heeft niets te maken met dat het een wrapper rond de Win32 API is.

Fuzzillogic schreef op zondag 22 juni 2014 @ 15:34:
[...] Refactormogelijkheden. Fatsoenlijk overzicht met "find usages" van methods e.d. Goede source control[...]

Refactormogelijkheden zitten er gewoon in en ook best uitgebreid, heb zelf nooit wat willen doen waarvoor ik een plugin nodig zou hebben. Find usages zie ik ook even het probleem niet? En goede source control zit er natuurlijk in in de vorm van TFS. Kan zijn dat TFS niet helemaal jouw smaak is, maar er is op zich niets mis mee. Voor git zou ik persoonlijk toch de commandline pakken of anders SourceTree, maar dat zou ik op elk OS doen. Er is nog geen enkele IDE die in de buurt komt van de cli of SourceTree IMO

Fuzzillogic schreef op zondag 22 juni 2014 @ 15:34:
[...] MonoDevelop lijkt me dan de aangewezen tool, maar ik heb daar geen enkele ervaring mee. Soms heb je geen do-it-all-IDE nodig, en wellicht dat MonoDevelop precies past voor dit soort kleinere projectjes. [...]

MonoDevelop past bij geen enkel project IMO. Je bent productiever als je VS2013 in een VM opstart Groot probleem is ook dat het echt enorm moeilijk is een plugin te schrijven voor MonoDevelop. Het is dus ook niet zo alsof je even je eigen slappe aftreksel van R# kan maken. En out of the box is MonoDevelop een erg spartaanse IDE.

[Voor 49% gewijzigd door Caelorum op 22-06-2014 19:17]

[Fuzzillogic]

Caelorum schreef op zondag 22 juni 2014 @ 19:12:
[...]

Valt ook wel mee. Gewoon in een using statement opnemen. Is niet veel anders dan wat je in java moet doen.
Overigens zal je hetzelfde moeten doen op linux of welk ander OS dan ook. Dit is gewoon een designkeuze van het platform. Er is ooit besloten dat unmanaged resources niet automatisch worden vrijgegeven wanneer een managed object wordt gedeconstruct. Dat heeft niets te maken met dat het een wrapper rond de Win32 API is.

In Java is het soms nodig om file handles e.d. te sluiten en niet onnodig open te houden. Maar voor afbeeldingen ben ik het niet tegengekomen. Sowieso is de platformabstractie veel verder doorgevoerd in Java waardoor "unmanaged" eigenlijk niet voorkomt.

Ik zegt niet dat de keuze van .NET verkeerd is. Maar als je doel platformonafhankelijkheid is, dan is het een drempel.

Refactormogelijkheden zitten er gewoon in en ook best uitgebreid, heb zelf nooit wat willen doen waarvoor ik een plugin nodig zou hebben. Find usages zie ik ook even het probleem niet? En goede source control zit er natuurlijk in in de vorm van TFS. Kan zijn dat TFS niet helemaal jouw smaak is, maar er is op zich niets mis mee. Voor git zou ik persoonlijk toch de commandline pakken of anders SourceTree, maar dat zou ik op elk OS doen. Er is nog geen enkele IDE die in de buurt komt van de cli of SourceTree IMO

Granted, VS2013 is wat dat betreft een stap voorwaarts tov 2008 en 2010. Maar toch...

TFS is anti-productief. Geneuzel met readonly-files, uitchecken is irritant. Uitgecheckte, maar ongewijzigde files bij "pending changes" opsommen is krankjorem. Problemen bij mergen. Three-way-diff? Nope! Buiten de IDE toegevoegde files negeren is niet meer van deze tijd. De tooling binnen en buiten de IDE is zijn geld niet waard, ook al heb je de express-versie. Het is bizar hoeveel clicks je nodig hebt om een overzicht van de wijzigingen binnen een checkin te zien, daar waar git/SourceTree het in 1 klik doet.

Sinds enige tijd gebruik ik git-tfs als bridge tussen tfs en een lokale git repository. SourceTree en de CLI als interface. Liever deze tussenstap dan direct tfs gebruiken... Brr.

Het is niet tfs als backend waar ik problemen mee heb, maar de tooling op je dev-machine. Met TFS2013 kun je git als "protocol" gebruiken, dus git-tools gebruiken om tegen de tfs repository aan te kletsen. Ik hoop dat een dezer dagen te kunnen testen.

MonoDevelop past bij geen enkel project IMO. Je bent productiever als je VS2013 in een VM opstart Groot probleem is ook dat het echt enorm moeilijk is een plugin te schrijven voor MonoDevelop. Het is dus ook niet zo alsof je even je eigen slappe aftreksel van R# kan maken. En out of the box is MonoDevelop een erg spartaanse IDE.

Da's jammer. Dan begin ik me toch af te vragen waar Mono dan wél crossplatform meerwaarde heeft? Ik zie zo nu en dan spellen gemaakt met Mono. Het is niet dat Java geen OpenGL ondersteunt, of dat de JRE niet makkelijk mee te bundelen is. Is C# voor die developers en wellicht VS dan nou de doorslaggevende rol? En is dat dan omdat ze de taal / IDE prettiger vinden? Of omdat C# / VS nou gewoon toevallig dat is wat ze kennen en geleerd hebben?

[farlane]

Caelorum schreef op zondag 22 juni 2014 @ 19:12:
Er is ooit besloten dat unmanaged resources niet automatisch worden vrijgegeven wanneer een managed object wordt gedeconstruct. Dat heeft niets te maken met dat het een wrapper rond de Win32 API is.

Natuurlijk heeft dat er wel mee te maken.

[Caelorum]

farlane schreef op zondag 22 juni 2014 @ 21:23:
[...]
Natuurlijk heeft dat er wel mee te maken.

Nee, ze hadden perfect alle resources kunnen vrijgeven in de destructor van de Bitmap class, door bijv. Dispose aan te roepen. Dat ze dat niet hebben gedaan is een designkeuze en heeft niets te maken met hoe het in Win32 wordt gedaan. Ik vermoed omdat je memory leaks kan hebben doordat de Garbage Collector soms ook niet alles kan opruimen binnen de VM vanwege bijv. circular dependancies (ik meen tegenwoordig wel). Dan heb je liever dat developers van begin af aan worden gedwongen sommige objecten te disposen (alles met IDisposable) door handmatig Dispose() aan te roepen of in een using statement te gebruiken.
Wat mij op het volgende brengt:

Fuzzillogic schreef op zondag 22 juni 2014 @ 19:52:
[...]
In Java is het soms nodig om file handles e.d. te sluiten en niet onnodig open te houden. Maar voor afbeeldingen ben ik het niet tegengekomen. Sowieso is de platformabstractie veel verder doorgevoerd in Java waardoor "unmanaged" eigenlijk niet voorkomt.[...]

Dat is dus een designkeuze en heeft voors en tegens, maar heeft weinig met platformabstractie te maken. In elk OS heb je resources die buiten de VM om worden gealloceerd. Hoe er binnen de VM vervolgens wordt omgegaan met het vrijgeven van die resources is een keuze en geen 1 manier is beter of slechter dan de andere.
Overigens moet je in Android wel specifiek de Bitmaps vrijgeven, want anders zit je met een memory leak en ben je zo door je geheugen heen. Ik vermoed dat dit wel eens bij meer implementaties van de jvm zo kan zijn.

Fuzzillogic schreef op zondag 22 juni 2014 @ 19:52:
[...]
Da's jammer. Dan begin ik me toch af te vragen waar Mono dan wél crossplatform meerwaarde heeft?[...]

Wineig buitenom de voor en nadelen van C# boven Java. Ook hier is er geen 1 beter of slechter dan de andere, maar soms is mono wel degelijk een betere keuze dan jvm of andersom. Mono is overigens wel iets meer dan gewoon .net voor linux en osx. Er zij veel subtiele en niet zo subtiele verschillen. Zie bijv. de hele Mono.* namespace en namespaces als Cairo e.d. Die zul je nooit in de .net VM gaan tegenkomen, omdat het vaak *nix of mono specifieke zaken betreft, maar ook de GC is anders dan die in de .net VM.

[...] Ik zie zo nu en dan spellen gemaakt met Mono. Het is niet dat Java geen OpenGL ondersteunt, of dat de JRE niet makkelijk mee te bundelen is. Is C# voor die developers en wellicht VS dan nou de doorslaggevende rol? En is dat dan omdat ze de taal / IDE prettiger vinden? Of omdat C# / VS nou gewoon toevallig dat is wat ze kennen en geleerd hebben?

Geen idee. De unity game engine (van Unity3d) heeft als scripting engine mono. Waarom zij voor mono hebben gekozen en niet iets anders moet je aan hun vragen. Hell, Unity levert zelfs een zwaar aangepaste MonoDevelop mee. Iets pakte in het voordeel voor mono uit boven lua of jvm. Ik vermoed dat het simpelweg eenvoudiger was mono te integreren in hun product en zodanig uit te breiden (voor UnityScript) dan dat het was om een jvm erin te stoppen.

[Voor 15% gewijzigd door Caelorum op 22-06-2014 23:28]

[HMS]

Caelorum schreef op zondag 22 juni 2014 @ 23:12:
[...]

Nee, ze hadden perfect alle resources kunnen vrijgeven in de destructor van de Bitmap class, door bijv. Dispose aan te roepen. Dat ze dat niet hebben gedaan is een designkeuze en heeft niets te maken met hoe het in Win32 wordt gedaan. Ik vermoed omdat je memory leaks kan hebben doordat de Garbage Collector soms ook niet alles kan opruimen binnen de VM vanwege bijv. circular dependancies (ik meen tegenwoordig wel). Dan heb je liever dat developers van begin af aan worden gedwongen sommige objecten te disposen (alles met IDisposable) door handmatig Dispose() aan te roepen of in een using statement te gebruiken.
Wat mij op het volgende brengt:

Het is dan ook aanbevolen om in de finalizer (destructor) van een object unmanaged resources op te ruimen, zie bijvoorbeeld MSDN: Dispose Pattern .
Het nadeel van de finalizer is dat die niet deterministisch is, je weet dus niet wanneer je resources worden opgeruimd als je het aan de GC overlaat. Om deterministisch unmanaged resources (of eigenlijk managed en unmanaged resources) op te ruimen hebben ze dus het Dispose pattern.

Daar wil ik niet mee zeggen dat de implementatie super fantastisch is, maar het ligt iets genuanceerd dan wat jij stelt .

[Caelorum]

Dat is inderdaad 1 van de andere gevolgen/mogelijke redenen Ik ga nadrukkelijk niet hier lopen verkondigen dat iets beter is dan iets anders. Zie trouwens niet hoe het genuanceerder is. Ik had daar gewoon nog even niet aan gedacht en aangestipt ^^

[farlane]

Caelorum schreef op zondag 22 juni 2014 @ 23:12:
Nee, ze hadden perfect alle resources kunnen vrijgeven in de destructor van de Bitmap class, door bijv. Dispose aan te roepen. Dat ze dat niet hebben gedaan is een designkeuze en heeft niets te maken met hoe het in Win32 wordt gedaan.

Dat het een designkeuze is lijkt me duidelijk, maar je geeft niet aan waarom deze (halfslachtige) manier gekozen is. Waarom weet jij zo zeker dat dat niets met de Win32 API te maken heeft?
Als je met die API op een efficiente manier spullen kunt opruimen zonder dat de gebruiker daar rekening mee hoeft te houden waarom zou je dan ueberhaubt het verschil gaan maken tussen managed en unmanaged resources?

Het is in mijn optiek weer een leaky abstraction.

[Woy]

@farlane: het is inderdaad een leaky abstraction, maar IMHO wel met een goede reden. Het niet deterministisch zijn v.w.b. geheugen in .NET ( en Java net zo goed ) levert een hoop voordelen op. Nou wil je in sommige gevallen wel gewoon deterministisch gedrag afdwingen, en daar is IDisposable i.c.m. het using statement IMHO een mooie oplossing voor, waar je bij Java zelf wat zult moeten regelen.

IDisposable hoeft natuurlijk niet perse alleen bij unmanaged resources gebruikt te worden, maar de reden dat het daar het meest gebruikt is, is omdat deze helemaal buiten de scope van het .NET framework liggen, en dus is de impact niet goed in te schatten door dat framework.

Het is dus niet specifiek voor .NET dat je voor het vrijgeven van die resources extra werk moet verzetten. In C# heb je dan in ieder geval nog de mogelijkheid van IDisposable/Finalizers.

Zo heeft .NET wel meer punten waar je de mogelijkheid hebt om meer "native" te werken, zoals het gebruik van pointers, en het fixen van een object op een locatie. Het zijn geen constructies die je heel veel wil gebruiken, maar ik vind het wel fijn dat je in ieder geval de mogelijkheid hebt zodat je voor die paar gevallen niet terug hoeft te vallen op bijvoorbeeld C++. Als je hele code barst van dat soort dingen had je natuurlijk beter wel voor een ander platform kunnen kiezen

[matthijsln]

Ik denk dat het punt wat Farlane probeert te maken is dat veel API's in .NET gemaakt zijn door met een schuin oog naar de huidige Windows API's te kijken en die redelijk direct te mappen in .NET stijl, maar dat er niet op een hoger abstractieniveau en met andere, niet-Microsoft API's in gedachten is gewerkt. Hierdoor zijn er denk ik niet vaak designkeuzes van Windows API's ter discussie gesteld en eventueel extra abstractielagen (om slechte designkeuzes of portabiliteitsproblemen te verhelpen) ingebouwd. Dan heb je automatisch minder oog voor portabiliteit en is het implementeren van een API op andere platformen dan Windows veel meer werk en levert mogelijk minder performance en meer compatibiliteitsproblemen/bugs op, en zal de implementatie achter die van Windows aan laggen.

Voor een platform als Java is dit misschien eerder andersom in de zin dat de API structuur meer lijkt op bestaande Unix-api's en makkelijker op Unix-achtigen te implementeren is, maar omdat Windows vanaf het eerste moment een first-class platform is geweest is dat ook meegenomen bij het ontwerp en implementatie.

Niet-Microsoft platformen zijn gewoon geen first-class citizen bij .NET en zullen dat nooit worden ook.

[Caelorum]

farlane schreef op maandag 23 juni 2014 @ 10:24:
[...] Het is in mijn optiek weer een leaky abstraction.

Dat is het zeker, maar jij impliceert meteen dat dat zou komen door Win32, zoals hier

farlane schreef op maandag 23 juni 2014 @ 10:24:
[...]Waarom weet jij zo zeker dat dat niets met de Win32 API te maken heeft? [...]

en dat betwijfel ik heel erg. Ook op linux heb je resources die buiten de VM om worden gealloceerd en moeten worden vrijgegeven. Veroorzaakt door Win32 is het niet.
Er zijn hier nu al twee redenen gegeven om het niet in de destructors/finalizers te willen doen, maar expliciet. De eerste is determinisme, welke ongetwijfeld de reden is waarom je in Android ook Bitmaps e.d. zelf moet recyclen, en de tweede (IMO net zo belangrijk) is dat tenminste vroeger (en nu nog steeds in zekere mate) de GC niet al je troep kan opruimen en je dus anders nooit zeker weet of je niet memory leakt tijdens het draaien van de applicatie.

matthijsln schreef op maandag 23 juni 2014 @ 12:37:
[...] Niet-Microsoft platformen zijn gewoon geen first-class citizen bij .NET en zullen dat nooit worden ook.

Gelukkig is mono dan ook niet het .NET Framework (en al helemaal niet de VM) en zijn er genoeg verschillen. Ik ben het wel met je eens dat het geheel allemaal iets meer low-level aanvoelt op zowel linux als windows (Ook voor *nix en posix heb je overigens een complete namespace in mono), maar het aangedragen voorbeeld van dat je moet Disposen is nou net *niet* 1 van de gevolgen van alleen voor Win32 ontwerpen, maar een ontwerpkeuze die is gemaakt om het probleem van hoe met niet VM gealloceerde resouces om te gaan. En die zul je op elk systeem hebben of dat nou Windows, linux, OSX of welk ander OS dan ook is.

Nog even los van dit alles is het .NET Framework wel redelijk platform agnostisch. Dat moest ook wel met de komst van Silverlight. Voor die tijd was het allemaal nog veel erger

[Voor 33% gewijzigd door Caelorum op 23-06-2014 12:53]

[matthijsln]

Qua Bitmaps zie ik het niet zo zeer in het opruimen maar meer in het feit dat deze in .NET System.Drawing.Bitmap heet, je in de Windows API een direct vergelijkbare functie hebt CreateBitmap(), en de Bitmap class een GetHbitmap() functie heeft wat anti-portable is, en in Java een vergelijkbare class BufferedImage heet.

Mooi dat het met .NET makkelijk is om met native Windows code samen te werken, maar dat levert je veel makkelijker unportable code op. Als je een Java JAR hebt kan je er 99.9% van uit gaan dat deze portable is ook als dat niet expliciet is vermeld. Voor een random .NET assembly schat ik dit op 0% tenzij er bij staat dat het op Mono werkt op die en die platformen.

In Mono's Bitmap vind ik die getHbitmap() methode niet eens.

Ik denk dat als je zo door alle .NET API's heen gaat je wel even door kan gaan met dit soort zaken.

edit: handles en DIB's noemde Fuzzillogic dus ook al naast expliciet Dispose() aanroepen.

[Voor 12% gewijzigd door matthijsln op 23-06-2014 13:30]

[Caelorum]

Dubbelpost ^^ scroll maar verder...

[Voor 96% gewijzigd door Caelorum op 23-06-2014 14:32]

[Caelorum]

matthijsln schreef op maandag 23 juni 2014 @ 13:22:
Qua Bitmaps zie ik het niet zo zeer in het opruimen maar meer in het feit dat deze in .NET System.Drawing.Bitmap heet, je in de Windows API een direct vergelijkbare functie hebt CreateBitmap(), en de Bitmap class een GetHbitmap() functie heeft wat anti-portable is, en in Java een vergelijkbare class BufferedImage heet.[...]

En dat allemaal omdat de class Bitmap heet in plaats van BufferedBitmap? En toevallig in de Windows API ook?
Bitmap en BufferedBitmap zijn niet eens echt vergelijkbaar, al is het alleen maar vanwege het missen van zooi om te saven naar de stream waaruit het wordt opgebouwd. Of direct een file naar bitmap te gooien door de path mee te geven in de constructor. De manier van opbouw van de frameworks is dusdanig anders dat een vergelijking op zo'n niveau niet eens meer te maken is. Ik zie ook niet waarom je de moeite doet. Ja, het .NET framework is iets minder platform agnostisch, maar het is niet allemaal doordat de onderliggende API Win32 is. Mono lekt ook genoeg door, maar werkt prima op linux met Cairo en xcb en niet met Win32.

matthijsln schreef op maandag 23 juni 2014 @ 13:22:
[...] Mooi dat het met .NET makkelijk is om met native Windows code samen te werken, maar dat levert je veel makkelijker unportable code op. Als je een Java JAR hebt kan je er 99.9% van uit gaan dat deze portable is ook als dat niet expliciet is vermeld. Voor een random .NET assembly schat ik dit op 0% tenzij er bij staat dat het op Mono werkt op die en die platformen. [...]

En ik schat het op 50% en hoe zijn we nu verder? Ik zou geen idee hebben hoeveel er daadwerkelijk wel en niet werkt van het totaal. Enige wat ik weet is dat toen ik met mono bezig was ik nooit tegen problemen ben aangelopen waardoor iets niet werkt, tenzij het overduidelijk al niet cross-platform is doordat het bijv. WPF gebruikt.

matthijsln schreef op maandag 23 juni 2014 @ 13:22:
[...] In Mono's Bitmap vind ik die getHbitmap() methode niet eens.[...]

http://docs.go-mono.com/?...awing.Bitmap.GetHbitmap()

matthijsln schreef op maandag 23 juni 2014 @ 13:22:
[...]ik denk dat als je zo door alle .NET API's heen gaat je wel even door kan gaan met dit soort zaken.[...]

Ik vermoed dat dat nog vies gaat tegenvallen...

matthijsln schreef op maandag 23 juni 2014 @ 13:22:
[...] edit: handles en DIB's noemde Fuzzillogic dus ook al naast expliciet Dispose() aanroepen.

Dat is allemaal wel leuk, maar mijn originele punt staat IMO nog steeds. Dit heeft vrijwel niets te maken met Win32, maar met een ontwerpkeuze. Als ze bij Java hadden besloten om het geheel zo te maken dat het iets dichter bij de onderliggende processen ligt dan had je ook in aanmerking gekomen met handles en dergelijken. Sterker nog met mono op linux kom je er ook mee in aanmerking, ondanks dat mono toch echt wel cross-platform is.

[matthijsln]

Caelorum schreef op maandag 23 juni 2014 @ 13:49:
[...]
En dat allemaal omdat de class Bitmap heet in plaats van BufferedBitmap? En toevallig in de Windows API ook?

Als jij denkt dat dat toeval is... Prima hoor. Is toeval.

Bitmap en BufferedBitmap zijn niet eens echt vergelijkbaar, al is het alleen maar vanwege het missen van zooi om te saven naar de stream waaruit het wordt opgebouwd. Of direct een file naar bitmap te gooien door de path mee te geven in de constructor.

Natuurlijk zijn die classes vergelijkbaar. Ze representeren allebei een afbeelding die bestaat uit een raster van pixels. Je noemt nu alleen maar utility methods die verschillen. En dat is het helepunt: in Windows heb je de LoadImage() functie die een HBITMAP handle oplevert en je dus makkelijk zo'n constructor kan maken.

De manier van opbouw van de frameworks is dusdanig anders dat een vergelijking op zo'n niveau niet eens meer te maken is. Ik zie ook niet waarom je de moeite doet. Ja, het .NET framework is iets minder platform agnostisch, maar het is niet allemaal doordat de onderliggende API Win32 is. Mono lekt ook genoeg door, maar werkt prima op linux met Cairo en xcb en niet met Win32.

"Iets minder platform agnostisch" is wel een heel sterk eufemisme voor "niet portable".

http://docs.go-mono.com/?...awing.Bitmap.GetHbitmap()

Ja, blijkbaar hebben ze heel GDI+ geport. Punt is dus dat Microsoft dat voor Windows die inspanning dus niet hoefde te maken.

Dat is allemaal wel leuk, maar mijn originele punt staat IMO nog steeds. Dit heeft vrijwel niets te maken met Win32, maar met een ontwerpkeuze. Als ze bij Java hadden besloten om het geheel zo te maken dat het iets dichter bij de onderliggende processen ligt dan had je ook in aanmerking gekomen met handles en dergelijken. Sterker nog met mono op linux kom je er ook mee in aanmerking, ondanks dat mono toch echt wel cross-platform is.

"Als ze bij Java"... Dat hebben ze dus niet gedaan. We zijn het dus eens. .NET is niet ontwikkeld voor portabiliteit en Java wel.

[Voor 15% gewijzigd door matthijsln op 23-06-2014 13:59]

[Caelorum]

matthijsln schreef op maandag 23 juni 2014 @ 13:57:
[...]
"Als ze bij Java"... Dat hebben ze dus niet gedaan. We zijn het dus eens. .NET is niet ontwikkeld voor portabiliteit en Java wel.

Nee, het punt is dat jij blijft hangen bij Microsofts .NET implementatie. Mono is zeker wel ontwikkeld voor portabiliteit en ondanks dat in jouw woorden

Fuzzillogic schreef op zaterdag 21 juni 2014 @ 00:04:
[...] .NET lekt het onderliggend platform (Windows in mijn geval) me nog veel te vaak door naar de bovengelegen .NET-laag. In Java is de platform-abstactie verder doorgevoerd.[...]

is het niet zo dat die mindere platform-abstractie in de weg zit van portabiliteit. Jou C# code zal hetzelfde doen in een mono VM op Windows als op linux als op OSX en het zal je niet eens gek veel meer werk kosten (misschien minder afhankelijk van de situatie) om het te implementeren in C#/mono dan met java en een willekeurige VM.

Kom ik ook nog terug bij Dalvik voor Android. Daar heb je ook dat het onderliggende platform doorlekt in de bovengelegen lagen en dat is ook Java. Ik vind het alleen niet heel erg netjes om een vergelijking mono vs dalvik te gaan maken (want crossplatform vs niet crossplatform). Net zo min als dat een vergelijking MS .NET vs Oracle's java-spul dat is (want niet crossplatform vs crossplatform).

[Voor 23% gewijzigd door Caelorum op 23-06-2014 14:22]

[Woy]

matthijsln schreef op maandag 23 juni 2014 @ 12:37:
Ik denk dat het punt wat Farlane probeert te maken is dat veel API's in .NET gemaakt zijn door met een schuin oog naar de huidige Windows API's te kijken en die redelijk direct te mappen in .NET stijl, maar dat er niet op een hoger abstractieniveau en met andere, niet-Microsoft API's in gedachten is gewerkt.

Dat is inderdaad wel het geval, er zijn een aantal namespaces die specifiek met MS technologie in het achterhoofd gemaakt zijn. Dat zijn dan vooral de System.Windows, System.Drawing en System.Managment.

Wat dat betreft is het helaas in Java ook niet altijd even fijn met de UI. De eerste pogingen van Java met AWT en Swing zijn ook geen onverminderd succes .

[Janoz]

Voor native GUI's kun je helemaal geen hoger abstractie niveau gebruiken. Dat werkt gewoon niet. Widgets zijn sterk verbonden met de onderliggende windowmanager. Je kunt niet zomaar een andere look en feel daarop toepassen (hoe graag winamp dat ooit ook wilde). GUI apps zou ik dan ook nooit met java doen.

Aan de andere kant, hoeveel GUI applicaties zijn er uberhaupt nog. Zo ongeveer alles verplaatst zich naar webbased. En dan heb ik het niet eens over de corporate markt. Zelfs thuis hebben de meeste mensen al servers of NAS-en met daarop applicaties en ook die werken allemaal met een web GUI.

Caelorum schreef op maandag 23 juni 2014 @ 14:16:
Net zo min als dat een vergelijking MS .NET vs Oracle's java-spul dat is (want niet crossplatform vs crossplatform).

Grappig. Jij bent juist zelf begonnen met de vergelijking .NET vs Java. en jij was degene die aandroeg dat .NET hardstikke crossplatform was ..

[Voor 23% gewijzigd door Janoz op 23-06-2014 14:35]

[Caelorum]

Janoz schreef op maandag 23 juni 2014 @ 14:32:
[...]
Grappig. Jij bent juist zelf begonnen met de vergelijking .NET vs Java. en jij was degene die aandroeg dat .NET hardstikke crossplatform was ..

Mag jij mij aanwijzen waar, want zover ik weet heb ik het altijd over Mono gehad en C# in het algemeen en ben ik alleen over MS .NET begonnen toen anderen daarover begonnen (http://gathering.tweakers.net/forum/view_message/42427569). Ik heb ook nergens gezegd dat Microsofts .NET implementatie hardstikke crossplatform is (zoals jij suggereert). .NET op zich wel in de vorm van mono's implementatie daarvan.

Ik denk dat mensen hier de moeite hebben om .NET, Microsofts implementatie daarvan en mono uit elkaar te houden. Het .NET framework wordt dan wel door Microsoft ontwikkeld, maar bestaat al lang niet meer alleen uit dingen van Microsoft. Dat hield op zodra mono langskwam.

Maar nogmaals, de hele discussie is vrij zinloos, omdat het hier niet gaat over MS .NET of zelfs maar .NET zelf, maar over mono, dat meer is dan alleen een .NET implementatie.

[Voor 29% gewijzigd door Caelorum op 23-06-2014 14:47]

[matthijsln]

Caelorum schreef op maandag 23 juni 2014 @ 14:16:
Jou C# code zal hetzelfde doen in een mono VM op Windows als op linux als op OSX

Het punt is dat (afgerond) niemand Mono op Windows gebruikt, maar wel de Microsoft VM. En omdat veel programmeurs *alleen* maar die combinatie gebruiken, je dus niet een random applicatie of library in Mono kan gebruiken. Dat is wat we bedoelen met portabiliteit.

Niemand is er in geinteresseerd dat Mono zelf portable is. Als iemand .NET zegt bedoelt hij "MS .NET".

[Voor 4% gewijzigd door matthijsln op 23-06-2014 14:50]

[Janoz]

Ik ging er inderdaad niet vanuit dat je een .NET hebt en een .NET. Als je het alleen over Mono hebt, dan begrijp ik niet waarom je dat uberhaupt als een serieus alternatief voor de JVM ziet eigenlijk.

[farlane]

matthijsln schreef op maandag 23 juni 2014 @ 12:37:
Ik denk dat het punt wat Farlane probeert te maken is dat veel API's in .NET gemaakt zijn door met een schuin oog naar de huidige Windows API's te kijken en die redelijk direct te mappen in .NET stijl, maar dat er niet op een hoger abstractieniveau en met andere, niet-Microsoft API's in gedachten is gewerkt.

Dat dus.

[Woy]

Janoz schreef op maandag 23 juni 2014 @ 14:32:
Voor native GUI's kun je helemaal geen hoger abstractie niveau gebruiken. Dat werkt gewoon niet. Widgets zijn sterk verbonden met de onderliggende windowmanager. Je kunt niet zomaar een andere look en feel daarop toepassen (hoe graag winamp dat ooit ook wilde). GUI apps zou ik dan ook nooit met java doen.

Klopt helemaal, dat is ook exact wat ik aan wilde geven. Dat de .NET GUI libs ( Winforms/WPF ) platform afhankelijk zijn is dan dus ook niet echt een argument voor/tegen java/.NET.

Aan de andere kant, hoeveel GUI applicaties zijn er uberhaupt nog. Zo ongeveer alles verplaatst zich naar webbased. En dan heb ik het niet eens over de corporate markt. Zelfs thuis hebben de meeste mensen al servers of NAS-en met daarop applicaties en ook die werken allemaal met een web GUI.

Klopt, en juist daarmee heeft MS een hele flinke stap gedaan met OWIN, en .NET vNext qua platform afhankelijkheid. Daarom denk ik ook dat voor NMe het een prima omgeving is om te doen wat hij wil.

Ik heb jaren geleden wel eens een .NET applicatie moeten porten naar Linux/Mono en eigenlijk de enige echte hindernis die ik daar tegen kwam was bij het GUI gedeelte. En dat was nog in de tijd dat MS een stuk minder bezig was met "Open Source" en vrijgeven van gegevens.

[Caelorum]

Ja, ik kan me voorstellen dat het gebrek aan libraries je in de weg kan zitten en dat dat een goede reden is om niet voor mono te kiezen, maar voor java. Maar dat is niet wat hier als reden werd gegeven.
Even vrij vertaald waren de redenen die Fuzzillogic aandroeg om niet voor MS .NET te kiezen:

1. .NET lekt het onderliggend platform teveel door
2. Twijfel over de toekomst, want MS dupliceert zooi in System.* naar Windows.* welke buiten de standaard valt
3. "C# als taal... Meh."
4. VS als IDE teleurstellend

En dan als klap op de vuurpijl om niet voor mono te kiezen: "Voor mij valt Mono al af omdat ik zelf niet voor C# / .NET zou kiezen."

Als je voor mono kiest kies je voor de ISO variant, incl. een implementatie van een groot deel van het huidige .NET framework zoals door MS is ontwikkeld en een zooi aan eigen mono specifieke zaken. Wil je crossplatform ontwikkelen in mono kies je voor alleen mono's .NET implementatie. Er zijn dan nog genoeg redenen om niet te kiezen voor mono, zoals dat een deel van de libraries gemaakt door anderen niet zullen werken.. Maar de redenen die Fuzzillogic aangaf zijn IMO niet redenen om niet voor mono te kiezen. Alleen om niet voor MS's implementatie van .NET te kiezen. Want:
[list]• .NET lekt het onderliggend platform teveel door
Dat doet mono ook inderdaad, maar dat maakt het niet minder cross-platform.
[list]• Twijfel over de toekomst, want MS dupliceert zooi in System.* naar Windows.* welke buiten de standaard valt
is niet van belang in het geval van mono. Wat MS doet moeten ze zelf weten, jouw mono applicatie is afhankelijk van het mono-team niet MS.
En dan blijven alleen nog over:

• "C# als taal... Meh."
• VS als IDE teleurstellend
• sommige libraries doen het niet

Ben zelf nog niet zoveel libraries tegengekomen die het niet doen en ook niet na wat kleine wijzigingen, maar ok. Soms heb je net die ene library nodig die inderdaad niet werkend te krijgen is.

Janoz schreef op maandag 23 juni 2014 @ 15:04:
Ik ging er inderdaad niet vanuit dat je een .NET hebt en een .NET. Als je het alleen over Mono hebt, dan begrijp ik niet waarom je dat uberhaupt als een serieus alternatief voor de JVM ziet eigenlijk.

ehh.. Waarom zou het *niet* een serieus alternatief kunnen zijn voor de JVM?

Kijk zelf maakt het me allemaal niet zoveel uit. Ik heb een lange tijd alleen met C# gewerkt, maar heb er al een jaar niets meer mee gedaan. Maar ik wordt altijd een beetje treurig als mensen een platform afwijzen op basis van, IMO, rare vooroordelen en missconcepties. JVM heeft zo zijn eigen plek, net zoals mono, MS CLR, php, c++, etc.

[Voor 19% gewijzigd door Caelorum op 23-06-2014 15:14]

[matthijsln]

Ja, maar ik word er ook kriebelig van als de woorden .NET en portabiliteit samenvallen mensen met Mono komen aanzetten. Mono werkt vast wel voor een aantal applicaties en libraries, maar het overgrote deel van de applicaties die met MS .NET op Windows zijn ontwikkeld niet. Dat zijn toch hele grote mitsen en maren qua portabiliteit.

[ThomasG]

Caelorum schreef op maandag 23 juni 2014 @ 15:06:
"C# als taal... Meh."

Als je puur "taalkundig," voorzover dat kan met programmeertalen, kijkt naar C# en Java. Dan is C# als taal zijnde in vrijwel alle vlakken beter dan Java. In veel vlakken technisch ook. Het enige nadeel, maar wel een grote, is dat er geen goede platform onafhankelijkheid is voor .NET. Als Microsoft voor een goede (MSIL) VM zorgt voor linux en OS X, met goede ondersteuning, dan is het gauw gedaan met Java. Helaas zal die tijd niet komen, of in ieder geval niet op korte termijn.

[Woy]

Je moet sowieso de .NET runtime en het .NET framework apart zien. De Mono/MS runtime zijn gewoon prima compatible.

In het .NET framework zitten inderdaad componenten die vooral op MS Windows gebouwd zijn, maar zelfs daarvan zijn de meeste in het Mono framework opgenomen. Over het algemeen zullen de meeste libraries ook wel werken. Maar er valt zeker niet te ontekennen dat daar wel een issue kan zitten m.b.t. portabiliteit.

matthijsln schreef op maandag 23 juni 2014 @ 15:22:
Mono werkt vast wel voor een aantal applicaties en libraries, maar het overgrote deel van de applicaties die met MS .NET op Windows zijn ontwikkeld niet. Dat zijn toch hele grote mitsen en maren qua portabiliteit.

Dat vindt ik ook wel weer erg sterk uitgedrukt. Bij applicaties die specifiek op windows getarget zijn zal dat ongetwijfeld het geval zijn, maar voor libraries heb ik het idee dat het overgrote gedeelte wel degelijk op Mono draait. De keren dat ik met Mono gewerkt heb, heb ik daar in ieder geval geen problemen mee ondervonden.

Maar dat neemt niet weg dat je daar voor platform onafhankelijkheid wel voor moet blijven waken, maar ook in Java zul je rekening moeten houden met het platform, bijvoorbeeld voor paden waar dingen opgeslagen worden.

ThomasG schreef op maandag 23 juni 2014 @ 15:23:
[...]
Als Microsoft voor een goede (MSIL) VM zorgt voor linux en OS X, met goede ondersteuning, dan is het gauw gedaan met Java. Helaas zal die tijd niet komen, of in ieder geval niet op korte termijn.

Maar die goede VM is er juist wel in de vorm van Mono. Het punt waar het echter nog aan schort is het Framework zelf, want daar zitten nog gaten in qua platform onafhankelijkheid.

Juist het afsplitsen van functionaliteit naar de Windows.* en Microsoft.* namespaces is wat dat betreft IMHO een goede stap, want dan word het duidelijker welke namespaces je wel en niet moet gebruiken ( of abstraheren ) als je cross-platform wil ontwikkelen.

[Voor 21% gewijzigd door Woy op 23-06-2014 15:29]

[Caelorum]

Janoz schreef op maandag 23 juni 2014 @ 15:04:
Ik ging er inderdaad niet vanuit dat je een .NET hebt en een .NET. Als je het alleen over Mono hebt, dan begrijp ik niet waarom je dat uberhaupt als een serieus alternatief voor de JVM ziet eigenlijk.

Moet hier nog even aan toevoegen dat normaal als ik en ieder ander het over .NET dan wordt inderdaad MS .NET Framework bedoeld. Niet vreemd want inderdaad de meeste mensen gebruiken die implementatie. In dit topic wordt echter specifiek over mono gepraat en dan is het belangrijk om het verschil te maken, omdat mono niet een 1-op-1 implementatie is van het .NET framework, de laatste C# versie of de CLR.

Woy schreef op maandag 23 juni 2014 @ 15:26:
[...] Maar dat neemt niet weg dat je daar voor platform onafhankelijkheid wel voor moet blijven waken, maar ook in Java zul je rekening moeten houden met het platform, bijvoorbeeld voor paden waar dingen opgeslagen worden.[...]

Komt nog bij dat als je andere platformen target met een andere implementatie, zoals bijv. Android, dat je alsnog op veel zaken moet gaan letten.


*edit*
Wil wel even iedereen bedanken voor dit mooie topic Eindelijk weer eens een fatsoenlijke discussie over een interessant onderwerp in Programming

[Voor 6% gewijzigd door Caelorum op 23-06-2014 15:35]

[matthijsln]

Haha klopt. Niet File.separator gebruiken is het grootste portabiliteitsprobleem in Java applicaties (alhoewel altijd / gebruiken wel werkt, ook op Windows).

Misschien is de situatie met Mono niet zo dramatisch als ik schetste, maar het is toch wel een orde van grootte erger dan met Java.

Ik denk dat het qua libraries ook wel minder erg is. Daarna console applicaties, dan webapplicaties (MVC, entity framework etc.), daarna GUI-applicaties qua oplopende portabiliteitsproblemen.

Bij Java heb je dat dus praktisch niet, alleen dat je GUI applicatie wel werkt maar er niet uitziet. En ik heb wel eens een leuke game geschreven in .NET gespeeld zonder dat ik merkte dat het .NET was, maar bij een spel als Minecraft is het toch altijd pijnlijk duidelijk dat het in Java geschreven is. De vaste maximale heap size van de Java-VM blijft toch altijd een vervelend iets bijvoorbeeld.

Caelorum schreef op maandag 23 juni 2014 @ 15:33:
[...]
Komt nog bij dat als je andere platformen target met een andere implementatie, zoals bijv. Android, dat je alsnog op veel zaken moet gaan letten.

Android noemt zich dan ook geen volledige Java-implementatie. Het heeft alleen de taal en een aantal core-API's (waar Oracle nu een rechtszaak over voert) overgenomen.

[Voor 19% gewijzigd door matthijsln op 23-06-2014 15:35]

[Caelorum]

Caelorum schreef op maandag 23 juni 2014 @ 15:06:
[...]
En dan blijven alleen nog over:

• "C# als taal... Meh."

[...]

Bedacht me net dat bovenstaande ook niet eens een goede reden is. Als je wilt kan je met IKVM ook gewoon java met mono doen Of anders 1 van de pakweg 20 andere talen.

matthijsln schreef op maandag 23 juni 2014 @ 15:33:
[...]
Android noemt zich dan ook geen volledige Java-implementatie. Het heeft alleen de taal en een aantal core-API's (waar Oracle nu een rechtszaak over voert) overgenomen.

Ja, ok. Het ligt met Dalvik inderdaad nog meer anders

matthijsln schreef op maandag 23 juni 2014 @ 15:22:
Ja, maar ik word er ook kriebelig van als de woorden .NET en portabiliteit samenvallen mensen met Mono komen aanzetten. Mono werkt vast wel voor een aantal applicaties en libraries, maar het overgrote deel van de applicaties die met MS .NET op Windows zijn ontwikkeld niet. Dat zijn toch hele grote mitsen en maren qua portabiliteit.

Ik vind het altijd wel interessant als mensen komen aanzetten met "overgrote", "groot deel" en "95%" niet, terwijl ik geen enkel onderzoek kan vinden die dat onderbouwt. Sterker nog, gebaseerd op verhalen van de mensen die ik ken die daadwerkelijk met mono aan de slag zijn gegaan en op basis van mijn eigen ervaring zou ik het eerder richting 50% niet gokken.
Daarnaast is 100% portabiliteit van andere libraries niet het grote punt in de keuze om mono wel of niet te gebruiken. Wat het belangrijkste is, is dat je jouw applicatie/library kan maken met mono en dat die applicatie/library portable is. Als je gaat kiezen tussen frameworks, lijkt mij, dat de volgende afweging die is van met welke je het dan als snelste (en dus goedkoopste) kan bouwen. Libraries dragen uiteraard bij aan de ontwikkelsnelheid, maar als geen enkele van die libraries die het niet doen nodig zijn voor jouw applicatie/library boeit die hele portabiliteit van andere libraries geen ruk.

Komen we terug bij de vraag in de topic-titel:

Een crossplatform service schrijven: is Mono geschikt?

En dan is het enige antwoord dat je daar op kan geven IMO: ja, mits je geen exotische libraries hoeft te gebruiken.
En datzelfde antwoord kan je ook geven op de vraag: "Een crossplatform service schrijven: is Java geschikt?" of "Een crossplatform service schrijven: is .NET geschikt?" (lees MS implementatie). Want soms heb je een library nodig die niet eens is geschreven voor java of .NET, maar voor bijv. php, c of ruby.

*edit*
oh, en uiteraard zal niemand zomaar zeggen dat .net libraries portable zijn, maar mono libraries zijn dat zeker wel. Dus als je het hebt over .NET Framework en portabiliteit hoort daar *juist* mono bij en van een ieder die mono er niet bijhaalt zou ik persoonlijk weer kriebelig worden.

[Voor 96% gewijzigd door Caelorum op 23-06-2014 16:16]

[HMS]

Met de komst van de Portable Class Libraries, plus support van Mono voor PCL, wordt het portability probleem natuurlijk steeds beheersbaarder. Veel breed toepasbare libraries shippen nu al als PCL.