Gå til innhold

C# et bedre språk enn Java?


Anbefalte innlegg

Videoannonse
Annonse

90% er å dra litt hardt i, men det er ingen tvil om at det er veldig utbredt i bruk.

Av eldre programmer er Cobol mest brukt, men i mer moderne tid er det Visual basic (desverre), Java, og etterhvert nå også mye VB.NET/C#.

 

Jeg tror og håper at C++ vil bli mindre brukt, for jeg tror bransjen ville tjent, og spart mye på det.

Endret av GeirGrusom
Lenke til kommentar

Heh, jeg er glad for at moderator ikke slettet alle inleggene mine, for da hadde jeg rett og slett sluttet å poste her.

 

Men uansett; jeg mener at både Java og C# er et ypperlig valg fremfor C++ når det gjelder GUI, fordi C++ faktisk skaper så mange fallgruver som koster så mye tid å rette på i ettertid.

 

Selvom jeg foretrekker C#, pga. et mer gjennomført språk, ville jeg valgt Java fremfor C++ hvilken dag som helst.

 

Fordelen med C#, er at man kan bruke C biblioteker direkte, og at man faktisk har pekere (som har vist seg faktisk å være ekstremt hendige til grafikkhåndtering. Brukte det senest til å skrive en algoritme som gjort fargebilder sort/hvitt)

Lenke til kommentar
I C++ og C# blir man ikke tvunget til å catche exception... De aller fleste exceptions kan man uansett gardere seg mot, om du har gjort det "riktig"

Man må ikke fange alle exceptions i Java. Det man derimot må gjøre er å deklarere om en metode kaster en gitt Exception-type videre, med throws-klausulen i metodesignaturen.

 

Jeg ser du gir eksempler som fanger selveste Exception, og ikke en spesiell subklasse av denne. Det vitner ikke om veldig erfaring med Java.

 

Strings i java er også grenseløst irriterende av flere grunner for det første er jo string en klasse, og ikke en datatype, så den må skrives med stor S.

 

Så Java er dårlig fordi String skrives med stor S? String er en klasse i C# også, selv om du skriver de med liten s.

 

Autoboxing som grusom refererer til kom ikke før i Java 1.2

Feil, det kom i Java 5 (1.5).

Nei, autoboxing kom i 1.2 ;)

 

Nei, du tar feil. Autoboxing og unboxing kom i Java 5 (1.5). http://java.sun.com/j2se/1.5.0/docs/relnot...res.html#boxing. Sukk.

 

(fikset en skriveleif)

Endret av steingrim
Lenke til kommentar
I C++ og C# blir man ikke tvunget til å catche exception... De aller fleste exceptions kan man uansett gardere seg mot, om du har gjort det "riktig"

Man må ikke fange alle exceptions i Java. Det man derimot må gjøre er å deklarere om en metode kaster en gitt Exception-type videre, med throws-klausulen i metodesignaturen.

 

Jeg ser du gir eksempler som fanger selveste Exception, og ikke en spesiell subklasse av denne. Det vitner ikke om veldig erfaring med Java.

9536536[/snapback]

 

Det vitner om design-feil i Java, fordi man ikke nødvendigvis alltid er interresert i å catche exceptions, og den enkleste måten å unngå gjøre det på, er å catche Exception.

code bloat er noe drit, men hvorfor skal man bruke masse tid på å catche exceptions individuelt som ALDRI kommer til å dukke opp?

Lenke til kommentar

Jeg har verken mye erfaring med Java eller C#/C/C++, men jeg skulle godt ønske Java hadde overloading...

 

Og sånn sett er det helt logisk for meg at String er objekter, fordi det egentlig er en array av chars, og da må man ty til objekter. Det virker logisk for meg at alle programmeringsspråk ikke kan behandle flere chars (String) som noe annet et objekter simpelthen fordi de består av flere medlemmer. Og da er det bare bra at man ikke prøver å "skjule" de som en primitiv. Men overloading hadde jo vært fint her da. :yes:

 

Ellers synes jeg Java er et enkelt og flott verktøy til å lage programmer, men hvis jeg skal peke til andre poster jeg har undertegnet på, så har det nok sine svakheter. Så for min del, vil jeg nok bruke Java helt til svakhetene begynner å bli for mange.

 

En nokså nøytral mening fra min side altså. :!: Ingenting å kritisere...

Lenke til kommentar
Det vitner om design-feil i Java, fordi man ikke nødvendigvis alltid er interresert i å catche exceptions, og den enkleste måten å unngå gjøre det på, er å catche Exception.

code bloat er noe drit, men hvorfor skal man bruke masse tid på å catche exceptions  individuelt som ALDRI kommer til å dukke opp?

9536749[/snapback]

 

Nei, det er et bevisst valg fra Java designerne.

Som sagt tidligere i tråden, i Java må en eksplisitt deklarere hvilke exceptions en metode kan kaste. Dersom ingen er deklarert kan ingen kastes.

I motsetning har en C++ hvor en kan deklarere hvilke exceptions en metode kan kaste, og alle andre ville være ugyldige. Og i utgangspunktet kan metoden kaste hva som helst.

 

Alle vet at en uhåndtert exception er en feil i programmet. Java forsøker å hindre deg i gjøre slike feil.

 

Og som sagt lenger opp. Har du ingen ambisjoner om å håndtere exceptions i metoden du skriver så får du bare sørge for at samme metode kaster exception videre..

 

void foo(int a) throws [...]Exception
{
/* denne koden kan da vel ikke feile? */
...
}

Lenke til kommentar

C# er kanskje et bedre språk enn Java sånn rent syntaksmessig, men Java er jaggu meg en langt mer robust og omfattende plattform. Man kan krangle opp og ned i evigheten om hva som er best, men industrien har jo tydeligvis lagt sin elsk på Java de siste årene. Hvor mange tunge aktører i Norge er det som har mest fokus på .NET? Ikke mange. På Java? Accenture, Steria, Bouvet, Google, FairIsac, Objectware, Objectnet, Enonics osv. osv.

 

Java-zealots er en gjeng med gjøker, og de skulle fått mer deng av foreldra da de var små.

Det er ingenting som irriterer meg mer enn java-zealots (bortsett fra kanskje PHP-zealots). Bevitner bare om lite eller ingen erfaring med andre språk.

eg hatet alt det. Med god grunn. Når jeg kommer til det nivået hvor jeg får "NullReferenceException : Enter" når jeg trykker på enter i tekst-editoren, da forstår jeg med en gang at det er bare tull. Java er ment for teletubbies, ikke for ordentlige programmerere.

og så...

Jeg er dataingeniør, jeg jobber med dette som profesjonell programvareutvikler hver eneste dag

Hahahaha. Greit nok at du liker .NET, men ser ikke poenget med å slenge rundt med din giftige tunge fordi du enten har svært tunge preferanser eller eventuelt vanskelig for å beherske noe annet. Du fremstår ikke som profesjonell når du tydeligvis har så store problemer med noe resten av industrien bygger fremtiden med.

 

Edit: Måtte få lagt til at hvis problemet må å skrive et par linjer ekstra en gang i blant, pga. mangler i språket utgjør en stor del av din arbeidsmengde, så er det ikke særlig komplekse problemer du jobber med. For store web-applikasjoner er det rammeverkene som gjør forskjell på natt og dag.

Endret av Geofrank
Lenke til kommentar

Bransjen bygger mest på C++, som er mye verre en Java, jeg tror ikke dette har noe som helst med hva som er best å gjøre.

 

Jeg tror derimot det har mye med at Java og C++ læres på de fleste skolene.

 

Noen ting kan man rett og slett ikke gjøre i Java, som går fint an i C#, f.eks. kan du forsøke å få til OpenGL/OpenAL extensions i Java, det er ikke mulig fordi Java ikke kan bruke C biblioteker.

 

Dermed må all OpenGL/OpenAL kode skrives i et annet språk, det er derimot ikke nødvendig i C#.

 

Hahahaha. Greit nok at du liker .NET, men ser ikke poenget med å slenge rundt med din giftige tunge fordi du enten har svært tunge preferanser eller eventuelt vanskelig for å beherske noe annet. Du fremstår ikke som profesjonell når du tydeligvis har så store problemer med noe resten av industrien bygger fremtiden med.

 

:nei:

 

Han sier ikke at han har problemer med det, han sier at Java har mye idiotiske ting ved seg, og ærlig talt forstår jeg ikke hva det er å diskutere eller angripe han personlig på den måten.

Lenke til kommentar
Bransjen bygger mest på C++, som er mye verre en Java, jeg tror ikke dette har noe som helst med hva som er best å gjøre.

Det er vel de mer spesialiserte delene av bransjen som bruker C++ for tiden. Jeg syns forøvrig det er et brilliant språk. Men nå til dags er det langt flere Java-utviklere der ute. Mest til web-utvikling, men det er nå en gang slik at det er det brorparten av industrien driver med i disse dager.

 

Han sier ikke at han har problemer med det, han sier at Java har mye idiotiske ting ved seg, og ærlig talt forstår jeg ikke hva det er å diskutere eller angripe han personlig på den måten.

