Gå til innhold

ProgrammeringsBaren! Småprat, om det du elsker!


Anbefalte innlegg

Java er ikke akkurat moderne, det er temmelig tomt for features.

 

Du er veldig glad i å rakke ned på Java, og argumentene dine mot språket er alltid de samme. Gjeeeesp. At Java ikke har operator overloading for eksempel. Jeg har jobbet i flere språk som har dette, men har aldri følt behov for å override en operator. Men men, det betyr kanskje bare at jeg ikke er så flink som deg som tydeligvis bruker dem på annenhver kodelinje du skriver. :p

Det betyr bare at du ikke har fått bruk for operator overloading egentlig. Men det har jeg, spesielt i spillmotoren min som bruker OpenGL. Fordelen blir at en kan bruke vanlig operatorer på vektortyper og matriser.

Du kan rett og slett definere dine helt egne primitive datatyper, for eksempel 16-bit float om du vil. Det går derimot ikke an i Java av to grunner: Du kan ikke definere nye stackallokerte datatyper og du har ikke operator overloading.

 

Og så vidt jeg kan se, er enums i Java hakket kvassere enn i C#. Kan du utdype hvorfor enums i Java ikke er "skikkelige" som du påstår?

 

Werner

Kvassere er et fint ord, enums i Java er mye strengere enn de er i C#. I C# kan du fint sette en verdi i en enum som ikke er definert i den, og du kan ikke definere funksjoner eller andre egenskaper på den. Enums i Java er rett og slett java som bare oversetter det du skriver til en klasse, men masse final felt som er predefinerte instanser av klassen.

Enums i C# er et integer, ikke noe mer enn det. Dette gjør at du kan bruke dem som bitfelt og bruke verdiene definert i den, istedet for å definerte final integer og bruke en int som en gjør i Java. Enums i Java blir allokert på heap, til tross for at det har samme funksjonen som et integer ville hatt. I C# blir de allokert på stack.

 

Det er ting som irriterer meg i C# også, for eksempel at det ikke er noen språkdefinert array slicing der (som er en kjekk sak i Python) men jeg kan ikke komme på én eneste fordel Java har fremfor C#, men jeg kan telle ganske mange ting som jeg savner i Java i forhold til C#, som struct, enum som ikke er ubrukelig, delegates, paltform invoke, usignerte datatyper, lambda uttrykk...

 

Hvis det er noe galt med C#, og det er det, så har ikke jeg noen problemer med å innrømme det, men Java er langt mer grisete: Et standardbibliotek som snart har flere deprecated klasser og funksjoner enn riktige funksjoner, et GUI bibliotek som er mildt sagt dårlig designet, språk som mangler mye moderne og ikke så veldig moderne fasiliteter.

Det var opprinnelig kun et scriptspråk som ble oversatt runtime, det er det ikke lenger, men språksyntaksen gjenspeiler dette svært dårlig, blant annet ved å ha en heapallokert enum type, og ingen mulighet til å definere egne stackdatatyper, som begge er typisk for oversatte språk.

Lenke til kommentar
Videoannonse
Annonse
Er det noen studenter her inne som har eller kjenner noen som har deltatt i google sitt summer of code opplegg? Det må jo være noen norske studenter som er med i år. Neste år skal jeg gå over lik for å være med, skal bruke hele året på å smiske med en eller annen svær mentor organisasjon. :wee: På tide med en sommerjobb som er litt mer relevant enn butikk...

Med "smiske" så håper jeg du mener bidra.

Lenke til kommentar

Jeg er ikke ny i Java, jeg har holdt på med det siden 1996. Ikke så intensivt som de fire siste årene, men likevel nok til at jeg føler at jeg kjenner relativt godt til Javas utvikling, og modningsprosess. 13 år er lenge i IT-sammenheng, og jeg jobber forstatt med Java. Jeg har jobbet med mange andre språk parallelt med dette, f.eks. C, C++, C#, Python, Perl, Pascal, osv.

 

Men dette er ikke noen religionskrig for meg. Det er mye som har gått galt i Java-verdenen underveis. De første EJB-standardene er jo et godt eksempel på hvordan ting IKKE skal gjøres. Tenk på hvor mange milliarder dollar som er investert i prosjekter som benyttet disse råtne standardene. Og fortsatt tjener konsulenter grisemange penger på å holde disse prosjektene i live.

 

Men det har jaggu også skjedd mye bra i Java-verdenen. Ta bare Spring-rammeverket for eksempel. Og ting som Hibernate og andre lignende prosjekter. Det er morsomt å jobbe med Java i dag. Ti ganger morsommere enn det var for fem år siden, og sikkert tjue ganger morsommere enn det var for ti år siden.

 

Selvsagt kan man si mye negativt om Java, som man kan si mye negativt om ethvert programmeringsspråk. Jeg vet om folk som kan skrive bøker fulle av argumenter for hvorfor man ikke skal bruke C# eller Java. Men jeg synes det er uinteressante diskusjoner. Hva et språk mangler i forhold til et annet er fryktelig uinteressant for meg. Hva man kan få til i C# og ikke i Java gir jeg beng i, for jeg får til det jeg ønsker å få til i Java. Jeg bryr meg pent lite om at enkelte ting kanskje er lettere å skrive i C#.

 

Selv jobber jeg med utvikling og vedlikehold av ganske komplekse forretningsapplikasjoner, jeg skriver ikke shadere. Så jeg har kanskje ikke de samme behovene som deg.

 

Hvis vi tar operator overloading som et eksempel. Selv om det er en feature i språket, så er det like mye et "pattern". I programmeringens verden er det drøssevis av mer eller mindre kjente patterns som folk bruker eller ikke bruker. De "politisk korrekte" blar i pattern-bøker hver gang de skal løse en oppgave, og så har du de som bare løser oppgaven, og som senere finner ut at, hei, dette ligner jo på det og det patternet. Selv tilhører jeg kanskje den siste typen.

 

Det jeg vil fram til, er at hvis man er dyktig i et språk, så er ikke mangelen på en eller annen språklig feature nødvendigvis en hindring. Jeg tviler på at en C#-programmerer gjør en bedre jobb enn en Java-programmerer, bare fordi språket har en bestemt feature.

 

Uff dette ble mye toillprat på en gang. Jeg får vel sette punktum snart.

 

Men til slutt vil jeg tipse deg om Scala. Det er et kjekt språk, der alt er objekter og ting som operatorer er metoder. Scala kompilerer til Java bytecode, og kan således benyttes i ethvert Java-prosjekt. Man kan også benytte seg av alle Java-API'er som finnes.

 

Sentrale deler av Twitte ble faktisk utviklet i Scala.

 

Werner

Lenke til kommentar
Det jeg vil fram til, er at hvis man er dyktig i et språk, så er ikke mangelen på en eller annen språklig feature nødvendigvis en hindring. Jeg tviler på at en C#-programmerer gjør en bedre jobb enn en Java-programmerer, bare fordi språket har en bestemt feature.

Hvilke features og hvilke ting et språk gjør enkelt eller vanskelig vil forme programmererens tankegang. Det kan være positivt og/eller negativt.

At man kan jobbe seg rundt manglende features i et språk betyr ikke nødvendigvis at det er den riktige tingen å gjøre.

Lenke til kommentar
Men til slutt vil jeg tipse deg om Scala. Det er et kjekt språk, der alt er objekter og ting som operatorer er metoder. Scala kompilerer til Java bytecode, og kan således benyttes i ethvert Java-prosjekt. Man kan også benytte seg av alle Java-API'er som finnes.

Har brukt det over et år nå og er relativt fornøyd med språket, men er veldig omfattende å sette seg inn i hvis en kommer fra Java/C/C++. Spesielt hvis en ikke har noe som helst erfaring med funksjonell programmering og avanserte typesystemer. Ytelsen kan også være litt variabel hvis en benytter funksjoner som verdier eller når floats og ints auto-konverters til objekter. Neste versjon av Scala skal visst komme med noen forbedringer her.

 

