[The Java Posse] Re: NetBeans getting support for the Fan language

> Forgot to mention...CLR does not have any support for dynamic > invocation. Even the "dynamic" keyword in C# 4 is just porcelain over > the DLR's dyncall pipeline. Ah ok, that's what I was fishing for - not much info about this from John Lam nor Jim Huginen. > Oh, and I think it's important to

[The Java Posse] Re: NetBeans getting support for the Fan language

On Aug 16, 1:49 pm, Casper Bang wrote: > Got it. I just don't find it's very popular to talk about these things > though, having aired my share of similar thought on this group and > witnessing the Kumbaya backlash with a dash of Microsoft demonization > thrown in for good measure. A large group

[The Java Posse] Re: NetBeans getting support for the Fan language

On Aug 18, 11:21 am, Charles Oliver Nutter wrote: > > Btw. how come invokedynamic is needed for the JVM when the DLR is > > merely a library? Is it because the CLR already has dynamic dispatch > > or because they don't seek the same performance profile as you do? Forgot to mention...CLR does not

[The Java Posse] Re: NetBeans getting support for the Fan language

You must be a blast to be around, what with all the laughing. Make sure you stop to breath once in a while, Alex. I do feel we've come to an understanding that the JCP, for reasons that are their own and may well be very sensible, has no interest whatsoever in fixing java's shortcomings in regards

[The Java Posse] Re: NetBeans getting support for the Fan language

Again, laughable. There are technical reasons for and against op.overloading for BigDecimal/BigInteger, all of which Sun has considered in the past and none of which I am prepared to rehearse here. There are also strategic choices to be made: if we work on BD/BI overloading, we cannot work on some

[The Java Posse] Re: NetBeans getting support for the Fan language

Reinier Zwitserloot wrote: > On Aug 17, 2:08 am, Peter Becker wrote: > >> Has anyone ever wondered about the idea of replacing the JDK first? >> > > Yes. I think the right way to go about it is to first define a > construct whereby you can create mirrors. The representation in memory > is

[The Java Posse] Re: NetBeans getting support for the Fan language

I have been thinking about similar things, but then you get into the question of combining multiple algebras with overlapping types. Or you could have second-order constructs, such as creating your MatrixVectorAlgebra on top of an algebra for the scalars. If you use constructors as in your exa

[The Java Posse] Re: NetBeans getting support for the Fan language

On Aug 17, 2:08 am, Peter Becker wrote: > Has anyone ever wondered about the idea of replacing the JDK first? Yes. I think the right way to go about it is to first define a construct whereby you can create mirrors. The representation in memory is one thing, but any calls from your code to access

[The Java Posse] Re: NetBeans getting support for the Fan language

You know, your post made me think of this construct: using ( new MatrixVectorAlgebra() ) { Matrix result = matrix * vector; } using ( new ExactMath() ) { BigInteger i = 10 * foobar; } the algebra controls both how literals get translated, and the meanings of all operators. Just throwing

[The Java Posse] Re: NetBeans getting support for the Fan language

Charles Oliver Nutter wrote: > On Aug 12, 3:52 am, Casper Bang wrote: > >>> I like Fan. But to be honest, I wish there wasn't quite so much >>> attention paid to API-compatibility across both JVM and CLR worlds. >>> >> You mean as in it's too easy to write code depending on one or the >

[The Java Posse] Re: NetBeans getting support for the Fan language

To twist the thread a bit more: IMO the whole idea of having an operator with mixed types on a class is bad. So is having the Matrix.multiply(Vector) method. The Matrix-Vector product (left or right) is not intrinsic to either type, it is part of a larger algebra. Unfortunately OO won the mark

[The Java Posse] Re: NetBeans getting support for the Fan language

Got it. I just don't find it's very popular to talk about these things though, having aired my share of similar thought on this group and witnessing the Kumbaya backlash with a dash of Microsoft demonization thrown in for good measure. A large group of developers for instance looks at JavaFX as Su