Hehe, det er han som sier jeg er en gjøk, en teletubbie og at jeg ikke er en ordentlig programmerer :p

 

Noen ting kan man rett og slett ikke gjøre i Java, som går fint an i C#, f.eks. kan du forsøke å få til OpenGL/OpenAL extensions i Java, det er ikke mulig fordi Java ikke kan bruke C biblioteker.

JOGL?

Endret av Geofrank
Lenke til kommentar
Et dårlig designvalg, på samme måte som at funksjonen til enum er svært begrenset ved at de ikke kan brukes som bitfields fordi enums er klasser, og ikke primitiver, er et dårlig designvalg.

 

Jeg skjønner ikke denne kritikken. Dette er jo trivielt å løse på andre måter.

 

Vanligvis er kritikken rundt Java enums at de er alt for kraftige. Du kan gjøre litt i overkant spesielle ting med de, som for eksempel:

enum Algorithm {
   FAST(ImplementationFactory.getInstance("FAST")),
   ACCURATE(ImplementationFactory.getInstance("ACCURATE")),
   EFFICIENT(ImplementationFactory.getInstance("EFFICIENT"));

   private final Implementation implementation;

   Algorithm(final Implementation implementation) {
       this.implementation = implementation;
   }

   public double calculate() {
       return implementation.calculate();
   }
}

 

Thread.Sleep() throws ThreadSleepException

ThreadSleepException som CronoMan nevnte.

9543056[/snapback]

 

Nei, Thread.sleep() i likhet med noen andre metoder i Thread (som wait(), join()) kan kaste InterruptedException. Det skjer f.eks. om du kaller Thread.interrupt().

 

Hva vil du heller skal skje når sleep() blir avbrutt. Avslutte som om ingenting har skjedd?

 

Igjen, du svarer ikke på hvorfor det er et dårlig design valg å tvinge programmereren til å behandle unntakstilstander, du bare sier at det er et dårlig design valg, og det er jeg fundamentalt uenig med deg i.

Lenke til kommentar

Hvis du kaller Thread.Sleep så må du forvente at det kan skje, men da fanger du også opp denne exceptionen, men i de aller, aller fleste tilfeller er dette bare overflødig kode.

 

I C# bruker jeg som oftest enums til dette:

 

public enum SizeDirection
{
 West = 0x01
 North = 0x02,
 East = 0x04,
 South = 0x08,
 NorthWest = North | West,
 NorthEast = North | East,
 SouthWest = South | West,
 SouthEast = SouthEast
}

public void CheckDirection(SizeDirection size, Control ctrl, Point offset)
{
 if((size & SizeDirection.North) == SizeDirection.North)
 {
   // Sjekk om North er satt
   ctrl.Location = new Point(ctrl.Location.X, ctrl.Location.Y + offset.Y);
   ctrl.Size = new Size(ctrl.Size.Width, ctrl.Size.Height - offset.Y);
 }
 else if((size & SizeDirection.West) == SizeDirection.West)
 {
   ctrl.Location = new Point(ctrl.Location.X + offset.X, ctrl.Location.Y);
   ctrl.Size = new Size(ctrl.Size.Width - offset.X, ctrl.Size.Height);
 }
 //etc.
}

 

Istedet for enten å måtte bruke et int, og huske verdiene selv, eller bruke en switch for alle retninger.

 

Men det var litt fancy at du kan gjøre sånn i Java, selv kan jeg ikke helt se nytten av det.

 

Når det gjelder OpenGL extensions, så løser ikke JOGL problemet i det hele tatt.

Hvis du er interresert i å bruke GL_NV_vertex_array_range er du avhengig at JOGL har implementert det, i C# kan du fint implementere dette selv, fordi C# kan kommunisere med C biblioteker, og har tilgang til pekere (selvom jeg kun har hatt bruk for dette til grafikkbehandling, og ser ikke nytten til det egentlig i vanlige programmer)

Lenke til kommentar
Hvis du kaller Thread.Sleep så må du forvente at det kan skje, men da fanger du også opp denne exceptionen, men i de aller, aller fleste tilfeller er dette bare overflødig kode.

 

Nettopp.

Her er du inne på noe viktig; "I de aller fleste tilfeller". Dette handler nettopp om å håndtere unntakstilfellene, rett og slett for å unngå ubehagelige bugs.

Vi programmerere er late (per definisjon), og vi tvinges til å ta stilling til dette (vel, man kan jo alltids "try { ... } catch (Exception e) { /* bæ! */ }", men det er *dumt*).

 

I C# bruker jeg som oftest enums til dette:

 

<snip />

 

