mboost-dp1
Næste store JVM sprog er C#
Stephen Colebourne har skrevet en artikel omkring hvilket sprog han mener det er "The Next Big JVM Language".
http://www.jroller.com/scolebourne/entry/the_next_...
Mere specifikt foreslår han disse her ting som features
Sjovt som det passer 99% med C# :-)
http://www.jroller.com/scolebourne/entry/the_next_...
Mere specifikt foreslår han disse her ting som features
In terms of features, I covered a long list of features and issues that a new language should address.
- C-like syntax (familiar and good-enough)
- Static typing (dynamic is too loose and ineffective for this type of language)
- OOP with functional elements (pure functional too hard for mainstream)
- Easy access reflection (to escape the static typing restrictions)
- Properties (because getters and setters are crazy)
- Closures (capturing looping design patterns)
- Null-handling (preferably a means to declare whether each variable can or cannot hold null)
- Concurrency story (something better than raw threads and shared mutable state)
- Modules (need to be thinking in terms of larger units)
- Tools (need a language to be designed to help tool writers)
- Extensibility (allowing some additions without going back to the language designer)
Sjovt som det passer 99% med C# :-)
#1
C# er vist ret langt fra 99% af den liste.
Java er endnu længere væk, men forskellene på Java og C# er et eller andet sted i Java 7 og 8 planerne, så hvis C# var nok så var der slet ikke nogen grund til at skifte - man kunne nøjes med at speede Java SE udviklingen op.
C# er vist ret langt fra 99% af den liste.
Java er endnu længere væk, men forskellene på Java og C# er et eller andet sted i Java 7 og 8 planerne, så hvis C# var nok så var der slet ikke nogen grund til at skifte - man kunne nøjes med at speede Java SE udviklingen op.
#1
Jeg er iøvrigt ikke så imponeret af hans kommentarer.
Mit eksemplar af EJB 3.1 spec er stadig fuld af checked exceptions, så Java EE afviser ikke checked exceptions.
Jeg er iøvrigt ikke så imponeret af hans kommentarer.
1) Checked exceptions. Spring rejects them. Hibernate rejects them. Java EE rejects them. They are a failed experiment (good in theory, bad in practice). Now, many reading this blog still hold checked exceptions dear to your hearts. But I'm afraid its finally time to say "wake up and smell the coffee". Checked exceptions have been rejected by all the key industry API writers and leaders at this point. If you're still using or advocating checked exceptions, then I'm afraid your skill set is 5 to 10 years out of date. Period. (I know that may sound harsh, but to those in that camp, you seriously need to open your mind to what modern API design is about.)
Mit eksemplar af EJB 3.1 spec er stadig fuld af checked exceptions, så Java EE afviser ikke checked exceptions.
Well, det er jo heller ikke rene sprog features han kommer med, men også forslag til et base-class-library.arne_v (2) skrev:C# er vist ret langt fra 99% af den liste.
C# + .NET dækker stort set samtlige punkter.
Det er stadigvæk ironisk hvor mange af de punkter han nævner der dækkes ind af C#. De features som C# nu har haft i et pænt stykke tid (læs: årevis), har Java stadigvæk ikke fået sig nosset sammen til at få, og det ser jo ud til at Java 7 vil gemme halvdelen til Java 8, fordi de ellers aldrig bliver færdige.
C# har fået cirka 2-3 nye versioner på den tid Java har fået én.
C# er platformuafhængigt, og ISO/ECMA standardiseret (Java er ikke).røvskæg (5) skrev:Burde et af kravene ikke også være, at det er platformuafhængigt.
*host* Og der er færre patentproblemer end Java *host*
Vi snakker om sprog, og tilhørende base libraries, ikke platformsspecifikke libraries.
#2 Som jeg ser det:
C-like syntax
- Check
Static typing
- Check
OOP with functional elements
- Check (Linq, Extension Methods, Lambda)
Easy access reflection
- Missing (But C# got dynamics instead)
Properties
- Check
Closures
- Check (Delegates, lambda)
Null-handling
- Check (Nullable<T>)
Concurrency story
- Check (ConcurrentBag<T>)
Modules
- Missing
Tools
- Check (CLR, DLR)
Extensibility
- Check (Extension Methods, Annotations)
C-like syntax
- Check
Static typing
- Check
OOP with functional elements
- Check (Linq, Extension Methods, Lambda)
Easy access reflection
- Missing (But C# got dynamics instead)
Properties
- Check
Closures
- Check (Delegates, lambda)
Null-handling
- Check (Nullable<T>)
Concurrency story
- Check (ConcurrentBag<T>)
Modules
- Missing
Tools
- Check (CLR, DLR)
Extensibility
- Check (Extension Methods, Annotations)
Windcape (10) skrev:
Null-handling
- Check (Nullable<T>)
Nullable er ikke det han efterlyser.
Det er nærmest det modsatte.
Han vil have:
@NotNull
Foo bar = new Foo();
...
baz(bar);
...
void baz(@NotNull Foo bar) {
...
}
Konstruktionen efterlyses en gang imellem for at undgå NPE's.
Windcape (10) skrev:
Concurrency story
- Check (ConcurrentBag<T>)
Der skal noget mere end collections specialiseret for concurrency til at give en god concurrency story.
Iøvrigt fik Java sådanne i 2004.
Windcape (10) skrev:
Extensibility
- Check (Extension Methods, Annotations)
Extensions methods udvider library ikke sproget.
Annotations (som det hedder i Java) er et meget primitivt værktøj til at udvide sproget med.
Ups ja, det er "Attributes" i C#.
Men mht. NPE's så kan man jo benytte sig af CodeContracts i .NET 4.0. Sprogudvidelser i stil med C++ synes jeg måske det er bedre at være foruden.
De vigtigste punkter mener jeg stadigvæk er det at et sprog er hybrid mellem imperativt og funktionelt, og at der er mulighed for closures.
Det er to ting jeg har meget svært ved at leve uden i dag. Og Java er en af de eneste mainstream sprog tilbage der ikke har understøttelse for closures!
Men mht. NPE's så kan man jo benytte sig af CodeContracts i .NET 4.0. Sprogudvidelser i stil med C++ synes jeg måske det er bedre at være foruden.
De vigtigste punkter mener jeg stadigvæk er det at et sprog er hybrid mellem imperativt og funktionelt, og at der er mulighed for closures.
Det er to ting jeg har meget svært ved at leve uden i dag. Og Java er en af de eneste mainstream sprog tilbage der ikke har understøttelse for closures!
Windcape (12) skrev:Og Java er en af de eneste mainstream sprog tilbage der ikke har understøttelse for closures!
Afhænger vist lidt af hvad du betragter som mainstream og hvad du betragter som clojures.
Men indtil #() syntaxen (eller hvad det nu ender med) kommer til Java, så må du jo nøjes med de anonyme klasser.
Måske skulle jeg lige tilføje:
Jeg mener ikke at anonyme klasser er en "rigtig" implementation af closures.
Dog synes jeg det er fint at Java vælger at gå direkte til lambda med #() {} (tilsvarende () => {} i C#), frem for at definere et specifikt closure construct (delegate i C#, function i JavaScript, osv.)
Jeg mener ikke at anonyme klasser er en "rigtig" implementation af closures.
Dog synes jeg det er fint at Java vælger at gå direkte til lambda med #() {} (tilsvarende () => {} i C#), frem for at definere et specifikt closure construct (delegate i C#, function i JavaScript, osv.)
#16
I den "næsten perfekte" ende, se også følgende:
http://csharpindepth.com/Articles/Chapter5/Closure...
Og vedr. Java
http://www.javac.info/
https://docs.google.com/View?docid=k73_1ggr36h
I den "næsten perfekte" ende, se også følgende:
http://csharpindepth.com/Articles/Chapter5/Closure...
Og vedr. Java
http://www.javac.info/
https://docs.google.com/View?docid=k73_1ggr36h
Windcape (14) skrev:#13
.NET sprog, javascript, php, ruby, python, c++ har alle closures.
Java har ikke..
Jeg tror at der er en del C programmører som vil undre sig over at Ruby og Python er mainstream men C ikke er.
Der er måske sågar nogle Cobol programmører som vil undre sig, men der vil jeg så undre mig over at de undrer sig. :-)
Windcape (15) skrev:Jeg mener ikke at anonyme klasser er en "rigtig" implementation af closures.
Det er det heller ikke. Det er et objekt og ikke en funktion.
Men den praktiske forskel er kun at man skal taste en ekstra linie ind foroven og en afslutnings parentes mere.
#18
Jeg kan vel ikke nævne samtlige mainstream sprog. Nu nævnte jeg nogle stykker.
At et sprog som COBOL mangler closures er et mindre problem, end et sprog som Java gør det.
(+ @Override annotation)
Jeg kan vel ikke nævne samtlige mainstream sprog. Nu nævnte jeg nogle stykker.
At et sprog som COBOL mangler closures er et mindre problem, end et sprog som Java gør det.
Og bruge final over det hele!arne_v (19) skrev:Men den praktiske forskel er kun at man skal taste en ekstra linie ind foroven og en afslutnings parentes mere.
(+ @Override annotation)
Windcape (20) skrev:Og bruge final over det hele!
Nogen vil betragte det som en fordel at man skal markere det der skal bruges som final.
Der er ihvertfald mange C# udviklere som har været lidt forvirret over hvad der skete i deres closures.
Windcape (20) skrev:(+ @Override annotation)
Kun hvis det er en klasse.
Det er valid for interfaces også (fra 1.6), men efter min mening bad practice i den sammenhæng.
C# er platformuafhængigt, og ISO/ECMA standardiseret (Java er ikke).
*host* Og der er færre patentproblemer end Java *host*
Vi snakker om sprog, og tilhørende base libraries, ikke platformsspecifikke libraries.
C# .NET dækker stort set samtlige punkter.
Et stort, stort hul, lige dér i din oprindelige udtalelse:
Sjovt som det passer 99% med C# :-)
.NET er ikke platform uafhængigt.
Ergo dækker C# ikke 99% af alle kravene, og er derfor ikke en mulig kandidat, som påpeget af #5.
#23
Det er måske en okay artikel hvis man er (meget) inde i C# og er interesseret i hvordan det er i de forskellige versioner. Og man godt kan lide at se hvor grimt det er i java så man kan fryde sig.
Jeg er ikke interesseret i at få at vide gang på gang at man ikke har closures.
Jeg mangler stadig at vide hvad der sker når funktionen(/metoden) closuren er lukket under er færdig med at udfør og måske mere interessant er hvad der sker hvis den bliver kaldt igen.
Jeg er ikke vant til closures i sprog hvor man muterer rundt på alle objekter, så jeg ved ikke rigtigt hvordan det fungerer.
Edit:
Jeg gad godt at vide mere om følgende:
- Concurrency
- Extensibility (allowing some additions without going back to the language designer)
Skal det forstås således at det er nemt at lave parsere i C#?
Det er måske en okay artikel hvis man er (meget) inde i C# og er interesseret i hvordan det er i de forskellige versioner. Og man godt kan lide at se hvor grimt det er i java så man kan fryde sig.
Jeg er ikke interesseret i at få at vide gang på gang at man ikke har closures.
Jeg mangler stadig at vide hvad der sker når funktionen(/metoden) closuren er lukket under er færdig med at udfør og måske mere interessant er hvad der sker hvis den bliver kaldt igen.
Jeg er ikke vant til closures i sprog hvor man muterer rundt på alle objekter, så jeg ved ikke rigtigt hvordan det fungerer.
Edit:
Jeg gad godt at vide mere om følgende:
- Concurrency
- Extensibility (allowing some additions without going back to the language designer)
Skal det forstås således at det er nemt at lave parsere i C#?
Personligt tror jeg ikke at C# bør/kan bliver det næste store JVM sprog. C# inkorporerer muligvis en del af punkterne, men det er også efterhånden blevet til det datalogiske svar på biksemad. (Um! Det er godt, det putter vi også i) Et sprog defineres også i høj grad af de muligheder det *ikke* giver. Ellers ville C være da shizzle!
Og hans holdning til checked exceptions (og den tilhørende philosofi) er da ret trist.
Nej, men C# er heller ikke nødvendigvis == .NET
Og hans holdning til checked exceptions (og den tilhørende philosofi) er da ret trist.
ZiN (24) skrev:.NET er ikke platform uafhængigt
Nej, men C# er heller ikke nødvendigvis == .NET
illishar (30) skrev:C# inkorporerer muligvis en del af punkterne, men det er også efterhånden blevet til det datalogiske svar på biksemad. (Um! Det er godt, det putter vi også i)
Windcape (31) skrev:Skyldes i høj grad Hejlsbergs pragmatiske tilgang til alting.
MS har tydeligvis ingen problemer med feature creep.
Jeg betragter det som en risikabel strategi. De sidste to sprog der forsøgte at kunne alt var Ada95 og PL/I - og de var ikke nogen stor success.
onetreehell (29) skrev:
- Extensibility (allowing some additions without going back to the language designer)
Skal det forstås således at det er nemt at lave parsere i C#?
Det er vist ca. det samme som i Java.
Windcape nævner extension methods under extensibility.
Men jeg kan ikke se at det skulle være specielt relevant for parsere.
#extension methods
De fungerer som:
Du savner en .ToHexString() method på int, så du laver en:
og så kan du bruge:
i.ToHexString()
Det kan være ret bekvemt når man vil tilføje ny funktionalitet til nogle klasser uden at ændre klasserne.
Men det kan godt blive lidt grumset at finde ud af hvor den extension method kommer fra.
De fungerer som:
Du savner en .ToHexString() method på int, så du laver en:
public static class MyExtensions
{
public static string ToHexString(this int o)
{
return o.ToString("X");
}
public static string ToVmsString(this DateTime o)
}
og så kan du bruge:
i.ToHexString()
Det kan være ret bekvemt når man vil tilføje ny funktionalitet til nogle klasser uden at ændre klasserne.
Men det kan godt blive lidt grumset at finde ud af hvor den extension method kommer fra.
Mtjah, intellisense gør det meget fint.arne_v (35) skrev:Men det kan godt blive lidt grumset at finde ud af hvor den extension method kommer fra.
Og da Visual Studio tillader man kan gå til definition, endda selvom det er i et assembly uden vedhæftet kildekode, er det ikke noget jeg betragter som et problem.
Der er visse konventioner, som man så kan bruge til at gøre det nemmere.
F.eks. IntExtensions.cs for extensions til int.
Windcape (40) skrev:Til testing tilgår man jo bare sin extension som static.
Test as kode og fejlsøgning er ikke det samme.
Når du skriver en test ved du rent faktisk hvilken kode du tester.
Når du fejlsøger et problem i en applikation, kan du sagtens være i tvivl om hvilken del af koden "den er gal med".
Gå til top
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.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund