Vad för Programmeringsspråk ska jag lära mig nu?

s="abc"
S = s.capitalize # skapar en ny sträng "ABC"
s.capitalize! # modifierar strängen som 's' refererar till

I min bok är mutable helt ok om det utnyttjas ansvarsfullt. Problemet i Rubys fall är att de strängar som skapas av literaler är muterbara; kodstycket

a = "abc"
b = a
a << "def"

resulterar i b == "abcdef" (referens: http://www.ruby-doc.org/core-1.9.3/String.html)

Hur kan jag förhindra att en strängreferens inte muteras okontrollerat i en annan del av koden?

So sue me!

C:\>debug
-e 109 'Hello DOS!',0d,0a,'$'
-rcx
CX 0000
:20
-n hello.com
-a
0C76:0100 mov ah,9
0C76:0102 mov dx,109
0C76:0105 int 21
0C76:0107 int 20
0C76:0109
-w
Skriver 00020 byte
-q

C:\>hello
Hello DOS!

 a += "def"

Jag kan förhindra det genom att använda en annan metod, men finns det något sätt att försäkra att strängen aldrig byter värde genom någon annans kod?

Att utgå ifrån en omutbar sträng och skapa en sträng-datatyp som är mutable är enkelt, men att göra det omvända verkar omöjligt eftersom basreferensen alltid kan muteras.

Du har (minst två) sätt utöver att undvika "mutuable" metoder

> a="abc".freeze
=> "abc"
irb(main):002:0> a<<"def"
RuntimeError: can't modify frozen String
	from (irb):2
	from /usr/bin/irb:12:in `<main>'

"freeze" är en envägsfunktion, väl anropad så är objektet ett värde (i stället för bara en identitet) för resten av sitt liv. Det är förklaringen till varför "String" är "mutable" från start i Ruby.

alternativt skapa din egen strängklass som inte har "mutable" metoder / gör strängen "frusen" direkt vid skapandet.

Och om detta är ett så stort problem för dig lär du inte kunna använda språk som C# / Java (eller ens Scala). De må ha strängklasser som inte kan förändras i normalfallet, men väldigt många andra (majoriteten av fallen för C#/Java) tillåter modifiering av objekt av de flesta standardklasser.

Håller dock med om att det finns massor med fördelar att använda värden ("immutable" state) i stället för identiteter ("mutable" state), men är det något språk förutom Clojure som gör det enkelt och ändå hyfsat effektivt att jobba med (Clojure är trots allt rätt mycket långsammare än t.ex. Java trots att båda kör på en JVM)? Och det trots att Clojure just nu har den mest effektiva implementationen av persistent data structures som finns i någorlunda kända språk. Hur många prestandaproblem i C#/Java program är inte orsakade av att folk bygger strängar direkt med '+' operatorn i stället för StringBuilder, så det finns nackdelar också?

> a="abc".freeze
=> "abc"
irb(main):002:0> a<<"def"
RuntimeError: can't modify frozen String
	from (irb):2
	from /usr/bin/irb:12:in `<main>'

Det är literalen som är problemet, inte mutabilitet i sig som sagt.
Mutabilitet kan tas för givet ur lågnivåperspektiv och många utvecklare tar det även för givet eftersom de är vana vid iterativ programmering. Man kan även vända på steken och se mutabilitet som ett extra ansvarsområde för ett värde; en implicit setter-metod för att använda en väldigt naiv Java-liknelse.
När en literal ger en muterbar datatyp förbinder sig plattformen till ett större ansvar än om datatypen är immutable eftersom det inte går att komma ifrån den extra funktionaliteten.

Scala är inget rent funktionellt språk. Man har ett specifikt nyckelord för variabler som kan ändra värde och man rekommenderas att använda dessa i prestandakritiska områden av kod. Även muterbara datatyper och -strukturer som arrayer används med fördel i dessa situationer. Skillnaden ligger i att man sällan exponerar dessa datatyper utan omvandlar dem till omutbara modeller när de har behandlats klart. På så vis kan man (förhoppningsvis ofta) få det bästa av bägge världar med en förhållandevis liten overhead. Detta är en konvention som möjliggörs av standardramverket och, som jag förstår det, ganska likt "transient"-konceptet i Clojure fast med mer manuell handpåläggning.
Det skulle vara intressant att utveckla ett collection-bibliotek som bygger vidare på dessa idéer

Att man använder + för att konkatenera strängar i C#/Java är antingen av bekvämlighet eller av okunskap; det är inte en defekt i plattformen. Men jag förstår inte riktigt distinktionen mellan C#/Java och Ruby här; Ruby returnerar väl också en ny stränginstans när man konkatenerar med +?

Han syftade inte precis på + och att man inte använder . eller något annat för att sätta ihop strängar då detta är inte en plus operation, utan snarare prestanda problemet som förekommer när du plusar ihop ett par strängar, speciellt i loopar. För i just C# och Java's fall så är de imutable, dvs de måste skapas om varje gång. Gör du detta ett par tusen ggr så kan detta vara grunden till ett prestanda problem.

Att plusa ihop 2 strängar och detta är allt du ska göra så behövs inte stringbuilder o.s.v men ska du fortsätta att göra det så använd stringbuilder då prestanda skillnaden kan vara enorm.

Fixade själv ett projekt med det för några år sedan, tog ca 10 minuter att köra igenom en viss datamängd med den, efter fixen tog det ca 5 sekunder. Enda skillnaden var att istället för att plussa ihop strängar så använde jag strinbuilder.

Det är jag medveten om. Samma sak gäller för Ruby: http://www.ruby-doc.org/core-1.9.3/String.html#method-i-2B

Java skalar otroligt mkt bättre än vad många tror och bör inte uteslutas pga "prestandakritisk" programmering. Vi gjorde ett skalningstest mellan java och C/C++ för några år sedan och java vann den fighten. Värt att notera är att det var en kille från Massive som skrev C/C++ programmet.

OT har jag tyvärr inte mkt att säga.. Jag har jobbat i C/C++, Java och Perl samt pluggat C#. För mig är dock programmeringen ett verktyg för att få jobba med cool hårdvara så jag trivs bäst med C. För tillfället kodar jag i C i Linux kernel och leker med senaste snapdragon hårdvaran

/Knight

a = "abc"
b = a.dub # Make an copy of a for b
a << "def"

a # => "abcdef"
b # => "abc"

Visst, det går att göra en defensiv kopia av strängen innan man gör något med det, men då har man samtidigt förlorat eventuell vinst av att ha muterbara strängar till att börja med.

a = "hello!"
b = add_smiley(a)

add_smiley:

def add_smiley(text)
  text + " :)"
end

I exemplet ovan sker en defensiv kopiering av indatan, men funktionen hade lika gärna kunnat göra text.concat(" :)"). Vems ansvar är det att kopiera defensivt; funktionen eller anroparen av funktionen?

Det här tycker jag var ett rätt bra råd. Om man kan C++ hyggligt så är det en enkel match att lära sig java eller C#. Däremot så är omvändingen inte sann, alltså javaprogrammerare och C# programmerare som försöker sig på C++ brukar bli otroligt förvirrade åtminstone inledningsvis.

I C++ får man mycket hjälp av att allt är väldigt konsekvent uppbyggt och namngivet.
Exempelvis:
I C# så är en namnrymd en samling med klasser. I C++ så är en namnrymd en samling med namn/identifierare.
I C++ så finns det pekare, och det finns det pekare, och det finns funktioner. En pekare till en funktion kallas i C++ en funktionspekare. I C# kallas en pekare till en funktion för en "delegate".
I C++ så kan man "ärva" kod (medlemsdata och medlemsmetoder) från en annan klass, detta hänger ihop med objektorientering. Oavsett vad man skall ärva så använder man alltid samma skrivsätt, och man kan ärva från hur många klasser som helst, och man kan ärva vilken typ av medlemmar som helst (även tomma deklarationer).
I Java och C# så får man bara ärva från enda klass. Det finns restriktioner på vad man får ärva. Om man vill ärva tomma deklarationer så kallas det istället för "Interfaces" och räknas som en separat och annorlunda mekanism.

Lösningen är trivial i Ruby: om du vill att din sträng ska vara ett värde, anropa "freeze" i samband med skapandet av strängen. Detta är både elegant och konsekvent då "freeze" kan anropas på precis vilket typ (inte bara strängar) som helst och därmed göra instansen "immutable". Och då "freeze" är en envängsfunktion så måste saker starta i "mutable" tillstånd om man överhuvudtaget vill tillåta detta, vilket man typiskt vill av effektivitetsskäl.

Så om jag inte misstar mig måste man då alltid kontrollera om en sträng är frusen innan man anropar muterande funktioner på den. Jag vet inte om jag tycker det är en vettig lösning och får samma känsla över att kunna frysa arbiträra objekt.

Allt kommer ner till att man måste göra kompromisser, tycker personligen att Ruby gör en kompromiss här som är väldigt konsekvent samt enkelt att förklara/förstå.

Om du har en typ i Python/Java/C# som har metoder som förändrar tillståndet och de som inte förändrar tillståndet, hur säkerställer du då att ingen ändrar tillståndet på ett sätt som pajar något antagande du gör om tillståndet? Du gör en defensiv kopia, är det bättre/sämre än freeze?

I Ruby kan du alltid välja att enbart anropa metoder som inte förändrar tillståndet, då har du effektivt fått beteendet från Clojure (vilket är trevligt) men även prestandaegenskaperna (vilket i vissa lägen är mindre trevligt). Till en mindre grad gäller detta även Scala och nästan den enda anledningen till att ett typiskt Java program är snabbare än ett motsvarande typiskt Scala är att Scala normalt sätt använder "persistent data types" som skapar mer "skräp" (objekt som inte längre kan nås) när man bygger upp strukturerna. I teorin är "persistent data types" på alla sätt överlägset "mutable data types", men i praktiken måste man rätt ofta ta hänsyn till effektiviteten också.

På vilket sätt är valet man gjort i C#/Java bättre? Där är vissa typer "immutable" medan andra inte är det. För de som är "immutable", t.e.x strängar, så måste alla programmerare vara medveten om detta och använda andra metoder för att effektivt bygga strängar (StringBuilder). Inget större fel med denna lösning heller, men är den inte svårare att förklara för någon?

C++ har en ganska elegant lösning där man kan returnera en referens till en instans där själva referensen är markerad const. Alla metoder som inte förändrar tillståndet kan man markera som const metoder. Det är då möjligt att ha en typ med både metoder som förändrar tillståndet och de som inte förändrar tillståndet. Vill man säkerställa att instansen inte ändras av den som får en referens till den så ger man en referens som är markerad const. Effekten är snarlik den man får med "freeze", men fördelen i C++ är att eventuellt felaktig användning (anrop av "mutable" metod på "immutable" referens) ger ett kompileringsfel i stället för run-time fel.

Så det finns många lösningar, alla med sin beskärda del av fördelar och nackdelar. Själv gillar jag stark saker som är konsekventa, även om det ibland orsakar lite vassa kanter. Är det konsekvent är det i alla fall lätt att förklara, så Ruby, Clojure, Erlang m.fl. är alla bra, då alla är väldigt konsekventa även om de löser problemet olika.

Börjar med det sista: håller helt och fullt med, prestanda i Java är sedan Java6 extremt bra. Java6/7 är i många fall helt i nivå med C/C++ program och i genomsnitt så är Java betydligt snabbare än C#/.Net som saknar finesser som re-JIT (har bara JIT), escape analysis, m.fl.

Som redan nämns så är det inte på Java-koden som man kör JIT och hotspot "re-JIT" utan på bytekoden. När saker kompilerats till bytekod så har en hel del information om programmet redan gått förlorat. Om JIT/re-JIT var helt överlägset så skulle man bara kompilera C++ till bytekod (finns sådana kompilatorer) och köra det. Eller så kompilerar man C++ t.ex. till PPC/MIPS-assembler (båda dessa arkitekturer anses vara väldigt väldesignade) och sedan kör man "JIT" till underliggande CPUn.

Men så gör man inte då det i praktiken blir långsammare (fast typiskt inte med stor marginal, man kan nå 90-95% av "native" hastighet) och framförallt långt mycket mer resurshungrig. Kolla hur mycket RAM en hotspot optimerande JVM vill ha för att fungera optimalt, det handlar om 100-tals MB.

C++ har en fördel som få andra språk har: template meta-programming. Fördelen med detta över vanlig OO-programming är att kompilator har långt många fler möjliga optimeringar, funktioner som anropar andra funktioner i många led kan i vissa lägen helt optimeras bort och kompilator gör en enda stor funktion utan funktionsanrop (man kan skriva sådan kod direkt, men strukturen på ett sådant program blir typiskt en katastrof). Anledningen till att std::sort är snabbare än qsort() i C eller sort i Java/C# beror på att de senare implementationerna använder hopp via en funktionspekare (funktionspekare/virtuell metod) medan C++ använder sig av templates och kompilatorn kommer skapa de statiska funktioner som behövs för den typ man sorterar och alla anrop blir därmed direkta. Moderna CPUer som kör med "out-of-order execution" blir mycket mer effektiv när hoppen är explicita då det inte krävs någon spekulation i vart man ska hoppa.

Du har i teorin rätt om att en JVM kan använda alla instruktioner på den underliggande CPUn. I praktiken är det C/C++ som oftare drar nytta av de i form av att prestandakritiska bibliotek byggs specifikt för den underliggande arkitekturen och det finns tillägg till bl.a. Intels C/C++ kompilator som gör det mycket enklare att använda SSE/AVX. GCC och MSVC kan idag automatiskt dra nytta av heltalsfunktioner i SSE/AVX för att optimera loopar. I praktiken så utför inte JVM:erna någon autovektorisering, tittar man på formatet på bytekoden så inser man snabbt att det skulle vara extremt svårt att lura ut från den vad som kan vektoriseras.

Och att Java används i prestandakritiska nätverksapplikationer är inte heller så konstigt. Kör man med Java NIO så har man en extremt tunn wrapper ovanpå OSet, i Linux kan man använda finesser som epoll via NIO select, vilket är exakt samma anrop som ett C/C++ kommer att använda. Majoriteten av alla cykler spenderas i OS-kärnan (nätverksstacken) i dessa applikationer, så valet av språk/runtime-plattform blir inte speciellt viktigt mer än att man kommer åt "rätt" OS-funktioner. Ett börssystem är inte heller ett "hårt realtidssystem", så man är bara ute efter genomsnittlig låg latens. Det C/C++ även kan ge, men GC språk som Java/C# inte kan, är garanterade svarstiden.

Tack för ett bra svar! Jag kan hålla med om att det är en smaksak, uppenbarligen är många väldigt nöjda med Ruby. Men jag har lite svårt att förstå den här kompromissen, det känns som att man målar in sig i ett hörn.

Jag vill återigen passa på att understryka att jag inte har ett problem med muterbara typer i sig. Det är att man har valt att göra en literal muterbar som jag menar är ett misstag, eftersom det inte går att komma ifrån. Det finns ingen literal för en omutbar sträng. En fryst sträng är fortfarande en muterbar sträng, fast en som slänger exceptions när man försöker modifiera den.

Mycket kommer sig av att Ruby är ett dynamiskt språk. Hade man haft en statisk typechecker så hade man inte kunnat skicka en fryst sträng till en metod som krävde en ofryst, men det hade fortfarande gått att frysa en sträng bortom en användares kontroll, eftersom strängar är "mutable by design."

En annan effekt av denna design (av all design där sideffekter i form av okontrollerad mutation uppmuntras) är fördröjda fel till följd av att ett state man tog för givet har ändrats utanför ens kontroll. Man måste misstro alla tredjepartsmetoder som anropas innan man med säkerhet vet vad de gör, vilket resulterar i defensiv kopiering och mer garbage.

En bättre modell hade varit att separera mutable och immutable i standardbiblioteket, precis som man har gjort med Javas String kontra StringBuilder. Detta är en av ett fåtal idéer jag tycker att man fått rätt från början (även om man tidigare använde StringBuffer istället för StringBuilder..). I Scala har man gått ett steg längre och delat collections-biblioteket i separata grenar: collection.mutable och collection.immutable: http://www.scala-lang.org/api/current/index.html#scala.collection.package

Jag upplevde aldrig att Javas String-typ var ett problem innan jag helt hade greppat de här koncepten. Det jag fick höra var att det var ineffektivt att sätta ihop strängar i en loop och att man skulle använda StringBuffer istället. Personligen skulle jag tro att det är svårare för en nybörjare att greppa de olika typerna av metoder på en Ruby-sträng, och när det är läge att använda dem.

# Ditt exempel ovan är ungefär detsamma som att skriva
b = a + " :)"
# eller
b = a
b += " :)"
# Om det är en metod eller inte spelar alltså ingen roll. Du skapar ett nytt objekt enligt ovan.

Tack men jag förstår vad koden gör. Vad jag menar är att du som användare av ett tredjepartsbibliotek aldrig kan veta om din sträng blir modifierad eller kopierad inuti en metod utan att först läsa igenom källkoden. Det enda säkra blir att skicka en kopia av strängobjektet.

Metoden vet inte heller om användaren har skickat in en referens till en kopia av en sträng eller ett original, så den kanske också gör en säkerhetskopia av strängen innan den skickar den vidare. Istället för en referens har man nu tre, och det är inte ens säkert att de någonsin kommer byta värde.

När du anropar en metod som tar en String i Java är det garanterat att ditt strängobjekt inte ändrar värde. När man arbetar med flertrådade applikationer är detta en deal breaker, men även i enkeltrådade applikationer är det en trygghetsfaktor att veta att ett värde inte ändras utanför ens kontroll.

Använder både elisp och Clojure, så är fullt medveten om vad man kan göra i Lisp. Det fundamentala skillnaden i Lisp jämfört med andra språk är att kod och data är samma sak, vilket betyder att man kan via sitt program direkt modifiera programmets AST (Abstract Syntax Tree). Lisp program är däremot inte ens in närhet så effektiva som motsvarande C++ (eller för den delen Java) program om programmet i fråga är CPU-bundet.

Det ändrar ändå inte det faktum att C++ template meta-programmering kan leda till program som är snabbare än vad du kan åstadkomma med andra språk. Att template meta-programmering är komplicerat må vad sant, men rätt använt så är det enkelt att använda resultatet även om det är svårt att skriva själva implementationen. Eller på vilket sätt är detta komplicerat?

sort(begin(lista), end(lista)); // C++
lista.sort(); // sortera Java, C#

Linq i C++

int nums[] = {3,1,4,1,5,9,2,6,5,4};
auto result = from_array(nums)
                    >> where ([](int n) {return n%2==0;})
                    >> sum ();
}