Det er heller ikke et stabilt språk og er under konstant utvikling. Det høres kanskje drastisk ut men språket er bygd opp i to deler: kjernespråket og API-et. Scala har også den egenskapen at ting kan "se ut som" det tilhører kjernespråket. F.eks. er ikke "for-loop" en del av kjernespråket men kall til iterator-objektets foreach og filter metoder. Scala får ofte kritikk for å være for komplekst, men det er egentlig kompleksiteten til API-et det ofte er snakk om. Det fine er at dette er bare kode som kan skrives om eller utvides og er hvorfor Scala er under konstant forandring.

 

Et eksempel fra noe kode for en type-parametrisert matriseklasse som jeg bruker som base for diverse andre klasser:

object Matrix2
{
 protected def copy[T](from: Array[T], to: Array[T]) {
assert(from.length == to.length)
Array.copy(from, 0, to, 0, from.length)
 }
}

class Matrix2[T](val rows: Int, val cols: Int, elemsToCopy: Option[Array[T]])
{
 assert(rows > 1 && cols > 1)
 val elems = new Array[T](rows * cols)

 elemsToCopy match {
case Some(from) => Matrix2.copy(from, elems)
case None =>
 }

 override def toString() = "(Matrix2 rows:" + rows + " cols:" + cols + ")"
 def apply(i: Int): T = elems(i)
 def apply(x: Int, y: Int): T = elems(y * cols + x)
 def update(i: Int, value: T) { elems(i) = value }
 def update(x: Int, y: Int, value: T) { elems(y * cols + x) = value }
}

Notis:

- T er matrisens datatype for elementene som vanligvis settes til Byte eller Double, aka bytt alle forekomster av T i koden under med Byte/Double etc. Eksempel: var rgbaImage = new Matrix2[int](256, 256, null)

- alle klasser kan ha et "kompis-objekt" hvor alt av statiske ting defineres

- siden kompilatoren kan resonnere seg frem til korrekt type trenger en ofte ikke angi disse for variabler og returtypen til metoder.

- (val rows: Int, val cols: Int, copyFrom: Option[Array[T]]) er argumentene til primær-kontruktøren. Når argumentene angis med val eller var vil de bli attributter i klassen. Det går an å angi "enkle" tilleggskonstruktører i klassen, men disse må til slutt delegere til primær-konstruktøren.

- val = konstant, var = variabel, def = metode

- primær-konstruktørs koden er på samme nivå som attributt- og metodedeklarasjoner

- apply håndterer indeksering

- update håndterer indeksering med oppdatering

 

(fikk gjort noen forbedringer i samme slengen av originalkoden min... hehe)

Endret av hishadow
Lenke til kommentar
  • 2 måneder senere...

Trenger litt hjelp med BNF(ikke EBNF) for følgede linjer med operatorer hvor definisjonen av Char allerede er gitt.

 

1. + (choice) Valg left-asso binær

2. . (prikk) Concat left-asso. binær

3. * (stjerne unary postfix

 

Presedens i stigende rekkefølge, hvordan blir BNF grammatikken her som også tar høyde for parenteser?

Hva de forskjellige operatorene gjør er egentlig likegyldig, det har ingenting å si for grammatikken.

Lenke til kommentar

Jeg skal sjekke en string, det må bare være store bokstaver og bokstavene A-F. Er dette en elegant eller rotete måte å gjøre det på; (Java)

public static boolean gyldigeKarakterer(String a){
	int t = 0; 
	char[] listen = a.toCharArray();
	for (int i = 0; i < listen.length; i++){
		t = (int)listen[i];
		if(!(t >=0x41 && t <=0x46)){
			return false;
		}
	} 
	return true; 
}

 

Kan det gjøres raskere/bedre?

Lenke til kommentar
  • 2 uker senere...

Får inn grunnprinsippene, det er greit nok. Det jeg sliter med er den kreative tankeprosessen når jeg skal skrive et større program. Det går ikke raskt nok. Har en øving som krever 100-200 linjer, det blir smertefullt. Det er det første ja, og jeg må lære prolog før semesteret er over. Skal sies at foreleseren åpnet med å si "Ja, det er høy strykprosent på dette kurset". :D Det går bra, jeg hadde bare aldri innbilt meg at et funksjonelt språk skulle være vanskeligere enn objekt orientert programmering.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...