InfoQ om trends i programmerings sprog

De har lavet en lidt spøjs opdeling.

Alt andet end Java og web:

https://res.infoq.com/articles/programming-languag...

Java:

https://res.infoq.com/articles/java-jvm-trends-201...

Web:

https://res.infoq.com/articles/javascript-web-deve...

Java udviklere maa vaere super triste hver gang de ser udvikling af C# (seneste er https://docs.microsoft.com/en-us/dotnet/csharp/wha...

Og saa synes jeg det er lidt underligt at seperere TypeScript og JavaScript. Det er principelt samme teknologi.

#2: forhåbentligt kan de fleste java udviklere også andre sprog

#3

Det kan en stor del af dem formentligt.

Andre JVM sprog og andre non-JVM sprog.

Claus Jørgensen (2) skrev:

Og saa synes jeg det er lidt underligt at seperere TypeScript og JavaScript. Det er principelt samme teknologi.

Sådanne opdelinger er vel altid lidt arbitrære.

Man kan jo godt argumentere for at det er 2 sprog selvom det ene transpiles til det andet.

Claus Jørgensen (2) skrev:

Java udviklere maa vaere super triste hver gang de ser udvikling af C# (seneste er https://docs.microsoft.com/en-us/dotnet/csharp/wha...

Der bliver tilføjet langt mere til C# end til Java, men jeg tror ikke at Java udviklere går rundt og er super triste.

Forskellige tilgange til nogle ting.

De nye features i C# kan vel groft sagt grupperes i 3 kateogier:

1) Store ændringer som ikke er bagud kompatible eller ændrer paradigme.

Java får meget få af disse.

Men hvis Java udviklerne vil have disse features, så vælger de Kotlin eller Scala.

Java verdenen er blevet meget polyglotisk i de senere år.

2) Ændringer bringer variable og brug af samme tættere på fysisk memory.

Jeg vil tro at disse er særdeles interessante for C++ udviklere som overvejer at skifte til C#.

Men Java udviklere har generelt meget lille interesse i den slags.

3) Resten af ændringerne - traditionelle forbedringer af sproget.

Dem er Java udviklerne selvfølgelig interesseret i. Og de bliver også tilføjet løbende.

Der er sikkert mange som gerne så dem tilføjet hurtigere, men ...

Og så er der alle os andre der fortsat kan bruge kode vi perfektionerede for 15 år siden i vores nyeste programmer kørende på Win, Linux, Mac og mobil devices.
Det er nemlig os der stadig sværger til Delphi og FreePascal/Lazarus, hvor man ikke behøver at omprogrammere tingene hvert 2. år når den nyeste trend banker på.
Hvis nogen er interesserede så står jeg til rådighed.

#7

Det er ret generelt at programmeringssprog holdes kompatible så gammel kode stadig virker. Det er ikke en Delphi og FP-Laz ting. Java kode og C# kode fra 2004 virker fint idag. Nogen sprog udvikler sig bare så man idag vil skrive ny kode helt anderledes end i 2004.

arne_v (8) skrev:

#7

Det er ret generelt at programmeringssprog holdes kompatible så gammel kode stadig virker. Det er ikke en Delphi og FP-Laz ting. Java kode og C# kode fra 2004 virker fint idag. Nogen sprog udvikler sig bare så man idag vil skrive ny kode helt anderledes end i 2004.

Det er så ikke korrekt.

Hvis det er _basal_ kode, hvor diverse libraries ikke benyttes, så ja... så vil det meste virke...

Meen... alligevel... hvis vi i første omgang kun kigger på de helt centrale basale ting, så har f.eks. Java har introduceret flere keywords, hvilket giver syntax fejl, hvis du tilfældigvis har brugt samme navn til en variabel eller funktion.
Java 9 har så desuden et par utilsigtede kode breaking problemer også.

C# har også problemer (der er faktisk langt flere end i Java):
https://stackoverflow.com/questions/2548106/breaki...
https://codeblog.jonskeet.uk/2015/03/02/backward-c...
https://news.ycombinator.com/item?id=17567102

Men det er de færreste applikationer som ikke benytter sig af database adgang, og en eller anden form for GUI.

I Java er der blevet introduceret det ene library efter det andet til disse formål og i et uendeligt antal ofte ikke bagudkompatible versioner. Og det er en konstant chase at sikre at alle dependables er korrekte for at man kan forvente at en applikation kan både rekompileres og/eller simpelthen deployes.

