|
|
Back to UserFriendly Strip Comments Index
|
trends in programming languages | by dennismv | 2004-12-06 22:57:22 |
|
Java's not doing too badly. | by williamashbless | 2004-12-06 23:16:14 |
|
The two things I miss most in Java | by ToLazyToThink | 2004-12-06 23:19:52 |
|
At the risk of running off at the mouth | by Liava | 2004-12-06 23:48:47 |
| quite a list ;-) |
by tomcat6 |
2006-11-19 12:55:59 |
Let's see what we have here...
* Structs
What for? a class can do everything a struct can, but not the other way round
* Enums
Good thing. fixed in 1.5 as you mentioned, and even better than C/C++ enums
* Const (since when should mutable/immutable be a property of the class?)
can be a good thing when used in the way mentioned by ToLazyToThink. this, OTOH, can also be accomplished by "defensive copying". I strongly recommend the great book "Effective Java" by Joshua Bloch to all Java developers.
There is, admittedly, some run time penalty with this technique.
* Destructors
Only good in a system with explicit memory management. You are certainly aware of the "finalizer()" method, but still this is no replacement for several reasons. The main reason as compared to a destructor is that you do not have any guarantee (naturally) *when* the finalizer will be executed.
So why not just put your destructor code in a "cleanup()" (or even "destructor()" ;-) method that is called in the same place where you would've called "destroy" in your C++ code (if necessary! not all classes need this) and leave the rest to the VM? I do not see any disadvantage here, only the advantage of implicit memory management.
* Operator Overloading
Nice... but only syntactic sugar. I admit that this was the thing I missed most (besides templates and const) when switching from C++ ;-) afterwards, I found that I nearly never really missed it. Still, it would make the code easier to read sometimes.
* Templates
Necessary. I used to do this with wrappers around collection classes to ensure type safety, but this is less elegant because it alters the standard API of the collection. As you mentioned, this is fixed in 1.5
* Native executables
There are commercial products that do this, the best that I know of is here. it even allows for the execution of dynamically loaded class-files (which were not compiled natively! very important feature, think of JDBC-drivers etc, albeit this works only in the more expensive versions)
* Non-virtual-by-default class functions
What for? It does, in principle, make no difference if you have a keyword to make a method "non-virtual" explicetly or "virtual" explicetly. Just declare it "final" in Java (don't tell me that typing more keywords is the problem ;-) And talking in terms of re-usability, you normally should allow the overriding of your methods, that's one of the main points in OO. IMHO what's really missing in Java and in all other OO languages, is some way to *enforce* the call of the overridden method in the overriding method (i.e. enforce the super.method() call), then you have the guarantee that overriding always means "extension" and not "breaking the behaviour" for certain important methods.
* Pass-by-reference on value types
Noooooooo.... please... c'mon... ;-) What for? This is needed *really* very rarely even in C. It just promotes bad programming behaviours like "out"-parameters, which should IMHO be an absolute nono in any OO language. if you think about it a little longer, it is even unnecessary in C. If you need to return more than one value from a function, wrap it inside a struct and pass back (by-value) an instance of this struct as the function value.
I know that even the stdio-lib in C uses out-parameters (eg in the scan...()-functions), but this just leads to code that is harder to read especially for functions that are not as "standard" as scan...() I think that the inventors of C already might think differently about this if they invented the language now ;-) but of course then it would be a completely different language all the way.
I used to think quite in the same way after switching from C to C++ and later to Java. I found out that I was still thinking too much in terms of old-school programming concepts.
The fact that languages like C# re-introduce procedural programming style *back* into OO development does not help either (this also brought us the "ellipse" feature in Java 1.5, the C++ thing I was *least* missing, because it is something that should not be done in a typed language. BTW, if you need to do something like this, do it like the reflection-classes: pass one "Class"-Array (Array of type information) and one "Object"-Array (Array of parameters), see e.g. java.lang.Class#getMethod(String name, Class[] parameterTypes) and java.lang.reflect.Method#invoke(Object obj, Object[] args)
phew, that was a long one... but I'm lying sick in bed and boring my bum off, and perhaps it was useful for someone ;-)
BTW, referring to the original post by dennismv:
Yes, it's a good thing to have references instead of pointers. pointers are error prone and pose a security risk (step outside the allowed memory etc) C# has a so-called "sandbox" to cater for that, as baywolfe mentioned.
Iterators are also a good thing, because they are object oriented, allow for concurrent read access to collections etc. and deterministic failure in case of concurrent write access (think on the contrary of more than one process modifying an array. It will be a lot of work for you as a programmer to even *detect* these concurrent accesses without synchronizing the whole thing)
The reason why Java/C# are slower does not have to do mainly with the removement of pointers - they both are not compiled to machine code by their compilers, this has to be done at runtime by an interpreter (a so called "virtual machine").
And I dare doubt that a modern C compiler creates code that's slower than ASM (with all the optimization the compiler is doing, you have to be a f...ing genius to write ASM as fast as that ;-)
|
|
[ Reply ] |
|
|
[Todays Cartoon Discussion]
[News Index]
|
|
