I vilket språk utvecklar man appar (tiles) till windows phone?

Krävs ju dock inte mycket för att göra någonting som är bättre än JavaScript.

Tvivlar på att det kostar att ladda ner SDK'n, kollade just, är nog bara att ladda ner och börja programmera. Det är ju en annan sak om man ska ladda upp appar till app store, det kanske kostar.

https://dev.windowsphone.com/en-us/downloadsdk

Det jag gillar med TypeScript är:

• Föredrar statiskt typade språk över dynamisk typade språk då all forskning visar att ju tidigare man hittar ett fel, desto bättre. Men statisk typning hittar man vissa typer av fel redan vi kompilering som man först hittar när man kör programmet i dynamiskt typade språk. Type script är statiskt typat, JavaScript är dynamiskt typat.

• TypeScript är ett relativt enkelt språk (till skillnad från t.ex. C++ och C#). Ett "enkelt" språk är en stor fördel när det är fler än du själv som ska jobba på en och samma kodbas

• TypeScript är ett helt öppet språk så det finns inget enskilt företag som totalt kontrollera allt kring det. Visst är det mest Microsoft som jobbar på språket, men det finns inga juridiska eller tekniska hinder för andra att använda det.

C++ är ett väldigt komplicerat språk, men det har den stora fördelen att generera väldigt effektiva program + vet man vad man gör så kan man ådstakomma rätt coola saker. Det är därför spel-programmerare i nära nog 100% av fallen kör C++ och för WP8 är XNA "legacy" och det rekommenderade sättet att skapa spel är C++ samt DirectX.

Tycker WP8 rent tekniskt är väldigt bra, men tvivlar på att det någonsin blir mer än en väldigt avhängd 3:a efter Android (som redan är överlägsen 1:a) och iOS.

Ingen risk. Börja med Java du, och om behovet finns så kan du sedan väldigt enkelt lära dig C# senare, då Java och C# är väldigt lika.

Qt 5.1 (C++) har nu möjligheten till att köra på WinLinMac Android Ios och blackberry med en kodbas.

Läs artikeln igen, GC kan vara snabbare i genomsnitt än manuell minnes-hantering förutsatt att du tillåter din applikation att använda minst 5x gånger mer minne än vad den strikt behöver. Men det är i genomsnitt, du kommer aldrig ifrån att GC är icke-deterministiskt och kommer introducera jitter (det som i folkmun kallas "lagg"). I artikeln finns citat från Android- och WP-utecklare som just pekar på problemen med att hålla renderingstider när man har GC.

Så på mobila enheter är GC ett felaktigt val, alla har insett detta: Apple gick längst och skrotade GC helt i iOS, Android har NDK och för WP8 skrotades XNA till förmån för C++/DirectX.

Det "trista" med detta är att avsaknad av GC gör det svårare att använda många CPU-kärnor då många låsnings-fria algoritmer lider av ABA-problemet i frånvaro av GC och persistent data structure (något som man undrar varför bara Clojure använder "by default" när det är helt överlägset för multitrådade program) är i praktiken helt omöjligt att implementera effektivt utan GC. Så dagens 4-kärniga mobiler och pekplattor är totalt korkat, verkar bara vara Apple som begriper bättre och håller sig till 2-kärniga SoCer och fokuserar i stället på bättre enkeltrådprestanda / W.

Så på servers / backend är språk med GC ett självklart val idag då det inte är ett speciellt stort problem att programmen får jitter och kräver >=5x så mycket minne som strikt är nödvändigt, framför allt då dagens servers typiskt har >=8-kärnor.

På system som används interaktiva system, framför allt svaga sådana, ska man sky GC som pesten. Även på en modern PC blir det märkbart segt att använda lite mer komplicerade applikationer utvecklade med .Net/C#, på jobbet har vi två (inköpta, svindyra) program som blivit "uppgraderade" från C++/MFC till C#/.Net. Resultatet är nära nog 10x i RAM-användning och program som är sega på Core i7 CPUer med 8GB RAM.

Även GUI-applikationer skrivna i VB är rapp så länge som det handlar om relativt triviala saker. Skulle säga att WPF just är en ersättare för de GUI-applikationer som tidigare utvecklades i VB5/VB6 (med bonusen att C# är ett långt bättre språk jämfört med VB). Anledningen att WPF fungerar här är det man kommer tillbaka till flera gånger i artikeln, är CPUn och mängden RAM total overkill för det man ska göra så spelar det inte så stor roll om man kör med GC.

Men de applikationer vi kör på jobbet hamnar inte i den kategorin, de är inte superavancerade så med C++/MFC kunde man med gott resultat köra dessa på en Core2Duo laptop med 2GB RAM. Men en Core i7 3770 med 8GB RAM är inte 5-10x mot en Core2Duo så när samma program skrivs om med C#/WPF så blir det så tungt att driva runt och drar så mycket RAM att det upplevs som frustrerande segt.

Samma sak gäller telefoner, tycker man kanske gick onödigt långt på iOS när man helt skippade GC. På WP8 och Android finns det ju ingen anledning att utveckla väldigt enkla applikationer i "native-språk" utan GC, men alla lite mer krävande program ska definitivt använda "native".

Som beskrevs i artikeln så kan "managed" språk köra nära nog i samma hastighet som "native-språk" (kan till och med vara snabbare i vissa fall, t.ex. vissa typer av multitrådade program). Men för att nå denna prestanda måste "managed"-språk få ta ut svängarna rejält vad det gäller aggressiv JIT och mängden RAM som får användas, något som helt enkelt inte är vettigt eller i vissa fall ens möjligt på en mobil-plattform.

WP8 har faktiskt lagt sig mellan Android och iOS. Skriver du en C# applikation och kör den på WP7 så fungerar det på samma sätt som i .Net, din "binär" består av MSIL som JITas när applikationer startar, Android fungerar på samma sätt sedan version 2.2. Men WP8 kommer din telefon aldrig "se" MSIL-kode, utan det som installeras är en form av "native" kod kallad Machine Dependent Intermediate Language (MDIL). Fördelen med MDIL är att JIT kostar CPU-cykler och drar därmed ström + gör att applikationer tar längre tid att starta. Nackdelen att skippa JIT är att man inte kan göra enhetsspecifika optimeringar eller "hotspot" optimeringar (fast inte ens "riktiga" .Net gör "hotspot" optimeringar, bara Java6 och senare som utför detta vilket är en stor del av förklaringen varför Java-program idag är klart snabbare än motsvarande C#-program om problemet är CPU-bundent).

Resursläckor blir inte automagiskt lösta bara för att man har GC. Dels så kan du fortfarande få minnesläckor p.g.a. att någon form av (programmatisk) cache eller så har en pekare till minne som rent tekniskt är "dött". Sedan är RAM långt ifrån den enda resurs som program kan läcka, en GC kommer inte kunna fixa läckor av filhantag, mutex/semaforer, sockets etc. Läckor av dessa är precis lika illa så om de personer som inte kan skriva program med manuell minneshantering kommer inte kunna skrivna program med hög tillgänglighet oavsett språk. Faktum är att resurser != minne är lättare att hantera i språk som C++ (via deterministiska destruktorer) och Go (via nyckelordet defer) som båda enkelt kan använda RAII. Men inte ens RAII är den silverkula som fixa usel kod, inte ens i fallet Go där man även har GC.

WPF kommer inte fungera bra om ett motsvarande C++/MFC-program kräver en Core2 CPU och använder 100-200MB RAM då motsvarande C#/WPF kommer använda mellan 5x-10x så mycket RAM (vilket är fallet i de program vi använder). När GC ska hantera en aktiv heap på runt 1GB RAM så blir det långa pauser och det kräver mycket CPU.

Att deklarera att API A är bättre än API B är nog som bäst personligt tyckande. Sedan verkar framtiden för WPF vara högst tvivelaktig efter att WinRT (APIet, inte OSet) infördes då det är vad Microsoft trycker på idag. Överlappet mellan WPF och GUI-delen av WinRT verkar var hyfsat stort, så är ju ingen nackdel att känna till WFP. Själv gillade jag Qt bättre än WFP, men Qt har också en väldigt tvivelaktig framtid

Om du tycker 200MB är mycket undrar jag vilka program du använde som referens. Minnesåtgången i Java/JVM och C#/.Net är väldigt likartad då båda till stor del riktar in sig på samma marknader (webb-backend). Tittar du http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=java&lang2=gpp&data=u64q så ser du att relativt triviala program som råkar skapa många kortlivade objekt under sin körning ganska snabbt drar iväg i RAM-åtgång (om de inge gjorde det skulle prestanda suga). Att nå >500M kräver definitivt inget stort program/problem och i dessa fall kan GC-språk använda väldigt mycket mer RAM (40x som värst i det jag länkar till) jämfört med språk med manuell minneshantering. Du kommer med stor sannolikhet ha märkbart GUI-jitter redan vid 200MB på en modern PC.

Edit: och gillar du assemblies i .Net borde du älska hur moduler hanteras i Go. Det om något lämpar sig väl i riktigt stora projekt.