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] 4 5 ... 10
  ignore  |  Print  
  Things you disagree with in the java language  (Read 38060 times)
0 Members and 1 Guest are viewing this topic.
Offline Knut

Junior Newbie





« Reply #60 - Posted 2012-09-02 18:16:51 »

Yes, operator overloading can definately give room for confusing code. I would like it just for my own types (i.e. no changing the behavior of the build in classes), and even then one would have to be very careful when using the feature. Also, JavaDoc would help alot I think. It's not something I miss alot, but something that would be useful sometimes.
Offline Best Username Ever

Junior Member





« Reply #61 - Posted 2012-09-02 19:17:43 »

You would have to fix Generics to allow primitive types and do away with type erasure. You also would have to worry about extended classes. Overriding the add operator could throw in some odd behavior, and even if you made an exception to prevent overriding those methods you might want to make the entire class final just in case one method relies on another. Then for human compile time checks, you lose the ability to glance at an expression and say "That looks like the method signature of this type of function, therefore its reasonable the code has this type of semantics." I don't want to have to scroll around, check if I'm working with primitives or Objects, find every variable declaration, parse the expression, determine which overloading methods get called, mentally convert from infix notation to postfix notation, double check the meaning of each overloaded method just to make sure their are no quirks in the semantics of that operation, trace through the return values and side effects of each operation, then make a different mental map that's basically the same as the multi-line procedural format.

At the same time you lose the ability to easily make sense of arithmetic expressions. It's faster to look at an expression with familiar order of operations as in ordinary algebra. You could still overload + for concatenating and not lose anything because its obvious, behaves differently, and can't be used with other operators without conversions or parentheses. When it comes to most things, though, the use of operators tell me something useful about how primitives are being used and the use of explicit function calls tells me something useful about the way objects are being used. Mix the two, and certain blocks of code will force you to break your train of thought even if its shorter than the other version in some cases. Think of the line a = b * c; Now you have to figure out if this is a scalar-scalar multiplication, scalar-matrix multiplication, scalar-vector multiplication, matrix-matrix multiplication, vector cross product, vector dot product, or something else entirely. Then a * b may not necessarily even be close to b * a and may be defined in two different places. a = 0 * b[/t] does not necessarily mean a stores something like zero. It wouldn't be too hard, but, as Java is now, you don't currently need to methodically and roboticly parse code or learn how entire libraries work inside and out. It's like untangling headphones. Not impossible, but a huge productivity killer. Although it would be nice to use operator overloading with things similar BigInteger and BigDecimal and more efficient software implementations of types with different levels of precision than built in primitives, its not worth the trade.
Offline Danny02
« Reply #62 - Posted 2012-09-03 11:47:16 »

quick question, am I the only one around which do not think that type erasure is bad, but quite ellegant.
About operator overloading, everybodz here seems it can be bad if others use them but will not if only them use them in their own code. Why not use same Scala function classes in your Java code. One can mix Java with Scala code in the same applications with no problems(little changes to your build configuration) and Scala is an ideall language to build your own Domain Specific Language where you can overload as much you want and what you want.

PS: seems as if java-gaming.org is not banned in china, so I can at least access on of my most visited sites Smiley
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #63 - Posted 2012-09-03 12:38:52 »

I think type erasure was a great solution to get something that looked a bit like templates working backwardsly compatible with existing Java bytecode. It has its flaws and foibles but the way I use it it's all good. I especially like the new <> shortcut in Java 8.

Cas Smiley

Offline Oskuro

JGO Knight


Medals: 39
Exp: 6 years


Coding in Style


« Reply #64 - Posted 2012-09-03 13:03:14 »

Operator overloading I see as necessary (even mandatory) if you are designing new types.

I see that many of the complaints being posted here can be solved by something external to the coding language: Project coordination.

No, seriously, I see this on a daily basis at work, powerful tools have dangerous implications (like a chainsaw), and when you have a room full of chainsaw-wielding maniacs, you need some proper structure if you want to get anything accomplished (And before they start chopping each other down).


Of course, then the question is.... What is the goal of Java? If it is meant to be used exclusively as a high level  language, then by all means all these dangerous bits would need to either be locked, or made available through some advanced API (much like JNI).

If, on the other hand, we want to integrate low level capabilities.... Well, you can't make a chainsaw without the saw.


