mboost-dp1
Stallman langer ud efter C#
Windcape (59) skrev:Visual Studio kan se forskel, så på IDE niveau synes jeg det er ok.
I min VC# Express er de begge sorte og helt ens typografisk.
Men selvom de kan color codes af IDE'en så er det stadig en nødløsning fremfor en egentlig syntax forskel.
Windcape (59) skrev: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 er jeg helt enig i.
Historisk bagage. Da den beslutning blev truffer var det kun Vector og Hashtable, hvorfor en package måske var lidt overdimensioneret. Collections framework kom så i version 1.2, men da Vector og Hashtable blev retrofittet ind i det, så kunne man ikke så godt flytte.
Windcape (59) skrev: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.
Der er ikke ret mange JSF udviklere som baserer sig 110% på en IDE.
Generelt er Java folket langt mindre IDE orienteret end MS folket.
Windcape (59) skrev:Derfor ser jeg ikke et problem med properties, da der slet ikke børe være public fields iflg. god kode skik.
Problemet findes såmænd også med ikke public fields/properties.
Windcape (60) skrev:Jeg er sådan set enig, men undtagelsen af LINQ2SQL.
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.
Jeg er faktisk ikke specielt glad for alle de ORM specifikke QL (HQL, EJB QL whatever).
Jeg foretrækker standard QL d.v.s. SQL.
Men jeg indrømmer at det ikke altid passer så godt med ORM.
Compile time type check på QL er elegant, men det er efter min bedste overbevisning en genial løsning på et ikke eksisterende problem. Diverse type fejl i SQL har aldrig været et stort problem i den mere seriøse del af software udvikling (og den mindre seriøse kan næppe finde ud af LINQ alligevel).
Windcape (66) skrev:I Java forbliver det jo også bare en name convention (som derfor giver problemer med autocomplete og kræver styg meget XML i J2EE).
Autocomplete virker skam fint med getters og setters.
Der er mange XML filer i Java EE, men det har ikke noget med bean konventionen at gøre - det skyldes:
1) at mange af kerne API'erne er fra før Java fik annotations
2) tradition
Windcape (69) skrev:I Java er getters defineret ved: getValue, og setters ved setValue.
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.
Java og C# er helt ens her.
I Java kan du:
- lave det simpelt med PropertyDescriptor
- bruge class getMethods og teste på navne prefix m.v.
I C#/.NET kan du:
- lave det simpelt med Type GetProperty
- bruge Type GetMembers og teste på attributter m.v.
Windcape (69) skrev: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.
Jeg tror godt at Swing udviklerne kan finde ud af at bruge PropertyDescriptor.
:-)
Man kan være mere tvivlende overfor om de forstår at lave developer venligt GUI framework.
mazing (68) skrev:Hvis man ligger kode som laver andet end at gette/sette, i de metoder, så gør man vel noget forkert?
Hele grunden til at man bruger properties er at man har mulighed for at gøre noget mere.
Hvis man var 112% sikke rpå at man aldrig ville lave noget mere kunne man lige så godt bruge fields (ihvertfald hvis vi ignorerer virtual/override aspektet).
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.
Der er vel betydeligt mere substans i denne tråd end i så mange andre tilsvarende tråde,
sKIDROw (73) skrev:Manden er lynende intelligent, så kan man så være enig eller uenig, med enkelte eller flere af hans synspunkter.
Det kan der vist ikke herske tvivl om.
sKIDROw (73) skrev: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.
Han har så vidt jeg ved ikke nogle specielle kvalifikationer til at vurdere patenter. Han har en IT uddannelse - ikke en jurist uddannelse. Han har uviklet en verdenskendt editor (Emacs), fortolker (Lisp) og compiler (GCC). Han har stiftet en meget successfuld open source organisation (FSF). Men ingen af disse giver specielle kvalifikationer sammenlignet med en tilfældig dansker som har læst CW i 10+ år.
Windcape (78) skrev:Og det er op til udviklerne, som alligevel skal undersøge lov og patentkrav til deres software!
Det er en ret håbløs opgave i praksis.
Det vil koste >100000 udvikler time og >16000 advokat timer for en software applikation.
Det er de færreste software applikationer som har økonomi til det.
fidomuh (83) skrev:Jeg mener "slutbruger" som i, ham der HAR koebt produktet.
Du mener "maalgruppen" som i, ham der skal til, eller boer, koebe produktet.
Det er ikke hvad slutbruger og målgruppe betyder.
Slutbruger er dem som skal bruge produktet.
Målgruppe er dem man designer produktet til - det er i første led dem som skal betale for produktet, men i andet led er det slutbrugerne.
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.
fidomuh (92) skrev:De har reelt stadig muligheden for at sagsoege dig, ganske givet under lidt mere indskraenkede muligheder, men essentielt har de stadig.
De har afgivet et juridisk bindende tilsagn om ikke at sagsøge folk for at implementere ECMA-334 (C#) og ECMA-335 (CLI).
Eneste undtagelse er hvis du selv sagsøger Microsoft for disse to specifikationer (hvilket virker rimeligt).
Så det er langt mere end en venlig gestus.
(problemerne ligger i forskellen mellem CLI og MS .NET)
fidomuh (92) skrev:Er det ikke korrekt at MS kan forhindre C# i at fungere andre steder end paa deres platforme?
Nej.
Sproget C# kan de ikke længere forhindre implementationer af.
fidomuh (92) skrev:Er det ikke korrekt at MS tidligere har sagsoegt folk over netop denne slags ting?
De har sagsøgt for patenter på bl.a. filsystemer. Om det er "denne slags ting" ved jeg ikke.
fidomuh (92) skrev:Er det ikke korrekt at MS umiddelbart har alt magt over C# og dens implementation og understoettelse ( legalt ) ?
Nej.
Den magt ligger hos ECMA (og ISO).
Windcape (93) skrev:Nej. Ikke for de dele som er ECMA. Hvilket faktisk er en del til meget software.
Jeps.
Windcape (93) skrev:Så det er lidt på niveau med C/C++ nu, hvor du jo også kan benytte lukkede libs.
Jeps.
Windcape (93) skrev:Indtil i dag, ja. Efter i dag, nej.
Jeg mener ikke at det er så nyt.
Det er snarere en udvidelse/præcisering.
ECMA og ISO har allerede fået nogle løfter:
http://www.ecma-international.org/publications/fil...
http://www.ecma-international.org/publications/fil...
ECMA og ISO accepterer ikke noget som man ikke kan implementere - det giver ikke meget mening at have en standard som man ikke kan implementere.
fidomuh (94) skrev:Uanset hvad MS og andre synes om C, saa kan jeg altid bruge det og compilere, platforme, etc er helt frigivet.
C og C# er ikke så forskellige.
Du kan frit implementere C og C standard libs.
Du kan ikke nødvendigvis frit implementere andre C libs.
Du kan frit implementere C# og CLI.
Du kan ikke nødvendigvis frit implementere andre .NET libs.
Det sidste inkluderer den del af MS .NET som ikke er med i CLI. Og det er altså >95% !
Men CLI svarer meget godt til C standard lib.
CLI er langt mindre end Java og PHP standard libs.
#98
Bare fordi du ikke kan lide RMS og FSF, er der ingen grund til at lyve. FSF har intet problem med andre frie licenser, de syntes så det er uheldigt, hvis det er under GPL-inkompatible licenser. Men en fri inkompatibel licens, er til enhver tid bedre end en ufri licens.
Meget af .NET er open-source under Microsoft's egne licenser. FSF græder bare hver gang man benytter en ikke-GPL licens.
Bare fordi du ikke kan lide RMS og FSF, er der ingen grund til at lyve. FSF har intet problem med andre frie licenser, de syntes så det er uheldigt, hvis det er under GPL-inkompatible licenser. Men en fri inkompatibel licens, er til enhver tid bedre end en ufri licens.
Nå, har de bestemt sig om igen. Jeg må indrømme at jeg ikke følger aktivt med i Java 7 specs, så det er nok uddateret igen.arne_v (106) skrev:Nogen kilde til det?
Sidste udmelding jeg har hørt er at properties er ude af Java 7.
Men jeg synes at det at CLI bliver frigjort er meget positivt for C# som et sprog. Hvis man så vil kode sin egen version af Singularity eller lign. så står det jo en frit for nu.
Det har aldrig været særlig positivt hvad de har sagt om Microsoft's open source licenser.sKIDROw (116) skrev:FSF har intet problem med andre frie licenser, de syntes så det er uheldigt, hvis det er under GPL-inkompatible licenser. Men en fri inkompatibel licens, er til enhver tid bedre end en ufri licens.
Så jo, de har et problem. LGPL er kommet til af en grund. Folk kunne simpelthen ikke klare så strikse licenser.
#118
Det er du da velkommen til, at fremlægge nogle eksempler på?.
Det eneste jeg kan google mig frem til, er fra FSF Europe:
http://mailman.fsfeurope.org/pipermail/press-relea...
Som jeg da syntes er positivt med forbehold. (At udgive fri licens, giver jo først folk frihed, når du faktisk begynder at udgive dine ting under dem.) Så nej de har IKKE et problem.
LGPL blev helt præcist, skrevet til GLIBC. For at man forhåbentligt slap, for ufrie C biblioteker til platformen. Der er intet belæg for at påstå, at folk ikke kan klare "strikse" licenser som GPL. Den bliver jo flittigt valgt til nye projekter. Men licenser som MPL, CDDL og andre, kan jo have en berettigelse.
Det er du da velkommen til, at fremlægge nogle eksempler på?.
Det eneste jeg kan google mig frem til, er fra FSF Europe:
http://mailman.fsfeurope.org/pipermail/press-relea...
Som jeg da syntes er positivt med forbehold. (At udgive fri licens, giver jo først folk frihed, når du faktisk begynder at udgive dine ting under dem.) Så nej de har IKKE et problem.
LGPL blev helt præcist, skrevet til GLIBC. For at man forhåbentligt slap, for ufrie C biblioteker til platformen. Der er intet belæg for at påstå, at folk ikke kan klare "strikse" licenser som GPL. Den bliver jo flittigt valgt til nye projekter. Men licenser som MPL, CDDL og andre, kan jo have en berettigelse.
arne_v (105) skrev:Hele grunden til at man bruger properties er at man har mulighed for at gøre noget mere.
Hvis man var 112% sikke rpå at man aldrig ville lave noget mere kunne man lige så godt bruge fields (ihvertfald hvis vi ignorerer virtual/override aspektet).
Hvad er der for noget kode som kan forvirre dig? Jeg tænker på dit argument med at det er svært at skelne mellem fields og properties, og grunden til dette. Kan du komme med et praktisk eksempel, hvor det ville skabe problemer at ligge den kode i en property?
sKIDROw (119) skrev:LGPL blev helt præcist, skrevet til GLIBC. For at man forhåbentligt slap, for ufrie C biblioteker til platformen. Der er intet belæg for at påstå, at folk ikke kan klare "strikse" licenser som GPL. Den bliver jo flittigt valgt til nye projekter.
LGPL bliver også brugt flittigt til libraries.
Omend GPL med linking exception idag er anbefaling fremfor LGPL.
Men forskellen på disse to er meget lille.
mazing (120) skrev:Hvad er der for noget kode som kan forvirre dig? Jeg tænker på dit argument med at det er svært at skelne mellem fields og properties, og grunden til dette. Kan du komme med et praktisk eksempel, hvor det ville skabe problemer at ligge den kode i en property?
v = o.X;
er X et field eller en property?
#125
Tak for svaret - jeg var skam bare nysgerrig efter at høre nærmere. :)
Jeg er aldrig selv stødt på noget hvor det kunne være et problem (men er også stadig studerende).
Man kan vel sige, at siden at det er en fact at der ikke kan kendes forskel, må vi altid gå ud fra at staten kan ændres.
Er det virkelig et problem/tab i virkeligheden? God OO-skik (som mine lærer har banket i mig med en kæp :() siger at vi ikke må have public fields alligevel.
Tak for svaret - jeg var skam bare nysgerrig efter at høre nærmere. :)
Jeg er aldrig selv stødt på noget hvor det kunne være et problem (men er også stadig studerende).
Man kan vel sige, at siden at det er en fact at der ikke kan kendes forskel, må vi altid gå ud fra at staten kan ændres.
Er det virkelig et problem/tab i virkeligheden? God OO-skik (som mine lærer har banket i mig med en kæp :() siger at vi ikke må have public fields alligevel.
#126
Man kan altid diskutere hvor væsentlig noget er.
Jeg mener at det er ret væsentligt for læsbarheden af kode, at man nemt kan se, hvor der kan ske ændringer af state.
Og det koster tid at checke om der faktisk sker en ændring.
Public fields er ikke godt, men eksemplet kræver ikke at field er public.
Man kan altid diskutere hvor væsentlig noget er.
Jeg mener at det er ret væsentligt for læsbarheden af kode, at man nemt kan se, hvor der kan ske ændringer af state.
Og det koster tid at checke om der faktisk sker en ændring.
Public fields er ikke godt, men eksemplet kræver ikke at field er public.
Ja. Specielt hvis du skal arbejde med immutable objects.mazing (126) skrev:Er det virkelig et problem/tab i virkeligheden?
class Person
{
public string Name { get; }
public Person(string name)
{
this.Name = name;
}
}
Her er person imnmutable. Og du *ved* at den er immutable, da Name er read-only. Hvis du benyttede et field, så ville den ikke være immutable mere, hvilket kan give problemer med threading og andre ting.
(Simpelt eksempel, but hey)
Windcape (129) skrev:Hvis du benyttede et field, så ville den ikke være immutable mere
...medmindre det er et final field. Jeg går ud fra at der findes noget tilsvarende i C#:
public class Person {
public final String name;
public Person(String name) {
this.name = name;
}
}Dvs. den forskel er der altså ikke. Den kan være immutable i begge tilfælde.
Faktisk kan du næsten kun være sikker med en field. Selv om der ikke er en setter, aner du jo ikke om der er andre måder at ændre værdien på. Med et final field ved du at den eneste omvej er reflection, hvilken jo grundlæggende er snyd. ;-)
Windcape (129) skrev:Ja. Specielt hvis du skal arbejde med immutable objects.class Person
{
public string Name { get; }
public Person(string name)
{
this.Name = name;
}
}
Her er person imnmutable. Og du *ved* at den er immutable, da Name er read-only. Hvis du benyttede et field, så ville den ikke være immutable mere, hvilket kan give problemer med threading og andre ting.
(Simpelt eksempel, but hey)
Det er også lidt for simpelt. Dit eksempel er ikke gyldig kode og ville skulle omskrive til:
class Person
{
private readonly string _name;
public string Name
{
get
{
return _name;
}
}
public Person(string name)
{
_name = name;
}
}
Så er vi tilbage til samme problemstilling, arne_v nævner. Du kan ikke som udgangspunkt se, hvad din property returnerer, hvorimod du må forvente, at et readonly field returnerer det samme hver gang.
Jeg betragter det dog ikke selv som et praktisk problem. Hvis man koder op imod noget, bør man kunne vide, om værdien ændrer sig fra kald til kald.
Men en getName() metode ville jo have præcist samme problem.Acro (131) skrev:Så er vi tilbage til samme problemstilling, arne_v nævner. Du kan ikke som udgangspunkt se, hvad din property returnerer, hvorimod du må forvente, at et readonly field returnerer det samme hver gang.
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.
Nu er den her artikel ikke så slem. Men som du ved så er det sgu nok en and hvis den taler som en and og går som en and.
Manden er lynende intelligent, så kan man så være enig eller uenig, med enkelte eller flere af hans synspunkter.
Jeg skal ikke kunne sige hvorvidt han er begavet eller ej, man skulle dog mene at hvis det er tilfældet burde han jo vide at han med sin til tider yderligtgående retorik desværre skader mere end han gavner.
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.
Hvilken baggrund har han for at udtale sig om patenter? Jeg er dog langt hen ad vejen enig med ham når det kommer til de her ånsvage software patenter men jeg mener nu at han gør sig selv og alle os andre en bjørnetjeneste ved at fare frem som ham typisk gør. Det skræmmer simpelthen folk væk.
#133
Manden er konsistent hvad hans synspunkter at gøre, så kan man være uenige delvist eller helt. Men syntes generelt det ord er en uskik.
Intelligens følges ikke altid hånd i hånd, med sociale færdigheder.
Som udvikler der selv har haft dem inde på livet.
Hans patentforedrag er nu af en noget anden karakter, end hans foredrag om frit software. Jeg kan ikke se problemet i hans henvendelse. Det ville da være ualmindeligt trist, hvis der blev udviklet noget virkeligt banebrydende med Mono. Som bliver ubrugeligt den dag Microsoft indskærper, at alt udover de par lunser de har undet folk her, ikke må portes uden deres tilladelse. Hvis sandheden skræmmer folk, så lad dem være dumnaive for dem selv.
Nu er den her artikel ikke så slem. Men som du ved så er det sgu nok en and hvis den taler som en and og går som en and.
Manden er konsistent hvad hans synspunkter at gøre, så kan man være uenige delvist eller helt. Men syntes generelt det ord er en uskik.
Jeg skal ikke kunne sige hvorvidt han er begavet eller ej, man skulle dog mene at hvis det er tilfældet burde han jo vide at han med sin til tider yderligtgående retorik desværre skader mere end han gavner.
Intelligens følges ikke altid hånd i hånd, med sociale færdigheder.
Hvilken baggrund har han for at udtale sig om patenter?
Som udvikler der selv har haft dem inde på livet.
Jeg er dog langt hen ad vejen enig med ham når det kommer til de her ånsvage software patenter men jeg mener nu at han gør sig selv og alle os andre en bjørnetjeneste ved at fare frem som ham typisk gør. Det skræmmer simpelthen folk væk.
Hans patentforedrag er nu af en noget anden karakter, end hans foredrag om frit software. Jeg kan ikke se problemet i hans henvendelse. Det ville da være ualmindeligt trist, hvis der blev udviklet noget virkeligt banebrydende med Mono. Som bliver ubrugeligt den dag Microsoft indskærper, at alt udover de par lunser de har undet folk her, ikke må portes uden deres tilladelse. Hvis sandheden skræmmer folk, så lad dem være dumnaive for dem selv.
Hvis der bliver lavet noget banebrydende med C# som teknologi, kan Microsoft ikke gøre det store imod det.sKIDROw (134) skrev:Det ville da være ualmindeligt trist, hvis der blev udviklet noget virkeligt banebrydende med Mono. Som bliver ubrugeligt den dag Microsoft indskærper, at alt udover de par lunser de har undet folk her, ikke må portes uden deres tilladelse.
De kan begrænse at visse libraries ikke kan benyttes på andre platforme end Windows, men så står det dig stadig frit for at erstatte disse med andre libs.
C++ er ikke forskelligt på det punkt.
Windcape (128) skrev:fields starter med småt, properties med stort.
Det kan du ikke regne med.
"Design Guidelines for Developing Class Libraries" http://msdn.microsoft.com/en-us/library/ms229012.a... omtaler kun public/protected static fields som skal starte med stort. Der angives ingen retningslinier for private fields.
Så kan man kigge på hvad MS selv gør i .NET.
public static:
3 out of 11127 starts with lower case
11124 out of 11127 starts with upper case
0 out of 11127 starts with underscore
non public static:
3362 out of 9822 starts with lower case
5112 out of 9822 starts with upper case
1330 out of 9822 starts with underscore
public instance:
1550 out of 1672 starts with lower case
122 out of 1672 starts with upper case
0 out of 1672 starts with underscore
non public instance:
16125 out of 31615 starts with lower case
652 out of 31615 starts with upper case
14669 out of 31615 starts with underscore
Der er mange undtagelser fra reglen.
myplacedk (130) skrev:Jeg går ud fra at der findes noget tilsvarende i C#
Ja - C# readonly svarer nogenlunde til Java final, mens C# const svarer nogenlunde til Java final static.
http://msdn.microsoft.com/en-us/library/acdd6hb7.a...
http://msdn.microsoft.com/en-us/library/e6w8fe1b.a...
Hubert (133) skrev:Jeg skal ikke kunne sige hvorvidt han er begavet eller ej,
Taget i betragtning af hvor udbredt den software som han personligt har været med til at lave er og hvor meget software der er underlagt en licens som han har været med til at lave, så mener jeg godt at vi kan konkludere at han har evner.
#142
Har du dokumenation for at det er sådan generelt for de fleste udviklere set over hele branchen? (Kan være det er kommet tidligere)
jeg har kun 2 gange oplevet at vi havde overvejelser på teamet pga patenter, og hver gang blev spørgsmålet sendt ned til legal services. Tilgengæld har jeg flere gange opleve af spilde mere end 40% af min tid på møder uger i træk.
Har du dokumenation for at det er sådan generelt for de fleste udviklere set over hele branchen? (Kan være det er kommet tidligere)
jeg har kun 2 gange oplevet at vi havde overvejelser på teamet pga patenter, og hver gang blev spørgsmålet sendt ned til legal services. Tilgengæld har jeg flere gange opleve af spilde mere end 40% af min tid på møder uger i træk.
Hvor tit er det nødvendig? Har FSF overhovedet noget troværdig dokumentation på det?sKIDROw (144) skrev:Pointen var slet og ret, at hvis du må spilde tid på omskrivning, på grund af patenter, så har du dem i en vis grad dem inde på livet.
Specielt for Europa, hvor vi er ikke har sindsyg lovgivning!
Det afhænger jo meget af hvilken brance man arbejder i. Jeg har kun professionel erfaring som webudvikler i .NET og PHP, men der oplevede jeg ingen licensproblemer.
Det var på hosting siden at de skulle ordnes, men det er noget du betaler dig væk fra.
Som udviklere er pantent problemer rimelig sjældent vil jeg sige. Der er andre som håndtere dem for dig.
#145
Modstanden mod softwarepatenter kommer fra bredere kredse end FSF, og ældre artikler jeg læste herhjemme med to danske virksomheder, var budskabet at det ville koste dem en masse bøvl uden at give dem det fjerneste.
Patentkontorene i EU udsteder flittigt patenter på softwareidéer allerede, så vi skal bestemt ikke tage vores helle for givet. Lige nu er patenterne så ikke det papir værd de er trykt på, men hvis patentparasitterne får deres vilje, er helvedet for alvor løs.
Så lad os da håbe det forbliver sådan, for det er bestemt ingen selvfølge.
Hvis vi anerkendte softwarepatenter i EU, og du implementerede et patenteret teknologi, ville du(eller rettere din arbejdsgiver) også få en henvendelse fra en patentparasit.
Fordi en stor byrde bliver håndteret af nogle andre, er det stadig en stor byrde. Og nogle resourcer i kunne have brugt, på noget langt mere produktivt istedet.
Hvor tit er det nødvendig? Har FSF overhovedet noget troværdig dokumentation på det?
Modstanden mod softwarepatenter kommer fra bredere kredse end FSF, og ældre artikler jeg læste herhjemme med to danske virksomheder, var budskabet at det ville koste dem en masse bøvl uden at give dem det fjerneste.
Specielt for Europa, hvor vi er ikke har sindsyg lovgivning!
Patentkontorene i EU udsteder flittigt patenter på softwareidéer allerede, så vi skal bestemt ikke tage vores helle for givet. Lige nu er patenterne så ikke det papir værd de er trykt på, men hvis patentparasitterne får deres vilje, er helvedet for alvor løs.
Det afhænger jo meget af hvilken brance man arbejder i. Jeg har kun professionel erfaring som webudvikler i .NET og PHP, men der oplevede jeg ingen licensproblemer.
Så lad os da håbe det forbliver sådan, for det er bestemt ingen selvfølge.
Det var på hosting siden at de skulle ordnes, men det er noget du betaler dig væk fra.
Hvis vi anerkendte softwarepatenter i EU, og du implementerede et patenteret teknologi, ville du(eller rettere din arbejdsgiver) også få en henvendelse fra en patentparasit.
Som udviklere er patent problemer rimelig sjældent vil jeg sige. Der er andre som håndtere dem for dig.
Fordi en stor byrde bliver håndteret af nogle andre, er det stadig en stor byrde. Og nogle resourcer i kunne have brugt, på noget langt mere produktivt istedet.
sKIDROw (134) skrev:
Manden er konsistent hvad hans synspunkter at gøre, så kan man være uenige delvist eller helt. Men syntes generelt det ord er en uskik.
Ja det er et grimt ord der bliver misbrugt en del ser man på definitionen passer den dog meget godt.
Intelligens følges ikke altid hånd i hånd, med sociale færdigheder.
Det har dog ikke noget særligt med sociale færdigheder at gøre. Det er et spørgsmål om at kunne genneskue konsekvensen af sine handlinger...
Som udvikler der selv har haft dem inde på livet.
Aha og hvilket patent var han så uheldig at løbe ind i?
Hans patentforedrag er nu af en noget anden karakter, end hans foredrag om frit software. Jeg kan ikke se problemet i hans henvendelse. Det ville da være ualmindeligt trist, hvis der blev udviklet noget virkeligt banebrydende med Mono. Som bliver ubrugeligt den dag Microsoft indskærper, at alt udover de par lunser de har undet folk her, ikke må portes uden deres tilladelse. Hvis sandheden skræmmer folk, så lad dem være dumnaive for dem selv.
Selvfølgelig kan du ikke se et problem i hans henvendelse. Jeg har til dato ikke set dig vige fra hans side uanset hvad han lukker ud... Du burde måske passe på med at kalde andre for dumnaive... ;)
arne_v (140) skrev:Taget i betragtning af hvor udbredt den software som han personligt har været med til at lave er og hvor meget software der er underlagt en licens som han har været med til at lave, så mener jeg godt at vi kan konkludere at han har evner.
Beklager men jeg kan ikke se sammenkoblingen mellem noget kode han har skrevet og en licens han har været med til at skrive fra starten af og hans begavelse.
sKIDROw (146) skrev:
Modstanden mod softwarepatenter kommer fra bredere kredse end FSF, og ældre artikler jeg læste herhjemme med to danske virksomheder, var budskabet at det ville koste dem en masse bøvl uden at give dem det fjerneste.
Jeg kan kun tolke det her som et nej der er ingen dokumentation. Mere fsf skræmme taktik.
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