Bjarne Stroustrup om fremtidens C++ standard

Øv. Jeg er træt af at det bliver nemmere og nemmere at programmere. Der er snart ikke noget specielt ved at kunne det mere :P

#1

I stedet for at kunne gøre det, skulle man måske koncentrere sig mere om at gøre det godt nu. :)

#1 Der har aldrigt været noget "specielt" ved at kunne programmere. Udover det niveau af "specialitet" reserveret til en hvilken som helst evne. At kunne lave mad, at kunne cykle at kunne bygge huse.
Der er noget specielt ved at være god til disse ting. Desvære er det med programmering, som med alle de andre, 89% af dem der påstår at de er gode til det har misforsået hensigten med betegnelsen god i forhold til området.

At C++ bliver lettere for novicer betyder sandsynligtvis ikke at flere vil lærer det, men derimod at dem der i forvejen ønsker at lærer det vil kunne gøre dette lettere, og med færer store forhindinger. Derudover vil det forhåbenligt også betyde at antallet af 'fejl' som mange novicer laver vil være sværer at producere.

specialiserede features, og Bjarne Stroustrup argumenterer i artiklen for, hvorfor det er således. Nye features vil som oftest ikke komme med i den nye standard, men i stedet kunne findes i Standard Library faciliteterne.

Apropros det så har GCC (libstdc++) allerede nogle af de nye TR1 features og Dinkumware (leverandør af STL til MS Visual C++) er næsten færdige med deres implementering og forventer at offentliggøre deres arbejde snart. Selv om en compiler ikke behøver at implementere TR1 for at kalde sig Standard C++ så ser det ud til at vi kan få glæde af det snart på de fleste platforme.

De vedtagede forslag til TR1:
http://www.open-std.org/jtc1/sc22/wg21/docs/librar...

Nuværende draft:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers...

Undskyld mig lige, hvis jeg spørger dumt, men skulle han ikke være død?

Hey, hvasså? Har I aldrig set en sand slamkoder før?
En, der tør og som gør alt det nørderne spø'r
om man kan og hvordan - er det kodet i C?
Er det DET, der skal til? Er du Superman? (Yes)
for med en goto kan... hey, HEY, stop for fanden!
"Sagde han egentlig ikke lige G-ordet, ham manden?"
Og Bjarne Stroupstrup sagde... Ikke en skid, dit kvaj!
Han er DØD! Han hænger nede i kælderen hos mig. (haha)
C64 var egentlig ret fedt et sted
der var - der var - der var bare for få bitchs at fedte med, så jeg skred
over til Amiga for at finde gejsten
der var en del flere bitchs - der var faktisk 16.

Sorry, jeg kunne ikke lade være, da jeg så nyheden ;-D

Ja definér en god programmør.

En god programmør for mig er en som definerer struktur og kanon arkitektur.. og ikke om vedkommende synes at det er cool at arbejde med pointer pointer relationer.

Kode som udnytter de tilgængelige metoder.. Rekursion f.eks. hvor mange benytter egentlig det? Og kan en programmør sætte sig et design pattern for og derved gennemtvinge et design?

Der er mange faktorer

Nu er jeg selv Delphi programmør og jeg mener det vigtigeste for en programmør er at kunnne udvikle programmer som er så brugervenlige for en kunde som muligt... Faktisk bliver kodning svære jo mere brugervenligt et program skal være, da det bliver komplekst. Kan du kode noget, som virker så dårligt for en bruger at man opgiver programmet, så er det lige meget hvor inviklet og kompliceret din kode er. For brugeren vil synes det er noget lort... Og uden en tilfreds bruger intet program = ingen penge.

Så er meget enkelt. Men jeg vil heller ikke mene at hvem som helst bare lige kan programmere idag.. Det tager godt nok lang til for at blive en 'god' programmør som kender sit udviklings tool godt nok til at han kan drage nytte af alle dets functioner.

GZZ

Hvis der er nogen der ikke lige fanger #5, så tjek her. Den er ret spas.