Istedet for enten å måtte bruke et int, og huske verdiene selv, eller bruke en switch for alle retninger.

 

 

Neida. Et Java eksempel vil bare se litt annerledes ut (og en smule mer objektorientert).

 

enum SizeDirection {
   West(0x01),
   North(0x02),
   East(0x04),
   South(0x08),
   NorthWest(0x01 | 0x02),
   NorthEast(0x02 | 0x04),
   SouthWest(0x08 | 0x04),
   SouthEast(0x08 | 0x01);

   private int direction;

   SizeDirection(int dir)
   {
       direction = dir;
   }

   bool isNorth() { return (dir & North.direction == North.direction); }
   bool isSouth() { return (dir & South.direction == South.direction); }
   (...)
}

 

Så kaller du size.isNorth() eller isSouth() etc i CheckDirection.

Alternativt kan du aksessere size.direction direkte og bruke koden slik den er (hvis den ikke er private).

Lenke til kommentar
Når det gjelder OpenGL extensions, så løser ikke JOGL problemet i det hele tatt.

Hvis du er interresert i å bruke GL_NV_vertex_array_range er du avhengig at JOGL har implementert det, i C# kan du fint implementere dette selv, fordi C# kan kommunisere med C biblioteker, og har tilgang til pekere (selvom jeg kun har hatt bruk for dette til grafikkbehandling, og ser ikke nytten til det egentlig i vanlige programmer)

 

Denne muligheten har du Java også. Se på Java Native Interface (JNI).

Lenke til kommentar

Må nok si jeg er litt uenig med deg angående GUI i java. Synes selv det er morro å lage GUI i java, selv om det jo er litt tungvint, er vel trolig den delen jeg liker. Styre med hvor de forskjellige komponentene skal stå (De forskjellige layoutene som er med i Java duger ikke til noe) og lage egne komponenter er rett og slett morro, selv om det er tidkrevende.

Lenke til kommentar

Som Dj_Offset har nevnt er tankegangen i java ikke er helt lik tankegangen i C#. Man kan stort sett gjøre de samme tingene uten nevneverdig ekstraarbeid - hvis det er noe ekstraarbeid i det hele tatt.

 

Har selv gått Java -> C -> C++ -> Java veien på skolen, så jeg har derfor nødvendigvis mest erfaring med Java, men jeg har også litt erfaring fra C og C++.

 

Det jeg har sett av C# er at det er svært likt Java på mange måter, og hva man trives best med av de to er nok det språket man har mest erfaring med.

 

En av fordelene jeg ser med java er at veldig mye av bibliotekene som finnes er OpenSource, det samme gjelder rammeverkene, noe som gjør det enkelt og billig å anskaffe og gjenbruke kode.

 

Det må kanskje samtidig sies at java har gjort ett kvantesprang med EJB3 i forhold til tidligere versjoner (EJB1.1 og EJB2) som begge kan defineres som XML-hell, etc, etc...

 

På web-siden så har firmaet jeg jobber i nylig tatt i bruk EJB3+JSF+Seam og er veldig fornøyd med det i forhold til steinaldermetodikken vi hoppet over fra. (java det også)

 

På java-applikasjon gui siden så bruker vi Swing, noe som fungerer helt fint når du har en GUI-editor som du finner i f.eks JBuilder. Designer i XYLayout og gjør om til GridBagLayout når vi er fornøyd med designet, så det passer i alle oppløsninger. :)

 

... en liten addenum der - jo nyere jbuilder versjon, jo flere bugs finner du i GUI-editoren :p Unntaket er de eclipse baserte, som har kastet den gamle gui editor koden.

Lenke til kommentar
Min mening etter å ha programmert i både java og C# er at C# er morro å kode i, java er no realt møk.

Ta feks GUI i c#. Utrolig lett å kode med Visual Studios, Java tar lang tid og er undødvendig avansert.

Gjelder egentlig alt syns jeg. Hater java.

9566614[/snapback]

 

Tja, hvis du vil bruke ett program til å tegne GUI med, så finnes det jo IDE'er for java som lar deg bygge opp gui på forholdsvis lik måte som VS (f.eks. netbeans)...

 

Kan ikke sammenligne hvor enkelt det er, da jeg aldri har brydd meg med den type GUI i C# (har jobbet med XNA, og da bygges det opp på en litt annen måte ;))..

 

Mitt inntrykk etter å ha brukt c# en stund er at det har en god del forbedringer fra java, men at java er langt fra så mangelfullt og dårlig som en del her vil ha det til.

 

Og hvorvidt det å "måtte" håndtere exceptions er bra eller ei er vel heller opp til ens preferanse.

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å
×
×
  • Opprett ny...