[The Java Posse] Re: NetBeans getting support for the Fan language

On Aug 13, 6:14 pm, Casper Bang wrote: > What I admittedly still don't quite understand, is Charles critique > regarding dependencies on heavy and foreign runtime libraries. The > fact that fcode is transformed to CIL or bytecode natives is just an > implementation detail in my head to make use o

[The Java Posse] Re: NetBeans getting support for the Fan language

all, That last email was meant for Reinier and Alex only. I apologize for whatever harm may have been caused. iPhone user #fail Maybe they should make a "do you really want to send this to everyone?" annoying popup for folk like me. Sent from my iPhone On Aug 14, 2009, at 5:32 PM, Josh

[The Java Posse] Re: NetBeans getting support for the Fan language

Hypothesis: There is a central body in charge of (possibly amongst other things) picking on a case-by-case basis types for which java should add operator support. Proof that this hypothesis is false: Surely, BigInteger and BigDecimal have warranted operator support for many many years. If a cent

[The Java Posse] Re: NetBeans getting support for the Fan language

On Aug 14, 2:20 pm, Reinier Zwitserloot wrote: > The sheer amount of 'coin isn't making changes fast enough' sentiment > here and in the rest of the java community is -staggering-. But, apart > from that, if lombok gets some traction and adds a bunch of useful > features, but this one much touted

[The Java Posse] Re: NetBeans getting support for the Fan language

I'm not sure how others feel, but I think pretty soon this conversation will be finished with any kind of technical merit and turn into name-calling and one-uping. I usually reserve cuddle pictures of kittens (Everyone Loves Kittens) just for this kind of debate when it hits the Scala mailing lis

[The Java Posse] Re: NetBeans getting support for the Fan language

Hey, I have some lofty goals. I don't know if lombok can get there. I sure hope so, though. The sheer amount of 'coin isn't making changes fast enough' sentiment here and in the rest of the java community is -staggering-. But, apart from that, if lombok gets some traction and adds a bunch of usef

[The Java Posse] Re: NetBeans getting support for the Fan language

True, I should have said 'use an annotation to trigger the rewriting'. That's my issue: you can only try out language features that are concerned with declarations, since that's all you can annotate. It's like being a sports car designer but insisting you can only work with an automatic transmissi

[The Java Posse] Re: NetBeans getting support for the Fan language

On Aug 14, 6:32 am, Ben Schulz wrote: > > I like how you begin the paragraph "On the contrary" as if disagreeing > with anything I said, insinuating I made the statistical fallacy you > are talking about. > You said x + 0 is still x in the end, which I presumed meant: Even if speeding is not dir

[The Java Posse] Re: NetBeans getting support for the Fan language

> I mean I essentially want a language that has no baggage other than a > new compiler. Scala, Clojure, JRuby, Groovy, Fan all fall down on this > point because they drag a (sometimes very large) runtime library with > them. I think java.next needs to compile down to "just bytecodes" and > have no

[The Java Posse] Re: NetBeans getting support for the Fan language

On 14 Aug., 04:51, Reinier Zwitserloot wrote: > On the contrary. It's a statistical fallacy that leads to a lot of > wasted effort [...] I like how you begin the paragraph "On the contrary" as if disagreeing with anything I said, insinuating I made the statistical fallacy you are talking about.

[The Java Posse] Re: NetBeans getting support for the Fan language

On the contrary. It's a statistical fallacy that leads to a lot of wasted effort - if you are under the presumption that speeding CAUSES accidents, you will go overboard on spending resources on reducing speeding, instead of plucking low hanging fruit that would fight reckless driving. It can also

[The Java Posse] Re: NetBeans getting support for the Fan language

Alex, you seem to misunderstand a thing or two about lombok and APs. The two obvious mistakes: - An Annotation Processor that is registered to listener for everything is called, both on initialization and for each class, even if there are no annotations anywhere in the entire source code base. Y

