Steve Jobs forsvarer kodekrav: Tredjeparts-værktøjer giver dårligere iPhone-apps

Værktøjer, der lægger sig mellem udvikleren og Apples iPhone-platform, resulterer i dårligere iPhone-applikationer. Sådan lyder det kortfattede svar fra Apple-boss Steve Jobs på kritikken af de skærpede udviklerkrav i iPhone OS 4.0.

Apple-topchef Steve Jobs tager nu til genmæle overfor den kritik, der har haglet ned over selskabets stramning af reglerne for udvikling til det nye styresystem iPhone OS 4.0.

Ændringen af reglerne skyldes, at iPhone-applikationerne ganske enkelt bliver ringere, hvis de udvikles med et værktøj, der lægger sig oven på Apples egen platform, forklarer Steve Jobs.

Svaret fra Steve Jobs falder i en e-mail-udveksling med den administrerende direktør i Apple-huset Taoeffect, Greg Slepak, som i en e-mail havde udtrykt sin bekymring over Apples beslutning om at begrænse udviklere til at skrive iPhone-applikationer i Objective-C, C++ og C.

Han har offentliggjort den korte e-mail-udveksling på sin hjemmeside.

Steve Jobs: Mellemlag giver ringere kode

Apple præsenterede iPhone OS 4.0 i sidste uge, og udover nyheden om understøttelse af multitasking var stramningen af Apples iPhone Developer Agreement nok det, der gav størst genlyd blandt iPhone-udviklere verden over.

Der var ikke gået mange timer, før afsnit 3.3.1 i Apples iPhone Developer Agreement, som altså er blevet opdateret i forbindelse med iPhone OS 4.0 SDK, fik en hær af udviklere på verdensplan til at fare i blækhuset.

Mange har tolket stramningen som en krigserklæring fra Apples side mod værktøjer som for eksempel Adobes Flash Professional CS5 og Monotouch, der tillader udviklere at skrive iPhone-applikationer i henholdsvis Flash og C#.

I svaret til Greg Slepak konstaterer Steve Jobs meget kortfattet, at ekstra lag mellem udviklingsplatformen og udvikleren resulterer i dårligere applikationer.

»Vi har været der før, og mellemliggende lag mellem platformen og udvikleren producerer i sidste ende applikationer under standarden og hæmmer platformens fremskridt,« skriver Steve Jobs i e-mail'en.

Greg Slepak har svaret, at han udelukkende ser det opdaterede reglement som en måde at skræmme udviklere væk fra iPhone-platformen.

»Dårlige udviklere vil skrive dårlige applikationer, uanset hvor mange lag der findes, og det giver ingen mening at begrænse konverteringsværktøjer som Unity3D (dansk iPhone-udviklerplatform, red.) og andre,« skriver Greg Slepak.

Almindelige brugere på vente til sommer med at prøve iPhone OS 4.0, mens udviklere allerede nu kan få fingrene i en betaudgave af det tilhørende udviklingskit (SDK).

Læs hele udvekslingen mellem Steve Jobs og Greg Slepak under fanebladet Eksterne links.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (60)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Ulrik Rasmussen

Man kan sige meget om Apples metoder og regler, men de er jo sådan set frit stillede til at bestemme lugten i eget bageri. Personligt er jeg faktisk glad for at Apple har lavet så kontroversiel en regel, da jeg alle dage har syntes at Apple er for kontrollerende og deres platform for restriktiv til at den er interessant. Ved at komme med sådan nogle udtalelser tror jeg blot at mere interessante platforme, som f.eks. Android, bliver styrkede, hvilket jo udelukkende er en positiv ting.

  • 0
  • 0
Per Hansen

At apple vil bestemme folks udviklingsværktøjer?
Det svarer til at MS forbyder folk at bruge andet end VisualStudio til at kode C# i ..
Eller at alle UNIX programmer SKAL skrives med VI editoren ..

Hvis et andet udviklingsværktøj fungerer bedre for den pågældende udvikler, men stadig giver samme Object C kode nedenunder, så kan apple teknisk set være pisse ligeglade ... medmindre det som altid er for at kontrollere deres brugere/udviklere på hænder og fødder.

  • 0
  • 0
Jimi Hansen

Jeg kan godt forstå at Apple ikke gider have deres AppStore fyldt med skodringe Flash-spil - men det holder slet ikke at udelukke Unity og Monotouch m.fl.

Jeg tvivler stærkt på at Flash-værktøjerne ville resultere i andet end ringe eller i bedste fald middelmådig software. Hvis man er udvikler og har bare en smule ambitioner i retning af at lave et godt spil til iPhone, så laver man det da ikke i Flash. Unity derimod virker til at være ret OK...

http://blogs.unity3d.com/2009/09/23/5-unity-powered-iphone-games-in-top1...

  • 0
  • 0
Per Hansen

Jeg kan til nød forstå, at apple ikke ønsker at understøtte flash pga sikkerheds og performance aspekter.

Men at de vil forbyde udviklingsværktøjer, som danner samme kode som apples egne udviklingsværktøjer, og kører i samme sandkasse (eller mangel på samme), når de afvikles, det virker direkte barnligt.

  • 0
  • 0
Stephen Aaskov

Hvis kvaliceret = elsker alle dimser med et æble på, så nej..

Har du, eller har du ikke, læst aftalen mellem Apple og udviklere? Den er underlagt en NDA, så med mindre du har læst den er du vel ikke kvalificeret til at diskutere det.

Hvad barnagtigt er der i den holdning?

  • 0
  • 0
Ulrik Rasmussen

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

Det omtalte afsnit ligger jo offentligt tilgængeligt så alle kan læse det.

Den foregående licens før ovenstående rettelse kan findes her: http://www.wired.com/images_blogs/gadgetlab/2010/03/20100302_iphone_dev_...

Jeg tror der er rigeligt materiale til at man kan diskutere emnet.

  • 0
  • 0
Stephen Aaskov

Så som sædvanligt når der drejer sig om fakta der har været gennem en journalist, er der en graverende fejl i håndteringen af "nyheden"

Det nye krav fra Apple er, at software skal skrives i C/C++/Objective-C eller Javascript. Apple siger ikke ,som overskriften, at tredjeparts-værktøjer giver dårlig kode, men at mellemlag der fortolker kode og kompatibilitetslag er forbudt.

Med C/C++/Objective-C og Javascript er der hele fire åbne standardiserede programmeringssprog at vælge imellem - hvor er det lukkede i det?

  • 0
  • 0
ab ab

Med C/C++/Objective-C og Javascript er der hele fire åbne standardiserede programmeringssprog at vælge imellem - hvor er det lukkede i det?

Hele fire. Ja det er nærmest som om, at vi har fået en gave foræret fra vores kære leder, der med dette tiltag har anvist os alle Den Rette Vej (tm) at følge, når man vil udvikle iphone-applikationer. Lad os forenes i fælles anprisning af vores kære leder, der så nådigt har delagtiggjort os i dette visionære klarsyn. Det er jo en ren buffet.

Hvis denne beslutning handlede om at gøre det bedste for brugerne, så ville Apple erkende, at på et marked med perfekt konkurrence vil forbrugerne udmærket være i stand til at afveje deres egne behov og præferencer mellem et krydsplatform-kompatibelt produkt og et produkt, der bruger de nyeste dele af iphone's API'er.

Det er muligt, der er en modsætning mellem krydsplatform-kompatibelt og bedst; som det gamle ordsprog siger: fast, portable, good - pick any two; men Apple opfører sig himmelråbende arrogant ved at påstå, at de ved bedst hvilke præferencer, en bruger af iphone-applikationer bør have.

Når deres argumentation om, at det handler om at sikre en høj softwarekvalitet, så ikke en gang hænger sammen - jævnfør de talrige eksempler på ligegyldige prutteapplikationer skrevet i Objective C - kan man ikke nå frem til andet, end at Apple har haft rent kommercielle motiver til at udelukke fri konkurrence og forbrugerens frie valg fra platformen. Med denne beslutning demonstrerer Apple i mine øjne, at ingen udvikler kan basere sin forretningsmodel på iphone-platformen uden at acceptere den risiko, at Apple fra den ene dag til den anden ændrer holdninger til, hvad der er i Apples interesse og river tæppet væk under fødderne på udvikleren.

  • 0
  • 0
Stephen Aaskov

Når deres argumentation om, at det handler om at sikre en høj softwarekvalitet, så ikke en gang hænger sammen - jævnfør de talrige eksempler på ligegyldige prutteapplikationer skrevet i Objective C - kan man ikke nå frem til andet, end at Apple har haft rent kommercielle motiver til at udelukke fri konkurrence

Der er vist ikke mere at tilføje, når du ikke kan se forskel på kvalitet af et stykke software, og kvaliteten af evt. indhold det software stiller til rådighed.

  • 0
  • 0
ab ab

Der er vist ikke mere at tilføje, når du ikke kan se forskel på kvalitet af et stykke software, og kvaliteten af evt. indhold det software stiller til rådighed.

Skal jeg forstå dig sådan, at applikationerne bare prutter på en federe måde, når de er skrevet i Objective C frem for eks. Pascal, og at det er derfor, Apple tillader dem? Det begynder faktisk at lyde som noget, Jobs kunne have sagt på det seneste.

  • 0
  • 0
Michael Balle-Pedersen

Det vi i disse uger er vidner til, og som kommer til udtryk i denne tråd og talrige andre, er det endelige opgør mellem nørderne og de almindelige ikke tekniske brugere.

I årtier har nørderne siddet på magten inden for computerbrug, og holdt de almindelige mennesker i et jerngreb. Den tid er nu ved at være forbi, og naturligvis bryder nørderne sig ikke om at miste den magt de så længe har besiddet.

Nørderne vil naturligvis ikke forsvinde, men de vil blive marginaliseret, og sidde ovre i et hjørne og hygge sig med kryptiske kommandoer og obskure programmeringssprog, men uden den magt de i årtier har udøvet over for normale mennesker.

Men for almindelige mennersker, som blot ønsker sig let anvendelige apparater til at konsumere elektronisk indhold, der går vi nu en god tid i møde.

  • 0
  • 0
ab ab

Et dejligt faktablottet debatindlæg, som er noget nær det reneste stykke demagogi, jeg nogensinde har set. Måske med undtagelse af visse historiske eksempler.

  • 0
  • 0
Per Hansen

og ja, alm. mennesker (og de fleste "nørder" incl), ønsker sig bare letanvendelige apperater til elektronisk indhold.
men Steve Jobs seneste udmelding er ikke garanti for det, snarere tværtimod ...

  • 0
  • 0
Søren Bramer

Krav: Lav et program der kan vise (musik-)programmet for Roskilde Festival. Det skal være tilgængeligt for flest mulige brugere og som minimum kunne køre på iPhone. Budgettet tillader kun at der udvikles et program.

Løsning for et år siden: Lav et program der kører på iphone.

Løsning om et år, hvis Apple ikke havde ændret betingelserne: Lav et program i et "metasprog" der kan kompiles til iPhone, android etc.

Løsning om et år, nu da Apple har ændret betingelserne: Lav et program der kører på iphone.

Spørgsmål til den langsomme læser: Hvem gavner denne nye situation? Forbrugerne, Apple, ...?

  • 0
  • 0
Jakob Damkjær

http://www.devwhy.com/blog/2010/4/12/its-all-about-the-framework.html

en fornuftens stemme i en shitstorm af hyperbole og flash astroturfing.

Citat:
If Adobe actually wants to persuade Apple to support Flash on iPhone (either as a plugin or compiled to native apps), I know how they can do it. They can get an awesome, high performance, Flash environment working on Android, and get a bunch of great Flash apps running on Android phones. As much as Apple wants to control iPhone, I am willing to bet they want to beat Android more. Currently Adobe is asking Apple to put Adobe in a position where they wield influence over Apple, in exchange for the promise of apps in the future, apps that Apple thinks will be low quality. That is a bad deal. On the other hand, if Adobe proved the apps were high quality by deploying them on competitor's platform, and was offering a library of existing high quality apps that neutralized another competitor's advantage, then there is enough value that Apple probably could be influenced.

  • 0
  • 0
Baldur Norddahl

Det nye krav fra Apple er, at software skal skrives i C/C++/Objective-C eller Javascript. Apple siger ikke ,som overskriften, at tredjeparts-værktøjer giver dårlig kode, men at mellemlag der fortolker kode og kompatibilitetslag er forbudt

Nej, der står direkte at man ikke må oversætte fra andre sprog til maskinkode.

Man må godt lave sin egen oversætter, men den skal oversætte fra de fire nævnte sprog.

Det har ingen gang her på jorden. Valg af sprog afgør ikke et programs kvalitet.

Eftersom det er muligt at lave en oversætter, som oversætter til C, og derefter indlevere C koden til Apple til godkendelse, så er sammenligningen med valg af editor ikke urimelig. Hvor går grænsen? Må jeg heller ikke bruge en editor, som kan skrive kodestumper automatisk for mig? Hvordan vil de opdage det?

  • 0
  • 0
Baldur Norddahl

Hvem laver først en iphone simulator til Android? Den behøver ikke kunne køre programmerne direkte. Bare den kan oversætte et program skrevet i C/C++/Objective-C til iphone platformen med android som target.

Burde kunne gøres med et af de af Apple forhadte mellemlag. Mellemlaget skal bare bruges på Android, hvilket Apple vistnok får svært ved at forhindre.

  • 0
  • 0
Stephen Aaskov

Det har ingen gang her på jorden. Valg af sprog afgør ikke et programs kvalitet.

Nå, hvorfor koder vi så ikke i ADA her i år 2010?

Med Obj-C kan en udvikler skrive et stykke kode der løser en given opgave, på færre linier og mindre komplekst end det ville være muligt i C/C++. Derfor giver ObjC i den sammenhæng mindre risiko for fejl = højere kvalitet.

Eftersom det er muligt at lave en oversætter, som oversætter til C, og derefter indlevere C koden til Apple til godkendelse, så er sammenligningen med valg af editor ikke urimelig. Hvor går grænsen? Må jeg heller ikke bruge en editor, som kan skrive kodestumper automatisk for mig? Hvordan vil de opdage det?

Hvem indleverer C kode til Apple, det lyder som om du har misforstået noget omkring godkendelsesproceduren.

  • 0
  • 0
Poul-Henning Kamp Blogger

Det har ingen gang her på jorden. Valg af sprog afgør ikke et programs kvalitet.

Fint: skriv din næste applikation i INTERCAL og bevis din påstand :-)

Jeg kan faktisk godt følge Steve Jobs her: han vil ikke have en situation som med AcroRead hvor det pludselig er en eller anden middelware dims uden for hans kontrol der skal patches hver anden uge for ikke at være det største sikkerhedshul på hans produkt.

Alt andet lige: Flere kodelinier = flere fejl og dårligere performance.

Poul-Henning

  • 0
  • 0
Mikkel Meyer Andersen

Poul-Henning Kamp,

Alt andet lige: Flere kodelinier = flere fejl og dårligere performance.

Ahh, det var da noget af en udtalelse fra en mand, der (med god grund) ynder asserts i sin kode. At du ikke mener det så generelt er måske det, der ligger i "Alt andet lige"-præfikset :-).

  • 0
  • 0
Poul-Henning Kamp Blogger

Ahh, det var da noget af en udtalelse fra en mand, der (med god grund) ynder asserts i sin kode. At du ikke mener det så generelt er måske det, der ligger i "Alt andet lige"-præfikset :-).

Det var sgu' da den mest dumsmarte kommentar jeg har læst her på version2 i nyere tid.

Aner du overhovedet noget om softwareudvikling ?

Poul-Henning

  • 0
  • 0
Mikkel Meyer Andersen

Tak for det personlige angreb.

Hvad du åbenbart ikke fik fat i, var at jeg kritiserede din meget generelle udtalelse om, at "Flere kodelinier = flere fejl og dårligere performance", for netop i forbindelse med at forhindre fejl kommer der ofte flere kodelinier ind.

Så for at skære det ud i pap: Hvad mener du med udtalelsen?

Edit: Mener du at samme opgave løst i et programmeringssprog, der kræver flere linier, oftest også vil indeholde flere fejl?

  • 0
  • 0
Poul-Henning Kamp Blogger

Mener du at samme opgave løst i et programmeringssprog, der kræver flere linier, oftest også vil indeholde flere fejl?

Jeg mener præcist hvad jeg skrev.

Flere kodelinier i compilere, runtime-miljøer osv, betyder flere fejl.

Asserts er også kodelinier, de kan også indeholde fejl.

Længere er den ikke.

Poul-Henning

  • 0
  • 0
Mikkel Meyer Andersen

Okay, så er vi bare ikke enige, for jeg synes ikke at det kan stilles så sort/hvidt op som du gør.

Hvorfor bruger du så mange kodelinier på at undgå fejl, når du mener som du gør? Personligt gør jeg det for at nedbringe antallet af fejl i programmet.

  • 0
  • 0
Poul-Henning Kamp Blogger

Lad os lige tage den debat en anden gang, det er ikke relevant for emnet.

Så vidt jeg husker er C# runtime på "a number of MLOC", og du kan ikke seriøst påstå, at det ikke øger risikoren for fejl ?

Tommelfingerreglen er stadig "1 fejl per 1000 linier kode"

Poul-Henning

PS: og derudover er der problemet med hukommelsesforbruget, hvis hver app kommer med sin egen X*MB runtime.

  • 0
  • 0
Mikkel Meyer Andersen

For om der er en risikoforøgelse, skal der være noget at sammenligne i forhold til. Så hvad øger risikoen for fejl? Mener du i forhold til, hvis der var færre linier kode?

Og så synes jeg stadigvæk ikke, at man kan svare så sort og hvidt på det. For hvad vil du skære væk fra koden? Hvis det er decideret funktionalitet, så jo - et C# runtime på færre linier kode, fordi det har mindre funktionalitet, vil have færre fejl. Men et C# med færre linier fordi fejltjek er slået fra, vil have flere fejl. Hvis man blot tager et repræsentativt udsnit linier væk (og forestiller sig, at det stadig er gyldigt osv.), vil fejlraten være den samme.

Men den diskussion er lidt kunstig, for linierne findes allerede. Jeg snakkede om, at jeg synes det var fornuftigt at tilføje kodelinier for at undgå fejl.

Selvfølgelig er der relativt flere fejl i et program bestående af flere linier kode end et program bestående af en brøkdel. Hvis det var det, du hentydede til med din udtalelse, er vi helt enige - men så synes jeg til gengæld at min kommentar om uddybning var på sin plads.

  • 0
  • 0
Baldur Norddahl

ADA, Intercal? Man bruger det værktøj der er bedst til opgaven. Hvad der er bedst kommer også an på hvad programmøren har mest erfaring i.

Apples betingelser er jo formuleret, så at man ikke må udvikle et domæne specifikt sprog, som f.eks. Varnish benytter sig af.

For spil er det helt almindeligt at benytte en eller anden "engine" som faktisk kan betragtes som det forbudte mellemlag.

  • 0
  • 0
Poul-Henning Kamp Blogger

Hvad der er bedst kommer også an på hvad programmøren har mest erfaring i.

Huh ???

Ikke på vilkår, på den måde ender hele verden i et morads af Perl.

Sprog skal vælges efter både opgaven og programmøren.

Poul-Henning

  • 0
  • 0
Nikolaj Brinch Jørgensen

Alt andet lige: Flere kodelinier = flere fejl og dårligere performance.

@Mikkel Meyer:
Det kan godt være du ikke synes det, men sådan er det bare.

Derfor programmere vi i øjeblikket applikationer i 3GL og ikke i assembler.

Og derfor er det væsentligt med funktionelle sprog og inkludering af funktionelle udtryksformer i de objekt orienterede sprog.

Groovy er et godt eksempel, der tager skridt til at muliggøre nogle nye sprogkonstruktioner som gør at man skal skrive væsentligt mindre kode, og derfor falder raten af fejl i den løste opgave.

  • 0
  • 0
Mikkel Meyer Andersen

Nikolaj,
Jeg elsker "sådan er det bare"-argumenter. Tak. Desuden bør du nok læse hele debatten og overveje, om det er rimeligt at du trækker den holdning ned over mig. Jeg bad blot om en uddybning for at være sikker på, hvad PHK mente. Og for at få den, var jeg nødt til at sætte tingene på spidsen.

Desuden er udtalelsen stadig meget generaliserende, og nej, sådan er det ikke bare (!). Hvis jeg tilføjer fejltjek i min kode, vil det formenligt sænke fejl per 1000 linier kode. Forestil dig nu bare det simple
if (o->some_number > 0) return 1;
med 1 linie sammenlignet med
if (o == NULL) return 0;
else if (o->some_number > 0) return 1;
der fylder to linier. Jeg vil hellere have dobbelt så mange linier i dette tilfælde...

  • 0
  • 0
Carsten Sonne

Jeg glæder mig til at genoptage samtalen når du har programmeret i 20-25 år.

Hvis du da stadig kan huske hvad MLOC betyder, hehe.

(Kunne ikke lade være)

  • 0
  • 0
Mikkel Meyer Andersen

PHK,
Ja, men for at udbedre fejl, hvad bliver du så først nødt til?

Vi er altså helt enige om, at der er flere fejl i C# runtime end i et 2 liniers int main-program. Og jeg tror skam også, at vi er enige om, at det godt kan betale sig at tilføje linier for at indføre fejltjek. Ret mig meget gerne, hvis jeg tager fejl.

Hvad der så går galt i kommunikationen, der får dig til at insinuere, at der er noget jeg tydeligvis ikke forstår, ved jeg ikke. Det er dog korrekt, at jeg ikke har programmeret i 20-25 år, men det gør vel ikke, at jeg ikke må være kritisk?

  • 0
  • 0
Piotr Czarny

Hov hov hov du.

Perl kan i det mindste lægge to strenge sammen, uden at det bliver til en sikkerhedsrisiko :)

C-programmører har et tyndere runtime-lag med færre indbyggede fejl. Til gengæld har de det med selv at lave alle fejlene.

Du vil sikkert straks argumentere for, at det er et spørgsmål om at være en dygtig low level programmør. Det er det også.

Men selv dygtige programmører kan blive pressede, stressede og sløsede. Især når de ikke må bruge Adobe CS5 og skal skynde sig rigtigt meget for at nå at skrive deres mobile applikation om til Android og Windows Mobile.

  • 0
  • 0
Nikolaj Brinch Jørgensen

Jeg elsker "sådan er det bare"-argumenter. Tak.

Tager du alting meget personligt? Nå nok om det.

Læg mærke til at der skrives:

Tommelfingerreglen er stadig "1 fejl per 1000 linier kode"

Ved du hvad det betyder? At de 1000 ikke er eksakt. Det kan være 880 eller 1100, men i slag på tasken.

if (o->some_number > 0) return 1;

vs.

if (o == NULL) return 0;
else if (o->some_number > 0) return 1;

Det kommer jo an på kontrakten, kun hvis NULL skal give 0 er det korrekt, ellers er dette også en fejl.

Men de linier du beskriver er jo totalt ude af kontekst og det er totalt umuligt at vide hvor mange fejl der egentlig er i dem.

  • 0
  • 0
Mikkel Meyer Andersen

Nikolaj,
Nej, jeg tager ikke alting personligt, men at afvise kritik med "sådan er det bare", synes jeg er morsomt.

Ja, jeg er skam også med på, hvad der menes med en tommelfingerregel. Det eneste jeg er imod, er kommentaren om at det nødvendigvis introducerer flere fejl at indsætte flere linier i koden, for det er jeg ikke enig i. Nogle gange jo, men ikke altid (deraf nødvendigvis, hvis du ellers ved hvad det betyder).

Eksemplet skulle illustrere et typisk null pointer-problem, og hvordan at indsættelse af ekstra linier kunne afhjælpe dette. Returværdierne skulle ikke tillægges særlig betydning.

  • 0
  • 0
Nikolaj Brinch Jørgensen

Nej, jeg tager ikke alting personligt, men at afvise kritik med "sådan er det bare", synes jeg er morsomt.

Der er forskel på kritik og så at tale imod fakta.
Du kan jo bestride fakta, ved at starte med at komme med et bevis for at tommelfingerreglen med 1 fejl pr. 1.000 liniers kode er forkert?

Nogle gange jo, men ikke altid

Jo altid - det er risiko vi taler om her.
Jeg forstå slet ikke din tolkning. Hvordan vil du afgøre om din tilføjelse tilføre fejl eller ikke?

Eksemplet skulle illustrere et typisk null pointer-problem, og hvordan at indsættelse af ekstra linier kunne afhjælpe dette. Returværdierne skulle ikke tillægges særlig betydning.

Men der er jo problemet. Nullpointer problematikken er da en del nemmere at finde i en test fase end at programmet bare opføre sig helt underligt et sted ude i fremtiden fordi noget blev sat til 0.
jeg tror det er det her du har lidt problemer med at forstå.
Tilføjelsen af din linie øger risikoen for fejl i og med der nu er flere linjer i programmet. Flere linjer der kan laves fejl i. Jo flere ord der er i en bog jo større er chancerne for at der er stavefejl i den, og jo flere stavefejl vil der i gennemsnit være.

  • 0
  • 0
Poul-Henning Kamp Blogger

Det er dog korrekt, at jeg ikke har programmeret i 20-25 år, men det gør vel ikke, at jeg ikke må være kritisk?

Nej, det gør at du ikke er kommet tilbage til din egen 10 år gamle kode og tænkt "Hvem er den klytkoder der..."

Programmering er et håndværk og en kunst. Håndværkeren bliver god til sit håndværk, men kunstneren bliver både god og klogere på sit håndværk.

Derfra hvor jeg sidder, kan jeg se fire fem dimensioner til håndværket, som du åbenbart ikke har luret endnu.