Linq i C#

int[] nums = new int[]{3,1,4,1,5,9,2,6,5,4};
var result = nums.Where(n => n % 2 == 0).Sum();

Skillnaden här är att C++ versionen typiskt är långt mycket snabbare då C++ linq är ett template-bibliotek så det blir inga indirekta funktionsanrop och i lite mer komplexa uttryck så blir effekten av att C++ kan optimera bort massa mellansteg med temporära resultat riktigt stor. Har uppmätt skillnaden på runt två tiopotenser i prestanda mellan C# och C++ när data-set:et man jobbade på var ~1GB data.

Frågan var ju om C++ är mer effektiv än t.ex. Java, i "vanlig" kod är inte skillnaden relevant, men om template-meta programmering kan användas så kan det ge C++ en enorm fördel då en rad optimeringar kan göras vi kompilering som inte är möjligt i andra språk (inte ens i Lisp).

Jobbar bl.a. med att utveckla OS-kärnor och nätverksstackar för högprestandasystem, så har hyfsad koll på tiderna det tar att processa paket. Jobbar däremot inte med börssystem, men som jag förstått det ligger man idag på latenser ner mot eller ibland till och med under 10µs. Vid den latensen har man inte mer än 20k-30k CPU cykler på sig per paket och det inkluderar den tid paketet ska DMA:as in och ut från NIC då jag utgår från att den latens man specifierar är latens sett från en extern box. Windows behöver ganska exakt denna tid bara på att leverera och skicka paketet genom OSet (sist jag mätte, vilket var på Win7), Linux klarar detta på strax under 10k cykler och en specialdesignat TCP/IP stack kan komma ner till kanske 2k-3k cykler.

Som jag förstått det kör NASDAQ en "vanlig" Linux, så Java-delen kan max stå för ~50% av cyklerna i genomsnitt.

Linux är inte ett RTOS, så man har inte garanterad svarstiden. Men det är ändå så att med Java inför du än mer jitter då GC sker vid tillfällen du inte kan kontrollera. I majoritet av fallen handlar det om några 10-tals eller i värsta fall 100-tals µs som GC tar och det kan vara ganska långt mellan dessa tillfällen, men GC kommer att hända. C/C++ måste ta hand om minneshantering manuellt, vilket i genomsnitt faktiskt kan vara långsammare, men tiden det tar är jämt utspritt och ligger framförallt på samma ställe varje gång.

Men bevisligen spelar genomsnittstiden mest roll i börssystem.