[The Java Posse] Re: NetBeans getting support for the Fan language

> So, if a new Java-like language is going to break existing Java source- > code (because features need to be removed, not added from Java), then > why not just accept the bigger step of a language designed from > scratch to meet modern needs. And once you do that, you pretty > necessarily find th

[The Java Posse] Re: NetBeans getting support for the Fan language

On Aug 13, 7:22 pm, Casper Bang wrote: > > Project Lombok seems to be mostly a set of annotations for common Java > > patterns, rather than a new language. What I'd like to see is someone > > take javac, hack all the missing features into it, and call it > > something new. > > I've looked at java

[The Java Posse] Re: NetBeans getting support for the Fan language

On 14 Aug., 00:17, Eric wrote: > I do sometimes wish for operator overloading and people encoding > their Java source files in UTF-8 so that operators like !=, <=, and >= > could be written in Unicode as U+2260 NOT EQUAL TO, U+2264 > LESS THAN OR EQUAL TO, and U+2265 GREATER THAN OR > EQUAL TO.  

[The Java Posse] Re: NetBeans getting support for the Fan language

> There's one safeguard on roads that actually saves lives: Driving > lessons. If you put somebody behind the wheel of a car, they can kill > people at the drop of a hat, and no amount of laws are going to stop > this from being true. You get that license because the state > recognizes that they a

[The Java Posse] Re: NetBeans getting support for the Fan language

On Aug 13, 8:01 am, Jess Holle wrote: > That said, I don't see how it "speeds up execution".  It just reduces > >     vector2 = matrix.multiply( vector1 ); > > to > >     vector2 = matrix * vector1; > > Nice example of clear and concise (and appropriate) use of operator > overloading -- but not

[The Java Posse] Re: NetBeans getting support for the Fan language

I can see why support for the observer pattern this way can attract some criticism. I don't know if much is gained but I do know that one of the hardest things in programming is often coming up with meaningful and consistent names i.e. add/append/push/insert/put. I would also claim that, in C# any

[The Java Posse] Re: NetBeans getting support for the Fan language

On Aug 13, 2:03 pm, Reinier Zwitserloot wrote: > About project lombok, in reply to: > > On Aug 13, 7:50 pm, Charles Oliver Nutter wrote: > > > Project Lombok seems to be mostly a set of annotations for common Java > > patterns, rather than a new language. What I'd like to see is someone > > take

[The Java Posse] Re: NetBeans getting support for the Fan language

I'd agree that C++'s lack of garbage collection made operator overloading a non-starter for most usages (e.g. matrix arithmetic for one). Apart from that, however, I don't see any improvement in operator overloading elsewhere. It's interesting when actually dealing with mathematical types. It

[The Java Posse] Re: NetBeans getting support for the Fan language

I feel C++'s operators were problematic for different reasons. I actually highly approved of them, the big issue was *not* complexity of operator overloading, but of operator overloading + memory management. C++ caused a whole lot of pain in determining what kind of operators to support, how sho

[The Java Posse] Re: NetBeans getting support for the Fan language

About project lombok, in reply to: On Aug 13, 7:50 pm, Charles Oliver Nutter wrote: > Project Lombok seems to be mostly a set of annotations for common Java > patterns, rather than a new language. What I'd like to see is someone > take javac, hack all the missing features into it, and call it >

[The Java Posse] Re: NetBeans getting support for the Fan language

About project lombok, in reply to: On Aug 13, 7:50 pm, Charles Oliver Nutter wrote: > Project Lombok seems to be mostly a set of annotations for common Java > patterns, rather than a new language. What I'd like to see is someone > take javac, hack all the missing features into it, and call it >

[The Java Posse] Re: NetBeans getting support for the Fan language

