mboost-dp1
Stallman langer ud efter C#
Windcape (33) skrev:
Man bør jo så lade være som udvikler, at benytte det til store queries. LINQ og Lambda expressions istedet for store komplicerede Predicates er nok den mest produktive ændring jeg har oplevet i 10 år.
Hvis
var adults = persons.Where(p => p.Age > 21);
ikke er bedre , hurtigere at kode, og mere ren kode end
List<Person> adults = new List<Person>();
foreach(Person p in people) { adults.Add(p); }
så ved jeg virkelig ikke..
Jeg er syne også at delegates og lamda expressions er glimrende features.
Det er udelukkende:
var adults = from p in persons where p.Age > 21 select p:
som jeg synes er en gimmick der aldrig burde have været tilføjet sproget.
Windcape (34) skrev:Hvis det er et problem et sprog har features man kan benytte forkert, så burde man vel også holde op med at arbejde i C/C++, fordi man kan benytte pointers?
Hvis nogen foreslog at tilføje C style pointers "as is" til Java eller et andet sprog med tilsvarende anvendelse, så ville jeg absolut mene at det var en dårlig ide.
Pointers er egentligt ikke et problem i C. C er et sprog som blev designet til visse typer opgaver hvor pointere ofte giver mening. Problemet er at C bliver brugt til mange andre typer opgaver. Og det er en fejl.
Meget af det samme gælder for C++ omend moderne C++ kan minimere problemerne meget.
I parentes bemærket har jeg ikke noget problem med pointere i C#. Den eksplicitte markering af en unsafe blok er efter min mening et ganske fornuftigt kompromis.
Windcape (34) skrev:Og med de advanceret IDE værktøjer vi har i dag, er det altså virkelig ikke et problem at finde definitionen af dem.
At IDE'en kan finde noget bedre end at man selv kan finde det ved at grep'e i koden.
Men det er en dårlig erstatning for læsbar kode.
fidomuh (36) skrev:Tjah, der er vel ikke saa meget andet at sige, end at OpenSource software kun er "frit" hvis platformen det bygger paa er fri.
Software udvilket i C# vil jeg ikke anse som reelt at vaere OpenSource, hvis jeg kan risikere at MS siger "fuck you" og nu kraever 100 mill. for en licens til at compile programmet.. :)
Eller i det hele taget bare peger med fingeren og vupti, nu er dit software 100% afhaengigt af Windows :)
Jeg kan godt følge tankegangen lidt udfra en principielt betragtning.
Men i praksis er det altså ikke sort hvidt.
Uanset hvad man vælger at udvikle i kan der komme nogen imorgen og påstå at det krænker deres FooBar patent.
Man kan så lave en risiko vurdering.
Stallmann mener at Mono har en højere risiko end gennemsnittet.
Det kan man så være enig eller uenig i.
Det er ikke noget der kan bevises - det er en vurdering.
#39
Meget relevant pointe.
Sproget C# og CLI runtime er standardiseret af ECMA og ISO. Det er meget usandsynligt at Microsoft vil kunne komme efter nogen for at implementere dem.
Hvis der er et problem, så vil problemet ligge i Mono's implementering af forskellen mellem MS .NET og CLI.
CLI er mindre end 5% af MS .NET !
Meget relevant pointe.
Sproget C# og CLI runtime er standardiseret af ECMA og ISO. Det er meget usandsynligt at Microsoft vil kunne komme efter nogen for at implementere dem.
Hvis der er et problem, så vil problemet ligge i Mono's implementering af forskellen mellem MS .NET og CLI.
CLI er mindre end 5% af MS .NET !
Windcape (43) skrev:Og dette er jo netop problemet. Det er som at være kommunist i et demokrati.
De opfordre folk til at være fanatiske, og vælge dårligere produkter, fordi de er "fri". Og værrere, det opfordre lederne af distributionerne til at gøre det mere problematisk at benytte "ikke fri" software.
Hvor relevant er det lige at benægte konkurrence i den moderne verden?
Det er ikke en korrekt beskrivelse.
FSF mener at open source egenskaben er vigtig/afgørende kriterie for softwarens værdi for brugerne.
De opfordrer folk til at bruge det bedste software ifølge deres kriterier.
Der er ikke noget i det som ikke harmonerer med Adam Smith.
Windcape (43) skrev:Det bliver den ved med at være.
Det tror jeg at du har ret i.
fidomuh (44) skrev:MS har monopol, og uanset hvordan du drejer den, er det en skidt ting for forbrugeren.
MS har en monopol lignende position på markederne for desktop OS og kontorpakker.
De har ikke monopol på programmerings sprog, servere etc. som vel må være de mest relevant for denne diskussion.
fidomuh (44) skrev:
OK?
Hvorfor det?
1) De har været bagefter de sidste 5 år.
2) Deres roadmaps indikerer at de selv planlægger at være bagefter fremover derved at der er nogen ting de ikke vil/kan implementere.
Visual Studio kan se forskel, så på IDE niveau synes jeg det er ok.arne_v (49) skrev:Det giver ikke renere kode, fordi du i C# varianten ikke kan se om Houses og Address er et field eller en property/method.
Java's underlige placering af mange klasser i irrelevante packages som f.eks. java.util skulle aldrig have haft ArrayList<T>, men istedet skulle der havde været en java.collections.
Det gør at man alligevel er afhæning af ens IDE. Mange JEE teknologier, som f.eks. JSF er 110% bygget op omkring at du benytter et IDE.
Derfor ser jeg ikke et problem med properties, da der slet ikke børe være public fields iflg. god kode skik.
Jeg er sådan set enig, men undtagelsen af LINQ2SQL.arne_v (51) skrev:Det er udelukkende:
var adults = from p in persons where p.Age > 21 select p:
som jeg synes er en gimmick der aldrig burde have været tilføjet sproget.
Jeg er helt sikker på at du kender til NHibernate, så LINQ Query Syntax istedet for HQL er vel ikke en så dårlig ting? Her for vi compile-time rettelser af vores syntax, samt auto-complete og strong-type support af vores queries.
#59
Mine editor viser forskellen på en property og en metode med et lille ikon, og det er altså til at overse når man taster, og jeg synes det bare er irriterende at man skal holde øje med om det nu er det ene eller det andet. Og mht til sparet tastearbejde er det vist til at overse med de editorer vi har idag?
Mine editor viser forskellen på en property og en metode med et lille ikon, og det er altså til at overse når man taster, og jeg synes det bare er irriterende at man skal holde øje med om det nu er det ene eller det andet. Og mht til sparet tastearbejde er det vist til at overse med de editorer vi har idag?
Jeg kan tydelig se forskel, selv i hurtig tastning.mat (61) skrev:Mine editor viser forskellen på en property og en metode med et lille ikon, og det er altså til at overse når man taster,
Og så skal man ikke bekymre sig om at se efter property metoder, imellem alle de almindelige metoder.
Det er lang nemmere at se.
Ikke til collections!mat (61) skrev:Og mht til sparet tastearbejde er det vist til at overse med de editorer vi har idag?
Getter/Setter metoder er et helvede til collections.
#62
I mine editors listes properties sammen med metoder i "intellisense", så jeg kan ikke se hvad du mener?
Derudover vil en property blive listet ved dens navn, hvor en "eksplicit" setter/getter vil hedde getSomething eller setSomething og derfor vil figurere alfabetisk. Så hvis man leder efter et eller andet behøver man ikke bladre igennem 30 properties eller metoder, men bare skrive get..
Mener du getItemAt o.l. eller hvad?
Og så skal man ikke bekymre sig om at se efter property metoder, imellem alle de almindelige metoder.
I mine editors listes properties sammen med metoder i "intellisense", så jeg kan ikke se hvad du mener?
Derudover vil en property blive listet ved dens navn, hvor en "eksplicit" setter/getter vil hedde getSomething eller setSomething og derfor vil figurere alfabetisk. Så hvis man leder efter et eller andet behøver man ikke bladre igennem 30 properties eller metoder, men bare skrive get..
Getter/Setter metoder er et helvede til collections.
Mener du getItemAt o.l. eller hvad?
Blandt andet.mat (63) skrev:Mener du getItemAt o.l. eller hvad?
Det er nok personligt om det er en fordel.mat (63) skrev:Så hvis man leder efter et eller andet behøver man ikke bladre igennem 30 properties eller metoder, men bare skrive get..
Normalt foretrækker jeg at tingene er navngivnet mere naturligt, som f.eks.:
Person.By.PostNummer
Person.Navn
Person.Alder
o.lign.
Det virker mere naturligt end f.eks.:
Person.getBy().getPostNummer();
Når ens IDE håndtere det meste alligevel, så bør vi have en mere ren syntaks. Getters/Setters er specielt fjollet, da 9/10 properties jo er begge dele, eller kun een ting, uden at foretage sig andet.
Jeg er specielt glad for auto-properties til Struct lignede klasser, da de tillader dette her:
class Person
{
public string Name { get; set; }
public int Age { get; set; }
public string Address { get; set; }
}
var me = new Person() {
Name = "Claus", Age = 22
};
Det er specielt effiktivt i forbindelse med en del web-relaterede APIs, som f.eks. RewriteRoutes i ASP.NET MVC.
Vi kan sammenligne med python eller ruby, de er jo blandet andet populære fordi at syntaxen tillader at du kan lave noget! Det er ikke låst fast i at skulle være "purt" ligesom Java, som så alligevel ikke endte op med at være purt.
Hejlsberg og co. har designet et sprog som er rart at bruge, og tillader de ting du savnede fra andre sprog, uden at have problemer med performance, compiling eller komplex code.
#64
Jeg tror også det er smag og behag (eller det er jeg ret sikker på at det er), og jeg synes som nævnt at hvis man forventer at få afleveret noget fra et objekt, eller vil sætte noget hedder det getProp og setProp :)
Jeg ved ikke om jeg er enig i at person.name er mere "naturligt" end person.getName(), men det er jo nok bare vane.
Jeg har ingen problemer med C#, til de småting jeg har lavet i det har det fungeret helt fint for mig. Det er ihvertfald en behageligere oplevelse end at gå OOP i PHP. Men lige den der moderne ting med set og get som ligner properties er ikke lige mig :)
Jeg tror også det er smag og behag (eller det er jeg ret sikker på at det er), og jeg synes som nævnt at hvis man forventer at få afleveret noget fra et objekt, eller vil sætte noget hedder det getProp og setProp :)
Jeg ved ikke om jeg er enig i at person.name er mere "naturligt" end person.getName(), men det er jo nok bare vane.
Jeg har ingen problemer med C#, til de småting jeg har lavet i det har det fungeret helt fint for mig. Det er ihvertfald en behageligere oplevelse end at gå OOP i PHP. Men lige den der moderne ting med set og get som ligner properties er ikke lige mig :)
Jeg har baggrund i ikke OOP sprog før jeg lærte Java (og senere C#).mat (65) skrev:Jeg ved ikke om jeg er enig i at person.name er mere "naturligt" end person.getName(), men det er jo nok bare vane.
Som f.eks. PHP.
Der så folk altså ingen grund til at tilføje get/set til alle metode navne, uden grund.
I Java forbliver det jo også bare en name convention (som derfor giver problemer med autocomplete og kræver styg meget XML i J2EE).
I C# er det rigtige properties, det som getters og setters entligt skulle have representeret i Java!
Dvs. i baglyset af du skal bruge reflection til at design et API med, så er properties en rigtig rigtig dejlig ting! Hvilket har vist sig at være super relevant til Web Udvikling, og dertilhørende APIs.
#66
Nu virker det så også lidt kontraintuitivt for mig at tænke på getters og setters uden objekter.
Hvad mener du?
Nu virker det så også lidt kontraintuitivt for mig at tænke på getters og setters uden objekter.
Dvs. i baglyset af du skal bruge reflection til at design et API med, så er properties en rigtig rigtig dejlig ting! Hvilket har vist sig at være super relevant til Web Udvikling, og dertilhørende APIs.
Hvad mener du?
I Java er getters defineret ved: getValue, og setters ved setValue.mat (67) skrev:Hvad mener du?
I C# er de defineret ved get; set; constructs i en block på et property.
I C# kan du med reflection se forskel. I Java, er du nød til at kigge om de første 3 tegn er get/set, og mere vigtigt, checke om begge dele er der (muligt med eet check i C#).
Og often til webudvikling, hvor du benytter et form of databinding-to-markup, er det nødvendig med ordenlig reflection.
Men også til databinding af blandt andet GUI elements, er det nødvendig med ordenlig reflection:
Eksempel kan du definere med vores Person klasse som før, definere følgende for en ListBox.
listBox.DataSource = people;
listBox.DataMember = "Name";
C# kan så kigge direkte efter en "Name" property, hvor java skal kigge efter en "getName" metode der retunere object (dvs. ikke void).
Og metoder kan så overloades i Java, hvor at properties i C# ikke kan, da de behandles som object members.
Det er meget mere simpelt at lave i C#. Det er en af grundene til at GUI binding af datasources er så meget mere simpelt i .NET, end det er i Java/Swing.
Argumentet er at du kan ændre hvad der retuneres fra en getter metode, uden at skulle refractor din kode.mazing (68) skrev:Hvis man ligger kode som laver andet end at gette/sette, i de metoder, så gør man vel noget forkert?
Med det udgangspunkt ser jeg kun auto-implemented properties i C# som en positiv ting.
Men helt ærligt, hvis Person.Age ændres til ikke at retunere personens alder, så ville jeg hellere at man bliver tvunget til at refractor, så kode reflektere fejl i andre kode dele nemmere.
Ellers skal man til og debugge helt tilbage til problemets rod.
Det er fordele og ulemper ved begge dele. Dog kan de fleste problemer ved C# Properties løses med et godt IDE.
Problemerne med Java's properties... er der stadig efter 10 år, så SUN har endelig givet ind, og nu kommer der en @property annotation i Java 7, som gør det samme som autoproperties i C# ;-)
mazing (68) skrev:Hvis man ligger kode som laver andet end at gette/sette, i de metoder, så gør man vel noget forkert?
Well, det er i hvert fald den synlige effekt.
Man kan dog lave praktiske ting bag scenen alligevel. Hvis fx. en cache bliver værdiløs efter en værdi er ændret, så vil jeg nok hellere rydde cachen i setteren, end at checke for ændringer i alle gettere.
Jeg har haft stor glæde af at logge i gettere og settere.
Plus i en hurtig vending kan det være rart at kunne indsætte grum kode i en getter eller en setter. ;-)
Windcape (70) skrev:Argumentet er at du kan ændre hvad der retuneres fra en getter metode, uden at skulle refractor din kode.
refaktorering af auto-implemented properties er da ellers ikke så besværligt..
public int Age {get;set;}
Senere finder vi ud af at vi gerne vil have et tjek på..
private int _Age;
public int Age {
get { return _Age; }
set { if(CheckAge(value)) _Age = value; }
}
Synes selv det er nemmere/hurtigere at udvide auto-implemented properties senere når behovet opstår, end at lave get/set metoder fra starten.
Det er ikke til at tage folk seriøst, som konsekvent råber fanatisme efter alle tekster med RMS, uden at gide sætte sig ind i substansen.
Manden er lynende intelligent, så kan man så være enig eller uenig, med enkelte eller flere af hans synspunkter.
Når han advarer om patenter, er der grund til at lytte alvorligt efter. For manden har været med fra starten, og kan af nogen fortælle om alle de skader patenter har forvoldt.
Manden er lynende intelligent, så kan man så være enig eller uenig, med enkelte eller flere af hans synspunkter.
Når han advarer om patenter, er der grund til at lytte alvorligt efter. For manden har været med fra starten, og kan af nogen fortælle om alle de skader patenter har forvoldt.
Argumentet stammer fra før at refractoring var så nemt som det er i dag.mazing (72) skrev:refaktorering af auto-implemented properties er da ellers ikke så besværligt..
Så det handler mere om vane i dag.
En anden ting mht. refratoring, så er get/set metoder faktisk besværligt:
String name;
public String getName()
public void setName(String value)
I Java skal du så refractor alle 3 ting. I C#, kun een med autoproperties, 2 med normale properties.
Men argumenter er som før, at man ikke bør refractor sine getters/setters, og kun ændre på hvad der retuneres i ens class-scope.
Hans måde at argumentere på er meget højtråbende, og gør måske hans fans glade, men udviklere som vælger teknologi baseret på teknik, og ikke politik, er ikke særlig glade for ham.sKIDROw (73) skrev:Det er ikke til at tage folk seriøst, som konsekvent råber fanatisme efter alle tekster med RMS, uden at gide sætte sig ind i substansen.
Manden er lynende intelligent, så kan man så være enig eller uenig, med enkelte eller flere af hans synspunkter.
Når han advarer om patenter, er der grund til at lytte alvorligt efter. For manden har været med fra starten, og kan af nogen fortælle om alle de skader patenter har forvoldt.
rms burde holde kæft mht. Mono, og lade Miguel de Icaza køre showet.
Windcape (75) skrev:men udviklere som vælger teknologi baseret på teknik, og ikke politik, er ikke særlig glade for ham.
Er det ikke lidt indlysende, når det er politik han snakker om?
Og så burde enhver tage begge dele med i sine overvejelser. Så kan man vægte det som man har lyst.
#75
Til forskel fra EUs, eller en masse andre politikere? *host* :)
Jeg tror aerlig talt at han er ligeglad med hvad hans fans synes om hvad han siger.
At adskille teknik og politik i et emne som dette, er da direkte dumt?
Du vaelger en teknik som du kan risikere ikke virker.
Naar man vaelger "x" saa kigger man paa helheden og vurderer de enkelte pros/cons ifht. hinanden.
Er man ligeglad med at ens software muligvis bliver laast til Windows, saa er det jo helt fint.
Hvis ikke, saa boer man kigge paa andre muligheder. :)
Hans måde at argumentere på er meget højtråbende
Til forskel fra EUs, eller en masse andre politikere? *host* :)
og gør måske hans fans glade
Jeg tror aerlig talt at han er ligeglad med hvad hans fans synes om hvad han siger.
men udviklere som vælger teknologi baseret på teknik, og ikke politik, er ikke særlig glade for ham.
At adskille teknik og politik i et emne som dette, er da direkte dumt?
Du vaelger en teknik som du kan risikere ikke virker.
Naar man vaelger "x" saa kigger man paa helheden og vurderer de enkelte pros/cons ifht. hinanden.
Er man ligeglad med at ens software muligvis bliver laast til Windows, saa er det jo helt fint.
Hvis ikke, saa boer man kigge paa andre muligheder. :)
Og det er op til udviklerne, som alligevel skal undersøge lov og patentkrav til deres software!fidomuh (77) skrev:At adskille teknik og politik i et emne som dette, er da direkte dumt?
Du vaelger en teknik som du kan risikere ikke virker.
Naar man vaelger "x" saa kigger man paa helheden og vurderer de enkelte pros/cons ifht. hinanden.
Er man ligeglad med at ens software muligvis bliver laast til Windows, saa er det jo helt fint.
Hvis ikke, saa boer man kigge paa andre muligheder. :)
Ikke slutbrugerne.
Folk der bruger Apple produkter ser sjældent ud til at have problemer med at deres hardware er begrænset til hvad Apple nu tillader.
#78
Det er som saadan ikke op til fodtusserne, men det er da op til dem der designer det produkt der skal udvikles?
Slutbrugerne har ikke rigtigt nogen indflydelse paa hvad du som udvilker vaelger naar du laver dit program. :)
Hvad er det da Apple begraenser paa mit hardware?
Jeg maa installere lige praecis det OS jeg lyster.
Software maessigt er der masser af begraensninger i deres API, fx til Hardware mpeg2 dekodning, men hardware maessigt ved jeg ikke lige hvad der skulle vaere :)
Og det er op til udviklerne, som alligevel skal undersøge lov og patentkrav til deres software!
Det er som saadan ikke op til fodtusserne, men det er da op til dem der designer det produkt der skal udvikles?
Ikke slutbrugerne.
Slutbrugerne har ikke rigtigt nogen indflydelse paa hvad du som udvilker vaelger naar du laver dit program. :)
Folk der bruger Apple produkter ser sjældent ud til at have problemer med at deres hardware er begrænset til hvad Apple nu tillader.
Hvad er det da Apple begraenser paa mit hardware?
Jeg maa installere lige praecis det OS jeg lyster.
Software maessigt er der masser af begraensninger i deres API, fx til Hardware mpeg2 dekodning, men hardware maessigt ved jeg ikke lige hvad der skulle vaere :)
#79
Joeh hvis dit software stiller krav til de systemer det skal køre på hos en slutbruger, så bliver du jo nødt til at tage hensyn til hvad slutbrugerne har til rådighed.
Slutbrugerne har ikke rigtigt nogen indflydelse paa hvad du som udvilker vaelger naar du laver dit program. :)
Joeh hvis dit software stiller krav til de systemer det skal køre på hos en slutbruger, så bliver du jo nødt til at tage hensyn til hvad slutbrugerne har til rådighed.
#80
Du taenker paa maalgruppen, som jo selvfoelgelig skal tages hoejde for naar man designer sit produkt.
Jeg snakker om slutbrugeren.
Slutbrugeren eksisterer foerst naar dit program er faerdigt og solgt.
Joeh hvis dit software stiller krav til de systemer det skal køre på hos en slutbruger, så bliver du jo nødt til at tage hensyn til hvad slutbrugerne har til rådighed.
Du taenker paa maalgruppen, som jo selvfoelgelig skal tages hoejde for naar man designer sit produkt.
Jeg snakker om slutbrugeren.
Slutbrugeren eksisterer foerst naar dit program er faerdigt og solgt.
C# og CLI er nu under Community Premise, hvilket i hovedregelen betyder, at Microsoft fraskriver sig en hver mulighed for at sagsøge dem, der laver åbne implementeringer (selvfølgelig forudsat, at disse ikke selv har søgsmål imod Microsoft).
#75
Og det er jeres diskussioner aldrig?.. :P
Folk som er fremsynede tager hans udmeldinger til efterretning, om de så følger dem konsekvent, er jo så deres valg. Folk der kun vælger teknik baseret på teknik, tror jo at politik de ignorerer ikke kan skade dem. Der kan i gå hen og blive meget skuffede!.
Sidder du inde med kritisk viden, er det din pligt at advare folk. RMS har INTET med Miguel at gøre, så de må jo hver gøre hvad de vil.
Hans måde at argumentere på er meget højtråbende...
Og det er jeres diskussioner aldrig?.. :P
og gør måske hans fans glade, men udviklere som vælger teknologi baseret på teknik, og ikke politik, er ikke særlig glade for ham.
Folk som er fremsynede tager hans udmeldinger til efterretning, om de så følger dem konsekvent, er jo så deres valg. Folk der kun vælger teknik baseret på teknik, tror jo at politik de ignorerer ikke kan skade dem. Der kan i gå hen og blive meget skuffede!.
rms burde holde kæft mht. Mono, og lade Miguel de Icaza køre showet.
Sidder du inde med kritisk viden, er det din pligt at advare folk. RMS har INTET med Miguel at gøre, så de må jo hver gøre hvad de vil.
Ja, det har de jo så ikke med Community Promise.fidomuh (90) skrev:Bortset fra at MS stadig har mulighed for at sagsoege folk anyway, og det egentligt bare er en "Se vi er venlige" gestus.
Jeg har indsendt det som nyhed (hvis nogen gider skrive en), så kan vi diskuttere de legale aspekter viderer der.
Som jeg ser det, er stallman's post bare MS bashing, end seriøst viden.sKIDROw (89) skrev:Sidder du inde med kritisk viden, er det din pligt at advare folk. RMS har INTET med Miguel at gøre, så de må jo hver gøre hvad de
Bare ærgeligt at det kommer et par dage før den nye annoncering af Community Promise for C#, som har været undervejs i et stykke tid.
#91
Som jeg forstod det, saa jo.
De har reelt stadig muligheden for at sagsoege dig, ganske givet under lidt mere indskraenkede muligheder, men essentielt har de stadig.
Og de har stadig muligheden for at sige "FUCK YOU LINUX!".
Cool :)
Er der da noget i hans "post" der er forkert?
Er det ikke korrekt at MS kan forhindre C# i at fungere andre steder end paa deres platforme?
Er det ikke korrekt at MS tidligere har sagsoegt folk over netop denne slags ting?
Er det ikke korrekt at MS umiddelbart har alt magt over C# og dens implementation og understoettelse ( legalt ) ? :)
Tjah, det kaldes "god timing" :P
Jeg er sikker paa at RMS kommer med en opfoelgning paa problematikken, efter CP er gaaet igennem.
Saa boer vi fortsaette debatten der :)
Som konklusion kan man vel sige at ingen kan brokke sig over at man advarer om problematikker ved "x"?
Der er ingen der siger du skal sutte den brede og danse efter RMS' fanatisme, saa hvad skade er der i at faa problemstillinger frem i lyset? :)
Ja, det har de jo så ikke med Community Promise.
Som jeg forstod det, saa jo.
De har reelt stadig muligheden for at sagsoege dig, ganske givet under lidt mere indskraenkede muligheder, men essentielt har de stadig.
Og de har stadig muligheden for at sige "FUCK YOU LINUX!".
Jeg har indsendt det som nyhed (hvis nogen gider skrive en), så kan vi diskuttere de legale aspekter viderer der.[/quote]
Cool :)
Som jeg ser det, er stallman's post bare MS bashing, end seriøst viden.
Er der da noget i hans "post" der er forkert?
Er det ikke korrekt at MS kan forhindre C# i at fungere andre steder end paa deres platforme?
Er det ikke korrekt at MS tidligere har sagsoegt folk over netop denne slags ting?
Er det ikke korrekt at MS umiddelbart har alt magt over C# og dens implementation og understoettelse ( legalt ) ? :)
Bare ærgeligt at det kommer et par dage før den nye annoncering af Community Promise for C#, som har været undervejs i et stykke tid.
Tjah, det kaldes "god timing" :P
Jeg er sikker paa at RMS kommer med en opfoelgning paa problematikken, efter CP er gaaet igennem.
Saa boer vi fortsaette debatten der :)
Som konklusion kan man vel sige at ingen kan brokke sig over at man advarer om problematikker ved "x"?
Der er ingen der siger du skal sutte den brede og danse efter RMS' fanatisme, saa hvad skade er der i at faa problemstillinger frem i lyset? :)
Nej. Ikke for de dele som er ECMA. Hvilket faktisk er en del til meget software.fidomuh (92) skrev:#91
Som jeg forstod det, saa jo.
De har reelt stadig muligheden for at sagsoege dig, ganske givet under lidt mere indskraenkede muligheder, men essentielt har de stadig. Og de har stadig muligheden for at sige "FUCK YOU LINUX!".
Så det er lidt på niveau med C/C++ nu, hvor du jo også kan benytte lukkede libs.
Er der da noget i hans "post" der er forkert?Nej.
Er det ikke korrekt at MS kan forhindre C# i at fungere andre steder end paa deres platforme?
Er det ikke korrekt at MS tidligere har sagsoegt folk over netop denne slags ting?Nej, det er ikke min opfattelse af det. Jeg har aldrig set et søgsmål over Wine eller Visual C++.
Er det ikke korrekt at MS umiddelbart har alt magt over C# og dens implementation og understoettelse ( legalt ) ? :)Indtil i dag, ja. Efter i dag, nej.
Tjah, det kaldes "god timing" :PTjah, det er jo baseret på en ældre diskussion, og ikke stallmans nyhedsbrev.
Jeg er sikker paa at RMS kommer med en opfoelgning paa problematikken, efter CP er gaaet igennem.
Som konklusion kan man vel sige at ingen kan brokke sig over at man advarer om problematikker ved "x"?At Microsoft er hamrende ligeglade med hvad stallman siger.
Der er ingen der siger du skal sutte den brede og danse efter RMS' fanatisme, saa hvad skade er der i at faa problemstillinger frem i lyset? :)
Miquel til gengæld, har det jo lykkeds en hel del for, som det CP vi ser nu.
#93
Men hvor meget er saa ikke ECMA?
Men det er stadig ikke helt det samme.
Uanset hvad MS og andre synes om C, saa kan jeg altid bruge det og compilere, platforme, etc er helt frigivet.
Okay, saa hvis MS nu siger at C# er Windows-only og de sagsoeger alle andre implementationer af det, saa er det altsaa ikke en "forhindring" ? :)
Nu skrev jeg lignende sager, men vi kan jo kigge paa FAT og linux, fx.
Jeg er stadig ved at laese op paa CP, maa jeg indroemme, men indtil videre ser det ud til at MS stadig sidder med den store "FUCK YOU"-knap i haanden.
Korrekt, min pointe var mere at Stallman sikkert braeger mere varm luft ud paa internettet efter CP gaar igennem ;)
Jeg tror nu heller ikke at MS er Stallmans maalgruppe.
Det er langt mere sandsynligt at hans maalgruppe er folk som dig, der umiddelbart er floejtende ligeglade med om et enkelt firma kan diktere hvilken platform dit software kan koere paa.
Og?
Stallmans advarsel er stadig relevant.
Det er ikke Stallmans opgave at soerge for at MS ikke er roevhuller, derimod er det ganske venligt af ham at fortaelle andre at de muligvis kan vaere det. :)
Nej. Ikke for de dele som er ECMA. Hvilket faktisk er en del til meget software.
Men hvor meget er saa ikke ECMA?
Så det er lidt på niveau med C/C nu, hvor du jo også kan benytte lukkede libs.
Men det er stadig ikke helt det samme.
Uanset hvad MS og andre synes om C, saa kan jeg altid bruge det og compilere, platforme, etc er helt frigivet.
Nej.
Okay, saa hvis MS nu siger at C# er Windows-only og de sagsoeger alle andre implementationer af det, saa er det altsaa ikke en "forhindring" ? :)
Nej, det er ikke min opfattelse af det. Jeg har aldrig set et søgsmål over Wine eller Visual C .
Nu skrev jeg lignende sager, men vi kan jo kigge paa FAT og linux, fx.
Indtil i dag, ja. Efter i dag, nej.
Jeg er stadig ved at laese op paa CP, maa jeg indroemme, men indtil videre ser det ud til at MS stadig sidder med den store "FUCK YOU"-knap i haanden.
Tjah, det er jo baseret på en ældre diskussion, og ikke stallmans nyhedsbrev.
Korrekt, min pointe var mere at Stallman sikkert braeger mere varm luft ud paa internettet efter CP gaar igennem ;)
At Microsoft er hamrende ligeglade med hvad stallman siger.
Jeg tror nu heller ikke at MS er Stallmans maalgruppe.
Det er langt mere sandsynligt at hans maalgruppe er folk som dig, der umiddelbart er floejtende ligeglade med om et enkelt firma kan diktere hvilken platform dit software kan koere paa.
Miquel til gengæld, har det jo lykkeds en hel del for, som det CP vi ser nu.
Og?
Stallmans advarsel er stadig relevant.
Det er ikke Stallmans opgave at soerge for at MS ikke er roevhuller, derimod er det ganske venligt af ham at fortaelle andre at de muligvis kan vaere det. :)
Compilere af C# er frit nu. Microsoft har sagt de ikke vil sagsøge folk.fidomuh (94) skrev:Uanset hvad MS og andre synes om C, saa kan jeg altid bruge det og compilere, platforme, etc er helt frigivet.
Bare fordi at folk ikke vælger GPL som deres licens, betyder det ikke at det ikke er frit nok.
CP handler jo netop om at de ikke kan gøre C# windows-only mere.fidomuh (94) skrev:Okay, saa hvis MS nu siger at C# er Windows-only og de sagsoeger alle andre implementationer af det, saa er det altsaa ikke en "forhindring" ? :)
Andet har heller aldrig givet mening. Det ville være som at gøre COBOL OS/400 only :p
fidomuh (94) skrev:Men hvor meget er saa ikke ECMA?
Som jeg kan forstå det , alt andet end:
WPF (XAML som led i Monolight versionen af Silverlight er open-source).
ASP.NET
ADO.NET (Der er nHibernate og andre bedre alternativer alligevel).
WinForms
Det bliver mere klargjort når Mono teamet har splittet de 2 projekter mere explicit.
Microsoft vil bare sådan set, bevare rettighederne over deres egne biblioteker, og det giver jo også fin mening. Størstedelen af de ting som ikke er med i CP, er alligevel meget windows-baseret biblioteker.
Det er vigtigere at C# som sprog (og dermed LINQ, Extension Methods, og XAML) er frie.
#95
Jojo, hvad de siger og hvad de goer haenger bare ikke altid sammen.
Hvor har jeg snakket om GPL da?
"x" er ikke 'frit nok' hvis det ikke er 'frit', imo.
Specielt naar det kommer til udviklingsplatforme.
Det forstod jeg, jeg synes bare ikke det virker helt som den "frigivelse" de proever at faa det til at lyde som.
Ikke at jeg er imod CP overhovedet, jeg forholder mig bare skeptisk :)
Det giver fin mening for MS.
Ligesom deres meget snaevre tilladelse til brug af DirectX, fx.
#96
Joeh, man kan godt bevare rettighederne og saa frigive brugen af dem.
Hvilket saa underbygger min pointe om at MS stadig holder visse C#-ting som Windows-only.
Enig, det betyder dog ikke at jeg vil vaelge C# som sprog, naar platformen jeg skal bruge ikke hedder MS. :)
Compilere af C# er frit nu. Microsoft har sagt de ikke vil sagsøge folk.
Jojo, hvad de siger og hvad de goer haenger bare ikke altid sammen.
Bare fordi at folk ikke vælger GPL som deres licens, betyder det ikke at det ikke er frit nok.
Hvor har jeg snakket om GPL da?
"x" er ikke 'frit nok' hvis det ikke er 'frit', imo.
Specielt naar det kommer til udviklingsplatforme.
CP handler jo netop om at de ikke kan gøre C# windows-only mere.
Det forstod jeg, jeg synes bare ikke det virker helt som den "frigivelse" de proever at faa det til at lyde som.
Ikke at jeg er imod CP overhovedet, jeg forholder mig bare skeptisk :)
Andet har heller aldrig givet mening.
Det giver fin mening for MS.
Ligesom deres meget snaevre tilladelse til brug af DirectX, fx.
#96
Microsoft vil bare sådan set, bevare rettighederne over deres egne biblioteker, og det giver jo også fin mening.
Joeh, man kan godt bevare rettighederne og saa frigive brugen af dem.
Størstedelen af de ting som ikke er med i CP, er alligevel meget windows-baseret biblioteker.
Hvilket saa underbygger min pointe om at MS stadig holder visse C#-ting som Windows-only.
Det er vigtigere at C# som sprog (og dermed LINQ, Extension Methods, og XAML) er frie.
Enig, det betyder dog ikke at jeg vil vaelge C# som sprog, naar platformen jeg skal bruge ikke hedder MS. :)
En bindende stykke lovpapir skulle hænge ret meget sammen.fidomuh (97) skrev:Jojo, hvad de siger og hvad de goer haenger bare ikke altid sammen
Hvor har jeg snakket om GPL da?Meget af .NET er open-source under Microsoft's egne licenser. FSF græder bare hver gang man benytter en ikke-GPL licens.
"x" er ikke 'frit nok' hvis det ikke er 'frit', imo.
Hvilket saa underbygger min pointe om at MS stadig holder visse C#-ting som Windows-only.Nej, ikke C#, men .NET.
Du skal seperere Framework/Platform og Sprog. Ellers skal vi også sige at C er Windows-only pga. WINAPI.
Og det handler om at gøre C# fri, ikke .NET
Enig, det betyder dog ikke at jeg vil vaelge C# som sprog, naar platformen jeg skal bruge ikke hedder MS. :)Hvad vil du så benytte istedet?
Folk vælger jo C# istedet for C++ af grunde. Specielt Mono udviklere gør det fordi de godt kan lide sproget.
Acro (88) skrev:C# og CLI er nu under Community Premise, hvilket i hovedregelen betyder, at Microsoft fraskriver sig en hver mulighed for at sagsøge dem, der laver åbne implementeringer (selvfølgelig forudsat, at disse ikke selv har søgsmål imod Microsoft).
Windcape (93) skrev:Nej. Ikke for de dele som er ECMA. Hvilket faktisk er en del til meget software.
Windcape (96) skrev:Som jeg kan forstå det , alt andet end:
WPF (XAML som led i Monolight versionen af Silverlight er open-source).
ASP.NET
ADO.NET (Der er nHibernate og andre bedre alternativer alligevel).
WinForms
Læste I ikke:
arne_v (55) skrev:CLI er mindre end 5% af MS .NET !
eller har I ikke meget tiltro til min vurdering??
ECMA-335 alias CLI indeholder 331 klasser med 3263 members (ekskl. constructors).
MS .NET 3.5 indeholder 10033 klasser med 287915 members (jeg har kun talt mscorlib.dll og System.*.dll assemblies, constructors er igen ignoreret).
Man kan kritisere Mono for kun at indeholde 95% af MS .NET, fordi det kan give kompabilitets problemer.
Men CLI indeholder kun 3.3% af klasserne og 1.1% af members.
Kan vi ikke godt blive enige om at en meget stor del af .NET apps bruger nogle af de manglende dele?
CLI er ikke i samme klasse som MS .NET (eller Java eller PHP) med hensyn til funktionalitet.
CLI er i klasse med (ANSI) C.
#99
Jeg kan poste listen med CLI klasser, så kan I vurdere om I kan nøjes med dem:
Jeg kan poste listen med CLI klasser, så kan I vurdere om I kan nøjes med dem:
System.Action<T>
System.AppDomain
System.ApplicationException
System.ArgumentException
System.ArgumentNullException
System.ArgumentOutOfRangeException
System.ArithmeticException
System.Array
System.ArrayTypeMismatchException
System.AssemblyLoadEventArgs
System.AssemblyLoadEventHandler
System.AsyncCallback
System.Attribute
System.AttributeTargets
System.AttributeUsageAttribute
System.BadImageFormatException
System.Boolean
System.Byte
System.CannotUnloadAppDomainException
System.Char
System.CharEnumerator
System.CLSCompliantAttribute
System.Comparison<T>
System.Console
System.Convert
System.Converter<T,U>
System.DateTime
System.Decimal
System.Delegate
System.DivideByZeroException
System.Double
System.DuplicateWaitObjectException
System.EntryPointNotFoundException
System.Enum
System.Environment
System.EventArgs
System.EventHandler
System.Exception
System.ExecutionEngineException
System.FieldAccessException
System.FlagsAttribute
System.FormatException
System.GC
System.IAsyncResult
System.ICloneable
System.IComparable
System.IComparable<T>
System.IDisposable
System.IEquatable<T>
System.IFormatProvider
System.IFormattable
System.IndexOutOfRangeException
System.Int16
System.Int32
System.Int64
System.IntPtr
System.INullableValue
System.InvalidCastException
System.InvalidOperationException
System.InvalidProgramException
System.MarshalByRefObject
System.Math
System.MemberAccessException
System.MethodAccessException
System.MissingFieldException
System.MissingMemberException
System.MissingMethodException
System.NotFiniteNumberException
System.NotImplementedException
System.NotSupportedException
System.Nullable<T>
System.NullReferenceException
System.Object
System.ObjectDisposedException
System.ObsoleteAttribute
System.OutOfMemoryException
System.OverflowException
System.ParamArrayAttribute
System.Predicate<T>
System.Random
System.RankException
System.RuntimeArgumentHandle
System.RuntimeFieldHandle
System.RuntimeMethodHandle
System.RuntimeTypeHandle
System.SByte
System.Single
System.StackOverflowException
System.String
System.SystemException
System.Threading.Thread
System.ThreadStaticAttribute
System.TimeSpan
System.Type
System.TypedReference
System.TypeInitializationException
System.TypeLoadException
System.TypeUnloadedException
System.UInt16
System.UInt32
System.UInt64
System.UIntPtr
System.UnauthorizedAccessException
System.UnhandledExceptionEventArgs
System.UnhandledExceptionEventHandler
System.Uri
System.UriBuilder
System.UriFormatException
System.UriHostNameType
System.UriPartial
System.ValueType
System.Version
System.Void
System.Collections.ArrayList
System.Collections.Comparer
System.Collections.DictionaryEntry
System.Collections.Hashtable
System.Collections.ICollection
System.Collections.IComparer
System.Collections.IDictionary
System.Collections.IDictionaryEnumerator
System.Collections.IEnumerable
System.Collections.IEnumerator
System.Collections.IHashCodeProvider
System.Collections.IList
System.Collections.Generic.Dictionary<TKey,TValue>
System.Collections.Generic.Dictionary<TKey,TValue>.Enumerator
System.Collections.Generic.Dictionary<TKey,TValue>.KeyCollection
System.Collections.Generic.Dictionary<TKey,TValue>.KeyCollection.Enumerator
System.Collections.Generic.Dictionary<TKey,TValue>.ValueCollection
System.Collections.Generic.Dictionary<TKey,TValue>.ValueCollection.Enumerator
System.Collections.Generic.ICollection<T>
System.Collections.Generic.IComparer<T>
System.Collections.Generic.IDictionary<TKey,TValue>
System.Collections.Generic.IEnumerable<T>
System.Collections.Generic.IEnumerator<T>
System.Collections.Generic.IEqualityComparer<T>
System.Collections.Generic.IList<T>
System.Collections.Generic.KeyNotFoundException
System.Collections.Generic.KeyValuePair<K,V>
System.Collections.Generic.List<T>
System.Collections.Generic.List<T>.Enumerator
System.Collections.Specialized.NameValueCollection
System.Diagnostics.ConditionalAttribute
System.Globalization.CultureInfo
System.Globalization.DateTimeFormatInfo
System.Globalization.DateTimeStyles
System.Globalization.NumberFormatInfo
System.Globalization.NumberStyles
System.Globalization.UnicodeCategory
System.IO.Directory
System.IO.DirectoryNotFoundException
System.IO.EndOfStreamException
System.IO.File
System.IO.FileAccess
System.IO.FileLoadException
System.IO.FileMode
System.IO.FileNotFoundException
System.IO.FileShare
System.IO.FileStream
System.IO.IOException
System.IO.MemoryStream
System.IO.Path
System.IO.PathTooLongException
System.IO.SeekOrigin
System.IO.Stream
System.IO.StreamReader
System.IO.StreamWriter
System.IO.StringReader
System.IO.StringWriter
System.IO.TextReader
System.IO.TextWriter
System.Net.AuthenticationManager
System.Net.Authorization
System.Net.CredentialCache
System.Net.Dns
System.Net.DnsPermission
System.Net.DnsPermissionAttribute
System.Net.EndPoint
System.Net.GlobalProxySelection
System.Net.HttpContinueDelegate
System.Net.HttpStatusCode
System.Net.HttpVersion
System.Net.HttpWebRequest
System.Net.HttpWebResponse
System.Net.IAuthenticationModule
System.Net.ICredentials
System.Net.IPAddress
System.Net.IPEndPoint
System.Net.IPHostEntry
System.Net.IWebProxy
System.Net.IWebRequestCreate
System.Net.NetworkAccess
System.Net.NetworkCredential
System.Net.ProtocolViolationException
System.Net.ServicePoint
System.Net.ServicePointManager
System.Net.Sockets.Socket
System.Net.SocketAddress
System.Net.SocketPermission
System.Net.SocketPermissionAttribute
System.Net.TransportType
System.Net.WebClient
System.Net.WebException
System.Net.WebExceptionStatus
System.Net.WebHeaderCollection
System.Net.WebPermission
System.Net.WebPermissionAttribute
System.Net.WebProxy
System.Net.WebRequest
System.Net.WebResponse
System.Net.Sockets.AddressFamily
System.Net.Sockets.LingerOption
System.Net.Sockets.MulticastOption
System.Net.Sockets.NetworkStream
System.Net.Sockets.ProtocolType
System.Net.Sockets.SelectMode
System.Net.Sockets.SocketException
System.Net.Sockets.SocketFlags
System.Net.Sockets.SocketOptionLevel
System.Net.Sockets.SocketOptionName
System.Net.Sockets.SocketShutdown
System.Net.Sockets.SocketType
System.Reflection.AmbiguousMatchException
System.Reflection.Assembly
System.Reflection.Binder
System.Reflection.BindingFlags
System.Reflection.ConstructorInfo
System.Reflection.DefaultMemberAttribute
System.Reflection.EventAttributes
System.Reflection.EventInfo
System.Reflection.FieldAttributes
System.Reflection.FieldInfo
System.Reflection.GenericParameterAttributes
System.Reflection.MemberInfo
System.Reflection.MethodAttributes
System.Reflection.MethodBase
System.Reflection.MethodInfo
System.Reflection.Module
System.Reflection.ParameterAttributes
System.Reflection.ParameterInfo
System.Reflection.ParameterModifier
System.Reflection.PropertyAttributes
System.Reflection.PropertyInfo
System.Reflection.TargetException
System.Reflection.TargetInvocationException
System.Reflection.TargetParameterCountException
System.Reflection.TypeAttributes
System.Runtime.CompilerServices.CompilationRelaxations
System.Runtime.CompilerServices.CompilationRelaxationsAttribute
System.Runtime.CompilerServices.DecimalConstantAttribute
System.Runtime.CompilerServices.IndexerNameAttribute
System.Runtime.CompilerServices.IsVolatile
System.Runtime.CompilerServices.MethodImplAttribute
System.Runtime.CompilerServices.MethodImplOptions
System.Runtime.CompilerServices.RuntimeHelpers
System.Runtime.InteropServices.CallingConvention
System.Runtime.InteropServices.CharSet
System.Runtime.InteropServices.DllImportAttribute
System.Runtime.InteropServices.FieldOffsetAttribute
System.Runtime.InteropServices.GCHandle
System.Runtime.InteropServices.GCHandleType
System.Runtime.InteropServices.InAttribute
System.Runtime.InteropServices.LayoutKind
System.Runtime.InteropServices.MarshalAsAttribute
System.Runtime.InteropServices.OutAttribute
System.Runtime.InteropServices.StructLayoutAttribute
System.Runtime.InteropServices.UnmanagedType
System.Security.CodeAccessPermission
System.Security.IPermission
System.Security.PermissionSet
System.Security.SecurityElement
System.Security.SecurityException
System.Security.VerificationException
System.Security.Permissions.CodeAccessSecurityAttribute
System.Security.Permissions.EnvironmentPermission
System.Security.Permissions.EnvironmentPermissionAccess
System.Security.Permissions.EnvironmentPermissionAttribute
System.Security.Permissions.FileIOPermissionAccess
System.Security.Permissions.FileIOPermissionAttribute
System.Security.Permissions.PermissionState
System.Security.Permissions.ReflectionPermission
System.Security.Permissions.ReflectionPermissionAttribute
System.Security.Permissions.ReflectionPermissionFlag
System.Security.Permissions.SecurityAction
System.Security.Permissions.SecurityAttribute
System.Security.Permissions.SecurityPermission
System.Security.Permissions.SecurityPermissionAttribute
System.Security.Permissions.SecurityPermissionFlag
System.Text.ASCIIEncoding
System.Text.Decoder
System.Text.Encoder
System.Text.Encoding
System.Text.StringBuilder
System.Text.UnicodeEncoding
System.Text.UTF8Encoding
System.Threading.Interlocked
System.Threading.Monitor
System.Threading.SynchronizationLockException
System.Threading.ThreadAbortException
System.Threading.ThreadPriority
System.Threading.ThreadStart
System.Threading.ThreadState
System.Threading.ThreadStateException
System.Threading.Timeout
System.Threading.Timer
System.Threading.TimerCallback
System.Threading.WaitHandle
System.Threading.Parallel.ParallelEnvironment
System.Threading.Parallel.ParallelFor
System.Threading.Parallel.ParallelForEach<T>
System.Threading.Parallel.ParallelLoop<T>
System.Threading.Parallel.ParallelWhile<T>
System.Xml.Formatting
System.Xml.NameTable
System.Xml.ReadState
System.Xml.WhitespaceHandling
System.Xml.WriteState
System.Xml.XmlConvert
System.Xml.XmlException
System.Xml.XmlNamespaceManager
System.Xml.XmlNameTable
System.Xml.XmlNodeType
System.Xml.XmlParserContext
System.Xml.XmlReader
System.Xml.XmlResolver
System.Xml.XmlSpace
System.Xml.XmlTextReader
System.Xml.XmlTextWriter
System.Xml.XmlUrlResolver
System.Xml.XmlWriter
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund