Gå til innhold

C# et bedre språk enn Java?


Anbefalte innlegg

Videoannonse
Annonse
Du har jo det problemet at Java er et dårlig språk, med mye feil og mangler (mangler delegates, mangler unsigned datatyper, enum kan ikke brukes som bitfield, switch kan ikke brukes på strings etc.)

9450472[/snapback]

 

At man mangler unsigned datatyper (Har du ofte behov for unsigned datatyper?)

eller at man ikke kan bruke string i switch statment gjør da ikke språket dårlig, men man må velge andre metoder for å løse problemene på sånn som det er med alle andre språk.

 

Java har sitt bruksområdet som mange andre språk, men kan selvfølgelig ikke måle seg med andre lavere språk på mange områder. Eller andre språk på enkelte områder.

 

Jeg har stor respekt for dine meninger GeirGrusom, men her er jeg dypt uenig med deg.

Lenke til kommentar

Jeg mener Java har design feil, mange er blitt rettet (automatisk boxing/unboxing), men flere gjenstår.

 

At byte er signed, ser jeg på som helt på jordet, faktisk så banebrytende fjernt, at jeg vet ikke hva jeg skal si.

At enums ikke kan brukes til bitfields, fordi en enum blir en klasse, og kan kun ha én verdi, ser jeg på som helt håpløst, at delegates mangler, og man må skrive event listener og det sølet der, ser jeg på som helt idiotisk, jeg tror ikke jeg vet om noen andre språk som har en like dårlig løsning på events som Java har.

At Java er proppfullt av "deprecated" klasser, må være en konsekvens av dårlig planlegging.

Hvorfor alle exceptions må catches, er det få som har et godt svar på.

 

Jeg kan ikke skjønne at det er noe å være uenig i.

Lenke til kommentar
Jeg mener Java har design feil, mange er blitt rettet (automatisk boxing/unboxing), men flere gjenstår.

 

At byte er signed, ser jeg på som helt på jordet, faktisk så banebrytende fjernt, at jeg vet ikke hva jeg skal si.

At enums ikke kan brukes til bitfields, fordi en enum blir en klasse, og kan kun ha én verdi, ser jeg på som helt håpløst, at delegates mangler, og man må skrive event listener og det sølet der, ser jeg på som helt idiotisk, jeg tror ikke jeg vet om noen andre språk som har en like dårlig løsning på events som Java har.

At Java er proppfullt av "deprecated" klasser, må være en konsekvens av dårlig planlegging.

Hvorfor alle exceptions må catches, er det få som har et godt svar på.

 

Jeg kan ikke skjønne at det er noe å være uenig i.

9459305[/snapback]

 