Ved C# er der den samme historie... stuff opfindes og deprecates temmelig ofte.
Denne video fortæller en del om de forskellige GUI frameworks der har været, hvor der er en generel trend til at man er "nødt til" at omskrive hver gang, for at få de nyeste features med som findes i Windows, og som i en del tilfælde (UWB) så ikke kan bruges på ældre windows versioner.



Og så er der et større antal DB access API'er, og ved web support så er kode lavet tilbage i tidligere versioner af ASP.Net ikke altid kompatible med senere versioner osv.

I Delphi er det, i de fleste tilfælde, ganske nemt at tage et helt gammelt program, som benytter database og GUI, og rekompilere og køre det i selv nyeste Delphi version.
Nogle af årsagerne er at man har "tænkt tankerne" tidligt og f.eks:
- introduceret en standardiseret (abstrakt) måde at til gå databaser på via TDataset og TDataSource
- været enormt omhyggelig med ikke at introducere ændringer i grund biblioteker uden at sikre bagud kompatibilitet
- ikke har introduceret nye sprog features på bekostning af eksisterende, bare fordi det er cool og trendy
osv.

Istedet har man været ganske dygtige til at lade sproget udvikle sig langsomt evolutionært, samtidig med at der er kommet mange nye libraries og compilere til som gør cross platform kompilering mulig, omend at introduktionen af (ARC) automatisk garbage collection ved brug af ref. counting for alle objekter for de supporterede mobile platforme, var en uheldig beslutning taget i et desparat øjeblik, og som nu trækkes tilbage.

KimMadsen (9) skrev:

arne_v (8) skrev:

#7

Det er ret generelt at programmeringssprog holdes kompatible så gammel kode stadig virker. Det er ikke en Delphi og FP-Laz ting. Java kode og C# kode fra 2004 virker fint idag. Nogen sprog udvikler sig bare så man idag vil skrive ny kode helt anderledes end i 2004.

Det er så ikke korrekt.

Hvis det er _basal_ kode, hvor diverse libraries ikke benyttes, så ja... så vil det meste virke...

Meen... alligevel... hvis vi i første omgang kun kigger på de helt centrale basale ting, så har f.eks. Java har introduceret flere keywords, hvilket giver syntax fejl, hvis du tilfældigvis har brugt samme navn til en variabel eller funktion.

Hvilke keywords er der tilføjet Java de sidste 15 år?

KimMadsen (9) skrev:

Java 9 har så desuden et par utilsigtede kode breaking problemer også.

Som er?

KimMadsen (9) skrev:

Men det er de færreste applikationer som ikke benytter sig af database adgang, og en eller anden form for GUI.

I Java er der blevet introduceret det ene library efter det andet til disse formål og i et uendeligt antal ofte ikke bagudkompatible versioner.

Java har udviklet sig lidt på GUI området: AWT -> Swing (-> JavaFX).

Og API'erne er slet ikke kompatible.

Men de gamle libraries er der stadig.

15 år gammel kode som bruger AWT virker også idag.

Med hensyn til database har JDBC også udviklet sig lidt gennem versionerne.

Men de er kompatible. En applikation som brugte JDBC for 15 år siden vil stadig virke.

