ThoughtWorks seems to agree with the OP "Java End Of Life" is marked on their latest radar as something to assess: http://www.thoughtworks.com/radar
F# has been promoted and, along with clojure, is now close to transitioning from "assess" to "trial" interestingly, Scala seems to be the only statically-typed JVM language that's on the radar at all. <http://www.thoughtworks.com/radar> >From the .NET side, both C# 4.0 and F# are strongly typed. In general, dynamic typing continues to be strongly favoured, and functional programming is gaining ground. The placement of Functional programming is explained as: "... the assess ring indicates our view of their relative maturity and appropriateness." In ThoughtWorks terminology, this generally refers to quality of tooling and availability of experienced developers. Obviously LISP (e.g. Clojure) is a very mature language if only lifespan is considered :) Most curious of all: "JVM as a platform" has been promoted to "adopt", and yet the only JVM-capable language also flagged for adoption is JRuby. Go figure... On 1 September 2010 20:44, Kevin Wright <[email protected]> wrote: > correction... Any method defined WITHOUT A PARAMETER LIST is a de facto > property. > > > On 1 September 2010 20:44, Kevin Wright <[email protected]> wrote: > >> >> >> On 1 September 2010 20:24, Ricky Clarkson <[email protected]>wrote: >> >>> > Scala's type system is richer than that embedded into the .NET IL spec, >>> so >>> > it's impossible to fully reify on the platform. >>> >>> It is possible to reify what is supported by IL and reify the rest via >>> Manifest or a similar solution. >>> >>> > Coming from the other direction, allowing Scala to consume reified type >>> > parameters from other languages on .NET, the plan is to expose this >>> > information via Manifests, though it isn't implemented yet. >>> >>> This direction is probably more important. >>> >>> >> Is there a solution to the mismatch between .NET's >>> >> PublicMethodNamesInCapitals and Scala's lowerCaseForAlmostEverything? >>> > >>> > Isn't this just a convention? >>> >>> Yes, as far as I know, but a) mixing case conventions in one program >>> is ugly b) Scala treats identifiers that begin with uppercase >>> differently in cases. Ok, scrap this question then. >> >> >> Specifically, anything beginning with an lowercase letter is treated as a >> placeholder name in pattern matching, anything beginning with an Uppercase >> letter is treated as an extractor. As a convention, this works well, >> because constants, objects and classes tend to start with uppercase letters, >> variables with lowercase. These conventions are pretty much inherited, >> unchanged, direct from Java. >> >> This convention can be overridden by wrapping any lowercase identifier in >> `backticks`, there's essentially no need for overriding in the other >> direction (binding an extracted value to a an uppercase-prefixed identifier) >> >> >>> >> Does Scala on .NET support .NET's properties without having to write >>> >> Get_X and Set_X >>> > >>> > By design, there's no separation between methods and properties in >>> Scala; so >>> > it definitely can't be automated. >>> > I don't see any reason though why properties couldn't be specified by >>> an >>> > annotation, we already do that with @BeanProperty when compiling to >>> Java >>> > bytecode :) >>> >>> I mean that it would be poor to have C# code: x.Y += a.B; translated >>> to Scala: x.Set_Y(x.Get_Y() + a.Get_B()); Even for single-character >>> names it's ugly; when you have real identifiers in there it's close to >>> obfuscation. >> >> >> >> Oh, that suggests a better approach! - I think I'll raise this one on the >> Scala lists :) >> >> Again, by convention, any method defined in Scala is a de facto property. >> It's considered VERY bad form for such a method to cause mutations, caching >> excepted. >> I see no reason why such a method shouldn't just be mapped to a property >> in .NET >> (with the corresponding setter, if present) >> >> There's only one possible catch, if properties and methods in .NET share >> the same namespace and this could cause a name clash (though I don't *think* >> it would). It should still be doable, but it'll add some extra complexity >> to IL generation, and might well make things very confusing where >> compatibility via IKVM is also involved... >> >> >> >>> >> On Wed, Sep 1, 2010 at 7:46 AM, Roland Tepp <[email protected]> >>> wrote: >>> >> > Oh, I beg to differ. >>> >> > >>> >> > Using Scala (at least on the language level) does not necessarily >>> mean >>> >> > you have to use JVM. >>> >> > >>> >> > In fact it is quite possible to write Scala source and compile it >>> >> > to .Net >>> >> > >>> >> > The only thing tying your Scala programs to JVM is your own use of >>> >> > Java libraries. >>> >> > >>> >> > On 31 aug, 14:40, Jan Goyvaerts <[email protected]> wrote: >>> >> >> I didn't say you need to be there. >>> >> >> >>> >> >> Wait until the day after to read about it - when they stopped >>> throwing >>> >> >> the >>> >> >> eggs and rotten tomato's. :-) >>> >> >> >>> >> >> Anyway, it's now owned by them and switching to Scala (or anything >>> else >>> >> >> JVM >>> >> >> related) won't change a thing. >>> >> > >>> >> > -- >>> >> > You received this message because you are subscribed to the Google >>> >> > Groups "The Java Posse" group. >>> >> > To post to this group, send email to [email protected]. >>> >> > To unsubscribe from this group, send email to >>> >> > [email protected]<javaposse%[email protected]> >>> . >>> >> > For more options, visit this group at >>> >> > http://groups.google.com/group/javaposse?hl=en. >>> >> > >>> >> > >>> >> >>> >> -- >>> >> You received this message because you are subscribed to the Google >>> Groups >>> >> "The Java Posse" group. >>> >> To post to this group, send email to [email protected]. >>> >> To unsubscribe from this group, send email to >>> >> [email protected]<javaposse%[email protected]> >>> . >>> >> For more options, visit this group at >>> >> http://groups.google.com/group/javaposse?hl=en. >>> >> >>> > >>> > >>> > >>> > -- >>> > Kevin Wright >>> > >>> > mail/google talk: [email protected] >>> > wave: [email protected] >>> > pulse: kev.lee.wright >>> > skype: kev.lee.wright >>> > twitter: @thecoda >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> Groups >>> > "The Java Posse" group. >>> > To post to this group, send email to [email protected]. >>> > To unsubscribe from this group, send email to >>> > [email protected]<javaposse%[email protected]> >>> . >>> > For more options, visit this group at >>> > http://groups.google.com/group/javaposse?hl=en. >>> > >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "The Java Posse" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]<javaposse%[email protected]> >>> . >>> For more options, visit this group at >>> http://groups.google.com/group/javaposse?hl=en. >>> >>> >> >> >> -- >> Kevin Wright >> >> mail/google talk: [email protected] >> wave: [email protected] >> pulse: kev.lee.wright >> skype: kev.lee.wright >> twitter: @thecoda >> >> > > > -- > Kevin Wright > > mail/google talk: [email protected] > wave: [email protected] > pulse: kev.lee.wright > skype: kev.lee.wright > twitter: @thecoda > > -- Kevin Wright mail/google talk: [email protected] wave: [email protected] pulse: kev.lee.wright skype: kev.lee.wright twitter: @thecoda -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