Java er grunnleggende feil laget, om noen er uenig i det, er det fordi de rett og slett har får lite kjennskap til java vs andre språk (C/C++/C# :) )

 

I java 1.4.1, var det en ting som irriterte meg noe så inn i granskauen, Socket.SetTimeout(); (eller timeout generelt sett)

 

når man kaller Socket.Connect() blir tråden holdt igjen (logisk nok) og det stod svart på hvitt i dokumentasjonen at Socket.Connect() throws SocketTimeoutException. Så jeg skrev en normal

 

try {
Socket.Connect();
}
catch(SocketTimeoutException e)
{
System.out.println("Der fikk vi en timeout gitt :" + e.toString());
}
catch(Exception e)
{
System.out.println("wtfruit : " + e.toString());
}

 

MEN SocketTimeoutException fantes ikke.

ARGH?

 

Og Exceptions må selvfølgelig, som grusom sier, catches.

Om man har gjort alle forhåndsregler, hvorfor fortsatt bli tvunget til å catche dem?

 

F.eks, Thread.Sleep() throws ThreadSleepException.

kode
kode
kode
kode
try { Thread.Sleep() } catch(Exception e) {}

 

hvor ofte får man en exception fra Sleep()? Aldri?

Det er så bunnløst irriterende å måtte gjøre det som egentlig er en linje med kode til 3-6 linjer

 

At java også bruker interfaces til å "simulere" events er også helt tragisk.

Dette innebærer selvfølgelig at man må klippe og lime unødvendig mye kode om man skal implementere events (fordi du må definere alle funksjoner i en interface (det er jo hele poenget med dem)) som minner veldig over events i VB6 som så mange klagde over. Klager javabrukere over dette i Java? Nei. Hvorfor ikke? Rett og slett fordi de ikke vet bedre.

 

Over til java programmering cross-platform :

Om du har vært borti Java ME (MicroEdition, det samme som .NET Compact Framework) så har du garantert merket at denne ikke følger java-standarden i det hele tatt. Entrypointet i et ME-program fungerer på en helt annen måte, den er ikke static; når du kjører en MIDlet, vil java automatisk generere en instans av "hovedobjektet" (det som extender MIDlet) for deg. Som er helt latterlig.

 

Java kan heller ikke returnere en verdi fra main(). Hvorfor ikke? Fordi hele strukturen i java er feil. Man kan ikke lage int main(). Dette er vel antageligvis fordi et javaprogram ikke har mulighet til å iterere gjennom funksjoner i en klasse

 

Jeg har mye erfaring med de aller fleste mest brukte språk, og Java er helt overbevisende taperen. Eneste grunnen til at det fortsatt eksisterer er fordi Sun betaler folk for å bruke det. Hele Java er gjennomsyret av at det er lite planlagt og ufullstendige og ikke-fungerende funksjoner og biblioteker. Det er ikke noe som heter "standarder"; alt fungerer helt forskjellig.

 

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. Java har ikke noen operator overloading, så for å sammenligne to stringer, må man bruker String.Equals(String string2);. HVOR MANGE GANGER TRENGER MAN Å SJEKKE REFERANSEN MELLOM TO STRENGER? Dette er jo fallgruve nr.1 blant java-programmerere. Selv de som har holdt på med java i årevis gjør denne feilen. Heh, nok en veldig irriterende mangel.

 

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

Så om du ville bruke dem til noe vettugt før det, måtte du ta Integer a = new Integer(3);... :w00t:

Heh. Særdeles klovnete.

 

Og det er en million flere slike ting.

 

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.

Lenke til kommentar
FUD

 

Og der forsvant min respekt for dine fremtidige poster i dette forumet. Orker ikke å kommentere det du skrev engang.

9471145[/snapback]

 

Jeg har jobbet med både Java og C#. Både som applikasjoner; Java SE og Java ME, og på web (JSP).

Tidligere, så gikk alt arbeidet mitt ut på Java. Jeg hatet det. Alt tok lang tid, alt var så teit laget, alt var bare rør og ingenting funka uten videre.

Nå jobber jeg som webutvikler med ASP.NET : Aldri hatt det bedre.

 

Jeg bryr meg lite om hva du syns om mine standpunkter på java; jeg vet altfor godt hva java går ut på, og hvorfor man bør styre unna det så langt det er mulig. Og i min erfaring er de som benytter java veldig uerfarne og har lite erfaring på konkurrerende felter. Jeg kan de aller fleste språk og rammeverk, og Java er desidert det dårligste. Om du tror du kan diskutere det så vet jeg ikke helt hvilken verden du kommer fra. Java, VB og PHP er religion. Er ingen tvil om det. Det finnes mange ting som vil ende i mer robuste løsningen, men zealots kjenner ingen grenser. Jeg for min del holder meg til C/C++ og C#. Jeg ser ingen nåværende grunn til å benytte noe annet. Hele poenget med C# and the likes of it er at det skal redusere utviklingstiden, det er såkalt Rapid Development Tool, det skal gjøre utviklingen raskere. I java er det så mange unntak fra regler og forskjellige funksjonsmetoder i forskjellige klasser og biblioteksløsninger at man nærmest bare taper tid på å bruke det. Du bruker mer tid på å lese dokumentasjone enn faktisk utvikling. Om du ikke har sittet i timesvis for å forstå hvorfor ikke Ant-builden bygger noenting, og du ikke får tak i 3.-parts bibliotekene fordi de kanskje ligger på feil sted, eller at web.xml-filen gir helt latterlige kompileringsfeil, og du sliter med å få publisha websiden til tomcat, så lyver du.

Om du ikke har sittet og irritert deg over at javax.swing og java.awt fungerer på totaaaalt forskjellige måter, og eneste muligheten å oppgradere ville være å skrive hele dritten på nytt, eller at du har sittet og irritert deg over at du ikke kan bruke et javaprogram i en bat eller bash-script fordi den naturlig ikke vil kunne returnere verdi på noen annen måte enn å skrive ut til konsollen, så lyver du.

Om du aldri har irritert deg grønn over at public classes må ligge i en egen javafil, så du får en million javafiler der du gjerne skulle lagt flere klasser i flere filer så lyver du.

Du kan bruke hva du vil, men jeg vil ikke klage noe mindre av et slikt valg for det.

Om du vil bruke ufattelig mye tid på ting som er gjort på et par minutter i andre språk, be my guest. Om du syns det er greit at du ikke kan benytte biblioteker ment for andre rammeverk, gjør som du vil.

Om du trives med å bruke Eclipse, NetBeans eller Java Studio Creator; så fint for deg.

 

Jeg 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.

Lenke til kommentar
Jeg har jobbet med både Java og C#. Både som applikasjoner; Java SE og Java ME, og på web (JSP).

Tidligere, så gikk alt arbeidet mitt ut på Java. Jeg hatet det. Alt tok lang tid, alt var så teit laget, alt var bare rør og ingenting funka uten videre.

Nå jobber jeg som webutvikler med ASP.NET : Aldri hatt det bedre.

 

Jeg bryr meg lite om hva du syns om mine standpunkter på java; jeg vet altfor godt hva java går ut på, og hvorfor man bør styre unna det så langt det er mulig. Og i min erfaring er de som benytter java veldig uerfarne og har lite erfaring på konkurrerende felter. Jeg kan de aller fleste språk og rammeverk, og Java er desidert det dårligste.

 

Jeg klarer bare ikke å svare noe fornuftig til slike argumenter. Ikke så rart du hater Java så intenst, du har jo misforstått hele konseptet med språket; et språk som i bunn og grunn promoterer robuste multiplatform applikasjoner. Såvidt jeg klarer å forstå utifra postene dine så sliter du også med manglende kunnskap om diverse software designpatterns og jeg kan være enig i at da blir det vanskelig å bruke de forskjellige rammeverk og biblioteker som tilbys for Java platformen effektivt.

Lenke til kommentar
Jeg har jobbet med både Java og C#. Både som applikasjoner; Java SE og Java ME, og på web (JSP).

Tidligere, så gikk alt arbeidet mitt ut på Java. Jeg hatet det. Alt tok lang tid, alt var så teit laget, alt var bare rør og ingenting funka uten videre.

Nå jobber jeg som webutvikler med ASP.NET : Aldri hatt det bedre.

 

Jeg bryr meg lite om hva du syns om mine standpunkter på java; jeg vet altfor godt hva java går ut på, og hvorfor man bør styre unna det så langt det er mulig. Og i min erfaring er de som benytter java veldig uerfarne og har lite erfaring på konkurrerende felter. Jeg kan de aller fleste språk og rammeverk, og Java er desidert det dårligste.

 

Jeg klarer bare ikke å svare noe fornuftig til slike argumenter. Ikke så rart du hater Java så intenst, du har jo misforstått hele konseptet med språket; et språk som i bunn og grunn promoterer robuste multiplatform applikasjoner. Såvidt jeg klarer å forstå utifra postene dine så sliter du også med manglende kunnskap om diverse software designpatterns og jeg kan være enig i at da blir det vanskelig å bruke de forskjellige rammeverk og biblioteker som tilbys for Java platformen effektivt.

9471505[/snapback]

 

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

Lenke til kommentar
Java er grunnleggende feil laget, om noen er uenig i det, er det fordi de rett og slett har får lite kjennskap til java vs andre språk (C/C++/C# :) )

 

Nei, gå og legg deg... dette var utviklet som et forskningsprosjekt nettopp for å lage et bra objektorientert språk (i motsetning til C og C++).

De lykkes ganske bra spør du meg, men de fikk ikke alt helt riktig ved første forsøk.

 

I java 1.4.1, var det en ting som irriterte meg noe så inn i granskauen, Socket.SetTimeout(); (eller timeout generelt sett)

 

Ok, slutt på språk-kritikken, nå er det APIene som skal gjennomgå?

 

når man kaller Socket.Connect() blir tråden holdt igjen (logisk nok) og det stod svart på hvitt i dokumentasjonen at Socket.Connect() throws SocketTimeoutException. Så jeg skrev en normal

 

try {
Socket.Connect();
}
catch(SocketTimeoutException e)
{
System.out.println("Der fikk vi en timeout gitt :" + e.toString());
}
catch(Exception e)
{
System.out.println("wtfruit : " + e.toString());
}

 

MEN SocketTimeoutException fantes ikke.

ARGH?

 

Og, hvilke parametere ga du til connect()?

 

Og Exceptions må selvfølgelig, som grusom sier, catches.

Om man har gjort alle forhåndsregler, hvorfor fortsatt bli tvunget til å catche dem?

 

Man kan ikke ta forhåndsregler mot alle nødvendigvis? Dersom et exception blir kastet ville applikasjonen blitt abortert om den ikke hadde blit fanget opp. Ingenting unikt med Java her.

 

F.eks, Thread.Sleep() throws ThreadSleepException.

kode
kode
kode
kode
try { Thread.Sleep() } catch(Exception e) {}

 

hvor ofte får man en exception fra Sleep()? Aldri?

 

Det har du ikke kontroll på. Den må derfor fanges. Det finnes veldig mange grunner til at sleep skulle ville bli avbrutt (interrupt). Som, f.eks. et signal blir sendt til prosessen.

 

Det er så bunnløst irriterende å måtte gjøre det som egentlig er en linje med kode til 3-6 linjer

 

Javel :)

 

At java også bruker interfaces til å "simulere" events er også helt tragisk.

 

Men likevel synes du det er selvsagt at socket.connect() skal blokkere?? :whistle:

 

Dette innebærer selvfølgelig at man må klippe og lime unødvendig mye kode om man skal implementere events (fordi du må definere alle funksjoner i en interface (det er jo hele poenget med dem)) som minner veldig over events i VB6 som så mange klagde over. Klager javabrukere over dette i Java? Nei. Hvorfor ikke? Rett og slett fordi de ikke vet bedre.

 

Jada, gresset er alltid grønnere på den andre siden... btw, hvilken side er dette en snakker om forresten?

 

Over til java programmering cross-platform :

Om du har vært borti Java ME (MicroEdition, det samme som .NET Compact Framework) så har du garantert merket at denne ikke følger java-standarden i det hele tatt. Entrypointet i et ME-program fungerer på en helt annen måte, den er ikke static; når du kjører en MIDlet, vil java automatisk generere en instans av "hovedobjektet" (det som extender MIDlet) for deg. Som er helt latterlig.

 

Jepp, det er annet API, alright. Skjønner hva du sier, men skjønner ikke problemet...

 

Java kan heller ikke returnere en verdi fra main(). Hvorfor ikke? Fordi hele strukturen i java er feil. Man kan ikke lage int main().

 

Nei, for om en ønsker å returnere en verdi derfra skal en bruke System.exit(foo).

 

Dette er vel antageligvis fordi et javaprogram ikke har mulighet til å iterere gjennom funksjoner i en klasse

 

Den siste setningen der gir ingen mening for meg... Antar at du egentlig mener java.lang.reflection med venner, så du tar sikkert feil ;)

 

