Topudvikler: Programmeringssprog er meget dårlige

Så mange har forsøgt, og oprettet høj niveau sprog, som ofte er de 100% fokuceret på at løse et par problemer, og så snart man bevæger sig til udkandten af domænet, så bryder sproget sammen, og bliver belastning.. Dette er set så mange gange før, ved divs. 4GL implementeringerne.

Men faktisk fra mit synspunkt (ca 15 år i branchen som programmør), så har divs nye sprog ikke forbedret situationen et forfærdenligt meget ud over at komplicere livet for udviklere, da man nu ikke kun skal løse problemet mellem server og klient, men nu også mellem de forskellige trendy sprog og platforme (java, .net, Native code, m.v.)

Jeg er fuld ud klar over at alle computer sprog har begrænsinger, og kræver forskellige kompetancer, men jeg har endnu ikke oplevet et high level sprog der kan bruges i alle tilfælde, fordi de abstraktere for meget.

Som ofte det der kommer ud af de nye sprog er forøget resource forbrug, som jeg undre mig meget over i en tid hvor alle synger og Danser om CO2 udledning. Noget der kommer af resource overforbrug, mange programmer benytter gigantiske resourcer, selvom de reelt ikke løser nye problemer, i forhold til gamle programmer. Feks er en simple editor til breve, m.v. vokset sig fra ca 200-800kb, 8 MHz processor, inklusiv fonte, til 200+MB af ram forbrug, samt mindst 2+GHz processor.

Personligt mener jeg at vejen frem, ikke er nye sprog, og filosofier, men derimod at kigge tilbage, og opsamle hvad der var godt fra de forskellige æra, helt fra modulær design tiden til nu, og bygge metoder, og systemer som er effektive, ikke kun i udviklings tid, men i resourcer, og stabilitet.

Men jeg er enig i at man skal identificere sig med håndværket og ikke værktøjet, jeg er selv en system udvikler, jeg arbejder i de sprog mine kunder ønsker.

Problemet er vel ikke så meget at mange programmeringssprog er decideret dårlige. Problemet er vel snarere at de ukritisk bliver brugt til at løse alle klasser af problemer, også dem de ikke egner sig til.

Der er vel ingen der vil klippe græsset på en fodboldbane med en neglesaks. Alligevel er det ofte det man ser i programmering. Jeg har selv hovedsagelig beskæftiget mig med at lave administrative programmer, altså ERP og CRM systemer og den slags. Til sådanne programmer er database tilgang den aller vigtigeste tekniske forudsætning, men samtidig også det man ikke ønsker at bruge tid på. Jeg har til det formål hovedsagelig benyttet Visual DataFlex som er et såkaldt 4GL prorgammeringssprog som netop frigør alle de resourcer man ellers skulle have brugt på at styre sin database, opdatere skærmbilleder etc.

Hvis kan kan tale om database programmering som et domæne, så er Visual DataFlex netop et sådan meget stærkt domæne specifikt programmeringssprog.
I de tilfælde hvor man ikke kan løse et problem med Visual DataFlex, så benytter man sig bare at en Active X komponent, eller lign.

Klaus Berthelsen

Jeg mener at evnen til at vurdere et om programmeringssprog er godt eller dårligt består i evnen det har til at løse den specifikke opgave. Ergo, er det noget vås at give programmeringsprog overordnede karakterer. Hvis nogen kommer og kalder sig nordens bedste, og ikke kan sige det er sandt, kan han lukke nok så mange argumenter ud, de vil ganske enkelt ramme ved siden af, og i mine øjne har Ola Bini gjort sig grundigt til grin.

Nogle opgaver er store og kræver stærke typer samt en overordentligt stram syntaxpolitik, fordi det erfaringsmæssigt giver bedre fejlhåndtering. Der findes ikke programmer uden fejl, og programmeringssprogets evne til at fortolke fejl er ligeså vigtig som evnen til at løse selve problemet. Desto mere åben man lader typerne arbejde, desto større chancer er der for, at fejl først bliver fanget langt ude i systemer - hvis de bliver fanget overhovedet. At fejl bliver fanget i tide, er essentielt i kritiske systemer.