Nyere applikationer vil vel bruge JPA oven på JDBC. Og det er et helt andet API (ORM og SQL er nødvendigvis forskellige API'er). Men JDBC er stadig tilgængeligt.

KimMadsen (9) skrev:

Og det er en konstant chase at sikre at alle dependables er korrekte for at man kan forvente at en applikation kan både rekompileres og/eller simpelthen deployes.

AWT og Swing har ingen eksterne dependencies overhovedet. De kommer med Java.

For JDBC skal man have en driver til den database man vil bruge (strengt taget er det ikke nødvendigt for at kunne hverken kompile eller deploye applikationen, men det er nødvendigt for at køre applikationen, så ...). Det er normalt ikke et stort problem.

KimMadsen (9) skrev:

arne_v (8) skrev:

#7

Det er ret generelt at programmeringssprog holdes kompatible så gammel kode stadig virker. Det er ikke en Delphi og FP-Laz ting. Java kode og C# kode fra 2004 virker fint idag. Nogen sprog udvikler sig bare så man idag vil skrive ny kode helt anderledes end i 2004.

Det er så ikke korrekt.
...
C# har også problemer (der er faktisk langt flere end i Java):
https://stackoverflow.com/questions/2548106/breaki...

Prøv og læs teksten. Det er ikke store kompabilitets problemer.

Det første "problem" er:

"Timespan now implements IFormattable and old string.Format() with invalid options will throw exception instead of calling simple ToString()."

Der er en fejl i ens kode og den nye version af .NET opfører sig anderledes (er mere striks).

KimMadsen (9) skrev:

https://codeblog.jonskeet.uk/2015/03/02/backward-c...

Igen et noget specielt tilfælde.

KimMadsen (9) skrev:

https://news.ycombinator.com/item?id=17567102

Som der er kommenteret i tråden, så er påstanden om at .NET 1.x kode ikke kører på 2.0 simpelthen forkert.

KimMadsen (9) skrev:

Men det er de færreste applikationer som ikke benytter sig af database adgang, og en eller anden form for GUI.

...

Ved C# er der den samme historie... stuff opfindes og deprecates temmelig ofte.
Denne video fortæller en del om de forskellige GUI frameworks der har været, hvor der er en generel trend til at man er "nødt til" at omskrive hver gang, for at få de nyeste features med som findes i Windows, og som i en del tilfælde (UWB) så ikke kan bruges på ældre windows versioner.

.NET desktop GUI har udviklet sig: Win Forms -> WPF.

De er ikke kompatible.

Men Win Forms eksisterer stadig og virker fint.

Universal apps er noget andet end desktop apps.

KimMadsen (9) skrev:

Og så er der et større antal DB access API'er,

.NET database adgang har også udviklet sig: ADO.NET og untyped DataSet -> typed DataSet -> LINQ SQL -> EF.

Men ADO.NET og untyped DataSet virker stadig fint.

KimMadsen (9) skrev:

og ved web support så er kode lavet tilbage i tidligere versioner af ASP.Net ikke altid kompatible med senere versioner osv.

Hvad er ikke kompatibelt?

#10 og #11

Det sker at Java og .NET laver breaking changes, men det er normalt ret specielle tilfælde.

Oracle og Microsoft dokumenterer også disse.

Eksempler:

https://www.oracle.com/technetwork/java/javase/8-c...

https://docs.microsoft.com/en-us/dotnet/framework/...

#10 #11 #12

F.eks fra .Net 3.5 til 4.0:
https://www.infoq.com/news/2010/04/Migration-Issue...

Der er andre mellem andre versions skift, men Google selv ;)

Java:
https://en.wikipedia.org/wiki/List_of_Java_keyword...
https://stackoverflow.com/questions/16506411/was-t...

assert (J2SE 1.4), enum (J2SE 5.0), strictfp (J2SE 1.2), var (Java 10), _ (Java 9)

Men som jeg sagde... Selve Java sproget er ikke værst i forhold til breaking changes.
Det er de konstante inkomplette og ofte inkompatible opdateringer til libraries der er Java's største problem. Det har man (med rimelig held) forsøgt mitigeret med package managers (som der så også eksisterer en flok af, der ofte heller ikke indbyrdes er kompatible), men det er et faktum at man ikke som udgangspunkt kan forvente at eens applikation virker med seneste release af lib eller funktionalitet x,y eller z. Derfor package managers og installers.... for at sikre at en helt speciel version af lib x,y og z installeres sammen med applikationen.

Har man mange applikationer, så er det absolut ikke atypisk at have mange versioner af det samme library installeret på sin computer... med det gevaldige rod det giver at system mæssigt manage det, specielt ved større distribuerede installationer.

Vedr. C#.... igen ... Google er din ven ;)

https://docs.microsoft.com/en-us/dotnet/core/compa...

Men... det er stadig ikke det værste... Det værste er at hele centrale frameworks deprececates med jævne mellemrum, og gives status end of life. Ja du kan stadig køre dit gl. program, hvis du ellers husker at have den rigtige version af .Net (og de dertil krævede rigtige versioner af 3. parts libs) installeret, men du kan ikke bygge videre på den, bruge nye features, uden at du skal skrive det gl. framework ud af din kode, og et nyt framework ind.

https://docs.microsoft.com/en-us/dotnet/core/compa...

Det er f.eks. WinForms -> WPF -> UWP