(Yes, I'm State-The-Obvious-Boy, sidekick to Captain Obvious, I know)  Roll Eyes

Offline Roquen
« Reply #65 - Posted 2012-09-03 13:45:36 »

Type erasure only exists because it didn't require changes to the verifier.  The sad thing is that the verifier was being changed anyway (and was in the next version of java).  Type refinement is very not fun with type erasure...well type erasure adds yet-more boilerplate and hacky work-arounds.  What up-side is there (other than it pushed it out the door a little earlier)?  I can't think of any.

Operator overloading:  Forget everything you think you know if you're opinion comes from C++.  Getter/setters are the one most important that java could use and would need to be VM aware (aka not-just sugar).  Other stuff is sugar and you can just slap it on top yourself.
Offline Oskuro

JGO Knight


Medals: 39
Exp: 6 years


Coding in Style


« Reply #66 - Posted 2012-09-03 14:24:15 »

I actually like how Getters/Setters are handled in C# (Properties). Way more elegant and intuitive.

Offline Roquen
« Reply #67 - Posted 2012-09-03 14:42:27 »

Personally I'd do explicit getter/setters via annotations for java.  Future possibilities include interop with muli-dimensional array, concrete arrays, etc.

(Oh yeah, needs to be VM aware cause it would suck otherwise...simple example changing a public field to a getter/setter.  Code using would need to be recompiled with identical source to work...that would be too horrible).
Offline princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #68 - Posted 2012-09-03 15:06:59 »

Using getters and setters everywhere is a symptom of not really understanding OOP though. Not that I want to spell it out but: if you're going to all the trouble of hiding the implementation of a class by making all of its member data private, and then expose it all with trivial getters and setters, what exactly have you achieved. Nothing much apart from a lot of typing, and you've also managed to expose the entire internal state of your class as public API which means you can no longer change what's under the hood without breaking everything that uses it.

So for the love of whoever you want to love, keep getters and setters to the bare minimum required for tool interop (eg. Javabeans*)

Cas Smiley

* haha, as if anyone uses them

Offline ReBirth
« Reply #69 - Posted 2012-09-03 15:14:42 »

I even see that by tighter view, no point in having a set of getter and setter for a field.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Damocles
« Reply #70 - Posted 2012-09-03 15:23:11 »

The advantage of getter and setter Methods is that you can make
a nice documentation, wich pops up in your IDE.

Together with explanations about what it is for, what to excpect, specific boundaries etc.

This is helpful when using a class again after a long time.

Ok, documentation works also with a field, but it add some security for
allowed parameter ranges.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
   /**
    * set the love contained in this entity
    * only values 0 to 8 are allowed
    * -1 will throw a "You are so rude" Exception
    * @param loveCount
    */

   public void setMyValue(int loveCount)
   {
      ..bla
   }

Offline princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #71 - Posted 2012-09-03 15:55:05 »

I hear that spouted over and over. However the 99% of getters and setters out there in the wild do no such validation and never will. They are a total waste of time and space and effort.

Use a dot, if you're simply passing properties as data around for such things as configurations. It is what a dot is for.

Cas Smiley

Offline Oskuro

JGO Knight


Medals: 39
Exp: 6 years


Coding in Style


« Reply #72 - Posted 2012-09-03 15:55:31 »

The advantage of getter and setter Methods is that you can make
a nice documentation, wich pops up in your IDE.

Yes, javadoc is my one true love! Pity I'm the only one using it in my team.  Clueless

Getters and Setters have their uses, but it does rub me the wrong way when a class has lots of them protruding like half-formed appendages.

Offline Roquen
« Reply #73 - Posted 2012-09-03 17:13:16 »

I don't use trivial getter/setter and like Cas...just say no.  But they're not the only kind (hidden composed data, disassociated data, data views).
Offline sproingie

JGO Kernel


Medals: 201



« Reply #74 - Posted 2012-09-03 18:07:44 »

There's nothing really wrong with type erasure per se -- even Haskell uses erasure -- but the problem is that Java lets you use a raw type with nothing more than a warning.  The spec says that a later version of the Java language could remove this ability, but we all know the score: nothing ever gets removed from Java, especially now that a lot of programs have come to depend on this behavior.

Scala works around erasure a lot of the time by generating and passing manifests at compile time, but there are still things manifests can't fix, like overloading or pattern matching on List<Foo> vs List<Bar>.
Offline Best Username Ever

Junior Member





« Reply #75 - Posted 2012-09-03 19:28:34 »

It does mean you can't do something like implement Multiplyable<Matrix> and Multiplyable<Double> (Big or small 'D' double...) in the same class. (I wish I could think of a better example, but this is the only non-obscure, non-trivial example that comes to mind.)
Offline Roquen
« Reply #76 - Posted 2012-09-03 19:56:42 »

Trivial type erasure boilerplate example:  I want to do this: return this; and not abstract T self(); implemented here and there as return this and always have to do return self();
Offline Sammidysam
« Reply #77 - Posted 2012-09-03 20:14:23 »

I'd like strings to auto-initialize as "" instead of null.
Offline ags1

JGO Ninja


Medals: 46
Projects: 2
Exp: 5 years


Make code not war!


« Reply #78 - Posted 2012-09-03 20:22:54 »

I have been racking my brains for days trying to think of something I dislike about Java to post on this thread, but I can't think of anything. The language is fine - generics took a bit of getting used to, but they are a great feature. If generics had been built into the language from the outset, they would probably be done differently without some of the limitations mentioned in this thread - but don't forget that many of the early Java features had serious flaws and needed major rebuilding (threading, AWT etc) - so adding generics at a late stage may actually have given us a more mature and workable system.

It would be nice if Java had some built-in vector types to make use of SIMD instructions.

Offline 65K
« Reply #79 - Posted 2012-09-03 21:17:08 »

Oh well, generics... nice for simple usage cases like collections. But for anything complex when done correct and completely it leads to unreadable verbose code.

Offline kaffiene
« Reply #80 - Posted 2012-09-04 00:10:51 »

Headers and pointers are the two biggest mistakes in C++ and the two things Java got most right, IMHO.

Cas Smiley
Yeah, I agree with this.  Fixing circular dependencies in C++ is pure hell.  C++ never should have used C's build & link process - that was a relic of the past that ought to have died.

Offline kaffiene
« Reply #81 - Posted 2012-09-04 00:24:47 »

You know, most of these things brought up in this thread are pretty unimportant IMO.  I would imagine most of us have used languages with or without operator overloading, lambdas, various kinds of generics, properties vs getters/setters and none of this makes a squat of difference to whether you can produce good code in language X.

The number of people I've seen swear black and blue that you can't use Java because it doesn't have syntactic sugar Y.  It's rubbish.  For me, the best reason to use Java is that mistakes fail early and verbosely.  When I f**k up, it tells me where and why rather than failing silently like Javascript or crashing the machine like C++.  As a whole, I like the language features in java but I doubt anyone would leave if some of these decisions were one way rather than another.  I don't like operator overloading - I have worked with C++ in large dev teams and as Cas alluded to, that can get painful - but if it were added to the language I'd embrace it the same way I now use generics although I never thought the language needed them, either.
Offline princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #82 - Posted 2012-09-04 01:02:47 »

The slow introduction of new things is a great boon to Java, I think.

Cas Smiley

Offline loom_weaver

JGO Coder


Medals: 17



« Reply #83 - Posted 2012-09-04 01:49:30 »

What I don't like are annotations.

At first they were just visual sugar but I knew that wouldn't last.  Now your code won't work if you're missing or have the wrong annotations.

As far as I'm concerned annotations are the equivalent of C macros.  Programmers can do anything inside them and the potential for misuse outweighs the advantages.
Offline princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #84 - Posted 2012-09-04 01:51:59 »

What code breaks without annotations?

Cas Smiley

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #85 - Posted 2012-09-04 01:58:17 »

Any code using the latest buzzword-compliant J2EE web application framework du jour, I'll guess.

Personally I'm not against annotations having actual semantic meaning (rather than just compiler/documentation guides), but there's some horrific over use out there. But then you can write horrible code if you (ab)use any language feature.

JUnit gets annotation usage about right in my book.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline badlogicgames
« Reply #86 - Posted 2012-09-04 02:40:46 »

Two things: i can cope with Java cause it allows a team of differently skilled people to work with each other. It has so little syntactic sugar that almost anyone can read and given a little time understand most of the code. There aren't to many ways to severly shoot yourself in the foot either. I could not imagine working on anything > 2k LOC in JS with a team spanning novices coming straight from univ. to seniors.

Also, all the things mentioned here are available in C#. Why aren't we using C# again?

http://www.badlogicgames.com - musings on Android and Java game development
Offline Best Username Ever

Junior Member





« Reply #87 - Posted 2012-09-04 04:18:30 »

You know, most of these things brought up in this thread are pretty unimportant IMO.  I would imagine most of us have used languages with or without operator overloading, lambdas, various kinds of generics, properties vs getters/setters and none of this makes a squat of difference to whether you can produce good code in language X.

The number of people I've seen swear black and blue that you can't use Java because it doesn't have syntactic sugar Y.  It's rubbish.  For me, the best reason to use Java is that mistakes fail early and verbosely.  When I f**k up, it tells me where and why rather than failing silently like Javascript or crashing the machine like C++.  As a whole, I like the language features in java but I doubt anyone would leave if some of these decisions were one way rather than another.  I don't like operator overloading - I have worked with C++ in large dev teams and as Cas alluded to, that can get painful - but if it were added to the language I'd embrace it the same way I now use generics although I never thought the language needed them, either.

All good points. Often the introduction of new features hinders the ability to create good code and decreases the quality of existing code. Any form of pointers, for example, would instantly eliminate the readability, simplicity, interoperability, stability, security, reliability, portability, and predictability of code - and degrade the usefulness of static analysis and debugging - and nullify the possibility of certain compiler optimizations. Talk about porting a feature from an entirely different language to Java always makes me cringe. Sometimes it is a sign of inexperience. I've seen a lot of people insist on coding in C++ "because it's faster" that do things like use new with every constructor. And on the other hand, some people say things about Java that suggest they know nothing about heap allocation, stack allocation, or garbage collection. Aside: It amuses me to see people C++ programmers casually talk about (quick) sorting strings being significantly slower than sorting other types.

There's a huge difference between languages like C and C++, languages like Java and C#, and languages like Javascript and PHP. C++'s special operators, copy constructors, and heavy use of value type variable assignments makes ordinary coding and working with data structures radically different from Java programming practices. You can't easily integrate every feature from or use the same part of your programming brain in both languages. Users of that final class of languages seem not to notice how strange it is to use regular expressions and built in array functions instead of working with appropriate data types and algorithms.

I don't really agree with the sentiment that things like Generics and properties are purely unnecessary syntax sugar. You can live without them, but Generics is a huge help to write good code faster without sacrificing code quality. Properties are debatable, but very similar to Generics in that respect. It also speeds up coding as a user of third party libraries. I absolutely agree with you on your best reason to use Java. My best reason to use Java is that it makes mistakes easier to find and, more importantly, makes it so much easier to avoid mistakes entirely. There are annoyances in the Java language (enough so that it might be a good idea to reinvent it or invent a new language based on it), but they all can be worked around without sacrificing much and the time it takes is usually tiny compared to the time you save when using Java in large projects or anything involving more than one person's code. It scares me when I hear serious talk about new features from other languages, especially scripting languages.
Offline sproingie

JGO Kernel


Medals: 201



« Reply #88 - Posted 2012-09-04 05:17:42 »

Once your language is turing-complete, everything is syntax sugar.  What I want to see more of in languages is "semantic sugar".  When you notice that JDK8 lambdas do local type inference, that definitely fits into the semantic sugar category, and the effects of it will ripple beyond merely more concise code, and toward fundamentally better libraries and/or idioms that use it.  When you can express map concisely, it's a quick step to fmap, and just like that, you can wave bye-bye to null.  That's the power of semantic sugar.

Offline princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #89 - Posted 2012-09-04 11:34:23 »

Yeah, er, it's just that the conceptual leap from lambda to waving goodbye to null is a hard one for us ordinary programmers to grasp after so many years without anything like it. Slowly does it! It'll take a long time to get Java programmers to make the leap from purely imperative programming to functional programming. I know this because of the number of Java programmers I've met who simply cannot write SQL.

Cas Smiley

Pages: 1 2 [3] 4 5 ... 10
  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 (26 views)
2014-07-24 01:59:36

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

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

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

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

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

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

MustardPeter (40 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!