Og nej, du får ikke en facitliste af mig.

Poul-Henning

  • 0
  • 0
Michael Balle-Pedersen

Perl kan i det mindste lægge to strenge sammen, uden at det bliver til en sikkerhedsrisiko :)

Det framework du anvender på en iPhone indeholder en fin klasse til at arbejde med tekststrenge, så du ikke behøver bruge C til den slags.

  • 0
  • 0
Mikkel Meyer Andersen

Nikolaj,
Der er ikke kun én synsvinkel på sagen, som jeg tidligere har sagt.

Jeg snakker om, at givet et stykke kode, hvordan vil sandsynligheden for fejl så opføre sig, hvis man indsætter kode, der tjekker for fejl.

Så vidt jeg kan forstå, snakker PHK og dig om den ubetingede sandsynlighed.

Som du sikkert ved, er der forskel på betingede og ubetingede sandsynligheder. Og så er det rigtigt, at det jeg siger ikke giver så meget mening.

Jeg har aldrig bestridt den ubetingede sandsynlighed for, at en linie indeholder fejl.

Du skriver

Flere linjer der kan laves fejl i. Jo flere ord der er i en bog jo større er chancerne for at der er stavefejl i den, og jo flere stavefejl vil der i gennemsnit være.

Mener du virkelig det sidste, du skriver, eller har du skrevet forkert?

Nullpointer problematikken er da en del nemmere at finde i en test fase end at programmet bare opføre sig helt underligt et sted ude i fremtiden fordi noget blev sat til 0.

Som nævnt var returværdien tænkt. Mere realistisk ville jeg nok kaste en exception eller lave det som assert. Jeg er stadig fan af sådanne tjeks, for få laver udtømmende tests, der afprøver alle stierne gennem programmet. Men man skal naturligvis også lave tests.

Tilføjelsen af din linie øger risikoen for fejl i og med der nu er flere linjer i programmet. Flere linjer der kan laves fejl i. Jo flere ord der er i en bog jo større er chancerne for at der er stavefejl i den[...]

Pas på med din analogi med bogen - for når jeg tilføjer kodelinier, der tjekker for fejl tilføjer jeg rigtigt nok linier, men samtidig gør jeg det for at fange andre fejl. Så igen, ubetinget vil tilføjelser af linier hæve antallet af fejl, men betinget med at det er en fejlkontrollerende linie mener jeg altså stadigvæk, at det godt kan svare sig.

  • 0
  • 0
Mikkel Meyer Andersen

PHK,
Jeg er ikke i tvivl om, at du både er bedre kunster og håndværker end mig, og det er en af grundene til, at det er spændende at få lov til at diskutere med dig. Jeg mener stadig at vi snakker om forskellige ting, se evt. indlægget lige ovenfor.

Selvfølgelig har du luret mange ting, som jeg endnu ikke har luret. Og aldrig vil komme til. Som nævnt er jeg enig i dit udsagn efter at jeg forstod, hvad du præcist mente.

  • 0
  • 0
Nikolaj Brinch Jørgensen

Mener du virkelig det sidste, du skriver, eller har du skrevet forkert?

Du har ret, jeg skrev forkert, streg "i gennemsnit". Det understreger blot pointen, jo flere ord, jo flere fejl (både syntaktiske og semantiske).

Pas på med din analogi med bogen - for når jeg tilføjer kodelinier, der tjekker for fejl tilføjer jeg rigtigt nok linier, men samtidig gør jeg det for at fange andre fejl. Så igen, ubetinget vil tilføjelser af linier hæve antallet af fejl, men betinget med at det er en fejlkontrollerende linie mener jeg altså stadigvæk, at det godt kan svare sig.

Jeg gider ikke skrive det for jeg ved ikke hvilken gang. Hjælp! Din sondring med at nogle linjer skulle tjene til at nedbringe risikoen og dermed antallet af fejl i programmet er forkert. De linjer du tilføjer kan jo selv indeholde fejl, så ender du med at have indført linjer som muligvis får et korrekt program til at fejle.

Som nævnt var returværdien tænkt. Mere realistisk ville jeg nok kaste en exception eller lave det som assert. Jeg er stadig fan af sådanne tjeks, for få laver udtømmende tests, der afprøver alle stierne gennem programmet. Men man skal naturligvis også lave tests.

