Programmeringsspråk som har allt? (programmeringsspråkdesign)

Vi är ett par miljoner människor. Det finns ett antal miljoner akademiker. Många av det duktiga på det där med logik, språk och syntaxer, formella system med mera. Många också duktiga på programmering.

Sedan tittar man på C. En pionjär på sin tid, visst. En kille stort sett och hans kollegor designar pragmatiskt språket. Det såg först ut som skit rent ut sagt innan det blir något som senare mer liknade den C vi känner igen idag.

C++ kom senare som systemprogrammeringsspråk, lade till abstraktioner, RAII, mer libs. Förbättrade en del utvecklar- och underhållsproblem.

Nu har vi Rust. Ingen direkt ersättare till C++ men den gör några saker marginellt bättre. Den gör en del saker väldigt rätt.

Sedan har vi utspritt diverse skitspråk, PHP, Ruby med mera. Vissa bra på sitt sätt men många av den rent av objektivt bajsigt designade.

Därtill har vi rätt okej språk (för sina användingsområden) Javascript, BASH, perl och andra skriptspråk.

Olika språk kan ha olika mål och syften. Men jag har sett att vissa språk gör allt vad andra språk gör men de gör det bättre på precis alla fronter. Jämför lolcode och brainfuck med valfritt språk exempelvis. Jämför C++17 med C89 eller Pascal. Jämför C/C++ med en bra kompilator och assembler i vanligt systemutvecklarsyfte.

Jämför C++17 med C i utvecklingen av nästan vad som helst.

Jag säger inte att alla språk passar precis överallt alltid jämfört med allting. Men som generella programmeringsspråk så är vissa språk helt enkelt bättre än andra i de allra flesta aspekter.

Garbage collection är till exempel fullständigt meningslöst med Rust design. Tanken är att Mozilla nu ska slippa alla problem med minnesläckor och overflows och det bland annat var därför de utvecklade Rust. Kostnade är noll, möjligheterna exakt samma som med C och C++. De har löst en del subtila buggar som C++s typsystem har. Det är helt enkelt bara bättre designat och har inte C++s historiska baguage. Rust är inte bättre än C++ på alla fronter men vissa delar av rust hade i C++ inte varit någonting annat än förbättringar.

Vissa språk gör allt fel och ligger efter i tiden.

Världen har lärt sig hur programmeringsspråk ska se ut och världen fortsätter att lära sig och förbättra programmeringsspråken.

En stark faktor är dock industrin och ekonomin, det påverkar programmeringsspråks spridning och utveckling.

Jag undrar vad man hade kunnat få fram om man tog all vår samlade kunskap och kreativitet och försökte designa ett riktigt bra programmeringsspråk (jag vet att folk försöker). Självklart spelar målen med språket roll också, alla saker passar inte i samma låda. Men bättre kan vi.

Vad hade man kunnat få fram, är det så omöjligt att sätta sig ner flera tusen forskare med statligt bidrag eller något och kissa ut något fullständigt gudomligt?

Låt oss prata om hur ett sådant språk skulle kunna se ut, vad andra språk har gjort fel/rätt och om det går att få ihop allt till ett gudalikt språk.

Tror inte riktigt det är görbart att få ihop ett språk som passar alla precis överallt, språken är ju olika på grund av att de har olika användningsområden, right?

Vissa språk är ju till exempel bättre lämpade för matematiska operationer än andra (typ MATLAB), andra är ju optimerade för parallell exekvering (Erlang), C har ju sin plats i hårdvarunära kodning etc.

Att således klumpa ihop alla dessa hade nog blivit rätt rörigt, de har ju liksom olika ingångsvärden så att säga. I och med att programmeringsspråken måste av sin natur vara begripliga för en dator på ett eller annat sätt, utan de tvetydigheter som mänskligt språk kan innehålla tror jag inte riktigt på ett universalspråk, borde inte ett sådant redan ha funnits om det vore möjligt?

Jag förstår hur du tänker, men jag tror inte det är möjligt eller önskvärt att skapa ett sådant språk.

Om du skulle få till ett nytt språk, går det troligen samma öde till möte som XKCD 927

Olika hårdvaror och processorer är inget problem längre, det löstes nästan minimalistiskt av C. Ett språk på högre nivå måste i sin jakt på att göra människan mer produktiv antingen offra prestanda (hastighet/minnesanvändning) eller bygga ovanpå C och då skapa fler kombinationer/speciallfall som kan bli fallgropar. Utmaningen är väl att erbjuda programmeraren lättförståeliga och/eller snabbskrivna konstruktioner, t.ex. automatiska variabler, objektorientering, rekursivitet och templates, och samtidigt se till att de krockar på ett förutsägbart sätt utan att offra för mycket prestanda i processen? För om man använder dem alla, och utnyttjar språket till fullo, kommer de att interagera med varandra.

