mboost-dp1
SXC - clix
Han får det næsten til at lyde som om at fremtidens programmøre bare skriver "Mission:Lav et nyheds/forums system online. Name=newz.dk" også sker resten selv...
Not gonna happen.
Noget af det kan jeg dog følge:
Ingen diske.
Bisværm af test (tildels, men ikke så lang ude som beskrevet).
Masser af genbrug.
Skalering som en leg.
Alt det autokonfigurering han snakker om tror jeg ikke på. Du vil aldrig kunne trække et "user" objekt ind i koden også forbinder den automatisk med databasens "bruger" tabel. Jo, hvis du giver den forbindelsen, kan den selv analysere strukturen og lave insert/update/delete funktonerne, men det kan vi faktisk allerede idag, så ingen WOOT til ham der. Men autokonfigurering mellem 2 tilfældige komponenter vil aldrig ske.
Not gonna happen.
Noget af det kan jeg dog følge:
Ingen diske.
Bisværm af test (tildels, men ikke så lang ude som beskrevet).
Masser af genbrug.
Skalering som en leg.
Alt det autokonfigurering han snakker om tror jeg ikke på. Du vil aldrig kunne trække et "user" objekt ind i koden også forbinder den automatisk med databasens "bruger" tabel. Jo, hvis du giver den forbindelsen, kan den selv analysere strukturen og lave insert/update/delete funktonerne, men det kan vi faktisk allerede idag, så ingen WOOT til ham der. Men autokonfigurering mellem 2 tilfældige komponenter vil aldrig ske.
Jeg tror, han forsøger at være langt, langt foran end, hvad man kan nå på 25 år - lidt så vi ikke føler os snydt for den første warp-engine (blev vist "udviklet" i det 21. århundrede i Star Trek-verdenen?) eller for en rumrejse langt ude i stjernerne!
Han baserer jo ikke sine idéer på, hvad man har opnået med eksisterende værker, de er jo fra hans fantasi. Til gengæld kan de interessante pegepinde for, hvad sprogudviklerne bør kigge nærmere på i denne tid og fremover.
Han baserer jo ikke sine idéer på, hvad man har opnået med eksisterende værker, de er jo fra hans fantasi. Til gengæld kan de interessante pegepinde for, hvad sprogudviklerne bør kigge nærmere på i denne tid og fremover.
Ser dette lidt som ønske tænkning og intet andet.
godt nok udvikler vi alt inde for hardware og software
mere eller mindre konstant.
Men mange mennesker mente også før hen at
robotten med A.I. Artificial Intelligence ville være fremme
omkring nu. og det tætteste vi er på det er STAIR
(STanford AI Robot) Som kan finde og hente ting til dig
i kontoret/hjemmet. Det er en Nice maskine man langt fra
det færdige koncept "humanoid"
A.I. Artificial Intelligence ville blive en vigtig del
af hans programør fremtid. og om den er der til den tid tvivler
jeg meget på. og nogen forsøgr med deres "Self evolving robots"
Der skulle opleve livet som et menneske. lære gennem barndommen. opdrages som et menneske.. men forsøgne inde for det er langt fra nogen færdige opdagelse eller forsøg. selv om "den" laver hver ting anderledes for hver gang. nogen mener den tænker mens opfinderen af denne ide siger at det er umuligt da en maskine kun kan tænke ud fra og klare opgaven mest optimal, og derfor er det rent matematisk udregninger og ikke den
A.I. folk havde håbet på.
Inde for alt det kan jeg så virkelig ikke se at det kan blive en virkelighed. selv om iden er ret så fedt tænkt :P
godt nok udvikler vi alt inde for hardware og software
mere eller mindre konstant.
Men mange mennesker mente også før hen at
robotten med A.I. Artificial Intelligence ville være fremme
omkring nu. og det tætteste vi er på det er STAIR
(STanford AI Robot) Som kan finde og hente ting til dig
i kontoret/hjemmet. Det er en Nice maskine man langt fra
det færdige koncept "humanoid"
A.I. Artificial Intelligence ville blive en vigtig del
af hans programør fremtid. og om den er der til den tid tvivler
jeg meget på. og nogen forsøgr med deres "Self evolving robots"
Der skulle opleve livet som et menneske. lære gennem barndommen. opdrages som et menneske.. men forsøgne inde for det er langt fra nogen færdige opdagelse eller forsøg. selv om "den" laver hver ting anderledes for hver gang. nogen mener den tænker mens opfinderen af denne ide siger at det er umuligt da en maskine kun kan tænke ud fra og klare opgaven mest optimal, og derfor er det rent matematisk udregninger og ikke den
A.I. folk havde håbet på.
Inde for alt det kan jeg så virkelig ikke se at det kan blive en virkelighed. selv om iden er ret så fedt tænkt :P
Sprogudviklingen peger ret meget i en anden retning end den dynamiske, som han nævner. Der sker en masse interessant inden for C# verdenen og inden for Scala verdenen, som begge er statisk tjekkede sprog.photonatic (4) skrev:Han baserer jo ikke sine idéer på, hvad man har opnået med eksisterende værker, de er jo fra hans fantasi. Til gengæld kan de interessante pegepinde for, hvad sprogudviklerne bør kigge nærmere på i denne tid og fremover.
Python er så godt som det samme sprog som da det blev lavet for snart 20 år siden. Der har ikke fra et sprog-synspunkt været noget interessant at komme efter i det siden. Det samme kan stort set siges om de andre såkaldt dynamiske sprog. De er forholdsvis langsomme, har ringe eller (som i Python og JavaScript verdenen) ingen muligheder for parallellitet, og bærer præg af at være hacket hurtigt sammen.
Det er korrekt at de dynamiske sprog har opnået en større udbredelse de senere år, men det er ikke resultat af nogen nævneværdi udvikling.
Jeg sætter 100 kroner på, at vi har løst problemet i "Infinite monkey theorem" og derfor kun har ansat aber (og/eller indere).
#6 at Python ingen mulighed har for parallelitet skyldes implementationen og ikke andet; IronPython, fx, har fint mulighed for disse ting, og det samme får PyPy og (må man da håbe) Unladden Swallow. Man kan vist ikke mene det seriøst med et sprog i vore dage hvis det ikke kan eller snart kommer til at kunne arbejde effektivt parallelt.
OT, der er vist nogle grundlæggende algoritmiske problemer med et par af de mere romantiske forestillinger i den forudsigelse :)
OT, der er vist nogle grundlæggende algoritmiske problemer med et par af de mere romantiske forestillinger i den forudsigelse :)
mathiass (6) skrev:Sprogudviklingen peger ret meget i en anden retning end den dynamiske, som han nævner. Der sker en masse interessant inden for C# verdenen og inden for Scala verdenen, som begge er statisk tjekkede sprog.
Men er det ikke, fordi vi ser funktionel programmering som den hidtil bedste løsning til problemerne ifm. parallellitetsproblemerne (bl.a. at variable er immutable) og ikke nødvendigvis et udtryk for, at det er, hvad vi ønsker at opnå i fremtiden? Ifm. statisk typechecking er det for nogen trælst, at man skal skrive LinkedList<WhateverObject> ll = new LinkedList<WhateverObject>() bare for at type-checkeren kan verificere, om referencen matcher det man instantierer.
Men jeg erkender at nuværende dynamiske sprog er forholdsvis langsomme. Så måske ønsker vi et sprog, hvor man ikke behøver at angive typen, samtidig med at compileren er i stand til at foretage disse checks i compile-time og ikke run-time, og at de ikke skal fortolkes run-time... Men hvad ved jeg. ^_^
Fremtiden udvikler sig generelt mindre fantastisk end man forestiller sig. Jeg har Illustreret Videnskabs blade fra 80erne, som også i en rus forestiller sig at fremtiden om 25-30 år er helt vild. Bl.a. skulle kræft være totalt kureret, en blod prøve kan afsløre alt, flyvende biler osv.
Men de nævner intet om internettet f.eks. Den ide findes slet ikke nogen steder.
Så der vil ske en vild udvikling, men der er jokere vi slet ikke har fantasi til at forestille os nu, i det der oftes er ekstrapolering fra 2 punkter: Hvor vi var for 25 år siden, hvor vi er nu.
Computere bygger fundamentalt på den samme logik og arkitektur som de har gjort i .. omkring 70 år. Jeg tror ikke at de næste 25 vil ændre paradigmerne ret meget, i det der ikke er nogen økonomisk gevist ved at miste millarder af kode linjer som ikke længere kan bruges. Jeg kan ikke se den eksplosive udvikling inden for programmering ske, fordi de fleste principper som nu er "moderne" allerede var opfundet i Proof of Concept i 60erne og 70erne, det var bare ikke praktisk på det tidspunkt ikke at maskin compile alt kode.
Så - hans ide er altså at i fremtiden bruger man ikke "libs" men "smart objects" som kan autoconfigurere sig.. Det lyder som en halv fesen videreudvikling af web APIs som Amazon S3 osv. Det er der da ikke meget nyt eller revolutionært i. Desuden er der løsninger der "automatisk" kan compile parallel kode - dog kræver det at funktionen der skal paralleliseres skrives til det (blocks, grand central dispatch o.l.)
Men de nævner intet om internettet f.eks. Den ide findes slet ikke nogen steder.
Så der vil ske en vild udvikling, men der er jokere vi slet ikke har fantasi til at forestille os nu, i det der oftes er ekstrapolering fra 2 punkter: Hvor vi var for 25 år siden, hvor vi er nu.
Computere bygger fundamentalt på den samme logik og arkitektur som de har gjort i .. omkring 70 år. Jeg tror ikke at de næste 25 vil ændre paradigmerne ret meget, i det der ikke er nogen økonomisk gevist ved at miste millarder af kode linjer som ikke længere kan bruges. Jeg kan ikke se den eksplosive udvikling inden for programmering ske, fordi de fleste principper som nu er "moderne" allerede var opfundet i Proof of Concept i 60erne og 70erne, det var bare ikke praktisk på det tidspunkt ikke at maskin compile alt kode.
Så - hans ide er altså at i fremtiden bruger man ikke "libs" men "smart objects" som kan autoconfigurere sig.. Det lyder som en halv fesen videreudvikling af web APIs som Amazon S3 osv. Det er der da ikke meget nyt eller revolutionært i. Desuden er der løsninger der "automatisk" kan compile parallel kode - dog kræver det at funktionen der skal paralleliseres skrives til det (blocks, grand central dispatch o.l.)
decx (11) skrev:Desuden er der løsninger der "automatisk" kan compile parallel kode - dog kræver det at funktionen der skal paralleliseres skrives til det (blocks, grand central dispatch o.l.)
Af ren nysgerrighed ved du om compileren selv kan definere granularity / finhedsgraden i denne automatisering, altså om den er i stand til at dele en løkke der skal itereres 1.000.000 gange op i antallet af kerne? <--- Det forudsætter selvfølgelig, at der ikke er nogen afhængigheder.
fennec (2) skrev:Alt det autokonfigurering han snakker om tror jeg ikke på. Du vil aldrig kunne trække et "user" objekt ind i koden også forbinder den automatisk med databasens "bruger" tabel. Jo, hvis du giver den forbindelsen, kan den selv analysere strukturen og lave insert/update/delete funktonerne, men det kan vi faktisk allerede idag, så ingen WOOT til ham der. Men autokonfigurering mellem 2 tilfældige komponenter vil aldrig ske.
Det er fordi du tænker det indenfor det nuværende 'lokale' paradigme hvor du selv har siddet og fiflet med at lave en "bruger"-tabel, og givet den en semantik og opbygning som kun du kender. Det han mener er formentlig at mere eller mindre alt vil hentes ind fra nettet, og at komponenternes udformning vil være beskrevet i et universelt format så de automatisk kan mixes og matches.
F.eks. kunne newz.dk udbyde en "newzbruger"-komponent, som indeholdt en beskrivelse af at et "newzbruger"-objekt har egenskaber som navn, fødselsdato, land osv. Hvis man smed "newzbruger"-komponenten sammen med en database-komponent ville sidstnævnte automatisk kunne oprette tabeller og lign. for "newzbruger"-objekter da deres struktur ville fremgå af beskrivelsen.
http://www.artima.com/weblogs/viewpost.jsp?thread=284730 skrev:The future object incorporates the concept of "component" and will be the basic unit of code. It manages its own processes and comes with its own swarm of tests. The interface between components and other components (thus, components and systems) becomes universal. Adding a new component to a system becomes as easy as adding ingredients to a recipe. Component discovery will have its own search engine.
#0
Hvis vi nu antager at 2010->2035 kan approksimeres ved 1985->2010, så kan man drage nogle konklusioner.
1985 : de store sprog er Cobol, Pascal, C, Fortran
2010 : de store sprog er Java, C#, PHP, C++
Der er sket et paradigmeskift fra procedural programmering til objekt orienteret programmering. Førstevalgene af sprog til nye applikationer er totalt udskiftet, men de store sprog fra 1985 bruges stadig i stort omfang, fordi masser af apps fra 1985 stadig bruges.
Det lyder derfor rimeligt at vi i 2035:
- vil have en ny type af programmerings sprog
- vil have nye programmerings sprog af den type
- vil have brug for at understøtte både 1985 og 2010 sprogene af hensyn til eksisterende kode
1985 : data gemmes i index-sekventielle filer eller binære flade filer
2010 : data gemmes i relations databaser eller XML flade filer
1985 : multiple processes
2010 : multiple threads
Der er igen sket et skift i teknologi. Men der er ikke sket noget paradigme skift.
Det lyder derfor rimeligt at vi i 2035:
- vil have nye teknologier
- grundliggende vil tænke på data og på udførsel ligesom i 2010 og 1985
1985 : app skrives som kode i tekst filer
2010 : app skrives som kode i tekst filer
Igen ændringer overhovedet. Set i det store perspektiv er der ingen forskel på en tekst editor for 25 år siden på VT200 og VS2010.
Det lyder derfor rimeligt at vi i 2035:
- stadig vil skrive kode ligesom vi altid har gjordt
Hvis vi nu antager at 2010->2035 kan approksimeres ved 1985->2010, så kan man drage nogle konklusioner.
1985 : de store sprog er Cobol, Pascal, C, Fortran
2010 : de store sprog er Java, C#, PHP, C++
Der er sket et paradigmeskift fra procedural programmering til objekt orienteret programmering. Førstevalgene af sprog til nye applikationer er totalt udskiftet, men de store sprog fra 1985 bruges stadig i stort omfang, fordi masser af apps fra 1985 stadig bruges.
Det lyder derfor rimeligt at vi i 2035:
- vil have en ny type af programmerings sprog
- vil have nye programmerings sprog af den type
- vil have brug for at understøtte både 1985 og 2010 sprogene af hensyn til eksisterende kode
1985 : data gemmes i index-sekventielle filer eller binære flade filer
2010 : data gemmes i relations databaser eller XML flade filer
1985 : multiple processes
2010 : multiple threads
Der er igen sket et skift i teknologi. Men der er ikke sket noget paradigme skift.
Det lyder derfor rimeligt at vi i 2035:
- vil have nye teknologier
- grundliggende vil tænke på data og på udførsel ligesom i 2010 og 1985
1985 : app skrives som kode i tekst filer
2010 : app skrives som kode i tekst filer
Igen ændringer overhovedet. Set i det store perspektiv er der ingen forskel på en tekst editor for 25 år siden på VT200 og VS2010.
Det lyder derfor rimeligt at vi i 2035:
- stadig vil skrive kode ligesom vi altid har gjordt
#0 & #15
Grundliggende mener jeg at Bruce Eckel kommer med en masse BS.
Der er ingen tvivl om at massivt multi-core CPU'er og skyen vil være fundamental teknologi i 2035.
Men der er ikke noget reelt grundlag for at tro, at det bliver nemt at lave software i fremtiden. Erfaringerne fra de sidste 25 år siger at kravene til hvad softwaren skal kunne stiger hurtigere end udviklingen i tools. Vi bruger faktisk flere penge på software udvikling idag end for 25 år siden.
Og der er uhyggeligt lidt forskel på at skrive Fortran og VAX Assembler i en VT200 tekst editor og skrive Java kode i Eclipse (side note til windcape: eller C# i VS).
Tilbage i 1985 snakkede man faktisk meget om 4GL og CASE tools som skulle overtage det hårde arbejde i programmering. Og som bekendt skete det ikke.
Det sker heller ikke til 2035.
Grundliggende mener jeg at Bruce Eckel kommer med en masse BS.
Der er ingen tvivl om at massivt multi-core CPU'er og skyen vil være fundamental teknologi i 2035.
Men der er ikke noget reelt grundlag for at tro, at det bliver nemt at lave software i fremtiden. Erfaringerne fra de sidste 25 år siger at kravene til hvad softwaren skal kunne stiger hurtigere end udviklingen i tools. Vi bruger faktisk flere penge på software udvikling idag end for 25 år siden.
Og der er uhyggeligt lidt forskel på at skrive Fortran og VAX Assembler i en VT200 tekst editor og skrive Java kode i Eclipse (side note til windcape: eller C# i VS).
Tilbage i 1985 snakkede man faktisk meget om 4GL og CASE tools som skulle overtage det hårde arbejde i programmering. Og som bekendt skete det ikke.
Det sker heller ikke til 2035.
Anders Feder (13) skrev:Det er fordi du tænker det indenfor det nuværende 'lokale' paradigme hvor du selv har siddet og fiflet med at lave en "bruger"-tabel, og givet den en semantik og opbygning som kun du kender. Det han mener er formentlig at mere eller mindre alt vil hentes ind fra nettet, og at komponenternes udformning vil være beskrevet i et universelt format så de automatisk kan mixes og matches.
F.eks. kunne newz.dk udbyde en "newzbruger"-komponent, som indeholdt en beskrivelse af at et "newzbruger"-objekt har egenskaber som navn, fødselsdato, land osv. Hvis man smed "newzbruger"-komponenten sammen med en database-komponent ville sidstnævnte automatisk kunne oprette tabeller og lign. for "newzbruger"-objekter da deres struktur ville fremgå af beskrivelsen.
At kunne genbruge kode lavet andet sted eller andet tidspunkt er ikke noget nyt.
Det bruger man idag. Man brugte det i 1985. Og man var nok så småt startet på det allerede i 1960.
Det er en god ting, men det gør ikke programmering nemt.
Fundamentalt hænger det nok sammen med at det svære i programmering er at bestemme hvordan noget skal fungere ikke at taste koden ind.
Man bruger en maaned på at bestemme sig for hvordan en newzkomponent skal fungere - og så bruger man 8 timer på at taste koden ind eller 8 timer på at evaluere eksisterende løsninger og vælge den bedste.
#12
Det gøres ikke ved compile time, men i runtime. Du definerer din kode i en "block", compileren compiler det til maskinkode, men du skal stadigt bruge en process i kernel mode der kan sende disse blocks til ledige kerner/threads. Fordelen er selvfølgelig at du ikke selv skal lave kode til at finde ud af hvor mange frie kerner der er, men bare ved at "dispatcheren" altid vil sende dine blocks til en eller flere ledige kerner.
Det gøres ikke ved compile time, men i runtime. Du definerer din kode i en "block", compileren compiler det til maskinkode, men du skal stadigt bruge en process i kernel mode der kan sende disse blocks til ledige kerner/threads. Fordelen er selvfølgelig at du ikke selv skal lave kode til at finde ud af hvor mange frie kerner der er, men bare ved at "dispatcheren" altid vil sende dine blocks til en eller flere ledige kerner.
Du mener altså at det ikke er blevet nemmere at debugge software de sidste 25 år ? ;-)arne_v (16) skrev:Og der er uhyggeligt lidt forskel på at skrive Fortran og VAX Assembler i en VT200 tekst editor og skrive Java kode i Eclipse (side note til windcape: eller C# i VS).
Derudover er det vel nemmere at kode parrallet med bedre sprog og værktøjer. Jeg er ret sikker på at det er nemmere at lave parallelle operationer i f.eks. C# 4 end det er i Java eller C++.
At der er uhyggelig lille forskel på at rent faktisk taste koden ind er vel ligegyldigt. (udover alt den tid vi sparer med check på koden før vi trykker compile! Og forbedret værktøjer til dokumentation :p).
Og i dag snakker vi om at der intet er galt med multi-paradigme platforme, og at tage det bedste fra alle verdener til en samlet platform. (Java's fokus på at undgå multi paradigmer har været et stort tilbageskridt)arne_v (16) skrev:Tilbage i 1985 snakkede man faktisk meget om 4GL og CASE tools som skulle overtage det hårde arbejde i programmering. Og som bekendt skete det ikke.
Frameworks har vel i princippet overtaget det hårde arbejde i programmering i forhold til i 1985. Og programmeringssprogene hjælper med på mange punker (f.eks. med exceptions).
Så jeg vil da absolut mene at vi i dag kan fokusere mere på kerne delene (algoritmer, arkitektur, god-kode etc.) end vi kunne i 1985.
Derudover så er ting som IoC containers, og dependency injection noget mere udbredt i dag end det var i 1985. Jeg kan slet ikke forestille mig en IoC container til COBOL !
Man bruger også stadigvæk en hammer til at bygge et hus med, men det betyder jo ikke at menneskeheden ikke er blevet bedre til at bygge huse de sidste 2000 år!
Programmering 2035:
Vi vil bekymre os mindre om en lang række punkter i programmering, da compilerene vil være bedre og hardwaren hurtigere, så vi kan overlade en stor del af operationerne til compileren, som også vil optimere en del af koden.
I dette er blandt andet parallelle operationer, type-check (mere dynamisk typing og/eller duck-typing som C#s "var").
Vi vil også bekymre os mindre omkring hvad der er disk og memory, som BE også siger. Med en SSD disks er der god sandsynlighed for at vi kan optimere og forbedre vores programmer til at udnytte disse bedre.
Og det er ihvertfald ting som er temmelig langt fra 1985.
Vi vil bekymre os mindre om en lang række punkter i programmering, da compilerene vil være bedre og hardwaren hurtigere, så vi kan overlade en stor del af operationerne til compileren, som også vil optimere en del af koden.
I dette er blandt andet parallelle operationer, type-check (mere dynamisk typing og/eller duck-typing som C#s "var").
Vi vil også bekymre os mindre omkring hvad der er disk og memory, som BE også siger. Med en SSD disks er der god sandsynlighed for at vi kan optimere og forbedre vores programmer til at udnytte disse bedre.
Og det er ihvertfald ting som er temmelig langt fra 1985.
Windcape (19) skrev:Du mener altså at det ikke er blevet nemmere at debugge software de sidste 25 år ? ;-)
Nej. Stort set ikke.
Du vælger mellem debugger eller log filer. Debugger er super til undervisning. Log filer er bedst i den virkelige verden. Der er ikke den store forskel på debuggeren. Dengang skrev man s for single step, go for at køre til næste breakpoint og e noget for at evaluere en variabel. Idag bruger man nogle museklik til det samme. Men det er bare detaljer.
Windcape (19) skrev:Derudover er det vel nemmere at kode parrallet med bedre sprog og værktøjer. Jeg er ret sikker på at det er nemmere at lave parallelle operationer i f.eks. C# 4 end det er i Java eller C++.
Der er mig bekendt ingen specielle features i C# 4.0 til parallelitet.
.NET 4.0 kommer med et library til at udføre visse ting parallelt.
Den slags libraries kan laves i alle sprog.
Sammenlignet med f.eks. OpenMP er det uhyre primitivt.
Windcape (20) skrev:Og i dag snakker vi om at der intet er galt med multi-paradigme platforme, og at tage det bedste fra alle verdener til en samlet platform. (Java's fokus på at undgå multi paradigmer har været et stort tilbageskridt)
Historisk set dør can-do-everything programmerings-sprog meget hurtigere end mere fokuserede sprog.
PL/I og Ada95 er eksempler.
Der er ingen garanti for at C# ender på samme måde.
Men der er ihvertfald heller ingen garanti for at det ikke gør.
Ups ja, det er vist globalt for hele .NET frameworket. PLINQ :-)arne_v (24) skrev:Der er mig bekendt ingen specielle features i C# 4.0 til parallelitet.
Men det er jo netop ideen, at du skal have en simpel mulighed for at kører en række operationer parallelt, nemt og smertefrit.arne_v (24) skrev:Sammenlignet med f.eks. OpenMP er det uhyre primitivt.
Ja, men hvis man gør sproget fleksibelt nok til at kunne udvide det på library niveau, er det ikke så slemt.arne_v (26) skrev:Historisk set dør can-do-everything programmerings-sprog meget hurtigere end mere fokuserede sprog.
Mange af de ting jeg elsker ved C# findes f.eks. i Apache Commons til Java. Men det er langtfra så smertefrit at bruge fordi f.eks. Java ikke har extension methods (endnu).
Windcape (20) skrev:Frameworks har vel i princippet overtaget det hårde arbejde i programmering i forhold til i 1985.
Libraries er blevet større idag end de var dengang. Men det samme er opgaverne.
Jeg synes ikke at der er nogen speciel stor forskel.
Windcape (20) skrev:Så jeg vil da absolut mene at vi i dag kan fokusere mere på kerne delene (algoritmer, arkitektur, god-kode etc.) end vi kunne i 1985.
Software projekter bliver dyrere og dyrere. Og den gennemsnitlige kvalitet af kode bliver ringere og ringere.
Det er indrømmet meget drevet af opgaverne bliver større og der er blevet brug for flere udviklere henholdsvis.
Men jeg har noget svært ved at se de store fremskridt.
Windcape (20) skrev:Derudover så er ting som IoC containers, og dependency injection noget mere udbredt i dag end det var i 1985. Jeg kan slet ikke forestille mig en IoC container til COBOL !
IoC er et glimrende koncept. Men har det en målbar positiv effekt på software udvikling??
Ting vi gør anderledes i dag end for 25 år siden?
Objekt Orienteret Programmering: Det er vist svært at påstå at det ikke har ændret hvordan vi programmere.
Exceptions: Det er vist mere reglen end undtagelsen at sprog i dag har exceptions. Det har ændret hvordan vi håndtere fejl markant.
Det er måske også en af de ting som vil ændre sig mere markant når vi skal kode parallelt, hvor Erlangs tilgang til fejlhåndtering måske er mere attraktivt.
Memory håndtering: Med få undtagelser, så er memory håndtering gået i glemmebogen, og det er helt normalt at have en Garbage Collector til at rydde op efter en.
Objekt Orienteret Programmering: Det er vist svært at påstå at det ikke har ændret hvordan vi programmere.
Exceptions: Det er vist mere reglen end undtagelsen at sprog i dag har exceptions. Det har ændret hvordan vi håndtere fejl markant.
Det er måske også en af de ting som vil ændre sig mere markant når vi skal kode parallelt, hvor Erlangs tilgang til fejlhåndtering måske er mere attraktivt.
Memory håndtering: Med få undtagelser, så er memory håndtering gået i glemmebogen, og det er helt normalt at have en Garbage Collector til at rydde op efter en.
arne_v (17) skrev:At kunne genbruge kode lavet andet sted eller andet tidspunkt er ikke noget nyt.
Det er der heller ingen der har påstået. Det nye er at det gøres mere automatiseret. Og der er alt grund i verden til at tro at branchen vil flytte i den retning, ligesom den er flyttet fra f.eks. Fortran til C# og andre tidssvarende programmeringssprog. Eneste grund at tro at det ikke vil ske skulle være hvis man er meget stærkt investeret i status quo.
arne_v (17) skrev:Det er en god ting, men det gør ikke programmering nemt.
Falsk præmis: programmering er svært. Programmering er ikke svært - det er bare tidskrævende. Derfor vil det klart være en fordel hvis en større del af arbejdet kunne overlades til maskinen.
Men den gennemsnitlige Java/C# udvikler ville nok skrive endnu dårligere kode hvis man skulle kode Fortran eller C!arne_v (28) skrev:Software projekter bliver dyrere og dyrere. Og den gennemsnitlige kvalitet af kode bliver ringere og ringere.
Jeg synes ikke det er fair at give værktøjerne skylden for at folk ikke er godt nok uddannet eller ikke fokusere nok på at skrive god kode.
Netop god kode er vigtigt, så jeg er begyndt at anbefale Uncle Bob's Clean Code to folk der spørger om forslag til litteratur. Også fordi det netop er globalt for alle sprog, og derfor giver en bedre indsigt.
Hvis de ikke har nogen, hvorfor benytter vi det så?arne_v (28) skrev:IoC er et glimrende koncept. Men har det en målbar positiv effekt på software udvikling?
Der må være et kick et eller andet sted. Men uden erfaring fra entreprise løsninger hvor det benyttes, kan jeg ikke sige om der er målbare effekter.
Personligt synes jeg bare det giver renere kode, mindre side-effekter, og nemmere fejlhåndtering. Hvilket kan være et plus, afhængig af projekts kompleksitet.
Windcape (21) skrev:Vi vil bekymre os mindre om en lang række punkter i programmering, da compilerene vil være bedre og hardwaren hurtigere, så vi kan overlade en stor del af operationerne til compileren, som også vil optimere en del af koden.
HW bliver hurtigere. Ingen tvivl om det.
Windcape (21) skrev:I dette er blandt andet parallelle operationer, type-check (mere dynamisk typing og/eller duck-typing som C#s "var").
Nej.
dynamic er duck typing
var er type inferens
Windcape (21) skrev:
Vi vil også bekymre os mindre omkring hvad der er disk og memory, som BE også siger. Med en SSD disks er der god sandsynlighed for at vi kan optimere og forbedre vores programmer til at udnytte disse bedre.
Og det er ihvertfald ting som er temmelig langt fra 1985.
Hm.
Ideen med ens adressering af memory og disk er fra 1964 og har været meget brugt siden 1978 (System/38, OS/400, i5/OS).
Windcape (23) skrev:Jeg vil så tillade mig at være meget uenig i at det bare er detaljer.
Windcape (23) skrev:Alting kan jo være detaljer eller småting, men det er de små ting som forbedre hele processen i sidste ende.
Nu er der ikke engang universel enighed om at GUI er CLI overlegent.
Windcape (23) skrev:(Plus at det giver utrolig rodet kode!)
Forhåbentligt påvirker debugger UI ikke kodens udseende.
Men ikke nået mainstream udvikling endnu? (Java/C#).arne_v (32) skrev:Ideen med ens adressering af memory og disk er fra 1964 og har været meget brugt siden 1978 (System/38, OS/400, i5/OS).
Eller bliver det i dag håndteret på et abstraktionsniveau som vi ikke har adgang til fra programmeringssprogene.
Tjah. VS2008/2010s debugger versus html/log output i PHP? Problemet med logging er at du ikke har adgang til at se alting medmindre du explit sørger for det.arne_v (33) skrev:Nu er der ikke engang universel enighed om at GUI er CLI overlegent.
Debuggers gør et enormt stykke arbejde for os.
Netop? Men Asserts/sysouts i koden gør!arne_v (33) skrev:Forhåbentligt påvirker debugger UI ikke kodens udseende.
ArgumentException "value is null" , happy ? :Dkr00z0r (34) skrev:Hvis bare man kan undgå at skulle håndtere NullPointerExceptions i 2035 er jeg glad.
Windcape (29) skrev:Objekt Orienteret Programmering: Det er vist svært at påstå at det ikke har ændret hvordan vi programmere.
Windcape (29) skrev:Exceptions: Det er vist mere reglen end undtagelsen at sprog i dag har exceptions. Det har ændret hvordan vi håndtere fejl markant.
Windcape (29) skrev:Memory håndtering: Med få undtagelser, så er memory håndtering gået i glemmebogen, og det er helt normalt at have en Garbage Collector til at rydde op efter en.
Alle 3 ting har haft en klar positiv effekt.
Men vi snakker måske -10%/-25%, -2%/-2% og -2%/-10% for de 3 (original/maintenance), hvilket skal sammenholdes med at opgaverne vokser 20-40% om året i kompleksitet.
Jeg benægter ikke at der er sket fremskridt, men jeg kan ikke se fremskridt i den BE'ske målestok.
Windcape (31) skrev:Men den gennemsnitlige Java/C# udvikler ville nok skrive endnu dårligere kode hvis man skulle kode Fortran eller C!
Formentligt. Ihvertfald for C. C tillader folk at skyde sig selv i foden. Fortran er faktisk ikke så nemt at lave gris i (og Pascal det samme - der er en grund til at Pascal i et par årtier var det foretrukne undervisningsprog).
Windcape (31) skrev:Jeg synes ikke det er fair at give værktøjerne skylden for at folk ikke er godt nok uddannet eller ikke fokusere nok på at skrive god kode.
Det er heller ikke værktøjernes skyld.
Min pointe er bare at forbedringerne i værktøjer ikke har været stor nok til at opveje de eksterne forhold.
kr00z0r (34) skrev:Hvis bare man kan undgå at skulle håndtere NullPointerExceptions i 2035 er jeg glad.
Lige netop den tror jeg at du slipper for.
Jeg gætter på at mange af de nye sprog ikke vil have null og at dem som harf vil have statisk analyse der kan finde problemerne.
Men bare rolig - der skal nok være andre problemer.
Windcape (35) skrev:Men ikke nået mainstream udvikling endnu? (Java/C#).
Eller bliver det i dag håndteret på et abstraktionsniveau som vi ikke har adgang til fra programmeringssprogene.
Jeg vil formode at Java på System i virker sammen med det.
Men jeg har ingen personlig erfaring.
Windcape (35) skrev:Tjah. VS2008/2010s debugger versus html/log output i PHP? Problemet med logging er at du ikke har adgang til at se alting medmindre du explit sørger for det.
Debuggers gør et enormt stykke arbejde for os.
Nu var min pointe nu mest omkring text debugger med kommandoer versus GUI debugger.
Debuggers er fremragende i undervisnings situationer, hvor man skal illustrere hvorfor bubble sort er implementeret forkert.
De kan også bruges i nogle tilfælde i den virkelige verden. Desktop apps vil ofte kunne debugges.
Men de er ret håbløse til at finde ondsindede problemer i multithreaded server apps. Debuggeren påvirker udførslen for meget. Og der er for meget data til manuel inspektion.
Jeg skulle mene at Microsoft har forsøgt at gøre det lidt nemmere at debugge concurrency problemer i VS2010. Så det er vel endnu et punkt hvor vi kan forbedre os de næste 25 år?mathiass (42) skrev:Jeg vil nu nærmere sig at debuggeren ikke er egnet til netop concurrency problemer
(Men jeg har ikke testet den feature endnu.)
mathiass (42) skrev:Jeg vil nu nærmere sig at debuggeren ikke er egnet til netop concurrency problemer end at jeg vil sige at den generelt kun er egnet til desktop apps. Jeg har debugget mange Java server apps i min tid...
Jo. Men mange måske de fleste grimme problemer involverer noget concurrency.
Anders Feder (30) skrev:Det er der heller ingen der har påstået. Det nye er at det gøres mere automatiseret. Og der er alt grund i verden til at tro at branchen vil flytte i den retning, ligesom den er flyttet fra f.eks. Fortran til C# og andre tidssvarende programmeringssprog. Eneste grund at tro at det ikke vil ske skulle være hvis man er meget stærkt investeret i status quo.
Den eneste grund til ikke at tro på det er at det ikke giver nogen logisk mening.
For at kunne lave en automatiseret søgning efter noget færdig kode skal du have en komplet beskrivelse af funktionaliteten.
Har man en komplet beskrivelse af funktionaliteten, så behøver man ikke søge efter noget kode. Beskrivelsen er nemlig koden. Så i.s.f. at søge efter en anden kode der har samme funktionalitet vil man bare fortolke eller compile den beskivelse som man har.
Anders Feder (30) skrev:Falsk præmis: programmering er svært. Programmering er ikke svært - det er bare tidskrævende. Derfor vil det klart være en fordel hvis en større del af arbejdet kunne overlades til maskinen.
Vi har 50 års erfaring med at softwareudvikling er svært.
Forbedrede udviklings processer og forbedrede tools har hjulpet lidt.
Forsøg på automatiseret software udvikling har fejlet konsekvent.
Det kan siges med næsten 100% sikkerhed at der ikke vil ske en revolution i software udvikling de næste 25 år som vil gøre det nemt at lave software.
#48 Hvad er formålet med at du udtaler dig om hvad andre ved og ikke ved noget om? Hvis folk havde lyttet hver gang du igennem tiden havde nedgjort en ny teknologi så ville vi jo alle sammen sidde ved monokrome CRT-monitors og indtaste data per hulkort FFS!
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund