Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (533)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2 3
  ignore  |  Print  
  Tiger, Mustang, Dolphin  (Read 7785 times)
0 Members and 1 Guest are viewing this topic.
Offline Bombadil

Senior Member





« Posted 2004-12-06 08:10:22 »

Don't miss part II of the interview with Graham Hamilton, Sun Fellow in the Java Platform Team at Sun Microsystems.
Tiger and Beyond, the Future of the Java Platform
Offline phazer

Junior Member




Come get some


« Reply #1 - Posted 2004-12-06 10:47:47 »

"Code should do what it seems to do -- developers shouldn't need to worry about clever language side effects or about what "=" means this week."

I think Sun broke this rule in 1.5 when they added autoboxing and static imports. :-/

Offline shawnkendall

Senior Member





« Reply #2 - Posted 2004-12-06 12:40:27 »

You misquoted, it should read...

"Code should do what it seems to do -- developers shouldn't need to worry about clever language side effects or about what "=" means this week, except in the cases of when we added autoboxing and static imports."

Wink

Shawn Kendall
Cosmic Interactive, LLC
http://www.facebook.com/BermudaDash
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline DaveLloyd

Junior Member




Making things happen fast with Java!


« Reply #3 - Posted 2004-12-06 13:30:26 »

Agreed about autoboxing and static imports. But I really would like to see Java get some form of user defined operators. My previous fave language of all time was Algol 68 which while not widely popular did set the pace for 20 years or more of programming languages. Algol 68 provided user defined operators and they really are invaluable. I'm fed up with doing vector algebra in the following form (and vecmath is clumsy even in the OO mould):

a.add (b)
a.sub (c)
a.cross (d)

instead of

(a + b - c) /\ d

which is how I wrote it in A68.

Unfortunately C++ has muddied the waters badly and anyone in recent years who has played with user-defined operator has come away with the impression that it is a bad thing. It need not be.

(1) Don't allow the assignment operator to be overloaded - that really is bad (and was not allowed in A68 ).

(2) Only allow new meanings of operators to be supplied - redefining addition between ints really is bad (and was also not allowed in A68 )

In an OO world I'd be quite happy to go with something really simple such as '+' between object types gets expanded so that
   a + b == a.add (b)
and so forth. It is now just syntactic sugar and there is no new semantics. Generics would make this much more workable as well.

Probably the only remaining argument against operators in my book is the 'pure'ness of operators - i.e., operators are expected to be side-effect free (and this is enforced in Fortran 90 which follows the Algol 68 heritage in its approach). I'm not sure what 'pure' what mean in an OO world... without going the full functional route.

Of course we would need a new stable of operators to play with as well - A68 provided a general grammar for creating new operators (such as /\ above along with \/ and many others) but that is probably not a Java way of doing things.

Dave

Offline princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #4 - Posted 2004-12-06 14:17:31 »

I've always disagreed strongly with operator overloading, but not the ability to define new methods that can be used syntactically like operators. Thusly:

float cos = a dot b;

or

Matrix4f result = a mult b;

Cas Smiley

Offline phazer

Junior Member




Come get some


« Reply #5 - Posted 2004-12-06 15:00:57 »

Operator overloading is a hot carrot. When used correctly it can improve the readability of code, but when used incorrectly it produces mayhem.

My opinion is that for the common Java programmer operator overloading is of limited use, therefore it's not worth adding the extra complexity to the language. Also, operators are on the same abstraction level as normal method calls, so they don't present the programmer's intentions any clearer (which for example generics and foreach does). But I'm sure most mathematicians and physicists miss it. Smiley

Cas, your suggestion looks like Smalltalk. We don't want that.

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #6 - Posted 2004-12-06 15:43:07 »

Quote
Algol 68 provided user defined operators and they really are invaluable.


In the interests of fairness, you don't mean that.

You mean "...for a strictly limited set of use-cases, one of which happens to be 3D algebra, which happens to be very popular in games development, but otherwise isn't widely used".

Personally, (i.e. not @ Dave) I think:
- people who complain that a.dot(b) is bad do have a point but really are just whining Tongue. I've written quite a few software 3D engines and actually, when all is said and done, your code is VERY readable if you use sensible naming conventions, and potentially a lot BETTER than redefining operators.