Sen går alla världens features att emulera i C, så egentligen handlar det bara om enklare skrivbarhet och läsbarhet.


Kul tråd, här är mitt bidrag Puss.

Tcl gjorde ett försök att ha den simplaste syntaxen av alla normala språk, och det är lite bättre än Bash när man inte längre orkar hålla reda på alla tecken med särskild betydelse och på vilken nivå de har särskild betydelse. Men kanske framförallt inte bara i script-texten utan i datat man behandlar, då '0' inte avgränsar strängar i Tcl. NUL-terminering är Satans påhitt som genom att använda ett enda sketet tecken för att avgränsa resten, gör det omöjligt att lagra binär/fullständig data. Språk med NUL-terminering istället för längden i ett separat objekt, som man förstås kan lägga direkt före strängen om man vill, borde dö.

Ett Tcl-script består av noll eller fler kommandon separerade av radbrytning. Eller.. semikolon kan också separera kommandon och där gjorde skaparen John Ousterhout bort sig genom att introducera ett extra specialtecken. Men redan innan den här uppdelningen i kommandon sker, tolkas backslash följt av radbrytning och ersätts med ett mellanslag och där gjorde han bort sig igen. Att visa långa rader som flera borde vara texteditorns uppgift, inte språkets. Dessutom används backslash för att escape:a specialtecken i ett senare pass av texten, så det blir förvirrande.

Ett kommando består av ett kommandonamn följt av noll eller fler argument till det, alla separerade med whitespace (förutom radbrytning som som sagt separerar kommandon). För att bygga större uttryck utan att bry sig om var mellanresultaten tillfälligt lagras, använder man brackets som during runtime ersätts av kommandots returvärde.

Det viktigaste kommandot är "set", som tar ett eller två argument. Först variabelnamnet sen eventuellt ett värde att sätta det till, och det returnerar variablens värde (Efter att den eventuellt har blivit satt, för vad är postinkrement för underligt påhitt? Det hör väl inte hemma i en processor då det gör två operationer: returnerar det gamla värdet och lagrar det nya?)

Det här jävla forumhelvetet fixar inte Tcl-kod med alla sina brackets, så jag byter ut dem mot parenteser...


...läser hela filen vars öppnade ID finns i variabeln "stream", sätter variablen "length" till det värdet och skriver ut det.

Sen tröttnade nog folk på att använda "set" jämt, så $variabelnamn introducerades och senare arraynamn(index) där det stackars dollartecknet och parenteserna blev ytterligare specialtecken i vissa sammanhang. Och att kunna skriva kommandonamn eller -argument med mellanslag eller annan whitespace inuti, inklusive radbrytning, var såklart ett krav. Där dög inte ett enda escape-tecken som backslash trots att texteditorer skulle ha kunnat sköta "översättningen" för både skrivning och läsning, nejdå då introducerade man "" och {}. Dubbelfnuttarna kan ha substitutions inuti sig, alltså brackets eller dollartecknade variabelnamn. Måsvingarna kan man klistra in vad som helst mellan, förutom en stängande måsvinge förstås som måste escape:as med backslash, och en backslash som måste escape:a sig sälv.

En öppnande måsvinge har också betydelse för den skapar en ny nivå av måsar, som behövs för att kunna skriva kroppar i andra kroppar i t.ex. "if", "switch" eller "while", som liksom annat i Tcl är kommandon. While tar t.ex. två argument...


...och nästan alltid vill man ha mer kod än ett enda kommando som <script>. Då innesluter man det med måsvingar. Den enda fallgropen blir att man måste escape:a alla { och } inuti som inte är tänkta att påverka programmets struktur, eller iaf se till att antalet öppnande och stängda matchar, även om de är i en sträng mellan citationstecken eller i en kommentar. Måsvingar har högsta prioritet.

Kommentarer löste man genom att göra kommandonamnet "#" till ett som ignorerar sina argument. Men att skriva en kommentar efter ett kommando på samma rad är då inte möjligt, och det är antagligen en stark anledning att man plockade in semikolonet. Ska man kommentera efter ett kommando skriver man i Tcl `;# kommentaren` och kommer ihåg att alltid undvika måsvingar.

