mboost-dp1

Sun
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
@arne_v - jeg bliver nødt til at få en forklaring på hvorfor Func<> er "mindre" typesikker? Hvad mener du er forskellen i typesikkerhed på nedenstående?
1)
2)
1)
int Add(int x, int y) { return x + y; }
int Sub(int x, int y) { return x - y; }
int x = 10;
int y = 5;
int r1 = Add(x, y);
int r2 = Sub(x, y);
2)
Func<int, int, int> add = (x, y) => x + y;
Func<int, int, int> sub = (x, y) => x - y;
int x = 10;
int y = 5;
int r1 = add(x, y);
int r2 = sub(x, y);
Windcape (50) skrev:Det ville pynte på din trolling, hvis du rent faktisk vidste hvor lidt cross-platform Java faktisk er :p
Så længe du stadig sidder og fidter med dine NullPointerExceptions, skal du passe på du ikke bevæger dig ud, hvor du ikke kan bunde.
Kom med et eksempel på hvornår java ikke er cross-platform.
#51
Koden i EX1 indeholder 2 metoder ikke 2 delegates.
Det ekvivalente til EX2 må være:
(herefter kaldt EX1M)
Tilbage til det type sikre.
For det første tillader EX2:
sub = add;
i modsætning til EX1M.
Hvis det var enest problem, så var det ikke noget stort problem, fordi ingen ville lave noget sådant kode.
Men prøv og sammenlign EX1M og:
med EX2 og:
I det første får man compile fejl hvis man bytter om på add og sub i kaldet.
I det andet får man bare et forkert resultat.
Fordi at Adder og Suber er forskellige mens Func<int, int, int> og Func<int, int, int> er ens.
Hvis man sender delegates igennem mange metode kald så er det en reel risiko at bytte rundt på nogle argumenter.
Og i traditionel C# bruger delegates netop typisk til at send gennem metode kald.
Koden i EX1 indeholder 2 metoder ikke 2 delegates.
Det ekvivalente til EX2 må være:
public delegate int Adder(int v1, int v2);
public delegate int Subber(int v1, int v2);
...
Adder add = (_x, _y) => _x + _y;
Subber sub = (_x, _y) => _x - _y;
(herefter kaldt EX1M)
Tilbage til det type sikre.
For det første tillader EX2:
sub = add;
i modsætning til EX1M.
Hvis det var enest problem, så var det ikke noget stort problem, fordi ingen ville lave noget sådant kode.
Men prøv og sammenlign EX1M og:
public int Test2(int x, int y, int z, Adder add, Subber sub)
{
return sub(add(x, y), z);
}
med EX2 og:
public int Test2(int x, int y, int z, Func<int, int, int> add, Func<int, int, int> sub)
{
return sub(add(x, y), z);
}
I det første får man compile fejl hvis man bytter om på add og sub i kaldet.
I det andet får man bare et forkert resultat.
Fordi at Adder og Suber er forskellige mens Func<int, int, int> og Func<int, int, int> er ens.
Hvis man sender delegates igennem mange metode kald så er det en reel risiko at bytte rundt på nogle argumenter.
Og i traditionel C# bruger delegates netop typisk til at send gennem metode kald.
arne_v (54) skrev:#53
Du virker ret blissed !:-)
Når Windcape kan skrive :
Windcape (50) skrev:Det ville pynte på din trolling, hvis du rent faktisk vidste hvor lidt cross-platform Java faktisk er :p
viser han jo klart, han ikke aner hvad der er op eller ned, og bare holder fast i sin egne naive fanboy forestillinger.
Ikke mere. I dag bruger man Func/Action. Der er ingen der skriver nyt kode hvor de bruger gamle delegates.arne_v (55) skrev:Og i traditionel C# bruger delegates netop typisk til at send gennem metode kald.
Det er jo ikke specielt humoristisk , når det faktisk er tilfældet i temmelig mange sprog!arne_v (56) skrev:En lidt mere humoristisk måde at se på det er:
Hvis Func<T1,T2,T3> er godt til alle funktioner med 2 argumenter, så må Data<T1,T2> da være godt til alle data klasser med 2 properties.
Data<T1, T2> er jo også bedre kendt som en tuple.
Det næste bliver vel at du ikke kan lide monads. Jeg tror det er mere en smagssag, end et reelt programmerings-problem. Der er jo også folk som mener at checked exceptions er en god ting.
Windcape (60) skrev:#59
http://bash.org/?338364 , det må være nok argument til dig, med din egen argumentationsform.
lol
Så du indrømmer, du ikke aner hvad du snakker om, og der ikke er noget hold i dine subektive fanboy fantasier.
WinPower (57) skrev:Når Windcape kan skrive :
Jeg tænkte nu på klassikere som:
Lad os alle lige være opmærksome på at dette igen viser at Windows på alle kanter er Linux overlegen.
Det er rigtigt .... Det er det eneste sted Linux høre hjemme. I en virtuel maskine på en Windows box.
Det er rigtigt. - Alt andet end Windows er noget lort.
Hvorfor spilde sin til på noget andet, når nu Windows er bedst
Microsoft er så store og har så mange udviklere ansat og patenter at de er de bedste.
Windcape (58) skrev:Ikke mere. I dag bruger man Func/Action. Der er ingen der skriver nyt kode hvor de bruger gamle delegates.
De bruger alle sammen delegates.
Func<> er en delegate.
Eneste forskel er om de bruger en de selv har defineret eller en generel MS har defineret.
Og min pointe er brug af domain specifikke delegates er mere type sikker end brug af generelle kun karakteriseret ved argument typerne.
Windcape (58) skrev:
Det er jo ikke specielt humoristisk , når det faktisk er tilfældet i temmelig mange sprog!
Jo.
Men det er mindre type safe.
Og det er ikke almindelig praksis i C# at bruge dem til alt.
Og jeg trpr heller ikke at det bliver almindeligt.
Der er andre sprog end C# som ikke lægger speciel meget vægt på type sikkerhed.
Og de har også deres berettigelse.
I så fald er det en unødvendighed sikkerhed, ligesom checked exceptions.arne_v (64) skrev:Og min pointe er brug af domain specifikke delegates er mere type sikker end brug af generelle kun karakteriseret ved argument typerne.
Det er det blevet. Eller er det ihvertfald i den dele af .NET verdenen jeg færdes i.arne_v (67) skrev:Og det er ikke almindelig praksis i C# at bruge dem til alt.
Det *er* almindeligt. Ihvertfald inden for .NET open source, og i alle virksomheder jeg kender. Samt alting der vedrører UI udvikling (ASP.NET, WP7, WPF, Silverlight, etc.)arne_v (67) skrev:Og jeg trpr heller ikke at det bliver almindeligt.
Jeg er altså ikke sikker på at type-safe er det rigtige ordvalg her.arne_v (67) skrev:Der er andre sprog end C# som ikke lægger speciel meget vægt på type sikkerhed.
Der er jo ikke type-fejl der kan opstå. Det er expression trees som risikere at blive sat op forkert.
Windcape (68) skrev:Det er det blevet. Eller er det ihvertfald i den dele af .NET verdenen jeg færdes i.
Virkeligt?
Man definerer ikke længere klasser med properties. Man har droppet ORM (de kan vist ikke virke med generelle data klasser). Man har droppet WCF data contracts. O.s.v..
Det er ikke ligefrem det jeg ser.
Windcape (68) skrev:Jeg er altså ikke sikker på at type-safe er det rigtige ordvalg her.
Der er jo ikke type-fejl der kan opstå. Det er expression trees som risikere at blive sat op forkert.
Det er et helt traditionelt eksempel på manglende type sikkerhed.
Se følgende eksempel:
using System;
namespace E
{
public class Program
{
public static void PrintAddress(Tuple<string,string,string> adr)
{
Console.WriteLine(adr.Item1 + " bor " + adr.Item2 + " i " + adr.Item3);
}
public static void PrintQuestions(Tuple<string,string,string> spm)
{
Console.WriteLine("Spm. 1 : " + spm.Item1);
Console.WriteLine("Spm. 2 : " + spm.Item2);
Console.WriteLine("Spm. 3 : " + spm.Item3);
}
public static void Main(string[] args)
{
Tuple<string,string,string> adr = Tuple.Create("Anders Andersen", "A Vej 123", "A By");
Tuple<string,string,string> spm = Tuple.Create("Hvad er 2+2?", "Hvad er 2-2?", "Hvad er 2*2?");
PrintAddress(spm);
PrintQuestions(adr);
Console.ReadKey();
}
}
}
Windcape (68) skrev:I så fald er det en unødvendighed sikkerhed,
Mere type sikkert er altid mere type sikkert.
Det er ikke nødvendigvis bedre.
Hvis mere type sikkerhed altid var vedre så ville alle web apps blive skrevet i Ada Server Pages!
:-)
Man vælger et niveau af type sikkerhed udfra tyoen af applikation.
Brugen af Func<> er ret udbredt og jeg har aldrig hørt om et faktisk problem ved det.
Data<> eller Tuple<> som den hedder i .NET bruges derimod kun i mere begrænset omfang.
Windcape (50) skrev:Det ville pynte på din trolling, hvis du rent faktisk vidste hvor lidt cross-platform Java faktisk er
Det ville pynte på din <et eller andet>, hvis du vidste hvor cross platform Java faktisk er.
Hvis man kigger på resultaterne fra forskellige surveys så finder man at:
- ca. 1/2 af Java udviklerne skriver kode som skal i produktion på flere platform
- ca. 3/4 af Java udviklere skriver kode som kører på forskellige platforme
(forskellen på de to tal skyldes dem der udvikler og unit tester på en platform og deployer på en anden - i praksis er det som oftest udvikle på Windows og deploye på en eller anden *nix)
Det virker faktisk ude i den virkelige verden.
Og det virker også for alle andre sprog, hvor der er skrevet compilere til de givne platforme.arne_v (72) skrev:Det virker faktisk ude i den virkelige verden.
Og hvad hjælper det? Intet.
Jeg ser ingen Java til iOS, Windows Phone, og Android kører sin egen udgave (Dalvik). Og Java på OSX er notorisk kendt for at kører af helvede til.
Så at kalde Java for cross-platform, er ligeså seriøst som at kalde COBOL for cross-platform.
Og at vælge Java fordi at det "virker på flere platforme" er et meningsløst (næsten latterligt) argument. Der er andre sprog/frameworks som virker på flere platforme.
Og i den virkelige verden, så bruger folk Windows, Linux eller OSX, alle platforme som Mono virker på. Altså kan vi konkludere at C# er ligeså meget cross-platform som Java.
Faktisk mere, da Java som platform er langt bagud funktionalitetsmæssigt fra C#/.NET.
#73 - pointen var jo ikke om .Net kunne køres på andre platforme - diskussionen gik på Java og det kan køre på alle de store platforme.
Der er så årsager til, at det ikke kan køre på bl.a. iOS, Android og WP.
I Android har Google valgt en anden JVM, fordi den er optimeret til et mobilt os, men det betyder ikke du får det meste fra standard JDK'en og mere til - dog har jeg bemærket, at de har fjernet nogle standard metoder på bl.a. Strings, som de åbenbart syntes var overflødige.
Siden Apple ingen intentioner har om at lave en JVM til iOS så vil der aldrig komme understøttelse af Java på iOS givet den model Apple kører efter. Apple tillader ikke "manipulering" af selve os'et andet end af dem selv, så du skal jailbreake din iPhone for at kunne komme til at installere en JVM.
Vedr. WP kan jeg kun skønne, at Oracle (SUN) og MS aldrig bliver gode venner og derfor vil MS aldrig tillade en JVM på WP. Det ville jo dybest set også være underligt, hvis de gjorde - C# og Java er jo konkurrende sprog...
Din påstand om, at Java er berømt for ikke at køre særligt godt på OsX kunne jeg da godt tænke mig en uddybning af. Ja der er problemer med at acceptere certifikater i browseren, men vel og mærke kun i Apples egen browser (Safari) - det virker fint i Chrome og FF fx. Men det er så også en storm i et glas vand, hvis det er det eneste du mener ikke virker på OsX.
Der er så årsager til, at det ikke kan køre på bl.a. iOS, Android og WP.
I Android har Google valgt en anden JVM, fordi den er optimeret til et mobilt os, men det betyder ikke du får det meste fra standard JDK'en og mere til - dog har jeg bemærket, at de har fjernet nogle standard metoder på bl.a. Strings, som de åbenbart syntes var overflødige.
Siden Apple ingen intentioner har om at lave en JVM til iOS så vil der aldrig komme understøttelse af Java på iOS givet den model Apple kører efter. Apple tillader ikke "manipulering" af selve os'et andet end af dem selv, så du skal jailbreake din iPhone for at kunne komme til at installere en JVM.
Vedr. WP kan jeg kun skønne, at Oracle (SUN) og MS aldrig bliver gode venner og derfor vil MS aldrig tillade en JVM på WP. Det ville jo dybest set også være underligt, hvis de gjorde - C# og Java er jo konkurrende sprog...
Din påstand om, at Java er berømt for ikke at køre særligt godt på OsX kunne jeg da godt tænke mig en uddybning af. Ja der er problemer med at acceptere certifikater i browseren, men vel og mærke kun i Apples egen browser (Safari) - det virker fint i Chrome og FF fx. Men det er så også en storm i et glas vand, hvis det er det eneste du mener ikke virker på OsX.
Altså iOS har jo flere brugere end Linux, så konklusionen må jo være at det kan Java ikke. Til gengæld kan du gå Mono til alle de store (Jeg betragter ikke Solaris som stor i dag).Darwind (74) skrev:diskussionen gik på Java og det kan køre på alle de store platforme.
Altså må C# jo til enhver tid være et bedre valg end Java, hvis man vælger ud fra hvor stor support der er.
Men min pointe simpel: Det er dybt idiotisk at vælge Java (eller Mono), alene på den baggrund at det virker på mere end ét OS.
# Java og Crossplatform.
Der er issues, hvilket også er en af grundene til Apple langerede Rosetta ( http://en.wikipedia.org/wiki/Rosetta_(software) ).
Forskellene er bare ikke i de 99.99% af ting som de fleste udviklere bruger, men fx skal du vide om dit software skal køre på en intel eller en PPC processor, da der er nogle ting der ikke virker ens der.
Der er issues, hvilket også er en af grundene til Apple langerede Rosetta ( http://en.wikipedia.org/wiki/Rosetta_(software) ).
Forskellene er bare ikke i de 99.99% af ting som de fleste udviklere bruger, men fx skal du vide om dit software skal køre på en intel eller en PPC processor, da der er nogle ting der ikke virker ens der.
#78 - hvor mange Mac's kører på PPC nu til dags? Apple har jo ikke produceret PPC maskiner de sidste par år (3-4 år?) og man kan vist heller ikke opgradere sin PPC maskine til nyere OsX end 10.5? Hvilket betyder, at de brugere hænger fast på Apple's udgave af Windows XP. De mac mennesker jeg kender stiller sig ikke tilfreds med en forældet version af OsX og smider derfor gladeligt penge efter en ny mac og så ender de jo igen på en Intel baseret cpu ;) Det bliver så spændende hvis rygterne om ARM processorer holder vand...
#79, Jeg vil give dig ret i at PPC-Macs ikke er specielt udbredte, da de ikke er produceret siden 2005 eller sådan noget (De kan dog køre med OSX 10.5.8 fra 2009 (OSX 10.5 kom i 2007 så det er 6 år nyere end XP, XP er mere ala OSX 10.0)
Men Power PC arkitekturen har IBM kørt videre til server systemer (se fx www.power.org ) - Så ja, de bruges i dag.
Men min pointe var også bare at det ikke er en 100% cross platform compatibility på Java.
Helt baseret på ingen kilder, mener jeg også at kunne huske noget om at "tics" i system timer, også kan variere afhænigt af hvilket OS man køre.
Men Power PC arkitekturen har IBM kørt videre til server systemer (se fx www.power.org ) - Så ja, de bruges i dag.
Men min pointe var også bare at det ikke er en 100% cross platform compatibility på Java.
Helt baseret på ingen kilder, mener jeg også at kunne huske noget om at "tics" i system timer, også kan variere afhænigt af hvilket OS man køre.
Windcape (76) skrev:Altså iOS har jo flere brugere end Linux, så konklusionen må jo være at det kan Java ikke. Til gengæld kan du gå Mono til alle de store (Jeg betragter ikke Solaris som stor i dag).
Altså må C# jo til enhver tid være et bedre valg end Java, hvis man vælger ud fra hvor stor support der er.
Men min pointe simpel: Det er dybt idiotisk at vælge Java (eller Mono), alene på den baggrund at det virker på mere end ét OS.
Du har en utrolig ordkløvertendens... større platforme mener jeg traditionelle os som Windows, OsX, Linux osv. Og hvorfor er det idiotisk at lave programmer på baggrund af, at det kan køre på mange platforme? Det forstår jeg simpelthen ikke. Det er da netop totalt intelligent, da du netop kan ramme et større marked og derved eksempelvis tjene flere penge på dit produkt.
Windcape (77) skrev:Java som sprog har kun vækst pga. Android.
Hvorfor helvede tror du at Objective-C har den højeste vækst af samtlige sprog på den liste, når det kun bruges til én ting, og det er iOS udvikling!
Få nu dine facts straight i stedet for bare at slynge om dig med påstande. Objective C bruges OGSÅ til OsX programmer.
#81 - her har du en kilde http://download.oracle.com/javase/1,5.0/docs/api/j... :P Det er korrekt, at der kan være problemer med tidsangivelserne, men så skal man bare ikke bruge currentTimeInMillis()
Men, at en PPC så kan køre 10.5.8 betyder ikke så meget - synes jeg læste, at Apple har bebuddet, at supporten på 10.5 udløber meget snart, hvilket betyder, at der heller ikke kommer nye opdateringer til Java og des lige - så PPC'erne er knapt så relevante set ud for et bruger-synspunkt ;)
#79 - ja, så hører du jo til de få ville jeg mene ;)
Men, at en PPC så kan køre 10.5.8 betyder ikke så meget - synes jeg læste, at Apple har bebuddet, at supporten på 10.5 udløber meget snart, hvilket betyder, at der heller ikke kommer nye opdateringer til Java og des lige - så PPC'erne er knapt så relevante set ud for et bruger-synspunkt ;)
#79 - ja, så hører du jo til de få ville jeg mene ;)
Normalt kun til interfacing med Cocoa (OSXs pendant til Aero).Darwind (82) skrev:Få nu dine facts straight i stedet for bare at slynge om dig med påstande. Objective C bruges OGSÅ til OsX programmer.
(Jeg er udemærket klar over det. Det er ikke en påstand, det er en generalisering)
Det er jo så igen der hvor ting som fx Firma maskiner kommer ind.Darwind (83) skrev:#79 - ja, så hører du jo til de få ville jeg mene ;)
Pt. sidder jeg ude hos en kunde, og har fået udleveret en Lenovo T50 eller T60 fra 2005 som den maskine jeg skal bruge til udvikling.
Så der findes gammelt lort derude der bruges, måske primært i virksomheder, men det er desværre noget man stadig er nødsaget til at tænke over.
Og ja, currentTimeInMillis() må man så bare undgå, og der er sikkert også andre ting man skal undgå.. men så er vi igen derude at man vist godt kan sige at en Java ikke nødvendigvis fungere 100% ens på alle OS'er der understøtter SUN/Oracles JVM. :)
Hvad har Rosetta med Java at gøre? Rosetta blev brugt til at kører PPC binaries på x86. Der sår godt nok noget om Java men det er kun at du ikke kan kalde Apples JVM(som er kompilet til x86) fra et PPC program. Det har vil ikke noget med Javas crossplatformness.Saxov (78) skrev:# Java og Crossplatform.
Der er issues, hvilket også er en af grundene til Apple langerede Rosetta ( http://en.wikipedia.org/wiki/Rosetta_(software) ).
Windcape (73) skrev:Og det virker også for alle andre sprog, hvor der er skrevet compilere til de givne platforme.
Windcape (73) skrev:Så at kalde Java for cross-platform, er ligeså seriøst som at kalde COBOL for cross-platform.
Jeg tror, at du har misforstået hvad cross platform går ud på.
Det drejer sig om hvorvidt man kan bruge den samme kode på forskellige platforme ikke hvorvidt der er compilere til forskellige platforme.
Med Java kan du uploade dine jar/war/rar/ear filer og det virker.
Med Cobol tager du en kopi af kildekoden og går i gang med at tilrette den til den nye platform.
Stor forskel.
Hvis man vil kan man nuancere cross-platform ikke-cross-platform til:
1) kopier binaries
2) kopier source og rebuild
3) mindre tilretninger med brug af platform conditionals i source og build scripts
4) store tilretninger
5) umuligt da sproget ikke undrstøttes
Java er i kategori 1. Cobol er i kategori 4. Hello world i C er i kategori 2. Et real world C program vil typisk være i kategori 3.
Windcape (73) skrev:Og i den virkelige verden, så bruger folk Windows, Linux eller OSX,
I den virkelige verden kører et stort antal servere andre styresystemer.
z/OS, i, AIX, Solaris, HP-UX, OpenVMS etc..
Windcape (73) skrev:alle platforme som Mono virker på. Altså kan vi konkludere at C# er ligeså meget cross-platform som Java.
Hvis MS dropped MS .NET og "skubbede" alle .NET brugerne over på Mono kunne det godt blive en seriøs cross platform teknologi.
Men vi ved jo alle at det sker ikke.
Saxov (78) skrev:
Der er issues, hvilket også er en af grundene til Apple langerede Rosetta ( http://en.wikipedia.org/wiki/Rosetta_(software) ).
Forskellene er bare ikke i de 99.99% af ting som de fleste udviklere bruger, men fx skal du vide om dit software skal køre på en intel eller en PPC processor, da der er nogle ting der ikke virker ens der.
Nej.
Den samme Java kode virker på begge hardware platforme.
Native kode kan drille lidt.
(et af problemerne kan være at Power er big endian mens x86-64 er little endian)
Og derfor er der så tilsyneladende lavet noget software til at hjælpe med det.
Men hvis du læser dit eget link vil du se, at Java kun omtales i forbindelse med:
- native kode der kaldes fra Java
- native kode der kalder Java
Saxov (81) skrev:Helt baseret på ingen kilder, mener jeg også at kunne huske noget om at "tics" i system timer, også kan variere afhænigt af hvilket OS man køre.
Saxov (85) skrev:Og ja, currentTimeInMillis() må man så bare undgå, og der er sikkert også andre ting man skal undgå.. men så er vi igen derude at man vist godt kan sige at en Java ikke nødvendigvis fungere 100% ens på alle OS'er der understøtter SUN/Oracles JVM.
Java er stadig underlagt visse hardwar restriktioner:
- hvis OS timer springer med X ms, så springer resultatet fra en Java tids funktion også mindts med X
- hvis skærmen kun kan køre 600x800 så kan Java ikke køre 768x1024
- hvis det er en single core CPU kan Java ikke køre 4 gange hurtigere ved at bruge 4 tråde
Det må man leve med og kode efter.
PS: Java er iøvrigt ikke egnet til realtime programmering.
PPS: Det er kotyme at OS leverandøren leverer JVM. Stort set eneste undtagelse er at SUN valgte også at understøtte Linux og Windows. Linux har ikke rigtigt en leverandør og MS ville ikke lave en 100% kompatibel Java.
@Windcape. Nu har du bevæget dig ud, hvor du ikke kan bunde.
Hvordan virker Java VM ;
NullPointerException at Windcape
Du viser klart du ikke fatter hat om hvordan Java VM virker.
Du kunne faktisk have reddet, den ved at sige at Java ikke er cross-platform. Det virker nemlig kun på en platform: Java VM.
Men du viser, jo hvad du har imod ikke MS-teknologier: Du forstår dem ikke.
Det er vel også derfor du foretrækker GUI frem for en shell: Du kan ikke forstå det.
Enjoy your bliss, wannabe-nørd.
Hvordan virker Java VM ;
NullPointerException at Windcape
Du viser klart du ikke fatter hat om hvordan Java VM virker.
Du kunne faktisk have reddet, den ved at sige at Java ikke er cross-platform. Det virker nemlig kun på en platform: Java VM.
Men du viser, jo hvad du har imod ikke MS-teknologier: Du forstår dem ikke.
Det er vel også derfor du foretrækker GUI frem for en shell: Du kan ikke forstå det.
Enjoy your bliss, wannabe-nørd.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.