For instance, the (general [X]) ability to distinguish between:
- a dot b, result in a
- a dot b, result returned
- both at once
- each of the above, with normalisation
- ...etc
is IMHO just as "invaluable" as your operator overloading, and yet mutually exclusive. So, overall, IMHO, there is no great loss in not having operator overloading, and it *neatly* sidesteps an awful lot of pain, both the feared/dreaded and the genuinely experienced.

[X] = also applies to many other aspects of vector algebra. When you have a decent *and consistent* Grin naming scheme for it, this gets very very handy.

- I'd consider Cas's compromise, since my main gripe with op-overloading is that reduces your ability to glance at code and know what it does; Cas's route at least ensures every key operator is EXACTLY what I memorized it as, and I never have to think about them. Except instanceof, which suddenly looks strange Smiley (and, incidentally, Eclipse is incapable of auto-completing half the time. Stupid broken parser Angry). Sadly, the anti-op-overloading proponents have a very poor vocab, and tend to say "you can't glance at code and know what it does". BS. We all know that's not true. But...what IS true is that the percentage of code on screen where you have to engage your brain reduces/increases dramatically.

In addition, op-overloading converts arbitrarily long AND DESCRIPTIVE method names to excessively short and NON-DESCRIPTIVE names. c.f. all the arguments over long/short var-names. Ignore the final outcomes, where IDE's auto-complete made the arugment redundant, and revise some of the pros of long names.

So IMHO op-overloading increases the programmer workload for all maintenance, at the saving of initial prototype workload. So ... like a scripting language, really. Funny how C++ programmers tend to try and sneak in scripting-lang features elsewhere whilst declaiming how terrible scripting languages are and incapable of real programming (tongue-in-cheek!).

- Seeing as it's a (large) niche desire, it would seem sensible that some proprietary extension allow for it - like AspectJ and friends. What really intrigues me is that despite the multitude of such add-ons, there don't seem to be any major ones for op-overloading (are there any?). Which leads me to seriously question the validity of op-overloading as a "much needed" feature...

malloc will be first against the wall when the revolution comes...
Offline DaveLloyd

Junior Member




Making things happen fast with Java!


« Reply #7 - Posted 2004-12-06 16:24:46 »

blahblahblahh wrote:
Quote

In the interests of fairness, you don't mean that.

You mean "...for a strictly limited set of use-cases, one of which happens to be 3D algebra, which happens to be very popular in games development, but otherwise isn't widely used".

No I really do! 3D algebra is a big one granted (and IMHO a very important one) but not the only one. Differential algebra is another. Pattern languages and regular expressions can also make good use of operators without having to parse a string with a grammar that can't be checked at compile time. It's hard to remember all the uses of operators because they used to be such a common element in my toolkit.

It's interesting that you mention the new foreach statement - that adds nothing but syntactic sugar, yet I'm tidying up (and making intelligible again) vast tracts of code that had horrible iterators. Java finally catches up with 30 odd years of good programming language design.

At the end of the day Van Wijngaarden had it right (sorry I don't have the master's quote around) - a programming language should seduce you into writing correct code that someone else can understand immediately.

I read math far faster than English. That's why we don't use the old Cobol syntax of "add a to b giving c"!

Anyway: rant-off ;-)

Offline Raghar

Junior Member




Ue ni taete 'ru hitomi ni kono mi wa dou utsuru


« Reply #8 - Posted 2004-12-06 17:18:53 »

(a + b - c) /\ d

a is added to be and c is subtracted from it then  the result is xored...

Why should be mathematicans tokens better than programmers ones? Mathematicians books are filled just by lots of unreadable symbols where two clear sentences could be better.

firstVector = vm.add(firstVector, secondVector);
vm.add(firstVector, firstVector, secondVector);
is rather clear. //you could even use assambly notation.