För att sammanfatta tror jag att fördelen med den här syntaxen inte handlar så mycket om att kunna undvika oalfabetiska tecken när man citerar binär data eller text, som bara är en liten del av ett program och som sagt kan lösas av texteditorer. Men att allt är ett kommando, även control statements (och kommentarer), kan utnyttjas på intressanta sätt då man kan ersätta vilket inbyggt kommando som helst med sin egendefinierade procedur, och i den anropa det riktiga kommandot med förändrade eller nya argument. Att kommandon kan ha ett valfritt binärdata-namn, så länge det inte krockar med ett annat i namespace:t, ger också möjligheter.

Det är väl det här som har gjort att Tcl är det långsammaste språket i alla kodtävlingar och benchmarks. "Everything is a string" är ett av språkets motton, vilket stämde helt i början men nu optimeras det internt. Det är iaf ett dåligt citat som bara skryter med att alla datatyper (och funktionstyper) kan översättas till andra via en sträng, och det skapar förvirring och dålig framtid eftersom man för att använda det måste veta hur t.ex. en hash eller lista är representerad internt. Och det ska man inte veta.

(Ursäkta att den här posten är jävligt dåligt skriven, jag är riktigt jävla bajsnödig och toan är upptagen och jag har redan tryckt på sänd)

Stämmer detta för C/C++/Java/Rust jämfört med föregångarna och alla "nyheter" som exception, objektoritenterat, RAII, borrowing, nya typsystem, de nya modulsystemen mm? Vissa saker delar stort sett alla språk och vissa saker delar de "bästa" språken. Ett exempel är variabler, det är typ bara haskell och liknande som inte har variabler.

Enums är ganska populära, de är rätt så bra att ha i C-liknande språk.

Jag förstår vad du menar, så jag sitter inte och säger rätt emot nu, du pratar om hela språk. Men jag menar att det finns individuella koncept som visar sig vara rätt så bra och att det finns programmeringsspråk som helt enkelt är bättre än andra. BASIC duger inte till någonting exempelvis, om man ska vara krass och ställa lite krav.

Gränsen mellan C++ och Java och C# kanske år hårfin, men de är en genre av programmeringsspråk skulle jag vilja säga.

Man kan ofta ta ett enskilt språk och göra det bättre. Ett exempel är t.ex. att droppa all bakåtkompatibilitet i C++ och rensa upp i språket. Marginell skillnad, men jag menar att man alltid kan få någonting bättre.

Se på hur språk utvecklas med tiden och ofta är ändringarna game-changers. Så jo, visst är det möjligt.

Tror inte riktigt det är görbart att få ihop ett språk som passar alla precis överallt, språken är ju olika på grund av att de har olika användningsområden, right?
Man ska aldrig säga aldrig. Men så är det nog, det är iallafall svårt. Men för general purpose programming så finns det ju saker som helt enkelt är bättre än andra koncept eller bättre än att inte ha dem alls.

Ett exempel är klasser. Visst kan man programmera utan dem, men det ser fördjävligt ut, särskilt när man har med pekare att göra. Om du har 1000 C-programmerare i ett projekt så är minnesläckorna och overflowen givna. 1000 rust-programmerare som inte får skriva in "unsafe mode" skulle inte kunna få minnesläckor eller overflows om deras liv så hängde på det och de försökte sitt allra yttersta (stort sett).

Headerfiler måste bort, de suger och de är skräp i en modern värld där de inte behövs längre. Det är ett exempel på en förbättring som gäller typ alla programmeringsspråk. Varför ska man hålla reda på funktionshuvuden på två olika ställen när de kan plockas ut ur källfilen? C++ jobbar på att standardisera moduler, något som Java, Rust och andra språk har.

Namespaces är ett exempel som bara tillför något gott till de flesta språk.

General purpose programming utan objekt (t.ex. egendefinierade typer, structs eller klasser) blir också väldigt dåligt, som i BASIC till exempel.

Variabler med namn är ju också ett påhitt, så var det inte förr.

När det gäller C# och Java som är så lika varandra så tror jag nog att man skulle kunna få sig en bättre hybrid.

C++ skulle kunna droppa vissa bakåtkompatibiliteter och göras säkrare och snabbare att utveckla i.

En fördel med att inte ha variabler är väl att det är lättare att bevisa ett programs beteende?

Hoppas det var skönt att skita.