Jeg har mye erfaring med de aller fleste mest brukte språk, og Java er helt overbevisende taperen. Eneste grunnen til at det fortsatt eksisterer er fordi Sun betaler folk for å bruke det. Hele Java er gjennomsyret av at det er lite planlagt og ufullstendige og ikke-fungerende funksjoner og biblioteker. Det er ikke noe som heter "standarder"; alt fungerer helt forskjellig.

 

OK. Pek på noe bedre?

 

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. Java har ikke noen operator overloading, så for å sammenligne to stringer, må man bruker String.Equals(String string2);. HVOR MANGE GANGER TRENGER MAN Å SJEKKE REFERANSEN MELLOM TO STRENGER? Dette er jo fallgruve nr.1 blant java-programmerere. Selv de som har holdt på med java i årevis gjør denne feilen. Heh, nok en veldig irriterende mangel.

 

Ganske praktisk om du har en del forutsetninger, spør du meg...

 

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

Så om du ville bruke dem til noe vettugt før det, måtte du ta Integer a = new Integer(3);...  :w00t:

Heh. Særdeles klovnete.

 

Feil, det kom i Java 5 (1.5).

 

Og det er en million flere slike ting.

 

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.

9471071[/snapback]

 

Da sier vi takk til deg... du bærer preg av ikke å skjønne det store bildet :-)

 

