Hvorfor C# er bedre enn Java
Sturla Molden
Kommer jeg til Himmelen eller Helvete for dette?
S.M.
using System;
using System.Diagnostics;
using System.Runtime.InteropServices;
namespace Manual_Memory_Management
{
/// <summary>
/// Manual memory management in C#
/// </summary>
public unsafe class Memory
{
private class InternalHeap
{ // internal class ensures call to finalizer on graceful shutdown
public const uint dwInitialSize = 1024*1024; // 1 MiB
public const uint dwMaximumSize = 1024*1024*1024; // 1GiB
[DllImport("kernel32.dll",SetLastError=true)]
public static extern int HeapFree(uint hHeap, uint dwFlags, void* lpMem);
[DllImport("kernel32.dll",SetLastError=true)]
public static extern int HeapDestroy(uint hHeap);
[DllImport("kernel32.dll",SetLastError=true)]
public static extern void* HeapReAlloc(uint hHeap, uint dwFlags, void* lpMem, uint dwBytes);
[DllImport("kernel32.dll",SetLastError=true)]
public static extern uint HeapCreate(uint flOptions, uint dwInitialSize, uint dwMaximumSize);
[DllImport("kernel32.dll",SetLastError=true)]
public static extern void* HeapAlloc(uint hHeap, uint dwFlags, uint dwBytes);
[DllImport("kernel32.dll",SetLastError=true)]
public static extern uint HeapCompact(uint hHeap,uint dwFlags);
[DllImport("kernel32.dll",SetLastError=true)]
public static extern uint HeapSize(uint hHeap, uint dwFlags, void* lpMem);
public uint handle;
public InternalHeap()
{
handle = HeapCreate(0,dwInitialSize,dwMaximumSize);
}
~InternalHeap()
{
Process proc = Process.GetCurrentProcess();
Console.WriteLine("Destroying unmanaged heap in memory space of process {0}",proc.Id);
HeapDestroy(handle);
}
}
private static InternalHeap heap;
static Memory()
{
Process proc = Process.GetCurrentProcess();
Console.WriteLine("Creating unmanaged heap in memory space of process {0}",proc.Id);
heap = new InternalHeap();
}
public static void * Alloc(uint n)
{
if (n>InternalHeap.dwMaximumSize) return null;
void *retval = InternalHeap.HeapAlloc(heap.handle,0,n);
if (retval == null)
{ // heap may be fragmented
uint lb = InternalHeap.HeapCompact(heap.handle,0);
retval = InternalHeap.HeapAlloc(heap.handle,0,n);
}
return retval;
}
public static void Free(void *buf)
{
InternalHeap.HeapFree(heap.handle,0,buf);
}
public static uint BlockSize(void *buf)
{
return InternalHeap.HeapSize(heap.handle,0,buf);
}
[DllImport("kernel32.dll",EntryPoint="RtlCopyMemory",SetLastError=true)]
public static extern void Copy(void *dest, void *src, uint n);
[DllImport("kernel32.dll",EntryPoint="RtlFillMemory",SetLastError=true)]
public static extern void Fill(void *dest, uint n, byte fill);
[DllImport("kernel32.dll",EntryPoint="RtlZeroMemory",SetLastError=true)]
public static extern void Zero(void *dest, uint n);
[DllImport("kernel32.dll",EntryPoint="RtlMoveMemory",SetLastError=true)]
public static extern void Move(void *dest, void *src, uint n);
public static int Compare(void *s1, void *s2, uint n)
{ // C# code derived from OpenBSD memcmp.c
if (n != 0)
{
byte *p1 = (byte *)s1;
byte *p2 = (byte *)s2;
do
{
if (*p1++ != *p2++) return (int)(*--p1)-(int)(*--p2);
} while (--n != 0);
}
return 0;
}
}
/// <summary>
/// Example of how to use raw memory management for creating and destroying
/// matrices and vectors for numerical computations. This avoids the overhead
/// associated with .NET array classes.
/// </summary>
public unsafe class MathArray
{
public static double ** Matrix(int n, int m)
{ // two blocks are allocated, a bit more work but Windows can tell
// us the size of the matrix
uint rp_buff_size = (uint)(n*sizeof(double*));
uint data_buff_size = (uint)(n*m*sizeof(double));
void *rp_buff = Memory.Alloc(rp_buff_size);
if (rp_buff==null) return null;
void *data_buff = Memory.Alloc(data_buff_size);
if (data_buff==null)
{
Memory.Free(rp_buff);
return null;
}
double **retval = (double **)rp_buff;
for (int i=0; i<n; i++) retval[i] = (double *)((byte*)data_buff + i*m*sizeof(double));
return retval;
}
public static void Destroy(double **matrix)
{ // Find out which allocation method that was used, and select
// deallocation accordingly.
uint block_size = Memory.BlockSize((void*)(matrix));
uint data_start = (uint)(*matrix);
uint block_start = (uint)matrix;
if ((data_start>block_start)&&(data_start<block_start+block_size))
{ // data in block allocated to (void*)matrix by MatrixEx
Memory.Free((void *)(*matrix));
}
else
{ // data and row pointers separately allocated by Matrix
Memory.Free((void *)(*matrix));
Memory.Free((void *)matrix);
}
}
public static double ** MatrixEx(int n, int m)
{ // Only a single block of memory is allocated, this makes
// allocation and deallocation faster, but Windows cannot later
// report the width and height of the matrix.
uint buff_size = (uint)(n*sizeof(double*) + n*m*sizeof(double));
void *buff = Memory.Alloc(buff_size);
if (buff==null) return null;
double **retval = (double **)buff;
byte *datastart = (byte *)buff + n*sizeof(double*);
for (int i=0; i<n; i++) retval[i] = (double *)(datastart + i*m*sizeof(double));
return retval;
}
public static void DestroyEx(double **matrix)
{ // Only use this method if MatrixEx was used for allocation.
// Since the purpose of MatrixEx is to reduce the numer of
// required system calls, we don't do any checks to verify this.
Memory.Free((void *)matrix);
}
public static int Height(double **matrix)
{
uint block_size = Memory.BlockSize((void*)(matrix));
uint data_start = (uint)(*matrix);
uint block_start = (uint)matrix;
int retval;
if ((data_start>block_start)&&(data_start<block_start+block_size))
{ // matrix allocated by MatrixEx, Windows ignorant about width and height
retval = -1;
}
else// data block and row pointers in separately allocated memory blocks,
{ // Windows can report the width and height of our matrix
retval = (int)((int)block_size/sizeof(double*));
}
return retval;
}
public static int Width(double **matrix)
{
uint block_size = Memory.BlockSize((void*)(matrix));
uint data_start = (uint)(*matrix);
uint block_start = (uint)matrix;
int retval;
if ((data_start>block_start)&&(data_start<block_start+block_size))
{
retval = -1;
}
else
{
int nrows = (int)((int)block_size/sizeof(double*));
int ndata = (int)Memory.BlockSize((void*)(*matrix)) / sizeof(double);
retval = ndata / nrows;
}
return retval;
}
public struct MatrixDim
{
public int Height, Width;
}
public static MatrixDim Size(double **matrix)
{
uint block_size = Memory.BlockSize((void*)(matrix));
uint data_start = (uint)(*matrix);
uint block_start = (uint)matrix;
MatrixDim retval = new MatrixDim();
if ((data_start>block_start)&&(data_start<block_start+block_size))
{
retval.Height = -1;
retval.Width = -1;
}
else
{
retval.Height = (int)((int)block_size/sizeof(double*));
int ndata = (int)Memory.BlockSize((void*)(*matrix)) / sizeof(double);
retval.Width = ndata / retval.Height;
}
return retval;
}
public static double * Vector(int n)
{
return (double *) Memory.Alloc((uint)(n*sizeof(double)));
}
public static void Destroy(double *vector)
{
Memory.Free(vector);
}
public static int Length(double *vector)
{
return (int)Memory.BlockSize((void*)vector) / sizeof(double);
}
}
unsafe class AppClass
{
[STAThread]
static void Main(string[] args)
{
Console.WriteLine("");
// create a 5 by 5 matrix
double **mat = MathArray.Matrix(5,5);
// fill the matrix with zeros
Memory.Fill((void*)(*mat),5*5*sizeof(double),0);
// put in two values
mat[2][3] = 5.0;
mat[4][4] = 7.0;
// plot the matrix
Console.WriteLine("");
for (int i=0; i<5; i++)
Console.WriteLine("{0}\t{1}\t{2}\t{3}\t{4}",
mat[i][0], mat[i][1], mat[i][2], mat[i][3], mat[i][4]);
Console.WriteLine("");
// Create another matrix
double **mat2 = MathArray.Matrix(7,9);
int w = MathArray.Width(mat2);
int h = MathArray.Height(mat2);
Console.WriteLine("Width of second matrix is {0}",w);
Console.WriteLine("Height of second matrix is {0}",h);
Console.WriteLine("");
// Let's try MatrixEx instead
double **mat3 = MathArray.MatrixEx(7,9);
w = MathArray.Width(mat3);
h = MathArray.Height(mat3);
Console.WriteLine("Width of third matrix is {0}",w);
Console.WriteLine("Height of third matrix is {0}",h);
Console.WriteLine("");
// clean up
MathArray.Destroy(mat);
MathArray.Destroy(mat2);
MathArray.Destroy(mat3); // this is ok too, but MathArray.Destroy will be faster
}
}
}
Bjørn Furuknap
> Kommer jeg til Himmelen eller Helvete for dette?
>
Kommer an på om Microsoft har kjøpt opp himmelen før det...
Bjørn
--
- There is no failure. You either learn or you succeed.
Sturla Molden
> Kommer an på om Microsoft har kjøpt opp himmelen før det...
Uansett viser eksempelet at C# kan gjøre det samme
som C kan gjøre, i motsetning til Java. For eksempel
har de statiske metodene Memory.Copy og Memory.Alloc
samme effekt som memcpy og malloc i C. Eksempelet viser også
at det med C# er mulig å allokere og deallokere
minne dynamisk uten å bruke heap'et som holdes ryddig
av søppelmannen System.GC.
Et annet eksempel: I Java vil et uttrykk som matrix[i][j]
medføre funksjonskall og range-sjekking. Ved bruk av
C#-klassen MathArray vil ikke uttrykket matrix[i][j]
medføre større overhead en tilsvarende i C: ingen
funksjonskall og ingen range-sjekk.
S.M.
Tor Iver Wilhelmsen
> Et annet eksempel: I Java vil et uttrykk som matrix[i][j]
> medføre funksjonskall og range-sjekking. Ved bruk av
> C#-klassen MathArray vil ikke uttrykket matrix[i][j]
> medføre større overhead en tilsvarende i C: ingen
> funksjonskall og ingen range-sjekk.
matrix[i][j] er ikke en "matrise" men array av array: For å få en
"skikkelig" todimensjonal array bruker man syntaks lik matrix[i,j] -
også under deklarasjonen.
(Står på lista over ting jeg liker ved C#. :) )
Harald Nordgård-Hansen
Jeg tror aldri jeg helt har fått tak på denne diskusjonen, men... Du
prøver nå å vise hvorfor Java er så mye bedre enn C#, ja?
Det at et språk tillater brukeren å gjøre så lavnivå-ting som C, viser
for mange av oss at disse folkene som laget C# hverken har forstått C
eller Java (eller programmering generelt). Sånn sett gjentar C# de
samme katastrofale feilene som C++ gjorde i sin tid, og ender opp som
et like lite egnet verktøy for å programmere med.
-Harald
--
Harald Nordgård-Hansen, Linpro AS, Wilbergjordet 1
Postboks 375, NO-1601 Fredrikstad, Norway
Phone/Fax: +47 6935 9255/56 <>< http://harald.nordgard-hansen.net/
Frode Tennebø
> Uansett viser eksempelet at C# kan gjøre det samme
> som C kan gjøre, i motsetning til Java.
Og det er bra fordi?
> For eksempel
> har de statiske metodene Memory.Copy og Memory.Alloc
> samme effekt som memcpy og malloc i C.
Som er bra fordi?
> Eksempelet viser også
> at det med C# er mulig å allokere og deallokere
> minne dynamisk uten å bruke heap'et som holdes ryddig
> av søppelmannen System.GC.
Og slik minneslekasje er bra fordi?
> Et annet eksempel: I Java vil et uttrykk som matrix[i][j]
> medføre funksjonskall og range-sjekking. Ved bruk av
> C#-klassen MathArray vil ikke uttrykket matrix[i][j]
> medføre større overhead en tilsvarende i C: ingen
> funksjonskall og ingen range-sjekk.
Og du _vil_ ha buffer owerflow/array bounds read/write fordi?
-Frode
--
^ Frode Tennebø | email: fr...@tennebo.com | Frode@IRC ^
| with Standard.Disclaimer; use Standard.Disclaimer; |
Tor-Einar Jarnbjo
@orkan.itea.ntnu.no:
> On Wed, 16 Jun 2004 17:32:42 +0000, Bjørn Furuknap wrote:
>
>> Kommer an på om Microsoft har kjøpt opp himmelen før det...
>
> Uansett viser eksempelet at C# kan gjøre det samme
> som C kan gjøre, i motsetning til Java.
Hva om jeg skriver en Java-Klasse:
package test;
public class StdMem {
public static native long alloc(int size);
}
og implementerer metoden slik:
JNIEXPORT jlong JNICALL Java_test_StdMem_alloc
(JNIEnv * env, jclass clazz, jint size) {
return (jlong)malloc(size);
}
Greit nok at den siste biten ikke er Java, men det spiller da ikke så
stor praktisk rolle om du integerer C-syntax i C# (som det ser ut som om
er gjort) eller om du gjør det enkelt å bruke C-moduler fra Java? Jeg vil
heller påstå at det heller er en fordel å kunne programmere i C slik du
er vant til, og på den måten virkelig kunne utnytte alle fordelene ved å
programmere i C, i stedet for å være innskrenket til et nytt, ukjent
wrapper-API med mer eller mindre samme funksjoner.
> Et annet eksempel: I Java vil et uttrykk som matrix[i][j]
> medføre funksjonskall og range-sjekking. Ved bruk av
> C#-klassen MathArray vil ikke uttrykket matrix[i][j]
> medføre større overhead en tilsvarende i C: ingen
> funksjonskall og ingen range-sjekk.
¨
Ja, det har du rett i, men utelater å nevne alle de andre problemene du
pådrar deg. Jeg har implementert en del algoritmer for lyd- og
bildebehandling i Java og må være enig med deg i at på akkurat det
punktet henger Java ganske langt etter C når det gjelder hastighet.
Tor-Einar
Tor-Einar Jarnbjo
> Og du _vil_ ha buffer owerflow/array bounds read/write fordi?
Fordi det fortsatt finnes områder, der påtvunget bounds-checking gir for
stor overhead?
Tor-Einar
stu...@molden.net
> matrix[i][j] er ikke en "matrise" men array av array
I dette tilfellet er matrix en peker til en tabell med pekere.
Det som skjer her er at en double aksesseres gjennom dereferering
av to pekere, det vil si matrix[i][j] blir til *(*(matrix+i)+j).
Dette settes rett inn i bytekoden av kompilatoren og blir
JIT-kompilert av .NET-runtimen.
Men hvis du ser på hvordan databufferen til matrisen ble lagt
ut av MathArray.Matrix vil du se at det faktisk er en rektangulær
matrise. Det er ikke en tabell med tabeller. Det benyttes en
tabell med pekere i tillegg for å gjøre tabelloppslaget i
matrisen raskere (man unngår multiplikasjon). Matrisen kan for
eksempel kopieres med to kall til Memory.Copy, en for peker-
tabellen og en for databufferen.
> For å få en
> "skikkelig" todimensjonal array bruker man syntaks lik matrix[i,j] -
> også under deklarasjonen.
I prinsippet kunne man gjøre dette, men det er et stort problem
med det. Kompilatoren lager ikke effektiv kode. Av en eller annen grunn
er rektangulære tabeller svært ineffektive i C#. For det første
resulterer matrix[i,j] i et funksjonskall, det blir ikke "inlinet"
av kompilatoren. For det andre resulterer matrix[i,j] i bounds-
sjekking. Tabell-oppslag implementert som funksjonskall pluss
bounds-sjekking er direkte håpløst i ganske mange tilfeller.
Rektangulære matriser kan være svært effektive (jfr. Fortran),
fordi kompilatoren vet at matrix[1] og matrix[4] ikke kan være
alias. Men i C99 kan det gjøres enda mer effektivt: ved å
deklarere matrix som double*restrict*restrict i stedet for
double **. Da vet C99-kompilatoren det samme som Fortran-kompilatoren,
samtidig som den ikke trenger å bruke multiplikasjon for å
finne fram i tabellen.
> (Står på lista over ting jeg liker ved C#. :) )
Fin egenskap, men det er implementert alt for dårlig.
STurla Molden
Bjorn Borud
jeg er litt usikker på hva du mener er kult her? hvorfor programmerer
du ikke C++ isteden, for det er vel egentlig det du har lyst til?
-Bjørn
--
"The key to performance is elegance, not battalions of special cases."
-- Jon Bentley and Doug McIlroy
Geir Harris Hedemark
> Greit nok at den siste biten ikke er Java, men det spiller da ikke så
> stor praktisk rolle om du integerer C-syntax i C# (som det ser ut som om
> er gjort) eller om du gjør det enkelt å bruke C-moduler fra Java? Jeg vil
Det er litt mer omfattende enn som så, er jeg redd.
C# implementerer diverse ting som lar deg gå utenfor sandkassemodellen
som både JVM og CLI drar på. Sturla har helt rett i at sandkassa har
en kostnad. Fordelen er at man slipper buffer overruns, minnelekkasjer
fordi man glemmer å frigjøre minne eksplisitt når man kaster den siste
pekeren til det, pekere til datastrukturer i deler av programmet ditt
som _er_ håndtert av GC-systemet og så videre.
Det gir mening å ha slikt i et CLI-system dersom man ser det som
veldig viktig å kunne kjøre alle mulige sære språk på samme VM. Noen
prioriterer bjeller, oppvaskkummer og fløyter høyere enn andre, og det
må de jo få lov til.
I min verden er det design, vedlikehold og testing av kode som er de
store utgiftene - på grunn av de assosierte lønnskostnadene. Behov for
ekstra maskinvare på grunn av ytelsesdegradering er minst en
størrelsesorden mindre per år. Derfor bryr jeg meg minimalt om
overheaden ved å faktisk ha rangesjekking. Det får gutta som skal
knuse tall bekymre seg om - men av en eller annen grunn tror jeg ikke
de bruker C#.
> Ja, det har du rett i, men utelater å nevne alle de andre problemene du
> pådrar deg. Jeg har implementert en del algoritmer for lyd- og
> bildebehandling i Java og må være enig med deg i at på akkurat det
> punktet henger Java ganske langt etter C når det gjelder hastighet.
Har du forsøkt med JDK 1.4 og serveropsjonen slått på?
Jeg fant en artig artikkel i dag: http://sys-con.com/story/?storyid=45250&DE=1
Mannen påstår at Java vinner over C++ i en del benchmarks han har
kjørt. Jeg har ikke hatt tid til å faktisk se over min egen kode og
etterprøve om jdk 1.4.2 i servermodus faktisk gir såpass mye ekstra
oomf. Det hadde vært moro om den gjorde det.
Geir
Thore Karlsen
[...]
>I min verden er det design, vedlikehold og testing av kode som er de
>store utgiftene - på grunn av de assosierte lønnskostnadene. Behov for
>ekstra maskinvare på grunn av ytelsesdegradering er minst en
>størrelsesorden mindre per år. Derfor bryr jeg meg minimalt om
>overheaden ved å faktisk ha rangesjekking. Det får gutta som skal
>knuse tall bekymre seg om - men av en eller annen grunn tror jeg ikke
>de bruker C#.
Spørsmål: Utvikler dere programvare som kun skal brukes internt i
bedriften?
--
Be seeing you.
Tor-Einar Jarnbjo
news:xq3pt7z...@kolme.ifi.uio.no:
>> Ja, det har du rett i, men utelater å nevne alle de andre problemene
>> du pådrar deg. Jeg har implementert en del algoritmer for lyd- og
>> bildebehandling i Java og må være enig med deg i at på akkurat det
>> punktet henger Java ganske langt etter C når det gjelder hastighet.
>
> Har du forsøkt med JDK 1.4 og serveropsjonen slått på?
>
> Jeg fant en artig artikkel i dag:
> http://sys-con.com/story/?storyid=45250&DE=1
>
> Mannen påstår at Java vinner over C++ i en del benchmarks han har
> kjørt. Jeg har ikke hatt tid til å faktisk se over min egen kode og
> etterprøve om jdk 1.4.2 i servermodus faktisk gir såpass mye ekstra
> oomf. Det hadde vært moro om den gjorde det.
Akkurat arrays er en god del raskere med -server-opsjonen, men
forskjellen er veldig avhengig av selve koden og jeg har også opplevd at
ting tar lenger tid med server-opsjonen. Det virker som om grunnen er at
server-hotspoten venter lenger før den kompilerer byte-koden, men så gjør
den derimot en grundigere jobb når den først slår til.
Likevel er testen du referer til på mange måter ganske intetsigende,
siden det vel ikke er noen stor hemmelighet at gcc ikke akkurat
produserer verdens raskeste kode og å sammenligne GNUs og Suns hashcode-
og hashtable-implementasjoner har vel ikke så mye med forskjeller i C++
og Java å gjøre.
For å gjennomføre enda en upraktisk test, implementerte jeg en ikke-
rekursiv fibonacci-beregning slik:
fibs[0] = 1;
fibs[1] = 1;
for(i=2; i<100000; i++) {
fibs[i] = fibs[i-1] + fibs[i-2];
}
og testet den med forskjellige Java-versjoner, gcc 3.4.0 og Microsofts C-
compiler fra Visual Studio. fibs er long[] i Java og long long[] i C-
versjonen (begge 64 bit). I Java-versjonen kjørte jeg først 1000
iterasjoner for å "varme opp" og så 10000 iterasjoner for å måle tiden.
absolutt/relativ
gcc -march=k8 -O2 350 µs 1,35
cl /O2 /G7 260 µs 1,00
jdk1.4.2_04 -client 590 µs 2,27
jdk1.4.2_04 -server 290 µs 1,12
jdk1.5.0b2 -client 640 µs 2,46
jdk1.5.0b2 -server 290 µs 1,12
På den gamle maskinen min (Pentium III, 700MHz) er forskjellen mellom
klient- og server-vmen omtrent halvparten så stor, så det ser ut som om
server-versjonen trenger en del maskinkraft og/eller minne å gå på for å
komme opp i fart.
Tor-Einar
Geir Harris Hedemark
> Spørsmål: Utvikler dere programvare som kun skal brukes internt i
> bedriften?
Vi utvikler for det meste programvare som vi drifter for kundene våre,
ja.
Jeg tror ikke jeg klarer å følge tankerekka di. Kan du forklare litt
nærmere?
Geir
Sturla Molden
> gcc -march=k8 -O2 350 µs 1,35
> cl /O2 /G7 260 µs 1,00
> jdk1.4.2_04 -server 290 µs 1,12
Virkelig imponerende. Jeg kunne tenke med å teste
dette på C# eller J# også. Kan du poste hele koden?
S.M.
Sturla Molden
> jeg er litt usikker på hva du mener er kult her? hvorfor programmerer
> du ikke C++ isteden, for det er vel egentlig det du har lyst til?
Jeg har programmert mye C++, men Erik Naggum oppsummerte det
ganske godt en gang: "C++ er C med kreft." C++ er et verktøy
for å lage bloatware. Hvis man skal lage en GUI er ikke
C++ et velegnet verktøy.
S.M.
Tor-Einar Jarnbjo
@orkan.itea.ntnu.no:
Ja, det kan jeg jo:
long[] fibs = new long[100000];
int i=0, j=0;
fibs[0] = 1;
fibs[1] = 1;
for(j=0; j<1000; j++) {
for(i=2; i<100000; i++) {
fibs[i] = fibs[i-1] + fibs[i-2];
}
}
long t0 = System.currentTimeMillis();
for(j=0; j<10000; j++) {
for(i=2; i<100000; i++) {
fibs[i] = fibs[i-1] + fibs[i-2];
}
}
long t1 = System.currentTimeMillis();
System.out.println(t1-t0);
Jeg kom forresten på at den første sløyfa med "oppvarming" av Hotspot-
compileren ikke griper slik jeg hadde implementert det der, så jeg flyttet
den indre sløyfa ut i en ny metode:
private static void fib(long[] fibs, int length) {
fibs[0] = 1;
fibs[1] = 1;
for(int i=2; i<length; i++) {
fibs[i] = fibs[i-1] + fibs[i-2];
}
}
og forandret hovedprogrammet slik:
long[] fibs = new long[100000];
int i=0, j=0;
for(j=0; j<1000; j++) {
fib(fibs, 100000);
}
long t0 = System.currentTimeMillis();
for(j=0; j<10000; j++) {
fib(fibs, 100000);
}
long t1 = System.currentTimeMillis();
System.out.println(t1-t0);
Det hadde ingen innvirkning på C-programmet, client-versjonen av Java 1.4
brukte enda lenger tid, men det ble skikkelig fart i server-vmen:
absolutt/relativ
gcc -march=k8 -O2 350 µs 1,35
cl /O2 /G7 260 µs 1,00
jdk1.4.2_04 -client 680 µs 2,62
jdk1.4.2_04 -server 210 µs 0,81
jdk1.5.0b2 -client 640 µs 2,46
jdk1.5.0b2 -server 200 µs 0,78
Tor-Einar
Espen Vestre
> long[] fibs = new long[100000];
...
> for(j=0; j<1000; j++) {
> for(i=2; i<100000; i++) {
> fibs[i] = fibs[i-1] + fibs[i-2];
> }
> }
Dette ser da helt meningsløst ut, men jeg må spørre siden jeg er
en java-ignorant: Er ikke java long 64-bits signed? Dvs. største
long er 2^63-1? Til sammenlikning er jo allerede fibonacci-nummer
nr 92, 12200160415121876738, større enn 64 bit! Fibonaccinummer
nr. 50000 har allerede 34712 bits (jeg regnet ikke ut fler)...
*klør seg i hodet*
--
(espen)
Geir Harris Hedemark
> Dette ser da helt meningsløst ut, men jeg må spørre siden jeg er
> en java-ignorant: Er ikke java long 64-bits signed? Dvs. største
Det stemmer.
Geir
Geir Harris Hedemark
> Dette ser da helt meningsløst ut, men jeg må spørre siden jeg er
> en java-ignorant: Er ikke java long 64-bits signed? Dvs. største
Det stemmer.
java.math.BigInteger er din venn.
Geir
Espen Vestre
> Det stemmer.
>
> java.math.BigInteger er din venn.
Ah, jeg kan ikke få sagt hvor mye det gleder meg å se hvor grundig man
kan skyte seg i foten uten advarsel med java. Dette eksemplet skal jeg
dunke i hodet på den neste plagsomme statisk-type-fetisjisten jeg
møter :-)
til dem som lurer på hva java egentlig _gjør_ i dette eksemplet, jeg
skrev om javaprogrammet (*) til å skrive ut fibonaccitall nr. 88-95
(eller 89-96 ettersom hvor man begynner å telle):
88 1779979416004714189 (riktig)
89 2880067194370816120 (riktig)
90 4660046610375530309 (riktig)
91 7540113804746346429 (riktig)
92 -6246583658587674878 (12200160415121876738)
93 1293530146158671551 (19740274219868223167)
94 -4953053512429003327 (31940434634990099905)
95 -3659523366270331776 (51680708854858323072)
(*) mitt første forsøk på java etter at jeg fikk alvorlige kjedsomhets-
problemer et par leksjoner ut i Suns tutorial da jeg prøvde å
lære meg java for en 7-8 år siden ;-)
--
(espen)
Thore Karlsen
>> Spørsmål: Utvikler dere programvare som kun skal brukes internt i
>> bedriften?
>Vi utvikler for det meste programvare som vi drifter for kundene våre,
>ja.
>
>Jeg tror ikke jeg klarer å følge tankerekka di. Kan du forklare litt
>nærmere?
Jeg tenkte i grunnen det, men jeg var i grunnen bare nysgjerrig. De av
oss som utvikler programvare for andre lever i en litt annen verden.
Lønnsutgiftene mine er barnemat mot alle salgene vi hadde tapt om
ytelsen ikke hadde vært topp. :)
Men selv der jeg jobbet og utviklet skreddersydde systemer for én kunde
om gangen var ytelse viktig. Faktisk var det ikke noe annet jeg jobbet
mer med enn å øke ytelsen på Java-løsningene våre. Når ting skal kjøre
på svindyre serverparker kunne vi spare kunden enorme summer i hardware
og båndbreddekostnader. Lønnskostnadene var barnemat sammenlignet med
det. Bare å bytte JVM kunne i mange tilfeller spare kunden titalls
millioner.
--
Be seeing you.
Tor-Einar Jarnbjo
> Dette ser da helt meningsløst ut, men jeg må spørre siden jeg er
> en java-ignorant: Er ikke java long 64-bits signed? Dvs. største
> long er 2^63-1? Til sammenlikning er jo allerede fibonacci-nummer
> nr 92, 12200160415121876738, større enn 64 bit! Fibonaccinummer
> nr. 50000 har allerede 34712 bits (jeg regnet ikke ut fler)...
>
> *klør seg i hodet*
Poenget med metoden var jo egentlig bare å sammenligne hastigheten på
array-operasjoner i C og Java. Jeg var klar over at resultatet var
feil, men det var ikke så veldig viktig. Grunnen til at jeg valgte en
fibonacci-beregning var for å vise at det er en stor forskjell i
performance-variasjonene mellom min iterative implementasjon og den
rekursive beregningen i testen som Geir henviste til. Jeg antar at
resultatet av den testen er mer avhengig av overheaden ved et
metodekall, enn selve adderingen av tallene.
Tor-Einar
Tor Iver Wilhelmsen
> Jeg har programmert mye C++, men Erik Naggum oppsummerte det
> ganske godt en gang: "C++ er C med kreft." C++ er et verktøy
> for å lage bloatware. Hvis man skal lage en GUI er ikke
> C++ et velegnet verktøy.
Jeg foretrekker følgende:
C++: It's like C when you use it, and it will only get better when we
stop doing so.
:)
Jon Martin Solaas
>
> Kommer jeg til Himmelen eller Helvete for dette?
>
>
> S.M.
>
Spoersmaalet er vel om du kommer noe sted i det heletatt. Hva er poenget ?
Petter Gustad
> 88 1779979416004714189 (riktig)
> 89 2880067194370816120 (riktig)
> 90 4660046610375530309 (riktig)
> 91 7540113804746346429 (riktig)
> 92 -6246583658587674878 (12200160415121876738)
> 93 1293530146158671551 (19740274219868223167)
> 94 -4953053512429003327 (31940434634990099905)
> 95 -3659523366270331776 (51680708854858323072)
Hvor fikk du fasiten fra, ikke C# vel :-)
Petter
--
Sv: Fordi det roter til rekkefølgen i forhold til hvordan man
vanligvis leser tekst.
Sp: Hvorfor er det et problem?
Sv: Top-posting.
Sp: Hva er det mest irriterende du vet på usenet og i e-post?
Frode Tennebø
I mange tilfeller kan bounds-checking gjøres ved compile time. Jeg sier
ikke alle, men jeg vil hevde at hvis bounds-checking gir "for stort
overhead" (altså at det er det som stopper fremdrift i prosjektet) har
man i utgangspunktet valgt feil platform/språk/whatever.
Tor Iver Wilhelmsen
> Hvor fikk du fasiten fra, ikke C# vel :-)
Skal jeg gjette? Noe slikt...
>>> fibs = {}
>>> fibs[0] = fibs[1] = 1
>>> for i in xrange(2,100):
... a = fibs[i] = fibs[i-1] + fibs[i-2]
... if i > 90: print "%i: %i" % (i, a)
...
91: 7540113804746346429
92: 12200160415121876738
93: 19740274219868223167
94: 31940434634990099905
95: 51680708854858323072
96: 83621143489848422977
97: 135301852344706746049
98: 218922995834555169026
99: 354224848179261915075
:)
Tor-Einar Jarnbjo
> Ah, jeg kan ikke få sagt hvor mye det gleder meg å se hvor grundig man
> kan skyte seg i foten uten advarsel med java. Dette eksemplet skal jeg
> dunke i hodet på den neste plagsomme statisk-type-fetisjisten jeg
> møter :-)
Ja, akkurat her er det fort gjort å gjøre feil
> til dem som lurer på hva java egentlig _gjør_ i dette eksemplet, jeg
> skrev om javaprogrammet (*) til å skrive ut fibonaccitall nr. 88-95
> (eller 89-96 ettersom hvor man begynner å telle):
>
> 88 1779979416004714189 (riktig)
> 89 2880067194370816120 (riktig)
> 90 4660046610375530309 (riktig)
> 91 7540113804746346429 (riktig)
> 92 -6246583658587674878 (12200160415121876738)
> 93 1293530146158671551 (19740274219868223167)
> 94 -4953053512429003327 (31940434634990099905)
> 95 -3659523366270331776 (51680708854858323072)
99999 - 2597406934abc3428746875
999999 - 1953282128def8242546875
abc representerer 20880 siffer og def 208976 siffer.
Tor-Einar
Geir Harris Hedemark
> Men selv der jeg jobbet og utviklet skreddersydde systemer for én kunde
> om gangen var ytelse viktig. Faktisk var det ikke noe annet jeg jobbet
> mer med enn å øke ytelsen på Java-løsningene våre. Når ting skal kjøre
Merkelig. De ytelsesproblemene jeg har løpt borti som det har vært
lønt verdt å tak i i Java har vært algoritmerelaterte - med unntak av
trivielle nybegynnerting som konkatenering av String i stedet for bruk
av StringBuffer, manglende pooling av databaseconnections og så
videre.
Men så er vi heller ikke der at en fem prosents innsparing (mitt tall)
i ressursforbruk representerer "millioner av kroner" i hardware. Man
får relativt mange heftige bokser for en million kroner (i klassen for
100), og vi har definitivt ikke kunder med behov som tilsier en
serverfarm på 2000 maskiner.
Geir
Thore Karlsen
>> Men selv der jeg jobbet og utviklet skreddersydde systemer for én kunde
>> om gangen var ytelse viktig. Faktisk var det ikke noe annet jeg jobbet
>> mer med enn å øke ytelsen på Java-løsningene våre. Når ting skal kjøre
>Merkelig. De ytelsesproblemene jeg har løpt borti som det har vært
>lønt verdt å tak i i Java har vært algoritmerelaterte - med unntak av
>trivielle nybegynnerting som konkatenering av String i stedet for bruk
>av StringBuffer, manglende pooling av databaseconnections og så
>videre.
Det var litt av hvert som var galt. Mye var dårlig programmering og
planlegging. Poenget var ikke annet enn at mangel på fokus på ytelse
lett kan koste masse penger. Om man slipper å tenke på slik så er jo det
greit, men så heldige er vi ikke alle. :)
>Men så er vi heller ikke der at en fem prosents innsparing (mitt tall)
>i ressursforbruk representerer "millioner av kroner" i hardware. Man
>får relativt mange heftige bokser for en million kroner (i klassen for
>100), og vi har definitivt ikke kunder med behov som tilsier en
>serverfarm på 2000 maskiner.
Det ene prosjektet de ville jeg skulle jobbe med optimisering av var
sidene til Ford. Det var ikke småpenger de brukte på servere og
båndbredde, så det var enorme summer å spare. Jeg takket nei, så jeg vet
ikke hva den gruppen endte opp med å gjøre. Første steg var ihvertfall å
benchmarke forskjellige JVM-er. De regnet med å kunne spare inn flere
millioner bare på å bruke en mer effektiv JVM.
En annen løsning jeg jobbet med ble så treg at kunden ikke engang brukte
den. Det er ikke så vanskelig å velge mellom noen utviklerlønninger og å
betale tilbake $10mill til en misfornøyd kunde. :)
Som sagt, det er gøy om man slipper å tenke på slike ting, men det betyr
fremdeles veldig mye.
--
Be seeing you.
Bjorn Borud
|
| Jeg tenkte i grunnen det, men jeg var i grunnen bare nysgjerrig. De av
| oss som utvikler programvare for andre lever i en litt annen verden.
| Lønnsutgiftene mine er barnemat mot alle salgene vi hadde tapt om
| ytelsen ikke hadde vært topp. :)
min erfaring er:
a) folk overvurderer ytelsesgevinsten ved å bruke C++ (og C).
b) lønnsutgifter er en mindre belastning enn time to market.
c) C++ er utelukkende tilrådelig å bruke dersom man kan designe og
implementere alt fra scratch uten å dra på legacy-kode og design
samt at man har tilgang på særdeles gode programmerere.
jeg tror a) dels skyldes at folk mangler erfaring og dels at folk har
veldig tungt for å tro at verden endres. Java-verdenen endres
betydelig raskere enn C++ som er en, pardon my pun, relativt statisk
verden.
du kan skrive ting i C++ som er raskere enn Java, men det triste
faktum er at nesten ingen programmerere er gode nok til å gjøre det
konsekvent, på kort nok tid, samtidig produsere kode som er robust,
portabel og mulig å forstå uten at man må kaste bort uendelig mye tid
på å finne ut hvilke idiosynkrasier denne C++-utvikeren har¹.
(husk forøvrig at jeg tilbrakte mesteparten av 90-tallet på å hacke C
på UNIX og vente på at Java skulle bli brukbart, så jeg er ikke en av
de pimple-faced Java-fanboy'ene du ser på konferanser)
¹) min erfaring er at stilvariasjonen i C++-kode "in the wild" er
langt større og mye mer fundamental enn tilsvarende i Java.
Tor-Einar Jarnbjo
> On Thu, 17 Jun 2004 01:35:57 +0000, Tor-Einar Jarnbjo wrote:
Jeg ble også nysgjerrig nå på hvordan C# holder mål her, og siden du
tydeligvis ikke kom så langt (eller turde å komme med resultatet :), så
gjorde jeg det for deg:
C# (.NET 1.1) 420 µs 1,61
Jeg kunne jo ha prøvd J# også, men download-linken på web-sidene til
Microsoft virker ikke i kveld.
Jeg reimplementerte forresten din opprinnelige C#-kode i Java og server-
vmen i Suns JDK1.5.0 beta 2 er 10% raskere en .NET 1.1, selv med garbage
collection og bounds-checking. Java-klassen var på rundt 20 linjer, mot
dine 240.
Tor-EInar
Bjorn Borud
|
| Det ene prosjektet de ville jeg skulle jobbe med optimisering av var
| sidene til Ford. Det var ikke småpenger de brukte på servere og
| båndbredde, så det var enorme summer å spare. Jeg takket nei, så jeg vet
| ikke hva den gruppen endte opp med å gjøre. Første steg var ihvertfall å
| benchmarke forskjellige JVM-er. De regnet med å kunne spare inn flere
| millioner bare på å bruke en mer effektiv JVM.
høres ut som det slaget mot kostnader var tapt allerede på
tegnebrettet -- som det meste av systemer som backer websites.
jeg har endel kompiser som gjør gode penger på å gjøre "quick fix"-
oppdrag for "bedrifter som er i vinden" og det er utrolig hvordan
løsninger som er kriminelt dårlig designet fremdeles tiltrekker
vulture capitalist-dollars.
det utrolige er at det lønner seg.
det viktigste er som oftest time to market og hvordan noe *ser ut*. at
teknologien er så shabby at den bare fungerer mens den går på et halvt
dusin respiratorer, dialysemaskiner og en stab på stand-by er ikke så
farlig. at det koster mer å reparere slike systemer og holde dem på
life-support enn å gjøre jobben skikkelig et halvt dusin ganger er
heller ikke så farlig.
lite har endret seg i visse deler av bransjen.
Thore Karlsen
>| Jeg tenkte i grunnen det, men jeg var i grunnen bare nysgjerrig. De av
>| oss som utvikler programvare for andre lever i en litt annen verden.
>| Lønnsutgiftene mine er barnemat mot alle salgene vi hadde tapt om
>| ytelsen ikke hadde vært topp. :)
>min erfaring er:
>
> a) folk overvurderer ytelsesgevinsten ved å bruke C++ (og C).
Jepp.
> b) lønnsutgifter er en mindre belastning enn time to market.
Jepp.
> c) C++ er utelukkende tilrådelig å bruke dersom man kan designe og
> implementere alt fra scratch uten å dra på legacy-kode og design
> samt at man har tilgang på særdeles gode programmerere.
Jepp.
[...]
>du kan skrive ting i C++ som er raskere enn Java, men det triste
>faktum er at nesten ingen programmerere er gode nok til å gjøre det
>konsekvent, på kort nok tid, samtidig produsere kode som er robust,
>portabel og mulig å forstå uten at man må kaste bort uendelig mye tid
>på å finne ut hvilke idiosynkrasier denne C++-utvikeren har¹.
Det største problemet med C++ er at folk ikke vet hvordan de skal lage
enkel og elegant kode i C++. Det er faktisk mulig, og det er ikke engang
vanskelig. De fleste ser dessverre ikke ut til å forstå helt elementære
ting som gjør programmene mye kortere, enklere, og mer problemfrie.
Det viktigste å huske på i C++ er IMNSHO: Unngå å måtte rydde opp
ressurser manuelt. Har man først innsett det så er de fleste problemer
folk assosierer med C++ ute av veien. C++ gjør det faktisk lekende lett
å gjøre dette rett, mer så enn de fleste andre språk. En annen ting: Man
_må_ ikke bruke hele språket, alle bibliotekene, og alle idiomene. Ofte
fører det til kode som er grusom å lese. Mye av det jeg ser fra
C++-eksperter gir meg hodeverk og diaré fordi det er så bakvendt.
Ellers er mye felles for de fleste språk, som organisering av kode og
slike ting. Det største problemet jeg ser i C++ er dog manuell
ressurshåndtering. Jeg får angst når jeg ser slik.
>(husk forøvrig at jeg tilbrakte mesteparten av 90-tallet på å hacke C
>på UNIX og vente på at Java skulle bli brukbart, så jeg er ikke en av
>de pimple-faced Java-fanboy'ene du ser på konferanser)
For min del er det ikke så mye ytelse som er grunnen til at jeg ikke
bruker Java. I jobbsammenheng kan jeg ikke bruke det lenger, men på
hobbybasis bruker jeg det heller ikke fordi jeg rett og slett ikke liker
språket/miljøet.
>¹) min erfaring er at stilvariasjonen i C++-kode "in the wild" er
> langt større og mye mer fundamental enn tilsvarende i Java.
Det er også min erfaring. Og joda, det er mye søppelkode i C++.
--
Be seeing you.
Bjorn Borud
|
| Det største problemet med C++ er at folk ikke vet hvordan de skal lage
| enkel og elegant kode i C++. Det er faktisk mulig, og det er ikke engang
| vanskelig.
...dersom du har muligheten til å skrive koden fra scratch eller hive
*mye* kode på legacy-systemer. dersom du må forholde deg til
betydelig mengder legacy-kode som du skal bygge oppå, rundt og under
forandrer gamet seg betydelig. det er her C++ forårsaker mest smerte
og Java i *praksis* oppleves som noe mindre smertefullt selv når koden
er skrevet av sjimpanser på LSD.
| De fleste ser dessverre ikke ut til å forstå helt elementære
| ting som gjør programmene mye kortere, enklere, og mer problemfrie.
det er prisen for multiparadigmatisk valgfrihet. kult når du skal
imponere damene med hvor kryptisk det er mulig å spesifisere en
formell løsning på et problem: ubrukelig for å faktisk kommunisere
løsninger.
:-)
| Det viktigste å huske på i C++ er IMNSHO: Unngå å måtte rydde opp
| ressurser manuelt.
fint tanke i utgangspunktet, men selve språket er så klønete at man
likevel ender opp med å sjonglere pekere og annen moro fordi selv
elementære ting som collections er så gudsjammerlig ubehjelpelige
umoderne, komplisert og lite brukervennlig at man enten må kopiere
data eller sørge for indirekte automatisk opprydding ved å kopiere
ting som peker på ting...og så er du i gang med sirkuset.
enter referansetelling! C++ er fint helt til du skal begynne å gjøre
sånne nymotens ting folk finner på å gjøre i dag som f.eks å lage dyre
immutable-objekter med multiple referanser til seg. ok, moro, enten
kopierer vi eller... implementerer referansetelling.
jeg tror rekorden for ett prosjekt jeg har sett på er 8-9 ulike steder
der man har implementert ulike former for referansetelling. og
jevnlig må debugge fordi koden presterer å fucke opp
referansetellerne.
(great! jeg simpelthen elsker objekter som har metoder for å
inkrementere og dekrementere referansetellere og der utvikleren har
pepret koden med "oj, jeg kalte noe som inkrementerer
referansetelleren inni den sorte boksen så nå må jeg dekrementere den
fra utsiden igjen"-kode. storartet. tro ikke et øyeblikk at slikt
ikke forekommer "i de beste familier")
(de er nesten like tilbakestående som de *idiotene* som lager
"exceptions" i C med makroer og setjmp/longjmp. herregud, hvor kommer
disse idiotene fra og hvordan får vi dem nedi esken igjen?)
poenget mitt er at det degenererer fort til kode som er vanskelig å
vedlikeholde når man skal gjøre ting som i C++ er "avansert" (mens de
samme tingene er "hverdagslig" i f.eks Java) og som en betydelig andel
av C++-utviklere ikke vil skjønne og deretter herpe.
| En annen ting: Man _må_ ikke bruke hele språket, alle bibliotekene,
| og alle idiomene. Ofte fører det til kode som er grusom å lese. Mye
| av det jeg ser fra C++-eksperter gir meg hodeverk og diaré fordi det
| er så bakvendt.
gitt et stort nok prosjekt med nok legacy-kode og noen titalls
utviklere vil du bli eksponert for alle features C++ har og er du
ekstra uheldig: en bøtte features C++ ikke har, men som noen påfører
med "kreative triks".
| Ellers er mye felles for de fleste språk, som organisering av kode og
| slike ting.
organisering av kode? C++? hehe, den var god.
| For min del er det ikke så mye ytelse som er grunnen til at jeg ikke
| bruker Java. I jobbsammenheng kan jeg ikke bruke det lenger, men på
| hobbybasis bruker jeg det heller ikke fordi jeg rett og slett ikke liker
| språket/miljøet.
Java er en acquired taste hvis man har en IQ over 80. Java er
befolket med utrolige mengder flatulente krøtter, men heldigvis er
språket mye mindre og paradigmene for hvordan man lager infrastruktur
mye mer moderne og "lærbare" enn tilsvarende for C++ så selv idioter
kan faktisk skrive kode som, om den ikke er brukbar, som oftest er
enklere å fjerne kirurgisk.
dårlig C++-kode er som en kreftsvulst med lange fangarmer inn i
hjernen på systemet det infiserer: det er nesten umulig å operere
bort faenskapet uten å måtte skjære vekk mye av det det sitter fast
i.
det er i alle fall slik jeg opplever språkene i praksis.
stu...@molden.net
> Jeg ble også nysgjerrig nå på hvordan C# holder mål her, og siden du
> tydeligvis ikke kom så langt (eller turde å komme med resultatet :), så
> gjorde jeg det for deg:
> C# (.NET 1.1) 420 µs 1,61
Jeg kom på at det nok er dumt å benchmarke på ulike
PC-er så derfor orket jeg ikke prøve.
> Jeg kunne jo ha prøvd J# også, men download-linken på web-sidene til
> Microsoft virker ikke i kveld.
Det spiller nok neppe noen rolle.
S.M.
Thomas Bakketun
> Hvor fikk du fasiten fra, ikke C# vel :-)
* Tor Iver Wilhelmsen:
> Skal jeg gjette? Noe slikt...
Jeg gjetter heller noe slikt:
(defun fibs (from &optional (to from))
(do ((i 0 (1+ i))
(a 0 b)
(b 1 (+ a b)))
((> i to))
(when (>= i from)
(format t "~A: ~A~%" i b))))
Denne versjonen samler vel å merke ikke opp alle delresultatene i en
array, men det er unødvendig i tillegg til at minnet ville bli brukt opp
vel litt større tall.
Så en liten hastighetstest:
(time (fibs 100000))
; Evaluation took:
; 8.11 seconds of real time
; 4.520313 seconds of user run time
; 0.497925 seconds of system run time
; 8,108,715,511 CPU cycles
; [Run times include 1.52 seconds GC run time]
; 0 page faults and
; 446,611,728 bytes consed.
Slett ikke verst med tanke på at funksjonen gir rett svar, er ikke
optimalisert av noen betydning og er skrevet av en ganske fersk
lispprogrammerer.
Det er også mulig å skrive en versjon tilsvarende originalen:
(defun fibs-fort-og-gale (from &optional (to from))
(declare (optimize (speed 3)
(compilation-speed 0)
(safety 0) ; Sikkerhet er for pyser
(debug 0))
(fixnum from to))
(let ((fibs (make-array to)))
(setf (svref fibs 0) 1)
(setf (svref fibs 1) 1)
(do ((i 2 (1+ i)))
((> i to))
(declare (fixnum i))
(setf (svref fibs i)
(the fixnum (+ (the fixnum (svref fibs (- i 1)))
(the fixnum (svref fibs (- i 2))))))
(when (>= i from)
(format t "~A: ~A~%" i (svref fibs i))))))
(time (fibs-fort-og-gale 100000))
; Compiling LAMBDA NIL:
; Compiling Top-Level Form:
100000: -394347427
; Evaluation took:
; 0.0 seconds of real time
; 0.003999 seconds of user run time
; 0.0 seconds of system run time
; 3,303,972 CPU cycles
; 0 page faults and
; 401,208 bytes consed.
Konklusjonen må bli at Java er et bedre språk en Common Lisp å lage
programmer som gir feil resultat fortest mulig. Det skulle vel gjøre
Java en god konkurrent til C++.
--
Roten til alt vondt er egen syntaks for attributter.
Espen Vestre
> Hvor fikk du fasiten fra, ikke C# vel :-)
øh, nei ;-)
jeg bare lagde en rettframoversettelse til Common Lisp:
(defparameter *fibs* (make-array 100000))
(setf (aref *fibs* 0) 1)
(setf (aref *fibs* 1) 1)
(defun init-fibs (&optional (n 100000)(fibs *fibs*))
(loop for i from 2 below n
do (setf (aref fibs i)
(+ (aref fibs (- i 1))
(aref fibs (- i 2))))))
Det interessante poenget her er selvsagt at det er først når man
begynner å deklarere typer at man kan komme i skade for å introdusere
typefeil, siden man kan finne på å introdusere en type som er for
spesialisert i forhold til oppgaven!
Forøvrig er ikke effektiviteten så ille, dette kompilerer til kode
som ikke gjør noe minneallokering så lenge tallene er fixnums, først
når bignum _trengs_ (altfor tidlig på LW på x86, men det er en
implementasjonsdetalj) begynner dette programmet å "conse".
Ps.: Hvis jeg deklarerer fixnums og skrur av all sikkerhet, får
jeg masse morsomme feilmeldinger fra LispWorks, <pumpkin>
meg her og segmentation fault der, det er jo nesten bedre
enn å regne feil i all stillhet ;-)
--
(espen)
Espen Vestre
> C# (.NET 1.1) 420 µs 1,61
Jeg håper du har skriftlig tillatelse fra Microsoft til å offentlig-
gjøre det tallet ;-)
--
(espen)
Sturla Molden
> Spoersmaalet er vel om du kommer noe sted i det heletatt. Hva er poenget ?
kommer troll til himmelen?
Tor-Einar Jarnbjo
> Jeg håper du har skriftlig tillatelse fra Microsoft til å offentlig-
> gjøre det tallet ;-)
Dæven, men du må ikke tro at du slipper unna, selv om du bare siterte meg
:) Vent litt, det ringer på dø+++'\v9n385
Alf P. Steinbach
>
> Kommer jeg til Himmelen eller Helvete for dette?
Sannsynligvis til helvete.
Rå pekere er ren ondskap, Sturla. Ondskap! I forrige leksjon så vi at
rå pekere ikke er en god idé for å optimere strenghåndtering; i denne
leksjonen kunne vi ha sett, hvis jeg hadde giddet, at de heller ikke er
spesielt smarte for optimering av array-håndtering.
C# er etter min oppfatning langt bedre som opplæringsspråk enn Java, og
også til profesjonell anvendelse innen for eksempel Windows GUI, men et
språk er mer enn kun språkdefinisjonen og hvor enkelt det er...
Begrensningene som gjør Java dårlig som opplæringsspråk og til Windows
GUI er samtidig de som gjør Java velegnet som profesjonelt språk innen
visse andre områder (forskjellig fra C#).
Det er nesten alltid slik at "gode" begrensninger virker frigjørende; ta
for eksempel pipes og omdirigering som bygger på en begrensning av filer
til rene byte-strømmer, og som dermed generelt ikke fungerer til å
kopiere en Windows NTFS fil -- begrensningen i Unix er en "god" sådan.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Geir Harris Hedemark
> til rene byte-strømmer, og som dermed generelt ikke fungerer til å
> kopiere en Windows NTFS fil -- begrensningen i Unix er en "god" sådan.
Dette var ukjent for meg - jeg er unixtryne. Gidder du utdype litt?
(Og jeg håper ingen tolker Alf dithen at unix tvinger deg til å se på
en fil som en bytesekvens som _må_ leses i sekvens. Du kan aksessere
tilfeldig så mye du orker.)
Geir
Torkel Holm
> Det er også mulig å skrive en versjon tilsvarende originalen:
Vel, her blir jo oppførselen udefinert. Allegro slenger ut en
type-error under kjøring.
BTW fixnum er her signed 30-bit.
#+allergro
(deftype fixnum () `(integer ,(- #1=#.(expt 2 29)) ,(1- #1#))
> (defun fibs-fort-og-gale (from &optional (to from))
> (declare (optimize (speed 3)
> (compilation-speed 0)
> (safety 0) ; Sikkerhet er for pyser
> (debug 0))
> (fixnum from to))
> (let ((fibs (make-array to)))
> (setf (svref fibs 0) 1)
> (setf (svref fibs 1) 1)
>
> (do ((i 2 (1+ i)))
> ((> i to))
> (declare (fixnum i))
> (setf (svref fibs i)
> (the fixnum (+ (the fixnum (svref fibs (- i 1)))
> (the fixnum (svref fibs (- i 2))))))
> (when (>= i from)
> (format t "~A: ~A~%" i (svref fibs i))))))
--
Torkel Holm
Sturla Molden
> C# er etter min oppfatning langt bedre som opplæringsspråk enn Java, og
> også til profesjonell anvendelse innen for eksempel Windows GUI, men et
> språk er mer enn kun språkdefinisjonen og hvor enkelt det er...
Hvilket verktøy bør brukes til profesjonell Windows GUI
programmering?
- Visual C++, MFC og ATL
- Visual C++, ATL og WTL
- Borland C++ Builder, VCL
- Borland Delphi, VCL
- Visual Basic 6
- Visual Basic .NET
- Microsoft C#, Windows Forms
- Mono C#, GTK#
- C++, Qt
- C++, wxWidgets
- C++, FLTK
- C++, FOX
- C++, GTKMM
- C, GTK+
- C, WinAPI
- Python, wxWidgets
- Java, AWT og Swing
- Java, Eclipse og SWT
- J# .NET
- J++ og MFC
Eller noen annet?
Sturla Molden
Rune Huseby
news:xq3wu25...@kaksi.ifi.uio.no:
> al...@start.no (Alf P. Steinbach) writes:
>> til rene byte-strømmer, og som dermed generelt ikke fungerer til å
>> kopiere en Windows NTFS fil -- begrensningen i Unix er en "god" sådan.
>
> Dette var ukjent for meg - jeg er unixtryne. Gidder du utdype litt?
http://www.sysinternals.com/ntw2k/source/misc.shtml#streams
Kort fortalt kan en fil ha flere navngitte byte-strømmer i seg. Er visstnok
en Mac-isme for at NT skulle kunne serve Mac (Macintosh har/hadde to
strømmer pr fil, en for data/kode og en for ressurser som f.eks. ikoner)
--
Rune Huseby
Alf P. Steinbach
Den praktiske løsningen på dét spørsmålet er det du har tilgjengelig som
gjør jobben og som du har kompetanse på og som du liker og som du får
management med på og som ikke er helt utdatert (J++ faller der; i
forbifarten går jeg ut fra at "MFC" på den linjen kun er en skrivefeil).
Men ideellt er ikke Java+ATW/Swing noe særlig til den bruken, selv om
kriteriene ovenfor er oppfylt -- både tregt og stygt og fullt av
bugs/pitfalls og i det hele tatt. Dog, hvis det eneste man har er en
slegge, og man virkelig liker den sleggen, så kan man spikre med den.
Og til og med skru i en skrue eller to (da jeg holdt på med Java for
mange herrens år siden var et eksempel utklippstavlen i Windows, og et
annet skikkelig hjelpsystem, men jeg vet at hjelpsystem nå er OK).
Visual Basic 6 som du nevner er ikke nødvendigvis utdatert men til tross
for hva mange tror gjør den ikke jobben. Det går greit å lage noe men
slett ikke greit å få til en pålitelig installasjon av det lagede. Java
har muligens også litt av det problemet fremdeles, men det vet jeg ikke.
Jeg ville heller ikke brukt Perl (dog ikke nevnt i listen) til noe av
den størrelsen som en GUI typisk blir, siden det er write-only språk.
I motsatt retning: Borland Delphi finnes i .NET-versjon, men har ikke
brukt dyret. For en Pascal-entusiast er den kombinasjonen muligens midt
i blinken. Det finnes sikkert også mye annet interessant ikke nevnt i
listen i din -- for småtterier er det for eksempel aktuelt (synes jeg)
å lage .hta HTML-applikasjoner med scripting, valgfritt scriptspråk.
Thomas Bakketun
> Vel, her blir jo oppførselen udefinert. Allegro slenger ut en
> type-error under kjøring.
Da må Allegro være dårlig siden den legger inn mye unødvendig
kontrollkode...
Tor Iver Wilhelmsen
> Merkelig. De ytelsesproblemene jeg har løpt borti som det har vært
> lønt verdt å tak i i Java har vært algoritmerelaterte - med unntak
> av trivielle nybegynnerting som konkatenering av String i stedet for
> bruk av StringBuffer, manglende pooling av databaseconnections og så
> videre.
Pluss på med "beregne verdier i getValueAt() i stedet for å cache" for
TableModel i Swing.
På et system jeg var med på å lage var forøvrig den største
flaskehalsen databaselaget, som var skrevet i C++ (med RogueWaves
dbTools.h++) fordi de som skrev "laget" ikke likte Java eller JDBC noe
særlig. Men det brukerne opplevde var selvsagt at Swing-klienten som
snakket med basen gjennom CORBA opplevdes treg.
Tor Iver Wilhelmsen
> - J++ og MFC
Det skal vel være J++ og WFC. WFC ble laget som "a better MFC" for
Microsofts dialekt av Java.
Geir Harris Hedemark
> Pluss på med "beregne verdier i getValueAt() i stedet for å cache" for
> TableModel i Swing.
Swing? Uææh.
Geir
Sturla Molden
>> - J++ og MFC
>
> Det skal vel være J++ og WFC. WFC ble laget som "a better MFC" for
> Microsofts dialekt av Java.
Samme ulla. En W er en M opp ned.
Jon Martin Solaas
Det finner du nok ut.
Meningen med Java er å ikke gjøre det C kan gjøre, mens meningen med C#
er å gjøre det C kan gjøre? Er det det som er poenget? I såfall ville
jeg nok enten brukt C eller Java ...
Hvis du absolutt må bruke Java, og absolutt ikke kan leve med
boundschecking er du i et prosjekt du ikke bør være i, spør du meg, men
hvis du ikke kommer deg ut kan du vel prøve å ro deg i land med JNI.
Hvis oppgaven var forbundet med tallknusing ville jeg ligget langt unna
C# og heller satset på et språk som ihvertfall er kvasi-portabelt, som
f.eks. C. Hva koster forresten et C#-kapabelt cluster i disse dager?
jonmartin.solaas¤h0tm4i1
Jon Martin Solaas
Kanskje det er feil spørsmål? Hvilket verktøy bør *ikke* brukes til
profesjonell Windows GUI programmering?
>
> Eller noen annet?
Fins det noe særlig mer, da?
--
jonmartin.solaas¤h0tm4i1
stu...@molden.net
> Kanskje det er feil spørsmål? Hvilket verktøy bør *ikke* brukes til
> profesjonell Windows GUI programmering?
Sannsynligvis alle, muligens med unntak av Java, SWT og JFACE.
Delphi og J# er tvilstilfeller.
> Fins det noe særlig mer, da?
Ja noen til, blant annet Visual C++ .NET og Windows Forms.
S.M.
stu...@molden.net
> Hvis du absolutt må bruke Java, og absolutt ikke kan leve med
> boundschecking er du i et prosjekt du ikke bør være i, spør du meg,
Selv Matlab har bounds-sjekking. Men hvis JIT-kompilatoren flytter den
ut av små sløyfer er det ikke noe problem. Problemet er at .NET
sannsynligvis ikke gjør dette (selv om Microsoft skryter det på seg),
mens server versjonen av Suns JVM trolig gjør det. I Matlab er det ordnet
slik at kall til Fortran og C-blibioteker i f.eks. LAPACK og FFTW gjør
bounds-sjekking før bibliotek-rutinene startes opp, mens bibliotek-
funksjonene selvsagt ikke gjør noen sjekker. Så lenge man holder bounds-
sjekkene utenfor den beregningsintensive delen av koden er alt
i orden.
> hvis du ikke kommer deg ut kan du vel prøve å ro deg i land med JNI.
> Hvis oppgaven var forbundet med tallknusing ville jeg ligget langt unna
> C# og heller satset på et språk som ihvertfall er kvasi-portabelt, som
> f.eks. C.
C89 duger ikke på grunn av peker-aliasing. C99 er adekvat.
likeledes Fortran77 og Fortran95. Det mest fornuftige ser ut
til å være å like mot numeriske biblioteker skrevet i Fortran77,
for eksempel BLAS, ATLAS og LAPACK. Da kan man like gjerne
bruke Java til resten. Det er skjelden store deler av koden
som krever den ekstra ytelsen man kan presse ut av C99 eller
Fortran sammenlignet med Java.
Dessuten gjør Matlab det svært enkelt å bruke Java-klasser
sammen med Matlab-skript.
> Hva koster forresten et C#-kapabelt cluster i disse dager?
I kroner og øre eller i tapt ytelse? Hvis man i tillegg legger
til at syntaks-bloaten til C# etterhvert gjør koden umulig
å vedlikeholde (akkurat som C++), kommer man opp i en liten
formue.
Delegater, operator-overloading, versjonering av virtuelle
funksjoner, pass-by-reference av enkle typer, pekere,
structs på stack, eksplisitt struct layout (tilsvarende
byte-pakking og unioner i C), integrert COM og COM+, pekere,
og snart også C++ liknende templates gjør C#-kode til en
potensiell katastrofe. Alle disse "forbedringene" i forhold
til Java har ingen annen annen effekt enn å gjøre det enklere
å skrive dårlig kode. På grunn av syntaks-bloaten som C#
legger opp til kan man for bli sittende med en floke
som aldri kan nøstes opp -- og man må starte helt på nytt.
S.M.
Jon Martin Solaas
Windows Forms har du jo alt anbefalt, og hvorfor du anbefaler VC6 og
ikke VC .net har jeg ikke tenkt å spørre om :-/
Ottar Smidesang Holstad
> > profesjonell Windows GUI programmering?
>
> Sannsynligvis alle, muligens med unntak av Java, SWT og JFACE.
> Delphi og J# er tvilstilfeller.
Kvifor ser du på Delphi som tvilstilfelle? Gjeld det Win32-varianten,
.NET-varianten, eller begge?
Sturla Molden
> Kvifor ser du på Delphi som tvilstilfelle? Gjeld det Win32-varianten,
> .NET-varianten, eller begge?
Det gjelder først og fremst Win32-varianten. Borland har vært så
uklar med hensyn på hva de vil med VCL at man ikke kan stole på
at produktet har en framtid. I åpne brev på "Borland developer
network" har selskapet kastet tvil over framtiden til VCL for
Win32. Dette skjedde i forbindelse med laseringene av Delphi for
.NET og C++ Builder X.
Å basere et nytt prosjekt i dag på VCL anser jeg som et
høyrisikoprosjekt. Man bør bruke verktøy som man vet vil få support i
minst ti år, ikke starte med noe som produsenten kanskje la på is
året i forvegen. Problemet med Borland er at de aldri preannonserer
produkter eller forteller om sine visjoner, og de sier aldri fra
i klartekst hvis et produkt blir lagt på is. Så man vet aldri hva de
finner på et halvt år fram i tid. Kanskje er VCL for Win32 lagt ned,
kanskje ikke. Slikt kan man ikke forholde seg til.
Jeg mener det nok er tryggere å bruke .NET-varianten enn Win32-varianten
av Delphi i dag, siden Microsoft er såpass forutsigbar at de ikke
skrinlegger hele .NET-rammeverket over natta (slik Borland kunne gjøre).
På den andre siden er bruk av et .NET-verktøy fra et Borland også et
risikoprosjekt, bant annet fordi man kan komme i en situasjon der man
urettmessig bryter Microsofts rettigheter (blant annet til .NET-
assosierte patenter). Her må man stole på at Borland har alt på det
tørre, men det får kundene neppe innsyn i.
Delphi som språk har jeg ingen innvendinger mot. Turbo Pascal var
det programmeringsspråket jeg først lærte meg, da jeg startet som
student på NTH i 1994. Men jeg har ikke brukt Pascal siden den gang,
og det har gått i glemmeboken for lenge siden.
Sturla Molden
Thore Karlsen
wrote:
[...]
>Jeg mener det nok er tryggere å bruke .NET-varianten enn Win32-varianten
>av Delphi i dag, siden Microsoft er såpass forutsigbar at de ikke
>skrinlegger hele .NET-rammeverket over natta (slik Borland kunne gjøre).
Det er kanskje liten sjanse for at de gjør det med .NET, men de har da
skrinlagt drøssevis av teknologier over natta. OLE, DDE, COM, +++.
--
Be seeing you.
Alf P. Steinbach
OLE og COM lever da i ytterst beste velgående. Når Microsoft integrerte
MTS inn i ordinær Windows (i Windows 2000), og så integrerte .NET med
COM både i selve .NET rammeverket og i Windows XP, og når Microsoft til
stadighet kommer med nye OLE-baserte ting, så er det neppe for å
skrinlegge COM/OLE... DDE har du imidlertid rett i er en skrinlagt og
foreldet teknologi, men den har fremdeles full støtte i Windows.
En interessant liten opplysning: da Microsoft skrinla 16-bits Windows
API'en, med innføringen av Windows 95, standardiserte de den i ECMA. :-)
Forøvrig, den Pascal-varianten som Delphi representerer har vist en
utrolig seiglivethet. Første som den danske hva-den-nå-het Pascal, så
som Borland's Turbo Pascal, så Borland Pascal, så Delphi og Kylix, og nå
Delphi for .NET. Markedsføringen slo imidlertid om fra eksellent ("No
Speed Limit") til nærmest anti-produkt ("RAD!", "klikk og pek!"), så det
er ikke rart at det har dannet seg et inntrykk av upålitelighet -- når
de ikke har annet å skryte av enn at noviser kan bruke IDE'en, så...
Thore Karlsen
wrote:
>> [...]
>>
>> >Jeg mener det nok er tryggere å bruke .NET-varianten enn Win32-varianten
>> >av Delphi i dag, siden Microsoft er såpass forutsigbar at de ikke
>> >skrinlegger hele .NET-rammeverket over natta (slik Borland kunne gjøre).
>> Det er kanskje liten sjanse for at de gjør det med .NET, men de har da
>> skrinlagt drøssevis av teknologier over natta. OLE, DDE, COM, +++.
>OLE og COM lever da i ytterst beste velgående.
De _fungerer_ enda (det gjør DOS-programmer også), men det betyr ikke at
det teknologier Microsoft i disse dager investerer tid og krefter på.
http://news.com.com/2100-1046_3-5148148.html
-----
Speaking at the Developing Software for the Future Microsoft Platform
conference in Queen Elizabeth II Conference Centre here Monday,
Microsoft software architect Don Box said the company will not invest
much more in Component Object Model (COM) and Distributed Compound
Object Model (DCOM)--Microsoft's mechanisms for sharing objects between
programs.
Instead, Box said, programs will use managed services based on the
Extensible Markup Language to communicate with each other.
-----
--
Be seeing you.
Alf P. Steinbach
> On Sat, 26 Jun 2004 01:40:11 GMT, al...@start.no (Alf P. Steinbach)
> wrote:
>
> >> [...]
> >>
> >> >Jeg mener det nok er tryggere å bruke .NET-varianten enn Win32-varianten
> >> >av Delphi i dag, siden Microsoft er såpass forutsigbar at de ikke
> >> >skrinlegger hele .NET-rammeverket over natta (slik Borland kunne gjøre).
>
> >> Det er kanskje liten sjanse for at de gjør det med .NET, men de har da
> >> skrinlagt drøssevis av teknologier over natta. OLE, DDE, COM, +++.
>
> >OLE og COM lever da i ytterst beste velgående.
>
> De _fungerer_ enda (det gjør DOS-programmer også),
Å dra disse inn i samme kontekst er helt feil.
Du kan ikke lage noe mer enn leketøys-ting i Windows uten å bruke COM og
OLE (og faktisk er det selv for leketøys-ting, spesielt i scripting,
svært vanskelig å komme utenom OLE-teknologi, nemlig OLE automasjon).
Du er jo selv en av de ivrigste brukerne av WTL...
> men det betyr ikke at
> det teknologier Microsoft i disse dager investerer tid og krefter på.
>
> http://news.com.com/2100-1046_3-5148148.html
>
> -----
> Speaking at the Developing Software for the Future Microsoft Platform
> conference in Queen Elizabeth II Conference Centre here Monday,
> Microsoft software architect Don Box said the company will not invest
> much more in Component Object Model (COM) and Distributed Compound
> Object Model (DCOM)--Microsoft's mechanisms for sharing objects between
> programs.
>
> Instead, Box said, programs will use managed services based on the
> Extensible Markup Language to communicate with each other.
Hallo? Noen hjemme? Markedsføring har ingenting med noe som helst å
gjøre, og R&D innsats har ingenting med skrinlegging av teknologier å
gjøre -- hvis det trengtes R&D for COM/OLE så ville vi ikke brukt det.
Thore Karlsen
wrote:
>> >> [...]
>> >>
>> >> >Jeg mener det nok er tryggere å bruke .NET-varianten enn Win32-varianten
>> >> >av Delphi i dag, siden Microsoft er såpass forutsigbar at de ikke
>> >> >skrinlegger hele .NET-rammeverket over natta (slik Borland kunne gjøre).
>> >> Det er kanskje liten sjanse for at de gjør det med .NET, men de har da
>> >> skrinlagt drøssevis av teknologier over natta. OLE, DDE, COM, +++.
>> >OLE og COM lever da i ytterst beste velgående.
>> De _fungerer_ enda (det gjør DOS-programmer også),
>Å dra disse inn i samme kontekst er helt feil.
>
>Du kan ikke lage noe mer enn leketøys-ting i Windows uten å bruke COM og
>OLE (og faktisk er det selv for leketøys-ting, spesielt i scripting,
>svært vanskelig å komme utenom OLE-teknologi, nemlig OLE automasjon).
Jeg bruker (dessverre) COM hver dag, men at det idag gjennomsyrer alt
betyr ikke så mye. Med tanke på bakoverkompatibilitet kommer det
naturligvis til å henge rundt lenge, men det er ikke fremtiden ifølge
MS. Til sammenligning kan man fremdeles lage applikasjoner i VCL, men..
>Du er jo selv en av de ivrigste brukerne av WTL...
Ja, og Win32 er heller ikke noe satsningsområde for Microsoft, så tiden
vil vise når det ikke lenger er forsvarlig å starte ny utvikling i det.
>> men det betyr ikke at
>> det teknologier Microsoft i disse dager investerer tid og krefter på.
>>
>> http://news.com.com/2100-1046_3-5148148.html
>>
>> -----
>> Speaking at the Developing Software for the Future Microsoft Platform
>> conference in Queen Elizabeth II Conference Centre here Monday,
>> Microsoft software architect Don Box said the company will not invest
>> much more in Component Object Model (COM) and Distributed Compound
>> Object Model (DCOM)--Microsoft's mechanisms for sharing objects between
>> programs.
>>
>> Instead, Box said, programs will use managed services based on the
>> Extensible Markup Language to communicate with each other.
>Hallo? Noen hjemme? Markedsføring har ingenting med noe som helst å
>gjøre, og R&D innsats har ingenting med skrinlegging av teknologier å
>gjøre
De sier jo rett ut at de vil erstatte COM med en annen teknologi i
fremtiden. COM er ikke død, men det ser ikke ut til å ha mye fremtid.
Det kommer fremdeles til å eksistere, og folk kommer fremdeles til å
bruke det, men MS kommer til å fokusere på andre ting som kommer til å
ta plassen til COM.
>hvis det trengtes R&D for COM/OLE så ville vi ikke brukt det.
Neida, for alle teknologier vi bruker til daglig er fullmodne og trenger
ikke mer arbeid. Derfor kan man trygt også bruke VCL, for hvis det hadde
trengt R&D hadde ingen brukt det idag. Og om Borland slutter å utvikle
VCL har man jo fremdeles de gamle verktøyene som støtter det.
--
Be seeing you.
Alf P. Steinbach
>
> De sier jo rett ut at de vil erstatte COM med en annen teknologi i
> fremtiden. COM er ikke død, men det ser ikke ut til å ha mye fremtid.
> Det kommer fremdeles til å eksistere, og folk kommer fremdeles til å
> bruke det, men MS kommer til å fokusere på andre ting som kommer til å
> ta plassen til COM.
Bah. Det Don Box gjorde var å snakke om SOAP og relaterte teknologier
som erstatning for DCOM (gammelt nytt) og legge det fram som om det var
noe helt nytt og fantastisk som ville komme i Longhorn. Markedsføring.
Muligens trengs det. Jeg var med på et møte med Microsoft Norge for
min daværende arbeidsgiver (veldig stooooooort konsulentselskap, et
som ikke het DC) der Microsoft la fram visjonene for .NET og XML-
baserte tjenester. Problemet var at alle seniormanagerne som var med
der hadde funnet ut på forhånd hva de skulle lytte etter, ikke bare
personlig men oppskrevet og systematisk sett fra deres øyne, og så skrev
de opp i etterkant av møtet like "systematisk" hvilke av punktene MS
hadde kommet inn på -- og ignorerte alt resten, det vil si 99,7%.
Kanskje klarer Don Box å trenge gjennom slik forutinntatthet og direkte
teknologisk inkompetanse, men han har oddsene mot seg, tror jeg.
Thore Karlsen
wrote:
>> De sier jo rett ut at de vil erstatte COM med en annen teknologi i
>> fremtiden. COM er ikke død, men det ser ikke ut til å ha mye fremtid.
>> Det kommer fremdeles til å eksistere, og folk kommer fremdeles til å
>> bruke det, men MS kommer til å fokusere på andre ting som kommer til å
>> ta plassen til COM.
>Bah. Det Don Box gjorde var å snakke om SOAP og relaterte teknologier
>som erstatning for DCOM (gammelt nytt) og legge det fram som om det var
>noe helt nytt og fantastisk som ville komme i Longhorn. Markedsføring.
Men det skremmende er at Microsoft i fullt alvor synes slike ting er nye
og fantastiske, lenge etter at resten av verden gjesper av det. Og når
de først legger seg bak en ny teknologi har de en tendens til å gå helt
av skaftet. Stikkordet for neste generasjon verktøy er XML. Overalt.
Uansett om det er fornuftig eller ei.
>Muligens trengs det. Jeg var med på et møte med Microsoft Norge for
>min daværende arbeidsgiver (veldig stooooooort konsulentselskap, et
>som ikke het DC) der Microsoft la fram visjonene for .NET og XML-
>baserte tjenester. Problemet var at alle seniormanagerne som var med
>der hadde funnet ut på forhånd hva de skulle lytte etter, ikke bare
>personlig men oppskrevet og systematisk sett fra deres øyne, og så skrev
>de opp i etterkant av møtet like "systematisk" hvilke av punktene MS
>hadde kommet inn på -- og ignorerte alt resten, det vil si 99,7%.
>
>Kanskje klarer Don Box å trenge gjennom slik forutinntatthet og direkte
>teknologisk inkompetanse, men han har oddsene mot seg, tror jeg.
Hos managere eller internt i MS? Etter å ha snakket med flere utviklere
og managere hos MS virker det som om de også er som du beskriver. Veldig
buzzword-fikserte, og fokuserer altfor mye på det neste hotte på
bekostning av støtte av det gamle. Jeg har slitt veldig med det, og har
virkelig latt dem få høre hva jeg mener om det. (Og jeg er ikke den
eneste.) Microsoft dropper gammel teknologi og gamle produkter lett som
bare faen, det er det ingen tvil om, og når de dropper det er det veldig
lite håp om å bli hørt selv om det er et kritisk problem.
--
Be seeing you.
Tor Iver Wilhelmsen
> Men det skremmende er at Microsoft i fullt alvor synes slike ting er nye
> og fantastiske, lenge etter at resten av verden gjesper av det. Og når
> de først legger seg bak en ny teknologi har de en tendens til å gå helt
> av skaftet. Stikkordet for neste generasjon verktøy er XML. Overalt.
> Uansett om det er fornuftig eller ei.
Jeg sluttet å ta Microsoft på alvor i slike sammenhenger etter at en
eller annen tekniker derifra presterte å stå foran en samling
Java-utviklere og hevde at det å bruke .Nets klasse- og
metodeattributter (som f. eks. [Serializable] i C#) var
"aspektorientert programmering".
Dette inkluderte da opptil flere utviklere med god kjennskap til
AspectJ og annen AOP-teori...
Man skal jo ikke lese mye av Microsofts egen dokumentasjon for å
skjønne at det er lite annet enn metadata man kan spørre etter med
introspection.
Alf P. Steinbach
Det er litt aspect-ting der inne, en generell metodeanrop-interceptor.
_Men_: det er den interne implementasjonen. Den er ikke tilgjengelig
for vanlige programmører.
Geir Harris Hedemark
> De sier jo rett ut at de vil erstatte COM med en annen teknologi i
> fremtiden. COM er ikke død, men det ser ikke ut til å ha mye fremtid.
> Det kommer fremdeles til å eksistere, og folk kommer fremdeles til å
> bruke det, men MS kommer til å fokusere på andre ting som kommer til å
> ta plassen til COM.
Dette begynner å bli et problem for bransjen.
Dersom det er slik at verktøy- og operativsystemleverandørene baserer
seg på forsert utskifting av teknologier hvert tredje år eller så for
utskiftingens skyld - da må alle løpe etter og gjøre nye investeringer
i den nye teknologien. Dersom det ikke tilføres signifikante nye
forbedringer vil dette være en investering med dårlig nytteverdi.
Det har en negativ effekt på bunnlinja til firmaer som ofte allerede
har problemer.
Geir
Thomas Hansen
<stu...@molden.net> left his sanity behind and proclaimed:
[snipped_a_ton_with_code]
Vel, mange vil argumentere at akkurat det at du IKKE KAN gjøre det der
i Java er en FEATURE!
Akkurat som at mange kaller mangelen på deterministic implicit
destruction av objekter og mangelen på multiple inheritence i C#/Java
som en feature...
Jeg personlig ler RÅTT av at manglende støtte for MI defineres som en
feature!
Men det er nå bare meg da!
;)
Thomas Hansen
Nordgård-Hansen) left his sanity behind and proclaimed:
[snip]
>samme katastrofale feilene som C++ gjorde i sin tid, og ender opp som
>et like lite egnet verktøy for å programmere med.
TULLING!
Thomas Hansen
<ge...@dod.no> left his sanity behind and proclaimed:
>Thore Karlsen <s...@6581.com> writes:
>> Spørsmål: Utvikler dere programvare som kun skal brukes internt i
>> bedriften?
>
>Vi utvikler for det meste programvare som vi drifter for kundene våre,
>ja.
>
>Jeg tror ikke jeg klarer å følge tankerekka di. Kan du forklare litt
>nærmere?
>
>Geir
Har du 90 000 kunder som skal kjøre systemet ditt har du ikke RÅD til
å drite i "jern" kostnadene...
;)
Thomas Hansen
<borud...@borud.no> left his sanity behind and proclaimed:
[snip]
>det er i alle fall slik jeg opplever språkene i praksis.
Vel, gjør dette i Java...
namespace SmartWin
{
template<template<typename> class Base, class Parent>
class WidgetFactory;
/// DateTimePicker Control class
/** \ingroup WidgetControls
* \WidgetUsageInfo
* Class for creating a DateTimePicker control.<br>
*/
template<class Parent>
class WidgetDateTimePicker :
public virtual Widget,
public MessageMapControl<Parent, WidgetDateTimePicker<Parent> >,
private virtual TrueWindow,
// Aspects
public AspectSizable<Parent, WidgetDateTimePicker<Parent>,
MessageMapControl<Parent, WidgetDateTimePicker<Parent> > >,
public AspectFont,
public AspectVisible,
private virtual private_::AspectBase
{
friend class WidgetFactory;
/*...etc...*/
C++ handler om MAKT til å gjøre noe på en spesifikk måte, og på samme
måte som "nuclear fision" kan være kjipt i henda på Gadaffi/Saddam
eller Bush kan den også gjøre mange kule ting i henda på de "rette"
folka...
Koden over illustrerer forøvrig minst ** 3 ** ting som Java folk bare
kan DRØMME om i våte drømmer (hvis de hadde vært lure nok til å vite
hva det er og hva det handler om... ;) )
Thomas Hansen
left his sanity behind and proclaimed:
[snip]
>I kroner og øre eller i tapt ytelse? Hvis man i tillegg legger
>til at syntaks-bloaten til C#
Mulig poeng her...
> etterhvert gjør koden umulig
>å vedlikeholde (akkurat som C++), kommer man opp i en liten
>formue.
>Delegater,
men...
Delegates har i C# 2.0 ingen forskjell i footprint sammenlignet med
virtual functions (de er optimalisert 50 ganger eller no' sånt i følge
MS)
> operator-overloading,
Du skal være rimelig full for å klare å få høyere footprint på grunn
av "operator overloading" støtte...
>versjonering av virtuelle
>funksjoner, pass-by-reference av enkle typer, pekere,
>structs på stack,
Hva er bakdelen her?!? (ut ifra et memory/CPU footprint)
> eksplisitt struct layout (tilsvarende
Akkurat DET er vel ikke så "dårlig" for ytelsen...
>byte-pakking og unioner i C),
>integrert COM og COM+,
Nok en gang hvordan får du dårligere ytelse ved å gi støtte for å
kjøre kode som kanskje er native?
>pekere,
>og snart også C++ liknende templates
Generics heter de og vil øke hastigheten på f.eks. collections med en
faktor på opptil sånn ca. en zillion!
For ikke å nevne at du vil få "type sikre" collections og slipper å
tenke på å caste en båt til ei ku...
Men Java folk syns vel kanskje at det også er en fordel...
;)
>gjør C#-kode til en
>potensiell katastrofe. Alle disse "forbedringene" i forhold
>til Java har ingen annen annen effekt enn å gjøre det enklere
>å skrive dårlig kode. På grunn av syntaks-bloaten som C#
>legger opp til kan man for bli sittende med en floke
>som aldri kan nøstes opp -- og man må starte helt på nytt.
>
Syntaks er et spørsmål om "tro og religion", men ytelse er noe konkret
som kan måles og veies og en eksakt ting...
De fleste tingene du ramset opp ovenfor ØKER hastigheten til C# i
forhold til Java...
Jeg tror det er Quake II eller noe sånt som faktisk er portert til
Managed C++ (altså CLR), tviler for at vi vil se noe lignende med Java
i den nærmeste fremtiden...
;)
Når det er sagt er jeg helt enig i at C# er tregt og i mange
sammenhenger kommer med alt for stort memory/CPU footprint for å kunne
være brukbart som problemløsning på de respektive problemene, men å
sammenligne det med Java og si at det er tregt syns jeg er å gå litt
for langt...
Sjekk ut C# - Petstore porten til Microsoft for videre ytelse
sammenligninger mellom C# og Java...
Thomas Hansen
<stu...@molden.net> left his sanity behind and proclaimed:
>On Fri, 18 Jun 2004 09:11:43 +0000, Alf P. Steinbach wrote:
>
>> C# er etter min oppfatning langt bedre som opplæringsspråk enn Java, og
>> også til profesjonell anvendelse innen for eksempel Windows GUI, men et
>> språk er mer enn kun språkdefinisjonen og hvor enkelt det er...
>
>Hvilket verktøy bør brukes til profesjonell Windows GUI
>programmering?
>
>- Visual C++, MFC og ATL
>- Visual C++, ATL og WTL
>- Borland C++ Builder, VCL
>- Borland Delphi, VCL
>- Visual Basic 6
>- Visual Basic .NET
>- Microsoft C#, Windows Forms
>- Mono C#, GTK#
>- C++, Qt
>- C++, wxWidgets
>- C++, FLTK
>- C++, FOX
>- C++, GTKMM
>- C, GTK+
>- C, WinAPI
>- Python, wxWidgets
>- Java, AWT og Swing
>- Java, Eclipse og SWT
>- J# .NET
>- J++ og MFC
http://smartwin.sourceforge.net
>
>Eller noen annet?
>
>
>Sturla Molden
Geir Harris Hedemark
> Har du 90 000 kunder som skal kjøre systemet ditt har du ikke RÅD til
> å drite i "jern" kostnadene...
Når det gjelder rangesjekking - jo, det burde være vist ikke er så
farlig, ref tidligere postinger om ytelse.
Geir
Geir Harris Hedemark
> Syntaks er et spørsmål om "tro og religion", men ytelse er noe konkret
> som kan måles og veies og en eksakt ting...
> De fleste tingene du ramset opp ovenfor ØKER hastigheten til C# i
> forhold til Java...
Du må jo bare være totalforelsket i assembly.
Geir
Lars Haugseth
* Thomas Hansen <youJerk...@iHateYou.com> wrote:
|
| Generics heter de og vil øke hastigheten på f.eks. collections med en
| faktor på opptil sånn ca. en zillion!
| For ikke å nevne at du vil få "type sikre" collections og slipper å
| tenke på å caste en båt til ei ku...
| Men Java folk syns vel kanskje at det også er en fordel...
Hvis du skal fortsette å kritisere Java bør du kanskje følge litt
bedre med i timen. Java 1.5 har støtte for Generics.
--
Lars Haugseth
Vetle Roeim
<youJerk...@iHateYou.com> wrote:
[...]
> Jeg tror det er Quake II eller noe sånt som faktisk er portert til
> Managed C++ (altså CLR), tviler for at vi vil se noe lignende med Java
> i den nærmeste fremtiden...
> ;)
<URL: http://www.bytonic.de/html/jake2.html >
--
It's not a bug, it's the future.
Sturla Molden
> Delegates har i C# 2.0 ingen forskjell i footprint sammenlignet med
> virtual functions (de er optimalisert 50 ganger eller no' sånt i følge
> MS)
De kan være optimalisert så mye de vil. Man lager ikke et
robust programmeringsspråk ved å legge til nye nøkkelord.
Hvorfor skal man bruke funksjonspekere til objektorientert
programmering?
http://www.2famouslyrics.com/o/oystein-sunde/kjekt-a-ha.html
>> operator-overloading,
> Du skal være rimelig full for å klare å få høyere footprint på grunn
> av "operator overloading" støtte...
Man får ikke større "footprint". Men man får mer kompleks syntaks.
>>versjonering av virtuelle
>>funksjoner, pass-by-reference av enkle typer, pekere,
>>structs på stack,
> Hva er bakdelen her?!? (ut ifra et memory/CPU footprint)
Bakdelen "ut ifra et memory/CPU footprint"? Det vet jeg
ikke.
Det er et spørsmål om syntaksforsøpling.
>> eksplisitt struct layout (tilsvarende
> Akkurat DET er vel ikke så "dårlig" for ytelsen...
>>byte-pakking og unioner i C),
>>integrert COM og COM+,
> Nok en gang hvordan får du dårligere ytelse ved å gi støtte for å
> kjøre kode som kanskje er native?
Man kan gjøre slike ting uten å legge til en drøss med
nøkkelord i språket.
>>pekere,
>>og snart også C++ liknende templates
> Generics heter de og vil øke hastigheten på f.eks. collections med en
> faktor på opptil sånn ca. en zillion!
På bekostning av lesbarhet?
Templates (slik de finnes i C++) blander inn funksjonell
programmering i noe som er ment å være et objektorientert
språk.
> For ikke å nevne at du vil få "type sikre" collections og slipper å
> tenke på å caste en båt til ei ku...
Både C# og Java er pedantisk typesikre språk, også uten templates.
> Syntaks er et spørsmål om "tro og religion", men ytelse er noe konkret
> som kan måles og veies og en eksakt ting...
> De fleste tingene du ramset opp ovenfor ØKER hastigheten til C# i
> forhold til Java...
Nei.
> Jeg tror det er Quake II eller noe sånt som faktisk er portert til
> Managed C++ (altså CLR), tviler for at vi vil se noe lignende med Java
> i den nærmeste fremtiden...
Så du har ikke hørt om Jake2
http://www.bytonic.de/html/jake2.html
> Når det er sagt er jeg helt enig i at C# er tregt og i mange
> sammenhenger kommer med alt for stort memory/CPU footprint for å kunne
> være brukbart som problemløsning på de respektive problemene, men å
> sammenligne det med Java og si at det er tregt syns jeg er å gå litt
> for langt...
Jeg har ikke sagt det er "tregt". Spørsmålet om C# er "tregt"
er for øvrig meningsløst ettersom det avhenger av maksinvaren
og .NET-runtimen. C# er verken rask eller treg.
S.M.
Sturla Molden
> Vel, mange vil argumentere at akkurat det at du IKKE KAN gjøre det der
> i Java er en FEATURE!
Du begynner altså å forstå hva det dreier seg om.
> Akkurat som at mange kaller mangelen på deterministic implicit
> destruction av objekter og mangelen på multiple inheritence i C#/Java
> som en feature...
"Garbage collection" er en del av språkene C# og Java. Det
er ingenting i vegen for å la en metode frigjøre ressurser
hvis du ikke har tid til å vente.
> Jeg personlig ler RÅTT av at manglende støtte for MI defineres som en
> feature!
class top
{
}
class A : public top
{
}
class B : public top
{
}
class C : public B, public C
{ // hei, to topper!?!
}
Virkelig lurt det der ...
S.M.
Sturla Molden
> class C : public B, public C
> { // hei, to topper!?!
> }
Det skulle selvsagt være:
class C : public B, public A
{ // hei, to topper!?!
}
Geir Harris Hedemark
> > For ikke å nevne at du vil få "type sikre" collections og slipper å
> > tenke på å caste en båt til ei ku...
> Både C# og Java er pedantisk typesikre språk, også uten templates.
Jeg tror det Thomas tenker på er forskjellen mellom kompileringsfeil
og runtimefeil.
Jeg er enig med han i at runtimefeil er kjekt å unngå - dersom det er
det han mener, da.
Geir
Torkel Holm
Han tenkte sikkert på CLOS.
cl-user(59): (progn
(defclass top () ())
(defclass a (top) ())
(defclass b (top) ())
(defclass c (a b) ()))
#<standard-class c>
cl-user(60): (defgeneric foo (top)
(:method ((obj top))
(print "top")
(values))
(:method ((obj a))
(print "a")
(call-next-method))
(:method ((obj b))
(print "b")
(call-next-method)))
#<standard-generic-function foo>
cl-user(61): (foo (class-prototype (find-class 'c)))
"a"
"b"
"top"
--
Torkel Holm
stu...@molden.net
> Jeg tror det Thomas tenker på er forskjellen mellom kompileringsfeil
> og runtimefeil.
> Jeg er enig med han i at runtimefeil er kjekt å unngå - dersom det er
> det han mener, da.
De fleste runtimefeil som kan oppdages av kompilatoren bør
kompilatoren oppdage. Ada95 er vel det språket som har
kommet lengst i så måte. Men selv Ada er ikke idiotsikker,
jfr. Ariane 5 flight 501. Programmererne prøvde å kaste en
double til en short (eller hva de nå heter i Ada), og dette
resulterte i en overflow exception. For å gjøre programmet
mest mulig "effektivt" hadde ESAs ingenører valgt å ikke
fange opp dette unntaket. Dette resulterte i at Arianes
"self destruct sequence" ble utløst. Historiens dyreste bug?
S.M.
Alf P. Steinbach
Programmet fungerte slik det skulle i henhold til spesifikasjonen.
Feilen var administrativ: at programmet ble tatt over fra opprinnelig
kontekst som spesifikasjonen var laget for, til den nye raketten,
uten analyse og testing (det sparte mye penger, det...).
Hvis jeg ikke husker helt feil var det samme feilårsak for romfergene,
og basert på egne erfaringer er den feilårsaken framtredende i de
60 til 70% av offentlige IT-prosjekter som tryner. Administratorer tar
innersvinger fordi de tjener på det på kort sikt. Og når de negative
konsekvensene kommer, som de gjør, har vedkommende allerede høstet sin
personlige fordel (innenfor budsjett og tid, whatever) og har steget i
gradene til å ta seg av noe med enda større "fallhøyde".
Thomas Bakketun
> Vel, mange vil argumentere at akkurat det at du IKKE KAN gjøre det der
> i Java er en FEATURE!
> Akkurat som at mange kaller mangelen på deterministic implicit
> destruction av objekter og mangelen på multiple inheritence i C#/Java
> som en feature...
Mangel på multippel arv kan være litt irriterende i noen tilfeller, men
arv er i utgangspunktet spagettikode. Med multippel arv kan det virkelig
bli rot i spagettien.
Det som virkelig er tragisk med Java er disse native typene, som
bla. innbærer tall med fast lengde. Hvorfor er ikke også begrense
strenger til maks. 256 tegn?
--
Roten til alt vondt er egen syntaks for attributter.
Tor-Einar Jarnbjo
news:cbhud09ub5i3iotgc...@4ax.com:
> Koden over illustrerer forøvrig minst ** 3 ** ting som Java folk bare
> kan DRØMME om i våte drømmer (hvis de hadde vært lure nok til å vite
> hva det er og hva det handler om... ;) )
Siden det sikkert er mange Java-utviklere her som ikke forstår C++-syntaxen
i eksemepelet ditt, hadde det vel ikke vært så dumt om du forklarte hva du
mener.
Tor-Einar
stu...@molden.net
> Har du 90 000 kunder som skal kjøre systemet ditt har du ikke RÅD til
> å drite i "jern" kostnadene...
Det kommer helt an på systemet. Har du hørt om Mathworks?
S.M.
Nils Petter Vaskinn
Og derfor kan du _velge_ å la være å bruke MI i de språkene som
støtter det. Og ihvertfall C++ har mulighet til å hindre at du får
to topper når du arver fra to klasser med felles forelder. Eller du kan
velge å ha to topper i de tilfellene der det er ønskelig
--
NPV
What did that old blonde gal say? -- That is the part you throw away.
Tom Waits - The part you throw away
Tor Iver Wilhelmsen
> Og derfor kan du _velge_ å la være å bruke MI i de språkene som
> støtter det. Og ihvertfall C++ har mulighet til å hindre at du får
> to topper når du arver fra to klasser med felles forelder. Eller du kan
> velge å ha to topper i de tilfellene der det er ønskelig
Språk uten MI: Smalltalk, Java, C# - og man savner det ikke.
Språk med MI:
Perl: Veldefinert orden mhp. arverekkefølge
Python: Veldefinert orden mhp. arverekkefølge
Eiffel: Veldefinert på alle måter
C++: Ack!
Ditt trekk i den evinnelige debatten.
Husk: Ethvert problem "løst" med MI kan løses med SI.
Rolf Rander Næss
[ Tor Iver Wilhelmsen, 2004 Jun 30, 18:13]
> Språk med MI:
> Perl: Veldefinert orden mhp. arverekkefølge
> Python: Veldefinert orden mhp. arverekkefølge
> Eiffel: Veldefinert på alle måter
> C++: Ack!
Common Lisp ;-)
> Husk: Ethvert problem "løst" med MI kan løses med SI.
Noe jeg ofte har lyst på er "mixin-classes". Den eneste
java-teknikken jeg kjenner til for å få til dette er å la mix-klassene
være definert som et interface, og la implementasjonen av dette kalle
(delegere til) et hjelpeobjekt. Dette synes jeg er så mye
klipp-og-lim at jeg aldri gidder. (Derimot har jeg en gang laget en
preprosessor som genererer delegerings-koden for meg).
rolf rander
"Any sufficiently advanced technology is indistinguishable from magic."
-- Arthur C. Clarke
Thomas Bakketun
> Språk med MI:
> Perl: Veldefinert orden mhp. arverekkefølge
> Python: Veldefinert orden mhp. arverekkefølge
> Eiffel: Veldefinert på alle måter
> C++: Ack!
Og JavaScript!
<url: http://www.crockford.com/javascript/inheritance.html >
Nils Petter Vaskinn
> Nils Petter Vaskinn <m...@privacy.net> writes:
>
>> Og derfor kan du _velge_ å la være å bruke MI i de språkene som
>> støtter det. Og ihvertfall C++ har mulighet til å hindre at du får
>> to topper når du arver fra to klasser med felles forelder. Eller du kan
>> velge å ha to topper i de tilfellene der det er ønskelig
>
> Språk uten MI: Smalltalk, Java, C# - og man savner det ikke.
>
> Språk med MI:
> Perl: Veldefinert orden mhp. arverekkefølge
> Python: Veldefinert orden mhp. arverekkefølge
> Eiffel: Veldefinert på alle måter
> C++: Ack!
Vel etter det jeg har forstått _kan_ du sette opp et hierarki med
multippel arv veldefinert i C++
> Ditt trekk i den evinnelige debatten.
Nei. Jeg har hittil _valgt_ å holde meg unna MI fordi jeg ikke har hatt
et problem som har rettferdiggjort den ekstra påpasseligheten jeg måtte
ha.
> Husk: Ethvert problem "løst" med MI kan løses med SI.
Jepp.
Poenget mitt er at å trekke fram at MI er umulig som en fordel med ett
språk virker lite gjennomtenkt når alt du trenger å gjøre for å
oppnå det samme i språk med MI er å ikke bruke MI.
Alf P. Steinbach
>
> Poenget mitt er at å trekke fram at MI er umulig som en fordel med ett
> språk virker lite gjennomtenkt når alt du trenger å gjøre for å
> oppnå det samme i språk med MI er å ikke bruke MI.
Og dermed er vi tilbake til "gode begrensninger som virker frigjørende",
for å fritt sitere meg selv i en tidligere posting i denne tråden.
Enkelte begrensninger er nemlig slik at uten at du _vet_ at de er på
plass kan du ikke nyttiggjøre deg fordelene. Jeg nevnte filer som enkle
bytestrømmer (selvsagt søkbare) i Unix. Mens Windows NTFS har filer med
multiple bytestrømmer og annet rart, ut fra tankegangen "alt bør være
tillatt eller i det minste mulig", som gjør dem vanskeligere å håndtere
og betyr at enkle, generelle verktøy ikke gjør jobben bra nok.
Begrensningen til kun enkel arv, unntatt av grensesnitt, er dog ikke
nødvendigvis en frigjørende begrensning slik jeg ser det. Eiffel viser
at multippel arv kan være med i et språk uten slike problemer som i C++.
Hovedproblemet i C++ er at man må ta avgjørelser om multiple topp-klasse
instanser er ønsket eller ikke på topp-klasse nivået, ved å bruke eller
ikke bruke ordet virtual ved arv direkte fra topp-klassen, og et annet
hovedproblem er at virtuell arv er komplisert, ineffektivt, og ikke
fullt ut støttet selv i de mest moderne kompilatorene nå 7 år etter
standarden -- for eksempel kombinasjonen kovarians + virtuell arv.
Torkel Holm
(var det noen som kalte på Turing :) )
MI og SI (+ delegering) er abstraksjonsmekanismer som
ikke er semantisk ekvivalente. Hvert til sitt bruk
mener nå jeg da.
Du kan selvsagt alltid gå rundt grøten dersom et språk
ikke tilbyr den abstraksjonen du ønsker.
Mange såkalte patterns er gode eksempler på dette.
F.eks. <<visitor>> vs double dispatch, <<factories>> vs dynamisk
typing, <<strategy>> vs generiske funksjoner,
<<state>> vs dynamisk klasse-endring osv.
Min konklusjon er at jo lettere ulike abstraksjoner
kan tilpasses et språk jo bedre er det.
Hmm, er jeg enig med T. Hansen da?
--
Torkel Holm
Rolf Rander Næss
[ Torkel Holm, 2004 Jul 1, 14:16]
> Mange såkalte patterns er gode eksempler på dette.
> F.eks.
> <<visitor>> vs double dispatch,
> <<factories>> vs dynamisk typing,
> <<strategy>> vs generiske funksjoner,
> <<state>> vs dynamisk klasse-endring osv.
Tja, jeg ser «state» (om vi nå snakker om s 305 i GOF) som en teknikk
for å utnytte statisk typesjekk til å sikre at du overholder
protokollen for bruk av tilstandsmaskinen. Jeg har sett et c++-api
som utnyttet dette til et «embedded språk» slik at c++-kompilatoren kan
kontrollere at koden i det indre språket er syntaktisk korrekt.
Har man ikke statisk typing er dette ganske irrelevant. Dynamisk
endring av klasse ser jeg på som noe annet. (Men jeg har enda ikke
kommet på noen praktisk bruk av dette utover at det er veldig kjekt i
utviklingsfasen, så her er jeg på litt tynn is).
Alf P. Steinbach
>
> [ Torkel Holm, 2004 Jul 1, 14:16]
> > Mange såkalte patterns er gode eksempler på dette.
> > F.eks.
> > <<visitor>> vs double dispatch,
> > <<factories>> vs dynamisk typing,
> > <<strategy>> vs generiske funksjoner,
> > <<state>> vs dynamisk klasse-endring osv.
>
> Tja, jeg ser «state» (om vi nå snakker om s 305 i GOF) som en teknikk
> for å utnytte statisk typesjekk til å sikre at du overholder
> protokollen for bruk av tilstandsmaskinen.
Host kremt har jeg misforstått State fullstendig eller er det noe som
har gått meg hus forbi eller (lenge siden leste GoF, har ikke boken).
Har akkurat for ikke mange dagene siden snekret en generisk C++
implementasjon av det jeg trodde var State-mønsteret, kun for å sjekke
at noe annet var generelt nok.
Jeg kan ikke se noen måte som det å dynamisk skifte implementasjons-
objekt bak et grensesnitt skulle kunne sikre at en tilstandsprotokoll
overholdes, men det gjør kanskje muligens koden litt enklere ved at
hvert enkelt tilstandsrepresenterende objekt kun behøver å kjenne til
tilstandene som det skal kunne "gå" til (ved å bytte ut seg selv med
objekt for aktuell ny tilstand).
Faktisk var det eneste halv-fornuftige eksemplet jeg fant på nettet,
etter iherdig søking i flere sekunder (ok, et minutt eller to, minst)
en sak der en maskin i en fabrikk hadde en oppover-nedover skyvedør
foran et hull der man skulle legge inn råvarer, og døren styrtes av én
trykk-knapp som hadde forskjellig virkning avhengig av dørposisjon og
om den var på tur opp eller ned og hvor lenge og om det var noe der.
Men jeg ser adskillig enklere måter å implementere noe slikt på...
Bjorn Borud
|
| Jeg personlig ler RÅTT av at manglende støtte for MI defineres som en
| feature!
eksakt hvorfor egentlig?
-Bjørn
--
more is in vain when less will serve