Programmeringsjobb

[Lycantrophe]

Og det er umulig å utvide VMen?

[GeirGrusom]

Og det er umulig å utvide VMen?

Nei, men det går rett imot et annet mål de prøver å nå: mobilmarkedet.

Endret 15. mai 2014 av GeirGrusom

[Lycantrophe]

Mhm. Det nytter ikke å leke dominant og kontrollerende aktør når du ikke har en dominerende markedsposisjon, noe Microsoft heldigvis ikke har i mobilmarkedet. Og det er i deres interesse at C# er et populært språk noe a Javas Write Once, Run Everywhere™

 

Men jeg kan love deg at den trenden vil snu dersom de faktisk kommer seg i posisjonen de ønsker å være.

 

Jeg kommer ikke til å bidra til det.

[etse]

Men jeg kan love deg at den trenden vil snu dersom de faktisk kommer seg i posisjonen de ønsker å være.

Utrolig hvordan man kan forutse fremtiden. Det er ikke sansynlig at Microsoft vil fortsette i samme spor som nå for å beholde goodwill og i frykt for å miste markedsandeler til andre markeder?

 

Det finnes vinn-vinn situasjoner, hvor microsoft tjener penger på løsninger som kommer utviklere og forbrukeren til gode. Dette er også ofte de beste løsningen om de ønsker å beholde posisjonen dems i lang tid.

[Lycantrophe]

Utrolig hvordan man kan forutse fremtiden. Det er ikke sansynlig at Microsoft vil fortsette i samme spor som nå for å beholde goodwill og i frykt for å miste markedsandeler til andre markeder?

Hvem trenger goodwill når man har lock-in?

[etse]

Hvem trenger goodwill når man har lock-in?

Lock-in vil kun gi kortsiktig gevinst. Om Microsoft hadde kjørt den retningen ville de over tid kunne miste markedsandeler etterhvert som nye tjenester ble utviklet på andre plattformer. Med stort nok monopol, ville prosessen selvfølgelig tatt ganske lang tid. Men et selskap i en størelsesorden som microsoft er neppe ute etter kortsiktige gevinster - det er nok langsiktighet. Og mener i hvertfall jeg at det er best løsning for dem å satse på goodwill blandt utviklere så de hele tiden kan jobbe for å forsterke og beholde posisjonen sin.

 

Vinn-vinn løsninger vil være det beste for begge parter.

[Lycantrophe]

Lock-in vil kun gi kortsiktig gevinst. Om Microsoft hadde kjørt den retningen ville de over tid kunne miste markedsandeler etterhvert som nye tjenester ble utviklet på andre plattformer.

Javisst, men det kan gi oss nye 15 år med dark ages. Dersom du sitter i posisjon kan du også gjøre embrace & extinguish slik et visst Washington-basert selskap ikke har vært fremmed for å gjøre tidligere.

 

Med stort nok monopol, ville prosessen selvfølgelig tatt ganske lang tid. Men et selskap i en størelsesorden som microsoft er neppe ute etter kortsiktige gevinster - det er nok langsiktighet. Og mener i hvertfall jeg at det er best løsning for dem å satse på goodwill blandt utviklere så de hele tiden kan jobbe for å forsterke og beholde posisjonen sin.

Du mener slik de har gjort siden 80-tallet? Right.

[siDDis]

Dei driver faktisk enda med lock-in idag. Om du jobber med C# og rammeverkene, så vil du oppleve at API'et ofte blir snudd opp ned ved ein ny release. Ingen warnings med at deler av API'et er depricated...og ingen gode feilmeldinger er det heller. Så du må bruke ekstra lang tid på å finne feil og lære deg eit nytt API.

 

Denne tida kunne ein heller brukt på å bli ein betre utviklar. Men sidan du sliter med å få basisfunksjonalitet til å fungere fordi API'et blir snudd opp ned annakvart år, så greier du rett og slett ikkje å utvikle deg i riktig retning.

 

Bare sjå på vrælet med Windows 8 apper, det er eit HEILT FORBANNA NYTT API for noko så enkelt som å lagre filer!!!

[torbjørn marø]

Dei driver faktisk enda med lock-in idag. Om du jobber med C# og rammeverkene, så vil du oppleve at API'et ofte blir snudd opp ned ved ein ny release. Ingen warnings med at deler av API'et er depricated...og ingen gode feilmeldinger er det heller. Så du må bruke ekstra lang tid på å finne feil og lære deg eit nytt API.

 

Denne tida kunne ein heller brukt på å bli ein betre utviklar. Men sidan du sliter med å få basisfunksjonalitet til å fungere fordi API'et blir snudd opp ned annakvart år, så greier du rett og slett ikkje å utvikle deg i riktig retning.

 

Dette er en forferdelig dårlig beskrivelse av virkeligheten. Hvis det er ett selskap som er kjent for å alltid forsøke å være bakoverkompatible, så er det jo nettopp Microsoft. Gammelt og nytt kan kjøre knirkefritt side om side.

 

Og om noe deprikeres så får du warnings - det er jo det depricated er der for.

[siDDis]

Så kvifor er API'et for ein vanleg C# applikasjon, heilt totalt annerledes når du skal lage Windows Store App?

Sjå f.eks på BitmapEncoder klassen.

 

Dei likner ikkje litt ein gong.

 

Eg seier ikkje at det er betre i Java eller Python(Mange fine eksempler der og).

[torbjørn marø]

Så kvifor er API'et for ein vanleg C# applikasjon, heilt totalt annerledes når du skal lage Windows Store App?

Sjå f.eks på BitmapEncoder klassen.

 

Dei likner ikkje litt ein gong.

 

Jeg er ikke helt sikker på om jeg forstår hva du mener. BitmapEncoder var ny i .NET 3.0, så ble den litt utvidet i 3.5, og er uendret i 4.5. Mener du kanskje at WinForms ikke var direkte overførbart til WPF. Eller at det har kommet nye ting i WinRT/Windows 8?

 

Jeg har ikke erfaring med WinRT selv altså, så hvis du kan utdype så vil det sikkert være lærerikt. Men jeg blir ikke overrasket og synes ikke det er rart om det er det at du skal forholde deg til WinRT som er poenget. Altså ingenting med C# eller .NET å gjøre egentlig, men endringer i selve Windows.

[GeirGrusom]

Så kvifor er API'et for ein vanleg C# applikasjon, heilt totalt annerledes når du skal lage Windows Store App?

Windows Store benytter Windows Runtime mens eldre .NET programmer gikk mot GDI+ for denne funksjonaliteten.