On Aug 18, 11:21 am, Charles Oliver Nutter head...@headius.com
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
On Aug 16, 1:49 pm, Casper Bang casper.b...@gmail.com 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
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 note
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
On Aug 17, 2:08 am, Peter Becker peter.becker...@gmail.com 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
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
Reinier Zwitserloot wrote:
On Aug 17, 2:08 am, Peter Becker peter.becker...@gmail.com 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
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
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
On Aug 13, 6:14 pm, Casper Bang casper.b...@gmail.com 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
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
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
Charles Oliver Nutter wrote:
On Aug 12, 3:52 am, Casper Bang casper.b...@gmail.com 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
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
On Aug 14, 6:32 am, Ben Schulz ya...@gmx.net 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
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
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
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
On Aug 14, 2:20 pm, Reinier Zwitserloot reini...@gmail.com 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
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
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
On Thu, Aug 13, 2009 at 1:11 AM, Jess Holle je...@ptc.com 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
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
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.
On Thu, Aug 13, 2009 at 1:20 PM, Ben Schulz ya...@gmx.net 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
On Thu, Aug 13, 2009 at 7:29 AM, Jess Holle je...@ptc.com 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
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
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
On 13 Aug., 13:43, Casper Bang casper.b...@gmail.com 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
Michael Kimsal wrote:
On Thu, Aug 13, 2009 at 7:29 AM, Jess Holle je...@ptc.com
mailto:je...@ptc.com 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
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
On Thu, Aug 13, 2009 at 1:51 PM, Ben Schulz ya...@gmx.net wrote:
On 13 Aug., 13:43, Casper Bang casper.b...@gmail.com 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
On Thu, Aug 13, 2009 at 1:42 PM, Ben Schulz ya...@gmx.net 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
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
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
On Aug 12, 10:56 am, Casper Bang casper.b...@gmail.com 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
On Aug 12, 3:52 am, Casper Bang casper.b...@gmail.com 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
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
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
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 ++
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
About project lombok, in reply to:
On Aug 13, 7:50 pm, Charles Oliver Nutter head...@gmail.com 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,
About project lombok, in reply to:
On Aug 13, 7:50 pm, Charles Oliver Nutter head...@gmail.com 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,
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
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.
On Aug 13, 2:03 pm, Reinier Zwitserloot reini...@gmail.com wrote:
About project lombok, in reply to:
On Aug 13, 7:50 pm, Charles Oliver Nutter head...@gmail.com wrote:
Project Lombok seems to be mostly a set of annotations for common Java
patterns, rather than a new language. What I'd
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#
On Aug 13, 8:01 am, Jess Holle je...@ptc.com 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
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 are
On 14 Aug., 00:17, Eric erjab...@gmail.com 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
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 that a
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.
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
On 14 Aug., 04:51, Reinier Zwitserloot reini...@gmail.com 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
On Aug 11, 8:55 pm, Casper Bang casper.b...@gmail.com 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
On Aug 12, 1:43 am, Charles Oliver Nutter head...@gmail.com 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, ...)
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
On Aug 12, 1:23 pm, Reinier Zwitserloot reini...@gmail.com 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.
On Wed, Aug 12, 2009 at 8:46 PM, Augusto augusto.sellh...@gmail.com wrote:
On Aug 12, 1:23 pm, Reinier Zwitserloot reini...@gmail.com wrote:
Incidentally, projectlombok.org's goals are pretty much that: A
java.next for the rest of us. Closures, more literals, probably
extension methods
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
On Wed, Aug 12, 2009 at 11:04 PM, Reinier Zwitserloot reini...@gmail.comwrote:
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
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 the
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 circuits
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 operators,
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
65 matches
Mail list logo