-- pragmatisk c/c++ utvikler.

Endret av Dj_Offset
Lenke til kommentar
I tillegg til at jeg selv drev litt med Java da jeg studerte informatikk i hine hårde dager, har jeg kjent både Cronoman og GeirGrusom IRL i snart 24 år, og kan skrive under på at begge har ganske store mengder med erfaring på mange områder innen data, så jeg velger faktisk å sette min lit til at Cronoman har sånn noenlunde peiling på hva han snakker om.

 

OK. jeg kan skrive under på det motsatte...

- er litt usikker på hvor jeg skal signere...

Lenke til kommentar
I tillegg til at jeg selv drev litt med Java da jeg studerte informatikk i hine hårde dager, har jeg kjent både Cronoman og GeirGrusom IRL i snart 24 år, og kan skrive under på at begge har ganske store mengder med erfaring på mange områder innen data, så jeg velger faktisk å sette min lit til at Cronoman har sånn noenlunde peiling på hva han snakker om.

 

OK. jeg kan skrive under på det motsatte...

- er litt usikker på hvor jeg skal signere...

9474451[/snapback]

 

Du kan signere deg i panna med en sprittusj. I likhet med han andre som postet tidligere, kommer ikke du heller med noen reell argumentasjon, bare oppgulp.

 