Yes if you'd have a predefined unmodificable language syntax for it, you could have a little simplier live. Then again how do you know there is nothing else than addition? There could be a nice funcition that do a little more than addition. Just a few lines more that would be paintfull to write in mathematical notation.
And I coudl instead vm.add(. use qm.add(. Code readibility would be consistent.

(for discusion about consitent "operator overloading" look at the forum.java.sun.com. Search for Lord_of_the_chaos and language improvements block...)

Offline princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #9 - Posted 2004-12-06 17:18:55 »

They aren't a much needed feature really. Structs on the other hand are Smiley

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline DaveLloyd

Junior Member




Making things happen fast with Java!


« Reply #10 - Posted 2004-12-06 17:40:01 »

I can see this is a matter of background and taste as much as anything! My background is maths & physics so operators are natural to me.

But I don't want to start a religious war here - blahblahblahh probably has it right with his suggestion of an AspectJ like extension and see if evolution favours it as it did with generics and Pizza. Ho hum, yet another project to add to my stack...

Now structs I really don't see the point of ;-)

Dave

Offline nonnus29

Senior Member




Giving Java a second chance after ludumdare fiasco


« Reply #11 - Posted 2004-12-06 23:50:17 »

Personally, I'm against operator overloading because I have recently begun learning stuff like 3d math were people have used overloaded operators and to me it was confusing.  Also, I don't get the C++ 'lets overload ( and ) and call it functor!!!' sure I appreciate functors, but it just seems awkward to me.

Dave, you know some cobol, I'm sorry.    Tongue
Offline Grazer

Junior Member




My other avatar is much more flattering.


« Reply #12 - Posted 2004-12-07 04:10:36 »

Quote

a.add (b)
a.sub (c)
a.cross (d)

I'd expect that to be able to be written as:

  a.add(b).sub(c).cross(d);

which I think makes as much sense as operator overloading, and probably more.

Current Project: Easy Decal
Other Stuff: grlea online
Offline Grazer

Junior Member




My other avatar is much more flattering.


« Reply #13 - Posted 2004-12-07 04:17:08 »

Quote
Now structs I really don't see the point of ;-)

Personally, I actually do struggle to see the point of structs!
I think this is probably because of my shortage of non-Java dev experience.

I'm guessing the "cool" thing about structs is that you could write (psuedocode):
1  
2  
MyStruct ms = ...;
out.write(*ms, 0, sizeof(ms));

Is that right? i.e. That's how structs are used in C/C++?

When people ask for Java to have structs, is this the use case that they're really asking for?
i.e. the ability to write out an object (without all the serialisation crud) without having to write each element to a ByteBuffer?

Or was the whole dialogue about wanting structs a joke that has now become at my expense?  Cheesy

Current Project: Easy Decal
Other Stuff: grlea online
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #14 - Posted 2004-12-07 04:32:49 »

yup, thats one of the primary reasons.

Offline Spasi
« Reply #15 - Posted 2004-12-07 08:31:18 »

Quote
"you can't glance at code and know what it does"


When this happens to me, I know I've done something stupid, or I coded it really fast, so I rewrite it immediately. It also *always* happens whenever I look at code outside of an IDE, even with plain syntax colorizing. I mean, you can't know what's a class, what's an instance/static method/field, etc., just by glancing your code. Everything feels mixed up (and I'm talking about standard Java code).

That's why I never code outside of my IDE. My brain can't function properly without the intuitiveness of having non-local variables colored specially, methods in bold, static stuff in italics, etc.

On topic: I wouldn't mind some form of operator overloading, but I'd NEVER use it without help from a decent IDE.
Offline princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #16 - Posted 2004-12-07 08:44:57 »

NO, that wasn't what structs was about!! Structs was about memory mapping fields in a Java object to a direct byte buffer. And nothing else. Structs I now realise was such a bad, loaded, name for them. Sigh.

And as for operator overloading: the reason it has so singularly upset everyone is because no-one can agree what silly squiggles mean what. Maths is full of symbols you can't type, so C++ people have generally overloaded all sorts of symbols in imaginative ways. If we stuck to method names as operators we'd get the best of both worlds: proper operator overloading and readable code.

Cas Smiley

Offline MasterDirk

Senior Newbie




Somebody set up us the bomb...


« Reply #17 - Posted 2004-12-07 13:15:37 »

Quote
...Structs I now realise was such a bad, loaded, name for them. ...


Shouldn't that be "such a bad, overloaded name..."?

J/K


Grin
Offline princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #18 - Posted 2004-12-07 13:49:40 »

*groan*

Offline Giddy

Senior Newbie




Java games rock!


« Reply #19 - Posted 2004-12-07 15:19:46 »

what is wrong with autoboxing?
Offline Raghar

Junior Member




Ue ni taete 'ru hitomi ni kono mi wa dou utsuru


« Reply #20 - Posted 2004-12-07 18:32:02 »

Guess... everything?
Offline phazer

Junior Member




Come get some


« Reply #21 - Posted 2004-12-07 20:31:47 »

Quote
what is wrong with autoboxing?


Here's whats wrong with autoboxing:

http://www.javalobby.com/forums/thread.jspa?threadID=13257&tstart=270

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #22 - Posted 2004-12-07 21:46:22 »

Quote


Sigh. Am seriously considering quitting java (not anytime soon, but starting the process of re-specialising in something else) over the crap that's been forced upon us with java 5. Especially given how long and hard people (Sun, and others) fought to keep much more important things OUT of java, only finally to cave in on things like this that are astonishingly poor by comparison.

At the end of the day, those with numerical superiority are simply throwing their weight about and proving that if one uses a language whose main users by volume and wealth probably ought to be using Visual Basic for most of their work that you WILL get ****ed over, sooner or later, when the language gets dragged off in a hopeless direction. Hopeless to you, that is; for them, it's evolution.

You can't blame them for wanting to turn the only language they use (java) into the language they really want (VB), hoping to retain some of the exclusive benefits of the one, but not at the cost of keeping them away from the other.

A little part of me somewhere still holds out hope that java 6 will cut the "assert" crap and substitute in a real assertion system, now that 1.4 has forced people around the world to re-write their code to avoid the new keyword. Yeah right; might as well hope to wake up one day and find generics has been removed from all future versions of java...

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #23 - Posted 2004-12-07 21:47:22 »

Quote
what is wrong with autoboxing?


If nothing else, the fact that it (and generics) could actually have been so very much better designed and implemented. Makes you wonder how - with the combined might of all these tech companies - they managed to end up with such a mess.

malloc will be first against the wall when the revolution comes...
Offline nonnus29

Senior Member




Giving Java a second chance after ludumdare fiasco


« Reply #24 - Posted 2004-12-07 22:52:36 »

Quote
Sigh. Am seriously considering quitting java (not anytime soon, but starting the process of re-specialising in something else) over the crap that's been forced upon us with java 5.


Yeah, but were would you go?  What other platform or language can give you half of what java does?
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #25 - Posted 2004-12-08 04:33:06 »

That is quite a pitfall with autoboxing.

For projects one controls, one can always have a rule against autoboxing in the coding standards.

Will.

Offline phazer

Junior Member




Come get some


« Reply #26 - Posted 2004-12-08 06:16:31 »

Quote
For projects one controls, one can always have a rule against autoboxing in the coding standards.


Yes, it would be nice if javac had an option for each new language feature that would issue a warning when the feature is used.

Offline princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #27 - Posted 2004-12-08 07:55:57 »

I just set Eclipse to 1.4 and let it complain Smiley I don't think I'm going to use any features other than static import. Maybe enums one day.

Cas Smiley

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #28 - Posted 2004-12-08 08:33:48 »

enums are a good idea, saves having enum classes all over the place.

Of course, I am waiting for 1.5 on Mac first...

Will.

Offline aldacron

Senior Member


Medals: 9
Exp: 16 years


Java games rock!


« Reply #29 - Posted 2004-12-08 09:13:01 »

Quote


Yeah, but were would you go?  What other platform or language can give you half of what java does?



D is shaping up to be a nice alternative. I'm finding myself working with it more and more. Many of the newsgroup regulars are disgruntled Java programmers. As such, several of the community libraries springing up have a distinct Java flavor.
Pages: [1] 2 3
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

pw (24 views)
2014-07-24 01:59:36

Riven (24 views)
2014-07-23 21:16:32

Riven (18 views)
2014-07-23 21:07:15

Riven (21 views)
2014-07-23 20:56:16

ctomni231 (50 views)
2014-07-18 06:55:21

Zero Volt (45 views)
2014-07-17 23:47:54

danieldean (36 views)
2014-07-17 23:41:23

MustardPeter (39 views)
2014-07-16 23:30:00

Cero (56 views)
2014-07-16 00:42:17

Riven (55 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!