Den enda fördelen med bash och andra skal som jag kan komma på är pipe:ing/redirects, och det kanske är en game changer som bör finnas i det ultimata språket? Tänk om man eliminerade UNIX problem med NUL- och radbrytningstecken i datat genom att istället separera det på ett sätt som var skiljt från själva data-record:sen, gjorde funktionerna (programmen) mindre och lät ett programs output kunna kopplas till fler andra programs input än ett. Då skulle det bli ett komplett dataflödesspråk. Jag är inte insatt i Microsofts PowerShell men de kanske har fixat en del detta? För den som inte programmerar bash, här är ett exempel:


ls listar innehållet i mappen, grep behåller bara de rader som innehåller "tuttar" (case insensitive) och mail skickar resultatet till mamma.

Ett kommando senare på kommandoraden väntar inte på att det förra ska bli helt klart, utan tar hand om datat allt eftersom och programmeraren behöver inte bry sig om när det händer. Det fungerar bra med parallella processorer, men bara om datat går att dela upp och behandla i separata delar (rader i det här fallet) annars blir datadriving "bara" syntaktiskt socker. Programmet mail kan t.ex. inte göra något förrän hela datat har kommit in, p.g.a. hur internet fungerar. Eller så har jag fel, det kanske kan börja skicka IP-paket redan innan det har hela kroppens text. Iaf så behöver nog synen på data förändras radikalt om parallella processorer ska bli effektivare...

...och jag tror ändå inte att det är värt det. Säg att man bygger det ultimata parallella nätverket av processorer (där varje processor kan ses som en multikapabel funktion) för att emulera en hjärnas synapser. Man kan bara packa dem på bredden, höjden och längden så vår tredimensionella värld begränsar varje processors kopplingar till sina grannar till 14 (rakt och diagonalt) eller vad siffran nu blir. 14 processorer kan jag nog hålla upptagna var för sig med olika program, och även om inte så är en 14-dubbling inte imponerande.

DF-språken har iaf ett lärorikt/teoretiskt intresse, då dess utgångspunkt är att ett program eller en del av det har till uppgift att processa sitt indata för att producera utdata. De procedurella språkens utgångspunkt är att ett program eller en del av det har till uppgift att utföra en sekvens av operationer i ordning. Två helt olika sätt att se på programmering.

Man kan skriva datadrivet i procedurella språk genom att t.ex. hålla funktionerna korta och undvika globala variabler. Men man kan ju skriva procedurellt i ett DF-språk mycket enklare genom att helt enkelt lägga funktionerna på en rad?

Korrekt! Vi kan mer eller mindre slänga iväg ett strukturellt induktionsbevis och bevisa hela program.

Hej! Har inte lusläst diskussionerna i denna tråd men kan nämna att Ada programmeringsspråket har också sin charm. Speciellt när man håller sig inom en delmängd av Ada dvs. inom SPARK 2014 så kan man köra statisk kodanalys genom formella metoder. Ett exempel på en annan person som upptäckt att Ada är helt OK att koda i skriver bland annat "I am thoroughly convinced that Ada is exactly what the world needs now, and for the future." i en artikel på reddit:
https://www.reddit.com/r/ada/comment...op&sh=994c6ffd

Bra motivering till existensen av verktyg som SPARK kan man hitta i denna artikel av Yannick Moy: http://www.spark-2014.org/entries/de...-error-contest
I artikeln beskriver Yannick om hur en brist i statisk kodanalysverktyget GNATProve lyckats hålla sig gömd länge och avslutar artikeln med "If we were able to miss one case, while we earn a living for focusing on such checking, no amount of attention and cleverness is going to make a developer catch all such cases in a real life application." Jag håller med honom.

Det mest optimala idag är C++ och Lua, de kombinationen är mycket svårslagen. Och jag tvivlar på att det kommer dyka upp något som klår det. Lua kan självklart ersättas med annat skriptspråk. Men det är få skriptspråk som fått spridning och är så tunna som Lua. Skall Lua ersättas är det nog bäst att bygga in något eget språk i sin C++ applikation, inte så svårt som det kanske låter

Alla språk som har en GC, de kommer aldrig kunna konkurrera med språk utan GC som kan hantera minne. Det förstår man när man lär sig hur en processor fungerar

Vad tycker ni i tråden om Haskell?

Jag är kär i det. Man tvingas att bli en bättre programmerare. Tyvärr så är det ett helt annat sätt att tänka för de flesta programmerare än de andra språken, att bortse från det nästan allt man lärt sig är inte lätt.

Någon nämnde reducering av syntax och gav TCL som ett exempel;

I Haskell hade detta kunnat skrivas t.ex.
Eller