Ben, excellent point, in that you're totally wrong. There's one safeguard on roads that actually saves lives: Driving lessons. If you put somebody behind the wheel of a car, they can kill people at the drop of a hat, and no amount of laws are going to stop this from being true. You get that licen

[The Java Posse] Re: NetBeans getting support for the Fan language

Actually, Stephen, I think scala got it right and fan got it wrong: Whenever I work with scala, operator overloading shines exactly for the non-standard set. In fact, that holds for pretty much every language with operator overloading I ever worked with. For example, (only in languages where ++ is

[The Java Posse] Re: NetBeans getting support for the Fan language

Look, all this "Oh, just look at C++" is /very/ old hat. C++ operator overloading is a nightmare, but the point of history is that you learn from it, not that you hold them up as perpetual boogeymen. There are 3 reasons for C++'s problems, and they are all easily avoided: (A) We didn't know be

[The Java Posse] Re: NetBeans getting support for the Fan language

> Project Lombok seems to be mostly a set of annotations for common Java > patterns, rather than a new language. What I'd like to see is someone > take javac, hack all the missing features into it, and call it > something new. I've looked at javac and although no expert, it looks as if it's been

[The Java Posse] Re: NetBeans getting support for the Fan language

On Aug 12, 10:56 am, Casper Bang wrote: > Well Fan provides it's own, very tight and polished API that compiles > into fcode which again compiles to CIL, bytecode or JavaScript. It > then also provides interoperability mechanisms within the language but > the API's themselves are supplied by the

[The Java Posse] Re: NetBeans getting support for the Fan language

On Aug 12, 3:52 am, Casper Bang wrote: > > I like Fan. But to be honest, I wish there wasn't quite so much > > attention paid to API-compatibility across both JVM and CLR worlds. > > You mean as in it's too easy to write code depending on one or the > other? (selective interoperability rather tha

[The Java Posse] Re: NetBeans getting support for the Fan language

In my experience, you usually have a few core developers who create "samples" or "frameworks" on how you do XYZ in code. Then all the junior (or sometimes just lazy) developers cut and paste, tweaking as needed. I had a whole team come up to speed on Javascript/ExtJS because two of us would desig

[The Java Posse] Re: NetBeans getting support for the Fan language

We give programmers great flexibility in naming things. Programmers can and do misname things. Smart teams use guidelines, mentoring, code reviews, and refactoring to prevent, detect, and fix misnaming problems. Operator overloading does not fundamentally change the nature of the problem or its

[The Java Posse] Re: NetBeans getting support for the Fan language

Ok perhaps that's a bit of speculation there on my part. ;) My logic is based upon that the more concise/expressive you can be, the better the compiler can infer intent and optimize accordingly. For instance, it occurs to me that operator overloading would never need to go through vtable lookups..

[The Java Posse] Re: NetBeans getting support for the Fan language

On Thu, Aug 13, 2009 at 1:42 PM, Ben Schulz wrote: > > > So the morale of the story is: If you have an HR problem, deal with it - > > educate them, start unit testing, start to have code reviews etc. > > And that's exactly the point I was trying to make. If there were no > speedlimits, how would

[The Java Posse] Re: NetBeans getting support for the Fan language

On Thu, Aug 13, 2009 at 1:51 PM, Ben Schulz wrote: > > On 13 Aug., 13:43, Casper Bang wrote: > > With all due respect, operator overloading in Fan is an entirely > > different, much less scary beast than the infamous C++ implementation > > which everyone seems to have in mind. I'm not much for g

[The Java Posse] Re: NetBeans getting support for the Fan language

I've certainly used operator overloading myself for graphics matrix math. That said, I don't see how it "speeds up execution". It just reduces vector2 = matrix.multiply( vector1 ); to vector2 = matrix * vector1; Nice example of clear and concise (and appropriate) use of operator over

[The Java Posse] Re: NetBeans getting support for the Fan language

Michael Kimsal wrote: > On Thu, Aug 13, 2009 at 7:29 AM, Jess Holle > wrote: > > I've heard the saying that you shouldn't dumb down a language for > your dimmest bulbs at the cost of your bright ones. It's not that > simple, though. If you have a sizable team wi

[The Java Posse] Re: NetBeans getting support for the Fan language

On 13 Aug., 13:43, Casper Bang wrote: > With all due respect, operator overloading in Fan is an entirely > different, much less scary beast than the infamous C++ implementation > which everyone seems to have in mind. I'm not much for guns, but to > continue gun metaphor: Python and C# both demons

[The Java Posse] Re: NetBeans getting support for the Fan language

With all due respect, operator overloading in Fan is an entirely different, much less scary beast than the infamous C++ implementation which everyone seems to have in mind. I'm not much for guns, but to continue gun metaphor: Python and C# both demonstrates that this is not necessarily an explodin

[The Java Posse] Re: NetBeans getting support for the Fan language

> So the morale of the story is: If you have an HR problem, deal with it - > educate them, start unit testing, start to have code reviews etc. And that's exactly the point I was trying to make. If there were no speedlimits, how would you "educate" people to drive at a reasonable speed? It's a poi

[The Java Posse] Re: NetBeans getting support for the Fan language

On Thu, Aug 13, 2009 at 7:29 AM, Jess Holle wrote: > I've heard the saying that you shouldn't dumb down a language for your > dimmest bulbs at the cost of your bright ones. It's not that simple, > though. If you have a sizable team without a *really *rigorous, zealous > code review (and mandato

[The Java Posse] Re: NetBeans getting support for the Fan language

On Thu, Aug 13, 2009 at 1:20 PM, Ben Schulz wrote: > > > So operator overloading is bad because people have HR problems? > > Why stop at operator overloading? To hell with all safe guards.. No > more speed limits or safty belts; let's everyone just drive > reasonably. And what's with architects a

[The Java Posse] Re: NetBeans getting support for the Fan language

Viktor Klang wrote: > > Even so I: > >1. Reject the notion that it is acceptable to require syntax > highlighting for a language to be meaningful. >2. Fear the brevity trap. > * Operators are only 1 character. Programmers are > lazy. Und

[The Java Posse] Re: NetBeans getting support for the Fan language

> So operator overloading is bad because people have HR problems? Why stop at operator overloading? To hell with all safe guards.. No more speed limits or safty belts; let's everyone just drive reasonably. And what's with architects and statics? It'll hold. > Don't blame the gun, blame the shoot

[The Java Posse] Re: NetBeans getting support for the Fan language

On Thu, Aug 13, 2009 at 1:11 AM, Jess Holle wrote: > Augusto wrote: > > Reiner; > > That's a great long post that has nothing to do with my reaction! :-) > > As Jess points out, I'm not a fan of allowing programmers to mess > around with how operators work. That doesn't mean that I like some of

[The Java Posse] Re: NetBeans getting support for the Fan language

Its fascinating that amongst all the really great features (and ease of use) that Fan has, its operator overloading that has been picked on here. Anyway, Fan and Scala have different approaches to operator overloading. Scala, IIUC, allows virtually any symbol to be a method name, and for virtuall

[The Java Posse] Re: NetBeans getting support for the Fan language

Augusto wrote: > Reiner; > > That's a great long post that has nothing to do with my reaction! :-) > > As Jess points out, I'm not a fan of allowing programmers to mess > around with how operators work. That doesn't mean that I like some of > the inconsistencies that the Java language has with oper

[The Java Posse] Re: NetBeans getting support for the Fan language

Reiner; That's a great long post that has nothing to do with my reaction! :-) As Jess points out, I'm not a fan of allowing programmers to mess around with how operators work. That doesn't mean that I like some of the inconsistencies that the Java language has with operators, but letting everybo

[The Java Posse] Re: NetBeans getting support for the Fan language

Reinier Zwitserloot wrote: > (B) The & operator is strictly binary and, and && is strictly logical > and. Exactly why is this different from the behaviour for the slash, I generally agree with the post, but I thought I would add a minor comment that & and && are different to me in that && short

[The Java Posse] Re: NetBeans getting support for the Fan language

Reinier Zwitserloot wrote: > Exactly. If java had pure operators (where the operator's meaning is > independent of the expressions on either side), then adding operator > overloading is a mess, but java's operator set is a hopeless mess. > Utterly hopeless. It makes no sense at all, and therefore t

[The Java Posse] Re: NetBeans getting support for the Fan language

On Wed, Aug 12, 2009 at 11:04 PM, Reinier Zwitserloot wrote: > > Exactly. If java had pure operators (where the operator's meaning is > independent of the expressions on either side), then adding operator > overloading is a mess, but java's operator set is a hopeless mess. > Utterly hopeless. It m

[The Java Posse] Re: NetBeans getting support for the Fan language

Exactly. If java had pure operators (where the operator's meaning is independent of the expressions on either side), then adding operator overloading is a mess, but java's operator set is a hopeless mess. Utterly hopeless. It makes no sense at all, and therefore the argument that operator overload

[The Java Posse] Re: NetBeans getting support for the Fan language

On Wed, Aug 12, 2009 at 8:46 PM, Augusto wrote: > > On Aug 12, 1:23 pm, Reinier Zwitserloot wrote: > > > Incidentally, projectlombok.org's goals are pretty much that: A > > java.next for the rest of us. Closures, more literals, probably > > extension methods and operator overloading, properties,

[The Java Posse] Re: NetBeans getting support for the Fan language

On Aug 12, 1:23 pm, Reinier Zwitserloot wrote: > Incidentally, projectlombok.org's goals are pretty much that: A > java.next for the rest of us. Closures, more literals, probably > extension methods and operator overloading, properties, lots of > boilerplate elimination, et voila. Operator over

[The Java Posse] Re: NetBeans getting support for the Fan language

Well Fan provides it's own, very tight and polished API that compiles into fcode which again compiles to CIL, bytecode or JavaScript. It then also provides interoperability mechanisms within the language but the API's themselves are supplied by the underlying JRE/CLR runtime. So I guess I don't se

[The Java Posse] Re: NetBeans getting support for the Fan language

i imagine supporting both apis increases maintenance costs while reducing performance. not a good combo. On Aug 12, 2009, at 10:23 AM, Reinier Zwitserloot wrote: > > I'm guessing that Charles doesn't like that two-way JVM/CLR crap > because it either means code bases are targeted and wholly > i

[The Java Posse] Re: NetBeans getting support for the Fan language

I'm guessing that Charles doesn't like that two-way JVM/CLR crap because it either means code bases are targeted and wholly incompatible (will you use java.util.List or c#.util.list?) or every library needs to be rewritten as an abstraction that is capable of targeting either library. Such abstrac

[The Java Posse] Re: NetBeans getting support for the Fan language

> I like Fan. But to be honest, I wish there wasn't quite so much > attention paid to API-compatibility across both JVM and CLR worlds. You mean as in it's too easy to write code depending on one or the other? (selective interoperability rather than compatibility) > And it's not Scala; it's Scal

[The Java Posse] Re: NetBeans getting support for the Fan language

On Aug 12, 1:43 am, Charles Oliver Nutter wrote: > I tell you right now, if a language with static-typing, roughly Java- > like structure, and an appropriate set of syntactic enhancements > (local type inference, real closures or sugared-up anon classes, > additional literals, ...) you'd be well

[The Java Posse] Re: NetBeans getting support for the Fan language

On Aug 11, 8:55 pm, Casper Bang wrote: > The somewhat under-covered language Fan is getting NetBeans support. > It's still early days, but already has rudimentary support for: I like Fan. But to be honest, I wish there wasn't quite so much attention paid to API-compatibility across both JVM and