Det er en illusion at tro, at man kan efterlade et problem, efter det er løst, hvilket er en problemstilling jeg i den grad savner i open source verdenen - måske fordi det ganske enkelt ikke kan lade sig gøre at have erfarne udviklere stående på sidelinjen til at tage sig af de nye problemer, når de opstår - og få dem løst, inden de koster penge.

Derfor ringer mine alarmklokker højere end domkirkén i Rom, når en udvikler som Ola Bini på storhedsvanviddets rand udråber sigselv til nordens dygtigste programmør, kan komme med udtalelser på et så lavt niveau.

Skal man vurdere et programmeringssprog, er det i evnen til at løse problemer på både højt og lavt niveau. Java udmærker sig ved at være superskalérbart, men sandt at sige må man ud og finde en overligger, hvis man vil programmere på endnu højere niveau. Det samme gælder andre sprog som pascal (Delphi), C#/.NET, C/C++ med en smule respekt for sigselv - de ovennævnte leverer mulighed for både at bære avancerede domænespecifikke opgaver og mindre tidskrævende algoritmer.

Og som antydet af de fleste, skal man op i domænespecifikke sprog, for at løse avancerede problemstillinger på en enkel måde; Men det er ofte med den svaghed, at det koster at bevæge sig udenfor de domæne specifikke opgaver, nøjagtigt ligesom det koster friheden at bevæge sig fra udviklede systemer til standard systemer. Gud ske tak og lov for det, ellers kunne jeg se mig om efter et andet arbejde.

Derimod er jeg ganske enig i den betragtning, at udvikling er et håndværk, som ikke er afhængigt af det eller de sprog man mestrer, men at springe fra en IT-uddannelse fordi man ikke lærer noget, er for mig et klart signal om, at man ikke har lært at lytte - og at lytte, er en af udviklerens fremste opgaver.

Det er vist længe siden programøre bekymrede sig synderligt om performance og effektivitet. De sidste version af for eksempel windows kræver en monster maskine. Tonsvis af tung kode...

Der er nu intet der matcher APL

Jeg anses muligvis som gammel-i-gårde, men det kan jeg godt leve med

Som programmør kan man ligesågodt lære at tænke som en 'maskine' mens man vel stadig er et 'menneske' og har en slags baggrund for de opgaver man skal 'programmere'.

Husk på, programmøren er en 'oversætter af tanker fra den menneskelige verden til den maskinelle verden' og indtil vi har rigtig AI kørende, så kan vi ligesågodt acceptere at vi er den programmerebare verdens typografer.

Til det er assembly programmering det bedste der findes, kun begrænset af hardwaredesignernes tåbeligheder og f.eks. mangel på forståelse for at vi gerne vil have én kommando til at flytte et register til et andet sted (f.eks. hovedlageret), og ikke først skal sætte et andet register for derefter at flytte data, bare fordi de ikke kan lave noget logik der skiftes helt over, og så måske lige den lille detalje at det ikke er særlig porterbart til andre arkitekturer ... nå ja

Anyway, derfor er det næstbedste C, som er det nærmeste assembly vi har, og hvor man så dermed ligesågodt kan overveje at se efter de egentlige forbedringer der kan forventes.

Fordelen med en programmerbar maskine er jo netop at den er programmerbar, og det bedste er jo hvis man kan programmere den ligesom man vil, men deri ligger også dens problem. For hvis én kan programmere den ligesom han/hun vil så er det måske ikke det samme som en anden vil.

Og deri ligger den fine balance mellem hvornår det er fine grænser og hvornår det er et fængsel der bare ikke er til at holde ud.

Mine erfaringer gennem en del år er at C sproget er ganske godt som struktur, for ligesom assembly supporter det alle teknologier, men dets svaghed er så at det også understøtter at blive hacket til ukendelighed.

Ergo er C et sprog der henvender sig til den uddannede professionelle programmør der har viden indenfor sit område og disciplin til at holde sig indenfor rimelige grænser.

Lidt bedre typechecking end selv ANSI C har, som f.eks. i C++ kan dog være en stor hjælp, for selv den professionelle kan komme i tvivl med typen, og man gider ikke altid konstant at grep'e for at finde det man leder efter.

Jeg er dog ikke enig i at gå hele vejen med at benytte objektmodellen som Bjarne og andre forklarer det, i selve sproget for C++ er et halvfærdigt sprog der alligevel kræver at man hacker det, og så vil jeg hellere have et 'ægte' C sprog.

Det der kan hjælpe et hvilketsomhelst sprog er udviklede biblioteker der løser specielle opgaver. Fortran har jo levet længe på dette og gør det vel stadig kun pga. af det.

Altså, væn jer til at der ikke findes nogen sølvkugle der kan gøre 'almindelige mennesker' til professionelle programmører, endsige afhælpe selvsamme professionelle programmørers fejl uden ordentlig uddannelse og erfaring.

Udviklingsmæssigt er vi endnu ikke længere end da geværpibemagerne fra slut-1800 skulle trække stålet til en fornuftig geværpibe.

Alle nyere sprog end Fortran og C har interessante elementer i sig, intellektuelt synes jeg Lisp er spændende mens jeg industrielt synes Erlang er meget spændende, og de to er ikke helt fra samme ende af verden

Dog er ingen som sådan 'dårlige' men de kræver ofte en hel del af deres brugere, og det er nok det som mange ikke kan acceptere. Ligesom det var lettere at tage et bil-kørekort i 'gamle dage' var det egentlig også simplere at programmere en maskine før, mens det er meget mere kompliceret idag, men det skyldes ikke problemer med sproget som sådan, men mere omgivelserne der er meget mere komplekse end før.

Da den bedste kontrol med omgivelserne opnås med et enkelt sprog som C vil jeg derfor give min stemme til C, og samtidig ønske lidt type opstramninger som f.eks. ANSI C og C++ giver, fordi det hælper programmøren i det lange løb.

Jeg var ellers helt sikker på at vi havde mindst to sprog som manden efterlyser: Cobol & Fortran, de var begge udviklet til forretningsspecifik udvikling.

.. gennem 10 år, må jeg indrømme nogle gange trækker jeg ldt på smile båndet af compilerverdens udvikling .... i 1995 (tror jeg nok) kom Delphi 1, og ca. samme tid C++ builder +/- et par år. De er blebet trend sættende for hvordan man udvikler et sprog ...

C++ fololkende har ALTID udråbt det til "den vej går vi adrig sproget" .. Men i dag er "alle" på vej der hen.

Se bare på C# det ligner Delphi meget, på mange punkter ... INDRØMMET på andre punkter er de "foran", hvis der er noget der hedder sådan. Men lad os så sige der er nogle ting der er nemmere i C# end i Delphi, men det sjove er: Microsoft har hugget hoved ideen i miljøet og ladet sig kraftigt inspirere i sproget ...

Button1.Caption = 'Test'; Button1.Caption := 'Test';

Vi lader lige de to sætninger stå for sig selv.

Min pointe er verden går den rigtige vej. Ikke bare fordi den, men mine briller går "Delphi" vejen, men fordi ange ting BLIVER nemmere og nemmere at kode.

Tænk bare på hvor meget skal der til for at skrive GUI i C++ vs. C#/Delphi ?

Så fokus mod compileren BLIVER mindre når ellers der kommer noget ordenligt GUI håndtering.

Så til forfatteren af artiklen : Ola Bini og alle jeg andre : FAT mod GUI og højniveau er kommet for at blive.

Jens B

Min hoved pointe var at rigtigt mange ting er meget nemmere i Delphi i forhold til C++. Rigtig mange af de ting er taget med over i C# hvilket glæder mig.

Jeg ved godt der er mange andre ting end GUI.

GUI håndteringen var bare ment som et eksempel på noget der frigav recourser fra compileren og over mod domæneproblemet ...


Der findes jo i Delphi/c# en milliard ting som bringer dig i den retning i forhold til c++

Jens B

Det er simpelthen for tyktflydende det her.

Ikke så snart har filmatiseringen af Stieg Larsson's roman nået uanede succeshøjder, før medierne skal storme ud for at finde hende den hyperintelligente EDB-haj i virkelighedens verden!

Og ved Gud om de ikke finder en sortklædt, tungepiercet afviger som endda kan lufte kontroversielle holdninger!

Det kan da få enhver journalist til at skrige af fryd!

Har han virkelig skrevet en programmeringslinie da han var syv år? Fanatastisk! Det er næsten bedre end hvis han kunne gå på vandet!

Og det han lukker ud er da komplet værdiløst.

Gad vide om journalisterne også havde slugt det hele råt, hvis han havde hævdet at abacus'en bliver den næste revolution?