-1

Ok, slutt på språk-kritikken, nå er det APIene som skal gjennomgå?

 

Javel

 

Jada, gresset er alltid grønnere på den andre siden... btw, hvilken side er dette en snakker om forresten?

 

Jepp, det er annet API, alright. Skjønner hva du sier, men skjønner ikke problemet...

 

Den siste setningen der gir ingen mening for meg...

 

OK. Pek på noe bedre?

 

Dette er jo intet mindre enn tullprat.

Endret av BrunoStergodt
Lenke til kommentar
I tillegg til at jeg selv drev litt med Java da jeg studerte informatikk i hine hårde dager, har jeg kjent både Cronoman og GeirGrusom IRL i snart 24 år, og kan skrive under på at begge har ganske store mengder med erfaring på mange områder innen data, så jeg velger faktisk å sette min lit til at Cronoman har sånn noenlunde peiling på hva han snakker om.

 

OK. jeg kan skrive under på det motsatte...

- er litt usikker på hvor jeg skal signere...

9474451[/snapback]

 

Du kan signere deg i panna med en sprittusj. I likhet med han andre som postet tidligere, kommer ikke du heller med noen reell argumentasjon, bare oppgulp.

 

-1

Ok, slutt på språk-kritikken, nå er det APIene som skal gjennomgå?

 

Javel

 

Jada, gresset er alltid grønnere på den andre siden... btw, hvilken side er dette en snakker om forresten?

 

Jepp, det er annet API, alright. Skjønner hva du sier, men skjønner ikke problemet...

 

Den siste setningen der gir ingen mening for meg...

 

OK. Pek på noe bedre?

 

Dette er jo intet mindre enn tullprat.

9474662[/snapback]

 

Enig. Og det var det som du fjernet i mellom også...

Lenke til kommentar
Java er grunnleggende feil laget, om noen er uenig i det, er det fordi de rett og slett har får lite kjennskap til java vs andre språk (C/C++/C# :) )

 

Nei, gå og legg deg... dette var utviklet som et forskningsprosjekt nettopp for å lage et bra objektorientert språk (i motsetning til C og C++).

De lykkes ganske bra spør du meg, men de fikk ikke alt helt riktig ved første forsøk.

 

Jeg sa : om noen er uenig i det, er det fordi _de_ (ikke sun) har for lite kjennskap til java vs. andre språk.

 

Jeg tror ikke Java var ment for det det er blitt utbygd til nå. Og jeg syns det er altfor tydelig

 

I java 1.4.1, var det en ting som irriterte meg noe så inn i granskauen, Socket.SetTimeout(); (eller timeout generelt sett)

 

Ok, slutt på språk-kritikken, nå er det APIene som skal gjennomgå?

 

Språk og rammeverk er mer eller mindre samme greiene i Java ;)

 

når man kaller Socket.Connect() blir tråden holdt igjen (logisk nok) og det stod svart på hvitt i dokumentasjonen at Socket.Connect() throws SocketTimeoutException. Så jeg skrev en normal

 

try {
Socket.Connect();
}
catch(SocketTimeoutException e)
{
System.out.println("Der fikk vi en timeout gitt :" + e.toString());
}
catch(Exception e)
{
System.out.println("wtfruit : " + e.toString());
}

 

MEN SocketTimeoutException fantes ikke.

ARGH?

 

Og, hvilke parametere ga du til connect()?

 

Parametrene er uinterresante, poenget er at SocketTimeoutException ikke fantes

 

Og Exceptions må selvfølgelig, som grusom sier, catches.

