mboost-dp1
Why we need even more programming languages
Når man læser sådan en overskrift kan man jo ikke lade være med at tænke på http://xkcd.com/927/
Det betyder dog ikke at man aldrig skal designe nye sprog, man skal bare have en meget god grund til det, og man skal have en klar plan for hvordan det integrerer med eksisterende systemer.
Hvis et nyt sprog kan erstatte 1-2 eksisterende sprog for en stor del af udviklerne, og det kan gøre livet lidt nemmere selv for dem der ender med at være tvunget til at bruge det nye sprog sammen med alle de sprog de i forvejen brugte, så var det en god idé at introducere det.
Hvis det nye sprog ikke kan overflødiggøre et eksisterende sprog for et nævneværdigt antal udviklere, og hvis det samtidigt er en lille ekstra byrde at supportere det i sammenhæng med alle de eksisterende sprog, så havde verden nok været bedre tjent med at det nye sprog ikke var blevet opfundet.
Vi har ikke brug for flere programmeringssprog, vi har brug for færre. Vejen til færre sprog kan godt være at introducere nye sprog der erstatter nogle af de gamle. Men uanset hensigterne er der altid en betydelig risiko for at et nyt sprog ikke er i stand til at overflødiggøre nogen af de eksisterende sprog.
Det betyder dog ikke at man aldrig skal designe nye sprog, man skal bare have en meget god grund til det, og man skal have en klar plan for hvordan det integrerer med eksisterende systemer.
Hvis et nyt sprog kan erstatte 1-2 eksisterende sprog for en stor del af udviklerne, og det kan gøre livet lidt nemmere selv for dem der ender med at være tvunget til at bruge det nye sprog sammen med alle de sprog de i forvejen brugte, så var det en god idé at introducere det.
Hvis det nye sprog ikke kan overflødiggøre et eksisterende sprog for et nævneværdigt antal udviklere, og hvis det samtidigt er en lille ekstra byrde at supportere det i sammenhæng med alle de eksisterende sprog, så havde verden nok været bedre tjent med at det nye sprog ikke var blevet opfundet.
Vi har ikke brug for flere programmeringssprog, vi har brug for færre. Vejen til færre sprog kan godt være at introducere nye sprog der erstatter nogle af de gamle. Men uanset hensigterne er der altid en betydelig risiko for at et nyt sprog ikke er i stand til at overflødiggøre nogen af de eksisterende sprog.
#2
Men hvis der er færre sprog, så vil udviklingen (af dem) jo gå endnu langsommere.
Men hvis der er færre sprog, så vil udviklingen (af dem) jo gå endnu langsommere.
#2
Nu tror jeg absolut ikke på ideen med sproget der kan det hele.
Forskellige sprog til forskellige formål giver fint mening for mig.
Og deraf følger at hvis antallet af applikations typer vokser, så er der også behov for flere sprog.
Men et nyt sprog bør enten være så markant bedre end et eksisterende sprog til et formål at det kan erstatte eller være beregnet til et nyt formål.
Nu tror jeg absolut ikke på ideen med sproget der kan det hele.
Forskellige sprog til forskellige formål giver fint mening for mig.
Og deraf følger at hvis antallet af applikations typer vokser, så er der også behov for flere sprog.
Men et nyt sprog bør enten være så markant bedre end et eksisterende sprog til et formål at det kan erstatte eller være beregnet til et nyt formål.
Jeg har en del sprog i min mentale toolbox:
C: til udvikling på linux, og embedded
c++: Når jeg kan bruge det istedet for C, og performance er critical
Java: Til enterprise udvikling, eller hvis multiplatform understøttelse er et must.
c#: Når det skal køre på windows, og det skal være hurtigt at lave.
Oveni det kommer så alle de små "sprog" html, javascript,sql,xpath etc. som der ofte bliver involveret i alle de større sprog.
Jeg ville ikke undvære et eneste sprog....de er alle rigtigt gode til det jeg bruger dem til, og jeg tænker ikke over hvilket jeg arbejder i.
C: til udvikling på linux, og embedded
c++: Når jeg kan bruge det istedet for C, og performance er critical
Java: Til enterprise udvikling, eller hvis multiplatform understøttelse er et must.
c#: Når det skal køre på windows, og det skal være hurtigt at lave.
Oveni det kommer så alle de små "sprog" html, javascript,sql,xpath etc. som der ofte bliver involveret i alle de større sprog.
Jeg ville ikke undvære et eneste sprog....de er alle rigtigt gode til det jeg bruger dem til, og jeg tænker ikke over hvilket jeg arbejder i.
#7
Nej, jeg tænker ikke jeg har fravalgt noget, hvis at jeg opdager jeg får en opgave hvor et af de sprog vil være bedst vil jeg lære det.
Jeg kan også VB, men vil aldrigt vælge det når jeg har c#.
Jeg har brugt delphi(pascal), men gik over til c++.
Jeg vil altid vælge asp.net over PHP.
Jeg fokuserer ikke så meget på mine præferencer, men mere på hvad der er det bedste værktøj til den opgave jeg har.
Jeg ville ønske at jeg fik en opgave hvor det gav mening at lære Lisp, Python eller Ruby.
Nej, jeg tænker ikke jeg har fravalgt noget, hvis at jeg opdager jeg får en opgave hvor et af de sprog vil være bedst vil jeg lære det.
Jeg kan også VB, men vil aldrigt vælge det når jeg har c#.
Jeg har brugt delphi(pascal), men gik over til c++.
Jeg vil altid vælge asp.net over PHP.
Jeg fokuserer ikke så meget på mine præferencer, men mere på hvad der er det bedste værktøj til den opgave jeg har.
Jeg ville ønske at jeg fik en opgave hvor det gav mening at lære Lisp, Python eller Ruby.
Hvorfor skulle det dog det? Hvis du har et givet antal udviklere som er i stand til at udvikle programmeringssprog, så kan de i fællesskab udvikle et sprog hurtigere end de hver især ville være i stand til hvis de fik hvert deres sprog at udvikle på.pewbe (3) skrev:Men hvis der er færre sprog, så vil udviklingen (af dem) jo gå endnu langsommere.
Selvfølgelig, men i øjeblikket er der formål hvor der findes 100 forskellige sprog til det samme formål. De tilfælde hvor der kun findes et enkelt sprog til et givet formål skyldes krav om kompatibilitet, der besværliggør introduktionen af et nyt sprog. I de tilfælde er det ene sprog der er lavet til formålet som regel ikke særligt godt.arne_v (5) skrev:Forskellige sprog til forskellige formål giver fint mening for mig.
kasperd (9) skrev:Hvorfor skulle det dog det? Hvis du har et givet antal udviklere som er i stand til at udvikle programmeringssprog, så kan de i fællesskab udvikle et sprog hurtigere end de hver især ville være i stand til hvis de fik hvert deres sprog at udvikle på.
Jeg mente at udviklingen af de eksisterende sprog vil gå langsommere, hvis der er færre af dem.
kasperd (9) skrev:Hvorfor skulle det dog det? Hvis du har et givet antal udviklere som er i stand til at udvikle programmeringssprog, så kan de i fællesskab udvikle et sprog hurtigere end de hver især ville være i stand til hvis de fik hvert deres sprog at udvikle på.
Den holder vist ikke.
Det er vist almindeligt accepteret at konkurrence fremmer udviklingen mens manglende konkurrnce hæmmer udviklingen.
Rent teknisk hænger det sammen med at der er mange mange flere udviklere som har kompetancer til at udvikle sprog og kompilere end der faktisk arbejder med dem idag. Så indsatsen på området er bestemt af interesse for (efterspørgsel efter) sprog og compilere ikke efter udbuddet af udviklere.
Noget som jeg ikke synes forfatteren kom specielt meget ind på er, at hvis man først har bygget et fundament som alle så bygger ovenpå, så er det ekstremt besværligt at ændre på fundamentet uden et eller andet går i stykker. Personligt tror jeg at det er den største udfordring; at der simpelthen er bygget for meget, baseret på fundamenterne.
Derfor giver det bedre idé at udvikle et helt nyt fundament så vi kan få alle de kældre og ledninger vi vil have, fremfor at tage en masse krumspring for at kunne ændre fundamentet. IPv4/v6 er et godt eksempel på hvordan man har startet på et nyt fundament, inspireret af det gamle, men trods alt på en ledig byggegrund.
Derfor giver det bedre idé at udvikle et helt nyt fundament så vi kan få alle de kældre og ledninger vi vil have, fremfor at tage en masse krumspring for at kunne ændre fundamentet. IPv4/v6 er et godt eksempel på hvordan man har startet på et nyt fundament, inspireret af det gamle, men trods alt på en ledig byggegrund.
Sjovt som C# aldrig nævnes i den slags artikler. Nye programmeringssprog er fine hvis man vil demonstere nye måder at gøre ting på, som kan forbedre sprogene.
Men der er ikke mange sprog, der har formået at opdatere sig selv med sådanne nye features.
C# er vel det sprog der er sprogmæssigt blevet mest udvidet de sidste 10 år.
Men der er ikke mange sprog, der har formået at opdatere sig selv med sådanne nye features.
C# er vel det sprog der er sprogmæssigt blevet mest udvidet de sidste 10 år.
Faktisk vil jeg kun argumentere for at bruge forskellige sprog, hvis der er grundlæggende forskel i deres runtime.arne_v (5) skrev:Forskellige sprog til forskellige formål giver fint mening for mig.
Dvs. managed versus native.
Jeg vil ikke argumentere for at mikse COBOL, PL/1, Ruby, Python, Java eller C#. Fordi sprogene generelt har samme virkemåde.
(Selvfølgelig kan man være begrænset af at platformen kun kan køre en bestemt slags programmer.)
Haskell?Alrekr (12) skrev:Noget som jeg ikke synes forfatteren kom specielt meget ind på er, at hvis man først har bygget et fundament som alle så bygger ovenpå, så er det ekstremt besværligt at ændre på fundamentet uden et eller andet går i stykker
Generelt giver monads dig ret gode muligheder for at udvide et sprog...
Eller tag et sprog som D. Det har ikke properties, men du kan implementere dem som en sprog-extension, uden at skulle skrive en ny compiler.
Det giver enorme fordele. Hvis jeg skulle skrive native kode, ville D helt klart være mit første valg. (At jeg så skal arbejde med C/C++ på mit nye arbejde, må jeg jo så finde mig i :p)
arne_v (7) skrev:Men du har jo også fravalgt nogle: Cobol, Fortran, Lisp, Pascal, PL/I, VB, PHP, Python, Ruby etc..
Mamad (moveax1ret) (8) skrev:Nej, jeg tænker ikke jeg har fravalgt noget, hvis at jeg opdager jeg får en opgave hvor et af de sprog vil være bedst vil jeg lære det.
Man får ikke opgaver i Cobol og lærer Cobol hvis man ikke allerede kan det.
Man får opgaver i Cobol og siger sit job op hvis man ikke allerede kan det.
Mamad (moveax1ret) (8) skrev:
Nej, jeg tænker ikke jeg har fravalgt noget, hvis at jeg opdager jeg får en opgave hvor et af de sprog vil være bedst vil jeg lære det.
Jeg kan også VB, men vil aldrigt vælge det når jeg har c#.
Jeg har brugt delphi(pascal), men gik over til c++.
Jeg vil altid vælge asp.net over PHP.
Jeg fokuserer ikke så meget på mine præferencer, men mere på hvad der er det bedste værktøj til den opgave jeg har.
Jeg ville ønske at jeg fik en opgave hvor det gav mening at lære Lisp, Python eller Ruby.
Så du har fravalgt VB.NET, Delphi og PHP men har ikke haft lejlighd til at prøve Lisp, Python og Ruby?
:-)
Windcape (13) skrev:C# er vel det sprog der er sprogmæssigt blevet mest udvidet de sidste 10 år.
Ja.
C# vil tydeligvis gerne op i PL/I, C++ eller Ada95 feature righeden.
Men flere features er ikke nødvendigvis bedre. Og de 3 forgængere i strategien har vel heller ikke formået at overtage fra deres simplere alternativer.
Windcape (14) skrev:Faktisk vil jeg kun argumentere for at bruge forskellige sprog, hvis der er grundlæggende forskel i deres runtime.
Dvs. managed versus native.
Jeg vil ikke argumentere for at mikse COBOL, PL/1, Ruby, Python, Java eller C#. Fordi sprogene generelt har samme virkemåde.
Jeg er helt uenig.
Det giver ingen mening at det samme sprog skulle være optimalt til at skrive newz.dk og skrive noget der styrer et fly.
Forskellige krav til omkostninger og korrekthed kan betyde at forskellige sprog er det optimale valg.
milandt (16) skrev:Man får opgaver i Cobol og siger sit job op hvis man ikke allerede kan det.
Cobol er et sprog ligesom alle andre.
Og med nogle ret unikke features.
Mange af disse features er ikke så vigtige som de har været, men du skal ikke afskrive Cobol's muligheder.
Jeg mener at der på et tidspunkt var en betydelig person i branchen, der udtalte, at et godt design er ikke et man opnår ved at tilføje features indtil man ikke kan finde på flere features at tilføje. Men et godt design derimod er et man opnår ved at fjerne features indtil der ikke er noget tilbage som kan undværes.arne_v (20) skrev:Men flere features er ikke nødvendigvis bedre.
Og det princip er i høj grade relevant for programmeringssprog. Hvis en feature kan skrives som en library funktion, så bør den ikke være en del af sproget. Den største ulempe ved at gøre så meget som muligt til library funktioner er at funktionskald ikke altid giver den pæneste syntaks.
Operator overloading kan hjælpe på syntaksen af funktionskald, men gør det desværre lidt for nemt at skrive ugennemskuelig kode.
Det får mig til at tænke på en konstruktion jeg engang for længe siden overvejede, men som jeg dog ikke ved om ville være en god idé.
Jeg overvejer om man i et sprog med en C lignende syntaks kunne give en anonym funktion som argument til en funktion med en syntaks i stil med:
funktionsnavn(argumenter) statement;
Hvis det var muligt ville selv if (og måske også for og while) kunne skrives som library funktioner.
kasperd (25) skrev:
Og det princip er i høj grade relevant for programmeringssprog. Hvis en feature kan skrives som en library funktion, så bør den ikke være en del af sproget. Den største ulempe ved at gøre så meget som muligt til library funktioner er at funktionskald ikke altid giver den pæneste syntaks.
Operator overloading kan hjælpe på syntaksen af funktionskald, men gør det desværre lidt for nemt at skrive ugennemskuelig kode.
Det får mig til at tænke på en konstruktion jeg engang for længe siden overvejede, men som jeg dog ikke ved om ville være en god idé.
Jeg overvejer om man i et sprog med en C lignende syntaks kunne give en anonym funktion som argument til en funktion med en syntaks i stil med:
funktionsnavn(argumenter) statement;
Hvis det var muligt ville selv if (og måske også for og while) kunne skrives som library funktioner.
Scala har muligheder lignende dette.
object Test extends App {
def mywhile(condition: => Boolean)(body: => Unit): Unit = while(condition) { body }
var i = 0;
mywhile(i < 10) {
println(i)
i = i + 1
}
}
(det er naturligvis ikke specielt interessant at definere mywhile udfra while, men det var lige det bedste eksempel jeg kunne komme på)
#26
Lidt mere interssant eksempel (hvor jeg dog også 98% af arbejdet er lavet af Scala:
Lidt mere interssant eksempel (hvor jeg dog også 98% af arbejdet er lavet af Scala:
object TestLoop extends App {
val mybreaks = new scala.util.control.Breaks
import mybreaks.{break, breakable}
def exitif(condition: => Boolean): Unit = if(condition) break
def loop(body: => Unit): Unit = {
breakable {
while(true) {
body
}
}
}
var i = 0;
loop {
println(i)
exitif(i > 3)
println(i)
i = i + 1
}
}
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
- ⟨
- Tagwall
Gå til bund