Som gammel kodekarl med 2,5 million linier bag mig i C, Java, Delphi og C# har jeg også en mening dette spørgsmål.

Den unge mand i interviewet er sympatisk men uerfaren.

I gamle dage, dvs. i 1990 var vi teknologisk nået til slutningen af mainframens dominans. Den gang var det utroligt vigtigt at design kode, sådan så det kunne fungere i samtidighed, og det måtte kun bruge så og så mange mips. På samme måde da vi kodede på Unix maskinerne, hvor mange mennesker skulle interagere med applikationerne og databaserne samtidigt - det nytter at så snart to brugere finder på at kalde to funktion som bruger samme db-ressource får det hele til at fryse - i dag er det nærmest almindeligt - vi retter fejlene som de kommer, vi forebygger ikke, vi retter - og tænk blot på Becks eller Boehms cost of change - IT ER for dyrt, fordi vi ikke er gode nok til at holde kravene nede og bruge tiden på at gennemtænke softwaren - i stedet for, finder vi os i absurde projektplaner og krav.

På et tidspunkt så skete der det at vi fik Windows og så kom alle de herlige og nemme sprog som f.eks Visual Basic og ASP. Alle kunne kode med, også skolelærene.

Og så gik det ellers ned af bakke for performancen og kvaliteten, og det er faktisk gået ned af bakken lige siden. Min tese er at hvis computerne have udviklet i halvt tempo ville både Visual Basic og ASP være kvalt i fødslen - de fungere bare ikke som de skal. Det samme gælder elendige database connectorer som odbc.

Problematikken er at Microsoft og alle andre fortæller cheferne at "nu er det blevet 10 gange hurtigere at kode" - og så farer de ned til IT-chefen og siger "kod 10 gange hurtigere" - men det er bare ikke virkeligheden.

I min optik bliver kvaliteten af det producerede software, ringere og ringere. Jeg mener faktisk at software kvaliteten falder og falder; jeg kan købe software i dag, som crasher det øjeblik jeg dobbeltklikker på det, og jeg skal nu selv ud og google, gå på experts exchange og al verdens, rode rundt med alle mulige ting og sager - det skulle jeg ikke i gamle dage for at installere software, der var det hardwaren er drillede. Problemerne rammer ikke kun softwaren applikationerne, men også vores alle sammens elskede Windows - se bare Vista! Christ!

Alt alt for meget software er stopfyldt med elendig fejlhåndtering og halv-gemmentænkt multiuser håndtering (elendig performance) - netop fordi cheferne mener at nu er det nemt at kode og at det SKAL GÅ STÆRKT.

NEJ, det er ikke nemt at kode, og vi kan heller ikke spare på kvaliteten og afprøvningen. Men vi gør det raskt væk alligevel. Skru ned for forventningerne og lav kvalitet. Brug tiden før sammenbrudene, og undgå dem. Albert einstein blev engang spurgt hvad han ville gøre hvis han fik en 1 time til at redde verden - hans svar

"Jeg ville bruge 55 minutter på at gennemtænke en løsning, og 5 minutter på at udføre det"

I dag bliver der brugt "5 minutter på at løse det, og 55 minutter på at konstatere at problemet ikke blev løst"

Men pointen i at sprogene er dårlige til kommunikation er sådan set rigtig nok - men blot fordi kravene til leveringshastighed stiger og stiger, også selvom vi i al væsentlighed ikke er blevet bedre til at levere.

Problemet er min optik, IKKE at sprogene er dårlige, der er masser af gode sprog, C# er såmænd ikke så ringe implementeret, heller ikke selvom de dårlige programmøre bydes til med halvfordummende trashcollectorer m.v, ligesom både C++, Delphi samt Java stadigvæk har masser at byde på.

og her vil citere en rigtig IT-mand som efter min mening har forstået problematikkerne:

"Personligt mener jeg at vejen frem, ikke er nye sprog, og filosofier, men derimod at kigge tilbage, og opsamle hvad der var godt fra de forskellige æra, helt fra modulær design tiden til nu, og bygge metoder, og systemer som er effektive, ikke kun i udviklings tid, men i resourcer, og stabilitet."

Ola Bini kommer til Aarhus den 5. maj og København den 6 maj.

Læs mere på:

Aarhus: https://secure.trifork.com/ (...)

København: https://secure.trifork.com/ (...)