Der er ikke kommet nye features i WinForms siden WPF blev introduceret som det næste store. Det koster app. udviklere og deres firmaer mange mange penge, at "følge med" ved at omskrive hver gang MS genopfinder sig selv, og det har også gjort at 3. parts udviklere har været tvunget til at "progresse" ved at fokusere på det nye "blå" og dermed ikke længere udvikle ny 3.parts funktionalitet til tidligere frameworks.

VCL har eksisteret og udviklet sig i Delphi verden VCL siden Delphi 1 som blev releaset i 1995. TDataset har udviklet sig siden released med Delphi 2 i 1996, men i nyeste Delphi 10.3 Rio eksisterer begge stadig som grundlaget for applikationer, og 3.partsudviklere supporterer og videre udvikler stadig til dem.

Seneste Delphi 10.3 Rio inkluderer f.eks. stadig nye VCL kontroller som matcher nyeste Win 10 release.

Delphi har dog så også valgt at gå cross platform, med brug af FireMonkey (FMX), som ikke er direkte kompatibelt med VCL (men dog på mange områder på overfladen (events og properties) ligner VCL), men det udvikles sideløbende og selv om der konstant tilføjes nye platforme som skal supporteres, så kan man konstant flytte sin kode fremad, uden at skulle kode om.

KimMadsen (13) skrev:

men Google selv ;)
...
Google er din ven ;)

Ikke altid.

Enhver kan lave en søgning på Google og finde noget på nettet, men der er ingen garanti for at det er rigtigt og selvom det er rigtigt, så er der ingen gareanti for at det forståes rigtigt.

Google er en dårlig erstatning for at vide noget.

Og det her er vel et god eksempel.

KimMadsen (7) skrev:

Og så er der alle os andre der fortsat kan bruge kode vi perfektionerede for 15 år siden i vores nyeste programmer kørende på Win, Linux, Mac og mobil devices.

arne_v (8) skrev:

Det er ret generelt at programmeringssprog holdes kompatible så gammel kode stadig virker. Det er ikke en Delphi og FP-Laz ting. Java kode og C# kode fra 2004 virker fint idag. Nogen sprog udvikler sig bare så man idag vil skrive ny kode helt anderledes end i 2004.

KimMadsen (9) skrev:

Meen... alligevel... hvis vi i første omgang kun kigger på de helt centrale basale ting, så har f.eks. Java har introduceret flere keywords, hvilket giver syntax fejl, hvis du tilfældigvis har brugt samme navn til en variabel eller funktion.

arne_v (10) skrev:

Hvilke keywords er der tilføjet Java de sidste 15 år?

KimMadsen (13) skrev:

Java:
https://en.wikipedia.org/wiki/List_of_Java_keyword...
https://stackoverflow.com/questions/16506411/was-t...

assert (J2SE 1.4), enum (J2SE 5.0), strictfp (J2SE 1.2), var (Java 10), _ (Java 9)

Voila 5 styks fundet via Google.

Alt afklaret ikke sandt via Google.

Bortset fra hvis man ved noget om Java.

1.2, 1.4 og 5 er ikke fra de sidste 15 år.

var er ikke et keyword men et reserved type name. Så kan man naturligvis spørge om det gør en forskel. Og svaret er ja. Det gør nemlig at kode med variabel navn eller metode navn var stadig oversætter fint.

Så din påstand i #9 er forkert. Der er kun et nyt keyword som kan give det problem. Og der er formentligt ikke et eneste stykke kode som har haft problemet (jeg tror ikke at nogen bruger _ som variabelnavn).

KimMadsen (13) skrev:

Men som jeg sagde... Selve Java sproget er ikke værst i forhold til breaking changes.
Det er de konstante inkomplette og ofte inkompatible opdateringer til libraries der er Java's største problem. Det har man (med rimelig held) forsøgt mitigeret med package managers (som der så også eksisterer en flok af, der ofte heller ikke indbyrdes er kompatible), men det er et faktum at man ikke som udgangspunkt kan forvente at eens applikation virker med seneste release af lib eller funktionalitet x,y eller z. Derfor package managers og installers.... for at sikre at en helt speciel version af lib x,y og z installeres sammen med applikationen.

????

Du kan som udgangspunkt forvente at det indbyggede Java library er kompatibelt med tidligere version.

De mest gængse libraries vil også typisk opretholde kompabilitet.

Men der er naturligvis undtagelser.