Om man har gjort alle forhåndsregler, hvorfor fortsatt bli tvunget til å catche dem?

 

Man kan ikke ta forhåndsregler mot alle nødvendigvis? Dersom et exception blir kastet ville applikasjonen blitt abortert om den ikke hadde blit fanget opp. Ingenting unikt med Java her.

 

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"

 

F.eks, Thread.Sleep() throws ThreadSleepException.

kode
kode
kode
kode
try { Thread.Sleep() } catch(Exception e) {}

 

hvor ofte får man en exception fra Sleep()? Aldri?

 

Det har du ikke kontroll på. Den må derfor fanges. Det finnes veldig mange grunner til at sleep skulle ville bli avbrutt (interrupt). Som, f.eks. et signal blir sendt til prosessen.

 

Eneste måten jeg kan se de vil skje er om kallende thread tar abort, men man bruker ikke abort, man bruker join. Det er _feil_ å bruke abort, med mindre threaden er uresponsiv i lengre tid (og join vil kalle abortere om den bruker for lang tid) så om man får en ThreadSleepException, så er det programmereren som har gjort noe galt

 

Det er så bunnløst irriterende å måtte gjøre det som egentlig er en linje med kode til 3-6 linjer

 

Javel :)

 

Ja ;)

 

At java også bruker interfaces til å "simulere" events er også helt tragisk.

 

Men likevel synes du det er selvsagt at socket.connect() skal blokkere?? :whistle:

Selvfølgelig skal den blokkere, om du ikke vil den skal blokkere, så bruker du asynkron connect (beginConnect())

 

Dette innebærer selvfølgelig at man må klippe og lime unødvendig mye kode om man skal implementere events (fordi du må definere alle funksjoner i en interface (det er jo hele poenget med dem)) som minner veldig over events i VB6 som så mange klagde over. Klager javabrukere over dette i Java? Nei. Hvorfor ikke? Rett og slett fordi de ikke vet bedre.

 

Jada, gresset er alltid grønnere på den andre siden... btw, hvilken side er dette en snakker om forresten?

 

Dette var en ting VB6-motstandere i sin tid maste ekstremt mye om, hvis man lager en egen kontroll eller modul av ett eller annet slag, må alle events implementeres, enten du bruker dem eller ikke. Ved å bruke pointe-to-member, så kan en event faktisk ha en null-peker ;)

 

Over til java programmering cross-platform :

Om du har vært borti Java ME (MicroEdition, det samme som .NET Compact Framework) så har du garantert merket at denne ikke følger java-standarden i det hele tatt. Entrypointet i et ME-program fungerer på en helt annen måte, den er ikke static; når du kjører en MIDlet, vil java automatisk generere en instans av "hovedobjektet" (det som extender MIDlet) for deg. Som er helt latterlig.

 

Jepp, det er annet API, alright. Skjønner hva du sier, men skjønner ikke problemet...

 

Inkonsekvens. Det er rett og slett ikke sånn programmer funker, og hvorfor gå helt bort fra sin egen standard så fort plattformen byttes?

 

Java kan heller ikke returnere en verdi fra main(). Hvorfor ikke? Fordi hele strukturen i java er feil. Man kan ikke lage int main().

 

Nei, for om en ønsker å returnere en verdi derfra skal en bruke System.exit(foo).

 

Ah, I see... Visste ikke det :p

 

Jeg har mye erfaring med de aller fleste mest brukte språk, og Java er helt overbevisende taperen. Eneste grunnen til at det fortsatt eksisterer er fordi Sun betaler folk for å bruke det. Hele Java er gjennomsyret av at det er lite planlagt og ufullstendige og ikke-fungerende funksjoner og biblioteker. Det er ikke noe som heter "standarder"; alt fungerer helt forskjellig.

 

OK. Pek på noe bedre?

 

C#, D

 

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. Java har ikke noen operator overloading, så for å sammenligne to stringer, må man bruker String.Equals(String string2);. HVOR MANGE GANGER TRENGER MAN Å SJEKKE REFERANSEN MELLOM TO STRENGER? Dette er jo fallgruve nr.1 blant java-programmerere. Selv de som har holdt på med java i årevis gjør denne feilen. Heh, nok en veldig irriterende mangel.

 

Ganske praktisk om du har en del forutsetninger, spør du meg...

 

I C# så kan man bruke == for å sammenligne to strenger, om du vil bruke en spesifikk culture eller case insensitive, bruker man Equals.

 

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