For det første vil du få en exception (NullPointerException), derudover har disse tjeks det med at have et meget lille formål, hvis ikke der er tests til at bevise at de virker. Dermed rammer man asserts i produktion i stedet for i udviklingsfasen, og det er for dyrt og ligegyldigt. Skal man bruge asserts, skal i mine øjne allerhelst laves med metaprogrammering.
Desværre har vi stadig en masse udviklere der enten er dovne, eller også tror de, at de er så kloge at de ikke behøver skrive tests. Det er godt at du har fundet ud af vigtigheden af unit tests.

  • 0
  • 0
Per Hansen

Jo mere kode, jo mere uoverskueligt, jo mere fejl. Dette gælder også fejlhåndtering.

Jeg har set 3 liniers kode dækket ind af 50 liniers fejlhåndtering. Totalt uigennemskueligt hvad der egentligt sker, og dermed også øget chance for at introducere nye fejl.
Dermed ikke sagt at man ikke skal lave fejlhåndtering, det skal bare ikke gøres ukritisk ved at sylte alt ind i ekstra kode (som der egentlig også burde laves fejlhåndtering på .. )

  • 0
  • 0
Carsten Sonne

Antallet af fejl i en mængde kode afhænger af mange ting, henunder selvfølgelig mængden af kode. Det er bare ikke den eneste parameter der afgør hvor stor sandsynligheder er. Øvrige parametre er bl.a.
1) Test - Jo bedre koden af testet, jo flere fejl er fundet.
2) Design/Kodeorganisering - Et design kan afhjælpe mange kodefejl. Et design kan veje så tung på skålen at det kan betale sig at lave flere linier kode og alligevel få mindre fejl.
3) Viden - Viden om koden, teknikker og domænet gør selvfølgelig, at man har tendens til at producere mindre fejl.

Derudover findes der forskellige typer af fejl. Nogle gange kan det være uklart om en fejl egentlig er en fejl. Det afgørende kan være en kravspecifikation eller hvad behovene er.

Forskellige typer fejl kan reduceret med forskellige teknikker:
1) Statisk fejl - Fejl i datatyper, funktions/metode kald ol. Kan fanges compiletime. Fortolkede sprog kan have lignende værktøjer såfremt sprogen er typestærkt osv.
2) Runtime fejl - Fejl kan fanges via test og til dels kodeanalyse.
3) Logiske fejl - Typisk svære at finde og dem som finder vej til produktionsmiljøet. De værste fejl kan kun fanges med domæneviden (og gode aftaler med aftageren af softwaren).

Fejl er ikke bare fejl og raten er ikke bare statisk ift. mængden af kode.

  • 0
  • 0
ab ab

Ifølge New York Post - ikke Verdens mest pålidelige kilde, bevares - ligger to amerikanske myndigheder (Department of Justice og Federal Trade Commission) netop nu i "forhandlinger" om, hvem der skal indlede en undersøgelse af Apples seneste ændringer i SDK-betingelserne:

http://www.nypost.com/p/news/business/an_antitrust_app_buvCWcJdjFoLD5vBS...

Det er godt nok bare en anonym kilde, som tabloidavisen har til dækning for historien, så ind til videre hviler den på et ret spinkelt grundlag. Det har dog ikke afholdt nærmest hele blogosfæren fra at citere historien..

  • 0
  • 0
ab ab

En lille korrektion til ovenstående. Det som FTC og DoJ angiveligt overvejer er en såkaldt indledende høringsskrivelse i stil med den, som FCC tidligere sendte til AT&T, Google og Apple i forbindelse med Apples beslutning om at formene Googles såkaldte Voice-applikation adgang til deres platform.

Afhængig af udfaldet af denne "høring", kan den relevante myndighed beslutte at iværksætt en egentlig undersøgelse, men det sker langt fra altid, at en indledende høring fører til en undersøgelse.

  • 0
  • 0
Nikolaj Brinch Jørgensen

Det er bare ikke den eneste parameter der afgør hvor stor sandsynligheder er. Øvrige parametre er bl.a.

Du har ret - men kan du kvalificere det? Det er ikke nok at sige at der er færre fejl jo bedre koden er testet. Koden kan ikke blive af bedre kvalitet af at blive testet meget. Man kan ikke teste kvalitet ind i sin kode/sit produkt - det skal bygges ind fra start.

Mængden af fejl i kode er nogenlunde ligefrem proportional med kodemængden. Det kan kvalificeres.

  • 0
  • 0
Log ind eller Opret konto for at kommentere