Man bruger iøvrigt normalt ikke begrebet package manager i Java. Build systemer som Maven og Gradle har dog den samme funktionalitet som en del af deres funktionalitet.

Men de er altså ikke så simple som du beskriver: "for at sikre at en helt speciel version af lib x,y og z installeres sammen med applikationen".

Læse stof:

https://maven.apache.org/pom.html#Dependencies

https://www.mojohaus.org/versions-maven-plugin/

KimMadsen (13) skrev:

Har man mange applikationer, så er det absolut ikke atypisk at have mange versioner af det samme library installeret på sin computer... med det gevaldige rod det giver at system mæssigt manage det, specielt ved større distribuerede installationer.

Det er helt normalt i Java, .NET, native kode etc..

Og så længe at de libraries ligger sammen med deres applikationer og ikke et globalt sted, så er det ikke specielt rodet.

KimMadsen (13) skrev:

F.eks fra .Net 3.5 til 4.0:
https://www.infoq.com/news/2010/04/Migration-Issue...

Læs det.

Det er meget små ændringer.

Et godt eksempel er den her:

"Skip(0) is no longer ignored in LINQ to SQL queries."

I .NET 3.5 ignoreres den. I .NET 4.0 forsøger den at skippe 0 elementer. Forskellen er at i .NET 4.0 resulterer det i at der testes om der kunne laves en Skip. Og kode der ikke er klar til Skip vil derfor få en fejl som de ikke fik før. Men koden var også defekt i 3.5 - det nye er bare at det bliver opdaget i 4.0.

KimMadsen (13) skrev:

https://docs.microsoft.com/en-us/dotnet/core/compa...

Der er nok sket større ændringer i .NET Core end i .NET.

.NET Core har været et udviklings projekt i de første versioner.

Man må formode at det bliver mere stabilt når ".NET Core 4.0" bliver .NET 5.

KimMadsen (13) skrev:

Men... det er stadig ikke det værste... Det værste er at hele centrale frameworks deprececates med jævne mellemrum, og gives status end of life. Ja du kan stadig køre dit gl. program, hvis du ellers husker at have den rigtige version af .Net (og de dertil krævede rigtige versioner af 3. parts libs) installeret, men du kan ikke bygge videre på den, bruge nye features, uden at du skal skrive det gl. framework ud af din kode, og et nyt framework ind.

...

Det er f.eks. WinForms -> WPF -> UWP

Der er ikke kommet nye features i WinForms siden WPF blev introduceret som det næste store. Det koster app. udviklere og deres firmaer mange mange penge, at "følge med" ved at omskrive hver gang MS genopfinder sig selv, og det har også gjort at 3. parts udviklere har været tvunget til at "progresse" ved at fokusere på det nye "blå" og dermed ikke længere udvikle ny 3.parts funktionalitet til tidligere frameworks.

Jeg har svært ved at se problemet.

Win Forms understtøttes fint i nyere .NET versioner. Og mig bekendt er der ikke nogle planer om at droppe supporten.

Dem som ikke ønsker at ændre deres Win Forms applikation kan bare lade være.

Dem som kan se nogle fordele ved WPF og er villige til at betale hvad det koster at konvertere gør det.

Det er et frit valg.

Og jeg kan ikke se hvorfor MS skulle undlade at komme med et nyt GUI framework som har nogle fordele.

Nu er jeg ikke ekspert i UWP, men jeg ser ikke UWP som et nyt GUI framework til erstatning for WPF. Mig bekendt bruger UWP samme GUI framework, men forskellen er deployment via Windows Store og brug af en anden runtime.

Muligvis kan Wincape supplere here - det er mere hans (tidligere) ekspertise område.

Ja, UWP er en videreudvikling af WPF, og XAML er mere eller mindre det samme i begge frameworks. Udviklerne har ikke skulle genlaere UWP.

arne_v (6) skrev:

2) Ændringer bringer variable og brug af samme tættere på fysisk memory.

Jeg vil tro at disse er særdeles interessante for C++ udviklere som overvejer at skifte til C#.

Men Java udviklere har generelt meget lille interesse i den slags.

Tror jeg.

Men ikke desto mindre har Java 14 preview fået noget af det samme.

Jeg forstår det ikke.

Det er min bedste vurdering at:
* der er et mellemstort mindretal af C# folket som gerne ser C# afløse C++ overalt og som derfor gerne vil have den slags low level features
* der er stort set ingen Java folk som har ambitioner om at ersttate C++ (man vil hellere afløse Cobol og PL/I)