Så om du ville bruke dem til noe vettugt før det, måtte du ta Integer a = new Integer(3);...  :w00t:

Heh. Særdeles klovnete.

 

Feil, det kom i Java 5 (1.5).

 

Nei, autoboxing kom i 1.2 ;)

 

Og det er en million flere slike ting.

 

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.

9471071[/snapback]

 

Da sier vi takk til deg... du bærer preg av ikke å skjønne det store bildet :-)

 

-- pragmatisk c/c++ utvikler.

9474431[/snapback]

 

Jeg skjønner det store bildet altfor godt :) Derfor holder jeg meg til C# og C++. Da slipper jeg å rive meg i håret så altfor ofte ;) Jeg ser sammenhengen mellom VB, Java og PHP-"utviklere", de som har låst seg inn i ett eneste språk. De aller fleste vil rimelig enkelt kunne se at Java har en god del hull.

Microsoft må gi ut all dokumentasjonen sin med VB-kodeeksempler; fordi de som bruker VB gidder ikke engang å kikke på eksempler for C# eller C++...

Så de må ha både og. Jeg vedder på at det samme gjelder for Java og PHP

 

Apropos : I min mening er C# java gjort på riktig måte, så jeg holder meg til det ;)

Lenke til kommentar
Jeg skjønner det store bildet altfor godt :) Derfor holder jeg meg til C# og C++. Da slipper jeg å rive meg i håret så altfor ofte ;)

 

Greit, men da foreslår jeg at du holder deg til VB,BASIC,C#,C++,whatever.. og sparer oss andre for de meningsløse kommentarene dine angående Java; det blir bare for dumt. Jeg syns for eksempel de er mye merkelig i C++, men du ser ikke meg poste mongo innlegg om hvor primitive C++ utviklere er og hvor lite forståelse de har for andre språk. Mange syns Java er et veldig bra språk (meg inkludert) og hvis du ikke klarer å respektere det så syns jeg du heller bør la vær å uttale deg om språket.

 

Poenget mitt er: La oss holde diskusjonen på et noenlunde voksent nivå.

Lenke til kommentar

Hoi!

 

Dette ble en alt for lang post til at jeg gidder å svare helt på den med sitater, men la meg først si at jeg er faktisk enig med deg at C# er et bedre språk en Java. Microsoft hadde naturligvis lært en god del av Java når det ble laget, og siden Sun tvang dem vekk fra å modifisere Java måtte de finne på noe selv. Resultatet ble ikke uventet noe bedre enn Java.

 

Men det jeg ikke skjønner er den særdeles negative holdningen du viser til Java. Jeg ser mange som peker på at C# er bedre enn Java på forskjellige områder, og alle har forsåvidt gode poenger, men ingen av dem peker på disse meningsløse trivialiteter som du peker på lenger oppe i tråden (exception håndtering, interrupt, socket timeout, etc).

 

At Java skal være et av de dårligste språkene du har vært borti, er helt greit for meg. Jeg har vært borti mange værre (C++ er et av dem, IMHO).

 

Til slutt, autoboxing kom i Java 1.5 (se changelog her).

 

-- c++ dev

Lenke til kommentar

Ah, helt enig, C++ er helt udugelig til store prosjekter, da spesielt ting som innvolverer GUI.

 

Mye jobb for å gjøre ting som er trivielle i andre språk.

 

Jobbet med å debugge et program noen andre hadde laget, ganske stort for styring av HD video til forskjellige switcher.

Problemet var at det var et stort sprik i C++ kunnskap blant de som hadde skrevet det, og deler var også laget i C#.

Hele prosjektet kunne fint blitt laget i C#, men av en eller annen latterlig grunn hadde de valgt C++ med ATL.

Lenke til kommentar
Ah, helt enig, C++ er helt udugelig til store prosjekter, da spesielt ting som innvolverer GUI.

 

Mye jobb for å gjøre ting som er trivielle i andre språk.

 

Jobbet med å debugge et program noen andre hadde laget, ganske stort for styring av HD video til forskjellige switcher.

Problemet var at det var et stort sprik i C++ kunnskap blant de som hadde skrevet det, og deler var også laget i C#.

Hele prosjektet kunne fint blitt laget i C#, men av en eller annen latterlig grunn hadde de valgt C++ med ATL.

9484585[/snapback]

 

Prøvd Qt?

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...