gzz:
Det kan jeg ikke gi dig ret i.

En udvikler skal ikke lave GUI'en det skal GUI experter, som så fortæller dig hvordan den skal bruges.
Det er selvfølgeligt så vigtigt at følge disse regler.

Husk også der findes utroligt mange programmer der slet ikke har en GUI. Gui'en er forhåbentligt alligevel kun det øverste lag i din kode, alt derunder skal ikke kende til GUI'en.

...ikke om vedkommende synes at det er cool at arbejde med pointer pointer relationer.

Det er jo ting som Java og C# har udryddet, af produktivitetsårsager. Det giver dog stadig en utrolig tilfredshedsfornemmelse, at skrive en algoritme så effektivt som muligt, at se ens kode accelerere i performance. Desuden findes der andet end business software. Spil, OS'er, drivere og mission kritiske programmer vil vi blive ved med at se skrevet i C/C++.

Jeg bruger skam tit rekursion, det er da skønt at man kan lade stakken arbejde for sig og lade problemet være en uvildig størrelse. Skal du rende igennem en bibliotekstruktur, regne med power funktioner, skrive en top-down parser osv. er rekursion anvendt konsistent i alle sprog.

Men ting som multibel nedarving og sådanne eksotiske ting ville være rart af få opdateret. Et "rent" sprog er vigtigere for mig, end naiv bagudkompatibilitet, så må folk benytte en ældre compiler! Se bare på Java, hvor deprecated og bloated det efterhånden er blevet.

Jeg tør ikke rigtigt bruge rekursion i C++, med mindre jeg ved at arbejdsopgaven er meget lille. C++ kræver nemlig ikke at compilere understøtter tail-recursion, som f.eks. Scheme gør (og stort set alle Common Lisp-implementationer, selvom det ikke er et krav ifølge standarden).

Der er MANGE der bruger rekursion, måske ikke altid i C++. Men i en hel del andre mindre komplekse sprog, vil rekursion være naturligt i forbindelse med analyse af store datamængder.

I bund og grund har produktet ikke en skid at gøre med om koden er god eller ej. Sådan er den virkelige verden med bundlinjer osv jo bare ikke.

#10, hvad er der galt med multipel nedarvning? Du har nok anvendt kode der bruger multipel nedarvning ca. 10.000 gange, eftersom standard template biblioteket benytter det, især i stream klasserne. Løsningen er jo bare at nedarve virtuelt.

#7, ikke alt kode er synlig for brugeren. Langt de fleste tænker jo ikke over at en Oracle database er C++ kode (meget er..det hele er sikkert ikke). Iøvrigt skal kode jo netop aldrig være kompliceret eller indviklet, hvilket C++ heller ikke lægger op til. En del misforstår begrebet kompleksitet, og tror at fordi du ikke er bundet på hænder og fødder som med Java eller C#, så er altid noget værre indviklet rod. Andre går galt i byen fordi de synes det er mærkeligt at man skal kode alting selv, da standarden ikke indeholder så mange specifikke biblioteksklasser som Java eller C#.

#6, Design patterns skal ALDRIG følges slavisk, de er blot en hjælpende hånd. Hvis man går på kompromis pga et pattern, har man misforstået hele idéen med patterns.

C++ er ikke løsningen på alt, men det er nu er smukt sprog når man lige kommer lidt ind bag 101 teorien.

...hvad er der galt med multipel nedarvning?

At nedarve en implementation er i sig selv ikke så fleksibelt som at benytte et composite pattern. At nedarve fra flere implementationer er endnu værre.

Der er selvfølgelig steder hvor det er anvendeligt, primært i frameworks. Nu du selv omtaler streams, så er Java's stream del netop opbygget omkring decorator og strategy mønstrene, således at funktionalitet kan tilføjes samtidig med at problemer med stærk kopling undgås.

C++ er fra en tid før design mønstre og selv om man i teorien godt kan "skrive til interfaces" (via virtual...) så har jeg set alt for meget C++ kode som er skrevet op imod en statisk implementation.