#18

Og for lige at vise noget kode så folk forstår hvad jeg vrøvler om.

Først noget helt traditionelt C kode med noget rigtigt grimt pointer brug:

#include <stdio.h>

int main()
{
int i;
int ia[] = { 0x11111111, 0x11111111, 0x11111111, 0x11111111, 0x11111111 };
char *ca = (char *)ia;
char *ca2 = ca + 2;
for(i = 0; i < 16; i++)
{
ca2[i] = 0;
}
for(i = 0; i < 5; i++)
{
printf(" %08X", ia[i]);
}
printf("\n");
return 0;
}

output:

00001111 00000000 00000000 00000000 11110000

C# 7.2 introducerede Span<T> og en hel masse mere.

Samme kode i C#:

using System;
using System.Runtime.InteropServices;

namespace MemoryFun
{
public class Program
{
public static void Main(string[] args)
{
int[] ia = { 0x11111111, 0x11111111, 0x11111111, 0x11111111, 0x11111111 };
Span<int> si = ia;
Span<byte> sb = MemoryMarshal.Cast<int, byte>(si);
Span<byte> sb2 = sb.Slice(2, 16);
for(int i = 0; i < 16; i++)
{
sb2[i] = 0;
}
for(int i = 0; i < 5; i++)
{
Console.Write(" {0,8:X8}", ia[i]);
}
Console.WriteLine();
}
}
}

output:

00001111 00000000 00000000 00000000 11110000

Og har Java 14 preview fået nogle MemoryXxxxx klasser som kan det samme:

import java.lang.invoke.VarHandle;
import java.nio.ByteOrder;

import jdk.incubator.foreign.MemoryAddress;
import jdk.incubator.foreign.MemoryHandles;
import jdk.incubator.foreign.MemorySegment;

public class MemoryFun {
public static void main(String[] args) {
int[] ia = { 0x11111111, 0x11111111, 0x11111111, 0x11111111, 0x11111111 };
MemorySegment ms = MemorySegment.ofArray(ia);
MemorySegment ms2 = ms.asSlice(2, 16);
VarHandle bh = MemoryHandles.varHandle(byte.class, ByteOrder.LITTLE_ENDIAN);
MemoryAddress ma = ms2.baseAddress();
for(int i = 0; i < 16; i++) {
bh.set(ma.offset(i), (byte)0);
}
for(int i = 0; i < 5; i++) {
System.out.printf(" %08X", ia[i]);
}
System.out.println();
}
}

output:

00001111 00000000 00000000 00000000 11110000

#18

Der er utrolig lidt C++ hvor det er noedvendigt at lave den slags low level memory aendringer. Til OS level kode er det nok noedvendigt, men til alm. C++ kan jeg ikke se grunden medmindre at folk foersoeger at lave premature optimisations.

#20

Der er ikke ret meget kode, hvor man har brug for den slags.

Men hvis ikke man har brug for den slags - er C++ så det rigtige valg af sprog?

:-)

#19

Og Delphi (man kan ikke lav den slags i standard PAscal, men man kan godt i Delphi):

program memfun;

uses
sysutils;

var
ia : array [0..4] of integer;
ip : ^integer;
cp, cp2 : ^char;
i : integer;

begin
ia[0] := $11111111;
ia[1] := $11111111;
ia[2] := $11111111;
ia[3] := $11111111;
ia[4] := $11111111;
ip := @ia;
cp := pointer(ip);
cp2 := cp + 2;
for i:= 0 to 15 do begin
cp2[i] := chr(0);
end;
for i := 0 to 4 do begin
write(' ',Format('%.8X', [ia[i]]));
end;
writeln;
readln;
end.

arne_v (21) skrev:

#20

Der er ikke ret meget kode, hvor man har brug for den slags.

Men hvis ikke man har brug for den slags - er C++ så det rigtige valg af sprog?

:-)

Hvis resten af koden er skrevet i Java/C# saa er det jo rart ikke at skulle have language-interop bare fordi man skulle skrive en lille smule kode der tilgaar memory direkte.

#23

OK.

Java har 1 besværlig måde (JNI) og .NET 3 nemme måder (DllImport, COM og C++ mixed mode) at kalde native kode på, men det giver ofte problemer i forbindelse med at fejl-håndtering og fejl-finding.